Implementing the Industrie 4.0 IT Infrastructure for Digital Twins

In our previous blog post, we outlined a solution architecture to show what an Industrie 4.0 IT infrastructure for Digital Twins can look like. However, an architecture on its own is not sufficient for realizing Industrie 4.0. To bring the architecture to life and reap its benefits, an implementation of the concepts is needed. In the following, we will present our implementation using the open-source middleware Eclipse BaSyx and elaborate the IT infrastructure for Digital Twins based on a demonstration scenario using code examples.

Previously, we elaborated requirements on an Industrie 4.0 IT infrastructure for Digital Twins. Additionally, we showcased the Asset Administration Shell (AAS) as a specific implementation of the Digital Twin. Based on these requirements and the concept of the AAS, we identified the following key elements of such an infrastructure:

• AAS Registry: Keeps track of the AAS in the system, can be browsed based on certain criteria, and provides the endpoint information for AAS access.
• AAS Server: Provides the AAS and allows dynamic upload of AAS. Can be located in the cloud.
• Edge Node: Provided by the device. Hosts highly dynamic data, e.g., sensor values.

Yet, identifying key components is not enough to enable easy instantiation of the Digital Twin infrastructure. These concepts need to be implemented and instantiated. However, companies may either lack the IT know-how and IT experts to implement these components, or they might not want to invest the effort for developing their own solutions. This is where open-source software comes into play.

Today, companies are resorting more and more to open-source software [1]. As already described ten years ago, open source can be a key driver of innovation [2].

In another blog post, researchers of Fraunhofer IESE have already detailed various benefits of open-source software. These include:

• Free access to existing source code & easy tailoring
• A community supporting the solution
• No dependency on commercial suppliers
• No development efforts of one’s own needed to create the solution
• Broad support with open-source tools

In the following, we will showcase a demonstration scenario using Eclipse BaSyx, which is an open-source Industrie 4.0 middleware developed by Fraunhofer IESE and its partners.

First, we will present an overview of BaSyx and related open-source tools. Then we will detail the off-the-shelf components provided by BaSyx that allow easy instantiation of a Digital Twin system. Using BaSyx and its off-the-shelf components, we will present a demonstration scenario where we set up the AAS infrastructure and provide code examples. Finally, we will provide next steps as to how interested parties can dive deeper into the world of BaSyx and develop their own solutions and components.

Enabling Industrie 4.0 with open source and Eclipse BaSyx

Fraunhofer IESE is leading the BaSys 4.2 project, which is sponsored by the German Federal Ministry of Education and Research (BMBF) and focuses on enabling interoperability based on the concept of the Asset Administration Shell. While the results of the project are being published at appropriate scientific venues, they are also implemented as open source in Eclipse BaSyx.

BaSyx is published on the platform of the Eclipse Foundation and utilizes the Eclipse Public License 2.0, which enables its usage in commercial applications and products.

The middleware provides SDKs in Java, C++, and C#, enabling developers to implement Industrie 4.0 solutions in the programming language they are most comfortable with. In the context of this blog post, we will focus on the Java SDK, which is driven by Fraunhofer IESE.

SDKs provide the means to work with Asset Administration Shells, their submodels, and the AAS infrastructure in accordance with the Details of the Asset Administration Shell 2.0.1 document.

For example, there are methods for retrieving AAS and submodels based on their ID, as well as  for handling SubmodelElements.

In addition to several SDKs and off-the-shelf components, an open-source wiki is also provided. Here, a plethora of documentation on components and concepts, example snippets, and scenarios is available, such as the prerequisites and installation instructions of the Java SDK.

Additionally, an API documentation for each key component is provided. The API is described by an OpenAPI 3.0 specification and hosted on SwaggerHub.

Figure 2 – Excerpt of the AAS Registry API

Furthermore, there exist other open-source tools that facilitate working with AAS and their submodels. For example, the AASX Package Explorer enables quick creation of AAS and submodels via a graphical user interface. This configured data is then stored as an AASX package, which can be understood, for example, as a zip file containing Asset Administration Shells, submodels, and accompanying data (e.g., data sheets). However, this AASX file only contains the serialized data – it is not able to provide a runtime interface on its own. Using the off-the-shelf components provided by BaSyx, these AASX components can be hosted with little effort. Further details are described in the wiki.

Off-the-shelf components enable a quick instantiation

