Rhapsody TechBlog

BLOG about IBM Rhapsody. Contains technical information as well as more private travel stories.

Tag: UML (Page 1 of 3)

Rhapsody vs Preevision

February 15, 2021 / / 1 Comment

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 and 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)

Code generation

October 23, 2020 / / 4 Comments

Introduction

I am a heavy FaceBook user. ( I know, I know….) One of the things FaceBook does is some kind of daily report with things that you posted exactly x years back.
I used to really like that but in this COVID times these now start to annoy me because they remind me of the travelling times I had before.
I am now officially no longer the “Travelling Modeler” but the “Stay at Home Modeler”…
Well, it is what it is. Since 2 weeks I am not even allowed to travel to the office anymore since Germany does not want to have Dutch people without being tested or quarantined.

Now I assumed my life would be a lot less stressful but nothing is more untrue, I’m now clicking myself from online meeting to online meeting with Zoom via Webex, Skype and Teams back to my own desktop.
When there is time at night, the family takes up that time. Don’t get me wrong, I love that and it’s fantastic but there is hardly time left to write a BLOG. Like I used to have in Airport Lounges and Hotel Rooms.

So I just have to take that time otherwise and I hope I will succeed in giving you the Rhapsody info you need from my home.
The main picture of this post is the view from my living room. Could be worse I think.

Conspiracy Theory

They’ve always been there but in the Netherlands it’s a hot item nowadays: Conspiracy Theories about everything but now more than ever about COVID. I am not going to discuss that here, that is where I have FaceBook for, but I want to discuss one work related “Conspiracy Theory”: People are denying Code generation. This is where I want to stand up and convince people.

Because this hits me, time after time. Why on earth would you want to use UML and SysML to just draw pictures and then write software by hand if your tool can generate the code for you???

The sad thing about people believing in Conspiracy Theories is that it is extremely hard to convince them otherwise. They always have arguments “out of the blue” mostly lacking any truth or “conveniently” bending truths.

Same with the “Anti-CGers”. All their arguments have been wiped away years ago but they keep popping up.

  • Code Generation makes code too slow/big/unreadable
    Not true. In fact, our Code generator makes smaller code than the average developer does. Certainly when projects get either large or old or both. We all have seen “old” code that is no longer understandable. certainly if the developer is a fan of “It was hard to write, it should be hard to read”.
    Generated code is also faster and perfectly readable. in fact, the consistent structure of the code makes that you can read ALL code. Also the stuff your colleagues have written. The fact that you can make changes to your state-machine and the whole code is written new, from the ground up, instead of decorated with all sorts of work-arounds is saving valuable development and testing time.
  • creating a model that is suitable for Code Generation takes longer than simply write the code.
    Not even closely true. When using Code generation from a UML model you have to create a correct model anyway. Otherwise your model is something that only you can understand. UML and SysML have a very precise semantic, if you don’t follow that,your code has nothing to do with your model.
  • Generated Code can not be certified.
    On the contrary: Certifiers love the consistency and, for all, the traceability of generated code. Yes, traceability. Automatically generated if you create the links from the requirements to your model, the code generator automatically inserts the requirements numbers and text in your code. Without an error. Since testing can be done from the model (but also in the generated code) automatically, setting up that for a certification is easy. I know, I’ve done it. Multiple times.
  • Code generators are expensive.
    Well that depends on what your perception on “expensive” is. But for less than 5k you have a UML Tool that generates code in ‘C’, ‘C++’ or ‘JAVA”, including highly optimized framework and debugger. Including a full year of support. By me. Or my colleagues. I think that is a great deal.

In times where we have less social contact between the developers of projects, using a good structured code is becoming even more important. Cooperating is hard enough, let’s cooperate on model level so the communication is much clearer. Let the Code Generator do the hard work.

The truth is that for many die-hard ‘C’ and even ‘C++’ programmers it is hard to leave their “guru-status” behind and use a code-generator that writes better, smaller, faster and more readable code.
But like with COVID: it is what it is. You will not become a “lesser Guru” by letting a code generator do the largest (and mostly boring) part of your job.
Even the best code generator needs a smart human being to operate it the right way: you.

