Dr. Norbert Doerry, Tim Scherer, Jeff Cohen, Nickolas Guertin P.E. Open Architecture Machinery Control Systems ASNE Intelligent Ships Symposium 25 May 2011 Dr. Norbert Doerry, Tim Scherer, Jeff Cohen, Nickolas Guertin P.E. Statement A: Distribution is Unlimited

Main Concepts for a New Approach to MCS A Business Case for OA MCS Zonal Architecture Improves Acquisition and Shipboard Performance Naval Open Architecture and Product Lines Applied to MCS Next Steps

Open Architecture Defined OA CORE PRINCIPLES Naval Open Architecture: Business practices Technical practices Produce Systems: Based on open standards Published interfaces Modular, Loose Coupling, High Cohesion Design Disclosure and Data Rights Enterprise TOC Reduction and Reuse Transparency and Peer Reviews Competition and collaboration Naval Open Architecture (OA) is the confluence of business and technical practices yielding modular, interoperable systems that adhere to open standards with published interfaces. Interfaces are important, because we test to those interfaces. They become more “standards” that we follow, and give us a foundation to build on. OA Applied to MCS Business Technical ROI and Strategic Investments Can a qualified third party add, modify, replace, remove, or provide support for a component of a system, based only on openly published and available technical and functional specification of the component of that system

The Business Case for OA MCS - Development Cost Avoidance in MCS Development and Ship Construction Cross-Platform Product Reuse Integrated Logistics Support Incremental Testing Improved Schedule Performance Ship Construction Risk Reduction Improved Performance Access to Innovation Support for Automation

The Business Case for OA MCS – Life Cycle Cost Savings over the Life-Cycle Common Training Common Logistics Distance Support Transparency of Equipment Status Internal and External to the Ship Reduction in Software Maintenance – MFOP Current State of Practice OA Enables Competition for development and support

Zonal Architecture – Divide and Conquer Benefits of a Zonal Architecture Enhanced Survivability Local Control and Recovery Information Assurance: Defense-in-Depth Decompose Network Design for hierarchy of real-time performance Ship Construction testing and integration risk reduction Increased Maintainability and Troubleshooting Smart-loads minimize MCS design complexity

Zonal Architecture Characteristics Compartmentalization Data Decomposition As you go further to the right, more and more common across ship classes. To the left the elements are common, but more tailored to the specific ship.

Additional Features of OA MCS Cross-platform reuse to increase cost performance Elimination of proprietary design environments Soft PLCs Common HMI Escape hardware and software vendor-lock Reduced Enterprise Cost Rapid access to innovation Technology Insertion Transparency of Design Strategy and Resources Objective Architecture Defines Global Strategy Open Data Model to support integration of new components SDKs and Test Harnesses reduce system integration risk and test effort

OA Applied to MCS Classic Approach Independently Designed and Acquired on a Ship Class Basis CFE by the Ship Builder Typically Subcontracted OA MCS Approach General MCS Functional Decomposition Define the MCS Objective Architecture Define Supplier Market Boundaries Apply to a specific ship class Evolve the Family of Systems through Product Lines Establish an acquisition framework for incorporating innovation APB/ACB methodologies for software upgrades Technology Insertion strategies for hardware sustainment MCS Reusable Modules as GFE for modification and redelivery Naval Open Architecture: Business practices Technical practices Produce Systems: Based on open standards Published interfaces Government strategic use of Data rights to support competition; Periodic and strategic competition throughout the life cycle; Increased capability to the warfighter on a faster development timeline; Reduced life cycle costs; Shared risks with other programs through strategic alignment; Minimized duplication for technology development investments, shared life cycle costs; and Establish best fit solutions through open peer reviews.

Open Product Lines – the Next Step in the OA Revolution Product Line Focus: Build once, use subsequent variations Lower Cost to Upgrade Higher Quality Cross-platform utility Forward/Backward compatibility Reuse Open and managed reused components – strategic reuse Published architecture that specifies how features and behaviors are varied between products Assets can be competed as technology advances and/or mission needs change Reusable test scripts, plans, assets and harnesses shorten process and simplify execution See: Delivering Savings with Open Architecture and Product Lines; Womble, Arendt, Fain, Schmidt. https://acc.dau.mil/oa

