Intégration de la Sûreté de Fonctionnement dans les Processus d’Ingénierie Système
Triptyque exigences-solutions-V&V, principe de bonne conception
Au sujet de notre modèle d’information, dont l’utilité a été justifiée ci-dessus, nous souhaitons qu’il respecte un principe de bonne conception provenant des autorités de sûreté (voir [Albinet & al., 2008]). En effet, celles-ci imposent une séparation des concepts manipulés lors de la conception du système. Les exigences, la solution de conception et les données concernant la V&V doivent être développées indépendamment. On fait d’ailleurs référence au triptyque exigences-solutions-V&V. Il faut donc pouvoir distinguer très clairement ces différents concepts. Cette distinction peut être retrouvée dans des normes, par exemple dans la norme ISO-26262 , adaptation prochaine de l’CEI au domaine de l’automobile. Afin d’illustrer ce discours, la Figure IV.15 présente ce qui ne doit pas être fait (à gauche) et ce qu’il convient de faire (à droite). Or, le premier cas (celui de gauche) présente tout de même un avantage non-présent dans le second. Il permet d’attacher directement les exigences aux éléments de solutions, par exemple en restant dans le même formalisme. L’avantage du second cas, quant à lui, est clair. Il permet une gestion efficace de chaque concept, appuyée par des outils spécifiques. Ceci étant, le problème de cette approche est que les exigences sont gérées de façon externe au processus de modélisation de la solution. Il ne facilite donc pas la compréhension et la revue des exigences par rapport aux équipes de développement de la solution. Nous verrons que notre approche va, tout en respectant la séparation des concepts prévue par les autorités de sûreté, s’inspirer des deux cas précédents pour intégrer les deux avantages.
Modèle proposé
Dans cette section, nous présentons tout d’abord le langage SysML (System Modeling Language). Ensuite, nous détaillons quelques points particuliers de ce langage, notamment concernant les relations liées aux exigences. Puis nous justifions le choix de SysML pour le modèle d’information que nous proposons [Guillerm & al., 2010c] et nous exposons nos extensions du langage. La présentation de notre modèle d’information clôt la section.
Le langage choisi : SysML
SysML [Bock, 2006] est à l’ingénierie des systèmes complexes et/ou hétérogènes ce qu’UML est à l’informatique. Il doit permettre à des acteurs de corps de métiers différents de collaborer autour d’un modèle commun pour définir un système. La conception de système donne souvent lieu à une accumulation de documentations qui doivent toutes être croisées et mises à jour pour maintenir la cohérence et respecter les spécifications du système. SysML est un moyen de regrouper dans un modèle commun à tous les corps de métiers, les spécifications, les contraintes, et les paramètres de l’ensemble du système. SysML n’aborde plus la conception avec la notion de classes mais avec la notion de blocs qui deviendront des parties mécaniques, électroniques, informatiques ou autres. SysML (System Modeling Language) est donc : Un langage de modélisation visuel pour l’Ingénierie Système. Compatible avec UML pour l’Ingénierie Logicielle. Ce qui est parfaitement logique, puisque SysML est un DSL (Domain Specific Language) d’UML pour le « Système », c’est-à-dire une adaptation d’UML. Un support à la spécification, l’analyse, le design, la vérification et la validation d’un large panel de systèmes et de « systèmes de systèmes ». Ces systèmes pouvant inclure du matériel, du logiciel, de l’information, des processus, du personnel et des services.
Historique
Voici un bref historique des méthodes, techniques ou langages de conception qui ont permis d’arriver jusqu’à SysML, en passant évidemment par le langage UML (cf. Figure IV.16) : Dans les années 1970, les premières méthodes d’analyse pour la conception système apparaissent. Les années 1980 annonce l’approche systémique, avec la modélisation des données et modélisation des traitements : Merise [Redouin, 1989], Axial, IE… Entre 1990 et 1995, il y a une véritable émergence d’une multitude de méthodes orientée-objets : Booch [Booch, 1993], Classe-Relation, Fusion, HOOD, OMT [Rumbaugh & al., 1990], OOA, OOD, OOM, OOSE [Jacobson, 1992] … L’année 1995 marquera les premiers consensus, tels qu’OMT (James Rumbaugh), OOD (Grady Booch) ou OOSE (Ivar Jacobson). Les années 1995 à 1997 voit les premiers pas pour l’unification et la normalisation des méthodes avec la naissance d’UML. Ainsi, UML (Unified Modeling Language) est né de la fusion des 3 méthodes qui ont le plus influencé la modélisation orientée objets au milieu des années 90 : OMT (Object Modeling Technique). Méthode d’analyse et de conception orientée objets. Vues statiques, dynamiques et fonctionnelles d’un système. OOD (Object Oriented Design). Vues logiques et physiques du système. OOSE (Object Oriented Software Engineering). Couvre tout le cycle de développement. Une des plus anciennes méthodes objet focalisée sur le modèle statique. Fin 1997, UML devient un standard OMG (Object Management Group). L’OMG est un organisme à but non lucratif, créé en 1989 à l’initiative de grandes sociétés (HP, Sun, Unisys, American Airlines, Philips…). Son rôle est de promouvoir des standards qui garantissent l’interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes. Puis UML s’améliore et s’enrichit progressivement pour atteindre la version UML 2.0 en 2004. Finalement, suite aux premières prémisses d’un langage spécifique à l’ingénierie système dès 2001, c’est en 2005 qu’une première version de SysML voit le jour.
Présentation
SysML est une adaptation d’UML 2 pour l’ingénierie système. Plus précisément, SysML réutilise une partie d’UML, appelée UML4SysML (interpréter « UML for SysML »), à laquelle est ajoutée une extension (voir Figure IV.17). Figure IV.17 : Construction de SysML à partir d’UML .Pour définir SysML [Bock, 2005], 6 diagrammes ont été retirés des 13 diagrammes d’UML. Il s’agit des diagrammes de composants, d’objets, de déploiement, de vue d’ensemble des interactions et de temps, qui sont trop orientés pour le monde logiciel ou qui n’apporteraient rien de significatif à l’ingénierie système. Par ailleurs, 2 diagrammes ont été renommés : le diagramme de classes est remplacé par le diagramme de définition de blocks et le diagramme de structure composite devient le diagramme de blocks internes. La notion de classe, sur laquelle on pouvait s’appuyer pour créer des instances (c’est-à-dire des objets), n’a pas été reprise pour le domaine de l’ingénierie système, où celle-ci est substituée par la notion de block. Ainsi, un système ou un composant sont définis par des blocks en SysML. Le diagramme d’activité a subi quelques modifications et le diagramme paramétrique a été ajouté pour définir les relations entre les grandeurs physiques du système. Le dernier point, certainement l’innovation majeure de SysML, est le diagramme des exigences qui voit le jour. Il permet d’introduire les exigences systèmes dans le modèle, avec un certain nombre de liens de traçabilité rendu possible entre des exigences ellesmêmes ou entre des exigences et d’autres éléments de modélisation. La Figure IV.18 résume ce paragraphe traitant de l’ensemble des diagrammes offerts par SysML
Table des matières
Introduction Générale
Chapitre 1 : Ingénierie des systèmes complexes et sûreté de
fonctionnement
1. Introduction
2. Systèmes complexe
2.1. Définition d’un système
2.2. Complexité .
2.3. Propriétés émergentes
3. Ingénierie Système
3.1. Historique et définition
3.2. Cycle de vie et cycle de développement
3.3. Approche générale de conception des systèmes
3.4. Ingénierie des exigences
3.4.1. Définition d’une exigence
3.4.2. Rôle et intérêt de l’ingénierie des exigences
3.4.3. Expression des exigences
3.4.4. Traçabilité
3.4.5. Changement d’exigences
3.4.. Quelques outils d’ingénierie des exigences
3.5. Gestion des risques
3.5.1. Définition d’un risque
3.5.2. Pourquoi s’intéresser aux risques ?
3.5.3. Etapes de la gestion des risques
3.5.4. Stratégies de la gestion des risques
3.5.5. Outils de la gestion des risques
3.5.. Synthèse
4. Sûreté de fonctionnement
4.1. Historique
4.2. Concepts et définitions
4.3. Quelques méthodes de sûreté de fonctionnement
4.4. Enjeu de la sûreté de fonctionnement
5. Sûreté de fonctionnement des systèmes complexes
5.1. Exemples d’échecs
5.1.1. Navette spatiale Challenger
5.1.2. Ariane 5
5.1.3. Mars Polar Lander
5.1.4. Plate-forme pétrolière BP
5.2. Origines des problèmes de sûreté de fonctionnement
5.3. Nécessité d’une approche globale
. Conclusion
Chapitre 2 : Démarche processus proposée
1. Introduction
2. Etat de l’art pour une conception de systèmes sûrs
2.1. Normes de Sûret
2.1.1. CEI-0 et ses dérivées
2.1.2. ARP-
2.1.3. ARP-
2.2. Quelques projets
2.2.1. SQUALE
2.2.2. ESACS
2.2.3. ISAAC
2.2.4. ASSERT
2.3. Autres travaux de recherche
2.3.1. Modèle de développement à sûreté de fonctionnement explicite
2.3.2. Méthodologie d’IS basée sur les modèles et guidées par la SdF
2.4. Synthèse
3. Processus et normes d’Ingénierie Systèm
3.1. Vision processus
3.2. Normes d’Ingénierie Système (IEEE-20, EIA-32, ISO-2)
3.3. Paradigme processus-méthodes-outils
3.4. EIA-32
3.4.1. Historique et généralité
3.4.2. Interaction entre les différents processus
3.4.3. Les 33 sous-processus de l’EIA-32
3.4.4. Structure d’un système selon l’EIA-32
3.4.5. Vision des exigences de l’EIA-32
4. Approche globale proposée
4.1. Principe d’intégration de la SdF
4.2. Les processus de conception système
4.2.1. Le processus de définition des exigences
4.2.2. Le processus de définition de la solution
4.3. Les processus d’évaluation technique
4.3.1. Le processus d’analyse des systèmes
4.3.2. Le processus de validation des exigences
4.3.3. Le processus de vérification du système
5. Conclusion
Chapitre 3 : Méthodologie de déclinaison d’exigences de sûreté de fonctionnement
1. Introduction
2. Déclinaison d’exigences de sûreté de fonctionnement
2.1. Pourquoi cette déclinaison ?
2.2. Déclinaison vis-à-vis des processus d’ingénierie système
3. Travaux sur la déclinaison d’exigences de sûreté de fonctionnement
3.1. Travaux de Peter Lindsay, John McDermid et David Tombs
3.2. Travaux de Tim Kelly et al1
4. Présentation de la méthodologie
4.1. Aperçu de la méthodologie
4.2. Méthodes utilisées
4.2.1. AMDEC
4.2.2. Arbre de défaillances
4.3. Méthodologie de déclinaison
4.3.1. Etape 1 : Analyse des défaillances du système
4.3.2. Etape 2 : Analyses des causes des défaillances
4.3.3. Etape 3 : Analyses des défaillances des sous-systèmes
4.3.4. Etape 4 : Synthèse
5. Formalisation UML
5.1. Formalisation de l’AMDEC
5.2. Formalisation de l’Arbre de Défaillances
5.3. Formalisation de la méthodologie complète
. Cas d’étude
.1. Présentation de l’exemple
.2. Application de la méthodologie
.2.1. Etape 1 : Analyse des défaillances du système
.2.2. Etape 2 : Analyses des causes des défaillances
.2.3. Etape 3 : Analyses des défaillances des sous-système
.2.4. Etape 4 : Synthès
.3. Utilisation de la formalisation UML
. Bilan de la méthodologie et complément
. Conclusion
Chapitre 4 : Vers une méthodologie ISBM.
1. Introduction
2. Modèle d’information et ISBM
2.1. Ingénierie Système Basée sur les Modèles (ISBM)
2.2. Définition d’un modèle d’information
2.3. Intérêt d’un modèle d’information
2.3.1. Appuyer la gestion des exigence
2.3.2. Partager les connaissances
2.3.3. Supporter la conception
2.3.4. Synthèse
2.4. Travaux relatifs aux modèles d’information.
2.4.1. MeMVaTEx
2.4.2. Modèle de données de l’AFIS
2.4.3. Modèle de MAP Système
2.4.4. DoDAF et MoDAF
2.4.5. Snow Card Volere
2.4.. Travaux du CRAN
2.4.. Travaux du LAAS-CNRS
2.4.. Synthèse
2.5. Triptyque exigences-solutions-V&V, principe de bonne conception
3. Modèle proposé
3.1. Le langage choisi : SysML
3.1.1. Historique
3.1.2. Présentation
3.1.3. Stéréotype et block
3.1.4. Traçabilité avec SysML
3.1.5. Justification du choix de SysML
3.2. Extension proposée de SysML
3.2.1. Exigences enrichies
3.2.2. Nouveaux stéréotypes d’exigences
3.2.3. Stéréotype « risk »
3.3. Présentation du modèle d’information
4. Compléments au modèle
4.1. Utilisation d’OCL
4.2. Analyses et résultats issus du modèle de données
4.2.1. Matrices de traçabilité
4.2.2. Etats des exigences
5. Conclusion
Chapitre 5 : Exemple illustratif de l’avion S1
1. Introduction
2. Présentation de l’exemple
2.1. Le système « avion S1 »
2.1.1. Les fonctions
2.1.2. Les sous-systèmes
2.2. Le système « freins des roues »
2.2.1. Les fonctions
2.2.2. Les sous-systèmes
2.3. Le système « calculateur BSCU »
2.3.1. Les fonctions
2.3.2. Les sous-systèmes
3. Application de la méthodologie de déclinaison d’exigences de Sûreté de Fonctionnement
3.1. Niveau « avion S1 »
3.1.1. Etape 1 : Analyse des défaillances du système
3.1.2. Etape 2 : Analyses des causes des défaillances
3.1.3. Etape 3 : Analyses des défaillances des sous-systèmes
3.1.4. Etape 4 : Synthèse
3.2. Niveau « freins des roues »
3.2.1. Etape 1 : Analyse des défaillances du système
3.2.2. Etape 2 : Analyses des causes des défaillances
3.2.3. Etape 3 : Analyses des défaillances des sous-systèmes
3.2.4. Etape 4 : Synthèse
3.3. Niveau « calculateur BSCU »
3.3.1. Etape 1 : Analyse des défaillances du système
3.3.2. Etape 2 : Analyses des causes des défaillances
3.3.3. Etape 3 : Analyses des défaillances des sous-systèmes
3.3.4. Etape 4 : Synthèse
4. Modélisation SysML
4.1. Préparation du projet sous Tau-G
4.1.1. Extension de SysML
4.1.2. Organisation en packages
4.2. Niveau « avion S1 »
4.2.1. Package de la solution de conception
4.2.2. Package des exigences
4.2.3. Package de V&V : les cas de tests
4.3. Niveau « freins des roues »
4.3.1. Package de la solution de conception
4.3.2. Package des exigences
4.3.3. Package de V&V : les cas de tests
4.4. Niveau « calculateur BSCU »
5. Synthèse de l’étude de cas
6. Conclusion
Conclusion Générale
Bibliographie
Annexe A : Mots-clés associés au modèle de développement à SdF explicit
1. Expression des exigences
1.1. Processus de création
1.2. Processus de prévention de fautes
1.3. Processus de tolérance aux fautes
1.4. Processus d’élimination des fautes
1.5. Processus de prévision des fautes
2. Conception
2.1. Processus de création
2.2. Processus de prévention de fautes
2.3. Processus de tolérance aux fautes
2.4. Processus d’élimination des fautes
2.5. Processus de prévision des fautes
3. Réalisation
3.1. Processus de création
3.2. Processus de prévention de fautes
3.3. Processus de tolérance aux fautes
3.4. Processus d’élimination des fautes
3.5. Processus de prévision des fautes
4. Intégration
4.1. Processus de création.
4.2. Processus de prévention de fautes
4.3. Processus de tolérance aux fautes
4.4. Processus d’élimination des fautes
4.5. Processus de prévision des fautes
Annexe B : Modélisation SysML du niveau « calculateur BSCU »
1. Package de la solution de conception
1.1. Fonctions du système
1.2. Structure du système
2. Package des exigences
2.1. Diagramme des exigences haut-niveau
2.2. Diagramme de déclinaison des exigences
2.3. Diagramme de satisfaction des exigences
2.4. Diagramme de vérification des exigences
3. Package de V&V : les cas de tests
|
Télécharger le document complet
