SysML for embedded automotive systems: SysCARSS methodology

Transcription

1 SysML for embedded automotive systems: SysCARSS methodology Jea-Deis PIQUES Valeo Group Electroic Expertise ad Developmet Services 4 aveuee des Béguies, F Cergy-Potoise Cedex Tel: jea-deis.piques@valeo.com Abstract: This paper gives a overview of the five years of Valeo experiece i deployig a Model Based System Egieerig (MBSE) approach for mechatroic automotive embedded systems ad products. The differet stages are described, from iitial studies, laguage ad tool bechmarkig up to the last returs of experiece o idustrial projects. Particular emphasis is put o describig the SysCARS methodology which gives, ot oly a precise mappig of System Egieerig work items to SysML artefacts, but also the sequece of modelig activities to be performed. It is show how the SySCARS methodology has bee implemeted as a SysML profile, based o a powerful workflowuser durig the drive mechaism, which helps the modelig process. Fially it is preseted how iteroperability is esured with the tools already i place for requiremets maagemet ad cotrol desig. Keywords: Model-Based System Egieerig (MBSE), System Modelig, SysML, System Egieerig, SysCARS.. Motivatios. Itroductio ad overview Durig desig ad validatio stages of automotive products, icreasig complexity of techical systems, global orgaizatios, busiess models ad safety regulatio (ISO 26262) equires higher formalizatio efforts tha i the past. Stadard System Egieerig processes (ISO 5288, IEE 220, ) are prove solutios to achieve the high level of quality targeted. These methodologies have bee successfully used particularly i aerospace ad railway trasportatio idustries. However, the implemetatio of these processes with a traditioal documet cetric approach leads to a huge effort i updatig the documetatio whe customer chage requests cotiuously occur; which is particularly the case for icremetal developmet cycles ivolved i the automotive idustry. The Model Based System Egieerig (MBSE) approach is a key lever for the automotive idustry to cope with all these issues, while improvig agility ad R&D efficiecy o iovative products. Ideed, the model is used as a (semi-)formal descriptio of the product requiremets shared by all project stakeholders, ad as the uique source for o- demad automatic documetatio geeratio..2. Mai lessos leared Although SysML has become the de facto stadard for MBSE, a supportig methodological backgroud was ad is still madatory. The related Valeo experiece is preseted i Chapter 2, startig from the formalizatio of System Egieerig processes ad methods ad edig with the developmet of a specific customizatio, to cope with the weakesses of the curret tools. The SysCARS methodology [], which is summarized i Chapter 3, defies the sequece of SysML diagrams ad artefacts to be released, i order to implemet the egieerig process. However, pilot projects have show that this guidelie was ot sufficiet ad cosequetly other critical issues have bee addressed. A major issue is the adoptio of SysML existig modellig tools 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 Chapter 4 ad is implemeted by a Valeo profile, icludig ergoomic macros for the Artisa Studio modeler. Movig from a documet cetric approach to model based egieerig should also esure the formal couplig with requiremet maagemet tools. Chapter 5 addresses these aspects, defiig a strategy regardig traceability checks ad coectio to dedicated tools such as DOORS ad Reqtify. Also to facilitate adoptio ad due to weakesses of SysML compared to disciplie modelig / simulatio tools, SysCARS supports sychroizatio of structural diagrams. This feature is described i Chapter 6 ad is used to perform behavioural studies i legacy tools such as Simulik. Figure 0: Model-Based System Egieerig at Valeo ERTS Piques Page /7

2 2. Valeo experiece of usig SysML Valeo experiece of usig SysML ad related works were iitiated five years ago. 2.. Process defiitio Util recetly, the low complexity of the automotive products historically maufactured by Valeo did t require ay System Egieerig approach. This is the reaso why either System Egieerig stadard processes or the related techiques ad tools were precisely kow. The ew Valeo strategy focusig o products miimizig the CO2 emissios of cars, aturally leads to the developmet of high added value complex systems. It was clear that the traditioal processes, methods ad tools were o loger adequate ad a breakthrough was ecessary to build a real System culture iside the Valeo group. A trasversal workig group was put i place, cosistig of represetative experts from the relevat busiess groups of Valeo. This group, called System & Product Techical Focus Group was helped by exteral cosultatss familiar with System Egieerig practices deployed i other idustries such as aerospace ad railways trasportatio. Based o these mixed competeces, the workig group defied egieerig processes ispired from iteratioal stadards (ISO 52888, IEE 220, EIA 632, ) but totally adapted to Valeo s midset ad automotive costraits. The corerstoe of this referetial was a documet etitled System Developmet ad Validatio Process, describig the System Egieerig process as adapted to Valeo culture, with examples ad hits to make it uderstadable by people ot familiar with this domai. It was also completed with guidelies ad templates of work products. Figure 02: Valeo System Egieerig process 2.2. Role defiitio ad orgaizatio I the field implemetatios of the System Egieerig métier were also very differet depedig o the eeds of the various Valeo Busiess Groups. I may situatios, the System Egieerig activities were ot at all idetified ad there were o System team explicitly i charge of defiig the best product architecture trade-off, prior to implemetatio level activities (software, hardware, mechaics). The system desig was the etrusted to oe of the implemetatio teams ad geerally ot really formalized. To cope with these issues, the System & Product Techical Focus Group defied a geeric mappig of System Egieerig activities to typical roles ad resposibilities well established iside Valeo orgaizatio. This mappig was based o geeric job descriptios geerally used i the System Egieerig commuity (e.g. system architect, requiremets egieer, product maager, ). Startig from these idicatios, each Product Group has the ability to defie customizatio rules to put i place the System orgaizatio best fitted to the costraits of its product lie Tool selectio Some members of the System & Product Techical Focus Group were coviced that implemetatio of System Egieerig processes usig a documet cetric approach was urealistic i the automotive domai, with cotiuously chagig iput requiremets ad very short time to market. Therefore, ivestigatios were performed i the Powertrai Systems Busiess Group, o methods ad tools that could substatially help i deployig effective System Egieerig processes. Cosiderig that the key poit is performig architecture desig ot maagig requiremets, the focus was put o ivestigatig architecture modelig tools ad ot o requiremets egieerig oes. The first stage of the tool selectio process was to choose betwee tools with proprietary approaches ad those based o the SysML laguage. Eve if specialized architecture modelig tools (e.g. CORE) could have very iterestig features ad userbuilt upo the SysML friedly GUI, the tools laguage were preferred, due to their higher potetial for evolutio ad iteroperability. Ideed, the SysML laguage beefits from iputs from the whole System Egieerig commuity ad has the huge advatage of beig stadardized by OMG. Moreover, while still sufferig from isufficiecies, the XMI iterchage format offers the opportuity to migrate (most of the) SysML data from oe tool to aother tool, if required by the idustrial costraits. Last but ot least, learig SysML is ow geerally itegrated ito the traiig courses of egieers; which will make ewly graduated egieers immediately efficiet i their first professioal eviromet. The secod stage of the tool selectio process was to choose the SysML modelig tool best adapted to Valeo s expectatios. After a pre-selectio, based o aswers to a questioaire set to SysML tool vedors, a detailed bechmark was performed o the three emergig SysML modelers. ERTS Piques Page 2/7

