Mark Henry, Michael Iacovelli, Jeffrey Thatcher

DDG 1000 Engineering Control System (ECS) ABSTRACT The Navy’s advanced multi-mission 21st-century destroyer the USS ZUMWALT (DDG 1000) is well into the Detailed Design and Integration (DDI) and Detailed Design and Construction (DDC) phase. The highly advanced and integrated control system for the engineering plant, called the Engineering Control System (ECS), hierarchically supports the overall Ship Control System (SCS) to provide ship mobility and power to Combat Systems. Optimal manning objectives for DDG 1000 have driven ship system design to an unprecedented level of automation, and consequently the ECS is more complex than any other machinery control system ever developed for a Navy surface combatant. Software development is currently in detailed design phase while ECS hardware has progressed into production. This paper will explore the architecture and functionality of this distributed and hierarchical Engineering Control System that has emerged through years of evolution for Navy’s DDG 1000.

INTRODUCTION The DDG 1000 ZUMWALT-class destroyer is the US Navy’s next generation multi-mission surface combatant. The control system aboard these ships will be the most advanced that the U.S. Navy has developed and will incorporate advanced intelligence in order to achieve the optimal manning objectives of DDG 1000. The program is in various stages of design, development and production. This paper will focus primarily on the technical aspects of the Engineering Control System which is part of the overall Ship Control System; however, it will also address management and procurement strategies employed to produce this ship.

DDG 1000 PROGRAM OVERVIEW The DDG 1000 program can trace its origins back to the 1990s when a Cost and Operational Effectiveness Analysis (COEA) was performed, and operational requirements were developed. This activity culminated in a Mission Needs Statement (MNS) which resulted in a recommendation for a multi-mission surface combatant that could counter and adapt to the many different threats that it would encounter in the 21st Century. The first ship was to be called DD 21. The Operational Requirements Document (ORD) focused on land attack, reduced crewing, mobility and signature reduction. Two phases of Research & Development were completed, and, after a restructuring, the program was renamed DD(X) and the acquisition strategy changed. Instead of awarding a full service contract for the life of the class, the program embarked on Phase III in which the focus would be on system design and risk mitigation through the use of Engineering Development Models (EDMs). Two of these EDMs focused on Hull Mechanical & Electrical (HM&E) systems: the Integrated Power System (IPS) EDM and the Autonomic Fire Suppression System (AFSS) EDM. These EDMs were very successful and included the first incarnations of the DDG 1000 control system. The DD(X) Program held a successful system Critical Design Review (CDR) near the end of Phase III, and the program achieved Milestone B late in 2005. A contract was then awarded to Raytheon, the system integrator for Detailed Design and Integration (DDI) of the Mission Systems. The Mission Systems are depicted in Figure

1, and this included the Ship Control System (highlighted in red) which will be discussed

later in this paper.

Aco

ustic

Sen

se S

uite

Aco

ustic

Sen

se S

uite

Aco

ustic

Sen

se S

uite

Aco

ustic

Sen

se S

uite

Figure 1: DDG 1000 Mission Systems The DDI contract contains the effort to develop and produce all of the software for the DDG 1000 Total Ship Computing Environment (TSCE). Included in this effort is the software for the Engineering Control System and Damage Control Automation system. The ECS software contains the functionality for the supervisory control of the HM&E systems. This contract also included the efforts for the system integrator to develop the hardware to meet a Production Readiness Review. The acquisition of the ECS hardware was requested in the DDG 1000 Mission Systems Equipment contract which was also awarded to Raytheon.

The efforts to produce the local machinery control and embedded developmental software for the HM&E equipment and systems were included in the Detailed Design and Construction contracts. Northrop Grumman Ships Systems and General Dynamic’s Bath Iron Works received these contracts to build each of the first two hulls as part of a dual lead ship arrangement. This arrangement is being reconsidered; however. BIW is scheduled to deliver the first hull, the DDG 1000 in about mid FY 2013.

