Sub-GHz-Funkanbindung für Embedded-Systeme

Bild 1: Sub-GHz-Wireless ist eine beliebte Wahl für Smart-Metering-Anwendungen.Silicon Labs

In allen Märkten und Branchen boomt die drahtlose Datenanbindung, da immer mehr Elektronikgeräte und -systeme mit einer Steuerung und/oder Datenkommunikation per Funk ausgestattet werden. Verbraucher wollen den Komfort allgegenwärtiger Kommunikation. Die Funkanbindung wird damit eine Grundvoraussetzung für viele Elektronikgeräte. Das schnelle Wachstum des Internet der Dinge (IoT; Internet of Things) sorgt für eine zusätzliche Verbreitung drahtlos angebundener Einrichtungen. Branchenführer gehen davon aus, dass die Zahl der ans Internet angeschlossenen Geräte im Jahr 2015 die Marke von 15 Milliarden übersteigen wird. Bis zum Jahr 2020 sollen es 50 Milliarden Geräte beziehungsweise Einrichtungen sein. Dieses immense Wachstum umfasst die greifbaren Internet-Geräte wie Smartphones, Tablets, Wearable-Computing-Produkte sowie TV-Geräte und Settop-Boxen. Es gibt aber auch eine Vielzahl proprietärer Wireless-Systeme, die im Hintergrund arbeiten, wie zum Beispiel Sicherheits- und Überwachungskameras, Beleuchtungssteuerungen, Remote Keyless Entry (RKE), intelligente Thermostate, Smart Meter und eine Reihe weiterer netzwerkangebundener Haushalts- und Gebäudeautomatisierungsgeräte.

Die Wahl der richtigen Funkanbindung für Embedded-Systeme erfordert eine sorgfältige Prüfung der verschiedenen Designmöglichkeiten. Zu den wichtigen Faktoren bei der Wahl der optimalen Kommunikationstechnik zählen die Bereitstellungskosten, Sicherheit, Erfüllung gesetzlicher Auflagen, Reichweite und der Stromverbrauch. Für eine Funkanbindung stehen verschiedene Techniken zur Verfügung: WiFi, Bluetooth, ZigBee und Sub-GHz-Wireless. Für viele Anwendungen wie Backhaul-Kommunikation von einem Smart Meter in den Haushalt und weiter zu einer Datensammelschnittstelle (Bild 1), ist die Sub-GHz-Technik eine geeignete Wahl. Sie bietet eine große Reichweite, hervorragende Ausbreitung, stromsparenden Betrieb (längere Batterielebensdauer) und Zugriff auf das unlizenzierte Sub-GHz-Spektrum weltweit.

Die Neuerungen der IEEE 802.15 rund um Smart-Utility-Netzwerke und der IEEE 802.11 für Sub-GHz-WiFi zeigen das anhaltende Interesse an Sub-GHz-Funklösungen. Die steigende Nachfrage nach Sub-GHz-Funkanbindung bringt zahlreiche Anwendungen hervor und erhöht damit auch den Bedarf an verschiedenen Funk-Kommunikations-/Steuerungsarchitekturen.

Design-Überlegungen bei Funksystemen

Die steigende Nachfrage nach Datenanbindung führt dazu, dass traditionell nicht angebundene Geräte nun plötzlich eine Funkanbindung benötigen. Meist haben die Entwickler dieser Embedded-Produkte aber keine Erfahrung im Bereich Wireless Design. Die Nachfrage nach einer Funkanbindung und die Vielfalt an Wireless-fähigen Geräten erfordern flexible Hardware- und Software-Architekturen. Im Folgenden werden drei verschiedene Wireless-Architekturen für die Sub-GHz-Funkanbindung näher untersucht. Wie trägt jeder Ansatz zu einer optimalen Lösung bei, um die speziellen Anforderungen von Embedded-Systemen zu erfüllen? Bei der Wahl der richtigen Funkarchitektur sind auch zahlreiche Faktoren zu berücksichtigen, zum Beispiel Vorgaben hinsichtlich der Kosten, des Formfaktors, des Designs und der Time-to-Market.

Um 35 Milliarden neue Internet-angebundene Geräte bis zum Jahr 2020 bereitzustellen, müssen die Gesamtbetriebskosten weiter sinken. Dazu müssen nicht nur die Kosten für die Stückliste (BOM; Bill of Materials) niedrig ausfallen, sondern auch die Produktentwicklungskosten und die fortlaufenden Kosten. Die kostengünstigste Hardwarelösung führt zu den niedrigsten BOM-Kosten, kann aber erhebliche Entwicklungskosten für die Netzwerk- und Softwareentwicklung mit sich ziehen. Die günstigste Hardwarelösung kann auch mehr Support erfordern, vor allem bei Upgrades im Feld. Die Wahl der richtigen Architektur kann demnach die Gesamtkosten verringern und den Gewinn maximieren.

