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.

Fig. 1
figure 1

Life cycle of Cyber Physical Systems

Full size image

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).

Fig. 2
figure 2

Basic assumption: Applications are exchanging messages

Full size image

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).

Fig. 3
figure 3

Assignment of technologies and models to the interoperability layers

Full size image

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.

Table 1 Advantages and Disadvantages of Different Types of application function models in a CPS Component (based on [7])
Full size table

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).

Fig. 4
figure 4

Variable as modelling element for an application function

Full size image

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).

Fig. 5
figure 5

Representation of AAS

Full size image

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).

Fig. 6
figure 6

The AAS range

Full size image
Fig. 7
figure 7

AAS profiles

Full size image

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.

Fig. 8
figure 8

Technology relations to interoperability levels and placement of semantic protocols

Full size image

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.