# Architecting an Agent-Based Fault Diagnosis Engine for IEC 61499 Industrial Cyber-Physical Systems
###### Abstract
**RQ2:** _How do we architect a software agent to observe the data that is flowing between function blocks so that it can recognise fault evidence?_ Agents exhibit intentional behaviors that enable them to pursue goals and make decisions that modify their actions. To reason about faults, agents need to be able to capture information flowing between FBs. Section 3.4 explores the Diagnostic Point (DPs) that are a key feature of the engine, explaining how the agents autonomously deploy these custom FBs into an FB application to capture real-time fault telemetry. **RQ3:** _How can a fault diagnostic engine that implements the features identified in RQ1 and RQ2 be architected?_ Section 3 profiles the architecture in detail, showing how the Views and Beyond methodology [10] was used to guide and document the design. **RQ4:** _How do we evaluate the architectural decisions made to satisfy RQ1 and RQ2?_ The ATAM evaluation and the prototyping of key parts of the engine are discussed in Section 4. These processes refined both the agents themselves and the way they exchange information with the FBs being examined. This led to a more robust and versatile architecture. The ATAM presents scenarios that show how the features of the architecture satisfy both the functional and quality requirements for the engine. It demonstrates how the risks, sensitivities and trade-offs uncovered drove the architectural design choices that were made. This paper illustrates how Attribute-Driven Design (ADD) [11] and the Views and Beyond methodology were coupled with prototyping to architect the engine through iterative design steps. By creating a range of complementary artefacts that present features as distinct _views_, architects make it easier for stakeholders to understand the reasons why features should be implemented in the ways proposed. Thinking about non-functional requirements as Quality Attributes (QAs) that can be evaluated empirically led to the creation of a more robust architecture. The complete Software Architecture Document (SAD) is available on Mendeley Data [12] to complement the exploration of the architecture presented in this article. Each recommended section of the Views and Beyond document template was carefully replicated as an exemplar to help other practitioners. The resulting document illustrates the scope and maturity of ADD and Views and Beyond, which has continued to guide the on-going development of the engine. The primary contribution of this paper is its presentation of the architecture for a fault detection engine in a well-structured Software Architecture Document that draws on recognized industry standards. It describes the way the agents apply domain-specific knowledge during fault finding for ICPS. When agents are deployed by the engine, they first explore the IEC 61499 application definition files of the ICPS that will be diagnosed. They then build sets of beliefs about the FBs and how they are connected to each other. This creates a navigable in-memory representation of the FB application that captures what they believe. This later guides their search through fault paths while they determine if each FB is performing nominally. The agents deploy DPs by wiring them dynamically into the data and event streams of a FB. Each DP operates as a native FB, passing data transparently through itself while also relaying that data back to the agent that is monitoring the DP. When commanded by an agent, sets of DPs can isolate or _gate_ sections of the FB application. The agents then examine either individual or logical groups of FBs that are exhibiting fault symptoms, exercising them with pre-defined diagnostic tests. The DPs exhibit low-latency and impose a minimal overhead on the FB application. This approach illustrates how agents can dynamically investigate systems, reconfiguring the control layer from the agent's execution layer. This represents a significant enhancement of the interaction scheme employed in [PERSON] et al. (2013); [PERSON] et al. (2014) and [PERSON] (2015).