IDTA 02099-1: Digital Product Passport - Part 1: Metadata

This document is a part of an overall specification series [4]. Each part specifies the contents of a Submodel Template (SMT). The specifications of the Asset Administration Shell (AAS) are the basis for the Submodel Template specifications, see [3].

The target audience of the specification are developers and editors of technical documentation and manufacturer information, which are describing assets by means of the Asset Administration Shell (AAS) and therefore need to create a Submodel instance with a hierarchy of SubmodelElements. This document especially details on the question, which SubmodelElements with which semantic identification shall be used for this purpose.

This specification was created following the "semantic-driven workflow" as defined in [5] based on Aspect Models [6].

In this specification the following sources are used for defining semantics:

This Submodel template aims to define the data points that are required for every Digital Product Passport conformant to the specification of EN 18223:2026 [1].

This document represents the first part in a planned series. It is envisioned that future parts will be developed to address additional aspects; however, the scope, content, and timeline for these subsequent publications have not yet been determined.

EN 18223 is part of a series of standards pepared by the Joint Technical Committee JTC24 of CEN and CENELEC:

In this document they are referred to as the "JTC24 specifications".

This submodel template fulfills the requirements for data points as defined in CEN CENELEC JTC24 standard EN 18223:2026.

For clarity and an improved legibility readers suggested to go through this section at first before reading the following chapters.

UML diagrams feature box-like elements, called "classes". These classes, typically Submodels, SubmodelElementCollections or SubmodelElementLists, typically feature a set of Properties or further SubmodelElements. These elements can have specific cardinalities.

The single classes are hierarchally organized by aggregation relations, these can be seen as "contains" relation.

For a further overview on UML diagrams please refer to [2] and [3].

Further details about used table formats please refer to Section 4.

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].

The SubmodelElements described in section 3 are structured in the following way (see Figure 4):

Figure 5 shows the UML-diagram defining the relevant properties which need to be set.

For granularity three values are predefined, 'Model', 'Item' and 'Batch'.

There is no schema defined so far in EN 18223, so there also is no schema version. There also is no regular expression defined how a schema version should be specified.

Figure 6 shows the UML-diagram for SML contentSpecificationIds.

A content specification ID refers to the content of the DPP.

Two different cases need to be distinguished:

There are no rules standardized in CEN CENELEC how exactly the content specification IDs will be handled. So the following recommendations hold for DPPs created on basis of AAS Submodels.

The recommendation is to just use the "semanticId" of the Submodel Template Specification that belongs to the DPP under consideration as the unique Identifier of the content. If more than one regulation is affected then all these semantic IDs are added as well.

Example:

Since there might be more than one Submodel with the same semanticId in the same AAS, it would always be the newest version of the corresponding Submodel that needs to be included in the DPP.

If idShort are added to the elements within the SML "contentSpecificationIds" the recommendation is to use the idShort of the corresponding Submodel Template with the specified semanticId. :sectnums!:

The used tables in this document try to outline information as concise as possible. They do not convey all information on Submodels and SubmodelElements. For this purpose, the definitive definitions are given by a separate file in form of an AASX file of the Submodel template and its elements.

For clarity and brevity, a set of rules is used for the tables for describing Submodels and SubmodelElements.

This annex lists the changes from version to version of the Submodel, together with major changes in the overall document.

Note: .aasx is not affected by this bugfix