JP5810955B2 - Event collection method, event collection program, and information processing apparatus - Google Patents

Description

  The present invention relates to an event collection method, an event collection program, and an information processing apparatus.

  A sensor network that collects sensing data sensed by a sensor node as an event is known. Various services such as alert transmission and device control are provided according to events collected by the server node via the sensor network.

  As described above, when the event from the sensor node is collected by the server node, all the events are concentrated and notified to the server node. For this reason, the load on the server node increases, and the network bandwidth becomes tight as the network traffic increases.

  As an example of a technique for suppressing the load on the server node and the network traffic, the following technique has been proposed. An example is a system that improves system performance and / or resource consumption by transferring a filter agent that filters data from a consuming node to a data producing node. As another example, there is a sensor network system in which a script is nested and a part of the script is executed by an intermediate node or a lower node that is a lower node.

JP 2008-97603 A JP 2006-344017 A

  By the way, for example, there is a method of suppressing network traffic by distributing modules that aggregate events to lower nodes such as sensor nodes and relay nodes according to the event occurrence status of sensor nodes and the topology of the sensor network. It is done.

  However, in the above method, for example, when a module to be distributed is required to refer to data, in particular, to refer to a large amount of data, a large amount of data is deployed to each node, so the storage capacity is small. There is a problem that modules cannot be deployed to nodes. Further, when the reference data is updated or when the resource amount of the deployment destination node is insufficient, the reference data may be redeployed, and as a result, there is a problem that network traffic cannot be suppressed.

  The disclosed technology has been made in view of the above, and provides an event collection method, an event collection program, and an information processing apparatus capable of realizing unique processing in a node without deploying a large amount of data With the goal.

  An event collection method disclosed in the present application is an event collection method executed by a computer, and in one aspect, an input event from a sensor network in which a module that executes a process involving data reference is arranged in a node connected to the network. Receive. In addition, the event collection method specifies attribute information indicating an attribute in an input event, reference data extraction information for identifying a record referenced by the module according to the attribute information, and an attribute of data referenced by the module The reference location information corresponding to the module that executes the process related to the received input event and the reference location information are referred to by referring to the module definition storage unit that stores the reference location information to be associated with each other. Data is extracted from a master that stores data referenced by data reference. Further, the event collection method deploys the extracted data to the nodes.

  According to one aspect of the event collection method disclosed in the present application, there is an effect that unique processing can be realized in a node without deploying a large amount of data.

FIG. 1 is a diagram illustrating a system configuration of the sensor network system according to the first embodiment. FIG. 2 is a block diagram illustrating a functional configuration of the server node according to the first embodiment. FIG. 3 is a diagram illustrating a configuration example of information stored in the module storage unit. FIG. 4 is a diagram illustrating a configuration example of information stored in the module definition storage unit. FIG. 5 is a diagram for explaining information about reference data. FIG. 6 is a diagram for explaining Example 1 using reference data. FIG. 7 is a diagram for explaining Example 2 using reference data. FIG. 8 is a diagram for explaining identification of a deployment destination of partial reference data. FIG. 9 is a diagram for explaining information related to the deployment availability determination. FIG. 10 is a diagram for describing deployment availability determination according to reference data. FIG. 11 is a flowchart illustrating a procedure of master data monitoring setting processing. FIG. 12 is a diagram for explaining the data listed in step S104 of FIG. FIG. 13 is a flowchart showing a processing procedure when a master data change is detected. FIG. 14 is a diagram for explaining the process of counting the number of changes in step S202 of FIG. FIG. 15 is a diagram illustrating a configuration example of information stored in the topology storage unit. FIG. 16 is a diagram illustrating a configuration example of information stored in the event storage unit. FIG. 17 is a diagram illustrating a configuration example of information stored in the generated event information storage unit. FIG. 18 is a diagram illustrating a configuration example of information stored in the deployment destination information storage unit. FIG. 19 is a flowchart showing the procedure of module deployment processing. FIG. 20 is a flowchart illustrating a processing procedure for a deployed module. FIG. 21 is a flowchart illustrating a processing procedure for a deployed module. FIG. 22 is a diagram for explaining an operation example 1 of the deployment destination determination unit. FIG. 23 is a diagram for explaining an operation example 1 of the deployment destination determination unit. FIG. 24 is a diagram for explaining an operation example 1 of the deployment destination determination unit. FIG. 25 is a diagram for explaining an operation example 1 of the deployment destination determination unit. FIG. 26 is a diagram for explaining an operation example 1 of the deployment destination determination unit. FIG. 27 is a diagram for explaining an operation example 2 of the deployment destination determination unit. FIG. 28 is a diagram for explaining an operation example 2 of the deployment destination determination unit. FIG. 29 is a flowchart illustrating a procedure of deployment availability determination processing from partial reference data shortage detection. FIG. 30 is a block diagram illustrating a functional configuration of the sensor node according to the first embodiment. FIG. 31 is a flowchart illustrating a processing procedure in the sensor node according to the first embodiment. FIG. 32 is a diagram for describing an application example 1 of the disclosed technology. FIG. 33 is a diagram for describing an application example 2 of the disclosed technology. FIG. 34 is a diagram for describing an application example 3 of the disclosed technology. FIG. 35 is a diagram illustrating a system configuration of the sensor network system according to the second embodiment. FIG. 36 is a block diagram illustrating a functional configuration of a GW node according to the second embodiment. FIG. 37 is a diagram illustrating a computer that executes an event collection program.

  Hereinafter, embodiments of an event collection method, an event collection program, and an information processing device disclosed in the present application will be described in detail with reference to the drawings. Note that the present invention is not limited to the embodiments. Each embodiment can be appropriately combined within a range in which processing contents do not contradict each other.

[System configuration]
First, the system configuration of the sensor network system according to the present embodiment will be described. FIG. 1 is a diagram illustrating a system configuration of the sensor network system according to the first embodiment. The sensor network system 1 shown in FIG. 1 collects sensing data sensed by the sensor node 210 as an event, and provides various services according to the collected event.

  As shown in FIG. 1, the sensor network system 1 accommodates a server node 110 and a sensor node 210. The sensor node 210 and the server node 110 are communicably connected via the network 5. As an example of the network 5, there is a communication network such as the Internet, a LAN (Local Area Network), and a VPN (Virtual Private Network) regardless of wired or wireless. In the example of FIG. 1, the case where one sensor node 210 is accommodated is illustrated, but a plurality of sensor nodes may be accommodated, and can be applied when accommodating an arbitrary number of sensor nodes. .

  The sensor node 210 is a communication terminal with a sensor. Examples of the sensor node 210 include various devices such as personal computers and peripheral devices, AV (Audio Visual) devices, smart phones and mobile phones, portable terminals such as PHS (Personal Handyphone System), and home appliances. Examples of sensors mounted on the sensor node 210 include a power sensor that measures the amount of power, a temperature sensor that measures temperature, and a humidity sensor that measures humidity. Here, a power sensor or a temperature sensor is illustrated as an example of a sensor mounted on the sensor node 210, but an arbitrary sensor such as a GPS (Global Positioning System) sensor, an acceleration sensor, or a gyro sensor is used as the sensor node 210. Can be installed.

  The server node 110 is a server device that functions as a root node of the sensor network and provides various services according to events. For example, the server node 110 distributes the event by disposing a module that executes a processing process that processes the event received from the sensor node 210 in a node positioned lower than its own device. Such a module incorporates an event filtering process and an aggregation process that trigger a service providing process executed by the service providing application.

  In the example of FIG. 1, the sensor node 210 is illustrated as a lower node of the server node 110, but a GW (gateway) node 310 that relays communication between the sensor node 210 and the server node 110 is a lower node of the server node 110. Sometimes included as a node. Hereinafter, the sensor node 210 and the GW node 310 other than the server node 110 that is the root node may be collectively referred to as a “lower node”. Further, the sensor node 210, the GW node 310, and the server node 110 may be simply referred to as “nodes”.

