BlinkySimple example part 1
Open the Rhapsody project BlinkySimple from the directory <ARXF_CP_V8.0.1 installation folder>\ARXF_CP_V8.0.1\Samples\Autosar\Model\BlinkySimple:
The selected Configuration specifies for which environment the code must be generated: Target which can be deployed to your AUTOSAR tool environment
or Simulation to deploy to Visual Studio.
You can specify this using the Deployer tab of the RXF Configuration in
the Configuration of a Component:
A Component can have multiple configurations and one can set compiler defines per configuration, like Debug or Release.
The Component uses the stereotype RXF which is defined in the profile RXF.
Each RXF by SodiusWillert comes with this profile with this stereotype. RXF sets the proper environment,
some properties for the ARXF-CP and defines some tags.
The ArPackage RXFApplicationLayer contains:
The ArPackage CompositionPackage contains:
- SwcB which is an active class, running in the so-called swc task.
The derived object or in AUTOSAR terminology prototype swcb is statically allocated.
SwcB is based on the stereotype CpSWC.
- LED which is a seqential class. All sequential classes of an SW-C run in its swc task
- ControllerB is a sequential class too: it runs in the swc task.
- ECU-abstraction ioHwAb for which no code is generated but it is used to show the relation between SW-Cs and abstract hardware
on an SWCDiagram.
Composition serves as root compostion and defines which SWC prototypes are derived from which SWCs.
- the object derived from SwcB or in AUTOSAR terminology prototype swcb is statically allocated.
- 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 SWC contains 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: SwcB.c must include Rte_Swcb.h
- 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 critical section handlers.
The exclusive areas must be defined at the AUTOSAR authoring tool per SW-C.
- inter-runnable variables. The ARXF-CP needs to store and retrieve the address of an internal data structure.
One inter-runnable variable is required per OS task.
- runnables. Rhapsody will generate the class name as prefix, so when the generated C code of multiple SW-Cs 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.
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:
We use information from the AUTOSAR root composition showing SW-C prototypes and
use the relation between the RTE instances of SWCs and SWCs to initialize the Rhapsody instances of SWCs.
- initializeRxf which is called only once by the RTE.
The current implementation calls <yourSwc>_Init() to initialize the Rhapsody instance of the SWC including an instance of the ARXF-CP.
- eventDispatcherSwc which is typically called every 10 msec.
This runnable serves as UML eventDispatcher 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.
The cyclic calling of this runnable must be configured in the AUTOSAR authoring tool.
The runnable calls RXF_Active_eventDispatcher() to process a (UML) event in the swc task.
All sequential classes run in the swc task: the ControllerB and LED object in our example. The class LED toggles between two states:
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-C, its instance 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 AUTOSAR port to the hardware.
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. SwcB contains
itsControllerB and itsLED.
When the timer of the controller elapses, it sends an event to the LED
The Structure Diagram allows you to specify some details you need:
Please continue to the next BlinkySimple example part 2