Actor Oriented Programming with CAL-designing embedded system components

Johan Eker

Department of Automatic Control, Lund University

Chris Chang, Jörn Janneck, Yang Zhao

EECS, University of California at Berkeley

LUCAS Seminar, October 22, 2002

Multipurpose tools Express almost anything, guarantee almost nothing “You only need to know one programming language!”

Easy to get started, harder to finish Programmers+language, a lifelong marriage Examples:

Java C/C++ with RTOS, ADA, Modula-2 RMA & EDF scheduling

Sharpen your tools

Use problem specific tools

Constrain the solutions

Combine several dedicated tools

“Don’t get it right, keep it right”

Component Technologya component is a component is a component

Examples: Java beans, VB-components, etc Rationale

Encapsulation & Reuse Successful in many areas Embedded components

Problems with concurrency Threads do not compose well Difficult to encapsulate properties such as priorities,

deadlines, execution times, etc. Static interfaces not good enough

State-of-the art technology does not suffice

Enter actor oriented programming

Actors and models An application (or a model) is expressed as

a network of actors Actors communicate via token passing When an actor is fired it consumes

tokens and produces token The actor itself is agnostic about when

and how it is scheduled and how and with whom it is communicating

input ports output ports

parameters

Actortokens

‘C’

31

‘L’ ‘A’

tokens

42

‘P’

99 12 ‘\’

state 42

Actors decouple data and control

N

Data

41

FIRE

What's an actor

A Model of Computation governs the actor interaction, i.e.

Sheduling Communication

What's an application

A

B

C

D

A scheduleFire AFire AFire BFire AFire CFire D

Hierarchical, heterogeneous modeling and design in Ptolemy II

sensors

leader

Br Acc

Ba

bang-bang PID

follower

controller actuators

S

Models of computation

Slide courtesy of Edward Lee

Components

Actor = Component A network of actors can be

transformed into a single actor

+MoC

Enter CALCal Actor Language

A domain-specific language for writing dataflow actors

Ports, states, parameters Produces & consumes tokens

actor A() Double input ==> Double output:

mutable Integer n := 0; mutable Double sum := 0; action [a] ==> [sum / n] do n := n + 1; sum := sum + a; endend

A

Multiple actions and tags

actor B() Integer in1, Integer in2 ==> Integer out: a1 : action [a, b], [] ==> [exp1] do ... end a2 : action [a], [b] ==> [exp1, exp2] do ... end a3 : action [a, b], [c]==> [exp1] do ... end a4 : action [a], [b, c]==> [exp1] do ... endend

Port pattern example in1=[1,2,3], in2=[1] matches all in1=[1], in2=[2] matches a2 & a4 in1=[1,2,3], in2=[] matches a1

An actors defines a set of input-output relation

Parameters & Guards

actor A(Double max) Double input ==> Double output: mutable Integer n := 0; mutable Double sum := 0; action [a] ==> [] guard sum > max do end action [a] ==> [sum / n] do n := n + 1; sum := sum + a; endend

Action schedules, priorities & type parameters

actor FairMerge[T]() T Input1, T Input2 ==> T Output: A : action [a], [] ==> [a] do end B : action [], [a] ==> [a] do end schedule (A B)* endend

other selectors are conceivable, e.g.• (A B)* | (B A)*• ( (A B) | (B A) )*

actor AnotherMerge[T]() T Input1, T Input2 ==> T Output: A: action [a], [] ==> [a] do end B: action [a], [b] ==> [a] do end priority B > A endend

A CAL Application

actor A() T in ==> T out1, T out2: a1 : action [a] ==> [e1],[] do ... end a2 : action [a] ==> [],[e2] do ... endend

actor B() T in ==> T out: b1 : action [a] ==> [e1] guard .. do... end b2 : action [a] ==> [e2] guard .. do... endend

actor C() T in1, T in3 ==> T Out1, T Out2: c1 : action [a],[b] ==> [e1],[] do ... end c2 : action [a], [] ==> [],[e2] do ... end c3 : action [], [b] ==> [e1],[e2] do... endend

B

A C

Analysis of a CAL Application

B

A C

1. Map the network into a petri net2. Compute firing vectors3. Find legal firing sequences4. Select a schedule5. Calculate buffer sizes6. Fold the CAL actor descriptions for A, B & C

outputinput

input

output

Source level transformation

actor ABD() T in ==> T out: action [a] ==> [e1] A$a2(); B$b1(); C$c1(); end procedure A$a2() begin ... end .....end

1. fire A, action a22. fire B, action b13. fire C, action c1

Assume we found the following schedule:

Removes external buffers No need for a scheduler Source level components CAL provides an dynamic component interface

What are the benefits?

Components are refined upon composition!

Some Cal Buzzwords

Control flow analysis Token production/consumption rates Side effect free expressions Lambda and procedural closures

First class of course Type parametric Immutable varibles as default

No aliasing

Key Concept: Orthogonal Concerns

Communication

Scheduling

Algorithm

Summary Embedded system components Java code for Ptolemy II/Grafchart

frameworks C-code Compiler is being developed at UCB

and Thales Research Ltd, UK. More information

Eker et al “Taming heterogeneity-the Ptolemy Approach”, IEEE Proceedings

http://www.gigascale.org/caltrop http://ptolemy.eecs.berkeley.edu