Skip to main content
Release: 24.03 (current)

CX-0096 Triangle For Digital Product Pass v1.1.0

ABSTRACT​

This standard focuses on the digital product passport use case. This includes relevant requirements for

  • data provider, that want to provide different passports through Catena-X,
  • data consumer, that are searching for different passports in Catena-X, and
  • application developer / provider supporting the provisioning and consuming of passport data.

Specific passports that shall be mentioned here are the battery passport and the transmission passport, which are first realizations of product passports in Catena-X.

In this document, keywords for registering and searching digital twins and their passports submodels are defined.

1. INTRODUCTION​

This document defines the so-called standardization triangle for the digital product passport use case. Standardization triangle hereby means the mandatory components, data models, APIs etc. that are required to enable the digital product passport use case. Additionally, search objects as well as procedures to registering / providing and consuming the data will be defined.

1.1 AUDIENCE & SCOPE​

This section is non-normative

This document is meant for the following roles:

  • Data Provider / Consumer
  • Business Application Provider

The standard is of interest to all members of the automotive supply chain including suppliers, OEMs, dismantler, recyclers and stakeholders within the recycling industry and the circular economy.

Additionally, the standards also apply to software providers and core service providers to ensure interoperability and data sovereignty between different core service providers. The scope of this standard is to define mandatory components, logics and data models as well as give guidance for the provisioning and consuming of product pass information.

1.2 CONTEXT​

This section is non-normative

Manufacturer will have to provide information on different aspects of their products. These information will be stored in so-called passports, providing information on instances of the product.

Different stakeholders shall be able to read these passports such as legal authorities, dismantler, as well as the owner of the product in sense of public persons.

This standards defines the basic interactions with passport information as standard for the use case "digital product passport". It is implemented in a first reference application which can be found in section 3.3 REFERENCE IMPLEMENTATION.

1.3 ARCHITECTURE OVERVIEW​

This section is non-normative

This image depicts an overall image of the architecture this standard relates to. Further information can be read in the Eco Pass KIT. The standards related to these components are mentioned in 2.1 LIST OF STANDALONE STANDARDS. Further architecture diagrams for the interactions are presented in FIGURES.

Architectural Overview

1.4 CONFORMANCE​

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD and SHOULD NOT in this document document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.5 PROOF OF CONFORMITY​

This section is non-normative

All participants and their solutions will need to proof, that they are conform with the Catena-X standards. To validate that the standards are applied correctly, Catena-X employs Conformity Assessment Bodies (CABs).

All participants and their solutions will need to proof, that they are conform with the Catena-X standards. To validate that the standards are applied correctly, Catena-X employs Conformity Assessment Bodies (CABs). Please refer to the certification information page for the process of conformity assessment and certification. Since this Triangle document describes a set of standards to be fulfilled, participants MUST fulfill all mentioned standards listed at 2.1 LIST OF STANDALONE STANDARDS and the respective conformity assessment criteria in addition to the specific criteria mentioned in this document. The specific criteria described in this document are describing the usage of the central tools as well as common tools described in the linked standardization documents and therefore compliance should be checked with the tools provided for these components.

In order to proof conformity with this use case digital product pass standard as a data consumer or app provider demonstrate that you

  • can find passport twins
  • can distinguish the passport twin information from other submodels
  • are compliant with the consuming conditions in ADDITIONAL REQUIREMENTS

In order to proof conformity with this use case digital product pass standard as data provider show that you

1.6 EXAMPLES​

This section is non-normative

The following examples can be checked as they offer further explanations and guidance how to stay compliant with the standard:

1.7 TERMINOLOGY​

This section is non-normative

Use case relevant terminologies and explanations can be found in the Eco Pass KIT

The following terms are especially relevant for the understanding of the standard:

  • Asset Administration Shell (AAS): The AAS is the chosen standard in Catena-X to define digital twins of an asset (e.g. a battery or a full vehicle)
  • Business Partner Number (BPN): A BPN is the unique identifier of a partner within Catena-X as standardized in CX-0010 Business Partner Number.

2. STANDARDS FOR "USECASE DIGITAL PRODUCT PASSPORT"​

This section is normative

2.1 LIST OF STANDALONE STANDARDS​

This section is normative

To participate in the digital product passport use case, the following single standards MUST be fulfilled by all participants for which the standard is relevant:

To participate in the digital product passport use case, the following single standards SHOULD be fulfilled by data consumers / applications providers for which the standard is relevant:

IRS Optional

2.2 DATA REQUIRED​

This section is normative

The following data MAY be provided by data provider and are in direct relation to the use case:

2.3 ADDITIONAL REQUIREMENTS​

2.3.1 Onboarding and IAM​

All participant mentioned under 1.1 MUST follow the CX Standards

CX-0006, CX-0013, CX-0014, CX-0015, CX-0016 and CX-0017

2.3.2 Fetching EDC Endpoints​

