【正文】
l timing constraints are satisfied under any circumstance, BEFORE runtime ? How to do this? – How about using a very fast processor? – How about executing it and measuring the time? (Testing) 11 The story about a sheep in Scotland… 12 The story about the Pathfinder on Mars … What do we learn? ? Testing is inadequate 13 r e a lw o r s t c a s e b e h a v i o rg u a r a n t e e db o u n dt y p i c a l b e h a v i o re x e c u t i o n t i m ed i s t r i b u t i o nc o v e r e d b y t e s t i n go b s e r v e dw o r s t c a s e b e h a v i o rWhat do we learn? ? Testing is inadequate, especially for realtime embedded systems – Need to simulate the stimulus and feedback from the physical world 14 Even the NASA Lab fails, then how about your project? What do we learn? ? Difficult to fix the error, even if it is exposed in testing – Difficult to reproduce – Difficult to explain 15 Timing Analysis ? How to rigorously verify the timing correctness? – An extremely difficult problem … 16 RealTime Computing Technology ? Some leading countries – USA – Germany – Sweden – France – Italy – … … 17 Research in RealTime Systems ? Conferences – RTSS: IEEE RealTime Systems Symposium – RTAS: IEEE RealTime and Technology and Applications Symposium – ECRTS: Euromicro Conference on Realtime Systems ? Journal: – Journal of RealTime Systems 18 ? More details about RealTime Systems in the following 19 Hard vs Soft RealTime Systems ? Definition based on functional criticality – HARD: The failure to meet the timing constraints has disastrous consequences ? Braking system, collision detection, etc. – SOFT: A few misses of deadlines do no serious harm, and only the systems’ overall performance degrades ? Video playback, etc. – Problem: how serious is serious? A design property Hard vs Soft RealTime Systems ? Definition based on validation – Validation: A demonstration by a provably correct, efficient procedure or by exhaustive simulation and testing – HARD: The user require the validation that the system always meets the timing constraints – SOFT: No validation is required, or only a demonstration that the job meet some statistical constraint suffices Desirable Properties of RT Systems (1) ? Predictability – the system behavior is known before it is put into operation – . Response times, deadlock freedom, etc. ? Analyzability – easy to analyze if the system can meet all the deadlines ? Cost optimality – . Energy consumption, memory blocks, etc. Desirable Properties of RT Systems (2) ? Maintainability – modular structure to ease system modification ? Robustness – must not collapse when subject to peak load, exception, manage all possible scenarios ? Fault tolerance – hardware and software failures should not cause the system to crash Why Achieving Predictability is Hard? ? Challenges from hardware features – Cache sharing, processor pipelines, multicores, DMA ... – Interrupt handling may introduce unbounded delays – Resource sharing: priority inversion – Memory management (static allocation may not be enough, dynamic data structures . Queue), no virtual memory – Communication delays in a distributed environment Why Achieving Predictability is Hard? ? Challenges from software features – Difficult to calculate the worst case execution time for tasks (theoretically impossible, halting problem) – Bounded loops . Forloops only – Complex synchronization patterns between tasks: potential deadlocks (formal verification) – Multitasking, tasks that share resources Misconceptions about RT Computing ? Realtime puting is fast puting ? Realtime system research is performance engineering ? Realtime is time sharing Overall Structure of a RT System ? Hardware (CPU, I/O device etc) – a clock! ? A real time OS (function as standard OS, with predictable behavior and welldefined functionality) ? A collection of RT tasks/process