Spécification et analyse de systèmes ferroviaires à l'aide

20e Congrès de maîtrise des risques et de sûreté de fonctionnement - Saint-Malo 11-13 octobre 2016

SPECIFICATION ET ANALYSE DE SYSTEMES FERROVIAIRES A L’AIDE D’UN LANGAGE DE SCENARIOS

SPECIFICATION AND ANALYSIS OF RAILWAY SYSTEMS USING A SCENARIO-ORIENTED LANGUAGE

Issad M. Kloul L. Rauzy A. LGI, CentraleSupélec DAVID, UVSQ NTNU Chatenay-Malabry, France Versailles, France Trondheim, Norvège Siemens SAS [email protected] [email protected] Chatillon, France [email protected]

Résumé Les systèmes industriels tels que les systèmes ferroviaires sont de plus en plus complexes. Cependant, leur spécification demeure manuelle et rédigée en langage naturel, source d’ambigüités et d’erreurs. Ces erreurs se répercutent sur l’ensemble du cycle de vie du système, notamment l’analyse de sûreté qui repose sur l’expertise des ingénieurs sûreté et l’analyse effectuée sur d’anciens projets. Dans cet article, nous proposons une approche basée sur les scénarios afin de modéliser l’architecture et le comportement de ce type de système. A partir de cette vue fonctionnelle, nous proposons une méthode de propagation de fautes afin de générer des scénarios défaillants et évaluer leur impact sur le système. Summary Due to their complexity, industrial systems as railway systems are hard to specify, validate and even harder to maintain. Still, thespecification of such systems is written in a natural language, which is source of ambiguity and errors. These errors may have an impact on the overall system life-cycle, especially safety analysis that is based on the expertise of safety engineers that rely on the previous projects analyses. In this article, we propose a scenario-based approach to specify the architecture and behavior of these systems.Therefore, we implement a fault propagation technique to generate failure scenarios based on the system behavior and evaluate the impact of such failures on the system.

Introduction et motivations

Dans un contexte où les systèmes complexes peinent à passer à l’échelle dû à l’accroissement des fonctionnalités implémentées, les méthodes de conception existantes sont obsolètes et ne répondent plus aux besoins de conception agiles et fiables. Il existe plusieurstravaux dans la littérature adressant cette problématique de modélisation système. L’objectif de notre travail est d’évaluer la spécification et l’analyse sécuritaire des systèmes d’automatisation ferroviaire (Communication Based Train Control) (Schifers et al., 2000) à l’aide de scénarios.

Un système d’automatisation ferroviaire équipe les trains et gère la mise en route et conduite des trains sur une voie. Le système est aussi responsable d’assurer la protection du train et des passagers pendant son fonctionnement et gérer les éventuelles pannes. Pour assurer de telles fonctionnalités, le système CBTC est composé de plusieurs sous-systèmes qui réalisent une vingtaine de fonctions principales, toutes composées de plusieurs sous-fonctions plus ou moins complexes. Le système CBTC est donc complexe et sa conception requiert une méthodologie qui permet une agilité dans la validation et la vérification de ce dernier. Dans cet article, nousanalysons les documents de conception associés aux systèmes CBTC de Siemens.

La spécification de ces systèmes est regroupée dans plusieurs documents rédigés en langage naturel, incluant également des figures et graphiques : Le document de spécification d’exigences qui liste les exigences au niveau système (réponse aux besoins client). Le document d’architecture système qui décrit les fonctions principales du système CBTC. La description démarre par une description préalable et non exhaustive des composantes du système. Elle est suivie par la description des fonctions principales. Chaque fonction est décrite informellement et lui est associée une ou plusieurs exigences. Une traçabilité avec le précédent document est aussi réalisée. De plus, un document glossaire contient la définition des abréviations introduites dans les documents précédemment cités. Un document d’interfaces décrit les données échangées entre les différentes composantes du système. De plus, un document de spécification fonctionnelle décrit plusieurs scénarios opérationnels associés aux fonctions principales du CBTC. Cette description du système à travers plusieurs documents se veut exhaustive. Cependant, l’usage du langage naturel prévient une compréhension de la spécification et empêche une uniformité de la description qui résulte en une ambigüité dûe aux techniques de rédaction différentes et parfois contradictoires.

L’analyse de sûreté quant à elle, est spécifique à Siemens. Elle répond aux normes EN 50126 et EN 50128 (CENELEC, 1999), réadapte certaines techniques d’analyse de sûreté standardisées et adopte des techniques de preuve de sûreté propres aux systèmes CBTC de Siemens. Les systèmes ferroviaires sont caractérisés par leur nombre restreint d’accidents (14), ce qui limite et cadre l’analyse de sûreté. A l’aide des spécifications fonctionnelles du système, une Analyse Préliminaire des Dangers (APD) ainsi qu’une Analyse des Modes de Défaillance et de leurs Effets et Criticité (AMDEC) sont réalisées. L’APD décrit les situations dangereuses pouvant résulter en accidents répertoriés. Pour chaque situation dangereuse identifiée, les différentes causes potentielles sont décrites. L’AMDEC décortique les différentes fonctions principales du système décrites dans le document d’architecture du système. A chaque fonction lui est associée une liste de modes de défaillance génériques. L’AMDEC décrit l’effet de chaque mode de défaillance sur une fonction. Une traçabilité avec l’APD est réalisée en associant à chaque effet d’un mode de défaillance une situation dangereuse détectée en phase d’APD.

