Real%20Time%20Operating%20Systems%20for%20Networked%20Embedded%20Systems

1
Real Time Operating Systems for Networked
Embedded Systems

• Subhashis Banerjee
• Indian Institute of Technology
• Delhi
• suban_at_cse.iitd.ac.in

With Soumyadeb Mitra, Nitin Rajput,
M.Balakrishnan
2
Fire alarm system an example
Central server
TCP/IP over radio
Controllers ARM based
Low bandwidth radio links
Sensors microcontroller based
3
Fire Alarm System

• Problem
• Hundreds of sensors, each fitted with Low Range
  Wireless
• Sensor information to be logged in a server
  appropriate action initiated
• Possible Solution
• Collaborative Action
• Routing
• Dynamic Sensors/controllers may go down
• Auto Configurable No/easy human intervention.
• Less Collision/Link Clogging
• Less no of intermediate nodes
• Fast Response Time
• Secure

4
RTOS Target Architectures
Processors MIPS Microcontrollers
20 ARM7 100-133 ARM9 180-250 Strong
ARM 206 Intel Xscale 400 Mips4Kcore 400 X86
5
Presentation Outline

• Definitions
• Role of an OS in Real Time Systems
• Features of Real Time Operating Systems
• Scheduling
• Resource Allocation
• Interrupt Handling
• Other Issues
• Linux for Real Time Systems and RTLinux
• rtker Our own RTOS
• Other RTOSs

6
Real Time System

• A system is said to be Real Time if it is
  required to complete its work deliver its
  services on time.
• Example Flight Control System
• All tasks in that system must execute on time.
• Non Example PC system

7
Hard and Soft Real Time Systems

• Hard Real Time System
• Failure to meet deadlines is fatal
• example Flight Control System
• Soft Real Time System
• Late completion of jobs is undesirable but not
  fatal.
• System performance degrades as more more jobs
  miss deadlines
• Online Databases
• Qualitative Definition.

8
Hard and Soft Real Time Systems(Operational
Definition)

• Hard Real Time System
• Validation by provably correct procedures or
  extensive simulation that the system always meets
  the timings constraints
• Soft Real Time System
• Demonstration of jobs meeting some statistical
  constraints suffices.
• Example Multimedia System
• 25 frames per second on an average

9
Role of an OS in Real Time Systems

• Standalone Applications
• Often no OS involved
• Micro controller based Embedded Systems
• Some Real Time Applications are huge complex
• Multiple threads
• Complicated Synchronization Requirements
• Filesystem / Network / Windowing support
• OS primitives reduce the software design time

10
Features of RTOSs

• Scheduling.
• Resource Allocation.
• Interrupt Handling.
• Other issues like kernel size.

11
Scheduling in RTOS

• More information about the tasks are known
• No of tasks
• Resource Requirements
• Release Time
• Execution time
• Deadlines
• Being a more deterministic system better
  scheduling algorithms can be devised.

12
Scheduling Algorithms in RTOS

• Clock Driven Scheduling
• Weighted Round Robin Scheduling
• Priority Scheduling
• (Greedy / List / Event Driven)

13
Scheduling Algorithms in RTOS (contd)

• Clock Driven
• All parameters about jobs (release time/
  execution time/deadline) known in advance.
• Schedule can be computed offline or at some
  regular time instances.
• Minimal runtime overhead.
• Not suitable for many applications.

14
Scheduling Algorithms in RTOS (contd)

• Weighted Round Robin
• Jobs scheduled in FIFO manner
• Time quantum given to jobs is proportional to
  its weight
• Example use High speed switching network
• QOS guarantee.
• Not suitable for precedence constrained jobs.
• Job A can run only after Job B. No point in
  giving time quantum to Job B before Job A.

15
Scheduling Algorithms in RTOS (contd)

• Priority Scheduling
• (Greedy/List/Event Driven)
• Processor never left idle when there are ready
  tasks
• Processor allocated to processes according to
  priorities
• Priorities
• static - at design time
• Dynamic - at runtime

16
Priority Scheduling

• Earliest Deadline First (EDF)
• Process with earliest deadline given highest
  priority
• Least Slack Time First (LSF)
• slack relative deadline execution left
• Rate Monotonic Scheduling (RMS)
• For periodic tasks
• Tasks priority inversely proportional to its
  period

17
Resource Allocation in RTOS

• Resource Allocation
• The issues with scheduling applicable here.
• Resources can be allocated in
• Weighted Round Robin
• Priority Based
• Some resources are non preemptible
• Example semaphores
• Priority Inversion if priority scheduling is used

