Table of Contents


The ARXF-CP allows you to use Rhapsody to model SW-Cs and generate C code for AUTOSAR Classic Platform without deep knowledge of AUTOSAR. One needs an AUTOSAR tool to configure the Basic Software and Runtime Environment. That tool will be able to export ArXML, which can be imported in Rhapsody to use M2M to create an initial model, based on the Software Component Descriptions found.

ARXF_CP_V8.0.1 is designed to support the following workflow:

The tool M2M can be used to transform a Rhapsody UML model based on the IBM Autosar profile into a model based on the profiles ArUML_ARXF and ArUML_ARXF_CP.

You can use the ARXF-CP to model your SW-Cs and generate C code.

The generated SW-Cs use runnables for executing the state chart of so-called reactive classes: you can send UML events between objects, just as when using any RXF. The ARXF-CP is instantiated per SW-C instance, so no data is shared between SW-Cs - only code in case of multiple instantiated SW-Cs. Per SW-C the ARXF-CP needs to be initialized and handle an event queue; the sample models contain SW-Cs which already have runnables which implement the ARXF-CP required functionality.

Apart from runnables required for the ARXF-CP (or use this sample code in your existing runnables), you can use use existing code. This product comes with an example of legacy code, where a runnable is called by the RTE and this runnable sends a UML event to an object in the model. You can also call existing functions (or runnables) from your model.


In ARXF_CP_V8.0.1 an AUTOSAR SW-C is represented by a structured class in Rhapsody: The structured class will hold the classes which are created statically as part of the SWC. For this, you can use a Structure Diagram where you can also specify the relation from a class to the SWC:

Because Rhapsody knows the relations between SW-C and a class, it generates the proper code to initialize the Objects class:

After code generation and generation of necessary include files (with defined constants) needed during compilation, you can have these copied to the AUTOSAR tool environment during Deployment, to have your SW-C build inside that tool.
The ARXF-CP consists of sources which are compiled with your generated sources and include files. It is designed to be instantiated per SW-C: any ‘global’ data is allocated per SW-C instance or prototype and no data is accessed from one SW-C instance by another to be fully AUTOSAR compliant.


A runnable in AUTOSAR is called by the RTE, for example periodically or when some data has arrived. It can be regarded as an operation in UML. A runnable can be characterized by its category: The samples which come with ARXF_CP_V8.0.1 use a few runnables for the ARXF-CP. The names of the runnables in the examples have meaningful names, but obviously these must match the names of the runnables mentioned in the Software Component Description file.

Per SW-C, the following runnables are used:

For the two runnables, you can can find sample code in the Standard Content of an SWC, which we used in the samples which come with this product.

You can influence the Rhapsody public names for runnables; see stereotype cpRunnable in Profiles on how to do this.

The Standard Content for a eventDispatcher runnable in an SWC shows an example of how to deal with the Exection Budget used in AUTOSAR. There is no explicit UML modeling support: you must restrict the number of UML events processed by an eventDispatcher runnable before giving control back to the RTE. The number used is an arbitrary value.

The stereotype cpRunnable has the tags category and supportsHoldFlag which are reserved for future use.

Exclusive Area

We use exclusive areas for our critical region handlers, see OS Integration. Per SWC we need two critical region handlers and per active class we need one critical region handler.

By default, we use an exclusive area and related RTE generated APIs as critical region handler, but you can override properties to use other functions.
Exclusive areas must be defined within the internal behavior definition of an SWC by an AUTOSAR authoring tool used for explicit access. The exclusive areas will be accessed using an explicit API. The accessing runnables are declared as having explicit access ("can enter") to the exclusive area, i.e. will use the Rte_Enter and Rte_Exit APIs. These enter- and exit functions of an exclusive area are generated by the RTE.

Within the RTE configuration it is defined which interrupts are blocked: this is ALL_INTERRUPT_BLOCKING or OS_INTERRUPT_BLOCKING, but also the BSW scheduler configuration and OS task types are of influence.

