University of Pennsylvania ScholarlyCommons

Technical Reports (CIS) Department of Computer & Information Science

January 1998

MaC: A Framework for Run-Time Correctness Assurance of Real- Time Systems

Moonjoo Kim University of Pennsylvania

Mahesh Viswanathan University of Pennsylvania

Hanene Ben-Abdallah University of Pennsylvania

Sampath Kannan University of Pennsylvania, [email protected]

Insup Lee University of Pennsylvania, [email protected]

See next page for additional authors

Follow this and additional works at: https://repository.upenn.edu/cis_reports

Recommended Citation Moonjoo Kim, Mahesh Viswanathan, Hanene Ben-Abdallah, Sampath Kannan, Insup Lee, and Oleg Sokolsky, "MaC: A Framework for Run-Time Correctness Assurance of Real-Time Systems", . January 1998.

University of Pennsylvania Department of Computer and Information Science Technical Report No. MS-CIS-98-37.

This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_reports/77 For more information, please contact [email protected]. MaC: A Framework for Run-Time Correctness Assurance of Real-Time Systems

Abstract We describe the Monitoring and Checking (MaC) framework which provides assurance on the correctness of program execution at run-time. Our approach complements the two traditional approaches for ensuring that a system is correct, namely static analysis and testing. Unlike these approaches, which try to ensure that all possible executions of the system are correct, our approach concentrates on the correctness of the current execution of the system.

The MaC architecture consists of three components: a filter, an event recognizer, and a run-time checker. The filter extracts low-level information, e.g,, values of program variables and function calls, from the system code, and sends it to the event recognizer. From this low-level information, the event recognizer detects the occurrence of "abstract" requirements–level events, and informs the run-time checker about them. The run-time checker uses these events to check that the current system execution conforms to the formal requirements specification of the system.

This paper overviews our current prototype implementation, which uses JAVA as the implementation language and our Monitoring Script language as the requirements language.

Comments University of Pennsylvania Department of Computer and Information Science Technical Report No. MS- CIS-98-37.

Author(s) Moonjoo Kim, Mahesh Viswanathan, Hanene Ben-Abdallah, Sampath Kannan, Insup Lee, and Oleg Sokolsky

This technical report is available at ScholarlyCommons: https://repository.upenn.edu/cis_reports/77

MaC A Framework for Runtime Correctness Assurance of



Systems RealTime

Mo onjo o Kim Mahesh Viswanathan

y

Hanene BenAb dallah Sampath Kannan Insup Lee and Oleg Sokolsky

Department of Computer and Information Science

University of Pennsylvania

Philadelphia PA

Jan uary

This research was supp orted in part by NSF CCR AFOSR F ARO DAAG

ARO DAAG and ONR N MURI

y

Visiting from Departement dInformatique FSEG Universite de Sfax Tunisia

Abstract

We describ e the Monitoring and Checking MaC framework which provides assur

ance on the correctness of program execution at runtime Our approach complements

is correct namely static analy the two traditional approaches for ensuring that a system

sis and testing Unlike these approaches which try to ensure that all p ossible executions

of the system are correct our approach concentrates on the correctness of the current

execution of the system

The MaC architecture consists of three comp onents a lter an event recognizer

and a runtime checker The lter extracts lowlevel information eg values of program

variables and function calls from the system co de and sends it to the event recognizer

From this lowlevel information the event recognizer detects the o ccurrence of ab

stract requirementslevel events and informs the runtime checker ab out them The

runtime checker uses these events to check that the current system execution conforms

to the formal requirements sp ecication of the system

This pap er overviews our current prototyp e implementation which uses JA VA as

the implementation language and our Monitoring Script language as the requirements

language

Contents

Intro duction

Related Research

The Monitoring and Checking MaC Paradigm

Filter

Event Recognizer

Runtime Checker

The Current MaC Prototyp e System

Event Denition Languages

Logic for Events Conditions

Primitive Event Denition Language PEDL

Event Denition Language Meta

Target System

Issues in MaC prototyp e

Naming of Monitored Variables and Execution Points

Ob ject Oriented Monitoring

Atomicity of Variable Up date Detection

Filter and Co de Instrumentation

Event recognizer

Runtime Checker

Examples

A RailRoad Crossing System

A Database Client Example

An avionics example

Conclusions and Future work

A Java implementation of Database Client

Intro duction

We develop a framework for runtime monitoring of correctness of realtime systems based

ts Computer systems are often monitored on a formal sp ecication of system requiremen

for p erformance evaluation and enhancement debugging and testing control or check of

h Recently the problem of designing monitors to check for the system correctness Sc

correctness of system implementation has received increased attention from the research

community CG SM ML Sch Such monitors can b e used to detect violations

of timing ML a logical prop erty of a program CG a constraint on a language

construct SM and so on

The reason for increased interest in correctness monitors is that it is b ecoming more

dicult to test or verify software b ecause software size is increasing and its functionality

is b ecoming more complicated The most common way to validate a software system is

testing However testing cannot b e used to guarantee that the system is errorfree since

it is infeasible to completely test the entire system due to the large numb er of p ossible

b ehaviors Also as the functionality and structure of software b ecomes complex in order to

satisfy a broad range of needs testing itself needs to b e sophisticated enough to check the

program according to diverse criteria For example for testing a numerical computation it

is enough to check output with given input However when we test a realtime application

like trac control system we also have to check the timing b ehavior

Formal vercation has b een used to increase the condence that a system will b e correct

by making sure that a design sp ecication is correct However even if a design has b een

formally veried it still do es not ensure the correctness of an implementation of the design

This is b ecause the implementation often is much more detailed and may not strictly follow

the formal design So there are p ossibilities for intro duction of errors into an implementa

tion of a design that has b een veried One way to overcome this gap b etween the design

and the implementation is to resort to testing the implementations b ehavior on a set of

input sequences derived from the sp ecication This approach however suers from the

same drawback as testing in general and do es not provide guarantees ab out the correctness

of the implementation on al l p ossible input sequences Consequently we cannot guarantee

using the two traditional metho ds prior to the execution of the system that its runtime

b ehavior will b e correct Therefore the approach of continuously monitoring a running

system has received much attention

In this pap er we describ e a framework of monitoring and checking a running system

with the aim of ensuring that it is running correctly The salient asp ect of our approach

is the use of formal requirements sp ecication to decide what prop erties to assure Since

our goal is to check an implementation against requirements sp ecication at runtime we

assume that we are given b oth requirement sp ecications and an implementation To b e

able to monitor satisfaction of requirements we have to correlate lowlevel observations with

highlevel notions used in the requirements sp ecication Therefore the primary concern

of our presentation are the following two issues

how to map highlevel abstract events that are used in a requirement sp ecication to

lowlevel activities of a running system

how to instrument co de to extract necessary lowlevel activities

The framework consists of the three phases the design phase the implementation and

instrumentation phase and the runtime phase During the design phase the requirements

on the system are sp ecied Optionally a formal system sp ecication may also b e writ

ten down and in this case we assume that verication is done to ensure that the system

sp ecication satises the requirements During the implementation phase the system is

on the requirements sp ecication and the implementation the user implemented Based

script that contains instructions for instrumenting the co de so that provides a monitoring

lowlevel information ab out program state can b e passed on to the monitor In addition it

also contains information that can b e used to pro duce an event recognizer that transforms

this lowlevel information into highlevel events

Our runtime MaC architecture consists of three comp onents lter event recognizer

and runtime checker The lter extracts lowlevel information such as values of program

variables and time when variables change their values from the running co de In order to

achieve this we instrument the co de of the system to b e monitored The lter sends this

information to an event recognizer It is the job of the event recognizer to map this low

checker level information ab out the running co de to highlevel information that the runtime

understands Based on the values of the monitored variables it receives from the lter the

event recognizer detects the o ccurrence of events that are describ ed in the requirement

sp ecication and sends them to the runtime checker

The runtime checker then checks the correctness of the system thus far according to

a requirement sp ecication of the system based on the information of events it receives

from the event recognizer and on the past history It checks the correctness of a sequence

of events seen by stepping through the requirements sp ecication and the correctness of a

numerical computation by executing a program checker BK for that function This is

one of the main advantages that our approach oers over other approaches to monitoring

it provides an integrated framework to check general requirements b oth for control o w

during execution and for numerical computation

The current prototyp e implementation of the MaC architecture monitors programs

that are in JAVA byteco de and uses a new language called MEDL which is related to

linear temp oral logic to describ e the formal requirements Although MEDL is used for

requirements sp ecication it is p ossible to use other formal languages like ACSR BGLG

temp oral logic or Petri nets by making only minor mo dications to the existing framework

The rest of the pap er is organized as follows Section summarizes related research

Section gives an overview of the MaC framework and discusses p ertinent issues Section

describ es a prototyp e implementation of the MaC framework Section discusses example

applications that illustrate the use of our framework Section summarizes the presentation

and outlines furture work

Related Research

