Introduction
This is a small excerpt of my presentation at the IBM IoT CE Conference in Munich from may 14-16. A very nice conference, if you were not there: you missed out!
The Challenge
I might have said it before, cars are the most complex thing people build. Even more complex than planes. I “borrowed” a slide from Debby Edwards Keynote from the conference. That clearly shows it.
The F35 (JSF) plane has about 25 million lines of code, a modern high-end car 100 million. OK, there are trade-offs, like do you add multi-media systems or is a passenger plane more complex but the general idea is just: making cars is an immensely complex process. But look at a random big city during rush-hour and you see: The Automotive Industry still manages to make cars that work with a remarkable reliability.
Not always, we all know examples from cars that have huge electronic problems (I can tell some stories about that myself…)
No why is a car more complex than a plane? Well, part of the complexity is self-inflicted. Compare this:
- Car > 1.000.000 pcs < EUR 100.000,-
- Plane < 1.000 pcs. > EUR 100.000.000,-
this says it all, cars are mass products that are cheap (relatively to planes…) and planes are almost built-to-order products that are expensive.
A plane manufacturer does not bother the price of a micro-controller, they have a small number of certified ones that they choose from. If it costs EUR 2,50 or EUR 2,80 does not really bother him.
Now the car manufacturer is interested. If they can use a CPU that costs only EUR 0,10 less than another one for a device that is in a car (or even multiple times in a car) than the calculation looks different. 1.000.000,- * EUR 0,10 is already EUR 100.000,-
So mostly they choose small Microcontroller that barely fulfill the needs of their developers, adding to the complexity.
Mastering complexity: Process
One of the things you can do to master complexity, certainly if you are not changing the tool environment.
The Automotive industry has a process, Automotive Spice or short A-Spice. A thorough and already more than 10 years old process that is a big help in mastering complexity. Of course A-Spice does more than just helping to master complexity, but that is not in my focus now.
The process helps you to define what needs to be done in what stage of the development. So every item is defined and there is a definition of what should be in there. This helps engineers to gather information and present it in the right way to their colleagues so the development information is always up-to-date.
This process can be followed by hand, of course, but this is so error-prone that I strongly advise to use tools. We discuss later what tools and how.
Also mastering Complexity: Abstraction
The way to master complexity is the use of patterns (or abstraction). Abstraction can be explained by looking at this bunch of matches. If you need to count them, sorted like that, it is not that easy. So you sort them in groups, that makes it much easier to count. That is abstraction, you just follow the pattern and it makes it much easier. The disadvantage of this is: space/time drawbacks. You see that the matches take up more space if they are close together then when they are sorted.
the same applies for patterns in software, they help you solve complex things but also at a price. The fact that the pattern is universally applicable creates overhead.
Not mastering Complexity: AUTOSAR
The Automotive industry created AUTOSAR with a couple of goals in their minds. They wanted to make it easier to switch suppliers by letting them use a standard interface, they wanted to have multiple suppliers that develop applications on a single controller without having to know each other and be able to slip applications over multiple ECU’s without redesigning the complete application.
The extra data in AUTOSAR applications is stored in XML files called ARXML. This can be parsed and imported and tools can in that way exchange information in a standard way. That sounds fantastic but in praxis the advantages are limited, no one wants to share more information that absolutely necessary with others from a competitive standpoint.
AUTOSAR uses abstraction, they have standard software layers (Basic Software) that implements a lot of basic stuff. This will solve some pain but also introduces new complexity, the Basic Software layers are not easy to use.
AUTOSAR uses a Run-Time Environment that is derived from OSEK, the OS is very static and generated from ARXML. Although it sounds cool to just generate separate pieces of code that will be executed “somehow” this is not aiding to understandability.
You cannot create an easy to understand architecture that explains how your software is built-up and how it generally works. It basically adds a lot of abstraction overhead for a non-effective abstraction, it is measured that the use of AUTOSAR will almost double the memory needed compared to non-AUTOSAR solutions!
The conclusion is that AUTOSAR is not designed to lessen the complexity, on the contrary, it adds to the complexity. Experts estimate the complexity of AUTOSAR about 10 times that of SysML.
Certainly mastering Complexity: UML/SysML
UML and its sibling SysML were created to master complexity. The graphical way to model using different diagrams that help the developer concentrate on different aspects of development without being distracted by other stuff.
UML is used to make software, SysML is a UML profile that uses some of the UML diagrams, sometimes in a different way (The same elements but they have a different meaning) and adds some new diagrams. It is used to make systems.
Many Automotive customers that want to start using modeling ask for SysML, since they make systems, not just software. Now there are a few disadvantages to that, it is harder to make just software from SysML, so you probably do stuff 2 times or you have to write helpers that do intelligent conversion/linking between your SysML and UML model.
The funny thing is that most people who ask for SysML, in the end only create software. So they would have been OK by using UML.
One of the nicer aspects of the UML is that it is set-up to be flexible and configurable. A good example is SysML, this is actually a UML profile. the same thing for the AUTOSAR profile, it changes the way the UML looks and feels by just loading a profile.
UML Tools help you in creating links between several development elements. In that way you can create traceability that helps you find back your stuff (and the reasons why you solved it that way) and is a must for certifications in safety-related applications.
The standard graphical UML helps you define and understand your architecture.
Helping to master Complexity: Tools
As already said, following a process with just pen and paper is not doable. Luckily there are enough tools around to help you in the development of your applications.
Most tools more or less use their elbows towards other tools to conquer as much space in the V-Model as possible. They all want to be used for everything. They all claim to have solutions for the complete process from requirements to acceptance test.
My advice: Don’t buy that!
Most tools have a specific area where they are good, or even “The Best”, on other area’s they shine a lot less and you could use much better tools.
Now it is understandable that you want as less tool switches as possible during development. Every time you are confronted with information that needs to be synchronized or linked. This needs to be solved good.
You may need AUTOSAR Tools to generate RTE and to have access to Basic Software and or stacks.
You may need Simulink (with Embedded Coder or Targetlink) to generate code for pi or pid control loops
You may need a UML Tool like Rhapsody to have your architecture defined, use statemachines to describe behavior and much more
There are lots of tools available but you should be using a combination of the tools that fits your needs and can be combined with each other.
The Master: Single source of truth
Or “How to avoid having multiple captains on one ship”. All Tools manage information. Sometimes information from different tools must be linked. Then you must use some synchronization (like IBM Rhapsody Gateway or the Willert RequirementXChanger) to keep the information synchronized AUTOMATICALLY! In that way you create a so-called “Single Source of Truth”, only one tool can be the master of a specific type of information. You have to define in your process definition which tool that is and how its done.
Be the Master: use Rhapsody with AUTOSAR
Method 1: Model AUTOSAR
This is the “full-fledged” way. You load one of the AUTOSAR profiles in Rhapsody. This changes the look and feel of Rhapsody to be an AUTOSAR modeling tool. The good-old UML elements are all disappeared and only AUTOSAR Items are available.
You can now use AUTOSAR diagrams (Block diagram etc) and model that. You can export your model into an ARXML file that you can use for other tools and for the RTE Generation.
If you want to use “plain” rhapsody state-charts you first have to add a so-called “RIMBO”, connect the interfaces and then you can use “normal” rhapsody.
This is the way IBM recommends.
Since 8.3 you can safely use the 64-Bit version, in AUTOSAR: Do that! It will be slow otherwise.
You can combine 64 and 32 if you have an older version, import/export with the 64-bit, do the rest as 32-bit.
Method 2: Transform AUTOSAR and model UML
This is the “Willert” method. For the AUTOSAR stuff you use an AUTOSAR authoring tool. Then you export the ARXML from there and import that into Rhapsody using the AUTOSARXChanger. The result is a UML model with”converted” AUTOSAR elements. They are, however, normal UML elements with stereotypes.
Willert is working on other ways to use Rhapsody in an Automotive environment. We will have an exporter that can export UML models (with the correct stereotypes) to ARXML files.
Keyless Master
An example how this works.
Keyless Master: Marquardt Case.
OK, that’s it! Happy modeling/mastering/driving!
Walter van der Heiden (wvdheiden@willert.de)
