CSCI1600: Embedded and Real Time Software Lecture 11: Modeling IV: Concurrency Steven Reiss, Fall 2015.

Slides:



Advertisements
Similar presentations
An Introduction to Petri Nets
Advertisements

Introduction to Petri Nets Hugo Andrés López
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Petri Nets Section 2 Roohollah Abdipur.
Based on: Petri Nets and Industrial Applications: A Tutorial
6. Deadlocks 6.1 Deadlocks with Reusable and Consumable Resources
Timed Automata.
Chapter 3 Petri nets Learning objectives : Introduce Petri nets
IE 469 Manufacturing Systems
1 Concurrency Specification. 2 Outline 4 Issues in concurrent systems 4 Programming language support for concurrency 4 Concurrency analysis - A specification.
Lei Bu Petri Nets 11 Dining Philosphier 4 States , 5 transitions.
Synthesis of Embedded Software Using Free-Choice Petri Nets.
1 Introduction to Computability Theory Lecture3: Regular Expressions Prof. Amos Israeli.
10. Petri Nets Prof. O. Nierstrasz. Roadmap  Definition: —places, transitions, inputs, outputs —firing enabled transitions  Modelling: —concurrency.
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.
CP — Concurrent Programming 12. Petri Nets Prof. O. Nierstrasz Wintersemester 2005 / 2006.
1 Petri Nets H Plan: –Introduce basics of Petri Net models –Define notation and terminology used –Show examples of Petri Net models u Calaway Park model.
Modeling Worldviews Activity Scanning – Petri Nets and Event Graphs Event Scheduling – Event Graphs State Machines Process Interaction –Block Flow Diagrams.
FunState – An Internal Design Representation for Codesign A model that enables representations of different types of system components. Mixture of functional.
12/07/2007Jiacun Wang1 SE-561 Math Foundations Petri Nets - II Dr. Jiacun Wang Department of Software Engineering Monmouth University.
Software Engineering, COMP201 Slide 1 Protocol Engineering Protocol Specification using CFSM model Lecture 30.
1 Petri Nets Marco Sgroi EE249 - Fall 2001 Most slides borrowed from Luciano Lavagno’s lecture ee249 (1998)
Mata kuliah :K0362/ Matematika Diskrit Tahun :2008
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
程建群 博士(Dr. Jason Cheng) 年03月
An Introduction to Petri Nets Marjan Sirjani Formal Methods Laboratory University of Tehran.
Modeling with ordinary Petri Nets Events: Actions that take place in the system The occurrence of these events is controlled by the state of the system.
CY2003 Computer Systems Lecture 7 Petri net. © LJMU, 2004CY2003- Week 72 Overview Petri net –concepts –Petri net representation –Firing a transition –Marks.
Petri Nets Lecturer: Roohollah Abdipour. Agenda Introduction Petri Net Modelling with Petri Net Analysis of Petri net 2.
Modelling by Petri nets
CSCI1600: Embedded and Real Time Software Lecture 7: Modeling II: Discrete Systems Steven Reiss, Fall 2015.
School of Computer Science & Software Engineering
CAP 4800/CAP 5805: Computer Simulation Concepts
CSCI1600: Embedded and Real Time Software Lecture 28: Verification I Steven Reiss, Fall 2015.
1 Petri Nets Ina Koch and Monika Heiner. 2 Petri Nets(1962) Carl Adam Petri.
High Performance Embedded Computing © 2007 Elsevier Chapter 1, part 3: Embedded Computing High Performance Embedded Computing Wayne Wolf.
High Performance Embedded Computing © 2007 Elsevier Lecture 4: Models of Computation Embedded Computing Systems Mikko Lipasti, adapted from M. Schulte.
Petri-Nets and Other Models
CSCI1600: Embedded and Real Time Software Lecture 17: Concurrent Programming Steven Reiss, Fall 2015.
Technology of information systems Lecture 5 Process management.
Week 8 Computational Level
CSCI1600: Embedded and Real Time Software Lecture 10: Modeling IV: Compositions of State Machines Steven Reiss, Fall 2015.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini VIII. Specifications (II)
Advantages of FSM Their simplicity make it easy for inexperienced developers to implement with little to no extra knowledge (low entry level)
CPE555A: Real-Time Embedded Systems
Dr. Eng Amr T. Abdel-Hamid
Clockless Computing COMP
Week 8 Computational Level
CSCI1600: Embedded and Real Time Software
Concurrent Systems Modeling using Petri Nets – Part II
CAP 4800/CAP 5805: Computer Simulation Concepts
CAP 4800/CAP 5805: Computer Simulation Concepts
CSCI1600: Embedded and Real Time Software
CSCI1600: Embedded and Real Time Software
CSCI1600: Embedded and Real Time Software
CSCI1600: Embedded and Real Time Software
Introduction to Petri Nets (PNs)
CSCI1600: Embedded and Real Time Software
CSCI1600: Embedded and Real Time Software
CSCI1600: Embedded and Real Time Software
An Introduction to Petri Nets
CAP 4800/CAP 5805: Computer Simulation Concepts
Petri Net :Abstract formal model of information flow Major use:
CSCI1600: Embedded and Real Time Software
CSCI1600: Embedded and Real Time Software
CSCI1600: Embedded and Real Time Software
Petri Nets Laurie Frazier.
CSCI1600: Embedded and Real Time Software
Presentation transcript:

