WO2019159486A1 - セッション制御装置、セッション制御方法及びプログラム - Google Patents

セッション制御装置、セッション制御方法及びプログラム Download PDF

Info

Publication number
WO2019159486A1
WO2019159486A1 PCT/JP2018/043928 JP2018043928W WO2019159486A1 WO 2019159486 A1 WO2019159486 A1 WO 2019159486A1 JP 2018043928 W JP2018043928 W JP 2018043928W WO 2019159486 A1 WO2019159486 A1 WO 2019159486A1
Authority
WO
WIPO (PCT)
Prior art keywords
input
processing module
sensor
data
input data
Prior art date
Application number
PCT/JP2018/043928
Other languages
English (en)
French (fr)
Inventor
哲二 大和
泰司 吉川
Original Assignee
オムロン株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by オムロン株式会社 filed Critical オムロン株式会社
Priority to US16/962,365 priority Critical patent/US11563814B2/en
Priority to CN201880085789.1A priority patent/CN111615690B/zh
Publication of WO2019159486A1 publication Critical patent/WO2019159486A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms

Definitions

  • the present invention relates to a session control device, a session control method, and a program.
  • Patent Document 1 discloses a virtual sensor generation device that generates a virtual sensor.
  • a real sensor existing within a predetermined range is detected, and a virtual sensor is generated by using the detected real sensor (see Patent Document 1).
  • the virtual sensor as disclosed in Patent Document 1 includes, for example, a real sensor (an example of a device) and a processing module.
  • the processing module generates output data different from the input data by processing the sensing data (an example of input data) output by the actual sensor. For example, in order for a virtual sensor to function continuously, it is necessary to maintain the quality of input data to the processing module.
  • Patent Document 1 does not disclose a method for maintaining the quality of input data to the processing module.
  • the present invention has been made to solve such a problem, and an object thereof is to provide a session control device, a session control method, and a program capable of maintaining the quality of input data to the processing module. It is to be.
  • a session control apparatus configured to control a session between a processing module and a device that outputs input data to the processing module.
  • the processing module is configured to generate output data different from the input data based on at least one input data. Conditions for the quality of input data are defined for each processing module.
  • the session control device includes an extraction unit, a selection unit, and a switching unit.
  • the extraction unit is configured to extract a plurality of device candidates.
  • the selection unit is configured to select some or all devices from a plurality of device candidates.
  • the switching unit is configured to switch the device that outputs input data to the processing module to the device selected by the selection unit. Input data output from each of a plurality of device candidates satisfies the above conditions.
  • this session control device a device that outputs input data that satisfies quality-related conditions is extracted as a candidate, and a device that outputs input data to the processing module is switched to one of the extracted devices. Therefore, according to this session control apparatus, data satisfying the quality condition is input from the device after switching, so that the quality of the input data to the processing module can be maintained.
  • the switching unit selects a device that outputs input data to the processing module when the input data input to the processing module does not satisfy the above condition. Configured to switch to a device.
  • the device that outputs the input data to the processing module is switched to the device that outputs the input data that satisfies the quality-related condition. It is done. Therefore, according to this session control apparatus, since the input of data that does not satisfy the quality-related conditions is stopped, the quality of the input data to the processing module can be maintained.
  • the device is a sensor.
  • the input data is sensing data generated by the sensor.
  • the processing module is configured to generate output data based on a plurality of input data.
  • a virtual sensor is formed by the processing module and a device that outputs input data to the processing module.
  • the session control device is configured to control a session between the processing module and a storage that holds a data set to be input to the processing module.
  • the data set is composed of a plurality of data.
  • the processing module is configured to generate output data different from the input data based on at least one input data. Conditions for the quality of input data are defined for each processing module.
  • the session control device includes an extraction unit, a selection unit, and a switching unit.
  • the extraction unit is configured to extract a plurality of data set candidates.
  • the selection unit is configured to select a part or all of the data sets from a plurality of data set candidates.
  • the switching unit is configured to switch the data set input to the processing module to the data set selected by the selection unit. Data included in each of a plurality of data set candidates satisfies the above conditions.
  • this session control device a data set that satisfies the quality-related conditions is extracted as an input candidate, and the data set to be input to the processing module is switched to one of the extracted data sets. Therefore, according to this session control apparatus, since the data set that satisfies the quality condition is input, the quality of the input data to the processing module can be maintained.
  • a session control method controls a session between a processing module and a device that outputs input data to the processing module.
  • the processing module is configured to generate output data different from the input data based on at least one input data.
  • Conditions for the quality of input data are defined for each processing module.
  • the selection unit selects a step of extracting a plurality of device candidates, a step of selecting some or all of the plurality of device candidates, and a device that outputs input data to the processing module. Switching to a device. Input data output from each of a plurality of device candidates satisfies a condition.
  • a device that outputs input data that satisfies quality-related conditions is extracted as a candidate, and a device that outputs input data to the processing module is switched to one of the extracted devices. Therefore, according to this session control method, since the data satisfying the quality condition is input from the device after switching, the quality of the input data to the processing module can be maintained.
  • a program causes a computer to execute a process for controlling a session between a processing module and a device that outputs input data to the processing module.
  • the processing module is configured to generate output data different from the input data based on at least one input data. Conditions for the quality of input data are defined for each processing module.
  • the program includes a step of extracting a plurality of device candidates, a step of selecting some or all of the plurality of device candidates, and a device that outputs input data to the processing module as the device selected by the selection unit.
  • the step of switching is configured to be executed by a computer. Input data output from each of a plurality of device candidates satisfies a condition.
  • this program When this program is executed by the computer, a device that outputs input data that satisfies the quality-related conditions is extracted as a candidate, and a device that outputs input data to the processing module is switched to one of the extracted devices. Therefore, according to this program, data satisfying the quality condition is input from the device after switching, so that the quality of the input data to the processing module can be maintained.
  • FIG. 4 is a diagram for explaining an overview of a session control device 70.
  • FIG. It is a figure which shows an example of a sensor network system. It is a figure which shows an example of the hardware constitutions of a virtual sensor management server. It is a figure which shows an example of input candidate DB. It is a figure which shows an example of processing module side metadata DB. It is a figure which shows an example of the relationship of each software module implement
  • this embodiment an embodiment according to one aspect of the present invention (hereinafter, also referred to as “this embodiment”) will be described in detail with reference to the drawings.
  • the same or corresponding portions are denoted by the same reference numerals and description thereof will not be repeated.
  • the present embodiment described below is merely an example of the present invention in all respects.
  • Various improvements and modifications can be made to the present embodiment within the scope of the present invention. That is, in carrying out the present invention, a specific configuration can be appropriately adopted according to the embodiment.
  • FIG. 1 is a diagram for describing an overview of session control device 70 according to the present embodiment.
  • the processing module 150 has a plurality of input ports, and sensing data (an example of input data) output by the actual sensor 12 (an example of a device) is input to each input port.
  • the processing module 150 is configured to generate output data different from the input data based on the input data. That is, a so-called virtual sensor is formed by the processing module 150 and the actual sensor 12 (input sensor) that outputs input data to the processing module 150.
  • the virtual sensor is a sensor module that outputs, as sensing data, an observation result of an object different from the object observed by the input sensor based on sensing data generated by observing the object by the input sensor. The virtual sensor will be described in detail later.
  • the virtual sensor In order to make the virtual sensor function continuously, it is necessary to maintain the quality of the input data to the processing module 150. That is, if the quality of the input data to the processing module 150 is reduced, the virtual sensor may not be able to perform a desired function.
  • the session control device 70 is configured to extract in advance candidates for the actual sensor 12 that outputs input data to the processing module 150 (hereinafter also referred to as “input sensor candidates”). Specifically, the session control device 70 previously extracts the actual sensor 12 suitable as an input sensor of the processing module 150 from the plurality of actual sensors 12 that can communicate via the network, and inputs the extracted actual sensor 12. It is configured to be managed on a candidate DB (database) 140. More specifically, each real sensor 12 managed on the input candidate DB 140 can output data that satisfies the quality condition of the input data of the processing module 150.
  • the session control device 70 selects some or all of the actual sensors 12 from the plurality of actual sensors 12 managed on the input candidate DB 140, and selects an input sensor of the processing module 150 as necessary.
  • the actual sensor 12 is switched to. Therefore, according to the session control device 70, since the input data satisfying the quality condition is output from the real sensor 12 after switching, the quality of the input data to the processing module 150 can be maintained.
  • a specific configuration and operation will be described in order.
  • FIG. 2 is a diagram showing an example of the sensor network system 10 including the session control device 70 (FIG. 1) according to the present embodiment.
  • the sensor network system 10 includes a sensor network unit 14, a virtual sensor management server 100, an SDTM (Sensing Data Trading Market) server 200, and an application server 300.
  • the session control device 70 is realized by the virtual sensor management server 100 and the SDTM server 200.
  • the sensor network unit 14, the virtual sensor management server 100, the SDTM server 200, and the application server 300 are connected to each other via the Internet 15 so that they can communicate with each other.
  • the number of each component (virtual sensor management server 100, SDTM server 200, application server 300, sensor network adapter 11, actual sensor 12, etc.) included in the sensor network system 10 is not limited to that shown in FIG. .
  • sensing data generated by a sensing device can be distributed.
  • sensing data generated by the real sensor 12 can be distributed to the virtual sensor management server 100, and sensing data generated by the virtual sensor can be distributed to the application server 300.
  • the sensor network unit 14 includes, for example, a plurality of sensor network adapters 11.
  • a plurality of actual sensors 12 are connected to each of the plurality of sensor network adapters 11, and each actual sensor 12 is connected to the Internet 15 via the sensor network adapter 11.
  • the real sensor 12 is configured to obtain sensing data by observing the target.
  • the actual sensor 12 includes, for example, an image sensor (camera), a temperature sensor, a humidity sensor, an illuminance sensor, a force sensor, a sound sensor, an RFID (Radio Frequency IDentification) sensor, an infrared sensor, a posture sensor, a rainfall sensor, a radioactivity sensor, and a gas sensor. Any type of sensor may be used.
  • the actual sensor 12 does not necessarily need to be a fixed type, and may be a mobile type such as a mobile phone, a smartphone, and a tablet.
  • each real sensor 12 does not necessarily need to be comprised with the single sensing device, and may be comprised with the some sensing device.
  • the actual sensor 12 may be installed for any purpose. For example, for factory FA (Factory Automation) and production management, urban traffic control, environmental measurement such as weather, health care, crime prevention, etc. It may be installed.
  • each sensor network adapter 11 is disposed at a separate (distant) location, and each actual sensor 12 connected to each sensor network adapter 11 is disposed at the same (near) location. These arrangement locations are not limited to this.
  • Each application server 300 (300A, 300B) is configured to execute an application that uses sensing data, and is realized by, for example, a general-purpose computer.
  • the application server 300 acquires necessary sensing data via the Internet 15.
  • the virtual sensor management server 100 is a server for realizing a virtual sensor.
  • a plurality of processing modules 150, an input candidate management module 110, an input quality check module 120, and a session control module 130 are realized, an input candidate DB 140, and processing module side metadata.
  • the DB 160 is managed.
  • Each of the plurality of processing modules 150, the input candidate management module 110, the input quality check module 120, and the session control module 130 is, for example, a software module.
  • the processing module 150 includes at least one input port, and is configured to generate output data different from the input data based on the input data input to each input port.
  • the processing module 150 may be configured to output data indicating the number of persons existing in the room based on input data (voice data) output by a sound sensor arranged in the room.
  • a virtual sensor that detects the number of people in the room can be realized by the processing module 150 and the real sensor 12 (sound sensor).
  • the input candidate management module 110 is configured to manage the candidates (input sensor candidates) of the actual sensors 12 that output input data to the processing module 150.
  • the input quality check module 120 is configured to check the quality of input data to the processing module 150.
  • the session control module 130 is configured to control a session between the processing module 150 and the actual sensor 12.
  • the session control module 130 selects an input sensor to the processing module 150 as an input sensor candidate extracted in advance. Switch to one. Details of each software module and each database will be described later.
  • the SDTM server 200 is a server for realizing distribution of sensing data in the sensor network system 10.
  • an input candidate search module 210 and a data flow control module 220 are realized, and the sensor side metadata DB 230 is managed.
  • Each of the input candidate search module 210 and the data flow control module 220 is, for example, a software module.
  • the input candidate search module 210 is configured to search for input sensor candidates of the processing module 150 in response to a request from the virtual sensor management server 100 (input candidate management module 110).
  • the data flow control module 220 is configured to control distribution of sensing data from the real sensor 12 to the processing module 150 in response to a request from the virtual sensor management server 100 (session control module 130). Details of each software module and database will be described later.
  • FIG. 3 is a diagram illustrating an example of a hardware configuration of the virtual sensor management server 100.
  • the virtual sensor management server 100 is realized by, for example, a general-purpose computer.
  • the virtual sensor management server 100 includes a control unit 170, a communication I / F (interface) 190, and a storage unit 180, and each component is electrically connected via a bus 195. Yes.
  • the control unit 170 includes a CPU (Central Processing Unit) 172, a RAM (Random Access Memory) 174, a ROM (Read Only Memory) 176, and the like, and is configured to control each component according to information processing. .
  • CPU Central Processing Unit
  • RAM Random Access Memory
  • ROM Read Only Memory
  • the communication I / F 190 communicates with external devices (for example, the SDTM server 200, the application server 300, and the sensor network unit 14 (FIG. 2)) provided outside the virtual sensor management server 100 via the Internet 15. It is configured.
  • the communication I / F 190 is composed of, for example, a wired LAN (Local Area Network) module or a wireless LAN module.
  • the storage unit 180 is an auxiliary storage device such as a hard disk drive or a solid state drive.
  • the storage unit 180 is configured to store, for example, the input candidate DB 140, the processing module side metadata DB 160, and the control program 181.
  • FIG. 4 is a diagram illustrating an example of the input candidate DB 140.
  • input candidate DB 140 is a database that manages input sensor candidates of processing module 150.
  • input sensor candidates are managed for each input port of each processing module 150.
  • the first candidate is “sensor B1”
  • the second candidate is “sensor B2”
  • the third candidate is “sensor B3”.
  • the number of input sensor candidates managed for each input port is not necessarily three, and may be less than three, or may be four or more.
  • the update process of the input candidate DB 140 is repeatedly executed at a predetermined cycle. For example, when the specifications of the actual sensor 12 included in the sensor network unit 14 are changed, the input sensor candidates listed in the input candidate DB 140 are changed.
  • FIG. 5 is a diagram illustrating an example of the processing module side metadata DB 160.
  • the processing module side metadata DB 160 is a database that manages metadata indicating conditions of input data of the processing module 150.
  • the metadata of each processing module 150 realized in the virtual sensor management server 100 is registered in the processing module side metadata DB 160 in advance.
  • metadata is managed for each input port of each processing module 150.
  • Processing module side metadata includes, for example, “basic conditions” and “quality conditions”.
  • the “basic condition” is a basic condition required for the actual sensor 12 that outputs input data (sensing data), and includes, for example, “type”, “observation target”, and “installation location”.
  • the “type” is the type of the actual sensor 12, and for example, each of the temperature sensor, the illuminance sensor, and the camera is an example of the “type”.
  • the “observation object” is an object observed by the actual sensor 12, and each of the outside temperature, the station ticket gate, the illuminance, and the temperature is an example of the “observation object”.
  • the “installation location” is a location where the actual sensor 12 is installed. For example, each of P1, P2, and P3 is an example of “installation location” (note that each of P1, P2, and P3 is, for example, It shall indicate a specific place such as “Kyoto Station”).
  • Quality condition is a condition related to the quality of input data (sensing data), and includes, for example, “outlier condition”, “data missing frequency condition”, and “manufacturer condition”.
  • sensor condition conditions “sensor installation conditions”, “sensor maintenance history conditions”, “data specification conditions”, “data resolution conditions”, and the like may be included in the “quality conditions”.
  • the “outlier condition” is a condition regarding the probability that the input data output by the actual sensor 12 will be an outlier.
  • the “data missing frequency condition” is a condition related to a probability that data is not input at a timing when data should be input to the input port.
  • Manufacturing conditions are conditions relating to the manufacturer of the actual sensor 12 that outputs input data.
  • the “sensor state condition” is a condition related to the state of the actual sensor 12 that outputs input data. For example, “permitted as long as the sensor is operating”, “a part of the sensor has deteriorated to a predetermined level. “Unacceptable in case” is “sensor condition”.
  • Sensor installation conditions are conditions related to the installation of the actual sensor 12 that outputs input data. For example, “Sensor is not allowed when the sensor is displaced from the initial installation position”, “Sensor is dropped from the initial installation position” “Acceptable as long as it is not” is “sensor installation condition”.
  • the “sensor maintenance history condition” is a condition related to the maintenance history of the actual sensor 12 that outputs the input data.
  • the “data specification condition” is a condition related to the specification of input data.
  • the “data resolution condition” is a condition related to the resolution of input data.
  • the control program 181 is a control program for the virtual sensor management server 100 executed by the control unit 170.
  • the processing module 150, the input candidate management module 110, the input quality check module 120, the session control module 130 (FIG. 2), and the like may be realized by the control unit 170 executing the control program 181.
  • the control program 181 is expanded in the RAM 174.
  • the control unit 170 controls each component by interpreting and executing the control program 181 expanded in the RAM 174 by the CPU 172.
  • each software module realized by the control unit 170 according to the control program 181 will be described.
  • FIG. 6 is a diagram illustrating an example of the relationship between the software modules realized by the control unit 170.
  • each of the processing module 150, the input candidate management module 110, the input quality check module 120, and the session control module 130 is realized by the control unit 170.
  • the input candidate management module 110 extracts the actual sensor 12 suitable for the input sensor of the processing module 150 in cooperation with the SDTM server 200 while referring to the processing module side metadata DB 160.
  • the extracted input sensor candidates are managed on the input candidate DB 140.
  • the input quality check module 120 checks whether or not the quality of the data currently input to the processing module 150 satisfies the condition of the input data of the processing module 150 by referring to the processing module side metadata DB 160.
  • the session control module 130 determines whether it is necessary to switch the input sensor of the processing module 150 based on the check result by the input quality check module 120. When it is determined that the input sensor needs to be switched, the session control module 130 switches the input sensor to one of the real sensors 12 managed in the input candidate DB 140.
  • FIG. 7 is a diagram illustrating an example of a detailed configuration of the input candidate management module 110.
  • the input candidate management module 110 includes a metadata acquisition unit 111, a use side data catalog generation unit 112, a priority order assignment unit 113, and an input candidate DB update unit 114. Note that extraction of input sensor candidates by the input candidate management module 110 is performed for each input port of the processing module 150. Extraction of input sensor candidates for each input port may be performed in parallel or sequentially. In the following description, each module will be described after paying attention to one input port of the processing module 150.
  • the metadata acquisition unit 111 acquires the processing module side metadata 161 (FIG. 1) associated with the input port from which the input sensor candidate is extracted from the processing module side metadata DB 160.
  • the usage side data catalog generation unit 112 generates a usage side data catalog based on the processing module side metadata 161 acquired by the metadata acquisition unit 111.
  • the use side data catalog is a catalog indicating the attributes of the real sensor 12 required by the use side (virtual sensor management server 100).
  • the usage-side data catalog includes input data conditions indicated by the processing module-side metadata 161. For example, the usage-side data catalog includes “basic conditions” and “quality conditions” of the input data described above.
  • the user-side data catalog generated by the user-side data catalog generator 112 is transmitted to the SDTM server 200 via the communication I / F 190.
  • the actual sensor 12 that satisfies the conditions indicated in the use side data catalog is extracted.
  • Information that can identify the extracted actual sensor 12 (hereinafter also referred to as “actual sensor information”) is received via the communication I / F 190.
  • the actual sensor information includes, for example, an IP address assigned to the actual sensor 12 (information indicating the location of the actual sensor 12 on the Internet 15) and information indicating the attribute of the actual sensor 12.
  • the priority level assigning unit 113 gives priority to each real sensor 12 when a plurality of real sensor information is received.
  • the priority level assigning unit 113 may give priority levels to the real sensors 12 from any viewpoint. For example, when the “outlier value condition” is the most important among the conditions included in the use side data catalog, the priority level assigning unit 113 determines that the actual sensor 12 has a low outlier occurrence rate (outlier occurrence rate). Higher priority may be given.
  • the input candidate DB update unit 114 updates the input candidate DB 140 (FIG. 4) according to the priority order given by the priority order assigning unit 113. Thereby, in the input candidate DB 140, the actual sensors 12 that satisfy the conditions indicated in the user data catalog are managed in advance as input sensor candidates.
  • FIG. 8 is a diagram illustrating an example of a detailed configuration of the input quality check module 120.
  • the input quality check module 120 includes a data filtering unit 121, a metadata check unit 122, and an accident check unit 123.
  • the input data output by the actual sensor 12 includes sensing data and metadata associated with the sensing data (hereinafter also referred to as “input metadata”).
  • the sensing data is data generated by the actual sensor 12 observing the target.
  • the input metadata is data indicating the attribute of sensing data generated by the actual sensor 12.
  • FIG. 9 is a diagram illustrating an example of the input metadata 60 associated with the sensing data.
  • the input metadata 60 includes “basic attributes” and “quality attributes”.
  • the “basic attribute” is a basic attribute of the actual sensor 12 that outputs input data, and includes, for example, “type”, “observation target”, and “installation location”.
  • the “quality attribute” is an attribute related to the quality of the sensing data. For example, “outlier occurrence rate”, “data missing occurrence rate”, “manufacturer” of the actual sensor 12 and the like are included in the “quality attribute”. .
  • “sensor state attribute”, “sensor installation attribute”, “sensor maintenance history attribute”, “data specification attribute”, “data resolution attribute”, and the like may be included in the “quality attribute”.
  • the “outlier occurrence rate” that can be included in the input metadata 60 is not predetermined at the time of shipment of the actual sensor 12 or the like, but changes as the actual sensor 12 continuously operates.
  • the “outlier occurrence rate” is low.
  • the “outlier occurrence rate” increases as the actual sensor 12 operates for a long period of time.
  • the actual sensor 12 for example, it is monitored whether or not the sensing data corresponds to an outlier, and the outlier occurrence rate in a predetermined period is sequentially updated. Then, the updated outlier occurrence rate is associated with sensing data as input metadata 60.
  • “outlier occurrence rate” for example, “data missing occurrence rate”, “sensor state attribute”, “sensor maintenance history attribute”, and the like may change from moment to moment.
  • the data filtering unit 121 separates the input data output by the actual sensor 12 into sensing data and input metadata. Sensing data is output to the processing module 150, and input metadata is output to the metadata check unit 122.
  • the metadata check unit 122 acquires the processing module side metadata 161 (FIG. 1) associated with the input port to which data is input from the processing module side metadata DB 160 (FIG. 5). The metadata check unit 122 determines whether the sensing data satisfies the input data condition based on the processing module side metadata 161 and the input metadata. For example, the metadata check unit 122 determines that the sensing data satisfies the condition of the input data when each condition indicated by the processing module side metadata 161 satisfies each attribute indicated by the input metadata.
  • the metadata check unit 122 determines whether the quality of the sensing data satisfies the quality condition of the input data based on the processing module side metadata 161 and the input metadata. For example, when the quality attribute indicated by the input metadata satisfies each quality condition indicated by the processing module side metadata 161, the metadata check unit 122 determines that the quality of the sensing data satisfies the quality condition of the input data. judge.
  • the accident check unit 123 determines whether any accident has occurred in the input data based on the metadata associated with the sensing data. For example, the accident check unit 123 may cause the input metadata to be “garbled”, if the input metadata has a higher probability of “outlier” than the “outlier occurrence rate”, When the omission frequency is higher than the “data omission occurrence rate”, it is determined that an accident has occurred in the input data.
  • the input metadata is input to the processing module 150.
  • the input quality check result based on the check result by each of the metadata check unit 122 and the accident check unit 123 is input to the session control module 130.
  • the input quality check result is determined to be “good” when it is determined that the quality of the sensing data satisfies the quality condition of the input data and no accident has occurred in the input data.
  • the input quality check result is determined to be “bad” when it is determined that the quality of the sensing data does not satisfy the quality condition of the input data, or when it is determined that some accident has occurred in the input data.
  • FIG. 10 is a diagram illustrating an example of a detailed configuration of the session control module 130.
  • the session control module 130 is a module that controls session switching between the processing module 150 and the actual sensor 12. Switching the session between the processing module 150 and the actual sensor 12 means switching the input sensor of the processing module 150 to another actual sensor 12.
  • the session control module 130 includes a switching necessity determination unit 131, an input candidate selection unit 132, and a session switching unit 133.
  • the switching necessity determination unit 131 determines whether it is necessary to switch the input sensor of the processing module 150 based on the input quality check result in the input quality check module 120. For example, the switching necessity determination unit 131 determines that it is not necessary to switch the input sensor when the input quality check result is “good”, while the input sensor needs to be switched when the input quality check result is “bad”. judge.
  • the input candidate selection unit 132 selects one of the actual sensors 12 from the input candidates registered in the input candidate DB 140 (FIG. 4) when the switching necessity determination unit 131 determines that the input sensor needs to be switched. To do. For example, in the input candidate DB 140, the input candidate selection unit 132 selects the real sensor 12 having a high priority among the plurality of real sensors 12 associated with the input port determined to require switching of the input sensor.
  • the actual sensor 12 selected by the input candidate selection unit 132 is also referred to as “selected actual sensor” below.
  • Session switching unit 133 switches the input sensor to the selected actual sensor. Specifically, the session switching unit 133 controls the input port of the processing module 150 so that the input sensor is switched to the selected actual sensor. Session switching unit 133 further transmits a sensor switching command to SDTM server 200 via communication I / F 190 so that data transfer from the selected actual sensor to the input port is performed. Details of the sensor switching command will be described in detail later.
  • the input sensor can be switched to the actual sensor 12 that outputs the input data satisfying the quality condition.
  • FIG. 11 is a diagram illustrating an example of a hardware configuration of the SDTM server 200.
  • the SDTM server 200 is realized by a general-purpose computer, for example.
  • the SDTM server 200 includes a control unit 240, a communication I / F 260, and a storage unit 250, and each component is electrically connected via a bus 265.
  • the control unit 240 includes a CPU 242, a RAM 244, a ROM 246, and the like, and is configured to control each component according to information processing.
  • the communication I / F 260 communicates with external devices (for example, the virtual sensor management server 100, the application server 300, and the sensor network unit 14 (see FIG. 2)) provided outside the SDTM server 200 via the Internet 15. It is configured.
  • the communication I / F 260 is configured by, for example, a wired LAN module or a wireless LAN module.
  • the storage unit 250 is an auxiliary storage device such as a hard disk drive or a solid state drive.
  • the storage unit 250 is configured to store, for example, the sensor side metadata DB 230 and the control program 251.
  • FIG. 12 is a diagram illustrating an example of the sensor side metadata DB 230.
  • the sensor side metadata DB 230 is a database for managing metadata indicating the attributes of each real sensor 12 included in the sensor network unit 14 (FIG. 2).
  • the metadata of each real sensor 12 included in the sensor network unit 14 is registered in advance in the sensor side metadata DB 230.
  • metadata is managed for each actual sensor 12.
  • the sensor-side metadata includes, for example, “basic attributes” and “quality attributes”.
  • the “basic attribute” is a basic condition required for the actual sensor 12 and includes, for example, “type”, “observation target”, and “installation location”.
  • the “quality attribute” is an attribute related to the quality of sensing data output by the actual sensor 12. For example, “outlier generation rate”, “data missing occurrence rate”, “manufacturer” of the actual sensor 12, etc. Included in “quality attributes”. In addition to these, “sensor state attribute”, “sensor installation attribute”, “sensor maintenance history attribute”, “data specification attribute”, “data resolution attribute”, and the like may be included in the “quality attribute”.
  • the control program 251 is a control program for the SDTM server 200 that is executed by the control unit 240.
  • the input candidate search module 210 and the data flow control module 220 may be realized by the control unit 240 executing the control program 251.
  • the control program 251 is expanded in the RAM 244.
  • the control unit 240 controls each component by interpreting and executing the control program 251 expanded in the RAM 244 by the CPU 242.
  • each software module realized by the control unit 240 according to the control program 251 will be described.
  • SDTM server software configuration example> Referring to FIG. 2 again, in SDTM server 200, control unit 240 implements each of input candidate search module 210 and data flow control module 220. Hereinafter, each software module will be described in order.
  • FIG. 13 is a diagram illustrating an example of a detailed configuration of the input candidate search module 210.
  • the input candidate search module 210 includes a use side data catalog acquisition unit 211, a sensor side metadata acquisition unit 212, a provision side data catalog generation unit 215, a matching unit 213, and an input candidate acquisition unit 214. Including.
  • the usage-side data catalog acquisition unit 211 acquires the above-described usage-side data catalog from the virtual sensor management server 100 (input candidate management module 110) via the communication I / F 260.
  • the sensor side metadata acquisition unit 212 acquires the sensor side metadata 13 (FIG. 1) associated with each real sensor 12 registered in the sensor side metadata DB 230 (FIG. 12).
  • the providing side data catalog generation unit 215 generates a providing side data catalog based on the sensor side metadata 13.
  • the providing side data catalog is generated for each actual sensor 12 registered in the sensor side metadata DB 230.
  • the provider data catalog is a catalog indicating attributes of the provider (each actual sensor 12).
  • the provider side data catalog includes the attributes of the actual sensor 12 indicated by the sensor side metadata 13. For example, the provider data catalog includes the above-mentioned “basic attributes” and “quality attributes”.
  • the matching unit 213 performs matching between the usage-side data catalog acquired by the usage-side data catalog acquisition unit 211 and the providing-side data catalog generated by the providing-side data catalog generation unit 215.
  • the matching is established when the attribute of the actual sensor 12 included in the provider data catalog satisfies the condition of the input data of the processing module 150 included in the user data catalog.
  • the actual sensor 12 corresponding to the providing side data catalog is extracted as an input sensor candidate.
  • the attribute of the actual sensor 12 included in the providing side data catalog does not satisfy the condition of the input data of the processing module 150 included in the usage side data catalog, matching is not established. If matching fails, the actual sensor 12 corresponding to the provider data catalog is not extracted as an input sensor candidate.
  • the input candidate acquisition unit 214 acquires information (actual sensor information) that can identify the actual sensor 12 extracted as the input sensor candidate by the matching unit 213. Each real sensor information acquired by the input candidate acquisition unit 214 is transmitted to the virtual sensor management server 100 (input candidate management module 110) via the communication I / F 260.
  • FIG. 14 is a diagram illustrating an example of a detailed configuration of the data flow control module 220.
  • the data flow control module 220 includes a sensor switching command acquisition unit 221 and a data flow control command generation unit 222.
  • the sensor switching command acquisition unit 221 acquires the above-described sensor switching command from the virtual sensor management server 100 (session control module 130) via the communication I / F 260.
  • the sensor switching command includes, for example, actual sensor information of the actual sensor 12 that is currently outputting input data to the processing module 150 (switching source actual sensor 12) and actual sensor information of the switching destination actual sensor 12.
  • the data flow control command generator 222 generates a data flow control command based on the actual sensor information of the actual sensor 12 that is the switching source and the actual sensor information of the actual sensor 12 that is the switching destination.
  • the data flow control command includes an output stop command for input data to the processing module 150 by the actual sensor 12 at the switching source and an output start command for input data to the processing module 150 by the actual sensor 12 at the switching destination.
  • the output stop command is transmitted to the switching source real sensor 12 via the communication I / F 260.
  • the output stop command is transmitted to the actual sensor 12 that is the switching source, the output of the sensing data by the actual sensor 12 that is the switching source is stopped.
  • the output start command is transmitted to the real sensor 12 at the switching destination via the communication I / F 260.
  • the real sensor 12 at the switching destination uses an API (Application Programming Interface) for establishing communication with the processing module 150 at the output destination. Transmit to the virtual sensor management server 100.
  • the API Application Programming Interface
  • the virtual sensor management server 100 when the API is executed, the output of sensing data from the switching destination real sensor 12 to the target processing module 150 is started.
  • FIG. 15 is a flowchart illustrating an example of the input sensor candidate extraction operation of the processing module 150. The processing shown in this flowchart is executed at a predetermined cycle. As described above, the extraction of the input sensor candidates is performed for each input port of each processing module 150. Here, description will be given focusing on one input port of one processing module 150.
  • the flowchart on the left is executed by the control unit 170 operating as the input candidate management module 110.
  • the flowchart on the right side is executed by the control unit 240 operating as the input candidate search module 210.
  • control unit 170 acquires the processing module side metadata 161 associated with the input port from the processing module side metadata DB 160 (FIG. 5) (step S100).
  • the control unit 170 generates a use side data catalog based on the acquired processing module side metadata 161 (step S110).
  • the control unit 170 controls the communication I / F 190 to transmit the generated usage-side data catalog to the SDTM server 200 (step S120). Thereafter, the control unit 170 determines whether information (actual sensor information) indicating input sensor candidates has been received from the SDTM server 200 via the communication I / F 190 (step S130). If it is determined that actual sensor information has not been received (NO in step S130), control unit 170 waits until actual sensor information is received.
  • control unit 240 determines whether or not the use side data catalog has been received (step S200). If it is determined that the usage-side data catalog has not been received (NO in step S200), control unit 240 waits until the usage-side data catalog is received.
  • control unit 240 acquires sensor-side metadata 13 of each real sensor 12 managed in sensor-side metadata DB 230 (step S210). ). The control unit 240 generates a providing side data catalog based on the acquired sensor side metadata 13 (step S220).
  • the control unit 240 extracts input sensor candidates from the plurality of actual sensors 12 managed by the sensor side metadata DB 230 based on the acquired use side data catalog and the generated providing side data catalog (step S230). ).
  • control unit 240 determines whether the attributes (for example, “basic attribute” and “quality attribute”) indicated by the providing side data catalog are indicated by the user side data catalog (for example, “basic condition” and “quality condition”). When the condition is satisfied, the actual sensor 12 corresponding to the provider data catalog is extracted as an input sensor candidate. For example, the control unit 240 extracts more input sensor candidates than the number of input ports of the processing module 150. For example, when the number of input ports of the processing module 150 is “3”, the control unit 240 extracts, for example, four or more input sensor candidates.
  • the control unit 240 controls the communication I / F 260 to transmit the extracted plurality of actual sensor information to the virtual sensor management server 100 (step S240).
  • control unit 170 determines a predetermined reference. Accordingly, priority is given to each real sensor 12 (step S140).
  • control unit 170 updates the input candidate DB 140 according to the assigned priority order (step S150). That is, the control unit 170 updates the input candidate DB 140 so that each extracted input sensor candidate is managed according to the assigned priority.
  • the input sensor candidates of each processing module 150 are extracted based on the processing module side metadata 161 and the sensor side metadata 13. In other words, input sensor candidates are extracted in consideration of the input data conditions of each processing module 150. Therefore, according to the virtual sensor management server 100 and the SDTM server 200, appropriate candidates for the real sensor 12 that outputs input data to the processing module 150 can be extracted in advance.
  • FIG. 16 is a flowchart showing an example of the quality check operation of input data to the processing module 150.
  • the processing shown in this flowchart is executed by the control unit 170 operating as the input quality check module 120 at the timing when data is input to the processing module 150.
  • the quality check of the input data is performed for each input port of each processing module 150.
  • description will be given focusing on one input port of one processing module 150.
  • control unit 170 extracts input metadata from input data to processing module 150 (step S300).
  • the controller 170 checks the extracted input metadata (step S310). For example, the control unit 170 checks the quality of the input data based on the processing module side metadata 161 associated with the input port and the input metadata. For example, when the quality attribute indicated by the input metadata satisfies the quality condition indicated by the processing module side metadata 161, the control unit 170 determines that the quality of the input data is “good”, whereas the control attribute is indicated by the input metadata. If the quality attribute to be satisfied does not satisfy the quality condition indicated by the processing module side metadata 161, the quality of the input data is determined as “bad”.
  • the controller 170 determines whether or not an accident has occurred in the input data based on the input metadata (step S320). For example, the control unit 170 determines that an accident has occurred in the input data when “garbage” or the like has occurred in the input metadata. For example, the control unit 170 determines that the quality of the input data is “bad” when it is determined that an accident occurs in the input data, while the input data is determined when it is determined that no accident occurs in the input data. The quality of the product is judged as “good”.
  • the input quality check module 120 (control unit 170) notifies the session control module 130 (control unit 170) of the input quality check result based on the determination results in steps S310 and S320 (step S330). For example, the input quality check module 120 determines the input quality check result as “good” when the quality is determined as “good” in both steps S310 and S320, while the quality is determined in at least one of steps S310 and S320. When it is determined as “bad”, the input quality check result is determined as “bad”.
  • the input metadata includes the quality attribute of the input data to the processing module 150. Based on the input metadata, the quality of the input data is checked. That is, according to the virtual sensor management server 100, the quality of the input data to the processing module 150 can be checked.
  • FIG. 17 is a flowchart illustrating an example of a session switching operation between the processing module 150 and the actual sensor 12. The processing shown in this flowchart is executed when the control unit 170 operates as the session control module 130 when an input quality check result is notified from the input quality check module 120. As described above, the session switching is performed for each input port of each processing module 150. Here, the description will be given focusing on one input port of one processing module 150.
  • control unit 170 determines whether or not session switching is necessary based on the notified input quality check result (step S400). For example, the control unit 170 determines that switching is not necessary when the input quality check result is “good”, and determines that switching is necessary when the input quality check result is “bad”.
  • control unit 170 determines whether or not it is determined in step S400 that session switching is necessary (step S410). If it is determined that switching is not required (NO in step S410), control unit 170 does not switch the input sensor of processing module 150 and maintains the session (step S430).
  • control unit 170 determines whether there is a switching candidate (step S420). For example, the control unit 170 determines whether or not input sensor candidates for the corresponding input port are managed in the input candidate DB 140. For example, the control unit 170 determines that there is a switching candidate when the input sensor candidate of the corresponding input port is managed in the input candidate DB 140, while the input sensor candidate of the corresponding input port is not managed. It is determined that there is no switching candidate.
  • control unit 170 determines that there is no switching candidate (NO in step S420). If it is determined that there is no switching candidate (NO in step S420), control unit 170 maintains the session without switching the input sensor of processing module 150 (step S430). On the other hand, when it is determined that there is a switching candidate (YES in step S420), control unit 170 selects one of the input sensor candidates (selected actual sensor) from the input sensor candidates managed in input candidate DB 140. (Step S440).
  • control unit 170 executes processing for session switching (step S450). For example, the control unit 170 controls the input port of the processing module 150 so that the input sensor is switched to the selected actual sensor. Further, the control unit 170 controls the communication I / F 190 so as to transmit the above-described sensor switching command to the SDTM server 200.
  • the virtual sensor management server 100 when the input data of the processing module 150 does not satisfy the quality condition, the input sensor is switched to the new real sensor 12. Therefore, according to the virtual sensor management server 100, since the input of data that does not satisfy the quality condition to the processing module 150 is not continued, the quality of the input data can be maintained.
  • the real sensor 12 that outputs the input data that satisfies the quality condition is extracted in advance, and the real sensor 12 that outputs the input data to the processing module 150 is any of the real sensors 12 extracted in advance. It can be switched to. Therefore, according to the virtual sensor management server 100, data satisfying the quality condition is input from the real sensor 12 after switching, so that the quality of the input data to the processing module 150 can be maintained.
  • FIG. 18 is a flowchart illustrating an example of the data flow control operation. The process shown in this flowchart is executed by the control unit 240 operating as the data flow control module 220 at a timing when a sensor switching command is received from the virtual sensor management server 100 via the communication I / F 260. As described above, the control of the data flow is performed for each input port of each processing module 150. Here, a description will be given focusing on one input port of one processing module 150.
  • control unit 240 determines whether a sensor switching command is received from virtual sensor management server 100 via communication I / F 260 (step S500). If it is determined that a sensor switching command has not been received (NO in step S500), control unit 240 waits until a sensor switching command is received.
  • control unit 240 when it is determined that the sensor switching command has been received (YES in step S500), control unit 240 generates the above-described data flow control command (step S510). The control unit 240 transmits the generated data flow control command to the actual sensor 12 that is the switching source, the actual sensor 12 that is the switching destination, and the like (step S520). Thereby, the session switching between the processing module 150 and the actual sensor 12 is completed.
  • control units 170 and 240 select some or all of the actual sensors 12 from the plurality of input sensor candidates managed by the input candidate DB 140, and the input sensors of the processing module 150. Is switched to the selected real sensor 12.
  • the input data output from each of the plurality of input sensor candidates managed by the input candidate DB 140 satisfies the quality condition of the input data of the processing module 150. Therefore, according to the virtual sensor management server 100 and the SDTM server 200, since the input data satisfying the quality condition is output from the real sensor 12 after switching, the quality of the input data to the processing module 150 can be maintained.
  • the processing module 150 is an example of the “processing module” of the present invention
  • the actual sensor 12 is an example of the “device” of the present invention
  • the input candidate management module 110 is an example of the “device” of the present invention
  • the input candidate management module 110 is an example of the “device” of the present invention
  • the input candidate management module 110 is an example of the “device” of the present invention
  • the input candidate management module 110 is an example of the “device” of the present invention
  • the session control module is an example of the “session control device” of the present invention.
  • the quality condition included in the processing module side metadata 161 is an example of the “condition” in the present invention.
  • the matching unit 213 is an example of the “extraction unit” of the present invention
  • the input candidate selection unit 132 is an example of the “selection unit” of the present invention
  • the session switching unit 133 is the “switching unit” of the present invention. It is an example.
  • the input sensor candidates of the processing module 150 are extracted.
  • the object to be extracted does not necessarily need to be an input sensor candidate of the processing module 150.
  • data set candidates input to the processing module 150 may be extracted.
  • the data set is a set of a plurality of data generated in advance.
  • a set of sensing data obtained by observing an object for a predetermined period in advance is an example of a data set.
  • the data set is stored in a storage connected to the Internet 15.
  • metadata indicating the attribute of each data set is managed in the SDTM server 200.
  • a provider data catalog is generated based on the metadata associated with each data set.
  • a data set that satisfies the conditions of the input data of the processing module 150 is extracted based on the use side data catalog and the providing side data catalog. That is, based on the processing module side metadata 161 and the metadata associated with each data set, more data set candidates than the number of input ports of the processing module 150 are extracted from the plurality of data sets. The Thereby, it is possible to extract an appropriate data set that satisfies the condition of the input data of the processing module 150.
  • the quality of the input data to the processing module 150 is checked.
  • the quality check target is not necessarily input data.
  • the quality of the data set input to the processing module 150 may be checked.
  • the data set is composed of a plurality of data and metadata indicating attributes relating to the quality of each of the plurality of data.
  • the input quality check module 120 checks the quality of the data set including the metadata based on the metadata. Thereby, the quality of the data set input to the processing module 150 can be checked.
  • the input sensor of the processing module 150 when the input data to the processing module 150 does not satisfy the quality condition, the input sensor of the processing module 150 is switched to the new actual sensor 12.
  • the switching source and the switching destination are not necessarily the actual sensor 12.
  • the data set input to the processing module 150 may be switched to a new data set.
  • the switching destination real sensor 12 is selected from the input sensor candidates extracted in advance.
  • the target extracted in advance may be a data set
  • the target selected as the switching destination may be a data set.
  • the data included in each of the plurality of data set candidates extracted in advance satisfies the quality condition of the input data of the processing module 150.
  • both the actual sensor 12 and the data set may be included in each of the target extracted in advance as the input candidate of the processing module 150 and the target selected as the input switching destination of the processing module 150.
  • each input port of each processing module 150 performs a session with one of the actual sensors 12.
  • the partner with which each input port conducts a session is not limited to the actual sensor 12.
  • the session partner may be a storage storing a data set or a virtual sensor. Since the session partner does not necessarily have to be a sensor, the input data of the processing module 150 does not necessarily have to be sensing data.
  • the input data may be purchase history data of each user at a shopping site, score data of each user at a game site, or the like.
  • each of the virtual sensor management server 100 and the SDTM server 200 may be realized by a plurality of servers or the like. Moreover, in the said embodiment, the process performed by the virtual sensor management server 100 and the SDTM server 200 may be implement

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

