An Overview of the MOP Runtime Verification Framework

38 Pages·2011·0.92 MB·English

SoftwareToolsforTechnologyTransfermanuscriptNo.
(willbeinsertedbytheeditor)
An Overview of the MOP Runtime Verification Framework(cid:63)
PatrickO’NeilMeredith,DongyunJin,DennisGriffith,FengChen,GrigoreRos¸u
DepartmentofComputerScience,UniversityofIllinoisatUrbana-Champaign
201NGoodwinAve
Urbana,IL,61801,USA
e-mail: {pmeredit,djin3,dgriffi3,-,grosu}@cs.uiuc.edu
November5,2011
Abstract. ThisarticlegivesanoverviewoftheMonitoring propertiesthatareimplementedinhardware,butthesehard-
OrientedProgrammingframework(MOP).InMOP,runtime waremonitorsareactuallyusedtomonitorsoftwareprograms.
monitoringissupportedandencouragedasafundamentalprin- Monitoringorientedprogramming(MOP)[20–23,47]is
cipleforbuildingreliablesystems.Monitorsareautomatically agenericmonitoringframeworkthatintegratesspecification
synthesizedfromspecifiedpropertiesandareusedinconjunc- and implementationby checkingthe formeragainst the lat-
tionwiththeoriginalsystemtocheckitsdynamicbehaviors. ter at runtime. In MOP, one specifies desired properties us-
Whenaspecificationisviolatedorvalidatedatruntime,user- ing logical formalisms with actions to handle violations or
definedactionswillbetriggered,whichcanbeanycode,such validations of the specified property. MOP tools will then
as information logging or runtime recovery. Two instances automatically synthesize monitors from property specifica-
of MOP are presented: JavaMOP (for Java programs) and tionsandintegratethemwithintheapplicationtogetherwith
BusMOP(formonitoringPCIbustraffic).Thearchitecture user-providedhandlingcode.
ofMOPisdiscussed,andanexplanationofparametrictrace
monitoringanditsimplementationisgiven.Acomprehensive
1.1 RelatedWork
evaluationofJavaMOPatteststoitsefficiency,especiallyin
comparisonwithsimilarsystems.TheimplementationofBus-
MOPisdiscussedindetail.Ingeneral,BusMOPimposesno WenextdiscussrelationshipsbetweentheMOPframework
runtimeoverheadonthesystemitismonitoring. andotherrelatedparadigms,includingAOP,designbycon-
tract, runtime verification, and other trace monitoring ap-
proaches.Broadlyspeaking,alltheapproachesdiscussedbe-
lowareinstancesofruntimemonitoring.Interestingly,even
thoughmostofthesystemsmentionedbelowtargetthesame
1 Introduction
programminglanguages,notwoofthemsharetheexactsame
logicalformalismforexpressingproperties.Thisobservation
Runtime monitoring of requirements can increase the relia- strengthensourbeliefthatprobablythereisnosilverbullet
bilityoftheresultinghardwareorsoftwaresystems.Thereis logic(orsuperlogic)forallpurposes.Amajorobjectivein
anincreasinglybroadinterestinusesofmonitoringinsoft- thedesignoftheMOPframeworkwastoavoidhardwiring
waredevelopmentandanalysis,asreflected,forexample,by particularlogicalformalismsintothesystem.
abundantapproachesproposedrecently([4,12,16,19,25,26,
29,31,43,46] among others), and also by the runtime veri-
1.1.1 AspectOrientedProgramming(AOP)Languages
fication(RV)andtheformalaspectsoftesting(FATES)ini-
tiatives[10,30,31,34,35,58]amongmanyothers.Hardware
Sinceitsproposalin[42],AOPhasbeenincreasinglyadopted
approachestomonitoringhaveseenlessactiveresearch.Most
andmanytoolshavebeendevelopedtosupportAOPindif-
attemptsinhardwaretoperformmonitortaskshavebeenfor
ferentprogramminglanguages,e.g.,AspectJandJBoss[40]
the purposes of performance measures or temperature con-
forJava,andAspectC++[6]forC++.Builtonthesegeneral
trol.[45]isanapproachthatgeneratesmonitorsfromformal
AOPlanguages,numerousextensionshavebeenproposedto
providedomain-specificfeaturesforAOP.Amongtheseexten-
(cid:63) SupportedinpartbyNSFgrantsCCF-0916893,CNS-0720512,and
sions,Tracematches[4]andJ-LO[16]supporthistory(trace)-
CCF-0448501,byNASAcontractNNL08AA23C,andbyaSamsungSAIT
grant. basedaspectsforJava.
2 PatrickO’NeilMeredithetal.:AnOverviewoftheMOPRuntimeVerificationFramework
Tracematchesenablestheprogrammertotriggertheex- bugging,oronlinefordynamicallycheckingpropertiesduring
ecution of certain code by specifying a parametric regular execution.MaC[43],PathExplorer(PaX)[32],Eagle[11],and
patternofeventsinacomputationtrace,wheretheeventsare RuleR[12]areruntimeverificationframeworksforlogicbased
definedoverentry/exitofAspectJpointcuts.Whenthepattern monitoring,withinwhichspecifictoolsforJava–Java-MaC,
ismatchedduringtheexecution,theassociatedcodewillbe JavaPathExplorer,andHawk[25],respectively–areimple-
executed. In this sense, Tracematches supports trace-based mented.Alltheseruntimeverificationsystemsworkinoutline
pointcuts for AspectJ. J-LO is a tool for runtime-checking monitoringmodeandhavehardwiredspecificationlanguages:
temporalassertions.Thesetemporalassertionsarespecified MaCusesaspecializedlanguagebasedonintervaltemporal
usingparametriclineartemporallogic(LTL)andthesyntax logic,JPaXsupportsjustLTL,andEagleadoptsafixed-point
adoptedinJ-LOissimilartoTracematches’exceptthatthe logic. Java-MaC and Java PathExplorer integrate monitors
properties are specified in a different formalism. J-LO also viaJavabytecodeinstrumentation,makingthemdifficultto
usesthesameparametricitysemanticsasTracematches.J-LO porttootherlanguages.OurMOPapproachsupportsinline,
mainlyfocusesoncheckingatruntimepropertiesratherthan outline,andofflinemonitoring;allowsonetodefinenewfor-
providingprogrammingsupport.InJ-LO,thetemporalasser- malismstoextendtheMOPframework;andisadaptableto
tionsareinsertedintoJavafilesasannotationsthatarethen newlanguages(wediscusstwosuchinstancesinthispaper).
compiledintoruntimechecks.BothTracematchesandJ-LO Temporal Rover [26] is a commercial runtime verifica-
supportparametricevents,i.e.,freevariablescanbeusedin tiontoolbasedonfuturetimemetrictemporallogic.Itallows
thespecifiedpropertiesandwillbeboundtospecificvaluesat programmerstoinsertformalspecificationsinprogramsvia
runtimeformatchingevents. annotations, from which monitors are generated. An Auto-
TheMOPframeworkhaslogicplugins,whichencapsulate maticTestGeneration(ATG)componentisalsoprovidedto
differentlogicalformalismsandallowittocapturethecapabil- generatetestsequencesfromlogicspecifications.Temporal
itiesofTracematchesandJ-LO.JavaMOPistheinstantiation Roveranditssuccessor,DBRover,supportbothinlineand
oftheMOPframeworkforJavaprograms(seeSection3.2). offlinemonitoring.However,theyalsohavetheirspecification
JavaMOP allows for two different modes of matching formalisms hardwired and are tightly bound to Java. MOP
traces, referred to as total trace matching and suffix trace currentlyhasnometrictemporallogicplugin.
matching.TotalisthedefaultmodeofJavaMOP,whilesuffix
modeisusedbyprefixingaJavaMOPpropertywiththesuffix 1.1.3 DesignbyContract
modifier(seeFig.7andtheaccompanyingtext).
Withtotalmatching,forexample,withthepatterna∗b,a DesignbyContract(DBC)[49]isatechniqueallowingone
sequenceofeventsabbwilltriggerthevalidationhandlerof toaddsemanticspecificationstoaprogramintheformofas-
thegeneratedMOPmonitoronlyatthefirstbeventandthen sertionsandinvariants,whicharethencompiledintoruntime
theviolationhandler(ifany)atthesecondb. checks.Itwasfirstintroducedasabuilt-infeatureoftheEiffel
Withsuffixmatching,however,thepatternwillbematched language[28].SomeDBCextensionshavealsobeenproposed
twice,onceforeachbevent:thefirstmatcheseitherthewhole foranumberofotherlanguages.Jass[13]andjContractor[2]
traceaborthepartialtraceconsistingofjustthefirstbwith aretwoJava-basedapproaches.
zero occurrences of a, while the second matches the subse- Jassisaprecompilerwhichturnstheassertioncomments
quentpartialtraceb(thesecondbinthetrace)withzerooc- into Java code. Besides the standard DBC features such as
currencesofa;thus,therelatedadvicewillbeexecutedtwice. pre-/post- conditions and class invariants, it also provides
Withsuffixmatchingonecancountmatchesofapattern refinement checks. The design of trace assertions in Jass is
open close without a need to reset the monitor after each mainlyinfluencedbyCSP[38],andthesyntaxismorelikea
match, as would be required with total match monitoring. programminglanguage.jContractorisimplementedasaJava
Ontheotherhand,totaltracematchingismoresuitablefor librarywhichallowsprogrammerstoassociatecontractswith
runtime verification of formal properties, because it is the anyJavaclassorinterface.Contractmethodscanbeincluded
onlysemanticsthatmakessenseforsomelogicalformalisms, directlywithintheJavaclassorwrittenasaseparatecontract
such as LTL, and thus many users expect this behavior for class.Beforeloadingeachclass,jContractordetectsthepres-
pattern languages like regular expressions and context-free enceofcontractcodepatternsintheJavaclassbytecodeand
grammars,aswell. performson-the-flybytecodeinstrumentationtoenablecheck-
J-LOcanbecapturedbytheJavaMOPwithtotalmatching ingofcontractsduringtheprogram’sexecution.jContractor
becauseLTL(seeSection6.3)issupportedbytheMOPframe- alsoprovidesasupportlibraryforwritingexpressionsusing
work.MOPsupportsregularexpressionsaspartofitsextended predicatelogicquantifiersandoperatorssuchasForall,Exists,
regularexpression(ERE)logicplugin(seeSection6.2),and suchThat,andimplies.UsingjContractor,thecontractscan
TracematchesmaybecapturedbyJavaMOPbyusingthese bedirectlyinsertedintotheJavabytecodeevenwithoutthe
EREpatternswithsuffixmatching. sourcecode.
1.1.2 RuntimeVerification Java modeling language (JML) [44] is a behavioral in-
terface specification language for Java. It provides a more
Inruntimeverification,monitorsareautomaticallysynthesized comprehensivemodelinglanguagethanDBCextensions.Not
fromformalspecifications,andcanbedeployedofflineforde- all features of JML can be checked at runtime; its runtime
PatrickO’NeilMeredithetal.:AnOverviewoftheMOPRuntimeVerificationFramework 3
checkersupportsaDBC-likesubsetofJML.Spec#[9]isa siblesoft-coreprocessorimplementedonanFPGA,whileour
DBC-like extension of the object-oriented language C#. It approachcanpotentiallybeappliedtoanyCOTScommuni-
extendsthetypesystemtoincludenon-nulltypesandchecked cationarchitecture.Further,P2Vuseshardwiredlogic(PSL)
exceptions and also provides method contracts in the form whileBusMOPallowsdifferentformalisms.
ofpre-andpost-conditionsaswellasobjectinvariants.Us-
ingtheSpec#compiler,onecanstaticallyenforcenon-null
1.1.5 Discussion
types,emitrun-timechecksformethodcontractsandinvari-
ants,andrecordthecontractsasmetadataforconsumptionby
Allthisresearchandassociatedtoolsshowthatruntimemon-
downstreamtools.
itoringisanincreasinglyaccepted,powerful,andbeneficial
Webelievethatthelogicsofassertions/invariantsusedin
approachfordevelopingreliablesoftwareandhardware.Here
DBCapproachesfallundertheuniformformatofourlogic
wesummarizethesystemsdiscussedabove,andshowhow
engines,sothatanMOPenvironmentfollowingourprinciples
theymaybeclassifiedintermsofthefiveorthogonalattributes
wouldnaturallysupportmonitoringDBCspecificationsasa
oftheMOPframework:programminglanguage,logic,scope,
specialmethodologicalcase.Inaddition,theMOPframework
runningmode,andhandlers.Theprogramminglanguagede-
alsosupportsoutlinemonitoring,whichwefindimportantin
termineswhatlanguagetheprogramstobemonitoredmust
assuringsoftwarereliability(e.g.,monitoringforanddetecting
bewrittenin.Thelogicspecifieswhichformalismisusedto
andfixingdeadlocks)butwhichisnotprovidedbyanyofthe
specify the property. The scope determines where to check
currentDBCapproachesthatweareawareof.
the property; it can be class invariant, global, interface, etc.
Therunningmodedenoteswherethemonitoringcoderuns;it
1.1.4 OtherRelatedApproaches canbeinline(weavedintothecode),online(operatingatthe
sametimeastheprogram),outline(receivingeventsfromthe
ProgramQueryLanguage(PQL)allowsprogrammerstoex- programremotely,e.g.,overasocket),oroffline(checking
pressdesignrulesthatdealwithsequencesofeventsassociated loggedeventtraces)1.Thehandlersspecifywhatactionsto
withasetofrelatedobjects[46].Bothstaticanddynamictools performunderexceptionalconditions;therecanbeviolation
havebeenimplementedtofindsolutionstoPQLqueries.The andvalidationhandlers.Itisworthnotingthatformanylog-
staticanalysisconservativelylooksforpotentialmatchesfor ics,violationandvalidationarenotcomplementarytoeach
queriesandisusefultoreducethenumberofdynamicchecks. other,i.e.,theviolationofaformuladoesnotalwaysimply
Thedynamicanalyzercheckstheruntimebehaviorandcan thevalidationofthenegationoftheformula.
performuser-definedactionswhenmatchesarefound.PQL Most runtime monitoring approaches can be framed in
has a “hardwired” specification language based on context- termsoftheseattributes,whileintheMOPframeworkthey
free grammars (CFG) and supports only inline monitoring. maybeconfigured.Fig.1liststheattributesformostofthe
CFGscanpotentiallyexpressmorecomplexlanguagesthan softwaremonitoringsystemsdiscussedabove.Forexample,
regular expressions, so in principle PQL can express more JPaX can be regarded as an approach that uses linear tem-
complexsafetypoliciesthanTracematches.TheMOPCFG porallogic(LTL)tospecifyclass-scopedproperties,whose
plugindescribedinSection6.5allowstheMOPframeworkto monitorsworkinofflinemodeandonlydetectviolation.
specifymostofthepropertiesthatmaybespecifiedinPQL.
This observation essentially motivates the design disci-
ProgramTraceQueryLanguage(PTQL)[29]isalanguage
plineoftheMOPframeworkandspecificationlanguage,namely
basedonSQL-likerelationalqueriesoverprogramtraces.The
that one should be allowed to choose the most appropriate
currentPTQLcompiler,Partiqle,instrumentsJavaprograms
logicandthemostefficientmonitoringalgorithmforher/his
toexecutetherelationalqueriesonthefly.PTQLeventsare
ownapplications:whileprogramminglanguagesaredesigned
timestamped and the timestamps can be explicitly used in
andintendedtobeuniversal,logicsandspecificationstendto
queries. PTQL queries can be arbitrarily complex and, as
workbestwhentheyaredomain-specific.
shownin[29],PTQL’sruntimeoverheadseemsacceptablein
manycasesbutwewereunabletoobtainaworkingpackage
ofPTQLandcompareitinourexperimentswithJavaMOP 1.2 Examples
becauseoflicenseissues.PTQLpropertiesaregloballyscoped
andtheirrunningmodeisinline.PTQLprovidesnosupport Fig. 2 shows an example specification using JavaMOP; re-
forrecovery,itsmainusebeingtodetecterrors. call that this is the MOP instance for Java programs (see
ThePSLtoVerilogcompiler,P2V[45],isthesoleattempt Sections3.2and4).Detailedexplanationofthespecification
toperformruntimemonitoringofformalpropertiesinhard- syntaxcanbefoundinSections3.1and3.2.1.Thisspecifica-
ware,otherthanourBusMOPinstance(seeSections3.3and tion,calledSafeEnum,describesthecorrectbehaviorofusing
5),ofwhichweareaware.P2VissimilartoBusMOPinthat EnumerationsinJava.Essentially,thisspecificationrequires
monitorsareimplementedinhardwareratherthansoftware, thatanEnumerationcreatedfromaVectornotbeusedifthe
andthatbothapproachesthushavenoruntimeoverheadon VectorhasbeenupdatedsincetheEnumerationwascreated.
the CPU.P2V,however, is morelike the above approaches This is important in legacy code that still uses Vectors and
in that it is designed for monitoring actual programs rather
thanperipheraldevices.Alsoitrequiresadynamicallyexten- 1 Offlineimpliesoutline,andinlineimpliesonline.
4 PatrickO’NeilMeredithetal.:AnOverviewoftheMOPRuntimeVerificationFramework
Approach Language Logic Scope Mode Handler tersoftheproperty;inthisexample,twoparametersareused,
namelyaVectorobjectvandanEnumerationobjecte.
Hawk[25] Java Eagle global inline violation
J-Lo[16] Java ParamLTL global inline violation Thesecondpartcontainsthedeclarationoftwomonitor
Jass[13] Java assertions global inline violation variables:instanceVandinstanceE.Eachmonitorinstancefor
JavaMaC[43] Java PastLTL class outline violation eachinstantiationofthespecificationparametershasdistinct
jContractor[2] Java contracts global inline violation
monitorinstancevariables.Thus,theycanbeusedformany
JML[44] Java contracts global inline violation
JPaX[32] Java LTL class offline violation purposes:logging,extrastatesformonitoring,statistics,and
P2V[45] C,C++ PSL global inline validation/ soon.Here,theyareusedforbugreporting,tokeeptrackof
violation whichVectorandEnumerationcausethefailure.
PQL[46] Java PQL global inline validation
Thethirdpartofthespecificationcontainseventdeclara-
PTQL[29] Java SQL global outline validation
tions. Three events are defined: createE for the creation of
Spec#[9] C# contracts global inline/ violation
offline anEnumeration,updateVforupdatestoaVector,anduseE
RuleR[12] Java RuleR global inline violation forusesofanEnumeration.JavaMOPborrows(andextends;
Temporal C,C++, MiTL class inline violation seeSection3.2)thesyntaxofAspectJ[41]foreventdecla-
Rover[26] Java,
rations.Forexample,thecreateEeventisdeclaredtooccur
Verilog,
VHDL “after”afunctioncalltotheelements()methodofclassVec-
Tracematches[8] Java Reg.Exp. global inline validation tor.Notethatthetargetclauseisusedtobindparametersin
the event. Each event also sets one or both of the monitor
Fig.1.RuntimeMonitoringBreakdown.
variables,whichwill,again,bedistinctforeachbindingof
theparameters,usinganeventaction(theJavacodewithin
thecurlybraces).
full−bindingconnecteddecentralizedSafeEnum(Vectorv,Enumeratione){ Thefourthpartofthespecificationisaformaldescription
VectorinstanceV;
EnumerationinstanceE; of the desired property. As discussed in Section 2, MOP is
eventcreateEafter(Vectorv)returning(Enumeratione) : specification formalism independent, and one may choose
call(∗Vector.elements())&&target(v)
{instanceE = e;instanceV = v;} different logics to specify properties. In this example, the
eventupdateVafter(Vectorv) :
property description begins with fsm, meaning that a finite
(call(∗Vector.add∗(..))||call(∗Vector.remove(..)))&&target(v)
{instanceV = v;} statemachine(FSM)isused,andcontinueswithafinitestate
eventuseEafter(Enumeratione) :
descriptionofthemonitor.MonitorsforFSMpropertiesare
call(∗Enumeration.nextElement())&&target(e)
{instanceE = e;} initiallyinthefirststatelistedinthespecification,inthiscase
fsm :
start[ start.ThemonitorstaysinthestartstateuntilanEnumeration
updateV−> start iscreatedfromagivenVector.OncetheEnumerationhasbeen
createE−> enumCreated
] created,itissafetousetheEnumerationuntilsuchtimeasthe
enumCreated[ underlyingVectorismodified,atwhichpointtheinvalidEnum
useE−> enumCreated
updateV−> invalidEnum stateisentered.UsinganEnumerationintheinvalidEnumstate
] willresultinafailureoftheproperty.
invalidEnum[
updateV−> invalidEnum Thelastpartofthespecificationconsistsofhandlersto
]
executeindifferentstatesofthecorrespondingmonitor,such
@fail{
System.out.println(“Enumeration” + MONITOR.instanceE aspatternmatchorfailure.InFig.2,thehandlerstartswith
+“createdfromVector” + MONITOR.instanceV
@fail, defining the action, a simple warning in this case, to
+“notusedproperlyat” + LOC);
} executewhenthetracefailstomatchthepattern.Thehandler
}
reports which Vector and Enumeration are used incorrectly,
Fig.2. AJavaMOPSpecification(SafeEnum) and the line number where the failure occurs (given by the
MOP-reservedvariable LOC).The MONITORkeywordis
resolvedtothemonitorobjectbyJavaMOP.Thisisneeded
because there is no way from the context to tell if a given
EnumerationsbecauseJavadoesnotwarnofthispractice,it variable reference refers to a variable declared locally or a
simplyallowsfornon-deterministicresults. monitorinstancevariable.
Thespecificationiscomposedoffiveparts.Thefirstline JavaMOPspecificationsarecompiledintoAspectJ[41]
istheheaderofthespecification,startingwiththreemodifiers, aspects.SpecificationsasshortastheoneinFig.2compile
full-binding,connected,anddecentralized;thefirststatesthat intoseveralhundredlinesofAspectJcode.Thegeneratedas-
monitorinstancesforthispropertyshouldonlyraisefailures pectcanthenbeweavedintoaprogramonewishestomonitor,
wheneveryparameterforthemonitorinstancehasbeenbound usinganyAspectJcompiler.Onceweaved,simplyrunningthe
(Section4.4),thesecondstatesthattheobjectsboundtothe programasnormalresultsinamonitoredrunoftheprogram.
parametersmustbeconnectedbyaneventthatactuallyoccurs Fig. 3 shows an example specification using BusMOP,
(Section4.4),andthelastchoosesthewaytoindexmonitors the MOP instance for PCI Bus monitoring (see Sections 3
fordifferentparameterbindings(Section4.3).AnIDforthe and5).Themainuseforthisinstanceisensuringtheproper
specificationisgivenaftermodifiersandfollowedbyparame- useofperipheralsconnectedtothePCIBus.Improperuseof
PatrickO’NeilMeredithetal.:AnOverviewoftheMOPRuntimeVerificationFramework 5
pciSafeCounterModify{ wholerangeofaddresses.Notethatthiseventoverlapswith
signalcntrlCurrent : STDLOGICVECTOR(15downto0) := X“0000”;
countDisable and countEnable. The order of the events in
signalcntrlOld : STDLOGICVECTOR(15downto0) := X“0000”;
eventcountDisable : memorywriteaddress = base1 + X“220” Fig.3issignificantbecausesimultaneouseventsarehandled
dbytevalue(0)in‘0’
byreportingtheminthedeclaredorder(seeSection5).Each
eventcntrlMod : memorywriteaddressinbase1 + X“220”
{cntrlOld <= cntrlCurrent;cntrlCurrent <= value(15downto0);} cntrlEnablesavesthepreviousvalueoftheregister,sothatit
eventcountEnable : memorywriteaddress = base1 + X“220”
mayberestoredifthepropertyisviolated.Thespecialvari-
dbytevalue(0)in‘1’
ere: ((countEnablecountDisable)|cntrlMod|countDisable)∗ ablevaluereferstothevalueofthedataonthebus.Apipeline
@fail{
memreg <= ‘1’; iskeptwherethepreviousvalueisstoredtocntrlOldbefore
addressreg <= base1 + X“220”; cntrlCurrentreceivesthenewbusvalue,sothattheprevious
valuereg(15downto0) <= cntrlOld;
cntrlCurrent <= cntrlOld; valuemayberecoveredifthepatternfails(theeventaction
enablereg <= “0011”; occursbeforethepatternischecked).
}
} AsinFig.2,thefourthpartisaformaldescriptionofthe
desiredproperty,thistimeusinganextendedregularexpres-
Fig.3.ABusMOPSpecification(SafeCounterModify) sion(ERE).Thispatternspecifiesthedesiredbehaviorwhere
allmodificationsmusthappenafterdisablingthecounter(note
againtheorderofeventdeclarations,whichensuresthatthe
cntrlModencounteredfromacountDisableisreportedafter
peripheralsmayresultfrombugsindriversorfrommisuse
thecntrlMod).Thepair(countEnablecountDisable)enforces
of the drivers by application programs. This specification,
thatnochangescanbemadetocntrl cntrl2whileCounter2is
SafeCounterModify,statesadesiredpropertyofthePCI703A
enabled,otherthandisablingit.
digital-to-analog and analog-to-digital converter PCI board
Thelastpartofthespecificationisthehandlerforapattern
(ADC)[27].TheADChascountersthatareusedtodetermine
failure,similartoSafeEnum.Anassignmentof‘1’tothespe-
wheninputdataisfullyconvertedandreadytobeplacedon
cialvariablemem regalertsthesystemthatamemorywrite
the PCI bus. The specification in Fig. 3 is concerned with
iseminent.Theaddressofthewriteisplacedinaddress reg
the ADC’s Counter 2. It requires that any modification to
(notethatitisthecontrolregisterforCounter2).Thespecial
cntr cntrl2, the control register on the ADC for Counter 2,
variablevalue registhevaluetobewrittenoutbythemonitor,
happens only while the Counter 2 is not enabled (running).
anditisgiventhevalueofcntrlOld,whichstorestheprevious
Counter2isenabledwhenthe0’thbitofcntr cntrl2issetto‘1’.
value of cntr cntrl2. Lastly, the enable reg is specific to the
AsinFig.2,thefirstlineistheheaderofthespecification.
PCIBusinterface(seeSection5).
Thekeywordpcispecifiesthatthispropertyshouldgenerate
BusMOP specifications are compiled into hardware de-
buslisteningcodeforthePCIbus.AgainanIDnamingthe
scription language (HDL). As in JavaMOP, the size of the
specificationisprovided.Thistime,becauseBusMOPdoes
generatedcodeisfargreaterthanthatoftheoriginalspecifica-
nothaveparameters,thereisnoparameterlist.
tion.TheHDLcodeiscompiledintoanFPGAbitstreamand
Thesecondpartofthespecificationdeclarestwosignals, programmedontoanFPGAthatisinsertedintoanemptyslot
cntrlCurrentandcntrlOld,muchlikethemonitorvariablesof onthePCIbusofthesystemonewishestomonitor.
Fig. 2, but BusMOP has no monitor instances, so there is TheexamplesgiveninFigs.2and3maymonitorcom-
only one copy of the variables. These variables are used to pletelydifferentpropertiesincompletelydifferentproblem
store the previous value of cntr cntrl2, which is the control domains, but they follow the same pattern and philosophy.
registerforCounter2ontheADCboard.Thisisnecessary Byaclearseparationofmonitorgenerationandmonitorinte-
becausePCIbuspropertiescannotpreventincorrectbehavior, gration,MOPprovidesfundamentalandgenericsupportfor
but only detect and correct it. The stored value is used to effective and efficient application of runtime monitoring in
restorethevalueoftheregisterwhenthepatternfailstomatch different problem domains, and can be understood from at
(seebelow). leastthreeperspectives:
Thethirdpartofthespecificationcontainseventdeclara-
tions,muchlikethoseinFig.2,butusinganinstrumentation 1. Asadisciplineallowingonetoimprovesafety,reliability
languagespecifictoPCIBustraffic,ratherthanAspectJ.Three anddependabilityofasystembymonitoringitsrequire-
eventsaredefined.Thekeyworddbyteusedineacheventtells mentsagainstitsimplementationatruntime;
BusMOPthatthequantitywillbe16bitswide(i.e.,double 2. As an extension of programming languages with log-
byte).EventcountDisableoccurswhencntr cntrl2,whichis ics.Onecanaddlogicalstatementsanywhereinthepro-
addressX“220”intheaddressspaceoftheADC(base1con- gram, referring to past or future states of the program.
tainstheaddressofthebeginningoftheADC’saddressspace), Thesestatementsarelikeanyotherprogramminglanguage
hasits0thbit(value(0))setto‘0’,whichdisablesCounter2. booleanexpressions,sotheygivetheuseramaximumof
Thethirdevent,countEnable,isanalogous,but,asmentioned flexibilityonhowtousethem:toterminatetheprogram,
earlier,thebitissetto‘1’.TheeventcntrlModoccurswhen guide its execution, recover from a bad state, add new
cntr cntrl2ismodified.Thekeywordinisusedratherthan= functionality,etc.;
todefinetheaddressforcntrlMod.Thisisbecausewhenno 3. Asalightweightformalmethod.Whilefirmlybasedon
valueforthereadorwriteisspecified,itispossibletochecka logicalformalismsandmathematicaltechniques,MOP’s
6 PatrickO’NeilMeredithetal.:AnOverviewoftheMOPRuntimeVerificationFramework
purposeisnotprogramverification.Instead,theideaisto //Declarationofmonitorstate
intstate = 0;
avoidverifyinganimplementationagainstitsspecification
staticfinalinttransitioncreateE[] = {2,3,3,3};
beforeoperation,bynotlettingitgowrongatruntime. staticfinalinttransitionupdateV[] = {0,1,1,3};
staticfinalinttransitionuseE[] = {3,3,2,3};
//Codeforstateupdate
Section 2 introduces the generic MOP framework. Sec- state = transitioncreateE[state];
tion3discussesthetwocurrentlanguageinstancesofMOP, state = transitionupdateV[state];
state = transitionuseE[state];
givingabriefoverviewanddescribingtheirsyntax.Section4 //Codeforcategorychecks
presentstopicsspecifictotheefficientimplementationofJava- Categoryfail=state==3;
MOP, as well as a thorough evaluation of JavaMOP, while
Fig.5.JavacodefortheFSMinFig.2
Section5focusesonBusMOP.Aperformanceevaluationof
BusMOP(theMOPinstanceformonitoringPCIbustraffic)is
unnecessary,asithaszeroruntimeoverhead.2
isthelanguagespecificportionofanMOPinstance,weocca-
sionallyrefertothelanguageclientbythenameoftheMOP
2 MOPframework instancetowhichitbelongs.Languageclientsareresponsible
foralllanguage-specificaspectsofmonitoring,suchasinstru-
Allmonitoringsystemssharesomefeatures,suchasprogram mentation,parametricity,online/inline/outline,modifiers,etc.
instrumentationandmonitorintegration,evenwhentheyaim Theyareusuallycomposedofthreelayers:thebottomlayer
atdifferentdomainsorgoals.MOPseparatesmonitorgenera- containslanguagetranslatorsthattranslatetheabstractoutput
tionandintegrationandprovidesageneric,extensibleframe- of logic plugins into concrete code in a specific program-
workforruntimemonitoring,allowingonetoinstantiateMOP minglanguage;themiddlelayeristhespecificationprocessor,
with specific programming languages and specification for- whichextractsformulaefromthegivenpropertyspecification
malismstosupportdifferentdomains.Inthissection,wefocus andtheninstrumentsthegeneratedmonitoringcodeintothe
ontheoverallarchitectureofMOP. targetprogram;finally,thetoplayerprovidesusageinterfaces
totheuser.
2.1 Architecture WenextexplaininsomedetailtheJavalanguageclientfor
theJavaMOPinstance(whichbyabuseofterminologywewill
Fig. 4 shows the architecture of MOP. There are two kinds simplycallJavaMOP).JavaMOPgeneratesAspectJ[41]as-
ofhighlevelcomponentsinMOP,namelythelogicreposi- pectsfromaspecification.Atthebottomlayer,ithaslanguage
toryandlanguageclients.Thelogicrepository,showninthe translatorsforcontext-freegrammars(CFGs),thepseudocode
bottomofFig.4,containsvariouslogicpluginsandalogic outputgeneratedbythepasttimelineartemporallogicwith
pluginmanagercomponent.Thelogicpluginisthecorecom- callsandreturnsplugin,andfinitestatemachinedescriptions.
ponent to generate monitoring code from formulae written All plugins not mentioned use finite state machine descrip-
inaspecificlogic;forexample,theLinearTemporalLogic tionsasanoutputlanguage.Atthemidlevel,asmentioned,
(LTL)pluginsynthesizesstatemachinesfromLTLformulae. the Java client instruments the program with the generated
The output of logic plugins is usually pseudocode and not monitor code by creating a stand-alone aspect that can be
boundtoanyspecificprogramminglanguage.Thisway,the weavedintotheprogramusinganyAspectJcompiler,suchas
essentialmonitoringgenerationcanbesharedbydifferentin- ajc[7].Atthetoplevelthereisacommandlineinterfaceand
stancesofMOPusingdifferentprogramminglanguages.The a web-based interface. The two current MOP instances are
logicpluginmanagerbridgesthecommunicationbetweenthe discussedinSection3,and,respectively,Section4(JavaMOP)
languageclientsandthelogicplugin.Morespecifically,itre- andSection5(BusMOP),andthediscussionsessentiallyapply
ceivesthemonitorgenerationrequestfromthelanguageclient tothelanguageclientsassociatedwitheachinstance.
anddistributestherequesttoanappropriateplugin.Afterthe
2.3 LogicPlugins
pluginsynthesizesthemonitorfortherequest,thelogicplugin
managercollectstheresultandsendsitbacktothelanguage
client.Thisway,onecaneasilyaddnewlogicpluginsintothe Everylogicpluginimplementsandencapsulatesamonitorsyn-
repositorytosupportnewspecificationformalismsinMOP thesisalgorithmforaparticularspecificationformalism,such
withoutchangingthelanguageclient. asthepast-timelineartemporallogic(PTLTL)andtheCFG
plugins supported in the current MOP framework (see Sec-
2.2 LanguageClient tion6foracompletelistofavailableplugins).Thelogicplugin
accepts,asinput,asetofeventsandaformulaorpatternwrit-
Thelanguageclienthidestheprogramminglanguage-indepen- tenintheunderlyingformalismandoutputsanabstractmon-
dentlogicrepositoryandprovideslanguagespecificsupport itor.Thisabstractmonitorisusuallyapieceofpseudocode,
forthedifferentMOPinstances.Becausethelanguageclient whichchecksatraceofeventsagainstthegivenformula.
Wenextexplaininsomedetailoneparticularplugin,the
2 Overheadisexactly0%ifnorecoveryactionsareperformed.Recovery pluginforFSMspecifications.Fig.5showsthemonitoring
actionstakeupatinyportionofthebusbandwidth,andcouldtheoretically
codegeneratedbytheMOPFSMpluginfromtheFSMspeci-
addnon-zeroruntimeoverhead.Thiswasnegligibleinpractice,evenwith
continuouslyrecoveringproperties. ficationinFig.2.
PatrickO’NeilMeredithetal.:AnOverviewoftheMOPRuntimeVerificationFramework 7
Fig.4.ArchitectureofMOP
FSMmonitorsaresimple,asonemightexpect.Staticar- 3.1 MOPSyntax
rays keep the next state. There is one array for each event
inthespecification,ascanbeseeninFig.5.Whenanevent EveryMOPinstanceneedstoinstantiatetheMOPframework
arrives,theproperarrayisqueriedwiththecurrentstate,and infourdimensions:1)aspecificationlanguagebasedonthe
thenextstateisreturned.Afterthestateisupdated,thecat- problemdomain,whichismainlyrelatedtohowonedefines
egorychecksarepreformedtoseewhichhandlersmustrun. eventsinthedomain;2)atargetlanguageforgeneratedmoni-
Becausethespecificationonlychecked@fail,weonlyhave tors;3)supportedlogicpluginspecificationformalisms;and
onecheck,whichisforfail.Ascanbeseen,failisreachedif 4) the handlers allowed in the specification. Two MOP in-
themachineisinstate3.Thiscodemustbecombinedwith stanceshavebeenimplementedandexperimentedwithatthis
genericcodetohandletheotherpropertiesofthespecification, point:JavaMOPandBusMOP.WeexpecttoseemoreMOP
suchasconnectednessorfull-binding,aswellastheindexing instancesinthefuturebecausemanyproblemdomainscan
systemusedforparametrictraceslicing.TheFSMplugin,as benefitfrommonitoring.
wellastheothers,isdescribedinSection6. Each instance of MOP uses an instance of the generic
MOPsyntax.ThesyntaxofanyinstanceofMOPcanbegen-
eratedbydefiningcertainsyntacticcategories(non-terminals)
of the MOP grammar, which can be seen in Fig. 6. All of
3 MOPInstances
thegrammarsusedtodefineMOPsyntaxinthisarticleuse
ExtendedBackus-NaurForm(EBNF)[1].Non-terminalsin
thegrammarsaresurroundedby“(cid:104)”and“(cid:105)”.Braces(“{”and
Asonemayexpect,whenputtingtogethervariouslanguages “}”) enclose portions of the grammar that may appear zero
andspecificationformalisms,eachwithitsownsyntaxand ormoretimes.Brackets(“[”and“]”)encloseportionsofthe
semantics,consistencyandsyntacticseparationmaybecome grammar that are optional (i.e., it may or may not appear).
anon-trivialproblem.Inthissectionwediscussthefourdi- Concreteexamplesofthesyntaxdefinedbelowcanbeseenin
mensions that need to be instantiated in order to develop a Figs.2and3.
new MOP instance (like JavaMOP or BusMOP), how they
areinstantiated,andwheretheboundarybetweenthevarious 3.1.1 Sharedsyntax
componentsofaninstanceis.Sincethesemanticsofthevar-
iouspiecesistypicallyimplicitandnotformallydefined,in ThefollowingsyntaxconstructsaresharedbydifferentMOP
whatfollowsweplaceemphasisonsyntax. instances:
8 PatrickO’NeilMeredithetal.:AnOverviewoftheMOPRuntimeVerificationFramework
Sharedsyntax
(cid:104)Specification(cid:105)::={(cid:104)InstanceModifier(cid:105)}(cid:104)Id(cid:105)(cid:104)InstanceParameters(cid:105)“{”
{(cid:104)InstanceDeclaration(cid:105)}
{(cid:104)Event(cid:105)}
{(cid:104)Property(cid:105)
{(cid:104)PropertyHandler(cid:105)}
}
“}”
(cid:104)Event(cid:105)::=[“creation”]“event”(cid:104)Id(cid:105)(cid:104)InstanceEventDefinition(cid:105)“{”(cid:104)InstanceAction(cid:105)“}”
(cid:104)Property(cid:105)::=(cid:104)LogicName(cid:105)“:”(cid:104)LogicSyntax(cid:105)
(cid:104)PropertyHandler(cid:105)::=“@”(cid:104)LogicState(cid:105)(cid:104)InstanceHandler(cid:105)
Instance-specificsyntax
(cid:104)InstanceModifier(cid:105)::=(cid:104)Id(cid:105)
(cid:104)InstanceParameters(cid:105)::=(cid:104)JavaMOPParameters(cid:105)|(cid:104)BusMOPParameters(cid:105)|...
(cid:104)InstanceDeclaration(cid:105)::=(cid:104)JavaMOPDeclaration(cid:105)|(cid:104)BusMOPDeclaration(cid:105)|...
(cid:104)InstanceEventDefinition(cid:105)::=(cid:104)JavaMOPEventDefinition(cid:105)|(cid:104)BusMOPEventDefinition(cid:105)|...
(cid:104)InstanceAction(cid:105)::=(cid:104)JavaMOPEventAction(cid:105)|(cid:104)BusMOPEventAction(cid:105)|...
(cid:104)InstanceHandler(cid:105)::=(cid:104)JavaMOPEventHandler(cid:105)|(cid:104)BusMOPEventHandler(cid:105)|...
Logic-plugin-specificsyntax
(cid:104)LogicName(cid:105)::=(cid:104)Id(cid:105)
(cid:104)LogicSyntax(cid:105)::=(cid:104)FSMSyntax(cid:105)|(cid:104)ERESyntax(cid:105)|(cid:104)LTLSyntax(cid:105)|(cid:104)PTLTLSyntax(cid:105)|(cid:104)CFGSyntax(cid:105)|(cid:104)PTCaRetSyntax(cid:105)|...
(cid:104)LogicState(cid:105)::=(cid:104)FSMState(cid:105)|(cid:104)EREState(cid:105)|(cid:104)LTLState(cid:105)|(cid:104)PTLTLState(cid:105)|(cid:104)CFGState(cid:105)|(cid:104)PTCaRetState(cid:105)|...
Fig.6.MOPSyntax
– (cid:104)Specification(cid:105) — (cid:104)Specification(cid:105) describes the generic 3.1.2 Instance-specificsyntax
MOPspecificationsyntaxwhichcanbeinstantiatedfor
MOPlanguageinstancesandMOPlogicplugins.
Thefollowingconstructsarebasedontheparticularinstance
– (cid:104)Event(cid:105) — The (cid:104)Event(cid:105) declaration code allows for the
ofMOPusedforaparticularspecification.Moreinformation
definitionofevents,whichmaythenbereferredtointhe
ontheinstancesofMOPcanbefoundintheremainderofthis
property(see(cid:104)Property(cid:105)below).Eventdeclarationscan
section,andSections4(JavaMOP)and5(BusMOP).
alsohavearbitrarycodeassociatedwiththem((cid:104)Instance
Action(cid:105)),whichisrunwhentheeventisobserved((cid:104)Instance
EventDefinition(cid:105)),e.g.codetomodifytheprogramorthe – (cid:104)InstanceModifier(cid:105) — (cid:104)InstanceModifier(cid:105)s are specific
monitor state. For manual indication of events that can toeachlanguageinstanceofMOP.Syntactically,theycan
startatrace,thekeywordcreationisusedatthebeginning be any valid identifier restricted by the given language.
ofeachdeclaration.3 Theychangethebehaviorofthemonitoringcode.
– (cid:104)Property(cid:105)—EveryMOPspecificationmaycontainzero – (cid:104)InstanceParameters(cid:105)—allowonetodefinetheparame-
ormoreproperties.A(cid:104)Property(cid:105)consistsofanamedfor- tersofaparametricspecificationusingthelanguagecorre-
malism ((cid:104)LogicName(cid:105)), followed by a colon, followed spondingtotheMOPinstance.NotallMOPinstancesare
by a property specification using the named formalism parametric(e.g.,BusMOP),however,sothisnon-terminal
(see (cid:104)LogicSyntax(cid:105) below) and usually referring to the maybeempty.
declaredevents.Ifthepropertyismissing,thentheMOP – (cid:104)InstanceDeclaration(cid:105)—(cid:104)InstanceDeclaration(cid:105)sarespe-
specification is called raw. Raw specifications are use- cifictoeachlanguageinstanceofMOP.Theyallowfor
fulwhennoexistinglogicpluginispowerfulorefficient thedeclarationofmonitorlocalvariables.
enoughtospecifythedesiredproperty;inthatcase,one – (cid:104)InstanceEventDefinition(cid:105)—(cid:104)InstanceEventDefinition(cid:105)s
embedsthecustommonitoringcodemanuallywithinthe arespecifictoeachlanguageinstanceofMOP.Theydefine
(cid:104)InstanceAction(cid:105)code. theconditionsunderwhichaneventistriggered.
– (cid:104)PropertyHandler(cid:105) — Handlers contain arbitrary code – (cid:104)InstanceAction(cid:105)—Aneventcanhavearbitrarycodeas-
fromtheinstancesourcelanguage,andareinvokedwhen sociatedwithit,calledanaction.Theactionisrunwhen
acertainlogicstate(see(cid:104)LogicState(cid:105)below)orcategory theeventisobserved.Anactioncanmodifytheprogram
isreached,e.g.,match,fail,oraparticularstateinafinite orthemonitorstate,andthesyntaxoftheallowedstate-
statemachinedescription. mentsaredependentupontheMOPinstanceinquestion.
Typicallythestatementsusedinactionshavedifferentvari-
3 ThecreationkeywordhasnoeffectinBusMOPspecifications. ablesandfunctionsthatmaybereferredtothanhandlers.
PatrickO’NeilMeredithetal.:AnOverviewoftheMOPRuntimeVerificationFramework 9
Thisiswhydifferentnon-terminalsareusedforactions usedforlogging,recovering,blocking,oranyotherpurpose.
andhandlers. SincehandlersarespecifiedasarbitraryJavacode,auserhas
– (cid:104)InstanceHandler(cid:105)—(cid:104)InstanceHandler(cid:105)sarearbitrary quiteabitoflatitudetoachievehisorherpurposes.
codethatisexecutedwhenapropertyhandleristriggered.
3.2.1 JavaMOPSyntax
3.1.3 Logic-plugin-specificsyntax
ThesyntaxofJavaMOPisdiscussedbelow,asaninstanceof
Thefollowingconstructsarebasedonthelogicplugin(s)used thegenericMOPsyntaxdefiningtherelevantmodifiersand
inaparticularspecification.Moreinformationonlogicplugins language-specificsyntax(Javafordeclarationsandevent/hand-
canbefoundinSection6. leractions,enrichedwithAspectJforeventdefinitions).The
formalsyntaxcanbeseeninFig.7.Anythingnotexplicitlyde-
– (cid:104)LogicName(cid:105)—Anidentifiertoindicateinwhichlogic
scribedbelowcanbeconsideredtobeidenticaltothegeneric
apropertyisdefined.
MOPsyntax.Notethatsomenon-terminalssuchas(cid:104)Event(cid:105)
– (cid:104)LogicSyntax(cid:105)—Thisreferstothesyntaxoftheactual
refertolanguageinstancespecificnon-terminals,whichare
propertydefinition,andisdefinedinthesyntaxsectionfor
definedbelowforJavaMOP.
eachplugin.
– (cid:104)LogicState(cid:105)—(cid:104)LogicState(cid:105)sareconstantsdefinedfor
– (cid:104)JavaMOPModifier(cid:105)—Thethreebindingmodifiersrefer
eachplugin,statingforwhichmonitorstatesorcategories
tothedifferentbindingmodesdescribedinSection4.4,
(match,fail,etc.)ahandlermaybewritten.
thedefaultisany-binding.Themodifier“unsynchronized”
tellsJavaMOPthatthemonitorstateneedsnotbeprotected
3.2 TheJavaMOPInstance
againstconcurrentaccesses;thedefaultissynchronized.
Theunsynchronizedmonitorisfaster,butmaysufferfrom
JavaMOPisanMOPdevelopmenttoolforJava,supporting
races on its state updates if the monitored program has
several logical formalisms and a general specification lan-
multiplethreads.The“decentralized”modifierrefersto
guageusingthemtodescribeJavaprogrambehaviors[22].It
decentralizedmonitorindexing.Thedefaultindexingis
compilespropertyspecificationsintooptimizedmonitoring
centralized, meaning that the indexing trees needed to
code.ThegeneratedcodeusesAspectJ[41],andiscurrently4
quicklyaccessandgarbage-collectmonitorinstancesare
program-independent.Forexample,ausercanwriteaJava-
storedinacommonplace;decentralizedindexingmeans
MOP specification for a library. Then, JavaMOP generates
thattheindexingtreesarescatteredalloverthecodeas
monitoringcodeforthisspecification.Thiscodecanbeap-
additionalfieldsofobjectsofinterest.Decentralizedin-
pliedtoanyprogramthatusesthelibrary.
dexingtypicallyyieldslowerruntimeoverhead,thoughit
InJavaMOP,aneventcorrespondstoapointcut,whichan
maynotalwaysworkforallsettings.Moreinformation
AspectJcompiler(suchasajc[7])canusetoweavemonitoring
onindexingcanbefoundinSection4.3.The“perthread”
codeintotheoriginalprogram.Pointcutsincludefunctioncall,
modifiercausesJavaMOPtoconsidereventsfromeach
functionreturn,functionbegin,functionend,fieldassignment,
threadasthoughfromseparaterunsoftheprogram,(i.e.,
objectcreation,andmorecomplexoneswithpointcutoper-
one parametric monitor for each thread monitors only
ators,whichcombinemultiplesimplerpointcuts.JavaMOP
eventsfromitsownthread).The“suffix”modifiercauses
generatesmonitoringcodeforeachpointcut—corresponding
JavaMOPtoconsideratraceasmatchingifanysuffixof
toaneventinaJavaMOPspecification—tomaintainmonitor-
thattracewouldmatch.
ingstate,tocheckiftheprogramconformstothespecification,
– (cid:104)JavaMOPParameters(cid:105) and (cid:104)JavaMOPDeclaration(cid:105) —
andtotriggerahandlerifappropriate.
TheseareordinaryJavaparameters(asusedinmethods)
Asystembehaviorcanbedescribedusingoneofseveral
andJavadeclarations.Theformeraretheparametersof
logicalformalismssupportedbyJavaMOP,includingallthose
the JavaMOP specification and the latter are additional
describedinSection6.Aspecificationwillbeinterpretedby
localmonitorvariablesthatonecanaccessandmodifyin
thelogicrepository,agenericserverusedbyallinstancesof
botheventactionsandpropertyhandlers.Eachparameter
MOP,andtransformedintogenericmonitorcodeasmentioned
from (cid:104)JavaMOPParameters(cid:105) should be used in at least
inSection2.JavaMOPtranslatesthemonitorpseudocodeto
oneeventofthespecification.
AspectJcode.Anylogicwhichcanbetranslatedtofinitestate
– (cid:104)JavaMOPAction(cid:105),(cid:104)JavaMOPHandler(cid:105),and(cid:104)JavaMOP
machines(ERE,LTL,PTLTL)arereportedtoJavaMOPusing
EventDefinition(cid:105)—(cid:104)JavaMOPAction(cid:105)arenormalJava
the MOP finite state machine plugin syntax to reduce the
statementsthatmayalsorefertomonitorlocalvariables.
numberoftranslationalgorithmsnecessaryinJavaMOP(see
(cid:104)JavaMOPHandler(cid:105),however,slightlyextendsJavawith
Section6.1).
threespecialvariables:
A user can write a handler in Java for each monitoring
– RESET—aspecialexpression(evaluatestovoid)
state.Therecanbemoremonitoringstatesthansimplematch
thatresetsthemonitortoitsinitialstate,butdoesnot
and fail, depending on logical formalism. A handler can be
affectanyuserdefinedvariblesofthemonitor;
4 Weintendtoincorporateprogramstaticanalysistofurtherreduceruntime – LOC — a string variable that evaluates to the line
overheadsoon[17]. numbergeneratingthecurrentevent;
10 PatrickO’NeilMeredithetal.:AnOverviewoftheMOPRuntimeVerificationFramework
(cid:104)JavaMOPModifier(cid:105)::=“full−binding”|“maximal−binding”|“any−binding”|“connected”|“unsynchronized”
| “decentralized”|“perthread”|“suffix”
(cid:104)JavaMOPParameters(cid:105)::=“(”[{(cid:104)JavaMOPType(cid:105) (cid:104)Id(cid:105)“,”} (cid:104)JavaMOPType(cid:105) (cid:104)Id(cid:105)}]“)”
(cid:104)JavaMOPDeclaration(cid:105)::= syntaxofdeclarationsinJava
(cid:104)JavaMOPEventDefinition(cid:105)::=(cid:104)AspectJAdviceSpec(cid:105)“:”
(cid:104)AspectJPointcut(cid:105)[“&&”(cid:104)JavaMOPPointcut(cid:105)]
(cid:104)JavaMOPPointcut(cid:105)::=“thread”“(”(cid:104)Id(cid:105)“)”
| “condition”“(”(cid:104)BooleanExpression(cid:105)“)”
| (cid:104)AspectJPointcut(cid:105)
| (cid:104)JavaMOPPointcut(cid:105)“&&”(cid:104)JavaMOPPointcut(cid:105)
(cid:104)AspectJPointcut(cid:105)::=syntaxofPointcutinAspectJ
(cid:104)AspectJAdviceSpec(cid:105)::=syntaxofAdviceSpecinAspectJ
(cid:104)TypeList(cid:105)::=listofExceptiontypesinJava
(cid:104)BooleanExpression(cid:105)::=(cid:104)Id(cid:105)|“!”(cid:104)BooleanExpression(cid:105)
| (cid:104)BooleanExpression(cid:105)(cid:104)BooleanOperator(cid:105)(cid:104)BooleanExpression(cid:105)|“(”(cid:104)BooleanExpression(cid:105)“)”
(cid:104)BooleanOperator(cid:105)::=“||”|“&&”|“|”|“&”|“==”|“!=”
(cid:104)JavaMOPTypeList(cid:105)::=“(”[{(cid:104)JavaMOPType(cid:105)“,”} (cid:104)JavaMOPType(cid:105)]“)”
(cid:104)JavaMOPAction(cid:105) := Javastatements,whichmayrefertomonitorlocalvariables
(cid:104)JavaMOPHandler(cid:105) := Javastatementswithadditionalkeywords
(cid:104)JavaMOPType(cid:105) := AnyvalidJavatype
Fig.7.JavaMOPSyntax
– MONITOR — a special variable that evaluates to answersbothoftheseproblemsbyallowingthespecification
thecurrentmonitorobject,sothatonecanread/write andmonitoringofpropertieswithrespecttoPCIBustraffic
monitorvariables. (soontobeexpandedtootherbusarchitectures).
Similarly,theadviceusedtodefineJavaMOPeventsslightly In BusMOP, the events correspond to reads and writes
extendstheAspectJadvicesyntax.The(cid:104)JavaMOPEvent ofspecifiedvaluestospecifiedmemorylocationsonthebus.
Definition(cid:105)followstheAspectJsyntaxexceptforitsexten- PCIBusinterruptsarealsoallowedasevents.Themonitors,
sionwith(cid:104)JavaMOPPointcut(cid:105),whichcanonlybeadded and the logic to extract events from bus traffic, are synthe-
in a top-level conjunct context. (cid:104)AspectJPointcut(cid:105) and sized from hardware design language (HDL) code and pro-
(cid:104)AspectJAdviceSpec(cid:105)arebothstandardAspectJsyntax[7]. grammedontoafieldprogrammablegatearray(FPGA),which
Theadditionalpointcutshavethefollowingmeaning: ispluggedintothePCIBus.
– “thread”—Thethreadpointcutcapturesthecurrent BusMOPsupportstheFSM,ERE,LTL,andPTLTLplug-
threadandtakesanidentifierasaparameter.Theiden- insofMOP(seeSection6).PTCaRetandCFGhavetheprob-
tifiercanbeaclassnameoravariablename.Forthe lemofunboundedlogicresponsetime,whichwouldcausethe
former, the type of the captured thread should be a monitortonotmeettimingconstraintsinsomecases,andare
sub-class of the given class to trigger the event. For thusnotsuitableforinclusioninBusMOP.Itisalsonotclear
thelatter,thecapturedthreadisboundtothevariable. exactlywherethestructuredcapabilitiesoftheselogicsare
Thethreadpointcutallowsfortheeasyspecification usefulwhenconsideringflatbustraffictraces.
ofpropertieswhichareparameterizedbythecurrent Handlers in BusMOP can be specified using arbitrary
threadofexecution. VHDLcode.Severalresourcesareprovidedfortheuserfor
– “condition”—Theconditionpointcuttakesaboolean use in handler code, such as serial output for logging, and
expressionasaparameter.Aneventcontainingacondi- theactualabilitytowritetothePCIBustoperformrecovery.
tionpointcutisnottriggeredifthebooleanexpression RecoveryactionsinBusMOPrequirebusarbitrationtoundo
evaluatestofalse.Thisdiffersonlyfromtheifpointcut deleteriousactionsoffaultyperipheralsortheirdrivers.This
instandardAspectJinthatmonitorinstancevariables busarbitrationistheonlypossibleoverheadincurredbyBus-
maybeusedintheconditionalexpression. MOP,incasesofheavyBustraffic.Inthemajorityofsystems,
BusMOPcanbeusedwithnoruntimeoverhead.
3.3 TheBusMOPInstance 3.3.1 BusMOPSyntax
BusMOP[52]wasdesignedtoaddressthesafetyproblemof BelowwediscusstheBusMOPsyntax.Anythingnotexplic-
thirdpartyconsumeroff-the-shelf(COTS)components.The itly described below can be considered to be identical to
complexityofsafetycriticalsystemshasgrowntothepoint thegenericMOPsyntax.Notethatsomenon-terminalssuch
where the ability to use COTS in a safe manner is almost as(cid:104)Event(cid:105)refertolanguageinstancespecificnon-terminals,
mandatory.Additionally,thevastmajorityofOScrashesin whicharedefinedbelowforBusMOP.Thegrammarforthe
PCsarecausedbyfaultyperipheralsortheirdrivers.BusMOP syntaxcanbeseeninFig.8.