CX-0154 Digital Master Data v.1.0.1

ABSTRACT

The standard "Digital Master Data" shall enable a standardized, interoperable and secure exchange of structured master data across the automotive value chain to improve data consistency, traceability and collaboration.

FOR WHOM IS THE STANDARD DESIGNED

The standard is intended for data provider/consumer and Business Application Provider that want to provide and access Digital Master Data on which assets will be created.

1 INTRODUCTION

The project aims to reduce data inconsistencies and manual effort in the supply chain by enabling structured exchange of 2D/3D and digital master data. It enhances efficiency in PDM and CAD systems through harmonized master data shared between OEMs and suppliers.

On a broader scale, the initiative supports the digitalization of the automotive industry by establishing standardized data exchange infrastructure. It fosters collaboration and transparency among supply chain partners, reduces operational risks, and leads to significant time and cost savings by eliminating manual processes. Additionally, it helps meet regulatory requirements and enables the development of new digital services based on real-time, accurate data.

1.1 AUDIENCE & SCOPE

This section is non-normative

This standard is relevant for the following audience:

• Data Provider / Consumer
• Business Application Provider

This document focuses on Digital Master Data which is exchanged before the actual physiscal asset is created.

Out-of-scope is:

• The exchange of instance specific information (see CX-0127 Industry Core PartInstance)
• information that is already relevant in an existing supplier OEM-relationship (see CX-0126 Industry Core: PartType)

1.2 CONTEXT AND ARCHITECTURE FIT

During the development of components, there is a continuous exchange of data between supplier and OEM. The exchanged information includes requirements, properties of components and materials, test results, as well as 2D and 3D models. The exchange of this data is not standardized yet and usually requires data transformations among the involved partners.

This initial version of the standard defines the basic data model that enables digital exchange of part master data between between partners.

To provide a general framework, the components, interactions, APIs, and data models involved in this use case are presented in this chapter.

Components

• Master Data System: Abstraction for systems provding master data. Depending on the implemention this could be a PDM system, a database or a standalone application
• Digital Twin Registry: Stores and manages digital twin information
• Submodel Service: Handles submodel data and operations
• Eclipse Dataspace Connector (EDC): Reference implementation of a connector fulfilling the Dataspace Protocol (DSP) for data exchange between partners

Interactions

The system architecture demonstrates how components interact to facilitate master data exchange:

• Master Data System
  • Registers Digital Twins and Submodel Descriptors in the Digital Twin Registry
  • Provides Master Data Submodels to the Submodel Service
  • Uses the Eclipse Dataspace Connector to request digital master data and send notifications
• Eclipse Dataspace Connector (EDC)
  • Handles notifications sent from partners back to the Master Data System
  • Acts as the communication bridge between partners
• Digital Twin Registry
  • Provides Digital Twins to the Eclipse Dataspace Connector
• Submodel Service
  • Provides Submodels to the Eclipse Dataspace Connector

The following diagram illustrates the interactions between the named components.

Note: As part of the part master data information regarding 2D and 3D models are exchanged to enable retrieval of these models from the respective source systems. The concrete transfer of 2D and 3D data is not part of this specification but is listed for completeness and differentiation (visible as a dashed list in the diagram).

APIs

The data exchange is based on existing Catena-X standards. For more details refer to chapter 4.

• Digital master data is provided in defined aspect models that are attached to a Digital Twin.
• Sending and receiving of notifications in case of updated master data.

1.3 CONFORMANCE AND PROOF OF CONFORMITY

This section is non-normative

Sections marked as non-normative as well as 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 are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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

To prove conformance with the standard a participant (consumer, provider or application developer) MUST show that they can

• provide a digital master data twin and its associated submodels to other participants
• consume a digital master data twin and its associated submodels from another participant
• publish notifications in case a digital master data twin or its associated submodels are created, updated or deleted
• receive notifications in case a digital master data twin or its associated submodels are altered by another participant

1.4 Examples

JSON Payload Digital Master Data exchange

