Vacation!

Hi! And sorry for the low BLOG frequency. It’s vacation time. Not that I am on vacation, that would actually mean I have more time to write… No, I am busy at the moment, other are on vacation which leads to more work and I have a lot to do  privately: I’m building a new house.
That is… I have other people build me a house… As I always say: I have two right hands but unfortunately I am left-handed… (BTW: Today August 13 is international left-hander day!!)
So I do not build but that does not mean my work is done… there is a lot to do besides physically building.
So we did not planned a holiday because the house should have been finished around this time….
“Should have been”?? Yep. It’s not.

When software projects go rogue and take longer than planned, one of the things people (non-involved people…) say is: “These software projects… always late… they should learn how to plan just like the people who build houses.”
Well…. That is just sooo not true.. building projects also go rogue. Mine does but others do as well.
Builders plan but the same way software people plan. So plenty of space for mistakes and “unknown”
In my case the architect designed my house with a CAD tool. Not a very advanced one, I am still waiting on a 3D view…, but that is how he did it. The guy is an artist and he draws beautiful houses. We were very enthusiastic about it and we even got the permission to build it from our community (Yes that is needed in the Netherlands)

There were a lot of prerequisites that we had to comply with, it had to fit in a certain part of our (own!!!) ground and it had to have a straw roof (To make it look like the other farms in the neighbourhood)
I did not want that, I wanted Tesla Tiles that create power, but hey…
So the architect draw the straw roof. The drawings of the architect then have to be enhanced by a constructor that knows how you build a house. Then the builder starts organising sub contractors to deliver parts.
It turned out when he ordered the roof that the angle was not steep enough. So the roofer would do it but with our guarantee.
So back to the drawing board and half a year delay (New permit, new calculations…)
So don’t tell me building houses goes better than building software…

So I asked myself: Would modelling have helped here?
I think so. The fact that a straw roof needs an angle of more than 45º is basic knowledge that should have been a design rule in the CAD program.
Moreover, I have not seen anybody work with a tool like Doors or Polarion to fix the house requirements. It is more advanced than the last time I built a house (1986) but it is with Mail, WhatsApp and Word that the house is built.

Back to Rhapsody

Vacation time is a good time to work on improving your Rhapsody models!
Sometimes customers ask me to do a review on a Rhapsody model. What do I do in a review?
It depends of course but for totally new models I do a couple of steps which I want to share with you:

1. Check how old the model is. You cannot see it all but you can ask (..) and check if the model has CGCompatibilityPreX.Y Settings. They tell you the conversion already performed on the model (And the fact that the creators did not know what to do with it)
2. Do a Check Model ( “Tools”, “Check Model”, “<name>” ) This should give you a lot of information about the model. Most common warnings are: “Default Names” and “Empty Description” but there are many more.
   The more warnings, the less precise the model is built
3. Use Metrics to determine the number of elements in the model. Check for requirements, sequence diagrams and classes. There should be a fair number of requirements and a lot of sequence diagrams. unfortunately IBM stopped using the Metrics in 8.2. There is a more complicated system to still do it.
4. Use the built-in document creator ( “Tools” “Report on model”, then select only “Include Overridden Properties” ) to look at the overridden properties. This should be limited to profiles.
5. Do a general check.
   1. How do the names look? Consistent?
   2. How many packages compared to classes?
   3. Are there requirements used?
   4. Are there any Sequence Diagrams?
   5. Little number of properties is OK but not much
   6. What is the number of elements on diagrams. Yes that can be more than the “normal” 7+-2 but they should be understandable
   7. Are comments used?
   8. How is the diagram navigation?
   9. How many level of state-chart are there? One level or at most one sub-state-chart is OK. Everything else must be documented and proved necessary.
   10. Are model elements described in comment?

This is something that you can check yourself…. Do it sometimes.

Happy Modeling with Rhapsody

Greetings from Motown!

Walter van der Heiden (wvdheiden@willert.de)

License to thrill

The number 7 is a famous number, not in the least by James Bond who was, of course, “007”. He had a “License to Kill”. Our V7 has a “License to Thrill”.
That is what we hope it will do to you! OK, It took a us while, admitted, but the first release of our V7 RXF for ‘C++’ is now on our Willert Download Portal.
We have worked hard for it, had many Beta Releases and lots of changes to make the best RXF yet. A big thanks to everybody who worked on it but a special “Thank You” to Johannes who has really done a lot for this release!

What is changed?

