SysML for embedded automotive Systems: lessons learned

Transcription

1 SysML for embedded automotive Systems: lessos leared J-D. Piques, E. Adriaariso 2 (): Valeo - Powertrai Systems Busiess Group Electrical Vehicle Product Group (2): Valeo - Group Electroic Expertise ad Developmet Services 4 aveue des Béguies, Cergy-Potoise Cedex Abstract: This paper deals with the first lessos leared from usig the SysML laguage to support the System Egieerig activities whe developig automotive embedded s ad products with a particular focus o illustratig improvemet solutios that have bee experimeted ad validated i Valeo pilot projects. Keywords: Model Based Egieerig, System Modelig, SysML, System Egieerig, SysCARS. Itroductio ad overview Motivatios Icreasig complexity of techical s, busiess models ad safety regulatio (ISO26262) requires higher formalizatio effort. The Model Based System Egieerig (MBSE) approach is a key lever for automotive lea processes to cope with this cotext ad still esurig flexibility ad R&D efficiecy o iovative products. Mai lessos leared Although SysML has become the de facto stadard for MBSE, a supportig methodological backgroud was ad is still madatory. The SysCARS methodology [], which is summarized i Part 2, defies the sequece of SysML diagrams ad artefacts to be released i order to implemet the egieerig process. However pilot projects have show this was ot sufficiet ad other critical issues have bee addressed. A major issue is the adoptio of SysML existig modelers which are too complicated for o software egieers, providig o guidace o which diagram ad artefact to use amog overloaded GUIs. To support adoptio ad deploymet cotrol, a workflow drive approach is described i Part 3 ad is implemeted by a Valeo profile icludig ergoomic macros for Artisa Studio modeler. Movig from a documet cetric approach to model based egieerig shall also esure formal couplig to requiremet related tools. Part 4 addresses these aspects together with strategy regardig traceability checks ad coectio to tools such as DOORS ad Reqtify. Still to facilitate adoptio ad due to weakesses of SysML compared to disciplie modelig / simulatio tools, SysCARS support sychroizatio of structural diagrams. This feature is described i Part 5 ad is used to perform behavioural studies i legacy tools such as Simulik. ially Part 6, summarizes issues related to ad safety egieerig couplig ad presets mechaisms supportig Safety I the Loop approach (SaIL) targetig MEA/TA automatio. 2. SysCARS methodology overview SysCARS (System Core Aalyses for Robustess ad Safety) is a Valeo methodology which provides a practical help for desigers o how to perform the sequece of System modelig activities with SysML. This methodology, detailed i a previous paper [], is shortly summarized here. 2.. SysCARS priciples SysCARS methodology added value cosists i: Selectig a subset of SysML diagrams ad artefacts to be used i a coveiet ad pragmatic way (learig curve optimizatio) Providig defied sematics to esure diagrams meaig ad rules for verifyig model cosistecy Defiig a obvious diagram sequece which esures modelig efficiecy regardig compay processes Implemetig stereotypes ad templates for automatic documetatio geeratio at each stage of the process Takig ito accout couplig costraits with other processes or tools such as Reqtify from IBM for requiremet traceability or Simulik from The Mathworks for fuctioal modelig The curret methodology is therefore targetig the optimum trade off for Valeo deploymet ad is built from existig state of the art. It does ot claim for ay theoretical ovelty, while havig merged relevat best practices from existig approaches, such as EIRIS methodology [2]. This implemetatio is also takig maximum beefits from available features of the selected SysML tool, amely Artisa Studio from Atego SysCARS geeric workflow The overall System Egieerig process begis with aalyzig the project cotext, cosiderig the to be developed as a black box, ad the successively goes deeper ito the details util specifyig iteral compoet features. More Page /0

