Addressing the Need for Strict Meta-modeling in Practice - A Case Study

of AUTOSAR

Darko Durisic

, Miroslaw Staron

, Matthias Tichy

and J¨orgen Hansson

Volvo Car Group, Gothenburg, Sweden

Chalmers | University of Gothenburg, Gothenburg, Sweden

University of Ulm, Uml, Germany

University of Sk¨ovde, Sk¨ovde, Sweden

Keywords:

Strict Meta-modeling Principle, Domain-speciﬁc Meta-modeling, Deep Meta-modeling, AUTOSAR.

Abstract:

Meta-modeling has been a topic of interest in the modeling community for many years, yielding substantial

number of papers describing its theoretical concepts. Many of them are aiming to solve the problem of tradi-

tional UML based domain-speciﬁc meta-modeling related to its non-compliance to the strict meta-modeling

principle, such as the deep meta-modeling approach. In this paper, we show the practical use of meta-models

in the automotive development process based on AUTOSAR and visualize places in the AUTOSAR meta-

model which are broken according to the strict meta-modeling principle. We then explain how the AUTOSAR

meta-modeling environment can be re-worked in order to comply to this principle by applying three individual

approaches, each one combined with the concept of Orthogonal Classiﬁcation Architecture: UML extension,

prototypical pattern and deep instantiation. Finally we discuss the applicability of these approaches in practice

and contrast the identiﬁed issues with the actual problems faced by the automotive meta-modeling practition-

ers. Our objective is to bridge the current gap between the theoretical and practical concerns in meta-modeling.

1 INTRODUCTION

The use of meta-models (Saeki and Kaiya, 2007)

in the development of large software systems has

been in focus of the modeling research community

for more than a decade. Object Management Group

(OMG) provides a standardized framework for devel-

oping models as instances of domain-speciﬁc meta-

models, which are instances of UML, which in turn

is an instance of MOF (Meta-Object Facility) (MOF,

2004). This forms a commonly referred 4-layer meta-

modeling hierarchy of MOF. OMG also deﬁnes a

standard for the exchange of models between domain-

speciﬁc modeling tools based on XML known as XMI

(XML Metadata Interchange) (XMI, 2011).

Numerous papers have pointed out that the frame-

work of OMG fails to comply to one of the basic

meta-modeling principles known as the strict meta-

modeling (Atkinson and K¨uhne, 2002). According

to this principle, each model element on one meta-

modeling layer is an instance of exactly one element

on the layer above, with no other possible relation-

ships between the layers. In case of UML, instances

of domain-speciﬁc classiﬁers are at the same time in-

stances of the UML meta-class ”Object” (the problem

known as dual classiﬁcation (Atkinson and K¨uhne,

2001)). Additionally, the use of UML stereotypes

for giving additional semantics to the domain-speciﬁc

meta-model elements and/or their instances presumes

that the language deﬁnition of stereotypes and their

instances reside on the same layer as UML. For this

reason, UML based meta-modeling fails to comply to

the strict meta-modeling principle and therefore can

be classiﬁed as ”loose” meta-modeling.

A number of proposal have been made to intro-

duce strictness into the UML based meta-modeling.

Probably the most discussed approach in the literature

is the one proposed by Atkinson and K¨uhne known as

the deep meta-modeling, which relies on the concepts

of Orthogonal Classiﬁcation Architecture (OCA) and

deep instantiation (Atkinson and Kuhne, 2003). OCA

is able to expressthe distinction between the linguistic

and ontological (semantic) instantiations in the meta-

modeling hierarchy, thus solving the dual classiﬁca-

tion problem. Deep instantiation on the other hand

enables the existence of more than two ontological

layers which can be used to give additional semantics

to the meta-classes, instead of stereotypes.

Durisic, D., Staron, M., Tichy, M. and Hansson, J.

Addressing the Need for Strict Meta-modeling in Practice - A Case Study of AUTOSAR.

DOI: 10.5220/0005745303170322

In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 317-322

ISBN: 978-989-758-168-7

317

Despite this, the practical consequences of loose

meta-modeling remain unclear to the majority of

practitioners. Additionally, there is a lack of industrial

applications of the strict meta-modeling approaches,

such as deep meta-modeling, and the analysis of their

beneﬁts/drawbacks in comparison to the UML ap-

proach. We believe that these studies are needed to

bridge the current gap between the work of meta-

modeling researchers and the problems faced by the

