Model Checking and Logic Synthesis Using Spin (Lab)

Computer Lab 1: Model Checking and Logic Synthesis using Spin (lab)

Richard M. Murray Nok Wongpiromsarn Ufuk Topcu California Institute of Technology

EECI 19 Mar 2013 Outline The Spin Model • Spin model checker: modeling Checker concurrent systems and descr- Gerard J. Holzmann ibing system requirements in Addison-Wesley, 2003 Promela http://spinroot.com • Model-checking with Spin • Logic synthesis with Spin The process flow of model checking

Efficient model checking tools automate the process: SPIN, nuSMV, TLC,...

EECI, Mar 2013 Richard M. Murray, Caltech CDS 2 Spin Verification Models

System design (behavior specification) process 1

Promela (Process Meta Language) is a non- g1 TS 1 • ; { } deterministic, guarded command language for s0: red s1: green specifying possible system behavior of a distributed system in Spin There are 3 types of objects in Spin verification • process 2 model TS - asynchronous processes g2 2 ; { } - global and local data objects s0: red s1: green - message channels System requirements (correctness claims) default properties = g1 g2 • ⇤⌃ ^ ⇤⌃ absence of system deadlock - true - absence of unreachable code q0 A g g • assertions • fairness ¬ 2 ¬ 1 end-state labels never claim g2 g • • ¬ q1 q2 ¬ 1 • acceptance • LTL formulas • progress • trace assertions

EECI, Mar 2013 Richard M. Murray, Caltech CDS 3 Running Spin model.pml

system pan.c design -a (model gcc Spin checking compiler system code) requirements -i -t

model.trail pan random interactive guided negative simulation simulation simulation (counter- result (executable example) veriﬁer)

Typical sequence of commands correctness proof $ spin -u100 model!# non-verbose simulation for 100 steps $ spin -a model!! # generate C code for analysis (pan.c) $ gcc -o pan pan.c!# generate executable verifier from pan.c $ ./pan -a -N P1!# perform verification of specification P1 $ spin -t -p model!# show error trail

Note: spin -- and ./pan -- list available command-line and un-time options, resp.

EECI, Mar 2013 Richard M. Murray, Caltech CDS 4 Account Setup

Lab computer login How to edit and use files • Username: LAB22-0N\eeci • Edit files using ‘Notepad’ in the - NN = 1, 2, 3, ... dropbox folder on Windows • Password: P@ssw0rd - Remember to save after you make changes Connecting to Amazon - Wait a few seconds for sync’ing • Run “Putty” from the desktop • Run commands on Amazon • Double click on EECI saved session • Look at results on Amazon • Username: eeci13 • Password: pw4belgrade Using Amazon from your own laptop • See Ufuk or Richard to get IP address Finding the right folder on Amazon for appropriate Amazon instance • cd groupN/spin • Install Dropbox and then see Richard • ls!!!# list files or Ufuk to get sharing set up Open Dropbox folder for your group Installing Spin on your laptop • Double click on Dropbox icon (should • Install Spin from spinroot.com be on desktop) (requires local C compiler) • Open ‘groupN’ folder to see the same • Download sample files from course files web page (Computer Session 1)

EECI, Mar 2013 Richard M. Murray, Caltech CDS 5 Example 1: traffic lights (property verified)

System TS: composition of two traffic lights Specification P 1 : and a controller “The light are never green g1 simultaneously.” c2 q2,s1,c2 { } [](!(g1 && g2)) q1 s1 ↵ ↵ ↵ ↵

↵ ↵ c1 q1,s1,c1 SPIN code: q s2 P1 2 ¬ g1 g2 A c3 q1,s2,c3 traffic traffic g2 { } { } controller light 1 light 2 = { } Property verified:

TS P1 ltl P1 { [] (! (g1 && g2)) } spin -a lights_simple.pml

lights_simple.pml ltl P2 { [] <> g1 } gcc -o pan pan.c ltl P3 { ./pan -a -N P1 lights_simple.pml (always (!(g1&&g2))) && ./pan -a -N P2 lights_simple.pml (always eventually g1) spin -t -p lights_simple.pml }

EECI, Mar 2013 Richard M. Murray,6 Caltech CDS Promela: Process Modeling Language

