System and method for providing visualization of safety events over time in a process control system - Patents.com

Abstract

A system and method for visualizing safety events within a process plant is provided. [Solution] The system and method include accessing a cause and effect matrix (CEM) having a set of causes and a set of effects, where each of the set of causes represents a condition within the process plant, each of the set of effects represents an outcome to be taken within the process plant, and the set of causes and set of effects represent a set of monitored safety events within the process plant.

Description

[Technical field]

[0001] Related Applications This patent application is a regular patent application claiming priority to and benefit of the filing date of U.S. Provisional Patent Application No. 62 / 239,657, entitled “A System and Method for Configuring Separated Monitor and Effect Blocks of a Process Control System,” filed October 9, 2015, and is expressly incorporated herein by reference.

[0002] The present disclosure relates generally to managing process control systems in a process plant, and more specifically to configuring a cause and effect matrix (CEM) associated with a process control system and creating monitor and consequence blocks associated with the CEM. [Background technology]

[0003] A process control system, such as those used in chemical, petroleum, or other processes, typically includes one or more process controllers communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital, or analog / digital buses or lines. The field devices, which may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, and flow sensors), perform functions within a process plant, such as opening and closing valves and measuring process parameters. The process controller receives signals indicative of process measurements and / or other information made by the field devices, uses this information to implement control routines, and then generates control signals that are sent over a bus or lines to the field devices to control the operation of the process. Information from the field devices and controllers is typically made available to one or more applications executed by the operator workstation, allowing an operator to perform any desired function with respect to the process, such as configuring the process, viewing the current state of the process, modifying the operation of the process, etc.

[0004] In addition, in many processes, separate safety systems are provided to detect critical safety-related issues within the process plant and automatically close valves, shut off power from devices, switch flows within the plant, etc., when a problem occurs that may cause or lead to serious danger within the plant, such as a toxic chemical leak, an explosion, etc. These safety systems typically have one or more separate controllers, called logic solvers, separate from the standard process control controllers, that are connected to safety field devices via separate buses or communication lines installed within the process control plant. The logic solvers use the safety field devices to detect process conditions associated with critical events, such as the position of a particular safety switch or shutoff valve, an overflow or underflow in the process, the operation of a critical power generation or control device, the operation of a fault detection device, etc., thereby detecting "events" within the process plant. Upon detection of an event (typically referred to as a "cause"), which may be a single condition or the simultaneous occurrence of two or more conditions, the safety controller takes some action (typically referred to as an "effect") to limit the harmful nature of the event, such as closing a valve, turning off a device, shutting off power from a section of the plant, etc. general Typically, these actions or consequences include tripping or switching safety devices into a "safe" operating mode designed to prevent serious or hazardous conditions within the process plant.

[0005] Process plant operators, such as managers and engineers, typically maintain a database structure that stores related cause-effect relationships. For example, the matrix may have multiple rows and columns, where each row corresponds to a cause, each column corresponds to an effect, and each cell of the matrix corresponds to a particular cause-effect relationship. The cells may be populated by various triggers that indicate the respective cause and effect relationships. A so-called Cause-Effect Matrix (CEM) is typically constructed according to a requirement document that defines the safety design of a control system or a plant. A control engineer may utilize the CEM to engineer the control system such that the safety design is implemented accordingly. However, such CEMs are limited by the defined size of the matrix and are often not large enough to handle all desired cause / effect data relationships. Moreover, such CEMs cannot handle more complex / elaborate cause / effect relationships such as chaining, linking, leveling, looping, etc. Furthermore, a large CEM is cumbersome to implement into the control logic and is therefore prone to errors during implementation. Maintaining an accurate CEM is essential in any safety system because errors in the CEM can be serious, as failure of the safety system to operate properly could lead to serious injury or even death to plant personnel, and potentially millions of dollars of damage to equipment and materials within the plant. Summary of the Invention

[0006] A process control system of a process plant may have a safety system that may be implemented or designed to achieve a control logic defined in a cause-effect matrix (CEM), which is an overview of safety actions for the process plant displayed in a visual representation. Generally speaking, a CEM defines the basic cause-effect relationships of various safety protocols or procedures within the process plant. In general, a CEM may include a set of inputs and a set of outputs, where each of the set of inputs represents a condition within the process plant and each of the set of outputs represents an outcome or action to be taken within the process plant. Furthermore, at least some of the set of inputs and the set of outputs are related as cause-effect pairs, whereby an activity of a corresponding outcome is responsive to the occurrence of a corresponding condition or cause.

[0007] A process control system administrator may implement the CEM as a set of various function blocks. However, depending on the size and / or complexity of the process plant, a given CEM may include a large number of causes, effects, and cause-effect pairs, and thus may require implementing a corresponding large number of function blocks. This implementation may therefore be time consuming, complex, and tedious, leading to potential implementation errors. In accordance with the described systems and methods, various techniques are provided for implementing the CEM within a process control system as a set of separate but interconnected function blocks, which are described as implementing the CEM logic as monitor and effect function blocks.

[0008] In one embodiment, the system and method can identify patterns and groupings within a CEM and can implement a set of monitor blocks and a set of result blocks according to the identified patterns and groupings, thus reducing the complexity of the implementation of the CEM. In one implementation, a grouping of data within a CEM (e.g., a column of the CEM) is defined as a numerical representation of the logic defined by that portion of the CEM, providing a simpler and less complex manner of understanding and verifying that the CEM logic is implemented within the functional blocks (e.g., monitor and result blocks) used to implement the CEM logic. Still further, tools can be used to analyze and reorder or rearrange the CEM (e.g., the rows and / or columns of the CEM) to provide better, more logical, easier to implement, etc., groupings of the CEM logic that are implemented as one or more cause and effect blocks.

[0009] The present disclosure provides additional techniques for managing a CEM. In particular, the systems and methods described herein can be used to configure a CEM to include interactive features. For example, a configured CEM can include links or selections to access one or more documents detailing the safety protocols that make up the cause and effect relationships of the CEM, graphs representing the current and / or past states of one or more results of the CEM to allow a user to more easily understand previous conditions or actions related to a particular result when implemented in a plant, and diagrams of a process plant including devices related to the cause and effect of the CEM.

[0010] In addition, due to the often large amount of information contained in the CEM, engineers may have difficulty identifying any inconsistencies or errors contained in the process control system. The systems and methods provided herein further enable implementation of reverse engineering techniques and systems to automatically create a test CEM that defines the CEM logic actually implemented by the devices and the control logic of the process plant (or in some implementations, the monitoring and results blocks in the process control system), as well as the necessary safety protocols for a particular process plant. Thus, the systems and methods described herein can compare the test CEM with an existing CEM to identify any inconsistencies or errors between the actual configuration of the plant operation and the configuration that may be detailed in the design documents.

[0011] The figures described below depict various aspects of the disclosed systems and methods therein. It should be understood that each figure depicts one embodiment of a particular aspect of the disclosed systems and methods, and that each of the figures is intended to correspond to a possible embodiment thereof. Moreover, wherever possible, the following description will refer to reference numerals contained in the following figures, and features depicted in multiple figures will be designated with consistent reference numerals.

[0012] Although the drawings show the currently discussed arrangements, it being understood that the present embodiments are not limited to the precise arrangements and instrumentalities shown. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 is a block diagram of an exemplary process plant. [Diagram 2] FIG. 2 is a block diagram of an exemplary workstation as generally illustrated in FIG. 1. [Diagram 3] FIG. 1 is an illustration of an exemplary cause-effect matrix. [Figure 4] FIG. 2 is an illustration of an exemplary set of monitor and result blocks. [Diagram 5]FIG. 2 is an illustration of a first example set of functional blocks that can be used to implement a monitor and results block. [Figure 6] FIG. 2 is an illustration of a second example set of functional blocks that can be used to implement the monitor and results block. [Figure 7] FIG. 1 is a flow diagram of an example method for configuring monitor and result blocks associated with a process plant. [Figure 8] FIG. 11 is an explanatory diagram of a second example of a cause-effect matrix. [Figure 9] FIG. 9 is an illustration of a second example of the cause-effect matrix of FIG. 8 reorganized and structured into separate logical blocks. [Figure 10] FIG. 1 is a flow diagram of an exemplary method for reorganizing a cause-effect matrix. [Figure 11] FIG. 13 is an illustration of a second example of a cause-effect matrix with exemplary numerical representations. [Figure 12] FIG. 1 is a flow diagram of an exemplary method for calculating a numerical representation of a cause-effect matrix logic. [Figure 13] FIG. 13 is an example illustration of various interlinked user interfaces corresponding to the safety logic of the cause and effect matrix. [Figure 14] 14 is a flowchart of an exemplary method for navigating among the interlinked user interfaces of FIG. 13. [Figure 15] 1 is a flowchart of an exemplary method for reverse engineering a test cause-effect matrix. [Figure 16A] FIG. 2 is an illustration of an example user interface displaying monitored safety events. [Figure 16B] FIG. 2 is an illustration of an example user interface displaying monitored safety events. [Figure 16C] FIG. 2 is an illustration of an example user interface displaying monitored safety events. [Figure 16D]FIG. 2 is an illustration of an example user interface displaying monitored safety events. [Figure 17] 1 is a flow chart of an example method for displaying monitored safety events. [Figure 18] FIG. 13 is an illustration of an example cause and effect matrix including tolerances and time delay triggers.

[0014] The drawings depict preferred embodiments for illustrative purposes only, and those skilled in the art will readily recognize from the following discussion that alternative embodiments of the systems and methods illustrated herein may be used without departing from the inventive principles described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Figure 1 is a block diagram of an example process plant 10 that includes one or more nodes 12, 16, 18, and 20. In the example process plant 10 of Figure 1, each of the nodes 12 and 16 includes a process controller 12a, 16a connected to one or more field devices 22 and 23 via an input / output (I / O) device 24, which may be, for example, a Foundation Fieldbus interface, a HART interface, etc. The controllers 12a and 16a are also coupled to one or more host or operator workstations 18a and 20a of the nodes 18 and 20 via a network 30, which may comprise, for example, one or more buses, a wired LAN such as an Ethernet local area network (LAN), a wireless LAN, a wide area network (WAN), the Internet, etc. The controller nodes 12, 16 and their associated I / O devices 24 and field devices 22, 23 are typically located downstream in and distributed throughout a sometimes harsh plant environment, while the operator workstation nodes 18 and 20 are usually located within a control room or other less harsh environment where they can be easily evaluated by controller personnel.

[0016] Generally speaking, the workstations 18a and 20a of the nodes 18 and 20 may be used to store and execute applications used to configure and monitor the process plant 10 and / or manage the devices 22, 23, 24 and controllers 12a, 16a of the process plant 10. For example, the workstations 18a and / or 20a may store and execute applications such as a system navigator application 15, a cause and effect analyzer tool 17, a process control configuration application 19, and a safety configuration application 21 that may be implemented to manage safety requirements for the process plant 10. The system navigator application 15 may be implemented to provide an interlinked group of user interfaces that provide information regarding the safety requirements and devices of the process plant. A cause and effect analyzer tool may be implemented to manage a cause and effect matrix (CEM) and / or create a cause and effect matrix by reverse engineering from known safety requirements and / or function blocks. Additionally, the process control configuration application 19 and the safety configuration application 21 provide a user with the ability to manage the process plant's devices through the workstations 18a and / or 20a. A configuration database 32 may be connected to the network 30 and may act as a data historian and / or configuration database that stores the current configuration of the process plant 10 as it is downloaded to and / or stored within the nodes 12, 16, 18, 20. The configuration database may also include rules 31 and / or numerical representations 33 for re-deploying the CEM.

