Principles and Pragmatics for Embedded Systems

1. Principles and Pragmatics for Embedded Systems John Regehr University of Utah

2. 1998 2003 2008 Theme: Appropriate, checkable abstractions for systems software Composable Execution Environments Hierarchical Loadable Schedulers Secure, large-scale embedded systems?

3. Embedded Systems • Account for ~100% of new microprocessors • Consumer electronics • Vehicle control systems • Medical equipment • Smart dust

4. Embedded Software Goals • Memory • Lock • Time • Minimal • Memory use • CPU use • Power use • Safe • Efficient • Reusable • Easy to develop • Functionally correct • Composable • Late binding • Debuggable • Testable • Problem specific

5. Binding Infrastructure and metadata CEE – Composable Execution Environments Analyses Time Safety Stack Size Race Detection Lock Inference … Optimizations Thread Minimization Robust Scheduling Lock Elimination Inlining … Composed System Error

6. Why CEE? • Systems are in the real world • Hard to reach • Safety critical • Time is money • Space is money • Reuse is critical • Within a product line • Between generations of products

7. Embedded Platforms OS Type No OS GPOS Real-Time OS (RTOS) 1 B 1 KB 1 MB 1 GB RAM 4- and 8-bit 16-bit 32- and 64-bit CPU Type

8. CEE Main Ideas • Composition of restricted execution environments • Global analyses and optimizations • Late binding of requirements to implementations

9. Execution Environment • Set of • Idioms and abstractions for structuring software • Rules for sequencing actions • Rules for sharing information • Examples • Low-level: Cyclic executive, interrupts, threads, event loop • High-level: Dataflow graph, time triggered system, hierarchical state machines

10. Bad News • Environments have rules • Interacting environments have rules • Getting these right is a serious problem • Rules not usually checked

11. Good News • Diversity can be exploited • To create efficient systems • To match design problems • Constrained environments are easier to analyze, debug, and understand

12. Execution Environments • Embedded systems contain multiple execution environments • CEE exploits the benefits of multiple environments while mitigating the problems • Local analyses • Global analyses

13. Other Frameworks for Embedded Software • Cadena – Hatcliff et al., Kansas State • Koala – Van Ommering, Philips • MetaH – Vestal, Honeywell • nesC – Gay et al., Intel & Berkeley • Ptolemy II – Lee et al., Berkeley • Vest – Stankovic et al., Virginia

14. Motivation and IntroductionConcurrency AnalysisReal-Time AnalysisSummary and Conclusion

15. Concurrency • Embedded systems are fundamentally concurrent • Interrupt-driven • Response-time requirements • Concurrency is hard • Especially when using components • Especially when components span multiple execution environments

16. Task Scheduler Logic (TSL) • First-order logic with extra relations and axioms • Formalizes locking concerns across execution environments

17. TSL Capabilities • Find races and other errors • Generate mapping from each critical section in a system to an appropriate lock • Lock inference

18. Why Infer Locks? • Locking rules are hard to learn, hard to get right • Sometimes no lock is needed • Components can be agnostic with respect to execution environments • Global side effects can be managed

19. TSL Prerequisites • Visible critical sections and resources • Safe approximation of call graph • TSL specifications for schedulers

20. Using TSL • Developers connect components as usual • No direct contact with TSL • Run TSL analysis at build time • Success – Return assignment of lock implementations to critical sections • Used to generate code • Failure – Return list of preemption relations that cause races

21. TSL Concepts • Tasks – units of computation • Asymmetric preemption • A « B means “B may preempt A” • Schedulers • S ◄ B means “S schedules B” • Locks • S  L means “S provides L” • A «L B means “B may preempt A while A holds L”

22. Resources and Races • Resources • A →L R means “A holds L while accessing R” • Race (A, B, R) = A →L1 R  B →L2 R  A  B  A «L1L2 B

23. Specifying Schedulers S • Non-preemptive • Generic preemptive • Priority A B S (t, t0, … , tn) = i. t◄ti (A « B)  (B « A)

