Month: May 2018

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 thepattern 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 yyou 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 oklder version, import/export with te 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)

Youth dreams

One of the things I had planned a long time was the visit to the Kennedy Space Center in Florida. The chapter is called youth dreams and that is exactly what this was.
As a small kid I was completely mad about everything that had to do with space. I followed everything I could see on television about rockets and so on. I was listening to the radio when Appolo 8 was flying around the moon christmas 1968, shiovering when the communicatipn was restored.
And on june 21, 1969 (actually june 22 already in Europe) my parents woke me up in the middle of the night to watch the moon landing “live”
I watched every rocket launch there was on television, sitting behind the couch, not making a single sound so that my parents would not hear me. I later understood that my parents choosed to pretend not to notice me to give me the chance to watch and not loose their credibilkity…
But in that days I never expected to ever be closer to one of those places like Cape Kennedy or some NASA center.
But times change, the small kid idolate of rockets grew up to be the traveling modeler and travels the world. And now I had time to visit the Space Center, together with my son Robert.

Just Awesome

To give it away up-front: If you ever can: go there. It is not cheap but worth every penny. They have all the cool stuff, moonlander, Apollo, Saturn V rocket, a piece of the moon you can touch (How cool is that?) and many many more. Telling you everything would spoil half the fun. Don’t forget to take the trip to the actual launch center!

Back to reality…

Rhapsody…. It is used a lot for aerospace/avionics The tool fits very nicely with the requirements in that world. They are totally different than the automotive. Short difference: Automotive builds millions of devices for thousands of Euro’s, Avionics build thousands of devices for millions of euro’s. That is a difference. Plus that in avionics the complete top 10 of important items is safety. Not that Automotive doesn’t do safety but they do it different.

OK. Thanks! Happy Modeling with Rhapsody. Remember: the Sky is the limit!

Walter van der Heiden (wvdheiden@willert.de)

Hard Rock Café

The Hard-Rock Café is a must-visit on all my trips. I always buy a t-shirt (although my wife tells me that I have more than enough t-shirts already…)
The fun with the HRC t-shirts is that they have the name of the city printed on it. You can only buy them local, not on the internet, they have only neutral shirts there.
So if you see someone with an HRC t-shirt from some far, far away destination, he or she has either been there or has a good friend who has been there. (No, I will not bring you a t-shirt…. go there yourself…)

So on the Florida trip we decided to visit ALL the Florida HRC’s. Yes, all of them…
Key West, Miami, Fort Lauderdale, Tampa, Orlando, Daytona Beach and Nassau (On the Bahama’s, not exactly Florida as you can read on …)

We did Key West so the next day we left Arno’s house to drive via Tampa (HRC in the airport) , Orlando (HRC is in the Universal Studios) to Daytona Beach where we stayed in the Hard Rock Hotel. Then on to Miami (next to the Harbour See … )  via Kennedy Space Center (read …) Fly to Nassau and stay on the Bahama’s for a day (See: … ) and finally to Fort Lauderdale ( HRC in the Casino ) and then back to Fort Myers. Great trip, I can recommend it!

Sequence

I receive many questions about how to influence the Rhapsody generated code. Now you can post-process the code using the simplifier or even change the rules with our rules-composer but sometimes you should make life not more complicated than it already is.
There are more ways to ensure Rhapsody generates exactly what you want.
Ask most modeling guru’s (and the traveling modeler agrees…) and they will tell you: You have to model in a way that sequence doesn’t matter. As already said: I agree. But…..
There are circumstances where you just cannot model as you want to. The smaller the controller, the more rigid the real-time requirements, the more trouble to fit everything in and to certify it works.

Classes

Open a new model and if you create 4 classes (in this sequence!) “A”, “B”, “D”, “C”, you will see in your browser that under the default package you have the 4 classes, sorted alfabetically, A, B, C, D. This is just the “visual” sort, you can switch that of with either a property or with “View”, “Browser Display options”, “Enable Ordering”. This will switch on the small yellow arrows on top of the browser that let you order items as you want. (Only Visual!!)

