Wearables stellen eine der technisch restriktivsten Produktkategorien dar: Formfaktor unter 5 cm², Akkulaufzeit über mehrere Tage bei einer Zellkapazität von 100–300 mAh, BLE-Konnektivität mit Zertifizierungspflicht, und Stückkosten, die bei 10.000 Einheiten unter 8–12 USD liegen müssen. Die zentrale Architekturentscheidung lautet: proprietärer SoC mit integriertem Stack oder diskrete Standardkomponenten. Beide Pfade haben definierte Kostenpunkte, Risiken und Einschränkungen, die sich je nach Projektkonstellation unterschiedlich auswirken.

Dieser Artikel behandelt die Abwägungen zwischen proprietären Chips und Standardkomponenten aus der Perspektive von Hardware-Entscheidungen: Kosten, Zertifizierungsrisiko, Lieferkettenstabilität und Time-to-Market unter realen Projektbedingungen.

Was sind proprietäre Chips und warum werden sie in Wearables eingesetzt?

Proprietäre Chips integrieren anwendungsspezifische Funktionen – Biosignal-AFEs, Bewegungsklassifikation, BLE-Stack – in einem einzigen Package, das ausschließlich vom Hersteller bezogen werden kann. In der Wearable-Entwicklung reduziert das die Komponentenanzahl und den Integrationsaufwand auf Hardware- und Firmware-Ebene.

Apple, Fitbit und Garmin entwickeln eigene Chips, weil sie auf diese Weise den Energieverbrauch auf Systemebene optimieren, proprietäre Algorithmen direkt in Hardware abbilden und die Lieferkette vollständig kontrollieren können. Für externe Entwickler bedeutet dieselbe Architektur: Mindestabnahmemengen von typischerweise 50.000–100.000 Einheiten, NDA-gebundene Dokumentation und ein Lieferantenrisiko, das bei Discontinuation des Chips das gesamte Produktdesign invalidiert. Genau dieses Risiko wird in frühen Projektphasen systematisch unterschätzt.

Welche Alternativen zu proprietären Chips gibt es für Wearables?

Für die meisten Wearable-Anwendungen decken Standardkomponenten die funktionalen Anforderungen ab. Die Frage ist nicht, ob ein Standard-SoC die Aufgabe erfüllen kann, sondern ob das Entwicklungsteam die Integrationsarbeit leisten kann, die ein proprietärer Chip erspart.

Relevante Optionen nach Anwendungsprofil:

• Nordic Semiconductor nRF52/nRF53-Serie: ARM-Cortex-M4/M33 mit integriertem BLE 5.x, typischer Stromverbrauch im Connected-Advertising-Modus bei 4–6 µA, Stückpreis bei 10K Einheiten ca. 2,50–4,00 USD. Unterstützt Zephyr RTOS nativ. Risiko: Der SoftDevice-Stack belegt feste Flash-Bereiche und schränkt das Firmware-Layout ein; bei komplexen Anwendungen mit mehreren BLE-Rollen kann das zu Speicherkonflikten führen.
• STM32L-Serie (z. B. STM32L4/L5): Breite Peripherie-Unterstützung, mehrere Low-Power-Modi bis 30 nA im Standby, kein integriertes BLE – erfordert externes Funkmodul. Geeignet, wenn die Rechenlogik dominant ist und BLE als separates Modul akzeptabel ist. Mehrkosten durch zusätzliches Modul: ca. 1,50–3,00 USD pro Einheit.
• NXP i.MX RT-Serie: Cortex-M7 mit bis zu 1 GHz, relevant für lokale Inferenz oder komplexe Signalverarbeitung. Stromverbrauch im aktiven Betrieb deutlich höher als nRF52; für batteriebetriebene Wearables nur sinnvoll, wenn Duty-Cycle unter 5 % gehalten werden kann.
• Standard-Sensoren: Bosch BHI260 (IMU mit integriertem DSP), Maxim MAX30101 (PPG/SpO2), STMicroelectronics LIS2DH12 (Beschleunigung, 2 µA bei 1 Hz ODR) sind qualifiziert, breit verfügbar und haben öffentliche Datenblätter ohne NDA-Anforderung.

