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

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

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 Safe Efficient Reusable Easy to develop Functionally correct Minimal Memory use CPU use Power use Composable Late binding Debuggable Testable Problem specific

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

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 RAM 1 B1 KB1 MB1 GB 4- and 8-bit 16-bit 32- and 64-bit No OS Real-Time OS (RTOS) GPOS CPU Type OS 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 Introduction Concurrency Analysis Real-Time Analysis Summary 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  Non-preemptive  Generic preemptive  Priority S AB  (A « B)   (B « A) S (t, t 0, …, t n ) =  i. t◄t i

24. Specifying Schedulers  Non-preemptive  Generic preemptive  Priority S AB (A « B)  (B « A) S (t, t 0, …, t n, L) =  i. t◄t i   i,j. t i «  t j   l  L. t  l

25. Specifying Schedulers  Non-preemptive  Generic preemptive  Priority S AB  (A « B)  (B « A) S (t, t 0, …, t n, L) =  i. t◄t i   i,j. i<j  t i «  t j   l  L. t  l H L

26. INT IRQ Event Timer Network E1E2E3 H L

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

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 Introduction Concurrency Analysis Real-Time Analysis Summary 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. Previous Example INT IRQ Timer Network Event1 E1 E2 E3 Event2 THREAD H L H L

34. An Improvement INT IRQ Timer Network E1 E2E3 V-Sched HL

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(n 2 ) 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 versioncodedataPin-IntInt-TaskTask-Task Default5022 B232 B11.3 μs22.5 μs16.0 μs CEE6094 B448 B11.3 μs46.7 μs45.2 μs

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 Introduction Concurrency Analysis Real-Time Analysis Summary 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. Hierarchical Loadable Schedulers Theme: Appropriate, checkable abstractions for systems software 1998 2008 2003 Secure, large- scale embedded systems? Composable Execution Environments

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

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