An MQTT Server infrastructure comprises an MQTT Server in operable communication with at least one of the following: a SCADA/IIoT host; a plurality of MQTT EoN Nodes; and a plurality of Sparkplug applications. The MQTT Server infrastructure provides alert and metrics on key system status indicators, system errors, and performance issues for the Sparkplug open-source specification into an MQTT Server to provide a richer system awareness of connected MQTT clients.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to U.S. Provisional Patent Application 62/942,438 filed on Dec. 2, 2019, entitled “SPARKPLUG-AWARE MQTT SERVER” the entire disclosure of which is incorporated by reference herein.

TECHNICAL FIELD

The embodiments generally relate to network infrastructures and more specifically relate to a Sparkplug-aware MQTT Server.

BACKGROUND

MQ telemetry transport (MQTT) is an open OASIS and ISO standard lightweight, publish-subscribe network protocol that transports messages between devices. The protocol usually runs over TCP/IP, but any network protocol that provides ordered, lossless, bi-directional connection can support MQTT. The MQTT protocol was developed and designed for connections with remote locations where a small code footprint is required, or the network bandwidth is limited.

The MQTT protocol defines two type of network entities. First is a message server (aka broker) which is a server that receives all messages from the clients and then routes the messages to the appropriate destination clients. The second type of network entity is a client, which is any devices that runs an MQTT library and connects to an MQTT Server over a network which can then publish and/or subscribe to messages.

MQTT was originally designed as a message transport protocol for real-time supervisory control and data acquisition (SCADA) systems. The MQTT message transport specification does not specify the Topic Namespace to use nor does it define the Payload representation of the data being published and/or subscribed to. There is no are mechanisms defined to provide the state of an MQTT session such that SCADA/Control HMI applications can monitor the current state of any MQTT client in the infrastructure. The way state information is implemented and managed within the MQTT infrastructure (e.g., Topic Namespace and Payload) is not defined. In order for MQTT-based solutions to be interoperable within a given market sector or applied MQTT deployment, the Topic Namespace, Payload representation, and session state must be defined.

Sparkplug provides an open and freely available specification for how Edge of Network (EON) gateways or native MQTT enabled end devices and MQTT applications communicate bi-directionally within an MQTT infrastructure. Many MQTT brokers (i.e., MQTT servers) exist which act as an MQTT message broker and are not aware of the MQTT message content as defined by the Sparkplug specification which is an open source specification under the purview of the Eclipse Software Foundation. This leaves users of the system unaware of system metrics and potential system problems. In such, all existing MQTT servers lack the ability to have awareness of the Sparkplug specification.

SUMMARY OF THE INVENTION

This summary is provided to introduce a variety of concepts in a simplified form that is further disclosed in the detailed description of the embodiments. This summary is not intended to identify key or essential inventive concepts of the claimed subject matter, nor is it intended for determining the scope of the claimed subject matter.

The embodiments disclosed herein relate to an MQTT Server infrastructure comprising an MQTT Server in operable communication with at least one of the following: a SCADA/IIoT host; a plurality of MQTT EoN Nodes; and a plurality of Sparkplug applications. The MQTT Server infrastructure provides storage, alerts, notifications, reporting, and metrics on key system status indicators, system errors, and performance issues for the Sparkplug open source specification into an MQTT Server to provide a richer system awareness of connected MQTT Sparkplug clients. The way in which alerts, notifications, and reporting is done includes but is not limited to storage of pertinent Sparkplug events and metrics in a database, delivery using websockets, delivery using REST, delivery and display to a webpage, delivery using the MQTT protocol, delivery using other network based protocols, display using SCADA ‘tag system software’, delivery using text messaging, and delivery using email.

The MQTT server infrastructure is capable of understanding the Sparkplug structure and can add additional features to create a rich MQTT ecosystem with system insight and system overview, while providing MQTT clients with a framework to integrate data.

In one aspect, the MQTT server infrastructure receives a plurality of messages from a client and routes each message to the appropriate destination client.

In one aspect, the MQTT Server infrastructure provides the ability to detect, store, and report MQTT Sparkplug Clients with a duplicate Sparkplug Group ID and Edge Node ID.

In one aspect, the MQTT Server infrastructure has the ability to store Sparkplug metric properties within the MQTT Server query the MQTT Server infrastructure to allow the MQTT Server to introspect on Sparkplug NBIRTH and DBIRTH messages passing through the system such that the system may store the Sparkplug birth messages and make them accessible to clients and via API's for future use. This information would be accessible but not limited to REST calls, the Websocket protocol, and other network-based protocols such as MQTT. In addition, these queries could provide filtering options to limit the specific information returned to the caller.