L’APD et l’AMDEC sont des techniques répandues et standardisées. Même si leur utilisation n’est pas uniforme et diffère selon le type de système conçu et ses besoins spécifiques, leurs objectifs demeurent les mêmes ; analyser l’effet des différents accidents sur le système et ses fonctions principales. L’Analyse de Sûreté Fonctionnelle (ASF) quant à elle, est spécifique aux systèmes CBTC de Siemens. Elle se base sur l’expérience des experts sûreté qui, à partir des résultats de l’APD et AMDEC ainsi que des spécifications du système, établissent une liste d’évènements redoutés du système. A chaque évènement lui est associée une liste non-exhaustive de

Communication 6E /3 page 1/10

mailto:[email protected]




scénarios accidentels. Chaque scénario doit être analysé et prouvé, si le scénario est plausible sur la configuration du système, des exigences sécuritaires sont déployées. Si, par contre, le scénario est prouvé comme étant sûr, en se basant sur l’expérience des ingénieurs ainsi que les résultats des précédents projets, alors l’évènement redouté lui étant associé est répertorié comme étant impossible. L’ASF vérifie donc que les exigences sécuritaires couvrent toutes les causes potentielles ou situations dangereuses répertoriées dans l’APD.

Bien que ces techniques soient utilisées depuis plusieurs années, il n’en demeure qu’avec la multiplication des nouvelles fonctions implémentées sur le système et l’internationalisation de la conception, ces techniques peinent à passer à l’échelle. En effet, plusieurs problèmes sont redondants. Premièrement, l’exhaustivité des scénarios accidentels sur lesquels repose toute l’ASF ne repose que sur la conviction des experts. Deuxièmement, la traçabilité des scénarios avec la spécification fonctionnelle est hasardeuse. En pratique, les exigences système ne sont pas toutes couvertes par des scénarios qui lui sont propres. Souvent, des scénarios issus de précédents projets sont associés aux exigences du système. Troisièmement, les modes de défaillance utilisés en phase d’AMDEC sont génériques, donc rarement adaptés aux fonctions système. Souvent, plusieurs modes de défaillance ont un effet identique sur une fonction donnée et parfois un mode de défaillance n’est pas applicable à la fonction. Enfin, la structure des documents de spécification est non adaptée aux non-experts, ce qui implique la multiplication des erreurs systématiques dans l’analyse de sûreté résultant de la cascade d’incompréhensions pendant toutes les phases de conception et validation du système.

L’objectif de notre travail est de systématiser la spécification et analyse sécuritaire du système. Ce qui inclut la définition d’une méthodologie formellement définie et basée sur des concepts génériques afin d’uniformiser l’analyse des différentes fonctions du système. Il existe, dans la littérature et en pratique, plusieurs travaux autour de la systématisation des analyses de sûreté à partir de spécifications fonctionnelles, par exemple, (David et al., 2010).

Nous avons étudié l’impact de l’utilisation de scénarios en phase amont de la conception du système ainsi que leur utilisation pour valider les fonctions système. Dans cet article, nous présentons des méthodes d’analyse sécuritaire à partir de scénarios fonctionnels. Ces derniers sont modélisés à l’aide du langage de scénarios ScOLa. La structure de l’article est organisée comme ceci. Nous commençons par la présentation d’un exemple fil rouge issu des spécifications système CBTC de Siemens. Ensuite, nous présentons ScOLa, le langage de scénarios qui sert de support à la spécification à l’aide de scénarios. Enfin, nous présentons deux méthodes d’analyse de sûreté de ces systèmes et terminons par un état de l’art des méthodes couplées de modélisation système et analyse de sûreté.

Cas d’étude Un système CBTC est un système de contrôle pour métros et véhicules légers. Il commande les différentes fonctionnalités du train à travers des interactions continues entre un système installé à bord des trains ainsi qu’un système sol installé sur les voies. Le système bord contrôle l’ouverture et la fermeture des portes, le freinage, le positionnement du train, la gestion de sa vitesse, son arrêt ainsi que la transmission d’informations aux passagers. Le système sol est quant à lui responsable de délivrer des autorisations de mouvement au train selon sa vitesse et sa position sur les voies. Dans un système CBTC, la fonction qui maintient une distance de sécurité entre les trains est la fonction de localisation. Elle représente l’une des fonctions principales du système car les informations résultantes sont critiques. Elle est utilisée afin de détecter en temps réel la position d’un train et maintenir une distance de sécurité et ainsi assurer la sécurité des passagers à bord. Le scénario associé à cette fonction décrit le calcul de la position du train ainsi que le transfert d’informations entre deux trains, tous deux équipés du système CBTC (voir Figure 1). Les deux trains communiquent avec une unique composante au sol. Ils calculent leur position en continu et la transmettent au sous système sol. Celui-ci à son tour, détermine l’espace réglementaire aux deux trains. Si l’espace est atteint par l’un des trains, il applique un freinage d’urgence, sinon les deux trains ajustent leur vitesse en conséquence. Le scénario est décrit dans le document de spécification fonctionnelle en un ensemble d’étapes. Une ou plusieurs exigences sont associées à chaque étape ainsi qu’un tableau décrivant les conditions initiales nécessaires au scénario.

Figure 1. Scénario de localisation d'un système CBTC



