CityGuard: A Watchdog for Safety-Aware Conflict Detection...

CityGuard A Watchdog for Safety-Aware Conflict Detection inSmart Cities

M Ma S Masud Preum and J StankovicDepartment of Computer Science

University of VirginiaCharloesville Virginia 22903

meiyipreumstankovicvirginiaedu

ABSTRACTNowadays increasing number of smart services are being devel-oped and deployed in cities around the world IoT platforms haveemerged to integrate smart city services and city resources andthus improve city performance in the domains of transportationemergency environment public safety etc Despite the increasingintelligence of smart services and the sophistication of platformsthe safety issues in smart cities are not addressed adequately espe-cially the safety issues arising from the integration of smart serviceserefore CityGuard a safety-aware watchdog architecture is de-veloped To the best of our knowledge it is the rst architecturethat detects and resolves conicts among actions of dierent ser-vices considering both safety and performance requirements Priorto developing CityGuard safety and performance requirementsand a spectrum of conicts are specied Sophisticated modelsare used to analyze secondary eects and detect device and en-vironmental conicts A simulation based on New York City isused for the evaluation e results show that CityGuard (i) identi-es unsafe actions and thus helps to prevent the city from safetyhazards (ii) detects and resolves two major types of conicts iedevice and environmental conicts and (iii) improves the overallcity performance

CCS CONCEPTSbullComputing methodologies rarr Modeling and simulation bullComputer systems organization rarr Embedded and cyber-physical systems bullApplied computing rarr Service-oriented ar-chitectures

KEYWORDSCity Safety Conict Detection City Simulation Smart City

ACM Reference formatM Ma S Masud Preum and J Stankovic 2017 CityGuard A Watchdogfor Safety-Aware Conict Detection in Smart Cities In Proceedings of e2th ACMIEEE International Conference on Internet-of-ings Design andImplementation Pisburgh PA USA April 2017 (IoTDI 2017) 12 pagesDOI hpdxdoiorg10114530549773054989

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor prot or commercial advantage and that copies bear this notice and the full citationon the rst page Copyrights for components of this work owned by others than ACMmust be honored Abstracting with credit is permied To copy otherwise or republishto post on servers or to redistribute to lists requires prior specic permission andor afee Request permissions from permissionsacmorgIoTDI 2017 Pisburgh PA USAcopy 2017 ACM 978-1-4503-4966-61704 $1500DOI hpdxdoiorg10114530549773054989

1 INTRODUCTIONWith the increasing prevalence and development of smart citiesthe intelligence and complexity of smart services and platformshave been growing rapidly Various smart services in dierentdomains such as transportation environment energy and emer-gency management have been separately deployed to improve cityoperation and human experiences For example a smart energy ser-vice [17] distributes power optimally and saves idle energy and asmart taxi service [13] dispatches taxis to minimize passenger waittime To further increase smart city capabilities there is a need forintegration of multiple smart devices and services Smart city IoTplatforms such as IBM Watson IoT [3] ORACLE [5] KM4City [8]and others are built to integrate smart services working under thesame system making the communication and data sharing amongthem possible and convenient

However to date most of existing smart cities do not considersafety control in the context of integrated smart services especiallyin terms of conicts among them Not enough aention is paid tothe potential safety conicts caused by conicting actions taken bydierent smart services For example assume a smart trac serviceredirects vehicles from a highway to another road near a residentialarea to relieve trac congestion Now a higher concentrationof CO will be released in the residential area Assume that thesmart trac service is aware of this problem and regulates tracaccordingly Now assume there is a chemical factory nearby theresidential area which also releases CO gas but is monitored toguarantee that CO release is under safe limits However with thisnew action of diverting trac the total concentration of CO nowexceeds safe limits is results in unsafe air quality and aects thehealth of people living in this area Also although the two servicesmaintain the safety requirement (ie keeping CO release belowsafety threshold) individually their concurrent operations violatethe safety requirements cumulatively us it causes a conictSafety maintenance in a smart city is extremely important andchallenging

Even though some smart services have individual sophisticateddecision-making processes that consider safety requirements therestill exist inevitable conicts between smart services in smart citiesbecause of the following reasons

bull Most of the existing smart services are developed and usedindependently by dierent stakeholders including govern-ments commercial enterprises and individuals Also theindividual services usually have varied levels of sophistica-tion and aention on safety requirements which may beunaware of or inconsistent with each other

IoTDI 2017 April 2017 Pisburgh PA USA M Ma et al

Figure 1 CityGuard in the Smart City

bull In most cases the safety requirements from services onlyconsider the primary eects (eg minimize congestion)while ignoring secondary eects on the environment (egair pollution) thus violating safety requirements

bull e safe actions dened by smart services may not alwaysbe safe for a smart city when considering (i) the eectsof those actions over a time interval an area and (ii) theactions taken by other services

bull Devices and services might be updated over time withoutnotifying other services Even though services may havepre-dened safety requirements and rules to avoid conictsnew conicts may arise as smart services evolve over thelong term

Hence a safety-aware watchdog architecture called CityGuardis created to detect and resolve the conicts from multiple smartservices in a smart city (see Figure 1) Generally the smart cityis constructed of two main parts (i) an infrastructure layer withsensors and actuators and (ii) a soware layer consisting of IoTplatforms and individual smart services CityGuard is designedto be a middle layer with sophisticated safety requirements thatis embedded between the infrastructure layer and services them-selves CityGuard intercepts the actions from smart services de-tects whether potential conicts exist ahead of time and providesresolution whenever possible

11 Challengese key challenges in building a safety watchdog for smart citiesarise from the following three aspects

111 Defining Safety Requirements in Smart Cities In order tokeep a safe environment rigorous and consistent specications ofthe safety requirements for both a smart city and its smart servicesare important However it is dicult to integrate all the safetyrequirements from all services because they are dened undertheir own contexts with dierent granularity Furthermore anotherchallenge is how to dene safety requirements in the watchdogconsidering all the competing objectives of the smart city

112 Detecting Conflicts of Smart Services Detecting and re-solving the conicts of smart city services are both signicant anddicult for the following reasons

bull e eects of an action are hard to predict in a complexcity environment especially the secondary eects whichare also likely to violate city safety requirements

bull In addition to direct conicts there are indirect conictsIndirect conicts result from concurrent operations of mul-tiple actions each of which is safe individually but be-comes conicting when performed simultaneously

bull Eects of actions last over varying time intervals and areasand conicts may arise during those overlapping intervals

113 Implementation Due to the extremely complex function-alities of a smart city it is challenging to integrate all the smartservices and implement a watchdog architecture like CityGuarde implementation must be able to predict the eects of actionswith reasonable accuracy Presumably a combination of mathemat-ical models environmental models human behavioral models andheavy use of simulators will all be needed to detect and resolveconicts

12 ContributionsTo the best of our knowledge CityGuard is the rst work to builda safety-aware watchdog for detecting and resolving conicts be-tween services to address city safety requirements with three majorunderlying contributions

121 Specification and Definition of Safety Requirements andConflicts CityGuard species a set of safety requirements andidenties a broad spectrum of conicts in smart cities that areaware of the objectives of smart services

122 Detection of Conflicts CityGuard detects dierent typesof conicts by intercepting actions ahead of time analyzing thedetails of the actions and then running simulations to predictpotential conicts within a temporal and a spatial range ispaper focuses on conict detection especially for environmentalconicts In addition conict resolution with priority-based rulesare provided

123 Simulation and Evaluation on the Smart City Based onthe real data collected from New York City a smart city simulatornamely CityGuard SUMO is built with an emphasis on the do-mains of transportation environment and emergency services todemonstrate potential conicts in a real city Simulation is done in acontrolled seing Ten types of smart services are implemented andthen distributed to 20 major locations in the simulated Manhaan(ie 200 smart services are running in parallel) Each component ofCityGuard is evaluated by comparing results from the following 3scenarios (i) city without smart services (ii) city with smart ser-vices and (iii) city with smart services and CityGuard e resultsshow that CityGuard helps smart services running under safety andperformance requirements by identifying and preventing unsafeactions as well as detecting and resolving conicts

