AUTOSAR

Table of Contents

Introduction

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.

SWC

In ARXF_CP_V8.0.1 an AUTOSAR SW-C is represented by a structured class in Rhapsody:

for an AUTOSAR SW-C which has the AUTOSAR property supportsMultipleInstantiation set to True, the RTE will generate a so-called self pointer as argument in a call to a runnable.
This self pointer is the address of the RTE instance or prototype of an SW-C. How many instances are created by the RTE depends on the rootcomposition in the imported ArXML.
for an AUTOSAR SW-C which has the AUTOSAR property supportsMultipleInstantiation not set, the RTE will not use a self pointer as argument in a call to a runnable. The RTE will generate a single instance of the SW-C, according to the rootcomposition in the imported ArXML

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.

Runnable

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:

category 1A used for short actions, like the receipt of data.
Category 1A runnables are only allowed to use implicit RTE API calls
category 1B for actions which terminate.
Category 1B runnables are additionally allowed to invoke a server and use explicit RTE API calls.
category 2 for endless operations.

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:

RXFInit to initialize the ARXF-CP like memory pools, event lists, etc. This ’init’ runnable must be triggered only once.
To do this, you can use the RTE InitEvent or if that is not supported in your AUTOSAR tool, use the AUTOSAR Mode Management feature or configure a single shot OS alarm and map that event to this runnable. This ’init’ runnable must have its tag isInitRunnable set for proper code generation, see Profiles.
eventDispatcherSwc to handle an event.
All classes with concurrency set to sequential at the UML level run in a single OS task sharing one UML event queue, whereas all active classes run in their own OS task. Each task for an active class has its own UML event queue.
This runnable is of category 2.

This runnable also serves as heartbeat for the ARXF-CP so must be called at a regular interval, for example every 10 msec. The frequency is configured in the RTE and must match the value on the Configuration tab of the RXF Configuration of RXF_MS_PER_TICK.

A runnable used as UML event dispatcher must have a dependency stereotyped by eventDispatcherActiveClass for proper code generation, see Profiles.
Per task, this event dispatcher runnable must be called. For this, we use an RTE event in our examples:
- when a UML event is placed into an event queue for a used OS task, we use an RTE event to trigger its UML event dispatcher
- depending on your RTE configuration, you can finetune this RTE event: when configuring different RTE events for different tasks, only the event dispatcher for that particular task is triggered and not multiple tasks.

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:

verify if the SW-C is initalized before excuting ARXF-CP code
manipulate SW-C instance data, like the timer ticks
use the proper UML event queue to handle UML events for that class

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.

OS

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.

RTE

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:

runnables which deal with the swc task, see Concurrency. All sequential classes run in this swc task:
- the ‘init’ runnable which is called only once to initialize the instance of SW-C including ARXF-CP
- the ‘timerTick’
- the ‘eventDispatcherSwc’ runnable which processes all UML events for the swc task. This runnable must be triggered by the RTE at a regular interval because it also serves as heartbeat for the ARXF-CP.
runnables which deal with an active class: the ‘eventDispatcher’ runnable which processes all UML events for that task

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.

the runnable eventDispatcher of an active class must be triggered when another task sends an event:
when a sequential class or another active class sends something to this active class.

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.

Initialization

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:

connect the Rhapsody instance to the RTE instance using information of the AUTOSAR composition:
- if the SWC supports multiple instantiation, a self pointer was passed by the RTE to the ‘init’ runnable. The address of the RTE instance of the SWC is ‘connected’ to the Rhapsody instance of the SWC. The Rhapsody instance is stereotyped by CpSwcPrototype, see Profiles. The stereotyped ArComposition tells the code generator the names of the RTE instances, see Profiles.
- if the SWC does not support instantiation, no self pointer was passed by the RTE to the ‘init’ runnable. The symbol of the only RTE instance of the SWC, known by the SWC, is standardized. The address is known and used to ‘connect’ to the CpSwcPrototype stereotyped Rhapsody instance of the SWC.
the framework uses an inter-runnable variable to store ARXF-CP task pointers: the ARXF-CP task pointers stored during execution of the ‘init’ runnable are read by other runnables. This way, when the RTE triggers a runnable, that runnable can retrieve the ARXF-CP context of its instance.
the SWC initialization function calls the RXF_SWC_Init() function to initialize the ARXF-CP instance in this SWC.

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.

Ports

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:

client/server ports.
Multiple client ports can be used by the same runnable.
Per server port interface a runnable can be used for communication.
The Helper interface2runnable can be used to generate a runnable per interface of a server port.
sender/receiver ports.
Multiple sender ports can be used by the same runnable.
Per receiver port a runnable can be used to allow so-called implicit read communication.
The Helper interface2runnable can be used to generate a runnable for a receiver port including a sample implementation.

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.

Services

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.

Notes

external source files are not part of any Deployment of the Rhapsody generated code.
The BlinkyPlusLegacy example shows how a runnable which is part of legacy code can send a UML event to an object.
existing runnables are regarded as functions. No properties are to be set: the code is not generated.

Integration

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