AR3X_BMT project capabilities

This content applies to version 7.6.1 or later. The AUTOSAR AR3x_BMT project defines the AUTOSAR SW architecture and the Rhapsody® implementation (s) for atomic SW/C type(s) of that SW architecture.

AR3X_BMT project

The AR3X_BMT project can contain:
There are two additional diagrams with an AR3X_BMT project:
  • RIMB diagram - defines Rhapsody Implementation Blocks
  • SWC Implementation Diagram - defines the implementation of an AR SW/C type via RIMB objects, linking RIMBO with the SW/C type
RIMB Ports are designed to be only connected to AR Ports via delegation connectors. There are four kinds of RIMB ports that correspond to RIMB Interfaces:
  • RIMB receiver port - typed by RIMB Receiver port interface and designed to connect to AR receiver ports (AR Required port with S/R Interface)
  • RIMB sender ports – designed to connect to AR sender ports
  • RIMB client ports – designed to connect to AR client ports
  • RIMB server ports – designed to connect to AR server ports
RIMB Interfaces - there are four kinds of RIMB interfaces:
  • RIMB receiver port interface
  • RIMB sender port interface
  • RIMB client port interface
  • RIMB server port interface
The RIMB Interfaces can have:
  • typing attributes and operation parameters on sender or receiver interfaces, operation parameters on client or server interface. The typing attributes and operation parameters must be C-types compatible with the matching AR data elements types.
  • typing attribute with Rhapsody event on sender or receiver interface that must be typed by a Rhapsody event. The helper function generated by Rhapsody will also generate a corresponding Rhapsody event, with the data itself as optional parameter. Such Rhapsody events may be used to trigger transitions on the RIMB’s statechart. The Rhapsody event can either have no parameters or one parameter with a C type compatible to the to-be-connected AR data element type. The handling of Rhapsody event is facilitated via the provided helper functions.
  • specifying access mode that depends on the kind of interface and for which additional information is required:
    • Receiver interface: access mode needs to be specified for each attribute in the attributes tab. The access mode can have a value of:
      • Explicit-Blocking - it means AR explicit access which blocks until a value arrives. In the Access & Activation tab no active element can have activation policy of data received event.

      • Explicit-non-Blocking - it means AR explicit access which returns immediately with a status code. In the Access & Activation tab, no active element can have activation policy of wakeup on data received event.

      • Implicit - it means AR implicit access. In the Access & Activation tab must be one active element accessing it.

  • specifying call mode for which the following information is required:
    • Client interface for which the call mode needs to be specified for each operation in the operations tab. The call mode can be:
      • Synchronous – the call blocks until the server completes the operations

      • Asynchronous – the call returns immediately

    Another active operation with activation policy “Asynchronous Server Call Returns Event” can be used to retrieve the value of written parameters

RIMB Active Operations - the tab defines an AR Runnable Entity. All behavior defined within RIMB must be activated (called) by an Active Operation, including Statechart execution. The Active Operation can be implemented by any code. The Active Operation tab main features are:
  • Access to DataElements on sender or receiver interfaces, and operations on client or server interfaces. Access is defined based on the Access & Activation tab.

  • Activation policy which determines when the RTE scheduler should activate that operation. It can have a value of either:

    asynchronous activation policy- activation is defined based on the Access & Activation tab

    periodic activation policy - period and offset are defined

  • Guarded - guarded active operations are mutually exclusive. Implemented by a dedicated AR exclusive area, in which all of the guarded active operations are specified to “run within”.
RIMB Access and Activation - the tab defines the related Internal Behavior artifacts.
  • Access - which elements on ports are accessed by which active elements such as data read/write access, data send/receive points, server sync or async call points, wait points, and so on. The access mode of implicit or explicit is specified in the level of attributes on RIMB interfaces, and not here.

  • Activation - represents the activation policy of asynchronous active elements. Defines which RTE Events, aside Timing Event, will cause the activation of each asynchronous active element. Activation may be “N/A” in case a line defines (additional) access

Note: If the activation policy is “Data Received Event” or “Wakeup on Data Received Event” then a line defines both an activation policy and access to the data element. A given active element can have more than one line in the table. In this case the defined activation policy and access is the sum of all lines.

RIMB Concurrency can be either active (default) or sequential. When concurrency is “active”, a RunnableEntity will be created for the “doExecute” method of the RIMB. activation policy that determines when the RTE activates the “doExecute” method of the RIMB, must be specified. The activation policy can be either “asynchronous” or “periodic". The “asynchronous” activation policy is defined based on the “Access & Activation" tab. The “periodic” activation policy is when period and offset are defined. When the concurrency is “sequential”, no explicit activation is defined. If the RIMB is defined as an execution manager, the RIMB will implement a “doExecute” method that will manage its Statechart if it exists and its parts, and will own an event queue.