[Server node configuration]
Next, a functional configuration of the server node according to the present embodiment will be described. FIG. 2 is a block diagram illustrating a functional configuration of the server node according to the first embodiment. The server node 110 has functions of various functional units included in a known server device, for example, various input devices and audio output devices, in addition to the functional units illustrated in FIG.

  As shown in FIG. 2, the server node 110 includes a module registration unit 111, a module storage unit 111A, a module definition storage unit 111B, a topology acquisition unit 112, and a topology storage unit 112A. Further, the server node 110 includes an event receiving unit 113, an event storage unit 114, a module execution unit 115, an occurrence event registration unit 116, and an occurrence event information storage unit 116A. Further, the server node 110 includes a reference data storage unit 162, a partial reference data request reception unit 120, a partial reference data extraction unit 119, a partial reference data transmission unit 163, a deployment destination determination unit 117, and a deployment destination information storage. 117A and a module transmission unit 118.

  The module registration unit 111 is a processing unit that registers a module. For example, the module registration unit 111 accepts an upload of a module programmed by a module developer to filter or aggregate events that trigger various service providing processes. The module registration unit 111 registers the module uploaded to the server node 110 in a module storage unit 111A described later. The module registration unit 111 accepts definitions relating to the uploaded modules via a terminal device used by the developer, and registers the definitions relating to the accepted modules in a module definition storage unit 111B described later.

  The module storage unit 111A is a storage unit that stores modules. For example, in the module storage unit 111A, when a module is uploaded, the module registration unit 111 registers the module. In addition, for example, the module storage unit 111A is referred to by a module transmission unit 118 described later when modules are deployed in lower nodes such as the sensor node 210 and the GW node 310. A configuration example of information stored in the module storage unit 111A will be described later with reference to FIG.

  The module definition storage unit 111B is a storage unit that stores definitions related to modules. For example, the module definition storage unit 111 </ b> B registers the module definition by the module registration unit 111 when a definition related to the module is uploaded together with the module. Further, for example, the module definition storage unit 111B is referred to by a later-described deployment destination determination unit 117 in order to determine a module deployment destination. A configuration example of information stored in the module definition storage unit 111B will be described later with reference to FIG.

  The topology acquisition unit 112 is a processing unit that acquires a connection form of the sensor network, that is, a so-called topology. For example, the topology acquisition unit 112 acquires connection information between nodes indicating to which upper node the lower node is connected from lower nodes including the sensor node 210 and the GW node 310 accommodated in the sensor network. The topology acquisition unit 112 acquires information related to the storage capacity of the lower node. Then, the topology acquisition unit 112 registers the connection information between the nodes acquired from the lower nodes and the information regarding the storage capacity in the later-described topology storage unit 112A. In the following, it is assumed that the lower node acquires connection information detected by automatically recognizing the upper node using the UPnP (Universal Plug and Play) protocol or the like, but the server node 110 is connected to the lower node. It is also possible to recognize the situation.

  The topology storage unit 112A is a storage unit that stores the topology of the sensor network. For example, in the topology storage unit 112A, when connection information between nodes is acquired from a lower node, the connection information between nodes is registered as a topology by the topology acquisition unit 112. For example, in the topology storage unit 112A, when information about storage capacity is acquired from a lower node, the information about storage capacity is registered as a use resource by the topology acquisition unit 112. Further, for example, the topology storage unit 112A is referred to by a later-described deployment destination determination unit 117 in order to determine a module deployment destination. A configuration example of information stored in the topology storage unit 112A will be described later with reference to FIG.

  The event receiving unit 113 is a processing unit that receives an event. For example, when the event receiving unit 113 receives an event from a lower node such as the sensor node 210 or the GW node 310, the event receiving unit 113 stores the event in the event storage unit 114 described later. At this time, the event receiving unit 113 also outputs the event received from the lower node to the generated event registration unit 116 described later. Note that the event reception unit 113 does not necessarily receive an unprocessed event sensed by the sensor node 210, and the processed event is executed by a processing process performed by a module arranged in a lower node. May be received.

  The event storage unit 114 is a storage unit that stores events. The event storage unit 114 is provided to refer to a service providing application that provides a service triggered by the occurrence of an event.

  For example, in the event storage unit 114, when an event is received from a lower node, the event reception unit 113 registers the event. Further, for example, in the event storage unit 114, when an event is processed by a module, an event after the process execution is registered by a module execution unit 115 described later. A configuration example of information stored in the event storage unit 114 will be described later with reference to FIG.

  The module execution unit 115 is a processing unit that performs execution control of modules deployed in the server node 110. For example, when an event is received by the event reception unit 113, the module execution unit 115 determines whether or not a module that uses the received event as an input event type is deployed in the server node 110. At this time, when the module is deployed in the server node 110, the module execution unit 115 executes event processing by executing the module. The module execution unit 115 stores the data processed by the module in the event storage unit 114 as a new event.

  The occurrence event registration unit 116 is a processing unit that registers an occurrence event that has occurred in a lower node such as the sensor node 210 or the GW node 310. For example, when an event is received by the event reception unit 113, the occurrence event registration unit 116 determines whether or not the received event has already been registered in a later-described occurrence event information storage unit 116A as an occurrence event. At this time, if the occurrence event registration unit 116 has not yet been registered as the occurrence event, the occurrence event registration unit 116 registers the event received from the lower node in the occurrence event information storage unit 116A described later.

  The occurrence event information storage unit 116A is a storage unit that stores information related to the occurrence event. The generated event information storage unit 116A is provided to manage what events are occurring in lower nodes such as the sensor node 210 or the GW node 310.

  For example, in the occurrence event information storage unit 116A, when an event is received from a lower node, the occurrence event registration unit 116 registers the occurrence event. In addition, for example, the generated event information storage unit 116A is referred to by a later-described deployment destination determining unit 117 in order to determine a module deployment destination. A configuration example of information stored in the generated event information storage unit 116A will be described later with reference to FIG.

  The reference data storage unit 162 is a storage unit that stores data referred to when the module processes an event. The reference data storage unit 162 stores data referred to by the modules stored in the module storage unit 111A. Note that the reference data storage unit 162 may be referred to as a “master”. Further, data stored in the reference data storage unit 162 may be referred to as “master data”.

  The partial reference data request receiving unit 120 is a processing unit that receives a partial reference data request. This partial reference data request includes information related to the event that has triggered the request and information related to the node that made the request. As one aspect, the partial reference data request includes an occurrence node ID where an event has occurred, an occurrence event type, a search key, a value of the search key, and a deployment destination node ID.

  For example, when the partial reference data request receiving unit 120 receives a partial reference data request from a lower node such as the sensor node 210 or the GW node 310, the partial reference data request receiving unit 120 outputs the request to the partial reference data extracting unit 119 described later.

  The partial reference data extraction unit 119 is a processing unit that extracts partial reference data corresponding to a module to be deployed in a lower node from the reference data stored in the reference data storage unit 162. For example, when a module is deployed, the partial reference data extraction unit 119 reads a search key, a reference location, and an extraction method corresponding to the module from the module definition storage unit 111B. The partial reference data extraction unit 119 extracts partial reference data corresponding to a search key, a reference location, and an extraction method from the reference data stored in the reference data storage unit 162, and the partial reference data transmission unit 163 described later. Output to.

  The partial reference data transmission unit 163 is a processing unit that transmits partial reference data to a lower node. For example, the partial reference data transmission unit 163 receives the partial reference data extracted by the partial reference data extraction unit 119 from the partial reference data extraction unit 119. The partial reference data transmission unit 163 transmits the received partial reference data to a lower node that deploys the module.

  The deployment destination information storage unit 117A is a storage unit that stores information regarding the deployment destination of the module. For example, the deployment destination information storage unit 117A is accessed by the deployment destination determination unit 117 described later when there is a change in the sensor network topology. A configuration example of information stored in the deployment destination information storage unit 117A will be described later with reference to FIG.

  The deployment destination determination unit 117 is a processing unit that determines a module deployment destination. For example, the deployment destination determination unit 117 determines the module deployment destination when the topology storage unit 112A is updated, that is, when the topology of the sensor network has changed. The process in which the deployment destination determination unit 117 determines the module deployment destination will be described later with reference to FIGS.

  The module transmission unit 118 is a processing unit that transmits a module to a lower node such as the sensor node 210 or a GW node 310 described later. For example, when the deployment destination determination unit 117 registers the deployment destination node ID in the deployment destination information storage unit 117A, the module transmission unit 118 transfers the module stored in the module storage unit 111A to the node corresponding to the deployment destination node ID. Send.

