Embedded Systems &
vernetzte Sensorik

Die Wahl hängt an Speicher, Energiebudget, Echtzeit- und Pflegeanforderungen. Bare-Metal ohne Betriebssystem eignet sich für kleinste Mikrocontroller mit einer festen Aufgabe. Zephyr ist ein Echtzeitbetriebssystem für Geräte mit knappem Speicher- und Energiebudget, das Vernetzung, Sicherheitsfunktionen und Updates bereits mitbringt. Eine mit Yocto gebaute Linux-Distribution ist die Wahl, wenn ein vollwertiges System mit komplexer Anwendung, langer Pflegeperspektive und großen Gerätebeständen gebraucht wird. Wo eine Zulassung nach Safety-Normen verlangt wird, engt das die Auswahl ein, weil zertifizierbare Varianten vor allem im Echtzeitbereich existieren. Die Entscheidung gehört an den Anfang, weil sie später kaum revidierbar ist.

Über drei Bausteine. A/B-Partitionierung hält zwei Systemstände vor: Schlägt die Installation fehl oder bricht die Übertragung ab, startet das Gerät mit dem bisherigen Stand. Unterbrechungstolerante Übertragung setzt nach einem Abbruch an derselben Stelle wieder auf, statt von vorn zu beginnen, und differenzielle Pakete übertragen nur, was sich geändert hat. Die kryptografische Prüfung von Signatur und Integrität erfolgt auf dem Gerät selbst, sodass auch ohne Verbindung zu einem Server entschieden werden kann, ob ein Paket vertrauenswürdig ist. Ist gar keine Netzverbindung vorgesehen, etwa in air-gapped Umgebungen, läuft derselbe Ablauf über lokale Datenträger, mit derselben Prüfung.

Bei einem Software Defined Radio übernimmt Software Aufgaben, die in klassischen Funkgeräten in fester Schaltung liegen: Modulation, Filterung, Protokolle, die Wahl der Wellenform. Analog bleibt nur das Hochfrequenz-Frontend, das Signale sendet, empfängt und digitalisiert. Der Grund für diesen Aufbau ist wirtschaftlich: Ein Funkgerät bleibt oft Jahrzehnte im Bestand, während sich Wellenformen, Verschlüsselungsverfahren und Partneranforderungen deutlich schneller ändern. Bei fester Schaltung heißt jede solche Änderung Neubeschaffung oder Umbau in der Werkstatt. Bei einem SDR heißt sie Update. Dieselbe Hardware kann neue Wellenformen lernen, mit anderen Systemen interoperabel werden oder Schwachstellen schließen, und eine Plattform kann mehrere Gerätetypen ersetzen, was Beschaffung, Ausbildung und Ersatzteilhaltung vereinfacht. Der Preis dafür ist, dass das Funkgerät zu einem eingebetteten System wird, mit allen Fragen, die daraus folgen: welches Betriebssystem darauf läuft, wie Updates sicher ins Feld kommen und wie geprüft wird, dass nur echte Software startet.

Im Kern vier Dinge: ein gesicherter Startvorgang (Secure Boot), der nur geprüfte Software ausführt, ein gehärtetes Systemabbild ohne unnötige Dienste, sichere Verwahrung von Schlüsseln in einem Hardware-Vertrauensanker wie einem Trusted Platform Module und ein Aktualisierungsweg, über den Schwachstellen tatsächlich geschlossen werden können. Der letzte Punkt wird am häufigsten übersehen und entscheidet über die Sicherheit nach Jahr drei.

C ist die Basis der meisten Echtzeitbetriebssysteme, auch von Zephyr, und bleibt dort gesetzt, wo Kernel, Treiber und Herstellerbibliotheken es vorgeben. C++ trägt komplexe Anwendungslogik auf Linux-Systemen und bleibt die Wahl, wo bestehender Code weiterentwickelt wird oder ein Zulassungspfad eine qualifizierte Werkzeugkette verlangt. Rust schließt durch Speichersicherheit eine ganze Klasse von Schwachstellen aus, die in C und C++ einen großen Teil der schweren Sicherheitsfehler ausmacht, und eignet sich deshalb für Neuentwicklungen auf Linux und Bare-Metal, wo Werkzeugkette und Plattform es tragen. Die Abwägung lohnt pro Komponente, nicht pro Projekt, weil sich alle drei in einem System kombinieren lassen.