3 Both the pre-selectio questioaire ad the detailed bechmark were based o the same weighted criteria: Exchagig data with existig tools: Particular focus was put o exchagig data with requiremet maagemet tools (DOORS, Reqtify, ) ad automatic documetatio geeratio - Sychroizig architecture desig descriptios with Simulik was also expected. Ergoomics ad geeric features: Stress was put o cofiguratio maagemet ad cotrol of user access ad rights - Ergoomics ad model readability were also madatory expected properties - Ability to customize the iterface ad the workflow (ergoomic profilig) to make the easier to use, was also a strogly expected property for deploymet. System Modelig specific features: Emphasis was put o the ability to check SysML laguage correctess, with cotextual help to assist the user - Simulatio iteral to the SysML tool ad autocodig from UML were ot madatory features. Techical ad methodological support: Techical ad methodological support from the tool vedor were cosidered as particularly importat for efficiet deploymet. Cost of deploymet: Lower cost of deploymet was (of course) wished for, o the basis of highed floatig liceces for System architects ad low-ed stadaloe liceces for other System stakeholders. SysML stadard coformity: Coformity to SysML. specificatio (October 2008) ad later evolutios was madatory. Two tools emerged from the selectio process: Artisa Studio from Atego ad Rhapsody from IBM. Artisa Studio was preferred because it was best adapted to Valeo s iteded use ad rakig criteria. It is importat to otice that at the time whe the bechmark was performed (2009), ope-source alteratives were ot cosidered as mature ad reliable eough for a idustrial deploymet. Fially, the last stage of the tool selectio process was to verify i detail the features of the selected tool, by implemetig a wide scope example (i.e. powertrai maagemet system) SysML tool profilig Despite the high potetial of the selected SysML modeler, it was idetified from the very begiig that tool customizatios would be madatory prior ay efficiet usage by geeralist System Architects. Two cocurret approaches were the competig: Either developig a Domai Specific Laguage (DSL) completely maskig the uderlyig SysML laguage, by usig Valeo s ow termiology ad sematics specific to automotive embedded systems, Or keepig the origial SysML sytax while providig a guided approach for usig efficietly the right SysML diagram at the right aalysis stage. The secod approach was preferred because Valeo s maturity o Model Based System Egieerig processes was ot estimated to be sufficiet to defie its ow DSL, ad also because usig origial SysML sytax is a efficiet way to take beefits from the commuity of users, ad i particular from youg egieers already familiar with SysML. Cosequetly, i a first step, the so-called SysCARS ( System Core Aalyses for Robustess ad Safety ) methodology was developed to defie a precise mappig betwee the sequece of System Egieerig activities to be performed ad the SysML modelig artefacts ad diagrams to be used. I a secod step, the SysML tool was customize to implemet the SysCARS methodology, thaks to the profilig mechaism available i the tool. The SysCARS methodology is described i more detail i chapter 3, with its uderlyig workflow-drive implemetatio i chapter Pilot projects The SysCARS methodology ad the related SysML profile have bee validated ad optimized thaks to the pilot projects carried out durig the last three years. These differet projects allowed the coverage of a wide spectrum of problematics: Differet kids of product lies (e.g. combustio egie maagemet systems, electrical ad hybrid vehicle subsystems, steerig colum lock systems, electrical power steerig systems, tractio cotrol systems, wipig systems), with differet preferetial modelig viewpoits, Differet project typologies, from advaced studies focused o user requiremets capture ad architecture trade-off aalyses, up to idustrial projects focused o customer requiremets traceability, Differet System orgaizatios. Of course, these pilot projects led to the improvemet of the SysCARS methodology ad of its implemetatio iside the SysML tool. They have also cotributed to a better defiitio of the role of the System Architect, as ot just limited to requiremets maagemet but also icludig the completio of trade-off aalyses ecessary for product architecture optimizatio Traiig Amog the issues faced o the pilot projects, the mai oe was the slow learig curve of automotive egieers, due to the complexity of SysML modelig eviromets. The SysCARS methodology ad the ERTS Piques Page 3/7