bit g1, g2;!!!/* light status */ Declarations bit alpha1, alpha2, beta1, beta2; Declare global variables (+ initialize) int c = 1;!!!/* control state */ • active proctype TL1() { • Types: bit, int, char, etc + arrays do :: alpha1 -> g1 = 1 Processes :: beta1 -> g1 = 0 Each process runs independently od • } • ‘active’ => process starts immediately active proctype TL2() { - Otherwise use ‘run’ command loop2: Process = sequence of statements alpha2 -> g2 = 1 • beta2 -> g2 = 0 • Statements = guard or assignment goto loop2 } Control flow active proctype control() { • ‘do’ loops: non-deterministic execution do ‘goto’ statements: jump to location :: c == 1 -> alpha1=1; beta1=0; c = 2; • :: c == 2 -> alpha1=0; beta1=1; c = 3; • guarded commands: ‘guard -> rule’ :: c == 3 -> alpha2=1; beta2=0; c = 4; :: c == 4 -> alpha2=0; beta2=1; c = 1; Specifications od LTL statement to be checked } • - These generate ‘never’ claims ltl P1 { [] <> g1 } internally to spin (will see later) ltl P2 { [] ! (g1 && g2) }

EECI, Mar 2013 Richard M. Murray, Caltech CDS 7 Promela Objects: Processes

• A keyword proctype is used to declare process behavior • 2 ways to instantiate a process - Add the prefix active to a proctype declaration. The process will be instantiated in the initial system state. - Use run operator to instantiate a process in any reachable system state

# of processes to be instantiated in the initial system state proctype you run(byte x)

active [2] proctype main() { printf("x = %d n", x) \ { prinf("hello world n") } \ init } { run you run(0); keyword for initial process run you run(1) declaration and instantiation } Extra process init needs to be created

EECI, Mar 2013 Richard M. Murray, Caltech CDS 8 Promela Objects: Data Objects

• 2 levels of scope: global and process local • No intermediate levels of scope • The default initial value of all data objects is zero • All objects must be declared before they can first be referenced • User-defined type can be declared using keyword typedef

Type Typical Range Sample Declaration bit 0,1 bit turn = 1 bool false, true bool flag = true all elements byte 0 ...255 byte a[12] initialized to 0 chan 1 ...255 chan m mtype 1 ...255 mtype n pid 0 ...255 pid p 15 15 all elements short 2 ...2 1 short b[4] = 89 initialized to 89 int 231 ...231 1 int cnt = 67 unsigned 0...2n 1 unsigned w: 3=5 unsigned stored in 3 bits (range 0...7)

EECI, Mar 2013 Richard M. Murray, Caltech CDS 9 Basic Statements

• Assignment valid assignment: if the right-hand side yields a value outside - c++, c--, c = c+1, c = c-1 the range of c, truncation can result - invalid assignment: ++c, --c • Expressions - must be side effect free - the only exception is the run operator, which can have a side effect • Print: printf("x = %d n", x) \ • Assertion:assert(x+y == z), assert(x <= y) - always executable and has no effect on the state of the system when executed - can be used to check safety property: Spin reports a error if the expression can evaluate to zero (false)

int n; active proctype invariant() The assertion statement can be executed at any time. This can be used to check a { system invariant condition: it should hold no assert(n <= 3) matter when the assertion is checked. } send • message passing between processes (later, if time) • receive }

EECI, Mar 2013 Richard M. Murray, Caltech CDS 10 Rules for Executability

A statement in a Spin model is either executable or blocked • A statement is executable iff it evaluates to true or non-zero integer value 2<3 is always executable x < 27 executable i↵ x<27 3+x executable i↵ x =3 6 • print statements and assignments are always unconditionally executable • If a process reaches a point where there is no executable statements left to execute, it simply blocks

while (a != b) a == b; block until a==b

{ skip; do nothing while waiting for a==b }

do L: if :: (a == b) -> break :: (a == b) -> skip :: else -> skip :: else -> goto L od fi

EECI, Mar 2013 Richard M. Murray, Caltech CDS 11 Nondeterminism

2 levels of nondeterminism • System level: processes execute concurrently and asynchronously - Process scheduling decisions are non-deterministic - Statement executions from different processes are arbitrarily interleaved in time - Basic statements execute atomically • Process level: local choice within processes can also be non-deterministic

byte x = 2, y = 2; active proctype A() do { :: x = 3-x :: y = 3-y od At any point in an execution, any of these active} proctype B() statements can be executed do { :: x = 3-y :: y = 3-x od }

