47
Validation of Control Systems
Steven Ostrove
Ostrove Associates, Inc., Elizabeth, New Jersey, U.S.A.
INTRODUCTION
As discussed in chapter 46, the FDA has considered
computer systems as equipment that needs to be formally
qualified. The general approach to qualifying a piece of
equipment can be found in chapter 46. All types of
equipment used in or for the purpose of producing or
releasing a pharmaceutical or device product must be
qualified; computers and computer systems are no excep-
tion. The use of computerized control for manufacturing
and quality control has grown substantially over the last
decade. In fact, the FDA guideline on PAT discusses this
technology as it is gaining acceptance in the
pharmaceutical industry.
Chapter 46 discussed the history of computer vali-
dation and further discussed the development of
software validation. This chapter will focus on the
control devices themselves. These components or
systems usually are part or under the control of the
Process Automation or IT department. These areas
are expert in maintaining the systems and providing the
necessary service and training to allow the end user
(operations) the ability to employ their benefits.
However, qualification of the control components and
their software must still be performed by qualified
personnel.
Throughout this chapter, reference will be made to
computers, computer systems, automated devices, and
controllers (or control systems). In short, all of these names
apply to components that control or cause to be controlled
any step or operation in the production of a drug or
medical device. These include units that control the
Abbreviations used in this chapter: BMS, building management
systems; CFR, Code of Federal Regulations; COTS, commercial
off-the-shelf; CSQMP, Computer System Qualification Master
Plan; CSV, computer system validation; DCS, distributed control
systems; EEPROM, erasable electronically programmed random
only memory; EPROM, electronically programmed random only
memory; EMI, electromagnetic interference; FAT, factory accep-
tance test; FDA, Food and Drug Administration; GAMP, good
automated manufacturing practice; GMP, good manufacturing
practice; HMI, human–machine interface; I/O, input/output; IQ,
installation qualification; ISPE, International Society for Pharma-
ceutical Engineering; IT, information technology; MMI, man–
machine interface; MRP, materials resource planning; OQ, oper-
ational qualification; PAT, process analytical technology; PCs,
personal computers; PDA, Parenteral Drug Association; PLCs,
programmable logic controllers; PQ, performance qualification;
QA, quality assurance; QU, quality unit; RFI, radio frequency
interference; SAT, site acceptance test; SCADA, supervisory
control and data acquisition; SOPs, standard operating
procedures.
opening or closing of valves, take in process samples, or
assist an analyst to determine if the process meets its
predetermined acceptance criteria.
Several types of “controllers” are used in the
pharmaceutical industry. Each one has its own purpose
in production control. Starting with the simplest to the
most complex there are microprocessors (i.e., “chip”), the
PLCs, the PCs, SCADA, and DCS.
Microprocessors are found in almost every type of
unit used in the manufacturing (such as the digital
thermometer, barcode readers, etc.). PLCs are found in
such units as packaging line printers, filling machines or
the control of blenders, or other process equipment. PCs
are often found in laboratory settings and in online
testing and report generation equipment. Each of these
can be used as stand-alone (that is operate indepen-
dently) or linked together in a network with other
components. Even if linked into a system, they may
still perform functions independently of the others in
the system, or they may call on another unit to complete
the process. SCADA or DCS systems are used to control
a larger portion of the process. For example, SCADA
and/or DCS systems can control, monitor, or assist in the
full operation of a process from the initial blending
through granulation and drying. DCSs may even be
involved in inventory control, warehousing, or other
functions needed for total plant operation.
Each of these system or individual units (as in the
PLCs) can and usually are linked in a network designed
and maintained to control, monitor and report on the
production or quality of a pharmaceutical product
(including medical devices). As with any other qualifica-
tion, their qualification ranges from the relatively simple
to the very complex depending on the unit, its use, and
its configuration.
The validation of automated control systems is
substantially more complex than just the qualification
of the hardware (equipment). One must also take into
account the software being run on the system and the
interaction between the hardware and the software. The
software qualification is discussed in Chapter 46 of this
book and is only touched on or referenced in this
chapter.
This chapter will focus primarily on the qualifica-
tion of the hardware and deal with the software only as it
influences the hardware qualification. In order to differ-
entiate this from other qualification programs this chapter
will refer to automated control system qualification
as CSV.
In general, software qualification, as mentioned in
the various sections below, requires vigorous testing
620 VIII: COMPUTERIZED SYSTEMS
along with its associated hardware. This testing needs to
include the actual operation of the field instruments
(valves, etc.), as well as the recording and storage of the
data generated. Any changes to the set points of the
instruments needs to be recorded and logged.
As discussed in this chapter, software qualification is
usually separated into two distinct activities: the struc-
tural testing and the functional testing. The structural
testing includes the vendor audit, review of the code and
checks on the integrity of the code so that there is no dead
code (i.e., nonoperational code that may cause a “crash”
or data error).
SCOPE
This chapter will cover the qualification of various types
of computer systems that includes automated devices
used in the control of pharmaceutical/medical devices.
While Chapter 46 covered the background and software
validation/qualification aspects of CSV, the hardware
still needs to be qualified. This chapter will deal with
the qualification of the various types of computer or
automated control system qualification.
The intent is to provide the reader with an appreci-
ation of the complexity and the similarities of all types of
computer or automated system qualifications. It is a
general guide as to what is required to qualify/validate
the controlling systems used in pharmaceutical, bio-
technology or the medical device industry.
As stated in the introduction, all computer or
automated controllers require qualification; the level of
qualification is dependent upon its function. The industry
generally has adopted the GAMPa levels of software
systems. There are five levels of systems according to
the guide; these are:
& Firmware—This is the microchip type of system
& Operating System—The software performing the
underlying operation of the system (e.g., Windows
XPw)
& Standard Software Package—Non-configurable, also
called “off-the-shelf”
& Configurable Software Package—Standardized
packages that the owner can configure to fit their
specific needs or operations. These can perform a
general function, e.g., blending, these are termed
“COTS” or “configurable off-the-shelf”
& Custom Software—Prepared specifically for the
operation (usually prepared by specialty firms or
in-house programmers).
Each level above requires its own level of qualifica-
tion, increasing as the level goes up (the highest level is
the custom system). Notice that the levels are related to
the software and not the hardware. This is because the
hardware serves as the framework in which the software
performs its function. The interaction of the software and
hardware needs to be qualified. It is not possible to do
qualify one without the other.
a
GAMP Guide for Validation of Automated Systems, Ed. 4, ISPE
2001.
GENERAL TESTING ALL SYSTEMS
All computers or automated controllers that are used in
or for the production of pharmaceuticals or medical
devices require qualification prior to their use in the
process. Computers need qualification just as any other
system or component of the manufacturing process
does. The main difference between general equipment
qualification and CSV is that, as mentioned above, there
are two stages for the completion of a computer or
computer system. These include the software and hard-
ware aspects of the system. The first part of any CSV
program is the qualification referred to as structural; the
second phase of the qualification is the functional aspect
of the systems. The structural qualification and portion
of the program is focused on the development of the
software, while the functional qualification focuses on
the actual operation or function of the system. Chapter
46 deals with the structural qualification aspect, this
chapter will concern itself primarily with the functional
aspects of the qualification program.
As with software qualification, the hardware can be
divided into various stages. Each stage requires a quali-
fication phase in order to demonstrate that it is complete.
These stages can be divided as follows:
& Development—establishing system requirements
& Build—obtaining the correct components
per specifications
& Implement (this is where the full qualification program
is required)
& Operation (part of the full qualification program where
a qualified state needs to be maintained)
& Retirement—decommissioning the system for replace-
ment by another system
Functional qualification follows the same pattern as
any other pharmaceutical equipment or systems qualifi-
cation. Thus, in order to perform a functional
qualification as described in chapter 9 of this book, an
IQ and an OQ are necessary (Refer to chapter 9 for general
IQ and OQ requirements).
The IQ provides verification that the system is
installed according to a written preapproved plan. The
same is true for the OQ. All pharmaceutical systems
should have the following:
& Vendor qualification via an audit
& User specification
& Design specifications
However, in addition to the “usual” requirements
for IQs and OQs the qualification of computer systems
requires some additional items. Some of these are:
& Verification of system security
& Controlled access to the program
& Levels of access—e.g., an operator is allowed to
input data but the supervisor is allowed to
approve the data
& Protection of the system from outside interference
(e.g., no access via phone lines or the internet)
Note: Usually an intranet connection will
be allowed.
& Ability to track all entries (audit trail) into the
system—this includes the date, the person making
the entry and why the entry is made or changed.
 47: VALIDATION OF CONTROL SYSTEMS 621

