Scherer-Evolution-ASNE-2011[1].pdf

The Evolution of Machinery ControlSystems Support At the Naval ShipSystems Engineering Station& Timothy Scherer and Jeffrey Cohen

Naval Ship Systems Engineering Station

IntroductionMachinery Control Systems (MCS) have evolved

rapidly with the development of smaller and

more powerful computational and display

technologies. Over the past three decades

machinery controls have moved from

hardware-based logic to software-based logic.

The use of relays, push buttons and light-bulbs

has been replaced by processors, graphical user

interfaces, keyboards and track balls. Suppliers

have also evolved from using basic circuit

cards and military-specified processors running

machine language to Commercial Off The Shelf

(COTS) processors running high level languages

like C11 and JAVA. Networks provide

communication using industry standard

protocols. These changes have driven changes

in acquisition philosophy, life cycle support,

training, and modernization programs.

The Naval Surface Warfare Center, Ship Systems

Engineering Station (NAVSSES), has evolved

into a center of excellence for machinery

control and machinery control systems. Tracing

technical roots back to the advent of boiler

controls and later gas turbine control systems,

MCS personnel have provided support to nearly

every Navy surface ship. Since 1996, NAVSSES

has been developing new machinery control

systems for back fit on US Navy, US Coast

Guard and Foreign Military ships. See Figure 1

for a list of ship classes that NAVSSES is

providing MCS support.

While software and hardware designs have

evolved through the years, the technical

approach and current designs for modernizations

are based largely on successfully completed

systems. Each new control system uses lessons

learned from each of the previous programs.

This paper will discuss the support that

NAVSSES has provided the fleet using a

historical perspective to show how MCS support

evolved. While the organization provides steam

control systems and fluid systems automation

as well as networks and bridge control systems,

this paper focuses on the MCS product line.

A discussion of the early support for gas turbine

programs and their associated control systems

will be presented to provide a perspective on

how those programs influenced the current MCS

organization. The progression of support from

early programs through in-service engineering

to leading modernization programs will be

addressed throughout this paper.

What ConstitutesAMachinery ControlSystem?On U.S. Navy ships, the MCS provides

supervisory control and monitoring of machinery

systems, including: the propulsion plant, electric

& 2011, American Society of Naval Engineers

DOI: 10.1111/j.1559-3584.2011.00321.x

2011 #2&85

power plant, auxiliary systems, and damage

control systems. Looking across the fleet MCS

controls and monitors 86 shipboard systems (see

Figure 2). The MCS controls and monitors

designated systems throughout the ship, including

control of the propulsion plant from the bridge.

The system also provides bell and logging.

The MCS is comprised of hardware and software,

including the user interfaces, required to enable

monitoring and control of the machinery plant. On

older, legacy designs the MCS is centralized with

all of the required plant information connected via

cable to a central location and connected to the

appropriate consoles by functionality (propulsion,

electric power, auxiliaries, fuel control, damage

control, ballast control, etc.).

Most current machinery control systems are

distributed with the capability to control the

Figure 1: NAVSSES MCS Support

Figure 2: MCS Controlled/MonitoredShipboard Systems

NAVAL ENGINEERS JOURNAL86 & 2011 #2

The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station

ship’s machinery systems from numerous

workstations throughout the ship. The

distributed control system relies on a network to

allow communication between workstations,

control equipment, and controlled/monitored

devices. Figure 3 is a diagram of a notional

distributed control system showing the

interconnection of devices on the network. The

figure shows a core, mesh network with

control layer devices and information layer

workstations connected to it.

CAPT J. Preisel, USN (ret.), the first and former

DDG 51 Program Manager at NAVSSES,

describes how the machinery control system

scheme is implemented for the propulsion

system on a gas turbine ship:

‘‘In each of these systems, a similar scheme for

propulsion control exists: Propulsion control

(thrust control) is maintained at three

hierarchical levels: on the bridge, in a central

control station, and locally in each main

machinery space. Overall communications for

control and monitoring must be maintained among

the three levels of control. The safety-related

control loop (i.e. the engine inner loop control)

resides locally with the prime mover.’’

TheNAVSSESRole inMCSNAVSSES is responsible to provide the Life

Cycle Management (LCM), In-Service

Engineering (ISE), Software Support and

Research and Development (R&D) for

machinery control systems. Dating back to at

least 1973, NAVSSES, then known as NAVSEC

PHILADIV, had a Controls Application Branch in

the former Machinery Automation Systems

Department. Since that time there have been

numerous organizational structures, but the

control systems group was established as a

necessary organization to meet an increasing need

in the area of Naval automation and control.

That initial automation group has grown to five

MCS In-Service Engineering (ISE) Branches and

Figure 3: Notional Architecture of a Ship’s Distributed Machinery Control System

NAVAL ENGINEERS JOURNAL 2011 #2&87


one Research and Development (R&D) Branch.

These branches address the MCS life cycle.

There are five main life cycle areas of MCS

responsibility at NAVSSES:

�R&D

�Acquisition Support

� ISE/Software Support

�Technical Warrant Holder support

�Modernization Solutions

Research and Development

The R&D role is to work closely with ONR,

Program Managers and the Life Cycle

Managers/In-Service Engineers to complete the

bridge between the science and technology

(S&T) and the acquisition communities.

Another aspect of the R&D responsibility is

to establish the necessary resources and

perform the research and development of novel

survivable automation and control concepts for

network architectures, hardware, and software,

as well as the advanced sensors, actuators and

controllers necessary to support future Navy

missions. Figure 4 illustrates the flow of

technology and requirements through the system

life cycle.

Acquisition Support

The Acquisition Support role provides for

the review of new construction MCS from

requirements through design to testing and

delivery. The NAVSSES role also includes

testing or independent review of vendor

software (e.g. Factory Acceptance Testing or

Land Based Engineering Site testing) as

well as production and trial support. Support

is typically provided to the Ship Design

Managers and the Program Executive

Offices at the Naval Sea Systems Command

(NAVSEA).

In-Service Engineering (ISE) Support

ISE Support occurs primarily after the ship has

been transferred to Navy custody. At this point

there is a transition of responsibility for the MCS

hardware and software from the shipbuilder/

integrator/manufacturer to the In-Service

Engineering Agent (ISEA). The ISEA provides

engineering support to the fleet, including

engineering improvements, troubleshooting

fleet problems, providing software support of

the original software, ensuring accuracy of

logistics support documentation, and providing

training to fleet personnel. In many cases a

laboratory is established and for developing,

testing, and maintaining software changes as

well as hardware improvements.

Modernization Solutions

Modernization support has meant the design,

development, test, installation and logistics

support of a turnkey replacement system.

The new MCS typically resolves obsolescence

and supportability issues as well as improving

user interfaces and reducing workload

through automation. Software is designed

and developed by the Navy which eliminates

licensing fees and improves total ownership

cost through re-use and commonality.

Technical Warrant Holder (TWH) Support

Generally, this support is for developing or

reviewing standards, specifications and rules,

(e.g. Naval Vessel Rules), supporting major

initiatives such as commonality and open

architecture, developing system certification

requirements and performing certification

testing, and providing information on an as

needed basis for fleet problems.

FLEETNSWCLCM

NSWCR&DAgent

ONR

Warfighter Technology Needs

