Book a consultation

FactoryTalk: Rockwell's Software Portfolio, Layer by Layer

FactoryTalk AssetCentre and Controller Version Control

The most common gap we find on controls assessments: no automated backup, no version control, and a controller whose program no longer matches the server. What AssetCentre does and how to close the gap.

Vladimir Romanov


On controls assessments, one finding appears more consistently than any other: 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.

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.

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.

How a controller program diverges from the copy on the server Two parallel timelines. The server copy stays at the last agreed version. The running program receives online edits during breakdowns at intervals over months, opening a widening gap between them. How the gap opens, and why nobody notices Server copy What is actually running online edit 02:00 fault another edit 3 weeks later and another 6 months ? today last agreed gap Nothing breaks today. The cost lands the moment somebody needs to restore or modify, because "what is actually running?" now has no reliable answer and every offline change is unsafe to download.
It is not a dramatic finding and it does not stop production today. It is the reason a two-hour breakdown becomes a two-day breakdown.

What AssetCentre does

FactoryTalk AssetCentre automates the parts that depend on discipline:

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.

Version control with history. Each backup is versioned, so you can see what a controller held last Tuesday and compare it with today.

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.

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 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 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.

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.

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

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.


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

← FactoryTalk Software

Have a project that needs technical ownership?

Send us the situation. If it is not something we should take on, we will say so.