Vad är UDS (ISO 14229)? En guide till tjänsterna

Unified Diagnostic Services (UDS) är det standardiserade protokoll för begäran och svar som ett testverktyg använder för att tala med en styrenhet (ECU) om felsökning, konfiguration, datautläsning och omprogrammering. Protokollet definieras av ISO 14229, där det protokolloberoende applikationslagret specificeras i ISO 14229-1. UDS ligger medvetet ovanför transport- och nätverkslagren, och det är därför samma tjänstedefinitioner gäller vare sig styrenheten nås över CAN eller Ethernet.

Modellen är strikt klient-server. Testverktyget (klienten) skickar en begäran; styrenheten (servern) svarar med exakt ett svar. I normal drift förekommer inga oombedda meddelanden från servern. Varje begäran inleds med en tjänsteidentifierare (SID) på en byte som säger vad som efterfrågas; allt därefter är parametrar som hör till just den tjänsten. Det är den enkelheten som gör UDS möjligt att implementera på resurssnåla målsystem och konsekvent genom ett helt fordonsprogram.

Hur UDS beter sig styrs av den aktiva diagnostiksessionen, som hanteras med DiagnosticSessionControl (SID 0x10). Standardsessionen (0x01) är alltid aktiv vid uppstart och exponerar en begränsad, ofarlig uppsättning tjänster. Den utökade sessionen (0x03) låser upp fylligare diagnostik och konfiguration, och programmeringssessionen (0x02) aktiverar tjänsterna för omprogrammering. Underfunktioner väljer vilken session man går in i, och ett positivt svar returnerar de tidsparametrar testverktyget måste hålla sig till.

De flesta sessioner utöver standardsessionen löper ut om bussen tystnar, varpå styrenheten återgår till standardsessionen och tappar allt upplåst tillstånd. För att hålla en session öppen under långa operationer skickar testverktyget med jämna mellanrum TesterPresent (SID 0x3E), oftast med biten suppressPositiveResponse satt så att livstecknet inte genererar någon svarstrafik. Att få den tidsättningen rätt är en vanlig källa till fältproblem: tappar man livstecknet mitt i en flashning faller styrenheten tillbaka till ett säkert läge.

Dataåtkomsten är vardagens arbetshäst. ReadDataByIdentifier (SID 0x22) läser ett värde som adresseras med en dataidentifierare (DID) på två byte — allt från chassinummer och artikelnummer för mjukvara till levande sensorsignaler. WriteDataByIdentifier (SID 0x2E) skriver kodning och konfiguration till en DID. För felhanteringen hämtar ReadDTCInformation (SID 0x19) felkoder med deras status, ögonblicksbild och utökade data, medan ClearDiagnosticInformation (SID 0x14) raderar lagrade felkoder.

Två tjänster står som grind framför de känsliga operationerna. SecurityAccess (SID 0x27) kör en utmaning med seed och nyckel baserad på symmetrisk kryptografi för att låsa upp skyddade funktioner. Den nyare tjänsten Authentication (SID 0x29), som infördes i ISO 14229-1:2020, lägger till certifikatbaserad, asymmetrisk autentisering med PKI för starkare förtroende. RoutineControl (SID 0x31) startar, stoppar och läser resultatet av rutiner som körs i styrenheten, till exempel radering av minne, kontrollsummeverifiering eller självtest av ställdon.

Att flasha om en styrenhet är en bestämd koreografi snarare än en enskild tjänst. När programmeringssessionen är aktiv och SecurityAccess är passerad skickar testverktyget RequestDownload (SID 0x34) för att ange måladressen i minnet och den okomprimerade storleken på avbildningen. Styrenheten svarar med den största blocklängd den accepterar per överföring.

Därefter strömmas avbildningen med upprepade TransferData-begäranden (SID 0x36), där varje begäran bär en blockräknare och en del av nyttolasten, anpassad till den överenskomna maxstorleken. När sista blocket är skickat avslutar RequestTransferExit (SID 0x37) överföringen så att styrenheten kan färdigställa och validera det skrivna. En bootloader och en robust implementation av just den här sekvensen är vad som skiljer en rutinuppdatering från en förstörd styrenhet ute i fält; Diadroms Autotech Bootloader och DCS-stack finns till precis för att göra sekvensen pålitlig.

Ett lyckat svar upprepar begärans SID med 0x40 tillagt: en begäran med 0x10 kvitteras med 0x50, en 0x22 med 0x62, en 0x3E med 0x7E. Efter svarets SID följer eventuella returdata som hör till tjänsten, så ett testverktyg kan para ihop ett svar med sin begäran genom att titta på en enda byte.

En avvisad begäran ger ett negativt svar på tre byte: den fasta byten 0x7F, sedan den SID som avvisades, och sist en negativ svarskod (NRC). Koderna är standardiserade och värda att känna igen direkt, till exempel 0x11 serviceNotSupported, 0x7F serviceNotSupportedInActiveSession, 0x33 securityAccessDenied och 0x78 requestCorrectlyReceived-ResponsePending, som talar om för testverktyget att styrenheten fortfarande arbetar och att det ska fortsätta vänta i stället för att låta tiden löpa ut. Att läsa negativa svarskoder flytande är merparten av praktisk UDS-felsökning.

UDS bär i sig varken adressering eller segmentering, utan förlitar sig på ett transportprotokoll under. På klassisk CAN och CAN FD är det lagret ISO 15765-2 (ISO-TP, även kallat DoCAN), som delar upp nyttolaster större än en enskild ram i First-, Consecutive- och Flow Control-ramar, så att meddelanden på flera kilobyte kan färdas över en buss med åtta byte per ram.

När det behövs mer bandbredd, särskilt vid snabb flashning, körs UDS över fordonsethernet med Diagnostics over IP (DoIP), standardiserat som ISO 13400. DoIP lägger till upptäckt av fordon, ruttaktivering och ett ramverk för TCP/UDP, men UDS-tjänsterna ovanför är identiska med fallet på CAN. Den uppdelningen av ansvar är den verkliga styrkan hos ISO 14229: skriv diagnostiklogiken en gång, och den fortsätter att gälla medan fordonets nätverk utvecklas från CAN till Ethernet.