Embedded Software: Leveraging Concurrent Models of Computation

Edward A. Lee Professor, UC Berkeley Center for Hybrid and Embedded Software Systems (CHESS)

Citris Information Days June 30 – July 1, 2004 Infineon, Munich, Germany

Are Resource Limitations the Key Defining Factor for Embedded Software?

| small memory | small data word sizes | relatively slow clocks

To deal with these problems, emphasize efficiency: | write software at a low level (in assembly code or C) | avoid operating systems with a rich suite of services | develop specialized computer architectures z programmable DSPs z network processors

This is how embedded SW has been designed for 25 years

Lee, Berkeley 2

z1 Why hasn’t Moore’s law changed all this in 25 years?

Lee, Berkeley 3

Hints that Embedded SW Differs Fundamentally from General Purpose SW

| object-oriented techniques are rarely used z classes and inheritance z dynamic binding | processors avoid memory hierarchy z virtual memory z dynamically managed caches | memory management is avoided z allocation/de-allocation z garbage collection

To be fair, there are some applications: e.g. Java in cell phones, but mainly providing the services akin to general purpose software. Lee, Berkeley 4

z2 More Hints: Fundamentally Different Techniques Applied to Embedded SW.

| nesC/TinyOS method-call z developed for programming very small models of programmable sensor nodes called “motes” computation | Click z created to support the design of software-based network routers

| Simulink with Real-Time Workshop actor-oriented z created for embedded control software and widely models of used in the automotive industry computation | Lustre/SCADE z created for safety-critical embedded software (e.g. avionics software)

Lee, Berkeley 5

Standard Software Abstraction (20-th Century Computation)

initial state

sequence f : State → State Alan Turing

final state

• Time is irrelevant • All actions are ordered

Lee, Berkeley 6

z3 Standard Software Abstraction: Processes or Threads

The operating system (typically) provides: Infinite sequences of state • suspend/resume transformations are called • mutual exclusion “processes” or “threads” • semaphores suspend

resume

Lee, Berkeley 7

Standard Software Abstraction: Concurrency via Interacting Threads

Potential for race conditions, stalled by precedence deadlock, and livelock severely compromises software race condition reliability.

These methods date back to the stalled for rendezvous 1960’s (Dijkstra).

Lee, Berkeley 8

z4 A Stake in the Ground

Nontrivial concurrent programs based on processes, threads, semaphores, and mutexes are incomprehensible to humans, and should not be used in safety critical software.

z No amount of software engineering process is going to solve this problem. • the human brain doesn’t work this way. z Formal methods may help • scalability? understandability? z Better concurrency abstractions will help more • four promising examples: nesC/TinyOS, Click, Lustre/SCADE, and Simulink.

Lee, Berkeley 9

Alternative Concurrency Models: First example: nesC and TinyOS

Typical usage pattern: | hardware interrupt signals an event. interface provided | event handler posts a Component 1 task. | tasks are executed when interface used machine is idle. event handled command invoked | tasks execute atomically w.r.t. one another. command implemented event signaled | tasks can invoke interface provided commands and signal events. Component 2 | hardware interrupts can Command interface used interrupt tasks. implementers can | exactly one monitor, invoke other implemented by disabling commands or interrupts. post tasks, but do not trigger events. Lee, Berkeley 10

z5 Alternative Concurrency Models: Second example: Click Typical usage pattern: | queues have push input, agnostic output port pull output. | schedulers push output port have pull push input port input, push output. | thin wrappers for hardware have push output or pull input only. pull output port

Implementation of Click with a visual syntax in Mescal (Keutzer, et al.) Lee, Berkeley 11

Observations about nesC/TinyOS & Click

| But rather specialized z Unfamiliar to programmers z No preemption (tasks must be decomposed)

Lee, Berkeley 12

z6 Alternative Concurrency Models: Third example: Lustre/SCADE

Typical usage pattern: | specify tasks aligned to a synchronous signal value master “clock” and subclocks | clock calculus checks for consistency and deadlock | decision logic is given with hierarchical state machines.

state machine giving decision logic from http://www.esterel-technologies.com/ Lee, Berkeley 13

Observations about Lustre/SCADE

| But rather specialized z Unfamiliar to programmers z No preemption z No time

