The Digital Twin is currently a widely discussed topic for presenting and exchanging information on physical assets through virtual networks. Especially the digitisation of the manufacturing industry, Industry 4.0, drives the implementation of Digital Twins as part of integrated production processes. Hence, the protection of sensitive data becomes an evident challenge. We contribute by determining the requirements of current scenarios, the descriptive expressiveness of necessary vocabularies, and by formalising the involved operations. The Asset Administration Shell is used as a concrete metamodel for Digital Twins and is combined with the data sovereignty and enforcement concepts of the International Data Spaces to illustrate how these concepts can be implemented into a comprehensive Industry 4.0 scenario.
The excessive use of the term 'Digital Twin' in many di erent contexts makes it nearly impossible to nd a proper de nition that covers all intended use cases. While this vagueness certainly is one reason for the success of the terminology itself, it signi cantly complicates its technical implementation. As a consequence, several in uential initiatives and standardisation consortia have recently published detailed technical speci cations and requirement lists for respective Digital Twin realisations. This technical grounding and consolidation process states what a Digital Twin must provide and how it needs to behave. The resulting speci cations can be seen as the backbone for every practical roll-out of Digital Twins in productive settings.
Especially in the industrial domain faces a rising the demand for standardised, interoperable and semantically described physical assets. The heterogeneous machine parks { and the thereby created ine ciencies through elaborate integration steps, di cult maintenance procedures and the various information ows across companies { motivate Digital Twins as the core information carrier in a digital integration layer. The interoperability of assets is required due to the distributed nature of industrial production and the fact that the regarded digitisation processes usually happen in brown eld environments. Di erent to green eld scenarios, brown eld settings contain a legacy systems and facilities, which cannot be replaced easily. The semantically unambiguous descriptions are necessary due to an unmanageable amount of di erent terms, de nitions and data models, even within the same company.
One of the most critical concerns are certainly the ensuring of data security and privacy. Part of that is the protection of business-critical information and know-how. The desired opening of interfaces, systems and devices contains the risk of losing control of these resources. This paper outlines ways and processes how digital data can be exchanged through the Asset Administration Shell as one implementation of Digital Twin but at the same time ensuring that the containing information stays protected. We propose mechanisms relying on current standards, the concept of data sovereignty as proposed by the International Data Spaces (IDS) and incorporating the conventions of the Semantic Web.
We outline our vision of the AAS Digital Twin at the intersection of Web technologies, industrial requirements and privacy protection (1), explain how the Industry 4.0 requirements can be faced with Usage Control Contracts (2) and provide discussion points required to be solved for further progress in the domain (3). The following section gives a brief overview of the current situation, with a short discussion on related research works in Section 3. We provide a reference example in Section 4 to better illustrate how the AAS acts as a Digital Twin (Section 5) and which role Usage Contracts play (Section 6). We conclude with a discussion on the outlined points in Section 7. 2
The proposed approach in this paper relies on the latest speci cations for Digital Twins in Industry 4.0, the concept of Data Sovereignty and Data Usage Policy, and Access and Usage Control languages. These topics are brie y summarised in the following.
Digital Twins in Industry 4.0 Originally introduced as a simulation-driven
virtual representation of space and aircraft vehicles, the focus of Digital Twins
has shifted to data interoperability concerns and to serve as a foundation for
exchanging comprehensive data models of a nearly any kind of physical assets. As
this idea has gained a lot of attention, uncountable approaches, models and
variation appeared in the recent years. Worth mentioning are however the proposals
of the W3C working group Web of Things [
We have selected the Asset Administration Shell as the Digital Twin specication because the data model has now, with version 2.0, reached a su cient maturity level, the speci cation contains clear implementation instructions and the security model is de ned as an integral part of the metamodel. In particular, the data constraint statements enable the expressing of many required constructs and therefore form a suitable foundation for the following concepts. Data Sovereignty In current business interactions, permissions and obligations are declared through textual contracts. Wherever a formal, legally binding agreement needs to be documented, lawyers are required to express the intended meaning in written form. This is not suitable for the data-driven Industry 4.0, as interactions between organisations form on the y, dynamically and evolve and dissolve quickly.
In addition, the relation between the involved organisations needs to be reected by the technical implementations. Currently, arrangements between business partners rely on responsible human actors, which are trusted by the opposite party to treat their assets according to the previously concluded agreements. In case of violations, the textual contracts and the legislative system serve as escalation and disciplining stages. The interaction speed and data volume of the regarded scenarios, however, limit the monitoring capability of the involved humans, therefore restricting their options to control the data processing processes. The solution is to demand the implementation of data restrictions directly as part of the respective systems and, as far as this paper is concerned, into the Digital Twins.
The outlined situation is slightly di erent for person-related data, especially in member countries of the EU. The General Data Protection Regulation (GDPR) de nes certain rights and obligations for digital information related to humans. Still, the relevant data sets of Industry 4.0 do usually refer to machine to machine communication and, therefore, are not in the scope of GDPR laws. As no other legislative option exists to enforce control on digital information, respective agreements have to be established on a case-by-case basis.
In the following, we refer to contracts when talking about legally binding agreements, which usually appear in written, natural language form. In contrast to these human-readable contracts, policies, are understood as formally modelled descriptions: De nition 1. A Data Usage Policy is machine-readable representation of an agreement between two legal entities, exactly one assigner and one assignee, de ning the permissions on a de ned data artefact. Policies are serialised in a common data format (e.g. XML or JSON) and use shared vocabularies to unambiguously outline their intentions.
Note that in general more than two parties can participate in a policy. We
intentionally leave this and other extensions open for future work. It is also
important to understand that Data Usage Policies, as de ned here, have currently
no legally binding power. A binding agreement still requires textual contracts.
Policies however omit the intended blurriness of legal clauses and need to be
objectively decidable. Contracts on the other hand must be interpreted based
on their context and the prevailing legal understanding of the contained clauses.
The challenge is therefore to translate the established patterns of textual
contracts into the digital world, and to create an equally recognised level of trust.
As stated, several frameworks and guidelines have targeted the formulation,
exchange and implementation of Digital Twins but also data restriction policies.
The terminology of permissions, obligations, and conditions introduced by the
UCONABC [
XACML applies very well in Attribute-based Access Control (ABAC)
scenarios. The object refers to the attribute of the resource under consideration,
which a subject wants to access. ABAC rules can be stated in plain text and
interpreted by the hosting system, as intended by the AAS metamodel. Yu et
al. [
The Data Privacy Vocabulary3 (DPV) provides terms to annotate and
categorise instances of legally compliant personal data handling according to the
GDPR, including the notions data categories, data controllers, purposes of
processing data, etc. The focus is on the description and annotation of privacy
constraints. The Open Digital Rights Language (ODRL) [
The IDS regards the secure and trustworthy data exchange on a data-centric,
domain-agnostic level. The Reference Architecture Model [
The scenario in this section serves as a running example to outline the ideas and approaches for an integrated Usage Control of a Digital Twin in an industrial setting (cf. Fig. 1). A Manufacturer collects static master data together with sensor observations of an operating device inside an AAS. It mandates a Data Analyst to access the AAS instance and come up with performance KPIs and failure predictions in order to optimise its production processes. The Manufacturer also is willing to share these insights contained in the Data Analyst's copy (AAS') with its Business Partner, as early information on potential breakdowns directly a ects their just-in-time supply chain. It is however crucial for the Manufacturer to prohibit any access of other customers of the Data Analyst, as those might be Competitors.
However { as the AAS' is now stored at the Data Analyst { the contained information is not under control of the Manufacturer anymore but still contains its critical data. As such, the Data Analyst needs to evaluate the access requests from both the Manufacturer's Business Partner and the Competitor accordingly. The required instructions and descriptions must be contained in the AAS, and also in the AAS'.
The Asset Administration Shell concept is a collection of several speci cation modules. The data model part speci es the core structure and di erent elements of the AAS, mainly administrative information about the AAS itself, the asset, and use case-speci c data collected and sorted in so-called Submodels. The serialised data can be transmitted in several data formats, for instance JSON, XML or any RDF serialisation. Another part of the AAS speci cation targets the interaction in a remote environment. API calls for OPC UA, MQTT and REST (based on HTTP) are currently under development.
Another speci cation targets the infrastructure components in an AAS-driven network. Distinct systems for search and discovery but also identity provision are required. For this challenge, two di erent aspects need to be distinguished. The identi cators of actual assets and their AAS will always be in the authority of their owners, following their company-speci c schemes. As the Digital Twin of the asset is intended as a product itself, no manufacturer can be expected to rely on a third party for naming its products. The attributes, properties and values contained in the AAS, however, need to be known to the intended users, otherwise no interoperability can be obtained. Rich and extensive vocabularies such as eCl@ss4 or the Common Data Dictionary (IEC CDD5) shall provide the necessary concepts. In our example, the Manufacturer can annotate the sensor streams using the eCl@ss property '0173-1#02-BAJ001#006'. Thereby, the value is xed to integer and the Data Analyst directly knows that the values have the unit litres per minute (l/min).
These approaches, however, only marginally re ect the potential of a comprehensively web-oriented approach. The catalogues only provide basic identi ers re ected in a taxonomy structure. Hypermedia links or machine-readable annotations are not provided out of the box. Identi ers have to be dereferenced using catalogue-speci c methods. Following the assumption that the Web stack (cf. Ass. 1) is a uniting technology and in place in every Industry 4.0 scenario at some point. Note that this does not mean that non-Web interactions shall be neglected. For instance, in machine-to-machine interactions, HTTP or Web browsers are usually not an appropriate choice. However, all developers, operators or any other involved stakeholders is capable to access and exchange Web-based information using the currently available tools, di erent to any other available technology set. This convenience advantage can not be underestimated since the acceptance by the target community is absolutely crucial for the success of any Industry 4.0 proposal.
Assumption 1 Web technologies are the common denominator known to every Industry 4.0 stakeholder. All involved parties are familiar with URIs, HTTP, DNS, and Web Browsers and can use this technology set to establish Industry 4.0 use cases based on it.
Linked Data and the Linked Data vocabularies can provide terms and concepts with rich annotations and machine-readable relations. Nevertheless, several reasons still severely hamper the wider adoption of Linked Data-based approaches for Industry 4.0 vocabularies. First, the requirements of industrial applications are long-term and for formal and guaranteed maturity. As legal liabilities arise from the implementation of concepts in productive facilities, a community-based approach such as DBpedia is indefensible. Established and well-reputated agencies need to back-up such a vocabulary, with clearly de ned process and decision-criteria. This is in contrast to the less formal procedures currently in place in the Semantic Web community, which is still mostly driven from an academic background.
Statement 1 Long-term support and formal liability are crucial factors for the adoption of any digital resource though the manufacturing industry. Preferred are established standardisation agencies such as ISO, IEC, NIST or DIN.
The second reason is certainly the separation of communities. Industrial developments are, by their nature, mostly driven and managed by people with an engineering background. Web developers on the other hand do not understand the speci c requirements or speak the used language appropriately. For instance, using the running example, a software application ran at the Data Analyst can quite easily be updated, relocated or completely replaced. This is a common development for Web services. A physical device or facility needs to stick to safety regulations and certi cation processes as otherwise people could get harmed. This leads to signi cantly longer and more complex design and decision processes. Combining digital services with physical assets leads to clashes between both approaches and communities. Fortunately, a steady progress can be identi ed. This is certainly driven by the identi ed business potential and the wide-spread conviction that neither non-digital devices nor plain software presents a future-proven product.
Statement 2 The current solutions proposed by Industry 4.0 consortia hardly re ect the potential of Web technologies. The (Semantic) Web community, on the other hand, needs to re ect the formal requirements of industrial applications and potential harmful consequences.
An entity, as understood in this paper, aggregates physical or tangible objects, information resources or digital data objects, software applications and any other identi able asset. It becomes a Digital Twin when it is extended with a digital form, representing it in digital networks. As we want to examine the AAS as the Digital Twin for the Industry 4.0, we use the following de nition: De nition 2. A Digital Twin is the combination of one distinct entity, called Asset, and its digital counterpart. This counterpart consists of the Asset Administration Shell and several Submodels containing data about the Asset ltered according to relevant use cases.
Note that the relation between an Asset and an representing AAS is not necessarily a one-to-one connection. For instance, the device in our example has an assigned AAS with all information for the Data Analyst and another one with relevant data for the Manufacturer's engineering department. They have di erent content and di erent identi ers. That means that not one single Digital Twin exist but rather overlapping sets.
Statement 3 As Digital Twins go through their own, but also re ect their Assets' life-cycles across companies and phases, one single, universal Digital Twin instance is usually not possible. Therefore, the AAS must be regarded as a fragmented set of information of the actual Asset.
In particular, this implies that the Open World Assumption holds for the AAS. Potential reasoning or other examinations of their content always takes place with incomplete information. This fact is partly regarded by the e orts to standardise Submodels as use case-dependent information carriers, which x the set of possible attributes and features.
All these models and data provisioning needs to be based on a well-de ned and consistent identi cation method. Currently, an incomprehensible set of legacy patterns is used in the domain, challenging a unifying approach. Furthermore, the ability and authority to select own identi ers is an essential characteristic for the public appearance of companies. However, proprietary schemes { sometimes implicitly encoding product families or versions { can lead to misunderstandings and errors at downstream services. Following the recommendations of the (Semantic) Web { using URIs { is a proven and technically easily manageable convention. This is formulated by the following assumption: Assumption 2 Every relevant actor in Industry 4.0 has its own internet domain. A direct mapping between the domain and the related company is always possible, also vice versa.
Due to the consideration that every company nowadays needs its own website, the validity of this claim seems reasonable. We furthermore regard an internet domain as a valuable, well-protected resource. Even though one can construct use cases where companies lose control over their domain, this will only happen in very few cases. Consequently, a su ciently durable namespace for identi ers is directly available for every company. Even though this assumption might be convincing at a rst glance, the legal obligations of long-lasting industrial identi ers are not necessarily met yet. This gap however might be resolved through new service providers, guaranteeing their sustainability as a new business model. Assumption 3 Internet domains are maintained over the whole life-cycle of a Digital Twin. A company will not lose control over its domain at any time. Statement 4 Constructing identi ers by concatenating a company's internet authority with its dedicated product-naming scheme automatically creates globally unique identi ers. The expressiveness of URIs is suitable for transporting this information in a syntactically feasible manner. Statement 5 URIs are the most commonly used identi ers throughout digital applications. Their established dissemination alone makes them superior to any other scheme.
Note that the convenience of the target group is again the dominant argument in favour of URIs. While this appears as a non-functional argument, we want to stress the fact that missing dissemination and adoption are the key obstacles of any Digital Twin concept published so far. 6
The expressiveness of the policies does, in general, not depend on the area they
are evaluated but on the targeted position in Figure 2. A human operator can
formulate and understand complex constructs, easily creating insolvable issues
for any AI. An control language stretching an unrestricted space is therefore not
bene cial, as it requires direct human intervention each time a policy is regarded.
However, in order to cope with most of the currently relevant use cases, we are
con dent that a small number of formalised dimensions (counting, time, space,
membership cf. [
Those dimensions need to be unambiguously de ned, limit the variety of interpretations and specify implementable logic for their evaluation. While for instance XACML or, as regarded in this paper, the Security module of the AAS and the IDS Usage Contracts provide a structure for data protection rules, their implications for evaluations is not yet su ciently de ned. The assumption reects the fact that there should be not only a shared understanding on the syntax of contracts but also their meaning. For our example, the Data Analyst must not only be able to request and receive the AAS but also understand and evaluate the clauses itself later on. While this is certainly solvable in point-to-point scenarios by simply agreeing on the allowed semantics, a truly federated framework for Industry 4.0 is not reached yet. This brings us to our next postulation, as the Usage Control of the AAS can only be as reliable as the embedding systems: Statement 6 A reliable end-to-end Usage Control scenario for Digital Twins requires trustworthy systems. Their state needs to be veri able through certi cation processes, cryptographic signatures and controlled environments.
Figure 3 shows the example expressed as an Asset Administration Shell snippet with focus on the description of the usage restrictions. The yellow, top classes represent the actual Digital Twin and the features of interest. According to the metadata model, those are represented by the AssetAdministrationShell and Submodel classes. The core data control sections are outlined, starting with the Security to the AccessControl class (blue), followed by the de nition of relevant entities and interactions (grey). The red Permission-related classes close the circle and link back to the actual protected features. Note that the same pattern can be expressed through an Usage Contract. The respective classes and properties are directly added but in another namespace (aas vs. ids).
The AAS is driven by the understanding of the host as the authority to de ne security rules. The focus is twofold, (a) to describe the requesting parties (called 'subjects') and their relations to certain attributes ('objects'). Furthermore, the relevant subcomponents of the control system are explicitly modelled (b).
The IDS aims to provide such a controlled, trustworthy ecosystem. While making no di erence in terms of the nature of the exchanged data, the IDS Connectors ensure a certain degree of control through certi ed execution environments, partly independent of the operating organisation. The IDS therefore locates the de nition of those Policy Points in the responsibility of the hosting system, without any mentioning in the Policy at all. While this behaviour allows for the shipment of both the AAS and the Policies, the interpretation of the described Policy is harder and requires higher degrees of formalisation. For instance, as soon as the AAS' is evaluated by the Data Analyst, its enforcement engine needs to interpret the Policy in accordance with its own local environment. This implies the need to be able to independently guess appropriate Policy Points. This very challenging task is further complicated by the prohibition of direct manual con guration, since the hosting system must ensure the Data Producer's interests and resist these kinds of manipulations. Statement 7 Derived Digital Twins must contain the original usage constraints. Downstream activities must be compliant to all previously stated restrictions.
This is of course di cult to maintain, as at some point in any work ow, the input components merge to a new product, with the assembler (previously consumer) as the new owner and provider. A simple example are the manuals shipped with each component of a machine. The Manufacturer in our example combines not only the device components into its product but also the manuals and safety documentation. Its customers of course do not get a single document set for each and every component. The resulting device's documentation, even though reusing content from several suppliers, is the property of the Manufacturer. De ning at which stage a new product appears { and who has the authority over its further use { is obviously a signi cant challenge. This is especially true for digital data in general and Digital Twins in particular.
We have outlined our vision how the merging of Usage Control and Data Sovereignty with the Asset Administration Shell can create an interoperable but protected Digital Twin for industrial purposes. The provided assumptions and statements are intended as starting points for further discussions. We believe that a consolidation of the thereby a ected approaches and concepts is necessary, and a trade-o between formalisation and expressed details on the one hand and adoption on the other is indispensable.
Still, the demand for more and more autonomously acting systems enforces overhead in terms of data models and implementations. The Usage Policies explained in the AAS show how the di erent speci cations can be combined to a comprehensive interpretation. We have observed that similar ideas and pattern appear in the di erent communities. The integrated approach as outlined in this paper can therefore also serve as a bridge between the communities. The combination of identi cation and interaction patterns with the standardisation e orts and domain requirements of manufacturers requires e orts from all parties. The result however has the potential to disrupt the way we regard assets and data in the intersection of the physical and virtual world.