Der komplette Leitfaden zur Firmware-Entwicklung für Embedded- und IoT-Geräte

Am 11. September 2026, EU-Gesetz zur Cybersicherheitsresilienz Erfordert nun von Herstellern, aktiv ausgebaute Schwachstellen in vernetzten Produkten innerhalb von 24 Stunden zu melden. Wenn Ihr Team innerhalb dieses Zeitraums keine verifizierte Aktualisierung auf ein in Betrieb befindliches Gerät bereitstellen kann, ist diese Regelung nun Ihr technisches Problem. Die meisten Teams können das nicht. Nur 8% veröffentlichen innerhalb eines Tages nach der Entdeckung eines Defekts eine Fixierung.

Diese Zahl stammt aus einer Umfrage unter 783 Embedded Professionals in 36 Ländern, die von VDC Research für Memfault. In derselben Studie wurde festgestellt, dass 50,3% der Teams mehr als eine Woche brauchen, um einen Softwarefehler vor Ort zu finden. Für 19,6 % dauert es Monate.

Diese Anleitung behandelt die Firmware-Entwicklung für Embedded- und IoT-Geräte End-to-end: Was genau eine Firmware ist, wie der Firmware-Entwicklungsprozess in Phasen ablauft, wann Bare-Metal eine RTOS-Lösung übertrumpft, wie man eine OTA-Pipeline entwirft, die keine Gerätebrüche verursacht, und wie die Firmware-Compliance in medizinischen, industriellen, automobilischen und logistischen Produkten funktioniert.

Alles darin stammt aus Geräten, die unsere Ingenieure bereits ausgeliefert haben, einschließlich der Teile, die wir beim ersten Mal falsch hatten. Beginnen Sie wo immer Sie möchten.

Firmware-Entwicklung ist die Entwicklung der persistenten, tiefen Ebene arbeitenden Software, die eine Hardware des Geräts direkt, indem es auf seinem Mikrocontroller läuft. Es befindet sich unter jeder Anwendungsebene und wird normalerweise im Produkt integriert und in eine nicht-flüchtige Speicherart gespeichert, anstatt von einem Benutzer installiert zu werden.

Das ist die kurze Antwort. Hier ist, was das in der Praxis bedeutet.

Ihr Gerät verfügt über einen Mikrocontroller mit einer festen Menge an Flash- und RAM-Speicher sowie eine Handvoll Peripheriegeräte. Bis Sie dort ein Betriebssystem einsetzen, verfügt es nicht über ein Betriebssystem. Firmware ist alles, was Sie schreiben, um das Silizium so zu programmieren, dass es wie ein Produkt funktioniert: der Code, der beim Einschalten zuerst ausgeführt wird, der Code, der mit jedem Sensorregister kommuniziert, der Code, der entscheidet, wann man schlafen soll, und der Code, der die eigentliche Funktion des Geräts implementiert.
Ein typischer Firmware-Bilder besteht aus vier Ebenen:

1. Bootloader. Der erste Code, der nach dem Zurücksetzen ausgeführt wird. Er initialisiert die Hardware und überprüft die Signatur des Hauptbildes, bevor er entscheidet, ob es geladen werden soll oder auf eine vorherige Version zurückgegriffen wird. In Geräten mit kabellosen Aktualisierungen wird der Bootloader auch dort durchgeführt, wo die Aktualisierung angewendet wird.
2. Hardware-Abstraktions-Layer und Board-Support-Paket.Das HAL existiert, um die Hardware zu abstrahieren und Speicher und Peripheriegeräte hinter einer stabilen API zu verschlüsseln. Die BSP-Pins verknüpfen diese API mit Ihrer spezifischen Board-Revisionsnummer. Diese Ebene ist der Ort, an dem die meisten Firmware-Entwicklungsprojekte tatsächlich stattfinden, und sie ist die Ebene, die von den meisten Erstprojektentwicklern unterschätzt wird.
3. Scheduler oder RTOS. Entweder ein voll funktionsfähiges Superloop mit Interrupt-Handler oder ein Echtzeit-Betriebssystem wie FreeRTOS oder Zephyr, das Aufgaben und Timer verwalten kann.
4. Anwendungslogik. Die Anwendungsschicht enthält die Firmware, die die Sensormusterdaten verarbeitet, Steuerungszyklen, Zustandsmaschinen, Protokollverarbeitung und Geschäftsregeln enthält.

Die Unterscheidung, die die Leute verwirrt, ist die zwischen Firmware und Gerätedrivern. Treiber sind Teil der Firmware, insbesondere die Funktion, die die Verbindung zwischen der Intent des Anwendungsprogramms und der Registerkarte des Peripheriegeräts herstellt. In der Entwicklung von eingebetteter Firmware schreiben Sie diese Treiber oft selbst, da die von den Herstellern bereitgestellten Treiber entweder nicht vorhanden sind oder zu allgemein sind, um Ihren Leistungs- und Timing-Zielen gerecht zu werden.

Firmware ist die engste dieser Begriffe und bedeutet Code, der an eine bestimmte Hardware gebunden ist. Embedded Software befindet sich eine Ebene höher, und IoT-Firmware ist Firmware, die außerdem einen Netzwerkstack und einen Updatemechanismus enthält, der das Sicherheits- und regulatorische Profil erheblich verändert.

Die meisten Guides behandeln diese Begriffe als Synonyme. Das stimmt jedoch nicht, und der Unterschied bestimmt, welche Normen für Ihr Produkt gelten und wie viel Ihres Engineeringbudgets wo eingesetzt wird.

Die praktische Konsequenz: Ein Metallgehäuse mit Motor steuert, das niemals mit einem Netzwerk in Kontakt kommt, hat eine ganz andere Kostenstruktur als ein batteriebetriebener Sensor, der an eine Cloud-Plattform meldet. Die Anbindung an ein Gerät bringt mehr als nur einen Funkmodul-Treiber. Es beinhaltet eine TLS-Stapel, einen Zertifikatslebenszyklus, einen Update-Pipeline, eine Verpflichtung zur Offenlegung von Sicherheitslücken und eine Supportverpflichtung, die so lange gilt, wie das Produkt selbst.

Dieser letzte Punkt ist es wert, sich darüber zu Gedanken zu setzen. Nach dem CRA ist eine Support-Periode für das Produkt vorgesehen, sodass eine Entscheidung über die Konnektivität in einem zwewöchigen Machbarkeits-Sprint eine Wartungsaufgabe mit Jahren verbunden ist.

Der Prozess der Firmware-Entwicklung besteht aus acht Phasen, beginnend mit den Anforderungen und bis hin zur OTA-Release-Strategie. In regulierten Branchen sind diese Phasen nicht optional, da jede von ihnen einen Nachweis erbringt, den ein Prüfer anfordern wird.

