KR20190130220A - IoT network system - Google Patents

Abstract

The present invention relates to an IoT network system. The IoT network system comprises: a physical layer (110); a virtual object layer (VOL) (120); a service composition layer (SCL) (130); and a business process layer (BPL) (140). Accordingly, the present invention provides an effect that a user may easily construct an IoT network infrastructure.

Description

IoT network system

The present invention relates to an IoT network system, and more particularly, to an IoT network network system for providing visual implementation information of an IoT network type for implementing an IoT network image.

Recently, with the rapid development of information and communication technology, interest and demand for the Internet of Things (IoT) technology is rapidly increasing. Such IoT can be defined in various ways, depending on the point of view of it. However, it is clear that IoT is essentially an intelligent information communication technology or service that enables communication between people and things, things and things by providing a network connection to various things based on the Internet.

Despite the rapid growth in the field of IoT technology, security technology in the IoT environment is still in its infancy. In particular, home IoT systems require general users to participate in security management. Moreover, home wireless networks are recognized as security vulnerable because it is very difficult for general users to recognize external attacks due to the wireless environment. Indeed, the UK's Internet media Telegraph, citing HP's report, found that 90% of the IoT devices currently in use collect personal information, 70% of which is transmitted unencrypted. Sixty percent of devices use an unsecured interface, saying that current IoT devices have about 250 potential security vulnerabilities. ProofPoint also reported that 750,000 phishing and spam emails were sent through smart appliances from late 2013 to early 2014. Therefore, there is an urgent need for security technology for an indoor wireless network of an indoor IoT system.

