Firmware Entwicklung für IoT: Grundlagen für Produktmanager

Produktmanager, die zum ersten Mal ein IoT-Gerät zur Serienreife bringen, unterschätzen regelmäßig eine Komponente: die Firmware. Hardware-Entscheidungen wie Prozessor, Sensorik und Gehäuse sind greifbar. Firmware ist es nicht. Dabei bestimmt sie maßgeblich, ob ein Gerät zuverlässig funktioniert, Energie effizient nutzt und Zertifizierungen besteht. Wer die Grundlagen versteht, trifft bessere Entscheidungen früher im Prozess und vermeidet teure Korrekturen kurz vor der Markteinführung.

Dieser Artikel richtet sich an Produktmanager und technische Entscheider, die ein IoT-Produkt entwickeln lassen oder intern steuern und dabei fundierter mit ihrem Entwicklungsteam kommunizieren wollen. Die folgenden Abschnitte decken Architekturentscheidungen, typische Fallstricke und die praktische Zusammenarbeit ab.

Table of Contents

Was Firmware im IoT-Gerät eigentlich steuert

Firmware ist die Software, die direkt auf dem Mikrocontroller läuft und die gesamte Hardware eines IoT-Geräts koordiniert. Sie steuert, wann Sensoren abgefragt werden, wie Daten verarbeitet und über welches Protokoll sie übertragen werden, wann das Gerät schläft und wann es aufwacht. Ohne funktionsfähige Firmware ist ein PCB mit korrektem Schaltplan nur Silizium und Kupfer.

In der Praxis bedeutet das: Firmware entscheidet, ob ein BLE-Gerät mit einer CR2032-Zelle drei Monate oder zwölf Monate läuft. Sie bestimmt, ob ein Sensor-Update Over-the-Air eingespielt werden kann oder ein physischer Zugriff auf das Gerät nötig ist. Bei medizinischen Geräten beeinflusst sie direkt den Zertifizierungsumfang unter IEC 62304. Firmware ist kein nachgelagertes Detail, sondern ein zentraler Produktbestandteil mit direktem Einfluss auf Kosten, Laufzeit und Zulassung.

Wichtige Architekturentscheidungen und ihre Produktauswirkungen

Die drei folgenreichsten Architekturentscheidungen in der frühen Firmware-Entwicklung sind: Betriebssystem-Wahl, Kommunikationsprotokoll-Stack und Update-Mechanismus. Jede dieser Entscheidungen beeinflusst Entwicklungszeit, RAM-Bedarf und Zertifizierungsaufwand.

RTOS-Wahl: FreeRTOS vs. Zephyr

FreeRTOS ist schlank, weit verbreitet und gut dokumentiert. Es eignet sich für Geräte mit weniger als 64 KB RAM und einfachen Task-Strukturen. Zephyr bietet ein vollständiges Treiber-Ökosystem, native BLE-Stack-Integration und Device-Tree-Konfiguration, benötigt aber typischerweise 256 KB Flash und 64 KB RAM als Minimum. Wer ein Gerät mit mehreren Funkprotokollen und OTA-Update-Anforderung entwickelt, kommt mit FreeRTOS schnell an Grenzen. Wer eine kleine Sensor-Node mit fester Funktionalität baut, zahlt mit Zephyr einen unnötigen Overhead-Preis in Speicher und Einarbeitungszeit.

Kommunikationsprotokoll und Stack-Integration

BLE 5.x auf einem nRF52-SoC kostet bei 10.000 Einheiten etwa 1,20 bis 1,80 EUR pro Einheit. Wi-Fi über einen ESP32 liegt in ähnlicher Preisklasse, verbraucht im Sendebetrieb jedoch 10 bis 20-fach mehr Strom. NB-IoT-Module kosten 4 bis 8 EUR, ermöglichen aber Reichweiten, bei denen BLE versagt. Die Entscheidung hängt von Batterievolumen, Sendehäufigkeit und Netzabdeckung ab, nicht von einer universellen Empfehlung. Ein häufiger Fehler: Teams wählen Wi-Fi für eine batteriebetriebene Außenanwendung, weil der Entwickler damit vertraut ist. Das Ergebnis ist eine Akkulaufzeit von Wochen statt Jahren.

