MachineVision AMCM
| Document | - |
|---|---|
| Version | 1.00.0 |
| Published | 2024-05-17 |
| Namespace | http://opcfoundation.org/UA/MachineVision/AMCM/ |
| Sector | Vision |
AMCM is the asynchronous machine control extension to OPC UA for Machine Vision, published 2024-05-17 as version 1.00.0. It adds request and response handling so a controller can issue vision jobs and collect results without blocking, which the 2019 base model handled only thinly.
Where it sits in the stack
AMCM is an extension, not a replacement: it carries its own namespace, http://opcfoundation.org/UA/MachineVision/AMCM/, and sits on top of the MachineVision base model, which in turn is a system-level control interface rather than a device model. A server implementing AMCM will carry both namespaces, and a client that loads only one of them cannot resolve the inherited types. The pattern it adds, an asynchronous job request with a correlated response, is the same problem Machinery Result and Machinery Jobs solve for the machinery stack, so on a modern line the same information may be reachable two ways.
Using it on a real machine
- Check for both namespacesRead NamespaceArray and expect the MachineVision URI and the AMCM URI together. AMCM alone is not a complete model, and a client loading only the AMCM nodeset will fail to decode inherited types.
- Establish that the vendor actually implements itThis extension is recent, from May 2024, and adoption is thin. Ask the vision vendor specifically whether AMCM is implemented and in which software version, rather than accepting a general statement of OPC UA vision support.
- Correlate requests to responses explicitlyThe whole purpose of an asynchronous model is that responses arrive out of order. Keep your own correlation table keyed on the request identifier the server returns, and never assume the next result belongs to the last request you sent.
- Design for the timeout caseAn asynchronous request that never produces a response is a normal failure mode. Give every outstanding request a deadline in your client and decide what a missing vision result means for the part before you go live.
- Keep the base model integration working without itBecause coverage is uneven, build your collection against the MachineVision base model first and treat AMCM as an improvement where present. That way one vendor's missing extension does not block the project.
What it gives you for OEE
Nothing directly. AMCM is a control and correlation mechanism, not a measurement model: it has no counters, no state machine for the machine being inspected and no stop reasons. Its indirect contribution is to the quality factor, in that reliable request and response correlation is what makes per-part inspection results trustworthy enough to count as scrap. Availability, cycle counts and reasons still come from Machinery, MachineTool, PackML or the vendor's own tags.
Gotchas
- It is an extension namespace. Two nodesets must be loaded, and a partial load produces undecodable inherited types rather than a clean error.
- Published in May 2024, so field coverage is limited. Treat vendor support as something to confirm per software version, not as a property of the product line.
- Asynchronous means genuinely unordered. Client code written against the base model's implicit last-result semantics will appear to work in testing and mis-attribute results under load.
- The base MachineVision model still carries no image transport, and AMCM does not change that.
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.