KR102285352B1 - PROXY, METHOD FOR INTERWORKING BETWEEN HETEROGENEOUS IoT DEVICE AND IoT FLATFORM AND SYSTEM THE PROXY - Google Patents

Abstract

A method for interworking a heterogeneous IoT device and an IoT platform according to an embodiment of the present invention includes: generating a mapping table including a device ID, a resource ID, and protocol information of an unregistered device; generating a resource of the device based on the mapping table; generating and transmitting a command for reading device information from the device based on the resource; and when device information is received from the device in response to the command, updating the resource to have the device information.

Description

Proxy, method, and system including the proxy for interworking of heterogeneous IoT devices and IoT platforms

A proxy for interworking between a heterogeneous IoT device and an IoT platform, a system including the proxy, and a method of interworking between a heterogeneous IoT device and an IoT platform.

The Internet is evolving from a human-centered connection network where humans create and consume information, to an Internet of things (IoT) network that exchanges and processes information between distributed components such as things. In addition, technology elements such as sensing technology, wired/wireless communication and network infrastructure, service interface technology, and security technology are required to implement the IoT. Recently, a sensor network for connection between objects, a machine to Technology such as machine, M2M) and MTC (machine type communication) are being studied.

Due to the nature of IoT, there are many IoT devices using various network protocols. Heterogeneous IoT devices are connected through the IoT platform, and data can be transmitted to the IoT service through the IoT platform.

However, existing heterogeneous IoT devices and IoT platforms are connected by a developer's own implementation. In particular, in order to transmit a message from an IoT device using a protocol not supported by the IoT platform to the IoT platform, all necessary information has been stored and managed in the internal memory of the proxy that provides interworking.

In this case, the proxy cannot be reused, and excessive protocol mapping information has to be continuously stored in the proxy for interworking, resulting in memory wastage.

According to the oneM2M standard document, an international standard for IoT, the existing IoT architecture defines all things as resources and accessible through a unique URI. However, since the contents for storing the mapping information of heterogeneous protocols are not defined in these resources, the existing proxy had to store all information in the internal memory to proceed with interworking.

US Patent Publication No. 2018/0063879

An object of the present invention is to provide a proxy for interworking between a heterogeneous IoT device and a standards-based IoT platform, a system including the proxy, and a method of interworking between a heterogeneous IoT device and an IoT platform.

A method for interworking a heterogeneous IoT device and an IoT platform according to an embodiment of the present invention includes: generating a mapping table including a device ID, a resource ID, and protocol information of an unregistered device; generating a resource of the device based on the mapping table; generating and transmitting a command for reading device information from the device based on the resource; and when device information is received from the device in response to the command, updating the resource to have the device information.

After the resource is updated, the method may further include the step of notifying the device information to an application entity subscribing to the resource.

The IoT platform may be a oneM2M platform.

The resource may be a flexContainer.

The device information may be stored as a child resource or attribute of the resource.

The resource may include the protocol information.

The protocol of the device is Modbus, and the resource may include register file information of Modbus.

A proxy device for interworking between a heterogeneous IoT device and an IoT platform according to an embodiment of the present invention includes: a mapping table storage unit storing a mapping table including a device ID, a resource ID, and protocol information of an unregistered device; a resource management unit that creates a resource of the device in an IoT platform based on the mapping table; and a device communication unit configured to generate and transmit a command for reading device information from the device based on the resource, and receive device information from the device in response to the command, wherein the resource management unit comprises: the device communication unit The resource is updated using the device information received from .

A system for interworking between a heterogeneous IoT device and an IoT platform includes an unregistered device; IoT platform; and a mapping table storage unit storing a mapping table including device ID, resource ID, and protocol information of the device; a resource management unit generating a resource of the device in the IoT platform based on the mapping table; a device communication unit configured to generate and transmit a command for reading device information from the device based on the device and receive device information from the unregistered device in response to the command, wherein the resource management unit includes: and a proxy device for updating the resource using device information.

After the resource is updated with the device information, the IoT platform may notify an application entity subscribing to the resource of the updated device information.

According to an embodiment of the present invention, interworking between heterogeneous IoT devices and standards-based IoT platforms is possible in a standard way.

According to an embodiment of the present invention, a oneM2M-based resource capable of storing protocol mapping information of heterogeneous IoT devices is provided. Accordingly, there is no need to store all of the protocol mapping information in the proxy, so that the memory burden of the proxy can be reduced.

