Overview
This appendix provides informal examples on how the building blocks defined in this specification can be used.
Identification and Finding Machines
In Figure 32, an example is given, showing the identification and Nameplate and Finding all Machines in Server use cases. The server provides information about a Robotics system as well as a CNC machine defined by Machine Tools (see OPC 40501, [3]). As the Robotics specification (see OPC 40010-1, [4]) already defines some Properties for identification directly, those are only referenced from the Identification functional group.
Figure 32 – Example of Identification
Component Identification and Finding Components of a Machine
In Figure 33, an example is given, showing the Component Identification and Nameplate and Finding all Components of a Machine use cases. The server provides information about a Robotics system (see OPC 40010-1, [4]). In that system, the components are organized according to the Robotics specification, and in addition according to this specification.
Figure 33 – Example of Component Identification
The Monitoring building block (see 16) can be used for a MachineryItem as well as for components of a MachineryItem. There are different ways how to combine this information, as shown in the following sections. Servers can choose which approach to use, Clients should be prepared for all those approaches.
The simplest implementation is, that the MachineryItem represents its monitoring information in its Monitoring building block, and the components provide their monitoring information in their Monitoring building blocks. When a component gets replaced, only this part of the information model needs to be replaced, as well.
An example is shown in Figure 34. The X:MyMachine provides the Monitoring building block with information only in the context of the machine, not considering anything from its subcomponents. It does provide a subcomponent X:MyComponent, also providing a Monitoring building block with information about the subcomponent.
Note: The values of the MachineryItem may be aggregated out of the values of subcomponents. Considering the example of Figure 34, the overall MachineryItemState may consider the MachineryItemState of subcomponent X:MyComponent as well. Same is true for the DeviceHealth. Depending on the functionality of the X:MyMachine, this may actually be required if the X:MyComponent is an integral part of the X:MyMachine, and the X:MyMachine would not be functional without X:MyComponent.
Figure 34 – Example of usage of Monitoring with independent representation
When some information of subcomponents is considered to be essential for the machine, the Monitoring building block may reference the information of the subcomponents directly. This is shown in Figure 35. The X:MyComponentProcessValue, provided by the X:MyComponent, is referenced from the Process folder of X:MyMachine. This approach only works, if the referenced Node has a unique (in the context of the machine) and self-explaining name and description in order to be interpretable. If this is not the case, the context needs to be provided by some proxy object, like used for the health of the subcomponent. Just referencing the Health folder or the DeviceHealth Variable would not provide the context of the subcomponent (assuming there would be several subcomponents), therefore a proxy object X:MyComponent was added. Note that this approach may lead to duplicating the components information in various places under Monitoring, It should be used rarely for important information that should be accessible from the Monitoring of the machine, directly. For the example of the health of the subcomponent, this may be unnecessary and better accessed by accessing the general information about the component.
Figure 35 – Example of usage of Monitoring with References
As stated in 18.1, Notifications Objects expose Notifications either as Objects or as Events. In B.5.2, an example is given, where Objects are used. In B.5.3, an example is given, where Events are used. In Figure 30 in 18.1 a small example is shown, where both approaches are combined.
In Figure 36, an example is given, where Objects are used as Notifications. The ObjectType X:ManualActivityType provides a notification that some manual activity (like the change of a tool in a machine tool) is needed. It provides information about the activity and when it is expected to be done. Whenever the machine predicts the need for such an activity, such an Object is created on the Notifications Object. The 0:NodeVersion Property can be used to identify such new Objects as a Client. After the action has been executed, the Notification Object will be removed.
Figure 36 – Example of usage of Notifications with Objects
In Figure 37, an example is given, where Events are used as Notifications. In this case, the log of maintenance activities as defined by Asset Management Basics [8] is used. The EventType X:MaintenanceEventType implements the IMaintenanceEventType defined by Asset Management Basics. The X:MyMachineType provides a GeneratesEvent Reference from its Notifications Object to the X:MaintenanceEventType. For each new maintenance event, or if the status is changing, such an Event is generated.
Figure 37 – Example of usage of Notifications with Events