Home : Home : Warfare Centers : NSWC Dahlgren : Dahlgren Resources : Leading Edge : I&I Leading Edge : Baron
The Science of Integration
"What Lurks in the Darkness of the Interstitial Space?" 
________________________________________________________

By Neil Baron

 Neil T. Baron
Distinguished Scientist for
Combat Control
Naval Sea Systems Command

Naval warfare and the warship have evolved out of necessity, human intellect, and technology to equitably compare with many other large complex machine developments of humanity, such as vehicles for manned space flight and exploratory devices such as subatomic particle accelerators. Developments demand the highest levels of integration. Investments are large, time scales are long, technical complexity is at an extreme, and constancy of purpose is continually challenged. Although visions are great, success in such large, complex, and highly integrated technical endeavors is rare. It is not enough merely to will it to happen. Success demands a holistic systems focus with the right tools and techniques to allow the best and brightest minds to see into the darkness of the unknown, to envision what could be from what is, to synergize and to maintain dedication from the initial vision until the very different realization of the machine at delivery.

Integration

Navies are unique in that they represent a nation’s significant capital investment due to the size and complexity of the machines (ships) utilized for combat. The architecting and engineering of machines of war demand the highest technical scrutiny during development to integrate the known, to invent the unknown, and to hold the public trust during the lengthy acquisition process, thus assuring the warfighter and the taxpayer that the best will be delivered in the end. The design of the naval warship and its role in the highly distributed nature of modern naval surface warfare, like other highly complex modern machines of today, requires striking a delicate balance among the domains of people, process, hardware, and software that when integrated successfully makes the holistic system perform. A primary role of the systems integrator is to bring such diverse domains together successfully, monitor their evolutionary progress, and reach an optimized balance between what is usually conflicting demands. Such domains are not naturally predisposed to interact successfully without a significant amount of engineering due diligence. Hidden flaws and faults, or even over reliance, in any one of the domains can lead to overall system failure.

The Navy laboratory structure, being able to execute the inherently governmental technical tasks, holds the kernel of necessary talent to technically succeed in such large scale complex systems engineering endeavors where flaw and failure lurk around every corner. The British researchers, Prencipe, Davies, and Hobday (2003) of the University of Sussex, address the many facets of successful engineering at the large complex system of systems level in their book, The Business of Systems Integration:1

The early phases of design require the communication of a vision for how the system should operate at the highest level, and then communicating the many visions of the lower level components among those that must ultimately integrate them together. When the visions become artefacts, any communication problems or just simple errors made in the design become obvious once those artefacts are connected to each other. All of the information that the designers used, either implicitly or explicitly, in the creation of the artefact become elements of that artefact. Unlike humans, who might not recognize the implications of lack of information or wrong information, the artefacts interact with each other the moment they are connected and operated together. This is why systems integration is the ultimate point at which social misunderstandings become manifest.

This article explores a technique for the systems integrator to better define and manage the highly complex nature of system to system dynamics, a critical element of engineering the system of systems that comprise modern naval warfare. This will be critical if the complexity of the overall machine is to be managed effectively and the desired system behaviors are to be realized and available on demand.

Integration: A Surface Warfare Example

Let’s illustrate the concept of integration through a simplified Naval Surface Warfare example. The radar and optical sensors of a surface combatant are challenged to see surface contacts over the horizon resulting in a limited operational picture for combat command and control. Utilizing a helicopter to extend the range of the surface combatant’s operational picture over the horizon is one option. The helicopter, if integrated with the surface combatant, could be used to identify, and if necessary, engage hostile targets at greater distances from own ship thus increasing effective battle space. With surface warfare engagement control resident on the ship and an airborne sensor feed and weapon on the helicopter, integrating the two platforms into a new expanded surface warfare capability is conceivable. See Figure 1. Integration would require the filling of the interstitial space between the two platforms to achieve the desired system of systems behavior and control. The two platforms would perform as one integrated system of systems to complete the mission.

Integration: Focusing on the Interstitial Space

Using the term “interstitial” helps differentiate and focus on the dimension between two objects that interact from the more traditional focus on the objects themselves. The subtle but key shift in concentrating on the interstitial from the physical enables the engineer to focus on the dimension of design where the interaction is housed and exercised. Simply put, this is where integration happens. The interstitial space, from classical use, is loosely defined as a gap between spaces full of structure or matter. It is usually thought of with physical properties such as an area, volume or space between two objects. For example, between the wheels and the engine of a car there is a transmission, drive shaft, a differential and an axle. These objects fill the interstitial space between the wheels and the engine to mechanically enable the function of powered mobility.

More generally, and even more interesting to the system of systems integrator, is to envision the interstitial space as simply the domain that enables key elements of behavior between two objects that have the potential to interact for some higher purpose. In this more general definition, the functional and logical interactions between geographically disparate objects can have their interstitial relationships filled with information-based technologies such as computer-based networks (both wired and wireless), protocols, data models, command signals, etc. In our surface warfare example, it is a data link and a set of data protocols with warfighting command functionality between a surface combatant and an off-board helicopter that realizes a ship controlled and helicopter executed surface warfare engagement.

