Complex Event Processing (CEP) provides a mechanism to efficiently correlate and infer conclusions about systems by means of analyzing the events they process. In areas such as the Internet of Things (IoT), Cyber Physical Systems (CPS), system monitoring or data streaming analytics, CEP is able to read events from a data stream and to generate complex events that represent situations of interest to the system owner by means of event patterns. Every time a sequence of events matches a pattern, a complex event is created and added to the data stream. The dependencies among the rules and the possibility of non-confluent behavior of CEP rule-based systems may lead to unexpected outputs when executing CEP programs. In this work, we show how to statically check and correct two particular properties of CEP systems: rule acyclicityand rule race conditions. We use Esper EPL as a CEP language, and present a tool we have developed to perform these analyses.

1. Static Analysis of Complex Event
Processing Programs
Adrián García-López1, Loli Burgueño1,2, Antonio Vallecillo1
1Universidad de Malaga, Spain
2Open University of Catalonia, Spain
1

2. Complex Event Processing (CEP)
 CEP is a method for data stream-processing for analyzing and correlating streams
of information about real-time events in order to derive conclusions from them
 CEP enables the definition of complex events on top of other events (primitive or
complex)
 CEP programs are composed of rules which are in charge of processing the events
2

3. Complex Event Processing (CEP)
 CEP is a method for data stream-processing for analyzing and correlating streams
of information about real-time events in order to derive conclusions from them.
 CEP permits defining complex events on top of other events (primitive or complex)
 CEP programs are composed of rules which are in charge of processing the events
3
Queries Data Results Data Queries
(patterns)
Results

4. Motivation: Real CEP application
 Andalucia Air Quality Control
 Andalusian Regional Government’s sensor network: 61 sensor stations
 Each station measures every 10 minutes six air pollutants (e.g., carbon monoxide,
ozone, …)
4
 The information about each pollutant
measurement is aggregated,
 The global air quality level is computed and,
 Expressed in a 6-grade scale: from Good to
Hazardous
 43 CEP rules
 We detected rule race conditions!!

5. The Smart House Example
 Sensors for detecting three basic parameters of a
house: temperature, carbon monoxide (CO) level, and main door open.
 Sensors for detecting the location of occupants
5
Home(id:3,
ts:1528443000,
x:0,
y:0,
sq:100,
temp:20,
co:4000,
dopen:false)
Person(id:1,
ts:1528443000,
x:50,
y:50)

6. The Smart House Example
 Patterns:
 TemperatureIncrease: The temperature of the house has increased 2 or
more degrees in less than one minute.
 TemperatureWarning: There are 4 TemperatureIncrease events is less than
5 minutes, and the temperature is always above 33 degrees.
 COHigh: CO levels exceed 5000 units.
 FireWarning: A COHigh event is detected, followed by a
TemperatureWarning event, everything within less than 5 seconds.
 NobodyHome: The main door of the house is closed and there is nobody
within the perimeter of the house.
 CallFireDept: A FireWarning event occurs after a NobodyHome event is
detected.
6

7. The Smart House Example
Patterns in CEP with Esper
 TemperatureIncrease: The temperature of the house has increased 2 or more
degrees in less than one minute
 Esper(1) engine able to process millions of events per second
7
insert into TemperatureIncrease
select h2.ts as ts,
h1.id as id,
h2.temp as temp,
h2.temp-h1.temp as incr
from pattern [
(every (h1=Home() ->
h2=Home(h2.temp-h1.temp>=2 and h2.id=h1.id)))
where timer:within(1 minutes)];
(1) http://www.espertech.com/esper/

8. But life is not so easy…
> When the number of patterns increases, the CEP code and rules become
difficult to understand, debug and maintain!
Rule acyclicity – it may lead to never-ending loops
 Rule_1 generates events of type A  which are consumed by Rule_2
 Rule_2 generates events of type B  which are consumed by Rule_1
Rule race conditions – they may lead to non-confluent executions
 Rule_1 and Rule_2 behave as before
 Rule_3 consumes events of type A->B, and produces events of type X
 Rule_4 consumes events of type B->A and produces events of type Y
 Depending on the order in which Rule_1 and Rule_2 are triggered, events X or Y are
generated.
 Assigning pritorities to rules can solve this issue, but they are not normally used
8
>> Static analysis of CEP programs can easily detect these situations

9. Representing CEP rules as a graph – Cycles detection
9
(*) Bugs in the code
that led to cycles

10. Representing CEP rules as a graph – Rule race conditions
10

11. The CEPA tool (CEP-Analysis)
 https://github.com/Garlo13/CEPStaticAnalysis
 Kosaraju-Sharir algorithm for detecting cycles O(#V + #E)
 Topological Order to traverse the graph O(#V + #E)
11

12. CEPA workflow
12

13. A snapshot of CEPA
 “Fixed” rules with priorities
13

14. Conclusions and Future Work
 CEP programs become difficult to understand, debug and maintain when
their number of rules grow
 Validation with a real CEP application (Andalucia Air Quality Control, 43 rules)
 Other analysis are of course required, but lightweight static analysis are very
cost-effective
 Provide support for more Esper features
 Obtain more feedback on the features and scalability of our approach by
means of more and larger case studies
 Add further static (and dynamic) analyses
14

15. Adrián García-López1, Loli Burgueño1,2, Antonio Vallecillo1
1Universidad de Malaga, Spain
2Open University of Catalonia, Spain
Static Analysis of Complex Event
Processing Programs
15