JP5307425B2 - Integrated processing system for sensor networks - Google Patents

Description

  The present invention relates to a sensor network that can easily collect surrounding environmental information by installing a sensor node for transmitting information obtained from a sensor to a location to be monitored, and the monitoring target The present invention relates to a sensor information integrated processing system that performs information processing on environmental information collected from a network and provides a service to be distributed to users.

  In recent years, due to the development of MEMS (Micro Electro Mechanical Systems) technology, proposals have been made on how to use sensor networks based on the downsizing and long-time driving technology of sensor nodes by applying sensor technology and wireless communication technology. . In addition, high-speed communication networks have facilitated large-capacity communication with remote areas, and various services using communication networks have appeared. On the other hand, in consideration of current social circumstances, it is expected to realize a communication service that combines a sensor network and a communication network in various fields such as disaster support, security, weather forecasting, and action support.

  Conventionally, in these target fields, services have been performed using dedicated equipment, equipment, etc., but the installation location is generally limited to a small scale. The sensor network has a feature that it can be installed freely and easily as long as wireless communication is possible. However, the situation is that the types of notification information from these sensors may increase or decrease arbitrarily when a range spanning multiple different areas is targeted and various different sensors are used in combination in these areas. Can be considered. In this case, the specific implementation mechanism of the network server system that can process the sensor information that can respond to the occurrence state of the information from the sensor in any case has not been disclosed.

For example, sensor networks are being put into practical use in the fields of logistics, security, meteorological observation, etc. As described above, sensor networks are used to obtain information quickly and in a timely manner. The network service for flexibly responding to the request of the user is not yet clarified in its implementation mechanism (see, for example, Patent Document 1).
Special table 2004-533034

  As described above, technologies for collecting information through a sensor network, processing them in an integrated manner, and providing them to users have been proposed, but these are mainly used as a means for providing information to users. (On-demand type) and push type are simply mixed to provide communication services to users.

  Therefore, the sensor information integrated processing system of the present invention performs a different service process for each of the pull type and the push type which have different user requirements, and provides a service by integrating one server. For the purpose.

In order to solve the above problems, an integrated processing system for a sensor network according to the present invention acquires data information detected by a sensor via an ad hoc network, converts the data information into a predetermined data format, and transmits the data information. The function unit, the sensor data collection function unit that collects data information transmitted by the network abstraction function unit, and the data information collected by the sensor data collection function unit are acquired and predetermined for each data information content and user. The data type collected by the push type service function unit and the sensor data collection function unit for delivering the received data distribution service in the push type distribution form, and the data information and data predetermined for each user A pull-type service function unit that distributes a distribution service in a pull-type distribution form; Wherein the pull type service function section receives a push history request from the user, it acquires the push history information including a sensor type identifier from the push service function unit, collected data information of the sensor data collection function unit The data information corresponding to the push history information is acquired from the information, and the analysis processing based on the data information corresponding to the push history information is performed .

In the integrated processing system for a sensor network according to the present invention, the push type service function unit refers to a predetermined event conversion table, and acquires an event conversion logic unit that acquires a sensor event corresponding to the content of the data information; with acquiring the sensor event to determine the event delivery instructions, and a context extraction logic unit for generating a context event information describing the service processing corresponding to the context by executing a processing task that is determined in accordance with the event distribution procedure, the It is preferable to include a service processing logic unit that executes service processing corresponding to the context event information for each processing task.
In the case of realizing a network service using a sensor network, a mechanism for realizing a network service can be provided by processing the context using logic for extracting the context.

In the sensor network integrated processing system according to the present invention, the push service function unit extracts a context extraction logic unit corresponding to a sensor event by referring to a predetermined context extraction logic unit database, and extracts the extracted context An event delivery logic unit that transmits a sensor event to the logic unit is further included, and a command for adding, deleting, or changing the context event information is stored in the context extraction logic unit database, and stored in the context extraction logic unit It is preferable to update the context event information that has been added, deleted, changed, or the like .
In push-type service processing, service processing logic can be arbitrarily added or deleted according to sensor type or user type.

  According to the present invention, in a network service utilizing a sensor network, a different service process is applied to each of a pull type and a push type, which have essentially different user requests, and a single server is integrated to provide a service. Can be provided.

Embodiments of the present invention will be described with reference to the accompanying drawings. The embodiment described below is an example of the configuration of the present invention, and the present invention is not limited to the following embodiment.
Details will be described below.