[Functional part of server node]
Next, the functional units shown in FIG. 2 that require further explanation will be described in detail with reference to the drawings.

  A configuration example of information stored in the module storage unit 111A will be described with reference to FIG. FIG. 3 is a diagram illustrating a configuration example of information stored in the module storage unit. As shown in FIG. 3, for example, the module storage unit 111A stores data in which a module identifier and a binary code are associated with each other. The “module identifier” here refers to an identifier for identifying a module. For example, a function name is given to a module programmed in C language, or a class name is given to a module programmed in Java (registered trademark) language, depending on the programming language used for development. An identifier can be assigned. The “binary code” refers to compiled binary data that is a module body.

  The example of FIG. 3 shows an example in which module IDs “average power calculation” and “home power total” are associated with their binary codes. Of these, “average power calculation” refers to the class name of the module that calculates the average power consumption for a given period, and “home power total” refers to the class name of the module that calculates the total power consumption for a given period. Point to. When these modules “average power calculation” and “home power total” are arranged in the lower node, events transmitted from the lower node to the server node 110 are aggregated.

  In the example of FIG. 3, the case where the binary code of the module is stored is illustrated, but it is not always necessary to store the module in the binary format, and data other than the binary format may be stored. For example, when the module is a script language, text data in which the script is described may be stored. Also, the source code before compilation may be stored. In this case, the module may be compiled at the stage where the module is deployed to a lower node such as the sensor node 210, or may be compiled at the deployment destination lower node.

  Next, a configuration example of information stored in the module definition storage unit 111B will be described with reference to FIG. FIG. 4 is a diagram illustrating a configuration example of information stored in the module definition storage unit. As illustrated in FIG. 4, for example, the module definition storage unit 111 </ b> B stores data in which information related to the process itself, information related to reference data, and information related to deployment availability determination are associated. In the following, each part of “information relating to processing itself”, “information relating to reference data”, and information relating to deployment availability determination will be described.

  First, “information regarding the processing itself” will be described. As shown in FIG. 4, the module identifier, the input event type, the output event type, and the aggregate attribute name are associated with the information regarding the process itself. Here, the “input event type” refers to an event type that becomes an input of processing executed by the module. The “output event type” refers to an event type that is an output of the process executed by the module. The “aggregated attribute name” refers to the name of an aggregate attribute that is a framework for aggregating a plurality of input events.

  The module identifier “average power calculation” shown in FIG. 4 receives an event of the input event type “power”, aggregates the input event based on the aggregation attribute name “outlet ID”, and sets it as an output event type “average power”. Represents processing that outputs processing results. 4 receives an event of the input event type “average power”, aggregates the input event based on the aggregate attribute name “user”, and outputs the event type “per person”. It represents a process of outputting a processing result as “power”. Note that the aggregate attribute name may not be specified depending on the content of processing.

  Next, “information related to reference data” will be described with reference to FIGS. FIG. 5 is a diagram for explaining information about reference data. As shown in FIG. 5, the reference data reference location, extraction method, and search key to be referred to when the module processes the event are recorded in the information related to the reference data. As one aspect, a reference location is specified by a table name or a column name, and an extraction method is specified as an extraction formula or the like when extracting a necessary record from reference data. Further, the attribute name in the input event type is designated as the search key. With this information, it is possible to link the record row in the master data and the attribute value in the input event type, and specify the record row and reference column, which are necessary for processing while referring to the reference data based on the contents of the input event. Do. Information on the reference data is designated by the application administrator and is used to subdivide the partial reference data to be deployed in the lower nodes. Further, when the module does not require reference data, the data related to the reference data may not be stored.

  As shown in FIG. 5, for example, a search key, a reference location, and an extraction method are associated with information related to reference data. The “search key” here refers to an attribute in the input event. The “reference location” refers to information for specifying a table and a column to be referred to. The “extraction method” refers to information that identifies a record to be referred to. The extraction method may refer to information for indirectly referring to data associated with reference data. With this information, partial reference data can be deployed in record units in accordance with the attribute value of the generated event. If the module does not accompany data reference, the information related to the reference data need not be stored. The search key is an example of “attribute information”. The reference location is an example of “reference location information”. The extraction method is an example of “reference data extraction information”.

  In FIG. 5, the reference method in which the reference data storage unit 162 is referred to by the process 5a of the module identifier “Proc1” will be described in three cases. Here, the three cases correspond to a case where the process 5a reads the data 5b as information on the reference data, a case where the data 5c is read, and a case where the data 5d is read. The case where the data 5b is read corresponds to the direct reference of the reference data corresponding to the event content, and the case where the data 5c is read and the case where the data 5d is read correspond to the indirect reference corresponding to the event content.

  As illustrated in FIG. 5, for example, when an input event “Event11” is input, the process 5 a is executed. When the process 5a is executed, the key corresponding to the search key is extracted from the data in the input event. Here, “key” indicates a unique value of the search key corresponding to the occurrence event. That is, when the process 5a is executed, the value “val1” corresponding to the attribute name “attr1” is extracted from the data in “Event11” as the key.

  Here, the data 5b is an example representing the direct reference of the reference data according to the event content. In the data 5b, reference locations “table AK, table AX” are stored. This indicates that the column K and the column X of the table A are referred to among the data stored in the reference data storage unit 162. The data 5b stores an extraction method “where key = table AK”. This indicates that among the data stored in the reference data storage unit 162, a record including a key in the column K of the table A is referred to. That is, when the process 5a is executed, in the case where the data 5b is read, the records “val1, val22” including “val1” in the column K are referred to among the columns K and X of the table A.

  Data 5c is an example of extracting reference data by following indirect reference according to the event content. In the data 5c, reference locations “table AK, table BX” are stored. This indicates that, among the data stored in the reference data storage unit 162, the column K of the table A and the column X of the table B are referred to. Further, the extraction method “where key = table AK &&, table AL = table B.K2” is stored in the data 5c. This is because the record stored in the reference data storage unit 162 refers to the record that includes the key in the column K of the table A and the record that includes the value of the column L of the table A in the column K2 of the table B. Indicates. That is, when the process 5a is executed, in the case where the data 5c is read, the value “val21” of the column L including “val1” in the column K of the table A is extracted, and further, “val21” is extracted in the column K2 of the table B. The value “val31” of the column X including “is referred to.

  Further, the data 5d shows another example of indirect reference according to the event content. In this example, the reference data value is extracted based on the value obtained by applying the calculation formula to the value extracted from the event content. In the data 5d, reference locations “table AK, table AX” are stored. This indicates that the column K and the column X of the table A are referred to among the data stored in the reference data storage unit 162. In addition, the extraction method “where f (key) = table AK” is stored in the data 5c. This indicates that, among the data stored in the reference data storage unit 162, the column K of the table A is referred to using a value obtained by applying the calculation formula f to the key. That is, when the process 5a is executed, in the case where the data 5d is read, the record “f (val1), val41” including “f (val1)” in the column K out of the column K and the column X of the table A is stored. Referenced. A calculation formula used for format conversion, granularity change, or the like is applied to the calculation formula f. In addition, the indirect reference in FIG. 5c shows a method of dealing with a two-stage reference to an indirect reference, but even if it is an indirect reference of three or more stages, the column of interest at the time of Join is similarly listed in the extraction method. It can respond. Furthermore, 5b to 5d indicate that the case where the extraction method of the reference data is different can be dealt with, and it is easily understood that extraction methods other than the examples shown here can be dealt with.

  Example 1 using reference data will be described with reference to FIG. FIG. 6 is a diagram for explaining Example 1 using reference data. The table A referred to here is associated with an outlet ID, a user, and a device.

  As shown in FIG. 6, for example, when a power event is input, the average power calculation 6a is executed. When the average power calculation 6a is executed, the key “11” corresponding to the search key “outlet ID” is extracted from the data in the input event. In the module definition storage unit 111B of FIG. 6, reference locations “table AK, table AX” are stored. This indicates that the column K and the column X of the table A are referred to the outlet ID of the power event. The module definition storage unit 111B stores an extraction method “where key = table AK”. This indicates that a record including the attribute value (outlet ID value) in the power event in the column K of the table A is referred to. That is, when the average power calculation 6a is executed, the record “11, Mr. A” including “11” in the column K among the columns K and X of the table A is referred to. In the case of FIG. 6, the partial reference data storage unit 216 stores data 6b including the record “11, Mr. A” including “11” in the column K among the columns K and X of the table A. Is done.

  Example 2 (case 5c, case of data 5c) using reference data will be described with reference to FIG. FIG. 7 is a diagram for explaining Example 2 using reference data. This example shows an example of extracting only data necessary for processing from master data managed and stored in a plurality of tables. The table A referred to here is associated with the outlet ID and the connected device, and the table B is associated with the device and the user.

  As shown in FIG. 7, for example, when a power event is input, an average power calculation 7a is executed. When the average power calculation 7a is executed, the key “11” corresponding to the search key “outlet ID” is extracted from the data in the input event. The module definition storage unit 111B of FIG. 7 stores reference locations “table AK, table BX”. This indicates that the column K of the table A and the column X of the table B are referred to the outlet ID of the power event. The module definition storage unit 111B stores the extraction method “where key = table AK &&, table AL = table B.K2”. This is because, among the data stored in the reference data storage unit 162, a record including a key in the column K of the table A and a record including a value equivalent to the column L of the corresponding record in the column K2 of the table B are referred to. Indicates that That is, when the average power calculation 7a is executed, the value “shared PC1” of the column L including “11” in the column K of the table A is extracted, and the column including “shared PC1” in the column K2 of the table B is extracted. The value “Mr. A” of X is referenced. In the case of FIG. 7, in the partial reference data storage unit 216, the data including the record “11, Mr. A” including “11” in the column K out of the column K of the table A and the column X of the table B. 7b is stored.

  With reference to FIG. 8, identification of the deployment destination of partial reference data will be described. FIG. 8 is a diagram for explaining identification of a deployment destination of partial reference data. The process illustrated in FIG. 8 is performed by, for example, the deployment destination determination unit 117 when the master data stored in the reference data storage unit 162 is changed.

  As illustrated in FIG. 8, for example, when the data “Mr. A” in the column X of the table A stored in the reference data storage unit 162 is changed, the deployment destination determination unit 117 indicates that the data has been changed. And the value “11” of the column K is acquired (s11). Then, the deployment destination determination unit 117 refers to the extraction method stored in the module definition storage unit 111B, and the value “11” in the column K of the table A is “outlet” of the power event as illustrated in FIG. It is determined that it corresponds to “ID”. Then, the deployment destination determining unit 117 refers to the generated event information storage unit 116A (s12), and specifies the generated node ID “power sensor 1” corresponding to the generated event “power” and the outlet ID “11” of the generated event attribute. (S13). Then, the deployment destination determination unit 117 refers to the deployment destination information storage unit 117A (s14), and deploys corresponding to the generation node ID “power sensor 1”, the input event type “11”, and the module identifier “average power calculation”. The node ID “GW1” is specified (s15). Here, the module identifier is acquired from the module definition storage unit 111B. As described above, the deployment destination determination unit 117 identifies the deployment node ID where the partial reference data is deployed in accordance with the change of the table in the reference data storage unit 162.

  Next, “information relating to deployment availability determination” will be described with reference to FIG. FIG. 9 is a diagram for explaining information related to the deployment availability determination. As illustrated in FIG. 9, for example, one or both of a reference data characteristic constraint and a resource viewpoint constraint is stored in the information regarding the availability determination. The reference data characteristic constraint is specified in order to suppress an increase in communication volume due to an increase in redeployment of reference data when the frequency of changing the master of partial reference data to be deployed is high. For example, the reference data characteristic constraint stores a value that designates the deployment frequency upper limit of partial reference data by the number of times per hour. As shown in FIG. 9, when the master data 9a of the reference data is changed, partial reference data needs to be deployed in accordance with the change. Therefore, if the total frequency of changes exceeds the upper limit, deployment is impossible. is there. Further, the resource viewpoint constraint is specified in order to suppress deployment that requires a large amount of partial reference data and exceeds the resource amount of the deployment destination node. For example, the resource viewpoint constraint stores a value that specifies the upper limit of the occupied resource amount of the partial reference data to be deployed by an absolute amount or a ratio. As shown in FIG. 9, for example, it is intended to suppress deployment that exceeds the resource amount of the deployment destination node by increasing the partial reference data due to the variation of the occurrence event. When the resource viewpoint constraint is specified as a ratio, the parameter is the resource amount of the deployment destination node. Note that when both the reference data characteristic constraint and the resource viewpoint constraint are stored, the information related to the deployment availability determination is determined by the AND condition. Further, the information related to the determination of whether or not deployment is possible is specified by, for example, an administrator who manages the system, and is used to reduce the cost for redeployment. Further, when the module does not require reference data, the data may not be stored in the information related to the deployment availability determination. Further, the reference data characteristic constraint is an example of “first condition”, and the resource viewpoint constraint is an example of “second condition”.

  With reference to FIG. 10, the deployment propriety determination according to the reference data will be described. FIG. 10 is a diagram for describing deployment availability determination according to reference data. The processing illustrated in FIG. 10 is performed by the deployment destination determination unit 117 when, for example, partial reference data is deployed.

  As shown in FIG. 10, for example, the deployment destination determination unit 117 detects the change of the table A or the table B in the master (s21), for the column on the reference data side associated with the search key of the occurrence event. To summarize the change frequency. Here, the deployment destination determination unit 117 aggregates the change frequency in units of records by referring to the extraction method of the module definition storage unit 111B (s22). Here, when the deployment destination is determined by the deployment destination determination unit 117, whether or not partial reference data can be deployed is determined based on the reference data characteristic constraint and the resource viewpoint constraint, and deployed when the respective constraint conditions are satisfied. (S23). Here, the number of records to be deployed, that is, the amount of resources varies according to the search key value of the occurrence event, and the redeployment burden varies depending on the total change frequency of the deployed records. In the partial reference data deployed to the candidate node 10a by the deployment destination determination unit 117, the necessary column of the referenced table is deployed for each record. The aggregation from s21 to s22 is a process according to reference data update, which is executed independently of the deployment destination determination process, and other function units such as a reference data storage unit may act for it.

  The flow of master data monitoring setting processing will be described with reference to FIG. FIG. 11 is a flowchart illustrating a procedure of master data monitoring setting processing. This monitoring setting process is, for example, a process of setting a location in the reference data monitored by the deployment destination determining unit 117 in order to detect a change in master data. This monitoring setting process is repeatedly executed as long as the server node 110 is powered on.

  As shown in FIG. 11, the deployment destination determination unit 117 waits for the module definition information to be registered (step S101). When the module definition information is registered in the module definition storage unit 111B, the deployment destination determination unit 117 determines whether the registered module is a process involving data reference and requires deployment determination based on reference data characteristic restrictions. (Step S102).

  When it is determined that it is necessary to determine whether deployment is possible due to the reference data characteristic constraint (Yes at Step S103), the deployment destination determination unit 117 executes the process of Step S104. In other words, the deployment destination determination unit 117 lists the locations in the reference data determined to be the corresponding record change for the column on the reference data side corresponding to the search key of the input event of the module based on the reference location and the extraction method. Up (step S104). Based on the corresponding result, the deployment destination determination unit 117 sets a change in master data that can be deployed as partial reference data on standby (step S105), and returns to the process of step S101. Note that the deployment destination determination unit 117 returns to the process of step S101 if it is not determined that the deployment availability determination from the viewpoint of reference data is required (No at step S103).

  Here, the data listed in step S104 of FIG. 11 will be described with reference to FIG. FIG. 12 is a diagram for explaining the data listed in step S104 of FIG.

  As illustrated in FIG. 12, for example, the deployment destination determination unit 117 lists data in the list 12a. For example, when the module definition information is registered in the module definition storage unit 111B, the deployment destination determination unit 117 registers “module identifier”, “input event”, “search key”, and “reference side column corresponding to the search key”. Is extracted from the module definition storage unit 111B. Here, the deployment destination determination unit 117 extracts the “reference side column associated with the search key” from the where phrase in the extraction method of the module definition storage unit 111B (s31). Then, the deployment destination determining unit 117 stores the extracted data in the list 12a. Further, the “location in the reference data determined to be a change in the corresponding record” in the list 12a is stored by the deployment destination determination unit 117 based on the reference location and the extraction method in the module definition storage unit 111B. That is, the deployment destination determination unit 117 extracts and stores what is regarded as a change in the corresponding record from the reference location of the module and the column that appears in the extraction method. Of the locations in the reference data that are determined to be changes in the corresponding record stored here, the data on the first row corresponds to the reference locations on the module definition storage unit 111B, and the data on the second and third rows are , Corresponding to the column of interest at the time of Join. For example, the list 12a is a module for monitoring change of master data indicating correspondence between an outlet ID (such as “11”), a connected device (such as “shared PC1”), and a user of the device (such as “Mr. A”). This indicates that it is performed in association with the identifier “average power calculation” (input event type “power”, search key “outlet ID”). According to this list 12a, for example, it can be counted as the number of record changes corresponding to the change in the column of the table set as the monitoring target, and the power event 12b with the outlet ID “11” is received. In this case, it is possible to determine whether or not to deploy based on the change frequency of the corresponding record.

  The flow of processing when master data change is detected will be described with reference to FIG. FIG. 13 is a flowchart showing a processing procedure when a master data change is detected. The process at the time of detecting the master data change is repeatedly executed as long as the power of the server node 110 is ON.

  As shown in FIG. 13, the deployment destination determination unit 117 waits for a change in master data that can be deployed as partial reference data (step S201). When the change of the master data is detected, the deployment destination determination unit 117 uses the list generated by the monitoring setting process to count the number of changes according to the search key value (step S202).

  Subsequently, the deployment destination determination unit 117 determines whether or not the module that refers to the changed data has been deployed (step S203). For example, the generated event information storage unit 116A identifies the generated event in which the output event type and the generated event type match and the search key attribute name and value match. Then, based on the occurrence node ID, the aggregate attribute value, and the occurrence event type of the identified occurrence event, the deployed module related to the event is identified from the deployment destination information.

  When the module that refers to the changed data has been deployed (Yes at Step S203), the deployment destination determination unit 117 determines whether or not the deployment destination node of the module is a node other than the cloud (Step S203). S204). If the node is a node other than the cloud (Yes at Step S204), the deployment destination determination unit 117 determines whether or not partial reference data can be deployed to the deployment destination node (Step S205). Specifically, based on the information regarding the deployment availability determination in the module definition information, the reference data characteristics are determined based on constraints and resource viewpoint constraints. When partial reference data can be deployed (Yes at Step S205), the deployment destination determination unit 117 stores “OK” in the determination result (Step S206), and transmits the partial reference data to the deployment destination node (Step S206). Step S207). Then, the deployment destination determination unit 117 returns to the process of step S201.

  On the other hand, when the partial reference data cannot be deployed (No at Step S205), the deployment destination determination unit 117 starts the process of Step S422 in FIG. 21 described later and returns to the process of Step S201 (Step S208). . When the module has not been deployed (No at Step S203), the deployment destination determination unit 117 returns to the process at Step S201. If the module deployment destination node is a cloud (No at step S204), the deployment destination determination unit 117 returns to the process of step S201.

  The process of counting the number of changes in step S202 of FIG. 13 will be described using FIG. FIG. 14 is a diagram for explaining the process of counting the number of changes in step S202 of FIG. FIG. 14 illustrates a table 14a for determining deployment availability. The table 14a is generated by the deployment destination determination unit 117, for example. For example, in the table 14a, the number of changes according to the value of the search key is aggregated in association with the module that refers to the changed data. In addition, the number of changes is totaled while sliding the specified period specified by the reference data characteristic constraint of the information related to the determination of whether deployment is possible. As one aspect, the deployment destination determination unit 117 monitors the change of the master data from a time t0 when the module definition is registered until a time t1 when a specified period, for example, 1 hour elapses. When the time t1 elapses, the deployment destination determination unit 117 counts the number of changes in the period from the detection time ti to the time tj that goes back the specified period every time a change in the master data is detected. The time tj is stored in the measurement section start time of the table 14a. Here, the case where the designated period is one hour has been exemplified, but the present invention is not limited to this, and an arbitrary time may be designated.

  A configuration example of information stored in the topology storage unit 112A will be described with reference to FIG. FIG. 15 is a diagram illustrating a configuration example of information stored in the topology storage unit. As illustrated in FIG. 15, for example, the topology storage unit 112A stores data in which a lower node ID, an upper node ID, and a used resource are associated with each other. The “lower node ID” here refers to an identifier for identifying a lower node. The “upper node ID” indicates an identifier for identifying an upper node connected to the lower node. “Used resources” refers to the capacity and ratio of used resources in lower nodes. The ratio referred to here indicates, for example, the ratio of the usage amount to the total memory in the lower nodes.

  In the example of FIG. 15, the upper node of the sensor 1 is GW1, and the upper node of GW1 is a cloud. For example, the sensor 1 corresponds to the sensor node 210, and the cloud corresponds to the server node 110. Further, here, the case where the GW 1 is interposed as a relay node between the sensor 1 and the cloud is shown, but the relay node may not necessarily be interposed. For example, as shown in FIG. The upper node may be a cloud. Further, in the example of FIG. 15, the sensor 1 uses 1 MB resources, and the ratio to the total memory is 80%.

  A configuration example of information stored in the event storage unit 114 will be described with reference to FIG. FIG. 16 is a diagram illustrating a configuration example of information stored in the event storage unit. As shown in FIG. 16, for example, the event storage unit 114 stores data in which an event type name, an event occurrence time, and an event attribute are associated. The “event type” here refers to an identifier for identifying the type of event. “Event occurrence time” refers to the time when an event occurs, that is, the time sensed by the sensor node 210. “Event attribute” indicates the nature and origin of the event. For example, the “event attribute” is attribute data such as sensing data collected as an event or the type of data processed by the event, an occurrence node where the event has occurred, and an aggregation attribute that aggregates multiple nodes including the occurrence node. Refers to a set. In the following description, it is assumed that each attribute data included in the event attribute includes an attribute name / attribute value pair.

  The first record shown in FIG. 16 shows an event that power is measured by the X house power sensor X at 12:00 on July 13, 2011.

  As described above, the event stored in the event storage unit 114 is referred to as a trigger for executing the service providing process by the service providing application. In the example of FIG. 16, an unprocessed event sensed by the sensor node 210 is illustrated, but when a module is deployed in a lower node, a new event processed by the module is also stored. It will be.

  A configuration example of information stored in the generated event information storage unit 116A will be described with reference to FIG. FIG. 17 is a diagram illustrating a configuration example of information stored in the generated event information storage unit 116A. As shown in FIG. 17, for example, the generated event information storage unit 116A stores data in which a generated node ID, a generated event type, and a generated event attribute are associated with each other. The “occurrence node ID” here refers to an identifier for identifying the occurrence node. The “occurrence event type” indicates an identifier for identifying the type of the occurrence event. The “occurrence event attribute” indicates an event attribute of the occurrence node.

  The first record shown in FIG. 17 indicates that an event occurs in which power is measured by the power sensor X of the X house. In the example of FIG. 17, an unprocessed event sensed by the sensor node 210 is illustrated as an occurrence event. However, when a module is deployed in a lower node, a new event processed by the module is also included. Stored as an event that occurred.

  A configuration example of information stored in the deployment destination information storage unit 117A will be described with reference to FIG. FIG. 18 is a diagram illustrating a configuration example of information stored in the deployment destination information storage unit. As illustrated in FIG. 18, for example, the deployment destination information storage unit 117A is associated with a module identifier, an input event type, an aggregate attribute name, a generated event attribute, a generated node ID, a deployed node ID, and deployment availability determination information. Remember the data. The “deployment destination node ID” here refers to an identifier for identifying the sensor node 210, the GW node 310, or the server node 110 on which the module is deployed. Further, the “deployment availability determination information” is associated with a planned deployment destination node ID, a determination state, and a time. Among these, “planned deployment destination node ID” is an identifier for identifying a node selected as a node on which a module is deployed, or an identifier for identifying a node that is determined to be undeployable by the deployment destination determination unit 117. Point to. The “determination state” refers to a state of determination as to whether or not a module can be deployed to a node specified by the planned deployment destination node ID. For example, in the determination state, when the determination is being made, the fact is stored, and when the determination is not being performed, the determination result is stored. “Time” refers to the determination time. For example, in the time, when the determination is being performed, the next determination time is stored, and when the determination is not being performed, the latest determination time is stored.

  The module deployment process in the deployment destination determination unit 117 will be described with reference to FIGS. FIG. 19 is a flowchart showing the procedure of module deployment processing. This module deployment process is activated when, for example, the topology of the sensor network changes.

  As illustrated in FIG. 19, the deployment destination determination unit 117 waits for the occurrence event information storage unit 116A to be updated (step S301). Then, when the occurrence event information storage unit 116A is updated, it is determined whether or not there is a deployed module (step S302). When there is no deployed module (No at Step S302), the deployment destination determination unit 117 proceeds to the process after Step S303 as the process for the undeployed module. On the other hand, when there is a deployed module (Yes at Step S302), the deployment destination determination unit 117 executes processing for the deployed module (Step S316). In addition, the process with respect to the deployed module is later mentioned using FIG.20 and FIG.21.

  Subsequently, the deployment destination determination unit 117 stores the column data of the module identifier, the input event type, and the aggregate attribute name among the module definitions stored in the module definition storage unit 111B in the corresponding column of the deployment destination information storage unit 117A. (Step S303).

  Then, the deployment destination determination unit 117 executes the process of step S304 described below after executing the process of step S303. That is, the deployment destination determining unit 117 extracts the generated node ID included in the input event type of the module in which the generated event type is not deployed from the generated node IDs stored in the generated event information storage unit 116A. Further, the server node 110 extracts nodes having the same attribute value belonging to the same aggregate attribute as the attribute name of the aggregate attribute defined in the undeployed module between the generated node IDs extracted as described above.

  Thereafter, the deployment destination determination unit 117 writes the generated node ID obtained as an extraction result and the generated event attribute associated with the generated node ID in the deployment destination information storage unit 117A (step S305).

  At this time, if the number of generated node IDs is “0” (Yes in step S306), there is a possibility that the generated event notified from the lower node is not completely registered in the generated event information storage unit 116A. In this case, the deployment destination determination unit 117 proceeds to the process of step S302.

  On the other hand, when the number of generated node IDs is not “0” (No at Step S306), the deployment destination determining unit 117 determines whether there are a plurality of generated node IDs (Step S307). If the number of generated node IDs is plural (Yes at Step S307), the process of Step S308 described below is executed. That is, the deployment destination determination unit 117 accommodates all the sensor nodes 210 or GW nodes 310 corresponding to the respective generation node IDs among the upper node IDs stored in the topology storage unit 112A as lower nodes, and on the lowest node side. A certain node ID is extracted.

  If the number of generated node IDs is one (No in step S307), the deployment destination determination unit 117 has no room for selection in the node that deploys the module. The node ID is a node ID, and the process proceeds to step S309.

  Subsequently, the deployment destination determination unit 117 determines whether or not the deployed module is accompanied by data reference (step S309). When data reference is accompanied (Yes at Step S309), the deployment destination determination unit 117 stores the candidate node ID in the planned deployment destination node ID of the deployment destination information storage unit 117A (Step S310).

  Then, the deployment destination determination unit 117 changes the node ID that is the search result of S308 to cloud (step S311), and records the determination start (step S312). That is, the deployment destination determination unit 117 stores “determining” in the determination state of the deployment destination information storage unit 117A, and stores the time obtained by adding the specified period in the information regarding the deployment availability determination to the deployment time. To do. If no data reference is involved (No at Step S309), the deployment destination determination unit 117 proceeds to the process at Step S313.

  Subsequently, the deployment destination determination unit 117 stores the node ID in the column of the deployment destination node ID (step S313). Then, the deployment destination determination unit 117 transmits the module stored in the module storage unit 111A to the node corresponding to the deployment destination node ID (step S314). Then, the deployment destination determination unit 117 waits for the occurrence event information storage unit 116A to be updated (step S315), and returns to the process of step S302.

  The process for the deployed module shown in step S316 of FIG. 19 will be described with reference to FIGS. 20 and 21 are flowcharts showing the processing procedure for the deployed module.

  As illustrated in FIG. 20, the deployment destination determination unit 117 identifies a corresponding deployed record from the occurrence event, that is, a record in the deployment destination information storage unit 117A (step S401). For example, the occurrence event type of the corresponding occurrence event matches the input event type of the deployed record, and the aggregate attribute name and occurrence event attribute of the record are the same as the corresponding attribute value of the corresponding attribute of the occurrence event Extract.

  If there is a corresponding deployed record (Yes at step S402), the deployment destination determination unit 117 determines whether the generated node ID of the corresponding deployed record includes the generated node ID of the generated event (step S403).

  When the occurrence event ID of the occurrence event is included (Yes at Step S403), the deployment destination determination unit 117 determines whether or not the deployment destination node ID of the corresponding deployed record is a cloud (Step S404).

  If it is a cloud (Yes at Step S404), the deployment destination determination unit 117 determines whether the determination state is “determining” and the determination end time has elapsed (Step S405).

  When the determination state is “determining” and the determination end time has elapsed (Yes at step S405), the deployment destination determination unit 117 designates the deployment planned node as the redeployment destination node ID (step S405). S406). Then, the deployment destination determination unit 117 determines whether to deploy the reference data characteristic constraint (Step S407).

  If the determination result indicates that the deployment is possible (Yes at Step S408), the deployment destination determination unit 117 proceeds to the process of Step S412 in FIG. On the other hand, when the determination result indicates that the deployment is impossible (No at Step S408), the deployment destination determination unit 117 stores “NG” in the determination state (Step S409), and proceeds to the process of Step S303 in FIG.

  If the occurrence event ID of the occurrence event is not included (No at Step S403), the deployment destination determination unit 117 stores the occurrence node ID of the occurrence event in the corresponding deployed record (Step S410). Then, the deployment destination determination unit 117 identifies the redeployment node ID (step S411). At this time, the deployment destination determination unit 117 searches the topology storage unit 112A for the node IDs where the generated node IDs are aggregated, and identifies the redeployment destination node ID as in the process of step S308 in FIG. Further, the deployment destination determination unit 117 proceeds to the process of step S412 in FIG.

  If there is no corresponding deployed record (No at Step S402), the deployment destination determining unit 117 proceeds to the process at Step S303 in FIG. If it is not a cloud (No at Step S404), the deployment destination determination unit 117 proceeds to the process at Step S303 in FIG. If the determination state is not “determining” or the determination end time has not elapsed (No at step S405), the deployment destination determination unit 117 proceeds to the process of step S303 in FIG.

  Next, FIG. 21 is a flow for explaining the operation of executing redeployment after determining whether or not deployment is possible after specifying the redeployment destination node IID. As illustrated in FIG. 21, the deployment destination determination unit 117 determines whether the module of the corresponding record is accompanied by data reference (step S412). When the module does not accompany data reference (No at Step S412), the deployment destination determination unit 117 stores the corresponding redeployment node ID in the deployment node ID (Step S413). Subsequently, the deployment destination determination unit 117 transmits the module stored in the module storage unit 111A to the node corresponding to the deployment destination node ID (step S414).

  Subsequently, the deployment destination determination unit 117 collects the corresponding module from the deployment destination node where the corresponding module has been deployed by that time (step S415). Then, the deployment destination determination unit 117 deletes the data related to the collected module output event (step S416).

  Here, the process of deleting data related to the module output event collected by the deployment destination determination unit 117 will be described in detail. For example, the deployment destination determination unit 117 refers to the generated event information storage unit 116A, identifies the event output by the collected module stored in the deployment destination information storage unit 117A, and deletes the event. This identification is performed based on whether the deployment destination node ID, the generated event type, and the generated event attribute of the collected module of the collected module match the generated node, the generated event type, and the generated event attribute of the generated event information. That is, the deployment destination determination unit 117 deletes the matching items here. Furthermore, the deployment destination determination unit 117 specifies a deployed module that uses the generated event deleted by the above-described deletion process as an input event for the column of the generated node ID in the deployment destination information storage unit 117A. This module is specified by checking whether the output event type and the generated event attribute of the generated event output by the process of the collected module specified in the above-described deletion process match the input event type and the generated event attribute of the deployment destination information. Determine and identify matches. Then, the deployment destination determination unit 117 deletes a column that matches the generation node of the generated event from the column of the generation node ID of the corresponding module. As described above, when the data is deleted in step S416, the deployment destination determination unit 117 returns to the process of step S301 in FIG.

  On the other hand, when the module is accompanied by data reference (Yes at step S412), the deployment destination determination unit 117 determines the resource viewpoint constraint of the redeployment destination node (step S417). If deployment is possible (Yes at step S418), “OK” is stored in the determination state (step S419). At this time, the time column of the deployment availability determination information in the deployment destination information storage unit is updated with the current time. Furthermore, the deployment destination determination unit 117 stores the corresponding redeployment node ID in the deployment node ID (Step S420). At this time, the deployment destination determination unit 117 causes the partial reference data extraction unit 119 to extract partial reference data, for example. For example, the partial reference data extraction unit 119 reads a search key, a reference location, and an extraction method corresponding to the deployed module from the module definition storage unit 111B. The partial reference data extraction unit 119 extracts partial reference data corresponding to the search key, the reference location, and the extraction method from the reference data stored in the reference data storage unit 162. Then, the deployment destination determination unit 117 transmits the partial reference data to the node corresponding to the deployment destination node ID (step S421), and the process proceeds to step S414.

  On the other hand, when the deployment is impossible (No at Step S418), “NG” is stored in the determination state (Step S422), and the current deployment destination node ID is stored in the planned deployment node ID (Step S423). Then, the deployment destination determination unit 117 stores the cloud in the deployment destination node ID (step S424), and proceeds to the process of step S414.

  Operation example 1 of the deployment destination determination unit 117 will be described with reference to FIGS. 22 to 26. 22 to 26 are diagrams for explaining an operation example 1 of the deployment destination determination unit. FIG. 22 shows an initial state of each table according to this operation example. That is, the table 22a corresponds to the reference data stored in the reference data storage unit 162. The table 22b corresponds to information stored in the module definition storage unit 111B. The table 22c corresponds to the list generated in step S104 in FIG. The table 22d corresponds to the table for determining whether or not to deploy, which is tabulated in step S202 in FIG. The table 22e corresponds to information stored in the topology storage unit 112A. The table 22f corresponds to information stored in the generated event information storage unit 116A.

  In the example of FIG. 22, as shown in the table 22f, the deployment destination determination unit 117 starts the deployment process when the “power” event corresponding to the outlet ID “11” is detected by “sensor 1”. To do. Here, if the module “average power calculation” having “power” as an input event is not yet deployed, the deployment destination determination unit 117 performs the following process. That is, the deployment destination determination unit 117 refers to the module definition storage unit 111B, and stores the module identifier “average power calculation”, the input event type “power”, and the aggregate attribute name “outlet ID” in the table 23a of FIG. Step S303). The table 23a corresponds to information stored in the deployment destination information storage unit 117A.

  Subsequently, the deployment destination determination unit 117 extracts, from the table 22f, the generation node whose generation event type is “power” and aggregated by the outlet ID “11”, that is, “sensor 1” (step S304). . Then, the generated node ID “sensor 1” obtained as a search result and the generated event attribute “outlet ID = 11” associated with the generated node ID are stored in the table 23a (step S305).

  At this time, since the number of occurrence nodes is “1”, the deployment destination determination unit 117 refers to the table 22b and determines that “average power calculation” involves data reference. Therefore, the deployment destination determination unit 117 stores “sensor 1” in the planned deployment destination node ID of the table 23a and changes the node ID to “cloud” (step S311). In addition, the deployment destination determination unit 117 stores “determining” in the determination state of the table 23 a and stores “2011.1.129 13:10:00” as the time (step S <b> 312). Thereafter, since the module “average power calculation” is deployed in the cloud by the processing of step S313 and step 314, the fact that the “average power” event occurs from “cloud” is added to the table 22f, and FIG. It becomes a table 23b.

  Subsequently, the deployment destination determination unit 117 starts processing for the “average power” newly added to the generated event information storage unit with the deployment of “average power calculation”. The deployment destination determination unit 117 determines that there is a deployed module (Yes at Step S302), proceeds to the process of Step S316, identifies the deployed module, but does not correspond (No at Step S402), and returns to Step S303. Thereafter, as described above, a module “Per-person calculation” corresponding to the input event type “average power” is deployed. In other words, the deployment destination determination unit 117 refers to the table 22b, adds “Per person calculation” to the table 23a, and sets it as the table 23c. In addition, since the “person-unit calculation” does not have information regarding reference data, that is, is a module that does not accompany data reference, the deployment destination determination unit 117 determines that the corresponding module can be deployed, and the determination state of the table 23c “OK” is stored in “”, and “Cloud” is stored in the deployment destination node ID. As a result, the module “Per-person calculation” is deployed in the cloud, so that a “Per-person power” event occurs from “Cloud” is added to the table 23b, and becomes the table 23d.

  Thereafter, when a new “power” event is detected, the deployment destination determination unit 117 identifies the record in the first row of the table 23c. Here, the occurrence node ID of this record includes “sensor 1” that generates a power event, the deployment destination node ID is “cloud”, and the determination state is “determining”. When the determination end time elapses (step S405), the deployment destination determination unit 117 designates the planned deployment node “sensor 1” as the redeployment destination node ID of this record (step S406), and whether or not the data characteristic constraint can be deployed. A determination is made (step S407). As shown in the table 22d, since the master change count related to the “average power calculation” of the outlet ID “11” is “1”, the upper limit value of the change count is set to “2” or more. The deployment destination determination unit 117 determines that “average power calculation” is deployable (Yes in step S408).

  Subsequently, referring to the table 22b, since the “average power calculation” is a module with data reference, the deployment destination determination unit 117 determines whether or not to deploy based on resource viewpoint constraints of the deployment destination node (step S417). The deployment destination determining unit 117 refers to the table 22e, and adds the amount of data to be deployed to the currently used resource amount to determine whether or not deployment is possible. Here, when it is determined that deployment is possible (Yes in step S418), the deployment destination determination unit 117 stores the redeployment node ID “sensor 1” in the deployment node ID of “average power calculation” in the table 23c ( In step S420), “OK” is stored in the determination state, the time is updated, and the table 24a is updated.

  Subsequently, the deployment destination determination unit 117 causes the partial reference data extraction unit 119 to extract partial reference data, for example. At this time, the partial reference data extraction unit 119 reads the search key, reference location, and extraction method corresponding to the deployed module from the module definition storage unit 111B. The partial reference data extraction unit 119 extracts partial reference data corresponding to the search key, the reference location, and the extraction method from the reference data stored in the reference data storage unit 162. Here, partial reference data {11, Mr. A} is extracted. Then, the deployment destination determination unit 117 transmits the extracted partial reference data {11, Mr. A} and the module to the deployment destination node ID (Steps S421 and S414), and the partial reference data from the nodes deployed so far. Then, the module is collected (step S415). Then, the deployment destination determination unit 117 deletes the data 24e in the table 24d and updates it to the table 24f, and deletes the data 24b in the table 24a and updates it to the table 24c (step S416). That is, the table 24c and the table 24f correspond to the state after the redeployment of the “average power calculation”. From the above operation, it is easily understood that when deploying a process involving data reference, it is possible to extract and deploy only necessary data according to the module definition information.

  Next, when a new “average power” event occurs from the sensor 1 due to the redeployment of the above “average power calculation” to the sensor 1, the deployment destination determination unit 117, as shown in the table 25a of FIG. Detects an event that occurs from the redeployment destination. Here, the deployment destination determination unit 117 identifies “Per person calculation” in the table 24c of the deployment destination information storage unit (step S401), and the node ID “sensor 1” is not included in the corresponding generation node ID (step S401). (No in S403), the source node “sensor 1” is added to the source node ID in the table 25b (step S410). Then, the deployment destination determination unit 117 refers to the table 22e and identifies the node “sensor 1” on which “average power” is aggregated (step S411). Since the module “Per-unit calculation” is not accompanied by data reference (No in step S412), the deployment destination determination unit 117 stores the identified “sensor 1” in the table 25b as the deployment destination node ID in the table 26a of FIG. Update (step S413). Then, the deployment destination determining unit 117 transmits the corresponding module “Per-person calculation” to the deployment destination node (step S414), then collects the corresponding module from the previous deployment destination (cloud) (step S415), and the data in the table 25c. 25d is deleted (step S416) and updated to the table 26b. The table 26 a and the table 26 b correspond to the state after the redeployment of “Per-person calculation”. From the above operation, it can be easily understood that the subsequent processes can be redeployed in a chained manner in accordance with the redeployment of the dependent preprocess.

  Operation example 2 of the deployment destination determination unit 117 will be described with reference to FIGS. 27 and 28. 27 and 28 are diagrams for explaining an operation example 2 of the deployment destination determination unit. In the operation example 2, an operation example of the deployment destination determination unit 117 when it is determined as NG in the deployment availability determination after module deployment will be described. The table 27a corresponds to the table for determining whether or not to deploy, which is tabulated in step S202 of FIG. The table 27a illustrates a case where the master data change count of the reference data of the module “average power calculation” is “6”, which exceeds the upper limit of the change count. Here, as an example, when the current state of the deployment destination information storage unit is the table 26a illustrated in FIG. 26, the deployment destination determination unit 117 determines whether the corresponding module “average power calculation” has been deployed. It is determined whether or not (step S203). Here, since the module “average power calculation” has been deployed (Yes at Step S203), the deployment destination determination unit 117 determines whether or not the deployment destination node of the module is a node other than the cloud (Step S204). ). Here, since the current deployment destination node is “sensor 1” (Yes in step S204), the deployment destination determination unit 117 determines whether or not partial reference data can be deployed in the sensor 1 (step S205). Specifically, based on the information regarding the deployment availability determination in the module definition information, the reference data characteristics are determined based on constraints and resource viewpoint constraints. Here, since the case where the upper limit value of the number of changes is exceeded in the table 27a is shown, the deployment destination determination unit 117 stores “NG” in the determination state (steps S208 and S422). Then, the deployment destination determination unit 117 stores the current deployment destination node ID “sensor 1” in the planned deployment destination node ID (step S423), and stores “cloud” in the deployment destination node ID (step S424). That is, the deployment destination determination unit 117 updates the table 26a to the table 27b.

  Subsequently, the deployment destination determination unit 117 causes the partial reference data and the module to be transmitted to the deployment destination node ID (Step S414), and collects the partial reference data and the module from the nodes that have been deployed so far (Step S415). . Then, the deployment destination determination unit 117 deletes the data 27c in the table 27b and updates it to the table 28a, and deletes the data 27e in the table 27d and updates it to the table 28b (step S416). The tables 28a and 28b correspond to the state after the “average power calculation” is redeployed in the cloud.

  Subsequently, the deployment destination determination unit 117 receives an “average power” event from the cloud as illustrated in the table 28c. Here, since the node ID is not included in the generation node ID corresponding to the “person-by-person calculation” in the table 28a, the deployment destination determination unit 117 refers to the table 28c and determines the input event type “average power” generation node. A certain “cloud” is stored in the generation node ID of the table 28a. Then, the deployment destination determination unit 117 refers to the table 22e and identifies the node “cloud” in which “average power” is aggregated. Since the module “personal calculation” is not accompanied by data reference, the deployment destination determination unit 117 stores the identified “cloud” in the table 28a as the deployment destination node ID and updates the table 28d.

  With reference to FIG. 29, a description will be given of the deployment feasibility determination processing from the partial reference data shortage detection. FIG. 29 is a flowchart illustrating a procedure of deployment availability determination processing from partial reference data shortage detection. This deployment propriety determination process is started when, for example, a partial reference data request is received from a lower node.

  As shown in FIG. 29, the deployment destination determination unit 117 waits for a partial reference data request from a lower node (step S501).

  Subsequently, based on the request, the deployment destination determination unit 117 identifies the deployed module that is the request source and the deployment target data (step S502). Then, the deployment destination determination unit 117 determines whether deployment is possible (step S503). It should be noted that in this determination as to whether or not deployment is possible, the reference data characteristic constraint is determined using the change frequency of the data to be deployed, and the resource viewpoint constraint is determined using the resource amount of the deployment destination node.

  If deployment is possible (Yes at step S504), the deployment target data is deployed to the requesting node (step S505), and the process returns to step S501. At this time, the deployment destination determination unit 117 causes the partial reference data extraction unit 119 to extract partial reference data, for example. For example, the partial reference data extraction unit 119 reads a search key, a reference location, and an extraction method corresponding to the deployed module from the module definition storage unit 111B. The partial reference data extraction unit 119 extracts partial reference data corresponding to the search key, the reference location, and the extraction method from the reference data stored in the reference data storage unit 162. If the deployment is impossible (No at Step S504), the process of Step S422 in FIG. 21 is started and redeployment is performed (Step S506). From the above operation, it is easily understood that the missing reference data can be additionally deployed upon reception of the partial reference data request transmitted when the deployment destination node detects a new target.

  Note that various integrated circuits and electronic circuits can be adopted for the module registration unit 111, the topology acquisition unit 112, the event reception unit 113, the module execution unit 115, and the occurrence event registration unit 116. Various integrated circuits and electronic circuits can also be adopted for the partial reference data request receiving unit 120, the partial reference data extracting unit 119, the partial reference data transmitting unit 163, the deployment destination determining unit 117, and the module transmitting unit 118. For example, an ASIC (Application Specific Integrated Circuit) is an example of the integrated circuit. Examples of the electronic circuit include a central processing unit (CPU) and a micro processing unit (MPU).

  Further, a semiconductor memory element or a storage device can be adopted as the module storage unit 111A, the module definition storage unit 111B, the topology storage unit 112A, and the event storage unit 114. In addition, a semiconductor memory element or a storage device can also be used for storage units such as the occurrence event information storage unit 116A, the reference data storage unit 162, and the deployment destination information storage unit 117A. For example, examples of the semiconductor memory element include a video random access memory (VRAM), a random access memory (RAM), a read only memory (ROM), and a flash memory. Examples of the storage device include storage devices such as a hard disk and an optical disk.

