Comment

01 November 2004

PLC on drugs

The control system must comply with FDA regulations before it can be in operation for products.

By Eric Niu and Claudio Cuffolo

In the real business world, validation professionals from pharmaceutical manufacturers typically lack real and practical development experience in relation to the development and use of programmable logic controller (PLC) application software.

With respect to the control system integrator or system supplier, they typically are not trained in Current Good Manufacturing Practice (cGMP) or Good X Practice (GxP) (relating to FDA compliance where x can mean clinical, laboratory, manufacturing, pharmaceutical, and others), nor do they possess the solid validation operational experience required for FDA compliance.

The gap between supplier and pharmaceutical users is obvious and problems caused by this gap can be numerous. As a result, Good Automation Manufacturing Practice (GAMP) has come into being to address these issues, as it considers the overall automation system validation methodology.

Yet, even GAMP is more of a guideline rather than practical application of the PLC development cycle and practices.

Therefore, the emphasis is on Good Engineering Practice (GEP) that should ensure the engineering or software development methodology generates deliverables that support the requirements for qualification or validation in the pharmaceutical industry. The control system integrator or system supplier shall plan a software development strategy—which is the key to a successful compliant system.

Operating system in PLC world

PLC-based systems have been used in various industries for many years. Typically, a PLC control system in the pharmaceutical industry works with packaging machines, purified water systems, and air handling unit or batch controls.

A typical PLC control system consists of the hardware, software, and network components, together with the controlled functions and associated documentation.

The PLC hardware can include a rack, power supply, CPU, network interface card, digital or analog I/O cards, and other special purpose cards such as high-speed counter, motion control, pulse input, and others.

The software portion of a PLC control system involves firmware—which is the operating system in the PLC world—and programming software tools and application software usually developed by a system integrator for a dedicated process control.

Depending on the size of target process and the operational requirements, the structures of PLC control systems can vary. More often, a supervisory control and data acquisition (SCADA) system is applied, which consists of PLC-based control on the plant level, graphic screen interface on the operation level, and data processing/server on the management level.

GAMP classifies software commonly found in process controls into five categories and these categories help determine an appropriate validation approach. The PLC CPU firmware falls into category 1: Operating System. The PLC application software is custom built (category 5).

PLC software requirements

"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." –FDA Guidelines on Principles of Process Validation

This definition clearly identifies the FDA intention on validation. GxPs including Good Testing Practice, Good Documentation Practice, and Good Engineering Practice provide general principles and guidelines on validation requirements. Especially, the GAMP Guide for Validation of Automated Systems in Pharmaceutical Manufacture provides a detailed systematic approach on automation system validation but lacks many of the details on the programming side.

Even so, compliance policy guides are in place making it very clear that PLC code is an electronic record. In addition, parts of 21 CFR 11 can translate such that PLC code is an electronic record. The followingexamples of FDA warning letters well explain the position the FDA is taking on this issue.

"Failure to establish and maintain documented procedures to control and verify the design of the device in order to ensure that specified design requirements are met, as specified in 21 CFR 820(a)(1). For example, there were no procedures for review of source codes in design controls for software validation, and there is no assurance that all lines and possibilities in the source codes are executed at least once." – Example of FDA 483 warning letter

"Failure to maintain adequate device master records 21CFR 820.1811. For example, your firm did not maintain or refer to the location of the software engineering change records and software test procedures." – Example of FDA 483 warning letter

Therefore, procedures to control and verify the design process from PLC-based control systems to the firmware, to the PLC application source code must be addressed and specified clearly. SCADA packages, which often connect to PLCs, count as configurable software packages (category 4). Thus the system integrator or system supplier, in both cases, should undergo auditing in conjunction with their application of GxPs and GAMPs relative to the entire PLC/SCADA system.

The system integrator or system supplier often has to provide sufficient documentary records to ensure that the user accepts and validates the system. Use of integrator or supplier documents can simplify the overall validation process. For example, the supplier's own inspection procedures and documentation may meet the requirements of the normal installation qualification (IQ) activities if the user reviews and approves them. Correspondingly, the supplier's development methods, quality procedures, and documents may supplement or replace some normal operational qualification (OQ) activities.

Documents required for IQ and OQ are in most compliance policy guidelines. The essential part of IQ and OQ is testing procedures. The system integrator or supplier shall provide two IQ testing documents named IQ1: FAT and IQ2: SAT. In IQ1 test, all hardware I/Os test on a signal simulator; software I/Os should undergo verification and testing simultaneously. IQ2 shall proceed once all site instruments have calibrated and loop-checked with all electrical components ready. These two tests should happen in "dry run."

The software OQ is the systematic and formally documented verification that customer-built application control software performs its proper function as specified in Functional Specification. For the control system, this means supplying evidence that all functions individually and as a whole are operating in accordance with the specification. OQ test can also separate into OQ1: FAT and OQ2: SAT. OQ1 shall happen where the target process is simulated. OQ1 shall happen in a structured approach, from cell, to unit, to process area, module by module, or function block by function block. OQ2 takes place in an operational environment, and software OQ is always the essential subset of the overall system OQ.