(Embodiment 1)
FIG. 1 is a schematic configuration diagram of a sensor network integrated processing system according to the present embodiment. The sensor network integrated processing system according to the present embodiment includes a sensor network 100 and a sensor data integrated processing system 105. The sensor network 100 and the sensor data integrated processing system 105 are connected by a communication network 110 such as the Internet.

  The sensor network 100 includes one or a plurality of sensor nodes 101 and a communication node 102, and is connected by an ad hoc network that performs transmission and reception with each other without the intervention of an access point.

  The sensor node 101 includes a sensor and a communication device. Acquire data information such as sensors, natural environment or human body. The data information may be acquired by directly detecting the data information or by communication. The communication device transfers the acquired data information to the communication node 102 by multi-hop communication means.

  The communication node 102 includes a reception interface 103 and a network abstraction unit 104. The reception interface 103 receives the data information and transfers the data information to the network abstraction unit 104. The network abstraction unit 104 converts the received data information into a data format that can be handled uniformly in order to absorb differences between communication protocols such as a packet format, and transfers the data information to the sensor data integration processing system 105. The data format is, for example, an XML format.

  The sensor data integrated processing system 105 includes a sensor data collection function unit 106, a pull type service function unit 107, and a push type service function unit 108. The sensor data collection function unit 106 receives data information sent from the network abstraction unit 104. Thereby, the sensor data integration processing system 105 collects data information. Then, the sensor data collection function unit 106 transfers the data information to the pull type service function unit 107 and the push type service function unit 108. At this time, the data information is transferred to the pull type service function unit 107 and the push type service function unit 108 in a suitable format such as an XML format.

  The pull-type service function unit 107 distributes to the terminals zz1 and zz2 owned by the user. The push-type service function unit 108 delivers to the terminals yy1 and yy2 owned by the user. Accordingly, the sensor network integrated processing system can provide a pull-type and push-type information distribution service. The terminals zz1, zz2, yy1, and yy2 can be applied to anything having a data information reception function. For example, a computer such as a personal computer or a PDA, or a telephone such as a mobile phone. Here, the pull-type service function unit 107 and the push-type service function unit 108 include processing mechanisms specialized for the respective distribution forms.

(Embodiment 2)
When the sensor network 100 described in the first embodiment has a plurality of areas, the sensor data collection function unit 106 identifies sensor networks at a plurality of sites from the data information transmitted from the sensor data abstraction unit 104. The identification of the sensor network 101 is information unique to the sensor data abstraction unit 104. For example, it is geographical information for each base such as GPS (Global Positioning System), GIS (Geographic Information System) and the like.

  FIG. 2 shows a data format example in the sensor network. As information unique to the sensor data abstraction unit 104, a region code (hereinafter referred to as an area code) for easily identifying a specific region where each sensor node 101 is deployed is used. In this case, each sensor data abstraction unit 104 includes a mechanism for adding an area code to data information. In addition to this, it is also possible to transfer the data information to the sensor data collection function unit 106 after adding the area code at the communication node 102 which becomes the monitoring base of each sensor network 100. However, it is not limited to these methods.

  In the sensor network integrated processing system according to the first and second embodiments, the pull format, the push format, and the two information distribution means are formed as different processes having different user processing requests, or in one process. Thus, a processing form such as realization as another task is performed, and the distribution service is provided to the user corresponding to the distribution method suitable for each processing service. Also, the mechanism disclosed in the present embodiment links push and pull formal processing services with each other.

  Specifically, the sensor network integrated processing system according to the present embodiment is connected to a computer, a personal computer, a mobile phone, a fixed phone, etc. in a monitoring center via the Internet, a mobile phone network, or a fixed phone network. The data information detected by the sensor node 101 relating to the natural environment or the human body is transmitted to the communication node 102, which is the entrance of the network, in a multi-hop manner through an ad hoc network for relaying the acquired information. In a network service system in which data information is processed in the sensor data integrated processing system 105 on the processing server side on the network registered in advance, the acquired information is processed, and the result is stored in a database so that the user can use it. Widely dispersed In response to sensor information obtained from a large number of sensor nodes 101, one or a plurality of registered users, one or a plurality of sensor types on the server side corresponding to the requested application type for each sensor node 101 In the data integration processing system 105, when performing different individual processing, two logical processing units, that is, a processing unit that detects a context from acquired information and a processing unit that processes the context and provides a service are operated. An application mechanism for automatically generating and corresponding context extraction processing is provided in the sensor data integration processing system 105, and a registered user uses a remote means to determine which application type corresponding mechanism is used. Data integration processing system 105 is notified and registered And the user, sensor data integrated processing system 105, only when the results based on the requested application is obtained, the push delivery.

  In addition, the sensor network integrated processing system according to the first and second embodiments is connected to the Internet or a communication network such as a mobile phone network or a fixed telephone network with respect to a computer, a personal computer, a mobile phone, a fixed phone and the like in a monitoring center. The data information detected by the sensor node 101 related to the human body etc. is relayed via the ad hoc network via the ad hoc network via 110 and 111, and the data is pre-registered in the network. The blood pressure, body temperature, pulse wave, and electrocardiogram obtained from the sensor node 101 attached to the human body, which is processed by the above processing server and stored in a database and made available to the user and can be moved over a wide range. Send data information to the network in real time In the network service system for notifying registered supervisors, the sensor data integration processing system 105 detects the data sent via the sensor network in a push format, analyzes the contents, and then registers the data. Perform the processing in the event processing logical unit, and easily add / change the service processing logic unit (304 in FIG. 3) and the context detection logic unit (303 in FIG. 3). A database for dynamically adding / changing a service, push processing results to users yy1 and yy2, and managing history information when the push delivery is performed for all registered users After a request from the administrator xxx, cooperate with the pull type network service, Sometimes, the stored sensor information until now visualized, and providing.

  In addition, the sensor network integrated processing system according to the first and second embodiments is connected to a computer, a personal computer, a mobile phone, and a fixed telephone in a monitoring center via the Internet, a mobile phone network, or a fixed telephone network. The data information detected by the sensor node related to the natural environment or the human body is relayed to the communication node 102, which is the entrance of the network, in multihop via the ad hoc sensor network, and the data In a network service system in which the result is stored in a database and made available to the user, the database includes seismic intensity, illuminance, noise, water quality, pollen , Measurement information such as wind speed, rainfall The information is sent to the integrated processing database via the sensor network in a push format at a time when a certain threshold value is exceeded or at regular time intervals. After analyzing the sensor data content, it is processed in advance based on the content processed in the event processing logic unit registered by the user, the result is pushed to the registered user, and the push history is When there is a request from the database administrator xxx for the purpose of managing all registered users, the transmission history of the pull type service and the information, and the information obtained in all the time series so far When the analysis result obtained by analyzing the whole is presented together or when there is a pull type service request, For network services, characterized in that it push that there is the request, a sensor information integration processing system.