Analyse de spécifications système

Afin d’analyser la spécification système rédigée en langage naturel, une première étape de formalisation de cette dernière est nécessaire. Pour ce faire, nous présentons le langage ScOLa défini à partir du document d’architecture et de spécification de scénarios du système CBTC de Siemens. Ce dernier représente la base pour un support formel de spécification système ainsi qu’une base pour une analyse de sûreté basée sur les scénarios.

Présentation de ScOLa ScOLa (Issad et al., 2015) (Scenario Oriented Language) représente une solution aux difficultés rencontrées lors de la spécification système. ScOLA est la composition d'un langage de description d'architecture et d'un modèle comportemental de scénarios formellement défini. La description de l’architecture structure les composantes du système. Cette description se base sur le paradigme S2ML (Batteux et al., 2015) en proposant une vue hiérarchique, orientée prototype, des composantes. Une composante est similaire à une classe, elle peut être instanciée et permet la connexion entre composantes à l’aide de ports et attributs. Comme un scénario peut prendre en compte plusieurs instances d’une architecture, ScOLa introduit le concept de bloc. A chaque scénario est attribué un bloc qui peut, à son tour, être attribué à plusieurs scénarios. Un bloc est donc une composition d’instances de l’architecture. Définition : Un modèle de scénarios ScOLa M est défini par le tuple <S, A, C, L, Op> tel que :

- S est un ensemble fini de scénarios qui décrivent le comportement du système ; - A est un ensemble fini d’actions atomiques qui composent les scénarios ; - C est un ensemble de composantes physiques du système qui structure l’architecture du système ; - L est l’ensemble des niveaux d’abstraction possibles du système ; - Op est un ensemble fini d’opérateurs.

Concept de scenario: c’est une séquence d'actions ou d'événements correspondants aux réactions du système à un contexte donné. Les scénarios représentent la partie fonctionnelle du système. Un scénario est unique, réutilisable et peut contenir plusieurs sous-scenarios. Un scenario représente une vue abstraite et de haut niveau de la description comportementale. Formellement, un scénario s € S est défini par le tuple <Id

s, L

s, F(s)> tel que :

- Ids est l’identifiant unique du scénario ;

- Ls est le niveau d’abstraction associé à s ;

- F(s) est l’ensemble de sous-scénarios ou actions qui composent s. Si F(s) = ᶲ alors s est une action. Concept d'action: Lorsqu'un scénario ne peut être décomposé, il est considéré comme étant une action. Cette dernière est unique, réutilisable, et lui est associée une ou plusieurs composantes selon son type. Formellement, une action a €A est définie par le tuple <Id

a, C(a), L

a, T(a)> tel que :

- Ida est l’identifiant unique de a ;

- C(a) est l’ensemble de composantes nécessaires à la réalisation de a ; - L

a est le niveau d’abstraction correspondant à a ;

- T(a) est le type correspondant à a. - Une action peut être de type simple si elle est exécutée par une seule composante (par exemple, un traitement de données).

Formellement, soit As l’ensemble d’action simples. Si a €A, alors Ǝ c € C te que a €A(c).

- Une action de type transfert représente un échange d'information entre deux composantes. Formellement, soit At l’ensemble

d’actions de transfert. Si a €A, alors Ǝ c1, c

2 € C tel que a €A(c

1) ∩ A(c

2).

- Une action de type test représente une condition. Soit Aq l’ensemble d’actions de type test. Si a € A

q et a

1, a

2, …, a

n € A

alors l’exécution de a enclenche l’exécution de a1 ou a

2 ou …a

n.

Concept de composante: c’est la partie physique du système. Une composante fait partie de l'architecture et peut être instanciée dans un ou plusieurs blocs. Une composante est unique, peut être allouée à une ou plusieurs actions du système, c’est à dire une composante peut être assignée à une action simple ou être en coopération avec une autre composante sur une action de transfert. Formellement, une composante c €C est définie par le tuple <Id

c, A(c), C(c), L

c> tel que :

- Idc est l’identifiant unique de c ;

- A(c) est l’ensemble d’actions allouées à c ; - C(c) est l’ensemble de sous-composantes de c, si C(c) = ᶲ alors c est basique ; - L

c est le niveau d’abstraction de c.

Les scénarios représentent un processus donné. Ils sont exécutés selon un ordre défini par un des concepts suivants: Concept de précédence: On considère deux scénarios s

1 et s

2 . Si s2 dépend de s

1 et ne peut s'exécuter qu'à la fin de s

1, alors nous considérons que s

1 et s2 ont une relation de précédence, l’inverse est également valable.

Concept de parallélisme: Si l'on considère deux scénarios s

1 et s

2 et que l'ordre d'exécution de ces scénarios n'a pas d'impact sur le

résultat du scénario, alors s1 et s

2 ont une relation de parallélisme.



Concept de choix: Si un scénario s est de type test et suivi par deux scénarios s1 et s

2, alors, selon le résultat de s, seule une action peut

