Ein Hardware-Produkt zu entwickeln ist kein linearer Prozess. Wer ein IoT-Gerät von der Idee zur Serie bringen will, trifft auf eine Kette technischer Entscheidungen, bei denen jede Weiche die nächste beeinflusst. Schaltungsarchitektur, Firmware-Stack, Kommunikationsprotokoll, Zertifizierungsstrategie: Jede dieser Entscheidungen hat direkte Auswirkungen auf Entwicklungskosten, Time-to-Market und Skalierbarkeit. Teams, die diesen Prozess zum ersten Mal durchlaufen, unterschätzen regelmäßig, wie stark frühe Designentscheidungen spätere Phasen blockieren können.

Dieser Artikel beschreibt die typischen Phasen der Elektronikentwicklung, benennt die kritischen Entscheidungspunkte in jeder Phase und zeigt, wo Projekte erfahrungsgemäß scheitern.

Die typischen Phasen im Überblick

Die Entwicklung eines Hardwareprodukts folgt keinem universellen Ablaufplan, aber es gibt eine bewährte Phasenstruktur, die in der Praxis stabil funktioniert: Anforderungsanalyse, Konzept und Architekturentscheidung, Prototypenentwicklung, iterative Validierung, Zertifizierung und schließlich Serienanlauf. Jede Phase hat definierte Eingangsvoraussetzungen und Ausgangskriterien. Wer eine Phase überspringt oder zu früh abbricht, zahlt in einer späteren Phase den Preis.

Ein häufiger Fehler: Teams starten direkt mit dem PCB-Layout, ohne die Systemarchitektur schriftlich fixiert zu haben. Das Ergebnis sind Schaltungsrevisionen ab Revision 3 oder 4, die auf fehlende Anforderungen zurückgehen, nicht auf Designfehler. Bei einem typischen IoT-Gerät mit BLE und Sensorintegration kostet jede zusätzliche PCB-Revision je nach Komplexität zwischen 3.000 und 8.000 Euro an Engineering-Zeit, zuzüglich Prototypenkosten und Zeitverlust von 4 bis 8 Wochen.

Konzept und Anforderungsanalyse als Fundament

Die Anforderungsanalyse ist die Phase mit dem höchsten Hebel und dem niedrigsten wahrgenommenen Aufwand. Hier werden Entscheidungen getroffen, die alle nachfolgenden Phasen in ihrer Komplexität und ihrem Risiko definieren. Welches Kommunikationsprotokoll? Welche MCU-Architektur? Welche Betriebsdauer bei welchem Batterieprofil? Welche Zertifizierungen sind für den Zielmarkt verpflichtend?

Konkret bedeutet das: Ein Gerät für den europäischen Markt mit BLE 5.x benötigt eine CE-Kennzeichnung nach RED. Ein Gerät für die USA benötigt eine FCC-Zulassung. Beides beeinflusst die Antennenkonstruktion, das PCB-Layout und die Firmware-Architektur. Wer diese Anforderungen erst nach dem ersten Prototypen klärt, riskiert ein komplettes Redesign der HF-Sektion. Die Anforderungsanalyse sollte daher ein schriftliches Systemspezifikationsdokument erzeugen, das Funktionsanforderungen, Umgebungsbedingungen, regulatorische Anforderungen und Kostenziele enthält. Dieses Dokument ist der Vertrag zwischen Produktmanagement und Entwicklungsteam.

Ein häufig vernachlässigter Aspekt: Energiebudget und Schlafstromziele. Bei einem batteriebetriebenen IoT-Gerät mit einem Jahr Laufzeit auf einer CR2032 liegt der zulässige Durchschnittsstrom im Bereich von 5 bis 15 µA. Diese Anforderung muss in der Konzeptphase in die MCU-Auswahl, den Sensor-Stack und die Firmware-Architektur einfließen, nicht erst beim Debugging am Prototypen.

Vom Prototyp zur Serienreife: Iterationen und Tests

Prototypenentwicklung ist iterativ. Ein realistischer Plan für ein mittelkomplexes IoT-Gerät sieht zwei bis drei Hardware-Revisionen vor, bevor ein Design für die Serienproduktion freigegeben wird. Wer mit einer Revision plant, plant falsch.

