System and method for representing a causal matrix as a set of numerical representations

Abstract

A system and method for defining a cause-effect matrix (CEM) within a process control system of a process plant, the system and method comprising: accessing a cause-effect matrix (CEM) having a set of causes and a set of results, wherein each cause in the set of causes represents a condition within the process plant, and each result in the set of results represents a result to be performed within the process plant. The system and method further comprises, for each result in the set of results: (i) identifying a subset of the set of causes based on a corresponding set of cause-effect pairs corresponding to the results in the set of results, (ii) defining the subset of the set of causes as a single-dimensional matrix, and (iii) automatically calculating a numerical representation of the single-dimensional matrix. The system and method further comprises configuring a set of function blocks for the process control system based on the set of numerical representations.

Description

[0001] This application is a divisional application of the invention patent application entitled “System and method for representing a causal matrix as a set of numerical representations”, with an international application date of October 7, 2016, an international application number of PCT / US2016 / 056031, and a national application number of 201680059067.X.

[0002] Related Applications

[0003] This patent application is a conventional patent application that claims priority to and the benefit of the filing date of U.S. Provisional Patent Application Serial No. 62 / 239,657, filed on October 9, 2015, and entitled “A System and Method for Configuring Separated Monitor and Effect Blocks of a Process Control System,” which is expressly incorporated herein by reference. Technical Field

[0004] The present disclosure relates generally to managing process control systems within a process plant, and more particularly, to configuring a cause and effect matrix (CEM) associated with a process control system and creating monitoring blocks and result blocks related thereto. Background Art

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

[0006] In addition, in many processes, a separate safety system is provided to detect significant safety-related problems within the process plant, and when a problem occurs that may cause or lead to a serious hazard within the plant (such as a toxic chemical spill, explosion, etc.), the valve is automatically closed, power is removed from the equipment, the process within the plant is switched, etc. These safety systems usually have one or more separate controllers in addition to the standard process controller, called logic solvers, which are connected to the safety field devices via a separate bus or communication line installed in the process plant. The logic solver uses the safety field devices to detect process conditions associated with significant events, such as the position of certain safety switches or shutoff valves, overflow or underflow in the process, the operation of important power generation or control equipment, the operation of faulty operation detection equipment, etc., thereby detecting "events" within the process plant. When an event (usually called a "cause") that may be a single condition or two or more conditions occurring simultaneously is detected, the safety controller takes some actions (usually called "effects") to limit the harmful nature of the event, such as closing valves, disconnecting equipment (turning off), removing power from various parts of the plant, etc. Typically, these actions or results include switching the safety device to a trip or "safe" mode of operation designed to prevent a serious or hazardous condition within the process plant.

[0007] Operators of process plants (such as managers and engineers) usually maintain a data structure that stores related causes and results. For example, a matrix may have multiple rows and columns, where each row corresponds to a cause, each column corresponds to a result, and each cell of the matrix corresponds to a specific cause-effect relationship. These cells may be filled with various triggers that indicate the relationship between each cause and result. The so-called cause-effect matrix (CEM) is generally configured according to a requirement document that defines a safety design for a control system or plant. Control engineers can use CEM to engineer control systems, thereby implementing safety designs accordingly. However, such CEMs are limited to the size of the definition of the matrix and are often not large enough to handle all desired cause / result data relationships. In addition, such CEMs cannot handle more complex / sophisticated causes / results, such as chain connections, links, levels, loops, etc. In addition, it is cumbersome to implement large CEMs into control logic, and therefore prone to errors during implementation. In safety systems, maintaining an accurate CEM is essential because errors in the CEM can be serious, since failure of the properly operating safety system can result in serious injury or even death of plant personnel and potentially millions of dollars in damage to equipment and materials within the plant. Summary of the invention

[0008] A process control system for a process plant may have a safety system that may be implemented or designed to affect control logic defined in a cause-effect matrix (CEM), wherein the CEM is a summary of safety actions for the process plant displayed in a visual representation. In general, the CEM defines basic cause-effect relationships for various safety protocols or processes within the process plant. Typically, the CEM may include a set of inputs and a set of outputs, wherein each of the input sets represents a condition within the process plant, and each of the output sets represents a result or action to be performed within the process plant. Furthermore, at least some of the input sets and the output sets are related as cause-effect pairs, whereby corresponding results are activated in response to the occurrence of corresponding conditions or causes.

[0009] An administrator of a process control system may implement a CEM as a collection of various function blocks. However, depending on the size and / or complexity of the process plant, a given CEM may contain numerous causes, effects, and cause-effect pairs, and may therefore require a correspondingly large number of function blocks to implement. As a result, such implementation may become time consuming, complex, and cumbersome, leading to potential implementation errors. According to the described system and method, a technique is provided for implementing a CEM within a process control system as a separate but interconnected collection of function blocks, described as monitoring function blocks and result function blocks, to implement CEM logic.

[0010] In one embodiment, the system and method can identify patterns and groupings within a CEM, and can implement monitoring block sets and result block sets based on the identified patterns and groupings, thereby reducing the complexity of the implementation of the CEM. In one implementation, groupings of data within a CEM (e.g., columns of a CEM) can be defined as numerical representations of the logic defined by that portion of the CEM to provide a simple and less complex way to understand and verify that the logic of the CEM is implemented within the functional blocks (e.g., monitoring and result blocks) used to implement the CEM logic. In addition, tools can be used to analyze and reorder or rearrange CEMs (e.g., rows and / or columns of CEMs) to provide better, more logical, easier to implement, etc. groupings of CEM logic to implement as one or more cause and effect block sets.

[0011] The present disclosure provides additional techniques for managing CEMs. Specifically, the systems and methods described herein can be used to configure a CEM to include interactive functionality. For example, a configured CEM can include a connection or selection to access one or more documents detailing a security protocol of cause and effect relationships that constitute the CEM, a diagram depicting the current and / or past status of one or more results of the CEM to enable a user to more easily understand previous conditions or operations with respect to a particular result achieved in the plant, and a diagram of a process plant including equipment associated with the causes and results of the CEM.

[0012] Additionally, due to the typically large amount of information contained in a CEM, it may be difficult for an engineer to identify any differences or errors contained in a process control system. The systems and methods provided herein further enable reverse engineering techniques and systems to automatically create a test CEM that defines the CEM logic actually implemented by the equipment and control logic in the process plant (or, in some implementations, the monitoring blocks and result blocks within the process control system) and the safety protocols required for a particular process plant. Thus, the systems and methods described herein can compare the test CEM with an existing CEM to identify any differences or errors between the actual configuration of the plant operation and the configuration of the plant operation that may be detailed in the design documentation. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings described below depict various aspects of the systems and methods disclosed therein. It should be understood that each of the accompanying drawings depicts an embodiment of a specific aspect of the disclosed systems and methods, and that each of the accompanying drawings is intended to conform to its possible embodiments. In addition, as much as possible, the following description refers to reference numerals included in the following drawings, wherein features depicted in multiple drawings are represented by consistent reference numerals.

[0014] The arrangements of the present discussion are shown in the accompanying drawings, however, it should be understood that the present embodiments are not limited to the precise arrangements and instrumentalities shown, wherein:

[0015] Figure 1 is a block diagram of an exemplary process plant;

[0016] Figure 2 yes Figure 1 A block diagram of an exemplary workstation schematically shown in FIG.

[0017] Figure 3 is a graphic representation of an exemplary cause-effect matrix;

[0018] Figure 4 is a diagram of an exemplary set of monitoring blocks and result blocks;

[0019] Figure 5 is a diagram of a first example of a set of functional blocks that may be used to implement a monitoring block and a result block;

[0020] Figure 6 is a diagram of a second example of a set of functional blocks that may be used to implement a monitoring block and a result block;

[0021] Figure 7 is a flow chart of an exemplary method of configuring monitoring blocks and result blocks associated with a process plant.

[0022] Figure 8 is a diagram of a second example of a cause-effect matrix;

[0023] Fig. 9 yes Figure 8 an illustration of a second example of a causal matrix of that has been reorganized and configured into separate logical blocks;

[0024] Fig.10 is a flow chart of an exemplary method of reorganizing a cause-effect matrix;

[0025] Fig.11 is a diagram of a second example of a cause-effect matrix with exemplary numerical representations;

[0026] Fig.12 is a flow chart of an exemplary method for computing a numerical representation of causal matrix logic;

[0027] Fig.13 is an exemplary illustration of various interconnected user interfaces corresponding to the security logic of the cause-effect matrix;

[0028] Fig.14 is used in Fig.13 A flowchart of an exemplary method for navigating between interconnected user interfaces;

[0029] Fig.15 is a flow chart of an exemplary method for reverse engineering a test cause-effect matrix;

[0030] Figures 16A-16D is an illustration of an exemplary user interface displaying monitored security events;

[0031] Fig.17 is a flow chart of an exemplary method for displaying monitored security events;

[0032] Fig.18 is a diagram of an exemplary cause-effect matrix including permissive and time-delayed triggers;

[0033] The drawings depict the preferred embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the systems and methods shown herein may be employed without departing from the principles of the invention described herein. DETAILED DESCRIPTION

[0034] Figure 1 is a block diagram of an exemplary process plant 10 including one or more nodes 12, 16, 18, and 20. Figure 1 In the exemplary process plant 10 of FIG. 1 , each of the nodes 12 and 16 includes a process controller 12 a, 16 a, which is 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 12 a and 16 a are also coupled to one or more hosts or operator workstations 18 a and 20 a in the nodes 18 and 20 via a network 30, which may include, for example, one or more of a bus, a wired local area network (LAN) such as an Ethernet LAN, a wireless LAN, a wide area network (WAN), an intranet, etc. While the controller nodes 12, 16 and the I / O devices 24 and field devices 22, 23 associated therewith are typically located within and distributed throughout the sometimes harsh plant environment, the operator workstation nodes 18 and 20 are typically located in a control room or other less harsh environment that can be easily accessed by control personnel.

