The Evolution of Machinery Control
Systems Support At the Naval Ship
Systems Engineering Station
& Timothy Scherer and Jeffrey Cohen
Naval Ship Systems Engineering Station
Introduction
Machinery 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
& 2011, American Society of Naval Engineers
DOI: 10.1111/j.1559-3584.2011.00321.x
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 Constitutes A Machinery Control
System?
On U.S. Navy ships, the MCS provides
supervisory control and monitoring of machinery
systems, including: the propulsion plant, electric
2011 #2& 85
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
Figure 1: NAVSSES MCS Support
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
Figure 2: MCS Controlled/Monitored
Shipboard Systems
86 & 2011 #2
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
NAVAL ENGINEERS JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
Figure 3: Notional Architecture of a Ship’s Distributed Machinery Control System
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
NAVAL ENGINEERS JOURNAL
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.’’
The NAVSSES Role in MCS
NAVSSES 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
2011 #2& 87
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
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
Figure 4: Technology and Requirements Technology Transition
Flows in System Life Cycle Activities
NSWC
FLEET
LCM
Warfighter Technology Needs
88 & 2011 #2
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.
Technology Development
NSWC
R&D ONR
Agent
NAVAL ENGINEERS JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
A Brief History Of The Navy’s Gas Turbine
Program and its Impact On Machinery
Control SystemTesting
Much 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.
NAVAL ENGINEERS JOURNAL
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.
FFG 7 Land Based Test Site
The 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
2011 #2& 89
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
Figure 5: Diagram of the DD 963 class
Engineering Control and Surveillance
System
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
90 & 2011 #2
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.
DDG 51and the Introduction of Software
Support
The 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
NAVAL ENGINEERS JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
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
NAVAL ENGINEERS JOURNAL
Figure 6: Diagram of the DDG 51
Machinery Control System
 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
2011 #2& 91
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
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.
DDG Modernization
Starting 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.
92 & 2011 #2
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.
DDG 51: Software Support and the Capability
Maturity Model
Six 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 JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
 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
NAVAL ENGINEERS JOURNAL
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.
CMMI
As 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.
Supporting MCS In-service Engineering and
Software Support Beyond the DDG 51Class
For 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
2011 #2& 93
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
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.
Standardized Monitoring and Control
System, Smartship, and Integrated Ship
Controls
The 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.
94 & 2011 #2
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.
On Board Trainer
The 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
NAVAL ENGINEERS JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
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.
LPD17 Engineering Control System
Similar 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.
DDG1000
The 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
NAVAL ENGINEERS JOURNAL
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 Classes
NAVSSES 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.
MCS Modernization Programs
Modernizations 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
2011 #2& 95
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
give the reader a sense of what NAVSSES does
for modernizations of the MCS.
MCM-1Class Integrated Ship Control System
In 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
Figure 7: ISCS Hardware Location
96 & 2011 #2
 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.
NAVAL ENGINEERS JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
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 Software
The ‘‘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
NAVAL ENGINEERS JOURNAL
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
2011 #2& 97
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
Figure 8: MRG View
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
98 & 2011 #2
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 Integrated Machinery Control
System
Following 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
NAVAL ENGINEERS JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
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
CVN Machinery Control Systems
NAVSSES 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)
NAVAL ENGINEERS JOURNAL
Figure 9: Ships Service Air System View
 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.
Distributed Data and Control Network
Machinery Control System
The Distributed Data and Control
Network (formally known as ‘‘Integrated
2011 #2& 99
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
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).
CVN Smart Carrier Machinery Control System
Recognizing 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
100 & 2011 #2
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
NAVAL ENGINEERS JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
Figure 10: Smart Carrier MCS Block Diagram
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
NAVAL ENGINEERS JOURNAL
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
2011 #2& 101
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
Figure 11: PLC Group
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
Figure 12: Commu-
nications Flow
102 & 2011 #2
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.
CVN 78 Machinery Control System
A 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 Class Machinery Control System
The 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
NAVAL ENGINEERS JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
Figure 13: LSD MCS Overview
(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).
NAVAL ENGINEERS JOURNAL
New LSD MCS
Like 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.
2011 #2& 103
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station

Figure 14: PLC PLC I/O enclosure. Each PLC receives inputs from
Enclosure
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

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
Figure 15: HMI
Computers
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 Control Console
(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

104 & 2011 #2 NAVAL ENGINEERS JOURNAL

 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
Figure 16: Quad Screen HMI
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) Machinery
Control Systems
For 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
NAVAL ENGINEERS JOURNAL
Endurance Class Cutter (WMEC-39) and
Off-shore Patrol Cutter (OPC).
National Security Cutter Machinery Control
and Monitoring System
NAVSSES 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
2011 #2& 105
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station

Figure 17: Dual- installed Main Propulsion Machinery

Monitor Pedestal
Control System (MPCMS) posed numerous
Console
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
non-hardened (same functionality of ship HW)
equipment. The objective of the HSI Lab is to test
The USCG tasked NAVSSES Philadelphia to
the entire functionality of the control system as a
design, develop, test and install a replacement
complete and integrated system. Tests are devised
for parts of the MPCMS.
to exercise every line of PLC and Console code.
Test equipment is connected to the PLCs to
NAVSSES is responsible to provide a new
simulate machinery and shipboard conditions.
machinery control and monitoring system to
replace the existing MPCMS installed on the
NAVSSES has developed and implemented a
USCG WMEC 270’ Class. Efforts are being
MCMS Life Cycle Management (LCM) Plan for
made to leverage off other NAVSSES Machinery
the entire NSC class. To date NAVSSES has
Control System (MCS) projects and retain
successfully delivered software updates to the
the existing MPCMS machinery control and
NSC-1 and NSC-2 ships. NAVSSES has also
monitoring functionality to decrease risk, help
provided for a technical refresh of computer and
alleviate program workload and costs and to
network components onboard these ships.
provide commonality of parts support with the
270’ Medium Endurance Class Cutter US Navy.
(WMEC-901) Machinery Plant Control And
Monitoring System Thirteen (13) WMEC 270’ ships and a Training
The U.S. Coast Guard (USCG) 270’ Medium Console currently located at Yorktown, Va. are
Endurance Cutter (WMEC) Class originally within the scope of this project.

106 & 2011 #2 NAVAL ENGINEERS JOURNAL

 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
ALEX HALEY Medium Endurance Class
Cutter (WMEC-39) Machinery Plant Control
and Monitoring System
The 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
NAVAL ENGINEERS JOURNAL
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
2011 #2& 107
The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
(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.
Conclusion
The 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
108 & 2011 #2
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.
ACKNOWLEDGEMENTS
The 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.
REFERENCES
Preisel, 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
NAVAL ENGINEERS JOURNAL
 The Evolution of Machinery Control Systems Support At the Naval Ship Systems Engineering Station
Engineers, Gas turbine and Aerospace and Aeroengine
Congress and Exposition, June 1989.
Hauschildt, M.R. and L.B. Ward, ‘‘U.S. Naval Machinery
Automation 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 DDG
Class: 16 Years of Lessons Learned,’’ ASNE Automation
and Control Conference Proceedings, December 2007.
Kraynik, D.A., R. Halpin, and J. Kitson, ‘‘Transitioning
from 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.
NAVAL ENGINEERS JOURNAL
AUTHOR BIOGRAPHIES
Mr. 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.
2011 #2& 109