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.

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.

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.

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.

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.

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