1

An Integrated Systems Engineering Methodology for Analyzing Systems of Systems Architectures

Thomas V. Huynh1 and John S. Osmundson2

1Department of Systems Engineering, 2Departments of Information Sciences and Systems Engineering,

Naval Postgraduate School, University Circle, Monterey, CA 93943-5000

{thuynh,josmundson}@nps.edu

ABSTRACT In this exploratory work, an integrated systems engineering methodology for analyzing architectures of systems of systems (SoS) involves linking an SoS architecture development process to the DoDAF products, using the systems modeling language (SySML 1.0) to represent DoDAF products, and hence to model the SoS architecture, and linking the SysML diagrams with the SoS architecture development process via executable object-oriented simulation models. In this paper we will explain the methodology and apply it to analysis of an integrated U.S.−Singapore SoS architecture that is network-centric operations warfare compliant employed to counter terrorism emanating from the maritime domain. Keywords: Maritime domain protection (MDP); architecture; system of systems (SoS); SysML, SysML modeling of SoS, SoS architecture development process, and executable model.

1. INTRODUCTION

We define a system of systems (SoS) as a conglomeration of existing, stand-alone systems or to-be-defined and to-be-developed systems that are integrated and interoperable with each other. Two systems are interoperable if they can successfully exchange and process information in support of a task or a mission. An SoS systems engineering problem involves analysis of existing and proposed systems of systems architectures [Osmundson and Huynh, 2005]. An integrated methodology is thus needed for analyzing SoS architectures.

An academic project (capstone project) or an industry program to develop an SoS starts with an SoS problem in which a mission to be carried out by the SoS is enunciated and ends with a set of ranked SoS architectures. In this work, the assessment of alternative SoS architectures and their ranking will be supported by modeling and simulation.

What SoS architecture development process is used to arrive at a selected architecture for an SoS? What framework is employed to capture an SoS architecture? What language is used to represent the products that capture an SoS architecture and simultaneously provide a

foundation for modeling the SoS and offer traceability between the architecture and the models in the simulation used for assessing the architecture? These questions precipitate the work elucidated in this paper.

A methodology for performing engineering analyses of systems of systems has been developed [Osmundson et al, 2004] and successfully applied to example military systems of systems [Huynh and Osmundson, 2005]. It involves the use of the unified modeling language (UML) to represent SoS models [Osmundson and Huynh, 2005]. Modeling non-software systems has been restricted by the limitations of UML, and SysML has advantages over UML in systems modeling [Rao et al, 2006]. UML thus needs be extended in order to model non-software systems [Hause et al, 2001]. The resulting language, SysML, has been recently used for system modeling − GEOSS by [Rao et al, 2006] and developing a conceptual maritime domain protection SoS by [Huynh and Osmundson, 2006].

A framework for assessing SoS architectures using modeling and simulation − the so-called SoS Architecture Development Process

2

(SoSADP)1 − has been used in Systems Engineering and Analysis capstone projects at NPS2,3. A logical, systemic, layered process, with the processes in a layer support those in the layers above, the SoSADP starts with the needs for an SoS and ends with SoS architectures assessed and ranked using modeling and simulation.

The Department of Defense (DoD) Architecture Framework (DoDAF) defines a common approach for DoD architectural description development, presentation, and integration [Wisnosky et al 2004; DAU 2003].

To the authors’ knowledge, no unified paradigm for analyzing SoS architectures exist in public literature that integrates an SoS architecture development process, the development of the DoDAF products, the SysML representation of a conceptual SoS, and an executable model of the SoS. This work is an exploratory attempt to integrate the following into a unified paradigm for analysis of SoS architectures: The SoSADP, DoDAF products, SySML diagrams, and a simulation model (converted from the SysML model.) In a nutshell, SoSADP provides the material used in the development of the DoDAF products; SySML is employed to represent the DoDAF products; simulation models are then developed to reflect the resulting SysML model.

This work is important because it strives to offer (a) an integrated methodology for analyzing SoS architectures, using modeling and simulation and (b) traceability between executable models and the SoS architecture.

The scope of this paper emphasizes the integration of the SoSADP, the development of DoDAF products, the use of SySML diagrams in representing an SoS architecture and illustrates it application with a maritime domain protection (MDP) SoS.

