Real Time Executive for Multiprocessor Systems

Real Time Operating Systems Case Study

Overview

● Real Time Operating Systems In General

● Historical Motivations of RTEMS

● Modern Support and Features

● Internal Architecture

● Conclusion and Resources

Real Time Operating Systems

Why Real Time Operating Systems?

● Typically required in more ‘responsive’ systems

● React to changing environments and data

● Very concerned with finishing required computation in a timely manner

● Usually very lightweight, running on embedded hardware with limited compute

power

● Must be very dependable and fault free, cannot experience deadlock

Deadlines

● Points in time at which work must be completed● Involved in scheduling, helps determine which tasks of equal priority to run

next● Hard Deadlines

○ Points at which data from calculation will no longer be useful○ Can be fatal○ Video or Audio codec, Object Detection in Self Driving Cars

● Soft Deadlines○ Work would be prefered to be finished, but it may still be valuable after○ May effect QoS, but rarely fatal○ MPG estimates in Cars, System Statistics

Real Time vs. General Purpose Operating Systems

● Scheduling based almost entirely on

priority and deadlines

● Relatively minimal in terms of features, just

enough to get by

● Deadlines help enforce rules on compute

times and sequences

● Preemptible Kernel allows for serving high

priority tasks when needed

● Time Deterministic

● ‘Flat’ Memory

● Scheduling based on optimal compute

hardware allocation

● Large, expansive feature sets for best user

interfacing

● Tasks can take unbounded amounts of

time to execute

● Kernel is non-preemptable, interrupts may

take some time to handle

● Time indeterministic

● Protected Memory / Virtual Memory

Real Time General Purpose

Historical Motivations of RTEMS

Real Time Executive for Missile Systems

● First released in 1986 as an Army funded project

○ The main goal was to decrease application development time

○ Has seen a great deal of improvement since then

● Sought out to free itself from the limitations of Ada

○ Ada was becoming too slow for missile systems of the day

○ RTEMS was written in C for the Motorola 68K family

● Based on the Real Time Executive Interface Definition (RTEID) Standard

○ This would later go on to shape the designs for the IEEE P1003.4 committee

○ POSIX received its real time functionalities as a result

Modern Support and Features

Modern Board Support Packages (BSPs)

Familiar to the Public

● ARM

● Atmel AVR

● Texas Instruments – C3x/C4x DSPs

● Intel – x86 architecture members 80386, Pentium,

and above

● MIPS

● PowerPC

● Motorola 68K

More Special Use

● Blackfin (DSPs often used in RF applications)

● Freescale ColdFire (Low end RISC, similar to ARM)

● LatticeMico32 (optimized for FPGAs)

● Nios II (Designed for Altera Brand FPGAs)

● Renesas – H8/300, M32C, M32R, SuperH

(Automotive applications)

● SPARC – ERC32, LEON, V9 (Sun Microsystems,

Server hardware)

Features

● Real Time Executive is basically a kernel in modern definitions

● Homogeneous and Heterogeneous System support

● Event Driven and Preemptive Scheduling

● Tasks are internally synchronous, but asynchronous between

● Executive acts as extension of CPU instruction set, allowing for changes in

scheduling, interrupt handling, load balance

Ecosystem

● Large User and Contributor Base

○ Began as Military

○ Now used in Space, Scientific, and Industrial applications

● Support for development tools on most major Operating Systems

○ This make it possible to build for many different chipsets

○ Allows for single image creation on a development machine before flashing

● Portability

○ Apps can be ported from board to board given good implementation

○ RTEMS abstracts away most hardware function

Internal Architecture

Basic Structure

● Comprised of a Core section and surrounding Resource Managers

● Core handles scheduling and dispatching primarily, has several scheduler

algorithms to choose from

● Resource Managers control various aspects of the system from

synchronization structures, to memory, to timekeeping tools

● External components such as hardware and software services can be

connected through a few dedicated Resource Managers

● Similar to Linux in this way

Resource Managers

● Initialization Manager● Task Manager● Interrupt Manager● Clock Manager● Timer Manager● Rate Monotonic Manager● Semaphore Manager● Barrier Manager● Message Manager● Event Manager

● Signal Manager● Partition Manager● Region Manager● Dual-Ported Memory Manager● I/O Manager● Fatal Error Manager● User Extensions Manager● Multiprocessing Manager

Tasks and the Task Manager

● Task - “a task is the smallest thread of execution which can compete on its own for system resources.

A task is manifested by the existence of a task control block (TCB).”

● Tasks can exist in five states: Executing, Ready, Blocked, Dormant, Non-Existent

● Tasks have ‘Mode’ parameters that change how they function

○ For Example, ‘No Preempt’ can be enabled to change control

○ Timeslicing can also be disabled/enabled this way

○ Asynchronous Signal Processing flags allow for holds

● The task manager controls access to these parameter and passes them to the scheduler when

needed

Interrupt Manager

● Allows for the configuration of Interrupts and their respective handlers

○ Often times, interrupts for specific stimuli may need to be watched for given a recent event

● Various parameters can be used to set catch targets

○ 256 levels of interrupt can be used based on priority and the like

● Interrupts can be enabled and disabled to allow non-interruptible code

segments

○ This is useful for ensuring safe execution of some critical regions

Timer And Rate Monotonic Manager

● Timers are used to schedule tasks for execution in the future

○ Such as check status at given time○ Often used for ‘Watchdog’ timers and

timeouts

● Callbacks are usually used to trigger events as result of timer firing

● Rate Monotonic really means executing periodically○ Examples of this might be

DSPs working on chunks of data

● Rate Monotonic Scheduler (RMS) algorithm ensures all Monotonic tasks are able to meet deadlines

Conclusion

What to take away

● Scheduling can be tuned to allow for quick response on critical functions

● Signals, Interrupts, Messages, Semaphores, etc can all be altered to provide

processing power where needed

● OS is broken into many small parts that need not all be used at once

● Very flexible design allows for large amounts of customization

References[1] “RTEMS.com | An Open Real-Time Operating System,” RTEMS.com | An Open Real-Time Operating System. [Online]. Available: http://www.rtems.com/. [Accessed: 4-Apr-2018].

[2] “RTEMS Real Time Operating System (RTOS),” RTEMS Real Time Operating System (RTOS) | Real-Time and Real Free RTOS. [Online]. Available: https://www.rtems.org/. [Accessed: 4-Apr-2018].

[3] “RTEMS Operating System,” RTEMS Operating System | Realtime Embedded. [Online]. Available: http://www.rte.se/blog/blogg-modesty-corex/rtems-operating-system/1.13. [Accessed: 4-Apr-2018]

[4] “TECHNICAL REPORT RD-GC-92-32 REAL TIME EXECUTIVE FOR MISSILE SYSTDIS USER'S GUIDE i80386 C INTERFACE,” dtic.mil. [Online]. Available: http://www.dtic.mil/dtic. [Accessed: 4-Apr-2018].

[5] “What is An RTOS?,” Why RTOS and What is RTOS? [Online]. Available: https://www.freertos.org/about-RTOS.html. [Accessed: 9-Apr-2018].