February 2013

COMBAT SYSTEMS ENGINEERING & INTEGRATION
1

Combat Systems Engineering & Integration Table of Contents

Introduction

5 Leading the Way Through Excellence in Combat Systems Engineering

and Integration

Captain Michael H. Smith

6 Combat Systems Engineering and Integration Edition of

Leading Edge Magazine

Dohn Burnett

7 Innovation Spanning All Levels of the Systems Engineering Hierarchy

Neil Baron 

Mission-Level Systems Engineering

8 The Importance of System-of-Systems Integration 

Alvin Murphy, David S. Richardson, and Terence Sheehan

16 Product Line Systems Engineering (Plse)

Gilbert Goddin and Chris Knowlton

24 Naval Integrated Fire Control — Counter Air Capability-Based 

System-of-Systems Engineering

Jeffrey H. McConnell and Lorra L. Jordan

32 On the Leading Edge of Interoperability

Phillip Hall and Gerrick Rosado-Vega

38 Mission Analysis in the Combat Systems Engineering Process

Stephanie Hornbaker and Sean Chapin

42 A Systems Engineering Approach to Requirements Commonality 

Across Surface Ship Combat Systems

Diana Kolodgie, Karen Shuttleworth, and Greg Albertson

50 Systems Engineering Planning

Joel Washington and Gilbert Goddin

Platform-Level Systems Engineering

58 Systems Engineering and Design – From the Total Ship 

Perspective

Miguel E. Rivera, Mark L. Williams, and Ashby G. Hall

64 Total Ship and Enterprise Approach to the Navy Platform 

Technical Team Model

David S. Richardson, Greg LaCava, and Stephen Haug

76 Where the Combat System Meets the Sailor: 

The Redesign of the Aegis Combat Information Center 

Jon Dachos

84 Advanced Capability Build Concept in Product Line 

Systems Engineering 

Joel Washington and Gilbert Goddin

90 ZUMWALT (DDG 1000) Combat System Integration Aboard the 

Self Defense Test Ship (SDTS)

Eric Sarabia and Alfredo Gabertan

Combat-Systems-Level Systems Engineering

96 Architecture Development for Shipboard Combat Systems

Diana Kolodgie, Alvin Murphy, and Terence Sheehan

104 Technology Integration and Assessment Capability

Darren C. Barnes, Neil T. Baron, and Jerry W. Oesterheld
2

Table of Contents

(Continued)

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering (Continued) 

110 Estimating Software Development Effort for Future Naval 

Capabilities

Terence Sheehan, Eric Rocholl, and Alvin Murphy

116 Integrated Training for Combat Systems: Past, Present, 

and Future

Lori Skowronski

122 NSWC Dahlgren’s Systems Engineering and Command and 

Control Expertise Applied to Marine Aviation

Douglas Haas, Damian Watson, Laura Beth Viventi-Collins, and Barret Lohr

128 Warfare System Interface Diagrams (WSIDs) in Support of 

Combat Systems Modernization

Jody Michael and Rob Byers

132 Major Combat Systems Technology Refresh for the 

Dock Landing Ship Fleet:

 Hardware Design at Combat Direction Systems Activity, Dam Neck

Barry Stevens, Larry Swinford, and Dale Bloodgood

136 Common Architecture System Assurance: Information 

Assurance for the Next Generation of Combat Systems

William Ward, Brian Hobson, Adam Simonoff, and Owen Seely

Element-Level Systems Engineering

140 Managing Computing Technology Change for

Surface Navy Combat Systems

Philip M. Irey IV, Leslie A. Madden, David T. Marlow, Greg D. Miller, and Jerry W. Oesterheld

Leading Edge magazine—produced by the Naval Surface Warfare Center, Dahlgren Division, Dahlgren, 

Virginia— is an official, authorized publication of the Naval Warfare Center Enterprise. The purpose of the 

publication is to showcase technical excellence across the Warfare Center Enterprise and promote a broader 

awareness of the breadth and depth of knowledge and support available to the Navy and DoD.

Address all correspondence to Corporate Communications, C6

Email: dlgr_nswc_c6@navy.mil; or write to

Commander

Naval Surface Warfare Center, Dahlgren Division

Corporate Communications, C6

6149 Welsh Road, Suite 239 

Dahlgren, VA 22448-5130

NSWCDD/MP-13/22

Approved for public release; distribution is unlimited.
3

Draft – Working Papers

Draft – Working Papers

Naval Sea Systems Command

Vice Admiral Kevin M. McCoy, Commander

Brian J. Persons, Executive Director

NAVSEA Warfare Centers

Rear Admiral (Select) Lawrence E. Creevy, Commander, NSWC

Rear Admiral Thomas G. Wears, Commander, NUWC

Donald F. McCormack, Technical Director, NUWC, and 

Acting Technical Director, NSWC

Naval Surface Warfare Center, Dahlgren Division

Captain Michael H. Smith, Commander

Stuart A. Koch, Acting Technical Director

Neil Baron, Distinguished Scientist/Engineer for Combat Systems, 

Warfare Systems Department

Dohn Burnett, Head, Warfare Systems Department

Janice Miller, Acting Corporate Communications Director

David Richardson, Managing Editor

Margie Stevens, Production Coordinator

Kellie Yeatman, Graphic Artist, Electronic Magazine Design & Production

Clement Bryant, Graphic Artist, Layout & Design

Trey Hamlet, Graphic Artist, 3-D Modeling

NSWC Dahlgren Authors

Darren Barnes David Marlow

Neil Baron Jeffrey McConnell

Sean Chapin Greg Miller

Jon Dachos Alvin Murphy

Gilbert Goddin Jerry Oesterheld

Douglas Haas David Richardson

Ashby Hall Miguel Rivera

Phillip Hall Eric Rocholl

Stephen Haug Gerrick Rosado-Vega

Stephanie Hornbaker Owen Seely

Phillip Irey Terence Sheehan

Lorra Jordan Karen Shuttleworth

Chris Knowlton Adam Simonoff

Diana Kolodgie Laura Beth Viventi-Collins

Greg LaCava Joel Washington

Barret Lohr Damian Watson

Leslie Madden Mark Williams

CDSA Dam Neck Authors

Dale Bloodgood Lori Skowronski

Rob Byers Barry Stevens

Brian Hobson Larry Swinford

Jody Michael William Ward

NSWC Port Hueneme Authors

Alfredo Gabertan Eric Serabia

Strategic Insight Ltd. Authors

Greg Albertson Warren Lewis

3
4

COMBAT SYSTEMS ENGINEERING & INTEGRATION
5

Leading the Way Through Excellence in 

Combat Systems Engineering and Integration

Introduction

Naval Surface Warfare Center, Dahlgren Division 

(NSWCDD) has a long heritage of integrating increasingly more 

complex systems into the warfighting capability for the nation. 

With an enduring technical professional development program, 

NSWCDD has successfully shown the value of engineering 

rigor within the systems hierarchy (i.e., components, systems, 

platforms, and missions). Our scientists and engineers are experts 

in translating needed mission capabilities into engineering 

solutions and are committed to providing the Navy’s core 

technical capability for the integration of sensors, weapons, and 

their associated weapon and combat systems into surface ships 

and vehicles. 

Our goal is to provide leadership in large-scale, end-toend systems engineering at the system level, system-of-systems 

level, and mission level. The articles in this Combat Systems 

Engineering and Integration edition of Leading Edge attest to 

this leadership and describe NSWCDD’s work in pioneering 

integrated solutions for the surface Navy. Throughout this 

publication, you will follow the journey to solve incredibly 

complex problems and gain an insight into the innovative 

enhancements, analysis, and designs that are making a difference 

to ensure optimal support for the warfighter and the Fleet. You 

will learn more about the Navy’s efforts in developing systems 

that are increasing flexibility and bringing advanced capability 

as we push the limit on power technologies and total ship 

integration.

The world will be different in the future and our warfighting 

capability needs to change with it. Limited footprint aboard 

ships will require more efficient use of available space. This 

edition of Leading Edge looks into the future with articles 

describing multifunction systems that will help us manage our 

topside requirements and deepen our magazines as well as nextgeneration systems. It also provides a look at the Navy’s totalship-enterprise approach and demonstrates how the approach is 

utilized by the Navy to support system integration to address the 

challenges in our 21st century Fleet. 

I invite you to explore the Combat Systems Engineering & 

Integration edition of Leading Edge and learn about the exciting 

and important work NSWCDD and others are doing in support 

of integrated combat system solutions across mission domains. 

Given the wide array of contributions our team is making, I am 

proud to say that our Navy will continue to be protected from 

adversaries, now and in the future. 

Captain Michael H. Smith, USN

Commander, NSWCDD
6

Welcome to the Combat Systems Engineering & Integration 

(CSE&I) edition of Leading Edge. The area of CSE&I has 

undergone significant evolution in the past decade. In that 

time, the art and science of CSE&I has progressed from systems 

engineering at the combat systems level, to the systems-ofsystems level and mission level. While these later areas are 

still rapidly evolving, many of the associated challenges have 

been recognized, characterized, and in some cases mitigated 

through recently defined processes and tools. Developing the 

competencies to engineer at these levels is critical to providing 

effective warfighting capabilities at affordable costs. At the same 

time, other aspects of CSE&I have evolved to address challenges 

such as computing technology insertion, cyber security, human/

systems integration, and state-of-the-art computer program 

development. Overarching all of this is the need to reduce costs 

while ensuring the warfighters have the quality systems they 

need. Many of these vital subjects are explored in this edition. 

I encourage everyone who has a stake in CSE&I to read through 

the articles, engage in discussion with the authors, and help 

ensure our collective capabilities can respond to the continuing 

challenges we are facing.

Acknowledgments

There are many people who worked very hard to make this Combat 

Systems Engineering and Integration issue of Leading Edge a reality.

I would like to thank the Technical Information Services Office’s 

(CX7) publishing staff and the NSWCDD Corporate Communications 

team (C6), who worked hard to produce this professional document.

My thanks also go to the authors who provided their expertise and 

talent and put key thoughts together in writing these articles.

I’d like to acknowledge the support of my chain of command—my 

Commander, Captain Mike Smith, and my Technical Director, Mr. Carl 

R. Siel, Jr.—who have been very supportive of our work in combat 

systems for the Navy, joint, and national needs areas.

Finally, I want to recognize Mr. David S. Richardson who led this 

effort for the Warfare Systems Department (W Department) and kept 

things moving forward. Mr. Richardson provided a critical review of 

all the articles and worked with many of the authors to ensure that the 

articles were current, relevant, and not redundant. He was also our 

Department liaison to Corporate Communications and the Command 

Public Affairs Office and is largely responsible for successful publication 

of this Leading Edge issue. I would also like to thank Mr. Neil Baron 

and Mr. Gil Goddin for their assistance in developing our theme and 

reviewing articles.

Mr. Dohn Burnett

Head, Warfare Systems Department

NSWCDD

Combat Systems Engineering and Integration

Edition of Leading Edge Magazine

Introduction
7

Foundational to the framework of systems engineering for 

U.S. Navy combat capabilities is the notion of a hierarchical 

relationship spanning from the smallest of computer components 

to the immenseness and complexity of the Aircraft Carrier Battle 

Group. Technical requirements and operational definitions are 

specified at each level of the hierarchy through a structured 

approach of decomposition (down) for development/production 

and then aggregation and integration (up) to achieve a deployable 

combat capability. From the day that Marconi brought the first 

radio to sea until today — the age of the digital computer — the 

capabilities and complexities of naval combat systems have grown 

to truly span all the levels of the systems engineering hierarchy. 

The machine of war, U.S. Navy combat capability at sea, is 

defined, developed, produced, tested, certified, and deployed at 

each level of the hierarchy. This is certainly a technical challenge, 

but it is also a scheduling and fielding challenge as the continued 

flexibility of adapting to threat-driven changes is also enabled 

through the same technology. The combat capabilities of our 

systems, ships, aircraft and land vehicles, and our deployed 

aircraft carrier, expeditionary, and surface action battle groups 

are continually evolving throughout their service lives and 

deployment schedules.

To help gain an insight into each area of combat capability 

development, we have chosen to structure the articles in the 

Combat Systems Engineering & Integration edition of Leading 

Edge utilizing the systems engineering hierarchy that drives so 

much of our effort. The articles are categorized at the mission 

level, platform level, system level, and component (or element) 

level; they explore development of specific products for 

particular levels of the hierarchy as well as the application of 

engineering disciplines such as requirements, certification, or 

cost engineering at those levels.

By structuring our work through the systems engineering 

hierarchy, we are able to safely and effectively engineer and 

manage naval combat system developments. There is nothing 

more complex, more demanding of engineering mastery, more 

dominating the world over, and yet more sensitive to catastrophic 

system failure than the naval warship at sea defending our nation; 

yet that is what a warship is built to do.

Please enjoy this Combat Systems Engineering & Integration 

edition of Leading Edge.

Innovation Spanning All Levels of the

Systems Engineering Hierarchy

Introduction

Mr. Neil Baron

Distinguished Scientist / Engineer

for Combat Systems

Warfare Systems Department, NSWCDD
Combat Systems Engineering & Integration

Mission-Level Systems Engineering

8

The Importance of System-of-Systems Integration

by Alvin Murphy, David S. Richardson, and Terence Sheehan

It is evident from today’s budget constraints that the Navy can no longer afford 

to build new and unique combat systems for each ship class. The Navy realizes that 

computing architectures in many of its systems are performance-limited and expensive 

to upgrade due to restricted, single-ship-class acquisition processes. The Navy is under 

intense pressure to control the rising costs of warfare systems and aging platforms 

and, at the same time, build a surface ship fleet capable of meeting emerging threats. 

To manage the various platform developments while keeping costs under control, the 

Navy must transition to managing this development within an enterprise portfolio of 

vessels. The Naval Surface Warfare Center, Dahlgren Division (NSWCDD), is uniquely 

situated and its employees are specifically trained to execute this transition. 

Combat Systems Engineering & Integration

Terminal Guidance

Intercept

Mission-Level Systems Engineering
The Importance of System-of-Systems Integration

9

Origin of Integrated Warfare Systems

Development of the Aegis Weapon System (AWS) was a revolutionary implementation of integrated 

warfare systems engineering generated as a result of the Advanced Surface Missile System (ASMS) 

Assessment Group. The group evaluated weapon system alternatives reaction time, greater firepower, 

expanded coverage, and higher availability and reliability through systems integration. The decision was 

made, at the time, to design and develop the entire ASMS system, later to be named “Aegis,” within a single 

project office where systems engineering methodologies could be applied to manage the requirements, 

allocate functions to system elements, and manage budgets across the system elements. Subsequently, 

Aegis has been able to deliver extremely capable, integrated systems that meet evolving requirements 

primarily by adhering to rigorous systems engineering and integration processes. The AWS integrated 

closed-loop fire control is shown in Figure 1.

The Importance of System-of-Systems Integration

9

Figure 1. AWS Integrated Closed-Loop Fire Control

Search

Detect

Track

Illuminate

Track

Midcourse

Guidance
Mission-Level Systems Engineering

10

Combat Systems Engineering & Integration

Migration to System-of-Systems 

(Sos) Engineering

Eventually, the Navy needed to apply the 

integrated systems engineering process at 

the force level for increased interoperability 

and mission performance, especially given 

the advent of advanced communications 

and data sharing opportunities, such as the 

Cooperative Engagement Capability (CEC). 

NSWCDD, as a leader in combat systems 

engineering, subsequently became a leader in 

SoS engineering, establishing leadership roles on 

the Combat System Functional Allocation Board, 

Design Community of Practice, and Architecture 

Community of Interest. The Naval System of 

Systems, Systems Engineering Guide1

 provides 

this definition for SoS:

The term system of systems (SoS) is used to 

describe an integrated force package of interoperable 

systems acting as a single system to achieve a mission 

capability. Typical characteristics include a high 

degree of collaboration and coordination, flexible 

addition or removal of component systems, and a netcentric architecture. Individual systems in the SoS 

may be capable of independent operations and are 

typically independently managed. An example would 

be an Expeditionary Strike Group acting to provide 

coordinated naval fires. The capabilities provided by 

each constituent system operating within the SoS are 

framed by the integrated force package architecture.

An SoS provides improved capabilities 

through network-centric operations. Designing, 

building, and managing SoS integration is an 

enormous task, given the entire set of systems, 

programs, platforms, and force compilations. 

Figure 2 depicts the complexity of Navy SoS 

integration overlaying the other services with 

similar integration challenges. 

So, why is integration at the SoS level 

necessary? Mission analysis indicates SoS 

performance significantly increases performance. 

It engages more threats, uses ordnance 

expeditiously, experiences fewer blue-onblue force (friendly fire) engagements, reduces 

collateral damage, and provides a number of 

other benefits including winning wars faster. 

Surface Navy Sos Vision

Platform-specific systems are being 

replaced with a common core set of combat 

capabilities used across all surface ships. As a 

result, the differences among combat system 

capabilities across ship classes will be limited 

to unique mission capabilities. The benefits of 

a common core set of capabilities are many, 

including fewer systems serviced, consistent 

warfighting methods, cross-platform training, 

and reduced shore infrastructure costs. The 

vision for enterprise combat system solutions 

is the development of reusable product line 

components into a single combat system 

Figure 2. Department of Defense (DoD) SoS
The Importance of System-of-Systems Integration

11

architecture. NSWCDD, with its decades 

of experience, leads the definition and 

implementation of this product line architecture 

(PLA). 

Implementation of the PLA increases 

competition and encourages a “best-of-breed” 

open business model based on the following five 

principles:

•	 Modular designs

•	 Competition and collaboration

•	 Interoperability through commonality

•	 Reusable software components

•	 Life cycle affordability using commercial

off-the-shelf (COTS) and technology 

insertion processes

Based on these principles, and using an open 

business process, the Navy, via the leadership 

of NSWCDD, decoupled combat system design 

from ship design, developed modular combat 

systems, facilitated software and hardware reuse, 

and incorporated COTS open standard-based 

components for ease of upgrade, as illustrated in 

Figure 3.

Product Line Approach to Sos

A software product line is a set of softwareintensive systems, sharing a common, managed 

set of features that satisfy the specific needs of 

a particular market segment or mission, and 

that are developed from a common set of core 

assets in a prescribed way.2

 Implementation of 

a product line approach for surface Navy SoS 

requires significant changes in how the systems 

engineering organization manages requirements, 

architectures, and detailed designs. NSWCDD 

is uniquely postured to support the warfighter 

and provide superior combat system capabilities 

by systems engineering the integration of SoS 

capabilities. In providing these capabilities, a 

product line approach is used. A product line 

approach requires integration and alignment 

of acquisition activities to realize the potential 

benefits of the approach.

In a document titled, A Software Product 

Line Vision for Defense Acquisition,

3 the author 

points out:

Many DoD missions depend on systems for 

which requirements and enabling technology change 

and are deployed at multiple sites and versions. A 

separate or modified solution for every circumstance 

can be wasteful and time-consuming. Instead, 

missions could be better served if acquisition 

programs were to take a product line perspective to 

explore whether and how different needs, operational 

contexts, solution technologies, and potential changes 

could be anticipated and addressed through an 

ability to develop and deploy different solutions. 

By exploiting the similarity inherent in alternative 

solutions to perceived mission needs, a product line 

acquisition could create a capability for the rapid 

production, deployment, and evolution of multiple 

products, each customized to suit specific needs. 

Figure 3. Surface Navy Product Line Vision
Mission-Level Systems Engineering

12

Combat Systems Engineering & Integration

SoS Enablers

SoS enablers include technical competency, 

architecture, enterprise requirements, and a 

systems engineering management plan (SEMP).

Technical Competency

An understanding and an acceptance of the 

need to develop and maintain a foundational 

enterprise technical competency are both 

required for enterprise-level integrated mission 

systems. The Navy needs to nurture and sustain 

a cadre of technical experts in its warfare centers 

because those experts are in the best position to 

understand the operations, requirements, and 

system instantiations across ship classes (i.e., 

aircraft carriers, amphibious platforms, and 

surface combatants) and across system domains 

(e.g., combat system, C4ISR [Command, Control, 

Communications, Computers, Intelligence, 

Surveillance, and Reconnaissance], aviation, 

hull, mechanical and electrical, and computing). 

SoS engineers (SoSEs) need broad experience 

working on different programs during their 

careers, and they need to have worked at the 

detailed technical level. Additionally, they need 

to be federal employees to facilitate access and 

visibility across programs. Multiple Program 

Executive Offices must be able to trust the SoSEs 

as honest brokers and technical authorities, 

especially when their recommendations 

sometimes contradict recommendations of 

subordinate program managers. 

Architecture

PLA development is a critical 

enabler for moving to a product line 

approach. A common architecture 

consists of an enterprise architecture, 

system architecture, and software 

architecture. All are distinct, but 

interrelated levels compose the overall 

architecture. Enterprise architecture 

defines business structures and the 

processes that connect them.4

 It further 

describes the flow of information and 

activities among various groups within 

the enterprise to accomplish an overall 

business activity. A repeated theme 

from SoSE lessons learned is the need 

for a clear understanding of integration 

scope, end-user requirements, and 

a systems engineering management 

process across all stakeholders. 

System and software architectures 

describe the system elements and 

software components and the interactions of a 

complete system. In a product line approach, 

an architecture reference model is established 

first to ensure common understanding of 

terminology, functional allocation, and data flow 

among system components. The reference model 

is then mapped onto a reference architecture 

to define a PLA that is used to define specific 

system architectures. PLAs should address the 

evolution of the capabilities in order to address 

future requirements. Quality attributes, such as 

modifiability, extensibility, performance, etc., 

facilitate assessment of architectural options. 

Software patterns such as publish/subscribe 

provide well-known solutions to architectural 

problems, such as extensibility; however, it 

should be noted that various patterns may have 

negative impacts on related quality attributes, 

such as performance. Architectural relationships 

are shown in Figure 4.

Enterprise Requirements

The migration of existing programs to a 

product line approach may require significant 

effort to align platform mission system 

specifications. Figure 5 presents a notional 

approach for moving from multiple unique 

specifications to product lines for surface 

combatants, carriers, and amphibious platforms. 

NSWCDD manages requirements by functional 

domains, as well as by mission areas, to facilitate 

Figure 4. Architectural Relationships5
The Importance of System-of-Systems Integration

13

allocation to combat system elements within the 

architecture and to assess capabilities through 

mission area analysis to specific product line 

requirements.

Enterprise Systems Engineering and 

Management Plan

As defined by industry standards, such 

as the Standard for Information Technology – 

Software Life Cycle Processes (IEEE 2207),6

establishment of an enterprise SEMP is critical 

for moving an organization toward a product 

line approach. The SEMP should provide (1) 

technical program planning, implementation, 

and control; (2) the systems engineering process; 

and (3) methodology for specialty engineering 

integration. 

Challenges

There are a number of challenges to the SoS 

approach; these include organizational, working 

with industry and academia, and political 

challenges.

Organizational

The Navy is organized for systems 

acquisition in a way that reflects our historical 

planning, funding, and acquisition execution 

(the verticals). Requirements are defined around 

platforms as opposed to product line capabilities 

(the horizontals) that can be employed across 

multiple platforms. Because organizations tend 

to reflect the environment in which they work, 

both the acquisition community and the customer 

side of the Navy are aligned to the vertical 

perspective. The most effective mitigating action 

to this challenge is to organize the requirements 

and budget infrastructure, including how 

appropriations are structured, to better reflect the 

benefits of the horizontally integrated enterprise. 

Working with Industry

Industry must become a willing and effective 

partner. Businesses participate in procurement 

and evaluate their competitive position in relation 

to each other based on potential work, reward, 

and future opportunity—whereas NSWCDD supports integration plans that support healthy industrial opportunities as well as maintain maximum 

system performance for the sailor and value for 

the taxpayer. Under this new, open business model, opportunities for competition will increase 

within the industrial base, encouraging best-ofbreed capability selection. 

Figure 5. Mapping of Existing Requirements to a Product Line Approach
Mission-Level Systems Engineering

14

Combat Systems Engineering & Integration

Working with Academia

Academia is a significant contributor 

in research and experimentation with new 

technology. It is important that NSWCDD 

includes academia in collaborations to 

continue to stay on top of the technology and 

implementation curve. It is also important that 

academia be kept current with the latest Navy 

SoS solutions and challenges so that future 

generations of engineers can be trained and 

prepared to replace the current work force. 

There is a variety of external challenges to 

overcome to achieve an open business model. 

We must capitalize on the forward-thinking and 

involvement that academia provides.

Political

Congress must be engaged as a willing 

partner and effective ally and have a clear 

understanding of the business model. The Navy 

will need to work with the Congress to clearly 

articulate the value and options to manage these 

within an enterprise construct.

Conclusion

The surface Navy requires a centrally 

managed, technically founded, large-scale SoS 

engineering capability at the cross-platform, 

combat system level to effectively manage 

combat system enterprise development. The 

approach to move toward an enterprise warfare 

systems environment for surface combat systems 

is centered on establishment of a product line 

approach for developing reusable components 

that can be assembled by the platform system 

integrators into systems that meet all the 

requirements of a particular ship class and 

enhance broad Navy warfighting. The focus, 

therefore, needs to be on key technical initiatives 

to enable this evolution. Notwithstanding, an 

enterprise organizational structure, continuity 

of leadership, and revitalization of government 

technical roles in the Navy’s warfare centers 

enable this evolution. The need to transition 

the surface Navy’s combat systems acquisition 

processes, technical underpinnings, and 

organization to a product line approach is 

pressing. The benefits to be derived from 

implementation of the new business model 

and enterprise systems engineering principles 

extend from tangible cost savings to rapid and 

effective integration of warfighter capabilities. 

The transition of the surface combat system 

acquisition enterprise to the new business model 

will be essential to Navy efforts to achieve its 

objectives for the size and strength of its surface 

combatant ship force.

NSWCDD has a long heritage of integrating 

increasingly more complex systems into the 

warfighting capability for the nation. With an 

enduring technical professional development 

program, NSWCDD has successfully shown the 

value of engineering rigor within the systems 

hierarchy (i.e., components, systems, ships, and 

force). Consequently, an aggressive yet paced 

reinsertion of NSWCDD as the prime integrator 

for targeted major weapon system acquisitions 

represents a sound Navy strategy. 

References

1. Naval “System of Systems” Systems Engineering Guidebook, 

Volume II, Office of ASN (RDA) Chief Systems Engineer, 

6 November 2006.

2. Clements, P., and Northrop, L., Software Product Lines: Practices 

and Patterns, Boston, MA: Addison-Wesley, 2002.

3. Campbell, G., Jr., A Software Product Line Vision for Defense 

Acquisition, June 2002.

4. Zachman, John A., “A Framework for Information Systems 

Architecture,” IBM Systems Journal, Volume 26, No. 3, 1987.

5. Carnegie Mellon University/Software Engineering Institute, 

(CMU/SEI), Software and Architecture, Principles and Practices, 

2007.

6. Standard for Information Technology – Software Life Cycle 

Processes (IEEE 12207), Institute of Electrical and Electronics 

Engineers, May 1998.
The Importance of System-of-Systems Integration

15

The Importance of System-of-Systems Integration
Combat Systems Engineering & Integration

Mission-Level Systems Engineering

16

Product Line Systems Engineering (PLSE)

by Gilbert Goddin and Chris Knowlton

The Navy has long applied a product line-like approach to selected subsets of 

its overall warfighting capability. For example, the weapons control system for the 

Tomahawk cruise missile has been fielded in many configurations across several 

surface ship classes as well as in the submarine fleet. Adaptations were made to 

accommodate the needs of each host platform, but most of the weapons control 

software was taken from a common product line core. Similarly, the Aegis Combat 

System has been differentiated into many product variants tailored to multiple baseline 

variations across two classes of ships. Reapplication of common features that proved 

successful, while introducing new capabilities in later baselines, was an effective way 

to develop the product line over time. Treating the core combat systems across a wider 

variety of surface combatants as a single product line, however, is just beginning.

The concept of a product line is well established in the commercial sector where 

this approach has been used by car manufacturers, cell phone makers, and computer 

companies to create a variety of unique products tailored to specific applications, all 

based on a common core. The Boeing Company, for example, developed the 757 and 

767 air transports as a product line. The parts lists for these two very different aircraft 

overlap by about 60 percent, thereby achieving significant economies of production 

and maintenance.1

 When this concept is applied to software, a product line is a related 

group of software-intensive systems developed from a set of common core components 

or a common source library. The rationale for doing this is typically to improve 

development time, cost, productivity, and quality.
17

Product Line Systems Engineering (PLSE)

Evolving Product Line Approach

As each surface Navy combat system moves 

towards a predictable, repeatable development 

cycle for fielding new capabilities in advanced 

capability builds (ACBs), it will become 

increasingly possible to coordinate development 

schedules across platforms and find opportunities 

for product line solutions supporting shared 

operational needs. However, a change in 

engineering methodology is required. Instead 

of stove-piped systems engineering focused on 

unique combat system programs, a product line 

systems engineering (PLSE) approach is being 

considered as the underpinning to the future 

surface combat system acquisition process.

The PLSE approach is very much a work in 

progress, but several characteristics are emerging. 

PLSE is clearly a system-of-systems engineering 

challenge, requiring the systems engineering 

organization to look across multiple ship classes as 

well as across multiple epochs when determining 

optimal plans and approaches for implementing 

new capabilities. PLSE makes use of the same 

systems engineering techniques and strategies that 

have become familiar in other complex softwareintensive combat systems engineering projects. 

What makes PLSE unique is that it widens the 

aperture of what is considered a system to include 

an entire potential product line, rather than 

just a single ship combat system. The systems 

engineering approach remains familiar, however, 

and consists of the following:

•	 Multiplatform mission thread analysis

•	 Requirements analysis

•	 Architectural analysis

•	 PLSE management

Multiplatform Mission Thread 

Analysis

Multiplatform mission thread analysis is a 

technique that shows great promise for use in 

PLSE. In a conventional mission thread analysis, 

a particular operational problem or challenge is 

examined in detail from end to end to determine 

alternatives and best options for addressing 

that challenge. The multiplatform mission 

thread analysis extends conventional analysis 

by identifying shared operational needs across 

platforms and evaluating common product line 

solutions where appropriate.

To conduct a mission thread analysis, a 

detailed operational scenario is first established. 

This scenario should accurately describe the 

operational environment and the expected 

challenges for a particular mission area and for 

a particular timeframe. For combat systems, 

mission threads are often threat driven, so they 

should make use of accepted, and whenever 

possible, common representations of current and 

future threats and their associated environments 

validated by the intelligence community. The 

mission thread scenarios themselves should 

depict force-level employment of a system of 

combat systems to counter the threats under 

consideration, according to an accepted concept 

of operations, and from approved sources such 

as design reference missions for programs slated 

to receive the combat systems under analysis. 

Once a set of operationally relevant scenarios 

is selected for the mission thread analysis, the 

scenario is examined using current combat 

system capabilities and inventories. The expected 

performance of current combat systems is 

determined through analysis of operational 

effectiveness, including such measures as 

probability of kill, survival of the examined unit 

or force, or attainment of mission objectives over 

time. Often, this analysis will reveal weaknesses or 

capability gaps that should be addressed through 

future combat system product line upgrades. The 

results of this gap analysis lead to a more detailed 

statement of the operational problem and set 

the stage for identification of options for closing 

the operational gaps. The next step of mission 

thread analysis is identifying possible (or leading) 

options for product line upgrades.

Once a set of upgrade options is identified, 

it is further analyzed from the perspectives of 

performance, cost, schedule, and risk to find the 

preferred options for further systems engineering 

development and implementation. When applied 

to the combat system product line, one of the key 

goals of the mission thread analysis is to examine 

all of the surface combatants in the product line 

to determine how the new capability might affect 

each one of them. For example, many combat 

systems in the product line share a requirement to 

provide tactical air control for aircraft assigned to 

them, but only large-deck, aviation-capable ships 

like aircraft carriers require a full air traffic control 

capability to manage large numbers of aircraft 

in the immediate vicinity of the ship. Evaluation 

of these types of differences in mission are 

important drivers that will help determine which 

requirements are shared between members of the 

combat system product line and which are unique 

to a single platform.

Another key goal of the product line mission 

thread analysis is to examine the operational 

gaps and the resulting upgrade options from 
18

Mission-Level Systems Engineering

Combat Systems Engineering & Integration

the perspective of the desired product line 

architecture for the combat system. When 

upgrade options are developed in this context, 

the proposed solutions are more likely to drive 

commonality into the product line over time. A 

product line mission thread analysis provides 

insights that drive requirements and architecture 

decisions. When the mission thread analysis 

reveals a need for common functionality across 

platforms, a set of upgrades and modifications 

to the product line architecture is defined. 

A description of the scope of each change is 

produced, including boundary conditions 

and major functionality to be included in 

each affected product line component. When 

performing this analysis from a cross-platform 

perspective, care must be taken to ensure 

that the functionality specified satisfies the 

minimum needs of the most stringent user. This 

analysis is performed at varying levels of detail 

until a detailed set of “design-to” and “buildto” functions result. These results can then be 

translated into detailed design requirements 

for the product line component at hand. Once 

again, care must be taken to ensure that the most 

stringent cases are considered to ensure that the 

resulting requirements satisfy the most stressing 

scenarios. Using this systems engineering 

approach, requirements and architecture are 

developed together at increasingly higher levels 

of detail until the system is fully designed. This 

approach also ensures an integrated design since 

all requirements are likewise defined using an 

integrated approach. 

Product Line Requirements 

Analysis

Operational requirements for 

joint and naval forces are initially 

expressed in the form of very 

high level Mission Area Initial 

Capability Documents (MAICD) or other capstone statements 

of mission requirements. For 

example, a Theater Air and Missile 

Defense (TAMD) MA-ICD was 

developed in 2004 to describe 

desired operational capabilities 

and perceived warfighting gaps for 

naval TAMD forces. These desired 

force capabilities are inherently 

cross-platform requirements, 

with a variety of naval and joint 

platforms cooperating to meet the 

overall force warfighting need. 

One of the first steps in upgrading individual 

combat systems, in response to the MA-ICD, 

is to extract the capabilities pertaining to a 

particular combat system and capture the subset 

of operational requirements for that specific 

combat system. For example, a platform-specific 

operational requirements document (ORD), 

capabilities development document (CDD), or 

naval capabilities document (NCD) is generated 

or updated to capture the operational capabilities 

applicable to the particular platform. A weakness 

in the current approach is that each platform 

performs its own analysis to determine how it 

should contribute to the overall force mission 

capability and extracts what it perceives to be 

the correct subset of MA-ICD capabilities for 

inclusion in its own platform-specific CDD 

or NCD. Each platform does this in relative 

isolation from other programs. The resulting 

CDD or NCD then becomes the primary driver 

for further system specification, architecture, and 

development. As shown in Figure 1, the current 

systems engineering process becomes platformcentric very early in the development process as 

each platform follows its own unique solution 

path. 

A product line requirements analysis 

approach would help address this divergence as 

this approach takes advantage of the fact that the 

capstone MA-ICD already contains statements 

of operational capability that span a number of 

naval and joint platforms. As shown in Figure 2, 

the top-level operational capabilities common to 

more than one platform could be developed as 

(or at least should be considered as candidates 

Figure 1. Platform-Centric Systems Engineering Approach
19

Product Line Systems Engineering (PLSE)

for) common development using the product line 

systems engineering approach. 

The first step in the PLSE approach is to 

perform product line requirements analysis 

on the top-level, cross-platform mission 

area requirements for a capability using the 

multiplatform mission thread analysis approach 

described earlier. This approach views the 

platforms as swim lanes for the analysis and 

high-level combat system functions allocated 

to these platforms in an end-to-end analysis. 

After a sufficient number of iterations and 

decomposition of this process, the aggregated 

functions are then translated into a set of 

operational requirements for each platform. 

In this manner, the operational requirements 

are integrated and deconflicted. Based on the 

resulting operational requirements (i.e., CDD, 

NCD), subsequent requirements analysis efforts 

focus at the system level to identify common 

versus unique combat system requirements. 

Therefore, in addition to allocating operational 

requirements to each affected system’s CDD or 

NCD in a coordinated manner, those capabilities 

common across platforms are identified up front. 

All common requirements are then generated and 

included in a product line system requirements 

database that contains the common requirements 

in the context of the common architectural 

framework across all platforms. Platform-unique 

requirements continue to be defined by the 

individual programs. Accordingly, a full systemlevel requirements specification for each program 

consists of program-unique requirements and 

common requirements from the product line 

system requirements database. 

Product line system requirements are best 

maintained using a modern requirements 

management tool such as IBM Telelogic’s 

Dynamic Object-Oriented Requirements 

System (DOORS). The database contains 

both the requirements statements as well as 

attributes indicating the platform to which each 

is applicable. Initially, the product line system 

requirements database would be populated by 

drawing from the system specifications of existing 

combat systems. Although these individual 

system specifications were not coordinated, they 

contain similar requirements in many areas. Once 

all platform system specifications are available 

in a common database, the product line system 

requirements can be created by normalizing these 

requirements by grouping similar specifications 

and rewriting them as common statements 

of functionality and performance. When 

new warfighting capabilities are identified for 

addition to the combat system product line, the 

resulting common cross-platform combat system 

requirements could then be added to the product 

line system requirements database. Then, when 

individual platform combat systems engineers 

analyze their CDD or NCD to create their systemlevel specifications, they can draw requirements 

directly from the product line system 

requirements database for those capabilities that 

are common to more than one platform.

Figure 2. Product Line Systems Engineering Approach
20

Mission-Level Systems Engineering

