KR20210090517A - Decoupled IoT Application Store System for Virtual Objects Sharing and Discovery - Google Patents

Abstract

The present invention relates to a technology for designing and implementing a cloud-centric IoT store with an objective of hosting a virtual object of an IoT domain. According to the present invention, by designing and implementing a cloud-based decoupling IoT store, the present invention can provide a major technology for searching and sharing of a virtual object. The method comprises: a generation step; a registration step; a distribution step; a processing step; a searching step; and a selling and renting step.

Description

TECHNICAL FIELD [0002] Decoupled IoT Application Store System for Virtual Objects Sharing and Discovery

The present invention relates to a method and system for creating virtual objects and services, registering them, sharing virtual objects through search, and performing sales.

The Internet of Things (IoT) is a cyber-physical space capable of discovering, inspecting, activating, interconnecting and updating physical objects to realize possible interactions in both virtual and physical space. has grown with the concept of

The basic idea behind the Internet of Things (IoT) is the concept of virtual objects, considered as digital equivalents to physical entities. The use of virtual objects has become an essential component in all IoT platforms today.

These virtual objects form the building blocks of IoT applications, support service discovery, facilitate the production of complex applications, improve energy and power management efficiency of entities, and solve heterogeneity and scalability problems.

Sharing and reuse of ideas allows for widespread dissemination, and for this purpose, different solutions are built to share an application or its components with similar domains to avoid duplication of effort.

The Internet of Things (IoT) is an innovative paradigm that forms technological development in the field of information and communication technology (ICT). The basic concept of this paradigm is that various objects or objects, such as sensors, actuators, RFID tags, and mobile phones, are pervasive around us. Disparate and pervasive entities with different computing and connectivity capabilities are united under a common term called IoT. Although the main goal of IoT is to provide services to users through the Internet, important information and services are strictly linked to the real world that has been provided through physical objects.

IoT applications typically consist of physical entities with limited ability to communicate using various communication protocols. To this end, the concept of virtual objects is introduced. A virtual object (entity) is a digital counterpart of a physical object, and aims to provide a technical solution that augments the functionality of a physical device with additional functions, all objects talking to each other at the same level, facilitating the realization of powerful applications make it possible to do

Virtual objects are recently considered a key component of IoT platforms. IoT applications combine various virtual objects to build services available to end users. Recent advances in cyber-physical systems are redefining our way of life, encouraging the idea of virtual objects and enabling the representation of physical space into cyberspace where all physical things can be interconnected and controlled through the cyber world. cleared the way Technologies such as Quick Response (QR) codes and RFID are already paving the way for digital representations of physical objects.

Historically, despite limited technical knowledge, there has always been a group of communities that search for technical components and integrate them to create products. These people are called makers. The main drivers of these groups are creativity and a sense of accomplishment. Many IoT businesses are complex systems that integrate commercial IoT products with hardware and software. These manufacturers are considered true user innovators of the IoT, driving innovation in new products and prototypes, while at the same time facing integration challenges ahead of the rest of users and developers. The creator's facilitation paradigm is the DIY (Do-it-Yourself) approach. In the DIY paradigm, the focus is on providing visual code components and entities that can be dragged and dropped to form IoT services. Some prominent platforms adopting a DIY approach are Node-RED, SAM Starter Kit, Super Stream Collider, particle.io and dweet.io. Virtual objects on most platforms are dragged and connected to form IoT services. However, most of these platforms are offline, and efforts by one maker cannot be reused by another. Therefore, there is a need for a common space that can be reused in areas similar to IoT applications by sharing the components of the IoT platform.

Korean Patent Publication No. 10-2014-0090503

The present invention has been devised to solve the above problems, and an object of the present invention is to create a virtual object and a service for a physical object that is a physical thing, register it, provide it to the public so that it can be accessed by the public, and perform a search. An object of the present invention is to provide a method and system for sharing and selling virtual objects discovered through

Furthermore, the purpose of designing and implementing a cloud-based decoupling IoT store is to provide a system that can provide a central technology for searching and sharing virtual objects. Furthermore, by exposing data of heterogeneous stores and APIs to ensure headerless operation, it is possible to secure clients that can consume data without going to the store, and IoT test provided for evaluating the efficiency of the proposed store It is to develop a bed client that can import virtual objects and provide a sharable system.

As a means for solving the above problems, in an embodiment of the present invention, as shown in FIGS. 1 to 4 , through the IoT test bed client 500 that shares the virtual object with an external terminal, the virtual object and Creating a service, registering a service, sharing a virtual object through a search, and implementing a method of performing a sale, the method comprising: creating the virtual object in a physical corresponding device in a physical layer (540); registering, in the gateway layer 530 , a virtual object designated by a user in the store 100 in which the virtual object is stored, with the gateway; decomposing a virtual object from the functional decomposition and microservice layer 520, decomposing it in the form of a functional block, and mapping it to form a microservice; processing the service provided by the platform so that the end user can use it in the service layer 510; in the store 100, in response to a search request for a virtual object coming through a user terminal, obtaining and searching a user query for virtual objects; It is possible to provide a method of providing an IoT store for sharing and selling virtual objects, including sharing the searched virtual object and selling or renting the virtual object in the store at the request of the user terminal.