24. Specifying Schedulers S • Non-preemptive • Generic preemptive • Priority A B S (t, t0, … , tn, L) = i. t◄ti  i,j. ti «tj  lL. t  l (A « B)  (B « A)

25. Specifying Schedulers S • Non-preemptive • Generic preemptive • Priority L H A B S (t, t0, … , tn, L) = i. t◄ti  i,j. i<j  ti «tj  lL. t  l (A « B)  (B « A)

26. INT H L IRQ Event Network Timer E1 E2 E3

27. IRQ Network Timer INT L H THREAD L H Event1 Event2 E3 E2 E1

28. Applying TSL • Applied to embedded monitoring system with web interface • 116 components • 1059 functions • 5 tasks • 2 kinds of locks + null lock

29. TSL Summary • Contributions • Reasoning about concurrency across execution environments • Automated lock inference • In ACP4IS 2003 • Future work: Optimal lock inference • Minimize run-time overhead • Maximize chances of meeting real-time deadlines

30. Motivation and IntroductionConcurrency AnalysisReal-Time AnalysisSummary and Conclusion

31. Real-Time Constraints • Examples • Deploy multiple airbags no more than 5 ms after collision • Compute flap position 100 times per second

32. Real-Time Analysis • Output • Success: • Static guarantee that deadlines will be met • A schedule (priority assignment) • Failure: • List of tasks not guaranteed to meet deadlines • Tasks with hard-wired priorities do not compose well

33. IRQ Network Timer Previous Example INT L H THREAD L H Event1 Event2 E3 E2 E1

34. IRQ Network Timer An Improvement INT H L V-Sched E2 E3 E1

35. Virtual Schedulers • Start with collection of real-time tasks • Insert only enough preemption to permit deadlines to be met • Support mutually non-preemptible collections of tasks • Existing real-time theory not good enough

36. Background • Preemption threshold scheduling (Saksena and Wang 2000) • Supports mixing preemptive and non-preemptive scheduling • But only as a back-end optimization • My work: make mixed preemption first-class

37. New Abstractions • Task clusters • Embed non-preemptive EEs in a system • Task barriers • Respect architectural constraints

38. Scheduling Algorithm 1 • Target is standard RTOS – no support for preemption thresholds • Three-level algorithm • Outer: iterate over partitions created by task barriers • Middle: iterate over clusters within a partition • Inner: iterate over tasks within a cluster • Requires O(n2) priority assignments to be tested

39. Scheduling Algorithm 2 • Target is RTOS that supports preemption thresholds • More degrees of freedom • Known optimal algorithms test O(n!) priority assignments • Use hill-climbing algorithm that attempts to minimize maximum lateness over all tasks • Works well in practice

41. Avionics Application • Avionics task set from Tindell et al. (1994) with 17 tasks and two locks • Both locks can be eliminated using task clusters • Only 5 threads are needed

42. Ping / Pong App on Motes

43. Real-Time Summary • Contributions: Task clusters and task barriers • Better abstractions to protect developers from multithreading • Permit embedding of non-preemptive execution environments • In RTSS 2002

44. Motivation and IntroductionConcurrency AnalysisReal-Time AnalysisSummary and Conclusion

45. Status and Ongoing Work • Tools exist • Checker for task scheduler logic • SPAK – real-time analysis • Stacktool – bound stack depth • Flatten – parameterizable inlining • Prototype CEE implementations • Large systems: PCs with Knit + OSKit • Small systems: Motes

46. Summary • CEE is a new framework for embedded software • Exploits qualities of the domain • Supports late binding • Basis for pluggable analyses and optimizations • Effective compromise between principles and pragmatics • NSF Embedded and Hybrid Systems 2002–2005

47. 1998 2003 2008 Theme: Appropriate, checkable abstractions for systems software Composable Execution Environments Hierarchical Loadable Schedulers Secure, large-scale embedded systems?

48. Thanks to… • Alastair Reid, Jay Lepreau, Eric Eide, and Kirk Webb

49. More info and papers here: http://www.cs.utah.edu/~regehr/