Provide end-user confidence

To develop PLC software, the following three documents must be in place: Control System Design Standard (CSDS), which is basically detailed standard operating procedures (SOPs) for control system design; User Requirement Specification (URS); and Functional Specification (FS).

The User Requirement Specification is critical, and the end user should take responsibility for its contents by reviewing and approving the document. In practice, the system integrators engineer may write most of the URS with the assistance from the end user, but final acceptance by the user is essential and mandatory.

The Functional Specification should describe what the system should perform under given conditions, but not how. The supplier normally writes the FS or Control Narrative according to the Process Description or Process Design Report. It is very important that the end user review and approve the FS to authorize the detailed design, development, and building of the system. In practice, the FS is continually updated and refined as the detail design process further develops.

The above two documents normally require a significant amount of time to interface with the end user to create, develop, and finalize. Both documents are GMP-controlled and shall be compliant with all GMP requirements.

The Control System Design Standard is normally one of the system integrator's in-house standards; it is detailed SOPs of control system design and frequently beyond the control of the end user. Nevertheless, an audit of the PLC control system integrator or system supplier is required to determine the level of quality and structural testing built into the standard product and to examine system quality. A good CSDS will provide the end user a certain level of confidence about the validation expectation. The CSDS shall cover the design standard on instruments, device controls, system controls, structure of software, standards approach of programming, and the like.

One area of the CSDS shall be discussed here—the software structure and general programming standard. The importance of producing a CSDS is clear when a programmer has to reverse-engineer the control functions of a system only from the several hundred lines of source code found in the controller itself. Certainly anyone who's attempted such a task will concur that it's a frustrating exercise and difficult to completely understand the concepts behind the code. However, if the end user knows that the system integrator has SOPs for software development, a software development methodology, and a validation program, he will feel confident about the ability of the product to achieve its design requirements.

As such, the PLC software structure layout should follow process order and data process. For example, the main tree in a code shows the order of data flow and the process area order as well. Regarding the detail code development, the IEC 61131-3 standard should serve as a reference. In practice, a good rule of thumb is the development of reusable code whenever possible since this can reduce large amounts of system programming and simplify troubleshooting and the validation effort.

A practical approach

The following tools are for programming a PLC in IEC 61131-3.

Function Block Diagram (FBD) is a graphical language using defined function blocks from the system library or user-defined library and wiring them together on the screen to accomplish certain functions. There are two types of FBDs, the predefined FBDs provided by the system like AND, OR, TOP, etc., and user-defined FBDs developed by the programmer to accomplish a certain project-oriented function.

Ladder Diagram (LD) is the traditional method of representing logical equations and simple actions as if they were relay switches. LD and FBD may be freely mixed.

Sequential Function Chart (SFC) is the core language of the IEC 1131 standard.

Structured Text (ST) is a high-level structured text language similar to Pascal but more intuitive to the automation engineer.

Instruction List (IL) is a low-level language that is highly effective for smaller applications or optimizing parts of an application.

The strategy of PLC application software depends on the size of the target process and its complexity. The strategy referred to here is not for simple machine control with few devices, but rather a large-size application with various functional process areas.

First, all devices or control components stand alone based on their function; a typical classification in a plant will be control valves, solenoid valves (2-way/3-way), ON/OFF valve, constant pump/motor, variable speed pump/motor, conveyor (single-direction/bi-direction), and others.

The ladder logic should serve to program the basic control function for each classified device, and this LD shall package as a generic user-defined FBD named after each type of device. Also in this FBD, there shall be one separate section for mode control, programmed by using either LD or FBD.

The next step is to classify the process into functional areas. This is also a good time to define the software structure. Once process classification into areas/units/cells takes place, the programming on process level may start.

The programming approach depends on the nature of the functions; if sequential controls are heavily involved, SFC shall be applied; otherwise, FBD shall be considered as a general way because it provides the programmer, who is not necessary knowledgeable about process, a clear way to trace process, troubleshooting, and, most important, validation.

Overall, the concept of using modular software blocks dominates application software development. The software modules/FBDs are the basic cell, and go together in a human-readable hierarchy organization. The work of troubleshooting, debugging, testing, and validation can fit into different levels such as device control level or process control level or system network level.

The way a huge software development breaks down into modules and FBDs sets up a solid foundation for the development, integration, and testing. More important, it defines a clear path to software validation. ?

Behind the byline

Eric Niu (Eric.niu@earthtech.ca), P.Eng., is senior control engineer with the instrument and automation group at Earth Tech Canada in Ontario. Claudio Cuffolo (claudio.cuffolo@earthtech.ca) is an ISA member and a certified engineering technologist (CET). He is a manager at Earth Tech Canada.