The Blog for Rhapsody (Power) Users.

Month: January 2018

Task, Process, Thread

Introduction

On the way back from the US I decided to write something about a question that I received multiple times.

What is a task in Rhapsody? Or equivalent questions using different words but are all about the same topic: task, process, thread.
You can use Wikipedia to read about it, I did too and it will help you, but I will give you my interpretation. which is not necessarily the correct one but I can live with it.

The main difference between a process and a thread is the memory space. threads share the same space, processes have their own memory space. A task can be both, it just indicates that something is running independent from other tasks.

So what is an active class in Rhapsody? That is not specified in particular but for most frameworks it is a thread. “Normal” Rhapsody code runs in the same memory space, it has to, if you send an event to another object, you need to know the “me-Pointer” of that object, which, inevitably has to be in the same memory space.

Hmm so it is not possible to use processes as Rhapsody “tasks”? Oh that is possible but you need a different framework. And a not so easy framework, It is called “distributed Framework” or short”DOX”. The adaptation to an operating system is much trickier in such a system since there is a lot of difference between the methods of inter process communication. You basically have to “register” all tasks and create a function that can communicate between tasks using shared memory or whatever mechanism your OS offers you.

Sending an event means that you have to serialize the event (and, if there, its parameters) then store it in shared memory, notify the OS. Than the OS in its turn will provide it to the receiver that receives it, unserializes it and put it back in the structure.

Solutions

There are other ways to still use Processes when writing an Application in Rhapsody.

  1. You can, as described above, implement a different Framework and use the available interprocess communication. The advantaged is that the Rhapsody model can be kept unaware of that and is still portable to other environments.
  2. On some CPU’s (for instance ARM Cortex) you can use memory protection in a special way. In that way you can use the same memory space but only allow certain functions access to certain memory ranges. This is a proprietary solution, not portable but since the hardware will checked everything, safe and small.
  3. The last way is to use a normal framework, create processes when you have an active class and then implement the shared memory in a class that has all communication addresses “Pre-compiled” You can take an instance of that class in each process. You cannot send events since the message queues are in different memory spaces so you have to communicate differently.
    There is no real difference between a single app with multiple processes at multiple apps. You might as well create a component for every process and include the communication in each and every one.

So. Hope this helps. Happy Modeling with Rhapsody!

Walter van der Heiden ( wvdheiden@willert.de)

Back to Work. Question of the Week: Windows or Linux

So. The nice and quite days after Christmas and New year are over. Back to work means: back to travel. A small one to start, yesterday evening I drove to Bückeburg, this week I’m in the office the complete week. Then we slowly increase the travel distance (Nantes, Bristol, Boston,…)

Introduction

Lately people ask me if they can use Rhapsody “native” under Linux.
Short answer: Please NO!
Long answer: No it is not really usable under Linux. It is simply the Windows version that runs under Linux because the graphic engine happens to work under Linux as well. A lot of features will not work (See list below)
This only makes sens if you have a compiler that runs under Linux (or your target environment of your Rhapsody Development is Linux)
If you really insist on doing your daily work under Linux then install VmWare and install Windows in a Virtual Machine. I have the same on my Mac.
Question: But VmWare is not free!
Answer: Grrr, i should have known…  Then take Virtual Box. or try Wine (I don’t know if it works but I expect it to)
At least you can create a shared drive where Rhapsody can generate (or in case of RXF, the deployer will deploy) the source code to.
Or you setup an rsync between the Windows VM and Linux.

Trust me, this is the best way to do it. The Linux version was never really developed as a native Linux application and therefor does not use any of the Linux advantages.
Walter Quote #1: It is always surpising to see how much money people are willing to invest to be able to use Linux for free.
Happy Modeling with Rhapsody (under Windows)
Walter van der Heiden (wvdheiden@willert.de)

Features not available in Linux version of Rational Rhapsody 8 releases

Abstract

Features listed in this document are not available in the Linux version of the IBM Rational Rhapsody version 8 releases.

