Sensor Products for Enterprises Creating Technological Opportunities in Remote Sensing

Ziele

Fernerkundung mit Drohnen ist eine Voraussetzung für „Precision Agriculture“. Gerade die bildgebenden Systeme (Hyperspektral-Scanner, Multispektal-Kameras, Synthetic Aperture Radars) erzeugen jedoch enorme Datenmengen, die gespeichert und prozessiert werden müssen. Sie entstehen aus den Sensorrohdaten (Level 0), die über Vorverarbeitungs- und Zwischenschritte wie Kalibrierung und Georeferenzierung (Level 1), daraus abgeleiteten geophysikalischen Variablen (Level 2), deren Projektion in ein einheitliches räumliches und zeitliches Gitter (Level 3) bis hin zu daraus abgeleiteten anwendungsrelevanten Informationen (Level 4) verdichtet werden. Diese Prozesskette beinhaltet die Schritte:

1. radiometrische Korrektur (Sensorgrauwertkalibrierung)
2. atmosphärische Korrektur (je nach Flughöhe muss die Absorption in der Atmosphäre z.B. Wasserdampf korrigiert werden)
3. geometrische Korrektur (auf Basis von Flight Attitude Daten)
4. Orthorektifizierung (orthogonale Projektion auf gängiges Koordinatensystem)

Danach erfolgt dann die eigentliche Analyse der Daten und die Erzeugung thematischer Karten hinsichtlich der Anwendungen, z.B.:

• Biomasse
• Düngestatus
• Nährstoffversorgung
• Kohlenstoffverteilung

All diese Prozess- und Darstellungsschritte (Präsentationsebene) basieren auf großen Datenmengen. Diese müssen in möglichst einheitlicher Weise gespeichert, effizient verfügbar gemacht und prozessiert werden. Die Herausforderung ist, flexibel Schnitte durch multidimensionale Datenwürfel zu schneiden oder auch auf dem gesamten mehrdimensionalen Datencube mit Algorithmen des maschinellen Lernens nach Mustern zu suchen.

Konventionell werden die Daten, die in diesen Schritten prozessiert werden,in einzelnen Files gehalten und in jedem Verarbeitungsschritt neu geladen und abgespeichert. Fortschrittlichere Datenbank-basierte Ansätze haben im Gegensatz dazu den Vorteil, dass auch effizient nach anwendungsspezifischen Signalen oder Mustern in den Zwischen- oder Endprodukten gesucht werden kann. Fernerkundungsdaten ergeben multidimensionale Datencubes, die nach unterschiedlichen Kriterien z.B. zeitlich oder nach Spektralbereich gefiltert und verschnitten werden müssen, um anwendungsrelevante Fragen zu beantworten. Relationale Datenbankmanagementsysteme sind prinzipiell geeignet, um diese Fernerkundungsdaten effizient zu speichern, wobei mit einer Repräsentation der Sensordaten in Array-Datenbanken ein effektiver Zugriff gewährleistet ist. Der große Nachteil sowohl der Datei- als auch Datenbank-basierten Vorgehensweise ist jedoch die geringe Reaktivität. Unter dem Begriff Reaktivität werden die Dimensionen Antwortbereitschaft (responsiveness), Widerstandsfähigkeit (resilience), Elastizität (elasticity) und Nachrichtenorientierung (message-driven) zusammengefasst [1]. Auf deren Basis werden aktuell verteilte, asynchrone und nicht-blockierende Architekturen insbesondere für Big Data Anwendungen umgesetzt. In vielen Big Data Szenarien für Fernerkundungsanwendungen ist eine hohe Reaktivität wünschenswert, weil dadurch ad-hoc Entscheidungen z.B. beim Precision Farming getroffen werden können und kurze Feedback-Schleifen für Echtzeitsteuerungen umgesetzt werden können. Außerdem erleichtert dies die Integration neuer Datenquellen oder zusätzlicher Verarbeitungskomponenten.

Lösungsarchitekturentwurf

Um zu reaktiven Fernerkundungsanwendungen zu kommen müssen zwei innovative Technologien kombiniert und für den Anwendungszweck Fernerkundung angepasst werden: In-Memory Datenbanken und massiv verteilte Verarbeitung.

