Ingénierie système et Sûreté de fonctionnement

Les systèmes produits par l’industrie deviennent de plus en plus complexes. Pour pallier à cette complexité, les différentes disciplines d’ingénierie, qui contribuent à leur conception (mécanique, hydraulique, thermique, électrique et électronique, software, hardware, middleware, …), virtualisent le contenu de leurs études au travers de modèles. Nous sommes entrés dans l’ère de l’ingénierie dirigée par les modèles [1]. De plus en plus utilisés, les modèles servent de support pour communiquer, pour calculer ou pour générer du logiciel embarqué.

Encore aujourd’hui, les disciplines d’ingénierie sont organisées en « silos ». Chacune utilise ses propres cadres mathématiques, concepts et méthodes. Les processus suivis sont spécifiques aux objectifs techniques et aux résultats attendus. Cette diversité se retrouve dans les modèles utilisés. Ces derniers sont conçus à l’aide de langages de modélisation différents (par exemple SysML [2], EAST-ADL [3], AUTOSAR [4], AADL [5], Simulink , Modelica , etc.), à des niveaux d’abstraction différents et avec des objectifs d’études différents. À une étape donnée du processus de conception, ils peuvent aussi présenter des niveaux de maturité très différents. En un mot, ils sont hétérogènes [6]. Cela peut amener les différents acteurs à avoir des visions divergentes, voire contradictoires du système en cours de conception.

LES DISCIPLINES D’INGENIERIE 

La thèse se focalise sur l’architecture système et la sûreté de fonctionnement qui jouent, toutes les deux, un rôle majeur tout au long du cycle de développement des systèmes et qui ont de fortes dépendances avec les autres disciplines d’ingénierie. L’architecture système définit, entre autres, la manière dont les composantes (fonctions, composants physiques, logiciels, etc.) du système sont architecturées, i.e. organisées et assemblées [8]. Elle s’appuie sur des représentations structurelles du système. Ces représentations caractérisent « l’architecture du système ». Pour les construire et les faire évoluer, l’architecture système interagit avec d’autres disciplines. La sûreté de fonctionnement détermine et évalue les critères de fiabilité, de maintenabilité, de disponibilité et de sécurité du système en tenant compte de son architecture et du comportement de ses composantes [9]. Pour mener ces études, la sûreté de fonctionnement interagit avec l’architecture système et des disciplines techniques (mécaniques, électrique, pyrotechnique, etc.).

Ces deux disciplines d’ingénierie présentent une grande complémentarité. L’une propose une architecture du système et l’autre est chargée d’évaluer la sûreté de fonctionnement du système en tenant compte de la proposition d’architecture. Aujourd’hui, les interactions et les échanges entre ces deux disciplines sont informels. Ils s’effectuent au travers de réunions d’avant-projet ou de réunions de suivi, de lectures documentaires ou parfois de mécanismes de retranscription. Ces mécanismes s’effectuent généralement manuellement ou par le biais de passerelles (transformation de modèles [10]) spécifiques à un domaine industriel [11]. Ces interactions non formalisées posent de nombreux problèmes, compte tenu des risques d’incohérence entre les modèles d’un même système, dont les principaux sont :

– Le temps important et la duplication des efforts pour comprendre ce que le système doit faire et doit être ;
– Les difficultés de communication liées au vocabulaire utilisé pour désigner des concepts différents ou a contrario les mêmes concepts pouvant être désignés par des termes différents ;
– Les erreurs humaines dans la retranscription de l’information ;
– Les difficultés à retranscrire l’information contenue dans un modèle à un autre.

D’où l’intérêt de proposer de nouvelles approches collaboratives permettant d’améliorer les interactions entre ces deux disciplines d’ingénierie, tout en conservant une séparation des préoccupations.

LES MECANISMES DE SYNCHRONISATION DE MODELES 

Les disciplines d’ingénierie ont besoin de collaborer pour échanger et se mettre d’accord sur leurs objectifs. Idéalement, leurs interactions devraient s’appuyer sur une comparaison des modèles qu’elles produisent. Cependant, cette comparaison est en pratique très difficile, voire impossible à réaliser, en raison de l’hétérogénéité des modèles. L’idée de la synchronisation de modèles est donc de mettre en œuvre des mécanismes permettant d’abstraire les modèles dans un formalisme commun, d’en étudier la cohérence à ce niveau d’abstraction, puis d’en restituer les résultats dans chaque modèle source.

