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