Traditionally verication and testing have b een two approaches to trying to ensure the

correctness of a program In formal verication one describ es b oth the requirements

and the system in some formal sp ecication language and then attempts to prove that

of of satisfac the formal sp ecication of the system satises the requirements This pro

tion can either b e obtained using a mo del checker CES which exhaustively checks for

satisfaction of the requirement in all p ossible computation scenarios or using a theorem

prover Gorb OSR where one shows that the requirement is a logical consequence

of the system sp ecication However b oth mo del checking and theorem proving have lim

itations The large size of the explicit representation of the state space of most systems

severely limits the size of systems that can b e mo del checked This is a problem referred

to as the state space explosion problem Although state reduction techniques Kur and

+

symb olic approaches BCD McM have b een prop osed to overcome the state space

explosion fully describing and verifying a system is still hard Theorem provers are dicult

to use as they unlike mo del checkers require extensive user interaction during pro of con

struction In addition they suer from the fact that they cannot provide counterexamples

which show that the design is incorrect Most imp ortantly even if some design has b een

formally proved to b e correct using a mo del checker or a theorem prover it do es not mean

that the implementation is correct b ecause often the implementation has greater detail and

so is susceptible to errors not present in the design

Testing attempts to overcome these problems by dealing with the implementation di

rectly Test cases are generated rst and then the system is tested by checking sequences

of test inputs and outputs from testing However to o many test cases are needed if one

wants to detect all faults with high probabilities Thus it is dicult to use testing to ensure

the correctness of the system on all p ossible input sequences

In order to overcome the limitations of b oth verication and testing some researchers

have tried to systematically derive the implementation of the system from a formal sp eci

cation BCG Tur or generate test cases and oracles using formal sp ecication LY

JP CL However these approaches have their own limitations Implementing the

system from a formal sp ecication has problems of ineciency and incompleteness in a

sense that only skeleton co de of the system can b e generated and a human programmer

has to b e involved to complete implementation which could intro duce errors In addition

most research on testing with a formal sp ecication JP SS fo cuses on blackb ox test

ing However the correctness of reactive programs dep ends not only on the inputoutput

b ehavior but also on ongoing interaction b etween comp onents of the system

Some researchers have therefore taken the approach of continuously monitoring the

current execution of the program to ensure compliance with b ehavioral and temp oral re

quirements The b ehavioral abstraction approach to monitoring was pioneered by Bates

and Wileden BW Although their approach lacked formal foundation it provided a

solid foundation for future developments The work of DJC addresses monitoring of a

distributed busbased system based on a Petri Net sp ecication Since only the bus activity

is monitored there is no need for instrumentation of the system The authors of SS also

consider only inputoutput b ehavior of the system In our opinion instrumentation of key

p oints in the system is needed to detect violations timely and reliably without to o much

p erformance overhead In this spirit the sentry system CG observes the execution of

program and determines whether the program is b ehaving correctly with resp ect to a set

of sp ecied logical prop erties on program variables Sankar and Mandel have develop ed a

metho dology to continuously monitor an executing Ada program for sp ecication consis

tency SM The user annotates an Ada program with constructs from ANNA a formal

sp ecication language But they can check only constraints on Ada constructs such as a

subtyping for Ada typ es Mok and Liu ML prop osed an approach for monitoring the vi

olation of timing constraints written in the sp ecication language based on Realtime Logic

Their goal is to b e able to detect timing violations as early as p ossible with low overhead

They describ e how to derive a set of timing constraints for a given sp ecication so that any

violation can b e caught as so on as it happ ens by checking the constraints of such a set

Our approach do es not limit the scop e of requirements to constraints on language construct

nor fo cus on timing constraints We monitor general requirements describ ed in a formal

sp ecication In the next section we explain a runtime assurance monitoring architecture

as a solution to the ab ove limitations of prior research In LC an elab orate language

for sp ecication of monitored events based on relational algebra is prop osed The authors

distinguish b etween conditions and events as we do The goal is to minimize eects of

instrumentation on runtime p erformance and to reduce the instrumentation cost through

automated instrumentation

The Monitoring and Checking MaC Paradigm

The MaC paradigm supp orts the runtime assurance monitoring of realtime systems The

paradigm consists of three phases for system development and deployment as shown in

Figure the design implementation and runtime execution phases

The design phase In the design phase we assume that the system requirements are

formally sp ecied In this phase a system design may also b e formally sp ecied and veri

ed against its requirements sp ecication Runtime assurance monitoring in MaC can b e

applied b oth to a system with or without a formal sp ecication The requirements sp ec

ication however must b e given since it is the basis for runtime assurance A formal

sp ecication of the system may b e helpful in mapping highlevel events of the requirements

sp ecication into the lowlevel system activities However the use of formal system sp eci System Static analysis Requirement Design Specification Specification Phase

System Monitoring Implementation Implementation Script Phase

Low level Events Information Run-time Event Run-time System Filter

Phase Recognizer Checker

Figure Overview of the MaC framework

cation is not required by the MaC framework

The implementation phase In the implementation phase the co de for the system is

develop ed or derived from the design Although there has b een a progress in automating

the derivation of an implementation from a design sp ecication currently the derivation

for complex software pro duces at b est skeleton co de SGME HLNP that must b e

manually augmented to complete an implementation This gap b etween a design and an

implementation in turn creates a gap b etween requirements and an implementation The

goal of the MaC paradigm is to narrow this gap

One source of the gap is that requirements are describ ed often in terms of highlevel

events while co de uses only lowlevel state information ab out execution In the rest of

the pap er we use event to denote highlevel event and state for lowlevel state In

order to monitor and check required prop erties the two typ es of information ie events

and states need to b e related and their relations must b e sp ecied explicitly in a mon

itoring script The monitoring script describ es how events at the requirements level are

dened on the monitored states of an implementation For example in a gate controller

of a railroad crossing system the requirements may b e expressed in terms of the event

train in crossing the implementation on the other hand only represents the trains

p osition with resp ect to the crossing in terms of a metric co ordinate train position

The monitoring script in this case can dene the requirements event in terms of the value

position for example as the time instant when of the implementation variable train

position train

The monitoring script is also used to generate a lter and an event recognizer automati

cally A lter is a collection of co de fragments that is used to instrument an implementation

to monitor necessary state information at runtime and an event recognizer determines the

o ccurrences of events using the information provided by the lter We note that the moni

toring script language dep ends on b oth the requirements and the implementation languages

used

The ma jor part of a monitoring script language is to dene events There is a tradeo

b etween the expressiveness of event denitions and the runtime cost of event detection

The language can b e designed to allow very expressive event denitions so that violation of

any requirements prop erty is itself an event However the drawback of an expressive event

denition language is the cost of event detection at runtime In general as the language

b ecomes more expressive the granularity of detection needs to b e ner which incurs more

overhead in b oth time and space However if the language has limited expressiveness it

cannot dene some useful events For example if an event denition language cannot express

th th

i o ccurrence of event we cannot dene InCrossing of the train We employ a two

level approach that uses two languages PEDL and MEDL see Section PEDL ensures

that we have an ecient lter and event recognizer whereas MEDL provides expressiveness

Furthermore the implementation language sp ecics are restricted to PEDL

The runtime phase At runtime the instrumented system is executed while b eing

monitored and checked against the requirements sp ecication As Figure shows during

execution the lter sends relevant state information to the event recognizer that determines

the o ccurrence of events These events are then relayed to the runtime checker to check

adherence to the requirements Our current system is geared towards the detection of faults

It would b e desirable in future to build monitors that can steer a system to correct states

Filter

A lter is a set of program fragments that will b e inserted into the implementation to in

strument the system The essential functionality of a lter is to keep track of monitored

ob jects such as program variables and function calls and to send p ertinent state informa

tion to the event recongnizer according to the monitoring script This part of the MaC

framework dep ends on the implementation language used In addition it must resolve the

following four issues

When to instrument The lter can b e added to the implementation either statically or

dynamically Static instrumentation means inserting the lter in the implementation b efore

the system is executed whereas dynamic instrumentation involves inserting the lter in the

implementation at runtime The advantage of dynamic instrumentation is exibility for

example where and what to insert can b e determined at runtime based on the intermediate

result of the execution eg MC However it may incur extra overhead at runtime

to determine when it is safe to insert and remove lters Also it requires a complex

instrumentation mechanism In our current prototyp e describ ed in Section we use static

instrumentation

What to instrument The lter can b e inserted at the sourceco de level or the excutable

co de eg byteco de level Compared to the sourceco de level instrumentation the byteco de

level instrumentation is complicated since the byteco de of a system do es not have source

level information useful for understanding the program In addition mo difying a system at

excutableco de level requires mo dication not directly related to monitoring but necessary

to keep the format of executable co de consistent The ma jor advantage however is that

this executableco de level of instrumentation can b e applied to a broad range of target

systems b ecause executable co de is always available for running a system Esp ecially in

mobile program environments it makes much sense Mobile programs migrate in the net