処理モジュールへの入力データの品質を維持することが可能なセッション制御装置、セッション制御方法及びプログラムを提供する。処理モジュール毎に、入力データの品質に関する条件が規定されている。セッション制御装置は、抽出部と、選択部と、切替部とを備える。抽出部は、複数のデバイスの候補を抽出するように構成されている。選択部は、複数のデバイスの候補から一部又は全部のデバイスを選択するように構成されている。切替部は、処理モジュールへ入力データを出力するデバイスを選択部によって選択されたデバイスに切り替えるように構成されている。複数のデバイスの候補の各々が出力する入力データは、上記条件を満たす。

Description

セッション制御装置、セッション制御方法及びプログラム
　本発明は、セッション制御装置、セッション制御方法及びプログラムに関する。
　特開２０１４－４５２４２号公報（特許文献１）は、仮想センサを生成する仮想センサ生成装置を開示する。この仮想センサ生成装置においては、所定範囲内に存在する実センサが検出され、検出された実センサを用いることによって仮想センサが生成される（特許文献１参照）。
特開２０１４－４５２４２号公報
　上記特許文献１に開示されるような仮想センサは、たとえば、実センサ（デバイスの一例）と、処理モジュールとを含む。処理モジュールは、実センサにより出力されたセンシングデータ（入力データの一例）に処理を施すことによって、入力データとは異なる出力データを生成する。たとえば、仮想センサを継続的に機能させるためには、処理モジュールへの入力データの品質を維持する必要がある。しかしながら、上記特許文献１においては、処理モジュールへの入力データの品質を維持する方法が開示されていない。
　本発明は、このような問題を解決するためになされたものであって、その目的は、処理モジュールへの入力データの品質を維持することが可能なセッション制御装置、セッション制御方法及びプログラムを提供することである。
　本発明のある局面に従うセッション制御装置は、処理モジュールと、処理モジュールへ入力データを出力するデバイスとのセッションを制御するように構成されている。処理モジュールは、少なくとも１つの入力データに基づいて入力データとは異なる出力データを生成するように構成されている。処理モジュール毎に、入力データの品質に関する条件が規定されている。セッション制御装置は、抽出部と、選択部と、切替部とを備える。抽出部は、複数のデバイスの候補を抽出するように構成されている。選択部は、複数のデバイスの候補から一部又は全部のデバイスを選択するように構成されている。切替部は、処理モジュールへ入力データを出力するデバイスを選択部によって選択されたデバイスに切り替えるように構成されている。複数のデバイスの候補の各々が出力する入力データは、上記条件を満たす。
　このセッション制御装置においては、品質に関する条件を満たす入力データを出力するデバイスが候補として抽出され、処理モジュールへ入力データを出力するデバイスが、抽出されたデバイスのいずれかに切り替えられる。したがって、このセッション制御装置によれば、切替後のデバイスから品質に関する条件を満たすデータが入力されるため、処理モジュールへの入力データの品質を維持することができる。
　また、好ましくは、上記セッション制御装置において、切替部は、処理モジュールに入力されている入力データが上記条件を満たさない場合に、処理モジュールへ入力データを出力するデバイスを、選択部によって選択されたデバイスに切り替えるように構成されている。
　このセッション制御装置においては、処理モジュールに入力されている入力データが品質に関する条件を満たさない場合に、処理モジュールへ入力データを出力するデバイスが、品質に関する条件を満たす入力データを出力するデバイスに切り替えられる。したがって、このセッション制御装置によれば、品質に関する条件を満たさないデータの入力が停止されるため、処理モジュールへの入力データの品質を維持することができる。
　また、好ましくは、上記セッション制御装置において、デバイスは、センサである。入力データは、センサによって生成されたセンシングデータである。
　また、好ましくは、上記セッション制御装置において、処理モジュールは、複数の入力データに基づいて出力データを生成するように構成されている。
　また、好ましくは、上記セッション制御装置においては、処理モジュールと、処理モジュールへ入力データを出力するデバイスとによって仮想センサが形成される。
　また、本発明の別の局面に従うセッション制御装置は、処理モジュールと、処理モジュールへ入力するデータセットを保持するストレージとのセッションを制御するように構成されている。データセットは、複数のデータで構成されている。処理モジュールは、少なくとも１つの入力データに基づいて入力データとは異なる出力データを生成するように構成されている。処理モジュール毎に、入力データの品質に関する条件が規定されている。セッション制御装置は、抽出部と、選択部と、切替部とを備える。抽出部は、複数のデータセットの候補を抽出するように構成されている。選択部は、複数のデータセットの候補から一部又は全部のデータセットを選択するように構成されている。切替部は、処理モジュールへ入力するデータセットを選択部によって選択されたデータセットに切り替えるように構成されている。そして、複数のデータセットの候補の各々に含まれるデータは、上記条件を満たす。
　このセッション制御装置においては、品質に関する条件を満たすデータセットが入力候補として抽出され、処理モジュールへ入力するデータセットが、抽出されたデータセットのいずれかに切り替えられる。したがって、このセッション制御装置によれば、品質に関する条件を満たすデータセットが入力されるため、処理モジュールへの入力データの品質を維持することができる。
　また、本発明の別の局面に従うセッション制御方法は、処理モジュールと、処理モジュールへ入力データを出力するデバイスとのセッションを制御する。処理モジュールは、少なくとも１つの入力データに基づいて入力データとは異なる出力データを生成するように構成されている。処理モジュール毎に、入力データの品質に関する条件が規定されている。セッション制御方法は、複数のデバイスの候補を抽出するステップと、複数のデバイスの候補から一部又は全部のデバイスを選択するステップと、処理モジュールへ入力データを出力するデバイスを選択部によって選択されたデバイスに切り替えるステップとを含む。複数のデバイスの候補の各々が出力する入力データは、条件を満たす。
　このセッション制御方法においては、品質に関する条件を満たす入力データを出力するデバイスが候補として抽出され、処理モジュールへ入力データを出力するデバイスが、抽出されたデバイスのいずれかに切り替えられる。したがって、このセッション制御方法によれば、切替後のデバイスから品質に関する条件を満たすデータが入力されるため、処理モジュールへの入力データの品質を維持することができる。
　また、本発明の別の局面に従うプログラムは、処理モジュールと、処理モジュールへ入力データを出力するデバイスとのセッションを制御する処理をコンピュータに実行させる。処理モジュールは、少なくとも１つの入力データに基づいて入力データとは異なる出力データを生成するように構成されている。処理モジュール毎に、入力データの品質に関する条件が規定されている。プログラムは、複数のデバイスの候補を抽出するステップと、複数のデバイスの候補から一部又は全部のデバイスを選択するステップと、処理モジュールへ入力データを出力するデバイスを選択部によって選択されたデバイスに切り替えるステップとをコンピュータに実行させるように構成されている。複数のデバイスの候補の各々が出力する入力データは、条件を満たす。
　このプログラムがコンピュータによって実行されると、品質に関する条件を満たす入力データを出力するデバイスが候補として抽出され、処理モジュールへ入力データを出力するデバイスが、抽出されたデバイスのいずれかに切り替えられる。したがって、このプログラムによれば、切替後のデバイスから品質に関する条件を満たすデータが入力されるため、処理モジュールへの入力データの品質を維持することができる。
　本発明によれば、処理モジュールへの入力データの品質を維持することが可能なセッション制御装置、セッション制御方法及びプログラムを提供することができる。
セッション制御装置７０の概要を説明するための図である。 センサネットワークシステムの一例を示す図である。 仮想センサ管理サーバのハードウェア構成の一例を示す図である。 入力候補ＤＢの一例を示す図である。 処理モジュール側メタデータＤＢの一例を示す図である。 制御部によって実現される各ソフトウェアモジュールの関係の一例を示す図である。 入力候補管理モジュールの詳細な構成の一例を示す図である。 入力品質チェックモジュールの詳細な構成の一例を示す図である。 センシングデータに対応付けられるメタデータの一例を示す図である。 セッション制御モジュールの詳細な構成の一例を示す図である。 ＳＤＴＭサーバのハードウェア構成の一例を示す図である。 センサ側メタデータＤＢの一例を示す図である。 入力候補検索モジュールの詳細な構成の一例を示す図である。 データフロー制御モジュールの詳細な構成の一例を示す図である。 処理モジュールの入力センサ候補の抽出動作の一例を示すフローチャートである。 処理モジュールへの入力データの品質チェック動作の一例を示すフローチャートである。 処理モジュールと実センサとのセッションの切替動作の一例を示すフローチャートである。 データフロー制御動作の一例を示すフローチャートである。
　以下、本発明の一側面に係る実施の形態（以下、「本実施の形態」とも称する。）について、図面を用いて詳細に説明する。なお、図中同一又は相当部分には同一符号を付してその説明は繰り返さない。また、以下で説明する本実施の形態は、あらゆる点において本発明の例示にすぎない。本実施の形態は、本発明の範囲内において、種々の改良や変更が可能である。すなわち、本発明の実施にあたっては、実施の形態に応じて具体的構成を適宜採用することができる。
　［１．概要］
　図１は、本実施の形態に従うセッション制御装置７０の概要を説明するための図である。図１を参照して、処理モジュール１５０は複数の入力ポートを有し、各入力ポートには実センサ１２（デバイスの一例）によって出力されたセンシングデータ（入力データの一例）が入力される。処理モジュール１５０は、入力データに基づいて入力データとは異なる出力データを生成するように構成されている。すなわち、処理モジュール１５０と、処理モジュール１５０へ入力データを出力する実センサ１２（入力センサ）とによって、いわゆる仮想センサが形成される。仮想センサとは、入力センサが対象を観測することによって生成されたセンシングデータに基づいて、入力センサによって観測された対象とは異なる対象の観測結果をセンシングデータとして出力するセンサモジュールである。仮想センサについては、後程詳しく説明する。
　仮想センサを継続的に機能させるためには、処理モジュール１５０への入力データの品質を維持する必要がある。すなわち、処理モジュール１５０への入力データの品質が低下すると、仮想センサが所望の機能を発揮し得なくなる可能性がある。
　本実施の形態に従うセッション制御装置７０は、処理モジュール１５０へ入力データを出力する実センサ１２の候補（以下、「入力センサ候補」とも称する。）を予め抽出するように構成されている。具体的には、セッション制御装置７０は、ネットワークを介して通信可能な複数の実センサ１２から、処理モジュール１５０の入力センサとして適した実センサ１２を予め抽出し、抽出された実センサ１２を入力候補ＤＢ（database）１４０上で管理するように構成されている。より具体的には、入力候補ＤＢ１４０上で管理される各実センサ１２は、処理モジュール１５０の入力データの品質条件を満たすデータを出力可能である。
　本実施の形態に従うセッション制御装置７０は、入力候補ＤＢ１４０上で管理されている複数の実センサ１２から一部又は全部の実センサ１２を選択し、必要に応じて処理モジュール１５０の入力センサを選択された実センサ１２に切り替える。したがって、セッション制御装置７０によれば、切り替え後の実センサ１２から品質条件を満たす入力データが出力されるため、処理モジュール１５０への入力データの品質を維持することができる。以下、具体的な構成及び動作について順に説明する。
　［２．構成例］
　＜２－１．システムの全体構成例＞
　図２は、本実施の形態に従うセッション制御装置７０（図１）を含むセンサネットワークシステム１０の一例を示す図である。図２の例では、センサネットワークシステム１０は、センサネットワーク部１４と、仮想センサ管理サーバ１００と、ＳＤＴＭ（Sensing Data Trading Market）サーバ２００と、アプリケーションサーバ３００とを含む。なお、本実施の形態において、セッション制御装置７０は、仮想センサ管理サーバ１００とＳＤＴＭサーバ２００とによって実現される。
　センサネットワーク部１４、仮想センサ管理サーバ１００、ＳＤＴＭサーバ２００及びアプリケーションサーバ３００は、インターネット１５を介して相互に通信可能に接続されている。なお、センサネットワークシステム１０に含まれる各構成要素（仮想センサ管理サーバ１００、ＳＤＴＭサーバ２００、アプリケーションサーバ３００、センサネットワークアダプタ１１及び実センサ１２等）の数は、図２に示されるものに限定されない。
　センサネットワークシステム１０においては、センシングデバイス（たとえば、実センサ及び仮想センサ）によって生成されたセンシングデータが流通可能である。たとえば、実センサ１２によって生成されたセンシングデータは仮想センサ管理サーバ１００に流通し得るし、仮想センサによって生成されたセンシングデータはアプリケーションサーバ３００に流通し得る。
　センサネットワーク部１４は、たとえば、複数のセンサネットワークアダプタ１１を含む。複数のセンサネットワークアダプタ１１の各々には複数の実センサ１２が接続されており、各実センサ１２はセンサネットワークアダプタ１１を介してインターネット１５に接続されている。
　実センサ１２は、対象を観測することによってセンシングデータを得るように構成されている。実センサ１２は、たとえば、画像センサ（カメラ）、温度センサ、湿度センサ、照度センサ、力センサ、音センサ、ＲＦＩＤ（Radio Frequency IDentification）センサ、赤外線センサ、姿勢センサ、降雨センサ、放射能センサ及びガスセンサ等であり、どのような種類のセンサであってもよい。また、実センサ１２は、必ずしも固設型である必要はなく、携帯電話、スマートフォン及びタブレット等の移動型であってもよい。また、各実センサ１２は、必ずしも単一のセンシングデバイスで構成されている必要はなく、複数のセンシングデバイスによって構成されていてもよい。また、実センサ１２は、どのような目的で設置されていてもよく、たとえば、工場におけるＦＡ（Factory Automation）及び生産管理、都市交通制御、気象等の環境計測、ヘルスケア並びに防犯等のために設置されていてもよい。
　センサネットワーク部１４において、たとえば、各センサネットワークアダプタ１１は別々の（遠い）場所に配置され、各センサネットワークアダプタ１１に接続される各実センサ１２は同一の（近い）場所に配置されるが、これらの配置場所はこれに限定されない。
　各アプリケーションサーバ３００（３００Ａ，３００Ｂ）は、センシングデータを利用するアプリケーションを実行するように構成されており、たとえば、汎用のコンピュータによって実現されている。アプリケーションサーバ３００は、インターネット１５を介して必要なセンシングデータを取得する。
　仮想センサ管理サーバ１００は、仮想センサを実現するためのサーバである。仮想センサ管理サーバ１００においては、複数の処理モジュール１５０と、入力候補管理モジュール１１０と、入力品質チェックモジュール１２０と、セッション制御モジュール１３０とが実現されるとともに、入力候補ＤＢ１４０と、処理モジュール側メタデータＤＢ１６０とが管理される。複数の処理モジュール１５０、入力候補管理モジュール１１０、入力品質チェックモジュール１２０及びセッション制御モジュール１３０の各々は、たとえば、ソフトウェアモジュールである。
　処理モジュール１５０は、少なくとも１つの入力ポートを含み、各入力ポートに入力される入力データに基づいて入力データとは異なる出力データを生成するように構成されている。処理モジュール１５０は、たとえば、室内に配置された音センサによって出力される入力データ（音声データ）に基づいて、該室内に存在する人の数を示すデータを出力するように構成されてもよい。この場合には、処理モジュール１５０と、実センサ１２（音センサ）とによって、室内の人の数を検知する仮想センサを実現することができる。
　入力候補管理モジュール１１０は、処理モジュール１５０へ入力データを出力する実センサ１２の候補（入力センサ候補）を管理するように構成されている。入力品質チェックモジュール１２０は、処理モジュール１５０への入力データの品質をチェックするように構成されている。セッション制御モジュール１３０は、処理モジュール１５０と実センサ１２とのセッションを制御するように構成されている。
　たとえば、入力品質チェックモジュール１２０によって入力データの品質が所定の基準を満たさないと判定された場合に、セッション制御モジュール１３０は、処理モジュール１５０への入力センサを、予め抽出されている入力センサ候補のいずれかに切り替える。各ソフトウェアモジュール及び各データベースの詳細については後程説明する。
　ＳＤＴＭサーバ２００は、センサネットワークシステム１０におけるセンシングデータの流通を実現するためのサーバである。ＳＤＴＭサーバ２００においては、入力候補検索モジュール２１０と、データフロー制御モジュール２２０とが実現されるとともに、センサ側メタデータＤＢ２３０が管理される。入力候補検索モジュール２１０及びデータフロー制御モジュール２２０の各々は、たとえば、ソフトウェアモジュールである。
　入力候補検索モジュール２１０は、仮想センサ管理サーバ１００（入力候補管理モジュール１１０）からの要求を受けて、処理モジュール１５０の入力センサ候補を検索するように構成されている。データフロー制御モジュール２２０は、仮想センサ管理サーバ１００（セッション制御モジュール１３０）からの要求を受けて、実センサ１２から処理モジュール１５０へのセンシングデータの流通等を制御するように構成されている。各ソフトウェアモジュール及びデータベースの詳細については後程説明する。
　＜２－２．仮想センサ管理サーバのハードウェア構成例＞
　図３は、仮想センサ管理サーバ１００のハードウェア構成の一例を示す図である。なお、本実施の形態において、仮想センサ管理サーバ１００は、たとえば、汎用コンピュータによって実現される。
　図３の例では、仮想センサ管理サーバ１００は、制御部１７０と、通信Ｉ／Ｆ（interface）１９０と、記憶部１８０とを含み、各構成は、バス１９５を介して電気的に接続されている。
　制御部１７０は、ＣＰＵ（Central Processing Unit）１７２、ＲＡＭ（Random Access Memory）１７４及びＲＯＭ（Read Only Memory）１７６等を含み、情報処理に応じて各構成要素の制御を行なうように構成されている。
　通信Ｉ／Ｆ１９０は、インターネット１５を介して、仮想センサ管理サーバ１００の外部に設けられた外部装置（たとえば、ＳＤＴＭサーバ２００、アプリケーションサーバ３００及びセンサネットワーク部１４（図２））と通信するように構成されている。通信Ｉ／Ｆ１９０は、たとえば、有線ＬＡＮ（Local Area Network）モジュールや無線ＬＡＮモジュールで構成される。
　記憶部１８０は、たとえば、ハードディスクドライブ、ソリッドステートドライブ等の補助記憶装置である。記憶部１８０は、たとえば、入力候補ＤＢ１４０と、処理モジュール側メタデータＤＢ１６０と、制御プログラム１８１とを記憶するように構成されている。
　図４は、入力候補ＤＢ１４０の一例を示す図である。図４を参照して、入力候補ＤＢ１４０は、処理モジュール１５０の入力センサ候補を管理するデータベースである。入力候補ＤＢ１４０においては、各処理モジュール１５０の入力ポート毎に入力センサ候補が管理されている。たとえば、この例では、処理モジュール１５０（ＩＤ：Ｍ１）における入力ポート２の、第１候補は「センサＢ１」、第２候補は「センサＢ２」、第３候補は「センサＢ３」となっている。なお、入力ポート毎に管理される入力センサ候補は、必ずしも３つである必要はなく、３つ未満であってもよいし、４つ以上であってもよい。
　詳細については後述するが、入力候補ＤＢ１４０の更新処理は所定の周期で繰り返し実行される。たとえば、センサネットワーク部１４に含まれる実センサ１２のスペックが変更されると、入力候補ＤＢ１４０にリストアップされる入力センサ候補が変更される。
　図５は、処理モジュール側メタデータＤＢ１６０の一例を示す図である。図５を参照して、処理モジュール側メタデータＤＢ１６０は、処理モジュール１５０の入力データの条件を示すメタデータを管理するデータベースである。仮想センサ管理サーバ１００において実現される各処理モジュール１５０のメタデータは、予め処理モジュール側メタデータＤＢ１６０に登録されている。処理モジュール側メタデータＤＢ１６０においては、各処理モジュール１５０の入力ポート毎にメタデータが管理されている。
　処理モジュール側メタデータには、たとえば、「基本条件」と「品質条件」とが含まれる。「基本条件」とは、入力データ（センシングデータ）を出力する実センサ１２に求められる基本的な条件であり、たとえば、「種別」、「観測対象」、「設置場所」が含まれる。
　「種別」とは実センサ１２の種類であり、たとえば、温度センサ、照度センサ及びカメラの各々が「種別」の一例である。「観測対象」とは実センサ１２によって観測される対象であり、たとえば、外気温、駅改札、照度及び温度の各々が「観測対象」の一例である。「設置場所」とは実センサ１２が設置されている場所であり、たとえば、Ｐ１，Ｐ２及びＰ３の各々が「設置場所」の一例である（なお、Ｐ１，Ｐ２及びＰ３の各々は、たとえば、「京都駅前」等の具体的な場所を示すものとする。）。
　「品質条件」とは、入力データ（センシングデータ）の品質に関連する条件であり、たとえば、「外れ値条件」、「データ抜け頻度条件」、「メーカ条件」が含まれる。また、これらの他にも「センサ状態条件」、「センサ設置条件」、「センサ保守履歴条件」、「データ仕様条件」、「データ分解能条件」等が「品質条件」に含まれてもよい。
　「外れ値条件」とは、実センサ１２によって出力される入力データが外れ値となる確率に関する条件である。「データ抜け頻度条件」とは、入力ポートにデータが入力されるはずのタイミングで、データが入力されない確率に関する条件である。「メーカ条件」とは、入力データを出力する実センサ１２のメーカに関する条件である。
　「センサ状態条件」とは、入力データを出力する実センサ１２の状態に関する条件であり、たとえば、「センサが作動している限り許容可」、「センサの一部でも所定レベルまで劣化していた場合許容不可」等が「センサ状態条件」である。「センサ設置条件」とは、入力データを出力する実センサ１２の設置に関する条件であり、たとえば、「センサが初期設置位置からずれている場合許容不可」、「センサが初期設置位置から落下してない限り許容可」等が「センサ設置条件」である。「センサ保守履歴条件」とは、入力データを出力する実センサ１２の保守履歴に関する条件であり、たとえば、「保守点検の頻度が１回／日未満である場合許容不可」、「保守点検の頻度が１回／月以上である場合許容可」等が「センサ保守履歴条件」である。「データ仕様条件」とは、入力データの仕様に関する条件である。「データ分解能条件」とは、入力データの分解能に関する条件である。
　再び図３を参照して、制御プログラム１８１は、制御部１７０によって実行される仮想センサ管理サーバ１００の制御プログラムである。たとえば、制御部１７０が制御プログラム１８１を実行することによって、各処理モジュール１５０、入力候補管理モジュール１１０、入力品質チェックモジュール１２０及びセッション制御モジュール１３０（図２）等が実現されてもよい。制御部１７０が制御プログラム１８１を実行する場合に、制御プログラム１８１は、ＲＡＭ１７４に展開される。そして、制御部１７０は、ＲＡＭ１７４に展開された制御プログラム１８１をＣＰＵ１７２によって解釈及び実行することにより、各構成要素を制御する。次に、制御プログラム１８１に従って制御部１７０によって実現される各ソフトウェアモジュールについて説明する。
　＜２－３．仮想センサ管理サーバのソフトウェア構成例＞
　図６は、制御部１７０によって実現される各ソフトウェアモジュールの関係の一例を示す図である。図６の例では、処理モジュール１５０、入力候補管理モジュール１１０、入力品質チェックモジュール１２０及びセッション制御モジュール１３０の各々が制御部１７０によって実現される。
　入力候補管理モジュール１１０は、処理モジュール側メタデータＤＢ１６０を参照しつつ、ＳＤＴＭサーバ２００と連携しながら、処理モジュール１５０の入力センサに適した実センサ１２を抽出する。抽出された入力センサ候補は、入力候補ＤＢ１４０上で管理される。
　入力品質チェックモジュール１２０は、処理モジュール側メタデータＤＢ１６０を参照することによって、現在処理モジュール１５０に入力されているデータの品質が処理モジュール１５０の入力データの条件を満たすか否かをチェックする。
　セッション制御モジュール１３０は、入力品質チェックモジュール１２０によるチェック結果に基づいて処理モジュール１５０の入力センサの切り替え要否を判定する。セッション制御モジュール１３０は、入力センサの切り替えが必要と判断された場合に、入力センサを、入力候補ＤＢ１４０において管理されているいずれかの実センサ１２に切り替える。
　以下、入力候補管理モジュール１１０、入力品質チェックモジュール１２０及びセッション制御モジュール１３０の詳細について順に説明する。
　（２－３－１．入力候補管理モジュール）
　図７は、入力候補管理モジュール１１０の詳細な構成の一例を示す図である。図７の例では、入力候補管理モジュール１１０は、メタデータ取得部１１１と、利用側データカタログ生成部１１２と、優先順位付与部１１３と、入力候補ＤＢ更新部１１４とを含む。なお、入力候補管理モジュール１１０による入力センサ候補の抽出は、処理モジュール１５０の入力ポート毎に行なわれる。各入力ポートの入力センサ候補の抽出は、並列的に行なわれてもよいし、順次行なわれてもよい。以下の説明においては、処理モジュール１５０の１つの入力ポートに着目した上で、各モジュールについて説明する。
　メタデータ取得部１１１は、入力センサ候補を抽出する対象となっている入力ポートに対応付けられた処理モジュール側メタデータ１６１（図１）を処理モジュール側メタデータＤＢ１６０から取得する。
　利用側データカタログ生成部１１２は、メタデータ取得部１１１によって取得された処理モジュール側メタデータ１６１に基づいて、利用側データカタログを生成する。利用側データカタログとは、利用側（仮想センサ管理サーバ１００）が必要としている実センサ１２の属性を示すカタログである。利用側データカタログには、処理モジュール側メタデータ１６１によって示される、入力データの条件が含まれる。たとえば、利用側データカタログには、上述の入力データの「基本条件」及び「品質条件」が含まれる。
　利用側データカタログ生成部１１２によって生成された利用側データカタログは、通信Ｉ／Ｆ１９０を介してＳＤＴＭサーバ２００に送信される。詳細については後述するが、ＳＤＴＭサーバ２００においては、利用側データカタログに示される条件を満たす実センサ１２が抽出される。抽出された実センサ１２を特定可能な情報（以下、「実センサ情報」とも称する。）が、通信Ｉ／Ｆ１９０を介して受信される。実センサ情報には、たとえば、実センサ１２に割り振られたＩＰアドレス（実センサ１２のインターネット１５上における所在を示す情報）、及び、実センサ１２の属性を示す情報が含まれる。
　優先順位付与部１１３は、複数の実センサ情報が受信された場合に、各実センサ１２に優先順位を付与する。優先順位付与部１１３は、どのような観点で各実センサ１２に優先順位を付与してもよい。たとえば、利用側データカタログに含まれる条件のうち、「外れ値条件」が最も重要である場合には、優先順位付与部１１３は、外れ値の発生率（外れ値発生率）が低い実センサ１２程高い優先順位を付与してもよい。
　入力候補ＤＢ更新部１１４は、優先順位付与部１１３によって付与された優先順位に従って入力候補ＤＢ１４０（図４）を更新する。これにより、入力候補ＤＢ１４０においては、利用側データカタログに示される条件を満たす実センサ１２が予め入力センサ候補として管理される。
　（２－３－２．入力品質チェックモジュール）
　図８は、入力品質チェックモジュール１２０の詳細な構成の一例を示す図である。図８の例では、入力品質チェックモジュール１２０は、データフィルタリング部１２１と、メタデータチェック部１２２と、アクシデントチェック部１２３とを含む。実センサ１２によって出力される入力データには、センシングデータと、センシングデータに対応付けられたメタデータ（以下、「入力メタデータ」とも称する。）とが含まれている。センシングデータは、実センサ１２が対象を観測することによって生成されたデータである。入力メタデータは、実センサ１２によって生成されたセンシングデータの属性を示すデータである。
　図９は、センシングデータに対応付けられる入力メタデータ６０の一例を示す図である。図９の例では、入力メタデータ６０には、「基本属性」と「品質属性」とが含まれる。「基本属性」とは、入力データを出力する実センサ１２の基本的な属性であり、たとえば、「種別」、「観測対象」、「設置場所」が含まれる。
　「品質属性」とは、センシングデータの品質に関連する属性であり、たとえば、「外れ値発生率」、「データ抜け発生率」、実センサ１２の「メーカ」等が「品質属性」に含まれる。また、これらの他にも「センサ状態属性」、「センサ設置属性」、「センサ保守履歴属性」、「データ仕様属性」、「データ分解能属性」等が「品質属性」に含まれてもよい。なお、センシングデータに対応付けられる入力メタデータ６０の少なくとも一部は、処理モジュール側メタデータ１６１とは異なり、時々刻々と変化し得る。たとえば、入力メタデータ６０に含まれ得る「外れ値発生率」は、実センサ１２の出荷時等に予め定められるものではなく、実センサ１２が継続的に稼働することによって変化するものである。たとえば、出荷直後はまだ実センサ１２が新しいため、「外れ値発生率」は低い。しかしながら、実センサ１２が長期間稼働することによって、「外れ値発生率」が高くなる。実センサ１２においては、たとえば、センシングデータが外れ値に該当するか否かが監視されており、所定期間における外れ値の発生率が順次更新される。そして、更新された外れ値発生率が入力メタデータ６０として、センシングデータに対応付けられる。「外れ値発生率」の他にも、たとえば、「データ抜け発生率」、「センサ状態属性」、「センサ保守履歴属性」等が時々刻々と変化し得る。
　再び図８を参照して、データフィルタリング部１２１は、実センサ１２によって出力された入力データをセンシングデータと入力メタデータとに分離する。センシングデータは処理モジュール１５０に出力され、入力メタデータはメタデータチェック部１２２に出力される。
　メタデータチェック部１２２は、データが入力される入力ポートに対応付けられている処理モジュール側メタデータ１６１（図１）を処理モジュール側メタデータＤＢ１６０（図５）から取得する。メタデータチェック部１２２は、処理モジュール側メタデータ１６１と入力メタデータとに基づいて、センシングデータが入力データの条件を満たすか否かを判定する。たとえば、メタデータチェック部１２２は、処理モジュール側メタデータ１６１が示す各条件を、入力メタデータが示す各属性が満たしている場合に、センシングデータが入力データの条件を満たすと判定する。
　より具体的には、メタデータチェック部１２２は、処理モジュール側メタデータ１６１と入力メタデータとに基づいて、センシングデータの品質が入力データの品質条件を満たすか否かを判定する。たとえば、メタデータチェック部１２２は、処理モジュール側メタデータ１６１が示す各品質条件を、入力メタデータが示す各品質属性が満たしている場合に、センシングデータの品質が入力データの品質条件を満たすと判定する。
　アクシデントチェック部１２３は、センシングデータに対応付けられているメタデータに基づいて入力データに何らかのアクシデントが生じているか否かを判定する。たとえば、アクシデントチェック部１２３は、入力メタデータに「文字化け」が生じてる場合や、入力メタデータが「外れ値」である確率が「外れ値発生率」よりも高い場合や、入力メタデータの抜け頻度が「データ抜け発生率」よりも高い場合に、入力データにアクシデントが生じていると判定する。
　その後、入力メタデータは、処理モジュール１５０に入力される。一方、メタデータチェック部１２２及びアクシデントチェック部１２３の各々によるチェック結果に基づく入力品質チェック結果は、セッション制御モジュール１３０に入力される。
　たとえば、入力品質チェック結果は、センシングデータの品質が入力データの品質条件を満たし、かつ、入力データにアクシデントが生じていないと判定された場合に「良」とされる。一方、入力品質チェック結果は、センシングデータの品質が入力データの品質条件を満たさないと判定された場合、又は、入力データに何らかのアクシデントが生じていると判定された場合に「悪」とされる。
　（２－３－３．セッション切替モジュール）
　図１０は、セッション制御モジュール１３０の詳細な構成の一例を示す図である。セッション制御モジュール１３０は、処理モジュール１５０と実センサ１２とのセッションの切り替えを制御するモジュールである。処理モジュール１５０と実センサ１２とのセッションを切り替えるとは、処理モジュール１５０の入力センサを他の実センサ１２に切り替えることを意味する。図１０の例では、セッション制御モジュール１３０は、切替要否判定部１３１と、入力候補選択部１３２と、セッション切替部１３３とを含む。
　切替要否判定部１３１は、入力品質チェックモジュール１２０における入力品質チェック結果に基づいて、処理モジュール１５０の入力センサの切り替え要否を判定する。たとえば、切替要否判定部１３１は、入力品質チェック結果が「良」の場合に入力センサの切り替えが不要と判定する一方、入力品質チェック結果が「悪」の場合に入力センサの切り替えが必要と判定する。
　入力候補選択部１３２は、切替要否判定部１３１において入力センサの切り替えが必要と判定された場合に、入力候補ＤＢ１４０（図４）に登録されている入力候補からいずれかの実センサ１２を選択する。入力候補選択部１３２は、たとえば、入力候補ＤＢ１４０において、入力センサの切り替えが必要と判定された入力ポートに対応付けられている複数の実センサ１２のうち優先順位の高い実センサ１２を選択する。なお、入力候補選択部１３２によって選択された実センサ１２を、以下では「選択済み実センサ」とも称する。
　セッション切替部１３３は、入力センサを選択済み実センサに切り替える。具体的には、セッション切替部１３３は、入力センサが選択済み実センサに切り替わるように、処理モジュール１５０の入力ポートを制御する。セッション切替部１３３は、さらに、選択済み実センサから入力ポートへのデータ転送が行なわれるように、通信Ｉ／Ｆ１９０を介してＳＤＴＭサーバ２００にセンサ切替指令を送信する。センサ切替指令の詳細については、後程詳しく説明する。
　これにより、たとえば、入力データの品質が品質条件を満たさない場合に、品質条件を満たす入力データを出力する実センサ１２に、入力センサを切り替えることができる。
　＜２－４．ＳＤＴＭサーバのハードウェア構成例＞
　図１１は、ＳＤＴＭサーバ２００のハードウェア構成の一例を示す図である。なお、本実施の形態において、ＳＤＴＭサーバ２００は、たとえば、汎用コンピュータによって実現される。
　図１１の例では、ＳＤＴＭサーバ２００は、制御部２４０と、通信Ｉ／Ｆ２６０と、記憶部２５０とを含み、各構成は、バス２６５を介して電気的に接続されている。
　制御部２４０は、ＣＰＵ２４２、ＲＡＭ２４４及びＲＯＭ２４６等を含み、情報処理に応じて各構成要素の制御を行なうように構成されている。
　通信Ｉ／Ｆ２６０は、インターネット１５を介して、ＳＤＴＭサーバ２００の外部に設けられた外部装置（たとえば、仮想センサ管理サーバ１００、アプリケーションサーバ３００及びセンサネットワーク部１４（図２参照））と通信するように構成されている。通信Ｉ／Ｆ２６０は、たとえば、有線ＬＡＮモジュールや無線ＬＡＮモジュールで構成される。
　記憶部２５０は、たとえば、ハードディスクドライブ、ソリッドステートドライブ等の補助記憶装置である。記憶部２５０は、たとえば、センサ側メタデータＤＢ２３０と、制御プログラム２５１とを記憶するように構成されている。
　図１２は、センサ側メタデータＤＢ２３０の一例を示す図である。図１２を参照して、センサ側メタデータＤＢ２３０は、センサネットワーク部１４（図２）に含まれる各実センサ１２の属性を示すメタデータを管理するデータベースである。センサネットワーク部１４に含まれる各実センサ１２のメタデータは、予めセンサ側メタデータＤＢ２３０に登録されている。センサ側メタデータＤＢ２３０においては、実センサ１２毎にメタデータが管理されている。
　センサ側メタデータには、たとえば、「基本属性」と「品質属性」とが含まれる。「基本属性」とは、実センサ１２に求められる基本的な条件であり、たとえば、「種別」、「観測対象」、「設置場所」が含まれる。
　「品質属性」とは、実センサ１２によって出力されるセンシングデータの品質に関連する属性であり、たとえば、「外れ値発生率」、「データ抜け発生率」、実センサ１２の「メーカ」等が「品質属性」に含まれる。また、これらの他にも「センサ状態属性」、「センサ設置属性」、「センサ保守履歴属性」、「データ仕様属性」、「データ分解能属性」等が「品質属性」に含まれてもよい。
　再び図１１を参照して、制御プログラム２５１は、制御部２４０によって実行されるＳＤＴＭサーバ２００の制御プログラムである。たとえば、制御部２４０が制御プログラム２５１を実行することによって、入力候補検索モジュール２１０及びデータフロー制御モジュール２２０（図２）が実現されてもよい。制御部２４０が制御プログラム２５１を実行する場合に、制御プログラム２５１は、ＲＡＭ２４４に展開される。そして、制御部２４０は、ＲＡＭ２４４に展開された制御プログラム２５１をＣＰＵ２４２によって解釈及び実行することにより、各構成要素を制御する。次に、制御プログラム２５１に従って制御部２４０によって実現される各ソフトウェアモジュールについて説明する。
　＜２－５．ＳＤＴＭサーバのソフトウェア構成例＞
　再び図２を参照して、ＳＤＴＭサーバ２００においては、制御部２４０によって、入力候補検索モジュール２１０及びデータフロー制御モジュール２２０の各々が実現される。以下、各ソフトウェアモジュールについて順に説明する。
　（２－５－１．入力候補検索モジュール）
　図１３は、入力候補検索モジュール２１０の詳細な構成の一例を示す図である。図１３の例では、入力候補検索モジュール２１０は、利用側データカタログ取得部２１１と、センサ側メタデータ取得部２１２と、提供側データカタログ生成部２１５と、マッチング部２１３と、入力候補取得部２１４とを含む。
　利用側データカタログ取得部２１１は、通信Ｉ／Ｆ２６０を介して、仮想センサ管理サーバ１００（入力候補管理モジュール１１０）から上述の利用側データカタログを取得する。
　センサ側メタデータ取得部２１２は、センサ側メタデータＤＢ２３０（図１２）に登録されている各実センサ１２に対応付けられているセンサ側メタデータ１３（図１）を取得する。
　提供側データカタログ生成部２１５は、センサ側メタデータ１３に基づいて、提供側データカタログを生成する。提供側データカタログは、センサ側メタデータＤＢ２３０に登録されている実センサ１２毎に生成される。提供側データカタログとは、提供側（各実センサ１２）の属性を示すカタログである。提供側データカタログには、センサ側メタデータ１３によって示される、実センサ１２の属性が含まれる。たとえば、提供側データカタログには、上述の「基本属性」及び「品質属性」が含まれる。
　マッチング部２１３は、利用側データカタログ取得部２１１によって取得された利用側データカタログと、提供側データカタログ生成部２１５によって生成された提供側データカタログとのマッチングを行なう。たとえば、提供側データカタログに含まれる実センサ１２の属性が、利用側データカタログに含まれる、処理モジュール１５０の入力データの条件を満たす場合に、マッチングが成立する。マッチングが成立すると、該提供側データカタログに対応する実センサ１２は、入力センサ候補として抽出される。一方、たとえば、提供側データカタログに含まれる実センサ１２の属性が、利用側データカタログに含まれる、処理モジュール１５０の入力データの条件を満たさない場合に、マッチングが不成立となる。マッチングが不成立となると、該提供側データカタログに対応する実センサ１２は、入力センサ候補に抽出されない。
　入力候補取得部２１４は、マッチング部２１３によって入力センサ候補に抽出された実センサ１２を特定可能な情報（実センサ情報）を取得する。入力候補取得部２１４によって取得された各実センサ情報は、通信Ｉ／Ｆ２６０を介して、仮想センサ管理サーバ１００（入力候補管理モジュール１１０）に送信される。
　（２－５－２．データフロー制御モジュール）
　図１４は、データフロー制御モジュール２２０の詳細な構成の一例を示す図である。図１４の例では、データフロー制御モジュール２２０は、センサ切替指令取得部２２１と、データフロー制御指令生成部２２２とを含む。
　センサ切替指令取得部２２１は、通信Ｉ／Ｆ２６０を介して、仮想センサ管理サーバ１００（セッション制御モジュール１３０）から上述のセンサ切替指令を取得する。センサ切替指令は、たとえば、現在処理モジュール１５０へ入力データを出力している実センサ１２（切り替え元の実センサ１２）の実センサ情報と、切り替え先の実センサ１２の実センサ情報とを含む。
　データフロー制御指令生成部２２２は、切り替え元の実センサ１２の実センサ情報と、切り替え先の実センサ１２の実センサ情報とに基づいて、データフロー制御指令を生成する。データフロー制御指令は、切り替え元の実センサ１２による処理モジュール１５０への入力データの出力停止指令と、切り替え先の実センサ１２による処理モジュール１５０への入力データの出力開始指令とを含む。出力停止指令は、通信Ｉ／Ｆ２６０を介して、切り替え元の実センサ１２に送信される。出力停止指令が切り替え元の実センサ１２に送信されると、切り替え元の実センサ１２によるセンシングデータの出力が停止される。一方、出力開始指令は、通信Ｉ／Ｆ２６０を介して、切り替え先の実センサ１２に送信される。切り替え先の実センサ１２は、たとえば、出力開始指令が受信された場合にセンシングデータの出力を許可するときは、出力先の処理モジュール１５０との通信を確立するためのＡＰＩ（Application Programming Interface）を仮想センサ管理サーバ１００へ送信する。仮想センサ管理サーバ１００において、該ＡＰＩが実行されることによって、切り替え先の実センサ１２から対象の処理モジュール１５０へのセンシングデータの出力が開始される。
　［３．動作例］
　＜３－１．入力候補の抽出動作例＞
　図１５は、処理モジュール１５０の入力センサ候補の抽出動作の一例を示すフローチャートである。このフローチャートに示される処理は、予め定められた周期で実行される。なお、上述の通り、入力センサ候補の抽出は各処理モジュール１５０の入力ポート毎に行なわれるが、ここでは１つの処理モジュール１５０の１つの入力ポートに着目して説明する。
　図１５を参照して、左方のフローチャートは、制御部１７０が入力候補管理モジュール１１０として動作することによって実行される。一方、右方のフローチャートは、制御部２４０が入力候補検索モジュール２１０として動作することによって実行される。
　図１５の左方を参照して、制御部１７０は、入力ポートに対応付けられている処理モジュール側メタデータ１６１を処理モジュール側メタデータＤＢ１６０（図５）から取得する（ステップＳ１００）。制御部１７０は、取得された処理モジュール側メタデータ１６１に基づいて利用側データカタログを生成する（ステップＳ１１０）。
　制御部１７０は、生成された利用側データカタログをＳＤＴＭサーバ２００に送信するように通信Ｉ／Ｆ１９０を制御する（ステップＳ１２０）。その後、制御部１７０は、通信Ｉ／Ｆ１９０を介してＳＤＴＭサーバ２００から入力センサ候補を示す情報（実センサ情報）が受信されたかを判定する（ステップＳ１３０）。実センサ情報が受信されていないと判定されると（ステップＳ１３０においてＮＯ）、制御部１７０は、実センサ情報が受信されるまで待機する。
　図１５の右方を参照して、制御部２４０は、利用側データカタログが受信されたか否かを判定する（ステップＳ２００）。利用側データカタログが受信されていないと判定されると（ステップＳ２００においてＮＯ）、制御部２４０は、利用側データカタログが受信されるまで待機する。
　利用側データカタログが受信されたと判定されると（ステップＳ２００においてＹＥＳ）、制御部２４０は、センサ側メタデータＤＢ２３０において管理されている各実センサ１２のセンサ側メタデータ１３を取得する（ステップＳ２１０）。制御部２４０は、取得されたセンサ側メタデータ１３に基づいて提供側データカタログを生成する（ステップＳ２２０）。
　制御部２４０は、取得された利用側データカタログと生成された提供側データカタログとに基づいて、センサ側メタデータＤＢ２３０によって管理されている複数の実センサ１２から入力センサ候補を抽出する（ステップＳ２３０）。
　たとえば、制御部２４０は、提供側データカタログによって示される属性（たとえば、「基本属性」及び「品質属性」）が利用側データカタログによって示される条件（たとえば、「基本条件」及び「品質条件」）を満たす場合に、該提供側データカタログに対応する実センサ１２を入力センサ候補として抽出する。たとえば、制御部２４０は、処理モジュール１５０の入力ポートの数以上の入力センサ候補を抽出する。たとえば、処理モジュール１５０の入力ポートの数が「３」である場合に、制御部２４０は、たとえば、４つ以上の入力センサ候補を抽出する。
　制御部２４０は、抽出された複数の実センサ情報を仮想センサ管理サーバ１００に送信するように通信Ｉ／Ｆ２６０を制御する（ステップＳ２４０）。
　再び図１５の左方を参照して、ステップＳ１３０において、複数の実センサ情報（入力センサ候補を示す情報）が受信されると（ステップＳ１３０においてＹＥＳ）、制御部１７０は、予め定められた基準に従って、各実センサ１２に優先順位を付与する（ステップＳ１４０）。
　その後、制御部１７０は、付与された優先順位に従って入力候補ＤＢ１４０を更新する（ステップＳ１５０）。すなわち、制御部１７０は、抽出された各入力センサ候補が付与された優先順位に従って管理されるように入力候補ＤＢ１４０を更新する。
　このように、仮想センサ管理サーバ１００及びＳＤＴＭサーバ２００においては、処理モジュール側メタデータ１６１及びセンサ側メタデータ１３に基づいて、各処理モジュール１５０の入力センサ候補が抽出される。すなわち、各処理モジュール１５０の入力データの条件が考慮された上で、入力センサ候補が抽出される。したがって、仮想センサ管理サーバ１００及びＳＤＴＭサーバ２００によれば、処理モジュール１５０へ入力データを出力する実センサ１２の適切な候補を予め抽出することができる。
　＜３－２．入力データの品質チェック動作例＞
　図１６は、処理モジュール１５０への入力データの品質チェック動作の一例を示すフローチャートである。このフローチャートに示される処理は、処理モジュール１５０へデータが入力されるタイミングで、制御部１７０が入力品質チェックモジュール１２０として動作することによって実行される。なお、上述の通り、入力データの品質チェックは、各処理モジュール１５０の入力ポート毎に行なわれるが、ここでは１つの処理モジュール１５０の１つの入力ポートに着目して説明する。
　図１６を参照して、制御部１７０は、処理モジュール１５０への入力データから入力メタデータを抽出する（ステップＳ３００）。制御部１７０は、抽出された入力メタデータをチェックする（ステップＳ３１０）。たとえば、制御部１７０は、入力ポートに対応付けられている処理モジュール側メタデータ１６１と、入力メタデータとに基づいて、入力データの品質チェックを行なう。たとえば、制御部１７０は、入力メタデータによって示される品質属性が処理モジュール側メタデータ１６１によって示される品質条件を満たす場合に、入力データの品質を「良」と判定する一方、入力メタデータによって示される品質属性が処理モジュール側メタデータ１６１によって示される品質条件を満たさない場合に、入力データの品質を「悪」と判定する。
　その後、制御部１７０は、入力メタデータに基づいて、入力データにアクシデントが生じていないか否かを判定する（ステップＳ３２０）。たとえば、制御部１７０は、入力メタデータに「文字化け」等が生じている場合に入力データにアクシデントが生じていると判定する。たとえば、制御部１７０は、入力データにアクシデントが生じていると判定された場合に入力データの品質を「悪」と判定する一方、入力データにアクシデントが生じていないと判定された場合に入力データの品質を「良」と判定する。
　入力品質チェックモジュール１２０（制御部１７０）は、ステップＳ３１０，Ｓ３２０における判定結果に基づく入力品質チェック結果をセッション制御モジュール１３０（制御部１７０）に通知する（ステップＳ３３０）。たとえば、入力品質チェックモジュール１２０は、ステップＳ３１０，Ｓ３２０の両方において品質が「良」と判定された場合に入力品質チェック結果を「良」と判定する一方、ステップＳ３１０，Ｓ３２０の少なくとも一方において品質が「悪」と判定された場合に入力品質チェック結果を「悪」と判定する。
　このように、仮想センサ管理サーバ１００においては、入力メタデータが処理モジュール１５０への入力データの品質属性を含む。そして、入力メタデータに基づいて、入力データの品質がチェックされる。すなわち、仮想センサ管理サーバ１００によれば、処理モジュール１５０への入力データの品質をチェックすることができる。
　＜３－３．セッション切替動作例＞
　図１７は、処理モジュール１５０と実センサ１２とのセッションの切替動作の一例を示すフローチャートである。このフローチャートに示される処理は、入力品質チェックモジュール１２０から入力品質チェック結果が通知された場合に、制御部１７０がセッション制御モジュール１３０として動作することによって実行される。なお、上述の通り、セッションの切り替えは、各処理モジュール１５０の入力ポート毎に行なわれるが、ここでは１つの処理モジュール１５０の１つの入力ポートに着目して説明する。
　図１７を参照して、制御部１７０は、通知された入力品質チェック結果に基づいて、セッションの切り替えの要否を判定する（ステップＳ４００）。たとえば、制御部１７０は、入力品質チェック結果が「良」である場合に切り替え不要と判定する一方、入力品質チェック結果が「悪」である場合に切り替え必要と判定する。
　次に、制御部１７０は、ステップＳ４００においてセッションの切り替えが必要と判定されたか否かを判定する（ステップＳ４１０）。切り替えが不要と判定されると（ステップＳ４１０においてＮＯ）、制御部１７０は、特に処理モジュール１５０の入力センサを切り替えず、セッションを維持する（ステップＳ４３０）。
　一方、切り替えが必要と判定されると（ステップＳ４１０においてＹＥＳ）、制御部１７０は、切替候補があるか否かを判定する（ステップＳ４２０）。たとえば、制御部１７０は、入力候補ＤＢ１４０において該当する入力ポートの入力センサ候補が管理されているか否かを判定する。たとえば、制御部１７０は、入力候補ＤＢ１４０において、該当する入力ポートの入力センサ候補が管理されている場合に切替候補があると判定する一方、該当する入力ポートの入力センサ候補が管理されていない場合に切替候補がないと判定する。
　切替候補がないと判定されると（ステップＳ４２０においてＮＯ）、制御部１７０は、特に処理モジュール１５０の入力センサを切り替えず、セッションを維持する（ステップＳ４３０）。一方、切替候補があると判定されると（ステップＳ４２０においてＹＥＳ）、制御部１７０は、入力候補ＤＢ１４０に管理されている入力センサ候補からいずれかの入力センサ候補（選択済み実センサ）を選択する（ステップＳ４４０）。
　その後、制御部１７０は、セッション切り替えのための処理を実行する（ステップＳ４５０）。たとえば、制御部１７０は、入力センサが選択済み実センサに切り替わるように、処理モジュール１５０の入力ポートを制御する。また、制御部１７０は、上述のセンサ切替指令をＳＤＴＭサーバ２００に送信するように通信Ｉ／Ｆ１９０を制御する。
　このように、仮想センサ管理サーバ１００においては、処理モジュール１５０の入力データが品質条件を満たさない場合に、入力センサが新たな実センサ１２に切り替えられる。したがって、仮想センサ管理サーバ１００によれば、品質条件を満たさないデータの処理モジュール１５０への入力が継続されないため、入力データの品質を維持することができる。
　また、仮想センサ管理サーバ１００においては、品質条件を満たす入力データを出力する実センサ１２が予め抽出され、処理モジュール１５０へ入力データを出力する実センサ１２が、予め抽出された実センサ１２のいずれかに切り替えられる。したがって、仮想センサ管理サーバ１００によれば、切り替え後の実センサ１２から品質条件を満たすデータが入力されるため、処理モジュール１５０への入力データの品質を維持することができる。
　＜３－４．データフロー制御動作例＞
　図１８は、データフロー制御動作の一例を示すフローチャートである。このフローチャートに示される処理は、通信Ｉ／Ｆ２６０を介して仮想センサ管理サーバ１００からセンサ切替指令が受信されるタイミングで、制御部２４０がデータフロー制御モジュール２２０として動作することによって実行される。なお、上述の通り、データフローの制御は、各処理モジュール１５０の入力ポート毎に行なわれるが、ここでは１つの処理モジュール１５０の１つの入力ポートに着目して説明する。
　図１８を参照して、制御部２４０は、通信Ｉ／Ｆ２６０を介して仮想センサ管理サーバ１００からセンサ切替指令を受信したか否かを判定する（ステップＳ５００）。センサ切替指令が受信されていないと判定されると（ステップＳ５００においてＮＯ）、制御部２４０は、センサ切替指令が受信されるまで待機する。
　一方、センサ切替指令が受信されたと判定されると（ステップＳ５００においてＹＥＳ）、制御部２４０は、上述のデータフロー制御指令を生成する（ステップＳ５１０）。制御部２４０は、生成されたデータフロー制御指令を、切り替え元の実センサ１２、切り替え先の実センサ１２等に送信する（ステップＳ５２０）。これにより、処理モジュール１５０と実センサ１２とのセッションの切り替えが完了する。
　［４．特徴］
　以上のように、本実施の形態において、制御部１７０，２４０は、入力候補ＤＢ１４０で管理されている複数の入力センサ候補から一部又は全部の実センサ１２を選択し、処理モジュール１５０の入力センサを選択された実センサ１２に切り替える。なお、入力候補ＤＢ１４０で管理されている複数の入力センサ候補の各々が出力する入力データは、処理モジュール１５０の入力データの品質条件を満たす。したがって、仮想センサ管理サーバ１００及びＳＤＴＭサーバ２００によれば、切り替え後の実センサ１２から品質条件を満たす入力データが出力されるため、処理モジュール１５０への入力データの品質を維持することができる。
　なお、処理モジュール１５０は、本発明の「処理モジュール」の一例であり、実センサ１２は、本発明の「デバイス」の一例であり、入力候補管理モジュール１１０と入力候補検索モジュール２１０とセッション制御モジュール１３０とを含む構成は、本発明の「セッション制御装置」の一例である。処理モジュール側メタデータ１６１に含まれる品質条件は、本発明の「条件」の一例である。マッチング部２１３は、本発明の「抽出部」の一例であり、入力候補選択部１３２は、本発明の「選択部」の一例であり、セッション切替部１３３は、本発明の「切替部」の一例である。
　［５．変形例］
　以上、実施の形態について説明したが、本発明は、上記実施の形態に限定されるものではなく、その趣旨を逸脱しない限りにおいて、種々の変更が可能である。以下、変形例について説明する。但し、以下の変形例は適宜組合せ可能である。
　＜５－１＞
　上記実施の形態においては、処理モジュール１５０の入力センサ候補が抽出された。しかしながら、抽出される対象は、必ずしも処理モジュール１５０の入力センサ候補でなくてもよい。たとえば、処理モジュール１５０に入力されるデータセットの候補が抽出されてもよい。データセットは、予め生成された複数のデータの集合である。たとえば、予め所定期間、対象を観測することによって得られたセンシングデータの集合は、データセットの一例である。たとえば、データセットは、インターネット１５に接続されたストレージに記憶されている。
　この場合には、たとえば、各データセットの属性を示すメタデータが、ＳＤＴＭサーバ２００において管理される。そして、各データセットに対応付けられたメタデータに基づいて、提供側データカタログが生成される。そして、利用側データカタログと提供側データカタログとに基づいて、処理モジュール１５０の入力データの条件を満たすデータセットが抽出される。すなわち、処理モジュール側メタデータ１６１と、各データセットに対応付けられたメタデータとに基づいて、複数のデータセットから、処理モジュール１５０の入力ポートの数よりも多くのデータセットの候補が抽出される。これにより、処理モジュール１５０の入力データの条件を満たす適切なデータセットを抽出することができる。
　また、上記実施の形態においては、処理モジュール１５０への入力データの品質がチェックされた。しかしながら、品質チェックの対象は、必ずしも入力データでなくてもよい。たとえば、処理モジュール１５０に入力されるデータセットの品質がチェックされてもよい。この場合に、データセットは、複数のデータと、複数のデータの各々の品質に関する属性を示すメタデータとで構成される。そして、たとえば、入力品質チェックモジュール１２０は、該メタデータに基づいて、該メタデータを含むデータセットの品質をチェックする。これにより、処理モジュール１５０へ入力されるデータセットの品質をチェックすることができる。
　また、上記実施の形態においては、処理モジュール１５０への入力データが品質条件を満たさない場合に、処理モジュール１５０の入力センサが新たな実センサ１２に切り替えられた。しかしながら、切り替え元及び切り替え先は、必ずしも実センサ１２でなくてもよい。たとえば、処理モジュール１５０への入力データが品質条件を満たさない場合に、処理モジュール１５０へ入力されるデータセットが新たなデータセットに切り替えられてもよい。
　また、上記の実施の形態においては、予め抽出された入力センサ候補から、切り替え先の実センサ１２が選択された。しかしながら、上述のように、予め抽出される対象はデータセットでもよく、切り替え先として選択される対象もデータセットであってもよい。この場合には、当然ながら、予め抽出された複数のデータセット候補の各々に含まれるデータは、処理モジュール１５０の入力データの品質条件を満たす。
　また、処理モジュール１５０の入力候補として予め抽出される対象、及び、処理モジュール１５０の入力の切り替え先として選択される対象の各々には、実センサ１２及びデータセットの両方が含まれてもよい。
　＜５－２＞
　また、上記実施の形態において、各処理モジュール１５０の各入力ポートは、いずれかの実センサ１２とセッションを行なうこととした。しかしながら、各入力ポートがセッションを行なう相手は、実センサ１２に限定されない。たとえば、セッション相手は、データセットを記憶したストレージであってもよいし、仮想センサであってもよい。セッション相手が必ずしもセンサである必要がないため、処理モジュール１５０の入力データは、必ずしもセンシングデータでなくてもよい。たとえば、入力データは、ショッピングサイトにおける各ユーザの購買履歴データや、ゲームサイトにおける各ユーザのスコアデータ等であってもよい。
　＜５－３＞
　上記実施の形態において、仮想センサ管理サーバ１００及びＳＤＴＭサーバ２００の各々によって行なわれた処理は、複数のサーバ等によって実現されてもよい。また、上記実施の形態において、仮想センサ管理サーバ１００及びＳＤＴＭサーバ２００によって行なわれた処理は、１つのサーバ等によって実現されてもよい。
　１０　仮想センサ管理システム、１１　センサネットワークアダプタ、１２　実センサ、１３　センサ側メタデータ、１５　インターネット、６０　メタデータ、７０　セッション制御装置、１００　仮想センサ管理サーバ、１１０　入力候補管理モジュール、１１１　メタデータ取得部、１１２　利用側データカタログ生成部、１１３　優先順位付与部、１１４　入力候補ＤＢ更新部、１２０　入力品質チェックモジュール、１２１　データフィルタリング部、１２２　メタデータチェック部、１２３　アクシデントチェック部、１３０　セッション制御モジュール、１３１　切替要否判定部、１３２　入力候補選択部、１３３　セッション切替部、１４０　入力候補ＤＢ、１５０　処理モジュール、１６０　処理モジュール側メタデータ、１７０，２４０　制御部、１７２，２４２　ＣＰＵ、１７４，２４４　ＲＡＭ、１７６，２４６　ＲＯＭ、１８０，２５０　記憶部、１８１，２５１　制御プログラム、１９０，２６０　通信Ｉ／Ｆ、２００　ＳＤＴＭサーバ、２１０　入力候補検索モジュール、２１１　利用側データカタログ取得部、２１２　センサ側メタデータ取得部、２１３　マッチング部、２１４　入力候補取得部、２２０　データフロー制御モジュール、２２１　センサ切替指令取得部、２２２　データフロー制御指令生成部、２３０　センサ側メタデータＤＢ、３００　アプリケーションサーバ。

