Base de connaissances SysML pour la conception de systèmes complexes sûrs de fonctionnement

1. LM’17, 5-7 octobre 2010, Espace Encan, La Rochelle, France Base de connaissances SysML pourla conception de systèmes complexessûrs de fonctionnement Romaric GUILLERM Hamid DEMMOU LAAS-CNRS (Toulouse) Nabil SADOU SUPELEC/IETR (Rennes)

2. Plan de la présentation • Contexte général, motivation et propositions • Cadre de conception • Modèle d’information • Conclusion

3. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Contexte général • Systèmes de plus en plus complexes  Processus de conception complexes • Plus fortes contraintes de Sûreté de Fonctionnement (SdF) (Normes, autorités de certification…) • Concurrence rude (coût et délai…)  Faiblesses des processus de sûreté actuels

4. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Contexte général • Faiblesses des processus de sûreté actuels [Rasmussen 97] • Absence de langage commun entre les différents métiers concernés par le système • Différents groupes ont besoin de travailler avec différentes vues du système : c’est une faiblesse lorsque les vues sont incohérentes • Mauvaise définition des exigences de sûreté et de leur formalisation • Absence de traçabilité des exigences de sûreté • Les méthodes existantes (traditionnelles) sont insuffisantes vu la complexité des systèmes actuels

5. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Motivation • Nécessité d’une approche globale pour la prise en compte de la sûreté de fonctionnement • Prise en compte des risques liés à l’intégration • Prise en compte des exigences de sûreté tout au long du cycle de vie du système • Nécessité d’une bonne gestion des exigences • Formalisation des exigences • Gestion de la traçabilité • Utilisation d’un langage commun

6. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Propositions • Approche globale pour la SdF • Cadre bien adapté : Ingénierie Système • But : prise en compte de la SdF tôt dans la conception, de manière globale (niveau système) • Approche IDM pour une meilleure prise en compte des exigences de sûreté • Modèle d’information • Langage commun • Formalisation des exigences • Traçabilité et liens avec le reste de la conception et les tâches de V&V

7. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Cadre de conception • Ingénierie Système - Définition L’ingénierie système est une démarche méthodologique générale qui englobe l’ensemble des activités adéquates pour concevoir, faire évoluer et vérifier un système apportant une solution économique et performante aux besoins d’un client tout en satisfaisant l’ensemble des parties prenantes. [AFIS] • Un cadre pour le développement des systèmes complexes • Norme EIA-632 • Guide méthodologique pour la prise en compte de la SdF au niveau des processus d’IS : • Processus de l’EIA-632 traduits et raffinés en termes de SdF

8. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Cadre de conception • Standard EIA-632 – Processus

9. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Cadre de conception • Standard EIA-632 – Gestion des exigences

10. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Modèle d’information Pourquoi? • Rendre efficace la gestion des exigences • Gérer les modifications/changements d’exigences • Aider les analyses d’impacts • Guider la conception • Évaluer l’avancement du projet • Être la base et le cœur de connaissance du projet de conception, en proposant un modèle partagé sur la base d’un langage commun compréhensible par tous

11. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Modèle d’information • Le modèle d’information est destiné à modéliser le niveau « système » • Moyen de mise en commun des connaissances entre les différents métiers ou spécialités, incluant les 3 volets : Exigences - Solution de conception - V&V • Les éléments de V&V sont inclus dans le modèle pour être directement liés aux exigences qu’ils vérifient.

12. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Modèle d’information • Choix du langage : SysML • Langage commun bien défini et compréhensible par tous • Modélisation d’une large gamme de systèmes • Expression des exigences dans le modèle • Traçabilité rigoureuse : faciliter les analyses d’impacts (exemple : un changement d’exigence) • Allocation visible des exigences sur le modèle • Intégration et association des cas de tests directement à la modélisation • Extensibilité de SysML (ajout d’information relative aux risques et propriétés de SdF attendues)

13. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Modèle d’information • Nous avons étendu SysML pour : • Nouveaux stéréotypes pour les exigences • Nouveaux attributs pour les exigences • Définition d’un nouveau lien (specify) pour lier les exigences spécifiées aux éléments du modèle SysML

14. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Modèle d’information • Nous avons étendu SysML pour : • Nouveau bloc « risk » lié à des exigences de SdF • Définition d’un nouveau lien (treat) pour lier les exigences de SdF aux risques qu’elles traitent SysML

15. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Modèle d’information Le modèle d’information = Méta-modèlestéréotypé pour la conception des systèmes SdF respectant l’EIA-632

16. Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Conclusion • Dans le cadre de l’approche globale de SdF : • Définition d’un modèle d’information • À l’aide de SysML, un langage commun, et de quelques extensions • Adapté à la norme EIA-632 • Intégrant des concepts de sûreté (exigences de SdF et risques) • Appuyant la gestion des exigences, avec une traçabilité rigoureuse entre les éléments • Un exemple en cours, pour valider l’approche  Avion S18 extrait de l’ARP-4761, avec étude de la fonction de freinage et des composants mis en jeu (syst. reverse, syst. aérofrein, syst. frein)

17. Questions guillerm@laas.fr ?

18. Annexes

19. Safety integration approach

20. Safety integration approach • The developer shall define a validated set of acquirer (other stakeholder) requirements for the system, or portion thereof. • In the safety framework: • Acquirer requirements, generally, correspond to constraints in the system. It is necessary to identify and collect all constraints imposed by acquirer to obtain a dependable system. • A hierarchical organization associates weight to safety requirements, following their criticality. • Safety requirements can be derived from certification or quality requirements or can be explicitly expressed by acquirer or other stakeholder. R.14 – Acquirer Requirements R.15 – Other Stakeholder Requirements R.16 – System Technical Requirements

21. Safety integration approach • The developer shall define a validated set of system technical requirements from the validated sets of acquirer requirements and other stakeholder requirements. • Concerning safety: • System technical requirements traduce system performances • It consists on defining safety attributes (SIL level, MTBF(1), MTTR(2), failure rate,…) • Technical requirements can be derived from a preliminary hazard analysis. • Some standard can help designer to define safety requirements. Example in civil aerospace sector: ARP4754 and ARP 4761. R.14 – Acquirer Requirements R.15 – Other Stakeholder Requirements R.16 – System Technical Requirements (1) Mean Time Between Failure, (2) Mean Time To Repair

22. Safety integration approach

23. Safety integration approach • The developer shall define one or more validated sets of logical solution representations that conform with the technical requirements of the system. • The recommendation is to use semi formal / formal models for the solution modeling. The use of formal methods allows for automation of verification and analysis. • In this processes, safety analysis techniques will be used to determine the best logical solution. R.17 – Logical Solution Representations R.18 – Physical Solution Representations R.19 – Specified Requirements

24. Safety integration approach • The developer shall define a preferred set of physical solution representations that agrees with the assigned logical solution representations, derived technical requirements, and system technical requirements. • The physical solution representations are derived from logical solution representation and must respects all requirements, particularly safety requirements. • The same safety analysis may be done for the physical solution representations. The same recommendations than for logical solution remain true. R.17 – Logical Solution Representations R.18 – Physical Solution Representations R.19 – Specified Requirements

25. Safety integration approach

26. Safety integration approach • The developer shall perform risk analyses to develop risk management strategies, support management of risks, and support decision making. • Techniques: Fault tree ; Failure Mode, Effect, and Criticality Analysis; … • Determines the risks of the system • Can generate safety requirements other than that defined by the acquirer and other stakeholders. R.22 – Effectiveness Analysis R.23 – Tradeoff Analysis R.24 – Risk Analysis

27. Safety integration approach

28. Safety integration approach • Requirements Validation is critical to successful system product. • Requirements are validated when it is certain that they describe the input requirements and objectives such that the resulting system products can satisfy them. • A great attention is done to traceability analysis. • Like other requirements, safety requirements must be validated. The validation allows designing safe system. • To facilitate this step, semi-formal solutions, like UML or SysML, can be used for good formulation of requirements. R.25 – Requirement Statements Validation R.26 – Acquirer Requirements Validation R.27 – Other Stakeholder Requirements Validation R.28 – System Technical Requirements Validation R.29 – Logical Solution Representations Validation

29. Safety integration approach

30. Safety integration approach • The System Verification Process is used to ascertain that: • The generated system design solution is consistent with its source requirements, in particular safety requirements. • Some traceability models allow defining the procedure of verifying safety requirement. These procedures are planned at the definition of safety requirement. • Simulation is a good and current method used to achieve system verification • Other methods: virtual prototyping, model checking,… R.30 – Design Solution Verification R.31 – End Product Verification R.32 – Enabling Product Readiness