Every component works. Yet the system fails.

No one made a mistake.

The hardware meets its specification. So does the firmware. So does the software. The communications work.

Every team can prove it.

And the whole thing is unusable.

This isn’t a paradox. It’s a systems problem.

Local compliance doesn’t guarantee the global result #

In the two previous Perspectives, we set out two ideas.

A symptom doesn’t necessarily reveal a problem’s origin. And a prototype that validates a hypothesis doesn’t automatically validate the product that follows from it.

There’s a less intuitive consequence: several perfectly compliant sub-systems can together produce non-compliant behaviour.

Take a deliberately simple example.

• A sensor provides a reading every 100 ms.
• A transmission can add 80 ms of latency.
• A software processing step needs 70 ms.

Individually, these three figures can each meet their specification perfectly. But if the use case requires a full response in under 200 ms, their combination can become incompatible with the real need.

No component is faulty. It’s the system’s temporal architecture that is.

Interfaces have behaviour too #

And timing is only one example.

Two components can use the same unit but not the same convention. An algorithm can assume a signal quality that the sensor only guarantees under certain conditions. A radio link can be excellent on the bench and disturbed once mechanically integrated. A perfectly functional system can become unusable simply because its user behaves differently from what was imagined.

This is where complex systems get interesting: some properties belong to no single component. They emerge from their interactions.

Change scale #

When a team has checked every component ten times without finding the problem, the eleventh check isn’t always the best use of its time.

It may be necessary to change scale.

• Observe the interfaces.
• Reconstruct the sequences.
• Measure the real conditions.
• Test the assumptions shared between teams.

And above all, come back to the most important question: “what behaviour do we actually expect from the complete system?”

Systems engineering doesn’t replace the specialist expertise. It lets you understand what appears when you assemble it. And sometimes the hardest problem to solve belongs precisely to none of them.

So far we’ve talked about systems where we know what they should do. But in R&D, things get stranger: sometimes we don’t even know yet whether what we’re looking for is possible.

Perspective 04 — next Monday: Experimental failure is data.

Sources #

• INCOSE — work on emergent behaviour in complex systems.
• NASA — Systems Engineering Handbook, system integration and validation.