Hier ist die Reihenfolge, die wir bei der Entwicklung von Firmware-Produkten anwenden.

Jede Phase endet mit einem Artefakt anstatt mit einem Gefühl. Phase 1 verpflichtet Sie mit einem Systemarchitekturdokument und einer Matrix zur Nachverfolgbarkeit der Anforderungen, in der die Leistungsanforderungen niedergeschrieben sind. Phase 2 verpflichtet Sie mit einem Entscheidungsschreiben zur Auswahl des Siliziumbaus, in dem der Flash- und RAM-Budget festgelegt ist. Phase 3 verpflichtet Sie mit einer HAL-Spezifikation, bevor ein Treiber existiert.

Phase 4 verpflichtet Sie zu einem Board-Supportpaket mit einer Bring-up-Bericht und Phase 6 verpflichtet Sie zu einer Strommessung an echten Boards statt zu einer Schätzung aus einer Datenblattangabe. Phase 7 und Phase 8 verpflichten Sie zu den Berichten über die Abdeckung und die statische Analyse, die ein Prüfer verlangen wird, sowie zu einer unterzeichneten Freigabebilddatei und einem dokumentierten Rollback-Verfahren.

Zwei Phasen verdienen mehr Aufmerksamkeit als sie normalerweise erhalten.

Phase 2 bestimmt Ihre Wirtschaftlichkeit. Die Wahl eines Mikrocontrollers bestimmt die Kosten für Ihre Einheit, die verfügbare Flashspeicher für A/B-OTA-Partitionen, die Lizenzkosten für Ihre Toolchain und Ihre Abhängigkeit von Ankündigungen des Lebenszyklus eines einzelnen Herstellers. Wir haben gesehen, dass ein Projekt eine Bauteil mit 512 KB Flash gewählt und eine 300 KB große Anwendung erstellt hat, um dann festzustellen, dass die A/B-Partitionierung für sichere Updates 600 KB benötigt hat. Die Lösung war eine Neuverpackung des Boards und eine sechswöchige Verzögerung. Wählen Sie Silizium mit Ihrem OTA-Schema bereits in Planung.

Phase 3 ist der Punkt, an dem man künftig kaufen oder verlieren kann.. Die Definition der HAL-Grenze vor dem Schreiben der Treiber fühlt sich in der zweiten Woche als zusätzliche Arbeit an. Sie ermöglicht es Ihnen, in einer Woche anstatt in einem Vierteljahr einen neuen Sensor zu installieren, wenn Ihr ursprünglicher Lieferant seinen Betrieb einstellt. In unserem Engagement mit der Intertape Polymer Group, einem globalen Verpackungshersteller mit Sitz in Sarasota, entwickelten wir eine skalierbare und wartungsfreundliche Embedded-Softwarearchitektur für ihre nächste Generation automatischer Bandabgabegeräte, um insbesondere sicherzustellen, dass die gleiche Firmwarebasis für mehrere Maschinenvarianten verwendet werden kann. Die Anmerkungen des Kunden in ihrer öffentlichen Überprüfung bezogen sich auf die Codestruktur, die eine zukünftige Entwicklung ermöglicht, was die ganze Idee dieser Phase ist.

Bei der Entwicklung eingebetteter Firmware gewinnt das Bare-Metal-Modell, wenn Ihr Gerät nur wenige gleichzeitig laufende Aktivitäten und zeitkritische Pfade aufweist. Ein RTOS gewinnt, sobald Sie mehrere unabhängige Aktivitäten mit unterschiedlichen Zeitbedarfen oder einen Konnektivitätssatz haben, der eine Blockierung erfordert.

Die Entwicklung von Bare-Metal-Firmware bedeutet, dass Ihre Anwendung den Prozessor vollständig für sich beansprucht und der Kernel keine zwischen den Aufgaben übereinstimmende Entscheidungen trifft. Ein RTOS fügt diese Entscheidungsstufe ein und verlangt dafür Speicherplatz.

Die Entscheidung wird in der Regel eher aus Gewohnheit getroffen als durch Analyse, daher gibt es hier einen Rahmen.

Wenn die Bare-Metal-Firmware-Entwicklung richtig ist. Ein Superloop mit Interrupt-Service-Routines hat keine Scheduler-Aufwände und keine Kontext-Switch-Jitter. Der Steuerungsprozess liest von oben nach unten. Für einen Stromsensor-Loop mit einer Frequenz von 20 kHz oder für ein Gerät, das einen Sensor überwacht und eine LED blinkt, erhöht ein RTOS die Risiken ohne einen Mehrwert zu bieten. Die Mikrocontroller-Firmware-Entwicklung auf Bauteilen wie dem STM32C0 oder der ATtiny-Serie ist aus Notwendigkeit meist „bare-metal“, da der Kernel allein den RAM-Budget verbrauchen würde.

Wenn ein RTOS richtig ist. Wenn Sie einen Funkstack und einen Sensormusterzeitplan haben, die um dieselbe CPU konkurrieren, wird handgefertigtes kooperatives Scheduling zu einer Fehlermaschine. FreeRTOS ist die pragmatische Standardlösung und die am häufigsten eingesetzt. Zephyr ist die stärkere Wahl für vernetzte Produkte, da es mit einem Netzwerkstack, einem Device Tree, einem Treibermodell und der Integration von MCUboot ausgeliefert wird, was Wochen an Konfigurationen erspart. ThreadX (jetzt Eclipse ThreadX) bleibt dort üblich, wo eine vorzertifizierte Kernel-Version für einen Sicherheitsfall von Bedeutung ist.

Wann sollte man auf Embedded-Linux setzen?. Wenn Sie ein Dateisystem, eine Anzeige-Stack, mehrere Netzwerk-Schnittstellen oder die Möglichkeit benötigen, Python oder Container zu betreiben, haben Sie das Mikrokontroller-Bereich verlassen. Das führt Sie in den Bereich der Mikroprozessoren mit externer DRAM, was Ihre Gesamtbetriebskosten und Ihren Stromverbrauch verändert. Der Kompromiss ist gerechtfertigt: Embedded Linux bietet Ihnen ein umfangreiches Software-Ökosystem und kostet Sie deterministische Zeitsteuerung und Ampere.

Drei architektonische Aspekte gehen über alle diese Aspekte hinaus.

Aufgabenplanung und Priorisierung. Legen Sie die Prioritäten anhand der gemessenen Zeitvorgaben fest. Ein häufiges Problem ist es, der Konnektivitätsaufgabe eine hohe Priorität zuzuschreiben, weil die Konnektivität als wichtig wahrgenommen wird – was die Sensoraufgabe dann unterbricht und Ihre Daten beschädigt, genau in dem Moment, in dem das Netzwerk überlastet ist.

