A tag name is supposed to be a unique handle on one physical point, so that whenever the system reads or writes that name, everyone knows exactly which measurement is meant. A naming collision is what happens when that promise is broken: two genuinely different points end up carrying the same name, or resolving to the same path, and the system can no longer tell them apart. When that happens, one point silently overwrites or shadows the other, and data is corrupted without any error being raised. This guide explains how collisions arise, why flat and hierarchical namespaces differ in their exposure to them, and how uniqueness is enforced and collisions detected during merges and rollouts.
Naming Collision in one line: A tag naming collision occurs when two distinct physical points are given the same tag name, or resolve to the same path, so the system cannot distinguish them and one overwrites or shadows the other. Unlike a duplicate tag, where a single point is defined twice, a collision joins two different real measurements under one identity, silently corrupting the data. Collisions are prevented by enforcing uniqueness constraints and are most likely to appear during system merges and unified-namespace rollouts.
A naming collision is a failure of uniqueness. The whole value of a tag name is that it points at exactly one thing, so that when a value is stored, read, or alarmed under that name, there is no ambiguity about which physical point is involved. A collision breaks that guarantee by attaching one name to two different real points. Now the name no longer identifies a measurement, it identifies two, and the system has no reliable way to know which one any given read or write is about. The identity that the whole data model depends on has quietly become non-unique.
The consequence is usually one point overwriting or shadowing the other. If two points map to the same name in a store keyed by that name, whichever updates last wins, so the stored value flickers between two unrelated measurements or one point's data is simply lost under the other's. If the resolution shadows instead, one point becomes invisible because every reference to the shared name resolves to the other. Either way the corruption is silent: no type error, no range violation, no alarm, just a value that is sometimes one point and sometimes another, or a point whose data has vanished with no message to say why.
That silence is what makes collisions so pernicious. A crashed connection or a bad-quality flag announces itself, but a collision produces plausible-looking values that are simply attributed to the wrong point, and the fault can persist unnoticed until someone questions why a trend behaves strangely or why a point that should have data does not. Because the data keeps flowing and the numbers look reasonable, a collision can corrupt records for a long time before anyone realizes the name they trusted was pointing at two different things all along.
It is worth separating a collision from a duplicate tag, because they are different faults with different fixes. A duplicate is the same physical point defined more than once, so the redundant definitions describe the same measurement and the remedy is to remove the extras and keep one. A collision is the opposite: two genuinely different points forced under one name, so there is no redundant copy to delete, and the fix is to give one of the points a new, distinct identity. Mistaking a collision for a duplicate and deleting one entry would simply throw away a real point's data, so telling them apart matters.
The shape of the namespace strongly affects how often collisions happen. A flat namespace, where every tag name must be unique across the entire system with no structure to separate them, forces every point in a large estate to compete for names in one global pool. As the number of points grows and as different areas, sites, or teams choose names independently, the odds that two unrelated points land on the same string rise quickly, especially with common patterns like naming points after a generic function. A flat namespace offers no natural barrier between one area's names and another's.
A hierarchical namespace reduces the exposure by giving each name a context. When a point's full identity includes its place in a structure, a site, an area, a piece of equipment, and then the measurement, two points that share a short local name are still distinct because their full paths differ. This lets the same short name be reused safely in different branches, which is natural and convenient, while keeping the full identities unique. Hierarchy does not eliminate collisions, though; it moves the risk to the path level, where two branches can still be defined so that different points resolve to the same full path, so uniqueness still has to be enforced, just over paths rather than bare names.
The primary defense against collisions is a uniqueness constraint enforced when a tag is created, so that the system refuses to accept a name, or a full path, that already exists rather than silently allowing the duplicate identity. A constraint applied at definition time turns a would-be collision into an error the configurator must resolve immediately, which is far better than discovering the clash later as corrupted data. Where the namespace is hierarchical, the constraint has to be on the full resolved path, not just the leaf name, so that two branches cannot be arranged to funnel different points to the same address.
Collisions are most likely to appear at moments when two independently built namespaces come together, which is exactly when detection deserves the most attention. Merging two systems, each of which was internally consistent, can bring their name pools into conflict, because a name that was unique within each becomes non-unique across both. The same happens during a unified-namespace rollout, when many existing systems are folded into one target namespace and names that never had to coexist suddenly must. Running a collision check across the combined set before committing the merge, listing every name or path that would end up shared by more than one point, surfaces the conflicts while they can still be resolved by design rather than discovered later as damage.
For a cloud SCADA platform such as Merobix, which consolidates points from many sites into one central namespace, enforcing uniqueness at ingestion is essential precisely because the data is unified. When a new site's points are onboarded, a naming scheme that was fine in isolation can collide with names already in the central store, so checking each incoming name or path against what already exists, and requiring a distinct identity before the point is accepted, prevents a new site from silently overwriting or shadowing an existing point's data. Because the platform holds all points under one governed namespace, the uniqueness check can be applied consistently across the whole fleet, and a collision that would otherwise corrupt shared history is caught as an onboarding conflict to resolve rather than as a mysterious data problem after the fact.
A duplicate tag is the same physical point defined more than once, so the fix is to remove the redundant definitions and keep one. A naming collision is two genuinely different points forced under one name, so there is no redundant copy to delete and the fix is to give one point a new, distinct identity. Deleting one entry in a collision would throw away a real point's data, which is why the two faults must be told apart.
In a flat namespace every tag name must be unique across the whole system in one global pool, so as points multiply and different areas choose names independently, the chance that two unrelated points land on the same string rises. A hierarchical namespace gives each name a context of site, area, and equipment, so the same short name can be reused safely in different branches while full identities stay unique, though uniqueness must then be enforced on the full path.
When two independently built namespaces are brought together. Merging two systems that were each internally consistent can make a name that was unique within each become non-unique across both, and a unified-namespace rollout folds many existing systems into one target where names that never had to coexist suddenly must. Running a collision check across the combined set before committing the merge surfaces the conflicts while they can still be resolved.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.