Damit das Internet der Dinge erfolgreich wird, müssen angebundene Geräte nützlich sein, ohne aufdringlich zu sein. Verbraucher wollen Daten von Hunderten von Einrichtungen in ihren Haushalten, aber sie wollen sie nicht immer sehen. Die physikalische Größe der Geräte ist daher eine wichtige Designerwägung. Zu den gängigen Vorgaben für die Systemarchitektur zählt die physikalische Größe des Embedded-Systems, einschließlich der Leiterplattenfläche, über die die Funkfunktion und die Batteriegröße implementiert werden. Ist das Design platzbeschränkt, muss der Einfluss der Funkanbindung auf die Designgröße beschränkt werden. Zu diesen Faktoren zählen die IC-Stellfläche, Antennengröße, die Gesamtzahl diskreter Bauelemente für die Funklösung und der Stromverbrauch. Eine Senkung des Stromverbrauchs kann die Größe der erforderlichen Batterie verringern. Die Verringerung der Anzahl und/oder Größe von Systemkomponenten kann einen direkten Einfluss auf die Produktgröße und den Formfaktor haben.

Neue IoT-Anwendungen finden sich jeden Tag und entwickeln sich schnell weiter. Daher ist eine schnelle Markteinführung gefordert. Die Wahl der Wireless-Architektur kann die Time-to-Market direkt beeinflussen. Ein gern übersehener Aspekt ist der Zeitaufwand für die Integration der Funksoftware in die Anwendung. Auch die Funkspezifikationen entwickeln sich stetig weiter, was mehr Updates für die Funksoftware als für den eigentlichen Produkt-Code erfordert. Das Zusammenführen von stabilem Produkt-Code mit sich weiterentwickelndem Wireless-Code kann den Test- und Validierungsaufwand erhöhen und die Time-to-Market verlängern. Die Trennung der Wireless-Software von der Anwendungssoftware kann dieses Risiko verringern und die Markteinführung beschleunigen.

Embedded-Entwickler müssen bei Funklösungen für ihre Anwendungen zahlreiche weitere Design-Einschränkungen berücksichtigen, zum Beispiel den Stromverbrauch, die Funkreichweite und die abgestrahlten Emissionen. Dabei gilt: Die Funkarchitektur muss nicht unbedingt alle diese Vorgaben beeinflussen, und die Produktanforderungen können nicht von allen Architekturen erfüllt werden. Benötigt das Embedded-System eine bestimmte Benutzerschnittstelle wie einen LCD oder Touchscreen, kann ein einzelner Funk-IC nicht alle erforderlichen Funktionen des Endprodukts bieten. Der Entwickler muss also eine Multi-Chip-Lösung finden, mit der sich die Produktanforderungen erfüllen lassen.

Lösungen für die Funkanbindung

Bild 2: OSI-Modell eines Embedded-System-Designs.Silicon Labs

Im Folgenden werden drei gängige Systemarchitekturen für Embedded-Funklösungen näher untersucht. Die Architektur bestimmt die Hardware- und Softwarepartitionierung, einschließlich der Wahl der ICs. Bild 2 zeigt drei Optionen auf Basis des OSI-Modells, um die Software- und Hardwareblöcke in einem Embedded-System zu partitionieren.

System-on-Chip

Ein System-on-Chip-Baustein wie Silicon Labs‘ Funk-MCU Si1060 in Bild 3 vereint einen Mikrocontroller und einen Transceiver in einem einzigen Chip, auf dem der Funksoftwarestack und die Anwendungssoftware läuft. Der SoC muss über ausreichend Funktionen verfügen, um das Embedded-System zu unterstützten. Dazu zählen die I/Os für Taster, A/D-Wandler (ADCs) zum Erfassen von Umgebungsbedingungen wie Temperatur und Feuchtigkeit. SoCs sind generell sehr stromsparend, bieten einen kleinen Formfaktor und ermöglichen eine lange Batterielebensdauer. Diese Option bietet die kostengünstigste Lösung mit der kleinsten Baugröße.

Bild 3: SoC in einer Funksensor-Anwendung.Silicon Labs

Zu den typischen Anwendungen für SoCs zählen Systeme mit fester Funktion, die eine einfache Benutzerschnittstelle oder in vielen Fällen keine Benutzerschnittstelle aufweisen, wie zum Beispiel Fernbedienungen, Schlüsselanhänger zum Aufsperren/Verriegeln der Fahrzeugtüren oder Tür-/Fenster-Sicherheitssensoren in der Haustechnik.

MCU plus Transceiver

Steht ein geeigneter SoC nicht zur Verfügung, erlauben Architekturen mit einem separaten Mikrocontroller und Funk-Transceiver die Wahl der optimalen MCU für die Anwendung (Bild 4). Zu den MCU-Optionen zählen nicht nur MCU-Architekturen (8 Bit contra 32 Bit, einschließlich verschiedene ARM Cortex-M Cores), sondern auch On-Chip-Funktionen wie ein LCD-Controller, USB Support, verschiedene I/Os, Timer, Komparatoren, ADCs und Flash-Speicher. Der Entwickler kann dann den besten Transceiver hinzufügen, um die Funkanforderungen der Anwendung zu erfüllen.

Bild 4: Diskreter Funk-Transceiver in Kombination mit einer MCU.Silicon Labs

