Ein IoT-Produkt zu entwickeln bedeutet, gleichzeitig Hardware, Firmware, Konnektivität, Zertifizierung und Produktionslogistik unter einen Hut zu bringen. Teams, die das zum ersten Mal durchlaufen, unterschätzen regelmäßig, wie stark diese Disziplinen voneinander abhängen. Eine Entscheidung im Schaltungsdesign beeinflusst die Zertifizierungskosten. Die Wahl des Mikrocontrollers begrenzt die Protokolloptionen. Wer diese Abhängigkeiten früh versteht, spart Monate und vermeidet kostspielige Redesigns.
Dieser Artikel beschreibt den vollständigen Weg vom ersten Konzept bis zur Serienreife, mit konkreten Entscheidungspunkten, typischen Fehlerquellen und realistischen Zeit- und Kostenrahmen. Ob es darum geht, ein IoT-Produkt entwickeln zu lassen oder intern aufzubauen, die Phasen und Fallstricke sind dieselben.
Die typischen Phasen einer IoT-Produktentwicklung
IoT-Produktentwicklung läuft selten linear. Die Phasen überlappen sich, und Entscheidungen aus Phase eins wirken sich auf Phase vier aus. Trotzdem gibt es eine strukturelle Reihenfolge, die den Gesamtaufwand kontrollierbar hält.
Typische Phasen sind: Anforderungsanalyse und Systemarchitektur, Schaltungsentwicklung und PCB-Layout, Firmware-Entwicklung, Prototypenbau und Validierung, Zertifizierung sowie Serienproduktionsanlauf. Die Anforderungsanalyse ist dabei keine Formalität. Wer hier Kompromisse macht, zum Beispiel bei der Spezifikation der Akkulaufzeit oder der Betriebstemperatur, zahlt das spätestens beim Zertifizierungstest. Für ein industrielles Sensorgerät, das in einer Produktionshalle bei 60 Grad Celsius und hoher Luftfeuchtigkeit betrieben werden soll, bedeutet das eine andere Bauteilauswahl, andere Leiterplattenoberflächen und andere Gehäuseanforderungen als für ein Consumer-Wearable.
Realistischer Gesamtzeitrahmen vom Konzept bis zur ersten Serienlieferung: 12 bis 24 Monate, abhängig von Produktkomplexität, Zertifizierungsumfang und Lieferkettensituation. Teams, die von 6 Monaten ausgehen, planen ohne Puffer für Redesigns nach dem ersten Prototypentest.
Hardware-Design und PCB-Layout: Worauf es wirklich ankommt
Die Schaltungsentwicklung legt den Grundstein für alles, was danach kommt. Fehler hier werden teuer, weil sie oft erst im Prototypentest oder schlimmer, beim EMC-Vortest, sichtbar werden.
Bauteilauswahl und Systemarchitektur
Die Wahl des Mikrocontrollers definiert den Lösungsraum für Firmware, Konnektivität und Energieverbrauch. ARM-Cortex-M-Architekturen wie STM32 oder NXP bieten breite Ökosystem-Unterstützung und gut dokumentierte Low-Power-Modi, sind aber bei sehr kleinen Stückzahlen teurer als PIC-basierte Lösungen. Wer auf Zephyr RTOS setzt, bekommt eine breite Treiberbibliothek, muss aber mit einem höheren Speicherbedarf rechnen: Zephyr-Basisimages beginnen typischerweise bei 64 KB Flash. FreeRTOS ist schlanker, erfordert aber mehr manuelle Konfiguration.
EMI und DFM als Designziele
EMI-gerechtes PCB-Layout ist kein optionaler Schritt. Schlechte Masseflächen, zu lange Hochfrequenzleitungen oder falsch platzierte Entkopplungskondensatoren führen beim CISPR-22- oder FCC-Part-15-Test zu Emissionsüberschreitungen. Ein Redesign nach dem ersten EMC-Test kostet typischerweise 4 bis 8 Wochen und 5.000 bis 15.000 Euro, abhängig von der Änderungstiefe. Design for Manufacturing (DFM) reduziert Bestückungsfehler in der Serienproduktion und sollte ab dem ersten Layout-Review berücksichtigt werden, nicht erst vor dem Produktionsanlauf.
Eine häufige Fehleinschätzung: Teams gehen davon aus, dass ein funktionierender Prototyp automatisch EMC-konform ist. Das gilt nur, wenn EMI-Anforderungen bereits im Layout als Constraint behandelt wurden.
Firmware und drahtlose Konnektivität für IoT-Geräte
Firmware-Entwicklung für IoT-Geräte unterscheidet sich wesentlich von klassischer Embedded-Entwicklung, weil Konnektivität, Energiemanagement und Over-the-Air-Updates (OTA) als Systemanforderungen behandelt werden müssen, nicht als Add-ons.
Protokollwahl unter realen Constraints
BLE 5.x eignet sich für kurze Bursts mit niedrigem Durchsatz und langer Akkulaufzeit, typisch unter 10 µA im Advertising-Modus bei 1-Sekunden-Intervall. Problematisch wird BLE bei Umgebungen mit hoher 2,4-GHz-Interferenz, zum Beispiel in Produktionshallen mit vielen Wi-Fi-Accesspoints. Dort steigt die Paketfehlerrate, und Connection-Timeouts können bei zeitkritischen Anwendungen zu Datenverlust führen.
NB-IoT und LTE-M eignen sich für Geräte mit sporadischer Datenübertragung über weite Strecken, zum Beispiel Asset-Tracker oder Umweltsensoren im Außenbereich. NB-IoT hat jedoch eine höhere Latenz (bis zu mehreren Sekunden für den ersten Verbindungsaufbau nach dem PSM-Schlaf) und ist für latenzempfindliche Anwendungen ungeeignet. LoRa bietet gute Reichweite bei sehr niedrigem Datendurchsatz, unterliegt aber Duty-Cycle-Beschränkungen im europäischen 868-MHz-Band (1% in den meisten Subkanälen), was die maximale Sendehäufigkeit begrenzt.
OTA-Updates und Sicherheit
OTA-Fähigkeit ist für IoT-Geräte in der Serienproduktion keine optionale Funktion. Geräte ohne OTA-Mechanismus können Sicherheitslücken nach dem Deployment nicht schließen, was in regulierten Branchen wie Medizintechnik ein Zertifizierungsrisiko darstellt. Eine sichere OTA-Implementierung erfordert signierte Images, einen Rollback-Mechanismus und einen Bootloader, der unabhängig von der Applikations-Firmware aktualisiert werden kann.
Prototyp, Tests und häufige Stolpersteine
Der erste Prototyp ist kein Produkt. Er ist ein Werkzeug zur Hypothesenvalidierung. Teams, die den Prototypen bereits als Vorserienstand behandeln, überspringen Validierungsschritte, die später als Feldprobleme zurückkommen.
Typische Stolpersteine in dieser Phase: Thermische Probleme unter Last, die im Labortest bei Raumtemperatur nicht sichtbar waren. Spannungseinbrüche beim Senden über Funk, weil die Leitungsführung zur Batterie zu hochohmig ist. Timing-Probleme zwischen Firmware und Hardware, die nur unter bestimmten Betriebsbedingungen auftreten. Für ein medizinisches Wearable, das im klinischen Umfeld eingesetzt werden soll, kommen zusätzlich Biokompatibilitätstests und elektrische Sicherheitsprüfungen nach IEC 60601-1 hinzu, die eigene Prototypeniterationen erfordern können.
Empfehlenswert ist ein strukturierter Testplan, der elektrische Charakterisierung, Funktionstest, Stresstest (Temperatur, Vibration, Feuchtigkeit je nach Einsatzbereich) und Kommunikationsvalidierung umfasst. Wer diesen Plan erst nach dem ersten Prototypen schreibt, verliert Vergleichbarkeit zwischen Revisionen.
Zertifizierung und Serienproduktion erfolgreich meistern
Zertifizierung ist kein finaler Stempel, sondern ein Prozess, der bereits im Design beginnt. Wer CE-Konformität oder FCC-Zulassung als letzten Schritt behandelt, riskiert Redesigns kurz vor dem geplanten Marktstart.
Für den europäischen Markt sind typischerweise relevant: RED (Radio Equipment Directive) für Geräte mit Funkmodul, RoHS, WEEE und je nach Anwendung die Maschinenrichtlinie oder MDR für Medizinprodukte. Zeitrahmen für CE-Zertifizierung inkl. EMC-Test: 8 bis 14 Wochen bei einem akkreditierten Prüflabor, vorausgesetzt, das Design besteht den ersten Vortest. FCC-Zertifizierung für den US-Markt läuft parallel und dauert ähnlich lang.
Beim Produktionsanlauf sind Bauteilverfügbarkeit und Lieferantenqualifizierung die häufigsten Risikofaktoren. Bauteile, die im Prototypen verwendet wurden, können bei Serienmengen nicht lieferbar sein. Eine frühzeitige Alternativbauteilstrategie (Second Source) im Schaltplan reduziert dieses Risiko. Produktionstests (In-Circuit-Test, Funktionstest, Boundary-Scan) müssen als Teil des Produktionskonzepts geplant und nicht nachträglich ergänzt werden.
Mit dem richtigen Entwicklungspartner schneller zum Markt
Teams ohne eigenes Hardware-Know-how oder ohne freie Kapazitäten stehen vor der Entscheidung: intern aufbauen oder Elektronikentwicklung outsourcen. Intern aufbauen dauert länger und bindet Kapital in Infrastruktur und Recruiting. Outsourcing reduziert Time-to-Market, erfordert aber einen Partner, der nicht nur einzelne Disziplinen, sondern den gesamten Entwicklungsprozess verantwortet.
Entscheidend bei der Partnerwahl: Kann der Partner Hardware-Design, Firmware-Entwicklung und Zertifizierungsbegleitung aus einer Hand liefern? Verfügt er über Erfahrung mit dem spezifischen Anwendungsbereich, zum Beispiel Medizintechnik oder industrielle Automatisierung? Liegen nachweisbare Referenzen für Produkte vor, die tatsächlich die Serienproduktion erreicht haben? Ein Partner, der nur Prototypen baut, aber keine Produktionsanlaufunterstützung bietet, verlagert das Risiko zurück ins eigene Team.
Wie Oxeltech bei der IoT-Produktentwicklung unterstützt
Wir bei Oxeltech begleiten IoT- und Embedded-Projekte vom ersten Konzept bis zur Serienreife. Unser Leistungsumfang deckt alle kritischen Phasen ab:
- Hardware-Design und Simulation: Schaltungsentwicklung mit EMI/EMC-Fokus, DFM-gerechtes PCB-Layout und Simulation, Bauteilauswahl mit Second-Source-Strategie
- Firmware-Entwicklung: Embedded Software auf ARM-Cortex-Architekturen (STM32, NXP, PIC), Zephyr RTOS und FreeRTOS, OTA-fähige Architekturen mit sicheren Bootloadern
- Drahtlose Konnektivität: Integration von BLE, Wi-Fi, NB-IoT, LTE-M, LoRa und Zigbee mit protokollspezifischer Optimierung für Energieverbrauch und Reichweite
- Prototypenbau und Validierung: Aufbau und Test von Prototypen, Fehleranalyse, iterative Revisionen bis zur Produktionsreife
- Zertifizierung und Produktionsanlauf: Begleitung durch CE-, FCC- und RED-Prozesse sowie Unterstützung beim Produktionsanlauf inkl. Testkonzept
Wir haben über 20 Hardwareprodukte von der Idee bis zur Serienproduktion begleitet, in Bereichen wie IoT, Medizintechnik, Consumer Electronics und industrielle Automatisierung. Wenn ein konkretes Hardware-Projekt ansteht und das interne Team Unterstützung oder Kapazität benötigt, ist der direkte Weg der schnellste: Projekt anfragen und gemeinsam die nächsten Schritte definieren.
Ähnliche Artikel
- Warum scheitern so viele Hardware Startups schon beim Prototyp?
- Kann man ein Wearable ohne proprietäre Chips kosteneffizient entwickeln?
- Was sollte man bei der Auswahl eines Entwicklungspartners für Wearables beachten?
- Wie lange dauert der Entwicklungszyklus eines Wearable-Produkts?
- Was kostet es, ein Wearable Gerät entwickeln zu lassen?
