From 392c0f1fb270778a0e61682bedf39b886ecdbcbd Mon Sep 17 00:00:00 2001 From: birgitboss Date: Tue, 26 May 2026 13:37:58 +0200 Subject: [PATCH] new: Annex on DPP --- .../modules/ROOT/pages/annex/dpp.adoc | 454 ++++++++++++++++++ .../modules/ROOT/pages/changelog.adoc | 2 + .../ROOT/partials/diagrams/seq-dpp.puml | 53 ++ 3 files changed, 509 insertions(+) create mode 100644 documentation/IDTA-01002-3/modules/ROOT/pages/annex/dpp.adoc create mode 100644 documentation/IDTA-01002-3/modules/ROOT/partials/diagrams/seq-dpp.puml diff --git a/documentation/IDTA-01002-3/modules/ROOT/pages/annex/dpp.adoc b/documentation/IDTA-01002-3/modules/ROOT/pages/annex/dpp.adoc new file mode 100644 index 00000000..4e4a14b5 --- /dev/null +++ b/documentation/IDTA-01002-3/modules/ROOT/pages/annex/dpp.adoc @@ -0,0 +1,454 @@ +//// +Copyright (c) 2023 Industrial Digital Twin Association + +This work is licensed under a [Creative Commons Attribution 4.0 International License]( +https://creativecommons.org/licenses/by/4.0/). + +SPDX-License-Identifier: CC-BY-4.0 + +//// + + +[[dpp]] += Implementing Digital Product Passport Operations via Asset Administration Shell Services + +== 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. + +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. +==== + +[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". +A conformant DPP service based on AAS shall implement all aspects described in this annex together with the metamodel mapping and the Submodel Template. +==== + + + +== 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: + +* 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. + +[Note] +==== +Attention: The DppMeta 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]*. + +[[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. +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. + +.DPP Composition Sequence via AAS Discovery, Registry, and Submodel Services +[[image-seq-dpp]] +[plantuml, seq-dpp, svg] +.... +include::partial$diagrams/seq-dpp.puml[] +.... + +<> illustrates the composition process for a ReadDPPByProductId interaction. The DPP Application discovers the relevant AAS via the Discovery Service, resolves the Submodel endpoints via the Registry Service, retrieves the relevant Submodels, and merges them into a conformant DPP payload. + +[[dpp-decomposition]] +=== Decomposition Process (Write Path) + +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. + +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. + +.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 + +| ReadDPPById +| GetAssetAdministrationShellById / GetAssetAdministrationShell or GetAssetAdministrationShellDescriptorById + GetSubmodel / GetSubmodelById (Value-Only or Normal) for each referenced and relevant Submodel +| Shall retrieve the AAS by its identifier, fetch all referenced Submodels, and compose the DPP document as described in <>. The `representation` query parameter controls the serialization format (see <>). + +| ReadDPPByProductId +| GetAllAssetAdministrationShellsByAssetId / SearchAllAssetAdministrationShellIdsByAssetLink + GetSubmodel (Value-Only or Normal) for each referenced and relevant Submodel +| Shall resolve the product identifier to an AAS (via `globalAssetId`) and compose the DPP document. + +[Note] +=== +Multiple AAS instances might be associated with the provided product identifier. +=== + +| ReadDPPVersionByIdAndDate +| GetAssetAdministrationShellVersionByIdAndDate / QueryAssetAdministrationShells / QueryAssetAdministrationShellDescriptors + GetSubmodel (Value-Only or Normal) for each referenced and relevant Submodel +| Shall retrieve the version of the DPP that was current at the specified point in time (ISO 8601 UTC timestamp). The implementation shall select the latest version of each Submodel whose `updatedAt` timestamp is less than or equal to the requested date. + +| ReadDPPIdsByProductIds +| GetAllAssetAdministrationShellIdsByAssetId / SearchAllAssetAdministrationShellIdsByAssetLink +| 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. + +| 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. + +| DeleteDPPById +| DeleteAssetAdministrationShellById / DeleteAssetAdministrationShellDescriptorById ( + DeleteSubmodelReference / DeleteSubmodelDescriptorById + DeleteSubmodelById for the Submodel "DppMeta") +| 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. + +.Mapping of DPP Registry API Operations to AAS Service Operations + +[Note] +==== +Although the AAS supports an AAS Registry this kind of Registry is not necessarily the same as for the DPP Registry and should not be mixed up. +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 + +| RegisterProductDPP +| Direct call to the DPP Registry +| Upon creation of a new DPP, the implementation should register the DPP at the DPP Registry. + +[Note] +=== +So far no Submodel Template Specification is available for posting the DPP registration information. +=== +|=== + +[NOTE] +==== +The DPP Registry is typically a centrally hosted service operated independently from individual DPP data providers. The exact mechanism for registration may depend on the specific DPP Registry implementation and the applicable regulatory framework. +==== + + +== 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. + +.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 + +| 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]*). +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. + + +|=== + +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]*. + + +[[dpp-serialization]] +== Serialization Considerations + +FprEN 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 + +| *Compressed* (FprEN 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) +| 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. + +[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. +==== + + +[[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. + +A typical DPP discovery sequence proceeds as follows: + +. A client application obtains a product identifier, for instance by scanning a data carrier (e.g., QR code) on the product. The client executes the DPP operation ReadDPPByProductId, passing the product identifier as input. +. The DPP Service invokes the *SearchAllAssetAdministrationShellIdsByAssetLink* operation on the AAS Discovery Service, passing the product identifier as the `globalAssetId`. +. The Discovery Service returns the identifiers of AAS instances associated with the product identifier. +. The DPP Service selects the appropriate AAS identifier and invokes *GetAssetAdministrationShellDescriptorById* on the AAS Registry Service to obtain the AAS Descriptor, which includes the endpoints for accessing the AAS and/or its Submodels (see sequence xref{image-seq-dpp-discovery-1}), or +. 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]*. + +.DPP Discovery and Composition Sequence with a Registry Service involved (see *TODO_XREF:[IDTA-01002 Part 2 -- Chapter Interactions]*) +[[image-seq-dpp-discovery-1]] +[plantuml, seq-dpp-discovery, svg] +.... +@startuml +'title Discovery and Composition via AAS Services + +actor "DPP Client" as C +participant "DPP Service" as DPPS +participant "AAS Discovery Service" as DS +participant "AAS Registry Service" as RS +participant "AAS or Submodel Repository / Service" as ASR + +activate C +C -> DPPS: ReadDPPByProductId +activate DPPS + +DPPS -> DS: SearchAllAssetAdministrationShellIdsByAssetLink(globalAssetId=productId) +activate DS +DS --> DPPS: aasIds[] +deactivate DS + +DPPS -> RS: GetAssetAdministrationShellDescriptorById(aasId) +activate RS +RS --> DPPS: AAS Descriptor (incl. Submodel endpoints) +deactivate RS + +DPPS -> ASR: GetSubmodelById(dppMetaSubmodelId) +activate ASR +ASR --> DPPS: DppMeta (header fields + contentSpecificationIds) +deactivate ASR + +loop for each object in contentSpecificationIds + DPPS -> ASR: GetSubmodelById(contentSubmodelId, representation[, date]) + activate ASR + ASR --> DPPS: Content Submodel + deactivate ASR +end + +note right of DPPS + Compose the DPP document +end note + + +DPPS -> C: DPP document +deactivate DPPS + + +@enduml +.... + + +.DPP Discovery and Composition Sequence with a Repository Service involved (see *TODO_XREF:[IDTA-01002 Part 2 -- Chapter Interactions]*) +[[image-seq-dpp-discovery-2]] +[plantuml, seq-dpp-discovery, svg] +.... +@startuml +'title Discovery and Composition via AAS Services + +actor "DPP Client" as C +participant "DPP Service" as DPPS +participant "AAS Discovery Service" as DS +participant "AAS or Submodel Repository / Service" as ASR + +activate C + +C -> DPPS: ReadDPPByProductId + +activate DPPS + +DPPS -> DS: SearchAllAssetAdministrationShellIdsByAssetLink(globalAssetId=productId) +activate DS +DS --> DPPS: aasIds[] +deactivate DS + +DPPS -> ASR: GetAssetAdministrationShellById(aasId) +activate ASR +ASR --> DPPS: AAS (incl. Submodel references) +deactivate ASR + +DPPS -> ASR: GetSubmodelById(dppMetaSubmodelId) +activate ASR +ASR --> DPPS: DppMeta (header fields + contentSpecificationIds) +deactivate ASR + +loop for each object in contentSpecificationIds + DPPS -> ASR: GetSubmodelById(contentSubmodelId, representation[, date]) + activate ASR + ASR --> DPPS: Content Submodel + deactivate ASR +end + +note right of DPPS + Compose the DPP document +end note + +DPPS -> C: DPP document +deactivate DPPS + +@enduml +.... + +[[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. + +To implement ReadDPPVersionByIdAndDate, an implementation shall perform the following steps: +. Retrieve the AAS and all referenced Submodels as described in <>. +. For each Submodel, select the version whose `updatedAt` timestamp is less than or equal to the requested date. This can be achieved by using the `date` query parameter when retrieving the Submodel, which instructs the AAS Service to return the version that was current at that point in time. +. Compose the DPP document from the selected versions of the Submodels as described in <>. + +.ReadDPPVersionByProductIdAndDate Sequence via AAS Versioning +[[image-seq-dpp-versioning]] +[plantuml, seq-dpp-versioning, svg] +.... +@startuml +title ReadDPPVersionByIdAndDate via AAS Versioning + +actor Client as C +participant "AAS Repository/Service" as AR +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) + SR --> C: Content Submodel (version at date) +end +@enduml +.... + + +== 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. + +[Note] +==== +In-path identifiers in AAS are base64url-encoded. +==== + +.Exemplary HTTP Mapping of DPP Operations to AAS Repository Endpoints +[.table-with-appendix-table] +[cols="25%,10%,30%,35%"] +|=== +h| DPP Operation h| HTTP Method h| DPP Path (FprEN 18222) h| AAS Equivalent Endpoint + +| ReadDPPById +| GET +| `v1/dpps/{dppId}` +| `shells/{aasId}` + `submodels/{smId}/$value` (per Submodel) + +| ReadDPPByProductId +| GET +| `v1/dppsByProductId/{productId}` +| `shells?assetIds={productId}` + Submodel retrieval + +| ReadDPPVersionByIdAndDate +| GET +| `v1/dppsByIdAndDate/{dppId}?date={timestamp}` +| `shells/{aasId}` + `submodels/{smId}/$value` with `date` filter + +| ReadDPPIdsByProductIds +| POST +| `v1/dppsByProductIds` +| `lookup/shells` (Discovery) for each product ID + +| CreateDPP +| POST +| `v1/dpps` +| `shells` (POST) + `submodels` (POST per Submodel) + +| UpdateDPPById +| PATCH +| `v1/dpps/{dppId}` +| `shells/{aasId}` (PUT) + `submodels/{smId}` (PUT per Submodel) + +| DeleteDPPById +| DELETE +| `v1/dpps/{dppId}` +| `shells/{aasId}` (DELETE) + +| RegisterProductDPP +| POST +| `v1/registerDPP` +| `registry/shell-descriptors` (POST) or DPP Registry API + +| ReadDataElement +| GET +| `v1/dpps/{dppId}/elements/{elementPath}` +| `submodels/{smId}/submodel-elements/{elementPath}/$value` + +| UpdateDataElement +| PUT +| `v1/dpps/{dppId}/elements/{elementPath}` +| `submodels/{smId}/submodel-elements/{elementPath}` +|=== + + +== Compliance Considerations + +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. + +*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]*. + +*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 diff --git a/documentation/IDTA-01002-3/modules/ROOT/pages/changelog.adoc b/documentation/IDTA-01002-3/modules/ROOT/pages/changelog.adoc index f3a04ced..0e4d8467 100644 --- a/documentation/IDTA-01002-3/modules/ROOT/pages/changelog.adoc +++ b/documentation/IDTA-01002-3/modules/ROOT/pages/changelog.adoc @@ -19,6 +19,8 @@ Major Changes: * Added a new profile for the AAS Repository Service Specification, the "Identifiable Profile", which only includes operations that require an identifier as input parameter. (https://github.com/admin-shell-io/aas-specs-api/issues/496[#496]) * New API operations and profiles for signing, including Asset Administration Shell Repository Service Specification - Signature Profile SSP-004, Submodel Repository Service Specification - Signature Profile SSP-003, and Concept Description Repository Service Specification - Signature Profile SSP-004 (https://github.com/admin-shell-io/aas-specs-api/issues/518[#518]) * Add the asynchronous AASX File Server Service Specification (https://github.com/admin-shell-io/aas-specs-api/issues/347[#347]) +* Add new section in the annex on the usage of the AAS Services for implementing a digital product passport (DPP) based on EN 18222 and the relevant API operations for DPP interactions. +This section also includes an overview of how to expose the DPP interactions through a REST API that follows the specifications of the AAS Services. Minor Changes: diff --git a/documentation/IDTA-01002-3/modules/ROOT/partials/diagrams/seq-dpp.puml b/documentation/IDTA-01002-3/modules/ROOT/partials/diagrams/seq-dpp.puml new file mode 100644 index 00000000..e37ee0df --- /dev/null +++ b/documentation/IDTA-01002-3/modules/ROOT/partials/diagrams/seq-dpp.puml @@ -0,0 +1,53 @@ +@startuml + +participant DPPClient as "DPP Client" + +box "DPP Service" +participant Client as "DPP Application" +end box + + +box "Discovery Service" + participant AASDiscovery as "AAS Discovery Interface" +end box + +box "Registry Service" + participant AASRegistry as "AAS Registry Interface" +end box + +box "AAS or Submodel (Repository) Service" + participant SMService as "Submodel Interface" +end box + +activate DPPClient +DPPClient -> Client : scan data carrier (result: product ID) + +activate Client +Client <- Client : map product ID to globalAssetId + +Client -> AASDiscovery: SearchAllAssetAdministrationShellIdsByAssetLink +activate AASDiscovery +Client <-- AASDiscovery : IDs of AAS +deactivate AASDiscovery +Client -> Client : select AAS ID + + +Client -> AASRegistry : GetAssetAdministrationShellDescriptorById +activate AASRegistry +Client <-- AASRegistry : AAS Descriptor with Submodel Endpoints +deactivate AASRegistry +Client -> Client : extract relevant Submodel Endpoints + +loop for all relevant Submodels +Client -> SMService : GetSubmodel(ById) +activate SMService +Client <-- SMService : Submodel +deactivate SMService +end + +Client <- Client : identify DppMeta and content Submodels +Client <- Client : serialize and assemble DPP document +DPPClient <-- Client : return DPP +deactivate Client + +@enduml \ No newline at end of file