• Completely made with Rhapsody. So the RXF is a model, with everything a model needs to be a good model, Requirements, traceability, Sequence Diagrams, explanations etc.
• Smaller and faster. (YES! although modelled and generated, the code is smaller and faster!)
• All adaptations integrated in one version. You select RTOS, compiler, CPU etc via tags.
• New Deployer, this one remembers a lot more of your stuff. (Is not completely finished yet but I’ll give the new features)
  • Creates direct links to the Rhapsody code in your IDE so round-tripping just works!
  • Able to create you own template models that you can select, they are then copied
  • stores its settings in the project
• Latest Target Debugger
  • faster, will not degrade performance when many events are processed
  • new design, improved stability and usage
  • break-point editor
  • editor for event injection
  • export to Rhapsody
• Easier to configure Memory Management

For the time being only in ‘C++’, ‘C’ will take a while. But with a decent compiler we recommend ‘C++’ anyway. Bob Dylan already sang it a long time ago: “The times they are changing”. And that is what happens. From ‘C’ only in 32Bit on 8 and 16Bit Targets to ‘C++’ on 64Bit on 16- and 32Bit Targets.

That was it for now. It’s hot here… almost too hot to work. Luckily we are getting used to it.

Have fun with Rhapsody!

What is the difference?

Rhapsody Developer is the “full” version of Rhapsody, EUSIII (Embedded UML Studio III) is the Willert version. The only difference is that EUSIII does not have Animation, all other features are there. Also EUSIII has the Willert RXF as additional Framework.

No Animation? Is that bad?

Not really. Animation will only work with Windows on a PC as target environment (Or Linux or another really powerful platform) otherwise it is not possible/practical to use it. EUSIII has an alternative built-in solution called “Embedded UML target Debugger” that does the same but without using additional resources.

RXF?

Yep. The Real-time eXecution Framework. The Willert Framework that allows you to generate Rhapsody code on even the smallest of targets without real-time violations or large use of resources. Comes with a built-in single-threaded RTOS or adapters for other RTOSes. Also included is the UML target Debugger that can write Sequence Diagrams and Timing Diagrams even from a small target environment.

Re-install?

Nope. Not necessary. You can keep using your existing installation. Since EUSIII is based on the Architect for Software you have to start that version.

• Starting Rhapsody via a desktop icon. (Or via the start menu) Then you can open the properties of the shortcut and go to the tab “Shortcut” (Names are different in other languages) There you can add “-architect” to the “target” field. If it already says “-dev_ed” you have to remove that. You can add the -lang=C or -lang=C++ to start the correct language by default.
• Starting Rhapsody by double-klick a Rhapsody Model. Now you have to look for the Rhapsody.ini file. This should be in the directory next to where your “Share” directory is. In that file there are 2 commands:

  DefaultEdition=Architect
  DefaultLanguage=c++

  You should change them that they say “Architect” and the correct language.

Install RXF

Not only does EUSIII come with the RXF, you really need it. Without an RXF the code generation will not work. So you must install one. It is not important which one but of course you should install one that you want to use. Installation is easy, just start the setup, answer the questions, check if there are no errors (When an error is given during installation it will NOT workl!!!)
When you have purchased EUSIII (Or just an RXF) you have access to the Willert Download Portal where you can download your RXF adapters for the Language (C or C++) the Compiler (Keil, IAR, GreenHills, Visual Studio and many more) and the RTOS (CMSIS, FreeRTOS, OORTX, µCOS, Linux and many more) that you want to use.

License

You either have received a dongle (with a license file) or just a license file (Floating License) You just install that as usual with Rhapsody,

So that’s it. Happy Modeling with Embedded UML Studio III

Walter van der Heiden (wvdheiden@willert.de)

Introduction

Preparation is everything. That is valid for everything. For modeling but also for vacation…..
Both Robert and I have never been to the Bahama’s and it seemed like a great idea to visit it. The flight was pretty cheap so we decided to just go there on an early flight and leave again in the evening. (Yes, we are the “Been there, Bought the t-shirt type tourists…)
But we did not do any other preparation…. we just went to the airport early. That was not difficult, the time zone works in our advantage.
The flight was very nice and shorter than planned. But then the first “small” issue crossed our path.
We both assumed that the Bahama’s were part of the USA. They are not… as it turned out… It is a country. With customs and borders and so… On the airport we had to fill in a Visa application form. Luckily there was nothing to do upfront.
Now the good part was that nobody gave us a hard time, everybody was extremely friendly but at first we were worried. But we got in quite quickly.
Then we wanted to check on the web where we had to go just to find out that even my super-duper cell phone plan did not cover the Bahama’s… Being online was extremely expensive so we had to stay in the airport WiFi to figure out where to go.
The speed of the WiFi was, well, very low. So I just saw that Uber would not work and that Nassau was on the opposite part of the island from the airport.
So we decided to rent a car. Hertz (my normal rental company) was out of cars but I managed to rent a car.
It was a VW Polo, Automatic and Aircon but not in a good shape. There we were confronted with preparation again.. There was a big sticker on the windshield that said “Keep Left”. But confusingly he car had a left-hand side steering wheel…
Then I realized that the Bahama’s have been English. These guys leave their marks thorough… So the road signs were exactly as in the UK and people drove left.
Not very cool with a “normal” car but I managed.
We were also not able to tell what kind of units they were using. The first sign after the airport was “45” but it took a while to figure out that they used miles or kilometers. With the state of the cars there, kilometers would not have been unlogical. So miles and not metric like the speedometer of the car. It didn’t even had the small inner “mile” indicator.

