This specification provides building blocks for various use cases. Other specifications or vendor-specific information models can pick the building blocks for specific use cases they want to support.

The user would like to uniquely identify machines, potentially across various OPC UA Servers or aggregating OPC UA Servers. The user wants to get standardized information about the machine, like manufacturer or serial number, and set user-specific information in order to simplify the usage of the machine.

That leads to the requirements:

• A machine shall be globally uniquely identified (see section 8, ProductInstanceUri).
• Information about the machine, like manufacturer or serial number, can be accessed (see section 8, IMachineVendorNameplateType).
• Application-specific information about a machine can be set by an OPC UA Client (see section 8, IMachineTagNameplateType).

The user would like to easily find all machines managed by an OPC UA server.

That leads to the requirement:

• All machines shall be easy to find in an OPC UA Server (see section 9, Machines Object).

The user would like to identify components of a machine. The user wants to get standardized information about the component, like manufacturer or serial number, and set user-specific information in order to simplify the usage of the component.

That leads to the requirements:

• Information about the component, like manufacturer or serial number, can be accessed (see section 10.2, MachineryComponentIdentificationType).
• Application-specific information about a component can be set by an OPC UA Client (see section 10.2, MachineryComponentIdentificationType).

The user would like to easily find all components related to a specific machine.

That leads to the requirement:

• All components of a machine shall be easy to find in an OPC UA Server (see section 11.2, MachineComponentsType).

The user would like to monitor information about a specific machine or a component of a machine, like the state or operation mode, for example to get a quick overview over the current state and bottlenecks (localization of errors), to recognize trends or to determine the relevant times (productive time, standby time, etc.) for subsequent KPI calculations (e.g. for calculating reliability and availability). Further information for the KPI calculation might be necessary.

That leads to the requirement:

• The state of a machine or a component of a machine can be accessed (see section 12).
• The operation mode of a machine or a component of a machine can be accessed (see section 13).

Note: This version of the specification defines some base information for this use case. There is more information that could be defined for this use case, which might be addressed by later versions of this specification, domain-specific companion specifications or vendors.

In Annex C an example is given, on how the state and operation mode can be used as base for KPI calculations.