Speicherverwaltung. Die dynamische Zuweisung in langlaufenden Firmware-Versionen führt zu Fragmentierung, die Sie im Test nicht reproduzieren und die Sie im Feld bereits im achten Monat bemerken werden. Wir empfehlen statische Zuweisungen und Pools mit fester Größe. Wenn Sie die Zuweisung in der Laufzeit dennoch durchführen müssen, sollten Sie dies beim Initialisieren tun.

Interruptionen verarbeiten. Halten Sie die Interrupt-Serviceroutinen kurz genug, damit sie uninteressant wirken. Setzen Sie eine Flagge oder verschieben Sie sie in eine Warteschlange, und beenden Sie dann die Aktion. Jede echte Arbeit gehört zu einer Aufgabe. Wir haben mehr Fehler bei Feldbusübertragungen, die durch lange ISRs verursacht werden, als durch andere einzelne Ursachen.

Die Entwicklung von IoT-Firmware führt zu zwei Einschränkungen, die die Entwicklung von Firmware für Embedded Systeme Ohne Konnektivität muss man nicht rechnen: Ein Strombudget, das jahrelang mit einer Batterie überleben muss, und ein Konnektivitätsspektrum, das funktionieren muss, wenn das Netzwerk nicht verfügbar ist. Beide sind architektonische Entscheidungen, daher müssen diese vor dem Schreiben von Anwendungscode getroffen werden.

Wie wird die Stromverwendung in der Firmware tatsächlich berechnet?

Starten Sie von der Batterie und arbeiten Sie rückwärts. Eine 2400 mAh-Batterie, die fünf Jahre lang halten soll, liefert Ihnen etwa 55 Mikromgäng für den durchschnittlichen Stromfluss. Ein typischer MCU im aktiven Modus zieht 5 bis 10 Milliampere. Das entspricht einem Verhältnis von etwa 1 zu 150, was bedeutet, dass Ihr Gerät während mehr als 99 Prozent seiner Lebensdauer ausgeschaltet sein muss.

Mit dieser einzigen Berechnung wird das gesamte Firmware-Design neu interpretiert. Man schreibt nicht ein Programm, das gelegentlich schläft; man schreibt einen Schlafrhythmus, der gelegentlich berechnet wird.

Vier Techniken leisten den größten Teil der Arbeit:

• Duty-Cycling. Stromsensoren und Radios werden nur dann benötigt, wenn sie benötigt werden, und messen die tatsächlichen Kosten für die Stromversorgung jeder Peripherieeinheit. Einige Sensoren benötigen länger, um sich zu stabilisieren als um die Messwerte zu erzeugen, was die häufigen kurzen Messungen kostspieliger als die seltenen langen Messungen macht.
• Tiefe Schlafphase mit der richtigen Weckquelle. Verwenden Sie einen RTC-Wecker oder einen GPIO-Interrupt, um den Prozessor zu aktivieren, und halten Sie so viel SRAM frei, wie Ihr Status es zulässt. Der Unterschied zwischen einem Schlafmodus mit 2 Mikroamp und einem mit 20 Mikroamp ist der Unterschied zwischen fünf Jahren und sechs Monaten.
• Sensor-Batching. Die Messwerte werden lokal gespeichert und in Gruppen übertragen. Die Funkübertragung dominiert in der Regel den Energieverbrauch, weshalb zehn Messwerte in einem Paket viel weniger Strom kosten als zehn Pakete einzeln übertragen.
• Ereignisgesteuerte Übertragung. Senden Sie an Grenzübertritte statt zu einem festen Zeitplan. Ein Kälteschrankensensor meldet nur dann, wenn die Temperatur ihren Grenzwert überschreitet; er sendet also nur einen Bruchteil der Daten, die ein Reporter mit festgelemten Intervallen sendet.

Die Wahl eines Konnektivitätsstacks

Die Radioauswahl legt den Leistungsrahmen und die Nutzlastgrenzen fest. Außerdem wird festgelegt, wie viel Firmware Sie schreiben und zertifizieren müssen.

Ein Hinweis zu Matter: Da es mittlerweile in den meisten Diskussionen über Verbraucherprodukte und Bauprodukte zum Thema ist: Der Nutzen der Interoperabilität ist real, und die Kosten für die Firmware sind höher, als die Teams erwarten. Die Inbetriebnahme und die Bereitstellung der Zertifikate während der Produktion fallen sowohl dem Firmware-Team zu, wie auch dem Zertifizierungsprozess selbst.

Randverarbeitung: Wie viel sollte das Gerät entscheiden?

Jeder Byte, den Sie nicht übertragen, ist Energie, die Sie nicht verbrauchen; daher verbessert das Aufbringen von Rechenaufwand auf das Gerät in der Regel gleichzeitig die Akkulaufzeit und die Latenzzeit. Die Grenze ist Ihr Flash- und RAM-Budget sowie Ihre Fähigkeit, die Logik später zu aktualisieren.

Eine vernünftige Regel: Die Geräte sind mit deterministischer Filterung und Schwellenwerten zu versehen und alles, was Sie häufig ändern möchten, sollte in der Cloud verwaltet werden. Grenzwerte für die Anomalieerkennung, die monatlich geändert werden, gehören nicht in ein Firmware-Image, das drei Wochen dauern würde, um sicher auszuliefern.

Unsere Arbeit an individuelle explosionsgeschützte IoT-Sensoren Ein niederländischer Kompressormarketinger entschied sich für diesen Weg. Die Sensor-Firmware übernahm die lokale Signalverarbeitung und die Alarmierung, während die vorausschauenden Wartungsmodelle in der Plattform blieben, wo sie neu trainiert werden konnten.

Diese Trennung senkte die Supportkosten des Kunden um 52 Prozent und führte zu einem Umsatzanstieg von 20 Prozent. Die Geräte konnten auch unter Netzwerkengpässen funktionieren und die Modelle verbesserten sich kontinuierlich, ohne dass eine gesamte Flotte aktualisiert werden musste.

Eine Firmware-Update-Veröffentlichung über das IoT erfolgt in sieben Schritten: Erstellung, Signatur, Veröffentlichung, Herunterladen, Verifizierung, Anwendung und Bestätigung. Jede Phase der OTA-Firmware-Entwicklung hat einen Fehlerfall, für den Sie eine Lösung entwickeln müssen. Die technische Herausforderung konzentriert sich auf die letzten drei Schritte, da hier ein Fehler ein Gerät in einen Stein verwandeln kann.

