How to Accelerate Commissioning

Once a new or retrofit project reaches mechanical and electrical completion, all eyes turn toward the instrumentation and control system as being the last obstacle that's preventing start up. Well, perhaps it's not quite that dramatic, but no matter how hard we try, all control and instrumentation systems eventually end up on a project's critical path.

By Dave Harrold June 1, 2003
  • Robust practices speed commissioning

  • Witness testing, early

  • Document results

  • Ready-made solutions

Validation or verification?
GAMP: ensuring automated systems’ performance

Software engineering standards collection

Once a new or retrofit project reaches mechanical and electrical completion, all eyes turn toward the instrumentation and control system as being the last obstacle that’s preventing start up. Well, perhaps it’s not quite that dramatic, but no matter how hard we try, all control and instrumentation systems eventually end up on a project’s critical path.

It’s been repeatedly documented that applying good project management skills to a well-defined project life-cycle methodology will deliver the lowest cost, highest quality implementation.

To illustrate that point, consider the theorem IBM development engineers evolved years ago known as the “1:10:100 Rule.” IBM’s rule states, “Any defect that can be removed for $1 during the design phase will cost $10 to remove during testing, and $100 to remove once it has been delivered to the customer.”

Granted the dollar values are outdated, but the 10X ratios remain legitimate benchmarks, and the rule represents sound reasoning for applying a well-defined methodology to all instrumentation and control system implementations.

More similarities than differences

Early identification of user and supplier responsibilitires helps eliminate surprises.

Most U.S. manufacturing and processing facilities must comply with a number of U.S. Environmental Protection Agency (EPA, ), U.S. Food and Drug Administration (FDA, ), and/or U.S Occupational Safety and Health Administration (OSHA, ) regulations. These agencies’ mission statements reveal two significant similarities.

  • Each agency addresses various forms of safety and protection; and

  • Many regulations, regardless of issuing agency, include “validation” requirements.

For many readers, the word “validation” only applies to FDA-regulated industries, such as pharmaceuticals, and is not applicable to chemical, pulp and paper, and refining industries. In fact, it’s not uncommon for non-FDA regulated industries to distance themselves from the word “validation,” choosing instead to use the word “verification.”

In reality, depending on how and where the words validation and verification are used, both can have legal implications. (See “Validation or verification?” sidebar.)

It’s true that some FDA-regulated validation activities could represent over-kill for non-FDA regulated industries. However, similarities make it worthwhile to utilize a common methodology to prove to any inquiring government inspector that instrumentation and control systems are performing as intended, designed, and stated.

There’s a business reason, an added bonus, for adopting and applying existing, robust methodologies and practices: commissioning goes faster.

Standards and practices

Organizing and compartmentalizing helps ensure activities receive proper attention.

Need help in developing an instrumentation and control system life-cycle methodology?

International Society of Pharmaceutical Engineers’ (ISPE) contribution to a more consistent implementation of control, automation, and instrumentation systems is GAMP (Good Automated Manufacturing Practices). The fourth edition is titled GAMP 4. (See “GAMP: ensuring automated systems’ performance” sidebar.)

The Institute of Electrical and Electronics Engineers’ (IEEE) contribution is a four-volume collection titled, “Software Engineering Standards Collection.” (See, “Software engineering standards collection” sidebar.)

Because software development is complex and continuously evolving, IEEE’s software engineering’s standards offer organizations a viable alternative to the time-consuming and often error-prone activities of developing standards from scratch.

Over time, using IEEE standards provides the added benefit of regular standards reviews and updates—something many organizations intend to do, but rarely find the time to complete.

Carnegie Mellon University’s Software Engineering Institute (SEI) helps improve software engineering practices, such as through establishing a software architecture backbone on which to build robust, software-intensive systems.

Selecting and applying an appropriate software architecture is paramount to ensuring a system’s quality attributes are consistently applied. Once established, a robust software architecture provides sufficient abstraction to allow deployment of reusable modules between systems.