work in executableco de form although we may have source co de we have to instrument

a mobile program in the eecutable co de If we have some limited sourceco de level infor

mation on the system such as meanings and names of monitored variables and functions

we can instrument the executable co de of the system without complete access to the source

co de Another advantage of the executableco de instrumentation is that low level op era

tions on executable co de can provide ner granularity of observations and reliable detection

of changes in the program state For the ab ove reasons our prototyp e instruments the

byteco de ie executable co de of the system

How to instrument Instrumentation can b e done automatically or manually With

manual instrumentation the user reads the source co de of the program then inserts lters

or prob es into the system This can b e done eciently b ecause it uses a heuristic and

domain knowledge to pinp oint where to instrument and what state information to extract

However its heuristic character may result in incompleteness For assurance monitoring

instrumentation should b e complete in the sense that it should capture all interesting infor

mation Missing information could lead to false or missed detection of faults Automatic

instrumentation determines what ltersprob es should b e inserted where in a mechanical

way based on the denition of the event and the structure of the program The weak p oint

of automatic instrumentation is that it may not b e easy to dene an event of high level

b ehavior based on low level state information

Event Recognizer

The event recognizer is the part of the monitor that detects an event from values of moni

tored variables received from the lter according to the event denition in the monitoring

script see Figure Each time it recognizes an event dened in the monitoring script the

event recognizer sends it to the runtime checker In addition to sending events the event

recognizer may also forward variables values to the runtime checker which uses them to

check certain typ es of requirements eg a function computation

While it is conceivable to merge the event recognizer with the lter separating the

two mo dules is more advantageous it shields the system execution from the overhead of

abstracting out events from lowlevel information In other words it minimizes interference

with the monitored systems execution On the other hand this architecture contains

communication overhead as the lter must send monitored variable changes to the event

recognizer Additionally implementation of the event recognizer as a mo dule separate from

the lter allows us to monitor distributed systems by having a lter in each of the mo dules

of the system communicate with the central event recognizer

Runtime Checker

The runtime checker checks that the execution thus far b elongs in a set of all acceptable

b ehaviors as dened by the requirements sp ecication The nature of this set determines

the kind of assurance we may have ab out the correctness of the system For example if the

set of acceptable b ehaviors is a set of traces then all we can say ab out an execution that

is passed by the runtime checker is that the sequence of events seen is correct Another

p ossibility is to have the set of acceptable b ehaviors to b e a set of timed traces In this case

it is p ossible to ensure not only the correctness of the system but also its timing prop erties

In Section when we discuss the requirements sp ecication language MEDL we will

formally dene the notion of a valid trace The Trace Validity Problem is a memb ership

checking problem to determine if a given trace is in the set of valid traces For suciently

expressive requirements sp ecication languages such as a pro cess algebra like ACSR this

problem turns out to b e NPcomplete Thus care should b e taken in dening this language

to make it expressive enough while still leading to a tractable trace validity problem We

show that for MEDL the trace validity problem can b e eciently solved

The monitor can provide several kinds of formal guarantees of the system correctness

If all the checking that is required is the validity of a trace in MEDL then the monitor

absolutely guarantees that the system b ehavior so far is correct If the program uses nu

merical functions the correctness of whose outputs is checked using the program checking

paradigm then the guarantees on system b ehavior so far will b e probabilistic However

the probability that the guarantee is incorrect can b e made as small as we need There

is a p ossibility that monitoring of a running systems b ehavior over suciently long inter

vals will allow us to provide statistical guarantees on the system itself and not just on its

b ehavior This is a direction that we will explore in the future

Another issue is unexpected events Unexp ected events are events which are not de

scrib ed in the requirements sp ecication and thus not detected by the event recognizer If

an unexp ected event happ ens at runtime the monitor may not see this event and conse

quently can make a wrong conclusion on the current execution of the system For example

let us assume that a requirements sp ecication do es not sp ecify an event caused by arith

metic exception such as division by zero When arithmetic exception happ ens at runtime

which may lead to the system crash the monitor might not detect that the current execu

tion is incorrect b ecause it do es not receive an event of arithmetic exception since it is not

dened in the sp ecication Currently we do not handle unexp ected events ie we assume

that unexp ected events do not happ en or these events do not inuence the correct execution

of the system However these have to b e considered for providing complete guarantees

The Current MaC Prototyp e System

To evaluate the eectiveness of the MaC framework we are developing a prototyp e system

whose overall structure is shown in Figure In this section we rst describ e our event

denition language in which monitored prop erties are written Then we explain the target

system to b e monitored in the prototyp e and discuss three design issues related to the

implementation of the prototyp e Finally we discuss the lter the event recognizer and the

runtime checker of the MaC prototyp e

Informal Requirement Specification Monitoring Script

Program(Java Source code) Human -Monitored Variable Declaration Human - Monitored Method Declaration

- Event Definition Program(Java Bytecode) Requirement Specification

Filter Generator(Java program - Functional Specification -Temporal Specification using JTREK library)

low level information Event Recognizer events Instrumented Program(Bytecode) (Java program) Run-time Checker

Legend

Input/Output Process Dependency Run-time communication

Figure The overall structure of the MaC prototyp e system

Event Denition Languages

In this section we give a brief overview of the languages used in the current implementation

of MaC to describ e what to observe in the program and the requirements that the program

must satisfy The scripts written in these languages are then used to generate the event

recognizer and the runtime checker automatically

The monitor observes a trace of the current execution of a program and checks that

it satises the requirements We distinguish b etween two kinds of data that make up the

trace of an execution things that are true at some instant during the execution which we

call events and facts that hold for a longer duration of time which are called conditions

o ccurs only at the instant when the For example the return from the metho d RaiseGate

control returns from the metho d while a b o olean condition like position holds as

long as the variable position do esnt change its value from Hence in the monitoring

script language PEDL section and the requirements sp ecication language MEDL

section we reason explicitly ab out b oth events and conditions The distinction b etween

events and conditions is imp ortant in terms of what the checker can infer ab out the execution

based on the information received from the event recognizer The checker assumes that truth

values of all conditions remains unchanged b etween up dates from the event recognizer For

events the checker makes the dual assumption namely that no events of interest happ en

b etween up dates

Based on this distinction b etween events and conditions we describ e a simple twosorted

logic that denes the various op erations on events and conditions PEDL and MEDL are

subsets of this logic with added denitions of primitive events and conditions

Logic for Events Conditions

Syntax We assume a countable set C fc c g of primitive conditions For example

1 2

in the monitoring script language Section these primitive conditions will b e Java

b o olean expressions built from the values of the monitored variables In the requirements

description language Section these will b e conditions that were recognized by the event

recognizer and sent to the runtime checker

We also assume a countable set E fe e g of primitive events When an event

1 2

o ccurs to b e dened formally later it can have an attribute value which is an element of

a set D For example StartMRaiseGate is a primitive event in the monitoring script

e

i

language which is present at the start of metho d RaiseGate and whose attribute value is

the tuple of values of all the parameters with which this metho d is called The primitive

events in the requirements description language are those that are rep orted by the event

recognizer

The logic has two sorts conditions and events The syntax of conditions C and events

E is as follows

C i c j hE i hE i j hC i j hC i hC i j hC i jj hC i j hC i hC i h

hE i e j start hC i j end hC i j hE i hE i j hE i jj hE i j hE i when hC i

Semantics The mo dels for this logic are sequences of worlds similar to those used for

linear temp oral logic Each world has a description of the truth values of primitive conditions

and o ccurrences of promitive events More formally a mo del M is a tuple S L L

C E

s g is a mapping from S to the time domain which could b e integers where S fs

0 1

rationals or reals L is a total function from S C to ftrue false g and L is a partial

C E

function from S E to D Intuitively L assigns to each state the truth values of all the

e C

primitive conditions Similarly in each state s L s e is dened for each event e that

E

o ccurs at s and gives the value of the primitive event e The mapping denes the time at

each state and it satises the requirement that s s for all i j ie the time at

i j

a later state is greater

We now dene what we mean by a condition c b eing true in mo del M at time t M t j c

and an event e o ccurring in a mo del M at time t M t j e The formal semantics of the

logic is given in Figure The lab els on states dene the truth value of primitive events

and conditions The semantics for negation c conjunction c c disjunction c jjc

1 2 1 2

and implication c c of conditions is dened naturally so c is true when c is false

1 2

M t j c c primitive i there exists state s such that s t and L s c true and

k i i k k i C

for all states s if s s t then L s c is true

j i j C j k

ie c is true at time t if its last assigned value was true

k

0

M t j e e i there exists t t such that M t j e and for all t t t

1 2 0 0 1 0

0

M t j e ie it is true since event e until event e

2 1 2

M t jc i M t j c

M t j c jjc i M t j c or M t j c

1 2 1 2

M t j c c i M t j c and M j c

1 2 1 t 2

M t j c c i M t j c or M t j c

1 2 1 2

