A Systems Engineering Methodology for Analyzing Systems of Systems

Transcription

1 A Systems Engineering Methodology for Analyzing Systems of Systems John S. Osmundson 1 and Thomas V. Huynh 2 1 Departments of Information Sciences and Systems Engineering, Naval Postgraduate School, 1 University Circle, Monterey, CA , josmundson@nps.edu 2 Department of Systems Engineering, Naval Postgraduate School, 1 University Circle, Monterey, CA , thuynh@nps.edu ABSTRACT This paper presents a methodology for performing architectural analyses of complex systems of systems using process modeling. A process is a series of actions undertaken by a system of systems to produce one or more end results, typically products and services. The method applies to systems-of systems whose effectiveness and performance depend strongly on process timelines, such as distributed information systems, logistics systems and manufacturing and distribution systems. A fundamental tool in this method is the development of a unified modeling language (UML) related view of the system-of-system processes of interest and the subsequent conversion of the UML related view into an end-to-end system of systems executable object-oriented simulation model. The Naval Postgraduate School has developed this methodology over the past ten years and has successfully applied it to a range of systems of systems studies. The methodology is illustrated by applying process modeling and simulation to analysis of an expeditionary warfare system of systems and a joint combat identification (CID) system. Work currently underway to apply the methodology to the analysis of a multinational maritime domain protection (MDP) system is described. Issues associated with systems of systems engineering analyses and future work are also discussed. 1

2 1.0 INTRODUCTION A methodology for performing engineering analyses of systems of systems has been developed at the Naval Postgraduate School (NPS) [Osmundson 2004] over the past several years and has been successfully applied to a number of example military systems of systems. The methodology developed at NPS and described here applies to problems of forming a system of systems from systems that have previously been independently developed as stand-alone systems. The methodology is not aimed at systems engineering of a system totally comprised of to-be-developed systems; in the authors opinion this case requires only an extension of known systems engineering methodologies, albeit possibly on a larger scale and for more complex systems. Typical questions posed when attempting a system of systems integration of existing systems are: To what extent are the existing systems interoperable? What are the resulting system-of-systems measures of effectiveness given the "asis" levels of interoperability? What levels of system of systems measures of effectiveness are possible, assuming modifications to existing systems, adding middleware, changing organizational structures or ways of doing business, or other modifications? Process modeling provides a framework for answering these questions. Systems of systems use processes - a series of actions undertaken to produce products, information, services or other end results. Architectural analyses of complex systems of systems, therefore, often involve analyses of systems processes, with the goals of identifying the most 2

3 important process design parameters that affect system performance and understanding the sensitivity of system performance to variations in the driving design parameters. One example of a process driven system of systems architecture in the military is a joint service intelligence collection management system. An example of a commercial system of systems would be the inter-operation of several organizations that join together in a new way to produce services or products. 2.0 METHODOLOGY Our systems of systems engineering analysis methodology consists of a sequence of analyses, transformations, model building, and simulations. 1. Development of system of systems scenarios and operational architectures 2. Identification of system of systems threads 3. Representation of operational architectures in a unified modeling language (UML)-like format 4. Identification of system of systems design parameters and factor levels 5. Transformation of UML-like format representation into executable models 6. Application of design of experiments 7. Simulation runs and analysis of results The first step, development of system of systems scenarios and operational architectures, corresponds to the initial step of the Department of Defense C4I architectural framework, which to determine the operational context. In this step the organizations, systems and operational goals within specified contexts are identified. The second step, identification of system threads, is an extension of the first step and corresponds to the OV-6c diagram in the Department of Defense Architectural Framework 3

4 (DODAF.) In this step initial events that trigger the initiation of a process in one or more of the systems are identified, as well as subsequent processes in the system of systems until a logical ending point is reached. In the third step the system of systems is represented in a UML-like format that corresponds to UML swim lane diagrams. Figure 1 shows an illustration of a generic system of systems and interactions between system elements in this UML-like format. Time increases to the right along the horizontal axis. As illustrated in Figure 1, element A of system 1 and element C of system 3 interact with system 2 by passing physical items or information to element C of system 2. Later element F of system 2 interacts with element B of system 1. Examples of elements of systems could include organizations of people, processing systems, communication systems, production systems or transportation systems that interact to produce information, products or to transport things. System 1 Element A Element B System 2 Element C Element F System 3 Element C Time Figure 1. Graphical View of System of Systems Interactions in a UML Format. 4

5 The flow of interactions shown on Figure 1 from a starting point to a logical ending point is similar to a thread in a software system, and this view of system-of-system interactions is analogous to swim lane diagrams in the Unified Modeling Language (UML) (Larman 1998). Complex system interactions can be understood by modeling each system in terms of objects corresponding to system elements, with the proper logical flow and timing of items of interest passed between system elements, either within a system boundary or across system boundaries, during interactions. Passing of items from one model object to another is analogous to passing messages between objects in UML. The measures of performance of such systems of systems could include time to complete a thread - such as accomplishing a complex task, or the throughput of items through the total system. Depending on how the model is constructed another example of a measure of performance could be the quality of the final outputs. The goal of some architectural analyses might be to determine interoperability requirements between systems. In an information system, for example, the directed arrows on Figure 1 would be information items and the graphical view of the system would indicate information exchange requirements needed for interoperability. If the graphical view shown on Figure 1, known as a paper model, were converted into an executable model such as a discrete event model, the timing requirements for interoperability could be determined. The fourth step in the methodology is the identification of system of systems design parameters and factor levels. Before developing executable models the systems engineer must identify the appropriate system of systems options. In many situations the system engineer would like to examine the effects of many systems variables on a dependent variable. The variables are often referred to as design factors and the dependent variable is often referred to as an objective function. The systems engineer must identify the design factors. Design factors might include the type of arrangement of system interconnections, methods of access, methods of routing and controlling flow of items, and throughputs of 5

6 the various links in the network. Typically each of the design factors can be varied (the design factors can be said to have several different states or levels) and combinations of the various design factors in different levels represent potential system of systems options. The fifth step transforms the UML-like system of systems representation into executable models. Modern software applications have the capability to model systems analogously to the method described above. System elements can be described as icons and the icons can be grouped to represent functional properties of a system or, as appropriate, system functions can be grouped and represented by a single modeling icon as shown in Figure 1. These icons can be graphically linked to form models of physically distributed systems of systems. Event generators are built in functions and can be programmed to trigger the creation of events and resultant threads in a system of systems model. Models of systems of systems are constructed in a modular manner so that design factors are represented by an association with modeling application objects. System options are represented by rearranging the objects and by varying the object attributes from model to model. The fifth step applies design of experiments to guide the development of executable models and the running of simulations. Once system design factors and factor states have been identified system of systems models must be built that enable all of the design options to be analyzed. Often the total number of options can be high, resulting in a formidable modeling task. For example a full parametric variation of a system involving m design factors each with L levels would result in the need to create N separate system models where N = L m. One approach to reducing the initial system modeling task to one of reasonable size is to use orthogonal arrays to identify the models required to cover the variable or design factor space and give sufficient information to identify the system arrangement that optimizes the dependent variable or objective function. This approach works well if the system of systems can be optimized by optimizing a single objective function. The concept of orthogonal arrays originated with the work of R. A. Fisher [Fisher, 1935] and has been the subject of numerous studies of the design of experiments [McLean and 6

7 Anderson, 1984] and the statistics of design of experiments [Raghavarao, 1971.] Taguchi [Taguchi, 1987] gives a treatment of orthogonal arrays that emphasizes practical applications as opposed to mathematical analysis and is very accessible for engineers. As a simplified example of orthogonal arrays consider a system that has three design factors each with two possible levels. A full parametric variation would require 8 models to be built and run in order to determine an optimum configuration. The orthogonal array for this case is shown in Figure 2. Here the eight models that are required using full parametric variation are reduced to four models using design of experiments. The first model is built with all of the three design factors in their first level. The second model is built with the first design factor in its first level and the other two factors in their second level, and so forth. A characteristic of an orthogonal array is any two columns of the array contain all possible combinations of states of different factors the same number of times. Design Factors Factor 1 Factor 2 Factor 3 Model 1 Level 1 Level 1 Level 1 Simulations Model 2 Level 1 Level 2 Level 2 Model 3 Level 2 Level 1 Level 2 Model 4 Level 2 Level 2 Level 1 Figure 2. Orthogonal Array for a Three Factor, Two Level Design Problem. Results of the models are analyzed as follows: The values of the objective function for all runs obtained with models with design factor #1 in level 2 are added and divided by the number of runs with design factor #1 in level 2, and the same procedure is followed for all runs obtained with design factor #1 7