Die Entwicklung von OTA-Firmware ist die entscheidende und risikoreiche Aufgabe bei einem vernetzten Produkt. Wenn sie richtig gemacht wird, können Sie innerhalb weniger Tage eine Sicherheitslücke in einer gesamten Flotte beheben. Wenn sie falsch gemacht wird, kann ein einzelnes fehlerhaftes Image die installierte Basis und Ihr Image zerstören.

Die sieben Schritte

1. Erstellen. Eine reproduzierbare Build-Methode in CI, die mit einer monoton steigenden Version gekennzeichnet ist. Reproduzierbarkeit ist wichtig, da man schließlich beweisen muss, welche Quelle die gelieferte binäre Datei erstellt hat.
2. Schriftzug. Unterschreiben Sie das Bild mit einer privaten Schlüsseldatei, die in einem HSM gespeichert ist, niemals auf einem Entwickler-Laptop und niemals im Repository. Das Gerät enthält nur die öffentliche Schlüsseldatei.
3. Veröffentlichen. Hochladen auf einen Update-Service mit kohortenbezogener Targetingfunktion, sodass Sie eine Beta-Gruppe oder eine bestimmte Hardware-Revision erreichen können.
4. Download. Das Gerät zieht das Bild über TLS hinweg, vermutet man. Angenommen, die Verbindung bricht in der Mitte ab, da dies bei einem Mobilgerät der Fall ist.
5. Verifizieren. Prüfen Sie die Signatur und den Hash, bevor etwas ausgeführt wird. Prüfen Sie die Version, um eine Rückkehr zu einem bekannten, anfälligen Image zu verhindern.
6. Bewerben. Schreiben Sie in den inaktiven Slot und setzen Sie ein Boot-Flag.
7. Bestätigen. Starten Sie das neue Image und führen Sie einen Selbsttest durch. Markieren Sie das Image erst dann als gut, wenn der Selbsttest besteht. Wenn der Selbsttest fehlschlägt oder der Watchdog ausgelöst wird, kehrt der Bootloader bei der nächsten Zurücksetzung zu der vorherigen Slot-Nummer zurück. Für einen strukturierten Ausgangspunkt liefern OWASP’s IoT Top 10 und NIST IR 8259 beide eine verlässliche Grundlage, auf der Sie Anforderungen vergleichen können. Dies ist nützlich, wenn ein Kunden-Sicherheitsfragebogen vorliegt.

Schritt 7 ist der Schritt, den die Teams überspringen. Ohne einen Bestätigungsabschnitt ist ein Firmware-Image, das bootet, aber nicht auf das Netzwerk zugreifen kann, nicht mehr reparierbar, da das Gerät keine Möglichkeit hat, das Update zu empfangen.

A/B-Partitionierung vs. Ein-Schlitz-Austausch

A/B-Partitionierung Speichert zwei vollständige Anwendungsbilder in Flash. Das Gerät lädt das eine und schreibt das andere, wechselt dann zu dem anderen. Das Zurücksetzen ist sofort und sicher. Der Nachteil ist, dass die Anwendungsflaschendauer verdoppelt wird – genau das Problem, das Teams mit einem frühen Einsatz von Silicon gegenüber denen, die erst nach der Entwicklung von OTA auf Silizium umgestiegen sind, aufhält.

Einzelslot mit einer Zwischenstation Speichert das ankommende Bild in einer externen Flash-Speicherkarte oder einem internen Scratch-Bereich und kopiert es dann über den Bootloader in die Anwendung. Dies erfordert weniger internen Flash-Speicherplatz. Außerdem wird während des Kopiervorgangs ein Fenster angezeigt, in dem ein Stromausfall das Gerät ohne gültige Anwendung zurücklässt. Daher muss der Bootloader in der Lage sein, sich zu erholen und erneut das Bild zu verlangen.

Bei allen batteriebetriebenen oder physisch nicht zugänglichen Geräten wählen Sie A/B. Die Kosten für den Blitz sind geringer als der Preis für einen Lkw-Roll.

Delta-Updates

Eine Delta-Update-Version enthält nur die Differenz zwischen zwei Versionen, was die Nutzlastgröße um 80% oder mehr reduzieren kann. In einer berechneten Mobilfunkflotte ist dies eine direkte Kostenaufwandschwelle. Das Problem ist, dass die Delta-Rekonstruktion erfordert, dass das Gerät eine bytegenaue Kopie des aktuellen Bildes speichert; daher muss jedes Gerät, das von einer bekannten Referenzbasis abweicht, auf ein vollständiges Bild zurückgreifen. Planen Sie für beide Möglichkeiten.

Stagede Einführung und Beobachtbarkeit

Versenden Sie niemals gleichzeitig 100% Geräte aus einer Flotte. Eine praktikable Stufenleiter besteht aus 1%, dann 10%, dann 50% und dann dem Rest, wobei die Stufen jeweils lang genug sind, um eine Störungsanforderung erkennen zu können.

Dies funktioniert nur, wenn die Geräte eine Meldung abgeben, da der Update-Service die Erfolgsraten beim Booten und die Crashberichte pro Kohorte sehen muss. Verwalten Sie eine Geräteflotte von einer Ferne ausy ist der Unterschied zwischen dem Auffinden einer schlechten Aktualisierung um 1% Uhr und der Meldung darüber von der Kundensupportabteilung um 100% Uhr.

OTA-Werkzeuge, die Sie nicht selbst erstellen müssen

Dieses Feature muss man selten von Grund auf neu erstellen. Gängige Optionen sind die AWS IoT Device Management-Jobs, die Azure Device Update for IoT Hub, die native OTA von ESP-IDF für Espressif-Bauteile, MCUboot, einer der wenigen Bootloaders, die sowohl auf Zephyr als auch auf anderen RTOSs funktionieren, Mender für embedded Linux, nRF Cloud FOTA von Nordic sowie Memfault für eine kombinierte Beobachtung und Rollout-Steuerung.

Die Sicherheit der IoT-Firmware basiert auf einem Hardware-Vertrauensgrund und einer verifizierten Boot-Kette, sodass ein Gerät nur Code ausführen darf, der von Ihnen signiert wurde. Alles andere, von verschlüsselten Bildern bis hin zu gesperrten Debug-Ports, stärkt diese Grundlage.

Firmware ist ein beliebter Angriffsziel, da dies der Ort ist, an dem die Schlüssel gespeichert sind und sie nur selten überprüft wird. Durch ein Neustart besteht auch weiterhin die Möglichkeit, Kompromisse zu erzwingen. Die Sicherheitslücken in IoT-Firmware neigen zudem dazu, systemisch zu sein: Eine Schwachstelle in einer einzelnen Bilddatei gilt für alle ausgelieferten Geräte als Schwachstelle.

