More Efficient On-the-Fly Verification Methods of Colored Petri Nets

Colored Petri Nets (CP-nets or CPNs) are powerful modeling language for concurrent systems. As for CPNs' model checking, the mainstream method is unfolding that transforms a CPN into an equivalent P/T net. However the equivalent P/T net tends to be too enormous to be handled. As for checking CPN models without unfolding, we present three practical on-the-fly verification methods which are all focused on how to make state space generation more efficient. The first one is a basic one, based on a standard state space generation algorithm, but its efficiency is low. The second one is an overall improvement of the first. The third one sacrifices some applicability for higher efficiency. We implemented the three algorithms and validated great efficiency of latter two algorithms through experimental results

GUESSING, MODEL CHECKING AND THEOREM PROVING OF STATE MACHINE PROPERTIES – A CASE STUDY ON QLOCK

It is worth understanding state machines better because various kinds of systems can be formalized as state machines and therefore understanding state machines has something to do with comprehension of systems. Understanding state machines can be interpreted as knowing properties they enjoy and comprehension of systems is interpreted as knowing whether they satisfy requirements. We (mainly the second author) have developed a tool called SMGA that basically takes a finite sequence of states from a state machine and generates a graphical animation of the finite sequence or the state machine. Observing such a graphical animation helps us guess properties of the state machine. We should confirm whether the state machine enjoys the guessed properties because such guessed properties may not be true properties of the state machine. Model checking is one possible technique to do so. If the state machine has a fixed small number of reachable states, model checking is enough. Otherwise, however, it is not. If that is the case, we should use some other techniques to make sure that the system enjoys the guessed properties. Interactive theorem proving is one such technique. The paper reports on a case study in which a mutual exclusion protocol called Qlock is used as an example to exemplify the abovementioned idea or methodology

Parameterized Verification of Algorithms for Oblivious Robots on a Ring

We study verification problems for autonomous swarms of mobile robots that self-organize and cooperate to solve global objectives. In particular, we focus in this paper on the model proposed by Suzuki and Yamashita of anonymous robots evolving in a discrete space with a finite number of locations (here, a ring). A large number of algorithms have been proposed working for rings whose size is not a priori fixed and can be hence considered as a parameter. Handmade correctness proofs of these algorithms have been shown to be error-prone, and recent attention had been given to the application of formal methods to automatically prove those. Our work is the first to study the verification problem of such algorithms in the parameter-ized case. We show that safety and reachability problems are undecidable for robots evolving asynchronously. On the positive side, we show that safety properties are decidable in the synchronous case, as well as in the asynchronous case for a particular class of algorithms. Several properties on the protocol can be decided as well. Decision procedures rely on an encoding in Presburger arithmetics formulae that can be verified by an SMT-solver. Feasibility of our approach is demonstrated by the encoding of several case studies

A new dialect of SOFL-Syntax formal semantics and tool support

Structured Object Orientated Formal Language (SOFL) is a formal method design methodology that combines data flows diagrams and predicates in order to describe processes that can be refined. This methodology creates a very versatile method of describing a system, which system properties can be proven rigorously. Data flows are grouped by ports that define from which data flows data can be consumed or on which flows data can be generated. For predicates, Logic of Partial Functions (LFP) are used; and an undefined element that is also used to indicate if a data flows do not contain any data. Over time SOFL “evolved organically” and a number of features were added: usability was the main consideration for a feature being added. For a formal language to be useful there must be no uncertainty of a specific design’s meaning. With SOFL, there is a possible contradiction between the requirement that a process's precondition must be true when the process fire, and the fire rules. This contradiction is due to the use of LPF. Semantics (the meaning) of SOFL was not always updated to keep track of the changes made to SOFL which resulted in an outdated and incomplete semantic. The incompleteness of the semantics is a significant factor motivating the work done in this dissertation. In this dissertation, a dialect of SOFL is created to define a semantic. Not all the elements of SOFL are added in order that a simpler semantic can be defined. Elements that were removed include: LPF, Classes, and Non-deterministic broadcast nodes. Semantics of the dialect is created by a two-step process: firstly, an intuitive understanding of the dialect is created, and secondly, both static and dynamic semantics are defined by means of translations. A translation is a mapping from the dialect to a formal language that describes a certain aspect of the dialect. Static semantics defines the meaning of the elements that are “fixed” in their state: SMT-LIB is used as the target language to describe the static semantics of the dialect. Dynamic semantics describes how an element in a design changes over time: the process algebra mCRL2 is used as the formal language which describes the dynamic behaviour of the dialect. The SMT-Solver Z3 and tools included in mCLR2 are used to analyse the translation of the dialect. Use of these tools allows properties that are necessary for a design to have a well defined meaning, to be proven. Properties that can be proven include: a process can fire, a process can fire an infinite number of times, and a predicate that described a property. An Eclipse plug-in is created so that translation is not required to be done manually. After a design is translated the tools Z3 and mCRL2 are run using script files and the results of the analysis are displayed on the screen. The desired properties could be proven but for a moderate size design, but as the size of the design increased the analysis of the translation could not be completed due to computational problem. Usability of the tool can be improved by not only using a textual representation of a design, but also visual representations as in SOFL. As a result, properties that are necessary for a design to have a well-defined meaning, can be proven using these tools.Dissertation (MSc)--University of Pretoria, 2018.Computer ScienceMScUnrestricte

Mathematics in Software Reliability and Quality Assurance

This monograph concerns the mathematical aspects of software reliability and quality assurance and consists of 11 technical papers in this emerging area. Included are the latest research results related to formal methods and design, automatic software testing, software verification and validation, coalgebra theory, automata theory, hybrid system and software reliability modeling and assessment