Technology DevelopmentTechnology TransitionFigure 4: Technology and RequirementsFlows in System Life Cycle Activities



ABrief HistoryOf TheNavy’s GasTurbineProgramand its Impact OnMachineryControl SystemTestingMuch of the current Navy’s roots for distributed

machinery control system expertise are found in

the development and testing of gas turbine

systems. The Navy conducted in-house studies in

the late 1930’s to determine if gas turbine

engines could be used for marine propulsion.

In 1940 the Bureau of Ships (now NAVSEA)

published a report including recommendations

to establish a naval gas turbine program. A

program was established and a contract was

awarded in December 1940 for the development

of a gas turbine plant. This plant was tested at

the US Naval Engineering Experiment Station

(USNEES) in Annapolis, MD, starting in 1944.

USNEES would later become part of the David

Taylor Research Center and be subsequently

merged with NAVSSES in Philadelphia as a

result of the Base Realignment and Closure

Commission.

During the same time period, the Navy Boiler and

Turbine Laboratory (NBTL), which later evolved

into NAVSSES, was established in 1941 to provide

the US Navy with the capability to test boilers,

steam turbines, and associated auxiliary systems.

In the 1950s a Combined Steam and Gas Turbine

propulsion system test was conducted at NBTL.

NBTL had developed expertise and experience in

steam turbines and propulsion systems, and the

Navy took advantage of this expertise for testing

the first full scale gas turbine plant. A control

console was used for initial gas turbine control

and monitoring (Carleton and Weinert).

As the Navy’s gas turbine programs continued to

grow, NBTL expertise in these programs grew as

well. The result was that NAVSSES became the

primary location for gas turbine testing for the

Navy. Once the Navy had committed to using

the gas turbine engine in the propulsion plant,

NAVSSES conducted propulsion plant machin-

ery performance testing, endurance testing and

integration testing. The control systems for the

engine and propulsion plant were integral to

these tests.

The first major gas turbine ship testing occurred

on the DD 963 Land Based Test Site (LBTS)

at NAVSSES in 1973. The purpose of this

testing was to evaluate system integration,

performance, control characteristics, and

shipboard applicability. Included in this testing

was a propulsion control system that provided

program control of the shaft’s speed. Testing

identified problems in both the Propulsion

Control System and the Integrated Throttle

Control. (Nufrio and McNamara) The

nomenclature for the DD 963 machinery control

system was the Engineering Control and

Surveillance System (ECSS). The ECSS

contained:

�Propulsion and Machinery Control Equipment

�Electric Plant Control Equipment

�Propulsion and Machinery Information System

Equipment

�Propulsion Local Operating Equipment

Much of these systems were hard wired with

significant signal conditioning. Some signals and

information were communicated via serial data

buses. A centralized digital computer with an

embedded computer program processed the

information from signal conditioners and the

serial buses. Engineers and technicians who were

experienced in electronics were the primary

support for support for this system. Figure 5

provides a diagram of the ECSS.

FFG7LandBasedTest SiteThe next major ship class testing was

accomplished at the FFG 7 LBTS in 1975. The

purpose of this test was similar to the testing

on the DD 963 class LBTS and included the

FFG 7 gas turbine’s Free Standing Electronic

Enclosure (FSEE), which provided local control

of the engine. The necessary hardware for the

machinery control system was also included.

The testing of the system identified numerous

control system issues, including integration

issues. One such integration issue that was

resolved was communication problems between

the FSEE and the machinery control system.

Other control system problems that were



identified included: control system operation

issues due to electromagnetic interference, set

point problems, software design problems, and

grounding problems. Integration testing would

continue to expand with the control systems’

increased complexity and become a major

reason for testing in subsequent shipboard

systems.

Other systems testing that followed the testing of

the FFG 7 propulsion system were the Rankine

Cycle Energy Recovery (RACER) system from

1984 to 1986, and the Reversible Converter

Coupling (RCC), which was eventually used on

the AOE 6 class. The FFG 7 LBTS was modified

to test the RCC upon completion of the FFG 7

propulsion system testing. During this time

frame the CG 47 class was introduced into the

Navy. With a propulsion plant similar to the DD

963 class, there was no large scale land based

testing conducted on the CG 47 machinery

control system or on propulsion system

integration.

The next major gas turbine propulsion

combatant was the DDG 51 class. Due to the

issues found and resolved during previous gas

turbine tests, there was a demonstrated need for

another Land Based test Site to support this

ship class. Additionally, there were significant

differences in the control system equipment

that warranted a land-based integration and

test program which preceded shipboard

integration.

DDG51and the Introductionof SoftwareSupportThe DDG 51 MCS had numerous attributes

that differed from previous machinery control

systems. It was a significant step forward from

previous designs, transitioning engineering plant

control from analog to digital. It was also more

advanced in the areas of distributed processing

and software based control. Each console has a

standalone computer based upon a military

standard. A text based computer interface was

used to display alarms and indicators that were

now stored in software. A data multiplexing

System (DMS) enables communication between

the MCS consoles. Figure 6 provides a one line

diagram of the system.

A software based control system offered

numerous advantages over the previous

hardware-centric control systems. A software

based system allows parameters and set points to

Figure 5: Diagram of the DD 963 classEngineering Control and SurveillanceSystem



be changed more easily through changes

in the computer program or user entry into a

user-defined field. Significantly more

information is available to the user.

The DDG 51 Land Based Engineering Site

(LBES) was built to test the propulsion

plant, the electric plant, MCS and DMS well in

advance of the delivery of the ship. A primary

purpose of the LBES was to provide integration

testing of the propulsion system, including the

control system, to allow for finding and

resolving problems with the propulsion plant

before going to sea.

In 1988 testing began on the DDG 51 Land

Based Engineering Site. Testing objectives for the

MCS included:

�Wiring checks

�Alarms at design set points

�Data transfer

�Data displays

�Control circuits

�Propulsion Control Transfer

� Safety circuits and permissives

�Modes of Operation

�No-break Power Supplies

�Ground detection circuitry

�DMS interfaces/communication

All of these areas were to be tested statically and

dynamically with the hot plant.

During the initial testing only the main propul-

sion consoles were installed on the LBES. The

missing consoles were simulated until they were

later added into the LBES MCS configuration.

Full systems integration testing began on April

26, 1989. Testing that was accomplished in-

cluded (Preisel):

�Dynamic overspeed trips

�Torque and speed limiting

�Main reduction gear tooth contact checks

�Full power testing

�Program control testing

�Brake mode testing

�Dynamic system responses

�Remote system tests

As a result of the expertise that was developed

during system testing, NAVSSES was selected to

be the life cycle software support agent (SSA) for

the DDG-51 MCS in 1989. This selection was

the significant milestone that allowed the Navy

Figure 6: Diagram of the DDG 51Machinery Control System



to build a foundation of technical excellence in

MCS and software engineering.

Initially, the DDG 51 MCS computer program

was approximately 80,000 lines of code in

CMS-2, a source code language used on circa

1980 military microprocessors. One of the first

major changes in the DDG 51 MCS software

was porting algorithms developed by a technical

support contractor to correct issues with shaft

speed control and other problems. Shaft speed

control was initially an open loop control system

that did not reliably produce ordered shaft

speed, and transient response was unacceptably

slow. The new code was developed and

interfaced to the existing subprograms to create

