Date post: | 24-Dec-2015 |
Category: |
Documents |
Upload: | oswald-simpson |
View: | 228 times |
Download: | 3 times |
An Introduction and Practical approach to RTOS concepts.
What is an Operating System? Piece of software that sits between applications and
hardware. Hides hardware details from applications. Provides standard interfaces to hardware and
software devices. Provides protection mechanisms. Typical services:
– Memory management (main memory, secondary memory, virtual memory, paging, file system)
– Process management (scheduling, task management, synchronization, interrupt and exception handling, inter task communication)
– Protection– Input - Output management (device driver)– Support of distributed applications and multiprocessors
What is a Real Time System? Timeliness is the single most important
aspect of a real-time system. These systems respond to a series of external inputs, which arrive in an unpredictable fashion. The real-time systems process these inputs, take appropriate decisions and also generate output necessary to control the peripherals connected to them.
As defined by Donald Gillies “A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time in which the result is produced. If the timing constraints are not met, system failure is said to have occurred.”
Examples of RT Systems.
Control of production processes / industrial automation
Railway switching systems Automotive applications Flight control systems Environmental acquisition and monitoring Telecommunication systems Household appliances Robotics Military systems Space missions
An in-depth view Real-time
– Time: main difference to other classes of computation
– Real: reaction to external events must occur during their evolution.
System time (internal time) has to be measured with same time scale as controlled environment (external time)
Real time does not mean fast but predictable Concept of deadline:
– Time after which a computation is not just late, but also wrong
Hard Vs Soft RT systems Hard RT task:
– if missing its deadline may cause catastrophic consequences on the environment under control
Soft RT task: – if meeting its deadline is desirable (e.g. for
performance reasons) but missing does not cause serious damage
RTOS that is able to handle hard RT tasks is called hard real-time OS
Why is a desktop OS not suited?
Monolithic kernel is too feature rich. Monolithic kernel is not modular, fault-
tolerant, configurable, modifiable, … Takes too much space. Not power optimized. Not designed for mission-critical
applications.
Design goals of an RTOS Small: minimal memory footprint Open: many interfaces and protocols, open
system standards Modular: easy to integrate custom components Portable: run on lots of devices Real- time: support of hard deadlines, bounded
interrupts, scheduling, synchronization Power consumption: integrated power
management Robustness: fault tolerant, halts, guards,
exceptions, CRC, … Configurable: adaptable to required functionality
Desirable features of RTOS Timeliness
– OS has to provide mechanisms for: • time management • handling tasks with explicit time constraints
Predictability Fault tolerance Design for peak load Maintainability
Timeliness
In timeliness, we say that a given task should be completed in stipulated amount of time else there is no meaning of performing the task.
This is so strict in Hard RT systems and is adjustable in Soft RT systems
This is also referred as responsiveness
Predictability
This feature insists that the response of the system should be predictable for any unpredicted input to the system.
This takes care of the stability of the system.
When the system doesn’t have this feature, it leads to a chaos state.
Fault tolerance
This takes care of the exceptions that occurs in the system.
Fault tolerance is the feature by which the system can continue normally even a failure occurs.
This is also referred as fail-safe operation, exception handling.
Design for peak load The efficiency of the RTOS is taken
care by this factor While designing the system, the peak
load should be taken into account as the normal load
This would guarantee best operation even at fully loaded condition
Testing should be done to meet this peak load condition
Maintainability
This feature helps in the future development and maintenance of the RTOS
Not a strict need for one-time design systems
RTOS simplification factors (earlier) No display No disk drives (and no file system) One, dedicated “user” Limited security requirements Limited Tasks Limited connectivity Controlled interaction Closed system
RTOS complication factors (earlier) Limited resources Direct hardware access Unpredictable I/O Hardware reliability Limited I/O Required reliability Cost
Evolution of RTOS
Traditional monolithic kernel
Microkernel
RTOS elements
Scheduler I/O handler File handler (If any) Exception handler
Scheduler definition Given a set of tasks J = {J 1 , ...J n } a
schedule is an assignment of tasks to the processor so that each task is executed until completion.
A schedule is called feasible if all tasks can be completed according to a set of specified constraints
A set of tasks is called schedulable if there exist at least one algorithm that can produce a feasible schedule
Key fact of an RT scheduling
– Any RT scheduling policy must be preemptive:
• Tasks performing exception handling may need to preempt running tasks to ensure timely reaction
• Tasks may have different levels of criticalness. This can be mapped to a preemption scheme
• More efficient schedules can be produced with preemption
Task synchronizing Mechanisms:
– Mutex– Semaphore– Message Queue– Monitor
Must be manipulated in a critical section! Used for shared resources:
– Global variables– Memory buffers– Device registers
I/O handler
I/O can be using any device unlike traditional systems
I/O handler should be efficient to take care of the latency
File handler
Normally takes care of maintaining files like traditional systems except that the medium may be different
Efficient way of optimizing available space should be taken care
Exception handler
This take care of an abnormal condition. Guarantees fail-safe performance of the
RTOS Exhaustive testing is need on this
design
Hard reset
A hard reset is termed to be the reset of the system to its initial state loosing all the previous data and states of the system
There should be provision for this to handle if all fail-safe measure fails.
RTOS selection criteria Processor Performance (deterministic) Cost
– Initial– Royalties
Tools– Cross-compilers– Debuggers
RTOS selection criteria (contd…) Capability
– Scheduling– Device Drivers– Protocol stacks– Flash file systems
Availability of source code Technical Support Compatibility with 3 rd party tools Floating-point math Accommodates your constraints
An RTOS should
Support a wide range of hardware platforms Have a scalable kernel Support multi-level interrupt process-level
priorities Support multi-threaded operations with
predictable thread synchronization Support code sharing for re-entrant tasks Provide Real-Time memory management Support ANSI C Support the Real-Time POSIX® standards Provide a wide range of commercially
available software tools
Low end of the spectrum
Accelerated Technologies Nucleus– http://www.acceleratedtechnology.com
Kadak’s AMX– http://www.kadak.com/
High end of the spectrum Wind River VxWorks
– http://www.windriver.com/ Inegrated Systems’ pSOS
– http://www.windriver.com/ Microtec VRTX
– http://www.mentor.com/microtec/ QNX
– http://www.qnx.com/