Edge automation system with unified specification

Abstract

The invention discloses an edge automation system with a unified specification, and relates to the technical field of Internet of Things, the edge automation system comprises a plurality of controllers, the plurality of controllers are connected and communicated through a control network, each controller comprises a plurality of software components, and the plurality of software components are communicated through a TLP message protocol. Message types of communication among the plurality of software components are divided into request messages, response messages and event messages, through a standardized communication protocol and an authority control mechanism, an interoperability problem among the Internet of Things devices is effectively solved, a feasible solution is provided for realizing real Internet of everything, and the method is suitable for all the Internet of Things devices and has a wide application prospect. The messages can be connected to the gateway and identified by the gateway, various services can be realized, and the messages among the services can be mutually identified.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet of Things, and in particular to an edge automation system with unified specifications. Background Art

[0002] In the current IoT field, edge system technology has not yet formed a unified specification system. Due to the lack of standardized guidelines, various manufacturers and developers often use different methods and protocols when designing and implementing IoT devices.

[0003] Due to the lack of unified specifications, IoT devices have large differences in data processing, communication protocols, security mechanisms, etc. This not only increases the compatibility issues between devices, but also brings huge challenges to system integration and maintenance. Devices produced by different manufacturers often require separate adaptation and debugging, which not only consumes a lot of time and resources, but also limits the widespread application and rapid development of IoT technology. To this end, we propose an edge automation system with unified specifications. Summary of the invention

[0004] The purpose of the present invention is to solve the problem that due to the lack of unified specifications, there are large differences in data processing, communication protocols, security mechanisms, etc. in IoT devices. This not only increases the compatibility issues between devices, but also brings huge challenges to the integration and maintenance of the system. Devices produced by different manufacturers often require separate adaptation and debugging, which not only consumes a lot of time and resources, but also limits the widespread application and rapid development of IoT technology. The present invention provides an edge automation system with unified specifications.

[0005] In order to achieve the above-mentioned purpose, the present invention specifically adopts the following technical solutions:

[0006] An edge automation system with unified specifications includes multiple controllers, the multiple controllers are connected and communicated through a control network, the controllers include multiple software components, and the multiple software components communicate through a TLP message protocol, and the message types communicated between the multiple software components are divided into request messages, response messages and event messages. The request message is that the software component can subscribe to a message path to monitor all messages sent to the path, the response message is that the software component can also send a request to a message path and expect to receive a result on the monitored response path, and the event message is that the software component can broadcast an event on a message path, and all components subscribed to the message path will receive the broadcast event message.

[0007] Furthermore, the TLP message protocol regards each message path as a resource address, and explicitly defines the following types of operations, which are mainly used to implement permission control. Specifically, the GET operation is used to read the resource content, and this operation will not cause any changes to the resource content; the PUT operation is used to update the resource content, in which case the resource can be modified or replaced; the POST operation is used to create a new sub-item or partially modify the resource content, which can add a new resource item or partially modify an existing resource; finally, the DELETE operation is used to delete resources, and its main function is to remove the specified resource, thereby implementing the resource deletion operation. Through these operation types, the TLP message protocol can effectively control the permissions of resources and ensure the security and integrity of resources.

[0008] Furthermore, each of the messages consists of a message address, a message header and a message body.

[0009] Furthermore, the message address is a string that uniquely identifies the destination or source of the message, and has the following format:

[0010] / MP / 1.0 / <contro l l er I d> / components / <component I d> / (services|events|results) / <servi ce I d> / [...].

[0011] in,<contro l l er I d> It is the unique identifier of the controller in the network.<component I d> is a unique identifier of a software component within the controller,<servi ce I d> Is a unique identifier for the service within the scope of the controller.

[0012] Furthermore, there are three types of message addresses, and the corresponding values ​​of the three types of addresses and devices are as follows: component service address / components / <component I d> / services / <servi ce I d> / ...、Build a broadcast address

[0013] / components / <component I d> / events / <serv i ce I d> / ...、Response address

[0014] / components / <component I d> / resul ts / <servi ce I d> / ...

[0015] Furthermore, the message header contains description information of the message, which is expressed in the form of a key-value pair and is divided into message headers of a request message, a response message and an event message.

[0016] Furthermore, the role-based access control (RBAC) mechanism in the message header adds role information. When each software component sends a request message, it must include its role information in the message header. The system decides whether to allow the component to access the target resource address based on the role information and preset permission rules.

[0017] Furthermore, the message body carries the specific content of the message, and its encoding format is determined by the contentType in the message header. The message body uses content as the field name.