(Embodiment 3)
FIG. 3 is a configuration example of the push type service function unit 108. The push type service function unit 108 is connected to the sensor data collection function unit 106, and realizes communication with a push type user registration terminal. The push type service function unit 108 includes an event conversion logic unit 301, an event distribution logic unit 302, a context extraction logic unit 303, a service processing logic unit 304, a push facility 305, a push database 306, a management control unit 307, and a context extraction logic unit database. 308, a service processing logic unit database 309, and an event conversion correspondence table 320. Here, the push service function unit 108 may include a plurality of service processing logic units 304.

  An outline of the push type service function unit 108 will be described. The numerical value of the step corresponds to the circled number in the figure. In step S <b> 1, the event conversion logic unit 301 acquires data information from the sensor data collection function unit 106. In step S2, the event conversion logic unit 301 searches the event conversion correspondence table 320. Then, a sensor event is generated according to the search result. In step S <b> 3, the event conversion logic unit 301 outputs the generated sensor event to the event distribution logic unit 302. In step S <b> 4, the event distribution logic unit 302 acquires information on identifiers held in the receivable context extraction logic unit 303 from the context extraction logic unit database 308. In step S <b> 5, the event distribution logic unit 302 outputs the sensor event to the context extraction logic unit 303. In step S <b> 6, the event distribution logic unit 302 acquires the event distribution procedure from the context extraction logic unit 303. In step S 7, the event distribution logic unit 302 acquires the identifier information held in the service processing logic unit 304 from the service processing logic unit database 309. In step S8, the event distribution logic unit 302 outputs the context event to the service processing logic unit 304. In step S <b> 9, the service processing logic unit 304 outputs the service processing logic unit identifier, the processing task identifier, and the service processing result to the push facility 305. In step S <b> 10, the push facility 305 acquires push target user information from the push database 306. In step S11, the push facility 305 outputs the result of the service processing to the push type user terminal yyy.

  In step S12, the management control unit 307 acquires an add command, a delete command, and a change command of the context extraction logic unit 303 or the service processing logic unit 304 from the administrator xxx. In step S13, the management control unit 307 stores the add command, the delete command, and the change command of the context extraction logic unit 303 or the service processing logic unit 304 in the context extraction logic unit database 308 and the service processing logic unit database 309. In step S <b> 14, the management control unit 307 updates the context event information stored in the context extraction logic unit 303 such as addition, deletion, and change. In step S15, the management control unit 307 updates the service processing logic unit 304. For example, if it is an addition command, a new service processing logic unit 304 is added. If it is a delete command, the service processing logic unit 304 is deleted. If it is a change command, it is updated to a new service processing logic unit 304.

  The event conversion correspondence table 320 stores events corresponding to sensor types in advance. If the sensor type is information about the environment, for example, it is a temperature sensor or an illuminance sensor. The event is, for example, sensor information such as configuration format and generation information. A sensor type identifier such as # 0001 is assigned to the sensor type, and conversion is possible based on the sensor type.

  The push database 306 stores push target user information. The push target user information is information related to a user who provides a distribution service from the push type service function unit 108, and includes the name of the push target user, a distribution means of a service processing result, a distribution destination address, and the like.

  The context extraction logic unit database 308 stores information on the receivable context extraction logic unit 303 for each sensor type.

  The service processing logic unit database 309 stores information about the service processing logic unit 304. For example, the service processing logic unit 304 stores the service processing logic unit meta information such as the identifier of the service processing logic unit 304, the operating status thereof, the receivable event type, the presence / absence of push distribution, and the push distribution history.

  The event conversion logic unit 301 shown in FIG. 3 receives the data information transmitted from the sensor data collection function unit 106, and converts the data information into a corresponding sensor event.