4 GROUPING ALLOCATION related SysML workflow-drive profile partially solved the problem, but a efficiet traiig course remais a madatory pre-requisite. The Valeo iteral traiig course is divided ito three mai modules: System Egieerig basics: This traiig is dedicated to acquirig backgroud kowledge o System Egieerig ad related stadard processes, methods ad tools. SysCARS methodology: The objective of this traiig is to preset SysCARS methodology cocepts idepedetly from ay tool implemetatio, makig comparisos with well kow methods traditioally used for fuctioal aalysis. SysCARS practice with SysML: This traiig is dedicated to acquirig practical skills i usig the SysML Valeo profile o a case study coverig the whole scope of the SysCARS methodology. After that, traied people are also helped o their iitial project, by meas of o the job traiig. I this cotext, the first step is to build the skeleto of the SysML model with the traier. The latter also periodically reviews the model at differet maturity steps ad provides assistace for tricky tasks, such as coectio to existig requiremet maagemet tools or cofiguratio for automatic documetatio publishig Deploymet Sice the ed of 202, the model-based SySCARS methodology have bee used at a idustrial level for desigig a electrical power steerig system, with start of productio plaed for 204. Other idustrial applicatios are plaed to start this year, i other product lies. 3. SysCARS methodology overview SysCARS (System Core Aalyses for Robustess ad Safety) is a Valeo methodology which provides a practical help for system desigers o how to perform the sequece of System modelig activities with SysML. However, its methodological backgroud also makes sese idepedetly from ay tool implemetatio. 3.. 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 (leadig to the optimizatio of the learig curve), Providig defied sematics related to 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 Dassault Systèmes) for requiremet traceability or Simulik (from The Mathworks) for fuctioal modelig The curret methodology [][2] is therefore targetig the optimum trade off for Valeo deploymet ad it 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 [3][4]. This implemetatio is also takig maximum beefits from available features of the selected SysML tool, amely Artisa Studio from Atego SysCARS workflow The overall System Egieerig process begis by aalyzig the project cotext, cosiderig the system to be developed as a black box, ad the successively goes deeper ito the details util specifyig iteral compoet (or system elemet) features. More precisely, the SysCARS methodology is divided ito five major phases: Stakeholder eeds defiitio Requiremets aalysis Logical architecture desig Physical architecture desig Compoets eeds defiitio The related SysCARS workflow is described below. Stakeholders Needs Defiitio Requiremets Aalysis Logical Architecture Desig Physical Architecture Desig a b c d Cotext Exteral Iterfaces Iteral Fuctios Usage Mai Services User Scearios 2a 2b 2c 2d 3a 4a Cadidate Solutios 3b Logical Architecture System Scearios Log Iteral Iterfaces 4b 4c 4d Physical Phy Physical Iteral Phy Physical Iteral Physical Architecture Physical Iterfaces Physical Physical Iteral Scearios Iteral Architecture Iteral Iteral Architecture BDD Iterfaces IBD Scearios SD Iterfaces Scearios Figure 03: SysCARS methodology Modes BDD UCD SD STM IBD States For 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 systematically 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: UCD 3c AD BDD IBD BDD SD STM SND SyRD SyDD ERTS Piques Page 4/7

5 Stakeholder Needs Documet, SyRD: System Requiremet Documet, SyDD: System Desig Documet, CND: Compoet Needs Documet). The last stage (Compoet Needs Defiitio) has ot bee represeted, because it is maily a extractio of compoet artefacts from the physical architecture, producig oe specificatio for each compoet. O the [figure 03], the kid of diagram used at each step is give by its SysML acroym attached to the related activity: 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): For iovative products, the whole set of activities of the [figure 03] are performed, ad i particular the ivestigatio of several physical architectures ad trade-off aalyses. SysCARS-CS (Core Stream): For carry over products, the activities represeted by grey boxes o the [figure 03] are ot performed I the followig of this chapter, for a clarity purpose, oly the SysCARS-CS simplified workflow is preseted. It is also importat to otice that the ames of paragraphs below are the same as those used i the workflow diagram preseted at chapter Stakeholder eeds defiitio Probably the most importat step i a system developmet process is collectig iitial eeds to secure the goals that the system uder developmet is to pursue. The key steps of this phase are: Idetify all the stakeholder eeds, Defie the boudaries of the system ad exteral actors ivolved, Idetify ad describe the operatioal use cases, Idetify the user level operatig modes, Lik the stakeholder requiremets to the operatioal use cases. At this stage, all the aalyses are performed from the system exteral user poit of view, the system beig cosidered as a black box. The output of this phase is the Stakeholder Needs Documet (SND), which makes a sythesis of all the activities performed Stakeholder eeds elicitatio (REQ) All idividuals ad orgaizatios that may have a iterest i the system are the potetial source of requiremets ad therefore should be idetified prior to all other activities. The key poit is that stakeholder eeds should describe the services expected by the system user, ad ot how the system will fulfill these eeds. The sources of stakeholder eeds will be maaged outside of the SysML model, withi requiremets documets or specific databases. It is particularly importat to capture missio-level performace requiremets ad measuremets of expected performaces that will be used later to select the best oe amog the cadidate solutios. The ext step is to import stakeholder eeds (with all their relevat fields) ito mirrorig SysML requiremet objects (with same idetifiers). A gateway mechaism, such as those implemeted by Reqtify, is required to perform a moo-directioal sychroizatio (from exteral data to SysML) i case of chage of source data. Because the stadard SysML requiremet format is quite limited, the extesio mechaism of stereotypes is used to add ew specific attributes (i.e. tags) to keep track of extra iformatio resultig from aalyses performed durig elicitatio. A particularly importat tag attached to requiremets at elicitatio stage is dedicated to classifyig requiremet ito oe of the three followig categories: user related, system related or compoet (i.e. system elemet) related. This value coditios at which modelig level the requiremet will be later covered Cotext aalysis (BDD) The system cotext diagram represets the direct eviromet of the system ad gives iitial iformatio about the system boudaries ad the iteractios betwee the system ad exteral systems ad users. The first step is to idetify the differet stages of the system lifecycle, from maufacturig to recyclig. For each stage of the system lifecycle, oe SysML block defiitio diagram is declared to model the associated operatioal cotext. The system itself appears i the ceter of the diagram as a sigle black box SysML block. The ext step cosists i represetig all curretly kow iteractig parters, usig SysML actor objects. A actor is ot ecessarily a cocrete idividual or system, but a role played by a outside elemet i iteractio. The, iteractios betwee actors ad the system are represeted as SysML associatio relatioships. The purpose is to idetify basic iformatio helpful to determie the services requested from the system embedded i its eviromet, ad ot to give techical details of these services. Costraits o these services are ERTS Piques Page 5/7

