Unified dynamic controller for power and process applications

Abstract

The invention relates to a unified dynamic controller for power and process applications. A high availability controller for combining and unifying aspects of a process controller and an electrical controller. The unified namespace combines a process domain namespace and a power domain namespace in a common database of the controller without changing any one of them. The unified namespace maps a source device name of the power domain and a unique process control name of the process domain. A common record set of event sequences (SOEs) for the process domain and the power domain is generated, and the SOEs generated from the power domain are incorporated into the common record set. The controller performs process control and monitoring as well as electrical control signaling and monitoring within a single control policy directly from the controller.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to Indian Patent Application No. 202411039315, filed on May 20, 2024, the entire disclosure of which is incorporated herein by reference. Background Technology

[0003] Driven by the need for enhanced efficiency, reliability, and sustainability, the integration of power and process control systems has become a key effort in modern industrial operations. For example, as the oil and gas industry continues to optimize its operations, the convergence of these traditionally disparate domains offers significant opportunities to optimize resource utilization, minimize downtime, and improve overall operational performance. This integration is essential for achieving a holistic view of industrial processes, enabling seamless coordination between energy management and production control.

[0004] The integration of power and process control systems offers numerous benefits. By synchronizing energy consumption with production demands, organizations can achieve significant cost savings, reduce environmental impact, and enhance their competitive advantage in dynamic market conditions. Furthermore, a collaborative approach facilitates predictive maintenance based on real-time equipment performance data. This, in turn, leads to reduced downtime, optimized asset lifecycles, and enhanced operational reliability. Moreover, convergence enables richer analytical inputs, providing actionable insights to drive continuous process optimization and energy efficiency improvements.

[0005] Despite their potential advantages, the integration of power and process control systems is not without its challenges. Interfacing with different technologies and control philosophies, ensuring network security, and managing interoperability complexities are some of the key hurdles that must be overcome. For example, traditional technologies for combining process and electrical control schemes require direct parallel hardwiring and interlocking, or the use of gateways and inter-system wiring and marshalling cubicles, which translate relevant namespaces into commonly understood client-server protocols (e.g., Modbus Serial). Furthermore, traditional combined controllers can suffer from excessive control latency and round-trip times. Summary of the Invention

[0006] Aspects of the present disclosure provide a high availability controller that combines and unifies aspects of process controllers and electrical controllers. The combined aspects involve including a process control namespace as well as a namespace for intelligent electronic devices (IEDs) defined by a communication protocol such as IEC 61850. In an aspect, the two namespaces are included within the same database of an embedded controller without alteration and the unaltered behavior of both is provided. Aspects of the present disclosure support multiple logical engines working asynchronously on a common database and combine cyclic process control with event-driven electrical signaling behavior required by IEC 61850.

[0007] The main protocols involved include, for example: Foxboro Compound: Block: Parameter namespace with object manager services, IEC 61850 servers and clients, and Modbus TCP servers and clients on a common Ethernet controller. The controller of the present disclosure is fully self-contained and continues to run and save available data and events until reconnected to the multiple clients and servers, respectively.

[0008] In one aspect, a method of configuring a controller for control in both a process domain and an electrical domain of an industrial operation includes mapping a unified namespace to source device names of one or more IEDs in the electrical domain. The unified namespace is based on unique process control names of the process domain. The method also includes generating a common record set of sequences of events (SOEs) for the process domain and the electrical domain and incorporating SOEs generated from the IEDs into the common record set. The method further includes receiving one or more commands from a control system of the industrial operation, updating the unified namespace with the received commands, presenting the received commands to one or more control engines for execution, and updating the unified namespace after execution of the received commands.

[0009] In another aspect, an electrical controller has a high availability architecture for control in both a process domain and an electrical domain of an industrial operation. The controller includes a database, a processor, and a memory device. The database stores a unified namespace that maps source device names of devices in the electrical domain based on unique process control names of the process domain. The memory device stores processor-executable instructions that, when executed, configure the processor for receiving one or more commands from a control system of the industrial operation, updating the unified namespace with the received commands, presenting the received commands to one or more control engines for execution, and updating the unified namespace after execution of the received commands.

[0010] Other objects and features of the present application will be in part apparent and in part pointed out hereinafter. Attached Figure Description

[0011] Figure 1 An electrical and process system with a highly available unified architecture is illustrated according to an embodiment.

[0012] Figure 2 A high availability architecture for a unified controller according to an embodiment is shown.

[0013] Figure 3 This is a block diagram illustrating a unified namespace for process and electrical domains according to one embodiment.

[0014] Figure 4 This is a block diagram illustrating a common control engine for process and electrical domains according to an embodiment.

[0015] Figure 5 This is a block diagram illustrating a common SOE / alarm across process, electrical, and security domains according to an embodiment.

[0016] Figure 6 This is a block diagram illustrating multi-protocol support for electrical and process domains according to an embodiment.

[0017] Figure 7 This is a block diagram illustrating support for both loop-driven and event-driven control engines for process and electrical domains according to an embodiment.

[0018] Figure 8 This is a block diagram illustrating a time synchronization process for a low-voltage device according to an embodiment.

[0019] Figure 9 A high availability (hot-cold redundancy) architecture for process control according to an embodiment is shown.

[0020] Figure 10 A high availability (hot-warm redundancy) architecture for low voltage control is shown according to an embodiment.

[0021] Figure 11 A high availability (hot-hot redundancy) architecture for medium-voltage control according to an embodiment is shown.

[0022] Figure 12 The high availability (hot-hot redundancy) command synchronization process according to an embodiment is illustrated.

[0023] Figure 13 The high availability (hot-hot redundancy) report synchronization process according to an embodiment is illustrated.

[0024] Figure 14 The integration process and components of the electrical domain are shown according to an embodiment.

[0025] Figure 15is a block diagram illustrating an example data flow according to an embodiment.

[0026] Figure 16 is a flow diagram illustrating an example engineering workflow according to an embodiment.

[0027] Figure 17 is a block diagram illustrating a distributed control system (DCS) control network interface design according to an embodiment. Figure 1

[0028] Figure 18 is a block diagram illustrating multiple control engines for process and electrical domains according to an embodiment.

[0029] Figure 19 is a block diagram illustrating event-driven control engines for process and electrical domains according to an embodiment.

[0030] Figure 20 is a block diagram illustrating state and logic control engines for process and electrical domains according to an embodiment.

[0031] Figure 21 is a block diagram illustrating a unified namespace for process and electrical domains according to an embodiment.

[0032] Figure 22 is a block diagram illustrating common control engines for process and electrical domains according to an embodiment.

[0033] Figure 23 is a block diagram illustrating common SOE / alarm across process, electrical, and safety domains according to an embodiment.

[0034] Figure 24 is a block diagram illustrating multi-protocol support for process and electrical domains according to an embodiment.

[0035] Figure 25 is a block diagram illustrating support for both cyclic and event-driven control engines for process and electrical domains according to an embodiment.

[0036] In all of the drawings, like reference numerals refer to like parts throughout the several views. DETAILED DESCRIPTION

[0037] The features and other details of the concepts sought to be protected herein, and the system and techniques thereof, will now be more particularly described with reference to the drawings. It will be understood that the particular embodiments described herein are shown by way of illustration and not as a limitation of the disclosure and concepts described herein. Features described herein can be employed in various embodiments without departing from the scope of the concepts sought to be protected.

[0038] ​The combination of process and electrical control schemes in the past required direct parallel hardwiring and interlocking or the use of gateways and inter-system wiring and marshalling cabinets. By using more high-speed control hardware, memory, and Ethernet capabilities, a single controller embodying aspects of the present disclosure can now eliminate the need for gateway and proxy control connections and protocol translators, providing a lower cost, simpler solution. Further, the disclosed controller allows a single process control strategy to directly interact with electrical high-speed control services within the same execution engine, greatly reducing control latency and round-trip time.

[0039] Referring to Figure 1 An exemplary process and electrical system 100 is shown. In the illustrated embodiment, the system 100 integrates an electrical system 102 and a process system 104, which together make up an electrical substation. The electrical system 102 includes electrical equipment monitoring and control system (EMCS) operations indicated at 106. The EMCS operations 106 include, for example, at least one human-machine interface (HMI) and at least one database containing archived EMCS data for automating substation control, maintaining stable power generation conditions, etc. Figure 1 The electrical system 102 also includes low voltage (LV) and / or medium voltage (MV) switchgear 108 (housing protection and control IEDs 110) and EMCS solutions 112 (including, for example, intelligent fast load shedding (iFLS) protection 114 and generation management system (GMS) 116). In one embodiment, one or more unified electro-dynamic controllers 120 combine and unify aspects of both process controllers for process control and electrical controllers for electrical control. The controllers 120 provide data acquisition, display, historical collection, alarming, reporting, etc. functions for the electrical system 102. The controllers 120 are configured to obtain data from various LV and MV equipment. As is familiar to those skilled in the art, communications within the electrical system 102 are according to an IEC 61850 network, indicated at 122. IEC 61850 defines standards for the design of substation automation systems and applications, including communication protocols. In this regard, each intelligent electronic device, such as each IED 110, is a logical node on the IEC 61850 network 122 representing the functional capabilities of the device. Further, the controllers 120 of the electrical system 102 are logical nodes on the IEC 61850 network 122.

[0040] Figure 1The process system 104 includes process and substation operations indicated at 126. Operation 126 includes, for example, at least one HMI, at least one database containing alarms and events, at least one historical recorder, etc. The process system 104 also includes at least one safety controller 128 connected to one or more safety control devices 130 and at least one processor controller 132 connected to one or more process control devices 134. Further for... Figure 1 For example, one or more unified controllers 120 also provide functions such as data acquisition, display, history collection, alarms, and reporting regarding the low-voltage motor control center (MCC) 136 of the process system 104. As is familiar to those skilled in the art, the components of the process system 104 are coupled according to a DCS MESH network, as shown in 138. In this embodiment, the controller 120 of the process system 104 is a node on the MESH network 138 and maintains the high availability requirements of the DCS.

[0041] As mentioned above, creating high availability schemes for controllers typically requires dedicated hardware interfaces and is platform- and application-specific. However, controller 120 is capable of meeting the high availability requirements of a DCS and of transferring data from electrical system 102 to process system 104. In this respect, aspects of this disclosure integrate high availability schemes for both the DCS (process system 104) and EMCS (electrical system 102). By combining these high availability schemes, high availability is achieved through a unified controller 120. Controller 120 can receive data from various LV and MV devices that support open standard communication protocols and provide data to the DCS using its proprietary communication protocol.

[0042] In one embodiment, the unified electrical controller 120 is the key node that seamlessly connects the power and process architecture of the following two systems: DCS and EMCS. Its unique ability to host multiple communication protocols (for process and power domains) and combine their data in one address space simultaneously enables seamless integration. It also eliminates the need for separate communication modules for each protocol. The unified electrical controller 120 provides four key interfaces for power and process use cases. These four interfaces can be referred to as north, west, east, and south. The north interface includes proprietary communication (object manager) for DCS application workstations (e.g., process HMI, historian) and IEC 61850 communication (MMS) for EMCS workstations (e.g., electrical HMI). The west interface includes proprietary communication (object manager) for DCS and safety controllers. The east interface includes IEC 61850 communication (MMS and GOOSE) for EMCS IEDs used for protection, control of power generation, distribution, electric machines, etc. The south interface includes hardwired integrated supervisory control using IO modules and Modbus TCP communication for LV electric machines, drives, and other electrical equipment.

[0043] According to embodiments, a unified namespace combines the process domain namespace and the power domain namespace in a common database of the controller 120 without changing either one. The unified namespace maps the source device names of the power domain (i.e., electrical system 102) and the unique process control names of the process domain (i.e., process system 104). A common record set is generated for SOEs of the process domain and the power domain, and SOEs generated from the power domain are incorporated into the common record set. The controller 120 performs process control and monitoring and electrical control signaling and monitoring within a single control strategy directly from the controller. Using a common database with cloning allows lossless transfer of SOEs without loss and with time stamping at the source. The controller 120, also referred to as an electrical dynamic controller, is fully bidirectional and supports dual-port control and electrical network backbone first while maintaining their isolation. This simplifies the network security model and ensures that instruments from process instrumentation or electrical drives or IEDs can be combined within the same distributed control strategy. This greatly enhances the ability of process engineers to combine electrical equipment within process control automation loops and continuously improve the loop throughout the life cycle in the field without additional or changed hardwiring.

