What is the method in applying formal methods to PLC applications?

The question we investigate is how to obtain PLC applications with confidence in their proper functioning. Especially, we are interested in the contribution that formal methods can provide for their development. Our maxim is that the place of a particular formal method in the total picture of system development should be made very clear. Developers and customers ought to understand very well what they can rely on or not, and we see our task in trying to make this explicit. Therefore, for us the answer to the question above leads to the following questions: Which parts of the system can be treated formally? What formal methods and tools can be applied? What does their successful application tell (or does not) about the proper functioning of the whole system

Abstract State Machines 1988-1998: Commented ASM Bibliography

An annotated bibliography of papers which deal with or use Abstract State Machines (ASMs), as of January 1998.Comment: Also maintained as a BibTeX file at http://www.eecs.umich.edu/gasm

Why Just Boogie? Translating Between Intermediate Verification Languages

The verification systems Boogie and Why3 use their respective intermediate languages to generate verification conditions from high-level programs. Since the two systems support different back-end provers (such as Z3 and Alt-Ergo) and are used to encode different high-level languages (such as C# and Java), being able to translate between their intermediate languages would provide a way to reuse one system's features to verify programs meant for the other. This paper describes a translation of Boogie into WhyML (Why3's intermediate language) that preserves semantics, verifiability, and program structure to a large degree. We implemented the translation as a tool and applied it to 194 Boogie-verified programs of various sources and sizes; Why3 verified 83% of the translated programs with the same outcome as Boogie. These results indicate that the translation is often effective and practically applicable

Transforming ASN.1 Specifications into CafeOBJ to assist with Property Checking

The adoption of algebraic specification/formal method techniques by the networks' research community is happening slowly but steadily. We work towards a software environment that can translate a protocol's specification, from Abstract Syntax Notation One (ASN.1 - a very popular specification language with many applications), into the powerful algebraic specification language CafeOBJ. The resulting code can be used to check, validate and falsify critical properties of systems, at the pre-coding stage of development. In this paper, we introduce some key elements of ASN.1 and CafeOBJ and sketch some first steps towards the implementation of such a tool including a case study.Comment: 8 pages, 12 figure

A Denotational Semantics for Communicating Unstructured Code

An important property of programming language semantics is that they should be compositional. However, unstructured low-level code contains goto-like commands making it hard to define a semantics that is compositional. In this paper, we follow the ideas of Saabas and Uustalu to structure low-level code. This gives us the possibility to define a compositional denotational semantics based on least fixed points to allow for the use of inductive verification methods. We capture the semantics of communication using finite traces similar to the denotations of CSP. In addition, we examine properties of this semantics and give an example that demonstrates reasoning about communication and jumps. With this semantics, we lay the foundations for a proof calculus that captures both, the semantics of unstructured low-level code and communication.Comment: In Proceedings FESCA 2015, arXiv:1503.0437

Ten virtues of structured graphs

This paper extends the invited talk by the first author about the virtues of structured graphs. The motivation behind the talk and this paper relies on our experience on the development of ADR, a formal approach for the design of styleconformant, reconfigurable software systems. ADR is based on hierarchical graphs with interfaces and it has been conceived in the attempt of reconciling software architectures and process calculi by means of graphical methods. We have tried to write an ADR agnostic paper where we raise some drawbacks of flat, unstructured graphs for the design and analysis of software systems and we argue that hierarchical, structured graphs can alleviate such drawbacks