a new Shaft Control Unit program. This new

program was then interfaced to the engine

controllers and other consoles. The new

program was tested on the LBES and delivered

to the USS ARLEIGH BURKE (DDG 51), where

it was tested at sea (Halpin and Odum).

Since that software change, hundreds of

software deliveries by the NAVSSES SSA have

been made to DDG 51 class ships, providing

improvements or solving problems within the

system.

DDGModernizationStarting with proposals in 2002 the DDG

Modernization program has been supported by

NAVSSES from evaluation of alternatives

through requirements development. A new MCS

architecture was implemented on the forward fit

ships, DDG 111 and DDG 112, with the intent

to back fit this system in older DDG 51 class

ships for MCS modernization. The forward fit

ships will be supported in the same way as

previous DDG 51 class new construction ships.

NAVSSES took delivery of new control system

hardware in 2008 and modified the LBES

simulator/stimulator and switching equipment

to interface to this new hardware. In late 2009,

NAVSSES was requested to finalize the

computer program for the DDG 111 in support

of builders and acceptance trials in 2011.

For the backfit effort NAVSSES took the DDG

111 MCS computer programs and modified

them for DDG 51 configuration differences.

This hardware was interfaced with the new

integrated bridge, network, digital video and

other equipment at LBES during the 2009–2010

timeframe. This hardware and software

suite was installed on the DDG 51 and 53 in

mid-2010.

In 2010 it was decided that the DDG new ship

construction program would be restarted. The

DDG 51 class support schedule has extended to

2025, when the DDG 127 is scheduled to be

commissioned and the first of the FLT 2A ships

will be modernized. The modernization program

could extend to the year 2042.

DDG51: Software Support and the CapabilityMaturityModelSix general categories have been identified as

sources of software changes:

�Fleet Problem Resolution

� Ship Alterations

�External System Life Cycle Manager Changes

�Obsolescence

� Ship Construction Problem Resolution

�Casualties

These changes impact not only the software but

support documentation as well. A Software

Support Activity is responsible to ensure that

software meets its requirements and fulfills its

intended functions in the operation of a system.

To perform this role, the SSA utilizes established

processes to:

�Ensure software development and

configuration management integrity

� Support software acquisition, development,

test, and production prior to deployment

�Manage software requirements and interfaces

�Maintain system requirements allocated to

software

�Oversee integration testing

� Supply/Install/Support tactical software to the

fleet

NAVAL ENGINEERS JOURNAL92 &2011 #2


�Review shipboard engineering changes for

software impact

�Duplicate, troubleshoot and resolve problems

from fleet

�Document and track all software problems and

improvements

�Ensure software is viewed from a systems

engineering perspective

As the SSA workload increased on the DDG 51

class, it became difficult to meet the SSA

requirements. In 1996 NAVSSES engineers and

management realized that there was a need for

more rigorous and structured processes as the

SSA responsibility increased rapidly. While the

software products were of high quality and

schedules were being met, the environment was

having detrimental effects on the workforce, due

to short deadlines, late changing requirements,

and high workload. It was also recognized that

the DOD was adopting the Software Capability

Maturity Model (SW-CMM) to evaluate

organizations that were developing software.

NAVSSES made the decision to develop a

Standard Software Process that was compliant

with the SW-CMM. (Kraynik)

SW-CMM was developed to guide the adoption

of best practices in software engineering in an

effort to address numerous shortcomings in

software products. During the 1980’s many

complex, software-based products were

delivered to the DOD that did not meet expected

functionality or quality. Many, if not most,

software projects were grossly over budget

and did not meet schedule. In the 1990’s the

SW-CMM became widely utilized, and in many

cases, DOD programs required organizations

that developed software to be SW-CMM

compliant.

The DDG 51 MCS SSA was assessed at Level 2

of the SW-CMM in September 1998. This meant

that NAVSSES had a disciplined approach to

process that was repeatable on projects that are

similar. Upon receiving the assessment of Level

2, efforts began to expand the deployment of the

Standard Software Process (SSP) across multiple

projects and attain a Maturity Level 3. For Level

3, the SW-CMM states that the ‘‘software

process for both management and engineering

activities is documented, standardized, and

integrated into a standard software process for

the organization.’’ In September 2000, the

Machinery SSA was assessed at Level 3 for five

software programs: the DDG 51 class MCS,

AOE 6 class MCS, the MHC 51 class

Machinery/Ship Control System (M/SCS), the

ARS 50 class MCS, and the Integrated Condition

Assessment System.

CMMIAs the SW-CMM moved to a systems view,

rather than just limited to a software view,

NAVSSES revamped its processes and rolled out

a new Software-based Systems Process that

complied with the new Capability Maturity

Model Integrated (CMMI). In 2006 and again

2009, the organization was appraised at Level 3

of the new integrated model. The MCS

programs were significant to demonstrating the

value and benefit of the SSP, which has been

applied to all software-based system products at

NAVSSES.

SupportingMCS In-serviceEngineeringandSoftware Support Beyond theDDG51ClassFor many shipbuilding programs it was not

financially viable to build an LBES with hot

plant to test MCS. To reduce testing costs, the

MCS control consoles and local controllers are

connected to a simulator/stimulator for testing

and problem resolution. Examples of this type of

ISEA/SSA lab include the AOE 6 class and the

MHC 51 class. In 1994 NAVSSES was

designated as the SSA for both the AOE 6 class

and the MHC 51 class. The AOE 6 class was a

natural extension of the support provided

to the DDG 51 class, since the consoles were

manufactured by the same vendor and were very

close in technology. Support for the AOE 6 class

continued until the ships were transferred to the

Military Sea Lift Command.

NAVSSES began supporting the MHC 51 class

Machinery/Ship Control System (M/SCS) during



the mid 1990s. Numerous improvements were

developed for the class, including an autopilot

function. The autopilot development effort was

the first MHC 51 software change in the class.

The MHC M/SCS is currently being replaced by

NAVVSES with a new MCS under the Foreign

Military Sales program.

StandardizedMonitoringandControlSystem, Smartship, and Integrated ShipControlsThe Standard Monitoring and Control

System (SMCS) was to be a standards-based,

open architecture system with standard

human-machine interfaces workstations that

were functionally configured by upgradeable

software. The concept development and design

was largely accomplished at NSWCCD in

Annapolis with testing accomplished at

NAVSSES. SMCS concepts became the

precursor to the Smartship program’s machinery

control system.

The initial Smartship, USS YORKTOWN (CG

48), played in important role in providing a

platform to evaluate enabling technologies.

As a result of the success of the technology

evaluation, the Integrated Ship Control (ISC)

program was established. An element of this

program was established to replace the

increasingly obsolete CG 47 class Engineering

Control and Surveillance Equipment with a

distributed and more automated Machinery

Control System. This system was tested on the

DDG 51 LBES through the use of switching

equipment and signal conditioning to

allow the new CG 47 class MCS to operate the

DDG 51 hot plant. This was an effective and

cost efficient means of validating the CG 47

MCS.

The USS TICONDEROGA (CG 47) was the first

ship in the class to receive the ISC machinery

control system. NAVSSES provided on-site

support and simultaneous LBES testing to the

first several ISC modernizations. In 2001,

NAVSSES’ MCS personnel assumed the

responsibility as the ISEA/SSA for the system.

