[SIRIUS] - Sujet officiel

[Yannick du 90]

Je trouve que ça serais sympa sur une tablette.

Il se murmure à radio ballast que le prochain sirius serait une tablette...

Je l'ai utilisé en "réel" pour la première fois en TER et je dois bien avouer que c'est pas mal ! téléchargement JS et FT relativement rapide, pas de souci en ligne hormis une ou deux pertes GPS à des endroits connus et sur 50m pas plus. Le fameux service allégé de fin d'année a connu comme toujours quelques râtés, et il m'a fallu retélécharger en catastrophe deux FT sans souci, une fois le train terminé il m'a demandé s'il fallait les rajouter au BS et s'il fallait modifier une FT existante.

Le BS justement qui me faisait un peu peur se remplit très bien, et avec un peu de pratique c'est plus rapide que la version papier. Seul bémol quand on a des engins en UM (très fréquent en TER) la manip est un peu fastidieuse, il faudrait pouvoir les rentrer tous à partir de la même page.

Question autonomie il m'a tenu le RHR complet sans recharge, avec encore une led verte allumée à la fin.

Yannick

[nissart06]

Il se murmure à radio ballast que le prochain sirius serait une tablette...

Je l'ai utilisé en "réel" pour la première fois en TER et je dois bien avouer que c'est pas mal ! téléchargement JS et FT relativement rapide, pas de souci en ligne hormis une ou deux pertes GPS à des endroits connus et sur 50m pas plus. Le fameux service allégé de fin d'année a connu comme toujours quelques râtés, et il m'a fallu retélécharger en catastrophe deux FT sans souci, une fois le train terminé il m'a demandé s'il fallait les rajouter au BS et s'il fallait modifier une FT existante.

Le BS justement qui me faisait un peu peur se remplit très bien, et avec un peu de pratique c'est plus rapide que la version papier. Seul bémol quand on a des engins en UM (très fréquent en TER) la manip est un peu fastidieuse, il faudrait pouvoir les rentrer tous à partir de la même page.

Question autonomie il m'a tenu le RHR complet sans recharge, avec encore une led verte allumée à la fin.

Yannick

La batterie de secours a une grande autonomie environs 20h celle la batterie du PDA 6h, ca se recharge assez rapidement 30 min 40 % environ en mettant la BA de secours sur le PDA.

[Yannick du 90]

La batterie de secours a une grande autonomie environs 20h celle la batterie du PDA 6h, ca se recharge assez rapidement 30 min 40 % environ en mettant la BA de secours sur le PDA.

Je pars avec les deux batteries chargées à bloc et je les laisse branchées en permanence dès l'instant que le PDA tourne, j'ai remarqué que ça tenait plus longtemps que si on recharge le PDA avec la batterie de secours où là elle se casse la g... rapidement. Compte tenu de l'utilisation que j'en ai faite avec des étapes courtes, des recherches de FT et autres bidouilles de novice, le score de 2 leds vertes pour un RHR est honnête je pense.

[Rigolo]

Il se murmure à radio ballast que le prochain sirius serait une tablette...

Je l'ai utilisé en "réel" pour la première fois en TER et je dois bien avouer que c'est pas mal ! téléchargement JS et FT relativement rapide, pas de souci en ligne hormis une ou deux pertes GPS à des endroits connus et sur 50m pas plus. Le fameux service allégé de fin d'année a connu comme toujours quelques râtés, et il m'a fallu retélécharger en catastrophe deux FT sans souci, une fois le train terminé il m'a demandé s'il fallait les rajouter au BS et s'il fallait modifier une FT existante.

Le BS justement qui me faisait un peu peur se remplit très bien, et avec un peu de pratique c'est plus rapide que la version papier. Seul bémol quand on a des engins en UM (très fréquent en TER) la manip est un peu fastidieuse, il faudrait pouvoir les rentrer tous à partir de la même page.

Question autonomie il m'a tenu le RHR complet sans recharge, avec encore une led verte allumée à la fin.

Yannick

Je te rejoinds à 100% , faut essayer avant de parler , un collègue me l'a prêtait pendant qu'il était en voiture avec moi et le Sirius c'est bien finalement , seul défaut l'autonomie et le BS fastidieux !

Modifié 25 décembre 2010 par Pluto

[CRL COOL]

La batterie de secours a une grande autonomie environs 20h celle la batterie du PDA 6h, ca se recharge assez rapidement 30 min 40 % environ en mettant la BA de secours sur le PDA.

Le taux de charge de la batterie du HTC est assez piégeux: la décharge n'est pas linéaire.... S'il reste environ 25%, çà dure 30 à 40 mn pas plus....

Modifié 25 décembre 2010 par CRL COOL

[ADC01]

