Safety Architect : A Tool for Model-Based Safety Analyses Compliant with the System Engineering Approach

Transcription

1 Safety Architect : A Tl fr Mdel-Based Safety Analyses Cmpliant with the System Engineering Apprach Authrs: Jnathan Dumnt, Franck Sadmi, Frédérique Vallée (All4tec) Keywrds: Safety, Dependability, Mdel-Based System Engineering, FMECA (Failure Mde Effects and Criticity Analysis, FTA (Fault Tree Analysis) Summary: Mdel-based system engineering is nwadays mre and mre cnsidered as essential t help defining cmplex systems. Thus it is part f the recmmended appraches fr implementing system engineering es. Mdel-based safety assessment is als tday a way mre and mre cnsidered in rder t imprve the safety analyses f cmplex system. In this paper we prpse an apprach that cmbines bth trends and we describe a tl named Safety Architect that supprts the prpsed apprach. The paper addresses successively the fllwing aspects: System Engineering and system mdeling main cncepts, Hw safety analysis must be cnducted in accrdance with system engineering principles Main bjectives and functinalities f Safety Architect 1 System Engineering and System Mdeling 1.1 Transversal cncepts and definitins Blck-system The blck-system is the basic decmpsitin technique used fr system engineering. It decmpses a cmplex system int several hierarchical sub-systems. Each blck-system is a cmplete entity n which the whle engineering es must be applied. Figure 1 : Blck systems decmpsitin Each blck-system has its wn cmplete set f dcuments prduced by the system engineering es: stakehlders needs dcument, system requirements dcument, design dcument, cmpnent needs dcuments, integratin and validatin test plans, integratin and validatin test reprts, justificatin file. At the last level, blck-systems als generate cmpnent needs dcuments but the system engineering es are n mre applicable t these cmpnents: cmpnent design and technlgic es must be used at this level. A blck-system is a generic bject: in a specific blck system the first level is always called system and elements f the next decmpsed level are always called cmpnent. The cmpnent becmes a system when cmes the turn t study its crrespnding blck-system.

2 System Cmpnent 1 Cmpnent 2 Cmpnent 3 Cmpnent Exchanges between blck-systems Figure 2 : Blck systems and cmpnents During the descending phase f the V life-cycle, the nly dcuments transmitted between blck-systems are the custmer needs dcuments (what the upper blck-system needs) and the system requirements dcument (what the under blck-system can d). S, each blck-system may use its wn tls and es: the nly requirement is that the custmer needs and the system requirements are the same fr the upper and fr the under blck-systems. In particular, the traceability has t be managed nly inside a single blck-system: the nly traceability prblem between blck-systems is the identificatin f custmer needs in ne hand and f system requirements in the ther hand. During the ascending phase f the V life-cycle, the physical bjects and their validatin files rise frm the underneath levels. Upper Blck-System (Upper) Cmpnent needs dcument (Under) System requirements dcument (Under) physical system (Under) System validatin files Under Blck-System Wrk by iteratin Figure 3 : Links between blck-systems Fr the blck-system develpment, the system engineering es are nt perfrmed sequentially. Of curse, the requirements are always first analyzed, then the functinal architecture and physical architecture definitin is perfrmed. But the wrk is dne thrugh numerus iteratins: The first iteratin cvers the nminal peratinal mde, then the fllwing nes cver the degraded mdes, the dependability requirements, etc. until the blck system is cmpletely described. A cmplete and cnsistent set f dcuments is established, verified and validated at the end f each iteratin. This set is the basis fr mck-up r prttyping develpment, is knwn and accepted by all stakehlders and allws the transitin t the next iteratin with cnfidence Multi-disciplines teams By definitin, a system team addresses multi-disciplines, therwise it is a mn discipline team and the system engineering es are n lnger applicable. The persn in charge f develping a blck system must rely n diverse disciplines skills and knwledge (mechanical, sftware, hardware, electrical, dependability, quality ). Representatives f all invlved disciplines must be represented in the system team. The system dcuments must address all multi-disciplines aspects and must be apprved by all system team members (e.g. a specific electrical dcument can nt exist and nly be apprved by the electrician f the system team) Dcuments elabratin

3 Each engineering dcument is first a way t cmmunicate infrmatin. Thus the fllwing rules have t be fulfilled: Each dcument must precise its bject in rder fr the reader t make sure that he will find what he needs in the dcument. The dcument must cntain an intrductin part t present the cntext and the main cntent that will facilitate the dcument apprpriatin by any new incmer. A glssary is required fr all acrnyms and discipline r applicatin dmain specific vcabulary. The dcument must be structured t imprve the usability: the reader must find quickly what he is lking fr. All mdeling slides r prgramming lines withut cmments must nt be inserted in the main parts f the dcument but inserted in appendixes with apprpriate anntatins. An bject r a cncept must always be identified with the same name in all dcuments f the same blck system. D nt use synnyms. 1.2 System engineering es System engineering es are useful fr the develpment f cmplex systems with a lt f functins, flws and interactins between cmpnents. They are heavy es: it is nt recmmended t use them fr a simple system with nly tw functins. The system engineering es cver several applicatin fields: management field, cntractual field, technical field. The management field pertains t all prject management activities (prject planning, prject mnitring and cntrl, decisin analysis and reslutin) and als t all supprt management activities (dcumentatin management, cnfiguratin management, prblem management, management, risk management, etc.). The cntractual field pertains t purchasing, sales and supplier management activities. The technical field pertains t all engineering activities.

4 ENGINEERING PROCESSES TECHNICAL PROCESSES ENGINEERING PROCESSES Stakehlders needs definitin MANAGEMENT PROCESSES Prject Management Dcumentatin Management System requirements analysis System functinal design System physical architecture Cnfiguratin Management Risk Management Prblem Management Prcess Management INTEGRATION - VALIDATION PROCESSES Cmpnent acceptance Integratin Validatin TRANSVERSAL PROCESSES PROCESSUS CONTRACTUELS Purchasing Sales Vérificatin validatin Change management Dependability Optimisatin Traceability management Figure 4 : System engineering es

5 TRANSVERSAL PROCESSES Stakehlders needs definitin Needs and requirements es Validatin System requirements analysis Integratin - validatin es Integratin System functinal design Design es Cmpnent acceptance System physical architecture Cmpnent es Main links Secndary links Figure 5 : Interactins between technical es This paper fcuses n the technical engineering es which are divided int fur main categries: es related t the stakehlders needs definitin and system requirements analysis activities, es related t the system functinal design and the physical architecture definitin activities, es related t the cmpnent acceptance, system integratin and validatin activities, transversal es (verificatin, change management, dependability activities, ptimizatin activities) used as supprt by the three ther categries. Thse technical es fllw a lgical rder (needs fllwed by implementatin, integratin and finally validatin) but they are nt strictly sequential because many iteratins and rewrk may be necessary in a same prject. The es f the tw first categries are defined in mre details hereafter Stakehlders needs definitin This cllects and elicits the needs and cnstraints frm all stakehlders which are affected r accuntable t the system thrughut the phases f the prduct lifecycle. The needs are identified, selected and classified befre been allcated t the apprpriate blck-systems with the apprpriate traceability reference. This encmpasses the fllwing activities: Identify the system missin and scpe Identify the bundaries f the system Identify the stakehlders Cllect the needs Structure the input dcumentatin Establish the stakehlders needs dcument Trace the needs rigin Verify and validate the stakehlders needs dcument System requirements analysis Stakehlder needs are analyzed and translated int system requirements until sufficient details are available t enable design, and testing f the system t prceed. This analysis can be instrumented with mdelling

6 techniques. System requirement analysis prduces functinal requirements, effectiveness requirements, external interfaces requirements, peratinal requirements and cnstraints applicable at system level. All requirements are nt systematically issued frm a client need (e.g. re-use cnstraint r derived requirement issued frm thers blck-systems). Specific attributes are assciated t each requirement in rder t ease its management (e.g. versin, pririty, histry ). Each requirement is identified and classified thanks t pre-defined criteria. Each requirement is traced frm its rigin. The system requirements dcument is submitted t a frmal review. This encmpasses the fllwing activities: Build the scenaris Identify the peratinal mdes Identify the interfaces Analyze the dcuments t find the applicable requirements Establish the system requirements Classify the system requirements Allcate attributes t the system requirements Trace the system requirements rigin Verify and validate the system requirements System functinal design The system functinal design is perfrmed accrding t the tw fllwing steps: Befre the physical architecture definitin phase: A functinal architecture independent f the physical architecture is defined r an already existing ne is reused. After the physical architecture definitin phase: The functinal architecture is updated in rder t take int accunt the physical ne. In this phase, the technical functins required by the system cmpnents (e.g. electrical supplies) are integrated and, what is mre, the whle functinal architecture is rerganized in a way t separate and minimize interfaces between functins allcated t different system cmpnents. This decupling is the first step fr the system cmpnents detailed design and identify in a precise way all exchanges between cmpnents. The traceability between functinal requirements and the assciated functinal elements (scenaris, peratinal mdes, main functins r elementary nes) is established. The rigin f the new functins intrduced during the design phase (such as technical cnstraints functins) is als recrded. The functinal mdel (architecture and hierarchy definitin) is dcumented in the functinal part f the design dcument and submitted t a frmal review. This encmpasses the fllwing activities: Identify the elementary functins Describe the peratinal mdes Establish the functinal architecture Establish the functinal hierarchy Trace the used requirements with the functinal elements (mdes, scenaris, main r elementary functins) Verify and validate the functinal design System physical design The system physical architecture cnsists in identifying and rganizing all cmpnents that implement elementary functins. A recmmended practice fr design is t identify several ptential technical slutins and select the mst apprpriate ne thanks t an ptimizatin. Functins are allcated t cmpnents and functinal flws are allcated t physical links. The physical mdel (architecture and hierarchy definitin) is dcumented in the physical part f the design dcument and submitted t a frmal review. This encmpasses the fllwing activities: Identify the candidate physical architectures Chse the mre adapted physical architecture Allcate the functinal and the nn functinal requirements t the cmpnents Verify and validate the chsen physical architecture

7 1.3 Mdeling appraches The tw first es may rely n different ways f mdelling. Depending mainly n the nature f the system that is tackled, the fllwing mdelling appraches and tls may be used: SADT, SART, SysML, Statemate, CORE, UML, Matlab/Simulink, etc. ALL4TEC aims are t use these mdels, when they exist, as a basis t perfrm the safety analyses f the dependability and thus t bth take advantage f a cllabrative wrk and enfrce cnsistency between system engineering and safety engineering. 2 Safety analysis f the successive mdels The dependability is perfrmed in parallel with all ther engineering es and includes safety analyses f the system under design. During the system requirements analysis phase, all system ptential r pssible hazards and accidents are analyzed. The ptential surces r sequences f events leading t hazards r accidents and their impacts are identified. Frm this risk analysis, dependability requirements are deduced t define which risk levels are acceptable and which high level safety tests must be perfrmed. During the design definitin phase, the functinal and physical architectures are analyzed in rder t: determine the hazard r accident prpagatin thrugh the data flw cmmunicatin links r interfaces, evaluate the likelihd and cnsequence f hazards fr all system cmpnents and allcate them t safety requirements. The chsen implementatin methds r prtectin techniques are defined with the crrespnding tests t be perfrmed. They are traced as dependability requirements t. At the end f the engineering, the system Feared Events (FE) have been refined int Cmpnents Feared Events. Figure 6 : Safety analysis in the engineering 3 The tl : Safety Architect Safety Architect is a tl dedicated t the safety analysis f preexisting mdels whatever the nature r the descriptin degree f the mdel is. In Safety Architect, safety analysis is handled via a methd similar t FMECA (Failure Mdes, Effects and Criticality Analysis) and the analysis results are shwn in a Fault Tree. Mre details n the tl main principles and functinalities are given in the fllwing paragraphs.

8 3.1 Main principles Reminder that FMEA aims are t determine, fr a given system, cmpnents failures that can bring the system int a nn-desired state defined as a feared event (FE). Each FE must be identified as a failure mde f ne utput f the system. The paths frmed by failures and their spread in the system leading t a FE are called critical paths. The main principles f using Safety Architect are summarized in the fllwing synptic: Figure 7 : Main functinalities f Safety Architect The user must first have a system functinal design r its physical architecture mdel. A Mdeler, utside Safety Architect, allws him t cnstruct such a mdel cnsisting f blcks cnnected amng themselves and with the envirnment f the system by riented streams (in the brad sense, it can be energy, infrmatin r dependencies/cnstraints). Then the user must imprt this mdel int Safety Architect t perfrm the safety analysis. The first step cnsists in perfrming a lcal analysis. Therefre, the tl helps the user t define the lcal effects f each leave blck f the mdel. This cnsists in linking failure mdes f the utputs f the blck t the linked failure mdes identified n the blck inputs. Failure events can als exist n the blck itself, and then can be linked t blck utput failure mdes. Safety Architect perfrms such a lcal analysis nly n leave blcks. In parallel with lcal analysis, the user can als implement safety barriers. Remind that a safety barrier is a part f a system participating t the safety bjectives cmpliance. This element cut the critical paths and thus prevents the attainment f identified FE. At the physical level, it can be fr example a redundancy, and at the functinal level, the additin f cnditins detecting r crrecting errrs. With Safety Architect, tw appraches are pssible t implement safety barriers: explicitly by the additin f blcks "barriers" in the riginal system mdel r implicitly by mdifying the lcal analysis equatins. Then, befre launching the verall analysis, the user must specify the failure mdes crrespnding t the feared events (FE) which will be studied by this analysis. At this step, the user may request Safety Architect t achieve the verall analysis stage. This step, fully autmatic, cnsists in spreading in the system all the identified failure mdes, and t trace thse (r cmbinatins f them) that reach a FE.

9 At the end f this analysis, the failure mdes (r their cmbinatins) reaching each FE as well as the paths used by the failure mdes t attain the FE are knwn. When the results are nt acceptable, the user can g back t the lcal analysis and add implicit safety barriers. When the results are acceptable, the user can exprt t the Mdeler an enriched mdel. We call an "enriched mdel" a system mdel with dysfunctinal data issued frm Safety Architect. The enriched mdel cntains nt nly all assumptins made during lcal analysis but it can als summarize the results f the glbal analysis (fr example, nneditable views f the generated Fault Tree). This enriched mdel can be mdified in the Mdeler and reimprted int Safety Architect in rder t retrieve infrmatin reusable in the event f changes. Integrity checks are run during the imprt phase. 3.2 Summary f Safety Architect Features In summary, Safety Architect main features are: Imprtatin f the system mdel With «Papyrus» UML mdeler With RSA mdeler (?) Lcal analysis Glbal analysis Thrugh the imprtatin f SysML r UML mdels Definitin f the feared events Editin f failure mdes and their lcal effects Add f barriers Prpagatin f failure mdes FMEA results in «.html» r «.csv» file Minimal fault tree (nn editable) Exprtatin t a Fault Tree Tl 4 Cncluding remarks Prvided that mdel driven engineering is emplyed, Safety Architect is a tl that brings nticeable gain n Safety Analysis quality and csts. Fr example, ALL4TEC cnsiders that the average gain made n FMEA effrt is f 50% fr an initial FMEA and f 80% when there is a need f rewrk f FMEA.

10 Mrever Safety Architect can be used in all engineering lp, is independent frm any engineering tl and is able t interface with many engineering tls. It is cmpliant t usual safety standards such as: ISO/CEI 61508, EN 5012x, ESARRs, Future ISO It prvides an elegant way t ensure that safety analysis is fully cmpliant with system r sftware engineering activities and ffers a real cllabrative wrk between system r sftware engineers and safety analysts.