Distributed Networked Forces

Ray Christian, Naval Undersea Warfare Center

Download Presentation

There is a whole military world out there called "coalition". This study is trying understand a netting of coalition forces, and particularly what are the gaps. We are trying to take a look at anti-submarine warfare. We need to look at our strategic posturing, because we are not that much more advanced today than we were in WW II. This type of conference helps us identify more about what we need to research, as we take what we are currently working on to the next level.

Click on image for enlargement

In the beginning of our research (Fundamentals of Distributed, Networked Military Forces and the Engineering of Distributed Systems), we tried to suspend disbelief. As a result, all the engineering details are not worked out. The engineers that have looked at this think this work is great, yet there is a gap between the intellectual thinking and the engineering.

Basic Questions

There are some key questions about the support of distributed, networked forces.

• What are the defining characteristics of a distributed, networked system in the Information Age?

• What should a distributed, networked system be capable of?

• How should distributed, networked systems be developed to exploit their full potential?

The Dilemma

“Defense community innovators have proposed concepts for using cutting-edge technologies to solve long standing military challenges. These concepts assume great benefits from networking, however, the advantages of networking, as well as the implications of engineering distributed systems, have not been fully articulated.”

How is the concept of distributed, networked systems best translated to the technical and experimentation communities?

Distributed, Networked Systems (DNS) Fundamentals

What are distributed systems? Distributed Systems have shared fundamentals that include:

• Basic Building Blocks - Apply to any system.

• Functions - Pedigree from military combat modeling.

• Defining Characteristics - Most insightful ways to think about a DNS.

• Design Goals - What performance attributes comprise “Universal Goods” for DNS?
  

These fundamentals are similar to the ones you use when building a house. The blueprint has a design for the broad function and characteristics of the house. The design characteristics are the insights. There are also design goals that we think need to be designed into these systems. We also want to make sure that we look at the trends.

In search theory we look at the problem first. It is important to start here. Once the problem is defined, we look at the algorithm that needs to be used to solve the problem. If the problem does not include the system that you are using to create the task, then your solution may not be plausible. You have to understand the constraints for the systems when you look at the problem.

Basic Building Blocks

The basis building blocks include an element and a connection. An element is a physical component that performs a certain function (includes humans and IT equipment). The connection can be any interaction between elements or between elements and the external world (e.g., common links, weapon-target pairings or logical relations). These connections may be made via physical or nonphysical interactions.

Fundamentals

A function is what we want an element to do. Examples of this are:

• Sensing
• Transport
• Netting
• Information Fusion and Pattern Recognition (taking data and give it meaning)
• Interpretation, Cognition and Decision
• Influence

All of these may be executed collectively or individually. We are aware that things have to move in the battlespace. There are many dimensions to the system like physical, cognitive and action. We also have to consider the human as an element in the system. Where is the human in this process? Where are feedback loops?

Characteristics

These begin when you look at the Number of Elements and collective behavior that we want each to have. As you increase the relationships, you increase the complexity. We found that when you get to a level of 100 elements things start to happen and you start to get some tipping points.

There is also Connection Topology. A "real DNS" assumes a configuration based on resources available and tasks at hand.

Connection Strength and how to define rates, degree of response and adaptation. If your connection strength is too strong you have "synthetic epilepsy" leading to paralysis. If it is too weak, you have strong control signals. For the most, part you have a dynamic mix of strengths.

Diversity is critical. Systems that best adapt to competitors and environment have diverse elements and connections. Homogenous elements open you up to vulnerability. Specialization and standardization, which decreases diversity, means adaptation is devalued; systems become more vulnerable to catastrophic failure in dynamic competition.

Scale is the extent to which the same system looks different when observed at different levels of resolution. Scale is critical to the nature of the system. A DNS has different behaviors engineered into the system at different scales. A distributed, networked system will be inefficient (or even completely ineffective) if it cannot observe, understand or influence behaviors at the scales in which they occur.

Design Goals

