MachineTool
| Document | OPC 40501-1 |
|---|---|
| Version | 1.02.0 |
| Published | 2024-11-01 |
| Namespace | http://opcfoundation.org/UA/MachineTool/ |
| Sector | Machine tools |
OPC UA for Machine Tools is the richest OEE-ready companion specification. It defines MachineToolType with production state machines, ProductionStatisticsType counters, tool and tool-life models, monitoring types for channels and spindles, condition classes that act as standardised downtime reason codes, and a prognosis family that predicts stoppages.
Where it sits in the stack
MachineTool builds on Machinery, which builds on IA and DI, so a MachineTool server also exposes MachineIdentificationType, MachineryItemState and, where implemented, MachineryOperationMode. It is the model umati was built around and the one with the best free public implementation, which is why it is the best place to learn machine-data collection even if you work in another sector. Version 1.02.0 dates from November 2024, and the release tags for it also appear as 1.2.0.
The types that matter
| Type | What it carries |
|---|---|
MachineToolType | The root object type for a machine tool, aggregating identification, production, monitoring, tools and notifications. Match HasTypeDefinition against this to know whether you have a modelled machine or a folder of tags. |
ProductionType | The production branch of the machine: the active program, the active job, the part being produced and the statistics. This is where an OEE client spends most of its time. |
ProductionStatisticsType | The closest thing OPC UA has to a ready-made OEE counter block, holding produced and rejected part counts and related production figures at machine level. |
ProductionStateMachineType | The production state of the machine as a Part 16 state machine with CurrentState, LastTransition and transition events, so state duration is derivable rather than sampled. |
ProductionJobStateMachineType | The state of the current job, which is what lets a stoppage be attributed to an order rather than only to a machine. |
ProductionProgramStateMachineType | The state of the running NC program, useful for separating program-driven stops from machine faults. |
MachineOperationMonitoringType | Machine-level operating data and the mode and maintenance state machines, including MachineOperationModeStateMachineType and MaintenanceModeStateMachineType. |
ChannelMonitoringType | Per-channel monitoring on a multi-channel control, alongside SpindleMonitoringType, WorkingUnitMonitoringType, LaserMonitoringType and EDMGeneratorMonitoringType for the technology-specific units. |
ToolLifeType | Remaining tool life with its limit, used with ToolType, MultiToolType and ToolListType. Tool life is both a quality driver and the most predictable source of micro-stoppages. |
ToolBreakageConditionClassType | One of the standardised condition classes that function as portable downtime reason codes. The siblings are ToolChangeConditionClassType, ProcessIrregularityConditionClassType, PartMissingConditionClassType, ClampingConditionClassType, MeasurementConditionClassType, ManualProcessStepConditionClassType, OperatorConditionClassType and UtilityConditionClassType. |
ProductionJobEndPrognosisType | One of the prognosis types that tell you in advance what will interrupt production. Its siblings are ToolChangePrognosisType, ToolLoadPrognosisType, PartLoadPrognosisType, PartUnloadPrognosisType, MaintenancePrognosisType, UtilityChangePrognosisType, ProcessChangeoverPrognosisType and ManualActivityPrognosisType. |
ProductionActiveProgramType | The program currently running, with its identification and state, so counts and cycle times can be attributed to a specific program revision. |
Using it on a real machine
- Check capabilities and namespaces firstRead the server's ServerProfileArray and its ServerCapabilities codes, then NamespaceArray for http://opcfoundation.org/UA/MachineTool/ and the Machinery URI. The presence of AC tells you whether condition classes will be usable at all.
- Find the machine, then its typeBrowse the Machines folder from Machinery and read HasTypeDefinition on each child. A MachineToolType instance means your mapping will port to the next vendor; a BaseObjectType folder means per-machine tag mapping.
- Subscribe to the state machinesMonitor CurrentState on the production state machine, the job state machine and the operation mode, plus the transition events. State plus mode gives availability with planned and unplanned separated.
- Read counters from ProductionStatisticsTake produced and rejected counts from the statistics object rather than edge-detecting a cycle boolean, and store the raw counter with every delta so a reset is visible in the data.
- Subscribe to conditions with a proper filterCreate an event monitored item on the machine with a select clause covering ConditionClassId, SourceNode, Time, Severity, Message and ActiveState. ConditionClassId is what turns an alarm into a standardised reason code, and calling ConditionRefresh after connect gives you the currently active set.
- Consume the prognosis nodesSubscribe to the prognosis objects present on the machine. A predicted tool change or job end is a scheduled micro-stoppage, which is exactly the loss most OEE systems record as unexplained.
What it gives you for OEE
MachineTool is the best OEE surface in the whole companion-spec ecosystem, and each of the three terms has a real source. Availability comes from ProductionStateMachineType plus MachineOperationModeStateMachineType and MaintenanceModeStateMachineType: state machines with transition events, so durations are exact rather than inferred from sampling, and planned maintenance and setup are separable from breakdowns. Performance comes from ProductionStatisticsType counts against the active program and job, with ProductionActiveProgramType giving you the program revision to compare cycle times fairly. Quality comes from the rejected counts in the statistics plus the PartQuality and measurement condition information. The genuinely distinctive parts are two. The condition classes are standardised downtime reason codes: ToolBreakage, ToolChange, PartMissing, Clamping, Measurement, Operator, Utility, ManualProcessStep and ProcessIrregularity, arriving as timestamped Part 9 conditions with a ConditionClassId, which means your reason taxonomy is portable across vendors instead of hand-mapped per machine. And the prognosis family tells you before the machine stops why it is about to stop, which almost no OEE system consumes today. What is still missing is planned production time and standard cycle time, which come from MES or ERP.
Gotchas
- Optional nodes decide the project. ProductionStatistics, the prognosis objects and the condition classes are all optional, and plenty of shipped machines expose the identification and state and nothing else. Browse a real machine before quoting the scope.
- Condition classes need Part 9 support. If the server does not implement alarms and conditions, or does not advertise the AC capability, there are no reason-code events to subscribe to no matter what the type inventory says.
- Version naming is inconsistent between the nodeset Model element (1.02.0, 2024-11-01) and the release tags (1.2.0). They are the same release; record the Model element value per machine.
- The public umati server is a simulation. It is ideal for building and testing a client, but its state durations and counts are synthetic, so do not calibrate an OEE algorithm against them.
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.