Die Skala ist dokumentiert. Die Richtlinien der CISA und der NSA für sichere Speicher-Sprachen aus dem Jahr 2025 besagen, dass 75% CVEs In aktiven Angriffen wurden Sicherheitslücken in der Speicherverwaltung verwendet, wie Google Project Zero mitteilte. Von den 58 in freier Wildbahn entdeckten Zero-Days im Jahr 2021 waren 67% mit Speicherbeschädigungen verbunden.

Die Gemeinsame Richtlinien der CISA und der NSA zu sichern gespeicherten Sprachen In einer im Jahr 2025 veröffentlichten Studie wird die Zahl der Fehler bei der Speicherzuweisung bei BadAlloc genannt, einer Gruppe von Sicherheitslücken, die die Behörden bei mehr als 195 Millionen Fahrzeugen und kritischen Infrastrukturdiensten festgestellt haben. Die Zahl der Sicherheitslücken im Bereich Speicher-Sicherheit in industriellen Steuerungssystemen stieg von unter 1.000 im Jahr 2014 auf fast 3.000 im Jahr 2023.

Das Bedrohungsmodell

Sieben Ebenen tragen die meiste Gefahr. Das Stillbild kann extrahiert und rückverfolgt werden – genau das ist der Zweck von Bildverschlüsselung und Flash-Leseschutz. Der Bootvorgang kann durch ein bösartiges Replizieren ersetzt werden. Der Updatekanal kann abgefangen oder rückwärts bis zu einer älteren, signierten Version zurückverfolgt werden – TLS mit Zertifikatsverankerung gehört daher zusammen mit der Signaturprüfung dazu.

Schlüssel können direkt aus der Anwendungslaufzeit entnommen werden, weshalb sie in einem sicheren Element oder einem TPM untergebracht sein sollten. Einige Mikrocontroller bieten für denselben Zweck ihre eigene sichere Enklave an. Die Laufzeitspeicher können in den Code eingebracht werden. Speicherschutzbereiche und Stapelwarnmeldungen erschweren dies, und das Schreiben des Parsing-Codes in einer speicherssicheren Sprache führt dazu, dass die Klasse komplett ausgelöscht wird.

Die letzten beiden Ebenen sind diejenigen, die die Teams vergessen. Drittanbieterbibliotheken enthalten bekannte CVEs, egal ob man sie verfolgt oder nicht. Und physische Schnittstellen bleiben häufiger offen, als es irgendjemand zugeben mag. Daher werden Produktions-Fuse-Funktionen ausgelöst und die UART-Konsole wird in den Release-Builds deaktiviert.

Die unverhandelbaren Punkte

Sicherer Start mit einem Hardware-Vertrauensgrund. Der Bootloader der ersten Stufe muss in einer unveränderlichen Speicherzelle gespeichert sein oder durch einen Hardware-Schutz vor Manipulation geschützt werden. Er muss die nächste Stufe prüfen, bevor er ausgeführt wird. Ohne eine unveränderliche Referenz ist eine Signaturprüfung nutzlos, da ein Angreifer, der die Verifier neu schreiben kann, auch das Ergebnis neu schreiben kann.

Code-Signierung mit echter Schlüsselverwaltung. Private Schlüssel in einem HSM. Separate Schlüssel für Entwicklung und Produktion. Ein dokumentiertes Schlüsselumbruchverfahren, das Sie tatsächlich eingeübt haben.

Anti-Rollback. Eine monotone Versionszählung in ein-mal programmierbarer Speicher, die vor der Annahme eines Bildes überprüft wird. Andernfalls kann Ihre sorgfältig gepatchte Flotte auf eine anfällige Version zurückversetzt werden.

Debug-Interface-Lockdown. Die Öffnung von JTAG und SWD in der Produktion ist eine der häufigsten Feststellungen bei Firmware-Audits und eine der einfachsten zu beheben.

Ein SBOM und ein Sanierungszeitplan. Erstellen Sie für jede Version eine Software-Materialliste in CI und überwachen Sie diese kontinuierlich anhand von CVE-Feeds. Dies ist nun eine gesetzliche Vorgabe in der EU, und dies verändert die Art der Arbeit: Die Reparatur von Firmware von IoT-Geräten wird nicht mehr eine reaktive Aktion, sondern ein planmäßiger Prozess mit einem Service-Level-Ziel wird. Der Großteil der Arbeit wird nun automatisiert durchgeführt. Verhinderung von Sicherheitslücken in IoT-Firmwaren Dies geschieht hier, in der Boot-Chain und dem Updatepfad, lange bevor ein CVE gegen Ihr Produkt eingereicht wird.

Als strukturiertes Ausgangspunkt bieten OWASP’s IoT Top 10 und NIST IR 8259 beide eine verlässliche Grundlage, auf die Sie Ihre Anforderungen abstimmen können. Dies ist nützlich, wenn das Sicherheitsfragebogen eines Kunden vorliegt.

Die Firmware-Compliance wird durch zwei separate Normenfamilien gesteuert: funktionale Sicherheits- und Qualitätsstandards, die Ihrer Branche zuzuordnen sind, sowie Cybersecurity-Regelungen, die auf die Tatsache zurückzuführen sind, dass Ihr Produkt mit einem Netzwerk verbunden ist. Die meisten vernetzten Produkte auf regulierten Märkten müssen nun sowohl den einen als auch den anderen erfüllen.

In diesem Abschnitt verlieren Firmware-Projekte am häufigsten ein Viertel ihrer Kosten. Die Entwicklung von Firmware für den regulierten Markt ist sowohl ein Dokumentations- als auch ein Nachweisungsaufwand, und die Dokumentation, die Sie während der Entwicklung nicht erstellt haben, kann anschließend nicht so rekonstruiert werden, dass ein Prüfer sie akzeptieren kann.

Die beiden Fristen, die jetzt wichtig sind

Die EU-Sicherheitsstandards für den elektronischen Geschäftsverkehr gelten bereits.. Ab dem 1. August 2025 müssen Funkgeräte, die auf den EU-Markt gebracht werden, die Artikel 3(3)(d), (e) und (f) der Radio-Equipment-Richtlinie erfüllen, wobei die harmonisierten Normen EN 18031-1, -2 und -3 gelten. Diese wurden im Amtsblatt mit Einschränkungen erwähnt, insbesondere hinsichtlich des Artikels 3(3)(d) und benutzerdefinierten Passwörtern, sodass sie nur eine partiellige Annahme der Konformität geben. Wenn Ihr Gerät einen Funkempfänger hat, ist dies heute der Punkt, an dem Sie das CE-Kennzeichnungssiegel erhalten.

