System Modelling and Verification

Slides:



Advertisements
Similar presentations
Fakultät für informatik informatik 12 technische universität dortmund SDL Peter Marwedel TU Dortmund, Informatik 12 Graphics: © Alexandra Nolte, Gesine.
Advertisements

Communicating finite state machines
Embedded System, A Brief Introduction
ES Seminar1 Communicating Transaction Processes P.S. Thiagarajan National University of Singapore Joint Work with: Abhik Roychoudhury; ……
Based on: Petri Nets and Industrial Applications: A Tutorial
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
D u k e S y s t e m s Time, clocks, and consistency and the JMM Jeff Chase Duke University.
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
Timed Automata.
Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
fakultät für informatik informatik 12 technische universität dortmund Early design phases Peter Marwedel TU Dortmund, Informatik 12 Graphics: © Alexandra.
ECE 720T5 Fall 2012 Cyber-Physical Systems Rodolfo Pellizzoni.
Distributed Computing 5. Snapshot Shmuel Zaks ©
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture 05.
Synthesis of Embedded Software Using Free-Choice Petri Nets.
1 Complexity of Network Synchronization Raeda Naamnieh.
Petri Nets Overview 1 Definition of Petri Net C = ( P, T, I, O) Places P = { p 1, p 2, p 3, …, p n } Transitions T = { t 1, t 2, t 3, …, t n } Input.
Ordering and Consistent Cuts Presented By Biswanath Panda.
Review of “Embedded Software” by E.A. Lee Katherine Barrow Vladimir Jakobac.
FunState – An Internal Design Representation for Codesign A model that enables representations of different types of system components. Mixture of functional.
Software Engineering, COMP201 Slide 1 Protocol Engineering Protocol Specification using CFSM model Lecture 30.
Models of Computation for Embedded System Design Alvise Bonivento.
Modeling State-Dependent Objects Using Colored Petri Nets
CS 290C: Formal Models for Web Software Lecture 2: Modeling States with Statecharts Instructor: Tevfik Bultan.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Hoofdstuk 2 Systeemspecificatietechnieken 2.1 Functionele specificatie Prof.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
Real-Time System Requirements & Design Specs Shaw - Chapters 3 & 4 Homework #2: 3.3.1, 3.4.1, Add Error states to Fig 4.1 Lecture 4/17.
Lecture 6 Template Semantics CS6133 Fall 2011 Software Specification and Verification.
02/06/05 “Investigating a Finite–State Machine Notation for Discrete–Event Systems” Nikolay Stoimenov.
Ch.2 Part A: Requirements, State Charts EECE **** Embedded System Design.
- 1 - Embedded Systems—State charts Specifications.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Specifications.
Lecture 4 Finite State Machine CS6133 Software Specification and Verification.
Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Some general properties of languages 1. Synchronous vs. asynchronous languages.
ECE 720T5 Winter 2014 Cyber-Physical Systems Rodolfo Pellizzoni.
Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.
- 1 - Embedded Systems - SDL Some general properties of languages 1. Synchronous vs. asynchronous languages Description of several processes in many languages.
StateCharts Peter Marwedel Informatik 12 Univ. Dortmund Germany.
CY2003 Computer Systems Lecture 7 Petri net. © LJMU, 2004CY2003- Week 72 Overview Petri net –concepts –Petri net representation –Firing a transition –Marks.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Ch. 2. Specification and Modeling 2.1 Requirements Describe requirements and approaches for specifying and modeling embedded systems. Specification for.
Lyra – A service-oriented and component-based method for the development of communicating systems (by Sari Leppänen, Nokia/NRC) Traditionally, the design,
C. André, J. Boucaron, A. Coadou, J. DeAntoni,
1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
Petri Nets Lecturer: Roohollah Abdipour. Agenda Introduction Petri Net Modelling with Petri Net Analysis of Petri net 2.
CSCI1600: Embedded and Real Time Software Lecture 7: Modeling II: Discrete Systems Steven Reiss, Fall 2015.
1 Copyright  2001 Pao-Ann Hsiung SW HW Module Outline l Introduction l Unified HW/SW Representations l HW/SW Partitioning Techniques l Integrated HW/SW.
CS3773 Software Engineering Lecture 06 UML State Machines.
technische universität dortmund fakultät für informatik informatik 12 Early design phases Jian-Jia Chen (slides are based on Peter Marwedel) TU Dortmund,
CSCI1600: Embedded and Real Time Software Lecture 11: Modeling IV: Concurrency Steven Reiss, Fall 2015.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Ordering of Events in Distributed Systems UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department CS 739 Distributed Systems Andrea C. Arpaci-Dusseau.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
 Simulation enables the study of complex system.  Simulation is a good approach when analytic study of a system is not possible or very complex.  Informational,
