One Controller, Many Uses

For years basic process control (BPC) and programmable electronic safety (PES) systems generally have been assembled from different products, often from different suppliers, always for different reasons, and usually implemented by different groups. But all that is changing. Increasingly, control system suppliers market "high-availability" control-system solutions that use the same controller as...

By Dave Harrold September 1, 2002

KEY WORDS

Controllers

Process and advanced control

Control software

Safety

Control architectures

Life-cycle analysis

Process control systems

Sidebars: Exclusive Interview with Dow Chemical What OSHA’s process safety management (PSM) regulation says about change management Agency angst? Go to the source

For years basic process control (BPC) and programmable electronic safety (PES) systems generally have been assembled from different products, often from different suppliers, always for different reasons, and usually implemented by different groups. But all that is changing.

Increasingly, control system suppliers market ‘high-availability’ control-system solutions that use the same controller as the BPC and/or PES solution.

Safety standards, such as ANSI/ISA S84.01, IEC 61508 and IEC 61511, require separation of BPC and PES functions, but stop short of dictating if separation should be physical or logical.

Physical separation has been the more traditional implementation choice.

Logical separation has been generally limited to gas turbine, transportation, and amusement-park ride controls.

Logical separation is also how Dow Chemical’s (Midland, MI) MOD 5 systems received TÜV Rheinland (Cologne, Germany) SIL-3 (safety integrity level) certification to perform BPC and PES functions in the same controller. (See ‘Dow Chemical shares its common controller platform experiences’ sidebar.)

Various seminars and conferences offer arguments for and against physical and/or logical system separation. What’s presented is interesting, often compelling, and well worth evaluating.

However, the gap between BPC and PES control system platforms is narrowing. System supplier justifications of better integration, improved operator awareness, reduced spare parts and training expenditures, and lower overall cost of ownership are becoming increasingly more valid. But, those aren’t the only evaluations and justifications end-users should consider before going down the common controller platform path.

Less obvious, but equally important, are evaluations to understand the:

Controller platforms original purpose and design;

System software capabilities; and

Corporate culture and work practice discipline surrounding the system’s use.

Study the bloodlines

Most COTS (commercial off-the-shelf) control and safety systems began ‘life’ as design specifications developed for BPC or PES applications.

BPC systems further evolved to satisfy specific application types (batch or continuous) and often include features and capabilities desired by a specific industry (pharmaceutical, petrochemical, etc.).

Likewise, PES systems are designed for specific safety application types (process plants, transportation, elevators, amusement parks, etc.).

While applying a dual- or triple-redundant safety system as a BPC system might improve system availability, it’s worth remembering’, the PES system likely didn’t begin life as a BPC system, so may not have all the desired or necessary process control functions.

GE Fanuc (Charlottesville, VA) critical safety system consultant Thomas Walczak says, ‘For example, PID (proportional, integral, derivative) algorithms aren’t permitted as part of a safety-system’s logic, thus PID function blocks wouldn’t be part of a safety system’s configuration/programming tool set. The same is true of other IEC 61131 programming library function blocks. Certainly the PES system supplier can add traditional BPC functions, such as PID, but it’s likely to be an add-on or perhaps requires a completely different configuration/programming tool set.’

Similarly, just because traditional BPC system suppliers decide to extend their marketing reach to include PES, doesn’t necessarily mean the controller’s capabilities and features have been adequately broadened to fit its ‘new’ role as a PES controller.

End-users sometimes believe that devices used in safety applications must be certified by third parties, such as Factory Mutual (FM, Norwood, MA.), TÜV Product Service (Munich, Germany), or TÜV Rheinland.

However, safety standards make allowance for suppliers to self-certify their products and/or end-users to apply equipment that has been ‘proven in use.’

End-users choosing the ‘proven in use’ path must document and analyze device field failure records ‘to a lower limit confidence of 70%.’ However, the real question end-users are asking is, ‘What will regulatory agencies, such as OSHA (Occupational Health and Safety Administration, Washington, DC), accept or require?’

Those hoping to avoid issues with regulatory inspectors, ask suppliers for safety-certified equipment.

