c d4.2 s cop prototype runtime mechanisms...d4.2 ju ga# 692529 ©thesafe coponsortium 1 introduction...

D4.2 JU GA# 692529

©TheSafeCOPConsortium

SAFE COOPERATING CYBER-PHYSICAL SYSTEMS USING WIRELESS COMMUNICATION

D4.2 - SAFECOP Prototype runtime mechanisms

Reporttype DeliverableD4.2

Reportname SafeCop Prototype runtime mechanisms

Dissemination level CO

Report status: Final

Version number: 1.0

Date of preparation: 2018/09/27

Ref. Ares(2018)4998109 - 29/09/2018

D4.2 JU GA# 692529


ReviRevision chart and history log Version Date Reason

0.1 2018/09/23 First draft

0.2 2018/09/24 First review

0.3 2018/09/25 Updated Draft

0.4 2018/09/26 Final review

1.0 2018/09/27 Final release

D4.2 JU GA# 692529


Authors

DavidPereira,RicardoSeverino,LuigiPomante,WalterTiberti,MaurizioMongelli,MarcoMuselli,EnricoFerrari,KarlMeinke,MatteoGrotto,CarloBrandolese,LucianoBozzi,FabioDelForno,LeonardoNapoletani,

D4.2 JU GA# 692529


Table of contents

SAFECOOPERATINGCYBER-PHYSICALSYSTEMSUSINGWIRELESSCOMMUNICATION 1

ReviRevisionchartandhistorylog 2

Authors 3

Tableofcontents 4

Abbreviations 5

1 Introduction 6

2 PrototypeRuntimeMechanisms 7

2.1 Runtimemanagerfunction(CNR-IEIIT,Impara) 7

2.2 Agilla2(UNIVAQ) 9

2.3 TinyWIDS(UNIVAQ) 11

2.4 Run-timesafetymonitorforCO-CPSbasedonlineartemporallogic(KTH) 13

2.5 Safetyintegritymechanismstosupportrun-timemanagement(IBTSolutions) 16

2.6 ARunTimeManagerprototypeinC++language(ROT) 18

2.7 RMTLD3SynthRuntimeVerificationFramework(ISEP) 22

2.8 ROSbasedRuntimeMonitoringArchitecure(ISEP) 31

2.9 RuntimeMonitoringArchitectureforSafety-CriticalSystems(ISEP) 34

D4.2 JU GA# 692529


ABBREVIATIONS

Abbreviation Description

CO-CPS CooperativeCyber-PhysicalSystem

WSN WirelessSensorNetworks

MAMW MobileAgentMiddleware

IDS IntrusionDetectionSystem

LCU LocalCentralUnit

RTM Run-timeManager

D4.2 JU GA# 692529


1 INTRODUCTION Thisdeliverable isa “demonstrator”deliverable fromWP4andisacompendiumofprototyperuntimemechanismstargetingthesupportfortheRuntimeManagerofSafeCOP.Thesehavebeendevelopedbydifferentpartners,andtheirusagevariesdependingonthetargetusecases,ascanbeseenineachoftheprototypesdescription(someofwhicharedescribedinmoredetailinD4.1).

Thedeliverableisstructuredasfollows.

• Eachruntimemechanismprototypeispresentedviaan“ItemForm”whichcollectsthemaindetailsabouttheprototype;

• Theactualprototypeisavailableinbinaryexecutableformatand/orassourcecodeattherepositoryspecifiedintheItemForm;

• TheItemFormcontainsalsoinformation(references)aboutthemethodand/ortool,andadditionaldocumentationmayalsobeuploadedintherepository.

Thetextbelowpresentseightitemsthathasbeendevelopedbythefollowingsevenpartners:CNR-IEIIT,Impara,UNIVAQ,KTH,IBTSOLUTIONS,ROT,andISEP

D4.2 JU GA# 692529


2 PROTOTYPE RUNTIME MECHANISMS

2.1 RUN TIME MANAGER FUNCTION (CNR-IEIIT, IMPARA)

Item Type

Runtimemanagerfunction.

Item Name

Runtimemanagerfunctioncomingfromintelligiblemachinelearningforsafety/performancepredictionofCO-CPS.

Reference Links

Paper[1].

Purpose of Item

Runtimemanagerfunctionforcollisionpredictioninvehicleplatooning.

Description of Item

Oncemachinelearninghasbeenappliedatdesigntime,afunctionisderivedtobeapplicableatrun timeto infersafetyconditions. Inthiscase, the functionapplies tovehicleplatooningandshowshowcollisionpredictionisprovidedaccordingtosystemconditionsmonitoredatruntime.ThefunctionbasedonasetofBooleanrulesmaybeeasilyimplementedonthefield.[Mon18]showshowthesetofruntimefunctionsprovideforecastwithstatisticalerrorveryclosetozero,whilekeepingthelargestsetofworkingconditions.

Thesoftwarerelatedwiththeitemformisasfollows.

• SAFECOP_D42_CNR&Impara_RTMAmodel.c:theruntimemanagerfunction.• SAFECOP_D42_CNR&Impara_RTMA model with application.c: the run time manager

functionappliedinasimulationcontext.Nothingpreventstoadopttheruntimemanagerfunctioninarealdevice.

• SAFECOP_D42_CNR&Impara_RTMA model with application output.txt: the outputprovidedbytheapplication;itgivesanexampleaboutthepredictionofcollisionbeforeitmayhappen.

SAFECOP exploitation and extensions

N/A

TRL

• CurrentTRL–4:Technologyvalidatedinlab.

D4.2 JU GA# 692529


• TargetTRL–4:Technologyvalidatedinlab.

Relation to processes and platforms

