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.