2 GROUPING ALLOCATION precisely the SysCARS methodology is divided ito five major phases: Stakeholder eeds defiitio Requiremets aalysis Logical architecture desig architecture desig Compoets eeds defiitio or clarity purpose, the process ad the sequece of activities are described i a pure sequetial way. However, i practice, differet steps could be performed simultaeously with iterative ad mutual refiemets. Moreover, each phase atically eds with: Traceability aalysis, to check the cosistecy ad completeess of activities performed ad artefacts created, Automatic geeratio of a documet makig a sythesis of the activities performed (SND: Stakeholder Needs Documet, SyRD: System Requiremet Documet, SyDD: System Desig Documet, CND: Compoet Needs Documet) SysCARS optimized workflows The SysCARS workflow is described below. Stakeholders Needs Defiitio Requiremets Aalysis Logical Desig Desig a b c d Cotext Exteral Iterfaces Iteral uctios Usage Mai Services User Scearios 2a 2b 2c 2d 3a 4a Cadidate Solutios 3b Logical 3c System Scearios Log Iteral Iterfaces 4b 4c 4d Modes BDD UCD SD STM IBD UCD AD BDD IBD BDD States STM Phy Iteral Phy Iteral Iterfaces Iteral Scearios Iteral Iteral Iteral BDD Iterfaces IBD Scearios SD Iterfaces Scearios SD SND SyRD SyDD igure 0: SysCARS System Egieerig Process The last stage (Compoet Needs Defiitio) has ot bee represeted, because it is maily a extractio of compoet artefacts from the physical architecture. The kid of diagram used at each step is give by its SysML acroym attached to the related activity block: Block Defiitio Diagram (BDD), Iteral Block Diagram (IBD), Use Case Diagram (UCD), Sequece Diagram (SD), STate Machie diagram (STM), Activity Diagram (AD) Lessos leared o pilot projects have show that i most situatios it makes sese to bypass the elaboratio of the logical breakdow ad to directly allocate iteral fuctios oto the physical architecture blocks. Ideed, physical architectures are very ofte froze because resultig from carry over products ad therefore the ivestigatio of several cadidate solutios is ot ecessary. Cosequetly, two kids of optimized workflow have bee defied depedig o the project typology: SysCARS-XS (exteded Stream): or iovative products, the whole set of activities of the [figure 0] are performed, ad i particular the ivestigatio of several physical architectures. SysCARS-CS (Core Stream): or carry over products, the activities represeted by grey boxes o the [figure 0] are ot performed. 3. Workflow-drive approach 3.. A specific profile for customizig SysML GUIs of SysML existig tools remai too complicated for a o software specialist, which is the targeted audiece for System Egieerig. Ideed, SysML user iterfaces provide cofusig ad ueeded features from the UML world. Very ofte, UML ad SysML artefacts ad diagrams are mixed without ay possibility for the user to limit to a pure SysML scope. Moreover, o guidace is provided o the relevat diagram to be used ad o the correct orderig of operatios. To cope with these drawbacks, a specific ergoomic profile (thereafter referred to as Valeo Profile ) has bee developed, itroducig the cocept of workflow-drive approach. The basic idea behid the workflow-drive approach is to provide the System egieer with a step by step help throughout the SysCARS egieerig workflow. Moreover, at each step of the workflow, oly relevat features ad diagrams are available i a simplified GUI. The mechaisms of the workflow drive approach are detailed i the chapters below Workflow diagram avigatio Whe creatig a ew model with the Valeo profile, this model directly opes a pre-defied workflow diagram. The workflow diagram is the cetral elemet of the Valeo Profile, defiig the sequece of modelig activities to be performed i accordace with the SysCARS methodology []. I fact, the workflow diagram is simply a statechart diagram, where states ad super-states respectively correspod to elemetary activities ad mai stages of the SysCARS methodology. No more tha oe elemetary state ca be active at oe momet; i.e. oly oe kid of elemetary activity should be performed. O the workflow diagram represeted below, the active state is highlighted i blue. Page 2/0

