InteriorLight example

InteriorLight Example

The InteriorLight example is used to show how AUTOSAR ports are implemented. You can generate a mini-RTE and use of the UML Target Debugger to stimulate the model and inspect its behavior.

Open the Rhapsody project InteriorLight from the directory <ARXF_CP_V8.0.1 installation folder>\ARXF_CP_V8.0.1\Samples\AUTOSAR\Model\InteriorLight\ARUML
(the SysML folder contains a model used as example in M2M)

The SWCDiagram shows you prototypes of SWCs and how they are connected via AUTOSAR ports; both client/server ports used to call or provide an operation and sender/receiver ports used to send and receive data.

Introducton

The ArUML model basically shows the implementation of the interior light. A lightmanager receives input from three doors: a reardoor, a left door and a right door. To switch on a light, the lightmanager signals a light actuator. The left- and right door have a sensor which signals the light manager. For the rear door the lightmanager gets a signal via CAN.

For the sake of simplicity, the Basic Software is not modeled: the Mode Manager is not implemented, nor is CAN used. To show the use of a self pointer in SWCs which support multiple instantiation, the door is instantiated in a left- and a right door. The LightActuator also supports multiple-instantiation, to inspect code of the generated mini-RTE.

Each SWC prototype has one part; each SWC contains a class prefixed by C_ with a corresponding name. Such class implements the Internal Behavior of an SWC, although one can also model a statechart directly in an SWC to react on different states of the Mode Manager.

We concentrate on the following SWCs:

RearDoor. The class C_BackDoor has an attribute backDoorStatus which it retrieves via CAN (not implemented). On a change, it sends it actual status via the sender port doorstatusp to LightManager. For sending, we use the explicit sender API, Rte_Write_doorstatusp_DoorStatusImpl() which is called from within the statechart.

The statechart runs in the context of the runnable eventDispatcher so from an AUTOSAR perspective, the RTE API is called by this runnable. The name of the RTE API is composed of the name of the port and the datatype being send:

The contract RearDoorStatus_Itf is provided in the sender port doorstatusp which is why the port is set to Reversed (see Ports section Reversed or not)

The receiver port reardoorstatusp receives a signal from a delegation port via the CAN bus (not implemented). Note that the receiver port has a stereotyped dependency PortAccess to a dedicated runnable which can wait for the signal to arrive:
Door. The SWC is instantiated twice and apart from the status it also communicates if the leftdoor- or the rightdoor is opened. The SWC responds its actual status via the client port doorstatusp to LightManager when the LightManager polls for a door being opened.

The statechart of the class C_Door reacts on a door opening or closing by setting its attribute doorStatus.

When a Door is polled, it uses the RTE API Rte_Call_doorstatusp_setxdoorstatus() to communicate the attribute.
The SWC Door prototype must use its self pointer as first argument in any RTE API it does, because the SWC has its tag supportsMultipleInstantiation set to True. Its self pointer or address of the RTE instance of the SWC prototype get be retrieved via Door_getSelf() which is generated from the rootcomposition

The Door also has a client port DoorSwitchSignal which is connected to the BSW IoHwAb module. This module is of stereotype CpEcu-Abstraction-SWC for which no code is generated. We will see later how we can Inject UML events to simulate the signals by the IoHwAb module.
LightManager. This SWC decides if the light must be switched on, depending on the status of Doors. The class C_LightMgr has the following statechart:

The C_LightMgr_sendFrontlightstatusp() calls the RTE API Rte_Write_frontlightstatusp_LightStatusImpl() which name is composed of the name of the port and the datatype being send. The senderport frontlightstatusp has its tag Explicit set to True. The CpSRInterface stereotyped interface interiorlightstatus_Itf uses the LightStatusImpl of package ImplementationDataTypes.
The server ports leftdoorstatusp and rightdoorstatusp use the CpCSInterface stereotyped interface FrontDoorStatus_Itf setxdoorstatus(). Per server port interface, a runnable is used which matches the signature of the interface: you will not find an operation setxdoorstatus() in class C_LightMgr. The runnable setxdoorstatus decides which attribute must be set:

The receiver port reardoorstatusp is connected to the doorstatusp sender port of the RearDoor, described as first SWC above. For a receiver port, a decicated runnable reardoorstatusp in the SWC LightManager is used, which has a PortAccess dependency. The implementation is currently not used, because the Basic Software is not modeled and CAN is not used, so the C_backDoor() can never send anything.

mini-RTE

Before we generate code from the model, we must generate a mini-RTE for it. All Blinky examples have a fixed mini-RTE, but this example shows how to add a generated mini-RTE to your model.

Select the RootComposition and generate a mini-RTE:

A package called ArUML_CP_miniRTE is added to your model, which you must add to the Scope of the active component so Rhapsody will generate code for it:

During generation of the mini-RTE warnings are shown. These refer to port usage of not implemented connections: you may ignore the warnings. In your own models, you can use the Check Wellformedness Helper to inspect ports and fix problems.

Obviously, when you want to generate code using RTE contracts generated by an AUTOSAR Authoring tool and deploy the model to an AUTOSAR environment, you must add an extra component and not add the mini-RTE to the scope: you want to use the real RTE contracts.

Generate/Make/Run

By pressing Generate/Make/Run, the code for the active configuration will be generated and the generated model, mini-RTE, List of Defines and RXF sources are deployed to a Visual Studio project:

The details on what IDE template is used and other details of a Deployment to are configured in the RXF perspective of the Deployer:

Visual Studio will be launched automatically. The project is populated with your model, the mini-RTE and the ARXF-CP sources:

Build the project, but do not start the Visual Studio Local Windows Debugger:

Using Target Debugger

After a successful build, start the UML Target Debugger:

You must configure the Target Debugger Communication channel. Select the TCP/IP plugin to communicate with the mini-RTE:

This will allow you to specify a port. Accept the default. Start the Visual Studio Local Windows Debugger:

You should see a succesful connection in the Console of the Target Debugger. If not, please refer to UML Target Debugger section TCP/IP.

The model has started execution: you see instances of the SWCs and their parts. However, the only thing you'll see are timeout events: nothing is happening yet.

Filter UML events

On the Views tab, you can add a filter for timeout events so these are no longer showed. The Views tab shows a list of sessions (one can save it to CSV format for later use). Select the current session and Add Filter:

A filter dialog is opened, click on New:

Enable Event to show only events known in the model:

Select the TimeOutEvent and the arrow to Hide it:

Click Apply:

Finally, select the new filter to activate it:

Inject UML events

When communication with Basic Software is not implemented or stubbed yet, you can add some events to your model to inject these into an object in your model. In this example we used a dbgOpenDoor and dbgCloseDoor event to send to the object O_Door which is part of SWC Door, so we can test the behavior of the LightManager, by "opening" or "closing" the left door and the right door.

The statechart of C_Door was extended to reply the proper status to the LightManager when it is polling a Door.

You can inject these events into your model to stimulate behavior of doors being opened or closed:

Clicking this button will activate another Window where you can use the dropdown boxes to select an event and where to send it to:

You are encouraged to read the section Best Practices before starting modeling yourself.