EC-14.5 Integration, and Why Systems Fail at the Joins

What this is and why it exists

Every part working alone and nothing working together is the most common state of a student project two weeks before the deadline.

The cause is almost always an interface that was never written down. That is why this topic sits after the architecture one and refers back to it.

Integrating incrementally is the single practice that prevents it, and it costs nothing except the restraint to resist connecting everything at once.

The vocabulary

• Incremental integration — adding one subsystem at a time, testing after each.
• Test harness — a stand-in that provides the inputs a subsystem expects.
• Root cause — the thing that, when fixed, stops the fault recurring.
• Emergent behaviour — behaviour of the whole system belonging to no single part.
• Handover — transferring a system with the information needed to continue it.

The mental model

Connect one subsystem at a time.

Connecting everything at once produces a system that fails for an unknown number of reasons simultaneously, and each fault masks the others. Adding one subsystem, testing, and then adding the next means every fault is found while it is still alone.

This is slower for the first hour and dramatically faster overall. It is also the practice most often abandoned under deadline pressure, which is exactly when its value is highest.

Six interface mismatches account for a large majority of integration failures, in student and professional work alike.

Units, where one side works in millivolts and the other in volts. Ranges, where one side can produce values the other cannot accept. Timing, where one side is ready before the other. Byte order, where a multi-byte value is assembled backwards. Voltage levels, where one side outputs three volts and the other expects five. And failure behaviour, where nobody agreed what happens when one side stops answering.

Every one of those is settled by writing the interface down, which is why the architecture topic insists on it.

A test harness lets a subsystem be tested before its partner exists. A short program or a simple circuit that produces the expected inputs is usually an hour's work.

It pays twice. It removes the dependency on the other team finishing. It also becomes the tool that isolates that subsystem during later fault finding, which is when you most want it.

Failure analysis has to reach a cause rather than a symptom. It stopped working is a symptom. The supply dipped below the brown-out threshold when the motor started is a cause.

The technique is to ask why repeatedly until you reach something that can be fixed. Then ask one more question. Could this same cause produce other faults we have seen? It very often can, and one fix then closes three tickets.

Emergent behaviour belongs to no single part and appears only at integration. A supply dip when two subsystems draw current together. Interference from a switching converter into an analog input. A shared bus that works with two devices and not with four.

None of these can be found by testing the parts separately, however thoroughly. That is an argument for integrating early rather than at the end, because these are the failures with the least time available to fix them.

Finally, the handover. Design files, test results, known faults, and the things you would do differently.

The known faults are the part people omit, and omitting them transfers the work while keeping the knowledge. A handover that hides what is broken is not a handover; it is a delay before the next person rediscovers it.

What you should now be able to explain or do

• Plan an integration so that each fault is encountered alone.
• Name the six interface mismatches and connect them back to the interface specification.
• Build a test harness so a subsystem can be tested before its partner exists.
• Drive a failure analysis to a cause and check whether it explains other faults.
• Recognise emergent behaviour and argue for integrating early because of it.
• Hand a system over including its known faults.

Check yourself