The Alarms That Didn’t Match What I Was Looking At

Every alarm that night pointed at the same source — Cylinder Control Unit 1, or CCU1, the electronic module that handles cylinder 1’s fuel injection, exhaust valve, and lubrication control — flagged as “Electrical Noise Detected.” I did what felt like the responsible first step: I called up the trend for FIVA setpoint and feedback, fuel plunger position, exhaust valve position, and tacho angle. All four looked like normal, repeatable cyclic operation. No dropouts. Nothing erratic or frozen. On a screen that clean, it’s easy to start building the case that the alarm itself is the faulty component, not whatever it’s supposed to be detecting.

I want to be honest that this felt like a reasonable place to stop. Those four channels are the ones any of us are trained to check first when something electrical trips on the engine control system, and they gave me nothing to work with. Multiple alarms in one night, all pointing at the same unit, is usually a strong signal on its own — a single trip is easy to write off as a transient, but a repeat pattern on one specific piece of equipment is the kind of thing that should hold your attention regardless of what the surrounding data shows. That repetition is the only reason I kept looking instead of closing the log entry after the first clean trend check.

What I Almost Got Wrong First

What stopped me was looking into exactly how the “Electrical Noise Detected” alarm is generated in the first place, rather than assuming it shared a data source with the channels I already had on screen. It doesn’t. On these engines, the alarm comes from a separate, dedicated high-frequency noise-sensing circuit built into the CCU — a small current loop running at 2 kHz, monitored through a capacitor in a specific connector, plug J35. None of the four trends I’d already checked touch that circuit at all. A clean FIVA or plunger trace says nothing about whether this specific detection loop is picking up noise, because it was never built to.

This is documented, known behavior on ME/ME-C/ME-B engines, not a quirk specific to our installation. MAN’s real Service Letter on the subject — SL2012-561/KBH, issued April 2012, “ECS Noise Detection Alarms due to Periodic 24-VDC Low Insulation” — describes the typical root cause plainly: chafed or pinched wire insulation inside an ECS junction box, where engine vibration lets a wire rub against the box, or a lid pinches a wire when it’s last closed, creating an intermittent short to earth on the 24 VDC ECS supply. It doesn’t cause a slowdown by itself. It’s an early warning. And worth knowing if you ever hit this yourself: MAN’s own letter states they offer free rectification kits for exactly this chafed-wire fault, which is worth requesting before sourcing parts yourself.

Finding Which Cylinder Actually Had the Problem

The correct next step wasn’t to start opening boxes. It was to rule out a shared cause first. I checked the Bender isolation monitor in PSU-A to confirm we weren’t looking at a permanent, global low-insulation fault across the whole system — we weren’t. From there, the localization method is simple in principle: compare the noise pulse counter on CH71 across every CCU on the engine, CCU1 through CCU10. If all ten show a similar counter rate, the fault is shared — something common like the 24V grid, the PDB, or the TSA-A/B boxes. If one CCU stands out well above the rest, the fault is local to that unit’s own wiring.

Every alarm that night had already pointed at CCU1. The counter comparison confirmed it wasn’t a coincidence of timing — CCU1’s count was well above every other cylinder’s, which were all sitting close together at a low, unremarkable baseline. I don’t think this step gets enough credit in how these investigations usually get told afterward. It’s not dramatic — it’s a counter comparison across ten near-identical readouts, most of them boring. But it’s the difference between opening ten boxes on a hunch, one after another, and opening exactly the one box that actually mattered, on the first attempt.

Working the Physical Fault Down

With the fault localized to CCU1, the next steps followed a set order rather than a hunch: check the junction boxes carrying cylinder 1’s FIVA tail, its fuel plunger sensor tail, and its exhaust valve tail first — the classic locations in MAN’s own documented failure examples, where an unsupported wire bundle rubs the inside of a box lid, or a wire gets pinched under the lid when it’s last closed. If nothing turns up there, open the CCU1 cabinet itself, where the MPC controller and its wiring terminations sit. If it’s still not found, widen the search to TSA-A/B, the PDB, the LOP, and the non-CCU cabinets. We didn’t have the dedicated MPC Earth-Finder tool MAN sells for this on board, so we worked it with an ohmmeter — checking from CCU to junction box, and junction box to sensor, one connection at a time.

