Download pdf - Automotive Systems Modelling with Vitruvius

ii

ldquoproceedingsrdquo mdash 2017824 mdash 1220 mdash page 1487 mdash 1487 ii

ii

ii

Maximilian Eibl Martin Gaedke (Hrsg) INFORMATIK 2017Lecture Notes in Informatics (LNI) Gesellschaft fuumlr Informatik Bonn 2017 11

Automotive Systems Modelling with Vitruvius

Manar Mazkatli1 Erik Burger1 Anne Koziolek1 Ralf H Reussner1

Abstract Model-driven technologies are widely used in the development of systems in the automotivedomain Although modelling tools and code generation increase the development speed and the qualityof the developed system in general the availability of several modelling languages for different stagesof the development process also introduces additional problems Developers use several models todescribe the same system on different levels of abstraction which serve as documentation basis forcode generation but also for model-based analyses of system properties such as security performanceor reliability If models are modified independently inconsistencies can arise which lead to incorrectresults of these analyses complicate the implementation of new features and create errors at laterstages in development that are costly to fix

In this paper we apply the model-based Vitruvius approach which preserves consistency inheterogeneous modelling environments to a scenario of automotive systems development Thescenario includes the modelling standards SysML AMALTHEA and ASCET We show at theexample of an onboard controlling unit how the Vitruvius approach can be used to increaseconsistency in automotive system development and reduce the accidental complexity that arises fordevelopers who have to work with heterogeneous modelling languages

Keywords Vitruvius view-based development process model-based development process automo-tive systems declarative description of correspondence rules

1 Introduction

The development of a technical system includes the modelling of the system from differentperspectives and at different levels of abstraction The models that are created duringthis process may be models of hardware software and additional information such asnon-functional properties Program code in general-purpose languages such as C is thenoften generated from these models

In the automotive domain for example the SysML and AUTOSAR standards are widelyused in conjunction with specific platforms such as AMALTHEA or ASCET Often there isno specified interface for the exchange of models between these standards Thus developersexchange the needed information and documentation along the development process andare often forced to manually check for consistency between the models This process is1 Karlsruhe Institute of Technology Institute for Program Structures and Data Organisation (IPD)

Am Fasanengarten 5 76131 Karlsruhe Germanymanarmazkatli|burger|koziolek|reussnerkitedu

cbe doi1018420in2017_148

Maximilian Eibl Martin Gaedke (Hrsg) INFORMATIK 2017Lecture Notes in Informatics (LNI) Gesellschaft fuumlr Informatik Bonn 2017 1487

ii


ii

ii

12 Manar Mazkatli Erik Burger1 Anne Koziolek1 Ralf H Reussner1

however expensive because a great part of the exchanged files is written by hand and thereuse of information is done using error-prone techniques eg copy and paste

During the evolution of a system developers may also alter these models independentlyof each other A modification in one of the models can lead to an inconsistent descriptionof the system if it is not manually propagated to all other models which may in turnlead to inaccurate simulations and analyses for example security or performance analysesIf inconsistencies affect the generated program code negatively this problem is only bedetected in late stages of the development process eg during the assembly phase Sincecompilation of program code can take up several hours in systems of common size thecorrection of these inconsistency errors is very time-consuming

Vitruvius [KBL13 Bur14] is a model-based approach for the development of softwarewith heterogeneous modelling standards It contains declarative languages for consistencyrelations between heterogeneous models that describe the same system which are used todetect violations and to re-establish consistency in the system model In this paper we willdescribe how we have applied the Vitruvius approach to automotive systems engineeringto improve the reliability of automotive systems We have conducted a case study thatdescribes the development of an onboard control unit for automotive systems using thelanguages and standards SysML AMALTHEA and ASCET To use these languages in theEclipse Modeling Framework which is the technical space of the Vitruvius prototypewe have selected appropriate metamodels and defined an import procedure for existingmodels To express the consistency relations between these types of models we have defineddeclarative mapping specifications in the Mappings language of Vitruvius

