Why a Framework?
Actually quite easy. When you generate code from UML you need a lot more then ‘C’ or ‘C++’ can offer you. Java is different, it has a VM that does most of the things you need. But ‘C’… how do you start a thread in ‘C’? Or how do you start a timer in ‘C++’?
Right. You can’t. At least not in the base language, you need an external library for that.
The “extra” functionality in the UML is all RTOS based functionality. So it seems logical to use an RTOS for that. To make the use of any RTOS easier it is smart to implement this in a framework that does the translation to your RTOS. in that way, the only thing you need to do is adapt the Framework to your current environment and your UML model should be runnable in that environment.
In an embedded environment this is only part of the story, many hardware and even compiler dependant parts exist. Modeling certainly helps you but you should take extra care to separate your hardware dependant parts in your model.
Also the framework adaptation is not always straight-forward but the reward is high when you stick to the standard: you can be independent of the environment you use.
We have done a model conversion from one environment to another environment twice, both times it went with minimal effort. As close as you can get to the holy grail of embedded software development: platform independent programming. But I will be honest… we are a long way from reaching that in the embedded world.
There are quite a few Frameworks for Rhapsody. Out of the Box there are already a few. Are they any good? As always, the answer is: that depends….
On what? On what you want to achieve with it. Creating a PC application, Linux or Windows? Real-Time does not bother you, nor do you care about memory usage?
Than the standard OXF is your friend! It is the default in Rhapsody, you don’t have to do anything. If you are lucky enough to own a developer edition, animation, panel diagrams and webify are there to support you.
What Frameworks are there to choose from:
- OXF, standard Framework
Is not small, is not fast, is not deterministic, blocks interrupts for unknown time, uses an RTOS.
- MXF, MicroC (Automotive) Framework, uses OSEK as RTOS
in combination with the AUTOSAR import/export
- SMXF, reduced MicroC Framework
Targetted for use in Certification projects
- RXF, Willert Framework
Small, fast, C and C++, UML Target Debugger for back-annotation, enhanced Workflow, available as Cert with documentation.
- IDF – Interrupt Drive Framework
Single threaded. Started as a demo for “how the framework works”, is available and adaptable. Was designed to be small
- SXF – Simplified C++ eXecution Framework
C++ for Safety critical. Is also only static
- synchronous Framework
For very small environments, discards a lot of UML functionality, programming only with triggered operations.
- NOF, No Framework
For the real die-hard…..
- ?? Did I forget one?
So here we have a few criteria that you can use to support your framework decision:
- Code size, use an RTOS or just a main loop?
- Language, C, C++ or else?
- (Real-) Time behavior, are interrupts disabled? If yes for how long?
- Safety viewpoint, MISRA? Is there documentation about safety?
- Animation and Back-annotation, UML debugging available?
- Simulation, on PC?
- Hardware abstraction / Portability, fast switch to other environments?
- Memory Management, static or “half”-dynamic?
- Workflow, build in Rhapsody or elsewhere?
- Limitations, Ports, Container Classes, Dynamic, etc
Check the criteria before you make a decision. As you can see, the Willert Frameworks (RXF and RXF-Cert) have excellent notes on all items.
We use a model to test framework speed, the speed unit we have is PEPS (Processed Events Per Second) We have invented that ourselves since there was no other measurement available.
The model is there for use in other environments, it is pretty standard so it must be easy adaptable to other environments. Ask me if you want to have it!
Happy Modeling with Rhapsody
Walter van der Heiden (Email: firstname.lastname@example.org)