Meanwhile, studies related to wireless LAN or Wi-Fi security technology mainly focus on user authentication and encryption in wireless communication between home IoT devices and the access point (AP) in the home, and as a Wi-Fi security standard, WEP (Wired Equivalent Privacy (WPA), Wi-Fi Protected Access (WPA), and WPA2 are commercially available.

The Internet of Things (IoT network) relates to a service infrastructure for providing advanced services by connecting various things in the physical world and the virtual world based on information and communication technology.

In order to design such an IoT network, infrastructure computing devices for realizing a ubiquitous space are planted in an environment and an object, and an intelligent communication between a person and an object, an object, and an object is made from an intelligent environment or an object itself (M2M: The concept of Machine to Machine has been extended to the Internet, and has evolved into a concept of interacting with not only things, but all information in the real and virtual world. The main technologies of the IoT include sensing technology, wired and wireless communication and network infrastructure technology, IoT interface technology, and service technology through the Internet of Things.

In such an IoT network environment, end-users are required to develop a technology for effectively using a smart environment through an application for discovering things.

That is, in the technical field, technology development for designing a hierarchical system for architecture and image realization is required.

Domestic Publication No. 10-2016-0086140 Domestic registered patent No. 10-1628996 Domestic Publication No. 10-2016-0096243 Domestic Publication No. 10-2016-0089772

The present invention is to solve the above problems, and to provide an IoT network system that can be easily provided interface without a basic knowledge of the programming language based on the diagram language solution related to business processor management.

In addition, the present invention provides an IoT network system for allowing a user to easily build an IoT network infrastructure by allowing the user to easily visualize and interact with and manipulate the created virtual objects (VOs) for the IoT network configuration. will be.

However, the objects of the present invention are not limited to the above-mentioned objects, and other objects not mentioned will be clearly understood by those skilled in the art from the following description.

In order to achieve the above object, an IoT network system according to an embodiment of the present invention, a physical layer (physical layer) (110) which is a layer for configuring things related to the IoT network; A virtual object layer (VOL) 120 that represents a thing in the physical layer 110 as virtual objects (VO), and is a layer for managing the virtual objects (VO); Service Composition Layer (SCL) for creating Service Objects (SO) by combining two or more Virtual Objects (VO) with respect to Virtual Objects (VO) in Virtual Object Layer (VOL) 120. 130; And when each service object SO is created, a flow of a process desired by a user for one scenario is formed for a service object of one unit, and a business process for performing a join-based model of the service objects SO. A Business Process Layer (BPL) 140 that utilizes Business Process Modeling Notations (BPMN); Characterized by having a system architecture formed of four layers (layer) comprising a.

In this case, the process flow operates to perform a function defined by an individual service object (SO) in the business process layer (BPL) 140, and based on the encrypted behavior between the individual virtual objects (VO) in actual interaction. It is characterized by performing a physical object (PO) directly.

In addition, the thing is characterized in that for detecting the control data for the predetermined phenomenon occurring in the IoT network environment and the surroundings.

In addition, the virtual object VO summarizes or compressively presents information related to the object of the physical layer 110 and allows a user to manipulate the virtual object VO in the IoT network system environment. In addition, the physical layer 110 represented by the virtual object VO is characterized in that to enable access to the environment of the thing.

In addition, the service object SO may be formed by combining the temperature sensor virtual object VO as an input virtual object VO and the LED virtual object VO as an output virtual object VO.

In addition, the virtual object layer (VOL) 120 may provide a user with a component of local or remote interface classes for inputting information related to a thing in the physical layer where the user wants to register the virtual objects (VOs). Providing a virtual object manager (VOM) 120a; Characterized in having a.

The IoT network system according to an embodiment of the present invention provides an implementation of a business process modeling notation (BPMN) based on the representation of service objects by implementing through an interface for creating and deploying IoT network applications.

In addition, the IoT network system according to another embodiment of the present invention, by allowing the user to easily visualize and interact with and manipulate the created virtual objects (VOs) for the IoT network configuration, the user can easily configure the IoT network infrastructure It provides a buildable effect.

1 is a system architecture of an IoT network system according to an embodiment of the present invention.
2 is an operation diagram of a virtual object manager (VOM) of the IoT network system of FIG.
3 is an operation flowchart of the virtual object manager of FIG.
4 is a diagram illustrating the operation of a service composition manager in the IoT network system of FIG.
5 is a service flow diagram by a service composition manager in the IoT network system of FIG.
6 is a business process layer process diagram according to an embodiment of the present invention.
7 is a business process layer sequence diagram according to an embodiment of the present invention.
FIG. 8 is a diagram illustrating an IoT network application in the IoT network system of FIG. 1.
9 is a virtual object manager (VOM) diagram based on the IoT network system of FIG.
10 is a service composition manager based on the IoT network system of FIG.
11 is a business process management diagram based on the IoT network system of FIG.
12 is a business process management deployment engine diagram based on the IoT network system of FIG.

Hereinafter, the detailed description of the preferred embodiment of the present invention will be described with reference to the accompanying drawings. In the following description of the present invention, detailed descriptions of well-known functions or configurations will be omitted when it is deemed that they may unnecessarily obscure the subject matter of the present invention.

In the present specification, when one component 'transmits' data or a signal to another component, the component may directly transmit the data or signal to another component, and through at least one other component. This means that data or signals can be transmitted to other components.

1 is a diagram illustrating a system architecture of an IoT network system based on a BPM (Business Process Model) according to an embodiment of the present invention.

Referring to FIG. 1, the system architecture of an IoT network system includes a physical layer 110, a virtual object layer VOL 120, and a service composition layer 130 (SCL) 130. It is formed of four layers of a business process layer (BPL) 140, and each layer communicates with an adjacent layer according to individual functions and a predetermined communication plan.

Hereinafter, each layer will be described in detail.

The physical layer 110 is a layer for composing things related to the IoT network (Internet of Things). Here, the thing may detect control data about a preset phenomenon occurring in or around the IoT network environment.

In addition, as an embodiment of the thing, it may be defined as a sensing device and an actuator device having a communication performance through the Internet.

The virtual object layer (VOL) 120 refers to a layer for managing virtual objects (VO). The virtual object VO represents an object in the physical layer 110.

The virtual object VO may summarize or compressively present information related to the object of the physical layer 110, and allow a user to manipulate the virtual object VO inside the IoT network system environment. In this case, access to an environment of things in the physical layer 110 represented by the virtual object VO is enabled.

The virtual object (VO) in the virtual object layer (VOL) 120 is formed by a combination of two or more virtual objects (VO) performed on a service composition layer (SCL) 130 described later. Used to create Service Objects (SO).

As an example of the service object SO, it operates when the temperature sensor virtual object VO exceeds 40 ° C as the input virtual object VO, and joins the LED virtual object VO to the output virtual object VO. It can be formed into). At this time, the LED virtual object (VO) is set to start blinking when the conditions are met, and the acquisition of the temperature value and the blinking of the LED is preferably in accordance with the encrypted function between the corresponding virtual object (VO).

Once a service object (SO) is created, this one unit of service object is used by the Business Process Layer (BPL) 140 to form the flow of the process desired by the user for one scenario. do.

Herein, the business process layer (BPL) 140 uses a business process modeling notation (BPMN) to perform a join-based model of service objects (SOs).

The process flow operates to perform the functions defined by the individual service objects (SOs) at the business process layer (BPL) 140, and the physical objects (POs) based on the encrypted behavior between the individual virtual objects (VOs) in real interaction. This is equivalent to performing) directly.

