Not that long ago, the USCGC William Chadwick (WPC-1150) had a problem. The same alarm on the machinery control system (MCS) had chimed over and over: ground fault, 440V distribution panel. Each time, Chief Electrician’s Mate Jack Watkins could see the needle on the switchboard's ground-current meter move, then return to zero, clearing the alarm after a little more than a minute—hardly long enough to do any troubleshooting. Although he eventually found the cause, he chased it fruitlessly for a month.
A three-phase heater in the galley’s dishwasher had corroded so badly that not only was one phase connected hard to ground, but it also had contorted and expanded such that Watkins and his third-class petty officer had to hook ratchet straps to the opposite bulkhead to pry it out of its housing. The heater would have shown clear signs of decay weeks before causing a “ghost ground,” but regular disassembly and inspection of a dishwasher is a poor use of an engineer’s time when the department faces bigger problems that could strand the cutter at the pier.
Advances in shipboard machinery control and monitoring have relieved much of the effort required to run a ship safely, but the latest versions of the cutter MCS should make greater use of state-of-the-market sensing and data-analysis tools to support a comprehensive reliability-centered maintenance program. As it stands, much of the valuable information from the machinery and alarm data simply ends up in the trash.
Looking at the data in new ways could inform when and to what extent certain equipment needs maintenance and would let operators find deficiencies before they become casualties. To do so requires “smart data,” and the Coast Guard has all the pieces in place to implement it. At the Massachusetts Institute of Technology (MIT), a group of researchers and Coast Guard officers has been studying the issue for almost 20 years. Within cutter product lines are groups dedicated to data analysis, and the Coast Guard Research and Development Center is working on it, too.
Analyze Smarter, Not Harder
Whereas “big data” often connotes a black-box machine-learning algorithm that uses lots of data to draw conclusions about what without showing why, analysis with smart data explains. Machine learning can support that end, but human operators gain an edge when they can readily draw conclusions from the physical meaning of the sensor streams.
Coast Guard cutters have more electronics and sensors on them than ever before. Typically, the ship’s MCS takes input from various sensors, presents the readings on a digital display, and saves the data locally so a technician can download it later if needed. All the while, alarms notify watchstanders when a parameter goes out of its acceptable range. It is a useful process, but it is essentially an electronic version of a watchstander checking if the needle on a gauge stays within the painted green region.
Such a system does a good job drawing attention to certain types of imminent casualties and saves considerable effort, but it does little to help watchstanders identify “soft faults,” plan maintenance activities, or find problems with auxiliary equipment that may not have sensors at all.1 Not to mention, every cutter still has a watchstander walking around with a clipboard and pen to check equipment that does not interface with the MCS as well as it should.
MCSs and even handwritten logs create troves of data representing most equipment on board, but, except for certain main propulsion data-analysis programs run by the Surface Forces Logistics Center (SFLC), rarely does that data get put to use; it takes too much work to collate and present in meaningful ways. The MCS often saves as little as one data point per minute, despite having a greater capacity. Some cutters can provide only wrinkled, oil-stained sheets of paper with numbers scrawled down at most once per hour.
Only after formatting the digital files or manually transcribing the logs can SFLC begin its analysis. Outside of annual full-power trials, SFLC must collect data the hard way: by asking cutters one by one to extract it from MCS or to scan their logs. It is a lot of effort for a short-staffed workforce, so MCS data often just gets deleted when the cutter’s hard drive fills up without ever contributing its full value. As for the paper logs, they get destroyed after gathering dust in a filing cabinet for three years.
The Real Cost of Monitoring
Some equipment is monitored intermittently and some continuously. Given the cost and maintenance demands of sensors, generally only critical machines with quick or hard-to-predict failure modes warrant continuous monitoring. Other valuable machines get intermittent monitoring if their failure modes develop gradually.2
The intermittent monitoring some machines get is so infrequent they might as well not be monitored at all. For them, formal monitoring of any kind has not been worth the trouble, even on newer fast response and national security cutters. Heaters, pumps, motors, and other auxiliary machinery often fit this description, and watchstanders must do the monitoring themselves on their rounds.
This may have made sense in the past, but not today. Ships are too complicated and watchstanders too valuable to justify checking on things the old-fashioned way when better methods exist.
The dishwasher heater issue on the William Chadwick showed how one such machine can waste time. Other machines can cause catastrophe, such as when the first indication of a problem is the fire alarm. For example, after the cutter Polar Star (WAGB-10) left dry dock in 2023, a lube oil heater on one of her engines caught fire after its flow switch stuck closed. Thankfully, a watchstander put out the fire. But the fact remains: Something “not worth monitoring” by conventional means could have dealt the coup de grace to the United States’ only heavy icebreaker—and potentially every other ship in the fleet has dangerous flaws that pose similar risks.
You Have to Manage What You Measure
Cutters are complicated, expensive, and dangerous. Practical data analytics and lightweight sensing technology can make life easier, safer, and less tedious for all concerned, especially the petty officers in the engine room. But, for the Coast Guard to use them, some practicalities must be addressed.
The first step is to build the right digital infrastructure. Inside an integrated data environment (IDE), a few clicks can grant access to a platform in which users and engineers can examine and manipulate data from all available sources.3 An IDE would give shipboard engineers and offsite technicians real-time information to troubleshoot and maintain complex equipment from anywhere in the world, provided the system adheres to cybersecurity standards.
In the conventional “platform-as-a-service” network model, nodes at the system’s edge (a cutter, for example) only collect and transmit data. Data processing and storage are done centrally (at SFLC, for example), which limits the immediate value of the cutter’s data when reliable, high-bandwidth communication is not available.
To address this, U.S. Naval Academy professor John Donnal created a decentralized data-processing network—Wattsworth—while studying at MIT.4 Each Wattsworth node can store locally generated data, run the necessary processing and presentation software, and allow other nodes secure access to it. Some call this “fog computing” (in contrast to “cloud computing”). Wattsworth improves cutters’ data self-sufficiency while also allowing the data to be shared securely. Following recent Starlink internet upgrades on many cutters, connectivity can be more than adequate to support a Wattsworth system.
Insight from Electrical Power Data
Energy scorekeeping is a new frontier in shipboard monitoring. This method looks for trends in energy consumption to verify a given piece of machinery works as the operator intends.5
A largely untapped means to that end is to examine systemic electrical power data. Whereas an MCS focuses on a distributed sensor network and records only a few broad metrics about the electrical distribution system, nonintrusive load monitoring (NILM) systems collect high-resolution electrical power data from a single point upstream of the loads to grant operators a systems-level view of the plant.6 With data processing, NILM systems can pick out not only what draws power at a given time, but also how well it works. In this way, continuous monitoring of run-to-break machines, such as lube oil heaters and dishwashers, becomes practical, saving effort and possibly avoiding disaster. If a NILM system had sensed one of the Polar Star’s lube oil heaters was on but its prelube pump was off, it could have alerted watchstanders before the heater failed. It can be that simple. Advanced algorithms and machine-learning tools can expand the capability further.7
The Coast Guard has had a special relationship with Professor Steve Leeb and the MIT Research Laboratory of Electronics. Coast Guard officers seeking graduate degrees at MIT often work as research assistants for Professor Leeb, a pioneer of NILM and energy accountability techniques. Consequently, a large share of NILM research in recent years has been conducted on Coast Guard cutters to solve Coast Guard problems, and several cutters in District 1 have served as proving grounds for NILM technology.8
Two Coast Guard vessels homeported in Boston currently have prototype NILM systems installed on board: the fast-response cutter William Chadwick and the patrol boat Sturgeon (WPB-87336). The icebreaking tug USCGC Thunder Bay (WTGB-108), the Marlin (WPB-87304), and some medium-endurance cutters also have had them at one time or another. On these vessels, NILM systems have diagnosed faults as diverse as corroded jacket water heaters, leaky valves, degraded motor couplings, and bad MCS sensors. One failure on the cutter Spencer (WMEC-905) nearly started a fire, but the NILM system detected the fault before it could.9
Putting It All Together
Instead of compelling a crew to become proficient in yet another complicated system, which would only feed “the elephant in the engine room,” accessible data can become as much a training aid as a troubleshooting tool.10 The purpose of a Wattsworth network is to collect and process data to provide insight conveniently. The more that operators engage with it, the more they will understand how their equipment should work—and how they can affect those operations.
It will take time to build the habits and thought processes necessary for these new tools to play a part. The Coast Guard Research and Development Center has already started. Its projects 9204 and 1030 consider how to handle engineering data and use it to inform condition-based maintenance.11 As shipboard computers become more capable and cutters correspondingly more complex, it will become ever more important to innovate the Coast Guard’s watchstanding and maintenance practices.
Chief Watkins helped install the NILM prototype on the William Chadwick, and he spoke with Coast Guard MIT grad students about their work. The next time the students came on board, he demonstrated the dishwasher heater issue. The students connected NILM sensors to the galley’s power panel and induced the ground before Chief Watkins replaced the heater.
Back in the lab, the students put the data in Wattsworth and graphed the electrical power data against the MCS ground-fault alarm (see figure on p. 26). With those two information streams on the same screen, the offending equipment showed clearly. The power signature of the dishwasher looks different from everything else on board. As soon as it was turned on, current began leaking to ground, and the MCS ground-fault alarm activated. Once the unit was turned off, the ground fault disappeared, and the alarm cleared. No flipping breakers, no staring at the switchboard, and no time wasted. All it took to find was five minutes using the right tool.
1. A soft fault can occur when automatic control systems cover up deficiencies, such as when a compressed air system has a leak but maintains pressure by running the compressor more often than it should.
2. Robert Randall, Vibration-Based Condition Monitoring: Industrial, Automotive, and Aerospace Applications 2nd ed. (New York: Wiley, 2021).
3. LTJG Evan Twarog and LTs Joseph Kidwell and Caleb James, USCG, “The Path to a Data-Driven Coast Guard,” U.S. Naval Institute Proceedings 147, no. 8 (August 2021).
4. John S. Donnal, “Wattsworth: An Open-Source Platform for Decentralized Sensor Networks,” IEEE Internet of Things Journal 7, no. 1 (January 2020).
5. Andre Aboulian et al., “NILM Dashboard: A Power System Monitor for Electromechanical Equipment Diagnostics,” IEEE Transactions on Industrial Informatics 15, no. 3 (March 2019): 1405–14.
6. Daisy Green et al., “NILM dashboard: Actionable Feedback for Condition-Based Maintenance,” IEEE Instrumentation & Measurement Magazine 23, no. 5 (August 2020): 3–10.
7. Daisy Green et al., “Adaptation for Automated Drift Detection in Electromechanical Machine Monitoring,” IEEE Transactions on Neural Networks and Learning Systems 34, no. 10 (October 2023): 6768–82.
8. For information about the Thunder Bay, see Andrew Moeller, Extracting Electromechanical Signals for Icebreaker Operations (master’s thesis) (Cambridge, MA: Massachusetts Institute of Technology, May 2022). For the Marlin, see Isabelle Patnode et al., “Shipboard Microgrids and Automation,” Naval Engineers Journal 135, no. 3 (September 2023).
9. David Chandler, “Energy Monitor Can Find Electrical Failures Before They Happen,” MIT News Office, 21 March 2019.
10. CDR Kelsey Barrion, USCG, “The Elephant in the Engine Room,” U.S. Naval Institute Proceedings 149, no. 8 (August 2023).
11. A. Arsenault, “U.S. Coast Guard FY24 RDT&E Project Portfolio.”
