This section introduces the use cases addressed by the LADS specification.
Description
Remote monitoring, Alarms and Events form the foundation of any basic automation functionality. If no information is available regarding the current values of function states, operation modes, process variables, set-points, parameters, etc. it is not possible to make decisions and take action. For selected values, such as Sensor or process values, the optional provision of time-series history services is recommended.
Remote monitoring entails the capability to measure a physical/chemical/biological property. It comprises of a “raw” measurement value provided by the sensing element, a calibration function, optional signal processing/filtering and the final Sensor value which represents a real-world physical/chemical/biological property.
The remote monitoring of a property may be augmented by Alarm and Notification functionalities which update the user regarding the monitored property value matching determined conditions (e.g., out of limits).
History services are supported to retrieve historic information on the observed properties.
Addressed in Sections: 7.1
Description
Function-based remote control enables a user to remotely perform an action, change parameters or setpoints, or start and stop Functions. It includes the remote invocation of Methods to perform Functions on a Device. For example, to start or stop device-specific Functions, open and close covers, as well as change parameters like Alarm limits, control and calibration values, or closed-loop control set-point values.
Addressed in Sections: 7.4, 7.6, 7.4.2
Description
Program-based remote control covers the orchestration of one or more instruments along a lab or analytical workflow. It enables a supervising system (e.g., LIMS) to manage and execute programs on a Device as part of a greater workflow.
Furthermore, it covers the capability to retrieve the Program Templates on the Device, select a program to be executed, start a program run and monitor the program’s progress.
The combined program-management and result-management use-cases are the basis for orchestration of several instruments along workflows.
Addressed in Section: 7.1.10
Description
A Device performing a specific Function may generate results. These results are typically consumed by one or more applications which may not run on the Device itself.
The generating Device exposes the results such that they can be retrieved by the application via OPC UA. The results data include the results themselves, but also metadata such as results templates, user information, timestamps, action identifiers, and sample Ids.
A Device can also provide the capability to observe intermediate/partial results, such that an application can monitor the execution of a Function on the Device.
There may be specific cases in which a consuming application may need to retrieve the results via an alternative interface. In these cases, the Device exposes the URI where the results reside and can be accessed via authenticated access. The possibility to retrieve intermediate/partial results via an alternative interface is outside the scope of this specification.
Addressed in Sections: 7.1.10, 7.2.2, 7.2.3
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:
- Finding a Device position for asset management and service needs
- Enabling autonomous robots to navigate within a lab facility or across multiple lab facilities
- Sample location tracking (future).
A Device location can include different information, including:
- Geographical
- Address
- Organizational
- Indoor coordinates
- GPS coordinates.
Addressed in Section:7.1