In regards to city safety CityGuard prevents up to 20 traccollisions caused by the 10 services within an hour interval andsaves up to 101 waiting time for emergency vehicles In terms

CityGuard A Watchdog for Safety-Aware Conflict Detection in Smart Cities IoTDI 2017 April 2017 Pisburgh PA USA

of city performance CityGuard increases air quality by 737 anddecreases vehicle waiting time by 35 over a baseline system (egcity operating without CityGuard)

2 CITY SAFETY AND CONFLICTIn order to fully understand CityGuard and its scope in this sectionwe dene terms related to the safety requirements the eects ofactions from services and the spectrum of conicts that are beingconsidered

21 Safety Requirements211 Coverage City safety generally involves safety for the

environment and humans Environmental Safety includes main-taining the quality of air water noise and weather and safety ofproperty For example actions taken by a service should not resultin air water or noise pollution or street lights should be kept onat night in crime-prone areas Human Safety refers to protect-ing citizens from any dangerous or unhealthy situation (eg roadaccidents)

Consequently the overall Smart System Safety means that all thesmart services running in a city must neither bring danger to theenvironment or citizens nor conict with each other For exampleautonomous vehicles are not allowed to hit pedestrians or causeenvironmental damage Also a smart trac service and a smartemergency service should not try to turn the same trac light togreen and red simultaneously

212 Context In the complex and dynamic seing of real timesmart cities safety and performance requirements need to be awareof context ie they need to accommodate special circumstancesbecause rigidstatic safety requirements can result in unwarranted catastrophic consequences For example assume a transportationdomain service sets the highest trac capacity of a street street Ato 100 to avoid congestion (ie a performance metric) although thestreet may accommodate more vehicles for a short time Howeverwhen there is a re on a nearby street street B vehicles may have toevacuate through street A (ie for safety) In this circumstance theperformance requirement of maintaining trac capacity in streetA should be aware of the safety requirement of street B us thesafety and performance requirements should be context aware

213 Emphasis As another complication range and frequencyof temporal and spatial entities should also be considered whenspecifying unsafe situations For example the trac congestionlasting for 5 min might not be considered as an unsafe situationbut the one lasting for 1 hour is unsafe

22 Eects of Actions from Services221 Primary and Secondary Eects Aer an action is taken

it has a series of eects on the city A primary eect relates to themain purpose of the action For example to control the noise levelin a school area the noise control service does not allow trucksto go through the school area during the day and redirects themto a nearby residential area e primary eect of this action isthe reduction of the noise level in the school area during day timeHowever this action may result in one or more secondary eectsFor example in this case the trac volume of the nearby residential

Table 1 Examples of conicts of services in smart cities

Category Type Example

Device Opposite Pedestrian service turn a trac signal to green while Trac Con-gestion Service turn the same trac signal to red

Device Numeric Trac Service set the speed of autonomous vehicles to be 70 mphSafety Service set the speed of them to be 60 mph

Device DurationEmergency service keeps the trac lights green for 10 minutes toallow ambulances to move faster while trac congestion serviceneeds it to turn red every 2 minutes

Environ-ment Single

Air quality control service redirect the trac to reduce air pollu-tion but cause serious trac congestion on the other road levelof which exceeds safety requirement

Environ-ment Opposite While emergency service tries to evacuate an area trac conges-

tion service directs more vehicles there

Environ-ment Additive

Event service caused a certain level of noise below thresholdemergency service caused a level of noise below threshold butthe additive level is above threshold

Environ-ment

Depen-dent

Trac service can only direct vehicles to street 1 aer the waterpipe leak is resolved by emergency service

area may increase as some trac is redirected from the school areaSuch secondary eects may have a serious inuence on the cityenvironment which may violate the city safety requirements

222 Spatial and Temporal Range Most eects of actions arenot limited to a single location at a single time Instead the eectshave spatial and temporal ranges of inuence which need to beconsidered when detecting conicts Following the above examplesince trucks have to drive on other roads when passing throughthis area the trucks will have an eect on the trac on these roadsand the added trac may cause congestion (ie a violation of aperformance requirement) for several hours Also an increasedvolume of trucks on a particular day may result in increased releaseof air pollutants causing air pollution (ie a violation of a safetyrequirement)

23 Spectrum of Conictse potential conicts of smart cities are categorized as device andenvironmental conicts as exemplied in Table 1

231 Device Conflicts When more than one action is taken onthe same device simultaneously if these actions are inconsistentwith each other they have a device conict In particular

bull if these actions have opposite directions but the samenumeric parameters it is an opposite device conict

bull if these actions have dierent numeric parameters andthese parameters cannot be satised at the same time it isa numeric device conict

bull if these actions have the same direction and parametersbut have dierent durations of application that cannot besatised at the same time it is a duration device conict

232 Environmental Conflict Besides the direct conicts onshared devices services are also prone to indirect conicts causedby unsafe or contrasting eects on the environment (resulting fromone or more actions) is is dened as an environmental conictEnvironmental conicts can be categorized into four classes asfollows

bull When the set of eects on the environment of a singleaction causes the state of the city to exceed a safety thresh-old or violate onemore safety requirements it results in asingle environmental conict


Figure 2 CityGuard Running in a Smart City

bull When the additive eects on the environment from twoor more safe actions exceed the safety thresholds or vio-late onemore safety requirements it results in an additiveenvironmental conict

bull When the eects of multiple actions are opposite on theenvironment and are not approved to happen by the safetyor performance requirements it results in an opposite envi-ronmental conict

bull When the eect of one action is the prerequisite of anotheraction ie multiple actions need to be performed sequen-tially or concurrently but the previous one is not taken itresults in a dependent environmental conict

3 SYSTEM OVERVIEW CITYGUARDCityGuard is a safety watchdog built between the smart servicesand the infrastructure layers (see Figure 1) CityGuard executesas a feedback loop as shown in Figure 2 Variables V1 through Vmmonitor city states and services S1 through Sn use the monitoreddata to choose actions CityGuard intercepts the actions decides ifthere is a device environment or both conicts based on the safetyand performance requirements Unsafe actions and conicts aredetected and resolved through CityGuard Safe actions are taken inthe city and cause the change of city states which triggers actionsfrom smart services again As a result the goal is that only safeactions are executed in the city However CityGuard does notguarantee safety but rather signicantly improve it as shown inthe evaluation

e internal structure of CityGuard is shown in Figure 3 ereare 4 important components in CityGuard City Safety and Perfor-mance Requirements (CSPR) City State and Service Action (CSSA)Pre-processing and Conict Detection and Resolution (CDR) Algo-rithm 1 shows how the components are executed

31 Safety and Performance RequirementsComponent

e safety and performance requirements component provides therules for CityGuard to monitor all the actions It has three modules(i) principles (ii) requirements and (iii) updating requirementsAll principles and requirements are dened and specied by citypersonnel CityGuard integrates them into the safety checkingcomponents

To start with CityGuard follows a set of principles to maintainsafety requirements For example it might contain

bull Any action of a service should not violate predened city individual service safety requirements

bull A safety requirement is a function of location and timewith conditions

bull When there is a conict between dierent safety require-ments follow the city objectives

CityGuard works with the safety and performance requirementsspecied by a particular smart city that is running CityGuard Forexample important safety and performance requirements for asmart city might include (i) Noise levels should be below the followingthresholds communityschool (Day 50 db night 45 db) Mallworkingzones (Day 60 db night 50 db) Highway (Day 70 db night 55 db) (ii)Actions taken by transportation services should not cause collision ofvehicles and (iii) emergency vehicles should not wait for more than10seconds at any intersection

