Computer System Validation for Production Equipment

Computer system validation is documented evidence that a computerised system does what its specification says it does, does it repeatably, and keeps doing it in daily production. On a production machine that scope covers the PLC application code, the HMI, recipe management, inspection pass/fail decisions and any electronic record the machine creates. The evidence is built along a V-model: a user requirement specification and design documents on the way down, then Installation Qualification, Operational Qualification and Performance Qualification on the way back up, each one testing a specific document written earlier. Motionwell Automation delivers IQ/OQ/PQ documentation with GMP machines such as the liquid filling and sealing lines built under projects P23005 and P25026.

This page explains what validation means for one piece of equipment rather than for an enterprise IT system: what each stage proves, what evidence satisfies it, where GAMP 5 software categories change the workload, and why the user requirement specification decides your schedule. If you already have a URS and a validation plan, send them to an engineer and we will scope the qualification effort against them.

What Is Computer System Validation on a Production Machine?

Validation answers one regulator’s question: how do you know this machine does what you say it does? Not “we tested it and it worked” — a signed, traceable record showing a written requirement became a design, got built, installed, challenged and proven.

On a special purpose machine the computerised system is rarely one thing. It is layered:

• PLC application code that runs the sequence, motion and interlocks
• HMI or SCADA project handling recipes, operator access and alarms
• Vision or measurement software making accept/reject decisions
• Data handling: batch records, audit trails, CSV or database logging, label and code printing
• Networked equipment such as code readers, printers, drives and safety controllers

Each layer needs its own treatment. A safety relay configured from a supplier catalogue is a small job. A vision recipe written to inspect your specific part is not.

For computer system validation in pharma the expectations come from EU GMP Annex 11 and the equivalent PIC/S guidance, with 21 CFR Part 11 governing electronic records and signatures for FDA-regulated products. Singapore’s HSA is a PIC/S member, so a line built here for a local site and a line built for export are usually held to the same specification set. Record-level controls — unique user accounts, an audit trail you cannot switch off, e-signature meaning — are covered in more detail on our 21 CFR Part 11 compliance page.

How Does the V-Model Connect Specifications to Tests?

The V-model exists so that no test is orphaned and no requirement is untested. Every document on the left side has a matching qualification stage on the right. If you cannot name which document a test proves, the test does not belong in the protocol.

Read the table bottom-up and the project sequence falls out of it: design review before build, IQ before OQ, OQ before PQ. Skipping ahead doesn’t save time. It moves the failure later, where it costs more.

What Is the Difference Between IQ, OQ and PQ?

IQ OQ PQ validation is three questions asked in order: is it the right machine, correctly installed? Does it do what it is supposed to do? Does it keep doing it with your product, your people and your procedures?

Installation Qualification

IQ is a matching exercise against the design documents. Typical evidence on one of our GMP filling machines:

• As-built mechanical drawings, electrical schematics and pneumatic layouts
• Component verification against the BOM: model and serial numbers of servo drives, pumps, sensors, code readers and printers
• Material certificates for product-contact parts, plus surface finish records — SUS316L electropolished to Ra 0.4 um on the filling platform, with weld and passivation records where product-contact piping is in scope
• Calibration certificates traceable to national standards for every critical instrument
• Software and firmware versions recorded for the PLC, HMI, drives and vision system, with a checksum or program archive
• Utilities verified as connected and within specification: power, compressed air quality, extraction, environmental conditions
• Manuals, spare parts list, safety documentation including interlock and guard verification

IQ is the stage most often treated as paperwork. It is the stage that saves you two years later, when a drive fails and nobody can prove which firmware version was qualified.

Operational Qualification

OQ challenges the functional specification with scripted tests, at the limits rather than at the comfortable middle. On a filling line that means dosing at the bottom and top of the declared range, not only at the nominal volume. Typical OQ content:

• Functional test of every sequence step and every alarm, including the deliberate creation of fault conditions
• Safety function verification: guard door interlocks, light curtains, emergency stop categories, restart behaviour
• Access control by user level, and confirmation that an operator cannot change a validated parameter
• Audit trail generation, content and review — including that entries cannot be altered or deleted
• Recipe creation, approval, loading and change control
• Power-loss and recovery testing: pull the supply mid-cycle and prove the machine restarts in a defined, safe state without corrupting the record
• Backup and restore of the program and the data
• Rejection logic: force a fault part and prove it is detected, diverted and logged

Performance Qualification

PQ moves from function to process. Real product, production operators, approved SOPs, and enough runs to show the result is not a lucky one. For the P23005 and P25026 filling platforms, PQ evidence centres on fill volume held within ±0.5% of target across containers, batches and shifts, with the servo ceramic piston pumps calibrated per nozzle rather than per machine, plus cleaning and changeover performed by the customer’s own staff following their procedure. The full build is described in the GMP filling and sealing machine case study, and the equipment specifications on the custom filling machines page.

Why Is Most Machine Software GAMP 5 Category 4 or 5?

GAMP 5 sorts software by how much of it was written for you, because that is what decides how much you must test. Category 2 was retired in GAMP 5; what remains is the following.

A single machine usually occupies three of those rows at once. On the P23005 and P25026 filling platforms the PLC firmware and the HMI PC operating system are Category 1, the configured HMI project and the drive parameter sets are Category 4, and the dosing sequence with its per-nozzle calibration is Category 5. Any machine with a purpose-built sequence lands in Category 5 for its control code, whatever the HMI package sits at. That is the honest answer for gamp 5 validation on custom equipment: the PLC program is bespoke by definition, so it gets design review, code review, and functional testing traced to the functional specification. Supplier documentation can carry a good share of the burden for Categories 1, 3 and 4, provided the supplier’s quality system has been assessed. Nothing carries the burden for Category 5 except your own testing.

The consequence is a risk-based split of effort. Functions affecting product quality, patient safety or record integrity get scripted, evidenced testing. Functions affecting only convenience get lighter, unscripted assurance. That principle sits at the centre of GAMP 5 Second Edition and the FDA’s computer software assurance thinking, and it separates a validation package that protects you from one that merely weighs a lot.

How Does a Traceability Matrix Prove Coverage?

The requirements traceability matrix is one table that makes the whole package auditable. Each row starts at a requirement and ends at a signed result.

An auditor reads that table first. Gaps show immediately: a requirement with no test, a test with no requirement, a deviation with no closure. Build the matrix when you write the URS and it maintains itself. Build it at the end and you will spend a week reverse-engineering what you tested.

What Delays Validation More Than Anything Else?

A user requirement specification written too late or written too vaguely. Nothing else comes close.

Late means after detail engineering has started. By then components have been selected, the panel is laid out and the code structure is fixed. A requirement that arrives at that point — a second product format, a serialization requirement, an audit trail on a parameter nobody flagged as critical — is not a document change. It is a redesign, and it moves the FAT date.

Vague means untestable. “The machine shall be easy to clean” cannot be qualified. “Product-contact parts shall be removable without tools and cleanable per the customer’s SOP within a defined changeover window” can. Every URS line should survive one question: what test would prove this, and what result would fail it? If there is no answer, the line will become a deviation during OQ.

Three habits that keep the schedule intact:

1. Write the URS before concept approval, and freeze it before detail engineering. The phase gates are described in our guide to special purpose machine design.
2. Classify each requirement by risk while writing it, so the test effort is decided early rather than negotiated during OQ.
3. Agree the acceptance criteria and the sampling plan with your quality unit before the protocol is drafted, not while the machine is running.

Is Equipment Qualification the Same as Computer System Validation?

They overlap but they answer different questions. Equipment qualification asks whether the machine — mechanics, utilities, materials, process capability — is fit for its intended use. Computer system validation asks whether the software and the records it produces are correct, controlled and attributable. On a modern machine the two are executed as one set of protocols, because you cannot test a servo dosing function without testing the code that commands it.

