Category: AUTOSAR

Introduction

M2M is a product from SodiusWillert that helps you to save large amounts of time. It converts Rhapsody models made with certain profiles to other profiles. For example, taking a SysML model and convert that to an AUTOSAR model.

How does it work?

It is not really magic… actually you do your own magic. M2M uses a ruleset to define what elements are moved to which other elements, for instance: take a SysML Block and transform it to an AUTOSAR Block.
Now that would be an easy one. You can also make it more complicated. E.g.: You can define that a SysML Block with stereotype “SWC” will be converted into an AUTOSAR SWC.

That is already more interesting. But it doesn’t stop there. The rules allow you to define multiple elements to convert to one element or one element to convert to multiple elements (1:1, 1:m, n:1, m:n)
But then the fun really starts because you can also add functions (written in JavaScript) to do pre-conversion checks (“Do I want this specific element to convert?”) or post-processor actions (:e.g. “Rename this element” or “Create other elements on other places”)

You only sync once?!?

This opens a lot of posibilities to transfer model element between models from different profiles. Using M2M in combination with DiffMerge opens even more possibilities.
This helps you in keeping different models up-to-date, no matter where you make changes.
So you can have multiple different views on your System under Development, a Systems Engineering view, an AUTOSAR view, a Software View and maybe even a source-code view of the used BSW (Basic SoftWare) all of them subject to changes but all of them in sync thanks to M2M.

Put the power where you need it.

Some models have certain possibilities that others don’t have and vice-versa.
This means that you should model in the profile that offers you what you need.
SysML is perfect to model requirements and use-cases and link them, the AUTOSAR model gives you feel insights in all parts of your software and the UML model has a bit of both (and state machines…)
M2M allows you to add your own information exactly where it fits best.

I want to have this!!

That is cool. Contact me to get an evaluation version and an evaluation license.

Introduction

When developing systems or software for an Automotive environment you cannot avoid using AUTOSAR. This is the standard for exchanging information between involved parties inside Automotive projects, can be an OEM requesting a TIERx to do the development of a certain ECU or small companies doing parts of software applications that will run on that ECU.
AUTOSAR also defines a standard software layer (BSW or in Adaptive ARA) that helps you developing on different microcontrollers without really knowing all details.
Then there is the Operating system, which on the Classic Platform is almost completely statically defined an generated out of the information in your AUTOSAR model. Also called RTE.
There are several companies where you can purchase tools to help you creating applications and generate the stuff that you need to make a complete production ready application.
They are from companies like Vector, Elektrobit, dSpace, Dassault but also from Siemens (former Mentor). We used to use ArcCore but they have been purchased by Vector and integrated in their tools now.
The problem with most of these tools is that they are looking at things from the “low-level” side. There is a lot of detailing necessary before you can work with these tools and that certainly is not helpful when you only want to create an overview of the blocks you are going to implement.
You can use Visio or a cheap UML tool for that, this will not give you the benefits you want since they are solutions that will not allow you to incorporate that information in a dynamic way in your AUTOSAR model.
There are also tools from previous named companies that try to overcome this disadvantage but these tools still work in a proprietary world, not with an open standard like UML or SysML

Why UML (or SysML)?

These are standards. And standards that were developed quite a while ago with many people that have knowledge of them. Standards that are taught on universities.
The UML was made out of lots of other smaller pieces of standards that were already available, hence the “Unified” in the name. It was made especially for handling the growing complexity of software projects. Source code (generation) played a role, of course, but the emphasise was on the handling of complexity. This was done with different diagram types for different aspects of the system to be developed. Every person that is involved in the project can enter information and extract information from the UML model and the exact right level without being disturbed by information that is not relevant for that person.

Rhapsody AUTOSAR profile

Rhapsody has, for quite a while now, an AUTOSAR profile. This allows Rhapsody to read in and write ARXML files. They are then stored in a Rhapsody Model so they can be edited on an AUTOSAR level. Rhapsody can even convert information between AUTOSAR versions!!
All AUTOSAR Elements are implemented and can be edited. This is not always the most comfortable way, some things are better done by using an AUTOSAR dedicated tool like Vector’s DaVinci for instance.
For use with the Code Generation from Rhapsody we also have an “AUTOSAR lite” profile

Rhapsody Rulezzz!

