Skip to main content
Version: Next

Development View

Architecture Overview​

State of the Art​

Maintenance in a semiconductor factory is not uncommon. Due to the long process run times and the highly complex processes themselves, machines operate 24/7. A system failure can cause extreme delays in run times and result in a high rate of scrap.
All information within the semiconductor system is classified as business-critical and therefore may not leave the company without authorization. This requires prior approval. This also applies to maintenance logs. These may contain process-critical information, particularly when they include machine data. Therefore, the exchange of maintenance logs is a critical process. However, the log is also important for the service provider, as it serves as the basis for their cost billing.

Currently, this process is carried out manually. A maintenance employee documents their work on paper during or after maintenance. Machine parameters may only be read and evaluated on-site and must not leave the company. The documentation is subsequently submitted to the maintenance supervisor for review and approval.

Solution​

The solution breaks up the paper-based structure described in State of the Art: the maintenance documentation is digitalised, but under the two guiding requirements of the use case - self-determined and secure. The component landscape shown below is deliberately mirrored: manufacturer/fab and equipment supplier/service partner operate the same building blocks, and the only connection between them runs through the two EDCs.

On the manufacturer/fab side, the abatement equipment is connected to the process control software. The AAS infrastructure hosts the digital twin of that equipment: the manufacturer of the abatements, provided the base AAS for the selected products with the submodel templates Nameplate, Technical Data and Handover Documentation; the Maintenance Logbook submodel is added on top of it and holds the maintenance logbook entries. The GUI Maintenance Logbook is the entry point for the maintenance personnel. The service AAS to EDC exposes the AAS infrastructure as EDC assets, so that the connector remains the single controlled egress point of the company.

The equipment supplier/service partner side mirrors this setup: its EDC receives the entries, the service EDC to AAS writes them into its own AAS server, where the Maintenance Logbook keeps the received entries 1..X, and the same GUI Maintenance Logbook makes them available to the service partner - for example as the basis for cost billing. The supplier therefore never gains access to the fab's systems; it holds its own copy of exactly those entries that were released for it.

The key design decision is this mirroring instead of a shared or centrally hosted logbook: both parties keep their data in their own AAS environment, and every entry crosses the company border only as an explicit, contract-governed transfer between the two EDCs. The sequence of such a transfer is described in the next diagram.

Both diagrams in this document are maintained as inline Mermaid source and rendered by Docusaurus using Mermaid 11.15.0; edit the fenced mermaid blocks and rebuild the site to regenerate them.

Sequence of a Maintenance Logbook Entry​

The sequence diagram shows the exchange of a single maintenance logbook entry between the manufacturer (fab) and the equipment supplier/service partner. Both parties operate the same set of components - Web UI, backend, AAS Repository, Submodel Repository and an EDC - so the deployment is symmetric and independent of the role a company takes in the exchange.

1. Provisioning (steps 1-8). Before any exchange takes place, both backends register their AAS Repository and their Submodel Repository at their local EDC. Read access (GET) and write access (POST, PUT, DELETE) are published as separate assets, each with its own policy and contract definition. This separation is a deliberate design decision: a partner can be allowed to append a maintenance entry without being allowed to read the complete logbook of the equipment, and vice versa.

2. Local recording (steps 9-14). The maintenance personnel create the entry in the Web UI, which hands it over to the backend. The backend resolves the AAS shell of the equipment in the AAS Repository and appends the entry to the Maintenance Logbook submodel in its own Submodel Repository. The local record is written first and remains the leading copy; no process-critical data has left the company at this point.

3. Sovereign transfer (steps 15-31). Only afterwards the backend starts the Dataspace Protocol flow through its EDC: it requests the partner's catalog with a filter for the synchronization asset, negotiates the contract and retrieves the data address (EDR). Using this data address, the entry is pushed as a POST request through both connectors into the supplier's Submodel Repository, where it is stored in the mirrored Maintenance Logbook submodel. The confirmation is propagated back to the Web UI, so the maintenance personnel can see whether the transfer succeeded.

The result is a push-based mirror of the logbook: the supplier receives exactly those entries that have been released for them - the basis for their cost billing - while the manufacturer keeps the complete record. All traffic crossing the company border passes exclusively through the EDC under a negotiated contract, and no central third-party storage is involved. All repository calls use the IDTA API in version 3.2 (BaSyx implementation), see the following section.

Application Programming Interfaces (API)​

The use case communicates with the AAS Repository and Submodel Repository through version 3.2 of the IDTA Application Programming Interfaces, implemented using Eclipse BaSyx.

Protocols​

NameDescriptionLink to Documentation
ISO/IEC DIS 26450Eclipse Dataspace Protocol (DSP)https://www.iso.org/standard/93502.html
Dataspace Protocol 2025-1Documentation for ISO/IEC DIS 26450https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol
ISO/IEC DIS 26451Eclipse decentralized claims protocolhttps://www.iso.org/standard/93503.html
Eclipse Decentralized Claims Protocol v1.0Documentation for ISO/IEC DIS 26451https://eclipse-dataspace-dcp.github.io/decentralized-claims-protocol/v1.0.1/

NOTICE​

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

  • SPDX-License-Identifier: CC-BY-4.0
  • SPDX-FileCopyrightText: 2026 Hochschule für Technik und Wirtschaft Dresden
  • SPDX-FileCopyrightText: 2026 Robert Bosch Semiconductor Manufacturing Dresden GmbH
  • SPDX-FileCopyrightText: 2026 DAS Environmental Expert GmbH
  • SPDX-FileCopyrightText: 2026 algorismic gmbh
  • SPDX-FileCopyrightText: 2026 Contributors to the Eclipse Foundation
  • Source URL: https://github.com/eclipse-tractusx/eclipse-tractusx.github.io