SaSTL: Spatial Aggregation Signal Temporal Logic for Runtime Monitoring in Smart Cities

SaSTL: Spatial Aggr egation Signal T emporal Logic f or Runtime Monitoring in Smart Cities Meiyi Ma Department of Computer Science University of V ir ginia Charlottesville, USA Email: meiyi@vir ginia.edu Ezio Bartocci F aculty of Informatics TU W ien V ienna, Austria Email: ezio.bartocci@tuwien.ac.at Eli Lifland, John Stankovic, Lu Feng Department of Computer Science University of V ir ginia Charlottesville, USA Email: {edl9cy , stankovic, lu.feng}@vir ginia.edu Abstract —W e present SaSTL—a novel Spatial Aggregation Signal T emporal Logic—for the efficient runtime monitoring of safety and performance requirements in smart cities. W e first describe a study of over 1,000 smart city requir ements, some of which can not be specified using existing logic such as Signal T emporal Logic (STL) and its variants. T o tackle this limitation, we develop tw o new logical operators in SaSTL to augment STL for expressing spatial aggregation and spatial counting characteristics that are commonly f ound in real city requir ements. W e also dev elop efficient monitoring algorithms that can check a SaSTL requirement in parallel over multiple data str eams (e.g., generated by multiple sensors distributed spatially in a city). W e evaluate our SaSTL monitor by applying to two case studies with large-scale r eal city sensing data (e.g., up to 10,000 sensors in one requirement). The results show that SaSTL has a much higher coverage expressiv eness than other spatial-temporal logics, and with a significant reduction of computation time for monitoring requirements. W e also demonstrate that the SaSTL monitor can help impro ve the safety and performance of smart cities via simulated experiments. Keyw ords -Spatial T emporal Logic, runtime monitoring, re- quirement specification, smart cities I . I N T R O D U C T I O N Smart cities are emerging around the world. Examples include Chicago’ s Array of Things project [1], IBM’ s Rio de Janeiro Operations Center [2] and Cisco’ s Smart+Connected Operations Center [3], just to name a fe w . Smart cities utilize a vast amount of data and smart services to enhance the safety , efficienc y , and performance of city operations [4], [5]. There is a need for monitoring city states in real-time to ensure safety and performance requirements [6]. If a requirement violation is detected by the monitor , the city operators and smart service providers can take actions to change the states, such as improving traffic performance, rejecting unsafe actions, sending alarms to polices, etc. The key challenges of dev eloping such a monitor include how to use an e xpressive, machine-understandable language to spec- ify smart city requirements, and ho w to efficiently monitor requirements that may in volve multiple sensor data streams (e.g., some requirements are concerned about thousands of sensors in a smart city). Previous works [7], [8], [9], [10] hav e proposed solutions to monitor smart cities using formal specification languages and their monitoring machinery . One of the latest works, CityResolver [11] uses Signal T emporal Logic (STL) [12] to support the specification-based monitoring of safety and performance requirements of smart cities. Howe ver , STL is not expressi ve enough to specify smart city requirements concerning spatial information such as “the average noise level within 1 km of all elementary schools should always be less than 50 dB” . There are some existing spatial extensions of STL (e.g., SSTL [13], SpaT eL [10] and STREL [14]), which can express requirements such as “ther e should be no traffic congestion on all the r oads in the northeast dir ection” . But they are not expressi ve enough to specify requirements like “ther e should be no traf fic congestion on all the r oads on average” , or “on 90% of the r oads” , which require the aggregation and counting of signals in the spatial domain. T o tackle these challenges and limitations, we develop a novel Spatial Aggregation Signal T emporal Logic (SaSTL), which extend STL with two new logical operators for expressing spatial aggregation and spatial counting characteristics that are commonly found in real city requirements. More specifically , this paper has the following major contributions : (1) T o the best of our knowledge, this is the first work studying and annotating over 1,000 real smart city requirements across different domains to identify the gap of expressing smart city requirements with existing formal specification languages. As a result, we found that aggre- gation and counting signals in the spatial domain (e.g., for representing sensor signals distributed spatially in a smart city) are extremely important for specifying and monitoring city requirements. (2) Drawing on the insights from our requirement study , we dev elop a new specification language SaSTL, which ex- tends STL with a spatial aggr e gation operator and a spatial counting operator . SaSTL can be used to specify Point of Interests (PoIs), the physical distance, spatial relations of the PoIs and sensors, aggregation of signals over locations, degree/percentage of satisfaction and the temporal elements Figure 1: A framew ork for runtime monitoring of real-time city requirements in a very flexible spatial-temporal scale. (3) W e compare SaSTL with some existing specification languages and show that SaSTL has a much higher cov erage experessi veness (95%) than STL (18.4%), SSTL (43.1%) or STREL (43.1%) ov er 1,000 real city requirements. (4) W e dev elop novel and efficient monitoring algorithms for SaSTL. In particular, we present two ne w methods to speed up the monitoring performance: (i) dynamically pri- oritizing the monitoring based on cost functions assigned to nodes of the syntax tree, and (ii) parallelizing the monitoring of spatial operators among multiple locations and/or sensors. (5) W e ev aluate the SaSTL monitor by applying it to a case study of monitoring real city data collected from the Chicago’ s Array of Things [1]. The results show that SaSTL monitor has the potential to help identify safety violations and support the city managers and citizens to make decisions. (6) W e also e v aluate the SaSTL monitor on a second case study of conflict detection and resolution among smart services in simulated New Y ork city with large-scale real sensing data (e.g., up to 10,000 sensors in one requirement). Results of our simulated experiments show that SaSTL monitor can help improve the city’ s performance (e.g., 21.1% on the environment and 16.6% on public safety), with a significant reduction of computation time compared with previous approaches. I I . A P P R OAC H O V E R V I E W Figure 1 shows an overvie w of our SaSTL runtime monitoring framework for smart cities. W e en vision that such a framew ork would operate in a smart city’ s central control center (e.g., IBM’ s Rio de Janeiro Operations Cen- ter [2] or Cisco’ s Smart+Connected Operations Center [3]) where sensor data about city states across various locations are av ailable in real time. The framew ork would monitor city states and check them against a set of smart city requirements at runtime. The monitoring results would be presented to city managers to support decision making. The framew ork makes abstractions of city states in the follo wing way . The framew ork formalizes a set of smart city require- ments (See Section III) to some machine checkable SaSTL formulas (See Section IV). Different data streams (e.g. CO emission, noise lev el) over temporal and spatial domains can be viewed as a 3-dimensional matrix. For any signal s j in signal domain S , each row is a time-series data at one location and each column is a set of data streams from all locations at one time. Next, the ef ficient real-time monitoring for SaSTL verifies the states with the requirements and outputs the Boolean satisfaction to the decision makers, who would take actions to resolve the violation. T o support decision making in real time, we improv e the efficiency of the monitoring algorithm in Section V. W e will describe more details of the framew ork in the following sections. I I I . A N A L Y S I S O F R E A L C I T Y R E Q U I R E M E N T S T o better understand real city requirements, we conduct a requirement study . W e collect and statistically analyze 1000 quantitativ ely specified city requirements (e.g., standards, regulations, city codes, and laws) across different applica- tion domains, including energy , en vironment, transportation, emergenc y , and public safety from large cities (e.g. New Y ork City , San Francisco, Chicago, W ashington D.C., Bei- jing, etc.). Some examples of these city requirements are highlighted in T able I. W e identify key required features to hav e in a specification language and its associated use in a city runtime monitor . The summarized statistical results of the study and key elements we identified (i.e., temporal, spatial, aggregation, entity , comparison, and condition) are shown in T able II. T emporal : Most of the requirements include a variety of temporal constraints, e.g. a static deadline, a dynamic deadline, or time intervals. In many cases (65.7%), the tem- poral information is not explicitly written in the requirement, which usually means it should be “always” satisfied. In addition, city requirements are highly real-time driv en. In ov er 80% requirements, cities are required to detect and resolve requirement violations at runtime. It indicates a high demand for runtime monitoring. Spatial : A requirement usually specifies its spatial range explicitly using the Points of Interest (PoIs) (80.1%), such as “park”, “xx school”, along with a distance range (65%). T able I: Examples of city requirements from different domains (The key elements of a requirement are highlighted as, temporal , spatial , aggregation , entity , condition , comparison . ) Domain Example T ransportation Limits vehicle idling to one minute adjacent to any school, pre-K to 12th grade , public or private, in the City of New Y ork [15]. The engine, power and exhaust mechanism of each motor vehicle shall be equipped, adjusted and operated to prev ent the escape of a trail of visible fumes or smoke for more than ten (10) consecutive seconds [16]. Prohibit sight-seeing buses from using all bus lanes between the hours of 7:00 a.m. and 10:00 a.m. on weekdays [17]. Energy Operate the system to maintain zone temperatures down to 55°F or up to 85°F [18]. The total leakage shall be less than or equal to 4 cubic feet per minute per 100 square feet of conditioned floor area [19]. En vironment LA Sec 111.03 minimum ambient noise lev el table: ZONE M2 and M3 – DA Y : 65 dB(A) NIGHT : 65 dB(A) [20]. The total amount of HCHO emission should be less than 0.1mg per m 3 within an hour , and the total amount of PM10 emission should be less than 0.15 mg per m 3 within 24 hours [21]. Emergency NYC Authorized emergency vehicles may disregard 4 primary rules regarding traffic [22]. At least one ambulance should be equipped per 30,000 population (counted by area ) to obtain the shortest radius and fastest response time [23]. Public Safety Security staff shall visit at least once per week in public schools [24]. T able II: Ke y elements of city requirements and statistical results from 1000 real city requirements Element Form Num Example T emporal Dynamic Deadline 77 limit ... to one minute Static Deadline 98 at least once a week Interval 168 from 8am to 10am; within 24 hours; Default 657 The noise (always) should not exceed 50dB. Spatial PoIs/T ags 801 school area; all parks; Distance 650 Nearby Default 154 (ev erywhere) ; (all) locations Aggregation Count, Sum 256 in total; x out of N locations; %; A verage 196 per m 2 ; Max, Min 67 highest/lo west value Entity Subject 1000 air quality; Buses; Comparison V alue comparison 836 More than, less than Boolean 388 Street is blocked; should Not 456 It is unlawful/prohibited... Condition Until 24 k eep... until the street is not blocked. If/Except 44 If rainy , the speed limit... One requirement usually points to a set of places (e.g. all the schools). Therefore, it is very important for a formal language to be able to specify the spatial elements across many locations within the formula, rather than one formula for each location. W e also found that the city requirements specify a very large spatial scale. Different from the requirements of many other cyber physical systems, requirements from smart cities are highly spatial-specific and usually in volv e a very large number of locations/sensors. For example, the first require- ment in T able I specifies a vehicle idling time “adjacent to any school, pre-K to 12th grade in the City of Ne w Y ork”. There are about 2000 pre-K to 12th schools, ev en counting 20 street segments nearby each school, there are 40,000 data streams to be monitored synchronously . An efficient monitoring is highly demanded. Aggregation : In 51.9% cases, requirements are specified on the aggregated signal over an area, such as, “the to- tal amount”, “av erage...per 100 square feet”, “up to four vending vehicles in any giv en city block”, “at least 20% of travelers from all entrances should ... ”, etc. Therefore, aggregation is a key feature for the specification language. I V . F O R M A L I Z I N G T E M P O R A L - S PA T I A L R E Q U I R E M E N T S SaSTL extends STL with two spatial operators: a spatial aggr e gation operator and a neighborhood counting operator . Spatial aggregation enables combining (according to a cho- sen operation) measurements of the same type (e.g., environ- mental temperature), but taken from different locations. The use of this operator can be suitable in requirements where it is necessary to ev aluate the av erage, best or worst v alue of a signal measurement in an area close to the desired location. The neighborhood counting operator allows measuring the number/percentage of neighbors of a location that satisfy a certain requirement. In this section, we formally define the syntax, and semantics. A. SaSTL Syntax W e define a multi-dimensional spatial-temporal signal as ω ∶ T × L → { R ∪ {  }} n , where T = R ≥ 0 , represents the continuous time and L is the set of locations. W e define X = { x 1 , ⋯ , x n } as the set of variables for each location. Each variable can assume a real value v ∈ R or is undefined for a particular location ( x i =  ). W e denote by π x i ( ω ) as the projection of ω on its component variable x i ∈ X . W e define P = { p 1 , ⋯ , p m } a set of propositions (e.g. { Scho ol , Street , Hospital , ⋯ } ) and L a labeling function L ∶ L → 2 P that assigns for each location the set of the propositions that are true in that location. A weighted undirected graph is a tuple G = ( L, E , η ) where L is a finite non-empty set of nodes representing locations, E ⊆ L × L is the set of edges connecting nodes, and η ∶ E → R ≥ 0 is a cost function ov er edges. W e define the weighted distance between two locations l , l ′ ∈ L as d ( l, l ′ ) ∶ = min { ∑ e ∈ σ η ( e ) ∣ σ is a path between l and l ′ } . Then we define the spatial domain D as, D ∶ = ([ d 1 , d 2 ] , ψ ) ψ ∶ = ⊺ ∣ p ∣ ¬ ψ ∣ ψ ∨ ψ where [ d 1 , d 2 ] defines a spatial interval with d 1 < d 2 and d 1 , d 2 ∈ R , and ψ specifies the property ov er the set of propositions that must hold in each location. In particular , D = ([ 0 , +∞ ) , ⊺ ) indicates the whole spatial domain. W e denote L l ([ d 1 ,d 2 ] ,ψ ) ∶ = { l ′ ∈ L ∣ 0 ≤ d 1 ≤ d ( l, l ′ ) ≤ d 2 and L ( l ′ ) ⊧ ψ } as the set of locations at a distance between d 1 and d 2 from l for which L ( l ′ ) satisfies ψ . W e denote the set of non-null values for signal variable x at time point t location l over locations in L l D by α x D ( ω , t, l ) ∶ = { π x ( ω )[ t, l ′ ] ∣ l ′ ∈ L l D and π x ( ω )[ t, l ′ ] ≠  } . W e define a set of operations op ( α x D ( ω , t, l )) for op ∈ { max , min , sum , a vg } when α x D ( ω , t, l ) ≠ ∅ that computes the maximum, minimum, summation and average of values in the set α x D ( ω , t, l ) , respectiv ely . T o be noted, Graph G and its weights between nodes are constructed flexibly based on the property of the system. For example, we can build a graph with fully connected sensor nodes and their Euclidean distance as the weights when monitoring the air quality in a city; or we can also build a graph that only connects the street nodes when the two streets are contiguous and apply Manhattan distance. It does not affect the syntax and semantics of SaSTL. The syntax of SaSTL is giv en by ϕ ∶ = x ∼ c ∣ ¬ ϕ ∣ ϕ 1 ∧ ϕ 2 ∣ ϕ 1 U I ϕ 2 ∣ A op D x ∼ c ∣ C op D ϕ ∼ c where x ∈ X , ∼∈ { < , ≤ } , c ∈ R is a constant, I ⊆ R > 0 is a real positiv e dense time interval, U I is the bounded until temporal operators from STL. The always (denoted ◻ ) and eventually (denoted ◊ ) temporal operators can be derived the same w ay as in STL, where ◊ ϕ ≡ true U I ϕ , and ◻ ϕ ≡ ¬◊¬ ϕ . W e define a set of spatial aggr e gation operators A op D x ∼ c for op ∈ { max , min , sum , avg } that ev aluate the aggregated product of traces op ( α x D ( ω , t, l )) over a set of locations l ∈ L l D . W e also define a set of new spatial counting opera- tors C op D ϕ ∼ c for op ∈ { max , min , sum , avg } that counts the satisfaction of traces over a set of locations. More precisely , we define C op D ϕ = op ({ g (( ω , t, l ′ ) ⊧ ϕ ) ∣ l ′ ∈ L l D }) , where g (( ω , t, l ) ⊧ ϕ )) = 1 if ( ω , t, l ) ⊧ ϕ , otherwise g (( ω, t, l ) ⊧ ϕ )) = 0 . From the ne w counting operators, we also deri ve the everywher e operator as ⧈ D ϕ ≡ C min D ϕ > 0 , and somewher e operator as  D ϕ ≡ C max D ϕ > 0 . In addition, C sum D ϕ specifies the total number of locations that satisfy ϕ and C avg D ϕ specifies the percentage of locations satisfying ϕ . W e no w illustrate ho w to use SaSTL to specify various city requirements, especially for the spatial aggregation and spatial counting, and how important these operators are for the smart city requirements using examples below . Example 1 (Spatial Aggregation) . Assume we have a re- quir ement, “The average noise level in the school ar ea (within 1 km) in New Y ork City should always be less than 50 dB and the worst should be less than 80 dB in the next 3 hours” is formalized as, ⧈ ([ 0 , +∞ ) , School ) ◻ [ 0 , 3 ] (( A avg ([ 0 , 1 ] , ⊺ ) x Noise < 50 ) ∧ ( A max ([ 0 , 1 ] , ⊺ ) x Noise < 80 )) . ([ 0 , +∞ ) , Scho ol ) selects all the locations labeled as “school” within the whole New Y ork city ( [ 0 , +∞ ) ) (pre- defined by users). ◻ [ 0 , 3 ] indicates this requirement is valid for the next three hours. ( A avg ([ 0 , 1 ] , ⊺ ) x Noise < 50 ) ∧ ( A max ([ 0 , 1 ] , ⊺ ) x Noise < 80 ) calculates the average and maximal values in 1 km for each “school”, and compares them with the requirements, i.e. 50 dB and 80 dB. W ithout the spatial aggregation operators, STL and its extended languages cannot specify this requirement. First, they are not able to first dynamically find all the locations labeled as “school”. T o monitor the same spatial range, users hav e manually get all traces from schools, and then repeatedly apply this requirement to each located sensor within 1 km of a school and do the same for all schools. More importantly , STL and its extended languages could not specify “av erage” or “worst” noise level. Instead, it only monitors each single value, which is prone to noises and outliers and thereby causes inaccurate results. Example 2 (Spatial Counting) . A r equirement that “At least 90% of the streets, the particulate matter (PMx) emission should not exceed Moderate in 2 hours” is formalized as C avg ([ 0 , +∞ ) , Street ) ( ◻ [ 0 , 2 ] ( x PMx < Mo derate )) > 0 . 9 . C avg ([ 0 , +∞ ) , Street ) ϕ > 0 . 9 represents the percentage of sat- isfaction is larger than 90%. Specifying the percentage of satisfaction is very common and important among city requirements. B. SaSTL Semantics W e define the SaSTL semantics as the satisfiability rela- tion ( ω, t, l ) ⊧ ϕ , indicating that the spatio-temporal signal ω satisfies a formula ϕ at the time point t in location l when π v ( ω )[ t, l ] ≠  and α x D ( ω , t, l ) ≠ ∅ . W e define that ( ω , t, l ) ⊧ ϕ if π v ( ω )[ t, l ] =  . ( ω , t, l ) ⊧ x ∼ c ⇔ π x ( ω )[ t, l ] ∼ c ( ω , t, l ) ⊧ ¬ ϕ ⇔ ( ω , t, l ) / ⊧ ϕ ( ω , t, l ) ⊧ ϕ 1 ∧ ϕ 2 ⇔ ( ω , t, l ) ⊧ ϕ 1 and ( ω , t, l ) ⊧ ϕ 2 ( ω , t, l ) ⊧ ϕ 1 U I ϕ 2 ⇔ ∃ t ′ ∈ ( t + I ) ∩ T ∶ ( ω , t ′ , l ) ⊧ ϕ 2 and ∀ t ′′ ∈ ( t, t ′ ) , ( ω , t ′′ , l ) ⊧ ϕ 1 ( ω , t, l ) ⊧ A op D x ∼ c ⇔ op ( α x D ( ω , t, l )) ∼ c ( ω , t, l ) ⊧ C op D ϕ ∼ c ⇔ op ({ g (( ω, t, l ′ ) ⊧ ϕ ) ∣ l ′ ∈ L l D }) ∼ c V . E FFI C I E N T M O N I T O R I N G F O R S A S T L In this section, we first present monitoring algorithms for SaSTL, then describe two optimization methods to speed up the monitoring performance. A. Monitoring Algorithms for SaSTL The inputs of the monitor are the SaSTL requirements ϕ (including the time t and location l ), a weighted undirected graph G and the temporal-spatial data ω . The output of the monitoring algorithm for each requirement is a Boolean value indicating whether the requirement is satisfied or not. Algorithm 1 outlines the monitoring algorithm. T o start with, the monitoring algorithm parses ϕ to sub formulas and calculates the satisfaction for each operation recursively . W e deriv ed operators ◻ and ◊ from U I , and operators ⧈ and  from C op D ∼ c , so we only sho w the algorithms for U I and C op D ∼ c . Algorithm 1: SaSTL monitoring algorithm Monitor( ϕ, ω, t, l, G ) Function Monitor( ϕ, ω, t, l, G ) : Input : SaSTL Requirement ϕ , Signal ω , T ime t , Location l , weighted undirected graph G Output: Satisfaction V alue (Boolean value) begin switch ϕ do Case x ∼ c return π x ( ω )[ t, l ] ∼ c ; Case ¬ ϕ return ¬ Monitor( ϕ, ω, t, l, G ); Case ϕ 1 ∧ ϕ 2 ; ▷ See Algorithm 4 return Monitor( ϕ 1 , ω , t, l, G ) ∧ Monitor( ϕ 2 , ω , t, l, G ) Case ϕ 1 U I ϕ 2 return SatisfyUntil( ϕ 1 , ϕ 2 , I , ω, t, l, G ); Case A op D x ∼ c ; ▷ See Algorithm 2 return Aggregate ( x, c, op, D , t, l, G ) ; Case C op D ϕ ∼ c ; ▷ See Algorithm 3 for the standard version, and Algorithm 5 for an impro ved parallel version. return CountingNeighbours ( ϕ, c, op, D , t, l, G ) ; end end W e present the satisfaction algorithms of the operators A op D and C op D in Algorithm 2 and Algorithm 3, respectiv ely . As we can tell from the algorithms, essentially , A op D cal- culates the aggregated values on the signal ov er a spatial domain, while C op D calculates the aggregated Boolean results ov er spatial domain. The time complexity of monitoring the logical and tempo- ral operators of SaSTL is the same as STL [25] as follows. ● The time complexity to monitor classical logical oper- ators or basic propositions such as ¬ x , ∧ and x ∼ c is O ( 1 ) . ● The time complexity to monitor temporal operators such as ◻ I , ◊ I , U I is O ( T ) , where T is the total number of samples within time interval I . In this paper, we present the time complexity analysis for the spatial operators (Lemma 1) and the new SaSTL monitoring algorithm (Theorem 1). The total number of locations is denoted by n . W e assume that the positions of the locations cannot change in time (a fixed grid). W e can Algorithm 2: Aggregation of ( x, op, D , ω , t, l, G ) Function Aggregate( x, c, op, D , ω, t, l, G ) : begin Real v := 0; n := 0; if op == "min" then v ∶ = ∞ ; if op == "max" then v ∶ = −∞ ; for l ′ ∈ L l D do if op ∈ { min, max, sum } then v := op ( v , π x ( ω )[ t, l ′ ]) ; end if op == "avg" then v := sum ( v , π x ( ω )[ t, l ′ ]) ; end n ∶ = n + 1 end if op == "avg" ∧ n ≠ 0 then v ∶ = v / n ; if n == 0 then return T rue else return v ∼ c ; end end Algorithm 3: Counting of ( x, op, D , ω , t, l , G ) Function CountingNeighbours( ϕ, c, op, D , ω, t, l, G ) : begin Real v ∶ = 0 ; n ∶ = 0 if op == "min" then v ∶ = ∞ ; if op == "max" then v ∶ = −∞ ; for l ′ ∈ L l D do if Monitor ( ϕ, ω, t, l, G ) ∧ op ∈ { min, max, sum } then v := op ( v , 1 ) ; end if Monitor ( ϕ, ω, t, l, G ) ∧ op == "avg" then v := sum ( v , 1 ) ; end n ∶ = n + 1 end if op == "avg" ∧ n ≠ 0 then v ∶ = v / n ; if n == 0 then return T rue else return v ∼ c ; end end precompute all the distances between locations and store them in an array of range trees [26] (one range tree for each location). W e further denote the monitored formula as φ , which can be represented by a syntax tree, and let ∣ φ ∣ denote the total number of nodes in the syntax tree (number of operators). Lemma 1 (Complexity of spatial operators) . The time complexity to monitor at each location l at time t the satisfaction of a spatial operator such as ⧈ D ,  D , A op D , and C op D is O ( l og ( n ) + ∣ L ∣) wher e L is the set of locations at distance within the range D fr om l . Pr oof: According to [26], the time complexity to re- triev e a set of nodes L with a distance to a desired location in a range D from a location l is O ( log ( n ) + ∣ L ∣) . The aggregation and counting operations of Algorithm 2 and Algorithm 3 can be performed while the locations are retriev ed. Theorem 1. The time complexity of the SaSTL monitor- ing algorithm is upper-bounded by O (∣ φ ∣ T max ( log ( n ) + ∣ L ∣ max )) wher e T max is the lar gest number of samples of the intervals considered in the temporal operator s of φ and ∣ L ∣ max is the maximum number of locations defined by the spatial temporal operators of φ . Pr oof: Following Lemma 1, by considering T max the worst possible number of samples that we need to consider for all possible intervals of temporal operators present in the formula, and ∣ L ∣ max for the worst possible number of locations that we need to consider for all possible interv als of spatial operators present in the formula. When there are two or more operators nested, the time comple xity for one opera- tion is bounded by O ( T max ( log ( n ) + ∣ L ∣ max )) . As there are ∣ φ ∣ nodes in the syntax tree of φ , the time complexity of the SaSTL monitoring algorithm is bounded by the summation ov er all ∣ φ ∣ nodes, which is O (∣ φ ∣ T max ( log ( n ) + ∣ L ∣ max )) . B. P erformance Impro vement of SaSTL P arsing T o monitor a requirement, the first step is parsing the requirement to a set of sub formulas with their corresponding spatial-temporal ranges. Then, we calculate the results for the sub formulas. The traditional parsing process of STL builds and calculates the syntax tree on the sequential order of the formula. It does not consider the complexity of each sub-formula. Howe ver , in man y cases, especially with the PoIs specified in smart cities, checking the simpler propositional variable to quantify the spatial domain first can significantly reduce the number of temporal signals to check in a complicated formula. For example, the city abstracted graph in Figure 2, the large nodes represent the locations of PoIs, among which the red ones represent the schools, and blue ones represent other PoIs. The small black nodes represent the locations of data sources (e.g. sensors). Assum- ing a requirement ⧈ ([ 0 , +∞ ] , School ) ◻ [ a,b ] ( A op ([ 0 ,d ] , ⊺ ]) ϕ ∼ c ) requires to aggregate and check ϕ only nearby schools (i.e., the red circles), but it will actually check data sources of all nearby 12 nodes if one is following the traditional parsing algorithm. In New Y ork City , there are about 2000 primary schools, but hundreds of thousands of PoIs in total. A very large amount of computing time would be wasted in this way . T o deal with this problem, we now introduce a monitoring cost function cost ∶ Φ × L × G L → R + , where Φ is the set of all the possible SaSTL formulas, L is the set of locations, G L is the set of all the possible undirected graphs with L locations. The cost function for ϕ is defined as: cost ( ϕ, l , G ) = ⎧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎨ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎩ 1 if ϕ ∶ = p ∨ ϕ ∶ = x ∼ c ∨ ϕ ∶ = T rue 1 + cost ( ϕ 1 , l , G ) if ϕ ∶ = ¬ ϕ 1 cost ( ϕ 1 , l , G ) + cost ( ϕ 2 , l , G ) if ϕ ∶ = ϕ 1 ∗ ϕ 2 , ∗ ∈ { ∧ , U I } ∣ L l D ∣ if ϕ ∶ = A op D x ∼ c ∣ L l D ∣ cost ( ϕ 1 , l , G ) if ϕ ∶ = C op D ϕ 1 ∼ c Figure 2: An example of city abstracted graph. A require- ment is ⧈ ([ 0 , +∞ ] , School ) ◻ [ a,b ] ( A op ([ 0 ,d ] , ⊺ ) ϕ ∼ c ) (The large nodes represent the locations of PoIs, among which the red ones represent the schools, and blue ones represent other PoIs. The small black nodes represent the locations of data sources.) Using the above function, the cost of each operation is calculated before “switch ϕ ” (refer Algorithm 1). The cost function measures ho w complex it is to monitor a particular SaSTL formula. This can be used when the algorithm ev aluates the ∧ operator and it establishes the order in which the sub-formulas should be ev aluated. The simpler sub-formula is the first to be monitored, while the more complex one is monitored only when the other sub-formula is satisfied. W e update monitor ( ϕ 1 ∧ ϕ 2 , ω ) in Algorithm 4. Algorithm 4: Satisfaction of ( ϕ 1 ∧ ϕ 2 , ω ) case ϕ 1 ∧ ϕ 2 do return Monitor( ϕ 1 , ω , t, l, G ) ∧ Monitor( ϕ 2 , ω , t, l, G ); if cost ( ϕ 1 , l, G ) ≤ cost ( ϕ 2 , l, G ) then if ¬ Monitor( ϕ 1 , ω , t, l, G ) then return Monitor( ϕ 2 , ω , t, l, G ); end return True; end if ¬ Monitor( ϕ 2 , ω , t, l, G ) then return Monitor( ϕ 1 , ω , t, l, G ); end return True; end W ith this cost function, the time complexity of the monitoring algorithm is reduced to O (∣ φ ∣ T max ( log ( n ) + ∣ L ′ ∣ max )) , where ∣ L ′ ∣ is the maximal number of locations that an operation is ex ecuted with the improv ed parsing method. The improvement is significant for monitoring smart cities, because for most of the city requirements, ∣ L ′ ∣ max < 100 × ∣ L ∣ max . C. P arallelization In the traditional STL monitor algorithm, the signals are checked sequentially . For example, to see if the data streams from all locations satisfy ⧈ D ◻ [ a,b ] ϕ in Figure 2, usually , it would first check the signal from location 1 with ◻ [ a,b ] ϕ , then location 2, and so on. At last, it calculates the result from all locations with ⧈ D . In this example, checking all locations sequentially is the most time-consuming part, and it could reach ov er 100 locations in the field. T o reduce the computing time, we parallelize the monitor - ing algorithm in the spatial domain. T o briefly explain the idea: instead of calculating a sub-formula ( ◻ [ a,b ] ϕ ) at all locations sequentially , we distribute the tasks of monitoring independent locations to different threads and check them in parallel. (Algorithm 5 presents the parallel version of the spatial counting operator C D .) T o start with, all satisfied locations l ′ ∈ L l D are added to a task pool (a queue). In the mapping process, each thread retriev es monitoring tasks (i.e., for l i , ◻ [ a,b ] ϕ ) from the queue and executes them in parallel. All threads only execute one task at one time and is assigned a new one from the pool when it finishes the last one, until all tasks are ex ecuted. Each task obtains the satisfaction of Monitor ( ϕ, ω , t, l, G ) function, and calculates the local result v i of operation op () . The reduce step sums all the parallel results and calculates a final result of op () . Algorithm 5: Parallelization of Counting of ( x, op, D , ω, t, l, G ) Function CountingNeighbours( ϕ, op, D , ω, t, l, G ) : begin paratasks = Queue(); for l ′ ∈ L l D do paratasks.add( l ); end results = Queue(); for i in 1 .. NumThreads do Thread i ← worker( ϕ, ω , t, G ); end W ait(); return op(results); end Function worker ( ϕ, ω , t, G ) : begin Real v ∶ = 0 ; if op == "min" then v ∶ = ∞ ; ; if op == "max" then v ∶ = −∞ ; ; while Num(tasks)>0 do l = paratasks.pop(); moni = Monitor( ϕ, ω , t, l, G ); v = op(v , moni); end results.add(v) end Lemma 2. The time complexity of the parallelized algorithm Monitor( φ , ω ) is upper bounded by O (∣ φ ∣ T max ( log ( n ) + ∣ L ∣ max P )) when distributed to P threads. In general, the parallel monitor on the spatial domain re- duces the computational time significantly . It is very helpful to support runtime monitoring and decision making, espe- cially for a large number of requirements to be monitored in a short time. In practice, the computing time also depends on the complexity of temporal and spatial domains as well as the amount of data to be monitored. A comprehensiv e experimental analysis of the time complexity is presented in Section VI. V I . E V A L U A T I O N W e ev aluate the SaSTL monitor by applying it to two city application scenarios, which are (i) runtime monitoring (1) Chicago (2) New Y ork Figure 3: Partial Maps of Chicago and New Y ork with PoIs and sensors annotated. (The black nodes represent the locations of sensors, red nodes represent the locations of hospitals, dark blue nodes represent schools, light blue nodes represent parks and green nodes represent theaters.) T able III: Information of T wo Application Scenarios Chicago New Y ork Area (km 2 ) 606 60 Data T ype Real-time States Real-time Predicted States Data Sources Real Sensors Simulated Sensors and Actuators Number of Sensor Nodes 118 10,000 Time Period 2017.01-2019.05 - Sampling Rate 1 min 10 seconds Domain En vironment, Public Safety En vironment, Transportation, Events, Emergencies, Public Safety V ariables CO, NO, O 3 , Visible light, Crime Rate CO, NO, O 3 , PM x , Noise, Traf fic, Pedestrian, Signal Lights, Emergency V ehicles, Accidents of city requirements in Chicago, and (ii) runtime conflict detection and resolution among smart services in a simulated New Y ork City . Then, (iii) we compared the coverage expressi veness of SaSTL against 1000 real city requirements with STL, SSTL, and STREL. W e provide the information of two application scenarios in T able III. Figure 3 presents the partial maps of two cities, where the locations of PoIs and sensors are marked. A. Runtime Monitoring of Real-T ime Requir ements in Chicago 1) Intr oduction: W e apply SaSTL to monitor the real- time requirements in Chicago. The framew ork is the same as shown in Figure 1, where we first formalize the city require- ments to SaSTL formulas and then monitor the city states with the formalized requirements. Chicago is collecting and publishing the city data [1], [27] e very day since January , 2017 without a state monitor . In this e v aluation, we emulate the real data as it arrives in real time, i.e. assuming the city was operating with the monitor . Then we specify 80 safety and performance requirements that are generated from the real requirements, and apply the SaSTL to monitor the data ev ery 3 hours continuously to identify the requirement violations. Figure 4: Requirement Satisfaction Rate during Different T ime Periods in Chicago 2) Chicago P erformance: V aluable information is iden- tified from the monitor results of different periods during a day . W e randomly select 30 days of weekdays and 30 days of weekends. W e divide the daytime of a day into 4 time periods and 3 hours per time period. W e calculate the percentage of satisfaction (i.e., number of satisfied requirement days divides 30 days) for each time period, respectiv ely . The results of two example requirements CR1 and CR2 are shown in Figure 4. CR1 specifies “The average air quality within 5km of all schools should always be abov e Moderate in the next 3 hours. ” and is formalized as ⧈ ([ 0 , +∞ ) , School ) ◻ [ 0 , 3 ] ( A avg ([ 0 , 5 ] , ⊺ ) x air > Mo derate ) . CR2 spec- ifies “For the blocks with a high crime rate, the a verage light lev el within 3 km should alw ays be High ” and is formalized as ⧈ ([ 0 , +∞ ) , ⊺ ) ◻ [ 0 , 3 ] ( x Crime = High → A avg ([ 0 , 3 ] , ⊺ ) x Light >= High ) . The SaSTL monitor results can be potentially used by different stakeholders. First, with pr oper requir ements defined, the city decision makers ar e able to identify the real pr oblems and take actions to r esolve or even avoid the violations in time . For example, from the two e xample requirements in Figure 4, we could see over 20% of the time the requirements are missed ev eryday . Based on the monitoring results of requirement CR1, decision makers can take actions to redirect the traffic near schools and parks to improve the air quality . Another example of requirement CR2, the satisfaction is much higher (up to 33% higher in CR2, 8pm - 11pm) o ver weekends than workdays. There are more people and vehicles on the street on weekends, which as a result also increases the lighted areas. Howe ver , as shown in the figure, the city lighting in the areas with high crime rate is only 60%. An outcome of this result for city managers is that they should pay attention to the illumination of workdays or the areas without enough light to enhance public safety . Second, it gives the citizens the ability to learn the city conditions and map that to their own requir ements . They can make decisions on their daily li ving, such as the good time to visit a park. For example, requirement CR1, 11am - 2pm has the lowest satisfaction rate of the day . The instantaneous air quality seems to be fine during rush hour , but it has an accumulati ve result that af fects citizens’ Figure 5: Number of Requirements Checked on Different Computing T ime (x: the number of requirements, y: the number of threads, bars: different periods of computing time) (especially students and elderly people) health. A potential suggestion for citizens who visit or exercise in the park is to av oid 11am - 2pm. 3) Algorithm P erformance: W e count the average mon- itoring time taken by each requirement when monitoring for 3-hour data. Then, we divide the computing time into 5 categories, i.e., less than 1 second, 1 to 10 seconds, 10 to 60 seconds, 60 to 120 seconds, and longer than 120 seconds, and count the number of requirements under each cate gory under the conditions of standard parsing, improved parsing with single thread, 4 threads, and 8 threads. The results are shown in Figure 5. Comparing the 1st (standard parsing) and 4th (8 threads) bar , without the improved monitoring algorithms, for about 50% of the requirements, each one takes more than 2 minutes to execute. The total time of monitoring all 80 requirements is about 2 hours, which means that the city decision maker can only take actions to resolve the violation at earliest 5 hours later . Howe ver , with the improved monitoring algorithms, for 49 out of 80 requirements, each one of them is ex ecuted within 60 seconds, and each one of the rest requirements is ex ecuted within 120 seconds. The total execution time is reduced to 30 minutes, which is a reasonable time to handle as many as 80 requirements. More importantly , it illustrates the effec- tiv eness of the parsing function and parallelization methods. Even if there are more requirements to be monitored in a real city , it is doable with our approach by increasing the number of processors. B. Runtime Conflict Detection and Resolution in Simulated New Y ork City 1) Intr oduction: The framew ork of runtime conflict de- tection and resolution [28] considers a scenario where smart services send action requests to the city center , and where a simulator predicts how the requested actions change the current city states ov er a finite future horizon of time. In this way , we use SaSTL monitor to specify requirements and check the pr edicted spatial-temporal data with the SaSTL T able IV: Safety and Performance Requirements for New Y ork City Requirement SaSTL NYR1 The average noise level in the school area (within 1km) should always be less than 50dB in the next 30min. ⧈ ([ 0 , +∞ ) , School ) ◻ [ 0 , 30 ] ( A avg ([ 0 , 1 ] , ⊺ ) x Noise < 50 ) NYR2 If an accident happens, at least one of the nearby hospitals (within 5km), its traffic condition within 2km should not reach the lev el of congestion in the next 60 min. ⧈ ([ 0 , +∞ ] , ⊺ ) ( Accident → C ([ 0 , 5 ] , Hospital ) ( ◻ [ 0 , 60 ] ( A avg ([ 0 , 2 ] , ⊺ ) x < Congestion )) > 0 ) NYR3 If there is an event, the max number of pedestrians waiting in an intersection should not be greater than 50 for more than 10 minutes. ⧈ ([ 0 , +∞ ) , ⊺ ) ( Event → ◻ [ 0 , 10 ] ( A max ([ 0 , 1 ] , ⊺ ) x ped < 50 )) NYR4 At least 90% of the streets, the PMx emission should not exceed Moderate in 60 min. C avg ([ 0 , +∞ ) , ⊺ ) ( ◻ [ 0 , 60 ] ( A max ([ 0 , 1 ] , ⊺ ) x PMx < Moderate )) > 0 . 9 NYR5 If an accident happens, it should be solved within 60 min, and before that nearby (500 m) traffic should be above moderate on av erage and safe in worst case. ⧈ ([ 0 , +∞ ) , ⊺ ) ( Accident → ( A avg ([ 0 , 500 ] , ⊺ ) x traffic < Moderate ∧ A max ([ 0 , 500 ] , ⊺ ) x traffic < Safe ) U [ 0 , 60 ] ¬ Accident ) formulas. If there exists a requirement violation within the future horizon, a conflict is detected. T o resolve the conflict, it provides se veral possible resolution options and predicts the outcome of all these options, which are verified by the SaSTL monitor . It finds the best option without a violation, otherwise, it provides the trade-offs between a few potential resolution options to the city manager through monitoring the predicted traces. Details of the resolution are not the main part of this paper and we thank the original authors for making the solution a vailable to the authors of the present paper . W e set up a smart city simulation of Ne w Y ork City using the Simulation of Urban MObility (SUMO) [29] with the real city data [30], on top of which, we implement 10 smart services (S1: Traf fic Service, S2: Emergenc y Service, S3: Accident Service, S4: Infrastructure Service, S5: Pedestrian Service, S6: Air Pollution Control Service, S7: PM2.5/PM10 Service, S8: Parking Service, S9: Noise Control Service, and S10: Event Service). The states from the domains of en vironment, transportation, ev ents and emergencies are generated from about 10000 simulated nodes. Please see T able III for the variables. W e use the STL Monitor as the baseline to compare the capability of requirement specification and the ability to improve city performance. W e simulate the city run- ning for 30 days in three control sets, one without any monitor , one with the STL monitor and one with the SaSTL monitor . For the first set (no monitor), there is no requirement monitor implemented. For the second one (STL monitor), we specify NYR1 to NYR5 using STL without aggregation ov er multiple locations, i.e., NYR1 is a set of requirements on many locations and each location has a temporal requirement. For example, NYR1 is specified as ϕ l i = ◻ [ 0 ,t ] ( x air > Mo derate ) , where l i ∈ L , L is a set of sensors within the range. The setting is the same for the rest of the requirements. F or the third one (SaSTL monitor), fiv e examples of different types of real-time requirements and their formalized SaSTL formulas are giv en in T able IV. 2) NY City P erformance: The results are shown in T a- ble V. W e measure the city performance from the domains of transportation, en vironment, emergenc y and public safety using the follo wing metrics, the total number of violations detected, the average CO (mg) emission per street, the av erage noise (dB) le vel per street, the emer gency vehicles waiting time per vehicle per intersection, the av erage number and waiting time of vehicles waiting in an intersection per street, and the average pedestrian waiting time per intersection. T o be noted, the number of violations detected is the total number of safety requirements violated, rather than the number of conflicts. Many times there is more than one requirement violated in one conflict. T able V: Comparison of the City Performance with the STL Monitor and the SaSTL Monitor No Monitor STL Monitor SaSTL Monitor Number of Violation Unknown 219 173 Air Quality Index 67.91 51.22 40.18 Noise (db) 73.32 49.27 41.42 Emergency W aiting Time (s) 20.32 12.93 11.88 V ehicle W aiting Number 22.7 18.2 12.6 Pedestrian W aiting Time (s) 190.2 130.9 61.1 V ehicle W aiting Time (s) 112.12 70.98 59.22 W e make some observations by comparing and analyzing the monitoring results. First, the SaSTL monitor obtains a better city performance with fewer number of violations detected under the same scenario. As shown in T able V, the number of violations detected by SaSTL Monitor is 46 less than the STL monitor . On a verage, the framew ork of conflict detection and resolution with the SaSTL monitor improv es the air quality by 21.6% and 40.8% comparing to the one with the STL monitor and without a monitor , respecti vely . It improv es the pedestrian waiting time by 16.6% and 47.2% comparing to the STL monitor and without a monitor, respectiv ely . Second, the SaSTL monitor r eveals the r eal city issues, helps r efine the safety requir ements in r eal time and supports impr oving the design of smart services. W e also compare the number of violations on each requirement. The results (Figure 6 (1)) help the city managers to measure city’ s performance with smart services for different aspects, and also help policymak ers to see if the requirements are too strict to be satisfied by the city and make a more realistic requirement if necessary . For example, in our 30 days simulation, apparently , NYR4 on air pollution is the one requirement that is violated by most of the smart services. Similarly , Figure 6 (2) sho ws the number of violations caused by different smart services. Most of the violations are caused by S1, S5, S6, S7, and S10. The fi ve major services in total cause 71.3% of the violations. City service developers can also learn from these statistics to adjust the requested actions, the inner logic and parameters of the functions of the services, so that they can design a more compatible service with more acceptable actions in the city . 3) Algorithm P erformance: W e compare the a verage computing time for each requirement under four conditions, (1) using the standard parsing algorithm without the cost function, (2) improved parsing algorithm with a single thread, (3) improved parsing algorithm with spatial paral- lelization using 4 threads and (4) using 8 threads. The results are shown in T able VI. T able VI: Computing time of requirements with standard parsing function, with improv ed parsing functions and dif- ferent number of threads Standard Parsing (s) 1 thread (s) 4 threads (s) 8 threads (s) NYR1 2102.13 140.29 50.31 26.12 NYR2 55.2 0.837 1.023 0.912 NYR3 69.22 22.25 7.54 4.822 NYR4 390.19 390.19 100.23 53.32 NYR5 61.76 61.76 20.25 15.68 T otal 2678.5 615.32 179.35 100.85 (1) Requirements (2) Smart Services Figure 6: Distrib utions of the violations over requirements and smart services First, the improved parsing algorithm reduces the com- puting time significantly for the requirement specified on PoIs, especially for NYR1 that computing time reduces from 2102.13 seconds to 140.29 seconds (about 15 times). Second, the parallelization ov er spatial operator further reduces the computing time in most of the cases. For example, for NYR1, the computing time is reduced to 26.12 seconds with 8 threads while 140.29 seconds with single thread (about 5 times). When the amount of data is very small (NYR2), the parallelization time is similar to the single thread time, but still much ef ficient than the standard parsing. The results demonstrate the effecti veness and importance of the efficient monitoring algorithms. In the table, the total time of monitoring 5 requirements is reduced from 2678.5 seconds to 100.85 seconds. In the real world, when multiple requirements are monitored simultaneously , the improve- ment is extremely important for real-time monitoring. C. Coverag e Analysis W e compare the specification co verage on 1000 quantitativ ely-specified real city requirements between STL, SSTL, STREL and SaSTL, the results are shown in Figure 7. The study is conducted by graduate students following the rules that if the language is able to specify the whole requirement directly with one single formula, then it is identified as T rue. T o be noted, another spatial STL, SpaT eL is not considered as a baseline here, because it is not applicable to most of city spatial requirements. SpaT eL is built on a quad tree, and able to specify directions rather than the distance. Figure 7: Comparison of the Specification Coverage on 1000 Real City Requirements As shown in Figure 7, STL is only able to specify 184 out of 1000 requirements out, while SSTL and STREL are able to formalize 431 requirements. SaSTL is able to specify 950 out of 1000 requirements . In particular , we made the fol- lowing observations from the results. First, 50 requirements cannot be specified using any of the four languages because they are defined by complex math formulas that are ambigu- ous with missing key elements, relev ant to the operations of many variables, or referring to a set of other requirements, e.g. “follow all the requirements from Section 201.12”, etc. Secondly , SSTL, STREL and SaSTL outperformed STL in terms of requirements with spatial ranges, such as “one- mile radius around the entire facility”; Third, SSTL and STREL hav e the same coverage on the requirements that only contain a temporal and spatial range. Comparing to SSTL and SaSTL, STREL can also be applied to dynamic graph and check requirements reachability , which is very useful in applications like wireless sensor networks, but not common in smart city requirements; Fourth, for the rest of the requirements (467 out of 1000) that can only be specified by SaSTL contains a v arious set of locations and the aggregation over spatial ranges. V I I . R E L A T E D W O R K Smart cities are special cases of cyber -physical systems (CPS) featuring a large amount of spatial distributed com- ponents that are responsible for monitoring and controlling the physical en vironment. In the last decade, ne w for- mal specification languages hav e been proposed to define spatial-temporal requirements ov er the ex ecution of CPS with spatial distributed components. For example, T alcott in [31] has introduced the notion of a spatial-temporal ev ent-based model for CPS. In such a model, the execution of actions, the exchange of messages and the physical changes trigger events that are processed by a monitor after being labeled with time and space stamps. This concept is further elaborated in [32] where a 2D Cartesian coordinate with location points and location fields system is used to represent the space. Howe ver , the approaches proposed in [31], [32] lack a spatio-temporal logic formalism enabling the specification of the requirements and the automatic monitoring generation. Other mathematical structures such as topological spaces , closure spaces , quasi-discr ete closur e spaces and finite graphs [13] can be used to reason about spatial relations, such as closeness and neighborhood in the context of collective adaptive systems [33]. Monitoring spatial distributed cyber-physical systems requires to deal with real-value signals over continuous time. Therefore, a common approach to design a specification language for spatio-temporal properties consists in extending STL [12] with spatial operators. Recent examples are SpaT eL [34], SSTL [13] and STREL [14]. Despite being well-defined and used in sev eral CPS applications, none of these logic systems can be directly applied to smart city requirements specification. The SaSTL proposed in this paper is meant to fill the blank between the formal logics and smart cities. Comparing to the spatial STL discussed abov e, SaSTL (1) specifies the spatial operators with distance and PoIs from the real world, (2) adds new aggregation operators, (3) adds a counting operator , and (4) monitors efficiently with parallel processing. V I I I . C O N C L U S I O N In this paper, we present a nov el Spatial Aggregation Signal T emporal Logic (SaSTL) to specify and to monitor real-time safety requirements of smart cities at runtime. W e dev elop an efficient monitoring framework that optimizes the requirement parsing process and can check in parallel a SaSTL requirement ov er multiple data streams generated from thousands of sensors that are typically spatially dis- tributed over a smart city . SaSTL is a powerful specification language for smart cities because of its capability to monitor the city desirable features of temporal (e.g. real-time, interval), spatial (e.g., PoIs, range) and their complicated relations (e.g. always, ev erywhere, aggregation) between them. More importantly , it can coalesce many requirements into a single SaSTL formula and provide the aggregated results ef ficiently , which is a major adv ance on what smart cities do now . W e belie ve it is a valuable step tow ards developing a practical smart city monitoring system even though there are still open issues for future work. Furthermore, SaSTL monitor is more than a smart city monitor, it can also be easily generalized and applied to monitor other large-scale IoT deployments with a lar ge number of sensors and actuators across the spatial domain at runtime efficiently . A C K N O W L E D G M E N T Supported in part by NSF NR T Grant 1829004. R E F E R E N C E S [1] C. E. Catlett, P . H. Beckman, R. Sankaran, and K. K. Galvin, “ Array of things: a scientific research instrument in the public way: platform design and early lessons learned, ” in Pr oceedings of the 2nd International W orkshop on Science of Smart City Operations and Platforms Engineering . A CM, 2017, pp. 26–33. [2] New Y ork Times, “IBM takes ‘smarter cities’ to rio de janeiro, ” 2012. [3] Cisco, “Smart+connected operations center, ” 2017. [4] M. Ma, S. M. Preum, M. Y . Ahmed, W . Tärneberg, A. Hen- dawi, and J. A. Stankovic, “Data sets, modeling, and decision making in smart cities: A survey , ” ACM T ransactions on Cyber-Physical Systems , vol. 4, no. 2, pp. 1–28, 2019. [5] Y . Y uan, D. Zhang, F . Miao, J. A. Stank ovic, T . He, G. Pappas, and S. Lin, “Dynamic integration of heterogeneous trans- portation modes under disruptive events, ” in 2018 A CM/IEEE 9th International Confer ence on Cyber -Physical Systems (IC- CPS) . IEEE, 2018, pp. 65–76. [6] M. Ma, S. M. Preum, and J. A. Stankovic, “Cityguard: A watchdog for safety-aware conflict detection in smart cities, ” in Pr oceedings of the Second International Confer ence on Internet-of-Things Design and Implementation , 2017, pp. 259–270. [7] H. Zhang, Y . Zheng, and Y . Y u, “Detecting urban anomalies using multiple spatio-temporal data sources, ” ACM on Inter- active, Mobile, W earable and Ubiquitous T echnologies , v ol. 2, no. 1, p. 54, 2018. [8] S. Sheng, E. Pakdamanian, K. Han, B. Kim, P . T iwari, I. Kim, and L. Feng, “ A case study of trust on autonomous driving, ” in 2019 IEEE Intelligent T ransportation Systems Confer ence (ITSC) . IEEE, 2019, pp. 4368–4373. [9] M. Ma, J. A. Stankovic, and L. Feng, “Runtime monitoring of safety and performance requirements in smart cities, ” in 1st ACM W orkshop on the Internet of Safe Things , 2017. [10] I. Haghighi, A. Jones, Z. K ong, E. Bartocci, R. Gros, and C. Belta, “Spatel: a nov el spatial-temporal logic and its ap- plications to networked systems, ” in Pr oceedings of the 18th International Conference on Hybrid Systems: Computation and Control . A CM, 2015, pp. 189–198. [11] M. Ma, J. A. Stanko vic, and L. Feng, “Cityresolver: a decision support system for conflict resolution in smart cities, ” in Pr oceedings of the 9th ACM/IEEE International Conference on Cyber-Physical Systems . IEEE Press, 2018, pp. 55–64. [12] O. Maler and D. Nickovic, “Monitoring temporal properties of continuous signals, ” in Pr oc. FORMATS , 2004. [13] L. Nenzi, L. Bortolussi, V . Ciancia, M. Loreti, and M. Massink, “Qualitativ e and quantitative monitoring of spatio-temporal properties, ” in Runtime V erification - 6th International Conference , RV 2015 , vol. 9333. Springer , 2015, pp. 21–37. [14] E. Bartocci, L. Bortolussi, M. Loreti, and L. Nenzi, “Monitor- ing mobile and spatially distributed cyber-physical systems, ” in MEMOCODE 2017: the 15th ACM-IEEE International Confer ence on F ormal Methods and Models for System De- sign . A CM, 2017, pp. 146–155. [15] NYC.gov , “Emissions from transportation, nyc en vironment protection, ” 2019. [Online]. A vailable: https://www1.nyc.gov/ html/dep/html/air/emissions_from_transportation.shtml [16] District of Columbia Municipal Regulations and D. of Columbia Register , “ Air quality - motor vehicular pollutants, lead, odors, and nuisance pollutants, ” 2016. [17] S. Matteo and J. Brannan, “ A local law to amend the admin- istrativ e code of the city of new york, in relation to restricting the use of bus lanes by sight-seeing buses, ” in Restricting the use of bus lanes by sight-seeing buses . The New Y ork City Council, 2019. [18] NYC Environment Protection, “Use of heating oil remaining in tanks. ” The city of New Y ork, 2019. [19] United States Environmental Protection Agency , “Residential energy efficienc y , ” in Ener gy Resources for State and Local Governments . The city of New Y ork, 2019. [20] LA Sec 111.03. Minimum Ambient Noise Level, “Official city of los angeles municipal code, ” 2016. [21] Hong Kong, “Guide to indoor air quality management in hong kong regional offices and public places, ” in Guide to Indoor Air Quality Management , 2019. [22] NYC.gov , “Stopping, standing or parking prohibited in spec- ified places, ” in New Y ork Public Law , 2016. [23] Beijing Emergenc y Agency , “Pre-hospital medical emergency regulations, ” 2016. [24] Beijing Government, “Safety management for kindergarten, primary and secondary school, ” 2016. [25] A. Donzé, T . Ferrere, and O. Maler, “Efficient robust mon- itoring for STL, ” in International Confer ence on Computer Aided V erification . Springer , 2013, pp. 264–279. [26] G. S. Lueker, “ A data structure for orthogonal range queries, ” in 19th Annual Symposium on F oundations of Computer Science . IEEE Computer Society , 1978, pp. 28–34. [27] City of Chicago, “Crimes of Chicago - one year prior to present, ” 2018. [28] M. Ma, S. M. Preum, W . T arneberg, M. Ahmed, M. Ruiters, and J. Stankovic, “Detection of runtime conflicts among ser- vices in smart cities, ” in 2016 IEEE International Confer ence on Smart Computing (SMARTCOMP) . IEEE, 2016, pp. 1– 10. [29] M. Behrisch, L. Bieker , J. Erdmann, and D. Krajzewicz, “Sumo–simulation of urban mobility: an overvie w , ” in Pr o- ceedings of SIMUL 2011 . ThinkMind, 2011. [30] NYC.gov , New Y ork City Open Data , https://nycopendata. socrata.com/. [31] C. L. T alcott, “Cyber-physical systems and events, ” in Softwar e-Intensive Systems and New Computing P aradigms - Challenges and V isions , ser . LNCS. Springer, 2008, vol. 5380, pp. 101–115. [32] Y . T an, M. C. V uran, and S. Goddard, “Spatio-temporal ev ent model for cyber -physical systems, ” in 2009 29th IEEE International Conference on Distributed Computing Systems W orkshops . IEEE, 2009, pp. 44–50. [33] V . Ciancia, D. Latella, M. Loreti, and M. Massink, “Spatial logic and spatial model checking for closure spaces, ” in Pr oc. of SFM 2016 , ser . LNCS, vol. 9700. Springer , 2016, pp. 156–201. [34] I. Haghighi, A. Jones, J. Z. Kong, E. Bartocci, G. R., and C. Belta, “SpaT eL: A Novel Spatial-T emporal Logic and Its Applications to Networked Systems, ” in Pr oc. of HSCC , 2015.