Real-time Stream-based Monitoring

11/10/2017 ∙ by Peter Faymonville, et al. ∙ Universität Saarland 0

We introduce RTLola, a new stream-based specification language for the description of real-time properties of reactive systems. In real-time applications, data arrives at varying rates and in most cases it is hard to predict the input rate. The integration of sliding windows over real-time intervals with aggregation functions into RTLola allows us to detach fixed-rate output streams from the varying rate input streams. However, the number of input values within a single window instance can grow arbitrarily large disallowing any guarantees on the expected memory consumption. A feature of RTLola is that it allows for an automatic memory analysis that guides the user in identifying the computationally expensive specifications. For specifications using only certain classes of aggregation functions, we can give a precise memory bound. Furthermore, assuming a fixed monitor output rate, we can provide memory guarantees which can be computed statically. To demonstrate the features of RTLola, we evaluate the language and the implementation experimentally.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

In stream-based monitoring, we translate input streams, which contain sensor readings and other data collected at runtime, into output streams, which contain aggregate statistics, such as an average value, a counter, or an integral. Trigger specifications define thresholds and other logical conditions on the values on these output streams, and raise an alarm or execute some other predefined action if the condition becomes true. The advantage of this setup is great expressiveness and easy-to-reuse, compositional specifications.

Existing stream-based languages like Lola [8, 12] are based on the synchronous programming paradigm, where all streams are synchronized via a global clock. In each step, the new values of all output streams are computed in terms of the values of the other streams at the previous time step or at some other time step identified by an offset given as a natural number. This paradigm provides a simple and natural evaluation model that fits well with typical implementations on synchronous hardware.

In real-time applications, however, the assumption that all data arrives synchronously is often simply not true. Consider, for example, an online store like Amazon, where we might monitor the customer reviews on different products. Depending on the popularity of the product, new reviews might arrive at rates ranging from seconds to days, months, or even years. In fact, the arrival rates for a single product would typically vary wildly, depending, for example, on the time of day. In principle, one could, of course, run all streams at the rate of the fastest input stream. But such an approach would not only be extremely wasteful in terms of memory and processing time, it would also produce its results much too rapidly. For example, an online store might only wish to publish updated review statistics on a daily basis, not at the rate of individual incoming reviews.

In this paper, we present RTLola, the extension of the stream-based runtime verification language Lola with real-time events. We introduce the following new concepts into Lola:

  1. Variable-rate input streams: we consider input streams that extend at a-priori unknown rates. The only assumption is that each new event has a real-valued time stamp and that the events arrive in-order.

  2. Real-time offsets: since the streams are no longer synchronous, it is no longer sensible to refer to events in other streams via an offset given as a number of steps. Real-time offsets are given in units of time, such as 1 hour.

  3. Sliding windows: A sliding window aggregates data over a real-time window given in units of time. For example, we might count the number of reviews over the past 24 hours.

The following example illustrates in a simple real-time controller scenario how RTLola translates variable-rate input streams into a fixed-rate output streams:

  input  double sensor
  input  double reference
  input  double timestamp
  output double error := sensor[2sec, 0, avg]
                    - reference[2sec, 0, avg]
  output double acc_error := error[10sec, 0, ]
  trigger acc_error > 5

The output stream error computes the average value of a sensor reading over a 2 second window and then subtracts from this the average value of a reference signal. The output stream acc_error then integrates over the error in a 10 second window. A trigger is raised if acc_error becomes too large.

The real-time features of RTLola integrate seamlessly into the other specification mechanisms of Lola, such as parameterization.

As with any semantic extension, the challenge in the design of RTLola is to maintain the efficiency of the monitoring. The efficiently monitorable fragment [8] of Lola consists of all specifications that only have bounded references into the future. This fragment can be monitored with constant memory. Obviously, not all RTLola specifications can be monitored with constant memory, even if we restrict offsets to refer to the past: Since the rates of the input streams are unknown, an arbitrary number of events may occur in the span of a fixed real-time unit. We can, nevertheless, again identify an efficiently monitorable fragment that covers many specifications of practical interest.