Now the sequence of Code generation is not relevant for classes since they have their own file. The sequence of attributes or operation within a class can be important!Now that can also be achieved easily. Rhapsody offers the sorting from within the browser. Depending on if you have switched on the “Enable Ordering” all elements

are either shown alfabetically or in the sequence that you have entered them in the model.
The code generation for attributes and operations is not depending on that setting!! Code is generated in alfabeticall sequence, or the sequence that you give in the “Edit Order of Attributes (Operations)”.
This opens a dialog where you can precisely select the generated source code sequence.

Now if you have created objects statically using “Make an Object” or by just creating them you can do the same. Right click on “Objects” and you can select “Edit order of Objects” you can select the order that the objects are instantiated. (Do a regenerate, Active Code View is not automatically updated) The same applies for singleton Objects.

This also works with dependencies (with Usage, that will select the sequence of include)

Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

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)

The Keys

The Florida Keys are the small strain of Islands that lie south of the Florida peninsula. They are connected to each other via a couple of bridges and a long highway.
I’ve been there before but that had to happen on one day and before the flight back so I had not much time to enjoy the beautiful scenery and the islands itself.
The attraction is of course Key West where you are very close to Cuba (90 miles, 145km)

So this time we planned a bit longer visit and even an overnight stay. Getting a room was OK, apparently it was not the tourist season. Still it was quite busy on Duval Street that is the main attraction. Lots of cruise-ships stop at Key West, unloading lots of passengers. That is the main income of the islands.

The trip to the island is (for me…) the main attraction. We were driving there in a BMW 430i convertible. That was pretty cool.

Hemingway’s House (& cats)

One of the attractions of Key West is the house of Ernest Hemingway.

It is now a museum (you have to pay for it… very undutch…) and shows the house in its original state. The walls are full with Hemingway memorabilia and explanations about his life.
I had heard of Hemingway of course but never read anything from him. I immediately started to read “The old man and the sea”.
The house is populated by many cats that are all descendants of Hemingway’s cat “Snow White” who had 6 toes on each foot. The cats there all (as far as i could see) have that to and is quite remarkable.

Vacation

Even traveling modelers have vacation, sometimes. Although my life sometimes lookes like a long vacation, it still is work. I usually have only limited time to really look at something.
So I decided to spend 2 weeks in the United States, in Florida. Finally time to see more than airports and security checks.
My youngest son joined me and on may 1 we left in the morning to fly to Fort Myers via Detroit. I will tell a lot more about where we went and what we did.

The planning is to visit The Keys, Tampa, Orlando, Daytona Beach, Bahamas, Miami and of course my friend Arno in Fort Myers.
That is quite a program for 10 days but we’ll see. First we spend a day at Arno’s to join the pool….

Animation

Not really a theme for me… The Willert Version of Rhapsody does not support Animation (Therefor we include our “world-famous” Target Debugger.
A question came in from a customer about the use of animation with more than one Rhapsody version (So you can animate different applications)
This is actually quite easy once you understand how Animation works.
Rhapsody generates extra code when you switch on Animation, every function has some Macro in it, different macros for different functions.
Also the framework includes the Animation and tracing Framework, that provides the functions you need to animate.
If you start the Rhapsody developer it will reserve a TCP/IP Port for the Animation communication. The number is 6423. This is the reason that when you start a second instance of the developer there is an error message that says: “Rhapsody cannot create socket” or something like that.

Solution

There are multiple solutions.
They both involve the Rhapsody,ini file, this file must be right next to your Share directory.

• Create a second Data directory for Rhapsody and change the Animation Port Number. Create shortcuts that start Rhapsody in different directories.
  Advantage is that you gave control over he port number and you can decide which one to start.
• Add a line AnimationPortRange=10 to your Rhapsody.ini file. Now Rhapsody will use a new port number (after 6423 or whatever you have configured in rhapsidy.ini) each time you start a new Rhapsody instance.
  You have to generate and build your code (It contains the correct port number) to use the correct port.

That’s it for today, Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)