Automotive MDSD – What pickle?

Over at the modeling languages website, Scott Finnie has started a number of posts detailing his point of view on the status of model driven approaches. He concludes his first post with the statement “No wonder we’re in a pickle.”. Reading that, I myself was wondering that I don’t feel in a pickle at all.

Since the comment section of has limited formatting for a longish post, I’d like to put forward my 2c here.

Yes, model driven is not as visible and hyped as many other current technologies and, compared to the entire software industry, its percentual usage might not be impressing. But looking at my focus industry, automotive, I think we have come a long way in the last 10 years.

Model-Driven development is an important and accepted part of the automotive engineer’s toolbox. Most of the industry thinks of ML/SL and Ascet when hearing of the MD* terms. But actually there are so many other modeling techniques in use.

Architecture models are one of the strongest trends, not the least driven by the AUTOSAR standard. But even aside (or complementary to) AUTOSAR, the industry is investing in architecture models in UML or DSLs, often in connection with feature modeling and functional modeling. Code is generated from those architectural models, with the implementation being generated from ML/SL, Ascet, state machines or being written manually. Quality of the engineering data is improving noticeably through this approach.

Companies introduce their custom DSLs to model architecture, network communication, test cases, variants and generate a huge set of artefacts from that.  Models and transformations are being used to connect the AUTOSAR domain to the infotainment domain by transformations to/and from Genivi’s Franca, itself being used to generate code for the infotainment platform.

Model Driven approaches are popping up everywhere and a lot has happened in the past few years. One of the key factors for that development, in my point of view, is the availability of low-cost, accessible tooling and I would consider two tools to be most influential in this regard

  • Enterprise Architect made UML modeling available at a reasonable price, opening it up to a much wider market. That made it possible for more projects and individual to build their MDSD approach based on UML and (custom) generators.
  • Xtext made a great framework and tool for domain specific languages available at no cost to companies, projects and enthusiasts. It is always fun and amazing to come into an existing project and find what many teams have already built on Xtext. Xtext itself of course is standing on the shoulder of giants, Eclipse and the Eclipse Modeling Framework (EMF).

Maybe Eclipse Sirius will be able to do for Graphical DSLs what Xtext has done for textual modeling. 15 years ago I was working for a company that offered UML-modelling and one of the first template-based code generation technologies at a high price. The situation is completely different now – and very enjoyable.

EclipseCon Europe 2015 from an Automotive Perspective

As Eclipse is established as a tooling platform in automotive industry, the EclipseCon Europe conference in Ludwigsburg is an invaluable source of information. This year’s EclipseCon is full of interesting talks. Here is a selection from my “automotive tooling / methodology” perspective.

  • The Car – Just Another Thing in the Internet of Things? – 

    Michael Würtenberger is the head of BMW CarIT. In addition to the interesting talk, BMW CarIT was also one of the strong drivers of the Eclipse / EMF based AUTOSAR tooling platform “Artop” and it is very interesting to learn about their topics.

  • openETCS – Eclipse in the Rail Domain, 

    Rover Use Case, Specification, design and implementation using Polarsys Tools

    Scenarios@run.time – Modeling, Analyzing, and Executing Specifications of Distributed Systems

    The multiple facets of the PBS (Product Breakdown Structure)

    openMDM5: From a fat client to a scalable, omni-channel architecture

    Enhanced Project Management for Embedded C/C++ Programming using Software Components

    All industries are also looking into what the “other” industry is doing to learn about strength and weaknesses.

  • Brace Yourself! With Long Term Support: Long-Term-Support is an important issue when choosing a technology as strategic platform. This talk should provide information to use in discussions when arguing for/against Eclipse and Open Source.

  • The Eclipse Way: Learn and understand how Eclipse manages to develop such a strong ecosystem

  • My experience as an Eclipse contributor:
    As more and more companies from the automotive domain actively participate in Open Source, you will learn on what that means from a contributor’s view.