For the space-efficient aggregation over real-time sliding windows, we partition the real-time axis into equally-sized intervals. The size of the intervals is dictated by the rate of the output streams. For certain common types of aggregations, such as the sum or the number of entries, the values within each interval can be pre-aggregated and then only stored in this summarized form.

In a static analysis of the specification, we identify parts of the specification with unbounded memory consumption, and compute bounds for all other parts of the specification. In this way, we can determine early, whether a particular specification can be executed on a system with limited memory.

1.1 Related Work

RTLola is based on it synchronous predecessor Lola [9, 13], where all streams are synchronized via a global clock and the computation is performed in a single, centralized monitor, corresponding to its main application domain: monitor circuit implementations on synchronous hardware.

In the area of monitor specification languages, a series of works have investigated the monitoring of real-time properties. Many of these approaches are based on real-time variants of temporal logics [1, 22, 27, 19, 11, 21]. Maler and Nickovic present a monitoring algorithm for properties written in signal temporal logic (STL) by reducing STL formulas via a boolean abstraction to formulas in the real-time logic MITL [25]. Building on the latter ideas, Donze et. al. present an algorithm for the monitoring of STL properties over continuous signals [10]. The algorithm computes the robustness degree in which a piecewise-continuous signal satisfies or violates an STL formula. Basin et. al. extend metric logics with parameterization [6]. A monitoring algorithm for the extension was implemented in the tool MonPoly [3]. MonPoly was introduced as a tool for monitoring usage-control policies. Another extension to metric dynamic logic was implemented in the tool Aerial [5]. However, most monitors generated from temporal logics are limited to Boolean verdicts.

Within stream-based monitoring approaches, two frameworks with expressive verdicts have been introduced in the Copilot framework [26] and with the tool BeepBeep 3 [18]. Copilot is a stream-based dataflow language based on several declarative stream processing languages [9, 17]. From a specification in Copilot, constant space and constant time C programs implementing embedded monitors are generated. The BeepBeep 3 tool uses an SQL-like language that is defined over streams of events. In addition to stream-processing, it contains operators such as slicing, where inputs can be separated into several different traces, and windowing where aggregations over a sliding window can be computed. However, both approaches assume a synchronous computation model, where all events arrive at a fixed rate and thus are limited to applications that have such an underlying model. A non-synchronized real-time stream specification language was introduced with TeSSLa [23]. TeSSLa allows for monitoring piece-wise constant signals where streams can emit events at different speeds with arbitrary latencies. In contrast to RTLola, TeSSLa does not support parametrization and sliding windows. A similar decoupling from variable input event rates via sliding windows and fixed rate clock streams has been raised in [2] within the context of temporal logics. Many works have considered approaches for the efficient evaluation of aggregations on sliding windows [24]. Basin et. al. present an algorithm for combining the elements of subsequences of a sliding window with an associative operator, which reuses the results of the subsequences in the evaluation of the next window [4].

On the application side, multi-robot systems with central task servers are a common paradigm, as shown in [7, 16, 28, 14]. Bandwidth restrictions as in our application have also been studied in several approaches for distributed wireless sensor systems [29, 15].

2 RTLola


Sliding Windows

Outputs + Triggers

Central Station
Figure 1: The RTLola framework

RTLola provides the stream-based monitoring framework depicted in Figure 1. In stream-based monitoring, sensor readings and other collected data at runtime are interpreted as streams. These input streams, are translated to new output streams, which define filters and aggregated statistics, such as an average value, a counter, or an integral. Monitoring tasks are defined by so-called trigger specifications, which define thresholds and other logical conditions on the values of input and output streams. The advantage of this setup is great expressiveness and easy-to-reuse, compositional specifications. Monitoring an RTLola specification can be distributed into monitoring tasks that are executed on a central server we call the central monitor. The central monitor evaluates data received from the central controller of the multi-robot system and from data collected from the robots themselves. Data collected from the robots can in turn be processed before it is sent to the central monitor. This is done by applying parts of the RTLola specifications locally on the robots. In general the goal is to relief the network from intensive data transmission. The RTLola framework provides tool support to determine the cost of executing monitoring tasks.

