# Architecting an Agent-Based Fault Diagnosis Engine for IEC 61499 Industrial Cyber-Physical Systems
## 3 Architecting the Engine
### The Process View  
The Process View of the architecture focuses on processes that execute in the engine that support fault-finding. The view corresponds to [PERSON] and Woods Information and Concurrency Viewpoint, detailed in Section 1.5 of the SAD. The SAD presents the operation of the agents and the DPs in two separate view packets.  
Prototyping the agents and DPs during the ATAM evaluation of the architecture led to significant refinements. The _DiagnosticTeam_ component is responsible for creating the team of agents and assigning goals to them. However, the Open Source version of GORITE does not provide a way of implementing multiple agent instances that can be multi-threaded. Each goal is implemented as a class with an \(execute()\) function that is designed to operate until the status of the goal changes. That implies that different agents cannot perform their goals in parallel if they are both operating on the current GORITE thread. The prototype single agent performed three goals successfully that included the configuration of the FB application, watching for simple faults and then reporting them. The ATAM identified that this did not address the quality attributes including Concurrency and Scalability. These could not be satisfied by executing agents on a single execution thread. The agents also need to be able to persist their own private copies of resource objects, each with their own state management requirements. Instantiating agents on their own threads demanded a Trade-Off that led to a different goal structure for the Team manager. Figure 6 details the revised interaction between the Team Manager Agent and the Diagnostic Agents.  
This included the extension of the set of GORITE Goals states to include a new \(EXECUTING\) status. The Team Manager Agent executes a set of GORITE Sequence Goals named \(Manage\) where the role of the team manager is to assign goals to available agents and monitor their progress. Each named agent instance provides a set of thread-safe synchronized methods that ensure the setting and reading of the \(AgentState\) and \(GoalState\) agent properties are interleaved appropriately. Agents execute goals such as \(Configure\), \(Monitor\), \(Diagnose\) and \(Analyse\), transitioning from first configuring the FB application,  
Figure 6: GORITE Team, agent, and diagnostic point processes across the execution layers.  
then watching the telemetry streams and intervening whenever fault evidence is observed. Each transition to a new goal is initiated by reporting via the _AgentState_ that the current goal is no longer being executed, whereupon the Team Manager Agent evaluates the goal status reported by the agent in _GoalState_ and assigns a new goal. Five agents were prototyped for an ATAM scenario and evaluated with GORITE on its own thread and its own set of management goals. No collisions or conflicts were observed. This new configuration now positions the Team Manager as an agent in its own right, co-ordinating multiple agents and freeing each agent to manage the state of the resources it instantiates. ATAMs do not usually involve a prototyping phase; however, the prototypes provided valuable quantitative feedback to justify the architectural changes needed that the ATAM had identified.