Machine Design #44: Configuration Baseline — Which Backup Is Really Running on the Machine?
A project folder may contain files named FINAL, FINAL_v2, FINAL_v2_OK, FINAL_v2_OK_new, and backup_before_fix. The machine may actually be running another version that was edited directly at site. HMI, robot, and vision backups may have been taken on different days. When a controller fails, the maintenance team has many files but does not know which one is the known-good baseline.
This is not only a naming problem.
A configuration baseline is a set of identified and controlled configuration items tied to evidence at a defined gate. For an automation machine, a useful baseline must answer:
Which configuration was approved, which configuration is actually running, which backup can be restored, and what changed afterward?
This article presents a practical configuration-management framework for automation machines. No single tool fits every platform. Upload, download, compare, and restore must follow access rights, vendor instructions, the project change process, and system validation.
1. Separate source, backup, baseline, and as-running
Source
Source is an editable document or project: a PLC project, HMI project, robot source, vision job, drawing/CAD, or recipe master. Source may not be compiled, deployed, or tested.
Backup
A backup is a copy intended to preserve or recover data and configuration. It may come from an engineering workstation, a runtime/device upload, an asset-management system, a disk image, or an export package. Its existence does not prove that it is complete, readable, or restorable.
Release
A release is a version that passed the review and approval process for deployment or handover.
Baseline
A baseline is the set of configuration items and versions fixed at a gate such as design release, FAT-tested, as-shipped, SAT-accepted, or as-maintained. A baseline is not only a ZIP file; it includes identity, relationships, evidence, and status.
As-running
As-running is the configuration actually operating on the device at a point in time. It may differ from the release because of an online edit, site tuning, recipe change, separate HMI download, robot mastering adjustment, firmware update, or device replacement.
Configuration management makes the relationships between these states explicit instead of assuming they are always identical.
2. Identify configuration items before saying “machine backup”
An automation machine is more than one PLC file.
Control
Include the PLC project, compiled/runtime data and symbols or comments where the platform supports them, the HMI application, safety configuration, and remote-I/O or device parameters.
Motion and robot
Include servo and drive parameters, motion profiles, robot programs, frames, tools, user coordinates, mastering, and calibration data.
Vision and quality
Include vision jobs or models, calibration, thresholds and parameters, reference images, and test datasets.
Production data
Include recipes, product master data, change-part mapping, limits, and acceptance parameters.
Infrastructure
Include the industrial-PC image and services, interfaces and middleware, in-scope network/device configuration, firmware and software versions, and license dependencies.
Engineering information
Include drawings, schematics, BOM, I/O and interface lists, alarm lists, manuals, and permitted risk, validation, FAT, and SAT records.
These items may not live in one repository. The configuration plan must define the system of record for each item and how they join into one baseline.
3. A baseline needs a clear purpose
There is no single “best” baseline for every situation.
Design-release baseline
The information released for manufacturing and programming. It may not be the final running configuration.
FAT-tested baseline
The version that produced FAT evidence. Any later modification needs impact assessment and a baseline or retest decision.
As-shipped baseline
The configuration closed before shipment, traceable from the FAT-tested baseline plus approved changes.
SAT-accepted baseline
The configuration after installation, site tuning, interfaces, and accepted deviations.
As-maintained baseline
The known-good state maintained by the owner after approved field changes.
The newest file may be untested, while an older file may be known-good. Newest and baseline are different concepts.
4. Give every item an identity
Each important configuration item should have an item ID, asset or system ID, item type, owner, version or revision, tool and compatibility requirement, dependency, system of record, access classification, baseline membership, and change or release reference.
| Item | Version identity | Dependency to record |
|---|
| PLC project | release plus native project identity | engineering tool and firmware |
| HMI | release/build | runtime version and linked tags |
| Robot | program set plus calibration state | controller, tool, and frame |
| Vision | job/model plus calibration | camera, firmware, lens, and setup |
| Recipe | dataset revision | machine and software compatibility |
The filename is only one attribute. Identity must not depend solely on whoever named the file.
5. Prove what is running
Do not rely on “I remember downloading that version.” Depending on the platform, evidence can include online compare, an upload compared with a protected baseline, native checksum or signature reports, runtime build information, deployment logs, controller identity, and timestamps with user/change records.
A matching checksum is useful only when it covers the correct object. Do not assume one checksum covers online parameters, external recipes, calibration, retentive data, services, firmware, or device state. The configuration plan must state which evidence proves which item.
6. Record deployment, not only source
Source control can answer who changed what, which version exists, and which branch or release was used. It does not automatically answer which version was downloaded to which asset, when, whether it succeeded, which parameters were applied, or what was tested afterward.
A deployment record can contain the asset ID, baseline or release ID, item versions, change authorization, performer, time, tool and target state, result, verification or retest reference, and deviation. Do not store credentials or keys directly in a widely shared record.
7. Backup completeness: one project file may not be enough
Recovery may require the source project, runtime/export package, device and firmware compatibility, library and package versions, HMI/robot/vision artifacts, drive parameters, recipe and master data, calibration and mastering, license and activation process, PC image or operating-system dependencies, and restore instructions.
An upload from a controller may omit comments, symbols, source structure, or external dependencies. A project on a laptop may omit the latest runtime tuning. Record where the backup came from, what it covers, what it does not cover, which tool/version is needed, and where each dependency lives.
8. Backup, compare, and a protected baseline
A stronger workflow than “copy a file every month” is:
- Identify a protected and approved baseline.
- Take a backup from the asset on schedule or at an event.
- Compare the backup with the baseline.
- Alert or report differences.
- Classify each difference as approved, expected, unauthorized, or unknown.
- Reconcile it to a change record.
- Update the baseline when the change is approved and tested.
Asset-management platforms may automate backup, compare, version archives, and audit tracking. Capability depends on the asset type, engineering software, and license. A tool does not replace configuration ownership. When a report says “different,” the process must state who triages it and how quickly.
9. Known-good does not mean newest
Call a version known-good only when suitable evidence shows that it was reviewed or released, deployed to the correct scope, tested or validated for its impact, documented with known deviations, and covered by a repeatable backup and restore route.
The newest version may be work in progress, an untested hotfix, an upload from an asset with unexplained changes, or a project that compiles but was never deployed. During an incident, restoring newest may recreate the fault that caused downtime.
10. Restore rehearsal: opening a file is not recovery
A restore rehearsal asks whether the file can be read, the tool/version and dependencies are available, the target hardware and firmware are compatible, and a controlled target, simulator, or spare can be restored. It also verifies boot behavior, interfaces, recipe and calibration recovery, required validation or recommissioning, and realistic recovery time.
Do not experiment on a production controller. Use a planned, isolated or controlled target where appropriate and keep a rollback route. A backup that has never been rehearsed still carries unknown risk.
11. Emergency changes are where baselines break
When a machine is down, an engineer may edit online to recover production. The change may be reasonable, but it still needs reconciliation:
- Record a temporary event or change.
- Capture the as-running configuration.
- Compare it with the baseline.
- Decide which changes are retained.
- Update the source.
- Review and test according to impact.
- Release a new baseline.
- Back up and compare again.
If runtime is edited and left alone, the next download from an old project can erase the hotfix. If the upload is merely renamed “new,” source history and rationale are lost.
12. Status accounting: know where a change is
Configuration status accounting answers what the current baseline is, which changes are proposed or approved, what has been implemented, which assets were deployed, which tests are complete, which documents are stale, and which deviations remain open.
| Change | Source updated | Released | Deployed | Tested | Baseline updated |
|---|
| EC-xxx | Yes/No | Yes/No | Asset list | Evidence | Yes/No |
A small status table can be better than hundreds of emails. The aim is to prevent “code changed but drawing, test, and manual did not.”
13. Audit whether the baseline matches reality
An audit can check that the item list is complete, repository and baseline records agree, as-running matches the approved baseline, unknown changes have an owner, the latest backup succeeded, compare alerts are handled, restore rehearsal is current, tools and licenses are supportable, access and retention are appropriate, and every change record traces to evidence.
An audit is not only about finding human mistakes. It reveals when the system or process no longer reflects the machine architecture.
14. Handover must transfer recovery capability
A good handover is not just a USB transfer. Define who owns the baseline after SAT, where the system of record is, who can approve and deploy, the backup schedule and success check, the comparison baseline, retention, suitable offsite or offline copies, maintained restore tools and dependencies, and how vendor remote support changes are captured.
A backup stored on one laptop or at one site may be lost in the same incident as production. The strategy must consider independent failures that matter to the risk.
15. Cybersecurity and configuration integrity
Configuration can contain network information, accounts, certificates or keys, safety settings, recipes, process knowledge, and customer data. Do not put passwords in public filenames, send projects through uncontrolled channels, give everyone overwrite rights, use shared unaudited accounts, or disable protection for convenience.
Separate configuration artifacts, secrets and credentials, access policy, and audit/change records. Recovery must preserve confidentiality, integrity, and controlled access.
16. Safety configuration needs its own route
A safety-configuration change can affect the safety function, architecture, diagnostic coverage, timing, and validation. It is not an ordinary production parameter.
The record should trace the approved change, authorized person, safety impact, related calculation or analysis, validation or revalidation, and as-running evidence. Protected safety data and instructions for bypassing protection do not belong in public content.
17. Configuration-management failure modes
Common failures include a backup older than runtime, multiple “masters,” a PLC aligned with baseline while HMI/robot/vision are not, recipes or calibration outside the backup, a project that cannot open with available tools, missing libraries or licenses, an upload that loses source comments, an old project erasing a hotfix, an unreconciled emergency edit, an untested newest version, an unmonitored failed backup job, backups lost with production, and technical restore without recommissioning.
Include these failure modes in FMEA, root-cause analysis, and continuity planning when appropriate.
18. Automation-machine baseline checklist
- [ ] Are all configuration items identified?
- [ ] Does every item have an owner, identity, system of record, and access class?
- [ ] Does each baseline have a clear purpose and gate?
- [ ] Are FAT-tested, as-shipped, SAT-accepted, and as-maintained states traceable?
- [ ] Is there evidence for the as-running state?
- [ ] Does a deployment record link a release to an asset?
- [ ] Does the backup cover source, runtime, recipes, calibration, and required dependencies?
- [ ] Are tool, firmware, library, and license compatibilities recorded?
- [ ] Is there a protected baseline and backup/compare workflow?
- [ ] Does every unknown difference have an owner and triage path?
- [ ] Is known-good proven by test and evidence rather than recency?
- [ ] Has restore been rehearsed in a controlled environment?
- [ ] Is there a reconciliation route for emergency changes?
- [ ] Does status accounting show which asset, test, and document each change reached?
- [ ] Are credentials and keys separated and protected?
- [ ] Do safety changes have authorization and separate revalidation?
Conclusion
A configuration baseline is not a folder called “final backup.” It is a controlled relationship between configuration items, approved versions, deployment to an asset, the configuration actually running, backup and compare evidence, restore evidence, and change, status, and audit records.
When those links are complete, maintenance does not have to guess which file is correct when a controller fails. The team has a known-good baseline, knows which machine it matches, knows at which gate it was tested, and knows how to recover in a controlled way.
References
- ISO 10007:2017 — Guidelines for configuration management: https://www.iso.org/standard/70400.html
- ISO — Configuration management and information security: https://www.iso.org/information-security/configuration-management
- Rockwell Automation — FactoryTalk AssetCentre: https://www.rockwellautomation.com/en-us/products/software/factorytalk/maintenancesuite/assetcentre.html
- Rockwell Automation — Disaster Recovery capability: https://www.rockwellautomation.com/en-pl/docs/factorytalk-assetcentre/16-00-00/ftacmainen-ditamap/welcome-to-factorytalk-assetcentre/ftac-disaster-recov-capability.html
- Beckhoff — TwinCAT 3 Source Control: https://download.beckhoff.com/download/document/automation/twincat3/tc3_sourcecontrol_en.pdf
View all MINATA technical articles