Thepredictionmodel(resultingfromtheanalysisdevelopedthroughmachinelearning)maybeusedasaunitoftheruntimemanagertopredictunsafebehaviorsatruntime.

Use Cases Interactions

• UC3:collision/instabilitypredictionofvehicleplatoon.• UC5:performancepredictionofvehicletrafficscenarios.

Contact Persons

• [email protected]• [email protected]• [email protected]

Bibliography

• [1]E.Ferrari.A.Fermi,M.Mongelli,M.Muselli,“IdentificationofSafetyRegionsinVehiclePlatooningviaMachineLearning,”14thIEEEInternat.Work.onFact.Commun.Sys.WFCS2018.

D4.2 JU GA# 692529


2.2 AGILLA2 (UNIVAQ)

Item Type

Co-CPSPlatform

Item Name

Agilla2

Reference Links

• D4.1_COCPS• Sourcecode:https://github.com/SafeCOP/WP4

Purpose of Item

Agilla2providesanagent-basedenvironmentinwhichapplicationandsoftwarecomponentsaredistributedintheformofagents.

Description of Item

Agilla2 isamobileagentmiddleware(MAMW)forWirelessSensorNetworks(WSN). It is theevolutionoftheAgillamiddleware,amobile-agentplatformbasedonTinyOSandwritteninthenesClanguage.

TRL

• CurrentTRL-4:Agilla2hasbeendevelopedandtestedinalaboratoryscenario.• TargetTRL–5:Agilla2willbeexploitedintheUC5context,insidetheRSU-SN

component.


InSAFECOP,Agilla2isexploitedintheWSNplatformsinordertoprovideaflexible,mobile-agentbasedapproachindistributingapplications.


InthecontextoftheUC5,Agilla2willbeinstalledintheWSNnodeswhicharepartoftheRSU-SNcomponent.

Tool usage process

Agilla2allowapplications tobewritten in the formof agents.Agents arewritten in a simpleAgilla2-specificprogramminglanguages.Oncetheagentsarewritten,theycanbedeployed(i.e.injected)intheWSNdynamically,withoutrequiringnormalWSNnodeboardprogramming.

Inputs/Outputs

D4.2 JU GA# 692529


Agilla2requirestheTinyOSplatformtobeinstalledinthenodes.TheinputsofAgilla2arethesoftwareapplication,writtenintheAgilla2specificprogramminglanguage.Asoutputs,Agilla2simplifytheapplicationdevelopmentanddistribution.


• UseCase5(UC5):Agilla2isusedtoprovideadynamicmobileagent-basedmiddlewarefortheWSNpresentintheRSU-SNcomponent.

Contact Persons

• LuigiPomante,[email protected]• WalterTiberti,[email protected]

Bibliography

• [1]L.Pomante,L.Corradetti,D.Gregori,S.Marchesani,M.Santic,W.Tiberti.“ARenovatedMobileAgentsMiddlewareforWSN-PortingofAgillatotheTinyOS2.xPlatform.”IEEERTSI2016.

D4.2 JU GA# 692529


2.3 TINYWIDS (UNIVAQ) Item Type

Mechanism

Item Name

TinyWIDS

Reference Links

• D4.1_RTMO• Sourcecode:https://github.com/SafeCOP/WP4

Purpose of Item

TinyWIDSisanIntrusionDetectionSystem(IDS)forWirelessSensorNetworks(WSN).ItallowsWSNnodestodetectasetofcommonmaliciousattacksandtonotifythecontrolcenter

Description of Item

TinyWIDS is the implementation of a intrusion detection system designed for the WSNenvironment. It is based onWIDS, a reference IDS forWSNwhich exploits theWeak-Processmodel (WPM) in order to achieve amisuse-based intrusion detection. TinyWIDS contains aninternaldatabaseofknownmaliciousattacks(storedasWPMrepresentations)whichisexploitedtodeterminewhethertheWSNisunderamaliciousattack.OnceTinyWIDSdetectsuchasituation,itsendsnotificationstothecontrollingapplication,whichinturn,cannotifythecontrolcenterorperformapplication-definedreactions.

TRL

• CurrentTRL:4-TinyWIDShasbeendevelopedandtestedinalaboratoryscenarioagainstasetofsimpleattacks

• TargetTRL:5-TinyWIDSimplementationwillbeexploitedintheUC5context,insidetheRSU-SNcomponent


InSAFECOP,weprovideTinyWIDSasfirstWIDSimplementationwritteninthenesClanguageand based on the TinyOS platform. It is exploited thanks to its ability to perform intrusiondetectionoperationusingonlythescarceresourcesavailableintheWSNnodes.


InthecontextoftheUC5,TinyWIDSwillbeinstalledintheWSNnodeswhicharepartoftheRSU-SNcomponent.

Tool usage process

D4.2 JU GA# 692529


TinyWIDShastobeinstalledintheWSNnodesintheformofasetofsoftwaremodules.Onceitisaddedtotheapplicationprogram,TinyWIDSautomaticallyperformitstasks.

Inputs/Outputs

TinyWIDS inputs are the WSN node state information and the database of known maliciousattacks.TinyWIDSelaboratesthoseinputsinordertoproduce,uponthedetectionofmaliciousattacks,alarmsandnotificationsexploitablebyboththeapplicationprogramrunningontheWSNnodeandtheLCU.


Use Case 5 (UC5): TinyWIDS is used to provide an intrusion detection system in the RSU-SNcomponent.EachWSNnodeinsidetheRSU-SNexploitsTinyWIDSformonitoringmaliciousattackattempts,eventuallynotifyingthelocalcentralunit(LCU).

Contact Persons

