The Complex Alarming Event Detecting and Disposal Processing Approach for Coal Mine Safety Using Wireless Sensor Network

Abstract

Due to the complex environment of the coal mine, the accidents can occur at any time and often result in partial or total evacuation of mine personnel and could result in the loss of lives. Therefore, it is important and necessary to detect the accidents and generate a corresponding alarming disposal in time. This paper proposed a real-time complex alarming event detecting and disposal processing approach for coal mine safety using wireless sensor network. Firstly, we introduce the event and complex events model, offer fully customizable policies for event selection and consumption, and also describe the state-automata-based complex event detection algorithm. Then, we describe an event-driven service coordination pattern for the behavioral model, which is based on event-condition-action triggering with BPEL control flow realized using decoupled publish/subscribe semantics. Finally, the system implementation is presented and deployed in the coal mine, showing the effectiveness of the proposed approach.

1. Introduction

Safety is a major concern for the miners who work in underground coal mines. Coal mine accidents can occur at any time and often result in partial or total evacuation of mine personnel and could result in the loss of lives. Environment monitoring in underground tunnels, which are usually long and narrow, with lengths of tens of kilometers and widths of several meters, has been a crucial task to ensure safe working conditions in coal mines where many environmental factors, including the amount of methane gas, carbon monoxide, temperature, and oxygen need to be monitored. However, a precise environment overview requires a high sampling density, which involves a large number of sensing devices. Wireless sensor networks employ multihop routing to implement data gathering. Each sensor node plays the role of data collector as well as message forwarder in the network. The utilization of the wireless sensor network to implement the underground environment monitoring should benefit from rapid and flexible deployment [1–3]. However, the multiple low-level events from multiple sources for sensors do not appear to have any relationship separately, and the safety alarming only depends on the reasonable complex pattern detection by comparing these multiple events for sensors; some unusual or less obvious correlation and some amount of sensor data should be enriched by infusion of related information to each event to more clearly illustrate how the many events are related at the same time. Especially, when a safety alarming trigger condition is satisfied with the corresponding complex situation pattern, the higher-level disposal process event is created, and some human or automated process that is invoked when the trigger event is reached. Therefore, it is necessary to detect the complex accidents pattern and generate the corresponding alarming disposal process for underground coal mine safety.

Service-oriented architecture (SOA) [4–10] makes the role of current industrial organizations more strategic as they establish high-level interoperability among the different components across the domain, which also provides the solutions for systems integration where the functionalities are encapsulated as interoperable services. Current SOA technologies target for process-based control and data flow and orchestrate the distributed services centrally with the predefined processes. However, the basic SOA approach is not suitable for the events that occur across or outside of the specific processes. Event-driven architecture (EDA) [11, 12] has been proposed as a paradigm for event-based applications. Particularly, the main idea lies in the processing of events, that is, to use the complex event processing (CEP) as the process model for event-driven decision support, and event streams contain a large of events, which must be transformed, classified, and aggregated to initiate appropriate actions. Combining the features with SOA and EDA, event-driven SOA (EDSOA) should be an ideal candidate, which complements and extends SOA by introducing long-running processing capabilities. Long-running processing capability enables to collect various asynchronous events over a long period of time and correlates these events into causal relationships. Event patterns of EDSOA can be designed and implemented to find the complex event relationships that span days, weeks, or months, and when certain complex event pattern is satisfied, and then to trigger the corresponding business process to complete some specific goals. Particularly, the business process execution language (BPEL) [13] is an orchestration language used to define a process model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. Using BPEL, which integrates a web service collection in the same process flow can be constructed. As mentioned above, it is also possible to use BPEL to define an executable alarming disposal process.

The traditional coal mine safety alarming system [14–17] usually only gives the warning signal in the form of voice, light, and electric, and so forth but does not follow the track of the alarming disposal process when the alarming event occurs. This is not conducive to monitor the execution of the alarming disposal process. A closed-loop coal mine safety alarming disposal process can effectively solve the above problems. In this paper, we present a novel approach to integrate wireless sensor network into SOA environments using event-driven SOA technologies to develop coal mine safety monitoring and alarming disposal platform. The rest of the paper is organized as follows. In Section 2, we describe the wireless sensor network underground coal mine. In Section 3, we describe the complex alarming event detecting approach. In Section 4, we describe the BPEL-based coal mine safety alarming disposal process. In Section 4 is the system implementation and illustration. The conclusions and future work are given in Section 5.

2. Underground Wireless Sensor Network

