C2 ARCHITECTURES: The Persistent Challenge · Adaptability= Cohesion-«coupling-P . a+P=1 . The...

SAL

8/2/2013 System Architectures Laboratory 1

C2 ARCHITECTURES:

The Persistent Challenge

Alexander H. Levis

18th ICCRTS

20 June 2013

Alexandria, VA

Report Documentation Page Form ApprovedOMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.

1. REPORT DATE 20 JUN 2013 2. REPORT TYPE

3. DATES COVERED 00-00-2013 to 00-00-2013

4. TITLE AND SUBTITLE C2 Architectures: The Persistent Challenge

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) George Mason University,System Architectures Laboratory,4400University Drive,Fairfax,VA,22030

8. PERFORMING ORGANIZATIONREPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited

13. SUPPLEMENTARY NOTES Presented at the 18th International Command & Control Research & Technology Symposium (ICCRTS)held 19-21 June, 2013 in Alexandria, VA. U.S. Government or Federal Rights License

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT Same as

Report (SAR)

18. NUMBEROF PAGES

35

19a. NAME OFRESPONSIBLE PERSON

a. REPORT unclassified

b. ABSTRACT unclassified

c. THIS PAGE unclassified

Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

SAL

System Architectures Laboratory 8/2/2013 2

Outline

• A Little History

• The Persistent Challenges and the Elusive Next Best Thing

• Systems of Systems

• Service Oriented Architectures and Clouds

• Resilience

• A C2 Challenge: Integrated Courses of Action

• A Current Example

• Closure

SAL

System Architectures Laboratory

A Little History:

The Symposium

• In 1978 the first MIT/ONR Workshop on C2 was held in Cambridge, MA

with the objective of creating a research community focused on C2

• In 1979, a workshop held at NDU articulated the need for a Science of

Command and Control

• In 1987 the MIT/ONR Workshop was transformed into the Symposium

on C2 Research sponsored by the Joint Directors of Laboratories and

held at NDU and the Naval Postgraduate School

• In 1995 the scope was expanded and it became the C2 Research and

Technology Symposium (CCRTS) sponsored by the Command and

Control Research Program under Dr David Alberts

• Also in 1995 the International series was launched (ICCRTS) with both

events integrated in June at the National Defense University

• From 1996 to 2006 the two series run in parallel for most of the time

• The CCRTS and the ICCRTS merged in 2007 and have continued in

this form to this day

8/2/2013 3

SAL


The Persistent Challenges

• Early on in these meetings, it was observed that C2 theory had to

address three major challenges:

– Coping with Uncertainty

• Adversaries, missions, coalition partners, goals and objectives

– Coping with Complexity

• Net-centricity and Net-Enabled capabilities, Information

sharing in a contested cyber environment, DIME and PIMEESI

– Coping with Change

• Transnational and non-state actors, technological change (e.g.,

PGMs, UAVs and UCAVs, cyber warfare), rapidly changing geo-

political structure

• These challenges are still here and they keep accelerating

8/2/2013 4

SAL


Many Solutions

• Every six or seven years*, a “next best thing” appears with the

promise to address the daunting C2 problems

– Examples:

• C4ISR and DOD Architectures

• Systems of Systems

• Service Oriented Architectures

• Cloud Computing

• And new concepts or “organizing principles” are articulated

– Examples:

• Net Centricity

• Net Enabled Capabilities

• Information Sharing

• Communities of Interest

• Collaboration

8/2/2013 5

* Totally unscientific observation

SAL


But Solutions Have Limitations

• However, as we start to go past the Powerpoint presentation and try to

realize these concepts and design processes and systems we

recognize that:

– While the concepts are valid and worthwhile

– Their applicability is usually limited

– They often do not scale

– They raise a host of new hard problems that need to be addressed

• A pervasive and persistent challenge is how to evaluate the designs

based on such solutions

– Functional Attributes (Performance evaluation: Accuracy,

Timeliness, Throughput Rate, etc.)

– Non Functional Attributes (Mission Assurance, Agility, Resilience,

Security, Vulnerability, …)

8/2/2013 6

SAL


System of Systems*

8/2/2013

