One of the first conclusions achieved in the first project meeting was then importance of the standards, and in particular the realtime extensions defined in the POSIX standard. POSIX is a mature, well developed, independent set of standards then are followed by most of the UNIX industry. Also the use of already existing standards in the open source community is a must.
OSEK is a RTOS specification designed to fulfil the requirement of the automotive industry. It was designed for systems with small hardware resources like 8 bit processes with no MMU. Although there are some ports of Linux to small processors like MC68000 family, Linux and RTLinux are specially designed for mid-range to high range processors. This is why we decided to select POSIX as the reference standard used in this analysis.
POSIX stands for stands for Portable Operating System Interface, and is an IEEE standard designed to facilitate application portability. It is the codification and standardisation of the common core of UNIX™ APIs, and realtime OS. A detailed list and status of all the sub-standards that are part of POSIX can be found in the PACS web page. The subset of POSIX standards that are related to real time or embedded systems are listed below:
1003.1b: Realtime Extensions (IEEE Approved)
1003.1c: Threads (IEEE Approved)
1003.1d: Additional Realtime Extensions (IEEE Approved)
1003.1j: Advanced Realtime Extensions (IEEE Approved)
1003.1q: Tracing (IEEE Approved)
1003.5: Ada binding to 1003.1 (IEEE Approved)
1003.5a: Ada Update (IEEE Reaffirmed)
1003.5b: Ada Realtime (IEEE Reaffirmed)
Following is the list of features that has been studied in every analyzed RTOS:
General overview and architecture. The internal architecture of the RTOS determines the overall performance and the type of environments where it can be applied. For example, a RTOS with protected address space for processes will have longer context switches times than that with a flat memory space.
Hardware support
Processors supported.
Multiprocessor support.
Process management
Weighted and/or lightweight processes. Lightweight processes (threads) is an efficient method to implement concurrent systems due to the efficient resource management and fast context switching. The POSIX thread standard define many realtime features.
Scheduling policy. POSIX define four scheduling policies: SCHED_FIFO, SCHED_RR, SCHED_SPORADIC and SCHED_OTHER. What kind of scheduling policies provide for hard and soft tasks?
Periodic tasks. Most of the scheduling theory was developed to provide support to periodic tasks. POSIX do not provide specific system calls to implement periodic activities; it has to be implemented by mean of timers and signals. Do the system provide any method to implement periodic tasks?
Range of priorities. POSIX require at least 32 priorities.
Thread creation and cancellation. POSIX standard provides a lot of facilities to deal the concurrency problems related to the termination of the running tasks. Do the RTOS provide a way to start and terminate threads in a safe way?
Memory management
Memory protection. This is a mayor issue in realtime, since it is a key feature to provide fault tolerance.
Dynamic memory allocation. Fixed block size memory allocation? do provide the standard malloc() and free() functions?
Inter-process communication
Semaphores. The most common and versatile synchronisation primitive.
Mutex. Mutexes are a special type of semaphore used to protect critical sections. The main difference with normal semaphores is that the thread that locks the mutex becomes the owner of the mutex, and this thread is the only one that can unlock it. Which type of mutex are available (spin-lock, recursive, etc.)?
Priority inversion control. Do provide some type of priority inversion control in concurrency control primitives?
Message queues. Real time extensions of POSIX include a message queue interface.
Mailboxes
Shared memory Since normal weight processes are executed in a protected memory space and threads (lightweight processes) are executed in a single common memory space. This functionality is only applicable to systems with separate memory spaces.
Signals (POSIX signals)
Time and timers
Time facilities. How the time is handled is one of the most important issues in a RTOS: Absolute/relative delays, time resolution, how timers are managed, configurable timer resolution, types of clocks, etc.
Facilities to add new hardware timers. Embedded boards are usually equipped with special timer and watchdog hardware. Do the RTOS provide some utility to use it?
Driver programming (low level programming)
Interrupts. How interrupts are handled? What facilities provide the RTOS to write interrupt handlers?
System facilities to do IO. Embedded systems usually have some custom devices. The RTOS has to provide some facilities to allow the engineer to write its own device drivers.
Quality of Service
Network
Available protocols.
Filesystems
Filesystem support.
Reservation features.
Trace and debug
Program debugging. Debugging and trace utilities are fundamental features that a RTOS must provide. There are two characteristics that stress the need of these type of tools: on one hand, embedded systems use to have limited communication capabilities (sometime only a serial line); on the other hand realtime systems should contain no bugs, this is achieved by means of a careful design and extensive debugging.
Event/timing debugging. Timing correctness is as important as logical correctness in realtime systems. The RTOS must provide timing information about the execution of the application. Recently, POSIX.1q added tracing facilities that allow the user to trace system and user events.
Miscelanea
Graphic support.
Development environment. Most RTOS, commercial and open source, use GNU development utilities: gcc, binutils, gdb, etc.
Programming languages. The "C" language is available in all the RTOS, but more and more other languages like ADA or C++ are also used.
Compatibility with other RTOS APIS. Like pSOS, VxWorks, OSEK, self propietary API.