On the technical side, a lot of talks are of interest for automotive tooling, including:

  • Ecore Editor- Reloaded

    CDO’s New Clothes

    GEF4 – Sightseeing Mars
    All Sirius Talks
    All Xtext Talks
    Modeling Symposium

    Customizable Automatic Layout for Complex Diagrams Is Coming to Eclipse

    Since EMF is a major factor in Eclipse in automotive, these talks provide interesting information on modeling automotive data.

  • EMF Compare + EGit = Seamless Collaborative Modeling

    News from Git in Eclipse

    Tailor-made model comparison: how to customize EMF Compare for your modeling language

    Storing models in files has many advantages over storing them in a database. These technologies help in setting up a model management infrastructure that satisfies a lot of requirements.

  • 40 features/400 plugins: Operating a build pipeline with high-frequently updating P2 repositories

    POM-less Tycho builds

    Oomph: Eclipse the Way You Want It

    High productivity development with Eclipse and Java 8
    Docker Beginners Tutorial

    These will introduce the latest information on build management and development tools.

Of course there are a lot more talks at EclipseCon that are also of interest. Checkout the program. It is very interesting this year.

Managing Autosar Complexity with (abstract) Models

A certain number of developers in the automotive domain complain that the introduction of AUTOSAR and its tooling increases the development efforts because of the complexity of the AUTOSAR standard. There is a number of approaches to solve this problem – one of the most used is the introduction of additional models.

The complexity of AUTOSAR

One often heard comment about AUTOSAR is that the meta-model and the basic softwae configuration is rather complex and that it takes quite some time to actually get acquainted with that. One of the reasons is that AUTOSAR aspires to be an interchange standard for all the software engineering related artefacts in automotive software design and implementation. As such, it has to address all potentially needed data. However, for the single project or developer, that also means that they will be confronted with all that aspects that they never had to consider. Overall, one might argue that AUTOSAR does not increase the complexity, but it exposes the inherent complexity of the industry for all to see. That however implies, that a user might need more manageable views on AUTOSAR.

Example: Datatypes

The broad applicability of AUTOSAR leads to a meta-model, that will take some analysis to understand. For application data types, the following meta-model extract shows relevant elements for  “specifying lower and upper ranges that constrain the applicable value interval.”

Extract from AUTOSAR SW Component Template

Extract from AUTOSAR SW Component Template

Which is quite a flexible meta-model. However, all the compositions make it complex from the perspective of an ECU developer. The meta-model for enumerations is even more complex.


Extract from AUTOSAR SW Component Template: Enumerations

If you come from C with its lean notation

it seems quite obvious that the AUTOSAR model might be a bit scary. So a lot of projects and companies are looking for custom ways to deal with AUTOSAR.

Custom Tooling or COTS

In the definition of a software engineering tool chain, there will always be trade-offs between implementing custom tooling or deploying commercial tools. Especially for innovative projects, the teams will use innovative modeling and design methods and as such will need tooling specially designed for that. The design and implementation of custom tooling is a core competency of tooling / methodology departments.

A more abstract view on AUTOSAR

The general approach will be to provide a view on AUTOSAR (or a custom model) that is suited to the special needs of a given user group and then generate AUTOSAR from that. Some technical ideas would be:

“Customize” the AUTOSAR model

In this approach, the AUTOSAR model’s features are used to annotate / add custom data that is more manageable. This case can be subdivided into the BSW configuration and the other parts of the model.

BSW: Vendor specific parameter definitions

The ECUC configuration supports the definition of custom parameter definitions that can be used to abstract the complexity. Take the following example:

  • The standard DEM EventParameter has various attributes (EventAvailable, CounterThreshold, PrestorageSupported).
  • Let’s assume, that in our setting, only 3 different combinations might be valid. So it would be nice if we could just say “combination 1” instead of setting those manually
  • So we could define a VSMD that is based on the official DEM and have a QXQYEventParameter that has only one attribute “combination”
  • From that we could then generate the DEMEventParameter’s values based on the combination attribute.

This is actually done in real life projects. Technologies to use could be:

  • COMASSO: Create a Xpand script and use the “update model”
  • Artop: Use the new workflow and ECUC accessors mechanism

SYstem / SW Templates:

The generic structure template of AUTOSAR allows us to add “special data” to model elements. According to the standard “Special data groups (Sdgs) provide a standardized mechanism to store arbitrary data for which no other element exists of the data model.” (from the Generic Structure specification). Similar to the approach of the BSW we could add simple annotations to model elements and then derive more complex configuration for that (e.g. port communication attributes).

