Designstrategien für Wearables Revolution am Handgelenk

Die »Revolution am Handgelenk« gibt neue Designregeln für Entwickler vor: Sie müssen ausgefeilte Sensorik, Rechen-, Display- und Funktechnik in erschwingliche, überzeugende und kompakte Designs integrieren, die über Monate mit einer einzigen Batterie oder anderen begrenzten Energiequellen zuverlässig funktionieren müssen.

Smart Watches, Aktivitätstracker, tragbare GPS-Geräte, Pulsmesser und Smart Glasses sind nur einige Beispiele für Wearable-Produkte, die laut Futuresource Consulting im Jahr 2013 ein geschätztes Marktvolumen von 8 Milliarden US-Dollar erreichten. Mit neuen Funktionen, einfach zu bedienender Anbindung, kompakten Formaten, extrem niedrigem Stromverbrauch und drahtloser Datenanbindung stellen die Geräte eine ganz neue Klasse von Elektronik für den Privatanwender dar, mit der wir nach deren Befürwortern gesünder, besser informiert und besser ausgestattet sind als je zuvor.

Obwohl verschiedene Smartphone-Hersteller vor einigen Jahren mit sperrigen Versionen ihrer Smartphones für das Handgelenk experimentierten, begann die eigentliche Revolution am Handgelenk Anfang 2012, als innovative Start-ups wie die »Pebble Smartwatch« 
die Smartphone-Hersteller überholten und eine neue Klasse leichter 
Geräte für das Handgelenk einführten. Endanwender konnten damit die Funktion ihres Smartphones erweitern. Garmin, Samsung, Sony, Fitbit, Magellan (Bild 1) und andere Hersteller von Unterhaltungselektronik nehmen ebenfalls an dieser Entwicklung teil und stellen ihre eigenen Smart Watches, Aktivitätstracker und andere Wearable-Produkte vor. Dieser neue Markt bringt auch kleine Start-ups hervor, deren Produkte wie der »Misfit Shine Fitness Tracker« (siehe Bild oben) erfolgreich mit etablierten Unternehmen im Markt konkurrieren.

Ein erfolgreiches Wearable muss die richtige Kombination aus Preis, 
Leistung, Funktionsumfang und Batterielebensdauer bieten sowie ein einzigartiges Aussehen und Gefühl vermitteln, um sich vom Wettbewerb zu differenzieren. Mikrocontroller (MCU), Sensoren, Funkelektronik und attraktive Benutzerschnittstellen müssen auf kleinem Raum untergebracht werden, um ein komfortabel am Handgelenk oder anderswo am Körper zu tragendes Gerät bereitzustellen. Da solche Formfaktorvorgaben nur wenig Spielraum für die Batterie bieten, müssen Wearables sehr energieeffizient sein, um eine möglichst lange Betriebsdauer zwischen den Batteriewechseln oder Aufladevorgängen zu garantieren.

Durch die Brille des Nutzers

Die Integration dieser verschiedenen Elemente in erfolgreiche Produkte erfordert Kompromisse bei Stromaufnahme, Leistungsfähigkeit, Funktionsumfang und dem Formfaktor. Verschiedene Hersteller bewegen sich sehr erfolgreich auf diesem Gebiet der anwenderorientierten Designmethode, die viele der herkömmlichen Praktiken eines Embedded-Entwicklers völlig verändert.

Üblicherweise beginnt der Designprozess für ein Embedded System mit der Definition der Funktionen und Eigenschaften, die den obersten Projektzielen entsprechen sollen. Im Gegensatz dazu startet das Design eines Wearables mit der Definition der gewünschten »Nutzererfahrung«. Diese Anforderungen definieren ein Produkt nach Aussehen, Gefühl (Look & Feel), Interaktion mit dem Endanwender und allen Eindrücken und Emotionen, die es auslöst. Der nächste Schritt in diesem Designprozess ist die Übertragung der Benutzerfreundlichkeit auf einen Anwendungsfall (Use Case). Dabei definiert eine Reihe von Top-Level-Funktionen die Hardware- und Softwareelemente des Produkts. 

Apple war einer der frühen Pioniere dieser Strategie. Mit großem Erfolg hat das Unternehmen neue Märkte definiert – und bestehende erweitert. Wer eine gut durchdachte Benutzererfahrung für nicht unbedingt notwendig hält, sollte sich an das einzigartige Steuerungsrad (Control Wheel) des »iPod«, das elegante Gehäusedesign und die einfach zu bedienende Software »iTunes« erinnern, mit der das Unternehmen den Markt für digitale Musik-Player verändert hat und immer noch dominiert.