OTA-Update-Strategie

Geräte ohne OTA-Mechanismus sind nach dem Deployment de facto eingefroren. Das ist in kontrollierten Industrieumgebungen akzeptabel, bei Consumer-IoT-Produkten jedoch ein Risiko. Ein OTA-Stack benötigt Dual-Bank-Flash, sichere Boot-Verifizierung und einen Rollback-Mechanismus. Das erhöht den Flash-Bedarf um mindestens 50 Prozent und verlängert die Entwicklungszeit um vier bis acht Wochen. Wer diesen Aufwand erst nach dem ersten Produktionslauf einplant, steht vor einem Hardware-Redesign.

Typische Fallstricke in IoT-Firmware-Projekten

Die häufigsten Projektverzögerungen in der IoT-Entwicklung entstehen nicht durch Hardware-Fehler, sondern durch unterschätzte Firmware-Komplexität in drei spezifischen Bereichen.

Erstens: Timing-Probleme zwischen Hardware-Peripherie und Firmware-Treibern. Wenn ein I2C-Sensor nach dem Einschalten 50 ms Initialisierungszeit benötigt und die Firmware diese Verzögerung nicht korrekt implementiert, erscheint der Sensor sporadisch nicht erreichbar. Solche Bugs sind schwer reproduzierbar und kosten erfahrungsgemäß zwei bis vier Wochen Debugging-Zeit.

Zweitens: EMI-Probleme, die erst in der Firmware-Testphase sichtbar werden. Ein schlecht getimter SPI-Bus kann Störungen im BLE-Stack erzeugen, die sich als erhöhte Paketfehlerrate manifestieren. Das Problem liegt an der Schnittstelle von Hardware und Software und ist ohne enge Zusammenarbeit beider Disziplinen nicht lösbar. Wer Hardware-Design und Firmware-Entwicklung an getrennte Teams ohne gemeinsame Schnittstellen-Dokumentation vergibt, riskiert genau dieses Szenario.

Drittens: Zertifizierungsanforderungen, die Firmware-Änderungen erzwingen. Die CE-Zertifizierung für Funkgeräte nach RED dauert typischerweise acht bis vierzehn Wochen. Wenn dabei festgestellt wird, dass der Duty-Cycle-Algorithmus der Firmware nicht normkonform ist, beginnt die Zertifizierung von vorn. Dieses Risiko lässt sich durch frühzeitige Einbindung eines Zertifizierungsberaters und einen zertifizierungskonformen Schaltungsentwurf erheblich reduzieren.

Zusammenarbeit zwischen Produktmanagement und Firmware-Team

Produktmanager, die Firmware als Black Box behandeln, verlieren die Kontrolle über Scope, Timeline und Qualität. Effektive Zusammenarbeit erfordert keine Kenntnisse in C-Programmierung, aber ein Verständnis für drei konkrete Schnittstellen.

Die erste Schnittstelle ist die Anforderungsspezifikation. Firmware-Entwickler benötigen präzise Angaben zu Messhäufigkeit, Datenformat, Schlafmodi und Fehlerverhalten. Vage Anforderungen wie „Gerät soll energieeffizient sein“ erzeugen technische Schulden, weil jeder Entwickler eine eigene Interpretation umsetzt. Eine konkrete Anforderung lautet: „Durchschnittsstromaufnahme unter 50 µA bei einem Messintervall von fünf Minuten und BLE-Übertragung alle 15 Minuten.“

Die zweite Schnittstelle ist das Testprotokoll. Firmware-Tests auf Hardware-Ebene erfordern Testequipment wie Logikanalysatoren, Strommessgeräte und Debug-Probes. Produktmanager sollten sicherstellen, dass Testbudget und Testzeit im Projektplan explizit vorgesehen sind. Projekte, die Testphasen unter Zeitdruck verkürzen, erreichen die Zertifizierung mit offenen Bugs und verlassen sie mit Nachbesserungsschleifen.

