Just back from Munich I was one day at home to switch my suitcase and get prepared for the next trip. This time a bit longer and further away but the start was in Paris.
I had to go to France anyway so I combined the visit with a visit to the Louvre. No not the museum, IBM organized the IBM Think! Conference there.
This was a cool conference, the only problem is that everybody spoke French and all the presentations (but one) were in French.
My French is not as sophisticatedly my German and English, unfortunately… but I managed. There were 2 presentations with fast and unclear speaking people where I really struggled to understand what they were telling, but most was understandable.
The one presentation that was in English was also the coolest (by far…) :
INFRASTRUCTURES ET PERFORMANCES
Aston Martin Red Bull Racing – Brian Jones, Head of Software Development
I think that at least 2/3 of the audience left the room, because it was in English…. Their bad because Brian had a cool story to tell about using big data in formula 1 to achieve an advantage on the competition. Very very interesting, thanks Brian!
At night there was time left to visit the Mondial, the Paris Auto Salon. A nice view on the new cars of today and new technology, very cool!
This was a nice “bridge” to the subject of today. The use of Rhapsody in an Automotive environment. We at Sodius and Willert are working very hard at creating solutions that will support automotive engineers to do their complex jobs as good and right as possible.
That is not easy, many OEMs and TIERx companies have very well defined processes and always a high degree of time pressure that makes it difficult for them to change anything in their daily work.
As Henry Ford already said: If I had asked my customers what they wanted they would have said: “A faster horse”. So you can ask your customer (and you should surely do that!) but you have to define your won way at least partly and then convince customers that your way is the better way.
Since using Rhapsody with Code Generation will already change a lot in the daily routine of everybody but certainly in that of the automotive engineer who already has defined run-time systems (that mostly use periodic tasks) The Rhapsody generated code assumes a preemptive OS that allows you to send and receive events and react to them if they appear, and sleep when there is nothing to do. This is a fundamentally different approach then the MatLab approach that even uses “polled” state machines.
This kind of programming is also much closer to the human way of thinking. Many people consider a polling, or synchronous, system to be more deterministic than an asynchronous system. It is not, asynchronous systems are much more scalable and run without collision much longer than synchronous systems. They also fit better in Object Oriented Designs.
Many Automotive systems are only doable when using synchronous systems. All Control Loops work way better and simpler when you do them in Simulink. But there are lots of systems that are asynchronous. Think about everything that is under direct user control, indicator, power windows, HVAC control panel etc. There is lots of asynchronous stuff in a car.
The more complex systems in cars use both synchronous and asynchronous components. The easiest and nearest way to solve them is by using MatLab. Now that tool really helps you to do the synchronous stuff and it also can do asynchronous stuff with no real penalty. So that prevents people from using UML for creating code in an automotive environment.
Now MatLab and its friends will not really help you to gain understanding and reducing of the complexity in new systems. UML/SysML will, they allow you to setup an understandable architecture. But the real benefit will come from using it to program the asynchronous parts of the application and use the code generation.
The funny thing is that most people do not want the code that is generated from a UML tool like Rhapsody but have no objection against code from a MatLab Simulink model.
It took me a while to figure out why but I think I understand that now. Simulink, used by a Systems Engineer generates just a bit of code that is the exact representation of the algorithm. Writing the code for that would be difficult, the formulas are mathematical things that everybody hates to remember and understand. To generate the code actually relieves you from a lot of extra knowledge.
Generating code from UML is not that easy, you need a lot of extra knowledge to apply that. So people do generally not like to use it.
Another big difference with MatLab is that Simulink Code is mostly used in continuous algorithms, the code is incomprehensible but the diagram is easy to understand. UML (and certainly Rhapsody) excel in discrete algorithms. There the diagrams are also relatively light to understand, as is the code, but the code needs some extra stuff around it to work. That is where people stop using it, it is just not straight forward.
So this is the big dilemma of the Sodius Willert developers, but I think we have some pretty good solutions to use mixed UML/Simulink/AUTOSAR environments. We have a very minimal framework that is easily to us inside an SWC, per ECU we only need one Framework, it can handle multiple instances. You can also import and export ARXML to be converted in stereotyped UML/SysML elements. We will present some solutions on several congresses in the next months.
We have experience in using UML in AUTOSAR environments, we have ASPICE experts on board, certainly in environments where certification is an issue (ASIL C or D) we have expertise and matching tools. And we can train you in using them!
A nice opportunity to introduce the Sodius/Willert Tool SECollab (Systems Engineering Collaboration). This helps System Engineers to control all data that they use in their development process, they can make links to achieve traceability, use it for reviews (You don’t even need a license for the original tool to do that!) and derive documents for certification purposes.
SECollab is a server based solution, clients use Web Access, so no tiresome installation issues, just login on the website and access all information available (to you, of cours!)
Take a look at it, if you like it, contact me for a demo!
Happy modeling with Rhapsody (and SECollab!)
Walter van der Heiden (email@example.com)