ese requirements dened in English by the city are inte-grated and translated to formal metrics in CityGuard manuallyFor example the above requirements can be translated to (i) R1Noise (LocationTime ) lt xdb (ii) R2 Num(collision) lt 0 and (iii)R3 waitinдTime (E) lt 10s

Since the mapping between actions and safety requirements isnot always straightforward CityGuard simulates and analyzes theeects of an action on the metrics and therefore decides if it is a safeaction by examining if the metrics are within their requirements

Furthermore with new services added and situations changed inthe city safety and performance requirements are also added andupdated

32 Real City State and Service ActionComponent

City state and service action is considered as the interface of City-Guard to services and cities It obtains real city states and passesthem to CityGuard SUMO in the CDR obtaining a consistent viewof states in the real city and the simulated city Meanwhile italso stores and provides the in-coming actions from services andon-going actions in cities

33 Pre-Processing ComponentWhen an action Ai is intercepted by CityGuard it contains infor-mation to direct an actuator which is also the source for CityGuardto analyze potential conicts Usually an action has the followinginformation Device Number indicates a unique numerical identierof the actuator on which the action is supposed to be taken ServiceNumber indicates a unique numerical identier of the service thatissues the action Act is the expected action or eect which dependson the functions of the services and could be a change in states loca-tions or send a warning or message etc Duration is the requestedduration of this action Some actions are continuous actions andneed to be acted on for a certain time while some actions are justone time actions Pre-conditions indicate the pre-conditions of theaction mainly pointing to the essential concurrent or sequentialactions e format is ltActionID ConPregt

In a pre-processing phase CityGuard checks the above action in-formation and deals with any missing information Device number


Figure 3 CityGuard Structure (Pre-Processing intercepts and checks the safety of the single action Conflict Detection amp Reso-lution detects conicts among actions aer Pre-processing and City Safety amp Performance and Real City amp Service Action storethe safety requirements and city states respectively Section III describes each component in detail)

Figure 4 Eects of Actions Taken in the Smart City OverTime

and service number are easy to tell from the source and destinationof the action All acts are assumed to be contained in the action in-formation otherwise it cannot be executed by the actuator Unlessspecied the duration is treated as 0 if it is missing on the actioninformation It is a reasonable way to deal with missing durationbecause even if a continuous action is being treated as a one-timeaction it still has an eect on the city performance which will bedetected by the environmental conict detection procedure

Aer intercepting the actions CityGuard also needs to considerthe timing of the actions CityGuard denes three types of actionsbased on their action and eect times including In-coming actionsOn-going actions and Past actions An In-coming action is one justbeing intercepted and going to be checked by CityGuard An on-going action is the one that has been already checked by CityGuardand is running Because it is still using the device the in-comingaction which wants to take dierent action on that device may beconicting with it A past action is the one that has been taken andnished ough it may still have an eect on the city its eects arereected by the city environmental states erefore CityGuard

does not track these actions any more For example in Figure 4at T2 A1 is an on-going action A2 and A3 are in-coming actionsereby all of A1 A2 and A3 may be conicting and need to bechecked by CityGuard However at T4 when A4 comes in there isno on-going action then CityGuard only needs to check if T4 is asafe action in terms of the single action environmental conict

As a result three key parameters are retained by CityGuardie In-coming actions Ai An On-going actions and the CityStates V1 Viminus1

ree steps are performed in the pre-processingStep 1 Intercept actions and obtain their key informationStep 2 Check single actionsrsquo safety by running them in City-

Guard SUMO Send back unsafe actions with warnings to theirservices ((1)(2) in Figure 3)

Step 3 Check Device Number of in-coming and on-going actionsthen send the actions with same device number to DCDR becausethey have a potential device conict Pass the other actions to theECDR ((3) in Figure 3)

Aer pre-processing all the actions sent to the conict detectioncomponents are safe single actions

34 Conict Detection and ResolutionComponent

Conict Detection and Resolution Component consists of 4 subcomponents ie CityGuard SUMO Device Conict Detection andResolution (DCDR) Environmental Conict Detection and Resolu-tion (ECDR) and an Overall Resolver (OR)

CityGuard SUMO is the central component of the CDR which isused by both DCDR and ECDR to simulate the eects of actionson a real city e solution uses the Simulation of Urban MObility(SUMO) [7] a trac simulation that models inter-modal tracsystems including road vehicles public transport and pedestrians


Algorithm 1 CityGuardinput Action Set Ak output Safe Action Set Aprimek initialize CityState Vk SimulationState SVk Requirement Rk SimuStep = 0while Ak = 0 do

Pre-Processingfor action = 1 length(Ak ) do

SVk = Vk for SimuStep = 1 n do

SV primek = CityGuardSUMO (Ak SVk )fFC = SafeCheck SV primek Rk if fFC == 1 then

Aprimek = Resolve(Ak )end

endendDevcieConflictfDC = DeviceCheck (Aprimek )if (fDCi j == 0) (fDCi j == 1ampampAi == AjampampDur (Ai ) = Dur (Aj )) then

go to EnvironmentConictendif fDCi j == 1 then

if Ai == minusAj thenAprimek = Resolve(Ai Aj )

endif Ai + Aj gt Rk then

Aprimek = Resolve(Ai Aj )endif Dur (Ai ) = Dur (Ai ) then

Aprimek = Resolve(Ai Aj )end

endEnvironmentConflictSVk = Vk for SimuStep = 1 n do

SV primek = CityGuardSUMO (Aprimek SVk )fEC = check (SV primek Rk )if fEC == 1 then

Aprimek = Resolve(Ai )endif Ef (Ai ) == minusEf (Aj ) then

Aprimek = Resolve(Ai Aj )endif Ai larr Aj ampamp exist(Aj ) == 0 then

Aprimek = Resolve(Ai )end

endAprimek = OverallResolverAprimek

end

By implementing smart services and simulating real city scenariosin SUMO CityGuard SUMO plays an important role to test theprimary and secondary eects of actions To do this there aredierent Physical Models (PM) in CityGuard SUMO to simulatethe primary and secondary eects of actions For example thetrac - air PM knows how the numbers and speeds of dierenttypes of vehicles aect emissions (eg CO HC PM) quantitativelyAs a result the secondary eects on environments of actions fromtransportation services are obtained

Before executing CityGuard inputs into the simulator the samestates of the city where actions are going to be taken en it runsone or multiple actions in this scenario into a future time intervalNew states of the city aer taking these actions are sent back toDCDR and ECDR where the decisions of detection and resolutionconicts are made SUMO also has models to simulate accidents

341 Device Conflict Detection and Resolution Component iscomponent is shown in the le part of CDR in Figure 3 reetypes of device conicts are processed using dierent detectors and

resolvers with corresponding models Once potential device conictactions are received by DCDR their acts are sequentially checkedby opposite duration and numeric conict detection modules withthe steps described below

Step 1 Following the logic dened in Section II DCDR comparesthe given actions to detect if they are (i) opposite (ii) with dierentnumeric requests or (iii) the same Accordingly proceed to Steps 2through Step 4

Step 2 If they are (i) opposite call the opposite conict resolverwhich makes a decision according to ORR

Step 3 If they are (ii) with dierent numeric requests whetherthey are conicting depends on if they can be taken at the same timewhich is simulated in CityGuard SUMO If one action with the largernumerical request actually tolerates the others there is no numericconict because all of the actions can be satised Otherwise thenumeric resolver is called for decision making according to ORR

Step 4 If they are (iii) the same compare their durations Ifdurations are the same there is no device conict betweenamongthem and the actions are sent to ECDR If durations are dierentsimilar to Step 3 actions are simulated and tolerance is checkedA longer duration is accepted by its resolver if they are tolerantOtherwise a decision is made according to ORR

Step 5 All actions with a marked decision from DCDR are sentto ECDR