Die dritte Schnittstelle ist das Change-Management. Jede Hardware-Änderung nach dem ersten Prototyp hat potenziell Firmware-Auswirkungen. Ein Sensor-Wechsel aus Kostengründen kann einen neuen Treiber erfordern. Produktmanager, die Hardware-Änderungen ohne Firmware-Team-Einbindung freigeben, erzeugen unkontrollierte technische Schulden.

Firmware-Entwicklung mit externem Partner erfolgreich umsetzen

Wer Firmware-Entwicklung beauftragen möchte, steht vor einer spezifischen Herausforderung: Firmware-Qualität ist schwer zu evaluieren, bevor ein Gerät in Produktion geht. Drei Kriterien helfen bei der Partnerauswahl.

Erstens: Referenzprojekte mit vergleichbarem Kommunikationsprotokoll und Zertifizierungsumfang. Ein Partner mit BLE-Erfahrung ist nicht automatisch qualifiziert für ein NB-IoT-Gerät mit LTE-M-Fallback. Zweitens: Dokumentationspraktiken. Professionelle Firmware-Entwicklung produziert Architektur-Dokumentation, Schnittstellenspezifikationen und Testprotokolle, die nach Projektende intern weiterverwendet werden können. Drittens: Hardware-Software-Kompetenz unter einem Dach. Wenn der Firmware-Partner auch das PCB-Layout verantwortet, entfällt eine kritische Kommunikationsschnittstelle, an der Timing- und EMI-Probleme entstehen.

Für Unternehmen, die Hardwareentwicklung outsourcen, ist die Frage der Übergabe ebenfalls entscheidend. Quellcode, Toolchain-Konfiguration, Bootloader und Zertifizierungsdokumentation müssen am Projektende vollständig und nutzbar übergeben werden. Projekte, die diese Übergabe nicht von Anfang an vertraglich definieren, enden in Abhängigkeiten, die spätere Produktiterationen verteuern.

Ein nicht offensichtlicher Aspekt: Embedded-System-Prototypen, die für Investoren-Demos gebaut werden, unterscheiden sich architektonisch von Produktionsdesigns. Wer einen Demo-Prototyp direkt in Serienproduktion überführen will, riskiert, dass Workarounds und Debug-Code in die Serienversion einfließen. Ein sauberer Architektur-Review zwischen Prototyp und Seriendesign ist kein optionaler Schritt, sondern eine Voraussetzung für skalierbare Produktion.

Wie Oxeltech bei der Firmware-Entwicklung für IoT-Produkte unterstützt

Wir bei Oxeltech entwickeln Firmware und Embedded-Software für IoT-Geräte, Wearables und industrielle Systeme, von der ersten Architekturentscheidung bis zur Serienreife. Unser Team vereint Hardware-Design und Firmware-Entwicklung unter einem Dach, was Timing-Probleme, EMI-Risiken und Zertifizierungsverzögerungen systematisch reduziert.

Firmware-Entwicklung auf ARM-Cortex-Architekturen, STM32, NXP und PIC mit FreeRTOS und Zephyr
Integration drahtloser Protokolle: BLE, Wi-Fi, NB-IoT, LTE-M, LoRa, Zigbee, MQTT und HTTP
Energieoptimierung für batteriebetriebene Geräte mit definierten Strombudgets
OTA-Update-Implementierung mit sicherem Boot und Rollback-Mechanismus
Begleitung durch CE-, FCC- und medizinische Zertifizierungsprozesse
Vollständige Quellcode- und Dokumentationsübergabe am Projektende

Wir haben über 20 Hardwareprodukte vom Konzept bis zur Serienproduktion begleitet und arbeiten mit Start-ups, Scale-ups und etablierten Unternehmen in Europa und den USA zusammen. Wenn ein konkretes IoT-Projekt ansteht, sprechen wir gerne über Architektur, Timeline und Zertifizierungsrisiken. Nehmen Sie jetzt Kontakt auf und schildern Sie uns Ihr Projekt.