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.

2015-04-01_22h30_31

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.

 

 

Augmenting UML with textual DSLs

Funded by the BMBF

For the IMES research project we are investigating introducing more formal notations in the requirements specification of automotive software systems. We are currently in an early stage where we define the criteria that the notations should fulfill for several artifacts in the software development process. One of those stages will be the definition of more formal notations for functional nets. To show a prototyping scenario, I am using UML (classes with ports) as model elements for functions and use Papyrus and Xtext to show how to adapt the tool to specify timing constraints with formal notations.

The Papyrus team has been using the Xtext integration to create a nice user interface for UML modeling. My scenario differs a little bit in that I am not using Xtext to edit parts of the UML model (like transition labels, property definitions etc.) but I augment the UML with additional models. The screenshot shows a domain specific language for the definition of timing constraints of a Port, with full syntax highlighting, error detection. As you can see in the screenshot, the content assist is fully aware of the UML model, suggesting a list of ports that could be peers of the selected port.

Integration of the Xtext editor took about 4 hours, mostly related to the fact that there is a tutorial by the Papyrus team that is very good for the first half. But then I needed some serious debugging to find about the inner workings. But if you have done it once, integration of such a grammar is very fast.

Right now the timing constraints are simply stored as text in a UML-Comment that belongs to the port as plain text. This makes code generation and model validation a little inconvenient, but I already have an idea in my mind on how to use a resource set that would make life simpler.

All in all, it is great fun extending the Papyrus tool and impressive what nice features you can implement with Eclipse based tooling in very short time!

Xtext 1.0.0 and UML (Xpand on top)

Several projects combine textual DSLs with Xtext with UML models and there have been some postings (by Sven, Holger and others) on how to achieve this with earlier versions of Xtext. This is a short sketch on how to do it with the latest version. If you do not now what this is about, have a look at the screenshot on the left: The Xtext grammar references a UML model with an Activity and two classes. This is fully integrated you see that content assist suggest the elements from the UML model.

The biggest difference is the need for IResourceProviders for UML. Xtext comes with a IResourceProvider for EMF models, and this can be used for writing an UML version. I added three new files to the Xtext project: UmlResourceDescriptionManager.java and UMLResourceServiceProviderImpl.java UMLResourceDescription.java . The former two are very simple: UMLResourceServiceProviderImpl.java only binds the .uml extension.

This is a very basic implemenation of a UML Resource Description: It returns all “NamedElements” from the UML model.  The functionality could be extended to different purposes, but this does the job right now.

The grammar of our languages is pretty ssimple. Nothing new compared to earlier releases:

As in the other tutorials, you should copy the relevant-meta-models into your project. However, there’s a lot of changes in the work flow. Have a look at this work flow to see how to adapt it to UML:

In the Manifest, the Resource Provider has to be made known through an extension. If you add org.eclipse.uml2.codegen.ecore, org.eclipse.uml2.uml and org.eclipse.xtext.ecore you are ready to go and create and run a grammar references to UML. However, if you want to also use code generation, this is a good time to modify the StandaloneSetup.java class:
package de.itemis.graf;

At this point, you can run the editor, create a UML model and reference the model elements from within your Xtext model.

On top, if you want to process this with Xpand, here is the work flow:

And here an example of a template:
Enjoy combining your DSLs with UML.

Installing Trufun UML Plato Free Edition

Last year I had already mentioned a free chinese UML tool in articles etc. I think it could be worthwhile investigating. However, since the website is all in Chinese, finding and downloading it is a problem for most Western people. Which is a pity, since the tool itself has both a Chinese and an English user interface.

The Home Page of Trufun is www.trufun.net , downloads are at http://www.trufun.net/www1/Ch/Downlist.asp The tools are based on Eclipse 3.5 (Galileo), but I just installed the Update-Version in Helios and it seems to run fine. Download http://download.trufun.net/uml/x/Plato-Free-Plugins-X-V3.0.zip and extract it into your Eclipse installation.

After starting your Eclipse, you are asked to update to the latest version. Don’t do this, this didn’t work on my installation. You can create new models with New->Other->Trufun UML Modeling.

Trufun stores its models as .tmx, which is a variant of uml2tools’ .uml format and can be converted with some tricks, so you can use Xpand etc. to use Xpand, Acceleo and other tools on the model. I will write about that in a later post.

Modeling Tool Usability Checklist – Element Deletion

Working with modeling tools that provide different views on the same model (like UML with diagrams) can be an interesting experience. The relationship between model and views introduces some challenges for usability, which is addressed differently by tools. These aspects can easily confuse those that do their first steps in modeling and annoy those that work with several tools. I suggest that you might want to have some checklist for your tool for quick reference to navigate these quirks. In a number of blog posts, I will propose and explain this checklist.

For illustration, I am working with Papyrus/MDT. Papyrus at the time of writing is available in version 0.7.0. Usability might change, but Papyrus is only used to illustrate the checklist, not to comment on the tool itself.

Checklist: In your tool, what commands are used for local deletion (in diagram) and from model.

Assume we have a small UML model with three classes, RainSensor, RainSensor Variant and SunRoof in two diagrams A and B.

Diagram A

Diagram A

Diagram B

Diagram B

It is important to remember, that diagrams are only views on the model. The actual model can be seen in the tree view. Obviously we should only find one RainSensor in the model.

Model Viewer

Diagrams are views on the model.  This has a view implications on usability. If we have a look on the context menu of Papyrus, we see two commands for deletion:

Deletion Commands

These two kinds of deletion commands can be found with all kinds of different naming conventions in graphical modeling tools. 2) will remove the symbol from the diagram without modifying the model. 1) will actually remove the model element. If you try 2), the model will not be changed. However, this is how the screenshots change after you choose 1): Since the model element has been deleted, its symbol is removed from Diagram B.

Don’t confuse the two, you might accidentally remove elements. It would be great if your tool had functionality to show you the impact of a deletion (the impact of any change would even be better).

Model elements can also be deleted by using the pop-up from the tree view:

Checklist: Check the semantics of Undo

If you try the above in any of your tools, try the undo function as well and see what your tool does. If you try the steps above and use undo after deleting from within the diagram, you will get the following results:

and, unexpectedly:

This tool does not undo any side effect a change has on other diagrams! Be sure to check the semantics of undo, to make sure you do not loose any data.

Checklist: Changes on closed diagrams

If you close the diagram (i.e. it is not open for editing), changes can have a different semantics. Again, deleting the model element RainSensor from within Diagram A, but having closed Diagram B results in the expected deletion of the model element. This is how B looks after opening it again:

Suddenly, there is an element “model” in there? What happened? Tools that do not actively update closed diagrams when the model changes, have to check the consistency of diagram and model upon opening. This specific tool seems to follow the strategy to replace references to non existing model elements with references to others. Check what your tool does!

Checklist: Collaboration

Several people working on one model at the same time opens another can of worms. Without going into detail: Check how deletions by one person are propagated throughout the system.

Checklist: Find unreferenced elements

You can easily imagine, that you might delete an element from the diagram, actually forgetting about it. But it is still there in the model. Does your tool have functionality to find unreferenced elements? You wouldn’t want to browse through all the diagrams just to find the unused items.

The next post on the topic will be on element renaming.