Wearable-Projekte scheitern selten an der Idee. Sie scheitern an der falschen Partnerauswahl: ein Dienstleister ohne Zertifizierungserfahrung, ein Team ohne Low-Power-Kompetenz, oder ein Partner, der erst nach dem ersten Prototyp auf strukturelle Designprobleme hinweist. Die Konsequenzen sind konkret: Redesign-Zyklen von 8–16 Wochen, CE/FCC-Nachzertifizierungen im fünfstelligen Bereich, oder ein Produkt, das die Akkulaufzeit-Anforderungen um den Faktor 2–3 verfehlt. Zwei grundlegend verschiedene Partnermodelle stehen zur Wahl: ein Elektronikdienstleister, der definierte Leistungen ausführt, oder ein Entwicklungspartner, der technische Mitverantwortung übernimmt. Welches Modell passt, hängt davon ab, wie viel interne Systemkompetenz das eigene Team mitbringt.

Dieser Artikel gibt CTOs, Produktmanagern und Engineering Leads konkrete Entscheidungskriterien für die Auswahl eines Entwicklungspartners für Wearables – mit Fokus auf technische Tiefe, Zertifizierungsrisiken und Projektökonomie.

Was einen Entwicklungspartner für Wearables qualifiziert

Ein qualifizierter Wearable-Entwicklungspartner muss Hardware, Firmware und Systemintegration als zusammenhängendes Problem behandeln. PCB-Layout-Entscheidungen beeinflussen direkt den Stromverbrauch der Firmware; Kommunikationsstack-Auswahl bestimmt Zertifizierungsaufwand und Stückkosten. Ein Partner, der diese Disziplinen getrennt bearbeitet, erzeugt Schnittstellenprobleme, die spät im Projekt teuer werden.

Wearables erfordern simultane Optimierung von Formfaktor, Energiebudget und Funkzulassung. Ein 4-Schicht-PCB mit 0,8 mm Pitch BGA-Komponenten verhält sich in der EMV-Messung anders als im Schaltplan – wer das nicht aus eigenen Projekten kennt, lernt es auf Kosten des Kunden. Typisches Warnsignal: Der Partner gibt Energieverbrauchsschätzungen ohne Betriebsmodus-Spezifikation ab. Korrekte Angaben nennen Stromaufnahme getrennt nach Active, Sleep und Advertising Mode.

Transparenz in der Projektkommunikation ist kein Soft Skill, sondern ein Risikoindikator. Partner, die Probleme erst beim Meilenstein-Review ansprechen, erhöhen die Wahrscheinlichkeit von Scope-Änderungen in der Validierungsphase – dem teuersten Zeitpunkt im Entwicklungszyklus.

Technische Kernkompetenzen und ihre Projektrelevanz

Die Kombination aus miniaturisiertem PCB-Design, Low-Power-Elektronik, drahtloser Kommunikation und Embedded-Firmware ist für Wearables nicht optional. Fehlt eine dieser Kompetenzen, entstehen Abhängigkeiten von Subdienstleistern mit eigenen Schnittstellenrisiken.

Hardware und PCB-Design

Miniaturisierung auf unter 20 × 30 mm erfordert kontrollierten Impedanzabschluss für HF-Leitungen, thermisches Management ohne konventionelle Kühlkörper und DFM-konforme Bauteilplatzierung für automatisierte Bestückung. Ein Partner ohne DFM-Erfahrung liefert Designs, die in der Prototypenfertigung funktionieren, aber in der Serienproduktion ab 1.000 Stück Ausschussraten von 3–8 % erzeugen. CE-Vorzertifizierungstests kosten 2.000–5.000 € pro Durchlauf – ein Design, das EMV-Probleme durch schlechtes Layout erzeugt, verursacht typisch 2–3 Wiederholungsdurchläufe.

Drahtlose Konnektivität

Die Wahl der Kommunikationstechnologie bestimmt Zertifizierungsumfang, Energiebudget und Infrastrukturabhängigkeit des Endprodukts. BLE 5.x bei 0 dBm Sendeleistung zieht im Advertising-Betrieb ca. 0,5–1,5 mA; NB-IoT im PSM-Modus kann auf unter 5 µA Ruhestrom kommen, benötigt aber Netzabdeckung und erzeugt höhere Modulkosten von 4–8 USD gegenüber 1–2 USD für ein BLE-SoC. LoRa eignet sich für industrielle Szenarien mit sporadischer Datenübertragung über 500 m bis mehrere Kilometer, ist aber für latenzempfindliche Anwendungen ungeeignet. Ein bekanntes Fehlermuster: BLE-Verbindungsabbrüche durch unzureichende Antennenisolation vom Metallgehäuse, die im Freifeld nicht auftreten, aber am Körper des Trägers zu Verbindungsverlusten von 30–60 % führen.

