1. ASNE Combat System Symposium PEO IWS Approach to Open Systems Architecture
Mr. Bill Bray, Executive Director
Program Executive Office, Integrated Warfare Systems
9 December 2014
DISTRIBUTION STATEMENT A: Approved for public release; Unlimited distribution.

2. Evolving Joint Environments
Operational Environment
Complex Threats
Employing Advanced Technology
in Challenging Environments
Humanitarian
Assistance
Short and Medium Range Ballistic Missiles
Persistent
ISR
Simultaneous Raids Across
Multiple Mission Areas
Sub-Sonic
Anti-Air &
Anti-Surface Missiles
Intermediate Range
Ballistic Missiles
Small Boat
Attacks
Cyber
Warfare
Anti-Piracy
Super-Sonic
Anti-Air & Anti-Surface Missiles
Fire Support Missions
Disaster Relief
Torpedoes
Anti-Ship
Ballistic Missiles
Advanced Super-Sonic
Anti-Air & Anti-Ship Missiles
Stealth
Under-Sea
Engage Long Range Ballistic Missiles
Mines
DRAFT WORKING NOTES
Advanced ASW
Rail Guns
Cyber
Defense
Over Land
Defense
Multi-Ship
Resource Coordination
Enhanced Shipboard Sensors
(Radar + ES/EA)
Capability Advancements
Directed
Energy
Area Air Defense
In Clutter Environments
Improved Self-Defense
UAV Integration
Integrated Air and Missile Defense
Integrated AAW & Situational Awareness
High Data Rate
Battle Group Networks

3. Implementing Open Systems Architecture: Strategy, Interfaces and Open Standards
Treat computing environment as a commodity
Select commercial mainstream COTS products that conform to well-established open system interface standards
Bundle specific COTS products for a given timeframe and revisit selections on a regular basis
Isolate applications from high rate-of-change COTS through selection of standard APIs
Upgrade H/W and S/W Independently and on different refresh intervals
Transform application development from single-platform development to multi-platform portfolio
Objective architecture defines key interfaces that support extensibility and reuse goals based on common data model
Eliminate redundant software development efforts
Applications
Middleware
Commercial Products
Operating System
Hardware
“Build
Once”
Display
Track Mgmt
Command
&
Control
Sensor
Mgmt
Weapon Mgmt
Vehicle Control
Middleware
Operating System
Hardware

4. Evolution of Open Systems Architecture

5. Combat System Objective Architecture
ExComm
Vehicles
Platform Adaptation
Combat System LAN
Weapons
Sensors
Common Core Domains
External Comms
Display
Services
Vehicle Control
Sensor Mgmt
Combat Control
Weapon Mgmt
Track Mgmt
Integrated
Training
Nav Systems
Navigation
Infrastructure
Training Systems

6. Common Computing & Infrastructure Vision Common Across Baseline Configurations
CCI Ships
Build Process
Common Computing, Storage and Operating Environment
Common Computing & Infrastructure
SSDS
“Common Components Across Multiple Combat Systems”
Key Elements of Common Development:
Common Requirements
Single Specifications
Program Plans Aligned
Single Set of Processes & Metrics
Integrated Team Structure
Enterprise Products
AEGIS, SSDS, Coast Guard, LCS Cross Program Representation

7. AEGIS TI 16 Enabled Consolidation
6 CPS Cabinets to be replace by 2 CCS; 2 ASAN Cabinets
4 TI 12 ACEG and IOPs Cabinets to be replace by 2 TI 16 ACEG/IO Cabinets
Hosting of Combat System Computer programs within the AWS boundaries
Common logistics
Common training
4 TI 16 CCS = 6 CPS (2CCS; 2 ASAN to replace 6 CPS)
2 TI 16 ACEG/IO = 4 TI 12 ACEG and IOPs
ALIS, DiVDS and DDS is one-to-one
0 TI 16 DPC - 4 TI 12 DPC
4 TI 12 DPC - 0 TI 16 DPC
No longer needed
CEM role caption reduced cables
AEGIS Example
Today’s Technology Enables a 2:1 Reduction in Footprint With Remaining Margin for Processing and Storage

