Dr. Norbert Doerry, Tim Scherer, Jeff Cohen, Nick Guertin U.S. Navy: NAVSEA, NAVSSES, NAVSSES, PEO-IWS Open Architecture Machinery Control System commercial markets by various control ABSTRACT system suppliers who tailor their products to Machinery Control Systems are currently meet the customer’s specifications and individually crafted for each class of ship. Just frequently utilize existing technologies as the combat systems community is improving based on their experience on other ship performance while reducing cost through an platforms. As the result, the installed MCS open architecture approach, an opportunity products have a variety of Commercial-Off- exists to develop and field an open architecture The-Shelf (COTS) flavors and in many machinery control system for use on all naval cases proprietary software and hardware ships. This paper proposes a business and components. Because MCS suppliers have technical approach to developing an Open been able to leverage existing product Architecture Machinery Control System hardware, software, and development (OAMCS) common across all classes of ships. investment, customers typically get Once adopted this approach would provide competitively package pricing during initial commonality across the fleet while preserving system procurement. However, it becomes competition and a viable industrial base. This more costly to obtain and replace MCS commonality facilitates user training, improved components as the systems age and require maintenance, and regular software and hardware maintenance or upgrading due to the updates. specialized nature of each supplier’s products. Furthermore, the propagation of The technical approach includes a description of different vendor-specific products in a the open standards needed both within the particular fleet requires extra effort and cost boundaries of the MCS and between the MCS to train the operation and support and the user equipment. A description of the personnel." activities required during ship design and acquisition is also described. To address the supportability issues of the current approach to developing machinery INTRODUCTION control systems for shipboard applications, increase access to innovation, and reduce both The views expressed herein are the personal development and life-cycle cost, the authors opinions of the authors and are not necessarily propose that the Navy invest in developing an the official views of the Department of Defense open architecture approach. or any military department thereof. As described by Nguyen et al.: OPEN ARCHITECTURE "Machinery Control Systems (MCS) on both APPROACH commercial and military platform have Open Architecture is a collection of best evolved into multi-layer distributed and practices, technical and business, when redundant control systems that provide combined with a willing corporate culture, can versatile and reliable control and monitoring result in a highly effective life cycle strategy of ship HM&E equipment. Ship equipment where total cost of ownership is minimized and typically includes propulsion plant, electric capabilities to the warfighter are maximized. plant, damage control or safety equipment, and a host of auxiliary systems that support As defined by the Open Systems Joint Task the operation of the previous three major Force (OSJTF), an open system "employs systems. There is a wide-range of MCS modular design, uses widely supported and product offerings for the military and consensus based standards for its key interfaces, and has been subjected to successful validation
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 1 DISTRIBUTION IS UNLIMITED
and verification tests to ensure the openness of 4. Enhanced transparency of system its key interfaces." An open architecture design through open peer reviews; "employs open standards for key interfaces within a system." Open standards "are widely 5. Competition and collaboration used, consensus based, published and through development of alternative maintained by recognized industry standards solutions and sources; organizations." An important objective of an 6. Analysis to determine which open system is to enable any competent supplier to provide modules or elements conforming to components will provide the best the standards that can be easily and successfully return on investment (ROI) to integrated into a working system meeting open…i.e., which components will customer requirements. Furthermore, the owner change most often due to technology of the system can take advantage of competitive bids among suppliers seeking to provide each upgrades or parts obsolescence and module. have the highest associated cost over The Navy has extended the work of the Modular the life cycle. Open Systems Approach (MOSA) work Achievement of these six principles requires performed by the DoD Open Systems Joint Task an affirmative answer to a fundamental Force (OSJTF) to more comprehensively question: achieve those desired goals as a part of the Can a qualified third party add, Naval Open Architecture (NOA) effort. NOA is modify, replace, remove, or provide defined as the confluence of business and support for a component of a system, technical practices yielding modular, based only on openly published and interoperable systems that adhere to open available technical and functional standards with published interfaces. It is the goal of the Naval Open Architecture effort to “field specifications of the component of common, interoperable capabilities more rapidly that system? at reduced costs”. In order to successfully permit a third party to add, modify, replace, remove or provide Guertin and Clements (2010) addressed the support as noted in the question above, the following core principals of the Open Navy must follow these business and Systems Architecture approach: technical elements as the program foundation 1. Modular designs with loose Foundational Business Elements of Open coupling and high cohesion that Systems Architecture: allow for independent acquisition of system components Government strategic use of Data 2. Continuous design disclosure and appropriate use of data rights rights to support competition; allowing greater visibility into an Periodic and strategic competition unfolding design and flexibility in throughout the life cycle; acquisition alternatives; 3. Enterprise investment strategies Increased capability to the warfighter that maximize reuse of system on a faster development timeline; designs and reduce total ownership Reduced life cycle costs; costs (TOC);
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 2 DISTRIBUTION IS UNLIMITED
Shared risks with other programs a. A published objective architecture specific to real-time systems like MCS that provides through strategic alignment; industry standard design patterns that provide Minimized duplication for for hardware independent software development, virtualization to reduce vendor dependant technology development solutions, and isolation of proprietary design elements to maximize acquisition flexibility. investments, shared life cycle costs; b. An industry/Government consortia based and processing architecture and data model. Establish best fit solutions through c. Development kits and test harnesses that ensure software portability, consistency of open peer reviews. implementation, risk reduction for system Foundational Technical Elements of integration, and ability to field subsets of the system for zonal platform module shipboard Open Systems Architecture: construction and integration testing. Modular designs with low coupling These documents provide the enabling and high cohesion based on open environment that is needed to support the standards and published interfaces; development an open technical system and associated open business practices for design, Separation of hardware and software integration and certification processes, and to prevent hardware obsolescence technologies to successfully implement the complexities; strategy. Maximized reuse of assets to limit The Navy's previous success in implementing open architecture in the Acoustic Rapid COTS program unique development; Insertion (ARCI) program is well known and Full Design disclosure; documented by Boudreau (2006). Similarly, the Aegis Open Architecture program is currently Limited use of proprietary being implemented as part of the ongoing components, but establish well- Cruiser and Destroyer modernization programs. defined open system interfaces In June 2009, U.S.S. Bunker Hill (CG 52) was where those solutions perform the the first cruiser to complete the modernization best value; work including the Aegis Open Architecture Use of Modular Open Systems Guidance for incorporating the open architecture Approach (MOSA) and OSA- approach can be found at https://acc.dau.mil/oa. specific compliance metrics. Products available at this site include the "Naval Open Architecture Contract Guidebook for The confluence of these business and Program Managers", the Open Architecture technical foundational elements will support Assessment Tool and other items issued by the Naval Open Architecture Enterprise Team and the achievement of Office of the Secretary the DoD OA Team. of Defense Acquisition, Technology & Logistics (OSD AT&L)’ Better Buying Power efficiency initiative.
The next innovation in the NOA transformation is to establish Open Product Line methods (Guertin, Clements 2010). These changes should embody the next evolution of MCS and include:
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 3 DISTRIBUTION IS UNLIMITED
OPEN ARCHITECTURE The MCS now becomes a family of MACHINERY CONTROL systems that can be applied across a range of different ship classes and enjoy SYSTEM the benefits of product line development and strategic reuse across a market of Introduction to OAMCS similar products. As changes to the As described by Amy et al. (1995) the present ship’s mission or requirement is acquisition approach for shipboard machinery identified for one class of ships, those control systems is: performance characteristics can be easily made available throughout the Once a set of ship requirements is rest of the fleet as part of the variation established, conduct a design which points embedded in the software design. discerns between alternatives to yield a This focus on cross-platform reuse will specific solution that fulfills the stated have down-stream cost savings requirements. The design is optimized associated with common training, on initial acquisition cost, assuming that logistics, and in-service product support. the stated ship requirements are met. Advanced features can be incrementally Sister ships are to be as identical as added to the fleet to improve possible. performance through automation and Throughout the life of the ship, convert reduce lifecycle support costs such as and/or modernize to the degree possible Maintenance Free Operating period or affordable. (Guertin & Bruhns, 2011). In contrast, the proposed approach for an open architecture machinery control system would be: Guiding Principles Conduct a functional decomposition of Some guiding principles for producing an naval ships in general to identify affordable machinery control system include: common functions and key interfaces. a. Design software configuration items to Develop a machinery control system be re-usable across multiple classes of open architecture which is built upon ships as part of a product line approach. open standards, functional modules with This requires a level of abstraction of loose coupling and high cohesion and machinery control system functions for defined interfaces through a published generic applications and defined objective architecture that defines the “configuration” mechanisms to adapt to modular construct to an appropriate specific ship requirements and system level of abstraction to minimize designs. development complexity and facilitate b. Align MCS system boundaries with the acquisition choice along natural physical zones of the ship. Enable zonal business markets. survivability by appropriate partitioning For a specific ship design, aggregate of control functions. selected modules within the framework c. Partition functionality among local, of the open architecture machinery zonal and shipwide controls to minimize control system. Verify that ship dependence on other elements of the requirements are met. A small number MCS in performing installation check of non-common (unique) modules may out and testing. be identified. They will, however, have d. Controls at the shipwide network level interfaces that are openly published should operate at a level of abstraction through an updated common data model that is independent of the particular and comport to the objective configuration of the ship. Ideally this architecture. software is ship independent, but
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 4 DISTRIBUTION IS UNLIMITED
configured through static configuration part of the ship could have a root cause files or self discovery. anywhere in the ship. e. Network Connectivity to the shipboard As shown in Figure 1, the OA-MCS has the network to enable distance support as following features: well as reporting of health and system status to both shore subject matter a. Ship-wide Network: This fault tolerant experts and operational commanders. network spans the total ship and crosses f. Utilize common hardware that is zone boundaries. It communicates to considered a commodity, where the zonal level elements and vendor manages obsolescence as an external/offboard networks through element of its business model. network bridges that incorporate firewalls. While individual equipment OAMCS Description and sensors may not yet reside on the shipwide network, automation and Figure 1 shows the authors’ concept for an Open supervisory level controls in addition to Architecture Machinery Control System. In this shipwide Human Machine Interfaces model, the OA-MCS is aligned with the overall (HMI) connect directly to the shipwide zonal architecture of a ship (Doerry 2006). A network. For the initial implementation zonal approach has the following advantages: of an OA-MCS, the authors anticipate a. Enhances survivability of the that this network will employ Ethernet machinery control system and the and internet protocols. overall ship by implementing zonal b. Zonal Network: A zonal network is survivability. Zonal survivability provided for each ship zone. ensures machinery controls Communication to other zonal networks, implemented in one zone are isolated external systems, and shipwide control from faults outside of the zone. The elements is accomplished via the network bridges and firewalls between network bridges / firewalls. Although a the shipwide network and the zonal business case must still be completed, networks provide a layer of defense for the authors anticipate that the zonal Information Assurance. network will employ a modern data b. Enables different network technologies distribution service for real time systems to be used for the zonal and shipwide and provide for hierarchical quality of networks. Different technologies may service attributes as required by each be desirable because the design sensor/machine type. HMIs could be objectives for each network are connected to the zonal network as well. somewhat different. This will provide for true local control c. During ship construction, the zonal and survivability if the zonal network is controls can be tested as an integrated cut-off from the ship-wide network. system before the ship is completed. c. The OA MCS objective architecture Full integrated testing of the shipwide must incorporate the Information controls must wait until the ship is Assurance principle of defense in depth. largely completed. A robust MCS design must also be able d. By aligning the boundaries of the to support incremental ship construction Machinery Control System with the and, should the need arise, graceful zonal boundaries of other systems, degradation in the face of ship damage situational awareness of the operators is or component failure. Firewall services, improved. Problems that manifest and decomposition of network topology themselves in one zone are likely caused network by using strategically placed by something going wrong within the routers, switches and network bridges zone. Without a zonal implementation, will limit performance risk from issues problems manifesting themselves in one arising in affiliated external ship-wide
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 5 DISTRIBUTION IS UNLIMITED
networks and ensure the zonal networks conducted to determine if requiring the are able to respond under conditions of equipment to meet the smart load system degradation and to minimize requirements or by using a DAU/PLC to exposure to network intrusion risks. IA convert the available interface protocols and security needs to be thought of at to the smart load interface is more the outset of any new MCS design. affordable. Confidentiality, Integrity and e. One of the major hurdles in affordably Availability of data must be assured in installing MCS systems and building a any MCS. Data Acquisition Units new ship design can be dramatically (DAU) / Programmable Logic improved through the use of a Zonal Controllers (PLC) provide direct Control architecture topography. Zonal interfaces with Equipment and Sensors. Control coordinates the control activity Software in the DAU / PLC must of multiple DAU / PLCs within a zone. provide standardized abstractions of the Zonal Control in one zone may devices to the higher level zonal communicate with Zonal Control of controls or shipwide controls. another zone at the direction of a Replacement of a sensor with a new Mission System Resource Manager or model should only impact the DAU / Distributed System Manager. However, PLC and not any other element of the the software in the Zonal Control should MCS. The software should also perform be fully testable independent of the error detection (and error correction if Zonal Control in other zones. The possible) and filtering of sensor data. combination of controls in user The software in the DAU / PLC should equipment, the DAU/PLCs and zonal be maximized to the extent possible to control should enable stable (but not be fully testable independent of other necessarily optimal) zonal operations DAU / PLCs. One of the emerging without communication through the standard of particular interest in this shipwide network. Zonal Control would area is IEC 61131 and IEC 61499. The be appropriate for many automation evolution of the soft PLC construct tasks where the equipment is all within allows vendor independent development one zone. For example, coordinating of MCS functions in a open and the starting and bringing online of a standard format (e.g. OpenPLC XML). generator set would be appropriate for Once the functionality is designed, the zonal control. Automation tasks hardware specific implementation can involving multiple zones would likely be translated to run in a vendor unique be coordinated by a distributed system environment. This innovation from the (or mission system) manager, but commercial embedded technology implemented through direct market can dramatically change the communication of Zonal Control in standard practice of developing MCS different zones. As shown in Figure 2, applications in such a way as to severely control action that requires segregation limit cross-platform reuse and for reliability, maintainability, ship development of components that can be construction or damage control purposes used across multiple MCS should not reside in the Zonal Control, implementations. but should be allocated to the DAU / d. Smart Load. A Smart Load incorporates PLC or equipment control. If the functionality of the DAU / PLC appropriate, Zonal Control may reside in within the boundaries of the load. It hardware common to the DAU / PLC. directly provides the standardized f. Zonal Human Machine Interface (HMI): abstraction of the device to the zonal provides the means for the human network. In selecting user equipment, a operator to communicate with the MCS. business case analysis should be From a controls perspective, the HMI
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 6 DISTRIBUTION IS UNLIMITED
does not include any control algorithms, components during construction or but does incorporate software for repair availabilities when full ship’s display, user authentication, permission power or other network services are not management, alarm management, and available. user input. Under normal operation, the i. Mission System Managers: A mission Zonal HMI will behave identically to system manager should exist for each the shipwide HMI. However, if network mission of the ship that has associated traffic is blocked through the Network equipment installed on the ship. These bridge / firewall, the Zonal HMI will Mission System managers are software only communicate with zonal equipment that reside on a hardware infrastructure. and controls. Normally the Zonal HMI Nothing would preclude multiple is a backup to the shipwide HMI. Mission Systems and Resource g. HMI (shipwide). The HMI provides the Managers residing on the same means for the human operator to hardware platform. One deviation from communicate with the MCS. It differs past practice could be the creation of a from the Zonal HMI only in that the Mobility Controller to manage the ships shipwide HMI may not be able to propulsion, steering, and roll control communicate with zonal loads through equipment. This Mobility Controller the Network Bridges / Firewalls during would communicate with other systems faulted conditions. The shipwide HMI to determine the best operating points will be the normal mode for users to for each of its associated equipment to communicate with the MCS. steer the operators desired course; to h. Distributed System Managers. A achieve a given speed; to limit ship distributed system manager exists for motions to specific accelerations; and to each distributed system such as minimize fuel consumption. Other Electrical Power, fireman, chill water, examples of the Mission Systems ventilation, JP-5, Fuel storage and Managers could include ballast / transfer system, potable water, CHT, deballast systems for amphibious assault AFFF, etc. The Distributed System ships, Aircraft Launch and Recovery Manager gathers operator input from the systems for aircraft carriers, combat HMI and implements it by sending systems, communications systems, and configuration and set point commands to damage control systems. Mission zonal controllers, smart loads, and Systems Managers ensure the correct DAU/PLCs as needed. The Distributed mission equipment is online or in System Managers ensure their systems standby to meet both current needs and are configured to meet existing demand, anticipated needs. Mission Systems can respond appropriately to anticipated Managers communicate with Distributed changes in demand, and can Systems Managers to ensure load shed successfully identify, isolate, and priorities are appropriate for the current reconfigure around distributed system ship operations as well as ensuring equipment failures and damage. The distributed systems have sufficient Distributed System Managers work with online capacity or "rolling reserve" to Mission System Managers and other handle anticipated increases in load. Distributed System Managers to j. Service Managers. Service Managers dynamically manage load shed support the operator and the other contingencies for the purpose of elements of the Machinery Control maximizing the ability of the ship to System. Examples of Service Managers conduct its missions in the event of include Onboard Training (OBT) equipment failure or damage. This data Systems, Data Logging, Condition architecture has the added benefit of Based Maintenance trending and supporting installation and test of analysis (such as ICAS), ship
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 7 DISTRIBUTION IS UNLIMITED
configuration and equipment status REDUCING VARIATION management, tagout management, maintenance management, technical A significant state of the practice affecting manual library, operational procedure overall Enterprise cost is that each ship class has management, etc. As with the Mission a different Machinery Control System. While the Systems Managers, the Service number of input/output (I/O) signals serviced by Managers are software that reside on a MCS is growing rapidly, so is the variability in hardware infrastructure. Sometime in MCS hardware, components, software, and the future, it may be possible and human machine interfaces across the fleet. Every desirable to encapsulate all ship specific new ship class has a unique MCS. information into a service manager (and This increasing variation drives life cycle cost potentially DAU/PLCs) such that all by requiring expertise in multiple vendor HMI, zonal HMI, Zonal Controls, hardware and software environments. Variation Mission System Resource Managers, and Distributed System Managers are also dictates a larger need for spare parts and a identical for all ships. larger variation in vendors and support
Mission infrastructure. The cost of training is increased, System - Supervisory ResourceSupervisor since each system is unique. There is no Equipment or ManagersControl
Sensors DAU / PLC y Control
Network Bridges Firewalls leveraging of previous efforts or software re-use
Equipment or Bridges
Sensor s DAU / PLC Network Bridges Network Network Distributed Equipment or SystemDistributed to lower cost and mitigate risk. Sensors DAU / PLC SystemDistributed
Zonal Managers System Network Zonal HMI Managers Smart Load Managers Zonal Control Network Unique systems also result in the use of vendor Zonal HMI HMI HMI specific development environments and Zonal Control HMI Equipment or Sensors DAU / PLC Shipwide programming languages that preclude strategic
Equipment or – DAU / PLC Service Sensor s Service software reuse across multiple classes. In ManagersService
Equipment or Managers
Network Firewalls
Sensors DAU / PLC Bridges Managers Zonal
Bridges addition, unique ship class related system
Network Network
Network Bridges Smart Load Network Network External & architectures and component design patterns Bridges – Off Board Firewalls Networks reduce opportunities to gain economies of scale Figure 1: Open Architecture Machinery Control efficiencies in support costs and software System Functional Architecture development environments. Variation is also typically seen in the HMI, requiring operators to have additional training when changing ship Mission System - Supervisory ResourceSupervisor classes. Training requirements for operators and Equipment or ManagersControl
Sensors DAU / PLC y Control
Network Bridges Firewalls maintainers are increased due to the differences
Equipment or Bridges
Sensor s DAU / PLC Network Bridges Network Network Distributed Distributed Equipment or System between systems. As commercial manufacturing Sensors DAU / PLC SystemDistributed
Zonal Managers System Network Zonal HMI Managers Smart Load Managers plants reduce their patchwork of obsolete Zonal Control Network automation solutions to gain economies of scale Zonal HMI HMI HMI Zonal Control HMI from reducing variation, the Navy should Equipment or Sensors DAU / PLC Shipwide
Equipment or – consider a similar approach. DAU / PLC Service Sensor s Service ManagersService
Equipment or Managers
Network Firewalls
Sensors DAU / PLC Bridges Managers
Zonal
Bridges
Network Network
Network Bridges Smart Load Network A recent deep dive study on MCS variation Network External & Bridges – Off Board Firewalls Networks sponsored by NAVSEA NAVSEA Commonality Programdetermined that there are Fast 5 ms or 20 ms or 100 ms or over one hundred eleven circuit card variants in slower slower slower machinery control systems on ships where either Figure 2: Time Scale Separation PLCs or microprocessors connected to a VME backplane were utilized. NAVSEA
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 8 DISTRIBUTION IS UNLIMITED
Commonality ProgramNAVSEA Commonality and customer support. Based on these criteria, Program also estimated that nearly fifty percent the NAVSEA Commonality Program study of this variability could be reduced at a life cycle concluded that: savings of $18M-$27M. In addition, Open Architecture practices that establish software Navy GIC solution provided the optimal for overall life cycle costs followed by independence from specific hardware baselines Industrial COTS. would free engineers and life-cycle support Military COTS solutions vary in professionals from being tightly bound to ship- competitiveness due to a wide range in by-ship obsolescence management efforts, acquisition costs precluding design efforts for innovation and Custom Proprietary solution is capability enhancement. Emerging design competitive for acquisition costs, but strategies that use Virtual PLC constructs would uncompetitive for obsolescence and allow products developed for one class, with availability Overall, the Hybrid scenario is the most unique target hardware to be reused without competitive solution for life cycle costs, wholesale hardware specific reverse engineering quality, performance, obsolescence, and fruitless redesign. These advantages of the availability, and customer support Virtual PLC construct must be traded off from a The key points from this conclusion are that total ownership cost perspective with using COTS VME solutions, which are used in traditional commodity based hardware PLCs. industrial applications, can be competitive in Example: VME Circuit Card Variation overall life cycle costs. The Navy GIC VME As part of the study, NAVSEA Commonality solution is also cost competitive. While military Program investigated VME cards for MCS COTS and custom proprietary solutions may be applications. Five unique VME system types cost competitive in the acquisition phase, they were analyzed across various hulls: are less or not all cost competitive over the life cycle. Reduction in the variation of the Industrial COTS: High volume, interfaces of connected sensors and equipment industrial control applications will also be a key benefit in reducing the number Military COTS: Low volume, military of different VME cards. control applications Custom Proprietary: Low volume, PLC variation Navy-specific applications NAVSEA Commonality Program also analyzed Navy-GIC: Generic Instrumentation & PLC module variation. They identified similar Controls (GIC) for Navy applications modules provided by the PLC manufacturers Hybrid: A combination of GIC Processing and Industrial COTS I/O and recommended eliminating variation by cards selecting the best module, typically the newer module. The key findings of the NAVSEA Commonality Program study found that VME card variation is They recommended phasing out older models driven by unique MCS designs and I/O for use on new ships, while stating that there requirements. These designs resulted in fifty- was no need to upgrade existing PLCs due to eight unique VME cards driven by lack of obsolescence support lasting for ten or more standardization. years. Circuit card obsolescence is managed by the vendor, and as such there is no incremental VME systems were evaluated on life cycle cost, cost to the Navy. The study noted that overall quality, performance, obsolescence, availability,
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 9 DISTRIBUTION IS UNLIMITED
PLC life cycle costs are similar for either of the that takes advantage of the work going on in primary U.S. Navy PLC vendors, though single industry (virtualization for displays and soft sourcing should be avoided to ensure PLC) and other Navy real-time personnel safety competition. (Future Airborne Capability Environment) and weapon safety, PEO IWS’s Combat System Workstation variation Objective Architecture, designs provide a an Workstation variation was analyzed by alternative approach that when accepted by the NAVSEA Commonality Program as part of the community to be more cost effective, will MCS deep dive. At the time of the analysis fundamentally shift how these systems are built there were twenty-four different operator and sustained in the fleet. workstations. NAVSEA Commonality Program concluded that the number of workstations could In a second MCS deep dive (2010) and an be reduced to eighteen with six major styles: analysis of commonality opportunities for Machinery Control System architecture was Sitting – single display conducted. Where in the first deep dive looked Sitting – dual display at variation in components this one evaluated a Sitting – three displays reduction in architecture areas such as MCS Standing console topologies and interfaces. This analysis was Bulkhead mounted terminal – status performed on 25 different new acquisition and panel Bulkhead mounted terminal – operator in-service ship classes and was expanded to interface include ship classes in the United States Coast Guard. For this deep dive the scope of the There are several variations for each of these Machinery Control System includes all the workstations/displays that require eighteen devices, connections and network equipment different designs. The future target is eight between Operator and actual shipboard workstations to further reduce variation and machinery. To understand the current state of associated costs. MCS architecture, the MCS was deconstructed Workstations and equipment in the control layer the various layers into attribute categories are the best opportunities for gaining economies 1. Topology is the physical layout of MCS of scale and reducing variation in hardware, components and connected devices 2. Functionality represents the systems that software, and user interfaces. This will have a are controlled and or monitored by the significant impact in overall total ownership Machinery Control System costs. 3. Methodology represents the key architecture philosophy decisions such For VME, PLC and display consoles designs, as whether to distribute or centralize the majority of the investment is in the software. processing, or whether to have a client- A new strategic approach based on the OA server or publish-subscribe practices of software independence from communication scheme hardware provides an opportunity to improve the 4. Interfaces are the connections between MCS components and external systems ability of the Navy to capitalize on the 5. And Protocol which are the standards commonality studies. These specific studies will that define the process, syntax and certainly generate lifecycle cost savings for the format of data across all layers of MCS current architectural constructs of platform and From the current state an analysis of what hardware unique design and development. defines variation in a control system was However a common MCS objective architecture performed. This variation was distilled down
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 10 DISTRIBUTION IS UNLIMITED
into twenty-four categories. Each category was operators becoming effective rapidly as they then evaluated for the relative cost across a set move to different ship classes. Common of Total Ownership Cost elements including: methodologies for controlling processes and for System Design and Test, Acquisition and managing alarms will become more critical as Installation, ILS, Corrective Maintenance and MCS size and complexity continues to grow. Obsolescence. Cost drivers for each area were evaluated. The result of this analysis produced a Reduced variation has the potential to save life comprehensive understanding of cost drivers and cycle costs in numerous areas with the added relative cost differences for each ship class. The benefit of providing the sailor fewer systems to result of this deep dive recommended a 57% learn to troubleshoot and more standard user reduction in choices across the twenty-four MCS interfaces to learn. The opportunity to enable architectural decisions. Some of the key these benefits is during ship requirements findings are that software-related decisions have development and design. the biggest decision-level impact for MCS, in particular development and support costs. Also, BUSINESS CASE FOR AN OA- initial MCS design is critical a critical element MCS of overall TOC. The ability to reuse previous Development of software modules in the OA systems for future design will drive significant environment will benefit existing programs as improvements in TOC. well as future programs across other classes. Once a new acquisition or modernization MCS Other variations to be addressed is developed using Open Product Line design Lastly, two of the larger challenges in the practices, built against an Enterprise Objective acquisition of MCS are 1) that the systems and Architecture, the resulting certified products are interfaces connected to MCS continually evolve in essence locked down, the modules can be during the ship design process, and 2) that every placed in a repository for future use by other ship design has a different MCS HMI. programs. These modules can be used as is or upgraded and evolved as a part of a product line A large number of interfaces has an impact on and published back to the development the number of circuit cards that are required to community for others to expand on and improve. connect sensors and control devices to the The value proposition of product line control system. Interfaces should be development includes the fact that as each standardized so that modules are easily inserted subsequent variation is developed, additional in a plug and play environment to adapt to features are added that can be applied both to the system changes, and there is less impact to MCS previous product line users and to subsequent hardware, software, and HMI during ship projects. Also as each new feature is added, design. latent bugs are resolved, thus improving the A common HMI with a common presentation to overall quality. Finally, because new the operator would reduce training and should development projects are not starting over, they enable lower cost in design by using common can more rapidly get capability to the user objects and common screens. Currently, each (Guertin & Clements, 2010). This enables new ship design has an Integrated Product Team continual improvements of existing modules established to design the MCS HMI. A common with all programs benefiting from a singular HMI would reduce effort across the enterprise in investment. This will require well defined and the design of successive HMIs and result in well understood interfaces and protocols so that
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 11 DISTRIBUTION IS UNLIMITED
functional modules are able to communicate and combatant (LCS), and amphibious warfare ships operate cohesively. such as the LHA 8 or LSD (X) provide opportunities to improve life cycle costs through Utilization of a real-time data distribution open architecture, commonality, and software service is essential to break into a more re-use. Many of these opportunities exist in the productive pattern of MCS system design and next five to seven years given the current warfighter value proposition. This needs to be acquisition plan in Table 1. built together with a fully published and community developed Enterprise data model so Modernization programs also present that as each newly designed MCS brings in new opportunities to implement an OA-MCS or to communication messages that can take utilize aspects of the OA-MCS in concert with advantage of the message sets developed by other commonality efforts to save in other projects. To improve this contribution to modernization development. Current cost, interface standards should be developed (or modernization programs may be leveraged to a limited set of commercial standards should be introduce OA-MCS concepts or modules on adopted as Navy standards) along with a small scale basis by implementing the initial reference architecture and a community enforced fleet introduction of the software test harnesses set of tools to form a software development kit, and associated community standard all of which will allow the various controllers, development utilities in the modernization mission modules, and user equipment to program, placing the certified software in the communicate with minimal if any configuration Navy’s SHARE repository (in essence, a by the user. software shelf), and later used in a new acquisition program or modernization program. TRANSITIONING TO AN OA- Licensing costs are reduced or eliminated, MCS documentation development and review costs Two paths exist to transition an OA-MCS into are reduced, and risk is reduced by utilizing the fleet – through new acquisition or through software that has been certified. Examples of modernization programs. Based upon the 2010 these types of software modules could be an shipbuilding plan published by OPNAV N8F, HMI shell, on board trainer shell for the there are several opportunities to implement engineering plant, or a data logging module. elements of the OA-MCS. New acquisition programs such as the large surface combatant (DDG 51 class future flight), the small surface . Table 1 FY 2011-2040 Long-Range Naval Vessel Construction Plan
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 12 DISTRIBUTION IS UNLIMITED
ONGOING EFFORTS complex network programming for distributed SUPPORTING AN OA-MCS applications. The key benefit to DDS is that communication for applications are entirely The Naval Enterprise has a set of innovative decoupled. Very little design time has to be practices that are maturing and are in a prime spent on how to handle their mutual interactions, state for the MCS community to join. Four new relieving one of the major complexities and initiatives are available to springboard the MCS program risks of MCS designs of the past.. DDS community forward. automatically handles all aspects of message delivery, without requiring any intervention The first is a set of Enterprise Objective from the user applications” (wikipedia: Data Architectures (e.g. PEO IWS’s Architecture Distribution Service). There is an open source Description Document (ADD), and PEO SUBs DDS and several vendors offer licensed and ADD) that could be replicated specific to MCSs. supported products with turn-key tools that These Architectures would prescribe a set of allow rapid and cost effective designs for consistent design patterns that will expand the systems that have real-time performance range of potential suppliers, increase characteristics and are widely used in the combat opportunities for innovation, and ensure system community. interoperability between an MCS family of systems for things like maintenance free The Open Architecture Product Line initiative is operating period practices and distance support specifically evolving a set of business and environments. technical practices for evolving strategic software reuse by purposefully building reusable There is a pair of evolving industry standards components that can be applied across multiple that would eliminate the typical vendor lock systems and platforms. Open Products Lines are prevalent in MCS designs of the past by using developed with embedded variation points that virtual PLC design practices. From can be configured to be applied to different PLCopen.org: “One of the core activities of instantiations for managing different needs PLCopen is focused around IEC 61131-3, the across similar systems. Open Product Lines only global standard for industrial control concepts are embodied by the use of Enterprise programming. It harmonizes the way people Objective Architectures, the using of open design and operate industrial controls by standards and programmatic strategic reuse. standardizing the programming interface. A standard programming interface allows people The unmanned air vehicle community has with different backgrounds and skills to create established an industry/Government consortium different elements of a program during different to evolve a set of real-time safety critical design stages of the software lifecycle: specification, practices that are ideally suited for the MCS design, implementation, testing, installation and domain. The Future Airborne Capability maintenance. Yet all pieces adhere to a common Environment (FACE) is a tri-service initiative to structure and work together harmoniously.“The standardize an open software environment that other standard is IEC 61499. This standard will reduce cost and speed of delivery for new prescribes a set of building blocks from which capabilities, encourage competition and the MCS application suite can be built. Between innovation, and enable software portability these two standards, the architecture and the across multiple airframes. The components of an open MCS can be developed industry/Government consortium is broken into that attends to almost all the technical attributes technical and business working groups. The of OA. technical working group is defining the standard, a tool set, test suite and associated FACE Real-time system development and network products. The business working group is design practices have radically changed over the developing a set of Government to industry past few years using the Real Time Data business models and performing outreach to Distribution Service (DDS) standard. “The DDS facilitate avionics developers to use the evolving publish-subscribe model virtually eliminates standard. The technical characteristics of a real-
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 13 DISTRIBUTION IS UNLIMITED
time personnel safety system for shipboard well as how to integrate the MCS design machinery control use and the associated into the overall ship design process characteristics for a real-time flight safety 5. Recommendations for how to system are nearly identical. The FACE effort incorporate the OA-MCS design into a could be a launching point from which the ship specification using available embedded controls and MCS communities could Military and Commercial Specifications. quickly leap ahead from the current practices to d. MCS community engagement in the an OA MCS business and technical NAVAIR/NAVSEA/SPAWAR Defense transformation. in Depth Architecture for Information Assurance. RECOMMENDED FUTURE e. Shift in program strategy to take EFFORTS advantage of other Navy acquisition programs for display devices and To implement the OA-MCS, the authors propose computing plant packaging. that the Navy fund the development and maintenance of the following Specification and The new specifications, standards, and design Standards: documents should include the minimum of a. New section to MIL-STD-1399 military requirements necessary for operation in providing MCS communication data a naval shipboard environment. Consideration message content protocols. This section should be given to creating "slant sheets" for would apply to all elements of the MCS, specific solutions to enable commonality across for communication between Smart ship types (as is currently practiced with Loads and the MCS, and for commonality shelf items). As technology communication with External and Off board Networks. It would not be evolves, obsolete slant sheets are deleted and directly applied to the interface between news ones added. The specifications should DAU/PLC and Equipment or Sensors. facilitate the economical acquisition of the b. Development of a MCS Community of component while preserving commonality Interest (CoI) data model, similar to the across ship types. ASW CoI data model effort as an alternative, or in conjunction with an The authors also propose that future MCS update to MIL-STD 1399. software development activity produce software c. Publish a MCS Objective Architecture configuration items that adhere to this general document, similar to the IWS/SUBS ADD as a NAVSEA Design Practice architecture and are designed for maximum re- and Criteria Manual providing a use across ship platforms. Software description of the OA-MCS architecture configuration items should be maintained in a including: shared environment such as the Navy’s SHARE 1. Recommendations for data repository for re-use across ship classes. communication methods to be applied in a Zonal Network The authors propose that the Naval Vessel Rules 2. Prescribe the use of a DDS method be updated to include the specifications and for a publish/subscribe information standards proposed for development. architecture. 3. Recommendations for protocols The authors propose that future ship acquisition between the DAU/PLC and equipment / sensors by using the IEC standards and modernization programs incorporate the 61161 and 61499 design process described in the proposed MIL- 4. Business models and programmatic HDBK or NAVSEA Design Practices and preferred practices for how to design an Criteria Manual. MCS using the OA-MCS elements as
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 14 DISTRIBUTION IS UNLIMITED
CONCLUSION Acquisition Research Symposium, May 12-13, 2010, Monterrey, CA. This paper has proposed a business and technical Naval Open Architecture Enterprise Team, "Naval approach to developing an Open Architecture Open Architecture Contract Guidebook for Machinery Control System common across all Program Managers," Version 2.0 of 30 June classes of ships. Once adopted this approach 2010. would provide an additional method to achieve commonality across the fleet while preserving Nguyen, Troy V., Wesley Epperly, Bruce Budinger, "A Survey of Existing Ship Machinery Control competition and a viable industrial base. This Systems and Suggested Improvement for Future commonality facilitates user training, improved Ship Platforms," ASNE Day 2010, April 8-9, maintenance, and regular software and hardware 2010, Arlington, VA. updates. Office of the Chief of Naval Operations (OPNAV), The technical approach includes a description of Report to Congress on Annual Long-Range Plan the open standards needed both within the for Construction of Naval Vessels for FY 2011, boundaries of the MCS and between the MCS Director, Warfare Integration (OPNAV N8F), and the user equipment. February 2010 The authors specifically recommend the Navy Open Systems Joint Task Force (OSJTF) “Open actively fund the development of the standards, Systems Defined – Terms and Definitions,” http://www.acq.osd.mil/osjtf/termsdef.html specifications, software, and infrastructure (page as viewed on 9 March 2011) needed to implement and sustain an open architecture machinery control system. Scherer, T. and Mclean, M., Leveraging Industrial Automation in US Navy Machinery Control REFERENCES Systems, , Proceedings of the ASNE Intelligent Ship Symposium VIII, May 2009 Amy, LCDR J.V. Jr, LCDR N. H. Doerry, LCDR T. J. McCoy, and Dr. E. L. Zivi, "Shipboard Controls of the Future", Naval Engineers Journal, May 1997. Dr. Norbert Doerry is the Technical Director of the NAVSEA SEA 05 Technology Office. He NAVSEA Commonality Program," Machinery retired in 2009 as a Captain in the U.S. Navy Control System Commonality Study" 2008 with 26 years of commissioned service, 23 years Boudreau, Michael, "Acoustic Rapid COTS as an Engineering Duty Officer. In his final Insertion: A Case Study in Spiral Development," billet, he served for nearly six years as the Naval Postgraduate School, 30 October 2006. Technical Director for Surface Ship Design. Dr Burns L., Guertin N., and Womble B., "Making Doerry is a 1983 graduate of the United States Choice Possible in the Acquisition of Machinery Naval Academy and a 1991 graduate of MIT. He Control Systems" ASNE Automation and is the 2008 recipient of the ASNE Gold Medal. Controls Symposium 2010, Aug 10-11, 2010, He is a member of ASNE, SNAME, IEEE and Milwaukee, WI. the Naval Institute and has published over 25 Doerry , CAPT Norbert H., "Systems Engineering technical papers. and Zonal Ship Design," presented at the ASNE Tim Scherer is the Branch Manager of the Engineering the Total Ship Symposium, ETS Automation and Control Research and 2006, May 1-2, 2006 Development Branch in the Research and Guertin, Nickolas and Paul Bruhns,, "Comparing Engineering Department of the Naval Surface Acquisition Strategies: Maintenance Free Warfare Center, Carderock Division, Operating Period vs. Traditional Logistics Philadelphia PA. His previous positions Support", Joint Undersea Warfare Technology include: Machinery Control System Life Cycle Conference, March 29-30, 2011. San Diego, CA. Manager, Machinery Control Systems Branch Guertin, Nickolas, and Paul Clements, "Comparing Manager, and Gas Turbine Electric Power Acquisition Strategies: Open Architecture vs. Systems Section Head. Product Lines," 2010 Naval Postgraduate School
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 15 DISTRIBUTION IS UNLIMITED
Jeff Cohen is the Branch Manager of the Machinery Control System Carriers and New Development Branch in the Machinery, Information Sensors and Control Division of the Naval Surface Warfare Center, Carderock Division, Philadelphia, PA. He is also the Life Cycle Manager for Naval surface ship Machinery Control Systems. He received a Masters of Sciences in Engineering Management from George Washington University, a Masters of Engineering from Widener University and a Bachelor of Science in Electrical Engineering from Rutgers, College of Engineering. He has over twenty five years of Naval engineering experience in machinery control systems in support of numerous ship classes. Mr. Cohen has held positions in the project management, design, development and test of Machinery Control System software and hardware.
Nickolas H. Guertin, P.E. received a BS in Mechanical Engineering from the University of Washington and a MBA from Bryant University. He is certified in Program Management and Engineering. Mr. Guertin worked at three NAVSEA field activities in the areas of nuclear propulsion plant testing, heavyweight torpedo depot engineering and sonar system development. Mr. Guertin’s experience in Open Architected system development spans fifteen years across sensor and weapon systems. Mr. Guertin is in the Program Executive Office for Integrated Warfare Systems and leads the transformation to change the business, technical, and cultural practices for how the Navy and Marine Corps buys and builds systems as a coordinated enterprise effort.
MAY 25, 2011 APPROVED FOR PUBLIC RELEASE; 16 DISTRIBUTION IS UNLIMITED