Lieferkettenstabilität ist ein struktureller Vorteil dieser Komponenten: Mehrere autorisierte Distributoren, öffentliche Roadmaps und keine exklusiven Bezugsbedingungen reduzieren das Produktionsrisiko bei Stückzahlskalierung erheblich.

Was kostet es, ein Wearable mit Standard-Chips zu entwickeln?

Entwicklungskosten bei Standard-Chip-Ansätzen entstehen primär durch Integrationsaufwand, nicht durch Lizenzgebühren. Das verlagert das Kostenrisiko von der Beschaffung in die Engineering-Phase – ein Unterschied, der Projektbudgets anders belastet.

Kostentreiber nach Kategorie:

1. Hardware-Design und PCB-Layout: Ein 4-lagiges PCB-Layout für ein BLE-Wearable mit IMU, PPG-Sensor und Power-Management kostet bei einem erfahrenen Dienstleister 8.000–20.000 EUR pro Iteration, abhängig von Antennenlayout, EMI-Anforderungen und DFM-Komplexität. Referenzdesigns der SoC-Hersteller reduzieren die erste Iteration um ca. 20–30 %, beseitigen aber keine projektspezifischen Anpassungen.
2. Firmware-Entwicklung: Der Aufwand für Embedded-Software-Entwicklung auf Zephyr oder FreeRTOS liegt für ein funktional vollständiges Wearable-Firmware-Stack bei 600–1.200 Stunden, abhängig von BLE-Profilkomplexität, Sensorintegration und Power-Management-Implementierung. Fehleinschätzungen hier sind die häufigste Ursache für Budgetüberschreitungen.
3. Prototypen und Zertifizierung: CE (RED-Richtlinie) und FCC-Zertifizierung für ein BLE-Wearable kosten typischerweise 15.000–35.000 EUR und dauern 8–14 Wochen, wenn das Design beim ersten Testlauf besteht. Jede EMC-Nachbesserung am PCB-Layout kostet eine weitere Iteration: 4–8 Wochen und 3.000–8.000 EUR. Bluetooth SIG-Qualifikation kommt bei Nutzung eines qualifizierten Moduls günstiger als bei eigenem BLE-Design auf dem SoC.

Teams, die erstmals mit der nRF52-Serie arbeiten, unterschätzen konsistent den Aufwand für das BLE-Stack-Tuning unter realen RF-Bedingungen. Verbindungsabbrüche im 2,4-GHz-Band durch Körperabsorption und metallische Gehäuseteile sind ein bekanntes Problem, das Antennenpositioning und Link-Layer-Parametrierung betrifft – und das sich nicht durch Software allein lösen lässt.

Welche Kompromisse entstehen beim Verzicht auf proprietäre Chips?

Der Verzicht auf proprietäre Chips verschiebt Integrationsaufwand vom Chip-Hersteller ins eigene Entwicklungsteam. Das ist beherrschbar, wenn die Konsequenzen konkret geplant werden.

Relevante Kompromisse mit ihren Mechanismen:

• Formfaktor: Ein nRF52840 mit externem PPG-Sensor, PMIC und passiven Komponenten benötigt realistisch 180–250 mm² PCB-Fläche. Ein proprietärer SoC mit integriertem AFE kann das auf 80–120 mm² reduzieren. Unterhalb von 25 mm Gehäusedurchmesser wird das zur harten Einschränkung.
• Energieoptimierung: Proprietäre Chips mit anwendungsspezifischem Power-Management erreichen in definierten Use-Cases Systemstromverbräuche, die mit Standardkomponenten nur durch aufwendige Firmware-Architektur und Hardware-Abschaltlogik erreichbar sind. Der Unterschied liegt typischerweise bei 15–40 % Systemstromverbrauch unter identischer Last – nicht durch Chip-Technologie, sondern durch tiefere Co-Design-Integration. Wird dieser Aufwand in der Firmware-Planung nicht eingeplant, verfehlt das Produkt seine Akkulaufzeit-Spezifikation.
• Zertifizierungsrisiko bei BLE: Wer einen nRF52 mit eigenem Antennenlayout betreibt, trägt die volle RF-Zertifizierungslast. Wer ein bereits FCC/CE-zertifiziertes Modul (z. B. u-blox ANNA-B112, Laird BL5340) einsetzt, reduziert das Zertifizierungsrisiko erheblich, zahlt aber 1,50–3,00 USD Aufpreis pro Einheit gegenüber dem nackten SoC.
• Time-to-Market: Ein proprietärer All-in-One-SoC mit fertigem SDK kann den Weg zum ersten funktionalen Prototypen um 4–8 Wochen verkürzen. Bei einem 6-monatigen Gesamtprojekt ist das relevant; bei einem 18-monatigen Projekt mit mehreren Iterationen verliert dieser Vorteil an Gewicht.

Eine verbreitete Fehlannahme ist, dass Community-Support bei Standard-Chips das fehlende proprietäre Application Engineering kompensiert. Für generische Anwendungsfälle stimmt das. Bei sicherheitskritischen Biosignal-Anwendungen oder sehr engen Strombudgets reicht Forum-Support nicht aus – dort ist strukturiertes Applikations-Engineering durch das eigene Team oder einen spezialisierten Dienstleister erforderlich.

Wie entwickelt man ein energieeffizientes Wearable ohne proprietäre Chips?

Energieeffizienz bei Standard-Chip-Designs entsteht durch das Zusammenspiel von Hardware-Topologie, Power-Management-Design und Firmware-Architektur. Wird einer dieser drei Bereiche vernachlässigt, lässt sich das Defizit durch die anderen nicht vollständig ausgleichen.

Chip-Auswahl und Hardware-Design

Der nRF52832 erreicht im System-Off-Modus 0,3 µA, der nRF52840 liegt bei 0,4 µA. Beide Werte gelten ohne externe Peripherie. Jeder aktive Sensor, jeder nicht abgeschaltete LDO und jede floating GPIO-Leitung addiert Leckstrom. Ein PMIC wie der TI TPS63031 oder der Nordic NPM1100 ermöglicht dynamisches Spanungsmanagement für Sensorversorgungen und reduziert den Gesamtstromverbrauch im Sleep-Betrieb messbar. Das PCB-Layout muss Leckstrompfade durch Feuchtigkeitsexposition berücksichtigen – besonders relevant bei körpernahen Wearables.

Firmware-Architektur und Software-Optimierung

Zephyr RTOS bietet mit dem Power Management Framework eine strukturierte Basis für Sleep/Wake-Zyklen, setzt aber voraus, dass alle Treiber korrekt implementierte Suspend/Resume-Callbacks haben. Fehlt ein solcher Callback in einem Sensor-Treiber, bleibt der Sensor aktiv, auch wenn das System in den Low-Power-Modus wechselt – ein Fehler, der im Stromverbrauchsprofil schwer isolierbar ist, wenn kein Inline-Strommesssetup vorhanden ist. BLE Connection Interval sollte auf den tatsächlichen Datenbedarf abgestimmt sein: 100 ms Intervall verbraucht ca. 50–80 µA Durchschnitt; 1.000 ms Intervall reduziert das auf 8–15 µA bei vergleichbarer Datenmenge. Sensoren sollten ausschließlich interrupt-gesteuert aktiviert werden, nicht polling-basiert.

Wann sollte man doch auf proprietäre Chips setzen?

Proprietäre Chips sind dann die ökonomisch und technisch begründete Wahl, wenn die Integrationstiefe, die sie bieten, mit Standardkomponenten nur durch unverhältnismäßig hohen Entwicklungsaufwand erreichbar wäre – oder wenn regulatorische Anforderungen eine zertifizierte Algorithmen-Implementierung auf Chip-Ebene verlangen.

