Over the air update för inbyggda Linuxsystem

Ola Redell 30 juni 2026

Att kunna uppdatera inbyggda system på distans har blivit en viktig del av modern produktutveckling. Produkter som tidigare levererades med fast programvara för hela sin livstid behöver i dag ofta kunna få säkerhetsuppdateringar, funktionsförbättringar och korrigeringar efter att de har tagits i drift. För företag som utvecklar elektroniska produkter med Linuxbaserad mjukvara är (F)OTA, eller Firmware over the air update, därför mer än en teknisk funktion. Det är ett sätt att underhålla, säkra och vidareutveckla produkten under hela dess livscykel.

I den här artikeln går vi igenom grunderna i OTA-uppdateringar för inbyggd Linux, hur olika arkitekturer som A/B-partitioner fungerar i praktiken, och hur du hanterar säkerhetsrisker (CVE) samt undviker de vanligaste fallgroparna vid implementeringen.

Vad är en OTA-uppdatering?

En OTA-uppdatering är en metod för att uppdatera firmware eller mjukvara på distans via ett nätverk, till exempel internet eller mobilnät. Det innebär att nya versioner kan skickas ut utan att enheten behöver tas in på service, anslutas med kabel eller bytas ut. På engelska används ofta begrepp som over the air update, firmware over the air update, OTA software update, FOTA update och embedded Linux OTA.

I praktiken handlar det om att skapa en trygg och kontrollerad väg för att uppdatera produkter som redan finns ute hos kund eller i fält. För produkter inom exempelvis medtech, fordonssystem, avancerade kameror och industriell utrustning kan OTA vara avgörande. Det gör det möjligt att hantera säkerhet, funktionalitet och regulatoriska krav även efter lansering.

En OTA-lösning består vanligtvis av tre delar:

  • Ett kontrollerat sätt att paketera firmware och mjukvara
  • En kanal för distribution till enheterna
  • Mekanismer i enheten för att ta emot, verifiera, installera och rulla tillbaka uppdateringen vid behov

OTA är alltså inte ett enskilt verktyg. Det är en kombination av infrastruktur, processer och kod i det inbyggda systemet.

Två medarbetare från Codiax i ett mötesrum.

FOTA update och OTA software update

OTA kan användas för olika typer av uppdateringar. En viktig skillnad är om det handlar om firmware eller mjukvara ovanpå operativsystemet.

FOTA update

En FOTA update, eller firmware over the air update, gäller de mer grundläggande delarna av systemet. Det kan till exempel handla om bootloader, kernel, root filesystem, BSP och andra hårdvarunära komponenter.

Den här typen av uppdatering kräver särskilt noggrann planering. Om något går fel kan systemet i värsta fall sluta starta. Därför behövs robust uppstartslogik, tydlig verifiering och möjlighet till rollback.

I inbyggda Linuxsystem innebär en firmwareuppdatering ofta att hela eller delar av systemimagen byts ut. För företag som bygger produkter på Linux blir embedded Linux OTA därför en viktig del av systemarkitekturen, och inte något som läggs till i efterhand.

OTA software update

En OTA software update gäller applikationer och tjänster ovanpå operativsystemet. Det kan exempelvis handla om användargränssnitt, backend-tjänster, AI-modeller eller produktspecifika algoritmer.

Här ligger fokus ofta på beroenden, datamigrering och kompatibilitet mellan olika versioner. Risken är vanligtvis lägre än vid firmwareuppdateringar, men uppdateringen behöver fortfarande testas ordentligt.

I många moderna produkter behöver OTA-systemet kunna hantera båda typerna. Ibland uppdateras bara applikationer. Ibland behöver både firmware och mjukvara ingå i samma release.

Embedded Linux OTA update i praktiken

En embedded Linux OTA update behöver anpassas efter produktens hårdvara, lagringsutrymme, uppkoppling och säkerhetskrav. Till skillnad från vanliga Linuxservrar eller datorer körs inbyggda Linuxsystem ofta i mer begränsade miljöer, där strömavbrott, svag uppkoppling eller begränsat minne kan påverka uppdateringen.

OTA-lösningen behöver kunna hantera exempelvis:

  • avbruten nedladdning
  • verifiering av uppdateringspaket
  • misslyckad installation
  • spänningsbortfall under installation
  • rollback till tidigare version
  • versionsspårning
  • säker uppstart efter uppdatering

För produkter med lång livscykel är detta särskilt viktigt. En robust embedded Linux OTA update gör det möjligt att hålla systemet säkert, kompatibelt och uppdaterat utan manuella ingrepp på varje enhet.

Säkerhet i OTA-lösningar

OTA-kanalen är en direkt väg in i systemet. Därför behöver säkerheten finnas med redan från början, både i arkitekturen och i arbetsprocessen.

Signering och verifiering

Firmware-imager och mjukvarupaket signeras kryptografiskt och krypteras. Enheten verifierar sedan signaturen innan uppdateringen installeras. Det minskar risken för att manipulerade eller obehöriga uppdateringar installeras i systemet. Kommunikationen bör också skyddas med säkra protokoll, till exempel TLS. Det gör att data inte kan manipuleras under överföringen och att enheten kan verifiera att uppdateringen kommer från rätt källa.