[0017] Each of the controllers 12a and 16a, which may be, as an example, a DeltaV™ controller sold by Emerson Process Management, may store and execute a controller application that implements a control strategy using several different, independently executing control modules or blocks. The control modules may each be comprised of what are generally referred to as function blocks, each of which is a portion or subroutine of an overall control routine and operates in conjunction with other function blocks (through communications called links) to implement a process control loop within the process plant 10. As is well known, a function block typically performs one of an input function (such as associated with a transmitter, sensor, or other process parameter measurement device), a control function (such as associated with a control routine that controls PID, fuzzy logic, etc.), or an output function that controls the operation of some device (such as a valve) to perform some physical function within the process plant 10. Of course, hybrid and other types of function blocks exist and may be utilized. The Fieldbus and DeltaV™ System protocols may use control modules and function blocks designed and implemented in an object oriented programming protocol, although the control modules may be designed using any desired control programming scheme, such as sequential function blocks, ladder logic, etc., and are not limited to being designed using function blocks or any other particular programming technique. As is typical, the configuration of the control modules as stored within the process control nodes 12 and 16 may be stored in a configuration database 32 that is accessible to applications executed by the workstations 18a and 20a.The function blocks may be stored in and executed by, for example, the controllers 12a, 16a, which is typically the case when these function blocks are used with or associated with certain types of smart field devices, such as standard 4-20 mA devices and HART devices, or the function blocks may be stored in and implemented by the field device itself, which may be the case for Fieldbus devices.

[0018] In the system illustrated in FIG. 1, the field devices 22 and 23 coupled to the controllers 12a and 16a can be standard 4-20 mA devices or can be smart field devices, such as HART, Profibus, or Foundation Fieldbus field devices, that include a processor and memory. Some of these devices, such as the Foundation Fieldbus field devices (labeled 23 in FIG. 1), can store and execute modules or sub-modules, such as function blocks, that are associated with the control strategies implemented in the controllers 12a and 16a. Of course, the field devices 22, 23 can be any type of device, such as a sensor, valve, transmitter, positioner, etc., and I / O device 24 can be any type of I / O device conforming to any desired communication or controller protocol, such as HART, Foundation Fieldbus, Profibus, etc.

[0019] The controllers 12a and 16a each include a processor that implements or oversees one or more process control routines stored in memory, which may include control loops stored therein or otherwise associated therewith. The controllers 12a and 16a communicate with field devices 22, 23, workstations 18a, 20a, and a database 32 to control the process in any desired manner. The controllers 12a and 16a each may be configured to implement a control strategy or control routine in any desired manner.

[0020] The process plant 10 may also include a safety system 14 (shown in dashed lines) that is integrated with the process control nodes 12 and 16. The safety system 14 may generally operate as a safety instrumented system (SIS) to monitor and override controls provided by the process control nodes 12 and 16 to maximize proper safe operation of the process plant 10.

[0021] Each of the nodes 12 and 16 may include one or more safety system logic solvers 50. Each of the logic solvers 50 is an I / O device having a processor and memory and configured to execute safety logic modules stored in the memory. Each logic solver 50 is communicatively coupled to provide control signals to and / or receive signals from safety system field devices 60 and 62. Additionally, each of the nodes 12 and 16 may include at least one message passing device (MPD) 70 that is communicatively coupled to other MPDs 70 via ring or bus connections 74 (only some of which are illustrated in FIG. 1). The safety system logic solvers 50, the safety system field devices 60 and 62, the MPDs 70, and the bus 74 generally comprise the safety system 14 of FIG. 1.

[0022] The logic solver 50 of FIG. 1 may be any desired type of safety system control device including a processor and a memory that stores safety logic modules adapted to execute on the processor to provide control functions associated with the safety system 14 using the field devices 60 and 62. Of course, the safety field devices 60 and 62 may be any desired type of field device that conforms to or uses any known or desired communication protocol, such as those mentioned above. In particular, the field devices 60 and 62 may be safety-related field devices of the type that are traditionally controlled by separate, dedicated safety-related control systems. In the process plant 10 illustrated in FIG. 1, the safety field device 60 is represented as using a dedicated or point-to-point communication protocol, such as a HART or 4-20 mA protocol, while the safety field device 62 is represented as using a bus communication protocol, such as a Fieldbus protocol. The safety field device 60 may perform any desired function, such as the functions of a shutoff valve, shutoff switch, etc. However, the safety system field devices 60 and 62 may be other types of devices and may use other types of communication protocols to communicate with the logic solver 50, including any desired wired or wireless communication protocol.

[0023] A common backplane (not shown) is used in each of the nodes 12 and 16 to connect the controllers 12a and 16a to the process control I / O cards 24, the safety logic solver 50, and the , and MPD 70. Controllers 12a and 16a are also communicatively coupled to network 30. Controllers 12a and 16a, I / O devices 24, logic solver 50, and MPD 70 may communicate with nodes 18 and 20 via network 30.

[0024] As will be appreciated by those skilled in the art, the backplane (not shown) of the nodes 12, 16 allows the logic solvers 50 to communicate with each other locally to coordinate the safety functions implemented by these devices, communicate data with each other, and / or perform other integration functions. Similarly, the backplane (not shown) of the nodes 16 allows the logic solvers 50 to communicate with each other locally to coordinate the safety functions implemented by these devices, communicate data with each other, and / or perform other integration functions. Meanwhile, the MPD 70 allows portions of the safety system 14 located in very different locations of the process plant 10 to still communicate with each other to provide coordinated safety operations at different nodes of the process plant 10. In particular, the MPD 70 in conjunction with the bus 74 allows the logic solvers 50 associated with different nodes 12 and 16 of the process plant 10 to be communicatively cascaded together to cascade safety-related functions within the process plant 10 according to specified priorities. The MPD 70 and bus 74 provide an alternative communication link to the safety system to the network 30.

[0025] Alternatively, two or more safety-related functions in different locations within the process plant 10 can be interlocked or interconnected without the need to run dedicated lines to individual safety field devices in separate areas or nodes of the plant 10 through the use of the MPD 70 and communication lines 74. In other words, the use of the MPD 70 and bus 74 allows a safety engineer to design and configure a safety system 14 that is virtually distributed throughout the process plant 10, but has different components of safety-related hardware communicatively interconnected to allow the hardware to communicate with each other as needed. This feature also provides scalability of the safety system 14 in that it allows additional safety logic solvers to be added to the safety system 14 as they are needed or as new process control nodes are added to the process plant 10. It will be appreciated that the logic solver 50 typically includes control logic that implements safety logic defined by one or more cause-effect matrices (CEMs).