On the surface, establishing software architecture appears to be more appropriate for instrumentation and control system manufacturers than for end-users. That is, until faced with a large project and short schedule. Having chosen a single control system supplier, the end-user decides to “crash the schedule” by hiring multiple integrators to implement different process areas.

In such a case, following startup and after the integrators moved on, the end-user’s staff typically need to modify some of the application software. What they often discover is that similar software modules have been developed, named, tested, and documented in entirely different ways. What should have been a single module used multiple times, turned out to be multiple modules used once or twice each.

Considering the control system would be in place for a very long time, the seemingly minor software anomalies created by the system integrators, unnecessarily increase the end-user’s life-cycle costs of maintaining the application software.

There are two lessons here. First, software anomalies will occur and recur unless someone from the end-user organization accepts responsibility to monitor, review, and control software module development activities—a key element of a robust software architecture.

Second, ensuring a system integrator’s software development methods and practices are consistent and aligned with end-user expectations requires melding the software architectures of the system integrator and end-user.

Leveraging methodologies

Methodologies, such as GAMP, IEEE, and SEI, accelerate commissioning of instrumentation and control systems when equipment manufactures jump in with “canned” solutions.

Unknown to many end-users, many instrumentation and control system manufacturers offer documentation consistent with GAMP guidelines.

For example, Invensys’ Eurotherm division offers a CD-ROM containing validation templates for its 5000 Series (which also serves as the technology base for Foxboro’s A2 automation system) products.

Included on Eurotherm’s CD is functional specifications, installation qualification (IQ) specifications, and test result forms.

Layout and content of the Eurotherm validation templates is consistent with the sample functional specification procedure detailed in Appendix D2 of the GAMP 4 guide, but with information specific to Eurotherm products.

Similarly, Rockwell Automation’s Propack Data EPM solution is available with IQ and operationally qualified (OQ) documentation designed to ensure quick and efficient product commissioning.

Working with several large end-user companies, Emerson Process Management’s Micro Motion and Rosemount Analytical divisions have developed a “Certified Factory Calibration” service, designed to accelerate the IQ/OQ process. Emerson calibrates sensor and electronics as a system, completes appropriate documentation with required signatures, seals the device in a special shipping container using tamper resistant tape, and ships the device and documentation separately.

Documentation is shipped directly to a designated “responsible party” within the customer’s organization. When it’s time to install equipment, the customer follows unpacking procedures for matching documentation and equipment. The Emerson service is designed to eliminate field calibration activities, which are often less accurate than factory calibrations.

Likewise, Honeywell’s POMS solution provides a number of pre-engineered modules designed to meet specific application requirements, thus some amount of testing and documentation is included.

By following GAMP 4 guidelines, instrumentation and control system manufacturers can more easily and cost effectively help end-users accelerate the commissioning process, regardless of industry or application.

Watch for gotchas

Michael Kolba, senior director of validation operations at Aker Kvaerner Pharmaceuticals says, “In an FDA-regulated instrumentation and control system deployment, factory- and site-acceptance tests [FAT and SAT], IQ, OQ, and performance qualification [PQ] activities are required. Those same activities, though with different names, are also performed when deploying instrumentation and control systems in non-FDA regulated industries, with one exception—the level of completeness applied to the witnessing and documenting of what’s been done.”

One of the things that makes GAMP an effective tool is its emphasis on minimizing testing, witnessing, and documentation overlap from FAT to SAT, IQ, OQ, etcetera. The architecture encourages testing, witnessing, and documenting things as early as possible. When this is combined with the minimization of testing overlap, elements get off the critical path early while still ensuring a robust, timely implementation.

The terms FAT and SAT are commonly understood; however, in other industries, IQ and OQ might be combined and called installation testing and water batching, final testing, or simply process commissioning may be used in place of PQ. The point is, there are a lot more similarities than differences in what’s meant and achieved among these terms.

