Ein Compliance-erster Leitfaden für die Entwicklung eingebetteter Systeme

Die meisten eingebetteten Fehler werden nicht durch einen schlechten Treiber oder einen Fehler verursacht. Jemand könnte in Isolation eingeschlossen sein. Sie erscheinen dort, wo Disziplinen sich überschneiden., Dies kann beispielsweise dadurch geschehen, dass eine Hardware-Beschränkung die Firmware beeinträchtigt, oder an einem anderen Punkt zwischen den verschiedenen Ebenen. Bis zu dem Zeitpunkt, an dem diese Probleme sichtbar werden, ist die Neugestaltung oft viel kostspieliger als die korrekte Umsetzung der ursprünglichen Implementierung.

Die Lösung besteht darin, die gesamte Anlage als ein System zu betrachten. Statt einer Stapel von separaten Ebenen. Hardware, Firmware, Konnektivität, Cloud, Sicherheit und Compliance beeinflussen einander. Daher wirkt sich eine Entscheidung in einer Ebene auf die anderen aus, und die Teams, die ihre Entscheidungen sauber treffen, sind diejenigen, die diese Zusammenhänge erkennen und nicht jede Ebene einzeln bearbeiten müssen. Die System-Level-Ansicht ist es, was sicherstellt, dass kleine Anfangsentscheidungen nicht zu spätzeitigen und kostspieligen Neudefinitionen führen..

Die Erstellung dieser Übersicht erfordert ein Verständnis für alle Einzelheiten, was der Rest dieses Leitfadens ebenfalls behandelt: die Architektur, den Entwicklungsprozess, die Technologien sowie die Compliance-Anforderungen, die bestimmen, ob ein Produkt reibungslos auf den Markt kommt oder auf dem Weg dorthin mit kostspieligen Integrationsproblemen zu kämpfen hat.

An Embedded System ist die vollständige, speziell entwickelte Einheit: die Hardware (ein Mikrocontroller oder Prozessor, die Platine, ihre Sensoren und Peripheriegeräte) zusammen mit dem Code, der auf ihr läuft. Eine angeschlossene Insulinpumpe und eine Motorsteuerungsplattform sind beide Embedded-Systeme.

Embedded Software ist die Codeebene in diesem Gerät. Sie wird direkt auf beschränkter Hardware ausgeführt, um eine bestimmte Aufgabe auszuführen – von der Firmware und den Treibern bis hin zur Anwendungslogik.

Die Entwicklung von Embedded-Systemen umfasst daher das gesamte Produkt, das sowohl Hardware als auch Software als eine Einheit entwickelt wird. Eingebettete Softwareentwicklung Die Disziplin konzentriert sich auf den Code, der die Hardware zum Leben erweckt. In der Praxis überschneiden sich die beiden Disziplinen ständig, weshalb die Ingenieure von Yalantis das Gerät als ein System anstatt in zwei Phasen – von der Leiterplatte bis zum Cloud-Bereich – entwerfen, sodass jede Wahl auf jeder Ebene die anderen Komponenten berücksichtigt.

Ein eingebettetes System besteht aus mehreren Ebenen, von der Hardware am unteren Ende bis zur Anwendungslogik oben. Jede Ebene erfüllt eine andere Funktion, doch das Produkt gelingt nur, wenn sie zusammen als einheitliches System funktionieren.

Bei der Entwicklung eingebetteter Systeme entstehen die größten Herausforderungen oft dort, wo diese Ebenen miteinander interagieren. Ein Fahrer kann Sensordaten falsch interpretieren, ein Konnektivitätspaket kann den Speicherbudget des Geräts überschreiten oder ein Cloud-Update kann ein Verhalten verursachen, das die Firmware nie für nötig gehalten wurde. Das Verständnis dieser Abhängigkeiten ist ebenso wichtig wie die Konstruktion der einzelnen Ebenen selbst.

Die nachfolgende Architektur zeigt, wie die Ebenen zusammenhängen und wo sich Integrationrisiken am häufigsten befinden.

Die Hardware-Basis

Jedes Embedded-System beginnt mit physischer Hardware: dem Prozessor oder dem Mikrocontroller, der Platine und den Peripheriegeräten, die diese steuern. Die hier getroffenen Entscheidungen – von der Auswahl des MCU bis zur Stromversorgung – setzen harte Grenzen für alles, was die Software darüber hinaus tun kann. Da die Hardwareentwicklung eine eigene Disziplin ist, behandeln wir sie in unserem Handbuch für die Hardwareentwicklung. Zurzeit konzentrieren wir uns jedoch auf die Software, die innerhalb dieser Grenzen funktioniert.

Firmware- und Board-Support

Direkt über dem Hardware-Baustein befindet sich die Firmware-Ebene: der Bootloader, die Geräte-Treiber und das Board-Support-Paket (BSP). Zusammen bieten sie die Schnittstelle zwischen dem Board und der darüber liegenden Software, wodurch höhere Ebenen ohne Kenntnis der Details der zugrunde liegenden Hardware arbeiten können.

Das Firmware-Betriebssystem ist weit mehr als nur ein Zugang zum Hardware-Speicher. Es steuert, wie ein Gerät startet, sich von Fehlern erholt, mit Peripheriegeräten kommuniziert und während seines gesamten Lebenszyklus Updates erhält. Eine Schwachstelle in dieser Ebene kann schwer zu diagnostizieren sein, da die Symptome oft an anderer Stelle im System auftreten.