342 Environmental Conflict Detection and Resolution Compo-nent All the actions received by this component (shown on theright side of CDR in Figure 3) from the Pre-processing and DCDRcomponents are sent to run in CityGuard SUMO for N steps tosee their combined eects on the environment (see (6) in Figure 3)rough analyzing performance results from CityGuard SUMO andchecking with the safety and performance requirements ECDRdetects three types of environmental conicts with following steps

Step 1 Check if their additive eects conict with the city re-quirements which includes the situations when simulated statesexceed required thresholds and when forbidden unsafe cases hap-pen If so then there is an additive conict e additive resolver iscalled

Step 2 With the results from CityGuard SUMO the environmen-tal opposite conicts are detected by comparing the primary eectsdetected from pre-processing component with the combined eectsfrom ECDR If there is an opposite conict detected actions aresent to the corresponding resolvers If these opposite eects onthe environment violates safety requirements a resolver resolvesit according to ORR Otherwise the resolver decides whether toresolve it or not based on the context of the system

Step 3 In the dependent conict detection model pre-conditionsof actions are checked

Step 4 All marked actions are sent to the overall resolverAer DCDR and ECDR there is a set of actions with marked tem-

porary decisions If a single action violates the safety requirementsit is rejected in the pre-processing stage However actions whichare detected to have a device conict or an environmental conictreceive a temporary decision from each part respectively In thesecases the nal decision is made from the Overall Resolver It isnecessary for two reasons (i) generally DCDR and ECDR proceedin parallel and donrsquot intervene with each othersrsquo decisions and (ii)


it is able to avoid rejecting both actions accidentally For exampleactions rejected by one component because of conicting with an-other action which may also end up with a rejection in anotherresolver in next step With an overall resolver a nal decision ismade by considering the decisions from all the resolvers

In the Overall Resolver there is a set of actions with temporarydecisions marked for nal decision making Actions approvedby both DCDR and ECDR are considered as safe actions and canproceed in the real city Actions with both device and environmentconict rejections are rejected along with a rejection message sentback to their services Furthermore actions marked rejection byECDR are considered as unsafe actions to be rejected while actionsmarked with a device conict rejection are re-checked to see if theystill have conicts with other approved actions If not it is viewedas a safe action as well Otherwise it is rejected

In addition resolvers in the DCDR and ECDR sub-componentsfollow the Overall Resolution Rules (ORR) for decision making ereare two principles priority-based and performance-based to makedecisions when it concerns conicting actions from multiple ser-vices

First dierent domains have a priority based on their importanceto the city giving services from each domain the same priority Anexample priority is Safety gt Emergency gt Environment gt TracHowever dierent cities may value dierent domains

Second actions of the services from the same domain are decidedby their performances in CityGuard SUMO In the pre-processingcomponent each action is tested in the simulation and comes backwith a performance result If two actions in the same domainconict with each other and they are not unsafe the one withbeer performance is accepted while the other one(s) is rejected

4 SIMULATION AND EVALUATIONCityGurad is evaluated using a smart city simulator which is ex-tended from SUMO a transportation simulator e evaluation usesa real map of one-half of Manhaan New York City and generatessimulated scenarios based on real data Ten smart services fromthe domains of transportation emergency and environment areimplemented and installed in 20 major locations ese services arelisted in Table 2 Due to the limitations of SUMO only services fromthe above domains are implemented However these are examplesof the most common smart services running in real cities and areboth representative and important

41 Initialization and Metrics of SimulationIn order to simulate the performance of CityGuard in a real cityenvironment to start with real city data from Manhaan is ana-lyzed From Trac volume counts of New York city data [4] thetrac volumes from 160 streets in Manhaan during 2013-2014 areobtained It is calculated from the data set that the average tracvolume for all streets is 105397 vehicles and 658 vehicles per streetper hour making the in-coming vehicle rate as 55s per vehicle

In order to generate a scenario closest to the real trac paern inManhaan three steps are performed to congure the simulationFirst we selected the average trac volume data of Manhaanfrom 800 am to 200 am to generate the trac data stream in thesimulation Second the trac streams for main streets of New York

Figure 5 Simulated Manhattan with 10 services running at20 dierent locations (denoted as red points)

city such as the Bowery Allen Street and Broadway are set basedon their own average trac volume per street Finally stream datafor other streets follow the average volume for the entire Manhaanarea ie the in-coming rate of 55 svehicle is used In this way thelower half of Manhaan including 102 streets and 454 trac lightsare used as the platform for all simulations in the evaluation

Furthermore important safety and performance metrics arechosen for evaluation as shown in Table 3 e rst four met-rics are obtained from internal models of SUMO indicating thetransportation safety and performance For instance the possibil-ity of a collision happening increases when the density of tracincreases and the distance between vehicles shrinks Meanwhilethese metrics when applied to emergency vehicles also indicatethe performance of the emergency domain Moreover mean speedwaiting number and waiting time per lane are measured for trans-portation performance Noise CO HC and PMx are measured forenvironmental performance and are considered as safety metrics

For the evaluation the requirements shown in Table 4 are as-sumed to be specied for the smart city

To beer understand the complexity and scope of conictsthe pre-processing component is rst evaluated in isolation isdemonstrates the spatial and temporal eects of individual serviceNext the overall CityGuard is evaluated

42 Overall Evaluation421 Pre-processing In the Pre-processing component single

actions are intercepted and their primary and secondary eects onthe environment are simulated to see if there is any violation ofsafety or performance requirements

Spatial and temporal ranges of action eects are tested by City-Guard SUMO on 10 services in 20 locations At rst the city issimulated without services and the metrics for all the streets nearthe services are recorded as the baseline Each service is simulatedindividually in dierent locations and the same states are recordedand compared with the baseline If the variance is above 5 it isviewed as an eect on the streets from this action In this way thenumber of blocks away from the service block that are aected bythe action is identied for each service in all locations Similarlyhow long the eects last on the environment are also monitored

e results are shown in Table 5 the rst column are the met-rics the second column lists services running with and withoutCityGuard the third column is when there are no services at all


Table 2 Services running in Simulated Manhattan

No Service Domain Description

S1 Congestion Service Transportation Its purpose is to minimize trac congestion When the waiting number of vehicles on the lane exceeds 50 of its total tolerance it willadjust the trac signal to release congestion

S2 Pedestrian Service Transportation Its purpose is to minimize waiting time of pedestrians When more than 2 pedestrians press crossing buon it will shorten their waitingtime by adjusting trac signals

S3 Vehicle Navigator Transportation Its purpose is to release vehicles from trac congestion When there is a trac congestion or closed lane causing a vehicle waiting fora long time it will call the re-route function to choose the next shortest path to its destination

S4 Air Pollution Control Environment Its purpose is to control air quality level with emphasis on the CO and HC gas released by vehicles on streets It will limit the numberand speed of vehicles when air pollution level is high by adjusting trac signal and sending speed request to vehicles directly

S5 PM25PM10 Control Environment Similar to S4 with emphasis on the PM25 and PM10 in the airS6 Waste Management Environment Its purpose is to manage waste in cities by sending out waste pickup vehicles regularly

S7 Noise Control Environment Its purpose is to control noise pollution causing by trac When noise level exceeds its threshold it will control the number of vehiclesgoing through related streets and redirect vehicles on the streets by adjusting trac signals

S8 Event Service Environment Its purpose is to ensure smooth operation of a city event by blocking the lanes nearby the eventS9 Accident Service Emergency Its purpose is to take the rst action to block the adjacent areas of a trac accident

S10 Emergency Service Emergency Its purpose is to minimize the waiting time of emergency vehicles When there is an emergency vehicle waiting in the lane it willadjust the trac signal to let it go through immediately

Table 3 Metrics for Evaluation of City PerformanceS=Safety and P=Performance Metrics

Name Description

Jam (P) Number of cases when a vehicle can not continue because there wasno space on the next lane

Yield (P) Number of cases when a vehicle is unable to cross an intersectionwhere it did not have priority