NAVSSES has since re-architected the system

and software.

Another important aspect of the CG 47 ISC

program is the implementation of physics based

embedded training, entitled the On Board

Trainer (OBT). The distributed nature of the ISC

MCS allows the capability for ship’s force to

train on one workstation which is connected via

network to a plant simulation, while another

workstation is in control of the engineering

plant. NAVSSES developed the second

generation of the ISC OBT to be a more realistic

simulation of the engineering plant. An

integrated model of the CG 47 class machinery

systems were developed, leveraging off of the

first OBT developed for the MCM 1 class

modernization. In 2002, the first gas turbine

machinery plant OBT was successfully installed

on CG 54.

OnBoardTrainerThe On-Board Trainer (OBT) is a software

application that provides a means for crew

training without operating a live machinery

plant. It provides a real-time training simulation

of the machinery plant that results in reduced

wear, less repair maintenance and fuel savings.

The OBT models the propulsion, electrical and

auxiliaries systems to provide a full simulation

of the machinery plant vital for ship operation.

It provides on-line individual and team

watchstander training during both pier and

underway conditions. The application is able to

run at any MCS control console.

Each MCS console can be placed in either

‘‘Simulation’’ mode or ‘‘Plant’’ mode. In

Simulation Mode, the consoles receives and

sends data to the simulator software and in Plant

Mode, the consoles will exchange data with the

MCS PLCs.

The OBT is composed of three main sections:

Instructor Operator Section, Controller

Simulation and Machinery Plant Simulation.

The Machinery Plant Simulation provides an

integrated, realistic simulation of the machinery



plant which is controlled and monitored by the

MCS. Manuals, operating guides and In-service

Engineering Agent input are used to develop the

OBT’s machinery modeling to ensure realistic

simulation. The simulation runs in real time and

is controlled by the Instructor Operator.

LPD17EngineeringControl SystemSimilar to the DDG 51 class and the CG 47 class

ISC, NAVSSES is responsible as the ISEA/SSA

for systems that have been transferred to the

Navy. The LPD 17 Class Engineering Control

System (ECS), one such system, is a VME based

real-time distributed data acquisition, control,

processing, and display system. ECS provides a

remote centralized monitoring and control of

propulsion, electrical, auxiliary, fuel, damage

control and ballast systems, and performs both

remote and centralized equipment health assess-

ment and maintenance functions.

NAVSSES was involved in specification devel-

opment and design reviews early in the program

and later provided on-site design and production

support. In 2007 NAVSSES was designated the

ISE/SSA, and a SSA Laboratory was established

in Philadelphia to provide a software

development environment as well as provide

troubleshooting capability.

DDG1000The DDG 1000 has the most complex

engineering plant control system ever designed

for a US Navy ship. The engineering plant

control or Engineering Control System (ECS) is a

component of the Ship Control System Element.

Within the ECS boundary, there are three

ensembles: Integrated Power System Control

(MIPS), Auxiliaries Control (MACS), and

Automated Damage Control (MADC). MIPS

monitors the power plant equipment and

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 the

Ship Domain Controller and are 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 (Henry et al).

During the Detail Design and Integration phase

the Ship Control System Integrated Product

Team was formed with the lead systems

integrator, its subcontractors, the shipbuilders,

and the Navy Technical Team (NTT) members.

NAVSSES is supporting the NTT, overseeing

design, integration, and testing. NAVSSES is also

supporting the integration testing of ECS to IPS

on the DDG 1000 LBTS.

Other Ship ClassesNAVSSES provides support to other ship classes

such as the LHD 8, LHA class, the LCS class and

the Ship to Shore Connector program. This

support can take the form of developing trade

studies, analysis of alternatives, requirements

development, and leading Integrated Product

Teams in the acquisition phase. Production

support at the waterfront has been provided, in

some cases with on-site personnel, as well as

support for sea trials. When designated,

NAVSSES is the ISEA and SSA for the MCS.

MCSModernizationProgramsModernizations have been a major aspect

of the MCS efforts at NAVSSES. This paper will

describe in some detail the technical design

characteristics and implementation starting with

the MCM 1 class and progressing to current

programs. This level of detail is intended to the



give the reader a sense of what NAVSSES does

for modernizations of the MCS.

MCM-1Class Integrated Ship Control SystemIn September 1996, NAVSSES proposed a

replacement system, the Integrated Ship Control

System (ISCS), for the MCM-1 Class MCS using

COTS equipment. This proposal also included

an On Board Trainer. The MCM-1 ISCS

replaced the existing unreliable and

maintenance-intensive analog propulsion

control and main diesel engine governor

systems with a new computer-automated,

software-based digital control system. ISCS

monitors and controls all of the ships

electrical power generation and distribution

functions, including those functions that directly

involve the ship’s primary mission area of

mine-countermeasure operations.

Initial tasking from the Mine Warfare Program

Ship Program Office stated the need to develop a

Service School Command trainer and install

ISCS on fourteen MCM-1 Class ships which

included two in Bahrain and two in Japan. The

initial planning for ISCS contained several goals

that would enhance the quality of life of MCM

crew members:

�Provide State-of-the Art Commercial-Off-

the-Shelf control system

�Reduce crew workload

�24-hour parts support

�First Class wide modern control system

�Enable on-board crew training utilizing

simulation

�Allow for expansion

�Original ISCS Hardware

ISCS design was predicated on the use of COTS

hardware, thereby minimizing initial

development costs and utilizing the OEM’s

existing support infrastructure. The following is

a detailed view of the system.

Primary ISCS hardware includes two sit-down

control consoles and three local workstations,

eleven Programmable Logic Controllers (PLCs)

and four ATM switching hubs. The shipboard

locations of the primary ISCS equipment are

shown in Figure 7.

The control consoles and workstations use

large hi-definition monitors. The consoles

and workstations, using a Windows operating

system, run the ISCS User Interface Program

and other applications. Since ISCS is a

distributive system, any console or workstation

can perform propulsion and/or electrical

control functions, however only one may have

control of the propulsion or electrical plant

at a time.

Figure 7: ISCS Hardware Location



Major parts of the ISCS control system were

assembled and consisted of equipment mounted

in stainless steel, watertight enclosures.

Eleven PLCs contain the circuit cards that

interface with the machinery plant. Each

PLC is a system of two cabinets (Alpha and

Bravo). The Alpha cabinet contains the PLC

processor and Analog Input and Output

modules. The Bravo cabinet contains the

Digital Input and Output modules. The PLC

processor contains signal processing and

machinery control logic.

Three Generator Local Control Electronics

Enclosures (GLCEEs), one for each Ship Service

Diesel Generator, contain electronics that

provide the Ship Service Diesel Generator’s

control interface between the switchboard and

the PLC. One Gas Turbine Control Relay Box

(GTCRB) contains electronics that are used to

perform automatic control functions for the

ships Gas Turbine Generator.

The primary Local Area Network (LAN)

hardware is four ATM switches, or hubs. The

Ethernet ports operate at 10 megabits per

second for each PLC and for all consoles and

workstations.

ISCS consoles, workstations, PLCs, and ATM

switching hubs are protected against power

failure by Uninterruptible Power Supplies

(UPS). Each UPS is fitted with a network

interface card for monitoring by the ISCS con-

soles. Other miscellaneous ISCS hardware