meta-modeling practitioners.

In this paper, we explore the use of domain-

speciﬁc meta-modeling in the context of automotive

model driven development where, with the introduc-

tion of AUTOSAR (AUTomotive Open System AR-

chitecture) (AUT, 2003), UML-based meta-modeling

is taken as a basis for specifying the architecture of

automotive systems. The goal of this paper is to ad-

dress the following research questions:

• Q1 What are the consequences of UML based

loose meta-modeling in the automotive domain?

• Q2 What are the drawbacks of approaches for as-

suring strictness of the AUTOSAR meta-model?

• Q3 What are the practical meta-modeling con-

cerns of the automotive modeling practitioners?

We achieve this by visualizing places in the AU-

TOSAR meta-model which are not compliant to the

strict meta-modeling principle and re-working the

AUTOSAR meta-modeling environment according to

the rule of strictness using three distinct approaches:

UML extension, prototyping pattern and deep instan-

tiation. We combine each approach with the OCA

representation of the layers and discuss their beneﬁts

and drawbacks in practice. Finally, we explain why

the issues of loose meta-modeling are not the primary

concern of the automotive practitioners and contrast

them with the actual problems they face in their work.

The rest ofthis paper is structured as follows: Sec-

tion 2 describes the role and hierarchy of the AU-

TOSAR meta-model in the automotive modeling en-

vironment. Section 3 applies three approaches for

assuring compliance of the AUTOSAR meta-model

to the strict meta-modeling principle. Section 4 dis-

cusses the beneﬁts and drawbacksof these approaches

in practice. Finally we conclude in Section 5 with

some guidelines for future meta-modeling research.

2 AUTOMOTIVE MODELING

Automotive software system is a distributed system

with typically more than 100 Electronic Control Units

(ECUs) today responsible for executing allocated ve-

hicle functions. Apart from its distributed organiza-

tion, the development of the automotive software sys-

tems is also distributed as ECUs are usually devel-

oped by a hierarchy of suppliers, e.g. application soft-

ware, middleware and hardware suppliers. In order

to facilitate this distributed development, AUTOSAR

standard was introduced as a joint partnership of car

manufacturers and their suppliers.

The goal of AUTOSAR is to standardize the ar-

chitecture of the automotive systems and their devel-

opment methodology. Figure 1 shows a common AU-

TOSAR based model-drivendevelopmentprocess un-

til the generation of the ECU source code.

Architectural

design

ECU

model

ECU functional

development

ECU config

ECU

Config.

model

ECU

req.

spec.

Simulink

model

ECU functional

code generation

Func.

code

ECU config

code generation

Config.

code

AR.

meta-

model

instanceOf

semantics

instanceOf

AR.

Templ.

AUTOSAR

Car manufacturer

Supplier

Figure 1: AUTOSAR based software development process.

The development starts with the Architectural de-

sign, which includes the deﬁnition of the ECUs and

allocation of the software components onto them. As

ECU development is usually done by different suppli-

ers, the complete architectural model is divided into

a number of ECU models, each one delivered to the

chosen supplier. Because different car manufacturers

and suppliers may use different modeling tools, assur-

ing their interoperability is quite challenging.

To facilitate this interoperability,AUTOSAR meta-

model is deﬁned as a standardized domain-speciﬁc

modeling language for the architectural ECU models,

i.e. an ECU model represents an instances of the AU-

TOSAR meta-model that speciﬁes its syntax. The se-

mantics is speciﬁed in the speciﬁcations called AU-

TOSAR templates (Gouriet, 2010). Therefore the AU-

TOSAR meta-model serves as a basis for the develop-

ment of the automotive modeling tool-chain.

Figure 2 shows an example of the AUTOSAR

meta-model which is used to specify the allocation

of the software components onto ECUs, and a cor-

responding model allocating the EnginePowerUnit

component onto the EngineControlModule ECU

(Durisic et al., 2014). The AUTOSAR models are ex-

pressed in XML and they are validated by the XML

schema which is generated from the AUTOSAR

meta-model using a set of deﬁned transformation.

The ECU model and the ECU requirements spec-

iﬁcation deﬁning the behavior of the allocated soft-

ware components serve as basis for the ECU func-

tional development. This is usually done in Simulink

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

318

Referrable

+ shortName :String

Identifiable

+ uuid :String

Ecu

+ busWakeUp :Boolean

+ diagAddress :Integer

SwcToEcuMapping

