Principles and Pragmatics for Embedded Systems

1
Principles and Pragmatics for Embedded Systems

• John Regehr
• University of Utah

2
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
Infrastructure and metadata
CEE Composable Execution Environments
Analyses Time Safety Stack Size Race
Detection Lock Inference
Optimizations Thread Minimization Robust
Scheduling Lock Elimination Inlining
Error
Composed 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
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

• Non-preemptive
• Generic preemptive
• Priority

S
A
B
S (t, t0, , tn) ?i. t?ti
?(A B) ? ?(B A)
24
Specifying Schedulers

• Non-preemptive
• Generic preemptive
• Priority

S
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

• Non-preemptive
• Generic preemptive
• Priority

S
L
H
A
B
S (t, t0, , tn, L) ?i. t?ti ? ?i,j. iltj
? ti ? tj ? ?l?L. t ? l
?(A B) ? (B A)
26
INT
H
L
IRQ
Event
Network
Timer
E1
E2
E3
27
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
Previous Example
INT
L
H
THREAD
L
H
Event1
Event2
E3
E2
E1
34
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

40
(No Transcript)
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
version code data Pin-Int Int-Task Task-Task
Default 5022 B 232 B 11.3 µs 22.5 µs 16.0 µs
CEE 6094 B 448 B 11.3 µs 46.7 µs 45.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 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 20022005

47
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/