FIG. 4 shows an example of an implementation flow of the event conversion logic unit 301. In step S <b> 101, the event conversion logic unit 301 receives data information from the sensor data collection function unit 106. The data information includes, for example, a sensor type identifier, a user ID, a group ID, event contents, and the like.
In step S102, a sensor type identifier is extracted from the data information received in step S101. For example, when a sensor type identifier is included in the event content of the data information, the sensor type identifier is extracted from the event content.
In step S103, the event conversion logic unit 301 searches the event conversion correspondence table 320 using the extracted sensor type identifier as a key. For example, in the event conversion correspondence table 320, sensor # 0001 is assigned to a temperature sensor, sensor # 0002 is assigned to an illuminance sensor, and sensor information such as a configuration format and generation information is stored in association with each sensor.
In step S104, it is determined whether or not information corresponding to the key exists in the event conversion correspondence table 320.

In step S104, when information corresponding to the key exists in the event conversion correspondence table 320, in step S105, the event conversion logic unit 301 generates a corresponding sensor event based on the information of the information. An example of sensor event description is shown in FIG. Although described in the Java (registered trademark) class, it is not limited to this. The sensor event preferably includes a sensor type identifier for determining the type of sensor event.
In step S106, the generated sensor event is transmitted to the event distribution logic unit 302, and the execution flow of the event conversion logic unit 301 is terminated.

  On the other hand, in step S104, when there is no information corresponding to the key in the event conversion correspondence table 320, the event conversion logic unit 301 ends the execution flow.

  The event distribution logic unit 302 illustrated in FIG. 3 determines a processing task corresponding to the sensor event transmitted from the event conversion logic unit 301 or the context event transmitted from the context extraction logic unit 303. The determination of the processing task is, for example, determination of a delivery destination. When the processing task is determined, the event distribution procedure 311 is acquired from the context extraction logic unit 303. Then, the reception event corresponding to the processing task is distributed to the context extraction logic unit 303 or the service processing logic unit 304.

FIG. 6 shows an implementation flow of the event delivery logic unit 302. In this implementation flow, the event distribution logic unit 302 distributes the sensor event transmitted from the event conversion logic unit 301 to the context extraction logic unit 303.
In step S201, the event distribution logic unit 302 receives the sensor event transmitted from the event conversion logic unit 301 in the push type service function unit 108, and then determines the sensor type. Although it is preferable to use the sensor type identifier included in the sensor event as the event type determination method, the determination method is not limited to this.
In step S202, after determining the sensor type, the event distribution logic unit 302 searches the context extraction logic unit database 308 using the sensor type as a key.
In step S203, the event distribution logic unit 302 determines whether there is a context extraction logic unit 303 capable of receiving the sensor type. That is, it is determined whether or not the processing task determined as the delivery destination exists in the processing task group of the context extraction logic unit 303.