THE DDG 1000 SHIP CONTROL & ENGINEERING CONTROL SYSTEM ORGANIZATION Under DDI, the SCS Integrated Product Team (IPT) was formed. This team is comprised of the lead system integrator (Raytheon), its subcontractors, the shipbuilders and the Government. The SCS IPT is responsible for controlling the machinery products shown in red in Figure 1 previously referenced. The SCS IPT meets on a regular basis at various facilities and is chartered with developing the automation for the ‘Components’ in its purview: Engineering Control System (ECS), Damage Decision and Assessment (DDA), Integrated Bridge System (INB), Navigation System (NSC), and EO (electro-optical) Surveillance (ESV). It also includes the Ship Domain Controller (SDC) whose primary purpose is to receive tasking from the higher level Command and Control System and to translate this into directives to the Ship Control System. This paper is focused on the Engineering Control System. The ECS team is split between the hardware and software team. For hardware, Northrop Grumman Sperry Marine is a direct subcontractor to Raytheon. For ECS software, Lockheed Martin Maritime Systems & Sensors (LM MS2), Moorestown, NJ, is a direct subcontractor to Raytheon. While top level program management is performed by LM MS2, the ECS Integrated Product Team is led by Lockheed Martin Simulation, Training & Support (LM STS) in Orlando. There are three software “ensembles” under ECS: Integrated Power System Control (MIPS), Auxiliaries Control (MACS), and Automated Damage Control (MADC). The functionality of these will be reviewed in depth later. LM STS leads MADC and has enlisted LM MS2 Baltimore to assist in the development. LM STS is also responsible

for the overall integration of the ECS software, and has recently been awarded tasking to develop the screens for the ECS Human Computer Interface (HCI). For MIPS and MACS, LM has subcontracted to Northrop Grumman Sperry Marine, who in turn has subcontracted MIPS to Converteam. Converteam is also a direct subcontractor to Northrop Grumman Shipbuilding (NGSB) under the DD&C contract to design and develop the high voltage portion of the DDG 1000 Integrated Power System. Utilizing Coverteam to develop the IPS supervisory control system is advantageous due to its main role as IPS developer. Each of these areas will be discussed in full detail in the next few sections. ARCHITECTURE OVERVIEW There are a number of ‘domains’ that provide a logical decomposition of the highest level ship operational specifications flowing from the ORD. These domains are a breakout related functions that are grouped together into focus areas. For example the Ship Segment is broken down into Structural Systems, Integrated Power Systems, Auxiliary Systems, Ship Control Systems, elements and more. These elements are defined as a set of element level hardware and software requirements that are further grouped and decomposed into to manageable pieces. This breakout is known as the Contractor Work Breakdown Structure, or CWBS. The focus of this paper will be the machinery controls automation of the ECS component in the Ship Control System element that is designed to meet DDG 1000 manning requirements in the ORD. For software, the CWBS decomposes segments into elements, which are further decomposed into components then ensembles. However, to fully understand ECS control capabilities some specific functional

dependencies in domains outside of the Ship Segment also have to be considered. In the hierarchy of the automation on DDG 1000, top level commands for control flows from the software in the Command, Control and Intelligence (CCI) Element into the SCS Element across segments. In addition, DDG 1000 Human Computer Interface (HCI) resides in the Human Interface Infrastructure (HII) element (in the Total Ship Computing Environment Infrastructure (TSCE-I) System Segment) and provides human interface with many applications including CCI, SCS. It is worth noting at this point that the hierarchy of the software functionality is different from that of the CWBS. There are additional examples of this type of cross domain interfacing that will be discussed further as needed in this paper. SOFTWARE HIERARCHY The level of abstraction of the interface between CCI and SDC, then ultimately SDC and ECS is aligned with the capability inherent to each level in the hierarchy. Command and Control will define ship needs at a mission level via an Integrated Ship Plan (ISP) which then results in sets of tasks being sent to each of the Ship’s domains. The Ship’s domain controllers have a more detailed knowledge of the components within their domain and therefore generate subsequent directives to its lower level software components that are more detailed and refined in order to initiate appropriate predefined behavior. In Ship Controls these directives are received by the ECS ensembles where they are further decomposed into I/O (analog, discrete, and serial) control and monitoring activities across all the HM&E systems under ECS control. When the ECS directives are being

