No code operation development framework system for tag data-based IoT embedded system

Abstract

According to some embodiments of the present invention, an IoT embedded middleware-based field management system using a no-code operational development framework comprises: an IoT embedded middleware device configured to form a connection with IoT devices at an industrial site to transmit and receive field management data; a cloud server configured to provide an IoT link utilized to access the field management data in a cloud environment; a no-code service server configured to provide an integrated operational development service that defines the control logic of the IoT embedded middleware device in a no-code manner; and a management server configured to provide a field management service regarding the industrial site using the IoT devices based on the integrated operational development service.

Description

Technology Field

[0001] The present invention relates to an IoT embedded middleware-based field management system. Background Technology

[0002] IoT technology is being utilized to comprehensively operate and manage the functions of various electronic devices in industrial settings and homes. By leveraging the integrated operational management of IoT devices, business models can be defined across diverse industrial environments. For instance, business models such as power management services using IoT power meters, smart vehicle data collection and management solutions, and smart electric mobility charging station management solutions can be envisioned. To achieve this, a hardware architecture capable of seamlessly utilizing data processed by various types of IoT devices, as well as a development method that allows for the easy generation of operational code for business models using this architecture, may be required. Prior art literature

[0003] Registered Patent Publication No. 10-2019701 The problem to be solved

[0004] One of the objectives of the present invention is to provide a field management system that integrates the management of data from various types of IoT devices using an IoT embedded middleware device, and enables field systems to be built and updated even by non-specialized personnel lacking programming knowledge using a no-code operational development framework. The technical objectives of the present invention are not limited to the technical problems mentioned above, and other unmentioned technical problems will be clearly understood by those skilled in the art from the description below. means of solving the problem

[0005] According to a first embodiment of the present invention, an IoT embedded middleware-based field management system using a no-code operational development framework comprises: an IoT embedded middleware device configured to form a connection with IoT devices at an industrial site to transmit and receive field management data; a cloud server configured to provide an IoT link utilized to access the field management data in a cloud environment; a no-code service server configured to provide an integrated operational development service that defines the control logic of the IoT embedded middleware device in a no-code manner; and a management server configured to provide a field management service regarding the industrial site using the IoT devices based on the integrated operational development service; wherein the no-code service server is configured to generate update information for the IoT embedded middleware device corresponding to a structural change of the industrial site and distribute it to the IoT embedded middleware device through the IoT link.

[0006] According to a first embodiment of the present invention, the no-code service server is configured to receive no-code user-developed logic corresponding to a structural change of the industrial site, generate an update file corresponding to the user-developed logic based on a code generator and a build engine, and provide the update file to the IoT embedded middleware device via an OTA method.

[0007] According to a first embodiment of the present invention, when the IoT embedded middleware device forms a new connection with an additional IoT device different from the IoT devices already connected to the industrial site, the operator of the site management service is configured to provide a no-code user-developed logic that reflects the change in the connection structure to the no-code service server, and the no-code service server is configured to generate an update file that enables access to the site management data of the additional IoT device.

[0008] According to a first embodiment of the present invention, the cloud server comprises a plurality of cloud storages for distributing and storing the field management data as real-time data and historical data by configuring a data processing pipeline, and the cloud server is configured to provide the real-time data and the historical data through the data processing pipeline in response to a request from the management server.

[0009] According to a first embodiment of the present invention, the IoT devices include smart power meters installed at the industrial site, the site management data includes power data collected from the smart power meters, the site management service provided by the management server includes a power management service based on the power data of the smart power meters, and the power management service includes a real-time service that provides a real-time power status based on the real-time data and a statistical analysis service that provides a statistical analysis of past power usage history based on the historical data.

[0010] According to a second embodiment of the present invention, an IoT embedded middleware-based field management system using a no-code operation development framework comprises: an IoT embedded middleware device configured to form connections with IoT devices at an industrial site to transmit and receive field management data; a cloud server configured to provide an IoT link utilized to access the field management data in a cloud environment; a no-code service server configured to provide an integrated operation development service that defines the control logic of the IoT embedded middleware device in a no-code manner; and a management server configured to provide field management services regarding the industrial site using the IoT devices based on the integrated operation development service. The connections formed between the IoT devices and the IoT embedded middleware device are configured to transmit and receive the field management data in two or more different data formats by two or more different communication methods, and the IoT embedded middleware device is configured to provide tag data with a unified data format of the field management data to the IoT link.

[0011] According to a second embodiment of the present invention, the IoT embedded middleware device includes a tag database for storing the tag data, the tag database includes an internal register for storing the original values ​​of the field management data and a metadata section for storing metadata information for accessing the original values, and the management server is configured to receive the tag data through the IoT link and access the original values ​​of the field management data based on the metadata information.

[0012] According to a second embodiment of the present invention, the tag data includes pre-defined (PDF) tag data provided by the IoT embedded middleware device itself and user-defined (UDF) tag data defined by an operator of the field management service during the process of programming the control logic using the integrated operation development service, and the IoT embedded middleware device is configured to manage at least a portion of the tag data as non-volatile (NV) data that is retained even when the power of the IoT embedded middleware device is lost.

