Combat Systems Engineering & Integration
Combat-Systems-Level Systems Engineering
Operational View
Systems and Technical
Services View Standards View
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 net-
centric environment (NCE).1 DoDAF supports the development of interoperating
and interacting architectures by defining three related views of architecture:
96
Architecture Development for Shipboard Combat Systems
Figure 1. Information Linkages Among Architectural Views
Operational View (OV), Systems and Services 6. Present results in accordance with deci-
View (SV), and Technical Standards View (TV). sion-maker needs
Each view is composed of sets of architecture The architectures for surface platforms and
data elements that are depicted via graphic, their subsystems are first documented within
tabular, or textual products. Information a system Capability Development Document
linkages among architectural views are shown in (CDD). A CDD captures the information
Figure 1.2 necessary to develop a proposed program,
normally using an evolutionary acquisition
NSWCDD Architecture strategy. The CDD outlines an affordable
Experience increment of militarily useful, logistically
NSWCDD systems engineers use DoDAF supportable, and technically mature capability.4
architectural standards for communication To function most effectively, the realized
between the operational and acquisition com systems architecture must maintain a connection
munity, as well as for supporting system develop to the CDD architecture, requiring that the
ment. Architecture development is an iterative system architects and CDD architects have
process and continuous evaluation of the views clear and consistent process associations and
must occur throughout development. Upon relationships. In recent years, the surface
completion of DoDAF views, an evaluation, platform community has built relationships
to include traceability to requirements and with CDD architects who have facilitated the
stakeholder review, must be performed to ensure maturing of architecture products through
consistency among all views. the systems engineering process, rather than
DoDAF defines a six-step process to ensure replacing those products with unique systems
the developed architecture is fit-to-purpose:3 engineering products.
1. Determine intended use of architecture While the CDD provides high-level system
2. Determine scope of architecture architecture within the context of other DoD
3. Determine data required to support archi- acquisitions, a System/Subsystem Design
tecture development Description (SSDD) provides system-level
4. Collect, organize, correlate, and store ar- architecture details. The SSDD describes the
chitectural data system- or subsystem-wide design and the
5. Conduct analyses in support of architec- architectural design of a system or subsystem.5
ture objectives As depicted in Figure 2, which was adapted
97
Combat Systems Engineering & Integration
Combat-Systems-Level Systems Engineering
Figure 2. Systems Engineering Process
from Defense Acquisition University (DAU) the effectiveness and completeness of the
Systems Engineering Handbook 2001, the SSDD architecture. What follows is an example use of
documents the results of a systems engineering DoDAF for a notional system, USS Dahlgren,
analysis of operational requirements and the to illustrate the content of various architecture
force-level architectures from the CDD.6 The views and products. The example begins with
SSDD provides the allocation of top-level mission threads.
requirements, functions, and interfaces to
system elements, components, and software. Mission Threads
A surface platform may have multiple SSDD Mission threads provide specific scenarios,
documents for each major system element. environmental conditions, and event sequences
Historically, prime contractors have developed for a set of missions. It provides the context
SSDD documentation; however, the surface for operational activities and operational
community is moving toward government- event-trace description diagrams. An example
developed, top-level architectures to facilitate of a surface warfare thread for the notional
product line alignment of enterprise systems. USS Dahlgren example is provided below:
This approach supports delivery of common
product line components across combat systems USS Dahlgren receives notification from
with common functions. Combined Task Force (CTF) 151 Counter-
Piracy Operations that pirate activity within
NSWCDD Example Use of DODAF the USS Dahlgren Area of Responsibility
for a Notional System (AOR) has recently escalated, and attacks
NSWCDD engineers are at the forefront on commercial shipping are imminent.
of systems engineering and architecture USS Dahlgren processes recent AOR piracy
development. Their experience spans decades. intelligence and undertakes planning to
Based on lessons learned from previous surface search for and neutralize the pirate threats.
platform architecture development efforts, Planning is coordinated with USS Dahl-
systems engineers have learned that it is best gren Air and Ship Control Operations to
to simplify the design for both usability and establish voyage and search plans for the
readability to effectively evaluate and analyze mission. Plans are reported to CTF 151 and
98
Architecture Development for Shipboard Combat Systems
USS Dahlgren coordinates with the Joint development. The goal is to ensure data elements
Force Maritime Component Commander for are uniquely defined and commonly linked
authorization to proceed. Prior to mission across all operational and system views. This
commencement, USS Dahlgren coordinates approach provides a common denominator
with Naval Support Operations for required for understanding and comparing views across
resource and supplies. Once pirates have mission areas to aid stakeholders in the decision-
been localized, USS Dahlgren assesses po- making process.
tential threats for hostile intent. If deemed
hostile, USS Dahlgren determines which Operational View (OV) Products
weapons to employ—nonlethal, guns, mis- The next step in architecture development
siles, and/or unmanned air system—based is to define the operational architecture using
on threat characteristics. Once engaged, operational views (OVs). The OVs are directly
USS Dahlgren will assess effectiveness and related to the operational requirements and
reengage as necessary to neutralize the pirate concept of operations provided by the OPNAV.
threat. OVs, as described in Table 2, depict the nodes,
tasks, and activities performed by USS Dahlgren
and the internal and external resource flows to
Overview and Summary accomplish the mission. Additional operational
Information (AV-1) views, not depicted, are included in DoDAF to
Overview and summary information (AV‑1) assist in the architectural description.
provides a planning guide to define the who, As illustrated in Figure 3, the OV
what, when, why, and how for the project. An development begins with a High-Level
example is shown in Table 1. Additionally, AV-1 Operational Concept Graphic OV-1, which
provides the context in which the architecture provides a graphical representation of
exists, i.e., assumptions and constraints, USS Dahlgren’s missions, environment, and
publication and development status, schedule, interactions with external nodes.
and milestones.
System View (SV) Products
Integrated Dictionary (AV-2) Development of system views typically
The integrated dictionary (AV-2) creates a occurs as part of the systems engineer’s functional
common vocabulary for integrated architecture 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
99
Combat Systems Engineering & Integration
Combat-Systems-Level Systems Engineering
Table 2. Minimum Required Operational Views
Operational View Description
OV-1
Graphical representation of missions, environment, and
High-Level Operational Concept
interactions with external nodes
Graphic
OV-2
Illustrates the need to exchange information between nodes
Operational Resource Flow
and/or resources
Description
OV-4 Depicts key players, their command structure, and their
Organizational Relationships Chart relationships
OV-5a / OV-5b
Integrated summary of all operational activities and their input
Operational Activity Decomposition
and output flows
Tree / Operational Activity Model
OV-6c Illustrates the dynamic behavior of operational activities by
Event-Trace Description depicting the timing and sequence of events
Figure 3. USS Dahlgren High-Level Operational Concept Graphic—OV-1
100
Architecture Development for Shipboard Combat Systems
Table 3. System View Descriptions
System View Description SysML Approach
SV-2
A description of resource flows
Systems Resource Flow SysML Internal Block Diagrams (IBD)
exchanged between systems
Description
SV-4 The functions performed by systems SysML Activity Diagrams or modeled activity
Systems Functionality and the system data flows among hierarchy tree using a Block Definition
Description system functions Diagram (BDD)
SV-5 A table of activity diagram actions mapped to
Operational Activity A mapping of system functions back OV-5/6c activities. May require modifications
to Systems Function to operational activities to SysML tool database schema to automate
Traceability Matrix generation.
Provides details of system resource
SV-6 A table of item flows depicted on the SysML
flow elements being exchanged
Systems Resource Flow IBDs. Items may be modeled as blocks in a
between systems and the attributes
Matrix BDD.
of that exchange
represents Object Management Group (OMG) and the combat system engineers describing
Systems Modeling Language (SysML) standards, how the system will be used in various real-
provides a framework for the required systems world scenarios. System architecture products
engineering activities, while providing views define the physical and functional instantiation
that satisfy DoDAF SV requirements. Table 3 of the combat system required to provide
summarizes the relationship between system the operational capabilities at the required
views and SysML products. performance levels. The system architecture can
The initial definition of a system functional be used to determine the development cost to
architecture traces operational activities migrate from existing program of record combat
to system functions. These functions are systems to the objective design.
documented in a DoDAF Systems Functionality Moreover, the surface Navy has been
Description (SV-4a). Each operational activity actively transforming from the acquisition
in the OV-5/6c products may yield one to many of independent platforms to a product line
mappings to functions in the SV-4a in order approach to provide maximum mission
to realize the required system capability. This capability across multiple platforms within
mapping is depicted in an Operational Activity budgetary constraints. The combat systems
to Systems Function Traceability Matrix (SV-5a). engineers, therefore, need to identify
For example, the “Fire Missile” activity in an OV- opportunities for implementing existing product
5/6c may require “Initialize Missile” and “Launch line components within the system architecture.
Missile” functions in an SV-4a. This relationship For new components, system architecture
is usually depicted in a matrix with the initial should be defined in terms of concordance to the
functional hierarchy depicted in a tree. Figure 4 product line architecture to the extent possible
provides a sampling of operational and system to provide the best return on investment to
views developed for USS Dahlgren. the Navy Enterprise. Operational architecture
mission threads should be very similar regardless
Application of the Architecture of which ship classes are fielding the systems and
Once the USS Dahlgren architecture is conducting the missions.
defined, engineers need to address how the In fact, it is desirable to fight missions
architectural products will be used in the combat similarly and consistently across classes to
systems engineering and acquisition effort. improve interoperability, mission coordination,
Operational architecture products are part of the and training. A common repository of
“contract” between the operational fleet forces system views and tools with standardized
101
Combat Systems Engineering & Integration
Combat-Systems-Level Systems Engineering
Figure 4. USS Dahlgren Systems Engineering Products
102
Architecture Development for Shipboard Combat Systems
system functions, functional definitions, and Operational View
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. Systems and
By designing and developing architecture using Services View
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. Technical
4. ACQuipedia;https://acc.dau.mil/CommunityBrowser. Standards View
aspx?id=28825&lang=en-US; accessed 18 Nov 2010.
5. Acquisition Community Connection; https://acc.dau.mil/Com-
munityBrowser.aspx?id=59129&lang=en-US; accessed 18 Nov
2010.
6. DAU, Systems Engineering Fundamentals, 2001.
103