1 is a diagram showing a network configuration of oneM2M.
2 is a diagram for explaining a function of a proxy in an IoT network according to an embodiment of the present invention.
3 is a diagram for explaining a method of interworking between an IoT device and an IoT platform in an IoT network according to an embodiment of the present invention.
FIG. 4 is a diagram illustrating an example of the mapping table of FIG. 3 .
5 is a diagram illustrating an example of a resource of the IoT device of FIG. 3 .
6 is a diagram showing a Modbus register file.
7 is a diagram illustrating a resource according to an embodiment of the present invention.
8 is a diagram for explaining the correspondence between resources and a mapping table according to an embodiment of the present invention.
9 is a diagram illustrating a command for reading a battery level generated using the resource of FIG. 7 .
10 is a diagram illustrating the configuration of an IoT network according to an embodiment of the present invention.

A method or configuration of any embodiment described herein may be implemented with respect to any other method or configuration.

The terms or words used in the present specification and claims should not be construed as being limited to their ordinary or dictionary meanings, and the inventor may properly define the concept of the term in order to best describe his invention. Based on the principle, it should be interpreted as meaning and concept consistent with the technical idea of the present invention.

In the specification and claims, when a part "includes" a certain element, it means that other elements may be further included, rather than excluding other elements, unless otherwise stated.

The use of the word singular when used in conjunction with the term "comprising" in the specification and claims may mean "a," or "one or more," "at least one," and "one or more than one." may be

Terms such as “…unit”, “…group”, “module”, and “device” described in the specification and claims mean a unit that processes at least one function or operation, which is hardware or software or hardware and software. It can be implemented as a combination.

Like reference numerals refer to like elements throughout.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

1 is a diagram showing a network configuration of oneM2M.

1, the oneM2M network is an application dedicated node (ADN: Application Dedicated Node) 101, an application service node (ASN: Application Service Node) 103, a middle node (MN: Middle Node) 105) and an Infrastructure Node (IN) 107 .

The application-only node 101 is a device including an IoT application, and refers to a constrained device having limited functions including only IoT service logic. The application service node 103 refers to an IoT device that provides a common service as well as an IoT application. The intermediate node 105 is an IoT gateway that connects other nodes and the infrastructure node 107 , and the infrastructure node 107 may be an IoT server that is located in a network infrastructure and provides Internet of Things services.

Each of the nodes may include one or more application entities (AE: Application Entity) or common service entities (CSE: Common Services Entity).

The application entity provides application logic for an end-to-end IoT solution.

The common service entity provides common service functions that can be commonly used by various application entities of the IoT. The common service function includes a data management and storage function, a communication management and delivery processing function, a registration function, a security function, a subscription/notification function, a group management function, and the like.

The subscription and notification function performs a role of notifying when an application entity or a common service entity subscribes to a change of a specific condition for a certain resource and the corresponding resource is changed and the condition is satisfied.

oneM2M follows the Resource Oriented Architecture (RoA). Common service functions are provided through operations on resources. A resource has a tree structure and may be addressed using a unique address (eg, URI). The resource is stored in a common service entity, and the application entity cannot have the resource.

The resource includes various resource types, and each resource type is defined with attributes and child resource types. For example, the application entity resource type includes properties of information (eg, application name, network address, semantic information) related to the application entity, and the container resource type and action transfer to the group are used to store information generated from the application entity. For this purpose, you can have a group resource type as a child resource. These resource types are created in the actual resource through the creation operation, and the service can be used through the operations of modifying, acquiring, deleting, and notifying the resource.

The oneM2M network may additionally include a Non-oneM2M Device Node (NoDN) 109 . An unregistered node is a node that does not have a oneM2M entity such as an application entity or a common service entity, and indicates a node attached to the oneM2M system for interworking purposes including management. The unregistered node 109 may communicate using a protocol other than oneM2M.

2 is a diagram for explaining the function of the proxy 30 in the IoT network 1 according to an embodiment of the present invention.

Referring to FIG. 2 , the IoT network 1 includes an IoT device 10 , an IoT platform 20 , and a proxy 30 .

The IoT device 10 may include a sensor, and transmits data obtained by the sensor according to a specific protocol. The IoT device 10 may correspond to the unregistered node 109 of FIG. 1 .

The IoT platform 20 may be an IoT server that provides an IoT service using data received from the IoT device 10 . The IoT platform 20 may correspond to the infrastructure node 107 of FIG. 1 .

The proxy 30 is a device for interconnecting the IoT device 10 and the IoT platform 20 through protocol mapping and protocol conversion between the IoT device 10 and the IoT platform 20 using different protocols. The proxy 30 may correspond to the intermediate node 105 of FIG. 1 . For example, when the protocol of the IoT device 10 is Modbus and the IoT platform 20 is a oneM2M platform, the proxy 30 uses the Modbus protocol when transmitting and receiving data with the IoT device 10 and Between the IoT platform 20 and the oneM2M protocol, the IoT device 10 and the IoT platform 20 are interconnected.

