Introduction

AUTOSAR is the standard created to support software development in automotive environments.
Why is there a special standard for that? Is software for cars special?
No, the software itself is not, it’s just plain ‘C’ (lately also ‘C++’) But the circumstances are different.
Are there special Tools for that? Yes there are. Wouldn’t it be nice to just use the normal Development Tools? YES Of Course!
Willert has all these tools and the add-ons necessary to use them in an AUTOSAR environment!

Differences

  • Timing is critical, in more than one way.
    There is the timing in the software itself, which is still critical although CPU performance increased severely last years. This is partly because most software in cars is “polled”. Due to the fact that there are algorithms in cars where developers use Simulink (and code generation in TargetLink and/or Embedded Code) that is “control loop software”, so does stuff every 10 milliseconds.
    That is OK, it works but your software is ALWAYS doing “something”. And while different paths through your code are taken (with different execution times) this is difficult to manage.
    Then there is the timing in the release of cars. That is different than most projects…. A cars introduction and production is planned years ahead and there is NO DELAY possible. Period. You can easier shift the timing of a solar eclipse that the intro of a car. So software development cycles must be predictable (they aren’t but they must be….)
  • Cooperation not only between colleagues but worldwide between multiple companies.
    Yes. Cars are defined by OEM’s, parts are made by Tier 1,2,3 etc by companies that have developers everywhere over the world.
    The environment supports exchanging information on buts and bytes and, for all, the possibility to exchange pieces of software built by one company for other pieces. AUTOSAR (ARXML) makes this possible.

How can Rhapsody help?

That is not too difficult. Rhapsody has the AUTOSAR Profile. This allows you to read-in ARXML files and make them visible, graphically, in Rhapsody.

AUTOSAR Menu


You can also edit the AUTOSAR model in Rhapsody. Or even create it there and export what you’ve mad to an ARXML file that can be read by an AUTOSAR Authoring Tool like e.g. DaVinci.

AUTOSAR Importer

Here you can import any ARXML file. Rhapsody will import it (Remember: Use the 64Bit version to import, 32Bit is way too slow)

Rhapsody AUTOSAR model

Another possibility to fill your AUTOSAR model is by using plain SysML or UML with the simplified AUTOSAR profile. This gives you stereotypes for the most used AUTOSAR elements. The M2M Tool will then synchronize your 2 views, the AUTOSAR view and the SysML/UML View.

M2M Workflow

In this way your models will always be up-to-date, wherever you make your changes.
The second step to use Rhapsody is then to generate code that can directly be used inside your AUTOSAR environment!

This picture shows the workflow. Mixing this with other tools like Simulink (even with co-simulation) is no problem!

The AUTOSAR Workflow

Reverse Engineering

This allows you to use the code from your AUTOSAR Tool (Basic Software and other RTE functions) in your Rhapsody state-machines or functions.
In contrast to the previous Rhapsody Workflow (RIMBO and then link your Rhapsody App in the AUTOSAR code) this is the much easier way: Just use a few stereotypes and you can use the Rhapsody Code you already know (If you’ve used Rhapsody for non-Automotive environments) in an AUTOSAR environment.

Contact me if you need more information. I can arrange an evaluation version!

Happy driving with Rhapsody!

Walter van der Heiden (wvdheiden@sodiuswillert.com)