Automatic Configuration of a Safety Instrumented System

Automatic Configuration of a Safety Instrumented System
Automatic Configuration of a Safety Instrumented System

Safety instrumented systems (SISs) have traditionally been configured manually using different source documents such as the safety requirement specification (SRS), cause and effect matrices (CEMs), safety integrity level (SIL) calculations, and I/O definitions, among other information.

Emerson partnered with exida to deliver a database-based solution that enables automatic configuration of safety logic using information captured in exida’s exSILentia software suite. An evident advantage of this approach is the reduced configuration effort. However, the real benefit is having a consistent configuration approach that has fewer errors and less rework and that is easily traceable back to the SRS.

Emerson partnered with exida to deliver a database-based solution that enables automatic configuration of safety logic using information captured in exida’s exSILentia software suite.

The DeltaV SIS Configurator tools provide great benefits for the implementation of emergency shutdown (ESD) projects within DeltaV safety instrumented systems. While the exSILentia tool does not generate the full DeltaV SIS configuration, it can potentially generate up to 90% of the safety logic. The user still needs to create input/output (I/O) configuration, graphics, and alarms. In addition to the time savings, another benefit is a consistent approach with less error.

This article is a high-level overview of the capabilities of the DeltaV SIS Configurator developed by exida. It is not intended as a configuration guideline. For further details please refer to exida’s documentation (exSILentia User Guide and DeltaV SIS Configurator User Guide).


DeltaV SIS configuration overview

The DeltaV SIS process safety system makes configuration of safety instrumented functions (SIFs) easy. The DeltaV SIS built-for-purpose function blocks can help to eliminate engineering hours required to implement safety applications. The TÜV-certified function blocks deliver powerful functionality out of the box, simplifying the implementation of complex SIS applications.

One of the advanced function blocks is the analog voter function block, which has advanced features to easily implement “M” out of “N” voter functions. That is, “M” inputs of the total “N” inputs must vote to trip. For example, the block can be configured as a 2oo3 (two out of three) voter, where two of the three inputs must exceed the trip limit before the output is tripped. What used to take a fair amount of programming using “AND” and “OR” logical gates is now replaced by a standard function block configured using radio buttons and check boxes (Figure 1). For example, if the application needs to prevent multiple maintenance bypasses at the same time, the user only needs to check one box. If the application requires a bypass timeout to either automatically remove the bypass after a predefined time or simplify to provide an alert, the user again just needs to select the proper options within the bypass option parameter.




Trip limits, trip delays, and detection types (high limit or low limit) are easily configured using parameters (Figure 2).

All the traditional programming required for implementing an analog voting function has been replaced by a few configuration settins. In the same way, there is a discrete voter function block with similar functionality.

Implementing a cause-and-effect relationship is done using another advanced function block. The cause-and-effect metrix function block defines interlock and permissive logic that associates as many as 16 inputs (causes) and 16 outputs (effects). The block’s “MATRIX” parameter defines the causes that produce each effect to trip. Figure 3 provides an example of how to configure an 8×3 CEM. Defining the trip logic is as simple as selecting the proper intersections in the “MATRIX” parameter.

Although a 16×16 matrix might seem relatively small, the reality is that DeltaV SIS breaks the configuration in SIFs, and the need for large matrices is greatly reduced. While the overall project CEM might include hundreds of causes and hundreds of effects, individual SIFs typically do not have more than 16 causes or 16 effects. Most of the SIFs can be implemented using the CEM function block. For the few SIFs requiring larger matrices, DeltaV v14 introduced two new function blocks (“MONITOR” function block and “EFFECT” function block). There is no set limit for the number of causes or effects that can be implemented combining the new “MONITOR” and “EFFECT” blocks.

SIF configuration Implementing a SIF in DeltaV SIS is quite simple (Figure 4): 1. Drag and drop the proper function blocks. 2. Wire the function blocks as appropriate. 3. Configure the proper parameters.


Applicability of the DeltaV SIS Configurator The ability to automatically generate DeltaV SIS safety logic is based on a sound conceptual design using exSILentia. An incomplete SRS will not generate the expected results. DeltaV-relevant information (e.g., signal tags) needs to conform with DeltaV syntax. The DeltaV SIS Configurator tool generates proper warning messages when the DeltaV SIS syntax rules are not being followed, and in most cases, the log file provides sufficient indication for resolving the issue.

The use of the DeltaV SIS Configurator does not eliminate proper engineering practices. In fact, a more structured approach is needed. Configuration implementation should not start until the design SRS is finalized and all relevant information for the DeltaV SIS is properly captured. Only users who have used exSILentia as both an SRS compilation tool and an SIL calculation tool will benefit from this solution. There are no migration tools to take SRS or SIL calculations developed in other software or tools and convert them into exSILentia. The exSILentia approach requires early engagement during the conceptual design.

The use of the DeltaV SIS Configurator is mainly targeted to ESD applications. It is estimated that the tool could create up to 90% of the safety logic, depending on the complexity of the application. Currently there is no support for a sequential type of safety logic (e.g., BMS). Applicability to fire and gas is greatly affected by the lack of SIL calculations in these applications.

The exSILentia tool focuses on the generation of tag-based safety logic. The I/O configuration, including CHARM Smart Logic Solver (CSLS) configuration, CHARM configuration, and device allocation, is not part of the scope of the tool. With the DeltaV SIS late binding capability, the user can easily bind the tag-based configuration with the I/O design developed independently from SIF design. DeltaV Smart Commissioning is supported by configuration safety logic created by exSILentia. Graphics are not automatically generated either. Only a few alarms are configured by the tool; most SIS alarms must be configured manually or generated from alarm rationalization software.