[0044] In embodiments, the hardware of the controller 120 is based on electrical standards for operating in the difficult electromagnetic compatibility environment encountered in a substation. To this end, the controller 120 can be placed directly in the electrical cabinet and extend the control network back to the field instrument room, for example, any distance away, via a fiber optic connection. This provides an additional benefit of simplification and reduced control hardware complexity. Since the controller implements dual ports for the DCS control network and IEC 61850 clients and servers, the controller 120 can be distributed locally and a single controller acts as the master publisher on the control network.

[0045] The electrical controller 120 is connected to the DCS meshed control network 138 using, for example, a fiber optic Ethernet connection. To this end, a small form factor pluggable (SFP) interface with digital diagnostic monitoring (DDM) is used. With the DDM feature, the transmit feature of the SFP is controlled from firmware over an I2C interface. Under normal conditions, if the SFP is directly connected to any network, disabling the transmit feature will cause a link down (LINK DOWN) to occur on the Ethernet interface. In the DCS control network (i.e., meshed network 138) interface design of the electrical controller 120 (see Figure 17 ), the fiber SFP of the electrical controller 120 is connected to the DCS meshed network 138 through an external splitter / combiner. In this architecture, the transmit feature is enabled on the active controller and disabled on the standby controller. Even though the transmit feature is disabled on the standby electrical controller, the Ethernet link is up (UP) due to the DCS control network (or meshed network) interface design, enabling the data from the meshed network 138 to be received in parallel on both controllers 120 and only data from the active controller to be transmitted to the meshed network 138. Figure 17

[0046] ​Aspects of the present disclosure provide a unified namespace based on unique process control names that are mapped to source IED names based on IEC 61850 namespace. In one embodiment, the unified namespace uses DCS function_block.parameter automation across process and power domains and incorporates all SOEs from IEC 61850 connected IEDs within a common process, safety, and power SOE record set. Aspects of the present disclosure also incorporate SOE buffers to allow pending events to be published with source time tags without interfering or constraining control processor cycles. For these reasons, the controller 120 embodying aspects of the present disclosure enables management of multiple disparate protocols within the same DCS controller in both client and server form, enables asynchronous response to connection-based protocol requests (polling, buffered, and unbuffered) within the same controller, and enables support for time synchronization of downstream IEDs via Precision Time Protocol (PTP) or Simple Network Time Protocol (SNTP).

[0047] A unified namespace is needed to allow simple data type representation of data from both external electrical control system 102 and process control system 104. Not just a namespace, read-write characteristics allow cloning and buffering to support asynchronous connected events between the two systems. Due to the event-driven nature of electrical control systems, exemplified by GOOSE (Generic Object Oriented Substation Event) protocol, and the necessary periodic behavior of DCS utilizing its block processing cycle, asynchronous behavior is needed. Data events from the electrical side must be stored point by point for subsequent processing within the process control cycle. This unique feature is the core of the invention and effectively eliminates the need for a switching protocol and buffering database between the two systems, i.e., the gateway.

[0048] The electrical controller allows applications written by users using IEC 1131 type engineering tools. This is not the usual language of DCS. Rather, DCS control strategies allow a defined set of blocks (BLOCKS) that perform all necessary functions and communicate with other local or networked blocks available within multiple networked controllers via parameter interfaces. Aspects of the present disclosure remove the additional engineering tools and logic programs and have a single loop process control engine. This simplifies the abstract design of control and allows the creation of common control strategies involving multiple control blocks and interacting with process field devices and electrical field devices and controllers as needed.

[0049] Due to the ability of the controller to host multiple protocols simultaneously and combine their data within one namespace, latency across protocol conversions is reduced. This eliminates the need to add multiple separate communication modules, one for each protocol.

[0050] The controller 120 according to embodiments can be located within either or both of the electrical system 102 or the process system 104. Interaction with either host system is managed independently. This allows engineers to represent process control data as standard IEC 61850 IEDs within the electrical control environment and electrical data as standard combined modules: modules: parameters within the process control environment. If either system fails for any reason, the controller 120 continues to work with very high availability until the network connection is restored.

[0051] Lossless transmission of event data obtained from the electrical system and retransmitted within the DCS event system requires a common time base propagated throughout the IEDs and controllers of the process system 104 and electrical system 102, where the lossless transmission of event data is completed with a time tag at the electrical IED source. The ability of the controller 120 to ensure that there is a common time within the substation environment in the plant and to match the DCS time ensures that operator or engineer root cause analysis and historical analysis for energy efficiency optimization is based on time consistent data.

[0052] Figure 2 A high availability architecture of the controller 120 according to one embodiment is shown. The controller 120 complies with the different requirements of high availability of both electrical and process control systems 102, 104 and utilizes a controller redundancy architecture with high availability for each specific domain (i.e., process or power). In one embodiment, one of the redundant nodes is active on the process control network at some time and the switchover can occur in a manner transparent to the other nodes. This requires a hot-cold redundancy architecture. The active node scans the devices on the network of the LV electrical system and the standby node can only connect to these devices so that the switchover can be completed in less than a second. This requires a hot-warm redundancy architecture. Both the active node and the standby node communicate with all of the IEDs of the MV electrical system simultaneously so that any switchover can be seamless (within a few milliseconds). This requires a hot-hot redundancy architecture. The various high availability requirements have been integrated into the architecture of the controller 120. The integrated redundancy architecture is platform agnostic. The remote terminal unit SCD6000 available from Schneider Electric is suitable to meet both the functional and performance requirements of these systems and is suitable to implement the redundancy architecture of the present disclosure.

[0053] As Figure 2As shown, in addition to control functions, the disclosed controller 120 also performs functions typically associated with a gateway. The controller 120 in the illustrated embodiment includes three interfaces (one for the process control network, one for the LV network, and one for the MV network), as well as a unique high availability architecture for process and electrical control. Each of the three interfaces has unique requirements for redundancy. One controller (active node) communicates with other nodes on the process control network. The active node can scan and control nodes on the LV network. Both the active node and the standby node run simultaneously on the MV network. In one embodiment, each interface requires three redundancy schemes: hot-cold on the process control network; hot-warm on the LV network; and hot-hot on the MV network. The redundancy operation of the controller 120 has different performance requirements on each interface. Advantageously, the controller 120 supports all DCS services and networks, and also supports various unique redundancy schemes (hot-cold redundancy, hot-warm redundancy, hot-hot redundancy) without losing event reporting from sources.

[0054] The electrical controller 120 has a unique HA architecture as shown in Figure 2 which provides application-independent interfaces to tasks to be synchronized. Application-specific synchronization is the responsibility of the respective task. It synchronizes the state and data of the application task. This allows customization of the HA architecture to meet the synchronization needs of DCS and EMCS.

[0055] Figure 3 is a block diagram illustrating a unified namespace for process and power domains according to an embodiment. Open standard protocols from the process and power domains update data to the same database. Aspects of the disclosure provide seamless namespace translation from power to process and from process to power, as well as seamless data flow without latency of data updates. No gateway is needed for data acquisition and control. As shown in Figure 3 the flexible architecture allows addition of any open standard protocol. In the illustrated embodiment, the distributed control middleware is a DCS component, and the medium voltage client is an IC block component.

[0056] Figure 4 is a block diagram illustrating a common control engine for process and power domains according to an embodiment. Data from the power and process domains is collected into the same database. Control strategies are performed seamlessly on data from both domains. Typically, conditions from the power domain can be used to control equipment (e.g., motors) in the process. Control can be performed on both domains. As shown, the common control engine is a DCS component, and electrical data is from an IEC 61850 client.

[0057] Figure 5is a block diagram illustrating common SOE / alarm across process, power, and safety domains according to one embodiment. Data from the power and process domains collected into the same database allows for generation of alarms and SOEs. Alarms are generated from the control engine. SOEs are generated asynchronously from the control object processor. Time stamps of the source are saved for both alarms and SOEs. The illustrated embodiment also provides support for operator action journal (OAJ). As shown, the common control engine, alarm / SOE processor, and alarm / SOE server are DCS components, and electrical data is from an IEC 61850 client.

[0058] Figure 6 is a block diagram illustrating multi-protocol support for power and process domains according to an embodiment. A flexible and scalable architecture such as provided in the present disclosure allows for the addition of various open standard protocols from both the process and power domains. Controller 120 can be a citizen of both DCS and EMCS for process control. In addition to cyclic control of both process and power equipment, it can respond asynchronously to events from electrical equipment / IEDs. As shown, distributed control middleware is a DCS component, while IEC 61850 server, electrical protocol #1, and electrical protocol #2 are third party stack components.

[0059] Figure 7 is a block diagram illustrating support for both cyclic and event driven control engines for process and electrical domains according to an embodiment. A scan and event driven (IEC 61499) control engine is provided for process and power control applications. Asynchronous events from the power domain can be handled independently of the scan based control of the process domain. Aspects of the present disclosure also support efficient CPU usage and increased IO count. As shown, the cyclic control engine is a DCS component, and electrical data is from an IEC 61850 client.

[0060] Figure 8 is a block diagram illustrating a time synchronization process for downstream IEDs over SNTP or PTP, as familiar to those skilled in the art. The illustrated controller 120 provides flexibility in configuration of the controller's time synchronization. It can act as both an SNTP client and server, and allows for time synchronization of downstream LV equipment. Optionally, controller 120 can also act as a PTP server or client. When configured as an SNTP server, the time of downstream LV equipment is synchronized.

[0061] Figure 9is a block diagram illustrating an embodiment of a high availability (hot-cold redundancy) architecture for synchronizing process control. A high availability mechanism, referred to as a synchronization manager 202A, 202B, is defined to synchronize the functions of two controllers 120A, 120B configured as active (or hot) and standby controllers, respectively. As shown, a synchronization manager 202A is executed on controller 120A of, for example, process system 104, and a synchronization manager 202B is executed on controller 120B of, for example, electrical system 102, or vice versa. Controllers 120A, 120B can both perform process or power functions, one active and the other standby. The same controller can work on both networks (power and process), resulting in the exchange of data and commands between the two networks. This abstraction mechanism provides one or more application programming interfaces (APIs) for synchronizing the functions of one or more application tasks 204A, 206A executed on controller 120A and corresponding application tasks 204B, 206B executed on controller 120B. It should be understood that a synchronization manager interface, such as synchronization managers 202A, 202B, synchronizes any number of one or more application tasks.

[0062] Synchronization managers 202A, 202B ensure that application tasks 204A, 204B are executed synchronously, and that application tasks 206A, 206B are executed synchronously, with the details of the synchronization handled by the application tasks themselves. Synchronization is achieved through synchronization points (also referred to as synchronization points), which are points of execution of application tasks 204A, 204B and 206A, 206B that ensure the synchronous execution of the tasks. Synchronization points are defined for the same domain (power / process) controller application tasks. The two controllers that make up a hot / standby pair run the same application (same configuration and firmware), so the application tasks are identical on both peer controllers.

[0063] The APIs provided by synchronization managers 202A, 202B ensure the synchronization of application "state" and "data". In embodiments, synchronization managers 202A, 202B transmit a first state to the same domain (power / process) controller running the same application (configuration and firmware). These APIs report "success" or "failure" or "timeout" of the synchronization operation. Application tasks 204A, 204B and 206A, 206B determine the action to be taken after synchronization. Due to the application-agnostic nature of the synchronization APIs, any application task in controller 120 can use them and build its own synchronization mechanism based on the application-specific functionality. Thus, synchronization managers 202A, 202B can be used by any controller 120 that has a free communication interface for synchronization. Advantageously, no hardware modifications are required in existing controllers 120 to achieve the high availability of operations.

[0064] Aspects of the present disclosure provide a high availability scheme that defines an abstract synchronization scheme that is agnostic to both the platform and the application. The scheme allows simplex controllers to be converted to hot / standby controller pairs 120A, 120B without requiring any hardware modifications. It can work over existing communication interfaces (e.g., lower bandwidth (as low as 2.5 MBPS)) and is agnostic to the communication technology. This is achieved by minimizing the data throughput for synchronization. By defining loosely coupled controllers, the overall efficiency of controller operation is also improved in a redundant pair configuration. In this way, aspects of the present disclosure provide a controller that is capable of high availability of the following: control applications; controller online configuration and diagnostics; alarms; SOEs; data distribution command communication; network channels (network communication); data acquisition and control (e.g., Modbus, IEC 61850, and hardwired inputs / outputs); and the like.

[0065] In one embodiment, a unified diagnostic tool (system manager) monitors the functionality of both the process control system 104 and the electrical system 102. The diagnostic tool is used to monitor the health information of the electrical controllers 120 and the electrical equipment monitored / controlled thereby.

[0066] Further reference Figure 9 The synchronization managers 202A, 202B provide an application agnostic synchronization mechanism for synchronization of the application tasks 204A, 204B and 206A, 206B. This abstract mechanism defines an application interface for state and data synchronization, while application specific synchronization is defined by the application tasks themselves. Both nodes, active and standby, on their respective networks, run simultaneously for the data they can receive independently, and share the data available to the active node, i.e., the controller 120A. The low data throughput of the synchronization is used for the minimum data for application synchronization. In operation, the synchronization managers 202A, 202B define synchronization points, which are execution statements in the application tasks 204A, 204B and 206A, 206B to be synchronized, and exchange synchronization messages. The synchronization managers 202A, 202B report synchronization success, synchronization failure / timeout to the respective application tasks 204A, 204B, 206A, 206B. In turn, the application tasks 204A, 204B, 206A, 206B define any synchronization actions following the synchronization feedback. In one embodiment, each node periodically checks for the existence of its peer and determines whether the role of the node is active or standby. If the peer node is lost, it needs to be recovered once it comes back online. In this case, the databases are shared with the peer and re-synchronization is established after recovery.

[0067] A synchronization mechanism based on a synchronization manager to synchronize the state and data of application tasks. A high availability controller that synchronizes state and data between power and process domains using an application programming interface is described in U.S. Patent Application No. 17 / 679,744, filed February 24, 2022, the entirety of which is incorporated herein by reference. Both nodes run simultaneously by synchronizing the state of the application tasks. Minimal data is exchanged between the two nodes. The active node communicates with other nodes on the process control network and updates the standby node. The active node sends a one-time and periodic synchronization message and expects a response from the standby node.

[0068] Figure 10 A high availability (hot-warm redundancy) architecture for low voltage control is shown according to an embodiment, including a proprietary redundancy protocol that provides synchronization of the controller database from the active node to the standby node. Event-driven updates save the number of updates, and standard objects are defined for data synchronization. The active node scans the LV devices and issues commands, and the standby node maintains the transmission connection to the LV devices. In this embodiment, file transfer enables configuration and firmware updates, and redundancy control uses role determination and checks the health of the redundancy link.

[0069] Figure 11 A high availability (hot-hot redundancy) architecture for medium voltage control is shown according to an embodiment. Both the active and standby nodes run the MV server and MV client applications simultaneously. A synchronization manager is used to ensure synchronization of the applications between the active and standby nodes. A high availability controller that synchronizes state and data between power and process domains using an application programming interface is described in U.S. Patent Application No. 17 / 679,744, filed February 24, 2022, the entirety of which is incorporated herein by reference. In this embodiment, the MV server publishes redundancy status via a standard communication protocol (e.g., IEC 61850). The MV client subscribes to the communication from the server to know its redundancy status. It receives data from the active server node and discards data from the standby server node. Commands are issued to the active server node.

[0070] Figure 12 A high availability (hot-hot redundancy) command synchronization process is shown according to an embodiment. In the embodiment shown, commands are processed by both the active and standby nodes. The redundancy status of the server IED is checked. The active controller sends commands to the active server. The command execution is then synchronized with the standby node. The standby node discards the command after synchronization. In the event of a failure of the active node prior to synchronization, the standby node reissues the command.

[0071] Figure 13A high availability (hot-hot redundancy) reporting synchronization process according to an embodiment is shown. Reporting is handled by both active and standby nodes. Filtering of the reports is done using an algorithm based on time and quality parameters of the data attributes. Typically, data from the active server is filtered for updates, and in the case of switchover, data from the standby node is updated.

[0072] Figure 14 and 15 Other aspects of the present disclosure are shown. In one embodiment, a user interface presenting a navigational dynamic list view allows quick navigation from single line diagram (SLD) and list view to dynamic detail panels for each device. A low latency high availability interface to an electrical network according to aspects of the present disclosure provides a high level of network security in a simpler design - the Common Information Model {C:B:P}. Figure 14 Components of an integrated process and power system according to one or more embodiments are determined. Figure 15 is a block diagram showing example data flows in which only data and controls needed from the ECMS system are extracted.

[0073] In operation, a method embodying aspects of the present disclosure performs process control and monitoring and electrical control signaling and monitoring within the same control strategy directly from the controller. The method includes mapping a uniform namespace based on unique process control names to source IED names based on IEC 61850 namespace, and automating DCS function_block.parameter across process and electrical domains. The method also includes incorporating all SOEs originating from IEC 61850 connected IEDs within a common process, safety, and electrical SOE record set, and incorporating SOE buffers to allow publishing of all pending events with source time tags without disruption or constraint to control processor cycles. Advantageously, the method provides the ability to manage multiple different protocols in both client and server form within the same DCS controller, to respond asynchronously to protocol requests including polling, buffered, and unbuffered for connection based protocols within the same controller, and to support time synchronization of downstream IEDs via PTP or SNTP protocols.

[0074] Further, the controller supports all DCS services and networks and one or more of the following unique redundancy schemes: high availability redundancy on the DCS control information network co-resident with a fault-tolerant peer controller; hot / hot parallel redundancy supporting electrical management systems attached via IEC 61850 servers; and hot / warm failover redundancy supporting single and dual connected Modbus / TCP devices. In one embodiment, there is no loss of event reporting from sources.

[0075] Furthermore, there is no common mode failure of memory or processor or network interface within the controller prior to the fault tolerant controller. Common mode failures are avoided by eliminating the control bus between the two controllers and synchronization and coordination of database cloning between the controllers is achieved by using fault resilient serial and token ring connections of different paths. A memory failure on one controller will not propagate to the backup controller without detection. And a network failure on any interface on one controller will not cause a failure of the corresponding network interface on the backup controller.

[0076] Aspects of the present disclosure advantageously provide several benefits over conventional controllers. For example, the unified namespace of the gateway and control functions allows publishing control of electrical protocols, including hardwired control as well as "softwired" control (publishing control of IEC 61850 clients). Real-time updates of corresponding electrical parameters due to the common address space allow efficient process control strategies to be established with relevant electrical parameters, resulting in improved process control and operation. Also, the elimination of separate controller and gateway nodes improves latency of data updates and command execution from the field. In an aspect, the controller 120 is dual-ported (on the EMCS and DCS networks), which provides information consistency and improved overall engineering efficiency by eliminating data mapping for different nodes on the two networks.

[0077] This common infrastructure on the process and electrical systems eliminates the gateway and hardwired IO modules with the unified controller 120 and enables the use of common HMI and historian and common network security methods between the DCS and EMCS systems. For example, the common infrastructure enabled by the unified controller 120 allows Figure 1 The control HMI of the process system 104 is configured to monitor not only DCS operations but also EMCS operations. In this embodiment, the control HMI presents a user interface that displays, in addition to process side information, the substation layout of the electrical system 102 with voltage levels. In other words, the operator can view electrical side information in the process side HMI. Similarly, the process operator 126 can include diagnostic tools that are able to initiate electrical system diagnostics from both the process side and the unified backup. The unified namespace of data from the DCS and EMCS systems also allows common SOE to be generated (from both the process and electrical systems), improving post-trip analysis.

[0078] Data from the electrical system (LV & MV system) is sent from the electrical controller 120 to the control HMI. The control HMI allows the operator to view both process data and related electrical data on the same screen. The operator can also issue commands to operate the IEDs 110 in the electrical system 102. Additionally, alarms and SOEs from the electrical system 102 are shown together with process alarms, enabling efficient analysis of any plant equipment trip or similar issues.

[0079] Reference is now made to Figure 16 Engineering workflow. IEC 61850 based system specification and system configuration tools, such as EcoStruxure TM The Electrical Power Automation System Engineering (EPAS-E) receives device configuration template files for the MV devices. The EPAS-E tool provides electrical system configuration (e.g., reporting subscriptions, one-line diagrams, electrical data mapping). The RTU station toolset for the electrical controller receives the IEC 61850 based configuration files from the EPAS-E tool, device templates for the LV devices, and DCS system (SYSDEF) configuration. In the illustrated embodiment, the RTU station toolset provides an export function for exporting electrical system configuration data to batch data objects responsible for instantiating templates for DCS control strategy and state view configuration. The batch data objects are part of the Foxboro Control Editor software available from Schneider Electric. The Control Editor deploys control strategies to the unified electrical controller 120 as well as the control processor 132. Additionally, the RTU station toolset downloads LV / MV device communication configuration to the unified electrical controller 120.

[0080] In one embodiment, as a common citizen of both the DCS and EMCS systems, the electrical controller 120 adheres to the high availability (HA) requirements of both systems. For example, the DCS system requires a hot-standby HA architecture, where only the hot node communicates with other nodes on the network. The standby node does not establish a connection with other nodes on the control network, and it is continuously updated to synchronize with the hot node. In the event of a failure of the hot node, the standby node transparently takes over without any impact to the process. On the other hand, the EMCS system requires a hot-hot HA architecture for the MV / IEC61850 network, where both nodes are simultaneously communicating with other nodes in the MV network. The nodes on the network accept data from one of the controller nodes and discard data from the other node. This is required to achieve seamless redundancy so that there is no loss of events during failover of the controller. The EMCS system requires a hot-warm HA architecture for the LV / Modbus network, where only the hot node actively communicates with the LV (Modbus) devices, while the warm node only maintains a network connection to the LV devices. In the event of a failover, the warm node will resume communication with the LV devices without any delay for establishing the connection.

[0081] Figure 18 is a block diagram illustrating multiple control engines for process and electrical domains. According to an embodiment, the electrical controller hosts multiple control engines suitable for both DCS and EMCS. Periodic, block-based control engines are implemented, which run control strategies for either the process or electrical or both systems. For example, for periodic control engines, a typical scan period of 200 / 500 milliseconds is implemented. For electrical systems, which typically require faster response times of 10-20 milliseconds, event-driven control engines are used. To handle sequential operations of the plant, a dedicated control engine is used, which is capable of running user-defined custom logic for control and automation needs. Allowing a common address space to host different communication protocols and control engines also allows interconnection of control engines. For example, as part of a DCS control strategy, a command to start a set of motors is issued from a periodic control engine. The output command is propagated to EMCS using an event-driven control engine. Similarly, a command from EMCS to trigger a fast load shedding is received through the GOOSE protocol, and executed by an event-driven control engine. The output command is propagated to a periodic control engine, which can stop a set of motors in the plant. This facilitates development of complex control strategies, i.e., outputs from one control engine can be used as inputs to another control engine.

[0082] Figure 18 An event-driven control engine is illustrated, for which any field event received can be used to trigger control. A state machine execution engine executes user-defined complex control strategies, which include sequential control driven by state machines. Figure 18The common control engines periodically execute process control strategies. Synchronization of these control engines is achieved using a controller database (common address space) and command queues. The output of the common control engines can be input to two other engines to perform control of the electrical system. In addition, an event driven engine performs fast event driven control and updates the common control engine, a state machine execution engine performs complex batch operations and also updates the common control engine.

[0083] Figure 19 is a block diagram illustrating an event driven control engine for process and electrical domains according to an embodiment. As shown, an IEC 61850 GOOSE user receives a TRIP command from the EMCS via a GOOSE message. The command is updated to the controller database (common address space) and the command is presented (via control object processor) to the event driven control engine. The event driven control engine immediately executes the command (driven by event reception) and updates the controller database after execution. The result of the command execution is presented (via control object processor) to the common control engine and the result is published to the control HMI.

[0084] Figure 20 is a block diagram illustrating a state and logic control engine for process and electrical domains according to an embodiment. In Figure 20 , a DCS command to run a batch control (e.g., start a group of motors) is received and processed by a DCS command processor. The command is updated to the control database consisting of control strategies. The common control engine executes the strategies at periodic intervals and updates the command to the controller database (common address space). The command is presented (via control object processor) to the state machine execution engine, which executes user defined complex control logic based on the received command. The resulting command is sent from the state machine execution engine to the field.

[0085] Figure 21 is a block diagram illustrating a unified namespace for process and electrical domains according to an embodiment. Open standard protocols from process and electrical domains update data to the same database. Aspects of the present disclosure provide seamless namespace translation from electrical to process and from process to electrical, as well as seamless data flow with no latency for data updates. No gateway is needed for data acquisition and control. As shown in Figure 21 , the flexible architecture allows for the addition of any open standard protocol. In the illustrated embodiment, the distributed control middleware is a DCS component and the combined module: module: parameters are associated with DCS tag names.

[0086] Figure 22is a block diagram illustrating a common control engine for process and power domains according to an embodiment. Data from the power and process domains is collected into the same database. Control strategies are seamlessly executed on data from both domains. Typically, conditions from the power domain can be used to control equipment in the process (e.g., motors). Control can be performed on both domains. As shown, the common control engine is a DCS component.

[0087] Figure 23 is a block diagram illustrating common SOE / alarms across process, power, and safety domains according to an embodiment. Data from the power and process domains is collected into the same database, which allows for generation of alarms and SOEs. Alarms are generated from the control engine. SOEs are generated asynchronously from the control object processor. Time stamps of sources are saved for both alarms and SOEs. The illustrated embodiment also provides support for operator action journal (OAJ). As shown, the common control engine, alarm / SOE processor, and alarm / SOE server are DCS components.

[0088] Figure 24 is a block diagram illustrating multi-protocol support for power and process domains according to an embodiment. A flexible and scalable architecture such as provided in the present disclosure allows for addition of various open standard protocols from both process and power domains. Controller 120 can be a citizen of both DCS and EMCS for process control. In addition to cyclic control of both process and power equipment, it can asynchronously respond to events from electrical devices / IEDs. As shown, the distributed control middleware is a DCS component.

[0089] Figure 25 is a block diagram illustrating support for both cyclic and event-driven control engines for process and power domains according to an embodiment. Scan and event-driven (IEC 61499) control engines are provided for process and power control applications. Asynchronous events from the power domain can be handled independently of the scan-based control of the process domain. Aspects of the present disclosure also support efficient CPU usage and increased IO count. As shown, the common control engine is a DCS component.

[0090] Commonly-assigned U.S. Patent Application No. 18 / 124,852, filed March 22, 2023, describes aspects of a unified dynamic controller for power and process applications, the entire disclosure of which is incorporated herein by reference.

[0091] Embodiments of the present disclosure can include a special-purpose computer that includes various computer hardware, as described in greater detail herein.

[0092] For purposes of illustration, programs and other executable program components, such as program tasks, are shown herein as discrete blocks. However, these program components, and others, can reside within a computer's memory during execution thereof, by a processor or processors of the computer, and other devices as appropriate, and can be written into storage media as described above.

[0093] Although described in connection with an example computing system environment, embodiments of aspects of the application can be used in other specialized computing system environments or configurations. The computing system environment is not intended to suggest any limitation as to the scope of use or functionality of any aspect of the application. Moreover, the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example operating environment. Examples of computing system, environments, and / or configurations that can be suitable for use with aspects of the application include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

[0094] Embodiments of aspects of the present disclosure can be described in the general context of data and / or processor-executable instructions, such as program modules, being stored on one or more tangible, non-transitory storage media and executed by one or more processors or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Aspects of the present disclosure can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

[0095] In operation, processors, computers, and / or servers can execute processor-executable instructions, such as those illustrated herein (e.g., software, firmware, and / or hardware), to implement aspects of the present application.

[0096] Embodiments can be implemented in processor-executable instructions. The processor-executable instructions can be organized into one or more processor-executable components or modules on a tangible processor-readable storage medium. Also, the embodiments can be implemented with any number and organization of such components or modules to include fewer, more, different, and / or different arrangements of components or modules than those illustrated and described herein. For example, aspects of the present disclosure are not limited to the particular processor-executable instructions or the particular components or modules illustrated in the figures and described herein. Other embodiments can include different processor-executable instructions or components with more or less functionality than those described and illustrated herein.

[0097] The order of execution or performance of the operations in accordance with the aspects of the disclosure illustrated and described above are not essential, unless otherwise specified. That is, unless otherwise specified, the operations can be performed in any order, and embodiments can include more or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, concurrently with, or after another operation is within the scope of the disclosure.

[0098] When introducing elements of the present application or the embodiments thereof, the articles "a," "an," "the," and "said" are intended to mean that there are one or more of the elements. The terms "comprising," "including," and "having" are intended to be inclusive and mean that there can be additional elements other than the listed elements.

[0099] All of the illustrated or described components can not be required. Additionally, some implementations and embodiments can include additional components. Variations in the arrangement and type of components can be made without departing from the spirit or ambit of the claims set out herein. Additionally, different or fewer components can be provided, and components can be combined. Alternatively, or additionally, components can be implemented by several components.

[0100] The above description illustrates embodiments by way of example and not by way of limitation. This description enables others skilled in the art to make and use the aspects of the application, and describes several embodiments, modifications, variations, alternatives, and uses of the application, including the best mode contemplated for carrying out the aspects of the application. Additionally, it is to be understood that the aspects of the application apply to other embodiments and can be practiced or carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. It is therefore contemplated to cover any and all modifications, variations, changes, alternatives, and equivalents that fall within the spirit and scope of the aspects of the application.

[0101] However, it is apparent that modifications and changes can be made without departing from the scope of the application as defined in the appended claims. Since many modifications, variations, changes, and alternatives can be made in the structure and arrangement of the parts and method steps according to the application, what is desired to be protected by letters patent is not the invention per se, but as such changes, modifications, variations, alternatives, and equivalents that follow in the spirit and scope of the aspects of the application.

[0102] In light of the above, it will be seen that the objects of the aspects of the application are achieved and other advantageous results attained.

[0103] The abstract and summary are provided to assist the reader in quickly ascertaining the nature of the technical disclosure. They are submitted with the understanding that they will not be used to interpret or limit the scope or meaning of the claims. The summary is provided in order to present some concepts of the disclosure in a simplified form as a prelude to the more detailed description that is to follow. The abstract is not intended to be used to interpret or limit the scope or meaning of the claims.

Claims

1. A method for configuring a controller in both a process domain and a power domain for industrial operation, the power domain including one or more intelligent electronic devices (IEDs), the method comprising: Map the unified namespace to the source device name of the IED in the power domain, where the unified namespace is based on the unique process control name of the process domain; Generate a common record set for sequence of events (SOE) for the process domain and power domain, and incorporate SOEs generated from IEDs into the common record set; Receive one or more commands from the control system of industrial operation; Update the unified namespace using the received commands; The received commands are presented to one or more control engines for execution; as well as Update the unified namespace after executing the received command.

2. The method according to claim 1, wherein, The controller performs process control and monitoring, as well as the transmission and monitoring of electrical control signals, within a single control strategy directly derived from the controller.

3. The method according to any one of claims 1-2 further includes storing data events from the power domain point by point for processing within the processing cycle of the process domain.

4. The method according to any one of claims 1-3 further includes publishing pending events with source timestamp information and incorporating them into an SOE buffer to allow the publication of pending events with source timestamps without interfering with or constraining the control processor cycle.

5. The method according to any one of claims 1-4, further comprising managing multiple dissimilar protocols within the controller in the form of both clients and servers.

6. The method according to any one of claims 1-5, further comprising asynchronously responding to protocol requests for connection-based protocols within the controller.

7. The method according to any one of claims 1-6 further includes synchronizing the IED via at least one of Precise Time Protocol (PTP) and Simple Network Time Protocol (SNTP).

8. The method according to any one of claims 1-7, further comprising identifying application tasks executed on the controller and on a standby controller capable of being synchronized therewith, and synchronizing the execution of the application tasks on the controller and the standby controller, wherein the controller and the standby controller integrate the process domain and power domain of industrial operation.

9. The method according to any one of claims 1-8, wherein the controller includes a first interface associated with a process control network, a second interface associated with a low-voltage (LV) network, and a third interface associated with a medium-voltage (MV) network, and further includes implementing a first redundancy scheme on the process control network, a second redundancy scheme on the LV network, and a third redundancy scheme on the MV network, the first redundancy scheme, the second redundancy scheme, and the third redundancy scheme being different from each other, and further includes coupling a backup controller to the controller via a redundant link, wherein the controller and the backup controller coupled to the controller integrate the process domain and power domain of industrial operation, and further includes coupling both the controller and the backup controller to the first interface, the second interface, and the third interface.

10. An electrodynamic controller having a high-availability architecture for control in both the process domain and electrical domain for industrial operation, comprising: A database stores a unified namespace, which maps the source device name of a device in the power domain to the unique process control name of the process domain. processor; as well as A memory device that stores processor-executable instructions, which, when executed, configure the processor for: Receive one or more commands from the control system of industrial operation; Update the unified namespace using the received commands; The received commands are presented to one or more control engines for execution; as well as Update the unified namespace after executing the received command.

11. The controller of claim 10, further comprising: The first interface associated with the process control network; A second interface associated with a low-voltage (LV) network; as well as A third interface associated with a medium-voltage (MV) network; The first redundancy scheme, the second redundancy scheme, and the third redundancy scheme are different from each other, and the controller is configured to implement the first redundancy scheme on the process control network, the second redundancy scheme on the LV network, and the third redundancy scheme on the MV network, and the first interface, the second interface, and the third interface each have different performance requirements and capabilities.

12. The controller of claim 11, further comprising at least one active node and at least one standby node, each active node and standby node coupled to a first interface, a second interface and a third interface, wherein the at least one active node is coupled to the at least one standby node via a redundant link, wherein the at least one active node communicates with other nodes in the process domain to perform both process control and monitoring, wherein the at least one active node scans and controls nodes on the LV network, and wherein both the at least one active node and the at least one standby node operate simultaneously on the MV network.

13. The controller according to any one of claims 10-12, wherein the control system comprises an electrical monitoring and control system (EMCS), and the one or more control engines comprise an event-driven control engine, and wherein the memory device stores processor-executable instructions, which, when executed, further configure the processor to: The results of the executed commands are presented to the common control engine for use in the human-machine interface (HMI) published to EMCS.

14. The controller according to any one of claims 10-12, wherein, The control system includes a distributed control system (DCS), and the one or more control engines include a state machine execution engine, wherein the state machine execution engine executes user-defined complex control logic based on one or more received commands, and wherein a memory device stores processor-executable instructions, which, when executed, further configure the processor for: Present the results of the executed command to the process domain.

15. The controller according to any one of claims 10-12, wherein, The one or more commands are received from an Electrical Monitoring and Control System (EMCS) and a Distributed Control System (DCS), wherein the one or more control engines include an event-driven control engine associated with the EMCS and a state machine execution engine associated with the DCS, wherein the state machine execution engine executes user-defined complex control logic based on the received one or more commands, and wherein a memory device stores processor-executable instructions, which, when executed, further configure the processor for: The results of commands executed by the event-driven control engine are presented to the common control engine for publication into the EMCS's human-machine interface (HMI); and The results of commands executed by the state machine execution engine are presented to the process domain.

Images