Monitoring the environment for underground coal mines has been crucial a task to ensure safe working conditions in coal mines where many environmental factors, including the amount of gas, water, and dust need to be constantly checked. Wireless sensor networks are used in coal mines to monitor coal mine environments. The underground wireless sensor network consists of three kinds of sensor nodes: one is the beacon node responsible for environment monitoring, which is usually deployed only at one side of the tunnel with the pillar and with same distance interval because of the narrow underground tunnel and inconvenience deployment. The second is the mobile node in the underground tunnel, as every mobile node has a unique number and is passively moved by the mobile object, it can serve as the identity of underground mobile objects and can be used to locate and track the moving objects in the tunnel. The third is base station deployed in the brow, which has the capacity of storage and computing and is the switching equipment of the underground wireless sensor network and the wired network. The base station is the unique data exit of the underground wireless sensor network and is responsible for the exchange of the collecting data and the control commands. Usually the base station has unlimited power supply and can communicate with very far distance. Figure 1 shows the wireless sensor network underground the coal mine.

Figure 1

Underground wireless sensor network.

Because of wireless transmission attenuation in an underground coal mine is influenced by a variety of factors, such as the corner, damper, and the slope. During the setting up of a sensor node, one should consider these factors, select the locations ease for communication, and appropriately increase the layout density of nodes. However, the layout density of nodes should not be very dense because the network communication latency would increase with the layout density. The real challenge for designing the topology of a wireless sensor network in underground coal mines is to find a proper topology for gaining the high system reliability and robustness demand by coal mine monitoring system. Considering the complex geographical conditions in coal mines, the network topology for underground should differ from the typical wireless sensor networks. Particularly, underground coal mine wireless sensor network is established by the ZigBee [18] nodes through ad hoc networks, which is an IEEE 802.15.4-based new wireless personal area net communication technology, with the advantage of simple, low cost, low power, ability of heavy capacity, and easy networking, and underground ZigBee wireless sensor network is comprised of a coordinator and multiple routers/end devices. The coordinator provides the initialization, maintenance, and control functions for the network. The router has a forwarding capability to route sensed data to a sink node. The end device lacks such a forwarding capability. The topology of underground ZigBee wireless sensor network is shown in Figure 2.

Figure 2

Topology for underground ZigBee wireless sensor network.

The underground coal mine corridor is segmented into many sections according to the geographical conditions and the ambient environment. Here, the arrangement and the scope of the wireless sensor nodes constantly change to march the advancement for the coal mining, which can cause the serious power consumption of node in long-distance data transmission. In order to ensure the network data transmission efficiently and save energy consumption, we use the cluster tree network is a special case of a peer-to-peer network. Any of the monitoring sensor nodes may act as a coordinator and provide synchronization services to other devices or other coordinators. Underground ZigBee wireless sensor network is composed of an ordinary cluster node, a cluster head, and an information transmission system. Particularly, the cluster node is equipped with humidity, methane sensors, and other sensors. It has a low computing capability and significant limitations of radio bandwidth and battery capacity. The cluster head is responsible for managing inner cluster nodes and transmitting information to the monitoring center via fiber cables. It has significantly more communication and power capacity than the battery-powered cluster nodes. The cluster nodes which are far removed from the cluster head have to choose appropriate routes to transfer their sensing data. The neighbors relay the data one by one to the cluster head.

3. Complex Alarming Event Detecting Approach

3.1. Events and Complex Events Description

The underground wireless sensor network will sense the environment conditions such as temperature, oxygen concentration, and humidity. Those collected data are transmitted to the sink node using multihop routing. To detect the possible anomalies like fires, explosions as gas explosions, dust explosions, premature explosions of charges, and toxic gases as carbon monoxide, and the methane, or even a roof failure, and the original data streaming should be abstracted for the complex event. Those original events are divided into three categories according to the semantics and the complexity of the event itself, which are atomic events, basic events, and the complex events, which are shown as Figure 3.

Figure 3

Atomic event, basic event, and complex event model.

It is observed from Figure 3 that the event description language is used to describe the relations between events. Particularly, the atomic event is simply defined as each change of the data monitored by the sensor with no semantics. The atomic event description is

\begin{matrix} E A t o m (s e n s o r_i d, l o c_i d, t y p e, v a l u e, t i m e s t a m p), \end{matrix}

(1)

where sensor_id represents the id of the sensor, which is the only identifier of a sensor. Loc_id represents the location id of the sensor. Type represents the factor's type the sensor monitoring. Value represents the value the sensor reads. Timestamp represents the time attribute.

Basic event is based on atomic events with some semantic and describes the occurrence of some relevant behavior between atomic events. Defining the basic events can filter the huge event flow from the sensor layer and improve the efficiency of queries. The basic event description is

\begin{matrix} E B a s i c (r u l e, e v e n t s, a t t r s, t i m e s t a m p), \end{matrix}

(2)

where rule represents the inquiry rules. Events represent a set of the atomic events. Attrs represents a set of the optional attributions of the basic events. Timestamp represents the time attribution of the basic event. Particularly, two primary kinds of basic events that frequently appear in event streaming are present in the following. The monitored value of a certain sensor is beyond some warning level:

\begin{array}{l} E B e y o n d W a r n i n g L e v e l (r u l e, e v e n t s, s e n s o r_i d, l o c_i d, \\ t y p e, v a l u e, l e v e l, t i m e s t a m p) . \end{array}

