Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS) Conditional Based Maintenance Plus (CBM+) Communications Architecture Modeling and Simulation with Decision Support Technology Jack Li Walter Lucchesi Peter Johnson US Army RDECOM CERDEC Space and Terrestrial Communications Directorate (S&TCD) Fort Monmouth, New Jersey 07703 Dr. Stanley Smith, S. H. Smith Associates, Montville, NJ Dr. Jeffrey Halle, EOIR Technologies, Eatontown, NJ Joseph Pasirstein, Systems Automation Associates (SAA) LLC, Parsippany, NJ ABSTRACT Architecture, Modeling & Simulations (AMS) in conjunction with decision support technologies are crucial to ensure successful execution on the CBM+ vision. Currently, stove-pipe CBM+ enabled platforms compete for inadequate network resources creating risks for Global Combat Support System - Army (GCSS-A) network availability, creating the inability for CBM+ data to reach the Logistics Support Activity (LOGSA). The inability of server replication could result in missing or conflicting CBM+ data for weapon system health management status reporting. A fundamental CBM+ Communications infrastructure/architecture is needed to bridge the gaps between the network and applications. This paper will discuss the high level methodology evolutionary approach to this problem in terms of architecture engineering, architectural modeling and simulation (M&S), decision support, and information assurance in detail based on the CBM+ efforts that we have accomplished so far. INTRODUCTION CBM+ is a proactive equipment maintenance process that uses sensors and system health indicators to predict functional failure prior to a failure event, thereby enabling maintenance personnel to take appropriate preemptive action. CBM+ improves equipment combat effectiveness, enhances safety and reduces life-cycle costs. The US Army REDCOM CERDEC S&TCD provides subject matter expertise (SME) in System of Systems (SoS) communications architecture integrated into the tactical Army, Information Assurance (IA), and tool sets to design, model, and analyze the communications architectures and networks to support developing CBM+ applications. This continuous and dynamic effort will change to support increased CBM+ density of applications, platforms, and equipment. The architecture development will support existing data strategies, LOGSA Taxonomy, Ontology/Semantic Web efforts, and Machinery Information Management Open Systems Alliance (MIMOSA). The results will bring a coherent integration to diverse data application efforts that lack SoS integration & interoperability. Results will be engineered through DODAF based architectural artifacts and set up on a web portal for the CBM+ stakeholders and consumers. This communications architecture and related engineering efforts will support an efficient, effective, and successful CBM+ implementation. The objective of our effort is to develop a communications architecture that will integrate with the Army Integrated Logistics Architecture (AILA) and meet CBM+ requirements such as improving operational availability, reducing logistic footprint, reducing O&M cost, speeding up decision support cycle using high level methodology evolutionary approaches such as Architecture Engineering, Modeling and Simulation, and Decision Support shown in Figure 1. We initiated investigation of existing CBM+ Architectural issues, gaps, existing architectures, and tools. As a result, we identified several communications and communications-related architectural issues that require architecture engineering analysis either prior to or Conditional Based Maintenance Plus (CBM+) Communications Architecture Modeling and Simulation with Decision Support Technology Page 1 of 7 Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS) concurrent with the development of the communications architecture. These issues [4] lie in the areas of (1) above platform infrastructure ownership and composition; (2) Very Small Aperture Terminal (VSAT) and satellite bandwidth requirements; (3) Service Oriented Architecture (SOA)/ Enterprise Service Bus (ESB) definition and ownership; (4) data requirements including methods for efficient transmission such as compression for platform data collection; (5) validity of existing Department of Defense Architecture Framework (DODAF) architectures (e.g., network communications architecture); (6) Cross-Domain Guard issues and (7) other information assurance (IA) issues ensuring the confidentiality, integrity, authentication, availability, and non-repudiation of the platform data. These issues are to be analyzed and socialized by applying engineering principals and rigor to Engineering of communications architectural related artifacts as well as the development and socialization of solutions sets. We believe this effort can make significant contributions to the CBM+ program beyond the development of communications architecture. Working relationships have been established with key stakeholders for our CBM+ efforts to ensure their requirements are met. We have participated in on-going Common Logistic Operating Environment (CLOE) Threshold Capability Integration (TCI) workgroup meetings as well as upcoming meetings such as the Communications Workgroup meetings. ARCHITECTURE ENGINEERING Using the Department of Defense Architecture Framework (DoDAF) 2.0 released on May 28, 2009, we have created front-end architecture requirement definition matrices such as (1) intended use and applicable artifacts, (2) artifacts and consumers and (3) artifacts and developers or maintainers to gather the requirements for DoDAF views (e.g. AV-1, SV-1, and SV-2) as shown in Figure 2. Along with the existing architecture analyses, this approach not only leads to integrated design with the existing architecture, but also identifies gaps and issues. This methodology requires use of modeling and simulation (M&S) and Decision Support tools to assist in the architecture design and optimization. Figure 2: CBM+ Communications Architecture Development Approach [1] Based on the initial AILA CBM+ architectural assessment [3], the following gaps have been identified: Completeness Gaps: (1) difficult to extract CBM+ specific IERs; (2) several important artifacts still need to be developed; (3) difficult to identify CBM+ specific information/data in the logical data model (OV-7), the physical data schema (SV-11) and the integrated dictionary (AV-2). Figure 1: High Level Methodology Evolutionary Approach [1] Consistency Gaps: (1) appears to be inconsistencies between several artifacts; (2) appears to be gaps between IERs and CBM+ needlines; (3) not all the Organizational Units’ platform sensor data needlines could be traced end-to-end Conditional Based Maintenance Plus (CBM+) Communications Architecture Modeling and Simulation with Decision Support Technology Page 2 of 7 Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS) (e.g., to the CBM+ data warehouse); (4) not all the CBM+ IERs that are identified in operational activities have operational Node-Node Connectivity. Finally, the preliminary gap impact assessments are: (1) AILA needs updates/enhancement in order for seamless CBM+ communications architecture development and integration; (2) it is essential to align & integrate CBM+ communications system views with AILA Architectures. Partnership opportunities exist to work these issues jointly with the CLOE and CBM+ communities. aircraft associated with them, and thus contain equipment for gathering and transmitting the CBM+ data obtained from the aircraft. There are three types of links in this network, Ethernet within a unit, wireless 802.11x links interconnecting the CAISI bridges, and SATCOM links between the units and the Enterprise HQ. ARCHITECTURAL MODELING & SIMULATION Aviation Baseline – Bde and Below The analysis of a complete network can be quite extensive. Based on earlier work [2], an initial estimation of what this architecture looks like was made. A preliminary analysis has been conducted using this architecture and estimates of traffic data we have obtained from the Ground and Aviation Node Baseline – BDE & Below [2]. In doing so, the source and location of bottlenecks in this network have been identified. It is anticipated that our further study will enable us to identify a methodology to alleviate the congestion enabling information to be passed and analyzed more efficiently. For this paper, we will describe the preliminary analysis of one portion of the CBM+ network, specifically the Aviation Brigade (BDE) and below. This architecture is illustrated in the top portion of Figure 3. The objective for this analysis is to understand the capacities of the network with respect to the CBM+ data, to identify the bottlenecks, and to find ways to alleviate these bottlenecks by modeling different traffic patterns, thereby, addressing the bandwidth requirement gap described in the introductory section. This network consists of several units at Brigade, Battalion, and Company level. All of the units have wireless 802.11x capability provided via Combat Service Support Automated Information Interface (CAISI) equipment to enable connectivity for Line of Sight (LOS) up to approximately 32 miles. Additionally, several units have VSAT capability to enable communications with the Enterprise HQ. Each unit contains various workstations, servers, LAN switches, and routers. Additionally, the Flight Companies have multiple Combat Aviation Bde HQ Figure 3: CBM+ Aviation Baseline – BDE and Below The primary tool utilized for this preliminary analysis is the JCSS (Joint Communications Simulation System) 9.0 (formerly known as NETWARS) from Defense Information Systems Agency (DISA). A high-level architecture structure of the network to be studied was created. It is shown in the middle portion of Figure 3. Each unit contains the detailed design of the particular architecture and connectivity for that unit. The Architecture Combat Aviation BDE HQ is displayed as an example in the bottom portion in Figure 3. Also in Figure 3, the arrow indicates how in each step the architecture has been modeled and simulated in successively Conditional Based Maintenance Plus (CBM+) Communications Architecture Modeling and Simulation with Decision Support Technology Page 3 of 7 Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS) more detail. Next, communication links among the units were created. For units equipped with VSAT, SATCOM links were created to the Enterprise HQ. IEEE 802.11x wireless links between CAISIs we employed to provide the remaining connectivity. Since these units could potentially be interconnected in a variety of routing schemes, several scenarios that differ by the routing schema were developed. Figure 4 illustrates this architecture with the connectivity displayed for one such scenario. analyze the effect of these modifications and to generate a protocol for managing the congestion. This preliminary work has identified some of the bottlenecks contained in this network, as well as providing an initial model and framework for continuing study. Further modeling and simulation studies will include propagation, terrain, background traffic effects, information assurance issues, etc. DECISION SUPPORT Figure 4: Baseline Architecture with Links and Traffic Flows The primary source of traffic on the network is the data gathered from each aircraft. The volume of data from each source is so large as to completely fill a VSAT circuit for several minutes, so the cause of bottlenecks is quite apparent. Fortunately, this data is not transmitted to the Enterprise HQ in real time, so various steps can be taken to lessen the impact. Among these measures to reduce the high data rate are spreading out the data transmission in time, data compression, traffic shaping to the interfaces to throttle the traffic flow from this data, and rerouting some of the traffic to use otherwise underutilized links. The next step of this modeling process was to create traffic flows from the sources to the destinations. These are illustrated by the dotted lines in Figure 4. (Note that there are also flows that are obscured by the solid lines that show connectivity.) Next, the parameters for these flows are modified to model the variants described in the previous paragraph, and a capacity analysis is conducted for each set. This process is repeated several times for each scenario to The System of System (SoS) enterprise architectural decision making processes are extremely complex, uncertain, and dynamic and led to unstructured and illdefined decision making. We have developed and implemented a rigorous, structured methodology to improve the decision making process. For architecture decision making process to be effective the process must be flexible (must be able to adjust the criteria, weights, etc), adaptable, provide for what-if and sensitivity-type analysis and provide the documentation supporting the decision. Everyday decision-making often seems trivial and typically follows little to no structure. This is usually acceptable for minor problems but insufficient for large scale, critical decisions, especially at an enterprise level. Turban [7] defines a Decision support system (DSS) as computer based information systems that combine models and data in an attempt to solve non-structured problem. The method described in this paper, allows for the combination of qualitative and quantitative data in it’s’ approach to decision-making. DSS are designed to be an accessory to decision makers, extend their capabilities, but not to replace their judgment. In turn, it uses these judgments to support the underlying algorithm which will compute best alternative for a given situation. A DSS multi-objective decision support tools based on the Analytical Hierarchical Process (AHP) developed by Dr Saaty [8, 9] was used for this paper. The AHP is designed to facilitate the decision making process by using both empirical data and subjective. The AHP implementation provides the subject matter experts (SMEs) with a structured means to organize and evaluate the importance of various objectives and the preferences of alternative solutions. Conditional Based Maintenance Plus (CBM+) Communications Architecture Modeling and Simulation with Decision Support Technology Page 4 of 7 Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS) The use of decision support technology [5, 6] is ideally suited for this type of decision making. An IDEF model of the seven steps in the decision support methodology is shown in figure 5. to derive the overall weight for the alternatives. The best alternative is that with the highest priority. Figure 6 illustrates an example of applying the key capabilities such as the decision hierarchy, criteria and sub criteria with their associated weights, and several sensitivity and comparative analysis modes. Figure 5: Top level Decision Support Methodology Step 1: Problem Identification and Research – the first step of the decision making process typically involves identifying the problem, objectives and alternatives and researching the alternatives. The suggestions that are discussed by Saaty [6] were followed, and were expanded upon, to eliminate possible pitfalls. Step 2: Eliminating Infeasible Alternatives – During this part of the process all the potential alternative are discussed. The SMEs determine the “Musts” for determining the criteria that must be met. Step 3: Building a Model - there is no one "correct" model for a decision. Different SMEs informed about a specific problem may structure the hierarchically differently, but if the judgments are similar, the overall answers will be similar. Step 4: Making Judgments – After the model was constructed, the architectural SMEs compared the elements at each level of the hierarchy. Several different techniques were used to capture the SME tacit knowledge. Step 5: Synthesizing – During this step the judgments that are made by the SMEs are synthesized (consolidated) throughout the model using a weighing and adding process Figure 6: An example of a possible Decision Support Hierarchy Step 6: Examining and verifying the Decision – This is a crucial step and often under emphasized. That is, verify that the intuition about the best alternative agrees with the chosen alternative. If not, re-examine the structure, objectives and judgments of the model. At this point a What-If or Sensitivity Analysis may be performed. Step 7: Presenting and Documenting the Decision – Once the results have been examined and verified, it is often important to be able to document the reasoning that went into a decision. The documentation may be used to justify the conclusion to others, or to reflect on the decision in the future. Figure 7 illustrates four typical sensitivity analysis diagrams, that is, an Overall Criteria Diagram, a Criteria Specific diagram, a Dynamic Sensitivity diagram and a Head to Head sensitivity diagram Applying this methodology to the CBM+ domain has been shown to be beneficial and has numerous advantages which span the entire process and life cycle (AS-IS to TO-BE evolution). This methodology is being applied to current & future architectural decisions. Without question, incorporating the DSS is enhancing the decision making Conditional Based Maintenance Plus (CBM+) Communications Architecture Modeling and Simulation with Decision Support Technology Page 5 of 7 Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS) process and will ensure a better understanding of the decision being made. In fact, complex decisions based on a combination of qualitative and quantitative measure (with different levels of maturity) are benefiting significantly both in understanding the problem and identification of the “best” solution. Since the process lends itself to capturing, refining and synergizing the tacit knowledge that is typically used by the SMEs it is ideal for continual process improvement Figure 7: An example of various sensitivity analysis reports from the Decision Support System (DSS) INFORMATION ASSURANCE Information Assurance (IA) is an integral component of the Army’s communications infrastructure. Its purpose is to protect and defend the information infrastructure and the information within it, in order to provide confidentiality, integrity, authentication, non-repudiation, and availability. IA covers a wide area of protection and defense that include operations security (OPSEC), communications security (COMSEC), transmission security (TRANSEC), information security (INFOSEC), personnel security, and physical security. An implementation of IA must not only ensure proper protection and defenses, it must also be developed in compliance with appropriate standards and regulations, risk mitigation, minimize network performance degradation, and cost effectiveness. A balance must be found among many variables such that the end result will produce the desired architectural design. This will be accomplished through experienced architectural engineering, modeling and simulation (M&S), and Decision Support disciplines. Architectural Engineering discipline provides a systematic approach to the development of communications and information systems’ architectures. The Architectural Engineering approach ensures that the information and communications architectures are compliant with the many IA standards, regulations, policies, and directives. It assists in the development of IA protective and defensive architecture in a manner that reflects the Army’s Defense-inDepth (DiD) strategy. The resulting architecture design uses IA devices and functionalities that will be placed appropriately at strategic locations in the communications networks and the information systems. Additionally, such architecture will place the information systems at their appropriate networks and enclaves and ensure their physical separation by their relative classification levels. The Architectural Engineering methodologies will also assist in early identification of issues and gaps such that there will be ample time for their resolution. The Modeling and Simulation (M&S) engineering will put to test the developed architectures. This discipline is used to confirm the architectural design and the decision support through quantitative analysis. Using modeling tools, such as the JCSS and/or OPNET, the IA devices and functionalities will be modeled in ways that reflect their real performance and behavioral characteristics. The modeled IA objects will be inserted into the modeled architectures, and then will participate in simulations runs under various traffic and environmental conditions. Results of the simulation runs will provide relatively realistic quantitative information regarding the network performance associated with the individual or aggregated IA objects. Further, each individual IA object will also be drilled down to provide various levels of performance details, relative to its configuration. The Decision Support methodology is part of the evolutionary process of the architecture development process. It provides the capability to perform comparisons and analyses of architectures, and assist in decisions regarding the selection of architecture based on various considerations or criteria. Any architecture that includes IA would be excellent candidates for analysis using the Conditional Based Maintenance Plus (CBM+) Communications Architecture Modeling and Simulation with Decision Support Technology Page 6 of 7 Proceedings of the 2009 Ground Vehicle System Engineering and Technology Symposium (GVSETS) Decision Support Tool. IA architecture implementation is complex due to the numerous implementation variables; selection and placement of protective and defense mechanisms, their relative network/throughput performance, and cost considerations, are just a few variables that are worth mentioning. In conclusion, the Architectural engineering, Modeling and Simulation (M&S), and Decision Support disciplines are key in the evolutionary process of development of communications and information architectures with integrated IA functionalities. They clearly provide the most effective engineering methodologies, DoDAF compliance and are effective in providing the necessary developmental tools and solutions. SUMMARY We identified, established, and leveraged expertise across CBM+ Community and CERDEC subject matter expertise. We are leveraging the existing system of system (SoS) architectures and modeling and simulation. Both areas are critical in developing CBM+ communications architecture. We have established communications architecture web portals (e.g. architecture analysis methodology, gaps, issues, DSS hierarchy) to facilitate communications among stakeholders. Currently, we are coordinating issues, analyses, reports and architecture evolution with stakeholders, and working with them to close the gaps. REFERENCES [1] W. Lucchesi, “Final CERDEC S&TCD CBM+ Brief to Mr. Terry Edwards, SES - Communication Architecture and Analysis Initial Kick-Off Meeting Plus”, 2009 FUTURE RESEARCH The areas of future research include the following: (1) Application of Measurement and Classification Theory to the Architectural Engineering Domain – System of System (SoS) Enterprise architecture (EA) engineering is a relatively new field. As such, an architectural quality taxonomy using proven measurement and classification theory needs to be developed and validated. This taxonomy would provide the insights (i.e., data, information, knowledge, and wisdom transformations) to support the development of appropriate quality and process metrics to measure (i.e., completeness, consistency, correctness, complexity.) the AS-IS → TO-BE architectural evolution. (2) Architectural Product Metrics – A common set of metrics to measure the quality (i.e., complexity, consistency, completeness, etc.) of the various artifacts is needed. In addition, metrics which capture the reusability, extendibility, complexity, cohesion, coupling and interdependencies would be valuable. Similar process metrics should be developed. 3) Decision Processes, Methods and technologies. – Further studies for applying advanced decision support technologies to the SoS EA are needed to model and validate the numerous types of decisions that are made during the EA life cycle. Furthermore, the traceability to the architectural metric and the fundamental purpose(s) are critical to the success of the EA. [2] S. Butcher, J. White, “Ground and Aviation Node Baseline Brief”, 2009 [3] S. Butcher, J. White, “Army Integrated Logistics Architecture (AILA) Architecture Assessment Brief”, 2009 [4] S. Butcher, J. White, “CBM+ Overview CERDEC Kickoff meeting to discuss CBM+ Communication Architecture Development Brief”, 2009 [5] A Decision Support System (DSS) based methodology to support the engineering of net centric architectural solutions, Walter M. Lucchesi, MILCOM 2005. [6] A Study of the Processes by which Enterprise Architecture Decisions are made, Utako Tanigawa, 2004, PhD Dissertation NSU [7] E. Turban, “Decision Support and Expert Systems”, 1995 [8] T. Saaty, “The Analytical Hierarchy Process”, 1980 [9] T. Saaty, “Fundamentals of Decision Making and Priority Theory”, 2000 Conditional Based Maintenance Plus (CBM+) Communications Architecture Modeling and Simulation with Decision Support Technology Page 7 of 7