So! Happy code generating (at home!) with Rhapsody!

Walter van der Heiden (wvdheiden@sodiuswillert.com)

And now for something completely different….

July 8, 2020 / / 3 Comments

Prologue

Hi All! It’s been a while since I wrote. Not much travelling these days, I was in Germany in the office last week and in Stuttgart (by car) but only briefly.
Work however continues and is even more than usual.
So not much time to write BLOG entries. Soon my first vacation in 3 years (too busy building a house…) will start. I promise to write some new stuff then…

XSD

This time I want to speak about something unexpected that you can do with Rhapsody: XSD (XML Schema Definition) import/export and editing with Rhapsody.
This is an add-on Tool (of course from SodiusWillert!!) That helps you deal with the normally textual and tiresome XSD files in a nice graphical way.

I added some of the pictures and explanations from our presentation, you can download the presentation here:

sodiuswillert-rhapsody-xsdDownload
  • During design, the data exchanged throughout external interfaces of a system are described by a set of technical XSD files.
  • They have to be integrated in the UML/SysML models and types linked with the model.

Rhapsody XSD – Key Features

  • Integrate XSD types in Rhapsody
    • Import XSD files in Rhapsody
  • Make XSD Types understandable in Rhapsody
    • Simple concepts but enough expressivity
    • Complete XSD Profile and Diagram Support
  • Use Rhapsody as an XSD editor
    • XSD Previewer
    • Export XSD Rhapsody to XSD Files

If this is interesting for you, please contact me!

Happy XSD-ing with Rhapsody!

Walter van der Heiden (wvdheiden@sodiuswillert.com)

Stay Home

May 6, 2020 / / 5 Comments

Introduction

I don’t want to say much about Corona, Lockdown, Virus, COVID-19, Social Distancing and related subjects, there are enough other places where you can read enough about that topic. I was personally quite busy with all kinds of things (moving to a new house but also not traveling…) so it took me a while to get back writing.

Rhapsody 9.0

Yes!It is there! the long awaited Rhapsody 9.0. To be precise… the name is no longer “IBM Rational Rhapsody” but “IBM Engineering Systems Design Rhapsody”. Whatever….

Here is a brief summary of important changes:

  • Windows 10 AppLocker Compliance
    The “Share” folder has been split up into “UserShare” which resides in the Rhapsody data folder and “Share” which is now in the (usually read-only) Rhapsody program files folder. You will find property files like SiteC++.prp in the “UserShare” folder now, while e.g. profiles and settings delivered with Rhapsody are in the Share folder.
  • Framework Compilation
    Rhapsody standard frameworks like the „oxf” do not come as ready-to-use libraries anymore. They are built when needed or via menu entry “Code” => “Build Framework“.
  • Dropped „Save As .rpy“ Support
    Attention: this is the first Rhapsody version that does not support to save in old Rhapsody format (.rpy) anymore.
  • Support for property help that comes with profiles
    For example our latest C++ RXF uses this mechanism and makes it possible to see properties for the RXF in Rhapsody including the context sensitive help.
  • MinGW Environment Support
  • IBM Product Renaming
    In most places „old product names“ have been adapted to match the IBM Engineering Lifecycle Management family product names.
  • Under-the-Hood Improvements
    There are important improvements internally, which are not directly visible to the customer. The toolchain used for Rhapsody development has been upgraded, also libraries Rhapsody relies on are updated. This is a big step that will be the prerequisite for future Rhapsody improvements, especially regarding the user interface.
  • And of course: Bugfixes
    Several problems reported by our customers and others have been addressed in that release, for details see IBM’s fix list.

Customers using the Embedded UML Studio (and a so-called ASL-license) can use our Download Portal to access Rhapsody 9.0: x86/x64.

Customers working with the RXF can check the support announcement for the RXF with Rhapsody 9.0 to see how they can easily upgrade.

RXF for C++ 7.11

And that’s not it…

