AMB

Where it sits in the stack

AMB is a thin layer over the Part 9 alarms and conditions machinery, and it is intended to be used alongside a sector model rather than instead of one. Where MachineTool defines its own condition classes for tool breakage, part missing and clamping, AMB provides the generic categorisation and root-cause pattern for machines whose sector model has no such taxonomy, which is most of them. It pairs naturally with Machinery for identification and state, and with the notifications structure Machinery already defines. If your downtime attribution currently relies on parsing alarm text, AMB is the model that replaces that with something typed.

Using it on a real machine

1. Check the namespace before designing around itRead NamespaceArray for http://opcfoundation.org/UA/AMB/. There is no server capability code for AMB, so the namespace is the only signal, and coverage in shipped products is thin.
2. Get the Part 9 basics right firstAMB adds categorisation on top of standard alarms and conditions. Your client needs a working event subscription with a select clause, ConditionRefresh handling on reconnect and correct acknowledgement behaviour before the categorisation is of any use.
3. Map categories to your own reason codes onceBuild one explicit mapping from the model's categories and root-cause indications to your plant reason-code list, version it, and apply it in one place. The value of a standardised category is lost if each dashboard maps it differently.
4. Use ConditionClassId for grouping, not severitySeverity is a vendor-tuned number and is a poor basis for downtime attribution. Group on the condition class and the AMB categorisation, and keep severity only for operator display.
5. Fall back to the sector model where presentOn a machine tool, MachineTool's condition classes are richer and more widely implemented than AMB. Prefer the sector taxonomy where it exists and use AMB for machines whose sector model has none.

What it gives you for OEE

AMB is the rare Tier 2 model whose whole point is an OEE input, and specifically the hardest one: reasons. It contributes nothing to availability or performance measurement directly, because it has no state machine and no counters. What it contributes is the attribution layer, a standard way to categorise an alarm and indicate a root cause so that a stop can be assigned to a category rather than to an alarm string. That matters because the usual failure of plant OEE systems is not measuring downtime, it is explaining it. Take availability from Machinery's MachineryItemState and operation mode, counts from the machine or from Machinery, and use AMB to make the reason column mean something across different builders.

Gotchas

• Coverage is thin. AMB is small, recent in its current revision and not widely implemented, so confirm it exists on your machines before building a reason taxonomy on it.
• It standardises the shape of the reason, not the reason itself. A vendor still chooses which category an alarm falls into, and two builders will categorise the same physical event differently.
• There is no capability code for it, so discovery is by namespace only.
• It does not replace the sector taxonomy. On machine tools the MachineTool condition classes remain the better source, and using both without a single mapping produces double counting.

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.