In Section 2 we explain the SoSADP. In Section 3 we elaborate on DoDAF and the products used in this work. In Section 4, we summarize SySML. In Section 5 we describe the mapping or the integrated process, which is the main contribution of this work. In Section 6 we describe and apply the methodology to an 1 Developed by the first author at Lockheed Martin (circa 2002), the

SoSADP has been adopted and modified for use in Systems Engineering

and Analysis projects at NPS.

2 M. Dermentzoudis et al, Maritime Dominance In The Littoral NPS SEA-

5 Report, June 2004 (unpublished)

3 J. Buschmann et al, Maritime Threat Response, NPS, Report Number NPS-97-06-004, June 2006.

integrated, network-centric operations warfare (NCOW) coalition MDP SoS. Finally, Section 7 contains some concluding remarks and future work. 2. SoS ARCHITECTURE

DEVELOPMENT PROCESS (SoSADP) A logical, systemic, layered process, with the processes in a layer support those in the layer immediately above, the SoSADP in Fig. 1 provides a framework for assessing SoS architectures using modeling and simulation. The connectors in red depict the support relationships − from a lower layer to an upper layer − while those in blue show the local (within a layer) relationships. The SoSADP starts with the SoS problem and ends with ranked SoS architectures using modeling and simulation. SoS Problem The SoS problem statement is a description of the SoS that needs to be built and sets in motion the SoSADP. The SoS problem statement provides missions, threats, unilateral or coalition undertakings, timeframes, geographical settings, needs for an SoS, and constraints.

Cos

t and

R

isk

Ana

lysi

s

SoS

Arc

hite

ctur

e R

anki

ng

Mis

sion

An

alys

isN

eeds

Ana

lysi

sR

equi

rem

ents

A

naly

sis

SoS

Arc

hite

ctur

e Al

tern

ativ

es

Figure 1. The layered structure of the SoS architecture development process (SoSADP).

Mission Analysis Mission analysis consists of determining the threats (Determine Threats4) and refining the missions (Determine Missions), and defining scenarios (Define Scenarios). A scenario includes the threats, their signatures, their trajectories, etc., the deployment of the defense forces, and the physical environment in which the mission takes place or executed. Needs Analysis 4 Italicized phrases in this section denote processes.

3

The Needs Analysis layer is built upon the output of Define Missions in the Mission Analysis layer. Analyze SoS Needs ascertains what functions the SoS must perform to execute the mission(s). Develop MOEs establishes how well the SoS must do to support the mission(s). Requirements Analysis The Requirements Analysis layer is built upon the output from the Needs Analysis layer. Perform Requirements Analysis is realized by Perform Operational Requirements Analysis, Perform Functional Analysis, Perform Non-functional Analysis, all of which use the output from Analyze SoS Needs. Perform Operational Requirements Analysis provides operational requirements. Perform Functional Analysis results in a functional description of the SoS and all facets of SoS operations and support and is accomplished through functional decomposition and allocation and development of functional flow diagrams. Perform Non-functional Analysis provides quantitative requirements. Flowdown Requirements is then performed using the results from Perform Requirements Analysis. Finally, Develop MOPs (measures of performance) uses the output from Develop MOEs (measures of effectiveness). SoS Architecture Alternatives The Requirements Analysis layer supports the SoS Architecture Alternatives layer. Identify Critical Elements, Perform Functional Embedding, Define SoS Comm. Structures, and Define SoS C2 Structures5 use the output from Flowdown Requirements, Develop MOPs in the layer immediately below. Perform Functional Embedding allocates functions to systems that make up the SoS. Identify Critical Elements establishes critical elements of the desired SoS. Identify Existing Systems identifies current systems with the required capabilities. Postulate Future Systems proposes future system elements. The results of Define SoS Comm. Structures6, Define SoS C2 Structures, Define SoS Architecture Options aid in the definition of CONOPS (concepts of operations) in Define CONOPS. Define SoS Comm. Structures establishes different Comm. Structures. Define SoS C2 Structures establishes different command and control structures. SoS Force Composition Options uses system elements and outputs of Perform Functional Analysis to define various force composition options. Define SoS Architecture Options generates SoS architectures 5 C2 stands for command and control

6 Comm. is shorthand for communications.

