2. Embedded and Real Time Systems Lecture #2 David Andrews dandrews@eecs.ukans.edu

3. What We Will Cover Today Fundamental Concepts and Definitions –Functional and Temporal Requirements –What Is A Distributed System Things That Matter Most In Embedded Systems –A Look At Tradeoffs –Examples Where We Are Going Next –Example System –Modeling/Requirements/System Architecture

4. Temporal Requirements Temporal requirements from 1.controlled object 2.controlling computer system… Controlled Object (From Control Theory) –delays associated with the time the system requires to Response delay to initiated change d object Achieve desired change d rise –Other Variations/Types Depending On Actual System Controlling Computer –Delays associated with Sampling Times d sample Calculation Times: computer delay d computer Variance in Calculation Times (Jitter)  d computer

5. Computer Controller Delays

6. Controlled Object Much information borrowed from control theory…. Exact information based on system under consideration. Flight controller that will adjust Azimuth and Elevation

7. System Timings  h is given to actuators for adjustment

8. Control Loop Parameters (Summary from Book) SymbolParameterSphere of ControlRelationships d object Controlled object delay Controlled objectPhysical process d rise Rise time of step response Controlled objectPhysical process d sample Sampling periodComputerd sample << d rise d computer Computer delayComputerd computer << d sample  d computer Jitter of delayComputer  d computer <<d computer d deadtime Dead timeComputer and controlled object d computer + d object

9. Example Simple Control System In example: Object = metal pot + water + rice Control system is temperature sensor + heating elements sensor CPU Heater Coil Rice + Water

10. Element Definitions d object controlled object delay Delay from applying control force to first observed response Due to inertial lag of physical plant (speed of thermal wavefront in rice cooker) d rise rise time of step response Physical time constant of system (thermal mass of rice+ water+ pot+ heaters) d sample sampling period How often temperature sensor is read ( should be > 10x rise time) d computer computer delay Time to compute new actuator command point (sensor iÿ heater on or off)  d computer jitter of computer delay Variations in computer delay ( e. g., cache misses, competing tasks) d deadtime dead time End- to- end latency from observation to action (lower = more stable)

11. Example Values For Rice Cooker d object = 90 seconds Time from electricity to coil to temperature change at sensor Varies depending on coil size (amps) and metal d rise = 10 minutes Time to boil water; varies with amount of water d sample = 10 seconds to 1 minute sampling frequency No point sampling temperature at 10 MHz ! d computer = 10- 100 msec compute time Hard to buy a computer slower than that  d computer =.1 - 1 msec jitter Conditional branches in software A/ D timeout loops, early- out multiplication, etc. d deadtime = 90 sec + 10 msec ~= 90 sec Computer isn’t a limitation in this case

12. General Control System Issues Latency is bad; it can create unstable systems If control loop is 180 degrees off from an oscillation, it will amplify problems Variability in latency reduces control effectiveness Communication network can be a large part of this latency And, you’re usually stuck with a given latency in the physical system Make sure control loops run faster than plant time constants Generally 10x faster gives smooth control and a safety margin Generally, want to set control loop deadlines faster than control loop frequency (each answer computed before next reading is taken)

13. Centralized vs. Distributed Systems Centralized vs. Dispersed vs. Distributed Determined by granularity and distribution of computers Centralized One computer, single set of I/ O channels “Old- style” embedded systems before cheap microcontrollers Common in jet aircraft engines OOoOOo actuator sensor CPUCPU

14. Dispersed Clustered compute+ I/ O modules “Several” computers (often 3- 10) Each computer has fixed I/ O capability, with a “few” channels Common practice in vehicles (engine, transmission, dashboard, …) Car Parts S A A A SS S SS S SS A A A A A A Engine CPU Trans CPU Ejector Seat CPU Network

15. Distributed Individual compute+ I/ O modules “Many” computers (dozens or hundreds) One (or a “few”) I/ O channels per computer – Controls a single physical item – “Smart” sensor/ actuator -- I/ O- centric instead of compute- centric Only now becoming widely used (especially building automation) cc Car Parts s a cc s a cc s a cc s a cc s a cc s a Network

16. What Is “Real Time”? Real time is not just “real fast” Real time means that correctness of result depends on both functional correctness and time that the result is delivered Soft real time Utility degrades with distance from deadline Hard real time System fails if deadline window is missed Firm real time Result has no utility outside deadline window, but system can withstand a few missed results

17. Typical Real- Time Embedded Characteristics See table 1.2 for summary

18. Fail Safe vs. Fail Operational Fail safe systems -- when in doubt, turn off Radiation therapy machines Car engines Power tools Nuclear power plant SCRAM system In general, things with a readily attainable safe condition Fail operational systems -- when in doubt, keep working Aircraft engines Military combat systems Difference is not always clear- cut Should an elevator move or not move with an open door in a fire? Pacemaker with a possibly faulty sensor Outcome generally decided by lawyers and liability insurance underwriters

19. Guarantees vs. Best Effort Guarantee – 100% certain Generally corresponds to hard/ firm real time systems ( e. g., spark plug timing) Can be wasteful; must reserve capacity for worst case Generally ignores possibility of equipment failure (so it’s only 99.999…%) Best effort – 0% certain Used in soft real time systems Can be more efficient, but breaks in the worst case Hybrid systems (research area) Provide guaranteed response as a fall- back strategy in the worst case Provide best effort in the average case

20. Event- Triggered vs. Time- Triggered Event- triggered Computation/ communication responds to an event Events happen whenever they want to happen Think “interrupt- driven I/ O” Efficient -- only do things when they need doing High peak load -- what if all possible events happen simultaneously? Time- triggered Computation/ communication responds to a system clock time Events happen according to a schedule (fixed or changeable) Think “I/ O polling” Inefficient -- do things periodically whether they need it or not Easily characterized load -- a spreadsheet can schedule the whole system

21. Review System includes many pieces, including the user Key issues are observability & controllability Latency is critical for stable control loops Degree of centralization is a tradeoff Trend is to decentralize as silicon becomes cheaper Real- time systems are more than simply “real fast” Typical tradeoffs with safety, guarantees, resource constraints, triggering Time-“ triggered” really means “periodic”; event- triggered means asynchronous Embedded computers are spreading everywhere Next lecture: Flight Controller Architecture