An Industry 4.0 Asset Administration Shell-Enabled Digital Solution for Robot-Based Manufacturing Systems

The increasing penetration of cyber-physical system (CPS) technologies in industry is transforming this environment into a multifaceted system featuring a tight combination of its physical and computational elements, including their digital (virtual) representations, contributing to the concept of an industrial CPS. The German “Industry 4.0” is a key innovation program aimed at realizing industrial CPS. Industry 4.0 is characterized by digital industrial components interacting with each other to become systems meeting flexible industrial demands, e.g., order-controlled production. An asset administration shell (AAS), as defined in the context of the Reference Architectural Model for Industry 4.0 (RAMI 4.0), is a practical embodiment of the latest buzzword, digital twin, and can be realized with the integration of operation technologies and information and communication technologies. AASs offer an interoperable way to capture key information pertaining to assets, such as intrinsic properties, operational parameters, and technical functionalities, and to enable straightforward interaction over standardized, secure communication with other Industry 4.0 components. The goal of this article is to present the status quo of AAS development, to design an intuitive method for implementing AASs, and to develop an AAS-enabled digital solution for cyber-physical applications in the manufacturing sector. Last but not least, we demonstrate a case study featuring an Industry 4.0 application scenario, i.e., plug-and-produce.


I. INTRODUCTION
The cyber-physical system (CPS) is an emergent approach that is perceived as enabling the integration of computational applications with physical devices through its design as a network of tight interactions between cyber and physical elements [1]. Applying CPSs to industrial infrastructures involves the combination of office-floor information and communication technologies and shop-floor operation technologies to control distributed physical production processes and systems, resulting in the formation of a so-called industrial CPS (ICPS) [2]. ICPSs in the context of manufacturing can be considered smart production systems, where The associate editor coordinating the review of this manuscript and approving it for publication was Claudio Zunino .
interactive software and hardware are becoming increasingly intertwined. Moreover, many ICPSs have a highlevel decision-making capability, which can be deployed to support, improve, or automate production processes such as scheduling and maintenance [3]. Therefore, ICPSs are expected to empower the transformation of industry and business at large to a digital, networked, adaptable, and knowledge-based industry with significant long-term impacts on the economy, society, the environment, and individual citizens [4].
In the era of Industry 4.0, digitalization is frequently proposed as a prerequisite for facilitating information (data) exchange throughout the production system lifecycle [5]. Manufacturing assets such as sensors, robots, and machines from different manufacturers or suppliers often generate a massive volume of data during production activities. Hence, it requires significant effort for the system integrator or plant operator to integrate this data into a higher enterprise level and then conduct a decision-making process therein [6]. Furthermore, data homogeneity, i.e., a consistent semantic form of production data that is comprehensible to all users, is necessary to address the needs of all value chain participants equally, provided it makes data easy to acquire and simultaneously provides the possibility of selectively accessing particular information [7]. On account of these two aspects, industry needs a digital transformation solution that can assist effortless data integration, provide comprehensive semantic data homogenization, and convey contextual information, while also allowing full access control to each data package [8].
Of late, deploying digital twins (DTs) for on-site manufacturing resources is emerging as an endeavor aimed at realizing the digitalization goal [9], [10]. The term DT is not precisely defined and is currently interpreted in different ways in industry. It is primarily used to characterize the digital replica of an asset with all the information relevant for a specific engineering activity, e.g., the simulation of exceptional loads or the design of a component in system planning [7]. A DT barely exists as a theoretical concept, whereas an asset administration shell (AAS), first proposed in German ''Industry 4.0'' initiative, is a practical and standardized approach for implementing DTs.
As defined by the International Electrotechnical Commission (IEC) Technical Committee 65 Working Group 24, an AAS is a standardized digital representation of an asset for industrial applications, giving uniform access to information and functions, and thereby facilitating interoperability among the applications of a manufacturing company [11]. As shown in Figure 1, an AAS helps transform raw data from physical assets into digital comprehensible information for stakeholders, such as domain experts and system developers. An asset with a proprietary communication interface (e.g., PROFIBUS) is presented with a uniform application programming interface (API), through which the asset data can be accessed in the form of an AAS. Part 1 of the specification ''Details of the Asset Administration Shell'' (abbreviated to ''AAS Specification'') [12] published by Plattform Industrie 4.0 describes the meta-model for specifying information in an AAS. Figure 2 shows an extract from the AAS meta-model. The AAS meta-model features a Submodel that defines a specific aspect of the AssetInformation. The Submodel contains a SubmodelElement that orchestrates the asset information as a Property. The Property is uniquely identified by an identifier and has a definition linked to a ConceptDescription, where a semantic DataSpecification, such as IEC 61360's FIGURE 2. An extract from the asset administration shell meta-model [12]. VOLUME 9, 2021 common data dictionary (CDD) [13] or ECLASS [14], can be referenced. Additionally, the AAS meta-model characterizes the concepts of Type and Instance, which distinguish the information regarding different lifecycle phases.
As a standardized implementation of DTs, AASs have the following strengths: 1) They make data discoverable and identifiable, thus breaking down information silos from the very beginning in the field of production.
2) They make data accessible through standardized APIs, thus enabling cross-border interoperability along the value chain.
3) They provide a digital basis for future autonomous systems where intelligent AASs can negotiate and coordinate with each other without human intervention.
Physically, the AAS can locate at different factory levels with regard to the automation hierarchy, e.g., the field or enterprise layer, depending on the computing capability of manufacturing resources. Beginning a couple of years ago, cloud computing has emerged as a major enabler of manufacturing industry [15], [16]. Cloud-and web-enabled services could facilitate the deployment of AASs for data storage, monitoring, and analysis [17]. The contribution of the present study is summarized as follows. We first present a cloud-enabled AAS solution for realizing cyberphysical manufacturing. To be specific, a cluster of AASs are deployed on an edge AAS platform, which acts as a hub for collecting runtime AAS data from miscellaneous assets; high-level AAS applications are developed in the cloud to manipulate the collected data so as to control and schedule the assets.
Second, we conduct a case study to evaluate the designed AAS solution, in which a laboratory-level testbed was demonstrated featuring a plug-and-produce (PnP) manufacturing scenario.
Third, implementation processes of the AAS deployment, the core of the AAS solution, are elaborated using a flow diagram.
Fourth, the AAS solution can be applicable to a variety of manufacturing use cases. Thus, the AAS solution endows existing legacy industrial systems with a capability to become digitalized toward ICPS without updating or replacing equipment entirely.
The remainder of this article is structured as follows. Section II reviews the state-of-the-art research and development activities on AASs. Section III introduces the architecture of the AAS-enabled solution and its detailed technology implementations. A case study of the PnP-capable manufacturing system with the AAS solution implemented is presented in Section IV. Section V gives a critical discussion about AASs and, finally, Section VI gives a conclusion and outlook.

