Battle Command Collapse

and M&S
April 8 2011

Ted Troccola
PD Common Software, PM BC
Contractor (Viecore FSD Inc.)

1
 Topics for Discussion

•  Background
•  BC Collapse Strategy
–  Operational
–  Technical
–  Programmatic

•  Simulation in Battle Command

2
Background

3
 PM Battle Command
Value To The Army
•  Battle Command Products are Successfully Supporting Army,
Joint, and Coalition Operations Worldwide
•  PM BC Products Support Small Unit Tactical Operations through
COCOM Strategic C2
•  PM BC Delivers Three Key Capabilities that are Critical to Force
Employment Success
–  Applications
–  Information Services Infrastructure (primarily BCCS & GCCS)
–  Worldwide support structure
•  PM BC Is the Army’s Primary Organization Engaging NATO to
support Unified Coalition C2 in OEF
•  PM BC Achieves Success by implementing a Disciplined S/W
Delivery Process that Rapidly Delivers Capability to Warfighters

Reinforcing Battle Command Reinforces Success

4
 Current Army Battle Command Capability
TBC  (Tac9cal  Ba;le  Command  )    
CPOF,  BCCS,  Joint  Convergence  
GCCS-­‐A/NECC  
EAC  C2  

Maneuver  
  Shared  SA  
Ba;le  Command  
  Net-­‐Ready   Common  Services  
 
 
Interoperability  
Automa7c  Database  Replica7on  
MANUEVER  
  Display  and  disseminate  COP  
  Disseminate  Orders  
NBC   Tac7cal  Collabora7on  
Blue  Force/SA  

FBCB2/JBC-­‐P    
  Interoperability  between    
  Tac7cal  and  Theater  levels  
  PLI/SA  
  MEDEVAC   ENGINEER     Chem-­‐Bio  Rad-­‐Nuc  (CBRN)  
  Orders  

FIRE  SUPPORT   AFATDS   JADOCS  

Fire  Support  
AIR  DEFENSE  
AMDWS  
Air  Defense  

  Air  Defense  to  Maneuver  Units  

  Posi7ve  AircraF  ID  
AIR  PICTURE    
 
Synchronized  Fires,  Effects,  &  Maneuver  
Execute  Responsive  Fires  
  Weapon  Coverage     Target    Management  
LOGISTICS    
 
Forward  Observer  Handhelds  
Radar/Observer  Loca7ons  

Logis7cs  
TAIS   BCS3  
Airspace  

  Joint  Automated  Air  Space  

Control  with  the  JFACC      Combat  Power  
  Air  Support  Request      In-­‐transit  Visibility    

10+ Systems = 10+ Individual sets of Hardware, 5

Software, Development, Test, Logistics… 5
 Pre-Collapse Inefficiencies…
Some Examples
CX-I Data Tagging Client Side

IED Symbology Change System Time Cost

•  Oct 08 – Received 3 Star Note requiring System 1 - $-

all BC systems incorporate 4 new IED System 2 65 days $80K

symbols System 3 60 days $50K
•  21 Systems across 4 PEOs needed to change System 4 90 days $350K
- 21 different implementation schedules
- 21 different contracts modified System 5 60 days $95K
- 21 different CONOPS/opinions System 6 60 days $100K
•  9 Months to get consensus on implementation System 7 14 days $10K
details
System 8 - -
•  Execution of changes ranged anywhere from
System 9 75 days $172K
1 week at no cost to 6 months at $250K
Total (PdM) 90 days $857K
•  Quarterly releases approved in Jul 09
SoS Test 10 days $0
Total PM BC 100 days $857K

CX-I Banner Baseline Change

System A System B System C System D System E System F System G System H

Time FSR 35 days FSR 5 days FSR - FSR 1.5 Months

Cost $0 $75K $0 $7K $0 - $0 $132K

6
BC Collapse Strategy

7
 BC “Collapse” Strategy
2009 2011 2013 2015+
BFA
GNEC Services
BFA
GNEC
Services
Enterprise
WIN-T WIN-T Services
Infrastructure

Network Network
Information

