Autosar Editor: Automatic Zoom for Connections

Just a little tidbit: In graphical editors, your target element for a new connection is often out of the current view. You need to scroll and find the element. For our Graphiti based Autosar editor I chose to add another functionality: When pressing CTRL when starting a new connection, the view is automatically zoomed to show all relevant elements. After finishing or canceling the connection, the original view is restored:

Interesting aspects of the AUTOSAR metamodel : Splitables

AUTOSAR is being well known for its efforts to standardize the basic software of the ECUs. In addition it strives to improve the workflow of software development by defining a standard exchange format for the SW-relevant aspects of ECU development. While the actual exchange format is xml-based, AUTOSAR defines the meta-model with UML (the xml schema for the exchange format is derived from that). Although the standard can be used only by AUTOSAR members in certain domain, the metamodel has concepts that can be of interest to anyone in modeling.


Some of the metamodel concepts are motivated by the workflow that is used in automotive. A full AUTOSAR system description will be made up by artifacts from a number of sources: different departments of the OEMs and suppliers. An AUTOSAR model will be huge – no one would want to handle a definition for a complex ECU in one file. AUTOSAR must make sure that those parts are correctly assembled and therefore define a common approach for splitting and assembling models. To understand the splitting, it is first necessary to understand how AUTOSAR handles references between objects.

References: by UID or by name?

In modeling, there are two major approaches for storing references between model objects. With the UID approach, each referenceable object has a unique id which is used for references. Often this UID is some kind of cryptic string. Any attribute that is the object name is not used for resolving references.


In the referencing by name, there is no such id. Objects reference each other by using their name, or by using a fully qualified name which would be the concatenation of all the object’s parents’ name.

Both approaches have their pros and cons. with the GUID approach, the references are more resilient to name changes. However, to build a reference, you need to know the GUID. Using name references supports a more flexible way of assembling models. E.g. your SW-component might reference some other component /AUTOSAR/somepackage/otherc. You can then still use your component in different combinations of xml files, where in one combination otherc is the real thing, and in another otherc will be some mockup. To do that with guids, both othercs must have the same GUID, which contradicts the very definition of unique.

So references in AUTOSAR exchange files are actually specified by the fully qualified name of the referenced object.

So the splitting of a model into several files is in the very heart of AUTOSAR. To allow for exchange, it is also necessary to specify how models could be split. Obviously, it would not be enough to just split on the top level. So being able to merge the contents of a package from several files would be an idea. But AUTOSAR does not stop here. It generalizes the concept of splitable and allows splitting the content of many associations in the metamodel. Which associations can actually split over more than one file is indicated by the stereotype atpsplittable on the association.

More details are found in AUTOSAR’s generic structure document. Here is some examples from that document:


An example for a merged model

The concept of splitable is quite powerful and useful. However, it is a specific feature that has not really been foreseen in existing modeling frameworks – so there are some additional efforts when implementing splitables.

In EMF (which is used by Artop), mode, objects are contained in resources. One .arxml file corresponds to one resource and the set of resources (resource set) make up the AUTOSAR model. However, in EMF, all the elements in a composition relationship are contained in the same resource. EMF does not support e.g. elements of an AUTOSAR package in different files. Obviously, there are additional concepts in the tools that tool providers need to design and implement.

The first idea could by to extend emf in such a way that the model loader merges the model and for each model element keeps track of where it is support to be stored. Then the serializer would need to split up the files when saving. This would have some conceptual difficulties and also would probably require quite some rewrite of the implementation.

Looking at the Reqif standard, there is another idea. in reqif, the model hierarchy of requirements is not built by compositions. Instead, all requirements are flat in a resource and structured by a submodel, the specification hierarchy, which contains references to the requirements objects. So an idea could be to actually not implement AUTOSAR compositions as emf containment references, but as simple references and keep the referenced objects in their original resource. However this would result in more major changes, since it is again the structure of the AUTOSAR xml files and they could not directly be used.

In artop there is a third solution. It keeps the emf model structure close to the AUTOSAR exchange files and provides an API to access the model that presents to the user of that API a view on the model where the Splitables are merged. This is done with the technology of the Java proxies, a mechanism of java reflection. Here, the calls to the objects methods are intercepted and access to associations that are modified so that the merged result of the splitable is returned to the user:

It seems necessary that the model is queried top down in order to resolve nested splitable associations. If you are implementing AUTOSAR tooling based on Artop, I recommend studying this API early on to be able to assess its impact on your tooling both in terms of performance and tool architecture. It might be harder to adapt your application later on than to work with the API from an early phase.

In addition to the pure model view, the splitable concept also requires to think about your user interface. When the user creates new model elements for a splitable relationship, how does he specify in which resource/arxml the new element should be persisted? Surely you don’t want to clutter your user interface with resource information for each element or association, since not all of that info might be relevant to your user each and every time.

AUTOSAR splitables are a powerful mechanism to structure arxml files. You should be aware of the concept early on. It allows great flexibility, but also requires more effort.