PROCESS

FIELD OF THE INVENTION

[001] The present invention relates to managing safety applications in industrial processes.

BACKGROUND OF THE INVENTION

[002] One of the main inputs for developing a safety logic is a Cause and Effect Matrix (CEM). A CEM maps one or more causes with one or more effects. A cause is an event or an alarm detected through a sensor(s) that monitors a parameter associated with an industrial process. An effect is an action(s) initiated in response to detecting a cause for mitigating risks.

[003] A developer receives a CEM as input from an Engineering, Procurement and Construction (EPC) or other contractor. The developer generates a safety logic based on the CEM. For instance, the safety logic can create an automated link between input signals received from one or more sensors (e.g. field devices), and output signals to be sent to one or more devices (e.g. motors). Thereafter, the developer manually verifies the developed application. The developer may write a few test cases for the verification. Manually verifying the developed application has scope of errors. Also, the test cases used may not be accurate or sufficient for the verification.

[004] Accordingly, there is a need for improved method for verifying safety logic in industrial processes.

SUMMARY OF THE INVENTION

[005] An aspect of the invention provides a method for verifying a safety logic in an industrial process. The safety logic is executed by a controller (or by multiple controllers) of a control system of an industrial process, wherein the safety logic corresponds to a predefined cause and effect matrix. The controller executes the safety logic by controlling one or more devices associated with the industrial process. Here, the controller controls the one or more devices based on one or more input signals received from one or more sensors, wherein the one or more sensors monitor one or more parameters of the industrial process.

[006] The method comprises loading data corresponding to the safety logic from one of the controller and a tool used for generating the safety logic. The method also comprises determining from the data, a relationship between a plurality of causes and a corresponding plurality of effects. Here, each cause of the plurality of causes is linked with a corresponding input signal from a corresponding sensor of the one or more sensors. Also, each effect of the plurality of effects is linked with a corresponding device of the one or more devices.

[007] In addition, the method comprises reconstructing a cause and effect matrix implemented by the safety logic based on the relationship between the plurality of causes and the corresponding plurality of effects. Thereafter, the method comprises comparing the reconstructed cause and effect matrix with the predefined cause and effect matrix to determine one or more inconsistencies in the safety logic for verifying the safety logic. The one or more inconsistencies may be used for regenerating the safety logic.

BRIEF DESCRIPTION OF DRAWINGS

[008] The subject matter of the invention will be explained in more detail in the following text with reference to exemplary embodiments which are illustrated in attached drawings in which: [009] Fig. 1 is a simplified representation of a system for generating and verifying a safety logic; and

[0010] Fig. 2 is a flowchart of a method for verifying the safety logic.

DETAILED DESCRIPTION

[0011] Referring to Fig. 1, which is a simplified representation of a system 100 for generating and verifying a safety logic. Here, safety logic refers to functional safety as per one or more standards associated with industrial automation. An example of such standard is IEC 61508. As shown, system 100 has a diagnostic tool 102, a safety tool 104, and a controller 106.

[0012] Diagnostic tool 102 provides various diagnostic features such as, but not limited to, reconstructing a Cause and Effect Matrix (CEM) from the safety logic, verifying the safety logic based on a the reconstructed CEM and a predefined CEM and regenerating safety logic according to the verification. In addition, diagnostic tool 102 can also, perform simulations, and generate test cases and reports. Diagnostic tool 102 may be provided as a separate tool, or may be integrated with a control system (of which controller 106 is a part of). Further, diagnostic tool 102 may have one or multiple modules for performing one or more of the diagnostic features. For example, diagnostic tool 102 may have a data loading module, a data processing module, a simulation module, a restructuring module and so forth.

[0013] Diagnostic tool 102 takes inputs from safety tool 104 and / or controller 106 for performing one or more diagnostic features. A cause and effect matrix 108 (CEM 108) is also available with diagnostic tool 102. CEM 108 may be provided during engineering phase for generating the safety logic. It should be noted that CEM 108 may change with time. This may be due to change in requirements, standards, systems and equipment and so forth. Accordingly, the safety logic may have to be regenerated. [0014] Safety tool 104 enables generating one or more safety logic that is to be executed by controller 106 (or in multiple controllers). For instance, safety tool 104 may be an editor that enables a developer to generate a safety logic based on a CEM. The developer can provide a CEM as input (e.g. CEM data in a raw format). The developer may also provide additional information (e.g. environment / other constraints not mentioned / covered in the CEM). All the inputs (i.e. CEM data and developer provided inputs) are converted by the editor automatically to a functional block diagram code (or safety logic). The safety logic is configured in a standard language (e.g. provided by IEC 61131-3).

[0015] Controller 106, which is part of a control system (not shown in figures), is configured to execute the safety logic that is generated using safety tool 104. The controller execute the safety logic by controlling one or more devices (e.g. devices 112a, 112b, 112c etc.) associated with an industrial process that is managed using the control system. Here, the controller controls the one or more devices based on one or more input signals received from one or more sensors (e.g. sensors 110a, 110b, 110c etc.). The one or more sensors monitor one or more parameters of the industrial process such as heat, pressure, flow rate and so forth (depending on the industial process).