(3)

The monitored value of a certain sensor is beyond some warning level and lasts for interval time:

\begin{array}{l} E S t a y W a r n i n g L e v e l (r u l e, e v e n t s, s e n s o r_i d, l o c_i d, t y p e, \\ v a l u e, l e v e l, i n t e r v a l, t i m e s t a m p) . \end{array}

(4)

The complex event is composed of basic events or complex events. In complex event processing, events are connected via event connectors. If the connected events satisfy the specific semantic, it is said that the complex event happens. The complex event description is

\begin{matrix} E C o m p l e x (r u l e, e v e n t s, a t t r s, t i m e s t a m p), \end{matrix}

(5)

where events represent a set of the basic events or complex events. The meaning of the other attributions is similar to the meaning of attributions mentioned in the basic event. The complex events mainly refer to alarming events. In most general forms of complex event processing, the relationships between events mainly include timing relationship, causal relationship, and combination relationship.

The combination relationship is the most popular relationship between events. The main connectors of combination relationship include and, or, and not. Let ∧ represents and connector, and ∨ represent or connector, ¬ represent not connector.

$E_{b w l} (t, l o c, l v)$ represents the basic event expressed in (3), which means that at location $l o c$ the value of t type factor exceeds the alarming value at alarming level $l v$ .

$E_{s w l} (t, l o c, l v, i n t e r v a l)$ represents the basic event expressed in (4), and which means that at the location $l o c$ the value of t type factor exceeds the alarming value at alarming level $l v$ and lasts for interval time.

$E_{c} (t, l o c, l v)$ represents at location $l o c$ , t type factor alarming at alarming level $l v$ . Then,

\begin{array}{l} E c 1 = E b w l (t = {CH}_{4}, l o c, l v = 2), \\ E c 2 = E b w l (t = {CH}_{4}, l o c, l v = 1) \\ \land E b w l (t = W i n d, l o c, l v > 1), \\ E c 3 = E s w l (t = {CH}_{4}, l o c, l v = 1, i n t e r v a l > 10 \min), \\ E c (t = {CH}_{4}, l o c, l v = 2) = E c 1 \lor E c 2 \lor E c 3 . \end{array}

(6)

It is observed from expression (6), and the ${CH}_{4}$ alarming event at level 2 happens perhaps because the ${CH}_{4}$ value exceeds the level 2 limitation, perhaps because the ${CH}_{4}$ value exceeds the level 1 limitation and the wind value exceeds the level 1 limitation, and also perhaps the ${CH}_{4}$ value exceeds the level 1 limitation and lasts for 10 minutes, which we suppose is the time limitation for the alarm promotion. The complex events model defines the relationship between the events and the behavior of event processing.

3.2. State-Automata-Based Complex Event Detection Algorithm

For any kind of complex event processing engine needs the complex event detection algorithm to describe how to detect the complex event patterns, with a large number of original events generated from the underground wireless sensor network, upon the strict temporal logics that describe the complex event rules, and it is necessary to match the complex event pattern with the predefined rules from the continuous events streaming. Here, the state-automata-based detection algorithm is applied to the complex event pattern detection.

Here, the state automata (state automata, $S A$ ) for complex event detection can be described with a six tuple describes $S A = 〈 I E, O E, S, T r and of S s, S a 〉$ , of which $I E$ means the event streaming into the state machine. $O E$ means the detection for the complex event successfully. S means the set of all possible states of the state automata. $T r$ means the transition relations between all states for the set $S \times S$ , and $T r$ is generally required to satisfy the event constraints. $S_{s}$ means the initial state for state automata. $S a$ means the acceptable state automata and detects the status of a rule that matches the incident. The main idea of the complex events detection algorithm is to construct a corresponding state automata for each user-defined patterns of events and get the corresponding set of states S for event patterns, the transition relations set $T r$ between all states for the set $S \times S$ , the input stream $I E$ for the state automata, and the reachable event domain $T E$ for each transition. Next based on user-defined rules to match the arrival input event stream $I E$ , if did not transit to an acceptable state $S a$ , and the complex events would be detected successfully.

The specific sequence of events will reach to the state automaton at different times in the run-time. When detects the sequence of the events, and to create an instance if an event in a sequence of events satisfies the initial conditions $S_{s}$ for the state machine, and to set the state as $S_{1}$ .

When the sequence of events automatically is detected to satisfy the conditions of transitions between the two states in state automata, and the state would be changed from $S_{i}$ to $S_{i + 1}$ . When some events trigger the transitions in the event sequence, and changed to the accepting states, and which means the event patterns have been detected successfully. Or the instance of state automata becomes invalid, and the state automata instance will be deleted. Considering the above scenario, it assumes that the methane gas alarming is happened also need the Oxygen concentration to reach a certain value:

\begin{array}{l} E C o m p l e x (r u l e : l o c_i d = l o c, t y p e = t, l e v e l = l v, \\ e v e n t s, 〈 l o c, t, l v 〉, t i m e s t a m p) h a p p e n s a s E c \\ at A n d (C o n s u m (F i r C h (E b w l (t, l o c, l v = 2))), \\ E o b w (t = O_{2}, l o c, l v = 2), T 1, T 2) . \end{array}

(7)

The state-automata-based coal mine complex events pattern detection model diagram for the above scenario is described in Figure 4.

Figure 4

The state automata model for event detection.

Here, $S_{s}$ means the initial state of the state automata, and $S_{e}$ means the termination state of the state automata. The specific steps for state automata for coal mine complex event detection scenarios are described as follows. According to the description of the event pattern, the state in the state automata is represented by the related event in the event pattern. Different states transition can be represented by the constraint state transition rules in the state automata. The matched sequence is denoted by $M S$ , and ${M S}_{k i}$ means that the kth matched sequence, and the sequence is in the ith state, whenever there are new events to meet the transition condition, and then to update $M S$ , or create a new copy of the $M S$ .

Here, it is also assumed that the monitoring time interval is 5 minutes, and the input event sequence is described as follows.

$E_{c 1} (t = {CH}_{4}, l o c = 2, l v = 2)$ represents the value of alarming events exceeding 2 levels in the time 1, where the sensor type is ${CH}_{4}$ , and the location value is 2.

$E_{c 2} (t = {CH}_{4}, l o c = 2, l v = 2)$ represents the value of alarming events exceeding 2 levels in the time 6, where the sensor type is ${CH}_{4}$ , and the location value is 2.

$E_{o 1} (t = O_{2}, l o c = 4, l v = 2)$ represents the value of alarming events exceeding 2 levels in the time 3, where the sensor type is $O_{2}$ , and the location value is 4.

$E_{o 2} (t = O_{2}, l o c = 2, l v = 2)$ represents the value of alarming events exceeding 2 levels in the time 7, where the sensor type is $O_{2}$ , and the location value is 2.

$E_{o 3} (t = O_{2}, l o c = 2, l v = 2)$ represents the value of alarming events exceeding 2 levels in the time 8.

The state-automata-based complex event detection algorithm with the above-mentioned scenario is described as Figure 5, and more details for each step are also described as follows.

Figure 5

The state-automata-based event detection algorithm.

Step 1.

At the time 0, to initiate a matched sequence ${M S}_{10}$ .

Step 2.

At the time 1, when the event in location $l o c = 2$ for the gas concentration exceeds 2 levels of arrival, which meets the state transition conditions for ${M S}_{10}$ , and so to update ${M S}_{10}$ to the new state of ${M S}_{11}$ and also create a new matched sequence ${M S}_{20}$ .

Step 3.

At the time 3, when the event in location $l o c = 5$ for oxygen concentration exceeds 2 levels of arrival, which does not meet the trigger conditions for state transition, so the event is discarded.

Step 4.

At the time 6, when the event in location $l o c = 2$ for the gas concentration exceeds 2 levels of arrival, which meets the state transition conditions for ${M S}_{10}$ , and so to update ${M S}_{20}$ to the new state of ${M S}_{21}$ , and also create a new matched sequence ${M S}_{20}$ . At the same time, the ${M S}_{11}$ has been five minutes of time constraints, so the matched sequences should be discarded.

Step 5.

At the time 7, when the event in location $l o c = 2$ for the oxygen concentration exceeds 2 levels of arrival, which meets the state transition conditions for ${M S}_{21}$ , and so to update ${M S}_{21}$ to the new state of ${M S}_{22}$ , and reach the end state, so the matched sequence of ${M S}_{22}$ has been found to meet the events pattern, and then output this events sequence.

Step 6.

At the time 8, when the event in location $l o c = 2$ for the oxygen concentration exceeds 2 levels of arrival, which meets the state transition conditions for ${M S}_{21}$ , and so to update ${M S}_{21}$ to the new state of ${M S}_{22^{'}}$ , and reach the end state, so the matched sequence of ${M S}_{22^{'}}$ has been found to meet the events pattern, and then output this events sequence.

3.3. Pub/Sub-Based Complex Events Dispatching Model

The publish/subscribe model provides a mechanism to dispatch the sensor data, which acts as a mediator between sensors who publish primitive events and consumers who subscribe to events of interest. There is no direct relationship between producers and consumers of data. Each sensor can be considered as a publisher that outputs a constant stream of data with a fixed schema. The applications can subscribe to various events from different sensors and produce their own events. The events dispatching model is shown in Figure 6.

Figure 6

Publish/subscribe based event dispatching model.

Here, there are two types of messages that flow through the publish/subscribe component, one is the signal messages and the other is the data messages. The signal message refers to the subscription and unsubscription messages. The data message mainly refers to the status changes of the sensor, the occurred alarming, and the on/off status for the switcher. Generally, those messages format is XML-based and also contains the topic that the messages belong to in the message header, and the message structure is described as follows:

<env:Envelope

xmlns:env=http://schemas.xmlsoap.org/soap/envelope/

xmlns:wsa=“http://www.w3.org/2005/08/addressing”>

<env:Body>

<wsnt:Notify xmlns:wsnt=“http://docs.oasis-open.org/wsn/b-2”>

<wsnt:NotificationMessage>

<wsnt:Topic Dialect=“…/wsn/t-1/TopicExpression/Simple”>

AlarmTopic

</wsnt:Topic>

<wsnt:Message>

AlarmMessageBody

</wsnt:Message>

</wsnt:NotificationMessage>

</wsnt:Notify>

</env:Body>

</env:Envelope>

Here, the publish/subscribe component can be easily hot deployed to the service bus. The topic-based publish/subscribe mechanism is applied, and the sequence diagram is shown in Figure 7.

Figure 7

Sequence diagram for publish/subscribe model.

It is observed from Figure 7 that the message PullPointQueue is used to save the message subscription for each message entity. The message interaction is described as follows: (1) the object of message entity class creates the message PullPoint; (2) the object of WSN component class creates the message PullPoint using the object of the PullPointQueue class; (3) when the subscription message occurs, the object of message entity class subscribes the assigned the subscription and the message of the PullPoint using the object of WSN component class; (4) the object of WSN component class creates the message through the object of message topic class; (5) the object of WSN component class subscribes to the specified topic and the message of PullPoint; (6) when the messages are published, the object of the message entity class notifies the published information using the object of WSN component class; (7) the object of WSN component class publishes the message; (8) the object of message topic class publishes the message; (9) the object of WSN component class gets the subscribed message through the object of message PullPointQueue.

As the mediator of the publisher and subscriber, publish/subscribe component realizes the decoupling of space and time between publisher and subscriber. This component provides the interfaces of publish, subscribe/unsubscribe, and notify. There are mainly two kinds of message that flow through the publish/subscribe component: signal message and data message. Signal message is the message that contains control instruction, such as subscribe instruction and unsubscribe instruction. Data message is composed of topic and data content, which means mainly the occurrence of various alarming events.

The publisher uses the registered publisher message to confirm whether can publish one or some of the topics. If an entity wants to be registered as a publisher, it must send the register publisher request message to the notification proxy. The message is described in following format:

<wsnt:RegisterPublisherRequest>

<wsnt:PublisherReference>

wsa:EndpointReference

</wsnt:PublisherReference>?

<wsnt:Topic>wsnt:TopicPathExpression</wsnt:Topic>*

<wsnt:Demand>xsd:boolean</wsnt:Demand>?

<wsrl:InitialTerminationTime>

xsd:dateTime

</wsrl:InitialTerminationTime>?

</wsnt:RegisterPublisherRequest>

It is necessary to define the publisher point reference for the register message, which is specified with the <wsnt:PublisherReference> tag. Also, it is needed to specify the topic of their own support, which is a list that contains many topic and is specified by the <wsnt:Topic> tag. Finally, the type and initial termination time for the publisher are optional, which can be specified by the <wsnt:Demand> tag and <wsrl:InitialTerminationTime> tag.

Message subscriber sends the subscription request to the notification producer for the information to register that it is interested in one or more topics, and of course the related notification message will be distributed to the subscriber specified in the subscription. As part of processing the registration request message, the notification producers must create a representative subscription of resources and return a response packet that contains the endpoint reference, and the endpoint reference contains the address of the subscription management services and subscription resources reference properties. The subscription message format is as follows:

<wsnt:SubscribeRequest>

<wsnt:ConsumerReference>

wsa:endpointReference

</wsnt:ConsumerReference>

<wsnt:TopicPathExpression/>

<wsnt:SubscriptionPolicy>wsp:Policy</wsnt:SubscriptionPolicy>?

<wsrl:InitialTerminationTime>

xsd:dateTime

</wsrl:InitialTerminationTime>?

</wsnt:SubscribeRequest>

A subscription message body first needs to specify a specific notification consumers, which is specified with the <wsnt:ConsumerReference> tag, and the notification message will be sent to this endpoint reference point, also needs to specify the topic that subscribed with <wsnt:TopicPathExpression/> tag. The notification schema and subscription time are optional, and the subscribers can choose to direct notification or proxy notification, but also can specify the end time for the subcription, such as a month, which can be specified with <wsnt:SubscriptionPolicy> and <wsrl:InitialTerminationTime> tags. Each subscription request will give the corresponding responses, and the response message format is described as follows:

<wsnt:SubscribeResponse>

<wsnt:SubscriptionReference>

<wsa:Address>Address Manager</wsa:Address>

<wsa:ReferenceProperties>

Subscription Identifier

</wsa:ReferenceProperties>

</wsnt:SubscriptionReference>

</wsnt:SubscribeResponse>