{
   "digitalMasterDataId":"urn:uuid:48878d48-6f1d-47f5-8ded-a441d0d879df",
   "basicdata":{
      "category":"Exterior",
      "description":"Injection-molded front bumper with integrated sensor mounts",
      "nomenclature":"Head Unit",
      "notes":[
         {
            "timestamp":"2025-06-17",
            "noteProperty":"Updated hole diameter from 10mm to 12mm"
         }
      ],
      "partNumber":"145SGG01.1",
      "releaseDate":"2025-03-15",
      "status":"Approved",
      "successorPart":"urn:samm:io.catenax.masterdatamanagement:a2f115cd-b9dd-4c5d-94c1-52fdf5b99a88",
      "supersededVersion":"V3.0",
      "supplier":"BPNL6666666666YY",
      "validFrom":"2024-03-15",
      "validTo":"2025-01-10",
      "version":"v3.2.1"
   },
   "engineering":{
      "electronicsData":{
         "diagnosticsAndErrorCodes":"P0420 - Catalyst System Efficiency Below Threshold",
         "flashingMethod":"UDS Flash via DoIP"
      },
      "mechanicsData":{
         "geometryData":{
            "representations":[
               {
                  "id":"Master Drawing",
                  "type":"2D_DRAWING",
                  "submodelSemanticId":"urn:samm:io.catenax.3dm:a2f115cd-b9dd-4c5d-94c1-52fdf5b99a88"
               },
               {
                  "id":"CAD MODEL",
                  "type":"3D_MODEL",
                  "submodelSemanticId":"urn:samm:io.catenax.3dm:a2f115cd-b9dd-4c5d-94c1-52fdf5b99b56"
               }
            ],
            "boundingBox":{
               "length":120.0,
               "width":45.0,
               "height":30.0,
               "unit":"mm"
            },
            "boundingSphere":{
               "value":315.0,
               "unit":"mm"
            },
            "calculatedWeight":{
               "value":2.35,
               "unit":"kg"
            },
            "calculatedWeightTolerance":"±0.5 kg or ±2%",
            "centerOfGravity":"(150.2, 75.6, 20.1) mm",
            "estimatedWeight":{
               "value":2.35,
               "unit":"kg"
            },
            "estimatedWeightTolerance":"±0.5 kg or ±2%",
            "momentOfInertia":{
               "value":0.045,
               "unit":"kg·m²"
            },
            "surfaceArea":{
               "value":200,
               "unit":"mm2"
            },
            "volume":{
               "value":400,
               "unit":"mm3"
            },
            "weightedWeight":{
               "value":2.35,
               "unit":"kg"
            },
            "weightedWeightTolerance":"±0.5 kg or ±2%"
         },
         "materialData":{
            "density":{
               "value":7850,
               "unit":"kg/m³"
            },
            "materialDescription":"Aluminum Alloy 6061-T6",
            "materialID":{
               "type":"IMDS",
               "id":"123456789"
            },
            "thermalExpansionCoefficient":"2.3 × 10⁻⁶ 1/K"
         }
      },
      "requirementInformation":"urn:samm:io.catenax.requirement:a2f115cd-b9dd-4c5d-94c1-52fdf5b99a88",
      "softwareData":{
         "securityAndEncryptionStandards":[
            "AES-256",
            "TLS 1.2",
            "Secure Boot"
         ],
         "signatureSign":"SH",
         "softwareVersion":"v3.2.1"
      }
   },
   "complianceData":{
      "homologationApprovalNumber":"E1 2007/46*1234*01",
      "safetyRelevant":true,
      "safetyRelevantFeatures":[
         "X"
      ],
      "statutoryFeature":[
         "REACH",
         "RoHS",
         "ISO 26262",
         "DBL 5307.10"
      ]
   }
}

JSON Payload Notifications

This event payload is based on the Catena-X Digital Twin Event Notification API Specification.

{
  "header": {
    "messageId": "urn:uuid:51BBbF0d-3784-1FBb-67Cf-fd3e5aeFa06b",
    "context": "IndustryCore-DigitalTwinEvent-<Operation>:3.0.0",
    "sentDateTime": "2007-08-31T16:47+00:00",
    "senderBpn": "BPNLNAH3KGbV0Ar6",
    "receiverBpn": "BPNLncBRFjdLU19t",
    "expectedResponseBy": "2007-08-31T16:47+00:00",
    "relatedMessageId": "b8eDBc8f-Ac4e-aFc6-2A1f-Cb61c5ea1fa7",
    "version": "3.0.0"
  },
  "content": {
    "listOfEvents": [
      {
        "eventType": "UpdateSubmodel",
        "catenaXId": "urn:uuid:d32d3b55-d222-41e9-8d19-554af53124dd",
        "submodelSemanticId": "urn:samm:io.catenax.masterdatamanagement:1.0.0#"
      }
    ]
  }
}