BLACK BOX VS. WHITE BOX TESTING
There are two methods of testing automated control
systems. These are referred to as “white box” and
“black box” testing. Both means of qualification are
used for systems at or above Level 2 of the GAMP
classification of computer systems. The difference
between “white” and “black” box testing is in the level
of testing of the software. Black box testing is primarily
functional testing while white box testing includes a
review of the source code (of the software program) as
well as the means of code development.
When doing black box testing the operation of each
portion of the software is tested. In addition, the testing
establishes that each function necessary for the correct
operation of the unit(s). Typically, the black box testing
grows exponentially with the amount of I/O while the
white box testing grows linearly.
GENERAL DOCUMENTATION
When beginning a CSV program, as with other qualifica-
tion programs, certain documents need to be either
prepared or collected. Since the qualification will
involve components not usually seen and usually not
accessible having the correct documents at the very
beginning of the project will help assure its success. The
list below covers the main documents to be prepared or
collected:
Prepare:
1. CSQMP
2. User requirements
3. Functional specifications
4. Traceability matrix (Note: To be prepared AFTER all
specifications and protocols have been collected and
developed but BEFORE protocol execution).
5. SOPs (to include the “How to Prepare” SOPs)
a. System setup/installation
b. Data collection and handling
c. System maintenance
d. Backup
e. Recovery
i. Backup
ii. Crash
iii. Jam/freeze
f. Contingency plans (emergencies)
g. Security
h. Change control
i. Storage
6. Protocols
a. Commissioning
b. IQ
c. OQ
d. PQ (as necessary)
Collect:
1. Ladder logic—As necessary for PLCs
2. Design or Vendor specifications for each com-
ponent—part of the system (network interfacing,
MMI)
3. Software version to be installed
4. Software source code (or 3rd party agreement)
After the documents are prepared and or collected,
you are ready to begin the qualification program itself.
(Note: this is assuming that the structural qualification
has been completed and is acceptable). As with all
qualification programs the commissioning phase
usually is the first “field” effort undertaken. (Note: This
follows the FAT and SAT portion of the program.) The
commissioning portion of the qualification can be
performed, at least in part, during the installation of
the system. For example, while the lines are being run
to the field instruments the loop checks can be performed.
A loop check is a check of continuity (and thereby
function) of the connection between a field instrument
and the controller. It is far simpler to perform and
document the loop check as each loop is being installed
rather than after the system is intact and ready to operate.
Other items that can be performed during the installation
or as part of the commissioning phase are:
& Instruments adjusted/calibrated (loop checks)
& Ambient conditions
& Temperature
& Humidity
& Alarms and events (general testing—operational
testing is left to the OQ phase of the qualification)
& Graphics
& Data base location
& Network configuration
The next phase of the qualification is the IQ. As
pointed out in Chapter 9 this may be done at the same
time or before the commissioning phase of the program.
Either during or even before the IQ is started the
structural phase of software testing is completed. Since
the structural testing includes items such as the vendor
audit, the code review, this part of the qualification must
be completed prior to any functional or OQ testing as
discussed below.
The general IQ consists of the following verifica-
tions. Specific tests will be pointed out later for each of the
types of automated systems.
1. List all components
a. Input devices—HMI and/or MMI
i. Keyboard
ii. Mouse
iii. External devices
& Field instruments,
& External drives,
& Monitors, etc.
b. Output devices
i. Screen
ii. External data device—hard drive
iii. Printer
iv. Filed instruments
c. Data storage devices
i. Hard drives
ii. MP3
iii. Floppy drives
iv. Flash cards
v. Tape/CD/DVD (backup)
2. List type of hardware
a. Mother board—chip type
b. Controller cards
i. Video
ii. Sound
iii. I/O
622 VIII: COMPUTERIZED SYSTEMS

