institut f¨ur informatik - PST Thesis Management Interface - LMU

INSTITUT FÜR INFORMATIK 

DER LUDWIG–MAXIMILIANS–UNIVERSITÄT MÜNCHEN 

Diplomarbeit 

An Automated Process for the 

Generation of Generic Model Interfaces 

for Evolutionary Different 

AUTOSAR Schema Versions 

Leonard Krpan

INSTITUT FÜR INFORMATIK 

DER LUDWIG–MAXIMILIANS–UNIVERSITÄT MÜNCHEN 

Diplomarbeit 

An Automated Process for the 

Generation of Generic Model Interfaces 

for Evolutionary Different 

AUTOSAR Schema Versions 

Leonard Krpan 

Aufgabensteller: Prof. Dr. Martin Wirsing 

Betreuer: Annabelle Klarl 

Christian Knüchel (BMW Car IT) 

Abgabetermin: 30. September 2011

Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbstständig verfasst 

und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. 

München, den 30. September 2011 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

(Unterschrift des Kandidaten)

Abstract 

This thesis describes a concept for the automatic creation of a generic, version-independent 

metamodel based on the comparison of evolutionary different metamodel versions. The 

comparison results are obtained from an automatically created difference model. Unlike 

a transformation engine which typically uses information in a difference model to migrate 

an existing model to the evolved model, the concept developed in this thesis exploits the 

difference model to identify metamodel elements that can be represented by a generic metamodel 

and explores to which extent this can be done automatically before a semantic gap is 

reached. The concept is showcased through a model transformation prototype that produces 

a generic metamodel encompassing elements common to all version-specific metamodels and 

elements that were subjected to minor changes during the evolution process. The generic 

metamodel can be directly deployed to automatically generate version-independent model 

API code with the Eclipse Modeling Framework. The concept is applied to create a generic 

AUTOSAR metamodel as a solution to the metamodel evolution problem that occurs in 

AUTOSAR tool development with Artop. 

vii

Acknowledgments 

I would like to thank Prof. Dr. Martin Wirsing for approving the request to do my thesis 

at BMW Car IT. More importantly, I thank Prof. Wirsing for the many lessons in which he 

shared his knowledge with me and which I much enjoyed attending. 

I would like to thank my LMU supervisor Annabelle Klarl for the time and effort she invested 

in mentoring my thesis and for organizing communications with Prof. Wirsing and the PST 

department. 

I would like to thank Team Blue at BMW Car IT for giving me the opportunity to experience 

their company through this thesis project. I especially thank my supervisor Christian 

Knüchel and my co-supervisor Paul Hoser for organizing the thesis, introducing me to their 

project and giving me the opportunity to expand my knowledge with the topics that this 

thesis covers. I also thank them for their extensive mentoring throughout the project. Furthermore, 

I thank my professor, my supervisors at LMU and BMW Car IT, the head of 

Team Blue, Michael Rudorfer, and the head of BMW Car IT, Prof. Dr. Harald Heinecke, 

for helping me ensure the quality of the thesis document. 

I would like to express deepest gratitude to my parents Irena Krpan and Jasmin Krpan 

for guiding me to decisions that led to choosing LMU and Munich, which has resulted in the 

opportunity to develop myself on a professional and personal level that would not have been 

attainable at home. I thank them and my sister Izabela Krpan, my grandmother Donka 

Miloˇs and our dog Peggy for their support, encouragement and love throughout my student 

experience. 

I would also like to thank my friends in Munich for the much needed support during the 

final stages of my university studies. 

My greatest appreciation goes to my girlfriend Erin Beaton for her enormous patience and 

for her continuous encouragement during every single day of work on this thesis. Without 

her love and care, I would not have had the strength to complete this work. 

ix

Contents 

1. Introduction 1 

1.1. Thesis objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2. Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

2. State of the Art 3 

2.1. Model-Driven Software Development . . . . . . . . . . . . . . . . . . . . . . . 3 

2.1.1. Growing complexity of software . . . . . . . . . . . . . . . . . . . . . . 3 

2.1.2. Abstraction in computing . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2.1.3. The model-driven approach . . . . . . . . . . . . . . . . . . . . . . . . 4 

2.1.4. Principles of model-driven software development . . . . . . . . . . . . 5 

2.1.5. Model-driven software development in the automotive industry . . . . 10 

2.2. Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.2.1. Ecore - the EMF metamodel . . . . . . . . . . . . . . . . . . . . . . . 12 

2.2.2. Model persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.2.3. Code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.2.4. EMF Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.3. Model evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

2.3.1. Model versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

2.3.2. Model adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3. Automotive Open System Architecture 25 

3.1. The AUTOSAR standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.1.1. AUTOSAR architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.1.2. AUTOSAR methodology . . . . . . . . . . . . . . . . . . . . . . . . . 27 

3.1.3. AUTOSAR metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

3.2. Artop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

3.2.1. Artop architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

3.2.2. Developing AUTOSAR tools with Artop . . . . . . . . . . . . . . . . . 32 

3.3. The Generic AUTOSAR concept . . . . . . . . . . . . . . . . . . . . . . . . . 34 

3.3.1. GAUTOSAR metamodel . . . . . . . . . . . . . . . . . . . . . . . . . 34 

3.3.2. Implementing tool functionality with GAUTOSAR . . . . . . . . . . . 35 

3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

4. Automation of Generic AUTOSAR 37 

4.1. Realization of GAUTOSAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

4.1.1. Process steps for realizing GAUTOSAR . . . . . . . . . . . . . . . . . 37 

4.1.2. Automation of the GAUTOSAR realization process . . . . . . . . . . 39 

4.2. Analysis of the automated metamodel comparison process . . . . . . . . . . . 40 

4.2.1. DiffMap metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

xi

Contents 

4.2.2. Model comparison in DiffMap . . . . . . . . . . . . . . . . . . . . . . . 42 

4.2.3. Distributed comparison history . . . . . . . . . . . . . . . . . . . . . . 42 

4.2.4. Leaking occurrence information . . . . . . . . . . . . . . . . . . . . . . 44 

4.3. Automated creation of the generic metamodel . . . . . . . . . . . . . . . . . . 50 

4.3.1. Construction phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

4.3.2. Decoupling phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

4.3.3. Gification phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

4.3.4. Prototype implementation . . . . . . . . . . . . . . . . . . . . . . . . . 56 

4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

5. Results 61 

5.1. Generic AUTOSAR metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

5.1.1. Observed issues in the generic metamodel . . . . . . . . . . . . . . . . 61 

5.1.2. Known limitations of the prototype . . . . . . . . . . . . . . . . . . . . 62 

5.2. Limitations in the automation process . . . . . . . . . . . . . . . . . . . . . . 63 

5.2.1. Undetectable class changes . . . . . . . . . . . . . . . . . . . . . . . . 63 

5.2.2. Generic elements not present in all metamodels . . . . . . . . . . . . . 63 

5.2.3. Superclass information gain . . . . . . . . . . . . . . . . . . . . . . . . 63 

5.3. Evaluation of achieved results . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 

5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 

6. Conclusion 69 

6.1. Thesis summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

6.2. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

6.2.1. Self-containment of the DiffMap model . . . . . . . . . . . . . . . . . . 70 

6.2.2. AUTOSAR-specific matching algorithm . . . . . . . . . . . . . . . . . 70 

6.2.3. Use-case analysis of attribute type changes . . . . . . . . . . . . . . . 71 

6.3. Final thought . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 

A. Appendix 73 

List of Figures 79 

List of Listings 81 

CD Contents 83 

Bibliography 85 

xii

1. Introduction 

Software development is a complex and demanding task that requires considerable human 

effort and significant technical resources. One of the technical aspects is the availability of 

comprehensive development tools. BMW Car IT is driving forward model-driven software 

development in the automotive domain, which also applies to creating tools. These tools 

facilitate development of models by offering various tool functions that can be used to create 

and manipulate the models. BMW Car IT is involved in developing Artop, an infrastructure 

platform for creating AUTOSAR tools. AUTOSAR is a standardized architecture for 

developing software for automobile electronic control units that relies on the model-driven 

approach. 

The AUTOSAR standard, representing a software entity, is under constant development 

and improvement. As a reaction to this development, the metamodel representing the AU- 

TOSAR architecture is subject to evolution. Artop reacts to metamodel evolution by providing 

support for a number of metamodel versions within each tool release. The consequence 

of supporting multiple metamodel versions in one tool is that semantically equivalent tool 

functionalities have to be implemented separately for each metamodel version. To alleviate 

this inconvenience, evolutionary different metamodel versions are compared in order to create 

a generic metamodel that encompasses common parts of metamodels of the supported 

versions. Tool functionality can then be implemented only once and automatically delegated 

to specific metamodel versions. Due to the size of AUTOSAR metamodels, comparing the 

metamodels and creating a common metamodel manually becomes a very complicated and 

time-consuming task. Therefore, BMW Car IT is engaged in research efforts to automate 

this process to the furthest possible extent. 

1.1. Thesis objective 

The objective of this thesis is to develop a concept for the automatic creation of a generic, 

version-independent metamodel based on comparison results of evolutionary different metamodel 

versions. The developed concept will be showcased through a model transformation 

prototype. The prototype will use a difference model containing metamodel comparison 

results as input and produce a version-independent metamodel as output. The automation 

concept will be applied to AUTOSAR metamodels and the prototype will yield a versionindependent, 

generic AUTOSAR metamodel as result. 

The metamodel comparison results will be obtained from a difference model developed in 

a preceding thesis at BMW Car IT. The difference model will be improved to present the 

comparison results in a format that enables automatic identification of generic metamodel 

elements. The difference model will also be improved to achieve a higher accuracy when 

identifying metamodel elements that are common in compared versions. 

1

1. Introduction 

The automation concept will process the difference model and explore to which extent the 

creation of a generic metamodel can be automated before a manual intervention is necessary. 

The concept will process each metamodel element found in the difference model and inspect 

the occurrence history and change information for that element in order to determine if it 

can be represented in the generic metamodel. This will enable automatic extraction of metamodel 

elements which are common in all versions or which have been changed to a minor 

degree and automatic creation of a generic metamodel made up from such elements. The 

generic metamodel will be self-contained in the sense that it will not contain references to elements 

in the version-specific metamodels. A naming convention will be used for the generic 

metamodel that enables a clear distinction between generic and version-specific elements, 

but at the same time makes it possible to relate their meaning. 

1.2. Thesis outline 

The remaining chapters of this thesis are organized as follows: 

2 

• Chapter 2 presents the state of the art of principles and general technologies that 

are relevant for this thesis. The motivation behind model-driven software development 

in terms of increasing software complexity and the principles of this approach are 

introduced first, followed by examples of applying these principles in the automotive 

industry. Next, an introduction to the Eclipse Modeling Framework as a tool for 

creating modeling applications in Java is given. The chapter is concluded with an 

overview of current research in model evolution. 

• Chapter 3 introduces specialized technologies that this thesis is concerned with. Different 

aspects of the AUTOSAR standard are discussed in detail at first. Artop is 

presented in detail as well, followed by examples of how it enables the creation of 

AUTOSAR tools. Following Artop a detailed explanation of the metamodel evolution 

problem and its effects on tool development are given. The use of a common 

version-independent metamodel is proposed as a solution. 

• Chapter 4 begins by introducing the process steps that are necessary to realize the 

concept of a generic metamodel, followed by the motivation for the automation of this 

process. Automatic comparison of metamodels (done in preceding work) is explained 

as the first part of the automation process, together with necessary improvements that 

were contributed in this thesis. This thesis’ main contribution - a concept for the 

automatic creation of a generic metamodel based on metamodel comparison results 

and the prototype that realizes the developed concept - are elaborated in detail as the 

second part of the automation process. 

• Chapter 5 analyzes the results of development efforts conducted in this thesis. The 

prototype for automatic creation of the generic metamodel is run with AUTOSAR 

metamodels and the resulting generic metamodel is examined. An overview of limitations 

that were encountered while conceiving the automation concept are given. An 

evaluation of achieved results concludes the chapter. 

• Chapter 6 concludes this thesis with a review of the problems and contributed solutions 

and an outlook to future work.

2. State of the Art 

This chapter gives an overview of the general software development principles, technologies 

and events that are relevant for this thesis. 

2.1. Model-Driven Software Development 

Model-driven software development gives answers to the issue of managing software of constantly 

increasing complexity. This section discusses the events that lead to such complexity 

and explains the background and principles of the model-driven solution. 

2.1.1. Growing complexity of software 

Current advancements in hardware and network technologies have led off to development of 

ubiquitous, collaborative software systems that became indispensable for the modern society. 

Software in these systems is often deployed in distributed and embedded environments that 

consist of various devices (from personal computers and mobile devices to specialized sensors 

and electronic control units), while communicating through diverse interaction paradigms 

[FR07]. The complexity of such software systems and the expectations of quality are increasing, 

while the software development cycles are becoming shorter. Such events cause 

software developers to face major challenges in all stages of the software life cycle [HT06]. 

However, a considerable factor that influences the complexity of developing such systems is 

not technical: it is the understanding of the problem domain - the area of interest to which 

the end-user is applying the software system - and the gap between the problem domain and 

the implementation of the problem solution [Eva03]. This gap appears when a developer 

creates software solutions by using abstractions that are at a lower level than those used to 

express the problem. When developing a system, the attempt to overcome this gap by using 

methods that rely on human effort will only increase the system’s complexity [FR07]. Tackling 

this issue thus requires a technology that will effectively raise the level of abstraction 

in which the solution is implemented, which in turn will result in improved productivity, 

efficiency and software quality. 

2.1.2. Abstraction in computing 

The history of computing can be observed as a study of layers of abstraction [Lid10, HT06]: 

from hard-wired computers to stored-program machines in the early days, programming has 

evolved from machine code to assembly languages and from there to third-generation languages. 

The third-generation languages enabled developers to ignore register allocation and 

low-level machine instructions by introducing high-level abstractions such as named variables 

and structured programming constructs. The translation back to machine code could be left 

to compilation technologies. Object-oriented languages introduced additional abstractions 

3


like abstract data types and objects, while domain-specific languages (see section 2.1.4) provided 

abstractions for particular application domains. Operating systems and device drivers 

were introduced to manage the complexity of interfacing with computer hardware and enabled 

developers to concentrate on application development instead on low-level hardware 

control. The abstraction of processes within an operating system introduced multitasking 

and allowed software developers to avoid dealing with the associated complexity to a great 

extent. Thus, each step in the evolution of programming languages and operating systems 

has introduced higher levels of abstractions, which enables software developers today to 

think in terms of domain objects rather than binary digits stored in a memory location. 

This way, the developers can better focus on the application domain because abstractions 

that are used to build a software product are conceptually much closer to the application 

domain itself. Model-driven software development introduces yet another abstraction with 

this goal in mind. 

2.1.3. The model-driven approach 

Model-driven software development (MDSD) is a software engineering approach consisting 

of the application of models and accompanying technologies to raise the level of abstraction 

at which developers create and evolve software [HT06]. By automating the various activities 

that comprise the software life cycle, the developers’ productivity can be increased while 

the cost of development and maintenance can be decreased. A model is a representation of 

a system or some part of a system that abstracts the aspects relevant to solving a certain 

problem and ignores irrelevant details [FR07, Sel03]. This representation enables an easier 

understanding of the system’s essentials. A model can also be considered as an abstraction 

of knowledge about a system’s domain [Eva03]. In MDSD, a model is not just an auxiliary 

artifact, but the central entity that is tightly integrated into the complete software development 

process. 

Models and modeling have had an essential role in engineering throughout history [Sel03]. 

Engineering models offer a visualization of the finished product. This helps to better understand 

a complex problem, its possible solutions and design flaws before the effort of a 

full construction is made. Engineering software means expressing ideas - it is not bound by 

physical laws as other engineering disciplines. Taking advantage of this opportunity brings 

out great potential for modeling techniques in software engineering: in MDSD the main 

focus of software development are models rather than computer programs. The advantage 

to this approach is that models are expressed by using concepts that are less bound to a specific 

implementation technology and closer to the problem domain (see section 2.1.2). This 

feature also facilitates a more effective communication with the stakeholders in a software 

project. The stakeholders are most likely more capable of understanding an abstract model 

rather than program code in a specific programming language [Lid10]. Thus, models can be 

used to reason about the problem and the solution domain, while the relationships between 

models provide dependencies that record the process of creating the solution and help the 

stakeholders better understand this process in all of its phases [BCT05]. 

As the system in development evolves, the models become more complete and the focus 

of effort shifts from models at higher abstraction levels to models at lower abstraction levels. 

Ultimately, models are used to directly produce program code that constitutes deployable 

4


software components [BCT05]. Since automation is the most effective technological way to 

boost productivity [Sel03], model transformations can be automated in order to ensure both 

consistency between models at different abstraction levels and increased productivity. If a 

MDSD technology provides means for automatic generation of complete program code, it 

causes the modeling language to take on the role of an implementation language. Essentially, 

this increases the abstraction level at which software is developed (as observed in section 

2.1.2). 

Expressing models requires a clear, formal notation of the model’s syntax and semantics. 

The syntax and semantics of a model are conveyed in its elements, their structure and references. 

The artifacts that provide this are yet again described in a model, which is called a 

metamodel. This formal approach is crucial to enabling the analysis, automation and transformation 

of models (see section 2.1.4). 

The notion of a model is not completely new to computing. If we look at a model as a 

representation of a system, then programming in any language involves some sort of model 

[Lid10]. A Java programmer thinks about the problem domain in terms of objects and Java 

classes, an SQL programmer through means of tables that have rows and columns. Common 

to both mentioned developers is that they are modeling a solution using the abstractions 

provided by the respective programming language. Hence, the process of analyzing a problem, 

creating a solution and expressing a solution in a high-level programming language can 

be considered an implicit form of modeling, which essentially makes software development 