Szenarien, in denen proprietäre Chips gerechtfertigt sind:

• Medizinische Wearables mit IEC 62304-pflichtiger Biosignal-Verarbeitung, bei denen ein proprietärer Chip eine bereits validierte Algorithmen-Implementierung mitbringt. Die Neuentwicklung und Validierung eines äquivalenten Algorithmus auf Standard-Hardware kostet 3–6 Monate zusätzliche Entwicklungszeit.
• Produkte mit Stückzahlen über 500.000 Einheiten pro Jahr, bei denen ein hochintegrierter proprietärer SoC die BOM-Kosten durch reduzierte Komponentenanzahl um 1,50–3,00 USD pro Einheit senkt – ein Betrag, der bei diesen Volumina die höheren Entwicklungskosten amortisiert.
• Projekte mit einem Prototypen-Deadline unter 10 Wochen, bei denen ein fertiges proprietäres Evaluation-Kit den einzigen realistischen Pfad darstellt. Der Trade-off: spätere Portierung auf Standard-Chips kostet 6–12 Wochen Zusatzaufwand, wenn das Produkt skaliert.
• Anwendungen mit Hardware-Sicherheitsanforderungen (Secure Element, Hardware-Attestation), bei denen ein proprietärer Chip eine bereits zertifizierte Sicherheitsarchitektur mitbringt.

Für Projekte mit Stückzahlen unter 100.000 Einheiten, ohne regulatorisch vorgeschriebene Algorithmen-Zertifizierung und mit einem Entwicklungsteam, das Embedded-Erfahrung auf ARM-Cortex-Plattformen mitbringt, sind Standard-Chips die belastbarere Ausgangsbasis: keine Mindestabnahmemengen, keine NDA-Abhängigkeit, kein Discontinuation-Risiko.

Wie wir bei der kosteneffizienten Wearable-Entwicklung helfen

Oxeltech begleitet Unternehmen durch die Wearable-Elektronikentwicklung von der Architekturentscheidung bis zur Serienproduktion. Der Fokus liegt auf Designs, die unter realen Stückzahl-, Kosten- und Zertifizierungsbedingungen funktionieren.

Konkrete Leistungsbereiche:

• Chip- und Modulauswahl mit expliziter Bewertung von BOM-Kosten, Zertifizierungsrisiko und Lieferkettenstabilität für BLE, Wi-Fi, LoRa und NB-IoT
• PCB-Layout mit Antennenpositioning, EMI/EMC-Design und DFM-Optimierung für Wearable-Formfaktoren
• Firmware-Entwicklung auf Zephyr und FreeRTOS für nRF52/53, STM32 und NXP-Plattformen, einschließlich Power-Management-Implementierung und BLE-Stack-Konfiguration
• Iterativer Prototypenaufbau mit Stromverbrauchsmessung und systematischer Fehleranalyse
• Zertifizierungsbegleitung für CE (RED), FCC und Bluetooth SIG, einschließlich Vorbereitung auf Pre-Compliance-Tests zur Reduktion von Nachbesserungsiterationen

Ob die Architekturentscheidung zwischen proprietärem und Standard-Chip noch offen ist oder ein bestehendes Design unter Strom- oder Kostendruck steht: Nimm jetzt Kontakt auf und beschreibe deine konkreten Anforderungen. Wir bewerten den technischen und wirtschaftlichen Pfad für dein spezifisches Projekt.

Ähnliche Beiträge

• Warum ist EMI/EMC-Optimierung bei Hardware-Design wichtig?
• Was sind die größten technischen Herausforderungen bei der Wearable-Entwicklung?
• Wie lange dauert der Entwicklungszyklus eines Wearable-Produkts?
• Was kostet die Entwicklung eines Embedded Systems?
• Was sollte man bei der Auswahl eines Entwicklungspartners für Wearables beachten?