Claims (8)

  1. 　処理モジュールと、前記処理モジュールへ入力データを出力するデバイスとのセッションを制御するように構成されたセッション制御装置であって、
    　前記処理モジュールは、少なくとも１つの前記入力データに基づいて前記入力データとは異なる出力データを生成するように構成されており、
    　前記処理モジュール毎に、前記入力データの品質に関する条件が規定されており、
    　前記セッション制御装置は、
    　複数のデバイスの候補を抽出するように構成された抽出部と、
    　前記複数のデバイスの候補から一部又は全部のデバイスを選択するように構成された選択部と、
    　前記処理モジュールへ前記入力データを出力するデバイスを前記選択部によって選択されたデバイスに切り替えるように構成された切替部とを備え、
    　前記複数のデバイスの候補の各々が出力する前記入力データは、前記条件を満たす、セッション制御装置。
  2. 　前記切替部は、前記処理モジュールに入力されている前記入力データが前記条件を満たさない場合に、前記処理モジュールへ前記入力データを出力する前記デバイスを、前記選択部によって選択されたデバイスに切り替えるように構成されている、請求項１に記載のセッション制御装置。
  3. 　前記デバイスは、センサであり、
    　前記入力データは、前記センサによって生成されたセンシングデータである、請求項１又は請求項２に記載の切替装置。
  4. 　前記処理モジュールは、複数の前記入力データに基づいて前記出力データを生成するように構成されている、請求項１から請求項３のいずれか１項に記載のセッション制御装置。
  5. 　前記処理モジュールと、前記処理モジュールへ前記入力データを出力する前記デバイスとによって仮想センサが形成される、請求項１から請求項４のいずれか１項に記載のセッション制御装置。
  6. 　処理モジュールと、前記処理モジュールへ入力するデータセットを保持するストレージとのセッションを制御するように構成されたセッション制御装置であって、
    　前記データセットは、複数のデータで構成されており、
    　前記処理モジュールは、少なくとも１つの入力データに基づいて前記入力データとは異なる出力データを生成するように構成されており、
    　前記処理モジュール毎に、前記入力データの品質に関する条件が規定されており、
    　前記セッション制御装置は、
    　複数のデータセットの候補を抽出するように構成された抽出部と、
    　前記複数のデータセットの候補から一部又は全部のデータセットを選択するように構成された選択部と、
    　前記処理モジュールへ入力するデータセットを前記選択部によって選択されたデータセットに切り替えるように構成された切替部とを備え、
    　前記複数のデータセットの候補の各々に含まれるデータは、前記条件を満たす、セッション制御装置。
  7. 　処理モジュールと、前記処理モジュールへ入力データを出力するデバイスとのセッションを制御するセッション制御方法であって、
    　前記処理モジュールは、少なくとも１つの前記入力データに基づいて前記入力データとは異なる出力データを生成するように構成されており、
    　前記処理モジュール毎に、前記入力データの品質に関する条件が規定されており、
    　前記セッション制御方法は、
    　複数のデバイスの候補を抽出するステップと、
    　前記複数のデバイスの候補から一部又は全部のデバイスを選択するステップと、
    　前記処理モジュールへ前記入力データを出力するデバイスを前記選択部によって選択されたデバイスに切り替えるステップとを含み、
    　前記複数のデバイスの候補の各々が出力する前記入力データは、前記条件を満たす、セッション制御方法。
  8. 　処理モジュールと、前記処理モジュールへ入力データを出力するデバイスとのセッションを制御する処理をコンピュータに実行させるためのプログラムであって、
    　前記処理モジュールは、少なくとも１つの前記入力データに基づいて前記入力データとは異なる出力データを生成するように構成されており、
    　前記処理モジュール毎に、前記入力データの品質に関する条件が規定されており、
    　前記プログラムは、
    　複数のデバイスの候補を抽出するステップと、
    　前記複数のデバイスの候補から一部又は全部のデバイスを選択するステップと、
    　前記処理モジュールへ前記入力データを出力するデバイスを前記選択部によって選択されたデバイスに切り替えるステップとをコンピュータに実行させるように構成されており、
    　前記複数のデバイスの候補の各々が出力する前記入力データは、前記条件を満たす、プログラム。