On the other hand, each layer of the IoT network system has a static structure (interaction structure) to describe the main operation of each layer.

FIG. 2 is a block diagram illustrating an operation of a virtual object manager (VOM) 120a of the IoT network system of FIG. 1.

First, referring to object virtualization, the virtual object manager (VOM) 120a corresponds to a major component in the virtual object layer 120. The virtual object manager (VOM) 120a may include other classes such as a file manager 120a-1, a communication manager 120a-2, an XML parser 120a-3, and the like. Collaborate with classes to perform all the functions associated with virtual object layers (VOLs).

The virtual object manager (VOM) 120a provides the user with a component of local or remote interface classes for entering information related to the thing in the physical layer where the users wish to register the virtual objects (VOs).

The communication manager 120a-2 uses the file manager 120a-1 to retrieve an XML version of the virtual object VO from the local file system or to extract related information using the file manager 120a-1. To send a virtual object (VO) to the client application.

In this process, the client application may be a service composition manager 130a described later.

On the other hand, the XML parser 120a-3 collaborates with the file manager 120a-1 and changes the information input by the user into an XML element representing the virtual object VO or vice versa. It serves as an interface to

Functionally, the XML Parser 120a-3 uses the DeviceInformation class as a template for creating virtual objects (VOs).

Next, FIG. 3 shows an operation flowchart of the virtual object manager 120a of FIG. 2. Referring to FIG. 3, the sequence model shown in FIG. 3 represents the interaction between the interface elements and the user as well as the interactions in the form of message exchanges between system internal components for performing user commands.

The sequence of interactions is initiated by the virtual object manager 120a and initialized by all components, including the user interface and communication manager 120a-2, etc., for sequence initiation by the virtual object manager 120a. You must be in a state.

The main interface 120a-4 provides a view for all virtual objects (VOs), providing an XML repository 120a-to the file manager 120a-1 via the virtual object manager 120a. 5) request to read data related to the virtual object (VO).

The read data is parsed by the XML parser 120a-3, and information related to the virtual object VO is provided to the virtual object manager 120a for output through the interface 120a-4.

Accordingly, the user may interact with the virtual objects VOs through the interface 120a-4 under the control of the virtual object manager 120a. At this time, the interacted virtual object (VO) means that the user interacted with the behavior in the sequence model.

When the virtual object VO is selected for one of the plurality of virtual objects VO displayed on the interface by the user, the selected virtual object VO information is displayed again to the user through the interface view. Thereafter, if necessary, the user may select at least one of editing and updating the virtual object VO.