La synchronisation de modèles est donc une démarche en trois étapes. Tout d’abord, une étape d’abstraction permettant d’extraire les informations pertinentes des modèles considérés. Ensuite une étape de comparaison des abstractions ainsi obtenues. Enfin une étape de concrétisation permettant de réinjecter des propositions d’aménagement issues des résultats de la comparaison vers les modèles originaux.

VERROUS SCIENTIFIQUES

L’approche proposée est à la fois pragmatique et originale. Elle demande de lever plusieurs verrous scientifiques et technologiques importants :
– Il faut appréhender le déroulement des processus de chaque discipline tout au long du cycle de développement du système et intégrer ces visions locales en une vision globale, dans le cadre particulier de l’entreprise ou du cas d’étude considéré.
– Il faut définir précisément les mécanismes de synchronisation de modèles dans le cadre particulier de l’entreprise ou du cas d’étude considéré.
– Il faut proposer une démarche de mise en œuvre de la synchronisation de modèles adaptée au contexte de l’entreprise ou du cas d’étude considéré.
– Il faut outiller cette démarche, ou en tout cas préciser ce que pourrait être à terme un outillage de cette démarche.

L’INGENIERIE SYSTEME

ORIGINES

Les institutions de la défense américaine : la NASA (National Aeronautics and Space Administration) et l’USAF (United States Air Force) ont été les premières à s’intéresser à l’ingénierie des systèmes [12]. Dans les années 60, elles ont tenté d’organiser le développement des programmes militaires et spatiaux (programme Apollo) à partir d’approches industrielles plus rationnelles. Les années 70 et 80 voient une fulgurante avancée de l’informatique dans le pilotage des systèmes technologiques et parallèlement un net recul de l’ingénierie système [13]. Alors que le métier du logiciel s’organise et définit des méthodes du génie logiciel, la méthodologie du métier “système” stagne jusque dans les années 90. Les constats d’échecs techniques ou économiques (l’inefficacité des systèmes de commandement durant les guerres, les pertes de satellites et l’explosion de navette spatiale) mettent en évidence des défauts d’origine systémique [12] (besoins peu exprimés, spécifications imprécises, solutions non justifiées ou non validées, confusion de responsabilités entre client et maîtrise d’œuvre …). En 1991, l’International Council On System Engineering (INCOSE) est créé. Cette organisation capitalise et diffuse les activités intellectuelles et l’échange des bonnes pratiques pour le développement de systèmes complexes nécessitant l’interaction de plusieurs disciplines. Aujourd’hui, l’INCOSE poursuit ses actions et tente de répondre à de nombreuses problématiques autour de l’ingénierie des systèmes. Elle a notamment publié le document SE Handbook [14]. L’Association Française de l’Ingénierie Système (AFIS), fondée en 1998, travaille avec l’INCOSE pour diffuser les travaux d’ingénierie système en France et faire remonter également les résultats de groupes de travail au niveau national ou international. L’INCOSE et l’AFIS entretiennent la mise à jour du SE Handbook [14] et du SEBoK [15] (Systems Engineering Body of Knowledge).

PRESENTATION

Plusieurs communautés scientifiques, normatives et industrielles proposent des définitions différentes de l’ingénierie système (ou ingénierie de systèmes). C’est le cas de celles proposées par l’AFIS [16] et l’INCOSE [14]. Ces différences entrainent des confusions entre l’ingénierie système (le cadre des études) et la conception système (les activités réalisées par les disciplines d’ingénierie). Nous proposons donc la définition suivante :

L’ingénierie système est un cadre qui englobe l’ensemble des activités des disciplines d’ingénierie. Ce cadre multidisciplinaire définit les périmètres des études des disciplines. Son but est de favoriser la réalisation d’un système performant comme solution finale aux besoins d’un client, tout en satisfaisant les parties prenantes.

Une partie prenante (« stakeholder ») est un acteur, individuel ou collectif (groupe ou organisation), activement ou passivement concerné par une décision ou un projet, i.e. dont les intérêts peuvent être affectés positivement ou négativement à la suite de son exécution (ou de sa non-exécution).

