IoT-Geräte sind längst kein Nischenthema mehr. Vom Temperaturmesser in der Produktionshalle bis zum medizinischen Wearable am Handgelenk: Die Bandbreite vernetzter Hardware ist enorm, und die Anforderungen an Entwicklungsteams wachsen entsprechend. Wer ein IoT Produkt entwickeln oder ein bestehendes Gerät zur Serienreife bringen möchte, steht vor einer zentralen Frage: Welche Gerätekategorie hat welche technischen und regulatorischen Eigenschaften, und was bedeutet das für das eigene Projekt?

Dieser Artikel gibt einen strukturierten Überblick über typische IoT-Gerätekategorien, ihre technischen Unterschiede und die Konsequenzen dieser Unterschiede für Entwicklung, Zertifizierung und Markteinführung.

Von der Industrie bis zum Alltag: Wo IoT-Geräte eingesetzt werden

IoT-Geräte teilen sich auf drei Hauptdomänen auf: Consumer, Industrial und Medical. Jede Domäne definiert eigene Anforderungen an Lebensdauer, Konnektivität, Schutzklasse und regulatorische Abdeckung.

Im Consumer-Bereich dominieren Wearables, Smart-Home-Geräte und vernetzte Unterhaltungselektronik. Typische Beispiele: Fitness-Tracker, smarte Thermostate, kabellose Kopfhörer mit Sensorintegration. Die Anforderungen liegen bei niedrigen Stückkosten (Ziel: unter 5 USD BOM bei 10K+ Units), kompaktem Formfaktor und langer Akkulaufzeit. Ein häufiger Fehler: Teams unterschätzen den Einfluss von Over-the-Air-Update-Mechanismen auf die Systemarchitektur. Fehlt ein robuster OTA-Pfad, sind Feldkorrekturen nach dem Launch mit erheblichem Aufwand verbunden.

Im industriellen Umfeld stehen andere Parameter im Vordergrund: Betriebstemperaturbereiche von -40 °C bis +85 °C, Schutzklassen ab IP67, Langzeitverfügbarkeit von Komponenten über 10 Jahre und deterministische Kommunikation. Typische Geräte sind Condition-Monitoring-Sensoren, Gateways für Maschinenanbindung oder Asset-Tracker in der Logistik. Hier ist eine fundierte Schaltungsentwicklung besonders kritisch, da Feldausfälle in industriellen Umgebungen direkte Produktionskosten verursachen.

Medizintechnische IoT-Geräte bilden die dritte Kategorie. Blutdruckmessgeräte, kontinuierliche Glukosemonitore oder tragbare EKG-Systeme unterliegen der MDR (EU 2017/745) oder FDA 21 CFR Part 820. Die Entwicklungskosten steigen durch Dokumentationsaufwand und klinische Evaluierung auf das Zwei- bis Dreifache im Vergleich zu äquivalenten Consumer-Geräten. Teams, die den regulatorischen Scope erst nach dem Designfreeze klären, riskieren vollständige Hardware-Revisionen.

Typische IoT-Gerätekategorien und ihre Merkmale

Innerhalb der drei Domänen lassen sich fünf technische Gerätekategorien unterscheiden, die jeweils unterschiedliche Entwicklungsschwerpunkte erfordern.

Batteriebetriebene Sensorknoten

Diese Geräte messen einen oder mehrere Parameter (Temperatur, Feuchte, Beschleunigung, Licht) und übertragen Daten drahtlos. Typische Akkulaufzeit: 2 bis 10 Jahre bei CR2032 oder Li-SOCl2. Das erfordert durchschnittliche Stromaufnahmen unter 10 µA, was aggressive Sleep-Strategien auf MCU-Ebene und eine sorgfältige Auswahl des Funkprotokolls voraussetzt. BLE Advertising mit 1-Minuten-Intervall und 1 ms Event-Dauer erreicht typisch 5-15 µA Durchschnittsstrom. LoRaWAN bei gleichem Intervall liegt je nach Payload und Spreading Factor bei 20-80 µA. Wer BLE wählt, weil es günstiger in der Entwicklung ist, aber ein Deployment mit 5 km Reichweite plant, hat ein Architekturproblem.

Gateways und Edge-Geräte

Gateways aggregieren Daten von Sensorknoten und leiten sie an Cloud-Backends weiter. Sie sind dauerhaft netzversorgt, haben höhere Rechenanforderungen und benötigen oft mehrere Funkschnittstellen gleichzeitig. Die häufigste Unterschätzung: Der gleichzeitige Betrieb von BLE (2,4 GHz) und Wi-Fi (2,4 GHz) erzeugt Koexistenzprobleme, die im Labor nicht sichtbar sind, aber im Feld zu Paketverlusten bis zu 30 % führen können.

