Canonical Data at the Edge: Why Source-Side Mapping Matters

A mixed-vendor floor speaks a dozen dialects — a spindle speed, a cycle-complete signal, and a fault code all look different on a FANUC, a Siemens line, a Brother machine, and a Modbus-fronted press. The common reflex is to deal with that difference late — in the historian, the SCADA, or a cloud pipeline — after multiple downstream systems have each had to handle multiple protocols. The integration cost can then start to scale with both the number of machine types and the number of downstream systems.

The idea: map once, at the edge, before routing

A canonical data model is one shared vocabulary that doesn't depend on which controller produced a reading. The approach is to map supported readings into that canonical vocabulary at the edge, where the required values are available — before any routing decision is made. Where equivalent values exist, a reading from a 2009 machine and a 2024 cell can be mapped to the same canonical signal, so the diversity is handled once, at the boundary, rather than in each system that consumes the data.

Why "at the source" helps

• Downstream systems need less protocol-specific logic. Your historian, SCADA, and analytics read canonical signals rather than vendor-specific ones.
• The pipeline stays deterministic. With the canonical shape fixed at the source, the transform that follows is testable and replayable — the same input produces the same output, which is what makes the path auditable rather than a black box.
• One shared vocabulary across supported machines. When the required signals are mapped into the existing canonical vocabulary, downstream systems can often remain stable while the edge layer absorbs the new collector logic.

Where it applies

Any mixed-vendor, brownfield floor — exactly the plants where late mapping tends to turn into a maintenance burden that scales the wrong way.

Common mistakes teams make

• Mapping late. Pushing raw vendor data downstream can push protocol-specific handling into multiple downstream systems.
• Formatting for one destination. Shaping data for a specific dashboard bakes in rework when the destination changes.
• Tag sprawl. Several names for the same physical quantity, because nothing mapped them to a shared vocabulary.

How Elpis approaches it

EdgeConnect is the protocol-agnostic edge runtime: it collects from supported sources using FANUC FOCAS2, MTConnect, Brother HTTP, Modbus TCP, Siemens S7, and from OPC UA Servers through its OPC UA Client capability. It then maps supported readings into a canonical vocabulary at the edge, where the required values are available. It can publish mapped data onward through MQTT or expose mapped data through EdgeConnect's OPC UA Server, so SCADA, MES, HMI, historians, or other OPC UA clients can consume it. (FANUC MT-LINKi REST integration is on the roadmap.)

In short — collection / source side: FANUC FOCAS2, MTConnect, Brother HTTP, Modbus TCP, Siemens S7, and OPC UA Server data sources via EdgeConnect's OPC UA Client capability; output side: MQTT publishing and EdgeConnect's OPC UA Server. The canonical layer sits between the floor and everything else, and EREMOS V2 turns the canonical stream into OEE, alarms, and reports. Where AI appears in the platform, it stays in decision-support, outside this deterministic data path. See the architecture and the Connectivity & Edge capability for the full model.

Where to start

List the physical quantities you actually report on — run state, cycle time, counts, alarms — and define one canonical name for each. That short list is the spine of everything downstream.

Elpis IT Solutions builds an Industrial Intelligence Ecosystem — from shop-floor signal to enterprise decision. Operating across India and the Middle East.