From f1d33aa3826b73bef819ba8f0e00eb94ed50b914 Mon Sep 17 00:00:00 2001 From: Malte Hellmeier Date: Fri, 7 Feb 2025 15:18:30 +0100 Subject: [PATCH] docs(pcf-exchange): fix link and spelling bugs (#1134) --- .../page_software-development-view.md | 24 +++++++++---------- docs-kits/kits/PCF Exchange Kit/changelog.md | 4 ++++ .../PCF Exchange Kit/page_adoption-view.md | 14 ++++++----- 3 files changed, 24 insertions(+), 18 deletions(-) diff --git a/docs-kits/kits/PCF Exchange Kit/Software Development View/page_software-development-view.md b/docs-kits/kits/PCF Exchange Kit/Software Development View/page_software-development-view.md index 06968858c7a..e228fc1fa4a 100644 --- a/docs-kits/kits/PCF Exchange Kit/Software Development View/page_software-development-view.md +++ b/docs-kits/kits/PCF Exchange Kit/Software Development View/page_software-development-view.md @@ -26,13 +26,13 @@ The following chapter illustrates the process from searching for an EDC point, t ### EDC Discovery and dDTR Access -In order to receive the EDC endpoints for a requested partner, the EDC Discovery Service is used, following the [CX-0001](https://catenax-ev.github.io/docs/next/standards/CX-0001-EDCDiscoveryAPI) EDC Discovery API standard. Therefor, at least the BPNL (Business Partner Number Legal) entity needs to be known. For more details please refer to the Catena-X standard above. +In order to receive the EDC endpoints for a requested partner, the EDC Discovery Service is used, following the [CX-0001](https://catenax-ev.github.io/docs/next/standards/CX-0001-EDCDiscoveryAPI) EDC Discovery API standard. Therefore, at least the BPNL (Business Partner Number Legal) entity needs to be known. For more details please refer to the Catena-X standard above. ![EDCDiscoveryAndDTRAccess](../resources/development-view/EDCDiscoveryanddDTRAccess.png) ### PCF Request -In order to request PCF values via the PCF API endpoint first of all the EDC PCF asset needs to be identified. Therefor, the decentralized Digital Twin Registry (dDTR) is used. Data providers must register their dDTR(s) as EDC assets following the [CX-0002](https://catenax-ev.github.io/docs/next/standards/CX-0002-DigitalTwinsInCatenaX) Digital Twins in Catena-X standard. After identifying the dDTR, the digital twin with the related PCF submodel can be looked up (see [API calls [0003 +0004]](#api-calls)). An example is documented [here](#payload-for-requesting-pcf-sub-model). +In order to request PCF values via the PCF API endpoint first of all the EDC PCF asset needs to be identified. Therefore, the decentralized Digital Twin Registry (dDTR) is used. Data providers must register their dDTR(s) as EDC assets following the [CX-0002](https://catenax-ev.github.io/docs/next/standards/CX-0002-DigitalTwinsInCatenaX) Digital Twins in Catena-X standard. After identifying the dDTR, the digital twin with the related PCF submodel can be looked up (see [API calls [0003 +0004]](#api-calls)). An example is documented [here](#payload-for-requesting-pcf-sub-model). After successfully locating the corresponding material twin containing a PCF submodel, the EDC asset containing the PCF request endpoint can be extracted (example payload can be found [here](#payload-for-edc-data-asset-pcf)) and the query for a PCF dataset can be initiated, as illustrated in the attached sequence diagram. @@ -53,16 +53,16 @@ The sequence diagram provided below presents an example of a PCF update flow. An #### API Calls -| Call | Method | Path | Parameter | -|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------|------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------| -| [001](https://eclipse-tractusx.github.io/docs-kits/next/kits/Digital%20Twin%20Kit/Software%20Development%20View/API%20EDC%20Discovery/post-list-of-bpns-or-an-empty-array-to-retrieve-available-company-connector-authorization-required-roles-view-connectors) (Lookup EDC endpoints) | POST | /api/administration/Connectors/discovery/ | `[]` | -| [002](https://eclipse-tractusx.github.io/docs-kits/next/kits/tractusx-edc/docs/samples/management-api-v2-walkthrough/catalog) (Look up dDTR) | POST | /v2/catalog/request | --> Lookup Asset in the EDC catalog (EDC asset type data.core.digitalTwinRegistry) | -| [003](https://eclipse-tractusx.github.io/docs-kits/next/kits/Digital%20Twin%20Kit/Software%20Development%20View/API%20AAS%20Discovery/get-all-asset-administration-shell-ids-by-asset-link) (Lookup Twin ID) | GET | /lookup/shells | `assetIds= [{"key": "manufacturerPartId", "value":"mat345",{"key":"digitalTwinType", "value": "PartType"}}]` | -| [004](https://eclipse-tractusx.github.io/docs-kits/next/kits/Digital%20Twin%20Kit/Software%20Development%20View/API%20AAS%20Registry/get-all-asset-administration-shell-descriptors) (Lookup PCF submodel/EDC asset ID) | GET | /shell-descriptors | `{DIGITAL TWIN ID}` | -| [005](../resources/development-view/catena-x-pcf-endpoint-1_1_1.yaml) (Requesting PCF value) | GET | /productIds | {productId} | -| [006](../resources/development-view/catena-x-pcf-endpoint-1_1_1.yaml) (Sending PCF value) | PUT | /productIds | {productId} | +| Call | Method | Path | Parameter | +|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------|------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------| +| Lookup EDC endpoints | POST | /api/administration/Connectors/discovery/ | `[]` | +| Lookup dDTR | POST | /v2/catalog/request | --> Lookup Asset in the EDC catalog (EDC asset type data.core.digitalTwinRegistry) | +| Lookup Twin ID | GET | /lookup/shells | `assetIds= [{"key": "manufacturerPartId", "value":"mat345",{"key":"digitalTwinType", "value": "PartType"}}]` | +| Lookup PCF submodel/EDC asset ID | GET | /shell-descriptors | `{DIGITAL TWIN ID}` | +| Requesting PCF value | GET | /productIds | {productId} | +| Sending PCF value | PUT | /productIds | {productId} | -- The assetIds under [003] must be base64 encoded! +- The assetIds under *Lookup Twin ID* must be base64 encoded! - When responding an PCF exchange request, the "requestID" is mandatory in the PUT call. - When sharing a PCF update, the "requestID" is NOT allowed in the PUT call. - The EDC asset used to receive a PCF is NOT looked up through AAS, but identified by type ("data.pcf.exchangeEndpoint"). @@ -258,7 +258,7 @@ The content of the access policy depends on the criterias used within the usage The following paragraphs give options how to achieve this. These options can always be replaced by corresponding (or even more restictive) policies, as long as the requirement of delivering only one offer per PCF Exchange asset version is met: If *no bilateral contract* reference criteria are used *in any usage policy* attached to the PCF Exchange asset, an empty access policy can be used:

![Tier1Supplier without bilateral contracts](../resources/development-view/Tier1AOpenUP.png) - +
Empty Access Policy (JSON) diff --git a/docs-kits/kits/PCF Exchange Kit/changelog.md b/docs-kits/kits/PCF Exchange Kit/changelog.md index 3ff8b803328..46d77719950 100644 --- a/docs-kits/kits/PCF Exchange Kit/changelog.md +++ b/docs-kits/kits/PCF Exchange Kit/changelog.md @@ -11,6 +11,10 @@ sidebar_position: 1 All notable changes to this Kit will be documented in this file. +## [1.2.1] - 2025-02-07 + +* Fix broken links and spelling mistakes + ## [1.2.0] - 2024-08-01 ### Added diff --git a/docs-kits/kits/PCF Exchange Kit/page_adoption-view.md b/docs-kits/kits/PCF Exchange Kit/page_adoption-view.md index d143736cbd9..06e6759175d 100644 --- a/docs-kits/kits/PCF Exchange Kit/page_adoption-view.md +++ b/docs-kits/kits/PCF Exchange Kit/page_adoption-view.md @@ -28,9 +28,9 @@ Report and steer the de-carbonization of our value chain with dedicated measures Addressing supply chain carbon emissions today is missing reliable data about baseline emissions, effect of reductions and best practices. This is due to three reasons: - Complexity of supply chains leading to huge amount of data: complex supply chains spanning different countries and actors from many industries lead to huge amounts of data. - + - Lack of trust: unwillingness to share data due to the risk of losing competitive advantage (data is shared with competitors). - + - Missing standards for measuring carbon emissions in a comparable way. At the core of our project is the recognition of a current challenge - the lack of transparency and accessibility to real PCF information in supply chains. Through our project, we strive to bridge this information gap by establishing a trusted and collaborative and interoperable environment. Suppliers will have the opportunity to share their PCF data with confidence, knowing that it remains sovereign and under their control. @@ -98,7 +98,7 @@ PCF data is exchanged between a data consumer (e.g., supplier on tier n) and a d - The data consumer realizes that he needs the PCF for a specific component and that this data is not available in his local data (or is not of sufficient quality). - With his PCF data exchange tool, the data consumer checks whether the required PCF data is available via Catena-X (from a technical perspective, this means that there is already a digital twin for the component and that the PCF submodel is available for this twin). If so, the tool would “fetch up” this data. If not, the user can request this data from the supplier as described in the next steps. -- The data consumer submits a “PCF request” (according to the standardized API [CX-0136](https://catenax-ev.github.io/docs/next/standards/CX-0136-UseCasePCF)) to his supplier. In doing so, he asks the supplier to provide PCF data for the specific component, which was determined in accordance with the requirements of the Catena-X PCF Rulebook ([CX-0029](https://catenax-ev.github.io/docs/next/standards/CX-0029-ProductCarbonFootprintRulebook)). +- The data consumer submits a “PCF request” (according to the standardized API [CX-0136](https://catenax-ev.github.io/docs/next/standards/CX-0136-UseCasePCF)) to his supplier. In doing so, he asks the supplier to provide PCF data for the specific component, which was determined in accordance with the requirements of the [Catena-X PCF Rulebook](https://catenax-ev.github.io/assets/files/CX-NFR-PCF-Rulebook_v.3.0-04874a80a6d27511df06e07ae3049278.pdf). With this request, the process temporarily ends for the data consumer. The ball is now in the data provider's playing field: @@ -120,7 +120,7 @@ This ends this customer journey. ### Customer Journey “PCF Calculation” -This customer journey describes the calculation of a PCF in compliance with the Catena-X PCF Rulebook ([CX-0029](https://catenax-ev.github.io/docs/next/standards/CX-0029-ProductCarbonFootprintRulebook)), with some of the required data obtained via the Catena-X network. +This customer journey describes the calculation of a PCF in compliance with the [Catena-X PCF Rulebook](https://catenax-ev.github.io/assets/files/CX-NFR-PCF-Rulebook_v.3.0-04874a80a6d27511df06e07ae3049278.pdf) with some of the required data obtained via the Catena-X network. ![PCF Calculation](resources/adoption-view/PCFCalculation.png) @@ -397,7 +397,7 @@ For this KIT only the PCF data model is used. The PCF data model follows the [CX #### Data Model Overview -The Catena-X PCF data model has been developed in accordance with the "Technical Specifications for PCF Data Exchange" from the WBCSD (World Business Council for Sustainable Development)/ PACT initiative. The basis for the specification of the Catena-X PCF data model is the PCF Rulebook V3.0.0 (see [CX-0029](https://catenax-ev.github.io/docs/next/standards/CX-0029-ProductCarbonFootprintRulebook)). +The Catena-X PCF data model has been developed in accordance with the "Technical Specifications for PCF Data Exchange" from the WBCSD (World Business Council for Sustainable Development)/ PACT initiative. The basis for the specification of the Catena-X PCF data model is the [PCF Rulebook v3.0.0](https://catenax-ev.github.io/assets/files/CX-NFR-PCF-Rulebook_v.3.0-04874a80a6d27511df06e07ae3049278.pdf). The following illustration describes the logical structure of the Catena-X PCF data model: @@ -618,7 +618,9 @@ The diagram shown here illustrates the interaction between the PCF KIT and the o The relevant standards can be downloaded from the official [Catena-X Standard Library](https://catenax-ev.github.io/docs/next/standards/overview): - [CX-0136 Product Carbon Footprint UseCase (Version 2.0.0)](https://catenax-ev.github.io/docs/next/standards/CX-0136-UseCasePCF) -- [CX-0029 Product Carbon Footprint Rulebook (Version 3.0.0)](https://catenax-ev.github.io/docs/next/standards/CX-0029-ProductCarbonFootprintRulebook) + +### Non-rechnical requirement +- [Product Carbon Footprint Rulebook (Version 3.0.0)](https://catenax-ev.github.io/assets/files/CX-NFR-PCF-Rulebook_v.3.0-04874a80a6d27511df06e07ae3049278.pdf) ## REFERENCE IMPLEMENTATIONS