Blinky example

The example Blinky is found in <ARXF_CP_V8.0.1 installation folder>\ARXF_CP_V8.0.1\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:

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

SW-Cs

The SW-Cs contain a few AUTOSAR specific details:

• 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 behavior 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

AUTOSAR Tasks

Deployer

Configuration Target

In the section Adaptation to AUTOSAR Authoring Tool is described which AUTOSAR details must be specified to get this example running in an AUTOSAR environment.

Please inspect some ArText files at <ARXF_CP_V8.0.1 installation folder>\ARXF_CP_V8.0.1\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

Please continue to the BlinkyPlusLegacy example