être exécutée, l'autre est annulée. Concept de raffinement : L’une des particularités des spécifications système classiques est leur niveau de détail important qui peut être utile pour du développement logiciel, mais compliqué pour des analyses systèmes telles que le test ou la validation, qui essaient de détecter des erreurs au plus tôt et au plus haut niveau de description. Pour pallier à cette difficulté, ScOLA introduit le concept de raffinement. Ce dernier structure et synchronise la relation entre le modèle ScOLA ainsi que le modèle d'architecture. En effet, un modèle au plus haut niveau l=0 est un ensemble de scénarios décrivant le comportement de composantes du niveau l=0 de l'architecture. Ensuite, à l'aide de raffinements successifs sur le modèle et l'architecture, on obtient un descriptif plus détaillé du système. Exemple : Modélisation graphique du scénario de localisation

Afin de représenter une spécification système à l’aide du formalisme ScOLa. Nous introduisons plusieurs opérateurs graphiques résumés dans le tableau suivant (Table 1) :

Concept Opérateur graphique Scénario S

Composante C

Action simple A

Action de transfert T

Action test Q

Parallélisme

Précédence

Table 1. Représentation graphique de ScOLa

Les Figure 2 et 3 sont une représentation graphique de l’architecture et du comportement du scénario de localisation en ScOLa.

S

A

S1 S2

C

C C

T

C1 C2

Q

S1 S2

S1 S2

Architecture

Train1

On-Board1

OBCU1 Odometry1

Train2

On-Board2

OBCU2 Odometry2

Wayside

WCU_ATP

Figure 2. Représentation graphique de l'architecture du scénario



Analyse de sûreté fonctionnelle à l’aide de ScOLa

Nous présentons une méthodologie de définition de scénarios défaillants à partir de scénarios fonctionnels. Cette dernière prend en entrée les scénarios fonctionnels définis en ScOLa ainsi que leurs modèles d’exécution associés. Ensuite, à l’aide d’un mécanisme d’injection et de propagation de fautes, elle détermine des scénarios défaillants associés.

Un modèle ScOLa est une composition de composantes et de scénarios et/ou actions. Nous définissons une défaillance de base comme étant la défaillance d’un de ses trois éléments. Nous distinguons aussi la défaillance partielle qui permet à l’élément de s’exécuter mais en générant une information erronée et la défaillance totale qui stoppe la composante ou le scénario. Nous considérons une configuration défaillante, un type de défaillance associé à l’élément défaillant, par exemple une composante partiellement défaillante est une configuration défaillante. Enfin, la propagation d’une configuration défaillante dans un modèle de scénario fonctionnel génère un scénario défaillant. Le tableau suivant résume les types de configurations défaillantes ainsi que leur implémentation dans le modèle d’exécution d’un scénario (Table 2) :

Type de défaillance Elément défaillant Implémentation de la défaillance

Partielle Composante Initialisation erronée du/des composants

Scénario Scénario/Action résultant une donnée erronée (mauvais transfert, mauvais résultat de test, mauvaise affectation de données)

Interface Interface unique générant un mauvais résultat sur toutes les actions correspondantes

Totale Composant Composant ne réalisant aucune action

Figure 3. Représentation graphique du scénario de localisation



Scénario Scénario/Action ne générant aucun résultat

Interface Multiples interfaces similaires ne générant aucun résultat

Table 2. Implémentation des configurations défaillantes

Enfin, la démarche de propagation de fautes qui génère un scénario défaillant est résumée comme ceci :

Pour chaque scénario fonctionnel : 1. Définir le sous-scénario où sera appliquée la défaillance de base 2. Définir une configuration défaillante au sous-scénario : type de défaillance et sa cause 3. Propager la configuration défaillante au scénario 4. Déduire le scénario défaillant

Exemple

Considérons le scénario de localisation du système CBTC précédemment décrit (Figure 3). Analysons la défaillance totale de la composante OBCU1 : les deux premiers sous-scénarios s’exécutent en parallèle, l’OBCU1 ne calcule pas la position du train, l’OBCU2 quant à lui s’exécute et transfert la position du train2 au WCU_ATP. Cependant, comme le sous-scénario suivant est en précédence et donc attend le résultat des deux trains, il reste en attente indéterminée. Le scénario ne peut donc poursuivre son déroulement. Dans ce cas, le scénario doit intégrer un mécanisme de détection de faute.

Si l’on considère la défaillance partielle de l’interface entre l’OBCU2 et le WCU_ATP. L’OBCU1 va transmettre une information erronée concernant la position du train2, mais le scénario poursuit son déroulement. Le WCU_ATP va transmettre une mauvaise distance sécuritaire au train2. Cette erreur peut provoquer soit un déclenchement de l’arrêt d’urgence injustifié et donc entrainer une série de mesures stoppant le trafic soit provoquer une collision des deux trains. Dans ce cas, des actions correctrices doivent être prises en compte afin de maitriser ces erreurs.

La défaillance partielle du sous-scénario test qui vérifie si l’espace limite entre les deux trains est atteinte peut aussi provoquer un arrêt d’urgence inopiné ou un mauvais ajustement de la vitesse limite entre les deux trains.

Cette approche est systématique, et peut être appliquée à plusieurs types de défaillances. De plus, l’implémentation de cette approche est réalisée en injectant une ou plusieurs configurations défaillantes dans le modèle d’exécution associé au scénario. Par la suite, une simulation du modèle décrit si le scénario résultant est défaillant ou pas.

Simulation d’un modèle