[0013] According to a second embodiment of the present invention, the IoT embedded middleware device is configured to generate tag data for at least some of the periodic reporting items among the field management data items periodically collected from the IoT devices, generate periodic reporting data abstracted into one dimension for the tag data for the periodic reporting items, and provide it to the cloud server, and the cloud server is configured to reconstruct the periodic reporting data abstracted into one dimension to generate connection-specific reporting data and provide the connection-specific reporting data to the management server.

[0014] According to a second embodiment of the present invention, the control logic programmed by an operator of the field management service using the integrated operation development service is generated by the no-code service server to include one or more messages regarding data access for each of the connections with the IoT devices, and the one or more messages include commands that instruct the IoT embedded middleware device to collect a portion of the field management data from each of the IoT devices and store it as tag data.

[0015] According to a third embodiment of the present invention, an IoT embedded middleware-based field management system using a no-code operation development framework comprises: an IoT embedded middleware device configured to form a connection with IoT devices at an industrial site to transmit and receive field management data; a cloud server configured to provide an IoT link utilized to access the field management data in a cloud environment; a no-code service server configured to provide an integrated operation development service that defines the control logic of the IoT embedded middleware device in a no-code manner; and a management server configured to provide a field management service regarding the industrial site using the IoT devices based on the integrated operation development service. The no-code service server is configured to receive input values ​​for generating at least one operator block and input values ​​for generating at least one operation target block from an operator of the field management service, and to generate the control logic for the IoT embedded middleware device based on a combination of the at least one operator block and the at least one operation target block.

[0016] According to a third embodiment of the present invention, the at least one operation target block includes a conditional block that outputs a result of 0 or 1 depending on whether a conditional statement is satisfied, the at least one operator block, a set block that sets a specific variable at a node of a logic circuit combining the at least one operation target block, and an assign block that assigns a specific value to a target variable.

[0017] According to a third embodiment of the present invention, the at least one operator block includes a logic gate block that outputs a logic value based on the result of one or more conditional blocks, an action block that performs a predefined operation based on input values, a message reading block that instructs to read the field management data from any one of the IoT devices, a message transmission block that instructs to transmit the input value to the cloud server, and an allocation block that generates a given operation result as tag data when the input value corresponds to a logic value of 1.

[0018] According to a third embodiment of the present invention, the no-code service server is configured to generate user code corresponding to a combination of at least one operator block and at least one operation target block using a code generator, and to generate a binary file corresponding to the user code using a build engine.

[0019] According to a third embodiment of the present invention, the no-code service server is configured to upload the binary file to cloud storage within the cloud server and provide the upload address of the cloud storage to the IoT embedded middleware device, and the IoT embedded middleware device is configured to download the binary file from the upload address of the cloud storage while performing an integrity check on the binary file. Effects of the invention

[0020] According to embodiments of the present invention, a field management system can be provided that integrates and manages data of various types of IoT devices using an IoT embedded middleware device, and enables field systems to be built or updated even by non-specialized personnel lacking programming knowledge using a no-code operational development framework. The technical effects according to the embodiments of the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art in accordance with the disclosure of this document. Brief explanation of the drawing

[0021] FIG. 1 illustrates an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments. FIG. 2 illustrates the operation process of an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments. FIG. 3 illustrates the effects that can be achieved by an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments. FIG. 4 illustrates a process for initiating the operation of an IoT embedded middleware device according to some embodiments. FIG. 5 illustrates the process of setting up the initial settings of an IoT embedded middleware device according to some embodiments. FIGS. 6 to 8 illustrate a process for performing a firmware update of an IoT embedded middleware device according to some embodiments. FIG. 9 illustrates a process of performing an update in response to a change in the structure of an industrial site according to some embodiments. FIG. 10 illustrates an IoT link architecture and data pipeline of a cloud server according to some embodiments. FIG. 11 illustrates a UI of a no-code service server for generating control logic for an IoT embedded middleware device according to some embodiments. FIG. 12 illustrates a tag database within an IoT embedded middleware device according to some embodiments. FIG. 13 illustrates a UI of a no-code service server for generating tag data according to some embodiments. FIGS. 14 and 15 illustrate a process for collecting and managing field management data according to some embodiments. FIGS. 16 and 17 illustrate a process in which a no-code service server according to some embodiments generates control logic for an IoT embedded middleware device. FIGS. 18 to 20 illustrate elements constituting an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments. FIG. 21 illustrates a method of operation for an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments. Specific details for implementing the invention

[0022] Embodiments of the present invention will be described in detail below with reference to the drawings. The description below is intended only to illustrate the embodiments and is not intended to limit or restrict the scope of the rights according to the present invention. Anything that can be easily inferred by a person skilled in the art from the detailed description and embodiments of the invention should be interpreted as falling within the scope of the rights according to the present invention. Detailed descriptions of matters widely known to those skilled in the art regarding the present invention are omitted.

[0023] The terms used in this invention are described as general terms widely used in the technical field relating to this invention; however, the meaning of the terms used in this invention may vary depending on the intent of those skilled in the field, the emergence of new technologies, examination standards, or case law. Some terms may be selected at the discretion of the applicant, and in such cases, the meaning of the arbitrarily selected terms will be explained in detail. The terms used in this invention should be interpreted not merely in their dictionary meanings, but in a sense that reflects the overall context of the specification.

[0024] FIG. 1 illustrates an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments.

[0025] Referring to FIG. 1, an exemplary structure of an IoT embedded middleware-based field management system (100) using a no-code operation development framework can be illustrated. The field management system (100) may include an IoT embedded middleware device (110), a cloud server (120), a no-code service server (130), and a management server (140).

