- 1 - Embedded Systems—State charts Specifications.

Slides:



Advertisements
Similar presentations
Technische universität dortmund fakultät für informatik informatik 12 Specifications and Modeling Peter Marwedel TU Dortmund, Informatik 12 Graphics: ©
Advertisements

Fakultät für informatik informatik 12 technische universität dortmund Specifications and Modeling Peter Marwedel TU Dortmund, Informatik 12 Graphics: ©
Fakultät für informatik informatik 12 technische universität dortmund SDL Peter Marwedel TU Dortmund, Informatik 12 Graphics: © Alexandra Nolte, Gesine.
Communicating finite state machines
Technische universität dortmund fakultät für informatik informatik 12 Specifications and Modeling Peter Marwedel TU Dortmund, Informatik
Embedded System, A Brief Introduction
Automata Theory Part 1: Introduction & NFA November 2002.
State Charts Mehran Najafi. Reactive Systems A reactive, event-driven, object is one whose behavior is best characterized by its response to events dispatched.
Technische universität dortmund fakultät für informatik informatik 12 Specifications, Modeling, and Model of Computation Jian-Jia Chen (slides are based.
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,
Week 6Fall 2001 CS5991 The STATEMATE Semantics of Statecharts D. Harel and A. Naamand Ahmad Alsawi 1-4 Bob Chen 5-8 Dapeng Xie 9-11.
TOPIC : Finite State Machine(FSM) and Flow Tables UNIT 1 : Modeling Module 1.4 : Modeling Sequential circuits.
Give qualifications of instructors: DAP
fakultät für informatik informatik 12 technische universität dortmund Early design phases Peter Marwedel TU Dortmund, Informatik 12 Graphics: © Alexandra.
Network Protocols Dr. Eng Amr T. Abdel-Hamid NETW 703 Winter 2006 Finite State Machines (FSMs)
Programming Languages Marjan Sirjani 2 2. Language Design Issues Design to Run efficiently : early languages Easy to write correctly : new languages.
ITEC113 Algorithms and Programming Techniques
Objectives Detailed Object-Oriented Requirements Definitions
CS 151 Digital Systems Design Lecture 37 Register Transfer Level
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.
Lecture 6 & 7 System Models.
Software Engineering, COMP201 Slide 1 Protocol Engineering Protocol Specification using CFSM model Lecture 30.
Models of Computation for Embedded System Design Alvise Bonivento.
State Machines Timing Computer Bus Computer Performance Instruction Set Architectures RISC / CISC Machines.
CS 290C: Formal Models for Web Software Lecture 2: Modeling States with Statecharts Instructor: Tevfik Bultan.
Mahapatra-A&M-Sprong'021 Co-design Finite State Machines Many slides of this lecture are borrowed from Margarida Jacome.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Hoofdstuk 2 Systeemspecificatietechnieken 2.1 Functionele specificatie Prof.
ECE 301 – Digital Electronics Introduction to Sequential Logic Circuits (aka. Finite State Machines) and FSM Analysis (Lecture #17)
ECE 331 – Digital Systems Design Introduction to Sequential Logic Circuits (aka. Finite State Machines) and FSM Analysis (Lecture #19)
SE-565 Software System Requirements More UML Diagrams.
An Introduction to Rational Rose Real-Time
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.
System Modelling and Verification
Ch.2 Part A: Requirements, State Charts EECE **** Embedded System Design.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Specifications.
Lecture 4 Finite State Machine CS6133 Software Specification and Verification.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Some general properties of languages 1. Synchronous vs. asynchronous languages.
1 COMP541 State Machines Montek Singh Feb 8, 2012.
Voicu Groza, 2008 SITE, HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 1 Hardware/Software Codesign of Embedded Systems SYSTEM MODELS Voicu Groza.
- 1 - Embedded Systems - SDL Some general properties of languages 1. Synchronous vs. asynchronous languages Description of several processes in many languages.
CS 3850 Lecture 3 The Verilog Language. 3.1 Lexical Conventions The lexical conventions are close to the programming language C++. Comments are designated.
StateCharts Peter Marwedel Informatik 12 Univ. Dortmund Germany.
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.
Problem Solving Techniques. Compiler n Is a computer program whose purpose is to take a description of a desired program coded in a programming language.
1 © 2014 B. Wilkinson Modification date: Dec Sequential Logic Circuits Previously, we described the basic building blocks of sequential circuits,
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
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.
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,
Registers; State Machines Analysis Section 7-1 Section 5-4.
Finite State Machines (FSM) OR Finite State Automation (FSA) - are models of the behaviors of a system or a complex object, with a limited number of defined.
VHDL Discussion Subprograms IAY 0600 Digital Systems Design Alexander Sudnitson Tallinn University of Technology 1.
Digital System Design using VHDL
Introduction to OOP CPS235: Introduction.
1 COMP541 Finite State Machines - 1 Montek Singh Sep 22, 2014.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CS151 Introduction to Digital Design Chapter 5: Sequential Circuits 5-1 : Sequential Circuit Definition 5-2: Latches 1Created by: Ms.Amany AlSaleh.
1 Advanced Embedded Systems Lecture 3 Specification Languages.
1 COMP541 Sequential Logic – 2: Finite State Machines Montek Singh Feb 29, 2016.
Lecture 2 Specification and Requirement Analysis of Embedded System.
From requirements to specification Specification is a refinement of requirements Can be included together as Software Requirements Specifications (SRS)
Advanced Embedded Systems
Embedded System Design Specifications and Modeling
The Von Neumann Model Basic components Instruction processing
Dynamic Modeling Lecture # 37.
Specifications and Modeling
Presentation transcript:

- 1 - Embedded Systems—State charts Specifications

- 2 - Embedded Systems—State charts Specification language for embedded systems should represent the following features: (1) Hierarchy Humans not capable to understand systems containing more than ~5 objects. Most actual systems require more objects  –Behavioral hierarchy Examples: states, processes, procedures. –Structural hierarchy Examples: processors, racks, printed circuit boards Timing behavior. State-oriented behavior Required for reactive systems; classical automata insufficient (no timing). Hierarchy Humans not capable to understand systems containing more than ~5 objects. Most actual systems require more objects  –Behavioral hierarchy Examples: states, processes, procedures. –Structural hierarchy Examples: processors, racks, printed circuit boards Timing behavior. State-oriented behavior Required for reactive systems; classical automata insufficient (no timing).

- 3 - Embedded Systems—State charts Requirements for specification techniques (2) Event-handling (external or internal events) No obstacles for efficient implementation Support for the design of dependable systems Unambiguous semantics,... Exception-oriented behavior Not acceptable to describe exceptions for every state. Event-handling (external or internal events) No obstacles for efficient implementation Support for the design of dependable systems Unambiguous semantics,... Exception-oriented behavior Not acceptable to describe exceptions for every state. We will see, how all the arrows labeled k can be replaced by a single one.. exception

- 4 - Embedded Systems—State charts Requirements for specification techniques (3) Concurrency Real-life systems are concurrent Synchronization and communication Components have to communicate! Presence of programming elements For example, arithmetic operations, loops, and function calls should be available Executability (no algebraic specification) Support for the design of large systems (  OO) Domain-specific support (control-dominated, data- dominated, centralized and distributed applications- domains) Concurrency Real-life systems are concurrent Synchronization and communication Components have to communicate! Presence of programming elements For example, arithmetic operations, loops, and function calls should be available Executability (no algebraic specification) Support for the design of large systems (  OO) Domain-specific support (control-dominated, data- dominated, centralized and distributed applications- domains)

- 5 - Embedded Systems—State charts Requirements for specification techniques (4) Readability : human, computer. Portability and flexibility Termination It should be clear, at which time all computations are completed Support for non-standard I/O devices Direct access to switches, displays,... Non-functional properties fault-tolerance, disposability, EMC-properties, weight, size, user friendliness, extendibility, expected life time, power consumption... Adequate model of computation Readability : human, computer. Portability and flexibility Termination It should be clear, at which time all computations are completed Support for non-standard I/O devices Direct access to switches, displays,... Non-functional properties fault-tolerance, disposability, EMC-properties, weight, size, user friendliness, extendibility, expected life time, power consumption... Adequate model of computation

- 6 - Embedded Systems—State charts Models of computation - Definition - Models of computation define [Lee, UCB, 1999]: What it means to be a component: Subroutine? Process? Thread? The mechanisms by which components interact: Message passing? Rendez-vous? Possibly also: What components know about each other (global variables? Implicit behavior of other components) Do not define interaction vocabulary Models of computation define [Lee, UCB, 1999]: What it means to be a component: Subroutine? Process? Thread? The mechanisms by which components interact: Message passing? Rendez-vous? Possibly also: What components know about each other (global variables? Implicit behavior of other components) Do not define interaction vocabulary

- 7 - Embedded Systems—State charts Models of computation - Examples (1) - Communicating finite state machines (CFSMs): SDL Discrete event model: VHDL, Verilog abcabc time action a:=5 b:=7 c:=8 a:=6 a:=9 queue

- 8 - Embedded Systems—State charts Models of computation - Examples (2) - Asynchronous message passing (buffer, overflow) Differential equations (analog) Synchronous message passing (rendez-vous) FIFO

- 9 - Embedded Systems—State charts StateCharts: recap of classical automata Classical automata: Moore-automata: Y = (Z); Z + =  (X, Z) Mealy-automata Y = (X, Z); Z + =  (X, Z) Moore-automata: Y = (Z); Z + =  (X, Z) Mealy-automata Y = (X, Z); Z + =  (X, Z) Internal state Z input Xoutput Y Next state Z + computed by function  Output computed by function Z0Z1 Z2Z3 e= clock Moore- + Mealy automata=finite state machines (FSMs)

Embedded Systems—State charts StateCharts Classical automata not useful for complex systems (complex graphs cannot be understood by humans).  Introduction of hierarchy  StateCharts [Harel, 1987] StateChart = the only unused combination of “flow” or “state” with “diagram” or “chart” Classical automata not useful for complex systems (complex graphs cannot be understood by humans).  Introduction of hierarchy  StateCharts [Harel, 1987] StateChart = the only unused combination of “flow” or “state” with “diagram” or “chart”

Embedded Systems—State charts Introducing hierarchy super-state S sub-states FSM will be in exactly one of the substates of S if S is active (either in A or in B or..)

Embedded Systems—State charts Modeling of Hierarchy: 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. 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. ancestor state of E

Embedded Systems—State charts Default state mechanism Filled circle indicates sub-state entered whenever super-state is entered. Not a state by itself! Allows internal structure to be hidden for outside world. Filled circle indicates sub-state entered whenever super-state is entered. Not a state by itself! Allows internal structure to be hidden for outside world.

Embedded Systems—State charts History mechanism 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. 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. (behavior different from last slide)

Embedded Systems—State charts Combining history and default state mechanism same meaning

Embedded Systems—State charts Concurrency Convenient ways of describing concurrency are required. AND-super-states: FSM is in all (immediate) sub-states of a super-state; Example: Convenient ways of describing concurrency are required. AND-super-states: FSM is in all (immediate) sub-states of a super-state; Example:

Embedded Systems—State charts Entering and leaving AND-super-states Line-monitoring and key-monitoring are entered and left, when service switch is operated. incl.

Embedded Systems—State charts Types of states In StateCharts, states are either basic states, or AND-super-states, or OR-super-states. In StateCharts, states are either basic states, or AND-super-states, or OR-super-states.

Embedded Systems—State charts Timers Since time needs to be modeled in embedded systems, timers need to be modeled. In StateCharts, special edges can be used for timeouts. 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.

Embedded Systems—State charts Using timers in answering machine

Embedded Systems—State charts General form of edge labels Events: Exist only until 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 Reactions: Can either be assignments for variables or creation of events Example: service-off [not in Lproc] / service:=0 Events: Exist only until 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 Reactions: Can either be assignments for variables or creation of events Example: service-off [not in Lproc] / service:=0 event [condition] / reaction

Embedded Systems—State charts The StateCharts simulation 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. Separation into phases 2 and 3 guarantees deterministic and reproducible behavior. 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. Separation into phases 2 and 3 guarantees deterministic and reproducible behavior.

Embedded Systems—State charts 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. The execution would be non-deterministic. 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. The execution would be non-deterministic.

Embedded Systems—State charts 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.

Embedded Systems—State charts Steps Execution of a StateChart model consists of a sequence of (status, step) pairs Status= values of all variables + set of events + current time Step = execution of the three phases Status= values of all variables + set of events + current time Step = execution of the three phases Status phase 2 phase 3 phase 1

Embedded Systems—State charts Broadcast mechanism Values of variables are visible to all parts of the StateChart model. New values become effective in phase 3 of the current step and are obtained by all parts of the model in the following step. Values of variables are visible to all parts of the StateChart model. New values become effective in phase 3 of the current step and are obtained by all parts of the model in the following step.  StateCharts implicitly assumes a broadcast mechanism for variables.  StateCharts is appropriate for local control systems ( ), but not for distributed applications for which updating variables might take some time (  ).  StateCharts implicitly assumes a broadcast mechanism for variables.  StateCharts is appropriate for local control systems ( ), but not for distributed applications for which updating variables might take some time (  ).

Embedded Systems—State charts Lifetime of events Events live until the step following the one in which they are generated (“one shot-events“).

Embedded Systems—State charts Evaluation of StateCharts (1) Pros: Hierarchy allows arbitrary nesting of AND- and OR- superstates. Semantics defined in a follow-up paper to original paper. Large number of commercial simulation tools available (StateMate, StateFlow, BetterState,...) Available “back-ends” translate StateCharts into C or VHDL, thus enabling software or hardware implementations. Pros: Hierarchy allows arbitrary nesting of AND- and OR- superstates. Semantics defined in a follow-up paper to original paper. Large number of commercial simulation tools available (StateMate, StateFlow, BetterState,...) Available “back-ends” translate StateCharts into C or VHDL, thus enabling software or hardware implementations.

Embedded Systems—State charts Evaluation of StateCharts (2) Cons: Generated C programs frequently inefficient, Not useful for distributed applications, No program constructs, No description of non-functional behavior, No object-orientation, No description of structural hierarchy. Cons: Generated C programs frequently inefficient, Not useful for distributed applications, No program constructs, No description of non-functional behavior, No object-orientation, No description of structural hierarchy. Extensions: Module charts for description of structural hierarchy. Extensions: Module charts for description of structural hierarchy.