Introduction

Lately a lot of automotive companies reach out to us for help with their development. Mostly their problem is that in spite of all the (expensive!) tools they use, they still have trouble getting all development done correctly, in-time and thoroughly tested.
I understand that, you can use several AUTOSAR Tools, you can use Simulink or ASCET or TargetLink or whatever, most of these tools do not solve your problems with, amongst others, complexity, timing and architecture.

With AUTOSAR you are able to develop very distributed. That is a big advantage but at the same time also the main problem with it.

Using AUTOSAR does not automatically mean you are using modeling, also modeling does not equal modeling. Using Simulink is completely different from using Rhapsody or another UML modeling tool.

This week I was in Noordwijk together with Clemens to define and implement some of our AUTOSAR/Rhapsody solutions.

How hard can it be?

As the famous Jeremy Clarkson always says when he and his former Top gear, now the Grand Tour, mates are doing something that is nearly impossible: “How hard can it be”.
I can tell you one thing: making software for cars is hard. Very hard.
In my opinion, cars are the most complex thing people build. Not planes or rockets ( The expression, “It’s not rocket science” should actually be: “it’s not automotive software”, IMHO )
Parts of that complexity stems from the fact that the Automotive sector suffers from a drastic price policy. If their purchase department can purchase a CPU that is €0,20 cheaper, they will do that, regardless of the fact that this can skyrocket the effort of building software. Well maybe it’s not that drastic but this is closer than what the Aerospace people do, they only use certified CPU’s. What they cost is pretty irrelevant, you never notice it on the price of a plane and they will only build a limited number of planes, not millions like car ECUs.
Other reasons for complexity is the environment of a car. Planes can fly and therefore already solve the problem of having millions of moving obstacles on their path. Air Control tell te plane where to go, how fast and how high. Makes things much more easy.
So the reason is this complexity, that will only be more now we are implementing autonomous driving.

UML or SysML?

The solution “du Jour” for this is now to use System Engineering or SysML (System Modeling Language) Is this better than UML? That is not a statement that you can make. It depends on what you are doing. I noticed lately that most people ask for SysML but they almost all end up with making software anyway, not systems. That does not mean that you should not use SysML but there are things in SysML that are different. Plus that you have “yet another Tool” and “yet another language” to learn.
So if you can be sure that no-one from any other department than the software guys will use SysML: choose UML. You can also mix SysML and UML (Even for Software development, we are embedded so in the end we always do some systems engineering as well.) The disadvantage is that you often have to do things double. Or put effort in model transformation or intelligent “helpers” that convert and link your model elements. (e.g. like the Harmony profile does)
But OK… since the UML has (still) not reached the critical mass in users, I gladly accept SysML (Which is nothing more than a UML profile) as the UML savior.

Multiple captains on one ship

That’s one of the problems with the mult-tool approach. It is generally a good idea to use the right tool for the right task. Unfortunately all tools think that they are capable of doing everything, which they are most definitely not. It’s like having 2 or more captains on a ship shouting contradictory commands.
The only way to use multiple tools where you have development information that is used in different tools is when you:

• use automatic synchronisation.
• use a tool that help you connect the information
• use a very rigorous process that tells you where the information is created, kept, supplemented and changed.
• Automate as much as possible

AUTOMOTIVE Spice

There is, luckily a process that you can use for development. This is a big help in defining your artefacts and how to store and process them.
Not really easy to implement but hey: we do complex stuff, this is never going to be easy. I could write a book about this but I won’t. Not here. You can read all about Aspice here.

Rhapsody can do AUTOSAR, can’t it?

Exactly. It can. You can load an AUTOSAR profile (Most AUTOSAR Versions are available) and then you can import and export ARXML files. You are no longer using UML, you use AUTOSAR. And you can model it, draw diagrams, make connections add AUTOSAR artefacts. You can even use UML State-machines you first have to create a so-called RIMBO (Rhapsody Implementation Block) and connect that to all AUTOSAR connectors.

You have to consider a few things. The ARXML import/export is using Java and uses a lot of memory. It turns out that Rhapsody 64-Bit is really much faster when importing or exporting ARXML. If you use Rhapsody 8.3 you’re OK, you can use the 64-Bit. For older versions you can still install the 64-Bit version just for import and export and do the modeling in the 32-Bit version.

If this is the solution, I want my problem back

This is not always the most optimal solution. In my opinion people want to use a UML/SysML tool because they want to use UML/SysML. And that is what you can do. The Willert Automotive Profile for Rhapsody delivers you the possibility to implement other use-cases with Rhapsody. You can use Rhapsody to:

• implement functionality that uses state-machines and/or Activity diagrams with Code generation. The Automotive RXF is small and fast and will be called in your system in the form of 2 runnables. The names are imported from an ARXML file that you create with another AUTOSAR tool like ArcCore or so.
• You can also model your AUTOSAR application in UML in Rhapsody, the stereotyped model elements can then be exported as ARXML and used in other AUTOSAR tools.
• We have defined a base model that includes many Automotive modeling examples, that shows a lot of modeling best-practices and already some very useful helpers.

There are some limitations to using this, not everything is possible (yet). We are working on automatically generating code for communication between runnables (Sender/Receiver ports) You can do this by hand now, however.

OK, we also walked on the beach, drank a few beers in a beach club but we worked very hard on the Willert Modeling for Automotive Solution! In one of my next BLOG entries I will take you through a complete automotive example.

Happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)