ScOLa est un langage de modélisation basé sur des scénarios. Il permet une description formelle et systématique de l’architecture ainsi que le comportement du système. Afin d’analyser et vérifier le comportement du système et l’allocation de l’architecture, nous proposons une simulation du système. ScOLa étant un langage principalement dédié au support à la communication entre ingénieurs, afin de simuler le comportement du système à partir d’un modèle ScOLa, il est nécessaire de lui associer un modèle d’exécution. Un modèle d’exécution naturel pour ScOLa est AltaRica 3.0. Les deux langages reposent sur le même paradigme de structuration S2ML. La traduction d’un modèle ScOLa vers AltaRica se réduit à la traduction du comportement. Le langage AltaRica est défini comme un langage événementiel : le système ne change d'état que lorsqu’un événement se produit. L'état du système est défini par la valeur de variables. Les changements d'états sont décrits par des transitions étiquetées par des événements. Des délais stochastiques ou déterministes peuvent être associés aux événements pour créer les modèles temporisés ou stochastiques. Les modèles de composants peuvent être assemblés en hiérarchies, connectés entre eux et leurs événements peuvent être synchronisés. De plus, AltaRica 3.0 adopte un nouveau paradigme de structuration des modèles: la modélisation orientée prototypes. Le modèle d'exécution est basé sur le formalisme des Systèmes de Transitions Gardées (GTS) (Rauzy, 2008), ce qui permet de modéliser les systèmes bouclés et les composants acausaux, c'est-à-dire les composants pour lesquels les entrées-sorties sont déterminées dynamiquement à l'exécution du modèle. Pour plus de détails sur la syntaxe et sémantique d’AltaRica 3.0 voir (Rauzy et al., 2014). Le modèle d’exécution d’un scénario ScOLa en AltaRica 3.0 s’effectue en deux étapes : Structure du modèle : AltarRica et ScOLa se basent sur le même paradigme de structuration S2ML. Nous utilisons les constructions structurelles d’AltaRica (la notion de classe et de prototype) afin de représenter l’architecture du système qui est une hiérarchie de composantes. La structure des scénarios et actions sont aussi représentées à l’aide du concept de prototype. Un scénario peut être composé d’un ou plusieurs sous-scénarios ou actions et les actions sont composées d’une ou plusieurs composantes selon son type. Modèle comportemental : Dans une spécification à l’aide de réseaux de Petri (Murata, 1989) ou chaines de Markov (Kemeny et al., 1960), les états du système sont préalablement connus. L’exécution de ce type de modèles est la réaction du système à de multiples évènements. Un modèle de scénarios quant à lui, crée les états au fur et à mesure, c’est à dire l’état final du système n’est pas connu au préalable. Dans notre implémentation du modèle ScOLa, nous introduisons la notion d’activation et de désactivation des scénarios. Tous les scénarios sont spécifiés mais sont dans un état d’attente ou désactivés. Seul un évènement externe de la part du scénario parent les active afin qu’ils s’exécutent. Chaque scénario peut donc activer ou désactiver un de ses sous-scénarios. A l’aide de cette même technique, nous associons aux différents concepts du langage, un système de transitions gardées. La Figure 4 représente les différents GTS associés aux concepts de précédence, parallélisme et choix. Le modèle AltaRica correspondant au modèle ScOLa est la composition des GTS associés aux différents éléments du modèle. Nous présentons une sous-partie du modèle AltaRica traitant du scénario de localisation du train en Annexe A.

La simulation d’un modèle d’exécution d’un scénario ScOLa peut ainsi être réalisée à l’aide des différents outils associés au langage Altarica 3.0 :



• Simulateur pas à pas (Prosvirnova et al., 2013) • Simulateur stochastique (Batteux et al., 2013)

Cette simulation nous permet de vérifier la faisabilité du scénario ainsi que ses différentes exécutions possibles et réactions à des conditions initiales différentes.

Etat de l’art

Il existe plusieurs travaux dans la littérature qui traitent de la problématique de la spécification et analyse de sûreté des systèmes complexes. L’ingénierie système basée sur les modèles tend à améliorer la spécification système à l’aide de méthodes formelles et semi-formelles. Les méthodes formelles reposent sur des bases mathématiques, notamment la méthode B (Abrial, 2005) basée sur le langage B pour la spécification des systèmes ferroviaires. Scade (Dormoy, 2008) est aussi un langage formel certifié pour le développement système utilisé dans de nombreux domaines. AADL (Feiler, 2006) et Uppaal (Larsen, 1997) ont aussi les mêmes propriétés. Cependant, le coût d’entrée des méthodes formelles est élevé. Elles requièrent une expertise qui est rare et coûteuse en temps et argent. Les méthodes semi-formelles sont principalement des notations graphiques afin de représenter différents aspects du système. Les graphiques sont un support de communication entre parties prenantes. ARCADIA (Voirin et al., 2013) (Architecture Analysis and Design Integrated Approach) est une méthode développée par Thales et propose plusieurs vues pour la représentation logique, physique et fonctionnelle du système. SysML (Friedenthal, 2014) est le langage de modélisation le plus répandu dans l’industrie et utilisé dans le cadre de plusieurs méthodologies de conception telles que SysCars (Piques et al., 2011) développé par Valeo et ASAP (Chalé Gongora, 2014) développé par Alstom. Cependant, toutes ces approches ne sont valides que dans un contexte spécifique. Elles représentent des objets plutôt que des concepts. Elles peuvent ne plus être valides si les systèmes sont amenés à évoluer. La sûreté de fonctionnement basée sur les modèles (MBSA) est une discipline qui se base sur des méthodes formelles afin de réaliser des analyses de sûreté. Altarica (Rauzy et al., 2014) est un langage de description hiérarchique du comportement nominal et défaillant de systèmes. Hip-Hops (Papadopoulos et al., 2011) est un modèle prédictif de modélisation des défaillances du système. Simulink (Ong, 1998) est un outil utilisé pour la modélisation et simulation des systèmes. Scade (Dormoy, 2008) est un environnement de développement critique basé sur les langages Lustre (Halbwachs et al., 1991) et Esterel (Berry, 1992).

