MachineVision
| Document | OPC 40100-1 |
|---|---|
| Version | 1.0.0 |
| Published | 2019-07-11 |
| Namespace | http://opcfoundation.org/UA/MachineVision |
| Sector | Vision |
OPC UA for Machine Vision models a vision system as a controllable unit: an operating-mode state machine, recipe management for the inspection programs, configuration management, and result management that hands out inspection results. It does not carry images. Version 1.0.0 dates from 2019 and the model has been extended rather than revised since.
Where it sits in the stack
This is a system-level control interface, deliberately scoped so a vision system can be operated from a PLC or MES without either side knowing the vendor's toolchain. It does not model cameras, lighting or the inspection algorithms, and it does not transport image data, which is the single most common expectation mismatch. Machinery Result later generalised the result-handling pattern that started here, so on a modern line a vision system may expose both. The asynchronous machine control extension, published separately in 2024, adds the request and response handling this first version left thin.
The types that matter
| Type | What it carries |
|---|---|
VisionSystemType | The root object for the whole vision system, holding its mode state machine and the recipe, configuration and result management objects. This is what you match with HasTypeDefinition. |
VisionAutomaticModeType | The automatic operating mode, where the system runs a selected recipe under external control. This is the mode a production integration uses. |
VisionStepwiseModeType | The stepwise mode, intended for commissioning and diagnosis, where execution advances one step at a time. |
VisionManualModeType | The manual mode, where the system is operated locally. Reading the active mode is how you know whether the data you are collecting reflects production. |
RecipeManagementType | The recipe interface: which inspection programs exist, which one is selected, and the methods to add, remove and activate them. Recipes are handled as opaque vendor artefacts with standard management around them. |
ConfigurationManagementType | The system configuration counterpart to recipe management, covering the setup that is not part of an individual inspection program. |
ResultManagementType | Where inspection results are made available and where the methods to fetch and acknowledge them live. This is the object a data-collection client actually cares about. |
Using it on a real machine
- Read the operating mode before anything elseFind the VisionSystemType instance and read which mode is active. Results collected while the system is in manual or stepwise mode are commissioning data, not production data, and mixing the two quietly corrupts a quality analysis.
- Treat recipes as opaque identifiersThe model manages recipes without describing their content. Capture the active recipe identifier and its version with every result, and do not attempt to interpret the recipe body, which is vendor-specific by design.
- Fetch results through result management, not by polling tagsUse the result-handling objects and methods rather than subscribing to individual outcome variables. Vision systems produce results in bursts and per-variable polling loses them.
- Do not expect imagesThe model carries results and references, not image payloads. If you need images, agree a separate transfer with the vendor, typically a file share or the vendor's own protocol, and keep only the reference in OPC UA.
- Pair with Machinery for contextA vision result on its own tells you a part failed. To know which order, station and machine state it failed under, take identification and state from Machinery and order context from Machinery Jobs or ISA-95 Job Control.
What it gives you for OEE
Quality only, and only partly. The inspection result is a genuine good or bad judgement at part level, which is the hardest OEE input to get honestly, so a vision system exposing this model is worth wiring up for the quality factor alone. What it does not give you is availability or performance: there is no production state machine in the Machinery sense, no cycle counter and no stop-reason taxonomy, and the operating-mode state machine describes the vision system rather than the machine it inspects. Counts of parts produced still come from the machine or line controller. Watch the boundary carefully, because a vision system that stops inspecting does not stop the line, and its own downtime is usually invisible in the line's availability figure.
Gotchas
- No images. This is the expectation gap that derails vision integrations, and it is a deliberate scope decision, not an omission.
- Version 1.0.0 is from July 2019 and the base model has not been revised. Vendors have filled gaps with their own extensions, so two conforming systems can differ considerably in what is actually usable.
- Result handling in the base model is thin. Where a vendor supports the asynchronous machine control extension, use it, because request and response correlation in the base model is easy to get wrong under load.
- Recipe management methods are frequently read-only in practice. Confirm which methods are executable before designing a recipe-changeover workflow around 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.