CSCI1600: Embedded and Real Time Software Lecture 11: Modeling IV: Concurrency Steven Reiss, Fall 2015

Statecharts  What is missing  Timing information for real time analysis  Performance evaluation  Synchronization information between tasks  How to model synchronization properties of a system  To understand what is happening  To reason about those properties  To prove theorems (e.g. no deadlock)

Petri Nets  Created in 1962 by Carl Petri  Mathematical tool for studying communication between automata  With a graphical representation  With a mathematical underpinning  Later tools (CSP, CCS, …) are more language oriented  Data flow languages are a generalization of these  Utility of Petri Nets  Modeling and studying synchronization  Modeling and studying asynchronous behaviors  Modeling and studying resource sharing

Petri Net Usage  Good fit for embedded systems  Model communciation in FSAs  Some more modern equivalents  They remain widely used  Communication protocols  Manufacturing systems  Sequence controllers  Software systems  Mathematical framework can be used for  Performance evaluation (not the best notation for this)  Scheduling problems (okay, but not preferred)  Reliability, safety, boundedness, liveness

Motivation  Transitions are as important as states  Both involve labels, actions, etc.  Represent both transitions and states as nodes  With different notations  Use arcs just to represent connections  States actually represent preconditions to a transition  Result of a transition is a set of postconditions  Represented by a state

Petri Net Components  Bipartite graph  Places  Labeled circles  Represent states  Transitions  Labeled bars  Represent transitions  Arcs  P -> T : preconditions to a transition  T -> P : postconditions to a transition  Can be integer-weighted (multiple instances of same arc)  No P -> P, T -> T arcs

Petri Net Tokens  Each place can hold 0 or more tokens  Dots in the circle  Indicate precondition is true  State is active  Mapping of places to #tokens  Is a marking

Dynamics of Petri Nets  Petri nets are interesting for their dynamic behavior  Not their static description  Tokens move around according to fixed rules  Enabling rule : when a transition can fire  Firing rule : what happens when a transition fires

Enabling Rule  A transition T is enabled if each input place P of T contains at least the number of tokens equal to the weight of the arc connecting P to T

Firing Rule  An enabled transition may or may not fire depending on the interpretation  Only one at a time, fairness, nondeterminism, priorities  The firing of an enabled transition T removes from each input place P the number of tokens equal to the weight of the directed arc from P to T  It also deposits in each output place P’ the number of tokens equal to the weight of the directed arc connecting T to P.

Petri Net Extensions  Can add negation (absence of a token)  Can limit the number of tokens on a place  Effectively an output condition on a transition  Pure : no self loops  No place is input and output of a single transition  Can always convert a Petri net into a pure one  Choosing transitions to fire  Nondeterministic, one at a time  Nondeterministic, set of non-conflicting transitions  Can add priorities

Example: Mutli-Robot System  Two robot arms can pick and place items in common workspace  Only one can access the workspace at a time  Modeling mutual exclusion  There is a buffer with limited space for products  One robots adds the the buffer  The other removes from it  Modeling producer consumer  Robots can also work outside the workspace

Robot Model  P1, P4 : Robot performing tasks outside the work space  P2, P5: Robot waiting for access to the work space  P3, P6: Robot performing task in the common workspace  P7: Mutual exclusion  P8: Empty position in buffer  P9: Full position in buffer

Example Dining Philosphers

Petri Nets Reachability  Reachability  Can a Petri net reach a specific state  What might you be interested in  Reach = there exists a sequence of firings from M 0 to M x  The set of markings reachable from M 0 is the reachability set R(M 0 )

Petri Net Properties  A Petri Net is k-bounded if the number of tokens in any place P is always <= k for every reachable marking  Why is this important  Might want different k’s for different states  A Petri Net is safe if it is 1-bounded  A Petri Net is conservative if the number of tokens is conserved  Does not require the same number of tokens all the time  Tokens have different weights in different states

Petri Net Properties  A Petri Net is live if it is deadlock free  No reachable state that has no subsequent states  But could deadlock only part of the Petri Net  From any stare reachable from M0, it is possible to fire any transition in the net  Sufficient, not necessary (why)  Can quantify various degrees of liveness

Petri Net Properties  A Petri Net is reversable if for every marking M in R(M 0 ), M 0 is reachable from M  Error recovery  Could use a different state other them M 0

Proving Properties  Petri nets are inherently finite  Construct a tree of all possible markings  Flag states that are duplicates  Can handle unbounded token counts  Use ω to represent infinity, ω + n = ω, ω – n = ω  Can detect from the tree when a count can be arbitrary – then replace with ω  Overall tree is finite

Proving Properties  Given the finite coverability tree  Proving properties is easy  Just check the property holds in each tree node  Can be done mechanically

Homework  Read 2.4