EECI, Mar 2013 Richard M. Murray, Caltech CDS 12 Control Flow

• Semicolons, gotos and labels swap the values of a and b • Atomic sequences: atomic ... atomic d step { } { { - Define an indivisible sequence of actions tmp = b; tmp = b; - No other process can execute statements from the moment b = a; b = a; that the first statement of this sequence begins to execute a = tmp a = tmp until the last one has completed } } • Deterministic steps: d step ... { } - Similar to atomic sequence but more restrictive, e.g., no nondeterminism, goto jumps, or unexecutable statements if are allowed :: (n % 2 != 0) -> n = 1 the else guard is executable • Nondeterministic selection: iff none of the other guards :: (n >= 0) -> n = n-2 if is executable. :: (n % 3 == 0) -> n = 3 :: guard1 -> stmnt11; stmnt12; ... :: else /* -> skip */ :: guard2 -> stmnt21; stmnt22; ... fi :: ... without the else clause, the if- fi statement would block until • Nondeterministic repetition: other guards becomes true. do :: guard1 -> stmnt11; stmnt12; ... do :: guard2 -> stmnt21; stmnt22; ... :: x++ :: ... :: x-- do :: break transfers control to the end of • Escape sequences: P unless E the loop { } { } od • Inline definitions: inline ... { } EECI, Mar 2013 Richard M. Murray, Caltech CDS 13 Nondeterministic Selection and Repetition

if do :: guard1 -> stmnt11; stmnt12; ... :: guard1 -> stmnt11; stmnt12; ... :: guard2 -> stmnt21; stmnt22; ... :: guard2 -> stmnt21; stmnt22; ... :: ... :: ... fi do

• If at least one guard is executable, the if/do statement is executable • If more than one guard is executable, one is selected non-deterministically • If none of the guard statements is executable, the if/do statement blocks • Any type of basic or compound statement can be used as a guard • ‘if’ statement checks once and continues; ‘do’ statement re-executes code until a break is reached

EECI, Mar 2013 Richard M. Murray, Caltech CDS 14 Defining Correctness Claims

• default properties - absence of system deadlock - absence of unreachable code safety • assertions • “nothing bad ever happens” - local process assertions • properties of reachable - system invariants states • end-state labels - deﬁne proper termination points of processes • accept-state labels - when looking for acceptance cycles • progress-state labels liveness - when looking for non-progress cycles • “ something good eventually happens” • fairness properties of infinite never claims • • sequences of states • LTL formulas • trace assertions

EECI, Mar 2013 Richard M. Murray, Caltech CDS 15 Progress and Acceptance

Progress • Search for reachable non-progress cycles (infinite executions that do not pass through any progress state) • Progress states are specified using progress label • Enforced by gcc -DNP and pan -l Acceptance • Search for acceptance cycles (infinite executions that do pass through a specially marked state) • Acceptance states are specified using accept label • Enforced by pan -a skip byte x = 2, y = 2; A P active proctype A() x = 3-x { do y = 3-y :: x = 3-x :: y = 3-y; progress: skip a non-progress cycle is an inﬁnite od execution sequence that does not pass through any progress state }

EECI, Mar 2013 Richard M. Murray, Caltech CDS 16 byte x = 2, y = 2; Fairness active proctype A() do { Weak fairness :: x = 3-x od • If a statement is executable infinitely long, it will eventually be executed active} proctype B() do { • Process-level weak-fairness can be enforced :: y = 3-y; progress: skip by run-time option pan -f od - if a process contains at least one } statement that remains executable $ spin -a progress.pml infinitely long, that process will $ gcc -DNP -o pan pan.c eventually execute a step $ ./pan -l -f - does not apply to non-deterministic transition choices within a process Strong fairness • If a statement is executable infinitely often, it will eventually be executed Enforcing fairness increases the cost of verification • Weak fairness: complexity is linear in the number of active processes • Strong fairness: complexity is quadratic in the number of active processes

EECI, Mar 2013 Richard M. Murray, Caltech CDS 17 Never Claims Define an observer process that executes synchronously with the system • Intended to monitor system behavior; do not contribute to system behavior • Can be either deterministic or non-deterministic • Contain only side-effect free expressions • Abort when they block spin -f '! []<>g1' • Reports a violation when - closing curly brace of never claim is reached - an acceptance cycle is found (infinite execution passing through accept label) Typically used to enforce LTL property never { /* ! []<>g1 */ T0_init: • Old style: spin -f ‘!spec’ generates if never claim :: (! ((g1))) -> goto accept_S4 :: (1) -> goto T0_init • New style: use ltl label { spec } fi; Make sure to run pan -a when you have accept_S4: • if never claims :: (! ((g1))) -> goto accept_S4 fi; Example: []<>g1 } • To make sure this is always true, need to make sure that !spec is never true (same inversion as usual)