Plusieurs langages et notations graphiques permettent la modélisation graphique de scénarios, les différents diagrammes UML/SysML tels que les diagrammes de séquence qui implémentent les message sequence charts (David Harel, 2004), les diagrammes d’activité qui sont une spécialisation des diagrammes d’état et une variante des statecharts (Harel, 1987). Enfin, les diagrammes de Vue d’Ensemble d’Interaction d’UML, similaires aux diagrammes d’activité, ils permettent une construction hiérarchique des activités du diagramme. BPMN (Business Process Modeling Notation) (White, 2004) est une notation graphique standardisée qui représente les processus d’entreprise. Il existe plusieurs travaux qui associent une sémantique formelle à ces notations graphiques. Nous pouvons citer notamment les travaux de Martin Glinz qui associe une sémantique formelle aux statecharts dans (Glinz, 1995). Une autre approche de formalisation consiste en la transformation de ces notations semi-formelles en langages formels. Nous pouvons citer les travaux de (Dijkman et al., 2007) qui transforment les BPMN en réseaux de Petri, ou les diagrammes d’activité en réseaux de Petri (López-Grao et al., 2004). Des langages plus formels permettent la représentation de scénarios tels que les différentes algèbres de processus (CCS, CSP et ACP en sont les références, comme citées dans (Baeten, 2005)). Les modèles de scénarios définis en ScOLa dans le cadre de notre étude auraient très bien pu être représentés à l’aide des ces différents langages. Cependant, comme les scénarios référent à des éléments de l’architecture fonctionnelle et physique, il était important d’intégrer l’architecture du système au modèle de scénarios afin de capturer le maximum d’informations dans un modèle. De plus, ce besoin d’avoir un langage dédié d’une part à la communication entre ingénieurs et l’analyse formelle, nous a poussés à capturer les différents concepts qui nous intéressaient dans un DSL (Domain Specific Language) ScOLa, et de définir son modèle d’exécution en AltaRica 3.0.

Figure 4. Les systèmes de transitions gardées associés aux concepts de précédence et parallélisme et de choix

a. Prédédence

b. Parallélisme

c. Choix



Conclusion

Dans cet article, nous avons présenté une méthodologie d’analyse de sûreté à l’aide de scénarios. Les scénarios reposent sur ScOLa, un langage de modélisation basé sur le concept de scénario et qui permet la modélisation de l’architecture ainsi que le comportement du système et leur interaction à travers des instanciations et agrégations. Les techniques de sûreté présentées visent à supporter et améliorer les méthodes existantes en proposant une approche inductive complémentaire à l’approche déductive existante et permettre une analyse plus en amont afin de détecter des erreurs au plus tôt. Ces techniques ont été implémentées sur des scénarios issus de la spécification système CBTC de Siemens. Notre travail a permis de mettre en exergue l’utilité des scénarios à représenter les différentes interactions entre les éléments de l’architecture d’un système ainsi que d’être un support à la communication plus intuitif entre les différentes parties prenantes du système. Cette étude nous a permis de détecter des erreurs systématiques et des informations manquantes telles que les composantes allouées à certaines fonctions données, les informations concrètes d'une action ainsi que les relations entre actions. Concernant la sûreté de fonctionnement, les approches précédemment citées sont complémentaires aux méthodes existantes. Elles permettent de faciliter l'échange entre ingénieurs ainsi que de s'assurer que toute information est explicite. Cette structure améliore l'extraction de données utilisables pour une analyse de sûreté. En effet, l'assignation de composantes aux actions permet, par exemple, de lister les actions d'une composante donnée dans un processus.

Références