Collision (S) Number of cases when a vehicle violated its minimal distancerequirement in relation to its leader vehicle

Wrong Lane(S)Number of cases when a vehicle was unable to move because it couldnot continue its route on the current lane and was unable to changeto the correct lane

Mean Speed (P) e mean speed of the vehicles on the specic lane (kmh)

Waiting Number (P) e number of vehicles waiting on the lane a speed of less than 01ms is considered a wait

Waiting Time (P) e time that a vehicle waits on the laneNoise (S) e noise emied by the vehicles on the specic lane (dB)

CO (S) e complete amount of CO emied by the vehicles on this laneduring the actual simulation step (mg)

HC (S) e complete amount of HC emied by the vehicles on this laneduring the actual simulation step (mg)

PMx (S) e complete amount of PMx emied by the vehicles on this laneduring the actual simulation step (mg)

and S1 to S10 are the data from just one service running Followinginsights are obtained from the results that are presented Table 5

When one service improves one aspect of city its secondaryeects may have a negative inuence on other metrics If notcontrolled this inuence may exceed the safety and performancerequirements

When there is no CityGuard actions from 5 services cause colli-sions which aect city safety signicantly and even create moreserious secondary eects ese collisions are prevented by City-Guard Meanwhile the number of jam and yield violations alsoexceeds the threshold of safety requirements which are highlightedin Table 5 However with control of CityGuard jam and yield fromall actions are controlled under the safety requirement

Another key metric for safety performance waiting time ofemergency vehicles (Row 8) is increased signicantly by 8 services exceeding the threshold of safety requirements With CityGuard itis controlled to under 10s For example waiting time of emergencyvehicle is reduced from 193s to 93s by CityGuard improving theperformance by 101

It is important to notice that in these 8 cases comparing the per-formance of other metrics when CityGuard runs with no services inthe city it improves the cityrsquos performance ie servicesrsquo functionsare not aected by CityGuard For example air pollution service

Table 4 City Safety Requirements

Transportationbull Actions should not cause collisions of vehiclesbull Vehicles should not be directed to travel in the wrong direction or to blocked roadsbull Trac signal lights should follow safety logicbull Vehicles from orthogonal directions should not cross an intersection simultaneouslybull Actions should not increase trac congestion by more than 10 bull Actions should not increase Yield by more than 15 bull Actions should not increase waiting time of emergency vehicles by more than 10bull e number of waiting vehicles in a lane should be less than the maximum vehicle

capacity of the laneEmergency

bull Emergency vehicles should not wait for more than 10s at a intersectionbull Emergency vehicles should not be directed to a blocked lane or area

Environmentbull Action should not create more than 50 dB noise per lanebull Action should not emit more than 50 mg CO per lanebull Action should not emit more than 1 mg HC per lanebull Action should not emit more than 02 mg PMx per lane

(S4) increases the waiting time of emergency vehicles to 15s withoutCityGuard and to 10s with CityGuard and where CO are 78mgand 76mg respectively Comparing with 1174mg of CO releasewithout any service S4 with CityGuard improves the air quality Asa result with CityGuard air quality is improved without aectingemergency vehicles In some cases service performance on one ortwo metrics is compromised with CityGuard because some of itsunsafe actions are rejected However CityGuardrsquos role here is toobtain a safe environment while helping services improve the cityFor example in column S1 waiting time for normal vehicles is 985seconds without CityGuard while 1002 with CityGuard oughthis performance is compromised by 2 seconds it still improvethe transportation performance comparing with the one withoutservice (12182 seconds) Most importantly the waiting time foremergency vehicles decreases from 115 to 10 comparing the resultswithout and with CityGuard consequently S1 is controlled to workunder safety requirements

If a service does not violate requirements at all it will not beaected by CityGuard such as S3 and S6

Some additional observations from these simulations arebull e ranges of spatial and temporal eects vary by functions

of services and locations For example Event Service (S8)usually has a longer eect time than the Congestion Service(S1) Eect range at Location 15 is always larger than thatat Location 20


Table 5 Eects on City with single services running

Metrics No S S1 S2 S3 S4 S5 S6 S7 S8 S9 S10

Jam No CG 102 100 422 60 102 68 102 84 402 222 290CityGuard - 100 110 60 102 68 102 84 86 120 120

Yield No CG 192 230 400 178 226 190 194 210 622 530 598CityGuard - 218 212 178 200 190 194 198 202 196 218

Collision No CG 0 0 4 0 2 0 0 0 4 4 6CityGuard - 0 0 0 0 0 0 0 0 0 0

Wrong Lane No CG 22 22 40 6 14 12 22 20 82 42 46CityGuard - 20 20 6 14 12 22 20 20 20 20

Mean Speed No CG 1128 1236 1029 1364 98 101 1128 1221 898 914 911CityGuard - 1322 111 1364 106 11 1128 135 1089 107 899

Waiting Number No CG 166 071 5 072 21 221 167 17 471 398 189CityGuard - 073 17 072 18 191 167 165 169 18 186

Waiting Time No CG 12182 9860 3117 1015 1501 1494 1219 1361 1413 1576 1814CityGuard - 1002 13097 1015 12941 13487 1219 1231 1318 1372 1347

Waiting Time (E) No CG 95 1150 133 1093 15 135 95 153 171 193 32CityGuard - 10 94 10 10 96 95 10 98 96 341

Noise No CG 3334 3498 4012 321 315 325 3334 176 376 396 394CityGuard - 3214 356 321 3093 311 3334 187 356 351 396

CO No CG 1174 1085 169 1065 78 741 1174 1161 134 1411 138CityGuard - 1075 124 1065 76 731 1174 1071 1231 1313 123

HC No CG 049 046 071 048 023 029 049 051 069 091 065CityGuard - 046 053 048 022 027 049 046 064 069 056

PMx No CG 008 007 012 069 005 003 008 008 011 017 011CityGuard - 007 009 069 005 003 008 008 01 013 009

(1)Without CityGuard (2)With CityGuard

Figure 6 Performances of trac at the intersection betweenBowery and Kenmare with and without CityGuard Yel-low and red objects denote regular and emergency vehiclesWith CityGuard there are higher trac ow less conges-tion and emergency vehicles are prioritized for faster traveltime

bull e eects are more signicant on the streets of the inter-section where services run rather than the neighboringstreets

bull e Accident Service (S9) has the largest average spatialeect range of up to 56 blocks while the Noise Service (S7)has the lowest one of 08 blocks e average eect rangefor all 10 services is 23 blocks

bull Temporal eects of dierent services vary signicantly notonly by service type and locations but also by the speciccontexts of the events For example the eect range ofservices is larger in area and longer in time when the tracdensity is heavier

422 Device Conflict Aer Pre-procesing actions on the samedevice (S1 S2 S4 S5 S7 and S10) are sent to the component of

DCDR Device Conicts detected between each two of them in 1hour are shown in Table 6 which indicates how many times ServiceA (services in the column) is triggered and how many times it isconicting with Service B (services in the row) For example thethird item in the second row rdquo2031342048rdquo indicates that out ofthe 42048 times Service S1 is triggered 20313 times it has a conictwith service S2

It is demonstrated that (i) conicts occur very frequently in thecity eg 20313 conicts happened between S1 and S2 and 31312times between S1 and S4 (ii) Percentages of device conicts arevery high eg device conicts between S1 and S3 is 745 whilethat between S7 and S2 is 686

Device conicts can cause serious consequences in the city ifthere is no prevention For instance in Figure 6 without CityGuardactions from emergency service and trac congestion service areconicting causing serious trac congestion More importantlyan emergency vehicle is trapped by this congestion is violatessafety requirements

423 Environmental Conflict In the environmental conict com-ponent integrated eects of concurrent actions are tested in simu-lated Manhaan e relationship between environmental conictsdetected and the number of services running in the city is analyzedN services are randomly chosen for 50 times and average perfor-mance is recorded Performance of representative metrics for safetyand performance ie number of collisions number of jams CO airpollution and trac waiting time per lane are shown in Figure 7leading to the following observations