Für eine detaillierte Beschreibung der Firmware-Architektur, der Entwicklungsmethoden und der Aktualisierungsstrategien lesen Sie bitte unsere Handbuch für die Firmware-Entwicklung für eingebettete IoT-Geräte.

Die Laufzeit: RTOS, OS oder Bare-Metal

Die Laufzeitebene bestimmt, wie sich Software auf einem Gerät ausführt. Einige Embedded-Systeme laufen in „bare-metal“-Modus, wobei die Anwendung direkt mit der Hardware interagiert, um maximale Kontrolle und minimalen Ressourcenverbrauch zu erreichen. Andere setzen auf ein Echtzeitbetriebssystem (RTOS), wie z. B. FreeRTOS oder Zephyr, um mehrere zeitkritische Aufgaben zu koordinieren. Leistungsfähigere Geräte hingegen können Embedded Linux verwenden, um Netzwerkfunktionen, Benutzeroberflächen und komplexe Anwendungen zu unterstützen.

Die wichtigste Herausforderung auf dieser Ebene ist die Vorhersagbarkeit. Ein System, das bei geringer Belastung korrekt funktioniert, kann jedoch unter Belastung durch konkurrierende Aufgaben, Unterbrechungen oder Kommunikationsereignisse zusammenbrechen. Daher geht es bei der Auswahl des richtigen Laufzeitmoduls weniger um Funktionen, sondern vielmehr darum, sicherzustellen, dass das Gerät seine Zeit- und Leistungsanforderungen konsequent erfüllen kann.

Middleware und Konnektivität

Die Middleware befindet sich zwischen der Laufzeitumgebung und der Anwendungsebene. Sie umfasst Kommunikationsprotokolle, Netzwerkstacke, Konnektivitätsservices sowie die Softwarekomponenten, die Daten zwischen dem Gerät und der Außenwelt übertragen.

Diese Ebene ist der Ort, an dem ein eingebettetes System Teil eines größeren Ökosystems wird. Je nach Produkt kann dies Bluetooth, Wi-Fi, Mobilfunkverbindung, Ethernet oder energieeffiziente Technologien wie LoRaWAN umfassen. Jede dieser Optionen bringt unterschiedliche Kompromisse in Bezug auf Reichweite, Bandbreite, Stromverbrauch, Latenzzeit und Sicherheit mit sich.

Hier entstehen viele Integrationsprobleme, da die Kommunikation über mehrere Systeme statt innerhalb einer einzelnen Einheit abläuft. Ein Produkt kann während der lokalen Testphase problemlos funktionieren, tritt jedoch bei der Datenübertragung mit Gateways, Cloud-Plattformen, mobilen Anwendungen oder anderen angeschlossenen Geräten auf Probleme mit Zuverlässigkeit, Leistung oder Interoperabilität auf.

Die Anwendungsebene

Die Anwendungsebene enthält die Funktionen, die die Benutzer tatsächlich benötigen. In einem Medizinprodukt kann sie eine Dosierung berechnen. In einem industriellen System kann sie Sensorwerte verarbeiten und Aktionen auslösen. Obwohl sie an der Spitze der Software-Struktur steht, hängt ihre Zuverlässigkeit von allem darunter ab: von den mit der Hardware interagierenden Steuerprogrammen bis hin zu den Verbindungsdiensten, die Daten mit externen Systemen austauschen.

Die Anwendungsschicht ist auch der Ort, an dem immer mehr eingebettete Geräte nun die lokale Datenverarbeitung und die KI-Intelligenz durchführen. Das Ausführen kompakter Modelle direkt auf dem Gerät kann die Latenz senken, die Bandbreitenanforderung verringern und sicherstellen, dass sensible Daten nicht von der Edge-Infrastruktur abgelenkt werden. Dies stellt jedoch auch neue Anforderungen an Speicher, Rechenleistung und Energieverbrauch mit sich.

Die Bedeutung jeder einzelnen Schicht hängt von der Art des zu entwickelnden Embedded-Systems ab, worüber wir in der nächsten Sektion sprechen werden.

Jedes eingebettete System verwendet die gleichen Bausteine, aber nicht jedes System stellt die gleichen Anforderungen an sie. Ein Motorregler lebt und stirbt von der Synchronisation. Ein angeschlossener Sensor hängt von einer zuverlässigen Kommunikation ab. Ein tragbares Gerät kann sich hauptsächlich durch die Batterielaufzeit einschränken.

Die meisten Produkte vereinen mehrere Merkmale gleichzeitig. Eine angeschlossene Insulinpumpe ist beispielsweise gleichzeitig real-time, vernetzt und batteriebetrieben. Das Verständnis der wichtigsten Anforderungen hilft den Teams dabei, sich auf die Bereiche zu konzentrieren, die das größte technische und geschäftliche Risiko mit sich bringen.

Die folgenden Kategorien bieten einen praktischen Ansatz, um eingebettete Systeme und die jeweiligen technischen Anforderungen zu betrachten.

In der Praxis, Entwicklung von IoT-Geräten Wenn man diese drei Komponenten kombiniert, bestimmt die Kombination, wie viel Disziplin die Konstruktion erfordert. Eine eigenständige Küchenuhr und ein vernetztes, Echtzeit-Medizintechnikgerät werden völlig unterschiedliche Entwicklungsprozesse erfordern.