[0026] The field management system (100) can collect field management data using IoT devices installed at an industrial site and provide management services through a management server (140) based on this data. For example, the field management system (100) may include power management services, vehicle information collection / management solutions, electric mobility charging station management solutions, etc.

[0027] The IoT embedded middleware device (110) can be installed at an industrial site to form connections with IoT devices through various communication methods. The IoT embedded middleware device (110) can communicate with a no-code service server (130) and a management server (140) through a cloud server (120). While the IoT embedded middleware device (110) is installed at an industrial site, the cloud server (120), the no-code service server (130), and the management server (140) can be installed in a remote location.

[0028] The no-code service server (130) can provide an integrated development environment (IDE) so that non-professional development personnel (132) can develop the operating environment of the field management system (100). For example, the non-professional development personnel (132) may be the operator of a user service (144) operated through the management server (140). The user service (144) may include a power management service, a vehicle information collection / management solution, an electric mobility charging station management solution, etc.

[0029] FIG. 2 illustrates the operation process of an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments.

[0030] Referring to FIG. 2, the operation process (210, 220, 230, 240) of the field management system (100) can be illustrated.

[0031] In the operation process (210), a field system that manages an industrial site in a no-code manner without specialized personnel can be set up through the no-code service server (130). In the operation process (220), the development settings for the field system can be applied to an IoT embedded middleware device (110) installed at the industrial site.

[0032] In the operation process (230), once field management data from an industrial site is collected by the IoT embedded middleware device (110), the field management data can be provided to other configurations of the field management system (100) via the IoT link of the cloud server (120). In the operation process (240), a management server (140) connected to the IoT link of the cloud server (120) can receive the field management data necessary for providing field management services.

[0033] FIG. 3 illustrates the effects that can be achieved by an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments.

[0034] Referring to FIG. 3, a structure for explaining the achieved effect of the field management system (100) can be illustrated.

[0035] An IoT embedded middleware device (110) may be installed at an industrial site, and IoT devices (112, 114, 116, 118) at the industrial site may form a connection with the IoT embedded middleware device (110). The IoT devices (112, 114, 116, 118) may be devices that perform different types of functions. For example, the IoT devices (112, 114, 116, 118) may include temperature sensors, humidity sensors, air conditioners, etc., and may include other types of IoT devices.

[0036] In the field management system (100), non-professional development personnel can write various applications for IoT embedded middleware devices (110) using a web-based integrated development environment (IDE) in a no-coding manner through a no-code service server (130). Since non-professional development personnel can directly build, maintain, and repair the management system of the field management system (100), high accessibility to development can be guaranteed. In addition, since multiple IoT devices of different types (112, 114, 116, 118) can be integrated through a single IoT embedded middleware device (110), the cost of building the IoT management system can be reduced.

[0037] FIG. 4 illustrates a process for initiating the operation of an IoT embedded middleware device according to some embodiments.

[0038] Referring to FIG. 4, a process (400) for initiating the operation of an IoT embedded middleware device (110) can be illustrated.

[0039] First of process (400), when the IoT embedded middleware device (110) is installed at an industrial site, integration with the cloud server (120) can be performed automatically. For example, access to the IoT link of the cloud server (120) can be made through a commercial data communication network such as LTE, 5G, or WLAN. Second of process (400), when a customer scans the QR code of the IoT embedded middleware device (110), the customer's account information can be provided to the no-code service server (130). For example, the customer may be a non-professional development personnel and an operator of the field management service operated by the management server (140).

[0040] Thirdly, in the process (400), the customer can proceed with system construction for the field management system (100) through an integrated development environment (IDE) provided by the no-code service server (130). Fourthly, in the process (400), once system construction is complete, configuration files and / or update files for the IoT embedded middleware device (110) can be provided via OTA. Finally, the IoT embedded middleware device (110) can start operation after verifying the security of the configuration / update content.

[0041] FIG. 5 illustrates the process of setting up the initial settings of an IoT embedded middleware device according to some embodiments.

[0042] Referring to FIG. 5, the process (410, 420, 430) of setting the initial settings of an IoT embedded middleware device (110) can be illustrated.

[0043] The first process (410) can be executed when the user's application is not uploaded or when a factory reset is performed. Communication for linking with the IoT link of the cloud server (120) can be performed. In the second process (420), the unique certificate of the IoT embedded middleware device (110) can be analyzed for linking with the IoT link of the cloud server (120). This can prevent tampering or theft of management data at the industrial site. In the third process (430), the digital signature of the no-code service server (130) can be verified. This may be necessary to verify whether it corresponds to a legitimate application. This can also prevent data tampering or theft.

[0044] The IoT embedded middleware device (110) can support real-time user logic execution and programmable functions. Real-time user logic can be executed at up to 125Hz. Programmable functions can be supported, and OTA updates can be supported. In terms of communication, the IoT embedded middleware device (110) can integrate field data and provide a stable connection with a remote server. Communication methods for integrating field IoT devices and industrial equipment can be supported. For example, in the case of Zigbee for network configuration as a coordinator, only designated devices can be connected. Low-power Bluetooth (BLE) can also allow only designated devices to connect.