The systems engineering of complex machines has contributed to huge intellectual leaps in understanding the physical interaction of things from the molecular level of atomic particle physics to the celestial level of astrophysics. On a more practical level, systems engineering has lead the technical advancement of machines to ease the human condition. The system of systems integrator must equally master the non-physical interfaces between systems and platforms that serve to establish functional and logical relationships between devices. Synchronizing, monitoring, and managing the behaviors of multiple systems to achieve a larger goal are usually the duties of the control system. The control system seeks to establish the physical, functional, and logical relationships that are realized through the interstitial space between system elements so they can behave as an integrated unit. System engineers need insights into the functional and logical dynamics of the interstitial space just as they currently enjoy today with technical insight into the physical dynamics.

Having a Model

Delving deeper into the interstitial space, some key models are presented below to describe the context around system integration and the interstitial space.

Physical, Functional, and Logical

There are three dimensions one must fully consider when integrating: the physical, the functional, and the logical. The physical dimension of integration is well understood. For thousands of years, it was the only form of integration that took place. With the modern digital age of electronics, communications, and the embedded computer, we are now witness to the significance of the other two dimensions of this model. The functional dimension, an intellectual construct to describe relationships, is characterized through the activity, purpose or task of the system or subsystem and how the system works or operates to perform that purpose. Likewise, the logical dimension is more traditionally defined as the networking topology that defines the architecture of the communications between the subsystems. System of systems integrators interested in focusing on the interstitial space will spend most of their efforts on the functional and logical dimensions of the design. The two examples in Table 1 illustrate this. The first row is a non-military, non-system example of this model applied to the development of a piece of literature. The second example is Navy-specific.                  

           
 PHYSICAL   FUNCTIONAL   LOGICAL 
 Book, Chapter, Paragraph    Information, Entertainment, Expansion and
 Promotion of Thought, Reference, etc.
 Theme, Story, Characters, etc.
 Ship, Combat System, Missile    Mobility, Command & Control, Weapons
 Control, etc.  
 Communication Links, Protocols,
 Signal Timing, etc.

            Table 1. Dimensions of System Integration and the Interstitial Space 

Warfighting Model

Another key model we rely on to describe the functional relationships of warfare is the warfighting model sequence of Plan, Detect, Control, Engage, and Assess. This terminology varies within and across the service cultures (Army, Navy, Air Force, Marine Corps), but each variation attempts to accomplish the same functional result in a similar sequence of activities.

A kill chain, or more generically, a mission thread, is a specific example of the warfighting model utilizing specific systems to perform the desired functions within the context of an operational scenario. A kill chain can be very local e.g., a Marine with a machine gun engaging an enemy combatant or very global with a multi-service system of systems ballistic missile defense capability defending a nation. Since each of these general functions may be performed by many systems and subsystems, with personnel trained and optimized to perform against threats, the precision of the interplay across the kill chain (through the interstitial space) is critical to a successful warfighting outcome. The role of the integrator is to understand, characterize, and discretely specify the necessary relationships between the systems and people to achieve the desired global behavior for the overall kill chain. Insight into how well the integrator is achieving the goals of system behavior management/control is “hiding” in the interstitial space between the systems.

Next, we will take a look at a tool to help the integrator see into the darkness of the interstitial space and bring to light, through measurement, how well the integration is maturing during system design, development, testing, and delivery.

Integration Readiness Level (IRL)

The establishment and use of “readiness levels” as a tool for the systems engineer to characterize the evolutionary maturity of a specific dimension of system design has been around for decades. Large-scale projects have found utility with the use of readiness levels as a way to simply convey to stakeholders where a specific design dimension of interest is in its evolutionary development. NASA is credited in the 1970’s with the creation of the Technology Readiness Level (TRL) as the first of a series of readiness level indicators. The Department of Defense (DoD) has since codified the use and utility of the TRL in acquisition policy and instruction across the services. Technology readiness, as its name implies, tends to focus on the physical instantiation of the system under development. As such, TRL focuses on “the box.” This works well for the physical dimension of integration but does little to provide insight into the functional and logical dimensions of the overall system, especially in a system of systems context. Since the integrator is equally as interested in what goes on between the boxes (the interstitial space) to achieve the local and global behaviors of the system, a new readiness level, the Integration Readiness Level (IRL), has been postulated to specifically focus on the interstitial space and work in concert with the TRL.

IRL Definition

The IRL follows the same readiness model structure as the TRL, which makes it easier for the technical and acquisition communities to use and understand. An IRL 1-9 level (1-lowest, 9-highest) numerical designation is assigned to a system at a specific point in time during its development to characterize the state of the integration that is resident in the interstitials of the system (see Figure 2). IRL levels 1-3 are the realization of an interface between two systems, much like the TRL levels 1-3 are the initial discovery and analysis levels for a technology. IRL levels 4-6 are higher levels of integration and control between two systems, much like the TRL levels 4-6 are the physical realization of the technology in a laboratory environment. Finally, IRL and TRL levels 7-9 are the demonstration and validation stages in ever more representative operational environments.