EECI, Mar 2013 Richard M. Murray, Caltech CDS 18 Spin Commands model.pml system pan.c design -a gcc Spin (model checking compiler system code) requirements -i -t

model.trail pan random interactive guided negative simulation simulation simulation (counter- result (executable example) veriﬁer) Generate model-specific ANSI C code pan.c $ spin -a model.pml correctness proof Generate verifier from pan.c Relay error trail • Typical command $ spin -t -p -g model.pml $ gcc -o pan pan.c follow print all print all • Enforcing progress error trail statements global variables $ gcc -DNP -o pan pan.c Perform verification • Typical command Note: spin -- and ./pan -- $ ./pan -a -N P1 model.pml list available command-line • Enforcing progress: add -l and run-time options, resp • Enforcing acceptance: add -a • Enforcing fairness: add -f EECI, Mar 2013 Richard M. Murray, Caltech CDS 19 Exercise 1: traffic lights

System TS: composition of two traffic lights Specification P 1 : and a controller “The light are never green g1 simultaneously.” c2 q2,s1,c2 { } [](!(g1 && g2)) q1 s1 ↵ ↵ ↵ ↵

↵ ↵ c1 q1,s1,c1 SPIN code: q s2 P1 2 ¬ g1 g2 A c3 q1,s2,c3 traffic traffic g2 { } { } controller light 1 light 2 = { } Property verified:

TS P1 ltl P1 { [] (! (g1 && g2)) } spin -a lights_simple.pml

EECI, Mar 2013 Richard M. Murray,20 Caltech CDS Exercise 2: modified traffic lights

System TS: composition of two traffic lights Specification P 2 : and a modified controller “The first light is infinitely often green.”

q1 s1 ↵ c1 c2 ↵ ↵ ↵ c4 c3 P q2 s2 ¬ 2 g1 g2 A Property verified: { } { } g1 ↵ TS P2 q1,s1,c1 q2,s1,c2 { } ↵ q1,s2,c4 q1,s1,c3

g2 Construct a new Promela model { } lights_sequence.pml ltl P1= { [] (! (g1 && g2)) } ltl P2 { [] <> g1 } and verify P1, P2, P3 ltl P3 { (always (!(g1&&g2))) && (always eventually g1) }

EECI, Mar 2013 Richard M. Murray,21 Caltech CDS Exercise 3: Traffic Light Controller

Distributed traffic controller • TL1: traffic light one, accepts on/off commands • TL2: same for second light • Control: send a sequence of commands Approach • Model commands to lights using global variables • Use a finite state machine to implement controller Check multiple properties • Both lights turn green infinitely often • It is never true that both lights are green at the same time

EECI, Mar 2013 Richard M. Murray, Caltech CDS 22 Exercise 4: Controller Synthesis

TS TS bool g1 = 0, g2 = 0; 1 2 active proctype TL1() { s0: ;red s0: ;red do :: atomic g1 == 0 -> g1 = 1 :: atomic{ g1 == 1 -> g1 = 0} ↵ ↵ { } P = 1 1 2 2 od k s1: green s1: green active} proctype TL2() { g g do { 1} { 2} :: atomic g2 == 0 -> g2 = 1 :: atomic{ g2 == 1 -> g2 = 0} od { } = ⇤ (g1 g2) ⇤⌃g1 ⇤⌃g2 } ¬ ^ ^ ^ never T0 init:{ !( )=Words() if L A :: (!g1) || (!g2) -> goto T0 init :: (g1 && !g2) -> goto T1 S1 fi; T1 S1: A if (g g ) :: (!g1) || (!g2) -> goto T1 S1 q0 ¬ 1 ^ 2 :: (!g1 && g2) -> goto accept S1 fi; g1 g2 (g1 g2) accept S1: ^ ¬ ¬ ^ if g g :: (!g1) || (!g2) -> goto T0 init ¬ 1 ^ 2 (g g ) :: (g1 && !g2) -> goto T1 S1 ¬ 1 ^ 2 q1 q2 fi; g g } 1 ^ ¬ 2 EECI, Mar 2013 Richard M. Murray, Caltech CDS 23 Exercise 5: Farmer Puzzle A farmer wants to cross a river in a little boat with a wolf, a goat and a cabbage. Constraints: • The boat is only big enough to carry the farmer plus one other animal or object. • The wolf will eat the goat if the farmer is not present. • The goat will eat the cabbage if the farmer is not present. How can the farmer get all both animals and the cabbage safely across the river?