Product Lines – Cross-platform use via variation points Management $$ Requirements Engineers Req Design Models Architects Models Source Code Developers Code Test Cases Testing & Validation Cases Shipclass ‘A’ ‘B’ ‘C’ Reusable Core Assets Product lines are a planned effort based on military needs, business strategy, and technology goals. A product line approach exploits commonality from a core system, and can result in tremendous cost and schedule improvements and decreased technical risk. At its essence, fielding a product line involves (1) development or acquisition of core assets, which can be hardware, software, documention, processes, and management artifacts engineered to be re-used, and (2) development or acquisition of improved products starting from core assets. (3) management and planning of core assets and product development. There are three overall product line acquisition approaches proposed by Bergey, 2010: 1. The government can commission a supplier to develop a specific product (or products) using the supplier’s own proprietary product line. This strategy involves acquiring products directly from a supplier who has an existing product line and a demonstrated capability to build products in the domain of interest. 2. The government can commission a government organization to develop a product line production capability and build specific products. This strategy involves acquiring a completely government-owned product line using the in-house capabilities of a designated government acquisition organization. The government can commission a supplier to develop a product line production capability and perform integration of products from other vendors into the production line. This strategy involves acquiring a complete product line production capability and developing derivative products through contracting with one or more suppliers. Major challenges to implementing any of these Product Line approaches include the fact that DoD’s acquisition policies and infrastructure are still largely predicated on acquiring ‘one-of-a-kind’ stove-piped systems, and no institutionalized means exist for funding the development and sustainment of a product line across multiple programs. Nevertheless, successful DoD product lines are being created by acquisition authorities with vision and foresight enough to overcome the difficulties and reap the benefits. © Carnegie Mellon University, Software Engineering Institute

We are not alone Several OA efforts in the Navy that are launching points for Open Product Lines and OA MCS PEO IWS: Combat Systems Objective Architecture PEO SUBS: SWFTS Objective Architecture PEO U&W: Future Airborne Capability Environment PEO C4I: Common Afloat Network Enterprise Services DASN RDT&E: Naval Enterprise OA Industry Consortia: Open PLC ASW and MPRF COI’s: Data Modeling OMG: Real Time Data Distribution Service

Guiding Principles Reusable, multi-platform, Product Line Modules Alignment of MCS Boundaries with physical ship zones Zonal Survivability Improved Construction Performance Partition functionality among local, zonal and shipwide controls Ship Construction Testing and System Checkout Control Environment Abstraction for configuration independence Network Connectivity off-board to enable distance support, status reporting, and eventually MFOP Use a hardware business model that uses the commercial market Hardware/Software Independence Technology Insertion production and sustainment model

Evolving Standards to Prevent/Escape Vendor Lock Naval Enterprise Architecture Description Document Open PLC standard - IEC 61131-3 Distributed Control and Automation standard IEC 61499 OMG Real Time Data Distribution Service (DDS) standard Understand and use Government Rights to Data https://acc.dau.mil/oa

Next Steps Create a MCS Communication Standard and Data Message Content Update MIL STD 1399 Establish a MCS COI Develop a MCS Data Model Write a MCS ADD Evolution into an Naval Enterprise ADD Build off PEOs IWS and Subs ADDs Contribute to the Cross-SYSCOM IA Defense-in-Depth Architecture Distance Support reduces support cost; connectivity is needed Reusing products from Navy programs Commonality Shelf Products Common Display System/Common Processing System

Backup Page #

Combat Systems OA + Product Lines DDG1000 Integration New ship class Integration Aegis Integration Carrier / Amphib Integration SSDS Update Shared Components for Future Applications and Available for Backfit The Surface Navy is implementing an overarching strategy to acquire, upgrade, and maintain combat systems using an open architecture and product line approach (PEO IWS, 2009), building on the success of the Submarine community’s application of open architecture with its sonar systems through the Submarine Acoustic Rapid Commercial Off-the-Shelf Insertion (A-RCI) / Advanced Processing Build (APB). The first execution of the strategy on active ships has decoupled the combat system software from its supporting hardware through the Advanced Capability Build (ACB08) on the aircraft carrier Nimitz and the cruiser Bunker Hill. As shown in the Figure, the end state desired is that the next class of ships would integrate the latest increment of shared and newly developed components available rather than developing a new combat system for every new ship. The same shared components will be available for back fit ship application. This is in stark contrast to the past where ships with tightly coupled combat systems and hardware were contracted from a limited choice of capable prime contractors. BUSINESS TECHNICAL Page #

Combat Systems Update Cycles ACB / TI Notional Model • Requires transition to COTS computing via initial TI • Each ACB builds on prior ACBs while adding new capabilities • Transitioned ships receive new ACB every 2 years • Every ship receives every other TI Page #

Crawl, Walk, Run – Reducing Variation Capture the value of recent commonality studies VME PLC Network Protocols Workstation Topology Functionality Methodology Target the Cost Drivers System Design and Test Acquisition and Installation ILS Corrective Maintenance and Obsolescence