FactoryTalk AssetCentre and Controller Version Control

On controls assessments, one finding appears more consistently than any other, and it is the gap FactoryTalk AssetCentre exists to close: the program in the controller does not match the program on the server, nobody knows when they diverged, and therefore every offline change is unsafe to download. This page explains how that gap opens, what AssetCentre does about it, what it costs to leave open, and how to close it with or without the product.

It is not a dramatic finding. It does not stop production today. It is the reason a two-hour breakdown becomes a two-day breakdown, because the moment somebody needs to restore or modify, the question “what is actually running?” has no reliable answer.

It belongs to FactoryTalk Software in the Rockwell Automation cluster.

How the gap opens

Nobody decides to run without backups. It happens the same way every time.

A fault at two in the morning. A technician makes a change online to get the line running. It works. The line runs. The change is never documented, never uploaded, never merged into the project on the server, and the person who made it is on nights for the next three weeks.

Repeat over years, across dozens of controllers, drives and HMI terminals, and the plant arrives at a state where the authoritative version of every program is the one inside the equipment, and the only way to know what it does is to go and read it.

What FactoryTalk AssetCentre does

FactoryTalk AssetCentre automates the parts that depend on discipline. Rockwell’s Getting Results Guide describes the capabilities below.

Scheduled automated backups. It connects to controllers, drives and HMI terminals on a schedule and pulls their current program or configuration. No engineer has to remember.

Compare against a protected master. Each disaster recovery operation compares what was uploaded from the device with a protected master file and reports differences to a recipient list. For Logix controllers it can also read changes from the controller’s own change log.

Version control with history. Files live in an Archive with check-out and check-in, so you can see what a controller held last Tuesday and compare it with today. An optional Management of Change workflow can require approval before a file is checked out for editing.

Change detection and audit. It compares what is in the device against the stored baseline and reports differences, with who changed what and when where that is available, and it keeps an event log and an audit log of user actions.

Disaster recovery. A verified, recent copy of every program on site, which is the thing you need on the worst day and cannot create retroactively.

Coverage beyond controllers. Drives and HMI terminals matter as much. A PowerFlex parameter file is the difference between a twenty-minute drive replacement and a day of reverse engineering. The guide lists asset types for PowerFlex drives, PanelView and PanelView Plus terminals and Stratix switches, and for several third-party controller families.

The economics

A plant with fifty controllers and no automated backup is carrying a risk that costs a few thousand dollars a year to remove. Against one shift of unplanned downtime caused by an unknown program state, the payback is immediate, and unlike most automation spending it does not depend on anyone changing how they work.

That is the unusual thing about this particular purchase: it is one of the few tools that improves a plant’s position without requiring a behaviour change. The backups happen whether or not anyone remembers.

Doing it without FactoryTalk AssetCentre

The product is not the only path, and for smaller sites it may not be proportionate. What matters is the capability, and it can be assembled:

• A scheduled upload from every controller, drive and terminal to a known location
• Version control on that location. Plain git is entirely adequate for this
• A documented, tested restore procedure. A backup nobody has restored is a hypothesis
• A change log with a named owner
• Periodic verification that what is in the device matches what is stored

The discipline is the hard part, which is why the automated product usually wins. A manual process depends on the same people who are busy at two in the morning.

Capability	AssetCentre	Assembled (scripts and git)	Other change management products
Fetch from devices on a schedule	Built in	Scripts or manual uploads	Built in
Compare device with stored master	Built in, reported by schedule	Manual, or tooling you build	Built in, depth varies by vendor
Readable differences in logic	For supported file types	Weak on binary project files	Varies; often a selling point
Non-Rockwell devices	Several families supported	Whatever you script	Often broader
Audit trail and approvals	Audit log and optional Management of Change	Commit history only	Built in
Cost profile	Licence by capacity plus server	Staff time, indefinitely	Licence, often by device

Which of these fits depends on the device mix and who will own it. Our vendor-neutral comparison of PLC version control software and the octoplant versus AssetCentre page cover the alternatives.

The related gap: nobody can open the file

Backups solve half the problem. The other half is toolchain availability.

A perfect backup of a version 20 project is worthless if nobody on site has a licensed copy of Studio 5000 version 20 that installs on a supported operating system. Audit both together: what is stored, and whether it can still be opened. The Product Compatibility and Download Center shows which software versions run on which operating systems.

See the version and firmware coupling section on Programming Software for why this matters more on Rockwell platforms than on some others.

A worked example (illustrative)

An illustrative scenario, not a description of any one plant.

A site with forty Logix controllers, sixty PowerFlex drives and a dozen PanelView Plus terminals has project files spread across three laptops and a shared drive. The first AssetCentre schedule uploads everything and compares it with the files the team believes are current, and several controllers differ. Each difference is reviewed with the area engineer, and the device version becomes the master unless someone can say why it should not. Within a month the site has a known baseline, a weekly compare schedule, a named owner for the difference report, and an answer to “what is running?” for every device. Nothing about production changed, and the next breakdown starts from a known state.

What we do

On any controls engagement, a verified baseline is the first deliverable, before any recommendation. We audit what is stored, what can still be opened, and where the device and the repository disagree, and we put automated backup in place regardless of whether the plant buys AssetCentre or assembles the capability another way.

It is unglamorous work and it is the highest-certainty return available at this layer. It is usually part of a plant systems assessment.

---

Related: FactoryTalk Historian · Studio 5000 Project Structure · FactoryTalk Software · Rockwell Automation hub