Bonsoir,
l'emploi de Sirius va générer des dérives, et en effet l'utiliser pour se repérer en est une. Mais cela m'étonne que la SNCF ne soit pas au courant que l'ADC est un être humain et que comme tout être humain il est susceptible d'utiliser un outil qui prétend le positionner justement comme raccourcis pour justement se positionner quand il est un peu perdu. Le raccourcis cognitif est un concept propre au cerveau humain, étudié de longue date et très bien connu, et il impose l'adaptation du système à l'humain, et non l'inverse ! Si cette utilisation est à considérer comme une dérive alors qu'elle est "naturelle", c'est que l'outil n'est pas pensé comme il se doit.
Ensuite attention à ne pas dire n'importe quoi. Si cet outil présenté comme véritable vecteur de l'entreprise, affiche des informations sensibles (position, heure, avance/retard...) à un opérateur sécurité, je vois très mal comment la SNCF pourrait se retrancher derrière l'affirmation "l'info n'est qu'informative et n'est pas une référence" en cas d'accident. L'entreprise n'a pas pour réputation de donner des informations fantaisistes à ses adc lorsqu'il s'agit de les employer en conduite. L'esprit doit être le même avec Sirius : vecteur de données estampillées SNCF. Si l'outil affiche quelquechose de non fiable à des opérateurs nécessitant à chaque instant des informations fiables, alors pourquoi les afficher ? Cela ne peut que l'embrouiller voire l'amener à l'accident, d'autant plus si l'ADC est un peu perdu et se réfère à une information donnée par un outil SNCF pour s'en sortir. La part de responsabilité de la SNCF risque d'être sérieusement engagée, et l'ADC aidé de conseillés juridiques aura tout intérêt dans ce cas à pointer du doigt Sirius pour se dégager juridiquement. Donc la SNCF doit prendre les devants : soit on affiche quelquechose d'exact à un opérateur sécurité, soit on ne l'affiche pas, il n'y a pas de demi mesure où l'opérateur devrait se demander si ce qu'il lit est bon ou pas. C'est la porte ouverte à être condamné très sévèrement par un tribunal. D'ailleurs ne s'agit-il pas d'une règle qui prédomine dans tout système embarqué, tel l'affichage de L'IV : autodétection d'anomalie par le système etc ?...
Enfin je trouve particulièrement malhonnête cette stratégie de communication si spécifique à Sirius et qui consiste à dire que "comme par manque de compétence on ne sait pas garantir l'exactitude d'une information affichée, alors on la décrète comme facultative", voire "à prendre avec des pincettes". C'est tenter de se dégager de ses responsabilités tout en prenant les adc pour des imbéciles. La SNCF ne sait pas garantir une information parce qu'elle ne sait pas le faire techniquement, alors elle doit ne pas l'afficher. Point. Et SURTOUT on ne joue pas à l'apprenti programmeur. Il n'y a pas aujourd'hui à penser à une évolution future sur ce genre de sujet tout simplement parce que à l'heure actuelle on ne le maîtrise pas. Un système qui peut afficher librement une information erronnée qui est susceptible d'amener l'adc à agir sur des commandes, est un système défaillant. C'est tout ! Il n'y a pas d'autre nom technique pour définir un tel comportement. Donc Il doit être d'abord isolé, ensuite corrigé, voire dans le cas spécifique de Sirius : surtout repensé à la base... Et surtout soit on le sort immédiatement de la Production soit la fonction défaillante est immédiatement neutralisée. On ne joue pas avec la sécurité ! Donc à ce stade on n'est très loin de parler d'évolution : là on est au niveau zéro du programmeur, celui du "on ne sait pas faire, et on se demande encore comment on peut faire", donc à cent mille lieux du "on veut mieux faire".
Comme la conversation tenue sur le blog ADC le fait très bien ressortir : le mode conduite de Sirius aujourd'hui est de l'ordre du bidouillage informatique là où il aurait fallu dès le début du bon sens et du professionnalisme. Rappelons que nous conduisons de vrais trains ce qui nécessite du matériel professionnel, précis, pensé et réalisé par des experts. Rien à voire avec des trains jouefs dont on estime les heures de passages avec un programme simplement développé en quelques heures en basic. Pardon je suis peut-être sévère, mais récupérer des infos GPS et les exploiter pour se positionner sur un parcours en ayant une base de donnée des points de jalonnement, c'est pas compliqué nombre de copains l'ont programmé très bien sur leur téléphone portable. Leur téléphone leur dit même quand freiner.
Le compliqué n'est pas là ! Le compliqué c'est pouvoir déterminer de manière automatique quand le système déconne (donnée manquante, mauvaise position, défaillance GPS, défailance de l'Operating System, donnée affichable abhrérante) et établir ce qu'il va devoir faire de manière automatisée (pause de la fonction, inhibition de plusieurs fonctions, activation d'une tâche de contrôle supplémentaire sur la prochaine info erronnée, utilisation d'une entrée parallèle, redondance des résultats, voire en dernier recours ne pas hésiter à mettre le sytème en panne automatiquement...)
Le traitement automatisé de l'erreur sur Sirius en mode conduite... Il garanti quoi ? A-t-il été seulement pensé ?
Allez petites questions aux DPX référents : existe-t-il un traitement automatisé de l'erreur sur Sirius en mode conduite ? Que garantit-il ? Quels sont ses prérogatives dans tous les domaines d'erreurs prévus? Comment a-t-on établi l'exhaustivité de ces domaines d'erreurs ? Quelles sont les tolérences connues, possibles du système ? (erreur de distance, temps de validité de l'info, définitions des tâches, ordonnançabilité (telle calcul doit se faire avant tel autre dans un temps déterminé strict et contrôlé par une tâche qui s'exécute en parallèle)...) ? Que se passe-t-il lorsque les limites sont franchies ? Question plus simple : quelles sont les limites en valeurs de résultats établies par le cahier des charges ?
Réponse que je prévoie : "Euh on sait pas" ou bien "Oh ça a été surement pensé tout est ok mais c'est compliqué à détailler" ou bien encore "Bof on s'en fout tant que ça marche" Eh bien Non messieurs-dames ! Parce que sans réponses connues et précises à ces questions, on reste au niveau Sirius mode conduite buggé actuel et son interprétation genre "Vas-y Fangeo t'es à la bourre, accélère jusqu'à la vitesse de référence" (Et là on entend un "bip bip bip" KVB et pouf au tapis...)
Je vois des yeux s'ouvrir en grand face à ce nouvel univers. Rien de spectaculaire à tout ceci, comme l'écrivait Hami45 plus haut ça s'appelle de la gestion de projet et de la programmation de système embarqués. Et pourquoi on ne donne pas ça à gérer au premier chef de projet du coin qui veut prendre du galon ? Parce que c'est très spécifique et que bien réalisé ça évite qu'un opérateur agisse sur une commande après avoir lu une info erronnée sur le pupitre. Et bien réalisé ça marche beaucoup mieux qu'une "JF".
