An Integrated Systems Engineering Methodology

An Integrated Systems Engineering Methodology for Analyzing Systems
of Systems Architectures
Thomas V. Huynh1 and John S. Osmundson2
1
Department of Systems Engineering,
2
Departments 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
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 nonsoftware 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
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
1
(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
Mission
Analysis
Needs Analysis
Requirements
Analysis
SoS Architecture
Alternatives
Cost and
Risk
Analysis
SoS
Architecture
Ranking
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.
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
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 SEA5 Report, June 2004 (unpublished)
3 J. Buschmann et al, Maritime Threat Response, NPS, Report Number
NPS-97-06-004, June 2006.
4 Italicized phrases in this section denote processes.
2
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 Nonfunctional 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
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 NCOWcompliant. 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
5 C2 stands for command and control
6 Comm. is shorthand for communications.
7 M&S stands for modeling and simulation.
3
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.
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 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).
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
8 In this paper, we use freely the material in [SysML Partners, 2006; S.
Friedenthal et al, 2006.].
4
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.
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
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,
9 SoSECE stands for System of Systems Engineering Center of Excellence
5
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
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 SingaporeU.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.
Figure 5. OV-1: The high-level operational
concept of the coalition SoS.
<<ContextDiagram>>
ibd[block] MaritimeDomainProtectionDomain
<<external>>
object:Ships
X2:
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,
<<system>>
MDPSoS:CoalitionMDPSoS
<<external>>
object:IntelInterface
X1:
<<diagramDescription>>
version= “1.0"
description=”U.S.-Singapore
SoS against maritime
terrorists
reference=
Completeness=
<<external>>
object:ShipComapies
X4:
X3:
<<external>>
weather:Weather
Figure 6. SysML Context diagram
corresponding to DoDAF OV-1
6
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
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 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
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.
7
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
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]
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,
, indicates, for
denoted by
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
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
8
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
Figure 14. Top-level View of Extend™ Model
of MDP SoS − a direct translation of DoDAF
OV-1 and SysML context diagram
(EngAnalysis)
bdd [bock] CoalitionMDPSoS [SoS Breakdown]
utilization of the network. The crux of this is
that an executable model can be built directly
from the SysML representation of the SoS.
<<system>>
MDPSoS
<<block>>
Network
<<block>>
USNetwork
<<block>>
C2
<<block>>
CoalitionNetwork
<<block>>
Radars
<<block>>
SingaporeRadars
<<block>>
USShipBasedRadars
<<block>>
SingaporeNetwork
<<block>>
Radar1
<<block>>
Radar3
<<block>>
Radar2
<<block>>
SingaporeC2
<<block>>
CoalitionC2
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.
<<block>>
USC2
<<block>>
USShip1
<<block>>
USShip2
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 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
9
Figure 16.
(EngAnalysis)
Some
simulation
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, 320337, 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.
results
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.
10