Design-Praxis / Embedded Software
OTA-Schnittstellen für µC-Apps
Fortsetzung des Artikels von Teil 1
Das Wesen einer Software-Applikation
Ein Großteil des OTA-Aktualisierungsprozesses besteht darin, die neue Softwareversion vom Server zum Client zu übertragen. Die Software wird als Bytefolge übertragen, nachdem sie vom Ursprungsformat in ein Binärformat gewandelt wurde. Der Wandlungsprozess kompiliert die Quellcode-Dateien (zum Beispiel .c, .cpp) und bindet sie in eine ausführbare Datei ein (zum Beispiel .exe, .elf). Anschließend wird die .exe-Datei in ein portables Binärdateiformat (zum Beispiel .bin, .hex) gewandelt.
Auf abstraktem Niveau enthalten diese Dateiformate eine Bytefolge, die eine bestimmte Speicheradresse im Mikrocontroller benennt. Typischerweise werden die übertragenen Informationen als Daten konzipiert, beispielsweise ein Befehl, der den Systemzustand oder vom System gesammelte Sensordaten, ändert.
Bei einem OTA-Update stellt die neue Software die Daten im Binärformat.
Oft ist die Binärdatei für eine Einzelübertragung zu groß und muss auf kleinere Übertragungspakete verteilt werden (Bild 1, unten). Im Beispiel enthält jedes Datenpaket 8 Byte Daten, wobei die ersten vier Byte die Speicheradresse des Clients für die nächsten vier Byte repräsentieren.
Jobangebote+ passend zum Thema
Herausforderungen
Aus dieser High-Level-Beschreibung des OTA-Update-Prozesses resultieren drei wesentliche Herausforderungen, welche die OTA-Update-Lösung adressieren muss. Die erste Herausforderung betrifft den Speicher. Die Software-Lösung muss die neue Software-Applikation in flüchtigem oder nichtflüchtigem Speicher des Clients organisieren, damit sie ausgeführt werden kann, sobald der Update-Prozess abgeschlossen ist.
Die Lösung muss sicherstellen, dass eine frühere Version der Software als Fallback-Applikation erhalten bleibt. Auch müssen der Client-Zustand zwischen Rücksetz- und Einschaltzyklen, wie bei der aktuell laufenden Software, sowie der Speicherort beibehalten werden.
Die zweite große Herausforderung heißt Kommunikation. Die neue Software muss vom Server zum Client in separaten Paketen gesendet werden, wobei jedes Datenpaket auf eine bestimmte Adresse im Speicher des Client abzielt. Aufteilungskonzept, Paketstruktur und das zur Datenübertragung benutzte Protokoll müssen in die Software-Entwicklung einfließen.
Die abschließende große Herausforderung betrifft die funktionale Sicherheit (Security). Da die neue Software drahtlos vom Server zum Client übertragen wird, ist sicherzustellen, dass der Server eine vertrauenswürdige Instanz ist. Diese Security-Herausforderung heißt Authentifizierung. Darüber hinaus ist dafür zu sorgen, dass die neue Software etwaigen Beobachtern verborgen bleibt, da sie vertrauliche Informationen enthalten kann. Diese Security-Herausforderung wird als Vertraulichkeit (Confidentiality) bezeichnet.
Das letzte Element der funktionalen Sicherheit heißt Integrität und gewährleistet, dass die neue Softwareversion beim Versenden über die Luftschnittstelle nicht beschädigt ist.
- 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