II. STATUS QUO OF THE AAS
There has already been a remarkable research effort dedicated to applying AASs to various use cases of ICPSs. Typically, the potential of AASs has been jointly explored with DTs [45]. In [18], the authors designed a virtual description model for a DT application by inheriting the AAS properties, together with a system demonstration at the level of a workcenter. In [19], the authors presented a mapping solution for transformations between different DT models; an example transformation from an ''ABB Ability'' DT model to the AAS model was illustrated. Likewise, the authors in [20] presented a guideline for transforming the information of AAS submodels between two different disciplines to reduce the modelling effort. Moreover, AAS can be applied in combination with many industrial standards. The work in [21] presented an AAS model that can represent IEC 61131-3 programs and applied it to a programmable logic controller (PLC)-based application. In [22], AAS models were used with IEC 62264, a standard for manufacturing operations management, to orchestrate the assets within system engineering activities. Note that AASs can be deployed not only on production equipment but also on products and people. The study in [23] developed a method to empower a product on the production line with the ability to communicate by integrating an AAS interface; a use case of remotely discharging a product was shown. In [24], the authors designed an AAS model for production workers to communicate with the AASs of production equipment for optimal allocation of the workforce. With regard to data security, blockchain, distributed file system, and version control technology were used in [25], to ensure data sovereignty, i.e., integrity, confidentiality, and availability of information, for the exchange of AAS data across value-added chains.
In [26], the authors specified an AAS template and practically implemented the AAS into a robot-conveyor production system. Further, in [27], they reported state-of-the-art work on AASs ranging from scientific research to commercial solutions; moreover, they also demonstrated a manufacturing use case. The scope of the present article is to complement the AAS research conducted in [26] and [27] by presenting status quo approaches for implementing AASs.
Recognized by Plattform Industrie 4.0, there are currently three types of AAS with regard to the interaction pattern: passive, reactive, and proactive ( Figure 3) [28]. In the case of a passive pattern, the AAS acts as a static file or file package.
Information from assets is stored in the AAS in a uniform data format, e.g., extensible markup language (XML) or JavaScript object notation (JSON). The underlying use case is that this file-based AAS is transmitted among value-chain partners digitally or physically to complete a particular valueadded process. This use case is elaborated in part 1 of the AAS specification. The second, reactive pattern indicates the scenario in which the AAS can exchange information with other AASs or software applications though an API. Such an API can be a web-based protocol, e.g., hypertext transfer protocol (HTTP) and message queuing telemetry transport (MQTT). Usually, this reactive interaction can be implemented through a server-client communication mode. Guidelines on the usage of an API are specified in a technology-neutral way in part 2 of the AAS specification [29]. In the third pattern, AASs are able to interact autonomously with each other via a standardized interface with a common syntax and semantics base, thus realizing peer-to-peer AAS interaction. The specification series VDI/VDE 2193 defines a common language for Industry 4.0 components [30] through which AASs can understand and cooperate with each other. The authors in [46] explored FIGURE 4. The asset administration shell-based architecture for cyber-physical manufacturing. VOLUME 9, 2021 the semantic aspect of this language. An AAS with such autonomy is called a proactive one, as shown in Figure 3.
With regard to practical implementation of an AAS, we do not claim that one specific methodology or technology should be adopted. There are several distinguished research projects summarized in [26], which provide different methods to implement an AAS. Plattform Industrie 4.0 has specified a package file format, AASX, based on the open packaging conventions for representing an AAS [12]. Designed to be in compliance with the AAS meta-model, the AASX file encapsulates the AAS information including AAS model elements, properties, and additional files of any format in a structural way. Within the scope of academic research, AASX is a widely acceptable data representation and exchange format for AASs. AASX has a high possibility of being nominated as an official data format for the AAS currently under development as an international standard in IEC project 63278-1 [11]. In addition, one website [31] has published a series of open-source tools that can be used to create, edit, and view AAS information in the AASX format. Through these tools, AAS beginners, users, and domain experts can gain an intuitive understanding of an AAS's structure and how AAS information is accessed and exchanged. These tools provide different types of data-accessing methods for an AAS, but all follow the AAS specifications (parts 1 and 2). Herein, these approaches are summarized as follows. First, the AASX package explorer is a C#-based AAS editor that provides a series of functions to manipulate the AAS information. It also implements several APIs including representational state transfer (REST), MQTT, and open platform communications united architecture (OPC UA) for other software applications to access the AAS information, while security mechanisms, e.g., token-based authentication, are also embedded. Second, derived from the AASX package explorer, the AASX server is a C#-based program that implements an AAS server that hosts the AAS information (an AASX model). The AASX server can also be connected via REST, MQTT, and OPC UA protocols and secure data access is guaranteed.
However, the aforementioned two tools are only suitable for use on high-level devices, e.g., a personal computer. To be integrated into user-specific applications and deployed on resource-constrained devices, the AASX model needs to be converted into a machine-interpretable data format, such as XML or JSON. As a machine-to-machine communication standard (IEC 62541) for industrial applications, OPC UA can be chosen to exchange AASX data because it integrates several data representation methods, such as XML, JSON, and binary encodings [32]. Until now, there have been few studies focusing on the practical application of AASX with OPC UA. Therefore, this article proposes a method which converts the AASX model into the OPC UA information model to enable the exchange of AAS information at runtime via OPC UA.

III. AAS-ENABLED DIGITAL SOLUTION
This section introduces an AAS-based digital solution for applications in ICPSs. As shown in Figure 4, this solution features a three-layer architecture: field assets, edge AAS deployment, and cloud AAS management. OPC UA is used as a backbone network for the three-layer architecture as it realizes a manufacturer-and platform-independent, protocolagnostic framework for industrial communication [33]. With regard to the ICPS, the field assets layer resides in the physical world while the other two layers belong to the cyber world.

A. ARCHITECTURE
The contents and functions of each architecture layer are illustrated respectively as follows.

1) FIELD ASSETS
This physical world layer contains all field manufacturing assets in a factory. Field assets can be both hardware and software resources, such as sensors, machines, and control logic programs. To connect the physical world of assets to the cyber world of information, each asset of interest should be integrated with a dedicated OPC UA server, thus constituting a field integration bus. This field integration bus serves as a uniform communication interface for connecting various manufacturer-independent assets. Moreover, every OPC UA server contains an information model that describes the asset information including meta-data, function, and configuration information. In this way, the connected field assets are preprocessed to provide a capability for being digitalized, for the cyber world. In other words, they are prepared by exposing information on their capacities and, further, can pass runtime data to their AASs.

2) EDGE AAS DEPLOYMENT
This edge layer serves as an AAS platform that provides a runtime environment for deploying AASs, for all field assets. This means that the AAS model of each asset resides in this layer, and AASs interact and exchange data with one another for realizing application-specific functions. Afterwards, the functional states and condition parameters of the assets are collected as AAS data herein. Specifically, this AAS platform is implemented by developing an AASX-based OPC UA server, whose information model integrates an AASX model containing AASs for the field assets. Additionally, this platform further aggregates the edge interface (OPC UA clients) for connecting with the underlying OPC UA servers developed in the field assets layer. This layer also contains a field data mapping module, which maps the runtime FIGURE 7. Field assets and their layout in the plug-and-produce system. data from assets with corresponding AAS properties in the AASX-based OPC UA aggregation server. This AAS platform can be deployed on an edge device with a particular computing capability. The detailed implementation processes of this AAS platform are provided later in this article.

3) CLOUD AAS MANAGEMENT
Cloud technologies are used in this layer to develop AAS applications to manage the AASs deployed in the edge layer. The cloud layer acquires data from the edge AAS platform through a cloud interface (OPC UA client). The acquired data are used by backend microservices through a message broker supporting, e.g., an advanced message queuing protocol (AMQP), and stored in a database. To this end, a container is VOLUME 9, 2021 built to host the web server and run independent applications as microservices, such as data analysis, control and operation, and web applications. Two AAS applications are featured in this layer. An AAS web browser can view and edit the AAS information in the AASX model used at the edge layer. An AAS user interface (UI) can control and monitor the runtime AAS data generated from field assets. All web applications interact with backend data through an AAS agent, which holds a web interface that could be, e.g., a RESTful API. In this way, human operators can interact with the entire AAS system through the cloud AAS UI; field manufacturing resources can thus be controlled and scheduled.

B. AAS DEPLOYMENT METHOD
This section illustrates the AAS deployment processes in the edge layer, i.e., how to integrate the AASX model into the OPC UA information model and how to map the AAS model data with the continuous runtime field data. The AAS deployment processes entail three steps, as shown in Figure 5.
In step one, the AASX package explorer is used to model the field assets and their properties and hierarchical relationships in an AASX file, which will also be saved as an XML file. Resulting from part 1 of the AAS specification, an AAS schema file (XML format) that defines the elements for the AAS meta-model is also prepared [31].
In step two, AAS parsing and conversion programs are developed, including two components, an XML parser and an OPC UA conversion module, both written in Python. The input of the AAS parser is the prepared AASX file and AAS schema file. The output of this step includes three files.
The first is a data table, in a comma separated value (CSV) format, that lists the hierarchical OPC UA tag names, i.e., the identifier for each AAS property in compliance with the hierarchy of properties in the AASX model. A field engineer will proceed with the field data mapping process by updating the table, i.e., stating which runtime field data should be mapped into which OPC UA data tag. The second file is a configuration file (JSON format) that contains system and network configuration information, e.g., the internet protocol (IP) address of field assets and sampling interval of field data. This file will be used by the edge interface (OPC UA clients) to detect and connect to field assets automatically. The third file is the OPC UA nodeset file (XML format), which describes the integration of the AASX model and OPC UA information model. This file will be imported into the OPC UA aggregation server program to generate the AASXbased OPC UA information model. Figure 6 shows an example of mapping the AAS and OPC UA information models in which properties of the AASX model (Figure 6a) are mapped to properties in the OPC UA information model (Figure 6b).
In step three, to connect downward with the field devices, OPC UA clients will be developed whose functions include automatic data subscription and acquisition from individual field devices, as well as managing their connection and communication states. Based on the updated data table in step two, the field data mapping module will generate a software program automatically, through which edge OPC UA clients can communicate the mapped data with the AASX-based OPC UA aggregation server. The data table will be stored in a database. In this way, the AAS layer is ready to be connected upward with the cloud layer.

IV. CASE STUDY: A PLUG-AND-PRODUCE MANUFACTURING SYSTEM
PnP is a typical use case to explore the digital requirements to be tackled by Industry 4.0. The goal of PnP is to make the production system as flexible as possible so as to realize the manufacturing scenario of an ''adaptable factory'' in the context of Industry 4.0 [34]. With the capability of PnP, new field devices could be plugged into the underlying system with minimal configuration effort. Legacy devices could be plugged out from the system without affecting the existing system operation [35]. In this way, production system flexibility will increase to reduce production costs and meet fluctuating market demands. There have already been remarkable researches dedicated to implementing PnP. In [47], the authors presented a PnP system architecture with OPC UA describing the skills of the system components.
The state-of-the-art works on PnP conducted by academia or industry (summarized in study [27]) generally cover various use cases, and adopt heterogeneous implementing methods. In other words, there is no standardized guideline or technical approach to follow for achieving PnP, even though it is of importance for future manufacturing. A lack of standards is one of the challenges. On the other hand, when attaining PnP with a digitalizing method specifically, the demands on machines and manufacturing modules increase. First, all modules must feature standardized self-described information so as to be integrated into a machine or plant. Second, a uniform communication interface is required to allow secure and efficient exchange of such information. Information representation and communication capabilities of AAS can meet the challenges on implementing the PnP.

A. SYSTEM OPERATION
We developed a PnP-capable manufacturing system in this work to evaluate the feasibility of the proposed AAS solution. Specifically, the implementation of PnP involves five steps as introduced in study [27]: physical setup, pre-integration, digital representation, AAS communication, and system assessment. The difference is that technical implementations in this study adopt the AASX model, and further realize the mapping of the AASX model to OPC UA information model. This implementation method is simpler and more efficient since the mapping between field data and OPC UA is completed in a single step.
The field assets of the PnP system included three different industrial robots (an Epson C4, an Epson SCARA, and a KUKA R540) and their controllers, and a customized round turntable controlled by a PLC, together with four pairs of photoelectric sensors. Each step for implementing the PnP system is illustrated as follows. First, the robot was physically connected to its peripherals (e.g., gripper, light), and then configured, for example, using the KUKA robot language program. Then, pre-integration was carried out by connecting the robot system and turntable to the field integration bus. The digital representation and AAS communication steps were realized by developing the edge AAS platform based on the AASX-OPC UA aggregation server and edge interface, and PnP-specific applications. Final system assessment was conducted on the AAS web UI by analyzing the AAS data.
Here, we describe the sequence of operation of the PnP system. As shown in Figure 7, the turntable was surrounded by three robots of equal operational priority (R1, R2, and R3). Initially, an iron plate was conveyed by the turntable. When the system was set to run in an operational mode, two robots (e.g., R1 and R2) sequentially executed the pick-andplace task on the turntable, which was to remove the plate from one slot and place it in another slot. A caution light (red, yellow, or green) indicated the running status (stop, idle, or start, respectively) of the robot. When the PnP mode was chosen, a certain PnP strategy (e.g., plug-out R1 and plug-in R3) was defined on the AAS web UI, and R1 was plugged out and R3 plugged in. When plug-out R1 and plugin R3, R1 will first communicate with R3 to notify R1's absence; then, R3 will communicate with R2 and turntable to announce R3's involvement in the operation. The pickand-place process is repeated. For this process, a detailed information flows among the turntable and robots can be referred in [27]. A video is available introducing the detailed operational scenario of the PnP system [36].

B. SYSTEM IMPLEMENTATION
Regarding hardware and software implementation, the edge AAS deployment layer was implemented on an embedded evaluation board with a Linux operating system (OS). The OPC UA-related software was developed using open62541 toolkits [37]. The cloud AAS layer was deployed on a personal computer with a Linux OS, and a thirty-party cloud hosting service from Amazon was used, on which the container service was developed using Docker. The database in this system was implemented as a time-series database using Machbase, which stored time-series data from the PnP system. The message broker was implemented using the open source RabbitMQ supporting AMQP communication.
A screenshot of the AAS web browser is shown in Figure 8, which displays the AAS model (including several AASs) for the entire PnP system. This browser was developed based on the open source AASX package explorer. Each AAS has four submodels: identification, operational data, technical data, and documentation. These four submodels are well-defined and indispensable for describing the property and skills of the assets. As shown in Figure 8, identification defines the supplier information of the asset. Operational data contains the runtime data of a production process, e.g., the sensor status describes the on/off state of the sensor during the system operation, which is of value to assist the robot operation. Technical data defines the technical parameters of the asset. Documentation stores and classifies the documents for an asset, e.g., a control diagram. Property data change in real time, tracking the real system operation. Figure 9 shows the AAS web UI, where a three-dimensional animation of the PnP system and the AAS submodel ''operation data'' were monitored in real time. The left side of Figure 9 shows a floating control panel that could define and execute the PnP strategy to control the system operation. The PnP system is set to run as soon as one certain PnP strategy (e.g., plugout R1 and plug-in R3) is chosen on the panel. In the right side of Figure 9, each asset has a unique AAS model, which demonstrates the data generated from respective action, e.g., position data of the robot axis. Figure 10 shows a picture demonstrating the entire PnP manufacturing system with the AAS solution implemented.

V. DISCUSSION
The following summarizes some of our experiences and reflections on the implementation of the AAS-enabled digital solution.
Here are some noteworthy improvements, as compared to our previous work reported in [27]. The present article presents up-to-date research on, and the development status of, AASs. We then proposed a new AAS implementation method, i.e., directly converting the AAS model into an OPC UA information model. This method is more effective than using automation markup language (AutomationML) and the OPC UA-based conversion method given that the intermediate AutomationML to OPC UA conversion is made redundant. Furthermore, this work updates our PnP case study with this new AAS implementation method while retaining the AAS data communication for realizing the PnP scenario. With regard to the high-level AAS applications, we developed several on a public cloud to manage the AAS data of the PnP system. The implementation of the PnP system has a limitation. The PnP function is implemented on an application level, currently, it is only applicable to the turntable and robots. In other words, robots and turntable operate based on the PnP strategy defined on the web UI.
Compared to the state-of-the-art methods on AAS implementation [48], our approach realizes the runtime data mapping between field assets and the AASX model; in other words, data generated during the system running will be constantly updated into the AASX model. We make a full mapping between the AASX model and OPC UA information model (Figure 7) to further communicate the data with the cloud, and we demonstrate the dynamic AASX model using a web application on the cloud. Furthermore, the proposed AAS solution is applicable to various manufacturing cases. We also validate this AAS solution using a three-dimensional In Mold Labeling (IML) molding machine in a real factory, Shinwoo Costec, in Korea [49].
The implementation methods for AASs could be multifarious. Currently, a working group jointly initiated by the OPC Foundation and the German industrial organizations ZVEI and VDMA is developing an OPC UA companion specification, which describes the mapping of the entire AAS meta-model to the OPC UA information model [38]. This is a generalized but complicated mapping process that considers the full features of both AASs and OPC UA. By contrast, our approach developed the OPC UA information model based only on the specific AASX model. The resulting constraint was that only on-demand AAS data were mapped into the OPC UA information model, thus causing the loss of some AAS meta-properties. In the future, we will conduct a full mapping between the AAS and OPC UA based on part 1 of the AAS specification.
Recently, Plattform Industrie 4.0 released two specifications of submodel templates for AASs, i.e., digital nameplate and technical data [39], [40], which specify the provision for information that describes the nameplate data and technical properties of the industrial equipment, respectively. These templates could provide AAS owners or engineers with guidance for their AAS development, enabling cross-discipline interoperability in engineering activities and ensuring cross-company transparency in the market. In the future, a further series of submodel templates might be specified, which would further serve as a basis for the development of AAS international standards.
Security is a central, huge topic in Industry 4.0 and CPS [41], [42]. Security capabilities like authentication, role management, and secure communication should be considered for accessing AAS data. Off-the-shelf access control policies, such as role-based access control, could be adopted to ensure that an AAS is only available to authorized users. Data encryption mechanisms could also be applied to deter malicious parties from accessing sensitive data in an AAS and to preserve the intellectual property of AAS manufacturers. As a secure industrial communication technology, OPC UA security mechanisms address the authentication of users and applications, the integrity and confidentiality of the exchanged messages, and the validation of function profiles. It can be used to ensure secure data communication in AAS-related applications.

VI. CONCLUSION AND FUTURE WORK
Nowadays, with the emergence of ICPS and its applications in various domains (manufacturing, energy, logistics, and so on), a new opportunity has risen for developing digitalization solutions, e.g., digital twins. This is because there is an excellent match between the ICPS challenges that need to be tackled and the intrinsic characteristics and capabilities of digitalization that could be utilized to do so. AASs, digital representations of industrial components, are one of the technological trends fulfilling this requirement for digital transformation. AASs are designed not only to support the standardized provision of machine-interpretable data but also to provide a description of the offered functionalities [43]. Different resources will then interact through their controlling AASs using standardized interaction protocols and semantic interfaces. Such a definition and context, as analyzed above, fit well with modern pursuits in the context of ICPS and Industry 4.0. In particular, AASs could be used either to implement DTs itself or support some of its key functionalities, for instance, physical object encapsulation, data gathering and communication, collaboration and negotiation, reconfiguration, and intelligent decision support [44]. As such, via AASs, any Industry 4.0 component (i.e., an AAS-based ICPS) becomes part of the value chain and can be utilized, generating added business value. In the future, proactive AASs could help transform the current rigid automation pyramid to a flexible automation network where automation components with AASs can perform autonomously.
To summarize, this article not only presents a novel method for implementing AASs but also reports on the design of an AAS-enabled digital solution for cyber-physical manufacturing systems. The proposed solution was put into operation in a practical PnP-based testbed, which proves it can help make legacy systems become Industry 4.0-capable with minimal development efforts and updating expenses.
In the future, we will evaluate an AAS solution in more complicated manufacturing use cases, e.g., a production line in a real factory. We will also follow new or upcoming publications on AASs to improve our AAS solution. We may also explore other open source implementation methods in relation to AASs. Future efforts will also focus VOLUME 9, 2021 on physical, automatic plug-and-play of new unknown field devices exploiting device discovery, capability assessment, and parameter configuration. More manufacturing scenarios of plug-ang-play can be elaborated. The specification VDI/VDE 2193 will be explored for straightforward communication between two AASs.