5 research outputs found

    Liveness of Randomised Parameterised Systems under Arbitrary Schedulers (Technical Report)

    Full text link
    We consider the problem of verifying liveness for systems with a finite, but unbounded, number of processes, commonly known as parameterised systems. Typical examples of such systems include distributed protocols (e.g. for the dining philosopher problem). Unlike the case of verifying safety, proving liveness is still considered extremely challenging, especially in the presence of randomness in the system. In this paper we consider liveness under arbitrary (including unfair) schedulers, which is often considered a desirable property in the literature of self-stabilising systems. We introduce an automatic method of proving liveness for randomised parameterised systems under arbitrary schedulers. Viewing liveness as a two-player reachability game (between Scheduler and Process), our method is a CEGAR approach that synthesises a progress relation for Process that can be symbolically represented as a finite-state automaton. The method is incremental and exploits both Angluin-style L*-learning and SAT-solvers. Our experiments show that our algorithm is able to prove liveness automatically for well-known randomised distributed protocols, including Lehmann-Rabin Randomised Dining Philosopher Protocol and randomised self-stabilising protocols (such as the Israeli-Jalfon Protocol). To the best of our knowledge, this is the first fully-automatic method that can prove liveness for randomised protocols.Comment: Full version of CAV'16 pape

    Foundations of the B method

    Get PDF
    B is a method for specifying, designing and coding software systems. It is based on Zermelo-Fraenkel set theory with the axiom of choice, the concept of generalized substitution and on structuring mechanisms (machine, refinement, implementation). The concept of refinement is the key notion for developing B models of (software) systems in an incremental way. B models are accompanied by mathematical proofs that justify them. Proofs of B models convince the user (designer or specifier) that the (software) system is effectively correct. We provide a survey of the underlying logic of the B method and the semantic concepts related to the B method; we detail the B development process partially supported by the mechanical engine of the prover

    Tank monitoring: a pAMN case study

    Full text link

    Stepwise Development Of Distributed Vertex Coloring Algorithms (Full Report)

    Get PDF
    Software-based systems have a strong impact in the daily life. For instance, systems like televisions, cell phones, credit cards are used for persons, while others systems, like networks, telecommunications, distributed and embedded devices, supercomputers, are used by organisations such as companies, governments, nations... Several countries, especially the advanced ones, rely on systems for the efficiency of domains like economy, health... Since they are needed in daily life, those systems should be reliable, and their specifications and design must be clear, understandable and should follow specific rules and they must avoid faults, failures and if they can not, they should at least be fault-tolerant and fail-safe. Therefore, because of those requirements, "Formal Verification" can be usefull to obtain an assurance and guarantee of their correctness with respect to safety and security issues

    Probabilistic termination in B

    No full text
    Abstract. The B Method [1] does not currently handle probability. We add it in a limited form, concentrating on “almost-certain ” properties which hold with probability one; and we address briefly the implied modifications to the programs that support B. The Generalised Substitution Language is extended with a binary operator ⊕ representing “abstract probabilistic choice”, so that the substitution prog 1 ⊕ prog 2 means roughly “choose between prog 1 and prog 2 with some probability neither one nor zero”. We then adjust B’s proof rule for loops — specifically, the variant rule — so that in many cases it is possible to prove “probability-one ” correctness of programs containing the new operator, which was not possible in B before, while remaining almost entirely within the original Boolean logic. Applications include probabilistic algorithms such as the IEEE 1394 Root Contention Protocol (“FireWire”) [9] in which a probabilistic “symmetrybreaking” strategy forms a key component of the design.
    corecore