Title: Diagnostics & Remote Service Safety | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/diagnostics-remote-service-safety Description: The diagnostic connector is a command path, not a data port: UDS, DoIP and DTC mechanics, the shift to service-oriented diagnostics on vehicle computers, which read, write, routine and mode actions can violate a safety goal, and the vehicle-side gating, bounding, containment and evidence mechanisms that keep the path safe. --- Concept guide · ISO 26262 + ISO 14229 + ASAM SOVD · 13 chapters # Diagnostics & Remote Service Safety Follow the diagnostic path from a garage plug to a backend a continent away, and rebuild inside the vehicle every guard that geography and habit used to supply for free. 13 Chapters 6 Action classes 5 Gates in series 3 Access scenarios Included in Expert [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fdiagnostics-remote-service-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **Why Diagnostics Became a Safety Topic** 2. 02 **The Classical Stack: UDS, DoIP and DTCs** 3. 03 **What Changes on HPCs and Software-Defined Vehicles** 4. 04 **Which Diagnostic Actions Can Violate Safety** 5. 05 **Session and Vehicle-State Gating** The short version ## Quick answers Why is a diagnostic interface a safety topic at all? 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. Which diagnostic actions can actually violate a safety goal? 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. Keep going, free - [Demo exam · no account Test yourself with 7 exam-style questions](https://iso26262.academy/demo-exam) Why this course · ISO 26262 ## Why it pays for itself ### One mechanism chain, not scattered protocol trivia Gating, bounded actuation, fault-memory integrity, remote semantics, containment and authorization are built in the order a design needs them, so every chapter hands the next the mechanism it depends on. ### The mapping that turns a protocol into a hazard analysis Six action classes crossed against four operational situations, with the hazard mechanism and the vehicle-side control named per cell, plus the exposure reasoning that connectivity changes in an existing analysis. ### An integrity argument for the gate itself The interlock that prevents a diagnostic hazard is a safety mechanism whose failure enables it, so the guide writes the inherited integrity requirement down, with the decomposition option and the independence it demands. After the course ## What you’ll be able to do ### Treat the Tester as Untrusted Place every safety-relevant decision inside the ECU, on signals the vehicle owns, so no tool crash, third-party clone or delayed connection can talk a hazardous action into execution. ### Map Diagnostic Actions to Hazards Cross action classes against operational situations to find which requests can violate which safety goals, and argue the exposure shift that connectivity introduces into an existing analysis. ### Specify Bounded Service Actuation Write envelope limits, time bounds, abort trajectories and precedence rules per routine, so a service action stays inside the hazard analysis even when the client disappears mid-operation. ### Protect Fault Memory as Evidence Gate clearing and suppression, keep freeze frames until they are read out, and defend the field monitoring loop that tells an organization whether its safety concept assumptions hold. ### Argue Coexistence and Authorization Produce a freedom from interference argument for a quality-managed diagnostic stack on shared compute, and keep the ISO 26262 and ISO/SAE 21434 boundary clean with an assumption ledger instead of hand-offs. ### Build the Diagnostic Safety Case Write the requirement families a diagnostic function always needs, give the interlock its inherited integrity, and close each claim with fault injection, refusal-behaviour and interference evidence. The curriculum · 13 chapters ## Chapter by chapter 1. 01 **Why Diagnostics Became a Safety Topic** A diagnostic interface can reset an ECU, silence its communication, stop its fault recording, move actuators, rewrite calibration and accept new software. Three concrete stories show the harm landing later, in traffic, long after the tool reported success. - A command path, not a data port - Three eras, five broken assumptions - Where ISO 26262 touches the service path 2. 02 **The Classical Stack: UDS, DoIP and DTCs** The protocol mechanics every later argument stands on: the service set sorted by what it can do to the vehicle, positive and negative responses, sessions and the S3 timer read as a dead-man switch, the DTC status byte, and the DoIP and description-data layers underneath. - Services grouped into action classes - Negative response codes read through a safety lens - Sessions, S3 fallback and status-bit traps 3. 03 **What Changes on HPCs and Software-Defined Vehicles** Consolidation breaks four load-bearing assumptions of classical diagnostics at once, and service-oriented vehicle diagnostics is the industry answer: a self-describing web API, three named access scenarios, and a gateway with an adapter into the legacy world. - Where the UDS worldview cracks - Self-description and token-based access - One gateway, two protocol worlds 4. 04 **Which Diagnostic Actions Can Violate Safety** The systematic map: six action classes with six distinct hazard mechanisms, crossed against four operational situations, then run through Part 3 thinking to show how connectivity quietly rewrites the exposure column of old analyses. - Same request, two situations - The action-by-situation matrix - How remote capability moves exposure 5. 05 **Session and Vehicle-State Gating** The highest-leverage mechanism on the page: the precondition check runs inside the ECU on its own view of vehicle state, in three layers with different temporal scope, and every way out of a session lands in one defined, verified configuration. - Entry, per-request and continuous gates - Revocation when conditions change mid-session - Four exit paths, one restored state 6. 06 **Safe Actuation and Routine Control** The tester requests and the ECU executes, which is what makes bounding possible at all. Envelope limits enforced next to the output driver, time bounds that survive the tester vanishing, and abort behaviour treated as functional design rather than a stop flag. - Envelope, time bound, interruptibility - The heartbeat as a dead-man switch - Abort trajectories and actuator precedence 7. 07 **DTC Semantics and Fault-Memory Integrity** Fault memory is the evidence locker of the safety lifecycle, so writes to it are safety-relevant. Aging ends a fault story with the evidence intact; clearing tears the story out of the book, and suppressing updates leaves the vehicle driving with its recorder dark. - Freeze frames and extended data as context - Clearing and suppression as gated writes - Bookkeeping is not detection 8. 08 **Local Versus Remote Access** When the tester leaves the building, presence, connection stability and exclusivity leave with it. Locks become vehicle-side leases, connection-loss behaviour is written down per operation class, and a backend action is a loop over thousands of vehicles. - Vehicle-side lock lifetime - Connection-loss semantics per operation - Read widely, write narrowly, actuate exceptionally 9. 09 **Containment: Diagnostic Apps Next to Safety Functions** On a shared computer the diagnostic stack is a neighbour, usually developed as quality-managed software, sitting beside ASIL functions. The coexistence argument is an engineering deliverable, and the interference paths each need a named mechanism with evidence. - Timing, memory and information interference - Processes, hypervisors and containers compared - Snapshot reads and the request-flood budget 10. 10 **Authorization as a Safety Dependency** Three generations of proving who is asking, why scopes must be cut along the hazard boundaries, and the reason an unauthorized request reaching a safety-relevant function belongs in the safety analysis no matter how it got there. - Shared secrets, certificates, scoped tokens - Five gates in series, two owners - Fail-secure against fail-safe, designed out 11. 11 **Maintenance, Repair and Evidence** The operation-phase view: maintenance instructions derived from the safety concept, the field monitoring loop and the way clearing without reporting blinds it, post-repair verification instead of clear-and-hope, and repairs that succeed mechanically while leaving the vehicle unsafe. - The field loop and its blind spot - Prove the repair, not just the code - Mandatory recalibration after body work 12. 12 **Engineering the Diagnostic Subsystem to a Safety Standard** An illustrative requirement set for a remote-capable park brake service function, the argument that the gating interlock inherits the ASIL of the hazard it prevents, traceability from requirement to mechanism to evidence, and verification built on breaking things deliberately. - Gating, bounding, release, interference, integrity - Decomposition and its independence price - Fault injection on the diagnostic path 13. 13 **Pitfalls, Patterns and a Decision Guide** Nine recurring anti-patterns paired with the pattern that replaces each, the whole defence drawn on one page, and ten questions to answer before any diagnostic capability is exposed. - The anti-pattern gallery - Defence in depth on one page - A ten-question release checklist Built for ## Who this guide is for - Safety engineers who must decide which diagnostic capabilities may be exposed, and under which conditions - Diagnostic and platform developers implementing sessions, routines, IO control and fault memory in an ECU - Architects designing service-oriented diagnostics on a vehicle computer next to ASIL functions - Remote service and connected-vehicle teams enabling backend access to workshop capabilities - Assessors and reviewers reading a technical safety concept that includes a service path ## Frequently Asked Questions Common questions about Diagnostics & Remote Service Safety 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. ## Start the course today A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required. [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fdiagnostics-remote-service-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)