1.5 TERMINOLOGY

Business Partner Number (BPN): A BPN is the unique identifier of a partner within Catena-X.

Notification: In Catena-X, notifications are JSON messages with a standardized data format consisting of a standardized header and a use-case-specific content.

2 RELEVANT PARTS OF THE STANDARD FOR SPECIFIC USE CASES

This section is normative

2.1 "Digital Master Data"

2.1.1 DIGITAL TWINS AND SPECIFIC ASSET IDs

The Digital Twin MUST be described as a PartRole.

Specific asset IDs are used to identify digital twins when looking up or searching for these digital twins. This is a required to connect the digital twins of the engineered parts to its digital twins. Mandatory specific asset IDs ensure that at least this information is available for the digital twin.

Key	Availability	Description	Type
manufacturerId	mandatory	The Business Partner Number (BPNL) of the manufacturer of the part.	BPNL
digitalTwinType	mandatory	The digitalTwinType has to be set to digitalTwinType="PartRole". Without this filter, a search for a particular manufacturer part ID would not only return the digital twin of the engineered part, but also all digital twins of the manufacturer that are accessible, i.e., of the corresponding serial parts and catalog parts.	String

2.2 POLICY CONSTRAINTS FOR DATA EXCHANGE

In alignment with our commitment to data sovereignty, a specific framework governing the utilization of data within the Catena-X use cases has been outlined. As part of this data sovereignty framework, conventions for access policies, for usage policies and for the constraints contained in the policies have been specified in standard 'CX-0152 Policy Constraints for Data Exchange'. This standard document CX-0152 MUST be followed when providing services or apps for data sharing/consuming and when sharing or consuming data in the Catena-X ecosystem. What conventions are relevant for what roles named in 1.1 AUDIENCE & SCOPE is specified in the CX-0152 standard document as well. CX-0152 can be found in the standard library.

The following usage purpose MUST be registered for data exchange in the use case:

Type	Subject	Description	Version	Usage Purpose
cx-taxo:Engineering	cx-taxo:ReadAccessEngineering	Data consumer are allowed to use the data for • Collaborative engineering of products (e.g., 3D Designs, Simulations) • regulatory compliance use cases (e.g., material information in master data for secondar material content checks) • Mock-Up and integration (e.g., collision checks in 3D) • versioning & release notifications of products (e.g., new product version that shall be used in a new product generation) • interface alignments (e.g., between interacting systems on physical, logical and functional level) They explicitly MUST not use the data for reverse engineering, e.g., by using material classifications for building the product themselves.	1	cx.enginnering:1

3 ASPECT MODELS

This section is normative

3.1 ASPECT MODEL "Digital Master Data"

This semantic model, developed for the Catena-X data space, defines a standardized structure for exchanging master data on which products are engineered.

3.1.1 Identifier OF SEMANTIC MODEL

The semantic model has the unique identifier:

  urn:samm:io.catenax.masterdatamanagement:1.0.0#

Note:

• You can find the corresponding Turtle file here
• You can find the corresponding files (Documentation, JSON Schema or AASX File, etc.) here.

3.1.2 Normative Criteria

This model MUST be used for providing and consuming masterdata.

3.2 ASPECT MODEL "MessageHeaderAspect"

The Catena-X Message Header containing standardized attributes for message processing across several use cases. This aspect is defined in standard CX-0151 Industry Core: Basics. The aspect MessageHeaderAspect is used for sending notifications to Catena-X Partners.

3.2.1 IDENTIFIER OF SEMANTIC MODEL

  urn:samm:io.catenax.shared.message_header:3.0.0#MessageHeaderAspect

Note:

• You can find the corresponding Turtle file here
• You can find the corresponding files (Documentation, JSON Schema or AASX File, etc.) here.

3.2.2 Normative Criteria

This model MUST be applied for the usage of the API.

4 APPLICATION PROGRAMMING INTERFACES

This section is normative