Der Entwicklungsprozess muss mit den Kosten des Scheiterns in Einklang gebracht werden. Ein Mangel an einem Verbrauchergerät kann unbequem sein. Ein Mangel an einem medizinischen oder industriellen System kann Sicherheits-, regulatorische und rechtliche Risiken mit sich bringen.
Deshalb setzen eingebettete Teams selten auf eine einzige Methodik. Das V-Modell bietet die Rückverfolgbarkeit und Überprüfung, die für sicherheitskritische Arbeiten erforderlich sind, während das agile Projektmanagement Teams dabei hilft, schneller mit Softwarekomponenten zu arbeiten, die sich einfacher ändern lassen. Die meisten erfolgreichen Projekte kombinieren beides und finden die richtige Balance zwischen Strenge, wo dies erforderlich ist, und Flexibilität, wo dies möglich ist.

Das V-Modell und warum regulierte Arbeit davon abhängt

Das V-Modell ist der Entwicklungsprozess für eingebettete Systeme, bei dem alle Designschritte im Abwärtsverlauf mit entsprechenden Tests im Aufwärtsverlauf verbunden sind. Anforderungen werden zusammen mit der Akzeptanzprüfung, Architektur mit dem Systemtest, Moduldesign mit der Integrationsprüfung und Code mit der Einheitsprüfung verknüpft. Die Form ermöglicht die Rückverfolgbarkeit. Jedes Anforderungsproblem hat einen Test, der es belegt, und jeder Test verweist auf ein Anforderungsproblem, was genau das ist, was ein Prüfer nach IEC 62304 oder ISO 26262 von Ihnen verlangt.

Deshalb ist die Verifizierung keine Phase, die man am Ende erreicht. Die Tests werden auf dem Weg nach unten geplant und auf dem Weg nach oben durchgeführt, sodass ein Lückenfall in den Anforderungen bereits lange vor dem Erreichen eines Geräts im Testplan erkennbar ist. Die Integration dieser Kontrollpunkte in jeden Schritt, anstatt sie erst für den Abschluss der Prüfung zu berücksichtigen, ist das Herzstück von Compliance-First Engineering und der Unterschied zwischen einer ruhigen Zertifizierung und einem hektischen Chaos.

Agile Anpassungen für die Software-Ebenen

Nicht jeder Teil eines eingebetteten Systems benötigt das gleiche Maß an Prozesskompetenz. Softwarekomponenten sind in der Regel schneller und kostengünstiger zu ändern als Hardware, was sie ideal für iterative Entwicklung macht. Firmware kann schnell neu erstellt und neu programmiert werden, während Anwendungs- und Cloud-Services oft durch kurze Release-Zyklen und kontinuierliche Feedback-Vorgaben geprägt sind.

Die Hardware-Entwicklung verläuft in einem anderen Tempo. Die Überarbeitung von Boards benötigt Zeit, und Zertifizierungsaktivitäten setzen Kontrollpunkte an, die nicht durch kürzere Sprints beschleunigt werden können. Um Hardware und Software parallel voranzubringen, benötigen Teams eine stabile Schnittstelle zwischen ihnen. Klar definierte Konzepte für Register, Protokolle und Datenstrukturen ermöglichen die Softwareentwicklung, ohne auf jede Hardware-Änderung zu warten.

Wie eine KI-gestützte PDLC die Lieferung beschleunigt

Viele der kostspieligsten Embedded-Projekte entstehen lange bevor die Implementierung beginnt. Architekturvorstellungen, fehlende Anforderungen und übersehene Ausnahmesituationen ergeben sich oft Monate später als Integrationsprobleme. AI kann diese Risiken früher erkennen, indem es Anforderungen analysiert, vorgeschlagene Architekturen validiert und bei der Dokumentation und Testplanung unterstützt.

Bei Yalantis unterstützt die KI den Produktentwicklungsprozess, während die Ingenieure die Verantwortung für jede Entscheidung behalten, die zur Produktion gelangen soll. Erfahren Sie mehr in unserer Anleitung. KI im Produktentwicklungsprozess.

Embedded-Geräte haben oft strenge Grenzen hinsichtlich der Speicherkapazität, der Rechenleistung und des Energieverbrauchs. Darüber hinaus interagieren sie auch direkt mit Hardware und in manchen Fällen mit sicherheitskritischen Systemen. Diese Anforderungen lassen nur wenig Raum für Abstraktion oder Ineffizienz, weshalb die Embedded-Entwicklung auf einer relativ kleinen Anzahl an Programmiersprachen basiert. Heute dominieren C, C++ und Rust die meisten Embedded-Software-Projekte.

C und C++

C ist die Standardsprache für eingebettete Anwendungen und war es seit Jahrzehnten schon. Jedes Mikrocontroller-Modul wird mit einem C-Compiler geliefert. Die Größe des Programms ist minimal und Sie haben direkten Zugriff auf Speicher und Register. C++ fügt Struktur, Klassen und RAII hinzu, um größere Anwendungen zu unterstützen, die von einer Organisation ohne den Verlust der tiefgreifenden Kontrolle profitieren.

Auch ihre gemeinsame Schwäche ist jahrzehntelange Tradition. Beide überlassen die Speicherverwaltung dem Entwickler, und ein einziger Fehler, ein überschränkter Puffer oder ein Pointer, der nach seiner Freigabe verwendet wird, kann zu einer Art Defekt werden, der sich sowohl in der Entwicklung als auch in der Praxis zeigt.

Rust für memristanzegnerne