After a description of the foundations of model-driven engineering and especially theVitruvius approach in section 2 we will introduce our case study of an automotivesoftware controller in section 3 In section 4 we describe the application of Vitruvius inour case study After related work (section 5) and future work (section 6) we conclude thepaper with section 7

2 Foundations

21 Model-Driven Engineering

Model-Driven engineering is a development paradigm that puts models in the centre ofthe development process and uses the following concepts [Sch06] First domain-specificlanguages (DSL) express domain concepts which reduce the complexity in the modellingof systems DSLs are defined using metamodels which themselves are defined using astandardised fixed meta-metamodel Second transformations engines are used to transformthese models into instances of other DSLs or into textual representations such as code

1488 Manar Mazkatli Erik Burger Anne Koziolek Ralf H Reussner

ii


ii

ii

Automotive Systems Modelling with Vitruvius 13

The Eclipse Modeling Framework (EMF)2 is a development framework for model-drivendevelopment that is implemented using the Java-based Eclipse platform

22 Vitruvius

ASCET

AMALTHEA

SysML

VT1

VT2VT3

VT4

instance-ofSysML view

instance-of

ASCET view

Legend

VT View Type

V View

MM MetamodelConsistencyDescriptions

ModelJoin

Fig 1 The modular SUM Metamodel concept of Vitruvius at the example of automotive systemsengineering

Vitruvius [KBL13] is a view-based model-driven framework for the management ofheterogeneous models ie models that are instances of different metamodels It is basedon the concept of a single underlying model (SUM) [ASB10] which represents all theinformation that is available about the system under development and implements thisconcept into a virtual SUM (VSUM) that encapsulates existing metamodels and enrichesthem with correspondence information and custom views which are specialized modelsfollowing the definition of Goldschmidt et al [GBB12] The VSUM conforms to a customizedmetamodel that is specific to the domain in which the Vitruvius approach is used forexample in the automotive domain it may contain the metamodels of SysML AMALTHEAand other standards which are combined to form a modular SUM metamodel (see Figure 1)The metamodels are included non-intrusively and do not have to be adapted To express thesemantic relations between the elements of the metamodels Vitruvius defines a languageframework for consistency description and restoration that consists of three languagesfor reactions mappings and invariants Since Vitruvius is a view-based approach allinformation in the SUM can only be retrieved or manipulated via specialized views For thedefinition of view types and views Vitruvius uses the ModelJoin language [Bur+14]The consistency preservation mechanism is triggered by changes to one or several viewsThe preservation mechanism of Vitruvius then reacts on a list of changes to propagatethem to the SUM

Vitruvius has been implemented as a prototype3 in the Eclipse Modeling Frameworkand can thus be used with any Ecore-conforming metamodel So far it has been applied tosoftware architecture models and model-based representations of programming languages

2httpwwweclipseorgmodelingemf retrieved 2016-12-133httpssdqwebipdkiteduwikiVitruvius retrieved 2017-02-13


ii


ii

ii


[LK15] It has been also applied to component-based software development [Kra+15] andsystems modelling of energy networks [BMK16]

Leonhardt et al [Leo+15] have introduced two strategies to integrate one legacy modelinto Vitruvius Moreover we have extended Vitruvius concept in [Maz16] to checkthe consistency between several legacy models automatically resolve the conflicts semi-automatically (if founded) and integrate these models in Vitruvius platform

3 Case Study of PID Controller Software Development

This case study describes the development of a controller software using a traditional PID(Proportional Integral and Derivative) control algorithm This algorithm is commonly usedin the automotive field (eg for controlling throttle positions) It depends on a control loopfeedback mechanism to calculate an error value as the difference between a desired set point(target_position in our case study) and a measured process variable (actual_position inour case study) Then it attempts to minimize this error over time by adjustment of a controlvariable (new_position in our case study) Figure 2 shows the layout of the ElectronicsControl Unit (ECU) that will later execute the control algorithm In this developmentscenario the developers describe the structure of the controller software using SysMLThen they describe the software architecture in AMALTHEA platform to generate glue-codedescribing tasks operating system configuration and the scheduling They implement thedefined architecture using ASCET and generate the implementation code The integrationof both codes on circuit provides the final executable code The following subsections givean overview of the modelling tools and the problem that arises during the developmentprocess