Hardware-Iterationen und ihre Funktion

Die erste Revision (EVT, Engineering Validation Test) dient der Funktionsvalidierung der Kernschaltung. Hier werden Grundfunktionen geprüft: Spannungsversorgung, Kommunikationsschnittstellen, Sensorintegration, erstes Firmware-Bring-up. Fehler in dieser Phase sind erwartet und günstig zu beheben. Die zweite Revision (DVT, Design Validation Test) integriert die Korrekturen aus EVT und validiert das Design unter realen Betriebsbedingungen, inklusive thermischer Tests, EMI-Vorabtests und Akkulaufzeitmessungen. Erst ab DVT-Freigabe beginnt die Vorbereitung für Zertifizierungstests.

Firmware-Entwicklung parallel zur Hardware

Firmware-Entwicklung läuft idealerweise parallel zur Hardware-Entwicklung, nicht sequenziell. Wer auf Hardware wartet, um mit der Firmware zu beginnen, verliert 4 bis 8 Wochen pro Revision. Moderne Entwicklungsumgebungen mit Hardware-Abstraktionsschichten, wie sie in Zephyr RTOS oder FreeRTOS üblich sind, ermöglichen es, Applikationslogik auf Simulatoren oder Evaluierungsboards zu entwickeln, bevor das eigentliche Zielboard verfügbar ist. Das setzt voraus, dass die Schnittstellen zwischen Hardware und Firmware bereits in der Konzeptphase definiert wurden. Wer Schaltungsentwicklung und Simulation von Anfang an integriert, reduziert Überraschungen beim Firmware-Bring-up erheblich.

Ein kritischer Fehler in dieser Phase: Energiesparmodi werden auf das Ende der Firmware-Entwicklung verschoben. Das führt dazu, dass tief in der Applikationslogik Strukturen entstehen, die Low-Power-Modi blockieren, zum Beispiel durch dauerhaft aktive Peripherie oder ineffiziente Polling-Schleifen. Das nachträgliche Refactoring kostet in der Regel 2 bis 4 Wochen und kann Zertifizierungstests verzögern.

Zertifizierung und Markteintritt erfolgreich meistern

Zertifizierung ist kein abschließender Schritt, sondern ein paralleler Prozess, der spätestens mit DVT beginnen muss. CE nach RED, FCC Part 15, RoHS, REACH: Welche Normen gelten, hängt von Produktkategorie, Zielmarkt und eingesetzten Kommunikationstechnologien ab. Medizintechnikprodukte unterliegen zusätzlich der MDR und erfordern ein vollständiges technisches Dossier.

Zeitrahmen für CE-Zertifizierungen nach RED liegen typischerweise bei 8 bis 14 Wochen, sofern das Design in den Vorabtests keine kritischen Abweichungen zeigt. FCC-Zertifizierung dauert ähnlich lang. Wer die Zertifizierung erst nach DVT-Abschluss einplant, verschiebt den Markteintritt um mindestens ein Quartal. Ein häufiger Fehler: Das PCB-Layout wird ohne Rücksicht auf EMV-Anforderungen optimiert, zum Beispiel durch Masseflächen-Unterbrechungen unter Hochfrequenzleitungen oder unzureichende Filterung an Versorgungsleitungen. Das Ergebnis sind Nachbesserungen nach dem ersten EMV-Test, die eine neue PCB-Revision erzwingen.

Für Teams, die ein IoT-Gerät zertifizieren lassen wollen, ohne eigene Zertifizierungserfahrung aufzubauen, ist die Wahl des richtigen Entwicklungspartners entscheidend. Ein Partner, der Zertifizierungsanforderungen bereits in der Schaltungsarchitektur berücksichtigt, reduziert das Risiko kostspieliger Nachiterationen erheblich.

Häufige Fehler bei der Hardwareproduktentwicklung

Die häufigsten Fehler bei der Hardwareentwicklung sind struktureller Natur, nicht technischer. Sie entstehen nicht aus mangelndem Fachwissen, sondern aus falschen Annahmen über den Prozess.

