Rhapsody TechBlog

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

Page 3 of 16

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

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

AUTOSAR

November 10, 2020 / / 0 Comments

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.

AUTOSAR Menu


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.

AUTOSAR Importer

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

Rhapsody AUTOSAR model

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.

M2M Workflow

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!

The AUTOSAR Workflow

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)

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

MesConf in COVID times

August 31, 2020 / / 0 Comments

Hi All!

Our yearly MesConf will, like any other conferences, be held online. It is what it is.
There are some advantages too, no travel, no maximum number of people and you can show up how you want, just keep your camera off… 😉
it will be held on September 17 and we have room left for interested people.

There are interesting presentations from Prof. dr, Alois Zoitl (Professor for cyber-physical systems for Engineering and production), Stephanie Borgert (Speaker, Author and Furtherthinker) and Martin Reiss (Chief Software Architect from Thales railway)

Of course I will be there as well (Speaking about using AUTOSAR together with UML and SysML) and many more of the Experts from OOSE, SodiusWillert, SiSy, IBM and many others!

Screenshot 2020-08-31 at 14.21.26.png

Here is the website (in German! Try to open with google translate if you want to read it in English)

The main message is here:

The subject is too important. Therefore, we will not skip the conference due to the corona risk, but will convert it into a one-day online conference.

MESCONF focuses on the benefits of modeling in the development of embedded systems. Another thematic pillar of MESCONF is model-based systems engineering (MBSE).

Our world is becoming more and more complex and dynamic. The constant change is one of the challenges for companies. Successful are those companies that can react flexibly and quickly to the changing requirements of the market with high-quality products.

We are convinced that modeling makes a crucial contribution to achieving this ability. We have formulated our values and convictions in a manifesto. At the conference we also want to talk and discuss the manifesto.

Tickets can be bought here at Xing.

I hope to 

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)

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 / / 7 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 elivered 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 off 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 )

Stay Home

May 6, 2020 / / 7 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 elivered 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 off 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 )

Nashville/Florida/Toronto

January 4, 2020 / / 9 Comments

I’ve been in the USA for quite some times. But Nashville was new, never been there before. So I increased my State count to 39! 11 to go.
The cheapest flight I could get was from Hannover. Via Amsterdam (which is closer to me, but don’t skip a leg, that’ll cost you….amazing in this time of saving the environment….)
So I got on the plane to AMS early for the stopover to… Toronto! I’ve been there before, twice. Nice city! There I would get on a plane to Nashville.

I was in Nashville for the Kick-off Conference of our beloved USA partner 321-Gang.

After the Kick-Off there was, luckily, some time left to visit Florida, a real must in winter time 😉 After 3 nice warm days I was on the way back ( ;-( ;-( ;-( ) But that was less easy then I thought… Again I would fly via Toronto but the plane coming from Toronto had a delay (Cause: medical Emergency…)
The information on the duration of the delay was very fuzzy. I tried to find out an alternative way to fly home but there was no real alternative.
So I gambled on the original flight that was earlier then expected.
It was, for hours and hours, on the tipping point of “Not going to make it” and “Just in Time”. I hate that.
To cut a long story short: The fact that I had to cross customs in Canada made me miss my plane.
So I had to spend another 24 hours in Canada. With only T-Shirts. And with -13ÂșC outside…
Luckily KLM was very, extremely good and they shifted my flight (They didn’t have to, i was on the cheap non-refundable flight) WestJet (Canada air-carrier operating for Delta) did not want to reimburse my Hotel costs.. “Use your insurance”…. Yeah I will.

Reverse and Roundtrip

In the last versions of Rhapsody we receive an increasing number of complaints about issues with Reverse and/or Roundtrip Engineering.

Issues

The issues are:

  • Reverse Engineering seems to start but does not give a result.
  • “Populate Diagram” is missing in the “Operation” menu

Rhapsody Version/License

A possibility is that your license is too old. What?? But everything works fine, except….
That is correct. Your old license also works for newer Rhapsody versions, I don’t understand that either, i’d link that to newer versions and support payments but hey, I know nothing about that….
So, exactly right. In some version of Rhapsody there was an entry added in the license file for Reverse/Roundtrip. Adding this solves the problem. You can generate a new license file in the License Key Center. (If you have a support contract with SodiusWillert (or Sodius or Willert or event somewhere else) we’ll help you.

32/64-bit

Most of these problems are related to the 32/64-bit version of Rhapsody. Due to some historic reasons the 64-bit version of Rhapsody lacked a lot of options that the 32-bit version had.
Also because of the way Windows is built, it is not easy to almost impossible to start 32-bit apps from 64-bit apps and vice-versa.

Solution

You can install both the 32-bit and the 64-bit version of Rhapsody even from the same install version. Remember that you then also need both Service Packs if you upgrade!
Then you can start 32-bit if you want to do stuff that involves any roundtrip or reverse engineering and use the 64-bit for everything else. Models are interchangeable.

So. That’s it. Have fun modelling with Rhapsody

Walter van der Heiden (wvdheiden@sodiuswillert.com)

« Older posts Newer posts »

© 2025 Rhapsody TechBlog

Theme by Anders Noren — Up ↑