octoplant Check In Check Out: The Edit Cycle and Who Can Do What

octoplant check in check out is the planned-change path in AMDT’s version control: an engineer takes the approved version out of the repository, edits it in the vendor’s own engineering tool, and puts a new version back with an explanation. AMDT describes it in one sentence: 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).

The question this page answers is practical: what does that cycle look like on a working day, what does it demand of the people doing it, and what happens when somebody does not follow it. For the model behind it, read the parent page on octoplant version control and change management.

The octoplant check in check out cycle, step by step

A typical planned change, as the cycle is described publicly. The detail of each screen depends on the octoplant release and the device type.

1. Check out the approved version. The engineer takes the current reference for the device from the repository. Starting here, not from a copy on a laptop, is the whole point.
2. Open it in the native tool. Studio 5000, TIA Portal, an HMI editor or a robot program editor. octoplant does not edit logic itself; the engineer needs the right licensed version of that software.
3. Make and test the change. Offline, then at the machine during the agreed window, with a download to the device.
4. Check in a new version with a comment. The comment says what changed and why: the work order, the problem, the expected effect.
5. Approve, if the workflow requires it. AMDT describes “configurable approval workflows” that provide “a controlled path from modification to approved version,” with the approval becoming part of the traceable history (AMDT, change management and version control).
6. Verify. The next scheduled job uploads from the device and confirms the running program matches the new approved version. A step-by-step look at that comparison is on the Smart Compare page.

An illustrative scenario. A controls engineer adds a new SKU to a palletizer recipe table. She checks out Monday’s approved version, adds the recipe in the native tool, downloads it during Tuesday’s changeover and runs ten pallets. She checks in with the work order number and “added SKU 4471 pattern, layers 1 to 6.” The area lead opens the compare, sees only the recipe table changed, and approves. Six months later, when a pallet pattern fails, the history answers in a minute what used to take an afternoon of guessing.

What octoplant check in check out requires of people

Engineers must start every change from a check-out, keep their native tools at versions the plant supports, and write comments someone else can read in two years. The hard part is the first one, because opening the copy already on the laptop is always quicker.

Contractors and integrators need access to the plant’s repository, or a defined way to hand in versions at milestones. That belongs in the contract. Our guide to working with system integrators explains why the handover terms matter as much as the price. If the integrator works remotely, agree how they check out without a direct connection to every device.

OEM machine builders often deliver a machine with its own program and keep servicing it. Agree who owns the approved version after acceptance, whether the OEM checks in its service changes, and what happens to its warranty if the plant edits the logic.

Approvers need time in the day to approve. An approval queue that waits a week teaches people to go around it.

When someone bypasses it: online edits

Online edits are normal in plants. A breakdown at two in the morning will be fixed at the controller, not through a check-out, and no software changes that. octoplant cannot block an online edit. Preventing one is the job of controller security settings, network access and procedure, and our OT network assessment is where that layer is usually examined.

What the system does is make the bypass visible. AMDT states that octoplant detects “planned, accidental, or unauthorized changes” and runs scheduled jobs that compare the device against the approved version (AMDT, About octoplant). The change detection page covers how those jobs work and how to triage what they find.

The rule that keeps the two worlds aligned: every online edit is followed, within an agreed time, by an upload, a check-in with a comment and, where required, an approval. Otherwise the repository drifts away from the plant and the next planned change starts from the wrong version.

Comment and approval discipline

A version history is only as useful as its comments. “Updated” tells an auditor nothing. NIST’s OT security guide asks for exactly this: document, test and approve changes before they are deployed, and keep the approved baseline documented (NIST SP 800-82 Rev. 3, section 6.2.4.2). The comment and the approval are where that record lives.

• Name the reason. Work order, deviation or problem, in a consistent format.
• Name the effect. “Raised jam timer on infeed conveyor from 2 s to 3 s” is checkable.
• Separate the approver from the author. One person should not approve their own change into the reference.
• Approve against a compare, not a comment. The approver should look at what actually changed.
• Match approval to risk. Mandatory release for safety, quality-critical or validated systems; check-in with comment for low-risk changes.

An illustrative roles and permissions table

AMDT says octoplant provides “role-based access to control who can modify, approve, or restore configurations” (octoplant.com, versioning). Its role names and the edition in which each permission appears are not public. The table is a starting design for a plant to adapt, not AMDT’s configuration.

Action	Engineer	Approver	Technician	Contractor / OEM	Auditor
View versions and history	Yes	Yes	Yes	Own scope	Yes
Check out	Yes	Yes	No	Own scope	No
Check in with comment	Yes	Yes	No	Own scope	No
Approve a new reference	No	Yes	No	No	No
Restore a known-good version	Yes	Yes	Yes, with record	No	No
Configure jobs and alerts	Admin only	Admin only	No	No	No

Where it gets hard

• Concurrent work. AMDT’s public pages do not say whether a check-out locks the project or how two engineers’ changes are reconciled. Shutdowns with several engineers on one line test this.
• Native tool versions. The cycle depends on every engineer having the right version of the native tool. A project saved in a newer version can stop others opening it; the Studio 5000 project structure page shows why this bites Rockwell sites in particular.
• Remote and offline work. Engineers at an OEM’s office or a site without a stable connection need a defined route back into the repository.
• Culture. If supervisors reward the fast online fix and never ask for the check-in, the history fills with gaps.

Back to octoplant version control and change management or the AMDT hub.