8. TI 16 Common Building Blocks for Navy Combat Systems
Fewer Unique Parts
Reduced Qualification Effort
Common Use Across Multiple Programs
3064 Edge Switch
3U Server
Storage
3132 Core Switch
Remote Access Server
1U Server
DC Power Distro
Power Control Device
Firewall
VMEbus Chassis
Enclosure Monitor
DVI Tray
Encoder Tray
Tactical Server
Chassis
Improved Capabilities
40% Processing Capacity Increase
3X Computing Density
300% Increase Bandwidth
35% Increase in Storage (115 TB)
Dual Network Redundancy
Redundant Display Connection
Sailor Benefits
60% Reduction in Maintenance Effort
20% Increase in Redundancy
Reduced Mean Time To Repair
Decreased Maintenance Training
Imbedded Videos & Repair Procedures
Closed Door troubleshooting
Common Building Blocks is the Key Concept of TI-16 for Reduced Fleet Maintenance, Training and Life Cycle Costs

9. AEGIS TI 16 State Of The Practice Improvements
115.2%
Processing
Margin 19 16
Cabinet
Count
76.8% 11
44.8%
With Fewer Cabinets, TI 16 Architecture Continues the Upward Progress on Processing Margin
TI 16 Reverses Trends and Requires Less Power, Less Cooling, & Reduces Weight of the Computing Infrastructure

10. SSDS Single Source Library Software Superset Supports All Platforms
2004
Open Standards-Based Designs
Componentized Architecture
Well-Defined Interfaces
Open Systems Architecture (OSA) Foundation
CVN 68
2014
LPD
2004
“Fix it Once”
LHD
2003
2005
Single
Source
Library
Build
Process
Single
Install
Media
LHA
Core
2012
Key Elements of Common Development:
Common Mission Capabilities
“Superset” of Specifications
Common Program Plans
Single Set of Processes & Metrics
Integrated Team Structure
Enterprise Products
FSEC Interop
OSA, ESSM/AEC
RAM BLK
LSD, CIWS 2012
More than 10 years ago, a single source library concept was conceived for the SSDS MK 2 operational computer programs. The library includes application software, operating system software, middleware, ship adaptation files and databases.
New capabilities and software fixes are added to the Single Source Library and can be extended to all SSDS MK 2 ships via the build process that creates a Single Install Media. Configuration files are created for each ship that configures and loads the software. Adaptation files are created for the specific sensor and weapon parameters for each ship.
The initial SSDS MK 2 core development supported both the CVN 68 and LPD 17 ship classes. The single source library has been expanded to include seven ship classes with the addition of LHD-1, LHA-6, LSD 41/49, and CVN-78 ship classes.
AMIIP, FCLIP
2014
DBR, Mode 5 (engagement only), ESSM with uplink,
Product Line Software Components, SEWIP
LSD
Enables Technology/Capability
Insertion Across Diverse Platforms
2015
CVN 78
Extensible Architecture Translates Into Reduced Development, Maintenance and Training Costs

11. AEGIS Common Source Library (CSL) REUSE within Baseline configurations
“Fix Once…
Use Many Times”
Key Elements of Common Development:
Common Mission Capabilities
Single Set of Specifications
Common Program Plans
Single Set of Processes & Metrics
Integrated Team Structure
Enterprise Products
Common Source Library
Build Process
CSL Ships
Baseline 8
~3500K SLOC
BMD 4.0.1
~500K SLOC
97% Re-use
Baseline 9
CG Modernization
~6000K SLOC
97% Re-use
97% Re-use
Baseline 9
DDG Modernization
~8000K SLOC
BMD 5.0
~2000K SLOC
99% Re-use
Baseline 9
DDG New Construction
~8015K SLOC
SPY-1D(V)
Integration
~15K SLOC
International
BMD 5.0
~2000K SLOC
99% Re-use
AEGIS
Ashore
Adaptation
~66K SLOC
Baseline 9
AEGIS Ashore
~8080K SLOC
BMD 5.0
~2000K SLOC
AEGIS / MDA AB Cross Program Governance
In Place to Coordinate Multiple Programs Using CSL

