We talked to Professor Christian Diedrich of the Otto von Guericke University Magdeburg (OvGU) and ifak (Institute for Automation and Communication) after the meeting.
Mr Diedrich, who attended the meeting and why?
“A total of 19 participants from nine projects and initiatives attended the meeting. These projects include BaSys 4.2 (funded by the Federal Ministry of Education and Research), Smart Factory Kaiserslautern (DFKI) and the TeDZ project (Fraunhofer IOSB-INA) as well as projects of ifak such as INVITE4.0, funded by the Federal Ministry for Economic Affairs and Energy, and projects at IBM, Mitsubishi, SAP, Siemens and Wittenstein. Bosch and the open source project “openAAS” are also on board, but were unable to send representatives to the kick-off meeting.
At first glance, the projects seem to vary widely. But they have more in common than one might think. They all deal with one question that is crucial and vital to Industrie 4.0: how do machines or products in factories communicate with one another in a way that enables them to interact autonomously and to complete their tasks in the production process? And this is precisely why the Asset Administration Shell Networked (Verwaltungsschale vernetzt) was created. It brings together existing projects that implement the and harmonises their languages.”
Were your expectations of the first meeting met?
“Absolutely. I'm particularly pleased that we went home with the agreement to create a common application as a first step and to use different implementation variants.”
What exactly does that mean? What goals have you set yourself?
“We will take BaSys 4.0, openAAS and other company-specific implementations into account as we move forward with our work. At the end of the project, the administration shells should all be interoperable with each other. To this end, we are defining the criteria for interoperability, gathering practical experience in a testbed, evaluating the specifications that already exist, and are communicating our results to the working groups of the I4.0 community. We are also developing best practice examples for the content and use of the management shell.”
What will be your first task, specifically?
“We have agreed that the project partners will implement a service provider for an automated tender in accordance with VDI/VDE 2193-2 by autumn 2019. This means that we will create and programme a service provider that will be able to autonomously prepare a bid based on an automated invitation to tender”.
What exactly is a service provider for a tendering procedure in the context of the administration shell?
“A service provider is a piece of software within the administration shell. It enables Industrie 4.0 components such as products, machines or production facilities to understand so-called service requests from other components. The service provider can respond to these requests and submit offers independently.
For example, let’s take the production of a bicycle handlebar. Even prior to it being manufactured, the handlebar is given an administration shell. This shell is able to publish the respective tender ‘I must now be printed in 3D. Who can take on the order at less than x euros?’ In other words, the bicycle handlebar administration shell takes on the role of a service requester and sends the print request to the factory hall, where five 3D printers are available. The administration shells of the 3D printers understand the request as they can also take on the role of a service provider based on the newly developed software. In this role, the five 3D printer administration shells automatically check whether the printer meets constraints such as the time of completion ('now') or the cost of implementation ('less than x euros'). The service provider in the administration shells of the 3D printers decides autonomously whether it can or wants to submit an offer and what this offer should be. It negotiates and communicates directly with the administration shell of the bicycle handlebar. When the next production step comes, the bicycle handlebar administration shell starts a new tender – and thus also initiates a new negotiation among the relevant administration shells.”
Is this tender procedure accessible to others who are not participating in the project?
"Yes, of course! Upon request, we will provide the relevant documents so that others are also able to programme such service provider software. The description is written in English”.
What are the benefits of this? Why do you implement the provider first?
“There are good reasons for choosing this example. The tender procedure shows new possibilities that are afforded by Industrie 4.0. It shows, for example, how we deal with features and dictionaries that go beyond the standard API interfaces. The tender procedure allows us to make the interaction between I4.0 components very dynamic and highly flexible, especially regarding the assignment of manufacturing tasks. Free internal or external capacities can thus automatically be integrated into company processes, and bottlenecks can be eliminated more quickly. This also shows how autonomous functions can be implemented in the I4.0 components.
Our work is based on the VDI/VDE 2193-2 standard, since the tender procedure is the subject of this standard which the VDI members adopted by consensus as the final VDI standard. It is therefore recognised and supported by experts. We have also subjected the standard to legal review with the result that the tender procedure can lead to a legally valid contract between machines if both parties accept the general terms and conditions. In addition, there is already a testbed that implements this example. Also, there is still no agreement on a middleware on how data can be exchanged. Work on this is still ongoing. The Industrie 4.0 language based on VDI/VDE 2193-2 is completely independent of such middleware and we can use it with a wide variety of middleware solutions.”
Thank you very much for this interview.
The next meeting of the project team will take place on 23 September 2019 and is likely to be held in Fulda.