Base de connaissances SysML pourla conception de systèmes complexes

sûrs de fonctionnement

Romaric GUILLERMHamid DEMMOU

LAAS-CNRS(Toulouse)

Nabil SADOUSUPELEC/IETR(Rennes)

LM’17, 5-7 octobre 2010, Espace Encan, La Rochelle, France

Plan de la présentationContexte général, motivation et propositions

Cadre de conception

Modèle d’information

Conclusion

2

Contexte généralSystèmes de plus en plus complexes

Processus de conception complexesPlus 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 d’informationConclusion

Contexte généralFaiblesses des processus de sûreté actuels

[Rasmussen 97]Absence de langage commun entre les différents

métiers concernés par le systèmeDiffé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 actuels4

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

MotivationNécessité d’une approche globale pour la prise

en compte de la sûreté de fonctionnementPrise en compte des risques liés à l’intégrationPrise en compte des exigences de sûreté tout au

long du cycle de vie du système

Nécessité d’une bonne gestion des exigencesFormalisation des exigencesGestion de la traçabilitéUtilisation d’un langage commun

5

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

PropositionsApproche globale pour la SdF

Cadre bien adapté : Ingénierie SystèmeBut : 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’informationLangage communFormalisation des exigencesTraçabilité et liens avec le reste de la conception et les

tâches de V&V6

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

Cadre de conceptionIngé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-632Guide 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

7

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

Cadre de conceptionStandard EIA-632 – Processus

8

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

Cadre de conceptionStandard EIA-632 – Gestion des exigences

9

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

Modèle d’informationPourquoi ?

Rendre efficace la gestion des exigencesGérer les modifications/changements

d’exigencesAider les analyses d’impactsGuider 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

10

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

Modèle d’informationLe 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.

11

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

Modèle d’informationChoix du langage : SysML

Langage commun bien défini et compréhensible par tousModélisation d’une large gamme de systèmesExpression des exigences dans le modèleTraç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élisationExtensibilité de SysML (ajout d’information relative aux

risques et propriétés de SdF attendues)

12

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

Modèle d’informationNous avons étendu SysML pour :

Nouveaux stéréotypes pour les exigencesNouveaux attributs pour les exigencesDéfinition d’un 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 d’informationConclusion

SysML

Modèle d’informationNous avons étendu SysML pour :

Nouveau bloc « risk » lié à des exigences de SdFDéfinition d’un nouveau lien (treat) pour lier les

exigences de SdF aux risques qu’elles traitent

14

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

SysML

Modèle d’information

15

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

Le modèle d’information

=Méta-modèle

stéréotypé pour la conception des systèmes

SdFrespectant l’EIA-632

ConclusionDans 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)

16

Contexte général, motivation et propositions Cadre de conception

Modèle d’informationConclusion

Questions

17

?

guillerm@laas.fr

18

Annexes

Safety integration approach

19

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.

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 4761.(1) Mean Time Between Failure, (2) Mean Time To Repair

Safety integration approach

22

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.

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.

Safety integration approach

25

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 systemCan generate safety requirements other than that defined

by the acquirer and other stakeholders.

Safety integration approach

27

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.

Safety integration approach

29

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,…