Bei In-Memory Datenbanken wird der gesamte Datenbestand im schnellen RAM gehalten und nicht in einem langsamen Festplattenspeicher eines herkömmlichen Datenbankmanagementsystems gespeichert. Datenbankmanagementsysteme wurden ursprünglich entwickelt, um den gerade benötigten Teil der Gesamtdaten zur Verarbeitung ins RAM zu laden und sofort nach Veränderung wieder auf die Festplatte zurück zu speichern. Die Verlagerung des gesamten Datenbestands in das RAM erlaubt den Verzicht auf langsame Such- und Verarbeitungsmechanismen, die erforderlich sind, um mit der sequentiellen Datenbereitstellung umgehen zu können. Dadurch werden effizientere Verarbeitungsmodelle möglich. Konkret auf Fernerkundungsdaten angewendet bedeutet dies, dass Daten in Form von Vektoren repräsentiert werden, auf denen die Transformationsalgorithmen direkt arbeiten können. Trotzdem ist es möglich den Vorteil von Datenbanken beim Erkennen von Signalen oder Mustern zu einzusetzen.

Obwohl die Hardwareressourcen von Rechnersystemen beständig größer werden, sind speicherhungrige Big Data Anwendungen nicht ohne weiteres im RAM von Standardrechnern zu halten. Für spezielle betriebswirtschaftliche In-Memory Anwendungen werden zwar Rechner mit Speichergrößen von bis zu 12 TB verwendet, jedoch haben aktuelle Standardrechner nur ca. 0,1 % dieses RAM-Ausbaus. Alternativ kann jedoch die RAM-Speicherkapazität mehrerer Standardrechner miteinander kombiniert werden. Cloud-Computing und Parallelverarbeitung bieten dieses Potenzial für Big Data Anwendungen. Mit Hadoop existiert ein weit verbreitetes Open Source Framework für die verteilte Verarbeitung, das auch bereits erfolgreich in Fernerkundungsanwendungen eingesetzt wurde [2].

Das Open Source Framework Apache Spark kombiniert verteilte Verarbeitung aus Hadoop mit In-Memory Technologien, speziell auf Basis des Hadoop Distributed Filesystems (HDFS), mit dem eine verteilte redundante Datenhaltung möglich ist. Die Idee von HDFS ist, dass für jedes Datenobjekt erfragt werden kann, auf welchen Rechnerknoten (redundante Speicherung ist möglich) im Verbund es sich gerade befindet, so dass dann die Verarbeitung dort erfolgen kann und eine Übertragung der Daten nicht erforderlich wird.

Apache Spark ist ein Framework für die Parallelisierung von rechenintensiven Aufgaben. Im Gegensatz zu alternativen Systemen setzt Spark speziell auf In-Memory-Techniken und bietet damit eine sehr viel höhere Verarbeitungsgeschwindigkeit. Der Spark Driver auf dem Master-Knoten bricht ein Problem in kleinere Aufgaben („Tasks“) herunter, die parallelisiert ausgeführt werden können. Diese Tasks werden auf Worker Nodes verteilt. Dabei werden Tasks nach Möglichkeit dort ausgeführt, wo die erforderlichen Daten bereits vorliegen. Die Daten, auf denen die Tasks arbeiten müssen, werden in „Resilient Distributed Datasets“ (RDD) auf der Basis von HDFS über die Worker Nodes in HDFS DataNodes verteilt gespeichert. Dabei ist zu beachten, dass Dateien zwar über HDFS-Mechanismen verteilt werden, jedoch auf den HDFS DataNodes vollständig im RAM gehalten werden („In-Memory Data Sets“).

Zweck von Apache Spark SQL als Teil von Spark ist die Parallelisierung speziell von datenzentrierten In-Memory Funktionen in einem Spark-Rechencluster. Die Plangenerierung für die Verteilung von Tasks erfolgt auf dem Spark Master Node in der Driver-Komponente.

Anpassungen an Apache Spark werden jedoch aufgrund der speziellen Anwendungsanforderungen für die Datentransformation erforderlich werden. Die Sensoren sollen als Datenquellen in einem Infrastruktur-Cloud-Ansatz [6] eingebunden werden. Dafür bietet sich insbesondere der Data Distribution Service Standard an, mit dem Near-Realtime Datenintegration in verteilten Systemen in einer reaktiven Art möglich ist [7].