c. Internal drives It is during the OQ testing that the software under-

i. Floppy goes its functional testing.
ii. CD In general, the OQ will have the following general
d. Output connections tests:
i. USB 1. Prepare test of each component listed in the IQ
ii. Parallel a. Meets design specifications
iii. Firewire b. Meets functional specifications hardware
iv. Serial c. Power limits—may be included as part of the PQ
v. S Video (below)
vi. Other monitor connections i. Recovery after power loss
e. Network cards (discussed below) ii. Power line stability
3. Check for: d. Environmental stress
a. Tight connections e. Alarms
b. Correct component type f. All component functions over their full range
c. Installed in the correct location (as applicable) g. Software
d. Model as per specifications i. version verification
4. Power (source and distribution) ii. Ladder logic or source code reviewb
a. Volts h. Input limits (boundaries)
b. Current i. Functional testing
c. Stability 2. RFI—that is a radio frequency should not cause the
d. Surge protection controller to malfunction (allow incorrect data in or
5. Software (includes the structural testing—see below) out)—e.g., a walkie-talkie (handheld radios).
a. Version installed 3. EMI—a magnetic field should not interfere with the
b. Source code verification data integrity—e.g., an electric drill
i. Annotation 4. I/O integrity
ii. Dead code 5. Calibration
iii. Vendor testing verification (part of vendor 6. Software
audit) a. Compete structural testing
c. Compliance to good software preparation b. Functional testing
The OQ follows the IQ. This set of testing cannot i. Restart after shutdown
start until the IQ is complete or until the QU gives ii. Restart after power loss
approval (as discussed in Chapter 9). In the case of iii. All major operations function and results
automated systems, the completion of the IQ is necessary are appropriate
since the system will not function as specified without all If a PQ needs to be performed (as it most likely
will), the following is a list of general tests that should be
components being installed correctly. While the system
included.
may seem to operate, some functions will be compro-
1. Power failure recovery—computer and process
mised if a component is lacking. This may not be
equipment (as seen above this may be done as part
immediately apparent but will, in the long term, compro-
of the OQ)
mise the final product. An example of this would be a
a. Recovery after power loss
missing printer. The controller would run, the machines
2. Security—system accessibility
would run, but the output data would not be able to be
a. Password challenge
expressed or recorded. This may cause the system to shut
b. Security challenge
down or to store the information that cannot be printed. It
c. Biometric security
would be printed later (if possible). This may compromise
d. Levels of access
the next lot of material being produced since it will get the
3. Archive/retrieve data in real time
incorrect label or printout. 4. Produce batch report
5. I/O Loops operation
b
Ladder logic and source codes need to be reviewed for compliance 6. Data lines transmission
to good code writing requirements (General Principles of Software 7. General data integrity
Validation; Final Guidance for Industry and FDA Staff January 11, 8. Interference between programs/components
2002, FDA—U.S. Department Of Health and Human Services,
9. Software
Food and Drug Administration Center for Devices and Radio-
logical Health Center for Biologics Evaluation and Research)
a. Full operation of all functions in conjunction with
Included in this is a review for problems involving dead code. the entire system
Ladder logic (is the programming code used for PLCs) should be b. Stress the software boundaries
reviewed for functionality as well as annotations. While the source c. Noninterference between modules or other
code of higher systems (PCs, etc.) also needs to be reviewed (e.g., programs
for dead code but also for annotation of the sections), it is usually
not possible to do a line by line review of the code for these
systems. This is why one additional requirement is that the code is SPECIFIC SYSTEMS
available for and able to be corrected if needed. This last require-
ment is usually met by “Third Party Agreements” with the code The next part of this chapter will deal with some of the
developer (e.g., storage but accessible under limited access if specific requirements needed to complete an adequate
required). qualification of different types of automated systems.