So, how do we do that with Rhapsody then?
Rhapsody is a UML tool that exists since 1996. It also does SysML (Because that is a UML profile, although that will change in the SysML 2.0 release).
But that is not all, the tool is part of the IBM Engineering Tools and can exchange information with DOORS, DNG and many other tools via OSLC on the Jazz platform.So your requirements from DOORS or DNG can be seen and linked inside Rhapsody. The same platform also allows you to use widespread external tools like Jira from Atlassian or even link to your production using WindChill from PTC.
And as already said above: Rhapsody can read ARXML files and exchange them with all other AUTOSAR enabled tools. You can even use MATLAB Simulink models linked to Rhapsody models.
This all enables you many different views on your application or system but still have these views synchronized (or even linked when they use OSLC)

Doing the Magic: M2M

Of course Linking informations is ALWAYS better than synching information, sometimes linking is just not possible. For that we have M2M (Model to Model) that can convert Rhapsody models with different profiles. It is rule-based, you create rules like:

When a certain element of MetaClass “SourceMetaClass” and a stereotype “SourceStereoType” is found
Then see if certain conditions “Conditions” apply
If that is the case, convert the element to an element of MetaClass “TargetMetaClass” with stereotype “TargetStereoType”. If there is a linked operation “Operation” then execute that.
All Rules have a sequence number, lower numbers will be executed first and exclude higher sequence rules.

After applying the rules, the resulting model must be merged back using (built-in) DiffMerge. This ensures that changes can be made to single model elements without redoing the whole model.

This allows a very sophisticated way of maintaining different views to the same information.

Happy Modeling with Rhapsody

Walter van der Heiden (wvdheiden@sodiuswillert.com)

Introduction

When developing systems or software for an Automotive environment you cannot avoid using AUTOSAR. This is the standard for exchanging information between involved parties inside Automotive projects, can be an OEM requesting a TIERx to do the development of a certain ECU or small companies doing parts of software applications that will run on that ECU.
AUTOSAR also defines a standard software layer (BSW or in Adaptive ARA) that helps you developing on different microcontrollers without really knowing all details.
Then there is the Operating system, which on the Classic Platform is almost completely statically defined an generated out of the information in your AUTOSAR model. Also called RTE.
There are several companies where you can purchase tools to help you creating applications and generate the stuff that you need to make a complete production ready application.
They are from companies like Vector, Elektrobit, dSpace, Dassault but also from Siemens (former Mentor). We used to use ArcCore but they have been purchased by Vector and integrated in their tools now.
The problem with most of these tools is that they are looking at things from the “low-level” side. There is a lot of detailing necessary before you can work with these tools and that certainly is not helpful when you only want to create an overview of the blocks you are going to implement.
You can use Visio or a cheap UML tool for that, this will not give you the benefits you want since they are solutions that will not allow you to incorporate that information in a dynamic way in your AUTOSAR model.
There are also tools from previous named companies that try to overcome this disadvantage but these tools still work in a proprietary world, not with an open standard like UML or SysML

Why UML (or SysML)?

These are standards. And standards that were developed quite a while ago with many people that have knowledge of them. Standards that are taught on universities.
The UML was made out of lots of other smaller pieces of standards that were already available, hence the “Unified” in the name. It was made especially for handling the growing complexity of software projects. Source code (generation) played a role, of course, but the emphasise was on the handling of complexity. This was done with different diagram types for different aspects of the system to be developed. Every person that is involved in the project can enter information and extract information from the UML model and the exact right level without being disturbed by information that is not relevant for that person.

Rhapsody AUTOSAR profile

Rhapsody has, for quite a while now, an AUTOSAR profile. This allows Rhapsody to read in and write ARXML files. They are then stored in a Rhapsody Model so they can be edited on an AUTOSAR level. Rhapsody can even convert information between AUTOSAR versions!!
All AUTOSAR Elements are implemented and can be edited. This is not always the most comfortable way, some things are better done by using an AUTOSAR dedicated tool like Vector’s DaVinci for instance.
For use with the Code Generation from Rhapsody we also have an “AUTOSAR lite” profile

Rhapsody Rulezzz!

So, how do we do that with Rhapsody then?
Rhapsody is a UML tool that exists since 1996. It also does SysML (Because that is a UML profile, although that will change in the SysML 2.0 release).
But that is not all, the tool is part of the IBM Engineering Tools and can exchange information with DOORS, DNG and many other tools via OSLC on the Jazz platform.So your requirements from DOORS or DNG can be seen and linked inside Rhapsody. The same platform also allows you to use widespread external tools like Jira from Atlassian or even link to your production using WindChill from PTC.
And as already said above: Rhapsody can read ARXML files and exchange them with all other AUTOSAR enabled tools. You can even use MATLAB Simulink models linked to Rhapsody models.
This all enables you many different views on your application or system but still have these views synchronized (or even linked when they use OSLC)