If there is a processing task determined as a delivery destination in the processing task group of the context extraction logic unit 303 in step S203, the processing from step S205 to step S207 is performed using each receivable logic unit in step S204. Are performed sequentially. In step S205, the event distribution logic unit 302 acquires the event distribution procedure 311 from all receivable context extraction logic units 303. Here, the event distribution procedure 311 is a program for determining which processing task in the processing task group 310 of the context extraction logic unit 303 is to receive the received event.
In step S206, the event distribution procedure 311 is executed to determine a processing task in the processing task group 310 of the context extraction logic unit 303 to be distributed. Thereby, a delivery destination is determined.
In step S207, the received event is distributed to the processing task. Thereby, the sensor event is distributed to the distribution destination.

  On the other hand, if there is no processing task determined as the delivery destination in the processing task group 310 of the context extraction logic unit 303 in step S203, the received event is discarded or the processing task is newly generated and generated. The reception event is distributed to the processing task. Which method is to be adopted can be determined by the event distribution procedure 311.

  The context extraction logic unit 303 illustrated in FIG. 3 acquires a sensor event from the event distribution logic unit 302 and outputs an event distribution procedure 311 to the event distribution logic unit 302.

  FIG. 7 is a configuration example of the context extraction logic unit 303. The context extraction logic unit 303 stores a processing task group 310, an event distribution procedure 311, a context detection procedure group 312, and a context-event correspondence table 313. The event distribution procedure 311 defines an event distribution rule used when the event distribution logic unit 302 determines a processing task that is an event distribution destination. The context-event correspondence table 313 stores context events corresponding to state changes (hereinafter referred to as contexts).

  The context detection procedure group 312 is a set of programs describing how the processing task in the processing task group 310 analyzes the received sensor event and detects the context. The context detection procedure is preferably defined for each sensor type that can be received by the context extraction logic unit 303, but the definition method is not limited to this. The context-event correspondence table 313 includes an identifier of a context detected by the processing task of the processing task group 310 and context event information corresponding to the context. For example, in the case of context identifier # 0001, the context event information is “temperature is above the upper limit”, and in context identifier # 0002, the context event information is “temperature is above the lower limit”. The context event information includes information related to the configuration format and generation of the context event.

  The processing task group 310 includes one or more processing tasks that execute actual context extraction processing. The processing task receives a sensor event distributed from the event distribution logic unit 302 and uses the program 312 that defines the context detection procedure group 312 held by the context extraction logic unit 303 to analyze the sensor event, It has a function to generate and send the context event. The processing task has a processing task identifier to distinguish it from other processing tasks in the processing task group 310. Each processing task is determined by the description of the event distribution procedure 311. For example, when an event distribution procedure 311 that defines an event distribution rule is described to be distributed to a processing task in area code units, the processing task is prepared for each area code.

FIG. 8 shows an implementation flow of the context extraction logic unit 303.
In step S <b> 301, the processing tasks constituting the processing task group 310 receive the sensor event distributed from the event distribution logic unit 302. Determine the sensor type of the sensor event.
In step S302, after determining the sensor type of the sensor event, the processing task acquires a context detection procedure corresponding to the determined sensor type.
In step S303, the processing task performs an analysis process using the context detection procedure. Here, when the processing task includes a local storage area for storing its own state, it is preferable to use the local storage area included in the processing task for analysis processing, but the present invention is not limited thereto.
In step S304, it is determined whether a context is detected from the result of the analysis process. As a result of the analysis processing, when a state change is confirmed in the analysis target, the processing task is regarded as having detected the context. The detected context has information called a context type for identifying the type of context.
If a context is detected from the result of the analysis process in step S304, in step S305, context event information corresponding to the context is acquired from the context-event correspondence table 313 using the context type of the context as a key.
In step S306, a context event corresponding to the context event information is generated based on the context event information.
In step S307, the generated context event is transmitted to the event distribution logic unit 302. The context event is an event necessary for the service processing logic unit 304 shown in FIG. 3 to start service processing, and has information on the detected context. A description example of the context event is shown in FIG.

  The service processing logic unit 304 shown in FIG. 3 receives the context event distributed from the event distribution logic unit 302, performs various service processes, and executes the push facility 305.

  FIG. 10 is a configuration example of the service processing logic unit 304. The service processing logic unit 304 stores a processing task group 314, an event distribution procedure 315, and a service processing procedure group 316. Each service processing logic unit 304 has a unique service processing logic unit identifier for distinguishing from other service processing logic units 304.

The event distribution procedure 315 defines an event distribution rule. For example, it has a function equivalent to the event distribution procedure 311 in the context extraction logic unit 303.
The service processing procedure group 316 is a set of programs that define service processing rules. The service processing procedure defines, for example, how a processing task in the processing task group 314 processes a received context event. This program is preferably defined for each context type, but the definition method is not limited to this.

  The processing task group 314 performs service processing corresponding to the context type of the context event distributed from the event distribution logic unit 302. The processing task in the processing task group 314 has the same function as the processing task group 310 in the context extraction logic unit 303 except that the service processing is executed using the service processing procedure group 316.