3 Pre-defied Package Structure Embedded SysCARS Workflow igure 02: Valeo Profile GUI Overview It is possible to avigate the states of the workflow diagram ad to select the workflow commads available: Next Step, Previous Step, Go to step. The the modelig step is chaged accordigly GUI features defied by workflow state The curret active state of the workflow diagram is used to moitor the look ad feel of the SysML modeler tool, i order to provide the user oly with the features required at this step of the modelig process. Cosequetly, commad meus available i the object browser ad toolbar meus o diagrams are both customized differetly i each state of the workflow diagram. The diagram below clearly shows the level of simplificatio o commad meus reached by the Valeo Profile. Customized cotextual Toolbar Customized cotextual Meu Workflow Meu igure 03: Valeo Profile Navigatio A secod kid of avigatio mechaism is available from the workflow diagram. Right-clickig o each state allows to reach the diagrams summarizig the results of this modelig step. The relevat diagrams should have bee attached as associated diagrams oce created. The implemetatio of the workflow i the profile is ot froze but cofigured usig a dedicated XML file. This optio eables further evolutios o the SysCARS workflow Pre-defied package structure Whe creatig a ew model with the Valeo Profile, this model is also provided with a pre-defied package structure. This package hierarchy is directly correlated to states ad super states of the workflow diagram, which i tur correspod to stages ad steps of the SysCARS methodology. However, the user is free to orgaize differetly artefacts ad diagrams withi a differet package structure. As previously, the pre-defied package structure is ot froze but cofigured usig a dedicated XML file. igure 04: Customized Meus I the object browser widow, the create commad meu displayed whe right-clickig a existig SysML object, is customized idividually for each type of SysML artefact ad diagram. I the graphical widow, buttos available o each kid of diagram toolbars are also customized depedig o the workflow diagram active state. The GUI features are evolutioary ad cofigured from two dedicated XML files, oe for the package browser commad meus ad oe for the diagram toolbars Stereotypes for documetatio Documetatio i a format that is easily comprehesible by a broad rage of stakeholders remais a effective way to validate ad commuicate desig iformatio. The first thig to do is to precisely defie the expected documet format ad cotets by creatig a correspodig template for the publishig tool. The same documet template will be re-used o differet projects, without ay modificatio. The, thaks to the publishig feature of the SysML tool, automatic documet geeratio ca be ru o demad to collect ad format data from the SysML model, without ay special effort. urthermore, separatio betwee modelig data ad documet templates eables versatile customisatio either to geerate geeric outputs or to address specific customer process. Page 3/0

4 The orgaisatio of the documetatio is also based o the workflow diagram breakdow. Oe particular kid of documet (with related template) is defied for each workflow diagram super-state, i order to make the sythesis of modelig activities performed withi this stage: SND (Stakeholder Needs Documet) for Stakeholder eeds defiitio stage SyRD (System Requiremets Documet) for Requiremets aalysis stage SyDD (System Desig Documet) for Logical ad architecture desig CND (Compoets Needs Desig) for Compoets eeds defiitio stage SysML artefacts ad diagrams created whe beig i a give super-state of the workflow diagram are automatically attached with stereotypes idicatig that they should appear i the documet associated with this super-state. The ames of these stereotypes are built with the ame of artefact or diagram prefixed by the ame of the target documet (e.g: SND_requiremet). It is also possible to maually apply documetatio stereotypes whe artefacts should appear i multiple documets Stereotype for Documetatio igure 05: Documetatio Stereotype Example The oly thig left to do is to load i the publishig tool the pre-defied documetatio template related to the workflow super-state to be documeted, ad the to lauch documetatio rederig. Diagrams ad artefacts appearig i the fial documet are automatically filtered depedig o their documetatio stereotypes, i.e. o the stage of the workflow they have bee created. 4. Couplig to requiremet maagemet tools 4.. Efficiet collaboratio betwee tools Speakig about requiremets i geeral may lead to adopt wrog requiremet maagemet toolig solutios. I fact, iitial eeds are iteratively refied durig the egieerig process, producig differet levels of so-called requiremets, correspodig to very differet kid of iformatio. Typically these requiremets ca be classified i three categories: User requiremets describe the expected services from the ed user poit of view. System requiremets defie the features of the ecessary to fulfil its missio. Compoet requiremets specify the iteral costitutive parts ecessary to implemet the expected features. Therefore, believig that a uique tool has the capability to address efficietly these three layers of iformatio is icorrect. O the cotrary, a pragmatic approach adopted at Valeo is to take beefits from tools optimised for each field ad to make them collaborate efficietly. Aother commo mistake is to mix up two categories of requiremets related tools: Requiremet defiitio tools are cotaiers of requiremets (or ay modelig artefacts used for specificatio). Requiremet traceability tools do ot defie ay requiremets but have the ability to aalyze requiremets from requiremet defiitio tools, ad to aalyze traceability liks. A tool of the secod category (e.g. Reqtify) ca therefore be used as a gateway to optimise collaboratio betwee tools of the first category (DOORS, SysML Artisa Studio, Simulik, ), for sychroizig iterface requiremets ad producig the whole traceability aalysis. Aother iterestig property of this scheme is its ability to let people workig with their disciplie specific tools (such as Simulik for cotrol desig). All the above metioed priciples are summarized o the figure below, showig the typical mappig of tools used at Valeo. USER Customer Repository User Requiremets SYSTEM Product Compoet Requiremets COMPONENT Disciplie Tools Developmet Tools Customer Customer Needs Needs Breakdow Traceability Results Refied Requiremets Desig/Validatio Elemets REQTIY igure 06: Requiremets Related Tools Mappig 4.2. Distributed requiremet storage Classical requiremet maagemet approaches assume that all requiremets shall be writte i atural laguage iside a cetralized database (typically DOORS). The, SysML modelig artefacts are oly cosidered as itermediary by-products that eed to be fially traslated ito textual requiremets. This process makes sese i the aerospace or railway trasportatio fields were certificatio procedures are documet-cetric by Page 4/0