Entwicklung mit Rust Dies verändert die Gleichung. Durch sein Eigentumsmodell sorgt es für Speicherzuverlässigkeit bei der Kompilierung, sodass Überlaufprobleme und Use-after-free-Fehler, die C und C++ beeinträchtigen, bereits vor dem Ausführen des Codes erkannt werden. Darüber hinaus ermöglicht Rust dies ohne Garbage-Collector und ohne Laufzeitkosten, was es auch auf Geräten mit 256 KB RAM nutzbar macht. Speicherzuverlässigkeit ist zu einer großen Sorge für die Industrie geworden: CISA und die NSA Der Bericht zufolge gehen rund 70% der schwerwiegenden Sicherheitslücken auf Probleme mit der Speicherzuverlässigkeit zurück, und beide appellieren nun zur Umstellung auf Speicherzuverlässige Programmiersprachen.

In der Praxis bedeutet das Einpflegen von Rust in der Praxis selten, eine gesamte Codebasis neu zu schreiben. Die meisten Teams implementieren es schrittweise und ersetzen einzelne Komponenten, während der Rest der Firmware weiterhin in C oder C++ läuft. Ein sicherheitskritischer Modul, wie ein Kommunikationsstack, ein Credential Manager oder eine sichere Boot-Komponente, kann in Rust neu geschrieben und mit dem bestehenden Code integriert werden. Diese Herangehensweise ermöglicht es Teams, die Sicherheit zu verbessern, wo das Risiko am größten ist, ohne ein stabiles Produkt zu unterbrechen. Wir erklären den Prozess genauer in unserem Handbuch zur Migration von C/C++ zu Rust.

Für sicherheitskritische Projekte helfen zertifizierte Toolchains wie Ferrocene außerdem, dass Rust die Überprüfung und Rückverfolgbarkeit nach Normen wie IEC 62304 und ISO 26262 erfüllt.

Werkzeugketten, Debugger und Emulatoren

Das Schreiben des Codes ist nur die Hälfte der Arbeit, denn Embedded-Software wird nicht dort ausgeführt, wo sie geschrieben wird. Sie wird auf einer Workstation erstellt und auf einem Gerät mit eigenem Prozessor, Speicherbeschränkungen und Hardware-Schnittstellen bereitgestellt – was die Toolchain zu einem zentralen Bestandteil des Engineering-Prozesses macht.

Mehrere Kategorien von Tools unterstützen diese Arbeit. Cross-Compilern entstehen Code für die Zielarchitektur. On-Chip Debugger verbinden sich über Schnittstellen wie JTAG oder SWD, sodass Ingenieure Speicher und Ausführungslage direkt am Gerät prüfen können. Emulatoren wie QEMU und Renode ermöglichen es, Firmware zu testen, bevor die physische Hardware verfügbar ist, was den Hardware- und Softwareteams hilft, parallel zu arbeiten. SDKs von Herstellern, wie STM32Cube und ähnliche Frameworks, bieten die benötigten Treiber, Bibliotheken und Konfigurationswerkzeuge für bestimmte Chipfamilien.

Wachsender Einsatz von Edge-KI das Verhältnis noch enger macht. Laufen TinyML-Modelle Die direkte Anbindung an ein Gerät kann die Latenz und die Bandbreitenanforderung reduzieren, erhöht jedoch auch die Anforderungen an Speicher, Rechenleistung und Energieverbrauch. Diese Kompromisse verdeutlichen eine umfassendere Realität der Embedded-Entwicklung: Die Softwarefunktionen werden stets durch Hardwarebeschränkungen bestimmt.

Hardware und Software werden oft als separate Disziplinen behandelt, aber die Entwicklung von Embedded-Systemen erfordert eine gleichzeitige Betrachtung beider Aspekte. Jede Hardware-Entscheidung beeinflusst die Software, und jede Softwareanforderung stellt die Hardware unter Druck. Diese Beziehung ist eine wesentliche Quelle von Integrationsrisiken, weshalb die Integration von Hardware und Software schon lange vor der vollständigen Umsetzung der jeweiligen Komponenten begonnen werden muss.

Softwareentwicklung im Hinblick auf die Grenzen der Hardware

Im Gegensatz zur traditionellen Anwendungsentwicklung beginnt das Design von eingebettetem Software mit festen Einschränkungen. Der Prozessor, die Speicherkapazität, die Stromversorgung und die Peripheriegeräte sind bereits festgelegt, und die Software muss innerhalb dieser Grenzen funktionieren.

Die Speicherkapazität ist oft die erste Einschränkung. Ein Mikrocontroller kann nur wenige hundert Kilobyte RAM bieten, was Entwicklern zwingt, die Arbeitsspeicher, die Speicherzuweisung und die Ressourcenauslastung sorgfältig zu verwalten. Energie ist eine weitere Herausforderung. Bei batteriebetriebenen Geräten spielt die Firmware eine direkte Rolle bei der Festlegung der Akkulaufzeit, indem sie steuert, wann der Prozessor schlafen und wieder aufwachen soll.

Die Hardwareauswahl bestimmt auch die Timing-Anforderungen und die Interaktionen mit den Peripheriekomponenten. Die auf dem Board verfügbaren Sensoren, Radios und Schnittstellen beeinflussen alles von der Implementierung der Treiber bis hin zur Interrupt-Verarbeitung. In vielen Echtzeitsystemen wird die Erfüllung der Timing-Anforderungen eher zum Kernbestandteil der Architektur als zur Leistungsoptimierung.

