Programmable logic controller with internet-of-things function

Abstract

The invention discloses a programmable logic controller with an internet of things function, and relates to the technical field of industrial control, and the programmable logic controller comprises a programmable logic controller body which is used for executing a logic control task; and the internet of things function engine is integrated in a software system of the programmable logic controller body and is used for establishing network connection with a proxy server and executing data reporting and subscribing tasks according to variable configuration and service configuration files issued by an upper computer based on the proxy server. The system does not need to depend on external gateway equipment, has the capability of being directly connected with an Internet of Things platform or a cloud data center, and reduces the deployment cost of small and medium-sized Internet of Things control scenes and the learning threshold of PLC engineers.

Description

Technical Field

[0001] This application relates to the field of industrial control technology, and in particular to a programmable logic controller with built-in Internet of Things (IoT) functionality. Background Technology

[0002] In the field of industrial control, Programmable Logic Controllers (PLCs) are widely used in automation control. However, traditional PLCs do not have the ability to communicate directly with IoT platforms or cloud data centers. Typically, additional IoT terminal devices or gateway devices are required for data interaction, with the PLC acting only as a terminal for data collection. This approach has certain advantages in scenarios with a large number of terminal devices and large amounts of data. However, when the number of terminal devices is small (such as in field equipment scenarios), introducing gateway devices leads to high costs, and the programming and configuration of gateways introduces additional learning costs for PLC engineers, reducing the flexibility and cost-effectiveness of system deployment. Summary of the Invention

[0003] The purpose of this application is to provide a programmable logic controller with built-in IoT functionality, which does not rely on external gateway devices and has the ability to directly connect to IoT platforms or cloud data centers, thereby reducing the deployment cost of small and medium-sized IoT control scenarios and the learning threshold for PLC engineers.

[0004] To achieve the above objectives, this application provides a programmable logic controller with built-in IoT functionality, comprising: a programmable logic controller body for performing logic control tasks; and an IoT function engine integrated into the software system of the programmable logic controller body for establishing a network connection with a proxy server and, based on the proxy server, performing data reporting and subscription tasks according to variable configurations and business configuration files issued by a host computer.

[0005] In one embodiment, the variable configuration is used to map physical elements of the programmable logic controller body to named variables in the Internet of Things (IoT) scenario.

[0006] In one embodiment, the variable configuration is encoded using CBOR format.

[0007] In one embodiment, the IoT function engine establishes a network connection with the broker server via the MQTT protocol; the business configuration file includes a custom MQTT configuration, a data group load configuration, and a cloud data center reporting configuration; the custom MQTT configuration includes connection parameters and connection load configuration for a custom MQTT broker server; the data group load configuration includes the configuration for assembling variables into MQTT message payloads in a custom MQTT scenario; the cloud data center reporting configuration includes the variables, reporting modes, and business parameters that need to be reported when connecting to a specific cloud data center.

[0008] In one embodiment, the IoT function engine includes: a variable table parser for parsing and storing variable configurations issued by the host computer; a client module for establishing and maintaining a network connection with the proxy server; and an engineering executor for parsing the business configuration file issued by the host computer and driving the client module to execute corresponding data reporting and subscription tasks according to the business configuration file.

[0009] In one embodiment, the engineering executor includes: a cloud data center engineering executor, used to report and subscribe to data with a specific cloud data center according to a predefined cloud data center application layer protocol based on a business configuration file issued by a host computer; and a custom engineering executor, used to connect to a custom proxy server according to a business configuration file issued by a host computer, and report and subscribe to data with the custom proxy server.

[0010] In one embodiment, the IoT function engine further includes a TLS communication module for conducting TLS encrypted communication with the proxy server.

[0011] In one embodiment, the IoT function engine and the host computer use the TFTP protocol to transfer configuration files.

[0012] In one embodiment, the triggering modes for data reporting include, but are not limited to, timed reporting, triggered reporting, change reporting, and flow-saving reporting; wherein, timed reporting is periodically triggered data reporting, triggered reporting is triggered when the state of a specified component changes, change reporting is triggered when the value of a specified variable changes, and flow-saving reporting is reporting only the change amount within a period.

[0013] In one implementation, the priority of the data reporting and subscription task is lower than the priority of the logic control task.

