Common practices for integrating industrial agents and low level automation functions

Industrial agent technologies have been integrated in key elements coupling industrial systems and software logic, which is an important issue in the design of cyber-physical systems. Although several efforts have been tried out over the last decades to integrate software agents with physical hardware devices, and some commonalities can be observed among the existing practices, there is no uniform way overall. This work presents an empirical survey of existing practices in three application area, namely factory automation, power & energy systems and building automation. It identifies pertaining common issues and discusses how they integrate low level automation functions by utilizing industrial agents. The surveyed practices reveal high diversity, customized traditional integration focusing mostly on I/O functions, without security, and an overall approach that is mostly coupled rather than embedded.


I. INTRODUCTION
Industrial systems are being re-designed to address the continuous globalization and digitalization of economies of scale, and the growing demand for more complex but in parallel highly-customized products [1], [2].Industrial Agents (IAs) [3] have been used to introduce intelligence and adaptation in such complex dynamic systems, constrained by some industrial requirements, namely the need to integrate low level automation functions, with lighthouse examples in several domains [1], such as factory automation, power & energy systems, and building automation.
Of special significance to IAs, are Multi-Agent Systems (MAS) which is a paradigm derived from the distributed artificial intelligence field that promote distribution, decentralization, intelligence, autonomy and adaptation, contributing to achieve flexibility, robustness, responsiveness and reconfigurability [4].A MAS is an ecosystem of intelligent, autonomous and cooperative computational entities, known as agents, which may represent physical or logical objects in the system.The overall system function emerges from the interaction among distributed agents, each one possessing its own knowledge and skills, and able to interact with other agents when it can achieve its goals.MAS offers an alternative way to design complex large-scale systems by decentralizing the control system by distributed, autonomous and cooperative entities, differing from the conventional approaches due to its inherent capabilities to adapt to emergence without external intervention.
MAS technology has already been integrated to several industrial applications in a Cyber-Physical Systems (CPS) context, namely smart production [3], [5]- [10]), smart power grids [11]- [14]), smart logistics [6]) and smart healthcare [15], [16]).IAs may form an integral part of CPS and are well aligned with the trends in the domain [1]- [3], expand the potential application domains of MAS and at the same time add the required flexibility, robustness and responsiveness to industrial automation systems.However, as recent surveys reveal [4], [17]- [20], their acceptance depend on key factors, including technology, standardization and hardware, which pertain the investigation in this work.
Although significant efforts exist in IAs, the practices to integrate the software agent counterpart with the physical hardware device counterpart are not homogeneous.Different domains have focused on different practices, that pertain the usage of tools, integration consideration and approach.Despite of this, some general commonalities can be observed.In this work, a survey was undertaken in three of such domains, i.e., factory automation, power & energy systems, and building automation.The aim was to collect empirical data on current practices and identify commonalities, that posteriorly will support the task to potentially propose a "best practice" for that specific domain or integration of IAs and low-level automation functions at large.
The following part of the paper is organized as follows: in section II the methodology used to perform the survey related to existing interfacing practices, namely explaining the selected application domains and the templates to categorize the analyzed practices, is described.Subsequently, section III analyses the survey results for the three independent application domains, namely factory automation, power & energy systems, and building automation.In section IV a discussion is carried out with the aim to identify commonalities and generalize the results towards the establishment of "best practices" for integrating IAs and low level automation functions at large.Finally, in section V the conclusions and future work are presented.

II. METHODOLOGY
As outlined in the introduction, the focus of this study is centered on three industrial domains, i.e., factory automation, power & energy systems, and building automation, as these form the core of efforts for integrating software agents, and they are also prevalent in ongoing efforts related to key high level initiatives in many countries, such as Smart Grids, Smart Cities and Fourth Industrial Revolution (Industry 4.0).To identify the existing approaches in integrating software agents with low level automation functions, a survey was selected as a mean of collecting data.
A questionnaire was constructed to clearly focus to a single practice of interconnecting the agent and the automation device.The questionnaire attempts to capture key aspects of such interfaces, e.g., the type of devices/controllers used, the interface concept, the type of services used, the data model of the interface, technologies & protocols utilized, etc. as well as a self-assessment of benefits & weaknesses for the specific practice.Note that the interface approach can be classified as follows (and as shown in Figure 1): The sample is exploratory and can be categorized as convenience sampling.The primary input stems from the participants of the IEEE P2660.1 working group [21].
Following the acquisition of the empirical data collection via questionnaires, these were firstly analyzed within their respective domain, in order to obtain domain-specific insights.Subsequently, the results were looked from a domainagnostic viewpoint, in order to identify commonalities, such as technologies, interfaces, practices etc.Having obtained the expected insights, a critical discussion follows identifying pros and cons, potential challenges and future directions.
The work carried out has several limitations.It should be pointed out that this survey does not aim at an exhaustive capturing of all practices in each domain, but some common ones.In addition, the focus is limited on the three aforementioned domains, while several others are considered as future work e.g., logistics.Another limitation of the approach is that since the sampling focuses on the IEEE P2660.1 group, it is clear that the results will reflect overwhelmingly the views of research institutes, universities and research departments within companies.Such limitations are seen as acceptable, as the aim is to gain some initial insights and the results may be the starting point for future more in-depth studies.

