TL;DR — OPC UA for Machine Vision (OPC 40100-1)
Full spec: reference.opcfoundation.org/MachineVision/v100/docs
What Is It?
OPC UA Machine Vision defines a standardized OPC UA interface for integrating machine vision systems — cameras, smart sensors, multi-computer inspection setups — into production control and IT systems. It covers control, configuration management, recipe management, and result management of any vision system on the shop floor.
Think of it as the "universal plug" between a vision sensor and its PLC, MES, SCADA, ERP, or analytics system — replacing vendor-specific I/O, fieldbuses, and proprietary protocols.
The Problem It Solves
Without a standard interface, every vision system vendor invents their own way to:
- Control the system — start inspections, halt, reset, handle errors
- Manage configurations — calibrate and align supposedly identical vision stations
- Manage recipes — load, prepare, and switch inspection/measurement programs
- Retrieve results — get pass/fail, measurements, positions, images back to the line controller
- Monitor system state — production, standby, downtime (SEMI E10 categories)
This spec standardizes all of that into a single, vendor-independent OPC UA information model.
Core Concepts
| Term | Definition |
|---|---|
| Vision System | Any system (smart camera, sensor, multi-computer setup) capable of recording and processing digital images/video for industrial purposes. |
| Configuration | System-specific parameters (calibration, alignment) ensuring different vision systems produce equal results for the same recipe. |
| Recipe | Properties, procedures, and parameters describing a machine vision job. Content is opaque — treated as a binary blob. |
| Job | A single execution of a recipe — e.g. inspect one part, measure a diameter, scan a surface. |
| Result | The output of a job — measurements, pass/fail, coordinates, images, etc. Content is application-specific. |
| Product | A named reference used by external systems (MES, PLC) to select the right recipe without knowing internal recipe IDs. |
Architecture Overview
flowchart TB
PLC["PLC / MES / Client"]
subgraph VS ["VisionSystemType"]
SM["VisionStateMachine<br/>(Mandatory)"]
CM["ConfigurationManagement<br/>(Optional)"]
RM["RecipeManagement<br/>(Optional)"]
RSM["ResultManagement<br/>(Optional)"]
SSM["SafetyStateManagement<br/>(Optional)"]
end
PLC -->|"Reset / Halt<br/>SelectModeAutomatic"| SM
PLC -->|"AddConfiguration<br/>ActivateConfiguration"| CM
PLC -->|"AddRecipe / PrepareRecipe<br/>PrepareProduct"| RM
RSM -->|"Results<br/>(ResultReadyEvent)"| PLC
PLC -->|"GetResultById<br/>GetResultListFiltered"| RSM
PLC -->|"ReportSafetyState"| SSM
style PLC fill:#1d3557,color:#fff
style SM fill:#2d6a4f,color:#fff
style CM fill:#264653,color:#fff
style RM fill:#264653,color:#fff
style RSM fill:#264653,color:#fff
style SSM fill:#264653,color:#fff
VisionSystemType — The Root Object
VisionSystem (VisionSystemType)
├── VisionStateMachine (VisionStateMachineType) [Mandatory]
├── ConfigurationManagement (ConfigurationManagementType) [Optional]
├── RecipeManagement (RecipeManagementType) [Optional]
├── ResultManagement (ResultManagementType) [Optional]
├── SafetyStateManagement (SafetyStateManagementType) [Optional]
├── DiagnosticLevel (UInt16) [Optional]
└── SystemState (SystemStateDescriptionDataType) [Optional]
State Machines (The Heart of the Spec)
The spec uses hierarchical state machines. The top-level VisionStateMachine has an Operational state containing a mandatory AutomaticMode sub-state machine.
Top-Level: VisionStateMachineType
stateDiagram-v2
[*] --> Preoperational: Power On
Preoperational --> Halted: Halt()
Preoperational --> Operational: SelectModeAutomatic()
Preoperational --> Error: auto (error detected)
Halted --> Preoperational: Reset()
Error --> Preoperational: Reset()
Error --> Halted: Halt()
Error --> Operational: auto (error resolved)
Operational --> Preoperational: Reset()
Operational --> Halted: Halt()
Operational --> Error: auto (error detected)
| State | Purpose |
|---|---|
| Preoperational | Initial state after power-up or Reset. System must be brought to Operational. |
| Halted | Intended as final state — safe for power-down. Reached via Halt(). |
| Error | Error preventing normal operation. Needs Reset() or auto-resolution. |
| Operational | Normal operation — always a composite state with a mode sub-machine (e.g. AutomaticMode). |
Sub-Level: VisionAutomaticModeStateMachineType
stateDiagram-v2
[*] --> Initialized
Initialized --> Ready: PrepareRecipe() / PrepareProduct()
Ready --> Initialized: UnprepareRecipe()
Ready --> SingleExecution: StartSingleJob()
Ready --> ContinuousExecution: StartContinuous()
SingleExecution --> Ready: auto (job done) / Stop() / Abort()
ContinuousExecution --> Ready: Stop() / Abort()
| State | Purpose |
|---|---|
| Initialized | Management operations available (config, recipe). System not yet ready to run jobs. |
| Ready | Recipe prepared. System can accept StartSingleJob() or StartContinuous(). |
| SingleExecution | Acquires data, runs one inspection job, returns to Ready. |
| ContinuousExecution | Continuously acquires and processes data until Stop() or Abort(). |
Each state can optionally have a VisionStepModelStateMachine for fine-grained synchronization with external systems (e.g. robot moves camera between positions, triggering step-by-step acquisition).
Configuration Management
Manages system calibration and alignment so that identical vision systems produce identical results.
| Method | Description |
|---|---|
AddConfiguration | Upload a new configuration (as file) |
GetConfigurationList | List available configurations |
GetConfigurationById | Retrieve a specific configuration |
ActivateConfiguration | Activate a configuration (only one active at a time) |
RemoveConfiguration | Delete a configuration |
Key point: only one configuration is active at any time, and it affects all recipes on the system.
Recipe Management
Manages inspection/measurement programs. Recipes are opaque binary objects — their internal structure is vendor-specific.
| Method | Description |
|---|---|
AddRecipe | Upload a new recipe |
PrepareRecipe | Make a recipe ready for execution (triggers Initialized → Ready) |
UnprepareRecipe | Deactivate a prepared recipe |
GetRecipeListFiltered | Query available recipes |
RemoveRecipe | Delete a recipe |
PrepareProduct | Prepare by product name (auto-selects linked recipe) |
UnprepareProduct | Reverse of PrepareProduct |
UnlinkProduct | Remove recipe↔product association |
Recipe ↔ Product Linking
A Product is a named reference to a recipe. External systems (MES, PLC) can call PrepareProduct("WidgetX") instead of knowing the internal recipe ID. This decouples the production control system from vision-system-specific identifiers.
Result Management
Results are generated by job execution and delivered asynchronously via events and/or polling.
| Method | Description |
|---|---|
GetResultById | Retrieve a specific result by ID |
GetResultComponentsById | Retrieve individual components of a result |
GetResultListFiltered | Query results with filters |
ReleaseResultHandle | Free a result handle |
ResultDataType — What a Result Contains
| Field | Type | M/O |
|---|---|---|
resultId | ResultIdDataType | M |
resultState | ResultStateDataType | M |
isPartial | Boolean | M |
isSimulated | Boolean | O |
jobId | JobIdDataType | M |
internalRecipeId | RecipeIdInternalDataType | M |
internalConfigurationId | ConfigurationIdDataType | M |
creationTime | UtcTime | M |
processingTimes | ProcessingTimesDataType | O |
measId / partId | MeasIdDataType / PartIdDataType | O |
productId | ProductIdDataType | O |
resultContent | BaseDataType[] | O |
The
resultContentfield is vendor/application-specific — it can contain measurements, images, pass/fail data, robot coordinates, etc. The spec deliberately leaves this open.
Events
| Event | When Fired |
|---|---|
| ResultReadyEvent | A new result is available |
| JobStartedEvent | A job begins execution |
| RecipePreparedEvent | A recipe is prepared and system enters Ready |
| ReadyEvent | System enters Ready state |
| AcquisitionDoneEvent | Image acquisition is complete |
| StateChangedEvent | Any state transition occurs |
| ErrorEvent | An error is detected |
| ErrorResolvedEvent | A previous error is resolved |
System State (SEMI E10)
The optional SystemState variable maps the vision system's internal state to SEMI E10 categories for equipment utilization tracking:
| Code | State | Meaning |
|---|---|---|
| PRD | Production | Actively producing / inspecting |
| SBY | Standby | Ready but idle |
| ENG | Engineering | Setup, calibration, programming |
| SDT | Scheduled Downtime | Planned maintenance |
| UDT | Unscheduled Downtime | Unexpected failure |
| NST | Nonscheduled Time | Outside operating schedule |
Concrete Example: Inline Part Inspection
sequenceDiagram
participant PLC as PLC (Client)
participant VS as Vision System (Server)
PLC->>VS: Reset()
Note over VS: Preoperational
PLC->>VS: SelectModeAutomatic()
Note over VS: Operational → Initialized
PLC->>VS: PrepareProduct("WidgetX")
Note over VS: Initialized → Ready
loop For each part
PLC->>VS: StartSingleJob(measId, partId)
Note over VS: Ready → SingleExecution
VS-->>PLC: JobStartedEvent
Note over VS: Acquire image, process...
VS-->>PLC: ResultReadyEvent(resultId)
Note over VS: SingleExecution → Ready
PLC->>VS: GetResultById(resultId)
VS-->>PLC: ResultDataType (pass/fail, measurements)
end
PLC->>VS: Halt()
Note over VS: Halted (safe power-down)
Flow:
- PLC resets the system and selects automatic mode
- PLC prepares a product (which auto-selects the linked recipe)
- For each part arriving on the line, PLC calls
StartSingleJob()with a measurement/part ID - Vision system acquires images, processes them, fires
ResultReadyEvent - PLC retrieves the result (pass/fail, measurements, coordinates)
- When done, PLC halts the system for safe shutdown
Key Takeaways
- State machine is central — hierarchical FSM controls the entire lifecycle: power-up → operational → job execution → shutdown
- Four management pillars — Configuration, Recipe, Result, and Safety management (all optional except the state machine)
- Recipes are opaque — the spec doesn't define recipe internals; they're binary objects transferred as files
- Results are flexible — structured metadata (IDs, timestamps, states) plus a vendor-specific
resultContentpayload - Product abstraction — MES/PLC can reference inspections by product name without knowing internal recipe IDs
- Two execution modes — SingleExecution (one-shot jobs) and ContinuousExecution (continuous streaming inspection)
- Step model for synchronization — optional VisionStepModelStateMachine enables fine-grained handshaking with robots/external systems
- SEMI E10 integration — optional SystemState maps to standardized equipment utilization categories
- Event-driven results — ResultReadyEvent notifies the client asynchronously; results can also be polled
- Vendor-extensible — vendors can add custom operation modes, extend result content, and subtype data types
Relationship to Other Specs
flowchart TB
CORE["OPC 10000<br/>OPC UA Core<br/>(FiniteStateMachine, FileTransfer)"]
DI["OPC 10000-100<br/>Devices (DI)<br/>(DeviceType)"]
MV["OPC 40100-1<br/>Machine Vision<br/>(this spec)"]
MACH["OPC 40001-1<br/>Machinery BBB<br/>(MachineryItem)"]
SEMIE10["SEMI E10<br/>(Equipment RAM & Utilization)"]
AUTOID["OPC 40010<br/>AutoID"]
CORE -->|"FiniteStateMachineType<br/>TemporaryFileTransferType"| MV
DI -->|"optional device model"| MV
MACH -->|"optional integration<br/>as MachineryItem"| MV
SEMIE10 -->|"SystemState categories<br/>(PRD, SBY, ENG, ...)"| MV
MV -.->|"DataMatrix readers<br/>can expose both"| AUTOID
style MV fill:#2d6a4f,color:#fff