M t j e e primitive i there exists state s such that s t and L s e is dened

k k i i E i k

M t j startc i s such that s t and M s j c and M s j c

i i i i1

ie startc o ccurs when condition c changes from false to true

M t j endc i s such that s t and M s j c and M s j c

i i i i1

ie endc o ccurs when condition c changes from true to false

M t j e jje i M t j e or M t j e

1 2 1 2

M t j e e i M t j e and M t j e

1 2 1 2

M t j e when c i M t j e and M t j c

ie event e o ccurs when condition c is true

Figure Semantics of events and conditions

c c is true only when b oth c and c are true c jjc is true when either c or c is true

1 2 1 2 1 2 1 2

and c c is true if c is true whenever c is true Conjunction e e and disjunction

1 2 2 1 1 2

e jje on events is dened similarly Now since conditions are true from some time until

1 2

just b efore the instant when they b ecome false two events can naturally b e asso ciated with

a condition namely the instant when the condition b ecomes true startc and the instant

when the condition b ecomes false endc Any pair of events dene an interval of time

and forms a condition e e that is true from event e until e Finally the event e when

1 2 1 2

c is true if e o ccurs and condition c is true at that time instant

Notice that some natural equivalences that one might exp ect hold in this logic For

star tc endc This allows one to identify conditions example for any condition c c

with pairs of events and is the reason why the languages in the MaC framework are called

event denition languages Also for conditions c and c and event e e when c when

1 2 1

c e when c c

2 1 2

Primitiv e Event Denition Language PEDL

The monitoring script in the prototyp e implementation is written in a language called

Primitive Event Denition Language or PEDL for short As stated earlier PEDL is based

on the logic for events and conditions describ ed in Section There are two underlying

principles on which the design of this language is based First we would like to limit

all the implementation sp ecic details of the monitoring pro cess to this language Hence

primitive events and conditions dened in terms of metho ds and ob jects are present only in

the monitoring script requirement sp ecication makes no references to metho ds and ob jects

of the program Second we would like the pro cess of recognizing highlevel events to b e

simple ie events should b e reconized based only on the current state of the program Thus

in this language we do not have logical op erators that help reason ab out state sequences

so the op eration on events is not present in this language Since it reasons only ab out

the current state we call it primitive

Structure of a PEDL script The BNF grammar for PEDL is given in Figure Every

PEDL script has an identier MonScrID which is the name of the script This is

followed by the lists of events and conditions that are exp orted ie the events and

conditions whose truth and falsity is rep orted by the event recognizer to the checker The

monitored ob jects of the program are declared after the MonitoredObjects keyword and

keyword Events the metho ds under observation are declared after the MonitoredMethods

and conditions are dened after this As stated earlier they are built up from expressions

over the monitored ob ject and metho ds The script ends with the keyword End

Monitored Entities The user should b e able to reason ab out any program ob ject that

holds a value and thus forms a part of the program state and any event that the program can

engage in The former include individual variables and comp osite data structures ob jects

in Java The latter at least for Java programs includes only metho d calls and returns

which also captures other activities such as pro cess creation and communication

A PEDL script contains the names of all ob jects metho ds and lo cal variables of metho ds

in the program that need to b e monitored The naming follows the standard Java convention

of using to move down in the classob ject hierarchy When naming metho ds we require

that the typ es of the arguments b e sp ecied This is to help distinguish b etween overloaded

metho d names Lo cal variables are referred to by the name of the metho d followed by

and the name of the variable

Note that lo cal variables in dierent invo cations of a metho d corresp ond to dierent

entities and so must b e distinguished during recursive metho d invo cations However this

requires the maintenance of an exp ensive stack at the event recognizer to keep track of the

dierent values of the lo cal variable Hence the default is not to distinguish b etween values

of lo cal variables across metho d invo cations But if the user desires to distinguish b etween

Monitoring Script Declaration

MonScr MonScrIDEventDclCondDclM onOb jDcl MonScr

MonMethDclEventDefCondDef End

Event Declarations

EventDcl export event EventDcl

EventDcl EventID EventDcl

Condition Declarations

CondDcl export condition CondDcl

CondDcl CondID CondDcl

Monitored Object Declaration

MonObjDcl MonitoredObjects MonObjDcl

Variable Variable T Object Object MonObjDcl T

MonObjDcl MonObjDcl

Variable Object Class are Java identifiers for variable object and class

Monitored Method Declaration

MonMethDcl MonitoredMethods MonMethDcl

MonMethDcl T Method T Method

Method is a Java method name along with types of parameters

Event Definitions

EventDef EventDef EventDef

EventDef EventDef Event EventID EventExp

EventExp SimpleEE EventExp EventOp EventExp EventExp when CondExp

Condition Definitions

CondDef CondDef CondDef

CondDef Condition CondID CondExp CondDef

CondExp SimpleCE CondExp CondOp CondExp

Preliminary Nonterminals

SimpleEE start CondExp end CondExp Update Variable StartM Method

EndM Method IoM Method

SimpleCE BooleanExp InM Method

BooleanExp Java Boolean Expression Exp CompOp Exp

BooleanExp BoolOp BooleanExp

Exp time EventExp value EventExp int

any Java expression built from monitored objects methods

EventOp

CondOp

BoolOp

CompOp

Figure BNF Grammar for PEDL

these values then he can app end a after the name of the lo cal variable and this ensures

that during recursive calls the lo cal variable values are dierentiated This actually in a

backhanded way allows the user to reason ab out the trace itself in the event recognizer

The reason we allow it is b ecause we want all program sp ecic information to b e limited to

the PEDL script

Also since the lter must rep ort all changes to monitored variables it must also do so

when a monitored ob ject is changed under an alias For example if a monitored ob ject a

and another ob ject b refer to the same ob ject at runtime then b also b ecomes monitored

However to detect such aliasing requires the lter to do exp ense b o ok keeping at runtime

So once again the default is to only detect changes to ob jects made under the monitored

names The user can however force the lter to detect changes made through aliases by

app ending a to the name of the ob ject

Events The primitive events in PEDL corresp ond to instants in the execution Dening

when control is transfered to and from a metho d or when a monitored variable is assigned

a value not necessarily a new one The following primitive events in PEDL corresp ond

these situations

The event updatex is triggered when the variableob ject x is assigned a new value

The value asso ciated with this event is the new value of x StartMf is triggered when

metho d f starts executing and EndMf is triggered when control returns from metho d f

The value asso ciated with StartM is the tuple containing the values of all arguments The

value of an event EndM is a tuple that has the return value of the metho d along with the

values of all the formal parameters at the time control returns from the metho d Besides

these three we have one other primitive event which is IoMf This is also triggered when

control returns from a metho d f but has as its value a tuple that contains the return value

of the metho d and the values of the arguments at the time of method invocation This event

allows one to lo ok at the inputoutput b ehavior of a metho d and is needed if one wants

to program check some numerical computation Notice once again that this event IoMf

violates our second design principle which is to limit the reasoning at the event recognizer

to b e based only the values of the variables at the current state IoM and lo cal variables see

paragraph on Monitored Entities are the only exceptions to the second design principle

and are present in PEDL only b ecause these are program sp ecic

All the op erations for events describ ed in the logic can b e used to construct more

complex events from these primitive events In PEDL we also have two predicates time

and value dened on events timee and valuee give the time and value asso ciated

with the last o ccurrence of event e resp ectively Now as we saw in the discussion on

the primitive events in PEDL most of the events have a tuple of values asso ciated with

them ie valuee is a tuple Individual elements of the tuple can then b e obtained via

a pro jection op eration We therefore overload the name valueen which gives the nth

element of the tuple valuee

Dening Conditions Primitive conditions in PEDL are formed by b o oleanvalued ex

pressions over the monitored variables In addition to these we have another primitive

condition InMf This condition is true as along as the execution is currently within

metho d f Notice that if there is no recursion then InMf is the same as StartMf

EndMf However if f is a recursive metho d then InMf is true from the start of

the rst invo cation till the end of the last invo cation and hence is not equivalent to

StartMf EndMf While this is a desirable equivalence we found that in most prac

tical situations dened the way we have in this do cument is a more useful op eration

on events Thus we have a sp ecial primitive condition InM in PEDL

Complex conditions are built from the primitive conditions using b o olean connectives

Pairing events ie op eration to dene conditions is not allowed in PEDL

Meta Event Denition Language

The safety requirements that need to b e monitored are written in a language called Meta

Event Denition Language or MEDL Like PEDL MEDL is also based on the logic for

events and conditions describ ed in section Events and conditions in MEDL are built

up from the events and conditions dened in PEDL hence the language has the adjective

meta MEDL also has auxilliary variables that may b e used to record certain asp ects of

the current trace that cannot b e describ ed using the connectives of the logic

Structure of MEDL script The structure of a MEDL script is shown in Figure

The list of Once again there is a name asso ciated with the MEDL script ReqSpecID

events and conditions the checker exp ects the event recognizer to inform it ab out is then