new_positiontarget_pos

actual_position

out normal

Fig 2 Layout of the control algorithm ECU

31 Languages and Models

SysML (Systems Modelling Language) is a graphical modelling language developedfor systems engineering [OMG12] SysML can depict a systemrsquos structure using BlockDefinition Diagrams (BDD) and Internal Block Diagrams (IBD) BDDs provide a blackbox representation of a systemrsquos blocks and the interconnections between them in term offlow ports whereas IBDs instantiate them to represent the final assembly of the system

In our case study we describe the controller software structure using an IBD Figure 3 showsControlAlgorithm Block with its internal blocks (PID Tuning Block and Limiter Block) inaddition to its in-out-ports (actual_position target_position and new_position)


ii


ii

ii


Fig 3 Modelling the structures of control algorithm case study using IBD

AMALTHEA is an open and expandable tool platform for embedded multicore systemsIt combines the developing tools of the automotive ECUs in a single platform [BJ13]Our case study describes the PID controller software architecture using AMALTHEAcomponent models and software models Component models define the components (egControlAlgorithm) and the connection between them whereas the software model definessoftware units Runnables are executable software units that can be run in parallel (egControlAlgorithm_normal and ControlAlgorithm_out) Labels are data elements that arelocated in memory and that are readwritten by runnables (eg new_position target_posand actual_position) Processes are a generalization of tasks that define execution pathscalling runnablesother processes (eg _10MS task) From these models the developersgenerate the C code (glue-code) including the OSEK Implementation Language (OIL) files4that describe OSEK real time systems (multitasking and communication configuration)

ASCET (The Advanced Simulation and Control Engineering Tool) is a tool suite fromETAS GmbH for model-based development of embedded automotive software ASCETModeling and Design (ASCET-MD)5 is a part of the ASCET product family and offersexecutable specification of ECU functions using graphical tools (eg block diagramsand state machines) or by textual tools (eg Embedded Software Description Language(ESDL) editors and C code editors) For example the block diagram editor shown inFigure 4 describes the functionality of the ControlAlgorithm software component in termsof an AscetModule The diagram shows its internal components a pre-defined componentLimiter provided from the ASCET database and the PIDT1 component described inanother block diagram Furthermore it shows imported data from other blocks such asmessages (target_pos and actual_position) the output message exported to other blocks(new_position) and the flow of the datacontrol signal through different arithmeticallogicaloperations This model generates the C code that will be then integrated with AMALTHEAglue-code

4httpwwwirisafralfdownloadspuautTPNXTimagesoil25pdf retrieved 2016-12-135httpwwwetascomdeproductsascet_md_modeling_design-detailsphp retrieved 2016-12-13


ii


ii

ii


Fig 4 Modelling of control algorithm in ASCET using block diagram editor

32 Consistency Preservation

To keep the consistency between the models in automotive systems domain the developersusually exchange documents including the needed information and documentation along thedevelopment process Developers may for example apply technology based on ManufacturerSupplier Relationship (MSR)6 [SLG05] and XML [WH04] This technology stores theinformation in a uniform format once in a shared database As explained in section 1 thisapproach suffers from manual production and synchronisation of documents which canlead to inconsistencies This may result in high costs for resolving potential conflicts thatare first detected at the assembly stage Further problems are drift and erosion betweenmodels and code if potential inconsistencies are resolved only by correcting code errors

4 Preserving Consistency with Vitruvius Approach

This section describes the consistency preservation of our case study based on VitruviusFirst we explain how we prepare Vitruvius platform to be used for consistent view-baseddevelopment Then we illustrate how we have evaluated the declarative mappings betweenthe metamodels of our case study Finally we show the result of the evaluation

