5 Use Cases

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.

5.1 Machine Identification and Nameplate

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:

5.2 Finding all Machines in a Server

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).
5.3 Component Identification and Nameplate

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:

5.4 Finding all Components of a Machine

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

That leads to the requirement:

5.5 Monitoring

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.

The user would like to monitor different aspects of a MachineryItem like its status, health, process and consumption.

That leads to the requirements:

  • The state of a MachineryItem can be accessed (see section 12).
  • The operation mode of a MachineryItem can be accessed (see section 13).
  • All monitoring information of a MachineryItem shall be easily accessible (see 16).
  • All status information of a MachineryItem shall be easily accessible (see 16).
  • All health information of a MachineryItem shall be easily accessible (see 16).
  • All process information of a MachineryItem shall be easily accessible (see 16).
  • All consumption information of a MachineryItem shall be easily accessible (see 16).

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

5.6 Preventive Maintenance

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).
5.7 Equipment Information

The user would like to access MachineryEquipment information used by a MachineryItem. The user would like to get some base information about each MachineryEquipment in a standardized way.

That leads to the requirements:

5.8 Notifications

The user would like to access notifications of a MachineryItem. Those notifications may include prognosis information, noteworthy or abnormal conditions.

That leads to the requirement:

  • All notifications of a MachineryItem shall be easily accessible (see 18).

Note: The notifications mentioned here are not necessarily all OPC UA Events a MachineryItem may produce (e.g., for job management defined in OPC 40001-3 (see [7])), but general notifications of a MachineryItem that may, or may not be modelled by OPC UA Events.