Why Control Systems Fail?

I’ve seen more outages caused by assumptions than by bugs. This was one of them.

During a recent onboard troubleshooting visit to a hybrid ferry, we had a situation where one generator was carrying around 96% load while supplying vessel loads and charging batteries.

A second generator was synchronized and connected to the bus.

Moments later, battery charging power increased. Then came the overload alarm. The PLC logic wasn’t broken.

It simply assumed: “Two generator breakers closed = two generators available.” But the second generator had only just connected. Load sharing hadn’t stabilized. The first generator was still carrying most of the load.

The code was correct. The assumption wasn’t. This is where automation engineering starts becoming systems engineering.

The real challenge isn’t programming inputs and outputs. It’s understanding system state.

A breaker closed doesn’t mean capacity is available. A pump running doesn’t mean process conditions are established. A motor enabled doesn’t mean torque is being produced.

The best engineers I’ve worked with think in: • Finite State Machines • State-Based Control Design • Systems Engineering • FMEA • HAZOP • Functional Safety • Supervisory Control Design

Because real systems don’t operate on signals. They operate on states, constraints, and transitions.

No amount of elegant code can compensate for a flawed assumption about how the system behaves.

The longer I work in automation, the less I worry about coding mistakes. We spend countless hours testing code. We spend far less time testing assumptions. That’s often where the real failure starts.

In your experience, what’s the most expensive assumption you’ve seen in a control system?