High Performance Embedded Computing © 2007 Elsevier Lecture 4: Models of Computation Embedded Computing Systems Mikko Lipasti, adapted from M. Schulte.
Hardware/Software Co-Design of Complex Embedded System NIKOLAOS S. VOROS, LUIS SANCHES, ALEJANDRO ALONSO, ALEXIOS N. BIRBAS, MICHAEL BIRBAS, AHMED JERRAYA.
Agenda  Quick Review  Finish Introduction  Java Threads.
1 Advanced Embedded Systems Lecture 3 Specification Languages.
Lecture 2 Specification and Requirement Analysis of Embedded System.
CPE555A: Real-Time Embedded Systems
2. Specification and Modeling
Embedded System Design Specifications and Modeling
COT 5611 Operating Systems Design Principles Spring 2012
Dynamic Modeling Lecture # 37.
Specifications and Modeling
COT 5611 Operating Systems Design Principles Spring 2014
Presentation transcript:

System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich

Processing system are everywhere and they are highly inter-connected Introduction Processing system are everywhere and they are highly inter-connected ABS gear box motor control climate control entertainment Kai Lampka

Introduction → high degree of non-determinism Systems are distributed and loosely coupled → high degree of concurrency Large degree of uncertainty w.r.t. timing and interaction → high degree of non-determinism Systems need to fulfill a set of (quantifiable) constraints, e.g. given in TCTL Kai Lampka 3

Modelling and Analysis System complexity can not be grasped by human- beings, at least as a whole, see PI-Problem. How does one ensure that a system design is free of systematic errors and fulfills its requirements? Examples: Reactivity within time bound, Deadlock- freeness, Buffer does not over-/underflow, absence of PI, timing correctness….. Need for scalable analysis methods of ensure that system designs satisfies predefined properties. implementation and analysis methods!

Verification & Validation System Engineering with the V-process Engineering = Design and Implementation + Deployment Verification & Validation Concept of Operations Operations & Maintenance System Verification & Validation Requirements & Architecture Verification & Validation Integration, Test & Verification Detailled Design Source: US department of transportation (see also wikipedia.org) Implementation Time For avoiding mal-developments and costly re-design of existing systems Verification, Validation, and Testing has to be integrated into the design process as early as possible!

Methodologies for evaluating System Designs Empirical Methods Deductive Methods Model-based Real System (Prototype) State-based methods: behaviour is captured by finite graphs, Examples: PN, StateCharts Simulation: behaviour is evaluated by statistics over individual runs (some snap-shots) Measurement, Monitoring Testing Kai Lampka Analytic methods: behaviour is deduced from closed-form formulae. Example: Process Networks, PN Industrial practice Non-exhaustive Exhaustive

Requirements for Modeling technique Represent hierarchy Humans not capable to understand systems containing more than a few objects, particularly when here is feedback/complex interaction Most actual systems require more objects Hierarchy of objects Behavioral hierarchy Examples: states, processes, procedures. Structural hierarchy Examples: processors, racks, printed circuit boards

