Toward Data Interoperability of Enterprise and Control Applications via The Industry 4.0 Asset Administration Shell

In a cyber-physical system, enterprise applications, control functions, and physical manufacturing assets are interconnected to seamlessly exchange information. However, the software and hardware often differ in terms of their data interfaces, data formats and semantics. Conventional enterprise applications usually employ file-based interfaces (e.g., Excel); control applications always support Ethernet-based protocols (e.g., OPC UA). Thus, data interoperability is currently lacking. The asset administration shell (AAS) is a new approach for achieving data interoperability across the automation pyramid as the AASX data format represents AAS information and supports data communication via OPC UA. In this study, we first provide insights into the AASX format and give exemplary applications on AASX; we then present an AASX-based solution for bidirectional data exchange between enterprise and control applications. In this solution, the conversion between AASX and Excel spreadsheets is completed to enable interoperable data exchange. Finally, a data exchange scenario for motor control is constructed to validate the effectiveness of the solution. The result shows no data were lost during the two-way conversions.

example of the DT, can make data discoverable, identifiable and accessible, thus facilitating interoperability among the applications of a manufacturing company [9] [10]. AASX is a package file format for representing an AAS. An AASX interface for field hardware assets was developed previously [24]. Here, we focus on the data interconnections between highand mid-level control applications. As explained above, existing enterprise applications usually employ file-based methods (e.g., an Excel spreadsheet) to exchange information, whereas control applications always support Ethernet-based protocols (e.g., OPC UA). AASX can support data communication via OPC UA. Hence, the goal of this study is to present an AASX-based solution that allows bidirectional, lossless information exchange between enterprise and control applications. The information semantics are implemented in the AASX to ensure data interoperability.
Therefore, the main contributions of this paper are as follows:  We review state-of-the-art research on AASX using several approaches to AASX implementation as examples.  We present an AASX-based data exchange solution that connects enterprise-and control-level applications.  Our solution guarantees bidirectional, lossless data conversion between AASX and Excel.  We use a test case to validate the feasibility of our solution.  We find that AASX serves as an intermediary in terms of data exchange, thus effectively eliminating the data siloes that keep enterprise and control applications separate.
The rest of the paper is organized as follows. Section II gives key background knowledge on AAS and AASX. Section III describes state-of-the-art data exchange solutions. Section IV introduces our AASX-based data exchange solution and details the data conversion between AASX and Excel. Section V describes the test case (with the data conversion results). Section VI draws conclusions and describes our planned future work.

II. BACKGROUND ON AAS AND AASX
As shown in Figure 1, an AAS is a standardized digital representation of an asset with industrial applications that allows uniform access to information and functions, thereby facilitating interoperability among the applications of a manufacturing company [11]. An AAS offers an interoperable way to capture key information on assets, including their intrinsic properties, operational parameters, and technical functionalities; and enables straightforward interactions over standardized and secure communication links with other Industry 4.0 components [12].
The structure of an AAS is defined in Part 1 of the AAS specification [13]. As shown in Figure 2(a), the AAS metamodel has a 'Submodel' that defines a specific aspect of 'AssetInformation'.
The 'Submodel' contains the 'SubmodelElement' that orchestrates asset information into, for example, a 'Property'. The 'Property' definition is linked to that of 'ConceptDescription', which references a semantic 'DataSpecification' such as the common data dictionary (CDD) [14] or ECLASS [15]. AAS model elements allow several types of identifiers (IDs), including internationalized resource identifiers (IRIs), international registration data identifiers (IRDIs), and custom IDs; these identify elements within a single AAS, or in an AAS network within (or extending beyond) a company, depending on the purpose.
Currently, an AAS is considered as a promising concept within the Industry 4.0 initiative. Information and communication technologies promote practical usage of AASs.

