Rhapsody runtime as OS

About need for Operating System

Each time Rhapsody runtime (OXF for example) is ported to the new OS or to the new environment following questions are risen: how to connect the requested by the OXF services to the provuded by the particular OS services: threads, mutexes, pools, ... .
This question is simple to answer (see page about the porting of the OXF). This is pretty staight forward task.

The more complicated question is not risen: Why one OS is necessary?

One OS is necessary?

The main service provided by one OS is : task scheduling, execute task if ready.
One of the services provided by the Rhapsody rumtime: statechart scheduling, execute statechart if events queed for statechart.

The major differences is:
1. OS can preempt the tasks
2. OS can protect tasks against mutual execution

Finally, if we speak about the need for one OS, we speak about:
1. This is necessary to execute statecharts in the separate threads
2. This is necessary to synchronize resources against mutual access

And the question ius about:
1. Is is necessary to run multiple threads in one address space and execute state charts in the own threads.
2. Is it necessary to call/send/receive from one thread to the otehr directly, versus interpocess based communication.

In the most cases the anser is: use asynchronous design, based on the state chart. Do not start blocking tasks, requiring separate threads. Rhapsody allows to do this.

NOFReactive as OS

NOF Reactive addresses the provided by the OS services as follows:
1. The build in statechart scheduler does not depend on OS and implements non preemtive round robin scheduler. Scheduler executed in the endless loop. This is per CPU scheduler. You can start each scheduler using separate thread, interrupt or other parallel execution means, if necessary.
2. The parallel execution supported by "CPU number". The execution on the specific CPU number is fully independent.
3. The statecharts are protected by "single writer - single reader" FIFOs, without need for the synchronization objects. For this reason the communication between threads and interrupts using selected communicationsendpoints possible.

The most simple model to interact with OS is implemented at moment: the scheduler is one while(1) loop, running over the linear array with references to statechart. This is one such array (dimension) for each CPU (CPU number is defined at compile time).

In case full featured OS is used, the best solution is to start multiple NOFReactive instances, each in his own process. This provides the parallel execution, and at same time isolates running at different threads (in this case processes) one from the other.
The communicatiuon between processes may be performed by NOFTransport services.

Porting NOFReactive

NOF Reactive does non require porting at all. The only one task is required to start task/thread/process/bare metal main function and call the "CreateSystem". This functions calls the statechart scheduler and returns only in case of error.

Modify NOFReactive scheduler

The NOFReactive allows to replace the scheduler by more sophisticated one.
The interface between the scheduler IOScheduler and the reactive base class IOxfReactive is very simple:
1. Per CPU array is "static" variable of the IOScheduler
2. At time state chart craeted the IOxfReactive call IOScheduler static function and add the statechart to the next free position
3. After all constructors called (in the NOF Reactive all class instances created at start, dynamic memory and statechart destruction not supported) the IOScheduler call init function of each state chart and then starts execution by call to the schedule state chart functions in one endless loop.

You can modify or replace the IOScheduler, add dynamic task management, add statechart priorities, and much more.
The questions to be answered are:
1. Is it really necessary for the software design. Is it not possible to resolve the problem by statecharts executed in non preemptive round robin fashion.
2. Supposed scheduler changed. How to prove the system always mets teh timing requirements?

Existing IOScheduler modifications

At current moment only one IO scheduler modification exists. This is scheduler for 3 CPUs, running each one independent from the other.
CPU 0 executed in bare metal main loop.
CPU 1 executed in timer interrupt.
CPU 2 executed in the hardware interrupt.

The communication between CPUs performed by state chart events, using the "single writer - single reader" pronzip, and does not required any synchronization with interrupts or between interrupts.

The oberall design is:
1. Hardware interrupt managed the state charts responsible for data transfer to/from device
2. Timer interrupt managed the state charts for soft realtime data processing.
3. Main loop managed the slow, requiring significant amount of the CPU time, state charts

The transfer of the significant amounts of data (> size of the event) was managed by the common buffer object. The memory descriptors were issued by this object and communicated by events between state charts.