Independent, But Connected

Wednesday, April 14, 2010 @ 03:04 PM gHale


By Ron Johnson and
Luis M. Duran

Operational aspects of safety systems are under increased scrutiny throughout the automation industry these days. Beyond the pure financial benefits, which focus on reducing operational cost throughout the system lifecycle, the real driver is safer operations.

Systems continue to get more complex, and with a larger number of systems in any given plant combined with a knowledge pool continuously depleting through retirement, the risk of safety critical mistakes understandably inch upward.

One counter-measure to negate this risk is a reduction in system complexity and the number of systems used.

Just take a look at Dow Chemical. For a long time the Midland, MI-based chemical giant used a combined basic process control system and safety instrumented system (BPCS/SIS) logic solver platform.

Dow’s proprietary home grown computer system is TÜV certified for SIL-3 plus BPCS control (providing they follow the safety manual). The company successfully used it this way since the mid-1990’s and they now have hundreds of installations utilizing this concept.

Today there are integrated SIS/BPCS logic solver platforms available all over the place. Since the early 2000’s, Dow started using an ABB SIL certified platform in a similar manner as their own home grown computer system. At one facility in Michigan that uses toxic chemicals and a gas fired curing oven. This 1,500 I/O facility uses multiple dual certified safety controllers to perform all of the normal process control plus roughly 75 safety instrumented systems (SIL-1 & SIL-2).

In some cases Dow has gone one step further and utilized the common pool of field data to enhance the basic process control and the safety systems by sharing sensors. In one case, the same two temperature signals see use by the oven’s fuel gas controller for temperature control and by the high temperature SIS trip that shuts the fuel block valves.

Conventional thinking would wire one sensor to the BPCS computer for temperature control and the other sensor to the SIL certified computer for the SIS. But by sharing these sensors, the temperature control becomes more robust and fault tolerant thereby decreasing the probability of control failure. At the same time, the SIS with two sensors is more robust and fault tolerant resulting in a lower failure probability. Dow recognizes the potential common cause issues associated with sharing sensors and consequently calculates proof test intervals with fault tree based tools.

In another case, a 1,300 I/O European Polyurethanes expansion with over 100 SIS loops utilized multiple dual certified safety controllers. The safety systems and the normal process control fully integrate within this single platform. Roughly 25% of the safety loops also share sensors with the basic process control. Although the front end design is more complex to ensure they do not compromise safety, the long term benefits are worth the effort.

The integration of safety and basic process control has proven itself with safer and less complex operating environments.  Within the last five years, Dow has installed over 20,000 I/O on commercially available dual certified logic solver platforms. Dow’s history with over 1,000,000 I/O on Dow’s proprietary dual certified platform ensures this is the future for Dow. History shows when properly designed and implemented, safety and basic process control can integrate in a safe and cost effective manner.

Industry shift

Dow’s move should not be a surprise because over the past decade the automation market has consolidated vendors and started to develop BPCS and SIS using similar hardware and software for sequential logic control and regulatory process control. Integration became more than sharing the process network.

As the advances in technology continued, the industry benefited from improvements in the reliability of hardware and software, including embedded software. The 1oo2 dual, 2oo3 triple, and quad systems available on the market today come from a design era that used redundancy and fault tolerance as a means of reducing the probability of a dangerous failure occurring. Today, a manufacturer can design out dangerous failure modes and they can provide more than 99% diagnostic coverage to protect integrity without resorting to duplication. The requirements of “fail safe” for “safety integrity” and “fault tolerance” for “availability” can now undergo independent consideration and used when and where they are applicable.

Other advances are in the form of the design process. Safety standards recommend product life cycle design processes which include product development or “validation and verification” to ensure everyone takes proper care in the development of the product.

This new degree of integration challenges the common accepted practices of satisfying and demonstrating the SIS is not subject to common cause failures with the BPCS. Furthermore, even though they are integrated, both systems can provide independent protection layers and meet the safety standard’s requirements.

