# The Role of Multi-Agent Systems in Realizing Asset Administration Shell Type 3
## 4 Agent-Based Reference Model for Realizing AAS Type 3
### Recommended Practices for Interfacing with Assets Supported by IEEE 2660.1 Standard
The interaction mode refers to the way the agent interacts with the asset:  
* Tightly coupled: This interaction mode is characterized by a direct, permanent, and non-mediated connection between the agent and asset. The participants are connected via direct network communication or shared memory and follow a traditional request-response schema. This schema typically involves the agent sending a request to the asset, which processes the request and sends back a response. * Loosely coupled: This interaction mode is characterized by an indirect connection between the agent and asset, usually mediated by one or more message brokers, following a publish-subscribe schema. Messages are sent asynchronously, meaning that the agent does not have to wait for an immediate response from the asset. Regarding the deployment location, two possibilities are identified:  
* Hybrid: The agent operates on a separate computational platform from the asset controller. * On-device: The agent operates on the same computational platform as the asset controller. In industrial settings, any proposed solution must be integrated with existing deployed systems. In this context, agent integration can be quite restricted depending on the specifics of the asset, but it can also be flexible, allowing multiple integration patterns and technologies to be applied for the same use case. In such circumstances, it is important to take into account the advantages and disadvantages of each integration pattern for different applications. In this context, the IEEE 2660.1 also defines a recommendation method  
Figure 6: IEEE 2660.1-2020 generic integration patterns (adapted from [27]). that recommends the best interface practices to interconnect agents and physical assets, particularly low-level automation devices, based on user-selected criteria. These criteria include functions (e.g., control, monitoring, or simulation), application domains (e.g., factory automation, building automation, or energy and power systems), technological constraints (e.g., the ability to host agents in the asset controller), as well as the relevant characteristics for the application scenario (e.g., response time, scalability, and reusability). Based on these criteria defined by the user, the method uses a recommendation engine that evaluates existing interface practices stored in a repository, which is continuously updated with interface practices collected from several industrial agent experts who have implemented and used different interface practices. As a result, the recommendation engine produces a ranked list of recommended interface practices, each assigned a score ranging from 0 to 5. To illustrate the application of the IEEE 2660.1 recommendation method, consider the digitization of an inspection gauge placed in a production line performing inspection tasks to detect deviations in product production. In this context, the application domain is \"factory automation\", the asset cannot host agents locally, and the functionality provided by the agent is the \"control\" of the asset, e.g., to adjust its measurement parameters that need to be changed according to the specifications of the product. In such a configuration, \"response time\" and \"reusability\" are the most important characteristics to be considered (weighted as response time 80% and reusability 20%). The results provided by the IEEE 2660.1 recommendation method are illustrated in Figure 7.  
The recommended practice (\"HT-7\") involves implementing a tightly coupled interface utilizing the OPC UA protocol. Due to hardware constraints preventing the hosting of agents on the asset, the suggested strategy relies on a hybrid location setup. This implies that the client operates remotely, potentially leading to response time being influenced by the communication infrastructure. If the asset is not capable of supporting the OPC UA protocol, other alternative interface practices can be considered, e.g., \"HT-6\" and \"HT-3\", which consider Ethernet/IP and HTTP protocols, respectively.