Die Beziehung funktioniert in beide Richtungen. Softwareanforderungen können ebenso leicht die Auswahl des Hardware-Konzepts beeinflussen. Eine Kommunikationsstack-Architektur kann mehr Speicher benötigen, als der ausgewählte Prozessor bereitstellt. Die Secure Boot-Funktionalität kann Hardware-Sicherheitsfunktionen erfordern, die auf dem ausgewählten Chip nicht verfügbar sind. Die frühzeitige Identifizierung dieser Abhängigkeiten hilft Teams dabei, kostspielige Neudefinitionen später im Projekt zu vermeiden.

Von dem Gerät über die Edge-Umgebung bis zum Cloud-Speicher

Die meisten vernetzten Geräte sind Teil eines größeren Systems, das über die eigene Geräte hinausgeht. Die Daten können auf dem Gerät verarbeitet, über eine Edge-Gateway weitergeleitet und schließlich in der Cloud gespeichert oder analysiert werden. Eine der wichtigsten architektonischen Entscheidungen besteht darin, zu entscheiden, wo jede Arbeitsaufgabe ausgeführt werden soll.

Die Verarbeitung von Daten auf dem Gerät kann die Latenz senken, die Bandbreitenanforderung reduzieren und sensible Daten lokal speichern. Die Verlagerung von Arbeitsbelastungen in die Cloud bietet eine größere Rechenleistung und vereinfacht Updates und Analysen. Die Balance zwischen den beiden Faktoren beeinflusst alles, von der Auswahl des Prozessors und den Speicheranforderungen bis hin zur Konnektivität und dem Stromverbrauch.

Es sollte von Anfang an mehrere Funktionen geplant werden, anstatt sie später hinzuzufügen. Über-die-Feld-Updates erfordern ein sicheres und zuverlässiges System zur Bereitstellung der Firmware an Geräte in der Feldarbeit. Die Bereitstellung, Überwachung und Verwaltung der Flotte von Geräten müssen ebenfalls frühzeitig berücksichtigt werden, da die Unterstützung von Tausenden von installierten Geräten eine architektonische Notwendigkeit ist und keine betriebliche Einzelheit darstellt.

Die Entscheidungen in Bezug auf die Verbindung erfolgen nach demselben Prinzip. Ob ein Produkt auf Bluetooth, Wi‑Fi, Mobilfunknetzen, Ethernet oder Niedrigenergie-Technologien wie LoRaWAN setzt, hängt von den Kompromissen zwischen Reichweite, Bandbreite, Latenzzeit, Stromverbrauch und Kosten ab.

Jede Verbindung, die einem Gerät hinzugefügt wird, erweitert auch seine Angriffsfläche. Update-Mechanismen, drahtlose Schnittstellen und Cloud-Integrationen schaffen neue Sicherheitsrisiken, die im Rahmen der Architektur angegangen werden müssen. Dies führt uns zu dem nächsten Thema: der Sicherheit eingebetteter Systeme.

Die Sicherung einer eingebetteten Geräte erfordert eine andere Denkweise als die Sicherung eines Servers. Angreifer können direkt physischen Zugriff auf die Hardware, die Firmware und die Kommunikationsschnittstellen haben. Eine Schwachstelle irgendwo in der Hierarchie kann jede Schutzmaßnahme, die darüber aufgebaut ist, untergraben.

Die Forschung von Security Signals von Microsoft Es stellte sich heraus, dass 80 Prozent der Organisationen innerhalb von zwei Jahren Opfer eines Firmware-Angriffs wurden, und die meisten Sicherheitsprogramme widmen ihre Aufmerksamkeit weiterhin eher der höheren Stufe der Sicherheitsarchitektur, wo es bereits zu spät ist.

Bevor Sie tiefer in unsere Handbuch zur Vermeidung von Firmware-Schwachstellen, Wir stellen Ihnen vier Tipps zur Sicherung eingebetteter Systeme vor:

1. Erstellen Sie einen vertrauenswürdigen Bootvorgang

Der Secure Boot-Schutz stellt sicher, dass nur autorisierte Firmware auf dem Gerät ausgeführt werden kann. Jeder Schritt der Startsequenz prüft die vorherige, bevor die Kontrolle übertragen wird. Auf diese Weise wird eine Vertrauenskette geschaffen, die auf Hardware-Sicherheitsfunktionen basiert. Ohne diesen Überprüfungsprozess kann bösartiger oder modifizierter Firmware jede nachfolgende Sicherheitsfunktion entgehen.

2. Schutz von Geheimnissen und Gerätsignaturen

Kryptografische Schlüssel sollten an einem separaten, sicheren Hardwaregerät gespeichert werden, anstatt in Firmware-Images oder Quellrepositorien. Die Sicherung von Gerätekennungen ist für die Authentifizierung, die sichere Kommunikation und die Überprüfung von Software-Updates unerlässlich.

3. Sicherer Datenaustausch und Kommunikation

Empfindliche Daten sollten sowohl während der Speicherung auf dem Gerät als auch während des Übertragungsprozesses über Netzwerke verschlüsselt werden. Kommunikationskanäle, APIs und Verbindungen zwischen Gerät und Cloud erfordern alle eine Authentifizierung und Verschlüsselung, um Interception oder Manipulationen zu verhindern.

4. Erstellen Sie eine sichere Update-Funktion

Aktualisierungen per Funk (OTA) sollten vor der Installation digital signiert und verifiziert werden. Außerdem benötigen Geräte einen Rollback-Mechanismus, damit sie sicher wiederhergestellt werden können, falls eine Aktualisierung fehlschlägt oder beschädigt wird.