SoftwareComponent

:Ecu

shortName = EngineControlModule

uuid = A2CD0720

diagAddress = 12

busWakeUp = false

:SoftwareComponent

shortName = EnginePowerUnit

uuid = FOAAD679

:SwcToEcuMapping

shortName = Mapping32

uuid = A19FAB93

Meta-Model

Model

+swc 1

+ecu 1

+ecu

+swc

Figure 2: AUTOSAR meta-model example.

as it supports automated ECU functional code gener-

ation from the Simulink models (Liu et al., 2013).

Apart from being input to the functional devel-

opment, the ECU models also serve as basis for the

ECU conﬁguration, i.e. conﬁguration of the middle-

ware (e.g. ECU communication, diagnostics). One

ECU can be conﬁgured using a number of parameters.

The values of certain parameters can be automatically

generated from the attributes of the ECU model, e.g.

signal transmission period. Other parameters, e.g. re-

lated to the operating system, need to be conﬁgured

in the ECU conﬁguration tools (Lee and Han, 2009).

Based on the complete ECU conﬁguration model in-

stantiating the AUTOSAR meta-model, Conﬁguration

code (C-structs) can be automatically generated in the

ECU conﬁguration code generation phase.

The ﬁnal ECU software is obtained by compiling

and linking the Functional code generated from the

Simulink models, the Conﬁguration code generated

from the ECU models and completed in the ECU con-

ﬁguration tools and the actual implementation of the

AUTOSAR middleware (commonly known as AU-

TOSAR basic software). The basic software is en-

tirely speciﬁed by AUTOSAR and it is usually imple-

mented outside of the model driven approach. The

language mostly used in the automotive domain is C.

Based on the described process, we can conclude

that the AUTOSAR meta-model plays an important

role in the architectural design of the system and the

conﬁguration of the ECU basic software.

2.1 AUTOSAR Meta-model Hierarchy

MOF (Meta-Object Facility) (MOF, 2004), an ac-

cepted standard for model-drivenengineering, deﬁnes

the following 4-layer meta-modeling hierarchy:

1. M3: MOF meta-meta-model

2. M2: UML meta-model

3. M1: Application model

4. M0: Application data

These layers are connected by the instantiation

mechanism, i.e., each layer represents an instance of

the layer above, except for the top layer which is con-

sidered to be an instance of itself. According to the

strict meta-modeling principle (Atkinson, 1998), each

model element on one layer is an instance of exactly

one element on the layer above.

The meta-modeling hierarchy of MOF exhibitsthe

property known as dual classiﬁcation (Atkinson and

K¨uhne, 2002). This is a consequence of the two no-

tions of the instanceOf relationship - linguistic, deﬁn-

ing the language (e.g. EngineControlModule is a

UML Object), and ontological, deﬁning the seman-

tics (e.g. EngineControlModule is an ECU) (Atkin-

son and Kuhne, 2003). This means that the objects on

the M1 layer are both ontological instances of the M1

classes and linguistic instances of the M2 meta-class

Object, thus breaking the strict modeling principle.

To resolve this problem, MOF considers the strict

meta-modeling principle only for the linguistic notion

of the instanceOf relationship. AUTOSAR, however,

attempts to visualize both linguistic and ontological

layers in the meta-modeling hierarchy thus deﬁning

the following 5 meta-modeling layers (AUT, 2014):

1. ARM4: MOF meta-meta-model

2. ARM3: UML meta-model and AR proﬁle

3. ARM2: AUTOSAR meta-model

4. ARM1: AUTOSAR model

5. ARM0: AUTOSAR run-time objects

By examining the semantics of the layers, we can

see that the ARM1 (containing objects) is an ontolog-

ical instance of the ARM2 (containing classes) and

both the ARM1 and ARM2 are linguistic instances

of the ARM3 (containing meta-classes Class and Ob-

ject). Therefore the illustration of the AUTOSAR lay-

ers breaks the strict meta-modeling principle as the

ARM1 objects directly instantiate (linguistically) the

ARM3 meta-class Object. On the ARM3 layer, AU-

TOSAR also extends the UML meta-model with its

own AUTOSAR Template Proﬁle (ATP). An simpli-

ﬁed example of the AUTOSAR meta-layers and the

ATP proﬁle is presented in Figure 3.

AUTOSAR deﬁnes a number of umlStereotypes in

the atpProﬁle and we show one of them, atpVariation,

