Ganzheitliche Testumgebung IoT-Funknetze simulieren, virtualisieren, emulieren und testen

IoT-Funknetzwerke: Simulation, Virtualisierung, Emulation und Test sind eine Herausforderung
IoT-Funknetzwerke: Simulation, Virtualisierung, Emulation und Test sind eine Herausforderung

Funknetzwerke müssen getestet werden, bevor sie in Betrieb gehen. Ein Großteil der Testansätze bezieht sich aber nur auf die Systemebene. Mit einer passenden Modellierung können die Tests bereits in früheren Entwicklungsstadien beginnen.

Der Test eingebetteter Systeme gewinnt angesichts der zunehmenden Komplexität und der gestiegenen Zuverlässigkeitsanforderungen rapide an Bedeutung. Dies gilt in besonderem Maße für verteilte Systeme im Internet der Dinge, deren Funktionen und Anwendungen über Kommunikationskanäle gekoppelt werden. Bei räumlich verteilten Funknetzen kommt eine zusätzliche Herausforderung hinzu, weil vermaschte Netzwerke besonders komplex werden können und somit eine Vielzahl an verschiedenen Anwendungsszenarien getestet werden müssen.

Auf Grund dieser Bedeutung haben sich verschiedene Herangehensweisen entwickelt, die die spezifischen Eigenheiten der jeweiligen Entwicklungen im Blick haben. Ein Großteil der Ansätze zielt allerdings nur auf die Systemtestebene ab. Dabei ist es gerade bei solch komplexen Systemen wichtig, schon frühzeitig einzelne, möglichst überschaubare und unabhängige Systemteile zu testen und erst, wenn deren korrekte Funktion verifiziert wurde, das Gesamtsystem zu prüfen. Dieses Vorgehen reduziert den Aufwand der Fehlerursachensuche erheblich und erhöht die Testabdeckung. Vor allem durch die Abstraktionsebenen, also dadurch, welche Systemaspekte betrachtet, bzw. nicht betrachtet (abstrahiert) werden, unterscheiden sich die Herangehensweisen. Da diese Ansätze in den vergangenen Jahrzehnten unabhängig voneinander entstanden sind, wurden sie bislang auch in unabhängigen Umgebungen bearbeitet, was zu vielen Doppelarbeiten geführt hat. Dies gilt insbesondere für die beiden folgenden Aspekte:

Auf diversen Ebenen werden Testfälle unterschiedlich modelliert, auch wenn sie eigentlich die gleichen Funktionen oder Abläufe beschreiben. Die Modelle der Funkknoten wurden bislang unabhängig voneinander entwickelt. So wurden vor allem die Simulationsmodelle (siehe Absatz: Netzwerksimulation) komplett unabhängig von den Implementierungen auf der realen Hardware (siehe Absätze: Emulation und Test) erstellt. Die doppelte Arbeit hat auch dazu geführt, dass die Netzwerksimulation in realen Projekten viel zu selten eingesetzt wird. Viel schwerer wiegt es aber, dass es hierbei auch noch komplex ist, die Implementierungen auf den unterschiedlichen

Testumgebung mit vier Abstraktionsebenen

Ebenen konsistent zu halten. Wenn also ein Fehler im Simulationsmodell gefunden und korrigiert wird, dann bleibt er oftmals in der realen Implementierung noch bestehen, und umgekehrt. Außerdem kann die Simulationsebene nicht dazu genutzt werden, um Fehlverhalten, das in der realen Hardware-Implementierung beobachtet wurde, auf der Simulationsebene für eine detailliertere Analyse nachzustellen. Am Institut für verlässliche Embedded Systems und Kommunikationselektronik der Hochschule Offenburg wurde ein durchgängiger Implementierungs- und Verifikationsansatz für Funknetzwerke entwickelt, der über vier Abstraktionsebenen hinweg eingesetzt werden kann (Bild 1).

Damit können Entwickler erstmals komplexe netzwerkbasierte Systeme in einer durchgängigen und einheitlichen Umgebung simulieren und testen – incl. Tests in realen Umgebungen.