4.1 APIs ASSOCIATED WITH DIGITAL TWINS

This standard completely and solely builds upon the standard CX-0002 Digital Twins in Catena-X.

DATA ASSET STRUCTURE

The Data Assets need to be registered in the EDC as follows:

Note: Expressions in double curly braces {{}} must be substituted with a corresponding value.

{
   "@context": {
      "dct": "http://purl.org/dc/terms/",
      "cx-taxo": "https://w3id.org/catenax/taxonomy#",
      "cx-common": "https://w3id.org/catenax/ontology/common#"
   },
   "@type": "Asset", 
   "@id": "{{CONNECTOR_ASSET_ID}}",
   "properties": {
      "dct:type": {"@id": "cx-taxo:Engineering"},
      "cx-common:version": "1.0",
      "aas-semantics:semanticId": {"@id":  "urn:samm: io.catenax.digital_engineering_master_data:1.0.0#DigitalEngineeringMasterData"}   
   },
   "dataAddress": {
      "@type": "DataAddress",
      "type": "HttpData",
      "baseUrl": "{{ SUBMODEL_ENDPOINT }}",
      "proxyQueryParams": "false",
      "proxyBody": "false",
      "proxyPath": "true",
      "proxyMethod": "false",
   }
}

The data asset MUST contain the following properties with the corresponding values from the table above:

• dct:type for type (as @id reference), see also CX-0018
• cx-common:version for version, see also CX-0018

4.2 NOTIFICATIONS

This standard completely and solely builds upon the standard CX-0151 Industry Core: Basics.

5 PROCESSES

This section is normative

5.1 DIGITAL MASTER DATA EXCHANGE

Part master data is requested by one Catena-X partner - called consumer - from another Catena-X partner - called provider - using simple messages in JSON format via Catena-X connector (EDC), as shown in the following figure:

The provider provides an asset in the EDC to retrieve digital twins and the respective submodels. The consumer initiates a contract negotiation for this asset to get a contract agreement. After a successful contract negotiation, the consumer requests a digital twin and respective submodels of the part master data via the provider's EDC dataplane endpoint.

5.1.1 ACTORS AND ROLES

• Catena-X Partner: A company participating in the Catena-X network. A partner can act as both, a master data consumer and master data provider.
• Master data consumer: The partner that retrieves part master data from another partner.
• Master data provider: The partner that provides part master data to one or more partners.

5.2 NOTIFICATION PROCESS

A notification is sent from one Catena-X partner - called sender - to another Catena-X partner - called receiver - using simple messages in JSON format via Catena-X connector (EDC), as shown in the following figure:

The receiver provides an asset in the EDC to which notifications can be sent. The sender initiates a contract negotiation for this asset to get a contract agreement. After a successful contract negotiation, the sender sends the notification to the receiver via the dataplane endpoint. All notification operations are sent via the same asset using the same contract agreement.

5.2.1 ACTORS AND ROLES

• Catena-X Partner: A company participating in the Catena-X network. A partner can act as both, a notification sender or notification receiver.
• Notification Sender: The sender of a Catena-X notification.
• Notification Receiver: The receiver of a Catena-X notification. The receiver provides an asset in the connector to which notifications can be sent.

6 REFERENCES

6.1 NORMATIVE REFERENCES

This section is normative

• CX-0001 EDC Discovery API v1.1
• CX-0002 Digital Twins in Catena-X v2.2.0
• CX-0003 SAMM Aspect Meta Model v1.2.0
• CX-0010 Business Partner Number v3.0.0
• CX-0018 Dataspace Connectivity v4.0.0
• CX-0151 Industry Core: Basics v.1.0.0
• CX-0152 Policy Constraints for Data Exchange v1.0.0

6.2 NON-NORMATIVE REFERENCES

This section is non-normative

• ISO 10303-242:2022
• ISO 14306:2017
• RFC 2077
• VDA 231
• prostep ivip Digital Data Package (DDP) Recommendation

6.3 REFERENCE IMPLEMENTATIONS

This section is non-normative

This section is empty.

6.4 LICENSES

This section is non-normative

The in Section 3 referenced Aspect Models are available under the terms of the Creative Commons Attribution 4.0 International (CC-BY-4.0) license, which is available at Creative Commons.

Legal

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