bull Generally with the growing number of services running inthe city eects on the environment become worse if thereis no safety protection mechanism

bull e number of collisions increase signicantly when morethan 7 services are running together which seriously vio-lates city safety However there is no collision with City-Guard


Table 6 Pairwise Device Conicts Detected in 1 hour

S1 S2 S4 S5 S7 S10S1 - 2031342048 3131242048 10242048 29142048 304342048S2 2031354475 - 10854475 6254475 65354475 532154475S4 3131242588 10842588 - 7942588 43942588 498742588S5 102745 62745 79745 - 110745 311745S7 291952 653952 439952 110952 - 422952S10 30438217 53218217 49878217 3118217 4228217 -

(1) Number of collisions (2) Number of jam

(3) Maximum CO of lane (4) Waiting time

Figure 7 Comparison of Service Eects on Environmentwith and without CityGuard

bull Similar to the number of the collisions the number ofJams is also aected by the number of services runningwhich can be controlled under a performance thresholdwith CityGuard running

bull Although waiting time is not aected as drastically as othermetrics it is seen from Figure 7 (4) that CityGuard can helpthe city to obtain a relatively stable performance with in-creasing number of services When the number of servicesis 10 the waiting time is improved by 35

bull CityGuard improves Air quality (as measured by emissionof CO) over services without CityGuard by 513 when 5services are running and by 737 when 10 services arerunning

e total number of conicts detected are summarized by 20locations of services in Figure 8 In all locations environmentalconicts have the highest percentage which usually is at mosttwice the percentage of device conicts and as much as 4 times assingle unsafe actions Moreover the number of conicts vary fromlocation to location e busier and larger an intersection is themore conicts occur there

5 DISCUSSION AND LIMITATIONSSafety-aware conict detection and resolution are critical and com-plicated issues in smart cities which is dicult to be solved at once

Figure 8 Number of conicts detected from each location

CityGuard is a watchdog solution to dynamically improve the safetyof smart cities by focusing on actions that impact the environmentand act across services It does not and we argue fundamentallycannot apriori guarantee complete safety due to the dynamics anduncertainty in the real world It is a general architecture which canbe integrated into any Smart City IoT platform Being the rst workof its kind CityGuard has limited scope in the following issues

Safety Requirements In this paper it is assumed that actionsand requirements that are integrated with CityGuard have a uni-form format For example it is assumed that actions provide nec-essary information ie device act duration and pre-condition(s)e mapping of actions to the safety and performance requirementswere performed manually because the existing safety rules of citiesare dened in English by dierent government departments ereare no tools to translate them into code automatically Howeverthis manual mapping process doesnrsquot aect the generalizability ofCityGuard Also if new requirements arise the module called CitySafety amp Performance Requirement can update the requirementsmaintained in CityGuard and detect conicts using the new re-quirements (See Figure 3) In the future we will explore ways tospecify requirements and algorithmically map actions to require-ments In this case semantic token extraction techniques for textualinterventions [19] can be useful

Conict Detection and Safety Simulating the primary andsecondary eects of an action CityGuard checks the eects with thecity-wide safety requirements to check if there is a conict amongactions Many such conicts are found and resolved Howeversome smart services have their own internal safety requirementsnot directly visible to CityGuard CityGuard cannot always detectthe safety violation of internal safety requirements of a service un-less they impact the environment in a negative manner as speciedin the city-wide requirements erefore although currently City-Guardrsquos goal is to signicantly improve the safety of a city safetyviolations can still occur Ideally in the future as services are addedto a city all the internal safety requirements should be exported


and compared to the city wide requirements Any conicts hereshould also be resolved

Conict Resolution Currently CityGuard focuses on themethods for conict detection rather than providing a compre-hensive solution for conict resolution Only predened prioritybased resolvers are used to resolve conicts once they are detectedHowever in real scenarios conict resolutions can be much morechallenging and might require considering several contextual fac-tors e list of such factors includes but is not limited to theimportance of the action (ie that causes conict) and its servicethe eects on the environments and human beings the cost of rejec-tion the optimal combinations of conicting actions dynamicallychanging objectives etc us a comprehensive solution of conictresolution demands further research

Simulation In the current implementation of CityGuard theselection of applications and the accuracy of conict detectionrely on the accuracy of the SUMO simulation and its embeddedmodels is is reasonable as (i) SUMO has been widely used toprovide simulations on city mobility with sophisticated physicalmodels developed in research and used in practice for over 15 years(as described in Section 6) (ii) SUMO is only an example tool forCityGuard which can be updated combined or replaced with moresophisticated modelssimulators once they are available (iii) eevaluations in this paper are limited yet realistic to illustrate howwe detect conicts and improve a cityrsquos safety and performancee approach for conict detection in CityGuard is sophisticatedenough to be applied in other domains once accurate models ofthose domains are available

Human Factors When CityGuard simulates the potentialprimary and secondary eects of actions during its assessmentphase it assumes that the people (ie citizens) and the devicescomply with the recommended actions Decisions to accept orreject actions are based on these assumptions However the citystate evolves based on what actually happens in the city eg aperson may not follow the advice or an unexpected unprecedentedevent may occur CityGuard includes a feedback loop to monitorand react to this situation

Privacy and Security Privacy and security are of great signif-icance to a smart city As they are out of the scope of this paper abrief discussion below highlights the key issues

ere are potentially many dierent privacy policies in the smartservices and for the city as a whole Policies themselves mightconict with each other or be violated due to actions from servicesWhen actions are taken by services CityGuard can be extended tomatch those potential actions with city wide privacy policies andtherefore detect potential policy conicts dynamically In otherwords the core concepts found in CityGuard can be applied toprivacy If services export their privacy policies then conceptuallya general policy conict detection between the city and a servicecan be detected at installation time

ere are two main levels of security issues in the context of thiswork which are the security of smart services and the security ofCityGuard itself e security of smart services should be main-tained by themselves However if a service has been aacked andit is taking erroneous actions CityGuard helps in avoiding somesafety violations because those erroneous actions might conictwith the safety requirements known to CityGuard and therefore be

blocked In addition there are ways that CityGuard itself can beaacked such as approving unsafe actions blocking actions fromother services seing higher priority for the service etc ereforesecurity mechanisms must be included in CityGuard prior to realdeployment

6 RELATEDWORK61 IoT Platforms for Smart Citiesere are several commercially available IoT platforms for smartcities such as IBM Watson IoT [3] Azure IoT suite from Microso[2] Intel IoT platform [6] and AWS IoT from Amazon [1] eyprovide support for seing up IoT infrastructure customized to ap-plication requirements ey address dierent aspects of potentialcity-level IoT infrastructure including but not limited to scalabilityof sensing and actuator modules real-time response cloud supportfor IoT real-time stream analytics raw data storage data drivendynamic applications and network and data security Althoughsuch IoT platforms can be utilized for developing scalable smart cityservices they consider smart city applications as independent enti-ties Hence they donrsquot focus on the integration of services and itssubsequent complexity (eg concurrency and conicts) While theexisting IoT platforms provide support for safeguarding connecteddevices networks data transmissions and data accessibility of theIoT infrastructure none of them addresses the safety challengesintroduced by integration of systemsservices (eg conicting oper-ations policy violations and conicting eects of services) To thebest of our knowledge we are the rst to formulate and develop asafety-aware architecture for detecting and resolving potentialconicts in the context of smart cities

62 Safety in Automation SystemsSafety issues have been well studied in Automation systems Stan-dards and rules for functional safety of automation systems havebeen made such as IEC 61508 and ISO 26262 [10] which denefunctional safety for automotive equipment applicable throughoutthe lifecycle of all automotive electronic and electrical safety-relatedsystems ey support the product development from hardwaresoware and system levels and provide safety analysis ese stan-dards can be very helpful when extended to the development ofsingle smart services in smart cities However there are no rulesfor interactions or conicts among servicessystems