Wearables

Wearables kombinieren miniaturisierten Formfaktor, Biosensoren, drahtlose Konnektivität und oft haptisches Feedback in einem Gehäuse unter 50 cm³. Der PCB-Stack muss Flex- oder Rigid-Flex-Designs berücksichtigen. Mechanische Belastung durch Körperbewegung ist ein realer Ausfallmechanismus: Lötverbindungen auf starren Boards brechen bei zyklischer Biegebelastung nach 50.000-200.000 Zyklen, was bei einem Handgelenkgerät einer Nutzungsdauer von unter einem Jahr entsprechen kann.

Vernetzte Industriesensoren und Aktuatoren

Diese Geräte steuern oder überwachen physikalische Prozesse. Latenz und Zuverlässigkeit sind kritischer als Energieeffizienz. Protokolle wie Modbus, CAN oder Profinet koexistieren mit drahtlosen Schnittstellen. Ein typischer Fehler: Galvanische Trennung zwischen Feldbus und MCU wird in frühen Prototypen weggelassen, was zu Schäden durch Masseschleifen im Feld führt, die schwer zu diagnostizieren sind.

Medizinische Wearables und Monitore

PPG-Sensoren, Impedanzspektroskopie oder EKG-Frontends erfordern sehr rauscharme Analogdesigns mit CMRR-Anforderungen über 80 dB. Digitale Filterung auf MCU-Ebene ersetzt keine sorgfältige Analogauslegung. Wer das Analogdesign für einen späteren Schritt hält, verliert 4-8 Wochen in der Debugging-Phase.

Was IoT-Geräte technisch voneinander unterscheidet

Die entscheidenden technischen Differenzierungsmerkmale zwischen IoT-Gerätekategorien sind Konnektivitätsprotokoll, MCU-Architektur, Energiebudget und Peripherieintegration. Diese vier Dimensionen bestimmen Entwicklungsaufwand, BOM-Kosten und Zertifizierungsumfang.

Konnektivität: Protokollwahl mit Systemkonsequenzen

BLE 5.x eignet sich für kurze Reichweite (bis 100 m im Freifeld), niedrige Latenz und direkte Smartphone-Kopplung. BOM-Kosten für ein zertifiziertes BLE-Modul: 1,20-3,50 USD bei 5K Units. NB-IoT und LTE-M sind für Wide-Area-Deployments ohne lokale Infrastruktur geeignet, erzeugen aber höhere SIM-Kosten und Latenz im Minutenbereich. LoRaWAN liegt dazwischen: keine SIM-Kosten, Reichweite bis 15 km in ländlichen Gebieten, aber maximale Payload von 51-242 Bytes und Duty-Cycle-Beschränkungen in der EU (1 % in den meisten Bändern), die Anwendungsdesigns direkt einschränken.

MCU-Wahl: Leistung gegen Stromaufnahme

ARM Cortex-M0+ erreicht typisch 30-80 µA/MHz im Active Mode und eignet sich für einfache Sensorknoten. Cortex-M4 mit FPU ermöglicht DSP-Operationen für Signalverarbeitung, liegt aber bei 100-200 µA/MHz. STM32L-Serie und NXP LPC55S sind optimiert für Low-Power-Anwendungen mit Betriebsspannungen bis 1,7 V. Die Wahl der MCU-Familie bestimmt auch den verfügbaren Toolchain-Support und damit die Firmware-Entwicklungszeit. Ein Wechsel der MCU-Familie nach dem ersten Prototyp kostet typisch 3-6 Wochen Neuentwicklung der Peripherietreiber.

RTOS-Anforderungen

Einfache Sensorknoten mit einem Task laufen auf Bare-Metal-Firmware. Sobald mehrere Kommunikationsstacks, Sensorfusion und OTA-Updates parallel laufen, ist ein RTOS wie FreeRTOS oder Zephyr notwendig. Zephyr hat den Vorteil eines eingebauten Bluetooth-Stacks und breiter Hardware-Unterstützung, erfordert aber eine Einarbeitungszeit von 4-8 Wochen für Teams ohne Zephyr-Erfahrung. Wer diesen Aufwand nicht einplant, verliert ihn später im Zeitplan.

Diese technischen Entscheidungen sind nicht unabhängig voneinander. Eine falsch gewählte MCU zwingt zu einem anderen RTOS, das den Konnektivitätsstack nicht nativ unterstützt, was Integrationsaufwand von 6-10 Wochen erzeugen kann. Wer ein IoT-Gerät entwickeln lassen möchte, sollte diese Abhängigkeiten frühzeitig klären.

Zertifizierung und Marktreife: Besonderheiten je nach Gerätekategorie

