Automated Configuration of BaSyx DataBridge using Standardized Asset Administration Shell Interface Modelling

Automated Configuration of BaSyx DataBridge using Standardized Asset Administration Shell Interface Modelling Andrés Pérez Vaz Smart Systems and Smart Manufacturing AIMEN Technology Centre O Porriño, Spain [email protected] Davinia Fernández Martínez Smart Systems and Smart Manufacturing AIMEN Technology Centre O Porriño, Spain [email protected] Emilio Costa Tobío Smart Systems and Smart Manufacturing AIMEN Technology Centre O Porriño, Spain [email protected] Lucía Alonso Ferreira Smart Systems and Smart Manufacturing AIMEN Technology Centre O Porriño, Spain [email protected] Abstract—The Asset Administration Shell (AAS) standard links the gap between physical and digital assets. It provides a structured and standardized way for describing assets. The DataBridge component within the BaSyx platform enables integration of multiple protocols, real-time data ingestion, transformation, and mapping from data sources onto AAS SubmodelElements. However, configuring the DataBridge requires significant manual effort in complex and real scenarios with a huge amount of data. This paper presents a novel software service for automating the DataBridge configuration using AAS-based standard submodels. The component simplifies configuration by automatically generating JSON configuration files based on a standardized AAS, reducing manual effort and accelerating development cycles in agile environments. The solution has been demonstrated using XXL Pilot Factory, showcasing how Asset Interface Descriptions (AIDs) and Asset Interface Mapping Communication (AIMC) submodels automate DataBridge configuration. Keywords—Asset Administration Shell, automation, protocols, DataBridge I. INTRODUCTION The fourth industrial revolution has driven the need for standardized digital representations of assets to enable interoperability across industrial ecosystems. The Asset Administration Shell, part of the RAMI 4.0 framework, provides a standardized structure for digital twins, allowing for unified data exchange. This is achieved by incorporating physical objects (e.g., a machine, sensor, or software system) and their virtual representations – the Asset Administration Shell and enabling bidirectional information exchange between them [1], thereby constituting an Industrie 4.0 Component, which serves as a foundational element for standardized communication and integration in I4.0 by using standardized semantics [2]. Manufacturing companies often rely on structured data exchange formats such as OPC UA [3] to handle the communication between machines and software tools, as part of vertical integration, but in recent years, the majority of solutions have relied on middleware-based architectures [4][5]. These architectures aim not only to support vertical integration between shop floor devices with enterprise systems, but also the horizontal integration across organizations and supply chains [6]. However, despite the advancements in interoperability, integrating multiple Cyber Physical Systems (CPS) requires not only protocol translation but also harmonized data semantics and alignment with emerging standards that are able to manage the large amount of data, particularly when configuring data bridges between different systems. To address this challenge, the Eclipse BaSyx, an opensource middleware supporting AAS implementation, offers a solution for real-time data integration between multiple protocols and AAS systems through its DataBridge component. Despite its flexibility, configuring the DataBridge is a tedious and error-prone task, particularly in real environments where hundreds of variables exist in the AAS. Moreover, frequent updates in the communication data structures during development cycles further increase the burden, requiring developers to continuously regenerate configuration files. In this paper, a novel DataBridge component, the DataBridge Configurator tool, is introduced, which automates configuration and communication mapping through AASbased standard submodels. The approach is deployed within the BaSyx platform. The solution enables real-time data ingestion, transformation, and routing, removing manual configuration and enhancing interoperability. II. BACKGROUND A. Asset Administration Shell The AAS standard IEC 63278-1 defines a digital representation of assets, allowing data modelling and interaction in industrial environments. The AAS is the model with the highest degree of maturity for mapping product and process information across the entire lifecycle of industrial goods. But there is a lack of format standardization when implementing AAS regarding technologies, as well as the need to address the semantic interoperability between assets [7]. This lack of established AAS models increases when it comes to immaterial and non-machine assets [8] (e.g., software components). Moreover, all the steps required for AAS modelling must be carried out manually, requiring intensive software re-programming [9]. This research has been supported by Horizon Europe research and innovation program under the grant agreement No 101058521. 2025 IEEE 30th International Conference on Emerging Technologies and Factory Automation (ETFA) | 979-8-3315-5383-8/25/$31.00 ©2025 IEEE | DOI: 10.1109/ETFA65518.2025.11205726 Authorized licensed use limited to: University of Patras. Downloaded on November 04,2025 at 20:20:30 UTC from IEEE Xplore. Restrictions apply. An AAS instance consists of multiple submodels, each representing a specific aspect or characteristic of an asset. To address the need for harmonized semantic structures, Industrial Digital Twin Association (IDTA) plays a pivotal role by providing submodels templates and specifications. Notable examples include templates for communicationrelated descriptions, such as OPC UA Server Data Sheet, Wireless Communication, or Asset Interfaces Description. Nevertheless, the existing templates do not yet cover the full range of communication protocols used in industrial environments, and, moreover, they are still under development. B. AAS Platforms Currently, there are various well-known existing and open-source implementations of AAS platforms, such as AASX Server, FA3ST, NOVAAS, and Eclipse BaSyx [10]. These implementations support real-time functionality and various communication protocols like HTTP, OPC UA, and MQTT. However, the degree of real-time synchronization capability between physical assets and their digital twin varies among implementations, often requiring additional customization or integration efforts. Among these, Eclipse BaSyx stands out due to its comprehensive open-source middleware architecture and modular design, providing a set of tools and components that support the entire digital twin lifecycle. It supports multiple programming languages, with the Java version being the most mature. It is divided into several core components and services (i.e., AAS Server, AAS Registry) that can be deployed in different combinations as required. Eclipse BaSyx offers multiple ways to synchronize with an asset: via custom coding, via a component called DataBridge, or via a mechanism called property/operation delegation. Via custom coding, theoretically, any kind of asset can be connected to the AAS; however, this requires manual writing of the code to do so. The DataBridge is an external component to the AAS Service that helps to synchronize with assets by subscribing to changes on the asset and forwarding them to the AAS via HTTP commands. It is based on Apache Camel, a messageoriented middleware for integrating producing or consuming data systems [11]. This component enables data to flow from various industrial sources—such as sensors, robots, and software systems—through multiple protocols — HTTP, MQTT, KAFKA, OPC UA, ActiveMQ, HONO, or PLX4X— into the digital twin represented by the AAS. The manual configuration process for even a simple operational data point in an AAS reveals significant practical hurdles. Each new data point requires manual creation of JSON transformations, source/destination definitions, and explicit linking across multiple files (i.e., one AAS property needs the manual configuration of five files). This tedious process becomes exponentially problematic when modifications are needed or a huge number of variables are required: the DataBridge must be stopped, the configurations must be manually updated, and the service restarted. For systems requiring frequent adjustments (i.e., flexible and reconfigurable production lines with hundreds of variables), this static approach greatly increases the configuration times. In large-scale industrial environments, these approaches prove insufficient, and the problem worsens in agile development environments where data structures frequently change, requiring continuous regeneration of configuration files and environment variables. This manual effort creates bottlenecks in development cycles and increases the likelihood of configuration errors. C. Existing approaches to automated configuration Previous research for the automatic configuration of AAS environments has explored rule-based data transformation and semantic interoperability in Industry 4.0 [12]. However, most approaches lack standardized AAS submodels for automating data exchange or mapping configurations. To address these limitations, recent scientific publications have also explored tools and methodologies for the automatic modelling of Asset Administration Shells (AAS) and their deployment in Industry 4.0 environments. For instance, the ConfigWizard tool [13] supports partially the automatic AAS generation by filling in the information in a user interface, assisting in the essential steps (such as information modeling and OPC UA server configuration), and generating AASs in compliance with the requirements and standards of I4.0; however, it does not support integration with AAS-based platforms (i.e., AAS Registry and Server from Eclipse BaSyx). This solution represents a low-code approach that requires tailoring toward specific technologies and use cases. To overcome these constraints and promote wider adoption, the definition of standardized interfaces and common templates facilitates the development of more technologyagnostic and low-code platforms. [14] In parallel, other studies have investigated the automatic self-configuration of infrastructures to enable plug-and-play scenarios. For instance, the mechanism proposed in [15] deploys a non-blocking client for PLCs to retrieve configuration-related information from an AAS database server during run-time. However, this implementation does not directly use the AAS; instead, it relies on AutomationML (IEC 62714) files, and, additionally, the run-time data is not stored back in the AAS database, preventing a fully integrated implementation of the administration shell. The limitations of existing approaches highlight the need for a more automated, standardized method for configuring data integration components. This publication presents a generic methodology and architecture as well as a novel software component able to manage the automatic configuration of an AAS Server (i.e., Eclipse BaSyx) for realtime data using a common template for the AAS definition of the communication interfaces. Moreover, the document also proposed a solution for a dynamic AAS configuration and modelling able to adapt to changes over the runtime execution. III. SYSTEM ARCHITECTURE The solution shown in Fig. 1 connects two key systems: a real-time data processing pipeline (origin) and an AAS platform (sink). Fig. 1. System architecture. Authorized licensed use limited to: University of Patras. Downloaded on November 04,2025 at 20:20:30 UTC from IEEE Xplore. Restrictions apply. The origin system continuously captures, combines, and processes operational data from diverse industrial sources, including robotic systems, operator tracking systems, and manufacturing databases. This raw data flows through an event streaming backbone for distribution. The AAS platform is provided by Eclipse BaSyx middleware, composed of the following components: • AAS Repository: Stores and manages AAS instances, including their submodels and properties. Not only hosts the AAS of the systems, but also the AAS that maps the communication interfaces between the origin and sink (DataBridge AAS). • AAS Registry: Enables discovery and lookup of AAS descriptors in a distributed environment. • DataBridge: Facilitates real-time data ingestion into AAS SubmodelElements from external sources (e.g., Kafka, OPC UA, MQTT). It facilitates the mapping of a data source into AAS SubmodelElements and acts as an intermediary, consuming real-time data, applying necessary transformations, and pushing the processed data into the appropriate AAS properties. • AAS Web UI: Enables the AAS real-time visualization of the different properties and facilitates the debugging of the configuration phase. • DataBridge Configurator: Python-based software component that supports the data modelling provisioning by reading the information available in the AAS Repository and generates all configuration files for setting up the system. IV. AUTOMATED DATABRIDGE CONFIGURATION USING AAS SUBMODELS As mentioned before, to automate the configuration of the BaSyx DataBridge component, a specific DataBridge AAS was modelled, detailing all relevant configuration information comprising three submodels shown in Fig. 2. First, two standard AAS submodels: the Asset Interface Description (AID) Submodel and the Asset Interface Mapping Communication (AIMC) Submodel. Both standards have been developed by the Industrial Digital Twin Association (IDTA) with the objective of describing the communication interfaces and the datapoint relationships of an asset-related service. Lastly, a custom Communication Message submodel describing the structure of the datapoints. A. Asset Interface Descriptions Submodel The AID Submodel was developed to define the interface(s) of an asset service or an asset-related service. It is based on the W3C Web of Things Thing Description, and it provides a common representation for all types of interfaces, but it also includes some specific properties for different protocols. The current version of this standard template (v1.0 of January 2024) [16] includes Modbus, HTTP, and MQTT protocols but can be used as a baseline for others. For this paper’s implementation two protocols have been used, HTTP and Kafka. The latter interface was created following the guidelines for MQTT because of its similarities. The AID SM has a v1.1 in review but is not yet publicly available. For this reason, the paper follows the specifications on v1.0. Fig. 2. DataBridge AAS main structure. In the DataBridge AAS, the AID Submodel describes not only the external interface(s) that send data from a real-time pipeline, but also the internal one used by the DataBridge to update that data in the asset’s AAS on the AAS Repository. In addition, this Submodel is also used to describe the communication information of each datapoint (e.g., MQTT topic). While the internal protocol used by the DataBridge for updating the AAS is always HTTP, the one used to communicate with the external sources is dependent on the characteristics of the assets or the existence of a middleware that provides the data. To complement this interface modelling, the EndpointMetadata SubmodelCollection (SMC) contains the information about the asset’s endpoint, including: the entry point connection defined in the base property as well as the common content type of the asset’s datapoints (each datapoint also specifies its content type, in case the general one is not applicable to all). Furthermore, the InteractionMetadata SMC covers the information regarding the datapoints. Each one is defined as an element in the properties collection, and contains the communication information, including the relative target IRI or full path of the datapoint, which, combined with the base information on the endpoint, makes up the full datapoint address. The path information is embedded within the href property of the forms collection. For the source interface, specifically, the properties available in the InteractionMetadata describe all datapoints received in the DataBridge with the respective topic and the content type, while the HTTP interface contains one element for each property to be updated in the final asset’s AAS. B. Communication Message Submodel Due to the lack of standardized formats or guidelines for communication messages —and the fact that message structures often vary as much as the assets themselves, depending heavily on the engineer responsible for system integration— the datapoints received in the DataBridge can range from single variables (e.g. an integer representing a temperature) to complex structures containing many elements (e.g. a JSON message containing multiple nested variables). Since every element needs to be mapped individually between the source interface and the final AAS, it becomes essential to model every property from the source data. To address this challenge, the Communication Message submodel was defined to describe the structure of every datapoint originated from the external interfaces. When the datapoint is a simple property, only one element would be included in this submodel. However, if the message contains composite elements, this approach allows the description of Authorized licensed use limited to: University of Patras. Downloaded on November 04,2025 at 20:20:30 UTC from IEEE Xplore. Restrictions apply. all of them using SMC to describe objects and SubmodelList (SML) for arrays, for instance. Accordingly, for each datapoint defined in the Interaction Metadata of the source interface, a CommunicationMessage SM must be created. This allows the DataBridge to interpret complex datapoints automatically. Once the message structure is detailed, a mapping between each source message property and its corresponding HTTP property can be established. C. Asset Interface Mapping Communications Submodel Once every element has been defined in the AID interfaces and in the CommunicationMessage SM, the next step is to establish a connection between all of them. The AIMC SM links the asset’s attributes provided by the real-time pipeline and their AAS properties, allowing for the automation of the AAS communications. This SM is comprised of collections of mapping configurations, each one containing a reference to its AID interface and a list of the relationships between elements. The first element of the relationship is always the data source, while the second element will be the data sink. The AIMC used in this development fully adheres to the latest version of the AIMC specification (v1.0 of June 2024) [17]. In this implementation, two types of mappings have been defined: • The type 1 links each datapoint from a source interface with the Communication Message submodel that describes its structure. There would exist one group of mappings for each source protocol. • The type 2 contains the link between each property in a Communication Message and the respective property defined in the HTTP interface that will update the asset’s AAS. There will always be one single group mapping of type 2 that describes all the relationships between the Communication Messages and the HTTP properties. D. Datapoint Mapping Process Across AAS Interfaces In summary, the dataflow (shown in Fig. 3) would be as follows: 1. A datapoint is defined in the AID InteractionMetadata of the source interface (which contains broker URL and topic). 2. In the AIMC first type group, a link is created between this element and the CommunicationMessage SM describing the structure of the message. 3. In the AIMC second type group a link is created between one property of that CommunicationMessage SM and the corresponding property defined in the AID InteractionMetadata of the HTTP interface that updates the AAS. 4. The property in the HTTP interface contains the relevant information to update the asset’s AAS on the BaSyx Server (IP of the server and complete path of the property). E. Configuration Automation Process The proposed automation workflow follows a systematic approach to generate DataBridge configuration files by considering the information modelled in the Databridge AAS. Fig. 3. Dataflow on the DataBridge AAS. The configuration workflow begins by launching the DataBridge Configurator tool prior to starting the DataBridge component. This tool queries the DataBridge's own AAS from the AAS Server. From this machine-readable specification, the tool automatically generates all required configuration files: • consumer.json: Configures the specific communication protocol (i.e., in case of Kafka, it will be the kafkaconsumer.json), topic subscriptions and consumer groups. The tool will generate one file per each protocol listed in the AID interface. • aasserver.json: Specifies target AAS endpoints in the AAS Server and Submodel mappings. This will be a unique file containing all relevant information. • JSONata variable files: Define dynamic binding expressions used to extract and transform data from incoming JSON messages. Each file contains a JSONata [18] query to a specific data field or structure of the JSON. Individual files will be automatically generated, one per property. • jsondatatransformer.json: Contains the mapping index between unique identifiers and their corresponding JSONata variable files. Each entry specifies the transformation details, including the file path, expected input type, and desired output format. The tool will create one per JSONata variable file previously explained. • routes.json: Defines the data flow by linking sources, logic transformation, and destinations using the unique ID´s of previous definitions. Once the configuration files are automatically generated, the DataBridge component can be deployed by following the steps and guidelines from Eclipse BaSyx. In this way, the Configurator tool not only facilitates automatic setup by eliminating manual JSON editing but also demonstrates the compliance with AAS metamodel of the generated AAS submodels and mappings through successful integration with the BaSyx ecosystem. V. EXPERIMENTAL VALIDATION The proposed solution was validated in the XXL Pilot Factory [19] (shown in Fig. 4) at AIMEN Technology Centre, a real Human Robot Collaboration (HRC) [20] testbed promoted in the CONVERGING project [21]. At the core of this environment, there is an industrial ABB robot, configured to expose position, velocity, and torque values of its six joints. Authorized licensed use limited to: University of Patras. Downloaded on November 04,2025 at 20:20:30 UTC from IEEE Xplore. Restrictions apply. Fig. 4. XXL Pilot Factory with an ABB robot and an operator. Additionally, it provided the status of the end-effector tool state. Complementing the robotic infrastructure, the pilot also featured advanced operator monitoring systems. A depth camera tracks 32 markers of the operator´s movements, capturing body kinematics in relation to the robot’s work envelope, and all this information is captured and published. On top of that, there is a software module that continuously evaluates the operator’s posture using a real-time RULA (Rapid Upper Limb Assessment) scoring method, adding an ergonomic dimension to the HRC interaction. To manage and process this high volume of data, the Data In Motion (DIM) module acts as a real-time pipeline, ingesting data from various sources—including ROS topics, MQTT brokers, and databases—before fusing and publishing it through Apache Kafka. The development of this tool was driven by the necessity to integrate the amount of data available in the Data In Motion (DIM) module with the Data At Rest (DAR) module. The DAR module is a part of the digital thread, using microservices for online processing, providing seamless data sharing between modules, and facilitating data analytics. However, for other modules or software components, the data needs to be structured in an interoperable way. This is where the AAS comes into play, serving as the bridge between raw streaming data and semantically enriched, standardized information models. The first step in the modelling process is to create the AAS digital models of the assets. In this implementation, this would be the Robot AAS and the Operator AAS, among others. These models contain all operational data to be updated, as illustrated in Fig. 5. As explained in the previous section, the DataBridge AAS was created to enable the automated configuration, containing the communication and protocol information. The source interface of the AID SM is Kafka (protocol used by the DIM module that provides data), and its base property in the EndpointMetadata SMC is the URL of the Kafka broker. In this specific use case, the properties collection in the InteractionMetadata SMC is comprised of the three Kafka topics used in the XXL Pilot Factory: MPCM.joint_tool_states, PAM.body_tracking_data and UXE.erg_cost. As shown in Fig. 6, every topic specifies its communication information through the forms collection (href for full topic’s name, maxpollrecords, groupid…). Fig. 5. Robot AAS. The second interface in this submodel is the HTTP one, which, as mentioned in section IV, would be common for every implementation of the DataBridge AAS regardless of the use case, since it is the interface that updates the properties on the asset’s AAS located on the AAS Repository. The base property for this interface is the BaSyx Server’s URI (containing the IP), while the properties collection includes one element for each property to be updated in the asset’s AAS. The href of each one comprises the entire property path, including the submodel ID in Base64 of the asset’s AAS that holds the properties to be updated. For instance, the position of the first joint of the robot is a property inside a Joint1 collection in the OperationalData submodel of the Robot AAS. Thus, its href is: {submodelID_Base64}/Joint1.Position. Fig. 6. InteractionMetadata Submodel Collection. Authorized licensed use limited to: University of Patras. Downloaded on November 04,2025 at 20:20:30 UTC from IEEE Xplore. Restrictions apply. For each of the three Kafka topics, a Communication Message SM was created. Fig. 7 (a) displays the Robot Communication Message, corresponding to the MPCM.joint_tool_states Kafka topic, that includes properties for the joints and the gripper. This SM shown in Fig. 7 (b) is manually created to transform and interpret the JSON message coming from Kafka into the AAS equivalent. For instance, the JSON object state is transposed to an SMC while the position array is interpreted as SML. Lastly, the AIMC SM contains two groups of mappings, one related to the Kafka interface and the other to the HTTP interface. The first one contains a relationship for each topic that links each one with the communication message that describes its structure. The second group links properties from the communication message to the HTTP element that contains the information to update the corresponding property in the AAS. For instance, as illustrated in Fig. 7 (c), the first relationship links the property state.joint.position[0] from the CommunicationMessage of the Robot to the HTTP element Joints1Position that contains in href the path to update the property Joint1.Position in the Robot AAS. Upon successful launch, the DataBridge Configurator initiates the automated configuration workflow. It begins by retrieving and processing the DataBridge's own AAS, then generates all required configuration files required for the deployment. For the XXL Pilot Factory use case, the tool is able to automatically configure 280 data variables, resulting in the following outputs: • 280 JSONata transformation individual files (one per variable). • 280 relations in jsonatatransformers.json file linking JSONata transformation files and unique IDs. • 280 AAS server endpoint definitions in aasserver.json. • Complete definition of kafkaconsumer.json with 3 Kafka topics. • Complete routes.json linking each source to its destination with its corresponding transformation. The tool generates clean configuration files in seconds, compared to hours of manual JSON editing. This proved particularly valuable when it came to troubleshooting or updating, because it simply verifies the AAS submodel definitions and regenerates them. The validation clearly showed how automated configuration generation solves two major pain points in industrial deployments and integrations: the time-consuming nature of manual setup and the error-prone process of maintaining complex data mappings across evolving systems. Fig. 7. a) Communication Message from Kafka, b) Communication Message Submodel, c) Relationship between the message and the interface. VI. CONCLUSION AND FUTURE WORK This paper presents a tool for automating the configuration of the BaSyx DataBridge component using the standard submodels AID and AIMC. By modelling the software interfaces themselves, the DataBridge Configurator automatically generates the static JSON configuration files. The developed solution reduces time and manual effort, improving AAS deployments in real industrial scenarios. Although it involves an initial investment in modeling the DataBridge interfaces as AAS submodels, this initial effort proves far more efficient than the original manual configuration procedure, reducing typical setup times from hours to minutes while eliminating configuration errors. Looking ahead, future work will focus on contributing these improvements directly to the official open-source Eclipse BaSyx Databridge repository as a new component. Specifically, the goal is to extend the current implementation to support dynamic, in-memory loading of configuration data. This would enable the DataBridge to read and update its configuration at runtime without requiring a restart. Such a feature would allow on-the-fly modifications to routes, protocols, and transformation logic, providing much-needed flexibility for dynamic industrial settings. Regarding the standard submodels, modifications in the AID and AIMC specifications will be monitored to adapt the Configurator to the new changes. It would also be interesting to propose the standardization of the Communication Message submodel to the IDTA. Furthermore, the Communication Message submodels that are now created manually, will be automated to transform JSON and other types of messages into the AAS Submodel. Following this path, the creation of all the properties of the HTTP AID Interface will also be automated using the asset’s AAS. Thus, using the properties already modelled in the Operational Data submodel of the AAS (e.g., the Robot AAS), the configuration of the HTTP Interface that updates these properties can be automatically generated. Authorized licensed use limited to: University of Patras. Downloaded on November 04,2025 at 20:20:30 UTC from IEEE Xplore. Restrictions apply. By shifting from static to dynamic configuration management, the DataBridge can become a more responsive and adaptable component in Industrie 4.0 architectures. We believe this enhancement would benefit the broader Eclipse BaSyx community and promote more fluid integration workflows across industrial use cases. ACKNOWLEDGMENT This research has been supported by Horizon Europe research and innovation program under the grant agreement No 101058521, the project Converging (Social industrial collaborative environments integrating AI, Big Data and Robotics for smart manufacturing). REFERENCES [1] X. Ye and S. H. Hong, “Toward Industry 4.0 Components: Insights into and Implementation of Asset Administration Shells,” IEEE Industrial Electronics Magazine, vol. 13, no. 1, pp. 13–25, Mar. 2019, doi: 10.1109/MIE.2019.2893397. [2] Merianstraße, “VDE Verband der Elektrotechnik Elektronik Informationstechnik e. V. VDE Association for Electrical, Electronic & Information Technologies DKE Deutsche Kommission Elektrotechnik Elektronik Informationstechnik in DIN und VDE-DKE German Commission for Electrical, Electronic & Information Technologies in DIN and VDE”, Accessed: Apr. 07, 2025. [Online]. Available: www.din.de [3] A. Volkova, M. Niedermeier, R. Basmadjian, and H. De Meer, “Security challenges in control network protocols: A survey,” IEEE Communications Surveys and Tutorials, vol. 21, no. 1, pp. 619–639, Jan. 2019, doi: 10.1109/COMST.2018.2872114. [4] J. S. Ok, S. Do Kwon, C. E. Heo, and Y. K. Suh, “A Survey of Industrial Internet of Things Platforms for Establishing Centralized Data-Acquisition Middleware: Categorization, Experiment, and Challenges,” Sci Program, vol. 2021, no. 1, p. 6641562, Jan. 2021, doi: 10.1155/2021/6641562. [5] W. Quadrini, C. Cimino, T. A. Abdel-Aty, L. Fumagalli, and D. Rovere, “Asset Administration Shell as an interoperable enabler of Industry 4.0 software architectures: a case study,” Procedia Comput Sci, vol. 217, pp. 1794–1802, Jan. 2023, doi: 10.1016/J.PROCS.2022.12.379. [6] “The Internet of Things and Services Graphics © Bosch Rexroth AG”. [7] S. Beden, Q. Cao, and A. Beckmann, “Semantic asset administration shells in industry 4.0: A survey,” Proceedings - 2021 4th IEEE International Conference on Industrial Cyber-Physical Systems, ICPS 2021, pp. 31–38, May 2021, doi: 10.1109/ICPS49255.2021.9468266. [8] C. Bouter, M. Pourjafarian, L. Simar, and R. Wilterdink, “Towards a Comprehensive Methodology for Modelling Submodels in the Industry 4.0 Asset Administration Shell,” Proceedings - 2021 IEEE 23rd Conference on Business Informatics, CBI 2021 - Main Papers, vol. 2, pp. 10–19, 2021, doi: 10.1109/CBI52690.2021.10050. [9] L. Alonso, L. Barja, B. Lodeiro, E. Xanthakis, and R. Broechler, “Asset Administration Shell Modelling and Implementation Enabling Plug and Produce Capabilities for Modular Production”, doi: 10.1007/9783-031-38165-2_24. [10] M. Jacoby et al., “Open-Source Implementations of the Reactive Asset Administration Shell: A Survey,” Sensors 2023, Vol. 23, Page 5229, vol. 23, no. 11, p. 5229, May 2023, doi: 10.3390/S23115229. [11] M. Jacoby et al., “Open-Source Implementations of the Reactive Asset Administration Shell: A Survey,” Sensors 2023, Vol. 23, Page 5229, vol. 23, no. 11, p. 5229, May 2023, doi: 10.3390/S23115229. [12] J. Nilsson and F. Sandin, “Semantic Interoperability in Industry 4.0: Survey of Recent Developments and Outlook,” Proceedings - IEEE 16th International Conference on Industrial Informatics, INDIN 2018, pp. 127–132, Sep. 2018, doi: 10.1109/INDIN.2018.8471971. [13] J. Arm et al., “Automated Design and Integration of Asset Administration Shells in Components of Industry 4.0,” Sensors 2021, Vol. 21, Page 2004, vol. 21, no. 6, p. 2004, Mar. 2021, doi: 10.3390/S21062004. [14] J. Zhang, C. Ellwein, M. Heithoff, J. Michael, and A. Wortmann, “Digital twin and the asset administration shell: An Analysis of the Three Types of AASs and their Feasibility for Digital Twin Engineering,” Softw Syst Model, pp. 1–23, Jan. 2025, doi: 10.1007/S10270-024-01255-0/FIGURES/13. [15] M. Wenger, A. Zoitl, J. Kepler, and T. Müller, “Connecting PLCs With Their Asset Administration Shell For Automatic Device Configuration,” 2018, doi: 10.1109/INDIN.2018.8472022. [16] “Submodel-templates/published/Asset Interfaces Description/1/0 at main · admin-shell-io/submodel-templates · GitHub.” Accessed: Jul. 14, 2025. [Online]. Available: https://github.com/admin-shellio/submodeltemplates/tree/main/published/Asset%20Interfaces%20Description/1/ 0 [17] “Submodel-templates/published/Asset Interfaces Mapping Configuration/1/0 at main · admin-shell-io/submodel-templates · GitHub.” Accessed: Jul. 14, 2025. [Online]. Available: https://github.com/admin-shell-io/submodeltemplates/tree/main/published/Asset%20Interfaces%20Mapping%20 Configuration/1/0 [18] “JSONata.” Accessed: Apr. 08, 2025. [Online]. Available: https://jsonata.org/ [19] J. Masood, F. Vidal, D. Castro, A. M. Pertusa, and A. Feijoo, “Robotized technologies for enhanced shipyard operations: challenges and solutions,” Green Manuf Open 2024;2:6., vol. 2, no. 2, p. N/AN/A, Mar. 2024, doi: 10.20517/GMO.2023.102601. [20] G. Michalos, P. Karagiannis, N. Dimitropoulos, D. Andronas, and S. Makris, “Human Robot Collaboration in Industrial Environments,” Intelligent Systems, Control and Automation: Science and Engineering, vol. 81, pp. 17–39, 2022, doi: 10.1007/978-3-030-785130_2. [21] “Home | CONVERGING | EU Funded Project.” Accessed: Apr. 08, 2025. [Online]. Available: https://www.converging-project.eu/ Authorized licensed use limited to: University of Patras. Downloaded on November 04,2025 at 20:20:30 UTC from IEEE Xplore. Restrictions apply.