AMDT
octoplant Version Control and Change Management: The Approved-Version Model
octoplant version control explained: the approved version, roles and approvals, compare, change detection and audit trail, and how it differs from Git.
octoplant version control is built on one idea: for every device in the plant, there is an approved version of its program or configuration, held in a central repository, and every change is either a deliberate path to a new approved version or a deviation from it. Check-out, check-in, approvals, Smart Compare, change detection and the audit trail are all ways of enforcing or verifying that single reference. Understand the approved version and the rest of the feature set reads as a system rather than a list.
This page explains that model, the roles and approvals that govern it, how the pieces fit, how it differs from the Git-based tools now entering the market, and what to check before you buy. It is an independent overview, written for engineering managers, controls leads and OT security leads. For the company and the platform itself, start at the AMDT hub.
The approved version: the core of octoplant version control
AMDT describes the working cycle plainly: teams “check out the latest approved version, make changes in their familiar engineering tools, then create and check in a new version” (AMDT, About octoplant). Every version is “stored centrally, documented, and available for comparison or rollback.”
Three consequences follow for a plant.
- There is always an answer to “what should be running?” The approved version is the reference that a restore goes back to and that a compare measures against. Without it, a plant only knows what is running, which is not the same thing.
- Engineering stays in the native tool. octoplant does not replace Studio 5000, TIA Portal, a robot teach pendant workflow or an HMI editor. It wraps them. That keeps the learning curve short for engineers and puts the burden on the tool’s device and editor support, which is why the supported devices question matters so much.
- The device is checked, not trusted. Scheduled jobs “capture current configurations and programs, and compare them against approved versions” (same source). The repository is not assumed to match the plant floor. It is tested against it.
An illustrative scenario. A night-shift technician changes a timer preset online to stop a nuisance jam on a case packer. The line runs. Under a backup-only regime, that edit lives only in the controller until somebody overwrites it with the older project on the server and the jam returns. Under an approved-version regime, the next scheduled job finds the difference, raises it, and the controls lead decides in daylight whether the change becomes the new approved version or is reversed.
Roles and approval workflows in octoplant change management
AMDT states that octoplant offers “role-based access to control who can modify, approve, or restore configurations” (octoplant.com, versioning) and “customizable change approval processes aligned with internal procedures,” which it also calls “optional” (octoplant.com, change management). The exact permission model per edition is not public, so the table below shows how plants typically divide the work, not AMDT’s role names.
| Typical role | What it usually does | Plant consequence |
|---|---|---|
| Controls engineer | Checks out, edits, checks in with a comment | Owns the change and its explanation |
| Approver (controls lead, area engineer, quality) | Reviews the compare and releases the new approved version | One named person accepts the risk before the reference moves |
| Technician | Reads versions, may restore a known-good version | Faster recovery without granting edit rights |
| External integrator or OEM | Scoped access to its own machines or projects | Work is traceable to the contractor, and limited to its scope |
| Administrator | Users, jobs, schedules, device onboarding | Keeps the system itself from becoming the unowned server nobody patches |
| Auditor or quality | Read-only history and reports | Evidence without the ability to change it |
Approval is optional, which is a decision, not a default. A packaging plant may run with check-in only and rely on change detection. A pharmaceutical site will want a formal release step, because the approval becomes part of the record an inspector reads. That record is the subject of the 21 CFR Part 11 page.
How version control, compare, change detection and audit trail fit together
The four capabilities are easy to read as separate features. They are one loop with two inputs: the planned change that comes through the engineering path, and the unplanned change that only shows up in the device.
What each piece contributes:
| Capability | Question it answers | Covered in depth |
|---|---|---|
| Version control | What versions exist, and which one is approved? | This page |
| Check-in and check-out | How does a planned change get from idea to approved version? | Check-In and Check-Out |
| Smart Compare | What exactly is different between two versions, or between stored and live? | Smart Compare |
| Change detection | Has anything in the device changed without going through the process? | Change Detection |
| Audit trail | Who changed what, when, where and why? | Compliance |
The same approved version is also what disaster recovery restores, which is why version control and backup and recovery are two views of one repository rather than two products.
How octoplant version control differs from Git-based approaches
Software teams use Git, and a growing part of the automation market is bringing Git to control logic. The two models answer different questions, and the difference matters more than any feature list. For the vendor-neutral version of this comparison, see our page on PLC version control.
| Approach | Model | Where it is strongest | What to check |
|---|---|---|---|
| octoplant (AMDT) | Central repository, approved version per device, scheduled device compare | Mixed-vendor plants, legacy assets, robots, drives and HMIs; running-versus-approved verification | Branching and parallel development; cloud options |
| Copia Automation | Git-based source control for PLC code, plus DeviceLink backup from running devices | Teams that already work in Git; cloud, data-centre or air-gapped deployment | Breadth beyond the PLC vendors it supports |
| Software Defined Automation | Browser-based “Industrial DevOps”: multi-vendor version control, backup, browser IDE, virtual PLC management | Cloud-first sites and virtual PLC projects | On-prem and legacy coverage |
| OEM-native Git (Siemens TIA Portal Version Control Interface and TIA Portal V21, SIMATIC AX, Rockwell FactoryTalk Design Studio) | Git inside one vendor’s engineering environment | Single-vendor engineering teams | It versions the project, not what is running in the device |
The distinction that matters most is where the truth comes from. Git tools are built around the developer’s project: branches, merges and pull requests. That suits new development. The approved-version model is built around the device: what is running, whether it matches, and what to put back. That suits a plant that maintains hundreds of assets it did not write. Copia now also markets device backup and recovery, positioning itself as an OT “first responder” (TNW), and SDA has added PLC vulnerability management (Automate.org), so the line between the two camps is moving. For a head-to-head, see octoplant vs Copia.
OEM Git does not remove the need for device-side verification. A Git history in TIA Portal tells you what an engineer committed. It does not tell you what is in the controller after a night-shift online edit. Plants using OEM Git still need something that reads the device. In a Rockwell-only plant, that may be FactoryTalk AssetCentre.
Governance for contractors and integrators
Most uncontrolled change in a plant arrives through people who do not work there: integrators, OEM service technicians and commissioning crews. Version control only governs them if the contract says so.
- Write it into the scope. The integrator checks out from the plant’s repository, checks in at agreed milestones with comments, and hands over with the repository matching the devices. Our guide to the systems integrator scope of work covers where this belongs.
- Baseline before they start. An approved version taken before the contractor arrives is the only way to prove later what they changed.
- Compare at handover. “As-left equals as-documented” should be a release condition, not a hope. Smart Compare makes it checkable.
- Scope their access. Role-based access lets a machine builder work on its machines without edit rights to the rest of the line.
- Decide who approves. The contractor should never approve its own change into the reference.
What the standards expect of OT change management
The approved-version model is not AMDT’s invention. Public guidance describes the same discipline, and quoting it is the quickest way to get an internal change procedure approved.
| Source | What it asks for | Where octoplant version control fits |
|---|---|---|
| NIST SP 800-82 Rev. 3, section 6.2.4.2 (NIST) | Document the approved baseline configuration of OT devices; document, test and approve changes before deploying them; consider centralising change tracking | The approved version is the documented baseline, and check-in with approval is the documented change |
| NERC CIP-010-4, R1 and R2 (NERC) | A baseline configuration per applicable cyber asset, authorised and documented changes, and for high impact BES Cyber Systems, monitoring for baseline changes at least once every 35 calendar days | Scheduled compare jobs can evidence part of the monitoring. CIP-010’s baseline also covers operating systems, ports and patches, so a program compare is one input, not the whole answer |
| MITRE ATT&CK for ICS, Modify Program, T0889 (MITRE) | Lists Audit (M0947) among the mitigations for adversaries changing controller programs | A device-against-approved compare is that audit, run on a schedule |
NIST adds a caution worth keeping. The same section notes that automated configuration management tools can move large amounts of data over the control network, and that some can affect operations by changing device configurations or manipulating active files. That is why job scheduling is a design decision, covered on the change detection page, and why utilities should read our NERC CIP page before assuming a tool closes a requirement.
Limits and open questions
- Feature split by edition is not public. AMDT publishes Core, Plus and Premium editions but no prices and no per-tier feature list (octoplant pricing). Confirm which approval and role features your edition includes. See editions and licensing.
- Parallel development is not described publicly. How two engineers working on the same project at once are handled, and whether anything resembling branching exists, is a question to put to AMDT.
- Compare depth depends on the device. Device and editor support varies and the official matrix is gated behind the myAMDT login.
- The tool records process; it does not create it. If online edits remain normal practice, the system will faithfully document a stream of deviations nobody resolves.
- On-prem first. octoplant is mainly deployed on-premises; a SaaS option for octoplant is not clearly stated as of October 2026. See octoplant architecture.
How to evaluate octoplant version control
- Which of our device types and engineering software versions support check-out, check-in and a detailed compare, as opposed to backup only?
- Can approval be mandatory for some device classes and optional for others?
- What are the roles and permissions, and can they be scoped by site, line or device?
- How are comments enforced at check-in?
- What happens when two engineers need the same project at once?
- How is a detected deviation turned into either a new approved version or a reversal, and is that decision recorded?
- Can contractors use the system without a full engineering seat on our network?
- How does history export to our ITSM or quality system? See OTSSM and integrations.
If the answers expose a gap in how changes are controlled today, that is usually a control system modernization conversation as much as a software purchase.
Deeper
- Check-In and Check-Out: the edit cycle step by step, what it asks of engineers and contractors, and what happens when someone bypasses it
- Smart Compare: version against version and stored against live, and what a compare can and cannot tell you
- Change Detection: scheduled upload-and-compare jobs, alerts, drift, and triaging a detected change
Back to the AMDT hub, or across to Backup and Recovery and octovision.
Frequently asked questions
Does octoplant version control use Git?
AMDT does not describe octoplant as Git-based. Its model is a central repository holding an approved version of each device's program or configuration. Engineers check out that version, edit it in the vendor's own engineering tool and check in a new version. Copia Automation and Software Defined Automation, by contrast, build on Git-style source control. Ask AMDT directly how branching and merging are handled if your team relies on them.
What is an approved version in octoplant?
It is the version of a device's program or configuration that the plant has accepted as the reference. AMDT describes configurable approval workflows that provide a controlled path from a modification to an approved version. Scheduled jobs then compare what is running in the device against that approved version, so any difference is visible, and it is the known-good version a plant restores to after a failure.
Can octoplant stop an engineer from making an online edit?
No change management tool can physically stop a person with engineering software and network access from editing a controller online. octoplant controls who can work with its repository through role-based access, and its change detection finds the edit afterwards by comparing the running device against the approved version. Prevention depends on controller security settings, network access control and procedure.
Is octoplant change management only for PLCs?
No. AMDT states that octoplant versions configurations of PLCs, HMIs, robots, CNC machines, SCADA, drives, network devices, industrial PCs and generic files. Coverage of any specific device and engineering software version must be checked against AMDT's current support matrix, which sits behind the myAMDT login.
How is octoplant different from FactoryTalk AssetCentre for version control?
Both use a central repository with check-out, check-in, compare and audit trail. The main difference is scope: AssetCentre is Rockwell-centric with some third-party support, while AMDT positions octoplant as multi-vendor across PLCs, robots, drives and HMIs. Which fits depends on how mixed your installed base is and what each tool supports for your specific devices.
References and further reading
- About Octoplant · AMDTThe check-out, edit, check-in cycle and scheduled compare jobs, in AMDT's words.
- Versioning & Version Control Management · AMDT (octoplant.com)Role-based access to modify, approve or restore.
- Change Management - Control Every Update · AMDT (octoplant.com)Optional approval processes and alerts for out-of-process changes.
- Pricing · AMDT (octoplant.com)Core, Plus and Premium editions, unlimited jobs, documents not counted as devices. No prices.
- SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security · NISTSection 6.2.4.2 covers configuration change control; 6.2.4.3 covers backups.
- CIP-010-4: Cyber Security, Configuration Change Management and Vulnerability Assessments · NERCR1 baseline configuration; R2.1 monitoring at least every 35 calendar days.
- Modify Program, Technique T0889 · MITRE ATT&CK for ICSLists Audit (M0947) among the mitigations.
- GitHub for the factory floor: Copia raises $26M to protect the code that runs industry · The Next Web
- Siemens boosts automation workflow with new TIA Portal V21 · eeNews Europe