The response message contains the subscription manager address and subscription result, which can specify with <wsa:Address> and <wsa:ReferenceProperties> tags. Notification message, all the messages are SOAP-based in the web service notification publish/subscribe model, and the representation for the notification message is the most concerned. The following XML element description is a core part of the notification message:

<wsnt:Notify>

<wsnt:NotificationMessage>

<wsnt:Topic>wsnt:ConcreteTopicPathExpression</wsnt:

Topic>

<wsnt:ProducerReference>?

wsa:EndpointReference

</wsnt:ProducerReference>

<wsnt:Message>xsd:any</wsnt:Message>

<wsnt:NotificationMessage>+

</wsnt:Notify>

Here, a notification message contains one or more message body, and the message body must specify the related topic, namely, the content for the above-mentioned <wsnt:Topic> tag, and can specify the endpoint reference for the notification producers, but this is optional and specified with <wsnt:ProducerReference> tag. The content of the <wsnt:Message> tag is the message body, which is the content of the notification message. With such a standard format, any subscriber needs to implement a standard method to process the notification message from any of the services.

4. BPEL-Based Safety Alarming Disposal Process

When a safety alarming event occurs, effective disposal process should be taken right away to eliminate the corresponding alarming. Here, the event condition action is applied to trigger the corresponding process to eliminate the safety alarming. Here, an event condition action (ECA) [19, 20] rule consists of three parts: event, which causes the rule to be triggered; condition, which is checked when the rule is triggered: action, which is executed when the rule is triggered and condition is true. The external event in service process will trigger the corresponding rules and execute the activity that is defined in the service process, while the activities will generate new events in the service process. Therefore, the active service provision is presented among the activities in the process, events, and rules. Here, an ECA rule can be written in the form of E[C]A. Generally, the enhanced event condition action rule conforms to the following patterns.

Event-Action Pattern

When received the event, and then to trigger the related actions.

Event-Condition-Action Pattern

When received the event that satisfied the condition, and then to trigger the related action.

Event-Conditionⁿ-Actionⁿ Pattern

When received the event that satisfied the ${condition}_{n}$ , and then to trigger the related ${action}_{n}$

\begin{array}{l} C_{n} = {{Condition}_{1} C {Condition}_{2} C \dots C {Condition}_{i}}, \\ i \geq 1; \\ A_{n} = {{Action}_{1} £ {Action}_{2} £ \dots £ {Action}_{j}}, j \geq 1 . \end{array}

(8)

Here, a simple ECA rule E[C]A can be realized by a BPEL event handler. As soon as an occurrence of event is registered, the event handler starts with a switch activity in which condition C is evaluated. If C evaluates to true, the activity A is carried out; otherwise, nothing can be done. This event handler may be simplified if C is a Boolean constant TRUE. Especially, the alarming disposal is implemented to inform the relevant staffs to handle the alarming events, and each alarming has a complete BPEL-based processing flow that contains many steps or services. Here, the corresponding disposal process is shown in Figure 8, which is triggered once a corresponding coal mine safety alarming situation happens.

Figure 8

BPEL for safety alarming disposal process.

It is observed from Figure 8, once the alarming event occurs, and it will trigger the corresponding alarming disposal process. Especially, the alarming disposal process receives the alarming events, and there is a need to determine the number of steps for the alarming disposal process based on the alarming ID, and then to publish the corresponding causes and measures to be processed, and also it is needed to determine which relevant staffs should be in charge of, and at the same time, to send the short messages and email to them. It is necessary to take some certain measures, and to deal with the corresponding alarming disposal process.

5. Implementation

Complex event processing can create high-level events from numerous low-level events. Events are created by filtering real-time data and infusing it with defining details such as dependencies or causal relationships discovered by correlating other events. We present and implement a real-time complex alarming event processing and disposal platform for coal mine safety using event-driven service-oriented architecture, which allows to operate the corresponding closed-loop controlled disposal process dynamically, in real time, as safety alarming events occur. The implementation of real-time complex alarming event processing and disposal platform for coal mine safety is based on the open-source enterprise service bus (ESB) ServiceMix core [21] and allows to easily configure the message routing, intermediation, transformation, logging, task scheduling, fail over routing, and load balancing, and also which has a pluggable architecture that allows organizations to use their preferred service solutions in SOA. Here, it contains the service engine or binding component, such as BPEL service engine, CEP engine, and WSN service engine, which should be deployed to the ESB container. Figure 9 shows the complex alarming event processing and disposal platform architecture for coal mine safety using event driven SOA, which adopts the enterprise service bus as the foundation infrastructure.

Figure 9

Proposed platform framework.

The CEP module provides a technology to detect the relationships in real time between series of simple and independent events from wireless sensor network, using predefined rules. Here, we consider a lot of underground heterogeneous sensor devices that generate isolated events, which can be used to obtain valuable information and to make decisions accordingly.

