How it Works

Major Components

This is three major components involved in the execution of the state chart asynchronous event processing:

• The reactive classes with generated state chart code, responsible for the processing of the events


• The events self, responsible for carrying the event information and the event parameters


• The Scheduler, responsible for the execution of the reactive classes

This chapter provides the description how the components do interact and at same time explains the differences to OXF (and OXF like) frameworks, where necessary.

Scheduler

The scheduler is implemented using the class IOScheduler . This class does contains only static functions and attributes. This is not possible to create one instance of this class (private constructor).
Each reactive class is derived from the class IOxfReactive. The constructor of the IOxfReactive shall call IOScheduler::registerReactiveClient and add the new reactive class to the scheduler list.
The scheduler list is implemented as array and the new registered client is added to the end of the array.
The length of the scheduler array defined by global constant numberOfNOFInstances .
Error Handling: The scheduler shall call the static system error function CsystemErrorHandler::handleError in case of array overflow.
After all reactive classes are created the function IOScheduler::initSystem shall be called by user code to perform the system initialization. This function shall call virtual function “IOxfReactive::init” for all registered reactive classes.
After the initialization performed the function IOScheduler::Run shall be called by user continuously (in one loop, periodically or triggered by external event).
The function shall call the virtual function IOxfReactive::schedule for all registered reactive classes.

Reactive classes

The reactive classes (classes with state chart attached and state chart code generated) are derived from the class IOxfReactive. This class implements following components:

• Event queue for asynchronous event processing
  
  • See Events chapter below
  
  


• Support for “tm()” triggers (state timeout triggers)


• Null transactions (state transitions without events, generated by code generator as part of the state chart)


• State chart code initialization
  
  • Shall call generated by the code generator state chart initial transition code rootState_entDef
  
  


• Asynchronous event processing
  
  • Shall call generated by the code generator state chart code rootState_processEvent
  
  

Executable classes

This is possible to add one class without attached state chart and without generated state chart code to the scheduler lisr. This class class shall be executed every time IOScheduler::Run called.
To achieve this behavior user shall:

1. Ensure base class is IOxfReactive


2. Add protected member function void rootState_entDef(void) {}
   
3. Add protected member function
   ifcNOFReactive::TakeEventStatus rootState_processEvent(void) { \
   return IoxfReactive::eventConsumed; }


4. Overwrite public virtual function void init(void)
   
   • Use function for the class initialization performed outside of the constructor
   
   


5. Overwrite public virtual function void schedule(void)
   
   • Function called by the scheduler
   
   

See CSystemTime for example.

Events, event queues and asynchronous event processing

The asynchronous events are shall be derived from the class IOxfEvent. This class implements the necessary for the event processing functions.
In the NOFReactive framework the events do not have the global scope. Each event object is created on the stack in case:

1. Event being sent to the state chart


2. Event processed by the state chart

The event object shall be created only for one purpose: gain access to the event parameters in the compatible with OXF fashion (to preserve code compatibility).
During the event transmission the stored in the event data shall be stored to the event data queue of the message target state chart (the message queue is part of the class IOxfReactive). The event constructor is responsible for the event data serialization: store of the event ID and the serialized event parameter to the queue.
During the event reception other constructor is responsible for the restore of the serialized event identifiers and parameters to the attributes of the temporary event object created on the stack.
The amount of the event parameters serialized controlled by the type IoxfEvent::eventData_t.
The size of the queue is controlled by the global variable numberOfNOFInstances: given N tasks and per task queue size of N every task can send to each other task one message per scheduling loop.
As described above only the event ID (integer data) and the serialized (converted to binary stream) event parameters are passed between reactive classes.
The serialization/de-serialization of the parameters is implemented by the function IoxfEvent::updateEventData.
The code for the invocation of this function is generated by the updated code generator template and by the code generation post processing step.