Lee, Berkeley 14

z7 The Real-Time Problem

| Programming languages have no time in their core semantics | Temporal properties are viewed as “non-functional” | Precise timing is poorly supported by hardware architectures | Operating systems provide timed behavior on a best-effort basis (e.g. using priorities). | Priorities are widely misused in practice

Lee, Berkeley 15

Alternative Concurrency Models: Fourth example: Simulink

Typical usage pattern: | model the continuous dynamics of the physical plant | model the discrete-time controller | code generate the discrete-time controller

continuous-time signal

Discrete signals semantically are piecewise constant. Discrete blocks have periodic execution with a specified “sample time.” Lee, Berkeley 16

z8 Observations about Simulink

| Bounded stack sizes | Deterministic (no race conditions) | Timing behavior is explicitly given | Efficient code generator (for periodic discrete-time) | Supports concurrent tasks | No threads or processes visible to the programmer z But cleverly leverages threads in an underlying O/S.

| But rather specialized z Periodic execution of all blocks z Accurate schedulability analysis is difficult

Lee, Berkeley 17

Two Distinct Component Interaction Mechanisms Method-call based: nesC/TinyOS class name What flows through data Click an object is methods sequential control

call return

Actor oriented:

Lustre/SCADE actor name Simulink data (state) What flows through parameters an object is streams of data ports

Input data Output data Lee, Berkeley 18

z9 Terminology Problem

| Of these, only nesC is recognized as a “programming language.”

| I will call them “platforms” z A platform is a set of possible designs: • the set of all nesC/TinyOS programs • the set of all Click configurations • the set of all SCADE designs • the set of all Simulink block diagrams

Lee, Berkeley 19

Abstraction

These four “platforms” offer distinct alternative abstractions (models of computation).

They are highly concurrent, and very different from the traditional threads and processes.

Three paintings by Piet Mondrian Lee, Berkeley 20

z10 How Many More (Useful) Models of Computation Are There?

Lee, Berkeley 21

Many Variants – Consider Dataflow Alone: Many tools, | Computation graphs [Karp & Miller - 1966] software frameworks, | Process networks [Kahn - 1974] and hardware | Static dataflow [Dennis - 1974] architectures | Dynamic dataflow [Arvind, 1981] have been | K-bounded loops [Culler, 1986] built to support | Synchronous dataflow [Lee & Messerschmitt, 1986] one or more of | Structured dataflow [Kodosky, 1986] these. | PGM: Processing Graph Method [Kaplan, 1987] | Synchronous languages [Lustre, Signal, 1980’s] | Well-behaved dataflow [Gao, 1992] | Boolean dataflow [Buck and Lee, 1993] | Multidimensional SDF [Lee, 1993] | Cyclo-static dataflow [Lauwereins, 1994] | Integer dataflow [Buck, 1994] | Bounded dynamic dataflow [Lee and Parks, 1995] | Heterochronous dataflow [Girault, Lee, & Lee, 1997] | … Lee, Berkeley 22

z11 How to Choose a Platform: Tools Focus

Is this a good tool? • How easy is it to use? • How well supported is it? • Does it run fast?

These are the Secondary Questions!

Lee, Berkeley 23

How to Choose a Platform: Abstraction Focus

Is this a good way to do design? • Does it express the important properties of a design? • Does it support abstraction and modularity? • Do the design abstractions scale? • Can it compile/code generate to cost-effective solutions? • Are designs built using it understandable/analyzable?

These are the Primary Questions!

Lee, Berkeley 24

z12 The Meta Question

How can we objectively evaluate the alternatives?

Lee, Berkeley 25

Meta Platforms Supporting Multiple Models of Computation

To varying degrees, each of these provides an abstract semantics that gets specialized to deliver a particular model of computation.

ROOM is evolving into an OMG standard (composite structures in UML 2) Lee, Berkeley 26

z13 Conclusion

| Embedded software is an immature technology | Focus on “platforms” not “languages” | Platforms have to: z expose hardware (with thin wrappers) z embrace time in the core semantics z embrace concurrency in the core semantics | API’s over standard SW methods won’t do | Ask about the “abstractions” not the “tools”

| Many questions remain…

Lee, Berkeley 27

z14