Showcase: Fail-Safe (OTA) Field Updating

Eingebettete Systeme und IoT-Geräte robust und sicher im Feld updaten zu können ist heute eine Kernanforderung jedes Produkts. Das Update-Framework RAUC ist die Basis für eine moderne und zukunftsfähige Lösung. In diesem Showcase zeigen wir die Grundprinzipien eines ausfallsicheren Update-Systems und wie Sie dieses mit Unterstützung von Pengutronix für Ihre Plattform realisieren können.

Die grundlegenden Anforderungen an ein Update im Feld sind klar umrissen: Das Update soll ausfallsicher eingespielt werden (reliability), das Gerät muss dabei aber vor unbefugtem Zugriff geschützt bleiben (security). Je nach Einsatzbereich stammt das Update von einem lokalen Medium (z.B. USB-Stick) oder soll vollautomatisch über das Netzwerk ausgerollt werden (deployment).

Neben diesen naheliegenden Anforderungen gibt es jedoch noch eine ganze Palette weiterer Überlegungen und Entscheidungen, die in einer möglichst frühen Projektphase getroffen werden sollten und wesentlich über Erfolg oder Misserfolg des Projektes mit entscheiden. Dazu später mehr…

Atomare Updates (und Fallback)

Das Zauberwort für ausfallsicheres Updaten von Systemen lautet Atomizität. Das bedeutet: Es muss sicher gestellt sein, dass ein Update vollständig erfolgreich eingespielt ist, bevor es zur Nutzung freigegeben wird.

Um das sicher zu stellen, verwendet man redundate Boot-Partitionen (auch Dual-Copy- oder A+B-Ansatz genannt). Dabei werden zwei vollkommen gleichwertige Systempartitionen benutzt, um wechselseitig Updates durchzuführen. Von der aktiven Partition wird in die Inaktive geschrieben und diese erst nach erfolgreichem Abschluss des Schreibvorgangs als neue aktive Partition geschaltet. Die Umschaltung zwischen den Partitionen erfolgt dabei im Boot-Loader. Dies bietet auch einen Verfügbarkeitsvorteil: Das Update kann mit diesem Mechanismus problemlos im Hintergrund der laufenden Anwendung durchgeführt werden ohne diese zu unterbrechen.

Die Verwendung redundanter Partitionen erlaubt es dann optional, auch im Fehlerfall des aktiven Systems auf das inaktive System zurück zu fallen und so die Verfügbarkeit der Plattform deutlich zu verbessern.

Kryptographisch gesicherte Updates

Da das Update-System den Austausch der Systemsoftware ermöglicht, handelt es sich hier um einen besonders kritischen Bereich. Um nicht-autorisierten Personen den Zugriff auf das System zu verweigern, muss das Update bei der Erstellung kryptographisch signiert werden und vor der Installation vom Zielsystem verifiziert werden. Dafür eignen sich asymmetrische Methoden hervorragend, da hier nur die Schlüssel zum Signieren geheim gehalten werden müssen, während der Schlüssel zum Verifizieren ohne weiteren Aufwand auf dem Gerät abgelegt werden können.

Die Nutzung gängiger Standards wie X.509 erlaubt darüber hinaus prinzipiell komplexere Hierarchien mit Entwicklungs-Schlüsseln, Pro-Geräte-Schlüsseln, mehreren Signaturen, etc.

Weitere Anforderungen

Der Teufel steckt oft im Detail, und so verhält es sich auch mit der Entwicklung einer Update-Strategie. Die technischen Vorgaben wie Prozessortyp, und Speichertechnologie müssen ebenso berücksichtigt werden wie Anforderungen der Applikation und das Ökosystem in dem das Gerät eingebunden ist.

Typische weitere Fragen, die sich dann ergeben sind

  • Wie trennt man Daten und Logs vom Betriebssystem?
  • Wie migriere man Applikations-Daten nach einem Update?
  • Wie sieht eine sinnvolle Partitionierung des Speichers aus?
  • Ist es möglich den Bootloader sicher zu aktualisieren?
  • Wie soll sich das Gerät im Fehlerfall verhalten?
  • Wie erkennt das Gerät zuverlässig, dass ein Fehler vorliegt?

Wie können wir Ihnen helfen?

Unser Integrations-Team beleuchtet mit Ihnen zusammen die offensichtlichen und weniger offensichtlichen Fragen und Anforderungen an das Update-System und entwickelt zunächst ein grundlegendes Update-Konzept, dass im weiteren Projektverlauf nachgeschärft werden kann.