includes three operator chairs, four stainless

steel hub enclosures, one color printer, three

portable data terminals, and two CD stack

players.

ISCS SoftwareThe ‘‘heart’’ of ISCS is the extensive amount of

software, which runs on the Control Consoles

and the Programmable Logic Controllers.

The ISCS Software suite consists of software

modules including the ISCS Control and

Monitoring Software, the Bell Logging Soft-

ware, the On-Board Simulator/Trainer Software,

and the Integrated Condition Assessment System

(ICAS).

The Control Consoles contain the ISCS User

Interface Software. This software is the User

Interface to the Machinery Plant. Its functions

are to provide the user the capability to monitor

the status of the machinery plant, send

commands to equipment and help diagnose and

troubleshoot ISCS problems. The User Interface

Software is written in the Visual C11

Programming Language. It utilizes bitmaps

stored on the console hard drive to display views

of the machinery plant.

The same software executable runs on all of the

control consoles and thus provides the same

machinery control and monitoring capability to

each console user. Equipment control capability

is broken down into two parts; Propulsion

Equipment and Electrical Equipment

responsibility. Each console has the capability to

monitor the entire machinery plant parameters

at all times. Only one console may have control

capability (Propulsion, Electrical or both)

at one time. A Transfer of Equipment Control

algorithm/hierarchy is established in the control

console software.

Like a typical Windows program the User

Interface Program contains menus, toolbars,

windows and audible sounds that provide the

operator with an easy-to-use interface with the

machinery plant. The look and feel of the

Console program is that of a common

Windows program. The user interfaces with the

program via a combination of track-ball

movements, right and left point-and-click

maneuvers and the keyboard. The Operator

chooses buttons and sliders to provide

machinery plant control.

The console software provides the user with the

current state of the shipboard equipment.

There are eighty different picture views of the

machinery plant, which the operator may



display. Views may be displayed in quad (up to

four views may be displayed at one time) or full

screen mode. Each display contains a number of

monitor and control boxes. These boxes are the

user active locations on the screen and represent

the shipboard equipment and machinery (e.g.,

temperature sensor or diesel engine state). The

state of a box is determined by its text, color and

flashing state. Figure 8 and Figure 9 show a

machine (MRG) view and a system (Ships

Service Air System) view.

Each of the eleven PLCs contains a separate

software program written in a Ladder Logic

Language. The PLC software provides for Signal

Processing and Machinery Control Logic. Signal

processing consists of signal conditioning, alarm

and status change processing and signal out of

range checking. Control logic includes Diesel

Engine and Diesel Generator Engine State

Logic, Propulsion Program Control, Electric

Plant Auto-Paralleling, Gas Turbine Engine

State and Control Logic, and Auxiliary

Equipment Logic.

Console Commands are sent through the

Control software by the Console-in-Control via

the FOLAN to the proper PLC. In turn, logic in

the PLC sends out the command to the proper

equipment. Discrete and Analog signals are

received by the PLCs, processed and available

via the fiber optic local area network (FOLAN)

to all of the Controls Consoles when queried.

Information is displayed through the Control

User Interface Software.

ARS-50 Class IntegratedMachinery ControlSystemFollowing the success of the MCM-1 ISCS

program NAVSSES was tasked to analyze the

aging control system on the ARS-50 Class ships.

It was found that the current ARS-50 Class MCS

posed numerous maintenance, obsolescence and

supportability problems. Rather than upgrade

an already outdated control system, NAVSEA

decided to replace the ARS-50 Class Machinery

Central Control System (MCCS) with a new

system and tasked NAVSSES to do so. Using

lessons learned from the MCM ISCS program,

a new control system called the Integrated

Machinery Control System (IMCS) was

developed. The new system was be a distributed

client-server system comprised of COTS

equipment and embedded software and was

intended to be used to control and monitor the

propulsion, electrical and auxiliary machinery

systems. Additionally, an OBT was developed to

Figure 8: MRG View



train ships force in the operation of the new

control system.

The IMCS was completely developed and lab

tested but due to budget cuts was never installed

shipboard. Although much of the ARS software

and hardware design was based on the MCM

ISCS project, there were numerous key changes

that would shape NAVSSES modernization

programs for years to come, including:

�Methods for developing Graphical User

Interfaces

�Managing MCS data with databases

�Methods for MCS data communications

CVNMachinery Control SystemsNAVSSES has been involved with in all phases of

Carrier Machinery Control System Programs.

This includes:

�Designation as the ISEA/SSA for the Distribu-

ted Data and Control Network (DDCN)

Machinery Control System (MCS)

� Selection as the designer/developer of the

Smart Carrier Program MCS

�Developing major MCS upgrades during

Carrier Refueling Complex Overhauls

(RCOHs)

� Supporting the CVN-78 acquisition

program

Before 2000, control and monitoring of

non-propulsion plant machinery systems

(e.g. JP-5 and Potable Water) on US Navy

Aircraft Carriers had been accomplished

through a combination of manual operations

(e.g. physically opening a valve) and

compartmentalized hard-wired remote

electronic panels and consoles (e.g. JP-5 consoles

and IC/SM alarm panels). Information was

limited to the space where these controls were

located and provided for limited machinery/

equipment situation awareness to the operator.

In addition, the control/monitoring equipment

was routinely in need of maintenance and repair.

Since the late 1990s, many of the hard-wired

electronic based consoles/panel and manual

controls had been replaced with computer-based

control systems. These replacement control

systems have been evolving and range from

simple stand-alone control systems to complex,

fully integrated solutions.

DistributedDataandControl NetworkMachinery Control SystemThe Distributed Data and Control

Network (formally known as ‘‘Integrated

Figure 9: Ships Service Air System View



Communications and Advanced Networks’’ or

ICAN) was a system integration concept

and acquisition strategy intended to use

Non-Developmental Items (NDI) and COTS

technology to integrate voice and data systems in

NIMITZ class CVNs. The system included a

core network fiber optic cable plant with a

redundant ATM/Gigabit Ethernet network

backbone supporting the following families of

systems: Integrated Voice, Machinery Control

and Navigation/Ship Control.

DDCN was initially developed by the

shipbuilder OEM for CVN 76, but a reduced

scope DDCN system was also developed by the

OEM for installation in CVN 68 during RCOH.

In 2001, NAVSSES provided extensive ISEA

technical support to ensure the ship would meet

deployment requirements. In 2002 NAVSSES

was designated as the DDCN ISEA/SSA, with

support from SPAWAR Charleston for Voice

System engineering. DDCN ISEA/SSA

responsibility included the CVN 69 (during

RCOH using a modified CVN 68 design

baseline) and the new acquisition CVN 77 (using

the CVN 76 DDCN design baseline).

CVNSmart CarrierMachinery Control SystemRecognizing the intense workload and the asso-

ciated impact on readiness and mission

effectiveness, the Chief of Naval Operations

(OPNAV N785) and the Program Executive

Office (PEO) for Aircraft Carriers stood up the

Smart Carrier (SC) Program as part of the US

Navy workload reduction effort. NAVSSES was

tasked to develop a new MCS architecture that

would fit the needs of the CVN ships. Smart

Carrier Program initiatives reduce shipboard

workload through insertion of enabling

technologies to enhance sailor quality of life and

reduce total ownership costs. NAVSSES used

