Ein eingebettetes System zu bauen ist kein linearer Prozess. Wer ein IoT-Gerät von der Idee zur Serie bringen will, steht vor einer Reihe von Entscheidungen, die sich gegenseitig beeinflussen: Welche Mikrocontroller-Architektur passt zur Anwendung? Welches RTOS ist geeignet? Wann ist ein externer Funkstandard sinnvoll, und wann erhöht er nur die Zertifizierungslast? Dieser Artikel beschreibt den technischen Pfad vom ersten Konzept bis zur Serienreife und benennt die kritischen Entscheidungspunkte, an denen Projekte scheitern oder Verzögerungen entstehen.
Die Fragen betreffen nicht nur Ingenieurteams, sondern auch CTOs und Produktverantwortliche, die Hardware-Projekte steuern, ohne jede Implementierungsebene selbst zu beherrschen. Die folgenden Abschnitte liefern keine generischen Empfehlungen, sondern benennen Bedingungen, Kosten und Risiken für konkrete Entscheidungen.
Komponenten und Architektur eines Embedded Systems
Die Architekturwahl bestimmt Entwicklungsaufwand, Stückkosten und Zertifizierungsumfang. Ein Embedded System besteht aus einem Prozessorkern, Peripherie, Speicher, Stromversorgung und Kommunikationsschnittstellen. Die Entscheidung, welche Komponenten auf einem einzelnen SoC integriert oder als diskrete ICs verbaut werden, hat direkte Auswirkungen auf PCB-Fläche, Leistungsaufnahme und Lieferkettenstabilität.
ARM-Cortex-M-Architekturen dominieren den Embedded-Markt aus gutem Grund: breite Toolchain-Unterstützung, skalierbare Leistungsklassen von M0+ bis M33, und ein reifes Ökosystem an HAL-Bibliotheken. STM32 eignet sich für industrielle Anwendungen mit harten Echtzeitanforderungen; NXP i.MX-Serien für Anwendungen, die Linux-basierte Stacks erfordern. PIC-Architekturen bleiben relevant in kostenoptimierten, niedrigkomplexen Designs mit kleinen Stückzahlen. Die Wahl zwischen diesen Plattformen hängt von drei Faktoren ab: verfügbarer Rechenleistung im Verhältnis zum Energiebudget, Verfügbarkeit zertifizierter Softwarekomponenten, und Langzeitverfügbarkeit des Bauteils.
Ein häufiger Fehler: Teams wählen den leistungsfähigsten verfügbaren Controller, weil er die Entwicklung vereinfacht. Das erhöht die Stückkosten bei 10.000 Einheiten um 0,50 bis 1,50 EUR pro Gerät und kann den Stromverbrauch im Schlafmodus um eine Größenordnung erhöhen, was bei batteriebetriebenen Geräten die Laufzeit direkt reduziert.
Hardware-Design: Von der Schaltung zum PCB-Layout
Das Schaltungsdesign legt die Grundlage für EMV-Verhalten, thermische Stabilität und Fertigungsausbeute. Fehler in dieser Phase sind teuer: Eine Layoutkorrektur nach dem ersten Prototyp kostet typischerweise 2 bis 4 Wochen Verzögerung und 1.500 bis 5.000 EUR für neue Prototypen-Platinen, abhängig von Komplexität und Lagenzahl.
Beim Schaltplan und PCB-Design sind drei Bereiche besonders fehleranfällig: Entkopplung von Versorgungsspannungen, Impedanzkontrolle bei Hochfrequenzleitungen, und thermisches Management von Leistungskomponenten. Fehlende oder falsch platzierte Entkondensatoren erzeugen Störspitzen, die sowohl die eigene Schaltung als auch die EMV-Messung beeinflussen. Bei BLE- und Wi-Fi-Designs mit integrierten Antennen sind der Abstand zur Massefläche und die Impedanz der Feedline auf 50 Ohm zu kontrollieren, sonst verschlechtert sich die Sendeleistung messbar.
DFM und Fertigungsplanung
Design for Manufacturing (DFM) sollte nicht am Ende des Layoutprozesses stehen, sondern von Beginn an in die Bauteilauswahl einfließen. Bauteile mit minimalen Padabständen unter 0,4 mm erhöhen die Bestückungskosten und Fehlerrate. Wer früh mit dem Fertigungspartner abstimmt, welche Gehäuseformen und Rastermaße bevorzugt werden, vermeidet Nacharbeit im Prototypenstadium und reduziert die Ausschussquote in der Serie.
Ein unterschätztes Risiko: Bauteilabkündigungen zwischen Prototyp und Serienanlauf. Bei langen Entwicklungszeiten von 12 bis 24 Monaten ist die Wahrscheinlichkeit hoch, dass mindestens ein kritisches Bauteil als EOL gemeldet wird. Alternative Footprints frühzeitig im Layout vorzusehen kostet wenig, spart aber im Ernstfall einen kompletten Re-Spin.
Firmware-Entwicklung und Betriebssystemwahl
Die Wahl des Betriebssystems beeinflusst Entwicklungsgeschwindigkeit, Zertifizierbarkeit und langfristige Wartbarkeit. Für ressourcenbeschränkte Mikrocontroller mit unter 256 KB RAM stehen zwei realistische Optionen zur Verfügung: FreeRTOS und Zephyr RTOS.
FreeRTOS ist etabliert, gut dokumentiert und in vielen bestehenden Projekten bereits vorhanden. Der Nachteil: kein integriertes Treiber-Framework, keine standardisierte Konnektivitäts-API. Jede Peripherie erfordert eigene Treiberimplementierungen. Zephyr bietet ein einheitliches Device-Tree-Modell, eine aktive Community und wachsende Unterstützung für Sicherheits- und Zertifizierungsanforderungen (IEC 62443, PSA Certified). Der Trade-off: Zephyr hat eine steilere Lernkurve und einen größeren Flash-Footprint, der bei sehr kleinen Controllern (unter 64 KB Flash) zum Problem wird.
Für Medizintechnik-Anwendungen mit IEC 62304-Anforderungen ist die Auditierbarkeit des Betriebssystems ein Auswahlkriterium, das viele Teams zu spät berücksichtigen. Wer ein RTOS ohne entsprechende Dokumentation und Versionierungshistorie einsetzt, riskiert erheblichen Mehraufwand im Zertifizierungsprozess. Wer erfahrene Embedded-Entwickler hinzuzieht, kann diese Weichenstellung frühzeitig treffen.
Drahtlose Konnektivität integrieren
Jeder Funkstandard bringt spezifische Zertifizierungspflichten, Stromverbrauchsprofile und Integrationskomplexität mit. Die Entscheidung für BLE, Wi-Fi, LoRa, NB-IoT oder LTE-M hängt nicht primär von der Reichweite ab, sondern von Datenmenge, Latenzanforderung, Energiebudget und verfügbarer Infrastruktur.
BLE 5.x ist für batteriebetriebene Geräte mit kurzen Datenbursts und Reichweiten unter 50 Metern die energieeffizienteste Option: Stromaufnahme im Advertising-Modus typischerweise unter 10 µA bei 1-Sekunden-Intervall. Der Fehler, der in der Praxis häufig auftritt: BLE-Verbindungsabbrüche durch falsch konfigurierte Connection Parameters. Zu kurze Connection Intervals bei schlechter Funkumgebung führen zu Supervision Timeouts, die die Anwendungsschicht nicht korrekt behandelt und die das Gerät in einem inkonsistenten Zustand hinterlassen.
NB-IoT und LTE-M eignen sich für Anwendungen mit sporadischer Datenübertragung über große Reichweiten, etwa industrielle Sensornetzwerke oder Asset-Tracking. Die Aktivierungszeiten von NB-IoT (PSM-Aufwachzeit 20 bis 60 Sekunden) sind für latenzempfindliche Anwendungen ungeeignet. LoRa ist für private Netzwerke ohne SIM-Abhängigkeit interessant, unterliegt aber Duty-Cycle-Beschränkungen im 868-MHz-Band (1 Prozent in Europa), die den Datendurchsatz auf wenige Bytes pro Stunde begrenzen können.
Zertifizierungsseitig gilt: Jedes Modul mit RED-Zertifizierung (Radio Equipment Directive) reduziert den eigenen Prüfaufwand erheblich. Wer ein eigenes RF-Design ohne zertifiziertes Modul entwickelt, muss mit 8 bis 14 Wochen zusätzlichem Testaufwand und Kosten von 5.000 bis 15.000 EUR für Funkzulassungen rechnen.
Testen, Zertifizieren und Serienreife erreichen
Testen ist kein abschließender Schritt, sondern ein kontinuierlicher Prozess. Hardware-in-the-Loop-Tests, automatisierte Firmware-Validierung und EMV-Vorabtests sollten parallel zur Entwicklung laufen, nicht erst nach dem letzten Prototypen-Spin.
Die CE-Zertifizierung für ein IoT-Gerät mit Funkkomponente umfasst typischerweise RED, RoHS und je nach Anwendung die Maschinenrichtlinie oder MDR (Medizinprodukte). Die Gesamtdauer liegt realistisch bei 10 bis 20 Wochen, wenn alle Unterlagen vollständig vorliegen. Häufige Verzögerung: EMV-Testergebnisse, die auf Layoutfehler zurückzuführen sind, die im Vorabtest nicht identifiziert wurden. Ein Pre-Compliance-Scan in einem akkreditierten Labor kostet 500 bis 2.000 EUR und kann einen kompletten Re-Spin verhindern.
Der Übergang von Prototyp zu Serie ist der Punkt, an dem viele Projekte unterschätzen, wie viel Arbeit noch vor ihnen liegt. Stückzahlbedingte Bauteilsubstitutionen, Fertigungstoleranzen, die im Prototyp keine Rolle spielten, und Qualitätssicherungsprozesse beim Bestücker erfordern eigenständige Ingenieurarbeit. Wer das IoT-Produkt zur Serienreife bringen will, sollte die Serienanlaufphase mit mindestens 20 Prozent des Gesamtentwicklungsbudgets einplanen.
Wie Oxeltech beim Aufbau von Embedded Systems unterstützt
Wir begleiten Hardware-Projekte von der ersten Architekturentscheidung bis zur Serienproduktion. Das umfasst konkret:
- Schaltungsentwicklung und PCB-Layout mit integrierter DFM- und EMV-Analyse
- Firmware-Entwicklung auf Basis von FreeRTOS und Zephyr für ARM-Cortex-, STM32- und NXP-Plattformen
- Integration drahtloser Protokolle: BLE, Wi-Fi, NB-IoT, LTE-M, LoRa, Zigbee
- Unterstützung bei CE-, RED- und branchenspezifischen Zertifizierungen
- Prototypenaufbau, Fehlersuche und Begleitung bis zur Serienanlaufphase
Wir haben über 20 Hardwareprodukte durch den vollständigen Entwicklungszyklus begleitet, von der Konzeptphase bis zum Markteintritt. Teams, die Elektronikentwicklung outsourcen oder ihre internen Kapazitäten gezielt erweitern wollen, erhalten bei uns einen Partner mit nachgewiesener Erfahrung in IoT, Medizintechnik und industrieller Automatisierung. Wer ein konkretes Projekt hat, kann direkt Kontakt aufnehmen und die technischen Anforderungen mit uns besprechen.
Ähnliche Artikel
- Wie entwickelt man ein Smart Wearable für das Patientenmonitoring?
- Was ist der Unterschied zwischen einem Wearable-Prototyp und einem Serienprodukt?
- Wie sichert man die Datenübertragung in medizinischen Wearables ab?
- Warum ist Enerbei der Wearablegieeffizienz -Entwicklung so entscheidend?
- Was kostet es, ein Wearable Gerät entwickeln zu lassen?