5 ature. However, i the automotive area, without ay costraits from certificatio procedures, a pure model-cetric approach is far more efficiet. Cosequetly, maximum beefits are take from expressive power ad semi-formal verificatio capability of the SysML modelig laguage. Requiremets or requiremets-like artefacts produced durig modelig activities are ot reformulated i atural laguage ito a exteral cetralized database. O the cotrary, the model itself becomes the referece ad the automatically geerated documetatio oly a illustratio of this referece. This philosophy is also used at implemetatio level, where requiremets or more exactly requiremets-like artefacts remais embedded ito disciplie specific ative models (such as Simulik models, for cotrol desig). This approach optimises the requiremet maagemet effort because requiremets are distributed amog the tool locatios where they have bee defied, at each stage of the egieerig process. As a couterpart, the cosistecy of the distributed requiremets storage must be supported by powerful traceability tools, with efficiet mechaisms for sychroizig iterface requiremets betwee modelig layers User requiremets i exteral repositories The iitial stakeholder requiremets (amely user requiremets) remai captured i text specificatios exteral to the SysML modelig tool, as i the classical approach. Typically, these specificatios are stored i a DOORS database but may also be described usig classical word processig or table editig softwares. The combiatio of the Reqtify gateway ad of Artisa Studio modelig tool provides a mechaism to import exteral text requiremets by creatig mirrorig SysML requiremets directly ito the SysML model ad to later maitai these data sychroized. I fact, three kids of sychroizatio mechaisms are available: Sychroizatio with a DOORS database Sychroizatio with ay kid of requiremet file captured with Reqtify Sychroizatio with Excel files (feature added by the Valeo Profile) The SysCARS modelig activities performed to aalyze stakeholder eeds ca result i proposig updates to the user requiremets baselie. However, the textual requiremets are formally updated ad cotrolled i the exteral requiremet repository ad chages are propagated to the SysML model thaks to the sychroizatio mechaism 4.4. System ad compoet requiremets iside the SysML model Requiremets produced durig SysML modelig activities are ot reformulated i atural laguage ito a exteral cetralized repository. As a cosequece, ad compoet level requiremets are located iside the SysML model, takig beefits from iteral traceability liks with other model artefacts. The stadard SysML requiremet object beig maily limited to a idetifier ad a descriptio field, it has bee ecessary to add complemetary attributes, for efficiet requiremet maagemet. The figure bellows shows these additioal fields added by the Valeo profile, usig tag defiitios. Requiremets Attributes igure 07: Stereotyped Requiremets Attributes Aother approach uder ivestigatio, but ot used o the first pilot projects, is to limit the use of SysML requiremets to o fuctioal requiremets. The, fuctioal requiremets are represeted by SysML artefacts attached to costitutive blocks, typically by operatios ad states. More tha avoidig reformulatig fuctios (described by operatios) or states ito fuctioal requiremets, this approach also saves the cost of declarig traceability relatioships betwee structural elemets ad related fuctios. Ideed, operatios ad states are already tightly liked to their owig blocks SysCARS traceability model The traceability model adopted i the SysCARS methodology has bee pragmatically defied takig ito accout the features of the SysML modelig tool ad the kid of verificatio that could be later performed. The mai rules used for defiig traceability relatioships are the followig: Derive is used betwee two levels of requiremets Refie is used betwee a use case or a sceario ad the requiremet elicitated Satisfy is used betwee a model artefact (state, port, operatio, block) ad the requiremet implemeted Trace is used betwee two represetatios of the same item, either refied betwee modelig levels or reformulated at the same level Page 5/0

