sharing, in which both the company providing the data and that using it mutually
benefit through improved services and databases [59].
The shared DT is necessary for implementing collaborative data sharing. It is
based on the fundamental concepts of a general DT, which are characterized by the
integration of various data formats from distributed data storage and the description
of data with meta-information [67]. Following the definition of data sharing, a shared
DT describes the extension of the archetypical characteristic of a DT by the functions
of interoperable and sovereign use in collaborative networks. This extension
includes the standardized data model, which in turn includes the uniform description
of interfaces. The respective data model must enable manufacturer-neutral and crosscompany interoperability.
A shared DT is further characterized by the emphasis on security concepts and, in
this context, especially the concepts for data policy enforcement. Access control is
an essential tool for data policy enforcement for DTs and restricts the access to
functionalities and the asset model information of the DT [68]. However, data
sovereignty must be considered in the use of DTs in collaborative networks. It is
the ability of a natural or legal person to exercise exclusive self-determination over
the economic asset data [59] and based on the data policy enforcement on usage
control. In contrast to traditional access control, usage control regulates future data
usage by adding restrictions [69]. Access control, therefore, manages the rights to
collect data, while usage control determines how the recipient can use the data
[70, 71].
Within an enterprise, data security, accountability, and transparency are defined.
If data leaves the enterprise, additional security is required. For shared DTs, it must
be ensured that the company providing the data always retains sovereignty. Therefore, the International Data Spaces Association (IDSA) [72] has developed a
reference architecture, which enables the secure and sovereign exchange of data
between trustworthy parties. It defines a technical infrastructure and a semantic set of
rules for data exchange and data usage in ecosystems. DIN SPEC 27070 [73], based
on the Industrial Data Spaces (IDS) reference architecture model, is the first global
and interoperable standard.
The AAS is a virtual digital and active representation of an asset and renders a
standardized I4.0 component in an I4.0 (eco)system composed of such building
blocks. For multilateral data exchange, the AAS offers an appropriate basis for
interoperability between the actors mentioned earlier through its upcoming standardization. The Fraunhofer Gesellschaft is currently working on the combination of
IDS and AAS (see Case Studies in Sect. 7). The AAS-REST-API will be realized as
an IDS Data App, which can be offered in an IDS App Store if necessary. IDS
messages contain AAS-compliant data with IDS references to resources available
via IDS. The ABAC of the AAS is synchronized with IDS Contracts and AAS
subjects with IDS Participants. The IDS is more focused on communication (data in
movement) and provides general interfaces but does not specify payload formats,
whereas the AAS standards are more concrete. In complex and automated I4.0
scenarios, new legal issues arise, currently being investigated in the legal testbed
project [74] in cooperation with IDSA and PI4.0.
The Challenge of Implementing Digital Twins in Operating Value Chains
149
benefit through improved services and databases [59].
The shared DT is necessary for implementing collaborative data sharing. It is
based on the fundamental concepts of a general DT, which are characterized by the
integration of various data formats from distributed data storage and the description
of data with meta-information [67]. Following the definition of data sharing, a shared
DT describes the extension of the archetypical characteristic of a DT by the functions
of interoperable and sovereign use in collaborative networks. This extension
includes the standardized data model, which in turn includes the uniform description
of interfaces. The respective data model must enable manufacturer-neutral and crosscompany interoperability.
A shared DT is further characterized by the emphasis on security concepts and, in
this context, especially the concepts for data policy enforcement. Access control is
an essential tool for data policy enforcement for DTs and restricts the access to
functionalities and the asset model information of the DT [68]. However, data
sovereignty must be considered in the use of DTs in collaborative networks. It is
the ability of a natural or legal person to exercise exclusive self-determination over
the economic asset data [59] and based on the data policy enforcement on usage
control. In contrast to traditional access control, usage control regulates future data
usage by adding restrictions [69]. Access control, therefore, manages the rights to
collect data, while usage control determines how the recipient can use the data
[70, 71].
Within an enterprise, data security, accountability, and transparency are defined.
If data leaves the enterprise, additional security is required. For shared DTs, it must
be ensured that the company providing the data always retains sovereignty. Therefore, the International Data Spaces Association (IDSA) [72] has developed a
reference architecture, which enables the secure and sovereign exchange of data
between trustworthy parties. It defines a technical infrastructure and a semantic set of
rules for data exchange and data usage in ecosystems. DIN SPEC 27070 [73], based
on the Industrial Data Spaces (IDS) reference architecture model, is the first global
and interoperable standard.
The AAS is a virtual digital and active representation of an asset and renders a
standardized I4.0 component in an I4.0 (eco)system composed of such building
blocks. For multilateral data exchange, the AAS offers an appropriate basis for
interoperability between the actors mentioned earlier through its upcoming standardization. The Fraunhofer Gesellschaft is currently working on the combination of
IDS and AAS (see Case Studies in Sect. 7). The AAS-REST-API will be realized as
an IDS Data App, which can be offered in an IDS App Store if necessary. IDS
messages contain AAS-compliant data with IDS references to resources available
via IDS. The ABAC of the AAS is synchronized with IDS Contracts and AAS
subjects with IDS Participants. The IDS is more focused on communication (data in
movement) and provides general interfaces but does not specify payload formats,
whereas the AAS standards are more concrete. In complex and automated I4.0
scenarios, new legal issues arise, currently being investigated in the legal testbed
project [74] in cooperation with IDSA and PI4.0.
The Challenge of Implementing Digital Twins in Operating Value Chains
149