[0018] Furthermore, the TLP message protocol supports the use of MQTT (Message Queue Telemetry Transport Protocol) or HTTP as the bearer protocol. When using MQTT, the message address is the Topic of the MQTT message, the message body uses content as the field name, and the Payload of the MQTT message is placed in the same way as the message header field. The message header and the message body are encoded with CBOR and placed in the Payload of the MQTT message. When using HTTP, the message address is the HTTP URL, the message body uses content as the field name, and the Body of the HTTP request is placed in the same way as the message header field. The message header and the message body are encoded with CBOR and placed in the Body of the HTTP request.

[0019] Furthermore, the software component supports message encryption and digital signature functions.

[0020] The beneficial effects of the present invention are as follows:

[0021] 1. The edge automation system with unified specifications proposed in the present invention effectively solves the interoperability problem between IoT devices through standardized communication protocols and permission control mechanisms, and provides a feasible solution for realizing the true "Internet of Everything". It is applicable to all IoT devices, allowing them to connect to the gateway and be recognized by the gateway, and can realize various services. The messages between services can be mutually recognized.

[0022] 2. The present invention combines the TLP message protocol with the HTTP or MQTT 3.1.1 protocol, which not only improves the real-time performance and reliability of the system, but also ensures the security of communication. This combination provides strong support for efficient and secure communication between IoT devices, and further promotes the development and application of IoT technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a system block diagram of the present invention. DETAILED DESCRIPTION

[0024] To make the purpose, technical solution and advantages of the embodiments of the present invention more clear, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0025] Embodiment 1:

[0026] See also Figure 1 The present invention provides an edge automation system with unified specifications, including multiple controllers, multiple controllers are connected and communicated through a control network, multiple software components are included in the controller, and multiple software components communicate through a TLP message protocol, and the message types communicated between the multiple software components are divided into request messages, response messages and event messages, the request message is that the software component can subscribe to a message path to monitor all messages sent to the path, the response message is that the software component can also send a request to a message path and expect to receive a result on the monitored response path, and the event message is that the software component can broadcast an event on a message path, and all components subscribing to the message path will receive the broadcast event message.

[0027] In this embodiment, preferably, the TLP message protocol regards each message path as a resource address, and explicitly defines the following types of operations, which are mainly used to implement permission control. Specifically, the GET operation is used to read the resource content, and this operation will not cause any changes to the resource content; the PUT operation is used to update the resource content, in which case the resource can be modified or replaced; the POST operation is used to create a new sub-item or partially modify the resource content, and this operation can add a new resource item or partially modify an existing resource; finally, the DELETE operation is used to delete resources, and its main function is to remove the specified resource, thereby implementing the resource deletion operation. Through these operation types, the TLP message protocol can effectively perform permission control on resources and ensure the security and integrity of resources.

[0028] In this embodiment, preferably, each of the messages is composed of a message address, a message header and a message body; through this structured message format, accurate transmission and processing of information can be effectively achieved.

[0029] In this embodiment, preferably, the message address is a string that uniquely determines the destination or source of the message, and the format is as follows:

[0030] / MP / 1.0 / <contro l l er I d> / components / <component I d> / (services|events|results) / <servi ce I d> / [...].

[0031] in,<contro l l er I d> Represents the unique identifier of the controller in the network, which can clearly identify the controller to which the message is destined.<component I d> It is an identifier that uniquely identifies a software component within the scope of the controller, which can help us accurately locate a specific software component.

[0032] <servi ce I d> It is an identifier that uniquely identifies a service within the scope of the controller, which ensures that the message can be accurately sent to a specific service. Through this format, we can ensure that the delivery of messages is highly accurate and reliable.

[0033] In this embodiment, preferably, there are three types of message addresses, and the values ​​corresponding to the three types of addresses and devices are as follows: component service address / components / <component I d> / services / <servi ce I d> / ...、Build broadcast address / components / <component I d> / events / <servi ce I d> / ...、Response address

[0034] / components / <component I d> / resul ts / <servi ce I d> / ...

[0035] In this embodiment, preferably, the message header contains description information of the message, which is expressed in the form of a key-value pair and is divided into message headers of a request message, a response message and an event message.

[0036] The message header contains detailed information about the message. This information is represented in the form of key-value pairs, making the structure of the message clearer and easier to understand. Specifically, the message header can be divided into three categories: request message header, response message header, and event message header. The request message header usually contains information about the operation or request that the sender wants the receiver to perform, and the response message header contains the response to the request message, indicating whether the request is successful and the related processing results. The event message header is used to describe specific events that occurred in the system so that the receiver can understand them in time and make corresponding processing. Through this classification and key-value pair representation, the transmission and processing of messages become more efficient and orderly.

[0037] The message header of the request message is as follows:

[0038]

[0039] illustrate:

[0040]

[0041] The response message header is as follows:

[0042]

[0043]

[0044] illustrate:

[0045]

[0046] The event message header is as follows:

[0047]

[0048] illustrate:

[0049]

[0050] In this embodiment, preferably, the role-based access control (RBAC) mechanism in the message header adds role information. When each software component sends a request message, it must include its role information in the message header. The system decides whether to allow the component to access the target resource address based on the role information and preset permission rules.

[0051] In this embodiment, preferably, the message body carries the specific content of the message, and its encoding format is determined by the contentType in the message header, and the message body uses content as the field name.

[0052] The contentType field in the message header specifies the encoding method of the message body content, thereby ensuring that the recipient can correctly parse the data in the message body. In addition, the message body uses content as its field name, which is concise and easy to understand and process. In this way, we can flexibly process different types of message content while ensuring the integrity and accuracy of the data.

[0053] In this embodiment, preferably, the software component supports message encryption and digital signature functions.

[0054] Message encryption usually uses symmetric encryption or asymmetric encryption algorithms, and digital signatures are implemented using asymmetric encryption algorithms combined with hash functions.

[0055] 1. Message encryption:

[0056] -Symmetric encryption: Use the same key to encrypt and decrypt messages, such as the AES algorithm.

[0057] -Asymmetric encryption: Use a public key to encrypt messages and a private key to decrypt them, such as the RSA algorithm.

[0058] 2. Digital Signature:

[0059] -Generate signature: Use the private key to encrypt the hash value of the message and generate a digital signature.

[0060] -Verify the signature: Use the public key to decrypt the digital signature, get the hash value, and compare it with the hash value of the message.

[0061] The software component integrates the above encryption and signature algorithms to support users to encrypt and sign when sending messages, thereby ensuring the confidentiality and integrity of the messages.

[0062] When the system is used, first, the user sets the parameters of each controller through the configuration interface, including controller ID, software component ID, and service ID, etc. These parameters will be stored in the local database of the controller and used to generate a unique resource address.

[0063] When a software component needs to communicate with another software component, it builds a corresponding message based on the type of request (request message, response message, or event message) that needs to be sent. For example, if component A needs to request data from component B, component A will build a request message, specify the resource address of the target component B, and put the request content in the message body.

[0064] The message is sent to the target component B through the control network. After receiving the message, component B parses the message body according to the contentType in the message header. If the message is a request message, component B will perform corresponding operations according to the request content, such as reading resource content, updating resource content, etc., and send the result back to component A through a response message. If the message is an event message, component B will perform a broadcast operation and send the event information to all components that have subscribed to the event path.

[0065] In terms of system integration and maintenance, since all components follow the unified TLP message protocol, compatibility between devices from different manufacturers can be easily achieved. Developers only need to develop software components according to unified specifications to achieve seamless integration between different devices. This greatly reduces the complexity and maintenance costs of system integration, and provides a solid foundation for the widespread application and rapid development of IoT technology.

[0066] In short, the TLP message protocol is a "request-response" and broadcast message transmission mechanism provided for software components. The protocol meets the service call requirements across processes and networks, and supports asynchronous notification of events. The edge automation system with unified specifications proposed by the present invention effectively solves the interoperability problem between IoT devices through standardized communication protocols and permission control mechanisms, and provides a feasible solution for realizing the true "Internet of Everything". It is applicable to all IoT devices, allowing them to connect to the gateway and be recognized by the gateway, and can realize various services. The messages between services can be mutually recognized. For example, an automation engine, image recognition service, user management service, permission management service, etc. can be written based on this message.

[0067] Embodiment 2:

[0068] In this embodiment, preferably, the TLP message protocol supports the use of MQTT (Message Queue Telemetry Transport Protocol) or HTTP as the bearer protocol. When using MQTT, the message address is the Topic of the MQTT message, the message body uses content as the field name, and the Payload of the MQTT message is placed in the same way as the message header field, and the message header and the message body are CBOR-encoded and placed in the Payload of the MQTT message. When using HTTP, the message address is the HTTP URL, the message body uses content as the field name, and the Body of the HTTP request is placed in the same way as the message header field, and the message header and the message body are CBOR-encoded and placed in the Body of the HTTP request.

[0069] Using MQTT 3.1.1 can further improve the real-time performance and reliability of the system. MQTT is a lightweight message transmission protocol that is particularly suitable for environments with limited bandwidth or unstable network conditions. By using MQTT, the system can achieve efficient message transmission, reduce network latency, and ensure timely delivery of critical data.

[0070] The Topic ic design of MQTT follows the address format consistent with the TLP message protocol, ensuring the accuracy of message routing and distribution. For example, when component A needs to send a request message to component B, it will construct an address that complies with the TLP message protocol and convert it to the Topic ic format of MQTT. Component B subscribes to the corresponding Topic ic, so that it can receive the message sent by component A.

