Pragmatic AUTOSAR

AUTOSAR defines a common standard for automotive software. One part of it is a language for describing software components, their interfaces, their composition to a larger system and many other details required in order to build a complete system. In this article I will outline the challenges we faced during our first large AUTOSAR project, our initial pragmatic solution, its evolution while we gained experience and an outlook on future tools and concepts we imagine.

AUTOSAR on a Grand Scale

About 5 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 huge 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. This was mainly due to the fact that 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 greatly 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 process 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 fully responsible for the correctness of the change 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 own 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 was focused on the relevant pieces of information only. 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. Nethertheless, 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 simple 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 with respect to 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 transformed back into valid AUTOSAR XML. Although the textual language provides the full set of possible commands, it already yields a great 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 usecases, but there are also cases where a graphical or table based tool is better suited. One example are 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.  

ShareTweet about this on TwitterShare on Google+
  • Pradeep Singh

    Hi Martin,

    Great article. Thanks for posting.
    I’m also an automotive software professional currently working in Lear Corporation, India. We are using similar approach to create RTE signals. Each developer does changes in the textual file and then using a command line based tool we generate corresponding arxml files.
    I’m very eager to learn how to make a particular project 100% AUTOSAR compliant.Most of the projects i see have only the RTE and Application layer as AUTOSAR compliant.
    But i’ve heard that one can make enitre BSW AUTOSAR compliant (inlcuding MCAL,ECUAL,Service layer).
    It would be interesting to know regarding how to make BSW autosar compliant.
    Looking after your similar posts regarding AUTOSAR .

    Regards,
    Pradeep Singh