a model-based problem solving activity [FR07]. These mental models evolve as a result of 

discussions with the project stakeholders, changes in requirements, errors discovered while 

testing etc. and lead the development of manually written code. The mental models can be 

shared with others using informal sketches or as formal statements in a modeling language. 

2.1.4. Principles of model-driven software development 

In order to facilitate the possibilities of models described in the previous sections, one should 

consider the following principles: [BCT05] 

• A formal notation for describing models through the means of metamodels enables 

meaningful transformation between models and represents the foundation for automation 

through tools. 

• Models expressed in a well-defined notation are essential for understanding a system 

solution. 

• Building a system can be organized around models by applying transformations on 

models and organizing them into a layered architecture. 

These principles can be identified each time MDSD is applied, regardless of the specific 

technologies and standards (such as executable UML, EMF or MDA) that are deployed. 

How these principles are realized is described in the remaining part of this section (in the 

order as presented above). 

5


Metamodels and metamodeling 

A metamodel uses a formal notation to define the abstract syntax and the semantics of a set 

of modeling constructs. In other words, a metamodel formalizes the concepts that are part 

of the problem domain and that a model should be able to represent, whereas the abstract 

syntax and the semantics describe the well-formed structure of a model [SV05]. 

Consider the two UML diagrams in figures 2.1 and 2.2. The UML class diagram in figure 

2.1 represents a simplified view of the domain of AUTOSAR software components and 

their communication paradigm. The software components communicate through interfaces 

that are defined by ports (see section 3.1.1). The UML object diagram in figure 2.2 illustrates 

a particular instance of the class diagram - an atomic AUTOSAR software component containing 

one provided and one required port that specify a client-server interface. The class 

diagram represents building blocks and relationships between those building blocks necessary 

to create models of AUTOSAR software components. Thus, the class diagram represents a 

metamodel for the model depicted in the object diagram. The model in the object diagram 

could further be used to automatically generate deployment code in a programming language 

(in AUTOSAR, software components are written in C [AUT10b]) and create the modeled 

object configuration - an instance of the model. 

Figure 2.1.: Simplified view of the domain of software components and their communication 

paradigm in AUTOSAR, expressed in the UML class diagram notation. 

The notation used for creating the diagrams in figures 2.1 and 2.2 is the UML structure 

diagram. The rules of UML on how to specify the different classes, attributes, objects and 

other entities constitute a metamodel for creating UML models. Thus, it can be concluded 

that the model notation is always relative to a metamodel. 

The Object Management Group (OMG), which stands behind the UML standard, defines a 

whole set of metamodeling levels (see figure 2.3). According to OMG, level M0 corresponds 

6


Figure 2.2.: The UML object diagram representing a model of an AUTOSAR software component. 

The model conforms to the metamodel in figure 2.1. 

to an instance of a model that typically represents real-life objects. Level M1 represents the 

information or problem domain, which is captured in the model. The metamodel is found on 

level M3. It defines the language for creating a model - this is UML itself. Finally, level M3 

provides the infrastructure for defining metamodels - the metametamodel. At this level, the 

Meta Object Facility (MOF), OMG’s metamodeling language, is situated. In order to avoid 

infinite stacking of further meta-layers, MOF recursively describes itself and is thus its own 

metamodel [mdsb]. This is a common approach and can be found in other technologies, such 

as XML Schema [mdse], Backus-Naur Form (BNF) grammars [mdsd] and Ecore (presented 

in section 2.2.1). 

If we strictly apply OMG’s layers to the AUTOSAR software component example, then 

the object diagram corresponds to level M0 and is an instance of the model represented by 

the class diagram on level M1. UML was used as the metamodel on level M2 and UML’s 

metamodel is MOF on level M3. Notice that the generated C code is left out and the object 

diagram took the role of a model instance. Here, one could argue that these two represent the 

same concept, but in a different notation (C code on one hand and a UML object diagram 

on the other hand). However, if we try to map the software component artifacts to the four 

layers as they were initially described, we get a different result: in the initial example, the 

C code is considered an instance of a model and therefore corresponds to level M0. The 

AUTOSAR software component model depicted in the object diagram corresponds to level 

M1 and the software components domain depicted in the class diagram corresponds to the 

metamodel on level M2. This leaves us with UML at the metametamodel level M3. However, 

7


Figure 2.3.: The four (meta)modeling layers as specified by OMG. 

we know that UML’s metamodel is not UML itself but MOF, which is now missing a layer. 

Indeed, the number of considered abstraction levels depends on the specific technology (i.e. 

Ecore defines only three levels). 

Domain Specific Languages 

In the process of creating a solution for an engineering problem, one can apply either a 

generic or a specific approach [vDKV00]. A generic approach offers a solution for many 

problems, however, such a solution might not be optimal. A specific approach offers a better 

performing solution for a small set of particular problems. This phenomenon is present in 

computer science, too [Tah08]: one can distinguish between general-purpose languages and 

modeling languages on the one hand, such as Java and UML, and domain-specific languages 

(DSLs) on the other hand, such as SQL and HTML. Often there is a distinction between 

visual DSLs, such as the Eclipse Graphical Editing Framework [mdsc], and textual DSLs, 

such as ARText [mdsa], which is a subproject of Artop (see section 3.2). Interestingly, some 

older programming languages - like Cobol, Fortran and Lisp - were all conceived for solving 

specific problems and came to evolve to general-purpose languages. Such evolution though 

causes a need for specialized language support to solve problems in specific application domains. 

This is why language designers today are especially interested in DSLs. 

8


The software component example given earlier in this section reflects this nature in a small 

scope: a general-purpose modeling language, UML, was used to create a specific modeling 

language intended to model simple AUTOSAR software components. 

DSLs can help bridge the gap between the problem and the solution domains: they allow 

solutions to be expressed in terms of problem domain entities and at the level of abstraction 

of the problem domain [FR07]. This makes it possible for domain experts to not only use 

DSLs, but also understand, validate and develop the language themselves, while not having 

to be concerned with implementation details at lower abstraction levels [vDKV00]. Thus, 

DSLs offer abstraction qualities that are necessary to express models in MDSD. 

Model transformation 

Model transformations are used to transform models that were initially conceived for some 

purpose into models that are better suited for other purposes while maintaining model traceability. 

Maintaining model traceability means keeping the transformed models consistent and 

the relationship between them traceable [FR07, HT06]. A typical example is the transformation 

from a technology-independent, high-level abstraction model to a technology-specific, 

low-level abstraction model that features specific data instead. 

Model transformations require a model as one of the inputs in the automation process and 

one or more models and/or different levels of executable code as output. Different types of 

transformations exist which can be classified as follows: [BCT05] 

• Refactoring transformations reorganize a model based on well-defined criteria. The 

output is a revision of the original model - the refactored model. 

• Model-to-model transformations convert information from one or more models to 

another model or a number of models. The goal is usually to convert information at 

one abstraction level to a different abstraction level. This type of transformation can 

also have other purposes that are specific to certain issues within the problem domain 

- such a transformation is the subject of this thesis (see section 4.1.1). 

• Model-to-code transformations convert model elements into program code and are 

often the final transformation that is performed. 

Transformations can be applied both manually and automatically [BCT05]. In a manual 

transformation, a developer or a domain expert analyzes the input model and manually 

creates or modifies the elements in the transformed model by interpreting the information 

in the original model. Automatic transformations apply a series of changes to a single or 

a number of input models based on predefined transformation rules. The rules can be provided 

by a tool used to perform the transformations or can be manually tailored based on 

domain-specific knowledge. Utilizing automatic transformation requires the input model to 

be syntactically and semantically well-formed. Combined, semi-automatic approaches where 

the automation process requires manual input in order to produce a correct transformation 

are possible, too (see sections 2.3.2 and 4.1.1). 

9


In a roundtrip engineering approach, models describing system design are used to generate 

code stubs that need to be further refined by the programmer. The code generation 

process applies a set of patterns to transform model elements to code (see section 2.2.3). 

The refinements in code need to be reflected in the model by either adapting the model 

manually or by using a transformation tool [BCT05]. In a model-centric modeling approach, 

models are established that convey enough detail for a full implementation to be generated 

through model-to-code transformation. A manual examination and modification of 

the generated code is unnecessary, just as this is the case with machine code generated by 

compilers. Furthermore, modern generators can achieve performance and memory efficiency 

that outperforms equivalent manual-written code [Sel03]. 

2.1.5. Model-driven software development in the automotive industry 

MDSD has found application in the telecommunications, financial and aerospace industries 

as well as in web application and software product line development [MD08]. However, this 

section gives an overview of using MDSD in the automotive domain. 

Modern innovations in the automotive industry are shifting from advances in mechanical 

engineering and mechanical solutions to electronic and software functions. Over the last 

years, advances in electronics made up 90% of innovations in new automobiles [VSK05]. 

This course of events causes software to become an important aspect of vehicle development. 

Traditionally, automotive embedded software applications are comprised of small programs 

that run on a single device, thus being self-contained and not depending on systems outside 

of the vehicle. However, the amount and complexity of embedded software is rapidly 

increasing due to networks of embedded, interacting devices that communicate through various 

channels and bus systems [VSK05]. Furthermore, telematics applications sending data 

from and to the vehicle and the recent trend towards the integration of mobile devices with 

the vehicle contribute to the complexity and require a complex integration of the involved 

systems [NH08]. 

The general goal in today’s embedded software development is to reduce the complexity 

of the system, to save development effort and to achieve a shorter time-to-market, while 

taking into account the requirements such as software modularity, customizability and extensibility 

[VSK05]. Thus, the issue of growing software complexity (see 2.1.1) holds also for 

the automotive industry. In the remaining parts of this section, selected work on deploying 

MDSD in the automotive domain is presented. 

A research roadmap for software engineering in automotive systems was devised in [PBKS07]. 

Five different features of the automotive software domain are introduced. Their characteristics 

are mapped onto research issues, followed by a proposal of using MDSD to address some 

of the issues. The proposal identifies four types of models and elaborates each one in detail: 

10 

• Requirements models embrace all issues related to requirements and deal with the 

behavior of embedded software functions from the users’ point of view. The use cases 

and related behavior specifications are a part of the models. 

• The logical architecture represents a breakdown of the software functionality into inter-


acting logical components, including their behavior. The logical components provide 

functionalities described in the requirements model. 

• The technical architecture defines the deployment architecture, i.e. all hardware units, 

the basic software (operating system and middleware) on them and their connections - 

controllers, communication devices, actuators and sensors, as well as a mapping from 

the logical architecture (its structures and behaviors), to this deployment architecture. 

• Behavioral models specify the functionality at a detailed level and allow the generation 

of production, simulation and test code. 

The work in [NH08] is motivated by the increasing integration of external devices and external 

communication into the vehicle. The authors focus on developing a facility for modeldriven 

development of embedded software that enables modeling from multiple viewpoints. 

The viewpoints include the functional viewpoint, software structure viewpoint and humanmachine 

interface viewpoint. They achieve this by extending a modeling facility that has 

been proven successful in body electronics ECUs to the system level and the infotainment domain. 

Furthermore, they include the associated requirements for wireless connectivity. This 

way, they bring the different viewpoints together in a set of models. These models provide a 

possibility to handle the associated complexity and ensure the quality of the vehicle software. 

In [GHH04] the use of well-understood mathematical modeling frameworks that allow formal 

verification of a system is emphasized. The background idea is early detection of bugs and 

problems in order to achieve a more efficient embedded software development process. The 

developed model-driven process places strong emphasis on performance and as much testing 

and verification in tight-loops as possible. The models and controllers are framed in the 

context of hybrid automata. 

Software variability in automotive systems refers to deploying varying controller software 

on the same ECU (while maintaining the same principal software structure) according to 

different customer requirements. During product configuration (configuration of the ECU 

software according to customer needs), specific class variants have to be selected (see section 

3.1.2). Selecting the right combination of variants for a certain product is error-prone because 

of the vast number of variants. Knowledge about dependent variants and conflicting 

variants is currently not explicitly included in models, but it is up to the software engineers 

to be aware of such dependencies and to resolve them. A solution to this problem is proposed 

at system design level in [Gri08] by extending existing tools to allow explicit modeling of 

dependencies between variants through creating appropriate metamodels. 

A model-driven method for building embedded component infrastructures based on the 

combination of component/container infrastructures is developed in [VSK05]. In particular, 

automatic code generation is used to create infrastructure code required to make the 

application logic work in the context of the embedded system’s hardware infrastructure. 

Building a software infrastructure for embedded components is also one of the central issues 

addressed by AUTOSAR. This extensive application of MDSD in the automotive domain is 

concerned in this thesis and is presented in detail in chapter 3. In particular, AUTOSAR 

addresses the logical and technical architecture mentioned above. 

11


2.2. Eclipse Modeling Framework 

The Eclipse Modeling Framework (EMF) is a utility for creating model definitions and modeling 

applications based on the Java programming language. As its name reveals, EMF 

exploits the facilities provided by the Eclipse Platform. EMF brings together Java, XML 

and UML: it allows to define and process models with any of these technologies. It also 

enables cross-transformations between these forms. EMF provides a runtime framework 

that can be used to validate, persist and edit any modeled data. Furthermore, it enables 

code generation of corresponding implementation classes, including Eclipse plugin artifacts. 

Figure 2.4 depicts how these features are organized into the EMF architecture. The features 

are described in detail throughout this section. 

EMF is not a high-level modeling technology, but rather places itself in the middle between 

the modeling and the programming worlds - to maximize the effectiveness of both 

[SBPM09]. An EMF model is essentially a subset of the UML class diagram. Even with this 

simple approach, the benefits of modeling in a standard Java development can be exploited 

to a great extent. Thus, EMF does not require a developer to understand complex mappings 

between high-level modeling concepts and the generated Java code, as the mappings 

are rather straightforward. 

Figure 2.4.: The EMF architecture (image adopted from [Ste08]). 

2.2.1. Ecore - the EMF metamodel 

The formal syntax of models in EMF - the EMF metamodel - is represented by the Ecore 

model. Ecore is itself an EMF model and therefore its own metamodel (see section 2.1.4). 

Ecore is inspired by OMG’s MOF and resembles it in its ability to specify classes, their 

structural and behavioral features, inheritance and reflection [SBPM09]. Ecore is situated 

at the Core of the EMF architecture in figure 2.4. 

12


In the following, some key aspects of the Ecore metamodel (see figure 2.5) will be described. 

• An groups related classes together in a package. Thus, EPackages are useful 

for structuring large models. When an Ecore model is serialized, the root element 

represents a package. 

• An models classes themselves. Classes are identified by name and can have a 

number of structural features, such as attributes and references. In order to support 

inheritance, a class can refer to one or more other classes as its supertypes. Abstraction 

is supported through respective EClass properties. 

• An is the common base class for EAttributes and EReferences. 

Both have a name and a type. EStructuralFeatures represent the components of 

an object’s data. They also define the state of an instance of the EClass they are 

contained in. Besides name and type, EStructuralFeatures have various properties 

that define them closely, such as upper and lower bounds, mutability, uniqueness etc. 

• An models the behavioral features of a class only by specifying interfaces 

to the operations (an actual behavior implementation can be supplemented through 

annotations). 

Figure 2.5.: An excerpt from the Ecore metamodel (image adopted from [Ste08]). 

EOperation is not displayed in this image. 

The structure of a domain model can be defined as an Ecore diagram (in an editor that 

is shipped with EMF, see figure 2.6), as XML or XML Schema Definition, as UML and 

as annotated Java. In each case EMF creates the corresponding Ecore model, which can 

then be used to automatically create model representations in all the other forms as well. 

13


Finally, an Ecore model can be created directly as a model tree. Besides loading a model 

from a serialized form, a model can be created programmatically. Essentially, creating a 

model means specifying the types of objects that make up the model, their data and their 

relationships. 

EMF uses a model in two different contexts [SBPM09]. During application development 

it is the primary source of information for the EMF code generator which produces a Java 

implementation of the model. At runtime a model can be manipulated through EMF’s 

generic API (similarly to reflection in Java) and dynamically explored and processed by 

user-written code (see section 4.3.4). 

The AUTOSAR software component example that was specified as a UML class diagram 

in figure 2.1 can be created as an Ecore diagram. An Ecore diagram resembles the UML 

class diagram notation. From the Ecore diagram EMF automatically creates the tree view 

and the XMI representation of the model, just as it would have created a diagram and a 

tree view had the model been initially created in XMI format. These representations of the 

software component metamodel are shown in figure 2.6. 

2.2.2. Model persistence 

The ability to persist and reference other persisted models is a key feature of EMF modeling 

[SBPM09]. Therefore, EMF provides powerful mechanisms for managing persistence of 

models. Persistence is part of the Core of the EMF architecture in figure 2.4. Generally, 

Ecore models are serialized in the XML Metadata Interchange (XMI) format (see figure 2.6). 

EMF also supports saving objects in any persistent form - though this might require writing 

custom serialization code - and referencing the objects serialized in this custom format. 

2.2.3. Code generation 

The boost in productivity that results from automatic code generation is an important 

benefit of EMF [SBPM09]. The EMF code generator (represented by the Codegen part 

of the EMF architecture in figure 2.4) does not produce code directly from a particular 

Ecore model, but uses a generator model instead. The generator model wraps the original 

Ecore model and supplements data regarding implementation details that are necessary for 

code generation in addition to data contained in the original model. Figure 2.7 shows the 

generator model and the various properties that can be set to generate model code that 

complies to these properties. 

The generator uses various patterns (which reflect design decisions made by the EMF creators) 

to produce high-quality model code. This model code includes type-safe interfaces 

and efficient implementations for creating, modifying, saving and loading model instances. 

The EMF generator also takes manual editing of generated code into account and provides a 

means to regenerate model code without overwriting manual changes. The generated model 

artifacts include (but are not limited to) the following [SBPM09]: for each model a factory 

