Skip to main content
Version: 24.05

Architecture View

Industry Core kit banner

The following page offers an architecture perspective including the main building blocks and information regarding communication between different components, shown as sequence diagrams in a runtime view. In general, data access must be provided in the Catena-X network using the Data Space Protocol (DSP). As standard for data-level interoperability, the Asset Administration Shell (AAS) standard is used - this is relevant for registering data via the Digital Twin Registry (short DTR), as well as for delivery of said data. SAMM is used as modelling language to model a Digital Twin's aspects, yielding json-schema that defines the payloads and context for runtime data.

Assumptions​

This architecture is based on the following assumptions:

  • There is a complete setup of the Catena-X Dataspace available with all Core Services as defined by the Operating Model Whitepaper v2.1.
  • All users have completed onboarding to the Catena-X network. This includes:
    • All participants hold a Verifiable Credential issued by an Operating Company (Core Service Provider B)
    • All participants have at least one Dataspace Connector deployed that's linked to their BPNL at the EDC Discovery Service.
    • All participants have an active network membership that is represented in their membership credential.
    • Data Providers operate a Digital Twin Registry according to the Digital Twin Kit
    • Data Providers expose their data via the Submodel API according to the Digital Twin Kit.
  • The customers of parts (on catalog and instance level) must be known when creating a digital twin and registering its data. Registering data in EDC and DTR requires data providers to define appropriate access permissions to prevent exposing data to unauthorized parties. For Traceability, the customer of a part must have access to the digital twin in the DTR as well as to the digital twin's data in the EDC. If the customer is not known when a digital twin is created, additional processes must be set up by the data provider to add access permissions for the customer at a later time.

Non-Functional Requirements​

Lawfulness​

Automotive supply chains hold sensitive data. Not only can improper exposure lead to the loss of trade-secrets but it can also violate antitrust regulations - especially when gaining access to sensitive data of horizontal competitors. As this can jeopardize the business of a company, especially Data Providers (and by proxy Business Application Providers) must ensure that their solutions are not only secure by default but also provide ergonomic and reliable means for configuration.

Correctness​

Data Chains are built up of the links to resources distributed among the supply chain. This is reflected in distributed data. Publishing incorrect or outdated data to the network will have ripple-on effects that may break the chain for all interested parties. To avoid this, implementation strictly according to standard, verified by rigorous certification, is critical for the success of the Industry Core and the network as a whole.

Resilience​

While processing data for publishing it to Catena-X, a data provider needs to access the digital twins of built-in parts from suppliers. These must be available in Catena-X at this point. If these digital twins are not found while the data provider is looking them up, the data provider will not be able to integrate these built-in parts into BoM aspect models (e.g., SingleLevelBomAsBuilt) as it is missing the built-in parts' Unique ID. Reasons for not finding a built-in part's digital twin can be:

  1. There is a network failure while the data provider's is looking for the digital twin.
  2. The supplier did not yet create the digital twin, e.g., because its internal processes were delayed
  3. The supplier is not yet part of the Catena-X network.

Resilience means that the data provider implements a pipeline that can cope with these issues. Digital twins are provided with the information that is available and are updated once more information is available (e.g., the supplier provides digital twins for built-in parts later on).

Backward Compatibility and Versioning​

Effective management of versions and changes for Catena-X standards, KITs, and open source reference implementations is crucial to guarantee compatibility, interoperability and security especially in a decentralized data space. The Catena-X lifecycle management coordinates quarterly releases, including one major release and three minor releases per year. Only a major release may contain breaking changes and does not need to be backward compatible.

The Catena-X data space aims to support a parallel phase of two major versions of 12 months to ensure a smooth upgrade process. Data providers and data consumers must take special care to prepare for such releases by planing necessary migrations in time. This means that, e.g., a Traceability app that was built for the previous (major) Catena-X release will still work in an environment that is running the new major release.

  • For digital twins and aspect models, this means that data providers and data consumers must at least support mandatory aspect model versions from the oldest, still supported major release. Newer mandatory aspect model versions can be optionally supported. A data provider cannot assume that all data consumers are already able to process newer aspect model versions. A data consumer cannot assume that all data providers already provide their data in newer aspect model versions.

    Mandatory versions for aspect models can only change in a major release as this change is breaking. Optional versions can be introduced with minor and patch versions, e.g., to introduce a future mandatory version first as optional for easier migration later on.

    A data provider that wants to support several versions of an aspect models must add a separate submodelDescriptor for every supported aspect model version to the digital twin. The submodelDescriptors will have different semanticIds and might also point to different EDC assets - depending on the asset structure used in the EDC for providing the digital twin's sumodel.

    A data consumer must search the submodelDescriptors of a digital twin for supported semanticIds and then select the most suitable one for further processing.

  • For Notification APIs, a separate EDC asset must be created for every major API version, e.g., for versions v1 and v2 of the API separate EDC assets must be created. The API version must be documented in the https://w3id.org/catenax/ontology/common#version property on a minor release level (e.g., 1.1). It is not necessary to create a separate EDC asset for every minor or patch version as these versions must always be backward compatible.

More information about backward compatibility and versioning can be found here:

Building Block View​

Building Block View of the Industry Core