VOLUME XX, 2020
State-of-the-art studies on AASs in academia and industry generally focus on specific cases [16][17][18]; methods of AAS implementation differ [19][20][21]. AutomationML, OPC UA, and web ontology languages such as the resource description framework (RDF) have been employed. A standardized guideline (or consensus technical approach) is urgently required for AAS implementation.
As shown in Figure 2(b), in line with the AAS meta-model, the AASX file encapsulates AAS information including the AAS itself, the submodel element, the property, a concept description, and supplementary files, in a structurally robust manner. Compared to existing engineering approaches to data interoperability (e.g., AutomationML), the AASX not only connects to field-level hardware assets (e.g., motors), but also enables data integration into enterprise-level applications (e.g., ERP) and promotes data transmission between such software applications. Unambiguous data semantics are guaranteed; all hardware and software of an entire automation pyramid can be interconnected in a networked and non-hierarchical system, allowing information exchange via uniform AASX interfaces. As shown in Figure 3, field hardware, control software, and enterprise and management applications can be connected to an intermediate AASX interface, although their data interfaces vary.
The Industrial Digital Twin Association (IDTA) has developed a series of AASX-based open-source applications that can create, edit, and view AAS information [22]. These applications allow users to obtain an intuitive understanding of how an AAS is structured, and information accessed and exchanged. The applications have different AAS data access methods, all of which are in line with Parts 1 and 2 [23] of the AAS specification. Below, we summarize two key applications, the first of which is an AASX package explorer. This C#-based AAS editor manipulates AASX information and implements several application programming interfaces (APIs), including  representational state transfer (REST), message queuing telemetry transport (MQTT), and OPC UA. These APIs allow other applications to access AASX information. Security mechanisms (e.g., token-based authentication) are also embedded. As shown in Figure 4, an asset and its AAS information, as shown in an AASX package explorer in Figure  4(a), can be accessed and browsed by an OPC UA client (e.g., UaExpert) [ Figure 4(b)]; the information can also be selectively accessed via the REST interface by a web browser. The result (e.g., the submodel data) is shown in a JSON file in Figure 4(c).
The second application, i.e., an AASX server, is derived from the AASX package explorer. The AASX server is a C#-based program that implements a server hosting AAS information (an AASX model). The AASX server can be accessed via the REST, MQTT, and OPC UA protocols; secure access is guaranteed.
However, these two programs work on only high-level devices such as personal computers. Prior to integration into user-specific applications and deployment over resourceconstrained devices, the AASX model must first be converted into a machine-interpretable data format, such as extensible markup language (XML) or JavaScript object notation (JSON). This function is embedded in the AASX package explorer. In our previous study [24], we applied AASX to a robot-based manufacturing system. We mapped runtime data from fieldlevel robots to an AASX model and integrated the model into OPC UA for data communication with web applications in the cloud.
Several open-source projects focusing on AASX implementation are listed in the GitHub repository [22]. For example, the 'java-serializer' project serializes/deserializes JAVA classes into/from AASX instances, while the 'aastransformation-library' project transforms AutomationML models to AASX models; the results are shown in JSON format.

III. STATE-OF-THE-ART
Many researchers have worked on data exchange among industrial applications or engineering tools. For example, automation markup language (AutomationML) is a neutral data format that connects heterogeneous modern engineering tools from different disciplines. AutomationML describes real plant components in different levels of detail [25]. However, data semantics have not received much attention; AutomationML focuses principally on the engineering phase of the plant lifecycle. The MTConnect data exchange standard uses a domainspecific vocabulary to devise data models of factory shop-floor equipment [26]. However, MTConnect is a read-only protocol employed principally to monitor data from machine tool components. Therefore, both AutomationML and MTConnect could not prove the data interoperability between different applications.
In academic research, AASX is widely used as a data representation and exchange format for AASs. It is highly likely that AASX will become an official data format for AASs. IEC project 63278-1 aims to develop an international standard of AAS [11], while another study [27] described a lightweight software framework (in line with AAS specifications) for implementation of an AAS; AASX was used to show such an implementation. Finally, open-source solutions for AAS implementation were comprehensively analyzed and a method by which an AASX-based AAS could be implemented into an embedded device was presented, dramatically reducing the computational requirement [28]. However, above studies only concentrated on AASX itself rather on data exchange scenarios between applications using AASX.
Only a few studies focused on proposing AASX-enabled data exchange solutions. For example, one study [29] developed an AAS model for two different software tools; AASX was employed for integration, while another [30] mapped the proprietary ABB Ability information model to the standard AAS information model using AASX. In [31], AASX was used to develop a data AAS for managing cross-enterprise engineering data sets. These studies promote the adoption of AASX for solving various data interoperability problems. However, it is of great significance to design a general AASX-enabled data interoperability solution, which not only enables consistent data exchange between enterprise and control applications but also extends to the control of field devices.

IV. AASX DATA EXCHANGE METHOD FOR ENTERPRISE AND CONTROL APPLICATIONS
We first present the data exchange challenge facing the enterprise and control applications, then propose a solution for data conversion between AASX and Excel, and finally detail data conversion steps.

A. THE PROBLEM
Consider the following manufacturing scenario. Field devices perform specific tasks and generate large amounts of production data. Control systems transmit the collected data to enterprise applications for analysis. The enterprise applications then create a manufacturing schedule and instruct the control systems to handle the new production task that the field devices will perform. Such two-way information exchange lacks consistent data exchange between the enterprise applications and control systems because enterprise-level applications usually use filebased interfaces, such as Excel, whereas control-level systems employ industrial communication interfaces such as OPC UA. AASX can support data communication via OPC UA; the AASX data format can serve as an intermediary between enterprise applications and control systems. The only remaining challenge is data conversion between AASX and Excel.

B. THE SOLUTION
The entire two-way information exchange in the above scenario is shown in Figure 5. We designed an AASX solution permitting two-way information exchange. The AASX solution is implemented as follows. Working from the bottom up, all field asset information and data collected by the control systems are first converted into an AASX file using AASX package explorer. Then, a web-converting tool [32] is used for data conversion from the AASX file to Excel. Finally, the Excel file is imported into the enterprise applications. From the top down, the tool converts Excel data into AASX format. Here, we focus on data conversion because we achieved AASX data communication via OPC UA in our previous publication [24]; moreover, Excel file importation/exportation is within the scope of specific industrial enterprise-level applications, so is not considered here. Figure 6 shows the data conversion process between AASX and Excel, also the design process of the web-converting tool. The requirement of designing the solution is realizing the bidirectional and lossless data conversion between the source and destination. The tool has two independent parsing programs written in Python. One tool parses the AASX model (a JSON file) and generates a well-formatted Excel file, and the other performs the opposite function. The two Python programs have been deposited in the GitHub repository [33].

1) AASX to Excel
As shown in the upper part of Figure 6, first, an AASX file (No. 1 in Figure 6) is prepared using the AASX package explorer. This file must be validated using the modeling rules of the AASX package explorer; otherwise, warnings or error messages will pop up. Second, the AASX file is exported as a JSON file (No. 2), which is supported in AASX package explorer. Third, the JSON file is uploaded to the web-converting tool that deserializes JSON data to Python objects. Finally, the Python program outputs an Excel file (No. 3) based on a prespecified Excel template (No. 4) that has a hierarchical structure for storage of parsed AASX information. In the third step, the tool parses every element of the AASX model in the JSON file.

2) Excel to AASX
This inverse procedure can be briefly described as follows. As shown at the bottom of Figure 6, the Excel template is filled with data from the enterprise applications. Then, the Excel file (No. 5) is uploaded to the web tool for conversion. Python parses the Excel file, engages in serialization, and outputs the result to a JSON file (No. 6). Finally, the AASX package explorer loads the JSON file and saves AASX information as an AASX file (No. 7). Note that the tool can only handle files that meet the requirements of the prespecified Excel template.

V. TEST CASE: MOTOR CONTROL
Given the manufacturing scenario described in section III, we now give an example of real data exchange between a motor control system and enterprise application. We examine the AASX solution and show lossless data conversion between AASX and Excel. We do not develop enterprise or motor control applications.

A. THE DATA EXCHANGE SCENARIO
The data exchange scenario for motor control is shown in Figure 7. After a specific motor operation, the control system must send the operation data of the motor (e.g., rotation speed) to the enterprise application; enterprise collects the data, analyzes it, and sends a new command (e.g., control mode) to the motor control system. A new task can then be performed by the motor. Detailed AASX model information are introduced in the following.   Figure 8 shows the model of motor control system in AASX package explorer. The AASX model serves as a benchmarking file in our example of data exchange. The file contains all AAS information that will be exchanged between the enterprise application and motor control system. Our AASX model was created based on the official AASX example provided by IDTA, which illustrates every discipline/rule that users must follow to create their own AASX models. We adopt this AASX example because it is both elaborate and comprehensive, and allows us to validate the effectiveness of our data conversion solution.

B. THE AASX MODEL
As shown at the top of Figure 8, the AASX model describes an AAS 'ExampleMotor' for the asset 'ServoDCMotor'. The AAS contains five well-defined submodels that describe the properties and capacities of motors used in different disciplines. 'Identification' contains supplier information (e.g., the name of the manufacturer). 'TechnicalData' defines the technical parameters of the motor (e.g., the maximum torque). 'OperationalData' contains the runtime parameters of the motor (e.g., the rotation speed). 'Documentation' stores and classifies the documents of an asset (e.g., the operation manual). The above four submodels are indispensable for describing an asset. The last submodel, 'EnterpriseData', is customized for the motor control scenario, which contains a ' SubmodelEelement' or 'Property' termed 'ControlMode'; the enterprise user employs this to control motor operation.
The bottom half of Figure 8 shows the detailed attributes of 'ControlMode' (e.g., the semantic ID and contents). The semantic ID links the 'SubmodelElement' to its definition (e.g., 'ConceptDescription').
Moreover, 'ConceptDescription' contains semantic descriptions of the 'SubmodelElement'; it is possible to refer to semantic 'DataSpecifications' (i.e., data standards such as ECLASS and IEC 61360 that allow for formal, common, and unambiguous definitions of properties). If no appropriate definition can be found in the standards, users can create and reference a public 'DataSpecification' by extending IEC 61360. The property should have the data value and value type. Supplementary files attached to the AASX model do not need to be converted, and are not worked on by the conversion tool.

C. DATA EXCHANGE RESULT
The data exchange results of the motor control scenario are shown in Figure 9. From AASX to Excel, the example AASX model is first exported to a JSON file. Figure 9(a) shows an extract of the Excel file converted from the JSON file; the extract contains the motor's AAS, submodels, and properties. This Excel file can be further imported into enterprise applications. On the other hand, when converting from Excel to AASX, we use the Excel file generated in the first round as the input. Figure  9(b) shows an extract of the JSON file converted from the Excel file. This JSON data block contains information on the motor's AAS submodel 'EnterpriseData'. The JSON file can be imported and displayed in the AASX package explorer.
We compared the generated JSON file to the original JSON file exported from the AASX model, and found no data loss after the two-way conversion. Thus, the two AASX models (before and after the conversions) are identical. This proves the validity of our conversion tool, and the feasibility of our AASX solution for lossless data exchange between enterprise and control applications. All files have been uploaded to the GitHub repository [34] and are freely available.  To ensure successful conversion using the online converting tool, certain rules must be followed when preparing the AASX file. For example, both the value type and initial value of a property must be assigned. The property in the submodel must be mapped to the corresponding 'ConceptDescription', and the definition of the 'ConceptDescription' must not be empty.

VI. CONCLUSIONS AND FUTURE WORK
In terms of the data interoperability required by Industry 4.0, the AAS is emerging as a digitalized approach that enables intimate interactions between cyber applications and physical devices. Given a uniform AAS interface, all manufacturing components (hardware devices and software applications) can be interconnected. In a fully integrated system, enterprise applications and manufacturing functions are aligned for efficient data flow. However, existing research has paid little attention to the semantic aspects of information exchange. To ensure robust data exchange between enterprise and control applications, we describe data conversion between AASX and Excel; the latter is generally used to manage the business-related data of enterprise applications. AASX is an Industry 4.0 AAScompliant data representation format supporting data communication with field-level manufacturing assets via OPC UA, for example. Moreover, appropriate semantic descriptions of information are provided by the AASX model, which can reference data standards such as IEC 61360. Therefore, data interoperability between enterprise and control applications is guaranteed if bidirectional lossless conversion between AASX and Excel is possible.
We validated our data conversion solution using a motor control scenario. We developed an AASX model for motor control based on the AASX file provided by IDTA. No data were lost during the two-way conversions. We focused on data conversion, and are not aiming to develop enterprise or control applications at present. Although our case study is simple, it proves the effectiveness of our AASX-based data conversion method. One limitation of the current solution is that the data conversion is completed by human operators. In future, we will develop an automatic converting solution which can support runtime data conversion. We will also apply the method to enterprise and control applications in real industries. Conversion between AASX and other data formats, such as IEC 62264 Business to Manufacturing Markup Language (B2MML) [35], will also be explored for two organizations to exchange business information.