Vanliga OTA-arkitekturer i inbyggda Linuxsystem

Hur OTA-lösningen byggs upp beror på produktens krav, hårdvara och risknivå. Vanliga arkitekturer är A/B-partitioner, single partition med rollback och paketbaserade uppdateringar.

A/B-partitioner

A/B-partitioner, även kallat dual bank, är en vanlig lösning för FOTA update i embedded Linux.

Systemet har då två uppsättningar firmware, A och B. Uppdateringen skrivs till den inaktiva partitionen. Först när den nya versionen har verifierats och startat korrekt växlar enheten över till den nya versionen.

Om uppstarten misslyckas kan systemet automatiskt rulla tillbaka till den tidigare fungerande versionen. Det gör lösningen särskilt lämplig för produkter där driftsäkerhet är viktig.

Single partition med rollback

I enklare system används ibland en enda systempartition tillsammans med snapshot- eller backupmekanismer.

Det kan vara ett alternativ när lagringsutrymmet är begränsat, men modellen kräver tydliga rutiner för återställning. Om något går fel behöver systemet fortfarande kunna ta sig tillbaka till ett fungerande läge. Ofta löser man detta i Linuxsystem med ett minimalt fallbacksystem, tex baserad på en initramfs, som bara finns för att kunna installera det kompletta systemet.

Valet mellan A/B-partitioner och single partition påverkas bland annat av tillgänglig lagring, uppstartstid och hur kritisk produkten är i sin miljö.

Paketbaserade uppdateringar

I vissa fall används paketbaserade uppdateringar. Då uppdateras applikationer och tjänster via en pakethanterare, medan firmwaredelen uppdateras mer sällan.

Det kan ge mindre och mer flexibla uppdateringar för applikationslagret. Samtidigt krävs god kontroll över beroenden, versioner och kompatibilitet.

För mer komplexa produkter kombineras ofta paketbaserad applikationsdistribution med imagebaserade firmwareuppdateringar.

CVE-hantering över produktens livscykel

Linuxsystem bygger på FOSS, alltså fri och öppen källkod. Det ger stora möjligheter, men innebär också att nya sårbarheter, CVE:er, löpande kan publiceras för bibliotek, Linuxkärnan och andra delar av systemet.

Det behövs en tydlig process för att:

  • bevaka relevanta CVE:er
  • bedöma påverkan på den egna plattformen
  • ta fram uppdaterade imager eller paket
  • distribuera uppdateringarna via OTA-lösningen

På så sätt blir OTA ett praktiskt verktyg för att faktiskt få ut säkerhetsåtgärder i fält, inte bara identifiera risker i en rapport.

Codiax har lång erfarenhet av inbyggd Linux och CVE-hantering, och kan hjälpa till både med uppdateringsstrategi, implementation och löpande underhåll.

Vanliga fallgropar vid införande av OTA

Många problem uppstår när OTA läggs till för sent i utvecklingsprocessen. Uppdaterbarhet bör helst finnas med redan när systemet designas.

  • Systemet saknar uppdateringsstrategi

  • En vanlig fallgrop är att plattformen från början inte har designats för OTA uppdateringar. Det kan leda till för lite lagringsutrymme, olämplig partitionering eller avsaknad av säker bootlogik.  Att lägga till OTA i efterhand blir då ofta både tekniskt svårt och kostsamt. 

  • Bristande versionshantering

  • Utan tydlig versionshantering är det svårt att veta vilka kombinationer av firmware, applikationer och konfigurationer som faktiskt körs ute i fält.  Det försvårar felsökning, support och säkerhetsarbete. Ett OTA-system behöver därför kompletteras med bra spårbarhet och tydlig versionsinformation. 

  • Otillräcklig testning

  • OTA-uppdateringar behöver testas i realistiska scenarier. Det gäller särskilt uppdateringar som påverkar bootloader, kernel eller root filesystem.  Testningen bör omfatta både lyckade och misslyckade uppdateringar, till exempel avbruten nedladdning, strömavbrott, rollback och återstart. 

När passar en OTA-lösning?

En OTA-lösning innebär en initial investering, men kan ge stor nytta över produktens livscykel, inte minst under den tidiga utvecklingsfasen då systemen i labbmiljö uppdateras frekvent. OTA är särskilt relevant när:

  • många enheter är spridda geografiskt
  • fältuppdateringar är dyra eller svåra att genomföra manuellt
  • kraven på säkerhetsuppdateringar och compliance är höga
  • produkten ska leva länge och kunna få nya funktioner över tid
  • kunder eller myndigheter kräver möjlighet till uppdateringar

För enklare, kortlivade eller helt offlinebaserade produkter kan manuella uppdateringsstrategier ibland räcka. Men för uppkopplade produkter är OTA en självklar del av systemarkitekturen.

Codiax hjälper er med rätt lösning från början

En fungerande OTA-lösning handlar inte bara om att välja rätt verktyg. Den behöver passa produktens hårdvara, säkerhetskrav, utvecklingsflöde och underhåll. Codiax har lång erfarenhet av att utveckla inbyggda Linuxsystem för olika typer av produkter. Kontakta oss så hjälper vi er att bygga rätt från början!