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

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; …

Système ferroviaire (2)

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); …

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)

Référentiel normatif Référentiel CENELEC EN 50126: EN 50129: EN 50128: 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.

Prise en compte des COTS (1) 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

Prise en compte des COTS (2) 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.

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

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

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

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

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.

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

É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, …

É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, …

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.

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

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

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.

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é ».

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.