In this section, we introduce the specification language of the RTLola framework and provide an evaluation algorithm for executing the monitoring tasks. In the next section we show how we can implement an automatic memory analysis procedure on top of the language that analyzes the memory consumption of an RTLola specification.

2.1 RTLola: The Language

RTLola (short for Real-Time Lola) is based on the synchronous stream processing language Lola [9, 13]. Lola has been used to monitor industrial hardware systems, such as bus protocols and memory controllers, as well as to monitor networks. RTLola extends Lola [13] with two new key features that make it possible to monitor real-time requirements: sliding window expressions, which compute aggregated values over windows of fixed (real-time) durations, and stream computation rates, which define the pace in which streams are extended with new values.

An RTLola specification is a system of stream declarations over typed stream variables. This system consists of typed input stream declarations of the form:


where each stream is of type for , and typed parameterized output stream templates of the form


for . Each stream template introduces a template variable of type that depends on parameters of types , respectively. For given values of matching types , we call a stream an instance of the template if it computes the stream induced by . The stream is created, extended, and deleted according to the following auxiliary streams:

  • is the invocation template stream variable of and has type . If an instance of is extended with a fresh value , then an instance of is invoked unless it already exists.

  • is the extension template stream variable of and has type bool. If an instance of is invoked with parameter values , then an extension stream is invoked with the same parameter values . The instance is extended whenever is extended with true.

  • is the termination template stream variable of and has type bool. If is invoked with parameter values , then a terminate stream is invoked. If is extended with true, the output stream is terminated.

Each instance runs on a local clock paced by its corresponding extend stream and by an additional optional clock . The instance is extended with every tick of if and only if is true. If is not given, the local instance clock always progresses equally fast as the fastest clock amongst all local clocks of the streams appearing the the expression . If neither nor is given the local clock in this case progresses in a discrete fashion, however, not with equidistant ticks on the real-time axis. Whenever a new value arrives for one of the sub-streams, a new tick takes place that extends . Therefore, the distance in time between two consecutive ticks can be arbitrarily large or small.

Auxiliary stream expressions can be omitted if they are inferable from the context.

The stream expression , is defined over a set of independent input stream variables , a set of dependent output stream variables , and a set parameter variables . Dependent stream variables have access to past and present values of all streams. An RTLola stream expression permits basic constructs such as constants, -ary function symbols, conditional expressions and stream accesses of form , i.e., the value of stream with an offset in the past.

RTLola extends its predecessor with sliding window expressions of the form , where is a real number defining the duration of the window and is a function of type defining the aggregation function.

Expressions of the form evaluate to the default value in case is not defined. This case occurs if the respective instance is not invoked at this point in time or its extend stream for an expression was true less than times.

Finally RTLola specifications contain a list of triggers:


where is an expression of type boolean over stream variables. Triggers generate notifications when their expression evaluates to . Trigger expressions also permit special operators arguing over stream instances, such as any of type bool checking the validity of a condition for any existing stream instance, and count of type int counting the number of existing stream instances of a given stream.

As a concrete example, a parametric variant of the specification presented before can be declared as following:

input bool offRoad
input int CID
input bool pickUp
output bool offRoadPickUp<int cid>: 0.1Hz
  invoke: CID
  extend: cid = CID
  := offRoad & pickUp
output bool suspicious<int cid> :=
  invoke: CID
  extend: cid = CID
  := offRoadPickUp(cid)[8h, count]?0 > 5

Observe that the output streams are now parametric in the robot car identifier cid. Since they have CID as an invoke stream, new stream instances of both output streams are created whenever a fresh identifier appears on the input stream CID. The extend stream then extends those stream instances whenever the matching identifier cid appears again on the input stream CID. Within the parametric output stream suspicious<int cid>, we access the corresponding offRoadPickUp stream instance by referring to offRoadPickUp(cid).