Adapt standard modeling languages

Another approach is to adapt standard (flexible) modeling languages like UML. Tools like Enterprise Architect provide powerful modeling features and the UML diagrams with their classes, ports and connections have striking similarities to the AUTOSAR component models (well, component models all have similarities, obviously). So a frequently seen approach is to customize the models through stereotypes / tagged values and maybe customize the tool.

The benefit of this approach is that it provides more flexibility in designing a custom meta-model by not being restricted by the AUTOSAR extension features. This approach is also useful for projects that already had a component-based modeling methodology prior to AUTOSAR and want to be able to continue using these models.

A transformation to AUTOSAR is easily written with Artop and Xtend.

Defining custom (i.e. domain specific models)

With modern frameworks like Xtext or Sirius, it has become very easy to implement your own meta-models and tooling around that. Xtext is well suited for all use cases where a textual representation of the model is required. Amongst others, that addresses a technical audience that is used for programming and wants fast and comfortable editing of the models with the keyboard.

German readers will find a good industry success story in the 2014 special edition of “heise Developer Embedded” explaining the use of Xtext at ZF Friedrichshafen.

The future?

AUTOSAR is a huge standard that covers a broad spectrum. Specific user groups will need specific views on the standard to be able to work efficiently. Not all of those use cases will be covered by commercial tools and innovation will drive new approaches.

Custom models with transformations to and from AUTOSAR are one solution and the infrastructure required for that is provided in the community project Artop and the ecosystem around the Eclipse modeling framework EMF.



Functional Architectures (EAST-ADL) and Managing Behavior Models

In the early phases of systems engineering, functional architectures are used to create a functional description of the system without specifying details about the implementation (e.g. the decision of implementation in HW or SW). In EAST-ADL, the building blocks of functional architectures (Function Types) can be associated with so-called Function Behaviors that support the addition of formal notations for the specification of the behavior of a logical function.

In the research project IMES, we are using the EAST-ADL functional architecture and combine it with block diagrams. Let’s consider the following simplified functional model of a Start-Stop system:

2013-11-10_12h53_32In EAST-ADL, you can add any number of behaviors to a function. We already have a behavior activationControlBehavior1 attached to the function type activationControl and we are adding another behavior called newBehavior.2013-11-10_12h54_06

A behavior itself does not specifiy anything yet in EAST-ADL. It is more like a container that allows to refer to other artefacts actually containing the behavior specification. You can refer to any specification (like ML/SL or other tools). For our example, we are using the block diagram design and simulation tool DAMOS, which is available as open source at

We can now invoke the “Create Block Diagram” on the behavior. 2013-11-10_12h55_34

The tool will then create a block diagram with in- und output ports that are taken from the function type (you can see in the diagram that we have two input ports and one output ports).2013-11-10_12h56_20 Add this point, the architects and developers can specify the actual logic. Of course it is also possible to use existing models and derive the function type from that (“reverse from existing”). That would work on a variety of existing specifications, like state machines, ML/SL etc.

A DAMOS model could look like this:2013-11-10_12h56_48

At this point of the engineering process, we would have:

  • A functional architecture
  • one or more function behaviors with behavior models attached to the function types

Obviously, the next thing that comes to mind is  to combine all the single behavior models and to create a simulation model for a (sub-) system. Since we might have more than one model attached to a function, we have to pick a specific model for each of the function types.

This is done by creating a system configuration.2013-11-10_13h02_52That will create a configuration file that associates a function type (on the left side) with a behavior model (right side). Of course, using Eclipse Xtext, this is not only a text file, but a full model with validation (are the associated models correct) and full type aware content assist:2013-11-10_13h16_52After the configuration has been defined, a simulation model is generated that can then be run to combine the set of function models.






Prototype of an AUTOSAR Parameter Definition Editor based on Xtext

A large part of developing an AUTOSAR ECU is the configuration of the Basic Software (BSW, i.e. the AUTOSAR “operating system”). All the parameters that can be configured are defined in the so-called “AUTOSAR parameter definition”. This includes hundreds, if not thousands of parameters for the configuration of the basic software modules.