Kolba adds, “The definition of terms and what’s required as part of each isn’t something to be brushed off lightly, especially when interviewing installation contractors. It’s important to ensure the installation contractor’s staff understands and follows IQ and OQ procedures, or whatever you call them, including the need for witnessing, documentation, and sign-off. Otherwise all the anticipated savings in dollars and time are lost.”

That’s sound advice. And when extended across the entire instrumentation and control system life-cycle methodology, it makes accelerating the commissioning process achievable without jeopardizing long-term instrumentation and control system support activities.


Validation or verification?

Government regulations and guidelines often use the words “validate” and “verify,” but what’s the difference?

FDA’s definition

FDA regulations state validation is, “Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes.”

For control systems, that means the system owner must establish and follow a written methodology that proves its control systems do what they are purported to do. If changes in production requirements require control system changes, the owner must preserve proof of system validation before the changes and preserve new proof of system validation after the changes are implemented.

Legal implications of control system validation come into play when an unsafe condition is brought to the attention of government regulators and investigation reveals the control system isn’t doing what it’s supposed to do.

Depending on the severity of the violation(s), warning letters, monetary fines, production shut downs, product recalls, and/or legal prosecution are all regulatory agency options.

Verification defined

Among dictionary definitions of verification are, “A confirmation of the truth of a theory or fact,” and “A determination or testing of the truth or accuracy of, as by comparison, investigation, or reference.”

The point is, semantics don’t represent a legal argument. Whether it’s validation or verification, it’s important control systems do what they are supposed to…every time.

GAMP: ensuring automated systems’ performance

Developed by the International Society of Pharmaceutical Engineers (ISPE), Good Automated Manufacturing Practice (GAMP), was developed for use by instrumentation and control system suppliers and users in the pharmaceutical manufacturing and related life science industries, including biotechnology and medical devices.

Though GAMP contains terminology specific to its target industries, its overall approach makes it adaptable to other industries.

Now in it’s fourth edition, GAMP 4 combines key principles and practices and describes how these can be applied to determine the extent and scope of validation for various types of automated systems.

GAMP 4 helps organizations develop:

Validated and compliant automated systems using the concept of prospective validation following a life-cycle model; and

Procedures to ensure that a validated automated system remains in a validated state throughout its operational life.

The guidance provides a common, technically sound approach to validation of automated systems that is understood by suppliers and regulators.

GAMP 4 guides suppliers of automated systems on the development and maintenance of those systems by following good practice. The guidance assists suppliers in producing documentation required to support validation.

Benefits of applying GAMP 4 include:

Cost benefits that aid the production of systems that are fit for purpose, meet user and business requirements, and have acceptable operation and maintenance costs;

Better visibility of projects to ensure delivery on time, on budget, and to agreed quality standards;

Increased understanding of the subject and introduction of a common language and terminology;

Reductions in the cost and time to achieve compliant systems;

Improved compliance with regulatory expectations by defining a common and comprehensive life-cycle model; and

Clarification of the division of responsibility between user and supplier.

GAMP 4 is provided as a single bound volume or on CD-ROM. Visit the ISPE Web site at

Software engineering standards collection

IEEE’s 730-1989 “Standard for software quality assurance plans” is referenced by the FDA as appropriate for computer and medical device software validation.

In 1999 IEEE released a four-volume collection of software engineering standards that has become the hallmark in helping to ensure the development and maintenance of high quality software.

Highlights of the IEEE software engineering standards collection include:

Volume 1: Customer and terminology standards: Describes the interaction between the customer and the supplier of a software engineering project. Included are descriptions of the agreement for software development, operation, and maintenance, detailed aspects of the customer/supplier relationship, and a glossary of software engineering terms.

Volume 2: Process Standards: Describes primary processes, including acquisition, supply, development, maintenance, operations, and measurements.

Volume 3: Product Standards: Explains the requirements for classes of product characteristics, measurements, evaluations, and specifications.

Volume 4: Resource and Technique Standards: Recommends the proper documentation for a well-managed software program and its related processes.

IEEE is scheduled to release a new edition of the Software Engineering Standards Collection in mid-2003.