Aus der Sicht der Anwendung ist eine Lösung mit MCU plus Transceiver ähnlich zu einem SoC, da das Netzwerk relativ einfach ist und nur wenige Timing-Bedenken im System zu beachten sind. Die MCU hostet die gesamte Software, einschließlich Anwendungs- und Funksoftware. Die physikalische Ebene (PHY) und die Datenlinkebene sind jedoch meist in den Transceiver integriert. Das Endprodukt enthält dann meist eine einfache Benutzerschnittstelle für die Einrichtung und Steuerung.

Netzwerk-Coprozessor

Bild 5: NCP mit separatem Host-Mikrocontroller.Silicon Labs

Ein Netzwerk-Coprozessor (NCP) kann eingesetzt werden, wenn die Komplexität und Leistungsanforderungen des Endprodukts den Einsatz einer Highend-MCU oder eines Mikroprozessors (MPU) erfordern. Ähnlich wie bei einem Funk-SoC vereint ein NCP eine MCU und einen Transceiver in einem Chip. Ein NCP bietet aber nicht die Funktionalität, die gesamte Anwendung zu unterstützen. Er handhabt den gesamten Kommunikations-Stack und die serielle Schnittstelle zum Host-Prozessor (UART oder SPI). Die NCP-Architektur trennt die Komplexität der Anwendungssoftware von der Kommunikationssoftware. Dies ist dann erforderlich, wenn das Netzwerk-Stack-Timing entscheidend ist oder ein hoher Datendurchsatz gefordert ist. Dieser Ansatz stellt die teuerste Systemlösung dar; die Kosten werden aber meist durch die weniger komplexe Entwicklung und die schnellere Markteinführung ausgeglichen. Gängige Systeme, die sich für eine NCP-Architektur eignen, sind Gateways, Sicherheitsbedienfelder und Geräte, die mehrere Protokoll-Stacks verarbeiten (Bild 5).

Design-Überlegungen

Mit diesen drei Funkarchitekturen lassen sich die Designerwägungen von Embedded-Wireless-Anwendungen adressieren. Der Entwickler muss die Vor- und Nachteile jeder Architektur abwägen, um die für seine Applikation geeignetste Lösung zu finden.

Mit dem Übergang von SoC- auf MCU plus Transceiver- und NCP-Architekturen steigen auch die Hardwarekosten. Diese lassen sich jedoch durch niedrigere Entwicklungs- und Supportkosten amortisieren, da die Software weniger komplex ist und sich die Markteinführung beschleunigt. Die NCP-Architektur ist die günstigste Lösung in Sachen Entwicklung und Wartung, da die Funk-Software vom restlichen System abgekoppelt ist. Sie lässt sich daher aktualisieren, ohne dabei den restlichen Applikationscode zu beeinflussen. Wird der Applikationscode im Laufe der Zeit komplexer, sollten in jedem Fall NCP-Architekturen berücksichtigt werden, um die höheren Gesamtbetriebskosten von SoC- und MCU plus Transceiver-Lösungen zu vermeiden.

Während ein SoC die Integration der MCU und des Funkteils und somit generell eine kleinere Baugröße ermöglicht, können sich aber Nachteile bei der geforderten Funktionalität des Endprodukts ergeben. In vielen Fällen werden die Größenvorteile eines SoC durch die Funktionsanforderungen ausgehebelt. Verlangt die Anwendung einen großen Host-Prozessor, hat ein Transceiver den geringsten Einfluss auf die Produktgröße. Dominiert die Größe der Batterie, kann ein NCP die optimale Wahl sein, da der gesamte Netzwerkdatenverkehr ohne Aktivierung des leistungshungrigen Host-Prozessors abgewickelt wird. Bezüglich der Baugröße und der Design-Einschränkungen müssen Entwickler also die Anforderungen des Endprodukts verstehen.

Zusammenfassung der Design-Einschränkungen.Silicon Labs

Eine schnelle Markteinführung oder „Time to Revenue“ ist ein entscheidender Faktor bei der Wahl der richtigen Funkarchitektur. Dabei sind zahlreiche Aspekte zu berücksichtigen, die die Time-to-Market beeinflussen. Wie bereits erwähnt, wird die Komplexität der Software in Embedded-Designs gerne übersehen. In einem einfachen unidirektionalen Funknetzwerk ist die Softwarekomplexität in der Regel kein Problem. Wird ein Netzwerk jedoch komplexer, zum Beispiel durch das Hinzufügen bidirektionaler Kommunikation, weiterer angebundener Geräte und vor allem durch Maschennetzwerke, beeinträchtigt diese zusätzliche Komplexität die Anwendung. Funkanwendungen sind meist zeitbeschränkt und erfordern eine gewisse Latenz. Anwendungen, die Prozessor- oder Interrupt-intensiv sind, können dann zu Problemen führen, wenn die Applikation auf der gleichen CPU läuft wie der Netzwerk-Stack. Nimmt die Komplexität der Anwendung und des Netzwerk-Stacks zu, können NCP-Architekturen diese Anforderungen am besten lösen.

(jj)