WO2020129995A1 - 情報処理システム、方法およびプログラム - Google Patents

情報処理システム、方法およびプログラム Download PDF

Info

Publication number
WO2020129995A1
WO2020129995A1 PCT/JP2019/049472 JP2019049472W WO2020129995A1 WO 2020129995 A1 WO2020129995 A1 WO 2020129995A1 JP 2019049472 W JP2019049472 W JP 2019049472W WO 2020129995 A1 WO2020129995 A1 WO 2020129995A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
common
ontology
resource
exchange
Prior art date
Application number
PCT/JP2019/049472
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 US17/414,284 priority Critical patent/US11843678B2/en
Publication of WO2020129995A1 publication Critical patent/WO2020129995A1/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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions

Definitions

  • the embodiment of the present invention relates to an information processing system, method and program.
  • OneM2M is a collection of common functions CSE (Common Service Entity) that is independent of communication methods such as data management and device management, and data mapping and exchange with other standard protocols (protocol). Interworking Proxy Entity) and AE (Application Entity) that utilizes the collected data.
  • CSE Common Service Entity
  • AE Application Entity
  • an application program hereinafter sometimes referred to as an application or application
  • mca interface between CSE-AE (Application Entity)
  • IoT data is managed by extremely silos by each business operator (data provider) who collects the data, and each business operator's unique IoT-PF API (Application Programming Interface) )) and the data model are different.
  • composite data is obtained.
  • the advanced traffic jam prediction service service
  • the meteorological data is provided to the composite data utilization application via the IoT-PF and API/data model specific to the first operator.
  • the traffic flow data is provided to the composite data utilization application via the IoT-PF and API/data model unique to the second operator.
  • the event holding data is provided to the composite data utilization application via the IoT-PF and API/data model unique to the third operator. In such a case, it is necessary to continuously support all APIs and data models for each data provider, which makes continuous data utilization difficult.
  • IoT data is managed in a highly siled manner for each collected IoT-PF operator, but the API and data model (including data structure and vocabulary) are unified among various PFs. The probability is extremely low. Further, the edge PF may be realized by a plurality of operators, and the API is different between the cloud and the edge, and thus diversified, so that the portability of the application is reduced.
  • IWK Specific Interworking
  • the conversion proxy between the standard A_Device and the common PF includes standard-dependent I/O conversion, Data Mapping A specific to standard A, and IWK Procedures A specific to standard A
  • the conversion proxy between technology B PF and common PF must include standard-dependent I/O conversion, Data Mapping B specific to standard B, and IWK Procedures B specific to standard B
  • Standard The conversion proxies between the C PF and the common PF include standard-dependent I/O conversions, Standard C-specific Data Mapping C, and Standard C-specific IWK Procedures C.
  • the present invention has been made in view of the above circumstances, and an object thereof is to exchange data in a short-term and low-cost mutual cooperation without individually supporting each data standard. It is to provide an information processing system, a method, and a program capable of performing.
  • one aspect of an information processing system is a common platform server which is connected to devices corresponding to a plurality of unique standards and exchanges data with an application.
  • An information processing system having a conversion proxy further connected to the conversion proxy, wherein the conversion proxy includes an acquisition unit for acquiring ontology data in which a data structure corresponding to the specific standard is described by an ontology, and the plurality of types.
  • a device management unit that acquires and manages unique device information associated with a device corresponding to a unique standard, based on ontology data acquired by the acquisition unit and device information managed by the device management unit A resource associated with a data structure common to the plurality of unique standards and a data exchange interface corresponding to the unique standard, and using the created resource to communicate with the common platform server. And a common exchange section for exchanging data.
  • One aspect of an information processing method is to connect a device compatible with a plurality of unique standards and further connect to a common platform server that exchanges data with an application.
  • An information processing method performed by an information processing system having a proxy, wherein the conversion proxy acquires ontology data in which a data structure corresponding to the unique standard is described by an ontology, and supports the plurality of unique standards.
  • the conversion proxy acquires ontology data in which a data structure corresponding to the unique standard is described by an ontology, and supports the plurality of unique standards.
  • unique device information associated with the device and based on the acquired ontology data and the managed device information, a data structure common to the plurality of types of unique standards, and A resource associated with a data exchange interface corresponding to a specific standard is created, and data is exchanged with the common platform server using the created resource.
  • FIG. 1 is a diagram showing an example of Ontology based IWK applied to an information processing system according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing a configuration example when Ontology based IWK is applied to the information processing system according to the embodiment of the present invention.
  • FIG. 3 is a diagram showing a configuration example of the information processing system according to the embodiment of the present invention.
  • FIG. 4 is a diagram showing an example of a part of oneM2M base ontology used in the information processing system according to the embodiment of the present invention.
  • FIG. 5 is a diagram showing an example of abstraction of a data structure.
  • FIG. 6 is a diagram illustrating storage of only the latest value.
  • FIG. 7 is a diagram illustrating an example of an ontology extension field.
  • FIG. 1 is a diagram showing an example of Ontology based IWK applied to an information processing system according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing a configuration example when Ontology
  • FIG. 8 is a diagram illustrating an example of a workflow when connecting to a conversion proxy.
  • FIG. 9 is a diagram illustrating an example of a sequence at the time of connecting a conversion proxy.
  • FIG. 10 is a diagram showing an example of a workflow for exchanging InputDataPoint.
  • FIG. 11 is a diagram showing an example of a sequence of InputDataPoint exchange.
  • FIG. 12 is a diagram showing an example of a workflow for exchanging OutputDataPoint.
  • FIG. 13 is a diagram showing an example of a sequence of OutputDataPoint exchange.
  • FIG. 14 is a diagram illustrating an example of standardizing a data exchange flow with another standard.
  • FIG. 15 is a diagram illustrating an example of accumulation of time series data.
  • FIG. 16 is a diagram illustrating an example of the ontology extension field.
  • FIG. 17 is a diagram showing an example of a data exchange workflow.
  • FIG. 18 is a diagram illustrating an example of a data exchange workflow.
  • FIG. 19 is a diagram showing an example of a data exchange sequence.
  • FIG. 20 is a diagram showing an example of a procedure of time series data accumulation.
  • FIG. 21 is a diagram showing an example of time series data accumulation.
  • FIG. 22 is a diagram illustrating an example of a data exchange workflow.
  • FIG. 23 is a diagram showing an example of a data exchange workflow.
  • FIG. 24 is a diagram showing an example of a data exchange sequence.
  • FIG. 25 is a diagram showing an example of a procedure of time series data accumulation.
  • FIG. 26 is a diagram showing an example of time series data accumulation.
  • FIG. 27 is a diagram illustrating an example of acquisition by on-demand.
  • FIG. 28 is a diagram illustrating an example of the ontology extension field.
  • FIG. 29 is a diagram showing an example of a data exchange workflow.
  • FIG. 30 is a diagram illustrating an example of a data exchange workflow.
  • FIG. 31 is a diagram showing an example of a data exchange sequence.
  • FIG. 32 is a diagram illustrating an example of an on-demand acquisition procedure.
  • FIG. 33 is a diagram illustrating an example of on-demand acquisition.
  • FIG. 34 is a diagram illustrating an example of batch acquisition by on-demand.
  • FIG. 35 is a diagram illustrating an example of the ontology extension field.
  • FIG. 36 is a diagram illustrating an example of a data exchange workflow.
  • FIG. 37 is a diagram showing an example of a data exchange sequence.
  • FIG. 38 is a diagram illustrating an example of batch acquisition by on-demand.
  • FIG. 39 is a block diagram showing an example of the
  • the operator of the data distribution infrastructure can complete the infrastructure setting with low development cost.
  • the structure of the data in the common PF is standardized. For this reason, the method of data acquisition is uniquely determined for the data utilization application, and the development and modification of the application become easy.
  • a pattern is divided into a data storage state and a data storage location, a processing flow is designed for each pattern, and the above abstraction is performed. Switching of the data exchange method is realized in units. This optimizes data storage with a simple configuration and maintains the performance of the infrastructure.
  • a data representation across different standards is structured by an ontology, and a common data exchange flow for a highly abstracted data representation is designed. As a result, the process of exchanging data between different standards and oneM2M is standardized.
  • FIG. 1 is a diagram showing an example of Ontology based IWK applied to an information processing system according to an embodiment of the present invention.
  • an ontology based IWK for converting data from IoT standards A, B, C to a common PF according to oneM2M conversion proxy between standard A_Device and common PF, technology B PF and common PF
  • conversion proxy between standard A_Device and common PF, technology B PF and common PF Between the standard C PF and the standard PF and the common PF include common Base Ontology Derived Model Mapping and Common IWK Procedures, respectively.
  • Be done. 1 shows a conversion procedure
  • b shown in FIG. 1 shows a standard-dependent I/O conversion.
  • FIG. 2 is a diagram showing a configuration example when Ontology based IWK is applied to the information processing system according to the embodiment of the present invention.
  • the A company IoT-PF is connected to the common PF server (server) via the A company IoT-PF compatible ontology creation GUI (graphical user interface) and conversion proxy.
  • the B company IoT-PF is connected to the common PF server via the B company IoT-PF compatible ontology creation GUI and the conversion proxy.
  • the C company IoT-PF is connected to the common PF server via the C company IoT-PF compatible ontology creation GUI and the conversion proxy.
  • FIG. 1 the example shown in FIG.
  • the sensor device is connected to the common PF server via the ontology creation GUI and the conversion proxy corresponding to the standard of the sensor device provider.
  • the common PF server realizes a highly abstract API and data structure to exchange data with various applications such as the composite data utilization application ⁇ , the composite data utilization application ⁇ , and the composite data utilization application ⁇ .
  • 2 shows a conversion procedure and ontology creation GUI
  • b shown in FIG. 2 shows a sensor device.
  • the structure of data processed by the common PF is standardized. Therefore, the method of data acquisition is uniquely determined for the data utilization application, and the application development and modification become easy. Also, simple settings can optimize data storage and preserve the performance of the infrastructure.
  • FIG. 3 is a diagram showing a configuration example of the information processing system according to the embodiment of the present invention.
  • the data processing device 10 provided corresponding to each operator is a device such as a sensor corresponding to a plurality of unique standards.
  • a common PF server 30 that exchanges data with an application, respectively, via a communication network.
  • the data processing device 10 is provided for each of the above standards and is connected to a device compatible with the relevant standard.
  • the functions of the data processing device 10 and the common PF server 30 include a processor such as a CPU (Central Processing Unit) that executes a program, a storage medium such as a RAM (Random Access Memory) and a ROM (Read Only Memory), and a keyboard. It is realized by using an input device such as (keyboard) and a display device such as a display.
  • a processor such as a CPU (Central Processing Unit) that executes a program
  • a storage medium such as a RAM (Random Access Memory) and a ROM (Read Only Memory)
  • keyboard Random Access Memory
  • an input device such as (keyboard)
  • a display device such as a display.
  • the data processing device 10 has an ontology creation GUI and a conversion proxy.
  • the ontology creation GUI includes an ontology creation unit (O, sometimes referred to as an ontology creation unit) 11.
  • the conversion proxy includes an ontology reading unit (A, sometimes referred to as an ontology reading unit) 21, a device management unit (B, sometimes referred to as a device management unit) 22, a sensor data exchange unit (C, sensor). Data exchange unit 23) and common exchange unit 24 (D, common exchange unit).
  • A ontology reading unit
  • B device management unit
  • C sensor data exchange unit
  • D common exchange unit
  • the ontology reading unit 21 acquires ontology data in which a data structure corresponding to a unique standard is described by the ontology.
  • the ontology reading unit 21 has an ontology data storage unit (sometimes referred to as storage unit X) 21a.
  • the device management unit 22 acquires device information unique to a device corresponding to a specific standard, and manages this device information.
  • the device management unit 22 has a device information storage unit (sometimes referred to as a storage unit Y) 22a.
  • the sensor data exchange unit 23 is connected with a sensor, device or PF of the business operator.
  • the sensor data exchange unit 23 has a sensor data storage unit (may be referred to as a storage unit Z) 23a.
  • the common exchanging unit 24 Based on the ontology data acquired by the ontology reading unit 21 and the device information managed by the device management unit 22, the common exchanging unit 24 supports a data structure common to a plurality of types of unique standards and a unique standard. A resource associated with the data exchange interface that was created. The common exchange unit 24 exchanges data with the common PF server 30 using this resource.
  • the common PF server 30 is provided as one server common to each standard, and has a data storage unit (sometimes referred to as E, data storage unit) 31, a data search unit (expressed as F, data search unit). Sometimes 32).
  • the data storage unit 31 includes an ontology data storage unit (may be referred to as a storage unit V) 31a in which an ontology file (.owl(Web Ontology Language)) in which a data structure is described is stored, and data. It has a tree (data tree) storage unit (may be referred to as a storage unit W) 31b).
  • the data tree is composed of, for example, “
  • the ontology reading unit 21, the device management unit 22, the common exchange unit 24, the data storage unit 31, and the data search unit 32 can be commonly provided for various standards, and the sensor data exchange unit 23 is provided for each standard.
  • Ontology reader ⁇ Input: owl file created by GUI
  • Output Ontology entity relationship map (relationship between Device, Service, Service, DataPoint)
  • B Device management part
  • Input Sensor output (when sensor is connected), PF Device Discovery API (when PF is connected)
  • -Output Device information map ( ⁇ Device ID, Device Name ⁇ )
  • C Sensor data exchange unit
  • Data Discovery API Value described in Ontology Service and DataPoint entity
  • Output Sensor data (Temperature: 37°C, Humidity: 50%, etc.), Command (switchON).
  • D Common exchange unit ⁇ Input: Device information from device management unit, sensor data from sensor data exchange unit ⁇ Output: Data exchange request (request) to server (resource creation, data update, etc.)
  • E Data storage unit-Input: Data exchange request from conversion proxy from common exchange unit-Output: Resource creation
  • F Data search unit-Input: SPARQL (RDF (Resource Description Framework) query (query) language) query -Output: Data acquisition URI (Uniform Resource Identifier), data value
  • O ontology creation unit-Input: Manual input-Output: IWK ontology (.owl)
  • the oneM2M Base Ontology is used to abstract the data structure of each different standard, and the information of the abstracted data structure is machine-readable by using RDF. Described, knowledge such as the relationship between data and device is structured as metadata, and data information is associated.
  • FIG. 4 is a diagram showing an example of a part of oneM2M base ontology used in the information processing system according to the embodiment of the present invention.
  • the IoT device (Device) resource transmits/receives data at the time of IWK to/from another standard via a service (Service) resource (may be referred to as a service).
  • Service service
  • a DataPoint resource (may be referred to as DataPoint) is defined below the service resource.
  • the classes “Device” and “Service” are associated with the property “property” “hasService”
  • the classes “Service” and “OutputDataPoint” are associated with the property “hasOutputDataPoint”
  • the classes “Service” and “Service” “InputDataPoint” is associated with the property “hasInputDataPoint”
  • classes “Device” and “Thing” are associated with the property "is-a”.
  • a hierarchical relationship is defined by expressing a child device and a child service by using a “ConsistsOf” field as shown in FIG.
  • FIG. 5 is a diagram showing an example of abstraction of a data structure.
  • the same operation as the RPC function is defined for different types of RPC (Remote Procedure Call) interfaces.
  • RPC Remote Procedure Call
  • FIG. 5 when a device resource called “Washing machine” has a service resource called “Switch (OnService)” and a DataPoint is used, InputDataPoint is used. Switch ON/OFF to get the current state of the switch from the OutputDataPoint.
  • Form 1 (Basic form): The latest value in the common PF is updated (only the latest value is saved).
  • Form 2. Extended form: Time series data (Time Series) is accumulated in the common PF (time series data accumulation).
  • Form 3. Extended form: Data is acquired (acquired by on-demand) from other standard PF/Device only at the time of request from application.
  • Form 4. Extended form: At the time of request from the application, the data accumulated in other standard PF/Device is collectively acquired (collective acquisition on demand).
  • FIG. 6 is a diagram illustrating storage of only the latest value.
  • OBI Ontology Based Interworking
  • FIG. 7 is a diagram illustrating an example of the ontology extension field.
  • the common PF server 30 supports the ontology of the abstracted data structure and other standards by using the metadata field "standard name: hasAPI" which is defined to store the latest data from devices of other standards. And the associated data exchange interface.
  • API another standard interface for sending and receiving DataPoint
  • metadata field metadata field
  • hasAPI eg:DWAPI(DeviceWebAPI):hasAPI
  • the API when a service of another standard is called can also be described.
  • the metadata field “standard name: hasUnit” is designed, and the data unit defined by another standard is described in the ontology.
  • the classes “Device” and “Service” are related by the property “hasService”, and the classes “Service” and “OutputDataPoint” are related by the property “hasOutputDataPoint”.
  • the classes “Service” and “InputDataPoint” are related by the property “hasInputDataPoint”, and the classes “Device” and “Thing” are related by the property "is-a”.
  • the class “Service” is associated with the class “Unit” by the metadata field "Protocol: hasAPI”
  • the class “OutputDataPoint” is associated with the class “Unit” by the metadata field “Protocol: hasAPI”
  • the class “Service” is associated with the class “Unit” by the metadata field "Protocol: hasAPI”.
  • FIG. 8 is a diagram illustrating an example of a workflow when connecting to a conversion proxy.
  • FIG. 9 is a diagram illustrating an example of a sequence when a conversion proxy is connected. This workflow and sequence is based on Form 1. ⁇ 4. Common to.
  • the conversion proxy reads the ontology, and common processing of Device/Service/InputDataPoint/OutputDataPoint is performed according to the contents of the ontology.
  • the ontology reading unit 21 reads the ontology file created by the ontology creating unit 11 and stores the ontology file in the storage unit X (S11).
  • the ontology reading unit 21 creates an OBI Client for the common exchange unit 24 and registers the ontology.
  • the common exchange unit 24 creates a resource for the conversion proxy and sends this resource to the data storage unit 31 of the common PF server 30. Further, the common exchange unit 24 stores the ontology data immediately below the resource representing the conversion proxy with the storage unit Y as the storage destination.
  • the device management unit 22 acquires the device information from the PF/Device of another standard (S12), and if the device indicated by this device information is a new device, the device list (device list) ⁇ Device ID, Device Name ⁇ is displayed. The device information is updated and this device information is transmitted to the common exchange unit 24.
  • the common exchange unit 24 determines whether or not the Device indicated by the device information acquired from the device management unit 22 is in the ontology (S13), and when this Device is not in the ontology (No in S13), the device It is determined that the Device indicated by the information does not correspond to the ontology, and the information related to this Device is deleted from the device list. On the other hand, when the Device indicated by the device information is in the ontology (Yes in S13), the common exchange unit 24 creates a Device Wrapper and stores the Device Wrapper in the storage units W and V of the data storage unit 31. Yes (S14). The data storage unit 31 uses the Device Wrapper to create a Device resource, which is a type of conversion proxy resource, and stores this resource in the storage units W and V in the data storage unit 31 (S15).
  • the common exchange unit 24 creates a Service Wrapper and stores the Service Wrapper in the storage units W and V of the data storage unit 31 (S18).
  • the data storage unit 31 creates a Service resource, which is a type of conversion proxy resource, using the Service Wrapper, and stores this resource in the data storage unit 31 storage units W and V (S17).
  • the common exchange unit 24 determines whether there is an unprocessed Service resource in the lower layer of the Device resource in the ontology (S19), and if there is an unprocessed Service resource (Yes in S19), transitions to S18. To do. If there is no unprocessed Service resource (No in S19), the common exchange unit 24 confirms the presence or absence of InputDataPoint (S20), and if there is InputDataPoint (Yes in S20), the Subscription resource is placed below the Service resource. The resource is created and stored in the storage unit W of the data storage unit 31 (S21). Subscription resource is a type of common PF data resource. When a Subscription resource is placed underneath other resources (eg: Service resource), a notification will be sent when the resource has updates. The notification destination is described in the Subscription resource. After S21, the process proceeds to S22 and the InputDataPoint exchange flow (S31 to S36) described later.
  • the common exchange unit 24 When there is no InputDataPoint (No in S20), the common exchange unit 24 confirms the existence of OutputDataPoint (S22), and when there is no OutputDataPoint (No in S22), the process ends. On the other hand, when there is OutputDataPoint (Yes in S22), the common exchange unit 24 creates a sensor data acquisition subflow (Stores OutputDataPoint and other standard API of the parent Service acquired from the storage unit X in the workflow). (S23). After S23, the process moves to the OutputDataPoint exchange flow (S41 to S47) described later.
  • FIG. 10 is a diagram showing an example of a workflow of exchanging InputDataPoint
  • FIG. 11 is a diagram showing an example of a sequence of exchanging InputDataPoint. This workflow and sequence are of the form 1. ⁇ 4. Common to. In the InputDataPoint exchange, another standard API described in the ontology is used to perform common processing of InputDataPoint (send data/command to another standard PF or device).
  • the data search unit 32 of the common PF server 30 searches the storage unit V of the data storage unit 31 by SPARQL from the application, and finds Device and Service, InputDataPoint under this Device (for example, “Device : WashingMaching”, “
  • the data search unit 32 updates (eg, Switch: ON) the InputDataPoint attribute in the lower layer of the Service resource in the storage unit W of the data storage unit 31 (S32).
  • the data storage unit 31 sends a notification to the conversion proxy specified in the Subscription resource below this service resource (S33).
  • the common exchange unit 24 of the conversion proxy determines whether or not the InputDataPoint is an InputDataPoint corresponding to an ontology (S34), and if it is not an ontology-compatible InputDataPoint (No in S34), the process ends. On the other hand, if the InputDataPoint is an InputDataPoint corresponding to the ontology (Yes in S34), the common exchange unit 24 reads this InputDataPoint and the API of another standard corresponding to the parent Service from the ontology, and the read result is the sensor data. It is sent to the exchange section 23 (S35). Then, the sensor data exchange unit 23 sends a command to the PF or device of another standard by using the API of another standard (S36).
  • FIG. 12 is a diagram showing an example of a workflow of OutputDataPoint exchange
  • FIG. 13 is a diagram showing an example of a sequence of OutputDataPoint exchange. This workflow and sequence is based on Form 1. ⁇ 4. Common to. In OutputDataPoint exchange, common processing of OutputDataPoint (acquiring data/command from another standard PF or device) is performed using another standard API described in the ontology.
  • the sensor data exchange unit 23 acquires the sensor data from the storage unit Z by using the OutputDataPoint and the other standard API of the parent Service (S41). The sensor data exchange unit 23 determines whether or not the sensor data can be converted into the DataType set in the ontology (S42). If the sensor data cannot be converted (No in S42), the process ends abnormally (Thread). If the conversion is possible (Yes in S42), the sensor data exchange unit 23 converts the sensor data into the DataType of this OutputDataPoint set in the ontology, and sends the OutputDataPoint value to the common exchange unit 24 (S43).
  • the common exchange unit 24 requests the data storage unit 31 to update the resource value of OutputDataPoint (S44).
  • the data storage unit 31 updates the resource value of OutputDataPoint in the storage unit W (S45).
  • the data storage unit 31 determines whether or not there is a subscription resource under this OutputDataPoint (S46). If this subscription resource does not exist (No in S46), the process ends normally (Thread).
  • the data storage unit 31 sends the latest value of OutputDataPoint to the application specified by the subscription resource (S47), and ends normally (Thread).
  • FIG. 14 is a diagram illustrating an example of standardizing a data exchange flow with another standard.
  • a common data exchange flow is designed regardless of various data structures with respect to other standards.
  • the instances “getData” and “ManageDev” belong to the class “Service”
  • the instances “Temperature”, “Humidity” and “CO2” belong to the class “OutputDataPoint”
  • the instance “Interval” belongs to the class “InputDataPoint”.
  • the instance “EnvSensor” is associated with the instances “getData” and “ManageDev” by the property “hasService”
  • the instance “getData” is associated with the instances “temperature”, “humidity”, and “CO2” by the property “hasOutputDataPoint”.
  • the instance “ManageDev” is associated with the instances “Interval” and “Switch” by the property “hasInputDataPoint”.
  • the instance “EnvSensor” is associated with the instance “environment sensor” by the property “is-a”.
  • the instance “ManageDev” is associated with another standard API (instance) “Sensor/Service1” by the property “hasAPI”.
  • the instance “getData” is associated with another standard API “Sensor/Service2” by the property “hasAPI”.
  • the instance “temperature” is associated with another standard API “DATA:arg(argument)1” by the property “hasAPI”.
  • the instance “humidity” is associated with another standard API “DATA:arg2” by the property “hasAPI”.
  • the instance “CO2” is associated with another standard API “DATA:arg3” by the property “hasAPI”.
  • the instance “Interval” is associated with another standard API “DATA:arg4" by the property “hasAPI”.
  • the instance “Switch” is associated with another standard API "DATA:arg5" by the property “hasAPI”.
  • Other standard APIs “DATA:arg1”, “DATA:arg2”, “DATA:arg3”, “DATA:arg4”, and “DATA:arg5” are associated with the class “API”.
  • the device discovery API of another standard is used to obtain a list of connected devices.
  • other standards eg: LoRa(Long Range)
  • analysis is performed from the data acquired for each device for the first time, and the field indicating the device type (EnvSensor) is extracted (in Fig. 14). a).
  • SPARQL which is the RDF query language (BO stands for Base Ontology) ⁇ ?Device RDFS:subClassof BO:Device ⁇ Is used to determine if the device type is present in the predefined abstract ontology. If the device indicated by this device type is a device that the ontology supports, a resource (device AE (Application Entity)) representing the device is created in the resource tree on the oneM2M side as common processing.
  • device AE Application Entity
  • the service (getData and ManageDev) that the device type (EnvSensor) has is the SPARQL below.
  • a resource expressed as ⁇ FC> (flexContainer) is created on the oneM2M side for the extracted service.
  • DWAPI Sensor/Service1 etc.
  • OutputDataPoint is determined for each of the extracted services as in (a) below (c in FIG. 14). ⁇ ?Service BO:hasOutputDataPoint ?o ⁇ ...(a) If OutputDataPoint exists, a new data acquisition thread is created for the stored other standard API of the service, and data reception preparation is performed. Then, the other standard API (eg: DWAPI:DATA:arg1) of each OutputDataPoint in the ontology is acquired and held by the metadata field (DWAPI:hasAPI).
  • DWAPI:DATA:arg1 DWAPI:DATA:arg1
  • the presence or absence of the corresponding InputDataPoint for each service is determined by SPARQL shown in (b) below.
  • ⁇ Subscription> resource mainly composed of IPE is created under the ⁇ FC> resource of the service created in oneM2M, and when the value of InputDataPoint is changed on oneM2M side, IPE Will be received.
  • the other standard API of the corresponding InputDataPoint is used to update the other standard device (d in FIG. 14).
  • Ontology information corresponding to the ⁇ SD> (Semantic Descriptor) resource under the oneM2M resource representing the device and service shown in FIG. 14 is stored according to the following rules (a) and (a): A machine-readable device service discovery and data acquisition interface called the SPARQL language is provided to the AE.
  • the part between Device and Service is stored in ⁇ SD> of each device.
  • the part between Service and DataPoint is stored in ⁇ SD> under each service resource.
  • FIG. 15 is a diagram illustrating an example of accumulation of time series data. The problems in accumulating time series data will be described. Originally, in the oneM2M OBI, only the latest value was stored in the common PF, so when an analysis that requires past time series information is performed (for example, an analysis such as a Kalman filter or an event log ( It was not possible to deal with (event log) fault isolation, etc.) unless data was saved on the application side.
  • an analysis such as a Kalman filter or an event log ( It was not possible to deal with (event log) fault isolation, etc.
  • FIG. 16 is a diagram illustrating an example of the ontology extension field.
  • the metadata field “standard name: storeTimeseries” that defines that the common PF server 30 stores time series data from devices of other standards is used. Series history data is stored on the common PF.
  • FIG. 17 and 18 are diagrams showing an example of a data exchange workflow
  • FIG. 19 is a diagram showing an example of a data exchange sequence.
  • the Boolean value of storeTimeseries subordinate to the Service resource described in the ontology is used to perform common history data storage processing of OutputDataPoint subordinate to the Service resource.
  • the ontology reading unit 21 determines whether or not storeTimeseries of Service is true (S51). If true, the ontology reading unit 21 sets flag of storeTSforService in the storage unit X to true (S52). ).
  • the common exchange unit 24 determines whether or not the child resource of the Service resource in the storage unit W of the data storage unit 31 has a time-series data storage resource (S53). If there is no time-series data storage resource (No in S53), the common exchange section 24 creates this as a child resource of the Service resource in the storage section W of the data storage section 31 (S54).
  • the sensor data exchange unit 23 acquires the sensor data from another PF and transmits the sensor data to the common exchange unit 24.
  • the common exchange unit 24 updates the sensor data in the data storage unit 31 (updates the value of OutputDataPoint) with the transmitted sensor data. If No in S51, Yes in S53, or after S54, the above OutputDataPoint exchange flow (S41 to S47) is performed.
  • the common exchange unit 24 determines whether or not the Flag of storeTSforService is true (S55). If not true (No in S55), the process ends, and if true (S55). Yes), the OutputDataPoint of the Service is merged into one JSON, and the merged result is sent to the data storage unit 31 (S56).
  • the common exchange unit 24 adds the sent JSON to the time-series data storage resource and sends it to the data storage unit 31 (S57), and the process ends.
  • the process from acquisition of sensor data to S57 is repeated at the set cycle.
  • the data search unit 32 confirms the storeTimeseries in the ontology data by SPARQL, acquires the URI data, and sends this data to the application (S58).
  • the application requests the data storage unit 31 to acquire the time series data, the data storage unit 31 acquires the time series data from the storage unit X (S59), and the data search unit 32 returns the time series data to the application. (S511), the process ends.
  • FIG. 20 is a diagram showing an example of a procedure of time series data accumulation.
  • the following processes (1) to (9) are performed in (Option1.) of time series data accumulation.
  • Ontology is read by the conversion proxy and storeTSforService in the conversion proxy is set to true for Service of storeTimeseries:true.
  • storeTSforServiceFlag is true, it is checked whether the child resource of the target Service ⁇ fcnt> has the target ts_Service ⁇ ts>.
  • Data can be obtained from the conversion proxy via the API of other standard PF/Device.
  • OutputDataPoint under the Service resource is merged into one JSON.
  • the conversion proxy creates the above JSON (ts_Service ⁇ ts>/ ⁇ tsi>).
  • the app confirms the StoreTimeseries status of the desired Service by SPARQL.
  • the app gets the target ⁇ ts>.
  • the application gets ⁇ ts>/ ⁇ latest> etc.
  • FIG. 21 is a diagram showing an example of time series data accumulation.
  • Ts time series data
  • Ts time series data
  • all OutputDataPoints under Service are collectively stored in JSON in con of ⁇ tsi>.
  • the two highest levels of “ ⁇ Common PFBase>” in the resource tree in the common PF are passed through “SUN_Device ⁇ app>”, “getGPS ⁇ fc>”, and “ts_getGPS ⁇ ts>”.
  • DataPoint values of the lower layer of the instance "getGPS" are collectively stored in " ⁇ tsi>" ( ⁇ datadataLongitude:XXX, dataLatitude:YYY ⁇ ).
  • FIG. 22 and 23 are diagrams showing an example of a data exchange workflow
  • FIG. 24 is a diagram showing an example of a data exchange sequence.
  • another standard API described in the ontology is used to perform common processing of OutputDataPoint (acquire data/command from another standard PF or device).
  • the ontology reading unit 21 determines whether storeTimeseries of OutputDataPoint is true (S61). If true (Yes in S61), the ontology reading unit 21 sets Flag of storeTimeseriesDataPoint in the storage unit X to true. Is set (S62).
  • the common exchange unit 24 determines whether or not the child resource of the Service resource (target Service ⁇ fc>) in the storage unit W includes the time-series data storage resource of OutputDataPoint (S63). If there is no time-series data storage resource (No in S63), the common exchange section 24 creates this time-series data storage resource as a child resource of the Service resource in the storage section W of the data storage section 31 (S64).
  • the sensor data exchange unit 23 acquires the sensor data from another PF and transmits the sensor data to the common exchange unit 24.
  • the common exchange unit 24 updates the sensor data in the data storage unit 31 (updates the value of OutputDataPoint) with the transmitted sensor data.
  • the common exchange unit 24 determines whether or not the Flag of storeTimeseriesDataPoint is true (S65), and if not true (No in S65), the process ends, and if true (in S65, S65). Yes), the common exchange unit 24 adds the OutputDataPoint to the time-series data storage resource and sends it to the data storage unit 31, and the process ends (S66). The process from acquisition of sensor data to S66 is repeated at the set cycle.
  • the data search unit 32 confirms the storeTimeseries in the ontology data by SPARQL, acquires the URI data, and sends this URI data to the application (S68).
  • the application requests the data storage unit 31 to acquire the time-series data, the data storage unit 31 acquires the time-series data from the storage unit X (S69), and the data search unit 32 returns the time-series data to the application. (S611), the process ends.
  • FIG. 25 is a diagram showing an example of a procedure of time series data accumulation.
  • the conversion proxy reads Ontology and sets storeTimeseries of ObiServiceWrapper to true for OutputDataPoint of storeTimeseries: true.
  • the conversion proxy checks whether the child resource of the target Service ⁇ fcnt> has the target ts_OutputDataPoint ⁇ ts>.
  • the conversion proxy Created if ts_OutputDataPoint ⁇ ts> does not exist.
  • Data can be obtained from the conversion proxy via the API of other standards PF/Device.
  • the conversion proxy creates the DataPoint (ts_OutputDataPoint ⁇ ts>/ ⁇ tsi>).
  • the application confirms the storeTimeseries status of the desired Service by SPARQL.
  • the application acquires the target ⁇ ts>.
  • the application gets ⁇ ts>/ ⁇ latest> etc.
  • FIG. 26 is a diagram showing an example of time series data accumulation.
  • Ts time series data
  • the dataHumidity value is stored in con of tsi.
  • SUN_Device ⁇ app> “getSensings ⁇ fc>”, “dataHumidity(float)”, “ts_dataHumidity ⁇ from the highest level “ ⁇ CommonPFBase>” in the resource tree in the common PF.
  • the dataHumidity value of the lower layer of the instance “dataHumidity” is stored in two “ ⁇ tsi>” that pass through “ts>” (the same layer as “dataHumidity(float)”).
  • FIG. 27 is a diagram illustrating an example of accumulation of acquisition results by on-demand. Describe the challenges of on-demand acquisition. Originally, oneM2M's OBI constantly updated the obtained data, but when the demand for data usage is low for devices that frequently generate data, it may be useless even if the data is updated. To be
  • FIG. 28 is a diagram illustrating an example of the ontology extension field.
  • the request from the application is made by using the metadata field “standard name: onDemand” that regulates that the latest data from the device is obtained from the device by the request from the application.
  • the metadata field “standard name: onDemand” that regulates that the latest data from the device is obtained from the device by the request from the application.
  • FIG. 29 and 30 are diagrams showing an example of a data exchange workflow
  • FIG. 31 is a diagram showing an example of a data exchange sequence.
  • the on-demand Boolean value described in the ontology is used to perform common on-demand acquisition processing of OutputDataPoint.
  • the ontology reading unit 21 determines whether or not the onDemand of OutputDataPoint in the storage unit X is true (S71), and true.
  • the common exchange unit 24 requests the common PF to create a subscription in the lower layer of the parent Service of the OutputDataPoint, and sets the notification destination to the conversion proxy (S72).
  • the common exchange unit 24 creates a subscription in the lower layer of the parent Service of the OutputDataPoint in the common PF, sends it to the data storage unit 31, and the process ends (S73). If not true in S71 (No in S71), the OutputDataPoint exchange flow (S41 to S47) is performed, and the process ends.
  • the application creates a Subscription at a desired DataPoint and stores this Subscription in the storage unit W of the data storage unit 31 (S75).
  • the application sends a data acquisition request (DataPoint update “demanding”) to the data storage unit 31 (S76).
  • the data storage unit 31 notifies the common exchange unit 24 of the change of DataPoint (S77).
  • the common exchange unit 24 confirms the DataPoint in the "demanding" state (S78).
  • the common exchange section 24 sends a demanding notification to the sensor data exchange section 23 (S79).
  • the sensor data exchange unit 23 acquires sensor data from another PF (S711) and sends OutputDataPoint to the common exchange unit 24 (S712).
  • the common exchange unit 24 reflects the sensor data in the OutputDataPoint in the storage unit W of the data storage unit 31 and updates it (S713).
  • the data storage unit 31 notifies the application of the sensor data via the data search unit 32 (S714).
  • the data search unit 32 deletes the Sub application in the storage unit W of the data storage unit 31 (S715).
  • FIG. 32 is a diagram illustrating an example of an on-demand acquisition procedure.
  • the conversion proxy reads Ontology and creates a sub conversion proxy ⁇ sub> under the target Service ⁇ fcnt> in the common PF for onDemand:true DataPoint.
  • the application confirms the onDemand status of the desired DataPoint by SPARQL.
  • sub application ⁇ sub> is created under the target Service ⁇ fcnt>.
  • the desired DataPoint is updated ([DataPoint]:"demanding").
  • Notify from common PF to conversion proxy (sub conversion proxy).
  • the content of Notification is confirmed in the conversion proxy.
  • Data can be obtained from the conversion proxy via the API of other standards PF/Device.
  • the conversion proxy updates the DataPoint ([DataPoint]: ⁇ value ⁇ ).
  • the common PF will notify the application (sub application).
  • the application When receiving the data, the application deletes the sub application.
  • FIG. 33 is a diagram illustrating an example of on-demand acquisition.
  • whether or not data is acquired on demand is set for each OutputDataPoint.
  • the dataCO2 value is acquired on demand, once stored in the resource tree in the common PF, and sent to the application.
  • “dataCO2(float)[customAttribute” in the lower layer of "getCO2 ⁇ fc>” that passes through "CO2_Device ⁇ app>” from the top " ⁇ common PFBase>" in the resource tree in the common PF. ]] stores the value of the lower layer of the instance "dataCO2".
  • FIG. 34 is a diagram illustrating an example of accumulation of results of batch acquisition by on-demand. Describe the issues in batch acquisition by on-demand. Originally, oneM2M OBI retains only the latest value of the obtained data. Therefore, even if past data was stored in other PFs, these data could not be acquired by the request from the application.
  • FIG. 35 is a diagram illustrating an example of the ontology extension field.
  • the time-series data stored in the other standard PF/Device specific to the device is collectively acquired by the request from the application.
  • the standard name: onDemandTS" is used.
  • the history data stored in the other standard PF/Device is collectively acquired from the other standard device (or PF) on demand.
  • FIG. 36 is a diagram showing an example of a data exchange workflow
  • FIG. 37 is a diagram showing an example of a data exchange sequence.
  • the Boolean value of onDemandTS described in the ontology is used, the common on-demand span of OutputDataPoint is specified, and the acquisition processing is collectively performed.
  • S71 to S74 and the OutputDataPoint exchange flow (S41 to S47) described in FIG. 29 are performed.
  • the processing from S74 to S79 shown in FIG. 30 is performed, and the sensor data exchange unit 23 acquires the sensor data for the designated period from another PF (S711) and outputs OutputDataPoint (sensor data). ) Is transmitted to the common exchange section 24 (S712).
  • the common exchange unit 24 checks whether or not there is a time-series data storage resource for the target OutputDataPoint, and if there is no resource, creates this resource and creates a sensor data group below this resource (S713a). After that, S714 and S715 described with reference to FIG. 30 are performed, and the process ends.
  • FIG. 38 is a diagram illustrating an example of batch acquisition by on-demand.
  • whether to collectively acquire data on demand for each OutputDataPoint and a period during which the data is acquired are set.
  • the two highest levels of “ ⁇ Common PF Base>” in the resource tree in the common PF are passed through “SUN_Device ⁇ app>”, “getSensings ⁇ fc>”, and “ts_dataTemp ⁇ ts>”.
  • the value of the lower layer of the instance "dataTemp" as the acquired past data is accumulated in " ⁇ tsi>".
  • FIG. 39 is a block diagram showing an example of the hardware configuration of the information processing system according to the embodiment of the present invention.
  • the data processing device 10 in the information processing system according to the above embodiment is configured by, for example, a server computer (server computer) or a personal computer, and a hardware processor such as a CPU ( hardware processor) 111A.
  • a program memory 111B, a data memory 112, an input/output interface 113, and a communication interface 114 are connected to the hardware processor 111A via a bus 120.
  • the communication interface 114 includes, for example, one or more wireless communication interface units, and enables transmission and reception of information with the communication network NW.
  • the wireless interface for example, an interface adopting a low power wireless data communication standard such as wireless LAN (Local Area Network) is used.
  • the input/output interface 113 is connected to an input device 50 and an output device 60 for an operator, which are attached to the data processing device 10.
  • the input/output interface 113 takes in operation data input by an operator through an input device 50 such as a keyboard, a touch panel, a touch pad, and a mouse, and outputs output data as a liquid crystal or an organic EL (Electro). Luminescence) or the like is output to an output device 60 including a display device and displayed.
  • the input device 50 and the output device 60 may be devices built in the data processing device 10, and may be used by other information terminals that can communicate with the data processing device 10 via the communication network NW. Input and output devices may be used.
  • the program memory 111B is, as a non-transitory tangible storage medium, for example, a nonvolatile memory (non-volatile memory) such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive) capable of writing and reading at any time, It is used in combination with a non-volatile memory such as a ROM (Read Only Memory), and stores programs necessary for executing various control processes according to an embodiment.
  • a nonvolatile memory such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive) capable of writing and reading at any time
  • a non-volatile memory such as a ROM (Read Only Memory)
  • ROM Read Only Memory
  • the data memory 112 is, as a tangible storage medium, a combination of, for example, the above-mentioned nonvolatile memory and a volatile memory such as a RAM (Random Access Memory), and various processes are performed. It is used to store various data acquired and created in the process.
  • a RAM Random Access Memory
  • the data processing device 10 is a processing function unit by software, such as an ontology creation unit, an ontology reading unit 21, a device management unit 22, and a sensor data exchange unit 23 shown in FIG. And a data exchange device having the common exchange unit 24.
  • software such as an ontology creation unit, an ontology reading unit 21, a device management unit 22, and a sensor data exchange unit 23 shown in FIG.
  • a data exchange device having the common exchange unit 24.
  • the ontology data storage unit 21a, the device information storage unit 22a, and the sensor data storage unit 23a of the data processing device 10 can be configured by using the data memory 112 shown in FIG. The same applies to the ontology data storage unit 31a and the data tree storage unit 31b of the common PF server 30.
  • these storage units are not an indispensable configuration in the data processing device 10, and are, for example, an external storage medium such as a USB (Universal Serial Bus) memory or a storage such as a database server arranged in a cloud. It may be provided in the device.
  • the processing function units in each of the ontology creation unit, the ontology reading unit 21, the device management unit 22, the sensor data exchange unit 23, and the common exchange unit 24 all execute the programs stored in the program memory 111B by the hardware processor. It can be realized by reading and executing by 111A. The same applies to the data storage unit 31 and the data search unit 32 shown in FIG. Note that some or all of these processing function units can be implemented in various other formats including integrated circuits such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). May be realized.
  • ASICs application-specific integrated circuits
  • FPGAs field-programmable gate arrays
  • the data structure common to the standard is based on the ontology data in which the data structure corresponding to the unique standard is described by the ontology and the device information.
  • a resource is created by associating a data exchange interface corresponding to a specific standard with a data exchange interface, and data is exchanged with the common platform server. As a result, data can be exchanged after commonizing the portions that had to be coded for each standard.
  • a first aspect of an information processing system is a common mode in which data is exchanged with an application by being connected to a device compatible with a plurality of unique standards.
  • An information processing system having a conversion proxy further connected to a platform server, wherein the conversion proxy acquires an ontology data in which a data structure corresponding to the specific standard is described by an ontology,
  • a device management unit that acquires and manages unique device information associated with a device corresponding to a type-specific standard, ontology data acquired by the acquisition unit, and device information managed by the device management unit.
  • a resource associated with a data structure common to the plurality of unique standards and a data exchange interface corresponding to the unique standard is created, and the common platform server is used by using the created resource.
  • a common exchange unit for exchanging data between them.
  • the common platform server has a data storage unit for storing data acquired from the device, and the resource is stored in the data storage unit.
  • a first data field defining that the latest data obtained from the device is stored, and the common exchange means of the conversion proxy obtains from the device based on the definition of the first data field.
  • the latest data is stored in the data storage unit.
  • the common platform server has a data storage unit for storing data acquired from the device, and the resource is stored in the data storage unit. It has a second data field that defines storing the time-series data acquired from the device, and the common exchange means of the conversion proxy acquires from the device based on the definition of the second data field.
  • the time series data is stored in the data storage unit.
  • the resource defines that the latest data obtained from the device is obtained from the device in response to a request from the application.
  • the common exchange means of the conversion proxy has three data fields, and the common exchange means of the conversion proxy acquires the data acquired from the device in response to a request from the application based on the definition of the third data field. To the application via.
  • the resource collectively collects time-series data stored in a unique storage unit associated with the device in response to a request from an application. And a fourth data field that defines that the common proxy of the conversion proxy is stored in response to a request from the application based on the definition of the fourth data field.
  • the data obtained from the department is sent to the application via the common platform server.
  • One aspect of an information processing program according to an embodiment of the present invention is to cause a processor to function as each of the means of the information processing system according to any one of the first to fifth aspects.
  • the data common to the standard is based on the ontology data in which the data structure corresponding to the specific standard is described by the ontology and the device information.
  • a resource associated with the structure and a data exchange interface corresponding to a specific standard is created, and data exchange is performed with the common platform server based on this resource.
  • the resource has a data field which defines that the latest data acquired from the device is stored in the common platform.
  • the latest data obtained from the device is stored in the data storage unit of the common platform in accordance with the regulations in 1.
  • the latest data can be obtained from the device after sharing the part that had to be coded for each standard.
  • the resource has a data field defined to store time-series data from the device in the common platform, and the resource has a data field.
  • the time series data acquired from the device is stored in the data storage unit of the common platform in accordance with the regulations.
  • the parts that had to be coded for each standard are standardized, and time-series data from the device can be obtained.
  • the resource has a data field that defines that the latest data from the device is acquired from the device by a request from the application.
  • the data obtained from the device is sent to the application according to the regulation in this data field.
  • the latest data can be passed from the device to the application after commonizing the parts that had to be coded for each standard.
  • the time-series data stored in the storage unit specific to the device can be collectively acquired by a request from the application. It has a defined data field, and in response to a request from the application, the data acquired from the storage unit is sent to the application via the common platform server according to the standard of the data field.
  • the time-series data on the device side can be passed to the application after commonizing the parts that had to be coded for each standard.
  • the method described in each embodiment is, for example, a magnetic disk (floppy (registered trademark) disk (Floppy disk), hard disk, etc.), an optical disk as a program (software means) that can be executed by a computer (computer).
  • a computer computer
  • semiconductor memory ROM, RAM, flash memory, etc.
  • the programs stored on the medium side also include setting programs for configuring software means (including not only execution programs but also tables and data structures) to be executed by the computer in the computer.
  • a computer that realizes this device reads a program recorded in a recording medium, and if necessary, constructs software means by a setting program, and the operation is controlled by this software means to execute the processing described above.
  • the recording medium referred to in the present specification is not limited to distribution, but includes a storage medium such as a magnetic disk or a semiconductor memory provided inside a computer or in a device connected via a network.
  • the present invention is not limited to the above-described embodiment, and can be variously modified in an implementation stage without departing from the gist thereof. Further, the respective embodiments may be appropriately combined and implemented, in which case the combined effects can be obtained. Further, the above-described embodiment includes various inventions, and various inventions can be extracted by a combination selected from a plurality of disclosed constituent features. For example, even if some constituent elements are deleted from all the constituent elements shown in the embodiment, if the problem can be solved and the effect can be obtained, the structure in which the constituent elements are deleted can be extracted as the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一実施形態に係る情報処理システムは、複数種類の固有の規格に対応したデバイスに接続され、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバに更に接続される、変換プロキシを有し、変換プロキシは、固有の規格に対応したデータ構造が記述されたオントロジーデータを取得する取得部と、固有の規格に対応したデバイスに固有のデバイス情報を取得して管理するデバイス管理部と、オントロジーデータとデバイス情報とに基づいて、複数種類の固有の規格に共通したデータ構造と固有の規格に対応したデータ交換インタフェースとが関連付けられたリソースを作成して、このリソースを用いて共通プラットフォームサーバとの間でデータ交換を行なう共通交換部と、を有する。