6 B CONTEXT (BDD) INTERACES (IBD) B2 B. B.2 B2. B2.2 a c e PBS (BDD) b d USAGE (UCD) Itet Itet2 Service Service2 SERVICES (UCD) B. B2. c d B.2 a INTERACES (IBD) Mod3 Mod State3 State B2. B.2 B2.2 c d ALLOCATION a b DECOMPOSITION a b e d DECOMPOSITIONS (AD) Mod Mod3 MODES (STM) State State3 STATES (STM) DECOMPOSITION ALLOCATION Mod2 State2 The figure below represets the correspodig SysCARS traceability scheme. Stakeholders Needs Defiitio Requiremets Aalysis Logical Desig Desig (cotext) System (physical) SATISIES System (physical) UserReqs a b c d SysReqs CompReqs (cotext) 2a 2b 2c 2d 4b 4c 4d SATISIES REINES REINES SATISIES DERIVES DERIVES SATISIES SATISIES 3a SATISIES SATISIES igure 08: SysCARS Traceability Scheme Refie ad Satisfy relatioships shall coect artefacts developed at the same modelig stage, while Derive ad Trace relatioships are also capable of likig artefacts of eighbourig levels Traceability aalyses The requiremet traceability verificatio activities are ivoked throughout the whole egieerig process. I fact, two kids of traceability aalyses are performed: Iteral traceability aalysis betwee SysML model artefacts, directly geerated usig the SysML tool, Exteral traceability aalysis, betwee the distributed requiremet repositories, doe usig a geeral purpose requiremet traceability tool such as Reqtify. Iteral traceability aalyses are the edig activities performed at each stage of the workflow to verify the model cosistecy (refer to gree states of the workflow diagram, [figure 02]). They use requiremet tables ad traceability matrices to check the coverage of all requiremets by appropriate model artefacts, i accordace with the traceability model preseted at the previous paragraph. These matrixes ad tables are geerated o demad at Excel format Towards modelig rules verificatio I future projects, it is pla to use a modelig rule checker to automatically verify the cosistecy ad the completeess of the model, i accordace with the traceability scheme. The idea of these rules is to check that each kid of requiremet is effectively covered, ad covered by the appropriate modelig artefact. The verificatio rules will be based o several properties of the SysML objects ad relatioships: Category of object, Value of the stereotype idicatig at which modelig stage the object has bee produced, Values of its specific qualificatio attributes, Type of relatioship used betwee objects. A typical rule should be writte uder the followig format: Each requiremet of this level ad of this type shall be covered by this category of object, with this type of relatioship, the liked objects beig respectively produced at these modelig stages. 5. Couplig to cotrol desig tools The issue of couplig a SysML tool to disciplie related tools (ad particularly simulatio tools) is ot studied i geeral but limited to couplig to cotrol desig ad software developmet eviromets, ad particularly to Matlab/Simulik. 5.. Static verificatio rather tha cosimulatio Some approaches promote use of the SysML model as a itegratio framework for buildig a whole executable model, i order to aalyze the dyamics of the. To support this, the static modelig eviromet must be upgraded by executio mechaisms, with closed coectio to disciplie specific simulatio tools. This way has ot bee chose at Valeo s for several reasos: A higher degree of sophisticatio of the SysML eviromet would go agaist a wide adoptio by (geeralist) egieers. Somehow, there is a cotradictio betwee flat deep detailed modelig ad the layered refiemet approach promoted by egieerig. Simulatio ad co-simulatio capabilities of SysML tools are quite limited compared to domai specific tools. or large scale, a full itegratio simulated model is practically itractable. The fial objective beig the verificatio ad validatio of the whole model, a static verificatio of traceability properties, as discussed i previous paragraphs, has bee preferred. The purpose is the to gai maximal cofidece i the completeess of the itellectual progress which led to the physical architecture solutio. I a secod time, as explaied i the ext paragraph, each compoet will be refied (ad possibly simulated) idepedetly i its disciplie related developmet (ad possibly modelig) eviromet, based o iput data from the model Trasfer of structure descriptio to Simulik The problem of collaboratio betwee SysML ad Simulik is ot stated i terms of (co)simulatio but rather i terms of efficietly trasferrig ad Page 6/0

