Composition of State Machines

Similar documents
Concurrent Models of Computation

Input and Output. Arijit Mondal. Dept. of Computer Science & Engineering Indian Institute of Technology Patna

Modal Models in Ptolemy

Introduction to Embedded Systems

Introduction to Embedded Systems

System Design, Modeling, and Simulation using Ptolemy II

(c) Does this model thermostat have the time-scale invariance property?

EEL 4744C: Microprocessor Applications. Lecture 7. Part 1. Interrupt. Dr. Tao Li 1

Reading Assignment. Interrupt. Interrupt. Interrupt. EEL 4744C: Microprocessor Applications. Lecture 7. Part 1

4/6/2011. Model Checking. Encoding test specifications. Model Checking. Encoding test specifications. Model Checking CS 4271

Executing SyncCharts with Ptolemy

Microkernel/OS and Real-Time Scheduling

Hybrid System Modeling: Operational Semantics Issues

Embedded Software Programming

Concurrent Models of Computation

Memory Architectures. Hongwei Zhang. Chapter 9

SCXML State Chart XML

Hierarchical FSMs with Multiple CMs

Introduction to Embedded Systems

Embedded System Design and Modeling EE382V, Fall 2008

SCXML. Michael Bodell.

A Multi-Modal Composability Framework for Cyber-Physical Systems

Lecture #13 Interrupts Embedded System Engineering Philip Koopman Monday, 29-Feb-2016

CA314 Object Oriented Analysis & Design - 7. File name: CA314_Section_07_Ver01 Author: L Tuohey No. of pages: 16

Controller FSM Design Issues : Correctness and Efficiency. Lecture Notes # 10. CAD Based Logic Design ECE 368

State Machine Diagrams

Embedded Real-Time Systems

Introduction to Embedded Systems. Lab Logistics

Meltem Özturan

STATE MACHINES. Figure 1: State Machines

SCXML State Chart XML. Previously, in this course...

ANSI C CODE SYNTHESIS FOR MLDESIGNER FINITE STATE MACHINES

State-Based Testing of Ajax Web Applications

Caches 3/23/17. Agenda. The Dataflow Model (of a Computer)

Caches. Samira Khan March 23, 2017

EE249 Lab September 30 h, 2008 Hugo A. Andrade

Synchronizing the Asynchronous

Grundlagen Microcontroller Interrupts. Günther Gridling Bettina Weiss

EE382N.23: Embedded System Design and Modeling

Introduction to Embedded Systems

Lecture 6B Hierarchical/Concurrent State Machine Models (HCFSM)

27 December 2016 Pramod Ghimire. Slide 1 of 16

Embedded Systems. Stammvorlesung 9 CP. Lectures: Tuesdays, 16:15-18:00 Thursdays, 10:15-12:00 BF - ES - 2 -

By: Chaitanya Settaluri Devendra Kalia

Unified Modeling Language 2

EE458 - Embedded Systems Exceptions and Interrupts

Model checking Timber program. Paweł Pietrzak

Formal Methods in Software Engineering. Lecture 07

In the previous lecture, we examined how to analyse a FSM using state table, state diagram and waveforms. In this lecture we will learn how to design

In the previous lecture, we examined how to analyse a FSM using state table, state diagram and waveforms. In this lecture we will learn how to design

Portable Real-Time Code from PTIDES Models

SDL. Jian-Jia Chen (slides are based on Peter Marwedel) TU Dortmund, Informatik 年 10 月 18 日. technische universität dortmund

Advanced Tool Architectures. Edited and Presented by Edward A. Lee, Co-PI UC Berkeley. Tool Projects. Chess Review May 10, 2004 Berkeley, CA

Embedded Software TI2725 C. 5. Software architectures. Koen Langendoen. Embedded Software Group

TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica

Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn. 2.3 Timed Automata and Real-Time Statecharts

The learning objectives of this chapter are the followings. At the end of this chapter, you shall

