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
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:
And so on. So the parameter in tm(xx) indicates the MINIMUM time to pass before
the transition is taken!
- 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.
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