Conclusion

The Bahamas are very much worth a visit, one day is enough unless you are the sunbath type. The day was very relaxing and in the evning an hour before flying back we returned the car. At the check-in the lady told us that we were just in time. It turned out that you had to check-in an hour before when flying to the US, we had 2 minutes left… This proved again that preparation is everything. For traveling but certainly also for things like modeling. Gather all information you can get and model your application based on that.

Walter’s Rules #10: “Assumption is the mother of all f***-ups.”

Happy modeling with Rhapsody

Walter van der Heiden ( wvdheiden@willert.de )

Introduction

Preparation is everything. That is valid for everything. For modeling but also for vacation…..
Both Robert and I have never been to the Bahama’s and it seemed like a great idea to visit it. The flight was pretty cheap so we decided to just go there on an early flight and leave again in the evening. (Yes, we are the “Been there, Bought the t-shirt type tourists…)
But we did not do any other preparation…. we just went to the airport early. That was not difficult, the time zone works in our advantage.
The flight was very nice and shorter than planned. But then the first “small” issue crossed our path.
We both assumed that the Bahama’s were part of the USA. They are not… as it turned out… It is a country. With customs and borders and so… On the airport we had to fill in a Visa application form. Luckily there was nothing to do upfront.
Now the good part was that nobody gave us a hard time, everybody was extremely friendly but at first we were worried. But we got in quite quickly.
Then we wanted to check on the web where we had to go just to find out that even my super-duper cell phone plan did not cover the Bahama’s… Being online was extremely expensive so we had to stay in the airport WiFi to figure out where to go.
The speed of the WiFi was, well, very low. So I just saw that Uber would not work and that Nassau was on the opposite part of the island from the airport.
So we decided to rent a car. Hertz (my normal rental company) was out of cars but I managed to rent a car.
It was a VW Polo, Automatic and Aircon but not in a good shape. There we were confronted with preparation again.. There was a big sticker on the windshield that said “Keep Left”. But confusingly he car had a left-hand side steering wheel…
Then I realized that the Bahama’s have been English. These guys leave their marks thorough… So the road signs were exactly as in the UK and people drove left.
Not very cool with a “normal” car but I managed.
We were also not able to tell what kind of units they were using. The first sign after the airport was “45” but it took a while to figure out that they used miles or kilometers. With the state of the cars there, kilometers would not have been unlogical. So miles and not metric like the speedometer of the car. It didn’t even had the small inner “mile” indicator.

Conclusion

The Bahamas are very much worth a visit, one day is enough unless you are the sunbath type. The day was very relaxing and in the evning an hour before flying back we returned the car. At the check-in the lady told us that we were just in time. It turned out that you had to check-in an hour before when flying to the US, we had 2 minutes left… This proved again that preparation is everything. For traveling but certainly also for things like modeling. Gather all information you can get and model your application based on that.

Walter’s Rules #10: “Assumption is the mother of all f***-ups.”

Happy modeling with Rhapsody

Walter van der Heiden ( wvdheiden@willert.de )

Helemaal niks in 020

People who know me will recognize the title at least partly. Because I was born in the best city of the Netherlands, Rotterdam, I will never pronounce the name of our capital. That city becoming capital is a capital mistake… (pun intended)
The Dutch government houses in The Hague, a beautiful city at the coast of the Northsea, so it would be logically that The Hague (Or ‘s Gravenhage as the official name is) should be the capital. Nobody really understand why it isn’t.
The rivalry between Rotterdam (010 btw) and 020 is of course very football related. “Helemaal niks in 020” is “Totally nothing in 020”. We in Rotterdam sing that if the 020 football team has another year without a prize. The 020 “fans” still think they are the best.
But OK, it is our capital and we have to live with it. And sometimes I have to visit it (I even worked there for 7 years…) since I had guests from the United States and they all want to visit that.

Tourists