FIG. 11 shows an implementation flow of the service processing logic unit 304.
In step S <b> 401, the processing tasks constituting the processing task group 314 receive the context event distributed from the event distribution logic unit 302.
In step S402, after the processing task determines the context type of the context event, the service processing procedure corresponding to the context type is acquired from the service processing procedure group 316.
In step S403, the processing task executes the service processing procedure group 316 to perform service processing.
Step S404 executes the push facility 305.

  Here, when the processing task includes a local storage area for storing its own state, it is preferable to use the local storage area included in the processing task for service processing, but the present invention is not limited thereto. After completing the service processing, the processing task executes the push facility 305 by passing the service processing logical part identifier, the identifier of the processing task, and the result of the service processing.

  The push facility 305 shown in FIG. 3 distributes the service processing result of the service processing logic unit 304 to the push-type user yyy registered in advance.

FIG. 12 shows an implementation flow of the push facility 305.
In step S501, the push facility 305 receives the service processing logic unit identifier, the identifier of the processing task, and the service processing result from the processing task of the processing task group 314 of the service processing logic unit 304.
In step S502, it is determined from the service processing logic unit database 309 whether the push function of the service processing logic unit is enabled or disabled using the service logic unit identifier as a key. Here, the enable / disable setting of the push function can be arbitrarily set by the administrator.
If the push function is valid in step S502, the push facility 305 acquires the push target user information from the push database 306 using the identifier of the processing task as a key in step S503.
In step S503, when the push function is valid, the push facility 305 uses the identifier of the processing task in FIG. 13 as a key to identify an identifier (push user ID) corresponding to the push target user information from the push database 306 in FIG. ) To get. FIG. 13 shows a configuration example of the push database. The push target user information includes a push target user name, a service processing result distribution unit (push unit, etc.), a distribution destination address (push address), and the like.
In step S504, it is determined whether there is a push target user.
When there is a push target user in step S504, in step S505, the push facility 305 uses the push target user information to distribute the result of the service process to the push target user.

  On the other hand, if the push function is not valid in step S502, or if there is no push target user in step S504, the implementation of the push facility 305 ends.

  The management control unit 307 illustrated in FIG. 3 includes a function for receiving an add command, a delete command, and a change command of the context extraction logic unit 303 or the service processing logic unit 304 from the administrator xxx, and the context extraction logic unit 303 or the service processing logic unit. It has a function of adding / deleting / changing 304.

FIG. 14 shows an execution sequence for adding the service processing logic unit 304. The management control unit 307 acquires an addition command that instructs to add the service processing logic unit 304. The acquisition of the additional command is received from the administrator xxx. The add command includes an add flag, a logical part identifier, an operation status, a push delivery flag, and service specific information.
The management control unit 307 searches the service processing logical unit database 309 using the identifier of the service processing logical unit included in the addition command as a key. FIG. 15 shows a configuration example of the service processing logic unit database 309. The service processing logic unit database 309 stores the service processing logic unit identifier and the meta information of the service processing logic unit such as operation status, receivable event type, presence / absence of push delivery, and the like. If the information corresponding to the identifier does not exist in the service processing logic unit database 309, the management control unit 307 determines that the service processing logic unit 304 specified by the add command can be added, and gives the administrator xxx Reply to that effect.
After receiving the response that the service processing logic unit 304 can be added, the administrator xxx transmits the component of the service processing logic unit 304 to the management control unit 307. The component includes an event distribution procedure 315 and a service processing procedure group 316 of the service processing logic unit 304.
After receiving the component of the service processing logic unit 304, the management control unit 307 uses the component to add the service processing logic unit 304 to the push type service function unit 108, and then stores it in the service processing logic unit database 309. Stores information on the additional command of the service processing logic unit 304.

  FIG. 16 shows an execution sequence for deleting the existing service processing logic unit 304. The management control unit 307 receives a deletion command including information related to the service processing logic unit 304 to be deleted from the administrator xxx. FIG. 17 shows a format configuration example of the delete command. After receiving the deletion command, the management control unit 307 searches the service processing logical unit database 309 using the identifier of the service processing logical unit included in the deletion command as a key. When there is information corresponding to the identifier, the management control unit 307 determines that the service processing logic unit 304 specified by the deletion command can be deleted, deletes the service processing logic unit 304, The information on the service processing logic unit is deleted from the service processing logic unit database 309.