[0014] According to the specific embodiments provided in this application, this application achieves the following technical effects: By directly integrating the IoT function engine into the software system of the programmable logic controller (PLC), no additional external IoT communication module is required, effectively simplifying the device hardware structure, reducing the deployment cost and space occupancy rate of the device in industrial control scenarios, and avoiding communication compatibility issues between external modules and the controller itself, ensuring the coordinated and stable operation of logic control and IoT communication. The variable configuration and business configuration files issued by the host computer can flexibly match the personalized needs of different industrial control scenarios, allowing for rapid adjustment of IoT business logic without modifying the controller hardware, significantly improving the intelligence level and remote control capabilities of the device. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of a programmable logic controller with built-in IoT functionality, provided as an embodiment of this application.

[0017] Figure 2 A schematic diagram of the secure connection and authentication process in one embodiment of this application.

[0018] Figure 3 This is a schematic diagram illustrating the login connection process between a programmable logic controller with built-in IoT functionality and the cloud, as provided in one embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The purpose of this application is to provide a programmable logic controller with built-in IoT functionality. This PLC does not rely on external gateway devices and has the ability to directly connect to IoT platforms or cloud data centers. It aims to reduce the deployment cost of small and medium-sized IoT control scenarios and the learning threshold for PLC engineers, and supports multiple data reporting formats and working modes through flexible configuration methods.

[0021] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] In one exemplary embodiment, such as Figure 1 As shown, a programmable logic controller with built-in IoT functionality is provided, including: a programmable logic controller body and an IoT function engine.

[0023] The programmable logic controller (PLC) body is used to perform logic control tasks. The PLC body contains traditional component areas (such as V, M, X, Y).

[0024] The IoT function engine is integrated into the software system of the programmable logic controller. The IoT function engine is used to establish a network connection with the agent server and, based on the agent server, execute data reporting and subscription tasks according to the variable configuration and business configuration file issued by the host computer.

[0025] Among them, the IoT function engine can establish a network connection with the agent server through the Message Queuing Telemetry Transport (MQTT) protocol, the Hypertext Transfer Protocol (HTTP), or the Constrained Application Protocol (CoAP).

[0026] In addition, variable configurations and business configuration files can be stored and downloaded in common formats such as Extensible Markup Language (XML) or JavaScript Object Notation (JSON).

[0027] In a specific application example, the IoT function engine and the host computer use the Trivial File Transfer Protocol (TFTP) to transfer configuration files. Compared to more complex file transfer protocols such as FTP and HTTP, the TFTP protocol stack is simple to implement and has extremely low resource consumption, making it very suitable for the characteristics of industrial PLC embedded environments. This ensures the stability and efficiency of the configuration download process without consuming valuable PLC operating resources. The host computer provides a graphical interface for configuring IoT functions and generating various configuration files to download to the PLC.

[0028] In a specific application example, the IoT function engine establishes a network connection with the broker server via the MQTT protocol. The broker server in this case is an MQTT broker server. The IoT function engine includes: a variable table parser, an MQTT client module, a project executor, and a TLS communication module.

[0029] The variable table parser is used to parse and store the variable configurations issued by the host computer. These variable configurations map the physical components of the programmable logic controller (PLC) to named variables in the IoT scenario. The variable configurations are encoded using Concise Binary Object Representation (CBOR) format to form the variable table. Compared to text formats like JSON, CBOR, as a binary format, has significant advantages in PLC embedded environments: firstly, the encoded data size is smaller, reducing network transmission load and storage space usage; secondly, the parsing speed is faster, reducing the load on the PLC's main CPU; and thirdly, the RAM usage of lightweight libraries like tinycbor is much lower than that of libraries like cJSON, which is crucial for memory-constrained industrial controllers, ensuring stable and coordinated operation of IoT and logic control functions.

[0030] The variable table is generated by the PLC IoT tool and is a format agreed upon by the PLC IoT tool, PLC kernel, and cloud platform. It is used to describe how to redefine PLC components (bit components, register components) and describe them as "scada variables" with "scada data type". In the custom MQTT function and the data reporting function of the specified cloud data center, the variable ID is used as the addressing reference for addressing. The field definitions of the variable table are shown in Table 1.

[0031] Table 1. Variable Table Field Definitions

[0032] The MQTT client module is used to establish and maintain a network connection with the MQTT broker server.

[0033] The engineering executor is used to parse the business configuration file issued by the host computer and drive the MQTT client module to execute corresponding data reporting and subscription tasks according to the business configuration file. The business configuration file includes custom MQTT configuration, data group load configuration, and cloud data center reporting configuration.