In addition, as a system configuration for implementing the above-described method for providing an IoT store for sharing and selling virtual objects, in an embodiment of the present invention, a user terminal 10 for searching a virtual object through wired/wireless communication; A store 100 that obtains a user query for a virtual object searched by the user terminal 10, posts a SPARQL (Simple Protocol and RDF Query Language)-based query, and returns a search result for a virtual object from user-provided metadata ); In the search request of the store 100 , a search result of a virtual object is provided from user-provided metadata, and a reference of the virtual object stored in a virtual object repository database 300 is provided. Returning semantic database (Semantic database; 200); A plurality of Internet of Things (IoT) domains 400 that share a virtual object with the store 100 in a standard set by the store 100 and enable code reuse of the shared virtual object; including, a virtual object To provide an IoT store system that can be shared and searched.

According to the present invention, virtual objects and services are created for a physical object, which is a physical object, registered and shared so that the general public can access it, and virtual objects found through search can be shared and sold. Thus, it is possible to increase the efficiency of use.

In addition, according to an embodiment of the present invention, by designing and implementing a cloud-based decoupling IoT application store, it is possible to provide a central technology for searching and sharing virtual objects.

Furthermore, by exposing data of heterogeneous application stores and APIs to ensure headerless operation, it is possible to secure a client that can consume data without going to the application store.

Furthermore, by developing an IoT test bed client that is provided for the efficiency evaluation of the proposed application store, virtual objects are imported and shared.

FIG. 1 is a block diagram showing the entire configuration of an IoT store system (hereinafter, referred to as 'the present invention') for sharing and selling virtual objects.
2 is a conceptual diagram illustrating an outline of a store according to the present invention.
3 is a conceptual diagram illustrating a scenario to which the system according to the present invention is applied.
4 is a diagram illustrating an implementation configuration and operating state of an IoT test bed client, which is prepared to evaluate the usefulness of a system proposed as part of the system architecture of the present invention.
Figure 5 illustrates the form of a basic module that can access the resources of the store.
6 shows an example of a postman based test request for granting an authorization code.
7 shows an ontology graph based on the Protege editor.
8 is a diagram illustrating a flow of a virtual object from a functional point of view.
9 illustrates an example of implementing a store utilization scenario according to an embodiment of the present invention described with reference to FIGS. 1 to 4 .
10 presents a snapshot of a program that implements virtual object management of the store. FIG. 11 illustrates a customer management page in the program of FIG. 10 .
12 illustrates roles and permissions for controlling unauthorized access to protected resources in the store. 13 is a diagram illustrating an interface of such a RestClient module.
14 shows the experimental setup of the IoT testbed client. 15 illustrates a client application designed for an IoT testbed client.
16 shows a flowchart of an application in the detailed design of intelligent weather management of a smart home. 17 illustrates a case in which a user requires a virtual object for a fan controller is set.
18 shows a result of displaying a virtual object on a map.

Advantages and features of the present invention, and methods for achieving them, will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be implemented in various different forms.

In the present specification, the present embodiment is provided to complete the disclosure of the present invention, and to fully inform those of ordinary skill in the art to which the present invention pertains to the scope of the present invention. And the invention is only defined by the scope of the claims. Accordingly, in some embodiments, well-known components, well-known operations, and well-known techniques have not been specifically described to avoid obscuring the present invention.

1 is a block diagram of an entire configuration of an IoT store system (hereinafter, referred to as 'the present invention') for sharing and selling virtual objects. 2 is a conceptual diagram illustrating an outline of a store according to the present invention. 3 is a conceptual diagram illustrating a scenario to which the system according to the present invention is applied. 4 is a diagram illustrating an implementation configuration and operation state of an IoT test bed client, which is prepared to evaluate the usefulness of a system proposed as part of the system architecture of the present invention.

1 and 4 , the method implemented by applying the present invention creates, registers, and searches virtual objects and services through the IoT test bed client 500 that shares virtual objects with external terminals. A method of sharing a virtual object and performing a sale is implemented through the step of creating the virtual object in a physical corresponding device in the physical layer 540, and in the gateway layer 530, the store 100 in which the virtual object is stored Registering the virtual object specified by the user in the gateway, functional decomposition and receiving the virtual object from the microservice layer 520, decomposing it in the form of a functional block, and mapping it to form a microservice, the service layer ( In step 510, processing the service provided by the platform so that the end user can use it, in the store 100, with respect to a search request of a virtual object coming through a user terminal, a user query for virtual objects (user) A method for providing an Internet of Things store for sharing and selling virtual objects, comprising the steps of obtaining and searching a query), sharing the searched virtual object, and selling or renting the virtual object in the store at the request of a user terminal. can be implemented.

In particular, in this case, performing a search for the search request for the virtual object may include, in the application layer 110 , a user query for virtual objects with respect to a search request for a virtual object coming through the user terminal. (user query) and, in the OWL processor module 120, create a SPARQL-based post-job using the user query, identification reference and data passed to the application layer 110 to store metadata and references in a semantic database , parses the search request in the MySQL adapter module 130, maintains the virtual object, returns unique identification information of the newly added virtual object, and in the MySQL adapter module 130 It can be implemented as a process of processing a request to search or share a virtual object based on the received information.

1 to 4, the configuration of the present invention for performing the above-described process will be described.

1, the present invention obtains a user terminal 10 for searching a virtual object through wired/wireless communication, a user query for a virtual object searched for by the user terminal 10, and SPARQL A store 100 that posts a (Simple Protocol and RDF Query Language)-based query and returns a search result for a virtual object from user-provided metadata, and a virtual object from user-provided metadata to a search request of the store 100 A semantic database 200, which returns a reference of the virtual object stored in the virtual object repository database 300, and the store 100 A plurality of Internet of Things (IoT) domains 400 that share a virtual object in the store 100 in a set standard and enable code reuse of the shared virtual object, and the store through RESTful web services It may be configured to include an IoT test bed client 500 that communicates with 100 , discovers a virtual object in the store 100 , and shares the virtual object with an external terminal.

