Dmarche dIngnierie Systmes Intgrant la Sret de Fonctionnement

Base de connaissances SysML pourla conception de systmes complexessrs de fonctionnementRomaric GUILLERMHamid DEMMOULAAS-CNRS(Toulouse)Nabil SADOUSUPELEC/IETR(Rennes)LM17, 5-7 octobre 2010, Espace Encan, La Rochelle, France

Plan de la prsentationContexte gnral, motivation et propositionsCadre de conceptionModle dinformationConclusion2

2Contexte gnralSystmes de plus en plus complexes Processus de conception complexesPlus fortes contraintes de Sret de Fonctionnement (SdF) (Normes, autorits de certification)Concurrence rude (cot et dlai)

Faiblesses des processus de sret actuels3

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusionDe plus en plus de fonctionnalitsDe plus en plus de technologies3Contexte gnralFaiblesses des processus de sret actuels [Rasmussen 97]Absence de langage commun entre les diffrents mtiers concerns par le systmeDiffrents groupes ont besoin de travailler avec diffrentes vues du systme : cest une faiblesse lorsque les vues sont incohrentesMauvaise dfinition des exigences de sret et de leur formalisationAbsence de traabilit des exigences de sretLes mthodes existantes (traditionnelles) sont insuffisantes vu la complexit des systmes actuels4

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusionVues : celle de lingnieur systme, celle de lingnieur de SdF4MotivationNcessit dune approche globale pour la prise en compte de la sret de fonctionnementPrise en compte des risques lis lintgrationPrise en compte des exigences de sret tout au long du cycle de vie du systme

Ncessit dune bonne gestion des exigencesFormalisation des exigencesGestion de la traabilitUtilisation dun langage commun5

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusionPropositionsApproche globale pour la SdFCadre bien adapt : Ingnierie SystmeBut : prise en compte de la SdF tt dans la conception, de manire globale (niveau systme)

Approche IDM pour une meilleure prise en compte des exigences de sretModle dinformationLangage communFormalisation des exigencesTraabilit et liens avec le reste de la conception et les tches de V&V

6

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusionCadre de conceptionIngnierie Systme - Dfinition Lingnierie systme est une dmarche mthodologique gnrale qui englobe lensemble des activits adquates pour concevoir, faire voluer et vrifier un systme apportant une solution conomique et performante aux besoins dun client tout en satisfaisant lensemble des parties prenantes. [AFIS]

Un cadre pour le dveloppement des systmes complexesNorme EIA-632Guide mthodologique pour la prise en compte de la SdF au niveau des processus dIS :Processus de lEIA-632 traduits et raffins en termes de SdF7

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusion7Cadre de conceptionStandard EIA-632 Processus8

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusionCadre de conceptionStandard EIA-632 Gestion des exigences9

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusionModle dinformationPourquoi ?Rendre efficace la gestion des exigencesGrer les modifications/changements dexigencesAider les analyses dimpactsGuider la conceptionvaluer lavancement du projettre la base et le cur de connaissance du projet de conception, en proposant un modle partag sur la base dun langage commun comprhensible par tous10

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusionModle dinformationLe modle dinformation est destin modliser le niveau systmeMoyen de mise en commun des connaissances entre les diffrents mtiers ou spcialits, incluant les 3 volets :Exigences - Solution de conception - V&VLes lments de V&V sont inclus dans le modle pour tre directement lis aux exigences quils vrifient.11

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusion

Niveau dinterconnexion Permet de regrouper dans un modle commun tous les corps de mtiers : les specifications, les contraintes et les paramtres du systme11Modle dinformationChoix du langage : SysMLLangage commun bien dfini et comprhensible par tousModlisation dune large gamme de systmesExpression des exigences dans le modleTraabilit rigoureuse : faciliter les analyses dimpacts (exemple : un changement dexigence)Allocation visible des exigences sur le modleIntgration et association des cas de tests directement la modlisationExtensibilit de SysML (ajout dinformation relative aux risques et proprits de SdF attendues)12

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusionModlisation dune large gamme de systmes, incluant tant du matriel, que du logiciel, de l'information, des processus, du personnel, ou des quipementsAutre type dallocation (en plus des exigences): fonctionnelle et structurelle, ce qui facilite la vrification et la validation

12Modle dinformationNous avons tendu SysML pour :Nouveaux strotypes pour les exigencesNouveaux attributs pour les exigencesDfinition dun nouveau lien (specify) pour lier les exigences spcifies aux lments du modle13

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusion

SysML- Catgorie : fonctionnelle, performance, fiabilit, scurit, (cf. Volere) Source : acqureur, partie prenante, conception- Cible : systme ou produit contributeur13

Modle dinformationNous avons tendu SysML pour :Nouveau bloc risk li des exigences de SdFDfinition dun nouveau lien (treat) pour lier les exigences de SdF aux risques quelles traitent14

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusion

SysML

Modle dinformation15

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusionLe modle dinformation=Mta-modle strotyp pour la conception des systmes SdFrespectant lEIA-632ConclusionDans le cadre de lapproche globale de SdF :Dfinition dun modle dinformation laide de SysML, un langage commun, et de quelques extensionsAdapt la norme EIA-632Intgrant des concepts de sret (exigences de SdF et risques)Appuyant la gestion des exigences, avec une traabilit rigoureuse entre les lments

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. arofrein, syst. frein)16

Contexte gnral, motivation et propositions Cadre de conceptionModle dinformationConclusion Questions17?guillerm@laas.fr

18Annexes

Safety integration approach19

Safety integration approach20

R.14 Acquirer RequirementsR.15 Other Stakeholder RequirementsR.16 System Technical RequirementsThe 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.

20Safety integration approach21

R.14 Acquirer RequirementsR.15 Other Stakeholder RequirementsR.16 System Technical RequirementsThe 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 performancesIt 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 approach22

Safety integration approach23R.17 Logical Solution RepresentationsR.18 Physical Solution RepresentationsR.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 approach24R.17 Logical Solution RepresentationsR.18 Physical Solution RepresentationsR.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 approach25

Safety integration approach26R.22 Effectiveness AnalysisR.23 Tradeoff AnalysisR.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 approach27

Safety integration approach28R.25 Requirement Statements ValidationR.26 Acquirer Requirements ValidationR.27 Other Stakeholder Requirements Validation

R.28 System Technical Requirements ValidationR.29 Logical Solution Representations ValidationRequirements 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, thats why industry-scale requirement engineering projects are so hard. So the UML or SysML with their different diagrams can be helpful.

28Safety integration approach29

Safety integration approach30R.30 Design Solution VerificationR.31 End Product VerificationR.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 verificationOther methods: virtual prototyping, model checking,