Zertifizierungsumfang und -kosten variieren stark nach Gerätekategorie und Zielmarkt. Diese Unterschiede wirken direkt auf Timeline und Budget.

Für Consumer-IoT-Geräte mit Funkkomponenten ist in der EU die CE-Kennzeichnung nach RED (Radio Equipment Directive 2014/53/EU) Pflicht. Typische Zertifizierungskosten bei einem akkreditierten Labor: 8.000-20.000 EUR, Dauer 8-14 Wochen. Wer ein bereits FCC/CE-zertifiziertes Modul verwendet, reduziert den Testaufwand erheblich, muss aber die Antennenkonfiguration dokumentieren und darf keine Änderungen vornehmen, die die Modulzertifizierung ungültig machen. Ein häufiger Fehler: Das Modul wird auf dem PCB näher an Metallgehäuseteile platziert, als in der Modulzertifizierung vorgesehen, was zur Ungültigkeit der Zertifizierung führt.

Industrielle Geräte benötigen zusätzlich zu RED oft EMC-Tests nach EN 55032/EN 55035 und je nach Einsatzbereich funktionale Sicherheitsnachweise (IEC 61508). Diese Tests erhöhen die Gesamtkosten auf 15.000-40.000 EUR. Für Geräte im Ex-Bereich (ATEX) kommen Baumusterprüfungen hinzu, die 6-12 Monate dauern können.

Medizintechnische Geräte der Klasse I (ohne Messfunktion) erfordern eine technische Dokumentation und EU-Konformitätserklärung. Klasse IIa und höher benötigen eine benannte Stelle. Die Gesamtkosten für MDR-Konformität einer Klasse-IIa liegen typisch bei 50.000-150.000 EUR inklusive klinischer Bewertung und QMS-Aufbau. Teams, die ein IoT Produkt zur Serienreife bringen wollen, ohne den regulatorischen Pfad von Beginn an zu definieren, riskieren komplette Hardware-Revisionen nach dem Designfreeze.

Ein nicht-offensichtlicher Aspekt: Die Wahl des Funkkommunikationsstandards beeinflusst den Zertifizierungsaufwand direkt. Geräte mit proprietären Protokollen auf 2,4 GHz benötigen vollständige Typzulassungstests, während BLE oder Wi-Fi auf zertifizierten Modulen den Testumfang reduzieren. Diese Entscheidung sollte in der Konzeptphase fallen, nicht nach dem ersten Prototyp.

Wie Oxeltech bei der IoT-Geräteentwicklung unterstützt

Wir begleiten IoT-Projekte von der Konzeptphase bis zur Serienproduktion und decken dabei alle technischen und regulatorischen Dimensionen ab, die in diesem Artikel beschrieben wurden. Unser Team hat über 20 Hardwareprodukte durch Entwicklung, Zertifizierung und Markteintritt geführt, in Bereichen von Consumer Wearables über industrielle Sensorik bis zu medizintechnischen Geräten.

Konkret unterstützen wir bei:

• Architekturentscheidungen in der Konzeptphase: MCU-Wahl, Protokollselektion, Energiebudgetierung und Zertifizierungsstrategie vor dem ersten Schaltplan
• Hardware-Design und PCB-Layout: Schaltungsentwicklung mit Fokus auf EMI/EMC-Compliance, DFM und Langzeitverfügbarkeit der Komponenten
• Firmware-Entwicklung: Bare-Metal- und RTOS-basierte Entwicklung (FreeRTOS, Zephyr) für ARM Cortex, STM32, NXP und weitere Plattformen
• Prototypenaufbau und Debugging: Vom ersten Bring-Up bis zur Validierung unter realen Betriebsbedingungen
• Zertifizierungsvorbereitung: Technische Dokumentation, Vortests und Begleitung durch CE, FCC und MDR-Prozesse
• Übergang zur Serienproduktion: DFM-Reviews, Stücklistenoptimierung und Koordination mit Fertigungspartnern

Teams, die Elektronikentwicklung outsourcen oder ein Embedded System Prototyp bauen lassen möchten, ohne interne Kapazitäten aufzubauen, finden bei uns einen Partner, der technische Tiefe mit Projekterfahrung verbindet. Kontaktiere uns für ein erstes Gespräch über dein Projekt.

Ähnliche Artikel

• IoT Gerät entwickeln lassen: Wie du Qualität und Kosten richtig abwägst
• Wie funktioniert kontinuierliche Überwachung mit einem Biosensor?
• Was ist der Unterschied zwischen starren und flexiblen PCBs bei Wearables?
• Was kostet die Entwicklung eines Embedded Systems?
• Welche Rolle spielt das Gehäusedesign bei der Wearable-Entwicklung?