Die Anforderungen an die Benutzererfahrung eines Wearables fallen in zwei Kategorien: 

  • Funktionsumfang: das einzigartige Look & Feel, die Funktionen und Eigenschaften, die das Produkt vom Wettbewerb unterscheiden. 
  • Benutzerfreundlichkeit: die Anforderungen, die ein einfaches Einrichten, intuitiven Betrieb und minimale Wartung ermöglichen. Eine lange Akkulaufzeit spielt eine wichtige Rolle bei der Benutzerfreundlichkeit, da das Aufladen eines Wearables alle paar Tage eher frustrierend ist und die Nutzung dadurch abnimmt. 

Zusammen definieren diese Elemente die Benutzererfahrung, die sich in einen Anwendungsfall übertragen lässt, der die Grundlage des Produktdesigns bildet. Je nach Anwendung kann die Definition der Benutzererfahrung ein Design erfordern, das eine angenehme Oberflächenstruktur, ergonomische Form und Designelemente umfasst, die ein bestimmtes Look & Feel vermitteln. Andere Produkte können die Entwicklung spezieller visueller Paradigmen für Bedienelemente und Displays erfordern, die komplexe Vorgänge einfach und intuitiv machen.

Sobald die Benutzererfahrung eines Produkts klar definiert ist, muss diese in einen Anwendungsfall übertragen werden, dessen funktionale Anforderungen das Design des Wearable-Geräts bestimmen. Ein detaillierter Anwendungsfall kann wichtige Informationen bereitstellen, um genaue Vergleichsstudien für jeden Aspekt eines Wearable-Designs durchzuführen.

Ein Anwendungsfall sollte die Aufgaben enthalten, die das Wearable ausführen soll, die erforderlichen Ressourcen und die Bedingungen, unter denen es arbeiten soll. Dazu zählen die Daten, die das Gerät sammelt, und wie es mit dem Anwender sowie anderen Geräten interagiert, die Betriebsumgebung (Temperatur, Wasser- und Stoßfestigkeit etc.), Betriebsmodi (Datensammlung und -analyse, Benutzerinteraktion, Kommunikation etc.) und wie oft die Synchronisation mit anderen Devices erfolgt.

Definition des Anwendungsfalls

Mit diesen Richtlinien kann das Entwicklungsteam die Sensor-, Rechen- und Kommunikationskomponenten festlegen, die den Applikationsanforderungen am besten entsprechen. Dabei lassen sich die Kosten für die Stückliste und der Strombedarf ermitteln, während das Team parallel die vorläufigen Design anforderungen herausarbeitet und somit die erforderlichen Parameter für einen optimalen Designansatz erhält.

Eine wichtige Rolle bei Wearables spielt wie schon gesagt die Batterielebensdauer. Um genau modellieren zu können, wie die Designentscheidungen die Batterielebensdauer beeinflussen, sollte der Anwendungsfall detaillierte Beschreibungen der Faktoren beinhalten, welche den Energieverbrauch des Systems beeinflussen. Dazu zählen unter anderem: 

  • Die Art der Daten, die das Gerät von der Außenwelt sammeln muss und wie oft diese gesammelt werden müssen. 
  • Ob der Nutzer mit dem Gerät über eine App, ein Touch-Display, Tasten oder beides agiert. Falls ja, welche Informationen werden kommuniziert und wie oft werden diese verwendet? 
  • Wie die Gerätekommunikation mit anderen Wearables, einem Smartphone, einem lokalen Netzwerk oder dem Internet stattfindet. Der Energiebedarf kann je nach Funkschnittstelle (Bluetooth, Wi-Fi oder ZigBee) und deren Implementierung stark variieren. 
  • Wie oft das Gerät synchronisiert wird oder ein Datenaustausch mit seinen Peers oder dem Host-System stattfindet. Wird zu häufig mit dem Host-System (zum Beispiel Smartphone) synchronisiert, kann dies die Batterielebensdauer verringern. 

Sind diese Informationen zusammengetragen, sollte der Anwendungsfall ein detailliertes Bild der verschiedenen Betriebsmodi eines Systems ergeben und aufzeigen, wie viel Zeit das Gerät in jedem Modus verbringt. Dies bildet die Grundlage für das Energiebudget eines Systems und informiert über die Designabwägungen, die für eine längere Batterielebensdauer erforderlich sind.