Steps in Using COMET/UML

Representing Swarm Behaviors

Signals, Synchronization. CSCI 3753 Operating Systems Spring 2005 Prof. Rick Han

Interacting Process Classes

Finite State Machines and Modal Models in Ptolemy II

Process Synchronization. Mehdi Kargahi School of ECE University of Tehran Spring 2008

State-Based Testing Part B Error Identification. Generating test cases for complex behaviour

Specifications and Modeling

Microcontrollers and Interfacing week 8 exercises

Section 8. The Basic Step Algorithm

From Analysis to Design. LTOOD/OOAD Verified Software Systems

Motivation State Machines

Embedded Real-Time Systems

Concurrent & Distributed Systems Supervision Exercises

The Real Time Thing. What the hack is real time and what to do with it. 22C3 30. December Erwin Erkinger e.at

State Machine Specification Directly in Java and C++ Alexander Sakharov

10/21/2016. ECE 120: Introduction to Computing. Let s Extend Our Keyless Entry FSM. FSM Designs Also Allow Use of Abstraction

Cyber Physical System Verification with SAL

AVR Timers TIMER0. Based on:

Editor. Analyser XML. Scheduler. generator. Code Generator Code. Scheduler. Analyser. Simulator. Controller Synthesizer.

Microprocessors B (17.384) Spring Lecture Outline

Exercise Unit 2: Modeling Paradigms - RT-UML. UML: The Unified Modeling Language. Statecharts. RT-UML in AnyLogic

Component-Based Design of Embedded Control Systems

Simulation of LET Models in Simulink and Ptolemy

Embedded System Design and Modeling EE382V, Fall 2008

RE-ENTRANCY IN OPERATING SYSTEM. - By Surya Seetharaman

The Java Memory Model

Combined Modeling and Programming with State Machines

Ingegneria del Software Corso di Laurea in Informatica per il Management

visualstate Reference Guide

TIMES A Tool for Modelling and Implementation of Embedded Systems

Hardware Description Languages & System Description Languages Properties

Hardware Description Languages & System Description Languages Properties

Specifications Part 1

Introduction to Embedded Systems

Applied Unified Ownership. Capabilities for Sharing Across Threads

EL6483: Basic Concepts of Embedded System ModelingSpring and Hardware-In-The-Loo

Embedded Systems Programming

Ripple Counters. Lecture 30 1

Page 1. Challenges" Concurrency" CS162 Operating Systems and Systems Programming Lecture 4. Synchronization, Atomic operations, Locks"

Object-Interaction Diagrams: Sequence Diagrams UML

fakultät für informatik informatik 12 technische universität dortmund Specifications Peter Marwedel TU Dortmund, Informatik /11/15

Chapter 3 - Top Level View of Computer Function

Transcription:

Chapter 5 Composition of State Machines Hongwei Zhang http://www.cs.wayne.edu/~hzhang/ Ack.: this lecture is prepared in part based on slides of Lee, Sangiovanni-Vincentelli, Seshia.

Outline Concurrent composition Hierarchical state machines

Outline Concurrent composition Hierarchical state machines

Composition of State Machines How do we construct complex state machines out of simpler building blocks? Two aspects of composition: 1. Spatial: how do the components communicate between each other? 2. Temporal: when do the components execute, relative to each other?

Temporal Composition of State Machines Sequential vs. Concurrent If Concurrent, Asynchronous vs. Synchronous

Hybrid Systems Provide Sequential Composition Modal models: sequencing between modes Drift Recovery Impulse https://www.youtube.com/watch?v=id3qggpzzim [Tomlin et al.]

For concurrent composition, we need an interface: Actor Model for State Machines Expose inputs and outputs, enabling concurrent composition:

Spatial Composition of State Machines Side-by-side composition Cascade composition Feedback composition