To find the decentralized registries of related parties in Catena-X, app provider MUST follow the CX-0001 standard.

2.3.3 Searching for Decentralized Digital Twin Registries​

To find decentralized Digital Twin Registries of related parties in Catena-X, app provider MUST follow the CX-0002 Standard.

2.3.4 Registration at the BPN Discovery Service​

To find the Business Partner Number of the related parties in Catena-X, data provider MUST follow the CX-0053 standard. Example can be found in the Digital Twin Kit

In specific, as a data provider you MUST register the manufacturerPartId following the Catena-X standard CX-0002 at the BPN Discovery Service. The BPN is hand-over by the authentication/authorization token. Only the owner of a BPN can link the manufacturerPartId to their BPN.

An example can be found here: Digital Twin Kit - API BPN Discovery

Example

POST /api/administration/connectors/bpnDiscovery
{
  "type": "manufacturerPartId", 
  "key": "12345678910"
}

Response

{
  "type": "manufacturerPartId",
  "key": "12345678910",
  "value": "bpn-123",
  "resourceId": "1ca6f9b5-8e1d-422a-8541-9bb2cf5fe485"
}

As an app provider / data consumer you MUST use the manufacturerPartId to search for related BPN endpoints. An example can be found here: Digital Twin Kit - API BPN Discovery

Example

POST /api/administration/connectors/bpnDiscovery/search
{
  "searchFilter": [
    {
      "type": "manufacturerPartId",
      "keys": [
        "12345678910"
      ]
    }
  ]
}

Response

{
  "bpns": [
    {
      "type": "manufacturerPartId",
      "key": "12345678910",
      "value": "bpn-123",
      "resourceId": "1ca6f9b5-8e1d-422a-8541-9bb2cf5fe485"
    }
  ]
}

2.3.5 Registration of the Digital Twin and the Submodels in the Digital Twin Registry​

A data provider MUST register their AAS of the product with the following values for the idShort:

  • for batteries: Battery_{{PartInstanceId}}
  • for transmissions: Transmission_{{PartInstanceId}}

For other product types the format {{Product Name}}_{{PartInstanceId}} SHOULD be used.

Additionally, the AAS MUST be registered with specificAssetIds: partInstanceId and depending on the current lifecyclePhase of the product with

  • assetLifecyclePhase = AsBuild for product that already have been build or
  • assetLifecyclePhase = AsPlanned for products not yet build.

When describing asPlanned information, ExternalReference has to be set to PUBLIC_READABLE as described in the Digital Twin Registry documentation

Example of a battery in as-planned lifecycle stage:

"idShort": "Battery_{{PartInstanceId}}",
"specificAssetIds": [
  {
    "name": "manufacturerPartId",
    "value": "{{manufacturerPartId}}",
    "externalSubjectId": {
      "type": "ExternalReference",
      "keys": [
        {
          "type": "GlobalReference",
          "value": "BPNL000000000000"
        },
        {
          "type": "GlobalReference",
          "value": "PUBLIC_READABLE"
        }
      ]
    }
  },
  {
    "name": "partInstanceId",
    "value": "{{PartInstanceId}}",
    "externalSubjectId": {
      "type": "ExternalReference",
      "keys": [
        {
          "type": "GlobalReference",
          "value": "{{BPN of partner}}"
        }
      ]
    }
  },
  {
    "key" : "assetLifecyclePhase",
    "value": "AsPlanned"
  }
]

Data provider MUST provide their product passport information in the submodelDescriptors depending on their product with the following information:

Product typeused data modelmandatory idShort
BatteriesBatteryPass (CX-0034)batteryPass
TransmissionsTransmission Pass (CX-0095)transmissionPass
Generic PassportDigital Product Pass (CX-103 Aspect Model Digital Product Passport)digitalProductPass
  • The data provider also MUST provide a API Endpoint following the CX-0002. Data- provider MUST register the related sub-models as shown in the example below.
  • The id added to the subprotocolBody SHOULD be a UUIDv4.
  • The href definition follows CX-0002

Example of a transmission:

"submodelDescriptors":[
  {
    "endpoints": [
      {
        "interface": "SUBMODEL-3.0",
        "protocolInformation": {
          "href": "https://{{edc.data.plane}}/{{path}}/urn:uuid:777a3f0a-6d29-4fcd-81ea-1c27c1b870cc",
          "endpointProtocol": "HTTP",
          "endpointProtocolVersion": [
            "1.1"
          ],
          "subprotocol": "DSP",
          "subprotocolBody": "{{AssetId_of_EDCasset}};dspEndpoint=https://{{edc.control.plane}}",
          "subprotocolBodyEncoding": "plain",
          "securityAttributes": [
            {
              "type": "NONE",
              "key": "NONE",
              "value": "NONE"
            }
          ]
        }
      }
    ],
    "idShort": "transmissionPass",
    "id": "urn:uuid:777a3f0a-6d29-4fcd-81ea-1c27c1b870cc",
    "semanticId": {
      "type": "ExternalReference",
      "keys": [
        {
          "type": "Submodel",
          "value": "urn:bamm:io.catenax.transmission.transmission_pass:1.0.0#TransmissionPass"
        }
      ]
    },
    "description": [
      {
        "language": "en",
        "text": "Transmission Passport Submodel"
      }
    ],
    {
      "endpoints": [
        {
          "interface": "SUBMODEL-3.0",
          "protocolInformation": {
            "href": "https://{{edc.data.plane}}/{{path}}/urn:uuid:777a3f0a-6d29-4fcd-81ea-1c27c1b870cc",
            "endpointProtocol": "HTTP",
            "endpointProtocolVersion": [
              "1.1"
            ],
            "subprotocol": "DSP",
            "subprotocolBody": "{{AssetId_of_EDCasset}};dspEndpoint=https://{{edc.control.plane}}/BPNL000000000000",
            "subprotocolBodyEncoding": "plain",
            "securityAttributes": [
              {
                "type": "NONE",
                "key": "NONE",
                "value": "NONE"
              }
            ]
          }
        }
      ],
      "idShort": "digitalProductPass",
      "id": "urn:uuid:777a3f0a-6d29-4fcd-81ea-1c27c1b870cc",
      "semanticId": {
        "type": "ExternalReference",
        "keys": [
          {
            "type": "Submodel",
            "value": "urn:samm:io.catenax.generic.digital_product_passport:3.0.0#DigitalProductPassport"
          }
        ]
      },
      "description": [
        {
          "language": "en",
          "text": "Digital Product Passport Submodel"
        }
      ]
    }
  }
]

2.3.6 EDC Data Asset Structure​

The general asset structure MUST follow the CX-Standard 0018. Examples are in the official Connector Kit. The following subchapters define the specifics for this standard.

2.3.6.1 EDC Data Asset​

The EDC assets for product passports MUST follow the JSON blow.

{
  "@context": {},
  "@type": "Asset",
  "@id": "{{assetId}}",
  "properties": {
    "name": "{{asset-name}}",
    "description": "{{Description}}",
    "version": "{{Version}}",
    "contenttype": "{{type}}"  
  },
  "dataAddress": {
    "@type": "DataAddress",
    "type": "HttpData",
    "baseUrl": "{{submodel.server.endpoint}}"
  }
}
2.3.6.2 EDC Policy Structure​

A participant mentioned under 1.1 MUST sign the overall Catena-X Terms and Condition as well as the sustainability agreement circular economy framework agreement. This follows the first SSI setup following the IAM Standards CX-0049, CX-0050, and CX-0051 in Catena-X covering the new SSI infrastructure. Have a look at example policies here.

The minimum set of membership and the circular economy frameworkagreement MUST to be added to the asset:


{
  "@context": {
    "odrl": "http://www.w3.org/ns/odrl/2/leftOperand"
  },
  "@type": "PolicyDefinitionRequestDto",
  "@id": "{{PolicyId}}",
  "policy": {
    "@type": "Policy",
    "odrl:permission" : [
      {
        "odrl:action":"USE",
        "odrl:constraint": {
          "@type": "LogicalConstraint",
          "odrl:and": [
            {
              "@type": "Constraint",
              "odrl:leftOperand": "Membership",
              "odrl:operator": {
                "@id": "odrl:eq"
              },
              "odrl:rightOperand": "active"
            },
            {
              "@type": "Constraint",
              "odrl:leftOperand": "FrameworkAgreement.sustainability",
              "odrl:operator": {
                "@id": "odrl:eq"
              },
              "odrl:rightOperand": "active"
            }
          ]
        }
      }
    ]
  }
}
2.3.6.3 Contract Definition​

Contract definitions of data providers MUST follow this structure (also defined in CX-0018):

"@context": {},
"@id": "{{ContractDefinitionId}}",
"@type": "ContractDefinition",
"accessPolicyId": "{{AccessPolicyId}}",
"contractPolicyId": "{{ContractPolicyId}}",
"assetsSelector" : {
  "@type" : "CriterionDto",
  "operandLeft": "https://w3id.org/edc/v0.0.1/ns/id",
  "operator": "=",
  "operandRight": "{{AssetId}}"
}

3 REFERENCES​

3.1 NORMATIVE REFERENCES​

See chapter 2.1.

3.2 NON-NORMATIVE REFERENCES​

This section is non-normative

No further references.

3.3 REFERENCE IMPLEMENTATIONS​

This section is non-normative

The code found at https://github.com/eclipse-tractusx/digital-product-pass presents a reference implementation that implements this standard.

ANNEX​

FIGURES​

This section is non-normative

Copyright © 2024 Catena-X Automotive Network e.V. All rights reserved. For more information, please visit here.