Netzwerksimulation mit Softwaremodellen

Das Verhalten von Kommunikationssystemen kann im Rahmen einer Simulation komplett in Software modelliert werden, wobei in der Praxis insbesondere drei Ebenen unterschieden werden können:

  • Es können insbesondere die physikalischen Eigenschaften des Kanals modelliert werden. Solche Kanalmodelle werden in der Regel für die Entwicklung und Optimierung von Modulations- und Codierungsverfahren eingesetzt. Die Modelle können aber auch bei der Simulation auf abstrakteren Ebenen zum Einsatz kommen, da durch sie auch Eigenschaften, wie Kollisionsverhalten oder erreichbare Datenraten bestimmt werden können.
  • Es kann die Kommunikation auf einer sehr abstrakten Ebene beschrieben werden, um z.B. das stochastische Verhalten von Kanalzugriffsverfahren zu beschreiben. Solche Werkzeuge werden in der Regel generisch in Matlab oder noch einfacher in einem Tabellenkalkulationsprogramm wie Excel umgesetzt, um erste Abschätzungen zu erhalten.
  • Netzwerksimulatoren im engeren Sinne sind Werkzeuge, die insbesondere für die Modellierung des ereignisorientierten (Event-driven) Verhaltens von Kommunikationsknoten ausgelegt sind. In einem Netzwerksimulator können z.B. die endlichen Zustandsautomaten (Finite State Machines) zahlreicher paralleler Knoten durchgerechnet werden. Die bekanntesten Beispiele für solche Netzwerksimulatoren sind NS-3 und OMNet++ als quelloffene und lizenzfreie Umgebungen, sowie der kommerzielle Riverbed Modeler, der lange als OPNET-Modeler vermarktet wurde. Darüber hinaus gibt es noch eine Vielzahl von protokoll- oder implementierungsspezifischen Simulatoren, wie z.B. Cooja für die Contiki-Umgebung oder OpenSim zur Simulation von OpenWSN-Netzwerken.

Der wesentliche Vorteil der Nutzung dieser Netzwerksimulatoren besteht darin, dass die Protokollimplementierung schon sehr frühzeitig durchgeführt werden kann, z.B. auch wenn noch keine Hardware zur Verfügung steht. So können sehr schnell und kostengünstig auch große Netze mit vielen hundert oder tausend Knoten aufgebaut und ihr Verhalten bezüglich Stabilität und Skalierbarkeit überprüft werden, bevor letztendlich auch das stochastische Verhalten von längeren Simulationsläufen modelliert werden kann. Zudem werden während der Entwicklung verschiedene Debugging- und Analysemethoden zur Verfügung gestellt, die es ermöglichen, die nebenläufigen Zustandsautomaten in den verschiedenen Kommunikationsknoten im Detail zu beobachten und zu verfolgen.

Viele der bereits existierenden Modelle wurden spezifisch für die jeweiligen Simulatoren geschrieben und nutzen dementsprechend auch deren Plattformgegebenheiten aus. Obwohl dieses Vorgehen durchaus mit Vorteilen verbunden ist, besteht allerdings auch die Möglichkeit, einen Gutteil vor allem der höheren Schichten unabhängig zu beschreiben, sodass Teile dieser Modelle später identisch auf eine Hardware-Implementierung übernommen werden können. Hierzu muss zum einen die Hardwareabstraktionsschicht (Hardware Abstraction Layer, HAL) auf die Simulationsumgebung angepasst werden. Darüber hinaus muss in den meisten Fällen eine Anpassung an die jeweilige Betriebsart des Simulators vorgenommen werden. So setzen z.B. viele Simulatoren auf ereignisgesteuerte Ausführungen. Dies erfordert dann entweder eine entsprechende Konzeption der Firmware – insofern deren Architektur noch nicht festgelegt ist – oder eine Verschmelzung unterschiedlicher Paradigmen, was z.B. bei Endlosschleifen-Implementierungen durch die gezielte Einschleusung von Pseudo-Ereignissen erfolgen kann.