imp orted in EventDcl and CondDcl The auxilliary variables are declared after the

keyword AuxilliaryVariables These auxilliary variables may b e used to store certain

asp ects of the current trace and their typ e must b e one of the primitive Java typ es The

events are conditions dened after EventDef and CondDef are events and conditions that

are used to dene the safety prop erties The prop erties that the program needs to satisfy

is sp ecied after this The alarms are dened after the keyword Alarms Finally the rules

for manipulation of auxiliary variables is given The termination of the script is indicated

by End

Auxilliary V ariables The logic describ ed is section has a limited expressive p ower

For example using the logical connectives describ ed one cannot count the numb er of o c

curences of an event or talk ab out the ith o ccurrence of an event For this purp ose MEDL

allows the user to dene auxilliary variables whose values may then b e used is dening

events and conditions These auxilliary variables however must b e of one of the basic

typ es in Java The up date rules for these auxilliary variables take the form of guarded

commands The antecedent of these guarded commands are events while the consequent

Requirement Script Declaration

ReqSpec ReqSpec ReqSpecID EventDcl CondDcl

EventDef CondDef AuxVarDcl

SafePropDef AlarmDef AuxVarDef End

Event Declaration

EventDcl import event EventDcl

EventDcl EventID EventDcl

Condition Declaration

CondDcl import condition CondDcl

CondDcl CondID CondDcl

Auxiliary Variable Declaraction

AuxVarDcl AuxilliaryVariables AuxVarDcl

AuxVarDcl T Id Id AuxVarDcl

Event Definitions

EventDef EventDef EventDef

EventDef Event EventID EventExp EventDef

Condition Definitions

CondDef CondDef CondDef

CondDef Condition CondID CondExp CondDef

Safety Property Definitions

SafePropDef SafetyProperties property SafePropID CondExp

Alarm Definitions

AlarmDef Alarms alarm AlarmID EventExp

Auxiliary Variable Definitions

AuxVarDef AuxVarDef EventExp Update

Update AuxVarT ExpT Update

Preliminary Nonterminals

EventExp SimpleEE EventExp EventOp EventExp EventExp when CondExp

SimpleEE start CondExp end CondExp

CondExp SimpleCE CondExp CondOp CondExp

SimpleCE BooleanExp EventExp EventExp

BooleanExp Java Boolean Expression Exp CompOp Exp

BooleanExp BoolOp BooleanExp

Exp time EventExp value EventExp int

any Java expression built from monitored objects methods

EventOp

CondOp

BoolOp

CompOp

Figure BNF grammar for MEDL

is a rule for up dation For example RaisingGate t time RaisingGate says that

when the event RaisingGate happ ens we set the auxilliary variable t to the time of this

event Up dates to auxilliary variables take place after the truth value of all events and

conditions has b een determined This means that if an event or condition is dened using

an auxilliary variable then the old value or the value computed in the previous state is

used to determine o ccurrence of the event

Dening events and conditions The primitive events and conditions in MEDL are

those that are dened in PEDL Besides these primitive conditions can also b e dened

using b o olean expressions using the auxilliary variables Complex events and conditions

are built up using the connectives of the logic describ ed in section These events and

conditions are then used to dene the safety prop erties and alarms

Safety Prop erties and Alarms The correctness of the system is describ ed in terms

safety prop erties and alarms Safety prop erties are conditions that must always b e true

during the execution Alarms on the other hand are events that must never b e raised

Note that all safety prop erties MP can b e describ ed in this way Also observe that

alarms and safety prop erties are complementary ways of expressing requirement Indeed

the event corresp onding to the safety prop erty condition changing state from false to true

is an alarm The reason we have b oth of them is for the convenience of the user b ecause

some prop erties are easier to think of in terms of conditions while others are easier to think

of in terms of alarms

Target System

As discussed at section our monitoring approach is dierent from similar approaches

in the way instrumentation is done The dierence is twofold First we instrument a low

level co de directly rather than instrument high level co de and recompile it Second we

instrument a program so that we can monitor variables continuously without missing any

up dates of the variables To supp ort the ab ove features we chose Java byteco de as the

target implementation for monitored system monitoring

The choice of Java byteco de for inmplementation do es not commit us to Java as high

level implementation language Java byteco de for Java is like assembler co de for

As assembler co de can b e generated from any highlevel languages including CC

CC Java byteco de can b e generated from many highlevel languages We use the term

class le indicating a le which contains a program written in Java byteco de

The rationale of selecting target system written in Java byteco de is as follows First a

class le contains rich symb olic information of a program in constant p o ol which contains

all class names metho d and eld typ e and name exception names and ranges and typ e

information LY Given a monitoring script we can automatically instrument a class le

with help of the information Second Java byteco de prohibits using p ointers and is strongly

typ ed A program written in Java byteco de makes it easier to monitor program variables

continuously than a program compiled from other conventional languages like CC Let

us see this through example Supp ose we want to monitor integer variable x in main

void main

int x

int px x

int px px

long px px

x x

px x

int px x

int px x

gpx x

As you see x can b e up dated directly by variable name x or indirectly by p ointer px

Even x can b e up dated through normal variable px of typ e int and px of typ e long In

order to monitor one variable we have to keep watching all other variables which can b e

converted to p ointer typ e in general It causes heavy overhead at runtime Furthermore

p ointer of x can b e passed to another function g Although x is a variable declared in

main we have to keep track of execution of function g to o

Java byteco de do es not use p ointers to primitive typ es It makes monitoring of accessing

to variables of primitive typ e easy Lo cal variable x of primitive typ e can b e up dated

only through the name x and only inside of the metho d where its declared For global

variableeld variable x of primitive typ e can b e up dated only through the name x and

by metho ds which can access x following access mo dier of x Monitoring variables of a

nonprimitive typ e class typ e is more complex than monitoring variables of primitive typ e

b ecause Java byteco de uses reference typ e for handling ob jects Still strong typing system

of Java byteco de makes monitoring nonprimitive typ e easier than CC we will discuss

it at section

As Java gains p opularity more systems will b e implemented in Java In addition

there are many highlevel languages such as Ada and Lisp that can b e compiled into Java

byteco de Tol making use of platformneutral and welldesigned structure of Java byteco de

Thus cho osing target system written in Java byteco de allows us to apply our metho dology

to a wide variety of systems

Issues in MaC prototyp e

MaC prototyp e monitors a prop erty which is a comp osition of assertions of the form thread

T up dates object O to value V using method M we can omit references to the thread

the metho d or the value of the ob ject from the assertion when they are irrelevant The

comp osition can b e done by temp oral b o olean conditional op erators MaC prototyp e can

monitor wellknown prop erties including safety temp oral and faulttolerance prop erties

see Section For example in a railroad crossing sp ecication we can describ e a safety

up dates train x to prop erty as when a train reaches a crossing ie a thread Train

using metho d running the gate must b e down ie thread Gate has nished metho d

gd

For monitoring a prop erty a target system should b e instrumented in such a way that

information ab out threads values of ob jects and metho d invo cations can b e correctly ex

tracted and passed to the monitor see Section for more detail Thus main design issues

are

how to describ e entities ie threads ob jects values and metho ds of an assertion in

the monitoring script

how to recognize the entities during the execution of the target system

how to implement a correct mechanism for the recognition

All the three issues are closely related to the language of target system Below we discuss

each issue in detail

of Monitored Variables and Execution Points Naming

When we sp ecify variables to b e monitored we have to identify the variable by its name

1

and its static and dynamic environment explicitly Because we want to monitor not only

class elds but also lo cal variables in a metho d the ob ject naming scheme includes metho d

names as well as ob ject names First consider an example

Double linked list

class A

int x

A next before

x Aint x thisx

1

We do not consider inner classes here

public static void mainString args

A a new A a new A a new A

asetLinknulla

asetLinkaa

asetLinkanull

atraverse

void setLinkA b A a

thisbefore b

thisafter a

void traverse

A a this

null length forint length a

Systemoutprintlnax

a anext

SystemoutprintlnLength is length

All ob ject sp ecications b egin with a name in the scop e of main or init Supp ose

we want to monitor length in metho d traverse of ob ject awe sp ecify this variable by

atraverselength Supp ose we want to monitor the value of variable x in an ob ject

that is b eing traversed from a We sp ecify it as atraverseax For static variables

and metho ds we use class name rather than ob ject name In addition we can include a

name of a thread into the ob ject sp ecication This is necessary to distinguish b etween lo cal

variables of a metho d invoked concurrently in two threads The followinf BNF describ es

2

the syntax for monitored ob ject naming sp ecication

VarName ThreadID VarName

VarName Varofmain

2

This syntax is not complete in a sense that there can b e some ob ject which we can not distinguish from

others using this syntax However we prefer current syntax b ecause of its simpleness than a complete and

complex syntax

VarNameGlobalVarName

VarNameMethodNamesLocalVarName

MethodNames MethodName MethodNamesMethodName

