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 Technology a 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 portsoutput ports parameters Actor tokens ‘C’ 31 ‘L’ ‘A’ tokens 42 ‘P’ 9912‘\’ 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 schedule Fire A Fire B Fire A Fire C Fire 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 CAL Cal 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; end 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... end end 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; end

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)* end end 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 end end

A CAL Application actor A() T in ==> T out1, T out2: a1 : action [a] ==> [e1],[] do... end a2 : action [a] ==> [],[e2] do... end end actor B() T in ==> T out: b1 : action [a] ==> [e1] guard.. do... end b2 : action [a] ==> [e2] guard.. do... end end 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... end end B A C

Analysis of a CAL Application B A C 1. Map the network into a petri net 2. Compute firing vectors 3. Find legal firing sequences 4. Select a schedule 5. Calculate buffer sizes 6. Fold the CAL actor descriptions for A, B & C output 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 a2 2.fire B, action b1 3.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