and a package are generated that provide a create method for instantiating each modeled 

class and accessors to Ecore model metadata. These artifacts serve as an entry point for 

model reflection. Furthermore, for each class a corresponding interface and implementation 

14


Figure 2.6.: Three representations of the simplified AUTOSAR software component metamodel: 

Ecore diagram (up left), Ecore tree view (up right) and the XMI serialization 

format (down). 

15


Figure 2.7.: The generator model (up left) and code generation properties (down) for the 

software component model (up right). 

16


class are generated. The separation between interface and implementation is a design favored 

by the creators of EMF: it is the best pattern for a model API and complies with 

design choices found in Eclipse itself. The generated methods for structural features contain 

not only the getter-and-setter stubs, but also observer notification implementations (as in 

listing 2.2) and support bidirectional reference integrity. 

Internally, the generator uses templates that can be extended by the user if needed (or 

completely replaced by fully customized ones, thus creating an own generator). The Java 

Emitter Templates (JET) that are used in the EMF generator consist of fixed content - 

that is meant to be output exactly as it appears - and of Java Server Pages (JSP)-like tags 

that are evaluated and interpreted by the template engine while processing model elements 

[SBPM09]. 

The interface and implementation of the SoftwareComponent class generated from the corresponding 

generator model are given in listings 2.1 and 2.2 respectively. Essentially, all 

the generated artifacts together comprise the software component model API. This model 

API can be used to create and manipulate instances of software components, ports and port 

interfaces in a Java program. Further examples of how the model API can be used is given 

in section 3.2.2. The prototype that implements the automation concept developed in this 

thesis (see section 4.3) also uses a model API to programmatically explore a model instance 

(and create a new model based on found information). 

... 

SoftwareComponent EObject { 

} 

String getName (); 

setName ( String value ); 

String getType (); 

setType ( String value ); 

EList getPorts (); 

Listing 2.1: Generated interface for the SoftwareComponent class. Generated imports and 

comments have been omitted for clarity. 

... 

SoftwareComponentImpl EObjectImpl 

SoftwareComponent 

{ 

... 

EList ports ; 

17


} 

SoftwareComponentImpl () { 

(); 

} 

String getName () { 

name ; 

} 

setName ( String newName ) { 

String oldName = name ; 

name = newName ; 

( eNotificationRequired ()) 

eNotify ( ENotificationImpl ( , Notification .SET , 

SwcomponentsPackage . SOFTWARE_COMPONENT__NAME , oldName , 

name )); 

} 

... 

EList getPorts () { 

( ports == ) { 

ports = EObjectContainmentEList ( Port . , 

, SwcomponentsPackage . SOFTWARE_COMPONENT__PORTS ); 

} 

ports ; 

} 

... 

Listing 2.2: Generated implementation for the SoftwareComponent class. Generated 

imports, comments and optimization methods have been omitted for clarity. 

Additionally the EMF generator produces a set of classes that utilize EMF.Edit (depicted in 

figure 2.4). These generated classes can be used to build a visual model editor. The editor 

can be used for creating and editing models and can be easily integrated into the Eclipse 

framework as an Eclipse plugin. The editor can be enriched with custom functionality and 

model functions specific to the model domain (i.e. a JET template could be written that 

produces C code from modeled AUTOSAR software components - this could be offered in 

the editor as a code generation function). Figure 2.8 shows the generated editor for the 

software component model. 

The final result is a visual domain-specific language (see section 2.1.4) for modeling simple 

AUTOSAR software components that consists of a visual editor and the corresponding functionality 

required to create and edit software component models. 

In a fashion similar to the simplified software components example, Artop (see section 3.2) 

exploits the power of EMF to create a DSL (and a full-scale framework) for modeling complete 

AUTOSAR systems. 

18


Figure 2.8.: The software component model editor generated with EMF and integrated into 

the Eclipse framework. The editor features a software component with two ports 

that define a port interface. 

2.2.4. EMF Compare 

EMF Compare is a model comparison facility for Ecore models. Models evolve due to changes 

in their domain and these changes may be performed by a number of people involved in the 

modeling process. The need to identify these changes and access model history arises, thus a 

model comparator becomes an essential tool in MDSD (see role of tools in MDSD in section 

2.1.4) [Tou06]. The EMF Compare tool provides a stable, generic model comparison implementation 

that can be used out-of-the-box, but at the same time it has been designed with 

extensibility in mind. Therefore, every part of the comparison process is extensible and can 

be customized according to user needs [emfa, Bru]. Figure 2.9 illustrates the comparison 

process and emphasizes parts that can be customized. The DiffMap project (see section 4.2) 

utilizes the extension possibilities of EMF Compare and customizes the diff builder and diff 

extension parts of the process depicted in figure 2.9. 

Currently, EMF Compare supports comparison of two or three models at most. The comparison 

process consists of two phases. In the matching phase, one model is browsed through 

while for each of its elements a corresponding element is searched for in the opposite model. 

The result of the matching process is presented in a match model. The differencing phase 

uses the match model and identifies the differences between matched elements to produce a 

diff model. The diff model then holds change information across the compared models. The 

diff model can be extended according to domain and user specific needs (see section 4.2.1) 

[Bru08]. 

19


Figure 2.9.: The EMF Compare process. Artifacts colored red can be customized to match 

specific user needs (image adopted from [Bru08]). 

The match engine is crucial in the comparison process as it determines the quality of the final 

comparison result. The generic match engine that ships with EMF Compare (and that was 

used in the DiffMap project, see section 4.2) is based on total comparison of the attributes 

of a model element and goes back to the fundamentals of information theory [Tou06]. In 

particular, it considers the name, content, type and relations of an element in order to 

determine similarity [Bru08]. 

2.3. Model evolution 

Evolution is an omnipresent aspect of software development which affects the whole software 

life cycle and spans across different artifacts involved in creating software. Model-driven 

software development is subject to software evolution as well. In [Bre10], the concept of 

living models is introduced. This paradigm is used to define model-driven management, 

design and operation of dynamically evolving systems. With an emphasis on metamodel 

and model evolution, current research in this area is concerned with two issues that can be 

considered complementary: 

20 

• Model versioning is an important task in MDSD. However, tools and techniques to 

support model versioning and change management are not as commonly available as 

they are for other software artifacts, such as text-based systems used for versioning 

source code. Crucial model versioning questions are the comparison of models and the 

representation of the comparison result [Gru06].


• Model adaption is the necessary response to metamodel evolution. As metamodels 

evolve due to changing requirements or refactorings during the development process, 

models need to be migrated to prevent invalidity and retain compatibility with regards 

to the evolved metamodel. 

In the following sections selected approaches to solve these issues are presented in more 

detail. Some open questions in model versioning and adaptation are summarized. Where 

appropriate, references to the subject of this thesis are given. 

2.3.1. Model versioning 

Current widely used version control systems (such as SVN [relc]) and their storage and visualization 

features rely upon the line-based comparison of a stream of text contained in 

a single file. This approach works well for artifacts such as source code. When applied to 

models, the only way to archive a model is to convert it into a linear file, usually an XML 

representation (see section 2.2.2). This however destroys the intuitive model hierarchy, as 

hierarchy and containment in models are replaced by links and references within the XML 

document. In order to acquire information from the comparison result, a model developer 

must browse through the XML documents and search for tags that denote change, while 

having to possibly mentally convert XML data back to a structured model representation. 

Hence archiving and versioning models requires an approach that will take into account the 

model structure directly. Thereby, model comparison and visualization of model differences 

are the central questions [LZG04]. A model-centric versioning system was developed in 

[Kal10], which will be explained in more detail later. 

Model comparison is required to detect changes between different models. In version 

control systems, one wants to track changes caused by evolutionary development. In the 

GAUTOSAR project (see section 3.3), the identification of changes is necessary to determine 

a common, generic model respective of all compared models. In both cases, manual 

comparison is tedious, time-consuming and error-prone (see section 4.1). The question that 

arises first is what properties of the models should be compared, followed by the question of 

how to define the mappings between two models [LZG04]. The EMF Compare framework, 

which was used in work dealing with GAUTOSAR, considers the name, content, type and 

relations of a model element in order to determine similarity (see section 2.2.4). Furthermore, 

section 4.2.4 describes AUTOSAR-specific comparison issues that arose during the 

course of this thesis. 

Visualizing model differences requires a different approach than parallel visual mapping 

of differences that is common for text files since linear files cannot sufficiently represent 

the hierarchical nature of models. The visualization technique is crucial for providing a fast 

and understandable overview of changes between model versions. A common technique is 

coloring, where different colors are used to indicate different types of changes. Coloring is 

also used in the approach of [Kal10], which will be discussed in the following paragraph. The 

DiffMap project (see section 4.2), which is concerned with model comparison in GAUTOSAR 

and which this thesis builds upon, uses history elements to model changes in a historical 

context at the position where they occurred in a model (see sections 4.2.1 and 4.2.2). 

21


A model-centric versioning system was developed in [Kal10]. It is a model repository 

for UML models with emphasis on model merging. The motivation behind the development 

of a model repository is the current lack of such tools. EMF Compare was customized for 

UML models (compare with DiffMap’s extensions to EMF Compare in section 4.2.1). In 

particular, it was used to compare the HEAD version of a model stored in the repository 

with the model being committed. The results are presented to the user in a UI which uses 

colors to denote differences. The user can initiate the merge of some or all model elements 

through EMF Compare. The result is presented in a diffModel. These functions are all part 

of a client tool. On the server side, it was attempted to use the EMF Compare diff model 

as a symmetric delta and thus the central versioning entity in the repository. This approach 

was abandoned in favor of EPatch [rela], which is further described in the next section. 

An approach to comparing models which conform to arbitrary metamodels is developed 

in [RV08] by using the Maude specification language [relb]. Maude is used to define 

a difference metamodel and a set of operations that provide support for calculating 

differences, composing simple differences to complex ones and applying model differences 

to perform model migration. In Maude, models are represented by object configurations, 

while metamodels are represented by object-oriented modules. This way, models conform to 

metamodels by construction. The difference model distinguishes between element addition, 

deletion and modification, but does not reflect elements that have not changed. This is in 

contrast to the EMF Compare difference model and its extensions by DiffMap (see section 

4.2.1): there, unchanged elements are included in the difference model with a ”clear” history. 

This approach has two advantages. On one hand, a domain expert examining the DiffMap 

model is presented a model as a whole and thus it is easier to mentally map it to the original 

model. On the other hand, GAUTOSAR is primarily concerned with model elements which 

feature no or little change in order to fulfill its goals (see section 3.3 for details). What is 

similar to EMF Compare is the calculation of differences in a matching and a differencing 

step. Matching can be performed in two ways. Since Maude objects have persistent identifiers, 

one possibility is to match objects comparing these identifiers. However, if the two 

models conform to different metamodels then two elements that are semantically the same 

will most likely not have the same identifier. This problem occurred within this thesis and is 

described in more detail in section 4.2.3. Thus, the other possibility is to match objects by 

using structural similarities (as EMF Compare does), which is again implemented in Maude. 

2.3.2. Model adaptation 

Manual model adaptation essentially suffers from the same peculiarities as manual model 

comparison described above. Moreover, metamodels may evolve in different ways: where 

some changes are independent from other elements and thus require no or limited model 

revision, other changes can lead to inconsistencies that cannot be easily and automatically 

resolved. With regard to these findings, the possible changes have been classified as follows: 

[CDREP08, Gru06] 

22 

• non-breaking changes: changes in the metamodel which do not break the consistency 

of the model to the corresponding metamodel. 

• breaking and resolvable changes: changes in the metamodel which break the consistency 

of the model, but can be automatically resolved.


• breaking and non-resolvable changes: changes in the metamodel which break the consistency 

of the model and cannot be automatically resolved. These changes require 

manual intervention by a domain expert. 

The concept of non-breaking and breaking changes can also be found in API evolution and 

the way it influences programs that make use of the API. An example for a non-breaking 

API change is the addition of a method in some class: this change does not break the existing 

instances of the class. The renaming of a method is an example for a breaking change: it 

breaks the program code that invokes this method by its old name because the code fails to 

compile. The code has to be adapted to use the new method name before it can compile 

successfully. 

The DiffMap model can be used as an information source for adapting AUTOSAR models 

to new versions of the AUTOSAR metamodel. This requires a transformation program 

that will adapt AUTOSAR models by utilizing metamodel change information found in the 

DiffMap model. However, this is not in the scope of GAUTOSAR and will not be further 

discussed in this thesis. 

OMG M-levels concept (see section 2.1.4) is used to elaborate on frequency and impact 

of model change in [Gru06]. M3 models represent modeling tools that are independent 

of the problem domain. As such, they are considered unchangeable from the point of view of 

the software solution and its life cycle. Changes to M2 models follow from insights into the 

problem domain as the software project evolves. These changes may cause inconsistencies 

in M1 models. M1 models are changed on a daily basis. Therefore, a need for a catalog of 

changes on M2 level and their influence on M1 level is identified. This catalog should be used 

to create algorithms for automated break resolution. Such catalogs have been constituted 

with varying levels of detail in [CDREP08], [BGGK07] and [HVW11]. 

Co-adaptation is a term coined in [CDREP08] to describe model adaptation required upon 

metamodel change. Furthermore, a transformational approach for model co-adaptation is 

proposed where well-defined adaptation steps can be automatically generated from modifications 

that the metamodel underwent. In order to facilitate this, a difference model of the 

metamodels is exploited to co-adapt the depending models. This difference model consists 

of all manipulation operations from the original metamodel to the evolved metamodel. This 

method of detecting change is known as recording the metamodel change trace, in contrast 

to direct comparison method used in EMF Compare (see section 2.2.4). A discussion of 

advantages and disadvantages of both approaches is given in [BGGK07] and [Eys08]. 

The work in [Eys08] explores the change tracing method in more detail and utilizes wellknown 

technologies such as the observer pattern and existing EMF utilities to implement 

this method in a patch. A patch is an EMF model that serves as a difference model where 

changes are described as atomic primitives, which enables transforming the old metamodel 

to the new one and vice-versa. The atomic primitives are then grouped into composite 

changes and augmented with information required for the co-adaptation algorithm. The 

patch technology was used for the development of the model versioning system in [Kal10] 

(see section 2.3.1). 

23


The COPE (COuPled Evolution of metamodels and models) project developed from a thesis 

done at BMW Car IT [Her07]. The term coupled evolution is used to describe the process 

of breaking down metamodel history into small steps of metamodel evolution and the associated 

model adaptation. In more detail, it is denoted that some primitive changes only make 

sense when regarded in combination with others, such as the migration of a class attribute 

to the superclass. In this case, primitive changes need to be combined and interpreted as 

a compound change. Coupled evolution steps can be divided in the same way as the types 

of changes referenced at the beginning of this section. The evolution steps can be complete 

if no manual interaction is necessary to correctly adapt a model or incomplete otherwise. 

Furthermore, the evolution steps are open if domain-specific knowledge is necessary to fully 

adapt the model and closed otherwise. This distinction is equivalent to the distinction between 

automatic and semi-automatic adaptation. For open coupled evolution, the approach 

consists of maintaining metamodel history as a sequence of changes that lead from an empty 

metamodel to the current version. In the course of evolution history, previous versions of 

the metamodel are constructed at some point in time. Then model transformation rules in 

a sufficiently expressive language can be attached to any number of primitive metamodel 

changes. Closed coupled evolution provides a mechanism to specify transformation rules in 

form of coupled evolution operations independently of the metamodel, which can then be 

instantiated and applied in a model adaptation template. 

2.4. Summary 

This chapter explained the events that led to the increased complexity of modern software 

systems and how models can be used to tackle this issue. Examples from the automotive 

industry were used to illustrate applications of the model-driven approach. Capabilities of 

the Eclipse Modeling Framework were explored in the context of creating a modeling tool 

for basic AUTOSAR software components. The chapter was concluded with an overview 

of model evolution, its common problems and research directions aiming at solving these 

problems. 

24

3. Automotive Open System Architecture 

This chapter introduces specialized technologies that rely on model-driven software development 

to solve the complexity issue in developing automotive software. These technologies 

represent the scope of work concerned in this thesis. 

3.1. The AUTOSAR standard 

AUTOSAR (AUTomotive Open System ARchitecture) is an open standard that applies the 

model-driven approach (see section 2.1) to software development for Electronic Control Units 

(ECUs) in automobiles. AUTOSAR is motivated by the increasing complexity of modern 

automotive electric and electronic (E/E) architecture (see section 2.1.5). In order to manage 

this complexity, automobile manufacturers, suppliers and tool developers have formed a development 

partnership that cooperates on developing common, basic functions and supports 

competition on innovative functions [Hei04]. The ability to manage this complexity results in 

improved quality and reliability of automotive E/E systems. Furthermore, the AUTOSAR 

development partnership aims at creating scalable solutions that can be reused within and 

across vehicle and component product lines and at an improved development process. 

3.1.1. AUTOSAR architecture 

The AUTOSAR architecture (see figure 3.1) provides a common software infrastructure for 

automotive systems of all vehicle domains. It consists of multiple software layers that build 

up on each other and are interconnected through standardized interfaces. 

This approach is considered fundamental to achieving the following technical goals: [Hei04, 

AUT11c] 

• Modularity: enables combining functional modules from different suppliers. 

• Scalability: ensures compatibility of common software modules to different vehicle 

platforms. 

• Transferability: optimizes the use of resources throughout the electronic architecture 

of a vehicle. 

• Reusability: enables integration of software modules into new environments. 

The remaining part of this section describes the essential concepts of the AUTOSAR architecture 

in more detail. 

25


Figure 3.1.: AUTOSAR ECU architecture (image adopted from [AUT11b]). 

AUTOSAR Software 

The AUTOSAR design concept distinguishes between application and infrastructure. Thus, 

an application in AUTOSAR consists of interconnected AUTOSAR software components - 

