Warfighting capabilities are increasingly dependent on the speed, safety, and maintainability of complex systems integrations involving diverse platforms. While System of Systems (SoS) integration is inherently complex and expensive, it is increasingly so due to the combinatorial nature of the integration effort and is further exacerbated by the increasing speed of technology advancement.
ASN RD&A Secretary Geurts has stated that “Velocity is its own competitive advantage”. Unfortunately, as applied to traditional methods of SoS integration, velocity is not readily achievable.
Traditional integration methodologies have been successful in handling the lower levels of interoperability that address transport and syntax of data. The DevSecOps initiative, tooling, and rigorous engineering practices focus on efficiencies related to what the paper refers to as the Build and Deploy aspects of integration, but they defer issues of integration relationships and composability. When an integration by commonality approach is consistently applied, a traditional approach is sufficient. However, when commonality is not suitable, semantic connection and composition of behavior must be explicitly addressed through model-based, machine-actionable documentation.
Beyond Build and Deploy, this paper proposes the interoperability paradigms Relating and Composing. Through these paradigms, the paper will examine more advanced interoperability concepts. These approaches facilitate faster, safer and more scalable integrations through semantic, model-enabled automation. The rigorous engineering, testing, and performance necessary in the defense domain requires more attention on these latter two concepts, and, in fact, future innovations in defense demand it.
Throughout the paper the three paradigms are correlated to the Conceptual Levels of Interoperability Model (At what level of interoperability is one operating?) and, where applicable, Interface Documentation Maturity Levels (How does one achieve this level of interoperability?). Through these examinations, the paper explores state-of-the-art methods to achieving integration at velocity.
In order to realize velocity at scale among our ever-advancing warfighting Systems of Systems (SoS), the practice of free-text, prosaic documentation must be replaced by methodologies that enable machine-readable, machine-exploitable documentation. Neither science fiction nor artificial intelligence, it is possible to automate the process of integration by clearly and unambiguously documenting systems.
As enemies continue to adapt to the US’s advancing technology, so must the US adapt to their advancements. “Out-spending” other sovereign nations is no longer affordable. The industry must identify and implement an approach to integrate systems faster and more accurately.
When discussing advancements, the difference between warfighting technologies and the tools that enable those technologies might seem obvious: these two are often confused. Consider the following statement from the NAVWAR requirements management lead upon completion of NAVWAR’s first Digital Twin on the USS Abraham Lincoln.
“Modeling complex systems in a digital environment is like working on a giant puzzle, where multiple people are working separate sections of the puzzle. It is not until the people begin to communicate that they are able put their sections together to reveal the final image. These systems are like separate sections of the puzzle, and in the past we have waited until fielding to put the puzzle pieces together, but with digital engineering we are putting the pieces together before fielding, allowing us to address issues before we deliver the system to the warfighter” (Navy, 2019).
The advancement highlighted here is the tooling that enabled the systematic development and sharing of information during the Build and Deploy process. The tooling is automated, improving development and testing processes that enable increased value in the warfighting technology. That said, the warfighting technology itself is not fundamentally changed through this process.
In this paper, tooling advancements are secondary to the advancement of the actual warfighting technologies and the management of those technologies. Automating integration, while achieving higher levels of interoperability, fundamentally changes not only the way in which systems are designed and developed but also how they are deployed and managed.
The benefits of digital transformation are key, as are the related methodology and tooling advancements. These advancements alone, however, are not enough. The rigorous engineering, testing and performance required in this domain necessitates automation, not only for sharing of documentation, but in the actual integration and testing process. Leveraging the successes in the digital transformation strategy, the industry must also push for innovations in the interoperability of the systems developed with these tools.
What is needed is a new way to more rapidly adapt existing systems to meet changing mission requirements and to introduce new capabilities into pertinent systems. Moving current process and design techniques into digital workflows and model-based representations alone will not fully address the need for flexibility. Too often, models codify a specific implementation and a specific system’s design constraints, dramatically limiting their adaptability to future needs.
The ‘new way’ is not some new protocol, communications standard, hardware fabric, functional allocation, or even new modeling standards and representations. These are necessary but not sufficient. The ‘new way’ involves leveraging Model Based Systems Engineering (MBSE) and DevSecOps but requires a very different approach to integration which explicitly defines the semantic relationships and the behavioral composition in the design of the architecture. Ongoing initiatives should be leveraged while using advanced methodologies to ensure that data models are fit for machine logic and processing consumption. Such models will contain the right sets of related and linked information that inform optimization and algorithmic approaches to procedurally generate integration software and infrastructure.
INTEROPERABILITY AND INTERFACE DOCUMENTATION
In order to constructively examine the subject of systems integration in relation to current and future efforts, one must first provide a baseline against which the relevant topics may be referenced. It is particularly helpful to discuss integration with relation to two key concepts: The Levels of Conceptual Interoperability Model (Tolk, 2004) which encompasses five (or six, by some sources) Levels of Interoperability (LOI) and Interface Documentation Maturity Levels (IDML) which define seven IDML and suggests additional levels of maturity beyond the first seven (Hand, Lombardi, Hunt, & Allport, 2018).
Although various other interoperability models exist, the Levels of Conceptual Interoperability Model (Figure 1) was developed with the intention of bridging technical and conceptual design. The greatest benefits of interoperability, including scalability and adaptability, are only achieved at the higher levels of interoperability requiring conceptual design.
Figure 1: Levels of Conceptual Interoperability adapted from “Composable Mission Spaces and M&S Repositories - Applicability of Open Standards" (Tolk, 2004)
The IDML is an additive maturity model progressing towards the most advanced practices in interface documentation (Figure 2). The IDML is based on the premise that, at a fundamental level, it is the rigor and specificity with which interfaces are documented that enables an architecture’s interfaces to be managed, understood, shared, and extended. Since interface documentation is so key to integration, the management and scalability of that documentation provides a litmus test for categorically identifying levels of interoperability.
Figure 2: Interface Documentation Maturity Levels adapted from “IDML: An Introduction” (Hand, Lombardi, Hunt, & Allport, 2018)
While the Levels of Conceptual Interoperability Model provides a context for what level of integrability is being discussed, the IDML provides a context for how, or through what methods, LOIs 1-4 may be successfully achieved. The latest IDML does not address, however, through what methods Conceptual Interoperability (LOI 5) may be realized. Such a framework is yet to be developed and could provide significant benefit to the use, extent, and maintenance of future interoperability initiatives.
BUILDING AND DEPLOYING
Today there is significant momentum behind the “Build and Deploy” paradigm. In many DevSecOps initiatives, the focus is centered on improved efficacy and efficiency of hardware and software design, development, testing, and deployment. Many of the programs instituted as a part of DevSecOps are both material and beneficial to any integration project, including the adaptability and efficiency of the DevSecOps Lifecycle model, process and communication automation and the integration of security throughout the lifecycle (DoD CIO, 2019).
When it comes to integration, however, the DevSecOps Reference Design defines Continuous Integration as going one step further than Continuous Build “…with more automated tests and security scans. Any test or security activities that require human intervention can be managed by separate process flows.” The practice’s goals of reduced mean-time to operation, increased deployment frequency, and updates “at the speed of operation” address integration only through the automated testing of that integration. Neither automated integration itself nor automated maintenance of those integrations is addressed. In fact, the entirety of what content (syntax, semantics, behaviors) to integrate and how to perform those integrations prior to testing is left to the integrator (DoD CIO, 2019).
When hardware and software needs to be connected, these connections are facilitated through Hardware and Software Architectures, and the connections become a part of the Build and Deploy process. Although there are a great many initiatives right now to improve Build and Deploy, when it comes to the integration of the relevant deployed systems, traditional methods of integration prevail. As such, only the lower levels of interoperability are reached.
Automating the Build and Deploy aspects of software development reaps a great many benefits; however, it simply does not address integration connections or the composition and orchestration of behavior.