7 sychroizig modelig data betwee both eviromets. The sychroizatio at architecture descriptio level was prove to be a efficiet way to trasfer iformatio betwee egieerig teams ad cotrol desig teams. I practice, the approach selected for pilot projects was to trasfer the IBD structural descriptios of cotrol law compoets, from SysML towards Simulik. The resultig Simulik models, iitially correspodig to empty structures are further refied, ad cotrol algorithms implemeted, simulated ad validated iside the Simulik modelig ad executio eviromet. The two figures below show a example of sychroizatio betwee a SysML Iteral Block Diagram ad Simulik dataflow model. ibd Detailed Desig [VehicleEergyMaager] vem_carame : CANBusCotroller Carame IceTorqueRequest BatteryVoltage VehicleAcceleratio AccelPedalPositio ElectricTorqueRequest BatteryVoltage VehicleAcceleratio AccelPedalPositio «block» «Block» VehicleEergyMaagemetUit-VEMU : BatterySOCEstimator : TractioCotrolMoitor : TorqueRequestEstimator BatterySOC TractioStatus TractioStatus TorqueRequest BatterySOC : IceElectricBalaceMaager TorqueRequest IceTorqueRequest ElectricTorqueRequest igure 09: SysML Cotroller (IBD) ElectricTorqueRequest IceTorqueRequest CANBusCotroller bc BatteryVoltage VehicleAcceleratio AccelPedalPositio BatteryVoltage VehicleAcceleratio AccelPedalPositio BatterySOCEstimator bsocm TractioCotrolMoitor tcm TorqueRequestEstimator tre BatterySOC TractioStatus TorqueRequest IceElectricBalaceMaager TractioStatus ElectricTorqueRequest BatterySOC TorqueRequest igure 0: Simulik Cotroller (Dataflow) iebm IceTorqueRequest At the ed of cotrol desig activities, Simulik simulatio results are summarized by measures of efficiecies (MoEs) fially attached as values to the correspodig SysML block. Artisa Studio provides the mai features required to sychroize ad update efficietly SysML structural models ad Simulik models: chages ca be propagated i both directios. However, extesios i the existig mechaisms would be ecessary for a full iteroperability betwee both eviromets. These suggested evolutios are preseted i the ext paragraph Mappig betwee SysML ad Simulik structural artefacts The table below presets the detailed mappig for a efficiet sychroizatio of structural descriptios betwee SysML Iteral Block Diagrams ad Simulik Dataflow models. Curretly existig features of Artisa Studio are writte i stadard fot, while suggested extesios are writte with bold characters. SysML Iteral Block Diagram Block Part low port (i) low port (out) Coector Name of the coected out flow port Item flow Block descriptio Sequece diagram Simulik Dataflow model System MDL Model Referece Sub- Iport Trigger port Outport Coectig lie Coectig lie ame (Sigal ame) Documetatio block Sigal builder igure : Mappig Betwee IBD ad Simulik The mai madatory evolutios required are related to the ability to deal with Simulik evets ad ot oly with cotiuous flows. Ideed, evets are atically used to specify cotrol flow mechaisms of algorithms. Therefore, it should be at least possible to map SysML (i) low Ports oto Simulik trigger ports (with fuctio call trigger type optio). The ability to trasfer ames to Simulik flow lies is also madatory, because i most situatios they are used as variable ames by automatic code geeratio tools. It would be potetially very iterestig to trasfer data related to the expected behaviour of the algorithm. SysML sequece diagrams describig test cases could be traslated ito Simulik sigal builder blocks. The Simulik eviromet itself could also be improved with the capability to declare traceability liks from Simulik sub-s towards SysML artefacts, ad particularly requiremets. These liks could be declared directly betwee tools or via a itermediate XMI file. Page 7/0

