Your Page Title
System of Systems Engineering Guidance
________________________________________________________
By William F. Ormsby
Every day, all around the globe, U.S.
Navy officers and sailors make decisions
to accomplish their assigned missions.
The decisions are influenced by the
capabilities possessed by the units
assigned to the mission. As defined in
the Chairman of the Joint Chiefs of
Staff Instruction (CJCSI 3500.01G; 15
March, 2012) a capability is:
“The ability to achieve a desired
effect under specified standards and
conditions through a combination
of means and ways across doctrine,
organization, training, materiel,
leadership and education, personnel,
facilities and policy (DOTMLPF-P)
to perform a set of tasks to execute a
specified course of action.”
This multi-faceted capability construct
has served as a model for Naval
Operations and materiel procurement
for many years. However, as attrition
warfare has been replaced by network
centric operations, including cyber
warfare, the complexity of engineering
effective weapon systems has grown.
Engineering guidance has evolved to
handle the increased complexity. For
example, the highly compartmented
system engineering disciplines used
to develop the Submarine-Launched Ballistic Missile
(SLBM) in support of the Strategic Triad Concept
are obsolete for systems used in more modern and
collaborative combat scenarios. System of Systems
(SoS) engineering guidance responds to: the deficiencies
in traditional system engineering practices;
the resulting Fleet’s dissatisfaction with strike-force
interoperability; and the crucial need for integrated
sensor, weapon, and command and control (C2) systems
that support coordinated decision-making in
dynamic threat environments.
The Deputy Assistant Secretary of the Navy
(DASN) for Research, Development, Test, and Evaluation
(RDT&E) Chief Systems Engineer (CHSENG)
is the naval technical authority within the acquisition
structure for ensuring compliance with overall
Department of the Navy (DON) Enterprise Architecture
(EA) policy along with integration and interoperability
of current and future DON acquisition programs.
The DASN has the responsibility to provide
guidance for SoS engineering processes to translate
mission operational requirements into measurable
and testable mission performance requirements. The
office of the Assistant Secretary of the Navy Research,
Development and Acquisition (ASN (RD&A)) Naval
System of Systems Engineering Guidebook Version
3.0, was developed to aid Program Managers and
System of Systems Engineers in the performance of
their duties. It is intended to support the Naval acquisition
community, particularly Program Executive
Offices (PEOs), Systems Engineering Integrated Product
Teams (SEIPTs), and Mission Area Systems Engineers
in implementing capability-based acquisition
in accordance with SECNAVINST 5000.02.
This article describes the latest version of the SoS
Engineering Guidebook including recent updates
made by a national technical team of subject matter
experts composed of Naval Sea Systems Command
(NAVSEA), Naval Air Systems Command (NAVAIR),
and Space and Naval Warfare Systems Command
(SPAWAR) personnel. The guidebook promotes a
shared understanding among engineers developing
various warfare systems, of effects desired by operators
who employ those collective systems in accordance
with a chosen course of action. This concept of “starting
with the end in mind,” a common mission model,
leads to fewer inconsistencies in system designs and
reduced costs associated with integration of systems
conceived to deliver mission enhancements. Excerpts
from the guidebook are highlighted in this article to
stimulate greater efficacy in acquisition and improved
operational readiness in support of National Security.
Integrated Capability Framework (ICF) –
Justification for and Nature of Changes
The SoS Engineering Guidebook V3.0 substantiates
its content and value by describing Carrier Group
issues first identified in 1998. It was determined that
target track information being passed between platforms
resulted in track ambiguity (1 threat aircraft
with 3 different tracks and 3 different IDs) which
negatively impacted Battlegroup interoperability (see
Figure 1).
As a result, initial policy was set in place to
ensure Warfare Systems are fully developed, mature,
reliable, and have completed interoperability testing
in a systems of systems environment prior to
deployment. The current guidebook recognizes that
no amount of end item testing will make a system
more interoperable, and that modern mission modeling
techniques can be used to preclude system designs
that would lead to similar interoperability issues.
In late 2010, the Chief of Naval Operations (CNO)
hosted a summit on Integration and Interoperability
(I&I) where he was briefed on a concept for improving
acquisition practices that would resolve many issues
that were degrading Fleet readiness. Subsequently,
actions were taken to convene a Multi-SYSCOM
team to define and validate an Integrated Capability
Framework (ICF) that formalizes a core set of data
elements, relationships, and taxonomies, as shown in
Figure 2, that improve efficacy of integrating systems
into Fleet missions.
The ICF includes: Department of
Defense Architecture Framework (DODAF) models
to distill the critical context required to decompose
mission-level requirements into SoS and component
system functional and performance requirements;
implementation guidance and associated roles
and responsibilities for interaction with the Fleet
to authoritatively capture Fleet needs; references to
authoritative sources, data taxonomies, and common
standards for capturing the complex relationship
between the ICF products, across platforms, systems,
and components.
Improving warfighting capability in a measureable
way requires identification of all types of data
that contribute to the measure. The ICF Data Model
includes the relationships and dependencies between
data types and can be shared with various stakeholders.
Cursory review of the ICF Data model reveals
SoS engineering disciplines are less about the system
and more about the data related to the system, either
directly or indirectly. The number of relationships
among these twelve data elements, each of which
consists of multiple items, exposes the complexity of
SoS engineering. That is, decomposition of system
behaviors (i.e., functions and timing) requires contextual
details of all eleven other data elements. Modern
tools help manage the complexity, and the SoS guidebook
describes methods for modularization that allow
data collection that results in a mission model with
maximum cohesion and minimal coupling. The ICF
Mission Model development focuses on:
- Describing the mission in operational
language through development of Concept
of Operations (CONOPS) and Tactical
Situation (TACSIT) description documents;
- Describing the capabilities required to
accomplish the mission;
- Modeling the activities, resource exchanges,
and system functions that are used to
accomplish the mission.
A historical example of mission decomposition provides
a basis for understanding updates to SoS engineering
guidance. Figure 3 is a universal high-level
operational concept graphic (Operational View, OV-1).
Such a graphic, together with a textual description
of a concept for operational mission performance, is
often considered the initial step in mission modeling.
In the 1950s, the mission was to keep the Soviet Union
at bay. The CONOPS for this mission required the
United States to have thousands of nuclear warheads
and three ways to deliver them on target. The three
legs of the nuclear “triad” included: heavy bombers,
Submarine-Launched Ballistic Missiles (SLBM), and
land-based intercontinental ballistic missiles. Three
technologies “saved the Navy’s bacon.”1 Miniaturized
warheads, solid propellants, and very high accuracy
gyros made it possible for the Navy to start the Polaris
SLBM Program. Policy in the 1950s established fire
control (FC) of the SLBM capability as an inherently
government function, and the SLBM FC system has
continued to be developed by government scientists
and engineers at Naval Surface Warfare Center Dahlgren
Division (NSWCDD) ever since.
Over the years, the Polaris Program evolved to the
Poseidon Program and then to the Trident Program,
each with greater targeting accuracy requirements.
SLBM engineering disciplines were thus influenced by:
- Geodesy, that branch of applied mathematics
which determines the shape, curvature, and
dimensions of the earth;
- Geopotential, the potential of the earth’s
gravity field;
- Satellite Geodesy, the use of artificial satellite
techniques to measure the distance between
launch locations and target locations and
the gravitational forces on ballistic missiles
during flight.
Within this context, the platforms and systems represented
in Figure 3 that are relevant to SLBM become
apparent and performance measures are understood.
An expectation is created for a description of an information
exchange (Department of Defense Architecture
Framework (DODAF), OV-3), together with
the technical standard profile (DODAF, TV-1), that
codifies the conditions that govern ballistic missile
trajectories, bounds the maneuvers of submarines
relative to ballistic missile targets as a function of
launch location, and influences the designs of fire
control and guidance systems.
To characterize the mission, one must fully understand
and characterize the environment upon which
the mission will be exercised. Continuing our SLBM
example, Figure 4 illustrates the TV-1: the World
Geodetic System (WGS84), “a model of the world”
that resulted from years of data collection. It shows
that the earth is not perfectly spherical; rather certain
locations (blue) are below the reference ellipsoid, and
other locations (orange) are above. The undulations for
given launch and target locations are easily calculated
and enable achievement of required accuracy.
Today we are dealing with new threats and with
inter-dependent missions. The advances of U.S.
adversaries, such as mobile missile launchers; the
Navy transformation to network-centric operations,
including use of unmanned air vehicles (UAVs); and
multi-mission requirements have created capability
dependencies that require greater collaboration
with the Fleet. More iteration between the ICF data
elements is anticipated to discover the dominant
parameters of missions. The success of the SLBM
Program confirms the return on investment in a
commitment to “modeling the world” and the need
for collecting data over long periods. Operating on
what we simply believe to be true (spherical earth)
can hinder the development of the required precision
for the machine operation to achieve mission
success. Future data collection will be conducted in
accordance with capability-based modeling practices
that describe dependencies and enable predictable
mission performance across kill-chains.
The nature of changes described in the SoS Engineering
Guidebook fulfills the Navy I&I Charter to
provide more informed input into the existing Planning,
Programming, Budgeting and Execution, and
Joint Capability Integration and Development System
processes. The changes leverage existing end-to-end
effects/kill chain gap analyses efforts and requires collaboration
among operational and acquisition subject
matter experts. The guidance enables a disciplined
assessment of I&I gaps at the mission level and development
of holistic (i.e., DOTMLPF) recommendations
to inform investment decisions. The changes
mandate development and use of authoritative mission
models to ensure the system requirements are
complete, consistent, correct, and testable. Version 3
of the guidebook also describes activities to govern
the evolution of mission models to converge the
designs and implementations of all systems across
an effects chain.
One basic tool to help characterize parameters
within the ICF is the use of Modeling and Simulation
(M&S). Models and simulations should continue to
be used as needed to support requirements definition,
analyze the Force Package configuration and design,
and mitigate identified risks through engineering
analyses. M&S supports the assessment of functional
and performance characteristics, integration and
interoperability, network throughput and bandwidth,
supportability, and Human System Integration (HSI)
issues such as maintainability, usability, operability,
and safety. Moreover, M&S provides the ability to
predict SoS performance as specified before system
design and testing.
Managing the System of Systems Acquisition
The guidebook describes the desired, iterative
nature of systems development noting that the verification
feedback loop at each level of the system life
cycle is the mechanism for providing development
control. Iteration of the design reduces the risk of
developing a system that does not meet the needs
of the user. As stated in the Defense Acquisition
Guidebook, “The ultimate purpose of the System
Engineering (SE) processes is to provide a framework
that allows the SE team to efficiently and effectively
deliver a capability to satisfy a validated operational
need.” Claiming that current derivation of system
functionality is done at the discretion of the individual
Program Managers, the guidebook promotes
significant use of venues that take system engineers
into Fleet operations, where DOTMLPF capabilities
and limitations are experienced first-hand.
The collaboration on mission-based test design and
Fleet Exercise and Experimentation events (FLEX) are
highlighted as advancements in mission engineering.
These venues are fleet-led and fleet-driven, and they
establish fact-based assessments of baseline capability
and fully vetted evaluations of concepts of future capabilities. Figure 5 portrays a mission engineering
life cycle and shows how I&I activities exploit an ICF
to provide continuity of Fleet insight throughout the
life cycle of all systems in an effects chain.
While a naval governance process for a mission-
level system of systems has not yet been established,
the guidebook prescribes business processes
that would govern the execution of those practices to
ensure integrity in the acquisition of horizontally integrated
capabilities. It defines the attributes of a governance
process that will provide mission engineers
the top-down authority to exercise the disciplines
described in the guidebook. The governance is based
on the premise that PEOs, PMs, and system engineers
recognize the dependencies among the many systems
employed in a kill-chain to achieve a desired operational
effect. Furthermore, the program manager’s
number one responsibility, “to deliver systems to
satisfy validated warfighting requirements at optimal
life-cycle cost,”3 is best achieved through governance
described here. The roles of organizations identified
in Figure 6 are defined in the SoS Engineering Guidebook
to achieve the goals of the Navy Integration
and Interoperability Charter, which was signed and
promulgated by the Vice-CNO on December 19, 2012.
The Navy I&I Charter endorses a business process
for the organizations to interact from a mission area
effects/kill chain perspective, to develop integrated
solution recommendations, to inform investment
decisions, and to verify all system dependencies have
been implemented. Figure 7 illustrates the temporal
aspects of an effective I&I battle rhythm that follows
the traditional DoD two-year Program Objective
Memorandum (POM) cycle with overlap from
cycle to cycle.
The information required from mission engineers
to support effective I&I governance becomes clear
during the mission decomposition activities. Figure 8
illustrates such activities at the various organizational
levels (vertical) and in the integrated capability phasing
timeframes (horizontal).
Examples of past activities are described below to
illustrate the data collection activities highlighted in
Figure 8, and the use of data to support acquisition
decisions.
Develop Baseline System Architecture and “To-Be”
System Phasing Options: In the early 1980’s,
NSWCDD scientists and engineers used the WBS-
72/84 model, which was developed for SLBM, in
work with the Naval Research Laboratory (NRL)
in developing optional constellations of the Global
Positioning System (GPS). The GPS architecture,
i.e., the number of satellites; the number of orbital
planes; the inclination of the orbital planes;
and the angular separation of satellites in each
plane, was evaluated to ensure reliability and availability
of the system. While the first GPS Block I
satellite was launched in 1989, GPS modernization
continues to meet growing military, civil, and
commercial performance and accuracy needs.
The use of GPS-enabled capabilities is critical
to modern combat operations, especially those
employing UAVs.
Validate System Models and Recommend for Use: In the mid 90’s the Navy was adrift waiting for
entrance criteria to be met prior to an SLBM readiness
assessment event. Policy held that “demonstration
and shakeout” (DASO) tests must be
preceded by fire control simulations and guidance
system simulations that produced the same
predicted outcome. Until current mission engineers
at NSWCDD were consulted, the cause for
different M&S predictions was unknown. Mission
engineering data was used to reveal discrepancies
between guidance system design specifications
and source code implementation. Once the source
code implementations were represented in FC
models, the simulations produced DASO predictions
that met entrance criteria and the readiness
assessment commenced.
Identify “To-Be” Mission Model Data Requirements: In the summer of 2000, the National Missile
Defense (NMD) Joint Program Office (JPO) was
scheduled to report to Congress with a “Deployment
Readiness Review.” A primary question
to be answered, which was posed by Army and
Air Force operational test agencies, was, “are we
deploying bulldozers to the right location (for placing
anti-ballistic missiles (ABMs))?” Engineers at
NSWCDD who had access to requirement specifications
for all five NMD components validated
the physical architecture of the NMD system of
systems in three steps. First, they partnered with
civilian Army and Air Force test engineers to get
the “as-is” ground-based test data and in-flight
test data that characterized baseline limitations.
Second, they used specifications for “to-be” NMD
performance requirements to develop credible
M&S of the specified SoS. Third, they collected
measures of effectiveness from simulations that
exercised new information exchanges to employ
NMD capabilities against stressing scenarios.
The historical anecdotes provided above are unique
in detail, but serve to convey the broader benefits of
mission modeling and simulation. However, there is
a recognized deficiency in number and comprehensiveness
of mission architectures. The cause, from the
perspective of this author, is that DODAF architecture
development has been “for compliance” and “in
isolation.” As a result, comprehensive, coherent, and
accurate mission models are not available to simulate
and predict outcomes of alternative Courses of Action
(COAs) for modern combat operations.
With promulgation of the Navy I&I charter—and
like the SLBM Fire Control function—integration
of individual contractor-delivered systems is now
recognized as an inherent government function. As
such, Multi-SYSCOM mission engineers will collaborate
with the ultimate purpose of delivering more
interoperable capabilities. The SoS Engineering
Guidebook V3.0 provides a vital tool for managing
acquisition activities to develop and use common
mission models, across multiple PEOs, to evolve operational
readiness.