[0016] The configuration of controller 106 may be performed during engineering or commissioning or thereafter. The configuration involves creating links between different inputs (e.g. signals from sensors) and outputs (e.g. control of devices). For instance, one or more sensors (e.g. temperature, pressure sensors etc.) may be configured for sensing certain signals indicative of one or more causes. Such detection may in turn cause controller 106 to take certain actions (one or more corresponding effects) by operating certain devices (e.g. cooler, actuator etc.). Such actions may be taken to avert risks or potential hazards. [0017] One way of performing such a configuration of controller 106 is to download the safety logic (functional block diagram code) into controller 106 (e.g. in a memory of controller 106). Such download may be performed after compiling the safety logic into executable code for the controller 106 (e.g. controller being programmable). The safety logic may be first compiled into an intermediate code and then compiled into the native executable code for controller 106.

[0018] Moving on to Fig. 2, which illustrates a flowchart of a method for verifying a safety logic. In one embodiment, the method is implemented by diagnostic tool 102. The safety logic is generated using a tool (e.g. safety tool 104) and executed by a controller(s) (e.g. controller 106). It should be noted that the safety logic is expected to correspond to a predefined Cause and Effect Matrix (CEM). The predefined CEM may be provided as an input by an Engineering, Procurement and Construction (EPC) or other contractor.

[0019] At 202, data corresponding to the safety logic is loaded. For instance, the data may be loaded from the safety tool. Alternately, the data may be loaded from the controller. The data may be in the form of a configuration file or executable script or compiled code. In scenarios where the safety logic is implemented by multiple controllers, the data corresponding to the safety logic may be retrieved from either the tool (in one read) or from the multiple controllers.

[0020] Once the data is loaded, at 204, a relationship between a plurality of causes and a corresponding plurality of effects is determined. In order to determine the relationship, firstly, the data is analyzed. Such analysis may require the data to be parsed (e.g. based on the nature of data), for identifying which portions of the data correspond to causes, and which portions correspond to effects. The analysis may depend on the tool used for generating the logic, and other factors such as development language. Each cause of the plurality of causes is typically linked with a corresponding input signal (or signals) from a corresponding sensor (or sensors) of the one or more sensors. Also, each effect of the plurality of effects is linked with a corresponding device (or devices) of the one or more devices.

[0021] At 206, a CEM implemented by the safety logic is reconstructed. Here, the term 'reconstructed' refers to creating the CEM in the diagnostic tool from the loaded data. As this is the second instance of the CEM generated in system 100, the step is a reconstruction. This CEM is reconstructed (hereafter also referred as reconstructed CEM) based on the relationship between the plurality of causes and the corresponding plurality of effects identified at 204. The reconstructed CEM may have a number of rows (corresponding to causes) and a number of columns (corresponding to events). Further, the reconstructed CEM may have properties (e.g. format) similar to that of the predefined CEM.

[0022] It should be noted that there may be certain deviations between the predefined CEM and the actual relationship between the cause and effects. This may be due to errors in generation of the safety logic (e.g. error in development, compiling etc.). Alternately, the deviation may be due to inconsistencies in inputs / outputs (e.g. from sensors, or to devices etc.)

[0023] Accordingly, at 208, the reconstructed CEM is compared with the predefined CEM to determine one or more inconsistencies in the safety logic. This may be for performing one or more diagnosis. For instance, this may be performed for verifying the safety logic.

[0024] Optionally, at 210, the method comprises regenerating the safety logic based on the one or more inconsistencies. The regeneration may be performed at the diagnostic tool and/or the safety tool. This step involves approval as per the safety process / standard. The step of regenerating the safety logic may comprise redefining (or updating) the predefined CEM based on the one or more inconsistencies. The step of regenerating the safety logic may also comprise performing a simulation(s) to predict accuracy of the regenerated safety logic. In addition, the step of regenerating the safety logic may comprise defining one or more test cases based on the one or more inconsistencies. A visual representation of the regenerated safety logic may also be generated for the verification.

[0025] Various steps of the method may be implemented by diagnostic tool 102. For instance, one or more modules of diagnostic tool 102 may perform one or more steps of the method described herein. As an example, the data may be loaded at diagnostic tool 102 through a data loading module, the data may be processed (e.g. steps 204, 206, 208 and/or 210) at a processing module, a matrix generation module and/or a safety logic module.

[0026] The method and diagnostic tool described herein can be used for performing different diagnoses and/or taking corresponding actions. Once the safety logic is successfully generated by a tool (e.g. tool 104), and downloaded in the controller, a safety engineer can use the diagnostic tool to extract data from the tool or from the controller itself. The diagnostic tool may perform a read only operation at this point in time, so as to not disturb the safety logic or normal working of the safety logic (or safety application) or the controller.

[0027] A developer or safety engineer can generate a detailed report using the diagnostic tool. The report can include details on the number of causes, effects, function blocks, Input/Ouput variables and other information used in designing the safety logic. The diagnostic tool may also be used to animate the causes, and soft signals which trigger effects. Simulation features of the tool can be used to demonstrate the working of the safety logic. The simulation can support different libraries used in designing safety systems / applications.

[0028] The diagnostic tool may also assist the developer or safety engineer in writing and executing the unit test cases to verify the correctness and working of the safety logic and report any logical errors or warnings.

[0029] Thus, the invention provides an improved method and tool for verifying safety logic in industrial processes.