Considering Agile for your tool chain development

Developing and integrating complex toolchains in automotive companies is a challenging task. A number of those challenges is directly addressed by the principles behind the “Agile Manifesto”. So it is worth while to see what “Agile” has to offer for these, independent of a specific framework (SCRUM, Kanban, …)

Keeping the (internal) customer happy

Tool departments and ECU development projects often have a special kind of relationship. Often, the ECU projects feel that the tooling they are being provided with do not fulfill their requirements with respect to functionality, availability or support. They are often in very different organizational units.

Principles behind the Agile Manifesto
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
So if agile lives up to its promises (and is correctly implemented!), then this should address these issues.

Dealing with a changing environment

For any project that is not short-term, your environment (and thus your requirements) is sure to change. Especially tooling for new technologies (like AUTOSAR Ethernet, Autonomous Driving, etc.) involve a lot of feedback loops based on experience in the project. And opportunity for change is abundant in addition to that:

  • Your customer’s timeline. The ECU needs to be finished earlier, later, not at all, wait – now it’s at the original schedule
  • Shifting priorities in functionality needed by the customer
  • Availability of new technologies: We have seen planned work packages turned completely redundant by the same functionality having become available in open source.

 

Principles behind the Agile Manifesto
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Getting customer committment

In some settings, a tool or tool chain is being discussed with the customer, then implemented independently by a team and provided to the customer upon completion, only to find the customer frustrated by what he has been delivered. This might lead to finger-pointing and dissatisfaction. A good way to get customer commitment is by integrating them into the development and be able to get early feedback and improvement suggestions. Because then it is “our” tool, not “their” tool. And everybody likes “our” tool more than “their” tool.

 

Principles behind the Agile Manifesto
Business people and developers must work
together daily throughout the project.
.

Agile is not simple

Agile methodologies and frameworks address some of the typical challenges of tool departments. However, “Agile” is no panacea and it doing it right is not necessarily an easy task. It forces change and it needs management support – otherwise you might just spin the buzzwords. But for many projects it is well worth the journey.

 

 

 

 

Integrating Rhapsody in your AUTOSAR toolchain

UML tools such as Enterprise Architect or Rhapsody (and others) are well established in the software development process. Sometimes the modeling guidelines are following a custom modelling, e.g. with specific profiles. So when you are modelling for AUTOSAR systems, at sometimes you are faced with the problem of transforming your model to AUTOSAR.

For customer projects, we have analyzed/implemented different stratgies.

Artop as a integration tool

First of all, if you are transforming to AUTOSAR, the recommendation is to transform to an Artop model and let Artop do all the serialization. Directly creating the AUTOSAR-XML (.arxml) is cumbersome, error-prone and generally “not-fun”.

Getting data out: Files or API

To access the data in Rhapsody, you could either read the stored files or access the data through the API of Rhapsody. This post describes aspects of the second approach.

Scenario 1: Accessing directly without intermediate storage

In this scenario, the transformation uses the “live” data from a running Rhapsody as data source. Rhapsody provides a Java based API (basically a wrapper to Windows COM-API). So it is very easy to write a transformation from “Rhapsody-Java” to “Artop-Java”. A recommended technology would be the open source Xtend language, since it provides a lot of useful features for that use case (see a description in this blog post).

Scenario 2: Storing the data from Rhapsody locally, transforming from that local representation

In this scenario, the data from Rhapsody is being extracted via the Java-API and stored locally. Further transformation steps can work on that stored copy. A feasible approach is to store the copied data in EMF. With reflection and other approaches, you can create the required .ecore-definitions from the Rhapsody provided Java classes. After that, you can also use transformation technologies that require an .ecore-definition as a basis for the transformation (but you can still use Xtend). The stored data will be very close to the Rhapsody representation of UML.

Scenario 3: Storing the data in “Eclipse UML” ecore, transforming from that local representation

In this scenario, the data is stored in the format of the Eclipse provided UML .ecore files, which represent a UML meta-model that is true to the standard. That means that your outgoing transformation would be more conforming to the standard UML meta-model and you could use other integrations that use that meta-model. However, you would have to map to that UML meta-model first.

There are several technical approaches to that. You can even to the conversion “on-the-fly”, implementing a variant of Scenario 1 with on-the-fly conversion.

 Technology as Open Source

The base technologies for the scenarios are available as open source / community source:

  • Eclipse EMF
  • Eclipse Xtend, Qvto (or other transformation languages)
  • Artop (available to AUTOSAR members)