Auswahl und Optimierung der MCU

Der energiebezogene Teil des Anwendungsfalls sollte alle Informationen über die Sensorik, Steuerung und Rechenaufgaben enthalten, die das Wearable ausführt. Hinzu kommen die Informationen darüber, welche Aufgaben der Mikrocontroller oder dessen Peripherie übernehmen, um so viel Energie wie möglich einzusparen. Dies hilft bei der Wahl der besten MCU für die jeweiligen Applikationsanforderungen sowie bei der Wahl der Entwicklungsstrategie.

Sind die Softwarefunktionen und Algorithmen sowie deren Ausführungshäufigkeit festgelegt, lassen sich die Rechenanforderungen des Geräts schon einmal grob abschätzen. In einem Fitnessmonitor beispielsweise erfasst die MCU die körperliche Aktivität des Nutzers durch einen Mehrachsen-Beschleunigungssensor, überwacht die Herzaktivität über einen IR-Näherungssensor und nutzt weitere Sensoren zur Messung der Temperatur, Feuchtigkeit, des Sauerstoffgehalts im Blut und sogar der Exposition von UV-Strahlen (Bild 2).

Der Mikrocontroller muss dann die Rohdaten der Sensoren filtern, Rauschen und andere Artefakte beseitigen, bevor er die eigentliche Schrittzahl und -frequenz bestimmen oder mit der Herzfrequenz kombinieren kann, um zwischen bestimmten Aktivitätsarten und anderen biometrischen Eingaben zu unterscheiden.

Unter den verschiedenen 32-Bit-Prozessorarchitekturen hat sich ARMs »Cortex«-Serie als Rechenkern für Embedded-Designs etabliert. Dafür sorgen die effiziente Architektur, der einfach erweiterbare RISC-Befehlssatz sowie zahlreiche Entwicklungswerkzeuge und Codebibliotheken. Im Laufe der Jahre hat ARM verschiedene Serien seiner Cortex-CPU auf den Markt gebracht, die alle auf bestimmte Anforderungen hin optimiert sind. »Cortex-M« eignet sich für Deeply-Embedded-MCUs und kommt dort zum Einsatz, wo Leistungsfähigkeit, Energieeffizienz und geringe Kosten entscheidend sind. Cortex-M bietet Core-Funktionen, die zahlreiche Anforderungen im Wearable-Bereich erfüllen, so zum Beispiel Preis, Batterielebensdauer, Rechenanforderungen und Art der Anzeige (Tabelle 1).

Rechenkern Cortex-M0+ Cortex-M3 Cortex-M4 
Display nein/LED kleines LCD mittleres LCD 
Verarbeitungsanforderungenniedrigmittel/keine FPUhoch/FPU
Batterielebensdaueram längstenlangmittel
Preis am niedrigsten niedrig mittel 
Tabelle 1: ARMs »Cortex«-M-Serie adressiert unterschiedliche Designs (FPU: Fließkommaeinheit)

In der Cortex-M-Serie sind die »M3«- und »M0+«-Cores für kostengünstige Anwendungen optimiert, die trotzdem hohe Rechenleistung und eine schnelle Systemantwort auf Echtzeitereignisse sowie eine niedrige dynamische und statische Leistungsaufnahme erfordern. Der komplexere und leistungsfähigere »M4«-Core führt rechenintensive Algorithmen biometrischer Überwachungsanwendungen wesentlich schneller aus, da sein erweiterter Befehlssatz DSP-Funktionen enthält.

Dessen Fließkommaeinheit (FPU) mit einfacher Genauigkeit (Single Precision) kann Ausführungszeiten drastisch verkürzen und damit die Zeit verringern, in der sich die MCU im aktiven Zustand befindet. Dies minimiert den Gesamtenergieverbrauch (Bild 3).

Um den Einfluss des Mikrocontrollers auf das Energiebudget des Geräts zu verringern, gilt es, die Häufigkeit und die Dauer jeder Aufgabe zu minimieren, die ein Aufwecken der MCU aus dem Sleep-Modus erfordert. Der Anwendungsfall sollte somit enthalten, wie häufig welche verschiedenen Aufgaben für die MCU zu erwarten sind und ob deren Ausführung ereignis- oder zeitgesteuert ist.

Sleep-Modi für lange Lebensdauer

