Your SlideShare is downloading. ×
Rt Course
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Rt Course


Published on

Published in: Business, Technology

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Grade: 60% exam, 40% assignments. Email: [email_address] Reception hours: after class. All lecture slides can be found on the course website. Book: B.P. Douglass, “Doing Hard Time”. Website for VxWorks Operating System:
  • 2. Lecture 1 Basic Concepts of Real-Time Systems
  • 3.
    • What distinguishes Real-Time(RT) systems from non-RT systems? Timing constraints!
    • Correctness depends not only on logical result but also time at which results are produced!
    • Tied to the performance of a computation during the actual time that the related physical process transpires in order that the results of the computation can be used in guiding the physical process.
    • Any system in which the time at which output is produced is significant. This is usually because the input corresponds to some movement in the physical world, and the output has to relate to the same movement. The lag from input time must be small enough to acceptable timeliness ( דייקנות ).
    • Any information processing activity/system, which responds to externally, generated input stimuli ( תמריץ ) within a finite and specified period.
    • The environment changes in real time and imposes timing constraints on the system. Current system output depends upon “timed behavior” of input.
  • 4.
    • Soft vs. Hard Real-Time System
    • A real time system has performance deadlines on its computations and actions.
    • Deadline : time when execution must be completed. A deadline is either a point in time (time-driven) or a delta-time interval (event-driven) by which a system action must occur.
    • Systems can be distinguished by the result of a delayed response:
    • Failure to respond in time can be accepted .
    • Response time is important but not crucial .
    • Failure to respond can be considered as bad as wrong response .
    • Hard deadline : late data may be a bad data.
    • Soft deadline : late data may be a good data.
  • 5.
    • Soft vs. Hard Real-Time System
    • Hard real-time system : jobs have hard deadlines; timing requirements must always be met !
    • Soft real-time system : jobs have soft deadlines; occasionally missing a deadline is undesirable, but does not result in system failure!
    • Some systems have both hard and soft deadlines, which are called firm deadlines. Individual deadlines may be missed as long as:
    • Sufficient average performance maintained in all times
    • Each deadline must be met no later than a certain time.
    • A schedulable system: can be guaranteed to meet all its performance requirements.
  • 6. Soft vs. Hard Real-Time Systems
  • 7. Soft vs. Hard Real-Time Systems Combat aircraft flight control system If the pilot is not giving new information about the environment quickly than the information is useless. It is no use being told what the air speed 10 minutes or even 10 seconds ago. If a pilot gives a command (e.g. lower landing gear) he wants it to be done now, 10 seconds from now can be hazardous. Patient monitoring system For example a machine that monitors the heart rate. It might be enough to know the heart rate within a second and not within a millisecond. Multimedia presentation system This system can be considered a real time system. But, it doesn’t really matter if all the deadlines are met on time as long as most of the time the deadlines are met. Some systems have both hard and soft deadlines.
  • 8. Soft vs. Hard Real-Time Systems Property Non Real Time Soft Real Time Hard Real Time Deterministic No Possibly Yes Predictable No Possibly Yes Consequences of late computation No effect Degraded performance Mission failure Mission-critical reliability No Yes Yes
  • 9.
    • Characteristics of Real-Time Systems
    • Real-time systems tend to be:
    • Embedded system : a component of a larger hardware/software system.
    • (Many people use the term embedded systems means real-time systems).
    • Concurrent system : the system simultaneously controls and/or reacts to different aspects of the environment, many events that need to be processed in parallel.
    • Safety critical system : not only reliable but also safe, if it fails then without causing injury or loss of life. The development of safe system involves architectural redundancy.
    • Reactive system : there is a continuous interaction with the environment, event-driven and must respond to external stimuli, system response is typically state dependent. Behavior of event-driven system primarly caused by reactions to external events.
  • 10.
    • Properties of Real-Time Systems
    • Control and monitor physical processes in a timely fashion.
    • Perform reliably for long periods.
    • Perform without direct human intervention.
    • Operate under more severe constraints than “normal” software systems. Some constraints are inherent in their problem domain. Some constraints come from the need to reduce recurring cost.
    • Must operate with a minimum memory footprint and with minimum of support hardware.
    • Harder to develop.
    • Do not use mass storage devices.
    • Do not provide conventional computer display or keyboard.
  • 11. Technical Complexity vs. Management Complexity
  • 12. Examples of Real-Time Systems Microwave ovens, Medical monitoring systems, Car control systems: ABS systems and engine control, Air craft systems, Chemical factory control system, Networks of dozens of computers collaborating to control entire factories, Nuclear power plant control systems.
  • 13.
    • Terms
    • A time driven system are primarily driven by periodic tasks rather than by the arrival of aperiodic events. The periodic tasks can be either a passage of some time or arrival of a deadline.
    • A task or a thread is an encapsulated sequence of actions that executes independently and in parallel with other tasks. Actions are sequentially executing statements that execute at the same priority or perform cohesive( מלכדת ) function.
    • Sometimes there is a distinction between heavyweight threads that are called processes and regular lightweight threads.
    • In a multitasking system the tasks are scheduled to run via scheduling policy .
    • Real Time Operating System(RTOS) is a software that is responsible, among other activities, to implement the scheduling policy. Not all real-time systems have RTOS. A task priority is used by RTOS to control when it runs in relation to other tasks.
  • 14.
    • Timeliness( דייקנות )
    • The timeliness of an action is how the action meets time constraints. The basic concept is that actions must begin in response to event or due time and must complete within a certain time after they begin. Usually, timeliness requirement is specified by determining the end to end performance requirement of an event response action sequence.
    • Example 1 (Response to event): The light switching algorithm will start after a user has pressed one of the traffic light button.
    • Example 2 (Due-time arrival): Every 100ms, the system will read the electromagnetic sensor data and will update traffic status.
    • Example 3 (Completion of an action): The camera will be positioned on the loaded traffic route within 3 sec from receiving an external command.
  • 15.
    • Timeliness( דייקנות )
    • Telebot example – book p. 62-65.
  • 16.
    • Responsiveness
    • Standard systems response primarily to the user, while real-time systems may interact with users, but primarily response to external sensors/actuators/devices. External events are often not predictable and the real-time system must react on time, this is called the responsiveness .
    • The real world is not linear and often its elements are dependent. A small perturbation in the input can cause a major change in the output. Our conceptual and computer models often make assumptions of linearity and independence, and things go wrong when these assumptions are violated. This is the main difficulty.
    • Examples: Flight control computers command engine thrust and wing and tail flap orientation to meet flight parameters. Chemical-process-control systems when, what kind, and the amounts of different reagents added to mixing vats. Pacemakers make the heart beat at appropriate intervals by means of electrical leads attached to the inside walls of the heart.
  • 17.
    • Concurrency
    • Concurrency is the simultaneous execution of multiple sequential chains of actions. The actions may execute on one processor(pseudoconcurrency) or multiple processors(true concurrency).
    • Execution of concurrent systems deals with:
    • Scheduling characteristics of the concurrent threads
    • Arrival patterns of incoming events
    • Rendezvous( נק ' מפגש ) patterns used when threads must synchronize
    • Methods of controlling access to shared resources
  • 18.
    • Concurrency – cont.
    • Why do we need threads/tasks?
    • The motivations to use tasks is to separate the timing of their execution from other tasks.
    • Tasks are fundamentally asynchronous.
    • Processing within each task is synchronous.
    • As long as tasks are not required to share data or control information, task synchronization is not required.
    • RTOS provides asynchronous mechanisms for task communication such as: messages, queues, events.
  • 19.
    • Scheduling Concurrent Threads
    • Many strategies of concurrency control:
    • FIFO run to completion event handling
    • Nonpreemptive task switching.
    • Time slicing round robin.
    • Cyclic execution.
    • Priority based preemption.
  • 20. Scheduling Concurrent Threads – cont. FIFO run to completion event handling Simple systems can use the run to completion policy to handle incoming events. The events are usually handled in First-In-First-Out (FIFO) policy and can be implemented by a set of independent interrupt handlers without RTOS. Does not work for large and complex systems. Nonpreemptive task switching The task switching relies on voluntarily release of the CPU by the application threads to the OS scheduling thread. When the OS scheduling thread receives control over the CPU, it selects the next thread upon a certain policy (priority, fairness). Time slicing Round-Robin The OS scheduling thread preempts application thread when they exceed their allotted time and suspends them. Then OS scheduling thread gives CPU to the highest priority waiting task . This type of preemptive scheduling is not sensitive to changing demands.
  • 21. Scheduling Concurrent Threads – cont. Cyclic execution Based on run-to-completion and has a set of statically ordered threads. The OS scheduler gives CPU to the first thread in the list, after its completion to the second and so on. The advantage of this method is that it is very simple to implement and test. Therefore, it is commonly used in complex safe critical systems, as air-flight control and NASA space vehicle control. The disadvantage of this method is that every time the applications are modified, the cyclic executive requires modification. Cyclic executive are not efficient in their overall usage of available CPU and does not provide optimal response time to external event. Priority based preemption Priority based preemptive schedulers suspend the currently executing task when a task of higher priority becomes ready to run. When two tasks share a resource, then a lower-priority task owning a required resource can block a higher-priority task from running. This is called priority inversion , because the highest-priority task can’t run. It will wait on an event upon the resource is freed. Most RTOS use this method.
  • 22.
    • Event Arrival Patterns
    • Arrival patterns may be periodic or aperiodic .
    • A periodic arrival pattern means that the thread is reinitiated on a fixed period plus or minus a small variation( jitter ). Such threads are called periodic tasks .
    • Aperiodic tasks don’t occur with a regular period but randomly. The timing of aperiodic events may be:
    • Irregular – known, but varying number of intervals between events.
    • Bursty – event can occur close to each other, but the number of events within a burst is bounded.
    • Bounded – a known minimal interval between events.
    • Bounded average rate – individual event times are unpredictable, but they cluster around a mean.
    • Unbounded – arrival intervals between events can be predicted only statistically
    • Different timing characteristics needs different mechanisms. Therefore, it should be analyzed carefully in reliable systems. Often bursty or bounded characterized only in minimal interval between events. For unbounded , the queuing theory often used to determine reasonable buffer sizes.
  • 23.
    • Thread Rendezvous Patterns
    • Concurrent threads need to communicate and synchronize.
    • Communication is done via messages.
    • Messaging includes a variety of rendezvous patterns:
    • Synchronous function calls : objects directly call methods of other objects, operating within the same thread of control.
    • Asynchronous function calls : supported by queuing a message from another thread and working on it when convenient. The caller continues without waiting.
    • A waiting rendezvous : the calling task waits indefinitely for the called task to become ready.
    • A timed rendezvous : the caller waits for a specified time before aborting the synchronization attempt.
    • A balking rendezvous : if the called task is not immediately available, the caller aborts the attempt and takes other actions.
    • It is important to characterize the rendezvous patterns of cross-thread messaging to meet the deadlines.
  • 24.
    • Sharing Resources
    • Tasks have problems with sharing resources.
    • The solution is serialization of access through mutual exclusion semaphores or queue.
    • Non atomic access to a data can cause data corruption.
    • We need to ensure that only one task at a time can access the value.
    • Example : floating-point operation takes a few atomic operations in almost every system. Two task may attempt to perform a floating point operating on the same data concurrently. The first tasks makes only one atomic operation, when the second tasks makes an atomic operation.
  • 25.
    • Sharing Resources - cont
    • There are few mechanisms to achieve mutual exclusion:
    • Asynchronous Access : the simple solution, every executing task has a message queue. If the extra-thread access to the resource is via message queue only, then the mutual exclusion is assured. The disadvantage is the heavyweight abstraction.
    • Critical Sections : allow direct assess to the resource, but make it atomic access by disabling interrupts and task switching before the access and enable after, the disabled section is called a critical. This solutions has several drawbacks:
    • The solution is on developer guarantee
    • Some interrupts and events may be lost during critical section.
    • We need to get interrupt state before disabling it, in order to restore it after the critical section. It is not always possible
    • High priority tasks are blocked since task switching is disabled.
  • 26. Sharing Resources - cont Semaphores : the common solution, it is a “lock” that serializes access to a resource. The mutual exclusion semaphore has 2 operations: take() – in order to get access to a resource, returns only when the resource is available, otherwise it waits. Once the resource is available, it locks the resource and returns. give() – in order to give up the access on a resource, releases the lock and gives up the ownership.
  • 27.
    • Predictability
    • The predictability of a system is the extent( מידה ) to which its response characteristics can be known in advance.
    • Predictability is crucial for safety-critical and high-reliability systems.
    • Several methods exist to determine predictability by analysis:
    • Static mathematical analysis, such as rate monotonic analysis(RMA),
    • Use simple control algorithm, for example disallow preemption,
    • Active objects that represent tasks and identify the performance characteristics of the tasks allow to use a variety of algorithms.
    • There are 2 aspects of predictability: schedulability and memory.
  • 28.
    • Predictability –cont.
    • Memory predictability is memory usage ( אופן השימוש ) and memory persistence ( משך השימוש ).
    • Memory persistent:
    • Non-writable persistent
    • Writable persistent
    • Volatile
    • Memory usage:
    • Execution memory, where executable code resides.
    • Data memory: stack, heap, static.
  • 29.
    • Memory Predictability –cont.
    • Static – allocate all memory at boot-up. Not applicable to large systems.
    • Stack – the simplest, verify that the stack is big enough to hold all the automatic variables and return addresses in all cases.
    • Heap – request a memory block from operating systems (ex. malloc). Most heap managers do not have constant or bounded time to allocate, since they traverse the free store. Not predictable and some deadlines may be missed.
    • Memory fragmentation even makes it worse.
    • Common solution - fixed size block allocation heaps.
    • Every mix has its properties:
    • Stack-writable persistent memory
    • Heap-volatile
    • Stack-nonwritable persistent
  • 30.
    • Correctness and Robustness
    • A system is correct when it does the right thing all the time. A correctness of the system depends not only on the logical results of the computation, but also on the time at which the results are produced.
    • A system is robust when it does the right thing not just in regular circumstances, but under unplanned circumstances, even in the presence of unplanned failures.
    • A robust system must:
    • -identify the fault
    • -take an action like:
    • correct the failure and continue processing
    • repeat the previous computation to restore the correct system state
    • enter a fail-safe condition
  • 31.
    • Correctness and Robustness – cont.
    • Exceptional Conditions:
    • One way to achieve robustness is to use exception handling to improve system correctness.
    • This requires active means to identify faults.
    • This means that computational preconditional invariants must be explicitly verified during execution.
    • If these are satisfied, normal processing continues.
    • If the invariant condition tests fail, then an action is taken.
    • In a robust system these invariants are checked whenever they are relied upon.
  • 32.
    • Correctness and Robustness – cont.
    • Exceptional Conditions - Example:
    • A satellite system is subject to a high level of ionizing radiation that frequently modify values of bits in memory. If a correct value was written to memory it does not mean that the value remains correct.
    • One can use the following class that verifies its values with redundant 1’s complement storage:
    • Class LaserPosition{
    • long x, y, z, notX, notY, notZ;
    • public:
    • void set(a,b,c){
    • x=a;notX=~a;
    • y=b;notY=~b;
    • z=c;notZ=~c; };
    • long getX(void){
    • if(x==~notX) return x;
    • else throw(“Corrupted X”); };
    • };
  • 33.
    • Correctness and Robustness – cont.
    • Deadlock: a task waits indefinitely for conditions that can never be satisfied. There are 4 conditions for deadlock:
    • Tasks claim exclusive control over shared resources.
    • Tasks hold resources while waiting for other resources to be released.
    • Tasks cannot be forced to give up resources.
    • A circular waiting condition exists.
    • Picture from book
  • 34. Correctness and Robustness – cont. Solution to deadlock conditions: Conditions 2 and 4 are the easiest to negate. Condition 2: no shared resource may be locked while another shared resource is requested. Condition 4: block all the other tasks from continuing every time a tasks claims a shared resource or use a time mutex as follows: if (semTake(mySem, 1000)==OK) { //do stuff } else throw (“Resource unavailable”);
  • 35. Correctness and Robustness – cont. Race Conditions: Occur when the state of a resource depends on timing factors that are predictable. When two or more threads access a shared resource with at least one modification to that resource, but the relative sequence of their actions to the resources is not predictable. Example: Class semaphore{ int isLocked; public: semaphore(void): isLocked(0){}; void semTake(){ while (isLocked) taskDelay(100);//let the other tasks run isLocked=1; }; void semGive(){ isLocked=0; };(Picture from the book-p80)?
  • 36. Correctness and Robustness – cont. Avoid race conditions: Class semaphore{ int isLocked; public: semaphore(void): isLocked(0){}; void semTake(){ enterCriticalSection(); while (isLocked) exitCriticalSection(); taskDelay(100);//let the other tasks run enterCriticalSection(); isLocked=1; exitCriticalSection(); }; void semGive(){ enterCriticalSection(); isLocked=0; exitCriticalSection(); };
  • 37.
    • Correctness and Robustness – cont.
    • To avoid race conditions:
    • No two tasks may be in their respective critical sections at the same time.
    • No assumptions are made about relative speed of different tasks.
    • No task outside one of its critical sections should block another task from continuing.
    • No task should have an unbounded wait to enter its critical section.
    • Mutex semaphores are the solution. Surround critical section with lock and unlock of mutex associated with that resource.
  • 38.
    • Distributed Systems
    • Large real-time systems may be distributed across many processors.
    • Sometimes in the same computer and sometimes across disparate physical locations.
    • These systems must relate more issues, such as:
    • Coordination and synchronization of tasks on different processors
    • Bootup process
    • Cross processor communication
    • Time base synchronization
    • Construct such systems using large-scale architectural abstractions, such as components and subsystems, as a mean to decompose the system and control it.
  • 39.
    • Fault Tolerance and Safety
    • Often real-time systems have high availability requirements.
    • Not only reliable but also safe, if it fails then it causes injury or loss of life. The system should not fail!
    • The development of safe system involves architectural redundancy.
    • Architectural design patterns are used to capture and represent the redundancy.
  • 40.
    • Low-Level Hardware Interfacing
    • One of the major difficulties is managing interfaces to the low level drivers.
    • The hardware components and devices often requires custom drivers.
    • These drivers need to interface the RTOS.
    • Sometimes the efficiency of the device handlers is crucial to the performance of the system.
  • 41.
    • Target Environment and Host Environment
    • Dealing with resource limited environment
    • Usually the embedded system is developed using tools hosted on host computer .
    • The executable application is targeted to a different target computer . Developer needs to use cross compiler tools, simulation, and other special development tools.
    • Sometimes the target environment has no sophisticated debugging tools .
    • The host environment is sometimes not capable of handling all target facilities.
    • Sometimes the target computer is composed of special hardware which is not present in the host computer( like timers,sensors) and it must be simulated.
  • 42.
    • Target Environment and Host Environment
    • Sometimes the target environment does not have a display on which to view errors or diagnostic messages.
    • Sometimes the target computer uses different Operating System than the host computer.
    • Usually the target computer is produced first in a limited quantity, and is used both for hardware and software development.
    • This concurrent development adds the difficulty of integration with hardware and hardware problems.
    • The differences between the development and target environment adds time, effort and risk to the development activities.
    • Often, the developer must design and write software for hardware that yet does not exists.
  • 43.
    • Costs
    • Dealing with resource limited environment
    • Many embedded products are cost sensitive.
    • Marketing and sales concerns push for smaller processors and less memory to lower the manufacturing costs.
    • The per shipped item is called Recurring Cost(RE).
    • The developmental (fixed) cost is called Non Recurring Cost(NRE).
    • Reducing the hardware facilities may reduce recurring cost.
    • This reduction influences and usually increases cost and effort of the development activities.
  • 44. Costs Dealing with resource limited environment
  • 45.  
  • 46.
    • The Mars Climate Orbiter (MCO) was launched on December 11, 1998 and spent 9 month traveling toward Mars.
    • It’s purpose was to orbit Mars as the first interplanetary weather satellite.
    • It was also to provide communication relay for the Mars Polar Lander (MPL) which was scheduled to reach Mars three month later, in December of 1999.
    • On September 23, 1999 the Mars Orbiter stopped communicating with NASA and it presumed to have either been destroyed in the atmosphere by entering orbit too sharply or to have passed by Mars by entering orbit too Shallowly .
    • The root cause for this failure to approach orbit at the right angle was discovered to be an inconsistency in the unit of measure used by two modules created by two separate groups .
    • Thruster performance data was computed in English units and fed into the module that computed small forces, but which expected data to be in metric units .
    • The system accumulated errors over the nine month journey and the Orbiter approached Mars at an incorrect orientation.
  • 47.  
  • 48.  
  • 49.
    • One month after the Mars Orbiter was launched, on January 3,1999, NASA launched three spacecraft using a single launch vehicle: the Mars Polar Lander (MPL) and two Deep Space 2(DS2) probes.
    • The Mars Lander was to land on the surface of the planet and perform experiments for 90 days.The DP2 were to be released above the planet surface and drop through the atmosphere, embedding themselves beneath the surface.
    • According to plan, these three spacecraft ended communications as they prepared to enter the atmosphere of Mars on December 3, 1999. After arriving on the planet they were to resume communication on the evening of December 4, 1999.
    • Communication was never reestablished. After a thorough investigation, the most probable cause seems to be the generation of spurious signal when the Lander’s lags were deployed during descent. This signal could give the Lander a false indication that it had landed, causing the engines to shut down. This would lead to a crash into the surface.
    • The report claims that there was no software requirement to clear spurious signals prior to using the sensor information.
    • During the test of the lander system, the sensors were incorrectly wired due to a design error. As a result the spurious signals were not identified by the systems test and the systems test was not repeated with properly wired touchdown sensors. While the most probable direct cause of the failure is premature engine shutdown, the underlying cause is inadequate software design and system test.