From c1e691042350951d35a984a371afd41a27266de6 Mon Sep 17 00:00:00 2001 From: birgitboss Date: Thu, 28 May 2026 10:06:38 +0200 Subject: [PATCH] Annex DPP: fix nav.adoc + update text --- .../IDTA-01002-3/modules/ROOT/nav.adoc | 2 + .../modules/ROOT/pages/annex/dpp.adoc | 157 +++++++++++------- 2 files changed, 95 insertions(+), 64 deletions(-) diff --git a/documentation/IDTA-01002-3/modules/ROOT/nav.adoc b/documentation/IDTA-01002-3/modules/ROOT/nav.adoc index d083ce60..e1baf7cc 100644 --- a/documentation/IDTA-01002-3/modules/ROOT/nav.adoc +++ b/documentation/IDTA-01002-3/modules/ROOT/nav.adoc @@ -74,6 +74,8 @@ Shared .adoc file are used from https://github.com/admin-shell-io/aas-specs-meta ** xref:annex/serialization-modifier-examples.adoc[SerializationModifier Examples] +** xref:annex/dpp.adoc[Digital Product Passport] + ** xref:annex/backus-naur-form.adoc[Backus Naur Form] ** xref:annex/uml-templates.adoc[Class Table Templates] diff --git a/documentation/IDTA-01002-3/modules/ROOT/pages/annex/dpp.adoc b/documentation/IDTA-01002-3/modules/ROOT/pages/annex/dpp.adoc index 4e4a14b5..5240e276 100644 --- a/documentation/IDTA-01002-3/modules/ROOT/pages/annex/dpp.adoc +++ b/documentation/IDTA-01002-3/modules/ROOT/pages/annex/dpp.adoc @@ -14,26 +14,42 @@ SPDX-License-Identifier: CC-BY-4.0 == Introduction -This annex specifies how the API operations defined in the Asset Administration Shell (AAS) Services specification shall be used to implement the Digital Product Passport (DPP) operations defined in FFprEN 18222. The mapping enables implementations based on AAS infrastructure to expose a fully conformant DPP API. - -The DPP operations defined in FFprEN 18222 are organized into three API surfaces: - -. *Life Cycle API - main API methods* (FFprEN 18222, Clause 4, Table 16) -- Mandatory read operations and CRUD operations for DPP lifecycle management. -. *DPP Registry API* (FFprEN 18222, Clause 5, Table 17) -- Registration of DPPs at the DPP Registry. -. *Life Cycle API - fine granular API methods* (FFprEN 18222, Clause 6, Table 18) -- Element-level read and update operations within a DPP. +To support the implementation of DPPs, 8 standards have been developed: + +* EN 18219:2026 – Digital product passport – Unique identifiers +* EN 18220:2026 – Digital product passport – Data carriers +* EN 18216:2026 – Digital product passport – Data exchange protocols +* EN 18222: 2026 – Digital Product Passport – Application Programming Interfaces (APIs) for the product passport lifecycle management and searchability +* EN 18223:2026 – Digital Product Passport – System interoperability +* EN 18221:2026 – Digital product passport – data storage, archiving, and data persistence +* EN 18239:2026 – Digital Product Passport – access rights management, information system security, and business confidentiality +* EN 18246:2026 – Digital Product Passport – Data authentication, reliability and integrity + +This annex specifies how the requirements as specified in + +* EN 18222:2026 – Application Programming Interfaces (APIs) for the product passport lifecycle management and searchability + +can be implemented using the Asset Administration Shell (AAS) Services specification. +The mapping enables implementations based on AAS infrastructure to expose a fully conformant DPP API. + +The DPP operations defined in EN 18222 are organized into three API surfaces: + +* Life Cycle API - main API methods* (EN 18222, Clause 4, Table 16) -- Mandatory read operations and CRUD operations for DPP lifecycle management. +* DPP Registry API* (EN 18222, Clause 5, Table 17) -- Registration of DPPs at the DPP Registry. +* Life Cycle API - fine granular API methods* (EN 18222, Clause 6, Table 18) -- Element-level read and update operations within a DPP. The following sections describe, for each of these API surfaces, how the corresponding API methods shall be mapped to AAS Interface and API operations as well as services. [Note] ==== -the terms "method" and "operation" are synonym in this context. -In FFprEN 18222 "method" is used, in IDTA 01002 "operation" is used. +The terms "method" and "operation" are synonym in this context. +In EN 18222 "method" is used, in IDTA-01002 "operation" is used. ==== [NOTE] ==== -The mapping of DPP data elements to AAS metamodel elements (FprEN 18223) is specified in *TODO_XREF:[IDTA-01001 Part 1 -- DPP Metamodel Mapping]*. -The DPP metadata Submodel Template is specified in link:https://industrialdigitaltwin.org/en/content-hub/submodels[IDTA-02099-1-0 Digital Product Passport – Part 1: Metadata - Submodel Template Specification] with isShort "DppMeta". +The mapping of DPP data elements to AAS metamodel elements (EN 18223) is specified in link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01001/v3.2/annex/dpp.html[IDTA-01001]. +The DPP metadata Submodel Template is specified in link:https://industrialdigitaltwin.org/en/content-hub/submodels[IDTA-02099-1-0 Digital Product Passport – Part 1: Metadata - Submodel Template Specification] with idShort "DppMetadata". A conformant DPP service based on AAS shall implement all aspects described in this annex together with the metamodel mapping and the Submodel Template. ==== @@ -41,33 +57,38 @@ A conformant DPP service based on AAS shall implement all aspects described in t == DPP Composition from AAS Infrastructure -A Digital Product Passport as defined in FprEN 18223 is a single JSON or XML document comprising *header fields* and *content data elements*. When using AAS infrastructure, a DPP shall be composed from the following AAS resources: +A Digital Product Passport as defined in EN 18223 is a single JSON or XML document comprising *header fields* and *content data elements*. When using AAS infrastructure, a DPP shall be composed from the following AAS resources: * An *Asset Administration Shell* representing the product for which the DPP is issued. -* A *DppMeta Submodel* (semanticId: `urn:samm:io.admin-shell.idta.dpp_meta:1.0.0#DppMeta` (exact identifier not yet finalized), as defined in *TODO_XREF:[IDTA-02099-1-0]*) containing the DPP header fields (`digitalProductPassportId`, `uniqueProductIdentifier`, `granularity`, `dppSchemaVersion`, `dppStatus`, `lastUpdate`, `economicOperatorId`, `facilityId`, `contentSpecificationIds`). -* One or more *content Submodels*, each contributing a section of the DPP content. The semanticIds of the contributing content Submodels shall be listed in the `contentSpecificationIds` property of the DppMeta Submodel. +* A *DppMetadata Submodel* (semanticId: `https://admin-shell.io/idta/cds/dppMetadata/1`, as defined in *IDTA-02099 V1.0*) containing the DPP header fields (`digitalProductPassportId`, `uniqueProductIdentifier`, `granularity`, `dppSchemaVersion`, `dppStatus`, `lastUpdate`, `economicOperatorId`, `facilityId`, `contentSpecificationIds`). +* One or more *content Submodels*, each contributing a section of the DPP content. +The semanticIds of the contributing content Submodels shall be listed in the `contentSpecificationIds` property of the DppMetadata Submodel. [Note] ==== -Attention: The DppMeta Submodel Template Specification is not yet published. Therefore, all related statements are subject to change. +Attention: The DppMetadata Submodel Template Specification is not yet published. Therefore, all related statements are subject to change. ==== -The Value-Only serialization (see *TODO_XREF:[IDTA-01001 Part 1 -- Format "Value" (Value-Only Serialization) in JSON]*) of the DppMeta Submodel corresponds directly to the DPP header fields defined in FprEN 18223, Table 1. No additional transformation of the header is required for the _compressed_ representation (FprEN 18223, Clause 5.2). The extended representation (FprEN 18223, Annex A) requires additional transformations from the "Normal" serialisation of the Asset Administration Shells and Submodels as described in *TODO_XREF:[IDTA-01001 Part 1 -- DPP Metamodel Mapping, Serialization]*. +The Value-Only serialization (see link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01001/v3.2/mappings/mappings.html#value-only-serialization-in-json[IDTA-01001 Part 1 -- Format "Value" (Value-Only Serialization) in JSON]) +of the DppMetadata Submodel corresponds directly to the DPP header fields defined in EN 18223, Table 1. +No additional transformation of the header is required for the _compressed_ representation (EN 18223, Clause 5.2). +The extended representation (EN 18223, Annex A) requires additional transformations from the "Normal" serialisation of the Asset Administration Shells and Submodels +as described in link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01001/v3.1.2/annex/dpp.html[IDTA-01001 Part 1 -- DPP Metamodel Mapping, Serialization]. [[dpp-composition-read]] === Composition Process (Read Path) To assemble a `DigitalProductPassport` JSON document, an implementation shall perform the following steps: -. *Resolve the DPP identifier to an AAS*: Determine the corresponding AAS, either by direct lookup of the DPP identifier or by resolving a product identifier through the AAS Discovery Service (see <>). -. *Retrieve the AAS*: Fetch the AAS from the AAS Repository, the AAS Service or via the AAS Registry. -. *Retrieve all referenced Submodels*: Obtain the Submodel references from the AAS or AAS Descriptor and retrieve each Submodel from the Submodel Repository, Submodel Service or via the AAS Registry. +* Resolve the DPP identifier to an AAS*: Determine the corresponding AAS, either by direct lookup of the DPP identifier or by resolving a product identifier through the AAS Discovery Service (see <>). +* Retrieve the AAS*: Fetch the AAS from the AAS Repository, the AAS Service or via the AAS Registry. +* Retrieve all referenced Submodels*: Obtain the Submodel references from the AAS or AAS Descriptor and retrieve each Submodel from the Submodel Repository, Submodel Service or via the AAS Registry. If a `date` parameter is provided, the implementation shall retrieve the version of each Submodel that was current at the specified point in time. -. *Identify the DppMeta Submodel*: Select the Submodel with semanticId `urn:samm:io.admin-shell.idta.dpp_meta:1.0.0#DppMeta` (exact identifier not yet finalized). This Submodel provides the DPP header fields. -. *Identify the content Submodels*: Select all remaining Submodels whose semanticId is listed in the `contentSpecificationIds` property of the DppMeta Submodel. -. *Serialize the header*: Serialize the DppMeta Submodel in Value-Only (for compacted DPPs) or "normal" format (for extended DPPs). The resulting JSON object constitutes the DPP header. -. *Serialize the content*: For each content Submodel, serialize the Submodel in the requested `representation` format (see <>). The JSON key for each content section shall be the Submodel's `idShort` with the first letter in lower case (camelCase convention). -. *Assemble the DPP document*: Merge the header fields and the content sections into a single `DigitalProductPassport` JSON document. +* Identify the DppMetadata Submodel*: Select the Submodel with semanticId `urn:samm:io.admin-shell.idta.dpp_meta:1.0.0#DppMetadata` (exact identifier not yet finalized). This Submodel provides the DPP header fields. +* Identify the content Submodels*: Select all remaining Submodels whose semanticId is listed in the `contentSpecificationIds` property of the DppMetadata Submodel. +* Serialize the header*: Serialize the DppMetadata Submodel in Value-Only (for compacted DPPs) or "normal" format (for extended DPPs). The resulting JSON object constitutes the DPP header. +* Serialize the content*: For each content Submodel, serialize the Submodel in the requested `representation` format (see <>). The JSON key for each content section shall be the Submodel's `idShort` with the first letter in lower case (camelCase convention). +* Assemble the DPP document*: Merge the header fields and the content sections into a single `DigitalProductPassport` JSON document. .DPP Composition Sequence via AAS Discovery, Registry, and Submodel Services [[image-seq-dpp]] @@ -83,24 +104,24 @@ include::partial$diagrams/seq-dpp.puml[] When a `CreateDPP` or `UpdateDPPById` operation is invoked with a `DigitalProductPassport` JSON document, an implementation shall decompose the document into the corresponding AAS resources: -. *Parse the DPP header fields*: Extract the header attributes (`digitalProductPassportId`, `uniqueProductIdentifier`, `granularity`, etc.) from the input document. -. *Create or update the AAS*: Map the header fields to the appropriate AAS attributes (e.g., `uniqueProductIdentifier` to `AssetInformation/globalAssetId`, `granularity` to `assetKind`). -. *Create or update the DppMeta Submodel*: Persist all header fields as properties of the DppMeta Submodel. -. *Create or update the content Submodels*: For each top-level content key in the DPP document, create or update the corresponding Submodel with the appropriate semanticId (as referenced in `contentSpecificationIds`). -. *Register Submodel references*: Ensure all Submodel references are registered in the AAS. +* Parse the DPP header fields*: Extract the header attributes (`digitalProductPassportId`, `uniqueProductIdentifier`, `granularity`, etc.) from the input document. +* Create or update the AAS*: Map the header fields to the appropriate AAS attributes (e.g., `uniqueProductIdentifier` to `AssetInformation/globalAssetId`, `granularity` to `assetKind`). +* Create or update the DppMetadata Submodel*: Persist all header fields as properties of the DppMetadata Submodel. +* Create or update the content Submodels*: For each top-level content key in the DPP document, create or update the corresponding Submodel with the appropriate semanticId (as referenced in `contentSpecificationIds`). +* Register Submodel references*: Ensure all Submodel references are registered in the AAS. Write operations should be atomic: if any step fails, all preceding changes shall be rolled back to maintain data consistency. == Life Cycle API Operations -The Life Cycle API (FprEN 18222, Clause 4, Table 16) defines the mandatory read operations and CRUD operations for managing the DPP lifecycle. The following table specifies how each DPP operation shall be mapped to AAS Service operations. +The Life Cycle API (EN 18222, Clause 4, Table 16) defines the mandatory read operations and CRUD operations for managing the DPP lifecycle. The following table specifies how each DPP operation shall be mapped to AAS Service operations. .Mapping of DPP Life Cycle API Operations to AAS Service Operations [.table-with-appendix-table] [cols="22%,30%,48%"] |=== -h| DPP Operation (FprEN 18222) h| AAS Service Operation(s) h| Description +h| DPP Operation (EN 18222) h| AAS Service Operation(s) h| Description | ReadDPPById | GetAssetAdministrationShellById / GetAssetAdministrationShell or GetAssetAdministrationShellDescriptorById + GetSubmodel / GetSubmodelById (Value-Only or Normal) for each referenced and relevant Submodel @@ -124,22 +145,22 @@ Multiple AAS instances might be associated with the provided product identifier. | Shall resolve a set of product identifiers to their corresponding DPP identifiers. The operation calls GetAllAssetAdministrationShellIdsByAssetId with the set of product identifiers and returns the union of all discovered DPP identifiers. Pagination via `limit` and `cursor` parameters should be supported. | CreateDPP -| PostAssetAdministrationShell / PostAssetAdministrationShellDescriptor + CreateSubmodel (for DppMeta and each content Submodel) -| Shall decompose the submitted DPP document and create the corresponding AAS and Submodels as described in <>. The DppMeta Submodel shall be created for every new DPP. Shall return the `digitalProductPassportId` with HTTP status 201. +| PostAssetAdministrationShell / PostAssetAdministrationShellDescriptor + CreateSubmodel (for DppMetadata and each content Submodel) +| Shall decompose the submitted DPP document and create the corresponding AAS and Submodels as described in <>. The DppMetadata Submodel shall be created for every new DPP. Shall return the `digitalProductPassportId` with HTTP status 201. | UpdateDPPById | PutAssetAdministrationShellById / PutAssetAdministrationShellDescriptorById + PutSubmodelById (for affected Submodels) -| Shall accept a partial DPP document (JSON Merge Patch per RFC 7396). If DPP header fields are present, the DppMeta Submodel shall be updated. If content fields are present, the corresponding content Submodels shall be updated. The `lastUpdate` field of the DppMeta Submodel shall be updated accordingly. All changes shall be archived per FprEN 18221. +| Shall accept a partial DPP document (JSON Merge Patch per RFC 7396). If DPP header fields are present, the DppMetadata Submodel shall be updated. If content fields are present, the corresponding content Submodels shall be updated. The `lastUpdate` field of the DppMetadata Submodel shall be updated accordingly. All changes shall be archived per EN 18221. | DeleteDPPById -| DeleteAssetAdministrationShellById / DeleteAssetAdministrationShellDescriptorById ( + DeleteSubmodelReference / DeleteSubmodelDescriptorById + DeleteSubmodelById for the Submodel "DppMeta") +| DeleteAssetAdministrationShellById / DeleteAssetAdministrationShellDescriptorById ( + DeleteSubmodelReference / DeleteSubmodelDescriptorById + DeleteSubmodelById for the Submodel "DppMetadata") | Shall delete the AAS and Submodels that contain the DPP metadata. Implementations shall ensure compliance with applicable regulations regarding archiving periods and the prohibition of deleting DPPs for products that are still in use. Shall return HTTP status 204. |=== == DPP Registry API Operations -The DPP Registry API (FprEN 18222, Clause 5, Table 17) defines operations for registering DPPs at a centrally hosted DPP Registry. When an AAS-based service acts as a data source for DPPs, it may also act as a client of the DPP Registry. +The DPP Registry API (EN 18222, Clause 5, Table 17) defines operations for registering DPPs at a centrally hosted DPP Registry. When an AAS-based service acts as a data source for DPPs, it may also act as a client of the DPP Registry. .Mapping of DPP Registry API Operations to AAS Service Operations @@ -151,7 +172,7 @@ An AAS Registry can be used to implement a DPP Registry. [.table-with-appendix-table] [cols="22%,30%,48%"] |=== -h| DPP Operation (FprEN 18222) h| AAS Service Operation(s) h| Description +h| DPP Operation (EN 18222) h| AAS Service Operation(s) h| Description | RegisterProductDPP | Direct call to the DPP Registry @@ -171,66 +192,70 @@ The DPP Registry is typically a centrally hosted service operated independently == Fine Granular API Operations -The Fine Granular API (FprEN 18222, Clause 6, Table 18) defines operations for reading and updating individual data elements within a DPP without retrieving or modifying the entire document. The following table specifies how each fine-grained DPP operation shall be mapped to AAS SubmodelElement operations. +The Fine Granular API (EN 18222, Clause 6, Table 18) defines operations for reading and updating individual data elements within a DPP without retrieving or modifying the entire document. The following table specifies how each fine-grained DPP operation shall be mapped to AAS SubmodelElement operations. .Mapping of DPP Fine Granular API Operations to AAS SubmodelElement Operations [.table-with-appendix-table] [cols="22%,30%,48%"] |=== -h| DPP Operation (FprEN 18222) h| AAS Service Operation(s) h| Description +h| DPP Operation (EN 18222) h| AAS Service Operation(s) h| Description | ReadDataElement | GetSubmodelElementByPath or GetSubmodel / GetSubmodelById -| Shall retrieve a single data element within a content Submodel by its element path. The `elementId` in the DPP maps to the `idShort`-based path in the AAS Submodel (see *TODO_XREF:[IDTA-01001 Part 1]*). +| Shall retrieve a single data element within a content Submodel by its element path. The `elementId` in the DPP maps to the `idShort`-based path in the AAS Submodel (see link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01001/v3.1.1/mappings/mappings.html#_format_path_idshortpath_serialization_in_json[IDTA-01001 Part 1]). In special cases it may also be the complete Submodel itself. | UpdateDataElement | PutSubmodelElementByPath or PutSubmodel / PutSubmodelById -| Shall update a single data element within a content Submodel. The `lastUpdate` field of the DppMeta Submodel should be updated accordingly. +| Shall update a single data element within a content Submodel. The `lastUpdate` field of the DppMetadata Submodel should be updated accordingly. |=== -For the mapping of DPP data element types (SingleValuedDataElement, MultiValuedDataElement, DataElementCollection, MultiLanguageDataElement, RelatedResource) to AAS SubmodelElement types (Property, SubmodelElementList, SubmodelElementCollection, MultiLanguageProperty, File), see *TODO_XREF:[IDTA-01001 Part 1 -- DPP Metamodel Mapping, Data Element Mapping]*. +For the mapping of DPP data element types (SingleValuedDataElement, MultiValuedDataElement, DataElementCollection, MultiLanguageDataElement, RelatedResource) to AAS SubmodelElement types (Property, SubmodelElementList, SubmodelElementCollection, MultiLanguageProperty, File), +see link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01001/v3.1.2/annex/dpp.html[IDTA-01001 Part 1 -- DPP Metamodel Mapping, Data Element Mapping]. [[dpp-serialization]] == Serialization Considerations -FprEN 18223 defines two JSON serialization formats for DPP content. These map to the existing AAS serialization formats as follows: +EN 18223 defines two JSON serialization formats for DPP content. These map to the existing AAS serialization formats as follows: .Mapping of DPP Serialization Formats to AAS Serialization Formats [.table-with-appendix-table] [cols="20%,25%,55%"] |=== -h| DPP Format (FprEN 18223) h| AAS Serialization h| Description +h| DPP Format (EN 18223) h| AAS Serialization h| Description -| *Compressed* (FprEN 18223, Clause 5.2) +| *Compressed* (EN 18223, Clause 5.2) | Value-Only (with minor differences) | The `elementId` is used as the JSON key. Metadata (`dictionaryReference`, `valueDataType`, `objectType`) is omitted. This is the default and mandatory format. -| *Full / Expanded* (FprEN 18223, Annex A) +| *Full / Expanded* (EN 18223, Annex A) | Normal (with differences) | Uses an `elements[]` array with explicit `elementId`, `objectType`, `dictionaryReference`, and `valueDataType` for each DataElement. Note that the AAS Normal serialization differs in structure: attribute names differ (`idShort` vs. `elementId`, `modelType` vs. `objectType`, `semanticId` vs. `dictionaryReference`), `semanticId` in AAS is a Reference object rather than a plain string, and the XSD data type prefix differs (`xs:` in AAS vs. `xsd:` in JTC24). |=== Implementations shall support the _compressed_ representation. The _full_ representation may be supported optionally. -The `representation` query parameter (FprEN 18222, Clause 8) controls which format is returned. If omitted, the _compressed_ format shall be used as default. +The `representation` query parameter (EN 18222, Clause 8) controls which format is returned. If omitted, the _compressed_ format shall be used as default. [NOTE] ==== -There are known differences in the serialization of MultiLanguageProperty and File between AAS Value-Only and JTC24 compressed format. Implementations shall ensure that the DPP output conforms to FprEN 18223. For details on these differences and the required transformations, see *TODO_XREF:[IDTA-01001 Part 1 -- DPP Metamodel Mapping, Serialization]*. -In *TODO_XREF:[IDTA-01001 Part 1 -- DPP Metamodel Mapping, Serialization]* also a detailed mapping for "Full / Expanded" format can be found. +There are known differences in the serialization of MultiLanguageProperty and File between AAS Value-Only and JTC24 compressed format. Implementations shall ensure that the DPP output conforms to EN 18223. +For details on these differences and the required transformations, see link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01001/v3.1.2/annex/dpp.html[IDTA-01001 Part 1 -- DPP Metamodel Mapping, Serialization]. +In link: https://industrialdigitaltwin.io/aas-specifications/IDTA-01001/v3.1.2/annex/dpp.html[IDTA-01001 Part 1 -- DPP Metamodel Mapping, Serialization] also a detailed mapping for "Full / Expanded" format can be found. ==== [[dpp-discovery]] == Discovery of Digital Product Passports via AAS Discovery Sequences -The discovery of Digital Product Passports can be implemented using the AAS discovery steps defined in *TODO_XREF:[IDTA-01002 Part 2 -- Figure 2]*. These steps enable clients to discover and access AAS instances based on asset identifiers, including the product identifiers used in Digital Product Passports. +The discovery of Digital Product Passports can be implemented using the AAS discovery steps defined in +link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01002/v3.1.2/http-rest-api/interactions.html#fig:seq-aas-endpoints[IDTA-01002 Part 2 -- Figure 2]. +These steps enable clients to discover and access AAS instances based on asset identifiers, including the product identifiers used in Digital Product Passports. A typical DPP discovery sequence proceeds as follows: @@ -241,9 +266,11 @@ A typical DPP discovery sequence proceeds as follows: . directly retrieves the AAS using *GetAssetAdministrationShellById* on the AAS Repository or Service (see sequence xref{image-seq-dpp-discovery-2}). . The DPP Service retrieves the relevant Submodels and composes the DPP document. -To enable discovery, the economic operator responsible for the product shall ensure that the AAS instance representing the DPP is linked to the product identifier via the `globalAssetId` or `specificAssetId` fields in the `AssetInformation` of the AAS. The `uniqueProductIdentifier` in the DppMeta Submodel shall correspond to the `globalAssetId` of the AAS. The explicit mapping is defined in *TODO_XREF:[IDTA-02099]*. +To enable discovery, the economic operator responsible for the product shall ensure that the AAS instance representing the DPP is linked to the product identifier via the `globalAssetId` or `specificAssetId` fields in the `AssetInformation` of the AAS. +The `uniqueProductIdentifier` in the DppMetadata Submodel shall correspond to the `globalAssetId` of the AAS. +The explicit mapping is defined in IDTA-02099. -.DPP Discovery and Composition Sequence with a Registry Service involved (see *TODO_XREF:[IDTA-01002 Part 2 -- Chapter Interactions]*) +.DPP Discovery and Composition Sequence with a Registry Service involved (see link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01002/v3.1.2/http-rest-api/interactions.htm[IDTA-01002 Part 2 -- Chapter Interactions]) [[image-seq-dpp-discovery-1]] [plantuml, seq-dpp-discovery, svg] .... @@ -270,9 +297,9 @@ activate RS RS --> DPPS: AAS Descriptor (incl. Submodel endpoints) deactivate RS -DPPS -> ASR: GetSubmodelById(dppMetaSubmodelId) +DPPS -> ASR: GetSubmodelById(DppMetadataSubmodelId) activate ASR -ASR --> DPPS: DppMeta (header fields + contentSpecificationIds) +ASR --> DPPS: DppMetadata (header fields + contentSpecificationIds) deactivate ASR loop for each object in contentSpecificationIds @@ -295,7 +322,7 @@ deactivate DPPS .... -.DPP Discovery and Composition Sequence with a Repository Service involved (see *TODO_XREF:[IDTA-01002 Part 2 -- Chapter Interactions]*) +.DPP Discovery and Composition Sequence with a Repository Service involved (see link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01002/v3.1.2/http-rest-api/interactions.html[IDTA-01002 Part 2 -- Chapter Interactions]) [[image-seq-dpp-discovery-2]] [plantuml, seq-dpp-discovery, svg] .... @@ -323,9 +350,9 @@ activate ASR ASR --> DPPS: AAS (incl. Submodel references) deactivate ASR -DPPS -> ASR: GetSubmodelById(dppMetaSubmodelId) +DPPS -> ASR: GetSubmodelById(DppMetadataSubmodelId) activate ASR -ASR --> DPPS: DppMeta (header fields + contentSpecificationIds) +ASR --> DPPS: DppMetadata (header fields + contentSpecificationIds) deactivate ASR loop for each object in contentSpecificationIds @@ -347,7 +374,7 @@ deactivate DPPS [[readdppversionbyidanddate]] == Retrieving Historical Versions of DPPs via AAS Versioning Mechanisms == -FprEN 18222 defines the ReadDPPVersionByIdAndDate operation for retrieving the version of a DPP that was current at a specified point in time. When using AAS infrastructure, this can be implemented by leveraging the versioning and timestamping features of AAS resources. +EN 18222 defines the ReadDPPVersionByIdAndDate operation for retrieving the version of a DPP that was current at a specified point in time. When using AAS infrastructure, this can be implemented by leveraging the versioning and timestamping features of AAS resources. To implement ReadDPPVersionByIdAndDate, an implementation shall perform the following steps: . Retrieve the AAS and all referenced Submodels as described in <>. @@ -367,7 +394,7 @@ participant "Submodel Repository/Service" as SR C -> AR: GetAssetAdministrationShellByIdAndDate(aasId, date) AR --> C: AAS (incl. Submodel references) loop for each Submodel in the AAS - C -> SR: GetSubmodelByIdAndDate(dppMetaSubmodelId, date) + C -> SR: GetSubmodelByIdAndDate(DppMetadataSubmodelId, date) SR --> C: Content Submodel (version at date) end @enduml @@ -376,7 +403,7 @@ end == HTTP API Mapping -The DPP operations described above shall be exposed through an HTTP REST API following the specifications of the Asset Administration Shell Services (FprEN 18222, Clause 8). In-path identifiers shall be percent-encoded. +The DPP operations described above shall be exposed through an HTTP REST API following the specifications of the Asset Administration Shell Services (EN 18222, Clause 8). In-path identifiers shall be percent-encoded. [Note] ==== @@ -387,7 +414,7 @@ In-path identifiers in AAS are base64url-encoded. [.table-with-appendix-table] [cols="25%,10%,30%,35%"] |=== -h| DPP Operation h| HTTP Method h| DPP Path (FprEN 18222) h| AAS Equivalent Endpoint +h| DPP Operation h| HTTP Method h| DPP Path (EN 18222) h| AAS Equivalent Endpoint | ReadDPPById | GET @@ -445,10 +472,12 @@ h| DPP Operation h| HTTP Method h| DPP Path (FprEN 18222) h| AAS Equivalent Endp Implementations of a DPP service based on AAS infrastructure shall ensure compliance with the applicable regulatory requirements. The following aspects are of particular importance: -*Archiving*: All changes to a DPP shall be tracked and archived per FprEN 18221. The AAS Services support this through the `updatedAt` attribute in `AdministrativeInformation` and the `date` query parameter for retrieving historical versions. Implementations shall maintain a complete audit trail of all modifications to a DPP. +*Archiving*: All changes to a DPP shall be tracked and archived per EN 18221. The AAS Services support this through the `updatedAt` attribute in `AdministrativeInformation` and the `date` query parameter for retrieving historical versions. Implementations shall maintain a complete audit trail of all modifications to a DPP. *Deletion restrictions*: Applicable regulations may prohibit the deletion of a DPP while the corresponding product is still in use or within mandatory retention periods. AAS implementations exposing DPPs shall enforce these restrictions regardless of whether the DeleteDPPById operation is supported. The AAS Services specification provides the DeleteAssetAdministrationShellById operation, but its use shall be governed by the applicable regulatory framework. -*Access control*: Implementations should enforce appropriate access control policies on DPP operations, in accordance with FprEN 18222, Clause 4.2–4.5. Different data elements within a DPP may require different levels of authorization depending on the stakeholder and their role in the product lifecycle. For further details see *TODO_XREF:[IDTA-01004 Part 4]*. +*Access control*: Implementations should enforce appropriate access control policies on DPP operations, in accordance with EN 18222, Clause 4.2–4.5. +Different data elements within a DPP may require different levels of authorization depending on the stakeholder and their role in the product lifecycle. +For further details see link:https://industrialdigitaltwin.io/aas-specifications/IDTA-01004/v3.1/index.html[IDTA-01004 Part 4]. -*Error handling*: All error responses shall conform to the `Result` object structure defined in FprEN 18222, Clause 7, containing an array of `Message` objects with `messageType`, `text`, `code`, `correlationId`, and `timestamp`. The HTTP status codes shall follow FprEN 18222, Table 15. \ No newline at end of file +*Error handling*: All error responses shall conform to the `Result` object structure defined in EN 18222, Clause 7, containing an array of `Message` objects with `messageType`, `text`, `code`, `correlationId`, and `timestamp`. The HTTP status codes shall follow EN 18222, Table 15. \ No newline at end of file