Digital Product Passport (DPP)

To support the implementation of DPPs, 8 standards have been developed:

This annex specifies how the requirements as specified in

are mapped to the AAS Metamodel.

In EN 18216 it is specified that JSON shall be used for syntactic interoperability. In addition to JSON also XML and JSON-LD may be used based on http content negotiation. A JSON-LD representation shall be processable by a regular JSON parser, allowing the possibility of including linked data context for advanced semantic processing.

A Digital Product Passport (DPP) is a digital record of product characteristics throughout its life cycle [1]. Example characteristics include environmental sustainability, environmental impact, and recyclability [1].

Figure 1 shows exemplary for the Battery Passport how a DPP is created based on the Asset Administration Shell (AAS): 7 standardized Submodel Template Specifications were created (based on DIN DKE SPEC 91100) to represent the Battery Passport in total (series IDTA-02035). At the point of publication of the requirements for Battery Passport EN 18223 were not yet published.

To ensure harmonization across different implementations, this document describes a single, recommended approach for creating a Digital Product Passport (DPP) using an Asset Administration Shell (AAS) as specified in IDTA-01001 and IDTA-01002. While other methods may exist, this document focuses exclusively on this proposed pathway to establish a consistent and interoperable standard between the DPP Metadata Submodel and the other Submodels needed to compose a DPP.

It is important to understand that an Asset Administration Shell (AAS) is not, by itself, the Digital Product Passport as required by EN 18222 or EN 18223. However, a DPP can be easily derived from an existing AAS. The prerequisite is that the AAS contains the submodels supporting the regulation’s required data points for the product, as well as the DPP metadata submodel specified in this document.

The Digital Battery Passport provides a clear example of this relationship. It is represented by seven standardized submodel specifications (see Figure 2). To create the complete passport, these submodels are merged with the DPP metadata submodel defined herein, resulting in a comprehensive Digital Product Passport conformant to regulation.

The primary advantage of using an Asset Administration Shell (AAS) to implement a Digital Product Passport (DPP) is its modular design, which contrasts with the monolithic structure assumed by the JTC24 specification.

An AAS acts as a container for multiple, independent Submodels. Each Submodel has a unique identifier and can be managed and reused separately. This modularity offers significant benefits:

The Battery Passport provides a perfect example. While the regulation requires a passport for every battery, much of the data is identical across batteries of the same type or from the same production facility. With an AAS, you can create a hierarchy of information, where the AAS for a single battery instance reuses Submodels from the AAS of its production facility and its battery type. This same principle allows for standardized Submodels, like contact information, to be reused across entirely different domains.

While the AAS approach is modular, it is designed to produce the single, monolithic JSON document that JTC24 expects. The key is understanding that even this single document must adhere to a set of different schemas. For a DPP to be compliant, it must be validated against at least two types:

The AAS framework directly supports this structure. It realizes this by registering new Submodels to an AAS and then adding the payload of those Submodels to the payload of the overall DPP. In essence, the AAS dynamically assembles the required monolithic document by aggregating the data from its various registered Submodels. This allows you to benefit from a modular development and management process while still delivering a compliant, single-file DPP that satisfies all schema requirements.

The process of generating the DPP from an AAS through a sequence of operation calls is detailed in the following subsections and illustrated in Figure 3.

The sequence diagram included herein is provided for informative purposes only, offering a contextual example to aid in understanding; it should not be considered an exhaustive or normative representation of all possible interactions. For implementation details, readers are directed to the metamodel in Part 1 and the API in Part 2 of the Asset Administration Shell specifications [3].

In Example DPPMetadata JSON Payload an example JSON instance of this Submodel Template Specification is shown. It describes a DPP using Submodel Template semanticIds as contentSpecificationIds, here (example) semanticIds for Nameplate, TechnicalData, HandoverDocumentation, ProductCondition, MaterialComposition and Circularity for a specific Product Passport.

