What is a Machine Interface Data Contract?
Technical definition
The owner’s formal specification of what data a machine or packaged unit must expose at its boundary (level 1.5): identities, states, tags, units, quality flags and update rates – with acceptance criteria tested at delivery.
In brief
The machine is the supplier’s black box below the boundary – but the data interface is yours. The contract turns normalisation into a procurement requirement instead of a cleanup project.
The Challenge
Without a contract, every machine supplier delivers their own OPC UA structure, their own tag names and their own units – and the integration cost is paid by you, again and again. The contract reverses the power balance: normalisation happens where the buyer’s leverage is – in procurement – instead of afterwards in the middleware. Control loops and safety are never touched; the contract covers data exchange at the boundary, not control through it.
HubMind’s Methodology
We define one canonical information model per machine type – identity per IEC 81346, a state model (PackML patterns or Weihenstephan where they fit), mandatory tags with units and quality flags. The supplier meets the contract natively (their OPC UA server following your model) or through an edge mapping documented as data mapping and owned by you.
The delivery is approved only when the interface passes its acceptance test: structure, units, update rates and state behaviour verified like any other commissioning check. The result: the source connects to UNS-O already normalised – and machine number eight costs almost nothing to integrate.
Warnings & Pitfalls
A contract without a test: An interface requirement without acceptance criteria is a wish. The test protocol is half the contract.
Too detailed too early: Contract what is consumed – identity, states, key figures – not every internal tag. The model must be able to grow by version.
The facility side gets forgotten: BMS suppliers are less used to interface contracts than machine OEMs – all the more reason to set the requirement. An air handling unit is a machine too.
💡Our Recommendation
Put it in procurement: The contract is an annex to the machine purchase – not a project afterwards.
One model per machine type: The type/instance pattern lets every new machine inherit the structure.
Acceptance-test at delivery: The data interface is approved as part of commissioning.
Version-control the contract: The model evolves – with traceable versions and an owner.
FAQ
Do suppliers accept this? More often than you would think – especially when the requirement is set before contract signing and builds on established patterns (OPC UA companion specs, PackML, Weihenstephan). The edge-mapping alternative makes the requirement always satisfiable.
Does it not make the machine more expensive? Marginally at purchase – but it converts a recurring integration cost into a one-time cost paid by whoever knows the machine best. Total cost falls with every machine.
Can real-time data cross the boundary? Yes – the contract covers data exchange (telemetry, states, events) in real or near-real time. Control loops stay below the boundary, in the machine’s own control system.
HubMind’s related pages:
Data mapping, Requirements management and OPC UA
Standards & frameworks:
OMAC PackML and Weihenstephan Standards – established machine interface patterns
Will your next machine ship with your data interface – or the supplier’s?
HubMind helps you create machine interface data contracts with acceptance criteria – so normalisation becomes a delivery requirement.
Scope note: The UNS pattern is domain-agnostic. It applies across industry, buildings, energy, logistics, laboratories and other digitalised operations that need shared structure and governance for operational data.
« Back to Glossary Index