Meanwhile, in order to store the edited virtual object VO, the information displayed in the interface view is transferred to the XML parser 120a-3 by the control of the virtual object manager 120a to convert the information displayed in the preset format into a file manager. 120a-1 records the converted virtual object in the XML storage 120a-5. The deletion process can also be performed in the same way.

The communication manager 120a-2 operates as a server thread by detecting incoming connections from a remote client service control manager (SCM). That is, upon receiving the access request, the communication manager 120a-2 may request the virtual object manager 120a for the virtual object (VO) information sent to the client.

FIG. 4 is a block diagram for describing an operation of a service composition manager 130a based on the IoT network system of FIG. 1. Referring to FIG. 4, the main classes of the composition manager 130a and the relationship and association process between the respective classes are generally illustrated.

Here, the Form (130a-1), TabControl (130a-2) and TabPage (130a-3) classes are each .Net acting as displayable windows and containers for visual control. It is desirable to be built-in classes.

Specifically, the device module 130a-4 class is provided to perform a virtual representation for input and output of virtual objects VOs, and FIG. 4 shows a device module 130a-4. It shows a specialized relationship between the input module (OutputModule) (130a-5), the output module (OutputModule) (130a-6), and the device module (DeviceModule) (130a-4).

Here, actual classes representing the input device as the pressure sensor and the output device as the LED may be obtained from the input module 130a-5 and the output module 130a-6, respectively. Each of these input or output device representation classes is associated with a user attribute.

The DeviceModule 130a-4 class provides an IDeviceModule 130a-7 interface for performing core properties related to device modules and for performing unique methods of each device module. It can work.

In addition, the device module 130a-4 class may operate an I cloneable interface 130a-8 for generating virtual devices to be replicated.

Here, the interface provided to the IC cloneable 130a-8 may be used to duplicate the selected module when the user drags the module to the canvas, which is a bitmap 2D graphics area displayed on the web browser.

That is, an individual device virtual object (VO) module such as an LED class may include a view and a setting class in the form of an LEDView and an LEDSettings class. These LEDView and LEDSettings classes may be classes specialized from the DeviceView 130a-9 class and the DeviceSettings 130a-10 class shown in FIG. 4.

The DeviceView class 130a-9 corresponds to a work area class for representing the characteristics of the selected module in the form of a detailed view tab in the editor. Similarly, the DeviceSettings 130a-10 class can provide a form for setting properties and parameters.

The MainProcess (130a-11) class acts as a main back end process, a separate database-only handler installed to help the host work, and is run as a singleton class. It is preferable.

Other classes shown in FIG. 4 use the same instance as the main process 130a-11 through a public interface. In the present invention, the instance may be an object that can be accessed and executed in a program by allocating a physical memory according to a data type defined in the UI framework.

In addition, the MainProcess 130a-11 class checks a list of the DeviceModule 130a-4 class and the WorkSpace 130a-12 class. Here, the Space 130a-13 class is a superclass of the WorkSpace 130a-12 class, and it is an XML serialization for converting objects to XML data for storage purpose as well as the file system. Take advantage of the (XmlSerialization) class (130a-11a).

The Space 130a-13 class provides the current IWorkspace 130a-14, Undo / Redo functions, including interfaces related to the storage of data spaces. Ispace UndoRedo (IspaceUndoRedo) 130a-15 related to the maintenance of space can be executed.

In order to maintain information about the joins formed between the input and output modules shown in the functional editor, the joining of parallel paths), the Space class 130a-13 is added to the JoinInfo class 130a-16. It is desirable to have a list of).

This list of JoinInfo classes 130a-16 is used by the WorkSpace 130a-12 who wants to know about the confluences of the parallel paths associated with the current project.

Similarly, each WorkSpace (130a-12) object is a DeviceContents (130a-17) and Contents (130a) to represent the input and output modules appearing in the workspace of a given service composition project -18) has an object of class DeviceData (130a-19) using the class.

