Certification ferroviaire et évaluation de conformité

La certification ferroviaire est un processus de conformité fondé sur les preuves.

L'objectif d'ingénierie est de démontrer qu'un véhicule ou sous-système satisfait aux exigences techniques, réglementaires et projet applicables à son exploitation prévue.

Cela exige davantage que la collecte de certificats.

Le problème central consiste à maintenir une chaîne cohérente entre :

• règles applicables ;
• exigences projet ;
• solutions de conception ;
• vérification et validation ;
• activités d'évaluation de conformité ;
• preuves finales.

Mes activités récentes de certification ont notamment concerné les projets train hydrogène et Oxygène (AMLD) chez CAF Reichshoffen.

Un projet ferroviaire peut être soumis à plusieurs sources superposées d'exigences techniques.

Elles peuvent inclure :

• les Spécifications techniques d'interopérabilité (STI) ;
• les règles techniques nationales ;
• les normes européennes et nationales applicables ;
• les exigences propres au projet ;
• les exigences de l'exploitant ;
• les interprétations des organismes d'évaluation ;
• les conditions liées aux interfaces ou à l'infrastructure existante.

L'applicabilité doit être déterminée explicitement.

Toutes les clauses ne s'appliquent pas à tous les véhicules, fonctions, sous-systèmes ou scénarios d'exploitation.

Les STI définissent des exigences harmonisées pour l'interopérabilité ferroviaire dans leur domaine d'application.

Le travail de certification peut nécessiter l'analyse simultanée de plusieurs STI.

Exemples issus de mon travail :

• PMR — accessibilité des personnes à mobilité réduite ;
• LOC&PAS — locomotives et matériel roulant voyageurs ;
• CCS — contrôle-commande et signalisation.

Les clauses pertinentes doivent être interprétées dans le contexte de l'architecture réelle du véhicule et de la configuration du projet.

Les exigences européennes ne couvrent pas nécessairement toutes les contraintes techniques nationales.

Les règles techniques nationales françaises peuvent donc rester applicables pour des points ouverts définis, des cas spécifiques, des interfaces historiques ou des exigences nationales.

Leur traitement doit suivre le même processus discipliné que les exigences STI :

1. identifier la règle applicable ;
2. établir son applicabilité au projet ;
3. allouer l'exigence ;
4. identifier les preuves de conformité ;
5. suivre les points ouverts et écarts ;
6. préserver la trace de décision.

Les différents organismes d'évaluation ont des rôles distincts.

Un organisme notifié (NoBo) réalise l'évaluation de conformité vis-à-vis des exigences européennes d'interopérabilité applicables dans son domaine de notification.

Un organisme désigné (DeBo) réalise l'évaluation vis-à-vis des règles techniques nationales applicables.

L'interface d'ingénierie avec ces organismes comprend typiquement :

• clarification de l'applicabilité ;
• échange de preuves ;
• commentaires de revue ;
• clôture des constats ;
• interprétation des exigences ;
• accord sur les méthodes de démonstration acceptables.

Une interface productive nécessite des réponses techniques précises, pas seulement la transmission de documents.

L'exploitant est une autre partie prenante importante.

Pour les projets destinés à une exploitation SNCF, les échanges techniques peuvent porter sur :

• les contraintes opérationnelles ;
• les preuves d'acceptation du véhicule ;
• les exigences d'interface ;
• les clarifications sur la documentation attendue ;
• la clôture des remarques techniques.

Les attentes de l'exploitant et la conformité réglementaire sont liées, mais ne doivent pas être confondues.

Un projet peut satisfaire un ensemble d'obligations tout en conservant des points ouverts dans un autre.

Les preuves peuvent comprendre :

• matrices d'exigences ;
• rapports d'analyse ;
• plans et dessins ;
• calculs ;
• rapports d'essais ;
• procès-verbaux d'inspection ;
• déclarations fournisseurs ;
• certificats ;
• rapports de validation ;
• documents d'interface ;
• documents liés à la sécurité lorsque c'est applicable.

La question essentielle n'est pas de savoir si un document existe.

Il faut déterminer si ce document démontre l'exigence applicable pour la bonne configuration système.

La qualité d'une preuve dépend du contexte.

Un rapport d'essai peut constituer une preuve forte lorsque la configuration testée et le critère d'acceptation correspondent à l'exigence.

Il peut être faible lorsque :

• la configuration diffère ;
• l'essai ne couvre qu'une partie de l'exigence ;
• le critère d'acceptation est implicite ;
• le rapport se réfère à une révision obsolète de l'exigence.

L'ingénierie de certification exige donc une vérification continue de la chaîne de preuves.

Les exigences réglementaires externes doivent être reliées aux exigences projet et aux preuves.

Cette correspondance est souvent gérée dans des outils tels qu'IBM DOORS.

Une correspondance utile enregistre :