Eine einzige Kontrolle allein ist nicht ausreichend, um ein Produkt zu sichern. Effiziente Sicherheit entsteht durch die Kombination dieser Maßnahmen in einer mehrschichtigen Architektur, die das Gerät über seinen gesamten Lebenszyklus schützt.

Ob ein angeschlossenes Produkt rechtmäßig verkauft werden kann, hängt oft von der Einhaltung der Vorschriften ab, und für eingebettete Software ist dies weniger eine endgültige Prüfung als vielmehr ein Nachweis, dass der Code die ersten Anforderungen erfüllt. Das V-Modell aus früheren Versionen ist der Weg, um diese Prüfung zu erstellen. Dieser Abschnitt behandelt, was die Standards tatsächlich von der Software verlangen.

Die Anforderungen fallen in mehrere Familien zusammen, die sich über Branchen erstrecken. Funktionale Sicherheitsstandards regeln, wie die Software gefährliche Ausfälle verhindert und unterbindet, und Sicherheitsstandards regeln, wie sie Angriffe abwehren kann. Eine dritte Gruppe umfasst Daten und Datenschutz. Die spezifischen Namen beziehen sich auf bestimmte Branchen, die im nächsten Abschnitt näher erläutert werden.

Einheitliche Anforderungen gelten nun für fast alle vernetzten Produkte, die in Europa verkauft werden. Der EU-Cyberresilienz-Act schreibt eine sichere Konstruktion, eine Software-Materialliste und Sicherheitsupdates über die gesamte Lebensdauer des Produkts vor. Es trat im Dezember 2024 in Kraft., Mit vollständigen Verpflichtungen ab Dezember 2027 und Geldstrafen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Umsatzes – daher ist jetzt der Zeitpunkt, um eine Lebenszyklus-Sicherheitsunterstützung zu entwickeln.

In der Praxis zeigt sich die Einhaltung in den Code als konkrete Ergebnisse: eine Traceability-Matrix, die jedes Requirement mit seinen Tests verknüpft, statische Analysen gegen einen Kodierungsstandard wie MISRA C, die als Gate ausgeführt werden, ein generiertes SBOM sowie dokumentierte Testnachweise, die ein Prüfer nachvollziehen kann. Erstellen Sie diese Schritt für Schritt, und die Zertifizierung ist eine Überprüfung. Nach der Zertifizierung können Sie sie anschließend anpassen und erstellen Sie eine Neubelebung.

Die verschiedenen Branchen stellen unterschiedliche Anforderungen an eingebettete Produkte. Ein medizinisches Wearable, eine Fahrzeugsteuerungseinheit, ein Industriegateway und ein Logistik-Tracker können alle Firmware in enger Verbindung mit der Hardware entwickeln, aber sie funktionieren auf unterschiedliche Weise. Eine Anlage kann zum Beispiel die Patientensicherheit gefährden. Ein anderes Gerät kann die Produktionslinie stoppen. Ein anderes Gerät kann die Batterie leerlegen, bevor die Sendung ihr Ziel erreicht.

Deshalb muss die Softwareentwicklung für Embedded-Systeme mit dem Betriebsumfeld beginnen, nicht nur mit der Codebasis. Teams müssen verstehen, welche Steuerungsmöglichkeiten das Gerät bietet, wo es läuft, wie oft es aktualisiert werden kann, welche Standards gelten und was passiert, wenn die Software fehlerhaft verhält.

Gesundheitswesen und Medizinprodukte

Die Entwicklung eingebetteter Systeme für medizinische Geräte wird von der Risikoklassifizierung, der Nachverfolgbarkeit und der Prüfungsdichte bestimmt. Nach IEC 62304 werden Softwareprogramme in Klassen A bis C eingeteilt, je nachdem, welche Schäden durch einen Fehler entstehen könnten. Klasse A umfasst Software, bei der es keine Verletzungen geben kann, während Klasse C gilt, wenn ein Fehler zum Tod oder schweren Verletzungen führen könnte.

Diese Klassifizierung verändert die Konstruktion. Ein Produkt der Klasse C benötigt eine stärkere Architekturabgrenzung, klarere Anforderungen, strengere Tests und mehr Belege dafür, dass jede Anforderung implementiert und verifiziert wurde. Die Norm ist nicht nur eine Dokumentationslast. Sie zwingt die Teams dazu, zu beweisen, dass das sicherheitsbezogene Verhalten über den gesamten Entwicklungsprozess hinweg konzipiert, getestet und kontrolliert wird.

Die Sicherheit der Speicher ist auch im Gesundheitswesen wichtiger, da kleine Fehler das Verhalten der regulierten Produkte beeinträchtigen können. Eine Speicherstörung in einem Verbrauchergerät kann zu einem Neustart führen. Eine Speicherstörung in einer angeschlossenen medizinischen Einrichtung kann die Überwachung, die Datenintegrität oder die therapiebezogenen Funktionen beeinträchtigen. Aus diesem Grund setzt die Entwicklung eingebetteter Systeme für den Gesundheitsbereich häufig auf strengere Kodierungspraktiken, statische Analyse, defensives Design sowie Sprachen oder Werkzeuge, die das unsichere Speicherverhalten reduzieren.

