Design-Praxis / Embedded Software
OTA-Schnittstellen für µC-Apps
Fortsetzung des Artikels von Teil 3
Entwicklungskompromiss: Die Rolle des SSBL
Nach der ausführlichen Erläuterung des SSBL und seiner Beziehung zur Applikationssoftware stellt sich die Frage nach der Aufgabe des SSBL-Programms. Dieses Programm muss mindestens die aktuelle Applikation erkennen und dann zu dieser Adresse hin verzweigen. Der Ort der verschiedenen Applikationen im Speicher des Mikrocontrollers wird im Allgemeinen in einem Inhaltsverzeichnis (ToC, Table of Contents) hinterlegt (Bild 3).
Die ToC ist ein gemeinsam genutzter persistener Speicher, über den SSBL und Applikationssoftware miteinander kommunizieren. Am Ende des OTA-Update-Prozesses wird das Inhaltsverzeichnis mit den neuen Applikationsinformationen aktualisiert. Teile der OTA-Update-Funktionalität können auch in den SSBL geschoben werden. Zu entscheiden, welche Teile dies sind, ist eine wichtige Aufgabe bei der Entwicklung von OTA-Update-Software.
Der oben beschriebene minimale SSBL ist äußerst einfach, lässt sich einfach überprüfen und benötigt höchstwahrscheinlich keine Modifikationen über die Lebensdauer der Applikation. Jedoch bedeutet dies, dass jede Applikation für das Herunterladen und die Überprüfung der nächsten Applikation verantwortlich sein muss. Dies kann zu Code-Duplikation bei Funk-Stack, Device Firmware und OTA-Update-Software führen.
Andererseits könnte auch der gesamte OTA-Update-Prozess in den SSBL verschoben werden. In diesem Szenario setzen Applikationen einfach eine Markierung (Flag) in der ToC, um ein Update anzufordern und setzen dann das System zurück. Der SSBL führt dann den Download-Vorgang und den Verifikationsprozess durch. Dies minimiert eine eventuelle Code-Duplikation und vereinfacht die applikationsspezifische Software.
Allerdings entsteht daraus die neue Herausforderung, möglicherweise den SSBL selbst aktualisieren zu müssen (den Update-Code zu aktualisieren). Letztendlich wird die Entscheidung, über Funktionsverlagerung in den SSBL, von den Speicherbedingungen des Clients, der Ähnlichkeit zwischen heruntergeladenen Applikationen und der Portierbarkeit der OTA-Update-Software abhängen.
Entwicklungskompromiss: Caching und Komprimierung
Eine weitere wichtige Entscheidung bei der Entwicklung der OTA-Update-Software betrifft die Organisation der eintreffenden Applikationen im Speicher beim OTA-Update-Prozess. Mikrocontroller enthalten normalerweise nichtflüchtigen und flüchtigen Speicher (Flash-Memory oder SRAM). Im Flash-Speicher befinden sich der Programmcode und Nur-Lese-Daten (Read Only) einer Applikation, zusammen mit anderen System-Level-Daten wie das Inhaltsverzeichnis und ein Ereignisprotokoll.
Das SRAM wird genutzt, um modifizierbare Teile der Software-Applikation zu speichern, zum Beispiel nicht konstante globale Größen und der Stack. Die Binärdarstellung der Software-Applikation in (Bild 1, unten) enthält lediglich den Programmteil aus dem nichtflüchtigen Speicher. Die Applikation initialisiert die Teile, welche sich beim Einschaltvorgang im flüchtigen Speicher befinden.
Während des OTA-Update-Prozesses wird jedes Mal, wenn der Client vom Server ein Datenpaket mit einem Teil des Programms empfängt, das Datenpaket im SRAM gespeichert. Das Datenpaket kann komprimiert oder unkomprimiert sein. Der Vorteil der Komprimierung des Applikationsprogramms ist, dass es dadurch kleiner wird und somit weniger Datenpakete übertragen werden müssen. Außerdem verringert dies den Platzbedarf zum Speichern der Datenpakete im SRAM während des Herunterladens. Nachteilig bei diesem Konzept ist die zusätzliche Verarbeitungszeit beim Update-Prozess durch die Komprimierung und Entkomprimierung. Außerdem muss zur Komprimierung gehörender Code in der OTA-Update-Software gebündelt werden.
Da die neue Applikationssoftware auf den Flash-Speicher abzielt, während der Aktualisierung aber im SRAM eintrifft, muss die OTA-Update-Software zu irgendeinem Zeitpunkt des Updates die Daten in den Flash-Speicher schreiben. Das temporäre Speichern der neuen Applikation im SRAM heißt Caching. Zum Caching der OTA-Update-Software gibt es drei verschiedene Ansätze:
- Kein Caching - Jedes Mal, wenn ein Datenpaket eintrifft, welches einen Teil der neuen Applikation enthält, wird es an seinen Bestimmungsort im Flash-Speicher geschrieben. Dieses Schema ist äußerst einfach und minimiert den Logikumfang in der OTA-Update-Software. Allerdings verlangt dies, dass der Bereich des Flash-Speichers für die neue Applikation komplett gelöscht wird. Durch diese Methode verschleißt der Flash-Speicher und es entstehen Overhead-Datenbereiche.
- Partielles Caching - Bei diesem Konzept wird ein Teil des SRAM für Caching reserviert: sobald neue Datenpakete eintreffen, werden sie in diesem Bereich gespeichert. Wenn sich die Region füllt, werden die Daten weiter in den Flash-Speicher verlagert. Dies kann komplex werden, falls Datenpakete ungeordnet eintreffen, oder das neue Applikationsprogramm Lücken aufweist. Dann wird eine Abbildung der SRAM- auf die Flash-Adressen notwendig. Eine Strategie besteht darin, den Cache als Spiegel (Mirror) eines Flash-Bereiches zu nutzen. Flash-Speicher ist in kleine Zellen, sogenannte Seiten (Pages), eingeteilt. Seiten stellen die kleinsten löschbaren Bereiche. Wegen dieser natürlichen Teilung sollte eine Seite im Flash-Speicher in den SRAM zwischengespeichert werden. Sobald sich das SRAM füllt, oder das nächste Datenpaket auf eine andere Seite gehört, wird der Cache unter Schreiben dieser Seite in den Flash-Speicher gelöscht.
- Vollständiges Caching - Bei dieser Methode wird die komplette neue Applikation während des OTA-Updates in SRAM gespeichert und nur in Flash-Speicher geschrieben, wenn sie vollständig vom Server heruntergeladen wurde. Dieses Konzept überwindet die Unzulänglichkeiten der bisher genannten Möglichkeiten, indem es die Anzahl von Schreibvorgängen in Flash-Speicher minimiert und komplexe Caching-Logik in der OTA-Update-Software vermeidet. Allerdings begrenzt dies den Umfang der runterladbaren Zielapplikation, da die Kapazität von verfügbarem SRAM im System normalerweise wesentlich kleiner ausfällt, als die des verfügbaren Flash-Speichers.
Jobangebote+ passend zum Thema
Das zweite Schema des partiellen Caching während eines OTA-Updates zeigt Bild 5. Darin wurde der Teil des Flash-Speichers für Applikation A aus den Bildern 3 und 4 vergrößert und ein funktionales Speicherabbild für das SRAM des SSBLs gezeigt. Die Flash-Seiten-Größe beträgt im Beispiel 2 kB. Letztlich wird sich die Entwicklungsentscheidung nach der Größe der neuen Applikation und der erlaubten Komplexität der OTA-Update-Software richten.
- OTA-Schnittstellen für µC-Apps
- Das Wesen einer Software-Applikation
- Der Second-Stage Bootloader (SSBL)
- Entwicklungskompromiss: Die Rolle des SSBL
- Funktionale Sicherheit und Kommunikation
- Versuchsaufbau
- Ergebnisse
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Airbus Cyber Security
»Cyber-Security wird zunehmend als Enabler für das IoT gesehen«
Edge Computing
Rechnen, wo Rechenleistung gebraucht wird
Mobilfunkmodul mit µC
LTE-Modem und µC als System-in-Package
Mess- und Prüftechnik / IoT-Sensorknoten
Das Zephyr von vorne aufgezäumt
Systemdesign / Safety&Security
Updateszenarien für und mit Linux