A system will be called a System of Systems (SoS) when:

– The component systems achieve well-substantiated purposes in their own right even if detached from the overall system;

– The components systems are managed in large part for their own purposes rather than the purposes of the whole;

– It exhibits behavior, including emergent behavior, not achievable by the component systems acting independently;

– [It is geographically distributed]

– Component systems, functions, and behaviors may be added or removed during its use

* Definition evolved from Maier, Sage, …

7

SAL


SoS Issues

8/2/2013 8

• A System of Systems (SOS) poses novel engineering challenge.

− Increasing complexity of the SOS Architectures

− Need to reconfigure to meet unpredictable needs

• While we have extensive System theory expressed in many

mathematical formalisms, it is based on the assumption that one can

draw the system boundary and determine what is in, what is out, and

what the interactions across the boundary are (a Physics-based point of

view)

• The fifth attribute of an SoS violates that assumption

• Consequently, we do not have a mathematical theory for the Analysis

and Design of Systems of Systems; we have ad-hoc approaches to their

design and evaluation

SAL


SOSI: The Kluge

Assumptions:

− The set of elements that compose the System of Systems changes over time

− The elements are heterogeneous

− The elements are at different stages of their lifecycle

− The SOS defines a set of capabilities implemented by a selection of its elements

Define a SOS Instance (SOSI) that is instantiated from a SOS

− A SOSI is instantiated from available elements of the SOS based on the relationships described in the SOSI architecture

− Each SOSI is unique

− A SOSI provides a particular set of capabilities, a subset of the SOS capabilities

− The SOSI is actually a System; we can analyze it and evaluate it

8/2/2013 9

SAL


Adaptability

8/2/2013 10

• Cohesion - measure of the relatedness of inputs and outputs within a Node (a node contains one or more elements)

• Coupling -measure of the interdependence among Nodes

• Adaptability - the degree to which a 5051 or Node can change configuration

Adaptability= Cohesion-«coupling-P a+P=1 The inverse of the Cobb-Douglass production function is used

a and p are the elasticities of substitution

• High Adaptability: Low Cohesion within Nodes, Low Coupling among them

• Medium Adaptability: Low Cohesion within Nodes, High Coupling among them or High Cohesion within Nodes, Low Coupling among them

• Low Adaptability: High Cohesion within Nodes, High Coupling among them

SAL


Example: ESG

• A Naval Expeditionary Strike Group reconfiguring its C2 to address an

unexpected Humanitarian Assistance / Disaster relief mission

• Three Architecture Patterns:

– Peer to Peer (PtP)

– Centralized (CS)

– Service Oriented Architecture (SOA)

• Three configurations of the SOSI that contains 19 elements

– Alt 1: Six Nodes

– Alt 2: Eight Nodes

– Alt 3: Four nodes

• The architectures were designed, executable models derived and

analysis and simulations carried out

8/2/2013 11

SAL


Adaptability

P2P CS1 CS2 CS3 SOA1 SOA2 SOA3

Alt 1 0.68 0.17 0.15 0.12 0.52 0.64 0.84

Alt 2 1.07 0.29 0.22 0.34 0.85 1.30 1.20

Alt 3 0.33 0.11 0.08 0.09 0.41 0.55 0.33

0.00

0.20

0.40

0.60

0.80

1.00

1.20

1.40

8/2/2013 12

SAL


Service Oriented

Architectures

• SOA is an architecture for building applications as a set of loosely

coupled black-box components orchestrated to deliver a well-defined

level of service by linking together processes.

• These loosely coupled components can be combined and recombined in

different ways

• SOA should support Net-Centric Concepts or Net-Enabled Capabilities by:

– Populating the Net Enabled Environment with new capabilities

– Utilizing existing Net Enabled capabilities

– Accommodating un-anticipated users

– Promoting the use of Communities of Interest (COIs)

– Supporting shared infrastructure

• An essential enabler of a SOA is meta-data (it is the currency of SOA)

• However, different meta-data sets lead to different SOAs that then need to

be federated

• Key issue: Quality of Service (an evaluation issue)

8/2/2013 13

SAL


SOA Federation Environment

8/2/2013 14

Ph

ys

ica

l La