Side-by-Side Composition: state machines being composed do not communicate A key question: When do these machines react? How the reactions of composed machines are coordinated is called a Model of Computation (MoC).

Side-by-Side, Parallel Composition When do these machines react? Two of many possibilities: Together, in lock step (synchronous, concurrent composition) Independently (asynchronous, concurrent composition)

Synchronous Composition

Synchronous Composition Note that these two states are not reachable. Synchronous composition

Asynchronous Composition Asynchronous composition using interleaving semantics

Asynchronous Composition Note that now all states are reachable. C Asynchronous composition using interleaving semantics: A reaction of C is a reaction of one of A or B, where the choice is nondeterministic.

Syntax vs. Semantics Synchronous or Asynchronous composition? If asynchronous, does it allow simultaneous transitions in A & B? How to choose whether A or B reacts when C reacts (i.e., scheduling/priority)? The answers to these questions defines the MoC being used.

Cascade Composition A B Output port(s) of A connected to input port(s) of B

Example: Time-Triggered Pedestrian Light This light stays green for 55 seconds, then goes red. Upon receiving a sigr input, it repeats the cycle.

Example: Time-Triggered Car Light

Pedestrian Light with Car Light sigy sigg sigr What is the size of the state space of the composite machine? sigr pedg pedr

Synchronous cascade composition unsafe states

Synchronous composition with unreachable states removed

Shared Variables: Two Servers

Feedback Composition Reasoning about feedback composition can be very subtle. (more about this later)

Spatial Composition of State Machines Side-by-side composition Cascade composition Feedback composition

Outline Concurrent composition Hierarchical state machines

Recall Synchronous Composition: Synchronous composition

Recall Asynchronous Composition: Asynchronous composition with interleaving semantics