6 documeted i the descriptio field of the associatio relatioships. bdd Operatioal Cotext [Hybrid Vehicle] «Primary» Driver Drives «Primary» User Reloads Eergy Fuellig Statio Provides Fuel «Cotext Block» Hybrid Vehicle (Cotext) * Provides Electricity Electrical Statio Moves o Road Cotact Figure 04: Operatioal cotext diagram High Voltage Statio Low Voltage Statio Eve though, defiig the cotext diagrams may seem obvious, i practice, searchig for actors ca lead to very fruitful discussios for defiig resposibilities betwee the differet stakeholders Cotext scearios idetificatio (UC, SD) Cotext use cases represet the services expected by the system users (people or other systems); which meas that they will be key iput elemets for the requiremet aalysis stage. Ideed, cotext use cases will help to refie stakeholder expectatios ad therefore idetify system requiremets i greater details. uc Operatioal Cotext Use Cases [Hybrid Vehicle] edig poit. These scearios describe sequeces of iteractios ad actios, begiig with the same pre-coditio (trigger) ad edig with the same post-coditio (result); the pre-coditio ad the post-coditio correspodig to modes (i.e. user states) i the user mode state machie metioed i the ext chapter. The scearios are described usig SysML sequece diagrams. The iteractios iside scearios are declared as cotext evets, also used later to defie trasitio coditios betwee states of the user mode state machie. It is particularly importat to otice that each sequece diagram established here is primarily aimed at idetifyig the system iteractios. The sequece diagram will be further refied, at requiremet aalysis stage, to idetify fuctios performed by the system User modes idetificatio (STM) A mode characterizes a situatio i the system life for which a specific expected behavior ca be defied. It represets a state ivariat of the system from the exteral user poit of view (i.e. regardig the service give to the user ad ot how this service is performed by the system). Hybrid Vehicle Modes Brakig evet_edofassemblylie/ evet_pushbrakepedal/ evet_releasebrakepedal/ evet_pushooffbutto[vehicle_speed == 0]/ Neutral Parkig Drivig evet_pushacceleratorpedal/ evet_releaseacceleratorpedal/ evet_pushooffbutto/ evet_failurerepaired/ Acceleratig Maiteace Hybrid Vehicle (Cotext) Brake evet_vehicledisposal/ evet_failuresuspected/ «iclude» evet_coectplug/ Park Vehicle «iclude» Accelerate Road Cotact evet_discoectplug/ evet_disegagefuelpistol/ evet_egagefuelpistol/ «Primary» Driver «Primary» User Drive Vehicle Fill Fuel Tak Load Electrical Battery «iclude» «exted» «exted» High Voltage Statio Figure 05: Cotext use case diagram (user level) Cotext uses cases will be idetified startig from the cotext diagrams, askig what the actors wat of the system, especially with regard to their roles ad icomig iformatio flows. More precisely, a use case always refers to at least oe actor; it is started by a exteral trigger ad it eds with a user result. Moreover, as may use case diagrams as stages of the system lifecycle will be described. I fact, a use case ca be see as a group of scearios performed by the same mai actor, with the same startig poit ad leadig to the same Start Stop Fuellig Statio Low Voltage Statio Battery reloadig Eergy reloadig Fuel refillig Figure 06: User modes state diagram The objective is to derive a uique state machie aggregatig all the modes (states) ad mai trasitios (evets) idetified i the cotext scearios. Therefore, establishig the user mode state machie is a iterative process tightly coupled ad iterleaved with the idetificatio of cotext scearios described i the previous chapter. The purpose is to describe the behaviours ivolved i all the cotext scearios, factorized ito a uique state machie. This state machie is owed by the cotext block associated to the whole black box system Cotext traceability checkig (REQ) We remember that stakeholder (or iitial) requiremets refer to statemets that defie the expectatios from the system i terms of missio objectives, eviromet, costraits ad ERTS Piques Page 6/7