each of which implements a part of the application functionality - and runs on the AUTOSAR 

infrastructure [AUT11d]. The software components have well-defined interfaces that are 

described through a standardized description format: [AUT10a] 

• operations and data elements the component provides and requires 

• requirements of the software component on infrastructure 

• resources needed by the software component (such as memory and CPU time) 

• information about specific implementation of the component 

By specifying provided and required data and services in this fashion software components 

can be exchanged as long as they provide the same communication interface. Furthermore, 

a software component is uncoupled from other software components in the sense that it does 

not require knowledge about whether it communicates with software components from the 

same (local communication) or from different ECUs (remote communication). The implementation 

of the software component is thus independent of the used network technology. 

The communication takes place through interfaces that are specified through ports, where 

a port is always assigned to only one component [AUT11d]. An interface can be either a 

client-server interface - by defining operations that can be used, or a sender-receiver interface 

- enabling data-oriented communication. If the client-server paradigm is used, a component 

providing an interface offers an implementation of the operations specified in the interface 

26


whereas a requiring component can invoke the operations. Equivalently, if a sender-receiver 

paradigm is used, a providing port generates the data whereas a receiving port consumes it. 

Virtual Functional Bus and Runtime Environment 

The Virtual Functional Bus (VFB) is a theoretical concept that represents an abstraction of 

the connections between AUTOSAR software components of the entire vehicle and between 

AUTOSAR software components and the components of the basic software. The VFB enables 

AUTOSAR software components to be integrated before the underlying ECU hardware 

is available, thereby speeding up the vehicle development process. The AUTOSAR runtime 

environment (RTE) functions as a communication center for both inter-ECU and intra-ECU 

information exchange that takes place between AUTOSAR software components [AUT10b]. 

Since these communication requirements depend on the deployment, the RTE needs to be 

customized for each ECU. Therefore, it can be seen as a realization of the VFB on a specific 

ECU. 

Basic software 

The basic software provides services to the AUTOSAR software components and is required 

to run the application part of the software, but it does not fulfill any functional tasks itself 

[Hei04]. The basic software consists of standardized components - such as an operating 

system, a communication framework to the vehicle bus systems (CAN, FlexRay etc.), access 

to the ECU’s microcontroller and other hardware such as sensors and actuators that are 

specific to each individual ECU. 

3.1.2. AUTOSAR methodology 

The AUTOSAR methodology describes the common technical approach for steps that are 

necessary for AUTOSAR system development [AUT11a]. Figure 3.2 shows a broad view of 

the design steps from system configuration to generating an ECU executable. The methodology 

is formalized as a workflow that defines dependencies between documents containing 

information and activities processing that information. 

Figure 3.2.: Overview of the AUTOSAR methodology (image adopted from [AUT11a]). 

The formal description of the contained information is supported by the AUTOSAR metamodel 

(see section 3.1.3). The activities involve complex processing of a large amount of 

27


data stored in the documents. Thus, the AUTOSAR methodology requires support through 

complex tools that allow a high degree of automation (see section 3.2). 

The System Configuration Input document in figure 3.2 defines the software, the hardware 

and the general system constraints. In particular, it requires for each software component 

a description of data types, ports and interfaces, for each ECU the specification of the 

processor unit, the memory, the sensors and actuators etc. The Configure System activity 

maps the software components to the ECUs and produces the System Configuration 

Description document. The Configure ECU activity, after extracting necessary information 

in the respective preceding steps, deals with the configuration of the RTE and Basic 

software modules. It results in the ECU Configuration Description, which contains all 

information specific for an individual ECU. Finally, Build Executable involves generating 

code for the RTE and the Basic software, compiling these sources and linking everything 

into an executable. 

The implementation of software components is independent from ECU configuration [AUT11e]. 

Figure 3.3 depicts the workflow that allows the development of a software component’s core 

functionality. 

Figure 3.3.: AUTOSAR methodology for software component implementation (image 

adopted from [AUT11a]). 

The Component Internal Behavior Description describes aspects such as scheduling issues 

and how a component responds to events, but does not specify any functional behavior. 

The Generate Component activity creates header declarations necessary for RTE communication. 

In the Implement Component activity a developer can utilize the information 

28


contained in the Component Internal Behavior Description and Component API documents 

to develop functional aspects of the component. This can be done independently 

from the design of the rest of the system. The functionality of the component is contained 

in the Component Implementation Description. The Compile Component activity uses 

the Component Implementation Description to compile the Component Implementation. 

Additionally the activity requires the Component API and the Additional Headers documents 

to complete the compilation process. The result of the Compile Component activity 

is the Compiled Component document and a refined Component Implementation 

Description. 

3.1.3. AUTOSAR metamodel 

The data contained in the documents that are utilized within the AUTOSAR methodology 

(see section 3.1.2) is supported through the use of an AUTOSAR metamodel and the accompanying 

templates 1 . The metamodel describes the structure of all components that compose 

the AUTOSAR architecture, i.e. software components (depicted in figure 3.4), ECU configuration 

and basic software modules. The templates describe the respective parts of the 

metamodel in more detail [AUT09]. 

Figure 3.4.: Detailed view of the AUTOSAR metamodel in [autb] describing different types 

of software components in AUTOSAR and their relationships. 

1 The metamodels and the templates are available at the official AUTOSAR website. The metamodels are 

described in terms of UML diagrams and available as Sparx Systems Enterprise Architect Project files. 

29


The AUTOSAR standard is subject to constant improvement. This causes the corresponding 

metamodel to evolve as well. Each new release of the AUTOSAR standard brings with it 

evolutionary modifications of the metamodel. If one compares the respective metamodels 

of AUTOSAR versions 3.1 ([auta]) and 4.0 ([autb]), one will notice structural changes in 

both parts describing the overall structure and very detailed parts of the metamodel. One 

metamodel always belongs to only one version of the AUTOSAR standard. 

3.2. Artop 

Developing AUTOSAR systems (see section 3.1.2) is supported through the use of appropriate 

tools. All these tools must cover basic functionality related to handling AUTOSAR 

models. A simple example is the ability to load an AUTOSAR model into the memory so it 

can be manipulated through tool functions. The specific functionality of the tool vendor’s 

area of expertise can be built on top of the common functions. However, with every tool 

vendor implementing the common AUTOSAR functionality on their own, a great deal of 

redundant development occurs among the vendors [KRV + 10b]. This approach is illustrated 

on the left hand side in figure 3.5. Artop (AUTOSAR Tool Platform) addresses this by 

applying the ecosystem approach to the field of AUTOSAR tools in a way that resembles 

ecosystems found in open-source projects [KRV + 10a]. An ecosystem in this sense refers to a 

concept where the value of products and services of the ecosystem participants complement 

each other. Such an organization implies the requirement for using common technologies 

and standards. This approach is illustrated on the right hand side in figure 3.5. 

Figure 3.5.: Non-collaborative and collaborative AUTOSAR tool development approach in 

comparison (image adopted from [KRV + 10b]). 

Artop is an infrastructure platform for tools used to design, develop and configure AUTOSAR 

systems which provides an implementation of common tool functionality. The community 

developing Artop - the Artop User Group - consists of AUTOSAR members and partners. 

This way Artop offers both an organizational and a technical advantage: an improved cooperation 

with AUTOSAR partners as well as a high interoperability and integration of 

AUTOSAR tools [Rud10]. 

For a better understanding of how Artop works and its role in the AUTOSAR world, the 

Artop stakeholders are presented: 

30 

• Artop developers are the immediate creators of the infrastructure platform that 

constitutes Artop and that is defined in this section. Artop developers comprise the 

Artop User Group layer of the Artop architecture in figure 3.6.

3.2. Artop 

• Artop users or AUTOSAR tool developers utilize the infrastructure provided by 

Artop developers to create vendor-specific tools. AUTOSAR tool developers comprise 

the Tool Vendor layer of the Artop architecture in figure 3.6. 

• AUTOSAR tool users work with tools provided by AUTOSAR tool developers to 

create AUTOSAR models. Such tools are comprised of all the layers of the Artop 

architecture in figure 3.6. 

3.2.1. Artop architecture 

Artop builds upon the Eclipse Platform and makes heavy use of the Eclipse Modeling Framework 

(see section 2.2) to create an infrastructure for realizing AUTOSAR tools. Where an 

adaption of existing Eclipse technologies is necessary, Artop provides a set of extensions to 

the respective Eclipse projects. Figure 3.6 shows the different layers of the Artop architecture: 

[Rud10] 

• Competitive Layer. Tool vendors commercially develop plugins at this level and 

realize their tool functionality by using the infrastructure provided by Artop. 

• Artop AUTOSAR Layer. This layer provides software components and plugins 

that implement AUTOSAR-specific functionality. 

• Artop Eclipse Complementary Layer. This layer implements Artop’s extensions 

to the Eclipse platform, but does not contain any AUTOSAR specific functions. Since 

Artop release 3.0 this layer has become a part of the Eclipse Sphinx project [sph] and 

is located in the Eclipse Platform layer. 

• Eclipse Platform. Eclipse is well-suited for developing domain-specific IDEs, hence 

it is used as Artop’s foundation. 

Figure 3.6.: Layers composing the Artop architecture (image adopted from [Rud10]). 

31


3.2.2. Developing AUTOSAR tools with Artop 

The Artop architecture contains implementations of AUTOSAR metamodel releases and enables, 

among other related AUTOSAR services, creation and editing of AUTOSAR models 

in a visual editor (as depicted in figure 3.7) [Rud10]. As mentioned in section 3.1.3, the 

AUTOSAR metamodel is subject to evolution. Artop aims at supporting a number of metamodel 

versions rather than just one. A wide support approach - together with functionalities 

that add value to the tools that make use of Artop - ensures a greater acceptance of Artop 

in the AUTOSAR community and especially among AUTOSAR tool developers. 

Figure 3.7.: Two models created with the Artop Technology Demonstrator - an Eclipse-based 

AUTOSAR tool which was built by the Artop community to showcase Artop’s 

capabilities. The same is also possible in any AUTOSAR tool that makes use 

of Artop. 

In the background Artop provides a model API that can be used to build and process an 

AUTOSAR model. Furthermore, the API can be used to manipulate AUTOSAR models 

through creating useful complementary tool functions. The API code is automatically 

generated from the AUTOSAR metamodel for each AUTOSAR version (see section 2.2.3). 

The version-specific APIs, although similar in content, are distinctive from each other. The 

reason for this lies in the fact that the APIs originate from different metamodels, which 

represent different AUTOSAR version releases. Figure 3.8 illustrates the generation of API 

code from the version-specific metamodels. 

32

3.2. Artop 

Figure 3.8.: Version-specific generation of AUTOSAR API code from the respective AU- 

TOSAR metamodels. 

This situation requires the tool developer to implement the same tool functionality separately 

for each AUTOSAR version. Consider an example where Artop should offer a function on a 

QueuedReceiverComSpec model element 2 from figure 3.7 that requires reading the value of 

its Queue Length property. The code will look like illustrated in listing 3.1: 

