Soutenance mémoire
Modélisation de systèmes complexes
Cette section décrit le contexte académique de notre travail : il s’agit de la modélisation et de l’analyse des systèmes complexes. Nous introduisons également les enjeux et les concepts de l’ingénierie système, et comment ils s’intègrent dans un cycle global de conception. Ensuite, nous décrivons de manière synthétique les différents types de modèles permettant de décrire et d’analyser un système complexe, ainsi que les différentes propriétés qu’il doit posséder, exprimées notamment dans son cahier des charges. Plus précisément, nous nous focalisons sur l’étude des systèmes à événements discrets soumis à des contraintes temporelles.
Pourquoi modéliser ?
La modélisation est indispensable pour la compréhension et l’analyse des systèmes industriels et constitue une base du processus de conception. Elle regroupe un ensemble de techniques permettant de disposer d’une représentation mathématique du système à étudier. Un modèle est une approximation, une vue plus ou moins abstraite de la réalité afin de l’appréhender plus simplement, selon un point de vue établi pour un objectif donné. La notion de complexité permet de qualifier des systèmes qui, par certains de leurs comportements, par leur taille et par la diversité de nature des phénomènes mis en jeu, présentent des difficultés d’analyse. Ainsi, un système complexe ne peut pas être réduit à un modèle unique. Un modèle ne rend compte que d’une partie de la connaissance du système étudié et en masque une autre partie, considérée superflue ou inutile à l’objectif désiré. Il n’est qu’une représentation d’un système dans son environnement d’utilisation. Plus qu’un modèle unique, c’est donc un ensemble de modèles complémentaires qui doit être élaboré en fonction des usages et des objectifs des différents acteurs d’un projet. De plus, il en va de même pour le choix des outils utilisés pour représenter ces différents modèles ; le contexte d’application devra ainsi être clairement défini afin de choisir de façon pertinente des outils spécifiques et adaptés. Entre autres, les outils de modélisation peuvent être textuels ou graphiques, fonctionnels ou analytiques, informels ou formels.
Ingénierie système
Tout d’abord, il semble nécessaire de clarifier la notion de système utilisée dans ce mémoire. Il existe en effet plusieurs définitions de ce terme en fonction du domaine étudié ou du point de vue adopté. Nous reprenons la définition 1.1 énoncée dans [Meinadier98].
Définition 1.1 (Système)
Un système est un ensemble composite de personnels, de matériels et de logiciels organisés pour que leur interfonctionnement permette, dans un environnement donné, de remplir les missions pour lesquels il a été conçu.
De nombreuses difficultés se présentent lors de la construction de systèmes devenant de plus en plus complexes : des besoins mal exprimés ou mal perçus, des spécifications imprécises ou incomplètes, des solutions non justifiées ou non validées, une communication entre acteurs non maîtrisée. Pour tenter de résoudre ces problèmes, l’ingénierie système (définition 1.2) a été développée afin de répondre aux besoins de compréhension et de maîtrise de ces systèmes. Elle s’applique dans divers domaines industriels : aérospatial, télécommunications, systèmes d’informations, transports, etc.
Définition 1.2 (Ingénierie Système [IEE99] )
L’ingénierie système est une démarche méthodologique coopérative et interdisciplinaire englobant l’ensemble des activités pour concevoir, développer, faire évoluer et vérifier un système et apportant une solution optimisée pour le système équilibrée sur l’ensemble de son cycle de vie, satisfaisant aux attentes d’un client et acceptables par tous.
Les méthodes de l’ingénierie système reposent sur des approches de modélisation, de vérification et de simulation pour valider les exigences et évaluer les solutions tout au long du processus. Il ne s’agit pas ici de décrire de manière exhaustive l’ingénierie système, plus de précisions pourront être trouvées dans [Meinadier98, Incose06]. L’intérêt de sa mise en œuvre est particulièrement visible dans les phases amont de spécification et de conception du système puisque la plus grande partie du coût global de développement d’un système provient de décisions prises lors de ces phases. Les principales activités inhérentes à une démarche système sont de tracer les exigences, de justifier les choix, de vérifier et valider tous les résultats.
Selon l’AFIS (Association Française de l’Ingénierie Système), Le cycle de vie d’un système est l’ensemble des phases par lesquelles passe le système depuis l’émission des besoins qui le concerne jusqu’à son retrait du service. Ainsi, il se compose des phases de conceptualisation, de conception, de réalisation, d’intégration, d’exploitation et enfin de retrait de service [Afis07]. Nous décrivons plus précisément les cycles de développement et leur intérêt dans la section suivante.
Cycles de développement
Le processus de développement d’une solution peut être découpé en différentes phases ; ainsi, un cycle de développement est un enchaînement d’activités comprenant les méthodes et les outils utilisés. L’objectif de ce découpage est de définir des jalons tout au long du processus de conception : en effet, plus une erreur est détectée tardivement, plus son coût risque d’être élevé. Par conséquent, il convient de détecter et de corriger au plus tôt ses erreurs. Par exemple, la méthode du cycle en V (figure 1.1) est couramment utilisée dans les grandes industries française, notamment dans le domaine ferroviaire [Boulanger06]. Dans ce modèle, la partie descendante correspond aux activités de conception, menant à la réalisation du système ou du logiciel, alors que la partie remontante est liée aux aspects de vérification et de validation. Le développement se fait par étapes, et chaque étape de conception est mise en correspondance avec une étape de validation. Le cycle en V propose donc un cadre structurant le processus d’automatisation. Cependant, il est difficile en pratique de dissocier ces différentes phases. Il est courant de se rendre compte d’erreurs ou d’incohérences dans les spécifications initiales seulement au moment de l’implantation. De plus, de telles erreurs détectées tard dans le cycle entraînent la plupart du temps de grandes pertes en terme de temps ou de moyens financiers. Cette méthode illustre bien la nécessité de construire pas à pas le système en précisant de manière de plus en plus fine la solution choisie correspondant aux spécifications initiales. Nous pouvons également évoquer d’autres cycles de développement utilisés dans l’industrie : la méthode du cycle de développement en cascade [Royce70] ou en spirale [Boehm88]. En conclusion de cette section nous tenons à souligner qu’il est nécessaire de détecter les erreurs au plus tôt dans le processus de conception. Dans cette optique, l’utilisation de méthodes formelles permet d’obtenir un système validé par construction. Enfin, le découpage du processus de conception en différentes phases en fonction de l’objectif visé nous semble indispensable et motive le fait d’utiliser différents modèles complémentaires.
Types de modèles et niveaux de description d’un système
Nous l’avons vu dans les sections précédentes, il existe plusieurs types de modèles en fonction du contexte ou de l’objectif voulu par le concepteur. Dans ce cadre, il est nécessaire de définir plusieurs niveaux de description d’un système en fonction de l’étape que l’on souhaite réaliser au sein de ce processus de développement :
– les besoins et les exigences des usagers,
– un ensemble de solutions possibles,
– une solution particulière,
– la structure interne de la solution choisie, la description des diverses modules,
– des algorithmes/machines/raffinements utilisés par chaque module,
– le code final.
Il existe donc différents types de modèles utilisés tout au long de ce cycle de développement. Une typologie de ces différents types en fonction de leur objectif et de leur usage est proposée par la méthode d’analyse et de conception Sagace [Penalva99] développée à partir de 1993 au centre à l’énergie atomique (C.E.A.). Cette démarche consiste à observer le système depuis différents angles et en plusieurs étapes. L’apport central de cette méthode est une matrice de points de vue de modélisation, proposant trois visions possibles du système (fonctionnelle, organique et opérationnelle) et trois perspectives temporelles d’étude (figure 1.2). Nous précisons les trois différentes visions du système :
– la vision fonctionnelle représente ce que fait le système par rapport à son environnement ;
– la vision organique représente ce qu’est le système ;
– la vision opérationnelle représente ce que décide le système pour remplir la mission.
Nous nous inspirons de cette méthode pour définir différents modèles en fonction de l’objectif que l’on souhaite atteindre et de la phase que l’on traite dans le processus de développement (figure 1.3) . Afin de réaliser un système conforme aux besoins énoncés dans le cahier de charges, il est nécessaire de décrire ce que le système doit satisfaire au sein d’un modèle dit prescriptif. Ce modèle peut être décrit sous la forme d’exigences, que l’on peut séparer en exigences fonctionnelles (ce que doit faire le système) et non-fonctionnelles (performance, fiabilité, sécurité..). Par exemple, dans le cadre de ce travail, la spécification des systèmes soumis à des exigences de sécurité doit clairement identifier ce qui ne doit pas arriver. La conception d’un système a pour objectif la construction d’un modèle dit constructif décrivant une solution répondant aux exigences auxquelles le système doit répondre. Ce modèle permet de représenter un système en mettant en évidence les propriétés souhaitées. Ensuite, il est nécessaire de construire des modèles prospectifs dont l’objectif est de déduire le comportement du système dans des situations nouvelles à partir d’un état connu. Ces modèles sont de deux types :
1. Modèles formels : capables de prévoir, de valider, de prouver des comportements;
2. Modèles analytiques : permettant l’estimation de performance, l’analyse de la sûreté de fonctionnement, la simulation.
De plus, nous pouvons citer [Chapurlat07] qui insiste sur l’importance du rôle du modeleur dans le processus de conception :
– La modélisation est tout d’abord guidée par l’objectif souhaité par le modeleur : construire un modèle de simulation, de pilotage, de contrôle..,
– elle est ensuite rendue possible par la maîtrise qu’a le modeleur des outils et des méthodes utilisées. Enfin, cette méthode s’appuie sur un ensemble de modèles purement descriptifs se basant sur un langage de modélisation souple, intuitif, proche du langage naturel mais insuffisant dans notre contexte de travail. Dans le chapitre 3 nous justifions les langages que nous avons choisi pour décrire un processus de conception de systèmes critiques ferroviaires. De plus, de notre point de vue, lorsque l’on représente les exigences contenues dans le cahier des charges, il faut être attentif à ne pas pré-sélectionner a priori une solution, notamment parce que cela pourrait entraîner l’exclusion de solutions alternatives.
Types de propriétés
Nous avons expliqué dans la section précédente l’intérêt d’utiliser différents types de modèles durant le processus de conception. Ces modèles permettent de vérifier différentes propriétés en fonction de l’objectif à atteindre. Nous présentons donc ici différents types de propriétés (définition 1.3) à spécifier et à vérifier lors de la conception d’un système complexe.
Définition 1.3 (propriété)
Une propriété est une qualité propre, une caractéristique intrinsèque (fonctionnelle, comportementale, structurelle ou temporelle) que doit posséder un système. Une propriété traduit une attente, une exigence, une finalité à laquelle l’entité doit répondre [Chapurlat07]. D’abord, les propriétés peuvent être statiques. Elle permettent dans ce cas d’assurer la cohérence du système. Dans les approches basées sur les transitions d’états, elles sont spécifiées sous la forme d’invariants ou de garde sur les opérations. Elles caractérisent plus particulièrement les architectures du système. Ensuite, une propriété est dite dynamique si elle traite de l’occurrence ou de l’ordonnancement des événements. Nous pouvons ici référer à la section 3.1 où sera justifié le choix des outils utilisés dans notre travail ; les réseaux de Petri serviront l’étude des propriétés dynamiques du système alors que la méthode B est envisagée pour vérifier ses propriétés statiques.
|
Table des matières
Introduction générale
1 Conception de systèmes ferroviaires
1.1 Modélisation de systèmes complexes
1.1.1 Pourquoi modéliser ?
1.1.2 Ingénierie système
1.1.3 Cycles de développement
1.1.4 Types de modèles et niveaux de description d’un système
1.1.5 Types de propriétés
1.1.6 Système à événements discrets
1.1.7 Systèmes à contraintes temporelles
1.1.8 Systèmes critiques
1.1.9 Sureté de fonctionnement
1.2 Le contexte ferroviaire
1.2.1 Introduction au transport ferroviaire
1.2.2 Sécurité des systèmes ferroviaires
1.2.3 Politique de transport ferroviaire européenne
1.2.4 Contexte normatif et législatif
1.2.5 Certification des systèmes de sécurité ferroviaire
1.3 Bilan sur la conception de système ferroviaires critiques
2 Méthodes utilisées pour garantir la sécurité des systèmes
2.1 Ingénierie des exigences
2.1.1 Propriétés, exigences et spécifications
2.1.2 Élicitation des exigences
2.1.3 Caractéristiques des exigences
2.1.4 Analyse et formalisation
2.1.5 Traçabilité
2.1.6 Un outil pour la gestion des exigences : SysML
2.2 Spécifications formelles
2.2.1 Langages semi-formel ou formel ?
2.2.2 Méthodes formelles
2.2.3 Validation, vérification et certification
2.3 Ingénierie dirigée par les modèles
2.3.1 Concepts de base de l’IDM
2.3.2 Règles de transformation
2.3.3 Hiérarchisation de modélisation
2.4 Bilan : méthodes et techniques de la conception système
3 Modèles utilisés pour l’analyse des systèmes critiques
3.1 Introduction sur les langages formels : Choix de deux modèles complémentaires
3.2 Les réseaux de Petri
3.2.1 Le modèle élémentaire
3.2.2 Les réseaux de Petri et le temps
3.2.3 Choix des extensions temporelles en fonction du niveau de modélisation
3.3 La méthode B
3.3.1 Historique et applications industrielles
3.3.2 Fondements
3.3.3 Extensions : méthode B et temporalité
3.4 Conclusion
4 Modélisation et validation des exigences temporelles
4.1 Vers une méthodologie de conception prenant en compte les exigences temporelles
4.2 Construction et synthèse de contrôle d’un modèle des exigences
4.2.1 Méthodes de supervision des SED temporisés
4.2.2 Synthèse de contrôleur par analyse d’un automate associé
4.2.3 Analyse structurelle d’un graphe d’événement
4.2.4 Exemple applicatif : un atelier
4.2.5 Discussion sur les méthodes de synthèse de commande
4.3 Projection de classes d’états pour la vérification d’une solution
4.3.1 Le concept de classe d’état
4.3.2 Analyse énumérative d’un réseau p-temporel
4.3.3 Analyse énumérative d’un réseau t-temporel
4.3.4 Validation du modèle de solution par projection des classes d’états
4.3.5 Exemple illustratif
4.4 Conclusion
Conclusion générale