While the SDKs allow quick creation of programs working with AAS and their infrastructure, they require knowledge of the respective programming language. However, not every user of BaSyx and the AAS environment needs to have programming know-how. Off-the-shelf components enable stakeholders to quickly instantiate the AAS infrastructure with no programming effort. Instead, with little changes in configuration files, they can be tailored to the specific contexts and the stakeholders’ needs.

Currently, we have the following off-the-shelf components with their respective backends at our disposal:

• AAS Registry
  • In-memory
  • MongoDB
  • SQL database
• AAS Server
  • In-memory
  • MongoDB

These components are distributed using Docker images. For example, images for these key components are available on DockerHub and can thus be easily downloaded and instantiated.

Additionally, the components are documented on their own page in the BaSyx Wiki.

Demonstrating the Industrie 4.0 IT infrastructure for Digital Twins with Eclipse BaSyx

To showcase the principles of the Industrie 4.0 IT infrastructure for Digital Twins and Eclipse BaSyx, we will next provide and describe an example scenario. This scenario utilizes the previously mentioned off-the-shelf components. The code for this scenario is also available online. In this scenario, an oven will be added to the system and will integrate itself with the AAS infrastructure.

However, first we have to set up the infrastructure itself. Note that you need to set up Docker on your machine. Since the AAS Server and the AAS Registry images are made available via Docker Hub, they can be pulled directly and started using the following commands:

docker run --name=aasServer -p 8081:4001 eclipsebasyx/aas-server:0.1.0-PREVIEW

docker run --name=aasRegistry –d -p 8082:4000 eclipsebasyx/aas-registry:1.0.0

The first time this is executed, the required images are automatically downloaded from Docker Hub. Now the local endpoints for accessing the AAS Server and the AAS Registry are:

http://localhost:8081/aasServer/shells/
http://localhost:8082/registry/api/v1/registry 

The AAS Registry and the respective containers can be started, stopped, and removed using their names “aasServer” and “registry”. For example, the following commands can be used to control the registry:

docker stop aasRegistrydocker start aasRegistrydocker rm aasRegistry

By default, these components are completely empty and based on the non-persistent in-memory „backend“. This and other settings can be changed by providing a configuration file when starting the container. For example, the AAS Server can be configured to load an existing AASX file (i.e., a packaged AAS, its submodels, as well as accompanying files). All configuration possibilities are documented on a page in the Eclipse Wiki.

After the infrastructure is set up, we can focus on the device commissioning.

First, the Asset Administration Shell and the two submodels (one for the Edge Node and one containing the documentation) are created.

// Create the oven asset
Asset ovenAsset = new Asset("OvenAsset", new Custom-Id("basyx.examples.OvenAsset"), AssetKind.INSTANCE);

// Create the AAS representing the oven
AssetAdministrationShell ovenAAS = new AssetAdministrationShell("oven", new CustomId("basyx.examples.oven"), ovenAsset);

// Create the documentation Submodel
SubModel docuSm = new SubModel("oven_doc", new Custom-Id("basyx.examples.oven.oven_documentation_sm"));

// Create the maximum temperature property and include it in the sub-model
Property maxTemp = new Property("max_temp", 1000);
docuSm.addSubModelElement(maxTemp);

// Create the edge submodel
SubModel edgeSm = new SubModel("curr_temp", new Custom-Id("basyx.examples.oven.current_oven_temperature"));
		
// The property in this submodel contains the currently measured temperature of the oven
// It is represented by a static value in this example
Property property = new Property("temp", 31);
edgeSm.addSubModelElement(property);

Now the Edge Node can be created and populated with the edgeSM. For this, an HTTP server is configured using the BaSyxContextConfiguration and a SubmodelServlet containing the Edge Submodel. After the configuration, the server is started.

// Create a BaSyxContext for port 8083 with an empty endpoint
BaSyxContextConfiguration config = new BaSyxContextConfiguration(8083, "");
BaSyxContext context = config.createBaSyxContext();

// Create a new SubmodelServlet containing the edgeSubmodel
SubmodelServlet smServlet = new SubmodelServlet(edgeSM);
 
// Add the SubmodelServlet mapping to the context at the path "/oven/curr_temp"
context.addServletMapping("/oven/curr_temp/*", smServlet);

// Create and start a HTTP server with the context created above
AASHTTPServer edgeServer = new AASHTTPServer(context);
edgeServer.start();

In the next step, the AAS and the Documentation Submodel that were created are uploaded to the cloud. The ConnectedAASManager is used for this task.

// Create a proxy to the registry server
AASRegistryProxy registry = new AASRegistryProxy("http://localhost:8082/registry/");

// Create a ConnectedAASManager with the registry created above
aasManager = new ConnectedAssetAdministrationShellManager(registry);

// Push the AAS to the cloud server
// The manager automatically registers it in the registry
aasManager.createAAS(ovenAAS, "http://localhost:8081/aasServer/");

 // Push the docuSubmodel to the cloud
// The manager automatically registers it in the registry
aasManager.createSubModel(ovenAAS.getIdentification(), docuSm);

The last step is to register the submodel provided by the Edge Node now running in the registry. For this, a descriptor for the submodel has to be created first .

// Build the SubmodelDescriptor for the Edge-SM
SubmodelDescriptor edgeSMDescriptor = SubmodelDescriptor(edgeSM, "http://localhost:8083/oven/curr_temp/");

// Add the already existing edgeSM to the descriptor of the AAS
registry.register(ovenAAS.getIdentification(), edgeSMDescriptor);

Now that the device has been commissioned and integrated with the system, we can use the Java SDK to retrieve the information about the AAS and the submodels, e.g., in an application.
The following code shows how to retrieve an AAS from the server using the ConnectedAssetAdministrationShellManager.

// Create a proxy to the registry server
AASRegistryProxy registry = AASRegistryProxy("http://localhost:8082/registry");

// Create a ConnectedAASManager using the registry proxy
ConnectedAssetAdministrationShellManager manager = new ConnectedAssetAdministrationShellManager(registry);

// Retrieve the AAS from the server
IAssetAdministrationShell aas = manager.retrieveAAS(ovenAAS.getIdentification());

Next, the submodels are retrieved from the server using the AAS obtained above.

// Get the Submodels from the AAS
// The returned Map maps idShort to Submodel
Map<String, ISubModel> submodels = aas.getSubModels();

Finally, the max_temp property is retrieved from the Documentation Submodel and printed to the console.

// Get the required Submodel from the Map using its idShort
ISubModel docuSubmodel = submodels.get("oven_doc");

// Retrieve it using its idShort
ISubmodelElement smElement = docuSubmodel.getSubmodelElement("max_temp");

// Print its value to the console
System.out.println(smElement.getValue());

Taking a deep dive into Eclipse BaSyx

Of course, the previous example showcases only a small portion of the features of Eclipse BaSyx. In the following, a small excerpt of other features is given:

• Events: Pulling information is not always the most appropriate interaction pattern. Instead, events can be triggered when an element changes. Currently, BaSyx supports events for changes on Submodels and their respective SubmodelElements. In the future, events will also be supported for changes on the AAS and Registry level.
• Virtual Automation Bus: The integration of heterogeneous communication systems can impose great challenges. The Virtual Automation Bus provides quick integration of arbitrary protocols through the definition of an intermediate language [3].
• Control Components: In a service-based production, interaction with service providers has to be addressed. Control Components provide the necessary abstraction and API for handling different types of service providers.

For further reading, the Eclipse BaSyx Project Wiki is a good starting point. As previously mentioned, we provide a multitude of code snippets and scenarios illustrating further use cases of BaSyx. Additionally, there are papers that describe Digital Twins for specific use cases. For example, the data models to be contained in Digital Twins for a service-based production are detailed [4].

Additionally, Eclipse BaSyx enables easy implementation of custom components. It provides interfaces for each core component that can be overwritten. The rest is handled by the BaSyx system. Furthermore, it provides Technology Compatibility Kits (TCK)]. These TCKs exist for each core component of BaSyx and enable third-party developers to easily validate whether their components behave as expected by the BaSyx system.

To summarize, Eclipse BaSyx and its off-the-shelf components make it easy to set up an Industrie 4.0 IT infrastructure for Asset Administration Shells. Its distribution as open-source software enables developers and users to quickly realize their own use cases and build commercial products.

 

SOURCES:

[1] https://www.immagic.com/eLibrary/ARCHIVES/GENERAL/OPTAR_US/O051219W.pdf

[2] Ebert, Christof. „Open source drives innovation.“ IEEE Software 24.3 (2007): 105-109.

[3] Kuhn, Thomas, Pablo Oliveira Antonino, and Frank Schnicke. „Industrie 4.0 Virtual Automation Bus Architecture.“ European Conference on Software Architecture. Springer, Cham, 2020.

[4] Schnicke, Frank, Thomas Kuhn, and Pablo Oliveira Antonino. „Enabling Industry 4.0 Service-Oriented Architecture Through Digital Twins.“ European Conference on Software Architecture. Springer, Cham, 2020.