Description

情報処理システム、方法およびプログラム
　本発明の実施形態は、情報処理システム、方法およびプログラムに関する。
　IEEE（Institute of Electrical and Electronics Engineers）による予測では、2025年までに約754億台のデバイス（device）がインターネットに接続される見込みである。このようなデバイスの数の増大は、特殊な業界に留まらず、様々なIoT(Internet of Things)規格を有する複数の業界に影響を及ぼす可能性がある。　
　このような業界の変化に適応するために、各規格に共通する優秀な共通IoTプラットフォーム(PF(Platform))を用意することだけでなく、既存規格との間の複雑なデータ（data）交換を簡素化させることが要望されている。
　一方、oneM2Mと称される、水平統合型のIoTプラットフォーム標準仕様（標準化を進めるために開始されたパートナーシッププロジェクト（Partnership project））は、様々なIoT規格の乱立を防ぐために開発された。　
　oneM2Mは、データ管理およびデバイス管理などの通信方式に非依存である共通機能の集合体CSE（Common Service Entity）、他規格のプロトコル（protocol）とのデータマッピング（data mapping）および交換を担うIPE（Interworking Proxy Entity）および集められたデータを利活用するAE（Application Entity）から成る。　
　oneM2Mでは、CSEに対し、アプリケーションプログラム（application program）（以下、アプリケーション又はアプリと称することがある）が、mcaと呼ばれるインタフェース（interface）（CSE-AE（Application Entity）間のインタフェース）を介して接続される（例えば、非特許文献１，２を参照）。
Nassim DENNOUNI, Ahmed LEHIRECHE、Towards a spatiotemporel model for the interworking of the GIS oneM2M Specification TS-0004 version 3.0.1
　ここで、IoT相互連携の現状について説明する。IoTデータは、データを収集した事業者（データ提供者）ごとに極めてサイロ化（silos）されて管理され、事業者ごとに固有のIoT-PF毎のAPI（Application Programming Interface（アプリケーション・プログラミング・インタフェース））およびデータモデル（data model）が異なるのが現状である。
　例えば、第１の事業者により提供される例えば気象データ、第２の事業者により提供される交通流量データ、および第３の事業者により提供されるイベント（event）開催データに基づいて、複合データ活用アプリにより高度渋滞予測サービス（service）を円滑に提供するケースについて説明する。　
　このケースでは、気象データは、第１の事業者に固有のIoT-PFおよびAPI/データモデルを介して複合データ活用アプリに提供される。交通流量データは、第２の事業者に固有のIoT-PFおよびAPI/データモデルを介して複合データ活用アプリに提供される。イベント開催データは、第３の事業者に固有のIoT-PFおよびAPI/データモデルを介して複合データ活用アプリに提供される。
　このようなケースでは、データ提供者ごとの全てのAPIおよびデータモデルが個別に対応し続けられる必要があり、継続的なデータ活用が困難である。
　上記のように、IoTデータは、収集されたIoT-PF事業者ごとに極めてサイロ化されて管理されるが、APIおよびデータモデル（データ構造および語彙を含めて）が各種PF間で統一される可能性は極めて低い。　
　また、エッジ（edge）PFも複数の事業者により実現される可能性があり、クラウド（cloud）およびエッジでAPIが異なり、多様化するので、アプリの可搬性が低下する。
　ここで、IoTデータを活用する多様なアプリが創出されることの阻害要因について説明する。　
　複数種類のPFがそれぞれ保持するデータが活用されるためには、各種アプリの提供者がPF毎/デバイス毎のAPIおよびデータモデルを習得する必要があり、大きな負担が発生する。　
　このため、PFの種類が例えば数十種類以上であると対応が極めて困難である。また、あるデータが連携されることによる価値の有無を判断するためには、お試しとしてのデータが取得されることが必要であるが、このお試しにも相当の負担が生じる。
　上記の対策として、アプリ提供者がPF毎およびデバイス毎に個別対応することなく、また、短期間かつ低コスト（cost）で相互連携を可能にし、持続的なデータ活用の発展が促進される技術を確立する必要がある。
　次に、Specific Interworking(IWK)によるIoT相互連携の課題について説明する。　
　異種規格間のデータ交換が行なわれる際に、データ表現の抽象化が行なわれず、データが一つずつ変換されて交換フローが作成される、Specific IWKと呼ばれる手法がある。
　例えば、IoT規格A, B, Cから共通PFへデータ変換されるSpecific IWKとしては、下記の（１）～（３）が挙げられる。　
　（１）規格A_Deviceと共通PFとの間の変換プロキシ（proxy）に、規格依存I/O変換、規格Aに固有であるData Mapping Aおよび規格Aに固有であるIWK Procedures Aが含まれること
　（２）技術B PFと共通PFとの間の変換プロキシに、規格依存I/O変換、規格Bに固有であるData Mapping Bおよび規格Bに固有であるIWK Procedures Bが含まれること
　（３）規格C PFと共通PFとの間の変換プロキシに、規格依存I/O変換、規格Cに固有であるData Mapping Cおよび規格Cに固有であるIWK Procedures Cが含まれること
　次にSpecific IWKの課題について、以下のa.～c.にて説明する。　
　a.　まず、開発コストの高騰が挙げられる。データが交換されるには、規格のデータ構造とデバイスとの関係性、データと共通プラットフォームのリソース（resource）との対応、及びマッピングフロー（mapping flow）などの知識が網羅的に理解されることが必要である。　
　一定以上の規模になると、すべてのデータに対して知識が蓄えられることとデータ交換フローが用意されることは実質困難である。　
　新しい規格との間でデータ交換が行なわれたい際に、データマッピングとデータ交換のフローが新しく作られなければならず、インタワーキング（interworking）する規格の増加によって開発コストが高騰する。
　b.　個別に決められたデータマッピングによって、共通プラットフォームのデータ構造も多様になり、データ活用アプリによりデータが取得される際にも個別なデータ構造が把握されなければならない。　
　c.　データ保管状態および場所のカスタマイズ（Customization）は、規格ごとに個別に行なわれる必要がある。
　この発明は、上記事情に着目してなされたもので、その目的とするところは、データの規格毎に個別対応することなしに、また、短期間かつ低コストに相互連携してデータ交換することができるようにした情報処理システム、方法およびプログラムを提供することにある。
　上記目的を達成するために、この発明の一実施形態に係る情報処理システムの一態様は、複数種類の固有の規格に対応したデバイスに接続され、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバに更に接続される、変換プロキシを有する情報処理システムであって、前記変換プロキシは、前記固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得する取得部と、前記複数種類の固有の規格に対応したデバイスに対応付けられた固有のデバイス情報を取得して管理するデバイス管理部と、前記取得部により取得されたオントロジーデータと前記デバイス管理部により管理されるデバイス情報とに基づいて、前記複数種類の固有の規格に共通したデータ構造と前記固有の規格に対応したデータ交換インタフェースとが関連付けられたリソースを作成し、前記作成されたリソースを用いて前記共通プラットフォームサーバとの間でデータ交換を行なう共通交換部とを備える。
　本発明の一実施形態に係る情報処理方法の一つの態様は、複数種類の固有の規格に対応したデバイスに接続され、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバに更に接続される、変換プロキシを有する情報処理システムが行う情報処理方法であって、前記変換プロキシは、前記固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得し、前記複数種類の固有の規格に対応したデバイスに対応付けられた固有のデバイス情報を取得して管理し、前記取得されたオントロジーデータと前記管理されるデバイス情報とに基づいて、前記複数種類の固有の規格に共通したデータ構造と前記固有の規格に対応したデータ交換インタフェースとが関連付けられたリソースを作成して、前記作成されたリソースを用いて前記共通プラットフォームサーバとの間でデータ交換を行なうようにしたものである。
　本発明の一態様によれば、収集されるデータの規格毎に個別対応することなしに、また、短期間かつ低コストに相互連携してデータ交換を行なうことが可能になる。
図１は、本発明の一実施形態に係る情報処理システム（system）に適用されるOntology based IWKの一例を示す図である。 図２は、本発明の一実施形態に係る情報処理システムにOntology based IWKが適用されたときの構成例を示す図である。 図３は、本発明の一実施形態に係る情報処理システムの構成例を示す図である。 図４は、本発明の一実施形態に係る情報処理システムに使用されるoneM2M base ontologyの一部の例を示す図である。 図５は、データ構造の抽象化の例を示す図である。 図６は、最新値のみの保存について説明する図である。 図７は、オントロジー（ontology）拡張フィールド（field）の一例を説明する図である。 図８は、変換プロキシ接続時のワークフローの一例を説明する図である。 図９は、変換プロキシ接続時のシーケンス（sequence）の一例を説明する図である。 図１０は、InputDataPoint交換のワークフローの一例を示す図である。 図１１は、InputDataPoint交換のシーケンスの一例を示す図である。 図１２は、OutputDataPoint交換のワークフローの一例を示す図である。 図１３は、OutputDataPoint交換のシーケンスの一例を示す図である。 図１４は、他規格とのデータ交換フローの共通化の一例を説明する図である。 図１５は、時系列データの蓄積の一例について説明する図である。 図１６は、オントロジー拡張フィールドの一例を説明する図である。 図１７は、データ交換のワークフローの一例を示す図である。 図１８は、データ交換のワークフローの一例を示す図である。 図１９は、データ交換のシーケンスの一例を示す図である。 図２０は、時系列データ蓄積の手順の一例を示す図である。 図２１は、時系列データ蓄積の実施例を示す図である。 図２２は、データ交換のワークフローの一例を示す図である。 図２３は、データ交換のワークフローの一例を示す図である。 図２４は、データ交換のシーケンスの一例を示す図である。 図２５は、時系列データ蓄積の手順の一例を示す図である。 図２６は、時系列データ蓄積の実施例を示す図である。 図２７は、オンデマンド（on demand）による取得の一例について説明する図である。 図２８は、オントロジー拡張フィールドの一例を説明する図である。 図２９は、データ交換のワークフローの一例を示す図である。 図３０は、データ交換のワークフローの一例を示す図である。 図３１は、データ交換のシーケンスの一例を示す図である。 図３２は、オンデマンドによる取得の手順の一例を示す図である。 図３３は、オンデマンドによる取得の実施例を示す図である。 図３４は、オンデマンドによる一括取得の一例について説明する図である。 図３５は、オントロジー拡張フィールドの一例を説明する図である。 図３６は、データ交換のワークフローの一例を示す図である。 図３７は、データ交換のシーケンスの一例を示す図である。 図３８は、オンデマンドによる一括取得の実施例を示す図である。 図３９は、本発明の一実施形態に係る情報処理システムのハードウエア（hardware）構成の一例を示すブロック図である。
　以下、図面を参照しながら、この発明に係わる一実施形態を説明する。　
　本発明の一実施形態に係る情報処理システムでは、従来の、データごとに1対1で行なわれていたデータマッピングとデータ交換とが、オントロジーが用いられることで抽象化され、抽象化エンティティ（entity）に対して処理が共通化される。　
　これにより、抽象化された単位で処理が決めされ、データマッピングとデータ交換フローの開発コストの削減と、アプリによるデータ取得方式の統一が実現される。
　これにより、データ流通基盤の運用者は、少ない開発コストで基盤設定を完了できる。データ活用アプリからの視点では、共通PFにあるデータの構成が共通化される。このため、データ活用アプリにとってデータ取得の仕方も一義に決められ、アプリの開発と修正も簡単になる。
　また、本発明の一実施形態に係る情報処理システムでは、データ保管状態とデータ保管場所に対して、パターン（pattern）が分けられて、このパターンごとに処理フローが設計され、上記の抽象化された単位でデータ交換方式の切り替えが実現される。　
　これにより、簡単な設定によりデータ保管が最適化され、基盤のパフォーマンス（performance）が保たれる。
　次に、オントロジーが用いられたIoT相互連携高度化について説明する。　
　本発明の一実施形態では、異種規格に跨ったデータ表現がオントロジーによって構造化され、高度に抽象化されたデータ表現に対する共通的なデータ交換フローが設計される。これにより、異種規格とoneM2Mとの間のデータ交換の処理が共通化される。
　図１は、本発明の一実施形態に係る情報処理システムに適用されるOntology based IWKの一例を示す図である。　
　図１に示された例では、IoT規格A, B, CからoneM2Mによる共通PFへデータ変換させるOntology based IWKとしては、規格A_Deviceと共通PFとの間の変換プロキシ、技術B PFと共通PFとの間の変換プロキシ、および規格C PFと共通PFとの間の変換プロキシには、規格に依存する規格依存I/O変換に加え、共通のBase Ontology Derived Model Mapping、およびCommon IWK Proceduresがそれぞれ含まれる。図１に示されたａは変換プロシキを示し、図１に示されたｂは、規格依存I/O変換を示す。
　図２は、本発明の一実施形態に係る情報処理システムにOntology based IWKが適用されたときの構成例を示す図である。　
　図２に示された例では、A社IoT-PFは、A社IoT-PF対応のオントロジー作成GUI（グラフィカルユーザインタフェース（graphical user interface））および変換プロキシを介して共通PFサーバ（server）に接続される。　
　図２に示された例では、B社IoT-PFは、B社IoT-PF対応のオントロジー作成GUIおよび変換プロキシを介して共通PFサーバに接続される。　
　図２に示された例では、C社IoT-PFは、C社IoT-PF対応のオントロジー作成GUIおよび変換プロキシを介して共通PFサーバに接続される。　
　図２に示された例では、センサデバイス（sensor device）は、センサデバイス提供元の規格に対応するオントロジー作成GUIおよび変換プロキシを介して共通PFサーバに接続される。　
　共通PFサーバは、複合データ活用アプリα、複合データ活用アプリβおよび複合データ活用アプリγなどの各種アプリとの間で、高度抽象化APIおよびデータ構造を実現してデータをやり取りする。図２に示されたａは変換プロシキおよびオントロジー作成GUIを示し、図２に示されたｂはセンサデバイスを示す。
　次にOntology based IWKの効果について説明する。　
　図２に示された構成では、図１に示された共通PF、Base Ontology Derived Model MappingおよびCommon IWK Proceduresの処理が共通化されるので、これらのBase Ontology Derived Model MappingおよびCommon IWK Proceduresが事業者ごとに都度開発される必要がなくなる。これにより、技術規格が増加したときの変換プロキシの開発コストを低減することができる。
　また、各種データ活用アプリからの視点では、共通PFにより処理されるデータの構成が共通化される。このため、データ活用アプリにとってデータ取得の仕方も一義に決められ、アプリの開発と修正が簡単になる。　
　また、簡単な設定によりデータ保管が最適化され、基盤のパフォーマンスが保たれ得る。
　図３は、本発明の一実施形態に係る情報処理システムの構成例を示す図である。　
　図３に示されように、本発明の一実施形態に係る情報処理システムでは、各事業者に対応して設けられるデータ処理装置１０が、複数種類の固有の規格に対応したセンサなどのデバイスと、アプリケーションとの間でデータ交換を行なう共通PFサーバ３０とに、通信ネットワーク（network）を介してそれぞれ接続される。　
　データ処理装置１０は、上記の規格ごとに設けられ、該当の規格に対応したデバイスと接続される。データ処理装置１０および共通PFサーバ３０の機能は、プログラムを実行するＣＰＵ（Central Processing Unit）等のプロセッサ（processor）、およびＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等の記憶媒体、キーボード（keyboard）などの入力装置、ディスプレイ（display）などの表示装置が用いられることで実現される。
　データ処理装置１０は、オントロジー作成GUIと変換プロキシを有する。　
　オントロジー作成GUIは、オントロジー作成部（O, オントロジー作成部と表記されることがある）１１を有する。
　変換プロキシは、オントロジー読取部（A, オントロジー読取部と表記されることがある）２１、デバイス管理部（B, デバイス管理部と表記されることがある）２２、センサデータ交換部（C, センサデータ交換部と表記されることがある）２３、共通交換部（D, 共通交換部と表記されることがある）２４を有する。
　オントロジー読取部２１は、固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得する。このオントロジー読取部２１は、オントロジーデータ格納部（格納部Ｘと表記されることがある）２１ａを有する。
　デバイス管理部２２は、固有の規格に対応したデバイスに固有であるデバイス情報を取得して、このデバイス情報を管理する。このデバイス管理部２２は、デバイス情報格納部（格納部Ｙと表記されることがある）２２ａを有する。
　センサデータ交換部２３には、事業者のセンサ、デバイス又はPFが接続される。このセンサデータ交換部２３は、センサデータ格納部（格納部Ｚと表記されることがある）２３ａを有する。
　オントロジー読取部２１により取得されたオントロジーデータとデバイス管理部２２により管理されるデバイス情報とに基づいて、共通交換部２４は、複数種類の固有の規格に共通したデータ構造と、固有の規格に対応したデータ交換インタフェースとが関連付けられたリソースを作成する。共通交換部２４、このリソースを用いて共通PFサーバ３０との間でデータ交換を行なう。
　共通PFサーバ３０は、各規格に共通した１つのサーバとして設けられ、データ保管部（E, データ保管部と表記されることがある）３１、データ検索部（F, データ検索部と表記されることがある）３２を有する。　
　データ保管部３１は、データ構造が記述されたオントロジーファイル（ontology file）(.owl(Web Ontology Language))が格納されるオントロジーデータ格納部（格納部Ｖと表記されることがある）３１ａ、データツリー（data tree）格納部（格納部Ｗと表記されることがある）３１ｂ）を有する。データツリーは、例えば「|-デバイス」、「|-サービス」、「|-データ」などで構成される。
　オントロジー読取部２１、デバイス管理部２２、共通交換部２４、データ保管部３１およびデータ検索部３２は、各種規格で共通に設けられることができ、センサデータ交換部２３は、規格ごとに設けられる。
　次に、各部の入出力の機能について下記で説明する。　
　A, オントロジー読取部
　・入力：GUIで作成されたowlファイル
　・出力：オントロジーエンティティ関係マップ（Device、Service間、Service、DataPoint間の関係）
　B, デバイス管理部
　・入力：センサ出力（センサ接続の場合）、PF Device Discovery API（PF接続の場合）
　・出力：デバイス情報マップ（{Device ID, Device Name}）
　C, センサデータ交換部
　・入力：Data Discovery API （オントロジーのServiceとDataPointエンティティ下に記述された値）
　・出力：センサデータ（温度：37℃、湿度：50%など）、コマンド（command）（switchON…）
　D, 共通交換部
　・入力：デバイス情報fromデバイス管理部、センサデータfromセンサデータ交換部
　・出力：サーバへのデータ交換リクエスト（request）（リソース作成、データ更新など）
　E, データ保管部
　・入力：変換プロキシからのデータ交換リクエストfrom共通交換部
　・出力：リソース作成
　F, データ検索部
　・入力：SPARQL（RDF(Resource Description Framework)クエリ（query）言語の１種）クエリ
　・出力：データ取得URI(Uniform Resource Identifier)、データ値
　O, オントロジー作成部
　・入力：人手による入力
　・出力：IWK用のオントロジー(.owl)
　次にBase Ontology (oneM2M)について説明する。　
　本発明の一実施形態では、oneM2M Base Ontologyが用いられることで各異種規格のデータ構造の抽象化が行われ、抽象化されたデータ構造の情報が、RDFが用いられることで機械可読な形で記述され、データとデバイスの関係性などの知識がメタデータとして構造化され、データ情報が関連付けされる。
　図４は、本発明の一実施形態に係る情報処理システムに使用されるoneM2M base ontologyの一部の例を示す図である。　
　図４に示された例では、IoTデバイス（Device）リソースが、サービス（Service）リソース（サービスと称することがある）経由で他規格とのIWK時におけるデータの送受信を行なうことを想定する。RESTfulインタフェースを有する異種規格の場合は、サービスリソースの下層にDataPointリソース（DataPointと称することがある）が定義される。　
　この例では、クラス（class）「Device」，「Service」はプロパティ（property）「hasService」で関連付けられ、クラス「Service」，「OutputDataPoint」はプロパティ「hasOutputDataPoint」で関連付けられ、クラス「Service」，「InputDataPoint」はプロパティ「hasInputDataPoint」で関連付けられ、クラス「Device」，「Thing」はプロパティ「is-a」で関連付けられる。
　複雑なIoTデバイスが用いられる場合には、図４に示されるように、「ConsistsOf」フィールドを利用して、子デバイスと子サービスが表現されることによって、階層関係が定義される。
　図５は、データ構造の抽象化の例を示す図である。RPC（Remote Procedure Call）インタフェースの異種規格に対しては、RPCの機能と同様なOperationが定義される。　
　例えば、図５に示されるように、「洗濯機（Washing machine）」と称されるデバイスリソースに対し「スイッチ（SwitchOnService）」と称されるサービスリソースがあり、DataPointが利用される場合は、InputDataPointによって、スイッチOn/Offの操作を行ない、OutputDataPointからスイッチの現在の状態を獲得する。
　次に、IoT相互接続におけるデータの保存および取得に係る４つの形態（形態1．～4．）について下記で説明する。　
　形態1．（基本形態）：共通PFでの最新値が更新（最新値のみ保存）される。
　形態2．（拡張形態）：共通PFに時系列データ（Time Series）が蓄積（時系列データ蓄積）される。
　形態3．（拡張形態）：アプリからのリクエスト時にのみ、他規格PF/Deviceからデータが取得（オンデマンドによる取得）される。
　形態4．（拡張形態）：アプリからのリクエスト時に、他規格PF/Deviceに蓄積されたデータが一括で取得（オンデマンドによる一括取得）される。
　（形態1．）
　次に、基本形態としての「形態1．：共通PFに最新値を更新」の詳細について説明する。図６は、最新値のみの保存について説明する図である。　
　共通PFでの最新値が更新される際の課題を説明する。元々、oneM2MのOBI(Ontology Based Interworking)では他規格（データ提供者に固有の規格）のデータを接続させる際のコーディング（coding）を減らす目的がある。しかしながら仕様で決められた内容だけではリソース構造を一致させることに留まり、実態としてはデバイスに対して大量のコーディングが必要になってしまう。
　そこで、形態1．の技術では、<Protocol:hasAPI>を用い、他規格のデータに接続するためのAPIがオントロジーに追加されることによって、デバイスごとにコーディングしなければならなかった部分がオントロジーにより吸収される。これにより、コーディング量が劇的に削減される。
　次に、形態1．におけるオントロジー拡張フィールドについて説明する。図７は、オントロジー拡張フィールドの一例を説明する図である。　
　図７に示されように、形態1．では、共通PFサーバ３０に他規格のデバイスからの最新のデータを格納することが規定されるメタデータフィールド「規格名：hasAPI」を用いて、抽象化されたデータ構造のオントロジーと他規格に対応したデータ交換インタフェースとの関連付けが行なわれる。
　例えば、DataPointを送受信するための他規格インタフェース（API）が、オントロジーにあるDataPointインスタンス（instance）（当該インスタンスが属するクラス「OutputDataPoint」，「InputDataPoint」を含む）に関連付けられるメタデータフィールド（metadata field）として、メタデータフィールド「規格名：hasAPI」（eg: DWAPI(Device Web API):hasAPI）が設計される。
　また、同じメタデータフィールドを用いて、他規格のサービスが呼び出される際のAPIも記述され得る。そして、上層がデータを効率的に理解するために、メタデータフィールド「規格名：hasUnit」が設計され、他規格で定義されたデータの単位がオントロジーに記述される。
　図７に示された例では、図４に示されたように、クラス「Device」，「Service」はプロパティ「hasService」により関連付けられ、クラス「Service」，「OutputDataPoint」はプロパティ「hasOutputDataPoint」により関連付けられ、クラス「Service」，「InputDataPoint」はプロパティ「hasInputDataPoint」により関連付けられ、クラス「Device」，「Thing」はプロパティ「is-a」により関連付けられる。
　そして、形態1．ではクラス「OutputDataPoint」はメタデータフィールド「Protocol：hasUnit」によりクラス「Unit」と関連付けられ、クラス「InputDataPoint」はメタデータフィールド「Protocol：hasUnit」によりクラス「Unit」と関連付けられる。
　また、クラス「Service」はメタデータフィールド「Protocol：hasAPI」によりクラス「Unit」と関連付けられ、クラス「OutputDataPoint」はメタデータフィールド「Protocol：hasAPI」によりクラス「Unit」と関連付けられ、クラス「Service」，「InputDataPoint」はメタデータフィールド「Protocol：hasAPI」によりクラス「Unit」と関連付けられる。
　次に、変換プロキシ接続時のワークフローについて説明する。図８は、変換プロキシ接続時のワークフローの一例を説明する図である。図９は、変換プロキシ接続時のシーケンスの一例を説明する図である。このワークフローおよびシーケンスは、形態1．～4．に共通する。
　このワークフローでは、変換プロキシがオントロジーを読み込み、オントロジーの内容に応じてDevice/Service/InputDataPoint/OutputDataPointの共通的な処理が行なわれる。
　まず、オントロジー読取部２１は、オントロジー作成部１１により作成されたオントロジーファイルを読取り、このオントロジーファイルを格納部Xに格納する（Ｓ１１）。　
　ここでオントロジー読取部２１は、共通交換部２４に対し、OBI Clientを作成し、オントロジーをRegisterする。共通交換部２４は、変換プロキシのリソースを作成し、このリソースを共通PFサーバ３０のデータ保管部３１に送る。また、共通交換部２４は、変換プロキシを表すリソースの直下に、オントロジーデータを、格納部Yを保管先として保管する。
　デバイス管理部２２は、他規格のPF/Deviceからデバイス情報を取得し（Ｓ１２）、このデバイス情報で示されるデバイスが新しいデバイスであれば、デバイスリスト（device list）{Device ID, Device Name}を更新し、このデバイス情報を共通交換部２４に送信する。
　次に共通交換部２４は、デバイス管理部２２から取得したデバイス情報で示されるDeviceがオントロジーにあるか否かを判定し（Ｓ１３）、このDeviceがオントロジーにないときは（Ｓ１３のＮｏ）、デバイス情報で示されるDeviceがオントロジーに対応していないと判定して、このDeviceに係る情報をデバイスリストから削除する。
　一方で、上記デバイス情報で示されるDeviceがオントロジーにあるときは（Ｓ１３のＹｅｓ）、共通交換部２４は、Device Wrapperを作成し、このDevice Wrapperをデータ保管部３１の格納部W, Vに保管する（Ｓ１４）。　
　データ保管部３１は、Device Wrapperを用いて変換プロキシのリソースの一種であるDeviceリソースを作成し、このリソースをデータ保管部３１内の格納部W, Vに保管する（Ｓ１５）。
　Ｓ１４の次に、共通交換部２４は、Service Wrapperを作成し、このService Wrapperをデータ保管部３１の格納部W, Vに保管する（Ｓ１８）。データ保管部３１は、Service Wrapperを用いて変換プロキシのリソースの一種であるServiceリソースを作成し、このリソースをデータ保管部３１格納部W, Vに保管する（Ｓ１７）。
　次に、共通交換部２４は、オントロジーにおけるDeviceリソースの下層に未処理のServiceリソースがあるか否かを判定し（Ｓ１９）、未処理のServiceリソースがあれば（Ｓ１９のＹｅｓ）、Ｓ１８に遷移する。　
　また、未処理のServiceリソースがなければ（Ｓ１９のＮｏ）、共通交換部２４は、InputDataPointの有無を確認し（Ｓ２０）、InputDataPointがあれば（Ｓ２０のＹｅｓ）、Serviceリソースの下層にSubscriptionリソースを作成し、このリソースをデータ保管部３１の格納部Wに格納する（Ｓ２１）。　
　Subscriptionリソースは、共通PFのデータリソースの一種である。Subscriptionリソースが、その他のリソース（eg: Service resource）の下層に配置されると、そのリソースに更新があるときに、通知が送られる。通知先は、Subscriptionリソースに記述される。　
　Ｓ２１の後は、Ｓ２２、および後述するInputDataPoint交換フロー（Ｓ３１～Ｓ３６）に移行する。
　InputDataPointがないときは（Ｓ２０のＮｏ）、共通交換部２４は、OutputDataPointの有無を確認し（Ｓ２２）、OutputDataPointがないときは（Ｓ２２のＮｏ）処理が終了する。　
　一方で、OutputDataPointがあるときは（Ｓ２２のＹｅｓ）、共通交換部２４は、センサデータ取得サブフローを作成（OutputDataPointと、格納部Xから取得した、親Serviceの他規格APIとをワークフローに保管する）（Ｓ２３）。
　Ｓ２３の後は、後述するOutputDataPoint交換フロー（Ｓ４１～Ｓ４７）に移行する。
　InputDataPoint交換フローについて説明する。図１０は、InputDataPoint交換のワークフローの一例を示す図であり、図１１は、InputDataPoint交換のシーケンスの一例を示す図である。このワークフロー、シーケンスは、形態1．～4．に共通する。　
　InputDataPoint交換では、オントロジーに記述した他規格APIが用いられて、InputDataPoint（他規格PF或いはデバイスにデータ/コマンドを送る）の共通的な処理が行なわれる。
　まず、共通PFサーバ３０のデータ検索部３２は、アプリからのSPARQLにより、データ保管部３１の格納部Vで検索し、Deviceと、このDeviceの配下のService, InputDataPointを発見する（例：「Device: WashingMaching」、「|-Service: Control」、「|-InputDataPoint: Switch」）（Ｓ３１）。
　データ検索部３２は、データ保管部３１の格納部Ｗにおいて、Serviceリソースの下層のInputDataPoint属性を更新（例：Switch: ONに）する（Ｓ３２）。　
　データ保管部３１は、このサービスリソースの下層のSubscriptionリソースに指定された変換プロキシに通知を送る（Ｓ３３）。
　変換プロキシの共通交換部２４は、上記InputDataPointがオントロジーに対応するInputDataPointであるか否かを判定し（Ｓ３４）、オントロジー対応InputDataPointでなければ（Ｓ３４のＮｏ）処理が終了する。　
　一方、上記InputDataPointがオントロジーに対応するInputDataPointであれば（Ｓ３４のＹｅｓ）、共通交換部２４は、オントロジーから本InputDataPointと、その親Serviceの対応する他規格のAPIとを読取り、読取り結果をセンサデータ交換部２３に送る（Ｓ３５）。　
　そして、センサデータ交換部２３は、他規格のAPIを使って、他規格のPF或いはデバイスにコマンドを送る（Ｓ３６）。
　OutputDataPoint交換フローについて説明する。図１２は、OutputDataPoint交換のワークフローの一例を示す図であり、図１３は、OutputDataPoint交換のシーケンスの一例を示す図である。このワークフローおよびシーケンスは、形態1．～4．に共通する。　
　OutputDataPoint交換では、オントロジーに記述された他規格APIを用いて、OutputDataPoint（他規格PF或いはデバイスからデータ/コマンドを取得）の共通的な処理が行なわれる。
　定期開始(Thread)後、センサデータ交換部２３は、OutputDataPointと、その親Serviceの他規格APIを用いて、センサデータを格納部Zから取得する（Ｓ４１）。　
　センサデータ交換部２３は、センサデータをオントロジーに設定されたDataTypeに変換可能か否かを判定し（Ｓ４２）、変換可能でなければ（Ｓ４２のＮｏ）、異常終了(Thread)となる。　
　変換可能であれば（Ｓ４２のＹｅｓ）、センサデータ交換部２３は、センサデータを、オントロジーに設定された、本OutputDataPointのDataTypeに変換し、OutputDataPoint値を共通交換部２４に送る（Ｓ４３）。
　共通交換部２４は、OutputDataPointのリソース値の更新をデータ保管部３１にリクエストする（Ｓ４４）。　
　データ保管部３１は、格納部WにおけるOutputDataPointのリソース値を更新する（Ｓ４５）。　
　データ保管部３１は、本OutputDataPoint下にsubscriptionリソースがあるか否かを判断する（Ｓ４６）。　
　このsubscriptionリソースがなければ（Ｓ４６のＮｏ）、正常終了(Thread)となる。
　また、上記のsubscriptionリソースがあれば（Ｓ４６のＹｅｓ）、データ保管部３１は、OutputDataPointの最新値をsubscriptionリソースにより指定されたアプリに送り（Ｓ４７）、正常終了(Thread)となる。
　次に、「環境監視センサ」と称されるデバイス（DWAPI規格準拠）を例とする、全てのデータ交換フローがオントロジー設定に沿って行なわれる実施例について説明する。　
　図１４は、他規格とのデータ交換フローの共通化の一例を説明する図である。　
　ここでは、他規格に対して、各種のデータ構造に拘らない共通化されたデータ交換フローが設計される。
　図１４に示された例では、インスタンス「getData」，「ManageDev」がクラス「Service」に属し、インスタンス「温度」，「湿度」，「CO2」がクラス「OutputDataPoint」に属し、インスタンス「Interval」，「Switch」がクラス「InputDataPoint」に属する。
　また、インスタンス「EnvSensor」は、プロパティ「hasService」によりインスタンス「getData」，「ManageDev」に関連付けられ、インスタンス「getData」は、プロパティ「hasOutputDataPoint」によりインスタンス「温度」，「湿度」，「CO2」に関連付けられ、インスタンス「ManageDev」は、プロパティ「hasInputDataPoint」によりインスタンス「Interval」，「Switch」に関連付けられる。
　インスタンス「EnvSensor」は、プロパティ「is-a」によりインスタンス「環境センサー」と関連付けられる。インスタンス「ManageDev」はプロパティ「hasAPI」により他規格API（インスタンス）「Sensor/Service1」と関連付けられる。インスタンス「getData」は、プロパティ「hasAPI」により他規格API「Sensor/Service2」と関連付けられる。
　インスタンス「温度」は、プロパティ「hasAPI」により他規格API「DATA:arg(argument)1」と関連付けられる。　
　インスタンス「湿度」は、プロパティ「hasAPI」により他規格API「DATA:arg2」と関連付けられる。インスタンス「CO2」は、プロパティ「hasAPI」により他規格API「DATA:arg3」と関連付けられる。　
　インスタンス「Interval」は、プロパティ「hasAPI」により他規格API「DATA:arg4」と関連付けられる。インスタンス「Switch」は、プロパティ「hasAPI」により他規格API「DATA:arg5」と関連付けられる。　
　他規格API「DATA:arg1」，「DATA:arg2」，「DATA:arg3」，「DATA:arg4」，「DATA:arg5」は、クラス「API」と関連付けられる。
　まず、他規格のデバイス発見APIが利用されて、接続されるデバイスリストが取得される。デバイス発見APIが無い他規格（eg: LoRa(Long Range)）に対して各デバイスから初めて取得されたデータから解析が行われ、デバイス種類（EnvSensor）を表すフィールドが抽出される（図１４中のａ）。
　次に、RDFクエリ言語であるSPARQL (中にBOでBase Ontologyを表す)
　{?Device RDFS:subClassof BO:Device}
が用いられて、事前に定義された抽象化オントロジーの中にデバイス種類が存在しているかどうかが判断される。このデバイス種類で示されるデバイスが、オントロジーが対応しているデバイスであれば、共通処理としてoneM2M側のリソースツリーに、そのデバイスを表すリソース（デバイスAE(Application Entity)）が作成される。
　次に、デバイス種類（EnvSensor）が持つサービス（getDataとManageDev）が下記のSPARQL
　{?Device BO:hasService ?Service}
により抽出される（図１４中のｂ）。　
　抽出されたサービスに対して、oneM2M側で<FC>（flexContainer）と表記されるリソースが作成される。また、データ交換のための各サービスを後ほど呼び出すための他規格API（DWAPI:Sensor/Service1など）も抽出されて保持される。
　さらに、抽出された各サービスに対して、対応OutputDataPointの有無が下記の（ａ）のように判断される（図１４中のｃ）。　
　{?Service BO:hasOutputDataPoint ?o}　…（ａ）
　OutputDataPointが存在する場合は、保管されている、そのサービスの他規格APIに対して、データ取得スレッドが新規に作成され、データの受信準備が行われる。そして、オントロジーにある各OutputDataPointの他規格API（eg: DWAPI:DATA:arg1）がメタデータフィールド（DWAPI:hasAPI）によって取得されて保持される。
　毎回、そのサービスからデータが取得された際に、DataPointの他規格APIが利用されて、各OutputDataPointの値がサービス呼出し結果から取得されて、oneM2Mリソースの対応customAttributeが更新される（図１４中のｄ）。
　一方、各サービスに対して、対応InputDataPointの有無が下記の（ｂ）で示されるSPARQLにより判断される。
　{?Service BO:hasInputDataPoint ?i}　…（ｂ）
　InputDataPointが存在する場合、oneM2Mで作成された、そのサービスの<FC>リソースの下層に、IPEを主にした<Subscription>リソースが作成され、oneM2M側で、そのInputDataPointの値が変えられるときにIPEが受信されるようにされる。oneM2M側の変化が受信されたら、対応InputDataPointの他規格APIが利用されて他規格デバイスに対して更新が行われる（図１４中のｄ）。
　ここまでの処理フローは「Device」，「Service」，「DataPoint」でなる三つの抽象クラスで高度に共通化された。それぞれのインスタンスの処理の違いは、全てオントロジーに定義され、処理の実行時に動的にパラメータ（parameter）として読込まれて動作がなされる。また、子デバイスと子サービスの処理も、メタデータフィールド「consistsOf」が利用されて抽出されてから、共通的に行われる。
　ここで、オントロジーのAEへの提供について説明する。　
　作成したオントロジーで表わされる他規格デバイスのデータ構造は、上層のAEに対しても有効な知識である。図１４に示されたデバイス、サービスを表すoneM2Mリソースの下層にある<SD>（Semantic Descriptor）リソースに対応のオントロジー情報が以下のルール（rule）（ａ），（ａ）に沿って保管され、SPARQL言語と称される機械可読のデバイス・サービス発見とデータ取得に係るインタフェースがAEに提供される。　
　（ａ）Device，Service間の部分は各デバイスの<SD>に保管される。　
　（ｂ）Service，DataPoint間の部分は各サービスリソースの配下の＜SD＞に保管される。
　（形態2．）
　次に、基本形態に対する拡張形態としての「形態2．：時系列データ蓄積」の詳細について説明する。図１５は、時系列データの蓄積の一例について説明する図である。　
　時系列データの蓄積における課題を説明する。元々、oneM2MのOBIではデータは最新値しか共通PFに保存されていなかったので、過去の時系列情報が必要な分析が行なわれるとき（例えばカルマンフィルタ（kalman filter）のような分析、又はイベントログ（event log）による障害切り分けなど）にはアプリ側でデータが保存されていない限りは対応できなかった。
　そこで、形態2．の技術では、<Protocol:storeTimeseries>が用いられて、時系列データとしての蓄積機能フィールドが新たに追加されることで、時系列ヒストリーデータ（history data）が共通PF上に格納される。
　次に、形態.2におけるオントロジー拡張フィールドについて説明する。図１６は、オントロジー拡張フィールドの一例を説明する図である。　
　図１６に示されるように、形態.2では、共通PFサーバ３０に他規格のデバイスからの時系列データを格納することが規定されるメタデータフィールド「規格名：storeTimeseries」が用いられて、時系列ヒストリーデータが共通PF上に格納される。
　図１６に示された（Option.1）では、メタデータフィールド「規格名：storeTimeseries」がServiceリソースに追加され、trueに設定される場合、当該Serviceリソースの配下の全てのOutputDataPointが一つの共通PF上のTimeSeriesリソース（TimeSeriesと称することがある）に統合されて保存される。
　図１６に示された(Option.2)では、メタデータフィールド「規格名：storeTimeseries」がOutputDataPointに追加され、trueに設定される場合、当該OutputDataPointの値が一つの共通PF上のTimeSeriesリソースに保存される。　
　形態2．における、変換プロキシ接続時のワークフローは形態1．と同じである。
　次に、（Option.1）におけるデータ交換のワークフローについて説明する。図１７，図１８は、データ交換のワークフローの一例を示す図であり、図１９は、データ交換のシーケンスの一例を示す図である。　
　（Option.1）におけるデータ交換では、オントロジーに記述されたServiceリソースの配下のstoreTimeseriesのBoolean値が用いられて、Serviceリソースの配下のOutputDataPointの共通的な履歴データ保管処理が行なわれる。
　まず、オントロジー読取部２１は、ServiceのstoreTimeseriesがtrueであるか否かを判断し（Ｓ５１）、trueであれば、オントロジー読取部２１は、格納部XにおけるstoreTSforServiceのFlagをtrueに設定する（Ｓ５２）。
　Ｓ５２の後、共通交換部２４は、データ保管部３１の格納部WにおけるServiceリソースの子リソースに時系列データ格納リソースがあるか否かを判断する（Ｓ５３）。時系列データ格納リソースがなければ（Ｓ５３のＮｏ）、共通交換部２４は、これをデータ保管部３１の格納部WにおけるServiceリソースの子リソースに作成する（Ｓ５４）。　
　ここで、センサデータ交換部２３は、他PFからセンサデータを取得して、このセンサデータを共通交換部２４に送信する。共通交換部２４は、送信されたセンサデータにより、データ保管部３１におけるセンサデータを更新する（OutputDataPointの値を更新する）。　
　Ｓ５１でＮｏのとき、Ｓ５３でＹｅｓのとき、又はＳ５４の後は、上記のOutputDataPoint交換フロー（Ｓ４１～Ｓ４７)がなされる。
　OutputDataPoint交換フローの後、共通交換部２４は、storeTSforServiceのFlagがtrueであるか否かを判別し（Ｓ５５）、trueでなければ（Ｓ５５のＮｏ）、処理が終了し、trueであれば（Ｓ５５のＹｅｓ）、Serviceが有するOutputDataPointを１つのJSONにマージ（merge）し、このマージされた結果をデータ保管部３１に送る（Ｓ５６）。
　共通交換部２４は、送られたJSONを時系列データ格納リソースに追加してデータ保管部３１に送り（Ｓ５７）、処理が終了する。センサデータの取得からＳ５７までの処理は設定された周期で繰り返される。
　また、アプリによる処理開始後、データ検索部３２は、SPARQLによりオントロジーデータ内のstoreTimeseriesを確認し、URIデータを取得し、このデータをアプリに送る（Ｓ５８）。　
　アプリは時系列データの取得をデータ保管部３１にリクエストし、データ保管部３１は、格納部Xから時系列データを取得し（Ｓ５９）、データ検索部３２は、アプリに時系列データを返答し（Ｓ５１１）、処理が終了する。
　次に、時系列データ蓄積の（Option1.）の手順について説明する。図２０は、時系列データ蓄積の手順の一例を示す図である。　
　図２０に示されるように、時系列データ蓄積の（Option1.）では以下の(1)～(9)の処理がなされる。　
　(1)変換プロキシによりOntologyが読み込まれ、storeTimeseries:trueのServiceに対して変換プロキシ内storeTSforServiceがtrueにsetされる。　
　(2)storeTSforServiceFlagがtrueの場合、対象Service<fcnt>の子リソースに対象ts_Service<ts>があるか調べられる。　
　(3)ts_Service<ts>がなければCREATEされる。　
　(4)変換プロキシから、他規格PF/DeviceのAPI経由でデータが得られる。　
　(5)Serviceリソースの下層のOutputDataPointが1つのJSONにマージされる。　
　(6)変換プロキシが上記JSONをCREATEする（ts_Service<ts>/<tsi>）。　
　(7)アプリが、SPARQLにより欲しいServiceのstoreTimeseries状態を確認する。　
　(8)アプリが対象<ts>を取得する。　
　(9)アプリが<ts>/<latest>などを取得する。
　次に、形態2.の（Option1.）の実施例を説明する。図２１は、時系列データ蓄積の実施例を示す図である。　
　（Option1.）では、複数のDataPointが纏めて蓄積されるケースで、Serviceごとに時系列データ保存のON/OFFが設定される。ここで、対象のServiceリソースの下層にTs（時系列データ）が作成され、Service配下にある全てのOutputDataPointが纏めて<tsi>のconにJSONで格納される。図２１に示された例では、共通PF内のリソースツリーにおける最上位の「<共通PFBase>」から「SUN_Device<アプリ>」、「getGPS<fc>」、「ts_getGPS<ts>」を経た２つの「<tsi>」にインスタンス「getGPS」の下層のDataPoint値が纏めて格納される（{datadataLongitude:XXX, dataLatitude:YYY}）。
　次に、（Option.2）におけるデータ交換のワークフローについて説明する。図２２，図２３は、データ交換のワークフローの一例を示す図であり、図２４は、データ交換のシーケンスの一例を示す図である。　
　（Option.2）におけるデータ交換では、オントロジーに記述された他規格APIが用いられて、OutputDataPoint（他規格PF或いはデバイスからデータ/コマンドを取得）の共通的な処理が行なわれる。
　まず、オントロジー読取部２１は、OutputDataPointのstoreTimeseriesがtrueであるか否かを判断し（Ｓ６１）、trueであれば（Ｓ６１のＹｅｓ）、オントロジー読取部２１は、格納部XにおけるstoreTimeseriesDataPointのFlagをtrueに設定する（Ｓ６２）。
　Ｓ６２の後、共通交換部２４は、格納部WにおけるServiceリソース（対象Service<fc>）の子リソースにOutputDataPointの時系列データ格納リソースがあるか否かを判断する（Ｓ６３）。　
　時系列データ格納リソースがなければ（Ｓ６３のＮｏ）、共通交換部２４は、この時系列データ格納リソースをデータ保管部３１の格納部WにおけるServiceリソースの子リソースに作成する（Ｓ６４）。ここで、センサデータ交換部２３は、他PFからセンサデータを取得して、このセンサデータを共通交換部２４に送信する。共通交換部２４は、送信されたセンサデータにより、データ保管部３１におけるセンサデータを更新し（OutputDataPointの値を更新し）。
　Ｓ６１でＮｏのとき、Ｓ６３でＹｅｓのとき、又はＳ６４の後は、上記のOutputDataPoint交換フロー（Ｓ４１～Ｓ４７)がなされる。　
　OutputDataPoint交換フローの後、共通交換部２４は、storeTimeseriesDataPointのFlagがtrueであるか否かを判別し（Ｓ６５）、trueでなければ（Ｓ６５のＮｏ）処理が終了し、trueであれば（Ｓ６５のＹｅｓ）、共通交換部２４は、OutputDataPointを時系列データ格納リソースに追加してデータ保管部３１に送り、処理が終了する（Ｓ６６）。センサデータの取得からＳ６６までの処理は設定された周期で繰り返される。
　また、アプリによる処理開始後、データ検索部３２は、SPARQLによりオントロジーデータ内のstoreTimeseriesを確認し、URIデータを取得し、このURIデータをアプリに送る（Ｓ６８）。　
　アプリは時系列データの取得をデータ保管部３１にリクエストし、データ保管部３１は、格納部Xから時系列データを取得し（Ｓ６９）、データ検索部３２は、アプリに時系列データを返答し（Ｓ６１１）、処理が終了する。
　次に、時系列データ蓄積の（Option2.）の手順について説明する。図２５は、時系列データ蓄積の手順の一例を示す図である。　
　図２５に示されるように、時系列データ蓄積の（Option2.）では以下の(1)～(8)の処理がなされる。　
　(1)変換プロキシがOntologyを読み、storeTimeseries:trueのOutputDataPointに対してObiServiceWrapperのstoreTimeseriesをtrueにsetする。　
　(2)ObiServiceWrapperのstoreTimeseriesFlagがtrueの場合、変換プロキシは、対象Service<fcnt>の子リソースに対象ts_OutputDataPoint<ts>があるか調べる。　
　(3)ts_OutputDataPoint<ts>がなければCREATEされる。　
　(4)変換プロキシから他規格PF/DeviceのAPI経由でデータが得られる。　
　(5)変換プロキシはDataPointをCREATEする（ts_OutputDataPoint<ts>/<tsi>）。　
　(6)アプリはSPARQLにより所望のServiceのstoreTimeseries状態を確認する。　
　(7)アプリは対象<ts>を取得する。　
　(8)アプリは<ts>/<latest>などを取得する。
　次に、形態2.の（Option2.）の実施例を説明する。図２６は、時系列データ蓄積の実施例を示す図である。　
　（Option2.）では、DataPointごとの蓄積が望まれる場合、OutputDataPointに時系列データ保存のON/OFFが設定される。　
　ここで、対象のOutputDataPoint毎にTs（時系列データ）が作成され、dataHumidity値がtsiのconに格納される。図２６に示された例では、共通PF内のリソースツリーにおける最上位の「<共通PFBase>」から「SUN_Device<アプリ>」、「getSensings<fc>」、「dataHumidity(float)」、「ts_dataHumidity<ts>」（「dataHumidity(float)と同じ層）を経た２つの「<tsi>」にインスタンス「dataHumidity」の下層のdataHumidity値が格納される。
　（形態3．）
　次に、基本形態に対する拡張形態としての「形態3．：オンデマンドによる取得」の詳細について説明する。図２７は、オンデマンドによる取得結果の蓄積の一例について説明する図である。　
　オンデマンドによる取得における課題を説明する。元々、oneM2MのOBIでは得られたデータが常に更新され続けていたが、高頻度でデータを発生するデバイスに対してデータ利用の需要が少ないときはデータが更新されても無駄になるケースが考えられる。
　そこで、形態3．の技術では、<Protocol:onDemand>が用いられ、データの最新値は共通PFに保存されずに、アプリからのリクエストによってオンデマンドで他規格デバイス（或いはPF）から取得される機能フィールドが新たに追加されることで、利用者の需要に応じてデータが取得される。
　次に、形態.3におけるオントロジー拡張フィールドについて説明する。図２８は、オントロジー拡張フィールドの一例を説明する図である。　
　図２８に示すように、形態.3では、デバイスからの最新のデータをアプリケーションからの要求によって当該デバイスから取得することを規定するメタデータフィールド「規格名：onDemand」を用いて、アプリからのリクエストによってオンデマンドで他規格デバイス（或いはPF）からデータを取得する。
　形態3.では、メタデータフィールド「規格名：onDemand」がOutputDataPointに追加され、trueに設定される場合、共通PFが常に他規格PF/Deviceから最新値を取り続けるのではなく、アプリからのリクエストに応じてオンデマンドが値が取得されていく。　
　形態3.における、変換プロキシ接続時のワークフローは形態1．と同じである。
　次に、形態3.におけるデータ交換のワークフローについて説明する。図２９，図３０は、データ交換のワークフローの一例を示す図であり、図３１は、データ交換のシーケンスの一例を示す図である。　
　形態3.におけるデータ交換では、オントロジーに記述されたonDemandのBoolean値が用いられて、OutputDataPointの共通的な、オンデマンドによる取得処理が行なわれる。　
　他規格のプロトコルとのデータマッピングおよび交換を担うIPE登録により処理が開始されると、オントロジー読取部２１は、格納部XにおけるOutputDataPointのonDemandがtrueであるか否かを判断し（Ｓ７１）、trueであれば（Ｓ７１のＹｅｓ）、共通交換部２４は、共通PFに当該OutputDataPointの親Serviceの下層におけるsubscriptionの作成をリクエストし、通知先を変換プロキシに設定する（Ｓ７２）。　
　共通交換部２４は、共通PFに当該OutputDataPointの親Serviceの下層にsubscriptionを作成してデータ保管部３１に送り、処理が終了する（Ｓ７３）。
　Ｓ７１でtrueでなければ（Ｓ７１のＮｏ）、OutputDataPoint交換フロー（Ｓ４１～Ｓ４７)がなされて、処理が終了する。
　また、アプリによる処理開始後、データ検索部３２は、SPARQLにより格納部Vにおけるオントロジーデータ内のonDemand=trueを確認し、URIデータを取得し、このURIデータをアプリに送る（Ｓ７４）。
　アプリは、所望のDataPointにSubscriptionを作成し、このSubscriptionをデータ保管部３１の格納部Wに格納する（Ｓ７５）。　
　アプリは、データ取得希望（DataPointを更新“demanding”）をデータ保管部３１に送る（Ｓ７６）。
　データ保管部３１は、DataPointの変更を共通交換部２４に通知する（Ｓ７７）。　
　共通交換部２４は、“demanding“状態のDataPointを確認する（Ｓ７８）。　
　共通交換部２４は、センサデータ交換部２３にDemanding通知を行う（Ｓ７９）。　
　センサデータ交換部２３は、他PFからセンサデータを取得し（Ｓ７１１）、OutputDataPointを共通交換部２４に送信する（Ｓ７１２）。
　共通交換部２４は、データ保管部３１の格納部WにおけるOutputDataPointにセンサデータを反映して更新する（Ｓ７１３）。　
　データ保管部３１はデータ検索部３２を介してセンサデータをアプリに通知する（Ｓ７１４）。　
　データ検索部３２は、センサデータを受け取ったらデータ保管部３１の格納部WにおけるSubアプリを削除する（Ｓ７１５）。
　次に、オンデマンドによる取得の手順について説明する。図３２は、オンデマンドによる取得の手順の一例を示す図である。　
　図３２に示されるように、オンデマンドによる取得では以下の(1)～(10)の処理がなされる。　
　(1)変換プロキシがOntologyを読み、onDemand:trueのDataPointに対して共通PF内の対象Service<fcnt>の下層にsub変換プロキシ<sub>を作る。Serviceが複数のDataPointを有する場合も１つのsubscriptionが、後ほどのnotify受信時に、DataPoint単位で通知が振り分けられる。　
　(2)アプリはSPARQLにより所望のDataPointのonDemand状態を確認する。　
　(3)onDemandがTrueである場合は、対象Service<fcnt>の下層にsubアプリ<sub>が作られる。
　(4)所望のDataPointがUPDATEされる（[DataPoint]:”demanding”）。　
　(5)上記により共通PFから変換プロキシにNotifyされる（sub変換プロキシ）。　
　(6)変換プロキシ内でNotificationの内容が確認される。　
　(7)変換プロキシから他規格PF/DeviceのAPI経由でデータが得られる。　
　(8)変換プロキシはDataPointをUPDATEする（[DataPoint]:{value}）。　
　(9)上記により共通PFからアプリにNotifyされる（subアプリ）。　
　(10)データを受け取ったらアプリはsubアプリを削除する。
　次に、形態3.の実施例を説明する。図３３は、オンデマンドによる取得の実施例を示す図である。　
　形態3.では、OutputDataPoint毎にデータがオンデマンドで取得されるか否かが設定される。図３３に示された例では、dataCO2値がオンデマンドで取得されて、共通PF内のリソースツリーに一旦格納されてアプリに送られる。図３３に示された例では、共通PF内のリソースツリーにおける最上位の「<共通PFBase>」から「CO2_Device<アプリ>」を経た「getCO2<fc>」の下層の「dataCO2(float)[customAttribute]」にインスタンス「dataCO2」の下層の値が格納される。
　（形態4．）
　次に、基本形態に対する拡張形態としての「形態4．：スパン（span）指定オンデマンドによる一括取得」の詳細について説明する。図３４は、オンデマンドによる一括取得の結果の蓄積の一例について説明する図である。　
　オンデマンドによる一括取得における課題を説明する。　
　元々、oneM2MのOBIでは、得られたデータの最新値のみが保持される。このため、他PFに過去のデータが蓄積されていたとしても、アプリからのリクエストで、これらのデータが取得されることはできなかった。
　そこで、形態4．の技術では、<Protocol:onDemandTS>が用いられ、アプリからのリクエストによってオンデマンドで、指定された期間で、他規格のデバイス（或いはPF）からデータが一括で取得される機能フィールドが新たに追加される。この技術では、他PFに蓄積される過去の一定期間分だけのデータが、利用者の需要に応じて一括で取得される。
　次に、形態.4におけるオントロジー拡張フィールドについて説明する。図３５は、オントロジー拡張フィールドの一例を説明する図である。　
　図３５に示されるように、形態.4では、デバイスに固有の他規格PF/Deviceに保管された時系列データがアプリケーションからの要求によって一括して取得されることが規定されるメタデータフィールド「規格名：onDemandTS」が用いられる。そして、アプリからのリクエストによってオンデマンドで、他規格デバイス（或いはPF）から、この他規格PF/Deviceに保管される履歴データが一括で取得される。
　形態4.では、メタデータフィールド「規格名：onDemandTS」がOutputDataPointに追加され、このonDemandTSがtrueに設定される場合、共通PFが他規格PF/Deviceから常に最新値を取り続けるのではなく、アプリからのリクエストに応じてオンデマンドでデータが取得されていく。データが取得される際に、アプリにより指定されたタイムスパンで履歴データが一括で取得され、共通PFに保存される。　
　形態4.における、変換プロキシ接続時のワークフローは形態1．と同じである。
　次に、形態4.におけるデータ交換のワークフローについて説明する。図３６は、データ交換のワークフローの一例を示す図であり、図３７は、データ交換のシーケンスの一例を示す図である。　
　形態4.におけるデータ交換では、オントロジーに記述されたonDemandTSのBoolean値が用いられて、OutputDataPointの共通的なオンデマンドスパンが指定されて、一括での取得処理が行なわれる。
　IPE登録により処理が開始されると、図２９で説明したＳ７１～Ｓ７４、およびOutputDataPoint交換フロー（Ｓ４１～Ｓ４７)がなされる。
　また、アプリによる処理開始後、図３０に示されたＳ７４～Ｓ７９までの処理がなされ、センサデータ交換部２３は、他PFから指定期間分のセンサデータを取得し（Ｓ７１１）、OutputDataPoint（センサデータ）を共通交換部２４に送信する（Ｓ７１２）。
　共通交換部２４は、対象OutputDataPointの時系列データ格納リソースがあるか否かを調べて、なければ、このリソースを作成し、このリソースの下層にセンサデータ群を作成する（Ｓ７１３ａ）。以降は、図３０で説明したＳ７１４，Ｓ７１５がなされて処理が終了する。
　次に、スパン指定オンデマンドによる一括取得の手順について説明する。
　スパン指定オンデマンドによる一括取得では、図３２に示された(1)から(5)までがなされた上で、以下の(6)以降がなされる。　
　(6)変換プロキシ内でNotificationの内容が確認され、データの取得期間が確認される。　
　(7)変換プロキシから他規格PF/DeviceのAPI経由でデータが得られる。　
　(8)対象OutputDataPoint<ts>があるか否かが調べられ、なければ、この対象OutputDataPoint<ts>がCREATEされ、この下層にデータ更新がCREATEされる（Device/Service/<ts>/<tsi>）。　
　(9)上記により共通PFからアプリにNotify（subアプリ）される。　
　(10)データを受け取ったら、アプリはsubアプリを削除する。
　次に、形態4.の実施例を説明する。図３８は、オンデマンドによる一括取得の実施例を示す図である。　
　形態4.では、OutputDataPoint毎にデータをオンデマンドで一括取得するか否かと、データが取得される期間とが設定される。図３８に示された例では、共通PF内のリソースツリーにおける最上位の「<共通PFBase>」から「SUN_Device<アプリ>」、「getSensings<fc>」、「ts_dataTemp<ts>」を経た２つの「<tsi>」に、取得された過去データとしての、インスタンス「dataTemp」の下層の値が蓄積される。
　図３９は、本発明の一実施形態に係る情報処理システムのハードウエア構成の一例を示すブロック図である。　
　図３９に示された例では、上記の実施形態に係る情報処理システムにおけるデータ処理装置１０は、例えばサーバコンピュータ（server computer）またはパーソナルコンピュータ（personal computer）により構成され、ＣＰＵ等のハードウエアプロセッサ（hardware processor）１１１Ａを有する。そして、このハードウエアプロセッサ１１１Ａに対し、プログラムメモリ（program memory）１１１Ｂ、データメモリ（data memory）１１２、入出力インタフェース１１３及び通信インタフェース１１４が、バス（bus）１２０を介して接続される。図３に示される共通PFサーバ３０についても同様である。
　通信インタフェース１１４は、例えば１つ以上の無線の通信インタフェースユニットを含んでおり、通信ネットワークＮＷとの間で情報の送受信を可能にする。無線インタフェースとしては、例えば無線ＬＡＮ（Local Area Network）などの小電力無線データ通信規格が採用されたインタフェースが使用される。
　入出力インタフェース１１３には、データ処理装置１０に付設される、オペレータ（operator）用の入力デバイス５０および出力デバイス６０が接続される。　
　入出力インタフェース１１３は、キーボード、タッチパネル（touch panel）、タッチパッド（touchpad）、マウス（mouse）等の入力デバイス５０を通じてオペレータにより入力された操作データを取り込むとともに、出力データを液晶または有機ＥＬ（Electro Luminescence）等が用いられた表示デバイスを含む出力デバイス６０へ出力して表示させる処理を行なう。なお、入力デバイス５０および出力デバイス６０には、データ処理装置１０に内蔵されたデバイスが使用されてもよく、また、通信ネットワークＮＷを介してデータ処理装置１０と通信可能である他の情報端末の入力デバイスおよび出力デバイスが使用されてもよい。
　プログラムメモリ１１１Ｂは、非一時的な有形の記憶媒体として、例えば、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）等の随時書込みおよび読出しが可能な不揮発性メモリ（non-volatile memory）と、ＲＯＭ（Read Only Memory）等の不揮発性メモリとが組み合わせて使用されたもので、一実施形態に係る各種制御処理を実行する為に必要なプログラムが格納されている。
　データメモリ１１２は、有形の記憶媒体として、例えば、上記の不揮発性メモリと、ＲＡＭ（Random Access Memory）等の揮発性メモリ（volatile memory）とが組み合わせて使用されたもので、各種処理が行なわれる過程で取得および作成された各種データが記憶される為に用いられる。
　本発明の一実施形態に係るデータ処理装置１０は、ソフトウエア（software）による処理機能部として、図３などに示されるオントロジー作成部、オントロジー読取部２１、デバイス管理部２２、センサデータ交換部２３および共通交換部２４を有するデータ処理装置として構成され得る。図３に示されるデータ保管部３１およびデータ検索部３２を有する共通PFサーバ３０についても同様である。
　データ処理装置１０のオントロジーデータ格納部２１ａ、デバイス情報格納部２２ａおよびセンサデータ格納部２３ａは、図３９に示されたデータメモリ１１２が用いられることで構成され得る。共通PFサーバ３０のオントロジーデータ格納部３１ａおよびデータツリー格納部３１ｂについても同様である。ただし、これらの格納部はデータ処理装置１０内に必須の構成ではなく、例えば、ＵＳＢ（Universal Serial Bus）メモリなどの外付け記憶媒体、又はクラウドに配置されたデータベースサーバ（database server）等の記憶装置に設けられたものであってもよい。
　上記のオントロジー作成部、オントロジー読取部２１、デバイス管理部２２、センサデータ交換部２３および共通交換部２４の各部における処理機能部は、いずれも、プログラムメモリ１１１Ｂに格納されたプログラムを上記ハードウエアプロセッサ１１１Ａにより読み出させて実行させることにより実現され得る。図３に示されるデータ保管部３１およびデータ検索部３２についても同様である。なお、これらの処理機能部の一部または全部は、特定用途向け集積回路（ＡＳＩＣ（Application Specific Integrated Circuit））またはＦＰＧＡ（Field-Programmable Gate Array）などの集積回路を含む、他の多様な形式によって実現されてもよい。
　以上説明したように、本発明の一実施形態に係る情報処理システムでは、固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータと、デバイス情報とに基づいて、規格に共通したデータ構造と固有の規格に対応したデータ交換インタフェースとを関連付けたリソースが作成されて、共通プラットフォームサーバとの間でデータ交換が行なわれる。これにより、規格ごとにコーディングする必要があった部分を共通化した上でデータ交換を行なうことができる。
　上記目的を達成するために、この発明の一実施形態に係る情報処理システムの第１の態様は、複数種類の固有の規格に対応したデバイスに接続され、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバに更に接続される、変換プロキシを有する情報処理システムであって、前記変換プロキシは、前記固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得する取得部と、前記複数種類の固有の規格に対応したデバイスに対応付けられた固有のデバイス情報を取得して管理するデバイス管理部と、前記取得部により取得されたオントロジーデータと前記デバイス管理部により管理されるデバイス情報とに基づいて、前記複数種類の固有の規格に共通したデータ構造と前記固有の規格に対応したデータ交換インタフェースとが関連付けられたリソースを作成し、前記作成されたリソースを用いて前記共通プラットフォームサーバとの間でデータ交換を行なう共通交換部とを備える。
　この発明の情報処理システムの第２の態様は、第１の態様において、前記共通プラットフォームサーバは、前記デバイスから取得したデータを保管するデータ保管部を有し、前記リソースは、前記データ保管部に前記デバイスから取得した最新のデータを格納することを規定する第１のデータフィールドを有し、前記変換プロキシの前記共通交換手段は、前記第１のデータフィールドの規定に基づいて、前記デバイスから取得した最新のデータを前記データ保管部に保管する。
　この発明の情報処理システムの第３の態様は、第１の態様において、前記共通プラットフォームサーバは、前記デバイスから取得したデータを保管するデータ保管部を有し、前記リソースは、前記データ保管部に前記デバイスから取得した時系列データを格納することを規定する第２のデータフィールドを有し、前記変換プロキシの前記共通交換手段は、前記第２のデータフィールドの規定に基づいて、前記デバイスから取得した時系列データを前記データ保管部に保管する。
　この発明の情報処理システムの第４の態様は、第１の態様において、前記リソースは、前記デバイスから取得した最新のデータを前記アプリケーションからの要求に応じて前記デバイスから取得することを規定する第３のデータフィールドを有し、前記変換プロキシの前記共通交換手段は、前記アプリケーションからの要求に応じて、前記第３のデータフィールドの規定に基づいて、前記デバイスから取得したデータを前記共通プラットフォームサーバを介して前記アプリケーションに送る。
　この発明の情報処理システムの第５の態様は、第１の態様において、前記リソースは、前記デバイスに対応付けられた固有の保管部に保管された時系列データをアプリケーションからの要求に応じて一括して取得することを規定する第４のデータフィールドを有し、前記変換プロキシの前記共通交換手段は、前記アプリケーションからの要求に応じて、前記第４のデータフィールドの規定に基づいて、前記保管部から取得したデータを前記共通プラットフォームサーバを介して前記アプリケーションに送る。
　本発明の一実施形態に係る情報処理プログラムの一つの態様は、第１乃至第５の態様のいずれか１つにおける情報処理システムの前記各手段としてプロセッサを機能させるものである。
　この発明の一実施形態に係る情報処理システムの第１の態様によれば、固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータと、デバイス情報とに基づいて、規格に共通したデータ構造と固有の規格に対応したデータ交換インタフェースとが関連付けられたリソースが作成され、このリソースに基づいて共通プラットフォームサーバとの間でデータ交換が行われる。これにより、規格ごとにコーディングする必要があった部分が共通化された上でデータ交換が可能である。
　この発明の一実施形態に係る情報処理システムの第２の態様によれば、リソースは、共通プラットフォームにデバイスから取得された最新のデータを格納することを規定したデータフィールドを有し、このデータフィールドでの規定に応じて、デバイスから取得した最新のデータが共通プラットフォームのデータ保管部に保管される。これにより、規格ごとにコーディングする必要があった部分が共通化された上でデバイスから最新のデータが得られる。
　この発明の一実施形態に係る情報処理システムの第３の態様によれば、リソースは、共通プラットフォームにデバイスからの時系列データを格納することが規定されたデータフィールドを有し、このデータフィールドでの規定に応じて、デバイスから取得した時系列データが共通プラットフォームのデータ保管部に保管される。これにより、規格ごとにコーディングする必要があった部分が共通化された上で、デバイスからの時系列データが得られる。
　この発明の一実施形態に係る情報処理システムの第４の態様によれば、リソースは、デバイスからの最新のデータがアプリケーションからの要求によってデバイスから取得すされることが規定されるデータフィールドを有し、このデータフィールドでの規定に応じて、デバイスから取得したデータがアプリケーションに送られる。これにより、規格ごとにコーディングされる必要があった部分が共通化された上で、デバイスから最新のデータがアプリケーションに渡され得る。
　この発明の一実施形態に係る情報処理システムの第５の態様によれば、リソースは、デバイスに固有の保管部に保管された時系列データがアプリケーションからの要求によって一括して取得されることが規定されるデータフィールドを有し、アプリケーションからの要求によって、上記データフィールドの規格に応じて、上記保管部から取得したデータが共通プラットフォームサーバを介してアプリケーションに送られる。これにより、規格ごとにコーディングされる必要があった部分が共通化された上で、デバイス側の時系列データがアプリケーションに渡され得る。
　また、各実施形態に記載された手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク（Floppy disk）、ハードディスク等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ（Flash memory）等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブル、データ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスク、半導体メモリ等の記憶媒体を含むものである。
　なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の発明が含まれており、開示される複数の構成要件から選択された組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、課題が解決でき、効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
　　１０…データ処理装置
　　１１…オントロジー作成部
　　２１…オントロジー読取部
　　２１ａ…オントロジーデータ格納部
　　２２…デバイス管理部
　　２２ａ…デバイス情報格納部
　　２３…センサデータ交換部
　　２３ａ…センサデータ格納部
　　２４…共通交換部
　　３０…共通PFサーバ
　　３１…データ保管部
　　３１ａ…オントロジーデータ格納部
　　３１ｂ…データツリー格納部
　　３２…データ検索部