Obtaining third-party safety certification for a product is expensive. Prior to submitting products and accompanying documentation to FM or TÜV, manufacturers are increasingly contracting with pre-certification companies, like Exida.com (Sellersville, PA), to help prepare a product for third-party safety certification.

In this example, control and safety system lifecycle models are combined to satisfy the common controller platform architecture. Depending on the type of change-process, control, or safety-following the lifecycle step re-entry points illustrate the complexities associated with change control management.

Exida.com president, William Goble explains, ‘Exida.com offers product suppliers three related activities designed to help prepare a product for third-party safety certification. We have conducted dozens of failure mode effects and diagnostic analysis (FMEDA) during the past couple of years. Based on our findings, some companies had to make changes to the product’s design, others chose to not proceed with third-party certification. Our three-step approach to certification makes it far more practical for companies to receive FM or TÜV functional safety certification, but it also makes it easier for a company to self-certify its products. I’m not aware of any suppliers who have chosen to ‘self certify,’ but it’s probably only a matter of time before one does. Personally I believe ‘self certification’ is a bad marketing decision,’ adds Mr. Goble.

Siemens Energy and Automation’s (Spring House, PA) director of safety systems John Cusimano says, ‘The ANSI/ISA S84, IEC 61508, and IEC 61511 standards permit end-users to conduct their own product evaluations. However, few companies have the resources and/or expertise to conduct the necessary FMEDA, prepare the appropriate reliability and availability calculations, and document everything in order to satisfy the standard’s ‘proven in use’ requirements. The customers I’ve talked with use only products certified by third parties.’

Like every technology ‘opportunity,’ final decisions fall on the shoulders of end-user. Before choosing a common controller platform for BPC and PES applications be sure to:

Examine and understand the controller platform’s original bloodline;

Ensure the controller has the features and capabilities to perform its new role;

Ensure the controller fits the application; and

Understand who’s behind any required certifications.

Stronger software required

When different BPC and PES hardware is used and different groups of people are responsible for each, maintaining system separation is relatively easy. Place the BPC and PES ‘eggs’ in one basket, hand the basket to one person, and because few persons possess the required in-depth knowledge required in each area, the probability of mistakes increases dramatically.

End-users, considering a single supplier’s controller platform for both BPC and PES applications should remember that suppliers developed original configuration/programming software to satisfy either a BPC or PES system design. Thus having different configuration/programming tools wasn’t a big deal. In fact, some end-users view separate software as an advantage.

When the same software is used for BPC and PES functions and support for both systems falls on the shoulders of a minimal number of people, either:

Excellent preparation, understanding, and enforcement of local, national, and international standards and work practices must take place every single day by every single person; or

System software needs to assist in the enforcement of local, national, and international standards and work practices.

Obviously the best solution is to have both. However, even with robust supplier-provided engineering software, if end-user corporate culture doesn’t support and enforce application of standards and work processes, the final results are likely to fall short of expectations and possible serious incidents can occur.

According to Invensys-Triconex (Irvine, CA) consultants, Robert Adamski and Charles Piper, ‘Strong engineering software provides a framework that allows traditional configuration/programming tools to be integrated with administrative rules throughout the BPC and PES system’s lifecycle. Working in harmony, the framework helps ensure control and automation methodologies, philosophies, and engineering design and implementation practices are enforced to avoid unwittingly jeopardizing system performance and safety.’ (See ‘Example-Combined BPC and PES System Lifecycle Model’ diagram.)

When visiting different suppliers, it’s amazing how similar and familiar the engineering software is from one to the next.

Similarity to what we already know can be a huge learning-curve advantage. Therefore it makes sense that strong engineering software retain that familiar look and feel.

Familiar look and feel

The user interface for control and safety system engineering software most often provides a graphical window’s look and feel with navigation provided by the popular tree structure to explore file locations or associations.

A flexible navigation structure is well suited to adapt to the system’s current life-cycle phase (See CE , September 2001, ‘Find the Right Engineering Tools’). For example, control system elements can be viewed in a component view during the design phase, and switched to an operational view for the operation and maintenance phase.

In an engineering framework environment, additional security, color changes, authorizations, audit trails, etc., can be attached to control system elements, units, and areas with appropriate enforcement rules.

