# Architecting an Agent-Based Fault Diagnosis Engine for IEC 61499 Industrial Cyber-Physical Systems
## 3 Architecting the Engine
ISO Standard 25010 defines and standardizes categories of quality attributes so that they can be used consistently by architects and understood by stakeholders [67]. While architecting the engine, the desired quality attributes were established by working alongside stakeholders in structured Quality Attribute Workshops (QAWS) [68]. The architecture was then evaluated through scenarios that were created using the Architectural Trade-off Analysis Method (ATAM) [69]. The ATAM provides a step-by-step method of validating an architecture empirically. The IEEE Standard 610 qualifies this definition of a requirement further, asserting that a requirement should be a \"documented representation\" of a need ([60], p. 65). [PERSON] et al. caution that all the effort put in by the architects is wasted if the documentation they produce cannot be understood later by developers [10]. By describing the structure of each architecturally-significant feature, architectures provide the framework needed to reason about the elements that make up a system, how they interact and how well they meet the objectives demanded of them [66]. Hence, the role of a software architect is to propose and document a solution by blending different, well-proven architectural styles. The Views and Beyond approach was used to create the Software Architecture Document (SAD) [70]. Applications such as the engine are too complex to be captured in any single diagram. Architects address this complexity by delivering a set of _Views_, structured descriptions of subsets of related architectural features. Each view is presented from the perspective or _Viewpoint_ of a particular stakeholder. Since stakeholders have different concerns and interests, a view illustrates how that part of the architecture addresses their needs. Figure 3 illustrates how in Views and Beyond, [PERSON] et al. extend the \(4+1\) Views Model of Architecture proposed by [PERSON] [71] to incorporate Rozanski and Woods seven distinct architectural viewpoints [72]. The Viewpoint Catalogue of Rozanski and Woods is explored in more detail in Section 1.3 of the SAD. The diagram shows how the stakeholders' viewpoints are considered in the light of the ASRs. The _View Packets_ are the smallest piece of information a stakeholder requires, presented from a particular viewpoint [73]. They are detailed on the right of the diagram, showing the view packets contained in the SAD that detail an aspect of the architecture. Inside each view packet, the rationale behind each feature is explained, providing diagrams that present each element used in the architecture [64]. Figure 3: From viewpoints, architecturally-significant requirements and views to view packets. SysML diagrams were adopted as a way of of presenting the elements of an architectural feature in a consistent way. SysML is an extension of the UML modeling language defined in the ISO 19514 standard [74; 75]. SysML extends the range of UML diagrams to add Activity, Requirement and Block diagram types which are ideal for describing systems-of-systems architectures such as the engine. UML and SysML both encourage systematic naming conventions for elements and the diagrams which contain them.This makes it easier to build the Views and Beyond Element Catalogues in the SAD that describe each view. For every view in the [PERSON] \(4+1\) model, there are well-known UML or SysML diagrams that have been adopted to document the elements appropriately in that view. The SAD is intended to provide a single-source of truth to capture the needs of the stakeholders and propose architectural solutions to those needs. In doing that, the architects carefully treat a fine line between providing just enough detail without over-architecting the design. Doing so would constrain the ability of the developers to make their own decisions about how the code should implement the design. Architecture is concerned with the external characteristics of elements. In contrast, developers create the internal implementation of elements to realize those external characteristics.