Umsetzung

Das Grobkonzept sieht vor, dass die reaktive Architektur für Big Data aus Fernerkundungsanwendungen auf einem Rechencluster mit OpenStack implementiert wird.

OpenStack soll Hardware-Ressourcen eines Rechnerverbunds in einer einheitlichen Weise als Cloud-Services bereitstellen. Die Zusammenhänge der Komponenten von OpenStack werden in Abb. 4 gezeigt, wobei die reaktive Architektur für Big Data aus Fernerkundungsanwendungen auf diesem System basiert: Mit der Komponente Nova werden virtuelle Maschinen mit vorgefertigten Betriebssystemkonfigurationen von Apache Spark-Knoten (ein Master Node, mehrere Worker Nodes) bereitgestellt. Die Images der virtuellen Maschinen werden mit der OpenStack-Komponente Glance im Rechencluster verwaltet, Neutron managt Sub-Netzwerke für die virtuellen Maschinen im Cluster, Keystone erledigt die Autorisierung des Zugriffs und Ceilometer überwacht die Ausführung der virtuellen Maschinen.

Fragen für die anwendungsorientierte Forschung an einer reaktiven Architektur für Big Data aus Fernerkundungsanwendungen sind:

• die Dimensionierung des erforderlichen Rechenclusters für unterschiedliche Anwendungsszenarien,
• geeignete Netzwerkarchitekturen und Kommunikationsprotokolle für die Integration von Sensoren als mobile Datenlieferanten mit dem stationären Rechencluster
• die Zusammenstellung und Konfiguration von Spark, Hadoop, HFS und OpenStack, so dass eine hohe Reaktivität erreicht wird,
• die Entwicklung von Softwarekomponenten zur Unterstützung der Integration und des Betriebs sowie
• die Anpassung von Sparks In-Memory Mechanismen an die Erfordernisse aus der Fernerkundung.

Diese Erkenntnisse können nur anhand von Anwendungsszenarien gewonnen werden, für die konkrete Architekturen auf dem Rechencluster implementiert werden. Zweckmäßigerweise sollten die Anwendungsszenarien komplex und realistisch sein und sich voneinander deutlich unterscheiden. Methodisch hat sich die Definition von groben „Szenaren“ bewährt, die einen grundsätzlichen Anwendungsbereich anhand eines Settings beschreiben. Innerhalb des Szenars werden dann konkrete Abläufe, die Vignetten, spezifiziert, die Messstellen enthalten, mit denen die Leistungsfähigkeit eines Systems und damit der zugrundeliegenden Architektur bewertet werden können. Die Messstellen sollten sich sowohl auf die Anwendungsfrage aus der operationellen Sicht der Nutzer beziehen („Measure of Effectiveness“ – MOE) als auch auf technische Parameter aus der Perspektive der Systementwickler („Mesasure of Performance“ – MOP). Anhand der experimentellen Entwicklung und Erprobung der Vignetten innerhalb der Szenare und der Auswertung der dabei erhobenen MOE und MOP können Architektureigenschaften bewertet werden.

Knackpunkt bei der letztendlichen Anwendung von Architekturen in realen Anwendungen ist jedoch die Information und Ausbildung von Entwicklern in Bezug auf die neuen Erkenntnisse über reaktive Architekturen für Big Data aus Fernerkundungsanwendungen. Dies geschieht am besten durch die Definition einer allgemeingültigen Referenzarchitektur für diesen Anwendungsbereich. Die Referenzarchitektur enthält alle als sinnvoll erkannten Elemente und deren Zusammenhänge, die in konkreten Architekturen verwendet werden können. Aus der allgemeinen Referenzarchitektur wird dann je eine Zielarchitektur für jedes spezifische System abgeleitet. Gute Referenzarchitekturen können in der Ausbildung und zum Promoten der Ansätze in der professionellen Entwickler-Community verwendet werden. Sie sollten deshalb gut dokumentiert und einfach verwendbar sein. Nützlich ist beispielsweise die Definition von Vorlagen für Modellierungswerkzeuge, aus denen leicht die Zielarchitekturen erstellt werden können.