• LuigiPomante,[email protected]• WalterTiberti,[email protected]

Bibliography

• [1]L.Pomante,W.Tiberti,M.Santic,F.Santucci,M.Pugliese,L.DiGiuseppe,L.Bozzi.TinyWIDS:a“WPM-basedIntrusionDetectionSystemforTinyOS2.x/802.15.4WirelessSensorNetworks”.FifthWorkshoponCryptographyandSecurityinComputingSystems(CS22018).

• [2]L.Pomante,M.Pugliese,S.Marchesani,F.Santucci.“WINSOME:AMiddlewarePlatformfortheProvisionofSecureMonitoringServicesoverWirelessSensorNetworks”.IWCMC2013.

• [3]L.Pomante,S.Marchesani,M.Pugliese,F.Santucci.“AMiddlewareApproachtoProvideSecurityinIEEE802.15.4WirelessSensorNetworks”.Mobilware2013.

D4.2 JU GA# 692529


2.4 RUN-TIME SAFETY MONITOR FOR CO-CPS BASED ON LINEAR TEMPORAL LOGIC (KTH) Item Type

Method(builtwithinasimulation)

Item Name

Run-timesafetymonitorforCO-CPSbasedonlineartemporallogic.

Reference Links

Paper[1].

Purpose of Item

Thepurposeof this item is to support run-time safetymonitoringby continuously evaluatingsafety conditions that have been derived from a hazard analysis. Such safety conditions areexpectedtohavebeenformalizedinlineartemporallogic(LTL)andtestedusingthequantitativesafety analysis (QSA) framework developed in Task 4.3. The QSA approach will identifyquantitativesafetythresholdsonsystemandenvironmentparameters.

ThederivedformulasandboundariesfromQSAwillbecontinuouslyassessedwithintherun-timemonitor, andassoonas they are violated thenerrorhandlingmechanismswill be called thatreturnthesystemtoasafestate.

Anexamplewouldbetomonitorthemaximumsafepacketlossinwirelesscommunication(anenvironmentalparameter)betweenplatoonvehicles(SafeCOPUC5.6).ThemaximumsafevalueforthisparameterwillbeestablishedbyQSA.Thepacketlossvaluewillthenbemonitoredatrun-time,andwhereitrisesabovethemaximumsafevalue,errorhandlingwillincreasethedistancebetweenvehiclestorestoresafety.

Description of Item

The item isarun-timemonitor thatobserveskey systemandenvironmentparameters,onaniterativesense-evaluate-actuatecycle.Thecycle timeneeds tobeshort toensure thatCO-CPSsystemsafetyisnevercompromised.

Duringtheevaluatephase,temporallogicsafetyformulasareevaluated.Whenasafetyformulabecomesfalse,theactuatephaseinvokesasafetyresponsefromappropriatecontrolalgorithmstosmoothlyrestoresystemsafety.

TRL

• CurrentTRL-1• TargetTRL–3


The QSA methodology will be defined and exemplified within research conducted withinSAFECOPTask4.3.

D4.2 JU GA# 692529


Themethodology will be developed and evaluated using an extension of an already existingplatooningsimulatorforUC5.6developedatKTH.

Somesoftwarefeaturesneedtobeaddedtothebackgroundtechnology(platooningsimulator)tosupportthismethodology.

Theintendeduseistoproviderun-timesafetysupportwhichcomplementsdesign-timesafetyanalysisthroughsafetyrequirementstesting.


Our approach will conform as an instance of the SafeCOP reference platform for run-timemanagement.

Methodology usage process

Therun-timemonitoringprocessisaniterativecycleasfollows:

1. Obtainupdatedcopiesofsystemsensorvalues.Ifnecessaryfiltersuchvaluesfornoise.Ifnecessaryestimatestatespacevalues,e.g.byKalmanfiltering.

2. Evaluateasetoftemporallogicsafetyformulas,basedoncurrentandprevioussensorvalues.

3. Ifatemporallogicsafetyformulabecomesfalse,activatetheappropriateerrorhandlingmechanism.Iftheformulaswasimmediatelypreviouslyfalse,checkthecurrentstatusoftheerrorhandlingmechanism.Ifnoresponse,escalatetheerror.

4. ReturntoStep1.

Inputs/Outputs

1. Input:oneormoresystemand/orenvironmentparameters2. Output:anactivationcalltoanemergencyresponsemechanism


Therun-timemethodologywillbeexemplifiedinUC6(platooning)toshowthatit isagenericmethodologythatcanbeappliedtotheotherCO-CPSusecases.Differentsafetyrequirementswillbe formulated for different uses cases on a platooning simulator (e.g. emergency braking).Differentsystemparameterswillbeidentified(e.g.timeheadway,distanceheadway),andaQSAwill be conducted to identify system and environment parameter boundaries. The resultingparametervalueswillbetakenasthresholdvaluesformonitoringwithintheruntimemanager.

Contact Persons

ProfessorKarlMeinke,[email protected]:0762238679skype:karl_meinke

D4.2 JU GA# 692529


Bibliography

• KarlMeinke:Learning-BasedTestingofCyber-PhysicalSystems-of-Systems:APlatooningStudy. EPEW 2017: 135-151 https://link.springer.com/chapter/10.1007/978-3-319-66583-2_9

D4.2 JU GA# 692529


2.5 SAFETY INTEGRITY MECHANISMS TO SUPPORT RUN-TIME MANAGEMENT (IBT SOLUTIONS) Item Type

Method

Item Name

Safetyintegritymechanismstosupportrun-timemanagement.

Reference Links

WPs/WP4/Workingdocuments/D4.1/SAFECOP_D41_RTME.docx

Purpose of Item