Requirements for Modeling Techniques (2) Represent timing behavior/requirements Represent state-oriented behavior suitable for reactive systems and complex behavior of SW. Represent dataflow-oriented behavior Components send streams of data to each other. No obstacles for efficient implementation, of the analysis methods and the system (synthesis of skeletons)

Models of Computation: Definition What does it mean, “to compute”? Models of computation define: Components and an execution (semantic) model for computations for each component, e.g., Token-game for PN) Communication model for exchange of information between components (semantic of interaction synchronous/asynchronous) Shared memory Message passing …

Semantic of communication: Shared memory Potential race conditions (inconsistent results possible) Communication must be implemented as critical section (sections at which exclusive access to resource r (e.g. shared memory) must be guaranteed). process a { .. P(S) //obtain lock .. // critical section V(S) //release lock } process b { .. P(S) //obtain lock .. // critical section V(S) //release lock } Race-free access to shared memory protected by S possible

Semantic of communication: Non-blocking/asynchronous message passing Sender does not have to wait until message has arrived; potential problem: buffer overflow, e.g., PN without inhibitor arcs … send () … receive ()

Semantic of communication: Blocking/synchronous message passing Sender will wait until receiver has received message, e.g., joint execution of transitions in PN (transitions are merged according to an logical AND) … send () … receive ()

Semantic of communication: Synchronous message passing: CSP CSP (communicating sequential processes) [Hoare, 1985], rendez-vous-based communication. process A .. var a ... a:=3; c!a; -- output action end process B .. var b ... ... c?b; -- input action end This basic mechanism can be found in most automata- based modelling formlisms, e.g., Timed Automata of Uppaal. Modeling asynchronous behaviour by explicitly modeling communication media (Queue)

Semantic of computation Discrete State Systems Finite state machines Petri Nets Continuous State Systems Differential equations Hybrid (continous states/ discrete control states) Timed Automata

Model of computation No language that meets all language requirements Use-case give needs and determines capabilities required from the modeling technique But, remember: Computation effort to do analysis differs considerably! Extension of Formalisms: Small changes in the modeling technique can easily result in undecidability for deciding state reachability!

StateCharts Classical automata not useful for complex systems (complex graphs cannot be understood by humans). Introduction of hierarchy StateCharts [Harel, 1987] in parts re-used in UML

Introducing Hierarchy FSM will be in exactly one of the substates of S if S is active (either in A or in B or ..)

Definitions Current states of FSMs are also called active states. States which are not composed of other states are called basic states. States containing other states are called super-states. For each basic state s, the super-states containing s are called ancestor states. Super-states S are called OR-super-states, if exactly one of the sub-states of S is active whenever S is active. superstate ancestor state of E substates

Default State Mechanism Filled circle indicates sub-state entered whenever super-state is entered. Entrance point, not a state by itself!

Saving history (behavior different from last slide) m k For input m, S enters the state it was in before S was left (can be A, B, C, D, or E). If S is entered for the very first time, the default mechanism applies. History and default mechanisms can be used hierarchically.

Combining History and Default State same meaning

Concurrency Convenient ways of describing concurrency are required. AND-super-states: FSM is in all (marked) sub- states of a super-state.

Entering and Leaving AND-Super-States incl. Line-monitoring and key-monitoring are entered and left, when service switch is operated.

Tree representation of state sets OR-super-state AND-super-state basic state A B E C D F M G H I K L A C D B E F I K L M G H A X Y B C Y Z X A

Computation of state sets Computation of state sets by traversing the tree top-down basic states: state set = state OR-super-states: state set = union of children AND-super-states: state set = Subset of cartesian product of children A B E C D F M G H I K L

Types of States In StateCharts, states are either Basic states, or AND-super-states, or OR-super-states.

Timers Since time needs to be modeled in embedded systems, timers need to be modeled. In StateCharts, special edges can be used for timeouts. If event a does not happen while the system is in the left state for 20 ms, a timeout will take place.

Using Timers: Example of an answering Machine

Extension of sematic to variables Besides states, arbitrary many other variables can be defined. This way, not all states of the system are modeled explicitly. These variables can be changed as a result of a state transition (“action”). State transitions can be dependent on these variables (“condition” ). action unstructured state space variables condition

Syntax: General Form of Edge Labels event [condition] / action also called guard Events: Exist only for the next evaluation of the model Can be either internally or externally generated Conditions: Refer to values of variables that keep their value until they are reassigned Actions: Can either be assignments for variables or creation of events Example: service-off [a <= 7] / service:=0

Events and actions “event” can be composed of several events: (e1 and e2) : event that corresponds to the simultaneous occurrence of e1 and e2. (e1 or e2) : event that corresponds to the occurrence of either e1 or e2, or both. (not e): event that corresponds to the absence of event e. „action“ can also be composed: (a1; a2) : actions a1 und a2 are executed in parallel. Note: Events, states and actions are globally visible!

Example true false true false x y z e/a1 [c]/a2 e: a1: a2: c: e: a1:

StateChart Model execution Phases How are edge labels evaluated? Three phases: 1. Effect of external changes on events and conditions is evaluated, 2. The set of transitions to be made in the current step and right hand sides of assignments are computed, 3. Transitions become effective, variables obtain new values.

Example In phase 2, variables a and b are assigned to temporary variables. In phase 3, these are assigned to a and b. As a result, variables a and b are swapped. In a single phase environment, executing the left state first would assign the old value of b (=0) to a and b. Executing the right state first would assign the old value of a (=1) to a and b. => Execution is non-deterministic, one needs to consider all permutations.

Model of compuation State Space exploration (step-wise execution) of a StateChart model consists of a sequence of (status, step) pairs Status= values of all variables + set of events + current time (state) Step = execution of the three phases (state-to-state transition) Status phase 2 phase 3 phase 1

Motivation for this modus operandi: Motivation for this modus operandi: It reflects model of clocked hardware In an actual clocked (synchronous) hardware system, both registers would be swapped as well. Same separation into phases found in other languages as well, especially those that are intended to model hardware (e.g., synchronous languages, LUSTRE).

Alternative interpretation Unfortunately, there are several (synchronous) time-semantics for StateCharts available. This is another possibility: A step is executed in arbitrarily small time. Internal (generated) events exist only within the next step. Difference: External events can only be detected after a stable state has been reached. external events stable state stable state state transitions t transport of internal events step

Example state diagram: stable states

Example state diagram (only stable states are represented, only a and b are external): A D E C F H c/d d d a B a b  a b _ a _ G I a b G,H b _ b a b B a/c a b  a b _ F,H

Example Non-determinism a a A C E G a a B D F H state diagram: A,B C,D E,H F,G a

Evaluation of StateCharts (1) Pros: Hierarchy allows arbitrary nesting of AND- and OR- super states. Semantics defined in a follow-up paper to original paper. Large number of commercial simulation tools available (StateMate, StateFlow/Matlab, BetterState, UML, ...) Available „back-ends“ translate StateCharts into C or VHDL, thus enabling software or hardware implementations.

Evaluation of StateCharts (2) Cons: Generated C programs frequently inefficient, Not useful for distributed applications, No description of non-functional behavior, No object-orientation, No description of structural hierarchy.

SDL Specification and Description Language (SDL) is a specification language targeted at the unambiguous specification and description of the behaviour of reactive and distributed systems. Used here as a (prominent) example of a model of computation based on asynchronous message passing. Appropriate also for distributed systems

Communication of SDL-FSM Communication between FSMs (or “processes“) is based on message-passing, assuming a potentially indefinitely large FIFO-queue. Each process fetches next entry from FIFO, checks if input enables transition, if yes: transition takes place, if no: input is discarded (exception: SAVE-mechanism).

Deterministic? Let tokens be arriving at FIFO at the same time. Order in which they are stored, is unknown All orders are legal: simulators can show different behaviors for the same input, all of which are correct.