5 Use cases

5.1 Overview

The DPP regulations places the burden on Manufacturers to collect the information that needs to go into the DPPs for the products they produce. This requires the Manufacturer be able to retrieve the DPPs for the materials, understand the information in them, and build their own DPPs that have the information required by regulation including links to the DPPs of additional product components. OPC UA provides an information modelling framework that can describe the requirements of the various regulations and allow a Manufacturer build its own DPPs using existing tools. The OPC UA information models are also used by the existing OT systems which data management needs.

The UACloudLibrary is a key part of the OPC ecosystem, and it is a cloud-based repository for OPC UA information models. Multiple versions of the UACloudLibrary are deployed in production systems today. This makes UACloudLibrary a foundation for a DPP Service Provider that provides additional services to Manufacturers to help them create and maintain their DPPs.

The relationships between the UACloudLibrary and the various actors involved with DPP creation and consumption are shown in Figure 8.

5.2 DPP Consumer Retrieves DPPs from the UACloudLibrary

A DPP Consumer needs to review the DPP for a product obtained. The DPPId is retrieved from a QR code on the label and use the EN 18222:2026 defined API to request the DPP. The UACloudLibrary builds a DPP including the DataElements the consumer has access to and returns it in a mandated format such as JSON-LD.

5.3 Importing Requirements from a Delegated Act for a Product Category

The EU is expected to create requirements for different product categories over time. Once a new set of requirements is published a DataElementType needs to be created so the requirements can be described in a NodeSet. This will require manual editing or automated conversion from another format such as an AAS submodel template. Once this is done, UACloudLibrary APIs are used to store the DataElementType, that they can be used by Manufacturers building their DPPs.

5.4 Manufacturer needs to Build a DPP for a new Product

The Manufacturer uses a standard OPC UA Modelling Tool to build a DPP which contains the required DataElements. They enter the information as values of the Variables and saves it as a DPP in the UACloudLibrary. The format of the DPP in this context is a NodeSet, to ensure compatibility with tools currently used in factories.

If the Manufacturer needs to produce DPPs with Batch or Item granularity, they can create a new subtype of DigitalProductPassportType that is instantiated by their OT systems during production. The OT systems would then automatically publish DPPs to the UACloudLibrary using UACloudLibrary APIs.

The Manufacturer also has the option of specifying the RolePermissions for any DataElement which allows the Manufacturer to control who has access to information. When a Consumer requests a DPP, it provides credentials that are mapped to Roles.

5.5 Testing Authority needs to update a DPP

Some of the claims in a DPP require authentication by an independent Testing Authority. Once the Testing Authority completes its work, it updates a DPP by adding a DataElement with a digital signature. This is done using the EN 18222:2026 defined API. The UACloudLibrary will save the original serialized from of a DataElement (i.e. JSON-LD with a Signature). The Signature is represented with the VerifiableCredentialType, which can be attached as an Add-In to any DataElement.