[0034] Custom MQTT configuration includes customizing the connection parameters of the MQTT broker server (such as address, port, authentication information) and connection load balancing.

[0035] Data group load configuration includes the configuration of assembling variables into MQTT message loads in custom MQTT scenarios, supporting JSON format (such as {"variable name": variable value}) and HEX raw data stream format.

[0036] The cloud data center reporting configuration includes the variables, reporting modes, and business parameters that need to be reported when connecting to a specific cloud data center.

[0037] In a specific application example, the engineering executor includes: a cloud data center engineering executor and a custom MQTT engineering executor.

[0038] The cloud data center engineering executor is used to report and subscribe to data with a specific cloud data center according to the business configuration file issued by the host computer and the predefined cloud data center application layer protocol.

[0039] Specifically, in the cloud data center scenario, the PLC control topics shown in Table 2 are used to realize the interaction between the agreed topics and the cloud data center.

[0040] Table 2 PLC Control Topics

[0041] This includes support for state synchronization based on the will topic: When the PLC connects, it configures the plc / v / onlineState / device ID topic as a will message. When the connection is abnormally disconnected, the Broker automatically publishes this message, enabling the cloud to detect device offline in a timely and reliable manner, thus achieving state consistency between the cloud and edge modules.

[0042] Atomic reporting of login and variable tables: Device login requests (plc / v / login) and project metadata (variable tables) are reported in the same message payload. This eliminates the "window period" after a device comes online, when its data point structure is not yet known to the cloud. It ensures that the cloud can correctly receive, parse, and process all subsequent data reports from the moment the connection is established, thus improving data integrity.

[0043] The custom MQTT project executor is used to connect to the custom MQTT broker server according to the business configuration file issued by the host computer, and to report and subscribe to data with the custom MQTT broker server.

[0044] Specifically, the interaction with a specific MQTT broker server is defined through the front-end page. This defines how to publish data in a specified format to the publishing topic according to the given configuration, and how to subscribe to and parse formatted data in a specified topic according to the given configuration. Upon receiving the subscription information, data in the specified format is published to the receipt topic. The process is as follows: (1) Dynamic configuration loader: This loader adopts an on-demand loading mechanism, loading only the configuration file corresponding to the data group currently being processed into RAM for execution, and unloading it immediately after processing, thereby achieving efficient and reliable scheduling of multi-data group tasks in a limited memory environment.

[0045] For custom MQTT scenarios, the host computer can generate multiple independent data group configurations. During PLC execution, each data group is processed sequentially in a loop: load configuration A -> execute A (read variables, frame, publish) -> unload A -> load configuration B -> execute B -> ... and so on. Here, A and B are two data groups. Through dynamic configuration loading and memory management mechanisms, the PLC achieves multi-channel, scalable IoT communication capabilities—previously requiring gateways or high-end controllers—on a single-chip microcontroller-level hardware resource, achieving a breakthrough balance between cost and performance.

[0046] (2) Generate load: In the custom MQTT scenario, the data group load configuration supports two modes: JSON structured mode and HEX raw stream mode.

[0047] In HEX mode, the PLC directly concatenates the raw binary data of selected variables into a load, achieving zero-overhead format conversion and providing advanced users with an ultimate bandwidth optimization solution. During deployment, the PLC directly concatenates the raw binary values ​​of these variables in memory according to the configured order to form the load. This process requires no data format conversion, achieving extremely high transmission efficiency (bandwidth utilization approaching 100%) and extremely low CPU overhead, making it specifically designed for bandwidth-sensitive systems or systems with custom binary parsing capabilities.

[0048] In JSON mode, the PLC provided in this application supports fully customizable MQTT topic names and user-defined JSON key-value pairs or HEX raw streams. This eliminates the need for customized development; the PLC can be directly connected to any public or private cloud providing standard MQTT access services, such as Alibaba Cloud IoT Platform, AWS IoT Core, or Tencent Cloud IoT Development Platform, simply through graphical configuration on a host computer. This breaks down the integration barriers between traditional industrial equipment and IT cloud platforms. Finally, the variables in the PLC are filled into the corresponding positions in the JSON text, generating JSON data which is then published to the specified MQTT topic payload.

[0049] In addition, the data reporting payload format is not limited to JSON and HEX, but can also be extended to support XML, Protocol Buffers, etc.

