Ein häufiger Fehler bei der Entwicklung von Hardwareprodukten: Die Embedded-Softwarearchitektur wird erst festgelegt, wenn das PCB-Layout bereits abgeschlossen ist. Das Ergebnis sind nachträgliche Hardware-Revisionen, Zertifizierungsverzögerungen und Kostensteigerungen in der Serienproduktion. Wer ein eingebettetes System entwickelt, steht typischerweise vor zwei grundlegenden Entscheidungen: bare-metal-Implementierung auf einem ressourcenbeschränkten Mikrocontroller oder RTOS-basierte Architektur mit höherem Speicherbedarf und Lizenzaufwand. Beide Pfade haben konkrete Auswirkungen auf Stromverbrauch, Zertifizierungsumfang und Entwicklungszeit.
Dieser Artikel behandelt die technischen Kernentscheidungen der Embedded-Softwareentwicklung: Architektur, Toolchain, Betriebssystemwahl und Zertifizierungsrisiken – mit dem Ziel, dass Sie fundierte Entscheidungen für Ihr Projekt treffen können.
Was ist Embedded-Softwareentwicklung?
Embedded-Software läuft direkt auf einem Mikrocontroller oder Mikroprozessor, hat direkten Zugriff auf Peripherieregister und operiert ohne die Abstraktionsschichten eines allgemeinen Betriebssystems. Der verfügbare RAM liegt typischerweise zwischen 2 KB und 512 KB, der Flash-Speicher zwischen 32 KB und 2 MB – abhängig von der Zielplattform.
Die enge Hardware-Software-Kopplung ist keine Designentscheidung, sondern eine Systemanforderung. Interrupt-Latenzen müssen deterministisch sein, Peripherietreiber müssen auf die exakte Registerstruktur des gewählten Controllers abgestimmt werden, und der Speicherlayout muss zur Linker-Konfiguration passen. Ein Fehler in der Interrupt-Prioritätskonfiguration kann beispielsweise dazu führen, dass ein zeitkritischer Sensor-Callback durch einen niederprioren UART-Handler blockiert wird – mit direkter Auswirkung auf die Messdatenqualität.
Embedded-Systeme arbeiten häufig ohne Benutzerinteraktion: Sie reagieren auf Sensordaten, steuern Aktoren und kommunizieren über Feldbusse oder drahtlose Protokolle. Jede Softwareentscheidung – von der Taktfrequenz bis zur Puffergröße – wirkt sich direkt auf das physische Verhalten des Produkts aus.
Wo wird Embedded-Software eingesetzt?
Embedded-Software kommt überall dort zum Einsatz, wo ein Gerät eine definierte Funktion deterministisch und ohne allgemeines Betriebssystem ausführen muss. Die Anforderungen unterscheiden sich je nach Anwendungsfeld erheblich – und diese Unterschiede bestimmen die Architekturentscheidungen.
- IoT-Entwicklung: Vernetzte Sensoren, Smart-Home-Geräte und Industriemonitoring-Systeme
- Medizintechnik: Patientenüberwachungsgeräte, Insulinpumpen und Diagnosegeräte
- Wearables: Smartwatches, Fitnesstracker und medizinische Wearables
- Industrielle Automatisierung: Steuerungseinheiten, Maschinenregler und Sicherheitssysteme
- Unterhaltungselektronik: Haushaltsgeräte, Fernbedienungen und Audiosysteme
Ein industrieller Condition-Monitoring-Knoten, der Vibrationsdaten per LoRaWAN überträgt, hat andere Anforderungen als eine CE-zertifizierte Insulinpumpe: Beim Monitoring-Knoten dominieren Stromverbrauch und Funkzertifizierung (typisch 6–10 Wochen für RED-Konformität), bei der Insulinpumpe gelten IEC 62304 und ISO 14971 als zwingende Rahmenbedingungen mit Entwicklungsaufwänden von mehreren Personenjahren allein für die Dokumentation. Wer diese Unterschiede bei der Architekturwahl ignoriert, riskiert eine vollständige Neuentwicklung kurz vor der Marktzulassung.
Wie funktioniert die Entwicklung eines Embedded-Systems?
Die Entwicklung eines Embedded-Systems durchläuft mehrere Phasen – von der Anforderungsanalyse über Hardware-Design und Firmware-Entwicklung bis zu Zertifizierung und Serienreife. Entscheidend ist, dass Hardware- und Softwareentwicklung von Beginn an parallel laufen, nicht sequenziell.
Von der Idee zum Prototyp
In der Konzeptphase werden Mikrocontroller-Auswahl, Peripherieschnittstellen und Kommunikationsprotokolle festgelegt. Diese Entscheidungen bestimmen den gesamten weiteren Entwicklungspfad. Ein häufiger Fehler: Der Mikrocontroller wird nach Bekanntheit ausgewählt, nicht nach den tatsächlichen Anforderungen an GPIO-Anzahl, ADC-Auflösung oder verfügbarem DMA. Das führt zu Hardware-Revisionen in späteren Phasen, die typischerweise 4–8 Wochen Verzögerung und 3.000–8.000 € zusätzliche PCB-Kosten verursachen.
Die Firmware-Entwicklung beginnt auf Entwicklungsboards, bevor die eigene Hardware verfügbar ist. Dabei ist darauf zu achten, dass Entwicklungsboard und Zielplattform denselben Mikrocontroller-Kern verwenden – andernfalls sind Timing-Annahmen und Peripherie-Initialisierungen nicht übertragbar.
Von der Fehlersuche zur Serienreife
Nach dem ersten Prototypen folgt eine iterative Phase aus Hardware-Debugging, Firmware-Optimierung und Validierung. Energieeffizienz, EMV-Konformität und Zertifizierungsanforderungen müssen spätestens hier adressiert werden – nicht erst in der Vorserienphase. EMV-Nachbesserungen am PCB-Layout nach einem gescheiterten Vortest kosten erfahrungsgemäß 2–6 Wochen und eine weitere Prototypen-Iteration.
Ein unterschätztes Risiko: OTA-Firmware-Updates (Over-the-Air) werden häufig als nachträgliches Feature behandelt. Wenn der Bootloader nicht von Anfang an für sichere Updates ausgelegt ist, erfordert die Nachrüstung eine vollständige Neuentwicklung des Flash-Speicherlayouts – inklusive Regressionstests aller bestehenden Funktionen.
Welche Programmiersprachen und Tools werden verwendet?
C ist die dominierende Sprache in der Embedded-Entwicklung, weil sie direkten Speicherzugriff, deterministisches Laufzeitverhalten und minimalen Overhead bietet. C++ wird für objektorientierte Abstraktionen eingesetzt, erhöht aber den Flash-Bedarf durch vtable-Mechanismen und kann bei unsachgemäßer Verwendung von Ausnahmebehandlung oder dynamischer Speicherverwaltung zu nicht-deterministischem Verhalten führen. Assembler bleibt relevant für zeitkritische ISR-Routinen und startup-Code.
Die Toolchain-Wahl hängt vom Ziel-Controller ab. Für STM32 (ARM Cortex-M) sind STM32CubeIDE und Keil MDK verbreitet; für NXP-Controller MCUXpresso. Wer auf eine herstellerneutrale Toolchain setzt, wählt häufig ARM GCC mit CMake und OpenOCD – das erhöht die Portierbarkeit, erfordert aber mehr Konfigurationsaufwand beim Einstieg (typisch 1–2 Wochen für ein sauberes Build-System).
FreeRTOS und Zephyr sind die meistgenutzten RTOS-Optionen für IoT-Geräte mit drahtloser Konnektivität. FreeRTOS hat einen geringeren Speicher-Footprint (ab ca. 5 KB RAM) und eine flachere Lernkurve, bietet aber keine eingebaute Treiberverwaltung für Funkmodule. Zephyr bringt ein vollständiges Treibermodell und native BLE/Wi-Fi-Stacks mit, benötigt aber mindestens 20–40 KB RAM und eine deutlich längere Einarbeitungszeit. Für Projekte mit strikten RAM-Limits unter 16 KB ist Zephyr keine praktikable Option.
Ein bekanntes Fehlermuster: Teams wählen ein RTOS, ohne den tatsächlichen Task-Scheduling-Bedarf zu analysieren. Wenn alle zeitkritischen Operationen in einem einzigen Task laufen, bringt das RTOS keinen Mehrwert – erhöht aber den Speicherbedarf und die Debugging-Komplexität.
Was ist der Unterschied zwischen Embedded-Software und Firmware?
Firmware bezeichnet die Softwareschicht, die direkt nach dem Reset-Vektor ausgeführt wird: Bootloader, Peripherie-Initialisierung, Treiber und grundlegende Kommunikationsschnittstellen. Sie liegt im nichtflüchtigen Speicher und ist eng an die Registerstruktur des Controllers gebunden. Embedded-Software umfasst zusätzlich Protokoll-Stacks, Anwendungslogik und RTOS-Schichten, die auf der Firmware aufsetzen.
In der Praxis verschwimmt diese Grenze bei einfachen Mikrocontroller-Projekten ohne RTOS. Die Unterscheidung wird relevant, wenn Softwareschichten unabhängig voneinander aktualisiert werden müssen – etwa wenn ein OTA-Update nur die Anwendungslogik austauscht, der Bootloader aber unveränderlich bleiben soll. Wer dieses Konzept nicht von Anfang an in der Speicherpartitionierung berücksichtigt, kann keine sicheren partiellen Updates implementieren.
Für regulierte Bereiche wie Medizintechnik oder funktionale Sicherheit (IEC 61508) ist die Schichtentrennung keine Konvention, sondern eine Anforderung: IEC 62304 klassifiziert Softwareeinheiten nach Sicherheitsklassen, was eine klare Abgrenzung zwischen Firmware- und Anwendungsschicht voraussetzt.
Wann sollte man einen externen Embedded-Entwickler beauftragen?
Externe Unterstützung ist dann sinnvoll, wenn das interne Team eine konkrete Lücke bei Mikrocontroller-Programmierung, Hardware-Design oder Zertifizierungsprozessen hat – nicht generell bei Kapazitätsengpässen. Der Unterschied ist relevant: Ein externer Entwickler, der ohne Kontextwissen in ein laufendes Projekt einsteigt, benötigt typischerweise 3–6 Wochen Einarbeitung, bevor er produktiv beiträgt.
- Das Unternehmen hat eine Produktidee, aber kein internes Hardware- oder Firmware-Team.
- Ein bestehendes Produkt soll um IoT-Konnektivität oder neue Sensorik erweitert werden.
- Ein Projekt steckt in der Entwicklung fest und benötigt frisches technisches Know-how.
- Die Zertifizierung für Märkte wie die EU oder die USA steht an und erfordert Erfahrung mit Normen und Prüfprozessen.
- Zeitdruck macht den internen Teamaufbau unwirtschaftlich.
Zertifizierungserfahrung ist dabei ein besonders kritischer Faktor: CE-Kennzeichnung nach RED erfordert typischerweise 8–14 Wochen, FCC-Zulassung 10–16 Wochen. Teams ohne Vorerfahrung unterschätzen den Dokumentationsaufwand und die Anzahl der erforderlichen Testiterationen regelmäßig um den Faktor zwei.
Wir bei Oxeltech begleiten Kunden von der Konzeptphase bis zur Serienproduktion – mit Erfahrung aus über 20 abgeschlossenen Hardwareprojekten in den Bereichen IoT, Wearables und Industrieelektronik. Wenn Sie ein konkretes Projekt haben, nehmen Sie gerne Kontakt mit uns auf.
Einen Überblick über unseren Entwicklungsansatz finden Sie auf der Über-uns-Seite von Oxeltech.
Ähnliche Beiträge
- Welche Materialien eignen sich für flexible Wearable-Gehäuse und Trägerstrukturen?
- Wie sichert man die Datenübertragung in medizinischen Wearables ab?
- Was sind die größten technischen Herausforderungen bei der Wearable-Entwicklung?
- Wie integriert man GPS-Tracking energieeffizient in ein Wearable?
- Was kostet die Entwicklung eines Embedded Systems?
