
Cirrus
Membre-
Compteur de contenus
23 -
Inscription
-
Dernière visite
Tout ce qui a été posté par Cirrus
-
Oui mais si un pâtachon qui roule en MI et arrive avec 1h de retard, ce n'est pas percu de la même manière que si c'est un TGV . Tout va être estampillé Europe dans pas longtemps, et déja je ne suis pas certain que les méthodes de validation des acquis chez un ADC de ECR ou Véolia soient les même que celles à la SNCF. Toute la question est de savoir si l'Europe va tirer la qualité vers le haut ou vers le bas.
-
Oui et non. Me concernant je suis persuadé qu'ils vont penser que je suis ce fameux XYP. Concernant certains participants le forum sert de thermomètre. Concernant les idées qui sont écrites elles sont lues, et quand elles sont "jugées" bonnes elles font l'objet d'une fiche inovation. Mais j'ai le regret de vous dire que c'est rare : et ce n'est pas une question de qualité des idées soutenues ici pourtant. Mais rien de nouveau dans celà : il s'agit d'évidences. Laisse moi deviner ? Pour tenter d'obtenir un indice pour savoir si je serai XYP ? Il vous obsède à ce point ce type ? On se croirait en Sarkoland là (remarque nous y sommes jusqu'à demain).
-
Bah voilà... Sirius est un projet national ne l'oublie pas. Lorsqu'il sera dédié par activité les procédures Sirius devront peut-être être réécrites pour distinguer celles d'une activité par rapport à celles d'une autre. Parfaitement d'accord avec toi. Fret.
-
Si la majorité des gens ne jouent pas au loto, ce n'est pas parce qu'ils ont peur de gagner... Plus sérieusement tu viens presque de défendre Sirius (lorsqu'il est éteint) !
-
Non c'est qu'elle est stupide : si je vous dis que je ne suis pas ce XYP, vous ne me croirez pas ; et si je m'amuse à vous dire que je suis lui alors vous allez causer de son bidule sur la page Sirius.
-
Un avis à prendre en compte en effet. Et pourtant nous sommes lus par l'équipe projet, je te le promets. Sur tes XMI et ton HLP tu devais effectuer combien d'arrêts en t'efforçant de respecter l'horaire ?
-
Nous sommes bien d'accord là dessus : il vaut mieux une bonne FT papier d'une machine bancale, toi tu diras qu'une machine tout court. Bref aujourd'hui la FT papier est meilleure que Sirius. Encore lui ?
-
Oui tu as parfaitement raison : on s'adapte en créant nous même un mode dégradé "personnel" qui doit palier aux défauts du mode dégradé prévu qui fait pourtant "force de loi". Et si tu appliques ce mode dégradé personnel et qu'il t'arrive un pépin grave on saura venir te le repprocher.
-
Euh je ne sais pas si c'est un compliment ou une insulte de me comparer à lui. En tous cas sur Google en tapant le nom que tu écris je tombe sur une page qui explique une procédure de cession de droits de la SNCF à votre ami... Ca ne semble pas vraiment indiquer qu'il veuille nous le filer. De toutes façons on s'en fout, SNCF c'est Sirius non ?
-
Faire avancer Sirius, mais en traitant de points peu abordés auparavant et récolter la perception des ADC sur ces points.
-
Ah non je ne suis pas enervé, au contraire : quand je parle ou j'écris à propos de Sirius cela me détend. Un projet quel qu'il soit à autant sinon plus de bénéfice à retirer des critiques lorsqu'elles sont faites de bonne foi, que des éloges.
-
Merci pour ta réponse. T'as-t-on avisé depuis des anomalies même mineures détectées par tes collègues et des corrections effectuées ? Autre points : dirais-tu que Sirius est plus/moins fiable qu'une FT papier. Si ta réponse est plus fiable alors peux-tu me dire en quoi ta FT papier l'est moins ? Et si ta réponse est que Sirius est moins fiable, pourquoi gardes-tu alors sur le pupitre Sirius, faillible à tes yeux, alors que ta FT l'est moins ? Ok concernant les RT (qui vont arriver sur Sirius prochainement n'est-ce pas ?) Ceci dit, N'y a-t-il aucune info sécurité présente sur une FT (Arrêts... horaires...) ? S'il n'y en a ne serait-ce qu'une seule, celà ne fait-il pas de la FT un document sécurité ?
-
Pas forcément si tu as préparé au préalable ta mission et que tu as constaté que les vitesses indiquées sur ta FT étaient exactes
-
Il y a une différence entre savoir que ton appareil va t'afficher quelquechose d'incohérent par rapport au réel parce que tu as été prévenu par le régulateur d'une modification de trajet, et un appareil qui t'indique une info erronée susceptible de ne pas être détectée parce que tu ne t'y attend pas. il y a une différence entre ne pas se souvenir de la présence d'un chantier, et avoir un appareil validé par ton employeur qui te donne une info chantier erronnée.
-
Sirius est validé par la SNCF et l'EPSF autant que ton IV, tes manos etc... Non ? Si tu n'as pas confiance envers ce qu'il affiche alors pourquoi l'avoir sur le pupitre à la place de ta FT papier ? Tu m'intéresses sur un autre point : comment t'as t'on expliqué en formation que Sirius n'était pas infaillible tout en t'expliquant qu'il a été validé par l'EPSF et qu'il est devenu un document sécurité (au même titre qu'une FT même si les vitesses y sont inexactes) ?
-
Rigoles, tu as raison... J'espère plus que tout avoir tort, j'accepte de passer pour un idiot aux yeux de tout le monde... Et ce que j'espère plus que tout c'est que l'avenir ne démontrera jamais que j'ai pu avoir raison.
-
Non, qu'il est humain et que la machine doit se plier à ses exigences et le servir, pas l'inverse.
-
Ta question démontre tout simplement que personne ne t'a jamais avisé de ce genre de particularités. As-tu entendu des collègues équipés Sirius dire que l'équipe projet les tenait au courant régulièrement des incompatibilité Sirius par rapport au terrain ? En parle-t-on en formation ? Fait-on régulièrement aux ADC équipés un état des lieu exhaustifs de ce genre de particularité ? On touche à la sécurité pourtant, et même s'il n'existe qu'un seul et unique cas en France (il y en a plus d'un) il faudrait au minimum les répertorier et en aviser tous les utilisateurs (même ceux qui ne circulent pas à cet endroit, au cas où ils découvriraient à leur tour des incompatibilités non répertoriées). Ce qui est choquant n'est pas que ce genre de particularités existe sur la voie, le problème est en amont : il s'agit de constater que ce genre de particularité n'a pas été jugé suffisement inquiétant au moment où il a été décidé d'inclure une fonction GPS à Sirius. Lorsqu'on ne sait pas ce qu'il s'est réellement dit, on peut alors appeler celà celà de l'incompétence... On pourrait aussi appeler cela un choix en fonction du rapport risques/coûts : on le savait mais vu le prix estimé pour développer un soft qui couvrirait tous les cas possibles, coût de développement à comparer aux coût des conséquences multipliés par les probabilités d'accidents découlant de telles particularités terrains, et au nombre de cas existant sur le terrain... Si tu dois doubler le prix du soft rien que pour couvrir un cas particulier que tu estimes probable à 1 ou 2 cas en France... A un moment il faut choisir, et tu choisis vite surtout lorsque tu as un budget serré... Et si un accident arrive cinq ans plus tard eh bien c'est pas de bol voilà tout... Mais ça n'arrivera pas évidemment ! (Et là tu croises très fort les doigts et tu te convaincs que ça n'arriveras pas parce que si tu ne te convaincs pas suffisement tu fais exploser ton budget... Allez on met un troisième doigts sur les deux premiers pour se convaincre encore plus... C'est suffisant, tu as bonne conscience maintenant). Mais qui sait s'il s'agit là d'incompétence ou d'un choix calculé ? En aval, l'autre élément dérangeant est que l'on est encore au stade où on craint que la liste des incompatibilités Sirius par rapport au terrain ne s'allonge (mais officiellement on a fait le tour, évidemment)... Et qu'on essai de ne pas trop ébruiter la chose auprès des ADC à qui on veut vendre l'outil comme THE SOLUTION ! (oups : non pas le mot "vendre", surtout pas le mot "vendre"... Et puis non ce n'est pas THE SOLUTIONS : c'est un outil pensé par eux fait pour et par eux hein !...)
-
Rapidement, un simple exemple : celui de la boucle. Le train part de A, il passe sur la "croix" de la boucle par exemple sur un pont alors que la gare B (ou tout autre type de point de jalonnement) doit être desservie en bas après avoir effectué l'intégralité de la boucle. Sirius ne gère pas les comparaisons de caps, s'il détecte que le train passe sur le croisement en haut (c'est à dire à moins de 100m à vol d'oiseau de la gare qu'il doit desservir en bas), il basculera sur le prochain point de jalonnement alors que le train doit encore effectuer l'intégralité de la boucle avant d'arriver à quai. Je vous laisse imaginer le doute qui s'installera dans l'esprit de l'ADC si dans la boucle entre A et B il y a un chantier que l'ADC aura précautionneusement indiqué sur la FT Sirius en créant un mémo, et que finalement ce mémo sera affiché comme franchi alors qu'il ne le sera pas... Ce n'est qu'un très simple exemple. Vous pouvez en imaginer très facilement de nombreux par vous même si vous prenez en compte le fait que le basculement sur le prochain point de jalonnement se fait lorsque la distance train-jalon est à vol d'oiseau inférieure à 100m, que Sirius ne gère pas les comparaisons de cap....Ajoutez là dessus un ou deux chantiers avec des taux différents et vous arriverez avec un ADC qui dans certains cas suivra ce qui Sirius lui indiquera et roulera de bonne foi à une vitesse alors qu'il doit rouler à une autre... Imaginez que le KVB soit tombé en panne en amont... Autre exemple : la coupure de perception GPS. Lorsque Sirius recapte le signal GPS il tente de se repositionner sur la FT. Or si par exemple après un tunnel, ou un simple problème de captage, l'endroit où il recapte le signal est plus proche par exemple d'une gare desservie sur la FT mais qui n'est pas la prochaine sur la voie, alors Sirius fera un bond jusqu'à cette gare en supputant qu'il s'agit de la prochaine. Imaginez des VL différentes, un ou deux chantiers... Pour peu qu'à cet endroit la ligne ne soit pas équipée KVB ou que le KVB soit tombé en panne quelques kilomètres en amont... La faute sera porté au "crédit" de l'ADC surtout s'il n'est plus là pour pointer du doigt Sirius. On rétorquera à celà qu'il y a moyen d'utiliser la fonction de recalage... Ok mais encore faut-il que l'ADC y pense. Est-ce son travail de constament comparer Sirius par rapport au terrain et d'imaginer qu'à chaque instant Sirius puisse lui afficher une information inexacte ? Sirius est estampillé SNCF, validé par l'EPSF, l'ADC n'a donc aucune raison de douter de ce qu'affiche Sirius... Pourtant tous les ADC équipés à ce jour sont des testeurs en puissance à qui on demande de remonter toute anomalie constatée... Ont-ils une prime de conducteur d'essai ? De plus le recalage est une action paliative qui ne devrait être utilisée que lorsque l'outil boggue, et non pas lorsqu'il fonctionne normalement et que l'ADC finit par l'utiliser pour palier au manque d'anticipation de l'équipe projet. Aujourd'hui cette fonction de recalage sert principalement à l'ADC dans ce type de cas alors que cette même utilisation dans ce contexte démontre que Sirius n'est pas GAME à l'existant. A ceci on vous rétorquera que le coût de mise en oeuvre de ces évolutions est extrêment élevé (c'est probablement exact) comparé aux probabilités d'un accident dans de tels cas multiplié par le coût financier d'un tel accident (en mathématique on appelle celà une variable aléatoire, celà permet d'estimer le bénéfice divisé par le coût de la mise en oeuvre d'une solution par rapport au coût d'un accident multiplié par sa probabilité si on ne la met pas cette solution en oeuvre). Maintenant réfléchissez en conducteurs professionnels de la sécurité que vous êtes : est-ce normal qu'on vous donne un outil qui ne gère pas de manière exhaustive le fait que les voies tournent et se croisent ? Est-ce normal que l'on vous donne un outil dont les soucis sécurité peuvent venir non pas de boggues, mais de choix relatifs à des problèmes de coûts ? Est-ce normal que le mode nominal papier soit plus fiable en cabine que l'évolution proposée ?
-
Sirius a de bon qu'il a permis dans sa version 1 de mettre en place la partie serveurs, les tuyaux entre les bases de données, un début de réponse au besoin d'une hotline, un petite base de travail sur le mode dégradé, une équipe de test, une stratégie de déploiement (logistique, formations...), d'appréhender les echanges avec les partenaire sociaux (à retravailler pour les inclure dans le projet au lieu de se casser les dents dans une logique de conflit), une ébauche de petit programme sur PDA (dit "Portail Conducteur") et sa partie encadrante ("Portail Sirius"), d'appréhender tous les tests de charge et les problèmes généraux de fonctionnement etc... Désormais il serait bon que Sirius ait véritablement l'esprit Nouvelle Génération et prenne les ADC pour des professionnels de la sécurité conducteurs de trains et non pas pour de vagues chauffeurs de voitures lowcost genre ADIAT avec leurs compétences et matériels plus qu'aléatoires (...) On s'adresse à 18000+ professionnels de la sécurité donc on leur donne un outil carré, pro. (hardware dédié, software refondu, équipe projet professionnelle DSIT / TMS / Activités etc...) Sinon on restera dans un esprit commercial paranoïaque ou la v2 NG sera un Sirius v1 remanié pour donner un style "new high tech " pour mieux le vendre.
-
Autres points à solutionner qui permettraient de prétendre à sortir une v2 (dit Nouvelle Génération) digne de ce nom : - Il est intolérable que le mode nominal d'alimentation de l'outil soit une batterie. Celà impose à l'ADC d'effectuer des opérations complémentaires qui sont en inadéquation avec la volonté de faire un outil GAME (Globalement Au Moins Equivalant) à l'existant (aujourd'hui SIRIUS fait du GAME quand il le peut et quand celà permet d'etre utilisé comme argument de "vente", et lorsqu'il ne le peut pas il trouve comme solution intermédiaire de demander à l'ADC d'adapter son comportement) ; - Il est intolérable que le mode hors GPS soit non GAME à l'existant car nécessitant une action de la part l'ADC (défilement au doigt nécessaire fréquemment, validation à chaque arrêt, là où jusqu'à ce jour l'ADC n'avait qu'à baisser les yeux sur la FT voire tourner la page rarement ; - Il est intolérable que le mode dégradé conduite fasse appel à des tierces personnes pour la remise des FT : dans certains cas connus l'ADC n'obtiendra jamais de FT et devra palier au mode dégradé inadapté à ces cas en demandant par radio certains détails de la FT ; - Comme lu sur un autre forum, il est intolérable que certaines fonctions aient été implémentées sans en maitriser la technologie ; - Les formations des ADC sont sur plus de 4h. C'est trop long, de plus celà nuit toute maitrise de la stratégie de déploiement ; - Le temps écoulé entre l'écriture du cahier des charges de l'outil et la fin du déploiement (dernier ADC équipé) est trop long. Certes certains délais légaux sont incompressibles mais ce lapse de temps doit au grand maximum etre de 1 an et demi ; - Eviter de donner le nom Nouvelle Génération à un outil simplement parce qu'on change l'appareil, qu'on y adapte le programme en termes d'ergonomie et d'esthétique et qu'on solutionne des problèmes qui n'auraient jamais eu lieu d'être ; Une NG consiste à utiliser des solutions techniques dernier cri pour refondre en profondeur la perception même du projet (ce qui amène souvent à changer les équipes, le backoffice, une réécriture totale du code etc...) à suivre...
-
Mes interventions sur ce forum ne découlent que de mon point de vue, de ma simple opinion personnelle. Ainsi, à mon avis le gros problème de Sirius vient de quatre points : 1) Il est piloté par la Traction alors qu'il devrait l'être par une équipe constituée de TMS et des activités. Pour des utilisations spécifiques aujourd'hui celà donne un outil "national" très lourd avec des fonctions totalement inutiles voire d'autres qui dans certains cas (rares certes) peuvent mener en conduite à une inappropriation du comportement de l'ADC en fonction de la situation terrain. 2) anticipation du long terme = 0 ! Au début, l'équipe projet avec une conception de SIrius qui n'est absolument pas ce qu'il est devenu. Au tout début il était nul question d'utiliser un GPS, le défilement se faisait au doigt et tout allait bien, ce que le HTC pouvait très bien faire. Mais le jour où l'idée du GPS a commencé à fleurir dans l'esprit de l'équipe projet SNCF celle-ci a refusé de se poser les bonnes questions sur la faisabilité, les compétences nécessaires, les possibilités techniques. Ca a donné une suite de bugs liés à l'incompétence de la MOE(CSC) et de l'AMOA(CSC) sur le sujet, avec une MOA(SNCF) appuyée par l'AMOA (CSC) qui n'hésitait pas à fuir les problèmes futurs et répondre "on verra lorsque le problème se présentera". Or l'AMOA (CSC) et la MOE (CSC) ne pouvai(ent...) ignorer que cela allait mener à une cascades d'évolutions "correctives" qui, par rapport aux corrections de bugs, ont de bons si l'on se met à la place de CSC qu'elles sont payées par la SNCF (alors que la correction d'un bug est financé par le prestataire CSC...) Par manque d'anticipation, le code Sirius a fait l'objet d'une cascade de "rustines évolutives", qui a entraîné une perte massive de temps et d'argent pour la SNCF. Je n'en citerai qu'un thème qui a eu des conséquences majeures et qui continuera d'en avoir vu son approche actuelle sur Sirius : sur le terrain les voies ne sont pas posées en ligne droite ! Cela vous fera probablement rire, mais nombre de soucis actuels de Sirius en mode conduite sont liés à cette particularité, et au fait qu'à l'origine l'équipe projet n'ait pas su accepter qu'il fallait intégrer cette particularité dans la perception même de ce qu'était un logiciel embarqué destiné à des conducteurs de trains. 3) Les relations internes à l'équipe Sirius sont une chimère schyzophène. CSC a la main mise sur le projet depuis le début. S'il est exact que la MOA SNCF a le mot final sur tout ce qui est réalisé, les solutions proposés par CSC sur beaucoup de demandes d'évolution sont conçues de manière à asseoir leur présence future sur le projet. Je reviens sur la classification BUG/Evolution qui mène trop souvent CSC à proposer des solutions "fermées" qui peuvent mener à des situations inappropriées au terrain (perçues comme des bugs par les ADC) qui nécessiteront d'autres évolutions payantes (et non des corrections gratuites) pour résoudre le problème. Si la MOE et l'AMOA étaient confiées à la DSIT nous n'aurions pas ce genre de problèmes et nous ferions des économies en temps et en argent. 4) Le volet stratégie de communication du projet est lui aussi schizophrène : à la fois "commercial" et paranoïaque. Lorsqu'on entre dans l'équipe projet on entre dans une bulle où tout ce qui doit sortir est pesé pour aller dans un sens positif. Même si l'on s'y en défend, il ne reste pas moins que l'on "doit réussir" à "vendre" Sirius. Donc la communications sur les boggues est très limitée (et toujours très positive lorsqu'elle a lieu) auprès des utilisateurs finaux alors qu'elle devrait être quotidienne dans un esprit de sécurité. Aujourd'hui Sirius est "vendu" comme THE SOLUTION ! Sirius est ce qu'il vous faut, il est beau (voir les protos de la v2 qui au delà de quelques solutions techniques ont surtout un objectif commercial esthétique - rien n'est prévu être refondu en profondeur dans le code), tous les problèmes sont maîtrisés ou en voie de l'être ! Cela va jusqu'à une autosatifaction de l'équipe projet qui bride toute analyse et remise en question des fondements même du concept Sirius. Enifn même s'il est exact que l'équipe Sirius contient nombre d'ADC très compétents, d'exception, l'esprit global vis-à-vis de la "masse" des utilisateurs finaux ADC est une crainte, une méfiance malsaine. Conclusion : le souci majeur de SIrius est l'esprit dans lequel il est conçu : Une AMOA/MOE privée qui pense à l'argent, une MOA un peu molle qui craint de lui tenir tête, une perception commerciale et craintive des utilisateurs finaux et de leurs syndicats. La solution serait MOA : TMS/Activités ; AMOA/MOE : DSIT ; communication ouverte auprès des ADC et pas forcément dans l'esprit de "vente" d'un produit "miracle".