[0045] Communication methods for industrial equipment integration may be supported. Modbus RTU (over RS232, RS485), CAN 2.0 A / B Modbus TCP (over Wi-Fi / over Ethernet), OPC UA, DNP 3.0, IEC 61850, etc. may be supported. The IoT embedded middleware device (110) may communicate with a remote cloud server based on integrated MQTT. Cellular communication such as 2G / 3G / 4G / 5G may be supported, and Wi-Fi may be supported. For security, a certificate-based connection may be configured. Certificate protection through SecureZone, etc., may be supported. The IoT embedded middleware device (110) may be equipped with a lithium-ion battery of 500 mAh to 3000 mAh. A battery voltage measurement function may be provided. Waterproof and dustproof features (IP65), low-power operation (DC 8~16V), surge protection, reverse power protection, and operation in high temperature and high humidity environments may be supported.

[0046] The main processor of the IoT embedded middleware device (110) may include an ARM-cortex M4 MCU 192 MHz. The communication IC may include a Cellular IC, a Wi-Fi / BLE IC, a Zigbee IC, etc. The communication ICs may be used in a module form through the main processor. Alternatively, the main processor may be integrated into a Cellular IC. Two digital input dry contact channels may be supported. RS232, RS485, and CAN may be selectively supported as one channel each via a Mux. Four industrial mechanical antennas may be supported. For example, a broadband antenna (cellular), an active antenna (GPS), and a 2.4 GHz dedicated antenna (Zigbee, Wi-Fi / BLE) may be supported. However, such a hardware structure is merely an example, and other hardware structures may be utilized as needed.

[0047] FIGS. 6 to 8 illustrate a process for performing a firmware update of an IoT embedded middleware device according to some embodiments.

[0048] Referring to FIG. 6, a process (600) for performing a firmware update of an IoT embedded middleware device can be illustrated.

[0049] In the process (600), non-professional development personnel (132) can write user logic and send a build request to the no-code service server (130) based on it. In response, the no-code service server (130) can perform data structuring (510) on the user logic and input the result into a code generator (134) to generate user code (134). The build engine (136) of the no-code service server (130) can convert the user code (134) into a binary file (530). The no-code service server (130) can upload the binary file (530) to the cloud storage (122) of the cloud server (120). The cloud storage (122) may include Amazon S3 storage.

[0050] Referring to FIG. 7, a process (700) for performing a firmware update of an IoT embedded middleware device can be illustrated.

[0051] In process (700), the IoT embedded middleware device (110) can receive an upload address from the no-code service server (130) and download a binary file (530) from cloud storage (122). During the download process, the IoT embedded middleware device (110) can download the binary file (530) in a unit capacity and then perform an integrity check on it. For example, the unit capacity for the integrity check may be 1 KB.

[0052] Referring to FIG. 8, a process (800) for performing a firmware update of an IoT embedded middleware device can be illustrated.

[0053] In process (800), the no-code service server (130) can send an update command to the IoT embedded middleware device (110). In response, the IoT embedded middleware device (110) can enter update mode, perform a file integrity check, and then perform the update. If the update fails, the update may be retried or a factory reset may be performed.

[0054] FIG. 9 illustrates a process of performing an update in response to a change in the structure of an industrial site according to some embodiments.

[0055] Referring to FIG. 9, a process (900) for performing an update in response to a change in the structure of an industrial site can be illustrated.

[0056] In process (900), first, the physical configuration of the industrial site may be changed. For example, structural changes to the industrial site may include the addition of a connection with a new IoT device. When structural changes such as the addition of a connection occur, it may be necessary to update the control code to add control logic for the new IoT device.

[0057] To update the control code, the operator of the field management service provided by the management server (140) can add user logic through the no-code service server (130). The operator of the field management service can write user logic in a no-coding manner even without programming knowledge.

[0058] The no-code service server (130) can store an update file that remotely builds user logic in cloud storage (122). Based on the update file stored in cloud storage (122), an over-the-air (OTA) update for the IoT embedded middleware device (110) can be performed. Once the OTA update is completed, the operator of the field management service can verify the application of the update changes through the no-code service server (130).

[0059] FIG. 10 illustrates an IoT link architecture and data pipeline of a cloud server according to some embodiments.

[0060] Referring to FIG. 10, the IoT link architecture and data pipeline of the cloud server (120) can be illustrated.

[0061] The IoT embedded middleware device (110) can collect field management data from IoT devices and provide a report message in JSON format to the cloud server (120) based on this data. The IoT link architecture and data pipeline of the cloud server (120) can manage field management data at different times using multiple cloud storages. For example, the cloud storages of the cloud server (120) may include Amazon S3, Amazon EMR, Amazon DynamoDB, Amazon Athena, etc.

[0062] The IoT link architecture and data pipeline of the cloud server (120) can communicate with the management server (140) corresponding to the customer service server. The management server (140) can request real-time data and historical statistical data from the cloud server (120). Upon receiving such data, the management server (140) can provide functions regarding real-time data and / or statistical data. For example, in the case of a power management service using an IoT power meter, the management server (140) can provide functions such as a real-time power data display function and a statistical analysis function for historical power data.

[0063] FIG. 11 illustrates a UI of a no-code service server for generating control logic for an IoT embedded middleware device according to some embodiments.

[0064] Referring to FIG. 11, a UI (1100) of a no-code service server for generating control logic for an IoT embedded middleware device (110) can be illustrated.

