Ein Hardwareprodukt zu entwickeln, ist selten so geradlinig, wie es auf dem Papier aussieht. Zwischen der ersten Skizze und dem fertigen, zertifizierten Gerät in Serienproduktion liegen Monate intensiver Arbeit, zahlreiche technische Entscheidungen mit weitreichenden Konsequenzen und nicht selten unerwartete Rückschläge. Wer ein IoT-Gerät von der Idee zur Serie bringen will, sollte diese Realität frühzeitig einkalkulieren, denn die teuersten Fehler entstehen meist nicht aus Unwissen, sondern aus unterschätzter Komplexität.
Dieser Artikel richtet sich an Teams, die ein konkretes Hardwareprojekt vor sich haben: ein IoT-Gerät, ein Wearable, ein eingebettetes System für industrielle oder medizinische Anwendungen. Die folgenden Abschnitte beleuchten die kritischen Phasen des Entwicklungsprozesses, typische Fallstricke und die Entscheidungen, die den Unterschied zwischen einem erfolgreichen Marktstart und einem kostspieligen Neustart ausmachen.
Die unterschätzten Hürden auf dem Weg zur Serienreife
Der häufigste Planungsfehler in der Hardwareentwicklung ist die Unterschätzung des Aufwands zwischen Prototyp und Serienreife. Ein funktionierender Prototyp ist kein Beweis für ein produktionsreifes Design. Die Strecke von einem handgelöteten Einzelstück zu einem reproduzierbaren, zertifizierten Produkt mit stabiler Stückzahlproduktion kann leicht 40 bis 60 Prozent des Gesamtentwicklungsbudgets ausmachen.
Konkret unterschätzt werden regelmäßig: EMI/EMC-Anforderungen, die erst bei der Zertifizierung sichtbar werden; thermisches Verhalten unter realen Betriebsbedingungen; Toleranzstapel im mechanischen und elektrischen Design; sowie die Lieferkette für Bauteile, die in der Prototypenphase noch problemlos verfügbar waren. Ein typisches Szenario: Ein Team wählt einen Mikrocontroller, der im Einzelbezug lieferbar ist, aber bei 10.000 Einheiten eine Vorlaufzeit von 26 Wochen hat. Das verschiebt den Serienstart um ein halbes Jahr.
Wer ein Embedded-System-Prototyp bauen will, sollte bereits in der Konzeptphase Produktionsaspekte mitdenken. Design for Manufacturing (DFM) ist keine abschließende Prüfung, sondern ein kontinuierlicher Prozess, der von Anfang an in das Design einfließen muss.
Von der Konzeptphase zum ersten Prototyp
Die Konzeptphase legt die Grundlage für alle späteren Entscheidungen. Fehler hier multiplizieren sich durch den gesamten Entwicklungsprozess. Die zentrale Aufgabe ist nicht das Skizzieren von Features, sondern das Definieren von Systemgrenzen: Welche Anforderungen sind nicht verhandelbar? Welche Kompromisse sind akzeptabel?
Anforderungen mit technischen Konsequenzen
Jede Anforderung hat eine technische Konsequenz. Eine Akkulaufzeit von zwei Jahren bei einem BLE-Gerät mit stündlichem Datentransfer schränkt die Wahl des Mikrocontrollers, des Funkmoduls und der Sensorik erheblich ein. Ein Strombedarf von unter 10 µA im Tiefschlaf ist bei vielen ARM-Cortex-M0+-Derivaten erreichbar, bei Cortex-M4-Plattformen mit aktiviertem FPU-Subsystem jedoch nicht ohne explizites Power-Domain-Management. Wer diese Entscheidung zu spät trifft, baut den Prototyp zweimal.
Beim Aufbau des ersten Prototyps gilt: Modularität vor Miniaturisierung. Ein Design mit separaten Subsystemen auf einem größeren PCB erlaubt die unabhängige Fehlersuche und vereinfacht spätere Revisionen erheblich. Die Miniaturisierung folgt in einer zweiten oder dritten Revision, wenn das Systemverhalten verstanden ist. Teams, die direkt auf minimale Baugröße optimieren, riskieren Debugging-Aufwände von mehreren Wochen für Probleme, die auf einem modularen Design in Stunden isolierbar wären.
Hardware-Design, PCB-Layout und Firmware im Zusammenspiel
Hardware-Design, PCB-Layout und Firmware sind keine sequenziellen Phasen, sondern parallele Disziplinen mit starken gegenseitigen Abhängigkeiten. Wer sie nacheinander abarbeitet, zahlt dafür mit Revisionszyklen.
Kritische Schnittstellen zwischen Hardware und Firmware
Ein konkretes Beispiel: Die Wahl des Interrupt-Routing auf dem Schaltplan beeinflusst direkt die Latenz in zeitkritischen Firmware-Routinen. Wird ein Sensor-Interrupt auf einem GPIO-Pin platziert, der im PCB-Layout nahe einer Taktleitung geroutet ist, entstehen Einkopplungseffekte, die im Firmware-Debugging als sporadische Fehlauslösungen erscheinen. Die Ursache liegt im Layout, die Symptome zeigen sich in der Software. Solche Probleme kosten Wochen.
Beim Schaltplan und der Simulation müssen Power-Sequencing, Reset-Logik und Kommunikationsbusse bereits mit Blick auf die Firmware-Architektur ausgelegt werden. Ein I2C-Bus, der mehrere Sensoren mit unterschiedlichen Adressräumen verbindet, muss im Layout so geroutet sein, dass die Signalintegrität bei den verwendeten Taktfrequenzen gewährleistet ist. Bei 400 kHz Fast-Mode sind Leitungslängen und Pull-up-Widerstände nicht mehr vernachlässigbar.
Firmware-Architektur und RTOS-Wahl
Die Entscheidung zwischen einem RTOS wie FreeRTOS oder Zephyr und einer Bare-Metal-Implementierung ist keine Präferenzfrage, sondern eine Systemfrage. FreeRTOS ist bei ressourcenbeschränkten Mikrocontrollern mit unter 64 KB RAM und klar definierten Task-Strukturen die robustere Wahl. Zephyr bietet einen umfangreicheren Hardware-Abstraktionslayer und ist besonders dann vorteilhaft, wenn das Produkt auf mehreren Mikrocontroller-Plattformen laufen soll oder umfangreiche Netzwerkprotokolle wie MQTT über LTE-M integriert werden müssen. Der Trade-off: Zephyr hat eine deutlich steilere Lernkurve und erhöht den initialen Firmware-Entwicklungsaufwand um schätzungsweise 20 bis 30 Prozent gegenüber FreeRTOS bei einfachen Anwendungen.
Zertifizierung und Produktion: Was viele Entwickler zu spät bedenken
Zertifizierungsanforderungen sind keine abschließende Formalität, sondern ein Design-Constraint, der von Anfang an berücksichtigt werden muss. Wer CE-Kennzeichnung, FCC-Zulassung oder medizinische Zertifizierungen nach IEC 62368-1 oder MDR erst nach Abschluss des Hardware-Designs adressiert, riskiert kostspielige Redesigns.
Die CE-Zertifizierung für ein funkfähiges IoT-Gerät dauert unter günstigen Bedingungen 8 bis 14 Wochen und kostet je nach Prüfumfang zwischen 5.000 und 20.000 Euro. Schlägt der erste EMC-Test fehl, kommen Redesign-Kosten, erneute Prototypenproduktion und ein weiterer Testzyklus hinzu. Das verschiebt den Marktstart um 3 bis 6 Monate. Bei Geräten mit integriertem Funkmodul empfiehlt sich der Einsatz vorab zertifizierter Module (z. B. mit FCC-Modular-Approval), die den Zertifizierungsaufwand erheblich reduzieren, allerdings auf Kosten höherer Stückkosten von typischerweise 2 bis 5 US-Dollar pro Einheit gegenüber einer diskreten Implementierung.
Auf der Produktionsseite ist der Übergang von der Prototypenbestückung zur Serienproduktion mit einem EMS-Dienstleister ein eigener Prozess. Gerber-Dateien, Bestückungslisten und Testspezifikationen müssen produktionsgerecht aufbereitet sein. Fehlende In-Circuit-Test-Punkte im PCB-Layout, die im Prototyp kein Problem darstellten, können in der Serienproduktion die Ausschussrate signifikant erhöhen.
Wann ein externer Entwicklungspartner den Unterschied macht
Die Entscheidung, Elektronikentwicklung auszulagern, ist keine Frage der Teamgröße allein. Auch etablierte Unternehmen mit internen Ingenieurteams ziehen externe Partner hinzu, wenn spezifisches Know-how fehlt, Kapazitäten nicht ausreichen oder Zeitdruck besteht.
Ein externer IoT Entwicklungspartner macht dann den Unterschied, wenn das interne Team stark in Software ist, aber wenig Erfahrung mit analogem Hardware-Design oder RF-Layout hat. Oder wenn ein Produkt erstmals einen Zertifizierungsprozess durchläuft und niemand im Team die Anforderungen kennt. In diesen Fällen überwiegen die Kosten eines Partners die Kosten von Fehlern, die ohne diesen Partner entstehen würden.
Kritisch zu bewerten ist dagegen das Outsourcing bei Projekten, bei denen das Kernprodukt-Know-how im Hardware-Design liegt und langfristig intern aufgebaut werden soll. Wer Firmware-Entwicklung beauftragen möchte, ohne dabei internen Wissensaufbau zu betreiben, riskiert eine dauerhafte Abhängigkeit vom externen Dienstleister. Das ist in manchen Geschäftsmodellen akzeptabel, in anderen nicht.
Eine häufige Fehlannahme ist, dass ein externer Partner nur für frühe Phasen sinnvoll ist. In der Praxis zeigt sich, dass Unterstützung beim Übergang von Prototyp zu Serienproduktion, bei der Zertifizierungsvorbereitung und beim Aufbau der Fertigungsunterlagen mindestens genauso wertvoll ist wie die initiale Designarbeit. Teams, die diesen Übergang unterschätzen, verlieren Zeit und Budget in einer Phase, in der beides knapp ist.
Wie Oxeltech bei der Hardwareentwicklung unterstützt
Wir begleiten Hardwareprojekte vom ersten Konzept bis zur Serienproduktion. Unser Leistungsangebot deckt alle kritischen Phasen ab, die in diesem Artikel beschrieben wurden:
- Konzept und Systemarchitektur: Anforderungsanalyse, Komponentenauswahl mit Blick auf Verfügbarkeit, Kosten und Zertifizierungsanforderungen, Systemsimulation
- Hardware-Design und PCB-Layout: Schaltungsentwicklung, Simulation, EMI/EMC-gerechtes Layout, DFM-Optimierung für Serienproduktion
- Firmware-Entwicklung: Embedded Software für ARM-Cortex-Architekturen, STM32, NXP und PIC; RTOS-Implementierungen auf Basis von FreeRTOS und Zephyr; Integration drahtloser Protokolle wie BLE, Wi-Fi, LoRa, NB-IoT und LTE-M
- Prototypenaufbau und Fehlersuche: Aufbau erster Prototypen, systematisches Debugging auf Hardware- und Firmware-Ebene
- Zertifizierung und Serienproduktion: Unterstützung bei CE, FCC und weiteren Zulassungen; Vorbereitung der Fertigungsunterlagen; Begleitung des EMS-Übergangs
Wir haben über 20 Hardwareprodukte durch den gesamten Entwicklungsprozess bis zur Serienreife begleitet, darunter IoT-Geräte, Wearables und Embedded Systeme für industrielle und medizinische Anwendungen. Wenn ein konkretes Projekt ansteht und das interne Team Unterstützung in einer oder mehreren dieser Phasen benötigt, ist ein direktes Gespräch der effizienteste nächste Schritt. Projekt anfragen und gemeinsam klären, wo wir den größten Hebel setzen können.