For example:

Additional security measures can be implemented and enforced that prevent the person responsible for the BPC and PES systems from working on both systems at the same time;

Element, unit, and area color change rules can indicate required and completed activities; and

Authorization rules, combined with electronic signatures, validate required reviews and testing were conducted and approved.

When the engineering framework software combines color-change and authorization rules, unauthorized ‘downloads’ are prevented, and the framework’s audit trail tracks who, when, why, and how-including any failed or unauthorized events.

Of course, added security, authorization, and color-change rules would need to adapt to different lifecycle phases, but that’s not an insurmountable hurdle, simply another security and software administration issue.

Most importantly, a robust engineering framework environment offers far greater potential to avoid unwittingly doing something ‘dumb,’ compared to today’s configuration/programming tools.

Change control is key

Almost all production operations have to comply with one or more regulations issued by U.S. EPA (Environmental Protection Agency, Washington, DC), FDA (Food and Drug Administration, Rockville, MD), and/or OHSA.

Change control management is a common thread appearing in EPA, FDA, and OSHA regulations. Change control management also is included in standards issued by ANSI/ISA and IEC. (See ‘What OSHA’s process safety management (PSM) regulation says about change management’ sidebar.)

Change control management is the methodology used to ensure process and/or BPC and PES system changes are the results of sound thinking, good practices, and adequate reviews by qualified persons. Change control management activities, associated with BPC and PES systems, are designed to validate that each system repeatedly and reliably does what it is purported to do.

Many end-user companies have developed and stringently enforce change control management for process changes. Some companies have formal procedures in place for safety systems, far fewer companies have change control management in place for control system changes.

When the BPC and PES systems share common programming/configuration tools, it’s the vigilance and insistence of the rule-based engineering framework software that helps ensure sound thinking and good practices are consistently applied.

Evaluating a system supplier’s software from a change control management perspective, helps identify just how close the software comes to forming an engineering environment ‘expert assistant.’ Such an assistant should align with the end-users work practices and corporate culture.

Is this available?

The obvious question is, ‘Does any common controller platform with a rule-based, engineering framework software exist?’

Not yet, but several supplier companies claim they are getting close.

Suppliers say one of the things slowing the development process is end-user input.

As a group, end-users are unwilling to share work practices with suppliers because they:

Believe work practices represent a competitive advantage; and

Fear paying for their own work practices as part of the software.

It seems inevitable that control system suppliers are going to continue developing and eventually will market common-controller platforms. How sophisticated the engineering framework software becomes and how closely it meets end-user requirements depends on how willing end-users are to share and influence the suppliers offering.

The Abnormal Situation Management Consortium, made up of BP, Chevron, Celanese, Equilon, ExxonMobil, Nova Chemicals, and Phillips Petroleum, believes that sharing its knowledge with Honeywell Automation and Control Solutions (Phoenix, AZ) helps Honeywell produce products that meet common industry needs.

Dow Chemical believes that sharing its knowledge with ABB (Rochester, NY) will help ABB produce a common controller platform and engineering framework environment that meets Dow’s requirements and helps Dow extend its competitive advantage.

End-users can assume a ‘wait and see’ posture concerning common platform controllers and engineering software, or they can choose to participate with suppliers to develop a robust engineering framework environment that supports their requirements.

Those who choose to participate with suppliers would be most likely to gain real competitive advantages when it comes time to deploy a single controller with many uses.

Comments? E-mail dharrold@reedbusiness.com

Exclusive Interview with Dow Chemical

A pioneer shares its common controller platform experiences

In May 2001, Dow Chemical (Midland, MI) and ABB (Zurich, Switzerland) signed a 10-year agreement covering products, services, and knowledge transfer. As part of the agreement, Dow will share the ability to apply the MOD 5 control system as a combined basic process control (BPC) and programmable electronic safety (PES) system, with ABB. In a recent exclusive interview with Control Engineering (CE), Karen Robertson, Edward Sederlund, Eric Cosman, and Jerry Gipson, all part of Dow’s Process Automation (DPA) group, shared Dow’s MOD control system background and operational philosophy.