We have just released the new version 7.11 of the Real-time eXecution Framework (RXF) for efficient UML code generation.
Those are the most important news:

  • Dynamic Memory Usage for Events
    The RXF usually works with statically pre-allocated memory blocks for optimal and deterministic memory management of UML events (asynchronous messages). With the new version it is also possible to explicitly allow the usage of dynamic memory allocation from the heap, if matching  static memory pools are not available or full. By default, it still uses statically allocated memory pools.
     
  • RXF Property Perspective and RXF Property Help in Rhapsody
    When using the RXF stereotype, you automatically get a „Willert RXF“ property perspective to see all relevant properties for framework configuration in a well organized way. You can select it instead of „All“/„Overridden“/etc. in the properties tab drop down list. Actually this came with an earlier version already, but since Rhapsody 9.0 and with the latest RXF release it is even more useful, as you can see the property description now right inside Rhapsody just like for any standard Rhapsody property (see screenshot above).
     
  • ActiveClassTable
    It is now easier to keep an overview of all the threads (active classes) configured in your model:
     
  • No Setup required, Relative Paths used
    There is no need to install a framework to a specific absolute directory anymore. You may move the RXF folder to another location. As long as the RXF profile is referenced correctly from your UML model, all tool paths will work. This also allows easier configuration management and maintenance of future project specific RXF updates using externals on your SCM. For details read the HTML documentation under Technology => Configuration-Management.
     
  • MISRA Improvements and a Bugfix
    Most MISRA improvements have already found it’s way into earlier RXF releases, but still some minors could be improved. And a bug was fixed where timeout handling could be unprotected when using critical sections instead of mutexes.

Our C++ RXF is generic, it means you do not need to select a specific environment when you download it, but it contains components for different RTOSes, targets etc, so you can
make the selection when you deploy your model into an IDE. Here is a list of what is contained:


RTOS

  • CMSIS (based on Keil-RTX)
  • CMSIS2
  • FreeRTOS
  • embOS
  • Linux
  • OORTX (our non-preemptive, highly efficient runtime system)
  • COORTX (non-preemptive, called periodically by your legacy software)
  • QNXNeutrino
  • ucOSII
  • Windows


Target Hardware

  • Any ARM Cortex via CMSIS layer
  • AURIX TriCore (HighTec)
  • Any target abstraction supported by an RTOS listed above
  • PC (Windows, Linux)

Compiler

There are no compiler dependencies. Any C++98 (ISO/IEC 14882:1998) compatible compiler shall work. On our continuous integration build server the following compilers are always tested:

  • Keil ARM V5
  • Keil ARM V6
  • Linux gcc
  • ARM Cross-gcc
  • Visual Studio 2017

IDE (Deployer Exporters)

  • Keil μVision 5
  • IAR Embedded Workbench 8
  • Green Hills Multi
  • Microsoft Visual Studio 2015/2017/2019
  • Directory Exporter, covering Eclipse based IDEs and makefile centric builds like:
  • TI’s Code Composer Studio
  • NXP’s CodeWarrior
  • Tasking VX
  • gnu make
  • CMAKE
  • SCons

Do you need something else to support your environment? Just contact us and we can give details about how it can be supported.

RXF V6 Patch for Rhapsody 9.0 Compatibility Available

Also customers of the RXF V6 can use it with Rhapsody 9.0, please read our support announcement for the RXF with Rhapsody 9.0.

Exciting News for our RXF C Customers

We expect to release a version 7 for the C language in the next months with huge improvements. It will also be generic (no dedicated release for each tool and target combination required anymore), will not require a Setup and will have a completely new and optimized approach for ports and interfaces code generation in C! We will keep you up to date.

That’s it! Happy modeling with Rhapsody!

Walter van der Heiden ( wvdheiden@sodiuswillert.com )

Paris Code Generation.

September 29, 2019 / / 0 Comments

Introduction

Lately I do a lot of my travel to France or via France. Of course we are now, as SodiusWillert, located in Bückeburg but also in Nantes (and in Detroit)
But that is not all France… I prefer flying by KLM and that comes automatically with Air France and the occasional stop-over in Paris CdG.
Not my favorite airport as my regular readers know.
But sometimes the flight is just more convenient or just cheaper via CdG.