FIG. 18 shows an execution sequence for changing the meta information of the existing service processing logic unit 304. An implementation sequence for changing the meta information of the existing service processing logic unit 304 will be described. In this case, the management control unit 307 receives a change command including information related to the service processing logic unit 304 that changes the meta information from the administrator xxx. The change command includes, for example, a change flag, a logical part identifier, an operation status, a push delivery flag, and service specific information. After receiving the change command, the management control unit 307 searches the service processing logic unit database 309 using the identifier in the change command as a key. If there is information corresponding to the identifier, the management control unit 307 determines that the service processing logic unit 304 specified by the change command can be changed, and the management processing unit 307 stores the information in the service processing logic unit database 309. The information of the service processing logic unit 304 is updated based on the information included in the change command.
(Embodiment 4)
FIG. 19 shows an embodiment of cooperation between the push type service function unit 108 and the pull type service function unit 107. The push type service function unit 108 includes a push history database 501 that stores information related to push delivery in addition to the configuration of the push type service function unit 108 described with reference to FIG. By providing the push history database 501, the cooperation between the push type service function unit 108 and the pull type service function unit 107 can be improved. In the present embodiment, the configuration of the push type service function unit 108 is the same as described above except for the push history database 501, the context extraction logic unit 303, and the push facility 305, and thus description thereof is omitted.

  The pull type service function unit 107 includes a sensor database 401, a processing unit 402, and a transmission / reception unit 403. First, an example of a processing sequence in the pull type service will be described with reference to FIG. The sensor database 401 stores data information sequentially transferred from the sensor data collection function unit 106. On the other hand, the transmission / reception unit 403 receives a request from the pull-type user zzz, and transfers a service request from the pull-type user zzz to the processing unit 402. Based on the processing request received by the transmission / reception unit 403, the processing unit 402 requests data information necessary for processing from the sensor database 401 (hereinafter referred to as sensor DB), and extracts the necessary data information. Information processing such as graph creation and statistical processing is performed based on the extracted data information and a service request by the pull type user, and the information is distributed to the pull type user via the transmission / reception unit 403.

  When realizing the cooperation between the pull-type service function unit 107 and the push-type service function unit 108, information on push delivery held in the push history database 501 and data information corresponding to the push delivery held in the sensor database 401 For association, the context event information in the context event correspondence table 313 provided in the context extraction logic unit 303 includes a list of sensor type identifiers related to occurrence of the corresponding context. The processing tasks constituting the processing task group 314 included in the service processing logic unit 304 receive, in addition to the identifier of the service processing logic unit 304, the identifier of the processing task, and the result of the service processing, when executing the push facility 305. A list of sensor type identifiers included in the selected context event is given as an argument. The push facility 305 pushes the information about the push delivery and the list information of the received sensor type identifier in addition to the function of pushing the service processing result of the service processing logic unit 304 to the push type user yyy. It has a function of storing in the history database 501. FIG. 21 shows a configuration example of a push history database (hereinafter referred to as push history DB) 501.

FIG. 22 shows an implementation flow of the push facility 305 in this embodiment.
In step S601, the meta information of the service processing logic unit 304 is acquired from the service processing logic unit database 309. In step S602, it is determined whether the push function is valid.

  If it is determined in step S602 that the push function is valid, in step S603, the push facility 305 acquires information on the notification means with the user from the processing task identifier of the provided processing task group 314. In step S604, it is determined whether the corresponding user exists. For example, it is referred to whether it is registered in the push database 306.

  If it is determined in step S604 that there is a user, in step S605, the push facility 305 delivers the provided processing result to the user. In step S606, the push facility 305 determines whether the push history function is valid. For example, the push history database 501 is inquired whether it can be used.

  If it is determined in step S606 that the push history function is valid, in step S607, the push facility 305 stores the sensor type identifier, the push history information, and the like as the distribution result in the push history database 501.

  On the other hand, if it is determined in step S602 that the push function is invalid, or if it is determined in step S604 that there is no user, or if it is determined that the push history function is not valid in step S606, the implementation flow of the push facility 305 is performed. Exit.

Next, an embodiment in which the pull type service function unit 107 cooperates with the push type service function unit 108 will be described. FIG. 23 shows an example of a data transfer sequence of the sensor data integration processing system 105 according to this embodiment.
A push history request is transmitted from the terminal zzz of the pull type user. The information stored in the push history DB 501 receives a request by the transmission / reception unit 403 in the pull-type service function unit 107 every time a push history request is generated, and transfers the push history request to the processing unit 402.
The processing unit 402 transmits a push history request to the push history DB 501 and acquires requested push history information (including a sensor type identifier).
The processing unit 402 requests data information corresponding to the push history information to the sensor DB 401 using the date and time and the sensor type identifier included in the push history information as keys, and obtains data information corresponding to the push history information.
The processing unit 402 combines the obtained push history information and data information, and performs processing such as statistics and analysis. The processing unit 402 performs information processing by combining the push history and sensor information in response to a request from the pull-type user zzz. Thereby, the processing result of the data information based on the push history can be obtained.
The transmission / reception unit 403 distributes the processing result of the processing unit 402 to the pull type user. According to the present embodiment, it is possible to distribute data information based on a push history obtained by performing information processing by combining push history and sensor information even in a request from a pull-type user zzz.

  In the third embodiment, the context extraction logic unit 303 included in the push type service function unit 108, when performing the analysis process, performs the analysis process using only the received sensor event, the received sensor event, There has been a method of performing analysis processing by combining local storage areas possessed by processing tasks constituting the processing task group 310. As shown in the fourth embodiment, when the push type service function unit 108 cooperates with the pull type service function unit 107, when performing the analysis processing in the third embodiment, the sensor database 401 constituting the pull type service function unit is used. By obtaining and using necessary information, more detailed analysis processing is realized.

  The present invention can provide a sensor network that can easily collect various information such as disaster support, security, weather forecast, action support, etc., and can respond to various service requests of users. It can contribute to the advancement of the service function of the telephone system.

