Romaric GUILLERM Hamid DEMMOU LAAS-CNRS (Toulouse)

Présentation au sujet: "Romaric GUILLERM Hamid DEMMOU LAAS-CNRS (Toulouse)"— Transcription de la présentation:

1 Romaric GUILLERM Hamid DEMMOU LAAS-CNRS (Toulouse)
LM’17, 5-7 octobre 2010, Espace Encan, La Rochelle, France Base de connaissances SysML pour la conception de systèmes complexes sû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 Systèmes de plus en plus complexes
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 De plus en plus de fonctionnalités De plus en plus de technologies

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 Vues : celle de l’ingénieur système, celle de l’ingénieur de SdF

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 Propositions Approche globale pour la SdF
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 Cadre de conception Ingénierie Système - Définition
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 Cadre de conception Standard EIA-632 – Processus
Contexte général, motivation et propositions Cadre de conception Modèle d’information Conclusion Cadre de conception Standard EIA-632 – Processus

9 Cadre de conception Standard EIA-632 – Gestion des exigences
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 Modèle d’information Pourquoi ?
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. Niveau d’interconnexion Permet de regrouper dans un modèle commun à tous les corps de métiers : les specifications, les contraintes et les paramètres du système

12 Modèle d’information Choix du langage : SysML
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) Modélisation d’une large gamme de systèmes, incluant tant du matériel, que du logiciel, de l'information, des processus, du personnel, ou des équipements Autre type d’allocation (en plus des exigences) : fonctionnelle et structurelle, ce qui facilite la vérification et la validation

13 Modèle d’information Nous avons étendu SysML pour :
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 - Catégorie : fonctionnelle, performance, fiabilité, sécurité, … (cf. Volere) Source : acquéreur, partie prenante, conception - Cible : système ou produit contributeur SysML

14 Modèle d’information Nous avons étendu SysML pour :
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èle stéréotypé pour la conception des systèmes SdF respectant l’EIA-632

16 Conclusion Dans le cadre de l’approche globale de SdF :
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 ?

18 Annexes

19 Safety integration approach

20 Safety integration approach
R.14 – Acquirer Requirements R.15 – Other Stakeholder Requirements R.16 – System Technical Requirements 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.

21 Safety integration approach
R.14 – Acquirer Requirements R.15 – Other Stakeholder Requirements R.16 – System Technical Requirements 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. (1) Mean Time Between Failure, (2) Mean Time To Repair

22 Safety integration approach

23 Safety integration approach
R.17 – Logical Solution Representations R.18 – Physical Solution Representations R.19 – Specified Requirements 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.

24 Safety integration approach
R.17 – Logical Solution Representations R.18 – Physical Solution Representations R.19 – Specified Requirements 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.

25 Safety integration approach

26 Safety integration approach
R.22 – Effectiveness Analysis R.23 – Tradeoff Analysis R.24 – Risk Analysis 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.

27 Safety integration approach

28 Safety integration approach
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 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. A great attention is done to traceability analysis, which allows verifying all the links among Acquirer and Other Stakeholder Requirements, Technical and Derived Technical Requirements, and Logical Solution Representations. Indeed, the diversity of people concerned by the system design project can have limited knowledge concerning the structure of the future system, that’s why industry-scale requirement engineering projects are so hard. So the UML or SysML with their different diagrams can be helpful.

29 Safety integration approach

30 Safety integration approach
R.30 – Design Solution Verification R.31 – End Product Verification R.32 – Enabling Product Readiness 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,…