Not this time, I actually had to be in Paris. Closer to Orly than to CdG so I decided to fly there. The KLM-Air France “El Cheapo” airline “Transavia” flies to Orly and it was really quite cheap. The reason for that became clear when I was sitting in the train to Schiphol: I received a text message that my flight was cancelled. 15 Minutes later an email arrived with my options:

  • fly on another day
  • fly to a different place
  • ask my money back.

neither of these options was what I wanted, so I called the Transavia Hotline. After 15 minutes of waiting (“It will come in time” – Billy Preston and Syreeta on repeat…) the call was answered and the train entered a tunnel… so after 15 more minutes I was again in contact.
“We are currently busy checking all passengers out”, “please call back in half an hour” she said. After some pressure she promised to call me back as soon as she knew more. Apparently she is not much smarter because she still hasn’t called me.

I already expected that and started calling after 15 minutes. The next call center person was not able to do anything for me, she said. I had to do that in Schiphol at the rebook desk in terminal 2.
In the meantime I arrived and went to the desk. I already figured out there were 2 flights with KLM-Air France to Paris. One in 45 minutes (do-able since I had only carry-on luggage) and one on 21:30 in the evening.

To cut a long story short, I had to visit 2 more desks to finally buy a new ticket (€ 600) to Paris because nobody could rebook my flight. Of course I had the late flight, missed the early one due to the slow response and the lack of information. And I was at CdG so the Uber took an hour instead of 10 minutes. Thanks Transavia!

Code Generation

