View
8
Download
0
Category
Preview:
Citation preview
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].
Recommended