When an automotive function stops working, we may be tempted to reason directly in terms of components: a sensor provides information, a control unit processes it and commands an actuator.
This representation is useful, but it quickly becomes insufficient on a modern vehicle. A function may depend on several local pieces of information, data from other control units, authorization or inhibition conditions, before producing a command that may itself be nothing more than information intended for another control unit.
The IPO model — Input, Processing, Output — represents this chain without assuming the order in which we should diagnose it.
Input: what the control unit knows
An input is not limited to the electrical signal from a sensor directly connected to the control unit.
It may be:
- an analog voltage;
- a logic state;
- a frequency or PWM signal;
- information received via CAN, LIN or another network;
- a request from another control unit;
- an internal state already calculated from several pieces of information.
The distinction is important.
Consider a function whose activation depends on engine temperature. The control unit that ultimately commands this function does not necessarily have the temperature sensor connected to one of its physical inputs. It may simply receive a temperature value transmitted over the network.
From a functional point of view, that temperature is still an Input.
We are therefore not only trying to determine which sensors are connected to the control unit, but what information it uses to make its decision.
Processing: between information and decision
This is probably the least visible part of the chain.
Receiving correct information does not necessarily mean that an output should be commanded.
The control unit may combine several conditions:
A AND B AND NOT C → command
The decision may therefore depend on several combined states (logic gates): some must be present simultaneously (AND), others may be alternative conditions (OR), while some states may instead prevent the command (NOT).
But processing is not necessarily limited to a few logic gates. It may also include thresholds, time delays, calculations, plausibility checks, operating strategies or degraded operating modes.
Correct Inputs → Output intentionally not commanded
without there necessarily being a fault on the output.
This is an essential distinction in diagnostics. Observing that a control unit is not commanding an actuator is not enough to conclude that its output stage is faulty. We must still determine whether, under the present conditions, the control unit should actually be requesting that command.
Some of the information required for this decision will be accessible in diagnostic parameters. Other information may not be.
We must accept this limitation: we do not necessarily see all of the Processing.
Output: what the control unit produces
An output can naturally be an electrical command: ground-side command, controlled supply, PWM, relay command…
But, as with inputs, limiting the notion of Output to pins that command actuators would be too restrictive.
A control unit can produce a calculated value, a state or a request that it transmits over a network.
That information is then its Output, even if no actuator is directly commanded.
And this is where the model becomes particularly useful in a distributed architecture.
An output can become the next input
Consider a simplified chain:
Sensor → ECU A → CAN → ECU B → LIN → ECU C → actuator
We no longer really have a single Input – Processing – Output set.
We have a succession:
I → P → O → I → P → O → I → P → O
Information measured by ECU A is processed and then published over CAN.
For ECU A, the transmitted message is an Output.
For ECU B, exactly the same information becomes an Input.
ECU B may combine it with other conditions, produce a new decision and in turn transmit a command to ECU C.
The function we observe at the end of the chain may therefore depend on a decision made several control units upstream.
This representation prevents us from confusing the place where the symptom appears with the place where the functional chain was interrupted.
IPO does not impose I → P → O on diagnosis
Describing a function in the direction Input → Processing → Output does not mean that we must systematically diagnose it in that order.
Depending on the symptom, the DTCs present, the available data and the first measurements, it may be much more relevant to start with an output, a communication point in the middle of the chain, or a point common to several functions.
If several actuators stop working simultaneously, investigating their inputs one by one would, for example, make poor use of the information provided by the symptom. Conversely, an absent output may lead us back toward the conditions that allow it to be commanded.
We can therefore work through the chain in both directions: I → P → O or O → P → I, and sometimes begin directly in the middle.
The value of IPO is then to distinguish three different questions:
- What information is available to make the decision?
- What decision should result from that information and the present conditions?
- What is actually produced at the output?
Conclusion
In a distributed architecture, these three questions can be repeated at every control unit through which the function passes.
IPO therefore gives us a representation of the functional chain, not an imposed test order. The symptoms, DTCs, our knowledge of the system and the measurements then determine where it is relevant to enter that chain and which direction to follow.