Over-the-air-update is de mogelijkheid die bepaalt of een ingezette vloot kan worden onderhouden of moet worden bezocht. Het is ook de mogelijkheid om een vloot offline te halen als deze onzorgvuldig is ontworpen.
De ontwerpvraag is niet hoe je een nieuw beeld moet opleveren. Dit is wat er gebeurt als de levering, verificatie of uitvoering mislukt van een eenheid op een locatie die niemand snel kan bereiken.
Dubbele afbeeldingen en terugdraaien
De veilige opstelling houdt een werkimage vast terwijl er een nieuwe wordt geschreven, en schakelt pas over als de nieuwe image is geverifieerd en heeft aangetoond dat deze kan worden uitgevoerd. Als dit niet lukt, keert de bootloader zonder tussenkomst terug naar het bekende goede beeld.
Dit beperkt de flash-grootte, en daarom is de OTA zowel een hardwarebeslissing als een softwarebeslissing en moeilijk toe te voegen aan een ontwerp dat daar niet op was voorbereid.
Verifieer vóór de uitvoering, niet erna
Een afbeelding moet worden geverifieerd en de integriteit ervan moet worden gecontroleerd voordat deze mag worden uitgevoerd. Verificatie na het opstarten is te laat: tegen die tijd is niet-geverifieerde code al uitgevoerd.
Ondertekenen geeft die garantie en verplaatst het beveiligingsprobleem naar de ondertekeningssleutel, waar deze thuishoort en dienovereenkomstig moet worden beschermd.
Sleutelbewaring is het moeilijkste deel
Dit is het deel van het OTA-ontwerp dat het vaakst onopgesteld blijft, en de consequenties als het fout gaat, zijn de ernstigste van alles in het updatepad.
- Wie heeft de signeersleutel, en waar.
- Hoe de toegang tot ondertekening wordt gecontroleerd en vastgelegd.
- Wat gebeurt er als de sleutel in gevaar komt, en of de vloot een nieuwe kan accepteren?
- Of een klant die een technologieoverdracht ondertekent de mogelijkheid krijgt om te ondertekenen, en onder welke voorwaarden.
Voer de uitrol uit
Het in één keer updaten van een hele vloot betekent dat een defecte release invloed heeft op alles tegelijk. Een gefaseerde uitrol, beginnend met een kleine groep en uitbreidend zodra deze stabiliteit vertoont, beperkt de schade.
Het bepalen van de omvang van de eerste groep, zodat een mislukking kan worden hersteld, en het definiëren van wat stabiliteit betekent voordat wordt begonnen, zijn de twee beslissingen die enscenering eerder nuttig dan ceremonieel maken.
Update nooit halverwege de sessie
Als een update wordt toegepast terwijl een voertuig aan het opladen is, bestaat het risico dat een sessie wordt onderbroken en de transactierecord verloren gaat. Het updatemechanisme moet worden uitgesteld totdat de connector inactief is, en moet een voertuig afhandelen dat verbinding maakt terwijl een update in behandeling is.
Op een drukke locatie mag een lader niet lang stil staan, waardoor het mechanisme ook beleid nodig heeft over hoe lang hij wacht en wat hij dan doet.
Onderbroken downloads en stroomuitval
De connectiviteit valt uit tijdens het downloaden en de stroom valt uit tijdens het schrijven. Beide moeten de oplader de bestaande image laten draaien, waarbij de gedeeltelijke download wordt weggegooid in plaats van als voltooid te worden behandeld.
De test die er toe doet, is het opzettelijk uitschakelen van de stroom op verschillende punten tijdens een update en het bevestigen dat het apparaat nog steeds opstart. Het is gemakkelijk te rennen en wordt zelden uitgevoerd.
Versietracking voor het hele wagenpark
Vloten verzamelen versies. Eenheden die offline zijn tijdens een uitrol, die onder garantie zijn vervangen of uit oude voorraad zijn besteld, komen terecht op builds die niemand volgt, waardoor foutpatronen onleesbaar worden.
Het rapporteren van de actieve versie en het afstemmen van wat is geïmplementeerd en wat de bedoeling was, is onderdeel van het updatesysteem en niet een afzonderlijk rapportageprobleem.