The DevicePanel 130a-20, WorkPanel 130a-21, and WorkArea 130a-22 classes construct structures derived from the UserControl (130a-23) classes. Have These classes are used to provide a graphical user interface (UI) for each project. Here, each project is used to display the objects of TabPageEx (130a-2b) as tabs in KRBT TabControl (130B-2a), which is extended for the TabControl (130B-2) class. Means that.

TabPageEx 130a-2b corresponds to an extended version of the TabPage 130a-3 class for providing a closeable tabpage.

KRBT tab control (KRBTTabControl) 130a-2a corresponds to a portion of main form 130a-1a corresponding to a displayable main container for visual controls and components.

On the other hand, the Trashbin 130a-24 class can graphically represent waste bins worked with the panels 130a-21 to provide the ability to delete modules displayed in the editor's workspace. Perform the action.

5 illustrates a process for designing or configuring a service flow using a service composition manager 130a. Referring to FIG. 5, a user first executes a main graphical user interface (GUI) to create a new project.

More specifically, the first region 1st shown in FIG. 5 represents an interaction sequence among various internal components of the service composition manager 130a when the user initializes a new project, and the sequence of the first region. Does not perform initialization of the main process (MainProcess) (130a-11).

This is because the editor has already been initialized and the FrmMain 130b container has already been displayed on the screen where the user can click a new project button to start the process.

Referring back to FIG. 5, when a user clicks on a new project button in FrmMain 130b, FrmMain 130b calls the createWorkArea () function and creates a CreateSpace () message in the main process. Send it to (MainProcess) 130a-11.

The main process 130a-11 creates an object of the WorkSpace class and returns the generated object to the FrmMain 130b.

FrmMain 130b then adds the new workspace object to the collection space of MainProcess 130a-11, and adds the newly created workspace object to the WorkArea in response to the CreateSpace () message. By passing to 130a-22, a WorkArea 130a-22 object is created.

At this point, the WorkArea 130a-22 class is associated with a WorkPanel 130a-21 object that actually operates to illustrate the canvas for the Service Control Manager (SCM).

In addition, the WorkArea 130a-22 class is an input for displaying device module blocks that can be dragged and dropped by a user to a work area for creating a service design. And output panels.

To display the work area objects in the FrmMain 130b, the WorkArea 130a-22 class has an extended tab page object collection control called TabPageEx (130a-2b). Also perform.

Here, the tab page object is displayed as a new tab on the tab control, and all toolbar controls are created using the enableControls message. At this time, the user can check a new project tab that can drag and drop the virtual objects for creating the function pro.

When a new project is initialized, the user can start a strat to perform a drag and drop of an input or output virtual object VO to the work area.

If the work area accommodates the associated WorkPanel 130a-21 controls, a graphical representation for the virtual object VO dropped by the user is shown in the panel.

Next, the mapping sequence from the virtual object VO to the service object SO on the service composition layer 130 (SCL) 130 will be described with reference to the second region 2nd in FIG. 5. According to the drag & drop in the above panel, the event handler obtains the dropped virtual object (VO) and related data, and then creates a duplicate object from the original stored in the device list in the main process 130a-11. .

The clone object is added to the list of devices managed in each workspace through its parent class space. The parent class preferably has a stack implementation for managing Undo / Redo.

This workspace class 130-12 creates an XMLSerializer instance and requests that the MemorySerializeCollection be executed by the XMLSerializer 130a-11a having its own reference as a parameter.

Accordingly, the XMLSerializer 130a-11a class acquires all data associated with the workspace object, converts the obtained data into an XML format, and stores it as byte data in a memory buffer.

On the other hand, the byte data buffer reference is returned to the Workspace 130-12 class.

Here, the byte data buffer is pushed into the Undo stack, the device list is updated, and the WorkPanels 130a-21 are invalidated to generate the update flow.

This sequence is repeated every day when a new device module is dropped into the work panel by the user.

When a device module is deformed only once in a project in a project, only one thing can be memorized, but this is due to an initialization policy for simplicity of generated flows and can be changed according to a setting.

