1

Application of System of Systems EngineeringMethodology to Study of Joint Military Systems

Interoperability

John Osmundson1, Nelson Irvine2, Gordon Schacher3, Jack Jensen4, GaryLangford5, Thomas Huynh6, and Richard Kimmel7

1Departments of Information Sciences and Systems Engineering,Naval Postgraduate School,

1 University Circle, Monterey, CA 93943-5000, josmundson@nps.edu

2Department of Information Sciences Naval Postgraduate School,1 University Circle, Monterey, CA 93943-5000, njirvine@nps.edu

3Professor EmeritusNaval Postgraduate School

1 University Circle, Monterey, CA 93943-5000, GShacher@nps.edu

4The Monterey Technology Group10300 Saddle Road, Monterey, CA 93940, jjjensen@nps.edu

5Department of Systems EngineeringNaval Postgraduate School,

1 University Circle, Monterey, CA 93943-5000, golangfo@nps.edu

6Department of Systems EngineeringNaval Postgraduate School,

1 University Circle, Monterey, CA 93943-5000, thuynh@nps.edu

7Science & Technology AdvisorCommander Third Fleet, richard.kimmel@navy.mil

ABSTRACT

The Joint Systems Baseline Assessment (JSBA) program is currently planningoperational demonstrations of a selected set of joint and coalition intelligence andcollection management systems to be performed in early fall of 2006. The NavalPostgraduate School (NPS) is applying a system of systems engineering methodology(Osmundson and Huynh 2005) to the analysis of the interoperability of the JSBA jointand coalition intelligence and collection management systems. The JSBA systems arerepresented in the NPS approach by a unified model that captures the essential elementsof ten Department of Defense Architectural Framework (DODAF) views in a single moreeasily understood view. The NPS system of systems model is also being used to theguide the instrumentation and measurement requirements for the operational

2

demonstrations. Outputs from these measurements will be used in the near future asinputs to an executable model of the joint intelligence and collection management systemof systems, and outputs of the executable model are expected to aid the identification offuture interoperability issues, as well as help identify potential interoperability solutions.

1.0 Introduction

Because systems have been acquired over many years without strict adherence to

common specifications, the US Department of Defense (DoD) faces numerous

inoperability challenges. Significant among these is the challenge to attain

interoperability among joint and coalition intelligence collection management and

targeting systems. The Joint Systems Baseline Assessment (JSBA) program is chartered

by the US Joint Intelligence Interoperability Board (JIIB), under the direction of the Joint

Forces Command (JFCOM) with support from the Joint Systems Integration Command

(JSIC), to address selected interoperability issues in a series of annual demonstrations and

studies (Singleton and Myers 2006). The JSBA program is currently planning an

operational demonstration of a selected set of joint and coalition intelligence and

collection management systems to be performed in early fall of 2006.

The JSBA program personnel and Naval Postgraduate School personnel are

applying a system of systems engineering methodology to the analysis of the

interoperability of the JSBA joint and coalition intelligence and collection management

systems. This approach is enabling identification of architectures of operational

interoperability demonstrations to be performed in September, 2006 at China Lake, CA.

The JSBA systems are represented in this approach by a unified model that captures the

essential elements of ten Department of Defense Architectural Framework (DODAF)

views in a single view. The system of systems model is also being used to the guide the

3

instrumentation and measurement requirements for the operational demonstrations.

Outputs from these measurements will be used in the near future as inputs to an

executable model of the joint intelligence and collection management system of systems.

Outputs of this executable model are expected to aid in identifying future interoperability

issues, as well as help in identifying potential interoperability solutions.

2.0 SYSTEM OF SYSTEMS ENGINEERING METHODOLOGY

Our system of systems engineering analysis methodology consists of a sequence

of analyses, transformations, model building, and simulations. The first three steps, which

have been applied to the JSBA program, are:

1. Development of system of systems scenarios and operational architectures

2. Identification of system of systems elements and threads

3. Representation of operational architectures in a Unified Modeling Language

(UML) – like format

This approach incorporates many of the features of the DoD architectural framework

but combines approximately ten of the individual DODAF architectural views into one

comprehensive view that gives high visibility to information system of systems

interoperability issues, and further can be directly translated into executable models. An

additional benefit of this approach is that it facilitates development of system of systems

ontologies, including ontologies for interoperability (Osmundson, Huyhn and Shaw

2006).

DODAF views, and one sequence for constructing the views, are shown on figure 1

(Smith 2005). AV on figure 1 refers to all views, OV refers to operational views, SV

refers to system views and TV refers to technical views. A usual starting point is the

4

development of AV-1 which includes an overview including the scope, purpose, users

and environment of a particular system of systems operation. The AV-1 sets the scope

and the context of the system of systems architecture. Next, an OV-1 is developed which

includes the operational nodes, activities performed at each node, and connectivity and

information exchange need lines between nodes. Other OV’s provide additional detailed

information. System views show how multiple systems link and interoperate and may

also describe the internal construction and operations of particular systems within the

architecture

Figure 1. A Sequence for Constructing DODAF Views. (Smith 2005)

In our system of systems engineering methodology the first step, development of

system of systems scenarios and operational architectures, corresponds to the initial step

of the DoD C4I architectural framework, which is to determine the operational context.

In this step the organizations, systems and operational goals within specified contexts are

identified.

START

AV-1Overview/Summary

OV-1High-level Operational

Concept

OV-5

Activity Model

OV-6b

Operational State TransitionDiagram

OV-2

Operational NodeConnectivity OV-7

Logical Data Model

SV-4System Function-

Operational Activity

System InterfaceDiagram

SV-1

SV-10-c

Systems Event/TraceDiagram

OV-6c

Operational Event/TraceDiagram

OV-6aOperational Rules

Model SV-6

Report:System Data Exchange

SV-5

Operational Activity/System Function Matrix

SV-9

Technology/Tech Area

AV-2Integrated Dictionary

SA Repository

SV-10b

Systems State TransitionDiagram

TV-2

StandardsTechnology

Forecast

SV-10a

System Rules Model

AV-3Capability Maturity

ProfileSA - Future

OrganizationalRelationships

OV-4

Technical ArchitectureProfile

TV-1

SV-7 System PerformanceParameters Matrix

PhysicalData

ModelSV-11

Auto- generated Report:Information Exchange

OV-3

1.0

2.0

4.14.0

3.0

5.0

3.1.2

3.1.1

3.1

8.0

7.0

6.0

3.2.1

3.2

8.4

8.5

SV-8

System EvolutionSA Derived

6.2

SV-2

Systems Communications8.2

6.1.1

6.1.2

SV-3

Matrix; Report:System - System

8.1

6.1

9.0

8.3

10.0

START

AV-1Overview/Summary

OV-1High-level Operational

Concept

OV-5

Activity Model

OV-6b

Operational State TransitionDiagram

OV-2

Operational NodeConnectivity OV-7

Logical Data Model

SV-4System Function-

Operational Activity

System InterfaceDiagram

SV-1

SV-10-c

Systems Event/TraceDiagram

OV-6c

Operational Event/TraceDiagram

OV-6aOperational Rules

Model SV-6

Report:System Data Exchange

SV-5

Operational Activity/System Function Matrix

SV-5

Operational Activity/System Function Matrix

SV-9

Technology/Tech Area

SV-9

Technology/Tech Area

AV-2Integrated Dictionary

SA Repository

AV-2AV-2Integrated Dictionary

SA Repository

SV-10b

Systems State TransitionDiagram

TV-2

StandardsTechnology

Forecast

SV-10a

System Rules Model

AV-3Capability Maturity

ProfileSA - Future

AV-3AV-3Capability Maturity

ProfileSA - Future

OrganizationalRelationships

OV-4

Technical ArchitectureProfile

TV-1

SV-7 System PerformanceParameters MatrixSV-7 System PerformanceParameters Matrix

PhysicalData

ModelSV-11

Auto- generated Report:Information Exchange

OV-3

1.0

2.0

4.14.0

3.0

5.0

3.1.2

3.1.1

3.1

8.0

7.0

6.0

3.2.1

3.2

8.4

8.5

SV-8

System EvolutionSA Derived

6.2

SV-8

System EvolutionSA Derived

SV-8

System EvolutionSA Derived

6.2

SV-2

Systems Communications8.2

SV-2

Systems Communications

SV-2

Systems Communications8.2

6.1.1

6.1.2

SV-3

Matrix; Report:System - System

8.1

6.1

9.0

8.3

10.0

5

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 (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 2 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 2, element

A1 of system A and element C1 of system C interact with system B by passing physical

items or information to element B1 of system 2. Later element B2 of system B interacts

with element B1 of system B. 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.

Figure 2. Graphical View of System of Systems Interactions in a UML Format.

Time

System A

System B

System C

Element A1

Element B1

Element C1

Element B1

Element A2

System A

System B

System C

Element A1

Element B1

Element C1

Element B1

Element A2Item exchange

6

The flow of interactions shown on Figure 2 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 system 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.

An important goal of the JSBA architectural analyses is to determine

interoperability requirements between systems. For a system of joint and coalition

intelligence management systems the directed arrows on Figure 2 represent information

items and the graphical view of the system would indicate information exchange

requirements needed for interoperability. If the graphical view shown on Figure 2 were

converted into an executable model such as a discrete event model, the timing

requirements for interoperability could be determined.

The final four steps of our system of systems engineering methodology are:

4. Identification of system of systems design parameters and factor levels

5. Transformation of the UML-like representation into executable models

6. Application of design of experiments

7

7. Simulation runs and analysis of results

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. 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 the various links in the

network, and must be identified by the systems engineer. 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. Models of system 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 sixth 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, and design of experiments provides a means of reducing the

total number of models that need to be constructed.

8

The seventh 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

based 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 APPLICATION OF SoS ENGINEERING METHODOLGY TOINTEROPERABILITY OF COLLECTION MANAGEMENT SYSTEMS

There are a number of issues associated with interoperability of collection

management systems such as: interfaces between intelligence collection management

tools and ground stations; the capability to monitor health, status, and location of

intelligence surveillance reconnaissance (ISR) assets; tasking for collection platforms

capabilities; integrating human intelligence data into command and control systems;

intelligence, surveillance and reconnaissance support to detect and defeat improvised

explosive device (IED); and enhanced workflow management. Interoperability issues

that relate to assuring that there is proper inter-system connectivity and common data

formats and structures are typically addressed in specific system developments and then

tested during JSBA technical demonstrations. In this work the focus is on interoperability

issues associated with the time flow of collection management processes.

9

In JSBA, we identify scenarios of interest and corresponding operational

architectures, beginning with a high-level operational view as shown on the operational

view (AV-1) shown on figure 3.

Figure 3. DODAF All View 1 (AV-1) of the Joint and Coalition Intelligence andCollection Management System of Systems.

Next, a UML-like representation of the joint intelligence and collection

management SoSs was developed, a portion of which is shown on figure 4.

10

Figure 4. A portion of the joint intelligence and collection management systemof systems represented in a UML-like format.

Specific threads of interest that met key JSBA objectives were identified for the

planned operational demonstration. These threads are: intelligence preparation for seizure

of a facility, a naval aviation strike against a costal target, re-tasking of sensors to collect

against high value and time sensitive targets, surveillance of border crossings,

surveillance of border crossing cued by human intelligence, and reconnaissance in

11

support of convoy operations. UML-like representations of each of the six threads were

developed by extracting the relevant organizations and functions from the total

intelligence and collection management system of systems representation, a portion of

which is shown on figure 4. An example ULM-like representation of the naval aviation

strike against a costal target thread, corresponding to a DODAF OV-6c diagram, is

shown on figure 5.

Development of system of systems scenarios and operational architectures

Identification of system of systems threads

Representation of operational architectures in a Unified Modeling Language (UML) –

like format

Figure 5. UML-like representation of the thread: Naval strike against a costal target.

Next, systems to be deployed in the operational demonstrations were mapped to

each of the UML-like thread representations. Example systems overlain on the naval

strike thread are shown on figure 6.

12

Figure 6. Example systems mapped to the thread: Naval strike against a costal target.

A useful technique to aid in understanding the system of systems interoperability

problems due to systems’ time behavior is to construct executable models of threads of

interest (Osmundson 2000). Time delays are associated with the performance of each

function and interface, such as manually inputting data, accessing communications links

and transporting data, and waiting at queues, for example. One approach to improving

systems interoperability is to minimize the total time delay associated with each

important thread of functions through the systems.

In our approach, executable models are built, instrumented, and simulations run in

order to identify bottle-necks and to give insight into potential system of systems

architecture improvements through application of design of experiments (Osmundson

GCCS -M

GlobalHawk

DGCS

13

2004.) Figure 7 shows a portion of an executable model of the mission thread for a naval

aviation strike against a costal target.

Figure 7. Executable model of the thread: Naval strike against a costal target.

JSBA technical demonstrations and operational demonstrations will be

instrumented wherever possible to provide values for executable model parameters. The

models can then be run to provide a number of important outputs including:

Measurements of thread timelines

Measurements of system throughputs

Identification of bottlenecks and choke points

Assessment of technology improvements

Assessment of potential process improvements

Identification of best architectures

In addition the models can be run under much more stressing conditions,

including high tempo of battle, that are not possible in technical and operational

count

event

CFMCC HQ

CJTF HQ

JCWG

JCMB

JTF J2

JTCB

COCOM JIC

NTM(inactive)

CFACC HQ

CAOC

ISR TacticalUnits

PED Node

Strike TacticalUnits

T0

startV

F

L W

0

Available platforms,sensors, orbits

D

T U

Receive platforms,etc.

T1

startV

Nominate

F

L W

0

D

T U

Approvenominations

T2

D

T U

Draft CPCL

T3

ApproveCPCL

D

T U

T4

DraftJPCL

T5

ApproveJPCL

D

T U

T6

Forward approvedJPCL

Create collectiondeck

T7

D

T U

D

T U

D

T U

Create expoitationregmts

Createexploitation plan

D

T U

T8

D

T Ua

b

T9 T10

D

T U

DraftJCMP

ApproveJCMP

D

T U

D

T U

D

T U

D

T U

Naval Aviation Thread Model 1.0 John Osmundson

Forward approvedJCMP

Forward approvedJCMP

D

T U

Forward approvedJCMP

D

T Ua

b

T11

D

T U

Draft MAAP

D

T UApprove MAAP

DevelopATORSTA Annex

D

T U

ForwardATORSTA Annex

D

T Ua

b

D

T U

Collect Image

D

T Ua

b

Exploit Image

D

T Ua

b

Receive Exploited Image

F

L W

0 Exit#

0

F

L W

0 Exit#

1

F

L W

0 Exit#

1

a

b

T12 T13 T14 T15 T16 T17 T18 T19

a

b

F

L W

0Exit

#

0

a

b

ndemand

Var

#

n

demand

Var

#

n

demand

Var

#

ndemand

Var

#

ndemand

Var

#

ndemand

Var

#

14

demonstrations, therefore allowing the robustness of interoperability solutions to be

tested.

4.0 CONCLUSIONS

The JSBA program is following a disciplined system of systems engineering

methodology to address joint collection management systems interoperability issues. By

combining traditional DODAF views into a single comprehensive view, all of aspects of

interoperability issues, both systems issues and organizational issues, are illuminated.

Executable models can be developed based on the same single comprehensive view, and

the executable models can be exercised to test robustness of interoperability solutions and

explore further improvements.

5.0 ACKNOWLEDGEMENTS

The authors would like to acknowledge the following sponsoring and supporting

organizations: the Joint Staff – J2 (JS-J2), Joint Forces Command – J2 (JFCOM-J2),

National Geospatial-Intelligence Agency (NGA), Joint Systems Integration Command

(JISC), and the Systems of Systems Engineering Center of Excellence (SOSECE); and

personnel including LT COL Tony L. Barker, USAF, JS-J2; CDR Joseph A. Smith, USN,

NGA; LT COL Jill E. Singleton, USAF, JISC; LT COL Anthony S. Lombardo, USAF,

JS-J2, and Russell Myers, General Dynamics contractor to JISC.

References

Larman, Craig, Applying UML and Patterns, Prentice-Hall, Upper Saddle River, NJ,1998.

Osmundson, John, and Thomas Huynh, “A Systems of Systems (SoS) SystemsEngineering Methodology.” 1st Annual System of Systems Engineering ConferenceProceedings, Johnstown, PA, June 13-14, 2005.

15

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 EngineeringTool for Analyzing Complex Systems, Systems Engineering, Vol. 7, No. 4, 2004.

Osmundson, John, Thomas Huynh and Paul Shaw, “Developing Ontologies forInteroperability of Systems of Systems,” Proceedings of the Conference on SystemsEngineering Research, Los Angeles, CA.April 7-8, 2006.

Osmundson, John, A Systems Engineering Methodology for Information Systems,Systems Engineering, Vol. 3, No. 2, July, 2000.

Singleton, Jill and Russ Myers, Joint Systems Baseline Assessment 2006 (JSBA-06)Interoperability Assessment Plan V 4.0, Joint Systems Integration Command, 5 July,2006.

Smith, Joseph A., DOD Architecture Framework (DODAF) 101, Joint Staff J2P-3 March4, 2005.