In addition, as shown in FIG. 1 , the store 100 is an application layer that obtains a user query for virtual objects in response to a search request for virtual objects coming through the user terminal. 110, an OWL handler module 120 that creates a SPARQL-based post-job using the user query, identifying reference and data passed to the application layer 110 to publish metadata and references to a semantic database, search request Based on the information received from the MySQL adapter module 130, MySQL adapter module 130, which performs parsed for, maintains a virtual object, and returns unique identification information of a newly added virtual object. It may be configured to include a rest client module 140 that processes a request for virtual object search or sharing.

In addition, in the configuration shown in FIG. 1 , the plurality of IoT domains 400 share a virtual object provided by the application store 100 , but a virtual object buffer module for temporarily storing the provided virtual object ( 410), a meta descriptor module that extracts metadata information from a virtual object transmitted from the virtual object buffer module 410 and processes a request for virtual object sharing using the RestClient module 140 (meta descriptor module 420) ) may be further included.

In addition, referring to FIG. 4 , the test bed client 500 in the present invention as described above receives a service layer 510 that processes services provided by the platform so that end users can use it, and a virtual object to receive a functional block. Function decomposition and microservice layer 520 to form microservices by decomposing it in the form of , a gateway layer 530 for registering virtual objects designated by a user stored in the store 100 to the gateway, and physical correspondence It may be configured to include a physical layer 540 that handles distribution of the virtual object to a device.

In this case, the decomposition and microservice layer 520 communicates with the API exposed by the store 100, and a virtual object search layer ( 531) and the store 100 and communicates with the API exposed by the store 100, and may include a sharing layer that stores a virtual object customized to use the open source maker community in the store 100.

In addition, the test bed client 500 includes a service layer 510 that processes services provided by the platform so that end users can use it; Create a function corresponding to a virtual object as a task (e.g. temperature measurement task, humidity measurement task), map these tasks and virtual objects to include a function in the virtual object (e.g. by combining temperature and/or humidity a microservice layer 520 that forms and provides (determining whether freezing); a gateway layer (530) for registering virtual objects and microservices designated by a user stored in the store (100) with a gateway and supporting distribution to a corresponding physical device; It may include a physical layer 540 for distributing and processing the microservice of the virtual object to a physical counterpart device.

The present invention can implement a method of creating and registering virtual objects and services through an Internet of Things test bed client that shares virtual objects with external terminals, sharing virtual objects through search, and performing sales through stores. have. Hereinafter, various utilization and application methods for the configuration of the present invention will be described, and the store utilization of the present invention will be described.

One. Store usage scenario

(One) Virtual object search

The first embodiment for explaining the utilization of the present invention is a virtual object (virtual object) required by an IoT technology user (user) 10 who integrates different objects to build an IoT service in an application store (100). objects) can be used.

Specifically, in this case, the application layer 110 of the store 100 takes a user query for virtual objects. The user query includes a meta description of the virtual object.

The application layer 110 transmits the received information to the OWL processor module, and the OWL processor module 120 publishes a simple protocol and RDF Query Language (SPARQL)-based query, and the user of the semantic database 200 Retrieves the virtual object from the provided metadata.

When the virtual object is found, the semantic database 200 returns a reference of the virtual object stored in the virtual object repository database 300 .

MySQL adapter module 130 uses the returned reference of the virtual object to retrieve the virtual object, and in case the user requests a headless response, the application layer 110 or It is transmitted to the Rest Client module 140 .

These operations are indicated by numbering the operation sequence as 1, 2, 3, and 4 in FIG. 3 .

(2) Virtual object sharing

A second scenario for utilizing the present invention is to share virtual objects.

In a standard conforming to the store 100 , different IoT domains 400 share a virtual object. In this case, the virtual object buffer 410 temporarily stores the virtual object and then transmits it to the meta descriptor module 420 . The meta descriptor module 420 extracts meta data information from the virtual object and processes the request using the RestClient module 140 .

In the above request processing process, first, an equivalent SQL query is generated by the MySQL adapter module 130 that parses the request, maintains the virtual object and returns unique identification information of the newly added virtual object. . The OWL processor module 120 creates a SPARQL-based post-job using the identifying reference and data to publish the metadata and the reference to a semantic database 200 . The operation sequence of the second scenario is indicated by sequence numbers as A, B, C, and D in FIG. 3 .

(3) Usability evaluation_test bed

4 is a diagram illustrating an implementation configuration and operation state of an IoT test bed client, which is prepared to evaluate the usefulness of a system proposed as part of the system architecture of the present invention.

4, the present invention communicates with the store 100 through RESTful web services, discovers a virtual object in the store 100, and shares the virtual object with an external terminal. To be configured to further include the IoT test bed client (500).

That is, the present invention can implement the IoT Testbed Client to evaluate the usefulness of the proposed system as part of the system architecture.

The test bed of the IoT test bed client 500 discovers virtual objects in the store 100 of the present invention and enables sharing of specialized virtual objects for open source IoT users.

The test bed of the IoT test bed client 500 communicates with the store 100 using a RESTful web service.

The test bed of the IoT test bed client 500 is defined as a layered architecture as shown in FIG. 4 , and the layers for each role are different.