Here Var of main is a variable in the scop e of main and MethodNames is a se

quence of nested metho d invo cations

Similarly we name an execution p oint as a monitored entity

ThreadID ExePoint ExePoint

ExePoint start of VarNameMethodName

end of VarNameMethodName

Ob ject Oriented Monitoring

When we monitor the system as an evolving collection of ob jects we face two diculties

an aliasing problem and a reference changing problem The following example explains the

problems and our approach to its solution

class A

int x

Aint x thisx x

public static void mainString args

A a new A

A a a

A a new A

ax

aswapa

a a

void swapA a

int tmpx ax

ax thisx

thisx ax

On line an ob ject with eld x having value is created with name a On line it is

given another name a and on line the ob ject acquires still another name a in metho d

swap We refer to this as name aliasing The reference changing problem is illustrated

on line Name a do es not refer the ob ject created at line anymore but to a dierent

ob ject created at line Thus to monitor an ob ject correctly we have to check all reference

variables which refer to the ob ject We can not know statically which references will refer

to an ob ject We have to check it at runtime by monitoring references which can refer to

the ob ject This task is made simpler by the fact that Java byteco de is strongly typ ed that

is a reference of typ e T can refer only to an ob ject of typ e T In order to handle aliases

to an ob ject the lter maintains a table that contains names of monitored variables and

addresses of corresp onding ob jects By checking value of every reference variable of typ e

T against the address of the ob ject of typ e T we can ensure that we monitor the ob ject

without missing any up dates and that we monitor the correct ob ject In addition we may

have to keep a signature of a frame stack for monitoring lo cal variables

Atomicity of Variable Up date Detection

We insert a prob e of the lter immediately after storing instruction such as istore and

putfield When a monitored variable is up dated by storing instruction a lter immedi

ately sends information ab out the up date including the timestamp to monitor Based on

the timestamp the event recognizer determines the order of up dates we assume that clo ck

synchronization is outside the scop e of the problem However in a multithreaded appli

cation the order of up dates may b e determined incorrectly due to preemption by thread

scheduler Consider the following example

Thread 1 Thread 2 Thread 1 Thread 2

istore x 10 preemption istore x 10 send_update("x",10) by scheduler istore y 20 preemption send_update("y",20) by scheduler istore y 20 preemption send_update("y",20) by scheduler send_update("x",10)

a) Expected Behavior b) Incorrect Behavior

Figure Incorrect ordering of event detection

As you see in Fig up date of x should b e rep orted with an earlier timestamp than that

of up date of y But thread is preempted just b efore rep orting of up date of x and up date

of y has earlier timestamp Furthermore if thread up dates x to o the lter is left with an

erroneous view of the value of x

There are two conceivable solutions for the problem The rst one is to use two time

stamps One will b e assigned immediately b efore an up date of a variable the other im

mediately after the up date If the time interval b etween the two timestamps of up date of

x overlaps with the interval b etween the timestamps of up dating y the event recognizer

detects that order of up dates can b e either way However this solution can not prevent the

latter problem when thread up dated value of x The second solution is to use a global lo ck

for send buer of a lter A lter has a buer for storing and sending up date information

Immediately b efore b efore and immediately after the storing instruction we insert a lter

prob e to acquire the lo ck and place up date information into the buer and then release

the lo ck This makes the up date and its detection mechanism atomic It causes overhead

of acquiring and releasing lo ck at runtime However it guarantees the correct detection of

order of up dates and can b e implemented simply using monitor Therefore we cho ose the

second for up date detection mechanism

Filter and Co de Instrumentation

A lter consists of a set of prob es inserted into class les of the target system and a separate

lter ob ject The lter ob ject is an instance of a class which has metho ds for storing

information ab out up dates and for communication b etween lter and event recognizer a

table containing name and address of the monitored ob jects see section and a thread

to pro cess up dates To minimize a system overhead inserted prob es just store up dation

information in the buer in the lter class Checking a reference variable against the

address of the ob ject and sending up dation information is p erformed by the lter thread in

the background

As discussed in section we instrument a class le statically We instrument the

system to detect changes of values in monitored variables and send these values Let us

briey describ e how instrumentation works The lter keeps watch over three program

entities execution p oint lo cal variables and eld variables We do not discuss thread

identication here Instrumented System

Thread1 Thread2 Filter Thread Name/Address Table request_lock a1.x ... request_lock lock putfield a1.x 10 b1.y ... send_update("a1.x",10) Send to release_lock Event Recognizer putfield b1.y 20 var name b1.y a1.x send_update("b1.y",20) var value 20 10 release_lock timestamp 10250 10245

Send buffer

Figure Structure of Instrumented System

Execution p oint The current prototyp e detects when the execution p oint reaches a

metho d invo cation returns from a metho d The start and end of the program and excep

tions within a metho d are also detected Invo cation and return from the metho d can b e

detected by inserting the following byteco de b efore the rst instruction and after the last

instruction of the co de for the metho d

ldc Execution Point

ldc expoint

invokestatic MACFiltersendLjavalang StringLjavalangStringV

Instruction ldc loads a constant into op erand stack ex point is a string repre

sentation of start or end of a metho d such as Start of addIII where I means

integer typ es for two parameters and return value The last line invokes static metho d

MACFiltersend of the lter class with two parameters Execution Point and

point Other information ab out the up date such as thread name timestamp the ex

parent ob ject the signature of a frame stack are implicitly passed to the lter The metho d

checks whether this up date is related to the sp ecied monitored entities or not by lo oking

at the thread name static environment given by a parent ob ject and dynamic environment

given by a signature of frame stack Similarly the start of the program is detected by insert

ing co de at main or init Ending of program can b e detected by lo oking at invo cation

exit metho d and checking whether every thread except the daemon thread terminates

An exception of a metho d can b e detected by lo oking at the exception table Every metho d

has its own exception table that contains names of exception and jump addresses for the

case when the exception o ccurs We insert the ab ove co de at the jump address

Lo cal variable Every lo cal variable is indexed and accessed through this index which is

xed in byteco de instruction The only instructions that up date lo cal variable are Tstore

id where T is typ e of lo cal variable and id is the index of a lo cal variable and iinc

id Therefore we can statically identify the places in the byteco de that up date the lo cal

variable of interest Immediately after the up dating instruction we insert the following co de

ldc localvarname

Tload id

invokestatic MACFiltersendLjavalangStringTV

Field variable Detecting a change in a eld variable is similar to detecting a change in a

lo cal variable The putfield op erator has a reference to an ob ject as a runtime parameter

and an index to the eld in that ob ject as a xed parameter in byteco de We can detect

changes of the eld variable by keeping watch on putfield op erators and their reference

parameters

Inserting co de may cause side eects in the monitored program For example the

instrumented program may use more resources such as heap stack and constant p o ol than

the original program It may aect the scheduling of threads b ecause the newly added co de

consumes cpu time additionally However it seems very rare that a program exhausts all the

resource due to inserted co de and abnormally halts Furthermore a sound multithreaded

program dep ends on synchronization to guarantee correct execution

The lter is generated by a lter generator which is implemented in Java using JTrek

library Dig for inserting co de into the program The lter generator takes a program

to b e instrumented and list of monitored variables and monitored metho ds as input It

generates an instrumented program as output by inserting prob es at prop er places of the

co de The lter sends timestamp ed messages containing the up dated values through ob ject

serialization AG whenever it detects up dates of any of the ab ove three entities To

minimize the overhead to the system sending values to event recognizer through the network

is p erformed by a separate thread

Event recognizer

The event recognizer needs to determine the truth or falsity of the events and conditions

dened in the PEDL script at all time instants Assuming that the lter informs the event

recognizer whenever some ob ject of interest changes or some monitored metho d is invoked

the event recognizer needs to check the truth values at the times when it receives a message

from the lter The event recognizer maintains at all times a table that stores the current

value for each monitored variable Each message from the event recognizer causes this table

to b e up dated For lo cal variables whose value needs to b e distinguished across metho d

invo cation we maintain a stack each time the execution invokes the metho d in which this

variable is dened the new value of the variable is pushed onto the stack and when the

execution returns from such a metho d invo cation the top element is p opp ed from the stack

Whenever the event recognizer gets an up date from the lter it evaluates the truth

of all events and conditions Since conditions are dened in terms b o olean expressions

over monitored variables they can b e directly evaluated from the table storing the current

values of all monitored variables However in order to determine if an event like startc

is present it must not only know the current truth value of condition c but also its truth

value at the time of the previous up date The same is true for the event endc Hence

the checker also keeps track of the values of all the conditions at the time of the previous

up date in addition to the values of the monitored ob jects Finally once the checker has

determined the truth of all the conditions and events dened in the PEDL script it sends

to the checker the truth values of those events and conditions that have b een exp orted

Runtime Checker

The runtime checker gets information ab out the truth of certain events and conditions

from the event recognizer The checker then tries to see if the safety prop erties dened

in the MEDL script are always true and that the alarms in the MEDL script are never