[Configuration of sensor node]
Next, the functional configuration of the sensor node according to the present embodiment will be described. FIG. 30 is a block diagram illustrating a functional configuration of the sensor node according to the first embodiment. A sensor node 210 illustrated in FIG. 30 includes a sensor information reception unit 211, a module reception unit 212, a module execution unit 213, and an event transmission unit 214. The sensor node 210 further includes a partial reference data receiving unit 215, a partial reference data storage unit 216, a partial reference data request unit 217, a topology detection unit 218, and a topology transmission unit 219.

  The sensor information receiving unit 211 is a processing unit that receives sensor information from a sensor device built in or attached to the sensor node 210. For example, when a power sensor is built in the sensor node 210, the sensor information receiving unit 211 receives power measured by the power sensor. Further, for example, when the sensor node 210 includes a temperature sensor, the sensor information receiving unit 211 receives the temperature measured by the temperature sensor. For example, when the sensor node 210 includes a humidity sensor, the sensor information reception unit 211 receives the humidity measured by the humidity sensor. When a plurality of sensor devices are built in the sensor node 210, a sensor information receiving unit 211 is provided corresponding to each sensor device.

  The module receiving unit 212 is a processing unit that receives a module from the server node 110. The module received by the module reception unit 212 is output to the module execution unit 213 that performs module execution control. Further, the module receiving unit 212 receives, for example, a module collection request from an upper node. When receiving the module collection request, the module reception unit 212 deletes the module deployed in the sensor node 210.

  The module execution unit 213 is a processing unit that performs execution control of modules deployed in the sensor node 210. For example, when the sensor information is received by the sensor information reception unit 211, the module execution unit 213 determines whether a module that uses the received sensor information as an input event type is deployed in the sensor node 210. At this time, when the module is deployed in the sensor node 210, the module execution unit 213 executes event processing by executing the module. At that time, as will be described later, the processing is performed while referring to the data in the partial reference data storage unit as necessary. Thereafter, the module execution unit 213 outputs the data processed by the module to the event transmission unit 214 as a new event. If the module is not deployed in the sensor node 210, the sensor information is output to the event transmission unit 214 without being processed.

  The event transmission unit 214 is a processing unit that transmits an event to an upper node. For example, the event transmission unit 214 transmits the event processed by the module execution unit 213 or the sensor information received from the sensor device by the sensor information reception unit 211 to the upper node. At this time, when transmitting the sensor information to the upper node, the event transmission unit 214 collects the node ID of the sensor node 210 that is the generation node, and the attribute name and attribute value of the aggregate attribute that aggregates a plurality of nodes including the own device. Is added to the sensor information. After that, the event transmission unit 214 transmits an event including the node ID of the generation node and the aggregation attribute together with the sensor information to the upper node.

  Here, the attribute name and attribute value of the “aggregated attribute” can be incorporated into a device driver or the like at the manufacturing stage of the sensor node 210. For example, if the sensor device is a power sensor, the device driver is configured to add an aggregate attribute such as “outlet ID”, which is a framework for measuring power, to the event. After that, when the communication connection is established between the sensor node 210 and the server node 110, the attribute value of the outlet ID given prior to the other sensor nodes 210 that have already subscribed to the service is set as the server node. It can also be automatically acquired from 110.

  The partial reference data receiving unit 215 is a processing unit that receives the partial reference data transmitted by the partial reference data transmitting unit 163. The partial reference data received in this way is registered in a partial reference data storage unit 216 described later. Further, the partial reference data receiving unit 215 receives, for example, partial reference data collection. When receiving the partial reference data collection, the partial reference data receiving unit 215 deletes the partial reference data from the partial reference data storage unit 216.

  The partial reference data storage unit 216 is a storage unit that stores partial reference data. The partial reference data storage unit 216 is referred to by the module execution unit 213 when an event is processed by a module arranged in the sensor node 210.

  The partial reference data request unit 217 is a processing unit that transmits a partial reference data request to the server node 110. For example, when the partial reference data storage unit 216 is referred to by the module execution unit 213 and the partial reference data request unit 217 detects a shortage of partial reference data, the partial reference data request unit 217 transmits a partial reference data request to the server node 110. .

  The topology detection unit 218 is a processing unit that detects, as a topology, connection information between nodes indicating to which upper node the sensor node 210 is connected. For example, the topology detection unit 218 recognizes the GW node 310 existing in the same network as the sensor node 210 using the UPnP protocol or the like, or receives a notification of the existence of the GW node 310 from the server node 110. Detect topology with. The establishment of a network connection with the server node 110 can be realized by setting an address such as a URL of the server node 110. Furthermore, the topology detection unit 218 confirms the amount of used resources (storage capacity) in the own node and assigns it to the internode connection information.

  The topology transmission unit 219 is a processing unit that transmits the topology detected by the topology detection unit 218 to the server node 110. For example, the topology transmission unit 219 transmits the node ID of the upper node to which the sensor node 210 is connected to the server node 110.