CE: Please explain how Dow can safely apply basic process control and programmable electronic safety functions in the same MOD controller.

DPA: It began in the 1980s when Dow’s board of directors announced that Dow’s production operations were strategic to our long-term success. Included as part of that announcement was a commitment by Dow’s Board of Directors to:

Make the MOD 5, Dow’s control system of choice;

Develop standardized work practices;

Deploy only control systems capable of supporting safe, reliable,

Embark on a continuing education process to establish a disciplined corporate culture, focused on customer driven values.

When Dow’s control system development group first setout to develop what became the MOD system, they started with a ‘clean sheet of paper’ and a goal of making the system as reliable as possible.

That included eliminating sources of common mode failures, development of a fault-tolerant real-time operating system, and creation of an application-programming environment capable of enforcing multiple levels of security and standardized work practices.

It wasn’t until later the development group realized the system’s design could meet safety system standards.

Working with TÜV Product Services (Cologne, Germany) the MOD development group obtained safety certification to use the MOD system in SIL-3 (safety integrity level) applications.

MOD’s programming software includes robust security features and work practice enforcement. Both elements were significant to Dow’s receiving TÜV certification to apply a single MOD 5 control system (dual redundant controllers) to share BPC and PES functions.

Software programs are viewable by anyone, but the software compiler ensures only authorized persons perform changes. Once the compiler is satisfied with authentication, it evaluates the software structure against approved Dow practices. Only after the compiler is satisfied the person and software structure is correct will the software actually compile. A final check prevents loading new/modified software into an ‘online’ controller.

CE: What changes does Dow foresee will be necessary to apply a COTS (commercial off-the-shelf) control system similar to how MOD systems have been applied?

DPA: Dow is confident the things that made the MOD system successful are the same things that will allow Dow to transition to COTS control systems-that is, the enforcement of control system security and insistence on applying only approved work practices. Dow has 20+ years of success using the MOD control system. During that time, a well-disciplined corporate culture has evolved; one that embraces the enforcement of standardized work practices because they’ve witnessed the success that Dow has achieved following these principles.

We fully expect that COTS control systems selected and used by Dow Chemical in the future will provide the security and work practice enforcement that’s part of our current MOD 5 system.

CE: In your opinion, what can prevent a company from successfully applying a COTS common-controller platform system?

DPA: We suspect companies who consider production operations, and the related control systems, as anything but strategic investments will not have in place the necessary work practices and disciplined corporate culture to successfully apply a COTS common-controller platform solution.

Regardless of how many enforcement tools and rules a supplier makes available in one of these systems, without the experience and discipline of applying standardized work practices, end-user companies are apt to unwittingly open themselves to regulatory violations.

What OSHA’s process safety management (PSM) regulation says about change management

Everyone acknowledges that managing change is the wise thing to do. Unfortunately, in the heat of the moment, wisdom doesn’t always prevail.

Usually no harm comes of short cutting change management procedures, but not always. Every once in awhile, short cuts end up costing lives and becoming the lead story on the evening news.

That’s one of the reasons OSHA inspectors often begin a site audit with a review of management of change procedures.

And just in case you didn’t already know, here’s what OHSA inspectors expect to find in the area of change management controls:

1. The employer shall establish and implement written procedures to manage changes (except replacement in kind) to process chemicals, technology, and equipment; and changes to facilities that affect a covered process.

2. The procedure shall assure the following are addressed prior to any change.

The technical basis for the proposed change;

Impact of change on safety and health;

Modifications to operating procedures;

Necessary time period for the change; and

Authorization requirements for the proposed change.

3. Employees involved in operating a process and maintenance contract employees whose job tasks will be affected by a change in the process shall be informed of, and trained in, the change prior to startup of the process or affected part of the process.

4. If a change results in a change in the process safety information of this regulation, such information shall be updated accordingly.

5. If a change results in a change in the operating procedures or practices of this regulation, such procedures or practices shall be updated accordingly.

To learn more about the OSHA PSM regulation, visit

Agency angst? Go to the source

U.S. government websites provide information and contacts. Those mentioned here are:

Environmental Protection Agency

Food and Drug Administration

Occupational Health and Safety Administration

Standards organizations include: ANSI