Real-Time Behavior

Deterministic Real-Time Behavior

Deterministic here does not imply fixed-sequence polling. Although this is possible too, the ARXF-CP uses a different method to achieve a deterministic behavior. The ARXF-CP serves your generated application. It will provide services like sending and receiving events, handling timeout events and more.

How Events are processed

When an event is sent, the ARXF-CP will store a pointer to that event in a queue for the appropiate task, where it will be handled in a FIFO manner. See Concurrency.
The handling of events is done by the ARXF-CP. Handling events also means handling expired timers that are converted to events when they expire.

An event for a specific object will be given to the generated event handle function of that Objects Class. This function carries out all the associated actions (On Entry, On Exit, in State, in transitions) and will return the control to the ARXF-CP when finished.

This will guarantee a flawless handling of events in a deterministic way. Actions can be delayed by other actions but only for a time that can easily be calculated.

How Time-outs (tm(xx) ) are handled

When the tm(xx) statement is used in a state-machine, the user wants a certain delay in the processing of states. tm(xx) in a transition means: Wait at least xx milliseconds and then take this transition (and execute all attached actions)

The timer ticks are derived by using a runnable which is called by the RTE at a regular interval, for example every 10 msec. If the timer tick is 10ms then no timeout can be under 10ms. Also no timeout should be other then a multiple of 10.

When this happens to be the case, the ARXF-CP calculates the correct timout value. Due to the fact that the timer is derived from an external tick source, it is possible that a timeout request occurs just before a tick would happen or just after a tick has happened. The granularity of the ticks is the minimum tick value.

If RXF_TIMEOUT_GUARANTEE_TIME is enabled on the Configuration tab of the RXF Configuration, the following timeout handling can be observed:

Using a tm(10) on a 10 millisecond configured heartbeat for your SW-C can give you a tick time between 10 ms and 20 ms.
[tm(0)] will always expire when the next tick is there (with a maximum of 10 ms).
[tm(1)] will always expire at the second next tick (10 ms to 20 ms later).
[tm(2) - tm(10)] will give the same result as a tm(1).
[tm(11)] - expires after 20 ms to 30 ms.

And so on. So the parameter in tm(xx) indicates the MINIMUM time to pass before the transition is taken!

If the constant RXF_TIMEOUT_GUARANTEE_TIME is not configured, it is not guaranteed that tm(xx) indicates the MINIMUM time to pass before the transition is taken. But on a mostly idle system that has the advantage that cyclic tansitions triggered by a tm(xx) do not sum up a jitter.

NULL-transitions in a State Machine

In a statechart it is possible to model state transitions that are directly to be taken, without waiting for an event as a trigger. These are so called NULL-transitions. The ARXF-CP includes a mechanism to detect endless loops of NULL-transitions (e.g. because of a design error in modeling a state machine) during runtime. An endless loop is detected, if more than a defined number of NULL-transitions occur in a row. This maximum number of directly following NULL-transitions can be specified on the Configuration tab of the RXF Configuration.