The test bed client 500 receives the service layer 510 that processes the service provided by the platform so that the end user can use it, and decomposes the virtual object into the form of a functional block, and maps it to form a microservice. Function decomposition and microservice layer 520, gateway layer 530 for registering virtual objects designated by a user stored in the store 100 to a gateway, and physical layer 540 for handling distribution of the virtual objects to a corresponding physical device ) may be included.

In particular, in this case, the decomposition and microservice layer 520 communicates with the API exposed by the store 100 , and searches for and retrieves virtual objects according to the requirements of the store 100 . A layer 531 and a shared layer 532 that communicates with the API exposed by the store 100 and stores a virtual object customized for use in the open source maker community in the store 100 may be configured. have.

More specifically, as shown in FIG. 4 , in the test bed of the IoT test bed client 500 , a service layer 510 that processes services provided by the platform is arranged so that the top layer can be used by end users. do.

The next layer is the functional decomposition and microservices layer 520 .

The functional decomposition and microservice layer 520 receives a virtual object, decomposes it in the form of a functional block, maps it, and forms a microservice, and the result is also called a composite virtual object. Next, a virtual object search and sharing layer 530 is disposed below the functional decomposition and microservice layer 520 .

The virtual object search and sharing layer 530 has two lower layers, both of which communicate with the API exposed by the store.

That is, the virtual object search layer 531 , which is one of the lower layers of the virtual object search and sharing layer 530 , performs a function of finding and searching virtual objects according to the requirements of the store 100 .

In addition, the other lower layer, the sharing layer 532, shares virtual objects customized for use with the open source maker community to the store. Each virtual object is registered in the gateway 541 which is a task of the gateway layer 540 . Virtual objects are registered and mapped to real physical hardware.

The last layer is the physical layer 550 that handles the distribution of virtual objects to the physical counterpart device 551 .

The above-described embodiment of the present invention is a technical premise for standardizing virtual objects in IoT applications, and virtual objects must have unique representations (IDs), and objects (properties) and objects (object (methods)) data should be explained. In some cases, an object may have an executable that is the skeleton code for how to use the object data to simulate the behavior of a virtual object.

The present invention provides an embodiment of a decoupling store that provides a cloud-centric location of a virtual object based on such a technology.

These virtual objects can be found in the store of the system according to the present invention and can be used in a variety of similar IoT applications. In addition, other IoT domains may also share virtual objects to be discovered and consumed by other applications.

The store in the present invention may have loosely coupled IoT application configurations that can be combined to build IoT applications. For example, software implementing the present invention should be modular in structure, components within the same module should have high relevance, and elements between different modules should have little relevance. This is called aggregation and bonding. Sound software should have high cohesion and low cohesion. That is, modules have high relevance and have the lowest possible dependencies on other modules. The system design proposed according to the present invention makes it possible to provide modularity with high cohesion and low coupling using structural patterns.

The architecture of the store of the present invention is a separate and headless structure (headless). The term "headless" in the present invention refers to a function serving as a data source without a user interface. The application programming interface is exposed to client applications that can be used to obtain these resources using various client software such as Android applications and web applications.

Accordingly, according to the present invention, it is possible to design and implement a cloud-based decoupling IoT store to provide a central technology for searching and sharing virtual objects.

Furthermore, by exposing data of heterogeneous stores and APIs, it is possible to secure a client that can consume data without going to the store by guaranteeing a headless operation. Furthermore, an IoT testbed client is developed to evaluate the efficiency of the proposed store to bring and share virtual objects.

2. Features of the store configuration according to the present invention

Hereinafter, the features of the store in the present invention will be described for each function.

(One) decoupling

In the present invention, as described above, one of the core motivations of the application program store (store) is to have a decoupling characteristic of the module.

That is, decoupling, which means the separation characteristic of a module, means that the virtual object of the store in the present invention has a dependency that does not depend on the IoT platform and service. These objects are independent and can be consumed by any application.

It is regarded as one of the preliminary requirements of the system as the main motivation for this work.

A variety of systems exist that provide a complete IoT solution, including hardware, software, and user guidance on how to operate the system. In contrast to these systems, the target customers of the system proposed in the present invention are technical annotators and manufacturers who like to engage with technology and customize their applications to adapt to the business needs of the domain. Decoupling considerations allow IoT domains to use some virtual IoT resources as blocks and work with these blocks to develop custom IoT services that fit well with domain requirements.

(2) Modularity

An important design challenge in software engineering is to have a modular system with high cohesion and low coupling. The system proposed in the present invention is modular, each module has a defined function, and the cohesion is high. For example, Restful Web Services is utilized for Hypertext Application Language (HAL) and RESTful Web Services. Similarly, we use the OAuth2 module for authorization. The important modules of the system are summarized in the table below.

[Table 1] Overview of various modules used in the store of the present invention

(3) Headless Support

The term "headless" is often used when an application works without a graphical user interface. The demand for the headless nature of systems is increasing due to the vast number of mobile devices and smart things. If a software system can act as a data center for a ubiquitous array, it can be said to have headless support. These applications acting as consumers may be either mobile applications, web applications, or hybrid applications.

The system proposed in the present invention is implemented in a structure capable of headless support in that different IoT domains acting as consumers and providers can interact with the system without using a graphical user interface. Furthermore, the data is exposed using RESTful web services. Furthermore, an authenticated user may reach a specific endpoint exposed by the system and provide an IoT object.

(4) Support for stable web services