Claims (7)

  1. 　複数種類の固有の規格に対応したデバイスに接続され、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバに更に接続される、変換プロキシを有する情報処理システムであって、
    　前記変換プロキシは、
    　　前記固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得する取得部と、
    　　前記複数種類の固有の規格に対応したデバイスに対応付けられた固有のデバイス情報を取得して管理するデバイス管理部と、
    　　前記取得部により取得されたオントロジーデータと前記デバイス管理部により管理されるデバイス情報とに基づいて、前記複数種類の固有の規格に共通したデータ構造と前記固有の規格に対応したデータ交換インタフェースとが関連付けられたリソースを作成し、前記作成されたリソースを用いて前記共通プラットフォームサーバとの間でデータ交換を行なう共通交換部と、
    　を備えた情報処理システム。
  2. 　前記共通プラットフォームサーバは、
    　　前記デバイスから取得したデータを保管するデータ保管部を有し、
    　前記リソースは、
    　　前記デバイスから取得した最新のデータを前記データ保管部に格納することが規定される第１のデータフィールドを有し、
    　前記変換プロキシの前記共通交換部は、
    　　前記第１のデータフィールドでの規定に基づいて、前記デバイスから取得した最新のデータを前記データ保管部に保管する、
    　請求項１に記載の情報処理システム。
  3. 　前記共通プラットフォームサーバは、
    　　前記デバイスから取得したデータを保管するデータ保管部を有し、
    　前記リソースは、
    　　前記デバイスから取得した時系列データを前記データ保管部に格納することが規定される第２のデータフィールドを有し、
    　前記変換プロキシの前記共通交換部は、
    　　前記第２のデータフィールドでの規定に基づいて、前記デバイスから取得した時系列データを前記データ保管部に保管する、
    　請求項１に記載の情報処理システム。
  4. 　前記リソースは、
    　　前記デバイスから取得した最新のデータを前記アプリケーションからの要求に応じて前記デバイスから取得することが規定される第３のデータフィールドを有し、
    　前記変換プロキシの前記共通交換部は、
    　　前記アプリケーションからの要求に応じて、前記第３のデータフィールドでの規定に基づいて、前記デバイスから取得したデータを前記共通プラットフォームサーバを介して前記アプリケーションに送る、
    　請求項１に記載の情報処理システム。
  5. 　前記リソースは、
    　　前記デバイスに対応付けられた固有の保管部に保管された時系列データをアプリケーションからの要求に応じて一括して取得することが規定される第４のデータフィールドを有し、
    　前記変換プロキシの前記共通交換部は、
    　　前記アプリケーションからの要求に応じて、前記第４のデータフィールドでの規定に基づいて、前記保管部から取得したデータを前記共通プラットフォームサーバを介して前記アプリケーションに送る、
    　請求項１に記載の情報処理システム。
  6. 　複数種類の固有の規格に対応したデバイスに接続されて、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバに更に接続される、変換プロキシを有する情報処理システムが行なう情報処理方法であって、
    　前記変換プロキシは、
    　　前記固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得し、
    　　前記複数種類の固有の規格に対応したデバイスに対応付けられた固有のデバイス情報を取得して管理し、
    　　前記取得されたオントロジーデータと前記管理されるデバイス情報とに基づいて、前記複数種類の固有の規格に共通したデータ構造と前記固有の規格に対応したデータ交換インタフェースとが関連付けられたリソースを作成して、前記作成されたリソースを用いて前記共通プラットフォームサーバとの間でデータ交換を行なう、
    　情報処理方法。
  7. 　請求項１乃至５のいずれか１項に記載の情報処理システムの前記各部としてプロセッサを機能させる情報処理プログラム。