PCT/JP2018/043928 2018-02-13 2018-11-29 セッション制御装置、セッション制御方法及びプログラム WO2019159486A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/962,365 US11563814B2 (en) 2018-02-13 2018-11-29 Session control apparatus, session control method, and program
CN201880085789.1A CN111615690B (zh) 2018-02-13 2018-11-29 会话控制装置、会话控制方法以及程序

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018022958A JP6528869B1 (ja) 2018-02-13 2018-02-13 セッション制御装置、セッション制御方法及びプログラム
JP2018-022958 2018-02-13

Publications (1)

Publication Number Publication Date
WO2019159486A1 true WO2019159486A1 (ja) 2019-08-22

Family

ID=66821705

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/043928 WO2019159486A1 (ja) 2018-02-13 2018-11-29 セッション制御装置、セッション制御方法及びプログラム

Country Status (4)

Country Link
US (1) US11563814B2 (ja)
JP (1) JP6528869B1 (ja)
CN (1) CN111615690B (ja)
WO (1) WO2019159486A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005260914A (ja) * 2003-12-11 2005-09-22 Sony Internatl Europ Gmbh 動的な情報ソース管理
JP2011028325A (ja) * 2009-07-21 2011-02-10 Nec Corp 情報配信システム、情報端末、情報配信装置、情報配信方法、及び情報配信プログラム
JP2017111501A (ja) * 2015-12-14 2017-06-22 オムロン株式会社 データフロー制御装置およびデータフロー制御方法

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0711435B2 (ja) * 1985-07-23 1995-02-08 トヨタ自動車株式会社 内燃機関のセンサ異常判定方法
US6973396B1 (en) * 2004-05-28 2005-12-06 General Electric Company Method for developing a unified quality assessment and providing an automated fault diagnostic tool for turbine machine systems and the like
JP5080140B2 (ja) * 2007-06-13 2012-11-21 株式会社日立製作所 Ｉ／ｏデバイス切り替え方法
WO2008157503A1 (en) * 2007-06-15 2008-12-24 Shell Oil Company Remote monitoring systems and methods
US9137362B2 (en) * 2007-12-21 2015-09-15 Telecom Italia S.P.A. Method and system for managing communication sessions set-up between users
US8000909B2 (en) * 2009-05-27 2011-08-16 Dresser, Inc. System and method for monitoring and controlling pressure relief valve performance
US20150334016A1 (en) * 2009-11-26 2015-11-19 Nec Corporation Relay device
CN102083159A (zh) * 2009-11-30 2011-06-01 中国移动通信集团北京有限公司 一种移动通信系统中的切换控制方法及无线网络控制器
US20140201369A1 (en) 2011-08-12 2014-07-17 Omron Corporation Information management device, information management program, and information management method
JPWO2014030510A1 (ja) * 2012-08-22 2016-07-28 オムロン株式会社 デバイス管理装置及びデバイス管理方法
JP2014045242A (ja) 2012-08-24 2014-03-13 Oki Electric Ind Co Ltd 仮想センサ生成装置、仮想センサ生成方法およびプログラム
US9779183B2 (en) * 2014-05-20 2017-10-03 Allied Telesis Holdings Kabushiki Kaisha Sensor management and sensor analytics system
US20150248275A1 (en) * 2013-05-23 2015-09-03 Allied Telesis Holdings Kabushiki Kaisha Sensor Grouping for a Sensor Based Detection System
US20160048399A1 (en) * 2014-08-15 2016-02-18 At&T Intellectual Property I, L.P. Orchestrated sensor set
US10643457B2 (en) * 2014-10-17 2020-05-05 Alert Media, Inc. Event-driven safety notification based on automated incident monitoring
CN104902115A (zh) * 2015-06-03 2015-09-09 腾讯科技（深圳）有限公司 通信方法及通信终端
WO2017034922A1 (en) * 2015-08-25 2017-03-02 Volexity, Llc Systems methods and devices for memory analysis and visualization
EP3350658A4 (en) * 2015-09-16 2018-10-24 SZ DJI Technology Co., Ltd. Method and apparatus for operating mobile platform
WO2017169276A1 (ja) * 2016-03-30 2017-10-05 日本電気株式会社 プラント管理システム、プラント管理方法、プラント管理装置、および、プラント管理プログラム
US11317832B2 (en) * 2016-04-01 2022-05-03 Intel Corporation Sensor data management for multiple smart devices
US20170353704A1 (en) * 2016-06-01 2017-12-07 Apple Inc. Environment-Aware Supervised HDR Tone Mapping
US20180003572A1 (en) * 2016-07-01 2018-01-04 Exotag Inc. Sensor-Based Systems and Methods for Monitoring Temperature Sensitive Products
US10637878B2 (en) * 2017-02-28 2020-04-28 Micro Focus Llc Multi-dimensional data samples representing anomalous entities
US10604278B2 (en) * 2017-04-18 2020-03-31 General Electric Company Methods and apparatus to monitor health information of a turbine engine
WO2018200541A1 (en) * 2017-04-24 2018-11-01 Carnegie Mellon University Virtual sensor system
WO2018207350A1 (ja) * 2017-05-12 2018-11-15 三菱電機株式会社 時系列データ処理装置、時系列データ処理システムおよび時系列データ処理方法
DE102017211737B4 (de) * 2017-07-10 2019-03-28 Siemens Aktiengesellschaft Überwachungsvorrichtung und Verfahren zur Überwachung eines Systems
US10911494B2 (en) * 2017-08-08 2021-02-02 Ioannis Giokas Methods and systems for providing security to iot devices operating in an environment
US10695907B2 (en) * 2017-09-29 2020-06-30 Intel Corporation Methods and apparatus for monitoring robot health in manufacturing environments
US10884885B2 (en) * 2017-11-29 2021-01-05 International Business Machines Corporation Proactively predicting failure in data collection devices and failing over to alternate data collection devices
US10719832B1 (en) * 2018-01-12 2020-07-21 Wells Fargo Bank, N.A. Fraud prevention tool
US20200285997A1 (en) * 2019-03-04 2020-09-10 Iocurrents, Inc. Near real-time detection and classification of machine anomalies using machine learning and artificial intelligence

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005260914A (ja) * 2003-12-11 2005-09-22 Sony Internatl Europ Gmbh 動的な情報ソース管理
JP2011028325A (ja) * 2009-07-21 2011-02-10 Nec Corp 情報配信システム、情報端末、情報配信装置、情報配信方法、及び情報配信プログラム
JP2017111501A (ja) * 2015-12-14 2017-06-22 オムロン株式会社 データフロー制御装置およびデータフロー制御方法

