This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.

Minimising risk, lead times and cost of implementing safety instrumented systems

Author : Sergio Diaz, Emerson

02 November 2021

Plant and worker safety is paramount within process industries, but building and implementing safety instrumented systems can be complex and challenging. Sergio Diaz, Product Marketing Manager for process safety systems at Emerson explains how pre-engineered hardware solutions can simplify project execution, helping to save valuable time and resources.

Image: Shutterstock
Image: Shutterstock

(Click here to view article in digital edition)

Safety instrumented systems (SIS) are utilised extensively within process plants to take a piece of equipment or process to a safe state. Consisting of an engineered set of sensing elements, logic solving units and final elements, SIS are designed to respond to plant demand and generate the correct output before a hazardous event takes place.

Today’s SIS is based on logic solvers built for digital communications with smart safety sensors and final control elements, incorporating advanced diagnostics and predictive intelligence to improve the reliability of the entire safety instrumented function (SIF). The IEC 61511 standard provides guidance on SIS implementation within process industry applications.

Whether preventing safety incidents due to overpressure or tank overfills, the correct operation of an SIS requires a series of equipment to function properly. Sensors must be capable of detecting abnormal operating conditions such as high flow, low level, or incorrect valve positioning. A logic solver must make appropriate decisions based on information supplied by the sensor and change its outputs according to user-defined logic. The output results in the final element performing an action such as closing a valve to bring the equipment or process to a safe state.

Designing an SIS

An SIS is designed to meet the particular characteristics of the facility and specific application. The system may be required to implement one or more SIFs, and these can be based on single or multiple signals. Thus, each SIS installation will vary significantly from one application to the next.

The development and implementation of an SIS has always been a challenge because it requires tremendous effort to develop processes and procedures to meet every stage of the lifecycle.

Working with competent safety system design engineers is essential to ensure systematic failures – caused by poor specification or engineering – are reduced or eliminated. Once all the SIS requirements are determined and the safety integrity levels (SIL) of the SIF have been defined, the appropriate technology is chosen, and the SIS is installed and tested for functionality and operability.

SIS projects

Image: Emerson
Image: Emerson

Although safety is the primary concern and correct implementation is critical, SIS projects come under the same scrutiny, in terms of cost and timescale, as other automation projects. There is pressure to manage project risk, capital costs and scheduling. Planned outages, during which new systems or upgrades are often installed, cannot be allowed to overrun. Projects must be completed on time, enabling production to restart. Failure to do so can cause significant financial losses in terms of lost production. Tight schedules are therefore the norm and every effort must be made to minimise overall project risk.

Project execution is generally sequential because one area is waiting on information from another area to get started. For example, the number and type of I/O must be known before a safety system cabinet design can be started or SIF configuration can proceed. Time can be wasted when each team is rushed through tasks, only to have to wait on another team to continue their work.

Traditional approach

In general, safety systems have been built in the same way for many years. Essentially, different types of I/O cards and conditioning devices must be cross wired to conventional marshalling terminals for each signal type. The company supplying the SIS needs to know the I/O schedule before submitting cabinet designs for customer approval. The I/O cannot be finalised until hazard and operability (HAZOP) analysis has been completed, and the required SIFs have been designed to meet the target SIL rating. Time pressures often drive projects forward with the acceptance that there will be I/O changes at some point that then require re-design and re-work. Software and hardware are eventually tested by the customer at the supplier’s factory. The whole process requires several interactions between the two parties, which can consume a lot of valuable time and resources.

Disadvantages of custom-built cabinets