The debate about the separation of the safety function from the BPCS will no doubt continue. However, the IEC 61508 and IEC 61511 standards recognize safety and non-safety functions can reside in the same system if “it can be shown that the implementation of the safety and non safety functions is sufficiently independent (i.e. that the failure of a non safety related function does not cause a dangerous failure of the safety related functions)”. Also, the standards also require the possibility of common mode dependent failures reduces down to an acceptable level.

Standards and integration

It is easy to quote safety standards to answer the question of if it is possible to comply with standards in an integration scenario. IEC 61511-1 clause 11.2.4 states “the BPCS should be designed to be separate and independent to the extent that the functional integrity of the SIS is not compromised.” ISA-84.00.01-2004 Part 2 Clause 11.4.2 adds “physical separation between BPCS and SIS may not be necessary provided independence is maintained, and the equipment arrangements and the procedures applied ensure the SIS will not be dangerously affected by:

  • Failures of the BPCS;
  • Work carried out on the BPCS for example: maintenance, operation or modification.”

The same reference suggests “in order to safely use a single platform for BPSC and safety, you need to effectively separate the BPCS from the SIS. They need to be as independent as possible to ensure interference is eliminated. This is managed by a strong Operating Discipline (OD) program.”

The traditional approach for reducing common cause was to use totally different systems for the BPCS and the SIS, using different hardware and software to reduce common cause failures. These systems would come from different providers so common cause failures could most likely go out the door because the user would assume the provider’s logic solver manufacturing process used different development organizations, knowledge, manufacturing processes, as well as different installation, operation, and maintenance procedures.

Additionally, the SIS provider would need to have a third party certification of their products according to applicable safety standards. In one case, a certification provided by TÜV includes a complete assessment of the hardware and software of the product including failure modes, installation requirements, operating restrictions in case of a failure, design and verification process, and many others.

Dual system training

One obvious disadvantage emanating from today’s work intensive and engineer depleted environment is the manufacturer needs to engineer, commission, operate and maintain two totally different systems throughout the lifetime of the plant. Engineers, operators and maintenance personnel would need training and continuously need to maintain knowledge about different systems.

An alternative approach is to build independence in the design process of the integrated system. Independence is possible using diverse design engineering and programming teams provided with different software architecture specifications and guided by an overall concept for diversity from the start of the detailed design specifications.

The use of different toolsets in the development process provides even further diversity and facilitates reduction of common cause faults. Development techniques utilizing formal methods, the V-model (as defined in the safety standards), strict coding guidelines, separate development teams, and diverse implementation ensure a structured approach to avoid common mode failures throughout the entire specification, design and development process. When supported by a structured approach to test and formal verification at different levels, performed by an independent team, it is possible to enhance system reliability even more.

More than one solution

It is possible to design out dangerous failure modes and to provide more than 99% diagnostic coverage to protect integrity without resorting to duplication. Technology has evolved to a point where there are multiple options to address a similar technical problem. By using two or more technologies, diversity will embed into the system design. Diversity can occur in the embedded software by using different operating systems and then using different teams to develop the software on multiple cooperating modules.

By combining two different technologies (such as Micro Processor (MPA) or Micro controllers and Field Programmable Gate Arrays (FPGA)) to perform the same functionality in parallel to each other the design achieves a truly redundant and diverse implementation with a minimum of possible common cause failures. To eliminate the potential sources for common cause failures originating from design, development and test, this approach requires different development and test tools, as well as different programming languages for implementing the functionality,. By using two different development teams for creating system overheads in these two technologies, common cause failures can be minimal.

Memory management unit

In addition to implementing access control, password protection and a firewall, logical separation can come in the form of memory management. A memory management unit (MMU) can provide independence between different partitions of memory areas. These memory partitions then connect to different executing processes of the CPU such as regulatory process control or safety instrumented function. This approach ensures only the memory area belonging to that process is accessible while the CPU is executing one of its processes.

