Introduction to Realtime Systems

1. Introduction to Realtime Systems Chapter 1 R. Williams’ text B. Ramamurthy

2. Overview • Realtime processing requires both parallel activities and quick response (See figure in p.2 of a juggler) • Design for complexity management. (See figure in p.3) • See examples like parking meter • Microprocessors and realtime applications • Definition of realtime systems • Programming structures • Response latency • Relative speeds • Timing issues • Debugging real-time systems • Input/output handling • Deadlines (hard, firm and soft) • Software quality assurance

3. Design for complexity management • Choices: • Structured analysis/structured design (SA/SD) • Concurrent design approach for real-time systems (CODARTS) • Finite state machines (FSM) • Object-oriented design (OOD)

4. Microprocessor • Examples: vending machines, mobiles phones, alarm systems, washing machines, motor car engine controllers, heart monitors, microwave ovens all operate using embedded microcontrollers running dedicated software. • Microprocessors are the enabling hardware for realtime systems.

5. Lets define realtime (RT) systems • Timing: RT systems (RTS) are required to compute and deliver correct results within a specified period of time. Ex: traffic light controller • Interrupt driven: event-driven preemption; RTS are often involved with handling events. • Events manifest themselves in terms of interrupt signals arising from the arrival data at an input port or ticking of a hardware clock, or an error status alarm.

6. RTS Definition (contd.) • Low-level programming: RTS often deal with devices; C language is still a favorite for writing device drivers for new hardware. • Specialized hardware: Most RTS work within, or at least close beside, specialized electronic and mechanical devices. Often closed loop systems. (See fig on p.6) • Volatile data IO: Variables that change their value from moment to moment. RTS software must be structured to check for changes at the correct rate, so as not to miss a data update.

7. RTS Definition (contd.) • Multi-tasking: RTS are often multitasking. Several processes cooperate to carry out the overall job. Divide RTS problem into tasks as a design strategy. • Run-time scheduling: Separation of activities into tasks leads to question of task sequencing or scheduling. Moreover the external events and required response to these lead to run-time scheduling or dynamic scheduling. • Unpredictability in inputs/stimulus: Being event-driven, RTS are at the mercy of unpredictable changes in their environment. • Predictability response requirement! • Life-critical code: failure to run correctly may result in death or at least injury to the user and/or others. Life-critical systems requires extra testing, documentation and acceptance trials.

8. Programming Structures • Also known as control structures • Sequence (SEQ) • Iteration (IT) • Branches guarded by selection statements (SEL) • Parallel or concurrent instructions (PAR) • Critical group of exclusive instructions (CRIT)

9. Relative Speeds • Polling is a common method used in RTS for sensing events/inputs. • When designing RTS • Avoid polling input too slowly, you may miss events • Avoid sampling to frequently (called aliasing), since it will make the process inefficient. • Nyquist limit: The maximum frequency threshold is half the sampling rate referred to as Nyquist limit.

10. V2F: Voltage to Frequency • A commonly used environmental monitoring arrangement involves a transducer being interfaced to a voltage-frequency converter. • V2F unit converts voltage to frequency: larger voltage, higher frequency; lower voltage, lower frequency. • Computer has to dedicate a single bit input port to accept the information in serial mode. • Problem: converting this bit information into integer. • Timing of the two branches in the following sequences are not balanced; run these two alternating.

11. loop for 100 msec { if (input_bit) hcount++; else lcount++; } loop for 100 msec { if (!input_bit) lcount++; else hcount++; } Software Timing

12. High Speed Timing • Consider a laser range finder used in civil surveying, and battle field targeting. • Distance is calculated by the timing the duration of flight. • The Speed of light: s= 3 X 108 m/sec • Target is 20km away, the pulse of light will travel 40km (to and from): d = 4 X 104 m • Time taken: d/s = 4 X 104 / 3 X 108 = 130μs • If the item surveys is only at 50m distance, the flight time will be reduced to 325ns. • Regular 500MHz computer will not do for this. • Solution: Clear a high speed counter when the pulse leaves and capture the counter value on return of the pulse.

13. Output timing • Timing problems when controlling output devices such as motors. • Cyclic, periodic output data. • Several types of motors: stepper, DC servo, universal AC, induction AC, synchronous AC etc. • For example sometimes we need to dispatch every 20ms with an accuracy of 50μs. • Solution: need special hardware support: controller boards.

14. Machine IO • Programmed IO • Interrupt driven • Direct memory access

15. Types of RTS • Hard RTS: tight limits on response time, so that a delayed result is a wrong result. • Ex: jet fuel controller and camera shutter unit • Soft RTS: need to meet only time-average performance target. As long as most results are available before deadline the system will run successfully. • Ex: audio and video transmission, single frame skip is fie, but repeated loss is unacceptable • Firm RTS: somewhere between the two. • Ex: Space station solar panel unit

16. Software Quality Assurance • QA is especially important to RTS since many of these are deployed in life critical environments / situations. • Patriot missile failure

17. Summary • We studied key issues which make development of realtime software more challenging than desktop or traditional data processing applications. • Timing is very critical for RTS input, output, computing and response. • See the timing units of measurement on page 26. • Read the reference papers given at the end of the chapter.