= ⌃(f = w = g = c = 1) P f0,w0 f1,w0 ^ g ,c g ,c (w = g f = g) 0 0 0 0 ⇤ 6 _ ^ (g = c f = g) ⇤ 6 _ f1,w1 f1,w0 f1,w0 g0,c0 g1,c0 g0,c1 ( )=Words() L! A f0,w1 f0,w0 f0,w0 g0,c0 g1,c0 g0,c1 f1,w1 f1,w0 g1,c0 g1,c1 q0 (w = g g = c) f = g A f1,w1 6 ^ 6 _ g0,c1 (f = w = g = c = 1) ^ (w = g g = c) f = g f0,w1 f0,w1 f0,w0 6 ^ 6 _ g1,c0 g0,c1 g1,c1 p p = i (w = g g = c) f = g i , q1 6 ^ 6 _ p f,w,g,c , 2 { } f1,w1 f0,w1 EECI, Mari 20130, 1 g1,c1 g1,cRichard1 M. Murray, Caltech CDS 2 { } 24 Solving farmer puzzle with Spin

A farmer wants to cross a river in a little boat with a wolf, a goat and a cabbage. Constraints: • The boat is only big enough to carry the farmer plus one other animal or object. • The wolf will eat the goat if the farmer is not present. • The goat will eat the cabbage if the farmer is not present.

bit f=0, w=0, g=0, c=0; active proctype P() farmer crosses the river alone do { :: f=1-f farmer and goat cross the river :: atomic f==g -> f=1-f; g=1-g :: atomic{ f==w -> f=1-f; w=1-w } :: atomic{ f==c -> f=1-f; c=1-c } farmer and wolf cross the river od { } farmer and cabbage cross the river } never T0 init:{ if :: (w != g && g != c) || (f==g) -> goto T0 init q0 (w = g g = c) f = g A :: (f && g && w && c) && ((w != g && g != c) || f==g) 6 ^ 6 _ -> goto accept S2 (f = w = g = c = 1) fi; ^ accept S2: (w = g g = c) f = g if 6 ^ 6 _ :: (w != g && g != c) || (f==g) -> goto accept S2 (w = g g = c) f = g fi; q1 6 ^ 6 _ } EECI, Mar 2013 Richard M. Murray, Caltech CDS 25 Computer Lab Gcdrive Veriﬁcation Gcdrive is the overall driving software for Alice. It takes independent commands from Path Follower and DARPA and sends appropriate commands to the actuators. • Commands from Path Follower include control signals to throttle, brake and transmission. • Commands from DARPA include estop pause, estop run and estop disable. - An estop pause command should cause the vehicle to be brought quickly and safely to a rolling stop. - An estop run command resumes the operation of the vehicle. - An estop disable command is used to stop theExercise vehicle and put6: itAlice in the disable Actuation mode. A vehicle Interface that is in (adrive) Logic the disable mode may not restart in response to an estop run command. Unknown (U) Paused (P) Disabled (D) Mission The ﬁnite state machine to handle these concurrent Estop Disable - initial state on start - depress brakes - depress brakes Planner commands is shown below. Use Spin to verify that - reject all directives - send trans disable except steering - reject all directives the following properties hold. Traffic Estop Disable Estop Estop Paused Planner • If DARPA sends an estop disable command, Run Path Gcdrive state will eventually stay at Shift cmd Resuming (Re) Running (Ru) Shifting (S) Planner DISABLED and Acceleration Module will - start timer on entry Timeout - normal operating - reject all directives - transition after 5 state - transition when shift eventually command full brake forever. sec - process all directives Shift done is completed Path Follower • If DARPA sends an estop pause command whileDesired the vehicle properties is not disabled, eventually Gcdrive state will be PAUSED. Actuation • If Estop Disable is received, gcdrive state will be Disabled and Interface • If DARPA sends an estop run command while the accelerationvehicle is not will disabled, be ‘full eventuallybrake’ forever Gcdrive state will be RUNNING or RESUMING or DARPA will send• anEstop estop Paused disable: ifor not estop disabled, pause gcdrivecommand. will eventually enter Vehicle • If the current state is RESUMING, eventually the statePaused will statebe RUNNING and acceleration or DARPA will be will ‘full send brake’ an estop (not forever) disable or pause command. • Estop Run: if not Disabled, gcdrive will eventually be Running or Resuming (or • The vehicle is disabled only after it receives an estopreceive disable another command. pause or disable command) • Actuation Interface sends a full brake command• toIf theResuming Acceleration, eventually Module Running if the current(or receive state another is DISABLED, pause or disable) PAUSED, RESUMING or SHIFTING. In addition, •if Ifthe current vehicle mode is disabled, is Disabled, then Paused,the gear isResuming shifted to or 0. Shifting, full brake is commanded • After receiving an estop pause command, the vehicle• After may receiving resume an the Estop operation Pause 5, vehicleseconds may after resume an estop operation run 5 seconds after run is command is received. received (suffices to show that we transition from Resuming to Running via Timeout) ... • Project: verify correctness using SPIN model checker and message channels EECI, Mar 2013 Richard M. Murray, Caltech CDS 26 Exercise 7: Robot Motion Planning