The publish/subscribe module is a service engine (SE) component of the ESB which implements web service notification (WSN) specification. It is responsible for message interaction in the system. Other modules can subscribe the concerned topic and also can publish message via this module. For instance, the CEP module publishes the alarming message to the system, and the control server module subscribes the alarm topic correspondingly.

The coal mine safety alarming disposal process module mainly includes a BPLE service engine and acts as the execution engine of BPEL process. The alarming disposal process is written in BPEL, which describes a closed-loop control disposal process to handle the alarming events. The corresponding disposal process will be invoked when the control server captures the occurrence of the alarming event. When receives an alarming event on its delivery channel from WSN service engine, the BPEL service engine starts to execute the BPEL script corresponding to this service and port. It also validates the message received with the message type described in the WSDL. Here, the normalized message router (NMR) is responsible for mediating messages between different service engines. The service engines never send messages directly between each other. Instead, they pass messages to the NMR. The NMR is responsible for delivering the messages to the correct service engine endpoints. This allows the service engine components, and the functionality they expose, to be location-independent. The activity diagram in Figure 10 depicts a one-way service invocation between BPEL and WSN service engines, including a message exchange instance.

Figure 10

Service invocation between BPEL and WSN SEs.

It is observed from Figure 10 that BPEL SE acts as a service consumer and invokes the desired service by creating and establishing a request message exchange, containing the request message. BPEL SE then sends the message exchange instance to the NMR. This is shown by the message process flow between the BPEL SE and NMR. The NMR determines which service provider should provide the requested service and operation and routes the message exchange instance for delivery to the provider. This is shown by the message process flow between the NMR and the WSN SE. Particularly, on one hand, the BPEL SE can process the corresponding messages from the WSN SE, and on the other hand, the WSN SE can be event-driven, to send and receive the message exchanges which can take place at the same time, and this message is then sent through the delivery channel.

The control server subscribes the concerned events, invokes the BPEL-based alarming disposal process, and pushes the state change message to the clients.

The client communicates with control server and provides a user interface for user interaction. When receiving the state change information from the control server, the client updates the display panel.

The real-time complex alarming events detecting and disposal processing platform for underground coal mine safety using event-driven service-oriented architecture, which can monitor, display, alarm, and control various parameters of underground coal mine environment and production of coal mine and methane drainage process, and also can monitor and display environmental parameters such as methane, air flow, negative pressure, carbon monoxide, smoke, temperature, and air-door, and have functions of failure locking and alarming, local or remote overlimit power-off, interlocking of air, electricity and gas, and so forth. Figure 11 shows the underground coal mine safety alarming scenarios.

Figure 11

The coal mine safety alarming scenarios.

It is observed from Figure 11 that when the alarming is generated, it is accompanied by flashing of the tab, and the corresponding sensor on the underground coal mine map is also twinkled, and the alarming list items are increased on the right side. At the same time, there is a need to start a disposal process from the server side, and the disposal process status is monitored, and the corresponding disposal owners can do the appropriate processing. Particularly, the ReceiveData, the WarningLevel, and GetPrincipalInfo service as the main processing logic for the safety disposal process, and which can monitor the data, processing, and preparation of related alarming information. More details for the safety disposal process are described as follows. When the alarming disposal process first received the message from the web client, and to analysis and processing, and then to access the corresponding monitoring values for each monitoring point ID, and then to call the warningLevel services to match an appropriate safety disposal process. When the corresponding alarming disposal process item from the alarming list on the right panel is selected, then click the bottom button “show alarming handling process” to enter the closed-loop control for alarming disposal, and the status can be monitored for alarming disposal process, as shown in Figure 12.

Figure 12

Safety alarming disposal process scenarios.

It is observed from Figure 12, when the safety alarming occurs, it is necessary to take some certain measures, and to deal with the corresponding alarming disposal process, which is triggered by the alarming events. All the information for the safety alarming, and the charged staffs for each disposal steps, and the status for the current disposal process should be monitored in real-time way during the course of the alarming disposal processing.

6. Conclusion and Future Work

We proposed a real-time complex alarming event detecting and disposal processing approach for coal mine safety using wireless sensor network. In the proposed approach, we introduce the event and complex events model, offer fully customizable policies for event selection and consumption, and also describe the state-automata-based complex event detection algorithm. Then, we introduce an event-driven service coordination pattern for the behavioral model, which is based on ECA triggering with control flow realized using decoupled publish/subscribe semantics. Finally, a real system is implemented, showing the effectiveness of the proposed approach. In the future, we will continue to research on application of complex alarming event processing in the Internet of Things domain. Besides, more performance and scalability tests may be conducted with data flow in larger scales, and better performance and further improvements are expected.

Footnotes

Acknowledgments

This study is supported by 973 Program of National Basic Research Program of China (Grant no. 2011CB302704); National Natural Science Foundation of China (Grant nos. 61001118, 61171102); Program for New Century Excellent Talents in University (Grant no. NCET-11-0592).

References

Liu