Firmware und Embedded Systems

FreeRTOS und Zephyr haben unterschiedliche Implikationen für Zertifizierung und Langzeitpflege. Zephyr bietet native BLE-Stack-Integration und aktive Community-Pflege, erfordert aber längere Einarbeitungszeit und erzeugt höheren Flash-Bedarf. FreeRTOS ist schlanker und bei ARM Cortex-M0/M0+ mit 64–256 kB Flash besser geeignet. Der kritische Punkt: Jede nicht abgeschaltete Peripherie im Sleep-Mode kostet typisch 50–500 µA – bei einer 300-mAh-Zelle bedeutet 100 µA Leckstrom eine Reduktion der Standby-Zeit von theoretisch 3.000 h auf unter 300 h. Partner, die Energieoptimierung als Firmware-Feature behandeln statt als Systemdesign-Anforderung, erkennen diese Probleme erst im Feldtest.

Erfahrung bewerten: konkrete Indikatoren

Nachweisbare Wearable-Erfahrung zeigt sich nicht in der Projektanzahl, sondern in der Tiefe: Hat der Partner ein Design durch Pre-Compliance, Zertifizierung und Produktionsanlauf geführt? Kann er spezifische Designentscheidungen aus vergangenen Projekten begründen?

Ein erfahrener Partner spricht über Zertifizierungsprojekte in konkreten Begriffen: Welche Normen, welche Prüflabore, welche Iterationen. CE nach RED-Richtlinie für ein BLE-Gerät dauert bei einem gut vorbereiteten Design 8–14 Wochen und kostet 3.000–8.000 € im akkreditierten Labor. Wer diese Zahlen nicht kennt oder deutlich abweichende Schätzungen gibt, hat den Prozess nicht selbst durchlaufen. Gleiches gilt für die Serienproduktionsübergabe: ein Partner mit echter DFM-Erfahrung benennt konkrete Änderungen zwischen Prototyp und Seriendesign.

Qualität der eigenen Fragen ist ein verlässlicher Indikator. Ein kompetenter Partner fragt nach Betriebstemperaturbereich, IP-Schutzklasse, Zielmarkt (bestimmt Zertifizierungsumfang) und Stückzahlplanung (bestimmt Bauteilauswahl und Kostenstruktur) – bevor er eine Aufwandsschätzung abgibt. Wer ohne diese Informationen sofort ein Angebot macht, kalkuliert pauschal.

Technische Dokumentationsqualität in der Angebotsphase ist ein weiterer Indikator: Blockdiagramme, Komponentenauswahl mit Begründung und Risikohinweise deuten auf strukturiertes Vorgehen hin. Fehlende oder generische Dokumentation ist ein Warnsignal für spätere Kommunikationsprobleme.

Dienstleister vs. Entwicklungspartner: Entscheidungskriterien

Ein Elektronikdienstleister führt spezifizierte Aufgaben aus – PCB-Bestückung, Schaltungsdesign nach Lastenheft, Firmware nach Funktionsspezifikation. Ein Entwicklungspartner trägt Mitverantwortung für Systemarchitektur, Risikoidentifikation und Zielerfüllung. Der Unterschied ist ökonomisch relevant, nicht nur organisatorisch.

Das Dienstleister-Modell funktioniert, wenn das eigene Team vollständige Systemkompetenz besitzt und präzise Spezifikationen liefern kann. Fehlt diese interne Kompetenz, entstehen Spezifikationslücken, die der Dienstleister mit Standardannahmen füllt – oft nicht kompatibel mit den tatsächlichen Produktanforderungen. Ein typisches Ergebnis: ein Prototyp, der die Spezifikation erfüllt, aber nicht das Produkt, das gemeint war.

Für Teams ohne vollständiges internes Hardware-Firmware-Team ist das Partnermodell die risikoärmere Wahl bei komplexen Projekten wie der IoT-Wearable-Entwicklung. Die Mehrkosten gegenüber einem reinen Dienstleister liegen typisch bei 15–30 % des Projektbudgets, reduzieren aber das Risiko von Redesign-Zyklen, die einzeln mehr kosten können als dieser Aufschlag.

Verbreitete Fehleinschätzung: Teams unterschätzen systematisch den Koordinationsaufwand beim Dienstleister-Modell. Wer drei spezialisierte Dienstleister für Hardware, Firmware und Funk koordiniert, bindet intern 20–40 % einer Vollzeitstelle für Schnittstellenmanagement – Aufwand, der in der Projektkalkulation selten erscheint.

Qualifizierungsfragen für die Partnerauswahl

Konkrete Fragen in der Evaluierungsphase trennen Partner mit echter Projekterfahrung von solchen mit allgemeinen Fähigkeiten. Vage Antworten auf spezifische technische Fragen sind ein zuverlässiges Ausschlusskriterium.

