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.
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
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
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
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.
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
| 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.
|
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.
|
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.
|
call_p_f |
The call is required for the operation f on client port p. |
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().
The handling of Rhapsody events is facilitated by generated receivers, senders, and handlers. RIMB’s Statechart may be executed in one of two modes:
RTE-managed - the data elements arriving on AR receiver ports are transformed into triggered operations. When a data element arrives, the RTE calls a corresponding active operation which directly triggers a transition on the Statechart. The RIMB may be sequential, not active nor an execution manager, and no Rhapsody events are required. In this mode, only triggered operations originating from the arrival of AR data elements can trigger transitions on the statechart. Calling RiCGEN is not allowed.
Rhapsody-managed - The data elements arriving on AR receiver ports are transformed into Rhapsody events. When a data element arrives, an active operation is called which queues the corresponding Rhapsody event into the RIMBO’s event queue. The RIMB needs to be active-periodic and execution manager. Its doExecute runs periodically and dispatches the events into the Statechart one by one, imitating the usual Rhapsody mechanism.
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
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()