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 MachineryItem, 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 MachineryItem can be accessed (see section 12).
• The operation mode of a MachineryItem 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.

The user would like to monitor how long a MachineryItem is powered on and doing an activity and wants to monitor the expected remaining lifetime of a MachineryItem or other aspects of a machine (like the remaining time a software licence is valid).

That leads to the requirements:

• The total time a MachineryItem is turned on and the total time an activity is done can be accessed (see section 14).
• The remaining estimated lifetime of a MachineryItem or other aspects of a machine can be accessed (see section 15).