Skip to main content
Version: Next

Development View

lab

Development View​

eSDScom is a data model, not a software. No API other than the digital twin registry APIs. This document provides a developer-focused overview of the eSDScom KIT, including a technical breakdown of the architecture, and data exchange protocols and semantic models.

Target Audience​

Software Developers, Solution Architects, Technical Leads, API Developers, Integration Engineers.

Focus​

Technical implementation, APIs, and development resources

Required contents in the following sub-chapters:

Architecture Overview​

This section is non-normative.

The architecture of this KIT is based on Catena-X standards.

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

  • CX-0002 Digital Twins in Catena-X
  • CX–0018 Sovereign Data Exchange

To participate in the eSDScom use case, the following single standard MUST be fulfilled only by data providers:

  • CX-0162 eSDScom In the Catena-X technical landscape, the standard assumes the use of CX-0126-IndustryCorePartType. The architecture follows a pull-based pattern: data is pushed from supplier to consumer (or other way around) but made accessible by the data provider. This standard applies equally to Data Providers and Consumers. All parties involved in the exchange must implement the agreed data structure and access patterns to ensure interoperability within the Catena-X network.
  1. All Data Exchange Requirements follows the CX-0018 Dataspace Connectivity [https://catenax-ev.github.io/docs/standards/CX-0018-DataspaceConnectivity] and which lays out the principles for both, data providers and data consumers. More information can be found in the Connector KIT.
  2. Both, the data providers and consumers shall be identified in the Catena-X dataspace following the CX-0010 Business Partner Number Standard [https://catenax-ev.github.io/docs/standards/CX-0010-BusinessPartnerNumber] so that a clear identification of both parties enables automatic data exchange. The Onboarding of the parties on the Catena-X Dataspace shall be effectuated following the CX-0006 Registration and initial Onboarding standard [https://catenax-ev.github.io/docs/standards/CX-0006-RegistrationAndInitialOnboarding].
  3. The data provider party must have a digital twin registry which comply with the CX-0002 standard, detailed in the Digital Twin KIT. In this way the eSDScom data model can be provided in a AAS Shell Descriptor as a Submodel, more information can be found in the architecture diagram below. The eSDScom standard defines a structured data model that enables the exchange of SDS between suppliers and OEMs in the automotive industry. It is designed to reduce the current manual effort involved in gathering and processing data needed for occupational workplace and environmental safety, which today is commonly exchanged via e-Mail and PDF files. This standard is not embedded in a broader Catena-X use case or initiative but operates as a standalone specification that supports the bilateral exchange of information. It is applicable whenever a company needs to obtain SDS data.

System Architecture [High-level architecture diagram and explanation] Architecture Principles:

  • Modularity: Loosely coupled components
  • Scalability: Horizontal scaling support
  • Security: End-to-end encryption
  • Interoperability: Standards-based APIs
  • Observability: Built-in monitoring and logging

The architecture of this KIT is based on Catena-X standards. First all Data Exchange Requirements follows the CX-0018 Dataspace Connectivity [https://catenax-ev.github.io/docs/standards/CX-0018-DataspaceConnectivity] and which lays out the principles for both, data providers and data consumers.

Second, both, the data providers and consumers shall be identified in the Catena-X dataspace following the CX-0010 Business Partner Number Standard [https://catenax-ev.github.io/docs/standards/CX-0010-BusinessPartnerNumber] so that a clear identification of both parties enables automatic data exchange. The Onboarding of the parties on the Catena-X Dataspace shall be effectuated following the CX-0006 Registration and initial Onboarding standard [https://catenax-ev.github.io/docs/standards/CX-0006-RegistrationAndInitialOnboarding].

Figure 1 shows the high-level architecture of the notification exchange in the Catena-X dataspace and the services that are involved. Both the notification sender and the notification recipient must be members of the Catena-X network in order to communicate with each other. With the help of the Identity Access Management (IAM) each participant can authenticate itself, verify the identity of the requesting party and decide whether to authorize the request.

eSDScom Use Case Architecture

The architecture is designed for a decentralized data exchange within the Catena-X network, leveraging core services and standardized components. Figure 1 shows how two companies, a Data Consumer (the importer requesting eSDScom data) and a Data Provider (the supplier providing it), exchange eSDScom data securely over the Catena-X network without connecting to each other's internal systems directly. Each company operates the same two-component setup. The first is a eSDScom App, the business application where the importer composes requests and where the supplier prepares and calculates the eSDScom response data. The eSDScom app is a third-party business application required to manage and exchange eSDScom-relevant data that is compatible with Catena-X. The second is an EDC (Eclipse Dataspace Connector), a standardized secure gateway which manages who is allowed to connect and under what agreed conditions, and which is the actual channel through which the notification data travels.

There are two use cases for eSDScom data exchange:

Use case 1: The provider (supplier) is sending an SDS Use case 2: The consumer (customer, client or recipient) is requesting an SDS

Before any data moves, both connectors perform an authorization handshake to confirm the identities of both parties and verify that the data sharing conditions are met. Once authorized, the notification is sent to the provider or consumer (depending on the above use cases) eSDScom App. It prepares the response, and sends it back in the opposite direction. The connectors act as trusted, policy-enforced gateways on both sides, ensuring that data is only shared with verified partners and under agreed terms. Each notification consists of a header and a body.

The header contains the routing and identification information:

  • the BPNL (Business Partner Number Legal) of both the sending and receiving company
  • a unique message ID assigned to each individual message, and a related message ID that references the original request. The related message ID is particularly important when a supplier sends multiple separate responses to a single request, for example when emission data for different operators or goods is compiled and returned in stages. Each response can be matched back to the originating request via this identifier.

The following data fields in the eSDScom data model allow an unique assignment of the documents:

  • Supplier DUNS number
  • Formulation (specification) number
  • Version number of the SDS (current and previous)
  • Date of compilation
  • Supplier product name
  • Country (legal area)
  • Language

Data Schema​

Semantic Models​

Model: eSDScom Version: 1.0.0 SemanticId: urn:samm:io.catenax.esdscom:1.0.0#eSDScom

Model TypeLink
urn:samm:io.catenax.esdscom:1.0.0#eSDScom (.ttl)https://github.com/eclipse-tractusx/sldt-semantic-models/blob/main/io.catenax.esdscom/1.0.0/eSDScom.ttl
JSON Payloadhttps://github.com/eclipse-tractusx/sldt-semantic-models/blob/main/io.catenax.esdscom/1.0.0/gen/eSDScom.json
JSON Schemahttps://github.com/eclipse-tractusx/sldt-semantic-models/blob/main/io.catenax.esdscom/1.0.0/gen/eSDScom-schema.json

The following diagram shows the digital twin structure used to represent eSDScom data in the Catena-X dataspace.

eSDScom Digital Twin Structure

Sample data in multiple formats (JSON, XML, CSV)​

eSDScom is not bound to the JSON format provided in Catena-X's eSDScom KIT.

  • An implementation of the eSDScom data model as an XML Schema Definition (XSD) can be found at eSDScom's Github pages
  • Besides the data model, eSDScom delivers a curated library of Standard Phrases, i.e. expert approved wordings for all supported regulatory purposes. See the eSDScom Phrase Browser and Proposal Tool to read and contribute.
  • For general information on this project, go to the eSDScom Web Pages

History​

eSDScom traces back to the 1990s and is the industry standard for sending safety data sheets, exposure scenarios and relevant compliance information in the global chemical supply chain. It is a comprehensive and efficient solution saving money and time. It’s a package, covering the following developments and regulations for chemicals:

  • Safety Data Sheets to assist with occupational safety and health
  • Notification data to help customers with their legal obligations
  • for Europe: Exposure Scenarios and ENES achievements for downstream users

The eSDScom project acts as a think tank for software companies, content and service providers and chemical companies in the field of hazardous chemicals / dangerous goods management and maintains contacts to other associations and authorities. eSDScom is established also within companies for systems integration. Many associations, i.a. the European Automotive industry (ACEA) as well as the European chemical industry (CEFIC) supports the digital data exchange via eSDScom. For more information:

For general project information, please go to esdscom.eu.

It integrates two types of deliverables:

Standard phrases​

With roots in a single company phrase catalogue, The Federation of German Industries (BDI) formed the BDI Standard Phrase Catalogue which later became EuPhraC (European Phrases Catalogue).

Data Model and Exchange Format​

With roots in EDAS and its XML flavour EDASx, the project decided to redefine the exchange format when the European chemicals law was redefining the requirements in today's form (REACH and CLP). When Cefic started the ESCom project (Exposure Scenario Communication), the new format SDScomXML was defined. Its version 5 allowed to cover information on all relevant legislative regions in one XML document (instead of focusing of one SDS document per XML document) to facilitate systems integration. Later, ESCom and SDScom were joined to eSDScom.

NOTICE​

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