Next, referring to FIG. 5, the third region 3rd may allow a user to join an input device module to a plurality of output modules. To this end, the user should click and press the left mouse button on the input virtual object VO already created in the WorkPanel 130a-21. When the user moves the mouse while holding down the left button, the WorkPanels 130a-21 use the static method of the JoinInfo class 130a-16 to obtain the starting position where the join is drawn. Call To illustrate a join, a Bezier line is drawn from the start of the join to the mouse pointer.

When the mouse pointer is input to the virtual object (VO) area, it is calculated to the end position of the join again by the static method, and the join is displayed on the WorkPanels 130a-21.

In this case, when the user removes the pressed state of the mouse button, the JoinInfo class 130a-16 object is created together with the information of the input and output device modules, and the JoinInfo class 130a-16 object. Is added to the join list managed by the workspace object. The drawn line is deleted. Once a join is created, the user can double-click the join or individually double-click the virtual object (VO) to set up an action, ie to select an available function for the associated physical object, and other parameters. Can also be set. The relevant data is then stored as part of the Service Objects (SO) in the form of JoinInfo (130a-16), and the completed Service Object (SO) is connected to the input and output virtual objects (VOs). Is generated by

FIG. 6 is a diagram for explaining process modeling as a static structure representing main components in a business process layer (BPL) 140 according to an embodiment of the present invention.

Referring to FIG. 6, the purpose of a business process layer (BPL) 140 is to utilize a service object (SO) created in a service composition layer (Service Composition Layer, SCL) 130, and the service object ( This is to represent the SO to the user in the form of business process modeling notations.

The most important component in the Business Process Layer (BPL) 140 is the business process design manager 140a. The business process design manager 140a includes a BPM editor 140a-1, and the BPM editor 140a-1 includes a toolbar 140a-2 and a toolbox 140a-. 3) corresponds to the main window 140a-5 including a designer canvas (140a-4).

The toolbar 140a-2 is a component panel branched from the itemControl class 140a-2a. This panel shows a visual representation of the business process modeling notation form corresponding to the service object SO obtained in the service composition layer 130.

The toolbar 140a-2 component performs operations with basic drawing commands for performing drag and drop design by the user. Here, drawing commands mean execution, undo, copy, paste, group and ungroup operations.

The connection (140a-6) class and its associated ConnectionAdorner (140a-7) class are Business Process Modeling Notations (BPMN) items that represent a flow sequence between process processes. It is used to show the connection line between.

FIG. 7 is a flowchart illustrating an operation sequence in a business process layer (BPL) 140 according to an embodiment of the present invention based on the components of FIG. 6.

Referring to FIG. 7, an operation in a business process layer (BPL) 140 may include obtaining service objects SOs from the service composition layer 130, and may include service objects SOs. Including the mapping to the business process modeling notation, it converts service objects (SOs) into a process model for the user and finally executes the process.

The illustrated service control manager (SCM) communication manager 140c waits for a connection request from the BPM editor 140a-1, which is a major component of the business process layer 140.

When the connection is successfully connected, the service objects (SOs) available in the SO State Repository 140d are obtained in the form of an XML info object and passed to the Business Process Layer 140. do.

Obtained service objects (SOs) are parsed by an XML Parser 140f for presentation to the user in a business process modeling notation. The user creates a process model by drag-and-drop operation using a visually implemented business process modeling notation.

In this case, the user may draw the process component according to a predetermined operation rule or conditions in the middle of the process model generation process and connect the process component through the connection notation.

When the process model is completed through this process, a process object is created. The process object is an object that can be deployed through the deployment engine (or deployment manager) 140e in the business process layer 140.

These deployed process objects are those that can be changed into a series of operations based on the services that make up the service object.

Here, the deployment engine 140e interacts with services as part of the process object, and the generated process object is executed in a separate thread so that various process objects can be executed simultaneously.

8 is a reference diagram illustrating the concept of an IoT network application configuration system. Referring to FIG. 8, as a prototype execution screen of the proposed system, each sub-item shown in FIG. 8 represents an individual component and may be functionally classified.

