Vad är fordonsdiagnostik? UDS, ODX och DoIP förklarade

Fordonsdiagnostik är arbetet med att identifiera, läsa av, konfigurera och programmera om de styrenheter (ECU:er) som styr ett fordon. Ett modernt fordon är ett nätverk av datorer, och diagnostiken är gränssnittet mot dem: den svarar på vad som är fel, vilken mjukvara som körs, och vad som behöver ändras.

Disciplinen delar sig rent i två domäner. On-board-diagnostik är vad fordonet gör med sig självt: mjukvara inuti styrenheterna övervakar givare, ställdon och delsystem löpande, lagrar felinformation och varnar föraren när det behövs. Off-board-diagnostik är allt som görs utifrån, med ett externt testverktyg — identifiering av styrenheter, avläsning och radering av felkoder, parametrering och kodning, och omprogrammering i fält.

Det enklaste sättet att hålla isär dem: on-board svarar på frågan ”är något fel?”, off-board svarar på ”vad exakt är fel, varför, och vad ska vi göra åt det?” Båda behövs, men de byggs av olika människor, mot olika standarder.

Nej, och det är en vanlig förväxling. OBD-II är en smal, utsläppsdriven regelstandard — den kom ur amerikansk lagstiftning (CARB och EPA) för modellår 1996, definierar kontakten SAE J1962 och den varningslampa i instrumentpanelen som formellt heter MIL. Den finns för att en myndighet ska kunna kontrollera avgasrelaterade fel.

OBD-II är alltså en delmängd av on-board-sidan, inte hela diagnostikbilden. Det djupa arbetet — att identifiera varje styrenhet, koda varianter, läsa tillverkarspecifika felkoder och programmera om mjukvara — ligger på off-board-sidan och styrs av andra standarder.

UDS, Unified Diagnostic Services, är det standardiserade protokoll ett testverktyg använder för att prata med en styrenhet — för felsökning, konfiguration, avläsning av data och omprogrammering. Det definieras av ISO 14229, med det protokolloberoende applikationslagret i ISO 14229-1.

Modellen är strikt klient–server: verktyget skickar en förfrågan och styrenheten svarar med exakt ett svar, styrt av en tjänsteidentifierare på en byte. Vilka tjänster som är tillgängliga avgörs av vilken session som är aktiv — standardsessionen (0x01) gäller vid uppstart och exponerar en begränsad, säker uppsättning, den utökade sessionen (0x03) öppnar full diagnostik och konfiguration, och programmeringssessionen (0x02) aktiverar omprogrammering. Sessioner som inte är standardsessionen tar slut om bussen tystnar, så verktyget skickar TesterPresent (0x3E) med jämna mellanrum för att hålla dem vid liv.

De tjänster som används mest i praktiken: 0x22 och 0x2E för att läsa och skriva via dataidentifierare, 0x19 och 0x14 för att läsa och radera felkoder, 0x27 SecurityAccess och 0x29 Authentication för att låsa upp, och 0x31 RoutineControl för att starta rutiner i styrenheten. Vi går igenom protokollet i detalj i UDS (ISO 14229) explained.

UDS låter ett verktyg prata med en styrenhet, men säger ingenting om vad det ska säga. Det är ODX som stänger den luckan. ODX, Open Diagnostic data eXchange, är en XML-baserad datamodell som beskriver allt ett verktyg behöver för att diagnostisera en styrenhet: tillgängliga tjänster, strukturen på förfrågningar och svar, felkoder, data- och identifieringsparametrar, data för variantkodning och kommunikationsparametrar.

Den är standardiserad som ASAM MCD-2 D av ASAM och som ISO 22901-1 av ISO; den formatversion som används brett är ODX 2.2. Uttryckt enkelt: UDS är språket, ODX är ordboken och parlören — ett verktyg behöver båda. PDX är det paketformat beskrivningen levereras i.

Att beskrivningen är verktygsoberoende är inte en teknikalitet utan en inlåsningsfråga. Ligger era diagnostikdefinitioner bara i ett leverantörsspecifikt format är ni bundna till det verktyget så länge plattformen lever. Vi går igenom formatet i What is ODX?

DoIP, Diagnostic communication over Internet Protocol, är det standardiserade sättet att bära diagnostikmeddelanden över ett IP-nät i stället för över en fältbuss. Det definieras av ISO 13400, med transport- och nätverkslagret i ISO 13400-2 (nuvarande utgåva 2019) och Ethernet-fysiken i ISO 13400-3.

Det viktiga är att DoIP är en transport, inte ett nytt diagnostikspråk. Det ersätter den CAN-baserade transporten med TCP/IP och UDP/IP över fordonsethernet, medan tjänsterna ovanpå fortfarande är UDS — samma förfrågningar, samma svarskoder, samma sessioner. Flödet börjar med att fordonet annonserar sig över UDP på port 13400, följt av en TCP-anslutning och en routingaktivering innan någon UDS-trafik släpps fram.

En gateway eller DoIP-nod terminerar IP och vidarebefordrar meddelanden till styrenheter på CAN, CAN-FD, LIN eller FlexRay via logisk adressering. Och i och med att diagnostikkanalen därmed blir en nätverksändpunkt lade ISO 13400-2:2019 till TLS på port 3496 — ett skydd som kompletterar UDS 0x29 och kraven i UN R155.

Diagnostikmjukvara är den mjukvara som läser, uppdaterar, verifierar och spårar mjukvaran i fordonets styrenheter — dels on-board, som inbyggda komponenter i styrenheten, dels off-board, i de externa verktyg som används i utveckling, end-of-line-test och verkstad.

Tyngdpunkten i ingenjörsarbetet ligger på off-board-sidan, och skälet är livslängd. On-board-logiken följer styrenheten och ändras sällan. Off-board-sidan måste förbli korrekt över varje variant, marknad och mjukvarurevision i femton år eller mer efter att fordonet lämnat bandet — och när beskrivningen och verkligheten glider isär sker det tyst: varje verktyg nedströms läser fel värden, missar fel eller slutar kommunicera.

Diadrom har byggt off-board-diagnostik som disciplin sedan 1999, bevisat i serieproduktion hos Volvo sedan dess, och i dag rullar över 250 000 fordon med Diadroms diagnostik. Ska ni utvärdera en leverantör har vi samlat frågorna som avgör i att välja leverantör av diagnostikmjukvara.