Der Cyber Resilience Act kommt in zwei Teilen. Die CRA ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflicht gilt ab dem 11. September 2026: eine frühzeitige Benachrichtigung innerhalb von 24 Stunden nach Kenntnis über eine aktiv ausgebaute Sicherheitslücke, anschließend eine vollständige Meldung innerhalb von 72 Stunden. Ein abschließendes Bericht folgt innerhalb von 14 Tagen nach der Verfügbarkeit einer Korrektivmaßnahme. Alle verbleibenden Pflichten gelten ab dem 11. Dezember 2027. Die Strafen sind graduell. Die Verletzung der wesentlichen Anforderungen der Anlage I oder der Verpflichtungen gemäß Artikel 13 und 14 führt zu einer Geldstrafe von 15 Millionen Euro oder 2,5% des globalen Jahresumsatzes. Andere Pflichten führen zu einer Geldstrafe von 10 Millionen Euro oder 2%, und die Weitergabe falscher Informationen an Behörden führt zu einer Geldstrafe von 5 Millionen Euro oder 1%. Die Kommission veröffentlichte ihre Endgültige Implementierungsanleitung Am 27. Juli 2026 sind rund 80 Seiten mit praktischen Beispielen enthalten – eine Lektüre, die vor Ihrer nächsten Architekturüberprüfung Pflicht ist.

Compliance durch die Industrie

Yalantis verfügt über die Zertifizierungen ISO 9001, ISO 13485, ISO 27001 und ISO/IEC 27701 und arbeitet an den IEC-Normen 62304, IEC 62366-1, IEC 82304-1, IEC 62443 und IEC 81001-5-1. In der Praxis bedeutet dies, dass die Konstruktion die von einem Auditoren gewünschten Kontrollen sicherstellt, indem sie die Firmware während des Schreibens erstellt.

Bei einem medizinischen Programm bedeutet das die Einhaltung von IEC 62304 und ISO 13485 in eine integrierte Sprint-Kette einbauen, Dadurch entsteht eine höhere Rückverfolgbarkeit bei jeder Zusammenführung, anstatt dass sie panisch zusammengestellt wird, bevor sie eingereicht wird.

Das Firmware-Toolchain besteht aus vier Teilen, die Sie bewusst auswählen: einer integrierten Entwicklungsumgebung und einem Compiler, einem Hardware-Debugger, einem Build-System und einem CI-Pipeline, die Tests auf realem Silizium durchführen kann. Letzteres ist der Bereich, in dem die meisten Teams am schwächsten sind.

Wo die Low-Code-Entwicklung mit Firmware hilfreich ist und wo sie schädlich ist

Codegeneratoren für Hardware-Entwickler sind mittlerweile wirklich gut geworden. Mit STM32CubeMX, MCUXpresso Config Tools und Zephyr’s devicetree können Sie Uhren und Peripheriegeräte grafisch konfigurieren und Initialisierungskodex generieren. Wenn sie gut eingesetzt werden, beseitigt die Low-Code-Entwicklung der Firmware eine Woche langweiliges Register-Arbeit pro Board-Revision und eliminiert eine Kategorie von Kopier- und Einfügen-Fehlern.

Es tut weh an zwei Stellen. Generierter Code wird oft bei Ihren Änderungen neu generiert, daher muss alles, was Sie anpassen möchten, außerhalb der generierten Bereiche oder in Ihrer eigenen Beschränkungslösung liegen.

Generierte Initialisierungen neigen eher zu sicheren Standardwerten als zu optimalen Leistungswerten, weshalb ein Gerät, das ausschließlich aus Generatorleistung besteht, häufig bis zu zwei bis drei Mal den Ziel-Schlafstrom verbraucht. Verwenden Sie den Generator für den ersten Schritt, messen Sie anschließend die Leistungsverläufe und stimmen diese manuell an.

Die Firmware-Testung erfolgt in vier Schritten, um eine Build gegen ihre Anforderungen zu validieren: Einheitstests auf dem Host, Integrationstests auf dem Host mit mocked Hardware, Hardware-in-the-Loop-Tests auf echten Boards in CI und Fuzz-Tests auf alles, was externe Eingaben analysiert. Die statische Analyse läuft über alle diese Schritte hinweg.

Der Grund, diese Funktion ordnungsgemäß zu implementieren, liegt in den Memfault-Daten, die am Anfang dieser Anleitung erwähnt werden. Testen ist der Prozess, bei dem die Entwicklung der eingebetteten Firmware entweder ihre Zuverlässigkeit erlangt oder diese aufbaut. Teams, die eine Woche brauchen, um einen Fehler in der Hardware zu finden, sind keine langsamen Debugger. Sie verfügen weder über eine Beobachtungsfähigkeit noch über ein Regression-Paket, weshalb jedes Problem von Grund auf neu erstellt werden muss.

• Einheitstests auf Host. Die Kombination von Unity mit CMock, umgeben von Ceedling, ist die etablierte C-Komposition. GoogleTest funktioniert gut für C++. Die Zephyr-Projekte verwenden ztest. Voraussetzung ist eine saubere HAL-Grenze, weshalb Phase 3 des Lebenszyklus so wichtig ist: Code, der direkt mit Registern interagiert, kann nicht außerhalb des Testfelds getestet werden.
• Integrationstests mit simulierten Peripheriegeräten. Simulieren Sie einen SPI- oder I2C-Sensor, der Werte außerhalb des spezifizierten Bereichs zurückgibt, oder einen Flash-Speicher, der während des Betriebes fehlschlägt. Dies sind die Fehlerpfade, die im realen Einsatz auftreten und nie im Labor getestet werden.
• Hardware-in-the-loop. Ein Rack mit Zielplattformen, die an einen CI-Runner angeschlossen sind, mit programmierbaren Stromversorgern und Signalverstärkern. HIL ist der einzige Weg, Zeitverzögerungen zu erkennen, und das ist der Grund, warum Teams diese Funktion für die Zukunft verschieben, da dafür Kapital und Platz benötigt werden. Bauen Sie eine kleine Version früh. Zwei Boards auf einem Raspberry Pi mit einem Relais-Board erfassen mehr als gar nichts und wachsen mit der Zeit weiter.
• Fuzzing. Richt einen Fuzzer auf jeden Parser, der nicht vertrauenswürdigen Input verarbeitet: Ihren OTA-Image-Parser, Ihre BLE-GATT-Handler und Ihre Protokolldekodierer. libFuzzer gegen host-kompilierte Parsing-Code findet echte Fehler schnell.
• Statische Analyse. Analysetools wie Coverity, Polyspace, PC-lint Plus oder clang-tidy mit einem MISRA C-Profil. In regulären Projekten sind statische Analyseberichte Teil des Beweismaterials, daher sollten Sie sie von Anfang an in CI ausführen, anstatt sie rückwirkend zu erstellen.