ere is some research on the functional safety among multi-agents in automation systems such as building automation andcontrol systems e authors in [16] focus on the functions af-fecting peoplersquos safety security and health while maintaining thefunctional safety and system security of both the network nodesand the communication protocols Resendes et al present a surveyon the conict detection and resolution in home and building au-tomation systems [20] Palloino et al propose a cooperative policyfor conict resolution in multi-vehicle systems which rests on theassumption that all agents are cooperating by implementing thesame trac rules [18] ese integrated systems are only withinthe domains of transportation homes and buildings Howeverfunctional safety in smart cities is much more complicated as itinvolve multiple domains dierent types of services and drasticallylarge numbers of actuators


63 Conict Detection and Resolutionere are some existing systems to detect dependencies across mul-tiple human centric CPS systems Munir et al focus on detectingdependencies across interventions generated by dierent human-in-the-loop apps (eg health apps) [14] ey use simulated apps andstructured metadata from each app ey rely on a physiologicalsimulator [9] to approximate potential eects of an interventionPreum et al developed Preclude a system to detect conicts intextual health advice generated from smart phone health applica-tions and health websites [19] While they provide a taxonomy ofconicts in health advice and solution to detect dierent types ofconicts their approach is focused on textual interventions only

Another relevant system is DepSys that aims at detecting depen-dencies from multiple smart home apps [15] It is a utility sensingand actuation infrastructure specically designed for smart homesthat detects and resolves conicts among multiple smart home appsby addressing multiple dependencies SIFT [11] a safety centricprogramming platform detects whether apps running in an IoTenvironment conform to safety policies and whether apps result inlogical conict with each other Although it detects logical conicts(equivalent to opposite conict of CityGuard) using rule based ap-proach it does not consider dierent nuances of detecting conicts policy violations eg eects secondary eects emphasis andconditions and it is not applied to inter-services problems

Our previous work proposed a comprehensive typology of con-icts and a watchdog architecture for conict detection and reso-lution in the context of smart city applications [12] It identiesdierent characteristics of smart city services that contribute topotential conicts in smart cities eg uncertainty real-time dy-namic behavior of services spatio-temporal constraints durationand scale of eects It focuses on the runtime device conict detec-tion and detect conicts by imposing pseudo-services on historicaldata

64 City SimulatorSUMO [7] is an open source microscopic trac ow simulationwhich can import netmap and trac demand modeling compo-nents It has been utilized in several trac ow related researchsuch as vehicular communication route choice and dynamic navi-gation trac light algorithms emission and noise modeling person-based Intermodal trac simulation In our work SUMO is usedas a smart city simulator with help of Trac Control Interface(TraCI) [21] a technique for interlinking road trac and networksimulators With TraCI the behavior of vehicles during simulationruntime can be controlled and thus the inuence of actions on thesimulated city are beer understood

7 CONCLUSIONCityGuard a safety-aware novel watchdog architecture for de-tecting and resolving conicts in a smart city is developed andevaluated CityGuard is safety-aware as it focuses on maintainingsafety requirements by detecting and resolving conicts before theyoccur In doing so CityGuard also considers the context of potentialconicts and resolves conicts to maximize performance metricsCityGuard is able to simulate the primary and the secondary eectsof the actions performed by services detect and resolve conicts

among those actions and thus improve safety Evaluations areperformed using a simulation of part of New York City with 10smart services located in 20 places Using 6 safety metrics and 5performance metrics the evaluation shows that CityGuard is ableto minimize safety violations and improve overall city performancewhen compared to baseline methods

ACKNOWLEDGMENTis work was funded in part by NSF under grants CNS-1527563 andCNS-1319302

REFERENCES[1] AWS IoT hpsawsamazoncomiot[2] Azure IoT Hub documentation hpsazuremicrosocomen-usdocumentation

servicesiot-hub[3] IBM Watson IoT Platform hpwwwibmcominternet-of-things[4] New York City Open Data hpsnycopendatasocratacom[5] Oracle Smart City hpswwworaclecomapplicationsprimaverasolutions

smart-city-projectsindexhtml[6] e Internet of ings (IoT) Starts with Intel Inside hpwwwintelcomcontent

wwwuseninternet-of-thingsoverviewhtml[7] Michael Behrisch Laura Bieker Jakob Erdmann and Daniel Krajzewicz 2011

SUMOndashsimulation of urban mobility an overview In Proceedings of SIMUL 2011eird International Conference on Advances in System Simulation inkMind

[8] Pierfrancesco Bellini Monica Benigni Riccardo Billero Paolo Nesi and NadiaRauch 2014 Km4City ontology building vs data harvesting and cleaning forsmart-city services Journal of Visual Languages amp Computing 25 6 (2014)827ndash839

[9] Robert L Hester Alison J Brown Leland Husband Radu Iliescu Drew PrueRichard Summers and omas G Coleman 2011 HumMod a modeling environ-ment for the simulation of integrative human physiology Frontiers in physiology2 (2011)

[10] M Kucharski A Trujillo C Dunlop and B Ahdab 2012 ISO 26262 SowareCompliance Achieving Functional Safety in the Automotive Industry TechnicalReport Technical report

[11] Chieh-Jan Mike Liang Borje F Karlsson Nicholas D Lane Feng Zhao JunbeiZhang Zheyi Pan Zhao Li and Yong Yu 2015 SIFT building an internet ofsafe things In Proceedings of the 14th International Conference on InformationProcessing in Sensor Networks ACM 298ndash309

[12] M Ma S Masud Preum W Tarneberg M Ahmed M Ruiters and J Stankovic2016 Detection of Runtime Conicts among Services in Smart Cities In 2016IEEE International Conference on Smart Computing (SMARTCOMP) IEEE 1 ndash10

[13] Fei Miao Shuo Han Shan Lin John A Stankovic Desheng Zhang Sirajum MunirHua Huang Tian He and George J Pappas 2016 Taxi dispatch with real-timesensing data in metropolitan areas A receding horizon control approach IEEETransactions on Automation Science and Engineering 13 2 (2016) 463ndash478

[14] Sirajum Munir Mohsin Y Ahmed and John A Stankovic EyePhy DetectingDependencies in Cyber-Physical System Apps due to Human-in-the-Loop ()

[15] Sirajum Munir John Stankovic and others 2014 DepSys Dependency awareintegration of cyber-physical systems for smart homes In Cyber-Physical Systems(ICCPS) 2014 ACMIEEE International Conference on IEEE 127ndash138

[16] omas Novak Albert Treytl and Peter Palensky 2007 Common approachto functional safety and system security in building automation and controlsystems In Emerging Technologies and Factory Automation 2007 ETFA IEEEConference on IEEE 1141ndash1148

[17] Peter Palensky and Dietmar Dietrich 2011 Demand side management Demandresponse intelligent energy systems and smart loads IEEE transactions onindustrial informatics 7 3 (2011) 381ndash388

[18] Lucia Palloino Vincenzo G Scordio Antonio Bicchi and Emilio Frazzoli 2007Decentralized cooperative policy for conict resolution in multivehicle systemsIEEE Transactions on Robotics 23 6 (2007) 1170ndash1183

[19] Sarah M Preum Md Abu Sayeed Mondol Meiyi Ma Hongning Wang andJohn A Stankovic 2017 Preclude Conict Detection in Textual Health AdviceIn Pervasive Computing and Communications (PerCom) 2017 IEEE InternationalConference on IEEE

[20] Sılvia Resendes Paulo Carreira and Andre C Santos 2014 Conict detectionand resolution in home and building automation systems a literature reviewJournal of Ambient Intelligence and Humanized Computing 5 5 (2014) 699ndash715

