Embedded Systems sind heute in nahezu jedem elektronischen Gerät verbaut, das eine spezifische Aufgabe erfüllt: vom industriellen Sensor über das medizinische Messgerät bis hin zum vernetzten Wearable. Was auf den ersten Blick wie ein einfaches Gerät wirkt, enthält oft eine komplexe Kombination aus Mikrocontroller, Firmware, Peripherie und Kommunikationsstack. Wer ein Hardware Produkt entwickeln will, muss verstehen, wie diese Systeme aufgebaut sind, welche Designentscheidungen früh getroffen werden müssen und wo die häufigsten Fehler entstehen.
Dieser Artikel richtet sich an technische Entscheider, die ein IoT-Gerät, ein Wearable oder ein industrielles Embedded-System zur Serienreife bringen wollen. Die folgenden Abschnitte behandeln Architektur, Einsatzgebiete, Betriebssysteme, Konnektivität, Energiedesign und den Weg vom Prototyp zur Zertifizierung, mit konkreten Trade-offs und Entscheidungshilfen.
Aufbau und Kernkomponenten eines Embedded Systems
Ein Embedded System besteht aus einem Mikrocontroller oder Mikroprozessor, der eine definierte Aufgabe unter festen Ressourcenbeschränkungen ausführt. Der Unterschied zu einem General-Purpose-Computer liegt in der Spezialisierung: begrenzter RAM (typisch 64 KB bis 2 MB), Flash-Speicher für Firmware, deterministische Ausführung und direkte Hardware-Peripherieanbindung über GPIO, SPI, I2C, UART oder CAN.
Die Wahl der Mikrocontroller-Architektur hat direkte Auswirkungen auf Kosten, Toolchain-Reife und langfristige Lieferverfügbarkeit. ARM-Cortex-M-Derivate (z. B. STM32, NXP LPC/i.MX RT) dominieren den Markt für industrielle und IoT-Anwendungen, weil das Ökosystem aus Compiler-Support, HAL-Bibliotheken und Community-Ressourcen ausgereift ist. PIC-Architekturen werden weiterhin in kostensensitiven, einfachen Steuerungsaufgaben eingesetzt, bringen aber Einschränkungen bei der Peripheriedichte und dem Speicherausbau mit sich.
Häufiger Fehler bei der Komponentenauswahl
Teams wählen oft einen Mikrocontroller auf Basis des Evaluation-Board-Preises, nicht auf Basis der Stückkosten bei Zielvolumen und der Verfügbarkeit über einen 5 bis 10-Jahres-Horizont. Ein Chip, der bei 100 Einheiten attraktiv erscheint, kann bei 10.000 Einheiten durch Lieferengpässe oder EOL-Ankündigungen zum Projektrisiko werden. Dieser Entscheidungsfehler tritt besonders häufig bei Startups auf, die ihren ersten Elektronik-Schaltplan ohne Produktionsperspektive entwerfen.
Typische Einsatzgebiete von Embedded Systems
Embedded Systems finden sich überall dort, wo Rechenleistung, Reaktionszeit und Ressourceneffizienz unter kontrollierten Bedingungen gefragt sind. Die Bandbreite reicht von einfachen Sensorknoten mit Jahrzehnten Batterielaufzeit bis hin zu sicherheitskritischen Steuergeräten in der Medizintechnik.
In der industriellen Automatisierung steuern Embedded Systems Motorcontroller, Feldgeräte und Edge-Computing-Knoten. Hier zählen Determinismus und Langzeitverfügbarkeit mehr als Rechenleistung. In der Medizintechnik kommen zusätzliche Anforderungen hinzu: IEC 62304 für den Software-Lifecycle, IEC 60601 für elektrische Sicherheit und MDR-Konformität für den europäischen Markt. Ein Embedded-System-Prototyp, der diese Anforderungen nicht von Anfang an berücksichtigt, erzeugt Redesign-Kosten von 30.000 bis 100.000 Euro und verzögert die Markteinführung um 6 bis 18 Monate.
Consumer-Wearables und IoT-Geräte stellen andere Anforderungen: minimaler Formfaktor, niedrige Stückkosten und Over-the-Air-Update-Fähigkeit. Ein nicht-konsumerseitiges Beispiel ist ein vernetzter Zustandsmonitor für Industriepumpen, der Vibrationsdaten über LoRa an ein Gateway sendet und lokal auf Anomalien reagiert. Dieser Anwendungsfall erfordert eine andere Sensorik, ein anderes Kommunikationsprotokoll und ein anderes Energiebudget als ein Fitnesstracker, obwohl beide auf demselben Mikrocontroller-Kern basieren könnten.
Betriebssysteme und Firmware in Embedded Systems
Die Entscheidung zwischen Bare-Metal-Firmware, einem RTOS wie FreeRTOS oder Zephyr und einem Linux-basierten System bestimmt Entwicklungsaufwand, Zertifizierbarkeit und Wartbarkeit über den gesamten Produktlebenszyklus.
Bare-Metal eignet sich für einfache, zeitkritische Aufgaben mit wenigen Zustandsübergängen. Sobald mehrere Tasks parallel laufen oder Kommunikationsstacks integriert werden müssen, steigt die Komplexität ohne RTOS exponentiell. FreeRTOS ist etabliert und hat einen geringen Speicher-Overhead (ca. 5 bis 10 KB RAM), bringt aber keine eingebaute Sicherheitszertifizierung mit. Zephyr OS bietet einen modularen, sicherheitsorientierten Ansatz mit wachsendem Ökosystem, erfordert jedoch eine steilere Einarbeitungskurve und längere Buildzeiten.
Risiko bei der RTOS-Auswahl
Ein häufiger Fehler ist die Unterschätzung von Stack-Overflows unter Last. In FreeRTOS führt ein zu klein dimensionierter Task-Stack nicht zu einem sofortigen Absturz, sondern zu sporadischem, nicht reproduzierbarem Fehlverhalten im Feld. Ohne Stack-Monitoring und Watchdog-Integration ist dieses Problem in der Produktion kaum diagnostizierbar und kann zu Rückrufaktionen führen. Wer Firmware Entwicklung beauftragen möchte, sollte explizit nach Stack-Monitoring-Strategien und Watchdog-Konzepten fragen.
Drahtlose Konnektivität in modernen Embedded Systems
Die Wahl des Kommunikationsprotokolls ist eine der folgenreichsten Designentscheidungen, weil sie Antennenlayout, Zertifizierungsaufwand, Stromverbrauch und Cloud-Architektur gleichzeitig beeinflusst.
BLE 5.x ist für kurze Reichweiten (bis ca. 100 m Freifeld) und niedrige Datenraten geeignet und dominiert Wearable-Designs wegen des geringen Stromverbrauchs im Advertising-Modus (ca. 1 bis 5 µA durchschnittlich bei 1-Sekunden-Intervall). Wi-Fi bietet höhere Bandbreite, kostet aber 50 bis 150 mA im aktiven Betrieb, was bei batteriebetriebenen Geräten das Energiebudget dominiert. NB-IoT und LTE-M sind für LPWAN-Anwendungen mit Mobilfunkabdeckung geeignet, erfordern aber SIM-Verwaltung und laufende Konnektivitätskosten von 1 bis 5 Euro pro Gerät und Jahr. LoRa eignet sich für Anwendungen ohne Mobilfunkinfrastruktur, hat aber eine begrenzte Duty-Cycle-Pflicht (1 % in Europa gemäß ETSI EN 300 220), die das Datenvolumen stark einschränkt.
Ein kritisches Integrationsproblem entsteht, wenn das Antennenlayout nicht mit dem RF-Frontend abgestimmt ist. Eine schlecht platzierte PCB-Antenne kann die Sendeleistung um 6 bis 10 dBm reduzieren, was die effektive Reichweite halbiert oder zu Zertifizierungsversagen bei FCC oder CE führt. Dieses Problem wird regelmäßig erst im Pre-Compliance-Test entdeckt, was einen PCB-Redesign-Zyklus von 4 bis 8 Wochen auslöst.
Energieeffizienz als zentrales Designziel
Energieeffizienz ist kein nachgelagertes Optimierungsproblem, sondern ein Systemdesign-Constraint, der bereits im Schaltungsdesign, der Firmware-Architektur und der Kommunikationsstrategie verankert sein muss.
Der Schlafstrom des Mikrocontrollers (typisch 1 bis 10 µA im Tiefschlaf) ist oft nicht der dominante Verbrauchspfad. Externe Sensoren, Spannungsregler mit hohem Quiescent Current und schlecht implementierte Power-Domains können das Gesamtsystem auf 100 µA oder mehr im Ruhezustand halten, selbst wenn der MCU im Tiefschlaf ist. Eine CR2032-Knopfzelle mit 220 mAh hält bei 100 µA Dauerstrom weniger als 3 Monate, bei 10 µA über 2 Jahre. Dieser Unterschied entscheidet über das Produktkonzept.
Eine häufig unterschätzte Fehlerquelle ist das Vergessen von Pull-up-Widerständen an ungenutzten GPIO-Pins, die im Floating-Zustand parasitäre Ströme erzeugen. Ebenso führt ein nicht deaktivierter interner Oszillator zu einem Mehrverbrauch von 0,5 bis 2 mA, der im Systemtest nicht auffällt, aber die Batterielaufzeit im Feld signifikant verkürzt. Design for Manufacturing (DFM) und EMI-Optimierung müssen parallel zu diesen Energieüberlegungen erfolgen, da EMI-Filter und Entkopplungskondensatoren das Stromverhalten beeinflussen.
Von der Idee zum marktreifen Embedded-Produkt
Der Weg vom Konzept zur Serienreife folgt einer vorhersehbaren Struktur, aber die Zeitplanung scheitert regelmäßig an denselben Stellen: Schemadesign ohne Produktionsperspektive, Prototypen ohne Zertifizierungsstrategie und Firmware-Entwicklung ohne Over-the-Air-Update-Konzept.
Ein realistischer Zeitplan für ein IoT-Gerät mittlerer Komplexität sieht wie folgt aus: Konzept und Schemadesign 4 bis 8 Wochen, PCB-Layout und erste Prototypen 6 bis 10 Wochen, Firmware-Entwicklung parallel 8 bis 16 Wochen, Pre-Compliance und Redesign-Zyklen 4 bis 12 Wochen, CE-Zertifizierung 8 bis 14 Wochen. Gesamtdauer: 6 bis 14 Monate, abhängig von Komplexität, Zertifizierungsumfang und Iterationsgeschwindigkeit. Wer ein IoT Produkt zur Serienreife bringen will, muss diese Puffer einplanen, nicht als Worst-Case, sondern als Baseline.
Die Entscheidung, Hardwareentwicklung ohne internes Team über einen externen Dienstleister abzuwickeln, verändert das Risikoprofil: kürzere Time-to-Market durch spezialisiertes Know-how, aber höhere Abhängigkeit von externer Dokumentation und Wissenstransfer. Wer langfristig interne Kompetenz aufbauen will, sollte sicherstellen, dass der Entwicklungspartner vollständige Schaltpläne, Firmware-Quellcode und Testdokumentation übergibt. Fehlende Dokumentation ist einer der häufigsten Gründe, warum Unternehmen nach dem ersten Produkt den Dienstleister nicht wechseln können, obwohl sie es wollen.
Wie Oxeltech bei der Embedded-Systementwicklung unterstützt
Wir bei Oxeltech begleiten Unternehmen, die ein IoT Gerät entwickeln lassen oder ein bestehendes Embedded-System zur Serienreife bringen wollen, durch den gesamten Entwicklungsprozess. Unsere Leistungen umfassen konkret:
- Hardware-Design und Schaltungsentwicklung: Schemadesign, Simulation und PCB-Layout mit Fokus auf DFM, EMI/EMC und Produktionsvorbereitung
- Firmware-Entwicklung: Bare-Metal, FreeRTOS und Zephyr auf ARM-Cortex-, STM32-, NXP- und PIC-Architekturen, inklusive OTA-Update-Konzepten und Stack-Monitoring
- Drahtlose Integration: BLE, Wi-Fi, NB-IoT, LTE-M, LoRa und Zigbee, inklusive Antennenlayout und Pre-Compliance-Vorbereitung
- Zertifizierungsbegleitung: CE, FCC und branchenspezifische Anforderungen (z. B. MDR für Medizintechnik), mit vollständiger Dokumentation für den Prüfprozess
- Vollständiger Wissenstransfer: Schaltpläne, Firmware-Quellcode und Testdokumentation werden vollständig übergeben
Wir haben über 20 Hardwareprodukte vom ersten Konzept bis zur Serienproduktion begleitet, für Kunden in Europa und den USA. Wenn Sie ein konkretes Projekt planen oder eine bestehende Entwicklung beschleunigen wollen, nehmen Sie Kontakt auf und schildern Sie uns Ihren Anwendungsfall. Wir melden uns zeitnah mit einer ersten technischen Einschätzung.
