3.1. Overall Introduction
To realize intelligent greenhouse control, the CEP system needs to regard the fluctuation of different types of data in the greenhouse as the most basic atomic events at first. Additionally, it should continuously match and calculate to generate more complex events by analyzing the logical relationship between basic events. Some of the complex events contain the control commands and complex scene information needed in the greenhouse environment. The goal of our design is to provide a CEP system with simple data analysis capabilities and a complex event processing system framework that can yield control instructions based on expert commands or automatic control schemes. The core work is to design and implement a complex event processing engine.
Figure 1 shows the connection between the system and other objects in the greenhouse. These objects are sensors, feedback units, experts and other analysis systems, control strategies, and actuators in addition to the CEP system and greenhouse. Among them, different functional sensors include air humidity sensors, soil sensors, etc. The feedback unit and actuator can work on Internet of Things software platforms such as Fiware and ZigBee network facilities to transmit the data of sensors and controllers. Other analysis systems could be PhenoArch or other phenotype analysis platforms, which can generate meticulous and ample data information. The control strategy could be a simple switching operation or a more complex timing control mechanism. When a control strategy needs to be executed, the state of the controllers could be modified according to the preset instructions.
In detail, the sensors are responsible for collecting the physical and chemical information in the greenhouse and transmitting the original data to the feedback unit, agricultural experts, and other analysis systems to achieve preliminary processing. The feedback unit packs environmental data into events (atomic events) and transmits them to the CEP system. Agricultural experts and other analysis systems conduct preliminary analysis based on actual conditions. The feedback unit, agricultural experts, and other analysis systems package the analysis results into events and send them to the CEP system. When the CEP system receives this data and the event containing equipment status information fed back by the actuator, it will be transmitted to different processing modules (event processing agent, EPA) in the CEP engine through the event distribution middleware. EPA will analyze the input events in time sequence and logic according to the predetermined CEP rule set, so as to get high-density complex scene information. The identified complex scenes can eventually be fed back to agricultural experts and other analysis systems and mapped to the corresponding control strategies. In this way, the closed-loop control of the greenhouse is realized by the whole system.
For the convenience of description, according to the functions of the above objects, they are divided into four major information objects: CEP system (left, dark gray), controller (above, red), worker (middle, blue), and environment (below, green). In the CEP system, all input and output information will be packaged into events and delivered through event distribution middleware. The CEP engine runs according to the designed CEP rule set, including filtering, aggregating, and generating events. Nowadays, middleware technology represented by Kafka [
65] has matured, so this article focuses on the layout of CEP rules to provide reliable assistance for agricultural workers to use CEP technology in greenhouses.
As mentioned above, to build a CEP rule set, we need to stipulate the category of events, define atomic events, complex events, and the specific input and output of each type of EPA that can realize the event aggregation function, and finally constitute a complete event aggregation structure. This can reduce the repetition and incidental loss of intermediate information, thereby achieving information decoupling and determining whether complex scenes occur, and scheduling control strategies.
The following will present the general structure of the greenhouse-oriented CEP engine, the structural definition of various events, and the functional definition of EPA. It provides a general implementation of the greenhouse-oriented CEP system for agricultural experts and related workers. Subsequent experiments will be based on this structure for concrete function realization and feasibility verification.
3.2. Complex Event Processing Logical Relationships
In the process of judging complex scenes, it is necessary to analyze the logical relationship in time and space between low-level simple events to determine whether high-level complex events have occurred. Then, the complex event flow is synthesized by calculating the relevant information of the high-level events. The process of simple event flow evolving into complex event flow is called event aggregation. The logic between events that has been set is called event mode. The unit that performs matching and event generation based on event patterns is called an event processing agent (EPA). Through layer-by-layer aggregation, complex events are finally generated. These events can trigger control commands, get more valuable judgment information, and complete the reasoning process.
This article proposes 13 types of EPA and 21 types of typical events involved in greenhouse automatic control. The aggregation relationship between EPA and events is shown in
Figure 2. The circular nodes in the figure represent events. The color of the nodes represents the information source and destination of the event (as shown in
Figure 1 in the above section). Gray nodes represent the output of the event by the system. The square nodes correspond to the classes of EPA of the CEP engine, which can aggregate the input events to obtain the output events. In particular, the dashed arrows in the figure represent that one EPA module directly modifies the parameters of another EPA module. Each EPA module can be built using the existing CEP technology or can be replaced with any event processing module with the same type of event input and output (e.g., using machine learning for event classification filtering [
66]). This makes the CEP system have the characteristics of multi-field and multi-technology integration.
Each event flow from the beginning to the end corresponds to a specific farming problem. The system needs to use the existing coping strategies to build an event processing unit, analyze the current situation according to the event sequence, and transmit the analysis results to other units. The specific agricultural problems contained in the system are as follows:
In terms of environment, it is necessary to observe the changing trend of the greenhouse during the regulation (EPA2), find the most favorable greenhouse environment state for crop growth according to the crop planting plan (EPA5, EPA6, EPA3), and consider the mutual influence relationship existing in the greenhouse refinement regulation target (EPA7). The search for the most favorable greenhouse environment can be further refined into looking for the impact of the environment on crop growth (EPA5), the determination of crop growth status and the adjustment of control targets (EPA6), and the combination of control targets to judge the current state of the greenhouse (EPA3).
In terms of control, the system needs to monitor whether the connection and operation of the controller are normal (EPA8), consider the impact of the environment on the controller effect (EPA1, EPA4), how to dispatch the controller and generate early warning information (EPA9, EPA10, EPA11, EPA12), and whether the instruction execution is smooth (EPA13).
For the convenience of description, we have given the name of the EPA that solves the corresponding agricultural issues in parentheses. In the following, we will introduce the corresponding types and definitions of each event and the implementation methods and specific functions of each EPA one by one. In the experiment, we will build an example of the CEP system based on common solutions to agricultural problems.
3.3. The Event Definition
In this paper, the state change of the complex system is called "event". To make the structure shown in
Figure 2 work smoothly, it is necessary to strictly define the type and basic structure of events transmitted between each EPA module and system input and output.
Backus Naur Form (BNF) paradigm is a formal syntax representation method, which is often used to describe program syntax [
67] and data structure [
68]. This paper will use the following extended BNF paradigm to define the structure of events:
<> Angle brackets are used to separate strings that are the names of grammatical elements. If a triple with “e.g.,” as the second element appears in the angle brackets, the triple is a type of terminal symbol with a specific meaning. The first element is the category name of this type of terminal symbol, and the third element is some examples of this type of terminal symbol;
::= The operator used for definition. Represents that the syntax element on the left can be replaced by the string appearing on the right;
[] The elements in square brackets can appear 0 or 1 times;
/ The vertical line indicates that the element on the left can be replaced by the element on the right.
JSON is a lightweight data exchange format. It can describe the basic structure of data through key-value pairs [
69]. This article will wrap a specific data structure with a pair of braces. Each data structure is composed of multiple key-value pairs similar to “key: value”, separated by commas.
The following will use the BNF paradigm to specify the specific structure of the above events in the form of JSON string and list some specific examples of all terminations.
Most events have a unique number, type, name, timestamp, and other basic event information. Some special events may also have location and source information. Therefore, to simplify the subsequent expression, first define the basic event structure (BES) syntax as follows.
For most of the information content types of the control system, there are three main categories, namely numeric class, state class, and information class. They appear in a single numeric, enumeration, and string type. The event wrapping of these three types of information is relatively simple, just add the necessary information content to the underlying event structure. The structure is as follows:
For some special information, we need to tailor it to:
Environmental trends, which mainly reflect environmental changes, are usually obtained by differential or forecasting of environmental information and need to indicate the start and end times, the specific structure of which is as follows:
Control method, which simply distinguishes the type of method called by name, as follows:
System configuration information, which includes executable commands and some descriptions, as follows:
For greenhouse scenes, the event is divided into three levels.
Input information (the simplest atomic event). This information originates from other information objects and acts on the control system and is the basis for the calculation of control system reasoning, as shown in
Table 1.
Intermediate information (intermediate-level complex events). This message is not directly related to the input and output of the control system, but is used as a carrier of reasoning results in the control system, as shown in
Table 2.
Output information (highest level complex events). This information originates from the control system, acts on other information objects, determines the control action of the controller, and makes it easy for workers to know about the green-house, which is an important part of the realization of automatic control, as shown in
Table 3.
3.4. EPA Definition
This article uses automata technology to build EPA and uses transitions between states to identify the content of events and their relationships. When entering a new state, complete the corresponding instructions, modify local variables, and achieve event aggregation. There are three types of transition (or jump) between states, which are triggered by specific events, timers, and boundary conditions.
Transitions triggered by specific events can check the causal dependence between events, and whether data parameters and contextual relationships are in line with expectations. Its transitional rules include three parts: pre-transition state, post-transition state, and Boolean expression. Its Boolean expression can contain two types of parameters: the type of the received event and its parameters, and the local variables in the EPA. Event parameters include information such as the source of the event, the event ID, and timestamp. When a new event is received, the EPA will determine whether the pre-transition state in the jump rule triggered by the specific event is consistent with the current state. If it matches and the Boolean expression in the rule is true, it will transition to the post-transition state. Otherwise, no operation is performed. For all transitional rules with the same pre-transition state, their Boolean expressions are mutually exclusive and should not be established at the same time.
Transitions triggered by the timer can check whether the time relationship between events is in line with expectations. The transitional rules include three parts: pre-transition state, post-transition state, and elapsed time. Among them, the elapsed time is the length of time elapsed after entering the pre-transition state. When the EPA is in a certain state, it will determine whether the pre-transition state in the transitional rule triggered by all the timers is consistent with the current state and if they match, the timer will be established according to the elapsed time. When the timer expires, the EPA will transition to the specified post-jump state. If the EPA has made a state transition before the timing is over, all current timers will be closed and no longer executed. For any state, if there are transitional rules triggered by multiple timers, the transitional rules will never be executed. Therefore, in a specific implementation, the pre-transition state of the transitional rule triggered by all timers in any EPA is different.
Transitions triggered by boundary conditions are mainly used in the EPA at the bottom of the system, and specific atomic events can be identified from the input of the system. The transitions triggered by the boundary condition will continuously check whether the input value meets the expected condition. The transitional rule includes three parts: pre-transition state, post-transition state, and the boundary condition. Among them, the boundary condition is a Boolean expression containing two types of variables, local variables, and input values in EPA. When the input values are updated, it will check whether the boundary condition is established. If it is established, the corresponding transition will be performed.
When the EPA transitions to the next state, a collection of actions required to be performed within the state is executed once. Among them, the action contains three kinds of modification of local variables, generating new events, and executing specific instructions using the event information just received.
As shown in
Figure 3, an intermediate layer EPA triggers a jump without a boundary condition. The EPA has three states (State), T, L, and N, and when it enters the T state, a Cdt event is generated, with parameters Fan and RISE, the L state is the same, and the N state has no action to perform. The EPA has no arguments and there are two jump Boolean expressions. Wherein, the t-jump Boolean expression is used to determine whether the received event is an Eft type, the first argument is tem and the second argument is Inward condition, l jump takes 5 s, and if the EPA is in the N or T state for 5 s, it jumps to the L state.
For example, when the EPA is in state N and receives an Eft(tem, Inward) event, the EPA will check whether t is established. As the result is that t is established, the EPA jumps to the T state and generates a Cdt(Fan, RISE) event. Since there is a time jump l in the T state, a timer with a duration of 5 sec is established. When the timer expires after 5 s, the EPA will automatically jump from the T state to the L state and generate a Cdt(Fan, DECLINE) event. The subsequent process is the same.
As shown in
Figure 4, it is an example of a bottom EPA with boundary conditions triggering a jump. It has four states, two parameters, two jump Boolean expressions, and two boundary conditions. The ra jump, ua jump, and all state actions are similar to the middle layer EPA and will not be explained here. The EPA has two parameters from outside input. It will continuously observe the changes of these two parameters at a certain frequency. When the relationship between the two parameters matches the up or dn jump Boolean expression, the jump will be executed.
For example, when EPA is in state U, tem is 10.0, and tem_0 is 15.0, the external temperature sensor inputs a value, and tem_0 is updated to 5.0, and EPA will check whether the dn boundary condition is established. Obviously, tem_0 < tem is established at this time, so the EPA state will jump to D, and then an Eft (tem, Inward) event will be generated.
The transceiver unit for event transmission between EPAs can form a network of multiple EPAs to communicate with each other. Each EPA will respond to input events and pass the output events to other EPAs. This type of structure constitutes an EPA communication network called the event processing network (EPN). It is the key to the aggregation of complex events.
This chapter uses Kafka middleware with a publishing subscription pattern to deliver and receive events between EPA. For each type of event in the system, a message queue with the event name as the theme is established to hold all generated events of that type in the build order. When an EPA needs to send a specific type of event, it needs to find the message queue for the topic based on the event type and publish the event to this message queue. When the EPA needs to get a specific type of event, it subscribes to the message queue for the topic based on the event type and reads from the specified location in order, and then waits for the next event to enter the queue. When the system first starts, the message queue is emptied and all subscriptions are read from the header of the message queue.