Patent Description:
Industrial automation systems are managed and operated using automation control and monitoring systems, particularly in industrial automation environments. Such applications may include the powering of a wide range of actuators, such as valves, electric motors, and so forth, and the collection of data via sensors. Automation control and monitoring systems may include one or more components, such as programming terminals, automation controllers, input/output (I/O) modules, communication networks, human-machine interface (HMI) terminals, and the like to control operations of the industrial automation systems.

Generally, communication systems are deployed in industrial automation systems to permit industrial automation devices to communicate with the control and monitoring systems. However, some industrial automation systems are limited in control of devices by hardwired connections or programmed communicative pathways. These hardwired connections or programmed communicative pathways may be time-consuming to maintain and difficult to deal with when replacing components or adding new components into the system, since rewiring is sometimes performed to make room for new components. Furthermore, respective control systems and/or monitoring systems may each translate signals from industrial automation devices at intake, causing system-wide repetition of translation operations. These translation operations may be inefficient since each control and monitoring system receiving data from the industrial automation device may repeat the same (or similar) translation. As such, improved systems and methods for translation operations of an industrial automation system are desirable.

<CIT> relates to an apparatus that includes a first interface configured to communicate over a first industrial process control network using a first protocol. The apparatus also includes a second interface configured to communicate over a second industrial process control network using a second protocol. The apparatus further includes a third interface configured to communicate with at least one supervisory device over a third network. In addition, the apparatus includes at least one processing device configured to provide concurrent access for the at least one supervisory device to process control devices coupled to the first and second industrial process control networks during a migration of process control devices that use the first protocol to process control devices that use the second protocol.

<CIT> relates to techniques for allowing at least one second device configured to use a second communication protocol to communicate with at least one first field device configured to use a first communication protocol. An apparatus includes a first network communication arrangement configured to communicate with the at least one first field device using the first communication protocol, a second network communication arrangement configured to communicate with the at least one second device using the second communication protocol, and a device emulation processing arrangement configured to emulate the at least one first field device such that the at least one second device may communicate with the emulated at least one first field device using a third communication protocol.

<CIT> relates to a technique for enabling intelligence at an edge. The technique includes triggering by sensor data in a software layer hosted on either a gateway device or an embedded system. The software layer is connected to a local-area network. A repository of services, applications, and data processing engines is made accessible by the software layer. Matching the sensor data with the semantic descriptions of occurrence of specific conditions through an expression language made available by the software layer. Automatic discovery of pattern events by continuously executing expressions. Intelligently composing services and applications across the gateway device and embedded systems across the network managed by the software layer for chaining applications and analytics expressions. Optimizing the layout of the applications and analytics based on resource availability. Monitoring the health of the software layer. Storing of raw sensor data or results of expressions in a local time-series database or cloud storage. Services and components can be containerized to ensure smooth running in any gateway environment.

In one embodiment, a system is disclosed according to claim <NUM>.

In another embodiment, a method is disclosed according to claim <NUM>.

In yet another embodiment, a non-transitory computer-readable storage medium is disclosed according to claim <NUM>.

These and other features, aspects, and advantages of the present disclosure may become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:.

The present disclosure is generally directed toward a broker system disposed in an industrial automation system that may receive data from an industrial automation device and transmit the data to a control system. Communication systems are sometimes deployed in industrial automation systems to support the communication of data between control systems and industrial automation devices. However, some industrial automation systems are limited to using hardwired connections or certain specific communication protocols (e.g., wired or wireless) to transmit or receive data from devices. These physical or wireless communicative couplings may be difficult or time-consuming to maintain over the lifespan of the industrial automation system, since, for example, each coupling between devices may be updated each time a replacement or a repair is made. Furthermore, when communicating information between end points that use different communication protocols, respective devices within the industrial automation system may translate signals from other devices at intake of the signals. Since each device may perform its own translation operations, repetition of the translation operations may occur. Furthermore, if one device is operating on an outdated firmware or software version and/or otherwise does not have the capability to receive communications formatted according to a protocol used by a different device, those two devices may not be able to communicate.

With this in mind, operation of the industrial automation system may improve through use of the broker system. For example, the broker system may centralize translation operations and support a publish-subscribe system of reporting between the control systems and industrial automation devices. The broker system may reduce a number of translation operations performed by leveraging a common protocol (e.g., common protocol and/or common communication format) and data storage. The broker system may also store a library of data translations to permit conversion between different formats. In this way, data from the industrial automation device may be translated to the common protocol and stored before transmission to the control system. When transmitting stored data to the control system, the broker system may translate the stored data from the common protocol into a protocol used by the control system, thereby reducing a number of translations (e.g., a total number of translations) performed by the control systems. Indeed, when the data corresponding to the stored data is subscribed to by multiple control systems, the data is translated (e.g., translated to the common protocol) once instead of multiple times by each of the multiple control systems.

Respective controls systems and respective industrial automation devices may use different communication protocols when communicating information between components of the control systems and/or industrial automation devices. The broker system may thus be capable of translating between a variety of communication protocols and the common protocol. When receiving data from the industrial automation device, the broker system may translate the received data to the common protocol and store the received data. The broker system may translate the stored data from the common protocol to a communication protocol used by the control system for analysis and control operations.

In some cases, the control system may subscribe to data received by, stored on, or accessible to the broker system. For example, the control system may subscribe to a particular type of data that is accessible to the broker systems and may automatically receive the specified type of data from the broker system. The broker system may directly transmit the data to the control system, such as through dedicated data channels coupling between the control system and the broker system.

In some cases, the broker system may communicate with the control system through a network channel. The network channel may be associated with internet protocol (IP) communications and may enable one or more devices coupled to the network channel to selectively receive information transmitted through the network channel, such as based on properties of data (e.g., an identifier of the data, metadata describing the data and transmitted with the data). In this way, the broker system may receive data from the industrial automation device, translate the data, and publish the translated data to a network channel. The control system may couple to the broker system through the network channel and determine when relevant or subscription data is transmitted through the network channel, such as based on an interpretation of the properties of the data. In some systems, however, the network channel may route data to the control system based on subscriptions of the control system, may send some or all data to the control system based on what data is transmitted to the network channel by the broker system, or the like. In any of these cases, however, data is transmitted from the industrial automation device and the control system using the broker system that is able to translate the data between communication formats of the respective components.

Sometimes the broker system may facilitate bi-directional communication between control systems and industrial automation devices. Indeed, control systems may generate data, control signals, or the like to be transmitted to industrial automation devices, such as to implement a control operation within the industrial automation system. The broker system may also transmit these communications from the control system to the industrial automation device. In this way, the control system may generate a control signal that the broker system transmits to the industrial automation device to adjust operations of the industrial automation device.

It is noted that control systems and industrial automation devices represent two examples of suitable components that may use the broker system to manage communications. However, a variety of devices may benefit from usage of broker systems in an industrial automation system. For example, control systems, human machine interfaces, motor control centers, alarm management systems, internet-of-things (IOT) component systems, manufacturing execution systems (MES), time-series data repository systems, supervisory control and data acquisition (SCADA) systems, or the like may each interact with one or more industrial automation devices via communication with the broker system.

With the foregoing in mind, the broker system may use Message Queuing Telemetry Transport (MQTT) methods with translating communications between components. The MQTT platform uses a client device (e.g., components) and a broker (e.g., the broker system) to enable intercommunications. Each outgoing communication from the client device is transmitted through the broker and routed by the broker to a different client device (e.g., node). The MQTT platform may support uni-directional and bi-directional communications, and thus may suitably implement the broker system described herein.

Indeed, the broker system may couple a variety of components that may each respectively use disparate data types and disparate communication protocols when operating. The broker system may enable communication between the variety of components due to its translation operations. Furthermore, some of the components coupled to the broker system may use uni-directional communications (e.g., single direction communications), some may use bi-directional communications (e.g., two-way communications), and some may switch based on an operational mode of the component. In this way, the broker system may provide a robust and versatile communication solution to industrial automation systems. Additional details with regard to the operations of the broker system will be described below with reference to <FIG>.

By way of introduction, <FIG> is a perspective view of an example industrial automation system <NUM> that may include a broker system to translate communications of the industrial automation system <NUM>, as described herein. The industrial automation system <NUM> include individual components controlled by an industrial control system <NUM>. The components may relate to various industrial equipment such as mixers, machine conveyors, tanks, skids, specialized original equipment manufacturer machines, and the like. The components may also be associated with devices used by the equipment such as scanners, gauges, valves, flow meters, and the like. In one embodiment, every aspect of the components may be controlled or operated by a single controller (e.g., the industrial control system <NUM>). In some embodiments, the components may include devices such as individual industrial automation components, such as controllers, input/output (I/O) modules, motor control centers, motors, human machine interfaces (HMIs), operator interfaces, contactors, starters, sensors, drives, relays, protection devices, switchgear, compressors, network switches (e.g., Ethernet switches, modular-managed, fixed-managed, service-router, industrial, unmanaged, etc.) and the like. In another embodiment, the control and operation of each aspect of the components may be distributed via multiple controllers (e.g., the industrial control system <NUM>). In addition, the industrial automation system <NUM> may include stations having machine components and/or machines to conduct a particular function within an automated process, for example, an automated assembly line. The example automated process of the industrial automation system <NUM> may begin at a station 14A used for loading objects, such as empty cans or bottles to be filled, into the industrial automation system <NUM> via a conveyor section <NUM>. The conveyor section <NUM> may transport the objects to a station 14B to perform a first action, for example, washing the empty cans and/or bottles. As objects exit from the station 14B, the conveyor section <NUM> may transport the objects to subsequent stations <NUM> to continue the manufacturing or assembly process. Clearly, for other applications, the particular system, machine components, machines, stations, and/or conveyors may be different or specially adapted to the application. In addition to the equipment described above, the industrial automation system <NUM> may also include motors, protection devices, switchgear, compressors, and the like.

One or more properties of components of the industrial automation system <NUM> may be monitored and controlled by an industrial control system <NUM> for regulating control variables. For example, sensing devices (e.g., sensors <NUM>) may monitor various properties of the industrial automation system <NUM> and generate outputs used during adjustments of the operation of the industrial automation system <NUM>. Scanners, gauges, valves, flow meters, and the like of the industrial automation system <NUM> may each generate sensing data used by the industrial control system <NUM> when determining adjustments to one or more operations of the industrial automation system <NUM>. These adjustments may be managed via control loops. For example, a control loop may include a control system of the industrial automation system <NUM> may be associated with a motor drive, and thus may receive data regarding a temperature of the motor drive and may adjust operations of the motor drive based on the temperature.

The industrial control system <NUM> may be communicatively coupled to a display/operator interface <NUM> (e.g., a human machine interface (HMI)) and to one or more devices of the industrial automation system <NUM>. The industrial control system <NUM> may represent components of the industrial automation system <NUM> through visualizations of the components on the display/operator interface <NUM>. The industrial control system <NUM> may use data transmitted by sensors <NUM> to update visualizations of the components via changing one or more indications of current operations of the components. These sensors <NUM> may be any device adapted to provide information regarding process conditions. An operator <NUM> monitoring the industrial automation system <NUM> may reference the display/operator interface <NUM> to determine various statuses, states, and/or current operations, such as when adjusting operations of the industrial automation system <NUM> and/or for a particular component.

The industrial control system <NUM> may use networked devices <NUM> in managing operation of the industrial control system <NUM>. The networked devices <NUM> may be any suitable device within the industrial automation system <NUM> that communicates a status, a data packet, an alert, or the like, to the industrial control system <NUM> and/or to other networked devices <NUM>. The networked devices <NUM> may each include processing circuitry coupled to an example sensor <NUM> that enables transmission of sensing data to the industrial control system <NUM>.

The network of the industrial control system <NUM> may be a wired network, a wireless network, or a combination of the two However, when deploying communicative couplings between components of the industrial control system <NUM>, it may be desirable to use a broker system to manage the communications. Indeed, the broker system may enable communication between components that otherwise use disparate communication protocols.

To help elaborate, <FIG> is a block diagram representation of an example network <NUM> of the industrial automation system <NUM> that includes a broker system <NUM> to manage communications between an industrial automation device <NUM> and a control system <NUM>. The broker system <NUM>, the industrial automation device <NUM>, and the control system <NUM> may each include circuitry to perform operations. For example, the broker system <NUM> may include a processor <NUM>, memory <NUM>, a communication component <NUM>, input/output ports (I/O ports) <NUM>, and the like. The industrial automation device <NUM>, the control system <NUM>, and/or any other suitable device of the industrial automation system <NUM>, may also include a processor <NUM>, memory <NUM>, communication component <NUM>, I/O ports <NUM>, or the like.

The communication component <NUM> may use wireless communication or wired communication to transmit data and/or receive data from other components, wireless networks, wired networks, or the like. For the particular example of the broker system <NUM>, the broker system <NUM> may receive information from the industrial automation device <NUM>, the control system <NUM>, or the like via the I/O port <NUM>. This wired communication protocol or wireless communication protocol may include any suitable communication protocol, such as WI-FI®, mobile telecommunications technology (e.g., 2nd generation (<NUM>), 3rd generation (<NUM>), 4th generation (<NUM>), 5th generation (<NUM>), long-term evolution (LTE)), BLUETOOTH®, near-field communications technology, and the like. The communication component <NUM> may include a network interface to enable communication via various protocols such as ETHERNET/IP®, CONTROLNET®, DEVICENET®, MODBUS®, or any other industrial communication network protocol.

The processor <NUM> may be any suitable type of computer processor or microprocessor capable of executing computer-executable code, including but not limited to one or more field programmable gate arrays (FPGA), application specific integrated circuits (ASIC), programmable logic devices (PLD), programmable logic arrays (PLA), a programmable automation controller (PAC), or any other controller that may monitor, control, and operate an industrial automation device or component The processor <NUM> may, in some embodiments, include multiple processors. The memory <NUM> may include any suitable articles of manufacture that serve as media to store processor-executable code, data, and the like. The memory <NUM> may store processor-executable code used by the processor <NUM> to perform the presently disclosed techniques.

In some cases, the broker system <NUM> may wirelessly communicate with the control system <NUM> and communicate via wired connections with the industrial automation device <NUM>. However, any combination of wired communication and wireless communication may be permitted. For example, the broker system <NUM> may transmit data using a wired connection to the control system <NUM> and may transmit data using a wireless connection to the industrial automation device <NUM>, or vice versa. Some control systems <NUM> may use wired connections to communicate with the broker system <NUM> and some control systems <NUM> may use wireless connections to communicate with the broker system <NUM>. Furthermore, some industrial automation devices <NUM> may use wired connections to communicate with the broker system <NUM> and some industrial automation devices <NUM> may use wireless connections to communicate with the broker system <NUM>.

<FIG> is a block diagram representation of another example network <NUM> of the industrial automation system <NUM>. The network <NUM> may include the broker system <NUM>. The broker system <NUM> may translate communications between one or more control devices <NUM> and one or more industrial automation devices <NUM>. It is noted that the control devices <NUM> and/or the industrial automation devices <NUM> may be similar to the control system <NUM> and/or the industrial automation device <NUM> with reference to <FIG>, and thus references to the components are used herein although not specifically called out with the discussion of <FIG>.

When using the broker system <NUM> to enhance communications in the industrial automation system <NUM>, any combination of industrial automation devices <NUM> and control devices <NUM> may communicate with each other using the broker system <NUM>. The communication may involve a transmission of data, control signals, status signals, alerts, or the like. Furthermore, communication between the components may be uni-directional, bi-directional, or multi-directional. As an example, a first industrial automation device 66A may generate a status in response to generating a voltage output (e.g., in response to the voltage output exceeding a voltage threshold). The status generated may be transmitted from the first industrial automation device 66A to the broker system <NUM>. The broker system <NUM> may translate the status from a protocol used by the first industrial automation device 66A to a common protocol, and store the status now in the common protocol in a database associated with the memory <NUM>. When the one or more control devices <NUM> request the stored status from the broker system <NUM>, the broker system <NUM> may retrieve the stored status from the memory <NUM>, translate the stored status from the common protocol to a communication protocol used by the one or more control devices <NUM>, and proceed to transmit the status (now in the communication protocol used by the one or more control devices <NUM>) to the one or more control devices <NUM> that requested the stored status.

There may be many permutations to implementing the industrial automation system <NUM> that leverages the broker system <NUM>. For example, any suitable control device may be used to communicate to any suitable industrial automation device. Any suitable communication protocol may be used to transmit and/or receive data before or after translation of the data to the common protocol. The memory <NUM> used by the broker system <NUM> to store information may be internal to the broker system <NUM> and/or may be external to the broker system <NUM>. Furthermore, in some cases, both an internal memory and an external memory may be used to store data of the broker system <NUM>.

The one or more control devices <NUM> may include devices such as the control system <NUM>, a human machine interface (HMI) <NUM>, a supervisory control and data acquisition (SCADA) system <NUM>, an alarm management system <NUM>, a time-series data repository <NUM>, a manufacturing execution supervisory (MES) system <NUM>, an internet-of-things (IOT) platform system <NUM>, a computerized maintenance management (CMMS) system <NUM>, or the like. The HMI <NUM> may be a display communicatively coupled to a processor <NUM>. The processor <NUM> may generate graphics data for presentation on the HMI <NUM>. For example, the processor <NUM> may render a graphical user interface (GUI) on the HMI <NUM> to communicate one or more data visualizations of data received from the industrial automation device <NUM> and/or a respective device of the one or more industrial automation devices <NUM>.

By way of example, the one or more industrial automation devices <NUM> may operate as part of a motor control center <NUM>. Indeed, respective devices of the industrial automation devices <NUM> may include a motor driver, a branch feeder device, a variable frequency drive, a programmable logic controller, an alternating current (AC) drive, a soft starter, a direct online starter, a metering device, or the like. In this way, a variety of operations may be permitted. For instance, the motor control center <NUM> may change one or more operations in response to processing a load, such as in response to starting a motor to complete a manufacturing operation. The change in operation of the motor control center <NUM> may generate data and the data may be transmitted to the broker system <NUM>. After the broker system <NUM> receives the data, the broker system <NUM> may translate the data and transmit translated data to one or more control devices <NUM> for use. For example, the control system <NUM> may generate control operations in response to receiving the data from the motor control center <NUM>, where the control operations may be used to guide operation of the motor control center <NUM> to establish setpoints or parameters (e.g., to correct for a deviation of operation from an expected or desired operation). However, the other control devices <NUM> may use the data to perform different operations. For example, the MES system <NUM> and/or the CMMS system <NUM> may monitor for operational changes in the motor control center <NUM> as a way to track manufacturing operations of the industrial automation system <NUM>. Since the MES system <NUM> and/or the CMMS system <NUM> may be computerized systems used in manufacturing to track and document the transformation of raw materials to finished products, tracking when a component of the motor control center <NUM> changes state may indicate to the MES system <NUM> and/or the CMMS system <NUM> a location of respective product with respect to a manufacturing process.

Other control devices <NUM> may perform similar monitoring and/or reporting operations. For example, the time-series data repository <NUM> may store data collected over time. The time-series data repository <NUM> may store temperature changes over time, voltage value changes over time, current value changes over time, audio data received over time or generated over time, pressure changes over time, output changes over time, or the like and/or any suitable sensed discrete (e.g., digital) value or suitable sensed analog dataset (e.g., values sensed over time). The SCADA system <NUM> may receive status and/or data from the industrial automation devices <NUM> and use the received statues or data to generate control operations and/or to update an HMI (e.g., HMI <NUM>) with the updated statues or data. In this way, the SCADA system <NUM> may be similar to the control system <NUM>. The IOT platform <NUM> may help form a wireless communication network between components. The IOT platform <NUM> may autonomously execute control operations and monitoring operations of interconnected devices associated with the IOT platform <NUM>. The alarm management system <NUM> may receive data and generate alarm in response to the data from the industrial automation devices <NUM> being greater than or equal to one or more alarm thresholds. These devices are merely a subset of the wide variety of control devices <NUM> that may be used to receive data from the industrial automation devices <NUM>.

In some cases, the broker system <NUM> may receive a broker system configuration <NUM>. The broker system configuration <NUM> may include an indication of a configuration of the motor control center <NUM>, such as which of the industrial automation devices <NUM> correspond to a respective operation, component template (e.g., an indication of what industrial automation devices <NUM> are included in the motor control center <NUM> and corresponding setpoints and/or configurations for the industrial automation devices), or the like. The broker system <NUM> may create a model based on the broker system configuration <NUM>. The model may link particular industrial automation devices <NUM> to particular operations, component templates, or the like associated with the broker system <NUM>. The broker system configuration <NUM> may also provide publish relationships or subscribe relationships to the broker system <NUM> beyond the indications provided to the broker system <NUM> from respective control devices <NUM>. In this way, the broker system <NUM> may be configured before or after being coupled to one or more control devices <NUM>. Indeed, as may be appreciated, information stored by the broker system <NUM>, included in the broker system configuration <NUM>, or otherwise accessible by the broker system <NUM> may be leveraged by the broker system <NUM> to provide a physical unit model of the components associated with and/or communicating via the broker system <NUM>.

As may be appreciated, many suitable arrangements and configurations may be enabled at least in part by the broker system <NUM>. In some cases, for example, the HMI <NUM> may update a displayed icon in response to a control signal generated by the broker system <NUM> for transmission to the industrial automation device 66A. The control signal may be generated by the broker system <NUM> in response to data transmitted from the control system <NUM>, alarm management system <NUM>, SCADA system <NUM>, or the like, such as in response to determining sensed data received from the broker system <NUM> is greater than a threshold value (or is less than a threshold value). In this way, the HMI <NUM> may update a status or the display icon in response to the control system <NUM>, the alarm management system <NUM>, the SCADA system <NUM>, or the like, transmitting data to the broker system <NUM>. Indeed, the HMI <NUM> may subscribe to the broker system <NUM> to receive data transmitted from the control system <NUM>, the alarm management system <NUM>, the SCADA system <NUM>, or the like.

To elaborate further on communications facilitated by the broker system <NUM>, <FIG> is a flowchart of a method <NUM> for enabling communication via the broker system <NUM>. The method <NUM> may be performed by the broker system <NUM> to permit the industrial automation devices <NUM> to communicate with control devices <NUM>. However, for ease of explanation, an exemplary industrial automation device 66A and control system <NUM> may be described as communicating via operations of the method <NUM> performed by the broker system <NUM>. Although the method <NUM> is described below as being performed by the broker system <NUM>, it should be understood that any suitable control device, such as the industrial control system <NUM>, may perform the method <NUM>. Moreover, although the following description of the method <NUM> is described in a particular order, it should be understood that the method <NUM> may be performed in any suitable order.

At block <NUM>, the broker system <NUM> may receive data that may be in a first format from the industrial automation device 66A. The data may include status data, sensing data, or any suitable type of data. Furthermore, the data may be communicated to the broker system <NUM> according to any suitable communication protocol and having any suitable data type, such as WI-FI®, mobile telecommunications technology (e.g., 2nd generation (<NUM>), 3rd generation (<NUM>), 4th generation (<NUM>), 5th generation (<NUM>), long-term evolution (LTE)), BLUETOOTH®, near-field communications technology, and the like. The communication component <NUM> may include a network interface to enable communication via various protocols such as ETHERNET/IP®, CONTROLNET®, DEVICENET®, MODBUS®, or any other industrial communication network protocol. For example, the broker system <NUM> may receive the data from the industrial automation device 66A formatted according to industrial protocol (IP) communications, FIELDBUS® communications, fiber optic communications, wireless communications, wired communications, multi-point interface communications, distributed network protocols, standard-defined protocols, or the like. Furthermore, the broker system <NUM> may receive analog signals and/or digital signals from the industrial automation device 66A. In this way, the data from the industrial automation device 66A may be of a variety of data types, including integer type, floating-point type, string type, Boolean type, nothing type (e.g., null or NaN data), or the like. The data received from the industrial automation device 66A may correspond to one or more sensed values, such as voltage values, current values, pressure values, temperature values, humidity values, flow rate values, or any suitable type of data. Indeed, for example, the data received from the industrial automation device 66A may also include status information, such as whether a device is in a fault state or is otherwise undesirably operating or desirably operating.

In response to receiving at least some of the data from the industrial automation device 66A, at block <NUM>, the broker system <NUM> may convert the data from a protocol used by industrial automation device 66A to a common protocol. The common protocol may be a protocol, like a common industrial protocol, used to translate data between data types. The common protocol may be of any protocol type. It is noted that a format of data may be at least partially based on or inclusive of protocols used to communicate the data, the type of data, or the like, where when translating data between formats may involve an adjustment to an amplitude, phase, noise level, data type, communication protocol, or the like from an original format.

At block <NUM>, the broker system <NUM> may store the data, now common protocol data (e.g., the data of a first format is translated to the common protocol to generate the common protocol data), in memory, such as the memory <NUM>, storage, or the like. In some cases, the broker system <NUM> may be associated with a redundancy storage system, where the common protocol data stored in the memory <NUM> may be backed up in one or more databases, additional memory, or the like configurable as redundant storage of the redundancy storage system. Indeed, the broker system <NUM> may receive data from a variety of industrial automation devices over a period of time and may store the data from each device in its memory <NUM> or other suitable storage component.

At block <NUM>, the broker system <NUM> may receive a request from the control system <NUM> requesting for data from an industrial automation device associated with a parameter. In response to receiving the request from the control system <NUM>, the broker system <NUM> may query the memory <NUM> or other suitable storage component to find data matching or substantially suited to respond to a parameter indicated by the request. The parameter may be information related to a type of data, a type of component (e. g_, a class of industrial automation device <NUM> such as motors, drives, or any suitable device classification), a particular identifier of a particular sensed data (e.g., to result in a monitoring of a particular change or update to a value for a sensed value such as a sensed voltage value, a sensed pressure value, a sensed temperature value, a sensed power value, a sensed current value, or any suitable sensed value), an identifier of a portion of an industrial automation system (e.g., a unit, a sub-system), It is noted that a message or data packet transmitted as the request may include data that indicates the parameter. In this way, the parameter of the request may be used by the broker system <NUM> to determine data requested by the control device <NUM>. For example, the broker system <NUM> may search the data stored in the memory <NUM> to identify a subset of the data corresponding to the parameter specified in the request. For instance, the parameter may correspond to an identifier for the industrial automation device 66A and thus may refer to a request for a particular type of data (e.g., "generated data"). As such, the broker system <NUM> may query the data in the memory <NUM> for data that corresponds to the identifier (e.g., data generated by the industrial automation device 66A as opposed to the same type of data generated by any of the industrial automation devices <NUM>). In some cases, the parameter may include an indication that the control system <NUM> is requesting "data related" to the industrial automation device 66A, the broker system <NUM> may query the data in the memory <NUM> for data related to the particular industrial automation device (e.g., generated by the particular industrial automation device 66A and/or associated with a monitoring of the particular industrial automation device 66A). Although one particular query is described above, any suitable query may be executed (e.g., performed) by the broker system <NUM>. Furthermore, the request or query may include one or more search qualifiers, one or more query operators (e.g., "AND," "OR," "CONTAINS," "INCLUDES," "EQUALS"), or the like to expedite the query and provide more relevant results. The combination of query operations and parameters may enable the broker system <NUM> to execute a variety of queries desired by the control system <NUM> to retrieve any suitable data from the memory <NUM>.

In some embodiments, the request received at block <NUM> may correspond to a subscription request that the control system <NUM> may request to be received from the industrial automation device 66A (e.g., identified by the parameter) via the broker system <NUM>. When the control system <NUM> is subscribed to a data source (e.g., industrial automation device), a type of data (e.g., the data associated with the parameter), or another suitable output from the broker system <NUM>, the control system <NUM> may receive data from the broker system <NUM> associated with the data source, the type of data, or the like, after the broker system <NUM> acquires the data from the respective data source. For example, when the industrial automation device 66A transmits data to the broker system <NUM>, the broker system <NUM> may convert the data and transmit the converted data to each of the subscribing devices (e.g., one or more control devices of the control devices <NUM>). In some cases, the broker system <NUM> may transmit (e.g., publish) the converted data to a data channel between the broker system <NUM> and the one or more control devices <NUM>. The control devices <NUM> may access the data channel and receive a subset of the data transmitted by the broker system <NUM>. When the broker system <NUM> publishes data to the data channel, the control system <NUM> may receive a subset of the published data corresponding to the parameter of the request.

The data channel may include virtual data pathways (e.g., between layers, between transport layers or application layers), wireless data pathways, or physically wired data pathways for routing data between the broker system <NUM> and the one or more control devices <NUM>. The broker system <NUM> may also be able to change the pathways, such as in response to the request, parameters of the request, and/or subscription parameters (e.g., definitions that describe which control devices <NUM> are to receive what subsets of published data). The broker system <NUM> may establish a respective routing protocol for published data before transmitting the data to the one or more control devices <NUM>. That is, after receiving a subscription request, the broker system <NUM> may identify a data channel, a time slot, or any other setting in which to send data to a subscribing device.

At block <NUM>, in response to receiving the request at block <NUM>, the broker system <NUM> may retrieve the common protocol data from block <NUM> that corresponds to the parameters of the request from the memory <NUM> or other suitable storage component. The broker system <NUM> may determine that the common protocol data corresponds to the parameter when executing the query based on the parameter of the request. In response to querying the memory <NUM> based on the parameter of the request, the broker system <NUM> may identify a subset of data stored in the memory <NUM> as relevant or associated with the parameter or other information included in the request. In some embodiments, since the data acquired from different components (e. g_, industrial automation devices) may initially be acquired in different data formats, the data stored in the common protocol may enable more efficient and effective querying services for data provided by different components having different formats.

At block <NUM>, the broker system <NUM> may convert the common protocol data into a protocol used by the control system <NUM>. Similar to the industrial automation device 66A, the protocol used by the control system <NUM> may be any suitable protocol. In this way, the broker system <NUM> may transmit the data from the industrial automation device 66A to the control system <NUM> according to any of the industrial protocols, communication protocols, and/or communication techniques described herein and/or any suitable methods not specifically discussed herein.

At block <NUM>, the broker system <NUM> may transmit the converted data to the control system <NUM>. In this way, the converted data may include the data received from the industrial automation device 66A at block <NUM> translated to the data format interpretable by the control system <NUM>. The converted data transmitting to the control system <NUM> may also include data from other industrial automation devices <NUM>, including sensing data, statuses, or the like. The control system <NUM> may then use the converted data in any suitable operation performed by the control system <NUM>. Functionally, the control system <NUM> receives the same information as it may receive in a direct communication with the industrial automation device 66A, however the information is transmitted in a format interpretable by the control system <NUM>, as opposed to a format used by the industrial automation device 66A. Furthermore, the communicative coupling used to transmit the information from the industrial automation device 66A to the control system <NUM> may be relatively more efficient and easier to repair or maintain when compared to systems that use direct communication between the industrial automation device 66A and the control system <NUM> without use of a broker system <NUM>. That is, a direct communication link between the industrial automation device 66A and control system <NUM> may involve the control system <NUM> performing several translations (e. g, transformations, conversions) between the data originally received from the industrial automation device 66A and usable by the control system <NUM>. Moreover, the computing resources involved in enabling the control system <NUM> to perform the conversions may cause the processor size to be larger, the storage capacity to be larger, and the like. By using the broker system <NUM> to perform the storage operations, data conversion operations, and data transmission operations, the broker system <NUM> may provide these services for a number of devices, while allowing the devices to perform their respective operations.

With the foregoing in mind, <FIG> describes an example uni-directional data flow facilitated by the broker system <NUM>. However, data flow between components and the broker system <NUM> may be bi-directional. In this way, a device may transmit data to the broker system <NUM> and may receive data from the broker system <NUM>. It is noted that bi-directional communications between a device and the broker system <NUM> may occur at least partially at a same time when a suitable number of transmitting circuits, receiving circuits, or both, is present as to not cause interference between the communications, such as a transmit operation interrupting a receive operation.

To elaborate, <FIG> is a flowchart of a method <NUM> for operating the control system <NUM> to transmit and receive data from the broker system <NUM>, and thus bi-directionally communicate with the broker system <NUM>. Although the method <NUM> is described below as performed by the control system <NUM> to communicate with the industrial automation device 66A via the broker system <NUM>, it should be understood that any suitable control device, such as the industrial control system <NUM>, one or more of the control devices <NUM>, one or more industrial automation devices <NUM>, may perform the method <NUM>. Moreover, although the following description of the method <NUM> is described in a particular order, it should be understood that the method <NUM> may be performed in any suitable order.

At block <NUM>, the control system <NUM> may receive published data from the broker system <NUM> based on a request to receive certain types of data via the broker system <NUM>. The control system <NUM> may generate the request, such as the request received by the broker system <NUM> at block <NUM> of <FIG>. The request may include information that the broker system <NUM> uses to query the memory <NUM> of the broker system <NUM>, such a date range, an identifier of a target device, a type of data requested to be retrieved, an operation that the data requested to be retrieved is related to, or the like.

In some cases, the control system <NUM> may subscribe or specify that it wishes to receive data from the broker system <NUM>. As part of the subscription service, the control system <NUM> may receive some or all data transmitted to the broker system <NUM> from other components (e.g., industrial automation devices <NUM>). Furthermore, in some cases, the control system <NUM> may define which subsets of data that it wants to receive from the broker system <NUM>. For example, the control system <NUM> may subscribe to data from a subset (e.g., one or more) of the industrial automation devices <NUM> without subscribing to data from all industrial automation devices <NUM> or without subscribing to each device of the motor control center <NUM>.

At block <NUM>, the control system <NUM> may determine whether a value of the received data (e.g., published) is greater than or equal to a threshold value. The analysis operation associated with block <NUM> may be used to determine how to respond to particular data received from the broker system <NUM>. In this way, when the control system <NUM> determines that the value of the published data is not greater than or equal to the threshold value, the control system <NUM> may determine to not perform an adjustment based on the value of the published data and may continue, at block <NUM>, to receive additional published data from the broker system <NUM>. This may also involve storing the published data before returning to perform operations of block <NUM>, such as to perform a trending analysis operation and/or to use the published data in another operation.

However, at block <NUM>, if the control system <NUM> determines that the value of the published data is greater than or equal to the threshold value, the control system <NUM> may proceed, at block <NUM>, to determine an adjustment to the industrial automation device 66A. The control system <NUM> determines the adjustment to generally correct an operation of the industrial automation device 66A flagged by the value of the published data being greater than or equal to the threshold value. The adjustment may include a change in operation, a change in operational set points, a change in operating limits, a change in sensing frequencies (e.g., how often sensing operations are occurring by the industrial automation device 66A), or the like. For example, the control system <NUM> may change the operation of the industrial automation device 66A to correct values associated with operation of the industrial automation device 66A, to increase a rapidity of sensing to glean more information about operation of the industrial automation device 66A (e.g., which may or may not be used to determine operational adjustments), or the like.

At block <NUM>, the control system <NUM> may transmit the adjustment to the broker system <NUM> for translation and transmission to the industrial automation device 66A. In this way, the broker system <NUM> receives an indication of an adjustment to an operation of the industrial automation device and translates the adjustment (e.g., after translation to the common protocol and storage, similar to operations of block <NUM> of <FIG>) to a suitable format to control operation of the industrial automation device 66A.

The analysis performed at block <NUM> is just one example of a variety of different conditions that the control system <NUM> may use to analyze published data. In some cases, the control system <NUM> may determine whether published data is less than a threshold value, whether a calculation performed on the published data yields a value greater than or equal to (or less than) a threshold value, or the like. Indeed, as suggested, the control system <NUM> may average values received from the broker system <NUM>, use medians and/or ranges, perform other suitable computations, or the like to determine an operation to perform in response to receiving the published data.

Furthermore, the broker system <NUM> may, in some instances, translate the data received from the industrial automation device 66A directly into a format used by the control device <NUM>. This may happen when, for example, a status or data is flagged by the industrial automation device 66A, the broker system <NUM>, or one or more of the control devices <NUM>, or the like as having a relatively elevated priority. Skipping translation to the common communication format may reduce a total time of transmission between the industrial automation device 66A and the control system <NUM>. In some cases, the broker system <NUM> may translate the data to the format used by the control device <NUM> before translating the data to the common communication format for backup of the data.

Keeping the forgoing in mind, <FIG> is a block diagram of an example portion <NUM> of the industrial automation system <NUM> that uses the broker system <NUM> to manage communications between industrial automation devices <NUM> and a relay <NUM>. The relay <NUM> may be a solid-state device that opens or closes conductive contacts in response to a control signal. In this way, an operational state of the relay <NUM> (e.g., open state, closed state) may change an operation of a device of an industrial automation system <NUM>. For example, a motor drive may include one or more relays, where the combination of operational states of the one or more relays may operate the motor drive, and thus a motor associated with the motor drive, into different operational modes (e.g., on, off, start-up).

The broker system <NUM> may receive sensing data, status data, or other suitable information from the relay <NUM>, such as on a wired connection or a wireless connection coupling the broker system <NUM> to an output terminal of the relay <NUM>. The relay <NUM> may receive control signals from the broker system <NUM> and may receive power signals from a power management controller <NUM>. An operator workstation <NUM> may subscribe to updates (e.g., information transmitted from the broker system <NUM>) from the relay <NUM> via the broker system <NUM>. Thus, when the relay <NUM> sends new information to the broker system <NUM>, the broker system <NUM> may perform operations similar to that of the method <NUM> of <FIG> to translate and transmit the information from the relay <NUM> to the operator workstation <NUM>. The operator workstation <NUM> may use the information from the broker system <NUM> associated with the relay <NUM> to update a graphical user interface, an HMI (e.g., HMI <NUM>), or other suitable display device with an indication corresponding to the information. For example, a current state of the relay <NUM> may be represented by a graphic rendered by the operator workstation <NUM>, and thus an appearance of the graphic may be updated by the operator workstation <NUM> in response to receiving the information. The operator workstation <NUM> may perform computations using the data received from the broker system <NUM>, may use the data to determine a control action as a command to transmit to the broker system <NUM>, or the like. A control device <NUM> may use one or more commands, one or more computation results, or the like, when adjusting (e.g., determining to adjust) an operation of the industrial automation system <NUM>.

The broker system <NUM> may store data in a database <NUM>, a database <NUM>, or the like, such as any suitable storage device or memory device. The database <NUM> may be a long-term persistence database associated with backing up of data for long term storage. The database <NUM> may perform its own data refresh operations to keep stored data fresh and stable. The database <NUM> may be a relational database that stores data and relationships between the data. In this way, the database <NUM> may store information that identifies sensing data in addition to metadata associated with the sensing data, such as a source device for the sensing data. When the relay <NUM> generates sensing data, status information, or other suitable information for storage by the broker system <NUM> in the database <NUM>, the sensing data and/or status information may be stored in the database <NUM> in the common communication format, as well as with relationship data regarding a relationship to each other, to the relay <NUM>, or the like. Other relationships may be captured in the database <NUM>, such as a department indication and/or other operational information associated with capture of the sensing data, the status information, or the like. These relationships and/or metadata may help provide a more complete view of system operation at a time of capture of the sensing data and/or status information (e.g., facilitate with analysis and/or debugging), and thus may be referenced using the broker system <NUM> to provide insight for computations, control decisions, or the like.

In some cases, referring briefly back to <FIG>, a request may serve to subscribe the control system <NUM> to data from the industrial automation device 66A, to data associated with the parameter, or the like. When subscribed, the control system <NUM> may receive data published by the broker system <NUM> associated with the data source and/or the type of data. For example, when the industrial automation device 66A transmits data to the broker system <NUM>, the broker system <NUM> may convert the data and transmit the converted data to each of the devices (e.g., one or more control devices of the control devices <NUM>) that subscribed to the data. In some cases, the broker system <NUM> may transmit (e.g., publish) the converted data to a data channel between the broker system <NUM> and the one or more control devices <NUM>. The control devices <NUM> may access the data channel and receive a subset of the data transmitted by the broker system <NUM> corresponding to the respective requests of the control devices <NUM>. In this way, the broker system <NUM> may publish data to the data channel, and the control system <NUM> may receive a subset of the published data corresponding to the parameter of the request. The data channel may include one or more virtual data pathways, one or more wireless data pathways, one or more wired data pathways, or the like for routing data between the broker system <NUM> and the control system <NUM> and/or one or more control devices <NUM> based on the parameter of the requests and/or subscription parameters (e.g., definitions that describe which control devices <NUM> are to receive what subsets of published data). The broker system <NUM> may establish the respective routing before transmitting the data to the one or more control devices <NUM>.

To elaborate, an example of the publish/subscribe operation may include the broker system <NUM> reading the broker system configuration <NUM> from memory, from a software application accessible by the broker system <NUM>, or the like. Furthermore, the broker system <NUM> may read offline configurations from a data store (not depicted in <FIG> but should be understood to be a database and/or storage system accessible by the broker system <NUM> through any suitable communicative coupling). Accessing (e.g., reading) the offline configurations may provide to the broker system <NUM> an indication of configurations of systems outside a subset of industrial automation devices communicatively coupled to the broker system <NUM> (e.g., outside of the example MCC <NUM>). The broker system <NUM> may perform a device discovery operation, such as when devices coupled to the broker system <NUM> are not specifically enumerated or described in the broker system configuration <NUM> and/or the data store and/or when the broker system <NUM> is to authenticate industrial automation devices <NUM> for communication.

During the device discovery operation, the broker system <NUM> may test each communicative coupling it detects to confirm that a device (e.g., a respective industrial automation device <NUM>) is able to communicate with the broker system <NUM> via the communicative coupling. After confirmed, or after the communicative coupling is authenticated for use in communication with the device, the broker system <NUM> may receive data generated (e.g., acquired) by the device. The broker system <NUM> may publish the data generated by the device to a common communication channel to couple the broker system <NUM> with one or more of the control devices <NUM>. One or more of the control devices <NUM> may subscribe to the data published by the broker system <NUM>, and thus receive the data generated by the device from the broker system <NUM>. In some cases, the broker system <NUM> translates the data to the common protocol.

In some cases, the broker system <NUM> may sometimes perform authentication operations by comparing a list of discovered devices (e.g., discovered devices of the MCC <NUM>) to a list of expected devices before permitting data to be transmitted to it, before receiving data from a device, or before performing any operation that may involve receiving data from an unauthenticated device. The broker system configuration <NUM> may provide an indication of the list of expected devices to the broker system <NUM>. When a device is discovered that is not on the list of expected devices, the broker system <NUM> may ignore or disregard data transmitted from the device, may generate an alert indicating the discovery of the inconsistency (e.g., deviation), or the like to generally reject communication with the unauthenticated device. The generation of the alert may cause the broker system <NUM> to translate the alert into a format interpretable by one or more of the control devices <NUM>. The broker system <NUM> may transmit the alert to one or more of the control devices <NUM>. One or more of the control devices <NUM> may perform a wide variety of operations in response to the alert, such as performing an operation to address the concern associated with the alert, generating an additional alert or notification, or the like. For example, the HMI <NUM> may update a rendering of a graphic in response to receiving the alert, the IoT platform <NUM> may instruct a camera sensor to power on and to start collecting image data to record the discovered device in question), or the like.

As described above, MQTT may be used to support the broker system. A broker system <NUM> using MQTT may be thought of as a server connected to client devices (e.g., control devices <NUM>, industrial automation devices <NUM>) or subsystems (e.g., MCC <NUM>). One benefit of MQTT is that if a connection is unavailable between a client device (e.g., control devices <NUM>, industrial automation devices <NUM>) and the broker system <NUM>, the broker system <NUM> may buffer messages in a queue until the client device becomes available, and may publish messages to the subscriber when the client device becomes available. Another benefit of MQTT is that if a connection between a client device publishing to a broker system <NUM> is severed, the broker system <NUM> may send a message to each communicatively coupled client device remaining and alerting them of the absence of the severed client device. To identify the severed connection, the broker system <NUM> may transmit a test message to the client devices, such as periodically, on a regularly interval, in response to an event occurring (e.g., trigger event), or the like, to determine if the connection is still valid. The broker system <NUM> may also wait for a confirmation message from the client device, and if a duration of time longer than a threshold amount of time passes (e.g., communication confirmation times out), the broker system <NUM> may determine that the connection is severed. The broker system <NUM>, in this case, may force-close (e.g., end) the connection (e.g., communication) to the severed client device without operator intervention, such as changing a publish setting to stop outgoing communications from transmitting to the severed client device. Furthermore, the broker system <NUM> may transmit an indication (e.g., notification, message) to the control device <NUM> (e.g., HMI) to notify an operator that the communication with the client device has ended.

<FIG> is a flowchart of a method <NUM> for validating devices when preparing for communication using the broker system <NUM>. Although the method <NUM> is described below as performed by the broker system <NUM>, it should be understood that any suitable control device, such as the industrial control system <NUM>, may perform the method <NUM>. Moreover, although the following description of the method <NUM> is described in a particular order, it should be understood that the method <NUM> may be performed in any suitable order.

At block <NUM>, the broker system <NUM> may receive a configuration file corresponding to a system to be added to the industrial automation system <NUM>, such as a plant expansion, one or more additional components, a new unit, a new MCC, a new substation, or the like. The configuration file received may include a control file in a software package accessible by or transmitted to the broker system <NUM>, where the configuration file may include Extensible Markup Language (XML) data, an XML file, or other suitable format. The received configuration file may be included in a purchase order associated with one or more components purchased for implementation in the industrial automation system <NUM>. Furthermore, the received configuration file may be added to a system model maintained by the broker system <NUM>. The system model may be a digital representation of a component hierarchy of the industrial automation system <NUM>, equipment relative relationship within the industrial automation system <NUM>, a network connection model between components in the industrial automation system <NUM>, and the like. The system model may be used by the broker system <NUM> to manage the reception and transmission of data using a network model that describes the communication channels available to each respective communicative coupling and/or the network data pathways available in the industrial automation system <NUM>. For example, when the MCC <NUM> is purchased for the industrial automation system <NUM>, the MCC <NUM> may physically include the industrial automation devices <NUM> and a configuration file may describe the physical layout or arrangement of the industrial automation devices <NUM>.

In addition, the configuration file may specify industrial automation devices <NUM> that are expected to be included in the MCC <NUM>, as well as a relative placement of each of the industrial automation devices <NUM>, an internet protocol (IP) address for each of the industrial automation devices <NUM>, as well as an hierarchical placement within the industrial automation system <NUM> the MCC <NUM> (e.g., a system, a sub-system, a portion, an electrical line, or the like). Based on the relationships (e.g., data transmission pathways and/or component hierarchies) specified in the configuration file, the broker system <NUM> may integrate the relationship data regarding the components within the MCC <NUM> to the system model maintained for the industrial automation system <NUM>. The system model may then illustrate or depict a list of components connected to the MCC <NUM>, a list of electrical power sources, a list of components that provide control signals, and other related information for each component included within the MCC <NUM>.

Before adding the components data specified in the configuration file to the system model, the broker system <NUM> may, at block <NUM>, perform a device discovery operation based on the available communication channels or ports available to the broker system <NUM>. During the device discovery operation, the broker system <NUM> may test a communicative coupling to confirm that a device is present and able to communicate with the broker system <NUM> via the communicative coupling. For example, the broker system <NUM> may identify the IP addresses (e.g., networking addresses) for each industrial automation device <NUM> and/or control device <NUM> communicatively coupled to the broker system <NUM>. The broker system <NUM> may store in memory a list of devices discovered using operations of the block <NUM>, such as storing a list of identifiers for each device discovered using operations.

At block <NUM>, the broker system <NUM> may validate the discovered devices against the components listed in the configuration file. To do so, the broker system <NUM> may compare indications of expected devices and/or expected device IP addresses to those devices and/or IP addresses actually discovered. When there is an inconsistency and a discovered device does not match a device in the list of expected devices and/or an expected device is missing from the discovered devices, the broker system <NUM> may generate an alert to be presented via the HMI <NUM>, to be output via the alarm management system <NUM>, or the like. After verifying that the discovered devices match the components specified in the configuration file, the broker system <NUM> may add the components specified by the configuration file to the system model and/or initialize communication with the discovered devices. Furthermore, the broker system <NUM> may install or configure components specified in the configuration file to each discovered and validated device. The installation or configuration of devices may be reflected as an update the system model. Furthermore, the system model maintained by the broker system <NUM> may perform data abstraction operations that permit the broker system <NUM> to receive data from discovered devices and to link the data back to the system model for updates. Moreover, the broker system <NUM> may store the received data in a historical log accessible by way of reference to the model. As data becomes available for publishing, the broker system <NUM> may use the system model to prepare or send the data according to a desired format (e.g., isolated, separated, packaged as a part as opposed to a whole).

At block <NUM>, the broker system <NUM> may acquire data from a respective device and associate the data with its source component, such as an IP address corresponding to the respective device, to the system model. In this way, the broker system <NUM> may associate the data received from the respective device to a portion of the system model managed by the broker system <NUM>. Adding data to the overall system model in this way may generate an updated logical view of each component relative to the industrial system <NUM> (e.g., respective child or parent devices of each component). Moreover, the system model may specify a relative location for each component, physical switches that are used to control data transmission to and/or from each component, routers connected to the components, and the like. Before adding the data to the system model, the broker system <NUM> may perform calculations using the data and/or otherwise orchestrate further analysis or sorting of the data. The broker system <NUM>, when performing data orchestration operations, may receive many different data points and organize the different data points for analysis, modeling, and collection. This operation may be relatively more efficient by using one query to retrieve fifty data points, as opposed to performing orchestration operations using fifty individual queries to gather the fifty different data points. For example, the respective device may output data that is relevant for both the respective device and another device, such as the sub-system as a whole, the MCC <NUM>, a category of devices, or the like. In this way, when the data is relevant for multiple parts of the system model, the broker system <NUM> may route the data to the different parts of the system model for association with the IP address and/or for storage in the repository. Thus, the broker system <NUM> may support and multi-in/multi-out transmission system that dynamically routes and translates data between various generation-points (e.g., source devices) and end-points (e.g., sink devices).

When routing data between devices of the industrial automation system <NUM>, the broker system <NUM> may reference the system model to determine an efficient network path to transmit the data. For example, the broker system <NUM> may initiate collecting data from a sensor (e.g., example of an industrial automation device <NUM>) and determine a network route to follow to retrieve the data from the sensor, such as identifying a set of network switches to control to route the data from the sensor to the broker system <NUM>. A similar operation may be applied to network switches associated with control devices <NUM>. For example, the broker system <NUM> may control certain network switches to route data to a respective control device <NUM> and/or to receive a command from the respective control device <NUM>.

The model described above may be used to mass-deploy commands and/or other actions to one or more devices of the industrial automation system <NUM>. For example, just as a configuration file may be used to validate newly installed industrial automation devices <NUM> added to the system model, configurations files may additionally or alternatively be used to validate new control devices <NUM> added into the system model. Indeed, the broker system <NUM> may provide a return path of data for control of a data-generating device (e.g., control device <NUM>, industrial automation device <NUM>). This return path may specify a destination in which a control device <NUM> may direct data towards. For example, the return path may correspond to an application (e.g., software) of the broker system <NUM>. After receiving a command, the broker system <NUM> may access the model to determine a device tag corresponding to the device that is targeted by the command. To access the model, the broker system <NUM> may logically deconstruct the system model to access information stored within the information hierarchy of the system model. Indeed, the situation may arise where the command from the control device <NUM> is targeting a device that originally generated data used by the control device <NUM> to determine the command. This example exemplifies bi-directional communication capabilities of a communication network deployed with the broker system <NUM>. However, it is noted that the broker system <NUM> may enable a wide variety of combinations of data pathways, and the system model may represent an end-to-end model or a relatively comprehensive model for each data pathway that intersects with the broker system <NUM>.

Using these indications of the data pathways may permit the broker system <NUM> to receive one command from one control device <NUM> and deploy the command to entire sections of the industrial automation system <NUM> or subsets of components of the model by referencing the devices included in the hierarchy of the model. For example, the HMI <NUM> may receive an input indicating to shut down or remove power from the MCC <NUM>. Thus, the broker system <NUM> may determine which of the components of the MCC <NUM> are currently powered on (e.g., by reading voltage data or other sensed data output from one or more components of the MCC <NUM>). For the components that are powered on, the broker system <NUM> may, using the model, determine which networked components to use to electrically isolate and power-off the components to permit the MCC <NUM> to be powered off in a controlled manner. A similar process may be used to deploy batch commands to entire units, such as to change an operating speed of a type of motor (e.g., via deployment of command and/or operating settings to respective drives for the motors), or the like. Indeed, the broker system <NUM> may reference the system model to retrieve IP addresses for devices of the hierarchical system model. In some cases, one IP address may be used to reference each device under a sub-system in the hierarchy, such as when each device uses a same or otherwise compatible communication protocol or are of the same device. For example, transmitting a command to an IP address corresponding to the MCC <NUM> may enable the broker system <NUM> to transmit respective commands to each device of the MCC <NUM> using one command to the MCC <NUM>. Furthermore, it is noted that the system model may be stored in a storage repository for the broker system <NUM> to access and add to and/or remove from over time (e.g., when components are added or removed from the industrial automation system <NUM>).

To keep the system model updated, the broker system <NUM> may perform an audit. The broker system <NUM> may perform the audit on a periodic schedule, such as part of a maintenance schedule, after a specified amount of time passes, or the like. Sometimes, the broker system <NUM> may perform the audit not on a periodic schedule, such as in response to a control signal (e.g., a command from the HMI <NUM>), in response to a condition being satisfied (e.g., the broker system <NUM> discovering a new IP address), or the like. To perform the audit, the broker system <NUM> may repeat performing the method <NUM> across one or more portions of the industrial automation system <NUM>, or may perform other suitable verification operations.

In some systems, the broker system <NUM> may transmit a test message to the first industrial automation device and start a counter. The broker system <NUM> may force a communicative coupling to the first industrial automation device (e.g., control devices <NUM>, industrial automation devices <NUM>) to end in response to a count of the counter reaching a threshold value. In response to ending the communicative coupling, the broker system <NUM> may transmit an indication to a third industrial automation device (e.g., control devices <NUM>, industrial automation devices <NUM>), such as a HMI, where the indication communicates to the third industrial automation device that communication with the first industrial automation device timed out. Indeed, this one-to-many capability of the broker system <NUM> may enable the connected client device to focus on its operation, and not permit the delivery of data to an application or subsystem. The broker system <NUM> may still store the data generated by the first industrial automation device even if the data is not being transmitting on to the third industrial automation device. Provided how the MQTT protocol is also able to be deployed using relatively low amounts of power, the MQTT protocol permits effective communication even between resource constrained clients, and permits communication between many applications.

To provide another example of an operation of the broker system <NUM>, within a pulping process, multiple sensors measuring humidity, temperature, chemical content, tank levels, rotational speed, as well as other signals are embedded within various portions of the pulping process. A local control system or supervisory control system may use many of these signals within a control strategy or larger distributed control strategy. Additionally, these signals may also be used in a human machine interface, operator workstation, long term persistence database, as well as a reporting client. Rather than devices of the pulping process having to maintain four connections to the subsystems plus an additional connection to the control system to execute a control strategy, a broker system <NUM> may be used to manage communications of the system. With the insertion of the broker system <NUM>, fewer connections need to be made to a sensor, for example, one connection to the broker system <NUM> as opposed to four connections to the subsystems. By modeling the devices communicatively coupled to the broker system <NUM>, for example, according to the MQTT protocol, each subsystem may effectively consume, analyze, and present the data in a format that is easy to exchange with the other devices.

Thus, technical effects of the present disclosure include techniques for providing a broker system to communicate between wide varieties of industrial automation devices and control devices. The broker system may leverage a common communication format (e.g., common protocol) to translate data from a protocol used by the industrial automation device to a protocol used by the control device when transmitting data between the industrial automation device and the control device. In some cases, the broker system may store the data after translation to the common communication format in memory for subsequent use in historical analysis. The control devices may request specific data from the broker system (e.g., data from a particular device, data from a particular unit or portion of an industrial automation system), may subscribe to particular devices or particular subsets of devices to receive data output to the broker system by the devices, may subscribe to all updates (e.g., all data and/or statuses) from one or more devices of an industrial automation system, or the like. Leveraging a broker system in an industrial automation system may improve communication technology since communications may be deployed in an improved and/or more efficient manner. Furthermore, an industrial automation control system that uses a broker system may be easier to maintain over time since, for example, fewer respective couplings may be used between components in the system. Furthermore, data generated by the industrial automation devices, the control devices, the broker system, or the like may be more readily or easily backed up in databases since the communications transmit through a common distribution device (e.g., the broker system).

Moreover, the present embodiments described herein provide a data orchestration step such that data received from devices is ingressed or routed to the broker system <NUM>. The broker system <NUM> may logically orchestrated the data to match the physical arrangement and the logical network specified in the MCC model. The broker system <NUM> may perform certain types of analysis (e.g., translation, grouping) on the received data according to a data object model that may be specified as part of the MCC model. Both the MCC model and the data object model may be transmitted and egressed from the broker system <NUM> to multiple clients or data recipients,.

In addition, the data object model or the MCC model may provide a return path for the data received by the broker system <NUM> to facilitate the control of other devices. That is, the MCC model may specify that data received from a particular component may be routed to other components via the broker system <NUM>. As such, the return path may specify that data received from application, according to the model, may be routed to an individual device. In some embodiments, the model may be deconstructed to determine the individual tags and devices to route the data.

Claim 1:
A system, comprising:
a first industrial automation device (<NUM>) configured to generate a first set of data according to a first protocol;
a second industrial automation device (<NUM>) configured to generate an automation command configured to control the first industrial automation device based at least in part on the first set of data; and
a broker system (<NUM>) coupled between the first industrial automation device and the second industrial automation device, wherein the broker system is configured to perform operations comprising:
receiving (<NUM>) the first set of data from the first industrial automation device;
converting (<NUM>) the first set of data from the first protocol to a second protocol thereby generating a second set of data;
storing (<NUM>) the second set of data in a storage component;
converting (<NUM>) the second set of data from the second protocol to a third protocol thereby generating a third set of data in response to determining that the second industrial automation device is seeking the first set of data, wherein the second industrial automation device is configured to interpret data formatted according to the third protocol; and
transmitting (<NUM>) the third set of data to the second industrial automation device, characterised in that the broker system is further configured to to perform the operation:
converting the first set of data from the first protocol received from the first industrial automation device directly to the third protocol thereby generating the third set of data to be used by the second industrial automation device when data is flagged, by the first industrial automation device, as having relatively elevated priority.