Runtime View​

The runtime patterns represent a subset of the interactions specified in the Digital Twin Kit. Its "Interaction Patterns" section describes the interaction between a Data Provider and Data Consumer including the necessary configuration steps. Since the Discovery Services according to CX-0053 are not part of the Industry Core, all calls going to the components DiscoveryFinder and BPN Discovery Service can be omitted.

Future Concepts​

Reduction of Number of Digital Twins in the DTR​

With the current Industry Core concept, a digital twin must be created for every instantiated part that can be identified, e.g., with a serial number, no matter how small it is. This might result in a huge number of digital twins created in the DTR (more then several hundred million) as parts are produced on a daily basis.

Therefore, we developed a concept to reduce the number of digital twins by building upon the PartType digital twin of such instantiated part. The processing of data is mostly the same as when data is provided conventially, i.e., with a digital twin for every instantiated part.

  • The basic idea is to use a PartType digital twin to access data about instances of a part type. It is not necessary to create digital twins for instances.
  • For this PartType:
    • For every aspect that should be provided for instantiated parts (e.g., SerialPart, SingleLevelBomAsBuilt), a submodelDescriptor for this aspect must be added to the part type digital twin. As there are no aspect models currently that are used for both, part types and part instances, this does not create any ambiguities.
    • To get the actual submodel data for a digital twin, an operation must be provided by the data provider that is called via InvokeOperationSync or InvokeOperationAsync (see the AAS standard for more details). At least the ID of the instantiated part (e.g., partInstanceId or batchId) must be specified as an input argument of this operation. Note that details about the operation including, e..g, input arguments, still need to be standardized to provide a interoperable solution.
    • The backend data service must handle authorization for instantiated parts based on the BPN of data consumer (similar to asset bundling authorization requirements), if necessary.
    • The result of this operation must be compliant to the asepct model represented by the submodel descriptor.

With this approach, subsequent processing of the submodel data can then proceed as if a digital twin for the instantiated part was provided.

Standards​

A formal definition of the Industry Core's content is given in the standards CX-0126 and CX-0127 - first released in CX R24-03. These two standards build on a common subset of technologies that are themselves described in Catena-X standards.

The two standards share a common set of base technologies. And while the Industry Core does provide Business-relevant capabilities for Data Consumers, it can likewise serve as a launchpad for new use-cases.

Locating the Industry Core standards in the Catena-X landscape

The Interoperability Layer the Industry Core Standards build on, defines API structures of Data Providers and relevant core services hosted centrally. They depend on the EDC Discovery Service defined in standard CX-0001 to discover a participant's the EDC-endpoint. CX-0002 is the standard for the integration between assets and related data - leveraging the Asset Administration Shell standard as adopted by Catena-X. Its correct deployment is especially critical as its services (Digital Twin Registry and Submodel Endpoints) are operated by all Data Providers.

The Identity and Sovereignty Layers are defined in a variety of Catena-X standards that are assumed to be deployed and integrated form the foundation for data exchange in Catena-X.

All relevant standards can be downloaded from the official Catena-X Standard Library:

Sidenote: The following existing standards are incorporated into new standards. Please only refer to CX-0126 and CX-0127.

  • CX - 0126 Industry Core Part Type 1.0.0 is the new standard based on the following existing standards:
    • CX - 0042 Aspect Model SingleLevelBomAsPlanned
    • CX - 0043 Aspect Model PartAsPlanned
    • CX - 0094 Aspect Model PartSiteInformationAsPlanned
    • CX - 0061 Triangle Traceability Data Provisioning BomAsPlanned
  • CX - 0127 Industry Core Part Instance 1.0.0 is the new standard based on the following existing standards:
    • CX - 0019 Aspect Model SerialPart
    • CX - 0020 Aspect Model SingleLevelBomAsBuilt
    • CX - 0021 Aspect Model Batch
    • CX - 0060 Triangle Traceability - Digital Twin As-Built

NOTICE​

This work is licensed under the CC-BY-4.0.

  • SPDX-License-Identifier: CC-BY-4.0
  • SPDX-FileCopyrightText: 2023 BASF SE
  • SPDX-FileCopyrightText: 2023 Bayerische Motoren Werke Aktiengesellschaft (BMW AG)
  • SPDX-FileCopyrightText: 2023 Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V. (represented by Fraunhofer ISST & Fraunhofer IML)
  • SPDX-FileCopyrightText: 2023 German Edge Cloud GmbH & Co. KG
  • SPDX-FileCopyrightText: 2023 Mercedes Benz AG
  • SPDX-FileCopyrightText: 2023 Robert Bosch Manufacturing Solutions GmbH
  • SPDX-FileCopyrightText: 2023 SAP SE
  • SPDX-FileCopyrightText: 2023 Siemens AG
  • SPDX-FileCopyrightText: 2023 T-Systems International GmbH
  • SPDX-FileCopyrightText: 2023 ZF Friedrichshafen AG
  • SPDX-FileCopyrightText: 2023 Contributors to the Eclipse Foundation
  • Source URL: https://github.com/eclipse-tractusx/eclipse-tractusx.github.io/tree/main/docs-kits/kits/Industry%20Core%20Kit (latest version)