Next, FIG. 9 is a diagram illustrating an XML representation of the UI screen and the virtual object VO implemented by the virtual object manager (VOM) 120a. Referring to FIG. 9, an XML representation of data of stored virtual objects (VOs) is shown, and the virtual object manager (VOM) 120a may be able to encrypt behavior of IoT network resources to users.

The virtual object manager (VOM) 120a associates the IoT network resource data with a visual representation, allowing the virtual object (VO) to interact and manipulate in a more intuitive manner.

Two different approaches can be useful for this purpose. The first approach may be a passive approach where detailed provisioning of the IoT network resources in the form of Uniform Resource Identifiers (URIs), locations, types and services is made. In this way a device that performs the provided protocols may be added as a resource to the system.

Another approach is that the virtual object manager (VOM) 120a is provided with the URI of the remote device and then through the performed service of the CoAP protocol, whereby the virtual object manager (VOM) 120a is automatically needed from the device. Extract the information. However, this method has an advantage of being automatically performed, but has a disadvantage that it may be useful only for specific devices provided for performing a specific service in a system for a predetermined purpose.

FIG. 10 is a diagram illustrating an XML representation of a UI screen and a virtual object VO implemented by a service composition manager 130a.

Referring to FIG. 10, the service composition manager 130a corresponds to a main module in the service composition layer 130. The service composition manager 130a has a main purpose to allow the user to easily visualize and to interact with and manipulate the virtual objects (VOs) created by the virtual object manager (VOM) 120a.

To accomplish this purpose, the sensor virtual objects VOs and the actuator virtual objects VOs may be divided into input and output modules. These modules can be implemented to be dragged and dropped directly onto the canvas through mouse events in the Windows operating system. Virtual object (VO) modules implemented on the canvas may be represented by simple join lines expressed by connecting input virtual objects (VOs) and output virtual objects (VOs). You can use intuitive mouse events to set rules of action for VOs).

The join of the input virtual objects VOs and the output virtual objects VOs in the service composition manager 130a creates a service object SO, and these service objects SOs As part of the service object SO, it may be stored as XML documents that represent the input virtual object VO and the output virtual object VO separately.

In addition, the connection between the virtual objects (VOs) may be represented as an XML document in the form of a specific join node of the source and sink objects for the connection. Accordingly, the objects VOs may be stored, opened or updated according to a user's request.

FIG. 11 is a diagram illustrating an XML representation of a UI screen and a virtual object VO implemented by the BPM editor 140a-1. Referring to FIG. 11, the BPM editor 140a-1 expresses the representations of service objects (VOs) generated by the service composition manager 130a as a business process modeling notation (BPMN). In charge. The main interface for the BPM editor 140a-1 is shown in FIG.

The BPM editor 140a-1 provides a Business Process Modeling Notation (BPMN) based on the representation of service objects to provide the interface knowledge of the baseline for creating and deploying IoT network applications. The purpose is to provide.

In addition, the BPM editor 140a-1 may eliminate the need for a programming skill that a user needs to create a graphic model, and directly deploy it to an IoT network application.

Business Process Modeling Notations (BPMN) can be performed as part of a prototype system, including basic events, tasks, gateways, and script notations. Service objects are represented as tasks and dragged by the user. You can create a model using the drop approach.

This sequence of operations is created by the concatenation of the notations through the object objects, and the same object objects are used to obtain information about the input and output notations in the model.

Gateway notation is performed as a decision tool as long as screen notation is provided in the script list to be selected for the user to manipulate the data or proceed with the process.

In the XML implementation of the business process model generated by the user, the XML sample is shown in FIG. 11 to represent the task and other notations as DesignItem objects. In addition, in the model shown in FIG. 11, it can be seen that connection objects for maintaining tracks of source and sink items are included.

FIG. 12 is a diagram illustrating a UI screen implemented by a BMP Deployment Engine 140e or a BMP Deployment Manager. Referring to FIG. 12, not only the UI screen implemented by the BMP Deployment Manager 140e but also the result of a test of the same model generated through the BPM editor 140a-1 is shown.

