| WP2 - Architecture Specification: Deliverable D2.1 - Architecture and Components Integration | ||
|---|---|---|
| Prev | Chapter 2. Software Architecture | Next |
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.
Open Source
All are Open Source and released according to OCERA project licenses
Unique Level of Application
Each OC will be developed just for one level of criticality, either hard or soft real-time. This will let us separate configuration and parameterization and get smaller footprints.
We can have, nevetheless, the same feature or service in both levels, hard and soft, but this would be provided by different components, whether they share API (which will be the common case) or not.
Uniformized API
All OC will share a common API structure. They will adopt POSIX if available and a POSIX draft or POSIX-like API if not. All OC will have automatically their API uniformized: names, profiles, etc...
Compatibility with OCERA kernel
Although the components can be developed for any architecture, kernel, etc... They at least must be provided compatible with the OCERA Kernels. Notice that there will be several kernels depeding on the target architectures
Small footprint
Having in mind the development of Embedded Systems, the OCERA components footprint will be kept as small as possible
Although there is not specific maximum size for an OCERA basic system (just the system and libraries), we should strongly limitate its footprint to allow the development of embedded systems where non-volatile memory or disk capacity are very reduced.
Uniformity
All OCERA components will be provided in a standard way, including documentation, examples, etc... This is important for several reasons, first to ease development with OCERA components, second to allow people to contribute (to the existing components or adding new ones)
Minimum Dependencies
There can be dependencies between components, but these dependencies have to be maintained to a minimum
Sometimes we will develop components that make use of features provided by other components. Separating components increases modularity and eases development, but we have to take care not to add artificial dependencies. Frequently developers do not take much care about the dependencies of their software. Keeping dependencies to a minimum allows exchangeability, minimize the use of memory and system footprint, etc... so we will develop the components with a "just what needed" philosophy.
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.
Though they will be explained in detail later in, we present here a complete list of components that will be develop within OCERA:
Kernel and Scheduling
RTL-ADA: Porting of Runtime support of the ADA (GNAT) system to RT-Linux
POSIX Timers in RT-Linux
POSIX Non-realtime signals in RT-Linux
POSIX Barriers in RT-Linux
POSIX Message queues in RT-Linux
Application defined scheduler in RT-Linux
POSIX Trace support
Dynamic Memory Management support in RT-Linux
Constant Bandwidth Server (CBS) in RT-Linux
Quality of Service
Scheduler for resource reservation in Linux
Quality of Sercive (QoS) manager
User library for accessing previous components
A series of patches to the RT-Linux/Linux kernel to solve problems with preemption, low-latency and high-resolution timers patches.
Fault-Tolerance
Design & Building Tool
Application fault-tolerance monitor
Fault-Tolerance controller in kernel level
TaskReplicaAgent
Communications
Virtual CAN API
CANOpen device
EDS parser and CAN/CANOpen analyzer
Real-Time Ethernet (ORTE) device
Real-Time Ethernet analyzer
CAN model by timed automata/ Petri Nets
Verification of cooperative scheduling and interrupt handlers