numerous readily available technologies already

implemented in Navy ships to reduce or

eliminate repetitive manual tasks. Many of these

tools are based on COTS technology, available

at a cost far below what in-house development

would entail. The automation of functions

such as machinery controls and equipment

monitoring provided immediate benefit in

workload reduction, and acted as the enabler to

permit the reinvention of procedures and

consequent reduced manpower needs for

shipboard functions. The new Smart Carrier

MCS also paved the way for the reduction in

total ownership costs (R-TOC) and provides the

baseline for future aircraft carrier designs.

The new Smart Carrier MCS architecture was

developed to increase survivability, maintain-

ability and expansion potential. The SC MCS

has been successfully installed on the CVN 68

(replacing the DDCN MCS), 70, 71, 72, 73, 74

and 75 and integrates ship systems such as:

� JP-5

�Firemain

�List

� IC/SM Alarms

�Potable Water

�Reserve Feed

�Bilge & Drain

�CHT

�A/C Plant

�O2N2 Plant

�AFFF

The SC MCS was the first machinery control

system in the US Navy to use an Ethernet

I/O LAN. The I/O LAN is the network that

connects the controllers (in this case, PLCs) to a

remote I/O chassis. The I/O LAN is configured

in a survivable star topology.

The SC MCS provides monitoring and control

of designated shipboard systems using

multi-functional Human Machine Interface

(HMI) workstations, Programmable Logic

Controllers (PLC), Input/Output (I/O) Drops,

Operator Interface Panels (OIP), Core Network

Ethernet switches, Ethernet switch boxes and

data servers. Figure 10 shows the relationship of

MCS components.

MCS information is distributed and available

throughout the core network for use by

equipment connected to the Hull, Mechanical



and Electrical (HM&E) Network. Operator

controls are processed by the PLCs via operator

commands through the OIPs and HMI Displays.

The MCS also provides self-diagnostics of

equipment and signals.

Fiber Optic core network switching units make

up the core Ethernet backbone. Theses switches

distribute information to the HMI and data

servers through dual redundant fiber optic

cable paths. They also provide interface to other

software programs including the Integrated

Condition Assessment System (ICAS), Flooding

Casualty Control Software (FCCS) and the

Advanced Damage Control System (ADCS).

A dedicated Uninterruptible Power Supply (UPS)

Power distribution system powers MCS system

equipment. Power is distributed between the

UPSs. Some MCS equipment has an auxiliary

power source from the ship’s normal power

distribution system.

The MCS links existing and new sensors through

Input/Output drops where their discrete signals

are converted to digital signals and distributed to

the HMI and OIP through fiber optic cable

The PLC Groups, Core Network and HMI

Workstations form the architectural framework

for MCS signal processing. Together these

elements are implemented in an MCS designed

for survivability and reliability. There are

multiple PLC groups which process monitoring

and control signals. These groups are designed to

be functionally independent of each other for

system survivability. Each PLC Group has the

infrastructure needed to process the HM&E

system signals associated with it independent of

the remaining MCS. The failure of any single

Figure 10: Smart Carrier MCS Block Diagram



group will not affect the function of the

remaining eleven. Figure 11 provides a basic

diagram of PLC group communication. Each

PLC group has an Industrial Ethernet Switch

(IES) to process network communication within

the group and connect the group to other MCS

devices. PLC groups that process signals

with critical ship functions have local HMI

workstations attached to the group. Local HMI

workstations connected to a group’s Industrial

Ethernet Switch (IES) extend the group’s

independence from functional to operational.

This operational independence allows the group

to function as a self-contained system.

The core network refers to the Local Area

Network (LAN), which transmits system

information between PLC groups and HMI

workstations over a redundant infrastructure of

gigabit switches and fiber cabling. Information is

also sent through the Network to MCS Data

Servers for data logging as well as to other Smart

Carrier systems to support their function.

Without the Core Network, operation of the

MCS would be reduced to the PLC groups with

local HMI workstations. These groups would

remain operable since local HMI workstations

are connected directly to the PLC groups

through the IES of that Core Network’s Gigabit

switches. Figure 12 provides an overview of

communication in the Smart Carrier network.

CVN78Machinery Control SystemA new Machinery Control System is being devel-

oped for the CVN 78. Lessons learned from the

Nimitz class MCS backfits are being applied to the

system design and development. One major dif-

ference between the two programs is that where

the Nimitz backfits are focused on a direct

replacement of existing controls for a set machin-

ery plant, the CVN 78 machinery plant/equipment

and concept of operations are also being devel-

oped in parallel. This creates a situation with

additional challenges and steps for the MCS

development. NAVSSES is directly supporting the

NAVSEA Ship Design Manager in the areas of

requirements development and design review.

LSD-41/49 ClassMachinery Control SystemThe LSD41/49’s legacy machinery control/mon-

itoring architecture used a combination of

manual operations (e.g. physically opening a

valve) and compartmentalized hard-wired

remote electronic panels and consoles, for

example the ship’s Enclosed Operating Stations

Console (EOS) and Local Operating Station

Figure 11: PLC Group

Figure 12: Commu-nications Flow



(LOS). Machinery status information is limited

to the space where these controls are located and

provides limited machinery/equipment situation

awareness to the operator. Further, the LSD41/

49’s existing machinery control/monitoring

system experiences low achieved availability and

requires frequent repair.

In 2005 the PEO Ships Program Office tasked

NAVSSES to replace the current ship control and

monitoring system as part of the LSD41/49 Class

Midlife (ML) program. This new control system

was titled the Advanced Engineering Control

System (AECS).

AECS consists of a Machinery Control

System, (MCS) Steering Control System (SCS),

embedded Onboard Training System (OBT) and

Local Area Network (LAN).

NewLSDMCSLike the MCM-1 ISCS, ARS IMCS and CVN

Smart Carrier MCS the new LSD MCS is

based on a distributed control system

architecture that is designed to provide both

remote and local monitoring and control of the

LSD41/49 propulsion, electrical, and auxiliary

systems. Propulsion systems consist of the Main

Propulsion Diesel Engines, Reduction gear,

Propeller Shaft and associated support

systems. The Electric Plant consists of the

HMI interface to the Power Management

Platform and the 400 Hz system. Auxiliary

systems include AC Plants & Chilled Water,

Compressed Air, Potable Water, Waste, etc.

System processing will be distributed among

I/O enclosures and User Interface Console

processors. See Figure 13 for an overview of the

LSD MCS.

Figure 13: LSD MCS Overview



The MCS is configured as an Ethernet-based

‘‘producer/consumer’’ architecture and is designed

for potential expandability, reliability, availability

and maintainability. Each I/O controller group will

contain at least one PLC processor located within

one of the PLC enclosures. Figure 14 shows a typical

PLC I/O enclosure. Each PLC receives inputs from

legacy machinery pant sensors, processes the data,

and broadcasts (produces) its information onto the

LAN. Applications within the Human Machine

Interface (HMI) consoles and panels connected to

the network monitor for and read information

(consume).

The HMIs are the primary user interface to the

system. Figure 15 shows various types of HMI

equipment. Each of the consoles and panels will

be capable of controlling and monitoring the

entire machinery plant. Console control cap-

ability will be divided into logical control

domains (e.g. Propulsion and Electrical).

All consoles are able to monitor all machinery