raised The checker as well as the event recognizer determines the truth of the events and

conditions only at the times it gets a message from the event recognizer To do this the

checker maintains a table that stores the values of the auxilliary variables dened in the

MEDL script The checker also keeps track of the truth of events and conditions at the time

of the previous up date As we saw in the previous section this is sucient to determine

the truth value of all events and conditions that do not involve the pairing op eration The

truth of the condition e f can also b e evaluated The condition e f is true now if

either e is present now and f is not present now or if e f was true at the time of the

previous up date and f is not present now

Once all the truth of all the events and conditions has b een determined the auxilliary

variables are up dated If the event corresp onding to the up date rule is present is in the cur

rent time instant then the auxilliary variable is up dated as p er the assignment Whenever

an alarm b ecomes true or a safety prop erty b ecomes false the checker declares the program

to b e incorrect

Examples

A RailRoad Crossing System

The rst example illustrates how MaC framework is used for monitoring a safetycritical

system based on the railroad crossing This example is commonly used as a b enchmark

in formal metho ds research HD There are three comp onents in the system a train a

gate and a controller The goal of the system is to op erate the crossing gate sub ject to

safety and utility prop erties The safety prop erty states that when a train is in the crossing

the gate is down

We dene four events to check the safety requirement in PEDL startIC means the

train reaches in the crossing endIC means the train passes the crossing startGD means

the gate enters the closed state endGD means the gate starts raising We dene the safety

prop erty written in MEDL using condition IC which means a train is in cross and GD which

means a gate is down Figure presents a monitoring script containing the denitions of

these events and the safety prop erty

Let us briey explain what the program variables mean train x is the p osition of the

tail of a train train length is the length of a train Thus train x train length yields

the p osition of the head of a train cross x is the p osition of the left end of the crossing

Thus cross x cross length is the p osition of the right end of the crossing Methos

Gategd is used to lower the gate Gategu is the metho d for raising the gate

Client Example A Database

Another example describ es monitoring of a database client The client in our example

p erio dically prob es some database server cho osing it randomly from a list of servers for

some information The informal pseudoco de for the client app ears in Figure Some of

the requirements that one might b e interested in monitoring for such a system are

MonScr RailRoadCrossing

export event startIC endIC startGD endGD

MonVarDcl

float RRCtrainx

int RRCtrainlength

int RRCcrossx

int RRCcrosslength

MonMethodDcl

Gategd

Gategu

CondDef

Cond IC RRCtrainx RRCtrainlength RRCcrossx

RRCtrainx RRCcrossx RRCcrosslength

EventDef

Event startIC startIC

Event endIC endIC

Event startGD endmGategd

Event endGD startmGategu

End

ReqSpec RailRoadCrossing

import event startIC endIC startGD endGD

CondDef

Cond IC startIC endIC

Cond GD startGD endGD

SafePropDef

SafeProp safeRRC IC GD

End

Figure Monitoring script for the railroad crossing

Client

loop periodically every p time units do

location url from a given list randomly select a URL

open an HTTP connection to url with a timeout of To

if connection is established do

repeat for R times or until successful

send a CGI query for data

successful response from server within d units of time

if unsuccessful use old data

else use the data just received

else use old data

process data

endloop

Figure Informal description of the Database Client example

RT The client is indeed p erio dic ie every p units of time it tries to query a new server

FT If the pro cessed data is old then either a connection to the chosen server could not

b e op ened or the client could not get a resp onse to the query even after R retries

A sample Java implementation of the client according to the pseudoco de ab ove is

given in App endix The corresp onding monitoring script is given in Figure The events

to detect in the monitoring script are the start of a p erio d p erio dStart the start of

an attempt to establish a connection to a server conStart the failure of an attempt to

establish a connection conFail the resending of a query queryResend and the event

of old data b eing used during pro cessing oldData Using these events we can check the

prop erties RT and FT describ ed ab ove The prop erties RT and FT are formally sp ecied in

the corresp onding MEDL script in Figure The checker counts the numb er of times the

query was resent since the b egining of the p erio d using the auxiliary variable numRetries

The duration of the last p erio d is stored in the variable periodTime and the start time of

the previous p erio d is stored in the variable lastPeriodStart The variable chkConFail

is used to check if the connection did indeed fail during this p erio d

MonScr DBMon

export event periodStart conStart conFail queryResend

oldData

MonitoredObjects

int dbcgetDataBufferedReaderr

long dbcrunstartTime

Object dbcoldData

MonitoredMethods

void ctConnectTry string int

Socket ctresult

Object dbcgetData

EventDef

event periodStart updatedbcrunstartTime

event conStart startMctConnectTry

event queryResend

updatedbcgetDataBufferedReaderr

event oldData startvalueendMdbcgetData dbcoldData

event conFail startvalueendMctConnectTryresult null

End

Figure PEDL script for the database client

ReqSpec DBReq

import event periodStart conStart conFail queryResend

oldData

AuxilliaryVariables

long periodTime

long lastPeriodStart

int numRetries

boolean chkConFail

SafetyProperties

property periodic periodTime p

Alarms

alarm wrongFT oldData numRetries R chkConFail

AuxVarDef

initial periodTime p

lastPeriodStart

numRetries

chkConFail false

periodStart periodTime timeperiodStart lastPeriodStart

lastPeriodStart timeperiodStart

numRetries

conStart chkConFail false

conFail chkConFail true

queryResend numRetries numRetries

End

Figure Requirements for the database client

Figure The hexagonal pattern of MAVs

An avionics example

One more example of the utility of MaC approach is taken from a very imp ortant domain of

mo dern warfare Micro air vehicles MAV small unmanned planes that can b e dispatched

in large quantities very quickly eg dropp ed from another aircraft can b e employed to

p erform many dierent tasks One such task involves arranging MAVs into a hexagonal

pattern illustrated in Figure Each MAV has to b e near a grid of the pattern several

MAVs can o ccupy the same grid p oint this is clearly a twodimensional view of a three

dimensional situation Control of individual MAVs from a centralized controller is not

feasible therefore the MAVs must form the pattern through communications with their

neighb ours using lo cal information only Gordon and Sp eers at NRL Gora devised a

distributed algorithm to solve this problem The algorithm is based on relative p ositions of

the neighb ors of an MAV

The goal of this example is to demonstrate how monitoring and checking can b e used to

observe whether the desired pattern is forming as exp ected The approach to monitoring is

based on the observation that in the hexagonal pattern each neighb or of an MAV is either

at a xed distance that is the parameter of the pattern adjacent grid p oint or very close

to the MAV in question same grid p oint If the pattern is not fully formed there are

MAVs that have heighb ors in other lo cations and this can b e detected as a violations of

the pattern Intuitively we should exp ect that as the pattern forms the numb er of such

violations should go down

An implementationindep endent MEDL sp ecication of this prop erty is shown in Fig

ure The primitive event MAValert supplied by the event recognizer denotes a misplace

ment of some neighb or of an MAV Auxiliary variable currCount is used in the checker to

count the numb er of violations of the pattern in the current interval When the interval

elapses the accumulated numb er is compared with the numb er of violations in the previous

interval If a signicant increase in the numb er of violations is detected an alarm NoPattern

is sent to the user as a notication of p otential problems with the pattern formation

This monitoring approach is applied to a distributed emulator of MAV deployment

implemented in Java Each MAV is represented as a separate instance of class MAV based

on standard Java class Thread When the thread in an MAV is run it continuously executes

the p ositioning algorithm and queries its neighb ours for their p ositions A lo cal variable

distance in the run metho d of the class is used to hold the distance from the currently

queried neighb or The monitoring script for this implementation is shown in Figure It

denes event MAValert that is delivered to the checker The event is dened in terms of the

value of the variable distance By declaring the variable as a monitored entity he script

instructs the lter to send all up dates of this variable to the event recognizer which in turn

compares them with the acceptable range of values as describ ed in the script

Conclusions and Future work

We prop ose a monitoring and checking architecture as a framework for runtime assurance

It is bridging a gap b etween the traditional two approaches static verication and testing

We use ACSR and Java as our design and implementation language and mechanically

instrument the target system on the byteco de level To make runtime assurance monitoring

convincing we should provide formal guarantee of the requirement prop erty at runtime

ReqSpec HexPattern

import event MAValert

Auxiliary Variables

long currInterval

int currCount

int prevCount

Alarm Definitions

Alarm NoPattern currCount prevCount prevCount

Auxiliary Variable Definitions

starttrue

currInterval SystemcurrentTimeMillis

currCount

prevCount

SystemcurrentTimeMillis currInterval

currInterval currInterval

prevCount currCount

currCount

MAValert

currCount

End

Figure Requirement sp ecication for pattern monitoring

MonScr MAVpattern

export event MAValert

Monitored Entities

double MAVrundistance

Event Definitions

Event tooClose distance R distance R

Event tooFar distance R distance R

Event MAValert tooClose tooFar

End