using outputs from SoS Force Composition, Define SoS Comm. Structures, and Define SoS C2 Structures. Develop Threads with Data & Messages uses the results from Define SoS Architecture Options and Define CONOPS. Cost and Risk Analysis Model Cost and Identify Risks provide the total cost and the risks associated with the different SoS architecture alternatives. SoS Architecture Ranking Perform M&S7 models the SoS used in simulation to aid Conduct Performance Analysis in assessing the performance of the SoS architecture alternatives. Select SoS will select the best SoS architecture. Rank SoS Architecture Alternatives ranks the SoS architecture alternatives, using the estimated MOPs and MOEs, costs, and risk factors. 2. DoDAF and DoDAF PRODUCTS The DoDAF defines a common approach for DoD architectura1 description development, presentation, and integration. The Operational View (OV), Systems View (SV), and Technical Standards View (TV) describe an architecture. Each view consists of architecture products, which are interrelated within a view as well as across views. The reader is referred to [DoDAF, Vol. II and Desktop, 2004] for a detailed description of DoDAF and its products.

An implied support structure exists among the products, albeit developed iteratively, which motivates us to capture the views and their products in a layered construct depicted in Fig. 2. Again, a lower layer supports the layer immediately above it. The AV supports the OV, which supports the SV, which supports the TV. The arrows in red indicate the connections between layers. The arrows in other colors are local to the layers to which they belong.

This work is confined to an MDP SoS architecture that is integrated and NCOW-compliant. In an integrated architecture, the products and their constituent architecture data elements in one view are the same (i.e., same names, definitions, and values) as the architecture data elements in another view [DoDAF, Vol. II and Desktop, 2004].

An integrated, NCOW-compliant SoS architecture requires twelve DoDAF products at a minimum [Wisnosky 2004]: AV-1 (Overview and Summary Information), AV-2 (Dictionary Operational Node), OV-2 (Connectivity Description Operational), OV-3 (Informational 7 M&S stands for modeling and simulation.

4

Exchange Matrix), OV-5 (Operational Activity Model Systems), SV-1 (Interface Description), TV-1 (Technical Standards Profile) , together with the products required by NCOW, namely, OV-1 (High-Level Operational Concept Graphic), SV-2 (Systems Communications Description), SV-3 (System-Systems Matrix), SV-4 (Systems Functionality Description), and SV-5 (Operational Activity to Systems Function Traceability Matrix). In this work, we concentrate on only those products that are not textual and that can be represented by SysML diagrams. We will thus elucidate OV-1, OV-6c, OV-5, SV-1, and SV-4.

Figure 2. The layered structure depicting the interrelations among the DoDAF views and their

associated architecture products. 3. SysML and SysML DIAGRAMS A general-purpose graphical modeling language for systems engineering, SysML is effective in specifying requirements, system structure, functional behavior, and allocations during specification and design phases of systems engineering.8 The reader is referred to [SysML Partners, 2006; S. Friedenthal et al, 2006] for a complete discourse on SysML. In this work, we focus on Use Cases, Requirement, Activity, Sequence, Parametric, Block, and EngAnalysis diagrams. A SysML diagram represents a model element and has a diagram frame with a header. The header displays diagram kind, model element type, model element name, and descriptive diagram name or view name (Fig.3).

8 In this paper, we use freely the material in [SysML Partners, 2006; S.

Friedenthal et al, 2006.].

A diagram kind can be labeled ‘act’ for activity, ‘bdd’ for block definition diagram, ‘ibd’ for internal block diagram, ‘sequence’ for sequence diagram, etc. A model element type includes activity, block, interaction, etc. [Friedenthal et al, 2006].

Figure 3. SysML diagram [Friedenthal et al, 2006]

3. MAPPING between SoS ARCHITECTURE DEVELOPMENT PROCESS, DoDAF PRODUCTS, and SysML DIAGRAMS The mapping between the SoSADP, DoDAF, and SysML diagrams development (Fig. 4) underlines the scope of the integrated methodology espoused in this paper. The SoSADP remains the starting point of the integrated methodology. A layer-to-layer mapping allows the DoDAF products in the DoDAF layers to capture the results from the SoSADP processes. The SysML diagrams in the four pillars of SysML, namely, Structure, Behavior, Requirements, and Parametrics [Friedenthal et al, 2006], capture the results of the SoSADP processes. The mapping between the SoSADP processes and the SysML diagrams are not necessarily one-to-one.