[0071] In addition, the MQTT protocol supports QoS (Quality of Service) levels, allowing the system to select different message transmission guarantee levels based on actual needs. For example, for messages that require high reliability, you can select QoS level 2 to ensure that the message is received at least once. For scenarios with high real-time requirements, you can select QoS level 1 to ensure that the message is received at most once, thereby reducing the delay in message transmission.

[0072] In terms of security, in this embodiment, the MQTT protocol is combined with the encryption and digital signature mechanism of the TLP message protocol to further enhance the security of communication. Even when using the MQTT protocol, the system can still ensure the confidentiality and integrity of the message and prevent the data from being stolen or tampered with during transmission.

[0073] In summary, by combining the TLP message protocol with the HTTP or MQTT 3.1.1 protocol, not only the real-time performance and reliability of the system are improved, but also the security of communication is guaranteed. This combination provides strong support for efficient and secure communication between IoT devices, and further promotes the development and application of IoT technology.

[0074] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An edge automation system with unified specifications, characterized by: The invention comprises a plurality of controllers, wherein the plurality of controllers are connected and communicated through a control network, the controllers comprise a plurality of software components, and the plurality of software components communicate through a TLP message protocol, and the message types communicated between the plurality of software components are divided into request messages, response messages and event messages, wherein the request message means that the software component can subscribe to a message path to monitor all messages sent to the path, the response message means that the software component can also send a request to a message path and expect to receive a result on the monitored response path, and the event message means that the software component can broadcast an event on a message path, and all components subscribing to the message path will receive the broadcasted event message.

2. The edge automation system with unified specifications according to claim 1, characterized in that: The TLP message protocol treats each message path as a resource address and explicitly defines the following types of operations: The GET operation is used to read resource content. This operation does not make any changes to the resource content. The PUT operation is used to update resource content. In this way, resources can be modified or replaced. The POST operation is used to create a new sub-item or partially modify the resource content. This operation can add a new resource item or partially modify an existing resource. Finally, the DELETE operation is used to delete resources. Its main function is to remove the specified resource, thereby realizing the resource deletion operation.

3. The edge automation system with unified specifications according to claim 1, characterized in that: Each of the messages consists of a message address, a message header and a message body.

4. The edge automation system with unified specifications according to claim 3, characterized in that: The message address is a string that uniquely identifies the destination or source of the message, and has the following format: / MP / 1.0 / <controllerid> / components / <componentid> / (services|events|results) / <serviceid> / [...]< / serviceid> < / componentid> < / controllerid> in, <controllerid>It is the unique identifier of the controller in the network. <componentid>is a unique identifier of a software component within the controller, <serviceid> Is a unique identifier for the service within the scope of the controller.< / serviceid> < / componentid> < / controllerid> 5. The edge automation system with unified specifications according to claim 4, characterized in that: There are three types of message addresses. The corresponding values ​​of the three types of addresses and devices are as follows: Building service address / components / <componentid> / services / <serviceid> / ...、Build a broadcast address< / serviceid> < / componentid> / components / <componentid> / events / <serviceid> / ...、Response address< / serviceid> < / componentid> / components / <componentid> / results / <serviceid> / ...。< / serviceid> < / componentid> 6. The edge automation system with unified specifications according to claim 3, characterized in that: The message header contains description information of the message, which is expressed in the form of key-value pairs and is divided into message headers of request messages, response messages and event messages.

7. The edge automation system with unified specifications according to claim 6, characterized in that: The role-based access control (RBAC) mechanism in the message header adds role information. When sending a request message, each software component must include its role information in the message header. The system decides whether to allow the component to access the target resource address based on the role information and preset permission rules.

8. The edge automation system with unified specifications according to claim 3, characterized in that: The message body carries the specific content of the message, and its encoding format is determined by the contentType in the message header. The message body uses content as the field name.

9. The edge automation system with unified specifications according to claim 1, characterized in that: The TLP message protocol supports the use of MQTT (Message Queue Telemetry Transport Protocol) or HTTP as a bearer protocol; When using MQTT, the message address is the Topic of the MQTT message, the message body uses content as the field name, and is placed in the Payload of the MQTT message like the message header field. The message header and message body are encoded with CBOR and placed in the Payload of the MQTT message. When using HTTP, the message address is the HTTP URL, the message body uses content as the field name, and is placed in the Body of the HTTP request like the message header field. The message header and message body are encoded with CBOR and placed in the Body of the HTTP request.

10. The edge automation system with unified specifications according to claim 1, characterized in that: The software component supports message encryption and digital signature functions.

Images