Initializing Vitruvius Platform In the first step of applying Vitruvius we createthe modular SUM metamodel which includes an Ecore-based metamodel for each of thethree modelling languages SysML AMALTHEA and ASCET Since the metamodels ofboth SysML and AMALTHEA are Ecore-based we have imported and reused them directlyFor ASCET we have used the ASCET Data Object Model (ADOM) metamodel which isdefined in conjunction with the ASCET XML Model Description (AMD) metamodel

The three metamodels share a high semantic overlap Therefore we have identified thesemantic correspondences between them Table 1 lists the most important correspondences

6httpwwwmsr-wgde retrieved 2016-12-13


ii


ii

ii


SysML AMALTHEA ASCET Examples from the case study

Block Component AscetModule ControlAlgorithmFlowPort Label Message target_pos actual_position new_positionndash Runnable Method normal outndash Task Task InitTask etc _10MS

Tab 1 Main correspondences between SysML AMALTHEA and ASCET

with examples from the PID controller case study To control this redundancy of informationaccording to Vitruvius we had to define the mapping between the artefacts sharingthe same semantic the invariants that violate the consistency and the reactions that canrestore the consistency when the invariants are violated In this work we concentrate ondefining the mapping between the metamodels of our case study with declarative mappingslanguage of Vitruvius List 1 illustrates an example of the declarative mapping usingthe Vitruvius mapping language This example defines the correspondence between theComponent metaclass of the AMALTHEA metamodel and the AscetModule metaclass of theASCET metamodel which describes the behaviour of this component The example showsalso the sub-mapping and correspondence between Runnable (AMALTHEA) and Method(ASCET) on one hand (lines 6ndash9) and the AMALTHEA Label and ASCET Message datatypes on the other hand (lines 10ndash13) The mapping conditions are written between squarebrackets After this the Vitruvius framework generates the bidirectional model-basedtransformations that are used for re-instating the consistency

1 import package httpamaltheaitea2orgmodel10components as comp

2 import package httpcomboschswanascetadom10 as adom

3 mapping ascetModule_component

4 map adomAscetModule as ascetModule and compComponent as component

5 [equal (ascetModule(name)component(name))]

6 map ascetModulemethods as method and componentrunnables as runn

7 [ equal(Methodname runnname)

8 empty(methodarguments)

9 equal(methodretnull) ]

10 map ascetModuleelements as messag with messagtype==adomMessage

11 and component(labels as label)

12 [ equal(label constantfalse)

13 equal(labelnamemessagname) ]

List 1 Correspondence rule between AscetModule and Component

Evaluation To evaluate the defined mappings and their implementation (the bidirectionalmodel-based transformation) we wrote a set of test cases that define different scenarios torebuild the models of the PID controller case study in the Vitruvius platform According to


ii


ii

ii


each scenario the test case instantiates the modular SUM metamodel makes some changesto the models (create update or delete some objects) and then triggers the synchronisationto propagate them to the related models Finally the test case asserts that the changesare correctly propagated One of the test cases scenario can be the following creating anAMALTHEA Component object named ControlAlgorithm creating two Runnable objects(out normal) and three Label objects (actual_position target_position new_position)and assigning them to the ControlAlgorithm component The expected changes after thesynchronisation are creating the related AscetModule object ControlAlgorithm that consistsof two Method objects without arguments or return type (out normal) and three Messageobjects (actual_position target_position new_position) Moreover the synchronisationshould create a SysML Block instance named ControlAlgorithm and containing threeFlowPort objects (actual_position target_position new_position)