The practical arrangement on our projects: engineering commissioning happens first and generates test data, then qualification uses that data where it was collected under controlled, documented conditions rather than repeating it for form. That approach follows the intent of ISPE Baseline Guide Vol. 5 and ASTM E2500, and it is what keeps a validated build from taking twice as long as an unvalidated one. Cleanroom equipment adds environmental qualification to the same structure — fan filter unit performance, recovery, particle counts — as on the cleanroom automated test equipment delivered under P23018.

Does a Retrofit or Control Upgrade Trigger Revalidation?

Control-system modernisation is the most common validation question on legacy equipment: an obsolete PLC, ageing servo drives or a dead HMI on a machine that has run validated for a decade. Retrofits are now Motionwell’s largest project family, built mainly on Allen-Bradley CompactLogix and ControlLogix with PowerFlex and Kinetix drives. Each one starts the same way.

First, an impact assessment: which functions does the change touch, and which functions share data, interlocks or records with them. Second, a documentation update — the design specification, I/O list, schematics and software inventory must describe the machine as it now exists, which is the IQ deliverable. Third, a test scope agreed with the quality unit: full OQ on changed functions, regression testing on connected functions, and a PQ run long enough to show the process still holds.

The mechanical process usually did not change, so the PQ argument rests on comparability with historical data — possible only if the original validation package was retained. Sites that kept theirs requalify quickly. Sites that did not are effectively validating a new machine.

What Motionwell Delivers with a Validated Machine

We are a machine builder and system integrator, not your quality unit — you own the validation, and your QA approves it. What we deliver into it:

• URS review, with requirements challenged for testability before design starts
• Functional and design specifications written to be traceable, with a requirements traceability matrix maintained from the URS forward
• Software inventory and GAMP categorisation per layer, with supplier documentation for configured components
• IQ and OQ protocols and execution support, including FAT at our Woodlands Link facility and SAT on your site
• PQ protocol support and execution alongside your quality team
• Safety documentation: interlock and guard verification, LVD/CE test records, and MOM lifting certification where applicable
• As-built drawings, schematics, program archives, calibration records, operator training and maintenance procedures

Record-generating systems get the same treatment. Our electronic device history record system, deployed site by site for a medical device manufacturer, is a Category 5 application validated for user access, audit trail and record integrity rather than cycle time. The same structure applies across medical device production and pharmaceutical packaging lines, where serialization data is part of the validated record set.

Frequently Asked Questions

What is computer system validation?

Computer system validation is documented evidence that a computerised system does what its specification says, does it consistently, and keeps doing it through its operating life. On a production machine that means the PLC application code, the HMI, recipe handling, inspection decisions and electronic records. The evidence is produced against written specifications through installation, operational and performance qualification, and it is reviewed and approved by the quality unit that owns the system.

What is the difference between IQ, OQ and PQ?

IQ proves the machine that arrived is the machine that was specified and that it is installed correctly: serial numbers, drawings, software versions, calibration certificates, utilities. OQ challenges every function across its operating range with test scripts, including alarms, interlocks, access levels, recovery from power loss and audit trail behaviour. PQ runs the machine with real product, real operators and real procedures to show the process holds over time.

Is PLC machine software GAMP 5 Category 4 or Category 5?

Usually both, in different layers. A configured HMI, SCADA or vision package used as the supplier designed it is Category 4. PLC application code, motion sequences, custom recipe logic and bespoke inspection scripts written for one machine are Category 5, because no other installation runs that code. Category 5 needs design review, code review and functional testing against the specification, so it carries the heaviest share of the effort.

Does a control-system retrofit need revalidation?

It needs a change control and an impact assessment, not automatically a full revalidation. Replacing a PLC, drives or an HMI changes the software layer, so the functions touched by the change are re-tested, plus any function that shares data or interlocks with them. Requalification scope usually lands as a targeted IQ update, a partial OQ, and a shortened PQ run agreed with your quality unit.