La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Romaric GUILLERM Hamid DEMMOU LAAS-CNRS (Toulouse) Nabil SADOU SUPELEC/IETR (Rennes) LM17, 5-7 octobre 2010, Espace Encan, La Rochelle, France.

Présentations similaires


Présentation au sujet: "Romaric GUILLERM Hamid DEMMOU LAAS-CNRS (Toulouse) Nabil SADOU SUPELEC/IETR (Rennes) LM17, 5-7 octobre 2010, Espace Encan, La Rochelle, France."— Transcription de la présentation:

1 Romaric GUILLERM Hamid DEMMOU LAAS-CNRS (Toulouse) Nabil SADOU SUPELEC/IETR (Rennes) LM17, 5-7 octobre 2010, Espace Encan, La Rochelle, France

2 Plan de la présentation Contexte général, motivation et propositions Cadre de conception Modèle dinformation Conclusion 2

3 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 3 Contexte général, motivation et propositions Cadre de conception Modèle dinformation Conclusion

4 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 : cest 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 4 Contexte général, motivation et propositions Cadre de conception Modèle dinformation Conclusion

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

6 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 dinformation Langage commun Formalisation des exigences Traçabilité et liens avec le reste de la conception et les tâches de V&V 6 Contexte général, motivation et propositions Cadre de conception Modèle dinformation Conclusion

7 Cadre de conception Ingénierie Système - Définition Lingénierie système est une démarche méthodologique générale qui englobe lensemble des activités adéquates pour concevoir, faire évoluer et vérifier un système apportant une solution économique et performante aux besoins dun client tout en satisfaisant lensemble 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 dIS : Processus de lEIA-632 traduits et raffinés en termes de SdF 7 Contexte général, motivation et propositions Cadre de conception Modèle dinformation Conclusion

8 Cadre de conception Standard EIA-632 – Processus 8 Contexte général, motivation et propositions Cadre de conception Modèle dinformation Conclusion

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

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

11 Modèle dinformation Le modèle dinformation 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 quils vérifient. 11 Contexte général, motivation et propositions Cadre de conception Modèle dinformation Conclusion

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

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

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

15 Modèle dinformation 15 Contexte général, motivation et propositions Cadre de conception Modèle dinformation Conclusion Le modèle dinformation = Méta-modèle stéréotypé pour la conception des systèmes SdF respectant lEIA-632

16 Conclusion Dans le cadre de lapproche globale de SdF : Définition dun modèle dinformation À laide 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 lapproche Avion S18 extrait de lARP-4761, avec étude de la fonction de freinage et des composants mis en jeu (syst. reverse, syst. aérofrein, syst. frein) 16 Contexte général, motivation et propositions Cadre de conception Modèle dinformation Conclusion

17 Questions 17 ?

18 18 Annexes

19 Safety integration approach 19

20 Safety integration approach 20 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 21 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 (1) Mean Time Between Failure, (2) Mean Time To Repair

22 Safety integration approach 22

23 Safety integration approach 23 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 24 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 25

26 Safety integration approach 26 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 27

28 Safety integration approach 28 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.

29 Safety integration approach 29

30 Safety integration approach 30 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,…


Télécharger ppt "Romaric GUILLERM Hamid DEMMOU LAAS-CNRS (Toulouse) Nabil SADOU SUPELEC/IETR (Rennes) LM17, 5-7 octobre 2010, Espace Encan, La Rochelle, France."

Présentations similaires


Annonces Google