Combat Systems Engineering & Integration

Product Line Architecture 

Analysis

Concurrent with the product line 

requirements analysis, the architectural impacts 

of integrating the new warfighting capability in 

the surface combatant fleet need to be analyzed. 

The goal of this architectural analysis is to provide 

a mapping of the operational requirements onto 

a system (or in this case, product line) that can 

deliver the desired capabilities. Conducting this 

analysis for the product line introduces several 

new challenges when compared to architectural 

analysis for a single ship combat system. These 

challenges include:

•	 Assessing and resolving architectural 

differences between members of the 

product line

•	 Developing and upgrading a common 

product line objective architecture

•	 Determining appropriate migration plans

•	 Integrating architectural plans and 

schedules between product line members

Architectural analysis and requirements 

analysis are conducted concurrently because the 

outputs of each analysis effort feed the other. At 

the cross-platform level of architecture analysis, 

one of the major goals is to map the required 

operational capabilities for the force as a whole 

onto the individual ship combat systems. The 

output of the architecture effort is a partitioned 

set of requirements, allocated appropriately across 

the platforms. These partitioned requirements 

can then be mapped onto each combat system’s 

system-level architecture to come up with the 

appropriate partitioning of requirements at the 

system level. One of the key differences between 

product line architectural analysis and the 

traditional approach is the earlier point at which 

product line architectural analysis occurs in the 

systems engineering process. 

Traditionally, force-level operational 

requirements are first allocated to individual 

ships before any architectural analysis begins. 

Architectural analysis is then conducted on 

just the set of requirements for that ship, and 

the resulting architectural decisions affect only 

that ship. In product line architectural analysis, 

the force-level operational requirements are 

assessed to extract the corresponding system-level 

requirements so that architectural impacts on the 

product line are identified as a whole, particularly 

on common product line components. These are 

determined prior to final allocation of systemlevel requirements to individual members of the 

product line. As a result, not only are system-level 

requirements allocated to the platforms but, when 

appropriate, technical solutions are allocated in 

the form of plans, specifications, and componentlevel architectures as well for components 

designed to meet the operational requirements 

for all members of the product line. These 

common, planned component upgrades then 

become a constraint on the receiving systems, 

which must be engineered into their respective 

platform architectures. Levels of architecture (and 

requirements) include cross-platform operational 

architecture, platform-level systems architecture, 

platform-level element architecture, and platformlevel component architecture.

In general, surface combatants are multimission combatants. As a result, they participate 

in several mission areas at the same time. For 

example, an Aegis combatant supports integrated 

air and missile defense, undersea warfare, and 

strike warfare concurrently. The operational 

architectures for each of these warfare areas 

are different but must be woven together into a 

single, cohesive system design at the platform 

level. This introduces additional architectural 

considerations that must be addressed at the 

system level over and above those mandated when 

considering the mission operational requirements 

alone. For example, as ballistic missile defense 

operational capabilities are integrated, resource 

contention and multi-warfare interactions with 

other air defense requirements of the ship must 

be considered, as well as manning constraints and 

interactions with other mission areas. The level of 

maturity of the combat system product line must 

also be considered. 

PLSE Management

Achieving the goal of developing all surface 

combat systems using a product line approach 

requires that a new governance and decisionmaking process be put into place for product 

line systems engineering management. This new 

management process must address several new 

issues that have emerged when all combat systems 

are viewed as a system of systems. Product line 

questions that must be answered include:

•	 Which platforms share common 

operational requirements?

•	 Which capabilities should be developed as 

part of the common product line and which 

are unique?

•	 Which platform should develop the 

common products?

•	 When should these common products be 

introduced onto the host combat systems?
21

Product Line Systems Engineering (PLSE)

Clearly, managing a product line systems 

engineering process demands significant 

coordination and communication, because it 

involves systems engineering organizations 

at the overarching product line level – the 

individual platforms, the systems engineering 

agent contractors for each of the platforms, and 

possibly third-party contractors and organizations 

assigned responsibility for development of 

common components and capabilities. Production 

schedules for all of the platforms in the product 

line have to be communicated, assessed, and 

deconflicted to enable coordinated cross-platform 

development, particularly when there are critical 

path interactions between programs and platforms. 

The understanding of requirements, specifications, 

and technical characteristics of combat system 

component designs must be exchanged reflecting 

several levels of detail. Cross-platform and 

overarching product line governance structures 

and technical interchange forums need to be 

established to ensure alignment.

Because the surface Navy combat system 

product line is a system of systems produced 

by a variety of organizations over time, the 

communication of technical plans and schedules 

between programs is critical to ensuring effective 

coordination. This communication across and 

among related combat system contributing 

programs is beginning to take the form of a 

Capability Phasing Plan (CPP). The CPP is a 

concise summary of planned upgrades to a 

subsystem, component, or element, and include 

several key features:

•	 A listing of upgrades planned for the system

•	 A brief description of the upgrades

•	 A time-phased plan for rolling out the upgrade, preferably tied to particular ACBs for 

the targeted host combat system(s)

•	 Any known dependencies or relationships 

between these upgrades and those planned 

for other related systems, particularly if upgrades must be delivered together as a package to a combat system platform

•	 Funding profiles related to the upgrade

Although a final format for the CPP has not 

been defined, the content listed above has been 

useful in coordinating acquisition activities across 

the system of systems. One way to maintain 

and exchange information is through the war 

room approach, in which all combat system 

feeder programs contribute and maintain their 

upgrade roadmaps to a common space that all 

other programs can access. Coordination across 

programs then can take the form of formal and 

informal visits and reviews of the technical and 

programmatic information compiled in the war 

room to ensure consistency and synchronization 

between efforts and, when warranted, to spark 

more detailed follow-on discussions between 

combat system constituents. In addition to 

maintenance of a physical war room facility as a 

focal point for cross-program roadmap information, this data needs to be made available to all 

stakeholders through an integrated development 

environment with adequate controls to protect 

program data while making roadmap changes and 

updates available to all interested parties. 

Implementing Product Line 

Systems Engineering

Implementing product line systems 

engineering for surface combat systems requires 

a fresh look at the traditional government 

and industry roles and responsibilities in the 

acquisition process. The responsibility for systems 

engineering of naval surface combat systems is 

a shared task, with the government providing 

program oversight, program management, and 

technical review of systems engineering efforts for 

the affected combat systems. An industry prime 

contractor provides much of the technical analysis 

and detailed systems engineering effort. This 

model has worked well because each platform’s 

combat system has been maintained as a separate 

entity associated with a dedicated prime contractor.

Moving toward product line systems 

engineering and acquisition will require many 

important systems engineering decisions affecting 

multiple combat systems and industry partners. 

These decisions include determining whether 

to develop or procure particular upgrades, 

which programs should be funded to develop 

a common capability that will later be shared 

between programs, and other procurementsensitive systems engineering decisions. These 

types of product line combat systems engineering 

decisions are best made within the government, 

although the government will continue to rely 

on the technical expertise of its combat system 

contractors. That said, the government must 

increasingly develop and rely on its own technical 

resources for product line systems engineering 

in key areas of high-level system architecture 

definition and planning and combat system 

requirements management. This includes systemlevel specification development and maintenance 

of the program roadmaps for all combat systems, 

contribution elements, feeder programs, and the 

product line itself.
22

Mission-Level Systems Engineering

Combat Systems Engineering & Integration

NSWCDD’s Role in PLSE Process 

Development

The Naval Surface Warfare Center, Dahlgren 

Division (NSWCDD), has been a significant 

contributor to the Program Executive Office 

for Integrated Warfare Systems (PEO IWS) in 

conceptualizing and documenting key systems 

engineering processes for PLSE. These processes 

span the systems engineering spectrum from early 

capability planning and programmatic support 

through development and fielding of capabilities 

on individual platforms. The approach taken 

to define and capture these evolving processes 

and their associated business rules is to apply a 

use case modeling approach using the Unified 

Modeling Language (UML). Figure 3 shows 

several use cases identified as functions of PEO 

IWS in executing PLSE, external agencies that 

interact with PEO IWS in carrying out these use 

cases, and primary areas of interaction.

For each of these use cases, more detailed 

activity diagrams were generated to further 

define the use case. Each organization involved, 

both inside and outside of PEO IWS, is 

assigned a vertical swim lane, which contains 

the process steps (i.e., activities) performed by 

that organization. Figure 4 is an example of one 

such activity diagram for the use case “Conduct 

Enterprise Systems Engineering,” which focused 

on the cross-platform, product line aspects of the 

systems engineering process.

These activity diagrams provided a convenient 

mechanism for describing both the processes 

and the organizational roles and responsibilities 

for PLSE. This approach captured the process 

knowledge as it was evolving, and it served 

as a way to communicate the current state of 

understanding with other process stakeholders 

who then provided valuable inputs for extending 

and refining the activity diagrams to reflect their 

particular areas of expertise.

NSWCDD used the results of this PLSE 

process modeling effort to generate the PEO IWS 

Systems Engineering Concept of Operations 

(SE CONOPS). The SE CONOPS defines the 

PEO IWS Product Line Systems Engineering 

Process and the Concept of Operations for 

Combat Systems Engineering across surface Navy 

platforms, which is applied to all programs and 

projects within PEO IWS. The initial release of 

the SE CONOPS was signed by RDML Benedict 

in April 2010. (PEO IWS Systems Engineering 

Concept of Operations, Version 1.0, dated 22 

April 2010). NSWCDD is leading efforts to 

further define and update the PLSE processes to 

be included in this forthcoming revision. Figure 5 

identifies the planned activity diagram updates.

Conclusion

The Navy’s approach to product line systems 

engineering across surface combat systems is 

still a work in progress. PLSE is not an attempt 

to make the combat systems on all ships the 

same, but rather, a disciplined engineering 

methodology to reduce overall acquisition cost 

by deploying common core capabilities across 

platforms and by developing unique functionality 

for individual ships where necessary to fulfill 

unique system requirements. In order to achieve 

the goal of delivering new capabilities using 

PLSE, a new governance and decision-making 

process is required. Key to success is collaboration 

Figure 3. PLSE Use Case Diagram for PEO IWS Product Line Systems Engineering
23

Product Line Systems Engineering (PLSE)

by resource sponsors, program managers, ship 

integration program managers, platform systems 

engineering agents, and participating acquisition 

resource managers across multiple ship classes in 

government-led requirements definition. PLSE 

needs to commence with operational requirements 

and continue until the system-level requirements 

are complete for each combat system in the 

product line. Institutionalizing this rigorous 

product line requirements and architecture analysis 

approach undoubtedly will lead to common system 

requirements, further leading to the development 

of common components for all surface combat 

systems supporting future Navy warfighting needs. 

Acknowledgment

Warren Lewis (Strategic Insight Inc.) contributed to this article.

Reference

1. Carnegie Mellon University, Software Engineering Institute, Software Product Lines, http://www.sei.cmu.edu/productlines/start/

index.cfm, accessed 5 Oct 10.

Figure 4. Activity Diagram for PLSE Process

Figure 5. Planned PLSE Process Updates
Mission-Level Systems Engineering

Combat Systems Engineering & Integration

Naval Integrated Fire Control – Counter Air

Capability-Based System-of-Systems Engineering

by Jeffrey H. McConnell and Lorra L. Jordan

“Understanding the environment in which a system or system of systems (SoS) 

will be developed is central to understanding how best to apply systems engineering 

(SE) principles within that environment.”1

 Since 1996, the Naval Integrated Fire 

Control – Counter Air (NIFC-CA) project has been striving to develop an SoS 

capability to defeat overland cruise missile and Over-the-Horizon (OTH) air warfare 

threats. Lacking the luxury of a “directed” SoS SE organization with component 

systems subordinated to the overarching SoS, the NIFC-CA project has utilized the 

“acknowledged” SoS SE methodology. This approach empowers an SoS SE team 

to work collaboratively with independent component system SE teams to achieve 

SoS capabilities and objectives. The NIFC-CA SoS SE approach has been very 

challenging but also rewarding and is viewed by the Deputy Under Secretary of 

Defense for Acquisition and Technology (DUSD(A&T)) as a pilot model for future 

SoS acquisition programs. With the successful completion of all critical design review 

(CDR) milestones in 2009, a review of the NIFC-CA SE environment, approach, and 

accomplishments is timely and instructive for similar developmental programs.

NIFC-CA Background

In a letter dated January 11, 1996, Mr. Paul Kaminski, then Under Secretary 

of Defense for Acquisition and Technology (USD(A&T)), and the Vice Chairman, 

Joint Chiefs of Staff (VCJCS), Admiral W. A. Owens, initiated action to address the 

emergence of the overland cruise missile threat.2

 Very challenging situations are 

presented by this threat when the detection and illumination of cruise missiles, that 

can also change course and speed, become blocked by the Earth’s curvature, coastal 

hills, mountains, and varying types of terrain. 

Beginning with the 1996 letter, technologies and acquisition programs were given 

direction or guidance to ensure emerging developmental systems would include 

capabilities supporting the resultant Overland Cruise Missile Defense (OCMD) SoS. 

Specifically, OCMD was to be supported by the development of the Army aerostat 
Naval Integrated Fire Control – Counter Air

Capability-Based System-of-Systems Engineering

25

program (known today as the Army Joint Land 

Attack Cruise Missile Defense Elevated Netted 

Sensor (JLENS)), improvements to the Navy E-2C 

and Air Force E-3 early warning aircraft, and 

advanced interceptor seeker development. 

In 2002, the OCMD program was officially 

recast as the NIFC-CA project in a joint 

ASN(RDA) and VCNO letter.3

 This recasting 

documented the growth of project scope to 

defeat the OTH manned fighter and OTH antiship cruise missile (ASCM) threat in addition 

to the original OCMD mission. The letter also 

directed Program Executive Officer – Integrated 

Warfare Systems (PEO IWS) to establish a NIFCCA Systems Engineering and Integration Project 

Office to “integrate across the elemental programs 

in support of the development and acquisition of 

a NIFC-CA Capability.” NIFC-CA was to execute 

as a capabilities-based acquisition project, levying 

minimal requirements onto the component 

systems while deriving SoS capability from the 

union of these independent systems.

In 2010, NIFC-CA resolved into an advanced 

Family of SoS (FoS) engineering project that is 

working to combine multiple sensors through 

IFC-compliant combat systems to support 

extended range active missiles. The NIFC-CA 

FoS officially includes three complete SoS known 

as “killchains” as illustrated in Table 1. Each 

SoS killchain consists of elevated and surface 

sensor(s), a sensor network, a weapon control 

system and an active missile. The balance of this 

paper will concentrate on the FTS killchain.

The NIFC-CA SoS SE Environment

“Control your own destiny or someone else 

will.” – Jack Welch – former CEO of General 

Electric

An SoS is defined as a set or arrangement of 

systems that results when independent and useful 

systems are integrated into a larger system that 

delivers unique capabilities.4

The ability to control the outcome of any 

SoS development is a function of the authority 

available to the SoS manager or SoS integrator. In 

all SoS acquisition programs, the developmental 

environment is a key driver of what can be 

accomplished, how the systems acquisition and 

systems engineering will be performed, and 

whether the ultimate outcome is successful or not. 

The SoS “type,” as described below, dictates 

how much authority and control is available to 

the SoS manager and systems engineering team to 

achieve SoS objectives. The type further addresses 

SoS component system independence and the 

manner in which the component systems are 

aligned, either by direction or cooperation, to 

achieve SoS capabilities. 

Table 1. The NIFC-CA Family of System of Systems
26

Mission-Level Systems Engineering

Combat Systems Engineering & Integration

SoS Type

The DUSD/A&T Systems Engineering Guide 

for SoS describes the four types of SoS typically 

seen across DoD and industry. Table 2 lists all 

four types with a short description of each to 

help delineate and define the “acknowledged” SoS 

approach utilized by NIFC-CA. 

The virtual and collaborative types are not 

utilized for the development of SoS that have the 

intended purpose of delivering lethal force. The 

more intentional systems engineering processes 

inherent in the acknowledged and directed types 

of SoS are essential to lethal systems development. 

The Missile Defense Agency (MDA) is a 

contemporary example of a directed SoS type. 

On January 2, 2002, the Secretary of Defense 

refocused and reorganized the existing Ballistic 

Missile Defense (BMD) program into the newly 

formed MDA with the mandate and authority to 

manage all aspects of the component systems as a 

synergistic whole. This SoS type is very attractive 

but a rarity, typically mandated at the secretariat 

level for national priority programs such as 

the Strategic Systems Program, the National 

Reconnaissance Office, and the MDA.

NIFC-CA is an example of and a USD 

pilot project for the “acknowledged” type 

of SoS. NIFC-CA is charged with bringing 

together independent major defense acquisition 

programs (MDAP) as component systems of 

the NIFC-CA SoS. These programs have their 

own operational requirements, specific funding 

lines, independent developmental timelines, and 

staggered deployment schedules. The mandate 

to collaborate with and support the NIFC-CA 

project management and systems engineering 

team has been communicated from senior USD, 

ASN, and Navy leadership but still presents a 

tough balancing act for all program managers 

involved.

NIFC-CA Acquisition Leadership and Management

Successful management of acknowledged 

SoS SE projects requires reaching across 

organizational boundaries to establish an endin-mind set of objectives and the resourced plan 

for achieving those objectives. The acknowledged 

SoS type increases the complexity, scope, and 

cost of both the planning process and systems 

engineering, and introduces the need to 

coordinate interprogram activities and manage 

agreements among multiple program managers 

(PMs) as stakeholders who may not have a vested 

interest in the SoS. 

Through 2002, as the Navy solidified 

its programmatic approach to NIFC-CA 

development, the organizational structure 

depicted in Figure 1 evolved. This picture was 

completed in 2006 as PEO IWS-7, the NIFCCA Project Office, established a collaborative 

government/industry systems engineering 

integration & test (SEI&T) team that is primarily 

Table 2. SoS Types

Virtual

A virtual SoS lacks a central management authority and a centrally agreed upon purpose for the system 

of systems. Large-scale behavior emerges—and may be desirable—but this type of SoS must rely upon 

relatively invisible mechanisms to maintain it. The DoD net-centric policies and strategies that connect all 

DoD systems to virtual networks for information sharing are creating a virtual SoS. 

Collaborative

In a collaborative SoS, the component systems interact more or less voluntarily to fulfill agreed upon central 

purposes. The Internet is a collaborative system. The Internet Engineering Task Force works out standards 

but has no power to enforce them. 

Acknowledged

An acknowledged SoS has recognized objectives, a designated manager, and resources for the SoS; 

however, the constituent systems retain their independent ownership, objectives, funding, and development 

and sustainment approaches. Changes in the component systems are based on collaboration between the 

SoS and the component system. 

Directed

A directed SoS is one in which the integrated SoS is built and managed to fulfill specific purposes. It is 

centrally managed during long-term operation to continue to fulfill those purposes as well as any new 

ones the system owners might wish to address. The component systems maintain an ability to operate 

independently, but their normal operational mode is subordinated to the central, managed purpose.
Naval Integrated Fire Control – Counter Air

Capability-Based System-of-Systems Engineering

27

composed of personnel from the NIFC-CA 

Project Office, government laboratories, academia, 

and industry (with team members from each 

component system). 

The task of the NIFC-CA SEI&T effort is to 

ensure the component programs are integrated 

to achieve a viable SoS by matching individual 

system contributions to SoS performance goals. 

The NIFC-CA capability is not derived from a 

set of initial requirements leading to component 

program selection. Rather, the NIFC-CA 

capability is derived from the SoS performance 

predictions via analysis and/or SoS models 

and simulations that describe the expected 

performance of the component systems.

NIFC-CA Capability Acquisition 

and SoS Engineering

Over the past decade, the NIFC-CA 

government/industry team has made significant 

accomplishments across the acquisition 

spectrum both at the FTS SoS killchain level 

and within the supporting component systems. 

Figure 2 illustrates the disciplines, processes, 

tools, and products that have been executed 

throughout the development of the NIFC-CA 

Capability. 

The challenge lying before the SEI&T 

team working with the component systems’ 

engineering teams is summarized in the 

following basic statements: 

1. The Aegis combat system was designed in 

the 1970s and has evolved and expanded 

dramatically ever since. 

2. The Aegis combat system provides a selfcontained, highly engineered anti-air warfare system with a dedicated phased array 

multifunction radar; a robust, time-critical command and decision system; and a 

semiactive interceptor (SM-2) that is tightly controlled all the way to intercept. 

3. For IFC engagements, the SEI&T team was 

charged with uncoupling and distributing 

this single-system killchain across independent pillar systems consisting of multiple nonorganic sensors, connected via the 

CEC network to the Aegis Combat System 

so that it can control the SM-6 missile until 

it goes below the horizon, becoming active 

and independently concluding the engagement. 

While Figure 2 takes on the form of the 

familiar Systems Engineering “V,” the individual 

steps and functions performed within the chart 

may not seem familiar. Based on a limited budget 

and the acquisition/engineering management 

environment described so far, this chart describes 

the analyses and engineering deemed essential 

to reassemble the distributed killchain, automate 

remote sensor and interceptor management, 

and ensure performance against a wide range of 

threats in many theaters and scenarios. 

Figure 1. NIFC-CA SoS Management
28

Mission-Level Systems Engineering

Combat Systems Engineering & Integration

The key timeline drivers within this chart 

are the four CDRs listed that each component 

system was scheduled to meet within its system 

acquisition timeline. The challenge for the SEI&T 

was to execute and finalize all NIFC-CA analysis, 

functional allocation, and design documentation 

in time to support each CDR for each component 

system. The transition from analysis and 

engineering to implementation, integration, and 

T&E is denoted at the bottom of the V, marking 

when the final component system CDR took place 

in November of 2009. The following sections of 

this paper will discuss several of the processes 

performed on the left side of the V. 

System Architecture Development

For NIFC-CA as an acknowledged SoS type, it 

became apparent that a good system architecture 

would be essential to NIFC-CA development. In 

2002, NSWC Dahlgren began working with pillar 

program offices, FTA killchain system engineers, 

and prime contractors to develop a NIFC-CA 

DoD Architecture Framework (DODAF) 

architecture. 

In 2006, with the establishment of the SEI&T 

industry team, architecture development drove 

toward a complete architecture with enough 

insight at the component systems level to validate 

NIFC-CA functional allocations and information 

exchange requirements (IERs) across the entire 

killchain. Details of the SoS functionality were 

added as killchain analyses and design work were 

conducted for each pillar. This effort ensured 

the allocated design fulfilled the operational 

architecture. 

The NIFC-CA architecture has been utilized 

as the authoritative source of information to 

guide system engineering tasking as well as high 

level discussions with other military services, the 

Joint Integrated Air and Missile Defense Office 

(JIAMDO), and other organizations. The NIFCCA DODAF architecture has proven to be a 

powerful tool for capturing the functionality, 

communications, and essential information of the 

Figure 2. NIFC-CA Capability Acquisition and SoS Engineering 
Naval Integrated Fire Control – Counter Air

Capability-Based System-of-Systems Engineering

29

NIFC-CA SoS. It has fostered communications 

across the killchains and within the component 

pillar systems while documenting the requirements for incorporation of future sensors, 

weapons, and combat systems supporting IFC as 

well as future functionality and capability spiral 

evolution.

NIFC-CA FTS Killchain Engineering Analysis

As described earlier, the key engineering 

challenge within NIFC-CA FTS has been the 

decomposition of a tightly integrated real-time 

killchain and subsequent reallocation of that 

killchain across independent component systems. 

Killchain Engineering Analysis is an essential part 

of ensuring that the resultant distributed killchain 

will perform effectively and safely across all SoS 

component systems. 

Within the collaborative environment of the 

government/industry SEI&T team, the entire FTS 

SoS killchain was reviewed and performancecritical and/or time-critical functions identified 

for detailed analysis. Performance Assessment 

Report (PAR) plans were developed and assigned 

to small teams partnering different prime 

contractors and government personnel to analyze 

these critical functions. Two examples illustrate 

the scope and importance of this analysis:

•	 The Containment PAR analyzed the maximum size error basket that would be required from the remote sensors via the CEC 

network in order to support SM-6 missile 

active seeker performance.

•	 The Sensor Support Quality of Service 

(QOS) PAR defined the attributes and parameters that would be requested by the 

weapons control system in order for CEC 

to find and provide remote sensors meeting 

that QOS request.

NIFC-CA FTS Killchain Systems Engineering 

Based on the findings of the killchain 

engineering analysis and guided by the NIFCCA DODAF architecture, working groups were 

formed to address specific killchain systems 

engineering topics. In order to engage component 

system program offices and engineers within 

the broader Navy IFC community, collaborative 

groups were created to facilitate engineering 

tasking and information exchange in the form of 

Interface Working Groups (IWGs) and Technical 

Interchange Meetings (TIMs). 

Due to the staggered nature of the CDRs for 

each of the component systems and the early 

CDR date for the SM-6, an Aegis/SM-6 IWG was 

the first group to gather and develop the specific 

documentation artifacts for the interface between 

the Aegis ACB12 combat system and the missile. 

This is a historic working relationship going back 

several decades for all variants of the Standard 

Missile family. Even so, the SM-6 is a major 

upgrade in capability, and significant design and 

interface tasking had to be accomplished. 

The Aegis/CEC IWG (ACIWG) was 

established next in order to design and document 

several CEC-to-Aegis interfaces. In order to 

allow many current and future sensor types to 

support SM-6 engagements, the Aegis WCS is 

being built to be “sensor agnostic”; essentially 

it will not know the specific characteristics of 

remote radars, just the real-time characteristics 

of their tracking information. To support this 

uncoupling, CEC was tasked to take on the 

function of finding and providing remote sensors 

that are able to meet Aegis Quality of Service 

(QOS) requirements for each engaged target. 

Therefore, the ACIWG took on the challenge of 

creating and documenting a new paradigm for 

IFC sensor support.

29

Naval Integrated Fire Control – Counter Air

Capability-Based System-of-Systems Engineering
30

Mission-Level Systems Engineering

Combat Systems Engineering & Integration

In mid-2006 it became apparent that a 

larger forum including engineers and leadership 

supporting CEC, Aegis, and all sensors was 

needed to discuss and document the detailed 

engineering that supports the overall NIFCCA architecture. This forum was established as 

the Sensor Netting Leadership Team (SNLT). 

This team, working closely with the ACIWG, 

took on the challenge of fleshing out the midlevel architecture (IERs, functional allocation, 

operational sequence diagrams) and, eventually, 

the low-level integration agreements that 

are generally invisible outside of contractor 

development facilities. This latter category 

basically came down to discussions and 

agreements between two companies on either 

side of an interface regarding topics such as 1) 

data unit interpretations, 2) mathematical matrix 

transformations, 3) matrix rotation conventions, 

etc. This function of the SNLT was needed 

because this kind of coordination historically 

would have occurred within a single prime 

contractor. With a distributed SoS killchain, a 

pseudo-government forum had to be established 

to enable and capture this kind of discussion 

between prime contractors on either side of an 

interface.

NIFC-CA SoS SE Accomplishments

With the successful completion of the 

Aegis ACB12 CDR in November 2009, a very 

capable, flexible, and extensible IFC design was 

established across the pillars of the NIFC-CA FTS 

capability. The FTS SoS detailed design is being 

implemented by each component system as this 

article is being written. The resultant product 

will allow the Fleet to engage any target from 

the near-horizon to the maximum kinetic range 

of the SM-6 and future interceptors utilizing a 

variety of sensors. 

At a less apparent level, the NIFC-CA 

engineering teams took the opportunity to apply 

basic systems engineering principles to distribute 

the NIFC-CA killchain across component 

systems and establish a solid foundation for 

rapid evolution of future IFC capabilities. Key 

system engineering and software engineering 

techniques, including modularity, abstraction, 

and information hiding, were applied during the 

functional allocation and distribution process 

resulting in a system that is far more extensible, 

allowing dramatic evolution and innovation in 

the future. The following are examples of SoS SE 

innovations applied during the NIFC-CA design 

process:

1. Sensor Agnostic WCS: In order to 

accommodate a variety of remote nonSPY sensors, the ACB12 Aegis baseline was 

chosen as a point of implementation for a 

new Reduced State Estimator (RSE) WCS 

filter design. This design does not rely on 

hard-coded knowledge of sensor type and 

performance (information hiding) but is 

designed to accept basic covariance data 

describing the sensor track error basket 

and dynamically apply that data within the 

filter. This breaks the hard coupling across 

the interface between WCS and sensors 

(better modularity), allowing for many 

different sensors to become providers for 

engagements without any modification to 

WCS design or code.

2. CEC Best Sensor Selection (BSS): Early in 

the NIFC-CA design process, the decision 

was made to institute basic networkcentric principles by assigning NIFC-CA 

remote sensor selection and management 

to the CEC network. This decision 

provides full support to the decision 

to uncouple WCS from remote sensors 

and moves sensor management closer to 

the actual sensors while ensuring WCS 

accuracy and timing requirements are 

met. Based on a QOS requested by WCS 

for each target, the new CEC BSS function 

will find from one to several sensors 

capable of meeting the QOS and make 

contracts with each sensor to provide data 

for the engagement. Per these contracts, 

CEC will provide one or more sensor track 

data streams to WCS, where final filtering 

and multistream fusion are performed to 

guide the interceptor flight.

3. Active Seeker Technology: This technology 

uncouples the hard connection and 

dependence between the ship and the 

interceptor. The ship will retain control 

of the interceptor for the majority of the 

flight, but the ship’s radar and illuminator 

horizon is no longer a hard floor limiting 

the flight of the interceptor. Control 

and illumination from any source is not 

required for the final seconds before 

intercept as the missile goes active and 

independently finds the target. The entire 

battlespace from interceptor operating 

ceiling down to the land or sea surface and 

from ownship out to interceptor maximum 

kinematic range is now available to Fleet 

operators for engagement of all threats. 
Naval Integrated Fire Control – Counter Air

Capability-Based System-of-Systems Engineering

31

These are just a few major examples of 

the systems engineering accomplishments 

during NIFC-CA system development. These 

accomplishments support higher level DoD 

acquisition objectives for IFC by enabling a 

growing diversity of DoD airborne and surfacebased sensors to support OTH engagements. This 

uncoupling and opening of interfaces will lead 

to industrial innovation of both tracking sensor 

and active missile capabilities and to further 

improvement in overall military capability.

Conclusion

SoS systems engineering provides great 

opportunities to leverage national investments 

in defined-purpose military systems in order to 

achieve unique and powerful capabilities at the 

SoS level. It is apparent that most future military 

SoS acquisition and engineering programs 

will be of the acknowledged type. Based on 

this brief overview of NIFC-CA SOS SE, it is 

hopefully apparent that the acknowledged type 

of SoS SE environment is full of opportunities 

and challenges. It will require flexible, creative, 

and active program leadership, and systems 

engineering leadership that is mindful of 

the fundamentals of systems engineering 

while encouraging and guiding collaborative 

engineering teams toward SoS-unique objectives. 

Within that type of leadership framework, the 

collaborative community consisting of SoS 

systems engineers working with the diversity of 

the component systems’ engineering teams can 

produce innovative, extensible, and powerful 

solutions. 

References

1. Deputy Under Secretary of Defense for Acquisition and 

Technology (DUSD(A&T)), Systems and Software Engineering, 

Systems Engineering Guide for Systems of Systems, Version 1.0, 

Washington, D.C.: ODUSD(A&T)SSE, August 2008 ( www.acq.

osd.mil/se/docs/SE-Guide-for-SoS.pdf ).

2. USD(A&T) memo of 11 Jan 96; Subj: Land Attack Cruise Missile 

Defense (CMD).

3. ASN(RDA)/VCNO Memo of 11 Oct 2002; Subj: Updated 

Responsibilities for Management of Naval Integrated Fire 

Control – Counter Air (NIFC-CA).

4. Department of Defense (DoD), Defense Acquisition Guidebook, 

Chapter 4: “System of Systems Engineering,” Washington, DC: 

Pentagon, October 14, 2004.

31

Naval Integrated Fire Control – Counter Air

Capability-Based System-of-Systems Engineering
32

Mission-Level Systems Engineering

Combat Systems Engineering & Integration

Over the years, warfighter reliance on Tactical Data Links (TDLs) has increased 

exponentially. When initially implemented, the simple exchange of basic radar contact 

information via Link-11 in a sector air warfare environment was deemed a success. 

Today’s TDL employment encompasses all warfare areas and phases from detection and 

dissemination to engagement and kill assessment. TDL interoperability has been and 

remains a critical consideration necessary for warfighters to achieve mission success.

Joint guidance concerning interoperability states that “systems, units, and forces 

shall be able to provide and accept data, information, materiel, and services to and 

from other systems, units, and forces and shall effectively interoperate with other U.S. 

forces and coalition partners.”1

 Interoperability is best understood by considering the 

principal function of a shipboard Combat Information Center. Each unit, through the 

use of radars and other sensors, collects, processes, and displays tactical information 

for evaluation and action. Multiple units within a strike force follow the same process 

and exchange their tactical information using a number of TDLs. The TDLs provide 

decision-makers with a coherent and common tactical picture to use to conduct a 

particular operation. Accordingly, what warfighters see on local tactical displays needs to 

correctly represent the tactical environment and reflect essentially the same information 

displayed on every other unit participating on the TDLs. 

In the mid-1970s, Naval Surface Warfare Center, Dahlgren Division (NSWCDD) 

engineers began supporting development efforts that resulted in the introduction of the 

first Aegis cruiser, USS Ticonderoga (CG 47) into the Fleet. At that time, Link-11 was 

the primary means of tactical data exchange among carrier battle groups. Link-11, also 

known as TDL-A, is based on 1960s technology and is a relatively slow TDL. It normally 

operates on a polling sequence architecture where network participants transmit tactical 

data when called upon, as shown in Figure 1. 
On the Leading Edge of Interoperability

33

As mission needs evolved and technology 

advanced, the need for a more capable and robust 

TDL was identified. This led to the development 

of Link-16, also known as TDL-J, which provided 

the warfighter the technical and operational 

improvements needed to meet evolving mission 

needs. Link-16 is a secure, jam-resistant, lineof-sight TDL that allows network participants to 

exchange tactical data based on predetermined 

time slots, which results in a significant increase 

in the rate of data exchange over Link-11. A highlevel Link-16 architecture is depicted in Figure 2.

As operational missions continued to 

evolve, the requirement was identified for a 

communication system capable of tactical data 

exchange with other units Beyond Line-ofSight (BLoS). Multiple variations of satellite 

communication systems were developed to 

Figure 2. Link-16 High-Level Architecture

Figure 1. Link-11 High-Level Architecture
34

Mission-Level Systems Engineering

Combat Systems Engineering & Integration

satisfy these requirements. Satellite Link-11 

(S TDL-A) and Satellite Link-16 (S TDL-J) 

were the first satellite systems used for BLoS 

TDL communications. While they provided the 

capability to exchange tactical data with BLoS 

network participants, the number of participants 

and the speed at which data could be exchanged 

were limited because of the data rate constraint 

of the satellites used. As technology continued to 

advance, faster and more capable satellite systems 

were used for BLoS TDL communications. The 

Joint Range Extension Application Protocol 

(JREAPS) capability, which provides added 

security, improved speed, and an increased 

number of network participants over S TDL-A 

and S TDL-J, is the latest satellite TDL capability 

implemented by the Navy. A high-level BLoS TDL 

architecture is depicted in Figure 3.

Adhering to Military Standards

The TDLs mentioned earlier are governed by a 

series of Military Standard (MIL-STD) documents 

that identify implementation requirements that 

combat systems must meet to be interoperable 

with other combat systems. Interoperability is 

made possible by consistent implementation of 

MIL-STD requirements on applicable combat 

systems. Prior to fielding, each combat system 

must be certified to validate that it meets the 

applicable MIL-STD requirements.

The MIL-STDs are dynamic documents 

that are under continual review and changed as 

necessary to satisfy the operational community’s 

requirements. The change process for the 

NSWCDD Data Link engineering team begins 

with listening to the needs of the operational 

community and program offices supported. 

Figure 3. BLoS High-Level TDL Architecture
On the Leading Edge of Interoperability

35

Examples of this input include post-deployment 

reports, Fleet feedback, Fleet trouble reports, 

and the introduction of new capabilities by the 

respective program offices, such as the new 

Mode 5 Identification Friend or Foe capability. 

With an understanding of the requirements, 

NSWCDD engineers begin developing a 

proposed modification or addition to the various 

MIL-STDs, termed Interface Change Proposals 

(ICPs). An ICP can range from a few pages to a 

document several hundred pages in length as it 

details the proposed technical solution for the 

implementation of an operational requirement. 

Following development and subsequent 

internal reviews, the proposed ICP is provided 

to the Navy technical standards section of the 

Space and Naval Warfare Systems Command 

(SPAWAR) Systems Center (SSC) Pacific 

Code 59. This organization (formerly known 

as the Navy Center for Tactical Systems 

Interoperability) then distributes the ICP to 

various other program offices and activities 

for review and comment. The ICPs are then 

presented by the proposing agency at a regularly 

scheduled Technical Interoperability Standards 

Group (TISG) meeting. The TISG, chaired by an 

SSC Pacific Code 59 representative, has a voting 

membership made up of representatives from 

multiple Navy program offices and engineering 

activities. At the TISG, the technical merits of 

the ICP are discussed, and the ICP is either 

approved as written, modified to address the 

requirements and concerns of other users, or 

disapproved. Following Navy approval, ICPs then 

make their way to a review by the other services, 

and in some instances, to the North Atlantic 

Treaty Organization for review and approval. 

Interface Change Proposal 

Process

The ICP development process is not 

