Presentation on Real Time Operating Systems

1
Presentation on Real Time Operating Systems
2
Contents

• Real Time System Fundamentals
• Real Time Operating System (RTOS)
• Linux as RTOS

3
What are Real-time Systems ?

• Real-time systems
• Those systems in which the correctness of the
  system depends not only on the logical result of
  computation, but also on the time at which the
  results are produced.

4
Types of Real Time Systems

• Based on Hard deadline Penalty due to missing
  deadline is a higher order of magnitude than the
  Reward in meeting the deadline.
• Based on Soft deadline Penalty often equal /
  lesser magnitude than Reward.

5
A Sample Real Time System (1)
6
A Sample Real Time System (2)

• Mission Reaching the destination safely.
• Controlled System Car.
• Operating environment Road conditions.
• Controlling System
• - Human driver Sensors - Eyes and Ears of the
  driver.
• - Computer Sensors - Cameras, Infrared
  receiver, and Laser telemeter.

7
A Sample Real Time System (3)

• Controls Accelerator, Steering wheel,
  Break-pedal.
• Actuators Wheels, Engines, and Brakes.
• Critical tasks Steering and breaking
• Non-critical tasks Turning on radio

8
A Sample Real Time System (4)

• Performance is not an absolute one. It measures
  the goodness of the outcome relative to the best
  outcome possible under a given circumstance.
• Cost of fulfilling the mission ? Efficient
  solution.
• Reliability of the driver ? Fault-tolerance is a
  must.

9
Contents

• Real Time System Fundamentals
• Real Time Operating System (RTOS)
• Linux as RTOS

10
RTOS Kernel

• RTOS Kernel provides an Abstraction layer that
  hides from application software the hardware
  details of the processor / set of processors upon
  which the application software shall run.

11
RTOS Kernel Functions
12
Task Management

• Set of services used to allow application
  software developers to design their software as a
  number of separate chunks of software each
  handling a distinct topic, a distinct goal, and
  sometimes its own real-time deadline.
• Main service offered is Task Scheduling
• controls the execution of application software
  tasks
• can make them run in a very timely and responsive
  fashion.

13
Task Scheduling

• Non Real -time systems usually use Non-preemptive
  Scheduling
• Once a task starts executing, it completes its
  full execution
• Most RTOS perform priority-based preemptive task
  scheduling.
• Basic rules for priority based preemptive task
  scheduling
• The Highest Priority Task that is Ready to Run,
  will be the Task that Must be Running.

14
Priority based Preemptive Task Scheduling

• Every Task in a software application is assigned
  a priority.
• Higher Priority Higher Need for Quick Response.
• Follows nested preemption

15
Nested Preemption
Timeline for Priority-based Preemptive Scheduling
16
Task Switch (1)

• Each time the priority-based preemptive scheduler
  is alerted by an External world trigger /
  Software trigger it shall go through the
  following steps that constitute a Task Switch
• Determine whether the currently running task
  should continue to run.
• Determine which task should run next.
• Save the environment of the task that was stopped
  (so it can continue later).
• Set up the running environment of the task that
  will run next.
• Allow the selected task to run.

17
Task Switch (2)

• A Non Real time operating system might do task
  switching only at timer tick times.
• Even with preemptive schedulers a large array of
  tasks is searched before a task switch.
• A Real time OS shall use Incrementally arranged
  tables to save on time.

18
Task Switch (3)

• Task Switching Timing

19
Intertask Communication Synchronization

• These services makes it possible to pass
  information from one task to another without
  information ever being damaged.
• Makes it possible for tasks to coordinate
  productively cooperate with each other.

20
Inter-Task communication Synchronization

• The most important communication b/w tasks in an
  OS is the passing of data from one task to
  another.
• If messages are sent more quickly than they can
  be handled, the OS provides message queues for
  holding the messages until they can be processed.

21
Message passing in OS

• Most General Purpose OS actually copy messages
  twice as they transfer them from task to task via
  a message queue.

22
Message passing in RTOS

