1 / 52

Real-Time Systems: Introduction, Scheduling, Analysis, and Verification

This lecture provides an overview of real-time systems, including scheduling algorithms, schedulability analysis, formal analysis, and verification. It covers concepts such as time, clocks synchronization, and the characteristics of real-time systems.

georgiat
Download Presentation

Real-Time Systems: Introduction, Scheduling, Analysis, and Verification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Real-Time Systems, COSC-4301-01, Lecture 1 Stefan Andrei COSC-4301-01, Lecture 1

  2. Real-time systems • COSC-5340-01 is a 3 credit points module • Assignments: 20% • Research paper presentation: 30% • Written final exam: 50% (open book) • Module homepage: http://galaxy.lamar.edu/~sandrei/cosc-4301-01 • COSC-4301-01 is a 3 credit points module • Assignments: 40% • Written final exam: 60% (open book) COSC-4301-01, Lecture 1

  3. Course etiquette • Code of conduct • no copying • for details, see webpage • You are encouraged to attend to all lectures, tutorials, and so on. • You are encouraged to ask questions. • You are encouraged to offer answers. COSC-4301-01, Lecture 1

  4. The team • Associate Professor: • Dr. Stefan Andrei, sandrei@cs.lamar.edu • Office hours: • 8:30am-9:30am and 11:30am-12:30pm • please send an email to make an appointment • Lectures based of the book: • Albert M.K. Cheng: Real-time systems. Scheduling, Analysis, and Verification, Wiley-Interscience, 2002 (first printing), 2005 (second printing), ISBN: 0-471-18406-3 • Recommended books: • John A. Stankovic, Marco Spuri, Krithi Ramamritham, Giorgio Buttazzo: Deadline Scheduling for Real-Time Systems: EDF and Related Algorithms, Springer Verlag, 1998 • Herman Kopetz: Real-Time Systems. Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, 1997 COSC-4301-01, Lecture 1

  5. Pre-requisites: • It is recommended to be already familiar with: • Symbolic logic; • Automata and languages. • What is this course all about? • Real-time scheduling algorithms and schedulability analysis. • Formal analysis and verification of real-time systems. COSC-4301-01, Lecture 1

  6. Overview of this course • Introduction in Real-Time Systems • Real-time scheduling and schedulability analysis • Real-time logic, graph-theoretic analysis, and MODECHART • Model checking of finite-state systems • Visual formalism, statecharts, and STATEMATE COSC-4301-01, Lecture 1

  7. Lecture structure • Reminder of last lecture • Overview • Content (new notions + examples) • Summary • Reading suggestions • Coming up next COSC-4301-01, Lecture 1

  8. Overview of this lecture • Introduction in Real-Time Systems • What is time? • What is a real-time system? • Simulation • Testing • Verification • Run-time monitoring COSC-4301-01, Lecture 1

  9. What is time? • Time is an essential concept in real-time systems. • Keeping time using accurate clocks is required to ensure correct operations. • Master source: Paris’s International Atomic Time (TAI - Temps Atomique International) is an average of several laboratory atomic clocks in the world. COSC-4301-01, Lecture 1

  10. What is time? • The earth’s rotational rate slows by a few miliseconds each day. • Universal Coordinated Time (UTC) is another master time source that performs leap corrections to the time provided by TAI, making the time length of every natural solar day constant. COSC-4301-01, Lecture 1

  11. Clocks synchronization • UTC time signals are sent from National Institute of Standards and Technology (NIST) radio station, in Fort Collins, Colorado, and other UTC radio stations to specialized receivers. • Selected radios, receiver-clocks, some phone-answering machines, etc, have the ability to receive these UTC signals to maintain accurate clocks. • Depending on the location of the receiver, the clocks synchronization should take into account the delay in receiving the UTC signal. COSC-4301-01, Lecture 1

  12. Wall clock or absolute time • For computers whose time is kept by quartz-based computer clocks, the clocks should be periodically synchronized such that they maintain a bounded drift relative to UTC. • In this course, when we want refer to wall clock or absolute time, we refer to the standard time provided by a bounded-drift computer clock on UTC. • So, there is a mapping clock: RealTime  StandardClockTime COSC-4301-01, Lecture 1

  13. What is a real-time system? • A system that should produce the result in a certain time. • Example: Anti-lock braking controller: • “When the driver of a car applies the brake, the anti-lock braking controller analyzes the environment in which the controller is embedded (car speed, road surface, direction of travel) and activates the brake with the appropriate frequency within fractions of a second.” • Both the result (brake activation) and the time at which the result is produced are important in ensuring the safety of the car and passengers. COSC-4301-01, Lecture 1

  14. Real-time (computer) systems • Many years ago, there were only non-real-time computer systems (e.g., old cars braking controller); • Recently, computer hardware and software are embedded in real-time systems to monitor and control their operations (these systems are called real-time computer systems or embedded systems). • Examples: the computerized version of the cars braking controller, avionics, multimedia tools, etc. COSC-4301-01, Lecture 1

  15. Distinguishing embedded and real-time systems • Real-time system: meets timing constraints and respects the functional requirements. Real-time systems Embedded systems • Embedded system: part of another system. COSC-4301-01, Lecture 1

  16. Correctness of real-time systems • Satisfaction of logical/functional constraints: • The result (e.g., brake activation) should be correct. • Satisfaction of timing constraints: • The time at which the result is produced is also very important (e.g., pressing the brakes should instruct the computer system to stop the car in a certain amount of time). COSC-4301-01, Lecture 1

  17. A model of a real-time system • X: space of sensor input vectors • x(t) is the value of x at time t • Y: space of decision vectors • y(t) is the value of y at time t • S: space of state vectors • T: set of timing constraints • I: set of integrity constraints • D: decision map S  X  S  Y • D(s,x)=(s’,y) means that given s and x at time t, then D determines the next decision y and system state s’ at time t+1. • A: relation over X and Y about the effect of a control decision on the external world. A X Y D S COSC-4301-01, Lecture 1

  18. A model of a real-time system. Example • Anti-lock braking controller: • X = the vector consisting of (wheel sensors) • S = the vector consisting of (car speed, direction of travel) • Y = the vector consisting of (frequency) • A = the environmental constraint as a relation over Y and X • D = the decision map that based on the S X value, it gives a value from S Y • T = the timing constraint that requests the braking mechanism to pump the brakes at a higher frequency within 100ms. COSC-4301-01, Lecture 1

  19. Anti-lock braking controller. Comments • The frequency (decision Y) depends on S and X. • For instance, if the car is turning (direction component) and the wheel sensor detects a wet road, then the frequency is higher (system pumps the brake more times/sec to avoid skid). COSC-4301-01, Lecture 1

  20. Analysis techniques • Simulation • Testing • Verification • Run-time monitoring COSC-4301-01, Lecture 1

  21. Simulation • Means constructing a model of an existing system to be studied or a system to be built and then executing actions allowed in this model. • The model can be: • a physical entity (e.g., scale clay model) or • a computer representation. • Comparison: • A computer model is usually less costly than a physical model. • A computer model can represent a non-computer entity (e.g., airplane, component) or a computer entity (computer system, program). COSC-4301-01, Lecture 1

  22. Simulation • Both physical and computer models are called simulators of the actual systems. • A simulator can carry out simulated executions of the simulated system and can display the outcomes of these executions. • Examples: • A physical model of an airplane in a wind tunnel shows the aerodynamics of the simulated plane; • A software model can simulate the behavior of an automobile crashing into a concrete barrier, showing the effects on the occupants. COSC-4301-01, Lecture 1

  23. Simulation • Is an inexpensive way to study the behavior of the simulated system and to study different ways to implement the actual system. • If we detect behavior or events that are inconsistent with the specification and safety assertion, we can revise the model and actual system to be built. COSC-4301-01, Lecture 1

  24. Simulation. Target system • Different levels of details of the actual system (called also target system) can be modeled and its events simulated by a simulator. • Example: when designing and simulating the cockpit of an aircraft, we can restrict attention to that particular component by simulating only the cockpit with inputs and outputs to the other aircraft components, without simulating the behavior of the entire aircraft. COSC-4301-01, Lecture 1

  25. Simulation techniques • Real-time-event simulation • Discrete-event simulation • Hybrid simulation COSC-4301-01, Lecture 1

  26. Real-time-event simulation • Example: a physical scale model of an automobile performs its actions in real-time and the observable events are recorded in real-time (crash testing simulator needs instruments of recording events in real-time). • When the physical model is an implemented target, the simulation is called testing. COSC-4301-01, Lecture 1

  27. Discrete-event simulation • Uses a logical clock and is usually software-based. • The variety of systems that can be simulated by software-based is not limited by the speed at which the hardware executes the simulator since the simulated actions and events do not occur in real-time. • Rather, they can take place according to the speed of the simulator hardware and the instructions in the simulator program. • Example: simulation of a network of computers in a single-processor system. COSC-4301-01, Lecture 1

  28. Hybrid simulation • The simulator works with a partial implementation of the target system by acting as the non-implemented part. • The hybrid simulator makes it possible to predict the performance and behavior of the target system once it is completely implemented. COSC-4301-01, Lecture 1

  29. Simulation. Disadvantages • Simulation is not able to model all possible event-action sequences in the target system where the domain of possible sequences of observable events is infinite. • Even if the domain is finite, the number of possible sequence of events is so large that the most powerful computer resources or physical instruments may not be able to trace through all possible sequences of events in the simulated target system. COSC-4301-01, Lecture 1

  30. Testing • Is a technique for detecting errors or problems in implemented software, hardware, or non-computer systems. • It consists of executing or operating the system to be tested using a finite set of inputs and then checking to see if the corresponding outputs or behavior are correct with respect to the specifications. • To test a real-time system, the values as well as the timing of the inputs are important. COSC-4301-01, Lecture 1

  31. Approaches for testing • Exhaustive testing • Functional testing • Structural testing • Code reading COSC-4301-01, Lecture 1

  32. Exhaustive testing • Considering every possible input values to be checked against the expected answers is not practical for larger systems. • For systems with infinite number of possible inputs, this approach is of course not viable. COSC-4301-01, Lecture 1

  33. Functional testing • Uses a “black-box” approach in which the programmer creates test data from the program specification using one or a combination of techniques such as boundary value analysis and equivalence partitioning. • The program is executed using these test data as input, and the corresponding behavior and output are compared with those described in the program specification. • If the program behavior or output deviates from the specification, the programmer attempts to identify the erroneous part of the program and correct it. COSC-4301-01, Lecture 1

  34. Structural testing • Is a “white-box” technique in which the programmer examines the source code of the program and then creates test data for program execution based on the percentage of the program’s statements executed. COSC-4301-01, Lecture 1

  35. Code reading • Code reading by stepwise abstraction requires the programmer to identify major modules in the program, determine their functions, and compose these functions to determine a function for the whole program. • The programmer then compares this derived function with the intended function as described by the program specification. COSC-4301-01, Lecture 1

  36. Verification • Simulation and testing can reveal errors in the simulated or actual system, but usually cannot guarantee that the system satisfies a set of requirements. • To apply formal verification techniques to a real-time system, we must first specify the system requirements and then the system to be implemented using an unambiguous specification language. COSC-4301-01, Lecture 1

  37. Verification. Personnel • Applications expert: • He/she could be a programmer or a system designer; • Formal methods expert: • A formal methods expert collaborates with the applications expert to write the requirements and system specification. • Once these specifications are written, the formal methods expert can verify whether the system specification satisfies the specified requirements using his/her favorite formal verification methods and tools. COSC-4301-01, Lecture 1

  38. Specification of real-time systems • Structurally and functionally specification (how the real-time system components work as well as their functions and operations): • Mechanical components • Electrical components • Electronic components • Behavioral specification • The result of each component in response to an internal or external sequence of events. COSC-4301-01, Lecture 1

  39. Example: real-time anti-lock braking system in an automobile • Structural-functional specification refers to: • Braking system components and sensors • How they are interconnected, and • How the actions of each component affect the other • Example: how to connect the wheel sensors to the central decision-making computer that controls the brake mechanism. • Behavioral specification refers to: • Events and effects • Example: when the wheel sensors detect wet road conditions, the decision-making computer will instruct the brake mechanism to pump the brakes at a higher frequency within 100ms. COSC-4301-01, Lecture 1

  40. Timing Constraints • Behavioral specification without the complexity of the structural specification often suffices. • We restrict the specification language to handle only timing relations. COSC-4301-01, Lecture 1

  41. Specification and safety assertion • An implementation of a real-time system is built from the structural-functional specification. • An implementation is correct (faithful) if • The behavioral specification (denoted as SP) implies safety assertion (denoted as SA). • In other words, we have to check whether SP  SA is a theorem or not. COSC-4301-01, Lecture 1

  42. Verification of timing properties • In checking SP → SA, we may have the cases: • (safe) SA is a theorem derivable from SP; • (inherently unsafe) SA is unsatisfiable with respect to SP; • (safe if additional constraints are added) the negation of SA is satisfiable under certain conditions. COSC-4301-01, Lecture 1

  43. Run-time monitoring • Motivation: • Despite simulation, testing, and verification, there may be a system behavior that was not anticipated. • This unexpected behavior may be because events and actions were not modeled by the static analysis tools or may be the result of making simplified assumptions about the real-time systems. COSC-4301-01, Lecture 1

  44. Run-time monitoring (cont) • So, there is a need to monitor the execution of the real-time system and to make the appropriate adjustments in response to a monitored behavior that violates the specified safety and progress constraints. • Even if the real-time system meets the specified safety and progress constraints at run-time, monitoring may provide information that can improve the performance and reliability of the monitored system. COSC-4301-01, Lecture 1

  45. The monitoring system • The monitored real-time system is the target system and its components, such as programs, are called target programs. • The monitoring system is the system used to monitor and record the behavior of the target system. • It consists of instrumentation programs, instrumentation hardware, and other monitoring modules. • It records the behavior of interest of the target system and produces event traces. COSC-4301-01, Lecture 1

  46. Monitoring techniques • Intrusive monitoring • Non-intrusive monitoring • The availability of monitoring systems does not mean that we can relax on the task of stringent pre-run-time analysis and verification of the target system. • Rather, monitoring should serve as an additional guarantee on the safety and reliability of the safety-critical target real-time systems. COSC-4301-01, Lecture 1

  47. Intrusive monitoring • Uses the resources of the target system to record its behavior and thus may alter the actual behavior of the target system. • Examples: • (computer example) Insertion of print() statements in a target program to display the values of the program variables. • (computer example) Extra statements inserted in the programs of computing nodes to record their states and the exchanges of these state variables. • (non-computer example) Addition of speed and impact-force sensing instruments in an automobile to record its performance. COSC-4301-01, Lecture 1

  48. Non-intrusive monitoring • Does not affect the timing and ordering events of the monitored target system. • This is important in monitoring of real-time systems where both timing and ordering of events are critical to the safety of the real-time systems. • Example: use of additional processor(s) to run monitoring programs used to record the target system’s behavior in a real-time environment. COSC-4301-01, Lecture 1

  49. Summary • Introduction in Real-Time Systems • What is a real-time system? • What is time? • Simulation • Testing • Verification • Run-time monitoring COSC-4301-01, Lecture 1

  50. Reading suggestions • Chapter 1 of [Cheng; 2002] • Chapter 1 of [Kopetz; 1997] • Chapter 1 of [Stankovic, Spuri, Ramamritham, Buttazzo; 1998] COSC-4301-01, Lecture 1

More Related