The interworking method between heterogeneous IoT devices and IoT platforms according to an embodiment of the present invention includes:

generating a mapping table including device ID, resource ID, and protocol information of an unregistered device;

generating a resource of the device based on the mapping table;

generating and transmitting a command for reading device information from the device based on the resource; and

and when device information is received from the device in response to the command, updating the resource to have the device information.

Hereinafter, a specific embodiment of a method of interworking between the heterogeneous IoT device and the IoT platform will be described with reference to FIG. 3 .

3 is a diagram for explaining a method of interworking between the IoT device 10 and the IoT platform 20 in the Internet of Things network 2 according to an embodiment of the present invention.

Referring to FIG. 3 , the IoT network 2 may include an IoT device 10 , an IoT platform 20 , a proxy 30 , a manager device 40 , and an application device 50 . The IoT device 10 , the IoT platform 20 , and the proxy 30 are the same as the IoT device 10 , the IoT platform 20 , and the proxy 30 of the IoT network 1 of FIG. 2 , and thus descriptions will be omitted. .

The manager device 40 is a device for allowing an administrator to access the IoT platform 20 and control functions of the IoT platform 20 , and may correspond to the application-only node 101 of FIG. 1 .

The application device 50 is a device that provides a specific service using data received from the IoT device 10 , and may correspond to the application-only node 101 of FIG. 1 including an application entity. For example, the application device 50 may collect and analyze data received from the plurality of IoT devices 10 to provide statistics or perform a function of controlling an electronic device based on the statistics.

Referring to FIG. 3 , the interworking method between the IoT device 10 and the IoT platform 20 includes the steps of adding the unregistered IoT device 10 ( S110 ), creating a mapping table ( S120 ), and the unregistered IoT device 10 . ) generating a resource (S130), receiving protocol information of the IoT device 10 from the resource of the IoT device 10 (S140), and generating a command for reading device information from the IoT device 10 step (S150), sending a command to the IoT device 10 and receiving device information (S160), updating the resource of the IoT device 10 to include the received device information (S170), application entity It may include a step (S180) of notifying the change of the resource.

First, the unregistered IoT device 10 is added to the proxy 30 by the manager device 40 (S110). Information about the unregistered IoT device 10 may be input to the proxy 30 by the manager device 40 .

Next, the proxy 30 creates a mapping table based on the added information of the unregistered IoT device 10 ( S120 ). When the mapping table has already been created, information on the unregistered IoT device 10 is added, and when there is no mapping table, a new mapping table is created. The mapping table may include an ID of the IoT device 10 , a resource ID of the IoT device, and protocol information of the IoT device.

Next, the proxy 30 creates a resource of the unregistered IoT device 10 based on the mapping table (S130). Accordingly, the IoT device 10 is registered with the IoT platform 20 . The created resource of the IoT device 10 is managed by the IoT platform 20 . The resource has a resource ID stored in the mapping table, and may include at least a portion of protocol information stored in the mapping table.

Next, the proxy 30 receives the protocol information stored in the resource of the IoT device 10 through the IoT platform 20 (S140).

Next, the proxy 30 generates a command for reading the device information from the IoT device 10 by using the protocol information of the resource received in step S140 (S150). Here, the device information may be data sensed by the IoT device 10 . In this case, information on the mapping table generated in step S120 may also be used.

Next, the proxy 30 transmits the command generated in step S150 to the IoT device 10 to receive device information from the IoT device 10 ( S160 ).

Next, the proxy 30 updates the resource of the IoT device 10 by using the device information received in step S160 . In this case, the proxy 30 may update the resource of the IoT device 10 through the IoT platform 20 ( S170 ).

When the resource of the IoT device 10 is updated, the IoT platform 20 notifies an application entity subscribing to the resource of the IoT device 10 of the updated device information (S180).

FIG. 4 is a diagram illustrating an example of the mapping table of FIG. 3 .

Referring to FIG. 4 , the mapping table includes the ID of the IoT device, the resource ID of the IoT device, and protocol information of the IoT device, and may additionally include creation time and availability.

When information of the IoT device 10 is input from the manager device 40 , the proxy 30 generates a mapping table using the information. The resource ID of the IoT device indicates a resource of the IoT device to be created later. The protocol information may include protocol-related information as well as a protocol name used by the IoT device. The protocol information is included in a later resource, and refers to information about a protocol required for the IoT device 10 and the IoT platform 20 to interwork.

