Companion specification · Tier 1

Machinery Energy

DocumentOPC 40001-x
Version1.00
Published2025-11-01
Namespacehttp://opcfoundation.org/UA/Machinery/Energy/
SectorMachinery

Machinery Energy is the newest Machinery namespace and standardises non-electrical energy and media consumption on a machine: compressed air, gas, steam, water and similar, through interfaces for base flow, mass flow and volume flow that can be applied to existing machine structures.

Where it sits in the stack

Energy is an interface-oriented addition to the Machinery family rather than a new machine model: the interfaces are applied to machine and component objects that already exist under the Machinery base layer. It complements, and does not replace, electrical measurement, which is covered by PA-DIM on the process-device side and by the separate ECM energy and standby model. Published in November 2025 at 1.00, it is the least mature member of the family.

The types that matter

TypeWhat it carries
INonElectricalEnergyTypeThe interface that marks a machine or component as reporting non-electrical energy consumption, which is the part of a machine's energy bill that electrical metering misses.
IBaseFlowTypeThe common base for flow measurement, giving the shared structure that the mass and volume flow interfaces specialise.
IMassFlowTypeFlow expressed as mass per unit time, the correct form for steam and for gases where density varies with pressure and temperature.
IVolumeFlowTypeFlow expressed as volume per unit time, which is how compressed air and water are usually metered on a machine.
AnalogUnitRangeTypeThe core Part 8 variable type the flow and energy values are built from, carrying EngineeringUnits, EURange and InstrumentRange on the value node.
EUInformationThe unit structure with its UNECE code. Energy and flow are exactly where unit confusion causes silent factor errors, so read the unit rather than assuming one.

Using it on a real machine

  1. Establish what is actually meteredRead NamespaceArray for http://opcfoundation.org/UA/Machinery/Energy/, then check which machine or component objects carry the energy interfaces. In most plants the meter is on the header, not the machine, and the model cannot invent a measurement that does not exist.
  2. Read units before valuesTake EngineeringUnits and EURange from each flow or energy variable and store the UNECE code with the samples. Mixing normal cubic metres with actual cubic metres is the classic error here.
  3. Subscribe with a deadbandFlow signals are noisy. Use an absolute deadband in the value's own unit and a publishing interval that matches your reporting cadence rather than the sensor's update rate.
  4. Integrate flow to consumption deliberatelyA flow rate is not a consumption total. Decide where integration happens, and if the server supports historical access and aggregates, ask it for a time-weighted aggregate over the shift window instead of streaming raw samples.
  5. Join to counts, not to timeEnergy per part is the useful number. Join consumption to the production counters from Machinery or MachineTool over the same window, so the figure survives a change in line speed.

What it gives you for OEE

Energy is not an OEE term and this model does not pretend otherwise: no state, no counters, no reasons. Its value is adjacent. Energy or media per part, computed by joining this model's flow data to the production counters over the same window, is the metric that makes an OEE improvement defensible to a plant manager, because it separates a genuine efficiency gain from running the same machine harder. It is also a good idle detector: standby consumption that continues through a long NotExecuting period is real money and is invisible in an availability figure. Note the scope limit, which is easy to miss from the name: this model addresses non-electrical energy, so electrical consumption has to come from elsewhere.

Try it free: No free public server is known to expose the Energy namespace, which is unsurprising for a model published in November 2025. Read Opc.Ua.Machinery.Energy.NodeSet2.xml to see how the interfaces attach, and use a local server or the umati sample server for the surrounding Machinery structure. For the analog value pattern itself, any public demo server with AnalogUnitRangeType nodes will do, such as opc.tcp://milo.digitalpetri.com:62541/milo.

Gotchas

  • The scope is non-electrical energy. If you need kilowatt-hours, look to PA-DIM, the ECM model or a dedicated meter, not here.
  • Interfaces have to be applied by the vendor. A machine can load the namespace and still expose no flow variables, so browse for the interface on real objects before designing.
  • Flow versus total is a decision, not a given. Some vendors publish a rate, some a totaliser that rolls over, and treating one as the other produces energy figures that are wrong by orders of magnitude.
  • Published 2025-11-01 at version 1.00. Expect very few implementations and expect the model to grow.
Verify before you rely on this: The four interface types are confirmed from the released nodeset inventory; the exact variable and component names each interface contributes, and whether any electrical counterpart is included, should be read from Opc.Ua.Machinery.Energy.NodeSet2.xml before you build against it.

Once the machine speaks a companion spec, the OEE mapping is portable across vendors, which is the point at which analytics stops being a per-machine project.

See Jemba →

Last verified 7 September 2026 against OPC UA 1.05.07. Version and publication date read from the released nodeset. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.

Free download
OPC UA Machine Data → OEE Mapping Kit
Which nodes to subscribe to, how they become Availability, Performance and Quality, and which companion specification already gives you the answer, so you stop inventing tags.
Get the free mapping kit →
Free, no course, no login