Declarative Policy Control for Data Spaces: A DSL-Based Approach for Manufacturing-X

TL;DR

This work tackles the challenge of declaratively specifying and enforcing data governance across federated manufacturing data spaces. By extracting and unifying metamodels from OPC UA, EDC, ID Link, and AAS, the authors develop a Domain-Specific Language that enables domain experts to declare policy, access, and discovery configurations in a single, machine-processable artifact. A prototype DSL demonstrates cross-technology consistency within a Manufacturing-X-inspired SDVN, highlighting potential for simpler, safer data sharing without bespoke imperative code. The study sets the stage for automated code generation and broader support for MX-Port configurations across diverse data-space technologies, advancing practical deployment of sovereign data sharing in Industry 4.0.

Abstract

The growing adoption of federated data spaces, such as in the GAIA-X and the International Data Spaces (IDS) initiative, promises secure and sovereign data sharing across organizational boundaries in Industry 4.0. In manufacturing ecosystems, this enables use cases, such as cross-factory process optimization, predictive maintenance, and supplier integration. Frameworks and standards, such as the Asset Administration Shell (AAS), Eclipse Dataspace Connector (EDC), ID-Link and Open Platform Communications Unified Architecture (OPC UA) provide a strong foundation to realize this ecosystem. However, a major open challenge is the practical description and enforcement of context-dependent data usage policies using these base technologies - especially by domain experts without software engineering backgrounds. Therefore, this article proposes a method for leveraging domain-specific languages (DSLs) to enable declarative, human-readable, and machine-executable policy definitions for sovereign data sharing via data space connectors. The DSL empowers domain experts to specify fine-grained data governance requirements - such as restricting access to data from specific production batches or enforcing automatic deletion after a defined retention period - without writing imperative code.

Figures (6)

• Figure 1: The five-layered MX-port architecture together with three application-specific implementations mx_port_whitepaper.
• Figure 2: The metamodel of the information required to implement the layers L5 and L4 of MX-ports with OPC UA.
• Figure 3: The metamodel of the information required to implement the layers L5 and L4 of MX-ports with Eclipse Data Space Connector.
• Figure 4: The unifying metamodel combining information required to implement the layers L5 and L4 of MX-ports with OPC UA, EDC, and ID Link & AAS security.
• Figure 5: The metamodel of the information required to implement the layers L5 and L4 of MX-ports with ID Link and AAS security.