1. CSE 522 Model-based Development (1) Computer Science & Engineering Department Arizona State University Tempe, AZ 85287 Dr. Yann-Hang Lee yhlee@asu.edu (480) 727-7507 Some of the slides were based on lectures by Lee & Seshia (UC Berkeley) and Fainekos (ASU)

2. Modeling, Design, Analysis  Modeling is the process of gaining a deeper understanding of a system through imitation. Models specify what a system does.  Design is the structured creation of artifacts. It specifies how a system does what it does. This includes optimization.  Analysis is the process of gaining a deeper understanding of a system through dissection. It specifies why a system does what it does (or fails to do what a model says it should do). 2

3. What is Modeling?  A mathematical model in the form of a set of definitions and mathematical formulas.  Use mathematical objects to describe the (dynamical or static) properties and behavior of the system  Developing insight about a system, process, or artifact through imitation.  The artifact that imitates the system, process, or artifact of interest.  Mathematical models can help us  understand the system behavior  predict the system behavior  analyze the system behavior  identify system parameters 3

4. What is Model-Based Design?  Create a mathematical model of all the parts of the embedded system  Physical world  Control system  Software environment  Hardware platform  Network  Sensors and actuators  Construct the implementation from the model  Construction may be automated, like a compiler  More commonly, portions are automatically constructed 4

5. When is a Design of a System “Correct”?  A design is correct when it meets its specification (requirements) in its operating environment  “A design without specification cannot be right or wrong, it can only be surprising!”  Simply running a few tests is not enough!  Many embedded systems are deployed in safety-critical applications (avionics, automotive, medical, …)

6. Specification, Verification, and Control Specification A mathematical statement of the design objective (desired properties of the system) Verification Does the designed system achieve its objective in the operating environment? Verification Does the designed system achieve its objective in the operating environment? Synthesis Given an incomplete design, synthesize a strategy to complete the system so that it achieves its objective in the operating environment Synthesis Given an incomplete design, synthesize a strategy to complete the system so that it achieves its objective in the operating environment

7. Model-Based Design: Verification Design Tool Verify: Does model satisfy spec.? Model Specification No Use error trace information to revise model/spec. Need a mathematical way to write models and specifications so that a verification algorithm can process it

8. Model-Based Design: Synthesis Automatic Model Synthesis Tool Partial Description of the Model Specification Automatic code s ynthesis for specific platform Need a mathematical way to write models and specifications so that an algorithm can process it

9.  Representation (i.e. variables, time)  state space and control function  Continuous System  continuous dynamics  differential equations  Discrete System (FSM)  in a sequence of discrete steps  difference equations  Hybrid System  digital controller (thermostat)  with both continuous and discrete dynamic behavior System Models 9

10. Continuous Models  Ordinary differential equations, Laplace transforms, feedback control systems, stability analysis, robustness analysis, … 10

11. Modeling a Simple Suspension (SS1) m1m1 car body m2m2 axles (all combined) coil springs tires k1k1 k2k2 c1c1 x2x2 x1x1 shock absorbers x road Input Outputs: x 1, x 2, dx 1 /dt, dx 2 /dt

12. Modeling a Simple Suspension (SS1)  Recall: let us set and  Thenwhere

13. Actor Model of a Continuous System  Example: integrator:  Continuous-time signal:  Continuous-time actor: Block x y d/dt x y=dx/dt 1/s x y(t)=x 0 +  0 t x(τ)dτ (SS1) x road z (integradtion) (differentiation) (our simple suspension system)

14. Discrete Systems  Example: count the number of cars that enter and leave a parking garage:  Pure signal:  Discrete actor:

15. Discrete Time Signals Consider a signal x : R +  {absent} x R, where R is some range and let T be the points in time that it is present T = {t  R + | x(t)  absent}. Then, x is discrete if there exists 1-1 function f : T  N which is order preserving. The system is event triggered. t absent present up : N +  {absent, present}

16. Garage Counter Finite State Machine  A garage has a finite space  state space = {0,1,2,…M} declaration of inputs and outputs the arrow denotes the initial state states down is present up is absent

17. FSM Notation  “guard / action”  A guard is a predicate (a boolean-valued expression) that evaluates to true when the transition should be taken  The transition is enabled transition self loop state initial state