There are a number of editors for the actual configuration of the values. Some of these work by reading the parameter definition and providing a user interface dynamically based on the defined parameters. So the ECU configurator does have graphical tools for his work.

The parameter definition itself, however, is often written with XML editors. AUTOSAR XML however is very verbose and often not really suited for human editing and inspection. Creating a textual editor with Xtext is often a good solution to provide comfortable editing. So we did a prototype for the schema definition editor based on Xtext and ARTOP.

Here is a small example of a definition for non-volatile RAM:

NVRam Parameter Definition

NVRam Parameter Definition

Using Xtext and Artop we have a number of benefits:

  • We work directly on the AUTOSAR model. We do not need a custom temporary model that we map to AUTOSAR
  • With a few lines of code, we save the parameter definition in the Xtext notation above as well as in correct AUTOSAR .arxml
  • We see the full parameter definition structure directly in Artop

2013-05-10_11h04_46The Xtext representation is more concise than the corresponding AUTOSAR XML:

What are the use cases? Obviously, this could be used by teams that provide the parameter definitions for the basic software. In addition, projects might want to define their own parameter definitions that hold additional data for the development process and should be stored in an AUTOSAR-compliant way – e.g. for being editable by the generic editors mentioned above.





Software Tool Chain for Automotive – the IMES research project

At itemis, we are currently participating in a public funded research project (IMES) that deals with the software development tool chain for automotive software, especially in early phases. We do have two main focus points in the project:

  • An integrated tool chain for logical functions and software architecture, including traceability to requirements and variant management.
  • A prototype for a trans-company model repository that avoids the current gaps in the tool chain.

The project is a good example how you can leverag existing Eclipse technologies and combine them:

IMES Architecture

IMES Architecture

  • The development process starts with requirements. We use the Eclipse RMF project to import ReqIF and display/edit requirements. This is also the basis for traceability. Eclipse RMF is an open source project contributed by itemis and the university of Düsseldorf / Formal Mind
  • The specification of feature models and model variants is done with tooling based on the Eclipse Feature Model project. The basis of the feature model project had been contributed by pure systems and recently, itemis has released the textual editors for the features / variants as open source and will put them under the Eclipse umbrellas. The editors are based on Xtext, another open source project.
  • Functional modeling (logical architecture) is based on the just recently published EAST-ADL meta-model / its implementation that is published under the name “EATOP”. The meta-model has been contributed by Continental AG as part of a public funded research project. The editors are implemented by itemis and rely heavily on the Eclipse Graphiti framework.
  • In early phases, logical architecture is often done in combination with functional prototypes. These are provided in terms of state machines or, more often, data flow / block diagrams. While the OEM will still use commercial modeling tools for this purpose, we use Eclipse DAMOS to show the integration.
  • Logical Functions are mapped to software architecture. The software architecture editor is developed in the scope of IMES and is based on Artop – an AUTOSAR meta-model implementation by the Artop user group.
  • The same applies for the deployment to real ECUs. Both editors again are based on the Graphiti framework.
  • All of the artifacts can be traced on model element level. This is done by using Yakindu CReMa, which has been developed within the VERDE research project.
  • Again, on model element level, change management tickets can be assigned on a fine level to any tickets. Eclipse Mylyn provides all the infrastructure and the connection to the editors is developed on the IMES side.

On the repository side, we are bringing together two of Eclipse’s interesting projects:

  • Sphinx provides a lot of functionality for workspace management and helps several editing tools from different sources to work together on the same models.
  • CDO is a persistency framework with branching / versioning support (think “Git” for models). It will allow for a number of different collaboration scenarios between OEM and 1st tier, including working together on the same server, working on offline repositories with sync etc.

The Eclipse eco-system is truly marvelous.

Avoiding manual merge when generating plugin.xml with Xtext/Xtend

In our project we do generate graphical editors for Graphiti based on DSL-models specifiying these editors. That works all fine when generating the source code (.java and .xtend). However, for Graphiti and the editor to work, there also have to be some additions / modifications to the plugin.xml of the editor’s defining plugin.