5 is a diagram illustrating an example of a resource of the IoT device of FIG. 3 .

In FIG. 5, the IoT platform is the oneM2M platform, and the resource of the IoT device is flexContainer.

A resource has protocol information (nodnProtocol, nodnMappingInfo) as a child resource or attribute.

For example, when the protocol of the IoT device is Modbus, Modbus may be stored in nodnProtocol of the resource of the IoT device, and register file information may be stored in the nodnMappingInfo property.

Next, an example of command generation will be described with reference to FIGS. 6 to 9 .

6 is a diagram showing a Modbus register file.

Referring to FIG. 6 , the Modbus register file includes a register object type (Coil, Discrete Inputs, Holding Registers, Input Register), a function code for specifying a register (Function Code), and a function (Action) of a register corresponding to each function code. ) is indicated.

In order to generate the resource of the IoT device, a resource corresponding to an Interworking Proxy application entity (IPE) is created in the common service entity of the IoT platform 20 . Then, an IoT device connected to and managed by a resource corresponding to the IPE is created as a lower resource, and a sensor of the IoT device is created as a lower resource of the resource corresponding to the IoT device. Protocol type and mapping information may be stored as attribute values in a resource corresponding to a sensor of the IoT device.

7 is a diagram illustrating a resource according to an embodiment of the present invention. Fig. 7 (a) shows a Modbus_IPE resource, Fig. 7 (b) shows a deviceThermometer resource, Fig. 7 (c) shows a battery resource, and Fig. 7 (d) shows a temperature resource.

The Modbus_IPE resource is a resource corresponding to IPE. The deviceThermometer resource is a resource corresponding to the IoT device and is a child resource of the Modbus_IPE resource. The battery resource and temperature resource are resources corresponding to the sensor of the IoT device, and are child resources of the deviceThermometer resource. The battery resource and the temperature resource have properties of register information (nodnproperties) corresponding to protocol type and mapping information. The deviceThermometer resource, battery resource, and temperature resource can be implemented as a flexContainer.

8 is a diagram for explaining the correspondence between resources and a mapping table according to an embodiment of the present invention.

(a) of FIG. 8 shows information (type, Reable, Writable) for each property when the battery resource has properties of level, capacity, charge, discharge, low battery, battery threshold, electrical energy, voltage, and material , (b) of FIG. 7 is a part of the mapping table, and shows Modbus protocol information (Modbus object type, number of necessary registers, address) for each attribute.

The mapping table of FIG. 8B is generated based on the Modbus register file of FIG. 6 . Since the resource ID is stored in the mapping table, protocol information of a mapping table item corresponding to the resource ID may be included when a resource is created. That is, although FIG. 8B shows a part of the mapping table, the same content may be included in the resource as protocol information.

9 is a diagram illustrating a command for reading a battery level generated using the resources of FIGS. 7 and 8 .

Slave ID indicates the ID of the battery. Although not shown in FIG. 7 , the ID of the battery may be stored in the mapping table and the battery resource. Accordingly, the ID of the battery may be obtained from the resource.

The function code is a value corresponding to the Input Register which is the Modbus object type of FIG. 8(b) in the Modbus register file of FIG. 6 . Although it has been described that the function code is generated by referring to the object type stored in the mapping table or resource and the function code corresponding to the object type of the register file, the function code is directly stored in the mapping table or resource, and by directly referencing the stored value may be created.

The required number of registers and addresses can be obtained from a resource as a value stored as protocol information in a mapping table and resource.

A CRC (Cyclical Redundancy Check) is a value added to check a command error.

By sending the thus generated command to the battery, the proxy can receive the battery level value from the battery. Thereafter, the proxy will update the battery level resource with the received value.

10 is a diagram showing the configuration of the IoT network 3 according to an embodiment of the present invention.

Referring to FIG. 10 , the IoT network 3 includes an IoT device 10 , an IoT platform 20 and a proxy 30 , and the proxy 30 includes a device ID and a resource ID of an unregistered device 10 . and a mapping table storage unit 310 storing a mapping table including protocol information; a resource management unit 320 for generating a resource of the device in an IoT platform based on the mapping table; and a device communication unit 330 that generates and transmits a command for reading device information from the device based on the resource, and receives device information from the device in response to the command, wherein the resource management unit 320 ) updates the resource using the device information received from the device communication unit.

As mentioned above, although the present invention has been described in detail through preferred embodiments, the present invention is not limited thereto, and it is common in the art that various changes and applications can be made without departing from the technical spirit of the present invention. self-explanatory to the technician. Accordingly, the true protection scope of the present invention should be construed by the following claims, and all technical ideas within the scope equivalent thereto should be construed as being included in the scope of the present invention.