[0035] In general, the workstations 18a and 20a of the nodes 18 and 20 can be used to store and execute applications for configuring and monitoring the process plant 10, and / or manage the devices 22, 23, 24 and controllers 12a, 16a in the process plant 10. For example, the workstations 18a and / or 20a can include tools such as the system navigator application 15, the cause-effect analyzer tool 17, the process control configuration application 19, and the safety configuration application 21, which can be implemented to manage the safety requirements of the process plant 10. The system navigator application 15 can be implemented to provide an interconnected group of user interfaces that provide information about the safety requirements and devices in the process plant. The cause-effect analyzer tool can be implemented to manage the cause-effect matrix (CEM) and / or create the cause-effect matrix by reverse engineering from known safety requirements and / or functional blocks. In addition, the process control configuration application 19 and the safety configuration application 21 provide users with the ability to manage the devices of the process plant through the workstations 18a and / or 20a. The configuration database 32 may be connected to the network 30 and may operate 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 contain rules 31 and / or numerical representations 33 for reordering the CEMs.

[0036] Each of the controllers 12a and 16a (which may be, for example, a DeltaV TM A controller) may store and execute a controller application that implements a control strategy using a number of different, independently executed control modules or blocks. The control modules may each be comprised of what are commonly referred to as function blocks, wherein each function block is a portion or subroutine of an overall control routine and operates in conjunction with other function blocks (via communications referred to as 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 an input function associated with a transmitter, sensor, or other process parameter measurement device), a control function (such as a control function associated with a control routine that performs PID, fuzzy logic, etc. control), or an output function that controls the operation of some device (e.g., 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. Although Fieldbus protocols and DeltaV TM The system protocol may use control modules and function blocks designed and implemented in an object-oriented programming protocol, but the control modules may be designed using any desired control programming scheme including, for example, sequential function blocks, ladder logic, etc., and are not limited to being designed using function blocks or any other specific programming technique. Typically, 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 by applications executed by the workstations 18a and 20a. 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 for or associated with standard 4-20mA devices and certain types of smart field devices such as HART devices, or may be stored in and implemented by the field devices themselves, which may be the case for Fieldbus devices.

[0037] exist Figure 1 In the illustrated system, the field devices 22 and 23 coupled to the controllers 12a and 16a may be standard 4-20mA devices, or may be intelligent field devices, such as HART, Profibus, or Foundation fieldbus field devices, which include a processor and memory. Some of these devices, such as Foundation fieldbus field devices (in Figure 1The field devices 22, 23 may be any type of device, such as a sensor, a valve, a transmitter, a positioner, etc., and the I / O device 24 may be any type of I / O device that complies with any desired communication or controller protocol, such as HART, Foundation fieldbus, Profibus, etc.

[0038] The controllers 12a and 16a each include a processor that implements or oversees one or more process control routines stored in a memory, which may include control loops stored therein or otherwise associated therewith. The controllers 12a and 16a communicate with the field devices 22, 23, the workstations 18a, 20a, and the 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.

[0039] The process plant 10 may also include a safety system 14 (indicated by a dashed line) 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 the controls provided by the process control nodes 12 and 16 to maximize the safest possible operation of the process plant 10.

[0040] Each of the nodes 12 and 16 may include one or more safety system logic solvers 50. Each logic solver 50 is an I / O device having a processor and a memory and is configured to execute a safety logic module 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. In addition, each of the nodes 12 and 16 may include at least one message propagation device (MPD) 70 that communicates with the safety system field devices 60 and 62 via a ring or bus connection 74 (only in the case of Figure 1 The safety system logic solver 50, the safety system field devices 60 and 62, the MPD 70, and the bus 74 generally constitute a Figure 1 Security system14.

[0041] Figure 1The logic solver 50 may be any desired type of safety system control device that includes a processor and a memory that stores safety logic modules suitable for execution 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 devices that follow or use 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 conventionally controlled by a separate, dedicated safety-related control system. Figure 1 In the illustrated process plant 10, the safety field device 60 is depicted as using a dedicated or point-to-point communication protocol, such as HART or a 4-20mA protocol, while the safety field device 62 is illustrated as using a bus communication protocol, such as a Fieldbus protocol. The safety field device 60 may perform any desired function, such as shutting off a valve, shutting off a 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 for communicating with the logic solver 50, including any desired wired or wireless communication protocols.

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

[0043] As will be appreciated by those of ordinary skill in the art, the backplanes (not shown) in the nodes 12, 16 enable the logic solvers 50 to communicate locally with each other to coordinate the safety functions implemented by these devices, transfer data to each other, and / or perform other integrated functions. Similarly, the backplane (not shown) in the node 16 enables the logic solvers 50 to communicate locally with each other to coordinate the safety functions implemented by these devices, transfer data to each other, and / or perform other integrated functions. On the other hand, the MPD 70 operates so that parts of the safety system 14 disposed in widely different locations of the plant 10 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, enables the logic solvers 50 associated with different nodes 12 and 16 of the process plant 10 to be communicatively cascaded together to allow the cascading of safety-related functions within the process plant 10 to be performed according to assigned priorities. The MPD 70 and the bus 74 provide a communication link to the safety system that serves as a replacement for the network 30.

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

[0045] Figure 2 1 is a block diagram schematically illustrating the structure of an exemplary workstation 18a (workstation 20a may include the same or similar devices). Workstation 18a may include at least one processor 100, volatile memory 104, and non-volatile memory 108. Volatile memory 104 may include, for example, random access memory (RAM). In some embodiments, RAM may be backed up by one or more batteries so that data is not lost in the event of a power failure. Non-volatile memory 108 may 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, etc. Workstation 18a may also include a workstation I / O device 112. Processor 100, volatile memory 104, non-volatile memory 108, and workstation I / O device 112 may 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, which may be, for example, one or more of a keyboard, a keypad, a mouse, 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 bus (not shown) separate from the address / data bus 116, or may be directly coupled to the processor 100.

[0046] Display device 120 and user input device 124 are coupled to workstation I / O device 112. In addition, workstation 18a is coupled to network 30 via workstation I / O device 112. Figure 2 1. In some embodiments, one or more of the display device 120 and the user input device 124 may be coupled directly to the address / data bus 116 or to the processor 100.

[0047] Reference now Figure 1 and Figure 2 , a process control configuration application 19 associated with one or more of the control nodes 12, 16 can be stored on and executed by one or more of the workstations 18a and 20a. For example, the process control configuration application 19 can be stored on the non-volatile memory 108 and / or the volatile memory 104 and executed by the processor 100. However, if desired, the application can be stored and executed in other computers associated with the process plant 10. In general, the process control configuration application 19 allows a programmer, control engineer, or other person to create and configure control routines, control modules, function blocks, programs, logic, etc. to be 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. can then be downloaded to the appropriate controllers 12a, 16a, I / O devices 24, and / or field devices 22, 23 via the network 30.

[0048] Similarly, the 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 on 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 and executed in other computers associated with the process plant 10. In general, the safety system configuration application allows a programmer, safety engineer, or other person to create and configure safety-related control routines, safety logic modules, function blocks, programs, logic, etc. to be implemented by the logic solver 50 and / or the devices 60, 62. These control routines, safety modules, function blocks, programs, logic, etc. may then be downloaded to the appropriate controllers 12a, 16a, logic solvers 50, and / or devices 60, 62 via the network 30.

[0049] 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 typically a narrative document that specifies the requirements for control and / or safety actions. In a safety system, safety requirements are documented in a safety requirements specification (SRS). The SRS (described in more detail below) can provide a logical description that can be represented by plain text, a logic diagram, or a cause-and-effect diagram (also called a cause-and-effect matrix). The cause-and-effect matrix (CEM) is a summary of the safety actions provided by the safety system in a simple visual representation. Therefore, the CEM defines the basic cause-and-effect relationships implemented by the safety logic and is the basis for the configuration of the safety logic.

[0050] Figure 3 An exemplary representation of a CEM 300 is shown that can be displayed via any type of display device. In particular, the display device can be part of a user interface associated with the safety configuration application 21, and the display can 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 can be used in a traditional process control system, contains multiple causes and multiple results. The causes of the CEM are generally defined by the safety requirements specification and relate to conditions or conditions at or indicated by 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 can be that the reading of a sensor is: the temperature of a specific area of ​​the plant is outside a safe or predefined range.

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

[0052] In CEM 300, cause-effect relationships are represented by an "X" in each cell, indicating that the effect associated with the cell column is triggered by the cause associated with the cell row. 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 and effect may be related. For example, a trigger may have the following form: an "X" indicating that if the cause is received, the effect will be activated immediately, a "T" meaning that if the cause is received, the effect will be activated with a time delay, a "P" indicating that if the cause is received, the effect will be permissive, and so on. In addition, an empty cell may indicate that a particular cause-effect pair is not currently relevant in the matrix, and therefore may not be active in the plant (i.e., the occurrence of the cause has no triggering relationship with the effect).

[0053] The exemplary CEM 300 is a 7×7 matrix, which may be smaller than a typical cause-effect matrix of a process plant, but is shown in a simplified form for the sake of illustration. The exemplary CEM 300 includes 10 cause-effect relationships represented by an “X” in each cell in the corresponding set of cells. For example, cause 2 (C2) includes an “X” in each cell corresponding to effects 3, 4, and 5 (E3, E4, and E5), respectively. Therefore, if the associated event of cause 2 (C2) occurs, the corresponding actions of effects 3, 4, and 5 (E3, E4, and E5) can be triggered within the process plant by the safety logic module in the plant. However, in some embodiments, each of effects 3, 4, and 5 may also require other associated causes to occur before being triggered. For example, depending on the logic used in the system, before effect 4 is triggered, effect 4 may require one or more of causes 2, 3, 4, and / or 5 to be activated (i.e., because effect 4 has an “X” for each of causes 2, 3, 4, and 5). Therefore, the logic defined by the CEM can be based on "OR" logic (i.e., the occurrence of any one of the causes in the effect column will cause the effect to be triggered), or it can be based on "AND" logic (i.e., every cause in the effect column must exist before the effect is triggered by the safety logic).

[0054] In another embodiment, depending on which causes occur, the result (such as result 4) can be triggered in different ways. For example, if one associated cause occurs, the result (such as result 4) can be triggered on a delay, and if two or more associated causes occur, the result (such as result 4) can be triggered immediately. In addition, some associated causes can activate automatic triggering, while other causes can activate delayed triggering for results (such as result 4). In addition, some associated causes can trigger results independently of other associated causes, while other associated causes can trigger results only when they exist in conjunction 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 by corresponding cause-effect pairs.

[0055] As will be discussed in more detail, the logic defined by the CEM can be decomposed into multiple sets or groups of logic implemented on subsets of causes and effects defined by the CEM, and these different subsets of logic can be implemented by specific functional blocks in the safety logic implementation. For example, the logic defined by the selected logic blocks 305 and 310 shown in the CEM 300 can be implemented using functional blocks. In this case, the logic block 305 will include two cause inputs (C2 and C3) and will correspond to three result outputs (E3, E4, and E5). In this exemplary embodiment, the subset of logic to be implemented by the logic blocks 305 and 310 is identified by simply identifying clusters of populated cells of the CEM 300. Here, the logic blocks 305 and 310, while covering only 12 of the 49 cells of the CEM 300, contain most of the important information (cause / effect relationships) indicated by the CEM 300. In other embodiments, logic blocks 305 and 310 may be made larger and / or another logic block may be added or identified to include the remaining filler cells of CEM 300 that are not included in logic blocks 305 and 310. As will be discussed in more detail below, CEMs may be rearranged to cluster filler cells in a better or more efficient manner to help identify logic blocks and, in turn, create functional blocks. While such clustering may seem like a no-brainer for a given CEM 300, it may be nearly impossible for a human to effectively identify patterns in a CEM having hundreds (or thousands) of cells.

[0056] 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 in a CEM. Therefore, the use of state machine function blocks is limited by the size of their definition, and thus can be proliferated in large numbers. However, unlike conventional systems, the current system organizes CEMs into two types of function blocks: monitoring blocks and result blocks, which are used to reduce logic complexity and increase optimization of logic implementation within a safety system when implementing complex or large CEMs.

[0057] More specifically, separate monitoring blocks and result blocks are used to implement any logical pattern or logical group defined in the corresponding CEM, and the shortcomings of traditional systems are solved by dividing causes and results into two different categories of blocks. Generally, a monitoring block (MB) is an abstract representation of a cause, and a result block (EB) is an abstract representation of a result. In this way, the system can represent a large CEM and its causes and results by linking or otherwise connecting one or more monitoring blocks to one or more result blocks. For example, the output of a set of monitoring blocks can be used as an input to one or more result blocks, and accordingly the input of each result block can be derived from the input from one or more monitoring blocks. In one embodiment, the output of a monitoring block can be used alternatively or additionally as an input to one or more other monitoring blocks. Therefore, monitoring blocks and / or result blocks can be chained, nested, layered and / or graded as needed to best implement any desired CEM logic. In addition, representing (and implementing) CEM as multiple MBs and EBs makes the implementation and maintenance of the safety system easier, and also allows more complex CEM relationships to be easily represented and configured.

[0058] There are many advantages to creating separate monitoring blocks and result blocks. Specifically, MBs and EBs can be sized as needed, which results in a faster and simpler implementation that is less prone to errors. In addition, control or safety systems that use these smaller sized MBs and EBs as functional blocks to implement CEM logic can be more easily tested and troubleshooted (or generally, reverse engineered) due to the transparent description of cause-effect relationships. In addition, large CEMs can be broken down into logic blocks of more manageable sizes. In addition, complex cause-effect relationships are more easily represented by using separate MBs and EBs. For example, hierarchical, looping, nesting, chain connections, etc. can all be depicted using separate monitoring blocks and result blocks.

[0059] Figure 4 is a schematic diagram 400 of a collection of interconnected monitoring blocks and result blocks. Figure 4 The monitoring block and result block set includes (implemented) in Figure 3 The CEM 300 is provided by Figure 3300. Here, monitoring blocks 405 and 410 generally correspond to causes (C2-C5) of logic blocks 305 and 310, while result blocks 415 and 420 generally correspond to results (E3, E4, E5, E6) of logic blocks 305 and 310 or results (E3, E4, E5, E6) associated with logic blocks 305 and 310. For example, monitoring block 1 (MB1) 405 includes causes 2 and 3 of CEM 300 as inputs. However, the outputs of MB1 405 do not directly correspond to results 3, 4, and 5 of CEM 300 (as with logic block 305). In contrast to state machines that are generally created to implement the logic of logic blocks 305 and 310 (which implement direct cause-effect relationships), monitoring blocks may include inputs (such as causes and outputs from other monitoring blocks) and outputs (which may be sent to other monitoring blocks or result blocks), but they do not directly correspond to results. For example, the output of MB1 405 is sent to various other monitoring blocks and result blocks in the set 400. Specifically, the output 401 of the monitoring block MB1 (405) is sent to the result block 1 (EB1) 415, the output 402 of the monitoring block MB1 is sent to the monitoring block 2 (MB2) 410, and the output 403 of the monitoring block MB1 is sent to the result block 2 (EB2) 420.

[0060] The outputs of an MB generally provide information about the corresponding inputs. 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 (logical 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 may be performed on causes C2 and C3 to determine output 402, such as XOR, etc. In a similar manner, output 411 of MB2 410 provides information about three inputs (output 402 of MB1 405, cause 4, and cause 5). In other words, output 411 provides information about causes 2 and 3 (as defined by the logic that produces output 402 of cause block MB1) and causes 4 and 5.

[0061] Referring now to the result blocks 415 and 420, the result block 1 (EB1) 415 receives two inputs, namely the output 401 from the monitoring block MB1 (which depends on the state of reason 2) and reason 6 (corresponding to reason 6 from CEM 300). The result block EB1 (415) corresponds to only one result, namely result 3. Therefore, similar to CEM 300, the result block EB1 (415) associates reasons 2 and 6 to create result 3, which is the output of the result block EB1 (415). As will be appreciated, the result block EB1 (415) can implement any desired logic and delays based on the state of the output 401 (which in turn is related to the state of reason 2) and the state of reason 6 (C6).

[0062] Similarly, result block EB2 (420) corresponds to and implements logic that creates or defines the states of results 4, 5, and 6 of CEM 300. Tracing the inputs of result block EB2 (420) back to the corresponding monitoring blocks, it can be seen that the causal relationships for results 4, 5, and 6 of CEM 300 are affected by result block EB2 (420). In particular, result block EB2 420 receives output 411, which is based on causes 4 and 5 input to monitoring block MB2 and based on output 402 of monitoring block MB1. Therefore, output 411 has a value or state derived from causes 2, 3, 4, and 5 used to trigger result 4 in result block EB2. In addition, result block EB2 receives outputs 403 and 412, which are logically defined by causes 2 and 4 and are used in certain logical expressions to trigger result 5. In addition, result block EB2 receives output 413 that corresponds to or is defined as a logical value based on causes 4 and 5, and uses output 413 to trigger result 6. In turn, Figure 4 The monitoring block and result block set 400 includes Figure 3 The CEM 300 was previously provided or targeted Figure 3 All relationship information (and logic) defined by the CEM 300 of the same. Although the advantages provided by decomposing the CEM 300 into monitoring blocks and result blocks 400 may not be obvious in this example, the advantages are more obvious when decomposing larger CEMs. It should be noted that Figure 4 The depicted monitoring block and result block set 400 is meant as an example only, and monitoring blocks and result blocks may be created and organized in countless sizes and configurations to implement the logic defined by the CEM.

[0063] Figure 5is an example of an illustration of a configuration screen 500 that may be displayed by a display device and that represents or depicts a set of monitoring blocks and result function blocks that implement the logic of a CEM or a portion of a CEM. Configuration screen 500 represents a more detailed function block implementation of the monitoring blocks and result blocks than monitoring blocks and result block set 400, which is intended as a schematic representation of the logic associated with the monitoring blocks and result blocks. Figure 5 In the example of FIG. 5 , the configuration screen 500 includes inputs (reason 508, reason mask 512, and logic type 506), corresponding to Figure 4 The monitoring block MB1 (405) of the monitoring block 502, and the corresponding Figure 4 Result block 504 of result block EB1 (415).

[0064] Monitoring block 502 receives four inputs (IN_D1 and IN_D2, IN_MASK and LOGIC_TYPE) corresponding to two reasons 508, reason mask input 512 and logic type 506 respectively. Logic type 506 defines what type of logic is being implemented in the current monitoring block and result block set. In one embodiment, the logic type can be positive or negative. Positive logic can indicate that all reasons initially start with a "false" state, and if triggered, become "true". Therefore, if one or more reasons are "true", the corresponding output can be "true". In turn, the corresponding result block can receive one or more "true" inputs, which can promote the state of the result block and / or trigger the result block. Negative logic can be similar, but the cause initially starts with "true", and if the cause occurs, it is set to "false". This exemplary logic is not intended to be restrictive, and logic type 506 can also include "and" logic, "or" logic or any other logic that may help to implement monitoring block and result block.

[0065] The reason mask input 512 may represent initial parameters for filtering the reasons 508 received by the monitoring block 502. The monitoring block 502 also includes three configuration masks CFG_MASK 1, CFG_MASK 2, and CFG_MASK 3 510 for configuring the monitoring block 502, where each mask represents which reasons correspond to each output, and in some cases, represents the logic for generating outputs from non-masked inputs. The configuration masks 510 may be numerical representations derived from the CEM, as described in more detail below.

[0066] The monitoring block 502 also includes five outputs (OUT_D1 to OUT_D3 514, RAW_VAL 516, and MASK_VAL 518), one of which (OUT_D1) is used as an input to the result block 504 (eg, Figure 4508). The original value 516 may simply output the value of the received reason 508, while the masked value 518 may output the value of the reason 508 after applying the reason mask 512. In addition, OUT_D1 to OUT_D3 correspond to Figure 4 405 of MB1 405. Configuration mask 510 indicates which reasons correspond to each output. For example, CFG_MASK1 (of configuration mask 510) is set to 'A', which may indicate that only reason 2 (of reason 508) corresponds to OUT_D1 (of output 514). In addition, CFG_MASK2 (of configuration mask 510) is set to 'B', which may indicate that reason 2 (of reason 508) and reason 3 correspond to OUT_D2 (of output 514). In addition, in some cases, configuration mask 510 can be a numerical expression, such as a hexadecimal number, indicating which monitoring block input drives or affects a particular monitoring block output, and / or the actual logic used to generate the block output from the block input.

[0067] like Figure 5 As shown, 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 output 514 of the monitoring block 502 and Figure 3 6 of the CEM 300. The state 526 of the result block 504 may correspond to the operating 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"). When the result block 504 is in an abnormal state, the reset input 522 may allow the user to automatically reset the state of the result block 504 to normal once the necessary actions have been performed. Of course, other state change inputs may also be provided to the result block, such as allowing a reset (e.g., when a cause input or a monitoring block input changes state, etc.). Furthermore, in this case, if one or more of the received inputs 520 are "true", the output OUT_D corresponding to the result 3 of the CEM 300 may be a triggered response because the logic type 506 in this example is set to positive.

[0068] As an example, Figure 5The state of each of OUT_D1 (of block 502), IN_D2 (of block 504), and Out_D when the reason 2 and reason 3 inputs are "false" and the logic type of both blocks 502 and 504 is set to positive is shown. Now, if reason 2 (of reason 508) will occur in the process plant, the state of reason 2 can be changed from "false" to "true". Therefore, MB1502 will receive input IN_D1 as true. Based on the positive logic type at the Logic_Type input and the configuration mask (i.e., CFG_MASK1) for OUT_D1 (output 1), the corresponding output OUT_1 will then become true. In this example, after applying the configuration mask 510, IN_D1 drives or affects the value of each of the outputs 514 (OUT_D1 to OUT_D3). In particular, based on IN_D1 being set to "true", OUT_D1 can be set to "true". Therefore, the state 526 of EB1 504 will then receive at least one "true" input (IN_D1). Therefore, the state 526 of EB1 504 will be changed to "triggered", and the output 524OUT_D of the result block 504 will be set to "true", which means Figure 4 The result 3 of will be triggered or "true". Therefore, this result has been triggered and any corresponding actions and / or alarms in the process control plant can be started.

[0069] Figure 6 6 is another example of an illustration of a configuration screen 600 that may be displayed by a display device and that may represent configuration of a monitoring block and a result block. Figure 6 The example focuses on Figure 4 The monitoring block MB2 and the result block EB2 of FIG. For the purpose of illustration, the logic type 606 is set to negative, which means that when in a normal state, all causes are "true". In the negative logic type, when one or more inputs occur, the state switches to "false", the corresponding output of the monitoring block can be set to "false", and the result block can receive the output as "false" and then trigger the result to set the result to "true".

[0070] In addition, result block EB 604 includes a time delay input 608. In this example, when "20" is input to the Delay_Time 1 input of result block 604, input 1 (IN_D1) of result block 604 can cause output OUT_D to be triggered with a delay (DELAY_TIME1) of 20 seconds. However, because the time delay (DELAY_TIME2) is set to zero, input 2 (IN_D2) of this example can cause 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 set for a particular result block.

[0071] As an example, if Cause 4 were to occur, the state of Cause 4 (and therefore IN_D2) would change to FALSE. Figure 4 , it can be seen that Cause 4 corresponds to or affects each of the outputs 411-413 of the monitoring block 410. Therefore, in this example, Cause 4 (and IN_D2) can drive or affect all of the outputs (OUT_D1 to OUT_D3) of MB2 according to the logic implemented by the configuration mask of the monitoring block 602. In particular, OUT_D1 of MB2 602 can be set to "false". In turn, IN_D2 of EB2 604 will be received as "false". Therefore, when the time delay (DELAY_TIME2) corresponding to IN_D2 of EB2 604 is set to zero time delay, the corresponding result of EB2 604 can be triggered immediately. As an example, if Figure 4 If the output 411 of MB2 410 corresponds to OUT_D1 of MB2 602, then these outputs simply drive Result 4 (of CEM 300), which may be represented as OUT_D1 in EB 604. Therefore, OUT_D1 of EB 604 may now be triggered and set to "true".

[0072] Figure 5 and Figure 6 The exemplary monitoring blocks and result blocks provided in are intended to be simplified for demonstration purposes. For example, although the monitoring block 502 is Figure 5 , but other embodiments may include any desired number of inputs and outputs required based on the functionality of the monitoring block. In one embodiment, the number of inputs IN_Dx and outputs OUT_Dx generally corresponds to the number of inputs and outputs in each logic block of the reorganized CEM. In addition, the system can configure masks so that one monitoring block can be implemented to drive or affect multiple result blocks and additional monitoring blocks. In turn, the CEM can be divided into multiple monitoring blocks and result blocks through layering, looping, nesting, chaining, etc., which can provide the system with greater flexibility to configure the system of the process control plant than traditional state machine implementations.

[0073] Figure 7 700 is a flow chart of an exemplary method 700 for configuring monitoring blocks and result blocks associated with a process plant. The method 700 may be implemented periodically and / or in response to a triggering event (e.g., an instruction or a start signal from a configuration engineer or other user or other safety logic designer). The method 700 may be executed by an electronic device (e.g., a causal analyzer tool 17) that may include a process plant (such as a reference Figure 1 One or more components of the process plant 10) in question.

[0074] At box 710, the electronic device may receive or otherwise access the CEM. In some embodiments, it may be beneficial to rearrange the CEM to remove sparseness and otherwise collect information in clusters of groups before identifying logic blocks. At box 715, the electronic device may automatically rearrange the CEM and / or enable a user to rearrange the CEM. Methods for automatically rearranging the CEM are discussed in more detail below. At box 720, the electronic device may identify and create a set of monitoring blocks and result blocks to implement the logic of the CEM. At box 730, the electronic device may display the monitoring blocks and result blocks to a user, such as a configuration or security logic engineer who may design security or control logic for implementing the CEM. In particular, the electronic device may cause a display device to display a graphical user interface (GUI), wherein the GUI may indicate a first monitoring block, a second monitoring block, and a result block. In addition, each of the first monitoring block, the second monitoring block, and the result block may indicate a plurality of cells arranged in a matrix having a first dimension and a second dimension, wherein the position along the first dimension may indicate an output and the position along the second dimension may correspond to an input, such that the plurality of cells may define an input / output pair based on the positions of the plurality of cells relative to the first dimension and the second dimension.

[0075] In box 740, the electronic device may configure or may enable a user to configure the monitoring block and the result block to implement the logic of the CEM. In one embodiment, the electronic device may enable a user to input configuration data via an input device. In another embodiment, the electronic device may automatically determine or generate configuration data by parsing the CEM. Depending on the implementation, the electronic device may configure one of the outputs of the first monitoring block to be used as one of the inputs of the second monitoring block, may configure another of the outputs of the first monitoring block and one of the outputs of the second monitoring block to be used as inputs to the result block, and / or may specify at least one of the multiple units of each of the first monitoring block, the second monitoring block, and the result block as a trigger that is associated with a corresponding input / output pair of the corresponding unit and corresponds to a condition in the process plant.

[0076] In one embodiment, to configure the monitoring block and the result block, the electronic device may incorporate at least one additional monitoring block having an additional plurality of cells defining additional input / output pairs, configure at least one output of the additional monitoring block to serve as an input to at least one of the first monitoring block, the second monitoring block, and the result block, and designate at least one of the additional plurality of cells as an additional trigger associated with a corresponding additional input / output pair of the corresponding additional cell and corresponding to an additional condition in the process plant. In another embodiment, to configure the monitoring block and the result block, the electronic device may incorporate at least one additional result block having an additional plurality of cells defining additional input / output pairs, configure at least one input of the additional result block to correspond to an output of one of the first monitoring block or the second monitoring block, and designate at least one of the additional plurality of cells as an additional trigger associated with a corresponding additional input / output pair of the corresponding additional cell and corresponding to an additional condition in the process plant.

[0077] In addition, in one embodiment, in order to configure the monitoring block and the result block, the electronic device can configure an input for each of the first monitoring block and the second monitoring block, can configure an input mask for at least one of the first monitoring block and the second monitoring block, the input mask is logically associated with the input of at least one of the first monitoring block and the second monitoring block, can designate at least one trigger as a time delay trigger so that the associated result is activated with a time delay, and / or can designate at least one trigger as a permission trigger.

[0078] In block 750, the electronic device may store the configured monitoring blocks and result blocks. In particular, the electronic device may store the configuration data on 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 also display multiple units of each of the first monitoring block, the second monitoring block, and the result block on a display device, and may indicate corresponding triggers within the corresponding multiple units.

[0079] Of course, method 700 can create any number of monitoring blocks and result blocks, which are connected together in any number of ways to use these interconnected monitoring blocks and result blocks to implement the logic of CEM. Each monitoring block can include any number of reasons of CEM or any subset of reasons as its input, and can include inputs bound to the outputs of other monitoring blocks, thereby affecting the monitoring blocks of cascade. In addition, any result block can determine one or more results from the input set, and can receive any output and / or any reason input of the monitoring block as input. In addition, method 700 can interconnect or enable users to interconnect each monitoring block and other monitoring blocks and result blocks (that is, define the connection between each monitoring block and other monitoring blocks and result blocks). In this way, each monitoring block includes logic, which determines one or more intermediate logic conditions or signals based on one or more cause signals (directly input to the monitoring block or input to the monitoring block in the form of another intermediate logic signal formed by the cause signal input to another upstream monitoring block). Similarly, each result block produces one or more result signals based on its input set, wherein such input is the cause signal and / or intermediate logic signal output from one or more monitoring blocks. In this way, method 700 enables intermediate logic signals to be formed in one or more monitoring blocks that represent certain logical combinations of cause signals, and to provide or use the intermediate logic signals as inputs to one or more result blocks, thereby simplifying the configuration, size, and logic implemented by the result blocks to create the result signals.

[0080] For smaller CEMs, it is possible that a safety engineer manually rearranges and / or configures the CEMs at block 715 of method 700, such as by identifying patterns or by attempting to group related causes and effects. Such rearrangement may be manually accomplished by a user via a graphical user interface, who moves or rearranges individual rows and / or columns of the CEMs to group cells that define cause-effect relationships (e.g., cells marked with an X) closer to one another or to form denser groupings. However, there are a variety of ways to reorganize large CEMs, and it is beneficial to determine the best options for reorganization. Therefore, there is an opportunity to dynamically and automatically analyze and reorganize CEMs associated with a process control system.

[0081] In one embodiment, the system (ie, Figure 1 A computer system (e.g., a computer system) may implement the causal analyzer tool 17 to automatically reorganize a large CEM based on a set of rules. In one embodiment, the rules 31 may be stored in Figure 1The analyzer tool 17 may analyze the CEMs to determine the most appropriate or optimized configuration of the CEMs given the rule set 31 (i.e., the best way to rearrange the CEMs to produce a set of monitoring blocks and result blocks). The rule set 31 may be specified by an engineer or automatically generated by a computer (e.g., the analyzer tool 17) based on the current needs or configuration of a particular process plant. For example, the rule set 31 may indicate that the CEMs should be organized into groups where certain causes and / or results are grouped together based on the corresponding logic solver 50, MPD 70, and / or field devices 22, 23, 24, 60, and 62 in which the logic is to be implemented. In addition, the rule set 31 may indicate that the CEMs should be reorganized to remove sparsity based on a particular pattern, based on the efficiency of the system, and / or based on other criteria. In another embodiment, the rule set 31 may indicate that certain causes and / or results (or groups of causes and / or results) are not moved. In another embodiment, the rule set 31 may indicate the weights of specific causes and / or results that need to be reorganized, which are used to resolve conflicts when trying to apply multiple rules that result in different results.

[0082] In one embodiment, the rule set 31 may indicate that the CEM is to be reorganized into a specific number of groups and / or groups of a specific size. The rule set 31 may also indicate the manner in which the groups are organized. For example, the rule set 31 may indicate that each group should contain a specific number, a specific maximum number, or a specific minimum number of causes and / or results. In one embodiment, the rule set 31 may indicate that the groups should not contain overlapping causes and / or results. The rule 31 may also specify that certain causes or results should be grouped together because, for example, these causes will be detected by a specific logic solver or detected in a specific node, or the result may need to be implemented by a specific logic solver at a specific node. In any case, once the CEM is reorganized, the rule set 31 may also enable engineers to manually configure specific causes and / or results in the CEM. It should be understood that alternative or additional rules may be conceivable.

[0083] In one implementation, the analyzer tool may receive or generate a rule set 31 indicating that only certain causes and / or effects corresponding to certain areas of the process plant should be reorganized, or should be reorganized together or reorganized into groups. Similarly, the rule set 31 may indicate that only a certain subset of the causes and effects of the CEM should be reorganized. The analyzer tool may also receive or generate a rule set 31 that "locks" certain rows and / or columns to prevent the received rows and / or columns from being moved during the reorganization. In addition, the analyzer tool may receive or generate a rule set 31 indicating that causes corresponding to positive logic (i.e., if the cause is "on", the effect is activated) should be grouped together and causes corresponding to negative logic (i.e., if the cause is "on", the effect is not activated) should be grouped together. Other ways of grouping or reorganizing CEM rows and columns based on the type of logic defined in the CEM unit (i.e., the type of logic to be implemented) may also be used.

[0084] Accordingly, the reorganization of the CEMs may require a multi-part analysis that may be implemented by a computer and may be based on the rule set 31. The computer may analyze the CEMs 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 element that is most suitable for implementing the rule set 31. For example, Figure 8 is Figure 3 800 is a significantly larger exemplary CEM than the previous exemplary CEM 300. CEM 800 includes a plurality of filler cells dispersed throughout the matrix. Although CEM 800 is only slightly larger than CEM 300, it is apparent that the problem of identifying logical blocks or logical groups in CEM 800 that are to be implemented by a set of monitoring blocks and result blocks is increasingly complex. Furthermore, CEM 800 includes filler cells dispersed from larger groupings, which increases the difficulty of effectively selecting logical blocks to be used to generate monitoring blocks and result blocks. The difficulty of manually selecting or defining logical blocks becomes significant with increasing sizes of CEMs.

[0085] Fig. 9 An example of a display depicting a CEM 900 is shown. Figure 8 A reorganized version of the CEM 800. Fig. 9As shown, CEM 900 has been organized to include three primary groups or logic blocks: 901, 902, and 903. In an exemplary embodiment, each of logic blocks 901, 902, and 903 may correspond to a specific logic solver 50 within a process plant. In another embodiment, the computer may have identified logic blocks 901-903 based on criteria defined within rule set 31.

[0086] For example, Fig. 9 Logic block 901 may correspond to a set of results that all belong to a particular physical location of a process plant (e.g., a particular heating section) or that will be implemented by the same controller or logic solver in the plant control system. In addition, logic block 902 may be derived by the analyzer tool by removing sparsity from the CEM by identifying groups in which all causes are related to all results. In particular, in logic block 902, each of causes 4-10 is paired with each of results 3-5. Logic block 903 may correspond to a group of negative logical causal relationships. Although the exemplary CEM 900 includes three logic blocks, the CEM may be decomposed into any number of logic blocks and based on any of the above rules 31, or any combination or rules 31 or any other rules not mentioned above that may be used by the analyzer tool 17 in analyzing and reorganizing the CEM. As described above with respect to Figure 3 and Figure 4 As described, logic blocks 901, 902, and 903 may each be used to define a set of interconnected monitoring blocks and result blocks to implement the logic of these portions of the CEM.

[0087] Fig.10 1 is a flow chart of an exemplary method 1000 for rearranging a cause-effect matrix and defining and / or managing logic blocks to be used to develop a CEM of safety or control logic for a process control system. The method 1000 may be implemented periodically and / or in response to a triggering event, such as during configuration of a plant, whenever a CEM of logic is changed or updated, etc. The method 1000 may be implemented by an electronic device (e.g., Figure 1 Analyzer tool 17) is executed, and the electronic device may include a process plant (e.g., reference Figure 1One or more components of the process plant 10 discussed. At box 1010, the electronic device can access an initial cause-effect matrix having an input set and an output set (i.e., a cause set and a result set). In an embodiment, each input in the input set can represent a condition within the process plant, and each output in the output set can represent a result to be performed within the process plant. In addition, at least some of the input set and the output set can be related as a cause-effect pair, whereby the corresponding result can be activated in response to the occurrence of the corresponding condition. The initial cause-effect matrix (CEM) can be stored in a data repository in the process control plant, or can be generated by a user at an electronic device for configuring a new process in the plant. The initial CEM can also be received from a database outside the process control system. In some embodiments, the initial CEM can be accessed only by engineers with appropriate credentials, and therefore a login or other password may be required to authorize access to the initial CEM.

[0088] The electronic device may define each group in the set of related groups within the initial CEM. In particular, at box 1020, the electronic device may access a set of rules 31 associated with the set of related groups. In particular, the electronic device may access the set of rules 31 through one or more databases inside or outside the process control system. The electronic device may also receive the set of rules 31 as input provided by an engineer of the process control plant. In addition, the set of rules 31 may be a combination of various rules accessed through various databases and / or inputs. As discussed in detail above, the purpose of the set of rules 31 is to be able to reorganize the CEM in an effective and efficient manner.

[0089] In one embodiment, a rule may specify that a specified portion in an output set must be within the same related group. In another embodiment, a rule may specify that portions of an input set must be numbered a certain number. In yet another embodiment, a rule may specify that both an input set and an output set should not overlap among a related group set. Of course, any other desired rule may be used.

[0090] At box 1030, the electronic device can identify a portion of the input (cause) set that is associated with a portion of the output (result) set based on a set of rules as defined by corresponding cause-effect pairs defined in the CEM. In addition, at box 1040, the electronic device can rearrange the portion of the input set and the portion of the output set so that the portions of the corresponding cause-effect pairs are rearranged. Box 1040 can perform this rearrangement to define one or more functional block logical units that will be implemented using the monitoring block and result block sets (as defined above). Box 1050 can analyze the rearranged CEM and determine whether the process is complete, and if not, provide control to box 1030 to identify other rules to be used to rearrange the CEM, further attempting to optimize the creation of monitoring blocks and result blocks based on the rearranged CEM. In addition, when the rearrangement is complete, box 1050 can define logical blocks or logical groups within the rearranged CEM, such as Fig. 9 Three logical groups 901, 902 and 903.

[0091] In one implementation, the electronic device may further configure one or more function block logic units for the process control system based on the set of related groups defined by block 1050. Additionally or alternatively, for each related group in the set of related groups, the electronic device may automatically calculate a numerical representation of the related group or a portion of the related group based on the rearranged cause-effect pairs, such as by calculating the following reference Figure 11-Figure 12 The hexadecimal representation of the relevant groups is discussed in more detail.

[0092] Once the Analyzer Tool has reorganized the CEM 900, the system can further decompose the CEM 900 into separate logical groupings to further increase efficiency in creating monitoring blocks and result blocks that implement those logical groupings. Fig.11 Depicted Fig. 9 In particular, the system can analyze Fig. 9 The CEM 900 of the rearranged CEM 900 can be used to generate various numerical representations 1101, 1102, and 1103 that can be used by the system to configure the functional blocks as a collection of interconnected monitoring blocks and result blocks. In one embodiment, each of the numerical representations 1101-1103 can represent or define an output or result as a value such as a hexadecimal value based on the configuration of the logical relationship defined by the cause and effect pairs defined by the rearranged CEM 900. This numerical value is in contrast to the traditional system that represents each column as a logical expression. However, such a traditional system is inefficient due to the difficulty in implementing or understanding logical expressions.

[0093] In one embodiment, the system can designate a numerical representation by assigning one of two values ​​(e.g., ON or OFF, 1 or 0, etc.) to each cell in the matrix and then converting each bit group (e.g., four binary digits) of a row or column of the CEM into a hexadecimal digit. Fig.11 As shown, the numerical representation 1101 of output 14 is the hexadecimal representation (FE08) of the cell associated with output 14, where an X in a cell is considered a binary "1" and an empty cell is considered a binary "0". This calculation can be demonstrated by decomposing output 14 into 4-bit groups (which are divided by thicker lines between cells and make up four bit numbers from top to bottom: 1111, 1110, 0000, 1000), and then converting each bit group into a hexadecimal number. In this case, the numerical representation 1101 of output 14 is FE08 because in hexadecimal numbers, F=1111, E=1110, 0=0000 and 8=1000. In the same way, the numerical representation 1102 (07E0) corresponds to output 5 because, from top to bottom, output 5 can be decomposed into bits 0000, 0111, 1110, 0000, which convert to the hexadecimal number 07E0. In a similar manner, output 17 can be represented as the hexadecimal number 0072 (numerical representation 1103). The exemplary numerical representation is not intended to be limiting, and some or all of the columns and / or rows may be assigned numerical representations. Furthermore, the numerical representation does not necessarily have to be a hexadecimal conversion, and may be performed in any other suitable form.

[0094] There are many benefits to developing numerical representations for certain groups of logic cells within a CEM. In particular, column-to-hexadecimal conversions are simpler, require no additional gates or programming to generate the expressions, take up less memory to store, and use less bandwidth to communicate with function block inputs than with conventional systems. In addition, hexadecimal value inputs can be more easily error-corrected as needed to ensure accuracy, see below. Fig.15 The test matrix is ​​discussed in detail.

[0095] The numerical representation can further enable the system to configure the cause and effect relationships of the security system configuration environment. In particular, the numerical representation can enable the system to define the relationship between a large number of causes and effects. In addition, the numerical representation can help eliminate configuration errors by distilling entire rows and / or columns into a single numerical value. In addition, the numerical representation can provide a simple and effective way to identify changes in cause / effect relationships and further reduce the effort required to manage changes in CEM.

[0096] For example, numerical representations may be implemented as function blocks such as Figure 4-Figure 6The numerical representations may define which inputs correspond to each specific output and thus de-associate (i.e., mask) the inputs that do not correspond to that specific output. For example, Fig.11 The numerical representation 1101 of result 14 in may disassociate all causes 6-13 from result 14. In other words, the monitoring block may receive all causes 1-16, but only causes 1-5 and 14-16 are associated with result 14 if the numerical representation 1101 is implemented as a mask.

[0097] In addition, when the range of possible cell values ​​is greater than 2 (e.g., when a cell can define multiple different triggers, such as no value, X, T (indicating a time delay), P (indicating a permission reason), etc.), the system can adjust the numerical representation. For example, for an exemplary range of four possible crosspoint values, the system can perform two hexadecimal conversions to generate the resulting numerical representation. In other words, the four possible different values ​​of each cell can be represented as one of the four possible values ​​of a two-bit number, which means that each cell will be defined by a two-bit value instead of a one-bit value, such as Fig.11 In this case, each set of two adjacent cells of the string will form a four-bit value, which can be converted into a hexadecimal number. Therefore, the numerical representation in this scenario will be Fig.11 The numerical representation shown is twice as long, but will be more dynamic as it may represent a greater number of potential logic expressions to be used in the logic implementing the CEM. Alternatively, the system may calculate the numerical representation using a suitable base other than base 16, and may then optionally convert the numerical representation (if necessary) to a hexadecimal input value for a function block (i.e., monitor and result blocks).

[0098] Fig.12is a flow chart of an exemplary method for creating / calculating numerical representations of values ​​or elements within a CEM. At box 1210, the causal analyzer tool 17 may access the CEM. In an exemplary embodiment, the CEM may be rearranged before continuing. At box 1220, the tool 17 may identify a subset of causes. In one embodiment, as described above, the subset of causes may belong to a specific logic block and / or be defined by a set of rules. Next, at box 1230, the tool 17 may define a single-dimensional matrix for the subset of causes. The single-dimensional matrix may correspond to a specific result of the CEM. Next, at box 1240, the tool 17 may calculate a numerical representation of the single-dimensional matrix. As described above, the tool 17 may convert the single-dimensional matrix into a binary string and / or multiple binary strings. In one embodiment, the tool may then convert one or more binary strings into a hexadecimal representation or any other suitable numerical representation. The calculated numerical representation may be stored as a numerical representation 33 in a repository (such as Figure 1 configuration database 32).

[0099] The numerical representation 33 may then be used to configure a set of functional blocks (eg, monitoring blocks and result blocks) at block 1250. For example, as described above, the numerical representation 33 may be implemented as a configuration mask in one or more monitoring blocks.

[0100] In another aspect of the system described herein, a system navigator application provides the user with the ability to quickly navigate between different user interface screens that provide relevant safety information for the process plant. Such information can be found in the CEM, monitoring blocks and results blocks, safety documents, and system configuration displays. In some embodiments, these different user interfaces provide different visual representations of the same safety logic. Thus, the present invention provides ( Figure 1 ) navigator tool 15 to navigate between sets of interlinked user interfaces. For example, Fig.13 is an exemplary illustration 1300 of a set of interlinked user interfaces.

[0101] 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 a narrative document that specifies requirements for control and / or safety actions for a process plant. In other exemplary process plants, such as a safety instrumented system (SIS), safety requirements are documented in a document called a safety requirements specification (SRS).

[0102] One of the inputs to the SRS is a list of identified safety instrumented functions (SIFs). Each SIF prevents a specific hazard and provides a defined level of risk reduction. A SIS is made up of one or more SIFs. In some embodiments, some safety systems combine all SIFs in a SIS configuration without distinguishing each individual SIF. In addition, some safety systems follow a SIF approach and allow SIS configuration based on SIFs.

[0103] An SRS typically includes different parts. One of these parts is a logical description that can be represented by plain text, a logic diagram, or a cause-effect diagram (i.e., a cause-effect matrix). As mentioned, some safety systems combine all SIFs in a SIS configuration, and CEM visualization can be very convenient in implementing such an embodiment.

[0104] In one embodiment, the navigator application 15 may allow an engineer to select a given cause (and / or result) within the CEM to navigate to a specific document describing the selected cause (and / or result). For example, selecting a cause may redirect to a specific SIF description in the SRS. This feature allows engineers to view specific safety logic associated with causes and / or results. In one embodiment, engineers are also able to select a safety module (system configuration) associated with a given SIF, and may then be redirected to a user interface that displays the appropriate SIF from the CEM. In addition, engineers may select an element of the CEM and be redirected to a display of a system configuration that highlights devices, logic blocks, function blocks, monitoring blocks, and result blocks, etc., related to a specific element of the CEM. From a safety or control module, the user may also be redirected to an appropriate section in the SRS or control narrative. In other words, the system may allow engineers to seamlessly switch between views of the CEM, SRS, or system configuration.

[0105] For example, if an engineer is displaying the CEM 1310 Fig.13 1320, the engineer may be redirected to a display screen 1320 showing a system configuration including specific equipment related to the selected cause and / or result of the CEM. For example, the system configuration 1320 may include symbols for tanks, valves, transmitters, pumps, pipes, sensors, etc. related to the selected cause and / or result of the CEM. In this example, the thermometer icon 1321 is highlighted, indicating that the selected cause and / or result corresponds to a temperature sensor reading.

[0106] Additionally, from the CEM 1310 or system configuration 1320, engineers can access documents (such as the SRS 1330) that describe the safety protocols for the process plant. Fig.13An exemplary display 1330 of a portion of a safety requirement specification is shown, including icons 1331 and text 1332 describing the relevant safety process. The navigator application 15 allows the engineer to switch between displays, providing the engineer with information and insights that were previously difficult to obtain. In addition, from any of the interfaces 1310, 1320, and / or 1330, the user can access a user interface 1340 that displays a collection of monitoring blocks and result blocks (e.g., other functional blocks or logic) that include logic to implement the relevant selected element (of the CEM 1310).

[0107] In an exemplary embodiment, an engineer may right-click an element of CEM 1310 (or SRS 1330, system configuration 1320, or monitoring and results block 1340) to access a drop-down menu. The drop-down menu may provide the engineer with options including access to other display views (such as 1310, 1320, 1330, and 1340) and / or other views (such as those described below). Fig.16A -D) option.

[0108] A user may easily navigate from the CEM 1310 (or from individual elements, causes or effects of the CEM 1310) or the system configuration 1320 to specific sections within the requirements specification (SRS 1330), such as definition of a general bypass philosophy, verification test requirements, etc.

[0109] This capability will provide seamless conversion back and forth between configuration and design documents to facilitate configuration validation, change management, troubleshooting and proof-of-concept testing.

[0110] Fig.14 A block diagram of an exemplary method 1400 for implementing access to information included in a safety requirements specification (SRS) of a process plant controlled by a process control system is depicted. The method 1400 can be readily implemented by a server or any type of electronic device, wherein the server can be equipped with or connected to a user interface configured to display content. The SRS can be stored in a memory accessible to the server.

[0111] The method 1400 may begin at block 1410, where the server may display the CEM in a user interface. In an embodiment, the (CEM) may include a set of elements including a set of causes and a set of results, wherein each cause in the set of causes may represent a condition within a process plant, and each result in the set of results may represent a result to be performed within the process plant. Furthermore, at least some of the set of causes and the set of results may be related as cause-effect pairs, whereby corresponding results may be activated in response to the occurrence of corresponding conditions.

[0112] At block 1420, the server may receive a selection of an element in the set of elements via a user interface. In particular, the server may receive a selection of a cause in the set of causes or a selection of a result in the set of results. In response to receiving the selection, at block 1430, the server may access a set of information associated with the elements of the set of elements from the SRS. In particular, the server may access a set of information associated with the selected cause or the selected result 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.

[0113] At box 1440, the server may display the information set in a user interface. In one embodiment, the server may also initiate an application configured to display security logic associated with the selected element via the user interface. Further, in one embodiment, the server may receive, via the user interface, an additional selection of a portion of the information set displayed in the user interface, access an additional information set associated with the portion of the information set from the SRS, and display the additional information set in the user interface. Further, in one embodiment, the server may receive, via the user interface, a selection of an additional information set displayed in the user interface, wherein the portion of the information set may correspond to an additional element in the set of elements of the CEM, and may display the CEM and an indication of the additional element in the user interface.

[0114] In some embodiments, large CEMs may contain thousands of cause-effect pairs. Therefore, these large CEMs may be decomposed into hundreds of monitoring blocks, result blocks, and numerical representations. Due to the large amount of information spread across numerous data structures, users may not be able to manually check whether the safety logic of the process control system is being accurately implemented. Previous process control systems lacked means for strictly verifying whether the configured process control system meets the required safety protocols. In other words, previous systems did not have a way to test the accuracy of CEMs and function blocks implemented to manage the safety of process plants. 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.

[0115] In one aspect, the causal analyzer tool 17 can automatically traverse the configuration of the process plant (or a portion thereof) to generate one or more test CEMs for the as-built or as-configured system. In one embodiment, the tool 17 can build the test CEMs by reverse engineering based on the functional blocks (i.e., monitoring blocks and result blocks) and numerical representations of the safety logic of the currently implemented process plant. The test CEMs can then be compared to the requirements defining the CEMs (CEMs that are known to be accurate representations of the safety logic required by the process plant). The comparison can reveal differences or other errors that can then be presented to the user.

[0116] Fig.15 is a block diagram of an exemplary method for verifying the safety logic of a causal matrix. At block 1510, the analyzer tool 17 may determine the configuration of one or more functional blocks representing the safety logic of the causal matrix. In one embodiment, as described above, the functional blocks are monitoring blocks and result blocks that include inputs, outputs, and numerical representations. The causal analyzer tool 17 may traverse the inputs and outputs of the monitoring blocks and result blocks (MEBs) while considering several factors (such as the logic implemented in the MEB and / or the numerical representation of the MEB) to determine the configuration of the MEB. For example, the tool 17 may receive the above Figure 5 and Figure 6 The tool 17 may start at the output of the result block and traverse the input of the result block to the input source (i.e., the cause directly fed back into the result block and / or the output of the monitoring block). The tool 17 may then trace the output of the monitoring block to the corresponding input of the monitoring block based on the numerical representation. The tool 17 may continue this process of iterating through the MES for each result until each relationship of each cause-effect pair has been identified.

[0117] At block 1520, the tool 17 may generate a test CEM based on the determined configuration. Based on the determined configuration of the monitoring block and the result block, the tool 17 may populate the test CEM with the identified cause-effect pairs. Once the test CEM is created, the tool 17 may store the test CEM 37 in a data repository such as Figure 1 The test CEM 37 may be implemented as any of the CEMs described herein.

[0118] At block 1530, the tool 17 may access the CEM for the requirement definition. In one embodiment, the CEM 35 for the requirement definition may be stored in a data repository such as Figure 1In other embodiments, the tool 17 may create a requirement-defined CEM based on the current configuration of the equipment in the process plant and the SRS and other safety documents. In one embodiment, the requirement-defined CEM 35 may include a set of causes and a set of effects, where the relationship of the cause-effect pairs is based on the safety requirements of the process plant. The requirement-defined CEM 35 may be implemented as any of the CEMs described herein.

[0119] At block 1540, the tool 17 may compare the test CEM 37 to the requirement-defined CEM 35 to determine if there are any differences. The differences may include any differences between cause-effect pairs from the test CEM 37 to the requirement-defined CEM 35. For example, the cause-effect pairs may not be related to each other by the same trigger type (e.g., permissive, immediate, delayed) and / or the same logic type (and / or).

[0120] The tool 17 may display any of the one or more determined differences. In one embodiment, the tool 17 may highlight Fig.13 and differences in any of the user interfaces described in Figures 16a-d. In other words, the tool 17 may highlight where incorrect logic is being implemented in the CEM, monitoring blocks and results blocks, SRS documents and / or system configuration user interfaces.

[0121] About the above Fig.13 and Fig.14 In addition to the functionality discussed above, it may also be beneficial to view the status history, causes and / or results of one or more devices in a process plant. Another aspect of the present invention provides a user interface view for monitoring the safety system status of a process control system, where the status is generally based on or "keyed on" to physical devices and / or safety test results, and the current and past status of various causes or results can be depicted to provide the user with some ability to see when and how CEM logic was implemented in the plant. For example, an engineer can call up a view showing a specific device or piece of equipment or group thereof (as described above with respect to Fig.13 discussed), which view can then be used to further access information presenting the current and / or past security status of each piece of monitored equipment / equipment, cause signals indicated thereon, result signals, etc. (e.g., Fig.16A -D). Additionally or alternatively, a safety engineer may run a safety test on a specific physical device / piece of equipment in the plant, and the results may be displayed on a display view (e.g., Fig.16A-D). Prior systems do not allow engineers to quickly monitor and assess the overall safety status of a plant (or a desired area of ​​a plant) without having to access numerous different display views of the physical equipment / equipment, or by having to run specific diagnostics to obtain test results. Prior systems are not only inconvenient for engineers, but also during emergency situations, valuable time is wasted when the engineer is forced to wade through multiple views or run tests in order to obtain or find the status data that he or she is interested in.

[0122] The systems and methods described herein provide an easily accessible display view of the current status and / or status changes of monitored security events (rather than of a specific device, equipment, or test result). The system aggregates the entire system-wide or region-wide security event / input status into a single display view or visualization, captures changes in security event status over time, and links the visualized security events on the entire security display view to the device / equipment / test result.

[0123] "Security event" is a logical representation of a monitored condition. In an exemplary embodiment, each monitored input (cause) of the CEM can be a monitored security event. In addition, each result can be a monitored security event. It is expected that the corresponding state and / or corresponding state change of each security event to be monitored is represented by different objects / items / graphic items on the security event visualization view. For example, each monitored event can be represented by a colored point, where different colors represent different current states (e.g., red-bad, blue-attention, black-OK). Additionally or alternatively, changes in the current state (binary and / or degree of change) can be represented, for example, by different colors or representations. These states and / or changes in state can be captured and saved over time. In fact, the display view can provide a rolling snapshot of time for the monitored events, and can include different parts for security events monitored at different rates (e.g., every 2 minutes, every 20 minutes, every 2 hours).

[0124] Fig.16A -D is an exemplary diagram of the status change of security events over time. Fig.16A -D, event E1 is a monitored security event. The current security status of E1 over time can be represented as a running line shape along the time axis on the display view, where each shape represents a different state (such as Fig.16A In the diagram 1600, a circle represents a normal state, a square represents a caution state, and a triangle represents a dangerous state. Alternatively, the change of the E1 safety state over time can be represented based on the time point at which the change occurs. For example, Fig. 16B, graph 1610 depicts a steady state (or no state change) with "0", a decrease in the safety state with "-", and an increase in the safety state with "+". It should be understood that the safety state and changes therein may be represented in any type of numerical or graphical form. Fig. 16C A chart 1620 showing the status as numbers is shown, where each negative increment from 0 represents an additional degradation of the status. If desired, the degree of change in the security status can be represented. For example, the y-axis of the chart can indicate the range of normal degradation, and the security status over time can look like a line graph or Fig.16D 1630. Additionally, a single line of colored running dotted lines of monitored events may slowly change / fade from one color to another, thereby indicating a deterioration and / or improvement in the safety status.

[0125] The above examples are not intended to be limiting, and any combination of numbers, symbols, colors, graphics and / or lines may be displayed to enable engineers to assess the safety level of monitored events. In addition, if desired, the state of various events and / or changes in state may be stored for post-processing.

[0126] In one embodiment, one or more graphs may be displayed in concert and / or in unison. Desired groupings of monitored events may be displayed in close proximity—e.g., by plant area, by function, by sensitivity to certain conditions or factors (e.g., during certain stages of a batch process), etc. An engineer may be able to mask the display view to be able to view specific safety events of interest at a glance.

[0127] In addition, visualization can be provided for more abstract security events.As discussed above, a monitored security event can be an abstraction of a set of monitored events, such as a monitoring block and a result block.

[0128] For example, refer to Figure 5 and 6 , the enablers or direct inputs into result blocks EB1 and EB2 may be monitored security events and / or each result E1, E2, etc. of result blocks EB1 and EB2 may be monitored security events. Each condition or input that constitutes each desired monitored event may contribute to the degree of change in its state. For example, if a monitored event requires four conditions in order to trigger the event, then when one condition exists, the state of the monitored event may be "-1", when two conditions exist, the state of the monitored event may be "-2", when three conditions exist, the state of the monitored event may be "-3", and when all four conditions exist, the state may be "X" or "touched". Therefore, as an example, Figures 16A-16DSymbols, numbers, dots, etc. can represent different possible states of the result (or cause), or can represent the number of causes that are set to the true state or are in the true state among the total number of causes that need to be set to the true state or are in the true state to trigger or start the result signal.

[0129] In addition, a click or other user indication on a particular security state or state change indicator may automatically link the user to the details of the corresponding condition. As described above, an engineer may access the SRS, system configuration, and / or CEM display from the security event visualization diagram. For example, and with reference to the above example of the four conditions required to trigger a monitored event, if the security visualization indicates "-1" for the above exemplary monitored event of diagram 1620 and the user clicks on "-1", a display view of the system configuration of the device or piece of equipment including the condition that caused the security state corresponding to "-1" may be displayed.

[0130] Fig.17 A block diagram of an exemplary method 1700 for visualizing security events within a process plant is depicted. The method 1700 may be readily implemented by a server or any type of electronic device, where the server may be equipped with or connected to a user interface configured to display content.

[0131] The method 1700 may begin with the server accessing (block 1710) a CEM having a set of causes and a set of results. In an embodiment, each cause in the set of causes may represent a condition within a process plant, and each result in the set of results may represent a result to be performed within the process plant. Furthermore, at least some of the set of causes and the set of results may be related as cause-effect pairs, whereby corresponding results may be activated in response to the occurrence of corresponding conditions, and the set of causes and the set of results may represent a set of monitored security events within the process plant.

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

[0133] The server may detect (block 1740) a change in state for the monitored security event. In one embodiment, the server may detect the change in state in response to the expiration of a time period. Based on the change in state, the server may also display (block 1750) an updated state of the monitored security event in a user interface. In one embodiment, the server may display the updated state as one or more second graphical objects that may be different from the one or more first graphical objects. Additionally, in an embodiment, the server may determine a degree of change between a current state and an updated state of the monitored security event, and may display the degree of change in the user interface.

[0134] In one embodiment, the server may also determine, in response to the expiration of the time period, that the update status of the monitored security event has not changed, and may display the update status of the monitored security event in the user interface. Additionally or alternatively, the server may receive a selection of the update status of the monitored security event via the user interface, wherein the monitored security event may have an associated set of conditions, and may display the condition status for each condition in the associated set of conditions in the user interface. Additionally or alternatively, the server may receive a selection of the update status of the monitored security event via the user interface, wherein the monitored security event may have an associated condition that exists, and may display an indication of a device within the process device that caused the associated condition to exist in the user interface.

[0135] Additionally or alternatively, the server may store in memory data representing monitored security events, current states of monitored security events, and updated states of monitored security events. Additionally or alternatively, the server may display in a user interface (i) additional indications of additional monitored security events of the set of monitored security events, and (ii) additional current states of additional monitored security events, detect additional state changes for additional monitored security events, and display in the user interface additional updated states of additional monitored security events based on the additional state changes.

[0136] The exemplary CEM provided above is a simplified representation intended for illustration purposes. Fig.18 An exemplary CEM 1800 is shown as a more complex CEM that includes a time-delayed trigger, a permissive trigger, an immediate trigger, and a reset trigger. CEM 1800 is a more substantial example of a CEM that is a more accurate representation of a real-world CEM. Fig.18In the illustrated CEM 1800, cells containing only "X" may indicate an immediate triggering effect. Additionally, any cell populated with only "R" may indicate that the effect will be triggered to reset if a cause is received. Cells of the CEM 1800 that begin with the letter "T" may indicate that the cause directly triggers the effect, but with a time delay. The time delay may be set in predetermined increments. For example, "T1" may correspond to a time delay of 10 seconds, "T2" may correspond to a time delay of 20 seconds, etc.

[0137] CEM 1800 also contains cells that contain only numbers, whereby these cells may correspond to "enablers". In particular, the number in the cell identifies the group to which the enabler belongs, where there may be one or more enablers for each group. Cells in CEM 1800 that begin with a number and have other characters may represent a relationship where the result is triggered only if the enabler is also triggered. In some embodiments, each cell associated with the corresponding enabler (or multiple enablers) must be "on" in order for the result to be triggered. In other embodiments, any combination of causes in a particular enabler group may be combined to trigger the result. Similarly, any combination of enablers may be required to trigger the result.

[0138] For example, in Fig.18 In the illustrated CEM 1800, cause 1801 is an enabler of Group 1. Therefore, if cause 1802 is triggered, the corresponding effect may not be triggered unless cause 1801 is also triggered. This causal relationship is considered a permissive relationship because the effect is only triggered when the enabler is "on." Continuing with this example, cell 1803 indicates that the causal relationship belongs to enabler Group 1, and when cause signal 1802 goes high and enabler cause signal 1801 is also high or on, effect 1805 will be triggered with a time delay corresponding to length T1. Cell 1804 indicates that the causal relationship is permissive and belongs to enabler Group 1, and if cause signal 1802 is enabled (i.e., cause signal 1801 is on) and triggered, effect 1806 will be triggered immediately.

[0139] The CEM 1800 may be implemented in all of the previous methods 700, 1000, 1200, 1400, 1500, and 1700 described above. Furthermore, the monitoring blocks and result blocks described herein for implementing a CEM or logic of a CEM may be used to implement complex logic functions and related logic functions, such as the CEM 1800, or any other logic functions in other CEMs. Despite the increased complexity of the 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 may be implemented in conjunction with any future embodiment of a cause-effect matrix for implementing safety logic in a process plant.

[0140] Figure 7 , Fig.10 , Fig.12 , Fig.14 , Fig.15 and Fig.17 Each of the methods 700, 1000, 1200, 1400, 1500 and 1700 in the embodiment may be implemented by software, firmware or hardware or some combination of software, firmware, software and / or hardware. Figure 7 , Fig.10 , Fig.12 , Fig.14 , Fig.15 and Fig.17 The flowcharts of the present invention are described as routines, but these flowcharts may be implemented by software, hardware, firmware, or a combination of software, firmware, and / or hardware.

[0141] Embodiments of user interfaces, such as those described above, may be implemented in whole or in part by, for example, a processor configured according to a software program. For example, workstation 18a or 20a or some other computer may implement the user interface described above in whole or in part. The software program for implementing an embodiment of a user interface may 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 the like, or in a memory associated with a processor, such as RAM, but one of ordinary skill in the art will readily appreciate that the entire program or portions thereof may alternatively be executed by a device other than a processor, and / or embodied in firmware and / or dedicated hardware in a well-known manner.

[0142] While the invention is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof have been shown in the drawings and described in detail herein. However, it should be understood that there is no intent to limit the disclosure to the particular forms disclosed, but on the contrary, the intent is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the disclosure as defined by the appended claims.

Claims

1. A method for defining a cause-effect matrix in a process control system of a process plant, implemented by a computer, the method comprising: accessing a cause-effect matrix having a set of causes and a set of effects, wherein each cause in the set of causes represents a condition within the process plant and each effect in the set of effects represents a result to be performed within the process plant, and wherein at least some of the set of causes and the set of effects are associated as cause-effect pairs whereby corresponding results are activated in response to occurrence of one or more corresponding conditions; For each result in the result set: identifying a subset of the set of causes based on the corresponding set of cause-effect pairs corresponding to the effects in the set of effects, defining the subset of the set of causes as a single-dimensional matrix, and Automatically calculate a numerical representation of the single-dimensional matrix to represent the result; and for each functional block in the functional block set, based on the corresponding numerical representation, configure the functional block with one or more configuration masks as inputs thereof, wherein the one or more configuration masks indicate how one or more inputs of the functional block correspond to each output of the functional block.

2. The method according to claim 1, wherein: Computing one or more numerical representations includes representing the results as one or more binary strings.

3. The method according to claim 2, wherein: Computing one or more numerical representations includes converting the one or more binary strings of each result into a hexadecimal number.

4. The method according to claim 1, further comprising: Rearranging the cause-effect matrix based on a set of rules, wherein rearranging the cause-effect matrix comprises: rearranging at least one of: (i) one or more rows of the cause-effect matrix, or (ii) one or more columns of the cause-effect matrix; and One or more numerical representations are automatically recomputed to represent each result in the result set.

5. The method according to claim 4, further comprising: A set of function blocks is configured for the process control system based on the one or more numerical representations.

6. A method for defining a cause-effect matrix in a process control system of a process plant, implemented by a computer, the method comprising: accessing a cause-effect matrix having a set of causes and a set of effects, wherein each cause in the set of causes represents a condition within the process plant and each effect in the set of effects represents a result to be performed within the process plant, and wherein at least some of the set of causes and the set of effects are associated as cause-effect pairs whereby corresponding results are activated in response to occurrence of one or more corresponding conditions; receiving a selection of a result from the result set; and determining a numerical representation of the result, wherein determining the numerical representation comprises: determining one or more values ​​to represent each cell corresponding to the result so that the result is represented as a string of values, and converting the string of values ​​into the numerical representation; and A functional block corresponding to the result is configured according to the numerical representation.

7. The method according to claim 6, wherein: Determining a numerical representation of the result includes: representing the result as one or more binary strings; and The one or more binary strings are converted to hexadecimal numbers.

8. The method according to claim 7, wherein: The one or more binary strings represent cause and effect pairs corresponding to the effect.

Images