7 measuremets of performace, from the system user poit of view. I order to make sure that all stakeholder eeds are covered by the cotext use cases, respective traceability liks have to be established betwee SysML use cases ad requiremets. As described i the traceability data model preseted at chapter 5.3, all requiremets that are characterized as user related shall be covered by correspodig cotext use cases, ad liked together by derive relatioships. Traceability aalyses are performed to verify the model completeess, usig requiremets tables ad traceability matrices, which are specific features of the Artisa Studio tool. req Stakeholder Needs Refimet to UC [Accelerate] Exteral iterfaces idetificatio (IBD) To keep track of aalyses previously performed at cotext level, it has bee decided to defie the system block used afterward as a specializatio of the cotext block studied at the previous stage (i.e. stakeholder eeds defiitio stage). The objective of the system iterface idetificatio step is to give more details o the iteractio flows betwee the actors ad the system (always see as a black box). The system physical exteral iterfaces are described usig iteral block diagrams, where are represeted the system block ad all the iteractig actors. ibd Exteral Iterfaces [Hybrid Vehicle (System)] IformatioDisplay : DisplayProtocol ElectricStatioCommmuicatioPort : CommuicatioProtocol StartVehicleButto : O-Off sigal Accelerate ElectricPlug : Curret Electrical Statio ZEVModeButto : O-Off sigal «refie» «refie» «refie» «Primary» Driver : Hybrid Vehicle (System) RoadCotact : Torque Road Cotact AcceleratorPedal : Cotiuous sigal «requiremet» Performaces closed to ICE vehicle id# U txt The degradatio of performaces comparatively to a ICE vehicle shall be admissible. «requiremet» Paylod capacity id# U0 txt The vehicle shall have a paylod capacity of 350 kg Figure 07: Requiremet traceability diagram Stakeholder eeds documet The last step is to lauch the automatic geeratio of a documet, makig the sythesis of all the modelig activities performed durig the stakeholder eeds defiitio stage. This documet is etitled Stakeholder Needs Documet (SND) Requiremets aalysis «requiremet» Acceleratio i ZEV mode id# U0 txt I ZEV mode, time from 0 km/h to 00 km/h shall be less tha 5 s The objective of the requiremet aalysis phase is to aalyze the iputs previously collected, i order to move from a problem statemet to a abstract solutio. The key steps of this phase are: Describe precisely the iterfaces of the system with exteral actors, Develop ad refie the system use cases, Idetify the system level operatig states, Develop ad refie the system requiremets ito exteral fuctio ad iterface descriptios, Lik system fuctios ad iterfaces to the system requiremets. At this stage all aalyses are performed from system desiger poit of view, the system still beig cosidered as a black box. The output of this phase is the System Requiremet Documet (SyRD), which summarizes all the activities performed. BrakePedal : Cotiuous sigal DiagosisToolCommuicatioPort : DiagosisProtocol Figure 08: Exteral iterfaces descriptio To specify the kid of admissible data flow, a type idicatio shall be associated with each port, usig SysML item types or flow specificatios. Several iteral block diagrams are defied to describe the differet cotexts of use. Moreover, it is also possible to defie several iteral block diagrams for the same cotext of use, each diagram correspodig to a specific kid of iterface (e.g.: mechaical, electrical, data processig buses ). This is particularly iterestig to ease iformatio sharig with ivolved disciplies ad also to avoid overloaded iterface diagrams System sceario refiemet (SD) Diagosis Tool The objective of this stage is to refie cotext level scearios, i order to idetify mai services or fuctios the system shall perform. Therefore, this activity is similar to a classical exteral fuctioal aalysis. To keep track of aalyses previously performed at cotext level, it has bee decided to keep cotext sequece diagrams itact ad to cloe them, i order to obtai iitial system sequece diagrams. The same approach is adopted betwee cotext use case diagrams ad system use case diagrams. The system sequece diagrams are the complemeted by the fuctios to be performed by the system (always see as a black box), after havig replaced the cotext block by the system block. As show o the figure below, the fuctios are modeled as SysML operatios attached to the (lifelie of the) system block. The iteractios iside scearios are declared as existig cotext evets or ew system evets, used ERTS Piques Page 7/7