Eine der besten Möglichkeiten, ein Low-Power-Embedded-System zu optimieren, ist das Auffinden des Sleep-Modus mit der geringsten Stromaufnahme, bei dem weiterhin eine Antwort auf Echtzeitereignisse möglich ist. Die meisten MCUs mit Cortex-M-Core unterstützen mehrere Sleep-Modi.

Die Mikrocontrollerfamilie »EFM32 Gecko« von Silicon Labs basiert auf Cortex-M-Cores und vereint eine verbrauchsoptimierte Peripherie und Taktarchitektur (Tabelle 2).

Parameter EM0 (Run Mode) EM1 (Sleep Mode) EM2 (Deep Sleep Mode) EM3 (Stop Mode) EM4 (Shut-off Mode)
Stromaufnahme 110 µA/MHz 45 µA/MHz 0,9 µA 0,6 µA 20 nA
Aufwachzeit-02 µs2 µs160 µs
schnell taktende Peripherieverfügbarverfügbar---
langsam taktende Peripherieverfügbarverfügbarverfügbar--
asynchrone Peripherieverfügbarverfügbarverfügbarverfügbar-
voller Erhalt von CPU und SRAMjajajaja-
Power-on Reset/Brown-out Detektorjajajajaja
Aufwach-Ereignisse alle alle 32-kHz-Peripherien asynchrone IRQs, I²C-Slave, Analog-Komparatoren, Spannungskomparatoren Reset, GPIO (steigende/fallende Flanke)
Tabelle 2: Verschiedene Power-Modi beim »EFM32 Gecko« von Silicon Labs

Die Architektur wurde speziell für stromsparende Anwendungen entwickelt und bietet eine Reihe von Power-Modi, mit denen sich bei Wearables eine optimale Energieeffizienz erzielen lässt. Zu den typischen Low-Power-Modi in MCU-Architekturen zählen: 

  • Sleep/Standby: ermöglicht eine schnelle Rückkehr in den aktiven Modus (in der Regel über einen Interrupt) auf Kosten eines geringfügig höheren Stromverbrauchs. 
  • Deep Sleep: hält die wichtigen MCU-Blöcke aktiv, während hochfrequente Systemtakte und andere nicht erforderliche Lasten deaktiviert sind. 
  • Stop: eine noch tiefere Version des Deep-Sleep-Modus, die eine weitere Stromeinsparung ermöglicht, während begrenzte autonome Peripherieaktivität und eine schnelle Wake-up-Funktion bestehen. 
  • Off: dieser »Fast-Aus«-Zustand erhält ein Minimum an notwendigen Funktionen, um einen Wake-up durch einen externen Stimulus zu initiieren. 

»Intelligente« Peripherie

Viele MCUs sind mit Peripherie ausgestattet, die eine routinemäßige Taktung, I/Os und Verwaltungsaufgaben ausführt, während die CPU in einem der energiesparenden Sleep-Modi verbleibt. Einige MCUs bieten sogar autonome Peripherie, die mehrere Funktionen (wie Zähler/Timer, ADCs, DACs, GPIOs, serielle Transceiver etc.) ohne Beteiligung der CPU ausführt. So kann die gesamte integrierte Peripherie der EFM32-MCUs autonom agieren und in einem oder mehreren Sleep-Modi des Bausteins aktiv bleiben.

Neben der genannten Peripherie bieten viele ARM-basierte MCUs noch weitere Funktionen: 

  • Einen Controller für kapazitive Sensorik über Touchpads und Koordinaten in einem xy-Raster, der minimale oder gar keine CPU-Intervention erfordert, 
  • einen LCD-Treiber, der ohne CPU-Eingriff numerische LCD- oder TFT-Displays über DMAs aus dem Speicher ansteuert, sowie 
  • Analog-Komparatoren zur Überwachung von Schwellenspannungen für Alarmzustände – ebenfalls ohne CPU-Eingriff. 

In einigen sehr energieeffizienten MCU-Architekturen können Peripheriefunktionen wie serielle Kommunikation, Zähler/Timer, Analog- und Digital-Komparatoren und I/Os über einen separaten Low-Power-Bus koordiniert werden. Damit lassen sich Ereignisse und Signale von einer Peripherie als Eingangssignal oder als Trigger für andere Peripherie verwenden. Diese Busarchitektur garantiert einen zeitkritischen Betrieb ohne CPU-Overhead und mit reduziertem Software-Overhead, was zu äußerst stromsparenden Wearable-Designs mit langer Batterielebensdauer führt.

Über den Autor:

Raman Sharma ist Director Field Marketing Americas bei Silicon Labs.