Machine interfaces: why two machines on one floor cannot talk

The pitch for connected manufacturing assumes a shop floor where equipment reports itself in a common language. The reality on most floors is two languages at least, and the reason is historical rather than technical. Machine tool builders in North America converged on one way of publishing data; process and automation vendors in Europe converged on another. Both approaches became standards, both are maintained, and both are genuinely open. That is the problem: openness says nothing about agreement.

Two standards, two shapes

OPC Unified Architecture is published internationally as the IEC 62541 series. It is a full communication stack with an information model on top: address spaces, typed nodes, subscriptions, security built into the session rather than bolted on. It was designed by people whose problem was plant-wide integration, and it shows. A supplier implementing OPC UA is implementing a protocol and a modelling language at the same time.

MTConnect, maintained by the MTConnect Institute, started from the opposite end. It is an XML vocabulary served over HTTP, deliberately read-only, and its original audience was machine tool shops that wanted to see what equipment was doing without granting anybody write access to it. An MTConnect agent publishes documents; a client asks for them. There is no session, no subscription model in the OPC UA sense, and that simplicity was the selling point.

Neither description is a criticism. A read-only vocabulary over HTTP is the right answer when the question is «what is the spindle doing right now and can I graph it». A typed address space with security at the session layer is the right answer when the question is «can this cell write a setpoint to that one». The trouble starts when one building contains both questions.

The companion specification, and what it does not do

The two organisations did the sensible thing and wrote a bridge. The OPC Foundation and the MTConnect Institute jointly publish a companion specification, identified as OPC 30070-1 and titled «MTConnect Part 1: Device Model», which expresses the MTConnect device and stream models in OPC UA terms. It is a real document, it is free to download from the OPC Foundation, and it means that an MTConnect device model can be exposed through an OPC UA server without either side being rewritten.

What it does not do is make the two standards one standard. A companion specification is a mapping, and a mapping has to be implemented by somebody. It tells a vendor how to express model A in language B; it does not oblige any vendor to ship that expression, and it does not retrofit anything onto equipment already on the floor. A buyer reading a brochure that mentions the companion specification should ask the only question that matters: is it implemented in the firmware of the machine being quoted, or is it a capability of a gateway that will appear on the invoice as a separate line.

What the framework standard admits

The clearest statement of the limit comes from a third document. The ISO 23247 series, published in 2021 in four parts under the title «Automation systems and integration — Digital twin framework for manufacturing», sets out a reference architecture for digital twins of what it calls observable manufacturing elements: equipment, materials, processes, personnel, facilities, products. Part 1 covers overview and general principles, Part 2 the reference architecture, Part 3 the basic information attributes, Part 4 information exchange.

Part 4 is where the honesty is. The series, as its own scope states, does not prescribe specific data formats and communication protocols. That is a deliberate choice by a standards committee that knew it could not referee between installed bases, and it is worth quoting at the next vendor meeting. The international framework for manufacturing digital twins explicitly declines to tell anybody which wire format to use. Interoperability at that layer is left to the buyer, the integrator and the contract.

Why this is a procurement subject

Nothing above is solvable by a plant engineer with a weekend and a Raspberry Pi, although that is how it is usually attempted. The decision that determines whether two machines can be read together is made when the second one is ordered, by somebody writing a specification, and it is cheap at that moment and expensive afterwards. Standards documents are the leverage available at that moment: they are public, they are citable in a tender, and a supplier that cannot say which clause it implements has told you something useful.

The hype cycle on this subject has turned over several times without the underlying situation changing much. Two standards remain, the bridge between them remains a document rather than a fact, and the international framework continues to leave the protocol question open. A shop floor that reads itself cleanly is a shop floor where somebody made this an acceptance condition.