Mit RAUC gibt es bereits ein von Pengutronix gepflegtes und vollkommen als Open-Source lizenziertes Update-Framework als Ausgangspunkt. Dies erlaubt die Fokussierung auf das Wesentliche ohne das Rad neu erfinden zu müssen. Trotzdem ist die Abstimmung des Gesamtsystems auf die konkreten Anforderungen des Kunden und der Einsatzumgebung alles andere als trivial und umfasst die Konfiguration diverser Komponenten, die eng verzahnt ineinander greifen müssen.

Auf Basis Ihres Board Support Packages (BSPs) implementiert unser Integrations-Team ein redundantes Boot-Setup, konfiguriert alle notwendigen System-Komponenten und bereitet alles so vor, dass Update-Artefakte erzeugen und installieren können.

Benötigen Sie zusätzliche Funktionalität, die durch die existierenden Komponenten nicht oder nicht vollständig abgedeckt ist, so erweitern wir diese gerne für Sie. Das möglichst so, dass neue Features direkt in den Hauptentwicklungszweig der Projekte zurück fließen können und sich nicht als technische Schuld im Projekt anhäufen.

Im Rahmen der Klärung der Anforderung und dem konkreten individuellen Aufsetzten der grundlegenden Update- und Boot-Loader-Konfiguration unterstützt Sie Pengutronix unter anderem bei:

  • Anpassen des Boot-Loaders für redundante Boot-Partitionen (barebox, U-Boot, Grub, UEFI)
  • Initiales Konfigurieren von RAUC im BSP (Yocto, PTXdist, Buildroot)
  • Abstimmen des Watchdog-Verhalten
  • Klärung von Security-/Verifizierungs-Verhalten
  • Klärung verwandter Themen wie Konfigurations-Management, Daten-Migration etc.
  • Integration in Kundenapplikation / Anbindung an Deployment-Infrastruktur
  • Rückfragen im weiteren Verlauf

Die größten Fehler beim Design eines redundant bootenden Systems werden übrigens oft bereits in der Frühphase des Projektes gemacht. Gerne bewertet Pengutronix daher auf Basis von langjähriger Erfahrung für Sie schon 'von Anfang an', ob die gewählte Hardware und insbesondere die verwendete Speichertechnologie, das Power-Management oder der Prozessor, Risiken bergen.

Und warum RAUC?

Download

Das 1.5.1-Release von RAUC herunterladen

Mit RAUC steht ein modernes Open-Soure-Update-Framework bereit, dass durch effiziente Nutzung etablierter Bibliotheken wie glib, OpenSSL und curl eine schlanke und gut wartbare Codebasis bietet. RAUC teilt sich dabei auf in einen Service, der auf der Zielplatform läuft und dort die Update-Artefakte verifiziert und atomar installiert und einem Host-Tool mit dem die Update-Artefakte (Bundles) erzeugt werden.

Mit der Reduzierung auf das Wesentliche und der Bereitstellung sowohl eines Kommandozeilen-Tools als auch einer D-Bus-API lässt sich RAUC gut in bestehende Kundenapplikationen integrieren.

Eine der wesentlichen Philosophien von RAUC ist die Beschreibung des redundanten Boot-Verhaltens per Konfigurations-Datei direkt auf dem Gerät. Dies lässt nicht nur eine Introspektierbarkeit des Systems zu, sondern erlaubt auch generische Update-Artefakte zu erstellen.

Zusätzliche Features wie PKCS#11-Support für das Signieren von Bundles, Möglichkeiten der Neu-Signierung von Bundles oder das Unterbringen von Intermediate-Zertifikaten in Bundles erlauben es, den Sicherheitsanforderungen im professionellen Umfeld zu begegnen.

Für die im Feldeinsatz initial oft unterschätzten doch später oft dringend notwendigen Updates des Boot-Loaders bietet RAUC für viele Anwendungsfälle die Möglichkeit, diese ebenfalls vollkommen atomar durchzuführen.

Wie lassen sich OTA-Updates umsetzen?

Wenn im Unternehmen bereist eine Deployment-Infrastruktur vorhanden ist oder auf eine gehostete Lösung gesetzt werden soll, kann RAUC mit Hilfe eines einfachen Dienstes, der Anfragen der Infrastruktur annimmt und RAUC über D-Bus oder Kommandozeile aufruft, getriggert werden.

