Wer ein Hardwareprodukt entwickelt, trifft früh eine Entscheidung, die den gesamten Projektverlauf bestimmt: Welche Systemarchitektur trägt die Anforderungen an Leistung, Energiebudget, Zertifizierung und Stückkosten? Dieser Artikel beschreibt die technischen Grundlagen von Embedded Systems unter realen Entwicklungsconstraints – für Teams, die bereits Hardware geliefert haben und die nächste Produktgeneration planen.
Was ist ein Embedded System, und wie unterscheidet es sich von einem PC?
Ein Embedded System ist ein spezialisiertes Computersystem, das in ein größeres Gerät integriert ist und eine klar definierte Aufgabe erfüllt. Ein PC bietet maximale Flexibilität auf Kosten von Energieverbrauch, Footprint und Stückkosten. Ein Embedded System optimiert auf eine Funktion – mit den entsprechenden Einschränkungen bei Erweiterbarkeit und Softwareökosystem.
Der strukturelle Unterschied hat direkte Projektwirkung: Embedded Systems laufen typischerweise auf Firmware oder einem minimalen RTOS ohne grafische Oberfläche. Das ermöglicht deterministisches Verhalten, Betrieb aus einer Coin-Cell-Batterie und PCB-Footprints unter 10 cm². Wer diese Architektur mit PC-ähnlichen Anforderungen – dynamisches Laden von Modulen, vollständiger TCP/IP-Stack auf Applikationsebene – belastet, riskiert Ressourcenengpässe, die erst in der Validierungsphase sichtbar werden.
Typische Merkmale: begrenztes RAM (2–512 KB je nach MCU-Klasse), Flash-gebundener Programmcode, deterministische Interrupt-Latenz und enge Hardware-Software-Kopplung. Wer diese Grenzen in der Anforderungsphase nicht explizit definiert, verliert Iterationszyklen in der Prototypenphase.
Welche Komponenten stecken in einem Embedded System?
Die Komponentenwahl bestimmt Stückkosten, Zertifizierungsaufwand und Energiebudget gleichzeitig. Jede Entscheidung auf Komponentenebene hat Konsequenzen auf Systemebene.
- Mikrocontroller (MCU): ARM-Cortex-M-basierte Controller (STM32, NXP LPC/i.MX RT, Nordic nRF) decken den Großteil industrieller und Consumer-Anwendungen ab. Die Wahl der MCU-Familie bindet das Team an ein Toolchain- und Support-Ökosystem – ein Wechsel nach dem ersten PCB-Spin kostet 4–8 Wochen Neuentwicklung.
- Speicher: Flash für Programmcode, RAM für Laufzeitdaten. Zu knappes RAM-Budget ist der häufigste Grund für späte Architekturänderungen. Kalkulieren Sie Stack, Heap und Kommunikationspuffer getrennt, bevor Sie die MCU-Klasse festlegen.
- Peripherie: GPIO, UART, SPI, I2C und ADC sind Standard. Kritisch ist die Anzahl verfügbarer Peripherieinstanzen: Viele Mid-Range-MCUs haben nur zwei I2C-Controller – bei drei Sensoren mit gleichem Bus-Protokoll entsteht ein Adresskonflikt, der ein Re-Spin erfordert.
- Kommunikationsmodule: BLE, Wi-Fi, LoRa, NB-IoT und LTE-M haben unterschiedliche Zertifizierungsprofile. Ein integriertes Funkmodul mit FCC/CE-Vorzertifizierung (z. B. u-blox, Murata) reduziert den Zertifizierungsaufwand um 6–10 Wochen, erhöht aber die Stückkosten um $1,50–$4,00 gegenüber einem diskreten RF-Design.
- Stromversorgung: Das Energiemanagement entscheidet über Akkulaufzeit und thermisches Verhalten. Ein schlecht dimensionierter LDO kann 20–40 mW Verlustleistung erzeugen – bei einem 100-mAh-Akku bedeutet das eine Laufzeitreduktion von mehreren Stunden.
Das PCB-Layout ist keine nachgelagerte Aufgabe. EMI/EMC-Probleme, die erst im Vorzertifizierungstest sichtbar werden, erzwingen Board-Revisionen mit 3–6 Wochen Verzögerung. Design-for-Manufacturing-Anforderungen – Testpads, Bauteilabstände, Panelisierung – müssen ab dem ersten Layout-Entwurf berücksichtigt werden, nicht beim Übergang zur Serienproduktion.
Wo werden Embedded Systems eingesetzt?
Die Anforderungen unterscheiden sich je nach Segment erheblich – und die Wahl des falschen Referenzdesigns aus einem anderen Segment ist eine der häufigsten Ursachen für Zertifizierungsprobleme.
- IoT-Sensorknoten: Smarte Sensoren und Gateways, die Daten über MQTT oder CoAP übertragen. Kritischer Punkt: Over-the-Air-Update-Mechanismen müssen von Anfang an eingeplant werden. Systeme ohne OTA-Fähigkeit sind nach der Feldinstallation nicht mehr wartbar – ein Fehler, der bei skalierten Deployments (1.000+ Einheiten) zu vollständigen Hardware-Rückrufaktionen führt.
- Medizintechnik: Tragbare Patientenmonitore und Insulinpumpen unterliegen IEC 62304 (Software-Lifecycle) und IEC 60601-1 (elektrische Sicherheit). Die Zulassung nach MDR in der EU dauert je nach Risikoklasse 12–24 Monate. Teams, die diesen Zeitplan unterschätzen, verschieben den Markteintritt um ein volles Entwicklungsjahr.
- Wearables: Fitness-Tracker und medizinische Wearables mit Anforderungen an miniaturisiertes Design (PCB unter 2 cm²) und Akkulaufzeit von 5–14 Tagen. Der Zielkonflikt zwischen Sensorabtastrate und Energiebudget ist hier am schärfsten ausgeprägt.
- Industrielle Automatisierung: Maschinensteuerungen und Robotik mit harten Echtzeitanforderungen (Interrupt-Latenz unter 1 ms). Industrielle Umgebungen erfordern außerdem Betriebstemperaturbereiche von -40 °C bis +85 °C, was die Bauteilauswahl einschränkt und die Stückkosten erhöht.
- Consumer Electronics: Haushaltsgeräte und Smart-Home-Systeme mit hohem Kostendruck. Bei Stückzahlen über 50.000 Einheiten entscheidet eine MCU-Preisdifferenz von $0,20 über die Gesamtmarge.
Ein nicht-kanonisches Beispiel: Industrielle Zustandsüberwachung an rotierenden Maschinen kombiniert Vibrationssensoren, Edge-Inferenz auf einem Cortex-M55 und LoRaWAN-Konnektivität in einem ATEX-zertifizierten Gehäuse. Die ATEX-Anforderungen schränken zulässige Materialien und Schaltungsdesign so stark ein, dass Standardreferenzdesigns nicht übertragbar sind.
Wie funktioniert ein Echtzeitbetriebssystem in einem Embedded System?
Ein RTOS garantiert deterministische Reaktionszeiten durch prioritätsbasiertes Task-Scheduling. Das ist keine Performanceoptimierung, sondern eine Systemsicherheitsanforderung: In sicherheitskritischen Anwendungen muss die maximale Reaktionszeit auf ein Ereignis beweisbar eingehalten werden.
Das RTOS verwaltet Tasks nach Priorität. Tritt ein zeitkritisches Ereignis auf, unterbricht der Scheduler laufende Tasks mit niedrigerer Priorität innerhalb einer definierten Latenz. Dieser Determinismus ist in Anwendungen wie medizinischen Alarmsystemen oder Motorsteuerungen nicht optional.
FreeRTOS benötigt ab ca. 6 KB Flash und 1 KB RAM und eignet sich für ressourcenbeschränkte Cortex-M0/M3-Systeme. Zephyr bringt ein breiteres Protokoll- und Treiberökosystem mit, benötigt aber mindestens 32 KB RAM und 64 KB Flash – auf kleinen MCUs nicht immer realisierbar. Zephyr ist im IoT-Bereich vorteilhaft, wenn BLE, Thread oder Matter nativ unterstützt werden sollen.
Ein häufiger Fehler: Priority Inversion. Wenn ein niedrig priorisierter Task eine Ressource hält, die ein hochpriorisierter Task benötigt, blockiert das System – trotz RTOS. Ohne Mutex-basierte Priority-Inheritance-Mechanismen führt das in Produktionssystemen zu nicht-deterministischen Hängern, die im Testbetrieb selten reproduzierbar sind.
Was ist der Unterschied zwischen Firmware und Embedded Software?
Firmware ist die hardwarenahe Schicht: Sie initialisiert Peripherie, konfiguriert Takte und stellt Treiber bereit. Embedded Software ist der übergeordnete Begriff, der Firmware, Middleware, RTOS-Integration und Applikationslogik umfasst. In einfachen Systemen ohne RTOS ist Firmware die einzige Softwareschicht.
Die Unterscheidung ist für Produktentwickler relevant, weil sie den OTA-Update-Scope definiert. Firmware-Updates erfordern einen zuverlässigen Bootloader mit Rollback-Mechanismus – fehlt dieser, kann ein fehlgeschlagenes Update das Gerät im Feld unbenutzbar machen. Bei skalierten IoT-Deployments ohne physischen Zugang zu den Geräten ist das ein nicht behebbares Problem ohne Hardware-Rückruf.
In medizinisch regulierten Produkten (MDR, FDA 21 CFR Part 11) muss jede Softwareschicht separat versioniert und im technischen Dossier dokumentiert sein. Teams, die Firmware und Applikationslogik nicht sauber trennen, erzeugen Dokumentationsschulden, die den Zulassungsprozess um Monate verzögern. Unsere Embedded-Software-Entwicklung deckt beide Ebenen ab – von der hardwarenahen Firmware bis zur Applikationslogik.
Wie lange dauert die Entwicklung eines Embedded Systems?
Ein erster funktionsfähiger Prototyp auf Basis eines Evaluierungsboards ist in 4–8 Wochen realisierbar. Ein serienreifes Produkt mit eigenem PCB, Zertifizierung und Produktionsübergang dauert typischerweise 9–18 Monate. Der größte Zeitpuffer entsteht nicht in der Entwicklung, sondern in der Zertifizierung und der Fertigungsanlaufphase.
- Konzept und Anforderungsanalyse: Definition von Funktionen, Schnittstellen, Energiebudget und Zertifizierungsumfang. Unvollständige Anforderungen in dieser Phase sind der häufigste Grund für späte Architekturänderungen.
- Hardware-Design und Simulation: Schaltplan, PCB-Layout, Signalintegritätssimulation und erste EMI/EMC-Analyse. Ein Re-Spin wegen EMC-Problemen kostet 3–6 Wochen und $5.000–$15.000 für Prototypenfertigung und Testwiederholung.
- Prototypenaufbau und Fehlersuche: Erste Muster werden bestückt und iterativ validiert. Planen Sie mindestens zwei Hardware-Revisionen ein.
- Firmware-Entwicklung: Treiber, RTOS-Integration, Kommunikationsstack und Applikationslogik. Wird parallel zur Hardware entwickelt – erfordert enge Abstimmung, um Schnittstellenänderungen nicht doppelt zu implementieren.
- Zertifizierung: CE (RED-Direktive) dauert 6–12 Wochen für Funkprodukte, FCC vergleichbar. Medizinische Zulassungen nach MDR Klasse IIa: 12–18 Monate. Diese Zeiträume sind nicht komprimierbar.
- Serienproduktion: Übergang zur Fertigung mit Teststrategie, Produktionsprogrammierung und Qualitätssicherung. Fehlende Produktionstests (ICT, Functional Test) führen zu erhöhten Ausschussraten und Feldausfällen.
Teams unterschätzen konsistent den Aufwand für Produktionstests und OTA-Infrastruktur. Beides wird als nachgelagerte Aufgabe behandelt und verzögert den Serienanlauf um 4–8 Wochen. Wenn Sie ein konkretes Projekt planen, nehmen Sie Kontakt über unsere Kontaktseite auf.
