Introduction

This BLOG is named “AUTOSAR,” the title is “What is AUTOSAR,” it should be clear what this will be about then.

Well… not entirely. If you want to know more about AUTOSAR, there are thousands of websites and books that tell you precisely what AUTOSAR is.

So it would be, at least, overkill to start writing all this again. It’s like recording yet another version of “Yesterday” by The Beatles. It has been done enough, the chance that my version will add is close to zero.

AUTOSAR consist of (when printed on standard paper) more than 2 meters of documentation (7 feet for my imperial friends). That should be enough, and I will not do anything about that.

OK, then what is the purpose of this BLOG? I want to write about using AUTOSAR in the context of UML and SysML modeling. How can you combine that? How can modeling benefit from AUTOSAR and vice-versa?

What do I think is AUTOSAR?

I think AUTOSAR is the logical consequence of many companies working together (or against each other) for decades in a vast industry where safety (and security) are increasing issues and where complexity is going through the roof.
AUTOSAR attempts to structure the cooperation between car manufacturers OEM), ECU manufacturers (TierX), software companies, and more.
It is also an attempt to make software (and hardware!) companies interchangeable by structuring the data exchange between the TierX and the OEM.

The key to this is abstraction and standardization. There is always a price to be paid for that: performance and memory. This price is also the case in the AUTOSAR world. The already strained ECU’s were mainly not capable enough to run the extra stacks and layers needed for AUTOSAR. MCAL (Micro-Controller Abstraction Layer), BSW (Basic SoftWare), Virtual Bus are all very useful, and all help making software development better, but they all cost extra CPU performance.

Another great feature is the exchange format ARXML (AUTOSAR XML) that helps in exchanging information (without the need of opening source code with valuable algorithms)

The 2 AUTOSARs

AUTOSAR comes in two distinct colors, Classic and Adaptive.
Just to be sure: “No”, Adaptive is not Classic++, it is entirely different (But still has comparable features) targeted to large ECU’s like in newer cars.

Feature	Classic ( CP )	Adaptive ( AP )
Language	C (Actually also C++ but nobody uses that)	C++
OS	Static generated RTE on bare metal	Linux (POSIX)
Platform	small 8b, 16b, 32b	large 32b, 64b
Architecture	Polled	asynchronous
Target	Small Embedded	HiPower

AUTOSAR Modeling

There are also plenty of tools to do direct AUTOSAR modeling.
The Metamodel was, in fact, made with Enterprise Architect.
But the AUTOSAR modeling is different from UML or SysML; it is more optimized for writing code.
IBM’s Rhapsody has always been strong on doing modeling in UML and SysML but also on connecting to other development streams like Code, Requirements, Tests, Quality, Workflow, etc.
That is why this BLOG is there to write about using multiple models (multiple Views) and smartly combine them to give your development team the exact information when it’s needed (Just In Time!!)

Coming soon to a computer near you

We are rolling out our Rhapsody Add-Ons, M2M (Model to Model), and the ARXF (Code Generation from UML for AUTOSAR) as we speak.
Where M2M is useable in the Classic and the Adaptive platform, ARXF is only for the Classic platform, but we are working franticly to do the ARXF for Adaptive. We will release that later this year.

Happy driving with AUTOSAR modeled by Rhapsody!

Walter van der Heiden ( wvdheiden@sodiuswillert.com )