GAMP 5-Aligned Automation Software Documentation and Validation Support

What GAMP 5 alignment means

GAMP 5 is industry guidance for achieving computerized systems that are fit for intended use and meet applicable regulated requirements. It is not a product certification and it does not replace the regulated company’s quality management system or approval authority.

For an automation supplier, alignment means applying critical thinking and proportionate controls across the lifecycle: understand intended use, concentrate evidence on functions that can affect patient safety, product quality or data integrity, use supplier knowledge effectively, connect specifications to verification, and retain objective evidence of the approved result.

Scale the lifecycle to risk and system context

The documentation depth should reflect the system boundary, novelty, configurability, process criticality and the customer’s procedures. A TwinCAT solution may combine infrastructure and standard products, configured libraries, custom PLC code, HMI functions, databases and external interfaces. Treating the whole system as one undifferentiated software category can create unnecessary paperwork in low-risk areas while missing the truly critical custom behaviour.

1. Define intended use, process impact, regulated records and the hardware/software boundary.
2. Identify critical functions, data and failure modes through a documented risk assessment.
3. Assess supplier, platform, libraries and existing evidence.
4. Choose specifications, reviews and tests that control the identified risks.
5. Maintain traceability from approved requirements through design and verification.
6. Baseline the released configuration and define how changes will be assessed.

The supplier documentation package

The agreed package can be assembled from the following controlled artefacts. Names vary between customer quality systems, so the document map and approval responsibilities are confirmed at the start of the project.

• Planning and scope: lifecycle documentation plan, system boundary, supplier/customer responsibility matrix, intended-use statement, validation-plan input and risk-assessment support.
• Requirements and design: URS support, functional specification or FDS, control philosophy, system/hardware design (SysDS/HDS), software design specification (SDS), software module design specifications (SMDS), interface specifications, I/O and alarm schedules.
• Configuration and build: approved source revision, TwinCAT/XAE and runtime versions, library and dependency manifest, device and network configuration, build instructions, access roles and deployed-software baseline.
• Traceability and review: requirements traceability matrix, design-review records, code-review evidence, change-impact assessment, issue/deviation log and release approval record.
• Verification and qualification support: test strategy, unit or module tests, simulation and regression evidence, FAT/SAT protocols and reports, plus agreed supplier input to IQ/OQ/PQ.
• Operation and maintenance: backup and restore, disaster recovery, user/access administration, operating and maintenance information, known limitations, training, change control and periodic-review input.

TwinCAT software that can be reviewed and reproduced

The design should make critical behaviour understandable without reverse-engineering a large PLC project. Axiotech separates field I/O, devices, modules, machine states and external interfaces; uses typed structures and explicit state models; records library dependencies; and keeps the controlled source set in version control.

An SDS describes architecture, tasking, interfaces, data ownership, error handling, security-relevant behaviour and significant design decisions. SMDS documents define the responsibility, inputs, outputs, states, interlocks, alarms and test basis for important modules. Together they create a reviewable bridge between functional requirements and Structured Text implementation.

For an inherited system, the first deliverable may be a verified as-built baseline: source and runtime identity, library versions, hardware/configuration inventory, gaps in ownership or traceability, and a risk-ranked remediation plan. Retrospective documentation must describe the system that actually exists rather than inventing a design history.

Data integrity, electronic records and access control

Where the system creates or manages GxP records, the scope may also need to address EU GMP Annex 11 and, for relevant US electronic records or electronic signatures, 21 CFR Part 11. Requirements can include authorised access, audit trails, accurate and secure data transfer, time synchronisation, backup and restore, retention, record availability, electronic signatures and periodic review.

These controls must be tied to the actual architecture. A PLC alarm history, HMI recipe store, OPC UA interface, historian and MES transaction do not all have the same record ownership or retention duty. The design therefore identifies the system of record, data flow, metadata, quality state, security boundary and behaviour during communications or infrastructure failure.

For medical-device production or quality-system software, the current FDA Computer Software Assurance guidance supports a risk-based approach to establishing confidence and retaining objective evidence. Its applicability and the required records remain decisions for the regulated manufacturer.

Verification and qualification evidence

Testing is selected from the requirements and risks rather than copied from a universal script library. Reviews and static checks can verify document and code qualities; TcUnit or other automated tests can exercise deterministic calculations, state transitions, alarm timing and error handling; simulation can cover sequences and failure paths; bench and machine tests prove hardware, interfaces, motion and operator interaction.

Each formal test identifies its preconditions, approved system version, expected result, actual result, evidence, tester, date and disposition. Deviations are recorded and assessed rather than silently corrected. A successful compile is useful build evidence, but it is not evidence that the process or machine behaviour is correct.

FAT and SAT can be structured to provide reusable evidence for the customer’s qualification strategy. IQ/OQ/PQ ownership and approval are agreed explicitly: Axiotech may prepare supplier protocols, execute agreed tests or support the customer team, while the regulated organisation retains approval under its procedures.

Ways to engage Axiotech

• New automation system: develop lifecycle documents with the control design so requirements, source and tests remain aligned.
• OEM machine platform: establish reusable specifications, module evidence, release baselines and customer documentation for repeat builds.
• Software change or upgrade: assess impact, recover the baseline, update affected specifications and execute risk-based regression and acceptance tests.
• Inherited or incompletely documented equipment: perform an as-built assessment, identify gaps and create a proportionate remediation package.
• Validation-readiness review: compare available evidence with the intended use, customer procedures and applicable requirements before committing to implementation or qualification.

A useful first discussion covers the process and intended use, current control platform, available source and documents, regulated markets, customer quality procedures, required delivery date and who will approve the lifecycle documents.

Boundaries and accountable approval

Axiotech does not describe a system as “GAMP certified.” GAMP 5 is guidance, and no supplier document can transfer the regulated company’s accountability. Project proposals therefore state which documents and tests Axiotech will provide, which customer templates and procedures apply, who reviews and approves them, and which legal or regulatory assessments remain outside the supplier scope.

This boundary strengthens the offer: buyers receive useful, maintainable engineering evidence without a misleading promise. The result is a clearer route from requirement to released software, more efficient review and qualification, and a stronger basis for controlled support and future change.