Application ferroviaire et COTS

1. Application ferroviaire et COTS Boulanger Jean-Louis jean-louis.boulanger@utc.fr

2. Système ferroviaire (1) • Système de transport plus ou moins complexe: • Transport ferroviaire : • Transport de personne ; • Transport de fret ; • Transport urbain: • Métro (automatique ou non) ; • RER ; • Métro léger; • Différent types de métier et d’application: • Conduite des trains ; • Gestion du trafic ; • Gestion de l’exploitation ; • Maintenance; • …

3. Système ferroviaire (2)

4. Système ferroviaire (3) • Caractéristiques : • Une longue durée de vie : 40 ans • Chaque projet est « spécifique » • Chaque projet est souvent autonome (nouvelle ligne, nouveau besoin, …., remise a jour d’un équipement, ..) • Chaque partie du système est confié à un industriel • La SNCF a mis en place une politique de double fournisseurs • Changement: • Niveau ferroviaire : séparation entre exploitant (SNCF) et gérant (RFF); • Réhabilitation d’une ligne en exploitation (exemple ligne 1 du métro parisien); • …

5. Différents niveaux de sécurité • Le niveau de sécurité d’un système ferroviaire est introduit au travers du SIL (Safety Integrated level). • Cinq niveau • SIL0 Aucun risque • SIL1 – SIL2 Risque de blessure • SIL3 – SIL4 Risque de mort (1 ou plusieurs)

6. Référentiel normatif • Référentiel CENELEC • EN 50126: • Norme Européenne, NF EN 50126 « Applications ferroviaires - Spécification et démonstration de la fiabilité, de la disponibilité, de la maintenabilité et de la sécurité », Janvier 2000. • EN 50129: • Norme Européenne, ENV 50129 « Applications ferroviaires - Systèmes de signalisation de télécommunication et de traitement. Systèmes électroniques de sécurité pour la signalisation », Mai 2003. • EN 50128: • Norme Européenne, NF EN 50128 « Applications ferroviaires - Système de Signalisation, de télécommunication et traitements - Logiciels pour systèmes de commande et de protection ferroviaire », version française, Juillet 2001.

7. Prise en compte des COTS (1) EN 50126: L’utilisation d’un produit standard disponible dans le commerce peut varier d’une application à l’autre. A titre d’exemple le produit A est utilisé pour remplir des fonctions différentes dans les applications 1 et 2. Donc l’intégrité requise du composant peut évoluer en fonction de son utilisation. Avant d’utiliser un composant dans un système, il faut évaluer les limites et les contraintes relative à la fonction et à l’environnement afin d’évaluer leurs compatibilités avec les exigences du système Système 1 Système 2 A A C C C C C A B A B C

8. Prise en compte des COTS (2) • EN 50129: • Dans le cadre de cette norme ont définit le processus de maîtrise des risques à mettre en œuvre pour démontrer que le système, les sous-systèmes et les équipements sont exempts de défaillance. • Ce processus est basé sur la notion de risque et d’exigence. • Un élément de la chaîne peut avoir été « éprouvé » • déjà en utilisation, • dispose d’un certificat, • … • et être réutilisé en conformité avec les exigences du contexte.

9. Prise en compte des COTS (3) • CENELEC EN 50128 – Aspect Logiciel du commerce • SIL0 : • pas de contrainte • SIL1-SIL2: • Les logiciels utilisés doivent être inclus dans le processus de validation. • SIL3-SIL4: • Les logiciels utilisés doivent être inclus dans le processus de validation. • Une analyse des défaillances potentielles doit être réalisée. • Il faut mettre en place une stratégie pour détecter leurs défaillances et pour ce protéger de ces défaillances; • La stratégie de protection doit faire l’objet d’une validation • Des journaux des erreurs doivent exister et doivent être analysés. • Dans la mesure du possible on se limitera a utiliser les fonctions les plus simples.

10. Prise en compte des COTS (4) • La norme EN 50128 recommande « l’utilisation autant que possible de logiciel déjà vérifié/validé »

