Automation Lifecycle & Support
An automation system is specified, designed, factory- and site-tested, commissioned, qualified, handed over, and then supported for fifteen years by people who were not there. Whether it can be safely changed in year eight is determined almost entirely by decisions made at handover: what documentation was transferred, whether the configuration is readable without the integrator, and who is contracted to support it.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 23 LINKSAutomation is validated once and supported for twenty years, and the support arrangements are where the validated state is actually kept — or quietly lost, one undocumented vendor fix at a time.
06 · QUALITY MATURITY — AUTOMATION LIFECYCLE & SUPPORT, REACTIVE TO ADAPTIVE
The integrator who built it is the only party who understands it. Support is a phone call and changes arrive as fixes.
A support contract exists with response times, but vendor changes reach the system through the vendor’s process rather than the site’s.
Every change reaches the system through site change control regardless of who makes it, source and configuration are held by the site, and competence to operate the system is retained internally.
Obsolescence is tracked per component with a funded plan, and spares and engineering environments exist so a failure is a repair rather than a project.
The site could change vendor without losing the ability to run, maintain and evidence the system — which is the practical test of whether the knowledge is actually held.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 4 regulatory bodies: EMA, ISPE, ASTM, IEC.
RECORDS & OBJECTIVE EVIDENCE
- The support agreement, including how vendor changes enter site change control
- Site-held source, configuration backups and engineering environments
- Component obsolescence status with replacement plans and funding
- Records of vendor-performed changes, and their site approval
- Internal competence records for operating and maintaining the system
COMMON INSPECTION FINDINGS
- Vendor changes applied to a validated system without a site change record
- No site-held configuration backup, so recovery depends entirely on the vendor
- Components past support with no replacement plan and no compensating arrangement
- Remote vendor access used to make changes that were never reviewed
- No internal competence, so the site cannot assess what the vendor proposes
The V-model is real here, and the left side is where it fails
GAMP 5 organises computerised-system work across a lifecycle in which each verification activity answers a specification activity: site acceptance testing against the functional specification, qualification against the user requirements. ASTM E2500 makes the same argument for manufacturing systems with an emphasis on subject-matter expertise and on verifying what is critical rather than everything.
The failure is almost never on the verification side; teams test diligently. It is that the user requirements were written thinly, so the testing verifies against a specification that never captured what mattered. A requirement stating "the system shall control temperature" cannot be verified in any way that means anything, and the test that passes against it is theatre performed sincerely.
Factory and site acceptance testing buy different things
Factory acceptance testing is the last point at which a defect is cheap. It happens on the integrator’s premises with the integrator’s engineers present and no production pressure, and defects found there are fixed in hours. The same defect found at site acceptance is fixed in days, and after go-live it is a change control.
The recurring mistake is treating FAT as a demonstration rather than a test — a scripted walkthrough of the happy path, witnessed and signed. The value is in the abnormal cases: what the system does on loss of communication, on a sensor failure, on an out-of-sequence operator action, on a power interruption mid-batch. Those are the conditions that will occur in production, and the factory is the cheapest place to find out.
Handover decides what year eight looks like
The handover package is usually treated as a contractual formality and is in fact the whole support horizon. What matters: the configuration in a readable, portable form rather than only inside a proprietary tool; the control narratives that explain why the logic is as it is, not only what it does; the source or project files, with licences that survive the integrator relationship; and a defined support arrangement with response commitments and an escalation path.
The absence of the second item is the most consequential. A site that holds the configuration but not the reasoning cannot safely change anything, because nobody can tell which behaviours are deliberate. Control narratives written during the project cost little; reconstructed in year eight from a running plant, they cost a specialist contract and a lot of guessing.
SPEQ interpretation — obsolescence is a quality risk with a known date
Control-system obsolescence is managed as an engineering capital problem and surfaces as a compliance problem: an unsupported platform cannot be patched, so the security exposure grows, and the remediation carries a requalification burden that makes it a project rather than a maintenance task. Every part of that is foreseeable years ahead.
The unusual property of this risk is that it has a date attached. Vendors publish end-of-support timelines, so an obsolescence register per system — with the support end date, the upgrade path, its qualification burden and the compensating controls in the interim — turns a surprise into a planned capital item. Almost no site maintains one, and almost every site discovers the need for it during a security assessment.
FREQUENTLY ASKED
What should factory acceptance testing actually cover?
The abnormal cases: loss of communication, sensor failure, out-of-sequence operator actions, power interruption mid-batch. A scripted walkthrough of the happy path is a demonstration, not a test. FAT is the last point at which a defect costs hours instead of a change control, so it should be spent on the conditions production will actually produce.
What has to be in an automation handover package?
Configuration in a readable, portable form; control narratives explaining why the logic is as it is, not only what it does; source and project files with licences that outlive the integrator relationship; and a support arrangement with response commitments. The narratives are the most consequential and the most often omitted — without them nobody can tell which behaviours are deliberate.
Why is control-system obsolescence a compliance problem?
Because an unsupported platform cannot be patched, so security exposure accumulates, and the remediation carries a requalification burden that turns it into a capital project rather than maintenance. It is also entirely foreseeable: vendors publish end-of-support dates, so an obsolescence register per system converts a surprise into a planned item.
Where does automation qualification usually go wrong?
On the specification side, not the testing side. Teams test diligently against user requirements that were written too thinly to verify — "the system shall control temperature" cannot be tested in any way that means anything. The verification then passes sincerely against a specification that never captured what mattered.