Comparing State Machines: Equivalence and Refinement

Transcription

1 Chapter 14 Comparing State Machines: Equivalence and Refinement Hongwei Zhang Ack.: this lecture is prepared in part based on slides of Lee, Sangiovanni-Vincentelli, Seshia.

2 2 Component Substitution Can we replace one component in a system by another and be assured that it will continue to work correctly? What if we replace the Cortex-A9 core by a Cortex-A12? myrio 1950/1900

3 Comparing State Machines Why compare state machines? Check conformance with a specification. Optimize a model by reducing complexity. Check if component substitution is OK. How can we compare two state machines Equivalence: Do they do the same thing? Refinement: Does one do more than the other? E.g., exhibit different behaviors? produce different outputs?

4 FSM Controller for irobot Assume a time-triggered FSM. If the level input is present, then it drives forward for a fixed amount of time by issuing a drive command. If the level input is absent, then it rotates for a fixed amount of time.

5 FSM Controller for irobot Assume a time-triggered FSM. If the level input is present, then it drives forward for a fixed amount of time by issuing a drive command. If the level input is absent, then it rotates for a fixed amount of time. M 1 Alternative FSM. Is machine M 2 equivalent to M 1? In what sense? M 2

6 Equivalence: Part 1: Type Equivalence Notice that the actor models for these machines have the same input ports and the same output ports. Moreover, the ports have the same types. M 1 Therefore M 2 is type equivalent to M 1. M 2

7 Equivalence: Part 2: Language Equivalence Notice that for every input sequence, the two machines produce the same output sequence. M 1 Therefore M 2 is language equivalent to M 1. M 2

8 Equivalence: Part 3: Bisimulation This one is very subtle: Notice that for every state of M 1 there is a corresponding state of M 2 that will react to inputs in exactly the same way and will then transition to another similarly corresponding state. corresponding M 1 Therefore M 2 is bisimilar to M 1. For deterministic machines, language equivalence and bisimilarity are the same. For nondeterministic machines they are not. We will come back to this! But first, refinement. M 2

9 Equivalence vs. Refinement Two state machines M 1 and M 2 that are not equivalent may nonetheless be related: M 2 may be type compatible with M 1 in that it can replace M 1 without causing a type conflict. (type refinement) M 2 may be a specialization of M 1 in that it can produce only output sequences that M 1 can produce, given the same input sequences. (language containment) M 2 may be a specialization of M 1 in that, at every reaction, M 2 can produce only output values that M 1 can produce. (M 1 simulates M 2 ) (simulation) In all cases, if M 1 is valid in a system, then so is M 2, where only the meaning of valid varies. M 2 is a type/language/simulation refinement of M 1. M 2 implements M 1 (here, M 1 is taken to be a specification).

10 Outline Type equivalence and refinement Language equivalence and refinement Simulation and bisimulation

11 Refinement: Part 1: Type Refinement x: V x y: V y M 2 is a type refinement of M 1 if: w: V w M 1 P 1 = { x, w } Q 1 = { y } x: V' x M 2 y: V' y z: V' z M 2 can replace M 1 without causing a type conflict. P 2 = { x } Q 2 = { y, z }

12 Recall the Garage Counter

13 Example of Type Refinement Consider a garage counter M 1 with M = 99 spaces. Suppose another garage counter M 2 has M = 90 spaces. M 2 is a type refinement of M 1. Why might this matter? Is it always OK to replace M 1 with M 2?

14 When is Replacement OK? The counter machine above can be replaced by the equivalent machine below:

15 When is Replacement OK? The two machines are again equivalent. How to define equivalence? Is equivalence always required? M 1 M 2 For deterministic machines: language refinement. For nondeterministic machines: simulation

16 Outline Type equivalence and refinement Language equivalence and refinement Simulation and bisimulation

17 Behavior (Execution Trace) of a State Machine For language refinement, traces will comprise only of inputs and outputs, not of states.

18 Behavior of a State Machine x: V x y: V y M 1

19 x: V Language Refinement x y: V y M 1 x: V x y: V y M 2 L(M 2 ) L(M 1 ) M 2 can replace M 1 if its observable (I/O) behavior is a subset of that of M 1.

20 Language Equivalence is not Enough in General Note that these two machines are language equivalent. Yet.

21 Robin Milner Much of this is due to Robin Milner, English computer scientist and Turing Award winner ( )

22 Language Equivalence is not Enough in General Even though these machines have exactly the same input/output behaviors, there is a context in which M 1 is not a valid replacement for M 2.

23 Language Equivalence is not Enough in General Suppose M 1 is the specification (everything it does is OK). It is fine to replace it with M 2 because at each step, any move M 2 can make is OK (because any move M 1 can make is OK).

24 Language Equivalence is not Enough in General Conversely, Suppose M 2 is the specification (everything it does is OK). It is not OK to replace it with M 1 because in state b, M 1 is always capable of making a move that M 2 cannot make (think of a malicious M 1 that watches M 2 ).

25 Outline Type equivalence and refinement Language equivalence and refinement Simulation and bisimulation

26 Simulation Relation: The Matching Game M 1 simulates M 2.

27 Simulation Relation: The Matching Game M 1 simulates M 2. Game: each machine starts in its initial state. M 2 moves first

28 Simulation Relation: The Matching Game first possibility M 1 simulates M 2. Game: M 2 moves first, and then M 1 matches the move. M 2 moves first

29 Simulation Relation: The Matching Game M 1 simulates M 2. second possibility Game: matching the move: same input, same output. M 2 moves first

30 Simulation Relation: The Matching Game M 1 simulates M 2. Game: Get to all reachable states of M 2. M 2 moves first the simulation relation

31 Simulation Relation: The Matching Game Since M 1 simulates M 2, M 2 refines M 1, M 2 can replace M 1 ; everywhere M 1 is OK, so is M 2.

32 M 2 does not simulate M 1 M 1 moves first

33 M 2 does not simulate M 1 valid choice for M 2 M 1 moves first

34 M 2 does not simulate M 1 valid choice for M 2 valid choice for M 1 outputs don t match!!!

35 Simulation Relation: The Matching Game Postponing decisions is more powerful than not. Free will is more powerful than preordination. M 1 can do anything M 2 can do, but not vice versa. M 1 simulates M 2, but not vice versa.

36 Formal definition of Simulation

37 Bisimulation A still stronger form of equivalence is called bisimulation. M 1 is bisimilar to M 2 if they are type equivalent and, when playing the game, on each move, either machine can move first, and the other machine can match its move.

38 Bisimulation It is possible to have two machines that simulate each other that are not bisimilar. M 1 simulates M 2 and vice versa, but they are not bisimilar.

39 Bisimulation It is possible to have two machines that simulate each other that are not bisimilar. Having the ability to make decisions early does not hurt you unless you exercise it.

40 Bisimulation, Formally

41 Simulation and Trace Containment

42 Summary M 2 is a type refinement of M 1 : M 2 can replace M 1 without causing a type conflict. M 2 is a language refinement of M 1 : M 2 can produce only output sequences that M 1 can produce, given the same input sequences. M 2 is a simulation refinement of M 1 : (equivalently, M 1 simulates M 2 ) At every reaction, M 2 can produce only outputs that M 1 can produce. M 2 is bisimilar to M 1 : At every state, either machine can produce only outputs that the other can produce. In all cases, if M 1 is valid in a system, then so is M 2, where only the meaning of valid varies. Alternative terminology: M 2 implements M 1 (here, M 1 is taken to be a specification).

43 Assignment Exercise #10 Chapter 14: 3, 5, 6