As was seen above, computer or automated control
systems require both software and hardware qualifica-
tion. The software qualification has adopted the GAMPw
approach while the hardware has retained the basic
IQ/OQ/PQ approach. The specific types of systems
that will be discussed are:
& Microprocessors
& PLCs
& PCs
& Networks
& SCADA
& DCS—all forms
All of these require some form of software and
hardware qualification. Starting with microprocessors as
the simplest of the control systems and working up to the
DCS, the basic qualification approach outlined above and
in chapter 46 applies. The discussion of networks, while
not actual control systems, needs to be considered since
any of the above control or automated controllers can be
networked forming larger control systems or
controls loops.
Microprocessors
These simple controllers exist throughout the process
industries. Their purpose is usually a single function
such as turning a light on and off on a schedule. Thus,
they are more than simple switches. Other examples of
microprocessor controllers are:
& A light may come on and a camera activate in
response to a door opening.
& An alarm may be triggered by a door not closing
within a set period of time.
& The closing of the door may activate another timer
that will keep the light on for a given period.
& A micro switch may be pressed during production
based on some activity; this in turn activates a
microprocessor to count the events.
This kind of controller provides basic functionality
within equipment and rooms or facilities. These control-
lers usually do not allow any change in configuration;
that is a change in the type of control or timing of the
system. However, a microprocessor may be an EPROM or
may be or the type that is EEPROM. Both the EPROM and
the EEPROM require software qualification as well as the
standard functional testing of the microprocessor. The
software is accessible only through another computer and
even then only with specialized software. This software
requires control both in access to and in validation of the
program itself. The EPROM or EEPROM will then need to
be able to verify the latest version of the software
programmed in (this is a “burn-in” process similar to
using writing a read-only CD). The validation of the
programming software, the EPROM or EEPROM, is
basic tests and verifications of operation.
Most often this type of control, such as those that
provide standard environmental lighting or activate
pumps or heaters included within larger systems are not
a regulatory focus. However, that does not mean they can
be ignored. As long as the basic functional testing is
appropriate, as long as their function within the facility
is part of the wider design and that functionality is tested
when it affects product, they do not require a separate
qualification or validation.
47: VALIDATION OF CONTROL SYSTEMS 623
Programmable Logic Controllers
In the pharmaceutical industry, the PLC is probably the
mainstay of all operations. The PLC can be found in a
variety of operating units. They are used to open or close
any type of field device (i.e., valves, air pressure control,
motors). In general they are easy to program (hence the
name). In contrast, microcontrollers (microprocessors) are
related but very different. Microcontrollers are essentially
single microprocessors where the controller hardware on
the circuit board is customized to the device. Once the
microcontroller code is installed into the device from the
manufacturer, it is very difficult to change, and similar to
the EPROM or EEPROM noted above.
In contrast, a PLC is a much more complex
controller. It can be viewed as multiple microprocessors
in a single unit. However, the big difference is that they
are more easily programmed. By its very nature, it has a
much more complex and richer instruction set. It typi-
cally has much more memory, redundancy, and
processing power as well. Though PLCs are mass-
produced, typically PLC code (called ladder logic as
apposed to source code used for PCs and higher types
of controllers) and hardware wiring are customized for
each device based on the customer’s specific needs.
Because the code is to be customized by the client
(operating company), the PLC manufacturers testing of
the operating system software is usually only on a high
level. This leaves the true qualification work to the owner.
PLCs fall into several of the GAMP4 categories,
depending upon their configuration. The more standard
controllers, like those for lab bench analyzers and sterili-
zers could be category 2 or 3; and complex, more
customized equipment, like filling systems or lyophili-
zers, could be category 5. However, since PLCs are
relatively easily to program and are most often custo-
mized to the specific client use, GAMP4 category 5 is the
most likely approach. That is full testing will be required.
From a risk assessment standpoint, PLCs typically
have the highest direct safety risk (both human and
equipment), SCADAs and DCSs are next, then database
systems—and safety is only one small aspect of the risk
assessment process.
For a simple PLC controller, say less than 20 I/O,
black box testing makes more sense than white box.
However, for anything more than 20 I/O or for systems
with a HMI, white box is probably more effective than
black box testing. The amount and type of testing is
related to the amount of code, the amount of user-
specified coding versus vendor coding, the actual use in
the process (i.e., what equipment it will be used to
control), and other factors as outlined in the GAMP
guide.
An example of PLC qualification can be seen as
follows:
Assume that a machine has two sensors, A and B.
When sensor A is on, we want to turn on alarm horn A. In
addition, when sensor B is on, we want to turn on alarm
horn B. In addition, when sensors A and B are on, we
want to shut down the machine. In 99% of the cases,
programmer will cause sensor A to set a bit that causes
the output alarm horn A to turn on; and sensor B to set a
bit that causes the output alarm horn B to turn on. When
both of these bits are on, the machine will stop.
624 VIII: COMPUTERIZED SYSTEMS
From a black box testing perspective, this is very
difficult to catch. You must, in fact, black box test all
possible combinations of the interlock conditions in each
of the four states (good, going into alarm, alarming, going
into good). For our example, the black box testing would
contain eight tests alone! On the other hand, white box
testing could be done on six of those states, leaving two
for black box.
A typical protocol for the average PLC should be
about 90% white box (Ladder logic or code review) and
10% black box (functional). The number of total tests is
exponentially proportional to the amount of I/O and
code. Therefore, for 50 I/O, there may be 2500 tests.
That is, there may be 2500 interactions between inputs,
outputs, and internal conditions. A test protocol with
white box testing would examine dozens of these
interactions in a few test cases, using the duplicity of
the structure with which they were created (if there was a
structure).
The testing for all network-rung paths and all
possibilities, as well as questioning the operating
system integrity, would take longer than the testing of
inputs, outputs, and screens in a black box fashion.
For another example, assume we have a system of
five inputs and five outputs. For the short term, we will
ignore the complexities that can be built into the operator
interface. Given an input, or combination of inputs, some
outputs happen. Let us say that input 1, vessel pressure
high, causes output 1 vessel vent valve, to actuate. The
requirements and design documents will probably state,
“Open the vessel vent valve when the vessel pressure is
high.” Most protocols would include a single test—
stimulate the input, observe the response output. This
must be done for each of the I/Os.
Continuing with the 5!5 example, if the system is
such that the position of the outputs will not feed back in
to how the system responds (meaning that the PLC does
not care that the vessel vent valve is open as it goes on to
do its other tasks), then each input should have 32 tests
(on or offZ2 positions, with five inputs, 32Z2 5).
Assuming that the protocol is written such that the
other output expected results are inclusive in the 32
tests, there should be 32 tests for five inputs to generate
five outputs. The argument is that this is more than the
number of tests necessary for white box testing. By
following the code in the white box analysis, then there
will be only one path to test for each input and one path
for each output, for a total of 10 tests.
Of course, as more interlocks, sequences, and other
rules are added to the complexity of the PLC logic, the
advantages are harder to see—though they are still there.
Items to verify for PLCs:
& Review the ladder logic
& Correct version installed
& Inputs and outputs
& Environmental conditions
& Point-to-point testing—Loop checks
Personal Computers
PCs are relatively easy to qualify. The reason for this is
that most of the software used on a PC is off-the-shelf
non-configurable. That is, the software cannot be
changed. Only the application is configurable. For
example, Microsoft Excelw spreadsheet program can
neither be validated nor qualified. However, the appli-
cation of each spreadsheet must be qualified. Specifically
each calculation needs to be verified from both its
algorithm to its data input and output.
All aspects of the PC need to be qualified, just as any
other process or laboratory equipment. All I/O devices
(e.g., keyboards, disk drives, USB inputs of outputs,
mouse control and other pointers, screen displays, prin-
ters, etc.) need to be tested and demonstrated to be
functioning correctly. This means that the data being
input is the same as the data coming out. For example,
when typing the letter “M,” the keyboard should respond
only to the M from the designated key and the screen
should display only an M from that designated key. The
same holds true for any data storage device, whether
internal or external.
One difference between PCs and other automated
controllers is that very often the data is taken off the PC
and stored in an external device (tape drive, external hard
disk, etc.). In this case the data transfer to the devices used
for storage as well as the recovery of the data from the
device needs to be qualified. Storage time of the data on
the external device as well as the environmental con-
ditions it is stored under are factors in this qualification.
Code review for vendor-supplied programs is not
required. This includes the operating system. A word of
caution here is that the last statement assumes that there
are many hundreds of units of the same program on the
market and thus errors in the code have been readily
observed and corrected. Thus, if one purchases or
prepares a new operating system, specific for the appli-
cation, then this would require full qualification as
determined by the GAMP4 approach.
There are other areas that extra caution is needed
when using PC for control operations. One of the biggest
areas of concern in the use of PCs is their ability to
connect to the “Internet.” The Internet is an outside
link, i.e., opening the system to other computers, and
should be avoided. Data security and integrity are key
issues in dealing with any automated control system.
Items to verify on a PC:
& All input devices
& All output or data storage devices
& Data integrity both in and out of the PC
& PC calibration
& Software:
& Operating and off-the-shelf programs do not
usually require qualification
& Application software and applications on off-the-
shelf programs do require qualification (e.g.,
COTS—Commercial off-the-shelf software)
& Environmental conditions—Temperature/humidity/
liquids
Networks
PLCs and PCs may be linked together to form a
“Network.” Simply, a network is a group of individual
units (PCs or PLCs) linked together so that information
can be easily shared. There are two basic types of
networks, open and closed. In the pharmaceutical
industry, the closed network is the preferred type. As
described above with the PCs, the internet represents an