18. Formal Definition of FSM  An FSM (finite state automaton) is a 5-tuple (states, inputs, outputs, update, initialstate) where  States is a finite set of states  Inputs is a set of input valuations  Outputs is a set of output valuations  update : States x Inputs  States x Outputs is an update function, mapping a state and input valuation to a next state and an output valuation  initialState is the initial state

19. Garage Counter Mathematical Model The picture above defines the update function.

20. Garage Counter Mathematical Model update(s,i) = (s+1,s+1) if s<M and i(up)=present and i(down) = absent (s-1,s-1) if s>0 and i(up)=absent and i(down) = present (s,absent) otherwise update : States x Inputs  States x Outputs

21. FSM Execution  The dynamics of a discrete system can be described by a sequence of reactions  We ignore how much time has passed between each reaction  For each reaction the FSM moves from the current state to the next state  s : N  S is the state of FSM for each reaction  We can number the visited states (0 for the initial)  Input & output valuations x : N  Inputs and y : N  Ouputs  The FSM dynamics are (s(n+1),y(n)) = update(s(n),x(n))

22. FSM Behavior  Each port p, for each reaction will take a value from V p  {absent}, generating a sequence (or function) s p : N  V p  {absent}  Behavior: the assignment of signals to each input port such that an output sequence can be produced  Observable trace ((x i, y i )) i  N  Execution trace ((x i, s i, y i )) i  N  The set of all behaviors of an FSM M is called the language of M and it is denoted by L(M) 22

23. Garage Counter: Behavior Behavior: s up = (present, absent, present, absent, present, …) s down = (present, absent, absent, present, absent, …) s count = (absent, absent, 1, 0, 1, …) Note if s count was something else, then this might not have been a behavior of the system.

24.  A default transition is enabled if no non-default transition is enabled and it either has no guard or the guard is true.  Extended state machines augment the FSM model with variables that may be read or written. Extended State Machines Question: What is the size of the state space?

25. Definitions  Stuttering transition: Implicit default transition that is enabled when inputs are absent and that produces absent outputs.  Receptiveness: For any input values, some transition is enabled. Our structure together with the implicit default transition ensures that our FSMs are receptive.  Determinism: In every state, for all input values, exactly one (possibly implicit) transition is enabled, i.e. next possible state is uniquely determined.  Non-deterministic: If for any state of a state machine, there are two distinct transitions with guards that can evaluate to true in the same reaction.

26. Example: Nondeterministic FSM  Nondeterministic model of pedestrians arriving at a crosswalk:  Formally, the update function is replaced by a function

27. Behaviors and Traces  FSM behavior is a sequence of (non-stuttering) steps.  A trace is the record of inputs, states, and outputs in a behavior.  A computation tree is a graphical representation of all possible traces.  FSMs are suitable for formal analysis. For example, safety analysis might show that some unsafe state is not reachable.

28. Uses of Nondeterminism  Modeling unknown aspects of the environment or system  Such as: how the environment changes the iRobot’s orientation  Hiding detail in a specification of the system  We will see an example of this later  More compact than deterministic FSMs  For a fixed input sequence:  A deterministic system exhibits a single behavior  A non-deterministic system exhibits a set of behaviors...

29. What we will be able to do with FSMs  FSMs provide:  A way to represent the system for:  Mathematical analysis  So that a computer program can manipulate it  A way to model the environment of a system.  A way to represent what the system must do and must not do – its specification.  A way to check whether the system satisfies its specification in its operating environment.

30. Example from Industry: Engine Control Source: Delphi Automotive Systems (2001)

31. FSM Controller for iRobot States = {init, tilt, drive} Inputs = ? outputs = ? update = ? Any transitions missing?

32. FSM Controller for iRobot (version 2) Will this robot always drive uphill? (assume that it starts facing uphill) Also need to specify “else” arcs for tilt and drive

33. Modeling the iRobot’s environment Llevel=true NL45 level=false, 45 o offset NL90 level=false, 90 o offset q Self loops on: rotate=false q Is this model deterministic?

34. Traffic Light Controller  When does a reaction occur  time-triggered model -- if one reaction per second  event-triggered model -- when any input is present