Five Myths & a Spacecraft: Automation System Failures When Everyone Is Right

In 1999 NASA lost the Mars Climate Orbiter. The interface specification called for thrust impulse data in metric units. The ground software supplied it in English units. Both programs, examined alone, worked exactly as written — and together with broader assurance gaps, the mismatch contributed to losing the spacecraft.

Nobody made a mistake inside their own boundary.

That sentence is the subject of this article. It describes the interface failure above, it describes every myth in the list that follows, and it describes most of what goes wrong in a plant that is staffed by competent people. Correctness inside a boundary is not correctness. It is a local property being mistaken for a global one.

Five myths that are true inside a boundary

These get repeated on plant floors because they are comfortable, and because each is defensible if you look at only one layer.

”Pneumatics are fail-safe — the spring brings it home”

A spring-return actuator can be designed to reach a defined position on loss of air. That is an engineered outcome for a specific hazard, not a property of air.

Stored energy, friction, load, accessories and restart behavior all vote on the result. The safe state belongs to the complete installed function — derive it from the hazard analysis, then prove it under authorized isolation procedures. The actuator datasheet is correct about the actuator. It is silent about your installation.

”High-performance HMI means grey screens”

ISA-101 does not mandate a palette; the official series overview establishes no single mandatory color scheme.

What the standard asks for is a lifecycle: calm normal states, salience reserved for what needs action, meaning that survives without color, validated with real operators on real scenarios. A grey screen nobody tested is a beige version of the old problem — and teams routinely buy the palette while skipping the validation, which was the actual requirement.

”It supports OPC UA, so it will integrate”

A protocol name is not an interface contract.

Profiles, information models, versions, semantics, units, status handling and security all still have to match, and then be tested end to end on the configured products. Both vendors are telling the truth about their own compliance. Neither is making a claim about your data. “Vendor-neutral” describes the label.

”2oo3 voting is the safe choice”

Voting changes which failure combinations matter. It does not decide integrity.

Integrity belongs to the complete safety function — sensors, logic solver, final elements, common cause, diagnostics and proof testing — across its whole lifecycle, per IEC 61511. The voting architecture is a real engineering choice with real evidence behind it. It is simply not the thing that determines whether the function achieves what you need. 2oo3 is an option with evidence behind it, or it is a habit.

”The edge box can take over that interlock”

Proximity does not confer authority.

Qualified control and safety functions stay in their engineered, validated systems; edge platforms observe, buffer, mediate and analyze. That boundary is exactly what lets you use edge computing aggressively everywhere else — the discipline is what makes the freedom safe.

The interface nobody validated

Every plant has the Orbiter’s problem. Several instances of it, usually.

Controller to historian. MES to line. Vision system to PLC. Lab system to recipe management. Two teams, two documents, two sets of assumptions about units, ranges, scaling, sign conventions, timestamps, and what a “good” status actually means — each side correct in isolation.

The defense

It is unglamorous and it works:

1. 01
   Pick one critical interface

   One that carries a decision, not just a number on a screen.

2. 02
   Each side writes it down separately

   Producer team documents its units, ranges and update semantics. Consumer team documents theirs. No comparing notes.

3. 03
   Compare

   The gaps between the two documents are the defects, and they are cheap to fix on paper.

Step two is the whole exercise. Do it in a meeting and you get agreement — people converge on whoever speaks with most confidence. Do it separately and you get the truth.

Mismatches hide precisely where both sides are confident. A flow in cubic metres per hour read as litres per minute. A level in percent of a range that one side re-ranged two shutdowns ago. A timestamp one side believes is source time and the other believes is receipt time.

Each is invisible until the day it isn’t.

Verification and validation are not the same question

Verification evaluates whether specified requirements were met. Validation evaluates whether the result is suitable for its intended use within its declared context.

Both teams on the Orbiter verified. Each met its own specification. Nobody validated the pair — and validating the pair is a different activity, owned by a different person, requiring somebody to hold both documents at once.

That role frequently does not exist on a project org chart. Which is how a defect that either team could have caught in an afternoon survives to commissioning, or past it.

Why this keeps happening

Most of us learned this trade one layer at a time. You were the PLC person, or the instruments person, or the SCADA person, or the network person. The layer above and below arrived as tickets, not as context.

That worked for a long time. Then the decisions started crossing layers, and they have not stopped.

A controller choice changes engineering tools, I/O, network behavior, diagnostics, spares, and who can support it at 2 a.m. A historian compression setting, chosen by IT convention, quietly decides which process events an investigation can reconstruct three years later. An alarm philosophy shapes operator trust. A handover package — or its absence — determines whether the maintenance team inherits a plant or a mystery.

None of these is a single-layer decision. All of them land on whoever is standing closest when the consequence arrives, which in most plants is a maintenance engineer or an area manager who was never shown the whole map.

The map, not the layer

So the upskilling that pays is not deeper expertise in the layer you already know.

It is the lifecycle map: what your decision receives from upstream, what it commits downstream, and what evidence should exist at each seam. You do not need to run every layer. You need to know what each one owes the others, and what to ask when the answers seem missing.

That is a smaller skill than it sounds, and a rarer one. It is also the only reliable defense against a failure mode where everybody was right.

The engineers who build that view stop being the person who fixes what arrives, and start being the person who catches it two layers earlier, on paper, where it is cheap.

That is the whole trade.

Each myth above, the interface-contract method with its traceability requirements, and the ten-part lifecycle map are covered in Industrial Automation: Real-World Frameworks & Implementation Guide.