Results The evaluation of the Vitruvius synchronisation based on the defined mappingshowed the following issues First the Vitruvius synchronisation can often re-instate theconsistency fully automatically For example the test case example defined in the previoussection is performed correctly ie the synchronisation automatically creates the relatedobjects (AscetModule and SysML Block objects) with the shared information Similarlyaltering the name of an AMALTHEA Component object will automatically update the nameof its related objects Second the synchronisation was not able to restore the consistencyfully automatically in some cases For instance if the developer creates an AMALTHEATask object named _10MS the synchronisation will ask him then to select the type of ASCETTask object that should be created to restore the consistency This is due to the one-to-manymapping between the AMALTHEA Task type on one hand and the ASCET Task typeand its subtypes on the other hand (see the last row of Table 1) Third the automaticallycreated related objects may need further development to provide them with the non-sharedinformation For example the AscetModule objects that are automatically created by thesynchronisation should be further developed to describe the functionality in details ThusVitruvius informs the developers with automatically generated elements that may needfurther development Finally the found results show that Vitruvius can be used to keepthe consistency in a real-life development scenario of automotive heterogeneous modelsThe main advantages are that the automated synchronisation will save manual effort avoidpotential inconsistency that may occur during the manual process resolve the conflicts withlower cost in the design stage and keep the models consistent with their implementation

5 Related work

This section describes related approaches that are used to keep consistency betweenautomotive heterogeneous models The document-centric approach (mentioned in section 1and subsection 32) suffers from manual preservation of consistency Born et al [BFK10]suggest representing exchanged information as models ndash even if it is a document ndash to


ii


ii

ii


ease tracing and to perform semi-automatic checks of consistency Our approach alsooffers semi-automatic conflict resolution Other works specify the relations between themodels and use them to perform automatic consistency preservation For example Gieseet al suggest using Triple Graph Grammars (TGGs) [Sch95] to describe the relationshipbetween SysML and AUTOSAR [GHN10] and to generate the bidirectional model-basedtransformations needed to synchronise these two models with each other If there are morethan two models additional chains of transformations should be built to connect them TheVitruvius approach however offers the development and management of more than twoheterogeneous models Moreover any change that violates the consistency constrains willbe not processed but rather ignored according to Giesersquos concept which is not the case inVitruvius approach where changes that violate consistency constraints can be handled bypredefined response actions

Other concepts keep consistency by generating a consistent model from another oneusing model-based transformations For example Selim et al [Sel+15] apply modeltransformations to migrate from legacy models of General Motors which are built usingcustom-built and domain-specific modelling language to standardized AUTOSAR modelsModel-to-model transformations have been also used by Sindico et al [SNP11] to generateSimulink models from SysML models and vice versa Similar work by Sjoumlstedt et al[Sjouml+08] transforms Simulink models to UML composite structure and activity modelsbased on Atlas Transformation Language ATL Macher et al [MAK15] depend on seamlesscombination of heterogeneous tools approach [Bro+10] to exchange the models betweenSysML and MatlabSimulink tools Other work of Macher [Mac+15] based on the sameapproach generates the configuration of RTOS from control system information in SysMLand vice versa The approaches mentioned in this paragraph are limited to a specificcombination of two models or languages The Vitruvius approach in contrast can beused to combine arbitrary modelling languages as long as they can be expressed as anEcore-conforming metamodel Vierhauser et al [Vie+12] present a framework for checkingand maintaining consistency between the Product Line (PL) model and some parts ofunderlying code However their approach is limited to PL models and their underlying codeand does not support other models needed in software product line engineering

6 Future WorkCurrently editors for the modelling languages used in our case study are not directlyusable with Vitruvius Therefore we suggest connecting the modelling tools with theVitruvius platform through implementing bidirectional transmitters These transmittersshould detect the changes made in the modelling tools and transform them to Vitruviusfor the synchronisation on one hand On the other hand they should record the changesresulting by Vitruvius synchronisation and transform them to the modelling tools in orderto update the models under development If recording the changes in the modelling tool isnot feasible as it is the case of closed-source ETAS ASCET tool then the transmitter shouldcalculate them by comparing two recent versions of the model in a way similar to [BT14]


ii


ii

ii


7 Conclusion

