Description

Devices typically come with a set of properties that identify them for discovery, management, and maintenance purposes. This set of properties is commonly summarized using the term “nameplate“. The information available includes (but it is not limited to) device name, identifiers, serial number, manufacturer, hardware and software versions, and product URI. A nameplate for a device is required to be recognized correctly in the server.

Furthermore, a Device is composed of different Components. Each of these Components can have a nameplate itself. The definition of Components is up to the implementer of the Device.

It should be possible to represent an individual Device as an OPC UA Server or aggregate multiple Devices into the same OPC UA Server. Therefore, an OPC UA Server can represent an arbitrary number of Devices. The following scenarios are envisioned to be covered by this specification:

• Single Devices incorporating an OPC UA Server,
• Gateway Devices representing a set of Devices, including OPC UA capable Devices as well as non-OPC UA capable Devices  (e.g., a simple analogue Sensor or legacy device using a different communication protocol),
• Devices serving both of the above roles.

Addressed in Section: 7.1

Description

The condition of a Device or a Component of a device is useful for understanding its health status and performance, as well as possible maintenance actions needed. For these reasons, the following information is envisioned to be represented for a Device or Component:

• Indicators of health status,
• Indicators of operating time and number of actions performed since installation or maintenance,
• Indicators of (estimated) remaining lifetime based on the device information provided by suppliers,
• Device modes (e.g., operating, sleep, maintenance, off) and Methods to trigger changes.

For maintenance purposes, the possibility to trigger, record, and retrieve information related to maintenance activities is seen as valuable.

Maintenance activities can be recurrent, periodic, or ad-hoc. They can be vendor defined (e.g., yearly maintenance) or user defined (e.g., calibration). Maintenance activities may be initiated based on specific conditions related to the health and condition of a Device or a Component. History with dates and details of actions performed on a Device or a Component should be available.

Addressed in Sections: 0 7.1.1,

Description

The location of a Device is of interest for multiple purposes. These include:

1. Finding a Device position for asset management and service needs
2. Enabling autonomous robots to navigate within a lab facility or across multiple lab facilities
3. Sample location tracking (future).

A Device location can include different information, including:

• Geographical
• Address
• Organizational
• Indoor coordinates
• GPS coordinates.

Addressed in Section:7.1