Figure 4. The mapping between the SoSADP, DoDAF, and SysML diagrams development

Table 1 displays the various DoDAF products for an integrated, NCOW-compliant SoS architecture that capture some of the results from the SoSADP and the SysML diagrams that represent the DoDAF products and the SoSADP results. The SysML diagrams explicitly depict

5

an SoS architecture graphically and aid in the verification of the traceability between an SoS architecture and an executable model that represents the SoS architecture. Note that a

blank space in Table 1 implies that there is no mapping among the entities of the SoSADP, DoDAF, and SysML.

Table 1. The mapping between the SoSADP, DoDAF, and SysML diagrams for an integrated,

NCOW architecture.

4. APPLICATION TO COALITION MARITIME DOMAIN PROTECTION Maritime domain awareness and maritime domain protection (MDP) have been the areas of strong interest to the U.S. and its allies. Recently, an MDP Task Force at NPS engaged in systems engineering and integration of a layered MDP SoS and the development of associated concepts of operations [Huynh 2004]. A student capstone project at NPS then followed and dealt with large ship security in the Strait of Malacca [Buschmann et al, 2005]. In 2005,

through SoSECE9, NPS was funded by the Office of the Under Secretary of Defense (Acquisition, Technology, and Logistics) to develop an integrated systems engineering methodology that provides a framework for designing SoS or complex systems and to apply it in the design and assessment of conceptual MDP U.S.-Singapore SoS architectures to prevent and defeat terrorism in the Strait of Malacca [Huynh et al, 2005]. In this paper we 9 SoSECE stands for System of Systems Engineering Center of Excellence

6

employ the integrated methodology to assess an MDP SoS architecture, with focus on SysML modeling of the MDP SoS and its foundation underlying modeling and simulation of such an SoS. Furthermore, we will, for the purpose of illustration, simplify the DoDAF products and sketch the SysML diagrams pertaining to assessment of MDP SoS architectures by modeling and simulation. The mapping between the DoDAF products and the SysML diagrams are indicated in each figure.

The statement of MDP coalition Singapore-U.S. SoS problem may be simplified as follows: Define and select Singapore-U.S. SoS architectures to counter Potential Attack Vessels (PAVs), which are vessels that potentially carry weapons of mass destruction (WMD), in the Strait of Malacca. The SoS will consist of current U.S. and Singaporean systems. Intelligence element is considered to be external to the SoS.

Part of the AV-1 contains the following. Intelligence on suspicious container ships − PAVs− and locations is received by the coalition command and control (C2) center. Orders (with initial threat data) sent to the Singaporean C2 center via the Singapore C2 network and the United States (U.S.) C2 center via the U.S. network. Singapore radars as well as U.S. war ship organic radars search for the PAVs. Data on the threats detected by the Singaporean and/or U.S. radars are sent to the Singaporean C2 center (if detected by Singapore radars) for processing, the U.S. C2 center (if detected by the U.S. radars) for processing, and the coalition C2 center (processed data by either respective individual C2 center). Detected threats are identified. Singapore Navy and U.S. Navy are then given surge orders. Weapons of mass destruction Singapore teams are assembled. Singapore vessels with search teams and U.S. ships are underway to intercept the PAVs. Search teams conduct exhaustive passive search of containers and selective active search of suspect containers. WMD detections are resolved through reach-back with land-based technical experts in Singapore or in the U.S. via agile networks. The PAVs are allowed to proceed to ports once cleared by search teams.

This paper deals only with the italicized part of the statement in the AV-1 above. We now discuss the application of our methodology to analysis of an U.S.-Singapore SoS architecture. Parenthetically, ‘coalition’ in this paper means U.S.-Singapore alliance. The OV-1 product (Fig. 5), the high-level operational concept of the coalition SoS, depicts a network of coalition C2 center located in Singapore, a Singaporean C2 center, the U.S. C2 headquarters on one of the U.S. ships, the ground-based Singaporean radars,

and U.S. ship-based radars. The Singaporean C2 network connects the Singaporean C2 center with the Singaporean radars. The U.S. ships and C2 center communicate on the U.S. C2 network.

Setting the context and the MDP SoS boundaries, the context diagram in Fig. 6 depicts the top-level systems of the SoS. The «system» and «external» stereotypes help identify the SoS relative to its environment (i.e., IntelInterface, Weather, ShipsCompanies, and Ships.).

Fig. 7 displays the use case diagram for the MDP SoS problem description. Triggered by intelligence messages from ‘Intel Agency’ actor followed by ship manifests from ‘Ship Companies’ actor, and provided with weather reports from ‘Weather Center’ actor, the coalition SoS performs a sequence of actions indicated by the use cases Receive & Process

Figure 5. OV-1: The high-level operational concept of the coalition SoS.

<<ContextDiagram>>

ibd[block] MaritimeDomainProtectionDomain

<<external>>weather:Weather

X3:

X1: X4:

<<external>>object:IntelInterface

<<system>>MDPSoS:CoalitionMDPSoS <<external>>

object:ShipComapies

X2:

<<external>>object:Ships

<<diagramDescription>>version= “1.0"

description=”U.S.-Singapore SoS against maritime

terroristsreference=

Completeness=

Figure 6. SysML Context diagram corresponding to DoDAF OV-1

7

Intel, Receive & Process Ship Manifests, Fuse Intel and Ship Manifests, Receive & Process Weather Reports, Track Threats, Process Radar Data, and Form COP. Fig. 8 shows the use case diagram for the ‘Coalition U.S.-Sing. C2’. The additional actors are the Singapore C2 center and the U.S. C2 center, which both provide status and radar reports to the coalition C2. The Form and Send Alert Messages use case is supported, through<<include>>, by the Process Intel, Process Ship Manifests, and Fuse Intel and Ship Manifest use cases. Likewise, the Formulate and Disseminate COP use case is supported by the Process Radar Reports and Status, Fuse Radar Reports and Status, and Process Weather Reports.

For the purpose of illustrating the usage of the requirement diagram, we develop a notional concept of the requirements for the U.S.-

Figure 7. The use case diagram for the MDP SoS problem description (DoDAF OV-1and

AV1).

Figure 8. The use case diagram for the ‘Coalition U.S.-Sing. C2’ (DoDAF OV-1 and

AV-1) Singapore C2 and include the resulting requirement diagrams shown in Fig.9. As a high-level view of the requirements flowdown, the requirement diagrams show the trace relationship between Coalition U.S.-Sing. SoS Requirements and a reference to a trade-off analysis that provides the rationale for this trace.

The SoS specification presumably consists of text requirements. The requirements include the critical requirement of the Coalition U.S.-Sing. C2 performance, denoted by the requirement stereotype <<criticalrequirement>> Coalition U.S.-Sing. C2 Performance and the requirement of the Coalition U.S.-Sing. C2 timing, indicated by the requirement stereotype <<requirement>> Coalition U.S.-Sing. C2 Timing. The critical requirement is a requirement stereotype subclass with the C2 performance being a critical requirement. A Coalition U.S.-Singapore C2 Use Case traces to the SoS specification to provide further refinement of the text based requirements. Both the critical requirement on the coalition U.S.-Sing. C2 performance and the requirement on the coalition U.S.-Sing. C2 timing are flowed down. We include only the requirement flowdown of the critical requirement

Figure 9. SysML requirement diagrams (DoDAF SV-4)

on the coalition U.S.-Sing. C2 performance. The flowdown is represented by <<criticalrequirement>> Coalition U.S.-Sing. C2 Performance being supported by the <<criticalrequirement>> Fuse/Analyze Performance and the <<requirement>> Decide Performance stereotypes. The Fuse/Analyze Algorithm Design package satisfies the critical Fuse/Analyze Performance specification. The Decide Algorithm Design satisfies the Decide Performance requirement

8

The activity diagram for the Coalition U.S.-Singapore SoS depicts the functions that are performed by the various parts of the systems comprising the SoS. As shown in Fig.10, the SysML activity diagram allows modeling of the SoS at the functional level. The components of the coalition SoS perform the activities represented by the parts labeled with the functions they perform. The connectivity and data flow are shown by the solid lines connecting the ports attached to the various parts. Both continuous and discrete flows are shown in the diagram.

The sequence diagram in Fig. 11 shows data/message flows between the different blocks representing the systems within the Coalition U.S.-Singapore SoS and between the Coalition U.S.-Singapore SoS and the systems external to the SoS. The sequence diagram in Fig. 11 identified by the string ‘seq: Coalition U.S.-

act CoalitionMDPSoS [Swimlanes]

act CoalitionMDPSoS [Swimlanes]

Figure 10. SysML activity diagrams (DoDAF OV-5 and 0V-6c)

Singapore C2’ in the heading shows data/message flows between the different processes within the Coalition U.S.-Singapore C2 and between the Coalition U.S.-Singapore C2 SoS and the systems external to the SoS. Upon receipt intelligence tip-off of PAVs and possibly ship manifests from ship companies the coalition

C2 disseminates command/alert messages on a coalition network to alert the Singaporean C2 and U.S. C2. Through the Singaporean C2 network, the Singaporean C2 then commands its own radars to track the PAVs. The U.S. C2, which is located on one the two U.S. ships, also commands via its own network the radars on the two ships to track the PAVs. Radar track reports are then sent to and processed by the Singaporean C2 and U.S. C2 via their own respective networks. The two C2 centers then send status and processed radar reports to the coalition C2. The coalition C2 then processes the radar reports to produce a common operating picture (COP), which is then sent out to the individual C2. The individual C2 will use the COP in their response to the PAVs.

A block has been used to represent a component of an SoS. Fig. 12 shows the blocks representing some systems of the coalition MDP

Figure 11. SysML sequence diagram (DoDAF SV-1 and OV-6c). SoS. Each block is shown with the attributes and operations. FlowPorts and ServicePorts represent the entities entering and exiting a block. Fig. 13 shows the SoS breakdown or the composition of the coalition SoS in terms of the blocks representing the systems of the SoS. The rest of the components in the diagram belong to the SoS and hence defined using the «system» stereotypes. The composition graphical path, denoted by , indicates, for example, that Singapore Radars is composed of Radar 1, Radar 2, and Radar 3.

As in [Osmundson and Huynh, 2005] which emphasizes the utility of UML-based paper model in the development of an executable model, the work in this paper brings out the utility of SysML modeling of an SoS in building an executable model of the SoS for simulation. Fig. 14 points out a correlation of the OV-1 and the context diagram with the top layer of the executable SoS model, in this case, the

9

Figure 12. Blocks with ports representing some systems of the coalition MDP SoS.

Extend™ model of the SoS. The emphasis here is the interactions among the elements of the SoS and the Intel and Ship Manifests external systems via the coalition network. Each of these graphical icons is supported by complicated modules that reside in the layer immediate below

bdd [bock] CoalitionMDPSoS [SoS Breakdown]

<<system>>MDPSoS

<<block>>Network

<<block>>Radars

<<block>>USNetwork

<<block>>SingaporeNetwork

<<block>>CoalitionNetwork

<<block>>USShipBasedRadars

<<block>>SingaporeRadars

<<block>>Radar1

<<block>>Radar2

<<block>>Radar3

<<block>>SingaporeC2

<<block>>CoalitionC2

<<block>>USC2

<<block>>USShip1

<<block>>USShip2

<<block>>C2

Singaporean network supports Singaporean C2 and radars.U.S. network supports U.S ships and U.S. C2.Common colaition network connects U.S. C2 and Singaporean C2.

Figure 13. SysML block breakdown diagram depicting composition of the coalition (DoDAF

OV-4) the top layer. For example, Fig. 15 displays the detail of the coalition C2 module, which captures the connectivity and structural contents of the activity and sequence diagrams of the Coalition U.S.-Sing. C2. Fig. 16 contains the assumed characteristics (probability distributions) of the messages generated by the different components of the coalition SoS. As shown, more PAVs, meaning more traffic (messages per second) imposed on the coalition network, more

Figure 14. Top-level View of Extend™ Model of MDP SoS − a direct translation of DoDAF

OV-1 and SysML context diagram (EngAnalysis)

utilization of the network. The crux of this is that an executable model can be built directly from the SysML representation of the SoS.

Figure 15. Extend™ Module of Coalition U.S.-Singapore C2 capturing SysML activity and

sequence diagrams.

5. CONCLUSION In this exploratory work, an integrated systems engineering methodology for analyzing architectures of systems of systems involves linking the SoSADP to the DoDAF products, using SySML to represent (to model) DoDAF products and hence to model the SoS architecture, and linking the SysML diagrams to SoSADP via executable simulation models. Focus is on an integrated, NCOW-compliant SoS architecture. The methodology represents part

10

Figure 16. Some simulation results (EngAnalysis)

of our on-going research at NPS in establishing an integrated methodology for SoS architecting and engineering to be used in industry. We illustrate the methodology with an exploratory application to analysis of a coalition U.S.- Singapore SoS architecture employed to counter terrorism emanating from the maritime domain. Our future work is aimed at extending the methodology and improving its rigor and tying it to ontological engineering. We also recognize a need for more SysML applications in modeling systems and SoS in order to bring out the advantages of SysML and to identify any features that are still missing.

REFERENCES

DAU, Introduction to Defense Acquisition Management, November 2003.

DoDAF, Architecture Framework, Version 1.0, Volume II: Product Descriptions 9 February 2004.

DoDAF, DoD Architecture Framework, Version 1.0, Deskbook, 9 February 2004.

S. Friedenthal, A. Moore, & R. Steiner, OMG Systems Modeling Language (OMG SysML™) Tutorial, July 2006.

M. Hause and F. Thom, Rebuilding the Tower of Babel − The case for UML with Real-time Extensions, INCOSE Spring Symposium 2001, May 14-16, INCOSE UK Chapter.

T.V. Huynh, Maritime Domain Protection Systems Engineering & Integration, Maritime Domain Protection Task Force Symposium Proceedings, 18-19 August 2004, Naval Postgraduate School.

T.V. Huynh, J.S. Osmundson, and P. Shaw, Research in Maritime Domain Awareness/Maritime Domain Protection/Metrification of the Littorals (DA/MDP/MoL), Presentation to OUSD(AT&L), February 7, 2006.

Huynh, Thomas V., and John S. Osmundson, “A Systems Engineering Methodology for Analyzing Systems of Systems Using the Systems Modeling Language (SysML)”, Procedings of the 2nd Annual System of Systems Engineering Conference, Ft. Belvoir, VA, sponsored by the National Defense Industrial Association (NDIA) and OUSD AT&L, 25-26 July, 2006, http://www.sosece.org.

J. Buschmann, T. Crider, G. Ferraris, E. Garcia, H. Gungor, S. Hoffmann, M. Kelley, C. MacCumbee, R. Malloch, C. McCarthy, J. McIlvaine, D. Rummler, S. Sari, T. N. Teo, D. Walton, Jr., W. Westmoreland, M. Wiens, A. Wise, G. Woelfel, R. Wyllie, H. H. Ang, K. M. Chang, C. Chua, D. Cfir, K.H. Er, Y.S. How, Y.C. Hsu, W.T. Khoo, S.J. Koh, R.Kratzer, L. Liang, J. Lim, T.L. Lim, J. Lorio, J. Lukacs, C.M. Ng, W. Ong, C.K. Quek, D. Raghavan, M. Tan, N.K. Tan, A. Teo, H.S. Teo, M. Tong, K.H. Yeoh, Y.C. Yong, Maritime Domain Protection in the PACOM AOR, Report prepared for the Deputy Chief of Naval Operations for Warfare Requirements and Programs (OPNAV N7), 2000 Navy Pentagon, Rm. 4E92, Washington, DC 20350-2000, June 2005.

J. S. Osmundson, R. Gottfried, Y. K. Chee, H. B. Lau, W. L. Lim, P. S.W. Poh, and C. T. Tan, Process Modeling: A Systems Engineering Tool for Analyzing Complex Systems, Systems Engineering, Vol. 7, No. 4, 320-337, 2004.

J. S. Osmundson and T.V. Huynh, A Systems Engineering Methodology for Analyzing Systems of Systems, Proceedings of 1st Annual System of Systems Engineering Conference, Johnstown, PA, June 13 – 14, 2005, http://www.sosece.org.

M. Rao, S. Ramakrishnan, and C. Dagli, Modeling Net-centric System of Systems Using the Systems Modeling Language, Proceedings of the Fourth Annual Conference on Systems Engineering Research, Los Angeles, CA, April 7-8, 2006, http://www.incose-la.org/cser2006.

SysML Partners, SysML Specification v. 1.0 May 2006.

D.E. Wisnosky,et al, DoDAF Wizdom, Wizdom Systems, Inc., 2004.