unique to the NSWCDD community and, 

as voting members of the TISG, NSWCDD 

representatives are responsible for reviewing 

and commenting on ideas brought forth 

by other Navy and joint service activities. 

This requires an understanding of how the 

other systems operate and how the proposed 

changes might impact the systems NSWCDD 

supports. The ICP process, from origination 

to incorporation into the applicable MILSTDs, can take years as nations, services, and 

individual technical communities provide 

insight and recommend changes on the way to 

the final technical solution.

Once ICPs are formally approved, the 

NSWCDD Data Link engineering team 

begins the process of determining how best to 

implement the ICPs into the applicable combat 

system programs such as Aegis, Aegis Ballistic 

Missile Defense, DDG 1000, Littoral Combat 

Ship, and the Common Aviation Command 

and Control System. NSWCDD engineers study 

the risks associated with cost, schedule, and 

performance, and provide recommendations 

to the respective program offices to determine 

which of the proposed changes will be scheduled 

for incorporation. The goal is to implement 

approved ICPs as quickly as possible on all 

applicable combat system programs; however, 

incorporation may be delayed due to available 

funding and delivery schedules. This applies to 

all program efforts across the services and, as a 

result, contributes to some of the interoperability 

issues our warfighters face today.

Once ICPs are approved for incorporation 

into a given combat system, NSWCDD 

engineers continue to coordinate with the 

program office and developers to ensure the 

required changes are incorporated. This process 

involves working with the design activity 

to develop and evaluate the combat system 

Specification Changes (SCs) that incorporate the 

ICP and detail the changes to the Command and 

Control System functions and displays. These 

SCs can be very complex as they typically affect 

multiple elements and/or functions within the 

combat system.

Once SCs are reviewed and approved, 

the developers code and deliver the updated 

combat system programs. During this process, 

depending on the combat system supported and 

the stage of development, NSWCDD engineers 

take the lead in testing and validating the 

ICP implementation or assist other agencies 

as required. This process can involve the 

development of test plans and procedures, test 

conduct, post-test data analysis, and reporting. 

Tactical Datalink 

Interoperability Certification

Throughout the combat system development 

effort, NSWCDD engineers work with the 

program office to determine the best approach 

for obtaining TDL/interoperability certification 

for the combat system. There are three phases 

in this process: Navy TDL/interoperability 

developmental testing, Navy TDL/

interoperability certification testing, and joint 

TDL/interoperability certification testing. 
36

Mission-Level Systems Engineering

Combat Systems Engineering & Integration

Navy Tactical Data Link Interoperability 

Developmental Testing

Typically, a developmental test is conducted 

for all new and updated combat systems. 

Developmental tests are conducted while the 

combat system is still in development but 

mature enough to support testing in which 

interoperability performance can be assessed. 

Developmental tests are also conducted early 

enough in the development process to allow time 

to effect change should problems be identified 

during testing. During a developmental test, 

NSWCDD engineers work with the Navy servicelevel test agent, the SSC Pacific Code 59 System 

Test, Integration, and Certification Branch. This 

testing usually takes three weeks and delves 

into all aspects of CS TDL/interoperability 

functionality using a certified link simulation 

system, the Multi-Link System Test and 

Training Tool (MLST3), to simulate remote TDL 

participants. NSWCDD engineers function as 

the combat system test agent and assist the SSC 

Pacific test director and staff during the event. 

Following the test, the SSC Pacific and NSWCDD 

test teams conduct independent assessments 

of the test results and discuss these finding in 

a Navy Analysis Review Panel (NARP). At the 

NARP, SSC Pacific and NSWCDD representatives 

discuss the issues identified during test and 

analysis, adjudicate the priorities, and provide 

mitigation for the concerns where appropriate. 

Following the adjudication process, those 

issues deemed to be critical or high-priority by 

both parties are captured in a “must fix” list. If 

not corrected, these issues could prevent the 

combat system from achieving its Navy TDL/

interoperability certification or accomplishing all 

mission requirements once deployed. Following 

the NARP, NSWCDD engineers work with the 

program office and design activity to ensure the 

necessary computer program corrections are 

implemented prior to proceeding to the Navy 

TDL/interoperability certification effort. Figure 4 

is a photo of NSWCDD engineers performing 

console operations during a test event. 

Navy Tactical Data Link Interoperability 

Certification Testing

Once all of the TDL/interoperability-related 

combat system upgrades or corrections have been 

delivered and validated, the official Navy TDL/

interoperability certification test is scheduled. This 

effort is similar to the developmental test in that 

the same test procedures, test bed, and simulators 

are used. Any high-priority issues discovered 

during this test could result in failure to obtain 

Navy TDL/interoperability certification. This 

certification is one of the key criteria taken into 

consideration by the Combat System Certification 

Panel for the combat system under test.

Figure 4. NSWCDD Engineers Performing TDL/Interoperability Certification Testing
On the Leading Edge of Interoperability

37

Joint Tactical Data Link Interoperability 

Certification

Once a combat system has been Navy TDL/

interoperability-certified, NSWCDD engineers 

work with SSC Pacific test agent personnel 

to prepare for the joint interoperability test 

conducted by the Joint Interoperability Test 

Command (JITC) located in Fort Huachuca, 

Arizona. Like the Navy TDL/interoperability 

certification event, the goal of the joint TDL/

interoperability certification event is to ensure the 

combat system meets MIL-STD and operational 

TDL requirements. The main difference between 

the two is that Navy certification is conducted 

with a link-certified simulator (MLST3) 

representing the remote TDL participants, and 

the joint certification event is conducted with 

multiple joint combat systems exchanging tactical 

data over simulated TDL networks. Testing in 

this manner allows the engineers to gain insight 

into how the combat systems interact with each 

other when exchanging data over the TDLs. At the 

completion of this test event, NSWCDD engineers 

analyze the issues provided by JITC and other test 

participants, discuss their findings, and mitigate 

identified issues at a Joint Analysis Review Panel. 

This board, composed of representatives from 

JITC and the other services, discusses the issues 

observed during the test and decides whether 

or not to approve or disapprove that particular 

system’s joint interoperability certification. 

Deploying Group Systems Integration Testing

In addition to the Navy and joint 

interoperability certification processes described 

above, NSWCDD engineers participate in atsea test events, such as deploying group systems 

integration testing, which is conducted by all 

carrier strike groups and expeditionary strike 

groups prior to deployment. These events 

provide an opportunity to assess combat system 

interoperability performance in a tactical 

environment, evaluate interoperability changes 

and upgrades, and receive Fleet feedback on 

combat system capabilities and performance, 

which is then fed back into the process to identify 

new Fleet requirements.

Meeting Interoperability Requirements

Meeting interoperability requirements is a 

challenging task. The demands for exchanging, 

processing, and displaying information over 

the TDLs are ever increasing. To meet the 

challenges of implementing current and future 

interoperability needs, NSWCDD engineers not 

only must be knowledgeable of their respective 

combat systems from an interoperability 

perspective, but also well-versed in the capabilities 

and limitations of other systems, the requirements 

of operators, and the systems engineering 

process from design through test and evaluation. 

Despite these challenges, NSWCDD engineers 

continually deliver capabilities on the leading edge 

of interoperability that are necessary for ensuring 

that naval warfighters have the tools they need to 

achieve mission success. 

Reference

1. CJCSI 3170.01G, Joint Capabilities Integration and Development 

System, 1 March 2009.
38

Combat Systems Engineering & Integration

Mission-Level Systems Engineering

Mission Analysis in the Combat Systems 

Engineering Process

by Stephanie Hornbaker and Sean Chapin

Mission analysis is performed at multiple stages of the combat systems engineering 

process and is a technique used to estimate mission effectiveness under different 

operational concepts. In other words, mission analysis is the evaluation of multiple 

approaches to achieving a given mission, or goal, and the selection of one that 

provides the best performance.1

 Mission analysis is employed early in system design to 

identify capability gaps and evaluate approaches to close those gaps. It is also used for 

evaluating the impact on performance of new technologies and operational tactics. The 

performance analysis then drives the creation of requirements and the development, 

design, and deployment of a system. 

Beginning with a well-defined mission or need is critical. Analysts must first 

determine if the sponsor is looking for an answer to an acquisition, tactical, or 

technological question. The type of question will drive the design of an appropriate 

mission analysis study. Analysts initially might only be provided with high-level 

requirements for a system and may need to work with the customer to flesh out the 

specific threats and scenarios necessary to perform an appropriate analysis. For example, 

a customer may want to know how to configure multiple defense systems on a ship 

to achieve the best self-defense performance. Analysts would need specification on 

the types of systems, the measures of effectiveness most important to the customer 

in defining self-defense performance, and the types of threats to test against the ship. 

If the goal is not correctly defined in the beginning of the mission analysis process, 

the ultimate solution will not solve the customer’s problem. Once the mission has 

been accurately defined, the analyst must identify a set of architectures, approaches, 

and subsystems that represent the trade space. Mathematics, analysis, and simulation 

techniques are used to provide a quantitative justification for building or employing a 

combat system in a specific way. This article discusses the Naval Surface Warfare Center, 

Dahlgren Division’s (NSWCDD’s) established mission analysis process and tools. 
39

Mission Analysis in the Combat Systems 

Engineering Process

Mission Analysis Process

The mission analysis process begins with 

an acquisitional, technological, or operational 

question from the sponsor. The problem could 

involve a single ship or battle groups of ships 

performing multiple missions, such as anti-air 

warfare (AAW), ballistic missile defense (BMD), 

integrated air and missile defense (IAMD), or 

surface warfare (SUW). Typically the problem 

centers on making a decision among several 

combat system configurations or deciding if 

the addition of a new combat system element 

improves the ability of the overall combat system 

to perform its mission. Each configuration is 

defined by a control system, a sensor suite, and 

a weapon suite. For example, one configuration 

could consist of the Ship Self-Defense System 

(SSDS) control system with the Rolling Airframe 

Missile (RAM) and the SPQ-9B radar. A second 

configuration could share the same control system 

and sensor, but with an Evolved Sea Sparrow 

Missile (ESSM) instead. Thus, this mission 

analysis process would provide insights into the 

relative performance differences between the 

two configurations. A schematic of the mission 

analysis process is shown in Figure 1.

Once the problem definition is complete 

and understood by all analysts involved, tactical 

situations are designed that can be simulated 

in weapon, sensor, and control system models. 

The threat, sensor, and weapon models can be 

run independently of one another and their 

performance data fed into a control system model. 

Alternatively, the models can be integrated into a 

single end-to-end simulation of the engagements. 

The modeling process often involves simulating 

a raid of threats, such as cruise missiles or 

ballistic missiles attacking a U.S. Navy ship or 

a battle group. The threats are defined by the 

trajectories they fly, radar cross sections, and 

seeker characteristics. The threat characterization 

is passed to the sensor and weapon models to 

evaluate the performance against the threats. The 

sensor models produce measures of performance, 

such as probability of maintaining a track as a 

function of range for each threat trajectory, or 

detailed histories of when the threat is in track 

and when it is not. Networked sensors, such as 

those in a battle group, can be modeled to produce 

a common track picture available to multiple 

ships when running a battle group simulation. 

The weapon models produce lethality data for 

Figure 1. Schematic of the Mission Analysis Process
40

Combat Systems Engineering & Integration

Mission-Level Systems Engineering

the threat showing the single-shot probability of 

killing the threat as a function of range for any 

shooting ship against any threat in the scenario. 

The data from the sensor and weapon models are 

then fed into a control system simulation that 

models the sequence of events from detection of 

the threat by various sensors to its engagement 

by different weapons. The simulation includes 

scheduling algorithms for ship assets involved 

in the engagements. This includes launcher and 

illuminator scheduling and coordination of 

multiple shooting ships in a battle group. The 

battle simulation can be repeated hundreds 

of times generating a number of outcomes 

during which key events and statistics can be 

recorded. Sample outputs from a mission analysis 

simulation for three combat system configurations 

are shown in Figure 2.

In the mission analysis context, a measure 

of effectiveness (MOE) is designed to estimate 

how combat system performance changes across 

the configurations considered in the analysis. 

The MOEs are based on the statistics collected 

from the control system simulation and are used 

to underpin the analysis. Examples of MOEs 

include the probability of defeating the entire raid 

of threats, probability of defeating a particular 

threat, percentage of threats defeated, and weapon 

expenditures.

The final and most important step is to 

analyze the data and develop an understanding 

of overall system performance and interactions. 

Control system simulations can reveal important 

interactions between elements of the combat 

system by generating many possible outcomes 

of a battle depending on sensor threat detection 

timeliness, weapon performance, and the resulting 

effects on scheduling engagements. These 

interactions are not always obvious upon cursory 

examination and are used to inform acquisition 

decisions. For example, at first glance a new 

sensor that extends the range at which firm track 

is obtained on a threat might appear to be a simple 

way to improve a ship’s self-defense performance. 

However, if weapon performance is poor at the 

extended firm track ranges provided by the new 

sensor, overall system performance may not be 

improved. This would represent a situation where 

the additional cost of a new sensor might not 

be justified unless it provides other benefits to 

performing the mission deemed too important 

to ignore. Mission analyses designed to explore 

the trade space are essential for providing these 

insights to decision-makers. 

Another example of insight that mission 

analysis can provide is showing the impact of 

radio frequency propagation conditions on a 

radar’s ability to maintain firm track on a threat. 

Figure 2. Sample Mission Analysis Simulation Outputs
41

Mission Analysis in the Combat Systems 

Engineering Process

Meteorological conditions impact the paths 

of the electromagnetic waves emitted from 

the radar resulting in regions where the radar 

cannot see a threat. It is possible for the radar to 

track a threat for a period of time, lose track on 

the threat, and regain track on the threat again 

at a later time. This phenomenon can impact 

weapon effectiveness and the ability of the control 

system to schedule an engagement of the threat. 

Mission analysis enables exploration of a range 

of environmental conditions and impacts on 

overall combat system performance. While such 

variables cannot be controlled under operational 

conditions, analysts can systematically estimate 

their impacts and pass that information to 

decision-makers and the Fleet.

Once the mission analysis process is 

completed, a package of information is delivered 

to sponsors detailing how system performance 

varied over the trade space. The analytical 

approach, assumptions, conclusions, and driving 

factors must be clearly and concisely explained, 

suitable for a wide audience. That information is 

then fed back into the overarching alternatives 

analysis process, which also considers cost and 

risk analysis. The result is an analytically rigorous 

decision on a combat system configuration or 

operational approach that meets the warfighter’s 

requirements. System design and specification 

or updates to tactics or technologies can then 

commence. 

Conclusion

NSWCDD has a long history of performing 

mission effectiveness studies and alternatives 

analysis studies for the Chief of Naval Operations, 

for the operational Navy, for the Program 

Executive Office for Integrated Warfare Systems 

(PEO-IWS), and for other sponsors including 

foreign navies. Subject matter experts in sensors, 

weapons, threats, electronic warfare, and control 

systems across NSWCDD partner with mission 

analysts to produce authoritative assessments 

of combat system performance. As pressure on 

the Navy to produce combat systems that both 

perform their missions and are affordable persists, 

mission analysis plays a vital role in the combat 

systems engineering process. 

Reference

1. Buede, Dennis M., The Engineering Design of Systems: Models 

and Methods (New York, NY: John Wiley & Sons, Inc., 2000), 

pp.  39-141.

41

Mission Analysis in the Combat Systems 

Engineering Process
Mission-Level Systems Engineering

42

Combat Systems Engineering & Integration

A Systems Engineering Approach to 

Requirements Commonality Across 

Surface Ship Combat Systems 

by Diana Kolodgie, Karen Shuttleworth, and Greg Albertson

Today, the surface Navy designs and implements combat systems that are typically 

targeted for a particular class of ship (e.g., CG, DDG, LCS, CVN, and LPD) without 

adequately considering the larger family of systems implications. Requirements 

development and design approaches vary across ship classes and platforms and are, 

in effect, conducted independently. Commonality in cross-platform requirements 

analysis and development has the potential to increase the use of common 

components across designs of combat systems and to facilitate commonality in test 

and certification. Commonality among combat systems may reduce the complexity 

of family-of-systems design and of integrating platforms and their combat systems 

into highly effective and efficient operational task forces. This has great potential to 

achieve significant savings by reducing the cost of designing, developing, producing, 

training, maintaining, and updating capabilities, while increasing the ability to quickly 

incorporate new or updated capabilities into the Fleet.

Currently, there is no formal process to analyze, allocate, and coordinate 

requirements development between and within ship classes. As a result, platform 

requirements are developed independently of one another. This is further 

compounded by individual ship programs and systems having similar yet uniquely 

tailored requirements development. This has led to system-level requirements being 

decomposed from specific operational requirements in isolation and creating a stovepiped development approach. Having limited to no cross-platform development 

communication often causes the same operational need and functionality to be defined 

differently in system-level requirements and architecture. This approach inhibits 

commonality as requirements are decomposed down the requirements hierarchy. Thus, 

there is the potential to miss opportunities for common requirements and the total 

ownership cost benefits associated with commonality.

42

Combat Systems Engineering & Integration

Mission-Level Systems Engineering
A Systems Engineering Approach to Requirements 

Commonality Across Surface Ship Combat Systems

43

A solution to the lack in commonality is the 

engineering of combat systems as a common 

product line. Applying a systems engineering 

approach across platforms will allow for the 

identification of combat system components that 

can and should be common while preserving 

the option of platform-unique solutions where 

appropriate. This paper focuses on the integral 

role common requirements play as part of the 

systems engineering process as applied to surface 

Navy combat systems. A common approach 

to requirements development is provided as 

well as how common requirements contribute 

throughout the systems engineering process to the 

development of a common product line.

Application of Systems 

Engineering 

A combat system product line develops 

commonality, utilizing a common set of reusable 

requirements across the family of surface Navy 

combat systems. What makes these product lines 

part of a family are some common elements of 

functionality. Functional and nonfunctional 

requirements capture the intended behavior and 

constraints of the system. This behavior may 

be expressed as services, tasks, or functions the 

system is required to perform (functional) and 

the constraints describe how well a function 

is to perform (nonfunctional) and are largely 

consistent across the family. Adding platformunique constraints on the system’s behavior in the 

form of nonfunctional requirements produces the 

aggregate set of requirements for the system. This 

approach establishes a consistent and common 

decomposition of the operational requirements 

across multiple ship classes while preserving 

a platform’s unique requirements. Future and 

upgraded platforms will leverage a common set 

of product line requirements to which platformunique requirements can be applied to compile a 

complete set of combat system-level requirements. 

To establish a set of product line requirements, 

all existing legacy platform requirements will 

be analyzed and further normalized to produce 

a superset of common requirements. Product 

line requirements will be applicable to future 

platforms and platform upgrades throughout lifecycle development by using a central repository 

for all surface Navy combat system requirements.

A Systems Engineering Approach to Requirements 

Commonality across Surface Ship Combat Systems

43
Mission-Level Systems Engineering

44

Combat Systems Engineering & Integration

Establishment of Common 

Product Line Requirements

There are three main aspects to the overall 

product line requirements development 

process. The first focus is to establish the initial 

set of common product line requirements 

that will set the framework for all future 

requirements development. From that common 

set of requirements, future platforms can 

incorporate platform-unique requirements 

to develop a Combat System Requirements 

Document (CSRD). The final aspect is full lifecycle management of the product line. Future 

requirements will be reviewed and evaluated 

for incorporation into the common set. These 

future requirements will factor in platform 

and warfighter capabilities that evolve and are 

identified as a result of the campaign level of 

analyses conducted by the Office of the Chief of 

Naval Operations.

Establishment of Initial Common Product Line 

Requirements

The process described herein proposes the 

development of the initial common set of combat 

system-level requirements. Figure 1 provides a 

graphical representation of the following steps to 

develop the initial common set of requirements:

1. Establish requirements database

2. Compile source references

3. Review and sort requirements

4. Determine common versus platformunique requirements

5. Perform normalization

This development process is designed 

to establish the initial set of product line 

requirements based upon legacy combat system 

requirements. Incorporation of future platformunique requirements and life-cycle management 

of the product line are defined in separate 

processes later in the text. 

The proposed requirements development 

process is implemented using a requirements 

database. This will allow for a defined structure 

and for attribute definitions. Using an integrated 

database will enable systems engineering and 

facilitate data collection as well as provide a 

collaborative environment to review and modify 

requirements in one central location.

Step 1. Establish Requirements Database

An integrated requirements database is 

established to facilitate a systems engineering 

process throughout requirements development. 

A database will support the development of 

the product line requirements and maintain 

Figure 1. Product Line Requirements Development Process
A Systems Engineering Approach to Requirements 

Commonality Across Surface Ship Combat Systems

45

all combat system-level requirements for the 

development life cycle. An integrated database 

will allow for traceability among higher 

level requirements as well as to the defined 

product line architecture and platform-unique 

architectures. 

Along with capturing the requirements text, it 

is critical to define multiple attributes to provide 

a clear understanding of each requirement. In a 

specialist task, such as defining a product line that 

requires multiple sorts and unique information to 

be captured, each requirement can be tagged with 

an unlimited number of attributes allowing for 

easy selection of subsets of requirements.1

Table 1 provides examples of attributes that 

will be defined and utilized during the initial 

product line requirements development process. 

Additional attributes may be added throughout 

development as appropriate.

Step 2. Compile Source References

The next step in producing the initial combat 

system product line requirements is to compile 

a list of combat system requirements currently 

developed for legacy platforms. This list of 

requirements will be developed from available 

source combat system references, such as Aegis 

A-Specs, DDG 1000 Segment Specifications, 

and Precommissioning Unit (PCU) Gerald R. 

Ford (CVN 78) Performance and Capability 

Requirements. Additionally, applicable statutory 

and regulatory instructions will be compiled, 

such as information assurance, safety, and Naval 

Sea Systems Command (NAVSEA) guidance 

and policy on combat system and combat system 

element training safety precepts and design 

requirements. While these instructions may not 

contain the true “shall” requirements language, 

they do contain the governance and oversight 

that ensure stakeholder requirements are met 

and provide rationale for nonfunctional “ility” 

requirements. All current combat system-level 

requirements are compiled without modification 

into the established database.

Step 3. Review and Sort Requirements

The next step in the development process is to 

review and assign all compiled requirements with 

initial attributes. The assignment will allow for 

the sorting of requirements into local groupings, 

which provides a mechanism for a manageable 

review and facilitates the normalization process, 

based upon the functional and nonfunctional 

requirements common across all combat systems 

as derived from operational, statutory, and 

regulatory requirements. Proposed groupings 

include domain, mission area, and nonfunctional. 

The domains, as defined in the PEO IWS 

Surface Navy Combat Systems Software Product 

Line Architecture, Architecture Description 

Document (ADD) (2009),2

 provide a means to 

functionally group the requirements. The domains 

are not meant to be a physical representation of 

the deployed system (PEO IWS 2009). Domain 

mapping will provide an avenue for functional 

analysis and allocation. There are multiple 

Table 1. Initial Database Attributes
Mission-Level Systems Engineering

46

Combat Systems Engineering & Integration

mission areas across the numerous platforms. 

Each platform’s specific mission areas and 

nonfunctional groupings (potential inherent 

capabilities) are defined in its operational 

requirements document. Table 2 provides 

examples of potential domain, mission area, and 

nonfunctional mappings.

All requirements are first sorted by domain 

with the mission area and nonfunctional 

attributes providing amplifying information to 

assist in requirements analysis and normalization. 

Mission area attribute mappings will also assist 

in allocating the level of work to warfare area 

subject-matter experts (SMEs). The SMEs 

are consulted during this step to review and 

assess the requirements to ensure attributes 

were identified correctly. Their assessment 

and participation continues throughout the 

normalization process.

Step 4. Determine Common versus PlatformUnique Requirements

Once requirements are sorted into 

manageable groupings, they are further 

analyzed for commonality. This step allows for 

further analysis of the requirements to ensure 

normalization is performed correctly. SMEs will 

review current requirements within domain 

groupings and amplified with mission area and 

nonfunctional attributes for like requirements. 

All like requirements, those having the same 

or similar meaning, are identified as common. 

Those requirements that are standalone (i.e., do 

not have any other requirement with the same 

or similar meaning) are identified as “platformunique.” Platform-unique requirements are 

identified as such with the product line attribute 

(i.e., “no”) and not normalized. The requirements 

identified as common, with the product line 

attribute identified as “yes,” are then normalized 

into product line requirements.

Step 5. Perform Normalization

Once all current combat system-level 

requirements have been identified as like or 

platform-unique, the compiled list of like 

(potential product line) requirements can be 

normalized to produce the initial product line 

requirements. 

The goal of the final step, normalization, is to 

standardize all common requirements. This step 

is necessary because of the differences among 

current requirements writing approaches taken 

across platforms. All common requirements 

will be reviewed and rewritten to be consistent, 

with respect to style and requirements writing 

standards. 

It is critical in the normalization process 

that requirements are thoroughly reviewed 

to ensure sound requirements are produced 

without losing the original intent. There are many 

different requirements aspects to review to ensure 

consistency and quality requirements writing. 

In addition to the provided requirements 

characteristics, it is vital that quality requirements 

writing be utilized when creating the superset of 

common requirements. There are many guides 

to writing quality requirements. In summary, 

Buede (2000)3

 provides some guidance for quality 

requirements writing.

Table 2. Initial Attributes for Sorting
A Systems Engineering Approach to Requirements 

Commonality Across Surface Ship Combat Systems

47

1. A statement of requirement includes the 

use of the word “shall.” 

2. A requirement statement should only 

include one “shall.”

3. Requirements statements shall include a 

subject (the relevant life-cycle system), 

the word “shall,” a relation statement (e.g., 

less than or equal to), and the minimum 

acceptable threshold with units.

4. Use appropriate grammar.

5. Avoid compound predicates and negative 

predicates.

6. “And/or” colloquialism is inappropriate. 

7. Requirements statements should not start 

with “If...” statements.

8. Requirements statements should be 

unambiguous.

9. Common verbs that are not specific should 

be avoided (e.g., maximize, minimize, and 

optimize).

10. Adjectives and adverbs are a major source 

of ambiguity.

Like requirements are reviewed and rewritten, 

using quality requirements writing, into common 

requirements. These common requirements 

become the product line requirements used for 

future platform requirements development and 

legacy upgrades. 

Following the normalization process, we are 

able to see that object IDs 1 and 3, as currently 

worded for their platforms, contain the same 

functional requirements and can be reviewed 

and rewritten into common product line 

requirements. Table 3 provides the original object 

text along with an example of new, normalized 

object text. The normalized object text is the new 

requirements language developed from the two 

original platform requirements and rewritten into 

a standardized requirements language, based on 

applying the guidance described above. The new 

text is then included in the superset of common 

product line requirements to be utilized by all 

future platforms.

Establishment of Future Platform CSRDs

Once the initial common set of combat 

system-level requirements (product line 

requirements) have been developed, systemlevel documents can be quickly and commonly 

produced. Future combat system requirements 

document development will leverage the existing 

applicable common product line requirements. 

The proposed process of common product line 

requirements establishes a requirements database 

that facilitates the development of CSRDs. A 

future platform can simply sort the product 

Table 3. Examples of Normalized Requirements
Mission-Level Systems Engineering

48

Combat Systems Engineering & Integration

line requirements based on their stakeholderdefined mission areas to obtain an initial set of 

requirements. The product line requirements 

will then be augmented with a platform’s unique 

requirements deemed necessary to achieve its 

aggregate combat system requirements.

Significant savings and commonality 

across platform combat systems development, 

integration, testing, and deployment can be 

realized by utilizing product line requirements 

to establish the majority of its requirements base 

needed to fulfill the platform’s missions. 

Life-Cycle Management of Product Line 

Requirements 

The final aspect to implementing a full combat 

system product line is the ability for life-cycle 

management of all system-level requirements 

and documents. Once the initial set of common 

requirements has been developed, the next step 

is to document a process to integrate potential 

new additions to the common set of requirements 

as well as expand the current database into a 

fully integrated surface Navy combat system 

requirements database. 

As new operational requirements are defined 

by stakeholders, new system-level requirements 

are derived and will need to be evaluated as 

potential additions to the common product 

line superset. If new requirements are deemed 

common, they will then impact the scope of 

legacy upgrades as well as all future platforms. 

A fully integrated surface Navy combat 

system database will incorporate not only the 

common product line requirements but all 

future platform-unique requirements (clearly 

identified as such with attributes) and traceability 

links back to platform-specific operational 

requirements. This fully integrated database will 

create one central repository for all system-level 

requirements development. This central database 

will encompass all system-level requirements, 

documents, and architecture, providing a clear 

mechanism for consistency and commonality.

At this point in the process, configuration 

management would need to be addressed and 

initiated to ensure quality control of defined 

configuration items. Product line control boards 

would be established to approve all new additions 

to the common set of requirements.

Establishment of Common Product Line 

Architecture

Similar to the establishment of a common 

requirements repository, the development of a 

common functional architecture would assist in 

alleviating the problem of the loss in commonality 

in the translation of operational capabilities 

into the requirements and design of the combat 

systems. A common functional architecture 

can be developed through functional analysis 

and allocation of requirements. The functional 

architecture serves as the bridge between the 

common product line requirements and the 

common product line components. Those 

requirements that are allocated to components 

outside of the common core set are platformunique. 

As new operational requirements are 

developed for future ship platforms, requirements 

and functional analyses will be performed to 

determine the common components that satisfy 

the new requirements. The platform will use 

the applicable functionality and allocations 

from the common functional architecture as 

determined from the analysis performed. The 

final architecture for each future platform will 

be a combination of common components and 

platform-unique components as depicted in 

Figure 2. The common requirements database 

would then be updated with the traceability to the 

applicable functions and components.
A Systems Engineering Approach to Requirements 

Commonality Across Surface Ship Combat Systems

49

Conclusion

The common product line requirements 

development process focuses on the development 

of a superset of combat system requirements 

across all surface Navy platforms. The fivestep process described above should alleviate 

the problem of the loss in commonality in the 

translation of operational capabilities into the 

requirements for and design of the combat 

systems. Combined with architecture, a common 

product line requirements development process 

is critical for determining where common 

components may be used in the combat systems 

across surface Navy platforms. This proposed 

systems engineering approach will support the 

awareness of and coordination in allocating 

and decomposing requirements from capability 

development documents to ship classes and 

contribute to the development of the system 

design specification. If done properly, this 

approach will facilitate test, verification, and 

certification of combat systems, as well as achieve 

cost saving across surface Navy combat systems 

development and training. 

Bibliography

Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 3170.01G, 

Joint Capabilities Integration and Development System, 1 March 2009.

Defense Acquisition University (DAU), Systems Engineering 

Handbook, 2001.

Department of Defense (DoD) Instruction 5000.2, Operation of the 

Defense Acquisition System, 8 December 2008.

Office of the Deputy Under Secretary of Defense for Acquisition and 

Technology, Systems, and Software Engineering, Systems Engineering 

Guide for Systems of Systems, Version 1.0, August 2008.

Secretary of the Navy Notice (SECNAVNOTE) 5000, Department of 

the Navy Urgent Needs Process, 12 March 2000. 

References

1. Office of the Assistant Secretary of the Navy (Research, 

Development and Acquisition) Chief Systems Engineer, Naval 

“Systems of Systems” Systems Engineering Guidebook, Volume I, 

Version 2.0, 6 November 2006.

2. Program Executive Office Integrated Warfare Systems (PEO 

IWS), Surface Navy Combat Systems Software Product Line 

Architecture, Architecture Description Document (ADD), Version 

1.0, 31 July 2009.

3. Buede, D.M., The Engineering Design of Systems, New York: John 

Wiley & Sons, Inc., 2000.

Figure 2. Combat System Systems Engineering Process
Mission-Level Systems Engineering

50

Combat Systems Engineering & Integration

Systems Engineering Planning

by Joel Washington and Gilbert Goddin

The surface Navy adopted an Advanced Capability Build (ACB), technology 

insertion (TI), combat system modernization approach that implements future 

warfighting requirements across platforms. As the Navy transitions away from building 

large end-to-end, platform-unique systems toward cross-platform capabilities, the 

role of systems engineering (SE) planning has become critical to ensuring systems 

engineers properly implement newly developed or modified components and 

capabilities. At the top level, it is important for the government, acting as its own 

system of systems (SoS) integrator, to fully understand the details of the enterprisewide SoS architecture and the strategic development planning that accommodates 

the changes expected over a long SoS evolution. This article addresses the role of SE 

planning and the processes that enable Program Executive Office (PEO) Integrated 

Warfare Systems (IWS) to execute the ACB/TI combat system modernization approach 

and the impact of changes to system requirements, budgets, and schedules on the 

overall SoS.
Systems Engineering Planning

51

Systems Engineering (SE) 

Planning

Integrated warfare and combat systems are 

being designed with increasing complexity and 

with varying interoperability requirements. As 

a result, these complex systems must operate as 

an SoS. Consequently, they must be designed 

as an SoS. A strong SE approach is required to 

translate operational requirements to a complete 

set of system requirements. The key to success 

is flexibility in both TI and business processes 

to enable the selection, program execution, 

and delivery of the required capabilities to the 

warfighter. 

SE planning is one of the four pillars of systems 

engineering. The other three pillars include 

system integration, system architecture, and 

requirements engineering. Naval Surface Warfare 

Center, Dahlgren Division (NSWCDD), engineers 

have been involved with generating SE plans for 

numerous programs. The development of SE 

plans requires a strong understanding of program 

requirements, knowledge of systems engineering, 

and the ability to tailor generic systems engineering 

principles to a specific program. Examples of SE 

plans that have been developed by engineers at 

NSWCDD for programs include:

•	 Systems Engineering Management Plan 

for Area Air Defense Commander Support 

System

•	 Warfare Systems Management Plan, SEMP 

for the CVN-77 Integrated Warfare System

•	 SEP, Aegis Advanced Capability Build 2012 

(ACB 12)

•	 ACB/Technology Insertion (TI) Planning 

Process Users’ Guide

•	 Systems Engineering Concept of Operations 

(SE CONOPS)

Systems Engineering Plan (SEP)

The SEP is the key guidance document for 

all technical aspects of a program. Department of 

Defense (DoD) Instruction 5000.02, Operation 

of the Defense Acquisition System, states that 

all acquisition program managers shall develop 

an SEP for each milestone. It further states, 

“The SEP shall describe the program’s overall 

technical approach, including key technical risks, 

processes, resources, metrics, and applicable 

performance incentives. It shall also detail the 

timing, conduct, and success criteria of technical 

reviews.”

DoDI 5000.02 is used in conjunction 

with other acquisition guidance necessary for 

the preparation of a SEP. Figure 1 shows the 

relationship between acquisition guidance and 

systems engineering policy.

The SEP is drafted once initial operational 

requirements for the ACB are established. The 

SEP is used to guide all technical activities 

Figure 1. Relationship among SE Guidance Documents
Mission-Level Systems Engineering

52

Combat Systems Engineering & Integration

needed for ACB completion. Thus, the SEP is 

the principal guiding document for all technical 

aspects of the program. The SEP documents the 

high-level technical plan, not the details of each 

process. The SEP describes the organization of 

the program’s Integrated Product Teams (IPTs), 

including all appropriate technical, certification, 

and programmatic authority functions.

Systems Engineering Management 

Process

SE planning is a part of the overall SE 

technical management process. It is an iterative 

effort that continues throughout the program 

until disposal (and sometimes beyond, if the 

program is restarted). An essential part of SE 

planning is the determination of the level of 

technical control the government will exert. Each 

PEO assigns a lead or chief systems engineer to 

monitor SE implementation within each program. 

NSWCDD engineers have supported PEO IWS 

by documenting the cross-platform systems 

engineering efforts in the SE CONOPS.

The scope of the technical effort required to 

develop the ACB is addressed in the SEP. As a 

minimum, planning identifies which SE tasks must 

be scheduled, how they will be accomplished, how 

the overall effort will be scheduled, what resources 

are needed, how the SE effort will be monitored 

and controlled, and how the technical effort will 

be folded into program planning, including the 

requisite contractual documents. SE management 

planners must address:

•	 Program requirements

•	 Technical planning and control

◆ Scheduling

◆ Organization structure

◆ IPTs

•	 Technical maturation

•	 Technical reviews

•	 Test, evaluation, and certification

Program Requirements

The SE plan should provide a top-level mission 

description that summarizes user requirements. 

Identification and refinement of ACB system 

requirements for each platform’s combat system 

occurs in parallel with the Office of the Chief 

of Naval Operations (OPNAV) operational 

requirements definition. Operational requirements 

for naval surface combatants are drafted and 

controlled by the OPNAV Surface Warfare 

Division (OPNAV N86). OPNAV releases an ACB 

Development Guidance Letter approximately 18 

months prior to the System Requirements Review 

that stipulates the new capabilities expected to be 

developed, aligned with, and integrated within 

the combat system. In response, PEO IWS gathers 

program alignment data (cost, schedule, and 

technical risk impacts), refines the statements of 

work and cost estimates from the Program Office 

Memorandum planning phase, conducts analysis 

and/or leverages existing studies specific to the 

requested new capabilities as needed, and assesses 

the new capabilities against mission-level gaps 

to generate an ACB evaluation, alignment, and 

assessment letter (ACB Execution Letter), which 

details the work that can be accomplished within 

the available funding and schedule.

Technical Planning and Control

Technical planning and control refers to those 

elements that are used to plan the technical efforts, 

the organizational structure used to execute and 

manage the project, and the definition metrics 

used to measure progress and to control the 

technical baseline of the project. The aspects of 

technical planning and control include scheduling, 

organizational structure, and integrated product 

teams. 