Recall program that does something for 2 seconds, then stops volatile uint timercount = 0; void ISR(void) { disable interrupts if(timercount!= 0) { timercount--; enable interrupts int main(void) { // initialization code SysTickIntRegister(&ISR);... // other init timercount = 2000; while(timercount!= 0) {... code to run for 2 seconds

D E A B C Position in the program is part of the state volatile uint timercount = 0; void ISR(void) { disable interrupts if(timercount!= 0) { timercount--; enable interrupts int main(void) { // initialization code SysTickIntRegister(&ISR); // other init timercount = 2000; while(timercount!= 0) { code to run for 2 seconds whatever comes next A key question: Assuming interrupt can occur infinitely often, is position C always reached?

D E A B C State machine model volatile uint timercount = 0; void ISR(void) { disable interrupts if(timercount!= 0) { timercount--; enable interrupts int main(void) { // initialization code SysTickIntRegister(&ISR); // other init timercount = 2000; while(timercount!= 0) { code to run for 2 seconds whatever comes next Is asynchronous composition the right thing to do here?

Asynchronous composition A C B This has transitions that will not occur in practice, such as A,D to B,D. Interrupts have priority over application code.

Asynchronous vs Synchronous Composition volatile uint timercount = 0; void ISR(void) { disable interrupts if(timercount!= 0) { timercount--; enable interrupts int main(void) { // initialization code SysTickIntRegister(&ISR);... // other init timercount = 2000; while(timercount!= 0) {... code to run for 2 seconds Is synchronous composition the right model for this?

Asynchronous vs Synchronous Composition volatile uint timercount = 0; void ISR(void) { disable interrupts if(timercount!= 0) { timercount--; enable interrupts int main(void) { // initialization code SysTickIntRegister(&ISR);... // other init timercount = 2000; while(timercount!= 0) {... code to run for 2 seconds Is synchronous composition the right model for this? Is asynchronous composition (with interleaving semantics) the right model for this? Answer: no to both.

Modeling an interrupt controller FSM model of a single interrupt handler in an interrupt controller:

Modeling an interrupt controller int main(void) { // initialization code SysTickIntRegister(&ISR); // other init timercount = 2000; while(timercount!= 0) { code to run for 2 seconds Note that states can share refinements. volatile uint timercount = 0; void ISR(void) { disable interrupts if(timercount!= 0) { timercount--; enable interrupts

Hierarchical State Machines OR state (being B means being in C or D) refinement Reaction: (one of many possible models) 1. First, the refinement of the current state (if any) reacts. 2. Then the top-level machine reacts. If both produce outputs, they are required to not conflict. The two steps are part of the same reaction. [Statecharts, David Harel, 1987]

Hierarchical State Machines Example trace: Simultaneous transitions can produce multiple outputs. These are required to not conflict.

Hierarchical State Machines simultaneous transitions Example trace: Simultaneous transitions can produce multiple outputs. These are required to not conflict.

Hierarchical State Machines history transition Example trace: A history transition implies that when a state with a refinement is left, it is nonetheless necessary to remember the state of the refinement.

Equivalent Flattened State Machine Every hierarchical state machine can be transformed into an equivalent flat state machine. This transformation can cause the state space to blow up substantially.

Flattening the state machine (assuming history transitions): A history transition implies that when a state with a refinement is left, it is nonetheless necessary to remember the state of the refinement. Hence A,C and A,D.

Hierarchical State Machines with Reset Transitions A reset transition always initializes the refinement of the destination state to its initial state. reset transition Example trace: A reset transition implies that when a state with a refinement is left, you can forget the state of the refinement.

Flattening the state machine (assuming reset transitions): A reset transition implies that when a state with a refinement is left, it is not necessary to remember the state of the refinement. Hence there are fewer states.

Preemptive Transitions A preemptive transition specifies that the guard should be evaluated before the current state refinement reacts, and if it is true, then the current state refome,emt should not react.

Summary of Key Concepts States can have refinements (other modal models) OR states AND states Different types of transitions: History Reset Preemptive

Modeling an interrupt controller int main(void) { // initialization code SysTickIntRegister(&ISR); // other init timercount = 2000; while(timercount!= 0) { code to run for 2 seconds Note that states can share refinements. volatile uint timercount = 0; void ISR(void) { disable interrupts if(timercount!= 0) { timercount--; enable interrupts

Simplified interrupt controller This abstraction assumes that an interrupt is always handled immediately upon being asserted: A B C int main(void) { // initialization code SysTickIntRegister(&ISR); // other init timercount = 2000; while(timercount!= 0) { code to run for 2 seconds D E volatile uint timercount = 0; void ISR(void) { disable interrupts if(timercount!= 0) { timercount--; enable interrupts

Hierarchical interrupt controller This model assumes further that interrupts are disabled in the ISR: A key question: Assuming interrupt can occur infinitely often, is state C always reached?

Hierarchical interrupt controller This model assumes interrupts are disabled in the ISR: Reset, preemptive transition History transition

Hierarchical composition to model interrupts History transition results in product state space, but hierarchy reduces the number of transitions compared to asynchronous composition. Examining this composition machine, it is clear that C is not necessarily reached if the interrupt occurs infinitely often. If assert is present on every reaction, C is never reached.

Hierarchical composition to model interrupts History transition results in product state space, but hierarchy reduces the number of transitions compared to asynchronous composition. Under what assumptions/model of assert would C be reached?

Communicating FSMs In this ISR example, our FSM models of the main program and the ISR communicate via shared variables and the FSMs are composed asynchronously. There are other alternatives for concurrent composition (see Chapter 6 of Lee & Seshia).

Summary Composition enables building complex systems from simpler ones. Concurrent composition Hierarchical state machines: enable compact representations of large state machines. These can be converted to single flat FSMs, but the resulting FSMs are quite complex and difficult to analyze by hand. Algorithmic techniques are needed to analyze large state spaces (e.g., reachability analysis and model checking, see Chapter 13 of Lee & Seshia).

Assignment Exercise #7 Chapter 5: 4, 5, 6