• la clause source ;
• l'applicabilité ;
• l'exigence projet ;
• le sous-système responsable ;
• la méthode de vérification ;
• la référence de preuve ;
• l'état ;
• les commentaires ou justifications.

Les correspondances absentes ou ambiguës sont des risques techniques, pas seulement des défauts de base de données.

Les projets de certification manipulent de grands ensembles documentaires ; une automatisation sélective est donc utile.

Des outils Python peuvent aider à :

• extraire les exigences ;
• comparer les révisions ;
• effectuer des contrôles de cohérence ;
• détecter les correspondances manquantes ;
• générer des tableaux de revue ;
• identifier les clauses modifiées ;
• comparer des ensembles d'exigences réglementaires et DOORS ;
• produire des rapports.

L'automatisation est particulièrement utile pour les contrôles mécaniques de cohérence et de complétude.

Les décisions de conformité restent des décisions d'ingénierie.

Le matériel roulant à hydrogène introduit des interfaces système nouvelles ou modifiées par rapport aux trains diesel ou électriques conventionnels.

Du point de vue de la certification, cela peut modifier l'ensemble des questions techniques à tracer entre sous-systèmes et preuves.

L'ingénieur certification doit s'assurer que les exigences applicables restent allouées de manière cohérente malgré la nouvelle architecture énergétique.

Le traitement exact de la sécurité et de la réglementation dépend du périmètre du projet et du corpus de règles applicable ; il ne doit pas être déduit de la seule présence d'un système hydrogène.

Oxygène, précédemment désigné dans le contexte projet par AMLD, est un projet de matériel roulant distinct du train hydrogène.

Pour les activités de certification, les deux projets nécessitent une analyse maîtrisée des exigences applicables, des preuves, des commentaires des organismes d'évaluation et de l'état de configuration.

Garder les identités de projet explicites évite la réutilisation accidentelle de conclusions ou de preuves entre configurations.

Les activités d'évaluation génèrent des commentaires, constats, réserves ou demandes de clarification.

Un processus robuste de clôture doit enregistrer :

• le problème initial ;
• le responsable ;
• la réponse technique ;
• le document ou la preuve modifié ;
• le retour du réviseur ;
• la décision de clôture ;
• l'état final.

Clore un constat signifie résoudre son fondement technique, pas seulement modifier son état dans un workflow.

Les preuves de certification dépendent de la configuration.

La conclusion de conformité doit se rapporter à un état défini du véhicule et des documents.

Les dimensions importantes de configuration comprennent :

• révision matérielle ;
• version logicielle ;
• variante de sous-système ;
• configuration du train ;
• baseline d'exigences ;
• configuration d'essai ;
• révision documentaire.

La réutilisation d'une preuve n'est acceptable que si l'équivalence est justifiée.

La certification repose sur une évaluation indépendante.

Cela modifie la posture d'ingénierie.

Les argumentaires doivent être compréhensibles par des réviseurs qui n'ont pas participé à la décision de conception initiale.

Une bonne preuve est donc :

• traçable ;
• explicite ;
• reproductible ;
• maîtrisée en configuration ;
• techniquement justifiée ;
• suffisamment concise pour être revue.

Une explication qui dépend de connaissances projet non documentées est fragile.

Vérification, validation et certification sont liées mais distinctes.

La vérification demande si le système satisfait aux exigences spécifiées.

La validation demande si le système implémenté convient à son usage prévu.

La certification demande si des preuves suffisantes démontrent la conformité au cadre réglementaire ou d'évaluation applicable.

Le même essai ou la même analyse peut contribuer à plusieurs de ces objectifs, mais son rôle doit rester explicite.

Voir aussi : Vérification, validation et certification.

Un flux pratique de certification peut être résumé ainsi :

1. établir le corpus de règles applicable ;
2. déterminer l'applicabilité des clauses ;
3. intégrer les exigences dans la baseline projet ;
4. allouer les responsabilités ;
5. définir les preuves de conformité attendues ;
6. suivre la production des preuves ;
7. interfacer avec les organismes d'évaluation et l'exploitant ;
8. répondre aux commentaires et constats ;
9. vérifier la cohérence de configuration ;
10. assembler l'argumentaire final de conformité.

Le processus est itératif car les modifications de conception et les commentaires d'évaluation peuvent modifier l'ensemble de preuves.

Les principaux principes que j'applique sont :

• déterminer l'applicabilité avant de collecter les preuves ;
• préserver un chemin traçable de la règle jusqu'à la preuve ;
• distinguer exigences européennes, nationales, exploitant et projet ;
• traiter les commentaires NoBo et DeBo comme des questions techniques, pas comme de simples tâches d'acheminement documentaire ;
• maintenir la gestion de configuration ;
• automatiser les contrôles de cohérence lorsque c'est utile ;
• réserver le jugement humain aux conclusions de conformité ;
• rendre chaque point clos indépendamment révisable.