ye

r O

pe

ratio

na

l La

ye

r

Service

Service

Service

Service Service

Business Process n

Business Process 2

Business Process 1

Se

rvic

e L

aye

r

Service Container

Service

Service Container

Service

Service Container

Service

Service Container

Service

ESB

Supervisor MOM Orchestrator Registry

ESB


SOA Federation

SAL

Op

eratio

nal Laye

r Service

Service

Service Service Service

Business Process n

Business Process 2

Business Process 1

Service

Layer

Service Container

Service

Service Container

Service

Service Container

Service

Service Container

Service

ESB


ESB


Ph

ysical Layer

Analysis & Evaluation of the Hybrid

Executable Model, 2

Physical Layer(1)

Utilization, Throughput

ESB Services Layer(2.1)

Utilization, Throughput, Response Time

Business Services Layer(2.2)

Utilization, Throughput, Response Time

Operational Layer(3)

Business Productivity, Response Time,

Creation Time

Dep

en

den

cy

15 8/2/2013

SAL


The Challenge

• Meta-data is not universal; rather Communities of Interest define their

own meta-data

• Some meta-date is common by agreement, but much is not (semantic

differences)

• Consequently, we cannot integrate SOAs; we need to federate them so

that we can exploit service availability across SOAs (a sort of cross-

domain issue)

• That brings in a whole new level of necessary infrastructure that

increases complexity and degrades the Quality of Service

• A key component of SOA is the orchestrator (or workflow manager)

that needs to deal with semantic issues for the valid interconnection

(inter-operation) of services when crossing COIs.

– Think of creating workflows in which Apple apps and Android apps

inter-operate in complex ways

– Think cloud computing across clouds!

8/2/2013 16

SAL


Resilience and Time

An evaluation of resilience must consider time

Survival Phase Recovery Phase Avoidance Phase

Mo

P fo

r C

ap

ab

ility

t0 td tmin tret tf

ValueT

Value2

Value1

Normal Operating

Level

A Disruption

Occurs at time

td

Capability

decreases.

Capability

decreases to

some minimum

value V1 at time

tmin

A minimum (Threshold)

capability level of acceptable

performance;

Performance returns

to pre-disruption

levels at time tret

In this case, the capability never

dropped below the minimum

threshold value.

8/2/2013 17

Resilience is the ability to “avoid, survive and recover from disruption”

SAL


Resilience Measures

8/2/2013 18

Concept MOP

Buffering Capacity

Reactive Capacity

Residual Capacity

Rate of Departure

Fault Tolerance

Point of Failure

Tolerance

Cohesion

Common Use

Proportion of Use

Capacity

"The ability to operate at a

certain level of capability as

defined by a given measure"

Tolerance "the ability to degrade

gracefully after a disruption"

Flexibility "the ability of a system to

reorganize its elements to

maintain its capabilities"

SAL

System Architectures Laboratory 19 Naval Surface Fire Support

Forward Observer

FSO C2 Vehicle

Firing Battery

Threat TargetAdjacent and

Maneuver Units

III

Higher HQPos/Status Rpt to HQ

Pos/Status Rpt to HQ



Navigation Aid Data



COP

ESG

Close Air Support

Call For Fire

Targeting Architecture Case Study:

Operational View

SAL


Targeting Architecture:

Scenario and Disruption

• Examine the resilience of the capability to ‘Coordinate and Synchronize

Fire Support’ to disruption of the ‘geo-positioning navigation aid

signals (GPS)’ in early entry operations (of what, to what, under what

conditions)

• Cyber attack to the GPS satellite constellation scrambled the GPS

signal, rendering it useless

• Loss of GPS affects the fire support process from end to end (FO self-

location, target location, clearance of fires, and allocation of weapons)

• Each portion of the fire support team can still complete the process, but

the process transitions to pre-GPS era methods which require much

longer times to complete. Soldier common task standards for times to

manually complete tasks, vs. GPS enabled times are used

• No backup is available to offset this loss except for the older manual

approaches (i.e., no reactive capacity exists to this disruption)

8/2/2013 20

SAL


Capacity

0

100

200

300

400

500

600

700

800C

apac

ity:

Re

amin

ing

Win

do

w o

f O

pp

ort

un

ity

(se

c) t

o E

nga

ge t

he

Tar

get

Scenario Time (hours)

Remaining Window of Opportunity

Pre-Disruption Average Capacity

Post-Disruption Average Capacity

(T) Threshold Capacity Requirement

BufferingCapacity

Disruption Occurs(td = 5 hours)

Red circles = targets which departed (missed opportunities)

8/2/2013 21

SAL


GPS Alternative: An Aerostat

• Fire Support Community understands

its vulnerability to loss of GPS – what

can be done?

• Aerostats can be used as a limited

alternative to GPS.

• Approach:

– Modify the architecture to reflect Aerostat reactive capacity.

– Reflect the architectural modifications into the executable model

– Repeat the analysis of appropriate resilience measures

– Apply the revised results into the resilience evaluation framework

8/2/2013 22

SAL


Aerostat Reactive Capacity

• The aerostat

returns

performance

to meet

requirements

• However,

there is a

window of

severe

vulnerability

• Issue: Static

performance

analysis vs.

dynamic

performance

analysis

0

100

200

300

400

500

600

700

800

Cap

acit

y: R

eam

inin

g W

ind

ow

of

Op

po

rtu

nit

y (s

ec)

to

En

gage

th

e T

arge

t

Scenario Time (hours)

Remaining Window Of OpportunityPre-Disruption Average Capacity(T) Threshold Capacity RequirementAerostat Average CapacityPost- Disruption Average Capacity

BufferingCapacity

Surrogate ReactiveCapacity

Disruptiontd = 5 hours

Circles = targets which departed (missed opportunities)

Reactive Capacity AvailableTime trc = 7 hours

8/2/2013 23

SAL


Integrated Courses of Action

(Cross-Domain)

Current C2 enterprise processes cannot produce integrated Courses

of Action (COAs) within the desired timeframes for planning

− Time-constrained Crisis Action Planning results in COAs which are

not fully integrated adding more risk to military operations

− Lack of a method to discover and agree upon cross-domain effects

makes mutual adjustment between domains very difficult

− Commanders are often required to perform (mental) COA

integration themselves during decision making

24

Integrated COA – A COA in which all participating entities act as one

organization in pursuit of common goal(s); A COA in which no higher

estimation of performance can be obtained by changing the actions

taken and action timing in each involved domain

SAL


Current De-Confliction

Approach

8/2/2013 25

Organization 1

COA COA VELOPMEN ANALYSIS

Age of the information

Time

COA COA

Transfer Time

VELOPMEN ANALYSIS

Decode Time

Avoid major negative synergies;

""C ~

0 0 u c 10.0 Ill Cl.l c

"' E ~

0 -c

Organization 2

Enable synergies as possible wit hout major rework of COA; Exercise in satisficing not optimization

"' c: 0 ·-...

<C u ·-0 -~ u c:

0 u I

QJ c

Joint Agreement *

SAL


Co-Design or

Collaborative Approach

8/2/2013 26

Organi2ation 2

Higher Headquarters

Design Coordinations: 0. Coordinat ion Approach 1. Objective(s) and metric(s) 2. Key lnfluencers of objective(s) 3. Adversary and environment potential actions 4. Organizations' (Domains') potential act ions

an r:: 0

"Q ~ c::

"g .... 0

8

5. System structure (interactions, constraints, synergies) 6. Integrated COA 7. Integrated COA Timing

Joint Agreement *I

SAL


Illustrative Results

• Maintain prescribed tempo

8/2/2013 27

SAL


Persistent Challenges

8/2/2013 28

... ~~ORGE IYJASON U N I V E !R ~S~~~-T~Y~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

\.aeaders in Strategic Deterrenc Preeminent Global Warfighters in Space and Cyberspace

8 Providing Global Security for America

---,' .....

/ Departments/Agencies' ·._

' ' ', ___ IC

·-------

CCDRs/ ' JFCs

I SynchroniZed I global MD

Planning, integrating, and coordinating ISR in support of strategic

and global ops I Architecture Phase I

Centralized Integration and synchronization through traditional

J-codes

SAL