2.2 Efficient Evaluation

For a space and time efficient evaluation, we need to pay special attention to the computation of sliding windows. Consider a sliding window over a target stream with aggregation function and window size . In a naïve approach, whenever produces a new value, the value is stored until has passed. In the meantime, when the window is evaluated, all stored values are aggregated using . For input streams with variable input rate, storing all values while retaining strict memory guarantees is not an option.

We apply a paning approach [24]. Here, we split into a pre-determined amount of time frames with equal width. All values arriving within the same frame are pre-aggregated using . The resulting value now represents all values that arrived within the frame, enabling us store only one value rather than all incoming values. When the window is evaluated, the pre-aggregated values are aggregated once again. Pre-aggregation is possible for homomorphic functions . Most widely used aggregation functions such as max, min, sum, and integral are in fact homomorphic.

Window paning greatly reduces worst-case memory consumption for variable rate target streams. More details can be found in Section 3. Another concern for safety monitoring is the running time: If the computation takes too long, it might already be too late when the monitor detects the problem.

Although the running time for each stream expression in isolation can be bounded quite easily and is constant in the length of the trace, this is not the case of the number of stream instances due to parametrization.

Consider for example a parametrized stream counting the number of times one specific car picked up a customer off road:

  input int CID
  output int suspicious <int cid>
    invoke: CID
    extend: CID = cid
    := offRoadPickup[8h, count(cid), 0]

Here, the number of instances of suspicious depends on the number of different car ids in the trace, bounded by the domain of int or the number of cars in the fleet, whichever is less.

A large number of instances can have a significant impact on the runtime if each instance needs to be evaluated at the same time.

Note, however, that in this example the extend condition for the stream, CID = cid, indicates that only one instance can be extended at any time: If a new value of CID arrives, there can only be one instance of suspicious with parameter that needs to be extended.

We say that a stream is efficiently bound if the extend condition is a positive boolean formula where the atoms are equality checks between parameter values and input streams. Extending efficiently bound streams does not depend on the number of active instances and, thus, has constant running time.

2.3 Evaluation Algorithm

The evaluation algorithm consists of two components, one running periodically and computing the value of fixed-rate streams, and one running sporadically whenever new input values arrive.

Input: Events for Streams , Timestamp
Result: Trigger
1 begin
2       foreach  do
3             extend by value ;
4             register in depending windows at time ;
5             foreach  do
6                   invoke with parameter ;
8      foreach  do
9             if  compatible with  then
10                   = compute value for with ;
11                   extend by ;
12                   register in depending windows at time ;
13                   foreach  do
14                         invoke with parameter ;
16      return active triggers
Algorithm 1 VarRateEvaluation

Algorithm 1 outlines the variable-rate component. It is triggered whenever a new input arrives. First, the respective input streams are extended and new values are added to all depending window instances. Note that this does not trigger the computation of the overall window value, but is local to a single interval. Then, streams which invoke stream were extended are identified and invoked. Afterwards, efficient streams are extended. As discussed before, the existential quantifier can be resolved efficiently by the efficient binding. Again, depending windows are notified and respective instances invoked. Note that efficient streams cannot be invoked by other efficient streams. As a result, one iteration over suffices to cover all extended instances.

The last step identifies active triggers efficiently by only considering count- and exists-triggers whiles targets were invoked. For any-triggers only one instance per stream template and input even can be extended, rendering the check for active triggers efficient.

The running time of Algorithm 1 is very low, because

  1. the number of invokes and extends in one execution is strictly limited,

  2. registering values in sliding windows only requires few arithmetic instructions, and

  3. the overhead induced by the loops in lines 5 and 12 can be greatly reduced by using clever book-keeping data structures.