C21 C22 C23 C24 C25 The robot starts from cell C21.

C16 C17 C18 C19 C20 Compute a trajectory for a robot to visit cell C8, then C1 and then cover C10, C 17 and C25 while avoiding C11 C12 C13 C14 C15 obstacles C2, C 14, C 18. C6 C7 C8 C9 C10 Physical constraints: C1 C2 C3 C4 C5 • The robot can only move to an adjacent cell

C1 C2 C3 C4 C5

C6 C7 C8 C9 C = C (C C C C ) 10 ⌃ 8 ^ ⌃ 1 ^ ⌃ 10 ^ ⌃ 17 ^ ⌃ 25 ^ ⇤ (C2 C14 C18) C11 C12 C13 C14 C15 ¬ _ _

C16 C17 C18 C19 C20

C21 C22 C23 C24 C25

EECI, Mar 2013 Richard M. Murray, Caltech CDS 27 Example: frog puzzle

Find a way to send all the yellow frogs to the right hand side of the pond and send all the red frogs to the left hand side. Constraints: • Frogs can only jump in the direction they are facing. • Frogs can either jump one rock forward if the next rock is empty or they can jump over a frog if the next rock has a frog on it and the rock after it is empty.

http://www.hellam.net/maths2000/frogs.html

EECI, Mar 2013 Richard M. Murray, Caltech CDS 28 Solving the frog puzzle as logic synthesis

• Rock i is not occupied or occupied r 0, 1 r0 r1 r2 r3 r4 r5 r6 i { } • State of frog i: s(F ) s ,s ...,s i { 0 1 6} • Transition system of frog i: Fi s0 s1 s2 s3 s4 s5 s6 • Overall system model: P = F F F 1 2 ··· 6

F1 s0 F F3 r1 r1 r2 r 2 ¬ ^ ¬ s ¬ 2 s s r 1 2 2 ¬ 2 r r r r r2 r3 r3 r4 s1 s2 104 2045 2 ^ ¬302163 0456 3 ^ 40321¬ 4 5062 603 ^ ¬ ^ ¬ r2 r3 r3 r4 r4 r4 ^ ¬ ^ ¬ s3 ¬ s4 s3 ¬ s4 r4 s ¬ s r4 r5 r5 r6 r4 r5 r5 r6 3 4 ^ ¬ ^ ¬ ^ ¬ ^ ¬ r4 r5 r5 r6 r6 r6 ^ ¬ ^ ¬ s5 ¬ s6 s5 ¬ s6 r6 s5 ¬ s6

= s(F ),s(F ),s(F ) s ,s ,s s(F ),s(F ),s(F ) s ,s ,s ⌃ 1 2 3 2 { 4 5 6} ^ 4 5 6 2 { 0 1 2} p , s(F1),s(F2),s(F3) s4,s5,s6 true p trueA 2 { } ^ q0 q1 s(F ),s(F ),s(F ) s ,s ,s 4 5 6 2 { 0 1 2}

EECI, Mar 2013 Richard M. Murray, Caltech CDS 29