PCT/JP2019/049472 2018-12-18 2019-12-17 情報処理システム、方法およびプログラム WO2020129995A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/414,284 US11843678B2 (en) 2018-12-18 2019-12-17 Information processing system, method, and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018236520A JP7059916B2 (ja) 2018-12-18 2018-12-18 情報処理システム、方法およびプログラム
JP2018-236520 2018-12-18

Publications (1)

Publication Number Publication Date
WO2020129995A1 true WO2020129995A1 (ja) 2020-06-25

Family

ID=71101962

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/049472 WO2020129995A1 (ja) 2018-12-18 2019-12-17 情報処理システム、方法およびプログラム

Country Status (3)

Country Link
US (1) US11843678B2 (ja)
JP (1) JP7059916B2 (ja)
WO (1) WO2020129995A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101808483B1 (ko) * 2017-03-31 2018-01-18 국방과학연구소 조절형 파편탄두의 제작 방법 및 조절형 파편탄두용 파편 성형 라이너

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016526231A (ja) * 2013-06-04 2016-09-01 アレバ・エヌペ 技術設備を記述したデータの交換の方法
WO2018064455A1 (en) * 2016-09-29 2018-04-05 Convida Wireless, Llc Access control policy synchronization for service layer

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016011361A1 (en) * 2014-07-18 2016-01-21 Convida Wireless, Llc M2m ontology management and semantics interoperability
WO2016118979A2 (en) * 2015-01-23 2016-07-28 C3, Inc. Systems, methods, and devices for an enterprise internet-of-things application development platform
KR20170109404A (ko) * 2016-03-21 2017-09-29 전자부품연구원 IoT 서비스 상호 연동을 위한 온톨로지 관리 방법 및 시스템
US11483418B2 (en) * 2017-12-06 2022-10-25 Intel Corporation Plugin management for internet of things (IoT) network optimization

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016526231A (ja) * 2013-06-04 2016-09-01 アレバ・エヌペ 技術設備を記述したデータの交換の方法
WO2018064455A1 (en) * 2016-09-29 2018-04-05 Convida Wireless, Llc Access control policy synchronization for service layer

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HARADA, MEGUMI, MAEOMICHI, HIROYUKI, YAMASAKI, IKUO.: "Overview of loT International Standard oneM2M", PROCEEDINGS OF THE 2017 IEICE SOCIETY CONFERENCE. INSTITUTE OF ELECTRONIC, INFORMATION AND CONTROL ENGINEERS . ), 13 September 2017 (2017-09-13), pages SS39 - SS42 *

