Skip to content

Commit

Permalink
docs(pcf-exchange): fix link and spelling bugs (#1134)
Browse files Browse the repository at this point in the history
  • Loading branch information
@mhellmeier
mhellmeier committed Feb 7, 2025
1 parent af90a5c commit f1d33aa
Show file tree
Hide file tree
Showing 3 changed files with 24 additions and 18 deletions.
24 changes: 12 additions & 12 deletions ...ts/PCF Exchange Kit/Software Development View/page_software-development-view.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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/ | `[<Company's BPNL>]` |
| [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/ | `[<Company's BPNL>]` |
| 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").
Expand Down Expand Up @@ -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:<p></p>
![Tier1Supplier without bilateral contracts](../resources/development-view/Tier1AOpenUP.png)

<details>
<summary>Empty Access Policy (JSON)</summary>

Expand Down
4 changes: 4 additions & 0 deletions docs-kits/kits/PCF Exchange Kit/changelog.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
14 changes: 8 additions & 6 deletions docs-kits/kits/PCF Exchange Kit/page_adoption-view.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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:

Expand All @@ -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)

Expand Down Expand Up @@ -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:

Expand Down Expand Up @@ -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

Expand Down

0 comments on commit f1d33aa

Please sign in to comment.