Table Of ContentEzio Bartocci
Yliès Falcone (Eds.)
l
a
i
r
o
t
u
T
7
5 Lectures on
4
0
1
S Runtime Verification
C
N
L
Introductory and Advanced Topics
123
Lecture Notes in Computer Science 10457
Commenced Publication in 1973
Founding and Former Series Editors:
Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen
Editorial Board
David Hutchison
Lancaster University, Lancaster, UK
Takeo Kanade
Carnegie Mellon University, Pittsburgh, PA, USA
Josef Kittler
University of Surrey, Guildford, UK
Jon M. Kleinberg
Cornell University, Ithaca, NY, USA
Friedemann Mattern
ETH Zurich, Zurich, Switzerland
John C. Mitchell
Stanford University, Stanford, CA, USA
Moni Naor
Weizmann Institute of Science, Rehovot, Israel
C. Pandu Rangan
Indian Institute of Technology, Madras, India
Bernhard Steffen
TU Dortmund University, Dortmund, Germany
Demetri Terzopoulos
University of California, Los Angeles, CA, USA
Doug Tygar
University of California, Berkeley, CA, USA
Gerhard Weikum
Max Planck Institute for Informatics, Saarbrücken, Germany
More information about this series at http://www.springer.com/series/7408
è
Ezio Bartocci Yli s Falcone (Eds.)
(cid:129)
Lectures on
fi
Runtime Veri cation
Introductory and Advanced Topics
123
Editors
EzioBartocci Yliès Falcone
TU Wien UniversitéGrenoble Alpes, Inria,
Vienna Laboratoire d’Informatique deGrenoble
Austria Grenoble
France
ISSN 0302-9743 ISSN 1611-3349 (electronic)
Lecture Notesin Computer Science
ISBN 978-3-319-75631-8 ISBN978-3-319-75632-5 (eBook)
https://doi.org/10.1007/978-3-319-75632-5
LibraryofCongressControlNumber:2018933096
LNCSSublibrary:SL2–ProgrammingandSoftwareEngineering
©SpringerInternationalPublishingAG,partofSpringerNature2018
Thisworkissubjecttocopyright.AllrightsarereservedbythePublisher,whetherthewholeorpartofthe
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storageandretrieval,electronicadaptation,computersoftware,orbysimilarordissimilarmethodologynow
knownorhereafterdeveloped.
Theuseofgeneraldescriptivenames,registerednames,trademarks,servicemarks,etc.inthispublication
doesnotimply,evenintheabsenceofaspecificstatement,thatsuchnamesareexemptfromtherelevant
protectivelawsandregulationsandthereforefreeforgeneraluse.
Thepublisher,theauthorsandtheeditorsaresafetoassumethattheadviceandinformationinthisbookare
believedtobetrueandaccurateatthedateofpublication.Neitherthepublishernortheauthorsortheeditors
give a warranty, express or implied, with respect to the material contained herein or for any errors or
omissionsthatmayhavebeenmade.Thepublisherremainsneutralwithregardtojurisdictionalclaimsin
publishedmapsandinstitutionalaffiliations.
Coverillustration:Automata-basedandrewrite-basedruntimeverification.CreatedbyYlièsFalcone.Used
withpermission.
Printedonacid-freepaper
ThisSpringerimprintispublishedbytheregisteredcompanySpringerInternational
PublishingAGpartofSpringerNature
Theregisteredcompanyaddressis:Gewerbestrasse11,6330Cham,Switzerland
Preface
Runtime verification (RV) is a lightweight, yet rigorous, formal method for the mon-
itoring and analysis of the runtime behavior of software and hardware systems. RV
complements classic exhaustive verification techniques (such as model checking and
theoremproving)withamorepracticalapproachthatanalyzesasingleexecutiontrace
of a system. At the price of a limited execution coverage, RV can give very precise
information on the runtime behavior of the monitored system. RV is now widely
employed in both academia and industry both before system deployment, for testing,
verification,anddebuggingpurposes,andafterdeploymenttoensurereliability,safety,
robustness, and security.
The interest in this field of research has grown since 2001 when the first interna-
tional workshop on RV was organized. This venue has occurred each year since then,
becomingaconferencein2010.In2014,weinitiatedtheInternationalCompetitionon
Runtime Verification (CRV) with the goal offostering the comparison and evaluation
ofsoftwareruntimeverificationtools.Inthesameyear,anEuropeanscientificnetwork
for the Cooperation in Science and Technology (COST) on “Runtime Verification
Beyond Monitoring (ARVI)” was approved and funded within the European frame-
work program Horizon 2020. ARVI currently includes the participation of scientists
from 26 European countries and Australia. In 2016, together with other partners of
ARVI, wealso started toorganizethefirst ofaseriesofschoolsonRV.Ouraimisto
train researchers from academia and industry introducing them first to the basic con-
cepts and then to the advanced topics in this exciting research area.
The idea of this volume originated from the need to have a book for students to
supporttheirtrainingwithseveraltutorialsondifferentaspectsofRV.Thevolumehas
been organized in seven chapters and the topics covered include an introduction on
runtime verification, dynamic analysis of concurrency errors, monitoring events that
carry data, runtime error reaction and prevention, monitoring of cyber-physical sys-
tems, runtime verification for decentralized and distributed systems, and an industrial
application of runtime verification techniques in financial transaction systems.
Eachpaper hasbeenreviewed bytworeviewersandtheeditors.The editors would
like to thank the reviewers: Thomas Arts, Ebru Aydin Gol, Andreas Bauer, Christian
Colombo, Raymond Hu, Jan Kofron, Zhaodan Kong, Laura Nenzi, Gordon Pace,
Rahul Purandare, Giles Reger, Oleg Sokolsky, Shmuel Ur.
November 2017 Ezio Bartocci
Yliès Falcone
Contents
Introduction to Runtime Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Ezio Bartocci, Yliès Falcone, Adrian Francalanza,
and Giles Reger
Discovering Concurrency Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
João M. Lourenço, Jan Fiedor, Bohuslav Křena,
and Tomáš Vojnar
Monitoring Events that Carry Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Klaus Havelund, Giles Reger, Daniel Thoma,
and Eugen Zălinescu
Runtime Failure Prevention and Reaction. . . . . . . . . . . . . . . . . . . . . . . . . . 103
Yliès Falcone, Leonardo Mariani, Antoine Rollet,
and Saikat Saha
Specification-Based Monitoring of Cyber-Physical Systems:
A Survey on Theory, Tools and Applications. . . . . . . . . . . . . . . . . . . . . . . 135
Ezio Bartocci, Jyotirmoy Deshmukh, Alexandre Donzé,
Georgios Fainekos, Oded Maler, Dejan Ničković,
and Sriram Sankaranarayanan
Runtime Verification for Decentralised and Distributed Systems. . . . . . . . . . 176
Adrian Francalanza, Jorge A. Pérez, and César Sánchez
Industrial Experiences with Runtime Verification of Financial
Transaction Systems: Lessons Learnt and Standing Challenges. . . . . . . . . . . 211
Christian Colombo and Gordon J. Pace
Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Introduction to Runtime Verification
Ezio Bartocci1(B), Yli`es Falcone2 , Adrian Francalanza3, and Giles Reger4
1 TU Wien, Vienna, Austria
[email protected]
2 Univ. Grenoble Alpes, Inria, CNRS, Grenoble INP,
Laboratoire d’Informatique de Grenoble, 38000 Grenoble, France
3 University of Malta, Msida MSD 2080, Malta
4 University of Manchester, Manchester, UK
Abstract. Theaimofthischapteristoactasaprimerforthosewant-
ing to learn about Runtime Verification (RV). We start by providing
an overview of the main specification languages used for RV. We then
introducethestandardterminologynecessarytodescribethemonitoring
problem, covering the pragmatic issues of monitoring and instrumenta-
tion, and discussing extensively the monitorability problem.
1 Introduction
ThefieldofRuntimeVerification(RV)hasbeen,andisstill,referredtobymany
names such as runtime monitoring, trace analysis, dynamic analysis etc. The
term verification implies a notion of correctness with respect to some property.
This is somewhat different from the term monitoring (the other popular term)
which only suggests that there is some form of behaviour being observed. Some
view the notion of monitoring as being more specific than that of verification
as they take it to imply some interaction with the system, whereas verification
is passive in nature. At this early point in this chapter we would like to note
that the community is not in agreement about the various meanings of certain
terminology, such as the difference between runtime verification and runtime
monitoring.Wetakeapopularinterpretationinthischapter,butthereaderwill
most likely encounter alternative views in the literature.
RV is a lightweight, yet rigorous, formal method that complements classical
exhaustiveverificationtechniques(suchasmodelcheckingandtheoremproving)
withamorepracticalapproachthatanalysesasingleexecutiontraceofasystem.
At the price of a limited execution coverage, RV can give very precise informa-
tion on the runtime behaviour of the monitored system. The system considered
canbeasoftwaresystem,hardwareorcyber-physicalsystem,asensornetwork,or
anysystemingeneralwhosedynamicbehaviourcanbeobserved.Thearchetypal
analysis that can be performed on runtime behaviour is to check for correctness
ofthatbehaviour.Thisisalsothemainactivityconsideredinthischapter.How-
ever, there are many other analyses (e.g., falsification analysis [22]) or activities
(e.g.,runtimeenforcement[80])thatcanbeperformed,asitwillbediscussedelse-
whereinthisbook.RVisnowwidelyemployedinbothacademiaandindustryboth
(cid:2)c SpringerInternationalPublishingAG,partofSpringerNature2018
E.BartocciandY.Falcone(Eds.):LecturesonRuntimeVerification,LNCS10457,pp.1–33,2018.
https://doi.org/10.1007/978-3-319-75632-5_1
2 E. Bartocci et al.
beforesystemdeployment,fortesting,verification,anddebuggingpurposes,and
afterdeploymenttoensurereliability,safety,robustnessandsecurity.
TheRVfieldasaself-namedcommunitygrewoutoftheRVworkshopestab-
lished in 2001, which became a conference in 2010 and occurs each year since
then. In 2014, we have initiated the international Competition on Runtime Ver-
ification (CRV) [17,23] with the aim to foster the comparison and evaluation
of software runtime verification tools. In the same year, a European scientific
network for the COoperation in Science and Technology (COST) on Runtime
Verification beyond Monitoring (ARVI) was approved and funded within the
European framework programme Horizon 2020. ARVI currently includes the
participation of scientists from 26 European countries and Australia. In 2016,
together with other partners of ARVI, we have also started to organise the first
of a series of Schools on RV.
However, it is worth noting that the research on monitoring techniques has
beenaroundforaverylongtimeanditispresentinothercommunitieswhereit
is not referred to in the same terms as it is here, even if the process is the same.
In this chapter we introduce the field of RV covering the basic concepts and
thestandardnotionsofmonitoring.Wehavenotattemptedtomakeafullsurvey
ofallrelatedwork,butwerefertothemainrelevantliterature[77,100,112,140].
When considering how to check whether the runtime behaviour of a system
conforms to some specification there are three necessary steps to be taken:
1. Specifying (Un)Desired System Behaviour. Section2 considers how system
behaviour can be abstracted in terms of events and traces and how specifica-
tion languages can be used to describe properties of such traces.
2. GeneratingaMonitorfromaSpecification.Section3considersthemonitoring
problem and various issues that must be dealt with during monitoring.
3. Connecting a Monitor to a System. Section4 considers how various instru-
mentation approaches can be used to extract the information necessary for
monitoring from a running system.
We are also interested in the question of what can and cannot be monitored;
thisisaddressedinSect.5.Eventhoughthisquestionseemsmoretheoretical,it
determineswhatsortsofpropertiescanbehandledwithruntimeverification.We
provide an overview of all the chapters of this book in Sect.6 and we conclude
in Sect.7.
2 Formal Specification of the System Behaviour
This section introduces the reader to different formal approaches to describe
the expected behaviour of a system. We start by presenting various abstrac-
tions enabling to reason about the system behaviour at different level of detail.
We then present some specification languages after having discussed first some
general properties of these formalisms.
Example 1 (Traffic Lights). Throughout this section we choose as our running
example a traffic light system. This system consists of three lights of different
Introduction to Runtime Verification 3
colors:green,red,yellow.Wethenconsiderhowtospecifytheexpectedbehaviour
of such a system using different formalisms.
2.1 The Abstract Notion of Behaviour
Whenweconsiderthebehaviourofasystemwearereferringtothewaythesys-
temchangesovertime,byupdatingsomeinternalstate,takingsomeinternalor
externalaction,oraffectingtheenvironmentinsomeway.Wetypicallydescribe
thisbehaviourintermsoftheobservationswecanmakeaboutit.Therearetwo
general kinds of observations we can make: either we inspect some snapshots of
thecurrentstate ofthesystemataparticulartime,orwerecordcertainactions
orstate changes madebythesystem(wherethesysteminquestionmayinclude
the environment). Below we describe how we will abstract systems in terms of
the observations (events) we can make about them over time (giving a trace)
and how we describe behaviour using these abstractions.
Events. We will call any kind of observation about the system an event. In
the simple case an event is a name for something that can happen, for exam-
ple lightTurnsGreen, lightBrightnessIs80 or pedestrianButtonPressed. In the more
complex case an event could be structured, containing data values of interest.
We do not cover this complex case here, but it is discussed in Chap. 3 [102].
Note that we make a distinction between events as syntactic elements and
what they denote semantically. For example, an event temperatureLimit may
correspond to a sensor detecting that the temperature is at or above 20◦C. We
separate the representation of this event and the process of recording/detecting
and reporting it (Sect.4 describes how we practically observe systems).
In this presentation events are discrete atomic entities, but there are two
alternative views that are taken in various work. Firstly, some work considers
an event as having a duration, i.e., a start and end time. This can be easily
translated into the setting where events are atomic by introducing associated
start and end events. For example, we might have the event lightGreen at one
level of abstraction, but lightGreenOn and lightGreenOff at another level of
abstraction.Secondly,inlanguages specifiedovercontinuous time eventscanbe
viewedassignals thatcanbequeriedforavalue.Wediscussthissettinginmore
detail later. Where an alternative interpretation of event is being taken we will
be explicit in the text.
We call alphabet the set of the system’s observable events of interest. We
stress of interest as there are potentially an infinite number of different ways
of describing an event, but typically we are only interested in a small (at least
usually finite) set of such events. It is clear that the choice of events is funda-
mental in how much information we have about a system and the properties
we can describe. Events can be defined at different levels of abstraction and be
related to the internal or external behaviour. They may cover the whole system
or one specific part, and may not correspond directly with existing components
or actions defined in the system. The choice of events is part of the specification
process and will depend on what the end goal is.