Die Firmware ist nur eine der Ebenen des Problems. Testen eines angeschlossenen Produkts End-to-end bedeutet, dass bewiesen werden muss, dass die Nähte zwischen einem Gerät und seiner Backend-Plattform unter den gleichen Ausfallbedingungen bestehen, wie sie am Prüfstand erzeugt wurden.

Mit Rust werden Speicherunsicherheitsfehler bei der Kompilierung beseitigt, wodurch die Sicherheitsklasse von etwa drei Vierteln der ausgebeuteten CVEs beseitigt wird. Für sicherheitskritische Firmware ist dies nun eine verlässliche Wahl, anstatt eine experimentelle, da die Toolchain formal zertifiziert wurde.

Die Beweislage ist eindeutig. Die Android-Plattform von Google hat neue Komponenten in Speicher-sichere Sprachen umgesetzt und die Speicher-bedingten Sicherheitslücken von 76% CVEs im Jahr 2019 auf 24% im Jahr 2024 reduziert, ohne die bestehende Codebasis neu zu schreiben.

Die Richtlinie von CISA zur Problematischen Praxis in Bezug auf Produkt-Sicherheit forderte die Hersteller außerdem dazu auf, bis zum 1. Januar 2026 einen Fahrplan zur Sicherheit der Speicher zu veröffentlichen. Dadurch wird Rust von einer technischen Präferenz zu einer Beschaffungssache, die Ihre Kunden stellen werden.

Die Qualifikationsgeschichte schloss die letzte wirkliche Einwände. Ferrocene, Das qualifizierte Rust-Toolchain-Paket von Ferrous Systems ist gemäß TÜV SÜD für ISO 26262 bis ASIL D, IEC 61508 bis SIL 3 und IEC 62304 Klasse C zertifiziert. Ab der Version 26.02 Anfang 2026 enthält eine zertifizierte Untergruppe der Rust-Kernbibliothek die ISO 26262 ASIL B- und IEC 61508 SIL 2-Zertifizierung, die die gewünschte Erweiterung war, die die Teams gespannt erwartet hatten.

Die selektive Migration ist der praktische Weg. Welche der drei Strategien zur Migration einer eingebetteten C- oder C++-Codebasis in Rust Die Kompatibilität hängt davon ab, wie viel des bestehenden Firmware-Codes bewahrt werden soll. Beginnen Sie mit den Komponenten, bei denen ein einzelner Speicherfehler katastrophal ist – also der Boot-Verifizierungslogik und allem, was die Netzwerk-Input-Parsing-Funktionen übernimmt –, und lassen Sie die funktionierenden, gut getesteten Treiber in C-Code.
Das Kisten-Ökosystem für Rost auf beschränktem IoT-Hardware Es ist so reif geworden, dass ein neuer Peripherie-Treiber, der in Rust geschrieben wurde, jetzt etwa so viel kostet wie ein solcher in C.

Die gleiche Disziplin der IoT-Firmware-Entwicklung führt zu sehr unterschiedlichen Projekten je nach Branche, da die Bindungseinschränkungen variieren. In medizinischen Geräten ist dies beispielsweise die Dokumentation, in industriellen Systemen die Protokollkomplexität und die Lebensdauer der Geräte, in der Automobilindustrie die funktionale Sicherheit, in der Logistik die Stromaufnahme.

Medizintechnik und IoMT

Die IEC 62304 ordnet Ihrer Software eine Sicherheitsklasse A, B oder C entsprechend der Schäden an, die ein Ausfall verursachen könnte. Diese Klasse legt fest, wie viel Überprüfung und Dokumentation Sie verlangen müssen. Arbeiten in der Klasse C erfordern eine Einheitsebene mit Rückverfolgbarkeit von jeder Anforderung bis hin zu einem spezifischen Testresultat.

Die praktische Anwendung für die Firmware-Architektur ist die Segregation. Die Isolierung sicherheitskritischer Funktionen in einen separat verifizierten Modul ermöglicht es Ihnen, den Rest der Firmware weiter unten zu klassifizieren, was die Dokumentationslast erheblich reduzieren kann. Die Entscheidung darüber nach der Festlegung der Architektur ist weitaus kostspieliger als die Entscheidung in der ersten Phase. Darüber hinaus sind ISO 14971-Risikomanagement und ISO 13485-Designkontrollen zu berücksichtigen sowie die Dokumentation für MDR oder FDA-Anträge.

Industrie und Fertigung

Die Entwicklung der Firmware erfolgt in einer Umgebung mit installierter Hardware, die über mehrere Generationen Ihres Produkts hinweg verwendet werden kann. Sie werden Modbus RTU neben MQTT neben OPC UA finden – manchmal in derselben Schalttafel – und Sie werden aufgefordert, die Konnektivität an einen Controller zu retrofitieren, dessen Dokumentation verloren gegangen ist.

Die IEC 62443 regelt die Sicherheitsaspekte und verlangt einen dokumentierten sicheren Entwicklungsprozess sowie ein Patch-Management-Prozess. Genau hier hört eine OTA-Funktionalität auf als Feature und wird zu einer Compliance-Anforderung. Die andere wesentliche Einschränkung ist die Segmentierung von OT und IT: Ihr Firmware befindet sich oft an dieser Schnittstelle, und die Netzwerkarchitektur bestimmt, wie Ihre Update-Route aussehen kann.

Automobilindustrie

Ein modernes Elektrofahrzeug verfügt über etwa 100 Millionen Codezeilen in Hunderten elektronischer Steuerungseinheiten und hat eine Lebensdauer von über 20 Jahren. Die ISO 26262 legt den Rahmen für die funktionale Sicherheit mit der ASIL-Klassifizierung fest und beschränkt Ihre Toolchain-Lösung, da ein qualifizierter Compiler zu einer Pflicht wird und keine Option mehr ist.

Die regulatorische Ebene ist es, was die Automotive-OTA auszeichnet. UN R155 erfordert ein zertifiziertes Cybersecurity-Management-System und UN R156 erfordert ein Software-Update-Management-System – beide als Voraussetzung für die Typgenehmigung von Fahrzeugen in der EU und auf Dutzenden weiterer Märkte.

R156 bedeutet, dass Ihre Aktualisierungsmechanismen überprüfbar sein müssen: Jeder genehmigte Kampagnenplan, jede Kennzeichnung der Anwendbarkeit jedes Fahrzeugs, jede Erfassung der Ergebnisse. Die ISO 24089 ist der übliche Implementierungsstandard für diesen Prozess.

Logistik und Kältesysteme