Weil bei einem SDR die Wellenform Software ist und damit im Eigentum und in der Kontrolle des Betreibers liegen kann, statt fest in das Gerät eines Herstellers eingebaut zu sein. Wer die Wellenform selbst besitzt oder sie über einen offenen Standard wie die Software Communications Architecture zwischen Geräten portieren kann, ist nicht an einen Gerätehersteller gebunden, kann Interoperabilität mit Partnern per Update herstellen und Geräte verschiedener Hersteller mit derselben Wellenform betreiben. Das gilt mit einer Einschränkung: Die Verschlüsselung bleibt in der Regel in eigenen, zugelassenen Modulen und unterliegt eigenen Regeln. Souveränität beim SDR heißt deshalb vor allem Kontrolle über Wellenform und Plattformsoftware, nicht über die Kryptografie.

Der CRA verpflichtet Hersteller vernetzter Produkte, Sicherheit über den gesamten Lebenszyklus nachzuweisen: keine bekannten ausnutzbaren Schwachstellen bei Auslieferung, sichere Standardkonfiguration, Sicherheitsupdates über den Unterstützungszeitraum, ein Prozess zur Behandlung und Meldung von Schwachstellen und eine Software-Stückliste der Abhängigkeiten. Die Meldepflichten gelten seit September 2026, die übrigen Pflichten ab Dezember 2027. Produkte, die ausschließlich für Verteidigung oder nationale Sicherheit entwickelt werden, sind ausgenommen; Komponenten und Dual-Use-Produkte in der Regel nicht. Für Embedded-Geräte heißt das praktisch: reproduzierbare Systemabbilder, nachvollziehbare Zusammensetzung und ein belastbarer Update-Weg, denn ohne ihn lässt sich die Update-Pflicht nicht erfüllen.

Aus vier Gründen. Latenz: Eine Reaktion in Millisekunden verträgt keinen Umweg über ein Rechenzentrum. Bandbreite: Ein Videostrom oder ein Sensor mit hoher Abtastrate lässt sich nicht dauerhaft übertragen, ein Ergebnis schon. Verfügbarkeit: Funktionen, die am Gerät laufen, arbeiten auch ohne Verbindung weiter. Vertraulichkeit: Daten, die das Gerät nicht verlassen, müssen nicht geschützt übertragen und andernorts gespeichert werden. Der Preis sind begrenztes Rechen- und Energiebudget, was Modellgröße und Verfahren einschränkt, und ein Update-Weg, der Änderungen an der Auswertung auf jedes Gerät bringt.

Beides sind Verfahren, um Gerätesoftware gegen ihr Umfeld zu testen, ohne jedes Mal das komplette System aufzubauen. Software-in-the-Loop (SIL) führt die Software in einer Emulation oder Virtualisierung aus. Das setzt voraus, dass es eine Ausführungsumgebung gibt, in der Tests ohne die echte Hardware aussagekräftig sind, was bei hardwarenaher Software oft nicht der Fall ist. Hardware-in-the-Loop (HIL) testet auf dem realen Gerät, während der Rest des Systems simuliert oder durch ein Gegenstück ersetzt wird. Die Bandbreite ist groß: von Rack-Aufbauten, die ein ganzes Fahrzeug nachbilden, bis zu zwei über Kreuz verbundenen Funkgeräten, die einander als Gegenstelle dienen und per Skript angesteuert werden. Entscheidend ist nicht die Größe des Aufbaus, sondern ob er die Fragen beantwortet, die vor einer Auslieferung offen sind, und ob er in der Pipeline automatisiert läuft.