GAMP 5 for control engineers, without the consultancy

GAMP 5 has a reputation among control engineers as a large amount of paperwork imposed by people who do not write code. Some of that reputation is earned by the way it gets implemented, and the guidance itself is more sensible than its reputation.

What it is

Good Automated Manufacturing Practice, published by ISPE, currently in its second edition. It is guidance, not a regulation. Regulators do not require GAMP; they require validated systems, and GAMP is the most widely used way of demonstrating one.

The central idea is that validation effort should be proportionate to the risk a system carries to product quality, patient safety and data integrity, rather than uniform across everything.

The categories

Software is classified, and the classification sets the expected rigour.

• Category 1, infrastructure. Operating systems, controller firmware, database engines. Recorded and version controlled, not validated by you.
• Category 3, non-configured. Used as supplied with default settings. Verified that it does what is needed.
• Category 4, configured. A standard product configured for this use. Most PLC and SCADA applications built from standard blocks land here. The configuration is specified, reviewed and tested.
• Category 5, bespoke. Written for this system alone. Full specification, code review, and testing traced to every requirement.

The line between 4 and 5 is argued about on every project. A program built from a library of reviewed standard blocks is genuinely Category 4; the same program with three hundred lines of custom sequence in it has a Category 5 part inside a Category 4 whole, and pretending otherwise is the kind of thing an auditor notices.

The V model

Specifications down the left, corresponding tests up the right, each test verifying the specification at the same level.

• User requirements, verified by performance qualification.
• Functional specification, verified by operational qualification.
• Design specification, verified by installation qualification.
• Configuration and code, verified by unit and module testing.

The value is traceability. Every requirement leads to a test; every test traces back to a requirement. An auditor's most common question is to pick a requirement and ask to see the evidence it was met, and the V model is what makes that answerable in a minute.

What changes about writing the program

The practical differences, for somebody who writes PLC code and now has to do it in a regulated context.

Specify first. The functional specification exists before the code, and the code implements it. Writing the program and then documenting it afterwards produces a document that describes the code rather than a specification the code was tested against.

Review the code. A second person reads it against the specification and records that they did. This is the single highest value activity in the whole exercise and the one most often reduced to a signature.

Test to the specification. Not to what the code does. A test written by reading the program tests that the program does what it does.

Control changes. Every change after validation is assessed for impact, approved, implemented, tested and recorded. This is the part that feels heaviest day to day.

Keep the evidence. Test records, review records, approvals, all retained and retrievable for the life of the system.

Where the effort should go

The second edition is explicit that critical thinking is expected, and it is worth taking seriously rather than testing everything to the same depth.

Identify which functions affect product quality, patient safety or data integrity. Those get the full treatment. A lamp driver does not.

What is required is that the reasoning is written down. An auditor is not troubled by a low risk function tested lightly; they are troubled by a system where nobody can explain why the effort was allocated as it was.

The honest caveat

Everything above is guidance about how to demonstrate control. None of it makes a program correct. A fully validated system can implement a badly conceived process perfectly, with complete documentation of having done so.