While there is no issue in generating any text file (and such some .xml) with Xtend, the default mechanism has two characteristics that require a manual merge:

  • Artefacts are generated into src-gen/, plugin.xml is one level higher
  • No merging support of existing files with generated files out-of-the-box

While it is probably possible to modify the code generator infrastructure that Xtext provides out-of-the box, we chose a simpler way: Why not generate the extensions that we use in separate in the src-gen directory and then use another mechanism to merge in with plugin.xml?

Eclipse allows you to add custom builders to your project through the project properties. There are basically two that you can configure: An external program or an ANT Build. An external program was not feasible, since we would like the same configuration to work on different platforms (WIN,Mac,Linux) and you would require absolute pathes to binaries.

But the same can be done with an ant. So in our projects we do have a new ANT script2013-01-11_09h40_56that recognizes the merged sections and upon build, throws them out and replaces them with the contents of one or more “fragment” files that end with “copymetoplugin.xml” from src-gen:



Hier is the pom fragment to update the XML from Tycho:



Lost Art Of the Ancients – Software Through Pictures/Ameos, EuGENia, Spray et al.

Despite the strong trend for textual DSLs, graphical diagrams and even editors are still popular. It is just easier to see the connections in a component diagram than trying to figure them out from a textual representation (though it is not necessarily easier to edit them graphically).

DSLs for graphical editors

Although the APIs for graphical editors are becoming more powerful and more easy to use (e.g. with Graphiti), they still require a lot of implementation effort. With the availability of textual DSL tooling, a solution to this problem is to provide a textual DSL for the graphical editors. On Eclipse, two of these projects would be Spray for Graphiti editors and EuGENia for GMF editors.

Lost art of the ancients: StP

Part of the UML diagram definition in StP

It is good to have these projects, since the Eclipse platform is the current tool integration platform of choice. On the other hand, it is also a pity to me to see what we once had and what has to be “redone” again: In the late 90s and earls 2000s, one of the better known UML case tools was “Software Through Pictures”, later rebranded to “Ameos”. But it was more just an UML tool. The entire product was based on a textual DSL to specify graphical diagrams, tabular editors and property sheets.

Since StP supported the later UML 1.x and early 2.x versions, Booch, OMT and other diagrams, it was quite powerful and able to deal with a lot of cases. It is a good inspiration for anyone looking to design DSLs for the specification of graphical editors.


But the company that was responsible for the tool (Aonix at that time), decided not to invest in further development. Luckily, a spin off of that company called ScopeSet managed to get the tool into open source to be able to support users. Although I would consider the tool outdated, its DSLs are worth studying. It can be downloaded at If you are interested in the DSL without installing the tool, google for “stp customization manual”. It is from 1998 and not up to date for the latest tool version, but it gives a good impression of the DSLs.



In the public funded research project, we defined a DSL for our Graphiti editors (Spray! was not published when we started). Because of my long time background with Ameos, it was built upon my experiences with that tool.


  •  Line 16 defines a diagram. Much of the information is for generating the Graphiti infrastructure. “Extension” specifies the file name extension for diagrams of that type
  • Line 18: Diagrams are attached to model object. In this case, we attach to an Autosar ARPackage. That will result in a “New Diagram” pop up menu to be added to the Eclipse project explorer for Autosar packages. New Diagrams will be initialized with nameFunc, which is a Xtend2 expression that is evaluated.
  • Line 23: Our first symbol is for Autosar Composition Type.
  • Line 24: The attribute specifies which attribute should be taken for the label of the symbol. This is just a convenience field. More complex operations are possible with Xtend2 (see below).
  • Line 26: The shape to be drawn. We did not spend any effort for a Shape DSL – that is often just implemented in Java with similar effort
  • Line 29: The context specifies that we can directly place this on the diagram. The objects will then be added to the ctx.elements colleciton of the diagram’s object (again, a Xtend2 expression with full content assist support)
  • Line 33: The other symbols, a Component Prototype (in UML, you’d call this a “part”)
  • Line 34: The label expression is more complex.
  • Line 37: We can use this symbol in different contexts. Depending on the context, it is put / taken from different collection. Note that we do not have any forced relationship between graphical containment and domain model containment. That would not be sufficient for most more complex meta-models (Autosar, UML, EAST-ADL)
  • Line 109: We want to be able to drag a software component into another and create a prototype.
  • Line 110: The convert function (Xtend2!) specifies how to create the prototype from the dragged object.
  • It is not sufficient, to map connections to EReferences. In most sophisticated meta-models, a graphical connection is mapped to complex data structures. In our DSL, we can specify what to do after a connection is created with Xtend2 structures.