open system and thus the greater possibility of
data corruption.
Networks come in many formats. In the early days
of networking, two or more computers were connected
by regular wires between the units. The next stage was
the use of “twisted pair” wiring. This made use of part of
the telephone wires for connecting the computers. This
gave way to the Ethernet and now the wireless network.
Each of these earlier types of networks still exists,
although some to a much lesser degree. Each requires
their own special approach to qualification.
For example if a system transmits data used on
batch records, and that this data is the active record—that
is, regardless of any printouts of this data, the active data
that the company uses is this electronic record—like a
maintenance log for a piece of equipment used in drug
manufacture. The security needs to be tied to the record,
and typically, the record is tied to a database system. In
this case, if users were transmitting this data over the
network, then the network should be validated. However,
that validation is usually a subset of validation of the
database system (with tests that make sure clients can talk
to servers and so forth). In addition, there is typically
some platform validation performed to ensure that the
network has appropriate bandwidth and can handle
traffic flow correctly.
A risk assessment should truly answer when to do
network validation. For example, if the network is only
used for backing up servers, then the firm would develop
a set of requirements, specifications, and tests regarding
how servers are backed up (in this case a worst-case
scenario would involve data quantity as opposed to
network loading). If the network were only used for
client interaction to the server, then the firm would
develop requirements, specifications, and tests around
network loading, response speed, and server time-outs—
packet “sniffer” software will typically analyzes this.
Let us assume for a minute that the firm has a large
multiuser database system that is being tested prior to
plant roll out. In the test room, there are a couple of clients,
the server, and a network switch that are all tested and
validated. Now the system is placed on the plant network.
The firm discovers from an investigation that there
are a number of differences: some of the clients PCs on the
network are using older operating systems. The network
itself is larger and more complex and uses hubs, routers,
and firewalls. Will it be necessary to retest all the aspects
of the application? No. Is the application still validated?
Yes. What is needed is to resolve and test aspects of
the network.
If “Yes” start by analyzing the test network and the
live network. A good packet sniffer available for free is
Ethereal (1). Based on where packet collisions occur it can
detect what part of the networks are having an issue and
resolve it. The firm can use the test system to develop data
transmission requirements (based on what the sniffer
reveals) and then validate to those requirements on the
live system.
Validate the network with the application
(assuming that both the application and the network
relate to predicate rule records or processes), and then
“qualify” the network platform for all the systems that
use it. So, for example, a database client–server system is
validated with the network structure in place, and then
47: VALIDATION OF CONTROL SYSTEMS 625
the network is “qualified” to be able to handle all the
other client–server systems it has to carry (that is,
bandwidth and capacity are evaluated).
Items to consider for network qualification:
& All major components of the network (e.g., PCs,
routers, switches)
& Point-to-point testing
& Qualify networks that are related to predicate
rule data
& Use the risk assessment approach to determine the
extent of a network qualification
& Transport layers
& Application layers
& Commissions to specifications
& Validates to requirements
& Security (refer also to Part 11)
& Open system
& Closed systems
& Collision reconciliation
& Node operation
Larger automated systems such as discussed below
are similar to the smaller systems described above. All of
the same type of testing needs to be done for these larger
systems. The difference is in the complexity of the system
and the amount of time required completing the qualifi-
cation program. In general, the larger the systems the
more time it will require to qualify since there are an
increased number of variables to test. With more compli-
cated systems, it is more important to follow a full
qualification program starting with the development of
a Validation or Qualification Master Plan. This plan
should be specific for the system(s) involved, its intended
use and the type of hardware and software to be used.
Supervisory Control and Data Acquisition
SCADA systems are made up of several components.
Each of these components may be qualified as separate
units or combined into one large qualification program. A
SCADA system is made up of:
& HMI—The screen is often a touch screen
& Control Units—Controlling the field devices
& Main Processor—Interprets the information form the
field units/PLCs and the operating instructions from
the HMI
As with all automated or computerized systems,
security and data integrity are primary issues. Each of the
components needs to be secure from outside interference
as well as internal problems resulting from adjacent
equipment or component problems. Alarms are key to
the functioning of a SCADA system. They alert the
operator of problems in carrying out the instructions
inputted by the operator or the recipe.
Items to verify for a SCADA qualification:
& Alarms
& Loop checks
& Point-to-point are unique
& Field unit verifications
& Input devices
& HMI
& Access levels
& Supervisor
& Operator
626 VIII: COMPUTERIZED SYSTEMS
& Disks
& Tapes
& Graphics
& Is the system represented correctly on the screen?
& Data acquisition and data integrity
& Is the screen a true representation of the system?
& Is it a touch screen?
& Interface between the screen and the system (i.e.,
valves, temp. control, etc.).
& Does the screen do what is indicated in the
system?
& Calibration
Distributed Control Systems
DCSs have evolved over the years into sophisticated
units. These systems are usually involved in more than
just pharmaceutical manufacturing. They are found in
inventory control, warehousing, ordering, maintenance,
and manufacturing controls. BMS and MRP Systems are
examples of DCS systems. These systems integrate many
functions into one package. The BMS controls and
monitors the environmental conditions in the facility. It
can prepare documentation on the environmental status
of any part of the plant if requested or as part of a batch
record. It can monitor the fire alarms or access to
restricted areas.
MRPs on the other hand, are made up of sub-
modules that monitor or control inventory, financial
records, warehousing operations, production schedules,
etc. While not all sub-modules are GMP systems, all must
be considered in order to assure that no part interferes
with any other part during their operation.
As BMSs are configurable off-the-shelf packages,
risk assessment should focus on testing on the configured
and customized portions of the package and not on the
standard components of the package. For example, the
package allows the firm to graphically trend points.
Testing should therefore ensure that the set of points to
be trended is correctly configured, but the operation of
zoom, forward, and back buttons on the standard trend
screen can be ignored.
Items to verify for a DCS:
& Individual node/unit can function independently
& No interference between units
& No interference between users
& Each node/unit can be qualified independently
& Environmental conditions for each node
& Input and Out devices
& Network qualification
& HMI qualification
PART 11
No discussion of computer or control system qualification
will be complete without at least an overview of Part 11 (21
CFR Part 11). This part of the CFR has caused the
pharmaceutical industry great concern in recent years
due to its perceived complexity. Part 11 has been around
since 1997 but has only recently become more strictly
enforced by the FDA. The reason for this is, the FDA
allowed the industry time to comply, by updating their
control systems, updating their operating procedures,
training, etc., before strict enforcement would be
implemented. According to the latest guidelines,
systems put into operation prior to 1997 are usually
considered exempt from the Part 11 rules. However,
caution needs to be taken here, as any change to the
system after the 1997 start, may bring the control system
under Part 11 requirements.
When one looks closely at the requirements, they
are really quite understandable; however, their
implementation can be very complex. The FDA has
issued two sets of guidelines for this Part of the CFR.
The first set of guidelines has been withdrawn and a new
“draft” guideline has been issued. The current guidelines,
has made compliance to Part 11 regulations clearer to the
industry. The regulations have not changed; only their
perception has changed.
There are three major sections of the requirements.
These are:
& Subpart A—General provisions
& 11.1 Scope
& 11.2 Implementation
& 11.3 Definitions
& Subpart B—Electronic records
& 11.10 Controls for closed systems
& 11.30 Controls for open systems
& 11.50 Signature manifestations
& 11.70 Signature/record linking
& Subpart C—Electronic signatures
& 11.100 General requirements
& 11.200 Electronic signatures components and
controls
& 11.300 Controls for identification codes/
passwords
Subparts B and C represent the main body of the
requirements. Only an overview of the requirements will
be presented; further study will be required to fully
understand this section of the CFR.
Subpart B is concerned with any computerized
system (of any size or type) or of the people who use
these systems. Both open and closed systems are included
(11 CFR 11.10 and 11 CFR 11.30). In this part of the CFR
the FDA specifies that any system used to “create, modify,
maintain, or transmit electronic records shall employ
procedures and controls designed to ensure the authen-
ticity, integrity. and ensure that the signer cannot
readily repudiate the signed record as not genuine.”
This means that the system(s) need to be validated/qua-
lified and that, as with written records, there needs to be
traceability of all data. Access to the systems and the data
or records (electronic) needs to be limited and authorized.
Records that are maintained in paper format, as the
final, official copy are not included in this section of the
regulations. The paper records are part of what is known
as the predicate rules requirements. The predicate rules
are any rule previously established as found in 21 CFR
Part 211.
Subpart C deals with the actual control and require-
ments for electronic signatures. It describes the levels for
security and access, the need for verification of the person
signing. There are two types of identification discussed;
these are biometric and non-biometric. The non-biometric
form is most familiar to everyone. These include items
such as identification badges (picture ID) sign-in logs,
and password. If this type of identification is used, then
two forms must accompany the signature (i.e., user

identification and a password). On the other hand, a
biometric identification would include fingerprint iden-
tity, retinal scans of the eye, or voice recognition.
Biometric identification is becoming easier and less
expensive, and is available on some PCs now.
As can be seen from this short discussion of Part 11,
the regulations are not difficult; however, some aspects of
the rules may be harder to implement. All control systems
have, or should have, limited access to both the system
and the various levels of data (e.g., operator, supervisor,
and administrator). Any change in the data needs to have
a “trail” indicating “who” made the change and why the
change was made (similar to changes in paper records).
Thus, compliance to Part 11 has become achievable and,
with the new Guidelines from the FDA, it has become
more understandable. However, care needs to be taken
with all computerized systems to be sure that all of the
Part 11 regulations are implemented.
ACKNOWLEDGMENT
The author acknowledges the assistance and input from
John Hannon on several of the topics in this chapter.
BIBLIOGRAPHY
Code of Federal Regulations 21 CFR Part 11, 2006.
Code of Federal Regulations 21 CFR Part 211, 2006.
Code of Federal Regulations 21 CFR Part 211 (21 CFR Part 11),
2006.
FDA Computerized Devices/Process Guidance, May 1992.
FDA General Principles of Software Validation; Final Guidance
for Industry and FDA Staff, January 11, 2002.
FDA Guidance for Industry—PAT:A Framework for Innovative
Pharmaceutical Manufacturing and Quality Assurance
(draft guideline), August 2003.
47: VALIDATION OF CONTROL SYSTEMS 627
FDA Guide to Inspection of Computerized Systems in Drug
Processing, February 1983.
General Principles of Software Validation; Final Guidance for
Industry and FDA Staff, U.S. Department Of Health and
Human Services, Food and Drug Administration Center for
Devices and Radiological Health Center for Biologics
Evaluation and Research—January 11, 2002.
Good Automated Manufacturing Practice (GAMP) Guide for
Validation of Automated Systems, ISPE, 2001, GAMP 4.
Good Practice and Compliance for Electronic Records and
Signatures—Parts 1 and 2, ISPE and PDA, 2002.
Guidance for Industry Part 11, Electronic Records; Electronic
Signatures—Scope and Application. U.S. Department of
Health and Human Services Food and Drug Adminis-
tration Center for Drug Evaluation and Research (CDER)
Center for Biologics Evaluation and Research
(CBER) Center for Devices and Radiological Health
(CDRH) Center for Food Safety and Applied Nutrition
(CFSAN) Center for Veterinary Medicine (CVM) Office of
Regulatory Affairs (ORA), August 2003.
Guidance for Industry PAT—A Framework for Innovative
Pharmaceutical Development, Manufacturing, and
Quality Assurance—U.S. Department of Health and
Human Services Food and Drug Administration Center
for Drug Evaluation and Research (CDER) Center for
Veterinary Medicine (CVM) Office of Regulatory Affairs
(ORA) Pharmaceutical CGMPs, September 2004.
ISPE C & Q.
IVT article on PLCs.
King JH. A Practical Approach to PLC Validation, Institute of
Validation Technology. Special ed. Computer Validation II,
2005.
Technical Report No. 18, Validation of Computer-Related
Systems, PDA, V49, number S1, 1995.
http://www.ethereal.com/
http://www.pacontrol.com/PLC.html
http://www.pacontrol.com/SCADA.html
http://www.pacontrol.com/DCSystem.html