Scheduling

Scheduling is one of the most important SE 

planning tools. The schedule serves as the toplevel process control document. The schedule 

identifies the key events and milestones to be 

accomplished and identifies the critical path for 

the program. The ACB development schedule 

depicts development of a two-year delivery cycle 

and a five-year development, integration, test, 

and certification timeline. From a cross-platform 

perspective, a schedule must be maintained of all 

programs feeding products into the ACB, along 

with any objective architecture initiatives that will 

be implemented in the ACB. Figure 2 illustrates 

how all of these schedules must be linked and 

managed to ensure that all required products will 

arrive when needed. For Aegis ACB 14, NSWCDD 

initiated coordination with the applicable Program 

Acquisition Resource Managers (PARMs) to obtain 

and begin management of these various program 

schedules.

Organizational Structure

The SEP identifies the organizational structure 

and position roles and responsibilities. It identifies 

the functional leads, the program management 

chain of command, and the lead subject-matter 

experts. From a cross-platform perspective, the 

organization is matrixed, and the participants 
Systems Engineering Planning

53

are from several other organizations. NSWCDD 

engineers performed an SE process definition 

analysis using a Unified Modeling Language 

activity diagram format. This analysis resulted in 

identifying required organizational entities, the 

functions that these entities must perform, and 

the interactions and products that must be worked 

between entities. This information has been 

captured in the ACB/TI Users’ Guide and in the 

SE CONOPS. Figure 3 depicts a high-level view 

of the SE functional roles that resulted from the 

NSWCDD analysis.

The PARMs and element developers work 

collaboratively with the domain managers and 

component developers to develop the product 

based on defined requirements. 

Figure 2. ACB Systems Engineering and Development Notional Timeline

Figure 3. PEO IWS Systems Engineering Functional Roles
Mission-Level Systems Engineering

54

Combat Systems Engineering & Integration

Domain leads:

•	 Identify and upgrade domain candidates

•	 Coordinate activities with the Platform 

System Engineering Agent (PSEA)

•	 Maintain domain and component-level 

requirements and architecture

Component developers:

•	 Develop and update component 

specifications

•	 Develop new components

•	 Deliver the components to the domain 

manager

•	 Test and integrate the component into the 

combat system

Combat system integration manager:

•	 Manages execution and upgrade of surface 

ship combat systems

•	 Maintains list of platform integration issues

•	 Resolves with PARMs and ship design 

manager platform integration issues

•	 Maintains long-range upgrade plans for 

platform

•	 Maintains hardware and equipment 

upgrade plans for platform

NSWCDD, as a member of the Naval Sea 

Systems Command Warfare Center Enterprise, 

performs the following activities in support of SE 

planning:

•	 ACB planning

•	 Test planning and conduct

•	 Combat system modernization and 

upgrades

•	 Combat system certification

•	 Systems engineering

•	 Performance verification assessments to 

ensure upgrades operate safely, perform 

ships’ missions, and provide stability

•	 Establishment, maintenance, and control 

of software and equipment for certified 

configurations

The PSEA is responsible for integrating 

government-furnished capability upgrades and 

other products into each ship class combat system. 

Integrated Product Teams (IPTs)

Described in the SE plan is the manner in 

which the program will organize IPTs to achieve 

program execution. Different members of a crossfunctional team may have primary, secondary, 

or minor support roles during different phases of 

ACB development. The goal of the IPT is to get 

all disciplines involved at the beginning of the 

development process to ensure that requirements 

are completely stated and understood for the full 

life cycle of the ACB.

Technical Maturation

Outlined in the SEP is the approach for 

managing the overall technical products and 

how the program will assess and evaluate new 

technology. Metrics used for the assessment 

should be closely tied to cost and schedule. In 

order to plan appropriately, one of the first 

steps in the ACB development process is to 

identify and assess new technologies under 

development by the Navy, other DoD agencies, 

and industry to determine their tactical 

importance, maturity, expected performance, 

and computational resource requirement. There 

are many techniques that can be used to support 

sound decision analyses and evaluations of 

potential new technologies. Alternative concepts 

should be evaluated in terms of established 

measures of effectiveness, and the technologies 

considered should include the interoperability 

of all components necessary to achieve the 

capabilities. One of the key outputs of the 

Analysis of Alternatives (AoA) is an evaluation 

of technology maturity, as this will be used 

to define the technology development and 

demonstration phase, which follows the AoA and 

must be completed prior to formal acquisition 

program start. 

The Technical Authority (TA) role and 

responsibility should also be described in the 

SE plan. The TA provides an independent 

assessment of engineering processes, products, 

and risks associated with the ACB. The PEO 

IWS Technical Director oversees the TA process. 

TA participants include Technical Warrant 

Holders (TWHs) and TWH technical team 

members associated with specific aspects of the 

project. They are responsible for supporting 

the PM and the program’s systems engineer. 

The TA pyramid is depicted in Figure 4. The 

TWH guides the systems engineer in all 

standards implementations and ensures usability, 

supportability, and interoperability of the final 

products. TA participants serve as members of 

the technical review board.

Technical Reviews

The procedure for the program to conduct 

technical reviews and how the reviews will be 

chaired and supported by the technical team, 

including program-level office representatives, is 

described in the SEP. The PEO IWS SE process 

includes technical program reviews as identified 

by the technical review manual and as Figure 5 

illustrates. Technical program reviews are 

designed to reach decisions regarding technical 
Systems Engineering Planning

55

Figure 4. Technical Authority Pyramid

Figure 5. SE Technical Reviews
Mission-Level Systems Engineering

56

Combat Systems Engineering & Integration

design approaches, assess technical risk, and 

measure the maturity of the program or project 

during the development and maintenance phases. 

PEO IWS aligns the technical reviews for each 

program or project with those of the host combat 

system.

Test, Evaluation, and 

Certification

Outlined in the SE plan is the technical 

approach for integration test and evaluation, 

system certification, and life cycle support. During 

integration and test, the PSEA is responsible 

for delivering the ACB required capability. 

Component developers support the testing and 

correct problems found in their components 

during the test period, in accordance with the 

problem resolution budgets and contracts they 

have in place.

Figure 6 illustrates that combat system 

integration and test is a hierarchical process. Level 1 

testing starts at the component level to ensure each 

component meets its requirements. Level 2 testing 

begins to integrate components to execute chains of 

functionality. Level 3 testing integrates components 

to form an element and verifies element-level 

requirements. Level 4 and Level 5 testing is 

performed at the weapon- and combat-system 

levels, respectively, by a collaborative test team 

composed of PSEA and Navy test engineers. This 

testing focuses on verifying element- and systemlevel requirements in the target environment and 

assesses system performance and stability under 

stressing and endurance conditions.

Figure 6. Integration and Test
Systems Engineering Planning

57

ACB at-sea testing, conducted by the 

PSEA and Navy test engineers, is the most 

important phase of testing prior to inclusion of 

the technology in the combat system. This test 

provides the opportunity to verify performance 

and collect calibrated data for future use. The 

PSEA is also responsible for evaluating and 

assessing the test results and for the interpreting 

the component-level and subsystem- or systemlevel results. These at-sea tests are not intended to 

serve as the system certification.

Described in the SEP is the manner in which 

the program will implement system certification. 

PEO IWS accomplished system certification 

via a separate testing effort following full 

integration of the ACB into the baseline system. 

However, this step is designed with certification 

in mind so that the program office can ascertain 

the level of certification testing required. In 

addition, Navy Operational Test and Evaluation 

Force representatives participate in testing as 

independent observers, facilitating decisions 

regarding future certification testing. Upon 

test completion, the system is delivered to the 

program office for incorporation into the combat 

system.

Following the fielding of a combat system, its 

performance is analyzed based on data collected 

during deployments in actual operational 

environments as part of a life cycle support plan. 

The life cycle support plan is designed to provide 

data to support future ACB spirals, to establish 

a new baseline capability to compare to future 

improvements, and to address real-world Fleet 

issues in operational environments.

Value Added

The SE plan captures the program’s current 

and evolving SE strategy and its relationship 

with the overall program management effort. It 

documents the program office’s understanding 

of how the program will accommodate and 

balance cost, schedule, performance, sustainment 

requirements, and constraints, expected products 

of SE activities, and how these products will 

contribute to program decision-making. The 

real value from SE planning, however, is realized 

when warfighting capabilities and platforms 

work effectively and seamlessly together to help 

warfighters fight, win, and come home safely.

Systems Engineering Planning

57
58

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

Systems Engineering and Design –

From the Total Ship Perspective

by Miguel E. Rivera, Mark L. Williams, and Ashby G. Hall

The systems engineering (SE) landscape changed dramatically over the past decade 

due, in part, to a shift in the design and development of larger, more complex systems 

that cut across multiple programmatic, contractual, and technical boundaries. Recent 

acquisition policy changes and surface combatant lessons learned now emphasize 

the need for an SE process that facilitates coordinated total ship systems engineering 

(TSSE) through a total systems engineering team (TSET) construct developed in 

alignment with a structured technical baseline. This article introduces a new approach 

that blends a combination of top-down and bottom-up SE through the employment 

of an architectural core utilizing the DoD Architecture Framework (DoDAF) as the 

foundation. 

The key phrase throughout this discussion is “from the total ship perspective.” As 

far as is known, this recommended SE approach provides, for the first time, a process 

to apply SE from a total ship perspective with a focus on the technical baseline and 

engineering and design management acquisition phases. This approach has yet to be 

performed from cradle to grave for a large ship program.

Systems Engineering and Design Process

The Systems Engineering and Design Process (SEDP), shown in Figure 1, 

merges top-down and bottom-up SE by employing an architecture framework as 

the foundation to facilitate coordinated TSSE and design processes in alignment 

with a TSET construct. The approach utilizes the DoDAF as the architectural core 
59

Systems Engineering and Design – From the Total Ship Perspective

to facilitate total ship (mission systems, ship 

systems, and support systems) coordination and 

evolution throughout the program life cycle. 

An iterative evolution converges on a traceable, 

testable, feasible, and cost-permissive design that 

meets Office of the Chief of Naval Operations 

requirements as provided through the Joint 

Capabilities Integration and Development Systems 

(JCIDS) Process within the Initial Capabilities 

Document (ICD) and Capability Description 

Document (CDD).

The SEDP is a comprehensive, iterative, 

and recursive problem-solving process, applied 

sequentially by integrated teams. It transforms 

needs and requirements inset of system products 

and process descriptions, generates information 

for decision-makers, and provides input for 

the next level of development. The SEDP is 

applied sequentially, one level at a time, adding 

additional detail and definition with each level of 

decomposition.

The SEDP is derived from lessons learned 

from recently engineered and designed surface 

combatants and aligns with acquisition policy 

updates. The SEDP includes four components: 

(1) Notional Timeline; (2) Top-Down SE; (3) 

Architectural Core; and (4) Bottom-Up SE. Each 

of the components is addressed in further detail 

below. 

Notional Timeline

The notional timeline, depicted in the 

top of Figure 1, encompasses the material 

solution analysis, technology development, and 

engineering and manufacturing development 

phases of the acquisition life cycle. The timeline 

identifies milestones, gates, technical reviews, and 

pertinent decision points in alignment with new 

and updated SE and acquisition guidance. The 

timeline provides the driving force for alignment 

of TSSE. Actual timelines will be program-specific 

and may require tailoring for program needs.

A key element of the timeline is the 

operational requirements. For most major defense 

acquisition programs, this requirement will come 

in the form of a CDD that has been validated and 

approved by the Joint Requirements Oversight 

Council through the JCIDS process. Since the 

CDD is not formally approved until Milestone B, 

it is assumed that the acquisition program will be 

Figure 1. Systems Engineering and Design Process
60

Platform-Level Systems Engineering

Combat Systems Engineering & Integration

provided with various draft and Navy-validated 

releases. The timeline depicts notional CDD 

releases and assists in ensuring design alignment 

to end-user needs. 

Top-Down Engineering

Top-down engineering, depicted in the upper 

middle of Figure 1, aligns with requirements 

development SE activities and commences with 

the analysis of process inputs. Requirements 

analysis is used to develop functional and 

performance requirements; i.e., customer 

requirements are translated into a set of 

requirements that define what the system must 

do and how well it must perform. The systems 

engineer must ensure that the requirements are 

understandable, unambiguous, comprehensive, 

complete, and concise. Requirements analysis 

must clarify and define functional requirements 

and design constraints. Functional requirements 

define quantity (how many), quality (how 

good), coverage (how far), timelines (when and 

how long), and availability (how often). Design 

constraints define those factors that limit design 

flexibility, such as environmental conditions or 

limits; defense against internal or external threats; 

and contract, customer, or regulatory standards. 

An initial set of DoDAF operational 

viewpoints (OVs) is provided as input within 

the net-ready key performance parameters of 

the CDD. These OVs provide a mechanism for 

capturing the organizations, tasks, or activities 

performed, and information that must be 

exchanged to accomplish DoD missions. OVs 

convey the types of information exchanged, 

frequency of exchange, tasks and activities 

supported by the information exchanges, and 

nature of the information exchanges. The 

DoDAF OVs are used to support and validate the 

operational and functional requirements. 

The iterative requirements loop ensures 

that both the requirements and architecture are 

consistent and characterize the complete system. 

The process then proceeds with the Synthesis 

Phase. After the completion of one complete SE 

cycle, a baseline is established and the process 

begins again for the next baseline.

Architectural Core

In parallel with the top-down and bottomup engineering, a series of architectural products 

is developed through functional analysis and 

allocation SE activities. The architectural core is 

depicted in the middle of Figure 1. Functions are 

analyzed by decomposing higher-level functions 

identified through requirements analysis 

into lower-level functions. The performance 

requirements associated with the higher level 

are allocated to lower functions. The result is 

a description of the product or item in terms 

of what it does logically and in terms of the 

performance required. This description is often 

called the functional architecture of the product 

or item. 

Functional analysis and allocation allow for a 

better understanding of what the system has to do, 

in what ways it can do it, and to some extent, the 

priorities and conflicts associated with lower-level 

functions. This provides information essential 

to optimizing physical solutions. Key tools in 

functional analysis and allocation are use cases, 

functional flow block diagrams, requirements 

allocation sheets, and the DoDAF All Views 

(AVs), OVs, System Views (SVs), and Technical 

Views (TVs). 

The DoDAF SVs capture information on 

supporting automated systems, interconnectivity, 

and other systems’ functionality in support of 

operating activities. The SVs provide a functional 

alignment to the requirements through OV 

mappings and alignment and facilitate a 

framework to capture the physical ship design. 

The AVs provide an overall description of the 

complete architecture, the scope, and definitions 

of the terms used. The TVs define the applicable 

and emerging technical standards, conventions, 

and business rules. 

Bottom-Up Engineering

The bottom-up engineering aligns with the 

synthesis (design) SE activities as depicted in the 

bottom of Figure 1. Design synthesis is the process 

of defining the ship in terms of the physical and 

software configuration. The result is often referred 

to as the physical architecture that includes ship 

arrangements and layouts. Each part must meet 

at least one functional requirement, and any part 

might support many functions. The physical 

architecture is the basic structure for generating 

the specifications and baselines.

The design process employs the ship work 

breakdown structure as a system-oriented coding 

structure to categorize the various subsystems. 

Standard design engineering, in accordance with 

Naval Sea Systems Command (NAVSEA 05) Ship 

Design Manager Manual, evolves development of 

the ship design from the analysis of alternatives to 

the contract design. 

Similar to the requirements loop described 

above, a design loop is employed to revisit the 
61

Systems Engineering and Design – From the Total Ship Perspective

functional architecture to verify that the physical 

design synthesized can perform the required 

functions at required levels of performance. 

The design loop permits reconsideration of how 

the system will perform its mission and helps 

ensure consistency with the requirements and 

architecture. DoDAF SVs are a mechanism to 

capture the physical design. 

Technical Baseline

Baselines signify departure points for 

government configuration control. Figure 2 

depicts a notional technical baseline with 

technical review overlays. The technical baseline 

was constructed to resolve the lesson learned 

for closer coordination between mission and 

ship design developers. The specification tree 

aligns TSSE activities to ensure a final design that 

converges and is traceable back up to the ICD.

The technical baseline includes four 

independent baselines: (1) performance, (2) 

functional, (3) allocated, and (4) product. The 

performance baseline consists of the operational 

requirements as captured in the ICD as developed 

in the material solutions analysis phase and the 

CDD, both of which are under the purview of the 

Office of the Chief of Naval Operations, Surface 

Warfare Division for the Surface community. 

The functional baseline includes the Specified 

Performance Document (i.e., the total ship system 

requirements document), the System/Subsystem 

Design Description, and the other associated ship 

architectural products. 

The allocated baseline is composed 

of functional, performance, and interface 

requirements as flowed down from the Specified 

Performance Document and allocated to lower 

level segment and element specification. The 

product baseline contains an approved design 

that describes the system configuration during 

the procurement and production, fielding/

deployment, and operational support phases of 

its life cycle. The product baseline includes the 

Ship Specification [i.e., Design, Build and Process 

Specification] and lower-level detailed design 

artifacts.

 At the point in the design when development 

of the ship specification has begun, all portions of 

the requirements flow into the ship specification 

and are broken down by the ship’s work 

breakdown structure. This includes all lowerlevel requirements, purchase specifications, 

drawings, and diagrams. Again, the purpose of 

this construct is to ensure all aspects of the design 

stay coordinated by the entire team throughout 

development. As previously mentioned, the key 

Figure 2. Example Technical Baseline
62

Platform-Level Systems Engineering

Combat Systems Engineering & Integration

to the SDEP and development of the Technical 

Baseline resides with a coordinated TSET.

Teaming

Figure 3 illustrates a notional teaming 

concept for maximization of SEDP benefits. 

This teaming structure provides a coordinated 

approach that aligns the programmatic side, led 

by the Program Manager, and the technical side, 

led by the Technical Director and Ship Design 

Manager, into a seamless organization. Based on 

a total ship focus, it is assumed that all aspects of 

the program are included (i.e., risk management, 

configuration management, cost), although these 

are not specifically discussed within this article. 

The notional teaming concept includes three 

components: (1) the Program Management Team; 

(2) the Technical Management Team; and (3) the 

TSET. The TSET manages the Product Teams and 

Cross-Product Teams. Each of the components is 

addressed in further detail below.

A key element of the teaming concept is a 

team with co-leads. Each major team will have 

two co-leads, typically one from the top-down and 

one from the bottom-up portion of the process. 

This co-lead approach is loosely based upon that 

of the Virginia-Class Submarine Program and has 

been modified to complement the SEDP approach 

and the associated technical baseline. 

Program Management Team

The Program Management Team is the 

top-level team that manages the program and 

coordinates with other program, business, and 

financial managers in partnering organizations. 

The Program Manager and Senior Ship Design 

Manager are co-leads. 

Technical Management Team

The Technical Management Team is 

composed of engineering leads from the systems 

commands and participating PEOs as well as 

Figure 3. Notional Teaming Construct
63

Systems Engineering and Design – From the Total Ship Perspective

leads from the TSET, Cross-Product Teams, 

and Product Teams. The team provides day-today technical management and coordination 

with emphasis on integrating efforts related 

to requirements, architecture, interfaces, 

interoperability, testing, and system verification 

and validation. The team is the bridge between the 

technical and programmatic work. The Technical 

Director and Ship Design Manager are co-leads.

Total Systems Engineering Team

The TSET performs SE management and 

technology development management functions. 

The TSET defines and establishes SE processes; 

coordinates SE activities across Product Teams 

and Cross-Product Teams; supports the Technical 

Director in the preparation and execution of 

technical reviews; oversees technology risk 

reduction activities; and coordinates technology 

readiness assessments. The team is key to the 

success of the SEDP and maintains coordination 

among all the stakeholders and teams. The TSSE 

and Deputy Ship Design Manager are co-leads. 

Product Teams represent the functional 

areas such as Combat Systems, led by PEO 

Integrated Warfare Systems; Command, Control, 

Communications, Computers, and Intelligence 

Systems, led by PEO C4I; Aviation Systems, 

led by Naval Air Systems Command; and Ship 

Systems, led by NAVSEA 05. The teams work 

the development and design of their respective 

functional areas and provide the membership for 

all the Cross-Product Teams, thereby ensuring 

that they have input into all aspects of the design. 

Product Teams do not require co-leads.

Cross-Product Teams perform and 

coordinate functions that must cross the product 

boundaries to help facilitate an integrated total 

ship systems design. Cross-Product Teams form 

the lowest management level that requires coleads.

Conclusions

A systems engineering design – from the 

total ship perspective – is necessary to manage 

an integrated technical baseline for the total ship 

as it advances through the Navy surface platform 

acquisition life cycle. This proposed approach 

blends a combination of top-down and bottomup SE. A DoDAF architecture framework serves 

as the foundation to facilitate coordinated, total 

ship SE and design processes that are aligned 

with a total ship engineering team. It is based 

on lessons learned from multiple platforms. If 

adopted, this approach will help the Navy better 

design and build systems-engineered ships 

more efficiently and more effectively, ultimately 

benefiting naval warfighters with enhanced 

capabilities for years to come.

Bibliography

Chairman of the Joint Chiefs of Staff, Interoperability and Supportability of Information Technology and National Security Systems, 

CJCSI 6212.01E, December 2008.

Chairman of the Joint Chiefs of Staff, Joint Capabilities Integration 

and Development System, CJCSI 3170.01G, 1 March 2009.

Chairman of the Joint Chiefs of Staff, Manual for the Operation of 

the Joint Capabilities and Development System, 31 July 2009.

Concept Design Handbook Version 1.0, NAVSEA 05D, 27 December 

2006.

Defense Acquisition University Press, Systems Engineering Fundamentals, January 2001.

Department of Defense, Operation of the Defense Acquisition System, DoDI 5000.02, December 2008.

Department of Defense, Systems Engineer Plan Preparation Guide 

Version 2.01, April 2008.

Department of Defense, The Department of Defense Architecture 

Framework (DoDAF) Version 2.0, May 2009.

Department of the Navy, Systems Engineering Technical Review 

Handbook Version 1.0, Draft, October 2008.

Deputy Under Secretary of Defense for Acquisition and Technology, Systems Engineering Guide for Systems of Systems Version 1.0, 

August 2008.

Government Accountability Office, Best Practices – High Levels of 

Knowledge at Key Points Differentiate Commercial Shipbuilding 

from Navy Shipbuilding, May 2009.

PEO IWS and NAVSEA 06, Technical Review Manual (TRM) Version 2.0, December 2009.

Secretary of the Navy, Department of the Navy (DON) Requirements 

and Acquisition Process Improvements, SECNAVNOTE 5000, 26 

February 2008.

Secretary of the Navy, Implementation and Operation of the Defense 

Acquisition System and the Joint Capabilities Integration and Development System, SECNAVINST 5000.2D, 16 October 2008.

NAVSEA 05D, Ship Design Manager Manual, 1 June 2009.
64

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

Total Ship and Enterprise Approach to the 

Navy Platform Technical Team Model

by David S. Richardson, Greg LaCava, and Stephen Haug

For more than a decade, the Navy’s surface ship technical community has 

supported system acquisitions using a model known as “Tech Team.” This model 

focuses the right technical expertise at the right levels from warfare centers, universityaffiliated research centers, and support contractors into a virtual enterprise for 

the Navy to ensure necessary technical oversight in the research and development 

phases of ship design. With the recent refocus on systems integration, the roles 

and responsibilities of government and private sector engineering staffs are being 

reevaluated. The Tech Team model can be sized and structured appropriately for a 

given program based on the acquisition approach and desired risk level. In addition, 

the Navy is moving toward a product line systems engineering approach for platform 

development, where consolidation of components and openness of architectures is 

embraced. Items addressed in this article are how the model operates, lessons learned 

over the last decade, critical environments and tools to maintain technical insight 

over varying levels of design detail, and how it can be utilized by the Navy to support 

systems integration challenges in a 21st century Fleet.

64

Combat Systems Engineering & Integration

Platforms

Carrier Amphibious

Air & Missile 

Defense

Sensor

Products

Weapon

Sensor

Products

C2

Products

Computing 

Environment

ISR

Products

Integrated

Fire Control

Capabilities

Product

Lines

Platform-Level Systems Engineering
65

Total Ship and Enterprise Approach to 

the Navy Platform Technical Team Model

Introduction

Motivation

The surface Navy requires a centrally 

managed, technically founded, large-scale system 

of systems engineering capability at the crossplatform, combat system level to effectively 

manage combat system enterprise development. 

The focus needs to be on key technical initiatives 

to enable this evolution; specifically, architecture, 

requirements, systems engineering planning, 

and systems integration. This will be further 

enabled through an enterprise organizational 

structure that includes technical teams, maintains 

continuity of leadership, and revitalizes 

government technical roles in the warfare 

centers. The need to transition the surface Navy’s 

combat systems acquisition processes, technical 

underpinnings, and organization is pressing. The 

benefits to be derived from implementation of 

the new business model and enterprise systems 

engineering principles extend from tangible cost 

savings to rapidly and effectively integrating 

warfighter capabilities in response to everchanging threats. The transition of the surface 

combat system acquisition enterprise to the new 

business model is an essential element in the 

Navy’s ability to achieve its goals for its future 

surface combatant force.

The approach to moving toward an enterprise 

warfare systems environment for surface combat 

systems is centered on establishing a product line 

of reusable components that can be assembled 

by the platform system integrators into systems 

that meet all of the requirements of a particular 

ship class to enhance broad Navy warfighting. 

Requirements and systems engineering processes 

are tailored to implement these principles and 

foster competition and collaboration throughout 

the acquisition and operations and support phases 

of a ship and of a system’s life. 

Failure to adopt an enterprise development 

model will maintain the existing cost structure, 

within which multiple efforts to provide the same 

capabilities must be funded. Legacy architectures 

will still require a higher level of effort and cost to 

65

Total Ship and Enterprise Approach to 

Navy Platform Technical Team Model

Support

Products

Comm.

Products

Displays Training

Products

Track Mgmt 

Products

Vehicle 

Control 

Products

Surface 

Warfare

Naval Fires Anti-Sub 

Warfare

Mine Warfare

Aircraft Surface Combatant Next-Generation

Platform
66

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

maintain and modernize. New construction ships 

will focus significant resources on redesigning and 

testing capability similar to what is already fielded, 

and any new capabilities will not be readily 

backfit on legacy ships. The extra expense of this 

redundant effort will hinder the Navy’s ability to 

build the future Fleet, and is already unaffordable 

for the Navy to sustain.

Naval warfare centers have a long heritage of 

integrating ever more complex systems into the 

warfighting capability for the nation. For example, 

this unique capability was recognized by the 2005 

Base Realignment and Closure Commission and 

in international texts on the subject of large-scale 

systems integration at Naval Surface Warfare 

Center, Dahlgren Division (NSWCDD). With 

an enduring technical professional development 

program, the NSWCDD laboratory has 

successfully shown the value of engineering rigor 

up the systems’ hierarchy: components, systems, 

ships, and force. An aggressive reinsertion of the 

warfare center to lead as the prime integrator 

for targeted major weapon system acquisitions 

is a sound strategy, especially in aligning 

programs at the beginning of their acquisition 

and development cycles. This action rebalances 

the risk between the public and private sectors 

and will help reestablish the military-industrial 

complex needs while providing stability to combat 

system platform developments. 

Challenge

Decades of increasing requirements driving 

increasing levels of machine complexity, coupled 

with socioeconomic business strategies, have led 

to major ship and submarine cost deviations, 

an atrophying of the public sector work force 

of scientists and engineers, and a significant 

decrease in affordable naval force structure. This 

has been caused in part by a gradual diminishing 

of government technical participation and 

active technical oversight during development, 

the classical technical team roles. Acquisition 

strategies for ship development must lean more 

heavily on the Navy laboratory infrastructure to 

regain and maintain long-term technical control 

of the most highly integrated, complex, capable 

machines ever to go to sea—the naval warship. 

The Navy is organized for systems acquisition 

in a way that reflects its historical planning, 

funding, and acquisition execution. Requirements 

are defined around platform programs (the 

verticals) as opposed to product line capabilities 

(the horizontals) that can be employed across 

multiple platforms. The responsibilities for 

providing these requirements, as well as the 

structure within which budgets are developed 

and executed, are similarly aligned to the 

verticals. Because organizations tend to reflect 

the environment in which they work, both the 

acquisition community and the customer side of 

the Navy are aligned to the vertical perspective. 

The broader industry (beyond the defense 

industry) historically was also aligned in verticals 

but has now recognized the need to integrate 

horizontally across platforms with common 

products managed horizontally. While many 

sectors of industry have been able to transition 

to the horizontally aligned organization in recent 

years, the Navy is constrained by the realities of 

working with Congress and with the complexity 

of multiple organizations interacting to deliver 

capabilities. The most effective mitigating 

action to address this challenge is to organize 

the requirements and budget infrastructure, 

including how appropriations are structured, 

to better reflect the benefits of the horizontally 

integrated enterprise. Critical to the success of the 

technical team organizational model is setting up 

the technical authority and technical structures 

to enable successful insertion of warfighting 

capabilities across platforms. 

Systems-of-Systems Context

Baron (2007)1

 opines a good summary of 

the state of play in the military and public sector, 

which is summarized here. There has been a 

collapsing of available private sector contractors 

in the military business base due to corporate 

acquisition and merger—actions that were driven 

by short-term financial pressures of share price 

protection and major contract capture. This 

state of affairs should be troubling to senior 

government leaders who rely on this competitive 

industrial base to economically execute decadelong national programs. Also surprising is that 

the government’s own technical infrastructure is 

not leaned on more heavily to bridge the inherent 

gaps in current corporate business ventures. Not 

only should the government provide critical 

services, it should also act as the technical risk 

management arm on behalf of the sponsor to 

continue program progress through completion. 

Industry contractors must not be given the 

full responsibility for our national defense, for 

accountability rests with our government. The 

current defense acquisition strategy is overreliant 

on private sector prime integrators for large-scale, 

complex system development at the exclusion of 

government technical institutions. 
67

Total Ship and Enterprise Approach to 

the Navy Platform Technical Team Model

The private sector prime contractor may 

also have limited knowledge into the full range 

of technological possibilities to resolve technical 

issues. It is not unreasonable to expect that by the 

simple nature of a depth of knowledge in its own 

internal technological investments, the prime 

contractor will tend to overly defend and rely on 

its internal technology for problem resolution. 

This may be at the expense of suboptimization 

of the design. Trust in and protection of 

proprietary rights and equitable compensation for 

corporate technology is a coveted governmental 

characteristic. The government laboratories, 

through proper disclosure arrangements, can have 

a much broader insight into the potential range of 

technological solutions to engineering challenges. 

There are several functions that must move 

back to the government, but care must be taken 

to not swiftly move too many acquisition roles 

in that direction. Recent workforce reshaping 

and reduction activities in the warfare centers 

will limit the warfare centers’ ability to initially 

respond with significant additional resources. 

Reengagement of the government lead integration 

agent roles should take place with targeted 

programs and then continue to grow (crawl, 

then walk). This will allow the programs most 

in extremis to gain the earliest and maximum 

support while allowing the laboratory structure to 

rebuild human capital. The relationship between 

the program offices and laboratory must be 

shared responsibilities and not simple handsoff risk transfer as was with the industrial prime 

contractor integrator. Sustainment demands of 

a national intellectual infrastructure must be 

balanced and checked through resourcing and 

workflow mechanisms. A mutually agreeable 

condition that would allow more governmental 

technical leadership and execution in large-scale 

integration efforts can certainly be achieved, and it 

should be executed through organizational growth 

and targeted divestitures. 

The Navy surface and undersea warfare 

laboratories that are focused on the research, 

development, acquisition, and test and evaluation 

stages of acquisition, such as at NSWCDD and 

Naval Undersea Warfare Center, Newport, Rhode 

Island, can play key inherently governmental 

and critical technical leadership roles in 

major acquisition programs and in a systemof-systems context. These two organizations 

lead partnering between the warfare center 

enterprise and industry on the integration task, 

giving the program office the best minds, the 

widest knowledge base, and unbiased technical 

assessment as to program progress. Engineering 

across the ship mission domain and across all 

surface and subsurface platforms uncovers 

opportunities for efficiencies in engineering to 

fully realize warfighting and affordability goals. 

This is usually executed through a Tech Team 

model, where senior government experts lead 

various teams consisting of diverse public and 

private participation under the integrated product 

and process team structure of the particular 

acquisition. The Navy must lead certain critical 

teams while only providing unique subject-matter 

expertise to others. Determining which teams are 

led by the government and which teams are just 

supported is unique to each program, usually due 

to unique acquisition strategies and contractorgovernment relationships. Technical participation 

to gain insight and to be able to report technical 

progress as well as quick surfacing and 

participation in the realization of new technical 

unknowns or challenges that must be resolved 

for program success is critically important. This 

would take the form of an integrated warfare 

center technical team that is capable of working 

across Navy platform programs. In addition, 

resource sponsors must be incentivized to allow 

Navy platform technical teams to work across 

programs to enable better products for less 

investment. These changes will enable a better 

usage of a total ship and enterprise approach 

to national technical teams led by the warfare 

centers, and will create better and more reusable 

products across Navy combat systems.

A secondary advantage of exploiting 

integration centers at Dahlgren and Newport is 

the ability to share, implement, and exploit crossprogram system solutions, standards, processes, 

and integration strategies; thus, providing a 

system of systems integration. Government 

leaders, senior scientists, and engineers are able 

to oversee and direct enterprise initiatives within 

their programs on such important integration 

topics as open architecture, modular development, 

and cross-program reuse since these initiatives are 

not only good business strategies but also enable 

the force-wide capabilities of naval and Joint 

systems of systems to be technically realized. 

Current Surface Navy Tech 

Teams

Approach

In recent Navy surface combatant 

acquisitions, the common practice has been 

for an industry contractor to be selected as the 
68

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

Platform System Engineering Agent (PSEA), 

in charge of integrating the various Program 

Acquisition Resource Manager-provided products 

(e.g., sensors, communications, and weapon 

systems) into a combat system. The PSEA often 

also provides the Combat Management System 

software that controls the combat system. A Navy 

Technical Team is then stood up to oversee the 

efforts of the contractor. The Technical Team acts 

in an advisory role, assisting in identifying risks 

and mitigations and solutions to issues but not 

making decisions or developing products, which 

are the responsibility of the PSEA. The Technical 

Team also provides the Program Manager with an 

independent technical assessment of progress and 

risks.

In general, the Technical Teams mirror the 

work breakdown structure of the PSEA. The 

work breakdown structure is usually broken 

down by product, and the Technical Team is 

then defined as Integrated Product Teams (IPTs) 

along those product lines. Examples include 

Command, Control, and Intelligence; Weapons, 

Communications; and Sensors. In addition to 

product IPTs, there are usually a few CrossProduct Teams (CPTs) covering areas that touch 

many of the product IPTs. Examples include 

test and evaluation, modeling and simulation, 

and certification. Figure 1 represents a typical 

technical team structure. 

All recent Navy acquisitions also have 

an overarching, high-level technical team, 

represented by the Systems Engineering and 

Integration (SEI) team in Figure 1. The main 

role of the SEI team is to coordinate the IPTs 

and CPTs to ensure that the integrated system is 

capable of meeting its requirements. This includes 

identifying issues and decisions from lower level 

teams that may affect other teams and identifying 

and managing risks across the system. The SEI 

team also includes internal teams responsible for 

system requirements architecture development 

that affect the whole system.

IPTs are composed of members from industry 

(including the PSEA and system component 

developers) and Navy. Navy members come 

from the warfare centers (e.g., NSWCDD and 

Naval Surface Warfare Center, Port Hueneme 

Division), Navy contractors (e.g., Johns Hopkins 

University Applied Physics Laboratory), and the 

program executive offices (e.g., Program Executive 

Office [PEO] Integrated Warfare Systems and 

PEO Command, Control, Communications, 

Computers, and Intelligence [C4I]). The Navy lead 

of each IPT is typically from the organization that 

specializes in the area; for example, the C4I IPT 

Navy lead is from PEO C4I. 

IPT member responsibilities vary from 

program to program. In some programs, the 

Navy members participate in development of the 

products. In others, the Navy members participate 

in more of an advisory role. In all cases, the Navy 

members are responsible for understanding the 

product, reviewing requirements and design, 

identifying and recommending solutions for 

potential problems, and reporting progress to the 

IPTs.

Managing IPTs whose members are all 

across the country requires the use of good 

systems engineering tools and collaborative 

environments. Programs provide collaboration 

tools like VIEWNet, which is a Navy-owned 

“virtual war room” that allows teams to 

access information affecting engineering 

decisions quickly, utilizing calendar, action 

item, program review, library, and technical 

artifact review management. Programs also 

provide collaborative environments like the 

Navy Integrated Collaborative Environment, 

which serve as data repositories and hosts for 

engineering tools like the Dynamic ObjectOriented Requirements System (DOORS), the 

de facto standard requirements management tool 

for Navy surface combatant programs.

Advantages of the Tech Team Approach

One advantage to the traditional approach is 

it allows for a staggered startup of IPTs and allows 

them to grow or shrink as needed. For example, in 

the early stages, the SEI team can be fully staffed 

while the system requirements are being defined. 

Once those requirements are defined, the lower 

component requirements are derived from them, 

at which point the product IPTs’ membership 

would be increased. Similarly, as acquisition 

progresses from development to integration, the 

product-based teams can be decreased while the 

testing and certification teams are increased.

This allows the teams to be the right size at 

the right time, helping to minimize cost. Perhaps 

more important, this also enables laboratories to 

balance resources across programs by having the 

outgoing team members move to a new project 

during the right phase. System requirements 

members can move to a startup program or 

product team members can move to another 

program in early component definition. This 

helps to ensure that lessons learned are rolled into 

successive development, experts are fully engaged, 

and a knowledge base is maintained. 
69

Total Ship and Enterprise Approach to 

the Navy Platform Technical Team Model

Another advantage of the current approach 

is found in the SEI team. The SEI team, as an 

overarching body of senior engineers, ensures that 

issues are dealt with at the system level. Productbased IPTs run the risk of becoming stove-piped, 

unintentionally not considering the effects on 

others of design decisions, risks, and issues that 

arise. The SEI team meets regularly with all the 

IPT leads to ensure all issues were shared, and also 

keeps a register of risks that includes the impact 

to all. Similarly, the SEI internal teams ensure that 

system architecture and requirements reflect all 

the elements, and that the ways in which changes 

within one element impact other elements 

are considered. Frequent communication is 

instrumental in getting potential risks identified 

and mitigated early.

Similarly, the CPTs ensure that, for major 

design elements, the relevant product teams work 

together. Within the CPTs, the Subject-Matter 

Experts (SMEs) not only focus on their elements 

but work together to ensure that overarching 

design issues are resolved across the system.

As stated earlier, team membership includes 

not only the PSEA but many government and 

support contractors and system component 

developers. This ensures that, throughout the 

process, all stakeholders are represented. For 

example, issues related to operator training 

would not be found until system delivery if the 

training community is not involved throughout 

development. That would result in either operator 

workarounds or expensive changes that can be 

avoided by early issue identification.

Disadvantages of the Tech Team Approach

Of course, there are disadvantages to the 

traditional approach as well. Perhaps the biggest 

disadvantage is that the bulk of all technical work 

is done by Navy contractors. This leaves the Navy 

team members less opportunity to develop the 

necessary knowledge and skills to become the 

SMEs needed to oversee the PSEA work. This 

makes it difficult, if not impossible, to oversee 

all the PSEA work, resulting in the Navy team 

targeting oversight to the most risky or significant 

areas. SMEs are needed to track key issues in their 

areas and must have the breadth to ensure that 

issues in otherwise low-risk areas do not develop 

into critical problems. 

While the contractors all work hard to 

ensure a successful product, there is little 

incentive or ability to seek out commonality in 

similar programs for potential reuse. Rather, the 

contractors are likely to use in-house technologies 

and solutions to maximize return on their 

investments. This has led to combat systems with 

different architectures, interfaces, data models, 

Figure 1. Example of Navy Surface Combatant Technical Team Structure
70

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

and components, even though the systems are 

implementing very similar requirements. These 

differences result in increased cost and decreased 

interoperability.

Another disadvantage is that product IPTs 

tend to become stove-piped. Although the 

SEI team and CPTs try to minimize this, for 

most of the time the IPTs work alone. This can 

easily result in incompatible designs of the 

system components, which can cause delays or 

suboptimal systems.

Similarly, the IPTs can be divided if tech 

teams are not composed of members representing 

all stakeholders. The various organizations (e.g., 

PEO C4I, PEO IWS, and PEO Ships) all have 

different schedules for their products. Significant 

coordination is needed to ensure that all the 

dependencies are maintained. The SEI team has 

to manage the dependencies closely and ensure 

that all teams are bringing their products in on 

schedule, or managing delays such that they don’t 

affect other teams.

Another potential hurdle is enabling 

collaboration across geographically 

separated teams. In order to work together, a 

national Technical Team requires additional 

infrastructure and tools. Failures in either 

cause significant problems for the teams. For 

example, requirements are maintained in a 

single location, but access is required across 

the country. Problems at the central servers 

or the connections to each site can degrade 

performance, and the likelihood of such issues 

increases proportionally with the spread of the 

team. Classified projects require additional 

security measures that add to the infrastructure 

cost. Bandwidth issues can hamper team 

productivity. Similarly, when many team 

members require simultaneous access (e.g., 

during a major milestone review), the necessary 

software licenses may expire.

The tools have their own drawbacks in 

current acquisitions. All the system and software 

engineering tools used are very capable, but also 

very expensive, and have large learning curves. 

The PSEAs, as contractors, are sometimes free 

to choose whatever tools will best suit them. 

Although DOORS is generally the requirements 

tool of choice, there is little commonality 

between other tools. In order for Navy Technical 

Teams to function effectively, the Navy has to 

purchase sufficient licenses for every tool and 

invest in training for their teams. When a team 

member moves to another project, the training 

must be repeated for a new tool that performs 

the same functions. In addition, many tools (e.g., 

modeling and simulation tools) are created by 

the PSEAs, leaving the Navy dependent on PSEA 

expertise for any future analysis. 

Finally, the advantages gained from the 

“divide and conquer” product-based team 

approach can also become a disadvantage. Even 

though the teams are divided by product, there 

are dependencies between the teams that cannot 

be eliminated. Schedules invariably change over 

time as risks are realized and issues or unforeseen 

events cause delays. Those delays will in turn 

cause delays in the dependent programs. As a 

result, the schedule needs to be flexible enough 

to handle delays, something difficult to do when 

ship availabilities require a set date delivery.

Tenets of an Enterprise 

Technical Team

Although maintaining relevancy through 

continued education is important, competent 

cadres of systems engineers and major 

program chief engineers are not hired out 

of academia; they are developed through 

numerous experiential assignments. Domain 

knowledge and significant acquisition and 

technical experiences are critical to a successful 

systems engineering work force and establish 

the baseline technical competency required 

to drive higher orders of system complexity 

integration. These experiences form the basis 

to understand technical progress and risk via 

various organizational and acquisition models. 

These are professionals who have had a varied 

set of technical experiences, traditionally have 

not stayed in one product area, and use their 

experiences to develop an ever-increasing set of 

technical accomplishments. 

How to Develop an Enterprise Technical Team

Mr. Neil T. Baron, in the paper, Large-Scale 

Systems Integration, an Engineering Challenge of 

Modern Warship Design, NSWCDD, 2007,1

 opined 

how NSWCDD has modeled the development of 

warfare systems engineers. This presents a solid 

model for the time and effort required to “build” 

the technical competency of systems engineers 

capable of working across the surface Navy 

enterprise. The NSWCDD work force is trained to 

always take a “systems approach” to the problem 

space, thus optimizing the solution through a 

larger set of technical options. Mr. Baron states, “A 

general pedigree of the systems engineering work 

force at Dahlgren looks something like this based 

on the years of experience compiled over a career:
71

Total Ship and Enterprise Approach to 

the Navy Platform Technical Team Model

Base Discipline (1–8 Years)

Element engineering development. Elements of 

the combat system include sensors, guns, missiles, 

launchers, decoys, displays, combat management 

and/or control, communication links, and aspects of 

physical and functional ship integration.

Technical foundation. Technical foundations of the 

combat systems engineer include electrical, electronic, 

mechanical, computer engineering, physics, computer 

science, and mathematics disciplines.

Apprentice (5–15 Years)

Control systems (basic), either of a combat 

system element or between elements within a logical 

family of elements, such as multiple radars, multiple 

communication links, and multiple defense weapons.

Combat Systems Engineer (15 Years Minimum)

Assimilation of diverse and disparate weapon 

system components into an integrated whole. 

Assimilation of the whole into a mobile platform (ship) 

for support functions and deployment optimization.

Warfare Systems Engineer (15–20 Years Minimum and 

Combat Systems Background)

Assimilation of a platform combat system 

with diverse and disparate mission systems, such 

as intelligence; air traffic control; metrology; battle 

group command; and Joint Battle Management 

Command, Control, Communications, Computers, 

and Intelligence.”

Building a knowledgeable and deep cadre 

of systems engineers capable of working at 

these levels of complexity and integration takes 

numerous experiences and time. Once a deep 

pool of Enterprise Systems Engineers has been 

developed, the Surface Navy must look at how it is 

employing these talents through its organizational 

construct and approaches to Enterprise technical 

teams.

Organizational Construct

As previously stated, the Navy is organized 

for systems acquisition in a way that reflects its 

historical planning, funding, and acquisition 

execution. Requirements are defined around 

platform programs (the verticals) as opposed to 

product line capabilities (the horizontals) that 

can be employed across multiple platforms. The 

responsibilities for providing these requirements, 

as well as the structure within which budgets are 

developed and executed, are similarly aligned to 

the verticals. Because organizations tend to reflect 

the environment in which they work, both the 

acquisition community and the customer side of 

the Navy are aligned to the vertical perspective. 

The broader industry (beyond the defense 

industry) historically was also aligned in verticals 

but has now recognized the need to integrate 

horizontally across platforms with common 

products managed horizontally. While many 

sectors of industry have been able to transition 

to the horizontally aligned organization in recent 

years, the Navy is constrained by the realities of 

working with Congress and with the complexity 

of multiple organizations interacting to deliver 

capabilities. The most effective mitigating action 

to this challenge is to organize the requirements 

and budget infrastructure, including how 

appropriations are structured, to better reflect the 

benefits of the horizontally integrated enterprise. 

Critical to the success of the technical team 

organizational model is setting up the technical 

authority and technical structures to enable 

successful insertion of warfighting capabilities 

across platforms. Being able to facilitate this 

management and budgetary change facilitates 

Enterprise support from Warfare centers.

Figure 2 depicts an operational construct for 

technical teams, organized by function vice the 

traditional platform-centric organization. Being 

able to facilitate management and budgetary 

change facilitates Enterprise support from warfare 

centers. 

The surface Navy requires Combat System 

Integration (CSI) leadership that is accountable 

in developing product line capabilities and 

optimizing capabilities across the surface Navy. 

The CSI leadership would be supported by a cadre 

of experienced Enterprise systems engineers 

that works all systems engineering disciplines 

horizontally across the surface Navy. This group 

would encompass the “Family of Combat Systems 

Engineers” in Figure 2. These systems engineers 

would be supported by “product line” engineers 

chartered to develop products across surface 

Navy platforms. Some of these products will serve 

Enterprise needs while others may be unique, 

if only required by one surface Navy platform. 

A small percentage of each product line group, 

represented by the C’s within Figure 2, would 

be dedicated to Enterprise development and 

integration, and would likely come from the 

set of experienced engineers articulated above. 

Nominally, 10 percent of the warfare center work 

force would be dedicated to Enterprise needs 

(horizontals), while 90 percent would serve the 

individual platform development and integration 

(verticals) that is required to field ships. Executing 
72

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

this construct means Platform Program Managers 

must accept that 10 percent of their work force 

will work for the higher good of the Navy and 

Joint Enterprise. The program managers must also 

accept that the entire technical team works for the 

Navy; thus, their best and brightest need to have 

freedom to work across program bounds without 

dictating ownership of their technical team to 

their program solely. Sponsors and program 

managers would pull from a larger resource pool 

to meet their individual platform needs. The 

Navy would be able to integrate product lines into 

mission capabilities and then into platforms, and 

technical teams would ensure technical integrity 

through development of common components 

and integration into platform Combat Systems. 

Figure 3 depicts this concept, and illustrates how 

the Navy Enterprise needs to work through the 

web of product lines to develop mission capability.

The Navy needs to employ levels of 

governance to establish systems engineering 

rigor in the decision-making, definition, and 

management of Enterprise combat systems. 

Enterprise Products Required to Manage 

Technical Teams

In order for Enterprise technical teams 

to be effective, the government must own the 

architecture and requirements for combat systems 

and their components. The Navy must also put 

in place a governance structure and program 

management tools to manage combat system and 

component development.

Architecture and Requirements

To ensure that common combat system 

components are compatible across multiple 

platforms, the Navy must take ownership of 

combat system architecture, defining what the 

set of common components will be. In addition, 

to ensure interoperability of the components, 

the interfaces and requirements must be well 

defined and stable, so given a set of inputs, the 

expected processing occurs and the proper output 

is generated. Similarly, the performance of each 

common component must meet the needs of the 

combat system, or even the proper responses to 

input will not guarantee threats can be defeated.

On a macro scale, this is not much different 

from the way combat systems are managed today. 

For example, the Navy owns the interface between 

the Cooperative Engagement Capability (CEC) 

and the rest of the combat system, enabling 

independent development of both systems 

while ensuring that the CEC can be integrated 

into the combat system. The Navy also owns 

Figure 2. Combat Systems Integration Operational Construct
73

Total Ship and Enterprise Approach to 

the Navy Platform Technical Team Model

the requirements defining CEC functionality, 

again ensuring that the PSEA can design a 

combat system that includes CEC, knowing that 

the CEC will meet the combat system needs. 

Just as important, Navy ownership of both the 

architecture and requirements has enabled the 

CEC to be used on multiple platforms including 

Aegis and the Ship Self-Defense System. 

In order to enable Enterprise technical 

teams to have the same success throughout the 

combat system, this model must be expanded 

to all combat system elements. Traditionally, 

combat system software has been left to the 

PSEAs to develop, which has resulted in software 

components being developed to meet very similar 

needs multiple times, increasing the cost to the 

Navy. Navy organizations, such as NSWCDD, are 

uniquely suited to assess common needs across 

platforms. Navy ownership of the architecture and 

requirements allows the Navy to take advantage 

of that ability to define common components that 

will still meet PSEA needs and be interoperable. 

Although there is significant overlap, the 

interfaces, functionality, and performance 

requirements of seemingly common components 

on different platforms are not identical; it is not 

possible to simply take components from one 

platform and put them on another. To truly 

enable reuse of components across platforms, 

technical teams must be empowered to define 

the components such that the overall set will 

meet platform needs, to define the component 

interfaces and the standards used, and to define 

the component requirements. This will enable the 

teams to oversee component and combat system 

development by contractors.

Governance

The second element needed to manage 

combat system and component development 

is proper governance. As is always the case in 

development, this includes engineering boards to 

oversee the teams and make decisions affecting 

multiple stakeholders where agreement cannot 

be reached. An Enterprise Systems Engineering 

Management Plan (SEMP) must be developed 

to define the governance and define the 

systems engineering processes. As stated in The 

Importance of Systems Integration: System-ofSystems Enabler (Richardson 2008),2

“The SEMP should provide (1) technical 

program planning, implementation, and 

control; (2) the systems engineering process; 

and (3) methodology for specialty engineering 

integration. The first part describes the technical 

program tasks that must be planned and 

Figure 3. Platform, Capabilities, and Product Line Relationships
74

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

implemented and includes organization, work 

breakdown structure, scheduling, cost estimating 

and reporting, technical performance measures, 

and risk management. It essentially provides 

an overview of the technical tasks and their 

relationships and responsibilities to allow the 

technical manager to evaluate project execution 

and take corrective action if necessary. The second 

part provides the systems engineering process 

steps and tools from requirements development 

through delivery of the final product. The third 

part describes the required specialty engineering 

areas and how these will be integrated into the 

overall “mainstream” engineering process. Without 

these elements of the SEMP, the risk of developing 

an enterprise system at any cost is astronomical. 

The SEMP provides an efficient way to ensure 

the final product meets the requirements and 

measures progress toward the final product.”

The Navy must also develop an Integrated 

Master Schedule of all components and platforms. 

This schedule must accurately show all the 

dependencies of all the programs to ensure 

PSEAs get the components when needed. The 

schedule must also show the planned evolution 

of all the components to meet the needs of future 

platforms. Properly built, the schedule can be 

closely monitored for progress to identify risks to 

the programs and can be used to identify impacts 

of proposed changes.

Conclusions and 

Recommendations

Establishing an Enterprise naval technical 

team that works cross-program solutions is at 

the forefront for developing and integrating 

naval capabilities. The surface Navy requires 

CSI leadership that is accountable in developing 

product line capabilities and optimizing 

capabilities across the surface Navy. The CSI 

leadership would be supported by a cadre of 

experienced Enterprise systems engineers 

that works all systems engineering disciplines 

horizontally across the surface Navy. The basis for 

an Enterprise technical team needs to be actively 

cultivated through NAVSEA warfare centers. As 

with any complex change effort, challenges and 

risks abound. However, the risk of maintaining 

the status quo is significantly greater than any 

risk in making this transition. The steps outlined 

in this article present a very broad overview that 

must now be translated into more specific actions 

across the organization to take broad principles 

and apply them to specific programmatic 

actions. The way ahead is framed with challenge 

and opportunity both for the government and 

industry. Change cannot be instantaneous, and 

the realization of benefits of the transition will be 

over a period of years. 

References

1. Baron, Neil T., Large-Scale Systems Integration, an Engineering 

Challenge of Modern Warship Design, NSWCDD, 2007.

2. Richardson, David S.; Murphy, Alvin; and Sheehan, Terence, The 

Importance of Systems Integration: System-of-Systems Enabler, 

NSWCDD, 2008.
75

Total Ship and Enterprise Approach to 

the Navy Platform Technical Team Model

Sensors

Human Systems/Computer Interface

Mission Analysis

Modeling & Simulation

Integrated Logistics Support

Test & Evaluation

Certification

C3I Weapons Ship

75

Total Ship and Enterprise Approach to 

the Navy Platform Technical Team Model
76

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

Where the Combat System Meets the Sailor: 

The Redesign of the Aegis Combat Information 

Center 

by Jon Dachos

The Naval Surface Warfare Center, Dahlgren Division (NSWCDD), has a long 

history in the systems engineering design, development, testing, certification, and life 

cycle support of the Aegis Combat and Weapons Systems. Human systems integration 

(HSI), as an integral part of the systems engineering paradigm, however, is relatively 

new. 

HSI is a multidisciplinary field of study composed of human factors engineering, 

system safety, health hazards, personnel survivability, manpower, personnel, training, 

and habitability. HSI emphasizes human considerations as the top priority in systems 

design and acquisition to reduce life cycle costs and optimize system performance.1

This article demonstrates how HSI was employed when redesigning the Aegis Combat 

Information Center (CIC) – the vital link between the combat system and the sailor.
77

Where the Combat System Meets the Sailor: 

 The Redesign of the Aegis Combat Information Center

Aegis Combat Information Center

The Aegis Combat System (ACS) was 

designed as a total weapon system for the Navy 

to address multimission threats, including antiair, 

antisurface, and antisubmarine warfare. Onboard 

an Aegis cruiser, the CIC serves as the warfare 

center of the ship, facilitating the performance of 

ten primary and five secondary warfare areas that 

support required operational capabilities (ROC). 

The ten primary warfare areas include:

•	 Air Defense

•	 Surface Warfare

•	 Undersea Warfare

•	 Command, Control, and Communications

•	 Command and Control Warfare (C2W)

•	 Strike Warfare

•	 Electronic Warfare (EW)

•	 Information Warfare (IW)

•	 Mobility (MOB)

•	 Missions of State (MOS)

The five secondary missions include:

•	 Fleet Support Operations (FSO)

•	 Intelligence (INT)

•	 Logistics (LOG)

•	 Mine Warfare (MIW)

•	 Non-Combat Operations (NCO)

Given the vital roles that CICs play, it is 

necessary that they are designed with HSI in 

Figure 1. Sonar Technician (Surface) 1st Class Steven Duncan stands watch in the Combat Information Center during the Fleet 

Synthetic Training – Joint Exercise (FST-J) aboard the Arleigh Burke-class guided-missile destroyer USS Sampson (DDG 102). 

(090617-N-3570S-070 SAN DIEGO; June 17, 2009; U.S. Navy Photo by Mass Communications Specialist 2nd Class Jeremy M. 

Starr/Released)

mind to facilitate the needs of warfighters in the 

most effective and efficient ways. Considering 

today’s new technologies and the fact that the 

ships are reaching 15 to 25 years of service life, a 

redesigned CIC was needed to meet the threats 

of the 21st century. Figure 1 shows a sonar 

technician working the CIC of USS Sampson

(DDG 102).

Redesign of the Aegis Combat 

Information Center

The Naval Sea Systems Command (NAVSEA), 

Program Executive Office for Integrated Warfare 

Systems (PEO IWS), tasked NSWCDD, in July 

2008 to construct mockups of potential CIC 

arrangements, incorporating feedback from 

Fleet surveys and HSI evaluations. NSWCDD 

engineers, in partnership with PEO-IWS and 

the Ship Integration & Test and Ship Physical 

Systems groups at Lockheed Martin, performed 

HSI analysis to construct CIC mockups for Aegis 

CIC design consideration. The engineering 

team leveraged Dahlgren’s Human Performance 

Laboratory (HPL) to bring relevant Fleet 

operators, system designers, and stakeholders 

together to build a number of CIC layout 

options, refine the designs, and formulate a final 

recommendation. 
78

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

HSI Process

The initial HSI process started by developing 

evaluation criteria with inputs from the Fleet and 

Navy training community stakeholders on what 

makes a good CIC design from an operator’s 

perspective. A team of CIC working group 

members, consisting of PEO-IWS-1 (Integrated 

Combat Systems), NSWCDD, and Lockheed 

Martin traveled to San Diego, California, 

and Norfolk, Virginia, to survey, interview 

and collect CIC layout feedback from Navy 

cruiser (CG) and destroyer (DDG) crews with 

experience in CIC operations. 

Partial and full-scale CIC mockups 

were then developed in the HPL to facilitate 

evaluations of candidate layouts and to solicit 

feedback from stakeholders and representative 

U.S. Navy Fleet CIC operators and maintainers. 

Mockups of consoles and other equipment were 

created from plywood and foam core, combined 

with reconfigurable platforms, large screen 

displays, bulkheads, and overhead fixtures, which 

permitted rapid reconfiguration to evaluate 

additional layout options. Formal Fleet feedback 

was solicited on potential designs and over 4800 

comments were received and evaluated based 

on interviews with 17 Aegis CG/DDG crews, 

5 destroyer squadron/class squadron (DESRON/

CLASSRON) staff visits, COMNAVSURFOR 

staff, and all CSCS Aegis Waterfront Training 

Detachments.

Mockup evaluations were 

conducted in three phases: 1) Common 

Display System (CDS) console-toconsole arrangements, 2) CIC layouts 

of all CDS in space, and 3) peripheral 

equipment placements. CDS console 

mockups were used to evaluate the 

degree to which basic console-toconsole placement options impacted 

operator interaction, display visibility, 

and maintenance access. Mockups of 

the overall CIC space were subsequently 

developed to provide a realistic 

environment for evaluations with 

stakeholders, expert evaluators, and 

representative users. DDG and CG 

mockup versions were implemented 

sequentially, and separate evaluation 

events were held to focus on specific 

issues and mission areas. After overall 

console placement was solidified, 

detailed evaluations of the placement of 

peripheral equipment around individual 

consoles were initiated. 

Partial mockups were used to quickly 

evaluate specific features of proposed layouts, 

including console groupings, raised platforms, 

and visibility of bulkhead-mounted displays. A 

full-scale mockup of the proposed layout was 

created to support stakeholder walkthroughs 

and to assess various levels of usability from 

representative users. Different CIC layouts were 

created by arranging mockups of the CDS and 

peripherals (e.g., large screen displays (LSDs), 

telephones, loudspeakers, and status boards). 

Operationally relevant scenarios also were 

included in some of the layout walkthroughs with 

the Fleet. A software tool called Spatial Analysis 

Link Tool (SALT) was used to analyze console 

proximity and visual locations of watch-stander 

positions. From analyses performed, potential 

console arrangements were down-selected as 

some arrangements promoted collaboration 

and supervision, while other arrangements 

inhibited collaboration, wasted space, or could 

not accommodate shipbuilding constraints. Key 

evaluation criteria used by the evaluators are 

shown in Table 1.

A number of candidate layout options for 

the CIC were developed and narrowed down 

to six potential layouts for evaluation. Watchstation adjacency ratings (i.e., individual watchstander pairs were rated with respect to the 

Table 1. Key Evaluation Criteria for Combat Information Center (CIC) Mockups
79

Where the Combat System Meets the Sailor: 

 The Redesign of the Aegis Combat Information Center

need for physical proximity and visual sightline) 

were collected from Fleet subject matter experts 

to support placement decisions for individual 

console positions. A quantitative, more objective 

comparison of alternative layouts was then 

performed using a link analysis approach. Link 

analysis established a relative rating or score for 

each element-to-element relationship or “link.” 

The physical and visual links were rated with 

respect to criticality, or importance of the link, 

and the frequency in which benefit was realized 

from the adjacency. Once scores or priorities for 

individual links or watch-stander pairings were 

defined, those scores were used individually to 

prioritize placements or collectively to score and 

compare overall layouts. 

The link ratings were entered into SALT to 

calculate overall scores for each of the layouts 

under consideration at the time of the analysis. 

SALT was used to model and analyze the impacts 

to human performance associated with placement 

of human and machine resources within the 

workspace. It enabled human and machine 

resources to be positioned and connected using 

links that represent auditory, visual, and other 

types of relationships. These links were used as 

input into analysis algorithms that ultimately 

provided feedback as to the overall quality of a 

particular layout. A screen capture from SALT is 

shown in Figure 2.

Partial CIC Mockups

The partial mockups were used as the first 

set of CDS console mockups constructed to 

evaluate specific features of the numerous CIC 

layouts. The candidate layouts were reviewed 

to identify unique or central features that had a 

direct bearing on the suitability and effectiveness 

of the layout. Figure 3 shows a sampling of CIC 

layouts considered, with the features evaluated in 

the partial mockups highlighted. Over two dozen 

console arrangements or other unique features 

were identified for evaluation through the partial 

mockups. 

Evaluations were organized by NSWCDD’s 

Human Systems Integration Branch. Evaluation 

participants included personnel from the 

Center for Surface Combat Systems (CSCS), 

Dahlgren, Virginia, and from the Human Systems 

Integration, Ship Integration & Test, and Ship 

Physical Systems groups at Lockheed Martin. 

The first of the two partial mockup evaluations 

focused on console-to-console arrangements. 

A total of 20 different console arrangements or 

variations, employing up to six consoles at a 

time, were evaluated sequentially. The second 

evaluation focused on evaluating the impact 

of the distance from a second row console to a 

bulkhead-mounted display, and of the height 

of the second row above the first row. Two 

different console distances and two different 

platform heights were evaluated for a total of 

four configurations. In each event, the evaluators 

assessed each configuration in order using the 

list of evaluation criteria. Evaluators then held a 

group discussion to identify the highest priority 

issues. Example layouts are shown in Figures 4 

and 5. 

Full CIC Mockups

Overall, the development of the full 

mockup supported four types of evaluations: 

1) stakeholder tours, 2) role-playing usability 

assessments, 3) scenario-based usability 

evaluations, and 4) expert walkthroughs. A pair 

of mission usability evaluations were held to focus 

on identification of issues with the “ID Fusion” 

layout concept in general and the positioning of 

ID-related and coordinator positions in particular. 

The DDG layout was used for these two events. 

The first event embedded expert users, primarily 

instructors and staff from CSCS, in an ID-centric 

scenario. The scenario was presented using 

static tactical situation (TACSIT) screenshots 

on representative large-screen displays and on 

paper printouts at each console. Information 

was provided via the TACSITs and through 

communications to each role player, permitting 

the watch team to conduct representative 

evaluation activities for air and surface contacts. 

The positions of Tactical Action Officer (TAO), 

Combat System Coordinator (CSC), Radar System 

Controller (RSC), Anti-Air Warfare Coordinator 

(AAWC), Anti-Surface Warfare Coordinator 

(ASUWC), Surface Warfare Supervisor (SWS), 

Tactical Information Coordinator (TIC), and 

Electronic Warfare Supervisor (EWS) were 

included in the event. Each role player had an 

evaluator specifically assigned to monitor the 

player’s activities and identify any problematic 

issues. A second event was conducted using the 

same scenario, but with an intact watch team 

from USS San Jacinto (CG 56) as the CIC watch 

standers. A photo of an underway ID fusion 

usability assessment is shown in Figure 6.

Approximately 20 evaluators participated in a 

walkthrough evaluation to address areas difficult 

to assess through a watch-standing scenario. 

The major focus areas included safety, 

maintenance, and off-watch operational support. 
80

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

Figure 3. Sampling of CIC Candidate Layouts 

Figure 2. SALT Screen Capture 
81

Where the Combat System Meets the Sailor: 

 The Redesign of the Aegis Combat Information Center

Figure 4. Sample Partial Mockup Console Arrangements 

Figure 5. Platform Height and Display Visibility Evaluations Using Partial Mockups
82

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

The evaluators were briefed on the work to date, 

assumptions for the CIC layout, and specific 

areas of interest for evaluation. Each evaluator 

examined the mockup independently and then 

met in focus groups to discuss their findings 

and determine priority issues. In addition to 

the role-playing usability evaluations, a series 

of scenario-based usability assessments were 

also incorporated to address a multi-day tactical 

scenario. For each stage of the scenario, specific 

evaluation questions were presented, and the 

strengths and weaknesses of the layout to support 

relevant activities were discussed. 

Console Workspace and 

Peripheral Evaluations

Once the overall CIC layout was stabilized 

and planned positions of individual watch 

standers were confirmed, a detailed evaluation 

of the placement of equipment associated with 

each watch stander was initiated. Foam core 

mockups of the equipment items associated 

with each position were constructed, allowing 

current operators and subject matter experts to 

provide recommended positions for each item 

and rationale in terms of function, criticality, and 

frequency of use. The evaluations included a focus 

on discerning the placement principles for each 

participant in order to understand the priorities 

behind individual recommendations, support 

deconfliction of competing recommendations, 

and allow development of overall principles 

applicable across the CIC. The goal of this series 

of evaluations was to provide recommended 

locations for critical positions within the CIC 

and to identify general recommendations that 

could be extended to peripherals for many other 

locations. The aim was to create a consistent 

layout that considered grouping peripherals by 

function and positioning them within operator 

reach based on importance and frequency of use. 

By focusing on a consistent design, shipbuilders 

and on-board operators alike can avoid creating 

or dealing with complicated mounting systems. 

Existing space also can be maximized to allow for 

the potential growth of new peripherals on board.

The Aegis CIC modernization concept 

redesign analysis team examined all CIC layout 

options and considered all of the direct feedback 

from CIC operators, maintainers, coordinators, 

and decision-makers. Based on total system 

feedback, HSI evaluators were able to provide 

an optimized CIC layout recommendation with 

detailed rationale for each positioning, which was 

approved by Chief of Naval Operations, Surface 

Warfare Directorate (OPNAV N86). The final, 

approved, layout design is shown in Figure 7.

Conclusion

Aegis Weapon System (AWS) and Aegis 

Combat System (ACS) modernization efforts 

increase capabilities against current and 

future threats, extend service life, and increase 

interoperability. If CIC’s were designed without 

considering HSI, the Navy could produce CICs 

that do not enable operators and decisionmakers to effectively or efficiently perform the 

ten primary and five secondary warfare areas 

that support required operational capabilities 

(ROC). Fortunately, as a result of the Aegis 

CIC modernization concept redesign effort, the 

analysis team was able to recommend an optimal 

CIC design and identify and document key 

impact areas to include cost avoidance, safety, 

human performance, situational awareness, and 

enhancement of warfighting mission capabilities. 

The impacted time frame (2012 to 2047) covers 

the operational lifetimes of Aegis CGs and 

DDGs – approximately 80 ships with a combined 

2000 years of naval service remaining for the 

Navy. An enhanced Aegis CIC design, therefore, 

not only provides warfighters with modernized 

capabilities but with capabilities designed with 

human systems factors integrated to enhance CIC 

warfighting effectiveness.

Reference

1. Naval Postgraduate School, http://www.nps.edu/or/hsi/, accessed 

4 November 2010.
83

Where the Combat System Meets the Sailor: 

 The Redesign of the Aegis Combat Information Center

Figure 6. ID Fusion Usability Assessment 

Figure 7. The Final, Approved, Aegis CIC Layout Design
84

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

Advanced Capability Build Concept in 

Product Line Systems Engineering 

by Joel Washington and Gilbert Goddin
85

Advanced Capability Build Concept in

 Product Line Systems Engineering

Introduction

The surface Navy has adopted a new 

acquisition model for the design, development, 

integration, and delivery of combat system 

upgrades. This new model was adopted for 

three primary reasons: (1) to institute a regular, 

repeatable delivery of capabilities to the 

Fleet; (2) to provide synchronization points 

for integration and test of combat system 

upgrades to achieve cost efficiencies; and 

(3) to increase the flexibility of introducing 

new capabilities later in the process to enable 

“rapid” introduction into the Fleet. This model 

is referred to as the Advanced Capability Build 

(ACB) process. 

In addition to ACBs, product line systems 

engineering processes are being adapted both 

within a family of combat systems as well 

as across combat system families to develop 

reusable combat system capabilities outside of a 

major baseline development and then integrate 

them into ongoing ACBs. This provides the 

ability to develop new capabilities off the critical 

path of a baseline or ship deployment schedule 

and cut the new capability into a baseline when 

it is sufficiently mature. The ability to reuse the 

software in multiple baselines increases the 

number of ships that can receive the capability 

and reduces the overall cost of providing that 

capability. 

ACBs define the capabilities that are to 

be delivered to a specific ship in an integrated 

combat system package that satisfies its 

operational requirements. The delivered package 

includes interface software for all baselinespecific elements, the Combat Management 

System, and other software and systems integral 

to the overall core functions of the combat 

system. The ACB process consists of a single 

cross-combat system planning phase (ACB 

Planning) and multiple individual combat 

system execution phases (ACB Execution). The 

planning phase is a government-led activity 

that commences with initial scoping of multiple 

ACBs and concludes with the definition of 

system-level requirements and architecture 

products for specific ACBs, including the 

successful conduct of the System Requirements 

Review (SRR) for each of the combat system 

baselines. The execution phase focuses on the 

design, development, certification, and fielding 

of an ACB, and is carried out by industry 

with government oversight. The ACB concept 

allows for revisiting the capability scope at 

major milestones to allow additional specific 

functionality to be added in order to meet 

emerging operational needs or to defer originally 

planned capabilities that are not able to meet the 

overall ACB schedule.

The surface Navy is implementing a 

combat system development approach that 

places emphasis on commonality of software 

components across surface Navy combat systems 

by moving the portfolio of surface combat 

system programs toward a common architecture 

over time. The engineering approach to support 

this cross-baseline/cross-program focus is 

referred to as product line systems engineering (PLSE). The cross-program nature of PLSE 

dictates that the government must perform 

the systems engineering associated with the 

requirements and architecture definition and 

development, since it spans multiple program 

office prime contractors. The product line focus 

introduces specific attributes to the ACB process. 

This article will describe the PLSE process and 

how it supports the ACB concept, and how the 

government role is changing with respect to 

early requirements and architecture definition.

Surface Warfare Tactical 

Requirements Group/Capability 

Phasing Plan

The OPNAV Surface Warfare Tactical 

Requirements Group (SWTRG) provides 

guidance and governance for ACB content 

definition. It is the decision-making body for 

aligning requirements, priorities, and budgets 

for a given ACB. The SWTRG, with inputs 

from program executive offices, provides 

coordination and collaboration across resource 

sponsors, program offices, and the Fleet to 

provide integrated surface warfare capability 

requirements to the acquisition community. The 

SWTRG’s goal is to maximize resources and 

increase the efficiency with which the surface 

Navy delivers and modernizes integrated combat 

system capabilities.

The Program Executive Office (PEO) 

Integrated Warfare Systems (IWS) ACB planning 

process includes a Capability Phasing Plan 

(CPP) process that evaluates combat system 

candidate upgrades for inclusion into future 

ACBs. The CPP process results in a proposed 

roadmap for aligning existing programs, 

integrating new technologies, and implementing 

new capabilities to achieve the Office of the 

Chief of Naval Operations’ (OPNAV) requested 

capability requirements. The CPP is an input to 

the SWTRG ACB definition process. Figure 1 
86

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

illustrates the SWTRG/Capability Phasing Plan 

(CPP) process.

ACB Planning and Execution

The ACB planning process results in two primary products. The first is the CPP. The second is 

a set of combat system-level requirements and a 

combat system-level architecture that represent 

the scope and constraints of the capabilities to be 

implemented in a particular ACB. The ACB planning phase concludes with a successful SRR for 

each baseline. Aegis ACB 16 is currently in the 

planning phase.

ACB execution commences with an approved 

set of system-level requirements and a systemlevel architecture resulting from the SRR and 

concludes with the fielding of a complete, 

tested, certified capability. Nominally, the ACB 

execution timeline will be four years from SRR 

to first shipboard delivery and five years from 

SRR to final combat system certification. Since 

ACBs for multiple ship classes will be under 

parallel development, close coordination between 

product line integrated product teams (IPTs), 

cross-product teams, system integration program 

managers, major program managers, and combat 

system engineering agents will be required 

throughout the engineering lifecycle. PEO IWSled coordination of cross-product line impacts 

and interdependencies will be critical.

Naval Surface Warfare Center, Dahlgren 

Division (NSWCDD) has had significant roles 

in both ACB planning and execution. NSWCDD 

led the effort to develop combat system-level 

requirements and architecture for Aegis ACB 14 

capability upgrades. NSWCDD engineers also 

led execution of the SRR. Currently, NSWCDD 

is working closely with PEO IWS and OPNAV 

to develop the CPP and to define the specific 

capability upgrades for Aegis and SSDS ACB 16.

Likewise, NSWCDD has had a significant 

leadership role in the execution phase of Aegis 

ACB 12. NSWCDD generated the Systems 

Engineering Management Plan that guides all 

ACB 12 systems engineering activities. NSWCDD, 

working with OPNAV, led the development of 

the Naval Capabilities Document (NCD), which 

identifies the operational capabilities document 

for this ACB. Lastly, NSWCDD is the lead 

Navy technical organization working with PEO 

IWS to manage and oversee all ACB 12 design, 

development, and integration activities.

Systems Engineering Efforts

As systems become larger and more complex, 

the design, development, and production of such 

systems, or system of systems (SoS), require 

greater levels of integration of numerous activities 

and processes. Systems engineering seeks to 

coordinate and integrate all acquisition lifeFigure 1. ACB Content Definition Process
87

Advanced Capability Build Concept in

 Product Line Systems Engineering

cycle activities. It integrates diverse technical 

management processes and develops technical 

information to support the program management 

decision-making process to achieve integrated 

system design. 

Presently, each acquisition program defines 

its own systems engineering plan and executes it 

relatively independently from other acquisition 

programs. The concept of PLSE expands the 

focus from a single program or system to 

identifying common requirements, interfaces, 

and implementations across a wider set of 

surface Navy combat systems. As each surface 

combat system moves towards a predictable, 

repeatable ACB development cycle, it becomes 

increasingly possible to coordinate capability 

development schedules across ship classes and 

find opportunities for common product line 

solutions to shared operational needs. PLSE 

makes use of the same systems engineering 

techniques and strategies that have become 

familiar in complex software-intensive combat 

systems engineering projects. What makes PLSE 

unique is that it widens the aperture of what is 

considered a system to include an entire product 

line rather than just a single ship class. While each 

program follows the systems engineering “V” in 

order to develop its unique products, PLSE applies 

across all programs to identify commonality in 

system-level requirements and define common 

architectural approaches, common interfaces, 

and component-level requirements for common 

solutions to those system-level requirements. 

During each individual combat system ACB 

execution phase, close coordination between the 

program-specific and cross-program systems 

engineering efforts must be maintained to ensure 

that all components are being developed based on 

the common architecture framework and that all 

components will come together as a system.

Product Line Systems 

Engineering

In order to better enable component reuse 

across ship class combat systems, PEO IWS has 

defined a combat system product line software 

architecture that consists of software components, 

their interfaces and allocated functionality, 

and the underlying data models that define the 

data they manage and exchange. A conceptual 

description of this product line architecture 

is defined in an Architecture Description 

Document (ADD). The ADD defines the software 

architecture to the level that describes the 

components and component interfaces the Navy 

will control to achieve product line commonality. 

A description of major functional responsibilities 

of each domain is provided in Figure 2.

To support product line engineering efforts, 

an overarching Combat System Architecture IPT 

is led by the PEO IWS Combat System Architect. 

The Combat Systems Architecture IPT maintains 

the product line architecture, as defined in the 

ADD, develops and maintains the prescriptive 

architecture models and common data models 

that support common component development, 

and sponsors and oversees IPTs and working 

groups focused on defining requirements and 

interfaces for common components within the 

product line architecture. 

The Combat Systems Architecture IPT 

approves changes to the objective architecture and 

participates in configuration management boards 

for products being developed in accordance with 

the product line architecture. The ADD guides 

the efforts of Navy-led IPTs that, over time, 

further define the data models and component 

descriptions to a level that can be used for 

contractual requirements and work products. The 

common data model and component requirement 

specifications form the prescriptive definition of 

the components and their interfaces.

The PLSE concept expands the focus from a 

single program or system to identifying common 

requirements, interfaces, and implementations 

across a wider set of surface Navy combat systems. 

As each surface combat system moves toward a 

predictable, repeatable ACB development cycle, 

it becomes increasingly possible to coordinate 

capability development schedules across ship 

classes and find opportunities for common 

product line solutions to shared operational 

needs. PLSE makes use of the same systems 

engineering techniques and strategies that have 

become familiar in complex software-intensive 

combat systems engineering projects.

Summary

The ACB process is a fundamental change 

in the way that the Navy designs, develops, 

integrates, and fields combat system upgrades. 

The ACB approach allows more flexibility in 

defining combat system upgrades and provides 

an avenue to field emerging capabilities more 

quickly than before. It is the foundation of a 

cross-program, system-of-systems approach to 

systems engineering for driving commonality 

into combat system designs across ship classes. 

The ACB concept assists in migrating combat 

systems toward the end goal of the product line 
88

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

software architecture. Detailed advanced planning 

is required for this to occur, including common 

combat system requirements and common 

architectural designs. 

NSWCDD is leading the development of ACB 

and PLSE systems engineering processes and the 

generation of key products such as the Combat 

System Requirements Document and System 

Subsystem Description Document, Software 

Requirements Specifications (SRSs), common 

data model UML data definitions, autogenerated 

software code, Interface Definition Language 

(IDL), and Interface Design Description (IDD) 

documentation. The updated ACB process 

will include government-led milestone events. 

NSWCDD has a significant role in the preparation 

and conduct of these government-led milestones, 

pioneered through the Aegis ACB 12 program.

Figure 2. Product Line Architecture Partitioning

EXTERNAL COMMUNICATIONS 

DOMAIN

• Provide Secure and Non-secure Voice / 

 Data Communications

• Perform Link Management and Data 

 Forwarding

• Control / Monitor Comms Devices and 

 Route Data Among Them

• Report Comms Status and Effective 

 Throughput

SENSOR MGMT DOMAIN

• Manage and Control Sensors

• Search / Detect Objects in Background 

 Environment

• Transition to Track Targets

• Report Target Measurement, Track, and 

 Attribute Data

• Assess and Correct Measurement

 Errors / Biases

• Report Sensor Status and Capabilities

INFRASTRUCTURE DOMAIN

• Provide Computing, Security, and 

 Network Services for Applications

• Monitor and Control Computing 

 Environment Resources and Report 

 Status

NAVIGATION DOMAIN

• Provide Fused Navigation Data

• Coordinate Ship Movement Requests 

 with the Bridge Control Systems

• Monitor Navigation and Time Data

• Provide Digital Nautical Charts and 

 Geospatial Data

DISPLAY / USER INTERFACE 

DOMAIN

• Display Data (e.g., Tracks, Tactical 

 Situation, Operational Readiness)

• Provide Set of Common Display Services 

 and Frameworks for Applications

• Support Variety of Display Services

• Display Alerts and Status

• Process Operator Actions

• Provide Common / Consistent GUIs 

 Across Platforms

• Provide Visualization Tools WEAPON MGMT DOMAIN

• Process Engagement Orders

• Compute Threat Engageability

• Confirm Weapon Availability

• Select Weapons and Schedule 

 Engagements

• Initialize / Control Weapons

• Monitor Engagement Status

• Monitor / Control Missiles in Flight

• Assess Engagement Effectiveness / Kill

• Report Weapon and Engagement Status

VEHICLE CONTROL DOMAIN

• Launch, Recover, and Control Manned Air 

 Vehicles (Fixed Wing and Helo)

• Deconflict Maneuver Space / Maintain 

 Safety

• Control Manned Small Boats

• Control Unmanned Vehicles (Air, Surface, 

 and Undersea)

• Manage Links to Controlled Vehicles

TRAINING DOMAIN

• Provide Simulated Training Environment

• Script and Execute Training Scenarios

• Simulate System Inputs IAW Scenario

• Control Training Configuration and Events

• Capture Training Assessment Data

• Playback Training Results and

 Debrief Crew

• Provide Simulated Ship

 Position / Movement

• Maintain Training Record

SUPPORT DOMAIN

• Evaluate Overall Ship Readiness

• Provide Data to Fleet Logistics Systems 

 and Distance Support

TRACK MGMT 

DOMAIN

• Create 

 Composite / 

Tactical Track 

 File

• Contribute to 

 Operational 

 Picture

• Determine Track 

 ID

• Resolve ID 

 Conflicts

• Integrate Multiple 

Track Data 

 Sources

• Perform Geodic 

 Registration

• Distribute Track 

 Data According 

 to Need

COMBAT 

CONTROL 

DOMAIN

• Control Tactical 

 Doctrine

• Evaluate Threats

• Evaluate Tactical 

 Options

• Determine COA

• Plan Missions

• Assess Mission 

 Effectiveness

• Synchronize 

 Cross-domain 

 Execution

• Provide Decision 

 Aids for 

 Operators
89

Advanced Capability Build Concept in

 Product Line Systems Engineering

Advanced Capability Build Concept in

 Product Line Systems Engineering

Advanced Capability

Build Concept

Product Line Systems Engineering

ACB
90

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

ZUMWALT (DDG 1000) Combat System Integration 

Aboard the Self Defense Test Ship (SDTS)

by Eric Sarabia and Alfredo Gabertan

The first large-scale integration of the Zumwalt-class destroyer (DDG 1000) 

combat system into a sea-based test environment will culminate in multiple firings 

of live ordnance against threat-representative targets. The live-firings of Evolved 

Sea Sparrow Missiles (ESSM) will require the integration of the Zumwalt-class 

destroyer’s combat system with the U.S. Navy’s unique test asset, the unmanned, 

remote-controlled Self Defense Test Ship (SDTS). The SDTS is shown in Figure 1. 

The integration effort will enable the SDTS to demonstrate the effectiveness of the 

U.S. Navy’s next generation, multimission destroyer combat system. 

The Program Executive Office for Integrated Warfare Systems, Program Executive 

Office Ships, and the Naval Sea Systems Command (NAVSEA) are teaming with 

industry to demonstrate the capability of the Zumwalt-class combat system to defeat 

stressing Anti-Ship Cruise Missile (ASCM) threats in an at-sea environment through 

Integrated Testing (formerly referred to as a combined Developmental Test (DT)/

Operational Test (OT) Air Warfare (AW) Ship Self-Defense (SSD) event) conducted 

on the SDTS. The Integrated Test is a requirement of both the Capstone Enterprise 

AW SSD Test and Evaluation Master Plan (TEMP) 1714, and DDG 1000 TEMP 1560 

analysis of data collected from ESSM live firings against an ASCM threat will provide 

validation data for the Probability of Raid Annihilation (Pra) Test Bed federation of 

models. Validation of these models is a necessary step in determining if the Zumwaltclass destroyer combat systems performance meets the TEMP Key Performance 

Parameter (KPP) for ASCM engagement.
91

ZUMWALT (DDG 1000) Combat System Integration 

Aboard the Self Defense Test Ship (SDTS)

SDTS Platform

The SDTS has evolved from four generations 

of various decommissioned Navy ships. The 

at-sea configuration supports remote control 

operations. The current platform is based on the 

decommissioned Spruance-class destroyer ExUSS Paul F. Foster (EDD 964). 

During typical operations, test targets 

simulating ASCMs are launched against the 

SDTS and the combat or weapon system being 

tested responds in defense of the ship. The 

predetermined attack is actually aimed at a decoy 

barge pulled behind the SDTS to protect the 

ship and its assets while still providing a threatrepresentative flight profile and engagement 

timeline. Manned live-fire test operations typically 

require a minimum Closest Point of Approach 

(CPA), which is dictated by range safety, at a much 

greater CPA than that able to be used during an 

unmanned SDTS test event. This larger manned 

test CPA offset results in unrealistic crossing 

target profiles and reduced engagement windows 

for ship self-defense tests. Figure 2 provides a 

visual comparison of flight profiles offered by the 

CPA of the SDTS versus that of a manned test 

engagement. 

SDTS Integration 

The effort to integrate a part of the Zumwaltclass destroyer’s combat system onto the SDTS 

started in 2007 with a definition of the subset of 

equipment required to test DDG 1000 air defense 

capabilities in a realistic threat environment by 

detecting the threat, processing targeting data, 

and executing an engagement. The AN/SPY-3 

radar installed on SDTS will detect the target and 

provide target illumination and ESSM midcourse 

guidance to support engagement. Target data will 

be processed by the Cooperative Engagement 

Processor (CEP). The SDTS CEP will be a 

Zumwalt-class production asset connected to 

the Total Ship Computing Environment (TSCE) 

through a Distributed Adaptation Processor 

(DAP). Using tactical software, the TSCE will 

control the engagement. The targets will be 

engaged with ESSMs launched from a Mk 41 

Vertical Launch System (VLS) outfitted with 

DDG 1000 unique Mk 57 electronics. Unique 

integration challenges facing the team included 

incorporating the Zumwalt-class combat system 

along with both legacy and current combat 

systems onboard the SDTS that support other 

Department of Defense programs.

Figure 1. SDTS, the Decommissioned Spruance-Class Destroyer Ex-USS Paul F. Foster (EDD 964) 

Under Way In Support of the AN/SPY-3 Engineering Development Model (EDM) At-Sea Testing, 2006 
92

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

An installation study recommended that 

the SDTS could be modified by installing an 

enlarged hangar extension that would support 

the majority of the Zumwalt-class equipment 

housed in Electronic Module Enclosures (EMEs) 

as depicted in Figure 3. 

AN/SPY-3

A complete SPY-3 radar set is composed of 

three array faces providing 360-degree coverage 

aboard DDG 1000. These arrays are supported 

by two X-Band Receiver Exciters (REXs), four 

IBM P6 computers, the Common Array Cooling 

System (CACS), and the Common Array Power 

System (CAPS). The IBM P6 computers are 

housed in the EMEs along with Distributed 

Adaptation Processors (DAPS). To support testing 

on the SDTS, only a single array face, a single 

REX, CAPS CACS, and two of the four IBM P6 

Computers for the SPY-3 radar were required to 

be installed and integrated to meet the TEMP 

1714 and TEMP 1560 test requirements. 

The ship power from the SDTS is 440 volts 

alternating current (VAC), 3-phase, vice the 

Zumwalt-class destroyer’s 4160 VAC, 12-phase. 

Integration of the SPY-3 CAPS required the 

analysis of several power conversion design 

alternatives. The most cost effective alternative 

was to bypass and eliminate the CAPS’s Power 

Distribution Unit while supplying 440 VAC, 

12-phase, directly to the CAPS’s Aperture Power 

Raft via a COTS transformer. This transformer 

converts the ship’s 3-phase to the required 440 

VAC 12-phase.

Figure 2. Visual Comparison of Unmanned SDTS CPA vs. Manned Test CPA 

NOT TO SCALE
93

ZUMWALT (DDG 1000) Combat System Integration 

Aboard the Self Defense Test Ship (SDTS)

Navigation Data Distribution 

Extension (NAVDDX) 

The Zumwalt-class TSCE relies on the 

navigation data provided by NAVDDX and an 

interconnected navigation suite of sensors, (e.g., 

Inertial Navigation System (INS) and Global 

Positioning System (GPS)). However, the SDTS 

utilizes the Navigation Sensor System Interface 

(NAVSSI) AN/SSN-6(V) for satisfying combat 

system navigation data requirements. NAVSSI 

provides processing and distribution of highly 

accurate positioning, navigation, and timing 

(PNT) data to combat system users. PNT data 

is based on external system interfacing with 

shipboard sensors, INS units, and GPS antennas/

receivers. 

It was determined to be both impractical 

and expensive to port the entire Zumwaltclass navigation suite onto the SDTS platform. 

Overall, NAVDDX employs the same type of 

functionality as NAVSSI, but both systems 

have very different equipment interface 

architectures and different message output 

formats to combat system users. The engineering 

challenge was to design a hardware/software 

solution for NAVDDX that leveraged NAVSSI 

and the existing sensor suite, INS units, and 

GPS antennas, while retaining the tactical 

functionality of both the Zumwalt-class and 

the existing SDTS combat systems. Raytheon 

and government engineers collaborated and 

engineered a viable solution that allowed NAVSSI 

to relay the existing navigation suite data to 

NAVDDX by utilizing a compatible network 

interface (i.e., reflective memory) between the 

two systems. The AN/WSN-7 remains connected 

to NAVSSI as it normally is on the SDTS without 

modification. This solution for integrating 

NAVDDX on the SDTS was approved through 

a Critical Design Review. The solution helped 

to eliminate functional duplication and reduce 

overall program costs.

Vertical Launching System (VLS)

A commissioned Zumwalt-class destroyer 

will include the new Mk 57 Vertical Launching 

System (VLS) in its design. The SDTS has 

the current generation Mk 41 VLS installed. 

Both, the Mk 57 and the Mk 41 are capable of 

launching ESSMs. The government/industry 

team determined that it would be more cost 

effective for the SDTS to employ a hybrid Mk 41/

Mk 57 utilizing the Mk 41 mechanical structure 

for gas management and the Zumwalt-class 

unique Mk 57 electronics to control the launcher 

Figure 3. SDTS Zumwalt-Class Equipment Placement
94

Combat Systems Engineering & Integration

Platform-Level Systems Engineering

and provide a Mk 57 representative end-toend launch. The selected Mk 57 components 

consisted of Mk 57 VLS Module Controller 

Units, Mk 57 Hatch Controller Units, Mk 57 

Canister Electronic Units, and modified Mk 57 

Hatch Actuator Units (HAU), referred to as 

Hybrid Hatch Actuator Units. Using these Mk 57 

components during the test events enables the 

launcher to communicate with the Weapon 

Control Element (WCE) software within TSCE. 

The hybrid system provides the functionality to 

select the launch ESSM against ASCM threats. 

Another integration challenge involved 

determining the optimal placement of the VLS 

with respect to the single SPY-3 radar array on 

the SDTS. Because of the limitations of having 

only a single MFR array face, the Mk 41 VLS 

was relocated to the aft end of the ship to place 

it in close proximity to the radar field of view to 

support ESSM engagements requirements. 

Test Ship Remote Control 

Network (TSRCN)

The SDTS version of the Zumwalt-class 

combat system will be integrated with the 

existing TSRCN. The TSRCN will enable remote 

control of the Zumwalt-class combat system on 

the SDTS through an encrypted radio link which 

will connect the Local Area Network (LAN) on 

the SDTS with the LAN at the Remote Control 

Center (RCC), located in the Surface Warfare 

Engineering Facility (SWEF) at Naval Surface 

Warfare Center, Port Hueneme Division (NSWC 

PHD). 

The test team will control the combat 

system through Common Display System (CDS) 

stations. Two CDS stations will be onboard 

the SDTS to support in-port verification tests 

and tracking exercises. The CDS interface will 

be accessed remotely by consoles on shore at 

SWEF. This will be done by transferring the 

CDS Graphical User Interface (GUI) on the 

SDTS to a commercial off-the-shelf (COTS)-

based client station at the SWEF. The CDS’s dual 

display, touch pads, trackball, and keyboard will 

be emulated on the client station, giving the test 

team control of the combat system, VLS, CEC, 

and SPY-3. 

In order to safely integrate the Zumwaltclass combat system into the TSRCN, the test 

team will define system behavior in the unlikely 

event of a loss of remote control. Remote control 

safety features will be provided, such as a loss 

of RF link fail safe, to disable the radar and 

weapon systems in case of communications 

failure and Arm Lock to keep the combat system 

armed and able to fire for a set period of time 

in the event of a loss of link once the target is 

committed. The fail-safe will be built into the 

system by integrating an Arm Lock function 

into the Remote Control Interface Unit (RCIU). 

Under normal conditions, the RCIU supports 

remote control of the system. Arm Lock will 

represent a user entered state that will keep the 

system armed for a set period of time. Once the 

time expires, the systems will automatically go 

to safe mode. At this point, the user will be able 

to cancel or extend Arm Lock. Provisions for 

onboard security and data collection/recording 

also will be addressed. 

SDTS Testing Way Ahead

The Zumwalt hardware installation plans 

and methods aboard the SDTS are considered as 

permanent installations. However, the flexibility 

to integrate with future combat systems such as 

the CVN 78 Gerald R. Ford-class aircraft carrier 

combat system for planned Enterprise testing 

was retained. 

The effort to integrate the advanced 

mission capabilities that give the Zumwalt-class 

destroyer unprecedented versatility in a variety 

of operational environments on the SDTS will 

culminate with numerous ESSM firings against 

an array of threat-representative targets and 

flight profiles. Successful integration of the next 

generation of surface ship combat systems and 

the ability to test in as realistic an environment as 

possible will result in lower risk, characterization 

of system performance, and the mitigation of 

significant issues before being introduced to the 

Fleet. Through collaboration, a NAVSEA and 

industry team is meeting the challenge to ensure 

that sailors onboard the DDG 1000 Zumwaltclass destroyer will be armed with safe, effective 

combat systems. 
95

ZUMWALT (DDG 1000) Combat System Integration 

Aboard the Self Defense Test Ship (SDTS)

ZUMWALT (DDG 1000) Combat System Integration 

Aboard the Self Defense Test Ship (SDTS)

Spruance-Class Destroyer,

Ex-USS Paul F. Foster (EDD 964)

95
96

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Architecture Development for Shipboard 

Combat Systems 

by Diana Kolodgie, Alvin Murphy, and Terence Sheehan

The Naval Surface Warfare Center, Dahlgren Division (NSWCDD), leads 

the Navy’s development and use of architectures for engineering surface 

shipboard combat systems. Architectures are used to define the integrated roles, 

responsibilities, and functions of systems for large-scale, complex battle forces. 

The Institute of Electrical and Electronics Engineers (IEEE) Standard 1471-2000 

defines architecture as: “The fundamental organization of a system embodied in 

its components, their relationships to each other, and to the environment, and the 

principles guiding its design and evolution.”

The Navy employs the Department of Defense (DoD) Architecture Framework 

(DoDAF) for developing and representing architecture descriptions that ensure a 

common denominator for understanding, comparing, and integrating architectures 

across organizational, joint, and multinational boundaries. DoDAF establishes 

data element definitions, rules, relationships, and a baseline set of products for 

consistent development of integrated or federated systems architectures. These 

architecture descriptions may include families of systems (FoSs), systems of systems 

(SoSs), and net-centric capabilities for interoperating and interacting in the netcentric environment (NCE).1

 DoDAF supports the development of interoperating 

and interacting architectures by defining three related views of architecture: 

Operational View

Systems and 

Services View

Technical 

Standards View
97

Architecture Development for Shipboard Combat Systems 

Operational View (OV), Systems and Services 

View (SV), and Technical Standards View (TV). 

Each view is composed of sets of architecture 

data elements that are depicted via graphic, 

tabular, or textual products. Information 

linkages among architectural views are shown in 

Figure 1.2

NSWCDD Architecture 

Experience 

NSWCDD systems engineers use DoDAF 

architectural standards for communication 

between the operational and acquisition community, as well as for supporting system development. Architecture development is an iterative 

process and continuous evaluation of the views 

must occur throughout development. Upon 

completion of DoDAF views, an evaluation, 

to include traceability to requirements and 

stakeholder review, must be performed to ensure 

consistency among all views. 

DoDAF defines a six-step process to ensure 

the developed architecture is fit-to-purpose:3

1. Determine intended use of architecture

2. Determine scope of architecture

3. Determine data required to support architecture development

4. Collect, organize, correlate, and store architectural data

5. Conduct analyses in support of architecture objectives

6. Present results in accordance with decision-maker needs

The architectures for surface platforms and 

their subsystems are first documented within 

a system Capability Development Document 

(CDD). A CDD captures the information 

necessary to develop a proposed program, 

normally using an evolutionary acquisition 

strategy. The CDD outlines an affordable 

increment of militarily useful, logistically 

supportable, and technically mature capability.4

To function most effectively, the realized 

systems architecture must maintain a connection 

to the CDD architecture, requiring that the 

system architects and CDD architects have 

clear and consistent process associations and 

relationships. In recent years, the surface 

platform community has built relationships 

with CDD architects who have facilitated the 

maturing of architecture products through 

the systems engineering process, rather than 

replacing those products with unique systems 

engineering products.

While the CDD provides high-level system 

architecture within the context of other DoD 

acquisitions, a System/Subsystem Design 

Description (SSDD) provides system-level 

architecture details. The SSDD describes the 

system- or subsystem-wide design and the 

architectural design of a system or subsystem.5

As depicted in Figure 2, which was adapted 

Figure 1. Information Linkages Among Architectural Views
98

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

from Defense Acquisition University (DAU) 

Systems Engineering Handbook 2001, the SSDD 

documents the results of a systems engineering 

analysis of operational requirements and the 

force-level architectures from the CDD.6

 The 

SSDD provides the allocation of top-level 

requirements, functions, and interfaces to 

system elements, components, and software. 

A surface platform may have multiple SSDD 

documents for each major system element. 

Historically, prime contractors have developed 

SSDD documentation; however, the surface 

community is moving toward governmentdeveloped, top-level architectures to facilitate 

product line alignment of enterprise systems. 

This approach supports delivery of common 

product line components across combat systems 

with common functions.

NSWCDD Example Use of DODAF 

for a Notional System

NSWCDD engineers are at the forefront 

of systems engineering and architecture 

development. Their experience spans decades. 

Based on lessons learned from previous surface 

platform architecture development efforts, 

systems engineers have learned that it is best 

to simplify the design for both usability and 

readability to effectively evaluate and analyze 

the effectiveness and completeness of the 

architecture. What follows is an example use of 

DoDAF for a notional system, USS Dahlgren, 

to illustrate the content of various architecture 

views and products. The example begins with 

mission threads.

Mission Threads

Mission threads provide specific scenarios, 

environmental conditions, and event sequences 

for a set of missions. It provides the context 

for operational activities and operational 

event-trace description diagrams. An example 

of a surface warfare thread for the notional 

USS Dahlgren example is provided below: 

USS Dahlgren receives notification from 

Combined Task Force (CTF) 151 CounterPiracy Operations that pirate activity within 

the USS Dahlgren Area of Responsibility 

(AOR) has recently escalated, and attacks 

on commercial shipping are imminent. 

USS Dahlgren processes recent AOR piracy 

intelligence and undertakes planning to 

search for and neutralize the pirate threats. 

Planning is coordinated with USS Dahlgren Air and Ship Control Operations to 

establish voyage and search plans for the 

mission. Plans are reported to CTF 151 and 

Figure 2. Systems Engineering Process
99

Architecture Development for Shipboard Combat Systems 

USS Dahlgren coordinates with the Joint 

Force Maritime Component Commander for 

authorization to proceed. Prior to mission 

commencement, USS Dahlgren coordinates 

with Naval Support Operations for required 

resource and supplies. Once pirates have 

been localized, USS Dahlgren assesses potential threats for hostile intent. If deemed 

hostile, USS Dahlgren determines which 

weapons to employ—nonlethal, guns, missiles, and/or unmanned air system—based 

on threat characteristics. Once engaged, 

USS Dahlgren will assess effectiveness and 

reengage as necessary to neutralize the pirate 

threat.

Overview and Summary 

Information (AV-1)

Overview and summary information (AV-1) 

provides a planning guide to define the who, 

what, when, why, and how for the project. An 

example is shown in Table 1. Additionally, AV-1 

provides the context in which the architecture 

exists, i.e., assumptions and constraints, 

publication and development status, schedule, 

and milestones.

Integrated Dictionary (AV-2)

The integrated dictionary (AV-2) creates a 

common vocabulary for integrated architecture 

development. The goal is to ensure data elements 

are uniquely defined and commonly linked 

across all operational and system views. This 

approach provides a common denominator 

for understanding and comparing views across 

mission areas to aid stakeholders in the decisionmaking process. 

Operational View (OV) Products

The next step in architecture development 

is to define the operational architecture using 

operational views (OVs). The OVs are directly 

related to the operational requirements and 

concept of operations provided by the OPNAV. 

OVs, as described in Table 2, depict the nodes, 

tasks, and activities performed by USS Dahlgren

and the internal and external resource flows to 

accomplish the mission. Additional operational 

views, not depicted, are included in DoDAF to 

assist in the architectural description. 

As illustrated in Figure 3, the OV 

development begins with a High-Level 

Operational Concept Graphic OV-1, which 

provides a graphical representation of 

USS Dahlgren’s missions, environment, and 

interactions with external nodes. 

System View (SV) Products

Development of system views typically 

occurs as part of the systems engineer’s functional 

analysis and allocation activity. SysML, which 

Table 1. Initial AV-1 (Notional System)

Architecture Description Identification:

Name: USS Dahlgren

Organization developing the architecture: NSWCDD

Approval authority: Office of the Chief of Naval Operations (OPNAV)

Scope: Architecture View(s) and Product Identification:

• AV-1, AV-2

• OV-1, OV-2, OV-4, OV-5, OV6c

• SV-2, SV-4, SV-5, SV-6, TV-1

Purpose and Perspective:

Provide a sample architecture based on lessons learned

Context:

USS Dahlgren is a surface combatant to be designed and built specifically to search for and deter pirate 

ship activity. The platform is equipped with an AN/SPY-3 radar for surveillance. A Non-Line of Sight Launching 

System (NLOS-LS) provides the capability to engage pirate threats. A Vertical Takeoff Unmanned Vehicle 

provides surveillance, reconnaissance, and targeting capability. When transiting in and out of port, 

USS Dahlgren uses a Shipboard Protection System to protect the ship’s force.

Tools:

System Architect, MagicDraw
100

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Operational View Description

OV-1

High-Level Operational Concept 

Graphic

Graphical representation of missions, environment, and 

interactions with external nodes

OV-2

Operational Resource Flow 

Description

Illustrates the need to exchange information between nodes 

and/or resources

OV-4

Organizational Relationships Chart

Depicts key players, their command structure, and their 

relationships

OV-5a / OV-5b

Operational Activity Decomposition 

Tree / Operational Activity Model

Integrated summary of all operational activities and their input 

and output flows

OV-6c

Event-Trace Description

Illustrates the dynamic behavior of operational activities by 

depicting the timing and sequence of events

Table 2. Minimum Required Operational Views

Figure 3. USS Dahlgren High-Level Operational Concept Graphic—OV-1
101

Architecture Development for Shipboard Combat Systems 

represents Object Management Group (OMG) 

Systems Modeling Language (SysML) standards, 

provides a framework for the required systems 

engineering activities, while providing views 

that satisfy DoDAF SV requirements. Table 3 

summarizes the relationship between system 

views and SysML products.

The initial definition of a system functional 

architecture traces operational activities 

to system functions. These functions are 

documented in a DoDAF Systems Functionality 

Description (SV-4a). Each operational activity 

in the OV-5/6c products may yield one to many 

mappings to functions in the SV-4a in order 

to realize the required system capability. This 

mapping is depicted in an Operational Activity 

to Systems Function Traceability Matrix (SV-5a). 

For example, the “Fire Missile” activity in an OV5/6c may require “Initialize Missile” and “Launch 

Missile” functions in an SV-4a. This relationship 

is usually depicted in a matrix with the initial 

functional hierarchy depicted in a tree. Figure 4 

provides a sampling of operational and system 

views developed for USS Dahlgren. 

Application of the Architecture

Once the USS Dahlgren architecture is 

defined, engineers need to address how the 

architectural products will be used in the combat 

systems engineering and acquisition effort. 

Operational architecture products are part of the 

“contract” between the operational fleet forces 

and the combat system engineers describing 

how the system will be used in various realworld scenarios. System architecture products 

define the physical and functional instantiation 

of the combat system required to provide 

the operational capabilities at the required 

performance levels. The system architecture can 

be used to determine the development cost to 

migrate from existing program of record combat 

systems to the objective design. 

Moreover, the surface Navy has been 

actively transforming from the acquisition 

of independent platforms to a product line 

approach to provide maximum mission 

capability across multiple platforms within 

budgetary constraints. The combat systems 

engineers, therefore, need to identify 

opportunities for implementing existing product 

line components within the system architecture. 

For new components, system architecture 

should be defined in terms of concordance to the 

product line architecture to the extent possible 

to provide the best return on investment to 

the Navy Enterprise. Operational architecture 

mission threads should be very similar regardless 

of which ship classes are fielding the systems and 

conducting the missions. 

In fact, it is desirable to fight missions 

similarly and consistently across classes to 

improve interoperability, mission coordination, 

and training. A common repository of 

system views and tools with standardized 

Table 3. System View Descriptions

System View Description SysML Approach

SV-2

Systems Resource Flow 

Description

A description of resource flows 

exchanged between systems SysML Internal Block Diagrams (IBD)

SV-4

Systems Functionality 

Description

The functions performed by systems 

and the system data flows among 

system functions

SysML Activity Diagrams or modeled activity 

hierarchy tree using a Block Definition 

Diagram (BDD)

SV-5

Operational Activity 

to Systems Function 

Traceability Matrix

A mapping of system functions back 

to operational activities

A table of activity diagram actions mapped to 

OV-5/6c activities. May require modifications 

to SysML tool database schema to automate 

generation.

SV-6

Systems Resource Flow 

Matrix

Provides details of system resource 

flow elements being exchanged 

between systems and the attributes 

of that exchange

A table of item flows depicted on the SysML 

IBDs. Items may be modeled as blocks in a 

BDD.
102

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Figure 4. USS Dahlgren Systems Engineering Products
103

Architecture Development for Shipboard Combat Systems 

system functions, functional definitions, and 

standardized messages and message exchange 

implementations best serves this purpose.

Conclusion

The USS Dahlgren example illustrates 

how NSWCDD systems engineers employed 

DoDAF to create useful products for defining 

a shipboard combat system that operates 

within complex battle forces and satisfies 

stakeholder requirements. Architecture 

provides the foundation for defining combat 

systems implementation, as documented in the 

SSDD, which can be traced back to the user’s 

requirements invoked in the operational views. 

By designing and developing architecture using 

the DoDAF construct, surface Navy warfighters 

will benefit considerably from NSWCDD’s 

systems engineered shipboard combat systems 

necessary for 21st century naval missions and 

operations.

References

1. ACQuipedia, DoDAF; https://acc.dau.mil/CommunityBrowser.

aspx?id=250150; accessed 18 Nov 2010.

2. Ibid.

3. DoD Architecture Framework (DoDAF) Version 2.0, 28 May 2009.

4. ACQuipedia;https://acc.dau.mil/CommunityBrowser.

aspx?id=28825&lang=en-US; accessed 18 Nov 2010.

5. Acquisition Community Connection; https://acc.dau.mil/CommunityBrowser.aspx?id=59129&lang=en-US; accessed 18 Nov 

2010.

6. DAU, Systems Engineering Fundamentals, 2001.

Operational View

Systems and 

Services View

Technical 

Standards View

103

Architecture Development for Shipboard Combat Systems 
104

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Technology Integration and 

Assessment Capability

by Darren C. Barnes, Neil T. Baron, and Jerry W. Oesterheld

RDT&E 

Network

TIAC

Dahlgren, Va.

DREN /

SDREN

IWSL (Aegis) Tomahawk Gun Range

San Diego

Camp

Pendleton

Huntsville Charleston

104

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering
105

Technology Integration and Assessment Capability

The integrated Naval Strike Force, made up 

of tens of combat systems, hundreds of weapon 

elements, and thousands of components desiring 

commercial-like computing with Internetlike access and yet the unwavering discipline 

required for the use of deadly force, puts great 

demands on the engineering and integration 

realm. Speed of evaluation, consistency of the 

evaluation framework, and the mere ability to test 

components within a highly integrated systemof-systems (SoS) environment were challenges 

that had to be overcome to consistently evaluate 

and field force-level warfighting capabilities. The 

core of a Technology Integration and Assessment 

Capability (TIAC) was established at Naval Surface 

Warfare Center, Dahlgren Division (NSWCDD), 

to begin serving these functions.

With the advent of the Navy’s open 

architecture technical and business strategy for 

the development of combat systems, the need 

for an independent evaluation facility for thirdparty product development was recognized. In 

response to this need, NSWCDD christened its 

Open Architecture Test Facility (OATF) in July 

2003 to provide an independent site for evaluation 

and certification of products to open architecture 

standards. Subsequently, to be more responsive to 

the pace of the Navy’s Advanced Capability Build 

(ACB) upgrade process administered through its 

Program Executive Office for Integrated Warfare 

Systems (PEO-IWS), it was further recognized 

that the OATF concept had to evolve and expand 

into an integrated laboratory environment where 

science and technology (S&T) products under 

development could interact more easily and 

regularly within existing combat systems architectures. This was needed to verify and validate 

proposed capabilities prior to a program decision 

to advance products under development into a 

program of record (POR). Additionally, the regular 

nature of a two-year development cycle, coupled 

with a more flexible research and development 

evaluation facility, was envisioned as a way to 

quicken the delivery of capability to the Fleet. 

Accordingly, NSWCDD established the TIAC as a 

mechanism to address specific SoS technology and 

architectural engineering challenges and time-tomarket fielding demands by the Fleet.

TIAC Overview

TIAC provides an instrumented, dispersed, 

command and control (C2) laboratory 

environment that interconnects individual warfare 

development laboratories into SoS constructs 

able to represent entire ships or groups of ships 

prosecuting a warfighting scenario. With the 

explosion of information technology into every 

aspect of the C2 functions of combat systems and 

Radar Lab(s) C2 Labs

Command & Control

UXV Integration 

Facility

Marine Corps Lab

105

Technology Integration and Assessment Capability
106

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

warfighting SoS architectures, it became apparent 

to laboratory leadership that a focused effort 

to integrate disparate facilities would provide 

critical capabilities to the laboratory’s mission to 

perform integration engineering functions at all 

levels of the systems engineering hierarchy. TIAC 

started as a single laboratory within NSWCDD’s 

Integrated Warfare Systems Laboratory (IWSL) 

complex, and is now expanding to include other 

C2 and computer laboratories for distributed 

experimentation and testing (on site and off 

site). The overall intent of the TIAC is to gain 

early (prior to a fielding decision) insight into 

technology integration into SoS environments, 

support value engineering activities, and reduce 

total ownership costs. (Value engineering 

analyzes the functions of a program, project, 

system, product, item of equipment, building, 

facility, service, or supply of an executive agency, 

performed by qualified agency or contractor 

personnel, to improve performance, reliability, 

quality, safety, and life cycle costs.) 

TIAC’s Mission

The mission of TIAC is to:

•	 Provide an independent evaluation environment with hardware-in-the-loop 

(HWIL) and simulation/stimulation to 

support warfighting system developments 

up to the Strike Force level. 

•	 Exploit the facilities and subject-matter 

expertise at the laboratory to enable architectural alignment of engineering developments and synchronize science and 

technology capability development into 

main stream program developments. 

TIAC’s Three Main Objectives

1. Provide an innovation center for 

industry, small business, academia, and 

naval and joint government laboratories 

enabling affordable and efficient C2 

technology integration and unbiased 

technological assessments into combat 

systems, ships, and naval forces within 

realistic operational warfighting 

scenarios. 

2. Provide local federated facilities and 

connectivity (multiple networks and 

venues) in an unbiased, government 

facility to connect innovative 

solutions with laboratory simulations, 

stimulations, and HWIL representations 

of combat systems of today’s Navy, the 

next Navy, and the Navy after next.

3. Effectively manage ever-changing security 

requirements for information assurance 

(IA) that burden control system laboratories by enabling prioritization of resources 

aligned to planned laboratory needs and 

strategic proposals for experimentation, 

evaluation, and assessment. 

TIAC Components

Core TIAC components consist of local 

connectivity, a robust modeling and simulation 

(M&S) environment, both operational view (OV) 

and system view (SV) architectures, local and 

global connectivity, and a robust IA environment. 

These TIAC components are represented in 

Figure 1.

Local connectivity enables different systems 

housed in local, unique, tactical laboratories at 

NSWCDD to be brought together into one virtual 

laboratory environment, thereby increasing the 

ability to represent a complex SoS environment. 

A representative list of laboratory facilities and 

capabilities includes the following: 

•	 Tomahawk Weapon System

•	 Surface Electronic Warfare Improvement 

Program

•	 AN/SLQ-32 Electronic Warfare System

•	 Aegis Weapon Control

•	 Aegis Command and Decision, Cooperative 

Engagement Capability laboratories

•	 Marine Corps’ Common Aviation 

Command and Control System (CAC2S)

•	 Systems Integration Laboratory (SIL)

•	 Radar and Sensor laboratories, including 

AN-SPY-1 and Ground/Air Tasking 

Oriented – Radar (G/ATOR)

•	 Human Systems Integration (HSI) 

laboratories 

Well-planned and properly configured local 

connectivity enables TIAC to represent an 

integrated test bed immediately for either S&T 

integration and assessment or early system 

integration assessments. The integrated test 

bed better represents the final operational 

environment of integrated elements operating 

synergistically in a combat system or an SoS 

framework. Local connectivity requires close 

cooperation, not only in technical areas, but 

also in coordination of M&S environments to 

reflect desired system environments. HWIL and 

threat and environmental simulations must work 

seamlessly within SoS mission threads (plandetect-control-engage-assess) to maximize the 

SoS realism and the effective capture of relevant 

engineering artifacts from the elements. Local 
107

Technology Integration and Assessment Capability

connectivity also supports the integration of IA 

and security aspects, an area that continues to 

expand as the commercial computer information 

security domain continues its Moore’s law rate 

of development. Connecting existing capabilities 

further facilitates the transition of S&T from 

inception to integration to warfighting systems. 

It also facilitates a more timely assessment of 

technologies into predefined architectural descriptions of ACBs, bringing new and improved warfighting capabilities and the exploration of naval 

and Joint system architectures into play while 

minimizing any disruption from the insertion. 

The TIAC concept, however, is not limited 

to the interconnection of locally housed systems 

within the confines of a local warfare/systems 

center laboratory. Today’s global environment 

requires the TIAC to create global connections 

to known (and yet to be known) systems beyond 

the local confines of NSWCDD. A representation 

of global connectivity is represented in Figure 2, 

showing connectivity from the Dahlgren, 

Virginia, site to other Dahlgren Division 

laboratories at Dam Neck, Virginia, and at the 

Surface Combat Systems Center (SCSC) at 

Wallops Island, Virginia. This triad of surface 

combat system facilities can then connect to other 

service, national, and international collaborators. 

Global connectivity must account for the 

same kinds of technical element-to-element and 

system-to-system interactions, but at a more 

complex level due to politics and programmatics 

spanning different organizational claimants. 

Instead of dealing with local organizations 

and networks, global connectivity requires 

cooperation and coordination among disparate 

organizations, networks, and interpretations of 

IA and security guidelines. A single commercially 

accepted Internet-based “plug-and-play” 

environment (such as you have at home with 

your personal computer) does not exist for a fully 

secure, high bandwidth, low latency national 

(international) network for military testing and 

evaluation. The global connectivity for the TIAC 

must accommodate many different and currently 

independent networks and protocols, such as:

•	 The Secure Defense Research and 

Engineering Network (SDREN), a 100-

Mbps network connection used to access 

various Department of Defense sites using 

InterTEC tools. 

•	 Missile Defense Agency (MDA) CNET, a 

100-Mbps connection using the Defense 

Research and Engineering Network 

(DREN) supporting missile defense systems 

for testing. 

•	 The Joint Mission Environment Test 

Capability (JMETC), an enterprise-level 

Live Virtual Constructive-distributed test 

capability. 

Figure 1. TIAC Components
108

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

The orchestration of these global 

connections allows the TIAC to reach well 

beyond the surface Navy environment to include 

MDA facilities and address the Navy’s role in 

national defense needs. Facilities can be joined 

to perform complex system assessments of either 

the whole architecture (including all services 

and coalition partner contributions) or the 

integration of new parts into existing complex 

environments. Likewise, connectivity enables 

integration with U.S. Marine Corps facilities, 

such as the Marine Corps Tactical Systems 

Support Activity (MCTSSA), Camp Pendleton, 

and Marine Corps Systems Command. Similarly, 

facilities for the integration of command, 

control, communications, computers, and 

intelligence (C4I) are located at Space and Naval 

Warfare Systems Command (SPAWAR) Atlantic 

(Charleston, South Carolina) and SPAWAR Pacific 

(San Diego, California) and at MDA.

Key to connectivity, both local and global, is 

to bridge together disparate laboratories to try to 

achieve a system-wide capability, which TIAC has 

demonstrated successfully in support of a Marine 

Corps command and control acquisition effort. 

TIAC Employment

As part of a proof of concept that turned 

into a successful program support tool, the TIAC 

recently supported a Marine Corps acquisition 

effort specific to complex C2 integration 

capabilities. For this application of the TIAC, the 

program office initially solicited industry solutions 

via a Request for Information, which resulted in 

responses in the form of proposed technology 

solutions to be characterized as part of a “String” 

or mission thread against a set of high-level 

performance requirements. NSWCDD provided 

the TIAC to include associated environments: 

Simulation and Stimulation, Host Combat System, 

Figure 2. TIAC Connectivity
109

Technology Integration and Assessment Capability

Component Under Test, Instrumentation Tools, 

and Post-Test Analysis Tools. Over the span of 

a few months, numerous vendors brought their 

solutions (in some cases, a fully integrated system; 

in other cases, only a small component solution) 

into the TIAC. NSWCDD and NSWC Corona 

performed assessments of each technology’s 

performance, its instrumented contribution to 

the overall mission string success, and the level of 

integration maturity into the SoS architecture. The 

TIAC approach facilitated a more streamlined and 

consistent acquisition approach and allowed the 

program office to select a best-of-breed solution 

that met warfighter needs. This proved invaluable 

to program office decision-makers as TIAC 

provided the sponsor with unbiased, government 

assessments of industry-proposed solutions in 

a fully instrumented operationally equivalent 

warfighting environment.

The Way Ahead

TIAC will grow to encompass additional C2 

laboratories across NSWCDD and by extension 

through experimentation and networking across 

the Navy warfare/systems centers and other Joint 

and coalition laboratories. Reiterating, TIAC’s goal 

is to network independent laboratories in order to 

realize a “virtual” laboratory capable of accurately 

representing the entire combat system (regardless 

of where elements are located) and the distributed 

nature of warfare at the Naval Strike Force level 

integrating and assessing current and future naval 

C2 environments. Different laboratories (local, 

national, international) can contribute to the TIAC 

mission based on warfighter and program needs. 

TIAC serves as a critical tool that enables the 

government to perform its technical integration 

and assessment role on highly integrated yet 

widely distributed systems via interconnected 

laboratories. Consequently, TIAC will expand to 

other warfare centers, systems centers, and other 

government installations to address large-scale, 

distributed, naval system and SoS development 

and fielding challenges. Ultimately, a fully 

realized TIAC will provide the environment, 

tools, and methodologies necessary to perform 

early evaluation and characterization of proposed 

technologies into a Naval Strike Force. TIAC will 

speed the integration of desired technologies 

into ship and Fleet architectures, putting critical 

capabilities into the hands of our warfighters. 

RDT&E 

Network

TIAC

Dahlgren, Va.

DREN /

SDREN

109

Technology Integration and Assessment Capability
110

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Estimating Software Development Effort 

for Future Naval Capabilities

by Terence Sheehan, Eric Rocholl, and Alvin Murphy

To keep pace with emerging threats, the Office of the Chief of Naval Operations 

(OPNAV) must ensure that warfighting capabilities are consistent with Navy needs. 

OPNAV is charged with balancing costs, schedules, and risks associated with efforts 

to meet new mission requirements, while at the same time striving to close existing 

capability gaps. In support of OPNAV decision-makers, Warfare Systems Department 

engineers at the Naval Surface Warfare Center, Dahlgren Division (NSWCDD), 

perform an integral role in the development of combat system cost estimates; this 

entails establishing architecture options, generating technical data, and quantifying 

software development effort. 

Over the years, NSWCDD engineers have leveraged multiple techniques for 

estimating software development costs. NAVSEA standard methods include analogy, 

parametric, and engineering buildup. Each method requires an estimate of the 

software development scope. This article provides an overview of a Source Lines 

of Code (SLOC)-based methodology for determining the software scope. SLOC is 

commonly used as an estimating metric since it has historically been the product 

or final output of the larger software development process that programs have used 

to report progress. Industry reports SLOC counts to the government via required 

contract deliverables. Also, the majority of Department of the Navy (DoN) software 

cost estimating models are driven by SLOC as their primary technical input. This 

article highlights ongoing NSWCDD research aimed at investigating relationships 

between other technical artifacts (e.g., system interfaces) and software development 

level of effort (LOE), in hopes of adding an alternative software cost-estimating 

technique to the toolset.

Developing quality software estimates enables OPNAV and Navy leadership to 

make informed decisions about future capability investments and required resources. 

Software development effort ultimately drives software development cost and 

schedule estimates, which are needed to properly plan, program, and successfully 

execute major defense acquisition programs. Modern combat systems derive an 

increasing portion of their overall functionality from software, therefore making 

it imperative for the Navy to accurately estimate software cost to support sound 

acquisition decision-making. 
Estimating Software Development Effort 

for Future Naval Capabilities 

111

Surface Navy Software Cost 

Estimation in Practice

To demonstrate NSWCDD’s SLOC-based 

technique for combat system software development cost estimation for new ship concepts in 

the early design stage, the following simplistic, 

fictitious scenario will be used (example and 

associated SLOC estimates are strictly to 

demonstrate the estimating technique and 

should not be misconstrued as representative 

values for any real acquisition program):

Combatant Commanders identify a capability gap in the Navy’s fire support arsenal. 

There is a need to support rapid, protected 

insertion of Marines, Army, and Navy forces 

ashore that can quickly maneuver to tactical 

objectives. Naval engineers are charged with 

designing a new ship with advanced warfighting capability to outpace ever-evolving enemy 

threats to friendly forces. The Navy needs increased, long-range firepower to counter land 

and surface targets, but at a much lower cost 

per engagement than exists in current platforms 

and weapons systems. The rising cost of fuel, 

weapon system procurement and maintenance 

demands that the Navy field more innovative, 

cost-effective warfighting systems.

Using this scenario and the notional operational concept depicted in Figure 1, NSWCDD 

combat systems engineers define weapon system 

alternatives for long-range threat engagements 

using three gun and munitions designs and 

two launching systems that support land attack 

missles. Gun and munitions design alternatives 

include:

•	 5-inch/62 caliber conventional gun with 

extended-range guided munitions

•	 Advanced gun system with long-range 

land attack projectile

•	 Electromagnetic launcher with hypersonic 

projectiles

Launching system alternatives that support land 

attack missiles include:

•	 Mk 41 Vertical Launching System (VLS)

•	 Mk 57 Advanced VLS

Weapon system alternatives are integrated 

with combat control systems to generate combat 

system alternatives, which are used for costing 

purposes. Combat system engineers, together 

with Naval Sea Systems Command (NAVSEA) 

naval architects, explore ship concepts for 

fielding these capabilities. Several notional ship 

design concepts are developed and coupled with 

combat systems alternatives to define total ship 

design concepts. The combat system part of the 

total ship design concept is further analyzed for 

performance and cost. In the example, three notional ship combat system concepts are analyzed:

1. Concept I: New destroyer-sized hull, Advanced Gun System, Mk 57 launcher

2. Concept II: New frigate-sized hull, 

5-inch/62 Gun, Mk 41 launcher 

3. Concept III: New destroyer-sized hull, 

electromagnetic launcher, Mk 41 launcher 

Figure 2 provides an example of each notional 

ship combat system concept.

Naval engineers must develop software 

integration architecture for each combat 

system alternative. Software architecture 

impacts projected for the integration of the 

electromagnetic launcher weapon system in 

Ship Concept III are shown in Figure 3. (The 

small red squares connote interfaces between 

software components that will be impacted 

by the capability integration. Conversely, the 

small white squares connote interfaces between 

software components that will not be impacted.) 

Several software components within the combat 

control system require modifications to support 

the new capability:

•	 A new electromagnetic launcher manager 

is required to control the electromagnetic 

launcher. The electromagnetic launcher 

manager must receive track data to 

support aiming the gun. Also, the electromagnetic launcher manager must provide 

display data and coordinate engagements 

with the engagement manager. The effort is 

a new software development.

•	 The engagement manager requires 

modified gun engagement logic and a new 

interface to the electromagnetic launcher 

manager. Additionally, new display data 

must be provided. This effort requires 

modification to existing software as well as 

creation of new code.

•	 The doctrine manager requires 

modifications to support selection of the 

electromagnetic launcher for engagement 

recommendations. Additionally, new 

display data must be provided. This effort 

also requires modification to existing 

software and new code.

•	 Graphical user interfaces (GUIs) must 

be developed to support new operator 

displays and interactions with doctrine, 

weapons selection, and electromagnetic 

launcher control.
112

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Figure 1. Operational Concept

Figure 2. Notional Ship Concepts
Estimating Software Development Effort 

for Future Naval Capabilities 

113

Systems engineers consider functional 

capability and information exchange 

requirements for each software component. They 

generate modified and reused code estimates 

for each component as a percentage of the 

existing total SLOC. For a new component 

(electromagnetic launcher manager), or new 

functionality within an existing component 

(doctrine manager), SLOC estimates are 

developed based upon comparison to existing 

combat system components with comparable 

functionality. Table 1 provides a summary 

of SLOC impacts to software components 

for integration of a notional electromagnetic 

launcher into the combat control system for Ship 

Concept III. 

Table 2 shows a notional SLOC estimate 

for the electromagnetic launcher integration 

in Concept III. The software data above are 

synthesized into a total estimate of new, modified 

and reused SLOC. Cost analysts then assess the 

effort associated with modifying and reusing code 

(i.e., 0.5 and 0.1), relative to the effort associated 

with developing new code (i.e., 1.0), to normalize 

the SLOC counts. 

This normalized SLOC estimate is converted 

into cost using cost estimating relationships 

(CERs) derived from historical software 

development efforts. During this conversion 

process, the effects of technological advances 

in software development processes and tools 

are evaluated. The CERs must address the full 

spectrum of software development activities (e.g., 

requirements, architecture, integration, system 

test) not just the design, code, and unit test (DCT) 

activities. 

NSWCDD Research into 

Alternative Cost Estimation 

Approaches

The above example provides a simplified 

representation of the broader scope associated 

with a full combat system capability upgrade, 

which may encompass as many as a hundred 

evaluated software components. It describes 

one technique used by NSWCDD engineers 

to quantify software development efforts for 

new capabilities; this technique scales the size 

(measured in SLOC) of a known or projected 

software component that has functionality similar 

to the software component or new functionality 

being estimated. SLOC is only one artifact of 

the overall software development effort. Figure 4 

provides an overview of activities and artifacts 

required for large-scale system-of-systems 

engineering. As system complexity varies, it is 

expected that the details, complexity and volume 

of related artifacts will also vary; however, this 

Figure 3. Notional Electromagnetic Launcher Software Integration
114

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Table 2. Notional Estimate of Software Impact for Electromagnetic Launcher Integration

Table 1. Notional Electromagnetic Launcher Weapon System Integration for Concept III

Software 

Component

Base SW 

Component Size 

(SLOC)

Description of Change % New 

SLOC

%

Modified

% Reuse 

SLOC

Electromagnetic 

Launcher Manager 145,000

Develop new software 

to add electromagnetic 

launcher manager to existing 

architecture.

100 0 0

Engage Manager 58,000

Modify software to include 

electromagnetic launcher in 

engagement logic.

20 5 95

Doctrine Manager 21,000

Update to include 

electromagnetic launcher in 

doctrine statements.

10 5 95

GUIs 15,000 Develop new display 

software. 100 0 0

Capability New SLOC Modified SLOC Reused SLOC Total SLOC

SLOC 173,700 3950 75,050 252,700

Effort Factor to 

Normalize SLOC 1.0 0.5 0.1

Normalized SLOC 173,700 1975 7505 183,180
Estimating Software Development Effort 

for Future Naval Capabilities 

115

effect is not clearly ascertained with a sharp, 

singular focus on SLOC. 

NSWCDD is leading the charge to develop 

alternatives to the traditional SLOC-based 

software-estimating approach and to expand 

the software-estimating toolset. Over the past 

year, NSWCDD engineers have been reviewing 

artifacts from existing systems to uncover 

other correlations that may provide reliable 

estimates. Initial analysis has shown that the 

number of interface messages and message 

sizes have direct relationships to integration 

complexity. Interface descriptions are developed 

early in the system engineering process and 

could offer early insight into integration costs. 

If new correlations prove robust enough to 

adopt in practice, then non-SLOC-based 

estimating approaches would ultimately have to 

be integrated with costing models that use the 

technical artifacts as input. By implementing 

modifications to existing contracts via software 

data reporting requirements, the government’s 

historical software dataset would evolve over 

time to include cost performance reporting at a 

level of detail commensurate with technical data 

reporting. 

Value Added

Delivering unmatched warfighting capabilities 

to U.S. Navy surface combatant warriors requires 

that Navy research, development, and acquisition 

organizations maximize the return on every 

taxpayer dollar. In the 21st century, systems 

that provide combat advantage will increasingly 

rely on the functionality of embedded software. 

Software acquisition programs will live or 

die based on their ability to deliver required 

functionality within allocated cost constraints. 

NSWCDD systems engineers are conducting 

leading edge research that will help the surface 

Navy leadership make cost-effective decisions 

when acquiring capabilities for the warfighter.

Figure 4. System Development Activities and Artifacts
116

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Integrated Training for Combat Systems: 

Past, Present, and Future

by Lori Skowronski

Embedded shipboard training systems are crucial to ensure our Fleet maintains 

combat readiness. Integrated combat systems team training is not a new concept for 

the Fleet; today, the Total Ship Training Capability (TSTC) is a training continuum 

philosophy consisting of both shore- and shipboard-based training, ensuring Fleet 

readiness. Shore-based team trainers and Navy schoolhouses have long been a 

standard by which many sailors have been trained to hone their skills and perform in 

a battle situation as a seamless consolidated unit. However, shipboard team training is 

an essential component of the Navy training continuum, creating a synergized effort 

of personnel, which allows the sailors and the Fleet to be onboard and to “Train the 

Way We Fight!”

Shore-based trainers do an excellent job of training sailors to understand their 

role and to operate their assigned equipment; however, the aesthetics of the facility 

does not necessarily allow for the reality of being onboard and under way, as stated in 

an excerpt from the Chief of Naval Operations (CNO) MESSAGE 051905Z DEC 91.

“...the concept that the ship, when properly supported presents the most 

effective training site for appropriate operational and functional training. This 

allows ships to train using their own equipment, system configurations and 

operational/casualty procedures. Enhanced training efficiency will result as 

training redundancy is identified and eliminated, a necessary reality in terms of 

future downsizing of the Navy.”

Creating a congruent Combat Systems Team Training system that could be 

utilized within the workspace, onboard ship, was theorized to be far more effective 

than creating and participating in a series of disjointed events and scenarios. As the 

initial shipboard training requirements matured, the Operational Requirements 

Document (ORD) to support the effort was developed to accommodate the 

mission needs of the Fleet. In March 1994, the Battle Force Tactical Trainer (BFTT) 

Operational Requirements Document (ORD) Rev 1 was implemented and states, 
117

Integrated Training for Combat Systems: 

Past, Present, and Future

“[BFTT] is an in-port shipboard combat 

system team training capability to provide:

•	 Realistic unit level team training in all 

warfare areas.

•	 A means to link ships together which are 

in different homeports for coordinated 

training using distributed interactive 

simulation (DIS) protocols.

•	 Stimulation to shipboard sensors via 

onboard trainers provided by tactical 

equipment program managers.

•	 Simulation of nonshipboard forces such as 

friendly, neutral, and enemy aircraft and 

submarines.

•	 An interface to the at-sea [Joint] Tactical 

Combat Training System ([J]TCTS).”

Basically, the BFTT was conceived and 

designed to electronically move real ships and 

crews located in separated ports, to a common 

synthetic theater of war (STOW). This provides 

a realistic, interactive environment that supports 

positive team training from the level of the battle 

group commander to the operator at the unit level 

across all warfare areas. However, to accomplish 

this training for a complex systems of systems 

(SoS), three phases of training are required.

The Basic Training Phase is accomplished 

right after an upkeep period for maintenance or 

system upgrades. During this period, an Afloat 

Training Group puts the ship’s combat system 

operators through a series of single-ship training 

events—the Command Assessment of Readiness 

and Training, Total Ship Training Availabilities, 

and a final evaluation period.

In the Intermediate Phase, ships are brought 

together for multiship training to include Fleet 

Synthetic Training (FST) events. These events 

proceed by multiple steps through their mission 

areas such as antiair warfare and strike warfare.

Finally, in the Advanced Phase, the scenarios 

are more complex culminating in at-sea Fleet 

exercises (FLEETEX) or Joint Tactical Force 

exercises (JTFEX) just prior to deployment.

Through this sequence, training becomes 

more progressively controlled by the ship’s own 

Combat System Training Team and Battle Group 

Commander and less controlled by the shore 

establishment. Throughout all events, Combat 

Systems Operational Sequencing System (CSOSS) 

(the set of procedures for equipment/system lightoff, casualty reconfiguration, and shutdown) is 

used and proficiency is evaluated.

The BFTT system has matured since its 

inception; it has grown from supporting all 

in-port training situations and single-ship at-sea 

...the next best thing to being underway.
118

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

applications provide the scenario and stimulus 

for the overall Live, Virtual, and Constructive 

(LVC) Environment (LVE), and BFTT is the host 

platform for Simulation/Stimulation (SIM/STIM). 

Second, BFTT can use NCTE connectivity to 

deliver a multiship or Battle Group (BG) scenario. 

Currently, the BFTT program fields 

seven different builds encompassing 127 

ships and shore sites. The builds are derived 

from a common source library supporting 

all of the required configurations. As ships 

are decommissioned and BFTT obsolescence 

upgrades continue, the number of BFTT 

baselines will be reduced. The breakdown of the 

BFTT family of systems’ (FoS) specific systems is 

listed in Table 1. 

The next phase of the BFTT FoS, BFTT FoS 

Modernization, ensures that the development 

of BFTT baselines are accomplished as required 

by the Advanced Capability Build (ACB) 

operational and system requirements process to 

interact successfully and plan for cross-program 

and platform-specific ACB activities through 

delivery. 

The goal of future builds will be to provide a 

more realistic and robust training environment, 

enhancing training processes and capabilities 

to ensure that the training provided effectively 

training events to now supporting the multiship 

at-sea training or FST events. 

The BFTT of today has evolved due to changes 

in technology and lessons learned. However, 

the basic concept has not changed; we still need 

to “Train the Way We Fight.” The conceptual 

framework of today’s BFTT is architected to accept 

controlled changes and solutions with minimal 

impact to hardware, software, and people, thus 

lowering operation and support costs. 

Central to this notional architecture are core 

BFTT training capabilities that support planning, 

conduct, assessment, and management of training 

and readiness information. These core BFTT 

capabilities are to be implemented with common 

services that aid in integrating the system 

components used by several training domains, 

functionally distinct trainer components for the 

training domains, and stand-alone training tools 

and aids that support both the trainer and trainee. 

Figure 1 portrays the components that make up 

BFTT and how they are related.

All external connectivity to BFTT is provided 

by the Navy Continuous Training Environment 

(NCTE) as part of the Global Information Grid 

(GIG). The NCTE, from the BFTT perspective, 

may operate in two modes. First, NCTE enables 

the training environment where tools and/or 

Figure 1. Training Environment
119

Integrated Training for Combat Systems: 

Past, Present, and Future

and measurably improves the performance of the 

individual/team/ship/task force. The BFTT will 

require technical insertion of training capabilities 

or traits into recently introduced and future 

ship systems such as combat systems, sensor 

systems, ship engineering, Link communications, 

navigation, etc. The enhancement of the BFTT 

architecture will enable economical, efficient, 

and scalable network management, database 

management, system resource management, 

and information assurance. Figure 2 depicts 

the Joint Vision 2020, Sea Power 21 Training 

Transformation as capabilities mature.

The future plans for the BFTT FoS modernization are depicted in the proposed build roadmap 

in Figure 3. Some of the competencies for each 

build are as follows:

Aircraft Simulation: An aircraft can be a 

simulated entity in a training scenario or the 

aircraft crew stations can be mocked up enabling a 

real-time pilot-in-the-loop synthetic training event. 

Capabilities include basic flight maneuvers, 

combat maneuvers, evasive maneuvers, and 

emergency procedures, including both radio 

communications and simulated Link within 

synthetic mission scenarios.

Vehicle Management: The Vehicle Domain 

Manager controls off-board vehicles, their sensors, 

weapons, and communication systems. These 

vehicles include rotary-wing aircraft, fixedwing aircraft, small boats, unmanned air vehicles 

(UAVs), unmanned surface vehicles (USVs) and 

unmanned underwater vehicles (UUVs). These 

vehicles complement the combat system by 

extending weapon, sensor, and/or communications 

footprints.

Scenario Generation and Control: Competency-based training, which requires a cognitive 

Table 1. BFTT Fielded Software Builds

Figure 2. Joint Vision 2020, Sea Power 21 Training Transformation
120

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

theory-based Scenario Generation & Control 

(SGC) module, builds scenarios based on 

competencies. The scenario generator is used 

to create scenarios for stimulated/simulated 

realistic circumstances. 

Common Database Schemas: Common 

database development would include all the 

training data. First, requirements must be 

developed and then the database schemas 

are implemented. Types of data may include 

Cognitive Theory Analysis, CompetencyBased Training Metrics, Competency-Based 

Metrics Automated Analysis, and Internal and 

External Capability Requirements for training 

organizations, such as individuals, teams, units, 

ships, and strike forces.

After-Action Reporting: An AfterAction Review (AAR) is a means of providing 

feedback to the principals on performance 

metrics captured during a training event. This 

feedback compares the actual performance of 

the individual/team/ship/strike force with the 

expected performance. 

These competencies and the metrics 

gathered, based on automated measurements and 

analysis, will provide details on specific training 

objects and their effectiveness. Differences 

between the actual and expected performance 

will be identified and then remedied via more 

exercises and drills or by the development and 

implementation of targeted training.

Fortunately, our leadership over 20 years ago 

realized that to have an efficient and effective 

battle force, an integrated training system was 

crucial to ensure our warfighters received the 

best possible training to assure a high state of 

operational readiness. Over the years, training, 

due to technological advances, has become 

more sophisticated, robust, and adaptable. The 

goal of providing the Fleet with an integrated 

training system that can be adapted to the 

training needs of the individual, work center, 

ship, battle group, and joint or coalition forces 

is being accomplished. The integrated training 

operational vision for synthetic training events is 

as shown in Figure 4. 

The future goal, to provide continued 

TSTC excellence in combat systems training, is 

imperative to Fleet combat readiness and crucial 

to ensuring that our sailors are prepared to 

combat and destroy current and future threats. 

The BFTT FoS enables and supports our sailors 

to “Train the Way We Fight,” ensuring that our 

Navy continues to be the best navy in the world!

Figure 3. BFTT Roadmap
121

Integrated Training for Combat Systems: 

Past, Present, and Future

Figure 4. Multiunit Synthetic Training

Integrated Training for Combat Systems: 

Past, Present and Future
122

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

NSWC Dahlgren’s Systems Engineering and 

Command and Control Expertise Applied to 

Marine Aviation

by Douglas Haas, Damian Watson, Laura Beth Viventi-Collins, and Barret Lohr
123

NSWC Dahlgren’s Systems Engineering Command 

and Control Expertise Applied to Marine Aviation

The United States Marine Corps (USMC) 

is modernizing and consolidating its aviation 

command and control (C2) systems. Its current 

systems have diverse lineages across the joint 

community and were not designed to work 

together in an integrated manner. They are 

manually intensive to operate and require an 

extensive logistical footprint. Consequently, 

the USMC tasked the Naval Surface Warfare 

Center, Dahlgren Division (NSWCDD), working 

with the Program Executive Office for Land 

Systems (PEO LS), to design a Common Aviation 

Command and Control System (CAC2S). 

USMC’s intent was to leverage NSWCDD’s 

recognized expertise in systems engineering and 

naval combat system design and development. 

This article describes NSWCDD’s contribution to 

the effort and highlights the systems engineering 

disciplines of requirements management and 

architecture development, and the use of 

engineering tools to facilitate these disciplines 

in support of the design and development of the 

CAC2S.

The CAC2S (depicted in Figure 1) provides 

a complete modernization replacement for the 

command and control (C2) equipment of the 

Marine Air Command and Control System 

(MACCS). CAC2S replaces single mission, stovepiped military specification legacy systems while 

providing commonality in training and logistics 

support. CAC2S fulfills joint net-ready capability 

standards required of all DoD C2 systems 

and remedies the operational, technical, and 

performance deficiencies of the existing MACCS. 

CAC2S eliminates current dissimilar systems and 

provides the aviation combat element with the 

necessary hardware, software, and facilities to 

effectively command, control, and coordinate air 

operations while integrated with naval and joint 

command and control (C2).1

CAC2S capabilities intend to replace the 

functions and equipment resident in the 

following:

•	 Tactical Air Command Center (TACC) 

•	 Direct Air Support Center (DASC) – air-toground operations (air attack) 

•	 Tactical Air Operations Center (TAOC) – 

air-to-air (fighters) and ground-to-air (air 

defense) - Patriot, Stinger operations

 CAC2S is both a producer and a consumer 

of battlefield information while communicating 

with sensors, data distribution networks, tactical 

data links, and aircraft. CAC2S interfaces 

with other battlefield agencies executing the 

functions of both command and control. As 

such, there are interfaces to both legacy and 

developmental systems within the USMC and 

Joint communities. The goal of CAC2S is to 

replace legacy Marine Corps systems with an 

extensible system capable of integrating a host of 

C2 tools, local sensors, networked sensors, and 

tactical data links necessary to modernize and 

enhance the Marine Corps’ ability to accurately 

and efficiently control Marine aviation, as well as 

provide a more transportable and mobile system. 

Sound systems engineering practices, specifically in the fields of requirements management 

and architecture development, were key to the 

CAC2S acquisition effort’s success. Requirements 

needed to be managed from the beginning, as 

basic capabilities were decomposed, clarified, 

and refined to produce system requirements. 

Architecture development then explored the 

communication needs, interfacing systems, and 

system functions, providing a continual feedback 

loop with the requirements. 

The Foundation – Engineering 

Stable Requirements 

Through early and rigorous requirements 

engineering and management activities, 

the NSWC Dahlgren CAC2S requirements 

engineering team worked with the user 

community and Headquarters Marine Corps, 

Combat Development and Integration 

(HQMC CD&I) to develop clear, complete, 

unambiguous, and testable system requirements. 

This was necessary because whenever system 

requirements are inadequately identified or 

are not managed early in the system lifecycle, 

acquisition costs can rise due to continuous 

requirements refinement. Worse, when system 

requirements fail to accurately capture the 

functions and capabilities required by the 

warfighter, mission success can be compromised. 

Consequently, in order to accurately capture and 

stabilize the CAC2S performance requirements 

early in the system acquisition cycle, the 

NSWCDD requirements engineering team 

immediately employed the use of the Dynamic 

Object-Oriented Requirements Suite (DOORS) 

provided by IBM Telelogic.

Requirements engineers utilized DOORS to 

store, baseline, trace, and exercise configuration 

control over the CAC2S requirements. This 

helped to facilitate sound requirements 

engineering. The resulting CAC2S requirements 

set consisted of 867 system-level requirements 

derived from 243 operational requirements. 

Each requirement was subsequently evaluated 
124

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Working together with Marine Corps Systems 

Command (MARCORSYSCOM) engineers 

and Marines, the NSWCDD architecture team 

helped to bridge the gap between operational 

needs and system solutions. CAC2S architecture 

engineers organized and fashioned system 

requirements into a workable model, aligned the 

system concept with the operational construct, 

and ultimately, influenced and guided system 

design.

In general terms, while requirements 

engineering yields an extensive list of 

requirements, architecture development 

provides the structure to move forward. 

Architecture development, therefore, defines the 

overarching organization of the system concept 

and outlines a problem statement to be solved by 

system design. 

System architecture development begins 

with system requirements, supported by 

direct warfighter input. Warfighter input to 

system architecture is received in the form of 

the operational architecture. The operational 

architecture is analogous to the system 

architecture; only the perspective is different. 

The operational architecture describes who 

the warfighters are, what activities they do, 

and what information is exchanged between 

organizations. The system architecture defines 

system components, what functions they 

execute, and what data is exchanged between 

systems.

For CAC2S, the operational architecture 

was developed by the operating forces, in this 

for clarity, appropriateness, traceability, and 

testability. Over 1600 Change Proposals were 

adjudicated as part of the effort; proposed 

changes included the modification of existing 

requirements, the deletion of redundant and 

immeasurable requirements and statements, 

and the insertion of new requirements. Refined 

requirements were then captured in the CAC2S 

Capability Production Document (CPD) and the 

CAC2S System/Subsystem Specification (SSS). 

In concert with the two formal processes 

outlined in the CAC2S Requirements 

Management Plan, the Change Proposal Process 

and the Requirements Validation Process, 

requirements engineering and management 

activities were strictly executed to support 

the comprehensive review of the CAC2S 

performance requirements by both the aviation 

C2 subject matter expert and requirements 

engineering communities. Thus, NSWCDD 

engineers provided stakeholders with quality 

requirements documents and subsequently 

supported the successful CAC2S System 

Requirements Review (SRR) held in summer 

2009. NSWCDD engineers, therefore, established 

a strong foundation on which to build the 

CAC2S system architecture diagrams and design 

documents.

Structure – Development of 

System Architecture 

In addition to the requirements effort, 

NSWCDD engineers also played a key role in the 

development of the CAC2S system architecture. 

Figure 1. Notional CAC2S Operational Layout
125

NSWC Dahlgren’s Systems Engineering Command 

and Control Expertise Applied to Marine Aviation

case, HQMC CD&I. The CAC2S operational 

architecture described USMC aviation C2 

through a set of Operational Views (OV). 

The task for the system architecture team at 

NSWCDD, then, was to define a model of 

CAC2S that reflected not only the requirements 

defined in the SSS, but more directly, satisfied 

the needs of the Marines as defined in the OVs. 

Figure 2 illustrates the basic development cycle 

for accomplishing that task. The diagram shows 

how the requirements and the OVs were inputs 

to the process that yielded the fundamental 

Systems and Services Views (SV) of the system 

architecture.

The process above began with two somewhat 

independent thrusts: functional analysis 

and interface analysis. The key steps in the 

functional analysis are shown on the far left 

side of the diagram (Figure 2). The OV-5, which 

described the operational activities (i.e., what the 

warfighter does), was the primary operational 

input to the CAC2S functional analysis. The 

warfighter activities drove the identification 

of what the system needs to do, as scoped and 

partly defined by the system requirements in the 

SSS. The explicit trace between the functions 

and activities was the SV-5. The organization 

of the system functions defined a functional 

hierarchy, part of the SV-4. Meanwhile, as shown 

on the far right side of the diagram, the interface 

analysis began with the OV-2, which described 

the relevant operational nodes (i.e., who the 

warfighters are). The identification of system 

entities, the systems used at the operational 

nodes, laid the groundwork to identify system 

interfaces. Finally, through the identification of 

communications media (e.g., radios, routers, 

etc.), the system interfaces were defined in 

the SV-2. From there, the identification of 

system data exchanges finally tied together the 

functional analysis and the interface analysis; the 

system data exchanges were, at the same time, 

the inputs and outputs of the system functions 

in the SV-4 data flow diagram, as well as the 

message traffic exchanged across the system 

interfaces, as documented in the SV-6. Following 

this process, the architecture engineers defined 

the system functions, system interfaces, and 

system messages, as depicted in the CAC2S 

architecture products.

Ultimately, however, NSWCDD’s 

contribution to the architecture development 

effort was not the CAC2S architecture itself, 

but rather, the engineers’ influence on system 

design. Because architecture development 

is a mandatory yet often misunderstood 