In this paper we have demonstrated how the model-driven Vitruvius approach can beused in the development of automotive systems Following the Vitruvius process wehave described how the existing standards SysML AMALTHEA and ASCET can be usedwith the Eclipse-based Vitruvius framework The case study of an onboard controlunit demonstrated that the steps for preserving and re-instating consistency which areusually carried out manually can be automated with the Vitruvius framework We haveformulated change-based consistency rules with the declarative Reactions language ofVitruvius to automate steps of consistency preservation that would normally have to becarried out manually and were for this reason often omitted

It is an important factor for reliable and secure systems that all the artefacts in the developmentprocess share consistency so that they can provide an up-to-date description of the systemunder development at all stages Model-driven technologies which are used widely inautomotive development processes form the basis for the advanced consistency preservationmethods of the Vitruvius approach Thus the accidental complexity of developing asystem with multiple metamodels languages or development tools can be reduced

References

[ASB10] Colin Atkinson Dietmar Stoll and Philipp Bostan ldquoOrthographic SoftwareModeling A Practical Approach to View-Based Developmentrdquo In Evaluationof Novel Approaches to Software Engineering Ed by Leszek A MaciaszekCeacutesar Gonzaacutelez-Peacuterez and Stefan Jablonski Vol 69 Communications inComputer and Information Science BerlinHeidelberg Springer 2010 pp 206ndash219

[BFK10] Marc Born John Favaro and Olaf Kath ldquoApplication of ISO DIS 26262in practicerdquo In Proceedings of the 1st Workshop on Critical Automotiveapplications Robustness and Safety ACM 2010 pp 3ndash6

[BJ13] Christopher Brink and Jan Jatzkowski AMALTHEA (ITEA2 ndash 09013) ndash WhitePaper Tech rep University of Paderborn Germany 2013

[BMK16] Erik Burger Victoria Mittelbach and Anne Koziolek ldquoModel-driven Consis-tency Preservation in Cyber-physical Systemsrdquo In Proceedings of the 11thWorkshop on Modelsruntime co-located with ACMIEEE 19th InternationalConference on Model Driven Engineering Languages and Systems (MODELS2016) (Saint Malo France) CEUR Workshop Proceedings Oct 2016

[Bro+10] Manfred Broy et al ldquoSeamless model-based development From isolated toolsto integrated model engineering environmentsrdquo In Proceedings of the IEEE984 (2010) pp 526ndash545


ii


ii

ii


[BT14] Erik Burger and Aleksandar Toshovski ldquoDifference-based ConformanceChecking for Ecore Metamodelsrdquo In Proceedings of Modellierung 2014Vol 225 GI-LNI Vienna Austria Mar 2014

[Bur+14] Erik Burger et al ldquoView-Based Model-Driven Software Development withModelJoinrdquo In Software amp Systems Modeling 152 (2014) Ed by RobertFrance and Bernhard Rumpe pp 472ndash496

[Bur14] Erik Burger ldquoFlexible Views for View-based Model-driven DevelopmentrdquoPhD thesis Karlsruhe Germany Karlsruhe Institute of Technology July 2014

[GBB12] Thomas Goldschmidt Steffen Becker and Erik Burger ldquoTowards a Tool-Oriented Taxonomy of View-Based Modellingrdquo In Proceedings of the Model-lierung 2012 Ed by Elmar J Sinz and Andy Schuumlrr Vol P-201 GI-Edition ndashLecture Notes in Informatics (LNI) Bamberg Gesellschaft fuumlr Informatik eV(GI) Mar 2012 pp 59ndash74

[GHN10] Holger Giese Stephan Hildebrandt and Stefan Neumann ldquoModel synchroni-zation at work keeping SysML and AUTOSAR models consistentrdquo In Graphtransformations and model-driven engineering Ed by Gregor Engels et alBerlin Heidelberg Springer 2010 pp 555ndash579

[KBL13] Max E Kramer Erik Burger and Michael Langhammer ldquoView-centric en-gineering with synchronized heterogeneous modelsrdquo In Proceedings of the1st Workshop on View-Based Aspect-Oriented and Orthographic SoftwareModelling VAO rsquo13 Montpellier France ACM 2013 51ndash56

