1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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.

8. 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

9. 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.

10. 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.

11. 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

12. 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

13. 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

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

15. 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

16. Backup
Page #

17. 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 #

18. 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 #

19. 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