Overview of exSILentia

The exSILentia product is an integrated suite of engineering software tools designed to support the process safety management (PSM) work process and the SIS functional safety life cycle. Data is seamlessly exchanged between the different phases of the safety life cycle, ensuring efficiency and consistency. Information from the process hazards analysis, layer of protection analysis, and SIL target selection are fed directly into the SRS. Once the SIFs and associated risk reduction requirements are defined, exSILentia SILVer facilitates the calculation of the achieved risk reduction for each SIF. Then, exSILentia enables the creation of an SRS that incorporates all the analysis done in the risk assessment.

The IEC 61511 standard requires the creation of an SRS and defines what the SRS should contain; exSILentia facilitates the compliance to IEC 61511 requirements. A proper SRS must contain all the requirements for the SIS and its associated SIFs. For each SIF, the SRS should include safe state, required SIL, maintenance and a startup overrides, architecture requirements, voting arrangements, trip delays, and other SIF requirements.


Emerson and exida collaboration

Emerson collaborated with exida to create a new approach for SIS configuration. By pairing builtin DeltaV SIS functionality with exida’s comprehensive software tools, users can develop safety logic configurations much faster and in fewer steps.

In a traditional SIS configuration approach, the project team uses the SRS, along with a custom-built CEM as the basis for the safety logic configuration. The SRS and CEM are manually interpreted and translated into the safety logic. This configuration model requires multiple data entry stages and presents opportunities for human error. The new configuration approach powered by exSILentia leverages data structures created during the conceptual design to automatically generate safety logic (Figure 5).





DeltaV SIS configuration using exSILentia The DeltaV SIS Configurator created by exSILentia converts the exSILentia data into a DeltaV SIS configuration file (FHX file) that can be imported to create safety logic. The exSILentia approach for DeltaV SIS configuration uses the SIL calculations and SRS captured in exSILentia, as well as the parallel structures between exSILentia and DeltaV SIS modules (Figure 6). Both exSILentia and DeltaV SIS follow an SIF approach that enables the overall SIS configuration to be divided into modular elements where a DeltaV SIS module contains one or more SIFs.

Each SIF contains a combination of sensors, voting arrangements, logic solvers, and final elements. Those elements defined in exSILentia are mapped to DeltaV SIS function blocks


Creating SIS modules from exSILentia

The exSILentia solution defines DeltaV SIS function blocks and the appropriate connections based on the SIL calculation diagram (in SILVer). exSILentia also parameterizes the DeltaV SIS function blocks based on the exSILentia data. Parameters such as I/O tag, trip limits, ranges, engineering units, and trip direction are defined as part of SIF definitions within exSILentia. All those exSILentia settings are properly mapped to parameters within the DeltaV SIS function block (Figure 7).


There also are parallel structures for maintenance overrides. The maintenance override requirements in exSILentia are mapped to the DeltaV SIS bypass option parameter (Figure 8).

SIFs sharing final elements are automatically combined into the same DeltaV SIS module, but users can also manually group SIFs into DeltaV SIS modules, even if those SIFs are not sharing a final element (Figure 9).

Annotations within SIS modules One key feature is related to the ability to add proper annotations within the safety logic. exSILentia automatically adds relevant information that facilitates traceability to the SRS and increases logic readability (Figure 10).

Once the SIF definition and the design SRS are completed, the DeltaV SIS configuration can be generated using the SRS C&E menu in exSILentia (Figure 11).

The user can choose to either generate the configuration for all SIFs or only selected SIFs (Figure 12). The option for selected SIFs is useful for updating a SIF after late changes in the conceptual design.

Workflow for using exSILentia to generate DeltaV configuration

For end users and system integrators who already use or are intending to use the exSILentia tool, the DeltaV SIS Configurator plug-in allows them to automatically generate safety logic to be imported into the DeltaV SIS database.

The use of exSILentia within a DeltaV SIS project is described by the following short list of activities: ● SIF modeling. Once the SIFs are deemed required per the analysis phase, the SIF architecture is defined to meet the SIL requirement. exSILentia is used to specify and model the SIFs. ● SIF detailing. After the SIF architecture is defined, the user needs to detail the SIF within exSILentia. At this point, the user sets variable ranges, trip limits, etc.

  • Data transfer. The exSILentia configuration file is now sent to the project team performing the DeltaV SIS configuration. In this approach, the exSILentia configuration file replaces the cause-and-effect diagram and other information typically sent to project teams.
  • SIF detailing for DeltaV SIS. The project team will load the exSILentia database and will work on design details that the end user or system integrator does not necessarily need to care about during the analysis phase but are important for the configuration. This includes, for example, logic solver names associated with each SIF and sdefining the grouping of multiple SIFs into one single SIS module. The information is limited to safety logic and excludes graphics and I/O configuration beyond I/O references within I/O function blocks.
  • Configuration generation. The project team will use exSILentia DeltaV Configurator to generate DeltaV SIS Logic (FHX files).
  • DeltaV import. The project team will import the generated FHX file and finalize the DeltaV configuration not supported by exSILentia (i.e., alarms, I/O allocation and I/O binding, auxiliary actions implemented in BPCS, CHARM configuration).
  • Finalizing DeltaV configuration. The project team will configure human-machine interface (HMI) graphics and verify logic implementation together with the HMI.
  • SIF logic validation. The user will validate the SIF logic to verify proper connections and safety functionality for each SIF.

This article comes from the May 2021 issue of Intech Focus: Process Control and Safety.

About The Author


Serio Diaz is DeltaV SIS Product Marketing Manager at Emerson Automation Solutions.


Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..

Subscribe