11. Ce qui ce passe effectivement • Dans le cadre des applications critiques: • Peu d’utilisation des COTS • Application spécifique • Processeur, outil de développement et compilateur • Dans le cadre des applications non-critiques: • Forte utilisation • mais pas ou peu de processus

12. Exemple d’application basée sur des COTS : PCC

13. PCC : nouvelle problématique • Actuellement un PCC (Poste de Commande Centralisé) est considéré comme un équipement de niveau SIL0. • Il a pour tâche de visualiser le trafic et de pouvoir le manager mais il ne réalise pas de commande à destination du terrain. • Suite a un certain nombre d’incident et aussi face à une nouvelle demande, les PCC commencent à intervenir sur la sécurité du système et de nouvelles questions se posent : • Impact de l’homme sur le système; • Impact des COTS sur le système; • Évolution su SIL : passage à SIL2.

14. Évolution actuelle – exemple 1 SACEM METEOR …. Processeur Codé équipement 68020 / 68040 Ligne 13 PMI SEI … Carte + Processeur du commerce Voteur spécifique équipement Architecture n/m

15. Évolution actuelle – exemple 2 • Applications critiques : • Processeur : 68040 • Système d’exploitation : OS spécialisés • Langage : ADA83 • Compilateur : qualifiés par l’utilisation (depuis les années 80). • Tentative d’évolution • Processeur : INTEL, PowerRisc, AMD • Système d’exploitation : Linux ? • Langage : C, C++, ADA95 …. • Compilateur : Gnat, GCC, …

16. Évolution induite par l’Europe • Mise en place d’un ensemble de texte normatif et de décret européen visant à homogénéiser le transport ferroviaire en Europe : • Gestion de la sécurité, • Règle d’exploitation, • Échange de train, • Partage du trafic, • …

17. ERTMS • Projet « European Railways Transportation Management System » • Constatation : • Chaque pays européen dispose d’un système ferroviaire ayant ces propres caractéristiques (taille des roues, écart des rails, signalisation, consigne d’exploitation, …) • But: • Ce référentiel a pour but de définir les caractéristiques techniques d’un système permettant à un train de franchir les frontières.

18. ERTMS (2) Standardisation des balises Standardisation d’un système radio GSM-Rail

19. TSI • Introduction de « spécification technique d’interopérabilité » qui caractérise l’architecture d’un système informatique et normalise un certain nombre de fonction. • Aspect grande vitesse • Aspect train conventionnel (en cours) • Aspect fret (en cours). • Constatation : • Lors de la conception d’une nouvelle ligne ferroviaire, le demandeur et le constructeur font souvent preuve d’innovation et d’intelligence pour produire un système « différent ». • Dans ces conditions, il y a peu de ré-utilisation donc des coûts constamment important. • But: • Définir une architecture de base pour les systèmes européens (équipement voie, système de contrôle/commande, supervision, ..) • Normaliser les fonctions afin de proposer des « composants » pouvant être associés à des certificats. • A terme : • Les industriels pourraient proposer des morceaux (COTS) qui répondraient à des exigences et ces morceaux pourraient être composés pour réaliser un système

20. Et l’interchangeabilité • Suite à la demande d’interopérabilité la suite logique était l’interchangeabilité. • Un élément est définit par ses interfaces et les fonctions qu’il remplit. • Interchangeabilité : • Pouvoir remplacer un élément d’un constructeur Y par un élément du constructeur Z.

21. Certificat • Chaque état européen doit se doter d’un organisme notifié pouvant délivrer des certificats de conformité d’un produit vis-à-vis des référentiels européens (ERTMS, TSI, ..). • Un processus de cross-acceptance (en cour) permettra de reconnaître les certificats entre organismes notifiés. • Des certificats de conformité d’un produit vis-à-vis des normes en vigueur peut-être remis par des laboratoire « accrédité ».

22. Conclusions • Une évolution du domaine ferroviaire vers une ingénierie des composants. • Les composants sont associés à des certificats définissant un contexte d’utilisation.