( element autosar21 . swcomponent . communication . 

QueuedReceiverComSpec ) { 

queuedReceiver_21 = ( autosar21 . swcomponent . communication . 

QueuedReceiverComSpec ) element ; 

qrValue = queuedReceiver_21 . getQueueLength (); 

... 

} ( element autosar3x . swcomponent . 

communication . QueuedReceiverComSpec ) { 

queuedReceiver_3x = ( autosar3x . swcomponent . communication . 


qrValue = queuedReceiver_3x . getQueueLength (); 

... 

} ( element autosar40 . swcomponent . 

communication . QueuedReceiverComSpec ) { 

2 The semantics of this element is irrelevant here, but can be found in the appropriate AUTOSAR template. 

33


} 

queuedReceiver_40 = ( autosar40 . swcomponent . communication . 


qrValue = queuedReceiver_40 . getQueueLength (); 

... 

Listing 3.1: Implementing the same functionality for different metamodel versions in an 

Artop-based AUTOSAR tool. 

This approach obviously requires redundant work from the tool developer, while the code 

becomes unclear and is error-prone. Each time a new version of the AUTOSAR standard is 

released, the code will have to be replicated for that version, making the situation even worse. 

Ideally, Artop would provide the tool developer with a possibility to implement functionality 

that involves certain parts of the metamodel only once. This refers to parts of the metamodel 

that have remained unchanged or feature only minor changes across different AUTOSAR 

versions. Furthermore, Artop would provide a way to integrate the existing functionality 

into APIs for new releases. This idea has been dealt with in the GAUTOSAR project, which 

is introduced in the next section. 

3.3. The Generic AUTOSAR concept 

The GAUTOSAR (Generic AUTOSAR) project arose from the idea of not having to write 

repetitive code for each AUTOSAR version API while implementing the same functionality 

on semantically identical model elements (see listing 3.1). The main purpose of GAUTOSAR 

is to relieve the AUTOSAR tool developer of this problem by providing means to implement 

the same functionality only once. This section introduces the GAUTOSAR concept. The 

realization of the concept is presented in detail in chapter 4. 

3.3.1. GAUTOSAR metamodel 

The GAUTOSAR metamodel encompasses model elements that are common to all versionspecific 

AUTOSAR metamodels. A unique API code is generated from the GAUTOSAR 

metamodel. This generic API code can then be referred to from existing AUTOSAR APIs 

and also reused in future AUTOSAR releases, given that the same model element in the 

new release can be represented by the current GAUTOSAR metamodel. Figure 3.9 depicts 

this idea. For model elements that are specific to each metamodel and thus cannot be 

represented in the GAUTOSAR metamodel, the version-specific API can still be used for 

realizing functionality on these elements. 

The GAUTOSAR metamodel is subject to a specific naming convention that makes it easy 

for tool developers to associate the generic model elements with their version-specific counterparts. 

At the same time, it enables a clear distinction between generic and version-specific 

model code. As the name GAUTOSAR implies, the naming convention consists of adding 

a prefix to model element names that is based on the ”keyletter” g. An overview of the 

naming convention for each model element type is given in table A.1 in the appendix. 

34

Figure 3.9.: The principle of Generic AUTOSAR. 

3.3.2. Implementing tool functionality with GAUTOSAR 

3.3. The Generic AUTOSAR concept 

With GAUTOSAR, implementing functionality depicted in listing 3.1 works as follows: for 

each generic class in the model, an appropriate interface is generated as depicted in listing 

3.2: 

gautosar . gswcomponents . gcommunication ; 

GQueuedReceiverComSpec 

{ 

Integer gQueueLength ; 

} 

Integer gGetQueueLength (); 

Listing 3.2: The generic interface representing a QueuedReceiverComSpec object. 

Instead of repeating code that embodies the desired functionality for each AUTOSAR version 

as in listing 3.1, the code can be written only once - by using the generic method provided by 

the generic interface. This way, at the time of implementation, the tool developer does not 

require any knowledge about how many AUTOSAR versions are supported in the current 

Artop release or in which version a tool user might build a model: 

35


... 

qrValue = element . gGetQueueLength (); 

... 

Listing 3.3: The actual implementation of the desired functionality reading the value of the 

queueLength property. 

The functionality in listing 3.3 does not need to be changed as long as its semantics remains 

the same and the GQueuedReceiverComSpec is still an element in the generic metamodel. If 

changes to the function are required, they only need to be incorporated at this site. 

In the background, the classes representing the QueuedReceiverComSpec object in each 

version-specific API all implement the generic GQueuedReceiverComSpec interface from listing 

3.2 and provide the value of its actual queueLength property: 

autosar21 . swcomponent . communication ; 

QueuedReceiverComSpec 

GQueuedReceiverComSpec { 

} 

Integer gGetQueueLength () { 

getQueueLength (); 

} 

Integer getQueueLength () { 

queueLength ; 

} 

Listing 3.4: Integration of the generic interface into a version-specific API (here the 2.1 API). 

3.4. Summary 

This chapter introduced the principles of AUTOSAR, a standardized architecture for modeldriven 

development of automotive control software. Artop was introduced as an infrastructure 

platform for creating tools that enable developing AUTOSAR systems. The issues in 

tool development caused by AUTOSAR metamodel evolution - the need for repetitive implementation 

of equivalent tool functionality for each metamodel version - were explained. 

The idea of using a generic AUTOSAR metamodel to generate version-independent model 

API code that can be used to implement tool functionality only once was introduced as the 

chosen solution. 

36

4. Automation of Generic AUTOSAR 

This chapter elaborates Generic AUTOSAR that was introduced in section 3.3 in detail. In 

particular, it explains the steps that are necessary to realize the GAUTOSAR concept with 

an emphasis on an automated realization process. The chapter is organized as follows: 

• Conceptual realization of GAUTOSAR is explained first in section 4.1 by introducing 

the necessary phases for the realization process. This is followed by an 

elaboration of the manual and the automatic realization approach. The motivation 

behind the automatic approach serves as an introduction to the remaining two parts 

of the chapter. 

• Analysis of the AUTOSAR metamodel comparison process and the resulting 

difference model. A concept for the implementation of step one of the GAU- 

TOSAR realization process presented in section 4.1.1 has been contributed in preceding 

work. The analysis of this work is presented in section 4.2, including solutions for 

known limitations and necessary improvements that were contributed in this thesis. 

• Presentation of a concept for automated creation of the generic metamodel. 

A concept for the implementation of step two of the GAUTOSAR realization process 

presented in section 4.1.1 is the main subject of this thesis. The developed concept 

and the prototype that implements the concept are presented in section 4.3. 

4.1. Realization of GAUTOSAR 

The GAUTOSAR realization process has already emerged in the course of Artop development 

prior to this thesis. However, it is still subject to research and has not been formalized 

yet. In [Kni11], a preceding thesis at BMW Car IT, a three-step process is proposed: metamodel 

comparison, manual refinement of comparison results and finally generation of target 

entities, such as API code or further models. These steps were established with an emphasis 

on metamodel comparison and presentation of comparison results. 

4.1.1. Process steps for realizing GAUTOSAR 

The process for the creation of the version-independent GAUTOSAR API will follow similar 

principles as for the version-specific AUTOSAR APIs. This involves automatic code generation 

from a metamodel. The generic metamodel that will be used for code generation 

should encompass all elements that are common to version-specific metamodels supported 

in a single Artop release. Thus, a refined sequence for the realization of GAUTOSAR that 

considers both metamodel comparison and creation of the generic metamodel is proposed. 

This process is illustrated in figure 4.1. The sequence for the realization process is organized 

in a way such that each step contributes a framework that helps realize the respective 

subsequent step: 

37


1. Comparison of existing AUTOSAR metamodels and presentation of the 

results in an appropriate format. This step requires developing an algorithm to 

compare an arbitrary number of AUTOSAR metamodels and creating a format to 

present comparison results in a way that makes the second step feasible. 

2. Exploration of comparison information and creation of the generic metamodel. 

Exploit the results of model comparison from the first step to determine differences 

and similarities between compared metamodels - and utilize external knowledge 

if required - in order to create a generic metamodel with the desired structure. The 

generic metamodel should be self-contained in the sense that it should not contain any 

references to other metamodels (in particular version-specific AUTOSAR metamodels) 

or their elements. The generic metamodel should also reflect requirements on the 

generic API. 

3. Generation of the generic API code and linking into version-specific APIs. 

Use the generic metamodel to automatically generate Java interfaces and link them to 

corresponding Java classes in version-specific APIs that provide functionality specified 

in the interfaces. 

Figure 4.1.: Illustration of the steps necessary to realize GAUTOSAR with their respective 

resulting entities. 

38

4.1. Realization of GAUTOSAR 

Originally the first two of the described GAUTOSAR realization steps have only been conducted 

manually. These steps require a domain expert to simultaneously browse and compare 

the structure of multiple AUTOSAR metamodels and determine changes among them (step 

one), then build a generic metamodel (step two) based on its desired properties (which will 

be reflected in the API) and the types of changes that occurred. 

The advantage of the approach where the first two steps are conducted manually is that 

a human domain expert can instantly recognize change and its influence on the surrounding. 

This is due to a human’s ability to implicitly understand context [WSA02]. Furthermore, a 

human expert has an understanding of the semantics behind the data structure - in this case 

the principles governing model-based and object-oriented software development. An algorithm 

can essentially only base its decisions on the syntax of a data structure, which makes 

its understanding of context limited. Therefore, creating a generic metamodel is a relatively 

easy task for a human expert. The disadvantage of the manual approach is that the current 

AUTOSAR metamodels contain between 600 and 900 classes, which makes manual analysis 

an extremely complicated and time-consuming task. Moreover, each time a new AUTOSAR 

metamodel becomes available and also becomes supported in an Artop release, the process 

has to be repeated with consideration of all metamodels that are supported in the particular 

Artop release. This includes some or all of the previously supported metamodels and the 

new metamodel. However, a fully automated process might not produce results as good as 

the manual process due to the semantic gap in algorithmic data processing. The ideal approach 

will combine fast automated processing with the contextual knowledge of the human 

expert. This semi-automatic approach combines the advantages of both man and machine 

while excluding the disadvantages on both sides to the furthest possible extent. 

4.1.2. Automation of the GAUTOSAR realization process 

The first step of the GAUTOSAR realization process - comparison of version-specific AU- 

TOSAR metamodels - was automated in the DiffMap project - a preceding thesis at BMW 

Car IT. The results of the DiffMap project including improvements that were contributed 

in this thesis are presented in section 4.2. Automation of the second step - creation of the 

GAUTOSAR metamodel - is the subject of this thesis and is presented in section 4.3. 

The quality of the metamodel comparison result directly influences the quality of the created 

generic metamodel. The extent of the generic metamodel then determines the usability 

extent of the generic API. As explained in the previous section, automatic comparison cannot 

detect all types of changes that can occur between version-specific metamodels due to 

a semantic gap. Similarly, some types of changes cannot be automatically resolved by the 

engine that uses comparison information to create the generic metamodel (see section 2.3.2). 

In order to resolve such issues nevertheless and improve the quality of the generic API, the 

comparison result and the generic metamodel should include a possibility for manual intervention 

by a domain expert. The comparison result and the generic metamodel are both 

Ecore models (see section 2.2.1) that can be manipulated by hand in Eclipse. 

The third step is already automated. It involves using an EMF generator that has been 

customized for Artop with special JET templates (see section 2.2.3) to generate the desired 

result. The generator processes the GAUTOSAR metamodel that is enriched with 

39


annotations which contain GAUTOSAR-specific generation instructions. It generates the 

GAUTOSAR API and implementations of the generic interfaces in the version-specific APIs. 

For the purpose of automation efforts conducted in this thesis, it is assumed that the results 

of each processing step in section 4.1.1 have been manually verified and corrected by a human 

domain expert before they are used as input for the subsequent processing step. 

4.2. Analysis of the automated metamodel comparison process 

The DiffMap model is a difference model that collects all the information about similarities, 

changes and version history of the compared metamodels [Kni11]. The collected information 

supports the creation of a generic AUTOSAR metamodel (see section 4.1.1) and is readable 

by both a domain expert and a computer program. DiffMap builds upon the EMF Compare 

framework (see section 2.2.4) by extending the provided algorithms to enable the comparison 

of more than two models (see section 4.2.2) and by extending the provided metamodel 

to define the comparison results in a historical context (see section 4.2.1). Presenting the 

results in this fashion implies reading and editing the model by a domain expert in order to 

gain knowledge about changes between different model versions and generic model elements. 

The quality of this information can be enhanced through manual completion of the model 

based on a domain expert’s knowledge. 

Sections 4.2.1 and 4.2.2 describe the DiffMap project in the stage as it was found before 

this thesis was commenced. During development, certain aspects of DiffMap with a crucial 

impact on this work had to be improved upon. Limitations in the structure of the resulting 

difference model and the solution contributed in this thesis are given in section 4.2.3. An 

improvement of the solution for a better comparison performance is described in section 

4.2.4. 

4.2.1. DiffMap metamodel 

The DiffMap metamodel places itself within the EMF Compare Diff metamodel (see [emfb]) 

and provides additional classes necessary to capture comparison results and make them 

available in a historical context. The DiffMap metamodel is shown in figure 4.2. Elements 

of the metamodel that are relevant for this thesis are explained in more detail below. 

The class is the central element in the DiffMap metamodel. It extends 

EMF Compare’s DiffGroup and contains a reference to an AUTOSAR model element. The 

comparison information for this model element is contained in a list of HistoryElements. 

The features versionOccurrence and continuousVersionOccurrence are computed from 

the contained versionHistory and state in how many model versions a model element 

occurred or respectively in how many model versions the element occurred unchanged. The 

state feature supports the domain expert in keeping track of the current state of the manual 

processing of model elements. The class contains information resulting 

from a (single) comparison that a model element took part in. Accordingly, the total number 

of historyElements in a model element is equivalent to the total number of comparisons 

(see section 4.2.2 for details on how models are compared) the element took part in. The 

from and to references point at the version information of the compared model pair, where 

40


Figure 4.2.: The DiffMap metamodel (purple) in the context of EMF Compare’s Diff metamodel 

(yellow) (image adopted from [Kni11]). 

41


from refers to the older model and to refers to the newer model. Each HistoryElement 

states that either no change occurred in a model element between these two versions or 

lists the changes that occurred. Changes can be found in the operations reference, which 

contains a list of diff operations - such as renaming, relocation etc. - that were identified on 

this element during the comparison process. The historyState feature shows directly if a 

model element has suffered any changes (broken) or has remained unchanged (continuous) 

during the comparison. 

4.2.2. Model comparison in DiffMap 

During the preprocessing step, metamodel elements that carry information which is only 

relevant for AUTOSAR metamodel developers is removed. Additionally, package restructuring 

is performed (see section 4.2.4). 

The matching step uses the generic matching algorithm provided by EMF Compare (see 

section 2.2.4) and performs a two-way comparison of each model pair. The model pairs are 

grouped by age (first version with second version, second version with third version etc.). 

The generic matching algorithm performs breadth-first search (BFS) simultaneously on the 

two models. For each model element in the older model, the algorithm tries to find a matching 

element at the same height in the newer model. If no match is found, the children of the 

element in the older model are stored in a separate list, while the children of visited elements 

in the newer model are ignored. The visited elements in the newer model are stored in an 

equivalent separate list. After BFS has completed, elements contained in the separate lists 

are attempted to be matched outside the search tree. A match model is created as the result 

of the matching process. 

The differentiation step utilizes the match model to figure out the exact type of change 

that occurred and then models this change as a diff operation (see 4.2.1) in the DiffMap 

model. The initial DiffMap model is created from the match model of the first model pair. 

Each element in the DiffMap model is modeled in a DiffMapGroup with its history information 

set accordingly (see 4.2.1). In order to facilitate comparison of more than two models, 

the EMF Compare diff engine is extended at this point to use the previously constructed 

DiffMap model and the next match model as input, which produces an extended DiffMap 

model. During this process, for each element in the match model the corresponding element 

in the DiffMap model is searched for. If found, the existing DiffMapGroup’s history information 

for that element is updated with difference information calculated from the current 

match model. If no element already incorporated into the DiffMap model can be associated 

with the element in the current match model, a new DiffMapGroup is created for the element 

found in the current match model. 

4.2.3. Distributed comparison history 

The analysis of DiffMap showed that when more than two metamodels were compared, the 

resulting DiffMap model contained a separate difference subtree for each pairwise comparison 

of AUTOSAR metamodels (see figure 4.3). Such behavior represented a limitation in 

recognizing generic metamodel elements required for the concept developed in this thesis. 

This section describes the problem and the contributed solution in detail. 

42


Figure 4.3.: The resulting DiffMap model structure when comparing three AUTOSAR metamodel 

versions. 

A metamodel element was modeled in DiffMap as many times as it participated in a pairwise 

comparison, with each occurrence containing exactly one history element. Due to this limitation, 

an element’s complete history could not be accessed from one location. The histories 

were distributed across the difference subtrees. The version occurrence attributes would not 

state the real number of occurrences in all compared metamodels. A domain expert could 

not make statements about the appearance of a metamodel element and its changes in a 

straightforward manner. This heavily impeded DiffMap’s usefulness for manual examination. 

A computer program that uses DiffMap to create a generic metamodel would have to 

search all subsequent difference subtrees for further occurrences of an element it found in the 

first subtree. The program would have to store version and change information, aggregate 

it and then decide if this element can be represented in the generic metamodel. Essentially, 

the program would have to match model elements across different subtrees, even though this 

matching was already done during comparison in DiffMap. 

The source of this issue was located in EMF Compare’s algorithm which creates difference 

groups and allocates compared elements to groups during the differentiation phase (see 

section 4.2.2). During the extension of the DiffMap model with information from the second 

43


and later comparisons, this algorithm tries to determine if a group for the element in the 

match model exists in two ways. It first takes the already grouped model element - which 

is a reference to an element in the first metamodel. It then compares this element with 

the older element of the matched elements pair contained in the second match model. The 

algorithm uses reference equality to compare the elements. However, because semantically 

identical elements from different metamodels have distinct memory addresses, comparing by 

reference always fails. In the second attempt the algorithm tries to fetch the grouped element’s 

corresponding matched element and compare it to the element in the second match 

model (again by reference). However, at that time only the second match model, which 

contains matching pairs from the second and the third metamodel, is available to the algorithm. 

The first match model, which contains matching pairs from the first and the second 

metamodel, is not available because EMF Compare was conceived for comparing only two 

metamodels, thus requiring only one match model when grouping elements. The attempt 

to find the grouped element’s matched counterpart thus results in null and the comparison 

to the element in the second match model fails again. After both attempts to allocate 

the element from the second or later match models to an existing group have failed, a new 

group is created, even though the correct group for that element exists in the DiffMap model. 

The solution is to enable the algorithm to successfully match elements from metamodels 

that were not compared directly. In order to achieve this, the algorithm is provided with 

all match models that were created during the matching phase. Except the oldest and the 

newest metamodel, each metamodel in between participates in two comparisons: first as 

the newer model and in the subsequent comparison as the older model. This situation is 

made use of to link pairs of match models through their common metamodel, thus creating 

a matching chain between semantically identical model elements in all metamodels. This 

approach is illustrated in figure 4.4. 

Figure 4.4.: Illustration of the matching chain solution. An element from model 1 can be 

matched to an element in model 3, even though model 1 and model 3 were not 

compared directly. 

The DiffMap model now contains only one difference tree where the complete comparison 

history for each element is available within one difference group (as depicted in figure 4.5). 

4.2.4. Leaking occurrence information 

In early stages of prototype development, it was noticed that a number of elementary classes 

were not incorporated into the generic metamodel even though they did fulfill the requirements 

for generic elements. These affected classes are at the top of the AUTOSAR class 

hierarchy and serve as superclasses for a vast number of specialized classes. This behavior 

represented a limitation in the ability of the prototype developed in this thesis to produce 

correct results. This section describes the problem and the contributed solution in detail. 

44


Figure 4.5.: The improved structure of the DiffMap model with three compared metamodels. 

The problem was caused by the radical restructuring of packages that contain the affected 

classes in metamodel version 4.0 (see figure 4.6) and the way EMF Compare’s matching 

algorithm operates (see section 4.2.2). Because the algorithm ignores the contents of new 

packages in metamodel version 4.0, the classes contained in these packages were not available 

for matching with their counterparts in metamodel version 3.x. Therefore, the DiffMap 

model incorrectly presented these classes as existing in only two of the three compared 

metamodel versions (depicted in figure 4.7). 

This issue was recognized in [Kni11] and the implemented solution inserts any packages 

(without their contents) that are new in the new model into the old model. This way the 

matching algorithm is able to store classes in new packages in the separate list and then 

match them with their corresponding classes in the older model’s separate list. The algorithm 

for identifying new packages was using the NsPrefix package property when comparing 

packages from both metamodels. This property is used to define the namespace prefix for 

the XML namespace of the root element [SBPM09]. However, this property is empty in all 

AUTOSAR metamodels used in this work. Therefore, no packages could be identified as 

new, which caused the solution to have no effect when a comparison was run. 

In order to make this solution effective, the algorithm was modified to identify new packages 

correctly. The crucial part of the algorithm is to identify equivalent packages that exist in 

both models and thereby filter out packages that are new. Using the package Name property 

is insufficient, as there is no guarantee that package names are unique in each AUTOSAR 

metamodel (this is especially true for words describing objects that are common in each part 

45


Figure 4.6.: Highlighted classes in metamodel version 3.x are reorganized and distributed 

among newly created subpackages in metamodel version 4.0. 

46


Figure 4.7.: The result of comparing metamodel versions 2.1, 3.x and 4.0. According to the 

comparison history of selected classes, they only exist in two metamodel versions 

- 2.1 and 3.x. 

47


of the metamodel, such as infrastructure, common, component etc.). Furthermore, packages 

at different locations in the hierarchy would be identified as equivalent, too. A different 

location though is usually a strong indication for different semantics of such packages. The 

NsURI property reflects the location of a package in the hierarchy in a fashion similar to the 

URI of a file on a web server. However, the value of the NsURI property does not depend on 

that package alone, but also on its sibling packages (see section 4.3.3 for details on how the 

NsURI property is computed). By using only the NsURI property, equivalent packages might 

not be recognized as existing in both models. Therefore, a combination of both Name and 

NsURI property is used to identify packages that exist in both models. If both properties 

match, the packages are labeled as equivalent. If only the Name property matches, the parent 

packages are checked for being equivalent and if so, the original packages are considered 

equivalent, too. 

The package insertion solution implemented in [Kni11] works as long as the older metamodel 

is a subset of the newer metamodel. If the older metamodel contains packages that do not 

exist in the newer metamodel (such as in figure A.1 in the appendix), the package is considered 

deleted in the difference model, while the classes it contains cannot be matched to 

their counterparts in the newer metamodel. The classes in the newer metamodel, as long as 

they are located in packages that were matched, are then considered added in that version 

(illustrated in figure A.2 in the appendix). To avoid this, the solution was extended to also 

insert packages that only exist in the older metamodel into the newer metamodel (the result 

is depicted in figure A.3 in the appendix). Furthermore, to make the DiffMap model better 

readable, package insertions are performed for each combination of metamodel versions. 

Since all metamodels now have the same package structure (in terms of parent relationships, 

the order of the siblings is irrelevant), no information about package structure change is 

available in the DiffMap model. This might be inconvenient for a domain expert who is 

using the DiffMap model to find out how the AUTOSAR metamodels evolved. However, 

creating the generic metamodel remains unaffected (see package elements in section 4.3.1). 

The described improvements of the package identification and the package insertion algorithms 

fulfilled the requirements that were necessary to continue the development of the 

prototype contributed in this thesis. A solution that tackles the described problem at its 

core is proposed in section 6.2.2. 

48


Figure 4.8.: The result of comparing metamodel versions 2.1, 3.x and 4.0 when the package 

insertion solution is applied. The comparison histories of selected classes now 

correctly describe the classes as present in all compared metamodels. 

49


4.3. Automated creation of the generic metamodel 

The concept presented in this section enables the automated creation of a common, versionindependent 

metamodel. It relies on metamodel difference information provided by the 

DiffMap model (described in section 4.2). The concept is applied to AUTOSAR metamodels 

and showcased through the GAUTOSAR creation engine prototype (see section 4.3.4). 

However, the presented concept can be likewise applied to arbitrary metamodels with a few 

customizations. The process of automated creation of the GAUTOSAR metamodel consists 

of the following phases (depicted in figure 4.9): 

• Construction is the critical phase of the process. In this phase the difference model 

is explored, change information is retrieved and decisions are made on if and how to 

incorporate each model element into the generic metamodel. The construction phase 

is described in detail in section 4.3.1. 

• Decoupling ensures that the generic metamodel constructed in the previous phase is 

self-contained. The decoupling phase is described in detail in section 4.3.2. 

• Gification renames the elements in the generic metamodel after the GAUTOSAR 

naming convention, but can be customized for other domains. The gification phase is 

described in detail in section 4.3.3. 

Figure 4.9.: Illustration of the automated process for creating the GAUTOSAR metamodel. 

50

4.3.1. Construction phase 


The construction phase requires the DiffMap model as input at runtime. Then, the DiffMap 

model is explored in a top-down manner and the generic metamodel is constructed simultaneously, 

based on information contained in DiffMap. In order to construct the generic 

metamodel automatically, some essential questions need to be answered. These questions 

apply to each model element that is represented in the difference model. The answers to these 

questions will then lead to a model element being incorporated into the generic metamodel 

or being dismissed. The questions are as follows: 

• What are generic model elements? This question is fundamental for the generic 

metamodel. The answer implies a decision that is based on two factors. The first factor 

is the occurrence frequency of model elements. This requires a decision if elements 

that are present in all or in a majority of compared metamodels are to be considered 

generic. The second factor is the amount of change that a model element has been 

subject to across different metamodel versions. This requires a decision about to which 

degree changed elements can still be considered generic and implies the next presented 

question. 

• What kind of change is detected in the difference model? The generic metamodel 

should contain model elements that have slightly changed. Therefore, change 

information must be available to the creation engine. The incorporation of such model 

elements implicates an answer to the next presented question. 

• How do changes affect the generic API? Different types of change require different 

handling in the generic API and an appropriate implementation strategy in the versionspecific 

APIs. Depending on the type of change and its effects, the implementations 

can be more or less complex. This question is tightly related to the next presented 

question. 

• How to represent change in the generic metamodel? This should be done in 

a way that makes it easy for the generator to recognize change and to generate code 

that reflects the chosen implementation strategy mentioned above. 

The DiffMap model carries occurrence and change information and thereby provides answers 

to the first two questions. However, it is not concerned with the effects of changes on the 

generic API or the representation of change in the generic metamodel. Therefore, external 

knowledge gained from the experience with the GAUTOSAR API that was generated from 

the manually created metamodel is used to answer the last two questions. This knowledge 

is required at development time and is thus implicitly included in the program code of the 

GAUTOSAR creation prototype. Examples of such external knowledge include choosing 

a specific, best-practice solution for reacting to change when dealing with complex change 

types (such as attribute type change), where a number of solutions are possible. Another example 

is the chosen format of information contained in annotations that enable the generator 

to recognize and react to change when producing code that represents generic metamodel 

elements. 

In the remaining part of this section, the presented questions are answered for different 

model element types and the resulting strategies for incorporating these model elements into 

the generic metamodel are elaborated. 

51


Package elements 

Package elements serve the purpose of structuring metamodel contents and do not have any 

semantics of their own. As no functional API code is generated from package elements (but 

rather folders which provide structure for files containing functional code), the occurrence of 

package elements across different metamodel versions has no effect on the functionality of the 

generic API. Therefore, the question of being generic is irrelevant for package elements. All 

package elements are incorporated into the generic metamodel, regardless of their contents. 

The contents are not inspected when processing a package element as they will be processed 

subsequently anyway. After the construction of the generic metamodel has completed, empty 

packages are deleted. 

Changes such as renaming of a package and relocation of a package also do not have 

an effect on the generic API code. Modeling package elements with the old or new name or 

at the old or new location in the generic metamodel is a matter of convenience. However, 

due to modifications of the DiffMap model explained in section 4.2.4, all compared metamodels 

have the same package structure and no package changes can be identified. As the 

DiffMap model is the only explicit input for the engine creating the generic metamodel, the 

generic metamodel adopts the package structure of the DiffMap model. The DiffMap model 

structure is based on the package structure of the oldest AUTOSAR metamodel [Kni11], 

with certain packages from the remaining metamodels additionally inserted because of the 

previously mentioned modification of the model. Adopting the DiffMap structure enables 

a domain expert to easily associate the information contained in the DiffMap model with 

information contained in the GAUTOSAR metamodel and vice versa. 

Class elements 

Classes are the essential elements of a model as they carry type information and denote 

the model semantics. The usefulness of the generic API heavily depends on the number of 

classes that are represented in the generic metamodel. 

A class element is considered generic if it occurs in all compared metamodels. If such a 

class is unchanged across all metamodels, it has no special effects on the generic API and 

does not require special attention for incorporating it into the generic metamodel. Therefore, 

unchanged classes are incorporated immediately and without any further actions to support 

their generic representation. The effects on the generic API and the incorporation strategy 

for generic classes that have been subject to change are discussed below. 

Relocation of a class from one package to another means a structural change that has no 

influence on class semantics. Since the GAUTOSAR API generator uses class names to map 

generic classes to their corresponding version-specific classes, the package where a generic 

class is located is irrelevant. Therefore, class relocation has no effect on the GAUTOSAR 

API. Relocated classes are incorporated into the generic metamodel at their original position 

- as in the oldest model, which is where they are modeled in DiffMap). Because the DiffMap 

model only states the name of the package to which a class has been relocated, but not its 

exact position in the model, it is easier for a domain expert to find a class from the difference 

model at that same position in the generic metamodel. 

52


Class renaming is a frequently occurring change. Renaming causes some classes in the 

version-specific APIs to have a different name than the generic interface they implement. 

Other than that, renaming has no functional effects. Name change can be represented in the 

generic metamodel by adding an annotation to the affected class. The annotation contains 

a mapping from AUTOSAR versions to names used in these versions if they vary from the 

name of the representing class in the generic metamodel. The generator looks for such annotations 

in classes in the generic metamodel and links the generic and the version-specific 

classes accordingly. The DiffMap model presents the class with its original name (as in the 

oldest metamodel), while the new name (or a multitude of new names in case the class has 

been renamed more than once) is contained in the change histories. Choosing the original 

name for the generic class makes it easier to pinpoint that class in DiffMap. However, that 

name might become obsolete as new AUTOSAR versions are released and thus unfamiliar 

to developers who are new to AUTOSAR. Because developing GAUTOSAR requires associating 

the DiffMap model with the GAUTOSAR metamodel frequently, the original name 

is chosen as the generic name. 

Superclass reference change affects the semantics of a class as superclasses determine 

the extent of information that a class contains. The DiffMap model can only detect the 

addition or the removal of a superclass reference. If a superclass reference is added at some 

point in history, it means that the information it adds has not been present in the class 

throughout the history and is thus not generic. If an original superclass reference is removed 

later on, the information contained in that superclass becomes non-generic, too. Therefore, 

superclass references in a class are considered generic only if they occur across all compared 

metamodels. 

Attributes and references 

Attributes and references define the properties of a class and hence determine the class semantics. 

A wide usability of a class in the generic API depends on the number of attributes 

and references that the class offers. 

Attributes and references are considered generic if they are features of a class that has 

already been incorporated into the generic metamodel and if they are present in all occurrences 

of the generic class. Just as with unchanged classes, attributes and references that 

have remained unchanged across all metamodels are incorporated into the generic metamodel 

immediately. Attributes and references contain an extensive list of properties that 

enable to fine-tune the semantics of the class they are contained in. A change in each of 

these properties has a certain effect on the generic API. However, only a selection of these 

properties and their changes is elaborated below. 

Renaming of attributes and references has a similar effect on the generic API as 

renaming of classes. It means that attributes, references and their accessor and mutator 

methods in some of the version-specific classes have a different name than their counterparts 

in the generic interface. Again, renaming is supported by adding annotations which map 

versions to names to the attribute or reference element in the generic metamodel. As for 

classes, the original name (from the oldest model) is chosen for the generic element. 

53


Type change has a major effect on the generic API. It causes the accessor methods to 

have different return types and for the mutator methods to have different argument types 

in the version-specific APIs and also compared to the generic API. One solution is to generate 

one accessor and mutator method set per type. The version-specific classes can then 

implement the business logic in methods that correspond to the type that the attribute or 

reference has in that version and throw an appropriate exception in implementations of all 

other methods. However, the tool developer would then have to implement functionality per 

type instead of per version. Even though the implementation effort is reduced, a need for 

repetitive implementation remains. Another solution is to use a unique type for the generic 

feature, which can be converted to the type found in the version-specific implementations. 

This solution is feasible for features of primitive types. Object types however cannot be 

easily converted. In such cases, a detailed analysis of the particular use case should be conducted 

in order to find out the appropriate solution. For both the multiple and single type 

solutions, annotations that map versions to types can be used to inform the generator about 

type change in a similar way as it is done for name change. 

Reference multiplicity change can imply a type change if it changes from single to 

multiple (or the other way around). The generic reference can be represented as a collection 

type, since a collection can carry both single and multiple elements. This way, it is possible 

to use only one reference in the generic API (rather than splitting them in single-type 

and multiple-type references). The number of possible elements in the collection can be 

restricted by the highest occurring multiplicity among the supported metamodel versions. 

In reading operations, the version-specific implementations can only use the collection range 

that is specified in that version and ignore the rest. Similarly, in writing operations the 

required range can be filled with user data, while the remaining range can be manually or 

automatically filled with blank values. Exceptions can be thrown if a user tries to enter data 

which are beyond the version-specific range. 

4.3.2. Decoupling phase 

The purpose of decoupling is to enforce the self-containment requirement of the generic 

metamodel (see step two in section 4.1.1). Because the DiffMap model is processed topdown 

to construct the generic metamodel, it is possible that classes that are referenced as 

supertypes and as return types of attributes and references have not been processed yet. 

Therefore, these are left pointing at classes in the version-specific metamodels until the 

DiffMap model has been processed completely and the generic metamodel has been fully 

constructed. Then, during the decoupling phase, the constructed generic metamodel is run 

through and references to version-specific classes are changed to point at the corresponding 

classes in the generic metamodel (figure 4.10 illustrates this). 

Under the assumption that only superclass references present across all compared metamodels 

and attributes and references whose type has not changed across all compared metamodels 

are considered for incorporation into the generic metamodel, these referenced types are guaranteed 

to be found again in the generic metamodel. Otherwise, a deletion of the supertype 

reference, attribute or reference from the affected class in the generic metamodel is necessary 

in order to avoid references to non-generic types. 

54


Figure 4.10.: Illustration of references in superclasses, attributes and references before and 

after the decoupling phase. 

4.3.3. Gification phase 

Gification is the procedure of renaming elements in the generic metamodel and setting up 

related name properties in accordance with the GAUTOSAR naming convention (see section 

3.3). The gification phase is thus specific to GAUTOSAR. However, the application of a 

special naming convention for generic metamodel elements is conceivable in other domains 

as well. 

The gification phase consists of two tasks which are described below. The results of the 

gification process are depicted in figure 4.11. 

The first task is concerned with setting the NsURI property of each package. EMF requires 

each package element to have a unique NsURI. Therefore, the NsURI properties of packages 

in AUTOSAR metamodels reflect the position of the respective package in the metamodel 

hierarchy. The NsURI properties of packages in the GAUTOSAR metamodel should follow 

the same principles. The NsURI of a package does not depend only on the name and the 

position of that package in the metamodel, but also on the sibling packages. The NsURI 

extension of a single package is derived from the first characters of words that make up the 

package name (figure 4.11 illustrates this). Thus, if the names of two sibling packages are 

composed of a single word starting with the same character, a different NsURI has to be 

assigned to one of them (i.e. by using the whole word or the first two characters). This 

convention does not apply to the NsURI of the root package - the full name of the root is 

used instead. 

The GAUTOSAR metamodel does not necessarily have the same package structure as the 

DiffMap model (see section 4.3.1). To ensure that the GAUTOSAR metamodel follows the 

same principles for NsURI properties as the AUTOSAR metamodels, the NsURI property has 

55


Figure 4.11.: An excerpt from the created GAUTOSAR metamodel showcasing the used 

naming conventions. The NsURI extension of the gautosar package in the 

infrastructure package is shortened to the letter a and appended to extensions 

of its predecessor packages. 

to be calculated anew for each package element. Existing tools from Artop were used for to 

accomplish this and modified where necessary. 

The second task is concerned with changing the name properties of packages, classes, attributes 

and references according to the convention displayed in table A.1. 

4.3.4. Prototype implementation 

The developed prototype that implements the concept presented in previous sections is 

essentially a model transformation engine. However, unlike a transformation engine that 

typically uses a difference model to migrate a model (that complies with an older version of 

its respective metamodel) to a newer version (that complies with the evolved metamodel), 

this prototype uses difference information to identify metamodel elements that can be represented 

by a generic metamodel and uses representations of such elements as building blocks 

for the generic metamodel. 

As noticed in section 4.1.2, the prototype assumes that the difference model it uses as 

input has been verified for correctness by a human domain expert. Likewise, it is assumed 

56


that the resulting generic metamodel will be verified by a domain expert before it is used as 

input for the generic API generator. 

The architecture of the prototype (see figure 4.12) consists of two functional layers that implement 

the concept phases presented in section 4.3. The lower layer features the GEngine 

and the AutosarVersionMap. The GEngine component is the core of the prototype: it implements 

the construction and the decoupling phase. During the construction phase, the 

GEngine makes use of the AutosarVersionMap, a convenience component that enables easy 

mapping of short and long forms of the AUTOSAR version number specifications. The implementation 

of the construction phase is described in detail later in this section. The upper 

layer features the Gifier component, which provides all mechanisms that are necessary to 

implement the gification phase. Implementing the gification phase in a separate component 

and locating this component in a layer above the GEngine enables easy customization - the 

Gifier can be replaced by a component that implements a metamodel naming convention 

for domains other than AUTOSAR. 

The UML diagram of software components described in this section is given in figure A.4 in 

the appendix. 

Figure 4.12.: Two-layered architecture of the GAUTOSAR creation engine prototype. 

A GEngine object requires the DiffMap model and the number of compared metamodels as 

input. The DiffMap model is processed top-down and depending on the model element type 

that is found within each difference group (DiffMapGroup object), the respective processing 

methods for these element types are invoked. These processing methods implement the 

strategies that were discussed in the earlier sections of this chapter. 

Package elements are processed without regard to their comparison history. A deep 

copy of the package element is created and stripped off its contents. This newly created 

package element then serves as the element that will be incorporated into the generic 

metamodel. Using a new element as the representative in the generic metamodel rather 

than just referencing an existing element in a version-specific metamodel contributes to the 

57


self-containment requirement of the generic metamodel. The difference group that contains 

the package element is stored with a link to the generic element representative in the 

diffMapModel2genericModelMap data structure. This data structure makes it possible to 

locate the parent element in the generic metamodel of a model element being processed via 

its parent difference group in the DiffMap model. The root of the compared metamodels is 

a package element (see section 2.2.1) and can be identified as the sole model element without 

a further parent element. If such a package element is identified, it is anchored to the 

genericModel object, thus becoming the root of the generic metamodel. If it is not the root 

element, the diffMapModel2genericModelMap data structure is used to retrieve the package 

element from the generic metamodel that should be used as the parent package. The generic 

representative of the processed package element is then attached under the found generic 

parent package. 

Class elements are processed only if their difference group contains the maximum number 

of history elements, meaning that the class is present in all compared metamodels. Generic 

representatives of class elements are created and the parent package in the generic metamodel 

is discovered the same way as for package elements. Additionally, the original class element 

is stored with a link to its generic counterpart in the originalClass2genericClassMap. 

This data structure is required for the decoupling phase. Then the history elements are 

explored to detect name and supertype changes. An algorithm was developed that facilitates 

the creation of a naming annotation for any number of name changes that might have 

occurred throughout the history. The created annotation is then attached to the generic 

representative of the class element. The metamodel version information that can be obtained 

in DiffMap has the long format, while the generator requires the short version format 

when processing naming annotations. Therefore, the AutosarVersionMap is used to obtain 

the corresponding short version. If a supertype reference that was present in the initial 

metamodel and has been removed later on is detected, an algorithm is used that deletes this 

supertype reference from a list of the originally present supertypes. This list is added to 

the generic representative of the class. Since the classes in this list are still version-specific 

classes, the supertype references are changed to point at corresponding classes in the generic 

metamodel during the decoupling phase. 

Attributes and references are processed only if their parent class has been incorporated 

into the generic metamodel and if within this class they are present in all compared 

metamodels. Again, a copy that serves as the generic representative is created and the parent 

class in the generic metamodel is located. If the element is unchanged, it is incorporated 

into the generic metamodel as a feature of the located generic class immediately. Otherwise, 

the history is explored to detect name changes. The same algorithm as for classes was used 

to create appropriate name annotations. If any other changes were detected, the prototype 

currently dismisses this element from incorporation into the generic metamodel. Return 

types that are still pointing at version-specific classes are changed to point at corresponding 

classes in the generic metamodel during the decoupling phase. 

58

4.4. Summary 

4.4. Summary 

This chapter elaborated the efforts that were taken to automatically realize the concept 

of GAUTOSAR. The first part of the chapter introduced the necessary steps for realizing 

the process that leads from comparing evolutionary different metamodel versions and 

creating a generic metamodel to producing generic model API code. The advantages and 

disadvantages of the manual approach were evaluated and the choice of the automatic approach 

was explained. The second part of the chapter was concerned with an analysis of 

a metamodel comparison process and the resulting difference model that were conceived in 

a preceding thesis. The difference model was improved to present the results in a format 

that enables automatic identification of equivalent metamodel elements across different compared 

metamodels. The difference model was also improved to achieve a higher accuracy 

when identifying such elements during the comparison process. The third part of the chapter 

elaborated the main contribution of this thesis - a concept for automated creation of a 

generic metamodel based on comparison information in the aforementioned difference model. 

The concept analyzes the types of change that can occur in different types of metamodel 

elements, their impact on the generic and the version-specific model APIs and the possibilities 

of representing such change in the generic metamodel. Based on this information and 

on the frequency of occurrence of elements in compared metamodels, a decision is made on 

incorporation of the element into the generic metamodel. A model transformation prototype 

was developed that implements this concept. The prototype uses the difference model as 

input and produces a generic metamodel as output. 

59


60

5. Results 

This chapter presents the results of development efforts that were conducted in this thesis. 

These include the generic metamodel produced by the prototype that implements the 

developed automation process and conceptual limitations that were encountered during the 

course of development. An evaluation of these results concludes this chapter. 

5.1. Generic AUTOSAR metamodel 

The prototype developed within this thesis implements the automation process for creating 

the generic metamodel that was presented in section 4.3. A DiffMap model containing the 

results of comparing AUTOSAR metamodel versions 2.1, 3.x and 4.0 served as input for the 

prototype throughout the development process. The prototype assumed that the correctness 

of results in its input had been verified manually by a domain expert prior to further 

processing. 

The GAUTOSAR metamodel produced by the prototype contains about 250 classes. The 

version-specific AUTOSAR metamodels that were used as input for comparison contain between 

600 and 900 classes. Excerpts from the resulting GAUTOSAR metamodel created 

by the prototype are presented in figure 5.1. The figure shows the results of the construction 

phase and the annotations that were used to support renamed classes and attributes. 

Furthermore, results of the decoupling phase can be seen in superclasses and references. 

The specific names of metamodel elements are the result of the gification phase. Only selected 

metamodel elements in the presented results have been verified manually. However, 

as noticed in section 4.1.2, the results should be verified completely and manually adapted 

if necessary prior to using the created metamodel to generate the GAUTOSAR API code. 

5.1.1. Observed issues in the generic metamodel 

The automatically created GAUTOSAR metamodel was found to still contain references to 

classes in version-specific metamodels. These can be seen in some attribute and reference 

elements contained in the GIdentifiable class and in the GCompositionType class in figure 

5.1. The cause of this inconsistency was found in the input DiffMap model. The DiffMap 

model did not recognize that the original type of the affected attributes and references had 

been deleted in the subsequent metamodel versions. Such metamodel elements are incorrectly 

presented as unchanged, which is why they are incorporated into the generic metamodel. 

The affected elements are left in the GAUTOSAR metamodel to point out this issue. The 

problem can be resolved through manual correction of the respective comparison information 

in the DiffMap model. 

61

5. Results 

Figure 5.1.: Two excerpts from the automatically created GAUTOSAR metamodel. 

5.1.2. Known limitations of the prototype 

The prototype does not yet support attribute type and reference multiplicity changes that 

were discussed in section 4.3.1. Due to the high number of different types that can be 

used to describe data and the effect of type change on the generic API, implementing the 

optimal strategy for reacting to such changes requires a detailed data and use case analysis. 

Furthermore, the prototype does not implement safe means for distinguishing Ecore and 

primitive types from AUTOSAR types in the decoupling phase. This could be resolved by 

inspecting the fully qualified name of each type in order to find out which respective API 

the type belongs to. 

62

5.2. Limitations in the automation process 

5.2. Limitations in the automation process 

The development efforts in this thesis have led to recognition of limitations in automated 

creation of the generic metamodel. For some of the discovered limitations, suggestions for 

their resolving are given following the description of the problem. 

5.2.1. Undetectable class changes 

In certain cases, information that is common to all metamodels can still be lost even if 

only classes that are present in all compared metamodels are considered generic. Such a 

case occurs when a class is split into more classes and thereby information contained in one 

class is distributed into a number of classes. Similarly, information loss can occur when a 

number of classes is merged and information is aggregated into one class. The EMF Compare 

matching algorithm can only establish pairwise links, thus the DiffMap model has no way 

of representing changes that involve more than two classes. The engine creating the generic 

metamodel has no possibility to detect and to react to these changes automatically. The 

problem reflects in the contents of the affected classes as well - attributes and references are 

distributed or merged accordingly. From a higher abstraction level, the semantics implied 

by the combination of these attributes and references remain unchanged (splitting is often 

caused by structural convenience). However, such situations cause a semantic gap that 

cannot be processed automatically and can only be resolved by a domain expert. 

5.2.2. Generic elements not present in all metamodels 

As the number of supported AUTOSAR versions in Artop increases, so does the amount 

of change across models. In other words, the amount of generic data shrinks. Therefore, 

in order to keep the benefits of GAUTOSAR high, classes that are present in most models 

rather than in all models could still be considered generic. This, however, would require 

a restriction of usage of generic model elements in model versions that are not covered by 

GAUTOSAR. The problem of the decreasing amount of generic data could also be addressed 

by retiring support for releases of AUTOSAR metamodels which are not in widespread use 

anymore. 

5.2.3. Superclass information gain 

As discussed in section 4.3.1, the DiffMap model only detects addition or deletion of a 

superclass reference. A superclass reference is incorporated into the generic metamodel only 

if it is present in all compared metamodels. This way, the ARElement class in figure 5.2 would 

lose both the NonSplittableElement and the PackageableElement superclass references 

because neither is present in all occurrences of the ARElement class. This way, the ARElement 

class loses all information contained further up in the superclass hierarchy. 

To avoid such information loss, an alternative approach for constructing the class structure 

of the generic metamodel is proposed. In this approach, the first classes incorporated into 

the generic metamodel are leaf classes (classes that are not referenced as superclasses). The 

generic metamodel is then constructed bottom-up by following superclass references as illustrated 

in listing 5.1. 

63

5. Results 

Figure 5.2.: PhysicalDimension class hierarchy in different AUTOSAR metamodels (the 

semantics of the class is irrelevant here). 

64

function constructSuperclassHierarchy ( class ) { 

} 

List supertypes = class . getSupertypes (); 

foreach supertype in supertypes do 

if supertype in genericMetamodel 

class . supertype = supertype ; 

else 

incorporateInGenericMetamodel ( supertype ); 

class . supertype = supertype ; 

constructSuperclassHierarchy ( supertype ); 

5.3. Evaluation of achieved results 

Listing 5.1: Recursive algorithm for construction of the generic metamodel by building up 

the superclass hierarchy. 

In order to ensure that each class in the hierarchy contains the maximum information possible, 

each class should contain the maximum number of superclasses, combined from all 

version-specific metamodels. The combined hierarchy for the PhysicalDimension class from 

figure 5.2 is depicted in figure 5.3. The challenge now is to determine the desired maximum 

order of supertypes from the aggregated hierarchy. Under the assumption that each class in 

an AUTOSAR metamodel is ultimately a subclass of the ARObject class, the class diagram 

depicted in figure 5.3 represents a directed acyclic graph (DAG). A topological sorting algorithm 

can be applied on a DAG to obtain the longest path in the graph. This longest path 

represents the desired maximum order of supertypes (depicted by red arrows in figure 5.3). 

With this approach, the decoupling phase becomes unnecessary. Because the generic metamodel 

is built by building up the class hierarchy, any class referenced as a supertype is 

incorporated into the generic metamodel before it is used in the reference (as illustrated in 

listing 5.1). The DiffMap model can be used to obtain leaf classes with desired occurrence 

and change properties (i.e. unchanged leaf classes present in all metamodels). Following 

a superclass reference in any class represented in the DiffMap model does not lead to the 

representation of the superclass in the DiffMap model, but to a class in a version-specific 

metamodel. This means that the generic metamodel is essentially built outside of DiffMap, 

as following further superclass references from a class in the version-specific metamodel also 

leads to a class in the version-specific metamodel. Therefore, the DiffMap model has to be 

explored in a subsequent phase to obtain and incorporate class change information. The 

modified phase order is depicted in figure A.5 in the appendix. 

5.3. Evaluation of achieved results 

An evaluation of the resulting GAUTOSAR metamodel showed that the highest degree of 

automation is achieved with model elements that occur in all compared metamodels. Such 

presence is a strong implication that the semantics of such elements has remained unchanged, 

therefore these elements can be represented in the generic metamodel without the need for a 

manual intervention through a domain expert. The generic metamodel presented in section 

65

5. Results 

Figure 5.3.: Aggregated hierarchy for the PhysicalDimension class. Red arrows indicate 

the desired superclass order that can be obtained by topological sorting of a 

directed acyclic graph. 

66

5.4. Summary 

5.1 can be used to generate API code that covers up to a third of version-specific classes, 

which would otherwise have to be conceived manually. 

The identified limitations in automated processing and limitations of the prototype give 

an overview of more complex cases of evolutionary metamodel change. These limitations 

can be used as a starting point for further improvements of the developed prototype, which 

will lead to the automatic creation of an even more detailed generic metamodel. 

5.4. Summary 

This chapter presented the results of automation efforts in creating a generic metamodel 

based on metamodel comparison information. A generic AUTOSAR metamodel that was 

automatically created by the prototype from a difference model of three evolutionary different 

AUTOSAR metamodels was analyzed. The generic AUTOSAR metamodel contained almost 

a third of the number of classes in the version-specific metamodels and can be used to 

generate the generic AUTOSAR API. Observed issues in the resulting metamodel and known 

limitations of the prototype were listed. Observed issues included remaining references 

to elements in the version-specific APIs that were caused by incorrect information in the 

difference model. Known limitations of the prototype included no support for attribute type 

and reference multiplicity change. Conceptual limitations in automated creation of a generic 

metamodel that were discovered in the course of development, such as changes that cannot 

be identified automatically or the incorporation of metamodel elements that do not exist 

in all compared metamodels, were discussed and some solution suggestions were given. An 

alternative way of constructing the generic metamodel by building up the class hierarchy 

was discussed. The chapter was concluded with an evaluation of achieved results. 

67

5. Results 

68

6. Conclusion 

This chapter summarizes the problems and solution concepts that this thesis was concerned 

with, proposes ideas for future work and concludes the thesis with a final thought. 

6.1. Thesis summary 

This thesis was concerned with AUTOSAR metamodel evolution in Artop. AUTOSAR is 

a standardized architecture for developing software for electronic control units in automobiles. 

Artop is an infrastructure platform that enables creating versatile tools for developing 

AUTOSAR software. Each Artop release supports several versions of the AUTOSAR metamodel. 

This required tool developers to implement equivalent tool functionality separately 

for each version. The solution to this problem was found in a generic metamodel that could 

be used to generate a version-independent model API code. This API makes it possible to 

implement tool functionality only once for all versions. The creation of such a generic metamodel 

requires a comparison of different metamodels and the extraction of common elements. 

Performing these tasks manually on AUTOSAR metamodels is a very time-consuming task, 

therefore research efforts were made to automate this process. 

This thesis described a concept for automated creation of a generic, version-independent 

metamodel based on comparison results of evolutionary different metamodel versions. The 

generic metamodel encompasses elements that are common to all version-specific metamodels 

and elements that have been subject to minor changes during the evolution process. The 

developed concept was implemented in a model transformation prototype. The prototype 

uses a difference model containing metamodel comparison results as input and produces 

a generic metamodel as output. The generic metamodel can be used to generate versionindependent 

model API code. 

The metamodel comparison results were obtained from a difference model that was developed 

in a preceding thesis. The difference model was improved to present the comparison 

results in a format that enables easy recognition of commonly occurring metamodel elements 

across the compared versions, thus supporting the identification of generic metamodel elements 

that was performed in this thesis. The comparison process was improved to recognize 

the appearance of common metamodel elements with more accuracy, thus improving the 

quality of the automatically created generic metamodel. 

The developed automation concept processes the difference model by inspecting the occurrence 

and change information for each found metamodel element. Based on this information, 

a decision is made on incorporating the element into the generic metamodel. The generic 

metamodel is decoupled from references to elements in version-specific metamodels. The 

elements of the generic metamodel are renamed in an unambiguous way that at the same 

time makes it easy to relate them to their version-specific counterparts. 

69

6. Conclusion 

The prototype implementing the concept was applied to a difference model of three evolutionary 

different AUTOSAR metamodels. The resulting GAUTOSAR metamodel covered 

nearly a third of classes found in version-specific metamodels. The GAUTOSAR metamodel 

could be used to generate version-independent model API code. Issues in the resulting metamodel 

that could be fixed by manual correction of difference results were pointed out. Known 

limitations of the prototype that could be implemented in succeeding work were listed. 

The development efforts led to the discovery of some conceptual limitations in automated 

creation of a generic metamodel. These limitations were discussed and solution suggestions 

were given where applicable. Such limitations included changes that cannot be identified 

automatically or the incorporation of metamodel elements that do not exist in all compared 

metamodels. An alternative way of creating the generic metamodel that was based on class 

hierarchy was discussed. 

6.2. Future work 

The automation attempts that were discussed in this thesis leave some room for improvement. 

This section lists issues that were identified in the course of development of this thesis and 

whose solutions would be of great benefit for the automation process. 

6.2.1. Self-containment of the DiffMap model 

During the development of the prototype, a need for an abstraction of version-specific model 

elements contained in DiffMap arose. The DiffMap model is not self-contained, but rather 

masks the version-specific metamodels with additional information. This means that AU- 

TOSAR metamodel elements that are contained in difference groups are not representations 

of version-specific elements, but direct references to elements in the version-specific metamodels. 

For instance, following a superclass reference of some class in the DiffMap model 

does not lead to the corresponding DiffMap representation of the referenced superclass, but 

to the referenced superclass in the version-specific metamodel. Which version-specific metamodel 

is referenced exactly depends on when the mentioned original class first occurred in 

the metamodel history and which comparison history element the superclass information 

was extracted from. When the DiffMap model is processed manually, this is not an issue 

because a domain expert is able to mentally abstract the contained information. However, 

this situation makes programmatic processing of semantically equivalent information from 

different metamodels difficult because it requires the programmer to think in as many dimensions 

as there are compared metamodels. Therefore a higher degree of abstraction would 

greatly ease programmatic processing and information extraction from the DiffMap model. 

6.2.2. AUTOSAR-specific matching algorithm 

The EMF Compare matching algorithm that is used in DiffMap is not well-suited for comparing 

AUTOSAR metamodels. This matching algorithm was the cause of problems described 

in section 4.2.4. An AUTOSAR specific matching algorithm could be developed to produce 

better matching results during the comparison process. This would improve the difference 

results and would require less manual effort through a domain expert to verify the results. 

70

6.3. Final thought 

By processing a difference model of higher quality, the GAUTOSAR creation engine would 

be able to produce a higher quality generic metamodel which would require less manual 

intervention, too. 

6.2.3. Use-case analysis of attribute type changes 

As mentioned in the discussion of attribute type changes in section 4.3.1, this type of change 

has a crucial impact on the model API. Representing attributes that have been subject to 

this kind of change in a generic metamodel is still possible. However, choosing the right 

strategy for incorporating such attribute elements into the generic metamodel greatly varies 

on the characteristics of the involved types. Therefore, a detailed analysis of possible usecases 

should be conducted in order to find out the optimal implementation strategy. The 

results of this research should be implemented in the prototype. The prototype will be able 

to create a more complete generic metamodel, which will result in a wider usage capability 

of the generic API. 

6.3. Final thought 

The results of automation efforts that were conducted in this thesis show that automatic 

creation of a generic metamodel from a difference model of version-specific metamodels is 

feasible. The automatically created metamodel can be used to generate version-independent 

model API code. Even if such API code cannot match the semantical quality of the API 

generated from the manually created generic metamodel, the extent of automation achieved 

in this thesis relieves Artop developers from manual work to a great extent and thereby 

contributes to the usability and wide acceptance of the Artop platform in the AUTOSAR 

tool development community. 

71

6. Conclusion 

72

A. Appendix 

Model element or API method Original name Generic name 

Package packagename packagename 

Class ClassName ClassName 

Attribute/Reference attrRefName AttrRefName 

Accessor method getAttrRefName GetAttrRefName 

Mutator method setAttrRefName SetAttrRefName 

Table A.1.: Overview of the naming convention for the GAUTOSAR metamodel. 

73

A. Appendix 

74 

Figure A.1.: Two test models for package insertion.

Figure A.2.: One-way, new-to-old package insertion as conceived in [Kni11]. Internally, 

newpackage from the newer model (version 2) is inserted into the older model 

(version 1), thus migration of ClassB is identified. Because leakpackage from 

the older model is not inserted into the younger model as well, the migration 

of ClassC is not recognized but the class is considered to have first appeared 

in the newer version. 

75

A. Appendix 

Figure A.3.: Two-way, new-to-old and old-to-new package insertion. Internally, newpackage 

from the newer model (version 2) is inserted into the older model (version 1) 

and leakpackage from the older model is inserted into the newer model. The 

migration of ClassC is now recognized, too. However, no package addition or 

deletion information is available anymore. 

76

Figure A.4.: UML class diagram depicting the software components of the GAUTOSAR 

creation engine prototype. Internal utilities have been omitted for clarity. 

77

A. Appendix 

Figure A.5.: Modified concept for creating the generic metamodel. The metamodel is constructed 

by building up the class hierarchy through superclass references, thus 

not requiring the decoupling phase anymore. 

78

List of Figures 

2.1. Simplified view of the domain of software components and their communication 

paradigm in AUTOSAR, expressed in the UML class diagram notation. . 6 

2.2. The UML object diagram representing a model of an AUTOSAR software 

component. The model conforms to the metamodel in figure 2.1. . . . . . . . 7 

2.3. The four (meta)modeling layers as specified by OMG. . . . . . . . . . . . . . 8 

2.4. The EMF architecture (image adopted from [Ste08]). . . . . . . . . . . . . . . 12 

2.5. An excerpt from the Ecore metamodel (image adopted from [Ste08]). EOperation 

is not displayed in this image. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.6. Three representations of the simplified AUTOSAR software component metamodel: 

Ecore diagram (up left), Ecore tree view (up right) and the XMI 

serialization format (down). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.7. The generator model (up left) and code generation properties (down) for the 

software component model (up right). . . . . . . . . . . . . . . . . . . . . . . 16 

2.8. The software component model editor generated with EMF and integrated 

into the Eclipse framework. The editor features a software component with 

two ports that define a port interface. . . . . . . . . . . . . . . . . . . . . . . 19 

2.9. The EMF Compare process. Artifacts colored red can be customized to match 

specific user needs (image adopted from [Bru08]). . . . . . . . . . . . . . . . . 20 

3.1. AUTOSAR ECU architecture (image adopted from [AUT11b]). . . . . . . . . 26 

3.2. Overview of the AUTOSAR methodology (image adopted from [AUT11a]). . 27 

3.3. AUTOSAR methodology for software component implementation (image adopted 

from [AUT11a]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

3.4. Detailed view of the AUTOSAR metamodel in [autb] describing different types 

of software components in AUTOSAR and their relationships. . . . . . . . . . 29 

3.5. Non-collaborative and collaborative AUTOSAR tool development approach 

in comparison (image adopted from [KRV + 10b]). . . . . . . . . . . . . . . . . 30 

3.6. Layers composing the Artop architecture (image adopted from [Rud10]). . . . 31 

3.7. Two models created with the Artop Technology Demonstrator - an Eclipsebased 

AUTOSAR tool which was built by the Artop community to showcase 

Artop’s capabilities. The same is also possible in any AUTOSAR tool that 

makes use of Artop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

3.8. Version-specific generation of AUTOSAR API code from the respective AU- 

TOSAR metamodels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

3.9. The principle of Generic AUTOSAR. . . . . . . . . . . . . . . . . . . . . . . . 35 

4.1. Illustration of the steps necessary to realize GAUTOSAR with their respective 

resulting entities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

4.2. The DiffMap metamodel (purple) in the context of EMF Compare’s Diff metamodel 

(yellow) (image adopted from [Kni11]). . . . . . . . . . . . . . . . . . . 41 

79

List of Figures 

80 

4.3. The resulting DiffMap model structure when comparing three AUTOSAR 

metamodel versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

4.4. Illustration of the matching chain solution. An element from model 1 can be 

matched to an element in model 3, even though model 1 and model 3 were 

not compared directly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

4.5. The improved structure of the DiffMap model with three compared metamodels. 45 

4.6. Highlighted classes in metamodel version 3.x are reorganized and distributed 

among newly created subpackages in metamodel version 4.0. . . . . . . . . . . 46 

4.7. The result of comparing metamodel versions 2.1, 3.x and 4.0. According to 

the comparison history of selected classes, they only exist in two metamodel 

versions - 2.1 and 3.x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.8. The result of comparing metamodel versions 2.1, 3.x and 4.0 when the package 

insertion solution is applied. The comparison histories of selected classes now 

correctly describe the classes as present in all compared metamodels. . . . . . 49 

4.9. Illustration of the automated process for creating the GAUTOSAR metamodel. 50 

4.10. Illustration of references in superclasses, attributes and references before and 

after the decoupling phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

4.11. An excerpt from the created GAUTOSAR metamodel showcasing the used 

naming conventions. The NsURI extension of the gautosar package in the 

infrastructure package is shortened to the letter a and appended to extensions 

of its predecessor packages. . . . . . . . . . . . . . . . . . . . . . . . . . 56 

4.12. Two-layered architecture of the GAUTOSAR creation engine prototype. . . . 57 

5.1. Two excerpts from the automatically created GAUTOSAR metamodel. . . . 62 

5.2. PhysicalDimension class hierarchy in different AUTOSAR metamodels (the 

semantics of the class is irrelevant here). . . . . . . . . . . . . . . . . . . . . . 64 

5.3. Aggregated hierarchy for the PhysicalDimension class. Red arrows indicate 

the desired superclass order that can be obtained by topological sorting of a 

directed acyclic graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 

A.1. Two test models for package insertion. . . . . . . . . . . . . . . . . . . . . . . 74 

A.2. One-way, new-to-old package insertion as conceived in [Kni11]. Internally, 

newpackage from the newer model (version 2) is inserted into the older model 

(version 1), thus migration of ClassB is identified. Because leakpackage from 

the older model is not inserted into the younger model as well, the migration 

of ClassC is not recognized but the class is considered to have first appeared 

in the newer version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

A.3. Two-way, new-to-old and old-to-new package insertion. Internally, newpackage 

from the newer model (version 2) is inserted into the older model (version 1) 

and leakpackage from the older model is inserted into the newer model. The 

migration of ClassC is now recognized, too. However, no package addition or 

deletion information is available anymore. . . . . . . . . . . . . . . . . . . . . 76 

A.4. UML class diagram depicting the software components of the GAUTOSAR 

creation engine prototype. Internal utilities have been omitted for clarity. . . 77 

A.5. Modified concept for creating the generic metamodel. The metamodel is constructed 

by building up the class hierarchy through superclass references, thus 

not requiring the decoupling phase anymore. . . . . . . . . . . . . . . . . . . 78

List of Listings 

2.1. Generated interface for the SoftwareComponent class. Generated imports 

and comments have been omitted for clarity. . . . . . . . . . . . . . . . . . . 17 

2.2. Generated implementation for the SoftwareComponent class. Generated imports, 

comments and optimization methods have been omitted for clarity. . . 17 

3.1. Implementing the same functionality for different metamodel versions in an 

Artop-based AUTOSAR tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

3.2. The generic interface representing a QueuedReceiverComSpec object. . . . . . 35 

3.3. The actual implementation of the desired functionality reading the value of 

the queueLength property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

3.4. Integration of the generic interface into a version-specific API (here the 2.1 

API). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

5.1. Recursive algorithm for construction of the generic metamodel by building up 

the superclass hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 

81

List of Listings 

82

CD Contents 

The enclosed CD contains documents and prototype sources as listed below. The accompanying 

readme files in each folder explain the respective contents and contain instructions for 

running the prototypes. 

• Thesis Document 

– Diplomarbeit Leonard Krpan.pdf 

• Source Code 

– DiffMap Source Code 

∗ de.bmw.carit.datk.avem.diffmap 

∗ de.bmw.carit.datk.avem.diffmap.edit 

∗ de.bmw.carit.datk.avem.diffmap.editor 

∗ de.bmw.carit.datk.avem.diffmap.tests 

∗ de.bmw.carit.datk.avem.diffmap.gautosar 

∗ de.bmw.carit.datk.avem.diffmap.gautosar.diffengine 

∗ de.bmw.carit.datk.avem.diffmap.gautosar.matchengine 

∗ de.bmw.carit.datk.avem.diffmap.gautosar.util 

∗ readme.txt 

– Thesis Source Code 

• readme.txt 

∗ EMF Examples 

· SwComponentExample 

· SwComponentExample.edit 

· SwComponentExample.editor 

· readme.txt 

∗ GAUTOSAR Creation Prototype 

· src 

· models 

· results 

· readme.txt 

83

CD Contents 

84

Bibliography 

[auta] AUTOSAR Metamodel Version 3.1. 

[autb] AUTOSAR Metamodel Version 4.0. 

[AUT09] AUTOSAR. System Template, 4.0.0 edition, December 2009. 

[AUT10a] AUTOSAR. Software Component Template, 4.1.0 edition, October 2010. 

[AUT10b] AUTOSAR. Specification of RTE, 2.3.0 edition, September 2010. 

[AUT11a] AUTOSAR. AUTOSAR Methodology, 1.2.2 edition, April 2011. 

[AUT11b] AUTOSAR. Layered Software Architecture, 2.2.2 edition, March 2011. 

[AUT11c] AUTOSAR. Main requirements, 2.1.1 edition, April 2011. 

[AUT11d] AUTOSAR. Specification of the Virtual Functional Bus, 1.2.0 edition, March 

2011. 

[AUT11e] AUTOSAR. Technical Overview, 2.2.2 edition, April 2011. 

[BCT05] Alan W. Brown, Jim Conallen, and Dave Tropeano. Introduction: Models, 

Modeling, and Model-Driven Architecture. In Sami Beydeda, Matthias Book, 

and Volker Gruhn, editors, Model-Driven Software Development, pages 1–16. 

Springer, 2005. 

[BGGK07] Steffen Becker, Thomas Goldschmidt, Boris Gruschko, and Heiko Koziolek. A 

process model and classification scheme for semi-automatic meta-model evolution. 

In Proc. 1st Workshop MDD, SOA und IT-Management (MSI’07). GiTO-Verlag, 

2007. 

[Bre10] Ruth Breu. Ten Principles for Living Models - A Manifesto of Change-Driven 

Software Engineering. In Proceedings of the 2010 International Conference on 

Complex, Intelligent and Software Intensive Systems, pages 1–8. IEEE, 2010. 

[Bru] Cedric Brun. EMF Compare 1.0.0 Galileo Simultaneous Release. Available 

online at: http://www.eclipse.org/project-slides/Galileo/EMF_Compare_ 

Galileo_Review.pdf, accessed 2.6.2011. 

[Bru08] Cedric Brun. Comparing and Merging Models with Eclipse : an Update on EMF 

Compare (Presentation). In EclipseCon, March 2008. 

[CDREP08] Antonio Cicchetti, Davide Di Ruscio, Romina Eramo, and Alfonso Pierantonio. 

Automating co-evolution in model-driven engineering. In Proceedings of the 2008 

12th International IEEE Enterprise Distributed Object Computing Conference, 

pages 222–231. IEEE, 2008. 

85

Bibliography 

[emfa] EMF Compare - Eclipsepedia. Online: http://wiki.eclipse.org/EMF_ 

Compare, accessed 2.6.2011. 

[emfb] org.eclipse.emf.compare.diff.metamodel (EMF Compare Javadoc). Online: http: 

//download.eclipse.org/modeling/emf/compare/javadoc/1.1.0/, accessed 

4.6.2011. 

[Eva03] Eric Evans. Domain-Driven Design: tackling complexity in the heart of software. 

Addison-Wesley, 1st edition, 2003. 

[Eys08] Moritz Eysholdt. Towards EMF Ecore based Meta Model Evolution and Model 

Co-Evolution. In MDSD Today, October 2008. 

[FR07] Robert France and Bernhard Rumpe. Model-driven Development of Complex 

Software: A Research Roadmap. In 2007 Future of Software Engineering, pages 

37–54. IEEE, 2007. 

[GHH04] Anouck R. Girard, Adam S. Howell, and J. Karl Hedrick. Model-Driven Hybrid 

and Embedded Software for Automotive Applications. In 2nd RTAS Workshop 

on Model-Driven Embedded Systems, 2004. 

[Gri08] Frank Grimm. Increasing Reliability of Model-driven Software Family Engineering 

and Product Configuration. In Second International Workshop on Variability 

Modelling of Software-intensive Systems, 2008. 

[Gru06] Boris Gruschko. Towards Structured Revisions of Meta Models and Semi- 

Automatic Model Migration. In Eclipse Modeling Symposium, October 2006. 

[Hei04] Heinecke, Harald and Schnelle, Klaus-Peter and Fennel, Helmut and Bortolazzi, 

Jürgen and Lundh, Lennart and Leflour, Jean and Mate, Jean-Luc and Nishikawa, 

Kenji and Scharnhorst, Thomas . AUTomotive Open System ARchitecture - An 

Industry-Wide Initiative to Manage the Complexity of Emerging Automotive 

E/E-Architectures, 2004. 

[Her07] Markus Herrmannsdörfer. Coupled Evolution of Metamodels and Models. Master’s 

thesis, Technische Universität München, 2007. 

[HT06] Brent Hailpern and Peri Tarr. Model-driven development: the good, the bad, 

and the ugly. IBM Systems Journal, 45:451–461, July 2006. 

[HVW11] Markus Herrmannsdörfer, Sander D. Vermolen, and Guido Wachsmuth. An extensive 

catalog of operators for the coupled evolution of metamodels and models. 

In Proceedings of the Third international conference on Software language engineering, 

SLE’10, pages 163–182. Springer, 2011. 

[Kal10] Philipp Kalb. UML Model Merging in the Context of a Model Evolution Engine. 

Master’s thesis, Leopold-Franzens-University Innsbruck, 2010. 

[Kni11] Tom Knipphals. Generische Verarbeitung evolutionär unterschiedlicher Versionen 

eines domänenspezifischen Modells. Master’s thesis, Fachhochschule für Angewandte 

Wissenschaften Augsburg, January 2011. 

86

Bibliography 

[KRV + 10a] Christian Knüchel, Michael Rudorfer, Stefan Voget, Stephan Eberle, Romain 

Sezestre, and Aldric Loyer. Artop - AUTOSAR Tool Platform. An ecosystem 

approach for collaborative AUTOSAR tool development. In ERTS2 Embedded 

Real Time Software and Systems, May 2010. 

[KRV + 10b] Christian Knüchel, Michael Rudorfer, Stefan Voget, Stephan Eberle, Romain 

Sezestre, and Aldric Loyer. Artop - AUTOSAR Tool Platform. An ecosystem approach 

for collaborative AUTOSAR tool development (Presentation). In ERTS2 

Embedded Real Time Software and Systems, May 2010. 

[Lid10] Stephen W. Liddle. Model-Driven Software Development. June 2010. 

[LZG04] Yuehua Lin, Jing Zhang, and Jeff Gray. Model comparison: A key challenge 

for transformation testing and version control in model driven software development. 

In Control in Model Driven Software Development. OOPSLA/GPCE: 

Best Practices for Model-Driven Software Development, pages 219–236. Springer, 

2004. 

[MD08] Parastoo Mohagheghi and Vegard Dehlen. Where Is the Proof? - A Review of 

Experiences from Applying MDE in Industry. In Proceedings of the 4th European 

conference on Model Driven Architecture: Foundations and Applications, pages 

432–443. Springer, 2008. 

[mdsa] Artop - AUTOSAR Tool Platform User Group. Online: http://www.artop. 

org/artext/, accessed 31.5.2011. 

[mdsb] Do you know what your metamodel is. Online: http://nekulturniy.com/ 

Writings/MOFarticle/MOF_article.html, accessed 31.5.2011. 

[mdsc] GEF. Online: http://www.eclipse.org/gef/, accessed 31.5.2011. 

[mdsd] Grammatical Description of Syntax: The BNF Metalanguage. Online: http: 

//www.cs.sfu.ca/~cameron/Teaching/383/BNF.html, accessed 31.5.2011. 

[mdse] XML Schema Tutorial - Part 1/5 - Defining Elements and Attributes. 

Online: http://www.liquid-technologies.com/Tutorials/XmlSchemas/ 

XsdTutorial_01.aspx, accessed 31.5.2011. 

[NH08] Edward Nelson and Henry Huang. A Software and System Modeling Facility 

for Vehicle Environment Interactions. In Manfred Broy, Ingolf H. Krüger, and 

Michael Meisinger, editors, Model-Driven Development of Reliable Automotive 

Services, pages 34–47. Springer, 2008. 

[PBKS07] Alexander Pretschner, Manfred Broy, Ingolf H. Krüger, and Thomas Stauner. 

Software engineering for automotive systems: A roadmap. In 2007 Future of 

Software Engineering, pages 55–71. IEEE, 2007. 

[rela] EMF Compare/EPatch - Eclipsepedia. Online: http://wiki.eclipse.org/EMF_ 

Compare/Epatch, accessed 7.6.2011. 

[relb] Maude. Online: http://maude.cs.uiuc.edu/, accessed 8.6.2011. 

87

Bibliography 

[relc] subversion.tigris.org. Online: http://subversion.tigris.org/, accessed 

7.6.2011. 

[Rud10] Rudorfer, Michael and Voget, Stefan and Eberle, Stephan. Artop whitepaper, 

2010. 

[RV08] Jose E. Rivera and Antonio Vallecillo. Representing and Operating with Model 

Differences. In Richard F. Paige and Bertrand Meyer, editors, TOOLS Europe, 

pages 141–160. Springer, October 2008. 

[SBPM09] Dave Steinberg, Frank Budinsky, Marcelo Paternostro, and Ed Merks. Eclipse 

Modeling Framework. Addison-Wesley, 2nd edition, 2009. 

[Sel03] Bran Selić. The pragmatics of model-driven development. Software, IEEE, 20:19– 

25, September 2003. 

[sph] Sphinx. Online: http://www.eclipse.org/sphinx/, accessed 13.7.2011. 

[Ste08] Dave Steinberg. Fundamentals of the Eclipse Modeling Framwork (Presentation). 

In EclipseCon, March 2008. 

[SV05] Thomas Stahl and Markus Völter. Modellgetriebene Softwareentwicklung - Technicken, 

Engineering, Management. dpunkt.verlag, 1st edition, 2005. 

[Tah08] Walid Taha. Domain-Specific Languages. In International Conference on Computer 

Engineering Systems, 2008, pages 23–28. IEEE, 2008. 

[Tou06] Antoine Toulme. Presentation of EMF Compare Utility. In Eclipse Modeling 

Symposium, October 2006. 

[vDKV00] Arie van Deursen, Paul Klint, and Joost Visser. Domain-specific languages: an 

annotated bibliography. SIGPLAN Notices, 35:26–36, June 2000. 

[VSK05] Markus Völter, Christian Salzmann, and Michael Kircher. Model Driven Software 

Development in the Context of Embedded Component Infrastructures. In Colin 

Atkinson, Christian Bunse, Hans-Gerhard Gross, and Christian Peper, editors, 

Component-Based Software Development for Embedded Systems, pages 143–163. 

Springer, 2005. 

[WSA02] Huadong Wu, Mel Siegel, and Sevim Ablay. Sensor Fusion for Context Understanding. 

In Proceedings of the 19th IEEE Instrumentation and Measurement 

Technology Conference, volume 1, pages 13–17. IEEE, August 2002. 

88

institut f¨ur informatik - PST Thesis Management Interface - LMU

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?