Supply Chain Process
We assume that the calculation and exchange of PCF data is “new territory” for many companies. In large or larger enterprises (e.g., OEM or Tier-1 suppliers) the topic of sustainability with its various facets has been on the agenda for several years now. Appropriate structures and organizations were set up there. In this respect, it can be assumed that they have the expertise and resources for a PCF calculation. Corresponding, self-developed IT tools can also be found there. We cannot expect this for small and medium-sized enterprises (SMEs). In particular small companies often lack the knowledge and resources to calculate a PCF.
These premises are therefore relevant for the following customer journeys:
A PCF calculation requires expert or at least in-depth knowledge. A PCF calculation is currently mostly created manually; automation is not common or possible in most cases. Automation is also not yet feasible because there are no concepts or standards for verifying PCF data. Due to the (manual) effort, PCF calculation and data exchange will initially only be carried out for selected products. Accordingly, the presented customer journeys are characterized by manual process steps. However, as the topic becomes more widely known in the automotive supply chain (especially among SMEs), greater automation should be sought. This is the only way to represent a larger (ideally the entire) range of products.
The scope of our business process is the calculation and the exchange of PCF data across the supply chain for parts/components that are already in series production (→ "after start of production (SOP)"). One can therefore assume that a real supply chain already exists for this part/component.
To describe the process, we defined two customer journeys:
The customer journey “PCF data exchange” describes an asynchronous communication process: a customer requests the PCF from their supplier for a component (“PCF Request”), and the supplier provides the requested data (“PCF Response”). If necessary, the requested PCF data must first be determined; this leads to the second customer journey “PCF calculation”. The exchange-process is initiated top-down (e.g., at the OEM; but it can also start at any level of the supply chain), starting with a request of a customer to the supplier. It could then be continued step by step throughout the entire tier-n supply chain. Ideally, the entire supply chain (or actually: the entire supply tree) would be covered via this cascading request/response process. The result would be a PCF that is 100% based on requested and reported data.
As stated in the Development View the Standard will be extended with synchronous data exchange and AAS-Submodel 3.0. Therefore, the business logic will be enhanced to also make proactive PCF data offers in addition to asynchronous PCF requests. We recommend all solution and data providers to adapt, test and certify their solution accordingly to enable a smooth transition. The second change to the standard will add customerPartId as an optional field in the PCF request thus enabling creation of a PCF requests with the customerPartId instead of manufacturerPartId.
In the real world, this will not be implemented this way, at least in the short and medium term. It can be assumed that this process and information chain will break down at certain points in the supply chain. There, data is not requested, but calculated using secondary data, as is standard procedure these days. There can be various reasons for this:
The affected part of the supply chain is only of minor relevance to the PCF; the effort required to determine the real data would therefore not be worthwhile. The supplier cannot or does not want to provide corresponding data. However, it is important that a PCF value reported from a supplier to its customer always represents the entire supply chain behind it. Therefore, the following data is recorded in a PCF calculation and aggregated to form the resulting PCF:
- direct emissions that are generated in the supplier's own production system ("Scope 1")
- indirect emissions from purchased energy ("Scope 2")
- upstream emissions caused by purchased products from the upstream supply chain ("Scope 3")
The data for direct and indirect emissions will usually come from internal data sources, as these emission-shares are generated in the supplier's own production system. The upstream emissions ("Scope 3") can either be requested from the respective sub-supplier or could be calculated, e.g. by using information from eco-databases. Putting all together, the transparency on the PCF for a given part or component is created through a cascade of top-to-bottom PCF requests, and a cascade of aggregated PCF data from bottom to top.
This customer journey describes the exchange of PCF data in an asynchronous request/response process.
PCF data is exchanged between a data consumer (e.g., supplier on tier n) and a data provider (e.g., supplier on tier n+1). It is basically an asynchronous request/response process that is started by the data consumer:
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) 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. With this request, the process temporarily ends for the data consumer. The ball is now in the data provider's playing field:
The data provider receives the PCF request (message/display in his PCF data exchange tool). The data provider checks whether the requested data is already available (i.e., whether the PCF has already calculated in the past but has not yet been provided to the customer yet). If the data is not yet available, the data provider must create it first. At this point, he starts the “PCF Calculation” subjourney (see below). At the end of this subjourney, the PCF data is available, and the provider can answer the original request with the next steps. The data provider sends a PCF response (according to the standardized API see CX-0136) to the data consumer. At the same time, the data is made available in Catena-X (which means from a technical perspective, that a PCF submodel is attached to the corresponding digital twin of the component). For the data provider, the process is now over, and the consumer's request has been answered with the response. On the consumer side, a few more steps follow:
The data consumer, who sent the initial PCF request, receives the PCF response (message/display in his PCF data exchange tool). With the data exchange tool, the consumer can access and “pick up” the PCF data, according to the standardized PCF data model (see Semantic Model). Remark: There are currently no options for data verification or acceptance/rejection of transmitted data at this stage in the process. These topics are currently still being discussed on Catena-X association level and are therefore not yet covered in the processes and tools. This might happen with later releases.
The data consumer can now transfer this data to his internal systems/databases (e.g., a PCF calculation tool), and use it for the internal business processes (e.g., PCF calculation or reporting). This ends this customer journey.
This customer journey describes the calculation of a PCF in compliance with the Catena-X PCF Rulebook with some of the required data obtained via the Catena-X network.
The calculation process will often be triggered by an incoming PCF request (see subjourney "PCF data exchange"). But of course, a PCF calculation can also be carried out proactively without a corresponding request via PCF Request. To determine a PCF, an appropriate calculation tool is usually used, which guides the user through the process and ensures that all relevant data is taken into account. We will limit ourselves here to a generic, tool-independent presentation of the most important steps.
Make a plan: What are the different components of the PCF? Where can I get the relevant data from? → This structuring should be supported by an appropriate process in the calculation tool. Put the direct emissions from the production site (e.g., use of natural gas or fuels) into the calculation. → Get the raw data from internal data sources and enter them in the calculation tool. Put the indirect emissions from purchased energy into the calculation. → Get the raw data (consumption values, energy mix, …) from internal data sources and from the energy supplier, and enter it in the calculation tool. Upstream emissions: For sub-components with a (expected) relevant share on the PCF, the aim is to use real data (or primary data) for the calculation. Therefore, a PCF request is sent to the suppliers of these sub-components, to obtain appropriate real data (see subjourney "PCF data exchange"). As soon as the data is available (via PCF Response), it can be used as input for the calculation. For other sub-components, which only make up a small proportion of the upstream emissions, there will be no request of data to the supplier. Instead, the data will be obtained from a database for secondary data. If necessary, put other emissions and further data into the calculation (e.g., transport emissions, waste, recycling quotas, ...). Put it all together and get the overall PCF. Transfer PCF to the exchange tool (or in general: make the PCF data available).