The main goal of this project is to deliver a structured set of components to ease the development of RTES providing new services not available in current RTOSes. These components are responsible for providing those new services or functionalities. This will be mainly performed by means of modifying the current Linux and RTLinux kernels or adding new software layers over them using their current POSIX APIs.


An OCERA component is a piece of software that brings some new functionality or feature in some of the fields of the Embedded and Real-Time Systems that are of interest for OCERA: Scheduling & RT-Kernels, Quality of Service, Fault-Tolerance and Communications.

An OCERA component will materialize in a kernel module, library, API, user-space application, etc...


Lets enumerate some of the general characteristics of the OCERA components.

External Structure

From the point of view of an external developer that wants to build her RTES using the OCERA framework, an OCERA component is simply a feature or service that can be activated or deactivated, and optionally configured or customised for the target application.

It might be the case that a selected component modifies the kernel source code but this should not be an issue for an external development. On the contrary, an external developer will not notice whether the components she has selected are kernel modules or they modify kernel sources; for her it will be completely transparent.

The only difference an external developer should notice is that some components will be activated/deactivated as a kernel feature, and configured in the same way, and others will be activated as a user process/thread that offers some new service, i.e., as a kind of a classical UNIX daemon.

List of Components

Though they will be explained in detail later in, we present here a complete list of components that will be develop within OCERA: