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

Abstract

To provide a technique of solving various technical problems arising from generating, updating, and / or exploring a process automation system alarm.SOLUTION: Implementations transmit, to a distributed control node (DCN), default alarm configuration file(s) that are determined based on a particular type of function block. Those implementations transmit the default alarm configuration file(s) to the DCN based on determining that the DCN is executing a function block that is of the particular type and / or is utilizing a function block, that is of the particular type, in alarm monitoring. A default alarm configuration file that is transmitted to a DCN can be stored locally at the DCN to enable viewing and / or editing thereof via HMI interfacing with the DCN. Implementations reflect, in an alarms database accessible via a process automation network, local updates that are made via an HMI to a default alarm configuration file locally stored at a DCN.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] Alarms are utilized in process automation systems to detect potential anomalies and cause actions to be taken in response to the detection of the potential anomaly. The potential anomaly may be with respect to the process automation system and / or with respect to the process automation process in which the process automation system is deployed. Actions in response to an alarm may include, for example, causing a corresponding notification to be displayed in an interface monitored by an operator and / or causing a repair to be automatically performed (e.g., an automated process or sub-process being automatically stopped or adjusted). As an example, an alarm may be configured to monitor sensor readings from a sensor in the process automation system and cause a corresponding notification to be displayed if the sensor reading exceeds a high value (and / or a high-high value) and / or falls below a low value (and / or a low-low value).

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

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

[0004] A process automation control node may include a distributed control node (DCN) that includes hardware (e.g., processors, memory, network interfaces, input and / or output ports, and / or other hardware) and software (e.g., function blocks) executed by at least some of the hardware. For example, software may be included in a memory of the DCN and executed by a processor of the DCN. The software of the DCN may, for example, utilize data from input ports of the DCN and / or data from other DCNs during execution and / or generate output for provision via output ports and / or network interfaces (e.g., for transmission to one or more endpoints via a process automation network of a process automation system). Summary of the Invention [Problem to be solved by the invention]

[0005] Various technical challenges exist when generating, updating, and / or deploying process automation alarms in a process automation system that includes distributed and / or heterogeneous hardware and / or software. 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 the alarm engine. To enable monitoring of those process variables by the alarm engine, the DCN that generates and / or enables access to the process variables must be accessible to the alarm engine. Additionally, the alarm engine must access and utilize appropriate alarm configuration files in monitoring for the occurrence of corresponding alarm conditions and in response, generating corresponding actions. The alarm configuration files may define conditions for corresponding process variables that, when satisfied, cause the alarm engine to initiate the corresponding action. Additionally, when an action includes initiating rendering (e.g., visual and / or audible rendering) of a corresponding output in an alarm viewer, establishing a connection-oriented connection between the alarm engine and the alarm viewer may be necessary or desirable.

[0006] However, due to the distributed and / or heterogeneous nature of process automation systems, achieving one or more of the desires and / or requirements mentioned above or elsewhere herein may be tedious and / or error-prone. As an example, assume that an alarm configuration file is stored locally in a particular DCN and utilized by a local alarm engine of the particular DCN in monitoring process variables of particular function blocks on the particular DCN (e.g., monitoring the values ​​of those variables during execution of the particular function blocks). Further assume that the alarm configuration file is stored locally and utilized by the particular DCN on the basis of being pre-loaded into the particular DCN (prior to the operation of the DCN in the process automation system) or fully manually configured by a human machine interface (HMI) coupled to the DCN during operation. If a particular DCN is replaced with a new DCN and the same function blocks are 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 certain function blocks and / or alarm engines are removed from a particular DCN and newly implemented in an alternative DCN, manual reassignment of alarm configuration files to the alternative DCN may be required. In addition to being tedious and requiring the use of computing resources, any errors in the manual reassignment may result in the corresponding alarms not actually being active or being inaccurate (e.g. because different values ​​are defined), which may result in the occurrence of an alarm condition not being monitored and the corresponding actions not being taken, which may lead to unsafe conditions or other adverse effects on the process automation configuration.

[0007] These and / or other challenges may be exacerbated if one wishes to be able to configure process automation alarms locally in the DCN. For example, there may be a desire to allow employees or contractors at a process automation facility to configure process automation alarms for function blocks through user interaction with a human machine interface (HMI) that interfaces directly with the DCN. The HMI may interface directly with the DCN via a wired or wireless connection with the DCN and, optionally, after authentication (e.g., using a username and / or password) has been performed via input to the HMI. For example, it may be desired to locally specify values ​​that define the conditions for a process automation alarm and to locally specify values ​​for other parameters of the process automation alarm (e.g., alarm sensitivity values, alarm message content, and / or values ​​of other parameters). However, local adaptations made via interaction with a given DCN may not be reflected in a new DCN that replaces the given DCN and / or if a function block is removed from the given DCN and implemented in the replacement DCN. Furthermore, those local specifications may not be reflected in a central database that may be used by a non-local alarm configuration GUI that allows viewing and / or editing of all alarms in the system. [Means for solving the problem]

[0008] Implementations disclosed herein address these and other challenges by automatically deploying default alarm configuration files to a DCN. In these implementations, when automatically deploying default alarm configuration files to a DCN, the default alarm configuration file is determined based on the function block type of the function blocks that are performed by the DCN and / or utilized by the DCN's local alarm engine in alarm monitoring. For example, for an "AO" function block type, the default alarm configuration file may include files for "Error", "Level", "Rate of Change", and "Deviation" alarm types, but omit, for example, "Discrete", "Answerback Mismatch", and / or "Answerback Error" alarm types. As another example, for a "DI" function block type, the default alarm configuration file may include files for "Error" and "Discrete State" alarm types, but omit, for example, "Rate of Change", "Level", "Deviation", "Answerback Mismatch", and / or "Answerback Error" alarm types.

[0009] As referenced above, the default alarm configuration files deployed to the DCN may be deployed to the DCN in response to a determination that the DCN will perform a particular type of function block corresponding to the default alarm configuration file and / or a determination that the DCN will implement alarm monitoring based on a particular type of function block. For example, the DCN may transmit an alarm configuration request over the process automation network to an alarm configuration service that includes function block identifiers of function blocks to be performed by the DCN and / or utilized in alarm monitoring by the DCN. The alarm configuration service may determine the function block types based on the function block identifiers in the alarm configuration request. Additionally, upon request, the alarm configuration service may transmit default alarm configuration files for those function block types to the DCN.

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

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

[0012] In some implementations or circumstances, such as when access to the corresponding function block is available in determining the default alarm configuration file, the default alarm configuration file may include the actual process variables to which the condition pertains. In some alternative implementations or circumstances, the default configuration file may and / or may not include placeholder process variables. Rather, they may be specified later via interaction with an HMI coupled to a DCN where the default alarm configuration file is provided and stored locally. The default alarm configuration file may include additional and / or alternative parameters, optionally defining default values ​​and / or not defining values. For example, the default alarm configuration file may specify a default security level (e.g., a default level defined for the function block type and / or alarm type) and / or may 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 if the corresponding condition is met.

[0013] The default alarm configuration file transmitted to the DCN may be stored locally on the DCN for viewing and / or editing via an HMI that interfaces with the DCN. For example, the HMI may 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 configuration file stored locally on the DCN may initially be flagged as invalid, which prevents implementation by the alarm engine of the DCN. The default alarm configuration file stored locally on the DCN may also initially be missing values ​​for conditions and / or other parameters and / or contain initial default values ​​for parameters. When the HMI interfaces with the DCN, the HMI may enable viewing, editing, and / or deletion of the default alarm configuration file. Additionally, the invalid flag of the default alarm configuration file may be removed or changed to a valid flag after the alarm configuration file is updated (and optionally confirmed) via the HMI or after the default alarm configuration file is confirmed via the HMI. When the disable flag in the optionally updated default alarm configuration file is removed or changed to an enable flag, local alarm monitoring in the DCN can be started based on the optionally updated default alarm configuration file.

[0014] By providing a default alarm configuration file in accordance with implementations disclosed herein, an operator can edit the default alarm configuration file (e.g., its parameter values) in a more efficient manner than if the operator were to create the alarm configuration file from scratch via the HMI and with limited user interface input. Additionally, alarm configuration files that the operator does not want to implement can be easily deleted or left in an inactive state via the HMI. Additionally, various implementations provide default alarm configuration files to the DCN while the DCN is running, without requiring preloading of default configuration files into the DCN, and / or provide only default configuration files that are relevant to function blocks that are performed by the DCN and / or utilized in alarm monitoring by the DCN, preventing waste of DCN memory in storing irrelevant default configuration files.

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

[0016] For example, the DCN may transmit an alarm configuration update including any updated alarm configuration files modified locally at the DCN to an alarm configuration service that manages an alarm database, along with the function block identifier to which the updated alarm configuration file pertains. The DCN may send such a transmission in response to local modifications at the DCN, thereby enabling the alarm configuration service to update the alarm database to reflect the modifications. This enables viewing of the updated alarm configuration file by a non-local alarm configuration graphical user interface (GUI) and, optionally, further modification of the updated alarm configuration file via the non-local alarm configuration GUI (and subsequently providing the further modified alarm configuration file to the DCN). Furthermore, by storing the alarm configuration file in association with the function block identifier, a new or alternative DCN that later implements the function block in place of the original DCN may be provided with the updated alarm configuration file instead of providing the corresponding default alarm configuration file. For example, the new or alternative DCN may provide an alarm configuration request including the function block identifier to the alarm configuration service. The alarm configuration service may use the function block identifier in the request to identify the alarm configuration file from the alarm database and return the identified alarm configuration file to the DCN for implementation. If there is no alarm settings file stored in association with the functional block identifier, a default alarm settings file according to the type of functional block may be provided as described above.

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

[0018] Utilizing function block identifiers in deploying alarms according to implementations disclosed herein can enable alarm deployment that is robust and / or mitigates errors in distributed and / or heterogeneous process automation system settings. For example, utilizing function block identifiers in determining which alarm configuration file to provide in response to an alarm configuration request can mitigate issues that may arise due to an old DCN being replaced with a new DCN (having a new DCN identifier), an alarm engine monitoring function switching from a given DCN (having a given DCN identifier) ​​to an alternate DCN (having an alternate DCN identifier), etc.

[0019] In various implementations, an alarm configuration request may be issued by the DCN in response to the DCN detecting the occurrence of one or more alarm configuration conditions. For example, an alarm configuration request may be issued by the DCN in response to the DCN determining that it is newly commissioned (e.g., newly added to a process automation system), determining that it has been powered on (e.g., initially or after a reboot), determining that an alarm engine is assigned to monitor a function block but that monitoring is not currently active (e.g., due to a missing alarm configuration file for the function block), determining that a threshold period has elapsed since it last issued an alarm configuration request, receiving an update request from an alarm configuration service, and / or detecting the occurrence of other conditions. Having the DCN issue an alarm configuration request in response to detecting such a particular condition allows the DCN to proactively search for an alarm configuration file in situations where it is more likely to be needed. Additionally or alternatively, preventing the DCN from issuing an alarm configuration request when a particular condition is not detected may conserve resources of the process automation system. For example, network resources utilized in transmitting an alarm configuration request from the DCN to the alarm configuration service and / or network resources utilized by the alarm configuration service in responding to the alarm configuration request may be conserved.

[0020] Thus, implementations disclosed herein enable efficient deployment of alarm configuration files to appropriate process automation nodes as they come online in a newly commissioned process automation system. Additionally or alternatively, 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, implementations enable robust alarm adaptation when a first DCN performing and / or monitoring a first function block is replaced by a second DCN (e.g., having different hardware specifications) that also performs and / or monitors the first function block.

[0021] The above description is provided as a summary of some implementations of the present disclosure. Further descriptions of those and other implementations are described in more detail below.

[0022] Further, some implementations include one or more processors of the one or more devices, the one or more processors operable to execute instructions stored in associated memory, the instructions configured to cause any of the aforementioned methods to be performed. The processors may 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 transitory or non-transitory computer-readable storage media that store computer instructions executable by the 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 subject matter recited in the claims 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] FIG. 1 illustrates an example environment in which selected aspects of the present disclosure can be implemented, according to various implementations. [Diagram 2] 2 illustrates the example environment of FIG. 1 after an HMI is used in a DCN to update a default alarm settings file previously received in some of the DCNs. [Diagram 3] 3 illustrates the exemplary environment of FIGS. 1 and 2 from the point in time of FIG. 2 onward and after the DCNs of FIGS. 1 and 2 have been replaced with alternative DCNs. [Figure 4] 2 after the time of FIG. 2 and after the DCNs of FIGS. 1 and 2 have been modified to remove the alarm monitoring functionality, and the alarm monitoring functionality removed from the DCN has been implemented in another DCN. [Diagram 5] FIG. 13 illustrates an exemplary method for processing an alarm setting request from a DCN, including at least selectively responding to the alarm setting request by transmitting to the DCN a default alarm setting file that is determined based on the functional block type of the functional block indicated by the alarm setting request. [Figure 6] FIG. 1 illustrates an example method for processing alarm configuration updates from a DCN. [Figure 7] 1 illustrates an exemplary method for generating and transmitting an alarm configuration request, receiving an alarm configuration file in response, and implementing local alarm monitoring based on the received alarm configuration file. [Figure 8]FIG. 1 illustrates generally an exemplary computer architecture in which selected aspects of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] Implementations disclosed herein relate to ensuring robust and / or accurate alarm monitoring based on function blocks implemented by the DCN of a process automation system. At least a subset of such function blocks are each utilized in implementing at least a portion of a corresponding at least partially automated process. As used herein, an "at least partially automated process" includes any process implemented by multiple devices in a process automation system in a collaborative manner 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 operated automatically (without human intervention) based on the output of one or more sensors. Some at least partially automated processes may be sub-processes of an overall process automation system workflow, such as the single process loop mentioned above. Other at least partially automated processes may include all or a significant portion of an overall process automation system workflow. In some cases, the degree to which a process is automated may exist according to a gradient, scope, or scale of automation. Processes that are partially automated but still require human intervention may be at or near one end of the scale. Processes that do not require much 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 a variety of domains, such as the manufacturing, development, and / or refinement of chemicals (e.g., chemical processing), catalysts, machines, and / or other domains.

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

[0027] The process automation network 106 may 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), cellular networks such as 3GPP® Long Term Evolution ("LTE") or other wireless protocols designated as 3G, 4G, 5G, and beyond, and / or other types of communication networks of various types of topologies (e.g., mesh). Process automation is often employed 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 implementations, the process automation network 106 may be configured with redundancy and / or backups to provide high availability (HA) and / or high quality of service (QoS). Additionally, nodes exchanging data over the process automation network 106 may implement time-sensitive networking (TSN) to facilitate time synchronization and / or real-time control streams. Various nodes / devices, such as an alarm configuration service 120, an alarm viewer 140, and DCNs 110A-N, are operatively 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) DCNs can be provided in the process automation system 108, as indicated by the ellipsis between DCN 110C and DCN 110N. Some DCNs in the process automation system 108 can have input / outputs (I / O) for coupling with sensors, HMIs, actuators, and / or other components. Other DCNs in the process automation system 108 can optionally omit I / O.

[0029] The DCN 110A is coupled to a flow transmitter (FT) component 111A via a first I / O and to an actuator (e.g., valve) 113A via a second I / O. The actuator 113A, as well as other actuators described herein, may be electrical, hydraulic, mechanical, and / or pneumatic components controllable to affect some aspect of the process automation workflow occurring in the process automation equipment 108. The FT component 111A includes sensors that provide sensor data indicative of the flow rate of the corresponding fluid streams, and also includes actuators that are adjustable to control the corresponding fluid streams. The sensors described herein may take a variety of forms, including, but not limited to, pressure sensors, temperature sensors, flow sensors, various types of proximity sensors, optical sensors (e.g., photodiodes), pressure wave sensors (e.g., microphones), humidity sensors (e.g., humistors), radiation dosimeters, laser absorption spectroscopy (e.g., multi-pass optical cells), and / or other forms.

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

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

[0032] The alarm engine 116A may optionally be implemented utilizing an open standard protocol. For example, the alarm engine 116A may be implemented by an Open Platform Communication (OPC) Unified Architecture (OPC-UA) server executed on the DCN 110A by its processor 112A. The alarm engine 116A may utilize the alarm configuration file described herein in monitoring for the occurrence of alarm conditions indicated by the alarm configuration file and performing corresponding actions when an alarm condition is detected. The corresponding actions may also be optionally indicated by the alarm configuration file. The conditions defined by the alarm configuration file may include, or be limited to, conditions that reference process variables of the function block, such as input variables, output variables, through variables, and / or internal variables of the function block.

[0033] Actions taken in response to an alarm condition detected by the alarm engine 116A may include, for example, sending corresponding data to the alarm viewer 140 to cause rendering of a corresponding audible and / or visual alarm message in one or more output interfaces. The sending of the corresponding data may occur via a connection-oriented communication session established between the alarm engine 116A and the alarm viewer 140. Additionally or alternatively, actions taken in response to a detected alarm condition may include causing a remediation to occur. For example, stopping and / or modifying a functional block causing the alarm condition and / or an associated functional block.

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

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

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

[0037] The alarm engine 116C may optionally be implemented utilizing an open standard protocol such as an OPC-UA server executed on the DCN 110C by its processor 112C. The alarm engine 116C may utilize the alarm configuration file described herein in monitoring for the occurrence of alarm conditions indicated by the alarm configuration file and in performing corresponding actions when an alarm condition is detected. The conditions defined by the alarm configuration file may include or be limited to conditions that refer to process variables of function blocks. The function blocks monitored by the alarm engine 116C include function blocks that are not executed by the DCN 110C (because the DCN 110C does not execute any function blocks). For example, the alarm engine 116C may monitor the function block 114B of the DCN 110B and / or function blocks of other DCNs. For example, monitoring the execution of the function block 114B may be via a communication from the DCN 110B reflecting the process variable of the function block 114B executing. Such communication may optionally occur via a connection-oriented communication session between DCN 110B and DCN 110C, for example, via the process automation network 106.

[0038] Actions performed in response to an alarm condition detected by the alarm engine 116C may include, for example, causing a remediation to be performed and / or transmitting corresponding data via a connection-oriented communication session to the alarm viewer 140 to cause the rendering of a corresponding audible and / or visual alarm message in one or more output interfaces.

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

[0040] Actions performed in response to an alarm condition detected by the alarm engine 116N may include, for example, causing a remediation to be performed and / or transmitting corresponding data via a connection-oriented communication session to the alarm viewer 140 to cause the rendering of a corresponding audible and / or visual alarm message in one or more output interfaces.

[0041] The alarm configuration service 120 is shown as including a configuration module 122, a request and / or update module 124, and a push module 126. In some implementations, the alarm configuration service 120 is implemented within a process automation facility, for example, within a single building, or a single campus of buildings, or throughout other industrial infrastructure. In such implementations, the alarm configuration service 120 may 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 the alarm configuration service 120 may be implemented in computing systems remote from the process automation facility. In some of those implementations, the alarm configuration service 120 may communicate with the process automation network 106 over a wide area network.

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

[0043] The alarm configuration files and their associations may be generated based on user interface input from engineers and / or other humans who implement and / or maintain 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 including a functional block identifier, the request and / or update module 124 can provide the functional block identifier and an indication of the default alarm configuration file to the configuration module 122. In response, the configuration module 122 can store the functional block identifier, the default alarm configuration file, and the association between the functional block identifier and the default alarm configuration file in the alarm database 125. As another example, when the request and / or update module 124 receives an alarm configuration update including an updated default alarm configuration file and the corresponding functional block identifier, the request and / or update module 124 can provide the functional block identifier and an indication of the updated default alarm configuration file to the configuration module 122. In response, the configuration module 122 can store the functional block identifier, the updated default alarm configuration file, and the association between the functional block identifier and the default alarm configuration file in the alarm database 125.

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

[0046] In some implementations, the alarm configuration files and some of their associations can be received via a non-local alarm configuration graphical user interface (GUI) 130. The alarm configuration GUI 130 can be implemented via the configuration module 122 or 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 fields for specifying function block identifiers (e.g., from a drop-down menu, via free-form input, via search or auto-complete based on entered characters) and can also include fields for specifying function block variables and conditions for those variables. For example, the alarm configuration GUI 130 can allow for the specification of function block identifiers and, once the function block identifiers are specified, can present the function block variables for the corresponding function block. Additionally, each of the function block variables can be selectable and, when selected, a condition corresponding to the function block variable can be defined through further interaction with the alarm configuration GUI. The selected function block variables and conditions can be used to generate corresponding alarm configuration files and corresponding alarm configuration files associated with the function block identifiers. Updates to the alarm configuration files can be performed via further bulk configuration files and / or via further interaction with the alarm configuration GUI 130. For example, the alarm configuration GUI 130 can allow viewing and modifying (or deleting) existing alarm configuration files in the alarm database 125 (optionally while maintaining the association with the function block identifiers and optionally with the DCN identifiers).

[0047] It should be noted that interaction with the alarm configuration GUI 130 can be used to define and / or update alarm configuration files and to define associations between alarm configuration files and function block identifiers, as described herein. Additionally, the alarm configuration files and associations can be stored in the alarm database 125 and provided for implementation on a corresponding DCN in response to a corresponding alarm configuration 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 configuration GUI 130 may not be communicatively directly coupled to any DCN and / or may not directly interact with any DCN (e.g., with its alarm engine) in defining and / or updating alarm configuration files.

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

[0049] The alarm configuration request received by the request and / or update module 124 may include a function block identifier of the function block and, optionally, a DCN identifier of the DCN that transmitted the alarm configuration request. In response to receiving the alarm configuration request, the request and / or update module 124 may access the alarm database 125 to determine whether there is a unique function block identifier in the alarm database 125 that matches the identifier of the alarm configuration request and is stored in association with an alarm configuration file. If so, the request and / or update module 124 may identify an alarm configuration file that is stored in association with the matching function block identifier. Further, the request and / or update module 124 may transmit the identified unique alarm configuration file in response to the alarm configuration request and the DCN that issued the alarm configuration request over the process automation network. If the request and / or update module 124 determines that there is no unique function block identifier in the alarm database 125 that matches the identifier of the alarm configuration request and is stored in association with an alarm configuration file, a default alarm configuration file may be determined based on the function block identifier. For example, the default alarm configuration file can be stored in the alarm database 125 and / or can be generated based on data from the alarm database 125. Additionally, the request and / or update module 124 can transmit the default alarm configuration file over the process automation network in response to an alarm configuration request and a DCN that issued the alarm configuration 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 optionally store an association of the DCN identifier included in the alarm configuration request with the identified function block identifier and / or the identified alarm configuration file. In doing so, the configuration module 122 may optionally delete a stored association of a disparate DCN identifier to the identified function block identifier and / or the identified alarm configuration file.

[0051] An alarm configuration update received by the request and / or update module 124 may include a function 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 a default alarm configuration previously provided to the DCN, but including new values ​​based on modifications made via an HMI-DCN interaction. 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 the function block identifiers and alarm configuration file of the alarm configuration update and the association of the function block identifiers to the alarm configuration file in the alarm database 125. In some implementations, the request and / or update module 124 also causes the configuration module 122 to store an association of the DCN identifier, optionally included in the alarm configuration update, with the received function block identifier and / or the received alarm configuration file.

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

[0053] In some implementations, when causing the DCN corresponding to the DCN identifier to provide an updated alarm configuration file, the push module 126 can transmit the updated alarm configuration file to the DCN identifier regardless of an alarm configuration request from the DCN. For example, the DCN identifier can be an IP address, and the push module 126 can transmit the updated alarm configuration file to the IP address. In some implementations, when causing the DCN corresponding to the DCN identifier to provide an updated alarm configuration file, the push module 126 can transmit an update request to the DCN identifier that, when received by the DCN, can be determined to be an alarm configuration condition. The DCN can then transmit the alarm configuration request if deemed appropriate by the DCN. The alarm configuration request can be processed by the request and / or update module 124, and the updated alarm configuration file is transmitted by the request and / or update module 124 to the DCN in response to the alarm configuration request.

[0054] In some implementations, the alarm viewer 140 is implemented within the process automation facility. In such implementations, the alarm viewer 140 may 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 may be implemented in a computing system remote from the process automation facility. In some of those implementations, the viewer 140 may communicate with the process automation network 106 over a wide area network. The alarm viewer 140 may communicate with the alarm engines of the DCNs 110A-N over connection-oriented communication sessions.

[0055] The alarm viewer 140 can cause rendering of at least any active alarms via one or more output devices in response to and in accordance with alarm messages received via the alarm engine via respective connection-oriented communication sessions. For example, the alarm viewer 140 can cause at least the active alarms to be displayed via a fixed display screen within the 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 cause transmission of at least some active alarms (e.g., alarms designated as “high severity” in a corresponding alarm configuration file) to an individual's mobile phone through an alarm app installed on the mobile phone, e.g., as a text message alert or push notification. Such transmission can occur 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 aural and / or visual rendering of a descriptor or other message corresponding to the condition that caused the alarm, such as a descriptor defined in the alarm configuration file for the alarm.

[0056] An active alarm may be signaled to the alarm viewer 140 based on a transmission from the DCN where the alarm engine has determined that an active alarm has occurred. The transmission may include a message regarding the alarm, a descriptor of the alarm determined, for example, using an alarm configuration file, an identification of the function block and / or process variable that caused the alarm, and / or a display of the alarm configuration file. The alarm viewer 140 may utilize information contained in the transmission from the DCN and / or information derived from the alarm database 125 utilizing information contained in the transmission in rendering the details of the alarm.

[0057] 1 illustrates an example environment 100 at a first time point, such as during or shortly after initial commissioning of a process automation system 108. In some implementations, during initial commissioning, one or more of the 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 stored alarm configuration files. After connecting to the process automation network 106, one or more such DCNs 110A-N may each transmit a corresponding alarm configuration request and, in response, obtain a responsive specific alarm configuration file and / or a responsive default alarm configuration file from the alarm configuration service 120.

[0058] 1, DCN 110A transmits alarm configuration request 117A including 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 may access alarm database 125 and determine that no unique alarm configuration file is stored in association with the function block identifier of request 117A. The unique alarm configuration file is a non-default alarm configuration file. The unique alarm configuration file may be stored in alarm database 125 in association with the function block identifier based on, for example, an association defined in bulk configuration file 135, an association defined via alarm configuration GUI 130, or an association defined by a previous alarm configuration update.

[0059] In response to determining that no unique alarm settings file is stored in association with the function block identifier of the request 117A, the request and / or update module 124 can determine a default alarm settings file 119A corresponding to the function block type based on the function block type indicated by the function block identifier. Additionally, the request and / or update module 124 can transmit the default alarm settings files 119A to the DCN 110A for storage locally by the DCN 110A. As a particular example, the function block identifier of the request 117A can end with ".PV" to indicate that it is a process variable type. The default alarm settings file 119A of that type can include default alarm settings files for "error," "level," "rate of change," and "deviation," for example.

[0060] Also, for example, in FIG. 1 , the DCN 110C transmits to the request and / or update module 124 an alarm configuration request 117C that includes a function block identifier of a function block monitored by the alarm engine 116C, such as function block 114B of the DCN 110B as described above. The request and / or update module 124 can access the alarm database 125 and determine that a unique alarm configuration file 119C is stored in association with the function block identifier of the request 117C. For example, the unique alarm configuration file stored in association with the function block identifier can be one defined via the bulk configuration file 135. In response to determining that a unique alarm configuration file 119C is stored in association with the function block identifier of the request 117C, the request and / or update module 124 transmits the unique alarm configuration file 119C to the DCN 110C to be stored locally by the DCN 110C and to cause the alarm engine 116C to implement local alarm monitoring based on the unique alarm configuration file 119C. Thus, the unique alarm settings file 119C is transmitted to the DCN 110C in response to the request 117C, instead of the default alarm settings file, the unique alarm settings file 119C being stored in the alarm database 125 in association with the functional block identifier.

[0061] 1, for example, the DCN 110N transmits an alarm configuration request 117N that includes a function block identifier of a function block 114N monitored by the alarm engine 116N to the request and / or update module 124. The request and / or update module 124 may access the alarm database 125 and determine that no unique alarm configuration file is stored in association with the function block identifier of the request 117N.

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

[0063] 2, exemplary environment 100 is shown after alarm configuration requests 117A-C of FIG. 1 have been provided and default alarm configuration files 119A and 119N have been provided to DCNs 110A and 110N, respectively. Additionally, exemplary environment 100 is shown after HMI 145A has been utilized to update default alarm configuration file 119A in DCN 110A and HMI 145B has been utilized to update default alarm configuration file 119N in DCN 110N.

[0064] As an example, the default alarm configuration file 119A transmitted to the DCN 110A may include a file that is a level alarm for the measured flow variable (based on the sensor of the FT component 111A) of the function block 114A, but may lack any designated values ​​for high-high, high, low, and / or low-low. The HMI 145A, when coupled to the DCN 110A (e.g., via a wired or wireless connection), may provide a GUI that can be used to define the designated values ​​for high-high, high, low, and / or low-low, thereby creating an updated default alarm configuration file. As another example, the default alarm configuration file 119A may include a file that is a rate of change alarm for the measured flow variable, but may lack a designated value for a maximum rate of change for the measured flow variable. The HMI 145A, when coupled to the DCN 110A (e.g., via a wired or wireless connection), may be used to define a value for the maximum rate of change, thereby creating an additional updated default alarm configuration file.

[0065] 2, DCN 110A transmits an alarm configuration update 118A including the updated default alarm configuration file and corresponding function block identifiers to alarm configuration service 120. In response to receiving alarm configuration update 118A, alarm configuration service 120 stores the updated default alarm configuration file and an association between the file and the corresponding function block identifiers in alarm database 125.

[0066] 2, the DCN 110N transmits an alarm configuration update 118N including the updated default alarm configuration file and corresponding function block identifiers to the alarm configuration service 120. In response to receiving the alarm configuration update 118N, the alarm configuration service 120 stores the updated default alarm configuration file and an association between the file and the corresponding function block identifiers in the alarm database 125.

[0067] 3, an exemplary environment 100 is shown after the time of FIG. 2 and after the DCN 110A of FIG. 1 and FIG. 2 has been replaced with an alternative DCN 110A1. The alternative DCN 110A1 can replace the DCN 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 associated memory (and corresponding instructions stored therein) to implement corresponding functions of the DCN 110A1. Those functions include implementing functional blocks 114A1 of the DCN 110A1, which can be stored in a portion of the associated memory and can be the same as the functional block 114A of the DCN 110A. Those functions also include implementing an alarm engine 116A1. In response to operation or power-on, DCN 110A1 may transmit an alarm setting request 117A1 including function block identifiers of function blocks monitored by function block 114A1 and / or alarm engine 116A1, which may be the same as those of DCN 110A (FIG. 1).

[0068] The requesting and / or updating module 124 can identify updated alarm configuration files included in the alarm configuration update 118A (FIG. 2) from the alarm database 125 in response to the alarm configuration request 117A1. The updated alarm configuration files can be identified based on being stored in the alarm database 125 in association with the function block identifiers of the alarm configuration request 117A1, and can be considered unique alarm configuration files 119A1 based on being stored in association with the function block identifiers. Additionally, the requesting and / or updating module 124 can transmit the unique alarm configuration files 119A1 to the DCN 110A1 for implementation of the unique alarm configuration files 119A1 by the alarm engine 116A1 of the DCN 110A1.

[0069] Additionally, the request and / or update module 124 can optionally update the alarm database 125 to store an association of the DCN identifier of DCN 110A1 with the unique alarm configuration file 119A1 and / or function block identifiers and / or provide the DCN identifier of DCN 110A1 to the alarm viewer 140. Note that the DCN identifier of DCN 110A1 can be unique with respect to the DCN identifier of the replaced DCN 110A. Updating the alarm database 125 to reflect the DCN identifier of DCN 110A1 and / or providing a push notification to the alarm viewer 140 can enable the alarm viewer 140 to establish a connection-oriented communication session with DCN 110A1 and / or enable the effective pushing of the updated alarm configuration file by the push module 126. Additionally, the unique DCN identifier of DCN 110A1 indicates the robustness of including the function block identifier in the alarm configuration request and its use by the requesting and / or updating module 124 when responding to the alarm configuration request 117A1. For example, if some of the responding unique alarm configuration files 119A1 were instead stored in association only with the DCN identifier of DCN 110A, and the DCN identifier of DCN 110A1 was included in the request instead of the function block identifier, the requesting and / or updating module 124 would not be able to identify such alarm configuration files in response to the alarm configuration request from DCN 110A1.

[0070] Figure 4 illustrates the example environment of Figures 1 and 2 from the point in time of Figure 2 onwards and after DCN 110A of Figures 1 and 2 has been modified to remove alarm engine 116A, and the alarm monitoring functions previously performed by alarm engine 116A are now assigned for monitoring by the modified alarm engine 116C1 of DCN 110C. In response to detecting an alarm setting condition, DCN 110C may transmit an alarm setting request 117C1 that includes function block identifiers of at least the function blocks previously monitored by alarm engine 116A.

[0071] The request and / or update module 124 can identify updated alarm configuration files included in the alarm configuration update 118A (FIG. 2) from the alarm database 125 in response to the alarm configuration request 117C1. The updated alarm configuration files can be identified based on being stored in association with the functional block identifiers of the alarm configuration request 117C1, and are considered to be unique alarm configuration files 119A1 based on being stored in association with the functional block identifiers in the alarm database 125. Furthermore, the request and / or update module 124 can transmit the unique alarm configuration file 119A1 to the DCN 110C for implementation of the unique alarm configuration file 119A1 by the alarm engine 116C1 of the DCN 110C. Furthermore, the request and / or update module 124 can optionally update the alarm database 125 to store an association between the DCN identifier of the DCN 110C and the unique alarm configuration file 119A1 and / or the functional block identifiers.

[0072] 5 is a flow chart illustrating an example method 500 for processing an alarm configuration request from a DCN, including at least selectively responding to the alarm configuration request by transmitting to the DCN a default alarm configuration file determined based on the functional block type of the functional block indicated by the alarm configuration request. For convenience, the operations of the flow chart are described with reference to a system that performs the operations. The system may include various components of various computer systems, such as alarm configuration service 120 (e.g., request and / or update module 124). Additionally, 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 reordered, omitted, or added.

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

[0074] In block 504, the system determines whether there is a unique alarm configuration file stored in an alarm database in association with the function block identifier (of the alarm configuration request of block 502). For example, the system may search the alarm database using the function block identifier to determine whether a stored association between the function block identifier and a unique alarm configuration file is present. As described herein, a unique alarm configuration file is a default alarm configuration file that has been updated (based on HMI input) or a non-default alarm configuration file, such as one defined via bulk upload and / or a non-local alarm configuration 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 as requested at block 502 and over the process automation network. The system may then optionally proceed to optional block 508, where the system stores a DCN identifier associated with the alarm configuration request in an alarm database in association with the transmitted alarm configuration file and / or in association with the function block identifier. For example, the DCN identifier may be an addressable DCN identifier (e.g., an IP address) included in a header or body of the alarm configuration request.

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

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

[0078] In sub-block 512A, if the system has access to a function block corresponding to the function block identifier, the system optionally includes a process variable from the function block in a default alarm configuration file. The system may access the function block based on the function block being included in the alarm configuration request of block 502 or based on the function block being stored in association with the function block identifier in the alarm database. As an example of sub-block 512A, assume a default alarm configuration file for an "excursion" alarm type and a function block includes a process variable of "tank123temp." In sub-block 512A, the system may include "tank123temp" as a process variable in the default alarm configuration file to be compared to the excursion value in determining if an excursion condition has occurred. This eliminates the need for future specification of the process variable via an HMI coupled to the DCN.

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

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

[0081] 6 is a flow chart illustrating an example method 600 for processing alarm configuration updates from a DCN. For convenience, the operations of the flow chart are described with reference to a system that performs the operations. The system may include various components of various computer systems, such as alarm configuration service 120 (e.g., request and / or update module 124). Additionally, 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 reordered, omitted, or added.

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

[0083] At block 604, the system stores the alarm settings files of the alarm settings update as unique files in the alarm database. The system also stores each of the alarm settings files of the alarm settings update in the alarm database in association with the functional block identifier of the alarm settings update.

[0084] 7 is a flow chart of an exemplary method 700 of generating and transmitting an alarm configuration request, receiving an alarm configuration file in response, and implementing local alarm monitoring based on the received alarm configuration file. For convenience, the operations of the flow chart are described with reference to a system that performs the operations. The system may include various components of various computer systems, such as any of the DCNs 110A-N. Additionally, 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] At block 702, the system monitors for the occurrence of an alarm setting condition. If an alarm setting condition is detected at block 702, the system proceeds to block 704. In some implementations, at block 702, the system monitors for the occurrence of any one of a number of conditions, such as determining that an alarm has been newly powered up, determining that a power has been applied, determining that an alarm engine is assigned to the monitoring functional block but monitoring is not currently active, determining that the time since the last alarm setting request has exceeded a threshold period, and / or receiving an update request from an alarm setting service (e.g., from the push module 126).

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

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

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

[0089] At block 710, the system determines whether all received alarm configuration files are duplicates, i.e., whether all received alarm configuration files are already stored locally and utilized locally by the system's alarm engine in performing alarm monitoring. If so, the system returns to block 702 to monitor for the occurrence of another alarm configuration condition. If not, the system proceeds to block 712.

[0090] At block 712, the system determines for each received alarm configuration file whether it is a default alarm configuration file or a unique alarm configuration file. If the system determines that the alarm configuration file is a unique alarm configuration file, the system proceeds to block 714 and implements local alarm monitoring based on the received alarm configuration file and the function block. When implementing local alarm monitoring based on the alarm configuration file and the function block, the system may monitor the function block for satisfying a condition in the alarm configuration file (e.g., during execution of the function block) and, in response to detecting that the condition is satisfied, perform a corresponding action for the satisfied condition.

[0091] If, at block 712, the system determines that the alarm settings file is the default alarm settings file, the system proceeds to block 716. At block 716, the system stores the default alarm settings file locally but does not immediately implement alarm monitoring based on the default alarm settings file. Rather, the system waits for HMI interaction to update the default alarm settings file, and optionally verifies the updated default alarm settings file, before implementing alarm monitoring based on the updated alarm settings file.

[0092] At block 717, the system waits for HMI interaction to update the default alarm settings file and, optionally, validates the updated default alarm settings file. For example, the system waits for user input provided via an HMI while communicatively coupled to the system to specify one or more unspecified values ​​in the default alarm settings file and / or to change one or more default values ​​in the default alarm settings file.

[0093] In block 717, once the default alarm settings file is updated and optionally an HMI interaction occurs to confirm the updated default alarm settings file, the system proceeds to block 720. In block 720, the system implements local alarm monitoring based on the updated alarm settings file and function blocks.

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

[0095] Block 810 may optionally include sub-block 810A. In sub-block 810A, when implementing local alarm monitoring based on the received alarm configuration file and the function blocks, the system monitors the function blocks for satisfying a condition in the alarm configuration file (e.g., during execution of the function blocks), and in response to detecting that the condition is satisfied, performs a corresponding action for the satisfied condition, such as transmitting corresponding data to an alarm viewer.

[0096] 8 is a block diagram of an exemplary computing device 810 that may optionally be utilized to perform one or more aspects of the techniques described herein. For example, the computing device 810 is an example of a computing device that may implement all or a portion of an alarm setting service and / or, optionally, all or a portion of some DCN. The computing device 810 typically includes at least one processor 814 that communicates with a number of peripheral devices via a bus subsystem 812. These peripheral devices may include, for example, a storage subsystem 824 including 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 allow a user to interact with the computing device 810. The network interface subsystem 816 provides an interface to an external network and is coupled to corresponding interface devices in other computing devices.

[0097] The user interface input devices 822 may include pointing devices such as a keyboard, a mouse, a trackball, a touchpad, or a graphics tablet, a scanner, a touch screen integrated into a display, audio input devices such as a voice recognition system, a microphone, and / or other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and methods for inputting information onto the computing device 810 or a communications network.

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

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

[0100] These software modules are generally executed by the processor 814 alone or in combination with other processors. The memory 825 used in the storage subsystem 824 can include multiple 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 persistent storage for program and data files and can include a hard disk drive, a removable media associated with a floppy disk drive, a CD-ROM drive, an optical drive, or a removable media cartridge. Modules that implement the functionality of a particular implementation can be stored by the file storage subsystem 826 in the storage subsystem 824 or on other machines accessible by the processor 814.

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

