Getting Started examples

This Product ARXF_CP_V8.0.1 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 a few sample models:

The Rhapsody model BlinkySimple consists of one SW-C which toggles an LED. It 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.
the Blinky example is based on BlinkySimple but adds two SW-Cs, so this Rhapsody model consists of three SW-Cs:
- 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.
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.
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.
the BlinkyPlusLegacy example 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.
BlinkyPlusPorts which is an example how to use UML ports within an SWC
the InteriorLight example which shows how to use AUTOSAR ports, generate a mini-RTE and use the UML Target Debugger.

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:

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.0.1 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 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.

The examples which are based on StandardContent in one of the AUTOSAR profiles show how the Rhapsody and RTE instances are connected.

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:

AUTOSAR environment. We supplied projects with ArText files which you can inspect to understand the examples:
- RXFSimple-artext which contains one SW-C definition, a root composition and ECU extract for the ARXF-CP
- RXF-artext which contain three SW-C definitions, a root composition and ECU extract for the RXF
- RXFplusLegacy-artext which is a copy of RXF-artext but adds a ‘legacy’ runnable
In the section Adaptation to AUTOSAR Authoring Tool is described which AUTOSAR details must be specified to get BlinkySimple running in an AUTOSAR environment.

Visual Studio, like the free Visual Studio Express.
The Visual Studio examples contain three solutions: BlinkySimple, Blinky and BlinkyPlusLegacy. While modeling in the Rhapsody model BlinkySimple, Blinky or BlinkyPlusLegacy, you can use the Generate/Make/Run to generate code and deploy it to the appropiate Visual Studio solution. The VS project file will be updated by the deployer and you can build and debug the solution within Visual Studio.

Please continue to the BlinkySimple example part 1