[0050] The TLS communication module is used for encrypted communication with the MQTT broker server using Transport Layer Security (TLS). Specifically, the secure connection and authentication mechanism of this application supports both static certificate mode and dynamic token mode. Static certificate mode is used for customized MQTT scenarios. Users download the required CA certificate, client certificate, and private key along with the project to the PLC file system via a host computer to establish a TLS encrypted connection. Dynamic token mode is used for specific cloud data center scenarios. The PLC has a built-in unique device identifier. During connection, it first interacts with the cloud authentication server via HTTP protocol, submitting the device identifier for legitimacy verification. After successful verification, the cloud issues a device-specific access token and TLS certificate materials. The PLC obtains and stores these materials before establishing a secure connection with the MQTT Broker. This mechanism achieves dynamic device-level security authentication, enabling one device, one key.

[0051] like Figure 2 As shown, after the PLC powers on and starts, it checks if the certificate file exists. If it does not exist, it requests a certificate from the HTTP authentication server. If it exists, it connects to the MQTT proxy server and checks if the MQTT connection is successful. If the connection is successful, normal communication occurs. If the connection fails, it requests a certificate from the HTTP server. After requesting a certificate from the HTTP server, it checks if the server verification is valid. If valid, it returns the MQTT certificate and connects to the MQTT server. If invalid, it returns a certificate acquisition failure message and re-requests a certificate from the HTTP server.

[0052] Furthermore, to ensure the real-time performance of the PLC's core control functions, the PLC software runs on a real-time operating system. The IoT function engine operates as an independent task or thread, with its data reporting and subscription tasks having a lower priority than the PLC's logic control tasks. Through the operating system's priority scheduling, it is ensured that under any circumstances, network communication delays or blockages will not affect the PLC's real-time control of field devices, achieving reliable coexistence of control and IoT functions within a single device.

[0053] This application supports multiple intelligent reporting trigger modes to balance data real-time performance and network traffic, including but not limited to scheduled reporting, triggered reporting, change reporting, and data saving reporting.

[0054] Among them, timed reporting refers to periodically triggered data reporting, that is, sending data at fixed time intervals.

[0055] The reporting mode is triggered when the state (0->1 or 1->0) of a specified element (such as a register) changes. This mode is suitable for event-driven applications.

[0056] Change reporting is triggered when the value of a specified variable changes. For register elements, users can set a "change dead zone". Reporting is only triggered when the absolute value of the difference between the current value of the variable and the last reported value exceeds this change dead zone. This mode effectively filters sensor noise or small fluctuations and greatly reduces meaningless data transmission.

[0057] Provincial flow reporting only reports changes within a period. Specifically, variables are checked at fixed intervals (e.g., 1000ms), but only variables that have changed within the current period (or whose changes exceed the dead zone) are reported. This mode combines periodic reporting with change reporting, achieving ultimate flow optimization while ensuring data timeliness.

[0058] The workflow of the programmable logic controller with built-in IoT functionality provided in this application is as follows: Configuration phase: Users define variables and complete business scenario configuration through the host computer, generate business configuration files, and download them to the PLC.

[0059] Execution phase: (1) After the PLC is powered on, the IoT function engine starts.

[0060] (2) For custom MQTT scenarios: The custom MQTT project executor connects to the specified MQTT broker server according to the business configuration file, and automatically frames (JSON or HEX format) the variable values ​​in the variable configuration according to the data group load configuration and publishes them to the specified topic; at the same time, it subscribes to the downlink topic to receive instructions or data write requests from the cloud.

[0061] (3) For cloud data center scenarios: The cloud data center engineering executor interacts with the cloud data center according to a set of predefined application layer protocols agreed upon with the cloud data center, based on the business configuration file. This protocol utilizes multiple dedicated MQTT topics to achieve a complete functional loop, such as: logging in and reporting engineering information through the plc / v / login topic; reporting variable data through the plc / v / valueUp / deviceID topic; receiving data write instructions from the cloud through the plc / v / valueDown / deviceID topic; and implementing commands and control through the plc / v / cmd / deviceID and plc / v / cmdResp / deviceID topics.