Underground coal mine monitoring with wireless sensor networks

ACM Transactions on Sensor Networks 2009 5 2 10

2-s2.0-61449091346

10.1145/1498915.1498916

Hargrave

C. O.

Ralston

J. C.

Hainsworth

D. W.

Optimizing wireless LAN for longwall coal mine automation

IEEE Transactions on Industry Applications 2007 43 1 111 117

2-s2.0-33947203205

10.1109/TIA.2006.885892

Bhattacharjee

Roy

Ghosh

Misra

Obaid

S. M.

Wireless sensor network-based fire detection, alarming, monitoring and prevention system for Bord-and-Pillar coalmines

Journal of Systems and Software 2012 85 3 571 581

Cucinotta

Mancina

Anastasi

G. F.

Lipari

Mangeruca

Checcozzo

Rusinà

A real-time service-oriented architecture for industrial automation

IEEE Transactions on Industrial Informatics 2009 5 3 267 277

2-s2.0-69249218873

10.1109/TII.2009.2027013

Luckham

C. D.

Frasca

Complex event processing in distributed system

Stanford University Technical Report 1998 CSL-TR-98-754

Delamer

I. M.

Martinez Lastra

J. L.

Service-oriented architecture for distributed publish/subscribe middleware in electronics production

IEEE Transactions on Industrial Informatics 2006 2 4 281 294

2-s2.0-33751524316

10.1109/TII.2006.885188

Kyusakov

Eliasson

Delsing

van Deventer

Gustafsson

Integration of wireless sensor and actuator nodes with IT infrastructure using service-oriented architecture

IEEE Transactions on Industrial Informatic 2012 8 3 1 9

Willig

Recent and emerging topics in wireless industrial communications: a selection

IEEE Transactions on Industrial Informatics 2008 4 2 102 122

2-s2.0-44249108577

10.1109/TII.2008.923194

Kalogeras

A. P.

Gialelis

J. V.

Alexakos

C. E.

Georgoudakis

M. J.

Koubias

S. A.

Vertical integration of enterprise industrial systems utilizing web services

IEEE Transactions on Industrial Informatics 2006 2 2 120 128

2-s2.0-33646723326

10.1109/TII.2006.875507

10.

Cucinotta

Mancina

Anastasi

G. F.

Lipari

Mangeruca

Checcozzo

Rusinà

A real-time service-oriented architecture for industrial automation

IEEE Transactions on Industrial Informatics 2009 5 3 267 277

2-s2.0-69249218873

10.1109/TII.2009.2027013

11.

Medjahed

Dissemination protocols for event-based service-oriented architectures

IEEE Transactions on Services Computing 2008 1 3 155 168

2-s2.0-77957973963

10.1109/TSC.2008.13

12.

Sheng

Q. Z.

Benatallah

Maamar

Ngu

A. H. H.

Configurable composition and adaptive provisioning of web services

IEEE Transactions on Services Computing 2009 2 1 34 49

2-s2.0-77950653723

10.1109/TSC.2009.1

13.

IBM Corporation Business Process Execution Language for Web Services, specification at: http://www.ibm.com/developerworks/library/ws-bpel

14.

De Kock

Oberholzer

J. W.

The development and application of electronic technology to increase health, safety, and productivity in the South African coal mining industry

IEEE Transactions on Industry Applications 1997 33 1 100 105

2-s2.0-0030643205

15.

Nutter

R. S.

Jr Aldridge

M. D.

Status of mine monitoring and communications

IEEE Transactions on Industry Applications 1988 24 5 820 826

2-s2.0-0024079633

10.1109/28.8986

16.

Cole

H. P.

Vaught

Wiehagen

W. J.

Haley

J. V.

Brnich

M. J.

Decision making during a simulated mine fire escape

IEEE Transactions on Engineering Management 1998 45 2 153 162

2-s2.0-0032069217

17.

Sacks

H. K.

Novak

A method for estimating the probability of lightning causing a methane ignition in an underground mine

IEEE Transactions on Industry Applications 2008 44 2 418 423

2-s2.0-42049096121

10.1109/TIA.2008.916599

18.

Koh

B. K. P.

Kong

P. Y.

Performance study on ZigBee-based wireless personal area networks for real-time health monitoring

ETRI Journal 2006 28 4 537 540

2-s2.0-33747168751

19.

Almeida

E. E.

Luntz

J. E.

Tilbury

D. M.

Event-condition-action systems for reconfigurable logic control

IEEE Transactions on Automation Science and Engineering 2007 4 2 167 180

2-s2.0-34147125889

10.1109/TASE.2006.880857

20.

Bae

Kang

S. H.

Kim

Automatic control of workflow processes using ECA rules

IEEE Transactions on Knowledge and Data Engineering 2004 16 8 1010 1023

2-s2.0-4344668668

10.1109/TKDE.2004.20

21.

Apache ServiceMix project home, http://servicemix.apache.org/home.html