Although the requirements and implementation of every SIS will be different, there are certain elements that offer opportunities to streamline the design and implementation process. The SIS cabinet is one such element and a good place to start. Normally a `custom-built’ SIS cabinet will be designed, with the specification and customisation of that cabinet extending as far as is desired. On the surface, this sounds reasonable; however, when analysing the work involved, this can often outweigh the benefits.

With any custom panel or junction box, engineering and design time is required for planning, panel configuration and design. This costs time and money. The project schedule must include the time it takes to design control panels and field junction boxes, along with the Factory Acceptance Test (FAT) that is usually required. The project will also include time for detail design, project administration and management. As the size of a project grows, there will be a significant increase in the amount of time needed to design, fabricate and test custom cabinets.

Schedule and costs can be affected by mistakes made during fabrication and wiring of custom cabinets. While many errors with wiring are generally found during FAT, fixing those errors takes time, which can extend the entire project timeline.

Impact of late changes to I/O

Image: Emerson
Image: Emerson

Any late changes made to the I/O will affect almost every aspect of the cabinet. Whilst they might not need to be completely re-fabricated, they may need to be modified extensively or even re-designed. I/O changes will certainly affect engineering drawings and very likely affect the wiring. Logic solvers and power supplies may also need to be moved and/or added. These changes and additions tend to be expensive. Late changes can even happen after the cabinets have been delivered to the site. When this occurs, it may be cheaper and faster to ship the cabinet back to the panel fabricator instead of relying on an inexperienced local workforce to make modifications in the field. In each case, the cost and schedule are severely affected (for large projects this can be weeks or even months), which may impact start-up. If IEC 61511 is being followed, rework also impacts on the verification process required by the standard.

Alternative approach

For a number years, end users have been able to streamline the distributed control system design and implementation process by making use of the availability of configure-to-order cabinets. This same flexibility can now be provided in the form or pre-engineered SIS. These offer an easy-to-deploy option that can make significant savings in terms of time and resources.

Pre-engineered solutions are beneficial for most safety applications on small to medium-sized projects. Standard solutions are available for applications including emergency shutdown, burner management, fire and gas detection, high-integrity pressure protection systems (HIPPS) and automatic overfill protection systems (AOPS). These solutions are also available for applications to replace ageing safety systems that might be causing reliability issues, or for concerns about IEC 61511 compliance.

Pre-engineered SIS allows end users to select from a simple menu of options to specify preconfigured standard cabinets or field enclosures as required. Attention is focused on the size of the cabinet based on the total I/O capacity required.

Electronic marshalling

A fundamental part of these pre-engineered solutions is electronic marshalling. This technology eliminates the need for traditional marshalling cabinets. Signals can be terminated directly from the field onto electronic marshalling terminals, and signals can also be mixed in any order. Intrinsically safe and non-intrinsically safe signals can be mixed on the same cabinet, while landing on separate baseplates. For each signal, the appropriate characterisation module is selected to match the electrical requirements. Characterisation modules are available for almost all commonly encountered I/O signal types and do not need to be specified until much later in the project. These can support different voltages, analogue and discrete inputs or outputs.

Enclosures can be shipped without knowing the I/O signal type. Characterisation modules can be added once the type of signal is known and even be left until after the I/O signal wires have been terminated onto the electronic marshalling terminal blocks. This flexibility is beneficial because cabinets can be built and shipped to site for field wiring termination much earlier in the project lifecycle. Alternatively, final design decisions can be accepted later in the project.

End users merely need to choose an enclosure size based on the I/O capacity they envisage at each location; up to the maximum I/O capacity. If intrinsically safe signals are required, then the mix of IS versus non-IS I/O needs to be determined so that signal segregation can be provided in the enclosure. End users must determine how the SIS will interface with existing systems and with the plant operators. Is this an extension of an existing DCS with full integration? Or is this a standalone SIS project to interface with an existing DCS via open communication protocols such as Modbus TCP? Other considerations include whether a local HMI panel is required.

Sergio Diaz, Emerson
Sergio Diaz, Emerson

Late binding of I/O

There are two important requirements for decoupling hardware and software design. First, the ability to define I/O references based on tag name rather than hardware position; in this way hardware and software design is truly decoupled. Second, the ability to automatically bind the hardware channel to the I/O reference. This capability is needed to easily bring together the hardware and software designs executed independently.

Standard compliance

All the standard requirements from a hardware perspective is performed by the factory, and documentation is shipped with the standard boxes, streamlining IEC 61511 compliance.

Simple decisions

In general, configuring system hardware comes down to three simple choices; the style of the enclosure, the size of the system, and the system interfaces required. Pre-engineered hardware solutions can be shipped ready to be installed on site. End users just need to connect power, ground, and communications.

About the author:

Sergio Diaz is the DeltaV SIS Product Marketing Manager at Emerson. He is responsible for capturing market needs, influencing product strategy and supporting product development. During his career at Emerson, Sergio has held different roles, including Field Service Engineer, Test Engineer during the introduction of DeltaV SIS, and upgrade team lead providing consultation and on-site implementation for numerous DeltaV system upgrades worldwide. Sergio holds both a BSc and a MSc in Electrical Engineering from the National Polytechnic Institute in Mexico.

Contact Details and Archive...

Print this page | E-mail this page