[0062] Specifically, such as Figure 3The login connection process between the PLC and the cloud, as shown, includes: After the PLC powers on, it connects to the MQTT proxy server, enters the login process, and checks the status of the variable table: If the variable table has not been reported or has been updated, it sends a login request containing the variable table to the cloud; if the variable table has been reported but not updated, it sends a login request without the variable table to the cloud. Upon receiving the login request, the cloud starts basic services, overwrites or updates the variable table, and sends a "login successful" command to the PLC, waiting for a response. If the PLC receives the command within the timeout period, it sends a "login successful" confirmation to the cloud and starts the full service. The cloud starts the full service upon receiving the PLC's response. If the PLC does not receive the command within the timeout period, it retryes the login. The cloud includes a cloud data center and a defined MQTT proxy server.

[0063] Compared with the prior art, this application has the following advantages: (1) High integration and reduced cost: The IoT function is built into the PLC, eliminating the need for external gateway hardware, which significantly reduces the equipment cost and deployment complexity of small and medium-sized application scenarios.

[0064] (2) Simple configuration and easy to use: PLC engineers can quickly realize data upload to the cloud without learning complex network programming through the graphical host computer tool, and the learning cost is low.

[0065] (3) High flexibility: It supports connecting to public cloud (custom MQTT) and specific private cloud (cloud data center) at the same time, and supports two data load formats, JSON and HEX, to adapt to diverse IoT application needs.

[0066] (4) Full functionality and high reliability: In particular, for interaction with cloud data centers, a complete communication protocol based on MQTT topics has been designed, realizing full-link functions such as login, authentication, data uplink and downlink, and command control, ensuring the reliability and real-time performance of communication.

[0067] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0068] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0069] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A programmable logic controller with built-in Internet of Things (IoT) functionality, characterized in that, The programmable logic controller with built-in IoT functionality includes: The programmable logic controller (PLC) itself is used to perform logic control tasks; The IoT function engine is integrated into the software system of the programmable logic controller. It is used to establish a network connection with the agent server and, based on the agent server, execute data reporting and subscription tasks according to the variable configuration and business configuration file issued by the host computer.

2. The programmable logic controller with built-in IoT functionality according to claim 1, characterized in that, The variable configuration is used to map the physical components of the programmable logic controller body to named variables in the Internet of Things scenario.

3. The programmable logic controller with built-in IoT functionality according to claim 1, characterized in that, The variable configurations are encoded using CBOR format.

4. The programmable logic controller with built-in IoT functionality according to claim 1, characterized in that, The IoT function engine establishes a network connection with the agent server via the MQTT protocol; the business configuration file includes custom MQTT configuration, data group load configuration, and cloud data center reporting configuration. The custom MQTT configuration includes custom MQTT broker server connection parameters and connection load configuration; The data group load configuration includes the configuration for assembling variables into MQTT message loads in a custom MQTT scenario; The cloud data center reporting configuration includes the variables, reporting modes, and business parameters that need to be reported when connecting to a specific cloud data center.

5. The programmable logic controller with built-in IoT functionality according to claim 1, characterized in that, The IoT function engine includes: The variable table parser is used to parse and store the variable configurations issued by the host computer. The client module is used to establish and maintain a network connection with the proxy server; The engineering executor is used to parse the business configuration file issued by the host computer and drive the client module to perform corresponding data reporting and subscription tasks according to the business configuration file.

6. The programmable logic controller with built-in IoT functionality according to claim 5, characterized in that, The engineering actuator includes: The cloud data center engineering executor is used to report and subscribe to data with a specific cloud data center according to the business configuration file issued by the host computer and in accordance with the predefined cloud data center application layer protocol. A custom project executor is used to connect to a custom proxy server based on the business configuration file issued by the host computer, and to report and subscribe to data with the custom proxy server.

7. The programmable logic controller with built-in IoT functionality according to claim 1, characterized in that, The IoT function engine also includes: The TLS communication module is used for TLS encrypted communication with the proxy server.

8. The programmable logic controller with built-in IoT functionality according to claim 1, characterized in that, The IoT function engine and the host computer use TFTP to transfer configuration files.

9. The programmable logic controller with built-in IoT function according to claim 1, characterized in that, The triggering modes for data reporting include, but are not limited to, timed reporting, triggered reporting, change reporting, and flow-saving reporting; wherein, timed reporting is periodically triggered data reporting, triggered reporting is triggered when the state of a specified component changes, change reporting is triggered when the value of a specified variable changes, and flow-saving reporting is reporting only the change amount within a period.

10. The programmable logic controller with built-in IoT functionality according to claim 1, characterized in that, The priority of the data reporting and subscription tasks is lower than the priority of the logical control tasks.

Images