Wireless LAN (WLAN) ist längst in allen Arten von Embedded-Applikationen angekommen. Da liegt die Vermutung nahe, dass es für jeden Anwendungsfall eine geeignete WLAN-Lösung gibt. In der Praxis jedoch ist es oft gar nicht so einfach, die bestmöglichen Komponenten und die richtige Vorgehensweise zu bestimmen. Eine der grundlegenden Entscheidungen ist dabei die Frage „Make or Buy?“. Diese Frage wird immer dann gestellt, wenn die Eigenentwicklung spezielle Fähigkeiten beziehungsweise viel Zeit benötigt oder überhaupt erst in großen Stückzahlen praktikabel ist. Bei der drahtlosen Kommunikation steht Buy in der Regel für den Einsatz von Modulen.
Doch durch Verwenden eines Moduls ist der Entwickler häufig noch nicht am Ziel: Auch ein optimiertes Antennen- beziehungsweise Gehäusedesign oder die erforderlichen Zertifizierungen setzen Erfahrungen und Fähigkeiten voraus, die es sich häufig nicht selbst anzueignen lohnt. Durch eine Vielzahl von Dienstleistungsangeboten lassen sich diese Herausforderungen lösen. Wobei sich in der Regel eine frühzeitige Zusammenarbeit lohnt, um die externen Erfahrungswerte bereits in die Produktentwicklung einfließen lassen zu können. Das bisher Genannte trifft – in mehr oder weniger starker Ausprägung – im Grunde auf alle Funktechnologien zu.
WLAN weist zudem eine Besonderheit auf: Als das drahtlose Pendant zu Ethernet lassen sich nahezu beliebig große lokale Netzwerke erstellen und optional über Router mit dem Internet verbinden. Der Einsatz der Internetprotokollfamilie ermöglicht den direkten Zugriff auf die unterschiedlichsten lokalen wie entfernten Geräte und Dienste. Die Anzahl an möglichen Protokollen zum Übertragen von Daten, Dateien, Nachrichten und Steuerbefehlen ist immens und macht WLAN universell einsetzbar. Daten werden zunehmend in der Cloud abgelegt und verarbeitet, Verschlüsselung und Authentifizierung sind daher unumgänglich. All diese Mechanismen wurden ursprünglich für Server und PCs, inzwischen zunehmend auch für Smartphones und Multimedia-Geräte, entwickelt. Wie kann sichergestellt werden, dass ein WLAN-Modul alle Anforderungen erfüllt und sich vielleicht sogar um zukünftige Anforderungen erweitern lässt?
Typische WLAN-Modul-Kategorien
Die Beantwortung dieser Frage erfordert zunächst eine kurze Betrachtung der beiden typischen WLAN-Modul-Kategorien: Da wäre als erstes das Self-Contained-Modul, das per UART oder SPI direkt mit einem Mikrocontroller verbunden werden kann. Sämtliche WLAN-spezifische Software sowie der TCP/IP-Stack läuft auf dem Modul und kann vom Anwender nicht modifiziert oder erweitert werden. Die auf dem externen Mikrocontroller erforderliche Treibersoftware ist häufig einfach, das Modul wird meist über Befehle aus
ASCII-Zeichen, zum Beispiel „AT Befehlssatz“, konfiguriert und angesteuert. Manche Module besitzen mehrere Schnittstellen oder erlauben es, über die Host-Schnittstelle beziehungsweise „over-the-air“ ein Firmware Update einzuspielen. Einige Varianten sind mit einem zweiten, frei programmierbaren Mikrocontroller ausgestattet, auf dem ein kundenspezifischer Applikations-Code laufen kann.
Als zweites gibt es Module ohne vollständigen Software-Stack. Sie werden meist per SDIO (Secure Digital Input/Output) mit einem Host Prozessor verbunden, auf dem als Betriebssystem zum Beispiel ein Embedded Linux läuft. Diese Module werden teilweise als SDIO-WLAN-Module bezeichnet. Genauso, wie bei einem USB WLAN Dongle, werden solche Module durch einen Kernel Driver ans Netzwerk-Subsystem des Betriebssystems angebunden. Viele WLAN-spezifische Funktionen und der gesamte Netzwerk-Protokollstack laufen auf dem Host-Prozessor als Teil des konzeptionell unverzichtbaren Betriebssystems. Bei der Erweiterbarkeit und Nutzung aus der eigenen Applikationssoftware gibt es nahezu keine Einschränkungen.
Die letztgenannte Kategorie ermöglicht in der Regel umfangreiche Freiheitsgrade in Bezug auf die Netzwerkfähigkeiten der Applikation. Sie erfordert jedoch detaillierte Kenntnisse über das verwendete Betriebssystem – zumeist Linux – und ist zudem nur möglich, wenn ein „linuxfähiges Prozessorsystem“ mit entsprechender Speicherausstattung überhaupt in Frage kommt.
Demgegenüber werden Self-Contained-Module nicht jeder Applikation gerecht. Die limitierten Speicher-Ressourcen des Moduls erlauben nur die Implementierung eines Teils der Internetprotokollfamilie, eine Erweiterbarkeit oder Auswahl der benötigten Protokolle ist nicht vorgesehen. Um diese und weitere Einschränkung zu reduzieren, bieten einige Herstellern inzwischen eine weitere Modul-Kategorie an: Das Customizable-Modul ist der Hardware eines Self-Contained-Moduls ähnlich, nur dass hier die Firmware ganz oder teilweise modifiziert werden kann. Hersteller dieser Module oder der darauf befindlichen WLAN-Chips bieten meist eine Integrierte Entwicklungsumgebung (IDE) zusammen mit der erforderlichen WLAN-Software und verschiedenen Applikationsbeispielen an, die als Ausgangspunkt für die eigene Custom-Firmware verwendet werden können. Dabei kann nicht nur die Netzwerk- und WLAN-Funktionalität angepasst, sondern auch
applikationsspezifische Software hinzugefügt werden.
Beispiele für Auswahlkriterien
Abgesehen von der reinen Software-Funktionalität haben selbstverständlich auch andere Applikationsanforderungen einen Einfluss auf die Modul-Auswahl, nachfolgend genannt sind nur einige Beispiele.
Bandbreite: Bei einem über UART angebundenen Self-Contained-Modul ist häufig sowohl Datendurchsatz als auch Latenz durch die Schnittstelle limitiert. SPI und SDIO hingegen bieten deutlich bessere Werte. Auch die verwendeten Prozessoren, deren Speicherressourcen sowie die eingesetzte Software haben einen Einfluss auf die maximal mögliche Bandbreite.
Kosten: Die Preise der Module beinhalten, neben den Kosten für die Hardware, auch den Entwicklungs- und Zertifizierungsaufwand sowie die Entwicklung, Pflege und Support der enthaltenen oder zur Verfügung gestellten Software. Statt des direkten Vergleichs verschiedener Modulpreise sollte immer versucht werden, die jeweils resultierenden Systemkosten unter Einbeziehung des internen und externen Entwicklungsaufwandes zu vergleichen.
Risiko: Nur das saubere Zusammenspiel von Hardware und Software führen zu einer stabilen und performanten WLAN-Kommunikation. Fehlende, fehlerhafte oder schlecht dokumentierte Treiber oder Beispielsoftware kann schnell zu einem signifikanten Risiko sowohl für die Kosten als auch den Erfolg des Projektes werden. Je nach Modul können die vorhandenen beziehungsweise zugänglichen Networking- und RF-Erfahrungen ebenfalls einen großen Einfluss auf das Entwicklungsrisiko haben.
Sicherheit: Die auf Self-Contained-Modulen verwendete fixe Firmware ist meist keine vollständige Eigenentwicklung des jeweiligen Herstellers. Durch die Analyse des Netzwerkverkehrs lassen sich beispielsweise Rückschlüsse auf verwendete Software Pakete, zum Beispiel FreeRTOS und LwIP, ziehen und damit auch auf deren Sicherheitslücken. Wird die einmal ausgelieferte Firmware nicht oder nur selten aktualisiert, können diese Lücken über längere Zeit für verschiedene Angriffsszenarien ausgenutzt werden.
Es zeigt sich, dass viele der für die Auswahl eines Moduls oder eines Entwicklungskonzeptes relevanten Kriterien im Zusammenhang mit Software stehen. Dabei kann es mitunter schwierig sein, die für einen Vergleich erforderlichen Parameter überhaupt in Erfahrung zu bringen, weil sie vom Hersteller nur unvollständig oder inkonsistent, also in nicht vergleichbarer Form, zur Verfügung gestellt werden. Eine Evaluierung der in Frage kommenden Module und Konzepte bringt in der Regel weitere Erkenntnisse, kann jedoch unter Umständen sehr viel Zeit in Anspruch nehmen und Entwicklungskapazität binden.
Durch Software-Expertise zur Entscheidung
Es besteht jedoch auch die Möglichkeit, bei der Selektionsprozedur auf die Erfahrungen und Kenntnisse der jeweils kompetentesten Software-Spezialisten zurückzugreifen: Wird voraussichtlich Linux beziehungsweise Android zum Einsatz kommen, so ist die Vielzahl an möglichen Spezialisten groß: Von Freelancern bis zu großen Entwicklungsdienstleistern finden sich rund um Embedded Linux alle möglichen Angebote. Die Ermittlung der Treiber-Unterstützung bei Hardware-Entscheidungen ist ein typischer Bestandteil vieler Projekte. Häufig liegen Erfahrungswerte zu bestimmten Paarungen aus Prozessoren und WLAN-Chipsätzen vor oder lassen sich leicht ermitteln. Auch der Vergleich von Zeitaufwand und Entwicklungskosten bei Verwenden verschiedener Kombinationen sowie die langfristige Pflege der Treiber-Sourcen durch die Community sind recht genau abschätzbar. Bei gut unterstützten Embedded-WLAN-Chipsätzen kann davon ausgegangen werden, dass es am Markt auch verschiedene Module mit unterschiedlichen Antennen-Optionen gibt.
Im Falle eines Self-Contained-Moduls ist die Situation komplizierter, aber nicht unlösbar. Es gibt in Zentraleuropa Embedded-Networking-Entwicklungsdienstleister, die für Modulhersteller die WLAN-Firmware oder für Kunden auf Basis von Customizable-Modulen eine individuelle Firmware entwickelt haben. Im Prinzip ist es über diese Dienstleister auch möglich, auf bestimmten Self-Contained-Modulen Anpassungen des Funktionsumfangs zu implementieren oder kundenspezifischen Code zu integrieren. Da auch Erfahrungen zum Einsatz von regulären Self-Contained-Modulen sowie deren Möglichkeiten und Einschränkungen vorliegen, kann eine individuelle Empfehlung aus einem deutlich größeren Spektrum gegeben werden, als dies ausschließlich mit Standard-Modulen der Fall ist.
Breites Spektrum an Lösungsansätzen
Zusammenfassend kann festgestellt werden, dass das frühzeitige Einbinden von Software-Spezialisten ein breites Spektrum an Lösungsansätzen zugänglich machen und zugleich Vorteile bei Projektrisiko, Time-to-Market und Funktionsumfang zur Folge haben kann. Die Arrow-FAEs können dabei behilflich sein, mögliche Partnerfirmen zu ermitteln – in jedem Fall ist es dann erforderlich, die individuellen Applikationsanforderungen und ermittelten Risikofaktoren direkt und im Detail mit den Dienstleistern zu erörtern.