Content

  • Android application development (feature completely removed in release 8.1.4 of Rhapsody)
  • Automatic Test Generation (ATG) add-on
  • Breakpoint synchronization is not supported in the Wind River VxWorks 6.9 and Wind River Workbench 3.3 integrations
  • C# application development (feature completely removed in release 8.1.4 of Rhapsody)
  • CORBA development
  • Configuration management SCC mode
  • Customizable code generation
  • Eclipse platform integration
  • Functional Mock-up Interface (FMI)
  • Generate support request
  • Helpers can be used, subject to the following limitations:
    • Helpers that are set up to be triggered by actions such as code generation will not work with RhapsodyCL on Linux.
    • When using Java helpers, the JRE used must be the one installed with Rational Rhapsody or a different IBM Java JRE. Also, the JRE cannot be within a ClearCase VOB.
    • Arguments cannot be passed to Java plugins.
  • Import from Rational Rose (feature completely removed in release 8.1.4 of Rhapsody)
  • Languages: Japanese, Korean, Simplified Chinese, Traditional Chinese
  • MathWorks Simulink integration limitations:
    • Managed Mode for Simulink
    • Plant Modeling (exporting a structured block to Simulink for simulation)
  • Microsoft VBA (feature completely removed in release 8.1.4 of Rhapsody)
  • Microsoft Visual Studio integration
  • NATO Architecture Framework (NAF) version of Unified Profile for DoDAF/MODAF (UPDM)
  • NI VeriStand (feature completely removed in release 8.2.1 of Rhapsody)
  • Oracle Java for plug-ins (JVM)
  • Parametric constraint evaluator
  • Rational Rhapsody apps cannot be developed in Linux with SWT libraries. (Note that you can develop Rational Rhapsody apps with Eclipse in Windows and use them for both Linux and Windows.)
  • Rational Rhapsody 64-bit application
  • Rational Team Concert integration
  • Rhapsody Model Manager (feature introduced in release 8.3 of Rhapsody)
  • Safety Critical Development in C
  • Siemens Teamcenter integration (feature completely removed in release 8.2.1 of Rhapsody)
  • SMXF (Simplified/reduced MicroC Framework for C)
  • Split diagrams during export
  • SXF (Simplified eXecution Framework for Safety Critical developers)
  • Target monitoring
  • TestConductor add-on limitations:
    • Cannot be used with Rhapsody in Ada
    • Does not work with RhapsodyCL. As an alternative, you can use the command line of rhapsody.exe with command line option -hiddenui.
    • Integration with Rational Quality Manager 4.0 not supported
    • AUTOSAR SWCs not supported
    • VxWorks 653 platform not supported
  • VxWorks 653 integration
  • Web-enabling a model (Webify)
  • Wizards that help create ProxyPorts
  • XMI Toolkit add-on for Rational Rhapsody is not compatible with RhapsodyCL

If it ain’t broke, don’t fix it….

Introduction

I’m not a fan of updates. A few years ago I always switched off my automatic updates. On a Mac that was possible and would hardly have other consequences.
Unfortunately, this is not the case anymore. Modern development methods like DevOps, Agile, Continuous Engineering and I_don’t_know_how_it_is_called are forcing you to keep your system up-to-date. Either Apps don’t work with the latest OS or an App requires a certain minimum version of the OS.
Many systems do not even allow you to wait with updates, even my beloved Mac starts whining and will update without asking.
Walter Quote #2: If it aint broke: Don’t fix it!

Rhapsody

