DoD technologies have traditionally relied on cyber-physical/software-intensive systems that are now widely available to all nations and non-state actors. The DoD's past practice of incorporating commercial-off-the-shelf (COTS) technologies on a system-by-system basis are insufficient to stay ahead of its adversaries and increase its pace of change for delivering innovation. The DoD thus needs new acquisition approaches that can achieve rapid delivery, flexibility, and capacity to provide continuous improvement to fielded capability.

This series of blog posts, adapted from a recently published paper, addresses these issues by establishing a DoD acquisition environment that is more efficient and capable of delivering much higher quality, with far greater innovation, in a fraction of the time. Our first post proposed a layered business and technical architecture model to help the DoD leverage modular component design practices that will establish more effective approaches for capability acquisition. In the second post, we explored this model in detail. In our third post, we examined key change drivers and organizational structures associated with our proposed model of acquisition. We also examined the impacts associated with the implementation and organizational structure of our proposed acquisition model. In this post, we examine the technical architecture for our proposed acquisition model.

Technical Architecture

The technical architecture described below flows from the business architecture, as shown in Figure 1 below. This overarching architecture begins with a set of technical reference frameworks (TRFs) that support the needs of military systems. A TRF is a published, standardized software and hardware environment (i.e., a standard implementation of open standards) that enable the deployment of functionality and (micro-)services onto target architecture(s).

Figure 1: Composition of Severable, Loosely Coupled Capabilities.

Several TRFs currently being used in isolated technical domains are good examples of collaboration between the DoD and industry consortia. These examples include the Future Airborne Capability Environment (FACE), Open Mission System (OMS), and the Common Afloat Networks and Enterprise System (CANES). These TRFs are being used as the starting point for creating company- or domain-specific reference implementations.

The TRFs also form the foundation for product lines. These product lines, in turn, support classes of reusable capabilities. From these reference implementations, product-line-specific architectures can be crafted and deployed as integrated capabilities.

Figure 2: Array of Related Technical Reference Frameworks.

By applying a well-orchestrated cascade of dynamically evolving, industry-supported TRFs, the DoD gains enterprise-level strategic advantage. Industry and government software and systems architects can transition the parent TRFs into local reference implementations. In turn, these local reference implementations can be used to create products that are inherently interoperable with reference implementations created elsewhere. Product lines can be spun out of these reference implementations for corporate reusable designs. These product lines can then be applied to spawn product-specific implementations that deliver unique capability instantiations to the field and/or fleet.

The full strategic value of TRFs is manifest through independent verification of the reference implementation and subsequent product line to support quick integration or removal with few dependencies to other modules. The resulting "plug and play" model provides a base capability of the installed infrastructure that is designed for flexibility and growth. The result is rapid and continuous delivery of new capability to the operational force.

Modular capability elements that are composed into a deployable product should be tested for platform integration in virtualized environments as soon as they are ready for use. This approach requires new means of continuously updating decoupled hardware and portable software in smaller increments. Cyber-physical capabilities should be expressed as loosely coupled modules (e.g., containerized micro-services) that can be plugged into the systems architecture with interfaces that are managed through discovery (Figure 3).

Figure 3: Virtuous Cycle of Rapid Feedback for Capability Integration and Deployment

Certification of these capabilities is performed as an overall product line, with platform-specific uniqueness certification needs addressed prior to shipment through a virtual test-bed/digital-twin construct. The new capabilities are then delivered to the platform (e.g., a ship, plane, or ground vehicle) as a pre-certified package, along with targeted hardware changes. The crew (not a civilian installation team) then follows a field procedure to install the changes through simplified--ideally automated--instructions and/or scripts. The results are then tested automatically on initiation to validate that (1) the certified configuration was accurately completed, and (2) the platform is ready for all its assigned missions.

Figure 3 also shows how a common data model can be used to support module-level interoperability, such that new functions can be discovered on introduction, complete with full semantic and syntactic descriptions. The Navy and Army have invested in at least two data models that are suitable for this purpose:

• ASW COI. The Anti-Submarine Warfare (ASW) Community of Interest (COI) Data Modeling Working Group is developing the U.S. Navy's ASW data management strategy. This open, approved-membership working group is sponsored by the Naval Sea Systems Command (NAVSEA). This data model ensures cross-platform and inter-operator common understanding of information (knowledge and capability-level interoperability). ASW is a team sport but requires a wide array of different platforms and systems to share data and knowledge across space, air, surface and submarine, and ocean floor to identify and properly handle a contact. A common data model facilitates lowering the barriers to common understanding and elimination of incompatible data in this unique military domain.

• Future Airborne Capability Environment (FACETM). FACETM facilitates integration of the information being used by different avionic components when composing flight-safety-critical avionics. This consortium was spearheaded by the DoD Military Departments (Navy, Army, and Air Force) as an open-system architecture approach to integrate different modules from multiple vendors to reduce barriers to entry, speed capability integration, improve delivery outcomes, improve business choices, and invigorate innovation. A data architecture is used as the linchpin to ensuring common understanding of data being created by different modules and to reducing integration risk and overall complexity. (Figure 4)
  

Figure 4: Layered Interoperability Architecture

A virtual testbed (digital twin) will be used to support automated testing and certification of a platform's delivered capability. This testbed can be deployed at as many development sites as needed by the development community. Capability tests can therefore be performed outside of a single integration laboratory, such that platform differences can be embraced and managed. As a result, the DoD will have the operational flexibility to fit out the capability set that a platform will need for the mission(s) it will perform. Hardware kits delivered to the DoD will have automatic test sequences to ensure that each kit is installed correctly and validated with respect to its digital twin.

These kits will be developed by Acquisition and Sustainment (A&S), so they can be installed by enlisted technicians. Finally, modern warfighting platform designs are based on standard equipment racks that are already in use on a platform-by-platform basis. These designs are all predicated on COTS infrastructure, such as an electronics-friendly 19-inch rack-mount design. Operational level and intermediate or depot-level actions are thus performed only under the most extreme conditions.

Gradients of Trustworthiness

A key challenge associated with modular, open-system architectures is to design for modernization and rapid change. To do so creates the presence of gradients of reliability, trustworthiness, and security within and across our systems. These gradients are generally unavoidable and require architectural attention to minimize the operational impact. They can also be beneficial, however, because they enable nimble approaches to integration of diverse payloads from diverse sources. The presence of these gradients must be addressed in architecting and re-architecting. Containers and micro services are an important part of the solution, but there are other aspects as well. The following are three examples of mechanisms to address the gradients:

• The design of connectors, among components in a system, which address issues ranging from governing data flows to enforcement of cross-domain data management policies.

• Technical methods for isolation and encapsulation, such as sandboxing, which can both protect sensitive components from the broader systems environment and, vice versa, enable safe use of less trustworthy components.

• Architectural patterns that reduce those areas requiring the deepest and costliest Test and Evaluation (T&E) practices, with consequent reduction in cost and delay. Examples of the latter are (1) flight controls vs. other avionics in the flight safety envelope/environment and (2) doer-checker patterns for advanced heuristic controls, such as those that might be guided by artificial intelligence/machine learning components that, in present practice, are relatively opaque to analysis and prediction regarding safety and security.

These examples highlight the unavoidable deep interplay of architectural technical choices and acquisition strategies.

Looking Ahead

In the fifth and final post in this series, we will examine the impacts associated with our proposed new acquisition implementation and organizational structure and provide an overview of our recommendations.

Additional Resources

This post was excerpted from a recently published paper, Capability Composition and Data Interoperability to Achieve More Effective Results than DoD System-of-Systems Strategies, which examines a new model of acquisition that applies a coherent set of methods to develop military mission capabilities as sets of composed modules.

Read an interview that Nick Guertin gave with Federal News Radio on how open systems are evolving to improve DoD buying power.

Read the SEI Blog Post by Don Firesmith Open Systems Architectures: When and Where to Be Closed.