The critical region handlers use by default the function pointer pair (enter- and exit) generated by the RTE. You can override the default behavior via the Code Generation tab of the Configuration of the ARXF-CP.

InterRunnable Variable

The ARXF-CP uses at least one inter-runnable variable per SWC plus one inter-runnable variable per active class.

In our examples, we use an inter-runnable variable rhapsodyTaskPointerSwc and rhapsodyTaskPointerController to exchange ARXF-CP information between runnables. At initialization time, we store some internal information of an SW-C instance. Other runnables can retrieve this information to:

The inter-runnable variables are accessed via RTE generated functions to write and read the ARXF-CP information. For this, there must be a variableAccess stereotyped dependency between a runnable and an inter-runnable variable it reads and/or writes. See Profiles.

If you want to use PerInstance memory, you might want to modify the Standard Content for SWC with respect to the implementation of its runnables.


The OS tasks used are configured in an AUTOSAR tool and specified in the ArXML you exchange with your AUTOSAR tool. In the Rhapsody model, a TaskAllocationDiagram shows you the relation between classes and tasks and runnables and tasks.


Mapping Runnables to Tasks and Events
The mapping of runnables to tasks and events to runnables is done within the RTE configuration of an AUTOSAR tool.

Note that the ARXF-CP does not retrieve an OS TaskID or name from the OS.

A task name is inserted in an automatically generated call to RXF_Active_init(), when there is an allocate stereotyped dependency from a runnable to an OS task in your model. See Profiles.
Such dependencies can be drawn on a TaskAllocationDiagram.

ARXF-CP Event Dispatcher
An SW-C modelled in Rhapsody using the ARXF-CP has different kinds of runnables:
When a UML event is added to the event queue of another task, that task must be triggered by the RTE.
For this, you must use a function provided by the RTE if that runnable is not already triggered cyclic by the RTE. In our examples, we use a function which sends a dummy word, but you can also use an RTE API to send an inter-runnable event.

If you have the RTE configured to call a runnable eventDispatcherSwc or eventDispatcher periodically, you do not need to specify an RTE event trigger to be called by the ARXF-CP.

The RTE API to call as trigger can be specified on the Code Generation tab of the ARXF-CP Configuration. The name of the RTE API which is passed as function pointer is used during Code Generation.


You can model multiple SWCs in a single UML package. When an ‘init’ runnable of an SWC is called, it must call <yourSwc>_Init() to initialize the Rhapsody instance of the SWC including an instance of the ARXF-CP framework. The operation <yourSwc>_Init() does:

Rhapsody generates a structure for an SWC, for example SwcB.h   One of its members is of type RXF_SWC *, which is a structure used by the ARXF-CP. It contains a member isInitialized, which we can use to test in other runnables to prevent use of a non-initialized SWC.

Please inspect the Standard Content for an SWC.


You can use the SWCDiagram to show the relation between your SW-Cs via AUTOSAR ports in the root composition:

For communication via AUTOSAR ports you must use an API implementation generated by an RTE. These APIs are specified in the RTE generated contract for your SW-C and depend on the port type and type of communication. The APIs are standardized by AUTOSAR and an AUTOSAR Authoring Tool can create a contract for your SWC and implement the APIs. A mini-RTE can be generated to debug or test your model on Windows.

The ARXF-CP supports:

Runnables used for AUTOSAR port communication must have a dependency stereotyped by portAccess.

Please inspect the section Ports for further details and InteriorLight example for a sample implementation of AUTOSAR ports.


For Services you can use the stereotype CpECU-Abstraction-SWC to prevent code generation.
Services may appear in a Composition so you can connect the proper instances of SWCs with services.

Legacy Code

We advice you to use Reverse Engineering for legacy code. Source files and functions will become visible in your model and allows you to reference artifacts.



AUTOSAR tool vendors often support templates for C code. The property ARXF_CP::ArPackage::GenerateForAutosarTool can be set in Code Generation Configuration.