Input: Clock signal at time ts
Result: Trigger, Outputs
1 begin
2       ;
3       fixpoint
4             foreach  do
5                   Compute latest value for at time
6            foreach  with  do
7                   = compute value for ;
8                   extend by ;
9                   register in depending windows at time ;
10                   ;
11                   foreach  do
12                         invoke with parameter ;
14      foreach  with  do
15             terminate
16      return active triggers,
Algorithm 2 FixedRateEvaluation

Algorithm 2 describes the fixed-rate component. Here, the update of windows, extension, and invocation of streams is repeated until no further action is possible, i.e., a fixpoint is reached. This process keeps track of all extended streams and their values. Reaching a fixpoint triggers the deletion of all instances with an active termination condition. The last step returns all active triggers and newly computed output values.

3 Memory Analysis

3.1 Dependency graph

Let be a specification with input stream variables and template stream variables with invoke, extend and terminate stream , and stream expression for . An annotated dependency graph (ADG) is a directed graph , where is a set of vertices each representing an input stream or a stream template variable, a set of edges defining the dependencies between the different streams, a function that annotates each vertex with either denoting stream with variable rates, or with a frequency in Hz for streams with fixed rates. We define var to be larger than any natural number. Finally, the function that states whether the dependency of two stream is defined via a window with a duration in milliseconds and aggregation function , or a discrete offset.

The annotation function is derived from the syntax of the specification. To compute the annotation of vertices we use the following rules. Let :

  • If has a fixed rate then .

  • Otherwise, if for then , else if for then

Consider for example the following RTLola specification

  input  double a
  input  double b
  output double diff = abs(a - b[-1,0])
  output double acc = diff[10sec,avg,0]

The ADG of is given in Figure 2(a). Both and are inputs with variable rates. Because is extended every time one of the input streams is extended, its rate is also variable, and so is the one of acc.


































Figure 2: Annotated Dependency Graph (ADG) to analyze the memory requirements of specifications , , and .

Let be as where diff is supplied with a stream clock as an extension stream, then its rate becomes fixed and its expression is evaluated only once every second. The rate of acc also becomes fixed, because it only depends on the rate of diff. The ADG of is shown in Figure 2(b).

Both and of the property can be computed efficiently, because the discrete offsets require only constant memory and the sliding window with the aggregation function avg can be computed as we have seen in the last section.

In contrast, a specification , which access a variable input stream with a real-time offset operator, do not permit an a-priori memory guarantee.

  input  double a
  input  double b
  output double diff = abs(a - b[-1sec,0])
  output double acc = diff[10sec,avg,0]

Here, there is no bound on the number of events that need to be stored for computing , because it is impossible to determine beforehand which points in time will be needed in the evaluation of this expression. The ADG for is depicted in Figure 2(c). Again, if we supply diff with a stream clock, then we only have to store the values of at the coarser granularity. Similarly, when we access a variable rate stream with an aggregation function, which requires to store all events in a sliding window, like max, we cannot provide a memory guarantee.

3.2 Computing memory requirements

We describe a concrete analysis method to derive tight memory requirements for a given RTLola specification. Memory bounds for discrete-time offsets can be computed as for Lola [9]. We extend this algorithm with new computational rules to determine the memory bounds for real-time sliding window expressions. For each edge in the ADG we can determine how many values must be stored for the computation of using the following rules, where is the duration of the sliding window:

[width=5em] ( (, pane size =

If the aggregation function requires to store all values, such as median, and the target stream has a variable output rate, the required memory is unbounded. If the target is a fixed rate stream, and the duration of the sliding window is , at most values can arrive, thus giving a bound on the required memory.

For efficient aggregation functions such as sum, count, or average, RTLola can use a paning approach presented earlier. Here, the real timeline is split into intervals of equal size . All values arriving within the same interval are considered equal in terms of arrival time. The discretization allows for giving tight bounds on the required memory because all values within an interval can be pre-aggregated. As a result, a single value is sufficient to represent the whole interval. Thus, even if the input rate is unbounded, pre-aggregated values are required. For a fixed rate input, if the rate of is sufficiently low, it is possible to store all values and forego paning.

Lastly, let be the values determined by the table above, and the maximal number of instances of a stream, the upper bound for the memory consumption of a stream is .

4 Experiments

We implemented RTLola in C for unix systems. It features two modes of output computation: In the fixed step mode, each arrival of an input value triggers a new evaluation cycle meaning that new output values are computed. In the variable step mode, evaluation cycles are time-triggered at a fixed frequency111The delay is subject to the non-deterministic sleep behavior of non-real time operating systems..

To realize this, we use multithreading with a reader thread reading input values from a .csv file. The worker thread is time triggered in the fixed step mode, or event triggered by the arrival of input values in the variable step mode. We use POSIX mutexes and and conditions for thread synchronization.

The parser for the specification is generated using the BNFC tool222

Each stream instance has a value store being either a cyclic buffer when there are no real time accesses, so the required space is bounded. Otherwise the store is a dynamic array of values and their respective time stamp.

Stream instances are managed in hash-maps where the parameter values are hashed with a generic hash function.

4.1 PID controller

In the first scenario we assume a PID controller monitoring the accumulated error of sensor data with respect to reference values. Data points arrive sporadically. We use the following specification:

input double temperature
input double reference
time input double timestamp
output double smooth_temp := temperature[10s,avg,0.0]
output double smooth_ref := reference[10s,avg,0.0]
output double error := smooth_temp - smooth_ref
output double acc_error := error[50s, avg, 0.0]
trigger any(acc_error > 0.016)

We generate input data using a Simulink feedback controller model and compare the fixed step mode against the variable step one on an input file with around 400 values. The results can be found in Table 1.

frequency time[s] memory[MB]
Variable n/a <1 3.36
Fixed 1Hz <1 3.61
0.2Hz <1 3.56
0.1Hz <1 3.55
Table 1: Experimental results for the PID controller data.

As the output frequency decreases, we can observe an improvement in the memory consumption of the monitor.

4.2 Amazon Review Data

In the second scenario we consider amazon product review data, especially the review rating of products. When a significant increase in ratings for a product is detected, the product is considered interesting right now, so the stock of the product should be increased.

In the corresponding specification seen in Figure 3, we parametrize over each product and terminate instances if the arrival frequency of new reviews drops below a certain rate. We compute the average star rating of a product and compare the average of a long running window to the average rating in the last tenth of that window and detect a significant short-term increase. If the comparison rises above a threshold, a trigger message is sent.

We again compare the fixed step and variable step mode.

We use real user data from amazon[20] for the category of videos. It contains a dataset with 100k elements. The results can be found in Table 2.

frequency time[s] memory[MB]
Variable n/a 3.16 89.19
Fixed 0.004Hz 175.2 1147
0.002Hz 204.84 886.1
0.001Hz 189.82 726.98
Table 2: Experimental results for the amazon review data.

We again see that lowering the output frequency of the monitor results in better memory usage. Remember that the variable mode has no guarantees on memory consumption, even though it may be more efficient in some cases.

input string uid
input string pid
input double stars
time input double timestamp
const double ter_thres := 10000.0
output bool right_pid <string prod>
  :inv: pid
  :ter: ter_cond
  := pid = prod
output double time_p <string prod>
  :inv: pid
  :ext: right_pid
  :ter: ter_cond
  := timestamp
output double arr_freq <string prod>
  :inv: pid
  :ext: right_pid
  :ter: ter_cond
  := time_p(prod)[slide, 1000, count, 0.0]
output bool ter_cond <string prod>
  :inv: pid
  :ter: ter_cond
  := arr_freq(prod)[0, 50000.0] < ter_thres
output double star_avg_l <string prod>
  :inv: pid
  :ext: right_pid
  :ter: ter_cond
  := stars[slide, 100000, avg, 0.0]
output double star_avg_s <string prod>
  :inv: pid
  :ext: right_pid
  :ter: ter_cond
  := stars[slide, 10000, avg, 0.0]
output double avg_delta <string prod>
  :inv: pid
  :ext: right_pid
  :ter: ter_cond
  := star_avg_l(prod)[0, 0.0] - star_avg_s(prod)[0, 0.0]
trigger any(avg_delta > 1.0)
Figure 3: Lola specification for the detection of an unusual high increase in star ratings of any product.

5 Conclusion

We introduced RTLola, a stream-based specification language for the description of monitors for real-time properties. RTLola specifications allow the definition of real-time offsets into the past and the future, the aggregation over real-time sliding windows, and can handle input streams of variable rate. We showed that for many aggregation functions used in practice, we can efficiently compute the aggregations of sliding windows on variable rate input streams by partitioning the real-time axis into intervals of equal sizes, which is determined by the given output rate. We also showed how a static analysis can be done for a given specification to indicate to the user which parts of his specification can be computed efficiently and which might lead to high memory consumption.

This new output-driven perspective gives a pragmatic way to give a memory guarantee for the monitor and the given specification without syntactically restricting the expressiveness of the underlying stream-based specification language.

In practice, most approaches would fix a rate on the evaluation of output streams. In this way, even if the rate of input streams is variable, the evaluation of output streams remains efficient.


  • [1] Alur, R., Henzinger, T.A.: Real-time logics: complexity and expressiveness. In: [1990] Proceedings. Fifth Annual IEEE Symposium on Logic in Computer Science. pp. 390–401 (Jun 1990)
  • [2] Basin, D., Bhatt, B.N., Traytel, D.: Almost Event-Rate Independent Monitoring of Metric Temporal Logic, pp. 94–112. Springer Berlin Heidelberg, Berlin, Heidelberg (2017),
  • [3] Basin, D., Harvan, M., Klaedtke, F., Zălinescu, E.: MONPOLY: Monitoring Usage-Control Policies, pp. 360–364. Springer Berlin Heidelberg, Berlin, Heidelberg (2012),
  • [4] Basin, D., Klaedtke, F., Zălinescu, E.: Greedily computing associative aggregations on sliding windows. Inf. Process. Lett. 115(2), 186–192 (Feb 2015),
  • [5] Basin, D., Traytel, D., Krstić, S.: Aerial: Almost event-rate independent algorithms for monitoring metric regular properties (2017),
  • [6] Basin, D.A., Klaedtke, F., Müller, S., Zalinescu, E.: Monitoring metric first-order temporal properties. J. ACM 62(2), 15:1–15:45 (2015),
  • [7] Bogue, R.: Growth in e-commerce boosts innovation in the warehouse robot market. Industrial Robot: the international journal of robotics research and application 43(6), 583–587 (2016),
  • [8] D’Angelo, B., Sankaranarayanan, S., Sánchez, C., Robinson, W., Finkbeiner, B., Sipma, H.B., Mehrotra, S., Manna, Z.: Lola: Runtime monitoring of synchronous systems. In: 12th International Symposium on Temporal Representation and Reasoning (TIME’05). pp. 166–174. IEEE Computer Society Press (June 2005)
  • [9] D’Angelo, B., Sankaranarayanan, S., Sánchez, C., Robinson, W., Finkbeiner, B., Sipma, H.B., Mehrotra, S., Manna, Z.: Lola: Runtime monitoring of synchronous systems. In: 12th International Symposium on Temporal Representation and Reasoning (TIME’05). pp. 166–174. IEEE Computer Society Press (June 2005)
  • [10] Donzé, A., Ferrère, T., Maler, O.: Efficient Robust Monitoring for STL, pp. 264–279. Springer Berlin Heidelberg, Berlin, Heidelberg (2013),
  • [11] Donzé, A., Maler, O.: Robust satisfaction of temporal logic over real-valued signals. In: Proceedings of the 8th International Conference on Formal Modeling and Analysis of Timed Systems. pp. 92–106. FORMATS’10, Springer-Verlag, Berlin, Heidelberg (2010),
  • [12] Faymonville, P., Finkbeiner, B., Schirmer, S., Torfah, H.: A Stream-Based Specification Language for Network Monitoring, pp. 152–168. Springer International Publishing, Cham (2016),
  • [13] Faymonville, P., Finkbeiner, B., Schirmer, S., Torfah, H.: A Stream-Based Specification Language for Network Monitoring, pp. 152–168. Springer International Publishing, Cham (2016),
  • [14] Gavran, I., Majumdar, R., Saha, I.: Antlab: A multi-robot task server. ACM Trans. Embedded Comput. Syst. 16(5), 190:1–190:19 (2017),
  • [15] Greenstein, B., Pesterev, A., Mar, C., Kohler, E., Judy, J., Farshchi, S., Estrin, D.: Collecting high-rate data over low-rate sensor network radios. Tech. rep., UCLA: Center for Embedded Network Sensing (2007)
  • [16] Guizzo, E.: Three engineers, hundreds of robots, one warehouse. IEEE Spectrum 45(7), 26–34 (July 2008)
  • [17] Halbwachs, N., Caspi, P., Raymond, P., Pilaud, D.: The synchronous dataflow programming language lustre. In: Proceedings of the IEEE. pp. 1305–1320 (1991)
  • [18] Hallé, S.: When RV Meets CEP, pp. 68–91. Springer International Publishing, Cham (2016),
  • [19] Harel, E., Lichtenstein, O., Pnueli, A.: Explicit clock temporal logic. In: Proceedings of the Fifth Annual Symposium on Logic in Computer Science (LICS ’90), Philadelphia, Pennsylvania, USA, June 4-7, 1990. pp. 402–413. IEEE Computer Society (1990),
  • [20] He, R., McAuley, J.: Ups and downs: Modeling the visual evolution of fashion trends with one-class collaborative filtering. In: Proceedings of the 25th International Conference on World Wide Web, WWW 2016, Montreal, Canada, April 11 - 15, 2016. pp. 507–517 (2016),
  • [21] Jahanian, F., Mok, A.K.L.: Safety analysis of timing properties in real-time systems. IEEE Transactions on Software Engineering SE-12(9), 890–904 (Sept 1986)
  • [22] Koymans, R.: Specifying real-time properties with metric temporal logic. Real-Time Systems 2(4), 255–299 (1990),
  • [23] Leucker, M., Sánchez, C., Scheffel, T., Schmitz, M., Schramm, A.: Tessla: runtime verification of non-synchronized real-time streams. In: Proceedings of the 33rd Annual ACM Symposium on Applied Computing, SAC 2018, Pau, France, April 09-13, 2018. pp. 1925–1933 (2018),
  • [24] Li, J., Maier, D., Tufte, K., Papadimos, V., Tucker, P.A.: No pane, no gain: efficient evaluation of sliding-window aggregates over data streams. SIGMOD Record 34(1), 39–44 (2005),
  • [25] Maler, O., Nickovic, D.: Monitoring Temporal Properties of Continuous Signals, pp. 152–166. Springer Berlin Heidelberg, Berlin, Heidelberg (2004),
  • [26] Pike, L., Goodloe, A., Morisset, R., Niller, S.: Copilot: A Hard Real-Time Runtime Monitor, pp. 345–359. Springer Berlin Heidelberg, Berlin, Heidelberg (2010),
  • [27] Raskin, J.F., Schobbens, P.Y.: Real-time logics: Fictitious clock as an abstraction of dense time, pp. 165–182. Springer Berlin Heidelberg, Berlin, Heidelberg (1997),
  • [28] Saska, M., Vonásek, V., Chudoba, J., Thomas, J., Loianno, G., Kumar, V.: Swarm distribution and deployment for cooperative surveillance by micro-aerial vehicles. Journal of Intelligent & Robotic Systems 84(1), 469–492 (Dec 2016),
  • [29] Wang, H., Estrin, D., Girod, L.: Preprocessing in a tiered sensor network for habitat monitoring. EURASIP J. Adv. Sig. Proc. 2003(4), 392–401 (2003),