1. An Introduction and Practical approach to RTOS concepts.

2. 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

3. 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.”

4. 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

5. 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

6. Hard Vs Soft RT systems Hard RT task: Soft 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

7. 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.

8. 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

9. 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

10. 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

11. 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.

12. 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.

13. 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

14. Maintainability
This feature helps in the future development and maintenance of the RTOS
Not a strict need for one-time design systems

15. 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

16. RTOS complication factors (earlier)
Limited resources
Direct hardware access
Unpredictable I/O
Hardware reliability
Limited I/O
Required reliability
Cost

17. Evolution of RTOS

18. Traditional monolithic kernel

19. Microkernel

20. RTOS elements Scheduler I/O handler File handler (If any)
Exception handler

21. 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

22. 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

23. 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

24. 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

25. 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

26. Exception handler This take care of an abnormal condition.
Guarantees fail-safe performance of the RTOS
Exhaustive testing is need on this design

27. 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.

28. RTOS selection criteria
Processor
Performance (deterministic)
Cost
Initial
Royalties
Tools
Cross-compilers
Debuggers

29. 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

30. 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

31. Low end of the spectrum Accelerated Technologies Nucleus Kadak’s AMX
Kadak’s AMX

32. High end of the spectrum
Wind River VxWorks
Inegrated Systems’ pSOS
Microtec VRTX
QNX