Thepurposeoftheitemistoprovidespecificguidelinesfortheimplementationofsafetyintegritymechanismsnecessarytosupporttherun-timemanagement.

Description of Item

The item collects a list of indications and guidelines to implement diagnostic and integritymechanismsinthecontextofresource-constrainedembeddedsystems.Particularfocusisposedondataintegrity,bothintheacquisitionphaseandinthestoragephase.Mostofthetechniquesdescribed in the item are specific realizations of themethods proposed in Functional SafetyStandardssuchasIEC61508andISO26262.

TRL

• TargetTRL–5:Fromthesoftwarepointofview,thetargetTRLtobereachedbytheendoftheprojectforthemaintechniquesis5.Itshallbenoted,though,thatsomeofthesetechniquesrequireahardwarecounterpart,whichwillnotbedesigned/redesignedduetothelimitedeffortavailable.Prototypicaldemonstratorswillbeusedinstead.


Themethodprovidestechniquestoprevent,diagnoseandreacttopossiblehazardousconditions.Allthesethreeportionsoftheitemwillbeused,possiblytodifferentextents.Whilemostofthetechniquesarebasedongeneralprinciples,theirspecificimplementationisstronglydependenton the specific application safety requirements and, most importantly, on the resourceavailability, in terms or processing and memory. In addition, since several techniques areconceived for generic sensordata, theyhavebeen customizedand specialized for the specificsensors(Accelerometer,Gyroscope,GPSandother)usedbytheSafeCOPapplication,inparticularforUC5.

Themaingoalofsuchtechniquesistwofold:ononehandtheyareaimedatguaranteeingthatthedata (position, speed, crash event alarms, …) collected by the OBU to be forwarded to theinfrastructureisreliabletothedesiredlevelofintegrity(ASILBorASILC);ontheotherhand,some techniques are adopted topreventunwantedactivationofpotentiallyhazardous safety-relatedfunctionssuchasvehiclebrakesactuation.

D4.2 JU GA# 692529



Themethodsandalgorithmsconstitutingthisitemarepartofthemonitoringinfrastructureoftherun-timemanager.

Tool usage process

Beingtheitemacollectionofmethodsandtechniques,theactualusageintheuse-caseapplicationis strongly dependent on the specific context. The guidelines provide suggestions on whichspecific techniques shall be used for diagnostic purposes, and, in some cases, for theimplementationofreactionsbringingthesystemtoasafe-state.

Ingeneralacustomimplementationisrequiredtointroducethedesireddiagnosticorintegritymeasureintothefunctionalportionoftheapplication.Tothisgeneralsituation,someexceptionare generic techniques such as double-inverted variable protection, CRC/Checksum dataprotections,programcontrolflowcheckingandafewother.SuchtechniquesareprovidedintheformofaClibrarybutstillaclearunderstandingoftheoperatingprinciplesandmanualcodingisnecessarytoproperlyintegratethemintotheapplication.

Inputs/Outputs

Themethodsareveryvariedandcanhardlybegeneralizedtoidentifycommoninputs.Ontheotherhand,outputsarestandardized.Twodifferenttypesofoutputscanbeidentified:

For thediagnostic techniques, theoutput isaBooleanvariable indicatingwhether integrity isviolatedornot.Thespecificformoftheoutput-fromtheprogrammingpointofview-canvaryfromtechniquetotechnique.

For system integrity technique, the output is actually constituted by a change of state of thesystem,whichisbroughttoeitheradegradeoperatingmodeorasafestate,typicallywiththesupportofspecifichardwarecomponents.


Thediagnosticandintegritymethodsconstitutingthisitem(bothintheformofmodelsandintheformofspecificClibraries)willmainlybeemployedintheV2Iuse-case(UC5).TheywillprimarilybeusedontheOBU(on-boardunit)toguaranteereliabilityofthedatageneratedbythedeviceandsharedwiththeinfrastructureandtopreventsystemfaultstoleadtohazardoussituationsandpotentialinjuries.

Contact Persons

• MatteoGrotto,[email protected]• CarloBrandolese,[email protected]

Bibliography

• [1] IEC 61508 - Functional Safety of Electrical/Electronic/Programmable ElectronicSafety-relatedSystems.

• [2]ISO26262-Roadvehicles–Functionalsafety

D4.2 JU GA# 692529


2.6 A RUN TIME MANAGER PROTOTYPE IN C++ LANGUAGE (ROT) Item Type

Co-CPSfunction/RTManager-Monitor(relatingtoSafeCOP-D1.1-RequirementsandEvaluationMetricsBaselineV2).

Item Name

ARunTimeManagerprototypeinC++language

Reference Links

Seebibliographybelow.

Purpose of Item

Themainscopeofthisitemistoprovideageneral-purposedesignandanimplementationthatcouldbereasonablyadoptedbyeveryUC,followingtheSafeCOPGenericArchitectureasin[1].

Description of Item

ARunTimeManager(RTM)prototypethattakesintoaccountresultsandapproachesasin[2],[3],[4]and[5].

Themainideaisto let users extendand customize this RTMimplementationto fit specific UCneeds,withoutlosingthemainobjectiveofguaranteeingsafetyatRuntime.

Basically,theRTMcanbeviewedasaFiniteStateMachinewith3operativestates:

• Idle:Initialstate

• Running:afteraninitializationphase,theRTMenterits"nominal"statewheremessagesfetchedbyqueuesaremonitoredandcontrolledwithrespecttoSafetyContracts;

• FailSafe: theRTMreacts, possiblywithanactuation, dependinguponviolations raisedwhenverifyingmessagedataagainstSafetyContracts.

Theproposedarchitectureiscomposedby3mainmodules:

CO-CPS Application interface:As already discussed, CO-CPS applications contains cooperativefunctionsunderdevelopmentbyeachUC.Alltherequirementsbasedoncooperativefunctionsbeingdevelopedundereachdemonstratorwillbelinkedhere.Wewilldefineaninterfacewhichallowstheseapplicationstointeractwiththesafetymanager.

SafetyManager/SafetyMonitor:thesemodulesreflecttheneedofhavingtwoseparatehandlersfor the safety functions; the SafetyManager gathers the inputs from theCO-CPSmodule andensuresthatthesafetycontractsforthecooperativefunctionsarenotviolatedthustoprovidethecorrectactuationchoicesforthevehiclewithintheplatoon.Complementarytothisbehavior,theSafetyMonitorwill ensure the quality of the data gathered by the on-board sensing andwillprovidethecorrectactuationsforthevehicleitselfbasedonthesafetycontracts.

D4.2 JU GA# 692529


Either if coming from the cooperative functions or from the on-board sensing,thegatheredinputsare evaluated based on a FSM logic and are used to implement theaction/reactionfunctionalities.

Figure1.SafetyManagerandMonitorarchitecture.

AsshowninFigure1,boththeSafetyManagerandtheSafetyMonitorarecomposedby4mainmodules:

• Builder:Itmanagestheprimitivesforreadingfromacommunicationchannel(ModuleI/O) andimplementsthe functions defined in the proxy interface (RealSubject).Itwillcontainforexample message parsing of 802.15.4 data ratherthanvelocity/odometer/accelerationsdata.

• Proxy:ItexposesthestandardinterfacetotheClient(i.e.FSM)tousetheconcretebuildermethodsandatthesametimeithidesfromclienttheknowledgeofabovemethods.

• Client:ItdefinesthelogicofdatareadingandwritinganditsendscommandexecutionrequeststotheCommand.Italsocontainstheapplicationdata buffer.It will

D4.2 JU GA# 692529


actuallycontaintheRuntimeManagerFSMandmechanismstoimplementisolation(I.e.messagequeues).

• Command:Entitythat, by receiving commands, applies the logicdefinedby theSafetyContracts(SimpleCommand),andperformstheactionincaseofviolations(itcouldbeamessagetoatask,adriverdirectlyinvokedontheO.S.,aninvocationofanAPIfunction,etc.), informing theClientof theresultedaction(violationornot), thusmanagingFSMstatetransitions.

TRL

Atthecurrentlevelofdesign,theprototypeisintendedtobeanexperimentalproofofconceptthatneedstobereviewedandapprovedbyallthepartnersinvolved.CurrentTRLis3andthetargetTRLwillbe4bytheendoftheproject.

Describe the Intended use of the Item in SAFECOP

Provideageneral-purposedesignandanimplementationoftheRTMthatcouldbereasonablyadoptedbyeveryUC,dependingupontheirspecificneeds.

Inputs/Outputs

• Input:CPS-Data(eg.sensing,alarm,ecc..)• Output:Monitoringdataandcontrolactionsonthedifferentsystemscontrollerstocomply

withsafetycontracts.


• WP2: thesafetycontractscoming fromtheHazardAnalysisofeachUCwillbeused tocreate the algorithms inside the SafetyManager to validate the cooperative functions(basicallyasetofparametersthatwillbemonitoredatRuntimetoensureSafetybetweentheCO-CPS).

• WP3: everything that relates to communicationprotocols is essential toguarantee thecorrectcommunicationbetweentheCO-CPS.ThecooperationwiththeWP4iscrucialinordertobeabletoensuretherightchoicesfortheRTMinthedifferentenvironments.

• WP1:TheUCsandRTMrequirementsareusedforthedesignphaseoftheRTM• WP5:ThefeedbackloopwiththedifferentUCswillserveasavalidationandverification

toolfortheRTMimplementationinthedifferentscenarios.

Contact Persons

• LucianoBozzi,[email protected]• FabioDelForno,[email protected]• LeonardoNapoletani,[email protected]

Bibliography

• [1]SafeCOP-D1.1-RequirementsandEvaluationMetricsBaselineV2

D4.2 JU GA# 692529


• [2]A.Casimiro,J.Kaiser,E.M.Schiller,P.Costa,J.Parizi,R.Johansson,R.Librino-TheKARYONProject:PredictableandSafeCoordinationinCooperativeVehicularSystems,WPs/WP4/Workingdocuments/SOA_D4.1/KARYON.pdf

• [3]CISTER–RuntimeVerificationofsafetyCriticalSystems,Documents/Meetings/RuntimeManagerWorkshop,Rome,Nov.28-29,2017/presentations/RuntimeVerification.pdf

• [4]C.Brandolese(Polimi/IBTS),L.Pomante(UNIVAQ)-SAFECOP_RT_v17_checkKARYON.ppt

• [5]S.Puri(INT)-Aboutmodellingcontractsandtheirpossibleusageatruntime,Documents/Meetings/RuntimeManagerWorkshop,Rome,Nov.28-29,2017/presentations/WorkshopRTMA-INT.pptx

D4.2 JU GA# 692529


2.7 RMTLD3SYNTH RUNTIME VERIFICATION FRAMEWORK (ISEP) Item Type

MonitorGenerationFramework

Item Name

RMTLD3SynthRuntimeVerificationFramework

Reference Links

Sourcecode:https://github.com/SafeCOP/WP4

Purpose of Item

Thepurposeof this item is to serve as a framework to specify andgenerate codeof runtimemonitorsbasedontheRMTLD3formaltimedtemporallogic.Thisframeworkhasbeendesignedtobegeneralenoughtobeadoptedvirtuallyinanyusecaseoftheproject.