Engineering the appropriate system is critical to success. How do you build adaptation into your system and still have stability? What are the direct and indirect connections? These are all part of the Design Goals.

Persistent Operational Advantage

Adaptively maintaining advantage against a clever foe, even when facing surprising initiatives, dramatic innovations or changing rules. (Includes admitting disadvantage to regain persistent advantage later.)

Competitive Collective Behavior

Acting as purposeful collectives without prescribed, centralized control or synchronization.

An example is an enemy's ability to discern friendly intent will be dramatically reduced if the macroscopic system actions are not mapped directly or obviously to the actions of the discrete elements.

Stable System Performance

Dynamic competitive environments are extraordinarily complex and unpredictable. A distributed, networked force must have a fundamental precept of stability in the midst of turmoil.

Controllable stability is akin to "physical agility" plus aspects of "balance." This also implies that limited losses should not impact macroscopic behavior.

Dynamic Adaptability

Branch-and-sequel planning is inappropriate for dynamic environments, but traditional long-term planning functions will still be required.

Also required are simultaneously allocation, assessment and planning at different time scales and in multiple dimensions. Ability of forces to self-synchronize is imperative.

Direct Connections

Advantages of Distributed, Networked Forces

Networking Only

• Example: Sensor-to-shooter
• Pro: Improves current processes
• Con: Decreasing returns

Distributing Only

• Example: Streetfighter and UAVs
• Pro: Increases options
• Con: Defeat in detail

Networking AND Distributing

• Example: CEC
• Pro: Factorial Effects
• Con: Requires Decentralized C2 (!)
  

Networking AND Distributing Military Forces

• Pro: Advantage can emerge from a broad pool of inputs and manifest in a multitude of ways, each obscure to an opponent until advantage is ready to be applied.
• Con: Requires dramatic cultural change

Potential DNS Design Principles

When you put together the system there are some design principles. (The explicit value of Design Principles is context dependent.)

You don't want to build something small and cheap that dies off fast. Instead, you could build something small and stable that will last for 300 days. There are many trade offs that you have to make when you look at your Design Principles. Make sure that you look at the the different paradigms that may emerge and make sure that you plan for them. We have to make sure that we look at the long term pay off.

Design Principles

• Recombination - ability to aggregate, distribute or interchange physical, information technologies

• Dispersion - Avoiding spatial, informational or logical massification

• Mobility - Sufficient speed for rapid relocation/reconfiguration

• Stealth - Physically smaller elements with reduced signatures

• Proximity - Ability to get close up and survive

• Flexibility - Fluid system substructures, broad interoperablity

• Persistence - Ability to operate without distribution by cyclic logistics

Development of Distributed, Network Systems

Intellectual Gap

There is an intellectual gap in that the physical parts of systems are over-represented in the Design Principles. This is largely because sensibilities for designing intangible behaviors in distributed, networked forces are immature.

We did not have an information-rich framework to build the system. We do not have many engineers that have built distributed networks on the scale that we are talking about. In the past, we normally have the engineering experts to throw at military problems. But the engineers are being developed in this new area as we develop DNS knowledge.

For example, aeronautical engineering was not created before we started to fly. We took what we knew about engineering and developed aeronautical engineering learning from our experience, from our successes and failures. We knew enough science to proceed, but we did not have an engineering force. A difficulty in the military is that we require ourselves to know exactly what we are building before we build it.

Fill the Gap

To fill the gap, the engineering discipline needs to evolve within the context of experimentation. The key is to experiment, experiment, and experiment some more.

Developing DNS

We need to create a process to begin experimentation, prototyping, advanced development and engineering development.

Click on image for enlargement

Conclusion

• Articulated a formal translation

• Explicitly described source of advantage

• Proposed Design Principles

• Suggested critical development needs

• Offered vision of paradigm shift

Questions

Does the non-targetness have to be a function?

What is the overlap between the system and warfighting functions?

What are the characteristics of the system and are they taken it into account?

What is desired to survive? What elements of the system are meant to just gather data and not survive?