octoplant Smart Compare: What a Program Compare Tells You, and What It Cannot

octoplant Smart Compare is the comparison engine in AMDT’s version control. It answers one question precisely: what is different? AMDT says Smart Compare “identifies the exact differences between versions and device states” (AMDT, change management and version control), and that a user can “see exactly what changed between versions or between the stored version and the live device state” (AMDT, About octoplant).

That sounds simple. It is also the step that separates a pile of backups from evidence. This page covers the two kinds of compare, the three views AMDT describes, what a compare cannot tell you, and how to use it at acceptance tests and after integrator work. It sits under octoplant version control and change management.

Two directions: version against version, stored against live

Version against version compares two stored versions: what changed between last month’s approved program and today’s. It is the compare an approver uses before releasing a new reference, and the one an engineer uses when a fault started “sometime after the March changes.”

Stored against live compares the approved version with what is actually running, uploaded from the device. It is the compare that finds online edits, a contractor’s unrecorded fix or an unauthorized change. Run on a schedule against the approved version, it becomes change detection.

An illustrative scenario. A filler starts rejecting bottles for underfill on Thursday. The version history shows no approved change since February. A stored-against-live compare on the filler controller shows two differences: a fill-time parameter and a disabled level-sensor check, both edited online. Without the compare, the team would troubleshoot valves and sensors for a shift. With it, the question becomes who made the edit, why, and whether to reverse it, and that conversation takes ten minutes.

Graph, table and text: the octoplant Smart Compare views

AMDT says users can “compare versions graphically and in tabular form” and get “change detection and analysis exactly how you need it: in graph, table, or text form” (octoplant.com). AMDT’s public pages do not describe each view in detail, so the following is how such views are generally used, not a specification:

• Graphical view. Suits ladder logic and function block diagrams, where an engineer reads the logic visually and needs to see which rung or block changed.
• Table view. Suits parameters, tag values, drive settings and configuration lists, where the question is “which of 400 values changed?”
• Text view. Suits structured text, scripts and configuration files from network devices or PCs, where a line-by-line difference is the natural form.

Which view you get for a given device depends on AMDT’s support for that device and editor version. A deep, element-level compare for one controller family and a file-level “these bytes differ” result for another are very different tools. Ask for a demonstration on your own devices, and check the supported devices overview.

What a compare tells you, and what it cannot

It tells you:

• Which logic elements, blocks, parameters or files differ
• Whether the running device matches the approved version
• When, through the version history, a difference first appeared

It cannot tell you:

• Intent. A changed timer preset looks the same whether it was a careful fix or a mistake.
• Semantics. A compare sees a changed contact. It does not know that the contact bypasses a guard interlock. Reading the consequence needs an engineer who knows the machine.
• Process effect. Whether the change improves throughput or will cause scrap next week.
• Who, on its own. Attribution comes from the version history and the audit trail, and for an online edit the device itself may not record who made it.

Noise matters too. Some engineering tools change metadata, timestamps or compile artefacts on every save, and some live values drift during normal operation. A compare that flags these as differences trains people to ignore it. Ask how octoplant filters them for your devices.

Using octoplant Smart Compare at FAT, SAT and after integrator work

Acceptance tests are where undocumented changes are born. The program passes the factory acceptance test, ships, and is then edited during installation, start-up and the first weeks of production. Our guide to the factory acceptance test for plant controls covers the test itself; compare is how the program state is held still across it.

1. Capture at FAT. Check in the program that passed as a named version.
2. Compare at SAT. Compare that version with what is installed. Every difference should map to a punch-list item or a documented field change.
3. Compare at handover. The delivered program should match the documented, approved version. “As-left equals as-documented” becomes a checkable condition.
4. Compare after warranty work. When the integrator or OEM returns, compare before and after.

This is the kind of discipline a commissioning support engagement should enforce, whichever tool provides the compare.

Compare around upgrades and migrations

Firmware updates, engineering software upgrades and platform migrations are where compare earns its keep a second time. Opening a project in a newer editor version often converts it, and the converted file can differ from the original in ways nobody intended to change.

1. Check in the pre-upgrade version as a named version before anyone touches it.
2. Check in the converted project as a separate version, before any functional edits.
3. Compare the two. Every difference should be explainable as conversion. Anything else is a change that slipped in and needs an owner.
4. Only then make functional changes, each in its own checked-in version.

This is the practical form of a recommendation in NIST’s OT security guide: where automated configuration management tools are used, processes should be in place to validate configurations before deployment (NIST SP 800-82 Rev. 3, section 6.2.4.2).

Keeping conversion and functional change in separate versions means that when a line misbehaves after the upgrade, the team can tell in minutes whether the cause is the new firmware, the conversion or the edit, instead of reopening the whole project to find out.

Compare scenarios at a glance

Scenario	Compare type	What you are looking for	Who reads the result
Approving a new version	Version vs version	Only the intended changes are present	Approver
Line fault after a recent change	Version vs version	Which change preceded the fault	Controls engineer
Scheduled check of the plant floor	Stored vs live	Drift from the approved version	Controls lead, OT security
Integrator handover	Stored vs live	Delivered program matches documentation	Project engineer
FAT to SAT	Version vs version	Field changes, each with a reason	Project engineer, QA
Suspected unauthorized change	Stored vs live	Exact scope of the change	OT security, controls lead
Before a disaster recovery restore	Version vs version	That the restore target is the right one	Maintenance lead

The last row links to disaster recovery: restoring the wrong known-good version is a real risk when several look alike.

Where it gets hard

• Coverage depth varies. The compare is only as detailed as AMDT’s support for each device and editor version, and the official matrix sits behind the myAMDT login.
• Large projects. Comparing big projects takes time; AMDT has worked on compare speed for TIA Portal in past releases, so confirm current performance on your largest project.
• Reading is a skill. A compare across a large program can return hundreds of differences after a firmware or editor upgrade. Someone has to separate the meaningful from the mechanical.
• No judgement included. A clean compare proves the program matches the reference. It does not prove the reference was right.

Back to octoplant version control and change management, the AMDT hub, or across to check-in and check-out.