Moi,qui pratique principalement les TGV A, je m"emmerderai pas à promenre la batterie de secours , il y aune prise 220 V en cabine et si le fil n'est pas assez long, je ferai une rallonge juste de la bonne longueur et le reste du temps ,je fais du Duplex avec au maximun des étapes de 2 heures alors ..... et puis de toute façon ce "cet appareil qui ne sert à rien" n'est pas encore déployé dans mon UP.

Modifié 26 décembre 2010 par ADC01

[Rigolo]

Moi,qui pratique principalement les TGV A, je m"emmerderai pas à promenre la batterie de secours , il y aune prise 220 V en cabine et si le fil n'est pas assez long, je ferai une rallonge juste de la bonne longueur et le reste du temps ,je fais du Duplex avec au maximun des étapes de 2 heures alors ..... et puis de toute façon ce "cet appareil qui ne sert à rien" n'est pas encore déployé dans mon UP.

Le fil n'est pas assez long, je te le dis dés maintenant mais celui de la batterie de secours est assez long !

[Gezor]

Récupéré sur un autre forum :

GeorgeProfonde Dit: Le 12 décembre 2010 à 1 h 05 min

Bonjour

Ok pour la consultation de la programmation, ok pour le rendu des BS (on le demande depuis longtemps), pas ok pour le mode conduite : voici pourquoi à mes yeux Sirius représente un danger pour les circulations. Il y a plusieurs jours, je roule avec Sirius sur le pupitre. J'ai 4 minutes d'avance sur le compteur avance/retard, conforme au réel. C'est la nuit. Avertissement, j'anticipe mon freinage et descend ma vitesse à 25 km/h, vitesse à laquelle je roule sur trois bon kilomètres avant d'arriver face au carré fermé. Je m';arrête. J'y reste 4 minutes durant lesquelles je reçois un bulletin CBA pour ce signal et un ordre de marche prudente du à la probable présence de voleur de cuivre aux abords des voies.

Je repart donc comme il faut et décide de ne pas rouler au dessus de 10 km/h sur le parcours qui m'a été désigné sur l'ordre de marche prudente. Une fois le parcours terminé je remonte en vitesse. Je consulte l'avance/retard Sirius : à l'heure ! Génial, je décide de respecter la vitesse de référence.

J'arrive aux abord d'un PN, barrière brisées. La totale.

Derrière on est venu me demander pourquoi j'ai roulé à Vref alors que finalement j'avais plus de 10 minutes de retard. On me dit que j'ai de la chance de ne pas avoir percuté une bagnole sur le PN car vu l'heure où des témoins ont vu les barrière être pêtées par un poids lourd, j'aurai déjà dû être passé.

Après une mauvaise nuit suite à cet incident j'ai compris : Sirius met à jour son avance/retard au passage des PR, et UNIQUEMENT au passage des PR, avec un comptage du temps d'arrêt D'où l'affichage à l'heure après 4 minutes d'arrêt alors qu'au préalable j'en avais 4 d'avance. Mais si entre deux PR il y a plusieurs kilomètres, que vous roulez à vitesse très réduite, alors l'info avance/retard est complètement erronée.

Moi j'ai adapté ma conduite en fonction de ce que j'ai lu sur Sirius, ce qui m'a amené à avoir un comportement complètement inadapté par rapport à la réalité terrain. Donc finalement je me pose une question : un logiciel qui m'affiche une info erronée, info qui m'amène à rouler d'une autre manière que j'aurai fais sans, avec un PN barrière brisées derrière, voire des morts. N'y aurait-il pas comme un soucis ?

J'avoue : je ne connais strictement rien à la programmation, aux ordinateurs (à part le PC de mes gamins) etc. Mais je me demande si l'entreprise à qui on soutraite la programmation de Sirius n'aurait pas loupé un petit quelque chose ? (rassurez moi : on ne soutraite pas ça à des gens vivant en Chine ou au Maroc où la main d'oeuvre est bon marché ?).

La programmation d'un logiciel qui a pour finalité de filer des infos à des conducteurs de trains pendant qu'ils conduisent, n'est-elle pas soumise à certaines règles qui en font quelquechose de plus efficace et surtout de sûre qu'une banale calculatrice windows ?

Hami45 Dit: Le 12 décembre 2010 à 9 h 48 min

Ce que tu écris là Georges confirme ce que ma fille m'a expliqué il y a quelques semaines. Elle est ingénieur dans l'aéronautique à Toulouse. D'après elle lorsqu'un système embarqué file des infos au conducteurs qui le font agir sur des commandes, alors ce système doit répondre à un cahier des charges écrit par des gens spécialisés dans un type de projets informatiques appelé "temps réels". Pareil pour ceux qui écrivent les lignes de programmes, ils doivent tout faire en respectant les règles de ce type de programmation.