So I organized that a friend of mine who happens to live here, the poor guy, would guide us around in the city. And we do that the tourist way. A walk through the center of the city and the same but then by boat. I can really recommend doning that, it’s really cool, admitted. A few visits to a terrace and a few beers. And of course to the Hard Rock Cafe. NO!!!, I did not buy a t-shirt. I will not wear that. The only HRC shirt I don’t have and never will have.

Any Rhapsody news?

Yes!! 8.3.1 is on the way, I have a beta version installed already, looks cool! AUTOSAR 4.3.1 is supported and what I like very much is the new bridges. Rhapsody can now, finally, create a small bridge in the diagram when two lines cross. Simple change but looks way better. The double click to enter stamp mode in a diagram is also really cool and saves you time when creating diagrams with a lot of similar elements. The quick navigation improved so you can switch to diagrams with a single click on an element.
The API is improved, you wil not notice that much but the use is now in line with the Microsoft guidelines. There is now support for Visual Studio 2017 and.. there is a setting to let Rhapsody save in the old file format by default.
We are going to thoroughly test the new Rhapsody and I keep you informed when we release this version to all of our customers.

That’s it! Happy modeling with Rhapsody!

Walter van der Heiden ( wvdheiden@willert.de )

It’s a tough job but somebody’s got to do it…

Sometimes life is good, sometimes life is awesome. I had a busy week, hence the limited BLOG entries, but during this week I had time to travel to 020 (That’s how I call the city that became our capital by a “capital” mistake see: 020 and 8.3.1)
Then why go there? Well there is a place called Ziggodome where lots of concerts take place, On Wednesday it was the time of Pearl Jam, one of the bands I love.
Their first album “10” was one I played over and over and I still do that.

When I saw they were performing in the Netherlands I was sitting behind my computer at the start of the sale to get tickets. Unfortunately I could only get 2 tickets… Better than nothing I thought…

Unfortunately I also noticed that I had visitors from the US in that week that I could not shift. So I was already thinking of selling my tickets but when I told my guests that they all shouted: “Can you get more tickets”? Yes I can… 😉

So I traveled from the office in Bückeburg to “Nul Twintig” together with my American friends. A nice drive, about 350 kilometers. We ate a burger at the Burger B*tch (Not kidding, that is the real name, just google it) drank a beer and attended the awesome concert. Life is good.

What does this all have to do with Rhapsody? Nothing directly… but my friends are also Rhapsody and modeling people. Not only that, there were 2 Automotive Spice experts and another AUTOSAR expert. So we used all traveling time very useful with some interesting discussions on how to do ASpice with Rhapsody, how to import and export Rhapsody UML information to and from ARXML, how to do a model transformation from SysML to AUTOSAR and back with traceability links. We only stopped discussion when Eddy Vedder was singing. That was just too good. Love Rhapsody but I also love Pearl Jam.

So. Happy modeling with Rhapsody. one is Alive in Even Flow….

Walter van der Heiden ( wvdheiden@willert.de )

Introduction

As every year we have organized our MESCONF (Modeling of Embedded Systems CONFerence) We changed the format a little bit, this year we have extended it to 2 days, the first day is just like last year with the difference that we have an evening session, the second day is “Tool Vendor Day” to allow Tool vendors to do a more marketing focussed presentation of their tools

Again at the fantastic Infineon location in Munich we had 80 people there listening to various presentations of experts and later some Open Space sessions.

The evening session with Nicolas Dierks the Philosopher was really interesting and shines a new light on our lives as developers.

As usual we used “Open Space” to organize a big part of the MESCONF. Proven concept, since years we receive very good critics about it.

We spoke about lots of things that occupy modelers these days. One thing that returned in many meetings was the topic of “How to handle people who are refusing to model.”
A very interesting topic. Why are people refusing to model?

• Some people just don’t get familiarized with modeling. Modeling is not easy, you need a lot of initial knowledge to apply it in the correct way. The only thing that helps there is train, train, train, coach..
• Modeling is different from programming. Sometimes people who are real programming guru’s refuse to switch to modeling while they lose their “guru” status. It is difficult to discuss with them since they do not refuse consciously most of the time. they will use other arguments to refuse modeling and keep on doing what they do.
• “Known hurts are better than unknown happiness”. A common attitude of most people is to stick to what they know until the hurt is really, really big. As long as people manage somehow to deliver their products using old methods they will stick to them.
• “We don’t have time to repair the fence, we are busy catching chickens”. Most people are under stress and continue doing what they do because the stress does not allow them to step back and take the time to evaluate the used methods.

There is no “silver bullet” solution to that. The common feeling is that the world is leaning more and more towards modeling, partly because younger developers have less objections against it (Mostly they had it in school) and because the complexity is increasing faster. We also notice an increase in Rhapsody business. And that’s good!

OK, that’s it. Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

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)