Programming with Lustre
|
|
- Ethelbert Gallagher
- 5 years ago
- Views:
Transcription
1 Programming with 1 Using tools This tutorial shows how to use the tool on a tiny program (the rising edge detector). You can indeed write your own program and experiment with it. 1.1 Writing the edge program is a data-flow language: each variable or expression denotes a (virtually infinite) sequence of values. As a first example, consider a sequence of Boolean value X = (X 0, X 1,..., X t,...). We whant to define, according to X, a sequence of Boolean values corresponding to the rising edges of X, i.e. such that Y t is true if and only if X t is true and X t 1 is false. Note that this definition does not hold for t 0, we must define also an initial value: by definition Y 0 is false. This specification can be easily translated in lustre: node edge(x : bool) returns (Y : bool); let Y = false -> X and not pre X; tel Write this node into a file edge.lus 1.2 Simulation The simpliest way to test/simulate a program is to use the graphical tool luciole. The arguments of the command must be: first the file name, second the node name (n.b. in general, a file may contain several nodes): luciole edge.lus edge tip: you can simply type luciole, a file/node browser will then appear to select the program. Luciole opens a simulation window (figure 1) containing a press-button for the input X, plus a label for the output Y (Booelan labels are displayed in red when the value is true, grey otherwise). Figure 1: Command : luciole edge.lus edge Clicking X makes the time pass with X = vrai. Clicking step makes the time pass with X = false. The result can be observed on the label Y. Timing diagrams (chronograms): The command Tools sim2chro 1 opens the timing-diagram displayer (figure 2). The dynamic behavior can be observed in a more convenient way. 1 Several versions may be available, typically a pure-x11 version, and a gtk-based version. They are equivalent, but may or may not work depending on the platform. 1
2 Figure 2: Chronogramme Boolean modes, auto-step vs compose : In the auto-step mode (default), clicking a Boolean input enforces the time to pass. This can be a problem, in particular for programs with several inputs (indeed, it is not the case here). The command Clocks Compose switches to the compose mode: Bolean inputs become check buttons, that can be selected/unselected without making the time pass. In this mode, it is necessary to press the Step button for enforcing the time to pass. Real-time clock: The commande Clocks Real time clock swithes to the auto-step mode: a step occurs automatically at each period of an internal clock (default 1000 ms). The period can be modified with Clocks Change period. 1.3 C code generation Step by step Compilation requires several steps. The front-end transforms a program into a Kernel program, called expanded code: lus2ec edge.lus edge This command produces the edge.ec, which, in this case, is completly similar to edge.lus. C code generation is performed by the command: ec2c edge.ec -v The argument -v is just for making the compilation verbose. Almost all the tools presented here have a -v option. The results are: a file edge.c containing the step (transition) procedure, the corresponding header file edge.h containing in particular the definition of the program internal memory (called context structure). By default, the compiler only generates this reactive kernel. The user has to write his own main loop and input/output functions to concretly run the program. However, the compiler has an option -loop that generates an extra file: ec2c edge.ec -loop -v produces (in addition to edge.h and edge.c) a file edge loop.c that contains a main procedure, with all the glue code necessary to run the program in a file-to-file manner. For simple programs (like edge) the set of file is self-containt, and an binary code can be optained using (for instance) gcc: 2
3 gcc edge.c edge loop.c -o edge This command produces an exec file edge, that reads inputs on stdin and write outputs to stdout Shortcuts A shell-script is available for combining the compilation steps: lus2c edge.lus edge combines lus2ec and ec2c. lux edge.lus edge combines lus2ec, ec2c -loop and calls gcc Running C code within luciole Using luciole for simulation programs is much more convinient than using the stdin/stdout program obtained with ec2c -loop. The compiler has an option that produce the necessary glue for running the generated C program within the graphical interface. More precisely, this code must be compiled into a dynamic linked library (instead of an executable), using (for instance) gcc. Compiling dll may be somehow tricky, and a shell-script command is provided, that does the whole job: lus2dro edge.lus edge produces a file edge.dro that can be loaded into luciole: luciole edge.dro Running a.dro file in luciole gives exactly the same simulation as running the corresponding.lus program. The difference is inside:.dro files are executed, while.lus (or more precisely,.ec ) files are interpreted. 1.4 Compilation into automata Step by step There exists a way for compiling a program into an explicit Mealy machine (i.e. automata where transitions are labelled with reactions). finite state The front-end is the same: lus2ec edge.lus edge and produces the file edge.ec. The command: ec2oc edge.ec generates the Mealy machine, in a particular format called oc, in the file edge.oc. This format can be translated into a C with the command: poc edge.oc The result is similar to the one obtained with ec2c: a code file edge.c and a header file edge.h. The poc command provides a -loop option equivalent to the one of ec2c. The full chain for optaning am executable edge is then: lus2ec edge.lus edge ec2oc edge.ec poc edge.oc -loop gcc edge.c edge loop.c -o edge 3
4 1.4.2 Shortcuts and options lus2oc edge.lus edge combines lus2ec and ec2oc. ec2oc (i.e. lus2oc) has numerous options (lus2oc -help to see them). Explaining all these options is out of the scope of this tutorial Visualization of automata with atg The interest of the automaton is not clear when the goal is just to simulate/execute the program. It is more precious when the goal is to check/analyse the behavior of the program. For small programs (and thus, hopefuly small automata), it may be very interesting to draw the corresponding automaton. We can use the tool autograph to visualize automata. Firat, use the following tool to generate the format suitable for autograph: lus2atg edge.lus edge This command produces a file edge.atg taht can loaded into autograph: atg edge.atg This command opens the graphical automaton explorer. Exloration is done with the mouse, in an intuitive clic/pull/release manner. Once fully explored, the result is the graph shown in figure 3. Figure 3: The edge automaton This figure summerizes all the possible behaviors of the program: From the initial state (double circle), if X is true, the program loops on this state, otherwise it enters the other state. The second state loops while X remains false, and when X becomes true, the output Y is emited (concretely it takes the true value), and the program returns to the initial state. 1.5 Formal verification The lustre toolset provides a tool dedicated to the formal verification of safety (invariant) properties. The user specify a set of properties that the program should satisfy, and the tool try to establish that these 4
5 properties hold for any execution of the program. The edge is very simple, and properties are likely to be trivial. The exercise is then not to find relevant properties, but rather to become familiar with the tool. We use xlesar, which is a gui above the real verification tool called lesar. First, select the file and the node to validate (button Browse ). Inputs/outputs variables are then displayed (figure 4). Figure 4: L outil xlesar The bottom part of the window is the property manager, showing the current list of properties, that allows to create New, edit Edit or remove Delete properties. The edit-property windows (figure 5) contains the name and the definition the property (left) and the verification launcher (right). Figure 5: Property editor/verifier The property must be a Boolean expression in. By default, the expression is true, which is trivially an invariant. We can try to check a less trivial property, which is informally the output cannot be true unless the input is true. This property can be formalized by stating that output implies input 5
6 is an invariant, that is, always true in any execution of the program. In syntax, this invariant is simply y => x. We can launch the verifier by pressing RUN PROOF. The result (in the dialog windows) is TRUE PROPERTY. A satisfied property: We try now to check a less trivial property, informally: output Y cannot be true twice in a row in any execution. The translation into a (expected) invariant is based in the following remarks: At the very first instant, there is nothing to check: the property cannot be violated since the past doest not exist. In any non-initial instant, if the output is true, then it must have been false just before. Finally, the invariant is: true -> (Y => not pre Y) We can then launch the verifier RUN PROOF ), and obtain (as expected) TRUE PROPERTY. Tips: select the Verbose to get informations on how the verification is performed. Try the same proof with different algorithms Enumerative, Symbolic forward, Symbolic backward etc.. Complexity of the proof: In verbose mode, one can deduce the complexity of the proof: in enumerative mode, the number of states (and transitions) is a relevant approximation of the complexity (4 and 8 in this example). in symbolic mode, the number of iterations is a good measurement (here 2 computaion steps either with forward or backward ). A false property: We now try to see what happens with a (clearly) false property, for instance: X => Y. Without options, we simply get FALSE PROPERTY. By checking first the Diagnosis option, we get a counter example, that is, a sequence of inputs that violates the invariant: DIAGNOSIS: --- TRANSITION X In this case, the sequence is of length 1: the invariant is violated from the very first instant if the input X is true. When validating a program, it often occurs that the verification fails because of a lack of precisions in the formulation of the property. For instance, it is often the case that the expected property holds almost all the time, expected in some particular situations (typically the very first instant). We can try here to precise the property by stating that, except for the initial step, X implies Y. The modified invariant is then: true -> (X => Y). Here again, the verification fails, but with a longer counter-example: DIAGNOSIS: --- TRANSITION X --- TRANSITION X 6
7 Assertions: A more general and powerful way for specifying hypothesis is to use assertions. For instance, suppose that we want to express that the property (X => Y) holds under the condition that X is false at the first instant. This hypothesis can be expressed by the invariance of the expression (not X) -> true. Select the Edit/New assertion menu, type this assertion, and run the proof. Once again it fails, with a longer counter-example: --- TRANSITION not X --- TRANSITION X --- TRANSITION X FALSE PROPERTY Indeed, the property (X => Y) is likely to be false unless stating very strong assumptions. Try for instance: X is always false X toggles (i.e. (not X) -> (X <> pre X) 7
8 2 Utilities The goal is to program a library of reusable utility operators in the file utils.lus. 2.1 Well initialized register Write and simulate a node jafter (just after): Input: x, Boolean Output: y, Boolean Function: y t true iif x t 1 exists and is true 2.2 Rising edge (strict) Write and simulate a node edge: Input: x, Boolean Output: y, Boolean Function: y t true iif x t 1 exists and is false, and x t is true Remarks: Falling edges of x are simply rising edges of x (edge(not x)). This is the strict version: if x is true initially, this is not considered as an edge. The weak version is obtained with x -> edge(x). 2.3 Two states automaton Write and simulate a node switch: Input: orig, on, off (Boolean). Output: state (Boolean). Function: output raise from false to true when on, falls from true to false when off. Behaves as state was equal to orig at the beginning. 8
9 3 Observers An observer of a property P is a program with a single Boolean output (e.g. ok) such that ok remains invariably true iff P holds. For instance: ok = (x => y); implements the property x cannot be true unless y is true too. ok = true -> (pre x => not x); implements the property x cannot be true twice in a row. Properties involving temporal intervals are useful. For instance: X must be true continuously between an occurrence of A and the next occurrence of B. X must be true at least once between an occurrence of A and the next occurrence of B. These properties are rather imprecise, more precisely: the intervals are not retriggerable, i.e. an occurrence of A between a A and the next B doest not start a new interval (similar to switch). the bounds are excluded, e.g. X must be true continuously (resp. once) between the occurrence of A excluded, and the next occurrence of B excluded. Propose an observer for those two properties, that is: once from to(x, A, B : bool) returns (ok : bool) always from to(x, A, B : bool) returns (ok : bool) 9
10 4 Car lights The goal is to write a controller of car lights. Commands are coming from a lever and buttons. Lights are side lights, low lights and high lights (figure 6). The lever can be turned left or right or pulled (and released): lever steering wheel TL TR LH Figure 6: Board control 4.1 Behaviour from the state all lights off, the user can turn left the lever and set the side lights, another turn left switches off the side lights and sets the low lights, in low or high light state, pulling the lever switches from low to high, in low or high light state, turning right switches pulling the lever switches between low and high, turning right in low/high state returns to side lights, turning right in side state returns to all lights off. 4.2 Inputs and outputs Inputs: 3 Boolean variables, TL, TR and LH, representing turn left, turn right and low/high. Outputs: 3 Boolean variables, representing the state of the lights side, low and high. 4.3 Question Write and simulate a car light controller in. 10
11 5 Car lights (extended version) We add to the specification two new lights: fog lamps are selected using a check button, and are effective only with low lights, long-range lamps are selected using a check button, and are effective only with high lights. The new inputs are FL and LRL, the new outputs are fog, long (Figure 7), plus two Boolean indicating whether fog and long-range lamps are selected. lever steering wheel TR TL LH FL LRL Figure 7: Board control 5.1 Behaviour The behaviour of lever is unchanged. Fog lamps are selected (unselected) by pressing FL. Similarly for longrange and LRL. When selected, the corresponding indicator diode is set (fog select and long select). When selected, fog lamps (resp. long-range) are actually switched on only in low mode (resp. high mode). 5.2 Question Write and simulate the extended controler. 5.3 Verification Check, using Lesar (or xlesar), the following properties: Side, low and high lights are exclusive. Fog lamps are effective only with low lights. Long-range are effective only with high lights. Remark: some assumptions will certainly be necessary, try to find a set of assertions as weak as possible. 11
LUSTRE-V4 manual (draft)
LUSTRE-V4 manual (draft) Pascal RAYMOND November 14, 2013 This document presents the tools associated to the language Lustre V4. The language itself is not presented here, see A Tutorial of Lustre 1 for
More informationThe Esterel language
Pascal Raymond, Verimag-CNRS Introduction 2 The first synchronous language (early 80 s) Gérard Berry and his team (École des Mines de Paris / INRIA Sophia-Antipolis) Imperative, sequential style (i.e.
More informationIntroduction 2 The first synchronous language (early 80 s) Gérard Berry and his team (École des Mines de Paris / INRIA Sophia-Antipolis) Imperative, s
Pascal Raymond, Verimag-CNRS Introduction 2 The first synchronous language (early 80 s) Gérard Berry and his team (École des Mines de Paris / INRIA Sophia-Antipolis) Imperative, sequential style (i.e.
More informationFormal Methods for Software Development
Formal Methods for Software Development Model Checking with Temporal Logic Wolfgang Ahrendt 21st September 2018 FMSD: Model Checking with Temporal Logic /GU 180921 1 / 37 Model Checking Check whether a
More informationA Lift Controller in Lustre. (a case study in developing a reactive system) Leszek Holenderski
Presented at 5 th Nordic Workshop on Program Correctness, Turku, Finland, October 25{28, 1993. Published in Proc. of the 5 th Nordic Workshop on Program Correctness, ed. R.J.R. Back and K. Sere, Abo Akademi
More informationIntroduction to Linear-Time Temporal Logic. CSE 814 Introduction to LTL
Introduction to Linear-Time Temporal Logic CSE 814 Introduction to LTL 1 Outline Motivation for TL in general Types of properties to be expressed in TL Structures on which LTL formulas are evaluated Syntax
More informationFormal Specification and Verification
Formal Specification and Verification Model Checking with Temporal Logic Bernhard Beckert Based on a lecture by Wolfgang Ahrendt and Reiner Hähnle at Chalmers University, Göteborg Formal Specification
More informationAXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop
AXIOMS OF AN IMPERATIVE LANGUAGE We will use the same language, with the same abstract syntax that we used for operational semantics. However, we will only be concerned with the commands, since the language
More informationMonitoring Interfaces for Faults
Monitoring Interfaces for Faults Aleksandr Zaks RV 05 - Fifth Workshop on Runtime Verification Joint work with: Amir Pnueli, Lenore Zuck Motivation Motivation Consider two components interacting with each
More informationLecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning
Lecture 1 Contracts 15-122: Principles of Imperative Computation (Fall 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,
More informationLecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning
Lecture 1 Contracts 15-122: Principles of Imperative Computation (Spring 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,
More informationIntroduction to Automata Theory. BİL405 - Automata Theory and Formal Languages 1
Introduction to Automata Theory BİL405 - Automata Theory and Formal Languages 1 Automata, Computability and Complexity Automata, Computability and Complexity are linked by the question: What are the fundamental
More informationIn Our Last Exciting Episode
In Our Last Exciting Episode #1 Lessons From Model Checking To find bugs, we need specifications What are some good specifications? To convert a program into a model, we need predicates/invariants and
More informationThe learning objectives of this chapter are the followings. At the end of this chapter, you shall
Chapter 5 Sequence diagrams In the previous chapters, we have seen different diagrams. Use case diagrams describe tasks that a system is supposed to perform. It gives high-level information about how a
More information3.7 Denotational Semantics
3.7 Denotational Semantics Denotational semantics, also known as fixed-point semantics, associates to each programming language construct a well-defined and rigorously understood mathematical object. These
More informationTemporal Logic and Timed Automata
Information Systems Analysis Temporal Logic and Timed Automata (5) UPPAAL timed automata Paweł Głuchowski, Wrocław University of Technology version 2.3 Contents of the lecture Tools for automatic verification
More informationChapter 3. Set Theory. 3.1 What is a Set?
Chapter 3 Set Theory 3.1 What is a Set? A set is a well-defined collection of objects called elements or members of the set. Here, well-defined means accurately and unambiguously stated or described. Any
More informationTesting. Lydie du Bousquet, Ioannis Parissis. TAROT Summer School July (TAROT 2009)
Testing TAROT Summer School Lustre/SCADE programs 2009 - July 6-10 Lydie du Bousquet, Ioannis Parissis 1 (TAROT 2009) Synchrone Scade/Lustre Siesta Issues 2 Synchronous / safety-critical software control/command
More informationTiming Analysis Enhancement for Synchronous Program
Timing Analysis Enhancement for Synchronous Program Extended Abstract Pascal Raymond, Claire Maiza, Catherine Parent-Vigouroux, Fabienne Carrier, and Mihail Asavoae Grenoble-Alpes University Verimag, Centre
More informationwant turn==me wait req2==0
Uppaal2k: Small Tutorial Λ 16 October 2002 1 Introduction This document is intended to be used by new comers to Uppaal and verification. Students or engineers with little background in formal methods should
More informationVerifying Safety Property of Lustre Programs: Temporal Induction
22c181: Formal Methods in Software Engineering The University of Iowa Spring 2008 Verifying Safety Property of Lustre Programs: Temporal Induction Copyright 2008 Cesare Tinelli. These notes are copyrighted
More informationEDAA40 At home exercises 1
EDAA40 At home exercises 1 1. Given, with as always the natural numbers starting at 1, let us define the following sets (with iff ): Give the number of elements in these sets as follows: 1. 23 2. 6 3.
More informationCS4215 Programming Language Implementation. Martin Henz
CS4215 Programming Language Implementation Martin Henz Thursday 26 January, 2012 2 Chapter 4 The Language simpl In this chapter, we are exting the language epl in order to provide a more powerful programming
More informationSymbolic Execution and Proof of Properties
Chapter 7 Symbolic Execution and Proof of Properties Symbolic execution builds predicates that characterize the conditions under which execution paths can be taken and the effect of the execution on program
More informationTUTORIAL: CREATING A VALIDATED CROSSROADS COMPONENT IN WCOMP
INTRODUCTION The purpose of this tutorial is to illustrate the Lecture on Verification of Component based adaptive middleware applications for IoT. The main goal is to design a validated component in WComp
More information6. Hoare Logic and Weakest Preconditions
6. Hoare Logic and Weakest Preconditions Program Verification ETH Zurich, Spring Semester 07 Alexander J. Summers 30 Program Correctness There are many notions of correctness properties for a given program
More informationVerification in Loosely Synchronous Queue-Connected Discrete Timed Automata
Verification in Loosely Synchronous Queue-Connected Discrete Timed Automata Oscar H. Ibarra, Zhe Dang and Pierluigi San Pietro Department of Computer Science University of California, Santa Barbara, CA
More informationT Reactive Systems: Kripke Structures and Automata
Tik-79.186 Reactive Systems 1 T-79.186 Reactive Systems: Kripke Structures and Automata Spring 2005, Lecture 3 January 31, 2005 Tik-79.186 Reactive Systems 2 Properties of systems invariants: the system
More informationMaterial from Recitation 1
Material from Recitation 1 Darcey Riley Frank Ferraro January 18, 2011 1 Introduction In CSC 280 we will be formalizing computation, i.e. we will be creating precise mathematical models for describing
More informationThe Lurette V2 User Guide
Unité Mixte de Recherche 5104 CNRS - INPG - UJF Centre Equation 2, avenue de VIGNATE F-38610 GIERES tel : +33 456 52 03 40 fax : +33 456 52 03 50 http://www-verimag.imag.fr Report n o TR-2004-5 Initial
More informationSCADE S E M I N A R I N S O F T W A R E E N G I N E E R I N G P R E S E N T E R A V N E R B A R R
SCADE 1 S E M I N A R I N S O F T W A R E E N G I N E E R I N G P R E S E N T E R A V N E R B A R R What is SCADE? Introduction 2 Software Critical Application Development Environment, a Lustrebased IDE
More informationApplications of Program analysis in Model-Based Design
Applications of Program analysis in Model-Based Design Prahlad Sampath (Prahlad.Sampath@mathworks.com) 2018 by The MathWorks, Inc., MATLAB, Simulink, Stateflow, are registered trademarks of The MathWorks,
More informationLecture 5: Duality Theory
Lecture 5: Duality Theory Rajat Mittal IIT Kanpur The objective of this lecture note will be to learn duality theory of linear programming. We are planning to answer following questions. What are hyperplane
More informationOverview. Discrete Event Systems - Verification of Finite Automata. What can finite automata be used for? What can finite automata be used for?
Computer Engineering and Networks Overview Discrete Event Systems - Verification of Finite Automata Lothar Thiele Introduction Binary Decision Diagrams Representation of Boolean Functions Comparing two
More informationA Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm
Appears as Technical Memo MIT/LCS/TM-590, MIT Laboratory for Computer Science, June 1999 A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm Miguel Castro and Barbara Liskov
More informationLecture Notes on Program Equivalence
Lecture Notes on Program Equivalence 15-312: Foundations of Programming Languages Frank Pfenning Lecture 24 November 30, 2004 When are two programs equal? Without much reflection one might say that two
More informationComputing intersections in a set of line segments: the Bentley-Ottmann algorithm
Computing intersections in a set of line segments: the Bentley-Ottmann algorithm Michiel Smid October 14, 2003 1 Introduction In these notes, we introduce a powerful technique for solving geometric problems.
More informationDIVERSITY TG Automatic Test Case Generation from Matlab/Simulink models. Diane Bahrami, Alain Faivre, Arnault Lapitre
DIVERSITY TG Automatic Test Case Generation from Matlab/Simulink models Diane Bahrami, Alain Faivre, Arnault Lapitre CEA, LIST, Laboratory of Model Driven Engineering for Embedded Systems (LISE), Point
More informationCS 512, Spring 2017: Take-Home End-of-Term Examination
CS 512, Spring 2017: Take-Home End-of-Term Examination Out: Tuesday, 9 May 2017, 12:00 noon Due: Wednesday, 10 May 2017, by 11:59 am Turn in your solutions electronically, as a single PDF file, by placing
More informationProgramming Languages Third Edition
Programming Languages Third Edition Chapter 12 Formal Semantics Objectives Become familiar with a sample small language for the purpose of semantic specification Understand operational semantics Understand
More informationArgos: an automaton-based synchronous language
Computer Languages 27 (2001) 61 92 www.elsevier.com/locate/complang Argos: an automaton-based synchronous language Florence Maraninchi a;, Yann Remond b a VERIMAG 1 /Institut National Polytechnique de
More informationModel-checking with the TimeLine formalism
Model-checking with the TimeLine formalism Andrea Zaccara University of Antwerp Andrea.Zaccara@student.uantwerpen.be Abstract A logical model checker can be an effective tool for verification of software
More informationDistributed Systems Programming (F21DS1) Formal Verification
Distributed Systems Programming (F21DS1) Formal Verification Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh Overview Focus on
More informationSynchronous Specification
Translation Validation for Synchronous Specification in the Signal Compiler Van-Chan Ngo Jean-Pierre Talpin Thierry Gautier INRIA Rennes, France FORTE 2015 Construct a modular translation validationbased
More informationCMSC 330: Organization of Programming Languages
CMSC 330: Organization of Programming Languages Operational Semantics CMSC 330 Summer 2018 1 Formal Semantics of a Prog. Lang. Mathematical description of the meaning of programs written in that language
More informationSoftware Engineering using Formal Methods
Software Engineering using Formal Methods Introduction to Promela Wolfgang Ahrendt 03 September 2015 SEFM: Promela /GU 150903 1 / 36 Towards Model Checking System Model Promela Program byte n = 0; active
More informationTimo Latvala. January 28, 2004
Reactive Systems: Kripke Structures and Automata Timo Latvala January 28, 2004 Reactive Systems: Kripke Structures and Automata 3-1 Properties of systems invariants: the system never reaches a bad state
More informationSpecifying circuit properties in PSL. (Some of this material is due to Cindy Eisner and Dana Fisman, with thanks) See also the Jasper PSL Quick Ref.
Specifying circuit properties in PSL (Some of this material is due to Cindy Eisner and Dana Fisman, with thanks) See also the Jasper PSL Quick Ref. Background: Model Checking property G(p -> F q) yes MC
More informationCS2 Algorithms and Data Structures Note 10. Depth-First Search and Topological Sorting
CS2 Algorithms and Data Structures Note 10 Depth-First Search and Topological Sorting In this lecture, we will analyse the running time of DFS and discuss a few applications. 10.1 A recursive implementation
More informationChapter 2 The Language PCF
Chapter 2 The Language PCF We will illustrate the various styles of semantics of programming languages with an example: the language PCF Programming language for computable functions, also called Mini-ML.
More informationAsynchronous Models. Chapter Asynchronous Processes States, Inputs, and Outputs
Chapter 3 Asynchronous Models 3.1 Asynchronous Processes Like a synchronous reactive component, an asynchronous process interacts with other processes via inputs and outputs, and maintains an internal
More informationModel Checking Revision: Model Checking for Infinite Systems Revision: Traffic Light Controller (TLC) Revision: 1.12
Model Checking mc Revision:.2 Model Checking for Infinite Systems mc 2 Revision:.2 check algorithmically temporal / sequential properties fixpoint algorithms with symbolic representations: systems are
More information10/21/2016. A Finite State Machine (FSM) Models a System. ECE 120: Introduction to Computing. An FSM Consists of Five Parts
University of Illinois at Urbana-Champaign Dept. of Electrical and Computer Engineering ECE 120: Introduction to Computing Finite State Machines (FSMs) A Finite State Machine (FSM) Models a System A model
More informationCOMPUTER SIMULATION OF COMPLEX SYSTEMS USING AUTOMATA NETWORKS K. Ming Leung
POLYTECHNIC UNIVERSITY Department of Computer and Information Science COMPUTER SIMULATION OF COMPLEX SYSTEMS USING AUTOMATA NETWORKS K. Ming Leung Abstract: Computer simulation of the dynamics of complex
More information2.8 Universal Turing Machines and the Halting Problem
2.8 Universal Turing Machines and the Halting Problem Through the hierarchy of Slide 74 we indirectly get a sense that Turing Machines are at least as computationally powerful as any other known model
More informationOverview of Timed Automata and UPPAAL
Overview of Timed Automata and UPPAAL Table of Contents Timed Automata Introduction Example The Query Language UPPAAL Introduction Example Editor Simulator Verifier Conclusions 2 Introduction to Timed
More informationfor (i=1; i<=100000; i++) { x = sqrt (y); // square root function cout << x+i << endl; }
Ex: The difference between Compiler and Interpreter The interpreter actually carries out the computations specified in the source program. In other words, the output of a compiler is a program, whereas
More informationProgram verification. Generalities about software Verification Model Checking. September 20, 2016
Program verification Generalities about software Verification Model Checking Laure Gonnord David Monniaux September 20, 2016 1 / 43 The teaching staff Laure Gonnord, associate professor, LIP laboratory,
More informationSTABILITY AND PARADOX IN ALGORITHMIC LOGIC
STABILITY AND PARADOX IN ALGORITHMIC LOGIC WAYNE AITKEN, JEFFREY A. BARRETT Abstract. Algorithmic logic is the logic of basic statements concerning algorithms and the algorithmic rules of deduction between
More informationSeminar Software Quality and Safety
Seminar Software Quality and Safety SCADE a model-driven Software Development Environment by Dominik Protte Software Engineering Group Universität Paderborn Motivation Many safety-critical components in
More informationOpenVera Assertions. March Synopsys, Inc.
OpenVera Assertions March 2003 2003 Synopsys, Inc. Introduction The amount of time and manpower that is invested in finding and removing bugs is growing faster than the investment in creating the design.
More informationIronFleet. Dmitry Bondarenko, Yixuan Chen
IronFleet Dmitry Bondarenko, Yixuan Chen A short survey How many people have the confidence that your Paxos implementation has no bug? How many people have proved that the implementation is correct? Why
More informationSome notes about Event-B and Rodin
Some notes about Event-B and Rodin Résumé This document briefly presents the language event-b and the tool Rodin. For a comprehensive presentation, refer to the event-b page http://www.event-b.org/, the
More informationProof Pearl: The Termination Analysis of Terminator
Proof Pearl: The Termination Analysis of Terminator Joe Hurd Computing Laboratory Oxford University joe.hurd@comlab.ox.ac.uk Abstract. Terminator is a static analysis tool developed by Microsoft Research
More informationPolygon Triangulation
Polygon Triangulation Definition Simple Polygons 1. A polygon is the region of a plane bounded by a finite collection of line segments forming a simple closed curve. 2. Simple closed curve means a certain
More informationLecture 1. 1 Notation
Lecture 1 (The material on mathematical logic is covered in the textbook starting with Chapter 5; however, for the first few lectures, I will be providing some required background topics and will not be
More informationCMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics
Recall Architecture of Compilers, Interpreters CMSC 330: Organization of Programming Languages Source Scanner Parser Static Analyzer Operational Semantics Intermediate Representation Front End Back End
More informationImproved BDD-based Discrete Analysis of Timed Systems
Improved BDD-based Discrete Analysis of Timed Systems Truong Khanh Nguyen 1, Jun Sun 2, Yang Liu 1, Jin Song Dong 1 and Yan Liu 1 1 School of Computing National University of Singapore 2 Information System
More informationLecture Notes on Contracts
Lecture Notes on Contracts 15-122: Principles of Imperative Computation Frank Pfenning Lecture 2 August 30, 2012 1 Introduction For an overview the course goals and the mechanics and schedule of the course,
More informationBehavioural Equivalences and Abstraction Techniques. Natalia Sidorova
Behavioural Equivalences and Abstraction Techniques Natalia Sidorova Part 1: Behavioural Equivalences p. p. The elevator example once more How to compare this elevator model with some other? The cabin
More informationDuet: Static Analysis for Unbounded Parallelism
Duet: Static Analysis for Unbounded Parallelism Azadeh Farzan and Zachary Kincaid University of Toronto Abstract. Duet is a static analysis tool for concurrent programs in which the number of executing
More informationGraphical Tool For SC Automata.
Graphical Tool For SC Automata. Honours Project: 2000 Dr. Padmanabhan Krishnan 1 Luke Haslett 1 Supervisor Abstract SC automata are a variation of timed automata which are closed under complementation.
More informationFormal Specification and Verification
Formal Specification and Verification Introduction to Promela Bernhard Beckert Based on a lecture by Wolfgang Ahrendt and Reiner Hähnle at Chalmers University, Göteborg Formal Specification and Verification:
More information(a) (4 pts) Prove that if a and b are rational, then ab is rational. Since a and b are rational they can be written as the ratio of integers a 1
CS 70 Discrete Mathematics for CS Fall 2000 Wagner MT1 Sol Solutions to Midterm 1 1. (16 pts.) Theorems and proofs (a) (4 pts) Prove that if a and b are rational, then ab is rational. Since a and b are
More informationCSC 501 Semantics of Programming Languages
CSC 501 Semantics of Programming Languages Subtitle: An Introduction to Formal Methods. Instructor: Dr. Lutz Hamel Email: hamel@cs.uri.edu Office: Tyler, Rm 251 Books There are no required books in this
More informationSoftware and Energy-aware Computing Fundamentals of static analysis of software
Software and Energy-aware Computing Fundamentals of static analysis of software John Gallagher Roskilde University ICT-Energy: Energy consumption in future ICT devices Summer School, Aalborg, Denmark,
More informationInformation Security CS526
Information Security CS 526 Topic 20: Non-interference and Nondeducibility 1 Optional Readings for This Lecture Security Policies and Security Models. J.A.Goguen and J.Meseguer. Oakland 1982 Non-deducibility
More informationAcceleration of SAT-based Iterative Property Checking
Acceleration of SAT-based Iterative Property Checking Daniel Große Rolf Drechsler Institute of Computer Science University of Bremen 28359 Bremen, Germany {grosse, drechsle}@informatik.uni-bremen.de Abstract
More informationLecture Notes on Arrays
Lecture Notes on Arrays 15-122: Principles of Imperative Computation July 2, 2013 1 Introduction So far we have seen how to process primitive data like integers in imperative programs. That is useful,
More informationSoftware Engineering using Formal Methods
Software Engineering using Formal Methods Introduction to Promela Wolfgang Ahrendt & Richard Bubel & Reiner Hähnle & Wojciech Mostowski 31 August 2011 SEFM: Promela /GU 110831 1 / 35 Towards Model Checking
More information1 Lexical Considerations
Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science 6.035, Spring 2013 Handout Decaf Language Thursday, Feb 7 The project for the course is to write a compiler
More informationCS 3512, Spring Instructor: Doug Dunham. Textbook: James L. Hein, Discrete Structures, Logic, and Computability, 3rd Ed. Jones and Barlett, 2010
CS 3512, Spring 2011 Instructor: Doug Dunham Textbook: James L. Hein, Discrete Structures, Logic, and Computability, 3rd Ed. Jones and Barlett, 2010 Prerequisites: Calc I, CS2511 Rough course outline:
More informationLecture 15 : Review DRAFT
CS/Math 240: Introduction to Discrete Mathematics 3/10/2011 Lecture 15 : Review Instructor: Dieter van Melkebeek Scribe: Dalibor Zelený DRAFT Today slectureservesasareviewofthematerialthatwillappearonyoursecondmidtermexam.
More informationLecture 6,
Lecture 6, 4.16.2009 Today: Review: Basic Set Operation: Recall the basic set operator,!. From this operator come other set quantifiers and operations:!,!,!,! \ Set difference (sometimes denoted, a minus
More informationAutomated Formal Methods for Embedded Systems
Automated Formal Methods for Embedded Systems Bernd Finkbeiner Universität des Saarlandes Reactive Systems Group 2011/02/03 Bernd Finkbeiner (UdS) Embedded Systems 2011/02/03 1 / 48 Automated Formal Methods
More informationBasic concepts. Chapter Toplevel loop
Chapter 3 Basic concepts We examine in this chapter some fundamental concepts which we will use and study in the following chapters. Some of them are specific to the interface with the Caml language (toplevel,
More informationLecture 2. The SCADE Language Data Flow Kernel. Daniel Kästner AbsInt GmbH 2012
Lecture 2 The SCADE Language Data Flow Kernel Daniel Kästner AbsInt GmbH 2012 2 Synchronous Programming Two simple ways of implementing reactive systems: Event-driven Foreach input_event
More information6.001 Notes: Section 8.1
6.001 Notes: Section 8.1 Slide 8.1.1 In this lecture we are going to introduce a new data type, specifically to deal with symbols. This may sound a bit odd, but if you step back, you may realize that everything
More informationLecture 5 - Axiomatic semantics
Program Verification March 2014 Lecture 5 - Axiomatic semantics Lecturer: Noam Rinetzky Scribes by: Nir Hemed 1.1 Axiomatic semantics The development of the theory is contributed to Robert Floyd, C.A.R
More informationProgramming Languages Fall 2013
Programming Languages Fall 2013 Lecture 3: Induction Prof. Liang Huang huang@qc.cs.cuny.edu Recursive Data Types (trees) data Ast = ANum Integer APlus Ast Ast ATimes Ast Ast eval (ANum x) = x eval (ATimes
More informationSemantics via Syntax. f (4) = if define f (x) =2 x + 55.
1 Semantics via Syntax The specification of a programming language starts with its syntax. As every programmer knows, the syntax of a language comes in the shape of a variant of a BNF (Backus-Naur Form)
More informationVCS SystemVerilog Assertions Training Exercises
VCS SystemVerilog Assertions Training Exercises LAB : SVA / VCS Overall Inline Tool Flow using checkers Goal Get Familiar with Inlined SVA Flow Location SVA/lab_ Design Traffic Light Controller Allocated
More informationHandout 9: Imperative Programs and State
06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 9: Imperative Programs and State Imperative
More informationModel checking pushdown systems
Model checking pushdown systems R. Ramanujam Institute of Mathematical Sciences, Chennai jam@imsc.res.in Update Meeting, IIT-Guwahati, 4 July 2006 p. 1 Sources of unboundedness Data manipulation: integers,
More informationFormal Methods for Software Development
Formal Methods for Software Development Verification with Spin Wolfgang Ahrendt 07 September 2018 FMSD: Spin /GU 180907 1 / 34 Spin: Previous Lecture vs. This Lecture Previous lecture Spin appeared as
More informationCantor s Diagonal Argument for Different Levels of Infinity
JANUARY 2015 1 Cantor s Diagonal Argument for Different Levels of Infinity Michael J. Neely University of Southern California http://www-bcf.usc.edu/ mjneely Abstract These notes develop the classic Cantor
More informationLecture 3: Recursion; Structural Induction
15-150 Lecture 3: Recursion; Structural Induction Lecture by Dan Licata January 24, 2012 Today, we are going to talk about one of the most important ideas in functional programming, structural recursion
More informationHomework 1 Due Tuesday, January 30, 2018 at 8pm
CSECE 374 A Spring 2018 Homework 1 Due Tuesday, January 30, 2018 at 8pm Starting with this homework, groups of up to three people can submit joint solutions. Each problem should be submitted by exactly
More informationAutomating Construction of Lexers
Automating Construction of Lexers Regular Expression to Programs Not all regular expressions are simple. How can we write a lexer for (a*b aaa)? Tokenizing aaaab Vs aaaaaa Regular Expression Finite state
More informationContents. References 43
Contents 1 Atomicity Decomposition Part 1 - Overview and Background 1 1.1 Introduction................................... 1 1.2 Overview of Atomicity Decomposition Diagram in Event-B........ 1 1.3 Event-B
More information