Real Time Systems & RTOS


Published on

An introduction on Real Time Systems, RTOS and its characteristics.

1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Definition comes from Ben Ari Implementation of parallelism is a topic in computer systems (hardware and software) that is essentially independent of concurrent programming. The topic has been around for a long time. |Can we traced back to Conway and Dijkstra in the early 60’s. Perhaps its defining moment was the publications of Dijkstra’s paper on Co-operating Sequential Processesin 1965 First concurrent programming language Simula 66? Not under 1983 until we see the first international standard concurrent programming language - Ada. This Department via Ian Pyle and Ian Wand were involved in that development Indeed is not Universally accepted that programming languages should be concurrent
  • Generally speaking, RTOSs are a subset of embedded operating systems. While you can solve many application challenges with an embedded operating system, some challenges can only be solved with the determinism afforded by a hard RTOS.
  • VxWorks uses Micro kernel with minmal set of utilities. (In the early days OS uses Monolithic kernel , It is a big kernel putting all together) VxWorks's default scheduler comes with two possible scheduling algorithms : A preemptive prioritybased scheduler (with 256 priority levels) and a round-robin scheduler . It is also possible to use a POSIX scheduler with both a first-in first-out (FIFO) and a round-robin algorithm. eCOS is an RTOS from Redhat. RT Linux consists of LynxOS from LynxWorks and BlueHat Linux.
  • High-speed control applications, such as hardware-in-the-loop simulations and motion control systems, typically require ISR and IST times to be less than 10 µs.
  • Context switch latency is the amount of time it takes to switch control to a high-priority process in response to an event that makes it run-able
  • Can you assign those algorithms on a per-thread basis, or does the RTOS force you into assigning one algorithm to all threads in your system? In Rate-Monotonic scheduling sets static priorities to the periodic tasks which it's scheduling. If a task has a short period - that is, it will be executed often, the scheduler will give it a higher priority . Tasks with longer period gets a lower priority . The draw backs of this schedule algorithm is it can't always guarantee that it's possible to schedule a set of tasks, or more correctly, it can't always maximize the CPU utilization EDF (Earliest Deadline First) scheduling case tasks always have dynamic priorities. The tasks with earliest deadlines will have always high priority. POSIX 1.b Scheduler are SCHEDULE_FIFO (First in First out) and SCHEDULE_RR (Round Robin) Does the RTOS support a partitioning scheduler that provides tasks with a guaranteed percentage of CPU time, regardless of what other tasks, including higher-priority tasks, are doing? They also ensure that critical tasks can remain available and meet their deadlines, even when the system is subjected to denial of service attacks and other malicious exploits. Can you easily customize the GUI's look-and-feel? Can the GUI display and input multiple languages (Chinese, Korean, Japanese, English, Russian, etc.) simultaneously? Can 2D and 3D applications easily share the same screen? Does the RTOS support an up-to-date suite of preintegrated protocol stacks, such as IPv4, IPv6, IPsec, SCTP, and IP filtering with NAT? Does it also support an embedded Web browser? The browser should have a scalable footprint and be capable of rendering standard Web pages on very small screens. It should also support standards such as HTML 4.01, SSL 3.0, CSS 1 and 2, OMA , JavaScript, WAP, and WML. Does the RTOS lock you into a proprietary API, or does it provide full support for a standard API like POSIX, which makes it easier to port code to and from other OSs? Does the RTOS vendor provide well-documented source and customization kits to help tailor the RTOS to your specific requirements? Does the vendor also offer driver development kits,
  • Real Time Systems & RTOS

    1. 1. Concepts on Real Time Systems & RTOS By Ch. Vishwa Mohan Software Consultant & Trainer
    2. 2. Who am I anyway? <ul><li>Name : Ch.Vishwa Mohan </li></ul><ul><li>Qualification : M.E ( Inst ) passed in 1994. </li></ul><ul><li>Experience : Over 13+ Years of Software development experience specially in Embedded/ Real Time systems in Industrial Automation, Process Control, </li></ul><ul><li> Semiconductor related areas. </li></ul>
    3. 3. What is an Real Time System ? <ul><li>A Real time system is one, Correctness of the computations not only depends on logical correctness but also the time at which the result is produced. If the timing constrains are not meet, system failure is said to have occurred. </li></ul><ul><li>Computer systems those operates in an environment in which they are required to response to external events, not only in a functionally correct way, but also in a correct timely way are labeled real-time systems. </li></ul><ul><li>Real Time systems are one in which timelines, performance, and schedulability are essential to correctness. </li></ul><ul><li>Real-time systems are generally reactive in nature, usually responding to external events via interrupts. </li></ul>
    4. 4. What is an Real Time System ? <ul><li>A real-time system is any information processing system which has to respond to externally generated input stimuli within a finite and specified period </li></ul><ul><ul><li>The correctness depends not only on the logical result but also the time it was delivered. </li></ul></ul><ul><ul><li>Failure to respond in time is as bad as the wrong response! </li></ul></ul><ul><li>The computer is a component in a larger engineering system => EMBEDDED COMPUTER SYSTEM </li></ul><ul><li>99% of all processors are for the embedded systems market </li></ul>
    5. 5. A simple fluid control system Pipe Flow meter Valve Interface Computer Time Input flow reading Processing Output valve angle
    6. 6. A Widget-Packing Station Line controller Computer Switch Assembly line Box 0 = stop 1 = run Bell Switch
    7. 7. A Typical Embedded System Algorithms for Digital Control Data Logging Data Retrieval and Display Operator Interface Interface Engineering System Remote Monitoring System Real-Time Clock Database Operator’s Console Display Devices Real-Time Computer
    8. 8. Characteristics of Real Time Systems <ul><li>Large and complex — vary from a few hundred lines of assembler or C to 20 million lines of Ada estimated for the Space Station Freedom </li></ul><ul><li>Concurrent control of separate system components* — devices operate in parallel in the real-world; better to model this parallelism by concurrent entities in the program </li></ul><ul><li>Facilities to interact with special purpose hardware — need to be able to program devices in a reliable and abstract way </li></ul><ul><li>Extreme reliability and safe — embedded systems typically control the environment in which they operate; failure to control can result in loss of life, damage to environment or economic loss </li></ul><ul><li>Guaranteed response times — we need to be able to predict with confidence the worst case response times for systems; efficiency is important but predictability is essential. </li></ul>
    9. 9. Concurrent Programming <ul><li>The name given to programming notation and techniques for expressing potential parallelism and solving the resulting synchronization and communication problems </li></ul><ul><li>Virtually all real-time systems are inherently concurrent. ( Devices operate in parallel in the real world ). </li></ul><ul><li>Implementation of parallelism is a topic in computer systems (hardware and software) that is essentially independent of concurrent programming. </li></ul><ul><ul><li>To allow the expression of potential parallelism so that more than one computer can be used to solve the problem. </li></ul></ul>
    10. 10. Why we need Concurrent Programming ? <ul><li>To fully utilise the processor </li></ul>Response time in seconds 10 -7 10 -6 10 -5 10 -4 10 -3 10 -2 10 -1 10 2 10 1 10 -8 10 -9 10 0 human tape floppy CD memory processor
    11. 11. Parallelism Between CPU and I/O Devices CPU Initiate I/O Operation Interrupt I/O Routine I/O Finished I/O Device Process I/O Request Signal Completion Continue with Outstanding Requests
    12. 12. Airline Reservation System VDU VDU VDU VDU P P P P Process Database
    13. 13. Air Traffic Control
    14. 14. Terminology <ul><li>A concurrent program is a collection of autonomous sequential processes, executing (logically) in parallel </li></ul><ul><li>The actual implementation (i.e. execution) of a collection of processes usually takes one of three forms. </li></ul><ul><li>Multiprogramming </li></ul><ul><ul><li>Processes multiplex their executions on a single processor </li></ul></ul><ul><li>Multiprocessing </li></ul><ul><ul><li>Processes multiplex their executions on a multiprocessor system where there is access to shared memory </li></ul></ul><ul><li>Distributed Processing </li></ul><ul><ul><li>Processes multiplex their executions on several processors which do not share memory </li></ul></ul>
    15. 15. Reliability, Failure and Faults <ul><li>The reliability of a system is a measure of the success with which it conforms to some authoritative specification of its behaviour. </li></ul><ul><li>When the behaviour of a system deviates from that which is specified for it, this is called a failure </li></ul><ul><li>Failures result from unexpected problems internal to the system which eventually manifest themselves in the system's external behaviour </li></ul><ul><li>These problems are called errors and their mechanical or algorithmic cause are termed faults </li></ul><ul><li>Systems are composed of components which are themselves systems: hence </li></ul><ul><ul><li>> failure -> fault -> error -> failure -> fault </li></ul></ul>
    16. 16. Real Time S/W design include of: <ul><li>Identification of Real time tasks. </li></ul><ul><li>Co-ordination between real time tasks. </li></ul><ul><li>Processing of system interrupts. </li></ul><ul><li>I/O handling to ensure no data loss. </li></ul><ul><li>Specifying internal/external constrains of system. </li></ul><ul><li>Ensuring the accuracy of data. </li></ul>
    17. 17. Topics interest in RT System Includes: <ul><li>Responding to external events </li></ul><ul><li>Priorities and scheduling </li></ul><ul><li>Synchronization requirements </li></ul><ul><li>Deterministic response times. </li></ul>
    18. 18. Metrics of Real Time Systems Include: <ul><li>Predictability fast responses to urgent events: The device should perform its intended function in a predictable manner, while supporting other functions. </li></ul><ul><li>High degree of schedulability: The timing requirements of the system must be satisfied at high degrees of utilization. </li></ul><ul><li>Stability under transient overload: When the system is overloaded by events and it is impossible to meet all the deadlines, the deadlines of selected critical tasks must still be guaranteed. </li></ul>
    19. 19. Problems for Real Time Software Developers: <ul><li>Real-time software developers have all the problems of non-real time developers plus several more: </li></ul><ul><ul><li>Timeliness: </li></ul></ul><ul><ul><ul><li>This timeliness is the key difference in real time systems. Many people thing of real time system as really-fast, but it is a misconception. </li></ul></ul></ul><ul><ul><ul><li>In real-time systems, the right answer at the wrong time is the wrong answer. </li></ul></ul></ul><ul><ul><ul><li>Designers can distinguish hard, soft and firm real time systems*. </li></ul></ul></ul><ul><ul><li>Low Resource Availability ( Memory, CPU speed, etc.,) </li></ul></ul><ul><ul><li>Reliability Issues: Should be more reliable, No Ctrl + Alt + Del </li></ul></ul><ul><ul><li>Safety Issues: Need to use Dual memory storage, CRC, Watch dog timer, etc., </li></ul></ul><ul><ul><li>Compiler and Tool Availability: </li></ul></ul>
    20. 20. Hard, Soft & Firm Real Time Systems: <ul><li>Hard Real Time Systems: In Hard real time systems the processing deadlines are missed, the system had said to be failed. </li></ul><ul><li>(Eg: Missile may not attack the target. Aircraft may crash, Nuclear Power plant may explode). </li></ul><ul><li>Soft Real Time Systems: In soft real time systems must meet the deadline but only in the average case. </li></ul><ul><li>(Eg: Screen switching at 250 m sec, Maintain and update of flight plans in commercial airlines, Live audio/Video systems) </li></ul><ul><ul><li>A soft real-time operating system is one that has reduced constraints on 'lateness,' but still must operate quickly within fairly consistent time constraints.&quot; </li></ul></ul><ul><li>Firm Real Time Systems: These systems that are primarily soft, but do have a hard deadline as well. </li></ul>
    21. 21. Hard, Soft & Firm Real Time Systems: <ul><li>It is important to note that hard versus soft real-time does not necessarily relate to the length of time available. </li></ul><ul><ul><li>A machine may overheat if a processor does not turn on cooling within 15 minutes . Still it is a Hard real time system. </li></ul></ul><ul><ul><li>A network interface card may lose buffered data if it is not read within a fraction of a second , but the data can be resent over the network without major adverse consequences. It is a Soft Real time system. </li></ul></ul>
    22. 22. Hard, Soft & Firm Real Time Systems: <ul><li>Hard real-time — systems where it is absolutely imperative that responses occur within the required deadline. E.g. Flight control systems. </li></ul><ul><li>Soft real-time — systems where deadlines are important but which will still function correctly if deadlines are occasionally missed. E.g. Data acquisition system. </li></ul><ul><li>Real real-time — systems which are hard real-time and which the response times are very short. E.g. Missile guidance system. </li></ul><ul><li>Firm real-time — systems which are soft real-time but in which there is no benefit from late delivery of service. </li></ul><ul><li>A single system may have all hard, soft and real real-time subsystems, In reality many systems will have a cost function associated with missing each deadline. </li></ul>
    23. 23. <ul><li>RTOS </li></ul><ul><li>( Real Time Operating Systems ) </li></ul>
    24. 24. RTOS ( Real Time Operating System ) <ul><li>What is an RTOS? </li></ul><ul><ul><li>RTOS is the brain of the Real Time System. </li></ul></ul><ul><ul><li>Respond to predictable way to unpredictable events. </li></ul></ul><ul><ul><li>Strict timing constraints. </li></ul></ul><ul><ul><li>Which would ensure fast interrupt response and real time scheduling. </li></ul></ul><ul><li>Primary role of an OS is to manage resources so as to meet the demand of target applications. In addition to this Real time applications demands Timelines and Predictability . The OS targeting real time applications meet the above demands by paying special attention to a host of OS features Like: </li></ul><ul><ul><li>Multitasking & Synchronization </li></ul></ul><ul><ul><li>Interrupt and Event Handling </li></ul></ul><ul><ul><li>Inter Task Communication </li></ul></ul><ul><ul><li>Timer & Clocks </li></ul></ul><ul><ul><li>Input/Output </li></ul></ul><ul><ul><li>Memory Management. </li></ul></ul><ul><li>Modern real time systems are based on complementary concept of multitasking and Inter task communication. </li></ul>
    25. 25. Different RTOS’s available : <ul><li>VxWorks </li></ul><ul><li>QNX </li></ul><ul><li>pSOS </li></ul><ul><li>RT Linux </li></ul><ul><li>eCOS </li></ul><ul><li>Win CE (& Win CE.NET) </li></ul><ul><li> C/OS-II </li></ul><ul><li>etc., </li></ul>
    26. 26. Real-time Programming Languages <ul><li>Assembly languages </li></ul><ul><li>Sequential systems implementation languages — e.g. RTL/2, C. </li></ul><ul><li>Both normally require operating system support. </li></ul><ul><li>High-level concurrent languages. Impetus from the software crisis. e.g. Ada, Chill, Modula-2, Java. </li></ul><ul><li>No operating system support! We will consider: </li></ul><ul><ul><li>Java/Real-Time Java </li></ul></ul><ul><ul><li>C and Real-Time POSIX </li></ul></ul><ul><ul><li>Ada 95 </li></ul></ul><ul><ul><li>Also Modula-1 for device driving </li></ul></ul>
    27. 27. RTOS Characteristics: <ul><li>The OS must be multithreaded and preemptive*. </li></ul><ul><li>The notion of thread priority must exists. </li></ul><ul><li>A system of Priority inheritance* must be exists. </li></ul><ul><li>The OS must support predictable thread synchronization mechanism. </li></ul><ul><li>Mechanism to avoid Priory Inversion*. </li></ul><ul><li>Sufficient Priority levels. </li></ul><ul><li>The interrupt latency must be predictable. </li></ul><ul><li>In addition to all the above, OS behavior must be predictable, </li></ul><ul><li> Contd…, </li></ul>
    28. 28. RTOS Characteristics: <ul><li>In addition to previous characteristics, Real time system developers must have detailed information about the system interrupt levels, system calls and timings. </li></ul><ul><ul><li>The maximum time during which interrupt are masked by the OS and device drivers must be known. </li></ul></ul><ul><ul><li>The maximum time the device drivers use to process an interrupt and specific IRQ information relating to these device drivers must be known. </li></ul></ul><ul><ul><li>The interrupt latency* ( time from interrupt occur to interrupt task run) must be predictable and compatible with application requirements. </li></ul></ul><ul><ul><li>The time for every system call should be predictable and must be independent of no of objects present in the system. </li></ul></ul>
    29. 29. Different Types of Multitasking Systems: <ul><li>Preemptive Multitasking system </li></ul><ul><ul><li>The task can be stopped by its execution whenever higher priority task is ready to execute called preemptive multi tasking . </li></ul></ul><ul><li>Non-Preemptive Multitasking System </li></ul><ul><li>Co-operative Multitasking System </li></ul>
    30. 30. Priority Inheritance <ul><li>Priority Inversion: It refers to a situation where the use of a resource by a low-priority thread delays the execution of a high-priority thread, when both are contending for the same resources. To address this you have following solutions: </li></ul><ul><ul><li>Priority Inheritance Protocol: It temporarily raises the priority of the low-priority thread to match that of the blocked thread until low priority thread releases the resource. </li></ul></ul><ul><ul><li>Priority Ceiling Protocol: Here the priority of the low-priority thread is raised immediately when it lock the resource, rather then waiting for a sub sequent lock attempt by a high priority thread. </li></ul></ul>
    31. 31. Deadlocks and Race Conditions <ul><li>Deadlocks: A deadlock occurs when each thread is waiting for the other to complete an action. </li></ul><ul><li>Race Condition: A race condition occurs when the threads are sharing a value and the final result of the value depends on the scheduling order of the thread. </li></ul>
    32. 32. Definition on Latencies & Delays: <ul><li>Interrupt Latency: The amount of time that elapses from the time that an external interrupt arrives at the processor until the time that the interrupt processing* begins. </li></ul><ul><li>Context Switch Delay: The amount of time required to scheduling a task. It involves scheduler determines which task to run saving the current task context and restoring the new task. </li></ul><ul><li>ISR Latency: Time from the point when an IRQ is set at the CPU to the point when the ISR begins to run. </li></ul><ul><li>IST Latency: IST latency is the period from the point when an ISR finishes execution (signals a thread) to the point when the IST begins execution. </li></ul>
    33. 33. Interrupt Latencies: <ul><li>In a typical RTOS these ISR and IST latencies are measured in single digit micro seconds. </li></ul>
    34. 34. Interrupt & Context Switch Latency:
    35. 35. Steps Involved in Interrupt Processing: <ul><li>Suspends the active thread. </li></ul><ul><li>Saves thread-related data that will be needed when the thread is resumed. </li></ul><ul><li>Transfers control to an ISR. </li></ul><ul><li>Performs some processing in the ISR to determine what action is needed. </li></ul><ul><li>Retrieves and saves any critical (incoming) data associated with the interrupt. </li></ul><ul><li>Sets any required device-specific (output) values. </li></ul><ul><li>Determines which thread should execute given the change in environment created by the interrupt and its processing. </li></ul><ul><li>Clears the interrupt hardware to allow the next interrupt to be recognized. </li></ul><ul><li>Transfers control to the selected thread, including retrieval of its environmental data that was saved when it was last interrupted. </li></ul>
    36. 36. Considerations Selecting RTOS <ul><li>Real Time Capabilities </li></ul><ul><li>( Hard real time interrupt handling and Premptive scheduling services). </li></ul><ul><li>Foot Print </li></ul><ul><li>Target CPU </li></ul><ul><li>Interrupt Latencies & Context Switch times. </li></ul><ul><li>Available API’s </li></ul><ul><li>BSP’s </li></ul><ul><li>Development Environment and Debugging Tools </li></ul><ul><li>Licensing </li></ul>
    37. 37. Considerations Selecting RTOS <ul><li>Flexible Choice of Scheduling Algorithms ( Eg: FIFO, Round Rabin, Rate-Monotonic, EDF, POSIX 1.b Scheduler, Sporadic, etc., ) </li></ul><ul><li>Guaranteed CPU availability : ( RTOS supporting Partitioning Scheduler, etc., ). </li></ul><ul><li>GUI Support: ( Eg: Win CE) </li></ul><ul><li>Tools for remote diagnostics: </li></ul><ul><li>Internet capabilities: </li></ul><ul><li>Standard APIs: </li></ul><ul><li>Source code and Driver Development Kit support: </li></ul>
    38. 38. Factors Selecting Commercial Operating Systems:
    39. 39. Thank you ! You can reach me at: