Top left banner Top right banner
Bottom left banner Bottom right banner
Home : Home : Warfare Centers : NSWC Dahlgren : Resources : Leading Edge : I&I Leading Edge : Ormsby
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.

           


Article Images




Figure 1. Battlegroup Interoperability Deficiencies 



Figure 2. Integrated Capability Framework Data Model



Figure 3. Universal High-Level Operational Concept Graphic (Operational View OV-1)



Figure 4. EGM2008 2.5 Minute Geoid Heights2




Figure 5. Mission Engineering Life Cycle



Figure 6. DON Architecture Organization



Figure 7. Notional I&I Battle Rhythm



Figure 8. Organizational Interactions Required for SoS Engineering Governance

Article References

  1. Dr. Russell H. Lyddane, “Dahlgren – Times of Crisis”, June 1977.

  2. http://earth-info.nga.mil/GandG/wgs84/
    gravitymod/egm2008/
    egm08_wgs84.html

  3. SECNAVINST 5400.15C, 13 September 2007.