[0026] FIG. 2 is a block diagram that generally illustrates the structure of an exemplary workstation 18a (workstation 20a can comprise the same or similar devices). Workstation 18a can include at least one processor 100, a volatile memory 104, and a non-volatile memory 108. Volatile memory 104 can include, for example, random access memory (RAM). In some embodiments, RAM can be backed up by one or more batteries so that data is not lost in the event of a power outage. Non-volatile memory 108 can include, for example, one or more of a hard disk, a read-only memory (ROM), a compact disk ROM (CD-ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a digital versatile disk (DVD), flash memory, and the like. Workstation 18a can also include workstation I / O devices 112. Processor 100, volatile memory 104, non-volatile memory 108, and workstation I / O devices 112 can be interconnected via an address / data bus 116. The workstation 18a may also include at least one display device 120 and at least one user input device 124, such as, for example, a keyboard, keypad, mouse, etc. , a trackball, a touch screen, a light pen, etc. In some embodiments, one or more of the volatile memory 104, the non-volatile memory 108, and the workstation I / O devices 112 may be coupled to the processor 100 via a separate bus from an address / data bus 116 (not shown) or may be coupled directly to the processor 100.

[0027] The display device 120 and the user input device 124 are coupled to the workstation I / O devices 112. Additionally, the workstation 18a is coupled to the network 30 via the workstation I / O devices 112. Although the workstation I / O devices 112 are illustrated as one device in FIG. 2, they may comprise multiple devices. Additionally, in some embodiments, one or more of the display device 120 and the user input devices 124 may be coupled to the address / data bus 116 or directly to the processor 100.

[0028] 1 and 2, a process control configuration application 19 associated with one or more of the control nodes 12 and 16 may be stored in and executed by one or more workstations 18a and 20a. For example, the process control configuration application 19 may be stored in the non-volatile memory 108 and / or the volatile memory 104 and executed by the processor 100. However, if desired, the application may be stored in and executed by other computers associated with the process plant 10. Generally speaking, the process control configuration application 19 enables a programmer, control engineer, or other personnel to create and configure control routines, control modules, function blocks, programs, logic, etc., implemented by the controllers 12a, 16a, I / O devices 24, and / or field devices 22, 23. These control routines, control modules, function blocks, programs, logic, etc. may then be downloaded over the network 30 to the appropriate ones of the controllers 12a, 16a, I / O devices 24, and / or field devices 22, 23.

[0029] Similarly, a safety system configuration application 21 associated with the safety system 14 may be stored on and executed by one or more of the workstations 18a and 20a. For example, the safety system configuration application 21 may be stored in the non-volatile memory 108 and / or the volatile memory 104 and executed by the processor 100. However, if desired, the application may be stored on and executed by other computers associated with the process plant 10. Generally speaking, the safety system configuration application enables a programmer, safety engineer, or other personnel to create and configure safety-related control routines, safety logic modules, function blocks, programs, logic, etc., implemented by the logic solver 50 and / or devices 60, 62. These control routines, safety modules, function blocks, programs, logic, etc., may then be downloaded over the network 30 to the appropriate ones of the controllers 12a, 16a, the logic solver 50, and / or the field devices 60, 62.

[0030] Safety systems are typically programmed in one of several languages ​​defined by the International Electrotechnical Commission (IEC) 61131-3 standard, and in some cases the safety logic may consist of a series of interconnected function blocks or other routines. Regardless of the programming language, the starting point is usually an annotation document that specifies the control and / or safety action requirements. In a safety system, the safety requirements are documented in a Safety Requirements Specification (SRS). The SRS, described in more detail below, may be written either in plain text, a logic diagram, or a fishbone diagram (also called a cause and effect matrix). It provides a logical description that can be represented in a simple visual representation. A Cause-Effect Matrix (CEM) is an overview of the safety actions provided by a safety system in a simple visual representation. The CEM thus defines the basic cause-effect relationships implemented by the safety logic and is also the basis for structuring the safety logic.

[0031] 3 illustrates one exemplary representation of a CEM 300, which may be displayed via any type of display device. In particular, the display device may be part of a user interface associated with the safety configuration application 21, and the display may be presented to a programmer or administrator, for example, via the display device 120 of the workstation 18a. The exemplary CEM 300, which is a CEM that may be utilized in a conventional process control system, includes multiple causes and multiple effects. The causes of the CEM are generally defined by the safety requirements specification and relate to conditions indicated, measured, or detected by or in the logic solver 50, field devices 22, 23, 60, and 62, etc., throughout the process plant 10. Different causes C1, C2, etc., defined in the CEM 300 are associated with each row of the CEM 300. For example, one cause may be a sensor reading, where the temperature of a particular area of ​​the plant is outside a safe or predefined range.

[0032] When a condition corresponding to a cause occurs, a result can be triggered, and the result can be an action to be taken in the plant. Different results E1, E2, etc. of CEM 300 are defined for and associated with each column of CEM 300. For example, one result (e.g., E3) of CEM 300 can be associated with a safety action to be taken in the plant, such as closing a valve, sounding an alarm, etc. When a particular cause (e.g., C2 or C6) triggers a particular result (E3), a corresponding cause-effect pair or relationship exists.

[0033] In CEM 300, cause-effect relationships are indicated in each cell with an "X," indicating that the cause associated with the cell's row triggers the effect associated with the cell's column. These relationships may be referred to herein as cause-effect pairs. In alternative implementations, cells may be populated with various "triggers" that more precisely indicate how the associated cause-effects may be related. For example, triggers may be in the form of an "X" indicating that the effect is activated immediately upon receipt of the cause, a "T" indicating that the effect is activated with a time delay upon receipt of the cause, a "P" indicating that the effect is permitted upon receipt of the cause, etc. Additionally, blank cells may indicate that a particular cause / effect pair is not currently related in the matrix and therefore cannot be activated in the plant (i.e., the occurrence of the cause has no triggering relationship with any effect).

[0034] The exemplary CEM 300 is a 7×7 matrix, which may be smaller than a typical cause-effect matrix for a process plant, but is shown in a simplified form for illustrative purposes. The exemplary CEM 300 includes 10 cause / effect relationships, indicated with an “X” in each of a set of corresponding cells. For example, Cause 2 (C2) includes an “X” in each cell that corresponds to Effects 3, 4, and 5 (E3, E4, and E5), respectively. Thus, if the associated event of Cause 2 (C2) occurs, then the actions of each of Effects 3, 4, and 5 (E3, E4, and E5) can be triggered within the process plant by the plant's safety logic module. However, in some embodiments, each of Effects 3, 4, and 5 may also require the other associated cause to occur before being triggered. For example, depending on the logic used in the system, outcome 4 may require one or more of causes 2, 3, 4, and / or 5 to be activated before outcome 4 can be triggered (i.e., because outcome 4 has an "X" for each of causes 2, 3, 4, and 5). Thus, the logic defined by the CEM can be based on "OR" logic (i.e., the occurrence of any one cause in the outcome string results in the initiation of the outcome) or it can be based on "AND" logic (i.e., every cause must be present in the outcome string before the outcome is triggered by the safety logic).

[0035] In another embodiment, the outcome (e.g., outcome 4) can be triggered in different manners depending on which cause occurs. For example, if one associated cause occurs, the outcome (e.g., outcome 4) can be triggered with a delay, while if two or more associated causes occur, the outcome (e.g., outcome 4) can be triggered immediately. Furthermore, some associated causes can activate an automatic trigger, while other causes can activate a delayed trigger of the outcome, such as outcome 4. Still further, some associated causes can trigger an outcome independently of other associated causes, while other associated causes can trigger an outcome only when they are present in combination with one or more other causes. The examples provided are not intended to be limiting, and any combination of logic and / or delays can be implemented with corresponding cause-effect pairs.

[0036] As will be discussed in more detail, the logic defined by the CEM can be divided into multiple sets or groups of logic implemented for subsets of the cause-effects defined by the CEM, and different subsets of these logics can be implemented by specific functional blocks of the safety logic implementation. For example, functional blocks can be used to implement the logic defined by selected logic blocks 305 and 310 illustrated in CEM 300. In this case, logic block 305 includes two cause inputs (C2 and C3) and corresponds to three effect outputs (E3, E4, and E5). In this exemplary embodiment, the subsets of logic implemented by logic blocks 305 and 310 are identified simply by recognizing clusters of populated cells of CEM 300. Here, logic blocks 305 and 310 contain most of the important information (cause / effect relationships) shown by CEM 300 while covering only 12 of the 49 cells of CEM 300. In other embodiments, logic blocks 305 and 310 may be made larger and / or additional logic blocks may be added or identified to include the remaining populated cells of CEM 300 that are not included in logic blocks 305 and 310. As discussed in more detail below, the CEM rearranges the populated cells to cluster in a better or more efficient manner, thereby assisting in identifying the logic blocks, which in turn create functional blocks. While this clustering may seem like a trivial task for a given CEM 300, it may be nearly impossible for a human to efficiently identify patterns in a CEM with hundreds (or thousands) of cells.

[0037] In conventional systems, CEMs are represented by state machine function blocks, where causes are inputs and results are outputs. Typically, a state machine function block is created for each result of a CEM. As a result, state machine function blocks are not limited in use by their defined size and can therefore proliferate extensively. However, unlike conventional systems, the present system organizes CEMs into two types of function blocks, namely, supervisory blocks and result blocks, which serve to reduce logic complexity and also increase optimization of logic implementation within a safety system when implementing complex or large CEMs.

[0038] More specifically, the shortcomings of conventional systems are addressed by separating cause from effect into two different categories of blocks, using separate monitor and result blocks to implement any pattern or group of logic defined in the corresponding CEM. In general, a monitoring block (MB) is an abstract representation of a cause, and an effect block (EB) is an abstract representation of an effect. Thus, a system can represent a large CEM and its causes and effects by one or more monitoring blocks linked or connected to one or more effect blocks. For example, the output of a set of monitoring blocks can serve as input to one or more effect blocks, and thus the input of each effect block can occur as an output from one or more monitoring blocks. In one embodiment, the output of a monitoring block can alternatively or additionally serve as an input to one or more other monitoring blocks. As a result, the monitoring blocks and / or effect blocks can be chained, nested, hierarchical, and / or leveled as desired to optimally implement any desired CEM logic. Furthermore, representing (and implementing) a CEM as multiple MBs and EBs allows for easier implementation and maintenance of a safety system, and also allows for more complex CEM relationships to be easily represented and configured.

[0039] There are many advantages to creating separate monitor and result blocks. In particular, the MBs and EBs can be sized as desired, which leads to faster and easier implementation that is less prone to errors. Also, control or safety systems that use these smaller sized MBs and EBs as function blocks to implement CEM logic can be more easily tested and troubleshooted (or generally reverse engineered) because cause relationships are transparently represented. Furthermore, large CEMs can be broken down into more manageably sized logic blocks. Furthermore, complex cause and effect relationships are more easily represented by using separate MBs and EBs. For example, hierarchical, looping, nesting, chaining, etc. can all be represented using separate monitor and result blocks.

[0040] FIG. 4 is a schematic diagram 400 of a set of interconnected monitor and result blocks. The set of monitor and result blocks of FIG. 4 includes (implements) all of the information or logic provided or defined for CEM 300 of FIG. 3. Here, monitor blocks 405 and 410 generally correspond to the causes (C2-C5) of logic blocks 305 and 310, while result blocks 415 and 420 generally correspond to the results (E3, E4, E5, E6) of or associated with logic blocks 305 and 310. For example, monitor block 1 (MB1) 405 includes cause 2 and cause 3 of CEM 300 as inputs. However, the output of MB1 405 does not directly correspond to results 3, 4, and 5 of CEM 300 (as does logic block 305). In contrast to state machines created to implement the logic of logic blocks 305 and 310, which typically implement a direct cause-and-effect relationship, a monitor block may contain inputs (such as causes and outputs from other monitor blocks) and outputs (which may be sent to other monitor blocks or result blocks), but do not directly correspond to results. For example, the output of MB1 405 is sent to various other monitor and result blocks in set 400. Specifically, the output 401 of monitor block MB1 (405) is sent to result block 1 (EB1) 415, the output 402 of monitor block MB1 is sent to monitor block 2 (MB2) 410, and the output 403 of monitor block MB1 is sent to result block 2 (EB2) 420.

[0041] The outputs of a MB generally provide information about its corresponding input. For example, output 401 provides information about cause 2 (the "X" in the corresponding cell of MB1 405 indicates this relationship). Similarly, output 402 provides information about cause 2 and / or cause 3. For example, output 402 may be high (logic 1) if either cause C2 or C3 is present (e.g., logically true), or output 402 may be high only when causes C2 and C3 are both present. Of course, other logical operations can be performed on causes C2 and C3 to determine output 402, such as dedicated ORing. In a similar manner, output 411 of MB2 410 provides information about the three inputs (output 402 of MB1 405, cause 3, output 402 of MB1 405, cause 4, and output 402 of MB2 410). In other words, output 411 provides information about causes 2 and 3, as well as causes 4 and 5 (as defined by the logic that generated output 402 of cause block MB1).

[0042] Referring now to result blocks 415 and 420, result block 1 (EB1) 415 receives two inputs: output 401 from monitor block MB1 (which depends on the state of cause 2), and cause 6 (which corresponds to cause 6 from CEM 300). Result block EB1 (415) only corresponds to one result: result 3. Thus, like CEM 300, result block EB1 (415) correlates causes 2 and 6 to produce result 3, which is the output of result block EB1 (415). As will be appreciated, result block EB1 (415) can implement any desired logic and delay based on the state of output 401 (again related to the state of cause 2) and the state of cause 6 (C6).

[0043] Similarly, result block EB2 (420) corresponds to and implements the logic that creates or defines the states of results 4, 5, and 6 of CEM 300. By tracing the inputs of result block EB2 (420) back to the corresponding monitoring blocks, it can be seen that the cause-effect relationships of results 4, 5, and 6 of CEM 300 are achieved by result block EB2 (420). Specifically, result block EB2 420 receives output 411 that is based on causes 4 and 5 input to monitoring block MB2 and that is based on output 402 of monitoring block MB1. Thus, output 411 has a value or state that is derived from causes 2, 3, 4, and 5 that are used to trigger result 4 of result block EB2. Additionally, result block EB2 receives outputs 403 and 412 that are logically defined by causes 2 and 4 and that are used in some logical expressions to trigger result 5. Furthermore, the result block EB2 receives an output 413 that corresponds to or is defined as a logical value based on the causes 4 and 5, and uses the output 413 to trigger the result 6. The set of monitor and result blocks 400 of FIG. 4 then contains all of the relationship information (and logic) previously provided or defined for the CEM 300 of FIG. 3. The advantages provided by decomposing the CEM 300 into a set of monitor and result blocks 400 may not be clear in this example, but the advantages become more apparent when decomposing larger CEMs. It should be noted that the set of monitor and result blocks 400 depicted in FIG. 4 is meant to be merely an example, and that the monitor and result blocks can be created and configured in an infinite number of sizes and configurations to implement the logic defined by the CEM.

[0044] 5 is one example of an illustration of a configuration screen 500 that may be displayed by a display device and that represents or represents a set of monitor and result function blocks that implement the logic of the CEM or a portion of the CEM. The configuration screen 500 represents a more detailed implementation of the function blocks of the monitor and result blocks, as opposed to the set of monitor and result blocks 400, which are intended to generally represent the logic associated with the monitor and result blocks. In the example of FIG. 5, the configuration screen 500 includes inputs (cause 508, cause mask 512, and logic type 506), a monitor block 502 that corresponds to monitor block MB1 (405) of FIG. 4, and a result block 504 that corresponds to result block EB1 (415) of FIG. 4.

[0045] The monitor block 502 receives four inputs (IN_D1 and IN_D2, IN_MASK and LOGIC_TYPE) that correspond to two causes 508, a cause mask input 512, and a logic type 506, respectively. The logic type 506 defines what type of logic is implemented in the current set of monitor and result blocks. In one embodiment, the logic type can be positive or negative. Positive logic can indicate that all of the causes initially start out in a "false" state and become "true" if tripped. Thus, if one or more causes are "true", the corresponding output can be "true". Then, the corresponding A corresponding result block can receive one or more "true" inputs, which can elevate the state of the result block and / or trigger the result block. Negative logic can be similar, but the cause starts out "true" and is set to "false" if the cause occurs. The example logic is not intended to be limiting, and logic type 506 can also include "AND" logic, "OR" logic, or any other logic that may be useful in implementing monitor and result blocks.

[0046] The cause mask inputs 512 may represent initial parameters for filtering the causes 508 received by the monitor block 502. The monitor block 502 also includes three configuration masks CFG_MASK1, CFG_MASK2, and CFG_MASK3 510 used to configure the monitor block 502, each mask representing which cause corresponds to each output, and in some cases the logic used to generate the outputs from the unmasked inputs. The configuration masks 510 may be numerical expressions derived from the CEM, as described in more detail below.

[0047] The monitor block 502 also includes five outputs (OUT_D1-OUT_D3 514, RAW_VAL 516, and MASK_VAL 518), one of the outputs 514 (OUT_D1) serves as an input to the result block 504 (identified in the configuration of FIG. 4). The raw value 516 may simply output the received value of the cause 508, while the masked value 518 may output the value of the cause 508 after applying the cause mask 512. Furthermore, the OUT_D1-OUT_D3 correspond to the outputs 401-403 of the MB1 405 in FIG. 4. The configuration mask 510 indicates which cause corresponds to each output. For example, the CFG_MASK1 (in the configuration mask 510) may be set to "A", indicating that only cause 2 (in the causes 508) corresponds to the OUT_D1 (in the output 514). Additionally, CFG_MASK2 (of configuration mask 510) may be set to "B", indicating that Cause 2 and Cause 3 (of Cause 508) correspond to OUT_D2 (of output 514). Still further, in some instances, configuration mask 510 may be a numeric representation, such as a hexadecimal number, that represents which monitor block inputs drive or effect the output of a particular monitor block and / or represents the actual logic used to generate the block's output from the block's inputs.

[0048] As illustrated in FIG. 5, the result block 504 may include four inputs (IN_D1 and IN_D2 520, Reset 522, and LOGIC_TYPE 506) and two outputs (Status 526 and OUT_D 524). The inputs 520 of the result block 504 include the outputs 514 of the monitor block 502 as well as the causes 6 of the CEM 300 of FIG. 3. The state 526 of the result block 504 may correspond to the operational state of the device corresponding to the result block 504. In other words, if no corresponding "true" cause is received, the state 526 may be normal. However, if one or more causes are received, for example, set to a "true" value, the state may change to indicate a new state (e.g., "Warning", "Danger", "Triggered"). The reset input 522 may allow a user to automatically reset the state of the result block 504 to normal, at which point a necessary action is taken when the result block 504 is in a non-normal state. Of course, other state change inputs can be provided to the result block as well, such as a reset of a permission (e.g., in response to a change in state of a cause input or a monitor block input). Additionally, since in this embodiment logic type 506 is set to true, if one or more of the received inputs 520 are "true," output OUT_D, which in this case corresponds to result 3 of CEM 300, can be a triggered response.

[0049] As an example, FIG. 5 illustrates a case where the inputs for Cause 2 and Cause 3 are “false” and blocks 502 and 5 illustrates the state of each of OUT_D1 (of block 502), IN_D2 (of block 504), and Out_D when both Logic_Type and 504 are set to true. At this point, if cause 2 (of causes 508) occurs in the process plant, the state of cause 2 may change from "false" to "true". Thus, MB1 502 receives input IN_D1 as true. The corresponding output OUT_1 then also changes to true based on the positive logic type at the input of Logic_Type and the configuration mask of OUT_D1 (output 1), i.e., CFG_MASK1. In this example, after the configuration mask 510 is applied, IN_D1 drives or achieves the value of each of the outputs (OUT_D1-OUT_D3) 514. Specifically, OUT_D1 may be set to "true" based on IN_D1 being set to "true". Thus, EB1 504 then receives at least one "true" input (IN_D1). As a result, the state 526 of EB1 504 changes to "Triggered" and the output 524 OUT_D of the result block 504 is set to "True", meaning that result 3 in Figure 4 is triggered or "True". As a result, the result is triggered and any corresponding actions and / or alarms can be set off in the process control plant.

[0050] 6 is another example of an illustration of a configuration screen 600 that can be displayed by a display device and that can represent the configuration of the monitor and result blocks. The example of FIG. 6 focuses on the monitor block MB2 and result block EB2 from FIG. 4. For illustrative purposes, the logic type 606 is set to negative, which means that all causes are "true" when in a normal state. In the negative logic type, when one or more inputs occur and switch the state to "false", the corresponding output of the monitor block can be set to "false", which can trigger a result that receives a result block and then sets the result to "true".

[0051] Additionally, result block EB 604 includes a time delay input 608. In this example, input 1 (IN_D1) of result block 604 causes output OUT_D to be triggered with a delay (DELAY_TIME1) of 20 seconds when "20" is input into the Delay_Time1 input of result block 604. However, input 2 (IN_D2) in this example has a time delay (DELAY_TIME2) set to zero, causing the output (OUT_D) to be triggered immediately. This example is not intended to be limiting and any number of delays and delay times can be configured for a particular result block.

[0052] As an example, when cause 4 occurs, the state of cause 4 (and consequently, IN_D2) changes to "false". Referring back to FIG. 4, it can be seen that cause 4 corresponds to or achieves each of the outputs 411-413 of the monitor block 410. Thus, in this example, cause 4 (and IN_D2) can drive or achieve all of the outputs (OUT_D1-OUT_D3) of MB2 according to the logic implemented by the configuration masks of the monitor block 602. Specifically, OUT_D1 of MB2 602 can be set to "false". Then, IN_D2 of EB2 604 is received as "false". Thus, when the time delay (DELAY_TIME2) corresponding to IN_D2 of EB2 604 is set to a zero time delay, the corresponding result of EB2 604 can be instantly triggered. 4 corresponds to OUT_D1 of MB2 602, then only these outputs drive result 4 (of CEM 300), which can be represented as OUT_D1 in EB 604. Therefore, OUT_D1 of EB 604 can be triggered at this point and set to "true."

[0053] The example monitor and result blocks provided in Figures 5 and 6 are intended to be simple for demonstration purposes. For example, monitor block 502 has four inputs and five Although shown having an output of IN_Dx, other embodiments can include any desired number of required inputs and outputs based on the functionality of the monitor block. In one embodiment, the number of inputs IN_Dx and outputs OUT_Dx generally correspond to the number of inputs and outputs of each logic block of the reorganized CEM. Furthermore, the system can configure masks so that one monitor can be implemented to drive or effect multiple result blocks and additional monitor blocks. The CEM can then be separated into multiple monitor and result blocks that can be layered, looped, nested, chained, etc., which can provide the system with greater flexibility to configure the system of the process control plant than a traditional state machine implementation.

[0054] 7 is a flow diagram of an example method 700 for configuring monitoring and consequence blocks associated with a process plant. Method 700 may be implemented periodically and / or in response to a triggering event, such as a direction or initiation signal by a configuration engineer or other user or other safety logic designer. Method 700 may be performed by an electronic device (e.g., cause and effect analyzer tool 17), which may include one or more components of a process plant, such as the process plant 10 discussed with respect to FIG.

[0055] At block 710, the electronic device may receive or otherwise access the CEM. In certain embodiments, it may be beneficial to rearrange the CEM to remove sparsity in the clusters of groups and other collected information before identifying the logic blocks. At block 715, the electronic device may automatically rearrange the CEM and / or allow a user to rearrange the CEM. Methods for automatically rearranging the CEM are discussed in more detail below. At block 720, the electronic device may identify and create a set of monitoring blocks and result blocks to implement the logic of the CEM. At block 730, the electronic device may display the monitoring and result blocks to a user, such as a configuration or safety logic engineer, who may design safety or control logic that implements the CEM. In particular, the electronic device may cause a display device to display a graphical user interface (GUI), where the GUI may show a first monitoring block, a second monitoring block, and a result block. Further, each of the first monitoring block, the second monitoring block, and the result block may represent a plurality of cells arranged in a matrix having a first dimension and a second dimension, where a position along the first dimension may represent an output and a position along the second dimension may correspond to an input, and thus the plurality of cells may define an input / output pair based on the position of the plurality of cells relative to the first and second dimensions.

[0056] At block 740, the electronic device may configure or allow a user to configure the monitoring block and the result block to implement the logic of the CEM. In one embodiment, the electronic device allows a user to input configuration data via an input device. In another embodiment, the electronic device may automatically determine or generate the configuration data by parsing the CEM. According to an implementation, the electronic device may configure one of the outputs of the first monitoring block to serve as one of the inputs of the second monitoring block, configure an additional one of the outputs of the first monitoring block and one of the outputs of the second monitoring block to serve as inputs to the result block, and / or designate at least one of the multiple cells of each of the first monitoring block, the second monitoring block, and the result block to a trigger associated with a respective input / output pair of the respective cell and corresponding to a condition of the process plant.

[0057] In one embodiment, to construct the monitor block and the result block, the electronic device includes at least one additional memory cell having an additional plurality of cells defining additional input / output pairs. In one embodiment, the electronic device may incorporate at least one additional result block having an additional plurality of cells defining an additional input / output pair, and may configure at least one input of the additional result block to correspond to an output of one of the first monitor block or the second monitor block, and may assign at least one of the additional plurality of cells to an additional trigger associated with a respective additional input / output pair of the respective additional cell and corresponding to an additional condition of the process plant. In another embodiment, to configure the monitor block and the result block, the electronic device may incorporate at least one additional result block having an additional plurality of cells defining an additional input / output pair, and may configure at least one input of the additional result block to correspond to an output of one of the first monitor block or the second monitor block, and may assign at least one of the additional plurality of cells to an additional trigger associated with a respective additional input / output pair of the respective additional cell and corresponding to an additional condition of the process plant.

[0058] Additionally, in one embodiment, to configure the monitoring block and the result block, the electronic device may configure an input of each of the first monitoring block and the second monitoring block, may configure an input mask of at least one of the first monitoring block and the second monitoring block such that the input mask is logically associated with an input of at least one of the first monitoring block and the second monitoring block, may designate at least one of the triggers as a time delay trigger to activate an associated result with a time delay, and / or may designate at least one of the triggers as a permissive trigger.

[0059] At block 750, the electronic device may store the configured monitoring block and result block. In particular, the electronic device may store configuration data in a computer-readable medium associated with the first monitoring block, the second monitoring block, and the result block. In one embodiment, the electronic device may further display a plurality of cells of each of the first monitoring block, the second monitoring block, and the result block on a display device and may indicate each trigger within each of the plurality of cells.

[0060] Of course, method 700 can create any number of monitor and result blocks connected together in any number of ways to implement the logic of the CEM using these interconnected monitor and result blocks. Each monitor block can include any number of CEM causes or any subset thereof as inputs to the monitor block and can be tied to the outputs of other monitor blocks, thereby achieving cascaded monitor blocks. Additionally, any result block can determine one or more results from a set of inputs and can receive as inputs either the monitor block's output and / or any cause input. Still further, method 700 can interconnect or allow a user to interconnect (i.e., define connections between) various monitor blocks as well as other monitor and result blocks. Thus, each monitor block includes logic to determine one or more intermediate logic conditions or signals based on one or more of the cause signals (inputs to the monitor block, either directly or in the form of another intermediate logic signal resulting from a cause signal input to another upstream monitor block). Similarly, each result block generates one or more result signals based on a set of inputs to the result block, such inputs being causal signals and / or intermediate logic signals output from one or more of the monitor blocks. In this manner, method 700 allows intermediate logic signals to be generated in one or more monitor blocks that represent several logical combinations of the causal signals, and allows this intermediate logic signal to be provided or used as an input to one or more result blocks, thereby simplifying the configuration, size, and logic implemented by the result blocks to create the result signals.

[0061] For smaller CEMs, block 715 of method 700 may allow a safety engineer to manually rearrange and / or configure the CEM, such as by identifying patterns or attempting to group related causes and effects. Such rearrangement may be implemented manually by a user via a graphical user interface, moving or rearranging various rows and / or columns around the CEM to group cells that define cause-effect relationships (e.g., cells marked with an X) closer together or to form denser groupings. However, there are numerous ways to reorganize larger CEMs, and it would be beneficial to identify the best option for reorganization. Thus, an opportunity exists to dynamically and automatically analyze and reorganize CEMs associated with process control systems.

[0062] In one embodiment, the system (i.e., the computer system of FIG. 1) can implement a cause and effect analyzer tool 17 to automatically reorganize a large CEM based on a set of rules. In one embodiment, the rules 31 can be stored in the configuration database 32 of FIG. 1 and / or received via a user interface of the workstations 18a and / or 20a. The analyzer tool 17 analyzes the CEM to determine an optimal or optimized configuration of the CEM (i.e., the best manner to rearrange the CEM to generate a set of monitor and result blocks) taking into account the set of rules 31. The set of rules 31 can be specified by an engineer or otherwise automatically generated by a computer, such as the analyzer tool 17, based on the current needs or configuration of a particular process plant. For example, the set of rules 31 can indicate that the CEM should be organized into groups, with certain causes and / or effects grouped together, based on the corresponding logic solver 50, MPD 70, and / or field devices 22, 23, 24, 60, and 62 in which this logic is to be implemented. Additionally, the set of rules 31 may indicate that the CEM should be reorganized to remove sparsity based on certain patterns, based on system efficiency, and / or based on other criteria. In another embodiment, the set of rules 31 may indicate that certain causes and / or effects (or groups of causes and / or effects) should not be moved. In yet another embodiment, the set of rules 31 may indicate weights of certain causes and / or effects that need to be reorganized, which are used to resolve conflicts when trying to apply multiple rules that lead to different results.

[0063] In one embodiment, the set of rules 31 may indicate that the CEM should be reorganized into a particular number of groups and / or groups of a particular size. The set of rules 31 may further indicate the manner in which the groups should be configured. For example, the set of rules 31 may indicate that each group should contain a particular number, a particular maximum number, or a particular minimum number of causes and / or effects. In one embodiment, the set of rules 31 may indicate that a group should not contain duplicate causes and / or effects. The rules 31 may also specify that certain causes or effects should be grouped together, for example, because these causes are detected by a particular logic solver or at a particular node, or because the effects may need to be implemented by a particular node in a particular logic solver. In any event, once the CEM is reorganized, the set of rules 31 may further enable an engineer to manually configure certain causes and / or effects of the CEM. It is to be appreciated that alternative or additional rules are contemplated.

[0064] In one implementation, the analyzer tool can receive or generate a set of rules 31, the set of rules being associated with a particular cause corresponding to a particular area of ​​the process plant. The set of rules 31 may indicate that only causes and / or effects of a CEM should be reorganized, or that these causes and effects should be reorganized together or as a group. Similarly, the set of rules 31 may indicate that only a particular subset of the causes and effects of a CEM should be reorganized. The analyzer tool may also receive or generate a set of rules 31 that "lock" particular rows and / or columns to prevent the received rows and / or columns from moving during reorganization. Still further, the analyzer tool may receive or generate a set of rules 31 that indicate that causes corresponding to positive logic (i.e., that activate the effect when the cause is "on") should be grouped together, and causes corresponding to negative logic (i.e., that do not activate the effect when the cause is "on") should be grouped together. Other manners of grouping or reorganizing the rows and columns of a CEM based on the type of logic defined in the CEM cell (i.e., the type of logic to be implemented) may be used as well.

[0065] Reorganization of the CEM may then require a multi-part analysis that may be implemented by a computer and based on the set of rules 31. The computer may analyze the CEM by row, by column, by group, by trigger, based on the corresponding logic solver 50, MPD 70, and / or field devices 22, 23, 24, 60, and 62, or by any other factor that is best suited to implementing the set of rules 31. For example, FIG. 8 is an exemplary CEM 800 that is significantly larger than the previous exemplary CEM 300 of FIG. 3. CEM 800 includes several populated cells scattered throughout the matrix. Although CEM 800 is only slightly larger than CEM 300, it is clear that the problem of identifying the logic blocks or groups of CEM 800 that are implemented by a set of monitor and result blocks is increasingly complex. Furthermore, CEM 800 includes populated cells that are interspersed from larger groupings, which increases the difficulty of efficiently selecting the logic blocks used to generate the monitor and result blocks. With an increased size of the CEM, the difficulty of manually selecting or defining logical blocks increases significantly.

[0066] Figure 9 illustrates one example of a display representing CEM 900, which is a reorganized version of CEM 800 from Figure 8. As illustrated in Figure 9, CEM 900 is configured to include three main groups or logic blocks 901, 902, and 903. In one exemplary embodiment, logic blocks 901, 902, and 903 may each correspond to a particular logic solver 50 in a process plant. In another embodiment, a computer may identify logic blocks 901-903 based on criteria defined in a set of rules 31.

[0067] For example, logic block 901 in FIG. 9 may correspond to a set of outcomes that all belong to a particular physical location of the process plant (e.g., a particular heating section) or are implemented by the same controller or logic solver of the plant control system. Additionally, logic block 902 may be generated by an analyzer tool that removes sparsity from the CEM by recognizing groups in which all causes are related to all outcomes. Specifically, in logic block 902, each of causes 4-10 is paired with each of outcomes 3-5. Logic block 903 may correspond to a group of negative logic cause-effect relationships. Although the exemplary CEM 900 includes three logic blocks, the CEM may be divided into any number of logic blocks and may be based on any of the rules 31, or any combination or any other rules described above or not mentioned above that may be used by the analyzer tool 17 when analyzing and reorganizing the CEM. Logic blocks 901, 902, and 903 define a set of interconnected monitoring and result blocks that can be used to implement the logic of these portions of the CEM, as described above with respect to Figures 3 and 4, respectively.

[0068] FIG. 10 is a flow diagram of an example method 1000 for rearranging a cause-effect matrix of a CEM used in developing safety or control logic for a process control system to define and / or manage logic blocks. The method 1000 may be implemented, for example, during configuration of the plant, whenever the CEM of the logic is changed or updated, periodically, and / or in response to a trigger event. The method 1000 may be performed by an electronic device (e.g., analyzer tool 17 of FIG. 1 ), which may include one or more components of a process plant, such as the process plant 10 discussed with respect to FIG. 1 . At block 1010, the electronic device accesses an initial cause-effect matrix having a set of inputs and a set of outputs (i.e., a set of causes and a set of effects). In an embodiment, each of the set of inputs may represent a condition within the process plant, and each of the set of outputs may represent an effect to be performed within the process plant. Furthermore, at least some of the set of inputs and the set of outputs may be related as cause-effect pairs, whereby a corresponding effect may be activated in response to the occurrence of a corresponding condition. The initial cause and effect matrix (CEM) may be stored in a data repository of the process control plant or may be generated by a user in an electronic device for configuring a new process in the plant. The initial CEM may also be received from a database external to the process control system. In some embodiments, the initial CEM may only be accessible by engineers with appropriate credentials, and thus a login or other password may be required to allow access to the initial CEM.

[0069] The electronic device may define each of the set of related groups in the initial CEM. Specifically, at block 1020, the electronic device may access a set of rules 31 associated with the set of related groups. Specifically, the electronic device may access the set of rules 31 through one or more databases either internal or external to the process control system. The electronic device may also receive the set of rules 31 as an input provided by an engineer of the process control plant. Furthermore, the set of rules 31 may be a combination of various rules accessed through various databases and / or inputs. As discussed in more detail above, the set of rules 31 may be intended to reorganize the CEM in an efficient and effective manner.

[0070] In one embodiment, a rule may specify that a specified portion of a set of outputs must be within the same associated group. In another embodiment, a rule may specify that a portion of a set of inputs must amount to a certain amount. In a further embodiment, a rule may specify that neither a set of inputs nor a set of outputs may overlap among a set of associated groups. Of course, any other desired rule may be used.

[0071] At block 1030, the electronic device may identify a portion of a set of inputs (causes) that are associated with a portion of a set of outputs (results) according to a set of rules defined by corresponding cause-effect pairs defined in the CEM. Further, at block 1040, the electronic device may rearrange a portion of the set of inputs and a portion of the set of outputs such that a portion of the corresponding cause-effect pairs are rearranged. Block 1040 may perform this rearrangement to define one or more functional block logic units that are implemented using a set of monitor and result blocks, as defined above. Block 1050 may analyze the rearranged CEM and determine whether the process is complete, and if not, provide control to block 1030 to identify other rules that may be used to rearrange the CEM to further optimize the creation of monitor and result blocks based on the rearranged CEM. Further, block 1050 may determine whether the rearrangement is complete. When this is done, it is possible to define logical blocks or groups of logic within the rearranged CEM, such as the three logical groupings 901, 902, and 903 in FIG.

[0072] In one implementation, the electronic device may further configure one or more function block logic units of the process control system according to the set of associated groups defined by block 1050. Additionally or alternatively, the electronic device may automatically calculate, for each associated group of the set of associated groups, a numeric representation of the associated group, or of a portion of the associated group, according to the rearranged cause-effect pairs, such as by calculating a hexadecimal representation of the associated group, discussed in further detail below with respect to FIGS.

[0073] Once the analyzer tool has reorganized the CEM 900, the system may further separate the CEM 900 into distinct logical groups to further improve efficiency in creating monitor and result blocks that implement those logical groups. FIG. 11 represents an additional representation of the CEM 900 of FIG. 9. Specifically, the system may analyze the CEM 900 of FIG. 9 to generate various numerical representations 1101, 1102, and 1103 that the system may use to configure the functional blocks as a set of interconnected monitor and result blocks. In one embodiment, the numerical representations 1101-1103 may each represent or define an output or result as a value, such as a hexadecimal value, based on the configuration of logical relationships defined by the cause-effect pairs defined by the rearranged CEM 900. This numerical value is in contrast to conventional systems that represent each column as a logical representation. However, such conventional systems are inefficient because the logical representations are difficult to implement or understand.

[0074] In one embodiment, the system can devise a numeric representation by assigning one of two values ​​(e.g., on or off, 1 or 0, etc.) to each cell of the matrix and then converting each bit group (e.g., four binary digits) of a row or column of the CEM into a hexadecimal number. For example, as illustrated in Figure 11, the numeric representation 1101 of output 14 is the hexadecimal representation (FE08) of the cell associated with output 14, where an X in the cell is treated as a binary "1" and an empty cell is treated as a binary "0". This calculation can be illustrated by dividing output 14 into four bit groups (with bold lines separating the cells to form four bit numbers from top to bottom: 1111, 1110, 0000, 1000) and then converting each bit group into a hexadecimal number. In this example, the numeric representation 1101 of output 14 is FE08, since in hexadecimal digits F=1111, E=1110, 0=0000, and 8=1000. In the same manner, the numeric representation 1102 (07E0) corresponds to output 5, which translates to hexadecimal 07E0, since output 5 can be divided from top to bottom into bits 0000, 0111, 1110, 0000. In a similar manner, output 17 can be represented as hexadecimal 0072 (numeric representation 1103). The exemplary numeric representations are not intended to be limiting, and some or all of the columns and / or rows can specify numeric representations. Furthermore, the numeric representations do not necessarily have to be hexadecimal representations, and can be created in any other suitable form.

[0075] Developing a numeric representation for a particular grouping of logic cells within a CEM has many advantages. Specifically, compared to conventional systems, converting the columns to hex is simpler, does not require additional gates or programming to generate the representation, takes less memory to store, and takes less bandwidth to communicate to the function block inputs. Additionally, hex value inputs can be more easily corrected for errors to ensure accuracy if desired, as discussed below with respect to the test matrix of FIG. 15.

[0076] The numerical representation can further enable the system to configure the cause / effect relationships of the safety system configuration environment. Specifically, the numerical representation can enable the system to define multiple cause and effect relationships. Furthermore, the numerical representation can help eliminate configuration errors by collapsing all rows and / or entire columns into a single numeric value. In addition, the numerical representation can provide a simple and efficient way to identify changes in the cause / effect relationships and further reduce the effort required to manage changes in the CEM.

[0077] For example, the numerical representations may be implemented as configuration masks for functional blocks such as the Monitor and Result blocks of FIGS. 4-6. These numerical representations may thus actually identify the logic to be implemented for a particular result of the Monitor and / or Result blocks. The numerical representations define which inputs correspond to each particular output, and thus may isolate (i.e., mask) inputs that do not correspond to a particular output. For example, the numerical representation 1101 of Result 14 in FIG. 11 may isolate all of Causes 6-13 from Result 14. In other words, the Monitor block may receive all of Causes 1-16, but if numerical representation 1101 is implemented as a mask, it simply correlates Causes 1-5 and 14-16 to Result 14.

[0078] Furthermore, the system can adapt the numeric representation when the range of possible cell values ​​exceeds two (e.g., when a cell can define multiple different triggers, such as no value, X, 1T (indicating a time delay), P (indicating a cause tolerance), etc.). For example, for an exemplary range of four possible intersection values, the system can perform two hexadecimal conversions to generate the resulting numeric representation. In other words, the four possible different values ​​of each cell can be represented as one of four possible values ​​of a two-bit number, meaning that each cell is defined by a two-bit value instead of the one-bit value shown in FIG. 11. In this case, two adjacent cells of each set of strings form a four-bit value that can be converted to a hexadecimal number. As a result, the numeric representation in this scenario is twice as long as the numeric representation shown in FIG. 11, but is more dynamic so that it can represent a larger number of potential logical expressions used in the logic implementing the CEM. Alternatively, the system can calculate the numeric representation using a suitable base other than base 16 and then optionally convert the numeric representation (if desired) to a hexadecimal input value for the function block (i.e., the monitor and result block).

[0079] FIG. 12 is a flow chart of an exemplary method for creating / calculating a numerical representation of a value or element in a CEM. At block 1210, the cause and effect analyzer tool 17 may access the CEM. In an exemplary embodiment, the CEM may be rearranged before continuing. At block 1220, the tool 17 may identify a subset of causes. In an embodiment, the subset of causes may be defined by belonging to a particular logic block and / or by a set of rules, as described above. Next, at block 1230, the tool 17 may define a single dimensional matrix of the subset of causes. The one-dimensional matrix may correspond to a particular outcome of the CEM. Next, at block 1240, the tool 17 may calculate a numerical representation of the one-dimensional matrix. As described above, the tool 17 may convert the one-dimensional matrix to a binary string and / or multiple binary strings. In an embodiment, the tool may then proceed to convert one or more binary strings to a hexadecimal representation or any other suitable numerical representation. The calculated numerical representation may be stored as numerical representation 33 in a repository such as configuration database 32 of FIG.

[0080] At block 1250, the numeric representation 33 can then be used to configure a set of function blocks (e.g., monitor and result blocks). For example, as explained above, the numeric Representation 33 may be implemented as a configuration mask of one or more guard blocks.

[0081] In another aspect of the system described herein, a system navigator application provides a user with the ability to quickly navigate between different user interface screens that provide relevant safety information for a process plant. Such information can be found in the CEM, Monitoring and Results Block, Safety Documentation, and System Configuration Views. In some embodiments, these different user interfaces provide different visual representations of the same safety logic. Thus, the present invention provides a navigator tool 15 (of FIG. 1) to navigate between a set of interlinked user interfaces. For example, FIG. 13 is an example illustration 1300 of a set of interlinked user interfaces.

[0082] In some exemplary process plants, safety protocols are programmed in one of several languages. Regardless of the programming language, the starting point for a safety protocol is typically an annotation document that specifies the control and / or safety action requirements for the process plant. In other exemplary process plants, such as a Safety Instrumented System (SIS), safety requirements are documented in a document known as a Safety Requirements Specification (SRS).

[0083] One of the pieces of information about an SRS is a list of identified Safety Instrumented Functions (SIFs). Each SIF protects against a specific hazard and provides a defined level of risk reduction. A SIS is composed of one or more SIFs. In some embodiments, some safety systems combine all SIFs in a SIS configuration without distinction of the individual SIFs. Furthermore, some safety systems allow for a SIF-based SIS configuration following the SIF approach.

[0084] An SRS usually contains different sections, one of which is a logical description that can be represented either by plain text, logic diagrams, or fishbone diagrams (i.e., cause-and-effect matrices). As mentioned above, some safety systems combine all SIFs in a SIS configuration, and the visualization of the CEM can be very convenient when implementing such embodiments.

[0085] In one embodiment, the navigator application 15 allows an engineer to select a given cause (and / or effect) in the CEM to navigate to a specific document that describes the selected cause (and / or effect). For example, selecting a cause can redirect to a description of a specific SIF in the SRS. This feature allows an engineer to view the specific safety logic associated with the cause and / or effect. In one embodiment, an engineer can also select a safety module (system configuration) associated with a given SIF and then be redirected to a user interface that displays the appropriate SIF from the CEM. Additionally, an engineer can select an element in the CEM to be redirected to a display of the system configuration highlighting devices, logic blocks, function blocks, monitoring and result blocks, etc., associated with the particular element in the CEM. From a safety or control module, the user can also be redirected to the appropriate section for annotations in either the SRS or control. In other words, the current system can allow an engineer to seamlessly switch between views of the CEM, SRS, or system configuration.

[0086] For example, if an engineer selects a cause and / or effect of the user interface of FIG. 13 displaying a CEM 1310, the engineer may be redirected to a display screen 1320 showing a system configuration including a particular device related to the selected cause and / or effect of the CEM. For example, system configuration 1320 may include symbols for tanks, valves, transmitters, pumps, pipes, sensors, etc., that are associated with a selected cause and / or effect of the CEM. In this example, thermometer icon 1321 is highlighted to indicate that the selected cause or effect corresponds to a temperature sensor reading.

[0087] Additionally, from either the CEM 1310 or the system configuration 1320, the engineer can access documents describing the safety protocols of the process plant, such as the SRS 1330. FIG. 13 illustrates an example display 1330 of a portion of a safety requirements specification including icons 1331 and text 1332 describing associated safety procedures. The navigator application 15 allows the engineer to toggle between the displays, providing the engineer with information and insight that was previously cumbersome to access. Additionally, from any one of the interfaces 1310, 1320, and / or 1330, the user can access a user interface 1340 that displays a set of monitoring and result blocks (or other function blocks or logic) that contain logic that implements the associated selected element (e.g., of the CEM 1310).

[0088] In an example embodiment, an engineer can right-click on an element in CEM 1310 (or SRS 1330, System Configuration 1320, or Monitoring and Results block 1340) to access a drop-down menu. The drop-down menu can provide the engineer with options including the ability to access other display views (such as 1310, 1320, 1330, and 1340) and / or one of the other views (such as those described with respect to Figures 16A-D below).

[0089] A user can easily navigate from the CEM 1310 (or from an individual cell, cause, or effect of the CEM 1310) or from the system configuration 1320 to a specific section(s) within the requirements specification (SRS 1330), such as a definition of the general bypass principle, proof test requirements, etc.

[0090] This functionality provides a seamless transition back and forth between configuration and design documents to facilitate configuration validation, change management, troubleshooting, and proof testing.

[0091] 14 depicts a block diagram of an example method 1400 for providing access to information contained in a safety requirements specification (SRS) of a process plant controlled by a process control system. The method 1400 may be facilitated by a server or otherwise any type of electronic device, where the server may comprise or be connected to a user interface configured to display content. The SRS may be stored in a memory that may be accessed by the server.

[0092] Method 1400 begins at block 1410, where a server may display the CEM on a user interface. In an embodiment, the (CEM) may include a set of elements including a set of causes and a set of effects, where each of the set of causes may represent a condition within the process plant and each of the set of effects may represent an outcome to be achieved within the process plant. Further, at least some of the set of causes and set of effects may be related as cause-effect pairs, whereby a corresponding outcome may be activated in response to the occurrence of the corresponding condition.

[0093] At block 1420, the server may receive, via a user interface, a selection of an element of the set of elements. Specifically, the server may receive a selection of a cause of the set of causes or an outcome of the set of outcomes. In response to receiving the selection, at block 1430, the server may receive from the SRS a selection of the element of the set of elements. The server may access a set of information associated with one of the elements of the SRS. Specifically, the server may access a set of information associated with a selected cause or a selected effect from the SRS. According to an embodiment, the server may access a piping and instrumentation diagram (P&ID) associated with the selected element, a safety instrumented function (SIF) description associated with the selected element, or other information from the SRS.

[0094] At block 1440, the server may display the set of information in the user interface. In one embodiment, the server may also initiate an application configured to display, via the user interface, safety logic associated with the selected element. Additionally, in one embodiment, the server may receive, via the user interface, an additional selection of the portion of the set of information to be displayed in the user interface, access from the SRS an additional set of information associated with the portion of the set of information, and display the additional set of information in the user interface. Furthermore, in one embodiment, the server may receive, via the user interface, an additional selection of the portion of the set of information to be displayed in the user interface, the portion of the set of information may correspond to an additional element of the set of elements of the CEM, and may display an indication of the CEM and the additional element in the user interface.

[0095] In some embodiments, large CEMs may contain thousands of cause-effect pairs. As a result, these large CEMs may be divided into hundreds of monitoring blocks, result blocks, and numerical representations. Due to the large amount of information scattered across multiple data structures, it may be impossible for a user to manually verify that the safety logic of a process control system is correctly implemented. Previous process control systems lacked a means to rigorously verify that a configured process control system meets required safety protocols. In other words, previous systems did not have any manner of testing the accuracy of the CEMs and function blocks that were implemented to manage the safety of the process plant. The present disclosure provides a tool (e.g., a cause-effect analyzer tool 17) that can automatically verify the safety logic currently implemented in a process plant.

[0096] In one aspect, the cause and effect analyzer tool 17 can automatically traverse the configuration of the process plant (or a portion thereof) to generate one or more test CEMs of the as-built or as-configured system. In one embodiment, the tool 17 can build a test CEM through reverse engineering based on the function blocks (i.e., monitor and result blocks) and numerical representations that represent the currently implemented safety logic of the process plant. The test CEM can then be compared to a requirements-defined CEM (a CEM that is known to be an accurate representation of the safety logic required by the process plant). This comparison can reveal discrepancies or other errors, which can then be presented to the user.

[0097] FIG. 15 is a block diagram of an exemplary method for validating the safety logic of a cause-effect matrix. In block 1510, the analyzer tool 17 may determine a configuration of one or more function blocks representing the safety logic of the cause-effect matrix. In one embodiment, the function blocks are monitor and result blocks that include inputs, outputs, and numerical representations, as described above. The cause-effect analyzer tool 17 may traverse the inputs and outputs of the monitor and result blocks (MEBs) while considering several factors, such as the logic implemented in the MEBs and / or the numerical representation of the MEBs, to determine the configuration of the MEBs. For example, the tool 17 may receive a set of monitor and result blocks, as described in FIGS. 5 and 6 above. The tool 17 may start with the outputs of the result blocks and traverse the inputs of the result blocks to the sources of the inputs (i.e., the sources that feed directly to the result blocks and / or to the outputs of the monitor blocks). The tool 17 may then trace the outputs of the monitoring block to the corresponding inputs of the monitoring block based on the numerical representation. The tool 17 may continue this process of iteratively traversing the MES for each effect until each relationship for each cause-effect pair has been identified.

[0098] At block 1520, the tool 17 may generate a test CEM based on the determined configuration. The tool 17 may populate the test CEM with the identified cause-effect pairs based on the determined configuration of the monitor and result blocks. Once the test CEM is created, the tool 17 may store the test CEM 37 in a data repository (such as the configuration database 32 of FIG. 1). The test CEM 37 may be implemented as any of the CEMs described herein.

[0099] At block 1530, the tool 17 may access the requirements definition CEM. In one embodiment, the requirements definition CEM 35 may be stored in a data repository (such as the configuration database 32 of FIG. 1). In another embodiment, the tool 17 may create the requirements definition CEM based on the current configuration of the process plant and devices of the SRS, as well as other safety documentation. In one embodiment, the requirements definition CEM 35 may include a set of causes and a set of effects, where the cause-effect pair relationships are based on the safety requirements of the process plant. The requirements definition CEM 35 may be implemented as any of the CEMs described herein.

[0100] At block 1540, the tool 17 may compare the test CEM 37 to the requirement definition CEM 35 to determine whether there are any discrepancies. The discrepancies may include any differences between the cause-effect pairs from the test CEM 37 to the requirement definition CEM 35. For example, the cause-effect pairs may not be correlated by the same trigger type (e.g., permissive, immediate, delayed) and / or the same logic type (AND / OR).

[0101] Tool 17 may display any of the one or more determined inconsistencies. In one embodiment, tool 17 may highlight the inconsistencies in any of the user interfaces such as those described in Figures 13 and 16a-d. In other words, tool 17 may highlight where erroneous logic has been implemented in the CEM, the monitoring and results block, the SRS document, and / or the system configuration user interface.

[0102] In addition to the functionality discussed above with respect to Figures 13 and 14, it may also be useful to view the status history of one or more devices, causes, and / or consequences of a process plant. Another aspect of the present invention provides a user interface view for monitoring the status of a safety system of a process control system, which status is typically based on or "keyed" to physical equipment and / or safety test results, and may show the current and past status of various causes or consequences to provide the user with some ability to know when and how the CEM logic is being implemented in the plant. For example, an engineer may be presented with a view (as discussed above with respect to Figure 13) that displays a particular device or portion of equipment, or a group thereof, which may then be further used to access a display view (e.g., Figures 16A-D) that displays the current and / or past safety status, cause signals, etc. of each of the monitored devices / pieces of equipment shown in the display view. Additionally or alternatively, a safety engineer may perform safety tests on a particular physical device / piece of equipment of the plant, and the results may be displayed in the display view (e.g., Figures 16A-D). Previous systems have been able to improve the overall safety of the plant (or desired areas of the plant) without requiring access to many different display views of the physical devices / equipment or having to perform specific diagnostics to obtain test results. The previous system did not allow engineers to quickly monitor and access all statuses. Not only was the previous system inconvenient for engineers, but it also resulted in valuable time being lost during emergency situations while the engineer had to wade through numerous views or test runs to obtain or find the status data of interest.

[0103] The systems and methods described herein provide an easily accessible display view of the current state and / or state changes of monitored safety events (rather than specific devices, equipment, or test results). The system aggregates system or area-wide safety event / input states into a single display view or visualization, captures safety event changes over time, and links visualized safety events across safety display views to device / equipment / test results.

[0104] A "safety event" is a logical representation of a condition being monitored. In an exemplary embodiment, each monitored input (cause) of the CEM can be a monitored safety event. Additionally, each outcome can be a monitored safety event. Each state and / or each change in state of each safety event desired to be monitored is represented by a different object / item / graphical item on the safety event visualization view. For example, each monitored event can be presented by a colored dot, with different colors indicating different current states (e.g., red-failure, blue-caution, black-OK). Additionally or alternatively, changes in the current state can be represented (binary and / or by degree of change), for example, by different colors or representations. Such states and / or changes in state can be captured and stored over time. In effect, the display view can provide a rotating snapshot time of the monitored events and can include different sections of the monitored safety events at different rates (e.g., every 2 minutes, every 20 minutes, every 2 hours).

[0105] 16A-D are exemplary illustrations of changes in the state of a safety event over time. In FIG. 16A-D, event E1 is a monitored safety event. The current safety state of E1 over time can be represented on a display view as a running line of shapes along a time axis, with each shape (as represented in FIG. 16A) representing a different state. In graph 1600, a circle represents a normal state, a square represents a warning state, and a triangle represents a dangerous state. Alternatively, changes in the safety state of E1 over time can be represented based on the time at which the change occurred. For example, in FIG. 16B, graph 1610 indicates a steady state (or the absence of any state change) with a "0", a decreasing safety state with a "-", and an increasing safety state with a "+". It should be appreciated that the safety state and its changes can be represented in any type of numerical or graphical form. FIG. 16C illustrates a graph 1620 that displays the states as numbers, with a negative increase from 0 representing additional state degradation. If desired, the degree of change in safety status can be represented. For example, the y-axis of the graph can show the range of degradation out of normal, and the safety status over time can appear as a line graph, or a bar graph of dots 1630 of FIG. 16D. Additionally, a single line of a colored running line of dots of monitored events can be gradually morphed / shaded from one color to another to indicate worsening and / or improving safety status.

[0106] The above examples are not intended to be limiting, and any combination of numbers, symbols, colors, graphics, and / or lines can be displayed to allow an engineer to quickly assess the safety level of the monitored events. Additionally, the status and / or changes in status of various events can be stored for post-processing, if desired.

[0107] In one embodiment, one or more graphs may be displayed together and / or simultaneously. A desired grouping of monitored events may be based on, for example, an area of ​​the plant, a function, or the like. , by particular condition or factor (e.g., during a particular stage of a batch process), etc. Engineers may be able to mask the display view to allow them to see a particular safety event of interest at a glance.

[0108] Additionally, the visualization can provide more abstract safety events. As discussed above, a monitored safety event can be an abstraction of a group of monitored events, such as an observation and result block.

[0109] For example, referring to Figures 5 and 6, the direct inputs to the enabler or result blocks EB1 and EB2 may be the monitored safety events, and / or each result E1, E2, etc. of the result blocks EB1 and EB2 may be the monitored safety events. Each of the conditions or inputs that each desired monitored event is included in may contribute to the degree of change in its state. For example, if a monitored event requires four conditions to trigger the event, when one condition exists the monitored event state may be "-1", when two conditions exist the monitored event state may be "-2", when three conditions exist the monitored event state may be "-3", and when all four conditions exist the state may be "X" or "tripped". Thus, by way of example, the symbols, numbers, dots, etc. of Figures 16A-16D may represent different possible states of the result (or cause), or may represent the number of causes that are set, or the number of causes that are true out of the total number of causes that need to be set, or are true to trip or initiate the result signal.

[0110] Additionally, clicking or other user instruction of a particular safety state or state change indicator can automatically link the user to details of the corresponding condition(s). As described above, from the safety event visualization graph, an engineer can access views of the SRS, system configuration, and / or CEM. For example, referring to the above example of four conditions required to trip a monitored event, if the safety visualization shows "-1" for the monitored event in the above example graph 1620 and the user clicks on "-1", a display view of the system configuration can be displayed that includes the devices or portions of the equipment that give rise to the condition corresponding to the "-1" safety state.

[0111] 17 depicts a block diagram of an example method 1700 for visualizing safety events in a process plant. The method 1700 can be facilitated by a server or otherwise any type of electronic device, where the server can comprise or be connected to a user interface configured to display content.

[0112] The method 1700 may begin when a server accesses a CEM having a set of causes and a set of effects (block 1710). In an embodiment, each of the set of causes may represent a condition within the process plant and each of the set of effects may represent an outcome to be performed within the process plant. Further, at least some of the set of causes and the set of effects may be related as cause-effect pairs whereby a corresponding outcome may be activated in response to the occurrence of the corresponding condition, and the set of causes and the set of effects may represent a set of monitored safety events within the process plant.

[0113] The server may receive a selection of a monitored safety event of the set of monitored safety events via the user interface (block 1720). Additionally, the server may display an indication of the monitored safety event and a current state of the monitored safety event on the user interface (block 1730). In an embodiment, the server may display the current state as one or more first graphical objects.

[0114] The server may detect a change in the state of the monitored safety event (block 1740). In one embodiment, the server may detect the change in state in response to an end of the time period. The server may also display an updated state of the monitored safety event in a user interface according to the change in state (block 1750). In an embodiment, the server may display the updated state as one or more second graphical objects, which may be different from the one or more first graphical objects. Further, in an embodiment, the server may determine an extent of change between a current state and an updated state of the monitored safety event, and may display the extent of change in the user interface.

[0115] In one embodiment, the server may further determine that an updated state of the monitored safety event has not changed in response to an end of the time period, and may display the updated state of the monitored safety event in a user interface. Additionally or alternatively, the server may receive, via a user interface, a selection of an updated state of the monitored safety event, where the monitored safety event may have a set of associated conditions, and may display a condition state of each of the set of associated conditions in the user interface. Additionally or alternatively, the server may receive, via a user interface, a selection of an updated state of the monitored safety event, where the monitored safety event may have an associated condition that exists, and may display in the user interface an indication of devices within the process plant that are causing the associated condition to exist.

[0116] Additionally or alternatively, the server may store in memory data representative of the monitored safety events, current states of the monitored safety events, and updated states of the monitored safety events. Further additionally or alternatively, the server may display (i) an additional indication of an additional one of the set of monitored safety events and (ii) an additional current state of the additional monitored safety event in a user interface, detect an additional change in state of the additional monitored safety event, and display an additional updated state of the additional monitored safety event in the user interface in accordance with the additional state change.

[0117] The exemplary CEM provided above is a simple representation intended for illustrative purposes. FIG. 18 illustrates an exemplary CEM 1800, which is a more complex CEM that includes a time delay trigger, a permissive trigger, an immediate trigger, and a reset trigger. CEM 1800 is a more substantial embodiment of a CEM that is a more accurate representation of a real CEM. In CEM 1800 as illustrated in FIG. 18, a cell containing only "X" can represent an immediate trigger result. Additionally, any cell populated with only "R" can represent that the result is triggered to reset if a cause is received. A cell in CEM 1800 beginning with the letter "T" can indicate that the cause directly triggers the result, but with a time delay. The time delay can be set to a predefined increment. For example, "T1" can correspond to a 10 second time delay, "T2" can correspond to a 20 second time delay, and so on.

[0118] CEM 1800 also includes cells that contain only numbers, such that these cells can correspond to "enablers." Specifically, the number in the cell identifies the group to which the enabler belongs, and there can be one or more enablers for each group. Cells in CEM 1800 that not only begin with a number, but also have other characters, can represent relationships that only trigger the result if the enabler is also triggered. In some embodiments, every cell associated with a corresponding enabler (or enablers) can be a trigger. A group of enablers must be "on" for the outcome to be triggered. In other embodiments, any combination of causes for a particular enabler group can be combined to trigger the outcome. Similarly, any combination of enablers may be required to trigger the outcome.

[0119] For example, in CEM 1800 as illustrated in FIG. 18, cause 1801 is an enabler of group 1. Therefore, if cause 1802 is tripped, the corresponding effect cannot be triggered unless cause 1801 is also tripped. This cause-effect relationship is considered a permissive relationship because the effect is triggered only if the enabler is “on”. Continuing with this example, cell 1803 indicates that the cause-effect relationship belongs to enabler group 1, and that effect 1805 is triggered with a time delay corresponding to length T1 when cause signal 1802 goes high and enabler cause signal 1801 is also high or on. Cell 1804 indicates that the cause-effect relationship is permissive and belongs to enabler group 1, and that effect 1806 is triggered immediately if cause signal 1802 is enabled (i.e., cause signal 1801 is on) and tripped.

[0120] CEM 1800 can be implemented with all of the previous methods 700, 1000, 1200, 1400, 1500, and 1700 described above. Furthermore, the CEM or the monitor and result blocks described herein for implementing the logic of the CEM can be used to implement the complex and interrelated logic functions of CEM 1800, for example, or any other logic functions of other CEMs. Despite the added complexity of CEM 1800, the benefits of managing the CEM still apply. Furthermore, the exemplary CEM is not intended to be limiting, and any of the methods 700, 1000, 1200, 1400, 1500, and 1700 described above can be implemented with any future embodiment of the cause and effect matrix used to implement safety logic in a process plant.

[0121] Each of methods 700, 1000, 1200, 1400, 1500, and 1700 of Figures 7, 10, 12, 14, 15, and 17 may be implemented by software, firmware, or hardware, or some combination of software, firmware, and / or hardware. Additionally, although the flow diagrams of Figures 7, 10, 12, 14, 15, and 17 are described as routines, these flow diagrams may be implemented by software, hardware, firmware, or a combination of software, firmware, and / or hardware.

[0122] An embodiment of a user interface, such as the user interface described above, can be implemented in whole or in part by a processor, for example configured according to a software program. For example, the workstation 18a or 20a, or some other computer, can implement the user interface described above in whole or in part. Although the software program for implementing the embodiment of the user interface can be embodied in software stored on a tangible medium, such as a hard disk, RAM, battery-backed RAM, ROM, CD-ROM, PROM, EPROM, EEPROM, DVD, flash memory, or in a memory, such as a RAM associated with a processor, those skilled in the art will readily recognize that the entire program or parts thereof can alternatively be executed by a device other than a processor and / or embodied in firmware and / or dedicated hardware in a known manner.

[0123] While the invention is susceptible to various modifications and alternative constructions, specific exemplary embodiments thereof are described below. Although embodiments are illustrated in the drawings and described in detail herein, it should be understood that the intention is not to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the present disclosure as defined by the appended claims.

Claims

1. 1. A computer-implemented method for visualizing safety events in a process plant, the method comprising: Accessing a Cause and Effect Matrix (CEM) having a set of causes and a set of effects, The causes are arranged along a first axis; The results are arranged along a second axis; each of said causes being associated with a respective effect as a respective cause / effect pair that defines whether or not the corresponding effect is initiated in response to the occurrence of the corresponding cause; accessing the causes and the effects representing a set of monitored safety events within the process plant; receiving, via a user interface, a selection of a monitored safety event of the set of monitored safety events; determining a current state of the monitored safety event; the current state indicates a safety level of the monitored safety event corresponding to a safety logic of the CEM; determining that the safety level indicates a degree of degradation of a state of the safety event from a steady state based on one or more conditions corresponding to the monitored safety event; (i) displaying an indication of the monitored safety events, and (ii) the current status of the monitored safety events on the user interface; detecting a change in a state of the monitored safety event, including detecting an end of a period during which the state of the monitored safety event is at the steady state; and displaying an updated status of the monitored safety event in the user interface according to the change in status.

2. Displaying the current status of the monitored safety events. displaying the current state of the monitored safety event as a first graphical object, and displaying the updated state of the monitored safety event includes: The updated status of the monitored safety event is displayed on the first graphical object.

10. The computer-implemented method of claim 1, further comprising displaying the first object as a second graphical object distinct from the first object.

3. Displaying the current status of the monitored safety events. displaying the current status of the monitored safety event as at least two first graphical objects, and displaying the updated status of the monitored safety event includes: The computer-implemented method of claim 1 or 2, further comprising displaying the updated status of the monitored safety events as at least two second graphical objects.

4. Displaying the updated status of the monitored safety events. determining a degree of change between the current state and the updated state of the monitored safety event; and displaying the degree of change in the user interface. determining, in response to an expiration of a predetermined monitoring period, that the updated state of the monitored safety event has not changed; The computer-implemented method of claim 1 , further comprising: displaying the updated status of the monitored safety events in the user interface.

6. receiving, via the user interface, a selection of the updated status of the monitored safety event, the monitored safety event having a set of associated conditions; The computer-implemented method of claim 1 , further comprising: displaying a condition state of each of the set of associated conditions in the user interface.

7. receiving, via the user interface, a selection of the updated status of the monitored safety event, the monitored safety event having an associated condition present; 7. The computer-implemented method of claim 1, further comprising: displaying in the user interface a symbol representing a device in the process plant that causes the associated condition to exist.

8. (i) displaying, on the user interface, an additional indication of an additional monitored safety event of the set of monitored safety events, and (ii) an additional current state of the additional monitored safety event; detecting an additional change in state of the additional monitored safety event; and 8. The computer-implemented method of claim 1, further comprising: displaying an additional updated status of the additional monitored safety event in the user interface according to the additional status change.

9. 1. A system for visualizing safety events in a process plant, comprising: A user interface; (i) a set of computer-executable instructions; and (ii) a memory configured to store a cause-effect matrix (CEM) having a set of causes arranged along a first axis and a set of effects arranged along a second axis, each of the set of causes represents a condition within the process plant and each of the set of consequences represents an outcome to be achieved within the process plant; each of said set of causes being associated with a respective effect as a respective cause / effect pair that defines whether or not the corresponding effect is initiated in response to the occurrence of the corresponding cause; a memory, the causes and the effects representing a set of monitored safety events within the process plant; a processor interfaced with the user interface and the memory, the processor executing the set of computer-executable instructions to: receiving, via the user interface, a selection of a monitored safety event of the set of monitored safety events; determining a current state of the monitored safety event; the current state indicates a safety level of the monitored safety event corresponding to a safety logic of the CEM, the safety level indicating a degree of degradation of a state of the safety event from a steady state based on one or more conditions corresponding to the monitored safety event; causing the user interface to display (i) an indication of the monitored safety events, and (ii) the current status of the monitored safety events; detecting a change in a state of the monitored safety event, including detecting an end of a period during which the state of the monitored safety event is at the steady state; and a processor that causes the user interface to display updated states of the monitored safety events according to the changes in state.

10. to cause the user interface to display the current status of the monitored safety events, the processor configured to cause the user interface to display the current status of the monitored safety event as a first graphical object, and to cause the user interface to display the updated status of the monitored safety event, the processor: The system of claim 9 , configured to cause the user interface to display the updated status of the monitored safety event as a second graphical object distinct from the first graphical object.

11. to cause the user interface to display the current status of the monitored safety events, the processor and configured to cause the user interface to display the current status of the monitored safety events as at least two first graphical objects, and to cause the user interface to display the updated status of the monitored safety events, the processor: The system of claim 9 or 10, configured to cause the user interface to display the updated status of the monitored safety events as at least two second graphical objects.

12. to cause the user interface to display the updated status of the monitored safety events, the processor determining a degree of change between the current state and the updated state of the monitored safety event; The system of claim 9 , configured to cause the user interface to display the extent of the change.

13. The processor, via the user interface, receiving a selection of a state, the monitored safety event having a set of associated conditions; The system of claim 9 , further configured to cause the user interface to display a condition state of each of the set of associated conditions.

14. The processor, and further configured to receive, via the user interface, a selection of the updated status of the monitored safety event, the monitored safety event having an associated condition present; 14. The system of claim 9, further configured to cause the user interface to display a symbol indicative of a device within the process plant that causes the associated condition to exist.

15. The processor, causing the user interface to display (i) an additional indication of an additional monitored safety event of the set of monitored safety events, and (ii) an additional current state of the additional monitored safety event; Detecting an additional change in state of the additional monitored safety event; 15. The system of claim 9, further configured to cause the user interface to display an additional updated status of the additional monitored safety event according to the additional status change.

16. 1. A computer-implemented method for visualizing safety events in a process plant, the method comprising: accessing a safety logic of a cause and effect matrix (CEM) corresponding to the process plant having a set of causes arranged along a first axis and a set of effects arranged along a second axis; each of the set of causes represents a condition within the process plant and each of the set of consequences represents an action to be taken within the process plant based on one or more of the conditions; each of said set of causes being associated with each of said set of effects; Define whether each cause / effect pair is activated in response to the occurrence of the corresponding cause; accessing the causes and the effects, the causes and effects representing a set of monitored safety events within the process plant; receiving, via a user interface, a selection of a monitored safety event of the set of monitored safety events; determining a current state of the monitored safety event; the current state indicates a safety level of the monitored safety event corresponding to a safety logic of the CEM; determining that the safety level indicates a degree of degradation of a state of the safety event from a steady state based on one or more conditions corresponding to the monitored safety event; displaying the current status of the monitored safety events on the user interface; and receiving, via the user interface, a selection of the displayed monitored safety event elements; displaying, via the user interface, a view of a system configuration including a device corresponding to the selected element; A computer-implemented method comprising:

17. displaying, via the user interface, a menu of one or more representations of the monitored safety events; Receiving a selection of a display type via a user interface; and displaying, via the user interface, the current status of the monitored safety events according to the display type; 20. The computer-implemented method of claim 16, further comprising:

18. the selection of the display type being one or more of a selection of symbolic, color, graphic, line, and numeric display; 20. The computer-implemented method of claim 17.

19. receiving, via the user interface, a selection of a second monitored safety event; and displaying, via the user interface, a current state of the second monitored safety event corresponding to the current state of the monitored safety event; 19. The computer-implemented method of claim 16, further comprising:

20. determining that the selected monitored safety event corresponds to an outcome from the set of outcomes; and displaying, via the user interface, information related to one or more conditions corresponding to the results; and 20. The computer-implemented method of claim 16, further comprising:

21. determining that the monitored safety event corresponds to a result corresponding to one or more conditions of a powerplant; and displaying an indication of each of said conditions via said user interface; 21. The computer-implemented method of claim 16, further comprising:

22. 1. A computer-implemented method for detecting an event in a process plant, the method comprising: enabling a user to define one or more safety events to be monitored within the process plant; each safety event of the one or more safety events corresponds to a cause-effect matrix (CEM) having a set of causes arranged along a first axis and a set of effects arranged along a second axis; each of the set of causes indicative of a condition within the process plant and each of the set of consequences indicative of an outcome occurring within the process plant; each of the set of causes is associated with each of the set of effects as a respective cause / effect pair that defines whether or not the corresponding effect is initiated in response to the occurrence of the corresponding cause; enabling the causes and effects to be defined to represent a set of monitored safety events within the process plant; receiving, via a user interface, a safety event selection of the one or more safety events to be monitored within a plant; via a processor, detecting a current state of the selected safety event and a safety level indicating a degree of degradation of the state of the safety event from a steady state based on one or more conditions corresponding to the monitored safety event; and displaying, on a display device, a status of the selected safety event as a graphical indication associated with a number of the detected current states of one or more conditions corresponding to the selected safety event; via the user interface, elements of the displayed monitored safety events. receiving a selection of displaying, via the user interface, a view of a system configuration including a device corresponding to the selected element; A computer-implemented method comprising:

Images