1 is a schematic configuration diagram of an integrated processing system for a sensor network according to Embodiment 1. FIG. It is an example of a data format in a sensor network. 2 is a configuration example of a push-type service function unit 108. It is an example of the implementation flow of the event conversion logic part 301. FIG. It is a description example of a sensor event. 5 is an execution flow of an event distribution logic unit 302. 3 is a configuration example of a context extraction logic unit 303. It is an execution flow of the context extraction logic unit 303. It is a description example of a context event. 3 is a configuration example of a service processing logic unit 304. 5 is an execution flow of a service processing logic unit 304. It is an execution flow of the push facility 305. It is a structural example of a push database. This is an execution sequence for adding a new service processing logic unit 304. It is an example of a structure of the service process logic part database 309. FIG. This is an execution sequence for deleting an existing service processing logic unit 304. It is a format structural example of a deletion command. This is an execution sequence for changing the meta information of the existing service processing logic unit 304. It is an Example of cooperation between a push type | mold service function part and a pull type | mold service function part. It is an example of a processing sequence in a pull type service. 5 is a configuration example of a push history database 501. It is an implementation flow of the push facility 305 in this embodiment. 4 is an example of a data transfer sequence of the sensor data integration processing system 105.

Explanation of symbols

DESCRIPTION OF SYMBOLS 100 Sensor network 101 Sensor node 102 Communication node 103 Reception interface 104 Network abstraction function part 105 Sensor data integrated processing system 106 Sensor data collection function part 107 Pull type service function part 108 Push type service function part 110, 111 Communication network 301 Event conversion Logic unit 302 Event distribution logic unit 303 Context extraction logic unit 304 Service processing logic unit 305 Push facility 306 Push database 307 Management control unit 308 Context extraction logic unit database 309 Service processing logic unit database 310 Processing task group 311 Event distribution procedure 312 Context detection Procedure group 313 Context event correspondence table 314 Processing task group 315 b Event distribution procedure 316 Service processing procedure group 320 Event conversion correspondence table 401 Sensor database 402 Processing function unit 403 Transmission / reception unit 501 Push history database

Claims (3)

A network abstraction function unit that acquires data information detected by a sensor via an ad hoc network, converts the data information into a predetermined data format, and transmits the data abstraction function unit.
A sensor data collection function unit for collecting data information transmitted by the network abstraction function unit;
The push type service function unit that acquires the data information collected by the sensor data collection function unit, and distributes the content of the data information and a data distribution service predetermined for each user in a push type distribution form;
A pull type service function unit that acquires data information collected by the sensor data collection function unit, and distributes data distribution service predetermined for each user and data information in a pull type distribution form;
Upon receiving a push history request from a user, the pull type service function unit obtains push history information including a sensor type identifier from the push type service function unit, and from the data information collected by the sensor data collection function unit An integrated processing system for a sensor network that acquires data information corresponding to push history information and performs analysis processing based on the data information corresponding to push history information . The push type service function unit
An event conversion logic unit that acquires a sensor event corresponding to the content of the data information with reference to a predetermined event conversion table;
When acquiring a sensor event, the event distribution procedure is determined, and a context extraction logic unit that generates context event information describing a service process corresponding to the context by executing a processing task determined according to the event distribution procedure ;
The sensor network integrated processing system according to claim 1 , further comprising: a service processing logic unit that executes service processing corresponding to the context event information in units of processing tasks. The push type service function unit
An event distribution logic unit that extracts a context extraction logic unit corresponding to a sensor event with reference to a predetermined context extraction logic unit database and transmits the sensor event to the extracted context extraction logic unit is further provided.
By adding a command for adding, deleting, or changing the context event information to the context extraction logic unit database, addition, deletion, change, etc. with respect to the context event information stored in the context extraction logic unit The integrated processing system for a sensor network according to claim 1 or 2 , wherein the update is performed .

Images