The same applies to Rhapsody. Newer versions will have improvements, bug fixes and sometimes new options or features. Since 8.1.3, IBM will at least deliver so-called iFixes that enclose bug fixes for the most serious bugs. (Check our download portal or the IBM website to download the iFix for you Rhapsody version. You only need to install the highest number, it will contain all previous iFixes for that version.
Here is a list with all versions (and Build numbers) since 8.0.
8.2.1

9810341

5 june 2017

Rhapsody Version Build Number Release date
8.3.1

9835533

24 june 2018
8.3

9831308

4 dec 2017
8.2

9803403

1 dec 2016
8.1.5

9728113

25 april 2016
8.1.4

9641846

14 dec 2015
8.1.3

9499822

26 june 2015
8.1.2.1

9278208

20 feb 2015
8.1.2

8254044

5 dec 2014
8.1.1

8200000

5 sep 2014
8.1

8169320

2 jun 2014
8.0.6

7155987

28 feb 2014
8.0.5

7139044

5 dec 2013
8.0.4

6118532

3 sep 2013
8.0.3

6107223

14 jun 2013
8.0.2

5093211

21 mar 2013
8.0.1

5074847

27 nov 2012
8.0.0.1

5071232

8 nov 2012
8.0

5066837

21 sep 2012

De-install the old one?

You don’t have to. You can install multiple versions of Rhapsody in parallel. A few things to consider:

  • Install in the same way as the previous version (Same directory structure)
  • The last installed version is the default version that will start when you double-click a .rpy file.

Models

You don’t have to do anything to update your models. But…. As soon as you save a model it is updated and cannot be opened with older versions of Rhapsody anymore. (Not always, sometimes 2 consecutive versions use the same database version.)
You can, however, use “Save As” to save the model in an older version. You can do that 2 versions back. So not too much.
Here is a list with the Rhapsody Versions and how they can be “saved” back.

Rhapsody Version „Save As“
8.3 8.2.1, 8.2
8.2.1 8.2, 8.1.5
8.2 8.1.5, 8.1.3
8.1.5 8.1.3, 8.1.1
8.1.4 8.1.3, 8.1.1
8.1.3 8.1.1, 8.0.6
8.1.2 8.1.1, 8.0.6
8.1.1 8.0.6, 8.0.4
8.1.0 8.0.6, 8.0.4
8.0.6 8.0.4, 8.0.2
8.0.5 8.0.4, 8.0.2
8.0.4 8.0.2, 7.6.1
8.0.3 8.0.2, 7.6.1
8.0.2 7.6.1, 7.5.3
8.0.1 7.6.1, 7.5.3
8.0 7.6.1, 7.5.3
7.6.1 7.5.3, 7.4

Of course a new version of Rhapsody can have changes in Code Generation. Best is to install a new version, start the old version, generate code, start the new version, load the model, generated code (In a different directory!!) and compare the code. If it is the same, you’re good. If different, first compile, you might still be good. But if it doesn’t work, try to understand the consequences of the changed code.

You will have some “Settings” files in your browser that are named “CGCompatibilityPreX.Y”. These files include the changed properties.

RXF

You MUST re-install the RXF and then during install tell the RXF the right directory for the new version of Rhapsody. (It will usually detect it automatically)
You can load the older models if you do not install the RXF but it will not work.

Eclipse

If you use Eclipse you have to either re-install the Eclipse plugin (first de-install the old one and then re-install the new one!)
If you want to use 2 versions then you will have to install Eclipse twice (I have not found any other way to do it…) and install the Eclipse Plugins/Workflow for the newer Rhapsody version in the second Eclipse.

ReqXChanger

Easy to forget… If you use the ReqXChanger, you have chosen the rhapsody.jar that matches the Rhapsody Version you use to sync your requirements with.
You have to edit the configuration to allow for ReqXChanger to use the new version of Rhapsody!

Happy Upgrading (and modeling) with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

O….M….G….

The OMG is the keeper of (amongst others) the UML and SysML standard. Today they have released the UML 2.5.1, a relatively small release. As far as I know there are no immediate plans for a UML 2.6 nor a UML 3.0.

The changes are not shocking and you will probably not even notice it. But I wanted to give you a small look into the factory of the standard.

You can read about this on the website of the OMG ( http://www.omg.org ) but also on the special UML website: ( http://www.uml.org )

In spite of what most people think: the standard is much more readable than you would expect. Not all of it, there ar “boring” parts in there but it is readable and it can answer your questions on how to apply the UML to your development.

Interesting Articles

This is an article telling about the UML. Where does it come from, what does it do, how should you use it.  http://www.uml.org/what-is-uml.htm

The past, present and future of visual modeling: http://www.uml.org/Visual_Modeling.pdf

The UML Specification: http://www.omg.org/spec/UML

Happy Modeling with UML (and SysML!) in Rhapsody!

Walter van der Heiden ( wvdheiden@willert.de )

Memory Management in the RXF

Introduction

Many users have asked me how they handle Memory Management when they use the Willert RXF as Framework.

There are 3 types of memory usage in C/C++:

  • Compile time (or static)
    this means that you declare something and the compiler/linker will take care of locating and allocating memory for it. (e.g. char MyArr[20]; will declare a 20 character array)
    You can find variables like this in the linker map file.
  • Heap
    This is what malloc uses and what many RTOSes use when allocating memory for their structures.You cannot find it in the map file specifically, you will find the heap size there. But the variables that use it are located in run-time.
  • Stack
    The most dangerous one… local variables are located on the stack as are function calls. compilers and or RTOSes offer stack check routines but they can be not reliable. Mostly they work with a standard pattern that is written on the stack (0xAA or 0x55) and compare that after each function call.

The RXF uses its own memory management. If you select the <<RXF Component>> stereotype for your current component and generate code for it, there will be „malloc()“ statements in the generated code.
But… this does not call malloc. Instead these calls are mapped (using a macro in WSTmodelling.h) to a function called WST_MEM_getMemory().

This function uses predefined and pre-allocated memory blocks. This shifts the use from heap to compile time.Why are they there and why do we not use malloc?

Easy. We do not use malloc for two main reasons:

  • Memory de-fragmentation
  • Malloc is non-reentrant.

Using our own memory allocation routines solve both problems. Our routines are protected using semaphores and because we only have pre-defined sizes, fragmentation cannot occur. How does this work?

There are a couple of properties that define size and number of these predefined blocks. Here we can define the exact size (in bytes) of each block type.There are 5 different block types:

– Tiny, Small, Medium, Large and Huge

The properties where you can define the number of blocks and the size are called:

- C_CG::Configuration::WSTTinyBufferSize - C_CG::Configuration::WSTInitialTinyBuffers

- C_CG::Configuration::WSTSmallBufferSize - C_CG::Configuration::WSTInitialSmallBuffers

- C_CG::Configuration::WSTMediumBufferSize - C_CG::Configuration::WSTInitialMediumBuffers

- C_CG::Configuration::WSTLargeBufferSize - C_CG::Configuration::WSTInitialLargeBuffers

- C_CG::Configuration::WSTHugeBufferSize - C_CG::Configuration::WSTInitialHugeBuffers

Setting the number of a certain type of blocks to 0 will remove every bit of code used for that specific block type.

NOTE!: make block sizes sequential increasing. So Tiny MUST be the smallest and Huge MUST be the largest. Otherwise the getMemory function will not work properly.

Taming the RXF

The properties for setting these sizes are available in Component and Configuration, we recommend setting them in your configurations. In that way you can easily create other configurations with different sizes to experiment.

Can I check how many blocks I have used and if they have the right size?

Yes you can check how many blocks you have used, check the HighWaterMark section. The size is a bit more difficult.You need to check the map file for the sizes of the elements that you allocate. You can also enter your debugger, set a breakpoint to the WST_MEM_getMemory routine. Each time you enter the breakpoint your application is requesting memory. Check the „requested_size“ variable and write them down.The call stack will reveal which routine requested memory.

As a rule of thumb: use one block type for events, one for events with parameter, and one for small classes. Set the other two to 0 so they won’t be there. Only use them if you want to use a finer use of your available memory. For larger classes use static allocation. If you use tasks, you will need memory for the allocated message queues, calculate their size and use another block type for that.

The best way to check how many blocks you have used is off course to use the Embedded UML Target Debugger, it shows you these numbers directly!

What to do if I run out of free memory blocks?

The allocator tries to use the best fitting block. So if you have blocks of 10, 20,30, 40 and 50 bytes, allocation 8 bytes will normally give you a 10 bytes block.When these are not there, you get a 20, then a 30 and so on.

If there is no fitting block left there are 2 options depending on the defines you set when compiling.

– The program will call the error routine with the Error:WST_ERR_ALLOC_TOO_LARGE.

You can (or actually should) change the error routine and adapt it to your own needs. (e.g write in a logfile or something like that)

– The original malloc routine is called.

This will only succeed if you reserved enough heap space so that malloc can give you the memory that you need. If not you will inevitably run into some kind of trap for using illegal memory.There are RXF versions that run into the error handler (Error:WST_ERR_ALLOC_FAILED) when malloc returns NULL.

What Defines and Properties influence the memory usage?

Using Tasks will also use your predefined memory blocks. Every task has a message queue, depending on the used RTOS there will be memory allocated for that.There are properties for tasks that influence the used memory.

CG::Class::ActiveMessageQueueSize will set the message queue size.There is a default size, this is what the RXF uses if you do not define your own.The size of the message queue is defined as „number of messages“.A message in UML is an event and it is sent by reference so there is only one pointer per message.The size of the pointer depends on the used CPU/Memory model. So on an ARM Cortex with the Keil compiler this means that a message queue size of 20 will use 80 bytes of blocks.

The Timer Array is static, it is depending on the property C_CG::Configuration::WSTMaxTimeouts. The array is allocated at compile time.

WST_CFG_HIGHWATERMARKS.When set to true, extra code is used to keep the largest number of reserved blocks.You can check the number in theWillert Embedded UMLTarget

Debugger or in your own source code debugger by typing „highwater“ in a watch window.This is an array that will show you the actually largest number of used blocks.

NO_MALLOC.When set, this will cause the RXF to NEVER use malloc. Rhapsody generated code can still use malloc, but the framework will not.

WST_FORCE_ALLOC_TOO_LARGE. Causes the RXF to use malloc when it runs out of memory blocks.

 

That’s it for today! Happy modeling with Rhapsody (and the RXF of course!)

Walter van der Heiden (wvdheiden@willert.de)

Happy New Year!

I wish everybody a “model” 2018! I had a little break during the christmas and new year holidays. Traveling is cool, but even a modeling traveler needs some rest once and a while.
But now we started a whole new year, 2018, and we have lots of plans to improve modeling in embedded.
IBM is also cooperating, they released Rhapsody 8.3, a brand new version with lots of changes!

AUTOSAR: migration of models to older versions of AUTOSAR

In release 8.3, for migration of AUTOSAR projects to an older version of AUTOSAR, additional target AUTOSAR versions have been added.

Code-centric mode: roundtripping changes to operation signatures

Prior to release 8.3, in code-centric mode, if you renamed an operation or modified its parameters and then roundtripped the code, the old operation was automatically removed and a new one was created in its place.

Beginning in this release, when roundtripping such changes, you have the option of retaining the existing operation and having it marked with a stereotype called MergeCandidate. After roundtripping, you can then go through these operation and merge them with the new operation that was created. The new operation body and declaration will then be copied to the existing operation, which will retain any other existing information such as dependencies. The second operation will be discarded. To enable this option, set the value of the property MarkMergeCandidateOperations to True.

Code-centric mode: support in 64-bit version of Rhapsody

You can now use code-centric mode in the 64-bit version of Rhapsody. However, code cannot be generated while in code-centric mode.

Configuration Management integration: renaming/deletion of Rhapsody units

Prior to release 8.3, if you renamed a Rhapsody element that was saved as a separate unit, the name of the file representing the unit would always keep its original name. Beginning in this release, if you configured Rhapsody to use the integration with Rational Team Concert (using the CMTool property), then when you rename a model element that is a unit, you will be asked whether you want to also change the name of the underlying file. This behavior can be controlled by the property RenameActivation.

Similarly, if you delete a unit, you will be asked whether you want to also delete the underlying file. The deletion behavior is controlled by the property DeleteActivation.

Modeling: “satisfy” stereotype in non-SysML projects

The “satisfy” stereotype, previously available only in SysML projects, can now be applied to dependencies in all Rhapsody projects.

Modeling: ownership of dependency between two other elements

Beginning in release 8.3, an element can be the owner of a dependency between two other elements. Among other uses, this makes it possible to create a dependency between two read-only model elements.

Modeling: selection of type for flowport

Now, when you try selecting a type for a flowport, the dialog remembers the last location used, allowing you quicker access to the relevant elements.

 

Rhapsody repository files: move to XML format

Beginning in release 8.3, the files used to save Rhapsody models are in XML format. To help differentiate between the new repository files and the repository files used in previous releases, the letter x has been added to the file extensions. For example, the main file for the project now uses the extension .rpyx instead of .rpy. Existing projects that are saved in version 8.3 of Rhapsody will be saved in the new format.

Statecharts: multi-line display of code for entry action, exit action, and internal transitions

Prior to release 8.3, in the graphical compartment used to display the code for a state’s entry action, exit action, and internal transitions, each of these items was allocated a single line, regardless of how long the code was.

Beginning in this release, there is an option to have the compartment display multiple lines of code when required. For individual states, this can be set in the Display Options dialog. If you want to set this as the default behavior in all your projects, you can add the following property to your site.prp file with a value of True: General::Graphics::SupportMultiLineCompartment.

Support for Red Hat Enterprise Linux 7.2

Rational Rhapsody can now be run on version 7.2 of Red Hat Enterprise Linux.

TestConductor/ATG: information about model elements not covered

In TestConductor and ATG, requirement coverage results now also include information about the model elements that are not covered.

TestConductor: testing of private/protected operations

Beginning in this release, TestConductor includes an option for testing private and protected operations by calling them directly. See the example and related documentation in the TestConductor Testing Cookbook.

TestConductor: user guide for assertion-based testing

The documentation for TestConductor now includes a new user guide (TestConductor_User_Guide.pdf) that deals only with C/C++ assertion-based testing mode. The existing user guide (RTC_User_Guide.pdf) now deals only with animation-based testing mode (Ada, Java, and C/C++).

User Interface: enhanced dialog for setting display options

Many element types now use a common tab-based dialog for setting display options.

User Interface: use of new combo box for filtering

A number of dialogs now use a new combo box that dynamically filters list elements as you type.

XMITookit: UML 2.4.1 namespace

XMIToolkit now recognizes the UML 2.4.1 namespace

XMIToolkit: activities with horizontal swimlanes

Now, when importing activities that contain horizontal swimlanes, the swimlanes are rotated so that they can be brought into Rhapsody.

In the next week we will test 8.3 ourselves and check compatibility with our RXF.

Happy modeling with Rhapsody in 2018!

Walter van der Heiden (wvdheiden@willert.de)

© 2025 Rhapsody Tech Blog

Theme by Anders NorenUp ↑