8 afterward to defie trasitio coditios betwee states of the system state machie. The startig poit ad edig poit of each sceario will also correspod to states of the system state machie. «Primary» Driver heels Road Cotact evet_pushacceleratorpedal evet_powertraiwheelpositivetorque evet_releasebrakepedal :Hybrid Vehicle (System) MF-002_AccelerateVehicle MF-006_CotrolTractio Figure 09: Sceario descriptio (system level) System states idetificatio (STM) The objective of this step is to describe the behaviours ivolved i all the system scearios, factorized ito a uique state machie. This state machie is owed by the system block describig the whole black box system. evet_pushacceleratorpedal/ Hybrid Operatig Torque Assisted Acceleratig... evet_releaseacceleratorpedal/ Idle evet_icegiestarted/ Regeerative Brakig... evet_pushbrakepedal/ Stoppig Startig do : do : MF-008_StopVehicle MF-00_StartVehicle Figure 0: Sub-state of the system state machie The system state machie is ot ecessarily oly a refiemet of the user mode state machie, as possibly ew sub-states or suppressed states ad eve a completely differet structure may be defied. Practically, establishig the system state machie is a iterative process tightly coupled ad iterleaved with system scearios refiemet described i the previous chapteroce the trasitios ad states of the system state machie are well defied, a particularly importat step is to defie i which states are triggered the mai fuctios idetified i the system scearios. This is simply doe by callig the related operatios with the Do property of the correspodig states. The system state machie the becomes the cetral elemet of the system model, allowig the simulatio of its behaviour for validatio purpose System requiremet traceability checkig (REQ) As it will be discussed at chapter 5, system level requiremets are all described iside the SysML Idle Torque Assisted Acceleratig Idle evet_releasebrakepedal/ evet_pushooffbutto[vehicle_speed == 0]/ model ad ot rewritte ito a exteral (textual) requiremets repository. As ofte as possible, the SysML model artefacts (e.g. operatios, ports, states) are directly used as requiremets ; their descriptio field beig writte i a requiremet-like way. Oly o fuctioal system requiremets are modeled by SysML requiremets (at the exceptio of system related fuctioal requiremets comig from stakeholder iputs). No fuctioal requiremets cocer costraits (icludig performace target) related to existig model artefacts, such as operatios, ports, states or to the system block itself. Therefore, we ca idetify two categories of traceability liks: Implicit traceability, whe there exists a strog depedecy betwee two model artefacts (e.g. operatio owed by the system block, port owed by the system block) Explicit traceability, whe a satisfy relatioship has bee declared betwee a model artefact (i.e. operatio, port, state, system block) ad a o fuctioal requiremet of the same level or whe a refie relatioship has bee declared betwee a system level requiremet ad a user level requiremet. Durig the requiremet aalysis process, implicit traceability liks have bee geerated, while the system block has bee automatically populated with all operatios ad ports declared i the differet diagrams. Moreover, operatios are also liked to sequece diagrams where they have bee defied ad to the states which call them. Hybrid Vehicle (System) flowports iout ElectricStatioCommmuicatioPort : CommuicatioProtocol iout DiagosisToolCommuicatioPort : DiagosisProtocol i ZEVModeButto : O-Off sigal i AcceleratorPedal : Cotiuous sigal i StartVehicleButto : O-Off sigal i ElectricPlug : Curret iout RoadCotact : Torque i BrakePedal : Cotiuous sigal out IformatioDisplay : DisplayProtocol operatios MF-00_StartVehicle () MF-002_AccelerateVehicle () MF-003_RecoverBrakigEergy () MF-004_ChargeBatteryLowVoltageStatio () MF-005_ChargeBatteryHighVoltageStatio () MF-006_CotrolTractio () MF-007_DecelerateVehicle () MF-008_StopVehicle () MF-009_TorqueAssist () Figure : System requiremets as block properties (implicit traceability) Explicit traceability liks shall be declared to esure that all user level requiremets are covered by system level requiremets (derive relatioship) ad that all system level requiremets are covered by model artefacts (satisfy relatioship) of the same level. These relatioships are declared either i requiremet diagrams or directly i the object database. Justificatios related to coverage or refiemet are logged as commets iside the descriptio fields of the requiremets diagrams. ERTS Piques Page 8/7

9 req System Requiremets Satisfied By Operatios [Hybrid Vehicle Platform] MF-002_AccelerateVehicle MF-009_TorqueAssist MF-006_CotrolTractio MF-007_DecelerateVehicle MF-003_RecoverBrakigEergy MF-00_StartVehicle MF-008_StopVehicle MF-005_ChargeBatteryHighVoltageStatio MF-004_ChargeBatteryLowVoltageStatio Figure 2: Traceability to system requiremets (explicit traceability) Traceability aalyses are the performed to verify the model completeess, usig requiremets tables ad traceability matrices, which are specific features of the Artisa Studio tool System requiremets documet The last step is to lauch the automatic geeratio of a documet, makig the sythesis of all the modelig activities performed durig the requiremets aalysis stage. This documet is etitled System Requiremets Documet (SyRD) Architecture desig «satisfy» «satisfy» «satisfy» «satisfy» «satisfy» «satisfy» «requiremet» Torque assistace «requiremet» Regeerative brakig «requiremet» Start time «requiremet» Stop time «requiremet» Fast battery chargig «requiremet» Stadard battery chargig The objective of the architecture desig phase is to describe how the system will be iterally structured to perform the expected features. Withi the framework of the SysCARS-CS simplified workflow preseted here, the physical architecture is directly elaborated takig ito accout implemetatio techologies. Logical architecture desig activities are limited to idetify iteral fuctios ad there is o itermediate logical architecture. The key steps of this phase are: Idetify the set of iteral fuctios to be provided by the system elemets (or compoets), Describe how these iteral fuctios are activated depedig o the system state, Defie a physical architecture capable of performig the required iteral fuctios, Allocate coheretly the iteral fuctios to physical compoets, Develop ad refie the compoets physical iterfaces ad iteractios, Develop ad refie the related compoets requiremets, Evaluate the measuremets of effectiveess of the physical architecture. At this stage all the aalyses are made from system iteral poit of view, the system beig cosidered as a white box. The modelig elemets developed are icluded i the System Desig Documet (SyDD), which makes a sythesis of all logical ad physical architecture desig activities. The output of this phase is a also a set of Compoet Needs Documets (CND), which correspod to specificatios for the compoets (or system elemets) to be implemeted Iteral fuctios idetificatio (ACT) The objective of this step is to provide details o the iteral behavior of the operatios owed by the system block. Therefore, the kid of task performed is similar to a classical iteral fuctioal aalysis. For this aalysis, a top level activity diagram is attached to each operatio of the system block, i order to describe how the correspodig mai fuctio is implemeted by iteral techical fuctios. This descriptio may ivolve several layers of activity diagrams. The activity diagrams use data flow ad cotrol flow represetatios i a hierarchical decompositio to work out iteral activities that should be performed. The lowest level activities (amely leaves activities) of this hierarchy represet calls (call-operatio-actios) to iteral fuctios modeled by elemetary operatios. The rule to ed the hierarchical decompositio is that every idetified elemetary operatio ca be assiged to a uique system elemet (or compoet) of the physical architecture. MoitorVehicleCoditios vehtorquerequest vehcmd : IF-08_ElaborateTorqueRequest «cotiuous» vehcommads «cotiuous» vehsesors «cotiuous» : IF-020_EstimateBatterySOC BatterySOC «cotiuous» vehvelocity vehsesors : IF-09_MeasureVehicleVelocity vehtractiostatus vehtorquerequest BatterySOC vehvelocity vehtractiostatus : IF-022_EstimateVehicleCoditios vehcod vehcod vehsesors «cotiuous» «cotiuous» «cotiuous» «cotiuous» Figure 3: Lowest level activity diagram describig system iteral fuctios The key poit is that the upper level activity diagrams describig the iteral behavior are triggered by the system state machie; which will be a iterestig ad madatory property for later executio of the system model Physical architecture defiitio (BDD) vehsesors : IF-02_MoitorTractio «cotiuous» The focus of the physical architecture desig phase is o the allocatio of elemetary operatios to compoets (or parts) of a physical architectural structure. This structure may result from a previous trade-off study or be a legacy architecture resultig from may years of experiece of a product lie. It is ERTS Piques Page 9/7