While that search was still open, a completely different protection function tripped — the cylinder lubrication feedback sensor, on the same cylinder, and this one triggered an actual slowdown. That’s a different signal path from the noise-detection loop, but as the diagram above shows, it runs through the same CCU1 wiring — which meant it landing on the exact cylinder we were already investigating was not a detail I was willing to treat as background noise. At that point the night effectively split into two live problems running in parallel — the original noise investigation, still in progress and not yet localized to a specific wire, and now an active slowdown demanding an immediate response. The slowdown took priority, as it should have, but I made a point of not letting the noise investigation simply pause and get forgotten once attention shifted. I wrote down exactly where we’d gotten to before we turned to the lubrication fault, specifically so it wouldn’t need reconstructing from memory afterward.

The Fix That Looked Complete

We found the fault on the lubrication side, changed the lubricator, and the slowdown cleared. Everything looked back to normal — the engine running steadily, no active alarms, no active protection functions tripped. It was the end of a long night, and there was a real pull to close the whole thing out right there: two problems, both quiet now, log it and move on to the next watch.

I want to be honest that I came close to doing exactly that. The visible, dangerous symptom — the slowdown — was gone, and it had cleared the moment we’d changed a specific, identifiable part. That’s usually enough evidence to call something resolved. I think this is the harder mistake to catch, of the two in this story, because it doesn’t feel like a mistake while you’re making it. Dismissing an alarm off a clean trend at least has an obvious counterargument sitting right there — the alarm is still firing, so something is clearly still happening. Standing in front of a quiet engine at four in the morning, with the dangerous symptom gone and a real part changed to explain it, there’s no equally obvious prompt telling you to keep digging. The case looks closed because it genuinely looks closed.

The Question That Kept It Open

What stopped me was the fact I’d nearly let slide past: the electrical noise detection and the cylinder lubrication feedback are two different protection functions — but they run through the same CCU1 wiring for cylinder 1. A single chafed or pinched wire inside that wiring could plausibly produce noise pulses on one path and a corrupted feedback signal on another, purely by where the damaged section happened to sit. Changing the lubricator may have solved the failure that triggered the slowdown without touching whatever was actually chafing inside that wiring.

I also want to be honest that we never fully settled which specific component had actually failed — whether it was the feedback sensor itself, its connector, or the wiring running into the lubricator’s own control unit. “Changed the lubricator” and “found the exact failure point” are not the same finding, and I’d rather admit that gap than pretend the log entry was tidier than it was. So instead of closing the case, we kept watching the CH71 noise counter for CCU1 specifically over the following watches, to see whether it actually stayed flat rather than just assuming the visible fix had ended the story. We also made a point of running the engine through a full manoeuvring and load range rather than only steady conditions, since intermittent wiring faults driven by vibration or engine transients often stay hidden at a fixed, steady load — and a slowdown showing up during manoeuvring is exactly the moment it’s most dangerous.

None of this was about distrusting the fix we’d already made. The lubricator genuinely needed replacing, and the slowdown genuinely stopped because of it. What I was refusing to do was let one confirmed fix stand in for a second question I hadn’t actually answered yet — whether the wiring fault behind the noise alarms was still sitting in that CCU1 wiring, waiting for the next sensor on the same run to be the one that failed instead.

What I Changed Since

The CH71 count for CCU1 dropped and stayed flat through the following watches, close to the same low baseline every other CCU had shown all along — as much confirmation as anything at sea ever really gives you that a fault is actually gone, rather than just quiet for now.

• When two different protection functions trip on the same cylinder close together in time, I treat it as one investigation until proven otherwise, not two tickets closed independently of each other.
• I keep watching the actual diagnostic channel — not just the visible symptom — for a defined period after any fix, before I’ll call a fault genuinely resolved.
• I log precisely which component was the actual failure point when I can establish it, and I log the ambiguity honestly when I can’t, because pretending a fix was more precise than it was just sets up the next person to guess from zero.
• Before trusting a clean-looking trend screen to clear an alarm, I check what that alarm is actually built to detect — not every fault shows up on the channel watchkeepers are trained to look at first.
• I now keep short, structured checklists on hand for uncommon alarms, built ahead of time rather than reconstructed from memory at three in the morning, so a localization step like the CH71 comparison doesn’t get skipped under pressure.