Pragmatic AUTOSAR

Martin Thiede |

AUTOSAR on a Grand Scale

About five years ago; a team set out to build one of the most complex automotive Electronic Control Units (ECU) at that time following the AUTOSAR standard. Being the software architect of this challenging project, I soon realized that the tools we had at hand were not sufficient for the job: We had to describe a massive system consisting of around 100 software components with their interfaces exchanging around 2000 different data items. This process involved automotive function experts and developers creating, reviewing and changing the description of the software components.

The most critical point was that the tools available to us practically implied that there could be only one person changing the overall description (aka. “model”) at a time. That was mainly because the tool didn’t provide any merge support for models and that its XML-based storage format also didn’t allow manual merging on file level. The tool and the person controlling it was a massive bottleneck. This inevitably led to the domain experts looking for ways to bypass the bottleneck. They started to write down their interfaces, i.e. the most important part of the overall model, in a self-made way in a text file or spreadsheet. While discussing with their counterparts, they were sending these files around by mail and finally communicated this information to the “modeler” who entered it into the modeling tool. When there was a mistake or misunderstanding, there was no easy way for the expert to compare different versions, to roll back to an old version or just to quickly fix a typo. As a result, the turnaround time for model changes was very long and the overall process significantly ineffective.

Models treated like Code

One way to solve this issue would have been to improve the elicitation process. This would have meant increasing the processing overhead, e.g. by using more formal, standardized spreadsheets, defining deadlines for the interfaces of single components, setting up meetings for interface consolidation, etc. Instead, we chose to improve the tooling. We made sure that the people working with models could use most of the practices well proven in software development:

  • every developer/modeler has a copy of the tool (like the compiler toolchain)
  • models are checked into a version control system, just as code
  • models can be compared, rolled back and merged and there can be tags and branches
  • every modeler can change the model at any time but is entirely responsible for the correctness of the modification and the consistency of the overall model
  • model consistency is enforced by a set of checks built into the modeling tool, every modeler runs the checks before each commit (taking around 1 min)
  • the task of the software architect is to define general architectural guidelines and to monitor and/or enforce them using the modeling tool

The tool we built to fulfill these requirements was a lightweight command line tool which read in plain text files following our Domain Specific Language (DSL). In contrast to the XML formats used by the other tools we looked at, this textual language could be read, compared and merged much more easily and only focuses on the relevant pieces of information. Looking back, we can say that this approach was not only helpful during initial model setup but also proved very useful during the following years of software development:

  • models and code are now kept in the same repository
  • the structure of the model files in the file system resembles the structure of the code, e.g. model and code are kept in the same software component directory
  • it allows for changes to model and code in one atomic repository commit, i.e. developers can add features in a concise and consistent way
  • it makes it easy to go back to older branches to fix bugs and merge bug fixes into other branches, or to remove unwanted features entirely
  • using a continuous build system, both code and model problems can be detected and tracked back to the original author automatically

Full AUTOSAR support

We found that this approach was useful for almost all the AUTOSAR projects we were involved in. Nevertheless, the original simplistic approach needed some tuning. The problem was that the definition of “relevant information” which made up the model varied across different projects and customers. So with every new feature request, the once straightforward and pragmatic textual language grew larger and more complex. At the same time, we were putting more and more effort into extending the tool, just to get closer and closer to the official AUTOSAR language which forms the natural boundary for such feature requests. So finally we decided to support the complete set of official AUTOSAR commands and thus be fully AUTOSAR compliant on the modeling language. Using a generic syntax for the textual language and importing the language commands from the machine readable description published by AUTOSAR (AUTOSAR Metamodel) this also made our tool implementation much simpler. With the new approach, any AUTOSAR model conforming to the AUTOSAR XML schema could be transformed into the simplified textual syntax. After editing the model in the text files, it could be converted back into valid AUTOSAR XML. Although the textual language provides the full set of possible commands, it already yields a vast improvement in conciseness and readability. Here is an example software component implementing two interfaces (one for input and one for output), expressed in both AUTOSAR XML and the textual syntax. Each representation can be transformed into the other without any loss of information.

Example: AUTOSAR XML

 <AUTOSAR xmlns:xsi="..." xsi:schemaLocation="..." xmlns="http://autosar.org/3.1.4">
   <TOP-LEVEL-PACKAGES>
   <AR-PACKAGE>
    <SHORT-NAME>Components</SHORT-NAME>
    <ELEMENTS>
     <APPLICATION-SOFTWARE-COMPONENT-TYPE>
      <SHORT-NAME>WiperController</SHORT-NAME>
      <PORTS>
       <P-PORT-PROTOTYPE>
        <SHORT-NAME>userInput</SHORT-NAME>
        <DESC>
         <L-2 L="FOR-ALL">user input commands</L-2>
        </DESC>
        <PROVIDED-INTERFACE-TREF DEST="CLIENT-SERVER-INTERFACE">/Interfaces/IWiperUserInput</PROVIDED-INTERFACE-TREF>
       </P-PORT-PROTOTYPE>
       <R-PORT-PROTOTYPE>
        <SHORT-NAME>hwControl</SHORT-NAME>
        <DESC>
         <L-2 L="FOR-ALL">control the wiper hardware</L-2>
        </DESC>
        <REQUIRED-INTERFACE-TREF DEST="CLIENT-SERVER-INTERFACE">/Interfaces/IWiperHwControl</REQUIRED-INTERFACE-TREF>
       </R-PORT-PROTOTYPE>
      </PORTS>
     </APPLICATION-SOFTWARE-COMPONENT-TYPE>
    </ELEMENTS>
   </AR-PACKAGE>
  </TOP-LEVEL-PACKAGES>
 </AUTOSAR>

Example: Plain Text

 AUTOSAR {
  ARPackage Components {
   ApplicationSoftwareComponentType WiperController {
    # user input commands
    PPortPrototype userInput, requiredInterface: /Interfaces/IWiperUserInput
    # control the wiper hardware
    RPortPrototype hwControl, providedInterface: /Interfaces/IWiperHwControl
   }
  }
 }

There is more to come

The basic concept of transforming AUTOSAR XML into a much more human-readable syntax and back is already very useful. But we can do much better: There are a number of tools and concepts we think will further boost AUTOSAR modeling efficiency in the future:

  • Model Macros. Simplify the textual syntax even more and encourage (project specific) modeling patterns
  • Editor Plugins. Plugins for Eclipse and other editors adding syntax highlighting, auto completion, online constraint checking, easy model navigation and more
  • Non-Text Browsers and Editors. A textual syntax is fine for many use cases. But there are also cases where a graphical or table-based tool is better suited. One example is inter-component connectors. The full power is unleashed when both kinds of tools work together seamlessly.

We will address these advanced topics in future articles, and we also plan to provide some insights into the technology behind.

More stories

Android Transporter for the Nexus 7 and the Raspberry Pi

Daniel Himmelein |
The Android Transporter allows you to share the display contents of your Nexus 7 tablet wirelessly with other screens in real time. Now, the first tech demo of the Android Transporter is out!
Read more

Use SFINAE to unit test inheritance

Matthias Kessler |
Check out our software engineer Matthias exploring the use of SFINAE for unit testing inheritance.
Read more
  • Munich Office
    • Balanstraße 73
    • Haus 10, 3.OG
    • 81541 München
  • Kulmbach Office
    • Langgasse 15
    • 95326 Kulmbach
  • Phone
    • +49 176 13770077
  • Email
    • contact@esrlabs.com
  • Imprint
    • Privacy Policy © 2017
    • E.S.R.Labs AG
    • All rights reserved