Doing the Magic: M2M

Of course Linking informations is ALWAYS better than synching information, sometimes linking is just not possible. For that we have M2M (Model to Model) that can convert Rhapsody models with different profiles. It is rule-based, you create rules like:

When a certain element of MetaClass “SourceMetaClass” and a stereotype “SourceStereoType” is found
Then see if certain conditions “Conditions” apply
If that is the case, convert the element to an element of MetaClass “TargetMetaClass” with stereotype “TargetStereoType”. If there is a linked operation “Operation” then execute that.
All Rules have a sequence number, lower numbers will be executed first and exclude higher sequence rules.

After applying the rules, the resulting model must be merged back using (built-in) DiffMerge. This ensures that changes can be made to single model elements without redoing the whole model.

This allows a very sophisticated way of maintaining different views to the same information.

Happy Modeling with Rhapsody

Walter van der Heiden (wvdheiden@sodiuswillert.com)

Introduction

AUTOSAR is the standard created to support software development in automotive environments.
Why is there a special standard for that? Is software for cars special?
No, the software itself is not, it’s just plain ‘C’ (lately also ‘C++’) But the circumstances are different.
Are there special Tools for that? Yes there are. Wouldn’t it be nice to just use the normal Development Tools? YES Of Course!
Willert has all these tools and the add-ons necessary to use them in an AUTOSAR environment!

Differences

• Timing is critical, in more than one way.
  There is the timing in the software itself, which is still critical although CPU performance increased severely last years. This is partly because most software in cars is “polled”. Due to the fact that there are algorithms in cars where developers use Simulink (and code generation in TargetLink and/or Embedded Code) that is “control loop software”, so does stuff every 10 milliseconds.
  That is OK, it works but your software is ALWAYS doing “something”. And while different paths through your code are taken (with different execution times) this is difficult to manage.
  Then there is the timing in the release of cars. That is different than most projects…. A cars introduction and production is planned years ahead and there is NO DELAY possible. Period. You can easier shift the timing of a solar eclipse that the intro of a car. So software development cycles must be predictable (they aren’t but they must be….)
• Cooperation not only between colleagues but worldwide between multiple companies.
  Yes. Cars are defined by OEM’s, parts are made by Tier 1,2,3 etc by companies that have developers everywhere over the world.
  The environment supports exchanging information on buts and bytes and, for all, the possibility to exchange pieces of software built by one company for other pieces. AUTOSAR (ARXML) makes this possible.

How can Rhapsody help?

That is not too difficult. Rhapsody has the AUTOSAR Profile. This allows you to read-in ARXML files and make them visible, graphically, in Rhapsody.

You can also edit the AUTOSAR model in Rhapsody. Or even create it there and export what you’ve mad to an ARXML file that can be read by an AUTOSAR Authoring Tool like e.g. DaVinci.

Here you can import any ARXML file. Rhapsody will import it (Remember: Use the 64Bit version to import, 32Bit is way too slow)

Another possibility to fill your AUTOSAR model is by using plain SysML or UML with the simplified AUTOSAR profile. This gives you stereotypes for the most used AUTOSAR elements. The M2M Tool will then synchronize your 2 views, the AUTOSAR view and the SysML/UML View.

In this way your models will always be up-to-date, wherever you make your changes.
The second step to use Rhapsody is then to generate code that can directly be used inside your AUTOSAR environment!

This picture shows the workflow. Mixing this with other tools like Simulink (even with co-simulation) is no problem!

Reverse Engineering

This allows you to use the code from your AUTOSAR Tool (Basic Software and other RTE functions) in your Rhapsody state-machines or functions.
In contrast to the previous Rhapsody Workflow (RIMBO and then link your Rhapsody App in the AUTOSAR code) this is the much easier way: Just use a few stereotypes and you can use the Rhapsody Code you already know (If you’ve used Rhapsody for non-Automotive environments) in an AUTOSAR environment.

Contact me if you need more information. I can arrange an evaluation version!

Happy driving with Rhapsody!

Walter van der Heiden (wvdheiden@sodiuswillert.com)

Traveling

Last year the 10th AOC was in San Jose, this year the 11th was just as far but then in the other direction… in Shanghai

Also a first time, I’ve never been to China before. before we left there was already a bit of bad news: The Hard-Rock cafe in Shanghai just closed. Grrr.