[Process flow in sensor node]
Next, the flow of processing in the sensor node 210 according to the present embodiment will be described. FIG. 31 is a flowchart illustrating a processing procedure in the sensor node according to the first embodiment. The process shown in FIG. 31 is repeatedly executed as long as the power of the sensor node 210 is ON.

  As shown in FIG. 31, when a new upper node is detected (Yes at step S601), the sensor node 210 executes the following process. That is, the sensor node 210 transmits the node ID of the upper node to the server node 110 (step S602). Furthermore, the topology detection unit 218 confirms the amount of used resources (storage capacity) in the own node and assigns it to the internode connection information. If a new upper node is not detected (No at step S601), the process proceeds to step S603 without executing the process at step S602.

  Subsequently, when a module is received from the server node 110 (Yes in step S603), the sensor node 210 deploys the module received from the server node 110 (step S604). If the module has not been received (No at Step S603), the process proceeds to Step S605 without executing Step S604.

  If partial reference data is received (Yes at step S605), the sensor node 210 stores the partial reference data in the partial reference data storage unit 216 (step S606). If partial reference data has not been received (No at Step S605), the process proceeds to Step S607 without executing Step S606.

  When sensor information is received from the sensor device (Yes at Step S607), the sensor node 210 further determines whether or not a module that uses the sensor information as an input event type is deployed (Step S608). If sensor information has not been received (No at step S607), the process returns to step S601.

  At this time, if the module is deployed (Yes at step S608), the sensor node 210 further determines whether or not partial reference data is deployed in the partial reference data storage unit (step S609). If the module is not deployed (No at Step S608), the sensor node 210 adds the generated node ID and the aggregation attribute to the sensor information received from the sensor device, and transmits it to the upper node (Step S614). ), The process proceeds to step S601.

  At this time, if partial reference data is deployed (Yes at step S609), the event is processed by referring to the partial reference data and executing the module (step S610). Then, the sensor node 210 transmits the event for which the processing process has been executed to the upper node (step S611), and proceeds to the process of step S601.

  On the other hand, when the partial reference data is not deployed (No at Step S609), the sensor node 210 transmits a partial reference data request to the server node 110 (Step S612). Then, when the sensor node 210 receives partial reference data corresponding to the partial reference data from the server node 110 and stores the partial reference data (step S613), the sensor node 210 proceeds to the process of step S610. In the process of step S613, when the partial reference data corresponding to the partial reference data is not received from the server node 110 within the predetermined time, the server node 110 includes the generation node ID and the sensor information received from the sensor device. It is good also as transmitting to an upper node after adding an aggregation attribute etc. and processing the said sensor information in an upper node.

