What Breaks When You Add a Second Site

A monitoring system that works well at one site is a system with a large number of unstated assumptions, all of which happen to be true there. The second site is where they are tested. This is the moment at which most industrial data programmes either become an architecture or become two systems, and the difference is largely decided by how many of the following were anticipated.

Naming collides first. The tags at site one were unique at site one. At site two there is another TT-101, another motor called M3, another line called Line 2. If the model has no site dimension — and single-site models rarely do, because the site was implicit — then joining the data either overwrites or requires a prefix retrofitted through every query, report and dashboard that exists. Adding the dimension before it is needed costs almost nothing; adding it afterwards touches everything.

Time follows. One site can get away with local time because everything in the system shares it. Two sites in different zones cannot, and the pathology is subtle: aggregations look right until a comparison crosses a daylight-saving boundary, at which point one site has a twenty-three-hour day and a shift report silently shifts. The rule is simple and worth enforcing from the start — store in UTC, carry the site's zone as an attribute, and convert only at the moment of display. So too for clock synchronisation: site two will have a different NTP arrangement, and possibly none, and timestamps that disagree between sites are worse than timestamps that disagree within one, because nobody can tell which site is wrong.

Units and conventions are next, and they are more insidious because they produce numbers that look fine. Site two measures pressure in bar rather than psi, flow in cubic metres per hour, temperature at a different reference. It counts a shift as eight hours where site one counts twelve. It defines "available" differently for OEE. Every one of these is invisible in a chart and fatal in a comparison, which is precisely what the second site is there to enable.

Then the network. The single-site design almost certainly assumed a reliable local link to wherever the data lands. The second site is on a different carrier, behind a different firewall administered by someone with different views, possibly on a satellite or cellular link with real latency and a data cap, and possibly in a country with rules about where the data may be stored. Store-and-forward at the edge stops being a nice property and becomes a requirement, and the answer to "what happens during an eight-hour outage" has to be a designed behaviour rather than a discovered one.

Identity and access were probably an afterthought at one site because everyone knew everyone. At two sites, the question of whether a site-two engineer can see site-one data, change site-one setpoints, or acknowledge site-one alarms becomes a real policy question with a real answer, and the system has to be able to express it. Retrofitting authorisation into a system that assumed a single trusted population is among the least pleasant migrations in this field.

Two more that are routinely underestimated. Equipment variance: site two has a different controller vintage, a different firmware, a different vendor for the same function, a machine that reports a value site one calculates. Any code that assumed a register map is now code that needs a driver layer. And operational variance: site two runs different products, has a different maintenance regime, and has its own local practice for things the first site did centrally. The data model has to accommodate that the same nominal process is genuinely not the same process.

The practical recommendation is to build the first site as though the second already exists, which costs perhaps a few percent and is the cheapest insurance in this domain. Concretely: put a site identifier in the model from day one; store UTC and carry zones; hold units and ranges as attributes rather than conventions; define the equipment model generically and instantiate it per site rather than describing site one's equipment directly; put a store-and-forward buffer at the edge even where the link is good; and write down the site's local conventions — shift pattern, calendar, product codes, definitions of availability — as data rather than as assumptions inside queries.

And when the second site does arrive, resist the strong temptation to clone the first. A copy is fast, it works, and it produces two systems that drift apart within a year and can never be compared. The point of a second site is comparison; an architecture that cannot compare has given up the main benefit for the sake of the first month.