Claims (15)

A method of interworking a heterogeneous IoT device using a different protocol and an IoT platform using a proxy, the method comprising:
The IoT platform has a resource-based structure (RoA; Resource Oriented Architecture) and stores and manages device information received from the IoT device in a resource,
The method is
generating, by the proxy, a mapping table including a device ID, a resource ID, and protocol information of an unregistered IoT device;
generating, by a proxy, a resource of the device, including the resource ID and the protocol information, based on the mapping table, and registering it with the IoT platform;
receiving, by a proxy, protocol information of the device stored in the resource from the IoT platform by requesting protocol information of the device from the IoT platform;
generating, by the proxy, a command for reading device information from the device based on the received protocol and transmitting the command to the device; and
updating, by the proxy, the resource to have the device information when the device information is received from the device in response to the command;
including,
The protocol information stored in the resource includes a type of protocol of the device and register file information of the protocol of the device. A method of interworking between heterogeneous IoT devices and IoT platforms.
According to claim 1,
Notifying, by the IoT platform, the device information to an application entity subscribing to the resource after the resource is updated
Interworking method of heterogeneous IoT devices and IoT platforms further comprising a.
According to claim 1,
The IoT platform is a method of interworking with a heterogeneous IoT device and an IoT platform, characterized in that the oneM2M platform.
4. The method of claim 3,
The resource is a method of interworking with a heterogeneous IoT device and an IoT platform, characterized in that the flexContainer.
4. The method of claim 3,
The device information is a method of interworking with a heterogeneous IoT device and an IoT platform, characterized in that stored as a child resource or attribute of the resource.
delete According to claim 1,
The protocol of the device is Modbus,
The resource is a method of interworking with a heterogeneous IoT device and an IoT platform, characterized in that it includes register file information of Modbus.
As a proxy for interworking heterogeneous IoT devices and IoT platforms using different protocols,
The IoT platform has a resource-based structure (RoA; Resource Oriented Architecture) and stores and manages device information received from the IoT device in a resource,
The proxy is
a mapping table storage unit storing a mapping table including device ID, resource ID, and protocol information of an unregistered IoT device;
a resource management unit generating and registering the resource of the device, including the resource ID and the protocol information, in the IoT platform based on the mapping table; and
By requesting protocol information of the device from the IoT platform, receiving protocol information of the device stored in the resource from the IoT platform, and generating a command for reading device information from the device based on the received protocol information a device communication unit for transmitting to the device and receiving device information from the device in response to the command;
including,
The resource management unit updates the resource using the device information received from the device communication unit,
The protocol information stored in the resource includes a protocol type of the device and register file information of the protocol of the device, a proxy for interworking between heterogeneous IoT devices and IoT platforms.
9. The method of claim 8,
The IoT platform is a proxy for interworking between heterogeneous IoT devices and IoT platforms, characterized in that the oneM2M platform.
10. The method of claim 9,
The resource is a proxy for interworking between heterogeneous IoT devices and IoT platforms, characterized in that the flexContainer.
11. The method of claim 10,
The device information is a proxy for interworking between heterogeneous IoT devices and IoT platforms, characterized in that stored as a child resource or attribute of the resource.
delete 9. The method of claim 8,
The protocol of the device is Modbus,
The resource is a proxy for interworking between heterogeneous IoT devices and IoT platforms, characterized in that it includes Modbus register file information.
unregistered IoT devices;
an IoT platform that uses a protocol different from the device, has a Resource Oriented Architecture (RoA), and stores and manages device information received from the IoT device in a resource; and
A mapping table storage unit storing a mapping table including device ID, resource ID, and protocol information of the device, and based on the mapping table, the IoT platform includes the resource of the device-the resource ID and the protocol information - a resource management unit that creates and registers, requests protocol information of the device from the IoT platform to receive protocol information of the device stored in the resource from the IoT platform, and based on the received protocol information, from the device and a device communication unit that generates a command for reading device information and transmits it to the device, and receives device information from the device in response to the command, wherein the resource management unit uses the device information received from the device communication unit to update the resource, and the protocol information stored in the resource includes a type of protocol of the device and register file information of the protocol of the device;
A system for interworking of heterogeneous IoT devices and IoT platforms, including
15. The method of claim 14,
The IoT platform is
After the resource is updated with the device information, the system for interworking between heterogeneous IoT devices and IoT platforms, characterized in that the updated device information is notified to an application entity subscribing to the resource.

Images