8 in level 1. Let R(F 1 a,f 2 b,f 3 c) be the result of a simulation run of a model having design factor 1 at level a (F 1 a), design factor 2 at level b (F 2 b), and design factor 3 at level c (F 3 c.) The average result for simulation runs for models shown on Figure 3 with design factor 1 in level 1 is given by: {R(F 1 1,F 2 1,F 3 1) + R(F 1 1,F 2 2,F 3 2)}/2; and the average result for simulation runs for models with design factor 1 in level 2 is given by: {R(F 1 2,F 2 1,F 3 2) + R(F 1 2,F 2 2,F 3 1)}/2. In each case the results for design factor F 1 in a given state include the effects of design factors F 2 and F 3 equally in all of their possible levels. Thus the results for design factor F 1 are independent of (or orthogonal to) the effects of F 2 and F 3 which is a characteristic of orthogonal arrays. This does not mean that the design factors are physically independent, but only that a mathematical analysis will produce independent results for each design factor [Barker, 1985.] This characteristic of orthogonal arrays allows the effect of each design factor to be determined separately by analyzing all of the simulation runs as a unit. None of the four models shown on Fig. 3 is necessarily an optimum arrangement of design factors and levels. However analysis of the results of an entire set of simulation runs will show the dependence of the objective function on the choice of levels for each of the design factors, indicating the arrangement of design factors and levels that will yield an optimum system. The reduction from 8 cases to 4 cases is not dramatic but for larger dimension systems the reduction in modeling effort can be substantial. A system with 7 design factors each with two states would require 128 models using full parametric variation but only 8 models using design of experiments. An orthogonal array must be constructed that is appropriate to the problem of interest, depending on the number of design factors present, the number of possible levels for each design factor, and whether any of the design factors interact with one another. A number of orthogonal arrays, known as standard orthogonal arrays, have been developed by previous researchers [Taguchi and Konishi, 1987] and other arrays can be constructed by applying rules to standard arrays. Ranjit Roy [Roy, 1990] gives an excellent discussion on the construction of orthogonal arrays by applying design rules to standard orthogonal arrays. 8

9 The sixth and final step in the methodology is running the simulations as specified by the design of experiments and analyzing the results. It should be noted that some high level system of systems issues can identified and resolved merely by constructing the paper model in UML-like format. Questions such as whether two systems have the required connectivity and meet basic item exchange requirements can often be resolved base on an inspection of a well constructed paper model. Obtaining qualitative measures of system of systems performance, however, requires the analytical basis provided by executable model results. 3.0 EXAMPLE APPLICATIONS Our methodology is illustrated by application to selected DOD problems. 3.1 Expeditionary Warfare Expeditionary warfare is the operation of an armed force in an area far from a supportable home base and supported by temporarily established means. The U.S. military has conducted expeditionary warfare in the past by building up forces, equipment and supplies at a beachhead before moving on to an objective. There is current interest in the U.S. military to shift from the concept of establishing a beachhead and then movement to an objective to a concept of sea based launching and supporting forces and sea-to-objective maneuver for fighting forces. A fundamental tool in this analysis is an end-to-end object-oriented simulation model emulating the full implementation of these force architectures and design factors as well as accounting for the impact of varying levels of operational intensity, attrition of personnel and transport vehicles, weather, mining sea lanes, transport vehicle operating and availability constraints, landing spot constraints and transit and communications delays. 9

10 Expeditionary Warfare Architectures The U.S. military has long been concerned with expeditionary warfare, developing plans during the first half of the 20 th century, and then achieving important victories throughout World War II and the Korean War. However, the operational concepts behind the Navy-Marine Corps expeditionary forces of today are not much different than the ones that existed in the 1950 s. Past expeditionary forces required operational pauses to build up forces in order to complete missions. Typically the build up of forces was done at a beachhead in a process of establishing an iron mountain, a term referring to the large amount of equipment and supplies built up at the beachhead. The iron mountain was essential to assembling and positioning sufficient force to then maneuver and secure the objective. Expeditionary warfare is a concept that seeks to make full use of sea basing. Sea basing is a concept in which forces and equipment are assembled at sea and then deployed directly to an objective without establishing a beachhead. The question is whether current and planned U.S. expeditionary warfare forces can fight and win by employing this type of warfare. The study undertaken by NPS includes extensive research into existing and proposed expeditionary warfare subsystems and a number of supporting analytical studies. A complete report on this study is available (SEIa, 2003.) Here we focus on the process modeling of the overall expeditionary warfare system of systems of systems process. The expeditionary operations considered for this study are assumed to take place in the year 2020 timeframe and are conducted with a Marine Expeditionary Brigade (MEB)-sized force. MEB operations are conducted up to 200 nautical miles (nm) inland from a sea base located nm offshore. Logistics ships, Maritime Preposition Force (MPF) ships, and at least one Carrier Strike Group (CSG) will augment the assault. Legacy platforms are projected 10

11 to remain operational through this timeframe. All new USMC aircraft and land vehicle purchases currently projected to be available in this timeframe are fielded on schedule. Three architectures for an expeditionary warfare system of systems of systems are considered: A current architecture, a planned architecture using sea-basing, and a conceptual architecture using sea-basing, more reliance on high-speed transport and use of notional seabasing vessels. The intent was to quantify any increases in expeditionary warfare performance that could be realized with planned and conceptual architectures Current Architecture The USMC s current doctrine indicates that the notional MEB force size is about 17,000 troops, approximately 5,500 of whom comprise the ground combat element that is projected ashore. The remainder is organized into an aviation combat element and a combat service support element. The amphibious force supporting a MEB expeditionary warfare operation normally consists of a Navy element consisting of a mix of amphibious ships, support ships, and in some cases maritime pre-positioned assets, which carry equipment and sustainment for fighting forces. Carrying sufficient equipment and supplies to sustain 17,000 Marine Corps personnel, six MPF ships are designed to sustain the MEB 30 days. Pre-positioned amphibious and support ships are designed to reduce strategic airlift requirements and global response time. In its current configuration, the force projects Marines ashore to the landing beaches and objective areas utilizing organic surface craft and helicopters, first establishing an iron mountain that uses existing port facilities as a base for combat force and logistics build-up. Upon establishing and securing an iron mountain site, the MPF ships pull in to unload their equipment and supplies. At the same time, the combat forces maneuver to the objective area. Commercial ships will transfer subsequent re-supplies from the continental U.S. (CONUS) or forward 11

12 logistics sites to the iron mountain at regular intervals. Sustainment requirements for a MEBsized force are defined in the MAGTF Planner s Guide (USMC, 2001), the Organization of Marine Corps Forces (USMC, 1998), and the pamphlet, Naval Expeditionary Warfare: Decisive Power, Global Reach (CNO (N75), 2002). The force relies on five or six MPF ships to provide equipment and sustainment of one MEB for 30 days. Current MPF ships require offloading cargo in a port facility and flying combat personnel into an airfield in order to marry up with their equipment. This offload and assembly process is expected to last ten days. Planned Architecture The Planned Architecture is similar to the current one, with programmed replacement of units by air, land and sea platforms scheduled to be in service during the timeframe. The distinctive difference in this architecture is implementation of sea basing, integrating the MPF (Future) ships capable of providing command and control, power projection and logistical support directly from the sea without the use of an intervening iron mountain. The fighting force, utilizing surface craft and helicopters organic to the expeditionary force, will be projected ashore to the objective area via a landing beach and then will punch through to the objective without an operational pause. Commercial ships or high-speed vessels will transfer subsequent re-supplies from CONUS to the sea base at regular intervals. In addition to implementing the concept of operating from a sea base, the fighting force features upgrades to amphibious platforms and their capabilities in conjunction with ships and aircraft already programmed for construction or operational implementation over the next years. The planned architecture consists of a projected large-deck amphibious assault ship replacement and the new amphibious transport ships, along with legacy ships. Surface craft, continuing to transport personnel, equipment and supplies, have planned replacements. Finally, the MV-22 advanced rotary wing aircraft is in 12

13 service for this system for use in conjunction with legacy helicopters. An assumption of this analysis is the resolution of current day MV-22 technical and operational problems. Conceptual Architecture The third expeditionary warfare architecture studied, a Conceptual Architecture, differs from the Planned Architecture, by employing significantly more MV-22 aircraft and introducing new conceptual heavy lift aircraft (SEIb 2003 ), combat ships and logistic ships (SEIc 2003) designed in related efforts in the Naval Postgraduate School study (SEIa 2003.) Summary The three architectures considered in this study are summarized in Table I. These are considered to span all of the viable options in the year 2020 time frame. Routes going from off shore bases or US land areas directly to an objective are considered infeasible because of the need to transport large amounts of forces and material over very long distances, assuming expeditionary warfare scenarios of interest are usually not near off shore bases or US land areas. Routing Seabase to Objective via Iron Mountain Seabase Direct to Objective Seabase Direct to Objective Naval Transport Vehicles Existing Planned Conceptual Air Transport Vehicles Existing Planned Conceptual Table I. Summary of Expeditionary Warfare Architectures. 13

14 System-of-Systems Analysis Approach An expeditionary warfare system of systems of systems must deliver forces and supplies to the objective in required quantities, while being designed with the properties of survivability, reliability, maintainability and cost effectiveness in mind.. A forcible entry scenario campaign analysis conducted as part of the overall study determined the high level measures of performance for an expeditionary warfare system of systems to be the speed with which forces can be built up at the objective and the level to which forces can be sustained once they reach the objective. These measures of performance are functions of delays in transport, packing and unpacking, and queuing delays due to competition for scarce transportation and logistics resources. This high-level analysis of emerging system of systems behavior is essential to determining performance requirements for specific subsystems. The atomic units of this complex expeditionary warfare system of systems of systems consist of time delays, transportation processes, warfare activity and interfaces among these functions. Time delays are associated with the performance of each function and interface, such as loading and unloading of troops, equipment and supplies, as acted upon by environmental factors and combat activity, such as attrition rates or mine activity. One approach to improving system performance is to minimize the total time delay associated with each important thread of functions through the system. System Design Factors In an expeditionary warfare system of systems, the high level design factors are those that affect the speed of delivery of forces and supplies. These design factors are routing of forces and supplies, speed of transport of forces and materials (a function of payload, speed, quantity and availability of the transport vehicles) and efficiency of logistics. Routing refers to the choice of 14

15 moving directly from a launch area to the objective or moving from the launch area to an intermediate location where supplies can be built up before moving to the objective. Speed of transport of forces and supplies can vary, for example, by employing relatively fast, low-payload aircraft or slow, large-payload ships. Also, the type of ship could be a conventional large payload, moderate speed ship or an advanced design ship that is much faster but carries a smaller payload. Efficiency of logistics encompasses the speed with which forces and supplies can be loaded and unloaded at various points in the expeditionary warfare chain. Cost was not considered as a design variable due to the guidance given at the start of the study. As an output of this study the US Navy wanted to know whether more advanced expeditionary warfare system of systems architectures would yield improvements in systems performance sufficient to warrant more detailed studies that would give the basis for cost comparisons. Trade studies of systems concepts with design factors selected in different levels yield identification of the most significant expeditionary warfare system of systems design issues and determination of the best values for these factors. Noise Factors Based on observations of amphibious and campaign analysis, modelers include weather, the extent to which sea-lanes are mined, consumption rates of ammunition and supplies, and combat attrition as noise factors in the simulation. Weather affects system performance by slowing the speed of transport and by slowing the process of loading and unloading forces and supplies. Sea mining causes delays while mine sweeping operations are carried out. Sea mining also may limit the number of sea access routes, in turn constraining the number of simultaneous sea transits by surface craft. High use of consumables, including fuel and water, increases 15

16 demands on supply lines. High combat attrition creates the need for more frequent reinforcement and re-supply of ammunition, water, fuel and other essentials. Expeditionary Warfare Model To enable a systematic and comprehensive study on expeditionary warfare and the factors that affect its performance, an end-to-end expeditionary warfare model was built with EXTEND TM, a discrete event simulation tool. This particular tool offers an ability to capture the functions, interfaces, delays and systemic characteristics to a desired level of fidelity. The resulting model emulates the processes involved in accumulating, assembling, deploying and sustaining expeditionary forces ashore. It provides a means for full accounting of the transport vehicles, forces, equipment and supplies and their interactions within the system and allows studies of the dependencies of expeditionary warfare system of systems architecture performance on design and noise factors. CONUS Offshore Bases Forces Forward Send forces, equipment and supplies Send forces, equipment and supplies Send forces Assembly Area Receive and send forces, supplies and equipment Planned and Conceptual Architecture Route Launching Area Iron Mountain Objective Current Architecture Route Time Receive and send forces, supplies and equipment Receive, buildup and send forces, supplies & equip Receive, forces, supplies and equipment Figure 2. Expeditionary Warfare Depicted as a System of Systems. 16

17 A view of the expeditionary warfare system of systems is shown in Figure 2 that corresponds to the generic process model shown in Figure 1. Figure 2 depicts the nodes involved in the entire operation and the flow of forces, equipment and supplies between the nodes. Two alternative routes are shown, one corresponding to the current use of an iron mountain and the other corresponding to the use of a sea base and transport of forces, equipment and supplies directly to the objective from the sea base. Due to the shift in concept from the current iron mountain-based architecture and the evolving sea-based Sea-to-Objective concept, two separate models were built. The first model was designed specifically to depict the flow from CONUS, to include forward deployed forces forming a MEB, assembling and proceeding to the launching area. Once the MEB arrives at the launching area, forces deploy in scheduled waves to both the objective and the iron mountain. After the iron mountain is secured for a specified period of time, the first wave of logistic supplies, provided by MPF ships supplying logistics such as food, water, ammunition and spares, arrive and build up of a logistic depot commences. Large, medium-speed ships or smaller high speed vessels (HSV) carry out subsequent logistic supplies from the offshore base to the iron mountain. At the same time, while concurrently fighting at the objective, reinforcements continue to advance from the iron mountain to the objective, providing troops, food, water and ammunition. For the purpose of this study, the entire operation continues for a 90-day period. The second model emulates expeditionary processes that allow both the planned and conceptual architectures to run under the new concept of operations, eliminating the need to establish an iron mountain using a sea base to provide the logistic depot. As in the first model, this begins with the build up of a MEB sized force from CONUS and forward deployed forces at 17

18 an assembly area and subsequent movement to the launching area. From the launching area, forces deploy in scheduled waves to the objective. After all the scheduled waves have been launched, the logistic ships stationed at the assembly area begin sustainment operations. Either large medium speed ships or high speed vessels transit between the offshore base and the assembly area to replenish these logistic ships. Again, the operation runs for a 90-day period. The main difference between the planned and conceptual architectures is that the assets used are different. Thus the second model represents the routing appropriate to both the planned and conceptual architectures but different sets of parameters are used in the second model to represent the different assets in the planned and conceptual architectures. A top level view of the second EXTEND TM executable model (Figure 2) and one example of a lower level of detail from the launching area (Figure 3) are shown. The top level view has a one-to-one correspondence to the nodal view shown in Figure 2, with the addition of a Beach Area in the EXTEND TM model to account for equipment that is too heavy to transport by air directly to the objective. Each major element of the top level model is treated as an object with forces, equipment, supplies and transport vehicles passed from one object to another. Each high level object is then modeled in hierarchical layers of detail. The approach to process modeling of other systems of systems is similar. Analysts partition the system-of-system of interest as a collection of objects and processes that create, modify and use items, with appropriate interactions between the objects. Interactions are passing of items between objects. Interactions to be included in an executable model are selected based on an understanding of potential system measures of performance and an understanding of the subject area domain. 18

19 Figure 2. Top-level view of the EXTEND Expeditionary Warfare Model for Sea Basing. 19

20 Figure 3. Lower Level View Within Launching Area. 20

21 The model was designed with two distinct layers: the physical layer at which items such as transporters, troops, equipment, etc., are transacted; and the communications layer at which messages are exchanged between nodes to coordinate transactions on the physical layer, e.g., logistics demand and fulfillment. The physical layer serves items that flow within and between nodes. The flow of logistic resource items is generally one way, while transporters (carrying mainly the logistic items) flow both ways between the logistic depot and the Objective. The EXTEND TM model is instrumented to count the arrival of forces, equipment, supplies and transport vehicles at various system nodes, primarily at the objective, as a function of time. Executable models of general systems of systems can be instrumented in a similar manner to track interactions relevant to measures of system performance. Model Input and Experiment Design The loading plan for all the scheduled waves that form the assault force to be launched ashore was an input for the model, making the simulation dependent on the way these scheduled assault waves are planned. Both current and sea-basing models use a constant rate of consumption for the expendable resources. However, the consumption rate of food, water, ammunition and fuel depends on whether it is a surge or normal consumption scenario. The model accounts for depletion of these resources as a function of the number of troops and the usage of the vehicles at the various locations throughout an operation. On another note, the model categorizes resources and supplies to ease implementation and interpretation of the output results. Examples of this include representing different types of trucks as a single truck type object, irrespective of their specific capabilities or limitations, and grouping ammunition into broader categories of air, ground and naval ammunition. However, such characterization still allows realistic emulation of the operation. Generalizing objects as 21

22 trucks does not eliminate the need to transport them from the ships to shore, placing demands on other transporter assets. Most importantly, this approach enables emulation of ground transportation behavior within an expeditionary warfare system of systems of systems and has the same implications for all three architectures. A concern in experimenting with the simulation model for this large, complex, interconnected system of systems is its inherent variability. A given set of design and noise factor parameter values requires sufficient numbers of runs in order to apply statistical methods for comparing measures. The number of iterations quickly grows out of hand. To decrease the number of experiments, analysts employed both classical Design of Experiments (Fisher, 1948 and Box, 1978) and Taguchi methods (Taguchi and Konishi 1987). This design of experiments requires a manageable number of simulation runs. The resultant experimental matrix is shown in Table II, which specifies 96 simulation runs in order to determine the main effects of the selected design factors and noise factors on expeditionary warfare. 22