[Effect of Example 1]
As described above, the server node 110 according to the present embodiment receives an input event from a sensor network that deploys a module that executes processing involving data reference to a node connected to the network. The server node 110 refers to the module definition storage unit, and extracts from the master data corresponding to the reference data extraction information associated with the module that executes processing related to the received input event and the reference location information. To do. The server node 110 deploys the extracted data to the node. As described above, the server node 110 extracts only the necessary record of the necessary column from the reference data and deploys it to the node, so that the unique process can be realized in the node without deploying a large amount of records.

  In addition, for example, the server node 110 determines whether or not the module that executes the process related to the received input event can be deployed on the node based on the index. Therefore, the communication load for future redeployment can be reduced. Can be reduced.

  In addition, for example, when a node that generates an input event related to a module that has already been deployed is changed, the server node 110 also changes the deployment destination when the deployment destination node for subsequent processing required by the change is changed. Since it is determined whether or not the corresponding module can be deployed to the node, the redeployment accompanying the module deployment can be easily realized.

  Further, for example, when the server node 110 receives a data request indicating that the data referenced by the module is requested from the node where the module is deployed, the server node 110 extracts data corresponding to the data request from the master. For this reason, the server node 110 can reduce the communication load accompanying data reference.

[Application example]
Next, application examples of the disclosed technology will be described. The disclosed technology can also be applied to cases other than the above-described power sensing. Hereinafter, three types of application examples 1 to 3 will be described as examples.