DSLs for graphical editors are currently getting a lot of attention. If you want some inspiration, look at the existing projects mentioned above and don’t forget to get inspired by StP.






A Graphiti based EAST-ADL Editor

Funded by the BMBF

Funded by the BMBF

In the public funded research project IMES we are building a set of editors for the SW Development process in Automotive. Some of the blogs here describe the AUTOSAR editors. Before the actual software development, the engineering process uses function models to describe the functionality without having decided which parts of the function are implemented in software or hardware.

For those function models, we had defined our own simple meta-model. But since we prefer standards and the EATOP-project has released an EAST-ADL .ecore, I migrated the editors to use the EAST-ADL analysis function model.

In IMES, we are using a textual DSL (not Spray!) to describe the Graphiti based editors. That made the migration very easy. It consisted basically in

  • Generating the EMF plugins from the EATOP ecore
  • Adjusting the textual DSL describing the editor.

Finished. Time overall: Two hours.

We will need some additional time to integrate EEF, variant management etc., what we had already for our home-grown meta-model. But getting the editor ready was very quick.

Generation gap pattern, ecore, Graphiti and nice pieces of mwe/Xtext

When using a model driven approach, you will face the situation where you have to combine your manual code with the generated artifacts. Heiko Behrens has written an excellent post on that matter. Little known is a nice feature of the Xtext framework, that gives you support for generation gap even if your project is not Xtext based!

The problem at hand

When implementing the Autosar editors we faced the situation that we had to introduce our own complex shapes. However, Graphiti has a fixed diagram meta-model defined as ecore. That makes sense if you want a purely programmatic API – Graphiti provides helper function to store user defined properties at the graphical elements.

However, we would liked to have full OO support, i.e. adding new methods, using inheritance, type safety at compile time for the properties etc. So we would actually like to extend the graphiti meta model.

And that is not really a problem: If we inherit from the Graphiti classes, the Graphiti framework will perfectly handle our new classes and we can make use of our newly introduced classes in our own Graphiti features. So we just create a new ecore definition that references the original Graphiti meta-model and derive from that. Since we were lacking creativity, we called the derived class “SmartShape” and we have several subclasses of that for functionality.

The subclasses do have methods that know how to do some things (move an associated floating label, change the shape depending on the business object) etc. These methods have to be implemented manually and EMF has some mechanisms to support adding manual code. However, that is done in the generated code, marked with tags and is not so nice (see Heiko’s Blog).

The unexpected friend: Xtext

A nice solution is to reuse parts of the Xtext workflow.

Standard emf classes are generated into emf-gen. Our own custom classes are in src.

The Xtext team have a solution to actually call the EMF model for the genmodel in such a way, that it hooks in into any CustomImpl classes that are found on the classpath. So e.g. in our meta-model we have a SmartShape. The code-generator of EMF will generate a SmartShapeImpl, but we are not going to modify that. Instead, we have a SmartShapeImplCustom, which extends SmartShapeImpl. If we run the mwe2 workflow again, the EMF Factories and all other classes will be generated in such a way, that a SmartShapeImplCustom is instantiated each time the createSmartShape() method is called on the factory. The workflow is pretty simple. Our genmodel is mentioned at the end (duankou.genmodel).

Since the custom classes are not touched at code generation, they are separated from the generated classes. So we do not need to but the generated code into source code management, only the manual classes.

Tycho 0.16

Tycho and mwe2 actually work together quite fine. So we can invoke this generation not only in the IDE, but in any of our automated builds as well:


Graphiti is a nice framework for the implementation of graphical editors. Generation Gap pattern and some nice feature from Xtext make it even more fun to work with. As you can see in the code below, the diagram is stored as a regular Graphiti Diagram with graphics Algorithms etc., but the Shape hiere is our own SmartShapeAutosarComponent.