L’architecture système et la sûreté de fonctionnement interviennent fortement dans les activités de conception, d’évolution et de vérification d’un système. Elles font partie du cadre d’ingénierie système. Cependant, ni le cadre, ni les référentiels métiers des disciplines (présentés plus tard) ne définissent précisément avec qui, quoi et quand conduire les interactions entre ces disciplines. De plus, la sûreté de fonctionnement n’est pas toujours mentionnée dans les cours et les ouvrages d’ingénierie système [12]. Depuis plusieurs dizaines d’années, les différentes disciplines d’ingénierie conçoivent des modèles. Ces modèles doivent être pris au sérieux et considérés comme l’objet central des problématiques scientifiques des disciplines d’ingénieries.

NATURE ET FINALITE DES MODELES DE SYSTEME

La nature d’un modèle dépend du cadre utilisé : mathématique, informatique (langage, algorithme) ou graphique (représentation structurelle ou comportementale). Le concepteur de modèles choisit ce cadre en fonction du résultat recherché et des moyens possibles pour y parvenir.

Modèle (en ingénierie système) [8] : C’est une abstraction d’un système réel ou étudié. Il s’appuie sur un cadre mathématique adapté à un ensemble d’objectifs et un ensemble de vues, i.e. des représentations définies par un point de vue.

Un langage de modélisation (ou métamodèle) spécifie la sémantique et la ou les syntaxe(s) permettant de construire des modèles.

Syntaxe : La syntaxe est, à l’origine, la branche de la linguistique qui étudie la façon dont les mots se combinent pour former des phrases ou des énoncés dans une langue. En informatique, la syntaxe définit des règles d’agencement des lexèmes (en informatique, ce sont des entités lexicales d’un langage informatique) en des termes plus complexes, souvent des programmes. Ces règles permettent de définir des expressions bien formées et de décider du respect, ou du non respect, de la grammaire formelle d’un langage.

Sémantique : C’est une branche de la linguistique qui étudie les signifiés, ce dont on parle, ce que l’on veut énoncer. En informatique comme en linguistique, la sémantique désigne le lien entre un signifiant, le programme, et un signifié, l’objet mathématique qui dépendra des propriétés que l’on souhaite connaître du programme.

En analysant les différents types de modèles qui permettent de représenter un système complexe, on peut constater qu’ils sont généralement conçus pour répondre à trois principaux objectifs :
– Des modèles pour présenter. Ils sont principalement employés pour construire des idées et communiquer avec des acteurs humains ayant des préoccupations particulières;
– Des modèles pour calculer. Ils sont principalement employés pour calculer des indicateurs ou simuler le comportement d’un système ;
– Des modèles pour générer. Ils sont employés pour construire une solution implémentée. Pour le logiciel, on parle de génération de code et pour des composants physiques, on parle de fabrication additive.

Table des matières