Die gleiche Logik gilt auch für die Entwicklung eingebetteter Systeme für tragbare Technologien. Diese Geräte haben strenge Grenzen hinsichtlich der Akkulaufzeit, der Speicherkapazität, der Konnektivität und der Gehäusegröße, doch sie erheben oft sensible physiologische Daten. Ein Pulsoximeter, ein EKG-Monitor, ein insulinbezogenes Gerät oder ein Rehabilitationssensor benötigen stabile Firmware, zuverlässige Datenerfassung, sichere Übertragung und einen klaren Updatepfad. Das Gerät mag klein sein, doch die Software-Aufgaben sind nicht weniger umfangreich.

Automobilindustrie

Die Entwicklung eingebetteter Software in der Automobilbranche wird von Funktionaler Sicherheit, Echtzeitverhalten und Systemkomplexität bestimmt. Moderne Fahrzeuge enthalten viele elektronische Steuergeräte, die in Bezug auf Bremsen, Lenkung, Batterieverwaltung, Infotainment, Telematik, Fahrerassistenz und Karosserie-Steuerung zusammenarbeiten. Ein Defekt in einem Bauteil kann andere Teile des Fahrzeugs beeinträchtigen, wenn die Architektur die Risiken nicht ordnungsgemäß isoliert.

Die ISO 26262 behandelt dieses Problem durch die ASIL-Stufen von A bis D. Je höher das Risiko, desto strenger die Sicherheitsanforderungen. In der Praxis bedeutet dies eine klare Trennung zwischen kritischen und nicht-kritischen Komponenten, eine vorausschaubare zeitliche Planung, kontrollierte Kommunikation und solide Nachweise für die Überprüfung.

Die sichere Programmierung von Speicherinhalten wird auch in Automobil-Systemen immer wichtiger. Eine einzige Speicherfehlererkennung kann ein Sicherheitsziel unterbrechen, eine Steuersignale beschädigen oder Verhaltensweisen erzeugen, die während der Testphase schwer reproduzierbar sind. Aus diesem Grund bewerten Zulieferer zunehmend sicherere Sprachsubsets, strengere C/C++-Praktiken, Laufzeit-Schutzfunktionen und Rust-basierte Komponenten, sofern diese die Architektur und die Zertifizierungspipeline erfüllen.

Industrielle Fertigung

Industrieumgebungen stellen eingebettete Systeme unter physischen, betrieblichen und sicherheitstechnischen Belastungen. Geräte müssen unter Vibrationen, Staub, Hitze, elektrischen Störungen oder instabiler Verbindungsqualität arbeiten. Sie steuern zudem oft reale Geräte: Motoren, Ventile, Förderer, Sensoren, Gateways und sicherheitsbezogene Automatisierungskomponenten.

Dies macht die Sicherheitsentwicklung eingebetteter Systeme in industriellen und Produktionssystemen besonders wichtig. Ein Firmwarefehler kann die Produktion stoppen, aber ein Sicherheitsfehler kann Angreifern den Zugriff auf operative Technologie-Netzwerke ermöglichen. Sichere Boot, Hardware-Vertrauensquellen, signiertes Firmware, Geräteeinheitensichtbarkeit, verschlüsselte Kommunikation, Zugriffskontrolle und sichere Update-Mechanismen werden zu Kernanforderungen der Konstruktion, anstatt zu optionalen Zusatzfeatures.

Das Verhalten in Echtzeit ist eine weitere wesentliche Einschränkung. Eine Cloud-Anwendung kann in der Regel eine geringe Verzögerung vertragen. Ein Controller auf einer Fabrikhalle kann dies jedoch nicht. Embedded Software muss Sensor-Input verarbeiten, Ausgänge auslösen und die Zeitgenauigkeit garantieren, während er über lange Betriebszeiten stabil bleibt. Für KI-basierte Inspektions- oder vorausschauende Wartungssysteme kann eine Edge-Verarbeitung ebenfalls erforderlich sein, wenn Latenzzeit, Bandbreite oder Datenschutz die Cloud-only-Verarbeitung unpraktikabel machen.

Logistik und Lieferkette

Logistikgeräte stehen in der Regel vor anderen Einschränkungen. Trackern, Sensoren für die Kältespeicherung, intelligenten Containern und Flottengeräten muss es gelingen, über lange Zeiträume hinweg mit einer begrenzten Akkulaufzeit und unzusammenhängender Verbindungsfähigkeit zu arbeiten. Sie müssen in Gebieten mit schwacher Netzwerkabdeckung, rauen Temperaturen und eingeschränkter Möglichkeit zur physikalischen Wartung eingesetzt werden können.

In dieser Umgebung konzentriert sich die Embedded-System-Softwareentwicklung auf die Entwicklung von energieeffizienten Systemen, stabile Verbindungen, lokale Datenspeicherung und zuverlässige Über-die-Luft-Updates. Das Gerät muss Daten sammeln, wenn das Netzwerk ausfällt, Ereignisse sicher speichern und diese synchronisieren, sobald die Verbindung wiederhergestellt ist. Ein unzureichender Energieverbrauch kann die Hardware nutzlos machen, bevor die Lieferung eintrifft, während ein schwaches Update-System Tausende von Geräten im Einsatz aussetzen oder sie veraltet lässt.

Die Kältespeicherung erhöht die Verantwortung zusätzlich. Sensoren müssen Temperatur, Luftfeuchtigkeit, Stöße oder die Position zuverlässig erfassen, da diese Daten belegen können, ob Arzneimittel, Lebensmittel oder sensible Materialien innerhalb der zulässigen Grenzen verbleiben. Das Embedded-System muss sowohl den Messprozess als auch die Datensicherung schützen.