applicable to umlClasses (indicates that a class may

have different variants), with the corresponding atp-

BindingTime tagged value (indicates when the variant

shall be bound). All stereotypes are branding both

classiﬁers and instances (Atkinson et al., 2002).

Figure 3 also shows three types of the non-

compliance of the AUTOSAR meta-modeling hierar-

chy with respect to the strict meta-modeling principle

(indicated by the numbers [1], [2] and [3]):

Addressing the Need for Strict Meta-modeling in Practice - A Case Study of AUTOSAR

319

ARM0

ARM1

ARM2

ARM4

ARM3

umlElement

+ name :string

umlClass umlStereotype

umlProfile umlTaggedValue

+ value :string

atpProfile atpVariation

atpBindingTime

+ value = PostBuild

ECU

EngineControleModule :ECU

umlObject

mofElement

ECM







+stereotypes

+tags

+base

+tags

+base

+classifier

+base

Figure 3: Example of the AUTOSAR meta-layers.

[1] The EngineControlModule on the ARM0 layer is

a direct linguistic instance of the umlObject on the

ARM3 layer (dual classiﬁcation).

[2] The atpProﬁle, atpVariation and atpLatestBind-

ingTime represent ontological instances of the

umlProﬁle, umlStereotype and umlTaggedValue,

respectively, even though they reside on ARM3.

[3] The non-instanceOf relationships between the at-

pVariation / atpLatestBindingTime and the ECU /

EngineControlModule cross the layer boundaries.

3 ASSURING STRICTNESS OF

AUTOSAR

The dual classiﬁcation problem [1] can be solved us-

ing the OCA with two dimensions, where the onto-

logical instantiation is depicted horizontally and the

linguistic vertically. The problems related to the use

of stereotypes [2] and [3] can be solved using differ-

ent approaches and we show in this paper three of

them combined with OCA: UML extension, prototyp-

ical pattern and deep instantiation (referred to as deep

meta-modeling in combination with OCA).

UML Extension: In this approach, the umlClass

on the linguistic layer L2 is directly extended by the

atpVariableClass with the attribute atpBindingTime

by means of inheritance, as shown in Figure 4. Green

color indicates linguistic instantiation (between L lay-

ers) while blue color indicates ontological instanti-

ations (between O layers). The linguistic instantia-

tion of the atpBindingTime attribute from the L2 layer

shall be done in a static manner, i.e. all O0 instances

of ECU shall have ”PostBuild” atpBindingTime. The

L0 layer is omitted due to its questioned value in the

meta-modeling hierarchy (Harel and Rumpe, 2004).

L1, O1 L1, O0

umlElement

+ name :string

umlClass

ECU

+ atpBindingTime = PostBuild

EngineControleModule :ECU

atpBindingTime = PostBuild

atpVariableClass

+ atpBindingTime :string

umlObject

mofElement

+classifier

Figure 4: Example of UML extension.

Prototypical Pattern: In this approach, the uml-

Class on the L2 layer is instantiated into a number

of atpVariable classes for different values of the atp-

BindingTime, e.g. atpPreBuildVariableClass and atp-

PostBuildVariableClass, as shown in Figure 5. The

actual domain-speciﬁc L1 classes, such as ECU, are

then inherited from the right atpVariableClass de-

pending on the intended value of the atpBindingtime.

L1, O0L1, O1

umlElement

+ name :string

umlClass

ECU

EngineControleModule :ECU

atpPostBuildVariableClass

umlObject

mofElement

atpPreBuildVariableClass

+classifier

Figure 5: Example of prototypical pattern.

Deep Instantiation: In this approach, the hierar-

chy of more than two ontological instantiations is al-

lowed, i.e. domain-speciﬁc classes can be instantiated

by other classes, not just objects as in UML.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

320

L1,O0L1,O1L1,O2

umlElement

+ name :string

umlClass

ECU:

atpVariableClass

EngineControleModule :

ECU

atpVariableClass

l1 :l

value = PostBuild

l:atpBindingTime

+ value = PostBuild

umlObject

mofElement

atpBindingTime

+ value :string

+classifier

Figure 6: Example of deep instantiation.

Figure 6 shows an example of the deep instan-

tiation. O2 classes (e.g. atpVariableClass) are lin-

guistically instantiated from the umlClass, just like

the domain-speciﬁc classes on the O1 layer (e.g.

ECU) ontologically instantiating the corresponding