Also acquiring a Visa was a bit troublesome… but I managed in time.

But OK, we had to work anyway. So on Sunday, me and a colleague left for Schiphol Airpor (My Favorite) to fly to Xiamen and then to Shanghai. Almost 16 hours in total. The first flight took 10 1/2 hours, that is long… Somehow I did not manage to sleep so I was pretty tired after arrival.

Luckily the arrival was in the evening so after a shower and a meal we could quickly go to bed. Before that we managed to get some SIM cards so that we could be online in an affordable way. Also we tried an ATM and that worked! China uses

But soon we noticed that not everything is easy in China. Almost everything is blocked, Google, Facebook, Uber, WhatsApp and even Pokémon (Yes, yes….) Even many commercial VPN services don’t work.

Luckily I have my own VPN at home so I could have some communication with the home front. But it is definitely not as easy as we are used to now. And slow. And you get kicked out every now and then.

So if you travel to China:

* buy a SIM card from China Mobile (costs about €20 for a Month unlimited data)

* Optionally take a second cel phone (Or a WiFi 4G Router)

* Organize a VPN

* Download WeChat. Without WeChat you are lost in China. It is their WhatsApp and Facebook and ApplePay.

* If you go to China longer: go to ICBC and organize a Bank Account. You can link that to WeChat and use it to pay. They not always accept you as a customer but just try another one.

* No Uber but China has DiDi, get that!

The Conference

The Conference was 2 days, the first was a technical day with 2 parallel slots, one for Classic and one for Adaptive. My colleague and I decided to split up, I would do the Classic track, he the Adaptive.

It turned out to be the most interesting day, the next day was much more superficially from an information standpoint. At night was the networking reception, that is always very useful.

I changed my opinion about Adaptive AUTOSAR. My usual comment was: “Adaptive is like teenager sex, they all speak about it but nobody know how it works and nobody has done it”. I thought the use would be limited to infotainment and autonomous driving ECUs.

But I noticed that there is a trend towards centralization, like in the IT world. Nota bad idea, you create lots of intelligent sensors and actors and connect them to a powerful system that can control them.

Since most ECU’s are not “stand-alone” anyway but have to share tons of information with other ECU’s it is a good idea to combine all these systems.

Since the “intelligent” sensors and actuators will be still made with Classic AUTOSAR, there must be an AUTOSAR Classic inside the Adaptive.

We also learned a lot of other things like the communication (SOME/IP) and DDS, a systemwide publisher Subscriber (A bit like Da Boston Broker )

Back Home

It was a short visit, on Thursday we went back the same way we came. We got lucky, a free upgrade to Economy Plus. Unfortunately a large family (I think from one of the countries that used to be Yugoslavia) thought it was a good idea to put the entire family in Economy Plus, including their noisy kids. But we returned home safely!

I will be back in Shanghai in 2 weeks for the MESCONF.

That was it

happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

Strategy

It’s not easy to have a good strategy for software. Things change so rapidly, what is important one day is totally forgotten a day later. Like AUTOSAR. There are 2 main streams, Classic and Adaptive.

Of course, as usual, we decide to concentrate on one and the next day customers start to ask about the other and vice versa.

So, no worries, we will do both!

For Adaptive we are preparing a Beagle Bone with Yocto Linux to get the first samples running, for Classic we have an STM Board that should work with a basic example.

We have already been doing a lot of work in getting a Classic AUTOSAR environment running. There were some examples with it but it still took us 2 days to get LED’s to blink on a board.

There is still a lot of “Voodoo power”involved in our opinion. Some stuff is totally incomprehensible for mere mortals as we are. It does not help when the documentation says: “The do a rebuild, just in case”…. Confidence sounds different.

What also _really_ surprised us is the size of the executable. We always thought that Automotive apps must be small. A blinking LED in 15k is not what I call small… Our UML generated stuff uses less than 1k for that. And we have trouble convincing people that the 1k is worth the increase in understandabilily.

During debugging we noticed lots of layered calls to abstract the Hardware. I think that is a great idea but we seriously doubt if any Automotive Companies is willing to pay the hardware price for that.

We also created Rhapsody models to generate code from that must be run in an AUTOSAR environment. We will then integrate the Rhapsody generated code with the AUTOSAR RTE generated code

Vacation

I will be on vacation the next 2 weeks. I will still be writing, no worries!

Happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