Abrial, J. R. (2005). The B-book: assigning programs to meanings. Cambridge University Press. Baeten, J. C. (2005). A brief history of process algebra. Theoretical Computer Science, 335(2), 131-146. Batteux, M., & Rauzy, A. (2013). Stochastic Simulation of AltaRica 3.0 models. Proceedings of the European Safety and Reliability Conference, ESREL 2013.Amsterdam (The Netherlands). Batteux, M., Prosvirnova, T., & Rauzy, A. (2015). System Structure Modeling Language (S2ML). Berry, G., & Gonthier, G. (1992). The Esterel synchronous programming language: Design, semantics, implementation. Science of computer programming, 19(2), 87-152. CENELEC, 50126 (1999): Railway applications–The specification and demonstration of Reliability. Availability, Maintainability and Safety (RAMS). David, P., Idasiak, V., & Kratz, F. (2009). Improving reliability studies with SysML. In Reliability and Maintainability Symposium, 2009. RAMS 2009. Annual (pp. 527-532). IEEE. Dijon (France). Dijkman, R. M., Dumas, M., & Ouyang, C. (2007). Formal semantics and analysis of BPMN process models using Petri nets. Queensland University of Technology, Tech. Rep. Dormoy, F. X. (2008). Scade 6: a model based solution for safety critical software development. In Proceedings of the 4th European Congress on Embedded Real Time Software (ERTS’08) (pp. 1-9). Feiler, P. H., Gluch, D. P., & Hudak, J. J. (2006). The architecture analysis & design language (AADL): An introduction. Carnegie-Mellon Univ Pittsburgh PA Software Engineering Inst. Friedenthal, S., Moore, A., & Steiner, R. (2014). A practical guide to SysML: the systems modeling language. Morgan Kaufmann. Glinz, M. (1995, September). An integrated formal model of scenarios based on statecharts. In European Software Engineering Conference (pp. 254-271). Springer Berlin Heidelberg. Halbwachs, N., Caspi, P., Raymond, P., & Pilaud, D. (1991). The synchronous data flow programming language LUSTRE. Proceedings of the IEEE, 79(9), 1305-1320. Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of computer programming, 8(3), 231-274. Harel, D., & Thiagarajan, P. S. (2003). Message sequence charts. In UML for Real (pp. 77-105). Springer US. Hugo Guillermo Chalé Gongora (2014). MBSE for railway rolling stock – Alstom ASAP methodology. Specief. Issad, M., Kloul, L., Rauzy, A., & Berkani, K. (2015). ScOLA, a Scenario Oriented Modeling Language for Railway Systems. INSIGHT, 18(4), 34-37. Kemeny, J. G., & Snell, J. L. (1960). Finite markov chains (Vol. 356). Princeton, NJ: van Nostrand. Larsen, K. G., Pettersson, P., & Yi, W. (1997). UPPAAL in a nutshell. International Journal on Software Tools for Technology Transfer (STTT), 1(1), 134-152. López-Grao, J. P., Merseguer, J., & Campos, J. (2004). From UML activity diagrams to Stochastic Petri nets: application to software performance engineering. ACM SIGSOFT software engineering notes, 29(1), 25-36. Murata, T. (1989). Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77(4), 541-580. Ong, C. M. (1998). Dynamic simulation of electric machinery: using MATLAB/SIMULINK (Vol. 5). Upper Saddle River, NJ: Prentice Hall PTR. Papadopoulos, Y., Walker, M., Parker, D., Rüde, E., Hamann, R., Uhlig, A., ... & Lien, R. (2011). Engineering failure analysis and design optimisation with HiP-HOPS. Engineering Failure Analysis, 18(2), 590-608. Piques, J. D., & Andrianarison, E. (2011). SysML for embedded automotive systems: lessons learned. Interfaces, vol.3, p. 3b. Prosvirnova, T., Batteux, M., Brameret, P.-A., Cherfi, A., Friedlhuber, T., Roussel, J.-M., et al. (2013). The AltaRica 3.0 project for Model-Based Safety Assessment.4th IFAC Workshop on Dependable Control of Discrete Systems, DCDS 2013.York (Great Britain): IFAC. Rauzy, A. B. (2008). Guarded transition systems: a new states/events formalism for reliability studies. Proceedings of the Institution of Mechanical Engineers, Part O: Journal of Risk and Reliability, 222(4), 495-505. Rauzy, A., & Prosvirnova, T. (2014). Les constructions structurelles de AltaRica 3.0. Actes du Congrès Lambda-Mu 19. Schifers, C., & Hans, G. (2000). IEEE standard for communications-based train control (CBTC) performance and functional requirements. In Vehicular Technology Conference Proceedings, VTC (pp. 1581-1585). Voirin, J. L., & Bonnet, S. (2013). Arcadia: Model-based collaboration for system, software and hardware engineering. In Complex Systems Design & Management, poster workshop (CSD&M 2013). White, Stephen A. "Introduction to BPMN." IBM Cooperation 2.0 (2004): 0.

Annexe A

domain StateScenario{IDLE, BEGIN, S_1, S_2, S_3, S_4, S_5, DONE, FAILED} domain StateAction{IDLE, BEGIN, WORK, DONE, FAILED} domain StateCondition{IDLE, BEGIN, sTRUE, sFALSE, FAILED} domain stateComponent{IDLE, FAILED, WORKING} include "architecture/components.alt"



class DeterminationOfSpeedLimitTrain // Scenario of train speed limit determination stateComponent s (init = WORKING); Train train ; block determineSpeedLimit stateScenario s (init = WORKING); block testDistance // if safe distance is not reached, train determines speed plan, else train emergency brake block testSafeDistance StateCondition s (init = IDLE); event activate (delay = dirac(0)); event etrue (delay = dirac(0)); event efalse (delay = dirac(0)); embeds Train.TGMT.OBCU as obcu; transition activate: s == IDLE -> s := BEGIN; etrue: s == BEGIN and obcu.s == WORKING and obcu.distance == true -> s := sTRUE; efalse: s == BEGIN and obcu.s == WORKING and obcu.distance == false -> s := sFALSE; hide activate, Etrue, Efalse; assertion obcu.outFlow := false; end block bTrue // determine and transmit speed plan and receive speed limit from wayside