But I arrived in Paris and had to speak the next day about Code Generation. I got the usual questions like:

  • “Why Code generation”
    because it’s the only way. Everywhere you look companies are already very low on staff, programming takes longer and longer, offshore programmers do not really help since we have to increase the effort for specification. Having code generated from a good spec dramatically decreases the time needed to deliver good quality software.
  • If that is so then why doesn’t everybody uses CG?
    We started selling Rhapsody with CG about 20 years ago. At that time there was no other tools that had CG. So sales people from all competitors would claim that CG was something nobody needed. A really annoying statement that is still haunting us (
  • We can just start by drawing pictures and then when we have learned UML we can try CG..
    Sounds like a cool idea. But it isn’t. think 25-30 years back. The time where ‘C’ came up. People were all using assembler and considered ‘C’ as being difficult, ‘C’-compilers were “eating memory” and everybody thought that this ‘C’ thing would go over because it wasn’t useful. Maybe only for documentation (Sounds familiar?)
    Now if you are using ‘C’ to document your code and you’d be programming assembler, what is the chance that you have learned ‘C’ after a few months? I can tell you: zero.
    You learn ‘C’ by developing in it and observe the compiler telling you what you did wrong. And after that the debugging of your programming. Then you learn ‘C’.
    Same thing with UML. You will learn that when you’ve seen and debugged the code. Not by just drawing pictures.
  • But UML is better for documentation isn’t it?
    Depends. As said before, just using UML without checking if you have done it right only increases the work you spend. Don’t forget that UML is a language with a lot of redundancy in it. You have to do a lot of work to create seamless documentation. Then why not generate code from it?

So what does a good UML Code generator needs?

We have tried to create an external code generator before (For EA, maybe you remember) This was not very successful, partly because there was no real integration.
Also many people thought they could take their existing models and then generate code from them, which is, of course, never going to work since you can do a lot in a UML Tool that does not make sense for Code Generation.
You can generate code from the following Diagrams:

  • Class Diagrams
    – Classes -> .cpp/.h (or .c/.h)
    – pointers or embedded classes for relations,
    – code for ports
  • State Diagrams
    – State machine that is connected to a class. All instantiated objects have this state-machine
  • Activity Diagrams
    – code for a Class, you can use a limited version to describe code for functions
  • Sequence Diagrams/Interaction Overview Diagrams
    – Lifelines are classes (Instances but they have to be classes first)
    – messages are events or operations. In theory it would be possible to generate behavior from Interaction Overview Diagrams.
  • Object Diagrams
    – Objects are Objects/instances
    – Links are assignments of object pointers to attributes
  • Package/Profile Diagrams
    – packages can have code, they need to bring the “glue” code for instantiating and connecting objects. Profiles influence the generated code.
  • Composite Structure Diagram
    – instantiates objects and connects them
  • Component Diagram
    – knows the relation of Components and could generate “make” files that links the correct components

No code is generated from:

  • Usecase Diagrams
    – Oh how we would love that, don’t we 😉 No, is not really possible. I would rather write something that generates code directly from requirements….
  • Deployment Diagrams
    – Not really feasible
  • Communication Diagram
    – Possible but who would want that?
  • Timing Diagrams
    – That is also possible but we haven’t worked that one out yet.

So we established that one of the important things for Code Generation is the integration with the UML Tool.
This needs to guide you with the model so that code can be generated from it.
Also we need to directly show the generated code in a window in the tool. Feedback is the most important thing.
Roundtrip and reverse engineering are very important. We need to able to change the code outside of the tool in “our favorite editor”. Also we must be able to use legacy code in an easy way.

  • Generated Code must be understandable by developers
  • it must be efficient in code size and in run-time behavior
    • at least as optimised as hand-written code
    • must satisfy timing requirements.
  • it must fulfil safety aspects if used in safety-critical systems.
    • code must be compliant with standards like MISRA
  • The generated code must be abstracted from RTOS/CPU and Compiler (The framework will do that)
  • it should not be unnecessarily dependent on other stuff

Up till today, there is still only one tool that does this way better than all others and that is Rhapsody. More than 20 years old and still going strong.

So. That’s it, have fun generating code with Rhapsody!

Walter van der Heiden wvdheiden@willert.de

 

Check, check, modelcheck….

August 16, 2019 / / 3 Comments

Introduction

Lots of times I get questions about model checks in Rhapsody. First of all if Rhapsody does model checks, the short answer here is: yes.
The longer answer is that Rhapsody does not check much, just if there are no errors in the model that prevent code generation.
You can start model check by hand (Menu: “Tools”, “Check Model”, “<<Configuration Name>>”. This will start a better Model Checker.
Does that check your complete model? Short answer: Yes. Long answer: Not exactly….
It does some checks like if you have added a description to your model elements and if you have changed the default names (Class_01, etc) But nothing more.
If you want more thorough checks you have to provide them yourself. This is not as bad as it sounds, the UML is a language, it is very difficult to check if somebody is using it in the wrong way.
If you want to check something you first have to define your model guide lines. How do you want to model. Then you can define how you want to check that.

Java API

Rhapsody has a Java API that allows you to (almost) completely control Rhapsody from extern.
You can use that to check the model, convert model elements, generate code and much more.
For check model you need to extend the model check interface and implement checks. Via the API you can walk through the model selecting elements based on type/name/position in the Browser Tree. You can access all information from the model and even change it when you like.
Same thing for Code Generation, you can, of course, walk the model and generate your own code but you can also instruct Rhapsody to call your Java functions when Rhapsody is ready generating code. We call that the Simplifier, Rhapsody will first take your model and generate a simplified model You can make that visible by setting: CPP_CG::Configuration::ShowCgSimplifiedModelPackage to TRUE.

Oh no… not Eclipse….

Yes… this works with Eclipse. Eclipse and I have a difficult relationship… We don’t like each other. It is getting better last years… but still not as easy as other IDEs.
You just create an Eclipse Java Project and you go to the properties of your project. Open the Java Build Path tab, then in Libraries open “Add External JARs”, now select the Rhapsody.jar file in “Share/JavaApi” . That’s all… should work now.

The Check

First Create a project (e.g. CustomChecksHelper). You can then create a class (e.g. CheckPlugin) that needs an entry point function:
RhpPluginInit (IRPApplication rpApp)
that will be called by Rhapsody. You can then instantiate all checks that you have made, all the classes that do checks have to extend RPExternalCheck and have to override the
check( IRPModelElement elem, IRPCollection failElem)
function.

Helper

Rhapsody uses “Helper” files to pre-load plugins. That makes them faster and immediately available. Therefor create a file under Share\Helpers with .hep as extension. The syntax of that file is quite cryptic, I always have to try 3 times before it works… Beware if you already have helpers then the numbers change.

[Helpers]
numberOfElements=1
name1=Checks_Plugin
isPlugin1=1
RhpVersion1=8.4
JavaMainClass1=com.telelogic.helpers.CheckPlugin
JavaClassPath1=$(OMROOT)\Helpers\CustomChecksHelper.jar

OK. That’s it! Have fun checking with Rhapsody!

Walter van der Heiden ( wvdheiden@willert.de )

Bromo active volcano mountain landscape at sunrise, East Java, Indonesia, Asia

Training in Bochum: Rhapsody in Java

January 24, 2019 / / 1 Comment

Introduction

I have been to Bochum before but I normally don’t use Rhapsody in Java… So still a “first”. I can program Java, however! Not as good as C but I’ll manage.

And I have to say… I like RiJ! It is really, really easy to use. Rhapsody brings its own Java so there is no need to install anything! It just works.

It’s a long time ago that I gave a training where all students had their “Hello World” running in minutes.

The Framework is, of course, much simpler, Java already brings everything you need to run UML generated code.

The only thing the Framework needs to do is to process the events and the timers.

Issues

There were not many issues with getting stuff to work. The most important thing was an issue when you installed Rhapsody and selected the wrong java Directory. But this is easy to repair.
in your Rhapsody Share directory there is an “etc” directory. In that directory you will find two batch files: jdkmake.bat and jdkrun.bat. These files have paths in them that need to point to the JDK that Rhapsody delivers by standard.

jdkrun_bat

 

jdkmake_bat

Hello World Example

The first program you make in any new language is “Hello world”. So we will create a Java Hello world.
Open Rhapsody in Java and create a new project. Call it “HelloWorld” and create it in a directory where you can find it back. (Rhapsody wants to create projects in the Rhapsody data directory by default.
When the project is created you will see an empty Object Model Diagram. Draw a Class (either select the Class from the drawing menu or right click in the diagram and select “Class”. Then draw the class. Call it “Hello” and give it a constructor, do not give it parameters.
In the constructor write ( in the Tab “Implementation” ) the following:

System.out.println”Hello World”);

Apply the change. Then we need an Object, right click on the Class “Hello” in the Rhapsody Model Browser and select “Make an Object”.
Then press “GMR” (Generate Make Run) and presto: it works!

 

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

 

Migrate Rhapsody Developer to EUSIII

July 18, 2018 / / 10 Comments

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 work!!!)
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)

Modeling with AUTOSAR

May 16, 2018 / / 2 Comments

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

autospice.gifOne 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.

automotive.png

Also mastering Complexity: Abstraction

The way to master complexity is the use of patterns (or abstraction). Abstraction can be explained by looking at this bunch of matches. If you need to count them, sorted like that, it is not that easy. So you sort them in groups, that makes it much easier to count. That is abstraction, you just follow the pattern and it makes it much easier. The disadvantage of this is: space/time drawbacks. You see that the matches take up more space if they are close together then when they are sorted.

csm_721435599Fuenf_Streichhoelzer_5780056202_6af0698c2e_o_129adc9027.jpg

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

csm_AUTOSAR_01_c35041dc46The 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

New Project.JPG

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.autosar project

You can now use AUTOSAR diagrams (Block diagram etc) and model that. You can export your model into an ARXML file that you can use for other tools and for the RTE Generation.

If you want to use “plain” rhapsody state-charts you first have to add a so-called “RIMBO”, connect the interfaces and then you can use “normal” rhapsody.

This is the way IBM recommends.
Since 8.3 you can safely use the 64-Bit version, in AUTOSAR: Do that! It will be slow otherwise.
You can combine 64 and 32 if you have an older version, import/export with the 64-bit, do the rest as 32-bit.

Method 2: Transform AUTOSAR and model UML

This is the “Willert” method. For the AUTOSAR stuff you use an AUTOSAR authoring tool. Then you export the ARXML from there and import that into Rhapsody using the AUTOSARXChanger. The result is a UML model with”converted” AUTOSAR elements. They are, however, normal UML elements with stereotypes.

autosarxchanger.JPG

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)

 

 

AUTOSAR in Noordwijk

May 6, 2018 / / 0 Comments

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 the 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 multi-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)

 

 

 

 

« Older posts

© 2026 Rhapsody TechBlog

Theme by Anders Noren — Up ↑