Getting Started Example - Part 4
The example Blinky is found in <ARXF_CP_V8.00 installation folder>\ARXF_CP_V8.00\Samples\Autosar\Model\Blinky
The example Blinky is in fact extending the BlinkySimple example to show a few topics:
- how to use multiple SW-Cs in a single Rhapsody model
- how to deal with a multiple instantiated SW-C
- how to use the same class in different SW-Cs
- how to use an active class which runs in its own task using its own UML event queue
Open the Rhapsody project Blinky:
The ArPackage RXFApplicationLayer contains:
The ArPackage CompositionPackage contains:
- SwcA which is an active class running in the so-called swc task. The derived objects swca1 and swca2 are statically allocated.
The profile ArUML_ARXF_CP has a stereotype CpSWC defined as New term
so you can create SW-Cs easily. An SW-C has runnables, inter-runnable variables and exclusive areas, but apart from that it is a normal UML class.
The tag supportsMultipleInstantiation is set to True so for runnables a so-called self pointer is passed by the RTE as argument,
which points at the RTE instance (prototype in AUTOSAR terminology) of the SW-C.
- SwcB and SwcC are active classes, each running in their so-called swc task. The derived objects swcb and swcc are statically allocated.
SwcB and SwcC are using the CpSWC stereotype.
The RTE will call their runnables without self pointer.
- LED which is a seqential class. All sequential classes of an SW-C run in its swc task
- ControllerA, ControllerB and ControllerC are all active classes: each runs in its own task for SwcA, SwcB and SwcC respectively.
An active class has its concurrency set to active and uses its own UML event queue.
- ECU-abstraction ioHwAb for which no code is generated but it is used to show the relation between SW-Cs and abstract hardware
on the SWCDiagram. See AUTOSAR section Ports.
- the prototypes swca1, swca2, swcb and swcc which are the instances of SwcA, SwcB and SwcC.
- serviceIoHwAb for which no code is generated but it is used to show the relation between SW-Cs and abstract hardware
on an SWCDiagram.
The SW-Cs contain a few AUTOSAR specific details:
The symbols for the runnables are public symbols, but instead of having any declaration generated by Rhapsody, we rely on the RTE generated contracts.
The Rhapsody generated code for an SW-C must include the contract generated by the RTE: SwcA.c must include Rte_Swca.h and so forth.
Such contract may not be included twice in the same source, nor is it allowed that sources of an SW-C include a contract of another SW-C.
So SwcB.c may not include Rte_Swca.h and/or Rte_Swcc.h - only Rte_Swcb.h
- SwcA contains the attribute self which is a convenient way to store the self pointer used by the RTE when calling a runnable.
In case your model needs the self pointer, because it is used in every API the RTE generates for an SW-C which supports multiple instantiation,
it is easy to use a class attribute so you can use it any time you need it.
Note that SwcB and SwcC do not have this attribute: their runnables are called by the RTE without argument.
- exclusiveAreas. The ARXF-CP needs a critical region handler when manipulating the (UML) event list, memory pools and timer list. Using an AUTOSAR exclusive area
allows us to use an RTE generated entry- and exit function as critical region handlers.
The exclusive areas must be defined at the AUTOSAR authoring tool per SW-C.
- runnables. For SwcA these are called with the self pointer as argument, the runnables of SwcB and SwcC are called without argument.
Note that the runnables are not prefixed with the class name. Rhapsody will generate the class name as prefix,
so when the generated C code of SwcA, SwcB and SwcC ends up in a single ELF file, so there will be no name conflict.
The behaviour of how Rhapsody generates the symbol for a runnable can be influenced via a property, see CpRunnable in Profiles.
Using properties at the SW-C and runnable level, we get exactly what we want.
The profile ArUML_ARXF_CP contains these properties and some StandardContent as well.
You can inspect the code for a runnable by double-clicking on it, to show its Features. The Implementation tab shows the code to generate:
- initializeRxf which is called only once by the RTE.
Such a runnable typically initializes the ARXF-CP (as it is instatianted per SW-C instance) by calling <yourSwc>_Init().
- eventDispatcherSwc which is typically called every 10 msec.
This runnable serves as UML event dispatcher as well as the heartbeat of the ARXF-CP. The counter is per SW-C instance and used to calculate if a
timeout event occurs for some object. See section Realtime behavior.
The cyclic calling of this runnable must be configured in the AUTOSAR authoring tool.
It calls RXF_Active_eventDispatcher() to process a (UML) event in the swc task.
Each task has its own event queue. All sequential classes run in the swc task: the LED object in our example. The class toggles between on and off.
The operations on() and off() are implemented using the calls generated by the RTE:
- the Basic Software is configured to have an LED which can be accessed via hardware abstraction module
- the root composition which includes the definitions of the SW-Cs, their instances or prototypes and ports results in artifacts used in the configuration of the RTE.
- the call Rte_Call_Digital_LED_Write() is in fact sending the proper value for the LED via the proper port to the hardware. Because SwcA is multiple
instantiated, this function uses the self pointer so the RTE can use the proper RTE instance of this SW-C.
- eventDispatcher in an active class like ControllerA. It first tests if the SW-C instance is initialized and if so,
it calls RXF_Active_eventDispatcher() to process a (UML) event in this particular task.
An SW-C is represented by a structured class. It contains parts, to enforce static allocation of the objects which build up a particular SW-C. SwcA contains
ControllerA and LED_SwcA. LED_SwcA is inherited from LED, because we want to re-use the LED class in multiple SW-Cs,
but AUTOSAR does not allow LED.c to include generated RTE contracts of multiple SW-Cs.
When the timer of the controller elapses, it sends an event to the LED
In AUTOSAR, OS tasks are created statically and do not terminate. The tasks are configured in an AUTOSAR authoring tool.
The RTE configuration specifies the relation between OS tasks and runnables. In the Rhapsody model, the tasks used actually refer
to the OS tasks configured in the Basic Software.
The ArUML_ARXF_CP supports a TaskAllocationDiagram
which we use to show the relation between classes and tasks and runnables and tasks.
The Deployer will deploy Rhapsody generated source files and some generated configuration files into your IDE.
If the combination of Rhapsody Component and Configuration has not been deployed yet,
a Deployment Configuration dialogbox is shown.
The Configuration Target is for AUTOSAR with configured Basic Software and RTE to build and run the three generated SWCs.
In the section Adaptation to AUTOSAR Authoring Tool is described which AUTOSAR details must be specified to get this example running in an
Please inspect some ArText files at <ARXF_CP_V8.00 installation folder>\ARXF_CP_V8.00\Samples\Autosar\ArText\RXF-artext
which come with this product for informational purposes only. These will help you understand what to configure in your AUTOSAR tools:
- the file swscs\SwcA.swcd, swscs\SwcB.swcd and swscs\SwcC.swcd
- the files Composition.swcd, Interfaces.swcd and RXFEcuExtract.sysd
The Configuration Simulation can be used to build and run Blinky within Visual Studio.
If Visual Studio is not launched, do so and browse to the folder
<ARXF_CP_V8.00 installation folder>\ARXF_CP_V8.00\Samples\Autosar\Model\Blinky\IDEProjects\Autosar\Simulation and select the solution file Blinky.sln
The Visual Studio project Blinky will automatically be updated and show the folders GeneratedModel, Library and RXF.
The folder Library is used for a mini-RTE using Windows threads to call your runnables.
Select Build | Build Solution which will result in a Blinky.exe which you can debug.
- doubleclick on GeneratedModel\SwcA.c and set a breakpoint at SwcA_initializeRxf(), SwcA_eventDispatcher(),
- doubleclick on GeneratedModel\LED_SwcA.c and set a breakpoint at LED_SwcA_on() and LED_SwcA_off()
Select Debug | Start Debugging. Watch the breakpoints being hit and also inspect the Threads window.
Notice the two instances of SwcA: swca1 and swca2. These are both triggered by the mini-RTE.
The LED being switched on and off is simulated using printf() statements in LED_SwcA.c and LED_SwcB.c which are shown in a command window.
Please continue to the BlinkyPlusLegacy example