INTRODUCTION
1. OBJECTIFS DES TRAVAUX
2. LES DISCIPLINES D’INGÉNIERIE
3. LES MÉCANISMES DE SYNCHRONISATION DE MODÈLES
4. VERROUS SCIENTIFIQUES
5. CONTRIBUTIONS
6. LISTE DES PUBLICATIONS
7. PLAN DE LA THÈSE
CHAPITRE I L’ARCHITECTURE SYSTÈME, LA SÛRETÉ DE FONCTIONNEMENT ET LEURS INTERACTIONS
1. L’INGÉNIERIE SYSTÈME
1.1. Origines
1.2. Présentation
1.3. Nature et finalité des modèles de système
1.4. Problèmes multidisciplinaires
2. L’ARCHITECTURE SYSTÈME
2.1. Origines
2.2. Missions de l’architecture système
2.3. Taxonomie et paradigme de structuration
2.4. Méthodes
2.5. Normes
2.6. Les logiciels
2.7. Les langages de modélisation
2.7.1. Les langages génériques
2.7.2. Les langages spécialisés
3. ANALYSES DE SÛRETÉ DE FONCTIONNEMENT
3.1. Historique
3.2. Missions des études de sûreté de fonctionnement
3.3. Taxonomie
3.4. Méthodes
3.5. Normes
3.6. Les logiciels
3.7. Les langages de modélisation MBSA
4. INTERACTIONS MULTIDISCIPLINAIRES
4.1. Approche orientées
4.2. Approche collaboratives MBSE et MBSA
4.3. Travaux connexes
4.3.1. Les ontologies
4.3.2. Regles de cohérence avec UML
4.3.3. Tissage de modèles
4.4. Positionnement des travaux de thèse
CHAPITRE II CADRE CONCEPTUEL DE SYNCHRONISATION DE MODÈLES
1. PÉRIMÈTRE DU CADRE CONCEPTUEL
1.1. Parties prenantes du processus de conception
1.2. Etapes du processus de synchronisation
1.3. Processus de conception et fonctions de synchronisation
2. DÉFINITION DES DISCIPLINES D’INGÉNIERIE
2.1. Concepts d’architecture et de modèle
2.2. Concepts d’un contexte des disciplines d’ingénierie
2.3. Modélisation des concepts
2.3.1. Métamodèle d’une activité
2.3.2. Métamodèle d’un contexte d’une discipline d’ingénierie
2.3.3. Metamodèle d’un besoin de synchronisation
3. DEFINITION DES CONCEPTS D’ARCHITECTURE
3.1. Concepts pivots de modèlisation d’architecture
3.2. Modélisation des concepts
3.2.1. Déclinaisons des éléments
3.2.2. Relations de structuration
3.2.3. Metamodèle pivot, une combinaison d’elements et de relations de structuration
3.2.4. Ordonnancement des concepts pivots d’architecture
4. CONFIGURATION DES INTERACTIONS MULTIDISCIPLINAIRES
4.1. Concepts d’un point de synchronisation
4.2. Modélisation des concepts
4.2.1. Métamodèle d’un point de synchronisation
4.2.2. Dépendance du besoin et des points de synchronisation
4.2.3. Ordonnancement des points de synchronisation
5. MISE EN COHÉRENCE
5.1. Concepts de mise en cohérence
5.2. Représentation graphique d’une relation de cohérence
6. APPLICATION DE LA SYNCHRONISATION DE MODÈLES
6.1. Concepts de synchronisation
6.2. Modélisation d’une application de synchronisation
6.2.1. Execution de l’application
6.2.2. Fonctions, entrées et sorties des étapes de synchronisation
6.2.3. Dépendance de l’application et du point de synchronisation
6.3. Transformation de modèles
6.3.1. Introduction
6.3.2. Technique d’abstraction
6.3.3. Technique de concrétisation
6.4. Comparaison de modèles
7. TRAÇABILITÉ ET HISTOIRES DES MODÈLES
7.1. Introduction et concepts de la traçabilité
7.2. Modélisation des concepts
8. METHODOLOGIE DE SYNCHRONISATION DE MODÈLES
8.1. Concepts méthodologiques
8.2. Principes de synchronisation
8.3. Modélisation d’un méthodologie de synchronisation
8.4. Modélisation des principes de synchronisation
CHAPITRE III PROPOSITION D’UNE MÉTHODOLOGIE DE SYNCHRONISATION DE MODÈLES
1. INTRODUCTION GÉNÉRALE
1.1. Objectif
1.2. Architecture d’entreprise
1.3. Proposition méthodologique
1.4. Exemples d’application
2. ACTIVITÉ DE DÉFINITIONS DES PRINCIPES D’INTERACTIONS
2.1. Objectif
2.2. Méthodes
2.2.1. Choix des disciplines d’ingénierie
2.2.2. Définition opérationnelle du projet de synchronisation
2.2.3. Etat actuel des interactions et les problèmes observés
2.2.4. Définition de l’état cible
2.2.5. Evaluation de l’adéquation du besoin avec l’approche
2.2.6. Etudes complémentaires
2.3. Exemples d’application
3. ACTIVITÉ DE DÉFINITION DES CONTEXTES DES DISCIPLINES D’INGÉNIERIE
3.1. Objectif
3.2. Méthodes
3.2.1. Définition des contextes d’ingénierie
3.2.2. Définition des besoins de synchronisation
3.3. Exemples d’application
4. ACTIVITÉ DE CONFIGURATION DE SYNCHRONISATION
4.1. Objectif
4.2. Méthode de formalisation des points de synchronisation
4.3. Exemples d’application
CONCLUSION

Lire le rapport complet