received from SDC, ECS is in automatic mode and, when the directives are coming from HCI, ECS is in remote manual mode. There are a number of systems under ECS with embedded controllers that are integral to the equipment and assemblies provided under Shipbuilder procurement specifications which respond to commands from ECS. The complexity and capability at the equipment level varies, but in some cases are very sophisticated (e.g. generator real and reactive load sharing, gas turbine engine control, equipment and system self protection/safety functionality, etc.). CCI uses rolled-up, or aggregated, status from the Mission Readiness Element (within the Support Systems Segment), human inputs, and other data from key domains to develop the ISP. The ISP defines the Ship’s mission and schedules events from approved planned maintenance to transitions of the operating profile of the ship as a whole. An example of a Ship’s profile transition is changing from moored pier-side to underway/restricted maneuvers. CCI then maps the ISP to tasks that are directed to individual domains as appropriate for action. Information from CCI in the form of tasking is received by the SDC which performs multiple functions. SDC functions include prioritizing tasks that may be in conflict or cannot be performed concurrently and also decomposes high level Ship’s activities. SDC then provides specific system states limitations and/or exceptions, providing indication of anticipated demands and/or loads on the HM&E systems that are necessary for successful execution of Ship’s mission. Figure 2 graphically shows interfaces for the flow of directives and status.

Figure 2: DDG 1000 Control Hierarchy TOTAL SHIP COMPUTING ENVIRONMENT DDG 1000 implements a TSCE to minimize integration effort and take advantage of common patterns across a number of domains. The TSCE has three tiers: Core, Adaptation, and Presentation. The Core Tier provides a common environment hosting the majority of the DDG 1000 software applications on a redundant infrastructure whose targeted hardware location is designed to be transparent to the applications. The Core Tier processors are IBM blade servers running with Red Hat Linux operating system that are housed in electronic modules that are distributed in a number of places on the ship. The Presentation Tier is that part of the TSCE

responsible for rendering displays on the consoles. The Adaptation Tier utilizes much more compact hardware to provide a means to integrate software into the TSCE, but the processor may be located in any suitable enclosure and location. The Adaptation tier for ECS utilizes paired Radstone single board computers (SBC) and General Microsystems SBCs in a Versa Module Eurocard (VME) chassis, which are referred to as Ensemble Controllers (ECs). The Radstone SBC’s run Lynx Operating System (LynxOS), i.e. UNIX, and use Java and/or C++ code applications which perform control and interface to other applications running in the TSCE infrastructure and are referred to as Distributed Adaptation Processors (DAPs). The General

Microsystems SBC in the ECS pair is running Microsoft Windows with a real-time kernel and Siemens Simatic WinAC RTX Soft PLC application and Ladder Logic to control and drive the remotely located I/O chassis known as remote Terminal Units (RTUs) that interface to the engineering plant equipment. ECS utilizes 32 Adaptation Tier processors in its architecture to allow the ensembles software to be located in close proximity to the systems that they control. ECS DISTRIBUTED SOFTWARE AND CAPABILITIES ECS applications reside on 16 Distributed Control Units (DCUs) located throughout the ship. Within the 16 DCUs are 32 ECs where the ECS control code reside. The ECs use DAPs to interface with other applications using TSCE partial mesh Gigabit network, and have the added capability of running independently of the other applications in the TSCE Core

(manual mode interfacing directly to the HCI). Core independent operation of ECS and HCI provides the capability for system recovery during degraded operation that may be the result of extended power outages, or equipment casualties. The second General Microsystems SBC in the EC running the Siemens Simatic WinAC RTX Soft PLC communicates with other DCUs and the RTUs via Profinet (Ethernet standard of Profibus & Profinet International) protocol. There are 180 RTUs remotely located in very close proximity to the hardware with which they interface. The DCUs and RTUs are connected across Fire Zones using the ship wide Profinet Network (known as the ECS Network) for DCU to DCU and DCU to RTU communications needed for active/standby processor failover, monitoring, and control of engineering plant equipment and systems. Figure 3 shows the distributed nature of the ECS system. The ECS control hardware and capabilities will be discussed in more detail later.