Four Use Cases

8/2/2013 29

Shape, Prevent, Prepare

USE CASE 1: Day to Day Operations

• End Condition: Maintained Strategic situational awareness and cognition of force readiness • Trigger Event(s):

. 1) External taskings (UCP, JSCP, etc.) 2) GCC/External requests 3) CCIRIPIR event

Crisis response, Stabilize, De-escalate

USE CASE 2: Prevent Adverse

Activity

• End Condition: Adversary action is prevented/ deterred and Command returns to Day to Day Operations • Trigger Event(s): Indications & warning indicate imminent adverse activity or "act of nature"; however no overt activity has occurred

USE CASE 3: Non-Nuclear Attack

• End Condition: Minimize effect of attack & prevent further attacks • Trigger Event(s): Kinetic attack, non-kinetic attack (asymmetric attack), or perceived attack against national interests/allies

Seize Initiative; Achieve Freedom of Action in Global Commons; Defeat Adversary

USE CASE 4: Nuclear Attack

• End Condition: End Attack on conditions favorable to US and Allies • Trigger Event(s): Valid indications of major strategic attack on US interests or Allies; Missile or Missiles inbound; Radiological detonation

SAL


Architecture Evolution

8/2/2013 30

Time

Degre

e o

f N

et

Enable

d

Capabili

ty

Baseline:

PtP

2015 2020 2025

Shared

Data/ PtP

Shared

Data/MSL

Shared

Data/MLS

None

Low

Medium

High

Reference:

PtP: Point to Point

SD: Shared Data

MLS: Multi-Level Security

MSL: Multiple Security Levels

SAL


Comparison of the Four

Architectures

8/2/2013 31

Baseline: Point to Point

Multi-Level Security Shared Data at Multiple Security Levels

Shared Data / PtP for security

1

3

SAL

System Architectures Laboratory 8/2/2013 32

Example Architecture ... ~~ORGE IYJASON UN

~· Arch~ecture: SO v.f "Shared Daw 4fl i;2Cll

SAL


The Challenges

• Enable Information Sharing at different levels of classification

• Enable collaboration while maintaining security levels

• Not all collaboration schemes are created equal. How do we design

the appropriate collaboration architecture for each Community of

Interest?

• Some experimental and Modeling and Simulation data exist rom the

ELICIT program (see The Agility Advantage by David Alberts) but

more, problem focused experimentation is needed

• USSTRATCOM is launching a Campaign of Experimentation to

address these issues

– Processes will need to adapt

– Systems will need to be modified

– Behaviors will need to change

8/2/2013 33

SAL


Some Questions

• Have the original goals that launched these conferences been met?

Yes, a Research and development community has evolved; Command

and Control is now in the public consciousness

• Is Command and Control a viable, challenging research field?

Yes, and the challenges are getting harder. We need new theories (and

empirical data) to address the impact of information technology on

processes and on human (operator and commander) behavior

• Do we understand the difference between C2 and C4I?

Yes, most of the time, but there is still the tendency to jump to system

solutions without fully assessing the need to change the processes

8/2/2013 34

SAL


Closure

• In 1987, at the first Symposium on C2 Research, I gave a plenary

speech on the Quest for a C2 theory that started with the opening lines

from Ithaca by the Greek poet, K. Kavafy:

“When you start on your journey to Ithaca, then pray that the

road is long, full of adventure, full of knowledge,”

• The talk ended with these lines from the same poem:

“Ithaca has given you the beautiful voyage, without her you

would not have taken the road. … and with so much experience

you have gained, you must surely have understood what Ithacas

mean.”

• Twenty six years later, looking back at what the C2 community has

contributed to the warfighter and the promise it holds for addressing

the continuously evolving (and persistent) challenges, it is clear that

it is the journey and not the destination that we should cherish

• And the journey promises to be “long, full of adventure, full of

knowledge”

8/2/2013 35

C2 ARCHITECTURES: The Persistent Challenge · Adaptability= Cohesion-«coupling-P . a+P=1 . The...

Documents

Transcript of C2 ARCHITECTURES: The Persistent Challenge · Adaptability= Cohesion-«coupling-P . a+P=1 . The...