The planning was to have a more quit week with less travelling. As usual, this did not work out well. As my good friend Bruce always says: The difference between theory and praxis is a lot larger in praxis than it is in theory. No problem, I’m used to that.

On Tuesday, at least that is what Clemens thought, we had a common AUTOSAR Meeting. We are AUTOSAR Premium Member (by proxy of Sodius) so we visit the meetings and we try to influence the process of the AUTOSAR specification.

So on Tuesday morning very early we drove from the apartment in Bückeburg to dSpace in Paderborn where the meeting was held.

There it turned out that Clemens made a tiny mistake. He assumed that all meetings had the same footprint during the week which was wrong. (As _I_ always say: Assumption is the mother of all f***-ups) So after a Tuesday full of very very in-depth AUTOSAR workgroup meetings (and a nice lunch, thanks dSpace!) we drove back to the appartement just to go up very early again on Wednesday to visit the meeting we wanted to visit….

Anyway… shit happens. This way Clemens and I had time to discuss the Willert AUTOSAR solutions. Basically there are 2 AUTOSAR solutions, Classic and Adaptive.

Classic is for targeted at smaller controllers and very static environments. Base is that many system information and software (SW-C, Software Component) information is captured in an XML structure (ARXML) Tools can read that structure and use the information in there to configure themselves and to export their own added information to other tools.

Adaptive is targeted at larger systems that have dynamic components. Base is a Linux environment with many specs for security. It will (amongst others) be used by ADAS (Advanced Driver Assistent Systems)

What does that has to do with us? Well, Rhapsody is a tool as well and it is, out of the box, capable of reading and writing these ARXML files. You can then add information and work with the provided information. We think, however, that this solution is not applicable and scalable enough for a lot of customers. So we visit the meetings and have access to the AUTOSAR information to be able to create our own simplified AUTOSAR profile. (Apple Style, or better: Jobs Style, keep it as simple as possible, hide the complex stuff, make it usable for everybody but also make the complex stuff still accessible for Guru’s)

What we basically do with Classic is that we import ARXML and convert it to UML Elements right away. In that way we can use “normal” UML to develop AUTOSAR SWC’s.

Adaptive is very new and in early stages of definition. So there is a lot to do for us in that area, not only in profiles and frameworks but we can do a lot there in Rhapsody modeling, at least that is what we think.

So in the next weeks we have a lot to do. Clemens and I will be cooperating in creating / improving the Willert AUTOSAR Solution!

Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

 

Introduction

The software development division of the Marquardt company decided in 2012 to switch from structured programming using ANSI-C to a model driven development approach using UML including automatic code generation. The reason was to have a better position in the future to master the increasing complexity and requirements in the automotive supplier market easily.

THE PROJECT

The first project where MDD was used was the development of a wireless keyless-entry/keyless-go system for a well known German car manufacturer. The hardware platform was a 16 bit controller with 64 Kb ROM and 4 Kb RAM. The application to be developed had to cope with limitations as the very small footprint, the minimal processing power and still require very little resources at startup time.

These challenges provided the Marquardt Software Design team with at the trigger- after successful proof of concept – to do a future oriented switch and become an ‘Early Adopter’ in Model Driven Development (MDD).

AT THE START

The assumption that MDD could be of great use in software development was initially quite controversial in the software development team. Also the question if the keyless system would be a suitable candidate for a pilot project was doubted, especially due to its its stringent resource requirements and the short time to develop. However, in the end it became clear that the
traditional methods of structured programming could no longer be used for such high requirements and time constraints in future projects. And although this keyless system project was not an ideal candidate as pilot project, given the short Time-to-Market that is common in the Automotive market, Marquardt decided not to wait with their switch to MDD. Its customers would benefit enormous of the innovative approach. The risks were carefully calculated and Willert Software Tools GmbH offered Training and Coaching during the entire product development process and helped in the Switch and the changed process.

DURING THE PROJECT

The project was carefully planned as pilot project to recognise the advantages of MDD during development. An investigation of tools to use was carried out, based on the requirements with respect to memory- and CPU resource usage and realtime behaviour, to determine how feasible the introduction of MDD would be with respect to memory usage, performance and real-time requirements.

The positive outcome of this investigation was convincing. The idea that restrictions due to software development in ANSI-C could be surpassed, was clearly valid. The development team of the pilot project defined the following goals:

The Tools: UML as modelling language, modelling in IBM Rhapsody in C extended with the Realtime eXecution Framework (RXF) by Willert Software Tools (see infobox) made it possible to meet the specific technical requirements and use code generation for the limited memory- and CPU resources.