[0065] In the UI (1100), IoT devices connected to the IoT embedded middleware device (110) can be defined as Connections. The Connection display unit (1110) can display the currently connected connections. For example, the field management system (100) may be a system for managing power at an industrial site, and IoT devices such as main power, air conditioners, and lighting may be connected to the IoT embedded middleware device (110).

[0066] Messages can be defined for each connection. A message may be an element that enables access to field management data of an IoT device. The name, attributes, etc. of a message can be set through the message setting section (1120) of the UI (1100). Non-professional development personnel (132) can set messages for accessing field management data through the message setting section (1120) of the UI (1100).

[0067] FIG. 12 illustrates a tag database within an IoT embedded middleware device according to some embodiments.

[0068] Referring to FIG. 12, a tag database (1200) operating within an IoT embedded middleware device (110) and elements constituting the same may be illustrated.

[0069] The tag database (1200) may be composed of an internal register (1210) for storing source data and a metadata section (1220) that provides information for accessing the data. Based on this structure, data access and control from another external engine (1230) can be enabled through the metadata without altering the original form of the data.

[0070] A tag is a data object in which an IoT embedded middleware device (110) abstracts data into one dimension, and can be broadly classified into PDF (Pre-DeFined) tags and UDF (User-DeFined) tags. PDF tags refer to data provided by the IoT embedded middleware device (110) itself, and may include digital input or output, GPS information, time information, etc. of the IoT embedded middleware device (110) itself. The PDF tag list may be provided differently for each model of the IoT embedded middleware device (110).

[0071] UDF tags are user-defined tags that serve as variables usable during the logic programming process. They can be used to store data exchanged with connections, temporary variables for logic, and more. Tags can be classified into two types based on their volatility; tags with the suffix "_NV" are non-volatile, meaning the data associated with them is retained even if the device is powered off and then restarted.

[0072] Tags can currently include UINT16, UINT32, FLOAT32, BOOL, etc. as data types, and additionally support CHAR and array forms. As for NV types, UINT16_NV, UINT32_NV, FLOAT32_NV, and BOOL_NV forms may be provided separately.

[0073] FIG. 13 illustrates a UI of a no-code service server for generating tag data according to some embodiments.

[0074] Referring to FIG. 13, a UI (1310, 1320) of a no-code service server (130) for generating tag data can be illustrated.

[0075] The UI (1310) may display a tag manager window of the no-code service server (130). A list of currently existing tag data may be displayed on the left side of the UI (1310). For example, the list of tag data may display UDF tags such as MY_APPLICATION_TAG1.

[0076] The UI (1320) may display a window for creating new tag data or modifying existing tags. The data type, name, description, etc. of the tag data may be set through the UI (1320). Data types may include float, uint, bool, char, array, etc.

[0077] FIGS. 14 and 15 illustrate a process for collecting and managing field management data according to some embodiments.

[0078] Referring to FIG. 14, in the process of collecting and managing field management data (1410), an IoT embedded middleware device (110) can utilize tag data (1420) abstracted into one dimension, and a cloud server (120) can manage the one-dimensional tag data (1420) again into high-dimensional data (1430).

[0079] The IoT embedded middleware device (110) can collect only the necessary information from each connection at the required interval and organize it into one-dimensional data in an internal TAG DB. The IoT embedded middleware device (110) can execute real-time user logic based on data organized in the same dimension, and can reconstruct the data according to user rules and transmit it to the IoT link of the cloud server (120). Even when data is sent down from the IoT link to each connection in the field, it can operate based on the same structure.

[0080] For example, IoT devices (112, 114, 116, 118) connected to the IoT embedded middleware device (110) may be smart power meters and may provide power metering information to the IoT embedded middleware device (110) as field management data (1410). The IoT embedded middleware device (110) may abstract the field management data (1410) of the IoT devices (112, 114, 116, 118) into one dimension to generate tag data (1420), manage this as a tag database, and transmit it to a cloud server (120) via an IoT link. The cloud server (120) may further separate and manage the tag data (1420) into power data by meter.

[0081] Referring to FIG. 15, a connection 1 (1510) formed with a first IoT device, a connection 2 (1520) formed with a second IoT device, and a connection 3 (1530) formed with a third IoT device may be illustrated. For example, the first IoT device, the second IoT device, and the third IoT device may each be a main power supply, an air conditioner, and a light.

[0082] In the case of connection 1 (1510), messages for collecting field management data from the first IoT device may be provided. In this case, the field management data may be power data. Message 1 may be a command instructing to store the serial number (SN) of the first IoT device in TAG AA1. Message 2 may be a command instructing to store the current active power and reactive power being metered by the first IoT device in TAG BB1 and TAG CC1. Connections 2 (1520) and 3 (1530) may also operate in a manner similar to connection 1 (1510).

[0083] FIGS. 16 and 17 illustrate a process in which a no-code service server according to some embodiments generates control logic for an IoT embedded middleware device.

[0084] Referring to FIG. 16, a UI (1610, 1620, 1630) representing the process of a no-code service server (130) generating control logic for an IoT embedded middleware device (110) may be illustrated.

[0085] The UI (1610) may represent an interface for the no-code service server (130) to generate user logic for controlling the IoT embedded middleware device (110). User control logic can be expressed as a combination of expressions and operators and can be written in the form of a logical expression. Conditional expressions can be written through a TAG composed of a single layer (e.g., one dimension), and the written logic can support real-time control.