Für OTA-Update in eigener (self-hosted) Infrastruktur bietet sich das Open-Source-Projekt hawkBit an. Dieses bietet eine umfangreich konfigurierbare Lösung für Geräteverwaltung, Deployment-Scheduling und Feedback.

Die Anbindung an RAUC ist, dank existierender Clients im RAUC-Projekt, spielend leicht umzusetzen. Mit dem rauc-hawkbit-updater steht hier eine solide in C geschriebene Client-Komponente zur Verfügung, die mittels REST mit der Device (DDI) API von hawkBit und via D-Bus mit RAUC interagiert.

Zurück zur Messeseite

Weiterführende Links

Showcase: Continuous Testing

In den Linux-Kernel wandern jedes Jahr etwa 70.000 Patche, viele davon sind Bugfixes. Das Gleiche gilt für die meisten anderen Open-Source-Projekte, die Teil eines modernen Linux-Systems sind. Um von der Arbeit in der Community profitieren zu können, bleibt als sinnvolle Strategie, ständig auf dem neusten Softwarestand aufzusetzen und das System aktuell zu halten. Natürlich können bei dieser Menge an Änderungen auch neue Fehler hinzukommen oder Inkompatibilitäten entstehen.


Showcase: Embedded off-the-shelf

Ein Firmware-Upgrade ist fällig. Eine neu implementierte Funktion muss ausgerollt, eine Sicherheitslücke gepatcht oder neue Hardware-Unterstützung hinzugefügt werden. Die Software ist zwar leistungsfähig, aber komplex. Pengutronix' Strategie, mit dieser Komplexität umzugehen, ist die Arbeit an einem versionskontrollierten Board Support Package (BSP) mit kontinuierlichen Updates und Tests auf dem neuesten Mainline-Linux-Kernel.


Showcase: Remote Working

Zur Projektarbeit mit unseren Kunden gehört die Arbeit mit Prototypen-Hardware. Da wir grundsätzlich parallel für mehrere Kunden an vielen verschieden Projekten arbeiten, bedeutet das eine Flut von Prototypen auf den Schreibtischen unserer Entwickler. Spätestens wenn im Team an einem Prototypen gearbeitet werden soll oder längere Zeit nicht aktiv an einem Projekt gearbeitet wird, muss die Hardware regelmäßig umgezogen und am neuen Arbeitsplatz verkabelt werden. Erschwerend kommt hinzu, dass die Entfernung zwischen unseren Entwickler-Schreibtischen durch die aktuelle Homeoffice-Situation, nicht wie gewohnt in Metern, sondern in Kilometern gemessen wird.


Showcase: Preempt RT und Time Sensitive Networking

Heutzutage verfügen selbst einfache und günstige Mikrocontroller über ausreichend Rechenleistung, um zeitkritische Aufgaben im industriellen Umfeld zu bearbeiten. Sind jedoch die Aktoren und Sensoren in einer größeren Anlage verteilt und sollen mittels Ethernet vernetzt werden, ist der tatsächliche Verarbeitungszeitpunkt eines Ereignisses nicht ohne weiteres vorhersehbar. Linux mit Preempt RT und ein Netzwerk mit Time Sensitive Networking (TSN) Funktionalitäten kann hier Abhilfe schaffen.


Showcase: Grafik auf i.MX8MP

Die Inbetriebnahme der Grafikausgabepipeline auf dem i.MX8M Plus (kurz i.MX8MP) ist ein aktuelles Beispiel dafür, wie Open Source und Upstream-Treiber für GPUs und Displayeinheiten Aufwand und Risiko im Projekt reduzieren können.


RAUC v1.12 Released

With 93 pull requests that brought in 248 new commits, a lot happened since the last release on master (v1.11.1). The new v1.12 version of RAUC focusses on making it even more robust while adding some features and improvements.


RAUC v1.11 Released

Ho Ho ho! As the year's progress bar approaches 99%, another update is already completed: RAUC v1.11 is here!


Yes we CAN... add new features

Have you ever experienced an otherwise fine product that is missing just the one feature you need for your application?


DSA in Barebox

The v2022.05.0 Release of barebox introduced initial support for the Distributed Switch Architecture (DSA) Framework. DSA is originally a subsystem from the Linux Kernel, which exposes the individual ports of a network switch IC as virtual network interfaces.


First Steps using the candleLight

So you went and got yourself one of our fancy rocket-penguin branded CandleLight dongles or, being the die hard hacker you are, went and soldered one up in your toaster oven labeled "not food safe". What's next then? How do you use this thing? Let's answer these question by grabbing a Raspberry Pi and exploring some of the possibilities.