• Unterschätzte Iterationszyklen: Teams planen eine Hardware-Revision ein und budgetieren entsprechend. Zwei bis drei Revisionen sind realistisch. Das Kostenbudget sollte das reflektieren.
• Fehlende Systemspezifikation: Ohne schriftliches Anforderungsdokument gibt es keinen stabilen Referenzpunkt für Designentscheidungen. Änderungen im Scope werden nicht erkannt und akkumulieren sich zu unkontrollierten Mehrkosten.
• Zertifizierung als Nachgedanke: Regulatorische Anforderungen, die erst nach dem DVT bekannt werden, erzwingen Redesigns. CE, FCC und ähnliche Anforderungen müssen in der Konzeptphase in die Architektur einfließen.
• Sequenzielle statt parallele Entwicklung: Hardware und Firmware sequenziell zu entwickeln verdoppelt die Entwicklungszeit. Parallelisierung erfordert klare Schnittstellendefinitionen, ist aber in der Praxis für die meisten Projekte umsetzbar.
• Zu frühe Kostensenkung: Günstigere Komponenten in frühen Revisionen zu verwenden, um Prototypenkosten zu sparen, führt häufig zu Inkompatibilitäten mit der Serienstückliste. Prototypen sollten mit seriennahen Komponenten aufgebaut werden.

Eine Annahme, die regelmäßig scheitert: „Wir können das intern machen und bei Bedarf externe Unterstützung hinzuziehen.“ In der Praxis bedeutet das, dass externe Expertise erst dann eingeholt wird, wenn das Projekt bereits in Schwierigkeiten ist. Hardwareentwicklung auszulagern ist dann am effektivsten, wenn der Partner von Beginn an in die Architekturentscheidungen eingebunden ist, nicht erst zur Fehlersuche.

Wie Oxeltech bei der Hardwareproduktentwicklung unterstützt

Wir begleiten Projekte von der ersten Anforderungsanalyse bis zur Serienproduktion. Das bedeutet konkret: Wir bringen Zertifizierungsanforderungen bereits in die Schaltungsarchitektur ein, entwickeln Hardware und Firmware parallel und reduzieren damit die Anzahl der Revisionszyklen. Über 20 Hardwareprodukte haben wir vom Konzept bis zur Markteinführung begleitet, darunter IoT-Geräte, Wearables und eingebettete Systeme für industrielle und medizinische Anwendungen.

Unser Leistungsangebot für Unternehmen, die einen Elektronikentwicklungsdienstleister suchen:

• Anforderungsanalyse und Systemspezifikation mit Fokus auf Zertifizierbarkeit und Energieeffizienz
• Schaltungsentwicklung, PCB-Layout und Simulation für IoT-, Wearable- und Industrieapplikationen
• Firmware-Entwicklung auf Basis von Zephyr RTOS und FreeRTOS für ARM-Cortex-, STM32- und NXP-Plattformen
• Integration drahtloser Kommunikationstechnologien: BLE, Wi-Fi, LoRa, NB-IoT, LTE-M, Zigbee
• Begleitung durch CE-, FCC- und MDR-Zertifizierungsprozesse
• Unterstützung beim Serienanlauf und der Produktionsoptimierung (DFM)

Wenn du ein IoT-Produkt zur Serienreife bringen willst oder ein bestehendes Design für die Zertifizierung vorbereiten musst, sprechen wir gerne konkret über deinen Projektstand. Nimm Kontakt auf und schildere uns dein Vorhaben, wir melden uns innerhalb von 24 Stunden.

Ähnliche Artikel

• Wann sollte man auf kontinuierliche Vitalwertüberwachung statt auf punktuelle Messung setzen?
• Was sollte man 2026 bei der Entwicklung eines IoT-Gesundheitsgeräts beachten?
• Wie funktioniert drahtloses Laden in ultra-kompakten Wearables?
• Wie sichert man die Datenübertragung in medizinischen Wearables ab?
• Wie entwickelt man ein ultra-kompaktes Wearable-Design?