Description of Item

Thermtld3synthisaframeworkoftheexpressivenessandpotentialofgeneratingmonitorsofRMTLD-3,presentedalreadyasoneoftheformallanguagesthatwasdesignedexactlytosuittheneedsofverifyingtimingconstraintsofcomplexsystems,suchasthoseaddressedinSafeCOP.This framework is able to automatically generate C++11 or OCaml programs that areimplementationsofmonitorsspecifiedusingtheRMTLD-3.

Forinstance,tospecifyaverysimpleconditionstatingthefollowing,assumingasthesetofeventsunderobservationtheevents𝑎,𝑏,and𝑐.Theconditioncanbespecifiedasfollows:“iftheevent𝑎holdsnow,theneither𝑎or𝑏willholduntiltheevent𝑐holds,butwithinthelimitof10unitsoftimeand,furthermore,theoveralldurationintimeof𝑐cannottakemorethan4unitsinthesamemaximumof10unitsoftime”.ThispropertycanbespecifiedinRMTLD-3asfollows:

(𝑎 → ((𝑎 ∨ 𝑏)𝑈*+,𝑐)) ∧ ∫ 𝑐+, < 4.

Now,inordertogeneratethecodeforthemonitorthatiscapableofverifyingthisproperty,wehavetoinputthisformulainthetextboxofthermtld3synthwebinterface,asdepictedinFigure2.ThetooltakesasinputthespecificationwritteninLaTexinitscurrentstatusofdevelopment,butbetterinputfacilitiesareexpectedtobedevelopedduringtheproject.TheactualspecificationinLaTexis

"(a\rightarrow((a\lorb)\until_{

D4.2 JU GA# 692529


Figure2.Weinterfaceofthermtld3synthtool.

D4.2 JU GA# 692529


Figure3.GenerationofC++11codefromthesamespecification.

TRL

Atthecurrentlevelofdesign,thetoolisintendedtobeanexperimentalproofofconceptthatneedstobevalidatedinalaboratorialuse-casesetting.ThelevelofTRLis3andtheaimistoreachTRLlevel4.


In SafeCOP the plan is to validate the tool in terms of its effectiveness to formally specifypropertiesthatarerelevantintheautomotivedomain,namelyviaitsintegrationinUC3.


Theproposedframeworkcanbeusedbyanypartner,asithasbeendesignedforspecifygeneralpropertiesaboutreal-timetimingproperties.ItwillbeexperimentedandvalidatedinUC3.

Tool usage process

D4.2 JU GA# 692529


Thermtld3synthsynthesistoolisabletoautomaticallygeneratemonitorsbasedontheformalspecificationswritten inRMTLD3.Polynomial inequalitiesare supportedby this formalismaswell as the most common operators of temporal logics. Furthermore, quantification is alsoconsideredinthelanguageofRMTLD3asameanstofacilitatethedecompositionofthequantifiedformulasintoseveralmonitoringconditions.

WewillnowpresentanoverviewofthetypicalprocessforgeneratingmonitorsforOCamlandC++11languagesusingthistool,togetherwitharunningexampleofasimplemonitoringcasegeneration.Webeginbytherunningexample,presentthegeneratedmonitors,andshowhowtoconfiguretheRVmonitoringmodeltocouplewiththesystem.

Letusconsiderthefollowingformula

thatintuitivelydescribesthatgivenanevent𝑎,𝑏occursuntilcand,atthesametime,thedurationof𝑏 shall be less than four-time units over the next 10-time units. For instance, a trace thatsatisfiesthisformulais(𝑎, 2), (𝑏, 2), (𝑎, 1), (𝑐, 3), (𝑎, 3), (𝑐, 10).

From rmtld3synth2ocaml tool, we synthesized the formula above into the code presented inError!Referencesourcenotfound.usingthefollowingcommandline:

./rmtld3synth --synth-ocaml --input-latexeq “(a \rightarrow ((a \lor b) \until_{10} c)) \land \int^{c} < 4”

Next,wecanalsogenerateC++11monitorsbyreplacing--synth-ocamlwith--synth-cpp11.TheoutcomeisthemonitorcodeispresentedinFigure5Error!Referencesourcenotfound.andFigure6Error!Referencesourcenotfound.,thelatterbeingtheheadercodethatconnectsmonitorstothecorrespondingruntimemonitoringarchitecture,andthatwewilldescribeinmoredetaillatterinthissection.

Tousethefirstmonitor(generatedfortheOCamllanguage),weneedtodefineatraceforOCamlreference as follows, which consists in defining a concrete trace to be analyzed and theninstantiatethecodeofthemonitorwithit(usingtheOCamlmodulesystem).

Now, we describe the settings for constructing the RV monitoring model. he settings forrmtld3synthtoolaredefinedusingthesyntax

( )

wherethesymbol“|”distinguishesbetweenthesupportedtypesofargumentssuchasBoolean,integerorstring,andsetting_idisastringcontainingthenameofthesettingtowhichvaluesareassigned.Anexampleofasetofpossiblesettingsforthetoolisgiveninthefirstfivelinesof

D4.2 JU GA# 692529


Error!Referencesourcenotfound..Wenowbrieflydescribethepurposeofeachofthesettingentries:

• gen_testssetstheautomaticgenerationsoftestcases;• gen_concurrency_tests constructs tests for testing lock- andwait-freemonitors

executingconcurrently;• gen_unit_testsconstructstestsforC++11synthesisusingtheOcamlsourcecodeas

anoracle;• buffer_sizesetsthestaticsizeofthebuffertobeused(rmtld3synthtoolcanchangeit

ifrequiredbysomeconstraints);• minimum_inter_arrival_timeestablishestheminimuminter-arrivaltimethatthe