Also Published As

Publication number Publication date
JP2019139553A (ja) 2019-08-22
US20200382604A1 (en) 2020-12-03
CN111615690A (zh) 2020-09-01
US11563814B2 (en) 2023-01-24
JP6528869B1 (ja) 2019-06-12
CN111615690B (zh) 2023-12-22

Similar Documents

Publication Publication Date Title
WO2019159484A1 (ja) 品質チェック装置、品質チェック方法及びプログラム
WO2019159483A1 (ja) デバイス選択装置、データセット選択装置、デバイス選択方法及びプログラム
WO2019159486A1 (ja) セッション制御装置、セッション制御方法及びプログラム
WO2019159485A1 (ja) セッション制御装置、セッション制御方法及びプログラム
WO2019159482A1 (ja) 候補抽出装置、候補抽出方法及びプログラム
JP2019169946A (ja) 品質チェック装置、品質チェック方法及びプログラム
JP6477935B1 (ja) 前処理判定装置、前処理判定方法及びプログラム
JP6320569B2 (ja) 宅内制御装置および宅内制御システム
CN111566630B (zh) 数据处理装置、数据处理方法及程序
WO2019159490A1 (ja) 出力管理装置、出力管理方法及びプログラム
WO2019159489A1 (ja) 出力管理装置、出力管理方法及びプログラム
WO2020049759A1 (ja) データ処理装置、データ処理方法及びデータ処理プログラム
WO2019171677A1 (ja) データ出力装置、データ出力方法及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18906693

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18906693

Country of ref document: EP

Kind code of ref document: A1