Generated Helper functions

Rhapsody can generate several types of helper functions for RIMBs. The helper functions can be called from active operations, hide the complexity and specificity of the RTE APIs, and enable leveraging further services, such as receiveAndHandleP_x. The helper functions contain:
  • Receivers - reads data on receiver ports. In some cases allow to change the access mode without changing the users’ code.

  • Senders - sends data on sender ports

  • Handlers - handle received data

  • Receive-and-handle - combines the effect of receive and handle

  • Callers - calls the required (client) services

  • Receivers, Senders, Receive-and-handle and Callers - returns the RTE API status

Table 1.
Generated Helper function Description

receiveData_p_x (int* const x)

Reads the value of attribute x on receiver port p and put it in parameter x. Generated only when p.x is typed by a C-type, not an event.

handleData_p_x (int x)

Generated only when p.x is typed by a c type, not an event.
  • If the RIMB has a triggered operation evP_x, then call it.

  • If the RIMB has attribute p_x. then set it to the value of the parameter.

  • If the RIMB has in addition a reception by the name chP_x and x changed, then generate a Rhapsody event chP_x and queue it on the manager’s queue.

receiveAndHandleData_p_x()

Received immediately and followed by handle. The code is inline, for example, it does not imply two additional function calls.

receiveEvent_p_x (int* const x)

Reads the value of attribute x on receiver port p and place it in parameter x. It is generated only when p.x is typed by an Rhapsody event. It is preferable to call receiveAndHandleEvent directly.

handleEvent_p_x()

Generated only when p.x is typed by an event.
  • If the RIMB has a reception ev then generate a Rhapsody event ev, and queue it on the manager’s queue.

  • If the event typing p.x has a parameter then handleEvent has a parameter which is copied into the event.

receiveAndHandleEvent_p_x()

Receive immediately followed by handle. The code is inline, for example, it does not imply two additional functions calls.

sendData_p_x(int x)

Sends the value of the parameter to attribute x on sender port p. It is generated only when p.x is typed by a C-type, not an event.

sendEvent_p_x()

Generated only when p.x is typed by an event ev.
  • If ev has a parameter then sendEvent also has a parameter that will be sent out.

  • If ev does not has a parameter, an arbitrary value will be sent.

call_p_f

The call is required for the operation f on client port p.

Time Handling

The time outs implementation is:
  • Two Runnable Entities:

    TimeTick - responsible for time incrementing

    PostTimedElements - responsible for posting expired timeouts. Implemented in mxf/RiCTimer.c.

  • Two Timing Events:

    TimeTick_tmev, PostTimedElements_tmev - used to trigger the above Runnable Entities periodically

  • One Exclusive area:

    TimerManager_EA - used for assuring mutual exclusion over access to the time counter. Entering and Exiting this Exclusive Area is done by mxf API called RiCOSTimerManagerMutex_lock(), and RiCOSTimerManagerMutex_free().

All artifacts are declared in the ARXML.

RIMB’s Statechart

The handling of Rhapsody events is facilitated by generated receivers, senders, and handlers. RIMB’s Statechart may be executed in one of two modes:

Defining the Statechart of a RIMB for execution in RTE-managed mode:
  • Define the RIMB as “sequential”

  • For each attribute x on a RIMB receiver port p whose arrival should trigger a transition define a triggered operation by the name evP_x

  • The access mode of x must be Explicit Blocking or Explicit Non-Blocking (i.e. not Implicit), and it must be typed by a regular C-type (for example, not a Rhapsody event)

  • Write a Statechart with those triggered operations as transition triggers

  • For each such p.x define an active operation to serve as a dispatcher for p.x

  • The implementation of the active operation must call receiveAndHandleP_x()

    This step is the same for RTE- and Rhapsody-managed mode. The difference is the code generated by Rhapsody for receiveAndHandleP_x()

  • Mark all the dispatchers for the Statechart as “guarded”, to ensure mutual exclusion between the dispatchers that will be activated by separate Runnable-Entities

Defining the Statechart of a RIMB for execution in Rhapsody-managed mode:
  • Define the RIMB as “active” with “periodic” execution policy

  • Use Rhapsody events to type attributes on RIMB receiver interfaces typing ports

  • Arrival of AR data element x on receiver port p will trigger the addition of event ev to the event queue

  • x on the RIMB receiver interface of port p must be typed by ev

  • ev is the name of the event on the Statechart, not a name on p.x

  • The binding of ev to p.x is achieved via typing x by ev

  • Write a statechart with Rhapsody events ev as transition triggers

  • For each such p.x define an active operation to serve as a polling for p.x

  • The implementation of the active operation should call receiveAndHandleP_x()

    This step is the same for RTE- and Rhapsody-managed mode. The difference is the code generated by Rhapsody for receiveAndHandleP_x()


Feedback