8 UNUSED IN CORE STREAM (SysCARS-CS) B ACTORS (BDD) INTERACES (IBD) B2 B. B.2 B2. B2.2 a c e PBS (BDD) b d USAGE (UCD) Itet Itet2 Service Service2 SERVICES (UCD) B. B2. c d B.2 a INTERACES (IBD) ALLOCATION Mod3 Mod State3 State a b e d DECOMPOSITIONS (AD) B2. B.2 B2.2 c d a b DECOMPOSITION ALLOCATION Mod Mod3 MODES (STM) State State3 STATES (STM) Mod2 State2 6. uctioal safety hadlig with SysCARS The ew regulatio ISO26262 focusig o uctioal Safety, requires a higher level of formalizatio ad traceability, ad promotes the formalizatio of techical safety cocepts i order to validate architectures regardig safety expectatios. This part focuses o the ogoig SysCARS evolutios to support Safety I the Loop (SaIL). 6.. Geeral System egieerig shall recocile all the differet aspects of the to be desiged. Amog the multiple poits of view, uctioal safety is a key oe. The fial architecture shall itegrate both ad fuctioal safety expectatios. Therefore safety ca ot be addressed separately i a parallel ad discoected egieerig domai. Despite followig a regular egieerig process, uctioal safety uses dedicated aalyses to achieve safety demostratios. I the rest of the chapter, focus is dedicated to major sychroizatio poits, exchaged artefacts ad impacts regardig SysCARS process ad tools System & safety process backgroud Performig process steps i the field, it appears that egieerig has a atural tedecy to focus more o fuctioal ad omial operatios, while uctioal safety focuses o malfuctioig ad degraded operatios. SysCARS is supportig both, ad provides guidace for techical safety cocept formalizatio as required by ISO26262: At Stakeholders Needs defiitio level Key egieerig artefacts: specific scearios related to critical safety cotexts or degraded operatios specific safety modes, related performace ad availability of fuctios SysCARS artefacts: usig regular diagrams but dedicated to safety focus ad iteractios Safety scearios are a coveiet way to capture i which coditios, malfuctios ad safety goals are idetified durig Hazard aalyses At Requiremet aalysis level Key egieerig artefacts: safety requiremets refiig previous uderstadigs to defie safety expectatios specified exteral iterfaces related to upper level safety mechaisms SysCARS artefacts: usig regular diagrams but dedicated to safety focus ad iteractios Safety goals/requiremets geerally use a somehow egative form (e.g. for a Electroic Power Steerig, avoidace of higher torque assist tha requested). While egieers are flowig dow positive requiremets (testable ), fuctioal safety egieerig cosists i: trasformig such egative goals ito techical safety requiremets allocated to implemetatio techologies (HW, SW, ) applyig prove desig patters (e.g. safety mechaisms) durig desig of techical safety cocept to achieve this trasformatio Safety goals ad requiremets are implemeted with regular SysML requiremets ad additioal attributes (ASIL, related cotext ) At Logical architecture desig level Key egieerig artefacts: breakdow of provided services ito iteral fuctios with flow dow of ASIL I geeral, due to a high level of reuse i the automotive projects, the logical architecture, as previously metioed, is ot see as a valuable step, except for iovatio projects with itermediate capitalizatio eeds regardig allocatio o multiple physical cadidate architectures. The same applies to safety, where the major objective is to esure the lik betwee high level requiremets ad fial implemetatio. urthermore the ASIL decompositio, havig to demostrate o iterferece, makes oly sese takig ito cosideratio hardware characteristics. Defie Stakeholders Needs Aalyze Requiremets uctioal Architectural Desig trasferred to Architectural Desig BMT (Simulik) a b c d (cotext) Services for Hazard Aalysis (PHA) 2a 2b 2c 6b System (physical) System (physical) 3a 4b 4c 4d (cotext) validated by MEA igure 2: SysCARS-CS couplig to safety activities At architecture desig level Key egieerig artefacts: ASIL decompositio oce iteral fuctios are allocated to physical parts ASIL of iteral parts ad iterfaces (due to highest ASIL fuctio allocated) Page 8/0

9 itroductio of additioal parts related to required safety mechaisms techical safety requiremets impactig specific disciplie SysCARS artefacts: customizatio of IBDs with specific visual stereotypes to highlight safety related parts I SysCARS-CS, iteratios are achieved betwee fuctioal decompositio ad physical architecture to work out the relevat decompositio depth ad esure the mappig. The same process is used to iterate ad itroduce additioal safety mechaisms. Iteractios ad shared artefacts System ad safety poits of view are completig each other, erichig the same artefacts which shall be kept cosistet i a commo referetial. Cosiderig process iteratios, a iitial set of scearios, iteral fuctios, physical parts is released by egieers, ad the modified or completed by safety egieers to meet safety expectatios. Settig up SysCARS as a commo backboe to couple ad safety egieerig solves these issues Safety specific verificatios Whereas ad safety geerate commo desig artefacts, discrepacy occurs whe takig ito accout safety related verificatios. ailure Modes ad Effects Aalyses (MEA) To check the safety relevace of a give architecture (fuctios allocated o physical), a commo aalysis is the MEA. Each part is cosidered as possibly beig faulty, ad occurrece of udesirable evets at scope are assessed. To achieve such aalyses, the descriptios shall be exteded to dysfuctioal modelig at part level: part, iput ad output fault modes part behaviour regardig faulty iputs, fault propagatio to outputs itrisic part fault propagatio to outputs These descriptios (together with part relatios) allow mathematical checkig of properties such as occurrece of a udesirable evet. urthermore, workig out dysfuctioal behaviour per each part of the architecture allows: to eable computer aided verificatio of the architecture usig MEA priciples to capitalize dysfuctioal behaviour per part ad therefore ease reuse of architecture subsets withi ew s a easier peer reviewig of dysfuctioal descriptios (per part), whereas review of traditioal MEA is difficult ault tree aalyses (TA) While MEA is a deductive approach, allowig to verify compliace of a give architecture regardig all udesirable evets (bottom up), TA is a top dow approach (iductive) doe per udesirable evet workig out relevat cotributig faults. Automated MEA verificatio may output a TA likig udesirable evet to the relevat faults withi the architecture (issues uder work). This feature appears to be a major lever for efficiet deploymet of the ISO26262, while traditioally TA ad MEA are cocurretly doe. urthermore, the merged TA is a key eabler to move forward quatitative aalyses. To draw TA trees, either geerated from architecture verificatio or doe by had from top to dow, specific profiles have to be set up i the SysML editor. System decompositio Hazard aalysis MEA MEA eared evet Geerated TA Geerated TA Geerated TA Geerated TA E Merged TA igure 3: TA Geeratio from SysCARS 6.4. Process ad toolig cosideratios rom a process poit of view, the key shared artefact is the physical architecture (key iterface betwee levels as well), icludig allocated techical fuctios, ad completed with dysfuctioal iformatio. Dysfuctioal descriptios i process Such approach already exists i some idustrial domais ad tools are available i order to achieve such safety architecture verificatio (e.g. usig the Altarica laguage ad model checker). These studies are i geeral performed by safety modelig experts. The ivolvemet of desiger is reduced to providig iformatio durig iterviews. This process ad required safety modelig skills are a major show stopper for automotive deploymet. The SysCARS objective is to tightly couple egieerig domais. System desigers are the oes who best kow both fuctioal ad dysfuctioal behaviour. Therefore, dysfuctioal modelig shall be itegrated i their processes (at least for iitial versios, later completed by safety experts). Page 9/0

