Transmitting default alarm configuration files determined based on function block type to distributed control node (DCN)

Abstract

To solve various technical challenges in creating, updating and deploying alarms in process automation systems.SOLUTION: A default alarm configuration file, determined based on a particular type of function block, is transmitted to a distributed control node (DCN). The default alarm configuration file is transmitted to the DCN based on a determination that the DCN is implementing a particular type of function block or utilizing a particular type of function block in alarm monitoring. The default alarm configuration file transmitted to the DCN may be stored locally to make it viewable and editable via an interfacing human machine interface (HMI). Local updates made via the HMI to a locally stored default alarm configuration file are reflected in an alarm database accessible via the process automation network.SELECTED DRAWING: Figure 1

Description

Background Art

[0001] Alarms are used in process automation systems to detect potential anomalies and initiate actions in response to the detection of potential anomalies. Potential anomalies can relate to the process automation system and / or to the process automation process in which the process automation system is implemented. Actions for alarms can include, for example, displaying corresponding notifications at an interface monitored by an operator and / or automatically performing a repair (e.g., an automated process or subprocess that is automatically stopped or adjusted). As an example, an alarm can be configured to monitor sensor readings from sensors of a process automation system and display corresponding notifications when the sensor readings exceed a high value (and / or a high-high value) and / or fall below a low value (and / or a low-low value).

[0002] In some process automation systems, all of the hardware and / or software of the process automation control nodes of the process automation system can be supplied and / or managed by a single entity (e.g., a single company). This enables the single entity to utilize its own techniques to create and manage alarms associated with the corresponding process automation control nodes.

[0003] However, other process automation systems include heterogeneous hardware and / or heterogeneous software that is supplied and / or managed by multiple entities and / or deployed in a distributed manner. For example, a process automation system can include some process automation control nodes supplied and / or managed by a first entity, other process automation control nodes supplied and / or managed by a second entity, and so on. Each process automation control node can have different hardware and / or software specifications, including different functional blocks that define the control executed by the process automation control node.

[0004] A process automation control node can include a distributed control node (DCN) that includes hardware (e.g., a processor, memory, network interface, input and / or output ports, and / or other hardware), and software (e.g., functional blocks) that is performed by at least some of the hardware. For example, the software can be included in the memory of the DCN and performed by the processor of the DCN. The software of the DCN can utilize, for example, data from the input port of the DCN and / or data from other DCNs during execution, and / or generate outputs for providing (e.g., transmitting to one or more endpoints via the process automation network of the process automation system) via the output port and / or network interface. SUMMARY OF THE INVENTION PROBLEMS TO BE SOLVED BY THE INVENTION

[0005] In a process automation system that includes distributed and / or heterogeneous hardware and / or software, there are various technical challenges when generating, updating, and / or deploying process automation alarms. For example, a process automation alarm may require monitoring of process variables of a particular function block, such as input variables, output variables, and / or internal variables of the particular function block, by an alarm engine. In order to enable the alarm engine to monitor those process variables, a DCN that generates and / or enables access to the process variables needs to be accessible to the alarm engine. Further, the alarm engine needs to access and utilize an appropriate alarm setting file when monitoring the occurrence of corresponding alarm conditions and generating corresponding actions in response thereto. The alarm setting file can define conditions for corresponding process variables, and when the conditions are met, cause the alarm engine to initiate corresponding actions. Further, when an action includes initiating rendering of a corresponding output in an alarm viewer (e.g., visual and / or audible rendering), it may be necessary or desirable to establish a connection-oriented connection between the alarm engine and the alarm viewer.

[0006] However, due to the distributed and / or heterogeneous nature of process automation systems, it can be cumbersome and / or error-prone to achieve one or more of the requirements and / or specifications mentioned above or elsewhere in this specification. As an example, assume that an alarm configuration file is stored locally in a particular DCN and is utilized by the local alarm engine of that particular DCN when monitoring process variables of a particular functional block on that particular DCN (e.g., monitoring the values of those variables during the execution of the particular functional block). Further assume that the alarm configuration file is stored locally and utilized by a particular DCN based on being pre-loaded into that particular DCN (prior to commissioning of the DCN in the process automation system) or based on being set up completely manually by a human-machine interface (HMI) coupled to the DCN during commissioning. If a particular DCN is replaced with a new DCN and the same functional blocks are being executed, it may be necessary to manually pre-load the alarm configuration file into the new DCN or manually configure the new DCN via the HMI. Similarly, if a particular functional block and / or alarm engine is removed from a particular DCN and newly implemented in an alternative DCN, it may be necessary to manually re-assign the alarm configuration file to the alternative DCN. Manual re-assignment is not only cumbersome and requires the use of computing resources, but if an error occurs during manual re-assignment, the corresponding alarm may not actually be active or may be inaccurate (e.g., because different values are defined), resulting in the inability to monitor the occurrence of alarm conditions, the non-execution of corresponding actions, and potentially dangerous states or other adverse effects on the process automation configuration.

[0007] If you want to be able to locally configure process automation alarms in a DCN, these and / or other issues may be exacerbated. For example, there may be a desire for employees or contractors in process automation facilities to be able to configure process automation alarms for functional blocks through user interaction with a human-machine interface (HMI) that directly interfaces with the DCN. The HMI can interface directly with the DCN after authentication (e.g., using a username and / or password) is performed via a wired or wireless connection to the DCN and optionally via input to the HMI. For example, it may be desired to locally specify values that define the conditions of a process automation alarm or locally specify the values of other parameters of a process automation alarm (e.g., an alarm sensitivity value, the content of an alarm message, and / or the values of other parameters). However, local adaptations made through interaction with a given DCN may not be reflected in a new DCN that replaces the given DCN and / or when a functional block is removed from a given DCN and implemented in an alternative DCN. Further, those local specifications may not be reflected in a central database that can be used by a non-local alarm configuration GUI that enables viewing and / or editing of all alarms in the system.

Means for Solving the Problems

[0008] The implementations disclosed herein address these and other challenges by automatically deploying a default alarm configuration file to a DCN. In these implementations, when automatically deploying the default alarm configuration file to the DCN, the default alarm configuration file is determined based on the functional block types of the functional blocks that are performed by the DCN and / or utilized by the DCN's local alarm engine during alarm monitoring. For example, in the case of the "AO" functional block type, the default alarm configuration file can include files of "error", "level", "rate of change", and "deviation" alarm types, but alarm types such as "discrete", "answerback mismatch", and / or "answerback error" are omitted. As another example, in the case of the "DI" functional block type, the default alarm configuration file can include files of "error" and "discrete state" alarm types, but alarm types such as "rate of change", "level", "deviation", "answerback mismatch", and / or "answerback error" are omitted.

[0009] As noted above, the default alarm configuration file deployed to the DCN can be deployed to the DCN in response to a determination that the DCN performs a particular type of functional block corresponding to the default alarm configuration file and / or a determination that the DCN implements alarm monitoring based on a particular type of functional block. For example, the DCN can transmit an alarm configuration request including the functional block identifiers of the functional blocks that are performed by the DCN and / or utilized during alarm monitoring by the DCN to an alarm configuration service via a process automation network. The alarm configuration service can determine the functional block type based on the functional block identifiers of the alarm configuration request. Further, in response to the request, the alarm configuration service can transmit the default alarm configuration files of those functional block types to the DCN.

[0010] As an example, a given function block can have a function block identifier of "FT101.PV". The function block identifier "FT101.PV" can be generated by the programmer of the given function block when creating the given function block, can be created automatically, or can be created or generated to be unique with respect to all other function block identifiers of all other function blocks of the process automation system. Further, a part of the function block identifier can indicate the type of the function block and can conform to a standardized type designation scheme. For example, "PV" in "FT101.PV" can indicate that the function block is of the "process variable" type. Also, for example, ".AI" can indicate a function block of the "analog input" type, ".AO" can indicate a function block of the "analog output" type, and / or ".PID" can indicate a function block of the "proportional-integral-derivative" type. In some of these or other implementations, at least a part of the function block identifier may not conform to a standardized designation scheme, but is semantically meaningful and / or may conform to a non-standardized designation scheme of the programmer and / or entity implementing the process automation system. "FT101" in "FT101.PV" is an example of such a part of the function block identifier. For example, in a process automation system, there may be multiple function block identifiers ending with ".PV". However, only one of them includes "FT101" before ".PV", and furthermore all of them include unique characters related to each other before ".PV". Thus, in various implementations, the alarm setting service can determine the function block type implemented by the DCN through processing of the function block identifier included in the alarm setting request from the DCN. For example, the alarm setting service can determine the function block type utilized by the DCN based on the suffix (e.g., the part following ".") of the function block identifier included in the alarm setting request from the DCN.

[0011] The default alarm setting file determined based on the function block type can include the conditions for the corresponding alarm type, but may or may not include the default values of the conditions. For example, in the case of the "analog input" function block type, the default alarm setting file can include the conditions for the "level" alarm type such as high-high, high, low, and low-low setpoint conditions. However, the default alarm setting file may or may not include the corresponding default value for each of those conditions. Rather, as described herein, the values of those conditions can be specified later via interaction with an HMI coupled to a DCN where the default alarm setting file is provided and locally stored.

[0012] In some implementations or situations, such as when access to the corresponding function block is available when determining the default alarm setting file, the default alarm setting file can include the actual process variables to which the conditions relate. In some alternative implementations or situations, the default setting file may or may not include placeholder process variables. Rather, they can be specified later via interaction with an HMI coupled to a DCN where the default alarm setting file is provided and locally stored. The default alarm setting file can include additional and / or alternative parameters, optionally defining default values and / or not defining values. For example, the default alarm setting file can specify a default security level (e.g., a default level defined for the function block type and / or alarm type), and / or can specify a default message (e.g., a default message defined for the function block type and / or alarm type) to be displayed in the alarm viewer when the corresponding condition is met.

[0013] The default alarm setting file transmitted to the DCN can be stored locally in the DCN so that it can be viewed and / or edited via an HMI that interfaces with the DCN. For example, the HMI can interface with the DCN, at least temporarily, via a wired connection (e.g., via the I / O of the DCN) or a wireless connection such as a wireless Bluetooth connection. The default alarm setting file stored locally in the DCN may initially have an invalid flag set, which prevents implementation by the DCN's alarm engine. The default alarm setting file stored locally in the DCN may also initially lack the values of conditions and / or other parameters and / or may include the initial default values of the parameters. When the HMI interfaces with the DCN, the HMI can enable viewing, editing, and / or deletion of the default alarm setting file. Further, the invalid flag of the default alarm setting file can be deleted or changed to a valid flag after the alarm setting file is updated via the HMI (and optionally after the update is confirmed) or after the default alarm setting file is confirmed via the HMI. When the invalid flag of the optionally updated default alarm setting file is deleted or changed to a valid flag, local alarm monitoring in the DCN can be started based on the optionally updated default alarm setting file.

[0014] By providing a default alarm configuration file according to the implementations disclosed herein, an operator can edit the default alarm configuration file (e.g., the values of its parameters) in a more efficient manner via the HMI using limited user interface inputs than creating the alarm configuration file from scratch via the HMI. Further, for alarm configuration files that an operator does not want to implement, they can be easily deleted or left in an inactive state via the HMI. Additionally, various implementations provide the default alarm configuration file to the DCN during DCN commissioning without requiring preloading of the default configuration file into the DCN, and / or provide only the default configuration files associated with the function blocks that are performed by and / or utilized in alarm monitoring by the DCN, preventing waste of DCN memory in storing irrelevant default configuration files.

[0015] The implementations disclosed herein relate to, additionally or alternatively, reflecting local updates made via an HMI to a default alarm settings file stored locally in a DCN in an alarm database accessible via a process automation network. For example, storing in the alarm database an updated alarm settings file based on the default alarm settings file transmitted to the DCN, the file including modifications to the default alarm settings file, the modifications responsive to inputs received via an HMI coupled to the DCN. Further, those implementations can also store in the alarm database an association between the updated alarm settings file and a functional block identifier of the functional block to which it pertains. Assignment of the updated alarm settings file to the functional block identifier can be done in addition to (or instead of) assignment of the alarm to a DCN identifier of the DCN that stores the updated alarm settings file locally for local use. For example, a given functional block can have an identifier such as "FT101.PV", which can be generated by a programmer of the given functional block and can be unique with respect to all other functional blocks of the system. Further, an updated default alarm settings file for alarm monitoring based on a given functional block can be stored in the alarm database, and an association between "FT101.PV" and the updated default alarm settings file can also be stored in the alarm database.

[0016] For example, the DCN can transmit an alarm setting update, including any updated alarm setting files locally modified in the DCN, to an alarm setting service that manages an alarm database, along with a functional block identifier to which the updated alarm setting file pertains. The DCN can send such a transmission in response to a local modification in the DCN. This enables the alarm setting service to update the alarm database in order to reflect the modification. This, in turn, enables browsing of the updated alarm setting files by a non-local alarm setting graphical user interface (GUI) and, optionally, further modification of the updated alarm setting files via the non-local alarm setting GUI (and then subsequent provision of the further modified alarm setting files to the DCN). Additionally, by associating and storing the alarm setting files with functional block identifiers, instead of providing corresponding default alarm setting files to a new DCN or an alternative DCN that later implements the functional blocks in place of the original DCN, an updated alarm setting file can be provided. For example, the new DCN or alternative DCN can provide an alarm setting request, including a functional block identifier, to the alarm setting service. The alarm setting service can use the functional block identifier of the request to identify an alarm setting file from the alarm database and return the identified alarm setting file to the DCN for implementation. In the absence of an alarm setting file stored in association with the functional block identifier, a default alarm setting file corresponding to the type of the functional block can be provided as described above.

[0017] The alarm setting service can be implemented on one or more servers coupled to the process automation network and can manage the alarm database and / or interact with the DCN as described herein. The alarm setting service can receive an alarm setting request from the DCN and, in response, provide a corresponding default alarm setting file. In some implementations, the alarm setting service can first search the alarm database based on the DCN identifier included in the alarm setting request to determine whether there is any unique (i.e., non-default) alarm setting file associated with the DCN identifier. If determined to be present, the unique alarm setting file can be transmitted to the DCN instead of the default alarm setting file. For example, the unique alarm setting file associated with the DCN identifier can be a file provided via a bulk upload, a file defined via interaction with a non-local alarm setting GUI, or a file provided in a previous update of the alarm setting (e.g., a file provided based on an HMI-based modification of the default alarm setting file). In such a manner, and in other ways, a newly commissioned DCN (e.g., commissioned at the initial commissioning of a process automation system or commissioned to replace a removed DCN) can obtain the appropriate default and / or unique alarm setting file using only the function block identifiers of the function blocks utilized (e.g., performed thereby and / or assigned for use in alarm monitoring) by the newly commissioned DCN. Further, the alarm setting service can optionally search for and provide the alarm setting file without reference to the addressable DCN identifier of the particular DCN on which a given function block is implemented.

[0018] The use of function block identifiers when deploying alarms according to the implementations disclosed in this specification is robust in distributed and / or heterogeneous process automation system settings and / or enables alarm deployment that reduces errors in such settings. For example, using function block identifiers when determining which alarm configuration file to provide in response to an alarm configuration request can mitigate potential problems that may arise, such as when an old DCN is replaced with a new DCN (having a new DCN identifier), or when the alarm engine monitoring function switches from a given DCN (having a given DCN identifier) to an alternative DCN (having an alternative DCN identifier).

[0019] In various implementation forms, in response to a DCN detecting the occurrence of one or more alarm setting conditions, the DCN can issue an alarm setting request. For example, the alarm setting request can be to determine that the DCN has been newly commissioned (e.g., newly added to a process automation system), to determine that the power has been turned on (e.g., for the first time or after a restart), to determine that the alarm engine has been assigned to monitor a functional block but that monitoring is not currently active (e.g., due to a lack of an alarm setting file for the functional block), to determine that a threshold period has been exceeded since the last alarm setting request was issued, to receive an update request from an alarm setting service, and / or to detect the occurrence of other states. In response to a DCN that has performed such detection of specific conditions, the DCN can issue an alarm setting request. By causing the DCN to issue an alarm setting request in response to the detection of such specific conditions, the DCN can actively search for an alarm setting file in situations where it is likely to be needed. Additionally or alternatively, by preventing the DCN from issuing an alarm setting request when specific conditions are not detected, the resources of the process automation system can be conserved. For example, network resources used when transmitting an alarm setting request from the DCN to the alarm setting service, and / or network resources used by the alarm setting service in response to the alarm setting request, etc., can be conserved.

[0020] Accordingly, the implementations disclosed herein enable the effective deployment of an alarm configuration file to an appropriate process automation node when the process automation node comes online within a newly commissioned process automation system. Further, additionally or alternatively, the implementations enable robust adaptation to replacement and / or modification of process automation nodes and / or other system components in an active process automation system. For example, the implementation enables robust alarm adaptation when a first DCN that performs and / or monitors a first functional block is replaced by a second DCN (e.g., having different hardware specifications) that similarly performs and / or monitors the first functional block.

[0021] The above description is provided as an overview of some implementations of the present disclosure. Further description of those implementations and other implementations will be provided in more detail below.

[0022] Furthermore, some implementations include one or more processors of one or more devices, the one or more processors being operable to execute instructions stored in an associated memory, the instructions being configured to cause execution of any of the methods described above. The processor can include various hardware processors such as a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a graphics processing unit (GPU), a digital signal processor (DSP), and / or other processors. Some implementations additionally or alternatively include one or more temporary or non-temporary computer-readable storage media storing computer instructions executable by one or more processors to perform any of the methods disclosed herein.

[0023] It should be understood that all combinations of the foregoing concepts and additional concepts described in more detail herein are contemplated as part of the subject matter disclosed herein. For example, all combinations of the subject matter recited in the claims set forth at the end of this disclosure are considered to be part of the subject matter disclosed herein.

Brief Description of the Drawings

[0024]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

[0025] The implementations disclosed herein relate to ensuring robust and / or accurate alarm monitoring based on functional blocks implemented by the DCN of a process automation system. At least a subset of such functional blocks are each utilized in implementing at least a part of a corresponding at least partially automated process. As used herein, an “at least partially automated process” includes any process implemented by multiple devices cooperating within a process automation system with little or no human intervention. One common example of an at least partially automated process is a process loop in which one or more actuators are automatically (without human intervention) operated based on the output of one or more sensors. Some at least partially automated processes can be sub-processes of the overall process automation system workflow, such as the aforementioned single process loop. Other at least partially automated processes can include all or a significant part of the overall process automation system workflow. In some cases, the degree to which a process is automated may exist depending on the gradient, scope, or scale of the automation. A process that is partially automated but still requires human intervention may be at or near one end of the scale. A process that requires little human intervention may approach the other end of the scale representing a fully autonomous process. In general, process automation can be used to automate processes in various domains, such as manufacturing, development, and / or purification of chemical substances (e.g., chemical processing), catalysts, machinery, and / or other domains.

[0026] Referring now to FIG. 1, an exemplary environment 100 in which various aspects of the present disclosure can be implemented is schematically shown. Environment 100 includes a process automation system 108 that can be implemented in various industrial environments, such as a chemical processing plant, an oil or natural gas refinery, a catalyst factory, a manufacturing facility, or a portion of other industrial environments. Process automation system 108 is shown in FIG. 1 as including an alarm setting service 120, an alarm database 125, a non-local alarm setting graphical user interface (GUI) 130, an alarm viewer 140, a process automation network 106, and distributed control nodes (DCNs) 110A - 110N. Process automation system 108 can include various additional components. However, for simplicity, they are not shown in FIG. 1.

[0027] The process automation network 106 can be implemented using various wired and / or wireless communication technologies, including but not limited to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 standard (Ethernet), IEEE 802.11 (Wi-Fi), 3GPP (registered trademark) Long-Term Evolution (LTE) or 3G, 4G, 5G, and other cellular networks specified as such and beyond, as well as / or other types of communication networks of various topologies (e.g., mesh). The automation of processes is often adopted in scenarios where the cost of failure tends to be high both in terms of human safety and the economic costs of stakeholders. Thus, in various implementation forms, the process automation network 106 can be configured with redundancy and / or backup to provide high availability (HA) and / or high quality of service (QoS). Further, nodes that exchange data via the process automation network 106 can implement time-sensitive networking (TSN) to facilitate time synchronization and / or real-time control streams. Various nodes / devices such as the alarm setting service 120, the alarm viewer 140, and DCNs 110A - N are operably coupled to the process automation network 106.

[0028] DCNs 110A, 110B, 110C, and 110N are shown in FIG. 1. However, it should be noted that additional (e.g., hundreds or even thousands of) DCNs can be provided in the process automation system 108, as indicated by the ellipsis between DCN 110C and DCN 110N. Some DCNs within the process automation system 108 can have input / output (I / O) for coupling to sensors, HMIs, actuators, and / or other components. Other DCNs within the process automation system 108 can optionally omit the I / O.

[0029] DCN110A is coupled to a float transmitter (FT) component 111A via a first I / O and to an actuator (e.g., a valve) 113A via a second I / O. Actuator 113A, and other actuators described herein, can be electrical, hydraulic, mechanical, and / or pneumatic components that are controllable to affect some aspects of a process automation workflow performed in process automation facility 108. FT component 111A includes a sensor that provides sensor data indicative of the flow rate of a corresponding fluid flow and also includes an actuator adjustable to control the corresponding fluid flow. The sensors described herein can take various forms including, but not limited to, pressure sensors, temperature sensors, flow rate sensors, various types of proximity sensors, optical sensors (e.g., photodiodes), pressure wave sensors (e.g., microphones), humidity sensors (e.g., hygrometers), radiation dosimeters, laser absorption spectrometers (e.g., multipass optical cells), and / or other forms.

[0030] DCN110A includes a processor 112A that can utilize a memory (and corresponding instructions stored therein) associated with implementing the corresponding functions of DCN110A. Those functions include implementing a functional block 114A of DCN110A that can be stored in some of the associated memory. Those functions also include implementing an alarm engine 116A.

[0031] Each of the functional blocks 114A of the DCN110A can define one or more aspects of sensor monitoring and / or actuator control executed by the DCN110A. In some implementations, each of the functional blocks 114A is a corresponding software model that includes input / output variables, through variables, internal variables, and / or an internal operation description of the function executed by the functional block. As a non-limiting example, one of the functional blocks 114A of the DCN110A can control the actuator of the FT component 111A based on sensor data from the sensor of the FT component 111A. As another non-limiting example, another functional block 114A of the DCN110A can control the actuator 113A in response to outputs from other functional blocks such as other functional blocks implemented in the DCN110A and / or other DCN110B-N.

[0032] The alarm engine 116A can optionally be implemented using an open standard protocol. For example, the alarm engine 116A can be implemented by an open platform communication (OPC) unified architecture (OPC-UA) server executed by its processor 112A on the DCN110A. The alarm engine 116A can monitor the occurrence of an alarm state indicated by an alarm setting file and utilize the alarm setting file described herein when executing corresponding actions when an alarm state is detected. The corresponding actions can optionally also be indicated by the alarm setting file. The conditions defined by the alarm setting file can include, or be limited to, conditions that reference process variables of functional blocks such as input variables, output variables, through variables, and / or internal variables of functional blocks.

[0033] Actions executed in response to an alarm state detected by the alarm engine 116A can include, for example, sending corresponding data to the alarm viewer 140 to cause rendering of corresponding audible and / or visual alarm messages at one or more output interfaces. The sending of the corresponding data can be performed via a connection-type communication session established between the alarm engine 116A and the alarm viewer 140. Additionally or alternatively, actions executed in response to the detected alarm state can include causing a repair to be performed. For example, stopping and / or changing the functional block(s) that caused the alarm state and / or related functional blocks.

[0034] DCN110B is coupled to a float transmitter (FT) component 111B via a first I / O and to a sensor 115B via a second I / O. DCN110B includes a processor 112B that can utilize a memory (and corresponding instructions stored therein) associated with implementing the corresponding functions of DCN110B. Those functions include implementing functional blocks 114B of DCN110B that can be stored in some of the associated memory. In particular, DCN110B does not include a corresponding alarm engine, and thus the functions implemented by processor 112B do not include implementation of an alarm engine. Rather, alarm monitoring related to functional blocks 114B of DCN110A is performed by DCN110C (described below).

[0035] Each of the functional blocks 114B of DCN110B can define one or more aspects of sensor monitoring and / or actuator control executed by DCN110B. In some implementations, each of the functional blocks 114B is a software model that includes input / output variables, through variables, internal variables, and / or a description of the internal operation of the functions executed by the functional block. As a non-limiting example, one of the functional blocks 114B of DCN110B can control the actuators of the FT component 111B based on sensor data from the sensors of the FT component 111B, sensor data from the sensor 115B, and / or sensor data from other sensors (e.g., the sensors of FT111A).

[0036] DCN110C is not connected to external components via I / O and can optionally omit I / O. Further, DCN110C does not include the functional blocks it performs. Thus, DCN110C does not implement functional blocks that "control" any automation process of the process automation system 108 directly or indirectly. However, the processor 112C of DCN110C implements an alarm engine 116C that monitors the functional blocks of other DCNs in the process automation system. In some implementations, DCN110C can be dedicated to alarm monitoring only.

[0037] The alarm engine 116C can optionally be implemented using an open standard protocol such as an OPC-UA server executed by its processor 112C on the DCN 110C. The alarm engine 116C monitors the occurrence of alarm states indicated by an alarm configuration file and can utilize the alarm configuration file described herein when executing corresponding actions when an alarm state is detected. The conditions defined by the alarm configuration file can include, but are not limited to, conditions that reference process variables of functional blocks. The functional blocks monitored by the alarm engine 116C include functional blocks not executed by the DCN 110C (since the DCN 110C does not execute any functional blocks). For example, the alarm engine 116C can monitor the functional block 114B of the DCN 110B and / or functional blocks of other DCNs. For example, the monitoring during the execution of the functional block 114B can be performed via communication from the DCN 110B that reflects the process variables of the executing functional block 114B. Such communication can optionally be performed via a connection-type communication session between the DCN 110B and the DCN 110C, for example, via the process automation network 106.

[0038] Actions executed in response to an alarm state detected by the alarm engine 116C can include, for example, causing a repair to be executed and / or transmitting corresponding data to the alarm viewer 140 via a connection-type communication session to cause the rendering of corresponding audible and / or visual alarm messages at one or more output interfaces.

[0039] DCN110N is coupled to sensor 115N via a first I / O. DCN110N includes a processor 112N that can utilize a memory (and corresponding instructions stored therein) associated with implementing the corresponding functions of DCN110N. Those functions include implementing a functional block 114A of DCN110N that can be stored in some of the associated memory. Those functions also include implementing an alarm engine 116N. As described herein, DCN110N can obtain an alarm setting file that defines an alarm monitored by alarm engine 116N from alarm setting service 120 via process automation network 106.

[0040] Actions executed in response to an alarm condition detected by alarm engine 116N can include, for example, causing a repair to be executed and / or sending corresponding data to alarm viewer 140 via a connection-type communication session to cause rendering of corresponding audible and / or visual alarm messages at one or more output interfaces.

[0041] Alarm setting service 120 is shown as including a settings module 122, a request and / or update module 124, and a push module 126. In some implementations, alarm setting service 120 is implemented within a process automation facility, for example, within a single building, or a single campus of a building, or across an entire other industrial infrastructure. In such implementations, alarm setting service 120 can be implemented on one or more local computing systems such as one or more server computers. However, in some implementations, some or all aspects of alarm setting service 120 can be implemented in a computing system remote from the process automation facility. In some of those implementations, alarm setting service 120 can communicate with process automation network 106 via a wide area network.

[0042] The setting module 122 can receive alarm setting files and their assignments to function block identifiers, and store those alarm setting files and associated function block identifiers in the alarm database 125. For example, a first alarm setting file can be assigned to a first function block identifier "FT101.PV", a second alarm setting file can be assigned to a second function block identifier "FT202.SP", and so on. Further, the setting module 122 can store in the alarm database 125 the first alarm setting file and the assignment (e.g., a pointer or other association) of the first alarm setting file to the "FT101.PV" function block identifier, and the second alarm setting file and the assignment (e.g., a pointer or other association) of the first alarm setting file to the "FT202.SP" function block identifier, and so on.

[0043] The alarm setting files and their associations can be generated based on user interface inputs from engineers and / or other personnel implementing and / or maintaining the process automation system 108.

[0044] In some implementations, some or all of the alarm configuration files and their associations stored by the configuration module 122 are received from the request and / or update module 124. As an example, when the request and / or update module 124 transmits a default alarm configuration file in response to an alarm configuration request that includes a functional block identifier, the request and / or update module 124 can provide an indication of the functional block identifier and the default alarm configuration file to the configuration module 122. In response, the configuration module 122 can store in the alarm database 125 the functional block identifier, the default alarm configuration file, and the association between the functional block identifier and the default alarm configuration file. As another example, when the request and / or update module 124 receives an alarm configuration update that includes an updated default alarm configuration file and a corresponding functional block identifier, the request and / or update module 124 can provide an indication of the functional block identifier and the updated default alarm configuration file to the configuration module 122. In response, the configuration module 122 can store in the alarm database 125 the functional block identifier, the updated default alarm configuration file, and the association between the functional block identifier and the default alarm configuration file.

[0045] In some implementations, some of the alarm configuration files and their associations are received via the bulk configuration file 135. The bulk configuration file 135 can be, for example, a.csv, or other structured format, or an unstructured format, and can be created using one or more programs.

[0046] In some implementations, some of the alarm configuration files and their associations can be received via the non-local alarm configuration graphical user interface (GUI) 130. The alarm configuration GUI 130 can also be implemented via the configuration module 122, or can be implemented via a separate component that at least selectively communicates with the configuration module 122. The alarm configuration GUI 130 can include graphical interface elements for specifying function block identifiers and for specifying alarm configuration file parameters for the function block identifiers. For example, the alarm configuration GUI 130 can include a field for specifying a function block identifier (e.g., via a drop-down menu, via free-form input, via auto-complete based on a searched or entered character), and can also include fields for specifying function block variables and conditions for those variables. For example, the alarm configuration GUI 130 can enable the specification of a function block identifier, and upon the specification of a function block identifier, can present the function block variables of the corresponding function block. Further, each of the function block variables can be selectable, and when selected, conditions corresponding to the function block variables can be defined through further interaction with the alarm configuration GUI. The selected function block variables and conditions can be used to generate the corresponding alarm configuration file and the corresponding alarm configuration file associated with the function block identifier. The update of the alarm configuration file can be performed via a further bulk configuration file and / or via further interaction with the alarm configuration GUI 130. For example, the alarm configuration GUI 130 can enable the viewing and modification (or deletion) of existing alarm configuration files within the alarm database 125 (optionally while maintaining the association with the function block identifier and optionally with the DCN identifier).

[0047] As described herein, note that an interaction with the alarm settings GUI 130 can be used to define and / or update an alarm settings file and to define an association between the alarm settings file and a functional block identifier. Further, the alarm settings file and the association can be stored in the alarm database 125 and provided for implementation on the corresponding DCN in response to a corresponding alarm settings request from the DCN or in response to a push to the DCN by the push module 126. However, in various implementations, unlike the HMIs described herein, the alarm settings GUI 130 may not be directly coupled communicably to any DCN and / or may not directly interact with any DCN (e.g., its alarm engine) when defining and / or updating the alarm settings file.

[0048] The request and / or update module 124 receives and processes alarm settings requests and / or alarm settings updates from a DCN, such as one or more of DCNs 110A - N, received via the process automation network 106.

[0049] Alarm setting requests received by the request and / or update module 124 can include the function block identifier of a function block and, optionally, the DCN identifier of the DCN that transmitted the alarm setting request. In response to receiving an alarm setting request, the request and / or update module 124 can access the alarm database 125 and determine whether there is a unique function block identifier within the alarm database 125 that matches the identifier of the alarm setting request and is stored in association with an alarm setting file. If determined to be the case, the request and / or update module 124 can identify the alarm setting file stored in association with the matching function block identifier. Further, the request and / or update module 124 can transmit the identified unique alarm setting file via the process automation network in response to the alarm setting request and the DCN that issued the alarm setting request. If the request and / or update module 124 determines that there is no unique function block identifier within the alarm database 125 that matches the identifier of the alarm setting request and is stored in association with an alarm setting file, a default alarm setting file can be determined based on the function block identifier. For example, the default alarm setting file can be stored in the alarm database 125 and / or generated based on data from the alarm database 125. Further, the request and / or update module 124 can transmit the default alarm setting file via the process automation network in response to the alarm setting request and the DCN that issued the alarm setting request.

[0050] In some implementations, the request and / or update module 124 may also cause the configuration module 122 to update the alarm database 125 to store an association, optionally included in the alarm configuration request, between the DCN identifier and the identified functional block identifier and / or the identified alarm configuration file. In doing so, the configuration module 122 may optionally delete the stored associations of heterogeneous DCN identifiers with respect to the identified functional block identifier and / or the identified alarm configuration file.

[0051] An alarm configuration update received by the request and / or update module 124 can include a functional block identifier and a corresponding alarm configuration file based on a previously provided default alarm configuration file. For example, the alarm configuration file received in the alarm configuration update may be an updated default alarm configuration file based on the default alarm configuration previously provided to the DCN, but it includes new values based on modifications made through the interaction between the HMI and the DCN. In response to receiving the alarm configuration update, the request and / or update module 124 provides relevant data to the configuration module 122 to cause the configuration module 122 to store in the alarm database 125 the association between the functional block identifier of the alarm configuration update and the alarm configuration file, and the functional block identifier to the alarm configuration file. In some implementations, the request and / or update module 124 may also cause the configuration module 122 to store an association, optionally included in the alarm configuration update, between the DCN identifier and the received functional block identifier and / or the received alarm configuration file.

[0052] The push module 126 is optional and, if provided, can be used such that an updated alarm settings file is provided to the corresponding DCN that was using the pre-update version of that alarm settings file. For example, in response to an update of the alarm settings file via the alarm settings GUI 130, the settings module 122 can associate the updated alarm settings file with its functional block identifier in the alarm database 125 while maintaining the association of the functional block identifier with the DCN identifier and / or while creating an association of the updated alarm settings file with the DCN identifier. As described with respect to the request and / or update module 124, the request and / or update module 124 can optionally cause the settings module 122 to store in the alarm database 125 the association of the DCN identifier with the functional block identifier and / or the alarm settings file in response to an alarm settings request or alarm settings update from the corresponding DCN that includes the functional block identifier. The push module 126 can identify the updated alarm settings file in response to a notification from the settings module 122 or in response to recognition of an update in the alarm database 125. In response to the identification of the updated alarm settings file, the push module 126 can cause the updated alarm settings file to be provided to the DCN corresponding to the DCN identifier and / or the associated functional block identifier associated with the updated alarm settings file.

[0053] In some implementations, when providing an updated alarm setting file to a DCN corresponding to a DCN identifier, the push module 126 can transmit the updated alarm setting file to the DCN identifier independent of an alarm setting request from the DCN. For example, the DCN identifier can be an IP address, and the push module 126 can transmit the updated alarm setting file to that IP address. In some implementations, when providing an updated alarm setting file to a DCN corresponding to a DCN identifier, the push module 126 can transmit an update request to the DCN identifier that can be determined to be an alarm setting condition when received by the DCN. Thereafter, the DCN can transmit an alarm setting request if it is considered appropriate by the DCN. The alarm setting request may be processed by the request and / or update module 124, and the updated alarm setting file is transmitted to the DCN by the request and / or update module 124 in response to the alarm setting request.

[0054] In some implementations, the alarm viewer 140 is implemented within the process automation equipment. In such implementations, the alarm viewer 140 can be implemented on one or more local computing systems such as on one or more server computers. However, in some implementations, some or all aspects of the alarm viewer 140 can be implemented in a computing system remote from the process automation equipment. In some of those implementations, the viewer 140 can communicate with the process automation network 106 via a wide area network. The alarm viewer 140 can communicate with the alarm engines of the DCNs 110A - N via a connection-type communication session.

[0055] The alarm viewer 140 can cause the rendering of at least any active alarms via one or more output devices in response to and in accordance with alarm messages received via respective connection type communication sessions through an alarm engine. For example, the alarm viewer 140 can display at least active alarms via a fixed display screen within a process automation facility. The fixed display screen can be communicatively coupled to a computing system implementing the alarm viewer. Also, for example, the alarm viewer 140 can transmit at least some active alarms (e.g., alarms designated as "high severity" in a corresponding alarm settings file) to an individual's mobile phone via an alarm app installed on the mobile phone, such as a text message alert or a push notification. Such transmission can be performed via the process automation network 106 and / or via one or more WANs connected to the process automation network. The rendering of active alarms by the alarm viewer 140 can optionally include an auditory and / or visual rendering of descriptors or other messages corresponding to the conditions that caused the alarms, such as descriptors defined in an alarm settings file for the alarms.

[0056] An active alarm can send a signal to the alarm viewer 140 based on a transmission from the DCN where the alarm engine determined the occurrence of the active alarm. The transmission can include a message regarding the alarm, such as a descriptor of the alarm determined using an alarm settings file, an identification of the function block and / or process variable that caused the alarm, and / or a display of the alarm settings file. The alarm viewer 140 can utilize the information included in the transmission from the DCN and / or information derived from the alarm database 125 using the information included in the transmission when rendering the details of the alarm.

[0057] Figure 1 shows an exemplary environment 100 at a first point in time, such as during or immediately after initial commissioning of process automation system 108. In some implementations, during initial commissioning, one or more of DCNs 110A - N initially include locally stored function blocks (and corresponding function block identifiers) and / or locally stored alarm engines (and corresponding function block identifiers), but may not have an alarm configuration file stored. After connecting to process automation network 106, one or more of such DCNs 110A - N each transmit a corresponding alarm configuration request and, in response, can obtain a responding proprietary alarm configuration file and / or a responding default alarm configuration file from alarm configuration service 120.

[0058] For example, in Figure 1, DCN 110A transmits an alarm configuration request 117A, which includes a function block identifier of function block 114A monitored by alarm engine 116A, to request and / or update module 124. Request and / or update module 124 can access alarm database 125 and determine that no proprietary alarm configuration file is stored in relation to the function block identifier of request 117A. A proprietary alarm configuration file is a non - default alarm configuration file. A proprietary alarm configuration file can be stored in alarm database 125 in association with a function block identifier based on associations defined, for example, within bulk configuration file 135, associations defined via alarm configuration GUI 130, or associations defined by previous alarm configuration updates.

[0059] In response to a determination that no unique alarm setting file is associated with the function block identifier of request 117A, request and / or update module 124 can determine a default alarm setting file 119A corresponding to the function block type based on the function block type indicated by the function block identifier. Further, request and / or update module 124 can transmit the default alarm setting files 119A to DCN 110A for local storage by DCN 110A. As a specific example, the function block identifier of request 117A can end with ".PV" indicating that it is a process variable type. The default alarm setting file 119A of that type can include, for example, default alarm setting files for "error", "level", "rate of change", and "deviation".

[0060] Also, for example, in FIG. 1, DCN110C transmits an alarm setting request 117C including a function block identifier of a function block to be monitored by the alarm engine 116C, such as the function block 114B of DCN110B as described above, to the request and / or update module 124. The request and / or update module 124 accesses the alarm database 125 and can determine that a specific alarm setting file 119C is stored in association with the function block identifier of the request 117C. For example, the specific alarm setting file stored in association with the function block identifier may be defined via the bulk setting file 135. In response to the determination that the specific alarm setting file 119C is stored in association with the function block identifier of the request 117C, the request and / or update module 124 transmits the specific alarm setting file 119C to DCN110C for local storage by DCN110C and enables the alarm engine 116C to implement local alarm monitoring based on the specific alarm setting file 119C. Therefore, in response to the specific alarm setting file 119C stored in the alarm database 125 in association with the function block identifier of the request 117C, the specific alarm setting file is transmitted to DCN110C instead of the default alarm setting file.

[0061] Also, for example, in FIG. 1, DCN110N transmits an alarm setting request 117N including a function block identifier of the function block 114N to be monitored by the alarm engine 116N to the request and / or update module 124. The request and / or update module 124 accesses the alarm database 125 and can determine that no specific alarm setting file is stored in relation to the function block identifier of the request 117N.

[0062] In response to a determination that no specific alarm setting file is stored in relation to the function block identifier of claim 117N, the request and / or update module 124 can determine a default alarm setting file 119N corresponding to the function block type based on the function block type indicated by the function block identifier. Further, the request and / or update module 124 can transmit the default alarm setting files 119N to the DCN 110N for local storage by the DCN 110A. As a specific example, the function block identifier of claim 117A can end with ".AI" indicating an analog input type. The default alarm setting file 119N of that type can include, for example, the default alarm setting files for "error" and "discrete state".

[0063] Referring now to FIG. 2, an exemplary environment 100 is shown after the alarm setting requests 117A - C of FIG. 1 have been provided, with default alarm setting files 119A and 119N provided to the respective DCNs 110A and 110N. Further, the exemplary environment 100 is shown after the HMI 145A has been utilized to update the default alarm setting file 119A in the DCN 110A and the HMI 145B has been utilized to update the default alarm setting file 119N in the DCN 110N.

[0064] As an example, the default alarm setting file 119A transmitted to DCN110A can include a file that is a level alarm of the measured flow variable of function block 114A (based on the sensor of FT component 111A), but there may be a lack of any specified value for high-high, high, low, and / or low-low. When HMI145A is coupled to DCN110A (e.g., via a wired connection or a wireless connection), it provides a GUI that can be used to define the specified values for high-high, high, low, and / or low-low, thereby creating an updated default alarm setting file. As another example, the default alarm setting file 119A can include one that is a rate-of-change alarm of the measured flow variable, but there may be a lack of a specified value for the maximum rate of change of the measured flow variable. When HMI145A is coupled to DCN110A (e.g., via a wired connection or a wireless connection), it is used to define the value of the maximum rate of change, thereby creating an additional updated default alarm setting file.

[0065] In response to an update in DCN110A, as shown in FIG. 2, DCN110A transmits an alarm setting update 118A that includes the updated default alarm setting file and the corresponding function block identifier to the alarm setting service 120. In response to the receipt of the alarm setting update 118A, the alarm setting service 120 stores the updated default alarm setting file and the association between the file and the corresponding function block identifier in the alarm database 125.

[0066] In response to an update in DCN110N, as shown in FIG. 2, DCN110N transmits an alarm setting update 118N that includes the updated default alarm setting file and the corresponding function block identifier to the alarm setting service 120. In response to the receipt of the alarm setting update 118N, the alarm setting service 120 stores the updated default alarm setting file and the association between the file and the corresponding function block identifier in the alarm database 125.

[0067] Next, referring to FIG. 3, an exemplary environment 100 is shown after the time point of FIG. 2 and after the DCN 110A of FIGS. 1 and 2 has been replaced with an alternative DCN 110A1. The alternative DCN 110A1 can replace the DNC 110A, for example, due to a failure of the DCN 110A. In FIG. 3, the DCN 110A1 is coupled to the FT component 111A via a first I / O and to the actuator 113A via a second I / O. The DCN 110A1 includes a processor 112A1 that can utilize a memory (and corresponding instructions stored therein) associated with implementing the corresponding functions of the DCN 110A1. Those functions can be stored in a part of the associated memory and can be the same as the functional block 114A of the DCN 110A, including implementing a functional block 114A1 of the DCN 110A1. Those functions also include implementing an alarm engine 116A1. In response to commissioning or power-on, the DCN 110A1 can transmit an alarm setting request 117A1 that includes a functional block identifier of the functional blocks monitored by the functional block 114A1 and / or the alarm engine 116A1, which can be the same as that of the DCN 110A (FIG. 1).

[0068] The request and / or update module 124 can identify, in response to the alarm setting request 117A1, the updated alarm setting file included in the alarm setting update 118A (Figure 2) from the alarm database 125. These updated alarm setting files can be identified based on being stored in the alarm database 125 in association with the function block identifier of the alarm setting request 117A1, and can be regarded as the specific alarm setting file 119A1 based on being stored in association with those function block identifiers. Further, the request and / or update module 124 can transmit the specific alarm setting file 119A1 to the DCN 110A1 in order to cause the alarm engine 116A1 of the DCN 110A1 to implement the specific alarm setting file 119A1.

[0069] Furthermore, the request and / or update module 124 can optionally update the alarm database 125 to store the association of the DCN identifier of DCN110A1 with the proprietary alarm setting file 119A1 and / or the functional block identifier, and / or can provide the DCN identifier of DCN110A1 to the alarm viewer 140. Note that the DCN identifier of DCN110A1 can be unique with respect to the DCN identifier of the replaced DCN110A. By updating the alarm database 125 to reflect the DCN identifier of DCN110A1 and / or providing a push notification to the alarm viewer 140, the alarm viewer 140 can be enabled to establish a connection-type communication session with DCN110A1, and / or an effective push of the updated alarm setting file by the push module 126 can be enabled. Furthermore, the unique DCN identifier of DCN110A1 indicates the robustness of including the functional block identifier in the alarm setting request and its use by the request and / or update module 124 in response to the alarm setting request 117A1. For example, if some of the proprietary alarm setting files 119A1 that respond were instead stored associated only with the DCN identifier of DCN110A and the DCN identifier of DCN110A1 was included in the request instead of the functional block identifier, the request and / or update module 124 would not be able to identify such alarm setting files in response to the alarm setting request from DCN110A1.

[0070] FIG. 4 shows an exemplary environment of FIGS. 1 and 2 after the time point of FIG. 2 and after the DCN110A of FIGS. 1 and 2 has been modified to delete the alarm engine 116A, and the alarm monitoring function previously executed by the alarm engine 116A is now assigned for monitoring by the modified alarm engine 116C1 of the DCN110C. In response to the detection of an alarm setting condition, the DCN110C can transmit an alarm setting request 117C1 that includes the function block identifiers of at least the function blocks previously monitored by the alarm engine 116A.

[0071] The request and / or update module 124 can identify, in response to the alarm setting request 117C1, from the alarm database 125, the updated alarm setting file included in the alarm setting update 118A (FIG. 2). Those updated alarm setting files can be identified based on being stored in association with the function block identifiers of the alarm setting request 117C1, and are regarded as unique alarm setting files 119A1 based on being stored in the alarm database 125 in association with those function block identifiers. Further, the request and / or update module 124 can transmit the unique alarm setting file 119A1 to the DCN110C in order for the alarm engine 116C1 of the DCN110C to implement the unique alarm setting file 119A1. Further, the request and / or update module 124 can optionally update the alarm database 125 to store the association between the DCN identifier of the DCN110C and the unique alarm setting file 119A1 and / or the function block identifier.

[0072] FIG. 5 is a flowchart showing an exemplary method 500 for processing an alarm setting request from a DCN, including at least selectively responding to the alarm setting request by transmitting a default alarm setting file determined based on the function block type of the function blocks indicated by the alarm setting request to the DCN. For convenience, the operations of the flowchart are described with reference to the system that executes the operations. This system may include various components of various computer systems such as an alarm setting service 120 (e.g., a request and / or update module 124). Further, although the operations of method 500 are shown in a particular order, this is not meant to be limiting. One or more operations may be rearranged, omitted, or added.

[0073] In block 502, the system receives an alarm setting request including a function block identifier via the process automation network and from the DCN. For example, the alarm setting request can be transmitted by the DCN based on the DCN execution block 704 of method 700 of FIG. 7.

[0074] In block 504, the system determines whether there is a unique alarm setting file stored in the alarm database associated with the function block identifier (of the alarm setting request of block 502). For example, the system can search the alarm database using the function block identifier to determine whether the association between the function block identifier and the unique alarm setting file is stored. As described herein, the unique alarm setting file is a non-default alarm setting file such as an updated default alarm setting file (based on HMI input) or one defined via a bulk upload and / or a non-local alarm setting GUI.

[0075] If the determination at block 504 is "yes", the system proceeds to block 506 and transmits the unique alarm configuration file to the DCN. The system transmits the unique alarm configuration file in response to the request of block 502 and via the process automation network. The system can then optionally proceed to optional block 508, where the system stores in the alarm database the DCN identifier associated with the alarm configuration request, in association with the transmitted alarm configuration file and / or in association with the function block identifier. For example, the DCN identifier can be an addressable DCN identifier (e.g., an IP address) included in the header or body of the alarm configuration request.

[0076] If the determination at block 504 is "no", the system proceeds to block 510 and determines the function block type based on the function block identifier of the alarm configuration request of block 502. For example, the system can determine the function block type based on the characters of the function block identifier that are mapped to the function block type, such as the suffix characters following the "." in the function block identifier.

[0077] At block 512, the system determines the default alarm configuration file based on the function block type determined at block 510. In some implementations, block 510 includes sub-block 512A and / or sub-block 512B.

[0078] In sub-block 512A, when the system can access a functional block corresponding to a functional block identifier, the system optionally includes process variables from the functional block in the default alarm setting file. The system can access the functional block based on the functional block being included in the alarm setting request of block 502 or based on the functional block being stored in the alarm database associated with the functional block identifier. As an example of sub-block 512A, assume a default alarm setting file of the "deviation" alarm type and the functional block includes a process variable of "tank123temp". In sub-block 512A, the system can include "tank123temp" as a process variable in the default alarm setting file and be compared with the deviation value when determining whether a deviation state has occurred. This eliminates the need to specify the process variable in the future via the HMI coupled to the DCN.

[0079] In sub-block 512B, the system includes blanks and / or default values as the values of the parameters in the alarm setting file. As an example of sub-block 512A, assume a default alarm setting file for "rate of change", where the value of the amount of change and the value of the specified time are required to determine whether the condition of the rate of change is met. In some implementations, the system can include blanks or null values for both the value of the amount of change and the value of the specified time. In some implementations, the system can include default values for one or both of the value of the amount of change and the value of the specified time. For example, the system can identify the default value of the amount of change and the default value of the specified time based on the alarm type (deviation) and / or the function block type, and incorporate both into the alarm setting file. For example, the first default value of the amount of change can be defined for the deviation alarm type and the "analog input" function block type, and the second default value of the amount of change can be defined for the deviation alarm type and the "ratio" function block type. As another example of sub-block 512A, assume a default alarm setting file that includes an alarm severity parameter. In some implementations, the system can include blanks or null values for the severity parameter. In some implementations, the system can include default values of the severity parameter, such as default values of the alarm type and / or the function block type.

[0080] In block 514, the system transmits the default alarm configuration file determined in block 512 to the DCN. The system transmits the default alarm configuration file via the process automation network in response to the request of block 502. The system can then optionally proceed to optional block 508, where the system stores in the alarm database the DCN identifier associated with the alarm configuration request, in association with the transmitted alarm configuration file and / or in association with the function block identifier. For example, the DCN identifier can be an addressable DCN identifier (e.g., an IP address) included in the header or body of the alarm configuration request.

[0081] FIG. 6 is a flowchart showing an exemplary method 600 for processing an alarm configuration update from a DCN. For convenience, the operations of the flowchart are described with reference to the system that performs the operations. This system can include various components of various computer systems, such as an alarm configuration service 120 (e.g., a request and / or update module 124). Further, although the operations of method 600 are shown in a particular order, this is not meant to be limiting. One or more operations may be rearranged, omitted, or added.

[0082] In block 602, the system receives an alarm setting update including a functional block identifier and an alarm setting file via a process automation network and from the DCN. For example, the alarm setting update can be transmitted by the DCN based on the DCN execution block 722 of method 700 of FIG. 7. The alarm setting file of the alarm setting update can include an alarm setting file that is an updated version of the default alarm setting file previously transmitted to the DCN (e.g., in block 514 of method 500 of FIG. 5). For example, the included alarm setting file can be the same as the previously transmitted default alarm setting file, but can include various additional or alternative values defined through interaction with an HMI communicatively coupled to the DCN.

[0083] In block 604, the system stores the alarm setting file of the alarm setting update as a file specific to the alarm database. Also, the system stores each of the alarm setting files of the alarm setting update in the alarm database in association with the functional block identifier of the alarm setting update.

[0084] FIG. 7 is a flowchart of an exemplary method 700 that generates and transmits an alarm setting request, receives an alarm setting file as a response, and implements local alarm monitoring based on the received alarm setting file. For convenience, the operations of the flowchart are described with reference to the system that executes the operations. This system can include various components of various computer systems such as any of DCNs 110A - N. Further, although the operations of method 700 are shown in a particular order, this is not meant to be limiting. One or more operations may be reordered, omitted, or added.

[0085] In block 702, the system monitors for the occurrence of alarm setting conditions. If an alarm setting condition is detected in block 702, the system proceeds to block 704. In some implementations, in block 702, the system monitors for the occurrence of any one of a plurality of conditions, such as determining that it has been newly commissioned, determining that power has been turned on, determining that the alarm engine is assigned to a monitoring function block but the monitoring is not currently active, determining that the time since the last alarm setting request was issued exceeds a threshold period, and / or receiving an update request from an alarm setting service (e.g., from push module 126).

[0086] In block 704, the system generates an alarm setting request that includes function block identifiers of function blocks based on function blocks that are being locally performed and / or locally utilized in alarm monitoring. For example, in alarm monitoring, the system can include function block identifiers based on function block identifiers assigned for use by the alarm engine of the system. In some implementations, the alarm setting request includes multiple function block identifiers of multiple function blocks based on a plurality of function blocks that are each being locally performed and / or locally utilized in alarm monitoring. In some implementations, block 704 includes sub-block 704A, and the system also includes in the alarm setting request the DCN identifier of the DCN that generates and transmits the alarm setting request.

[0087] In block 706, the system transmits the alarm setting request generated in block 804 via the process automation network.

[0088] In block 708, the system receives an alarm setting file for a function block identifier via the process automation network and in response to a request. In block 708, the system can optionally receive multiple alarm setting files, for example if the alarm setting request includes multiple function block identifiers. In some implementations, the alarm setting file is received in block 708 in response to the execution of block 506 or block 510 of method 500 of FIG. 5.

[0089] In block 710, the system determines whether all of the received alarm setting files are duplicates. That is, whether all of the received alarm setting files are already stored locally and are being used locally by the system's alarm engine when performing alarm monitoring. If there are duplicates, the system returns to block 702 and monitors for the occurrence of another alarm setting condition. If there are no duplicates, the system proceeds to block 712.

[0090] In block 712, for each received alarm setting file, the system determines whether it is a default alarm setting file or a unique alarm setting file. If the system determines that the alarm setting file is a unique alarm setting file, the system proceeds to block 714 and implements local alarm monitoring based on the received alarm setting file and the function block. When implementing local alarm monitoring based on the alarm setting file and the function block, the system monitors the function block for meeting the conditions of the alarm setting file (e.g., during the execution of the function block), and in response to the detection of meeting the conditions, can execute corresponding actions for the satisfied conditions.

[0091] In block 712, if the system determines that the alarm setting file is the default alarm setting file, the system proceeds to block 716. In block 716, the system locally stores the default alarm setting file but does not immediately implement alarm monitoring based on the default alarm setting file. Instead, the system waits for an HMI interaction to update the default alarm setting file and optionally checks the updated default alarm setting file before implementing alarm monitoring based on the updated alarm setting file.

[0092] In block 717, the system waits for an HMI interaction to update the default alarm setting file and optionally checks the updated default alarm setting file. For example, the system waits for user input to specify one or more unspecified values of the default alarm setting file and / or change one or more default values of the default alarm setting file, provided via the HMI while the system is communicatively coupled to the system.

[0093] In block 717, when an HMI interaction occurs to update the default alarm setting file and optionally check the updated default alarm setting file, the system proceeds to block 720. In block 720, the system implements local alarm monitoring based on the updated alarm setting file and the functional blocks.

[0094] The system also proceeds to block 722 and transmits an alarm setting update including the updated alarm setting file and the functional blocks.

[0095] Block 810 can optionally include sub-block 810A. In sub-block 810A, when implementing local alarm monitoring based on a received alarm setting file and functional blocks, the system monitors the functional blocks for meeting the conditions of the alarm setting file (e.g., during the execution of the functional block), and in response to detecting that the conditions are met, executes corresponding actions for the satisfied conditions, such as transmitting corresponding data to an alarm viewer.

[0096] FIG. 8 is a block diagram of an exemplary computing device 810 that can optionally be utilized to execute one or more aspects of the techniques described herein. For example, computing device 810 is an example of a computing device that can implement all or part of an alarm setting service and / or, optionally, all or part of several DCNs. Computing device 810 typically includes at least one processor 814 that communicates with a number of peripheral devices via bus subsystem 812. These peripheral devices can include, for example, a storage subsystem 824 that includes a memory subsystem 825 and a file storage subsystem 826, a user interface output device 820, a user interface input device 822, and a network interface subsystem 816. The input and output devices enable a user to interact with computing device 810. Network interface subsystem 816 provides an interface to an external network and is coupled to a corresponding interface device within other computing devices.

[0097] The user interface input device 822 can include a pointing device such as a keyboard, mouse, trackball, touchpad, or graphics tablet, a scanner, a touch screen incorporated in a display, a voice recognition system, a microphone, and / or other types of input devices such as audio input devices. In general, the use of the term "input device" is intended to include any possible type of device and method for entering information onto the computing device 810 or onto a communication network.

[0098] The user interface output device 820 can include a display subsystem, a printer, a fax machine, or a non-visual display such as an audio output device. The display subsystem can include a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a projection device, or some other mechanism for creating a visible image. The display subsystem can also provide a non-visual display via, for example, an audio output device. In general, the use of the term "output device" is intended to include any possible type of device and method for outputting information from the computing device 810 to the user or to another machine or computing device.

[0099] The storage subsystem 824 stores the programming and data structures that provide some or all of the functionality of the modules described herein. For example, the storage subsystem 824 can include logic for implementing the selected aspects of the methods of FIGS. 5-7 and, similarly, for implementing the various components in FIGS. 1-4.

[0100] These software modules are generally performed by the processor 814 alone or in combination with other processors. The memory 825 used in the storage subsystem 824 can include a number of memories, including a main random access memory (RAM) 830 for storing instructions and data during program execution and a read-only memory (ROM) 832 in which fixed instructions are stored. The file storage subsystem 826 can provide permanent storage for program and data files and can include a hard disk drive, removable media associated with a floppy disk drive, a CD-ROM drive, an optical drive, or a removable media cartridge. The modules implementing the functions of a particular implementation can be stored by the file storage subsystem 826 within the storage subsystem 824 or on other machines accessible by the processor 814.

[0101] The bus subsystem 812 provides a mechanism that enables the various components and subsystems of the computing device 810 to communicate with each other as intended. Although the bus subsystem 812 is shown schematically as a single bus, multiple buses may be used in alternative implementations of the bus subsystem.

[0102] The computing device 810 can be of various types, including a workstation, a server, a computing cluster, a blade server, a server farm, or any other data processing system or computing device. Due to the ever-changing nature of computers and networks, the description of the computing device 810 shown in FIG. 8 is intended only as a specific example for the purpose of illustrating some implementations. Many other configurations of the computing device 810 are possible that have more or fewer components than the computing device shown in FIG. 8.

[0103] Although several implementations have been described and illustrated in this specification, various other means and / or structures may be utilized to perform the functions described in this specification and / or to obtain the results and / or one or more advantages, and each such variation and / or modification is considered to be within the scope of the implementations described herein. More generally, all parameters, dimensions, materials, and configurations described herein are intended to be exemplary, and the actual parameters, dimensions, materials, and / or configurations will depend on the particular application or the application for which the teachings are used. One of ordinary skill in the art will recognize, or will be able to ascertain using no more than routine experimentation, many equivalents to the specific implementations described herein. Accordingly, the foregoing implementations are presented by way of example only, and it is to be understood that within the scope of the appended claims and equivalents thereto, implementations may be practiced otherwise than as specifically described and claimed. Implementations of the present disclosure are directed to the individual features, systems, articles, materials, kits, and / or methods described herein. Furthermore, any combination of two or more of such features, systems, articles, materials, kits, and / or methods is included within the scope of the present disclosure if such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent.

[0104] In some implementations, a method implemented by a hardware processor is provided, including determining whether a distributed control node (DCN) of a process automation system is performing a particular type of functional block. The method further includes determining a default alarm setting file based on the particular type. The method further includes transmitting, in response to determining that the DCN is performing a particular type of functional block, the default alarm setting file determined based on the particular type to the DCN via a network of the process automation system. The default alarm setting file is locally editable via the DCN and, when edited, is used by the DCN in implementing alarm monitoring based on the functional block.

[0105] These and other implementations of the technology disclosed in this specification can include one or more of the following features.

[0106] In some implementations, the method includes, after transmitting a specific type of default alarm setting file to the DCN, receiving, via the network and from the DCN, an alarm setting update that includes a functional block identifier of a functional block performed by the DCN and an updated alarm setting file that is an edited version of the previously transmitted default alarm setting file; and storing the updated alarm setting file and the association between the updated alarm setting file and the functional block identifier in an alarm database. In some versions of these implementations, the method further includes, after storing the updated alarm setting file and the association between the updated alarm setting file and the functional block identifier in the alarm database, receiving, via the network, an alarm setting request transmitted by an additional DCN of the process automation system and including the functional block identifier. In those versions, the method further includes, in response to receiving the alarm setting request, obtaining, from the alarm database, an updated alarm setting file based on the alarm setting file stored in association with the functional block identifier and the functional block identifier included in the received alarm setting request; and transmitting the updated alarm setting file to the additional DCN via the network of the process automation system. By the step of transmitting the updated alarm setting file, the additional DCN implements alarm monitoring compliant with the updated alarm setting file. In some of those versions, the additional DCN is a newly commissioned DCN that replaces the DCN in the process automation system. In other versions of those, the additional DCN is a previously commissioned DCN that performs a functional block at the time of the alarm setting request, and the DCN ceases to perform the functional block at the time of the alarm setting request.

[0107] In some implementations, the step of determining that the DCN is performing a particular type of functional block includes receiving, via the network, an alarm setting request transmitted by the DCN and including a functional block identifier of the functional block, and determining, based on the functional block identifier included in the alarm setting request, that the DCN is performing a particular type of functional block. In some versions of these implementations, the step of determining, based on the functional block identifier included in the alarm setting request, that the DCN is performing a particular type of functional block includes determining the particular type based on the functional block identifier including one or more characters mapped to the particular type. In some additional or alternative versions of those implementations, the method further includes determining whether there is a particular alarm setting file stored in the alarm database associated with the functional block identifier in response to receiving the alarm setting request. In those additional or alternative versions, the step of transmitting a default alarm setting file to the DCN further responds to a determination that there is no particular alarm setting file stored associated with the functional block identifier.

[0108] In some implementations, the default alarm setting file defines one or more conditions to be monitored when implementing alarm monitoring and, for each one or more conditions, includes or does not include a corresponding default value. In some of those implementations, the method further includes identifying a functional block performed by the DCN, and the step of determining the default alarm setting file includes modifying a particular type of general alarm setting file to include one or more process variables of the functional block performed by the DCN.

[0109] In some implementations, a method implemented by a hardware processor of a distributed control node (DCN) of a process automation system is provided, the method including receiving user interface input via a human-machine interface (HMI) that interfaces directly with the DCN. The method further includes determining, based on the user interface input, one or more updates to a default alarm setting file stored locally at the DCN and associated with a functional block to be performed by the DCN. The method further includes generating an updated alarm setting file based on the default alarm setting file and the one or more determined updates, implementing alarm monitoring based on the updated alarm setting file and the functional block, and transmitting, via a network of the process automation system, an alarm setting update including the updated alarm setting file and a functional block identifier of the functional block. By the step of transmitting the request, the updated alarm setting file is stored in an alarm database in association with the functional block identifier.

[0110] These and other implementations of the technology disclosed herein can include one or more of the following features.

[0111] In some implementations, the step of determining one or more updates to the default alarm setting file based on the input of the user interface is a step of determining specific values of one or more updates based on the user interface input, the specific values being related to conditions of the default alarm setting file. In some versions of these implementations, the default alarm setting file lacks a value for a condition, and the updated alarm setting file includes a specific value for the condition. In other versions of those implementations, the default alarm setting file includes a default value for the condition, and the updated alarm setting file includes a specific value for the condition.

[0112] In some implementation forms, before receiving user interface input via the HMI, the method further includes transmitting, via a network, an alarm setting request including a function block identifier, and in response to the transmission of the alarm setting request and via the network, receiving a default alarm setting file. In some versions of these implementation forms, the method further includes detecting the occurrence of one or more alarm setting conditions, and in those versions, the step of transmitting the alarm setting request responds to the detection of the occurrence of one or more alarm setting conditions. In some of those versions, the step of detecting the occurrence of one or more alarm setting conditions includes detecting the power-on of the DCN, detecting that the DCN has been newly commissioned in the process automation system, and / or detecting that alarm monitoring is not currently active by the DCN of the function block.

[0113] In some implementation forms, the function block identifier is unique to the function block and is not assigned to any other function block of the process automation system.

[0114] In some implementations, a process automation system includes an alarm setting server that includes one or more network interfaces communicatively coupled to the network of the process automation system, alarm setting files specific to a plurality of functional blocks, an alarm database including a corresponding association for each of the alarm setting files specific to the functional blocks to a corresponding functional block identifier, and one or more alarm setting processors. The alarm setting processor is configured to receive, via the network, an alarm setting request transmitted by a node of the process automation system and including a functional block identifier of a functional block, the functional block identifier being based on a functional block assigned for use in alarm monitoring by the node, determine whether a corresponding association in the alarm database includes an association to the functional block identifier, transmit, in response to determining that the corresponding association in the alarm database includes an association to the functional block identifier, an alarm setting file specific to the functional block having relevance among the alarm setting files specific to the functional blocks to the node in response to the alarm setting request, determine a default alarm setting file based on a specific type of the functional block identified by the functional block identifier in response to determining that the corresponding association in the alarm database does not include an association to the functional block identifier, and transmit the default alarm setting file determined based on the specific type to the node via the network, by executing stored instructions. The default alarm setting file is locally editable via the node and, when edited, is used by the node when implementing alarm monitoring based on the functional block.

Description of the Signs

[0115] 100 Environment 106 Process Automation Network 108 Process Automation System 108 Process Automation Equipment 110A to 110N Distributed Control Nodes (DCNs) 110A1 Alternative DCN 110B DCN 110C DCN 110N DCN 111A Float Transmitter (FT) Component 111B Float Transmitter (FT) Component 112A Processor 112A1 Processor 112B Processor 112C Processor 112N Processor 113A Actuator 114A Functional Block 114A1 Functional Block 114B Functional Block 114N Functional Block 115B Sensor 115N Sensor 116A Alarm Engine 116A1 Alarm Engine 116C Alarm Engine 116C1 Alarm Engine 116N Alarm Engine 117A to C Alarm Setting Requests 117A Alarm Setting Request 117A1 Alarm Setting Request 117C Request 117C1 Alarm Setting Request 117N Alarm Setting Request 118A Alarm Setting Update 118N Alarm Setting Update 119A Default Alarm Setting File 119A1 Specific Alarm Setting File 119C Alarm Setting File 119N Default Alarm Setting File 120 Alarm Setting Service 122 Setting Module 124 Requirements and / or Update Module 125 Alarm Database 126 Push Module 130 Non-Local Alarm Settings Graphical User Interface (GUI) 135 Bulk Settings File 140 Alarm Viewer 145A HMI 145B HMI 500 Method 600 Method 700 Method 704 DCN Execution Block 810 Computing Device 812 Bus Subsystem 814 Processor 816 Network Interface Subsystem 820 User Interface Output Device 822 User Interface Input Device 824 Storage Subsystem 825 Memory Subsystem 825 Memory 826 File Storage Subsystem 830 Main Random Access Memory (RAM) 832 Read-Only Memory (ROM)

Claims

1. A method implemented by one or more processors, comprising: determining whether a distributed control node (DCN) of a process automation system is performing a specific type of functional block; determining a default alarm setting file based on the specific type; in response to a determination that the DCN is performing the specific type of functional block, transmitting, via a network of the process automation system, the default alarm setting file determined based on the specific type to the DCN; and the default alarm setting file is locally editable via the DCN and, when edited, is used by the DCN when implementing alarm monitoring based on the functional block.

2. After transmitting the default alarm setting file of the specific type to the DCN, receiving, via the network and from the DCN, an alarm setting update including: a functional block identifier of the functional block performed by the DCN; and an updated alarm setting file that is an edited version of the previously transmitted default alarm setting file; storing, in an alarm database, the updated alarm setting file and an association between the updated alarm setting file and the functional block identifier; and The method according to claim 1, further comprising:

3. After storing, in the alarm database, the updated alarm setting file and the association between the updated alarm setting file and the functional block identifier, receiving, via the network, an alarm setting request transmitted by an additional DCN of the process automation system, the alarm setting request including: the functional block identifier; in response to receiving the alarm setting request, obtaining, from the alarm database, the updated alarm setting file based on the alarm setting file stored in association with the functional block identifier and the functional block identifier included in the received alarm setting request. Transmitting the updated alarm setting file to the additional DCN via the network of the process automation system, wherein by the step of transmitting the updated alarm setting file, the additional DCN implements alarm monitoring in accordance with the updated alarm setting file; The method according to claim 2, further comprising.

4. The method according to claim 3, wherein the additional DCN is a newly commissioned DCN that replaces the DCN in the process automation system.

5. The method according to claim 3, wherein the additional DCN is a previously commissioned DCN that performs the function block at the time of the alarm setting request, and the DCN stops performing the function block at the time of the alarm setting request.

6. The step of determining that the DCN performs the specific type of function block comprises receiving, via the network, an alarm setting request transmitted by the DCN and including a function block identifier of the function block; and determining that the DCN performs the specific type of function block based on the function block identifier included in the alarm setting request. The method according to claim 1, comprising.

7. The step of determining that the DCN performs the specific type of function block based on the function block identifier included in the alarm setting request comprises the method according to claim 6, further comprising determining the specific type based on that the function block identifier includes one or more characters mapped to the specific type.

8. In response to receiving the alarm setting request, further comprising determining whether there is a specific alarm setting file stored in the alarm database in association with the function block identifier; and the step of transmitting the default alarm setting file to the DCN further responds to a determination that there is no specific alarm setting file stored in association with the function block identifier.

9. The method according to claim 1, wherein the default alarm setting file defines one or more conditions to be monitored when implementing alarm monitoring, and for each of the one or more conditions, includes a corresponding default value or does not include a value.

10. Further comprising the step of identifying the functional block performed by the DCN, The method according to claim 9, wherein the step of determining the default alarm setting file comprises the step of modifying the specific type of general alarm setting file to include one or more process variables of the functional block performed by the DCN.

11. A method implemented by one or more processors of a distributed control node (DCN) of a process automation system, comprising: Receiving user interface input via a human machine interface (HMI) that directly interfaces with the DCN; Based on the user interface input, determining one or more updates to a default alarm setting file stored locally in the DCN and associated with a functional block performed by the DCN; Generating an updated alarm setting file based on the default alarm setting file and the one or more determined updates; Implementing alarm monitoring based on the updated alarm setting file and the functional block; Transmitting an alarm setting update including the updated alarm setting file and a functional block identifier of the functional block via a network of the process automation system, wherein the step of transmitting the request stores the updated alarm setting file in an alarm database in association with the functional block identifier. A method comprising:

12. Based on the input of the user interface, the step of determining the one or more updates to the default alarm setting file The method according to claim 11, further comprising the step of determining a specific value of the one or more updates based on the user interface input, wherein the specific value relates to a condition of the default alarm setting file.

13. The method according to claim 12, wherein the default alarm setting file lacks the value of the condition, and the updated alarm setting file includes the specific value of the condition.

14. The method according to claim 12, wherein the default alarm setting file includes the default value of the condition, and the updated alarm setting file includes the specific value of the condition.

15. Before receiving the user interface input via the HMI, transmitting, via the network, an alarm setting request including the function block identifier; receiving, in response to the transmission of the alarm setting request and via the network, the default alarm setting file; The method according to claim 11, further comprising the above steps.

16. further comprising detecting the occurrence of one or more alarm setting conditions, The method according to claim 15, wherein the step of transmitting the alarm setting request responds to the detection of the occurrence of the one or more alarm setting conditions.

17. The step of detecting the occurrence of the one or more alarm setting conditions includes: detecting the power-on of the DCN; detecting that the DCN is newly commissioned in the process automation system, and / or detecting that alarm monitoring is not currently active by the DCN of the function block. The method according to claim 16, comprising the above steps.

18. The method according to claim 11, wherein the function block identifier is unique to the function block and is not assigned to any other function block of the process automation system.

19. one or more network interfaces communicatively coupled to the network of the process automation system; a plurality of function block-specific alarm setting files, and an alarm database including a corresponding association to a corresponding function block identifier for each of the function block-specific alarm setting files; a plurality of alarm setting processors, receiving, via the network, an alarm setting request transmitted by a node of the process automation system and including the function block identifier of the function block. The alarm setting request includes the function block identifier based on the function block assigned for use in alarm monitoring by the node, Based on receiving the alarm setting request, determining whether the corresponding association in the alarm database includes an association to the function block identifier; In response to determining that the corresponding association in the alarm database includes an association to the function block identifier, Transmitting, in response to the alarm setting request, the alarm setting file specific to the function block having the relevance among the alarm setting files specific to the function block to the node; In response to determining that the corresponding association in the alarm database does not include an association to the function block identifier, Determining a default alarm setting file based on a specific type of the function block identified by the function block identifier; Transmitting, via the network, the default alarm setting file determined based on the specific type to the node, The default alarm setting file is locally editable via the node and, when edited, is used by the node when implementing alarm monitoring based on the function block, One or more alarm setting processors that execute stored instructions to perform the above; A process automation system comprising an alarm setting server including the above.

20. The process automation system according to claim 19, further comprising the node, wherein the node is a distributed control node (DCN) that performs the function block.

Images