[0086] UI (1620) can display an expression builder window. The expression builder window can display a list of currently defined UDF tag data and can set conditional expressions, assign expressions, set expressions, etc. based on this. For example, a conditional expression such as 'GPS_SPEED > 230' can be created.

[0087] The UI (1630) may represent an operator manager window. The operator manager window may provide the ability to add operators (operators) to be combined with one or more expressions on the UI (1610). Operators may include logical operation gates, message receive / send operators, user-defined special function operators, etc. For example, through the operator manager window, 2:1 OR gates, 2:1 NOR gates, 2:1 XOR gates, 2:1 AND gates, 2:1 NAND gates, NOT gates, etc. may be supported.

[0088] Referring to FIG. 17, an expression manager (1710) and an operator manager (1720, 1730) may be illustrated as a type of interface for generating user logic to control an IoT embedded middleware device (110).

[0089] The expression manager (1710) can add tag data and operation types to the control logic. The operator manager (1720) can add various logic gate operators to the control logic. The operator manager (1730) can support an assignment operator. For example, if the 'in' input of the assignment operator is digital true, the expression of the 'from' of the assignment operator can be calculated and the result entered into the 'to' tag.

[0090] FIGS. 18 to 20 illustrate elements constituting an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments.

[0091] Referring to FIG. 18, a first form of an IoT embedded middleware-based field management system (100) using a no-code operation development framework can be illustrated. The field management system (100) of the first form can generate update information regarding structural changes in an industrial site.

[0092] An IoT embedded middleware-based field management system (100) using a no-code operation development framework may include an IoT embedded middleware device (110), a cloud server (120), a no-code service server (130), and a management server (140). However, it is not limited thereto, and some components may be omitted from the field management system (100), or other general-purpose components may be further included in the field management system (100).

[0093] The IoT embedded middleware device (110) can be configured to form connections with IoT devices at an industrial site to transmit and receive site management data. For example, in the case of a power management system, the IoT embedded middleware device (110) can collect real-time power data from smart power meters, and in the case of an electric vehicle charging management system, the IoT embedded middleware device (110) can collect battery charging data from smart battery packs and / or smart chargers.

[0094] The cloud server (120) may be configured to provide an IoT link that is utilized to access field management data in a cloud environment. For example, the cloud server (120) may have an IoT link architecture and data pipeline as illustrated in FIG. 10, and may have multiple cloud storages. Through the IoT link, the no-code service server (130) and the management server (140) may receive field management data collected by the IoT embedded middleware device (110).

[0095] The no-code service server (130) may be configured to provide an integrated operational development service that defines the control logic of the IoT embedded middleware device (110) in a no-code manner. The integrated operational development service may include a no-coding-based development service and an operation service. Through the development service, the control logic of the IoT embedded middleware device (110) can be defined even by non-specialized personnel without coding knowledge, and through the operation service, it may be possible to adjust the control logic accordingly even when structural changes occur in the industrial site.

[0096] The management server (140) may be configured to provide field management services regarding industrial sites using IoT devices based on integrated operation development services. The manager of the management server (140) may be a customer using the field management system (100) to operate their business. For example, if the field management system (100) is a power management system, the field management services operated by the management server (140) may include power usage analysis and cost reduction services. For example, the field management services may be implemented in the form of a mobile application, such as the user service (144) of FIG. 1.

[0097] According to an embodiment, the no-code service server (130) may be configured to generate update information for an IoT embedded middleware device (110) in response to structural changes in an industrial site and distribute it to the IoT embedded middleware device (110) via an IoT link. Since the IoT embedded middleware device (110) may not operate correctly with existing control logic when the structure of the industrial site changes, the no-code service server (130) may support non-specialized development personnel in generating update information to resolve this.

[0098] According to an embodiment, a no-code service server (130) may be configured to receive no-code user development logic corresponding to structural changes in an industrial site, generate an update file corresponding to the user development logic based on a code generator and a build engine, and provide the update file to an IoT embedded middleware device (100) via OTA. More specifically regarding this, reference may be made to the aforementioned FIGS. 6 to 8.

[0099] According to an embodiment, when an IoT embedded middleware device (110) forms a new connection with an additional IoT device that is different from the IoT devices already connected at an industrial site, the operator of the site management service is configured to provide a no-code user-developed logic that reflects the change in the connection structure to a no-code service server (130), and the no-code service server may be configured to generate an update file that enables access to the site management data of the additional IoT device. For example, if a smart power meter is additionally installed at an industrial site, such an OTA update process may be performed to enable control of the additional meter.

[0100] According to an embodiment, the cloud server (120) may include a plurality of cloud storages for storing field management data distributed into real-time data and historical data by configuring a data processing pipeline, and the cloud server (120) may be configured to provide real-time data and historical data through the data processing pipeline in response to a request from the management server (140). For example, if the field management system (100) is a power management system, the real-time data may include current metering values ​​of smart power meters, and the historical data may include accumulated data of past metering values ​​of smart power meters.

[0101] According to the embodiment, IoT devices include smart power meters installed at an industrial site, and field management data includes power data collected from the smart power meters. Field management services provided by the management server (140) include power management services based on the power data of the smart power meters. The power management services may include a real-time service that provides real-time power status based on real-time data and a statistical analysis service that provides statistical analysis of past power usage history based on historical data. In this regard, the aforementioned portion of FIG. 10 may be referenced more specifically.