10 Thus, a pragmatic dysfuctioal formalizatio is uder study, which will be a subset of Altarica available cocepts, also takig beefits from York TPC research ad usig as much as possible easy otatios such as Boolea algebra. Trasformatio to Altarica tools (or others) with geeratio of the required code (takig ito cosideratio safety desig patters or fuctios typologies) is targeted SysCARS-SaIL status While lessos leared have cofirmed SysCARS capability to formalize ISO26262 techical safety cocepts, extesio is required to seamlessly implemet SaIL cocept (Safety I the Loop). Itroductio of dysfuctioal modelig ad couplig to safety tools, will allow efficiet safety architecture verificatio. Valeo iteral effort is completed by collaboratively addressig these topics i the framework of Europea projects such as SAE (ITEA2, Safe Automotive sotware architecture). 7. Coclusio Learig o Valeo pilot projects have cofirmed that the SysML laguage offers a adequate lever to exted the modelig practices to the area of System Egieerig icludig fuctioal safety aalyses. Valeo experieces have show that a successful approach requires a precisely defied modelig methodology (SysCARS). urthermore, the customisatio of existig tools i a workflow drive midset is madatory. However, further improvemets remai ecessary o commercial tools regardig ergoomics ad iterfacig with simulatio ad safety aalyses tools. 8. Acroyms AD Activity Diagram ASIL Automotive Safety Itegrated Level BDD Block Defiitio Diagram CND Compoet Needs Documet MEA ailure Mode Effects Aalysis TA ault Tree Aalysis TPC ault Trasformatio ad Propagatio Calculatio GUI Graphical User Iterface HW HardWare IBD Iteral Block Diagram ISO26262 Automotive uctioal Safety Regulatio ITEA Iformatio Techology for Europea Advace MBSE Model Based System Egieerig MDL Simulik file extesio MoE Measure Of Effectivess REQ REQuiremet Diagram SAE Safe Automotive sotware architecture SD Sequece Diagram SND Stakeholders Needs Documet STM STate Machie diagram SaIL Safety I the Loop SyDD System Desig Documet SyRD System Requiremets Documet UCD Use case Diagram 9. Refereces [] Eric Adriaariso, Jea-Deis Piques: "SysML for embedded automotive Systems: a practical approach", ERTS 200. [2] raçoise Caro: "Exigeces et igéierie système : Mise e œuvre avec SysML", EIRIS Coseil, [3] A. Arold, G. Poit, A. Griffault, A. Rauzy The Altarica formalism for describig cocurret s, 2000 [4] Richard. Paige, Louis M. Rose, Xiaocheg Ge, Dimitrios S. Kolovos, ad Phillip J. Brooke: PTC: Automated Safety Aalysis for Domai-Specific Laguages, 2008 urther bibliographical refereces ca be foud i [] Page 0/0