Getting Started Example - Part 1
This Product ARXF_CP_V8.00 for AUTOSAR Classic Platform uses a structured class to represent an SW-C.
Within this structured class, you can model other classes which are part of your SW-C. An AUTOSAR runnable is an operation of a class.
The ARXF-CP uses global data like a timer queue, an event queue and so forth which are local to the instance of the SW-C.
All ARXF-CP code is shared amongst all instances of the same SW-C.
The product come with three sample models:
The Rhapsody models show how a structured class can represent an SW-C. The generated C code must result in SW-Cs which can be build in an AUTOSAR
environment. For this, several conditions must be met:
- BlinkySimple to toggle an LED.
This Rhapsody model consists of one SW-C which consists of two runnables:
- initializeRxf which initializes the ARXF-CP for this SW-C instance (prototype in AUTOSAR technology),
followed by initializing the SW-C instance itself.
- eventDispatcherSwc which is the heartbeat of the ARXF-CP. It is called at a regular interval, for example every 10 msec.
- Blinky to toggle an LED.
Blinky is based on BlinkySimple but adds two SW-Cs, so this Rhapsody model consists of three SW-Cs:
Each SW-C consists of two runnables, just like in BlinkySimple, but ControllerA (part of swca) and ControllerB (part of swcb)
which are both active classes, each have their own runnable eventDispatcher which is signalled by the RTE that a UML event
is placed in the event queue for the task of an active object.
- swca which is multiple instantiated. SW-C swca is much like swcb but multiple instantiated.
This example shows how runnables are called differently by the RTE and
all RTE APIs need an extra argument: the self pointer, which points at the RTE instance of the SW-C.
- swcb is much like swcb in BlinkySimple but with a major difference: it shows the difference between
sequential classes which all share the same single UML
event queue of the SW-C and active classes which
use a dedicated UML event queue and run in a different OS task and priority.
- swcc contains a Controller only.
A second difference between BlinkySimple and Blinky is that this example also shows how to re-use a class in more than one SW-C.
The LED class is inherited by LED_SwcA or LED_SwcB and the example shows how to use a different RTE contract but the same
statechart and operations.
- BlinkyPlusLegacy which is just like Blinky but shows how a ‘legacy’ runnable can send a UML event into your model.
One SW-C contains a runnable exampleLegacy which is called at a regular interval.
This runnable is an example of legacy code: some runnable triggered by the RTE. In our example, it calls a function which sends a UML event,
instead of ControllerB did in the Blinky example.
- the name of the SW-Cs, if an SW-C is multiple instantiated or not, the name of the runnables and how they are called by the RTE,
must match the Software Component Descriptions specified by an AUTOSAR authoring tool.
- one SW-C may not access data of another SW-C or -instance, even if the SW-Cs end up in the same binary, like in our examples in a single .elf file.
Furthermore, all code of a multiple instantiated SW-C can be shared between the instances, but data is not shared.
The ARXF-CP is instantiated per SW-C instance, so its code too is shared but its data is unique per SW-C instance.
It is not possible yet to specify memory sections for code and data: this restriction which will be fixed later.
- an SW-C must comply to the contract which is generated by an AUTOSAR authoring tool, for example Rte_Swca.h
Our examples show how the contracts for swca, swcb and swcc are used.
Your model must use contracts generated by an RTE generator.
Note that multiple contracts may not be included in a single source: RTE generated types are specific per SW-C.
Our Blinky example shows how the LED class can be re-used in swca and swcb, using static inheritance in Rhapsody.
- an SW-C can access Basic Software and other SW-Cs only via ports. Because an AUTOSAR authoring tool will generate the RTE
including communication via the ports required, the Rhapsody model must not generate code for using such ports, but use existing
RTE generated APIs instead.
The product ARXF_CP_V8.00 for AUTOSAR Classic Platform has been designed to allow UML modeling without deep knowledge of AUTOSAR.
It requires little configuration in an AUTOSAR authoring tool to get your models to run. At the same time you can use UML
constructions like sequence diagrams and state machines which you can use with any RXF, so the Rhapsody models are portable to large extend.
Because the ARXF-CP uses little AUTOSAR details, the Rhapsody models use SodiusWillert AUTOSAR Profiles with only a few stereotypes plus so-called StandardContent,
which you can regard as a sort of copy&paste way of realizing code.
Rhapsody generated C code relies on allocation of objects:
the SW-Cs which are normal structured classes must be instantiated - either once or in our example in case of the multiple instantiated swca even twice. The RTE of an AUTOSAR authoring tool will instantiate these SW-Cs; in AUTOSAR terminology these are called prototypes.
The examples which are based on StandardContent in one of the AUTOSAR profiles show how the Rhapsody and RTE instances are connected.
- the Rhapsody generated code for an SW-C contains the relations to the parts within the structured class, like a Controller and
LED object, plus the runnables, code to initialize the SW-C, etc.
The runnables are from a UML point of view just operations, except that they are called by the RTE.
- the RTE generated code is the glue between the SW-Cs and Basic Software: it contains references to the runnables and
contains details for the RTE to allow the SW-Cs to communicate via ports with their outside world.
After code generation in Rhapsody, the code must be deployed to the environment where it is compiled and executed.
The product and thus the examples included support two environments:
Please continue to the BlinkySimple example