Chapter 2. Software Architecture

Table of Contents
A Tale of two Levels
OCERA Kernel
OCERA Framework
Components

A Tale of two Levels

A real-time application is normally composed by multiple tasks with different levels of criticality. Although losing deadlines is not desirable in a real-time system, soft real-time tasks could lose some deadlines and the system could still work correctly. However hard real-time tasks cannot lose any deadline or undesirable/fatal results can be produced in the system. From this point of view, a real-time application can be organised in two levels: hard real-time tasks and soft real-time tasks.

Within the OCERA project we will regard, thus, real time systems from these two levels of criticality. Both hard and soft real time software will run with the same customized kernel, from now on the OCERA Kernel (OcK).

Hard real time tasks will give precise and deterministic control of the system, very high time accuracy and very low latency. Hard real time systems will be provided through a RT-Linux kernel and modules. As explained in "D1.1 RTOS Analysis" hard real-time tasks are implemented in kernel modules, and as such, development of hard real time systems will resemble the development at kernel level: no memory protection, no filesystem, etc... Neither the common user space tools and libraries nor the Kernel services are available for hard rt-tasks.

Soft real time tasks, on the other hand, do not provide so much time accuracy, they depend on the Linux scheduler (or other scheduler we might install) and they are likely to miss some deadlines. To minimize latency and deadline misses we will patch the Linux kernel in a way that minimizes scheduler latency, give preemptability to the kernel, provide resource management and Quality of Service (QoS), etc... Soft real time systems will be developed at user space and then the usual mechanisms for their development are available.

There will also be the possibility to build systems that run both hard and soft real-time tasks at the same time. In this case the architecture model includes user space soft real-time applications on top on Linux which is on top of RT-Linux and the hard real-time taks.

One of the key features of this architecture is the fact that we are always considering POSIX Application Programming Interfaces (APIs). Linux and RT-Linux are both POSIX compliant and when a specific feature is not covered by the POSIX standard we will try to use a draft if it exists or a POSIX-like API if not. This way, developers can decide at compile time, whether they want their tasks to be hard or soft real-time. This is very helpful, since allows developers to build, run, test and debug their applications in user space, before entering Kernel realm, saving, thus, a lot of development time.

We have to point out that tasks have to be defined hard or soft at compile time. We will not give any mechanism to dynamically change a task criticality.