O2 classes. The objects instantiating the O1 classes

reside on the O0 layer. The ontological instantiation

of the O2 class attributes (e.g. value of the atpBind-

ingTime) shall be done in a static manner, i.e. all O0

instances shall have the same value.

4 DISCUSSION

We showed in Section 2.1 that the AUTOSAR meta-

modeling environment relies on the traditional UML

based meta-modeling extended with the UML stereo-

types. The consequences of this approach (Q1) de-

scribed in Section 2.1 (see [1], [2] and [3]) are solved

by the majority of UML based modeling tools avail-

able on the market today (e.g. Enterprise Architect

used by AUTOSAR).

For solving the problem of dual classiﬁcation [1],

modelers are required to create instances as Objects

(linguistic instantiation) and then classify them with

the correct Class (ontological instantiation). The

stereotype related problems [2] and [3] can be solved

by providing a graphical interface to the modelers for

mapping the applicable stereotypes to the actual UML

elements (e.g. atpVariation is applicable to Classes).

Regarding the use of the three proposed ap-

proaches instead of stereotypes that assure strictness,

the prototypical pattern can be applied in the tradi-

tional UML based tools. However it is not feasi-

ble for large domain-speciﬁc meta-models because a

new top-layer meta-class is required for each pair of

stereotype-tagged value creating a wide and deep in-

heritance hierarchy of meta-classes. For example, we

need a new top layer class for atpPostBuildVariation-

Point, atpPreCompileVariationPoint, etc.

UML extension and deep instantiation ap-

proaches, on the other hand, require special mod-

eling tools. For UML extension, modelers would

need to extend the UML meta-model with domain-

speciﬁc classes and then create their linguistic in-

stances (e.g. ECU as an instance of atpVariableClass

rather than umlClass). For deep instantiation, mod-

elers would need to deﬁne classes as ontological in-

stances of other classes (e.g. ECU as an instance of

atpVariableClass). The use of OCA in all three ap-

proaches improves the correct understanding of the

meta-modeling hierarchy.

Despite the fact that there are some modeling

tools today supporting these approaches (e.g. Mela-

nee (Atkinson and Gerbig, 2012) for deep meta-

modeling), they were not available on the market

when the AUTOSAR meta-model was initially devel-

oped in 2003. Furthermore, they are still not widely

used in the industry. The designers of large software

systems are reluctant to accept new approaches and

tools until they have a long successful history of ap-

plication in different domains (Pagel and Br¨orkens,

2006). This is one of their major drawbacks (Q2).

Additionally, the majority of automotive model-

ing practitioners are not aware of the advanced meta-

modeling concepts, such as deep meta-modeling. For

example, even the formal deﬁnition of the AUTOSAR

proﬁle (as an instance of the UML proﬁle deﬁnition)

that required deeper analysis of the UML meta-model

was considered too complex for the automotive mod-

elers (Pagel and Br¨orkens, 2006). On the other hand,

they are mostly familiar with the use of UML and

UML stereotypes. Therefore there is no need for ad-

ditional training of engineers which is important for

companies where hundreds of modelers are responsi-

ble for the design of the system.

Finally, the approach used by AUTOSAR based

on UML extended with proﬁles and XML as an ex-

change format for the AUTOSAR models is a well es-

tablished approach used for many years. This makes

the automotive modeling practitioners reluctant to

changes it, unless a new approach can solve some of

the practical problems they face today such as (Q3):

• How to estimate the impact of domain-speciﬁc

meta-model evolution on the modeling tools?

• How to minimize the tooling interoperability is-

sues after adopting a new meta-model release?

• How to assure smooth integration of the models

based on different meta-model releases?

Addressing the Need for Strict Meta-modeling in Practice - A Case Study of AUTOSAR

321

To exemplify these problems, consider the follow-

ing automotive scenario: A new AUTOSAR meta-

model release supports 10 new architectural features.

5 ECUs in the system are interested in using 2 of them

while other ECUs do not need any, just minor func-

tional updates (e.g. new signals on the bus). This re-

quires that the architectural design tools support mul-

tiple partial meta-model releases for different ECUs

(or their superset, if possible), which may cause un-

expected issues in the ECU conﬁguration tools. Addi-

tionally the integration of the ECU models developed

based on different meta-model releases may cause bus

and/or functional incompatibilities.

It remains unclear if and how the described meta-

modeling approaches support solving these practical

issues and whether there are signiﬁcant differences