In one aspect, the MQTT Server infrastructure provides internal tracking, storing, and reporting of Sparkplug-specific data flowing through the MQTT Server to permit Sparkplug metric counts, Sparkplug sequence number errors, Sparkplug template definition collisions, and Sparkplug historical metrics, and other Sparkplug specific information available to the MQTT Server.

In one aspect, the MQTT Server system tracks and reports online/offline MQTT Sparkplug Nodes and primary SCADA/IIoT Host applications to permit the MQTT Server to track Sparkplug clients connected to the MQTT Server. This includes binding, storing, and reporting additional pertinent information to the MQTT Client such as the source IP address, the Sparkplug Group ID, the Sparkplug Edge Node ID, and/or the SCADA/IIOT Host's primary host ID of each Sparkplug EoN Client.

In one aspect, the plurality of MQTT Sparkplug Nodes, which are offline vs online will be tracked, stored, and reported. This includes tracking, storing, and reporting of connection uptime/downtime, connection lost events, and reasons for connection loss when applicable.

In one aspect, the MQTT Server infrastructure provides Sparkplug compression sampling to allow the MQTT Server to perform an analysis of Sparkplug messages passing through the MQTT Server to see if compression is increasing or reducing overall bandwidth.

In one aspect, the MQTT Server system provides tracking of MQTT Sparkplug Nodes that are not subscribing on primary host ID.

In one aspect, the MQTT Server infrastructure provides tracking of timeout configurations and potential misconfigurations of the MQTT Will Message in the context of the plurality of Sparkplug applications. In addition, the MQTT Server will track Sparkplug bdSeq numbers on a per EoN Node basis. This is will allow for detection, storage, and reporting of misconfigured Sparkplug EoN Nodes with regard to ‘session state’ compliance.

In one aspect, the MQTT Server infrastructure provides ACL configuration based on Sparkplug topic tokens including the Group ID and/or Edge Node ID.

DETAILED DESCRIPTION

The specific details of the single embodiment or variety of embodiments described herein are to the described system and methods of use. Any specific details of the embodiments are used for demonstrative purposes only, and no unnecessary limitations or inferences are to be understood therefrom.

As used herein the term “MQTT Edge of Network (EoN) Node(s)” refers to any compliant MQTT Client application that manages an MQTT Session and provides the physical and/or logical gateway functions required to participate in the Topic Namespace and Payload definitions.

As used herein, the term “MQTT Enabled Device (Sparkplug)” refers to any MQTT-enabled device which connects to the MQTT infrastructure using a compliant MQTT connection with the payload and topic notation as described herein.

As used herein, the term “SCADA/IIoT Host” refers to any MQTT client application that subscribes to and publishes messages as described herein. The SCADA/IIoT Host typically aggregates data from the Sparkplug Nodes and optionally provides control of the Sparkplug Nodes.

As used herein, the term “MQTT Application Node” is any non-primary MQTT SCADA/IIoT client application that consumes real-time messages or any other data being published with proper permission and security.

As used herein, the term “MQTT Sparkplug Client” refers to a SCADA/IIoT host, a MQTT EoN Node(s), or a Sparkplug application.

In general, the embodiments described herein provide alert and metrics on key system status indicators, system errors, and performance issues for the Sparkplug open-source specification into an MQTT Server to provide a richer system awareness of connected MQTT Sparkplug Clients. The embodiments provide a richer insight into the overall systems configuration, performance, and security as well as providing the functionalities of an MQTT Server. The platform is flexible and configurable to permit modules to be plugged and unplugged for various functions.

The MQTT server may operate as an application on-premise or in the cloud ecosystem for high availability applications. This allows the server to be transported across any platform that and includes an updated user interface and web-based administration. The MQTT server may also be used as a MQTT server or broker in any SCADA system.

FIG. 1illustrates a block diagram of the infrastructure components100. One or more MQTT server(s)105are present in the infrastructure. The use of multiple MQTT servers105for redundancy, high availability, and scalability within any given infrastructure is possible. One or more MQTT Edge of Network (EoN) Node(s)110,115,120,125are each responsible for any local protocol interface to existing legacy devices (e.g., PLCs, RTUs, Flow Computers, Sensors, etc.) and/or any local discrete I/O, and/or any logical internal process variables. One or more devices130,135,140,145and one or more sensors150represents any physical or logical device connected to the MQTT EoN node providing any data, process variables, or metrics. One or more MQTT enabled device(s) (Sparkplug)155,160,165directly connect to the MQTT infrastructure using a compliant MQTT 3.1.1 connection with the payload and topic notation as described herein. The SCADA/IIoT host170may include one primary host responsible for the monitoring and control of a given group of MQTT EoN nodes110,115,120,125. Sparkplug may support the notion of multiple critical host applications which will not preclude any number of additional MQTT SCADA/IIot nodes110,115,120,125participating in the infrastructure that are in either pure or monitoring mode, or in the role of a hot standby should the primary MQTT SCADA/IIoT host go offline.

FIG. 2illustrates a block diagram of the general message flow200comprising the MQTT server(s)105and the MQTT EoN Node(s)110,115,120,125. Any MQTT Client can connect to the MQTT Server105without any notion of other MQTT Client applications that are connected and can issue subscriptions to any MQTT messages that it might be interested in as well as start publishing any message containing data that it has.

In some embodiments, the MQTT Server system provides the ability to detect, store, and report collisions between duplicate Sparkplug Group ID and Edge Node ID collisions across multiple MQTT Clients. In the Sparkplug infrastructure, any two MQTT EoN clients must have a unique combination of Group ID and Edge Node ID. If they do not, it can be problematic for consuming applications to handle their incoming messages because the consuming application cannot tell which incoming message is the “correct” client. In such, the MQTT Server system detects, stores, and reports these collisions by reporting the Group ID, MQTT EoN nodes ID, and the IP addresses of the clients involved in the collision.

In some embodiments, the MQTT Server system has the ability to store Sparkplug metric properties within the MQTT Server and make it queryable to allow the MQTT Server to introspect on Sparkplug “Birth” messages passing through the system such that the system may store the Sparkplug birth messages and make them accessible to applications for future use. These could be MQTT clients or other network-based applications such as REST, Websocket, or Web-based clients. This information would be accessible but not limited to REST calls, the Websocket protocol, and other network-based protocols such as MQTT. In addition, these queries could provide filtering options to limit the specific information returned to the caller.

In some embodiments, the MQTT Server system provides internal tracking, storing, and reporting of Sparkplug-specific data flowing through the MQTT Server to permit Sparkplug metric counts, Sparkplug sequence number errors, Sparkplug template definition collisions, and Sparkplug historical metrics.

In some embodiments, the MQTT Server system tracks and reports online/offline MQTT Edge Nodes and primary SCADA/IIoT Host applications (i.e., birth counts, death counts, State messages, and timing) to permit the MQTT Server to track Sparkplug clients connected to the MQTT Server. This permits tracking of “producer client” Edge Nodes and “consuming client” host applications. Metrics that may be tracked and reported may comprise Sparkplug birth counts, Sparkplug death counts, and online/offline times for Edge Node Clients. The metrics may also comprise State message, current State, and online/offline times as well as the retained status of the State message.

In some embodiments, Sparkplug clients that are going offline often are tracked and reported. The frequency at which the offline status is reported may be a parameter defined by the user.

In some embodiments, the MQTT Server system provides Sparkplug compression sampling to allow the MQTT Server to perform an analysis of Sparkplug messages passing through the MQTT Server to see if compression is increasing or reducing overall bandwidth.

In some embodiments, the MQTT Server system provides tracking of Edge Nodes that are not subscribing on the primary host ID which they should be. The MQTT server is the component of the distributed system that uniquely knows the subscriptions of each MQTT Sparkplug Client. Because of this, the MQTT Server could know both whether or not MQTT Sparkplug Clients are subscribed to the Sparkplug “State” messages. In addition, it could know if “State” messages were being published by a host system. With this information it would be possible to report Sparkplug EoN Nodes that were not subscribed on the primary host State topic and possibly should be.

In some embodiments, the MQTT Server system provides tracking of long keep alive timeout configurations and potential misconfigurations of MQTT Will Message in the context of Sparkplug applications. The Sparkplug specification requires MQTT clients to register in the MQTT Connect packet and that it be of a certain form. This feature would permit the MQTT Server to detect Edge Nodes and/or consuming host applications that did not properly implement the MQTT Will Message portion of the specification and report it.

In some embodiments, the MQTT Server system provides ACL configuration based on Sparkplug topic tokens. Existing Access Control List (ACL) configurations for MQTT Servers allow for configuration of ACLs based on topics using MQTT wildcard characters. However, since the Sparkplug topic namespace is well defined using Group ID, Edge Node ID, Device ID, and Sparkplug verbs, ACLs that control publishing and subscribing on topics could be made simpler to configure using these Sparkplug tokens as qualifiers. This feature will allow configuration of ACLs based on Sparkplug topic tokens rather than by generic MQTT topics with wildcards.

In some embodiments, system security may be managed with username/password authentication, TLS, and access control lists (ACL's) user authentication protocols.