eventscanhave.Itisaverypessimisticsettingbutprovidessomeinformationforstaticchecking;

• maximum_period sets themaximum interval between two consecutive releases of atask's job. It has a correlationbetween theperiodicmonitor andtheminimum inter-arrivaltime.Itprovidesstaticchecksaccordingtothesizeoftime-stampsofevents;

• event_typeprovidesthetypefordealingwithevents(commonlyisaclassparameter);• event_subtypeprovidesthetypefortheeventdata.Inthatcase,itisanidentifierthat

candistinct255events.However,ifmoreeventsarerequired,thetypeshouldbemodifiedtouint32_torgreater.Thenumberofdifferenteventsversustheavailablesizefortheidentifierisalsostaticallychecked;

• cluster_name identifies the set ofmonitors. It acts as a label for groupingmonitorspecifications.

The formulas `m_simple` and `m_morecomplex` are to RMTLD3 formulas that follow thetheoreticaldefinitionoftheruletoformformulasinductively,andtheyarerepresentedinOCamlbythetypeofdatapresentedinFigure4.

D4.2 JU GA# 692529


Figure4.GeneratedOCamlmonitor.

D4.2 JU GA# 692529


Figure5.GeneratedC++11monitor.

D4.2 JU GA# 692529


Figure6.GeneratedC++11monitorheader.

Figure7.Thedefaultconfigurationfile.

Figure8.Inductivetypeforthermtld3synthformulasandterms.

Inputs/Outputs

Theinputsforthetoolarewell-formedformulaswrittenintheRMTLD3logic[],describedinD4.1.The output of the tool is the code for themonitor (either in C++ or OCaml, for now) that issynthesizedfortheformulagivenasinput.

D4.2 JU GA# 692529



ThetoolwithbevalidatedinthecontextofUC3.

Contact Persons

• DavidPereira,[email protected]• RicardoSeverino,[email protected]

Bibliography

• [1]AndréPedro,“Dynamiccontractsforverificationandenforcementofreal-timesystemsproperties”,PhDThesis.10,Apr,2018.

D4.2 JU GA# 692529


2.8 ROS BASED RUNTIME MONITORING ARCHITECURE (ISEP) Item Type

RuntimeMonitoringArchitecture

Item Name

ROSbasedruntimemonitoringarchitecture.

Reference Links


Purpose of Item

ThepurposeofthisitemistoprovideagenericROSbasedinfrastructurethatallowsfortheruntimemonitoringviamonitorsspecifiedusingaprovidedlanguageand/orviatheusageofthermtld3synthtooldescribedintheprevioussection.

Description of Item

TheruntimemanagerbasedonROSthatweproposeherefollowsadifferentapproach,providingaYAMLbasedspecificationlanguagewhichallowstoabstractROSNodestoeventidentifiersthatcanthenbereadandanalyzedbymonitorsthatcaneitherbegeneratedbytheruntimemanagerviaaninternallanguage,orviapluggingexternalmonitorgenerationframeworks.ThegeneralviewofthisreferenceruntimemanagerarchitectureisdepictedinFigure9.

Figure9.ArchitectureofROSbasedreferenceruntimemanager.

Intheproposedarchitecture,componentscansubscribetoanytopicandextractitscontent,orcanreaddatafromanybag.Bagsaretypicallycreatedbyatoollikerosbag,whichsubscribestooneormoreROStopics,andstorestheserializedmessagedatainafileasitisreceived.ThesebagfilescanbeplayedbackinROStothesametopicstheywererecordedfrom(toidentifyruntimewitnessesofunspecifiedbehaviors),butmostimportantlytheycanberemappedtonewtopics,fromwhichmonitorscanreadandtriggertheSRMtoreact.

D4.2 JU GA# 692529


Theruntimemanagerarchitecturewearedescribinguseasynchronizerfilterthatsynchronizesincoming channels by the timestamps contained in their headers of the ROS Messages, andoutputsthemintheformofasinglecallbackthattakesthesamenumberofchannels.TheC++implementationcansynchronizeupto9channels.Thesynchronizerfilteristemplatedonapolicythatdetermineshowtosynchronizethechannels.Therearecurrentlytwopolicies:ExactTimeand ApproximateTime. The ExactTime policy requires messages to have exactly the sametimestampinordertomatch.TheApproximateTimepolicyusesanadaptivealgorithmtomatchmessagesbasedontheirtimestamp. When generating the runtime manager from configuration files (described below), apreprocessing expression evaluator is used to generate simplemonitors, that followa typicalprogramminglanguage,adhocmannerofwritingmonitors.ThisissometimesveryusefulwhenfocusingonparticularaspectsoftheCo-CPSforwhichasafetyconditiontobewritteninaformallanguagecouldrevealtobetoomuchtimeconsuming.Thispreprocessingexpressionevaluatorsupportsthefollowingfundamentalarithmeticoperations,andimperativelanguagestyletypesandstatements:

• Types:Scalar,Vector,String• Basicoperators:+,-,*,/,%,^• Assignment::=,+=,-=,*=,/=,%=• Equalities&Inequalities:=,==,,!=,=• Logicoperators:and,mand,mor,nand,nor,not,or,shl,shr,xnor,xor,true,false• Functions: abs, avg, ceil, clamp, equal, erf, erfc, exp, expm1, floor, frac, log, log10,

log1p,log2,logn,max,min,mul,ncdf,nequal,root,round,roundn,sgn,sqrt,sum,swap,trunc

