Enterprise Architecture analysis using Fault Trees and MODAF Ulrik Franke, Pontus Johnson, Evelina Ericsson, Waldo Rocha Flores, and Kun Zhu? Industrial Information and Control Systems, Royal Institute of Technology, Stockholm {ulrikf, pj101, evelinae, waldorf, zhuk}@ics.kth.se Abstract. Analysis of dependencies between information systems, busi- ness processes, and strategic goals is an important part of the discipline of Enterprise Architecture (EA). However, EA models typically provide only visual and qualitative decision support. This paper shows how EA frameworks for dependency analysis can be extended into the realm of quantitative methods by the use of techniques from Fault Tree Anal- ysis (FTA). Using MODAF, the UK Ministry of Defence Architecture Framework as an example, we give a list of criteria for the extraction of a metamodel for FTA use, and provide such a metamodel for MODAF. Furthermore, we use this MODAF FTA metamodel to perform depen- dency analysis on a sample MODAF model. Keywords: Enterprise Architecture, Fault Tree Analysis, dependency analysis, MODAF 1 Introduction During the last decade, Enterprise Architecture (EA) has grown into an estab- lished approach for management of information systems in organizations. EA is model-based and does not only increase the general understanding of an orga- nization’s business and information system landscape, but also aids in decision making. Formal analysis approaches for EA [1], including sub-disciplines such as maintainability [2] and interoperability [3], are a growing field. MODAF, the Ministry of Defence Architecture Framework, is designed to support the creation of an enterprise architecture for the British Ministry of Defence. Dependency analysis, i.e. the connection of high level concepts such as strategic capabilities (airlift, search and rescue, etc.) with the detailed and precise concepts that constitute low level technical systems (particular vehicles, radars, IT systems, etc.) has been identified as a key use of MODAF [4]. The present paper proposes an improvement and formalization of EA depen- dency analysis by methods from Fault Tree Analysis (FTA). FTA is a combi- natorial model of systems dependability, widely used for safety and reliability ? The authors gratefully acknowledge the useful comments provided upon the present work by Mathias Ekstedt, Per Närman, Teodor Sommestad, and Johan Ullberg. Proceedings of CAiSE Forum 2009 61 evaluations [5]. The method translates the failure behavior of a physical system into events connected by arcs. A visual model portrays the relationships in an accessible way, while a corresponding logical model enables quantitative evalu- ation. More details on FTA can be found in [6]. This paper aims to extend the EA analysis toolbox with the FTA method, enabling more powerful dependency analysis. MODAF is used as a running example. The remainder of this paper is structured as follows. Section 2 contrasts the present paper with some related work. Section 3 is the locus of the main contribution, describing how to map MODAF models into fault trees. Section 4 gives a practical example of the method. Section 5 discusses the contribution and concludes the paper. 2 Related work Model based generation of fault trees has been previously addressed. [7] describes generation of dynamic fault trees from data flow models. In [8], fault trees are extracted from UML system models. However, such fault tree derivation is often time-consuming and error-prone due to complex component interactions. Thus, [9] proposes more automation, viz. an algorithm for fault trees generation from Little-JIL process definitions. The present contribution goes beyond the scope of technical systems and processes directly supported by these systems, extending FTA into the realm of Enterprise Architecture. 3 A metamodel for the use of FTA in MODAF In this section, the possibility of mappings between MODAF models and fault trees is discussed. Criteria for the use of FTA in MODAF are listed, and a metamodel based on these criteria is then presented. 3.1 Selection criteria While FTA is a formal, mathematically precise method, MODAF models span wider fields (viz. all activities of the UK Ministry of Defence) and are as a consequence less clear-cut. We therefore define a list of selection criteria for identifying MODAF Meta Model (M3) objects appropriate for use in FTA. Criterion 1 (Causal chain). M3 objects relevant to FTA must be part of a causal chain connecting technical systems to higher level concepts on the way to the strategic enterprise goals from the MODAF Strategic view. Criterion 2 (Proper abstraction). M3 objects relevant to FTA must not make the overall architecture unnecessarily detailed. Criterion 3 (Relevance to failures). M3 objects relevant to FTA must have at least one of the following properties (i) be the subject of failure (prospective fault tree events) or (ii) be able to transfer failures (prospective fault tree arcs). Proceedings of CAiSE Forum 2009 62 Criterion 4 (Concreteness). M3 objects relevant to FTA must be on the level of concretion normal to FTA. Criterion 5 (Binary fault states). M3 objects relevant to FTA must, when instantiated as fault tree events, have the binary fault states non-failed and failed. 3.2 Creating the metamodel Using the M3 objects (entities and relations) thus selected, we build a metamodel for the use of FTA in MODAF. This entails a final delimitation: Criterion 6 (Connectedness). M3 objects relevant to FTA must not be soli- taire with respect to the whole set of such M3 objects. For event objects, this means that at least one arc object has to point to it. For arc objects, this means that it has to connect two event objects (not necessarily distinct). The metamodel created by application of criteria 1 through 6 is illustrated in Fig. 1. Objects removed by criterion 6 are listed to the left in the figure. Strategic Enterprise CapabilityDependency Goal Capability ActivityMapsToCapability Enduring StandardOperationalActivity Task CapabilityForNode* OperationalActivityAction*, Information ActivitySubject Actual ActivityComposition Material EnergyFlow*, Logical Element Organisation Flow Information Flow* odeLifeLine Exchange*, OperationalN Operational NodeType OperationalActivityAction* Activity Logical Operational ActualOrganisation Relationship Composition Architecture Interaction Configuration Operational Specification Actual Deplyed, Interaction Operational NodeHas Configuration Specification, Competence Consumes, NoLongerUsed Activity Behaviour OperationNode Operational Provides LifeLine Mission Activity CompetenceForRole* Action* Information OperationalActivityFlow Exchange LogicalFlow* ActualPost Message ActivityTo Commands* Capability Service FunctionMapping Commands* DataElement Controls* Controls* Configuration ResourceUsage* ResourceUsage* Resource ServiceFunctionTo Usage Resource Physical Platform e FunctionMapping sa g C Interaction DataModel u rc eU R e o mm Re so Human so u a r ce n d s System Controls* Fielded ResourceUsage Resource Us ag Function e ResourceUsage Capability Controls* Controls* ResourceUsage* ServiceFunctionTo Physical ResourceUsage* Controls* Physical FunctionMapping ResourceUsage* Architecture Asset Controls Controls* Controls Resourc * ResourceUsage ResourceUsage* eUsage* Software System Fig. 1. A metamodel for the use of FTA in MODAF. The objects listed to the left are the solitaires excluded by criterion 6. Note the singleton Service element. 3.3 From metamodel to fault tree Given a MODAF model and the metamodel illustrated in Fig. 1, the following algorithmic procedure allows the creation of a fault tree for dependency analysis. Proceedings of CAiSE Forum 2009 63 Events Starting from an existing MODAF model, identify the entities that are instantiations of entities found in the FTA metamodel (Fig. 1). We now have an event set. Arcs Similarly, identify the relations that are instantiations of relations found in the FTA metamodel (Fig. 1). We now have an arc set. Gates For each relation connecting two entities, take the causally descendant entity and consider together the whole set of arcs connecting it to antecedent entities. Partition this set into OR or AND gates. The degenerate parti- tioning of the whole set into one single gate is allowed, as is partitionings including singletons, i.e. gates corresponding to the identity relation. The procedure is iterated until all arcs in the arc set have been mapped to gates. Of course, this procedure cannot do away with the requirement of expertise and acquaintance with the system modeled. It does, however, provide a template and a coherent process for the generation of fault trees from MODAF models. 4 Dependency analysis of Search and Rescue capability This section presents a practical example of how FTA formalism can be employed for dependency analysis of an existing MODAF model. We use a Search and Rescue (SAR) example created by the VEGA Group under contract to the UK Ministry of Defence [10], illustrating a maritime search and rescue operation at sea. The scenario involves a monitoring unit, a yacht in distress, a Command and Control (C2) center, a helicopter, and a lifeboat. Now, we employ the FTA usage method from the previous section. Figure 2 illustrates the process of going from the initial MODAF model (1. in the figure), viz. a top to bottom dependency diagram from [10], via the FTA metamodel (2.) developed in the previous section, to a full blown fault tree (3.). The Maritime SAR capability is described by Search, Assistance, and Rescue sub-capabilities, connected to the top event, i.e. failure of the maritime SAR ca- pability, through an OR gate. OR gates are used for faults acting independently of each others, AND gates are used for failures acting in concert. For brevity, we have left the Assistance and Rescue capabilities undeveloped further down the tree. Instead developing the Search capability into sub-events, we proceed down through the Operations and System views until we reach basic events. This example illustrates the process described in the previous section. The fault tree generated, as depicted in Fig. 2, enables not only qualitative depen- dency analysis, as does standard MODAF models, but also quantitative analysis. If the fault distributions of the components whose failures constitute the basic events are known, the impact of these distributions on the maritime SAR ca- pability can be calculated. Decisions on procurement and maintenance of low level technical systems can thus be optimized with regard to the actual capa- bility they are to support, rather than an intermediate proxy. Not the least, this allows rational prioritization when it comes to trade-offs between different systems. Proceedings of CAiSE Forum 2009 64 <> has sub-capability <> Aeronautical SAR UK SAR Capability <> SAR Top to Bottom Dependencies This diagram shows an example of tracing dependencies from capability down to 2. Filtered system port interconnections has sub-capability has sub-capability <> contributes to through <> <> <> MODAF FTA Search Find victim Generate distress signal Distress Signal Monitoring undertakes undertakes <> NIMROD MRA has part realises <> Search node needline distress signal <> Person in distress realises <> Person in distress metamodel Strategic Strategic Enterprise Enterprise CapabilityDependency CapabilityDependency Goal Goal Capability Capability ActivityMapsToCapability ActivityMapsToCapability Enduring Enduring StandardOperationalActivity StandardOperationalActivity <> <> Task Task NIMROD Airframe Yacht CapabilityForNode* CapabilityForNode* OperationalActivityAction*, ActivitySubject ActivitySubject OperationalActivityAction*, Information Information Actual Actual ActivityCompositionActivityComposition Material Material Element Element 1. Initial MODAF EnergyFlow*, EnergyFlow*, Logical Logical Organisation Organisation Flow Flow Information Information Flow* Flow* Exchange*, Exchange*, alNodeLifeLine Operation OperationalNodeLif eLine Operational Operational NodeType NodeType OperationalActivityAction* OperationalActivityAction* Activity Activity Logical Logical Operational Operational ActualOrganisation ActualOrganisation Relationship Relationship Composition Composition Architecture Architecture Interaction Interaction Configuration Configuration Operational Operational Specification Specification Actual Actual Deplyed, Deplyed, Interaction Interaction Operational Operational hosts has part NodeHas NodeHas Configuration Configuration Specification, Specification, Competence Competence Consumes, Consumes, Activity Activity Behaviour Behaviour NoLongerUsed NoLongerUsed OperationNode OperationNode Provides Provides LifeLine LifeLine Operational Operational Mission Mission Activity Activity CompetenceForRole* CompetenceForRole* Information Information Action* Action* Exchange Exchange LogicalFlow* ActualPost LogicalFlow* ActualPost OperationalActivityFlow OperationalActivityFlow <> <> <> <> Message Message Service Service ActivityTo model Sensor Suite Process Signals Emit distress transmission Yacht Commands* Commands* Commands* Commands* Capability Capability FunctionMapping ActivityTo FunctionMapping DataElement DataElement Controls* Controls* Controls* Controls* Configuration Configuration ResourceUsage* ResourceUsage* ResourceUsage* ResourceUsage* Resource Resource ServiceFunctionTo ServiceFunctionTo Physical Physical Platform Platform Usage Resource Usage Resource e e FunctionMapping FunctionMapping ag ag Interaction Interaction DataModel DataModel Us UsRe Comm Co Re mm urce urce Systems Systems sourc an sourc an Controls* Controls*Reso Re so eU ds eU ds Fielded FieldedResourceUsage ResourceUsage Human sage Human sage ResourceUsage ResourceUsage has sub-system provides hosts Capability Capability Function Function provides Controls* Resource Controls* Resource Physical Physical Physical ResourceUsage* Physical ResourceUsage* Controls* Controls* Controls* Controls* ServiceFunctionTo ServiceFunctionTo Architecture Architecture Asset Asset ResourceUsage* ResourceUsage* ResourceUsage* ResourceUsage* FunctionMapping FunctionMapping Controls Controls* Controls Controls* Controls* Controls* ResourceUsage ResourceUsage* ResourceUsage ResourceUsage* ResourceUsag ResourceUsag e* e* <> offers <> Software Software System System system connection <> offers <> ESM System Frequency Scanner Transmitter Distress beacon distress signal 3. Created fault tree <> Maritime SAR Strategic OR <> <> <> Search fails Assitance fails Recovery fails OR OR OR <> <> <> <> <> <> <> Monitor Victim Prepare to receive Recover Victim Provide Medical Assist Victim Find Victim fails Track Victim fails fails Victim fails fails Assistance fails fails Operational OR <> <> <> <> <> <> Monitor for Assign SAR Generate distress Plan SAR Control SAR Monitor SAR distress signal assets to signal fails operation fails assets fails assets fails operation OR OR <> <> The Monitoring Command and Unit fails Control Center fails OR <> <> Air Sea Rescue RNLI Lifeboat fails Helicopter fails System AND <> <> <> <> <> Track info from Distress signal Communication GPS Navigation Voice radio fails monitoring unit fails System fails Aid fails fails OR OR <> <> <> <> <> <> Display waypoints Receive GPS Calculate course Display course Transmit radio Receive radio fails Broadcast fails and position fails and position fails waves fails waves fails Fig. 2. The process of generating a fault tree interconnecting the System, Operational, and Strategic viewpoints of MODAF. The initial MODAF model is taken from [10]. Proceedings of CAiSE Forum 2009 65 5 Discussion and conclusions MODAF was developed to support the modeling needs of the UK Ministry of Defence, while Fault Tree Analysis is a well-defined mathematical hazard analysis technique. The present contribution attempts to bridge this gap in several ways. First, there is a gap of abstraction: the MODAF Meta Model is a metamodel, whereas FTA is generally performed on concrete instances – models – of technical systems. This is bridged by the creation of a smaller metamodel aimed specif- ically at FTA usage. Second, there is a gap of expressive power: FTA is much less expressive as a language than is MODAF. This is bridged by the algorithmic procedure for creating a fault tree out of an existing MODAF model. The contribution of the present paper is three-fold: (i) The feasibility of ex- panding Fault Tree Analysis to strategic level enterprise architecture objects, usually considered too abstract for FTA, has been demonstrated. (ii) A meta- model for FTA use in MODAF has been proposed. (iii) A method for generation of fault trees, starting from the FTA metamodel in conjunction with an exist- ing MODAF model, has been provided, thus allowing MODAF users to perform dependency analysis using the FTA technique. References 1. Johnson, P., Lagerström, R., Närman, P., Simonsson, M.: Enterprise architecture analysis with extended influence diagrams. Information Systems Frontiers 9(2) (May 2007) 2. Lagerström, R., Johnson, P.: Using architectural models to predict the maintain- ability of enterprise systems. In: Proceedings of the 12th European Conference on Software Maintenance and Reengineering. (April 2008) 3. Ullberg, J., Lagerström, R., Johnson, P.: A framework for service interoperability analysis using enterprise architecture models. In: IEEE International Conference on Services Computing. (July 2008) 4. Ministry of Defence: MOD Architecture Framework version 1.2.003. Technical report, Ministry of Defence, UK (September 2008) 5. Ericson, C.: Fault tree analysis – a history. In: 17th International System Safety Conference. (1999) 6. Codetta-Raiteri, D.: Extended Fault Trees Analysis supported by Stochastic Petri Nets. PhD thesis, University of Torino, Torino, Italy (2005) 7. McKelvin, M., Pinello, C., Kanajan, S., Wysocki, J., Sangiovanni-Vincentelli, A.: Model-based design of heterogeneous systems for fault tree analysis. In Rodney J. Simmons, Ph. D., C., Gauthier, N.J., eds.: 24th International System Safety Conference, System Safety Society (August 2006) 400–409 8. Pai, G.J., Dugan, J.B.: Automatic synthesis of dynamic fault trees from uml system models. In: Proceedings of the 13th International Symposium on Software Reliability Engineering (ISSRE’02). (2002) 9. Chen, B., Avrunin, G.S., Clarke, L.A., Osterweil, L.J.: Automatic fault tree deriva- tion from little-jil process definitions. In: SPW/ProSim. (2006) 150–158 10. VEGA Group (contracted by UK MOD): Search and Rescue Example. Available on http://www.modaf.org.uk/vExamples/163/search-and-rescue-example, ac- cessed November 14, 2008 (Crown Copyright 2004-2008) Proceedings of CAiSE Forum 2009 66