IRL Use and Utility

The vast majority of modern system developments rarely get past IRL level 3. For stand-alone or self-contained systems, this may be adequate. But in an increasingly interconnected world, where “The Internet of Everything” is a term bantered about and individual weapons may have their own Internet Protocol (IP) addresses, systems with a TRL 7 and an IRL 3 will no longer integrate well with other systems. This disconnect between the physical, functional, and logical maturity of system development has led to dissatisfied stakeholders and end users. It is seen as a failure of system integration that has manifested itself as interoperability problems in the fleet.

The upsurge of the Interoperability and Integration (I&I) pandemic we are experiencing in the fleet today has largely come about due to increased warfighting demands, and from envisioning how very expensive and individually competent weapon systems could and should operate more easily together and in new ways. The aim is to provide a force multiplier (the synergy that comes with successful system of systems realization) with little additional effort/cost by drawing out latent capabilities from our current force structure by integrating existing systems in new ways. The frustration lies in not being able to easily realize the holistic kill chain across the system of systems due to I&I problems. Today’s I&I problems are recognizable through the lens of the low IRLs of the individual weapon system components we are attempting to integrate. Having an IRL designator for the interstitial space and actively analyzing and managing the IRL during system development is a first critical step to improving functional and logical integration and designing the mission rather than just delivering the boxes.

Complexity

As we presently experience the ubiquitous nature of information technology all around us, caution is warranted regarding the understanding of and the dealing with system complexity. Large complex system of systems development does not lend itself to oversimplified serial problem solving employed by more traditional engineering and program management techniques. The interrelationships among components and subsystems are never completely known for all conditions, although they can and must be characterized for a very specific desired response, based on discrete input and controlled conditions. The richness of response that comes from interdependency and integration leads to complexity and uncertainty.

A system development program that is preoccupied with immediate goals tends to see bundles of many independent mini-systems instead of one overarching system. With a desire for simplification of understanding, the program decomposes design problems (symptoms) and the potential solutions into a discrete cause-and-effect modulus. Information overload is also a contributor. With a desire to “solve” the problem expeditiously, a minimum set of data is gathered and analyzed that can logically support a proposed plan of action. If the problems are oversimplified in a complex interdependent system and a serial symptom-solution/symptom-solution model is in place, unforeseen causal relationships can eventually undo the solution. This scheme becomes readily apparent in a simple analogy presented in Dietrich Dorner’s, The Logic of Failure (1996),2 where oversimplification of complex phenomena can lead to unintended consequences (see Figure 3).

Oversimplification tends to result in selecting and focusing on one variable as central (the problem), while ignoring the complex interrelationships among the multitude of interdependent variables in the system. In the above example, the contributing factors - pool depth, oxygen content and stratification, water circulation, bacteria type and metabolism - all contributed to the undesired symptom, a stinky garden pool. A simple, permanent, and much less laborious (costly) solution was available in installing a small recirculation pump to prevent the anaerobic foul smelling bacteria from forming on the bottom of the pool. Unfortunately, this option was never considered due to a serial symptom-solution mindset. It is obvious why simplification is a desired strategy for a quick solution, which appears to be much more efficient, avoids apparent unnecessary data gathering and analytical efforts, and streamlines planning. Schedule pressures and an overzealous desire to please, temporarily, are also contributing factors. The lead systems integrator of a complex system must avoid the strong tendency toward oversimplification when schedule pressures are great and technical problems are not well understood; he must seek out the often hidden root cause (stagnant water) and bring to light simple and much more effective (and permanent) solutions.

Conclusions

Mastering the discipline of integration requires taking a much harder look at the interstitial space, that gap between spaces full of structure and matter. The highly networked system of systems construct for modern naval warfare demands that the system integrator bring new light and technical discipline into the interstitial space to combat I&I deficiencies and better manage the global system behavior. One mechanism to gain vision into the darkness of the interstitial space is the use of an IRL designator to continually monitor the maturation of the system design as it relates to the key integration dimensions of functional and logical response within a kill chain or mission context. This is yet another step toward harnessing the complexity of large-scale systems design and shedding light on the potential design deficiencies that lurk in the darkness of the interstitial space.


Article Images
 
        
Figure 1. Focusing on the Interstitial Space
        
Figure 1. Focusing on the Interstitial Space
        


        
Figure 2. Technology and Integration Readiness Levels
        



Figure 3. Stinky Garden Pool Analogy
               

Article References

  1. Prencipe, Davies, and Hobday; 2003, University of Sussex, “The Business of systems Integration” (pg 52).

  2. Dorner, Dietrich; 1996, “The Logic of Failure” (pg 71).