One of the main challenges for modern manufacturing is the possibility to react on particular situations in order to improve the efficiency of manufacturing or avoid some problems. Current systems for real-time processing in manufacturing are mainly focused on the simple reactivity, i.e. the possibility to define “simple” situations and react in “one step” on them. It is usually implemented through a CEP (Complex Event Processing) engine. However, more demanding manufacturing of the future will require “complex” reactivity that is essentially based on the discovery of complex situations of interest in real-time (zero delay, or even ahead of time). Moreover, in order to cope with very changeable environment (internal, external) in the manufacturing, the provided processing infrastructure must support dynamic changes, which is one of the main challenges for the current data processing infrastructure.
We have implemented this functionality in SE (Specific Enabler) called Dynamic CEP that is based on GE (Generic Enabler) Esper4FastData (which provides a traditional CEP engine).
For the case of envisioned dynamic monitoring new processing capabilities are requested, esp. in the context of processing pipelines, i.e. enabling complex processing networks. DyCEP assumes several processing elements which are connected in the way that ensures maximal efficiency of the processing task. This infrastructure is based on the Storm[1], the architecture for real-time (streaming) data processing. It uses custom created “spouts” and “bolts” to define information sources and manipulations to allow real-time distributed processing of streaming data.
From the technical point of view, DyCEP is realized as Complex Real-time Processing Network and its main advantage of the approach is the possibility to change the patterns deployed in the CEP engines (embedded in bolts). In that way we ensure that the processing infrastructure will be able to follow the dynamics of input data. In addition, such an approach will enable continuous improvement of the detection process that is very important for decreasing the number of false positive, which is one of the biggest problems for real-time processing approaches.
Figure 1 illustrates the high level architecture of DyCEP. The basic structure is similar to Storm, whereas the topology is organized according to the need for dynamic monitoring. There is one spout for receiving data and three bolts for data processing.
Two main functional blocks in the DyCEP are:
- Esper4FastData, responsible for static processing that requires simple complex event patterns and shouldn’t scale (because of the limited data input)
- ESPER-1, responsible for complex situations and prepared for horizontal scaling (by being hosted in a bolt, so that several bolt instances can be generated on demand)
GCM bolt enables delivering notification to mobile phones who subscribe to the complex event patterns deployed in the DyCEP.
[1] http://en.wikipedia.org/wiki/Storm_(event_processor)
The main elements are as follows:
- Broker is the mechanism for enabling subscriptions for relevant events by DyCEP (pub-sub functionality).
- Web API is responsible for getting input data in the DyCEP. It satisfies NGSI10 interface, as requested by FI PPP infrastructure. The format of data follows the specification provided by use case partners, in this particular case the specification for the TRW use case (see Functional Description for more details)
- Simple event handling spout enables receiving events of interest and forwarding them to the rest of the processing network
- Esper4FastData is FIWARE GE responsible for complex event processing (realized as external service, offered from a bolt). Outcome is realized through a web service.
- responsible for static processing that requires simple complex event patterns and shouldn’t scale (because of the limited data input)
- ESPER-1 is the CEP engine hosted in a bolt (in contrast to Esper4FastData – realized as external service). Outcome is realized through a web service. In addition notifications can be pushed to mobile devices.
- responsible for complex situations and prepared for horizontal scaling (by being hosted in a bolt, so that several bolt instances can be generated on demand
- GCM Push Bolt enables usage of the Google service for pushing notification to mobile devices (presented in the right-hand part of Figure 1)
The creation of the CEP patterns can be done in the manual way, or using a specialized mobile-based pattern editor provided by Nissatech.
The format of input data is as following (XML format):
<?xml version=“1.0” encoding=“utf-8” standalone=“no”?>
<updateContextRequest>
<contextElementList>
<contextElement>
<entityId type=“AngleDegree” isPattern=“false”>
<id>angle1</id>
</entityId>
<contextAttributeList>
<contextAttribute>
<name>degree</name>
<type>xs:double</type>
<contextValue>21.2899815638016</contextValue>
</contextAttribute>
<contextAttribute>
<name>sensorID</name>
<type>xs:string</type>
<contextValue>2</contextValue>
</contextAttribute>
</contextAttributeList>
<domainMetadata>
<contextMetadata>
<name>timestamp</name>
<type>xs:string</type>
<value>23-05-2014 18:29:43 976</value>
</contextMetadata>
</domainMetadata>
</contextElement>
</contextElementList>
<updateAction>UPDATE</updateAction>
</updateContextRequest>