[0102] Referring to FIG. 19, a second form of an IoT embedded middleware-based field management system (100) using a no-code operation development framework can be illustrated. The field management system (100) of the second form can generate tag data based on field management data.

[0103] According to an embodiment, connections formed between IoT devices and an IoT embedded middleware device (110) may be configured to transmit and receive field management data in two or more different data formats by two or more different communication methods, and the IoT embedded middleware device (110) may be configured to provide tag data with a unified data format of field management data to the IoT link. For example, connections with IoT devices may use Zigbee, Modbus, CAN communication, Bluetooth, Bluetooth Low Energy (BLE), etc., as shown in FIG. 3. Although they utilize different data formats, the IoT embedded middleware device (110) may generate tag data with a unified data format. For example, the unified data format may include data abstracted in one dimension.

[0104] According to an embodiment, an IoT embedded middleware device (110) may include a tag database for storing tag data, and the tag database may include an internal register for storing original values ​​of field management data and a metadata section for storing metadata information for accessing original values, and a management server (140) may be configured to receive tag data via an IoT link and access original values ​​of field management data based on metadata information. In this regard, reference may be made to the aforementioned portion of FIG. 12.

[0105] According to the embodiment, the tag data may include pre-defined (PDF) tag data provided by the IoT embedded middleware device (110) itself and user-defined (UDF) tag data defined by an operator of the field management service during the process of programming control logic using the integrated operation development service. The IoT embedded middleware device (110) may be configured to manage at least some of the tag data as non-volatile (NV) data that is retained even when the power of the IoT embedded middleware device (110) is lost. For example, the PDF tag data may include digital input or output of the IoT embedded middleware device (110) itself, GPS information, time information, etc. The UDF tag data may include tag data newly defined by an operator of the management server (140) during the process of generating update information in response to structural changes in the industrial site.

[0106] According to an embodiment, an IoT embedded middleware device (110) may be configured to generate tag data for at least some of the periodic report items among the field management data items periodically collected from IoT devices, and to generate periodic report data abstracted into one dimension for the tag data for the periodic report items and provide it to a cloud server (120). The cloud server (120) may be configured to reconstruct the periodic report data abstracted into one dimension to generate connection-specific report data and to provide the connection-specific report data to a management server (140). For example, as shown in FIG. 14, the IoT embedded middleware device (110) may generate tag data (1420) abstracted into one dimension, and the cloud server (120) may manage this again as connection-specific high-dimensional data (1430).

[0107] According to an embodiment, control logic programmed by an operator of a field management service using an integrated operation development service is generated by a no-code service server (130) to include one or more messages regarding data access for each of the connections with IoT devices, and one or more messages may include commands instructing an IoT embedded middleware device (110) to collect some of the field management data from each of the IoT devices and store it as tag data. In this regard, reference may be made to FIG. 15 described above.

[0108] Referring to FIG. 20, a second form of an IoT embedded middleware-based field management system (100) using a no-code operation development framework can be illustrated. The third form of the field management system (100) can generate control logic based on input values ​​from integrated operation development.

[0109] According to an embodiment, a no-code service server (130) may be configured to receive input values ​​for generating at least one operator block and input values ​​for generating at least one target block from an operator of a field management service, and to generate control logic for an IoT embedded middleware device (110) based on a combination of at least one operator block and at least one target block. An operator of a field management service provided by a management server (140) may transmit input values ​​through a UI such as that shown in FIG. 16 and FIG. 17, and control logic may be generated based thereon. For example, a target block may be displayed as a rectangular block in the UI (1610) of FIG. 16.

[0110] According to an embodiment, at least one operation target block may include i) a conditional block that outputs a result of 0 or 1 depending on whether a conditional statement is satisfied, ii) at least one operator block, iii) a set block that sets a specific variable at a node of a logic circuit combining at least one operation target block, and iv) an assign block that assigns a specific value to a target variable. The conditional block may be primarily utilized on the input side of the operator block, and the set block and the assign block may be primarily utilized on the output side of the operator block.

[0111] According to an embodiment, at least one operator block may include: i) a logic gate block that outputs a logic value based on the result of one or more conditional blocks; ii) an action block that performs a predefined operation based on input values; iii) a message reading block that instructs to read the field management data from any one of the IoT devices; iv) a message transmission block that instructs to transmit the input value to the cloud server; and v) an assignment block that generates a given operation result as tag data when the input value corresponds to a logic value of 1. For example, the action block may perform a specific function operation specified by a user. For the message reading block, reference may be made to FIG. 15 described above. For the assignment block, reference may be made to the operator manager (1730) of FIG. 17 described above.

[0112] According to an embodiment, a no-code service server (130) may be configured to generate user code corresponding to a combination of at least one operator block and at least one operation target block using a code generator, and to generate a binary file corresponding to the user code using a build engine. For the process of generating a binary file (530) corresponding to a combination of at least one operator block and at least one operation target block, reference may be made to the aforementioned part of FIG. 5.

[0113] According to an embodiment, the no-code service server (130) may be configured to upload a binary file to cloud storage within the cloud server (120) and provide the upload address of the cloud storage to the IoT embedded middleware device (110), and the IoT embedded middleware device (110) may be configured to download the binary file from the upload address of the cloud storage while performing an integrity check on the binary file. For the method of performing an integrity check on the binary file (530) and downloading it through the upload address of the cloud storage (122), reference may be made to FIG. 7 described above.