Note: While standard EN 18223 provides an illustrative example for the contentSpecificationId ("prEN1234_xyz"), it is important to recognize that this format is forward-looking. To date, no formal standards for vertical-specific digital product passports have been specified. Therefore, in the absence of a definitive specification, this document puts forth a recommendation to ensure a harmonized approach.

Although some attributes (see Example DPP JSON Payload in compressed serialization) of this Submodel specification can be mapped to attributes in the Asset Administration Shell (AAS) metamodel, the formal recommendation is to instead use this predefined Submodel Template IDTA-02099 for this metadata. This template is derived from the SMT IDTA-02006-4-0 Digital Nameplate. For the corresponding semantic identifiers, please refer to their respective specifications.

The payload required by EN 18223 for the DPP metadata maps to the Value-Only format of this Submodel.

Note: for the other Submodels used to build a DPP EN 18223 allows two different formats "compressed" and "expanded" with compressed being mandatory to be supported. For DPP Metadata there is exactly one correct serialization since it is part of the overall schema and not of a specific content.

In Table 1 the data points of IDTA-02099-1, the DPP Metadata, is mapped to the corresponding elements in IDTA-01001 and IDTA-02006.

In Figure 4 an overview of the metamodel as defined in EN 18223 is shown.

Given the example data for the DPP in Example DPPMetadata JSON Payload the example is now extended with the data of the corresponding Submodels itself (see Example DPP JSON Payload in compressed serialization). The JSON element name corresponds directly to the contentSpecificationId. It is the starting point for the corresponding Submodel data.

In Example AAS Value-Only JSON Payload for Battery Passport, PCF data an example JSON payload conformant to IDTA-02023 Version 1.0 Carbon Footprint (see CarbonFootprintBattery.json) in Value-Only format is provided. In this case no multi language properties or File elements are contained and this is why this payload is also conformant to the compressed format as specified in EN 18223. CarbonFootprintBattery-schema.json, generated from the Aspect Model conformant to IDTA-01023, is the schema that can be combined with the one of the EN 18223 generic schema.

So in combination it would be the "semanticId" of SMT IDTA-02035-3 that is "https://admin-shell.io/idta/CarbonFootprint/CarbonFootprint/1/0", (see Example DPP compressed serialization for Battery Passport, PCF data). The second value to be standardized is the one for the contentSpecificationIds. For details on "contentSpecificationIds" see Submodel Template Specification IDTA-02099-1.

In Example JTC24 expanded full serialization JSON Paylaod for Battery Passport, PCF data (with fewer elements) an example is shown how a payload similar to the AAS "Normal"-Format could look like.

For details on DPP serialization (compressed and expanded full) compared to Value-Only and Normal serialization of the AAS see IDTA-01001 Asset Administration Shell Specifications, Part 1.

In AAS "Normal" is considered the standard serialization but others are supported as well. In this context especially the mapping "Value-Only" is of interest.

In EN 18223 it is the other way around: what the AAS would call "Value-Only" and is called "compressed" in EN 18223 is mandatory to be provided. Optionally, also a format that is similar to the AAS "Normal" format can be provided by operators, it is referred to as the "expanded" serialization in EN 18223.

The expanded serialization is optional (see EN 18223). The AAS "Normal" serialization and the "expanded" EN 18223 serialization are similar when it comes to the rules of derivation the serialization from the UML model. However, since the UML model differ also the serialization differs.

The "objectType" in JSON serialization of AAS is mapped to "objectType" in EN 18223 expanded serialization.

EN 18223 also defines a XML serialization for the compressed representation (Annex B). The XML serialization is optional (see EN 18216). The AAS does not support a Value-Only serialization for XML, only for JSON. However, a corresponding serialization would be straightforward compared to AAS Value-Only as it is in EN 18223 compared to JSON compressed.

EN 18223 does not define a XML serialization for the expanded representation.

The JSON-LD serialization is optional (see EN 18216). EN 18216 requires that a JSON-LD representation shall be processable by a regular JSON parser, allowing the possibility of including linked data context for advanced semantic processing. However, in EN 18223 no examples or normative text is provided for JSON-LD representation. The AAS does not support a standardized JSON-LD representation.