Figure PEDL script for pattern monitoring

which we did not fully investigate yet We intend to incorp orate pro cess algebraic techniques

for reasoning ab out concurrency and communication and program checking for numerical

calculations into our monitoring approach

We are investigating a numb er of issues that deal with extension of MAC architecture to

distributed monitoring For example in a distributed environment we have to capture the

global state based on information from lo cal monitors only We think instrumentation of the

Java virtual machine can help distributed monitoring to obtain prop er timing information

ab out threads and communications within the system We p erformed exp eriments using

a multiple readerwriter example and have some theoretical results on distributability of

monitor

Another interesting question is ab out gap b etween the abstraction provided by a compu

tation mo del of a sp ecication language and the real program Most of formal sp ecication

languages have an ideal mo del which might not t into the real program The question

here is how to compare abstract executions of the sp ecication and concrete runs of the

monitored system and adjust the conclusions drawn from the monitoring pro cess to account

for this kind of dierence

References

AG Ken Arnold and James Gosling The Java Programming Language Addison

Wesley

+

BCD J Burch E Clarke D Dill L Hwang and K McMillan Symb olic mo del

20

checking states and b eyond In Proceedings of the th IEEE Symposium

on Logic in Computer Science

BCG G Berry P Couronne and G Gonthier Synchronous Programming of Reactive

Systems an Intro duction to ESTEREL Technical Rep ort INRIA

BGLG P BremondGregoire I Lee and R Gerb er ACSR An Algebra of Communi

cating Shared Resources with Dense Time and Priorities In Proc of CONCUR

BK M Blum and Sampath Kannan Designing programs that check their work In

JACM V No pages January

BW PC Bates and JC Wileden Highlevel debugging The b ehavioral abstraction

approach J Syst Software

CES EM Clarke EA Emerson and AP Sistla Automatic Verication of Finite

State Concurrent Systems Using Temp oral Logic Sp ecications ACM Transac

tions on Programming Languages and Systems April

CG Sarah E Cho drow and Mohamed G Gouda The Sentry System In SRDS

Octob er

CL Duncan Clarke and Insup Lee Automatic Test Generation for the Analysis of

a RealTime System Case Study In IEEE RealTime Technology and Applica

tions pages

Dig Digital Equip ement Corp DIGITAL JTrek

vadownloadjtrekindexhtml httpwwwdigitalcomja

DJC Michel Diaz Guy Juanole and JeanPierre Courtiat Observer a concept for

formal online validation of distributed systems IEEE Transactions on Software

Engineering Decemb er

Gora Diana Gordon private communication

Gorb M J C Gordon Hola pro of generating system for higherorder logic In VLSI

Specication Verication and Synthsis pages Kluwer

ormal Methods for RealTime Systems HD C Heitmeyer and D Mandrioli Eds F

Numb er in Trends in Software John Wiley Sons

HLNP D Harel H Lachover A Naamad and A Pnueli Statemate A working envi

ronment for the development of complex reactive systems IEEE Transactions

on Software Engineering

JP Lalita Jagadeesan and Adam Porter Sp ecicationbased testing of reactive soft

ware to ols and exp eriments In th International Conference on Software En

gineering May

Kur R P Kurshan Reducibility in analysis of co ordination In LNCS volume

pages SpringerVerlag

LC Yingsha Liao and Donald Cohen A sp ecicational approach to high level pro

gram monitoring and measuring IEEE Transactions on Software Engineering

Novemb er

LY LKDillon and YSRamakrishna Generating oracles from your favorite temp o

ral logic sp ecications Proceedings of the Fourth ACM SIGSOFT Symposium on

Software Engineering the Foundations of Software Engineering SIGSOFT

Notes pages

LY Tim Lindholm and Frank Yellin The Java Virtual Machine Specication Ad

dison Wesley

MC Barton P Miller and Mark D Callaghan The paradyn parallel p erformance

measurement to ols In IEEE Computer volume Novemb er

McM K L McMillan Symb olic mo del checking Kluwer

ML Aloysius K Mok and Guangtian Liu Ecient runtime monitoring of timing

constraints In IEEE RealTime Technology and Applications Symposium June

Manna and A Pnueli The Temporal Logic of Reactive and Concurrent Sys MP Z

tems SpringerVerlag

OSR S Owre N Shankar and J M Rushby The pvs sp ecication language In

Computer Science Laboratory SRI International Menlo Park CA February

Sch Beth A Schro eder Online monitoring A tutorial In IEEE Computer pages

June

Sch Fred B Schneider Enforceable security p olicies Technical Rep ort TR

Cornell University

SGME B Selic G Gullekson J McGee and I Engelb erg Ro om An ob jectoriented

metho dology for developing realtime systems IEEE Proc Fifth Interna

on ComputerAided Software Engineering Montreal Quebec tional Workshop

Canada pages July

SM Sriram Sankar and Manas Mandal Concurrent runtime monitoring of formally

sp ecied programs In IEEE Computer pages March

SS T Savor and R E Seviora An approach to automatic detection of software

failures in realtime systems In IEEE RealTime Technology and Applications

Symposium pages June

Tol Rob ert Tolksdorf Programming languages for the Java Virtual Machine Avail

able from httpgrungecstub erlindetolkvmlanguageshtml

ory and Implementation Tur David N Turner The Polymorphic PiCalculusThe

PhD thesis University of Edingburgh

A Java implementation of Database Client

import javaio

import javanet

class DBClient extends Thread

URL urlList

int numUrls

int period

int conTimeout

int queryTimeout

int retry

int retryDelay

Object data

Object oldData

Socket sock

DBClientString urlList int numUrls int period int conTimeout

int queryTimeout int retry int retryDelay

int port

URL u null

thisnumUrls numUrls

thisperiod period

thisconTimeout conTimeout

thisqueryTimeout queryTimeout

thisretry retry

thisretryDelay retryDelay

thisurlList new URL

forint i i numUrls i

try

thisurlListi new URLurlListi

catchMalformedURLException e

Systemerrprintlne

start

Main function gets file of URLs and parameters and passes all to

instance of DBClient

public static void mainString args

BufferedReader br null

String line null

String urlList new String

DBClient dbc null

int numUrls

Get url list file

if argslength

SystemerrprintlnUsage java DBClient urllist

period connectiontimeout readtimeout retry retrydelay

Systemexit

Get url list file

try

br new BufferedReader new FileReaderargs

catch FileNotFoundException e

Systemerrprintlne

Systemexit

Read url list file

do

try

line brreadLine

if line null

urlListnumUrls line

catch IOException e

Systemerrprintlne

while line null

Run DBClient

dbc new DBClienturlList numUrls IntegerparseIntargs

IntegerparseIntargs IntegerparseIntargs

IntegerparseIntargs IntegerparseIntargs

Main procedure of DBClient

public void run

BufferedReader in null

out null PrintWriter

long startTime

int index

Test

forint i i numUrls i

Systemoutprintln urlListi

Send query and receive data periodically

whiletrue

startTime SystemcurrentTimeMillis

try

Systemerrprintln

index connect Fault tolerrant connection

socksetSoTimeoutqueryTimeout Set timeout for receiving data

in new BufferedReader new InputStreamReader

sockgetInputStream

out new PrintWriternew OutputStreamWriter

sockgetOutputStream

Send query to URL

outprintlnGET urlListindexgetFile

outflush

y sent GET urlListindex SystemerrprintlnQuer

Receive data from the URL

data getDatain

SystemerrprintlnData received data

oldData data

processdata

Close the connection

inclose

outclose

sockclose

sleepperiod SystemcurrentTimeMillis startTime

catch InterruptedException e

Systemerrprintlne

catch IllegalArgumentException e

Systemerrprintlne

catch UnknownHostException e

Systemerrprintlne

catch IOException e

Systemerrprintlne

int connect

String url null

String host null

int port

int index

ConnectTry ct null

Select random url and read content from the url

whiletrue

index intMathrandom numUrls randome

host urlListindexgetHost

port urlListindexgetPort

port port port

ct new ConnectTryhostport

try

ctjoinconTimeout

if ctresult null

SystemerrprintlnConnection timeout conTimeout

to urlListindex

ctinterrupt

continue

else

sock ctresult

break

catch InterruptedException e

return index

Object getDataBufferedReader in

int r

while r retry

try

data inreadLine

oldData data

return data

catchInterruptedIOException e

SystemerrprintlnQuery Timeout queryTimeout

happen

try sleep retryDelay

catchException e

r

catchIOException e

SystemerrprintlnOld data is used due to max query failure

return oldData

Object processObject o

return null

class ConnectTry extends Thread

Socket s

String host

int port

ConnectTryString hostint port

thishost host

thisport port

start

public Socket result

return s

public void run

try

s new Sockethostport

if thiscurrentThreadisInterrupted

sclose

catchInterruptedIOException e

catch SocketException e Systemerrprintlne

catchUnknownHostException e Systemerrprintlne

catchIOException e Systemerrprintlne