If the system needs to be used without a graphical interface, since the data has to be exposed to other software, the system proposed in the present invention uses an anti-serialization web service to consume and provide the data. Given the popularity of RESTful services, it can be said to be a de facto standard for IoT applications. The present invention supports HAL, RESTful web service, and serialization module that provide secure and complete data transmission between different IoT domains through RESTful service. The serialization module is used for the JSON or XML payload of the request. Similarly, the HAL module is used to provision hypermedia objects such as external resources and links within JSON or XML payloads.

(5) Authentication and Role Management

The system proposed in the present invention provides a role management function that a user can associate with a specific role. Additionally, a set of privileges has been assigned for every role.

For example, the "Virtual Object (VO) Consumer" role can only use read data, cannot use write data, and the "VO Provider" role has also been granted write permission.

Roles and permissions enable verification and validation of tasks and tasks that users can perform. Similarly, it is implemented with a structure in which all users must be authenticated before using the system. The system allowed anonymous users to register. Once you have an account on the system, you can authenticate with the credentials provided during registration. Table 1 provides a small snapshot of some permission strings and assigned roles for their physical counterparts.

(6) Authorization

While authentication is useful for identifying a user or device, the ability to know whether an authenticated user can access a particular resource is used. For example, a user with the IoT Consumer role cannot delete virtual objects from the system, but conversely, users associated with the Admin role can delete it.

In addition to the simple authentication system, the embodiment of the present invention uses an OAuth server that adds another layer of security and aids in device and machine authentication. Authorization for a headless system is paramount in that an external user or machine must have a valid token to publish anything to the system.

(7) Analysis support

One of the fundamental considerations in any application design is to enable context awareness and user preferences so that only relevant content is visible to a specific set of users. For example, users belonging to the smart home IoT domain are only interested in resources that can be integrated into a smart home scenario.

Likewise, users using the smart farm case will want to have a list of virtual objects associated with the mentioned domain. Therefore, the proposed system according to the present invention uses an analysis module to learn and reflect user preferences over time.

3. Example description of the system progress configuration according to the present invention

Hereinafter, a main process of applying the IoT store system capable of sharing and searching virtual objects according to the present invention will be described. The overall process is described based on the scenario described earlier in FIG. 3 .

(1) registered user (User Registration)

User registration is the basic module that allows application users to access resources in the store. Users can be enrolled in the roles of Consumer, Provider and can choose both. When registering information such as IoT domain, time zone and email address are received. The administrator receives and approves the registration request, and new users are notified by e-mail. A sample web form is shown in FIG. 5 .

(2) Client Registration

The virtual object of the store of the present invention should be protected from unauthorized access. For this, the OAuth2 module can be used to enable effective authorization. One requirement in the OAuth2 system is to register all clients that tend to interact with the system. A client is an application that wants to access a user account on the system, and upon registration, the client is associated with a role and user on the system. The difference between a user and a client is that a client can be a machine, an IoT gateway, or a smart device. There are customers who do not need users, and there are customers who upload content autonomously without user intervention. When a client registers with the system, it is assigned a client unique user ID (UUID) and secret code that can be used as required parameters in the OAuth access token authorization request.

(3) Authorization Code Grant

Registered clients can receive an access code from an authorization server that grants them access to protected resources in the store. The client makes a request to the authorization server using the OAuth2 protocol by providing parameters such as the client UUID, secret, authorization server URL, access token URL, and callback URL.

The access token URL is where the token is posted, and the authorization server URL is the address of the authorization server that identifies and validates the client. A sample postman based test request using the provided UUID and secret is as shown in FIG. 6 . Once the form is submitted, which can be provided in REST's POST request header, and an access code is given, the system validates the access token and grants the request to the protected resource.

(4) presentation of virtual objects

Once the client is authorized and granted an access token, it can access the protected resource and add new resources to the application repository. The store's support for headerless access allows clients to share virtual objects in the store without having to visit the store.

Clients can utilize RESTful APIs to publish virtual objects to the store.

The rest of the request must be wrapped in a HAL to allow for hypermedia and embedded objects. A virtual object's standard payload is based on the virtual object's parameters. The JSON format of a system-compliant virtual object is shown below.

The payload forms the body of the POST request, the access token is provided in the header, otherwise the request is not authorized.

(5) Semantic Knowledge-Based Discovery

In the present invention, a semantic approach for storing and conceptualizing a description of a virtual object and a relationship with another object is used. The information model is based on the OWL ontology and enables search using SPARQL, a standard query language for querying and exploring the search graph. IoT applications should be meaningfully modeled in terms of an ontology that defines a common knowledge base in a specific IoT area. Because IoT applications deal with heterogeneous physical devices, some of the preliminary requirements for IoT applications mentioned in the initial design of IoT systems are interoperability and support of various platforms.

Therefore, the semantic representation of information is of paramount importance in the IoT domain because of the inherent comfort of interoperability. The semantic expression also makes it easy to search for IoT applications because of the uniformity of the document structure. The prototype editor is used to visualize the ontology, and the Apache Jena API is used to interact with the store. An ontology graph based on the Protege editor is shown in FIG. 7 .

As shown in FIG. 7 , OWL [owl:Virtual Obects, owl:Permission, owl:Platform] and others are defined along with their property relationships and domains. In semantic modeling of knowledge, certain known facts are passively constructed, also called asserted facts. On the other hand, some facts are inferred using asserted facts. For example, the following facts:

Ontology reasoning is performed by a reasoner. For this purpose, we use Fact+, a 'protege built-in reasoner', to infer knowledge based on asserted facts. Also, examples (also called 'individuals') are made for each class shown in the box with pink diamonds. Dotted arrows denote relationships, while solid arrows denote denote is-a relationships.

