Print this article

Comment

1 September 2005

Three options for control, safety

By Paul Gruhn

This is part one of a two-part series.

In the evolving world of process industry safety system standards, vendors continue to release new systems. Everyone is promoting something different, and everyone claims their solution is the best. It is difficult just to keep track of all the developments.

Control systems, also known as basic process control systems (BPCS), control variables such as temperature, level, pressure, and flow. They also optimize fuel usage or product quality. Safety systems, also known as safety instrumented systems (SIS), monitor the process and bring the process or the equipment to a safe state in the event of a potentially hazardous condition.

Control and safety systems often need to communicate with each other and share information. Three types of methods accomplish this: interfaced, integrated, and combined. Each design philosophy offers advantages and disadvantages. Which option may be most suitable for a particular application will vary based on factors such as size, level of risk, location, expertise of staff, availability of support, and cost.

Traditional guidelines

Certain guidelines, recommended practices, and standards suggest and sometimes mandate separating control and safety systems.

The English Health and Safety Executive "strongly" recommended separate control and protection systems in its 1987 guideline, Programmable Electronics in Safety Related Applications. The American Institute of Chemical Engineers Center for Chemical Process Safety said the logic solvers are "normally" separated from similar components in the BPCS in its stated 1993 textbook, Guidelines for Safe Automation of Chemical Processes. The 1996 version of the ISA-84 standard, Application of Safety Instrumented Systems for the Process Industries, said the logic solver "shall be separated from the basic process control system except where some applications have combined control and safety functions in one logic system," such as turbines.

Some more recent standards softened their approach on the separation issue, primarily at the request of committee member end users. Mandating separate control systems for small packaged pieces of equipment used throughout a facility may be unpractical and unnecessary because of low risk, higher cost, and increased complexity.

The ISA-84 standard came out again in 2004. The ISA committee worked closely with the International Electrotechnical Commission (IEC) 61511 committee in developing the IEC standard. ANSI/ISA-84.00.01-2004, Functional Safety: Safety Instrumented Systems for the Process Industry Sector, is the IEC 61511 standard with the added grandfather clause for existing systems. This standard said:

The design of the protection layers shall be assessed to ensure that the likelihood of common cause, common mode, and dependent failures between protection layers and between protection layers and the BPCS are sufficiently low in comparison to the overall safety integrity requirements of the protection layers. The assessment may be qualitative or quantitative.

We can interpret terms such as sufficiently low, as well as the type and degree of rigor of the assessment in different ways. And take this statement:

If it is intended not to qualify the basic process control system to this standard, then the basic process control system shall be designed to be separate and independent to the extent that the functional integrity of the safety instrumented system is not compromised.

Qualifying a control system to the safety system standard, which requires quite a few tasks of the end user, represents an onerous proposition for anything other than a small system. And perhaps most importantly:

A device used to perform part of a safety instrumented function shall not be used for basic process control purposes where a failure of that device results in a failure of the basic process control function, which causes a demand on the safety instrumented function, unless an analysis has been carried out to confirm that the overall risk is acceptable.

Again, the second part of that statement is open to interpretation. What is the extent and degree of rigor of the analysis?

The IEC 61508 standard, Functional safety of electrical/electronic/programmable electronic safety-related systems, which is a standard for manufacturers to follow in the design of their systems, when implementing an E/E/PE safety-related system to safety and non-safety functions, states all hardware and software "shall be treated as safety-related unless" you can show failure of any non-safety-related functions does not cause a dangerous failure of the safety-related functions. Another key statement is, where practicable, you should separate safety-related functions from the non-safety-related functions. It states you should exercise caution if implementing non-safety functions and safety functions in the same E/E/PE safety-related system. While the standard allows this, it could get complicated and make it more difficult to carry out E/E/PES safety lifecycle activities such as design, validation, functional safety assessment, and maintenance.

Interfaced control and safety

The traditional approach for control and safety systems has been to provide two separate platforms from two separate vendors. The systems communicate with each other either using an industry standard protocol (MODBUS or OPC) or on the same proprietary highway as the control system (often using some form of gateway). While major control system companies usually offer safety systems, simple investigations reveal most systems were either acquired from different companies or supplied through some form of partnership with a different company.

The primary benefit of this approach is you can select the best in class of both systems for any particular application. It doesn't force a user to use the control system vendor's preferred safety system, but it strongly influences the decision. A secondary and maybe more important benefit is reducing potential common-cause problems. Using diverse hardware and software simply means any potential single problem (other than a high level design error) would be less likely to negatively impact both systems.

One drawback of such an approach is contractors, integrators, and end users have to learn two separate systems: hardware and software. Costs for training and spare parts for two systems are higher. Getting diverse systems to communicate is not always as easy as sales professionals or manuals say it will be. The initial costs of such an approach will be the highest.

Stay tuned for Part 2 in the October InTech for more information on integrated control and combined control and safety.

Behind the Byline

Paul Gruhn is a safety product specialist at ICS Triplex, an engineering services and technology solutions provider in Houston.