D'après ce qu'on m'a dit à mi mots en formation, les gens qui programment Sirius bossent dans une entreprise qui a plus l'habitude de réaliser des softs pour des banques que pour cabine de conduite. En plus si je me rappelle bien, au début Sirius était entre autre prévu pour afficher une fiche train, pas pour filer des infos sensibles qui modifient le comportement du conducteurs sur le MPT ou le frein. On m'a aussi affirmé que les gars qui ont écrit le cahier des charge ne connaissent strictement rien aux projets orientés temps réel. Ca fait peur.

Je pense que les syndicats ont un coup à jouer pour faire en sorte que l'on nous garantisse les infos affichées pendant que nous conduisons. Peuvent-ils demander à consulter le cahier des charges et les lignes de programmes ? Peuvent-ils demander les qualifications en matière de softs embarqués de chaque acteur de ce projet ?

Hami450 Dit: Le 12 décembre 2010 à 11 h 15 min

@ Georges : ça s'appelle la gestion de projet en temps réel. C'est extrêmement compliqué et nécessite de longues années d'études pour devenir chef de projet temps réel ou développeur d'applications temps réel. Une application de ce genre coute très cher mais elle garantie à chaque instant une info exacte affichée quand il le faut. Tous les outils embarqués du secteur de l'aéronautique, de l'armée et de la marine sont développés sur ce principe. Sirius non : à la SNCF nous sommes meilleurs que les autres. Un indice : on utilise un PDA du commerce à 500 Euros là où au nom de la sécurité les autres sont contraints de développer un matériel dédié à 20 000 Euros pièce… Tu comprends la subtilité ? Voilà, tu as ta réponse.

Blaise Dit: Le 12 décembre 2010 à 12 h 17 min

