Application ferroviaire et COTS

Présentation au sujet: "Application ferroviaire et COTS"— Transcription de la présentation:

1 Application ferroviaire et COTS
Boulanger Jean-Louis

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: EN 50129: EN 50128:
Norme Européenne, NF EN « 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 « 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 « 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)
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)
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 – 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.

10 Prise en compte des COTS (4)
La norme EN 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é 68020 / 68040 équipement 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.