Die Firmware für die Kältespeicherung und die Asset-Tracking-Funktionalität ist zunächst ein Problem in der Stromtechnik. Die Geräte werden in einer Palette geliefert, laufen ein Jahr lang mit einer Knopfzelle oder einer kleinen Primärbatterie und können nicht gewartet werden. BLE übernimmt die lokale Lesung und LoRaWAN oder LTE-M übernimmt die Übertragung über größere Distanzen. Die Ereignisbasierte Übertragung ist es, die die Batterie am Laufen hält.

Wenn die Nutzlast GxP-konform ist, muss die Firmware außerdem eine Audittrail generieren: zeitgestützte Messwerte, die nicht stumm geändert werden können, und eine monotone Uhr, die auch nach einem Reset funktioniert. Diese Anforderung bedeutet in der Regel ein sicherheitsrelevantes Element und eine batteriegestützte RTC – dies sind Entscheidungen der zweiten Stufe.

Erstellen Sie in-house, wenn Firmware Ihr Kernprodukt ist und Sie das Team nach der Markteinführung beschäftigen können. Holen Sie einen Partner hinzu, wenn Sie Fähigkeiten benötigen, die Sie nicht selbst verfügen, und zwar innerhalb eines Zeitrahmens, der eine Einstellung nicht zulässt.

Die Personen, die Firmware für eingeschränkte Zielgeräte entwickeln, gehören zu den schwierigsten Fachkräften in der Embedded-Branche. Die erforderlichen Fähigkeiten sind nicht austauschbar. Ein erfahrener Entwickler von Firmware für die Anwendungsebene ist nicht zwangsläufig die Person, die ein neues Board programmieren oder einen Treiber aus einem Datenblatt erstellen kann.

Drei Modelle sind ehrlich gesagt zu vergleichen wert.

• Häufiges In-House-Verfahren Bietet maximale Kontrolle und eine langsamere Inbetriebnahme. In den meisten Märkten wird es sechs bis neun Monate dauern, eine fähige Embedded-Firmware-Entwicklungsgruppe zu engagieren; bei Bedarf benötigen Sie zudem regulatorische Erfahrung.
• Team-Augmentation Fügt einer bestehenden Teamstruktur spezifische Fähigkeiten hinzu. Dies funktioniert, wenn Sie über die notwendige technische Führung und eine klare Architektur verfügen. Es funktioniert jedoch nicht, wenn Sie sie zur Ersatzlösung für die Architekturentscheidung verwenden.
• Voller Outsourcing Es macht Sinn, wenn es sich um ein erstes angeschlossenes Produkt handelt oder wenn Sie das gesamte Hardware- und Firmware-Stack neu kennenlernen. Was Sie überprüfen sollten, ist, ob der Partner tatsächlich die Hardware abdeckt. Ein Firmware-Team ohne Zugriff auf die Platine bringt Ihnen bei der Worst-Case-Situation die Integrationsrisiken mit sich.

Sechs Fehler sind die Hauptgründe für die Überarbeitung der Firmware. Alle drei kosten Geld, und der dritte, die Überarbeitung über OTA, führt dazu, dass das Board neu programmiert werden muss.

1. Unterestimation der Arbeit von BSP und HAL. Teams investieren in die interessante Anwendungslogik und behandeln die Treiber als Rundungsfehler. Auf einem neuen Board verbrauchen die BSP- und Treiber-Schichten routinemäßig 40% oder mehr der Entwicklungszeit für die integrierte Firmware. Investieren Sie das Budget ausdrücklich.
2. Verzögerung der Hardware-in-the-Loop-Tests. HIL sieht immer so aus, als wäre sie nach der Markteinführung noch zu entwickeln. Dann kommt die erste Feldregression, und man hat keine Möglichkeit, sie zu reproduzieren. Beginnen Sie mit zwei Boards auf einem CI-Runner im zweiten Monat.
3. Die OTA als eine zweite Funktion zu behandeln. Das ist die teure Variante. Die Nachrüstung mit überfließenden Aktualisierungen verändert die Speicherstruktur und den Bootloader. Häufig verändert dies auch das Board. Entscheiden Sie sich für das OTA-Schema, bevor Sie das Silizium auswählen.
4. Die Sicherheit auf den letzten Sprint zu verlassen. Sicherer Bootvorgang mit einem Hardware-Vertrauensgrund ist nicht einfach aufzubauen, da er von den jeweiligen Siliziumfunktionen und den entsprechenden Herstellungsanforderungen abhängt. Ein Gerät, das ohne eine Schlüsselbereitstellung in der Produktion ausgeliefert wurde, hat keine Möglichkeit, einen sicheren Bootvorgang durchzuführen, ohne eine Hardwareänderung vorzunehmen.
5. Unterdokumentation zur Einhaltung der Vorschriften. Spürbarkeit, die nicht während der Entwicklung geschaffen wurde, kann nicht glaubwürdig rekonstruiert werden. Prüfer erkennen rückwirkende Dokumentation an und die Sanierungskosten übersteigen in der Regel das, was eine ordnungsgemäße Umsetzung hätte gekostet.
6. Die anhaltende technische Verschuldung ohne Migrationsplan. Niemand erwartet, dass man eine funktionierende Codebasis in Rust neu schreibt. Kunden und Regulierungsbehörden erwarten zunehmend einen Roadmap zur Speicherzuverlässigkeit. Das Fehlen einer solchen Roadmap stellt heute nicht nur ein technisches Risiko dar, sondern auch ein Beschaffungsrisiko.

Da die Entscheidungen, die ein Firmware-Programm bestimmen, in den ersten zwei Wochen getroffen werden, treffen wir diese zusammen mit den Hardware-Ingenieuren im selben Raum.

Das richtige Zusammenstellen des Mikrocontrollers und des Updatepfads sowie die Anpassung ist eine zweitägige Aufgabe. Falsch machen Sie sie, und Sie müssen das Board neu programmieren. Wir empfehlen, die weniger ansehnlichen Teile zuerst zu bauen, da ein signiertes OTA-Update und ein Testrack mit echten Boards die Langlebigkeit des Boards in den folgenden Jahren garantieren.

Unser R&D-Labor in Warschau wurde genau dafür gebaut. PCB-Design und Prototyping gehen Hand in Hand mit der Firmware, sodass nichts zwischen den Hardware- und Software-Teams voneinander getrennt ist. Wir sind ein Compliance-First-Partner mit über 17 Jahren Erfahrung und über 400 Spezialisten, und die Konstruktion wird dokumentiert, sobald ein Prüfer die Code-Ausführung beauftragt.

Wenn Sie gerade eine dieser Entscheidungen treffen, freuen wir uns, Ihnen behilflich sein zu können.