Folgende Fragen liefern verwertbare Informationen:

• Beschreiben Sie ein abgeschlossenes Wearable-Projekt: Welche Zielakkulaufzeit war gefordert, was wurde erreicht, und welche Designänderungen waren dafür nötig?
• Wie gehen Sie bei der Energiebudgetierung vor – auf Systemebene, nicht auf Komponentenebene?
• Welche drahtlosen Technologien haben Sie in Wearables implementiert, und nach welchen Kriterien haben Sie zwischen Optionen entschieden?
• Welche Normen haben Sie für CE- oder FCC-Zertifizierungen bearbeitet, und wie viele Prüfiterationen waren typisch?
• Wie sieht Ihr Übergabeprozess an die Serienproduktion aus, und welche Änderungen entstehen dabei typischerweise am Design?
• Wie strukturieren Sie Projektkommunikation, und wie gehen Sie vor, wenn ein Ansatz technisch nicht realisierbar ist?
• Welche Risiken sehen Sie konkret in unserem Projekt, bevor wir Details besprochen haben?

Die letzte Frage ist besonders aufschlussreich: Ein Partner mit Wearable-Erfahrung benennt sofort typische Risikokategorien – Antennenisolation, Zertifizierungsumfang bei Mehrband-Funk, thermische Probleme in geschlossenen Gehäusen. Wer keine Risiken nennt, hat keine Projekterfahrung oder kommuniziert sie nicht – beides ist ein Problem.

Einbindungszeitpunkt: Wann der Partner ins Projekt kommt

Den Entwicklungspartner ab der Konzeptphase einzubinden reduziert Redesign-Risiken, weil systemkritische Entscheidungen – Mikrocontroller-Auswahl, Kommunikationstechnologie, Gehäuseform – direkte Konsequenzen für Energiebudget, Zertifizierungsaufwand und Stückkosten haben und sich nach dem ersten PCB-Layout nur mit erheblichem Aufwand ändern lassen.

Ein verbreitetes Muster: Das Produktteam legt Mikrocontroller und Kommunikationstechnologie fest, bevor ein Hardwarepartner involviert ist. Wird dann festgestellt, dass die gewählte Kombination den Energiebedarf nicht erfüllt oder die Zertifizierung in den Zielmärkten kompliziert, kostet der Wechsel 4–10 Wochen Redesign-Zeit und 15.000–40.000 € in Abhängigkeit vom Projektstand. Die Annahme, dass Technologieentscheidungen reversibel sind, ist eine der häufigsten und teuersten Fehleinschätzungen in frühen Wearable-Projekten.

Frühe Einbindung ermöglicht außerdem eine realistische Zertifizierungsplanung. CE-Zertifizierung nach RED für ein Gerät mit BLE und NFC erfordert andere Testumfänge als ein reines BLE-Gerät – dieser Unterschied beeinflusst Timeline und Budget um 4–8 Wochen und 3.000–6.000 €. Wer das erst in der Validierungsphase erfährt, hat keinen Puffer mehr.

Wie Oxeltech bei der Wearable-Entwicklung unterstützt

Oxeltech begleitet Wearable-Projekte von der Systemarchitektur bis zur Serienproduktion. Als Hardware- und Firmware-Entwicklungspartner mit Fokus auf miniaturisierte, energieoptimierte und funkzertifizierte Produkte übernehmen wir technische Mitverantwortung – nicht nur Ausführung nach Spezifikation.

Unser Leistungsangebot für Wearable-Projekte umfasst:

• Hardware-Design und PCB-Layout mit Fokus auf Miniaturisierung, DFM und EMV-konforme Auslegung
• Firmware- und Embedded-Software-Entwicklung für ARM Cortex-M und STM32 mit systematischer Low-Power-Optimierung
• Integration und Auswahl drahtloser Kommunikationstechnologien (BLE, Wi-Fi, NB-IoT, LoRa) nach Anwendungsanforderungen
• Energiebudgetierung auf Systemebene mit messbaren Laufzeitzielen
• Zertifizierungsbegleitung für CE (RED), FCC und weitere Märkte – inklusive Pre-Compliance-Testing
• Überführung vom validierten Prototyp in die Serienproduktion mit DFM-Optimierung

Wir haben über 20 Hardwareprodukte vom Konzept bis zum Markteintritt begleitet, darunter Projekte mit CE- und FCC-Zertifizierung sowie Serienproduktionsanläufen ab 500 Stück. Wenn Sie ein Wearable-Projekt planen und die technischen Risiken früh adressieren möchten, sprechen Sie uns an – wir bewerten konkret, wo in Ihrem Projekt die größten Risiken liegen und wie wir sie reduzieren.