[Kra+15] Max E Kramer et al ldquoChange-Driven Consistency for Component CodeArchitectural Models and Contractsrdquo In Proceedings of the 18th InternationalACM SIGSOFT Symposium on Component-Based Software Engineering ACM2015 pp 21ndash26

[Leo+15] Sven Leonhardt et al ldquoIntegration of Existing Software Artifacts into a View-and Change-Driven Development Approachrdquo In Proceedings of the 2015 JointMORSEVAO Workshop on Model-Driven Robot Software Engineering andView-based Software-Engineering MORSEVAO rsquo15 LrsquoAquila Italy ACM2015 pp 17ndash24

[LK15] Michael Langhammer and Klaus Krogmann ldquoA Co-evolution Approach forSource Code and Component-based Architecture Modelsrdquo In 17 WorkshopSoftware-Reengineering und-Evolution Vol 4 2015

[Mac+15] Georg Macher et al ldquoAutomotive real-time operating systems a model-basedconfiguration approachrdquo In ACM SIGBED Review 114 (2015) pp 67ndash72

[MAK15] Georg Macher Eric Armengaud and Christian Kreiner ldquoIntegration of Hetero-geneous Tools to a Seamless Automotive Toolchainrdquo In Systems Softwareand Services Process Improvement Ed by Rory V OrsquoConnor et al ChamSpringer International Publishing 2015 pp 51ndash62


ii


ii

ii


[Maz16] Manar Mazkatli ldquoConsistency Preservation in the Development Process ofAutomotive Softwarerdquo MA thesis Karlsruhe Institute of Technology (KIT)2016

[OMG12] OMG Systems Modeling Language (OMG SysML) Version 13 Object Mana-gement Group June 2012

[Sch06] DC Schmidt ldquoGuest Editorrsquos Introduction Model-Driven Engineeringrdquo InComputer 392 (Feb 2006) pp 25ndash31

[Sch95] Andy Schuumlrr ldquoSpecification of graph translators with triple graph grammarsrdquoIn Proceedings of the 20th International Workshop on Graph-TheoreticConcepts in Computer Science Springer London UK 1995 pp 151ndash163

[Sel+15] Gehan MK Selim et al ldquoModel transformations for migrating legacy deploymentmodels in the automotive industryrdquo In Software amp Systems Modeling 141(2015) pp 365ndash381

[Sjouml+08] Carl-Johan Sjoumlstedt et al ldquoMapping Simulink to UML in the design of embeddedsystems Investigating scenarios and transformationsrdquo In OMER4 Workshop4th Workshop on Object-oriented Modeling of Embedded Real-Time Systems2008 pp 137ndash160

[SLG05] Marek Szwejczewski Fred Lemke and Keith Goffin ldquoManufacturer-supplierrelationships An empirical study of German manufacturing companiesrdquo InInternational Journal of Operations amp Production Management 259 (2005)pp 875ndash897

[SNP11] Andrea Sindico Marco Di Natale and Gianpiero Panci ldquoIntegrating SysMLwith Simulink using Open-source Model Transformationsrdquo In SIMULTECHEd by Janusz Kacprzyk Nuno Pina and Joaquim Filipe SciTePress 2011pp 45ndash56

[Vie+12] Michael Vierhauser et al ldquoApplying a consistency checking framework forheterogeneous models and artifacts in industrial product linesrdquo In InternationalConference on Model Driven Engineering Languages and Systems Springer2012 pp 531ndash545

[WH04] Bernhard Weichel and Martin Herrmann A backbone in automotive softwaredevelopment based on XML and ASAMMSR Tech rep SAE Technical Paper2004


ii


ii

ii


however expensive because a great part of the exchanged files is written by hand and thereuse of information is done using error-prone techniques eg copy and paste