• In RTOS, the OS copies a pointer to the message,
  delivers the pointer to the message-receiver
  task, and then deletes the copy of the pointer
  with message-sender task.

23
Dynamic Memory Allocation in General Purpose OS

• Non-real-time operating systems offer memory
  allocation services from what is termed a Heap.
• Heaps suffer from a phenomenon called External
  Memory Fragmentation.
• Fragmentation problem is solved by Garbage
  collection / Defragmentation.
• Garbage collection algorithms are often wildly
  non-deterministic.

24
Dynamic Memory Allocation in RTOS

• RTOS does it by a mechanism known as Pools.
• Pools memory allocation mechanism allows
  application software to allocate chunks of memory
  of 4 to 8 different buffer sizes per pool.
• Pools avoid external memory fragmentation, by not
  permitting a buffer that is returned to the pool
  to be broken into smaller buffers in the future.
• When a buffer is returned the pool, it is put
  onto a free buffer list of buffers of its own
  size that are available for future re-use at
  their original buffer size

25
Contents

• Real Time System Fundamentals
• Real Time Operating System (RTOS)
• Linux as RTOS

26
Dark Side of Linux in Real-Time

• The Linux kernel (lt version 2.6) is neither
  preemptive nor reentrant by user processes.
• Processes are heavy-weight Linux has
  insufficient resource handling.
• Fair share scheduling algorithm .
• Unbound amount of CPU time used by interrupt
  handlers under Linux, and these run at a higher
  priority than any user process.

27
Typical Solutions for Linux

• 3 ways to deal with Linux s poor real-time
  performance
• Ignore the problem (only for soft real-time).
• Work around and run real-time applications under
  an RTOS with Linux itself as a separate task.
  e.g. RT-Linux.
• Adapt Linux and run a Linux compatible RTOS
  kernel instead of the Linux kernel.

28
Ignore the problem Approach

• The most popular approach is to ignore the
  problem.
• Mostly works for soft real-time systems.
• Design recommendations to reduce latency
• If possible, address all real-time response needs
  directly with interrupt service routines.
• Avoid known excessive interrupt-off periods in
  Linux.
• If a process component is required in the
  real-time control path, then consider aggregate
  system loading Adapt processes.

29
Work Around Approach

• Linux kernel runs as a task under a small
  real-time executive.
• Real-time tasks are run directly under the
  real-time executive
• Non-real-time tasks are run under Linux.
• Applications that work on such a system can
  include machine control, process control, and
  instrumentation applications.

30
Work Around - Advantages

• The real-time executive can be small and simple
  making it easier to verify its real-time
  performance.
• The Linux kernel running non-real-time tasks is
  "standard" Linux so it is compatible with other
  Linux distributions and can easily be updated.
• Supports hard real-time applications.

31
Work Around - Disadvantages

• Not applicable if real-time part of the software
  is large / not easily separated from the code
  that needs a Linux environment
• Tasks running under the real-time executive do
  not have access to the Linux facilities, device
  drivers, etc.
• Tasks running under the Linux kernel and can
  access the facilities are not real-time.
• Programmers tend to increase the number of
  facilities in the real-time kernel until the
  real-time executive replicates facilities of
  Linux.

32
Adapt Linux

• The original Linux kernel is replaced with a
  compatible kernel with hard real-time performance
  characteristics.
• The kernel is only a small part of a whole
  operating system. If just the Linux kernel is
  replaced and the libraries, utilities, and file
  structure remain the same.
• The real-time kernel must support all the
  facilities of a Linux kernel while still
  remaining fully preemptive and reentrant.

33
Adapt Linux Approach Advantages Disadvantages

• Advantages
• No limits on the size and complexity of the
  real-time application code.
• Third party software not originally envisioned
  for real-time use can be invoked by real-time
  tasks
• With the same programming interfaces, programmers
  who understand Linux would already be experts in
  the real-time environment.
• Disadvantages
• With modified Linux you are NOT sure of full
  compatibility with standard Linux application

34
Any Questions?
35
Thank You !