Skip to content

Provide a DTDL v2 implementation of the Industry 4.0 Asset Administration shell ontology

License

Notifications You must be signed in to change notification settings

JMayrbaeurl/opendigitaltwins-assetadminstrationshell

Repository files navigation

Open Digital Twins ontology for the Industrie 4.0 Asset Administration Shell

The Industrie 4.0 Asset Administration Shell (AAS) is an open standard for the exchange of information between partners in the manufacturing value chain. The Asset Administration Shell (AAS) is the digital representation of an asset. We also call it a “digital twin”. The AAS consists of a number of submodels in which all the information and functionalities of a given asset – including its features, characteristics, properties, statuses, parameters, measurement data and capabilities – can be described.

Microsoft has defined an open standard for describing models of device and logical digital twins, the Digital Twin Definition Language (DTDL). This effort has been brought into the Digital Twin Consortium’s Open Source Collaboration Acceleration initiative. Ontologies for Smart Cities, Smart Buildings and Energy Grids have been published.

The authors of this GitHub repository have trialed the applicability of using the AAS as a base for building an ontology for Smart Production (Discrete Manufacturing, Process Manufacturing and Automotive Production).

Implementation with DTDL v2

The Asset Administration Shell is defined as a meta model. Implementing all essential models in DTDL was straightforward given the capabilities of DTDL.

High level architecture!

Figure 1: Implemented AAS Metamodel and Submodels

The DTDL JSON files all passed the DTDL Validator. When importing the models into the Azure Digital Twin Explorer, you get the following model graph:

High level architecture!

Figure 2: Asset Administration Shell meta model graph

Extensibility through Submodels

A powerful key concept of the AAS metamodel is that all relevant information is provided by submodels. Submodels can refer to other submodels.

Pro:

  • This enables a high degree of independence from the entire supply chain in building and operating digital twins.

  • The effort to build an DTDL implementation of the meta model is low.

Con:

  • The submodels have for the most part a very fixed structure. In other ontologies, these structure would have been designed in dedicated models. This implicates that there must be diligence in complying with the modeling requirements – to accomplish data integrity.

The example below illustrates this challenges. For the submodel “Nameplate” (source) the properties within are fully specified. [MLP= MultiLanguageProperty].

High level architecture!

Figure 3: Sample properties of submodel "Nameplate"

Samples

We implemented two samples:

  1. The example from the Industrie 4.0 “From idea to implementation” on page 36/37 where “Nameplate” was still referred to as “Identification”.

High level architecture!

Figure 4 Sample from the Industrie 4.0 documentation

High level architecture!

Figure 5 Twin graph from the first sample

  1. The Hilscher Iot Edge Gateway from the set of on pages 55-57 in the same document

High level architecture!

Figure 6 Second sample from the Industrie 4.0 documentation with Hilscher

High level architecture!

Figure 7 Hilscher netIOT Edge Gateway submodels

High level architecture!

Figure 8 Twin graph from the second sample

Example UI to Automate Twin Creation using the AAS Model

High level architecture!

Figure 9 Digital Twin Sample Client App

High level architecture!

Figure 10 New instance in ADT Explorer

Since customers may have their own sub model properties, we can also generate dynamic UI based on the model properties to automate the instance creation in Azure Digital Twin.

Industrie 4.0 Resources