Très intéressants ces commentaires. De toute façon, il est certain que le résultat du produit final est directement lié à l'investissement que l'Entreprise fait. Sachant d'avance que l'arrivée de cette nouveauté allait clairement créer des problèmes sur le terrain et que le soft ne serait pas finalisé, l'Entreprise a voulu ne pas trop investir quoi de plus logique me direz-vous ! Le temps que ce produit soit accepté et maîtrisé sur le terrain par les Agents De Conduite, l'Entreprise proposera dans peu de temps un nouveau produit, type Ipad (mais ça m';étonnerait que ce soit quand même un Ipad

Vivement une vraie tablette avec des programmes améliorés !

Zardoz Dit: Le 12 décembre 2010 à 16 h 39 min

Hop je m'inscris pour un petit témoignage. Il y a un mois en plein brouillard un peu perdu (et fatigué) je regarde le FT Sirius qui me dit que je suis entre deux PR. Ok je mets tout dans le coin pour monter à Vref. Et v'la que le KVBèze se met à bipper. Puré je rattrape de justesse. En fait le curseur qui t'indique où tu es sur la FT avait fait un bond en avant sans raison. Va contrôler le bidule lorsque tu te repose sur lui pour savoir où tu es en plein brouillard ! J'en touche deux mots à mon chef, il me dit qu'il existe des pépins avec des points mal localisés par l'infra. Moi je m'en tappe : si me me fais shooter par le kvb ou pire que je monte en vitesse kvb isolé suite à un pépin... Ca fait quoi derrière ? Qui c'est qui va expliquer ça à mes gosses ?

Désormais en conduite, le Sirius il est éteint : avant de nous filer un truc pas fini, ça ferait bien de vérifier les données. Entièrement d'accord avec hami45 : les syndicats doivent nous protéger de ce truc qui aujourd';hui peut nous sortir n'importe quoi en ligne.

Quiriam75 Dit: Le 13 décembre 2010 à 12 h 17 min

En fait au début l'idée était cantonnée à la prog, le rendu BS et l'affichage de la fiche train avec défilement au doigt.Jusque là la boîte sous-traitée par la SNCF savait faire : la gestion de données c'est leur domaine (Au passage : elle est à la fois AMOA et MOE sur ce projet. Oui oui : une même boite qui fait AMOA et MOE sur un projet : bravo ! Pour ceux qui ne le savent pas, cela signifie qu'elle est à la fois juge et partie... Comme si pour faire bâtir votre maison vous donniez la charge de l'ensemble de votre projet à la même boîte : les études, les plans, l'exécution des travaux, l'électricté la plomberie, tout !)

Mais un jour des ADC ont remonté l'idée : pourquoi ne pas faire un défilement automatique de la fiche train étant donné que le PDA sera équipé d'une antenne GPS ? Et comme le projet débutait et qu'il y avait des craintes que les adc le refusent, l'idée a été étudiée en fonction des vagues connaissances de chacun sur le sujet. Donc évidemment comme ce genre de choses donne l'impression d'être à la pointe de la technologie pour les adc, d'être "in", à la mode, la réponse a été "oui !". Réponse donnée sans préciser que cela impliquait une formation, du matériel ou des connaissances spécifiques. Naturellement la boîte sous-traitée par la SNCF et qui a décroché le contrat-pack (AMOA+MOE) au préalable n'a jamais dit "stop ! non : on ne sait pas faire !". Héhé : un contrat avec la SNCF ça ne se lâche pas comme ça surtout lorsque l'on y porte deux casquettes. Donc "Oui oui on sait faire !" sans faire remonter que cela pouvait dépasser leur domaine de compétences.

Ensuite l'idée est venu de dire que chaque utilisateur pouvait faire remonter des idées à l'équipe projet. Pas bête ! Le seul souci c'est que, comme l';explique Hami45 plus haut, certaines de ces idées (comme l'avance/retard) nécessitent, encore une fois, des connaissances et du matériel spécifique. Mais comme on veut être copain avec les adc et leur dire que Sirius vient d'eux tout en n'explosant pas le budjet de 16 millions d'Euros, on ne peut pas se permettre de leur répondre "non désolé mais il faudrait un budjet dix fois supérieur". Quant à la boîte sous-traitée par la SNCF : reconnaitre son incompétence dans le domaine signifierait perdre le contrat, donc "Oui on sait faire !" Evidemment comme elle est à la fois juge et partie sur le projet (AMOA et MOE) pas difficile de faire accepter la chose.

Voilà la petite histoire de l'extrême à peu près qui ressort du mode conduite de Sirius à l'heure actuelle.

[Gezor]

Ces extraits viennent de excellent site Blog Agent De Conduite : SIRIUS sur ADC BLOG

Ma petite contribution la voici : l'équipe Sirius a été mise plusieurs fois au courant des disfonctionnements à conséquences "sécuritaires" possibles du mode conduite, des disfonctionnements à redouter à cause de la méconnaissance de l'équipe concernant la gestion de ce type de projet qui nécessiterait, au moins dans sa partir 'conduite' une structure temps réel et une programmation spécifique.

En 6 mois l'alerte a été lancée à plusieurs niveaux (DSIT, TMS, Adc, DPX, Transilien...) Les décideurs de l'équipe projet ont décidé de dénouer cette crise en jouant la carte du temps et en faisant la sourde oreille tout en contournant le problème comme pointer du doigts la majorité des adc qui n'ont jamais expérimenté le mode conduite de Sirius en situation incidentelle sur le terrain (et dire que même sur VL Sirius peut afficher n'importe quoi à cause de problème de base de donnée, de repérage etc...). Certaines personnes du staff Sirius se sont même permises de tirer sur les ambulances en faisant jouer leurs galons de DPX sur le projet pour faire taire les avertisseurs. Bravo, ça c'est responsable !

Mais toute correspondance laisse des traces. Des traces qui intéresseront probablement la Magistrature en cas d'accident où Sirius pourrait être mis en cause. J'invite les syndicats à prendre contact auprès de leurs branches dans le domaine aéronautique et à leur poser des questions sur "comment gère-t-on un projet informatique qui a pour finalité d'afficher des informations sensibles en temps réels à des opérateurs sécurité", "Quelle type de programmation spécifique celà requiert-il ?" "Quel matériel et pourquoi ?" "Quel Operating System et pourquoi cet Operating System là et certainement pas un autre ? "...

Sauf erreur de ma part nous ne souhaitons pas un joujou de Noël choisi en priorité pour des questions de coûts et qui drague l'adc au nom du "new technologie !" de supermarché. Nous voulons du matos de pro, fiable, parce que nous sommes des pros, et qui plus est des pros de la sécurité. Que ce matériel affiche un DVD en RHR ou permette de jouer à des jeux ou autre, on s'en fiche. La règle numéro une doit être et rester : ce qu'il m'affiche quand je conduits doit TOUJOURS être exact et ne jamais m'induire en erreur. Ceci implique qu'il soit capable de détecter automatiquement les erreurs avant même de les afficher, et donc bloquer leur affichage et pouvoir se remettre en question voire se déclarer automatiquement en panne. (c'est ce qui se fait dans les systèmes embarqués avions). C'est le B-A BA.

Le reste est un plus, mais aucun gadget aussi flatteur soit-il ne doit transgresser cette première règle.

Modifié 26 décembre 2010 par Gezor

[Christophe]

Bonsoir,

2 choses m'interpellent à la lecture de l'extrait du blog:

- un CRL qui pense n'avoir perdu que 4 minutes après avertissement, arrêt+CBA. Cela confirme que l'avance/retard est un gadget.

- un CRL qui se repère sur le terrain avec son sirius. Comment faisait-il au temps du papier ?

Ça dérive déjà sérieusement . . .

[Nipou]

Surtout que je vois pas bien où est le scoop sachant que l'affichage de l'heure est bien annoncé comme étant donné à titre d'information et non de référence absolue.

Faut pas non plus devenir plus royaliste que le roi : avant tu avais des yeux et une montre et d'un coup, tu as besoin de sirius pour connaître l'heure et te repérer dans le brouillard :blink:

[Gom]

Plutôt que de prendre ça comme un défaut de SIRIUS, je vois plutôt un défaut de formation ! Le "détail" d'avance/retard est connu.

Si le logiciel devait donner l'avance/retard en temps réel, on râlerait encore parce que ça pomperait forcément plus sur la batterie (plus de calculs). On peut demander ça comme une évolution future, pourquoi pas.

Gom

[Yannick du 90]

Bonsoir,

2 choses m'interpellent à la lecture de l'extrait du blog:

- un CRL qui pense n'avoir perdu que 4 minutes après avertissement, arrêt+CBA. Cela confirme que l'avance/retard est un gadget.

- un CRL qui se repère sur le terrain avec son sirius. Comment faisait-il au temps du papier ?

Ça dérive déjà sérieusement . . .

Plutôt que de prendre ça comme un défaut de SIRIUS, je vois plutôt un défaut de formation ! Le "détail" d'avance/retard est connu.

Si le logiciel devait donner l'avance/retard en temps réel, on râlerait encore parce que ça pomperait forcément plus sur la batterie (plus de calculs). On peut demander ça comme une évolution future, pourquoi pas.

Gom

+1 !! A partir du moment où l'insiste en JF sur l'histoire du positionnement non temps-réel c'est facile de déduire que certaines infos sont à prendre avec des pincettes. Plus les PR sont espacés plus les infos de sirius sont "tangeantes"...

[asteras]

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".

Modifié 27 décembre 2010 par asteras

[asteras]

+1 !! A partir du moment où l'insiste en JF sur l'histoire du positionnement non temps-réel c'est facile de déduire que certaines infos sont à prendre avec des pincettes. Plus les PR sont espacés plus les infos de sirius sont "tangeantes"...

Pardon, mais la JF est une (in)formation sommaire données en quelques heures et dont nous savons tous qu'il en reste à peine 20% à la sortie. Quelle garantie la SNCF a-t-elle qu'en situation de stress l'information donnée en JF et permettant de mener au doute sera réactivée promptement et mènera l'ADC "à prendre l'info affichée avec des pincettes". Rappelons que l'information erronnée dont nous parlons est estampillée SNCF et que son seul garde fou sera enfouit dans la lointaine mémoire d'une JF. La SNCF pourra se retrancher derrière sa "formation JF" n'importe quel avocat fera tomber l'argument en invoquant le bon sens.

Modifié 27 décembre 2010 par asteras

[meldor]

Plutôt que de prendre ça comme un défaut de SIRIUS, je vois plutôt un défaut de formation ! Le "détail" d'avance/retard est connu.

Si le logiciel devait donner l'avance/retard en temps réel, on râlerait encore parce que ça pomperait forcément plus sur la batterie (plus de calculs). On peut demander ça comme une évolution future, pourquoi pas.

Gom

Oh ! On ne vit pas sur la même planète là ?!

Moi je veux que le bidule quand je le regarde il me file des infos exactes et uniquement des infos exactes ! C'est pas compliqué non ?

S'il peut afficher n'importe quoi quand je roule alors qu'il s'éteigne tout seul ou bien c'est moi qui vais l'éteindre à ma manière : mise en danger de la vie d'autrui tu connais ? Dehors !

C'est quand même pas la lune de la part d'un adc que de demander à son entreprise de lui filer de bonnes infos en roulant non ?! Hein ?

C'est le minimum nous sommes bien d'accord là ?

20 millions d'Euros ! Pour un truc qui t'affiche n'importe quoi quand tu roules, ça ne te parait pas un peu grave ?

Oh t'es adc là ? Hein ? on se comprends ?

Et ton histoire de batterie c'est pas mon soucis : le truc doit me filer les bonnes infos et doit marcher quand j'en ai besoin.

Ok pour que je le recharge, mais c'est tout. Le reste c'est votre problème, pas le mien.

C'est vous les ingénieurs, pas moi ! Alors arrêtez de vous fouttre de notre gueule avec vos explications vaseuses et filez ce projet à des gars qui savent ce qu'ils font.

Modifié 27 décembre 2010 par meldor

[Yannick du 90]

Pardon, mais la JF est une (in)formation sommaire données en quelques heures et dont nous savons tous qu'il en reste à peine 20% à la sortie. Quelle garantie la SNCF a-t-elle qu'en situation de stress l'information donnée en JF et permettant de mener au doute sera réactivée promptement et mènera l'ADC "à prendre l'info affichée avec des pincettes". Rappelons que l'information erronnée dont nous parlons est estampillée SNCF et que son seul garde fou sera enfouit dans la lointaine mémoire d'une JF. La SNCF pourra se retrancher derrière sa "formation JF" n'importe quel avocat fera tomber l'argument en invoquant le bon sens.

Je suis d'accord avec toi sur le fait qu'une information "à prendre avec des pincettes" devrait être supprimée ou rebouclée plusieurs fois pour avoir la fiabilité nécessaire à l'exercice d'une fonction de sécurité. Pour l'instant c'est l'ADC qui boucle avec sirius... Pourtant personne ne s'est insurgé contre la présence des vitesses limites sur une FT alors qu'elles sont justement "à prendre avec des pincettes".

Ce que j'ai retenu en JF sur sirius c'est que ce n'est qu'une fiche train qui déroule toute seule, un accès direct à toutes les FT et un outil pratique pour les BS. Pour le reste je me fie toujours à ma montre, ma connaissance ligne et mes RT. Les 80% restants... Je ne m'en souviens plus !

[Fred]

Le taux de charge de la batterie du HTC est assez piégeux: la décharge n'est pas linéaire.... S'il reste environ 25%, çà dure 30 à 40 mn pas plus....

J'ai entendu dire que passé 50 % il fallait considérer une conso (moyenne) de 1 % à la minute soit.... 50 minutes

[fby]

Au sujet des fiches trains ou les vitesses ne sont pas correcte , il est écrit en bas que seule les RT sont la référence et d'un coup avec siruis ce n'est plus le cas ?

En terme d'horaire la montre du CRL est la référence .

en terme de positionnement sur le terrain les PK et surtout la connaissance ligne est la référence .

Le premier souci de sirius est que cela change grandement le comportement des ADC et cela l'entreprise ne la pas pris en compte (retour au KVB soit disant transparent ) .

Donc outre la formation au fonctionnement de l'outil , il faut aussi faire un formation sur le comportement de l'ADC en mode conduite .

Mais comme d'habitude la formation et la sécurité a un cout que l'on veut minimiser .

Il a fallut batailler et l expertise la confirmé ,pour obtenir une JFC sirius alors que l'entreprise ne voulait consacrer que environ 2h30 dans une JFC .

II faudrait arriver a obtenir une formation en ligne , comme pour un EM .

Modifié 27 décembre 2010 par fby

[Christophe]

[...]

Ce que j'ai retenu en JF sur sirius c'est que ce n'est qu'une fiche train qui déroule toute seule, un accès direct à toutes les FT et un outil pratique pour les BS. Pour le reste je me fie toujours à ma montre, ma connaissance ligne et mes RT. Les 80% restants... Je ne m'en souviens plus !

Exact, sirius n'est qu'une pauvre[sic] fiche-train bahamas passée d'un support papier à un support électronique.

Et, par exemple, l'avance/retard se calcule à partir des points remarquables comme avec une FT papier, les vitesses limites sont toujours données sous réserve...

Le message d'Asteras est intéressant et argumenté.

Effectivement tout être humain a tendance à se reposer sur les outils qui lui sont fournis. Ça me rappelle l'histoire des valeurs de shuntage lors des formations 67400:

" - pas besoin de connaitre les valeurs puisque c'est automatique

-le jour où ta loc ne shunte pas comment détecteras-tu le défaut ?

-euh . . . "

Dans les cas cités dans le blog, il y a clairement eu un défaut de formation.

Pour ce qui est du cahier des charges et de la programmation du zinzin . . .

[icar13]

Exact, sirius n'est qu'une pauvre[sic] fiche-train bahamas passée d'un support papier à un support électronique.

Et, par exemple, l'avance/retard se calcule à partir des points remarquables comme avec une FT papier, les vitesses limites sont toujours données sous réserve...

Le message d'Asteras est intéressant et argumenté.

Effectivement tout être humain a tendance à se reposer sur les outils qui lui sont fournis. Ça me rappelle l'histoire des valeurs de shuntage lors des formations 67400:

" - pas besoin de connaitre les valeurs puisque c'est automatique

-le jour où ta loc ne shunte pas comment détecteras-tu le défaut ?

-euh . . . "

Dans les cas cités dans le blog, il y a clairement eu un défaut de formation.

Pour ce qui est du cahier des charges et de la programmation du zinzin . . .

Pas vraiment d'accord avec ton affirmation que Sirius n'est qu'une fiche-train Bahamas passé d'un support papier au support électronique.

Ce serait exact si les infos affichées se cantonnaient à ce qu'il y a sur une FT Bahamas. Mais on a voulu commencer à automatiser (remplacer l'intelligence humaine par celle informatique) en estimant la position du train entre des jalons, là où avant l'ADC le faisait de lui même avec un raisonnment comparatif par rapport au terrain. A ce stade ce n'est plus pareil : on apporte une information de positionnement à l'ADC, information en effet signée SNCF. Celle-ci se doit donc être parfaitement exacte.

Ensuite d'après ce que j'ai compris, on a voulu faire défiler automatiquement la fiche train pour remplacer le travail de recherche de l'oeil du cerveau humain. Encore une fois en faisant celà on fournie à l'ADC une information qu'avant il cherchait lui même. Rappellons que le travail de recherche de position sur le terrain amène aussi l'ADC à apprendre de ses erreurs, un processus désormais shunté par l'automatisation.

Donc nous serions parfaitement GAME (Globablement au moins équivalant àl l'existant) si toute cette automatisation n'existait pas. Mais à partir du moment où on l'apporte comme un plus (GAME plus) alors il faut qu'elle ne dénature pas la fiabilité des infos telles qu'elles auraient été à la base sans cette automatisation. Or les multiples erreurs dûes à la base de donnée, aux calculs employés, aux limites du système montrent au contraire que cette automatisation dénature nettement la fonction première de fiche-train vu que dans certains cas elle est susceptible d'afficher des erreurs.

On passe d'un désir de "GAME plus", à un "GAME moins-moins" dans les faits.

Enfin je passe sur la fonction avance/retard. C'est le summum car elle est présentée à l'écran ainsi "avance/retard xxx min". Quelle que soit la formation mise en place en amont (JF), en cas de stress sur le terrain, de fatigue ou autre, l'information peut parfaitement être perçue telle qu'elle est simplement écrite à l'écran : "tu es en avance/retard de xxx min". La oui c'est dangereux parce que comme cela a été démontré ci-dessus cette information présentée ainsi est fausse (elle n'est vrai qu'au moment du franchissement des jalons) et qu'elle est présentée comme étant toujours vrai... Et peut parfaitement être perçue ainsi en situation incidentelle. Le problème est qu'elle a des répercussions sur la conduite du train. Là on ne joue plus !

Je pense qu'au nom du technologiquement innovant on a voulu bien faire au départ, et qu'après l'équipe projet a commencé a dériver sur un terrain qu'elle ne maîtrisait pas. Ceci a abouti à un produit qui en mode conduite est "GAME moins-moins" parce qu'ils n'est pas fiable à cause de tous les ajouts (gadgets informatiques GPS) qu'on a voulu apporter à ce qui devait être au départ une simple FT Bahamas porté sur un écran, défilé au doigt, sans positionnement automatisé.

Je rejoins ce qui a été écris plus haut : lorsqu'on ne sait pas faire, il faut avoir l'honnêteté de le dire quels que soient les enjeux économiques. Et il est clair que tous les ajouts GPS développés pour le mode conduite ne sont pas maîtrisés par les développeurs ni par l'équipe projet. Maintenant le projet est trop engagé pour être stoppé (il devait aboutir coûte que coûte n'est-ce pas ?), mais il suffirait uniquement de neutraliser les fonctions GPS non maîtrisées de l'outils pour le rendre plus professionnel. Certe cela serait perçu comme un pas en arrière par l'équipe projet, et elle préfèrera donc prendre le risque de l'affichage d'une information incorrecte ou mal perçue... Un coup de poker en somme, ce qui est irresponsable.

A quand une v2 partant sur de bonnes bases (de compétences et humaines ) ?

Modifié 27 décembre 2010 par icar13

[icar13]

Exact, sirius n'est qu'une pauvre[sic] fiche-train bahamas passée d'un support papier à un support électronique.

Et, par exemple, l'avance/retard se calcule à partir des points remarquables comme avec une FT papier, les vitesses limites sont toujours données sous réserve...

Le message d'Asteras est intéressant et argumenté.

Effectivement tout être humain a tendance à se reposer sur les outils qui lui sont fournis. Ça me rappelle l'histoire des valeurs de shuntage lors des formations 67400:

" - pas besoin de connaitre les valeurs puisque c'est automatique

-le jour où ta loc ne shunte pas comment détecteras-tu le défaut ?

-euh . . . "

Dans les cas cités dans le blog, il y a clairement eu un défaut de formation.

Pour ce qui est du cahier des charges et de la programmation du zinzin . . .

Concernant les cas cités dans le blog, la formation n'est peut-être pas en cause.

16 000 adc... une formation de 8h en une fois... Pas étonnant que quelques centaines de personnes en situation de stress finissent pas utiliser Sirius de cette manière. Et ce n'est pas forcément leur faute ni celle de la formation : lorsque tu regarde ton Sirius tu vois un trait sur la FT entre deux jalons. Tu es un peu fatigué, stressé pas étonnant que malgré toutes les formations qu'on te donnera au cours de l'unique JF tu auras tendance à l'interpréter comme signifiant "tu es là". Idem pour l'avance retard.

Le soucis vient donc surtout de l'ergonomie : si on ne veut pas que l'adc comprenne le trait rouge comme signifiant "tu es là" alors on le présente autrement que comme un trait pouvant signifer pour l'adc moyen "tu es là". Pareil pour l'avance retard : si tu ne veux pas que l'adc moyen le comprenne comme "à l'heure actuelle tu es en avance/retard de xxx min" alors tu n'écris pas sur un écran "avance/retard xxx min".

J'ai bien peur que la JF devienne un merveilleux outil de déresponsabilisation de l'équipe projet : "on vous a filé une JF pour vous expliquer pourquoi quand on affiche A celà signifie Z, maintenant si vous n'en n'avez retenu que la moitié ce n'est pas notre faute, on a fait notre travail". Non messieurs. Le travail commence déja par afficher des infos exactes aux adc et à les afficher de manière claire sans la moindre possibilité d'ambiguïté. La JF ne doit rester qu'un accompagnement pas un immense mea-culpa de l'équipe projet signifiant : "Parce qu'on n'a pas su mieux faire, quand tu liras A celà signifiera parfois A et parfois Z. A toi d'avoir l'esprit suffisemment lucide quand tu liras l'info pour te rappeler comment l'interpréter correctement."

Modifié 27 décembre 2010 par icar13

[ADC01]

Oh ! On ne vit pas sur la même planète là ?!

Moi je veux que le bidule quand je le regarde il me file des infos exactes et uniquement des infos exactes ! C'est pas compliqué non ?

S'il peut afficher n'importe quoi quand je roule alors qu'il s'éteigne tout seul ou bien c'est moi qui vais l'éteindre à ma manière : mise en danger de la vie d'autrui tu connais ? Dehors !

C'est quand même pas la lune de la part d'un adc que de demander à son entreprise de lui filer de bonnes infos en roulant non ?! Hein ?

C'est le minimum nous sommes bien d'accord là ?

20 millions d'Euros ! Pour un truc qui t'affiche n'importe quoi quand tu roules, ça ne te parait pas un peu grave ?

Oh t'es adc là ? Hein ? on se comprends ?

Et ton histoire de batterie c'est pas mon soucis : le truc doit me filer les bonnes infos et doit marcher quand j'en ai besoin.

Ok pour que je le recharge, mais c'est tout. Le reste c'est votre problème, pas le mien.

C'est vous les ingénieurs, pas moi ! Alors arrêtez de vous fouttre de notre gueule avec vos explications vaseuses et filez ce projet à des gars qui savent ce qu'ils font.

Tout est dit et je suis completement d'accord avec toi.Je sais qu'il faut vivre avec son temps mais là avec cet outil, on se fout des ADC.

Modifié 27 décembre 2010 par nicopasta
Correction de balises

[Gom]

Bonsoir,

[...]

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 ?...

Prenons la même logique : l'IV de secours du 75000 n'est pas considéré comme fiable (étalonnage, etc). Pourquoi l'afficher ? Ben simplement parce que même s'il n'est pas précis, il s'agit d'une indication qui peut aider. Tout comme l'avance/retard, à partir du moment où on connait son fonctionnement : mise à jour uniquement au niveau des jalons.

Gom

[Gom]

Oh ! On ne vit pas sur la même planète là ?!

Moi je veux que le bidule quand je le regarde il me file des infos exactes et uniquement des infos exactes ! C'est pas compliqué non ?

S'il peut afficher n'importe quoi quand je roule alors qu'il s'éteigne tout seul ou bien c'est moi qui vais l'éteindre à ma manière : mise en danger de la vie d'autrui tu connais ? Dehors !

C'est quand même pas la lune de la part d'un adc que de demander à son entreprise de lui filer de bonnes infos en roulant non ?! Hein ?

C'est le minimum nous sommes bien d'accord là ?

20 millions d'Euros ! Pour un truc qui t'affiche n'importe quoi quand tu roules, ça ne te parait pas un peu grave ?

Oh t'es adc là ? Hein ? on se comprends ?

Et ton histoire de batterie c'est pas mon soucis : le truc doit me filer les bonnes infos et doit marcher quand j'en ai besoin.

Ok pour que je le recharge, mais c'est tout. Le reste c'est votre problème, pas le mien.

C'est vous les ingénieurs, pas moi ! Alors arrêtez de vous fouttre de notre gueule avec vos explications vaseuses et filez ce projet à des gars qui savent ce qu'ils font.

Mouais... Reviens me répondre quand tu seras moins énervé/parano. Merci.

Je vais finir par passer pour un pro SIRIUS après ça...

Gom