process in systems engineering, a common 

temptation is to merely use the architecture to 

Figure 2. CAC2S System Architecture Development Process
126

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

document the systems engineering decisions 

after they are made. A more mature systems 

engineering approach is to define the system 

architecture upfront, so that better design 

decisions can be made from a cohesive, 

succinct model. For CAC2S, as candidate 

components, implementations, and allocations 

were evaluated in the system design process, 

the system architecture was a key reference. 

The system architecture that NSWCDD and 

MARCORSYSCOM developed for CAC2S 

continues to be a driving influence in designing a 

system solution for Marine aviation C2.

Coordination – Maintaining an 

Engineering Environment 

As with any program, orchestrating complex 

systems engineering processes is a key challenge. 

Requirements and architecture concordance was 

maintained using an integrated suite of systems 

engineering software. Modeling languages were 

used to link the abstract system architecture 

to the emerging physical design, and an 

integration lab was established to provide a test 

and engineering facility to realize the system. 

As mentioned previously, the requirements 

engineering team utilized DOORS to create the 

requirements database. In a similar fashion, 

the architecture team used System Architect, 

another database-oriented tool. The selection 

of the two tools was a coordinated decision, 

enabling dynamic cross-referencing between 

the two efforts. The integrated suite of tools 

was employed in unison because of their ability 

to share information and to create linkage, as 

elements of the system architecture database 

were linked directly with system requirements 

in the DOORS database facilitating traceability. 

The use of these integrated tools for control was 

important in the CAC2S systems engineering 

effort. Having a comprehensive set of 

architecture products and a rigid requirements 

management process allowed NSWCDD, as the 

CAC2S Engineering Agent, to fully understand 

the requirements and constraints within which 

to develop CAC2S. 

Other engineering tools, such as Unified 

Modeling Language (UML) and Systems 

Modeling Language (SysML) sequence diagrams, 

provided the team with a medium and syntax 

to transform the abstract architecture into the 

configuration items of the physical design. 

NSWCDD engineers developed these sequence 

diagrams to illustrate the time-ordered execution 

of system actions or operations through system 

components and software. In effect, these models 

allowed the systems engineers an opportunity to 

proof the design against the architecture, while 

examining system functions, data exchanges, and 

system interfaces.

Conclusion

The need to transform Marine aviation C2 

systems has yielded a fruitful collaboration 

between NSWDD and the USMC. By applying 

sound systems engineering practices early 

in the acquisition process, especially in the 

requirements engineering and architecture 

development disciplines, NSWCDD is helping 

to provide a more capable, modern, and 

consolidated system to the Marine Aviation C2 

community.

Reference

1. PEO Land Systems, Common Aviation Command and Control 

System (CAC2S), http://www.marcorsyscom.usmc.mil/peolandsystems/cac2.aspx, accessed 28 September 10.
127

NSWC Dahlgren’s Systems Engineering Command 

and Control Expertise Applied to Marine Aviation

NSWC Dahlgren’s Systems Engineering

Command and Control Expertise Applied to 

Marine Aviation

NSWC Dahlgren’s Systems Engineering Command 

and Control Expertise Applied to Marine Aviation
128

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Warfare System Interface Diagrams (WSIDs) in 

Support of Combat Systems Modernization

by Jody Michael and Rob Byers

Increases in the volume and complexity of system-of-systems engineering 

solutions to the complex problems faced by warfighters create an opportunity to lose 

control of the “as-is” and “to-be” combat system configurations. In order to make 

informed decisions, stakeholders need a way to view the pertinent information in a 

format that is clear, concise, and at the appropriate technical altitude and aperture.

Warfare System Interface Diagrams (WSIDs) were originally developed by 

Combat Direction Systems Activity (CDSA), Dam Neck, in support of Program 

Executive Office, Integrated Warfare Systems (PEO IWS) 10.0, Ship Self Defense 

System (SSDS) development, to manage the planned SSDS ship configuration 

upgrades. These WSIDs originally tracked the hardware nomenclature, software 

versions, physical interface types, and governing interface documentation of the 

warfare system. The diagram depicted the detect-control-engage systems that 

are considered part of the warfare system and are included in the combat system 

certification package that is planned for delivery during a Chief of Naval Operations 

(CNO) scheduled ship maintenance and modernization availability. The WSIDs 

have come to be known as providing an integrated view of both current status and 

proposed modernization plans. In response to the early success, and with the support 

of PEO IWS leadership, CDSA Dam Neck expanded the applicability of the tool. 
129

Warfare System Interface Diagrams (WSIDs) in 

Support of Combat Systems Modernization

CDSA Dam Neck has now developed 

WSIDs to track the configuration of PEO IWS 

combat system elements, along with some 

Program Executive Office for Command, 

Control, Communications, Computers and 

Intelligence (PEO C4I) and Naval Air Systems 

Command (NAVAIR) systems. WSIDs have 

been developed for all carriers, large deck 

amphibs, cruisers, destroyers, guided missile 

frigates, USCG Maritime Security Cutters, and 

littoral combat ships. (Three of these ship types 

are shown in Figures 1 through 3.) WSIDs are 

maintained for each ship’s afloat configuration, 

showing the deployed combat system elements, 

and for the next five fiscal years of planned 

CNO availabilities. The WSID is now a package 

consisting of a hardware (HW) and interface type 

diagram depicting the hardware nomenclature 

and physical interfaces; a software (SW) and 

interface specification diagram depicting the 

software versions and interface documentation; 

and a WSID tabular changes page listing the 

IWS-approved changes by system and approval 

date. The scope of the changes planned for a 

specific availability period is annotated by the 

shading of the systems receiving changes. Blue 

shading is used for HW upgrades, yellow for SW 

upgrades. The more blue or yellow shading on 

a particular WSID, the more approved changes 

are planned. The WSIDs are recognized as the 

PEO IWS authoritative enterprise configuration 

management planning tool. WSID development 

is expanding in 2013 to include additional USCG 

classes, tracking Navy-Type, Navy-Owned 

(NTNO) equipment, and to document the Aegis 

Ashore configurations.

The WSIDs are governed by PEOIWSINST 

4130.1B, the PEO IWS Enterprise Configuration 

Control Process (ECCP). The ECCP manages the 

proposed configurations for ship modernization. 

Traditionally, Participating Acquisition Resource 

Managers (PARMs) have proposed C5I hardware 

and software upgrades for systems under their 

cognizance using Ship Change Documents (SCDs) 

as required through the Entitled Process (EP). The 

ECCP mandates that each PARM submit their 

Figure 1. Aegis Cruiser, USS Normandy (CG 60)
130

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Figure 2. SSDS Carrier, USS Nimitz (CVN 68)

Figure 3. Amphibious Ship, USS Iwo Jima (LHD 7)
131

Warfare System Interface Diagrams (WSIDs) in 

Support of Combat Systems Modernization

initiated SCDs to the Enterprise Configuration 

Control Board (ECCB) for approval by the 

PEO IWS Integrated Combat System (ICS) Major 

Program Managers (MPMs) before the SCD 

can be submitted into the EP. The ECCB is also 

supported by the NAVSEA 05 Platform Warfare 

System Integration Managers (SIMs), Deputy 

SIMs (DSIMs), and Baseline Managers, the Ship 

Program Managers (SPMs), and Ship Acquisition 

Program Managers (SHAPMs), the IWS Aegis 

Integration Engineering (AIE) Team, the SSDS 

Combat System Test (CST), and IWS Certification 

Readiness. The ECCB brings together the 

modernization plans developed by each PARM 

into a forum that reviews all the planned combat 

system upgrades as a package to ensure the right 

upgrades are being fielded at the right time on 

the right ships. The ECCB serves as the forum for 

coordination of fielding plans for multiple warfare 

system components within and across ship classes 

to meet Fleet requirements while optimizing cost 

and performance. 

After each ECCB, minutes are distributed 

to the C5I community and the SCDs are then 

submitted through EP by the individual PARMs. 

The WSIDs are updated in accordance with the 

ECCB-approved configuration changes, and 

released as a new, approved WSID baseline on 

the second Friday of each month. The WSIDs 

are then posted on the Warfare Interface System 

Engineering (WISE) web tool that is managed by 

CDSA Dam Neck. The data elements represented 

graphically on the WSIDs are also stored and 

managed in the WISE database. WISE gives 

users the ability to view all current and planned 

ship configurations in a variety of ways, such as 

systems and changes by ship, ships by system 

and change, and comparing two or more ship 

configurations.

During the planning phase for new ships, 

or for large combat system upgrade packages, 

the CDSA Dam Neck WSID Baseline Managers 

work in conjunction with the IWS ICS Integrated 

Product Team (IPT) leads to provide engineering 

support in the development of the proposed 

configurations. Targeted Configuration Interface 

Diagrams (TCIDs) are developed during the 

planning phases to allow for the use of the 

WSID type of document by the planning 

community, while not requiring the data to have 

been approved through the ECCB. For new 

construction ships, CDSA Dam Neck develops a 

Construction WSID based on the signed contract 

for the ship. The construction configuration is 

managed through the planning, development, and 

deployment phases of system upgrades. At the 

completion of Post-Shakedown Availability (PSA), 

the ship moves into an afloat WSID configuration 

and configuration management of the follow-on 

modernization availabilities continues. 

The WSIDs have facilitated PEO IWS’s need 

to gain control of the “as-is” and “to-be” combat 

system configurations through a rigorous, 

process-based approach. This fidelity provides 

additional user communities the confidence 

needed to look at other system-of-systems 

considerations such as realigning schedules to 

increase configuration commonality, reducing 

the number of required certification events, and 

providing more stable, operable, and supportable 

combat system capabilities.

The WSIDs can be accessed on the CDSA 

Dam Neck WISE Web site through the following: 

https://wise.navseadn.navy.mil.
132

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Major Combat Systems Technology Refresh 

for the Dock Landing Ship Fleet:

Hardware Design at Combat Direction Systems Activity, Dam Neck

by Barry Stevens, Larry Swinford, and Dale Bloodgood

The ships of the LSD 41 Whidbey Island and LSD 49 Harpers Ferry classes are 

about to receive a significant upgrade: a technology refresh that replaces the current 

Ship Self Defense System (SSDS) Mk 1 with an open architecture baseline of SSDS 

Mk 2. Deployed aboard LSDs since 1997, SSDS integrates and controls self-defense 

weapons and sensors aboard those ship classes to provide a self-defense capability. 

Dock landing ships support amphibious operations including landings via landing 

craft, air cushion (LCAC), conventional landing craft, and helicopters. The Whidbey 

Island-class amphibious dock landing ship USS Comstock (LSD 45) is shown in 

Figures 1 and 2.

Figure 1. Persian Gulf (November 22, 2006) - The Military Sealift Command (MSC) fast combat support ship USNS Supply 

(T-AOE 6), left, conducts an underway replenishment (UNREP) with the Whidbey Island-class amphibious dock landing ship 

USS Comstock (LSD 45). Supply and Comstock are under way in the U.S. 5th Fleet’s area of operations in support of maritime 

security operations. (U.S. Navy photo by Mass Communication Specialist 2nd Class Kitt Amaritnant (RELEASED))
133

Major Combat Systems Technology Refresh for 

the Dock Landing Ship Fleet:

Hardware Design at Combat Direction Systems Activity, Dam Neck

This article summarizes requirements and 

the resulting hardware design for the SSDS 

upgrade conducted by Combat Direction 

Systems Activity. SSDS is designed to integrate 

ships’ sensors and weapons to provide sailors 

with battle management command and control 

and automated, layered self-defense. The 

upgraded system for the LSDs is designated SSDS 

Mk 2 Mod 5C. Having completed the design 

phase, the Mod 5C project is in development and 

preparing for combat system certification testing 

in 2012. 

The purposes of the Mod 5C project are 

to improve the ships’ self-defense capability 

with respect to current threats, to provide an 

equipment refresh to the class, and to improve 

the logistics supportability of the combat 

system during the ships’ service life. The 

upgrade provides improved SSDS Humanto-Machine Interface (HMI) capabilities 

through the use of touch screen displays, highdefinition large-screen displays, and Voice-overInternet Protocol (VoIP), which will enhance 

warfighter situational awareness and the ability 

to direct fire control. Hardware supportability 

is improved by using open architecture 

hardware components. Software supportability 

is improved by bringing these ships into those 

supported by the SSDS Mk 2 single-source 

software library. The importance of the singlesource library, implemented by Raytheon 

Corporation, is to make applicable capability 

improvements or corrections done for any SSDS 

ship class available to the other ship classes more 

efficiently. SSDS engineers are working closely 

with sensor, weapon, navigation, and common 

processing and console programs to deliver a 

coordinated set of upgrades to produce a wellintegrated warfare system for these ships.

The SSDS Mk 2 Mod 5C system is composed 

of a command and control table, two network 

switching cabinets (NSC), CV-4437 MultiPurpose Enclosures (MPE), two Tactical 

Computer Consoles (TCC), three Large Screen 

Displays (LSD), and a Portable Maintenance Aid 

(PMA) which runs the Maintenance Tool Kit 

(MTK) application. The network switch cabinet 

is produced by Raytheon Corporation; the 

Common Display System (CDS) consoles and 

Common Processing System (CPS) processor 

cabinets are procured by PEO IWS 6. 

Open Architecture Command 

Table

Combat Direction Systems Activity 

(CDSA), Dam Neck, Virginia, part of the Naval 

Surface Warfare Center, Dahlgren Division, is 

conducting the design, production, hardware 

Figure 2. The Whidbey Island-class amphibious dock landing ship USS Comstock (LSD 45) returns to Joint Base Pearl 

Harbor-Hickam, Hawaii, after participating in Rim of the Pacific (RIMPAC) 2010 exercises. (100729-N-0641S-059 Pearl 

Harbor; July 29, 2010; U.S. Navy photo by Mass Communication Specialist 1st Class Jason Swink (Released))
134

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

monitor console. Modification was required to 

achieve a three-monitor configuration, while 

remaining sufficiently narrow to place the design 

within equipment footprint constraints. The 

right-hand operator position on LSDs, however, 

will be provided two display monitors vice three 

because that operator position is immediately 

adjacent to other combat system equipment.

The tactical computer console is the leftmost component shown in the figure. Its 

purpose is to provide processing power and 

network devices required for data recording, 

maintenance actions, and information assurance 

functions.

The two electronics equipment enclosures sit 

between the three CDS consoles. Their purpose 

is to provide processing and network devices in 

support of digital voice communications, video 

switching for the large screen displays, batteriesrelease functionality, and uninterruptable 

power to the command table in the Combat 

Information Center (CIC). High-resolution, 

large-screen displays provide the ability to view 

tactical displays and other video feeds on large 

physical display surfaces.

testing, and fielding of the command table 

hardware for SSDS Mk 2 open architecture 

baselines. Developed for this project, command 

table hardware will also be used in the new 

CVN 78 Ford-class aircraft carriers and backfit to 

other SSDS Mk 2 ships. A depiction of the open 

architecture command table is shown in Figure 3.

The command table supports three seated 

operators. It features high-resolution graphics, 

digital voice communications, video switching 

for the large screen displays, batteries-release 

functionality, and integrated tactical chat and 

Common Operational Picture (COP) display 

capability. Principal components of the command 

table are:

•	 Common Display System (CDS) consoles

•	 Tactical Computer Console TCC 

(OJ-830(V)2)

•	 Electronics Equipment Enclosure (EEE)

•	 Large-Screen Displays

Operators seated at the CDS consoles use a 

keyboard, trackball, variable action buttons (VAB) 

and display monitors for each position. The 

CDS consoles in the command table design are 

a modified version of the CDS Variant “B” dualFigure 3. The open architecture command table provides three SSDS Mk 2 operator positions.
135

Major Combat Systems Technology Refresh for 

the Dock Landing Ship Fleet:

Hardware Design at Combat Direction Systems Activity, Dam Neck

Figure 4. Multi-Purpose Enclosure components provide maximum adaptability within a single design.

Multi-Purpose Enclosure (MPE): 

SSDS’ Digital “Utility Infielder”

The warfare system being fielded for 

LSD 41 and 49 classes is a cost-effective mix 

of systems, some of which have been in the 

Fleet for a long time and some that are under 

development. During the warfare system design 

phase, it became apparent that a new, versatile 

component would be needed to provide an array 

of interface translations and processor backplanes 

to minimize the amount of hardware change 

to core SSDS components. CDSA Dam Neck is 

developing the MPEs for the Mod 5C project. 

The requirements for the Multi-Purpose 

Enclosure include:

•	 Support for interface types: NTDS A/B, D, 

E, 100BaseTX, 1000BaseT, 1000BaseLX and 

radar video,

•	 Support for processor backplanes: VME 

and cPCI,

•	 Support bulkhead or rack mounting. 

The Multi-Purpose Enclosure and its components 

are shown in Figure 4.

Onboard processing allows the MPE to host 

SSDS Mk 2 software, which is specific for that 

interface. The full set of interface options allows 

the MPE to perform media conversion within the 

warfare system. Bulkhead mounting is important 

for this ship class due to the limited deck space 

available for additional equipment.

Summary

The SSDS Mk 2 technology refresh improves 

the ships’ self-defense capability with respect 

to current threats, provides an equipment 

refresh to the class, and improves the logistics 

supportability of the combat system during the 

ships’ service life. CDSA Dam Neck provides 

government-owned designs and performs the 

acquisition and acceptance of Command Table 

and interface hardware for LSD 41/49 classes, 

which will also be reused throughout the SSDS 

Mk 2-equipped Fleet.

Capacitor Module

Power Supply 

Module

Fan 

Module

AC Input 

Module

Control Module

Air Filter, 

EMI Screen, 

Louver

VME/cPCI Cage

Rush Power 

Supply

Rush
136

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering
137

Common Architecture System Assurance:

Information Assurance for the Next Generation of Combat Systems

27 April 2014, Gulf of Aden. A U.S. Navy 

destroyer cruises through the entrance to the 

Arabian Sea, passing close to war-torn Somalia. 

The ship is on alert, as recent intelligence reports 

indicate terrorist cells are working actively in 

Somalia. In the Combat Information Center, 

watch standers are keeping close tabs on the 

systems governing the ship’s self-defense battery 

of sensors, radars, and weapons. At 0937 Zulu, 

an indicator on a little known but newly installed 

system named Common Architecture System 

Assurance (CASA) flickers from green to red, 

indicating an electronic intrusion attempt was 

detected in the combat system. The watch officer 

immediately orders one of the watch standers 

to open up the CASA display to determine what 

had happened and to begin any remediation. The 

operator quickly identifies an attempted hostile 

probe of the combat system was conducted over 

one of the external network interfaces but was 

blocked and reported by built-in safeguards. 

The watch officer, understanding the probe 

meant that hostile forces had somehow acquired 

material enabling them to interface with the 

combat system, shuts down the affected interface 

and notifies the Commanding Officer, who 

orders a full alert, realizing the electronic probe 

could be a prelude to an attack by slowing or 

even crippling the ship’s combat systems. The 

ship is well prepared when a hostile incoming 

contact is detected at 0943.

Fiction? Perhaps now, but in the future, likely to become fact. In leveraging our technological expertise, military platforms have become 

ever more capable, but conversely, have become 

more vulnerable to Information Assurance (IA) 

threats. 

The Navy work force has leveraged its unsurpassed ability in software and hardware to create 

reliable, fast, agile, and effective combat systems. 

This has been accomplished by building on software that is available to our adversaries, both 

current and future. Assuring the integrity of software and hardware in combat systems has thus 

become a matter of life and death. Our enemies 

know they cannot easily defeat our systems in a 

straight-up conflict and must find ways to disable 

or degrade them in order to attack us. CASA is 

designed to help prevent that from occurring.

What is CASA?

CASA is a specialized Security Information 

and Event Manager developed by engineers at 

Naval Surface Warfare Center, Dahlgren Division 

(NSWCDD), and Combat Direction Systems 

Activity, Dam Neck. The system is designed to 

collect, analyze, and report all IA-related events 

for a system, network or, potentially, an entire 

platform. By providing incident details, missioncritical impacts, and corrective actions to the 

warfighter, CASA helps to ensure the integrity of 

mission-critical Navy systems.

IA Made Simple

To make CASA simple enough for an enduser, Human Systems Integration engineers 

were involved in the planning, development, 

testing, and validation of CASA in collaboration 

with Certified Information Systems Security 

Professionals and combat systems engineers. 

CASA allows the warfighter to see at a glance the 

possible problems, the system effectiveness, and 

potential workarounds for IA events as they are 

understood by the subject-matter experts ashore 

who designed, built, and tested the systems. 

This ability gives the warfighter a virtual “expert 

in a box,” capable of evaluating the system and 

assessing the combat readiness and effectiveness 

of the system. The display is designed to be as 

intuitive as possible, allowing for quick and 

concise dissemination of IA information. The 

basic display, or dashboard view, provides a 

breakdown of the alert categories that CASA 

is currently monitoring along with a quick 

indication of their status. Figure 1 depicts a 

typical CASA dashboard display.

 If an alert were detected, an operator would 

use the dashboard display to select the category 

containing the alert of interest. Once this is 

done, CASA would provide a list view offering 

all unhandled events in that category. This view 

provides summary information, timestamps, and 

priority information for each event (Figure 2). 

By selecting a particular event from the list view, 

the operator is presented with a final expanded 

view offering mission impact information and 

remediation steps, as well as all of the technical 

details available to the operator as needed. The 

alert categories, alert rules, mission impact 

statements, and corrective actions can all be 

tailored for the specific IA requirements and 

system impacts for any Department of Defense 

(DoD) Program of Record.

DoD Policy Compliance

CASA is designed to meet cyber security 

laws and DoD policies. The Federal Information Systems Management Act requires 

government systems to be secure from IA 

threats. SECNAV 5239.3, Department of the 
138

Combat Systems Engineering & Integration

Combat-Systems-Level Systems Engineering

Figure 2. CASA Anti-Cyber-Warfare Detection Details

Figure 1. CASA Anti-Cyber-Warfare User Dashboard
139

Common Architecture System Assurance:

Information Assurance for the Next Generation of Combat Systems

Navy Assurance Policy, requires Department of 

Navy program offices to provide IA detection 

and monitoring capabilities. DoDI 8500.2, 

“Information Assurance Implementation,” 

requires system engineers to build in mitigations 

against IA threats. CJCSM 6510.01 CH 3, 

“Defense-in-Depth: Information Assurance 

(IA) and Computer Network Defense (CND),” 

requires warfighters to report IA events to 

external security authorities in their chain of 

command. All of these capabilities are part of the 

services CASA provides.

How It Works

CASA can be thought of as a type of security 

alarm system for the network. In a traditional 

security system, sensors are placed around a 

building to monitor doors, windows, motion, and 

other signs of intrusion. When these sensors are 

tripped, an alarm is triggered. CASA functions 

in much the same way. Sensors are placed on 

systems around the network that monitor log-in 

attempts, file corruption, port scans, and other 

signs of potential attack. In many cases these 

sensors already exist; CASA is filling in the gap 

where there had been no central repository and 

correlation capability that puts the pieces together 

to detect potential threats to information systems. 

Attempting to access each individual sensor and 

make sense of the considerable amount of data 

each one produces would normally overload an 

operator. CASA solves this problem by finding 

the important incidents that need to be elevated 

to the warfighter’s attention. As a result, CASA 

provides an IA situational awareness capability 

to the warfighter that has previously been 

missing. Even the best educated and trained 

warfighters cannot be experts on every aspect 

of every system; they especially cannot develop 

and maintain expertise on all of the esoteric and 

constantly changing threats associated with IA. 

The inherent IA language and terminology is 

obscure and often unhelpful to the warfighter. 

From an anti-cyber warfare perspective, the 

bottom line is that CASA supplies the sailor the 

answers to critical questions such as: Is my ship 

battle ready? Is my combat system running in a 

degraded mode? Has the network and/or tactical 

data been tampered with?

Open Architecture Standards 

Compliance

CASA incorporates event data from external 

devices into its database of monitored IA events. 

CASA communicates with the sensors that 

generate raw information about system events 

through the use of external software connectors. 

These connectors are responsible for translating 

and transmitting this event data in a format CASA 

can comprehend and efficiently process. This 

approach develops an extensible and adaptive 

framework that emulates the Open Source 

Software Development model, where extensions in 

capability are easily supported and can be shared 

by all users. CASA can collect data from sensors 

that use common formats such as Syslog, Simple 

Network Management Protocol, and Security 

Device Event Exchange. CASA could also be easily 

configured to monitor Microsoft Windows events 

by developing a connector capable of retrieving 

and converting the Windows-specific format into 

the consolidated CASA format.

CASA is revamping how the Navy manages 

IA for deployed systems, while growing and 

developing new capabilities. Recent features 

such as built-in redundancy and failover and 

an automated response capability have been 

prototyped. Additionally, enhancements for CASA 

such as real-time trending are planned.

Investment in programs such as CASA will 

help the Navy defend against emerging cyber 

threats as we continue to develop new, more 

capable systems for the Fleet. The threat is 

evolving; so is our response.
140

Combat Systems Engineering & Integration

Element-Level Systems Engineering

Managing Computing Technology Change

for Surface Navy Combat Systems

by Philip M. Irey IV, Leslie A. Madden, David T. Marlow, Greg D. Miller, and Jerry W. Oesterheld

Surface Navy combat systems include complex computing systems consisting of 

millions of lines of code that must be engineered to meet rigorous mission-critical 

requirements. Since Fleet deployment spans decades, these computing systems 

must undergo numerous planned capability upgrades as well as maintenance to 

prevent or correct problems. Modern combat systems depend upon commercial 

off-the-shelf (COTS)-based computing environments. The rate of change in these 

computing technologies far exceeds the development and deployment timelines for 

the combat systems that employ them. As a consequence, a multitude of challenges 

exist in leveraging and sustaining COTS technologies in this environment. 

This article discusses these challenges, provides examples of how they impact 

programs, describes architectural and acquisition approaches for mitigating 

them, and recommends engineering approaches for anticipating and adapting to 

technology change.

Computing Technology Challenges

Although the life spans of combat system applications used in Navy warships are 

very long, the COTS computing technologies on which they depend are changing 

at a rapid pace driven by the commercial marketplace, rather than the lengthy Navy 

acquisition cycle. Consequently, the Navy must manage problems of obsolescence 

in its deployed systems. During update cycles, in addition to enhancing warfighting 

capability, these systems must absorb major requirements and software changes 

driven by technology evolution. The traditional combat system update cycle 

spans multiple COTS product evolution cycles. Significant challenges result from 

requirements and utilization scenario differences between the targeted commercial 

environments and the combat system environment. COTS products must often be 

adapted or used in innovative ways because of these differences. 
141

Managing Computing Technology Change

for Surface Navy Combat Systems

Engineering of combat system computing 

technology is a key activity for addressing these 

challenges. Critical aspects of this discipline are 

foreseeing and managing the impacts of rapid 

computing technology changes on the combat 

system, while leveraging these changes to improve 

warfighting capability. The degree to which the 

Navy can predict these changes, assess their 

impact, develop strategies for leveraging them, 

and influence their future direction will drive 

sustainment costs and capability improvements. 

Evolution of Combat System 

Computing Technology

The Aegis combat system, which is the most 

capable, current surface combat system in the U.S. 

Navy, is deployed on over 80 of the Navy’s cruisers 

and destroyers. The distributed computing 

infrastructure of Aegis was originally based on 

military standard computing technology (e.g., 

UYK-43 computers, Naval Tactical Data System 

(NTDS) interconnects) but has evolved over 

time through a series of baselines and upgrades 

to use mainstream COTS computing technology 

illustrated in Table 1 and Figure 1. 

During the last two decades, the number 

of processors increased over 12 times while 

computing power increased over 1000 times. 

The increased hardware capacity has been 

accompanied by significant increases in software 

complexity. While the main focus of the following 

table and figure is on hardware technology 

associated with combat system evolution, software 

technology evolution is also ongoing at a rapid 

pace.

 The evolution of computing technology is 

inevitable, and it has a profound effect on the 

development and maintainability of systems that 

utilize it. In many cases, the selection of particular 

computing equipment or software is appropriate 

at the time it is chosen; however, as time passes, 

it is revealed to have significant, unanticipated 

consequences because of the evolutionary 

path of that technology family and the failure 

to adequately anticipate and plan for that 

evolution. An additional impact in the selection 

of a technology path is whether it will result 

in “vendor lock-in,” where future technology 

refreshes will be restricted to niche products only 

provided by a single vendor.

Architectural Constructs 

for Mitigating the Impacts of 

Technology Change

Managing technology change begins with 

defining architectural constructs that decouple 

the evolution of rapidly changing technologies 

from more stable system functionality. For 

example, utilizing interfaces that are well 

defined, tightly controlled, and stable allows the 

internal design of modular components that use 

them to evolve independently. Coupling such 

interfaces with an architecture that incorporates 

a separation of concerns between application 

components and the computing technology used 

by the system can significantly decouple the 

combat system from the impacts of computing 

technology change.

Modular Open Systems Approach (MOSA) and 

Open Architecture (OA)

The Modular Open Systems Approach 

(MOSA) established by the Office of Secretary 

of Defense1

 and Naval Open Architecture (OA) 

mandated by the Chief of Naval Operations have 

defined principles that can help mitigate the 

impacts of change. These principles, described in 

the Defense Acquisition Guidebook, include the 

following:2

1. Establish an enabling environment

2. Employ modular design

3. Designate key interfaces

4. Use open standards

5. Certify conformance

Table 1. Computing System Technology Evolution
142

Combat Systems Engineering & Integration

Element-Level Systems Engineering

Figure 1. Combat System Computing Technology Evolution

OA principles are compatible with MOSA 

and include the use of modular design and 

design disclosure to permit evolutionary design, 

technology insertion, competitive innovation, and 

alternative competitive approaches from multiple 

qualified sources.3

 As part of its implementation 

of OA, the surface combat system community 

has been evolving its systems over time to 

improve their adaptability to the changing COTS 

landscape. This evolution is gradual by fiscal 

necessity. 

The first phase of OA migration has been 

to reengineer existing combat systems to use a 

computing environment based on open standards. 

Software applications have been modified to 

decouple them from their dependency on specific 

custom products, making it easier to replace 

underlying technology with mainstream products 

acquired from the commercial marketplace. The 

second phase includes modularizing the combat 

system software, which improves the ability to 

make technology changes in one area without 

incurring a significant impact on other unrelated 

software functionality. Figure 2 shows some of the 

keys aspects in migrating to OA.

Surface Navy Combat System Objective 

Architecture

The surface combat system community is 

aligning its combat management systems to a 

common software product line architecture. 

Naval Surface Warfare Center, Dahlgren Division, 

(NSWCDD), engineers have played a key role 

in the development of the Surface Navy Combat 

Systems Software Product Line Architecture: 

Architecture Description Document (ADD).4

The ADD describes the end-state objective 

architecture precepts and patterns to be used in 

architecture development. Many of these precepts 

and patterns are motivated in part by a need to 

manage change in the computing technology base 

on which combat systems are hosted. For example, 

the ADD describes a component framework 

pattern that defines a common set of Application 

Program Interfaces (APIs) providing access to 

software infrastructure and management services. 

This approach allows the computing 

technology supporting the implementation 

of those services to evolve in a manner that is 

decoupled from the APIs. The ADD invokes 

the use of a multitiered architecture, shown in 
143

Managing Computing Technology Change

for Surface Navy Combat Systems

Figure 3. Objective Architecture Multitier Architecture

Figure 2. Migration to Open Architecture

Figure 3, which decouples the processing tier 

from the data tier and the presentation tier. This 

approach allows the technology for managing 

data and for presenting information to an 

operator to evolve separately from the business 

logic of the combat system.

Acquisition Constructs for 

Managing Technology Change

The surface domain of the Navy recently 

established two processes to more effectively 

maintain and modernize its combat systems. The 

Advanced Capability Build (ACB) process allows 

incremental fielding of warfighting capability 

upgrades to surface Navy combat systems on a 

2-year cycle. New and upgraded capability can 

be deployed based on Fleet need, the readiness 

of the capability, and the available budget for an 

ACB. ACBs are decoupled from the upgrade of 

computing technology, which are managed via the 

Technology Insertion (TI) process. 
144

Combat Systems Engineering & Integration

Element-Level Systems Engineering

Figure 4. Combat System Computing Technology Areas and Associated Standards Bodies

This TI process is intended to replace and/

or upgrade combat system computing hardware 

and software directly tied to the hardware to 

take advantage of technology advancement. 

The Navy develops a new TI baseline every 

4 years with each ship receiving every other 

TI (i.e., an 8-year cycle for an individual ship). 

The combination of the ACB and TI processes 

ensures that Navy systems keep pace with 

computing technology advances and that 

capability enhancements reach warfighters in a 

timely manner.

Engineering Constructs 

for Anticipating Computing 

Technology Change

To successfully field and sustain combat 

systems, the Navy must anticipate technology 

change so it can plan for and adapt to these 

changes when they occur. Failure to adequately 

anticipate technology change can have a 

significant adverse effect on the ability to deploy 

and support a combat system over its lifetime.

Standards Participation

NSWCDD engineers have successfully 

shown value by participating in organizations 

that are defining, enhancing, and maintaining 

standards for key combat system technologies. 

In these forums, the Navy articulates its unique 

requirements for operating and certifying these 

technologies for use in combat systems. Some key 

combat system technology areas and the standard 

bodies that drive the development of those 

technologies are illustrated in Figure 4.

 NSWCDD subject-matter experts 

(SMEs) represent the Navy in a number of key 

Department of Defense (DoD) Information 

Technology Standards Committee (ITSC) working 

groups that select IT standards for all of DoD. 

Engineering Initiatives

An Engineering Initiatives Team at NSWCDD 

has performed various initiatives to demonstrate 

uses of emerging technology in combat system 

domains. In 2009, they demonstrated and 

quantified the viability of inserting solid state 

disks into legacy Aegis Weapon System baselines. 
145

Managing Computing Technology Change

for Surface Navy Combat Systems

The experiment showed the advantages of using 

a solid-state drive, and data from the experiment 

was used to produce a business case analysis that 

identified the cost point where total replacement 

of hard drives with solid-state drives provides a 

positive return on investment.

Engagement with the Academic Community

Another activity that has proven successful 

in understanding the long-term direction of 

computing technologies is working with the 

academic community. The academic community 

often focuses on advances in areas whose 

time horizon is farther out than where the 

commercial product community is focused. 

Advances developed may prove to be feasible 

for incorporation into future commodity COTS 

products. 

Engagement with DoD Research Organizations

Participation with DoD research 

organizations (e.g., Defense Advanced Research 

Projects Agency (DARPA) and the Office of 

Naval Research) may enable larger DoD and/

or Navy efforts to provide critical information to 

a participating Navy program in a cost-sharing 

effort. Working together provides a greater 

opportunity for the combat system community 

to influence research activities in a direction 

that meets their requirements. It also provides 

a better likelihood of technology transition for 

the researchers since the resulting technology 

innovations are targeted to the needs of the 

combat systems. 

Technology Forecasts

For the Navy to mitigate the risks associated 

with leveraging technology developed in the 

commercial community, it must anticipate the 

direction of commercial technology development. 

While attending trade shows and reading trade 

journals might give insight into the near- and 

mid-term directions of these technologies, 

NSWCDD engineers must investigate other 

approaches to expand their insight into the midand long-term future directions. Technology 

forecasts written for key computing technologies 

are one way to gain insight into the mid- and 

long-term future directions. These forecasts 

need to be periodically updated and authored by 

multiple SMEs for each computing technology 

area. 

Relationship Between 

Engineering and Acquisition 

Constructs for Managing 

Computing Technology Change

Figure 5 shows some of the relationships 

between the engineering and acquisition 

construct for managing computing technology 

Figure 5. Examples of Relationships Between Engineering and 

Acquisition Constructs for Managing Technology Change
146

Combat Systems Engineering & Integration

Element-Level Systems Engineering

Figure 6. Examples of Relationships Between Engineering and Acquisition Technology 

Management Constructs over Time

change. As illustrated, these constructs are highly 

interdependent. 

 NSWCDD is engaged at each and every 

construct. The timeline relationship between 

the engineering and architectural constructs 

for managing computing technology change is 

shown in Figure 6. As illustrated, the relationships 

between the constructs are highly timedependent. 

Conclusion

NSWCDD personnel are involved in all 

aspects associated with the management of 

today’s computing technologies associated 

with the surface Navy’s combat systems. The 

practical experiences associated with current and 

emerging computing technologies have enabled 

NSWCDD’s engineering staff to take key roles 

in defining and acquiring the next generation of 

computing technologies. As a result, warfighters 

will benefit from more effective and efficient 

computing system technologies necessary to 

support surface Navy combat systems long into 

the future. 

Acknowledgment

We would like to thank Neil T. Baron, 

NSWCDD, for his leadership and guidance 

concerning the management and integration of 

computing technology change for surface Navy 

combat systems.

References

1. Under Secretary of Defense for Acquisition, Technology, and Logistics, “Operation of the Defense Acquisition System,” DoD Instruction 5000.02, 8 December 2008.

2. Defense Acquisition University, “Defense Acquisition Guidebook,” http://akss.dau.mil/dag/DoD5000.asp, Accessed on 

19 February 2010.

3. Deputy Chief of Naval Operations (Warfare Requirements and 

Programs), “Requirement for Open Architecture Implementation,” Memorandum, 23 December 2005.

4. Program Executive Office Integrated Warfare Systems, “Surface 

Navy Combat Systems Software Product Line Architecture: Architecture Description Document,” Version 1.0, 31 July 2009.