Abstract
Smart Manufacturing stellt neue Anforderungen an die Interaktion zwischen den Komponenten. Machine-to-Machine-Kommunikation (M2M), Cyber-Physical (Production) -Systeme (CP (P) S), Industrial Internet of Things (IIoT) sind die Schlüsselwörter hinter diesen Themen. Allen gemeinsam ist, dass Daten zwischen den Systemen transportiert werden und dass sie gegenseitig verstanden werden müssen. Dies wird häufig mit dem Begriff „Interoperabilität “bezeichnet. Unabhängig von den verwendeten Kommunikations- und Middleware-Technologien müssen die Daten in den Diensten identifiziert und hinsichtlich ihrer Bedeutung erkannt werden. Dies ist eine Herausforderung, da die Interoperabilität während des gesamten Lebenszyklus der Komponenten, Maschinen und Anlagen funktionieren muss, auch wenn unterschiedliche Kommunikations- und Middleware-Technologien verwendet werden. In diesem Artikel wird der Begriff Interoperabilität daher in verschiedene Ebenen unterteilt. Basierend auf den Schichten werden die Hauptmerkmale der Interoperabilität diskutiert. Das Asset Administration Shell (AAS)-Konzept der Industrie 4.0-Initiative wird in Kürze eingeführt, da es mögliche Lösungen für den lebenszyklusübergreifenden Einsatz identifiziert. Außerdem wird eine Zuordnung häufig verwendeter Technologien zu den Interoperabilitätsschichten und deren Beziehung zum AAS bereitgestellt.
You have full access to this open access chapter, Download conference paper PDF
Similar content being viewed by others
Keywords
1 New Requirements for Interoperability
Smart manufacturing can be seen as a synonym for production systems that aim for more flexibility in terms of product quantity and product variety at comparable costs as for series or mass production. In [13] new value creation processes in and between companies are named among them order-driven production, versatile factory, self-organizing adaptive logistics, Value Based Services and circular economy.
From this, specific requirements for the interaction of the partners involved can be derived (only a few are selected):
-
Possibility of establishing client-contractor relationships quickly and globally
-
Cross-manufacturer, cross-company and cross-location networking of factories and production systems
-
Possibility of manufacturing in conjunction with internal as well as external manufacturing units
-
There are both horizontal and vertical interactions
-
The technical focus of the interaction also extends to the organizational exchange
-
Machines, components and devices take on active roles in the production process
Figure 1 emphasizes that components and devices are products that are built into machines and that these machines are used as products in systems. The processes take place both in reality and in the information world. Along the life cycles of all the components, devices, machines and plants, there are information flows from the planning documents to operations documents and tools. There are also transfer interfaces when devices are planned and installed in the machine and when machines are integrated into systems. For example, a machine builder compiles documentation from all components (from which he himself manufactures and the purchased parts). This is included in the entire system documentation. Creating and updating consistent descriptions is associated with considerable effort. Just think of the multitude of properties for the auxiliary power supply, connectors and terminal points. Consistency between these properties of the catalog data and those at the software interfaces of automation devices and tools is currently only possible with human help.
2 What Is Interoperability?
[12] compiles 7 different definitions of interoperability [11]. also shows a variety of starting points. This reflects the still vague idea of interoperability. From the multitude of ideas, a simple and condensed representation is used here without further explanation which is based on [3]. Interoperability can be divided into the four levels.
-
Technical interoperability represents the ability to exchange data, i.e. the means of communication (in the sense of the OSI reference model) are the same for the partners. In principle, this can be considered possible today if the partners can agree on a communication system (with its variants).
-
The syntactic interoperability represents the description of the data with all its type attributes in uniform formats, so that the exchanged data can be processed mechanically with regard to the attributes (this concerns data types, valid value range and the like). In principle, this is solved today, since when using appropriate information models in mutual agreement between the partners, all technical requirements are available (e. g. through the definition of fieldbus profiles, or through the node sets of OPC UA, even if many details have to be clarified during implementation).
-
Semantic interoperability is the ability to interpret the exchanged data in such a way that the intended action can be recognized and triggered if possible. This is currently only possible in narrowly defined contexts and across life phases and hardly exists when products are handed over between producer and user.
-
Organizational interoperability is the ability to act in processes of the life cycle of products, machines and plants.
Cyber Physical Systems and Digital Twin, or the Asset Administration Shall as definition of the Digital Twin in the initiative “Industrie 4.0” are means to perform smart manufacturing [8,9,10]. Considering the above mentioned value creation processes the interoperability has to provide specific requirements which go beyond the state of the art interoperability concepts and methods in the todays automation technology.
The main and most important requirement is, that the interoperability has to work cross different technologies along the life cycle. The current interoperability use cases and means are bounded to one certain technology. For example fieldbus profiles are valid for one fieldbus system only. OPC US companion Specifications are working among OPC UA client/server or publisher/subscriber environments. Or take another example. The exchange between engineering tools using AutomationML is working only if all tool has according AutomationML import and export filter. Although, the AutomationML mapping into OPC UA provides access to the data, the AutomationML data are type data not related to the instance data of a certain components which are described in the system unit class. The data flow along the life cycle of devices, machines and plants starts from construction and catalog data along specific data during commissioning and operational and maintenance data. Along these path there are several technologies both for the representation of the data itself as well as for the data exchange among the tool and components.
-
CPS needs cross technology interoperability
From this top requirement several requirements can be derived. One has to be kept in mind that it is always spoken about machine interpretable information processing. These are:
-
Data have to be identifiable along the life cycle
-
The project SemAn40 has shown, that the property model according to IEC 61360 as used in eCl@ss and IEC CDD is suitable to provide these seamless identification [xx]
-
-
The relation between types and instances have to be possible among different life cycle phases and different technologies
-
For example, property types in catalogs are related to the instance values of the same property. May be the catalog provides a certain range of the property (manual sold together with the product to the customer), the instance has one current value.
-
-
There have to be relations between models representing one type and related instances in different life cycle phases and knowledge domains
-
For example, property types in catalogs are related to the instance values of the same property. May be the catalog provides a certain range of the property (manual sold together with the product to the customer), the instance has one current value.
-
-
One data element can occupy different roles in a scenario and has to be able to be distinguished
-
E.g. it can be that the value of a property is a requirement of a requesting partner and from the interaction partner it is an assurance and it can be a current value during operation (for example a certain the voltage of the electric power supply is requested (24 V), a voltage between 12 to 48 V (may be in steps) is assured and the current voltage is 23.8 V)
-
The reminder of the paper is structured as followed. Section 3 describe the general interoperability concept where the levels and their content are described. Section 4 focus on some aspects two of the interoperability levels, the semantical and organizational interoperability. The mapping of selected technologies to the interoperability levels is focus of Sect. 5. This section includes a short introduction of AAS in order to integrate the AAS into this mapping as well. A summary concludes this paper.
3 General Interoperability Concept
The general concept assumes that there are messages between the components of an CPS. Messages are part of a semantic protocol, an interface or part of an application layer service (Fig. 2).
As introduced in Sect. 1 there are several interoperability layers. In Fig. 4 the interoperability levels are shown more in detail.
Technical interoperability represents the transport of the messages. The ISO/OSI Reference Model provides the abstract view to the communication means.
The structure of the messages as well as the notation of the content, i.e. the coding of the content using different textual, semi-formal or binary formats are the means for the syntactical interoperability. This layer provides the remedy for the machine-readability of the messages and their content.
The application is a huge field which is comprising algorithms, rules, functions and other behavior representations. The system theory name this abstractly “system function”. It’s the nature of the beast that the implementation of the application is out of the scope of each standardization. Therefore, the projection of the application functions in the accessible part of the CPS component is considered and represented as semantic interoperability.
The projection has the following challenge. A message from a sender to a receiver has the intention that a certain application function at the receiver is triggered. This can be an easy read of a variable value or a complex function such as calibration of a device, the reference turn of a mechanical component or an optimization process. This means that the intension of the sender has to be identified and mapped to the internal not visible application implementation at the receiver. Therefore, the projection of the application function is part of the common agreement between the sender and the receiver. The semantic protocol [5] and [6] is one of the means to define this common agreement. This is symbolized in Fig. 4 in the top right of the figure. It is also seen that the data (represented by the data base) in the application is related by the states of the semantic protocols.
A CPS forms an application organization. These organizations can be hierarchical, a fully distributed network, a decentralized structure and others more. In an organization, roles, role relationships and their related type of interaction are defined and made clear to everyone. Organizational interoperability defines cross-system processes and establishes common concepts of roles and relationships. As a result, they characterize the different semantic interaction protocols (vertical, horizontal, etc.) (Fig. 3).
The technical interoperability is the prerequisite of the syntactical interoperability because the messages have to be transported before it can be read. The syntactical interoperability is a prerequisite for the semantical interoperability because only if the data can be decoded (de-serialized) it can be forwarded to the interpretation and at least to the application functions. The interpretation of the messages and their content is the task, which has to be considered by the semantical interoperability. The character of the semantic protocols is formed by the design of the organizational structure and the processes in the business chain of the system.
4 State of the Art of the Interoperability Levels
4.1 Technical and Syntactical Interoperability Levels
These two aspects are a matter of the state of the art. Conformance to the specifications are usually guaranteed by tests of the related implementations. Some organizations grant a related certificate, e.g. OPC Foundation, PROFIBUS User Organisation (PNO) or ODVA. Interoperability is addressed either by testbeds where system under test (SUT) are integrated in typical system configurations or at so called “plugfest”. These means are appropriate for technical and syntactical interoperability.
4.2 Semantical Interoperability Level
As described in Sect. 3 the projection of application functions is the accessible part of the functions of the CPS components. The number and details of application functions and their data are as rich as there are devices, components, machines and plants in industrial production systems. The CPS components follows the goal to represent these variety in a way that software systems can interpret the messages and data and invoke the appropriate application functions. Therefore, the CPS components offers means to model the application in a clear and distinct way. As true for all models the projection of the applications to the CPS component model is a simplification and a shortage of the full behavior and features of the application functions. However, in some applications a simpler model meet the necessary requirements and in other a representation very near to the original system behavior is necessary. Table 1 gives an overview with pros and cons about common model types which are used to project application functions.
We want to select the Variable example in Table 1 as application function model to describe the semantic challenge. Function call and function block are well known interface concepts and are not further described here. The semantic protocol is described in [5] and [6].
In legacy systems the usage of variables in interfaces is a very frequently used projection of mostly simple application functions and therefore described in Fig. 5. Assuming that a device offers the function to indicate threshold crossings of a certain dynamic variable. This is e.g. often provided for measurement data which can cross alarm or warning threshold. Figure 5 shows that the yellow signal regime is crossing the thresholds several time. Inside the related system there is the function which checks if the dynamic variable is greater than the threshold in a periodic cycle. If so, an alarm is fired. The interface provides initially the threshold variable only. Not direct seen is the event which carries the result of the threshold check function. If a human read that a certain variable is a threshold, he/she understand that there is this function behind. From a semantic interoperability point of view this variable together with an event mechanism represents an application function – a threshold supervision function. It is not fully described by the single variable and their attributes. A semantic reference to an according standardized function has to be designed. This includes the abstract description of the threshold supervision function with all inputs and outputs. This example stands for a variety of application functions with simplified interface projections (Fig. 4).
Similar to the described threshold supervision function the other function models such as operation, function block and semantic protocol have to be unambiguously identified with a related semantic reference. This is a necessary precondition for semantic interoperability in terms of machine interpretable CPS component interaction.
4.3 Organizational Interoperability Level
A system as shown in Fig. 3 needs a business process for the overall application. Each CPS component contributes to this application and takes its role or even more then one role. The requirements are coming from the value chain of the business processes as described in Sect. 1 and Fig. 1. Choreography or orchestration are two general concepts to build the business process mostly used in the service oriented architecture. They distinguish each other in the entity where the control logic is deployed. The orchestration approach is a centralized one, where the overall control is implemented in one entity which controls the other ones. Choreography do not have this centralized control entity. The choreography is the result of the activities of the distributed proactive components. The sequence of messages among the components are controlled by the behavior of the contributing components. This performs the business process.
The organizational interoperability level defines the paradigms for the control of the business processes. These have to be clear for the contributing CPS components because they have either to react in the orchestration type of control or be proactive in the choreography type of control or related to different roles in the business process in a mixed way.
This has strong impact to the interoperability. One single service, such as a read of a variable (orchestration) can be the matter of the external visible part of the application or a sequence of messages in a specific dialog has to be carried out (choreography). The interoperability is only possible if each component for each role is clearly defined for all CPS components, it has to play in the overall business process. We call this semantic protocol whose requirement is derived from the business process. This means that the organizational interoperability level defines the types and selection of semantic protocols for each path in the business process.
Reflecting the life cycle of the devices, components, machines and plants and their entire engineering processes this means that organizational interoperability has to be assured from the master data, product data and catalog data over their transportation to the users and the ERP integration to the MES, control and maintenance and optimization applications. The project SemAnz40 [3] and [4] has shown the contribution of the property model and their integration in the so-called Product, Process, Resource (PPR) model. It has assumed that all data are located in a single data repository (in this project structured according to AutomationML). The dedicated tools for the engineering tasks have to interact with this data repository. The engineering steps are driven by the engineers using the tools. If parts of these engineering business processes have to be driven by machine or tool to machine or tool interaction the machines and tools have to become part of the organizational interoperability. One single standalone standard as AutomationML, OPC UA or STEP cannot lead to a seamless engineering and operation application.
5 Relation Between Technologies and Interoperability Levels
5.1 Interoperability Aspects of Asset Administration Shells
The Industrie 4.0 initiative, in particular with the definition of the I4.0 components and the administration shell (German: Verwaltungsschale, VWS for short, English: Asset Administration Shell, AAS for short) has set itself the task of enabling interoperable data exchange and interaction across life cycle processes along the value creation processes. I4.0 components each consist of an asset and its digital twin, in the form of a so-called administration shell. The core of the existing concepts of the administration shell are standardized information models, the so-called sub-models. These information models describe the properties and functionalities of assets. The AAS can be offered in three different forms (Fig. 6). The passive AAS is mainly used when catalog data is given with the products. Exchange forms are e. g. JSON, a special XML schema, AutomationML and rdf. The reactive AAS provides the classic client/server interface. Here a REST or OPC UA server presents the data in the defined syntax. The proactive AAS represents I4.0 components that have decision-making skills in the sense of autonomous systems. A corresponding I4.0 language is available for this, which has been defined in VDI/VDE 2193. For more details see [2]. All forms of representation have the same meta-information model. This enables interoperable data usage across lifecycles (Fig. 5).
In addition to the different representations as shown in Fig. 6 AAS have a range of potential content and software implementations as follows. Figure 7 shows these range.
-
a range of model elements which are partial optional ➔ AAS Specification
-
different serialization formats based on related serialization schemes ➔ Schema specification and AAS serialization instances, i.e. passive AAS
-
different technologies for the design and implementation of interfaces ➔ AAS server (reactive) and AAS with I4.0 Language (proactive, VDI2193)
-
different mappings to communication systems
-
different infrastructure means
-
security means which are cross level defined for the AAS model elements as well as for individual aspects
-
different locations where the AAS, submodels or concept descriptions can reside
These large variety of AAS is necessary to meet the different requirements of the intended lifecycle (see Sect. 1).
This offers a wide range of individual AAS instances. In practice AAS instances are interoperable if the implemented model subset, implementation technologies and technology features match to the AAS or applications they want to interact with. This can be organized while defined profiles for the different aspects (Fig. 8). This reduces the effort to identify or engineer which AAS can interact with whom.
5.2 Mapping of Selected Technologies into Interoperability Levels
Different technologies provide different ranges of the interoperability levels.
MQTT is a transport protocol with no relation to the content it transfers. There is an endpoint (an inbox) only at the destination. Therefore, it supports communication, i.e. technical interoperability only. This has to include the security means of the AAS model.
http/Rest is a transport protocol as well and addresses the AAS model elements in details. This need the syntactical aspects of the AAS as well. The rest services address the endpoints but have no additional interpretation means such as data type, ranges, … Therefore, the are no sematic aspects in this technology.
OPC UA covers communication services and protocols, syntactical aspects (OPC UA I4AAS Companion Specification) and partly application related semantic aspects. Examples ae the method call or the event mechanisms.
The AAS with semantic protocols using the I4.0 language (VDI/VDE 2193) considers semantic of the AAS in terms of interpreting the intended meaning of the sender in extension to read, write and event. It is application depended and defined in the interaction pattern among the CPS components along the business processes.
The content of the AAS can be imported out of the different serializations of the AAS model. All technology mappings are based on the syntactical and semantical AAS model defined in [1].
6 Summary
Interoperability is a need for the ongoing digitization of the industry processes. State of the art is, that the interoperability is focused (1) on technical and syntactical and beginning to semantic interoperability only and (2) to one specific interface or data exchange technology only to fulfill selected use cases. It become visible that interoperable applications have to work cross technology, cross life cycle phases and cross business partners. This paper describes different levels of interoperability, their characteristics and their relation to the existing technologies. These technologies built the basement of the all over interoperability. The Asset Administration Shell is introduced to build the umbrella for the seamless interoperability for the lifecycle business processes.
References
Bundesministerium für Wirtschaft und Energie (BMWi) (Herausgeber): Specification Details of the Administration Shell – Part 1: The exchange of information between partners in the value chain of Industrie 4.0; Version 2.0.1 Federal Ministry for Economic Affairs and Energy (BMWi). Plattform Industrie 4.0, Berlin 2019. https://www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/Details-of-the-Asset-Administration-Shell-Part1.html
Bundesministerium für Wirtschaft und Energie (BMWi) (Herausgeber): I4.0 Sprache. Diskussionspapier Plattform I4.0. April 2018.
André Scholz, Constantin Hildebrandt, Alexander Fay, Tizian Schröder, Thomas Hadlich, Christian Diedrich, Martin Dubovy, Christian Eck, Ralf Wiegand: Semantische Inhalte für Industrie 4.0 – Semantisch interpretierbare Modellierung von technischen Systemen in kollaborativen Umgebungen. atp edition, [S.l.], v. 59, n. 07–08, p. 34–43, sep. 2017. ISSN 2364–3137.
Constantin Hildebrandt, André Scholz, Alexander Fay, Tizian Schröder, Thomas Hadlich, Christian Diedrich, Martin Dubovy, Christian Eck, Ralf Wiegand: Semantic Modeling for Collaboration and Cooperation of Systems in the Production Domain. Emerging Technologies And Factory Automation, At Limassol, Cyprus, Volume: 22nd
Tizian Schröder, Jürgen Bock : Modellierungsansätze für semantische Interoperabilität in industriellen IT-Systemen – Verknüpfung von ontologiebasierten und interaktionsbezogenen Semantikkonzepten. at automatiseirungstechnik. Sonderheft zur EKA 2020.
Johannes Reich, Tizian Schröder: A simple classification of discrete system interactions and some consequences for the solution of the interoperability puzzle. IFAC World Congress 2020. Online proceedings.
Bock, Jürgen, Malakuti, Somayeh, Boss; Birgit, Bayha, Andreas; Diedrich, Christian: Describing Capabilities of Industrie 4.0 Components. Joint Whitepaper between Plattform Industrie 4.0, VDI GMA 7.20, BaSys 4.2. Still in publishing process 2020.
Bundesministerium für Wirtschaft und Energie (BMWi) (Herausgeber). Plattform I4.0 Text and Editing: Aspekte der Forschungsroadmap in den Anwendungsszenarien – Ergebnispapier. April 2016.
Fei Taoa, Qinglin Qi, Lihui Wang, A.Y.C. Nee: Digital Twins and Cyber–Physical Systems toward Smart Manufacturing and Industry 4.0: Correlation and Comparison. Engineering Volume 5, Issue 4, August 2019, Pages 653–66. Elsevier. https://doi.org/10.1016/j.eng.2019.01.014
Yao, X., Zhou, J., Lin, Y., Li, Y., Yu, H. and Liu, Y. (2017) Smart manufacturing based on cyber-physical systems and beyond. Journal of Intelligent Manufacturing,(doi:https://doi.org/10.1007/s10845-017-1384-5).
Christian Diedrich et al.: Semantic interoperability: Challenges in the digital transformation age. IEC White Paper 2019. (https://www.iec.ch/whitepaper/)
Zeid A, Sundaram S, Moghaddam M, Kamarthi S, Marion T (2019) Interoperability in Smart Manufacturing: Research Challenges. Mach Des 7:21. https://doi.org/10.3390/machines7020021
Bundesministerium für Wirtschaft und Energie (BMWi) (Herausgeber). Plattform I4.0 Text and Editing: Aspekte der Forschungsroadmap in den Anwendungsszenarien – Ergebnispapier. April 2016.
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
Copyright information
© 2022 Der/die Autor(en)
About this paper
Cite this paper
Diedrich, C., Schröder, T., Belyaev, A. (2022). Interoperabilität von Cyber Physical Systems. In: Jasperneite, J., Lohweg, V. (eds) Kommunikation und Bildverarbeitung in der Automation. Technologien für die intelligente Automation, vol 14. Springer Vieweg, Berlin, Heidelberg. https://doi.org/10.1007/978-3-662-64283-2_8
Download citation
DOI: https://doi.org/10.1007/978-3-662-64283-2_8
Published:
Publisher Name: Springer Vieweg, Berlin, Heidelberg
Print ISBN: 978-3-662-64282-5
Online ISBN: 978-3-662-64283-2
eBook Packages: Computer Science and Engineering (German Language)