[0114] FIG. 21 illustrates a method of operation for an IoT embedded middleware-based field management system using a no-code operation development framework according to some embodiments.

[0115] Referring to FIG. 21, the operation method (2100) of an IoT embedded middleware-based field management system using a no-code operation development framework may include steps (2110) to (2140). However, it is not limited thereto, some steps may be omitted or other general steps may be added, and the steps of the operation method (2100) may be executed in a different order than the illustrated order.

[0116] The operation method (2100) may consist of steps processed sequentially in a field management system (100) based on IoT embedded middleware using a no-code operation development framework. Therefore, even if the details are omitted below, the description of the field management system (100) above may be equally applicable to the operation method (2100).

[0117] Steps (2110) to (2140) of the operation method (2100) can be performed by the IoT embedded middleware device (110), cloud server (120), no-code service server (130), and management server (140) of the field management system (100).

[0118] In step (2110), the field management system (100) based on IoT embedded middleware using a no-code operation development framework can perform the step of transmitting and receiving field management data by forming a connection with IoT devices at an industrial site through an IoT embedded middleware device.

[0119] In step (2120), the field management system (100) based on IoT embedded middleware using a no-code operation development framework can perform the step of providing an IoT link that is utilized to access field management data in a cloud environment through a cloud server.

[0120] In step (2130), the field management system (100) based on IoT embedded middleware using a no-code operation development framework can perform the step of providing an integrated operation development service that defines the control logic of the IoT embedded middleware device in a no-code manner through a no-code service server.

[0121] In step (2140), the field management system (100) based on IoT embedded middleware using a no-code operation development framework can perform the step of providing field management services for industrial sites using IoT devices based on integrated operation development services through a management server.

[0122] According to an embodiment, the operation method (2100) of an IoT embedded middleware-based field management system using a no-code operation development framework can be implemented in the form of a computer program stored on a computer-readable storage medium. That is, the computer program may include instructions for implementing the operation method (2100), and the instructions of the program may be stored on a computer-readable storage medium. The computer program may include a mobile application.

[0123] According to an embodiment, a computer-readable storage medium may include magnetic media such as a hard disk, a floppy disk, and a magnetic tape, optical media such as a CD-ROM and a DVD, magneto-optical media such as a floptical disk, and a hardware device specifically configured to store and execute computer program instructions such as ROM, RAM, and flash memory. Computer program instructions may include machine code generated by a compiler and high-level language code that can be executed by a computer using an interpreter, etc.

[0124] Although embodiments of the present invention have been described in detail above, the scope of rights according to the present invention is not limited thereto, and various modifications and improvements by those skilled in the art using the basic concept of the present invention as described in the following claims should also be interpreted as being included within the scope of rights according to the present invention. Explanation of the symbols

[0125] 100: Field Management System 110: IoT Embedded Middleware Device 120: Cloud Server 130: No-Code Service Server 140: Management Server

Claims

Claim 1 In an IoT embedded middleware-based field management system using a no-code operational development framework, the system comprises: an IoT embedded middleware device configured to form connections with IoT devices at an industrial site to transmit and receive field management data; a cloud server configured to provide an IoT link utilized to access the field management data in a cloud environment; a no-code service server configured to provide an integrated operational development service that defines the control logic of the IoT embedded middleware device in a no-code manner; and a management server configured to provide a field management service regarding the industrial site using the IoT devices based on the integrated operational development service....including, and connections formed between the IoT devices and the IoT embedded middleware device are configured to transmit and receive the field management data in two or more different data formats by two or more different communication methods; the IoT embedded middleware device is configured to provide tag data with a unified data format of the field management data to the IoT link; it includes a tag database for storing the tag data; the tag database includes an internal register for storing the original values ​​of the field management data and a metadata section for storing metadata information for accessing the original values; the management server is configured to receive the tag data through the IoT link and access the original values ​​of the field management data based on the metadata information; the tag data includes PDF (pre-defined) tag data provided by the IoT embedded middleware device itself and UDF (user-defined) tag data defined during the process of an operator of the field management service programming the control logic using the integrated operation development service; and the IoT embedded middleware device [requires] at least a portion of the tag data when the power of the IoT embedded middleware device is lost An IoT embedded middleware-based field management system using a no-code operational development framework configured to manage non-volatile (NV) data that is retained even in such cases. Claim 2 delete Claim 3 delete Claim 4 A field management system based on IoT embedded middleware using a no-code operational development framework, wherein, in claim 1, the IoT embedded middleware device is configured to generate tag data for at least some of the periodic reporting items among the field management data items periodically collected from the IoT devices, generate periodic reporting data abstracted into one dimension for the tag data for the periodic reporting items, and provide it to the cloud server, and the cloud server is configured to reconstruct the periodic reporting data abstracted into one dimension to generate connection-specific reporting data and provide the connection-specific reporting data to the management server. Claim 5 In claim 4, the control logic programmed by the operator of the field management service using the integrated operation development service is generated by the no-code service server to include one or more messages regarding data access for each of the connections with the IoT devices, and the one or more messages include commands instructing the IoT embedded middleware device to collect some of the field management data from each of the IoT devices and store it as tag data, an IoT embedded middleware-based field management system using a no-code operation development framework.

Images