Figure 3: DDG 1000 Distributed Machinery Control

The DDG 1000 engineering plant is comprised of the most automated systems and equipment that the Navy has ever attempted to design and build. The majority of the equipment and system automation utilizes embedded controls with digital interfaces that use common network and Fieldbus protocols. There are over 80,000 signals that can be used for monitor and control; however it was determined through a rigorous systems engineering process, that only approximately 30,000 of these signals need to be utilized by ECS. In contrast, current fielded state of the art Navy machinery control systems generally utilize between 4,000 to 10,000 signals. These signals are required to achieve the manning levels necessary for DDG 1000. Requirements for DDG 1000 stipulate that, after initial system alignment, the level of ECS automation provides the ability for a single operator to coordinate the entire engineering plant during normal operations spanning all ship level missions without the need for manual intervention at the machinery level. However during equipment casualties or damage events it is anticipated that at least one other operator will be involved with control of key systems, and the transfer of control of systems is a capability of ECS. If available through a equipment remote monitoring and control interface, ECS provides ‘drill-down’ capabilities to individual pieces of equipment, or sensors. This ability to see data at the lowest levels is provided to the operator as optional information as needed. The operator also has the ability to take remote control and send directives directly to ECS (see HCI interface in Figure 2.) This also supports the maintenance concepts, and the operator has the ability to override automation should it be deemed necessary. All the data is available to the operator and it can be provided to other applications such as Condition Based Maintenance (CBM) which can automatically identify and schedule maintenance actions.

