Minimising Risk, Lead Times and Cost of Implementing Safety Instrumented Systems
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.
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 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
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 redesign 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
Any late changes made to the I/O will affect almost every aspect of the cabinet. Whilst they might not need to be completely refabricated, 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 of 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 easyto-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.
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 are 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.
Gökhan Karatoprak
Senior Sales Engineer
Emerson Process Management