[Application Example 1]
Application example 1 of the disclosed technology will be described with reference to FIG. FIG. 32 is a diagram for describing an application example 1 of the disclosed technology. Application Example 1 shows that the disclosed technology can be applied to storage management such as physical distribution. Specifically, the case where it is applied to a temperature sensor with a tag reader is shown. In application example 1 shown in FIG. 32, a case where the disclosed technology is applied to a temperature sensor with a tag reader will be described. That is, in the application example 1, the case where the temperature sensor which measures the temperature in a storeroom is provided in the storehouse which stores fruits and vegetables, such as a strawberry and a melon. From this temperature sensor, an event including the sensor ID of the temperature sensor, the temperature in the storage, and the tag ID of the tag attached to each fruit and vegetable is generated. When an event is detected, the module execution unit executes a process for determining whether the temperature is appropriate according to the stored items, that is, the fruits and vegetables. In this processing, the processing deployed in the module execution unit requires reference data including storage conditions associated with fruits and vegetables corresponding to the tag ID detected by each sensor (sensor ID) in the storage as partial reference data. However, based on the indirect reference using the case of data 5d in FIG. 5, it is possible to deploy only necessary reference data {tag ID, storage condition} by following sensor ID⇒tag ID⇒fruit and vegetable name⇒storage condition. . Thus, the disclosed technology is suitably applied to a temperature sensor with a tag reader.

[Application Example 2]
Application example 2 of the disclosed technology will be described with reference to FIG. FIG. 33 is a diagram for describing an application example 2 of the disclosed technology. Application example 2 shown in FIG. 33 shows that the disclosed technology can be applied to work support in a factory or the like. Specifically, the case where it is applied to the evaluation of work efficiency by a motion sensor will be described. That is, in the application example 2, when a plurality of processes included in a certain production line are assigned to each worker, the disclosed technology is applied to a motion sensor that detects the operation of the worker working in each process. Is assumed. From this motion sensor, an event including a sensor ID, motion data indicating the operation of the worker during work, and a work ID for each work is generated. When the event is detected, the motion data is analyzed, and processing for evaluating the efficiency of the work of the worker is executed by the module execution unit. In this process, reference data including an evaluation standard associated with the work ID is referred to. When an efficient operation during work is detected by this evaluation, the operation is extracted as know-how, and motion data indicating the operation is updated / redeployed as reference data for evaluation. In this process, the process provided in the module execution unit requires appropriate motion determination data corresponding to the work ID to be analyzed for each motion sensor (sensor ID). In this case as well, only the necessary data can be deployed based on the indirect reference as in Application Example 1. As described above, the disclosed technique is suitably applied to the evaluation of work efficiency by the motion sensor.

[Application Example 3]
Application example 3 of the disclosed technology will be described with reference to FIG. FIG. 34 is a diagram for describing an application example 3 of the disclosed technology. In Application Example 3 illustrated in FIG. 34, a case where the disclosed technology is applied to monitoring of an operating state of a machine tool will be described. That is, in Application Example 3, it is assumed that the disclosed technology is applied to a sensor that detects the operating state of a machine tool. From this sensor, an event including the machine ID of the machine tool, the operating state, and the machine user ID occurs. Examples of this operating state include the amount of consumables mounted on the machine tool and the usage status by the user. When an event is detected, the module execution unit executes a process for determining, for each user, the consumption status of the consumables mounted on the machine tool, the usage status indicating whether the machine is being used safely, or the like. In this processing, the processing deployed in the module execution unit includes data relating to replacement time for consumables possessed by the machine corresponding to the machine ID, data relating to operational safety such as dangerous operation / appropriate operation corresponding to the machine ID, and the like. Requires reference data to include. In this case as well, in the same manner as in Application Example 1, based on indirect reference, machine ID → consumables → replacement time data and machine ID → operation safety data can be traced, and only necessary data can be deployed. Thus, the disclosed technology is suitably applied to monitoring the operating state of the machine tool.

  As described above, as shown in Application Examples 1 to 3, the disclosed technology is preferably applied even to various solution examples.

  Although the embodiments of the present invention have been described so far, the present invention may be implemented in other embodiments besides the above-described embodiments. Therefore, other embodiments will be described below.

[System configuration of sensor network system including GW node]
For example, in the first embodiment, the case where the server node 110 and the sensor node 210 are accommodated in the sensor network system 1 has been described, but the present invention is not limited to this. For example, the GW node 310 may be accommodated between the server node 110 and the sensor node 210.

  A system configuration of a sensor network system including a GW node will be described. FIG. 35 is a diagram illustrating a system configuration of the sensor network system according to the second embodiment. As shown in FIG. 35, the sensor network system 3 accommodates a server node 110, a sensor node 210, and a GW node 310. The sensor node 210 and the GW node 310 are connected to be communicable via the network 5. Further, the GW node 310 and the server node 110 are connected via the network 5 so that they can communicate with each other. In the example of FIG. 35, the case where the sensor node 210 and the GW node 310 are accommodated one by one is illustrated. However, the present invention is applicable to the case where an arbitrary number of sensor nodes 210 and an arbitrary number of GW nodes 310 are accommodated. it can.

  A functional configuration of the GW node 310 will be described. FIG. 36 is a block diagram illustrating a functional configuration of a GW node according to the second embodiment. The GW node 310 illustrated in FIG. 36 is different from the sensor node 210 illustrated in FIG. 30 in that it includes an event reception unit 311 instead of the sensor information reception unit 211. In the following description, the same reference numerals are given to functional units that exhibit the same functions as those in the above embodiment, and the description thereof is omitted.

  The event receiving unit 311 is a processing unit that receives an event. For example, the event reception unit 311 receives an event from the sensor node 210 or other GW node 310 that is a lower node.

[program]
FIG. 37 is a diagram illustrating a computer that executes an event collection program. As illustrated in FIG. 37, the computer 400 includes a CPU 401 that executes various arithmetic processes, an input device 402 that receives data input from a user, and a monitor 403. In addition, the computer 400 includes a medium reading device 404 that reads a program or the like from a storage medium, an interface device 405 for connecting to another device, and a communication device 406 for connecting to another device wirelessly. The computer 400 also includes a RAM (Random Access Memory) 407 that temporarily stores various types of information and a storage device 408. Each device 401 to 408 is connected to a bus 409.

  The storage device 408 includes a medical information input program having the same functions as the processing units of the event reception unit 113, the partial reference data extraction unit 119, the partial reference data transmission unit 163, and the deployment destination determination unit 117 illustrated in FIG. Remembered. The storage device 408 stores various data for realizing the event collection program.

  The CPU 401 reads out each program stored in the storage device 408, expands it in the RAM 407, and executes it to perform various processes. In addition, these programs can cause the computer to function as the event reception unit 113, the partial reference data extraction unit 119, the partial reference data transmission unit 163, and the deployment destination determination unit 117 illustrated in FIG.

  Note that the above-described event collection program is not necessarily stored in the storage device 408. For example, the computer 400 may read and execute a program stored in a computer-readable recording medium. The computer-readable recording medium corresponds to, for example, a portable recording medium such as a CD-ROM, a DVD disk, a USB (Universal Serial Bus) memory, a semiconductor memory such as a flash memory, a hard disk drive, and the like. Further, the program may be stored in a device connected to a public line, the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or the like, and the computer 400 may read and execute the program therefrom. good.

[Other Examples]
In the first embodiment, for example, the case where the module deployment process is started in response to a change in the network topology is exemplified. However, when a module is added or deleted, or when the module definition is changed. It is also possible to start the module deployment process.

  Note that in the disclosed apparatus, the module deployment process can be executed in the background of the event processing process executed by the module and the service providing process executed by the service providing application. For example, the module deployment process can be executed on the standby server node while the event processing process and the service providing process are executed on the active server node.

  The following supplementary notes are further disclosed with respect to the embodiments including the above examples.