Die Disziplinen, die zuverlässige Embedded-Software von der übrigen Software unterscheiden, sind diejenigen, die die Kosten für Änderungen reduzieren. Sie erkennen Probleme bereits, bevor sie noch kostengünstig behoben werden können. Die meisten davon betreffen die Sichtbarkeit und Wiederholbarkeit der Hardware, was man jedoch nicht kostenlos erhält.

• Test auf realem Hardwaregerät, automatisch. Emulatore erkennen logische Fehler, aber Timing- und Peripheriefehler treten nur beim Zielsystem auf, daher sollten Sie Hardware-in-the-Loop-Tests in Ihre Pipeline einbauen, anstatt sie am Ende manuell durchzuführen.
• Schließen Sie jede Verbindung bei der statischen Analyse. Ein Prüfer, der ein Kodierungsstandard wie MISRA C durchsetzt, verhindert eine ganze Reihe von Fehlern, bevor ein Mensch überhaupt über den Code nachdenkt.
• Erstelle so, dass Builds reproduzierbar sind. Verknüpfen Sie Ihre Toolchain- und Abhängigkeitsversionen so, dass das Zertifizierungsbild eindeutig das Bild darstellt, das Sie geliefert haben – was sowohl für Audits als auch für Debugging von entscheidender Bedeutung ist.
• Einfache Beobachtbarkeit integrieren. Ein Gerät ohne Bildschirm kann Ihnen dennoch erklären, warum es fehlschlug, wenn Sie frühzeitig strukturierte Protokollierung und Diagnostik implementieren.
• Maße ziehen, nie voraussetzen. Der Stromverbrauch und die Taktung des Profils auf dem eigentlichen Chip sind wichtig, da Instinkte, die aus Desktop- oder Server-Betrieb stammen, bei einem Mikrocontroller in der Regel falsch sind.
• Planen Sie auf die Wiederherstellung, nicht nur auf Updates. Ein Gerät muss einen Stromausfall während einer Aktualisierung überstehen, daher müssen sowohl ein sicheres Startprogramm als auch ein bekanntes und zuverlässiges Rückfallprogramm entwickelt werden – nicht nur der OTA-Verlauf selbst.

Es ist eine Sache, zu wissen, wie ein guter Embedded-Engineering-Service aussieht. Eine andere Herausforderung ist die Schaffung eines Teams, das diese Dienstleistung kontinuierlich erbringen kann. Dies führt uns zu der Frage, welchen richtigen Partner für die Entwicklung von Embedded-Software man wählen sollte.

Die Entscheidung zwischen der Eigenentwicklung und der Outsourcing-Option hängt von Faktoren wie der verfügbaren Expertise, den Lieferfristen, den regulatorischen Anforderungen sowie Investitionen in Hardware-Labore und Testgeräte ab. Lassen Sie uns uns auf das konzentrieren, was einen kompetenten Partner für Embedded-Software-Entwicklung von einem herkömmlichen Software-Anbieter unterscheidet.

Suchen Sie nach einem Team, das nicht nur in der Firmware, sondern auch in der gesamten Embedded-Plattform Expertise aufweist:

• Kenntnisse in C, C++, und Rust. Ein starker Partner versteht, wann jede Sprache die richtige Wahl ist, anstatt dass man dieselbe Technologie für jedes Projekt verwendet.
• Erfahrung mit der Entwicklung unter Bare-Metal- und RTOS-Umgebungen. Die Auswahl der Laufzeit sollte den Anforderungen des Produkts entsprechen und nicht den bestehenden Präferenzen des Teams.
• Sicherheit ist in den Konstruktionsprozess integriert. Sicherer Bootlauf, Schlüsselverwaltung, verschlüsselte Kommunikation und signierte OTA-Updates sollten Standard-Engineering-Praktiken sein, nicht optionale Dienstleistungen.
• Erprobte Erfahrung in regulierten Branchen. Suchen Sie nach Anhaltspunkten für nachvollziehbare Entwicklungsprozesse, V-Modell-Lieferung, falls zutreffend, und Vertrautheit mit Normen wie IEC 62304, ISO 26262 oder IEC 62443.
• Kenntnisse Ihres Hardware-Ökosystems. Erfahrungen mit den MCU-Familien, den Konnektivitätsprotokollen und den Entwicklungswerkzeugen, auf die Ihr Produkt angewiesen ist, verringern das Integrationsrisiko bereits von Anfang an.
• End-to-End-Lieferfähigkeit. Hardware, Firmware, Cloud-Infrastruktur, Konnektivität und Geräteverwaltung sollten als einheitliches Engineering-Projekt zusammenarbeiten. Die Aufteilung dieser Verantwortlichkeiten auf ein einziges Team reduziert die Handover-Prozesse, verbessert die Verantwortlichkeit und hilft dabei, Integrationsprobleme früher zu erkennen.

Yalantis liefert integrierte Systeme komplett aus einer Hand – kombiniert mit der Entwicklung von Firmware in C, C++ und Rust mit Hardware-Engineering, Cloud-Integration, Sicherheit und Compliance. Unsere Ingenieure unterstützen Projekte von der Prototypenauslegung über die Produktion bis hin zur Inbetriebnahme. Sie helfen Unternehmen dabei, vernetzte Geräte zu entwickeln, die den anspruchsvollen Anforderungen an Zuverlässigkeit und regulatorische Anforderungen genügen.