block determineSpeedPlan StateCondition s (init = IDLE); event activate (delay = dirac(0)); event work (delay = dirac(0)); event stop (delay = dirac(0)); embeds Train.TGMT.OBCU as obcu; transition activate: s == IDLE -> s := BEGIN; work: s == BEGIN and obcu.s == WORKING -> s:= DONE; stop: s == DONE -> s:= IDLE; hide activate, stop; assertion obcu.speed := true; end block transmitSpeedLimit block emitSpeedLimit StateCondition s (init = IDLE); event activate (delay = dirac(0)); event work (delay = dirac(0)); event stop (delay = dirac(0)); embeds Train.TGMT.OBCU as obcu; transition

activate: s == IDLE -> s := BEGIN; work: s == BEGIN and obcu.s == WORKING -> s:= DONE; stop: s == DONE -> s:= IDLE; hide activate, stop; assertion obcu.outFlow := obcu.speed; end block receiveSpeedLimit

StateCondition s (init = IDLE); event activate (delay = dirac(0)); event work (delay = dirac(0)); event stop (delay = dirac(0)); embeds Train.TGMT.OBCU as obcu; embeds Train.TGMT.Odometry as odometry ; transition activate: s == IDLE -> s := BEGIN; work: s == BEGIN and obcu.s == WORKING and odometry.s == WORKING -> s:=

stop: s == DONE -> s:= IDLE; hide activate, stop; assertion odometry.inFlow := obcu.outFlow;

end transition // parallelism between transmission and reception of speed limit activate: s == IDLE -> s := BEGIN; work: s == BEGIN -> s:= S_1; stop: s == S_1 -> s:= DONE; fire: !work & !transmitSpeedLimit.activate & !receiveSpeedLimit.activate; sync: !stop & !transmitSpeedLimit.stop & !receiveSpeedLimit.stop ; hide activate, work, stop; assertion odometry.inFlow := obcu.outFlow ;

end block determineSpeedLimit StateCondition s (init = IDLE); event activate (delay = dirac(0));



event work (delay = dirac(0)); event stop (delay = dirac(0)); embeds Train.TGMT.OBCU as obcu; transition activate: s == IDLE -> s := BEGIN; work: s == BEGIN and obcu.s == WORKING -> s:= DONE; stop: s == DONE -> s:= IDLE; hide activate, stop; assertion obcu.speed := true; end transition // precedence between the speed plan determination and the speed transmission activate: s == IDLE -> s := BEGIN; work1: s == BEGIN -> s := S_1; work2: s == S_1 -> s := S_2; work3: s == S_2 -> s := DONE; stop: s == DONE -> s:= IDLE; fireDetermineSpeedPlan: !work1 & !determineSpeedPlan.activate; fireTransmitSpeedLimit: !work2 & !transmitSpeedLimit.activate & !determineSpeedPlan.stop; fireDetermineSpeedLimit: !work3 & !determineSpeedLimit.activate & !transmitSpeedLimit.stop; stopDetermineSpeedLimit: !stop & !determineSpeedLimit.stop; hide activate, work1, work2, work3, stop; end

block bFalse // trigger emergency brake block triggerEmergencyBreaking StateCondition s (init = IDLE); event activate (delay = dirac(0)); event work (delay = dirac(0)); event stop (delay = dirac(0)); embeds Train.TGMT.OBCU as obcu; transition activate: s == IDLE -> s := BEGIN; work: s == BEGIN and obcu.s == WORKING -> s:= DONE; stop: s == DONE -> s:= IDLE; hide activate, stop; assertion obcu.emergencyBrake := true; end transition // precedence mechanism activate: s == IDLE -> s := BEGIN; work: s == BEGIN -> s := DONE; stop: s == DONE -> s:= IDLE; fireDetermineSpeedPlan: !work1 & !determineSpeedPlan.activate; fireTransmitSpeedLimit: !work2 & !transmitSpeedLimit.activate & !determineSpeedPlan.stop; fireDetermineSpeedLimit: !work3 & !determineSpeedLimit.activate & !transmitSpeedLimit.stop; stopDetermineSpeedLimit: !stop & !determineSpeedLimit.stop; hide activate, work1, work2, work3, stop; end transition // choice mechanism activate: s == IDLE -> s := BEGIN; workTest: s == BEGIN -> s:= S_1; work: s == S_1 -> s:= S_2; sync: s == S_2 -> s := DONE; stop: s == DONE -> s := IDLE; fireTestSafeDistance: !workTest & !testSafeDistance.activate; fireTrue: !testSafeDistance.Etrue & !bTrue.activate & !work; fireFalse: !testSafeDistance.Efalse & !bFalse.activate & !work; stopTrue: !bTrue.stop ; stopFalse: !bFalse.stop ; hide activate, workTest, sync, stop, work; end

transition // GTS of the scenario activate: s == IDLE -> s := BEGIN; work1: s == BEGIN -> s := S_1; work2: s == S_1 -> s := S_2; work3: s == S_2 -> s := S_3; work4: s == S_3 -> s := S_4; work5: s == S_4 -> s := DONE; stop: s == DONE -> s:= IDLE; fireCalculatePosition: !work1 & !obcu.calculatePosition.activate; fireEmitPosition: !work2 & !obcu.emitPosition.activate & !obcu.calculatePosition.stop; fireReceiveDistance: !work3 & !obcu.receiveDistance.activate & !obcu.emitPosition.stop; fireTestDistance: !work4 & !testDistance.activate & !obcu.receiveDistance.stop; stopTestDistance: !stop & !testDistance.stop; hide activate, work1, work2, work3, work4, work5, stop;

end end


Documents

Spécification et analyse de systèmes ferroviaires à l'aide