Also Published As

Publication number Publication date
JP7059916B2 (ja) 2022-04-26
JP2020098483A (ja) 2020-06-25
US20220078257A1 (en) 2022-03-10
US11843678B2 (en) 2023-12-12

Similar Documents

Publication Publication Date Title
Datta et al. Smart m2m gateway based architecture for m2m device and endpoint management
Alaya et al. Toward semantic interoperability in oneM2M architecture
Datta et al. A lightweight framework for efficient M2M device management in oneM2M architecture
EP2914022B1 (en) Device management method, middleware, and machine-to-machine communications platform, device, and system
US10270648B2 (en) Configuration information management method, device, network element management system and storage medium
CN102821414B (zh) 基于gui图形交互界面的cwsn通讯数据管理系统和方法
KR102016905B1 (ko) 전력 소프트웨어 개발 플랫폼
US20190044755A1 (en) Network system, control apparatus, method and program for building virtual network function
Broering et al. Sensor bus: an intermediary layer for linking geosensors and the sensor web
Faschang et al. Provisioning, deployment, and operation of smart grid applications on substation level: bringing future smart grid functionality to power distribution grids
US10733035B1 (en) Dynamic optimization of application workflows
CN104144215A (zh) 一种物联网泛在设备资源模型的构建方法
CN101854343A (zh) 提供节点信息的方法、获取节点信息的方法及设备
KR102435498B1 (ko) 계층형 엔진 프레임워크에 기반한 크로스 도메인 워크플로우 제어 시스템 및 방법
JP2016518641A (ja) 複数のコンバージドインフラストラクチャシステムへのアクセス
Pan et al. Research of livestock farming IoT system based on RESTful web services
CN103488696A (zh) Cpe的业务查询方法、装置及系统、acs和cpe
Giang et al. Extending the EPCIS with Building automation systems: a new information system for the internet of things
WO2020129995A1 (ja) 情報処理システム、方法およびプログラム
US20200220919A1 (en) Overlay resource trees in a communication network
Jin et al. IoT device management architecture based on proxy
JP6621075B2 (ja) リソース取得方法および装置
Nguyen et al. Software-defined virtual sensors for provisioning iot services on demand
Kazmi et al. A qos-aware integrated management of iot deployments in smart cities
Tao et al. Hybrid cloud architecture for cross-platform interoperability in smart homes

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: 19901330

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: 19901330

Country of ref document: EP

Kind code of ref document: A1