• Trigonometry:acos,acosh,asin,asinh,atan,atanh,atan2,cos,cosh,cot,csc,sec, sin,sinc,sinh,tan,tanh,hypot,rad2deg,deg2grad,deg2rad,grad2deg

• Controlstructures:if-then-else,ternaryconditional,switch-case,return-statement• Loopstatements:while,for,repeat-until,break,continue• Stringprocessing:in,like,ilike,concatenation• Optimizations:constant-folding,simplestrengthreductionanddeadcodeelimination• Calculus:numericalintegrationanddifferentiation

ThecurrentstatusofthislanguageconsistsinaYAMLfilethatallowstospecifytopicstowhichdata to be monitored is being published, define meta-variables that gather data from thesubscribedtopics,theselectionofatimesynchronizationpolicy,andasectioninwhichonecanwritesafetyspecificationseitherusingthesimpleprocedural-likelanguagedescribedintheaboveparagraphs,orbyspecifyingandRMTLD3Synthcompliantformalspecification.Inthecaseofthelatter,theRMTLD3Synthtoolsisexternallycalledtogeneratedthemonitor(thisisstillearlywork,butthatisgoingtobecontinuedduringSafeCOPtoallowforageneralwayofplugging-inotherexternalmonitorgenerationframeworks).AnexampleispresentedinD4.1. TRL

• CurrentTRL:2;• TargetTRL:3;


D4.2 JU GA# 692529


ThisframeworkwillbeexploitedinSAFECOPforvalidationpurposes, i.e.,wewillvalidateditscapabilitiesofproperlymonitoringseveralautomotivescenarios(withinthesameuse-case)andfromthere,understandhowtogeneralizeitsothatitbecomesaframeworkwithcross-domainapplicability.


ThetoolwithbevalidatedinthecontextofUC3andtheusageoftheRTMLD3Synthasaback-endtogeneratedmonitorsisgoingtobeexperimented.

Tool usage process

ThistoolrequiresthatasetofROStopicsismappedtoparticularvariablesthataredeclaredinaYAMLfile.Monitorsarealsotobespecifiedinthesamefile.Then,acompilationprocesstakesplaceandgeneratesthetargetcompleteROSinfrastructure(nodes,topics,services,etc.)andthecodeforthemonitors.

Inputs/Outputs

TakesasinputanYAMLspecificationfileaccordingtothestructuredefinedaboveand,asoutput,generatesthecorrespondingROSinfrastructure(includingthemonitors).


ThetoolwithbevalidatedinthecontextofUC3.

Contact Persons


Bibliography

• AndréPedro,“Dynamiccontractsforverificationandenforcementofreal-timesystemsproperties”,PhDThesis.10,Apr,2018.

D4.2 JU GA# 692529


2.9 RUNTIME MONITORING ARCHITECTURE FOR SAFETY-CRITICAL SYSTEMS (ISEP) Item Type

RuntimeMonitoringArchitecture

Item Name

RuntimeMonitoringArchitectureForSafety-CriticalSystems

Reference Links


Purpose of Item

Thisworkreferstoareferencearchitecturefortheruntimemonitoringthatissuitedtosafetycriticalaswellasnon-criticalapplications,andthereforecanbeadaptedbyUCsfortheirspecificdemands.Thisreferencearchitecturecouldthenbeimplementedinanylanguage,aslongasitrespects the prescriptions discussed below. The proposed run-timemonitoring framework isdepictedinFigure10.

Description of Item

The architecture presented in Figure 10 is composed of five main components, namely, themonitoredapplication,themonitors,thebuffersthroughwhicheventsaretransmitted,thebufferwritersforwritingeventsinaspecificbuffer,andthebufferreadersusedbythemonitorstoreadevents stored in a buffer. This architecture focuses on time and space isolation guaranteesbetweenapplications(seenhereastasks)andthemonitors.InthecontextofaCo-CPS,distributedcomponents can adopt this architecture for managing the interaction between its innerapplications and monitors, whereas safe distributed monitoring can be implemented via theguidelinesalreadyintroducedanddescribedinSectionError!Referencesourcenotfound.ofD4.1.

Figure10.Referenceruntimemonitoringarchitecture.

TRL

D4.2 JU GA# 692529


Atthecurrentlevelofdesign,thetoolisintendedtobeanexperimentalproofofconceptthatneedstobevalidatedinalaboratorialuse-casesetting.ThelevelofTRListemporaryfixedat3,buttheaimistoreachTRLlevel4.


InSafeCOP,theplanistoextendthecurrentarchitecturewithdistributedcharacteristics,ideallymapping the several design guidelines described in D4.1. and recommended for the variousimplementationsoftheruntimemanagerinthedifferentusecases.


ThearchitecturewasdevelopedsothatitisgenericenoughtobeusedinanyoftheUC,anditwillbeusedintheimplementationofUC3.

Tool usage process

Documentationontheusageprocessisavailableinthesourcecoderepository.Thetoolconsistsinasetoflibrariesthathavetobeusedtowrapmonitorsanddefineeventbufferstoallowthecommunicationbetweenapplicationandmonitors.

Inputs/Outputs

Theinputsforthislibraryisthecodeintendedtoimplementthemonitors,andthecodeforthetasksthataredefinedtobeobservedbythosemonitors.


ExtensionstothislibraryareexpectedtobevalidatedinthecontextofUC3.

Contact Persons


Bibliography

• [1]Nelissen,G.,Pereira,D.,Pinho,L.,"ANovelRun-TimeMonitoringArchitectureforSafeand Efficient Inline Monitoring", 20th International Conference on Reliable SoftwareTechnologies-Ada-Europe2015(Ada-Europe2015).22to26,Jun,2015.Madrid,Spain.

D4.2 JU GA# 692529