10 the reaso why the elaboratio of a itermediate logical architecture (idepedet from ay techology choice) is most of the time useless. The partitioig criteria used for allocatio of iteral fuctios to compoets should reduce the impact of requiremets ad techology chages ad more effectively address key issues such as performace, reliability, efficiet re-use of COTS, maitaiability, security ad cost.at model level, a iteral physical block is declared for each compoet (or part) of the physical architecture, ad this block ows the elemetary operatios which were allocated to him. To keep track of aalyses previously performed at system level, it has bee decided to defie the upper level physical (system) block used afterward as a specializatio of the system block studied at the previous stage (i.e. requiremets aalysis stage). The, a block defiitio diagram is used to describe the physical architecture, i.e. the compositioal relatioships betwee the upper level physical (system) block ad its costitutive physical blocks. bdd Physical Architecture Breakdow [Hybrid Vehicle] Accelerator BrakePedal BatteryCharger ElectricMotorGeerator IteralCombustioEgie CANCommuicatioBus ICEgieCotroller-ICEMU icec bc acc bkp emg ice ca trm VehicleElectricPlug Hybrid Vehicle (Physical) OBoardElectricNetwork values Electric Egie Cofiguratio = Cetral Motor Vehicle cargo capacity = 350 kg ZEV mode autoomy = 70 km Hybrid mode emissio = 65 g/km CO2 ZEV mode velocity = 05 km/h emc vep ElectricMotorCotroller-EMMU Trasmissio bpc BatteryPackCotroller-BMU Figure 4: Physical architecture Physical iteral iterfaces idetificatio (IBD) The objective of the iteral physical iterface descriptio step is to provide more details o the iteractio flows betwee the iteral physical blocks, usig iteral block diagrams. Physical iterfaces betwee iteral physical blocks are represeted by ports which ca be coected either to other iteral physical blocks or directly to exteral iterfaces of the upper level physical (system) block. To specify the kid of admissible data flow, a type idicatio shall be associated with each port, usig SysML item types or flow specificatios. bp BatteryPack obe vem VehicleEergyMaagemetUit-VEMU RightFw LeftRw dcdc rr diff diff FrotDifferetial FrotWheel RearWheel DC-DCCoverter RatioReducer Differetial diff RearDifferetial ibd Electrical Physical Iteral Iterfaces [Hybrid Vehicle] bc_bpprt : BatteryVoltage bc : BatteryCharger vep_bcprt : LoadVoltage vep : VehicleElectricPlug bp_bcprt : BatteryVoltage bc_vepprt : LoadVoltage emc_bcprt : LoadVoltage vep_elplgprt : Curret ElectricPlug : Curret Hybrid Vehicle (Physical) bp : BatteryPack emc_bpprt : BatteryVoltage emc : ElectricMotorCotroller-EMMU emg_emcprt : ElectricMotorFlow emg : ElectricMotorGeerator bp_emcprt : BatteryVoltage bp_dcdcprt : BatteryVoltage emc_emprt : ElectricMotorFlow obe_dcdcprt : OBoardVoltage dcdc : DC-DCCoverter Figure 5: Physical iteral iterfaces descriptio To avoid iformatio overload o the same diagram ad to make commuicatio to a specific team easier, several iteral block diagrams will be described, each diagram correspodig to a specific kid of iterface (ex: mechaical, electrical, data processig buses, ) Iteral scearios defiitio (SD) dcdc_bpprt : BatteryVoltage obe : OBoardElectricNetwork dcdc_obeprt : OBoardVoltage The focus of black-box sequece diagrams described at system level was o the idetificatio of the system mai fuctios. Because some physical compoets may require sigificat refiemet to address disciplie-specific cocers, it may be ecessary to establish white-box sequece diagrams focusig o the collaboratio betwee the differet iteral compoets. This activity is ot systematically performed ad is oly reserved for particularly critical scearios. A white-box iteral sceario reveals iteral physical blocks o a same sequece diagram. It allows checkig that the sequetial activatio of the elemetary fuctios (operatios owed by iteral system blocks) is cosistet with the mai fuctios (operatios owed by the upper level system block) expected at system level. Moreover, a physical iteral compoet may iclude a state machie as part of its specificatio, if it has sigificat state-based behavior Physical architecture traceability checkig (REQ) The same cosideratios as those doe at chapter 3.4.4, regardig implicit ad explicit traceability liks, also apply for iteral physical blocks ad related requiremets. Therefore, the traceability checkig is performed i the same way as at the requiremet aalysis stage. Durig the architecture desig process, implicit traceability liks have bee geerated, while the iteral physical blocks have bee automatically populated by all elemetary operatios ad ports declared i the differet diagrams. Moreover, elemetary operatios are also idirectly liked to ERTS Piques Page 0/7

