Embedded and Real Time Systems Lecture #2 David Andrews

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

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

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

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

Typical Real- Time Embedded Characteristics See table 1.2 for summary

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

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 …%) 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

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

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