Defense Daily Open Architecture Summit 2014 “PEO IWS Open Architecture Implementation” Mr. Bill Bray, Executive Director Program Executive Office, Integrated Warfare Systems November 4, 2014 DISTRIBUTION STATEMENT A: Approved for public release; Unlimited distribution.

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

Implementing Open 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

Evolution of Open Architecture

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

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

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

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

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

SSDS Single Source Library Software Superset Supports All Platforms 2004 Open Standards-Based Designs Componentized Architecture Well-Defined Interfaces Open Architecture (OA) Foundation CVN 68 2014 LPD 2004 “Fix it Once” LHD 2003 2005 Single Source Library Build Process Single Install Media LHA Core - 2003 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 - 2005 OA, ESSM/AEC - 2006 RAM BLK 2 - 2010 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 - 2013 2014 DBR, Mode 5 (engagement only), ESSM with uplink, Product Line Software Components, SEWIP - 2014 LSD Enables Technology/Capability Insertion Across Diverse Platforms 2015 CVN 78 Extensible Architecture Translates Into Reduced Development, Maintenance and Training Costs

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 OA 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 1000. 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 20140808 Combat System Commonality

Better Buying Power 3.0 Achieve Dominant Capabilities While Controlling Life Cycle Costs Strengthen “should cost” as an important tool for cost management Build stronger partnerships between acquisition, requirements, and intelligence communities Anticipate and plan for responsive and emerging threats Institutionalize stronger DoD level long range (R&D) planning Incentivize Productivity in Industry and Government Align profitability more tightly with Department goals Employ appropriate contract types, but increase use of incentive type contracts Improve the return on investment in DoD laboratories Increase productivity of industry IR&D and CR&D Incentivize Innovation in Industry and Government Increase the use of prototyping and experimentation. Emphasize technology insertion and refresh in program planning Use Modular Open Systems Architecture to stimulate innovation Increase the return on Small Business Innovation Research (SBIR) Eliminate Unproductive Processes and Bureaucracy Promote Effective Competition Improve Tradecraft in the Acquisition of Services Increase small business participation Strengthen contract management Improve Requirements definition Improve the Professionalism of the Total Acquisition Workforce

Summary IWS has been proactive in implementing Open Architecture precepts and concepts to the Surface Navy Open Architecture implementation has introduced opportunities to drive down costs and be more effective in the acquisition and deployment of combat capability BUT, Open Architecture implementation is a long term effort with much left to accomplish with a foundation in strong systems engineering discipline Our focus going forward will be to: Transition S&T into Programs of Records more effectively Continue hardware footprint consolidation Identify efficient and effective strategies and opportunities for software, component reuse Mature systems engineering and business processes to support combat system development, reduce costs, and enable rapid deployment Identify opportunities for continued Better Buying Power savings

BACK-UP SLIDES

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

Rising Costs Bring Focus on Total Ownership Costs Manning Training Mission Mission effectiveness Logistics Interoperability Capability Systems effectiveness Testing Modeling & simulation Construction System/Configuration Item performance Systems Engineering Focus Open System Architecture Standards Gov’t Data Rights Total Ownership Costs (TOC) is a focus of Systems Engineering Source: A.W. Meeks, Naval Open Architecture Avoiding Cost Growth through Open System Architecture, 22 April 2009