During the evolution of a system developers may also alter these models independentlyof each other A modification in one of the models can lead to an inconsistent descriptionof the system if it is not manually propagated to all other models which may in turnlead to inaccurate simulations and analyses for example security or performance analysesIf inconsistencies affect the generated program code negatively this problem is only bedetected in late stages of the development process eg during the assembly phase Sincecompilation of program code can take up several hours in systems of common size thecorrection of these inconsistency errors is very time-consuming

Vitruvius [KBL13 Bur14] is a model-based approach for the development of softwarewith heterogeneous modelling standards It contains declarative languages for consistencyrelations between heterogeneous models that describe the same system which are used todetect violations and to re-establish consistency in the system model In this paper we willdescribe how we have applied the Vitruvius approach to automotive systems engineeringto improve the reliability of automotive systems We have conducted a case study thatdescribes the development of an onboard control unit for automotive systems using thelanguages and standards SysML AMALTHEA and ASCET To use these languages in theEclipse Modeling Framework which is the technical space of the Vitruvius prototypewe have selected appropriate metamodels and defined an import procedure for existingmodels To express the consistency relations between these types of models we have defineddeclarative mapping specifications in the Mappings language of Vitruvius

After a description of the foundations of model-driven engineering and especially theVitruvius approach in section 2 we will introduce our case study of an automotivesoftware controller in section 3 In section 4 we describe the application of Vitruvius inour case study After related work (section 5) and future work (section 6) we conclude thepaper with section 7

2 Foundations

21 Model-Driven Engineering

Model-Driven engineering is a development paradigm that puts models in the centre ofthe development process and uses the following concepts [Sch06] First domain-specificlanguages (DSL) express domain concepts which reduce the complexity in the modellingof systems DSLs are defined using metamodels which themselves are defined using astandardised fixed meta-metamodel Second transformations engines are used to transformthese models into instances of other DSLs or into textual representations such as code


ii


ii

ii



22 Vitruvius

ASCET

AMALTHEA

SysML

VT1

VT2VT3

VT4


instance-of

ASCET view

Legend

VT View Type

V View


ModelJoin






ii


ii

ii







actual_position

out normal






ii


ii

ii







ii


ii

ii











ii


ii

ii






















ii


ii

ii




5 Related work



ii


ii

ii






ii


ii

ii


7 Conclusion



References







ii


ii

ii














ii


ii

ii













ii


ii

ii



22 Vitruvius

ASCET

AMALTHEA

SysML

VT1

VT2VT3

VT4


instance-of

ASCET view

Legend

VT View Type

V View


ModelJoin






ii


ii

ii







actual_position

out normal






ii


ii

ii







ii


ii

ii











ii


ii

ii






















ii


ii

ii




5 Related work



ii


ii

ii






ii


ii

ii


7 Conclusion



References







ii


ii

ii














ii


ii

ii













ii


ii

ii







actual_position

out normal






ii


ii

ii







ii


ii

ii











ii


ii

ii






















ii


ii

ii




5 Related work



ii


ii

ii






ii


ii

ii


7 Conclusion



References







ii


ii

ii














ii


ii

ii













ii


ii

ii







ii


ii

ii











ii


ii

ii






















ii


ii

ii




5 Related work



ii


ii

ii






ii


ii

ii


7 Conclusion



References







ii


ii

ii














ii


ii

ii













ii


ii

ii











ii


ii

ii






















ii


ii

ii




5 Related work



ii


ii

ii






ii


ii

ii


7 Conclusion



References







ii


ii

ii














ii


ii

ii













ii


ii

ii






















ii


ii

ii




5 Related work



ii


ii

ii






ii


ii

ii


7 Conclusion



References







ii


ii

ii














ii


ii

ii













ii


ii

ii




5 Related work



ii


ii

ii






ii


ii

ii


7 Conclusion



References







ii


ii

ii














ii


ii

ii













ii


ii

ii






ii


ii

ii


7 Conclusion



References







ii


ii

ii














ii


ii

ii













ii


ii

ii


7 Conclusion



References







ii


ii

ii














ii


ii

ii













ii


ii

ii














ii


ii

ii













ii


ii

ii