For example, the yellow dotted line between OWL is: "owl:VirtualObject and owl:Operations" represents the " performs " relationship. Every virtual object has several data properties, such as a unique ID, location, and timestamp, that are created or updated. The unique ID is also stored in the MySQL database, so when it is received by SPARQL, the same ID is also used when returning the actual virtual object from the database.

8 shows the flow of a virtual object from a functional point of view.

The IoT testbed client described above in FIG. 4 of the present invention connects to the store and requests a virtual object using the parameter set provided in the query string. The GET request is parsed by the RestClient module in the application repository and parsed in SPARQL format. The SPARQL query is executed by the SPARQL engine, and if the information matches a virtual object, the corresponding node ID is returned. After that, RestClient formats the request according to the node ID, redirects it to the MySQL adapter, and returns the virtual object in JSON format as shown.

9 illustrates an example of implementing a store utilization scenario according to an embodiment of the present invention described with reference to FIGS. 1 to 4 .

As described above, two scenarios in which the store according to the present invention can be used can be provided. The first scenario is resource search, and the second scenario is to share resources as shown in (a) and (b) of FIG. 9 . In both cases, the interaction is from the IoT testbed client to the store.

In the first scenario, the client application, which is an IoT test bed, aims to discover virtual objects for IoT resources registered in the gateway. This means that first the metadata of the registered resource is parsed to form a search request. A request for such resource search is made to the application layer in the form of a RESTful web service. The request is then placed as a GET request along with the metadata of the registered resource. Metadata can be supported protocols, platforms, and resource types. As part of the application layer, authorization and authentication, you will receive a location CSRF token as a request from the authentication server to evade request forgery attacks.

It also authorizes the request by adding an authentication token, which is a license to access the store. The request now has a CSRF and an authentication token in addition to the metadata. The OWL handler processes the request and forms a SPARQL query based on the metadata of the search request. If a virtual object matching the request payload is found, the node ID is returned in response to the MySQL adapter. Also, the SQL query for the node ID is made into a virtual repository, and the virtual object is returned to the search manager. The search manager decomposes virtual objects into functional blocks used to model microservices, and these microservices are deployed in the form of commands to real physical resources.

The second scenario for virtual object sharing in Fig. 9 is to obtain an access token, register a client computer in the store, and then publish it. In this case, the client application controls the IoT resource through some virtual object rather than in a store-compatible format. Also, before sharing a virtual object, a client must be registered with the store.

RestClient registers a client by sending a request to the Client Manager and connecting the UUID, UUID, and the secret for the client. The same information is also stored on the authorization server for the client ID so that the application store recognizes the same client as the authorized client for future requests.

Also, the same credentials are provided to the client application. The client forms a POST request for an access token to the authorization server, specifying the UUID and secret. The authorization server identifies the client, validates it, and returns an access code in response. The client uses the access code in the header of the POST request and the JSON representation of the virtual object in the payload.

If the request is validated and complies with the HAL requirements of the application repository, it is converted into a SQL query by the MySQL adapter and inserted as a node in the virtual object repository. If the insert operation is successful, the node ID of the newly inserted node is returned to the RestClient and passed along with the request to the OWL handler. The OWL processor creates a SPARQL query, and semantic information is stored in a semantic database (DB). A response code of 200 indicating success is returned to the share manager indicating that the virtual object was successfully shared from the application repository.

10 presents a snapshot of a program that implements virtual object management of the store.

The attributes of a virtual object can be title, model, virtual object type, data, method, and supported protocol. These virtual objects can be exported and used by other IoT applications in JSON and XML format. In addition to virtual objects, executable objects can also provide a way to deploy virtual objects on real physical hardware.

Fig. 11 shows a customer management page in the program of Fig. 10, which provides the client with information of a specific UUID, label, range and, optionally, a callback URL. In addition to these characteristics, a scope can also be defined to associate a client with a specific role, for example in FIG. 11 where one client has the app_consumer role and three of them have an app (provider role).

These clients are users or IoT gateways that interact with the store, sharing and obtaining virtual objects. Therefore, identification is of paramount importance to avoid malicious attacks and unauthorized access. The roles and permissions for controlling unauthorized access to protected resources in the store are shown in FIG. 12 .

As shown in Fig. 12 (a), the role management module lists all roles added to the system, and the administrator can add, edit, and delete roles. There are app provider and app consumer roles that are specific to virtual object sharing and retrieval, respectively. A user or client can have multiple roles. For example, an application user may be interested in retrieving some virtual objects from the application store, but at the same time, a customized virtual object may also be shared from the application store. In this case, both the App Consumer role and the App Provider role are assigned. The permission strings for each role are illustrated in Figure 12(b), which shows the corresponding implementation of the permissions and roles summarized in Table 3.

[Table 3] Snapshot of permission management and role management of the store

When a request is made for a virtual object, the nature of the request is first examined by the HTTP base module. If the request is in PUT, DELETE and POST, it is possible to modify the system. So, I checked the client ID to find the relevant role. Associated roles help find a list of a user's permissions, so access to that request is controlled accordingly. For example, if there was a DELETE request for a virtual object and the client ID determines that the relevant role is an app consumer that does not have permission to delete the virtual object, the result is that the request is denied. This makes the store robust and secure from unauthorized access, an important design aspect of IoT applications.

We also implemented a RESTClient module to enable RESTful API calls to the store, for decoupling and headless access to the store. 13 is a diagram illustrating an interface of such a RestClient module.