The BMP Deployment Manager 140e represents a process model for the relationship between various IoT network resources generated by the BPM editor 140a-1 and stored as an XML document.

These XML documents are loaded and executed in the BMP deployment manager 140e. Since the prototype implementation shown in FIG. 12 considers IoT network resources together with the CoAP implementation, the deployment manager 140e is implemented using Java. Accordingly, IoT network resources can be implemented using the Californium framework.

In order to execute the generated process model, the XML document is first parsed by the BMP deployment manager 140e and then related entities are extracted. Once relevant objects are extracted, they are sorted according to the flow of the process model and stored in a list, the list is generated repeatedly, and each object is performed based on attributes and actions.

CoAP services for tasks related to remote IoT network resources are invoked using the Californium framework described above. The response to the call is read and provided as input to another notation that is directly linked to the particular task notation.

For reference, scripts executed as part of the BMP Deployment Manager 140e may be executed by the manager by the manager while data is provided by another entity, such as a remote IoT network resource.

The invention can also be embodied as computer readable code on a computer readable recording medium. Computer-readable recording media include all kinds of recording devices that store data that can be read by a computer system.

Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disks, optical data storage devices, and the like, which are also implemented in the form of carrier waves (eg, transmission over the Internet). It also includes.

The computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. And functional programs, codes and code segments for implementing the present invention can be easily inferred by programmers in the art to which the present invention belongs.

As described above, the present specification and drawings have been described with respect to preferred embodiments of the present invention, although specific terms are used, it is only used in a general sense to easily explain the technical contents of the present invention and to help the understanding of the present invention. It is not intended to limit the scope of the present invention. It will be apparent to those skilled in the art that other modifications based on the technical idea of the present invention can be carried out in addition to the embodiments disclosed herein.

110: physical layer
120: Virtual Object Layer (VOL)
120a: Virtual Object Manager (VOM)
130: service composition layer (SCL)
130a: Service Composition Manager (SCM)
140: Business Process Layer (BPL)
140a: Business Process Design Manager (BPDM)

Claims (4)

In the IoT network system, based on the diagram language solution related to the business process management, the interface can be easily provided without the basic knowledge of the programming language.

A physical layer 110, which is a layer for configuring a thing related to an IoT network;
A virtual object layer (VOL) 120 representing a thing in the physical layer 110 as a virtual object (VO), which is a layer for managing the virtual object (VO);
The thing detects control data on a preset phenomenon occurring in and around the IoT network environment.
A service composition layer (SCL) 130 for generating a service object SO by a combination of two or more virtual objects VO with respect to the virtual object VO in the virtual object layer VOL 120; And
When each service object (SO) is created, it forms a flow of a process desired by a user for one scenario for a service object of one unit, and a business process to perform a join-based model of service objects (SO). A business process layer (BPL) 140 that utilizes modeling notation (BPMN),
The flow of the process operates to perform the functions defined by the individual service objects (SOs) in the business process layer (BPL) 140, and is based on the encrypted behavior between the individual virtual objects (VOs) in actual interaction. IoT network system, characterized in that to perform (PO) directly.
The method of claim 1, wherein the virtual object VO summarizes or compressively presents information related to a thing in the physical layer 110, and allows a user to manipulate the virtual object VO in an IoT network system environment. And access to an environment of things in the physical layer 110 expressed as a virtual object (VO).
The IoT of claim 1, wherein the service object SO is formed by a combination of a temperature sensor virtual object VO as an input virtual object VO and an LED virtual object VO as an output virtual object VO. Network system.
The virtual object layer (VOL) 120 of claim 1, wherein the virtual object layer (VOL) 120 provides a user with a component of local or remote interface classes for inputting information related to a thing in the physical layer where the user wants to register the virtual objects (VOs). IoT network system comprising a virtual object manager (VOM) (120a).

Images