Diagnostics & Remote Service Safety

Because it is a command path, not a data port. A modern diagnostic interface can reset an ECU, suspend its normal communication, stop its fault recording, run routines that move actuators, rewrite calibration and variant coding, and accept new software. For most of automotive history the access path itself enforced the preconditions: the plug lived under the dashboard, using it needed a cable and a person, and the vehicle stood still. Those guards were geometry and habit rather than mechanisms, and Ethernet-based transport, service-oriented APIs and permanent connectivity removed them while the capabilities only grew.

The guide sorts them into six action classes because the hazard mechanism belongs to the class rather than to a service identifier. Reads mislead the decisions built on them and add load on shared compute. Persistent writes change function behaviour silently, with no fault stored, because nothing failed. Actuation routines and signal overrides move hardware now. Mode changes suspend communication, fault recording or the ECU itself. Software transfer replaces the behaviour the safety argument was made about. And fault-memory operations attack the evidence layer. The same classes reappear unchanged behind a service-oriented API, because a modern interface changes the envelope, not the physics.

Inside the ECU, on the ECU own view of vehicle state, with a result no client can override. A tester application may also check that the vehicle is stationary before offering a routine, and a good one does, because early feedback is better usability, but that check protects nothing: tester software crashes, ships with bugs, gets replaced by a third-party clone, or sits behind a connection that delays its view of the world. The guide layers three gates with different temporal scope, an entry gate, a per-request gate and a continuous monitor that revokes the capability the moment its justification disappears.

Three assumptions disappear at once. Presence: nobody competent is at the vehicle to see that a person leans into the engine bay or that the car started rolling, so every physical fact a technician verified by looking must come from vehicle sensors through the gates or be declared unavailable. Connection stability: a cellular link drops mid-anything routinely, so client disappearance becomes an expected operating condition with a defined vehicle-side answer per operation class. And exclusivity: concurrent clients are normal, so locks become vehicle-side leases that expire on silence rather than waiting for a client to come back.

Yes, whenever it shares resources with ASIL elements. On a vehicle computer a large diagnostic subsystem runs as software on the same compute, under the same operating system or hypervisor, as functions carrying ASIL ratings, and it is usually developed as quality-managed software because building a full web-API stack to an ASIL process would be neither proportionate nor honest. The criteria for coexistence of elements then give two options: demonstrate freedom from interference with the elements it shares resources with, or develop it to the highest ASIL of the requirements it can violate. There is no third option in which the stack is assumed harmless because it only reads data.

It runs 13 chapters as one arc: why the old implicit guards are gone, the classical service, session and fault-memory mechanics, what consolidation and service-oriented diagnostics change, the action-class to hazard mapping and its situation matrix, three-layer vehicle-state gating with defined session exit, envelope limits and dead-man release for routines, fault memory as safety evidence, local against remote access with connection-loss semantics and vehicle-side locks, containment on shared compute, authorization as a safety dependency with five gates in series, service as part of the safety lifecycle, an illustrative requirement set with traceability and fault-injection verification, and a closing gallery of anti-patterns with a ten-question decision checklist.