[21] Axel Wegener Micha l Piorkowski Maxim Raya Horst Hellbruck Stefan Fischerand Jean-Pierre Hubaux 2008 TraCI an interface for coupling road trac andnetwork simulators In Proceedings of the 11th communications and networkingsimulation symposium ACM 155ndash163

Abstract

1 Introduction

11 Challenges

12 Contributions

2 City Safety and Conflict

21 Safety Requirements

22 Effects of Actions from Services

23 Spectrum of Conflicts

3 System Overview CityGuard

31 Safety and Performance Requirements Component

32 Real City State and Service Action Component

33 Pre-Processing Component

34 Conflict Detection and Resolution Component

4 Simulation and Evaluation

41 Initialization and Metrics of Simulation

42 Overall Evaluation

5 Discussion and Limitations

6 Related Work

61 IoT Platforms for Smart Cities

62 Safety in Automation Systems

63 Conflict Detection and Resolution

64 City Simulator

7 Conclusion

References


Figure 1 CityGuard in the Smart City

bull In most cases the safety requirements from services onlyconsider the primary eects (eg minimize congestion)while ignoring secondary eects on the environment (egair pollution) thus violating safety requirements

bull e safe actions dened by smart services may not alwaysbe safe for a smart city when considering (i) the eectsof those actions over a time interval an area and (ii) theactions taken by other services

bull Devices and services might be updated over time withoutnotifying other services Even though services may havepre-dened safety requirements and rules to avoid conictsnew conicts may arise as smart services evolve over thelong term

Hence a safety-aware watchdog architecture called CityGuardis created to detect and resolve the conicts from multiple smartservices in a smart city (see Figure 1) Generally the smart cityis constructed of two main parts (i) an infrastructure layer withsensors and actuators and (ii) a soware layer consisting of IoTplatforms and individual smart services CityGuard is designedto be a middle layer with sophisticated safety requirements thatis embedded between the infrastructure layer and services them-selves CityGuard intercepts the actions from smart services de-tects whether potential conicts exist ahead of time and providesresolution whenever possible

11 Challengese key challenges in building a safety watchdog for smart citiesarise from the following three aspects

111 Defining Safety Requirements in Smart Cities In order tokeep a safe environment rigorous and consistent specications ofthe safety requirements for both a smart city and its smart servicesare important However it is dicult to integrate all the safetyrequirements from all services because they are dened undertheir own contexts with dierent granularity Furthermore anotherchallenge is how to dene safety requirements in the watchdogconsidering all the competing objectives of the smart city

112 Detecting Conflicts of Smart Services Detecting and re-solving the conicts of smart city services are both signicant anddicult for the following reasons

bull e eects of an action are hard to predict in a complexcity environment especially the secondary eects whichare also likely to violate city safety requirements

bull In addition to direct conicts there are indirect conictsIndirect conicts result from concurrent operations of mul-tiple actions each of which is safe individually but be-comes conicting when performed simultaneously

bull Eects of actions last over varying time intervals and areasand conicts may arise during those overlapping intervals

113 Implementation Due to the extremely complex function-alities of a smart city it is challenging to integrate all the smartservices and implement a watchdog architecture like CityGuarde implementation must be able to predict the eects of actionswith reasonable accuracy Presumably a combination of mathemat-ical models environmental models human behavioral models andheavy use of simulators will all be needed to detect and resolveconicts

12 ContributionsTo the best of our knowledge CityGuard is the rst work to builda safety-aware watchdog for detecting and resolving conicts be-tween services to address city safety requirements with three majorunderlying contributions

121 Specification and Definition of Safety Requirements andConflicts CityGuard species a set of safety requirements andidenties a broad spectrum of conicts in smart cities that areaware of the objectives of smart services

122 Detection of Conflicts CityGuard detects dierent typesof conicts by intercepting actions ahead of time analyzing thedetails of the actions and then running simulations to predictpotential conicts within a temporal and a spatial range ispaper focuses on conict detection especially for environmentalconicts In addition conict resolution with priority-based rulesare provided

123 Simulation and Evaluation on the Smart City Based onthe real data collected from New York City a smart city simulatornamely CityGuard SUMO is built with an emphasis on the do-mains of transportation environment and emergency services todemonstrate potential conicts in a real city Simulation is done in acontrolled seing Ten types of smart services are implemented andthen distributed to 20 major locations in the simulated Manhaan(ie 200 smart services are running in parallel) Each component ofCityGuard is evaluated by comparing results from the following 3scenarios (i) city without smart services (ii) city with smart ser-vices and (iii) city with smart services and CityGuard e resultsshow that CityGuard helps smart services running under safety andperformance requirements by identifying and preventing unsafeactions as well as detecting and resolving conicts

In regards to city safety CityGuard prevents up to 20 traccollisions caused by the 10 services within an hour interval andsaves up to 101 waiting time for emergency vehicles In terms
















Environ-ment Single






Environ-ment

Depen-dent
































































end














































Name Description






















































S1 S2 S4 S5 S7 S10S1 - 2031342048 3131242048 10242048 29142048 304342048S2 2031354475 - 10854475 6254475 65354475 532154475S4 3131242588 10842588 - 7942588 43942588 498742588S5 102745 62745 79745 - 110745 311745S7 291952 653952 439952 110952 - 422952S10 30438217 53218217 49878217 3118217 4228217 -




















































Abstract

1 Introduction

11 Challenges

12 Contributions














6 Related Work




64 City Simulator

7 Conclusion

References
















Environ-ment Single






Environ-ment

Depen-dent
































































end














































Name Description






















































S1 S2 S4 S5 S7 S10S1 - 2031342048 3131242048 10242048 29142048 304342048S2 2031354475 - 10854475 6254475 65354475 532154475S4 3131242588 10842588 - 7942588 43942588 498742588S5 102745 62745 79745 - 110745 311745S7 291952 653952 439952 110952 - 422952S10 30438217 53218217 49878217 3118217 4228217 -




















































Abstract

1 Introduction

11 Challenges

12 Contributions














6 Related Work




64 City Simulator

7 Conclusion

References






















































end














































Name Description






















































S1 S2 S4 S5 S7 S10S1 - 2031342048 3131242048 10242048 29142048 304342048S2 2031354475 - 10854475 6254475 65354475 532154475S4 3131242588 10842588 - 7942588 43942588 498742588S5 102745 62745 79745 - 110745 311745S7 291952 653952 439952 110952 - 422952S10 30438217 53218217 49878217 3118217 4228217 -




















































Abstract

1 Introduction

11 Challenges

12 Contributions














6 Related Work




64 City Simulator

7 Conclusion

References































Name Description






















































S1 S2 S4 S5 S7 S10S1 - 2031342048 3131242048 10242048 29142048 304342048S2 2031354475 - 10854475 6254475 65354475 532154475S4 3131242588 10842588 - 7942588 43942588 498742588S5 102745 62745 79745 - 110745 311745S7 291952 653952 439952 110952 - 422952S10 30438217 53218217 49878217 3118217 4228217 -




















































Abstract

1 Introduction

11 Challenges

12 Contributions














6 Related Work




64 City Simulator

7 Conclusion

References






























S1 S2 S4 S5 S7 S10S1 - 2031342048 3131242048 10242048 29142048 304342048S2 2031354475 - 10854475 6254475 65354475 532154475S4 3131242588 10842588 - 7942588 43942588 498742588S5 102745 62745 79745 - 110745 311745S7 291952 653952 439952 110952 - 422952S10 30438217 53218217 49878217 3118217 4228217 -




















































Abstract

1 Introduction

11 Challenges

12 Contributions














6 Related Work




64 City Simulator

7 Conclusion

References








































Abstract

1 Introduction

11 Challenges

12 Contributions














6 Related Work




64 City Simulator

7 Conclusion

References

CityGuard: A Watchdog for Safety-Aware Conflict Detection...

Documents

Transcript of CityGuard: A Watchdog for Safety-Aware Conflict Detection...