23 Noise Factor Attrition Weather Sim. Run High High High High Low Low Low Low Good Good Poor Poor Good Good Poor Poor Mine Threat Low Low High High High High Low Low Cons. Rate High Low High Low High Low High Low Sim Design Factors Run Architecture Repl. Ship to Obj Means Proximity 1 Current MPF Close 2 Current MPF Far 3 Current HSV Close 4 Current HSV Far 5 Planned MPF Close 6 Planned MPF Far 7 Planned HSV Close 8 Planned HSV Far 9 Future MPF Close 10 Future MPF Far 11 Future HSV Close 12 Future HSV Far Results Table II. Expeditionary Warfare Design of Experiment. 23

24 RESULTS Comparing expeditionary warfare architectures and determining sensitivity of a given architecture to variation in design and noise factors requires a common set of measures of performance. For the assault phase, Combat Power Ashore (CPA) is selected as an index. CPA is an aggregated score to reflect the level of combat power available at any one time at a certain location. The CPA index is a summation of individual Combat Power Index (CPI) scores contributed by entities that compose combat power within the force. The score allocated to the individual entities is based on a RAND study (Allen 1992). The most important aspect of this index is that it provides a baseline performance measure for comparison under different conditions within the same operational scenario. The entities that contribute to combat power used in this analysis are M1A1 tanks, light armored vehicles, assault amphibious vehicles, advanced assault amphibious vehicles, M mm howitzers, high mobility multipurpose wheeled vehicles, and troops. In expeditionary warfare, there are two phases in building up a force ashore. The first phase is the initial build-up using the expeditionary force's organic assault assets; the second is delivery of the remaining force, either through the arrival of an MPF at the iron mountain for the current architecture or from the sea-based MPF or a conceptual expeditionary warfare ship. The first analytical objective is to measure, for each architecture, the performance of initial phase assault force projection capability. Hence, the desired force level that is used for this analysis is the force level that is projected based solely on the organic architecture's assault assets before the reinforcement by the logistics ships. The second analytical objective is to find out the performance of the overall force projection capability; for this analysis, the force level includes not only the force built up by the assault assets, but the build up of the remaining 24

25 force by the logistic ships as well. This allows a more comprehensive analysis of the performance and comparison of the total force built-up capability differences among the three architectures. Using the CPA scores, two measures of performance (MOPs) are identified to measure the performance of the individual architectures for the assault phase. The two MOPs are the Time to Landing of Advance Force (TAF) at the objective and the Time to Build Up (TBU) a desired level of forces at the objective. TAF is defined as the time taken from the launch of the operation to the establishment of a company level force at the objective; TBU, the time to build to desired force levels, represents the time required to place 80% of a MEB sized ground combat element and its supporting equipment at the objective. These MOPs, TAF and TBU are illustrated in Figure 4, which shows an output of a simulation run for the current architecture. Time, starting with the initial movement of forces and supplies from CONUS, is plotted in days along the horizontal axis. Combat Power Ashore, or CPA, is plotted on the vertical axis in terms of dimension-less units based on the number and type of force elements ashore and their corresponding CPI as determined by the RAND study. TAF and TBU are shown in Figure 5 as the times required to build up to the advance force level at the objective and to build up to the desired force level at the objective, respectively. Short-term oscillations and long term decrease in force level are caused by attrition of the forces coupled with the capacity and latency of the force delivery system with no replacement for armor vehicles lost during combat. 25

26 Combat Power Index (D1N1) 1800 Desired Force Level CPI 800 Advance Force Level TAF Time (days) TBU Figure 5. Depiction of Time to Advance Force (TAF) and Time to Build Up at Objective (TBU). Figure 6. Sample Means for TBU for the Three Architectures. 26

27 The measures TAF and TBU resulting from the simulation runs for the three architectures are analyzed as functions of design factors and noise factors and plotted on interaction plots, as shown in Figure 6, displaying TBU for the three architectures with respect to replenishment means, proximity of the sea base to the objective, attrition, mine threat and level of consumption of expendables. The upper left hand quadrant of the plot shows that as replenishment methods vary between high speed vessels (HSV) and large slower speed vessels (LMSR) the conceptual architecture outperforms the existing architecture and the choice of replenishment method has no effect on performance. Other effects are as shown on Figure 6. The conceptual architecture is able to project the first company of Marines ashore fastest, while the planned and current architectures take longer and are approximately equal in their performance. This is due to higher transit speeds built into conceptual amphibious ships, enabling them to get on station in a much shorter time. The analysis is also concerned with the process of sustaining the force sent ashore, comparing the number of days of supply held at the iron mountain (for the current architecture) and at the objective throughout the 90 day duration of the mission. For the logistics sustainment phase, the analysts use aggregated Mean Squared Error (MSE) of each class of daily sustainment categories required to sustain an operation ashore as the MOE (Frey 2002). The three classes of daily requirements are food and water, fuel and ammunition, measured at the iron mountain, sea base and the objective. MSE accounts for bias and variability of sustainment levels for the three resources as they deviate from desired levels. The aggregated MSE is obtained through averaging the MSEs of the three resource levels. Figure 7 shows sustainment level in terms of days of supply (DOS) of fuel, food, water and ammunition on the vertical axis versus time required to build up the supply levels. 27

28 Oscillation in the supply levels is caused by consumption of supplies coupled with the time delay to rebuild the supply level. In the EXTEND TM model, re-supply of the objective is demand driven by the level of supply at the objective and the consumption rate of food, fuel and ammunition by the forces ashore. Figure 10 summarizes the dependence of MSE on design and noise factors. Days of Supply (DOS) Food Fuel Ammunition Time - Days from Start Figure 7. Sustainment Levels at the Objective for the Current Architecture. Although simulation results show that the current architecture sustains the highest levels among the three architectures in sustaining the force at the objective, sea basing is a feasible option for supporting operating forces ashore, given good weather. The iron mountain has a huge capacity to transport resources over land to the objective which is not significantly diminished by poor weather or attrition due to enemy action. As a result, the objective is able to hold at least four days of supply independent of any other factor effects. The planned architecture using a sea base is also able to sustain the force at the objective just as well as the iron mountain in the current architecture when the MEB is operating in good weather conditions. Once weather 28

29 conditions deteriorate, the sea base has reduced capacity to move resources to the objective and levels decrease to an average of three days of supply. The planned architecture can sustain the objective just as well as the current architecture if transporters that are more robust against the effects of weather through better sea keeping and transloading capabilities are constructed. Analyzing the ability of a sea base to support operations at a distant objective experiments covered operations traversing four different distances - 58, 108, 158 and 208 nm - from the sea base to the objective. Increasing the distances between the sea base and the objective results in an increase in the TBU. This difference in build-up time is intuitive but it shows that it is possible to build up the forces ashore to the required level. Concern regards whether the forces ashore can be sustained from the different distances. The variability in the level of supplies at the logistics depot as a function of varying distances from the sea base to the objective is an output of simulations. For example, Figure 8 depicts performance of the planned architecture at a distance of 158 nm from the sea base to the objective Ammunition 7 6 DOS Food Water Fuel Time - Days from Start Figure 8. Sustainment Levels (Days of Supplies) over 150-plus Miles from Sea Base to Objective. 29

30 Analysts obtain MSE of days of supply (DOS) on hand as a function of distance to the objective and the maximum time that the objective could be supported before one or more of the replenishment items - food, water, fuel and ammunition - fall below a sustainment level. As expected, MSE at the objective increases as sea base distance from the objective increases. The sea base is able to sustain the duration of the operation at distances of 58 nm and 108 nm, but is unable to sustain it from 158 nm for more than 30 days, or 20 days at a 208 nm distance. The sea base proves unable to support fuel levels. The system is unable keep up with increased consumption as more re-supply missions are flown or launched. Replenishment studies identified potential areas for future system improvement. In order to have a functioning sea base that can sustain the forces ashore indefinitely at over-the-horizon distances, the replenishment system needs to be more robust or the load on the system reduced to allow it to function effectively at longer distances. This can be accomplished by reducing the consumption of resources at the objective through more efficient usage of fuel and ammunition. More fuel efficient hardware systems that consume less fuel and using stand-off precision strike weaponry will decrease consumption at the objective and will enable the sea base to support forces at greater distances. Shifting to sea-based and air-based responsive precision strike weaponry will relieve the MEB from having to move armor and artillery ashore, thus significantly decreasing fuel requirements at the objective. Experiments looked at four different options using varying proportions of air and sea assets for replenishing the objective from the sea base. This boiled down to a trade between speed and survivability. Replenishing entirely by air assets resulted in the lowest MSE of days of supply and conversely, replenishing entirely by sea assets resulted in the highest MSE. The 100% air replenishment option was subject to high levels of attrition due to the tremendous 30

31 number of sorties required to replace a single landing craft load, however. This increased aircraft exposure to enemy fire. 100% air replenishment is only viable in a low or no attrition environment, which translates to air superiority and dominance of the theater s air space. Finally, some combat equipment cannot be airlifted, such as the M1A1 tank. Even when a 100% air replenishment option is used, the M1A1 would still be a surface delivered combat system. Resources like food, fuel, and ammunition may be air or sea delivered depending on the option chosen. The high level results of this process modeling analysis give the first quantitative evidence that sea-basing is a viable expeditionary warfare concept. Results also show the performance of the three expeditionary warfare systems of systems architectures and the sensitivity of performance to various design and noise factors and provide guidance for future studies of expeditionary warfare system of systems. 3.2 Joint Combat Identification The movement toward digitization of the battlefield and the concept of network centric warfare leads to many complex military system of systems design and analysis problems. Among these problem areas is the compelling need to provide combat identification (CID) for large, joint force operations. CID solutions for future forces often propose equipping all, or a large number, of friendly combat force elements with situational awareness sensors - usually Global Positioning System (GPS) based position indicators - as well as ancillary sensors for identifying other forces [Marshall, 1999]. The data resulting from the CID sensors would then be distributed to all required users through a networked information system. The most important measure of effectiveness (MOE) of a distributed information CID system of systems is often data latency, i.e. the time required to get CID sensor data to required users under a variety of battle 31

32 conditions, and from a systems engineering perspective it is important to understand how data latency depends on system design alternative. Data accuracy is also important in a CID system of systems. However data accuracy also depends on data latency as well as the type of CID sensors employed. The choice of CID sensors is a separate system engineering issue that will not be addressed here. Scenario Following the proposed methodology we begin by constructing an example joint forces operational scenario for which forces and a sequence of force movements and supporting fires are specified. A littoral joint forces small scale amphibious operation scenario [Combat Systems Report, 1997] was constructed as a means of identifying CID requirements. The operation consisted of approximately 5,000 blue (friendly) force entities. Blue forces were defined to consist of specific types, numbers, and locations of dismounted troops, artillery and mortars, various other ground forces, mobile vehicles, fixed and rotary wing aircraft, landing craft, and offshore naval units. Dismounted troops were aggregated into squads and platoons. Each of the blue force entities was further defined in terms of weapons types, maximum speeds, and other characteristics. A countering red (enemy) force was also defined in the same manner. The scenario was run as a combat simulation using JANUS [JANUS, 1993], a force-on-force simulation system. A view from the JANUS simulation of the scenario is shown in Figure 9. At the time shown in Figure 48 blue forces had occupied areas near a port and an airfield and were preparing to link up with each other. Red forces occupied the area slightly to the south and between the airfield and port. The blue forces were concentrated in three areas as shown in Figure 9 and for purposes of analysis the forces were assumed to be equally distributed among the three areas. 32

33 Joint Amphibious Scenario Region 2 Region 1 Region 3 Sea Port Airfield Opposition Forces Figure 9. Joint Amphibious Operation Scenario. Locations and interactions of the blue and red forces changed during the JANUS simulation run. As blue force entities came into weapons range of one another, opportunities for fratricide existed. At times during the simulated battle there were critical periods when various blue force entities quickly came in close proximity to each other, creating a need for fast and accurate transmittal of CID information. 33

34 A simple paper model of the CID problem is shown in Figure 10. Information from CID sensors must be transmitted to the shooters in a timely manner. For simplicity the large number of distributed systems on the battlefield are shown as systems A, B and C in Figure 10. Processing can be done at the sensor, at the shooter, or at intermediate nodes. Sensors can be either organic to shooter platforms or remote. The CID information system must link the required sensor information to shooters within required timelines. Physical Physical Physical System C System B System A Sensors Sensors Sensors Processing Processing Processing Shooters Shooters Shooters Time Figure 10. Graphical View of the Joint Combat Identification Problem. Information from the JANUS simulation was used to construct a force interaction state matrix [Melich and Osmundson, 1995] for the scenario. The force interaction state matrix lists all blue force entities along the x and y axes of a two-dimensional plot. All possible lethal interactions between blue force entities are indicated at the intersection of the appropriate force entities on the two-dimensional plot, resulting in a force interaction matrix. Since the interactions change during 34

35 the battle, several snapshots of the interaction matrix were developed to determine average and worst case conditions from a CID perspective. Details about the interactions, including interaction dynamics, were derived from the weapons and motion characteristics of each force entity. CID data rate requirements were derived from the interaction matrices by assuming a generic sensor reporting position and ID, at a minimum, for each of the battlefield entities. A message size of 500 bits was assumed to be required in order to transmit position and ID information about each entity, including message encryption. Reporting rates were determined to fall into three main categories: 1) Reporting rate for dismounted troops and a background reporting rate for all entities for overall situational awareness was determined to be approximately 5 bps; 2) reporting rate for mobile ground vehicles was approximately 50 bps; and 3) reporting rate for fast moving entities, including rotary and fixed wing aircraft was approximately 500 bps. Candidate Network Architectures When situational awareness sensors with all processing on-board the sensors are used, the problem illustrated by Figure 10 becomes one of finding the best distributed communication architecture to support CID information needs. The interaction matrices suggest various approaches to CID network architectures. We note that forces are often grouped by geographical location, and/or by type of force element. This suggests network architectures that connect information sources and information users based on geographical areas, or type of force element, or a combination of both geographical location and type of force element. Time evolving interaction matrices also show that forces need to be connected across geographical areas and across types of force elements according to information needs, and that these information needs change dynamically depending on the situation. Additionally, the requirements for connection paths are not necessarily symmetric. Some suppliers of CID information may have 35

36 little need for CID from the rest of the CID system of systems while other users of information may require large amounts of CID data. We begin our analysis of CID architectures by considering major design alternatives or design factors and levels for a CID network. In order to simplify the problem of analyzing alternative network architectures we restrict ourselves to considering five major network design factors: 1) Grouping of CID information suppliers and users; 2) bandwidth of the CID network; 3) degree to which smart push of information is implemented; 4) method of network access and 5) dissemination network architecture. Figure 11 shows the five major options considered in this study in terms of network sub-elements and function options. The first column in Figure 11 lists the groupings and sub-groupings of CID information suppliers into local information reporting sub-networks that were chosen for analysis. Top-Level Combat Identification System Design Factors Reporting Grouping Bandwidth Smart Push Network Access Dissemination Method Design Factor Levels Type Area Type & Area 9.6 kbps 28.8 kbps 115 kbps Yes No TDMA Access on Demand Symmetric Asymmetric Figure 11. CID System of Systems Network Design Factors and Factor Levels. Each subnet can connect entities in a ring or star pattern, but for the purposes of this study star patterns are assumed. Inter and intra-network access was restricted to time division multiple access (TDMA) and to bandwidth on demand or Asynchronous Transfer Mode (ATM)-like access. 36

37 These two choices bracket existing tactical military communications technology and a very advanced network access technology. The overall network can be designed with or without smart push of information. One or more nodes that have total situational awareness including knowledge of the entire friendly force entity characteristics can maintain a dynamic interaction matrix of the potential lethal blue force interactions on the battle field. If smart push of information is implemented it can be used to transmit time-critical CID messages with higher priority and high frequency while limiting background traffic to lower rates. This effectively reduces the utilization of link bandwidth. In addition the bandwidth of each network is considered to be a design variable, with bandwidth restricted to three levels: Low bps, medium 28.8 kbps, and high kbps. These levels correspond to typical military tactical link bandwidths and current demonstration CID sensor system bandwidths. Asymmetric architectures are also considered, where reporting of CID information is forwarded on tactical links and disseminated using global broadcasting system (GBS) or global multicasting system from satellites, aerostats, or airborne nodes. For these cases the bandwidth of the dissemination system is assumed to be 3 Mbps, much higher than typical tactical reporting links. Broadcast CID information might have to be filtered at each user's receiver in order to prevent information overload of the users. An alternative would be to multicast return information by adaptively forming packets of CID information based on geographic area or unit type with packets headers for cueing of user's receivers. Options shown in Figure 11 lead to over 70 possible CID network architectures based on the total number of combinations of local groupings and function choices. There are potentially many measures of effectiveness of a network but the first measure should be that the architecture meets the timeliness requirements of the mission. Other important considerations include information 37

38 accuracy, network robustness (vulnerability to increases in the network load and susceptibility to network failures are some of issues associated with robustness), and cost. The more than 70 CID architectures corresponding to a full parametric variation of the design factor choices in Figure 11 were reduced to a set of eight different combinations of design parameter choices, shown in Figure 12, that were modeled using EXTEND. These choices of subnetworks and functions are a partial, but representative set of the total set of architectures required to be modeled, based on the use of orthogonal arrays and design of experiments methodology. Combat Identification System Design Factors Access Type Smart Push Disseminatio n Method Grouping Bandwidth Simulations Model 1 Model 2 Model 3 Model 4 Model 5 Model 6 Model 7 Model 8 TDMA Yes Symmetric Type 9.6 kbps TDMA Yes Symmetric Type & Area 115 kbps TDMA No Asymmetric Type 115 kbps TDMA No Asymmetric Area 9.6 kbps Access on Yes Asymmetric Area 28.8 kbps Demand Access on Yes Asymmetric Type & Area 28.8 kbps Demand Access on No Symmetric Area 115 kbps Demand Access on No Symmetric Type & Area 28.8 kbps Demand Figure 12. Combat Identification Models. 38

39 Figure 13 shows a top-level view of a representative EXTEND model for an architecture incorporating TDMA access, asymmetric (GBS) information dissemination, and smart push of information. The network in Figure 13 and all other network models consist of three sub-networks, with three nodes on each sub-network. Each node can be modeled to represent a large number of information suppliers and information users by appropriate scaling the message loads at each node to correspond to the simulation of the scenario shown in Figure 9 and the resultant CID information flows. Many nodes in Figure 13 are hierarchical blocks so that the details of the node model extend several layers deeper. Bandwidths and reporting entity groupings are determined by parameter settings within the model. Timers were inserted in every model to measure the delay from generation of information at a several different reporting nodes to receipt of the information by several different receiving nodes. Figure 13. Object-Oriented Model of the CID System of Systems. 39

40 Results of computer simulation runs for each of the design factors listed in Figure 13 are shown in Figure 14. The results are plotted in terms of relative delays of critical information generated at the first node of sub-network 1 (referred to as subnet 1 in Figure 14) and sub-network 3 (subnet 3 in Figure 10) reaching the user of the information for the eight selected network models. Models 1 4 shown in Figure 8 all have access type TDMA. Relative delays obtained by running models 1 4 were averaged to obtain the result corresponding to TDMA access in Figure 14. Results from running models 5 8 were averaged to obtain the result corresponding to access by demand in Figure 14. The two points corresponding to TDMA and demand access were then connected by a straight line to visualize the difference between access types. Other results were obtained in a similar manner. 1.2 Simulation Results Relative Network Delay Subnet 1 Subnet sym asym no yes TDMA On- type area area/type Demand Bandwidth Dissemination Smart Network Grouping kb/s Push Access Figure 14. Results of CID System of Systems Simulation Runs. 40

41 The first set of data in Figure 14 shows the effect of varying the bandwidth from 9.6 to 28.8 to 115 kbps. As expected, network delays are reduced with increasing bandwidth, but not dramatically so in going from 28.8 to 115 kbps. The next set of data shows the effect of disseminating information using the same return paths as for reporting - a symmetric network - or disseminating information using an asymmetric architecture, namely a GBS system. The improvement in using asymmetric dissemination is pronounced. The third set of data in Figure 14 shows the effect of introducing smart push. Again, definite improvement can be obtained by utilizing smart push of information, and this can sometimes result in a bigger improvement in network performance than increasing bandwidth. The fourth set of data relates to network access. Access by demand shows dramatic improvement over conventional military tactical data network TDMA methods. The fifth set of data shows the effect of grouping force elements for reporting and dissemination purposes by function, by geographical area, or by function within a given geographical area. A significant improvement is shown by grouping force elements by geographical area and a further smaller improvement is shown by grouping force elements by both type and area. While Figure 14 shows results in terms of relative delays the EXTEND models give results in absolute terms that are as accurate as the summed effects of the estimated component delays entered into the model. Absolute results could be compared to CID timeline requirements established from JANUS simulations in order to identify those modeled system options that met requirements. The set of system options meeting requirements could be further quantified in terms of cost, risk or other system parameters to form the basis of system trades. The models would need to be tested against a wide range of scenarios and battle conditions, and scaled to larger and smaller conflicts before the results could be claimed to apply universally 41

42 but the results shown in Figure 14 do give insight into the nature of the CID problem and network centric warfare. Increased bandwidth is important but in this particular example further increases in bandwidth above 28.8 kbps are much less important than asymmetric dissemination, implementing smart push of information, providing access on demand and grouping entities by geographical region. Further steps in the analysis procedure would be to consider the interaction of CID with other battlefield functions and to consider additional design factors. For example, CID should be incorporated into an overarching information system that would transmit remote firing and targeting data as well as other information. Reliability and survivability of networks would need to be analyzed. 3.3 Other Applications The methodology has been applied to the study of joint force targeting and fires system of systems interoperability study [Irvine, 2004] for Joint Forces Command and to the study of a standing joint force headquarters architecture, also for the Joint Forces Command [Hutchins, 2005]. The latter study addressed the question of what is the best architecture for a new headquarters staff designed to perform effects-based tasking. The methodology is currently being applied to a system of systems study of joint collection management. 4.0 APPLICATION TO MULTINATIONAL MARITIME DOMAIN PROTECTION According to the Department of Homeland Security Statement on Maritime Security Status before the U.S. Senate Committee on Commerce, Science, and Transportation on March 24, 2004, The world s oceans are global thoroughfares. It is plainly evident that a terrorist incident against our marine transportation system would have a disastrous impact on global shipping, international trade, and the world economy in addition to the strategic military value of 42

43 many ports and waterways. A cooperative international approach involving partnerships of nations, navies, coast guards, law-enforcement agencies, and commercial shipping interests is essential with all parties acting collaboratively to confront broadly defined threats to our common and interdependent maritime security. [tsa.gov 2004] In this maritime domain protection (MDP) arena, the ability to detect potential threats, process and fuse sensor data into actionable information, form decisions and then react to the threats in an effective manner is key to dealing with terrorism and other forms of asymmetric attacks. This ability what we term comprehensive awareness requires systematic understanding and engineering of a complex system of systems (SoS) that includes sensors, communications links, decision support systems and engagement systems. Our work presented here is an on-going research, related to the research described in a white paper submitted to OUSD(AT&L) [Huynh 2005]. In this research we will (i) develop a SoS engineering (SoSE) methodology that provides a framework and a tool for designing MDP SoS or complex systems, (ii) develop an ontology specification for coalition MDP SoS and operations, (iii) conduct a case study of an MDP SoS for a Singapore-United States coalition, applying the SoSE methodology and the ontology approach to the MDP Singapore-U.S. MDP, and (iv) extend the MDP Singapore-U.S. SoS to the following coalitions involving the nations around Malacca Straits and the U.S: 1) Indonesia and the U.S., 2) the Philippines and the U.S., 3) Singapore, Indonesia, and the Philippines, and 4) Singapore, Indonesia, the Philippines, and the U.S. In this paper we address the U.S.-Singapore MDP problem and discuss preliminary work on the development of the U.S.-Singapore MDP SoS, with focus only on ontology-based approach to data/information fusion. This preliminary work will serve as a pathfinder for a 43

44 larger coalition MDP SoS with all of its necessary functions. A report on the OUSD(AT&L) work will provide in detail the results of the research objectives (i iv). 4.1 US-Singapore MDP SoS Problem The AY 2005 Systems Engineering and Analysis (SEA 7) project at the Naval Postgraduate School involves the development of conceptual U.S.-Singapore coalition systemof-systems architectures to defeat and prevent terrorism in the Straits of Malacca (Fig. 15), with a focus on large ship security. Part of the MDP SoS functions is fusion of sensor data and database information to generate an integrated situational awareness picture. This is translated into a need for achieving semantic interoperability between country systems and accessing heterogeneous data sources and supporting technologies for data fusion. The context is thus sets of data and informational fragments, domain model (terminology, ontology, glossary), and mechanisms to produce data/information for fusion. Fusion: - Sensor data - DB Information - ID targets - Relay track ID to C2 300nm 300nm Figure 15. Malaccan Straits Maritime Domain Protection Area. 44

45 Database Philippines Item Relationship Database U.S. Type Category Location Speed Intent Environment ISAP Singapore Fusion Engine (Timely &acurate SA picture) Database Focus of Paper Indonesia Database Figure 16. Maritime Domain Protection Data Fusion 45

46 4.2 Solution Approach Process Modeling Use case narratives will be written from which MDP SoS objects and object attributes will be determined. A UML process will be followed whereby system events will be identified, interaction diagrams developed, and object-to-object messages or SoS information exchange requirements determined. While we will primarily employ the UML methodology, we will also explore the applicability of System Modeling Language (SysML) to the development of an MDP SoS. UML is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. [Booch 1997] UML does, however, not cover the entire set of useful stakeholder views, and UML is too focused on software systems. We will thus explore the SysML approach by taking advantages of SysML specific diagrams to capture system structure, behavior, parameters and requirements, and its support of more accurate fine grained modeling of behavior. Ontology Engineering A coalition MDP SoS requires data integration of disparate sources/databases to support data and knowledge sharing and technologies for aggregation, translation, and mediation of meaning across a heterogeneous array of databases. Ontologies are known to effectively support the integration of heterogeneous information sources; they make their content explicit by describing the semantics of the information sources. Mechanisms are thus needed to relate ontologies and to connect them with information sources. An ontology is an explicit specification of a shared conceptualization [Gruber 1993.] The importance of ontologies in military applications has been recognized for years [ Boury-Brisset 1999.] A challenge is that 46

47 existing ontologies are fragmented, incomplete, and in different formats. Another challenge is that integration of data/information involves a meta-abstraction [Ceruti 2004.] There are four sensor-data fusion levels [Waltz 1990]: Level 1 -- object refinement (i.e., fusion of data related to detection, tracking, classification and the identification of platforms without consideration of intent of the platforms); Level 2 -- situation refinement (i.e., relationship between platforms); Level 3 -- threat refinement and assessment of intent of hostile platforms; and Level 4 -- process refinement (i.e., prediction of hostile actions). While Level-1 data fusion deals with concrete entities such as emitters, platforms, low-level military units, Levels 2 and 3 are more concerned with abstract entities (e.g., event, intent, or goal). Level 2 concerns situation assessment issues and leads to a more symbolic representation of the environment and the relationships among the entities and the events in it. Situation assessment focuses on relational information to determine the meaning of a collection of entities. At the highest level of data fusion is the threat assessment level, or impact assessment (i.e., level 3), that projects the current situation into the future and infers about the impact of the assessed situation, the vulnerability and the force capabilities [Boury-Brisset 1999.] While concepts and applications of an ontology for level-one sensor fusion are addressed in Ceruti s paper [Ceruti 2004,] preliminary work in ontological engineering for Level 2 and 3 fusion processes is presented in Boury-Brisset s paper [Boury-Brisset 1999.] In the latter, an ontological approach to high-level information fusion and its application to heterogeneous information integration for the design of a knowledge server are presented. An MDP SoS requires all four levels of data fusion. There are twenty five different approaches for intelligent information integration [Wache 2001]. In our research, we will investigate and synthesize the various approaches to the development of ontologies to support the integration of internal and coalition heterogeneous information sources. We now sketch a preliminary layered approach to sensor fusion, a function to be performed by an MDP SoS. 47

48 It consists of (i) identifying purpose of ontology, (ii) developing formal ontologies (resource ontologies and shared ontologies) [Seth 1998] [Cui, 2005,] (iii) developing application ontologies for fusion, (iv) investigating tools for access to ontology, and (v) developing fusion engine. As depicted in Fig. 17, resource ontologies correspond to the individual resource databases (DB) and sensors. Mapping is carried out to generate a shared ontology; it will include translation, alignment, and integration of the ontologies Application ontologies are built to bridge the shared ontology and functions (such as fusion algorithm execution, discrimination, classification, etc.) to be performed by the computer or an agent. Resource DB/ Sensors Resource Ontologies Shared Ontology Application Ontologies Fusion Figure 17. Layered Approach to Fusion Ontologies Development. 4.3 U.S. Singapore MDP SoS Case Study The current (AY05) Naval Postgraduate School systems engineering and analysis (SEA) student capstone project is directed at the development of a MDP SoS concept for application to 48

49 a Singapore-U.S. coalition. Specifically, in the NPS SEA student capstone project the current MDP capabilities of Singapore alone and the current capabilities of both Singapore and the U.S. as a coalition are identified, and, as part of a gap analysis, additional capabilities for the coalition SoS are also identified. An MDP SoS architecture is then developed. Our maritime domain SoS research will use outputs of the SEA project and reflect the SoS engineering process and the ontology specification developed above. This MDP SoS case study is important, because it will serve as a pathfinder for developing MDP systems of systems for the coalitions involving the nations around Malacca Straits and the U.S. 5.0 FURTHER ISSUES AND FUTURE WORK 5.1 Agent-based Modeling Future work includes incorporating agent-based models into executable system of systems models as a means of representing humans and their interactions with other system elements. Simple human behavior was included in the Standing Joint Force Headquarters executable model, humans were system elements whose performance depended on their workload and task priorities. Representing humans by agent-based models will allow more complex behavior to be represented; behavior can be probabilistic, state dependent and also dependent on a range of system element influences, including other human behavior. 5.2 System Modeling Language Future research will include adapting UML views to Systems Modeling Language (SysML) views. The goal is to develop a more rigorous approach to developing paper models consistent with SysML. As an example SysML includes the construct, <<assembly>>, that describes a structure of interconnected parts and can have associated with it the construct known as NestedConnectorEnds. The advantage of such a construct as NestedConnectorEnds is that it 49

50 gives explicit insight into the precise interconnections that are required in a system of systems. As an example consider Figure 18 which represents a snippet of two missile Sensor Processor Interceptor Processor Sensor Processor Interceptor Processor Figure 18. Interconnections of a Layer Missile Defense System. defense systems. In order to work as a system of systems each layer must pass its organic sensor data to the processing element of the other layer. In addition the output of each processor including planned weapon-target pairings and kill assessment data needs to be sent to the processor of the other layer. SysML would allow the detailed representation of the item entry and exit points between systems to be shown using a structured modeling language. UML/SysML for Ontology Development Different formalisms and knowledge representation languages have been proposed to describe ontologies. Some are limited to describing concepts, attributes, and relations and resemble conceptual models in databases or object-oriented models (e.g., UML class models). UML has recently been extended to become a suitable candidate to support ontological engineering. [Cranefield 1999] [ Kogut 2002] Other formalisms use knowledge representation paradigms such as first-order logic, frame-based or description logic. New developments within 50

51 the Internet community and the semantic Web have led to new ontology languages proposals such as DAML+OIL [20], or OWL (Ontology Web Language.) [Heflin 2004] It is known that SysML architecturally aligns with the UML superstructure and customizes to support systems engineering applications, such as specification, analysis, design, verification and validation of a broad range of complex systems. As shown in Fig. 19, the major changes include enhancements to composite structure and activity diagrams and two new diagram types and new diagram usages. The overlapping of UML 2.0 and SysML motivates the use of SysML for ontology development. The overlap of UML 2 and SysML is shown in Figure 20 [SysML 2005.] Figure 19. SysML Resulting from Changes to UML

52 Figure 20. SysML Overlap with UML. In our research we investigate the application of both UML and SysML to the ontology development. This is a long-term effort and is exploratory in nature. 5.3 Organizational Behavior The question of how organizations work together in a given context can be as important as how systems can be made, technically, to interoperate in a given context. The methodology described in this paper does not explicitly treat organizational behavior nor political behavior, both of which can be important when considering the engineering of a systems of systems crossing organizational and national boundaries, such as joint service or multinational systems. However the methodology can provide a framework for understanding the consequences of organizational behavior and perhaps influence the development of organizational rules for the operation of multi-organizational and multinational systems. 52

53 West East South Figure 21. A Multinational Missile Defense System. As an example consider a multinational missile defense system of systems consisting of the national missile defense systems of three contiguous countries as shown in Figure 21. The system of systems has been designed such that all three countries, East, West and South, are to cooperate in the event of a missile attack against any or all of them. In the particular scenario shown on Figure 21 countries West and East might decide that it was not in their best to engage missiles aimed at South because of the political context. Process modeling can provide a framework for analyzing the consequences of organizational behavior in given situations and, therefore, might influence organizational behavior by being able to demonstrate the value of policy or business rules for a wide range of situations. 53

54 5.4 System Scaling The challenge of modeling system of systems increases for large systems and complex systems. An area of current and future work is to address issues associated with scaling of systems of systems models. In one study the ability to scale a model representing a medium sized area wireless communications network to a large scale battlefield was analyzed. Results showed the feasibility of such an approach [Osmundson 2002.] In a second study the ability to aggregate nodes in a network model using a collision sensing, collision avoidance protocol was analyzed both theoretically and in simulations. Results showed that a scaling law exists that allows multiple network nodes to be represented by a reduced set of nodes with an appropriate increase in message loading at each node [Osmundson and Huynh, 2004.] 6.0 CONCLUSIONS Architectural analysis of complex systems of systems using process modeling is illustrated by the examples of future expeditionary warfare and joint combat identification system of systems. The models developed in these efforts capture the objects, methods and relationships expected throughout this complex, dynamic operating system. The process modeling method enables the analysis of the dependence of architecture performance on system design factors and operational noise factors. Process modeling can be used in a similar way as a systems engineering tool to identify and analyze the most important design parameters in any complex systems of systems whose performance depends strongly on process timelines. 54

55 The approach to general systems of systems architectural analysis problems is identical to that discussed for the expeditionary warfare example. Starting at high level, the design parameters that are expected to have significant impact on system performance must be identified. The potential architectures that result from variations in the design parameters are modeled in a manner similar to UML swimlane diagrams shown in Figure 1. The system of systems of interest is treated as a collection of objects that interact by passing physical and logical items to one another. The explicit time behavior of the system of systems is captured by converting the swimlane view of the system into an executable object-oriented model that is instrumented to capture performance parameters of interest. The object-oriented nature of the executable models reduces the modeling effort when building models of different architectures; changes to an architecture can be localized to changes in specific objects and changes in specific object interactions. Some architectures will be represented by distinctly separate models and some will be represented by parameter variations within the same model. The choice of parameter values must be informed by a detailed study of the problem domain. External factors that may affect system behavior, called noise factors in this paper, must also be identified and a reasonable range of noise factor parameter values must be determined. Design of experiments can be used to reduce the number of models and simulation runs to a manageable number, and analysis of results in conjunction with design of experiments allows the extraction of system performance dependencies on the design factors and system performance sensitivities to noise factor variations. The level of abstraction of executable models is determined by the level of analysis required. Typically, as is the case of the expeditionary warfare model, initial analyses are done at 55

56 a high level of abstraction and the questions to be answered concern first order feasibility and identification of the best trade space for further analyses. The Systems Engineering and Information Sciences departments at the Naval Postgraduate School are applying the process modeling method to studies of complex information and decision system of systems. The executable models encompass all of the elements in these systems - the communication systems, processing systems and people. We analyze variations in communication methods including electronic data transmission by various means, voice and couriering, variations in communication system parameters, reliability of communication channels and processing systems, message loading on the communication system and work loading on people, and changes in business rules as they affect system performance. Results will be used to identify near term and long term approaches to system of systems developments. 56

57 REFERENCES Allen, Patrick,1992. Situational Force Scoring: Accounting for Combined Arms Effects in Aggregated Combat Models, RAND Strategy Assessment Center. Booch, G., Jacobson, I., and Rumbaugh, J.,1997. The Unified Modeling Language for Object- Oriented Development, Documentation Set, Version 1.0, Rational Software Corporation. Boury-Brisset, Anne-Claire, Ontology-based Approach for Information Fusion, In Proceedings of the Workshop on Intelligent Information Integration, 16th International Joint Conference on Artificial Intelligence (IJCAI-99). Box, George S., Hunter and Hunter, Statistics for Experimenters, John Wiley and Sons, Inc. New York, NY. Ceruti, Marion G., Ontology for Level-One Sensor Fusion and Knowledge Discovery, Combat System Science and Technology SE4021 Project Report - Combat ID, 13 June, 1997, Naval Postgraduate School, Monterey, CA. Cranefield, S. and M. Purvis, UML as an Ontology Modeling Language, Proceedings of the Workshop on Intelligent Information Integration, 16th International Joint Conference on Artificial Intelligence (IJCAI-99). Cui, Z., Jones, D. and O Brien, P. Issues in Ontology-based Information Integration, Intelligent Business Systems Research Group Intelligent Systems Lab,, BTexact Technology, (Found, 2005) Director, Expeditionary Warfare Division, N75, Office of the Chief of Naval Operations, 31 July Naval Expeditionary Warfare: Decisive Power, Global Reach, Department of the Navy, Washington, D.C. Fisher, R. A., Statistical Methods for Research Workers, Oliver and Boyd, Edinburgh. Frey, Christopher Mark, Sept., An Evaluation of Sea-Based Sustainment of Forces, Masters of Science in Operations Research Thesis, Naval Postgraduate School, Monterey, CA. Gruber, T. R.,1993. Toward principles for the design of ontologies used for knowledge sharing. Presented at the Padua workshop on Formal Ontology, March 1993, to appear in an edited collection by Nicola Guarino. Headquarters, United States Marine Corps. April MAGTF Planner s Reference Manual MSTP Pamphlet 5-0.3, MCCDC, Quantico, VA. 57

58 Headquarters, United States Marine Corps, 13 October Organization of Marine Corps Forces MCRP 5-12D, MCCDC, Quantico, VA. Headquarters, United States Marine Corps, 4 January, Operational Maneuver from the Sea, Department of the Navy, Washington, D.C. Heflin, J., R. Volz, J. Dale, Requirements for a Web Ontology Language, Working draft of the W3C Ontology Working Group, Hutchins, Susan G., Gordon Schacher, James Dailey, John Looney, Steven E. Sailor, Jack J. Jensen, John S. Osmundson, and Shelley P. Gallup, Modeling and Simulation Support for the Standing Joint Force Headquarters Concept, 10th International Command and Control Research & Technology Symposium, June 13-16, 2005, McLean, VA. Huynh, T., Osmundson, J., and Paulo, G., System of Systems Engineering for Maritime Domain Protection, White paper submitted to OUSD(AT&L), 26 April Irvine, Nelson, et al, Description and Documentation of the Extend Targeting Process Model, Naval Postgraduate School. JANUS 3.X User s Manual, 1993.Titan, Inc. Applications Group, Leavenworth, KS. Kogut, P., S. Cranefield, L. Hart, M. Dutra, K.Baclawski, M. Kokar, J. Smith, UML for Ontology Development, Knowledge Engineering Review. Larman, Craig, Applying UML and Patterns, Prentice-Hall, Upper Sadle River, NJ. Marine Corps Combat Development Command, 25 July Ship-to-Objective Maneuver, MCCDC, Quantico, VA. Marshall Associates, Combat Identification Study Final Report, USMC Contract No. M C-3028, Sterling, VA, McLean, Robert A. and Virgil L. Anderson, 1984 Applied Factorial and Fractional Designs, Marcel Dekker, Inc., New York. Melich, Michael E. and John S. Osmundson, A Systems Analysis Approach to Designing Evaluations of Multiservice Combat Identification Procedures and Capabilities, CISC-95, November, 1995, Naval Postgraduate School, Monterey, CA. Osmundson, John S., Russell Gottfried, Chee Yang Kum, Lau Hui Boon, Lim Wei Lian, Poh Seng Wee Patrick, and Tan Choo Thye, Process Modeling: A Systems Engineering tool for Analyzing Complex Systems, Systems Engineering, Vol. 7., No. 4,

59 Osmundson, John S., Lance T. Arp, Mike A. Parker, Kevin J. Stewart, and William G. Kemple, Scaling Analysis of Wireless Local Area network Technology to Large Scale Battlefields, Military Operations Research, Vol 7, No 1, Osmundson, John S., and Thomas V. Huynh, Scalability of Wireless ad hoc Networks by Simulation, Proceedings of the Conference on Systems Engineering Research, April 2004, University of Southern California, Los Angeles, CA. Osmundson, John S., A Systems Engineering Methodology for Information Systems, Systems Engineering, Vol 3, No 2, Raghavarao, Camaraju, Constructions and Combinatorial Problems in Design of Experiements, John Wiley, New York, Roy, Ranjit, A Primer on the Taguchi Method, Van Nostrand Reinhold, New York. SEIa (Systems Engineering Integration) Final Report, 2003, SEIb (Systems Engineering Integration) Final Report, Chapter XIV, Long Range, Heavy Lift Aircraft, 2003, SEIc (Systems Engineering Integration) Final Report, Chapter XV, TSSE (Total Ship Systems Engineering) Expeditionary Warfare Design, 2003, Sheth, A.P., 1998, Changing Focus on Interoperability in Information Systems: From System, Syntax, Structure to Semantics, M. F. Goodchild, M. J. Egenhofer, R. Fegeas, and C. A. Kottman (eds.) Interoperating Geographic Information Systems, Kluwer, SysML Partners, 2005.Systems Modeling language (SysML) Specification, Version 0.9, January, Taguchi, Genichi, System of Experimental Design (2 Volumes), UNIPUB/Kraus International Publications, Lanham, MD. Taguchi, G. and S. Konishi,1987. Taguchi Methods, Orthogonal Arrays and Linear Graphs, ASI (American Supplier Institute) Press, Dearborn, MI. Wache, H., T. Vögele, U. Visser, H. Stuckenschmidt, G. Schuster, H. Neumann, S. Hübner, Ontology-based Integration of Information A Survey of Existing Approaches, Proceedings of IJCAI-01 Workshop: Ontologies and Information Sharing, Seattle, WA. Waltz E., and J. Llinas, Multisensor Data Fusion, Artech House, Boston. 59

60 Authors Information Dr. John Osmundson is on the faculty of the Naval Postgraduate School in Monterey, CA, with joint appointments in the systems engineering and information science departments. His research interest is applying systems engineering and computer modeling and simulation methodologies to the development of system architectures, performance models, and system trades of complex distributed systems. Prior to joining the Naval Postgraduate School Dr. Osmundson worked for 23 years at Lockheed Missiles and Space Company in Sunnyvale and Palo Alto, CA, as a systems engineer, systems engineering manager, and manager of advanced systems studies. He received a B.S. in physics from Stanford University and a Ph.D. in physics from the University of Maryland. Dr. Osmundson is a charter member of the San Francisco Bay Area chapter of the International Council on Systems Engineering (INCOSE.) 60

61 Dr. Tom Huynh is an associate professor of systems engineering at the Naval Postgraduate School in Monterey, CA. His research interests include uncertainty management in systems engineering, complex systems and complex theory, system-of-systems engineering methodology, system scaling, simulation-based acquisition, and modeling and simulation. He applies systems engineering and computer modeling and simulation expertise to the development of system architectures, performance models, and system trades of systems of systems. Prior to joining the Naval Postgraduate School Dr. Huynh worked for 23 years at Lockheed Martin Space Systems in Sunnyvale and Palo Alto, CA, as a systems engineer, chief systems engineer, and research scientist, working in various defense programs. He received simultaneously a BA in mathematics and a BS in chemical engineering from UC Berkeley and a MS and PhD in physics from UCLA. He is a charter member of the San Francisco Bay Area chapter of the International Council on Systems Engineering (INCOSE.) 61