Machinery Result
| Document | OPC 40001-x |
|---|---|
| Version | 1.01.0 |
| Published | 2025-07-01 |
| Namespace | http://opcfoundation.org/UA/Machinery/Result/ |
| Sector | Machinery |
Machinery Result is the quality layer of the Machinery family. It standardises how a machine reports the outcome of a processing step: a result with metadata, an evaluation such as pass or fail via ResultEvaluationEnum, processing times, and a management object with methods to fetch, filter and acknowledge results.
Where it sits in the stack
Result sits beside the Machinery base layer as its own namespace and is the piece the Machinery stack was missing for quality. It generalises a pattern that sector models had already invented independently, notably MachineVision result handling and IJT tightening results, so newer sector work is expected to reuse it rather than define its own result structure. Version 1.01.0 (July 2025) is the current release and the model is still young in the field.
The types that matter
| Type | What it carries |
|---|---|
ResultManagementType | The object a client talks to: it holds the result store for a machine and exposes the methods for retrieving, filtering and acknowledging results. |
ResultType | One result as an object in the address space, so a result can be browsed, subscribed to and referenced rather than only pushed as an event payload. |
ResultDataType | The structure carrying the result itself, including its identifier, its evaluation and the payload produced by the processing step. |
ResultMetaDataType | The context around a result: what produced it, when, against which job or recipe, and which identifiers it can be joined on. |
ResultEvaluationEnum | The standardised verdict on a result, the pass and fail style evaluation that makes a result usable as a quality signal without parsing a vendor payload. |
ProcessingTimesDataType | The timing of the processing step, which is what turns a result into a performance measurement as well as a quality one. |
ResultTransferType | The mechanism for moving large result payloads, used with the file-transfer style access rather than a single read. |
ResultReadyEventType | The event raised when a new result is available. Subscribing to it is the correct pattern; polling a result store is not. |
GetLatestResult | Method returning the most recent result, the simplest entry point for a client that has just connected and needs current state. |
GetResultIdListFiltered | Method returning result identifiers matching a filter, so a client can reconcile a shift without downloading every payload. |
AcknowledgeResults | Method that marks results as consumed, which is how a machine knows it may release or overwrite them. Without acknowledgement a bounded store overflows. |
Using it on a real machine
- Check the namespace before designingRead NamespaceArray for http://opcfoundation.org/UA/Machinery/Result/. This is a 2025 model, so absence is the normal case on installed machines.
- Subscribe to ResultReady, do not pollCreate a subscription with an event monitored item filtered to the result event type, selecting the source node, time and result identifier. Polling a result store both misses results and loads the machine.
- Fetch by identifier, in bulkUse GetResultIdListFiltered to establish what exists, then GetResultById for what you actually need. GetLatestResult is for startup and for recovering after a reconnect.
- Acknowledge what you have storedCall AcknowledgeResults only after the result is durably persisted on your side. Acknowledge too early and a crash loses results permanently; never acknowledge and the machine's store fills.
- Use the transfer path for large payloadsWhere a result carries a measurement file or image, use the transfer and file-generation methods rather than reading a huge value in one Read, which is how you hit BadResponseTooLarge.
- Map evaluation to your own quality categories onceTranslate ResultEvaluationEnum into your good, scrap and rework categories in one documented place. Rework in particular is a plant convention, not something the enum decides for you.
What it gives you for OEE
This is the quality term, and it is the most under-used part of the Machinery stack. ResultEvaluationEnum gives a per-result verdict from the machine itself, which is a far better quality input than an operator's end-of-shift scrap tally, and ResultMetaDataType lets each verdict be attributed to a job, program or part. ProcessingTimesDataType also feeds performance: actual processing time per unit compared against a standard cycle time is the performance ratio, and results are one of the few places a machine publishes real cycle timing. Two boundaries to state plainly. Good versus scrap versus rework is a plant taxonomy, and the model gives you an evaluation, not your categories. And results are per processing step, so shift-level quality still requires you to aggregate, with a defined rule for what to do about results that arrive late or unacknowledged.
Gotchas
- Published in 2025 and thinly implemented. Treat a vendor claim of result support as a question about which methods and which optional structure fields are actually present.
- Sector models built their own result handling first. A machine may report results in a MachineVision, IJT or PlasticsRubber shape rather than this one, and the two are not interchangeable.
- Result stores are bounded. If nobody calls AcknowledgeResults, results are dropped or overwritten and the loss is silent.
- Results are structures. A client that cannot decode custom ExtensionObjects will read them as opaque byte strings, which is a very common first failure on this model.
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.