GCCS-A/JC2C
GCCS GCCS JC2C
BCS3
BCS3 BCS3 BC Infr BC Infr
BCCS BCCS
Collaboration Collaboration
CoMotion CoMotion DDS/MIP DDS/MIP
PASS DDS/MIP Enterprise Enterprise
Enterprise Enterprise Network Network

BC Workstation “v0.5” BC Workstation“v1.0” BC Workstation “v2.0”

Mvr Air Mvr Air Mvr Air
CPOF BC BC BC BC BC BC
Workstation Workstation Workstation Workstation

`
Workstation Workstation

Fires Log Fires Log

CPOF Fires Log
BC BC BC BC BC
BC
Workstation Workstation Workstation Workstation Workstation
Workstation
Collaborative Environment BC Environment
(Based on CPOF/CoMotion) (Standard, Open Framework)
MCS Others
BC
Workstation
Applications

GCCS-A BC Environment
GCCS-A

JADOCS
JADOCS Coalition Coalition
AMDWS
AMDWS
AFATDS
AFATDS
AFATDS
Others Others Others
Coalition
BCS3 AMDWS
BCS3

Others
TAIS

Web Web Web

Services Services Services
Environment Environment Environment

Version 5.1 8
 PM BC Strategic Intent

•  Shift from a Battle Command family of uniquely distinct

applications with unique data storing and sharing
mechanisms and collapse these systems towards a
consolidated Battle Command product line
•  Attributes of the consolidated approach
–  Significantly enhanced commander and staff ability to effectively
conduct collaborative mission planning and execution across a
range of operations and the spectrum of conflict
–  A singular battle command product line with a common
government owned and managed architecture sharable by all
–  A unified approach to data handling and infrastructure
procurement
–  Focus warfighting function development of subordinate PM’s on
warfighting functions rather than draining resources on common
tasks

9
PM BC Strategic Intent - Operational
Extend and Significantly Enhance Staff Collaboration while
Reducing the Complexity of Operations and Sustainment

•  Centrally stored Services &

Data to enable Flexible,
Rapid Deployment

•  Consolidated infrastructure;
reduced burden on end users
& FSRs

•  Extended and Enhanced

Common Collaborative
Environment

•  Widely available (limited)

Collaboration and Shared
Services

Driven by a Set of Operational User Stories 10

 PM BC Strategic Intent - Technical
Shift from a family of uniquely distinct applications with unique data
storing and sharing mechanisms and collapse these systems
towards a consolidated software product line

•  Physical Consolidation
•  Services Consolidation
- Tactical
- Enterprise
- Network

•  Enterprise Data Architecture

- Standard Data Sharing (DDS)
- Collaborative Data Environment
(CoMotion)

•  Thick Client Consolidation

•  Common Collaborative
Environment

•  Common ‘Thin Client’

Environment
•  Web Services (leveraging
the Services
Infrastructure above) 11
Executing Technical Intent – Status (1)
Decisions Made/Course Set -
•  BC Collapse Architecture
–  Architecture has been base-lined and is being refined through a series of
Design Reviews
•  Information Services Infrastructure -
–  Battle Command Common Services (BCCS) will continue to serve as BC’s
single, unifying physical tactical infrastructure server
–  Data Dissemination Service (DDS) is being tested and certified as part of
SWB11-12; will be the standard, default mechanism for data management
and dissemination
•  Common BC ‘Thick Client’ Workstation –
–  Set of User Stories were delivered in Oct 10
–  Initial architecture and framework is based on CPOF/CoMotion; Oct 11
delivery based on 3PDK v2.0
–  All Oct 11 and beyond Collapse (and non-Collapse workstations) will be
based off of the same Army Gold Master (AGM), Common Client Install
(CCI), Security Configuration

12
PM BC Strategic Intent - Programmatic
Shift from a family of uniquely distinct applications with unique data
storing and sharing mechanisms and collapse these systems
towards a consolidated software product line

•  One standard
BC Infrastructure

•  Ability to compete
enhancements to
the infrastructure
and standard clients
(‘Thick’ & ‘Thin’)

•  One standard
BC Thick Client/
Workstation

•  Ability to compete
for new apps/
services built on the
common infr/clients

•  One standard
BC Thin Client
Environment

13
 The iPhone Analogy…
Maneuver/ …from a business model perspective
Planning Logistics

Battle Command is standardizing

on a common server and client(s)
with a standard set of enterprise
capabilities (data, collaboration,
mapping, etc) and BC services…

Fires Air

…That will be developed, integrated,

tested, accredited, and approved
once per major release…and
ultimately purchased, fielded, and
supported centrally

“Starter Kit”
14
 BC Architecture Evolution
CS 09/10 –
•  Individual BFA systems sharing data through PASS/MIP
•  Collaboration capability implemented by CPOF
•  BCCS as the core provider of infrastructure services; initial GNEC demo

CS 11/12 and Upgrade –

•  First instance of Collapse BC client based on CPOF/CoMotion
•  Scope is Maneuver, Fires, Log, and Air
•  Ability to drop separate MCS, CPOF, and TAIS clients
•  Co-hosting of BFA applications to reduce footprint (“same user, multiple boxes”)
•  Implementation of a subset of BC capability as services accessible in a
web environment (“thin client”)
•  Evolution of the BC data management capability from PASS to DDS

CS 13/14 –
•  Evolution of Collapse BC client to a standards-based, open framework
•  GCCS-A, JADOCS, BCS3 and BCST Collapse clients
•  Hosting of services developed externally (FCS, other Services, DARPA, Coalition, etc.)

CS 15/16 –
•  Remainder of BC systems ported to Collapse infrastructure
•  Further evolution of Collapse client; extended to externally developed apps
• Further “collapsing” of BC infrastructure; complete shift of enterprise services to
WIN-T; potential further shift to hosting BC capability at GNEC
15
 Battle Command Users

BC has defined 2 types of users:

BC Workstation:
–  Thick client that uses the 3PDK to produce a
collapsed client with WFA specific application loaded onto a
common framework
BC Web:
–  A thin client implementation of core BC capabilities.

16
 BC Workstation
•  Oct 2010 releases contained an initial set of
functionality based on the capability of the
3PDK1.0
•  All BC Workstations will be loaded on a common
baseline using the Common Client Installer
along with the AGM 9.0 Vista.
•  WFA unique functionality will be hosted as
services on VM’s hosted on the BCCS.
•  WFA required functionality not yet available via
collapsed infrastructure will continue to be
delivered as a co-hosted capability.
17
BC Workstation Architecture

18
 BC Web

•  BC  ini7a7ve  to  collapse  on  a  unified  thin  web  client  

•  BC  Web  is  being  developed  by  Strategic  BaKle  
Command  (SBC)  under  PM  BaKle  command    
•  BC  Web  framework  is  based  on  Ozone  and  Synapse  
to  provide  a  single  common  baseline  
•  WFA  developers  are  stopping  all  development  on  
individual  thin  clients  and  focusing  on  delivering  
capabili7es  as  widgets  based  on  the  SBC  framework.  
•  Widgets  will  be  made  available  to  all  BC  Web  users  
via  a  “marketplace”  
19
BC Web Software Architecture

20
Simulation in Battle Command

21
 Current M&S in BC

•  The  Current  BC  architecture  does  not  include  any  

components  specifically  for  M&S  

22
 Ongoing M&S related work in BC

•  There  is  ongoing  work,  in  PD  Common  SoWware,  

related  to  Modeling  &  Simula7on  in  BC  
o  A  media7on  component  to  exchange  data  with  
OneSAF  is  being  created  (this  component  includes  
support  for  limited  BML  data  exchange)  
o  A  study  is  being  conducted  to  determine  where  
the  BC  Master  Data  Repository  and  PASS  Schemas  
could  be  modified  to  accommodate  M&S  data  

23
 Opportunities for M&S in BC

•  The  7ming  is  right  -­‐  BC  Collapse  is  happening  NOW  
•  The  BC  Web  architecture  minimizes  impact  on  BC  C2  
systems  
o  BC  Web  enables  introduc7on  of  widgets  which  
can  be  used  by  all  BC  users/systems  
o  Simula7on  func7onality  would  be  available  and  
op7onal  to  all  BC  users/systems  
•  The  Simula7on-­‐to-­‐C4I  Interoperability  (SIMCI)  Project  
Call  is  currently  accep7ng  synopses  for  “How  to  
Bridge  the  Gap  between  BC  and  M&S”  
24
Open Discussion

25