Chapter 7 Petri Nets: A Formal Language to Specify and Verify Concurrent Non-Deterministic Event Systems Didier Buchs, Stefan Klikovits, and Alban Linard Abstract The study of concurrent and parallel systems has been a challenging research domain within cyber- physical systems community. This chapter provides a pragmatic introduction to the creation and analysis of such system models using the popular Petri nets formalism. Petri nets is a formalism that convinces through its simplicity and applicability. We offer an overview of the most important Petri nets concepts, analysis techniques and model checking approaches. Finally, we show the use of so-called High-level Petri nets for the representation of complex data structures and functionality and present a novel research approach that allows the use of Petri nets inside Functional Mock-up Units and cyber-physical system models. Learning Objectives After reading this chapter, we expect you to be able to: • Use common Petri-net patterns to model concurrent processes • Understand the semantics of Petri-nets in terms of state transitions systems • Use model checking to systematically check for invariance and reachability properties of Petri-net models 7.1 Introduction Since the early days of computing the modelling and verification of programs has been an important subject. Nowadays this subject is even more vital as computers are ubiquitous in our current way of life. Computers thrive in all kinds of environments, and some of their applications are life critical. Indeed, more and more lives depend on the reliability of airborne systems, rail signalling applications and medical device software for examples. Given the importance of the matter, much effort has been invested to ensure the quality of the software. On the organisational side, project management techniques have been devised for the software development process, e.g. the RUP (Rational Unified Process) [174], the Waterfall Model [244], the Spiral Model [40], B-method [189], etc. Most recently, so-called “agile” methodologies, such as SCRUM [261], are taking over the Didier Buchs Faculty of Science, Computer Science Department, University of Geneva, Switzerland e-mail: [email protected] Stefan Klikovits Faculty of Science, Computer Science Department, University of Geneva, Switzerland e-mail: [email protected] Alban Linard Faculty of Science, Computer Science Department, University of Geneva, Switzerland e-mail: [email protected] © The Author(s) 2020 177 P. Carreira et al. (eds.), Foundations of Multi-Paradigm Modelling for Cyber-Physical Systems, https://doi.org/10.1007/978-3-030-43946-0_7 178 Didier Buchs, Stefan Klikovits, and Alban Linard industry [249]. However, software development frameworks can improve software quality only up to a certain point. In fact, they cannot offer complete guarantees for critical systems by themselves as their effectiveness is only based only on empirical evidence [249]. These approaches have the fact in common that all of them require the description of what the system does without prescribing how to do it. That description is called the specification. Depending on the development process used, the specification can be informal (e.g. SCRUM), semi-formal (e.g. RUP) or formal (e.g. B-method). Getting the specification right is paramount for the software quality. On the one hand, the specification is used to check if the development team understood the requirements (to answer the question “Are we building the right thing?”). This process is called validation. On the other hand, it is used to check if the finished software does what it was meant to do (“Are we building the thing right?”). We call this step verification. A very simple way to do verification is testing. In software testing, we use the specification to derive behaviours that we expect from the software. For each expected behaviour we write a test. A test is a procedure that exercises the software (or a part of it), and tells if the observed behaviour is as expected or not (according to the specification). Hence, a test can prove that there are errors in the software. However, proving the absence of errors is much more complicated. It implies to write a test for each possible behaviour of the software. The number of behaviours of even simple software is extremely large, meaning that testing is infeasible for proving the absence of errors. Nevertheless, there are some kinds of software that cannot afford to diverge from specification as human life or health depends on it. This need gave birth to a set of verification techniques that can guarantee the absence of errors in a given system: formal verification. Formal verification techniques, a.k.a. formal methods, can guarantee the absence of errors in a system up to its modelling. There are several formal methods ranging from theorem proving to model checking. These techniques aim to build a formal mathematical proof of the program’s correctness. This requires of course that the specification is also formally described. It further requires that the program itself has a formally specified semantics. In these sections we focus on the modelling phase and the model checking variant of formal methods. Formally modelling complex systems requires languages that are adapted to the kind of system we are interested in and also must be defined with certain structuring mechanisms. In this chapter, we will mainly describe languages that provide features related to dynamic systems and data types. For structuring mechanisms we propose to consult publications on extensions of algebraic nets such as CO-OPN [32] and LLAMAS [197]. We will not describe them further as they are not absolutely necessary for the understanding of the basic concepts behind formal methods. 7.2 Modelling Concurrency The modelling of concurrency requires specially adapted formal techniques. Among the numerous existing ones, we observe that all of them use constructs to either explicitly or implicitly describe events, states and synchronisation mechanisms. Moreover, the technique’s semantics must exhibit the various behaviours of the modelled system because parallelism and concurrency inherently introduce activity non-determinism into a system. One of the most well-known formalisms is Petri nets, which we will introduce throughout this chapter. However, it is important to understand that most of the explained principles can be translated to other kinds of models such as process algebra [207], state charts [135] and similar. In order to explain the essence of modelling with Petri nets, we use an example of a car engine throughout this paper. The system describes a very simple combustion engine consisting of foot pedal, engine, carburettor and fuel tank. The system is built from several elementary components, that are similar to automata used in some modelling tools [277]. We will see how all components are combined in a single Petri net that describes the entire system. Although we could use a model of communicating automata for such problems, the use of a Petri net makes communication between components explicit, whereas it is often implicit and hence unclear when using automata. For instance, the choice of synchronous versus asynchronous communication is a meta-property in automata, rather than an explicit choice. So, in summary, we will have the possibility to model systems with Petri nets in a condensed way. These systems will be composed of some non-deterministic entities communicating synchronously or asynchronously. 7 Petri Nets: A Formal Language to Specify and Verify Concurrent Non-Deterministic Event Systems 179 7.2.1 Petri Nets Petri nets [237] are a graphical, formal modelling language dedicated to the representation of concurrent processes, including communication and synchronisation between them. Petri nets consist of four basic concepts: places, transitions, arcs and tokens. Places (represented by circles) model processes and resource containers (such as a fuel tank) of the system, while transitions (represented by rectangles) are used to model system evolution (e.g. the starting of an engine). Places and transitions are connected by arcs. Arcs describe how many tokens (represented as large dots) are taken from a place before and how many tokens are put into a place after a transition is executed. We usually refer to these arcs as the pre- and postconditions of a transition. Tokens are used to model resources (e.g. the petrol in our example) or control (whether an engine is on or off). Note, that in classic Petri nets only one kind of token is used, meaning that the process control and the resources are both represented equally, which might be confusing for beginners. This feature however offers great flexibility and renders Petri nets a very powerful formalism. Figure 7.1 shows an example of a Petri net, that represents in a simple way the behaviour of a throttle foot pedal, engine and fuel tank within a car. It represents processes and resources as places: e.g. up, off, fuel or filled. The Petri net also contains transitions such as press, stop or empty. It can be easily observed that the amount of fuel is modelled by the number of tokens within the place fuel, but also that control of the engine is being handled by an individual token which is either in place on or off. An execution of a transition (e.g. start) will consume tokens from the precondition states (off) and produce tokens in postcondition states (i.e. on in our example). The groupings (i.e. the big frames) shown for foot pedal, fuel tank, engine and carburettor have no semantic influence on the system, but merely help system description. fuel tank up fuel off release start foot pedal empty engine press stop fill down on filled maximum carburetor Fig. 7.1: A Petri net that represents a simplified functionality of a car’s acceleration Each places contains a (positive) number of tokens (0 by default), that describes how many processes or resources are in this state.