(Appendix 1) An event collection method executed by a computer,
Computer
Receives an input event from a sensor network that deploys a module that performs processing with data reference to a node connected to the network,
Corresponds to attribute information indicating the attribute in the input event, reference data extraction information that identifies the record referenced by the module according to the attribute information, and reference location information that identifies the attribute of the data referenced by the module The reference data extraction information associated with the module that executes the process related to the received input event and the data corresponding to the reference location information are referred to the data reference by referring to the module definition storage unit attached and stored. Extracted from the master that stores the data referenced
An event collection method comprising: executing each process of deploying data extracted by the extracting process to the node.

(Appendix 2) An event collection method executed by a computer,
Computer
Receives an input event from a sensor network that deploys a module that performs processing with data reference to a node connected to the network,
Determining whether the module that performs processing related to the received input event can be deployed to the node based on the indicator;
When it is determined that the module can be deployed to the node by the determining process, each process of deploying data referenced by the data reference to the node is executed.

(Additional remark 3) The said computer determines whether the said module which performs the process relevant to the received input event can be deployed to the said node based on an parameter | index,
The appending process is characterized in that, when the determining process determines that the module can be deployed to the node by the determining process, the data extracted by the extracting process is deployed to the node. Event collection method.

(Additional remark 4) When the node which generate | occur | produces the input event relevant to the module already deployed is changed, the said determination process is applicable at the time of the change of the deployment destination node of the subsequent process required by the change. 4. The event collection method according to appendix 2 or 3, wherein it is determined whether or not the corresponding module can be deployed in the destination node.

(Supplementary Note 5) The determination process includes, as the index, one or both of a first condition related to a change frequency of data referred to by a module and a second condition related to a resource amount of a node in which the module is deployed. The event collection method according to any one of appendices 2 to 4, wherein it is determined whether or not the module can be deployed to the node using determination information including:

(Additional remark 6) When the process to extract receives the data request | requirement which requests | requires the data referred by the said module from the node by which the module was arrange | positioned, the data corresponding to the said data request are received from the said master. 4. The event collection method according to appendix 1 or 3, wherein the event is collected.

(Appendix 7)
Receives an input event from a sensor network that deploys a module that performs processing with data reference to a node connected to the network,
Corresponds to attribute information indicating the attribute in the input event, reference data extraction information that identifies the record referenced by the module according to the attribute information, and reference location information that identifies the attribute of the data referenced by the module The reference data extraction information associated with the module that executes the process related to the received input event and the data corresponding to the reference location information are referred to the data reference by referring to the module definition storage unit attached and stored. Extracted from the master that stores the data referenced
An event collection program that causes each process to deploy data extracted by the extracting process to the node.

(Appendix 8)
Receives an input event from a sensor network that deploys a module that performs processing with data reference to a node connected to the network,
Determining whether the module that performs processing related to the received input event can be deployed to the node based on the indicator;
An event collection program that, when it is determined by the determination process that the module can be deployed to the node, executes each process of deploying data referenced by the data reference to the node.

(Additional remark 9) The said computer determines whether the said module which performs the process relevant to the received input event can be deployed to the said node based on an parameter | index,
The appending process is characterized in that the deploying process deploys the data extracted by the extracting process to the node when it is determined that the module can be deployed to the node by the determining process. Event collection program.

(Additional remark 10) When the node which generate | occur | produces the input event relevant to the module already deployed is changed, the said determination process is applicable at the time of the change of the deployment destination node of the subsequent process required by the change. 10. The event collection program according to appendix 8 or 9, wherein it is determined whether or not the corresponding module can be deployed in the destination node.

(Additional remark 11) The said process to determine is one or both of the 1st condition relevant to the change frequency of the data referred by a module as the said index, and the 2nd condition relevant to the resource amount of the node by which a module is arrange | positioned The event collection program according to any one of appendices 8 to 10, wherein it is determined whether or not the module can be deployed to the node using determination information including:

(Supplementary Note 12) When the data processing indicating that the data referred to by the module is requested is received from the node in which the module is deployed, the processing to extract the data corresponding to the data request from the master The event collection program according to appendix 7 or 9, wherein the event collection program is extracted.

(Additional remark 13) The receiving part which receives an input event from the sensor network which arrange | positions the module which performs the process with a data reference to the node connected to the network,
Corresponds to attribute information indicating the attribute in the input event, reference data extraction information that identifies the record referenced by the module according to the attribute information, and reference location information that identifies the attribute of the data referenced by the module A module definition storage unit for storing the information;
With reference to the module definition storage unit, the data corresponding to the reference data extraction information associated with the module that executes the process related to the received input event and the data corresponding to the reference location information are referred to in the data reference. An extraction unit for extracting data from a master that stores data;
An information processing apparatus comprising: a deployment unit that deploys the data extracted by the extraction unit to the node.

(Supplementary Note 14) A receiving unit that receives an input event from a sensor network that deploys a module that executes processing involving data reference to a node connected to the network;
A determination unit that determines whether or not the module that executes processing related to the received input event can be deployed in the node based on the index;
An information processing apparatus comprising: a deployment unit that deploys data referred to in the data reference to the node when the determination unit determines that the module can be deployed to the node.

(Additional remark 15) It further has the determination part which determines whether the said module which performs the process relevant to the received input event can be deployed in the said node based on an parameter | index,
The information processing unit according to appendix 13, wherein the deployment unit deploys the data extracted by the extraction unit to the node when the determination unit determines that the module can be deployed to the node. apparatus.

(Additional remark 16) When the node which generate | occur | produces the input event relevant to the module already deployed is changed, the said determination part determines whether the said module can be deployed to the node after a change, It is characterized by the above-mentioned. The information processing apparatus according to appendix 14 or 15,

(Supplementary Note 17) A determination memory for storing determination information including one or both of a first condition related to a change frequency of data referred to by a module and a second condition related to a resource amount of a node in which the module is deployed Further comprising
The determination unit refers to the determination storage unit as the index, and determines whether or not a module that executes a process related to the received input event can be deployed in the node. 16. The information processing apparatus according to any one of 16.

(Additional remark 18) When the said extraction part receives the data request which shows that the data referred by the said module are requested | required from the node by which the module was arrange | positioned, the data corresponding to the said data request are extracted from the said master The information processing apparatus according to appendix 13 or 15, characterized in that:

1 sensor network system 110 server node 111 module registration unit 111A module storage unit 111B module definition storage unit 112 topology acquisition unit 112A topology storage unit 113 event reception unit 114 event storage unit 115 module execution unit 116 generated event registration unit 116A generated event information storage Unit 117 Reference data storage unit 118 Partial reference data request reception unit 119 Partial reference data extraction unit 120 Partial reference data transmission unit 121 Deployment destination determination unit 121A Deployment destination information storage unit 122 Module transmission unit

Claims (10)

An event collection method executed by a computer,
Computer
Receiving input events from the sensor network nodes are connected to perform a module for performing processing with a data reference,
When the input event is received, the attribute information indicating the attribute in the input event, the reference data extraction information for identifying the record referenced by the module according to the attribute information, and the attribute of the data referenced by the module are identified. A reference associated with a module that performs processing related to the received input event deployed in the node that transmitted the received input event with reference to the module definition storage unit that stores the reference location information in association with the data corresponding to the data extraction information and references location information, referring to the case where the module performs processing with the data reference, storing data corresponding to the reference data extraction information and the reference position information Extracted from the master based on the received input event ,
Deploying the data extracted by the processing of the extract to the node
Event collection method which is characterized in that to perform the processing. An event collection method executed by a computer,
Computer
Receiving input events from the sensor network nodes are connected to perform a module for performing processing with a data reference,
The input received based on one or more conditions among a condition related to characteristics of partial reference data based on data referred to when the module performs processing involving data reference and a condition related to the resource amount of the node Determining whether the module performing processing related to an event can be deployed to the node;
When it is determined by the determination process that the module can be deployed to the node, the data referenced by the data reference is deployed to the node
Event collection method which is characterized in that to perform the processing. The computer is based on one or more of a condition relating to characteristics of partial reference data based on data referred to when the module performs processing involving data reference, and a condition relating to the resource amount of the node. Determining whether the module that performs processing related to the received input event can be deployed to the node;
2. The process according to claim 1, wherein, when the determining process determines that the module can be deployed to the node, the data extracted by the extracting process is deployed to the node. The event collection method described. In the determination process, when a node that generates an input event related to a module that has already been deployed is changed , a module that has a dependency relationship with the module that has been deployed to the node after the modification is changed to the node after the modification. event collection method according to claim 2 or 3, characterized in that to determine whether it deployed. The determination process includes a first condition for determining whether or not the number of times per predetermined time regarding the change frequency of the partial reference data does not exceed an upper limit value, and the amount of occupied resources of the partial reference data is the resource of the node Whether or not the module that performs processing related to the received input event can be deployed to the node when one or more conditions are satisfied among the second conditions for determining whether or not the upper limit of the amount is exceeded The event collection method according to claim 2, wherein the event collection method is determined.   The extracting process includes extracting data corresponding to the data request from the master when a data request indicating that the data referred to by the module is requested is received from a node where the module is deployed. The event collection method according to claim 1 or 3, characterized in that On the computer,
Receiving input events from the sensor network nodes are connected to perform a module for performing processing with a data reference,
When the input event is received, the attribute information indicating the attribute in the input event, the reference data extraction information for identifying the record referenced by the module according to the attribute information, and the attribute of the data referenced by the module are identified. A reference associated with a module that performs processing related to the received input event deployed in the node that transmitted the received input event with reference to the module definition storage unit that stores the reference location information in association with the data corresponding to the data extraction information and references location information, referring to the case where the module performs processing with the data reference, storing data corresponding to the reference data extraction information and the reference position information Extracted from the master based on the received input event ,
Deploying the data extracted by the processing of the extract to the node
Event collection program, characterized in that to perform the processing. On the computer,
Receiving input events from the sensor network nodes are connected to perform a module for performing processing with a data reference,
The input received based on one or more conditions among a condition related to characteristics of partial reference data based on data referred to when the module performs processing involving data reference and a condition related to the resource amount of the node Determining whether the module performing processing related to an event can be deployed to the node;
When it is determined by the determination process that the module can be deployed to the node, the data referenced by the data reference is deployed to the node
Event collection program, characterized in that to perform the processing. A receiver node for executing a module for performing processing with data references to receive input events from the connected sensor network,
Corresponds to attribute information indicating the attribute in the input event, reference data extraction information that identifies the record referenced by the module according to the attribute information, and reference location information that identifies the attribute of the data referenced by the module A module definition storage unit for storing the information;
When the receiving unit receives the input event, the module definition storage unit is referred to and associated with a module that performs processing related to the received input event arranged in a node that has transmitted the received input event. the data corresponding to the reference data extraction information and references point information, the module refers to when processing with the data reference, stored data corresponding to the reference data extraction information and the reference position information Extracting from the master to be extracted based on the received input event ;
An information processing apparatus comprising: a deployment unit that deploys the data extracted by the extraction unit to the node. A receiver node for executing a module for performing processing with data references to receive input events from the connected sensor network,
The input received based on one or more conditions among a condition related to characteristics of partial reference data based on data referred to when the module performs processing involving data reference and a condition related to the resource amount of the node A determination unit that determines whether the module that performs processing related to an event can be deployed in the node;
An information processing apparatus comprising: a deployment unit that deploys data referred to in the data reference to the node when the determination unit determines that the module can be deployed to the node.

Images