11 the states, which call the activity diagrams i which they appear. Regardig explicit traceability liks, they shall be declared to esure that all system level requiremets are covered by compoet level requiremets (derive relatioship) ad that all compoet level requiremets are also covered by model artefacts (satisfy relatioship) of the same level. These relatioships are declared either i requiremet diagrams or directly i the object database. Justificatios related to coverage or refiemet are logged as commets iside the descriptio fields of the requiremets diagrams. Traceability aalyses are the performed to verify the model completeess, usig requiremets tables ad traceability matrices, which are specific features of the Artisa Studio tool. The results from egieerig aalyses doe o the physical architecture are also capitalized iside the model. These iformatio ofte referred to as measuremets of effectiveess (MoEs), are icorporated ito the SysML model as value properties attached to the upper level physical block describig the physical architecture. The estimatios of MoEs result from specific aalyses performed with appropriate tools such as modelig ad simulatio eviromets ad ivolve differet aalysis objectives (performace, robustess, safety, cost ) System desig documet ad compoet eeds documets The last step is to lauch the automatic geeratio of a documet, makig the sythesis of all the modelig activities performed durig the architecture desig stage. This documet is etitled System Desig Documet (SyDD). The physical architecture model results i the specificatio of the compoets to be implemeted by each specific disciplie (e.g. hardware, software, mechaics, ). As it is ecessary to isolate relevat iformatio for each team i charge of developig compoets, there is a eed for as may specificatio documets as there are iteral physical blocks iside the physical architecture. These documets called Compoet Needs Documets (CND) are also automatically geerated, makig the extractio of all the artefacts attached to the iteral physical block uder cosideratio ad filterig ay cofidetial or uecessary iformatio Modelig difficulties ecoutered with SysML.2 Durig the differet modelig stages, some difficulties have bee ecoutered with SysML.2. First of all, we would like to have a uified sematics for iterfaces. Ufortuately there is o relatioship betwee the ports defied o Iteral Block Diagrams ad the pis used o Activity Diagrams. For each port declared for exteral iterfaces, it was ecessary to create oe correspodig pi with the same ame ad type. To keep track of the similarity of the two artefacts, a trace relatioship was declared betwee them. Moreover, readability issues appear o Iteral Block Diagrams whe the umber of ports ad coectors becomes importat. This problem was partially solved by declarig composite flows as ofte as possible, thaks to flow specificatios. Nevertheless, routig efficietly coectors remais problematic. I this area, ispiratios from tools like Simulik would be welcome, for example by addig higher level costructs such as virtual buses or Goto-From coectios, i order to avoid crossig coectors. Icludig automatic routig features would also be a valuable evolutio. I the cotext of the full SysCARS-XS workflow, difficulties were experieced whe dealig with architecture alteratives ad particularly for fuctioal to physical allocatio. We would like that the same operatio could be declared oly oce ad be owed by differet blocks, each oe beig related to a architecture alterative. Ufortuately, it was ecessary to cloe each operatio represetig the same fuctio, as may times as there were alteratives to explore. Weakesses of the XMI iterchage format are well kow ad particularly the impossibility of exchagig diagrams. However, we were very surprised to otice that some basic iformatio were ot exported (e.g. descriptios fields of some artefacts or characters differet tha ASCII oes). Therefore, it remais very difficult to trasfer properly modelig descriptios to other modelig tools or eviromets such as Simulik. 4. Workflow-drive approach 4.. A specific SysML profile GUIs of SysML existig tools remai too complicated for a o software specialist, who 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. ERTS Piques Page /7

12 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 o 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 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 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, i order to provide the user oly with the features required at this step of the system 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. Pre-defied Package Structure Embedde ed SysCARS Workflow Figure 6: 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. Workflow Meu Figure 7: Valeo profile avigatio 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 dedicated XML files. This optio eables further evolutios o the SysCARS workflow. Figure 8: Customized meus I the object browser widow, the SysCars New commad meu displayed whe right-clickig a existig SysML object, is customized idividually for each type of SysML artefact ad diagram. I case the user wishes to have access to the classic features of SysML, he ca select the stadard New commad meu. I the graphical widow, buttos available o each diagram toolbar 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 ERTS Piques Page 2/7