12. Commonality Across Combat Systems
Commonality will address reduced training time, reduced O&S Cost and shorter availabilities
Surface and USW Combat Systems
Common Components
COTS and OSA based computing
Increase network-based Computing Equipment Capabilities
Common Source Library, Single Source Library and USW AxB
Common training and sailor qualification
JTM- Joint Track Manager
CDS- Common Display System
CPS- Common Processing System
BFTT- Battle Force Team Trainer
CANES Gateway
CIWS – SeaRAM – LPWS
MH 60R Integration
Standardize hardware and software components across surface Navy combat system elements
Common & Single Source-code Libraries
Near-term Efforts
Navigation Wholeness: ECDIS-N, VMS
ASTAC: Common operator mode for MH-60R
Combat System LAN: External Comms, Display Services, Vehicle Control, Weapon Management
ESSM BLK II
SEWIP BLK II/III
Enterprise Air Surveillance Radar (EASR)
Key Elements of Common Development:
Common Mission Capabilities
Single Set of Specifications
Common Program Plans
Single Set of Processes & Metrics
Integrated Team Structure
Enterprise Products
This is an update the to the “single” slide used during the March 2014 SBP
Key change is show the SSDS Single Source Library (SSL) vice just the AEGIS Common Source Library (CSL)
ASTAC: MH 60R is becoming the common Surface Ship Helo and is being integrated into SSDS, and AEGIS. Developing an ASTAC Operator Mode that is common across AEGIS and SSDS (DDGs, CVNs, and LCS). This will create a single look-and-feel on all ship classes and require only one training curriculum for all operators.
JTM: System Track Server and Track Manager are common components that run in AEGIS BL 9 and SSDS ACB 12. The System Track Server and Track Manager holds the track database. The common System Track Server and Track Manager allows us to provide more common components like developing the common ASTAC module.
Common Display System (CDS): CDS is the display console currently being delivered to AEGIS CGs & DDGs, SSDS Amphibs & CVNs, and DDG It is planned for USCG, FMS, and potentially LCS. CS Elements migrating to these consoles are SEWIP, Guns, UAVs, CV-TSC. We intend to have more CS Elements use CDS as soon as practical.
Common Processor System (CPS): CPS is being delivered to AEGIS and SSDS. Planned for USCG, FMS and potentially LCS. PARMS transitioning to CPS servers are SEWIP and Guns - intend to have more as soon as practical.
BFTT: Standardize hardware and software components across combat system elements to reduce cost, provide common training and maintenance, and take advantage of a shared network environment.
CANES Gateway: Reduces the number of gateways and provides and Open Interface between the C4I elements and the CS, and provides robust IA Assurance.
CIWS/SeaRAM/LPWS are existing common elements. Commonality in the future is good, but we also want to reduce variance in the in-service force today by aligning many different systems installations as packages.
Planned Future Efforts
Nav: Developing common Navigation functions across Surface Navy, ECDIS-N, VMS
C/S LAN: transition to network-based COTS Computing Environment to support future warfighting improvements where Elements will Publish and Subscribe for data to reduce point to point communications.
Enterprise Air Surveillance Radar (EASR) initiative to develop a Future common radar element to replace rotating radars on Carriers and Amphibs.
ESSM BLK II and SEWIP BLK II/III are future common elements that are planned for integration into AEGIS & SSDS.
ESSM
“Configuration variance in surface ships is not sustainable and must be reduced to manageable levels”
USFFC Letter 01 Aug 13
Combat System Commonality

13. USD AT&L
BBP 1.0 and 2.0 focused on cost consciousness and professionalism as critical elements of our culture
BBP 3.0 is focused on achieving dominant capabilities through innovation and technical excellence
Our technological superiority is not assured, and in fact it is being challenged very effectively right now
Honorable Frank Kendall
Under Secretary of Defense for Acquisition, Technology and Logistics

14. PEO IWS Systems Engineering Safe Firing Bearings
Understand the Current Design before you try to improve it.
Flow Requirements Down from the Force and Combat System levels to Sensors, C4I, and Weapons through a disciplined systems engineering process.
Pace threats in any new design.
Change only to improve Combat Systems Cornerstones.
Enable both a common tactical picture and integrated fire control in any new design.
Consider cost as an equal factor with technical performance.
Document Systems Engineering Decisions made for performance, cost, and risk management.
Predict Performance through the use of evolved end-to-end models and simulations. Judiciously use LIVE FIRE TO VERIFY …not discover.
TEST REALISTICALLY AT EXISTING LAND-BASED TEST SITES before initiating shipboard testing.
BUILD A LITTLE, TEST A LITTLE, LEARN A LOT!
PEO IWS Letter
Dated Nov

15. Summary Enabling Open, Modular, Scalable, and Extensible Designs
IWS Combat Systems Engineering using Open Systems Architecture has introduced opportunities to drive down costs and deliver combat capability to the war-fighter
BUT, Open Systems Architecture implementation is a long term effort that requires strong systems engineering discipline
Areas of focus going forward will be to:
Continue hardware footprint consolidation, keeping component obsolescence in mind
Identify effective strategies and opportunities for hardware/software component reuse
Mature systems engineering and business processes to support combat system development, reduce costs, and enable rapid deployment
Better align S&T transition plans to existing Programs of Records
Identify opportunities for continued Better Buying Power savings
Enabling Open, Modular, Scalable, and Extensible Designs