On-board vs off-board: deciding which side a function belongs on

The distinction itself is settled and not really in dispute. On-board diagnostics is software running inside the vehicle's ECUs, continuously monitoring sensors, actuators and subsystems and storing fault information. Off-board diagnostics is what an external tester does from outside — interrogating, configuring and reprogramming those same ECUs. We set that out in full in off-board vs on-board diagnostics, and the short version is that on-board asks whether something is wrong while off-board establishes exactly what, why and what to do.

The question that actually costs money is narrower and comes up hundreds of times per programme: given this specific function, which side does it belong on? Read a fault counter, run a calibration, reset an adaptation, unlock a variant, prove which software is installed — each of those can be argued onto either side, and each argument sounds reasonable in the room. The decision is usually made once, quietly, by whoever implements first. The platform then lives with it.

One test settles most of it: does the function have to work when nobody is connected? A vehicle in service spends effectively all of its life with no tester attached. Anything that must observe, react or record during that time has to run on the target. Continuous monitoring of sensors, actuators and subsystems, storing fault information for later retrieval, and warning the driver are on-board responsibilities by definition, because there is no external party present to perform them.

This is also why the emissions-era answer is not a general answer. OBD-II is a narrow, legally scoped window driven by emissions regulation, accessed through the standardised SAE J1962 connector, and it covers a small set of emissions-related parameters and trouble codes. It was never designed to expose the full behaviour of a modern vehicle's fifty-plus ECUs. Treating the on-board side as though it were OBD-II sized is the most common way this decision goes wrong early.

The mirror test is just as sharp: does the function change what the vehicle is? Writing a configuration value, coding a variant, calibrating a component or replacing the software in an ECU all alter the vehicle's identity and behaviour. Those belong off-board, behind authentication, with a record of what was done. Mechanically the pieces are familiar: configuration values are addressed by Data Identifiers, written with UDS service 0x2E and read back with 0x22, as defined in ISO 14229, while reprogramming is a defined sequence entered through the programming session and gated by SecurityAccess before any image transfers.

The second reason to put a function off-board is change. On-board logic ships with the ECU and rarely changes afterwards; the off-board side is expected to keep being corrected, extended and reissued for as long as the platform is in service. If a function's definition is likely to move — because the diagnosis improves, because a market differs, because a supplier revision lands — putting it off-board is what makes it maintainable at all. ODX (ISO 22901) exists precisely so that description can be versioned and exchanged rather than recompiled into a target.

In practice the decision comes down to four questions, asked per function rather than per system. First: must it work with no tester connected? If yes, it is on-board, and the discussion is over. Second: does it change configuration, calibration or software? If yes, it is off-board, and it needs authentication and a record — this is where the diagnostic channel stops being a convenience and becomes a security surface.

Third: is the definition expected to change after the vehicle ships? Anything likely to evolve should sit where it can be reissued, which is off-board. Fourth: who has to be able to run it, and where? A function needed by every workshop in every market has different reach requirements from one used on an end-of-line rig or an engineer's bench, and that reach is what determines transport and tooling — whether the answer is UDS over CAN, DoIP over Ethernet, or a remote connection. Ask those four and most functions place themselves; the ones that do not are exactly the ones worth escalating.

None of this is static. As function moves into high-performance computers and is updated continuously, the diagnostic interface has to become discoverable, service-oriented and remotely reachable while still serving the embedded ECUs that will populate vehicles for a long time yet. That is the shape SOVD describes: one uniform API above the vehicle, with an adapter mapping down to UDS underneath, so the same question — which side does this belong on? — gets asked again as the architecture changes.

Over-the-air updating is often mistaken for the boundary moving on-board. It is not. An over-the-air campaign is still an off-board function: it changes what the vehicle is. What it changes is the connection, not the responsibility. The authentication, the defined sequence and the record of which software ended up on which variant all still apply, which is why software identification across variants becomes harder rather than easier once updates go remote.

A boundary decision made by default is invisible for years and then expensive all at once. Put something on-board that should have been off-board and it cannot be corrected without touching the ECU software, so a diagnosis that turns out to be wrong stays wrong across the fleet until a software release can carry the fix. Put something off-board that should have been on-board and it simply is not there when it is needed, because no tester was connected at the moment that mattered.

Both failures land in the same place: the off-board side has to stay correct across every variant, market and software revision for fifteen years or more after the vehicle leaves the line, serving end-of-line testing, the dealer workshop, field campaigns and R&D validation from the same body of diagnostic data. That is the horizon the decision is really made against. It is also why we treat this as a toolchain question rather than a tool question — the argument we set out in choosing an off-board diagnostics toolchain.