plant data at all times, although only one (or

some) consoles have control at any given time.

Figure 16 shows a sample HMI interface. In this

case the HMI shows a Quad Screen display

showing four simultaneous views of different

parts of the machinery plant. A hierarchy for

transfer of control between the consoles is

established within the MCS software, replicating

the hierarchy of the existing control system.

FFG-7 Class Digital Damage ControlConsole(DDCC)The DDCC replaces the Damage Control

console and associated Interior

Communications Standard Modules (IC/SM)

with a new Programmable Logic Controller

(PLC) based control and monitoring system.

Monitored ship systems include ship damage

control zone alarms, the fire main system and

the ventilation system. An included video

monitoring system monitors Main Machinery

spaces. This system is currently installed on US

Navy FFGs and on Australian Navy FFGs.

A dual-monitor display pedestal console (see

Figure 17) located in the Central Control Station

is the Human-machine interface equipment

for the operator’s interface to the DCS plant

equipment. The dual-monitor display is capable

of displaying the Damage Control System

software on one display and the video software

Figure 14: PLCEnclosure

Figure 15: HMIComputers



on the other display. When a damage alarm is

sensed by the system the correct video of the

space will automatically be displayed.

United States Coast Guard (USCG)MachineryControl SystemsFor the past 4 years NAVSSES has been

providing Machinery Control System support to

the USCG. NAVSSES is currently providing

MCS support for the following USCG ship

classes: National Security Cutter (NSC) Class,

270’ Medium Endurance Class Cutter

(WMEC-901), ALEX HALEY Medium

Endurance Class Cutter (WMEC-39) and

Off-shore Patrol Cutter (OPC).

National Security CutterMachinery ControlandMonitoring SystemNAVSSES has been designated the ISEA and SSA

for the NSC-1 class. As has been done for all

major MCS platforms that NAVSSES acts as

ISEA/SSA for, a Hardware/Software Integration

(HSI) facility simulating the functionality of the

MCMS installed on NSC-1 was established in

Philadelphia, PA. This facility is comprised of a

mix of hardened (identical to shipboard) and

Figure 16: Quad Screen HMI



non-hardened (same functionality of ship HW)

equipment. The objective of the HSI Lab is to test

the entire functionality of the control system as a

complete and integrated system. Tests are devised

to exercise every line of PLC and Console code.

Test equipment is connected to the PLCs to

simulate machinery and shipboard conditions.

NAVSSES has developed and implemented a

MCMS Life Cycle Management (LCM) Plan for

the entire NSC class. To date NAVSSES has

successfully delivered software updates to the

NSC-1 and NSC-2 ships. NAVSSES has also

provided for a technical refresh of computer and

network components onboard these ships.

270’MediumEnduranceClass Cutter(WMEC-901)MachineryPlant ControlAndMonitoring SystemThe U.S. Coast Guard (USCG) 270’ Medium

Endurance Cutter (WMEC) Class originally

installed Main Propulsion Machinery

Control System (MPCMS) posed numerous

maintenance, obsolescence and supportability

problems.

The MPCMS provides for the control and

monitoring of Propulsion and Auxiliary

shipboard systems. The MPCMS major

subsystems include:

�Engineering Control Center Console (ECCC)

�Local Operating Stations (LOS) and Alarm

Panels

�Pilot House Station

The Engineering Control Center Console

(ECCC) that is located in the Engineering

Control Center (ECC) is primarily

responsible for monitoring and controlling

the main and auxiliary systems of the

machinery plant. The ECCC consists of five

major parts:

�Propulsion Control System

�Processor Alarm System

�Vital Alarm System

�Other Controls

�Miscellaneous Enclosed Components

The USCG tasked NAVSSES Philadelphia to

design, develop, test and install a replacement

for parts of the MPCMS.

NAVSSES is responsible to provide a new

machinery control and monitoring system to

replace the existing MPCMS installed on the

USCG WMEC 270’ Class. Efforts are being

made to leverage off other NAVSSES Machinery

Control System (MCS) projects and retain

the existing MPCMS machinery control and

monitoring functionality to decrease risk, help

alleviate program workload and costs and to

provide commonality of parts support with the

US Navy.

Thirteen (13) WMEC 270’ ships and a Training

Console currently located at Yorktown, Va. are

within the scope of this project.

Figure 17: Dual-Monitor PedestalConsole



ALEXHALEYMediumEnduranceClassCutter (WMEC-39)MachineryPlant ControlandMonitoring SystemThe U.S. Coast Guard Cutter (USCGC) Alex

Haley Medium Endurance Cutter (WMEC-39)

Class installed pneumatic Automatic Propulsion

Control (APC) System had numerous

maintenance, obsolescence, supportability and

operational problems. The ship was originally

the ATS-1 USS EDENTON, commissioned in

1969, and had some modifications completed

during its conversion to a USCG Cutter in the

1990s.

The Automatic Propulsion Control System

components include:

�Controllable Pitch Propeller (CPP) System

� Shaft Indicating System

�Engine Governor Controls

�Machinery Control System (MCS)

The Machinery Control System provides for

the control and monitoring of Propulsion and

Auxiliary shipboard systems. The MCS major

subsystems include:

�Main Control Console (MCC)

�Propulsion Monitoring System Electric Cabi-

net

�Alarm Switchboard and IC/SM 20 Panels

�AC/DC Rectifying Unit

�Bridge Console

The USCG tasked NAVSSES to design, develop,

test and install a replacement for the pneumatic

APC with a computer based electronic one.

MPCMS is the interface between the operators

and the machinery plant. It provides a means

for the operators to control and monitor the

machinery plant by providing for remote

indications of key machinery plant parameters.

It also allows for control of many devices with

the machinery plant

The MPCMS achieves increased reliability by

incorporating industrial processors and switches

into the system design. These industrial devices

are Commercial Off-The-Shelf (COTS)

components with a history of low failure rates.

Its reliable COTS equipment is integrated into a

system with a robust communications

structure to provide a highly functional,

low-maintenance system. Each COTS

component of the MPCMS is described in this

Technical Manual as well as vendor detailed

documentation.

The major components of the MPCMS are the

ECC Console, the Pilot House Console, The two

Uninterruptable Power Supplies (UPS), and the

two sets of Governor Control Unit (GCU)

Cabinets, the EOT Servo controllers, and Shaft

Speed Indication systems. The following section

will describe the equipment of these major

components.

The MPCMS is comprised of both hardware

and software, which together provide the

infrastructure for consolidated management of

machinery plant systems. The MPMCS performs

its function by processing the monitoring and

control signals using multi-functional Human

Machine Interfaces (HMI), Programmable Logic

Controllers (PLC), Input/Output (I/O) Racks,

Industrial Personal Computers (PCs) and

Industrial Ethernet Switches (IES). Data is

available throughout the networked system for

use by the various systems.

The new system is comprised of several distrib-

uted independent networks and sub networks.

The port and starboard shafts are completely

independent control and monitoring systems.

The Throttle controls, including the integrated

Engine Ordered Telegraph (EOT), has its own

independent control network between the

Pilot House EOT and the ECC EOT used for

indicating and controlling the EOT bell as well

as the EOT position.

The MPCMS Processors known as programma-

ble Logic Controllers (PLCs) communicate using

Ethernet IP. Three Industrial Ethernet Switches