The entity that the application's endpoint is exposed to is a virtual object, and the methods are GET, POST, DELETE, and patch. The request format can be one of hal_json, JSON and XML, and authorization is based on the oAuth2 library.

[Use Case for Virtual Object Sharing and Discovery: Internet of Things (IoT) Test Client]

As described above in FIG. 4 , the IoT testbed client may evaluate the functional operation and usefulness of the proposed store when creating an IoT application. The testbed client can discover some virtual objects in the store and handle sharing operations on those virtual objects.

[Table 4] Testbed client composed of various IoT devices and gateways in the store environment

The main purpose of the testbed client in the present invention is to use different IoT technologies, heterogeneous devices, and IoT platforms to find store interoperability.

Accordingly, CoAP, HTTP, and MQTT described in Table 4 are one of the communication protocols commonly used in IoT applications, and in the embodiment of the present invention, each of the servers is installed to utilize these three protocols.

For HTTP, you can use a Python-based Flask server that listens for HTTP requests. Similarly, in the present invention, MQ can be listened to using a Node.js server.

TT request to CoAP request and CoAP server. This resource connects to various IoT gateways that share wireless Internet access. Various small IoT applications were developed and built on a testbed client. These applications included functions such as temperature monitoring, fan control, remote traffic control, and remote lighting control. Virtual objects used by applications are shared in the application repository. The experimental setup of the IoT test bed client based on Table 4 is shown in FIG. 14 .

In this experimental setup, multiple gateways and devices were connected to form an IoT application mashup. For example, we implemented a simple IoT application using a gas sensor that takes a snapshot when gas is detected for indoor monitoring to prevent fire hazards. MQTT was used as a communication protocol and a virtual object of the camera, and the gas sensor was shared with the store. A web-based application has been developed that can handle these virtual objects and share them in the store using a RESTful API. 15 shows a client application designed for the IoT test bed client, thereby managing virtual objects and services used in the IoT test bed client. The implementation techniques of the client application are summarized in Table 5.

[Table 5]

The basic interface of the client application is shown in FIG. 15 . The virtual objects used by the application were managed by the client application. Every virtual object had two action buttons, one for sharing the virtual object with the application repository and the other for breaking the virtual object into functional blocks. Clicking the share button triggers an API request, which first authorizes the client for a UUID and secret. Once the client is approved and an access token is granted, subsequent requests publish it to the store by converting the virtual object to JSON and sending the access token in the header of the request. The RestClient receives the request, stores it in an application store compatible format, and stores it in the store.

Hereinafter, an example in which the IoT store system capable of sharing and searching virtual objects according to the present invention is applied will be described with reference to the drawings.

In this application case experiment, the detailed design of smart home intelligent weather management was implemented.

First, the application utilizes the proposed store to retrieve virtual objects of temperature and humidity sensors. It also uses a fan motor as the control actuator. A flowchart of the application is shown in FIG. 16 . First, the device profile is investigated in the specification document and the virtual object is searched for based on the desired characteristics. When a virtual object is discovered, it is received by the IoT testbed client. The virtual object is then configured to reflect application-specific changes (i.e. URI changes) and stored in the database. Virtual objects are later decomposed into functional blocks. Then use DIY techniques to drag and drop blocks to build microservices. In the present invention, jsPlumb, a Javascript library, has been used to activate the drag-and-drop operation in the browser. A microservice is an operation performed by a physical one. In a virtual domain, a microservice consists of a virtual object or virtual object and one or more operations.

Users who want to discover virtual objects start by adding them to the client system. The virtual object search interface has an option to search for virtual objects in the store, taking into account that the user is already connected and authorized. If the virtual object satisfies the device profile meta information provided by the user, the interface is pre-populated, and the virtual object is discovered using the RESTful GET method. The discovered virtual object was added after some application-specific modifications.

In the virtual object list interface, all virtual objects added to the database are listed as shown in FIG. 15 . For each virtual object, the Actions column breaks it down into function blocks and provides a few buttons to share application-specific functions in the application repository as well. In FIG. 17 , a case in which a user requires a virtual object for a fan controller has been set. First, he connects with the store and provides meta information. This includes tags, data attributes, descriptions, and actions or methods that an entity can potentially perform. In the second step, the virtual object is retrieved and stored in the indicated database.

The virtual objects listing page allows you to perform two operations on individual virtual objects: share to the application repository and decompose into functional blocks. In this case, when a decompose action is triggered, the application provides an interface that provides a space in which virtual objects are expressed as functional blocks to the manufacturer.

A function block is an operation that a virtual object can potentially perform. For example, for fan control, operations such as turn-fan, turn-clockwise, turn-atlantic lock are listed. These tasks are connected by dragging lines from the virtual object to the task and dropping it into the task block. Once the drag-and-drop is complete, the configuration remains in microsober format. On the next screen, the microservices are listed along with action buttons to deploy to that physical object. When the button is clicked, the fan control starts performing the specified action. As a result, manufacturers save a lot of effort by writing code to add, configure, and connect virtual objects. You can follow the same steps to retrieve a sensor virtual object and deploy it as a microservice to a specified temperature sensor. Microservices are conditionally deployed to provide simple weather control services. For example, if a temperature sensor is deployed and the sensed value is greater than some threshold, only a turn-fan microservice is deployed.

