ECU-flashning över UDS: så går omprogrammeringen till

Merparten av diagnostikkommunikationen handlar om att läsa: identifiering, felkoder, mätvärden. Flashprogrammering är den enda operation som ersätter den mjukvara en styrenhet kör — och den sker betydligt oftare än de flesta utanför området föreställer sig. Varje styrenhet programmeras i slutet av produktionslinan, programmeras om i verkstaden när en rättning eller en funktion släpps, och uppdateras i mjukvarudefinierade fordon trådlöst under hela sin livstid.

Komponenten som gör det här säkert är flash-bootloadern: ett litet, permanent resident program som äger flashminnet och avgör vad som får köras. Den är det första som exekverar vid uppstart, och den enda mjukvara som omprogrammeringen aldrig får skada — eftersom det är genom den allt annat återhämtar sig.

Omprogrammering över UDS (ISO 14229) är en bestämd koreografi. Den börjar redan före programmeringssessionen: i en utökad diagnostiksession (tjänst 0x10) kontrollerar testverktyget förutsättningarna — att fordonet står stilla och att spänningen är stabil — och tystar nätverket med CommunicationControl (0x28), som pausar den normala meddelandetrafiken, och ControlDTCSetting (0x85), så att resten av fordonet inte loggar fel medan en nod tystnar.

Sedan kommer själva sekvensen: gå in i programmeringssessionen (0x10), där exekveringen normalt lämnas över till bootloadern; lås upp med SecurityAccess (0x27), utbytet av seed och nyckel som grindar skrivvägen; radera det logiska målblocket med en raderingsrutin via RoutineControl (0x31). Nedladdningen är i sig tre tjänster — RequestDownload (0x34) anger minnesadress, storlek och dataformat, TransferData (0x36) flyttar avbildningen block för block bakom en blockräknare, och RequestTransferExit (0x37) avslutar överföringen. Till sist kör testverktyget verifieringsrutiner (0x31 igen) — en integritetskontroll av det som skrivits och en beroendekontroll av att kombinationen av block som nu ligger i flashminnet får köras tillsammans — innan en ECUReset (0x11) startar den nya applikationen.

Sekvensen ovan förutsätter att ingenting går fel. Serieproduktion förutsätter att allting förr eller senare gör det. Det som definierar en bootloader byggd för produktion är att en avbruten flashning — spänningsbortfall mitt i en radering, en kabel som dras ur mitt i en överföring — aldrig lämnar styrenheten död: den residenta bootloadern raderas aldrig, och vid varje uppstart validerar den applikationen innan den startas och stannar kvar i programmeringsläge när applikationen är ofullständig eller inkonsekvent. Återhämtningen är inbyggd i konstruktionen, inte hanterad från fall till fall.

Ytterligare två garantier skiljer produktionskonstruktioner från demonstrationer. För det första har många bootloaders ingen bestående kod alls för att skriva till flashminnet: flashdrivrutinen laddas ned till RAM när programmeringssessionen inleds och är borta efter återstart, så i normal drift finns helt enkelt ingen resident skrivväg till flashminnet. För det andra är verklig styrenhetsmjukvara inte en enda avbildning utan flera logiska block — applikation, kalibrering, datamängder — med beroenden sinsemellan, och bootloadern måste upprätthålla att felmatchade kombinationer aldrig körs. På produktionslinan ryms allt detta inom takttiden, så genomströmning är ett konstruktionskrav och inte en eftertanke.

Att låsa upp skrivvägen är inte samma sak som att lita på det som kommer genom den. En bootloader i serieproduktion verifierar avbildningens äkthet — signerad mjukvara, kontrollerad mot nycklar som bootloadern litar på — innan applikationen över huvud taget markeras som giltig, och moderna konstruktioner förankrar nycklarna i en hårdvarusäkerhetsmodul i stället för i mjukvara.

Diagnostikkanalen som bär flashsekvensen håller också på att säkras om: ISO 14229-1:2020 lägger till en Authentication-tjänst (0x29) med certifikatbaserad åtkomst vid sidan av det klassiska utbytet av seed och nyckel i 0x27. Den sidan av saken — ISO/SAE 21434, UN R155 och steget från seed och nyckel till certifikat — går vi igenom i Securing the diagnostic channel. Poängen här är att avbildningens äkthet och kanalens säkerhet avgörs inne i omprogrammeringssekvensen, inte skruvas på runt omkring den.

UN-reglemente nr 156 kräver ett Software Update Management System (SUMS) för typgodkännande av fordon: en process som vet vilka mjukvaruversioner som är kompatibla med vilka fordon, som skyddar uppdateringarnas integritet, som registrerar varje genomförd uppdatering och som identifierar mjukvarukonfigurationer — identifieraren RXSWIN finns till för precis det. ISO 24089 beskriver motsvarande ingenjörspraktik. Ramen spelar roll: en bootloader och dess verktygskedja byggs för att stödja den processen, och att stödja ett reglemente är inte ett påstående om certifiering.

Den obekväma upptäckten för många organisationer är att det svåra i R156 inte är uppdateringsmekanismen — det är dokumentationen. Att visa vilken mjukvara som körde på vilken enhet, när den ändrades och på vems godkännande är en diagnostikdisciplin: samma tänkande kring baslinjer och spårbarhet som programmering i slutet av linan och omprogrammering i verkstaden alltid har krävt, men nu som ett villkor för att få sälja fordonet. Omflashning slutade vara ett verktyg och blev en styrd process, och de organisationer som behandlar den så får ett betydligt enklare samtal med sin godkännandemyndighet.