(IES) are used to allow the PLCs to communicate

to each other as well as the consoles also known

as Human Machine Interfaces (HMIs).

The Programmable Logic Controller (PLC)

Racks in the ECC Console house the processor

and communications modules as well as I/O

modules which receive inputs and send outputs

to the field sensors and devices.

Three Industrial Ethernet switches are used to

establish network connectivity between the Port

and Starboard control systems, between the PLC

systems and HMIs as well as between the Pilot

House and ECC console.

The MPCMS was successfully installed and

tested in November 2010. This ship has since

deployed with the new system.

ConclusionThe MCS expertise that exists today has its

foundations in the Navy’s early steam turbine

and gas turbine testing. Much of the knowledge

was gained through testing and integration on

the Land Based Engineering Sites and in the

In-Service Engineering Software Support Labs.

These assets have been essential tools in

developing the skills of Naval engineers, whose

experience and expertise have played a

significant role in successful fleet introductions

and modernizations.

In addition to the tools and facilities, NAVSSES

has established rigorous processes in the form of

the Standard Software-based-system Process to

ensure that emphasis is placed on planning,

management, systems engineering, software

engineering, and quality assurance.

NAVSSES continues to innovate and to improve

its processes, skills and expertise. New methods

are being implemented to improve Naval

Machinery Control Systems and reduce costs

through Open Architecture and Commonality.

As machinery control systems have grown in

size, capability, and complexity, the organization

has grown to support the multitude of systems.

From R&D through Acquisition to ISE and

modernization NAVSSES has established a

Center of Excellence for Machinery Control

Systems.

ACKNOWLEDGEMENTSThe authors would like to thank and acknowledge

the following individuals for their support dur-

ing the writing of this paper: Dr. E. Michael

Golda, Dr. Stephen Mastro, James McNamara,

Richard Halpin, Dorothy Kraynik, Vincent

Tolotta, John Buckley, Michael Iacovelli, Robert

Stahl, Debra Dezendorf and Mark Ennis.

Additionally, the authors would like to

acknowledge the efforts, accomplishments and

dedication of the personnel who provided the

support documented in this paper as well as the

many sponsors who have provided advocacy and

guidance throughout the organization’s history.

Lastly, the authors would like to acknowledge the

late Richard Cunningham for his vision, technical

acumen, mentorship, and ability to meet any

technical challenge, thereby establishing NAVSSES’

initial expertise in software-based systems. The

fleet support that NAVSSES provides today is a

direct result of his efforts and accomplishments on

the DDG 51 MCS program and his technical

counsel on numerous other projects.

REFERENCESPreisel, J.H., ‘‘The Evolution of Machinery Control

Systems Aboard U.S. Navy Gas Turbine Ships,’’ Naval

Engineers Journal, May 1989.

Preisel, J.H., ‘‘Testing at the US Navy’s Gas Turbine

Systems Engineering Complex,’’ American Society of

Mechanical Engineers, Gas Turbine and Aerospace

Congress and Exposition, June 1990.

Nufrio, R.P. and J. McNamara, ‘‘United States Navy Gas

Turbine Propulsion Machinery Systems Testing,’’ Amer-

ican Society of Mechanical Engineers, Gas Turbine and

Aeroengine Congress and Exposition, June 1988.

Carleton, R.S. and E.P. Weinert, ‘‘Historical Review of

the Development and Use of Marine Gas Turbines by

the U.S. Navy,’’ American Society of Mechanical



Engineers, Gas turbine and Aerospace and Aeroengine

Congress and Exposition, June 1989.

Hauschildt, M.R. and L.B. Ward, ‘‘U.S. Naval MachineryAutomation Concepts,’’ Naval Engineers Journal, April

1973.

Ingram, J.D., R.M. Adair, D.M. Gildart, R. Cunningham,and J.R. Mailhot, ‘‘DDG 51 Machinery Control System,’’

Tenth International Ship Control Systems Symposium

Proceedings, 1993.

Halpin, R. and J. Odum, ‘‘Propulsion Control on the DDGClass: 16 Years of Lessons Learned,’’ ASNE Automation

and Control Conference Proceedings, December 2007.

Kraynik, D.A., R. Halpin, and J. Kitson, ‘‘Transitioningfrom SW-CMM to CMMI: A Level 3 Organization’s

Perspective,’’ Thirteenth International Ship Control

Systems Symposium, April 2003.

Amy, J.V., N.H. Doerry, T.J. McCoy, and E.L. Zivi, ‘‘Ship-board Controls of the Future,’’ Naval Engineers Journal,

May 1997.

Sturtevant, G., P. Socoloski, D. Bartlett, and L. Totimeh,‘‘U.S. Navy Smartship Integrated Ship Controls –

Technology Roadmap for Performance Enhancements,’’

Thirteenth International Ship Control Systems

Symposium Proceedings, April 2003.

Tolotta, V., M. Henry, and J. Cohen, ‘‘Embedded Training

for Navy Shipboard Distributed Machinery Control

Systems,’’ Thirteenth International Ship Control

Systems Symposium, April 2003.

Henry, M., M. Iacovelli, and J. Thatcher, ‘‘DDG 1000

Engineering Control System,’’ ASNE Intelligent Ship

Symposium VIII, May 2009.

Tangora, M.F. and J. Mariani, ‘‘US Carriers Exploiting

Technology To Pilot Toward 2010 and Beyond,’’

Thirteenth International Ship Control Systems

Symposium, 2003.

Lovejoy, R.S., T.A. Marchioni, and D. Vought, ‘‘MCM-1

Class Integrated Ship Control System: Proof of Concept

to Class-Wide Installation/Implementation,’’

Thirteenth International Ship Control Systems Sympo-

sium, 2003.

Smith, K. and D. Vought, ‘‘LSD41/49 Class ML Program:

Advanced Engineering Control System (AECS),’’

Intelligent Ships Symposium, 2007.

Perotti, T.A., K.A. Colville, and J.B. Cohen, ‘‘Aircraft

Carrier Networks Evolution; Distributed Data and

Control Networks,’’ Intelligent Ships Symposium, 2005.

AUTHORBIOGRAPHIESMr. Timothy Scherer is the Branch Manager of

the Automation and Control Research and

Development Branch in the Research and

Engineering Department of the Naval Surface

Warfare Center, Carderock Division,

Philadelphia, PA. His previous positions

include: Machinery Control System Life Cycle

Manager, Machinery Control Systems Branch

Manager, and Gas Turbine Electric Power

Systems Section Head.

He has a Masters of Science in Electrical

Engineering and Bachelor of Science in

Electrical Engineering from Drexel University.

He has over twenty five years of Naval

engineering experience in machinery control

systems and electric power systems and for ten

years led the Executive Steering Group for the

Research and Engineering Department’s

Standard Software-Based-Systems Process. In

this role he led the effort to attain Level 3 in both

the SW-CMM and the CMMI. He has experience

in numerous ship acquisition and in-service

engineering programs as well as establishment of

the software support activity for several ship

classes.

Mr. Jeffrey 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. Mr. Cohen has over twenty

five years of Naval engineering experience in

machinery control systems in support of

numerous ship classes and has held positions in

the project management, design, development

and test of Machinery Control System software

and hardware.



Documents

Scherer-Evolution-ASNE-2011[1].pdf