However, in order to fully answer any question, each user should seek for their answers by applying standards to assess the independence of both systems.

The pros and cons of integrated safety systems are “soft” and are often not easy to prove. Nevertheless, they constitute an important consideration when evaluating the overall performance of a safety system. The benefits are in the following areas:

  • There is only a single process automation computer platform in the facility. That means there is only a single operator interface for operations to learn and operate. In addition, there is only one computer language for programmers to learn and one platform for maintenance personnel to maintain.
  • All field instruments are wired to the common system, meaning there is less field splitting (optical isolators) or less communication required between two separate systems. That means there is easier instrument design and field wiring because all the I/O for a given unit operation wire to the same logic solver, regardless of whether it is safety I/O or not.
  • The complete pool of plant information is available for the BPCS and the safety system because all the facility’s I/O wires to the same logic solver. This allows for easy and safe communication of information between the SIS and the BPCS by utilizing the platform’s certified safeguards to maintain “non-interference” and “functional independence.” That also means the SIS operating window can be flexible since it can intimately know what is going on with the BPCS. For each unit operation the boundaries of the operating window change as the plants start up and shut down. This is much more difficult to manage with independent BPCS/SIS systems because there is only one SIS trip setting which forces operations to sometimes bypass these restrictive trip set points (for example during start-up activities). This introduces the need to bypass, and consequently the chance of leaving these hardware and software bypasses in place after startup. With an integrated system, you can automate manual SIS bypasses and enables by coordinating with process operations and thereby eliminate the issues associated with having to remember to re-enable the safety systems. In a more abstract way, signals are not simply used, but rather the data they represent is used. The data goes in the data pool and validated first. This allows the use of multiple information sources as well as more final elements to execute decisions.

A commonly referred to publication by the UK Health and Safety Executive summarizes primary causes of failure of safety systems as follows:

  • Inadequate specification: 44%
  • Changes after commissioning: 20%
  • Design and Implementation: 15%
  • Operation and Maintenance: 15%
  • Installation and Commissioning: 6%

Although these problems loom larger with Baby Boomers retiring, the publication points out close to three-fifths of all sources of failure already exist before operation of the system has started. Improvements during specification and design stages of projects will to reduce these types of failures.

Human error unquestionably plays a significant role in a majority of failures occurring during system installation, commissioning, operation, maintenance and subsequent upgrades or modifications, according to these numbers. ISA-84.00.01-2004 part 2 says in clause 11.4.2: “Identical separation between the SIS and BPCS may have some advantages in design and maintenance because it reduces the likelihood of maintenance errors.” Additionally, there may be a reduction in systematic trips.

The use of Integrated Safety Systems offer ways to enhance safety and, as an added benefit, reduce the cost of ownership. Engineering efficiencies, improved system understanding and support will have positive impact on safe plant operation and bottom line performance.

When safety standards and best engineering practices start with the initial design, it is possible to develop an automation system that integrates the BPCS and SIS function within the same operational, maintenance and engineering environments.

This approach changes the paradigm from building robustness and reliability around multiple redundant paths to the use of the technology options available today to creatively satisfy the core design principles of independence, diversity and separation. These can then enable independent protection layers that integrate the user work functions. These systems have TÜV certification without the need of certifying the complete automation infrastructure, and without the need of ensuring the non-interference nature of the process control system.

Users can enjoy the benefits of integration without compromising safety and be in compliance with safety standards. However, the most important factor is plant operators are able to detect and react promptly to process conditions before they develop into near misses or incidents. Additionally, operations have the ability to track, analyze and report within the environment used to perform those functions for all other plant operations.

Behind the byline
Ron Johnson is an engineering solutions safety instrumented systems subject matter expert at Dow Chemical. His e-mail is RKJohnson@dow.com.

Luis M. Duran is a safety systems business development manager at ABB. His e-mail is luis.m.duran@us.abb.com.

This story emanated from a paper written for ISA EXPO 2009.



Leave a Reply

You must be logged in to post a comment.