The MIPS ensembles reside on 4 DAPs (2 active, and 2 redundant standby processors) located in proximity to the main forward and aft power generation enclaves on the ship. The majority of the ECS equipment and subsystem interfaces for IPS use Virtual Local Area Networks (VLANs) using the TSCE network infrastructure. The VLAN communications protocols used by the MIPS ensemble are Ethernet Global data (EGD, MODBUS TCP, and OpenSea. In addition to monitoring the power plant equipment, the IPS control ensemble of ECS (MIPS) performs Power Management. Power Management is a generic name for functionality that integrates the high and low voltage power systems with the electric propulsion motors and manages power and loads to support ship activities. These activities are decomposed by SDC and provided to ECS as directives. MIPS coordinates sequences for system alignments, performs starts and stops of equipment, sequences and manages system recovery activities, and performs system reconfigurations in an automated fashion based on these directives. MIPS manages plant power by computing power availability and consumption in zones that are dictated by system alignment called ‘power centers.’ The ‘Power Accounting’ feature of MIPS is used to then further define how loads are fed from power sources (generators and/or power converters/inverters), to connect and disconnect loads based on priorities, to add power generation as needed, and to communicate to other ECS ensembles and domains outside of ship to coordinate power usage. The Auxiliary Control Ensembles (MACS) reside on 16 DAPs (8 active, and 8 redundant standby processors) located in a number of locations in proximity to the several machinery spaces where auxiliary equipment is located. Auxiliary systems include cooling water, fuel oil, water production, drainage, etc. In addition to

monitoring the Auxiliary Equipment, MACS performs system management. Although not nearly as sophisticated as managing the power plant, the MACS coordinates sequences for system alignments, performs starts and stops of equipment, sequences and manages system activities, and performs system reconfigurations in an automated fashion based on directives, including directives from the IPS and ADC ensemble. The Automated Damage Control Ensembles (MADC) reside on 12 DAPs (6 active, and 6 redundant standby processors) located in a number of locations in proximity to the several machinery spaces where Damage Control equipment is located. DC systems include seawater water (for ballast and de-water activities), Aqueous Film forming Foam (AFFF), High Pressure Water-mist, etc. For the most part MADC monitors the DC equipment that has local activation, but MADC also provides remote control capabilities in certain cases. MADC works with MACS to coordinates sequences for system alignment performs starts and stops of equipment, and system reconfigurations in an automated fashion required to support use of DC systems that are fed from auxiliary systems. EMBEDDED CONTROLS At the equipment level there are several sets of embedded controls that operate specific equipment and in some cases subsystems. For example, the high voltage switchboards have controllers that interface with the power generators. These controllers perform sequential steps to place generators on and offline, balance both real and reactive loads when generators are operating in parallel, and provide information needed for Power Management. Other examples of embedded subsystem controls include Programmable Logic Controllers (PLCs) for fire-main pumps and valves, PLC control of Emergency diesel Generator and support systems, and more.

HARDWARE The ECS is a real time distributed control system that permits automated monitoring and control of the DDG 1000 engineering plant. ECS utilizes networked Distributed Control Units (DCUs) and Remote Terminal Units (RTUs) that interface with the shipboard HM&E equipment for the monitoring and control of sensors, actuators, contactors, power equipment and more. The ECS is using a marriage of TSCE infrastructure hardware and commercial technology that has been widely used in manufacturing from oil refineries to water purification to automobile production, throughout the world for many years. With the exception of enclosure designs to meet strict environmental requirements, unmodified Commercial Off the Shelf (COTS) products and devices are being used in the ECS hardware just as though DDG 1000 engineering plant were a collection of equipment on a factory floor of a typical industrial plant. Survivability requirements for SCS mandate that the control system needs to be fully redundant with robust fail over capability for the command status of the Ships capability and health and the safety of its crew. The DCU units serve as the main processing component that is networked and interfaces to the ship’s main TSCEI network, controls and executes the ships software ensembles and will monitor and control the propulsion, auxiliary, electrical, and damage controls systems using closed loop control, predefined sequences and other control algorithms. The RTUs serve as the interface point to embedded controllers and a variety of analog and digital inputs and outputs. A single DCU contains two pair of Radstone and General Microsystems SBCs in a Versa Module Eurocard chassis. The Radstone SBC’s run applications in Lynx Operating System (LynxOS) to interface to the ships main TSCE via dual 1000 Megabits per second (Mbs) fiber optic Ethernet network

connections. As previously mentioned, this processor pair is known as an Ensemble Controller (EC). The DAP runs its application code and utilizes the TSCEI services developed for DDG 1000 for a number of functions such as transport mechanisms, database features, and more. The General Micro Systems (GMS) Windows based SBC executes Siemens Simatic WinAC RTX Soft PLC application. The Soft PLC application with a third party real time kernel provides monitoring and control of the ships systems with a configurable scan time. The DAP transmits commands to the Soft PLC processor via direct interface, and the same interface is used to communicate the Ships equipment and device status from the SoftPLC to the DAP. Each instance of an ensemble resides on two ECs providing redundancy - one operates in active and the other standby mode. The active and standby pairs are physically located in separate DCUs spread across Fire

Zones to increase for survivability. The active and standby Soft PLCs monitor each other via a Profinet Network and will automatically failover if the active unit fails or detects a fault. DCU ARRANGEMENT AND ECS NETWORK There are 16 DCUs distributed throughout the ship that use a Siemens based Profinet architecture. There are 4 DCUs in each of the 4 fire-zones on the ship (Figure 4), DCUs 1 and 2 are in fire-zone 1, DCUs 3 and 4 are in fire-zone 2, etc. Each DCU contains three Siemens Scalence X408-2 switches. The X408-2s provide ports for the 1000 Mbs fiber optic Profinet ‘managed ring’ network that connects all of the DCUs together, see Figure 4. The X408-2 switch also provides the network interface for the SoftPLC.

Figure 4: DDG 1000 DCU Interconnections

Each DCU physically connects to 3 or 4 other DCUs using the X408-2 switches and also provides the network interface for the Siemens Scalence X202-2IRT switches that

are used to interface with the redundant 100 Mbs fiber optic RTU networks, see Figure 5. The combined DCU and RTU network is referred to as the ECS network. The

Siemens Scalence switches used in the ECS network permit the configuration of switched networks at the switch level, which provides high availability of the network and extensive diagnostic options, high transfer rate and support of fiber optic and copper interface. The ECS network contains several ‘managed ring’ Ethernet network interfaces consisting of active and stand-by communication links (to ensure an active Ethernet ring is avoided). The active links

are solid line and the standby links are dashed lines in Figure 5. The managed ring approach keeps one section of the ring designated as inactive and automatically activates it (deactivating the other side) under 300ms upon any failure or fault on the active ring. Although the ring topology is not as robust as a mesh, this outperforms Spanning Tree algorithms that would have to be used with a mesh.

DCU 1A

DCU 1BDCU 2B

DCU 2AECS

NetworkTo Fire Zone 2

Fire Zone 1

RTU Network LinkRTU (qty varies)

Figure 5: DDG 1000 RTU Interconnections

There are 180 RTUs located throughout the ship. Each RTU connects to the HM&E equipment both through standard digital and analog modules and through serial Fieldbus/communication gateways. The RTUs also contain COTS Siemens network switches, interface modules and PLC functionality, slice I/O modules and terminal boards. The RTUs contain a single Siemens Scalence X204-2 network switch to communicate to SoftPLC part of the ECS ensembles in a DCU. The X204-2 has four RJ45 Ethernet ports and two fiber-optic ports. The dual fiber optic ports communicate to the DCU’s via the 100 Mbs RTU network. The communication between the DCUs and RTUs is based on the Profinet CBA protocol. Profinet CBA consists of

component-based communication via TCP/IP and real time communication with components. Profinet CBA enables an entire automation system to be divided into autonomously operating subsystems, grouping the interface data by subsystem and making the data available to any application on the network. Due to restrictions in the Profinet CBA, only 64 Profinet CBA connections can be made to each controller. This results in a limit of eight software ensembles connecting to any one RTU.

RTU INTERFACE WITH ENGINEERING PLANT EQUIPMENT

Within the RTU the Siemens CPU interface module, IM151-8, Slice I/O, and Serial Gateways provide monitoring and control between the ships HM&E systems and the DCUs Soft PLC ensembles. The IM151-8 interface module transmits and receives data from the Slice I/O and Serial Gateways to provide I/O status information for the DCU SoftPLC ensembles to coordinate the monitoring and closed loop control of the HM&E equipment. The IM151-8 contains failover ladder logic code to collect and transmit data to a DCU ensemble or its DCU stand by. Analog and Digital I/O from the Slice modules and the Serial Gateways communicate to the IM151-8 to interface with the ship systems equipment that are close in proximity to a particular RTU. The RTUs communicate data to the appropriate DCUs and their ensembles all throughout the ship. There is distinctive ladder logic code for each IM151-8 interface module in each of the RTUs. This is programmed with the Siemens Step 7 development software. The software code in the RTU contains configuration data used to initialize the I/O modules and Serial Gateways. The RTUs contain common I/O modules in a Slice form factor and several different types of Serial Gateways to interface and communicate with the HM&E equipment. The gateway modules interface to equipment such as networked sensors, individual smart components, and system/equipment local controllers. ZONAL FIELDBUS The Serial Gateways interface to HM&E equipment using a limited number of Fieldbus protocols. This collection of Fieldbus interfaces are referred to as the Zonal Field Bus (ZFB). To minimize cost, improve configuration management, and for life cycle support, there are just five different types of Fieldbus protocols on

DDG 1000: Profibus DP (over copper), Ethernet Industrial Protocol (EthernetIP), ControlNet, Modbus and LonWorks. Through an extensive trade study, these field buses were determined to be the most commonly used field buses in industry and would satisfy the needs of the HM&E equipment. The future of the DDG 1000 program depends on an open architecture, future stability of equipment and standard COTS hardware to enable the entire program maintain state of the art throughout its lifecycle while keeping costs down by using industrial automation architecture. Because these Fieldbus types were selected before Detail Design, the Shipbuilders and their vendors have been able to design or adapt their legacy equipment with one of these standard field buses. CONCLUSION The Navy’s advanced multi-mission 21st-century destroyer, DDG 1000, will be the first platform to include the most advanced ECS the Navy has ever fielded. This highly advanced and integrated control system for the engineering plant will provide automation to power and control auxiliary systems, support ship mobility and Combat Systems. Optimal manning objectives have resulted in an unprecedented level of automation, and complexity for the ECS that exceeds any other machinery control system ever developed for a Navy surface combatant. Through the continued dedication of shipbuilder, integrator and government personnel, the DDG 1000 program is positioned to possess a robust, highly automated control system. REFERENCES The ‘DDG 1000 Program Engineering Control System (CECS) Component Architecture Description Document (CADD)’, prepared by Northrop Grumman Corporation, Sperry Marine for Lockheed Martin Maritime Systems & Sensors.

ACKNOWLEDGEMENTS Thanks to Northrop Grumman Shipbuilders, and Bath Iron Works for designing the engineering plant systems and defining how those systems work. Both of these shipbuilders worked feverously to coordinate their designs and schedules with the Ship Controls Software developers from Raytheon and Lockheed Martin, and provide documentation to support software design. Thanks to the System Integrator team of Raytheon Integrated Defense System and Lockheed Martin who have provided leadership and technical guidance to the Ship Control System Integrated Product Team. Raytheon, Lockheed Martin, Northrop Grumman Sperry Marine, and Converteam are all providing new and reused software that constitutes the ECS piece of Ship Controls Software. The complexity of DDG 1000 machinery under ECS control combined with the tight timeline for the development of a very complex and integrated control system has been significantly challenging. Without the strong teaming relationship between these groups this project would not be in detailed design as it is today. Finally, the authors wish to acknowledge Program Executive Office, SHIPS, specifically PMS 500, and NAVSEA 05 for providing programmatic guidance and extensive support for the DDG 1000 Navy Technical Team. Through the dedication of this team of people, the DDG 1000 will become the best destroyer ever built. ____________________________________ Mark Henry Mark Henry graduated with honors, receiving a BSME from Temple University in 1990. Since that time he has been employed by Naval Surface Warfare Center

Carderock Division, Ship Systems Engineering Station (NSWCCD-SSES). Since employment he has worked with a number of different Hull Mechanical and Equipment (HM&E) systems in variety of roles from concept through design and installation of equipment on active ships, till today when he is working on design for new construction on the US Navy’s DDG 1000 Engineering Control System (ECS). Currently he serves as a government contractual and technical representative for the development of the ECS with focus on the Integrated Power System (IPS) controls overseeing machinery control system development for DDG 1000 class destroyer. Mark Henry is reached at mark.j.hernry@navy.mil Michael Iacovelli, P.E. Michael Iacovelli graduated from the University of Delaware with a BS in Mechanical Engineering and later received a MSME from Drexel University and his Professional Engineering License. Mr. Iacovelli started at what is now the Naval Surface Warfare Center Carderock Division, Ship Systems Engineering Station (NSWCCD-SSES) as an engineer in the Machinery Information, Sensors and Control Systems Department. While in that department, Mr. Iacovelli worked and sailed on numerous classes of ships including DDG-51, AOE-6, LHD-1, CG-47 and MCM-1 and worked on numerous in house programs. Mr. Iacovelli moved into the Programs and Platforms Department where he became the US Navy’s DDG 1000 Ship Systems Controls & Automation Systems Engineering Systems Engineering Manager. Mr. Iacovelli has recently transitioned to the role of Machinery Controls Branch Manager where he oversees machinery control system development for a number of ship classes including the DDG 1000, LPD 17 and Littoral Combat Ship (LCS). Michael Iacovelli is reached at michael.iacovelli@navy.mil

Jeff Thatcher Jeffrey Thatcher graduated from Temple University in 1989 with a Bachelors of Science in Electrical Engineering Technology. In the past two years he has been employed by Naval Surface Warfare Center Carderock Division, Ship Systems Engineering Station (NSWCCD-SSES). He is currently working on design for new construction on the US Navy's DDG 1000 Engineering Control System (ECS) with a central focus of ECS Hardware and Shipyard ECS Interface of Embedded Controls. His previous employment was in the Semiconductor and Telecommunications industry. Mr. Thatcher was the Electrical Engineering Manager for Denton Vacuum LLC and responsible for future development and integration of the digital and analog control systems for all OEM equipment. He has a vast knowledge of Automation Controls and has experience with multiple Programmable Logic Control systems, Human Machine Interface platforms and Data Acquisition software. Jeff Thatcher is reached at jeffrey.thatcher@navy.mil