between the approaches related to them. However it is

clear that the mentioned issues affect the entire mod-

eling tool-chain which may be distributed among sev-

eral companies, while the problems related to strict-

ness can be solved by individual modeling tools.

5 CONCLUSIONS

In this paper, we recognize that the concept of

domain-speciﬁc meta-modeling strictness is not the

primary concern of the meta-modeling practitioners

designing large software systems with distributed im-

plementation, such as automotive systems. However

we believe that the approaches assuring strictness,

such as deep meta-modeling (deep instantiation com-

bined with OCA), could be employed in the develop-

ment process of such systems. We also believe that

a joint work of researchers and practitioners to re-

work a part of a real industrial domain-speciﬁc meta-

modeling environment, such as AUTOSAR, accord-

ing to these approaches would be needed to evaluate

their beneﬁts and drawbacks. This would bridge the

current gap between the theoretical meta-modeling

discussion and their practical realization.

We also hope that this paper will lead to more re-

search addressing the practical problems described in

this paper both in the automotive domain and other

domains (e.g. avionics), such as the tooling interoper-

ability issues after the adoption of a new meta-model

version (or its subset) in the development projects.

ACKNOWLEDGEMENTS

We want to thank Swedish Governmental Agency for

Innovation Systems (VINNOVA), grant no. 2013-

02630, and Volvo Cars for funding this research.

REFERENCES

(2003). Automotive Open System Architecture. AUTOSAR,

www.autosar.org.

(2004). MOF 2.0 Core Speciﬁcation. Object Management

Group, www.omg.org.

(2011). XML Metadata Interchange (XMI) Version 2.2 . Ob-

ject Management Group, www.omg.org.

(2014). AUTOSAR Generic Structure Template v4.2.1.

www.autosar.org.

Atkinson, C. (1998). Supporting and Applying the UML

Conceptual Framework. In International Workshop

on The Uniﬁed Modeling Language, pages 21–36.

Atkinson, C. and Gerbig, R. (2012). Melanie: Multi-level

Modeling and Ontology Engineering Environment. In

Objects, Models, Components, Patterns, page 7.

Atkinson, C. and K¨uhne, T. (2001). The Essence of Multi-

level Metamodeling. In International Conference on

the UML 2000, volume 2185, pages 19–33.

Atkinson, C. and K¨uhne, T. (2002). Rearchitecting the

UML Infrastructure. Transactions on Modeling and

Computer Simulation Journal, 12(4):291–321.

Atkinson, C. and Kuhne, T. (2003). Model-Driven Develop-

ment: A Metamodeling Foundation. Journal of IEEE

Software, 20(5):36–41.

Atkinson, C., K¨uhne, T., and Henderson-Sellers, B. (2002).

Stereotypical Encounters of the Third Kind. In In-

ternational Conference on The Uniﬁed Modeling Lan-

guage, pages 100–114.

Durisic, D., Staron, M., Tichy, M., and Hansson, J. (2014).

Evolution of Long-Term Industrial Meta-Models - A

Case Study of AUTOSAR. In Euromicro Conference

on Software Engineering and Advanced Applications,

pages 141–148.

Gouriet, P. (2010). Involving AUTOSAR Rules for Mecha-

tronic System Design. In International Conference on

Complex Systems Design & Management, pages 305–

316.

Harel, D. and Rumpe, B. (2004). Meaningful modeling;

whats the semantics of semantics? IEEE Computer,

37(10):64–72.

Lee, J. C. and Han, T. M. (2009). ECU Conﬁguration

Framework Based on AUTOSAR ECU Conﬁguration

Metamodel. In International Conference on Con-

vergence and Hybrid Information Technology, pages

260–263.

Liu, Y., Li, Y. Q., and Zhuang, R. K. (2013). The Appli-

cation of Automatic Code Generation Technology in

the Development of the Automotive Electronics Soft-

ware. In International Conference on Mechatronics

and Industrial Informatics Conference, volume 321-

324, pages 1574–1577.

Pagel, M. and Br¨orkens, M. (2006). Deﬁnition and Gen-

eration of Data Exchange Formats in AUTOSAR. In

European Conference on Model Driven Architecture-

Foundations and Applications, pages 52–65.

Saeki, M. and Kaiya, H. (2007). On Relationships among

Models, Meta Models and Ontologies. In 6th OOP-

SLA Workshop on Domain-Speciﬁc Modeling.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

322