III. SURVEY RESULTS
Three domains were indicatively surveyed as analyzed in this section.An overview of the results is depicted in Table I.

A. Factory Automation
Eight practices (F1-F8) as shown in Table I have been analyzed in factory automation.Their Technology Readiness Level (TRL) [22] is positioned between TRL3 and TRL9, while most are of TRL4.The levels of solution robustness and technical availability are generally low.Out of the eight documented practices, 6 approaches match the coupled template (F1-F6), while two match the weak embedded template (F6-F7) and one the strongly embedded template (F8).
The analysis shows that regarding the practices that match the coupled template mostly target the interaction with conventional PLCs and, not surprisingly the functions typically used align in this direction and include: handling programs, digital I/O read/write, analog I/O read/write and the notification of events.Several custom data types are considered.Java is the prevalent technology on the agent side and, as mentioned, PLCs supporting IEC 61131-3 are frequently used without any vendor preference.The agent to PLC interaction mechanism makes use of conventional communication protocols.The practices matching the weak embedded template follow a similar line but here on practice reported the use of Raspberry Pi controllers.Only one strong embedded practice was reported and in this instance a custom software stack was developed for native applications supported by the JAMAICA VM over Linux.Overall the generic interfacing aspects do not seem to be mature.

B. Power & Energy Systems
Four practices (P1-P4) were analyzed related to power & energy systems (see Table I).All of the practices can realize a coupled interconnection of the agent with the automation device, while P3 can also facilitate the embedded paradigm.The technological maturity varies considerably among them: one is found at TRL 6 and the rest between TRL 2 and 4.
The analysis indicates that the coupled interface practices are based on libraries of software that are incorporated as directories of the host program defining the agent entity.On the automation device side, IEC 61499 and IEC 61850 are the basis for practices P2 (potentially) and 3, IEC 61499 and IEC 61131-3 are used in practice P4, while Modbus is preferred in practice P1.Monitoring and controlling digital I/O variables is common ground in all four practices.Practice P2 can be described as the most interactive of the ones gathered in this domain, since it can go as far as handle the execution of programs on the automation device side, if the agent requires so.Handling of event notifications in practices P3 and P4 may be attributed to the well-defined Application Programming Interface (API) that is available in these interface examples.All of the practices, regardless of coupled or embedded operation with the agent, are programmed in or as highlevel languages making them easier to use.It is interesting to note that practice P2 interacts with the device through a USB communication channel and practice P4 on a RS-232 protocol.The surveyed experts' opinion on these practices pointed out the opportunity for promoting them as readily applicable agent-automation interfaces, although the security of their implementation is a matter of concern.
One fifth interface practice (not analyzed separately Table I) is the OpenMUC software framework [47].OpenMUC, when enabled over the Modbus/TCP communication protocol, is built over JaMod (practice P1).

C. Building Automation
A total of five practices (B1-B5) as shown in Table I have been analyzed in the building automation domain.Their TRL is positioned between TRL3 and TRL9 with a prevalence of TRL4 and the levels of solution robustness and technical availability are generally low or moderate.Out of the five documented practices, two approaches match the coupled template (B1-B2), with one being considered as loose-coupled since it uses a broker approach, while B3-B5 match the weak embedded template.
The analysis shows that regarding the practices that match the coupled template target the interaction with monitoring of home environmental parameters and the control of devices, namely those considering the KNX protocol.Not surprisingly the functions typically include: digital I/O read/write, analog I/O read/write and the notification and subscription of events.Several custom data types are considered.Java is the prevalent technology on the agent side and, diverse device types are frequently used.The agent-to-device interaction mechanism make use of conventional communication protocols, particularly the ones based on TCP/IP.Both physical and wireless communication environments were utilized while the last is also considering the trending use of the publish/subscribe architectural approach.The practices matching the weak embedded template follow a similar line, i.e., in the diversity of device types.Here, the practices reported make use of newly devices, particularly the Raspberry Pi controllers, where it is possible the direct deployment of the agent compiled execution code.Overall the generic interfacing aspects do not seem to be mature, except the one offered by a commercial company.

IV. DISCUSSION
A first observation on the surveyed interface practices is that Java is predominantly utilized as the agent-side technology, followed by C++.This emanates a requirement for interfaces that can be incorporated as high-level programming appendices -most probably as libraries.In turn, such a requirement raises the question of whether a "best practice" proposal should also suggest how such a collection of appendices should be organized, both in terms of content and architecture.
Most analyzed interfaces follow the coupled approach, i.e., remote access to the physical hardware device.Some interfaces prefer the weak embedded template, while the strong embedded interface is barely considered.The aforementioned statistics imply that, usually, the interface of industrial agents in the context of CPS is not used for (hard) real-time control applications.This may be attributed to the general characteristics of services, control and operations, which the overlying agent system implements.If the events and actions that the agents respond to are in the time-frame of seconds to minutes (or more), an embedding interface practice that can handle fast implementation (compared to coupled) is, practically, obsolete.Although one could object that interface practices that enable strong embedding would offer maximum flexibility, the argument that customization of the interface to any specific automation device is required, counters this approach for multiple reasons.
From the perspective of information exchanged over the interface, it seems that all practices, at the absolute minimum, can handle read/write operations on the digital I/O interaction of the automation device with the controlled assets.All other device services vary from one interface to another, although some characteristics may attest to underlying trends (e.g., an API-enabled interface tends to be capable of some handling of events monitored through the device).Since, the digital I/O interaction of the automation device can be considered as a basic operation, all interface practices of such devices with a controlling agent should agree on a standard protocol [48]  [44]- [46] weak embedded and/or a common ontology, regardless of the programming language or other parameters.
A pertinent question that arises from this analysis is that more elaborate services are not used, e.g., handling programs, as well as the publish/subscribe mechanisms.This probably can be justified by typical functions associated to software agents when interacting with low-level automation functions, but is also justified by the immature technologies to support the interfacing.At the moment, the emergence of Industrial Internet of Things (IIoT) technologies offering a plethora of new capabilities, e.g., in terms of event-driven mechanisms, will permit to extend the use of more elaborate functions.Furthermore, it's expected that, for particular tasks, the agent's interfaces practices will be adjusted to future evolution in the IoT architectural trends, following possibly a more looselycoupled approach where the agent-device interface is done through communication brokers.
The reported interfaces use usually a kind of proprietary protocols, but some others prefer the use of more standardized ones, such as OPC UA or IEC 61850.This last option is preferred since it facilitates the industrial adoption.In fact, ISO 9506 [49], known as MMS (Manufacturing Message Specification), was a predecessor in this field by defining the application layer of the ancient MAP (Manufacturing Automation Protocol), and consequently providing a platform capable to interconnect various industrial computerized devices supplied by different suppliers.The guidelines defined by ISO 9506 can be used as source of inspiration in this work.
A major concern noticed by the surveyed experts is the security of the interface practices collected, which may be further amplified as the controlled devices may rely in critical infrastructures.Ensuring that both the agent decisions passed through the practice to the automation device, as also the feedback from the device to the agent should be ascribed to some security best practices and risk analysis procedures.
Apart from the general lack of common APIs and information exchanged [48], another issue raised is that of compatibility testing, especially when this pertains cross-language interactions as well as the interactions at agent or device level.This is mostly a result of lack of common APIs and best practices.However, the adoption of a testing approach e.g., based on ISO-29119 [50] set of standards, may enhance interoperability both at agent-to-physical device level via their interface, as well as between the agent-to-agent interactions.Such software tests, could also be expanded to concrete usecases and industries, depending on their requirements.The overall result would be not only to have a "best practice" on how to couple industrial agents with low level automation functions, but also detailed testing suites and processes that guarantee the applicability of these practices and the interoperability and quality on software life-cycle Such testing approach ought to complement the technology specific ones that might exist for each practice.It has to be pointed out though, that this might be a challenging undertaking, as even ISO-29119 faces critique on aspects pertaining context driven testing.

V. CONCLUSIONS
This paper describes a survey undertaken to analyze the current practices on interfacing software agents and lowlevel automation functions, in a CPS context.The collected empirical data for three domains, i.e., factory automation, power & energy systems, and building automation, allowed to identify commonalities that posteriorly will support the proposition of a "best practice".
The main observations extracted from the analysis of the reported interfaces are the overwhelming use of Java and C++ as programming languages to implement the software agents, the preferable use of the couple approach, the use of proprietary protocols for the interface, the focus on I/O functions and the missing security issues in the reported practices.However, probably the main conclusion extracted from this survey is that the final result would be not only to have a "best practice" on how to couple industrial agents with low level automation functions, but instead a set of "best practices" designed according to the domain and the application characteristics.This requires testing methods to support a recipe to select the best interfacing practice according to several input parameters that defines the application scenario.
Future work will be devoted to enlarge the sampling, particularly capturing other views from research institutes, universities and research departments within companies, and to derive the "best practices" to implement the interfacing between software agents and low level automation functions at large and for each specific domain.