[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 Figure 8 is intended only as a specific example intended to illustrate some implementations. Many other configurations of the computing device 810 are possible having more or fewer components than the computing device shown in Figure 8.

[0103] Although several implementations have been described and illustrated herein, various other means and / or structures may be utilized to perform the functions and / or obtain the results and / or one or more advantages described herein, and each such variation and / or modification is deemed 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 applications for which the teachings are used. Those skilled in the art will recognize, or be able to discover with no more than routine experimentation, many equivalents to the specific implementations described herein. Thus, it should be understood that the implementations described above have been presented by way of example only, and 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 each individual feature, system, article, material, kit, and / or method 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 that includes determining whether a distributed control node (DCN) of a process automation system is performing a function block of a particular type. The method further includes determining a default alarm configuration file based on the particular type. The method further includes transmitting, in response to determining that the DCN is performing a function block of the particular type, the default alarm configuration file determined based on the particular type to the DCN over a network of the process automation system. The default alarm configuration file is editable locally via the DCN and, once edited, is used by the DCN in implementing alarm monitoring based on the function block.

[0105] These and other implementations of the techniques disclosed herein may include one or more of the following features.

[0106] In some implementations, the method further includes, after transmitting a default alarm configuration file of a particular type to the DCN, receiving, over the network and from the DCN, an alarm configuration update including function block identifiers of function blocks performed by the DCN and an updated alarm configuration file that is an edited version of the previously transmitted default alarm configuration file, and storing the updated alarm configuration file and an association of the updated alarm configuration file with the function block identifiers in an alarm database. In some versions of these implementations, the method further includes, after storing the updated alarm configuration file and an association of the updated alarm configuration file with the function block identifiers in the alarm database, receiving, over the network, an alarm configuration request transmitted by an additional DCN of the process automation system and including the function block identifiers. In those versions, the method further includes, in response to receiving the alarm configuration request, obtaining the updated alarm configuration file from the alarm database based on the alarm configuration file stored in association with the function block identifiers and the function block identifiers included in the received alarm configuration request, and transmitting, over the network of the process automation system, the updated alarm configuration file to the additional DCN. The step of transmitting the updated alarm configuration file causes the additional DCN to implement alarm monitoring in accordance with the updated alarm configuration file. In some of those versions, the additional DCN is a newly activated DCN that replaces a DCN in the process automation system. In other of those versions, the additional DCN is a previously activated DCN that performed function blocks upon alarm configuration requests, and the DCN no longer performs function blocks upon alarm configuration requests.

[0107] In some implementations, determining that the DCN is performing a particular type of function block includes receiving an alarm configuration request over the network, the alarm configuration request being transmitted by the DCN and including a function block identifier of the function block, and determining that the DCN is performing a particular type of function block based on the function block identifier included in the alarm configuration request. In some versions of these implementations, determining that the DCN is performing a particular type of function block based on the function block identifier included in the alarm configuration request includes determining the particular type based on the function block identifier including one or more characters that map to the particular type. In some additional or alternative versions of these implementations, the method further includes determining whether there is a particular alarm configuration file stored in association with the function block identifier in the alarm database in response to receiving the alarm configuration request. In additional or alternative versions of these implementations, transmitting the default alarm configuration file to the DCN is further responsive to determining that there is no particular alarm configuration file stored in association with the function block identifier.

[0108] In some implementations, the default alarm configuration file defines one or more conditions to be monitored in implementing alarm monitoring, and for each one or more conditions includes a corresponding default value or no value. In some of those implementations, the method further includes identifying function blocks performed by the DCN, and determining the default alarm configuration file includes modifying a generic alarm configuration file of a particular type to include one or more process variables of the function blocks performed by the DCN.

[0109] In some implementations, a method is provided that is implemented by a hardware processor of a distributed control node (DCN) of a process automation system, the method including receiving a 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 configuration file that is stored locally in the DCN and associated with a function block performed by the DCN. The method further includes generating an updated alarm configuration file based on the default alarm configuration file and the one or more determined updates, implementing alarm monitoring based on the updated alarm configuration file and the function block, and transmitting the alarm configuration update including the updated alarm configuration file and a function block identifier of the function block over a network of the process automation system. The transmitting of the request causes the updated alarm configuration file to be stored in an alarm database in association with the function block identifier.

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

[0111] In some implementations, determining one or more updates to the default alarm configuration file based on the user interface input includes determining, based on the user interface input, specific values ​​for the one or more updates, where the specific values ​​are for conditions in the default alarm configuration file. In some versions of these implementations, the default alarm configuration file is missing a value for the condition and the updated alarm configuration file includes the specific value for the condition. In other versions of these implementations, the default alarm configuration file includes a default value for the condition and the updated alarm configuration file includes the specific value for the condition.

[0112] In some implementations, the method further includes transmitting, over a network, an alarm setting request including the function block identifier prior to receiving user interface input via the HMI, and receiving, over the network, a default alarm setting file in response to transmitting the alarm setting request. In some versions of these implementations, the method further includes detecting an occurrence of one or more alarm setting conditions, and in those versions, transmitting the alarm setting request is responsive to detecting the occurrence of the one or more alarm setting conditions. In some of those versions, detecting the occurrence of the one or more alarm setting conditions includes detecting power-up 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 implementations, the function block identifier is unique to the function block and is not assigned to any other function block in the process automation system.

[0114] In some implementations, a process automation system is provided that includes an alarm configuration server including one or more network interfaces communicatively coupled to a network of the process automation system, an alarm database including a plurality of function block specific alarm configuration files and a corresponding association for each of the function block specific alarm configuration files to a corresponding function block identifier, and one or more alarm configuration processors. The alarm configuration processor performs stored instructions to: receive an alarm configuration request transmitted by a node of the process automation system over the network and including a function block identifier for a function block, the function block identifier being based on a function block assigned for use in alarm monitoring by the node; determine whether the corresponding association in the alarm database includes an association to the function block identifier based on receiving the alarm configuration request; transmit the associated one of the function block specific alarm configuration files to the node in response to the alarm configuration request in response to a determination that the corresponding association in the alarm database does not include an association to the function block identifier; determine a default alarm configuration file based on a particular type of the function block identified by the function block identifier; and transmit the default alarm configuration file determined based on the particular type to the node over the network. The default alarm configuration file is locally editable via the node and, once edited, is used by the node in implementing alarm monitoring based on the function blocks. [Explanation of symbols]

[0115] 100 Environment 106 Process Automation Network 108 Process Automation Systems 108 Process Automation Equipment 110A~110N Distributed Control Node (DCN) 110A1 Alternate DCN 110B DCN 110C DCN 110N DCN 111A Flow Transmitter (FT) Components 111B Flow Transmitter (FT) Components 112A Processor 112A1 Processor 112B Processor 112C Processor 112N Processor 113A Actuator 114A Function Block 114A1 Function Block 114B Function Block 114N Function Block 115B Sensor 115N Sensor 116A Alarm Engine 116A1 Alarm Engine 116C Alarm Engine 116C1 Alarm Engine 116N Alarm Engine 117A~C Alarm setting request 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 configuration file 119A1 Specific alarm setting file 119C Alarm setting file 119N Default alarm configuration file 120 Alarm setting service 122 Settings Module 124 Request and / or Update Module 125 Alarm Database 126 Push Module 130 Non-Local Alarm Configuration Graphical User Interface (GUI) 135 Bulk Configuration Files 140 Alarm Viewer 145A HMI 145B HMI 500 ways 600 ways 700 methods 704 DCN Execution Block 810 Computing Devices 812 Bus Subsystem 814 Processor 816 Network Interface Subsystem 820 User Interface Output Device 822 User Interface Input Devices 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. 1. A method implemented by one or more processors, comprising: determining that a distributed control node (DCN) of the process automation system is performing a particular type of function block; determining a default alarm configuration file based on the particular type; in response to determining that the DCN is performing the function block of the particular type, transmitting the default alarm configuration file determined based on the particular type to the DCN via a network of the process automation system; after transmitting the default alarm configuration file of the particular type to the DCN; via said network and from said DCN; Function block identifiers of the function blocks performed by the DCN; An updated alarm settings file, which is an edited version of the previously transmitted default alarm settings file; and receiving an alarm setting update including: storing the updated alarm setting file and an association between the updated alarm setting file and the functional block identifiers in an alarm database; storing the updated alarm setting file and the association between the updated alarm setting file and the function block identifier in the alarm database; receiving an alarm setting request transmitted by an additional DCN of the process automation system over the network, the alarm setting request comprising: including said function block identifiers; In response to receiving the alarm setting request, obtaining the updated alarm setting file from the alarm database 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 configuration file to the additional DCN via the network of the process automation system; transmitting the updated alarm configuration file, whereby the additional DCN implements alarm monitoring in accordance with the updated alarm configuration file; Equipped with The method, wherein the default alarm configuration file is locally editable via the DCN and, once edited, is used by the DCN in implementing alarm monitoring based on the function blocks.

2. The method of claim 1, wherein the additional DCN is a newly commissioned DCN that replaces the DCN in the process automation system.

3. 2. The method of claim 1, wherein the additional DCN is a previously activated DCN that is performing the function block at the time of the alarm setting request, and the DCN ceases to perform the function block at the time of the alarm setting request.

4. determining that the DCN is performing the function block of the particular type, receiving, via the network, an alarm setting request transmitted by the DCN, the alarm setting request including a functional block identifier of the functional block; determining that the DCN is implementing the function block of the particular type based on the function block identifier included in the alarm configuration request; The method of claim 1 , comprising:

5. determining that the DCN is implementing the function block of the particular type based on the function block identifier included in the alarm configuration request; The method of claim 4 comprising determining the particular type based on the function block identifier including one or more characters that map to the particular type.

6. In response to receiving the alarm setting request, determining whether there is a particular alarm configuration file stored in association with the functional block identifier in an alarm database; 5. The method of claim 4, wherein the step of transmitting the default alarm settings file to the DCN is further responsive to a determination that there is no particular alarm settings file stored in association with the functional block identifier.

7. 2. The method of claim 1, wherein the default alarm configuration 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 no value.

8. identifying the function blocks performed by the DCN; 8. The method of claim 7, wherein determining the default alarm settings file comprises modifying a generic alarm settings file of the particular type to include one or more process variables of the function blocks performed by the DCN.

9. 1. 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 interfaces directly with the DCN; determining, based on the user interface input, one or more updates to default alarm configuration files stored locally in the DCN and associated with function blocks performed by the DCN; generating an updated alarm settings file based on the default alarm settings file and the one or more determined updates; implementing alarm monitoring based on the updated alarm configuration file and the function blocks; transmitting an alarm configuration update over a network of the process automation system, the alarm configuration update including the updated alarm configuration file and function block identifiers for the function blocks; transmitting the alarm setting update causes the updated alarm setting file to be stored in an alarm database in association with the function block identifier; Following the step of transmitting the alarm configuration updates, the updated alarm configuration files are stored in the alarm database in association with the functional block identifiers, by an additional DCN: Transmitting an alarm setting request over the network, the alarm setting request including the functional block identifier; receiving, in response to the transmission of the alarm setting request and via the network, the updated alarm setting file obtained 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; method.

10. determining the one or more updates to the default alarm settings file based on the user interface input, 10. The method of claim 9, comprising determining specific values ​​for the one or more updates based on the user interface input, the specific values ​​being related to conditions in the default alarm settings file.

11. The method of claim 10 , wherein the default alarm settings file is missing a value for the condition, and the updated alarm settings file includes the specific value for the condition.

12. The method of claim 10 , wherein the default alarm settings file includes default values ​​for the conditions, and the updated alarm settings file includes the specific values ​​for the conditions.

13. prior to receiving the user interface input via the HMI; transmitting, via the network, an alarm setting request including the functional block identifier; receiving, in response to transmitting the alarm configuration request and over the network, the default alarm configuration file; The method of claim 9, further comprising:

14. detecting the occurrence of one or more alarm conditions; The method of claim 13 , wherein transmitting the alarm setting request is in response to detecting the occurrence of the one or more alarm setting conditions.

15. Detecting the occurrence of the one or more alarm conditions comprises: detecting power-on of the DCN; Detecting that the DCN has been newly activated in the process automation system; and / or detecting, by the DCN of the function block, that alarm monitoring is not currently active; The method of claim 14 comprising:

16. 10. The method of claim 9, wherein the function block identifier is unique to the function block and is not assigned to any other function block in the process automation system.

17. A process automation system comprising: one or more network interfaces communicatively coupled to a network of the process automation system; an alarm database including a plurality of function block specific alarm configuration files and a corresponding association for each of the function block specific alarm configuration files to a corresponding function block identifier; one or more alarm setting processors, receiving, via the network, a request to set an alarm transmitted by a node of the process automation system, the request including a function block identifier for the function block; the alarm setting request includes the function block identifier based on the function block that is assigned for use in alarm monitoring by the node; and determining whether the corresponding association in the alarm database includes an association to the function block identifier based on receiving the alarm setting request; in response to determining that the corresponding associations in the alarm database include an association to the function block identifier, transmitting an alarm setting file specific to the associated function block among the alarm setting files specific to the function block to the node in response to the alarm setting request; in response to determining that the corresponding associations in the alarm database do not include an association to the function block identifier, determining a default alarm configuration file based on a particular type of function block identified by the function block identifier; transmitting, via the network, the default alarm configuration file determined based on the particular type to the node; the default alarm configuration file is locally editable via the node and, once edited, is used by the node in implementing alarm monitoring based on the function blocks; one or more alarm configuration processors that execute stored instructions to 1. A process automation system comprising an alarm configuration server comprising:

18. 20. The process automation system of claim 17, further comprising the node, the node being a distributed control node (DCN) that performs the function blocks.

Images