18
Priority Inversion
19
Solutions to Priority Inversion

• Non Blocking Critical Section
• Higher priority Thread may get blocked by
  unrelated low priority thread
• Priority Ceiling
• Each resource has an assigned priority
• Priority of thread is the highest of all
  priorities of the resources its holding
• Priority Inheritance
• The thread holding a resource inherits the
  priority of the thread blocked on that resource

20
Other RTOS issues

• Interrupt Latency should be very small
• Kernel has to respond to real time events
• Interrupts should be disabled for minimum
  possible time
• For embedded applications Kernel Size should be
  small
• Should fit in ROM
• Sophisticated features can be removed
• No Virtual Memory
• No Protection

21
Linux for Real Time Applications

• Scheduling
• Priority Driven Approach
• Optimize average case response time
• Interactive Processes Given Highest Priority
• Aim to reduce response times of processes
• Real Time Processes
• Processes with high priority
• No notion of deadlines
• Resource Allocation
• No support for handling priority inversion

22
Interrupt Handling in Linux

• Interrupts are disabled in ISR/critical sections
  of the kernel
• No worst case bound on interrupt latency
  avaliable
• eg Disk Drivers may disable interrupt for few
  hundred milliseconds
• Not suitable for Real Time Applications
• Interrupts may be missed

23
Other Problems with Linux

• Processes are non preemtible in Kernel Mode
• System calls like fork take a lot of time
• High priority thread might wait for a low
  priority thread to complete its system call
• Processes are heavy weight
• Context switch takes several hundred microseconds

24
Why Linux

• Coexistence of Real Time Applications with non
  Real Time Ones
• Example http server
• Device Driver Base
• Stability

25
RTLinux

• Real Time Kernel at the lowest level
• Linux Kernel is a low priority thread
• Executed only when no real time tasks
• Interrupts trapped by the Real Time Kernel and
  passed onto Linux Kernel
• Software emulation to hardware interrupts
• Interrupts are queued by RTLinux
• Software emulation to disable_interrupt()

26
RTLinux (contd)

• Real Time Tasks
• Statically allocate memory
• No address space protection
• Non Real Time Tasks are developed in Linux
• Communication
• Queues
• Shared memory

27
RTLinux Framework
28
rtker Our RTOS

• Motivation
• Our own OS
• Full grasp over source code Easily modifiable,
  portable
• Features
• Modular Design
• Isolation of Architecture/CPU dependent and
  independent code Easy to Port
• Pluggable Scheduler
• Two level Interrupt Handling
• Small footprint
• Oskits Device Driver Framework

29
Pluggable Scheduler

• Scheduler - part of the Application
• Kernel interacts with the scheduler through an
  API
• Application developer needs to implement the
  scheduler API
• Can optimize on Data Structures Algorithms for
  implementing the scheduler

30
rtker Block Diagram
31
Two Level Interrupt Handling

• Two level Interrupt Handling
• Top Half Interrupt Handler
• Called Immediately Kernel never disables
  interrupts
• Cannot invoke thread library functions - Race
  Conditions
• Bottom Half Interrupt Handler
• Invoked when kernel not in Critical Section
• Can invoke thread library functions
• Very Low Response time (as compared to Linux)

32
Two Level Interrupt Handling
33
(No Transcript)
34
Other Features

• Footprint
• Small footprint (50kb)
• Oskits Device Driver Framework
• Allows direct porting of existing drivers from
  Linux.
• Example Ethernet Driver of Linux

35
Other RTOSs

• LynxOS
• Microkernel Architecture
• Kernel provides scheduling/interrupt handling
• Additional features through Kernel Plug Ins(KPIs)
• TCP/IP stack , Filesystem
• KPIs are multithreaded
• Memory Protection/ Demand Paging Optional
• Development and Deployment on the same host
• OS support for compilers/debuggers

36
Other RTOSs (contd)

• VxWorks
• Monolithic Architecture
• Real Time Posix compliant
• Cross development System
• pSOS
• Object Oriented OS

37
Peripheral devices and protocols

• Interfacing
• Serial/parallel ports, USB, I2C, PCMCIA,
  IDE
• Communication
• Serial, Ethernet, Low bandwidth radio,
  IrDA,
• 802.11b based devices
• User Interface
• LCD, Keyboard, Touch sensors, Sound,
  Digital
• pads, Webcams
• Sensors
• A variety of sensors using fire,
  temperature,
• pressure, water level, seismic, sound,
  vision