According to the IoT store system capable of sharing and searching virtual objects according to the present invention, it is possible to provide a central technology for searching and sharing virtual objects by designing and implementing a cloud-based decoupling IoT store. . Furthermore, by exposing data of heterogeneous stores and APIs, it is possible to secure a client that can consume data without going to the store by guaranteeing a headless operation. Furthermore, an IoT testbed client is developed to evaluate the efficiency of the proposed store to bring and share virtual objects.

In addition, the functional configuration and execution operation applied to the IoT store system capable of sharing and searching virtual objects according to the present invention may be represented by functional block configurations and various processing steps. These functional blocks may be implemented in any number of hardware and/or software configurations that perform specific functions. For example, the present invention provides integrated circuit configurations, such as memory, processing, logic, look-up table, etc., capable of executing various functions by means of the control of one or more microprocessors or other control devices. can be hired

Similar to how components of the present invention may be implemented as software programming or software elements, the present invention includes various algorithms implemented as data structures, processes, routines, or combinations of other programming constructs, including C, C++ , Java, assembler, etc. may be implemented in a programming or scripting language. Functional aspects may be implemented in an algorithm running on one or more processors. In addition, the present invention may employ conventional techniques for electronic configuration, signal processing, and/or data processing, and the like. Terms such as “module”, “part”, “mechanism”, “element”, “means”, and “configuration” may be used broadly and are not limited to mechanical and physical components. The term may include the meaning of a series of routines of software in association with a processor or the like.

Claims (7)

Implement a method of creating and registering virtual objects and services through the Internet of Things test bed client 500 that shares virtual objects with external terminals, sharing virtual objects through search, and performing sales,
creating the virtual object in a physical corresponding device in a physical layer (540);
registering, in the gateway layer 530 , a virtual object designated by a user in the store 100 in which the virtual object is stored, with the gateway;
decomposing a virtual object from the functional decomposition and microservice layer 520, decomposing it in the form of a functional block, and mapping it to form a microservice;
processing the service provided by the platform so that the end user can use it in the service layer 510;
in the store 100, with respect to a search request for a virtual object coming through a user terminal, obtaining and searching a user query for virtual objects;
Including; sharing the searched virtual object and selling or renting the virtual object in the store at the request of the user terminal.
A method of providing an IoT store for sharing and selling virtual objects.
The method according to claim 1,
To perform a search for a search request for the virtual object,
In the application layer 110, for a search request of a virtual object coming through the user terminal, obtain a user query (user query) for the virtual object (virtual objects),
in the OWL handler module 120, using the user query, identifying reference and data passed to the application layer 110 to create a SPARQL-based post-job to publish metadata and references to a semantic database;
The MySQL adapter module 130 parses the search request, maintains the virtual object, and returns unique identification information of the newly added virtual object,
Processing a request for virtual object search or sharing based on the information, received from the MySQL adapter module 130,
A method of providing an IoT store for sharing and selling virtual objects.
a user terminal 10 for searching for a virtual object through wired/wireless communication;
A store 100 that obtains a user query for a virtual object searched by the user terminal 10, posts a SPARQL (Simple Protocol and RDF Query Language)-based query, and returns a search result for a virtual object from user-provided metadata );
In the search request of the store 100 , a search result of a virtual object is provided from user-provided metadata, and a reference of the virtual object stored in a virtual object repository database 300 is provided. Returning semantic database (Semantic database; 200);
A plurality of Internet of Things (IoT) domains 400 that share a virtual object with the store 100 in a standard set by the store 100 and enable code reuse of the shared virtual object;
Internet of Things test bed client 500 that communicates with the store 100 through RESTful web services, discovers a virtual object in the store 100, and shares the virtual object with an external terminal; includes; doing,
Internet of Things store system for sharing and selling virtual objects.
4. The method according to claim 3,
The store 100,
an application layer 110 for obtaining a user query for virtual objects in response to a virtual object search request coming through the user terminal;
An OWL handler module 120 that creates a SPARQL-based post-job using the user query, identifying reference and data passed to the application layer 110 to publish metadata and references to a semantic database.
a MySQL adapter module 130 that parses a search request, maintains a virtual object, and returns unique identification information of a newly added virtual object;
Rest client module 140 for processing a request for virtual object search or sharing based on the information, received from the MySQL adapter module 130; including;
Internet of Things store system for sharing and selling virtual objects.
The method according to claim 4,
The plurality of IoT domains 400 share a virtual object provided by the store 100,
a virtual object buffer module 410 for temporarily storing the provided virtual object;
A meta descriptor module 420 that extracts metadata information from the virtual object transmitted from the virtual object buffer module 410 and processes a request for virtual object sharing using the RestClient module 140; more containing,
Internet of Things store system for sharing and selling virtual objects.
6. The method of claim 5,
The test bed client 500,
a service layer 510 that processes services provided by the platform so that end users can use it;
a microservice layer 520 that creates a function corresponding to a virtual object as a task, maps these tasks and the virtual object, and forms and provides a microservice including a function in the virtual object;
a gateway layer 530 for registering virtual objects and microservices designated by a user stored in the store 100 to a gateway and supporting distribution to a corresponding physical device;
A physical layer (540) for distributing and processing microservices of the virtual object to a physical counterpart device;
Internet of Things store system for sharing and selling virtual objects.
7. The method of claim 6,
The microservice layer 520 including the function of the virtual object,
a virtual object search layer 531 that communicates with the API exposed by the store 100 and searches for and searches virtual objects according to the requirements of the store 100; and
A sharing layer that communicates with the API exposed by the store 100 and stores a virtual object customized for use in the open source maker community in the store 100;
Internet of Things store system for sharing and selling virtual objects.

Images