Echtzeit-Android

Ähnlich wie bei Linux haben Forscher an der RWTH Aachen An­droid mit Echtzeitfähigkeiten ­ergänzt und demonstrieren die Eignung von Tablets als Steuerungsplattform.RWTH

Quelloffenheit, Unterstützung vieler Hardware-Plattformen sowie die Erweiterbarkeit durch einfach zu installierende Programm­pakete haben dem Open-Source-Betriebssystem Android zu großer Popularität verholfen, bei Benutzern wie auch unter Entwicklern. Es liegt nahe, Android auch in der Automatisierungstechnik einzusetzen. Für nicht zeitkritische Aufgaben wie Visualisierungen geschieht dies schon vereinzelt; für zeitkritische Funktionen wie Regelungen oder Überwachungen lässt sich Android bisher nicht verwenden. Der Grund: Programmausführung und Prozessverwaltung berücksichtigen keine Echtzeitanforderungen.

Mit RT-Android haben Wissenschaftler des Lehrstuhls Informatik 11 – Embedded Software – ein Derivat des Android-Betriebssystems entwickelt, das das Erstellen und Ausführen von Android-­Applikationen mit Echtzeitanforderungen auf handelsüblichen Tablets und Smartphones ermöglicht. RT-Android bleibt dabei vollständig kompatibel zu bereits existierender Android-Software sowie zu zahlreichen Drittanbieter-Komponenten.

Grundlage: ein gepatchter Linux-Kernel

Da Android auf Linux basiert, bestand der erste Schritt zu RT-Android darin, den Linux-Kernel echtzeitfähig zu machen. Dazu wurde der Open-Source-Patch RT_Preempt verwendet. Diese Modi­fikation ermöglicht eine vollständige Kernel-Unterbrechung und somit eine deterministische, prioritätsbasierte Prozessverwaltung mit für Linux definierten Echtzeit-Zuteilungsstrategien. Konkret sind das: SCHED_FIFO und SCHED_RR. Damit kann RT-Android Echtzeitprioritäten zwischen 1 und 99 innerhalb von Anwendungen vergeben. Da laufende Android-Applikationen immer in einem oder mehreren Linux Prozessen gekapselt sind, lässt sich die Priorität der Applikationskomponenten flexibel anpassen, zum Beispiel für einen separaten Hintergrundservice auf Linux-Ebene.

Der Linux-Kernel ist aber nur ein Element der Android-Architektur, der das Echtzeitverhalten beeinflusst. Die von Google speziell für Android entwickelte Dalvik Virtual Machine (DVM) bringt für die Anwendungen nicht nur eine isolierte Laufzeitumgebung, sondern auch einen Garbage Collector (GC) für die automatische Speicherverwaltung mit. Der GC stellt in der herkömmlichen Form ein unkal­kulierbares Risiko für Echtzeitprozesse dar, weil bei seiner Aktivierung alle Threads der aktuellen Applikation angehalten werden. Für RT-Android entwickelten die Aachener Informatiker daher eine nicht-blockierende, echtzeitfähige Speicherverwaltung (RT GC) und integrierten sie in die DVM von Google. ­Dadurch müssen Prozesse mit dynamischer Speicherbelegung keine unvorhergesehene Unterbrechung mehr befürchten.

In der Original-Distribution von Android wird der Lebenszyklus einer Applikation (App) typischerweise von ihrer Sichtbarkeit beziehungsweise Interaktionsmöglichkeiten mit dem Benutzer beeinflusst. Sobald eine App vollständig in den Hintergrund gerät, verliert sie aus Sicht des Betriebssystems an Wichtigkeit für den Benutzer. Daher kann sie pausiert oder gar terminiert werden. Das Applikationsframework des Standard-Android überwacht und eliminiert aus seiner Sicht ­unwichtige Prozesse, um die knappen Ressourcen des mobilen Geräts besser zu nutzen. In RT-Android hingegen kann das System laufende Echtzeitapplikationen unabhängig von ihrer Sichtbarkeit grundsätzlich nicht negativ beeinflussen. Während Hintergrundprozesse in Android auch zugunsten der längeren Akkulaufzeit unterbrochen werden können, agiert RT-Android als eine zuverlässige Ausführungsplattform für Langzeitoperationen. Selbst bei ausgeschaltetem Bildschirm garan­tiert das Applikations-Framework von RT-Android ein vorhersagbares Laufzeitverhalten. Android würde den Ruhemodus aktivieren und die einzelnen Prozessoren herunterfahren oder niedriger takten.

Latenzzeiten unter einer Millisekunde

Die Modifikationen, unter anderem RT_Preempt und RT Garbage Collector, sorgen für vorhersagbare Reaktionszeiten und reduzieren auftretende Latenzen –das sind Differenzen zwischen dem geplanten und dem tatsächlichen Ausführungszeitpunkt – von mehreren Sekunden auf unter eine Millisekunde. Umfangreiche Tests konnten das belegen.

Obwohl die Anpassungen am Android-Betriebssystem vielfältig und komplex sind, können Anwendungen diese Funktionen einfach nutzen. Bei RT-Android wurden das ursprüngliche Applikations-Framework und die APIs um neue Schnittstellen für die eingeführten Funktionalitäten erweitert. Zum Beispiel können Entwickler über die Manifest-Datei die Echtzeiteigenschaften für einzelne Appli­kationskomponenten setzen. Diese Datei ist ein Hauptbestandteil von jeder für Android entwickelten Anwendung und enthält alle für das System relevanten Informationen wie Applikationsnamen, Versionsnummer und eventuell benötigte Berechtigungen.

Organisationen wie das Open Source Auto­mation Development Lab (OSADL) in Heidelberg setzen den RT_Preempt-Patch seit Jahren in der Industrie ein, beschrän­ken sich aber auf Linux als Betriebs­system. RT-Android erweitert die Möglichkeiten von Linux-Echtzeit-Lösun­gen und öffnet die Welt der mobilen Consumer-Geräte für die Automatisierungstechnik. Auch der Wechsel auf künftige Android-Versionen fällt leicht, da die Echtzeiterweiterung lose mit dem Rest des Systems gekoppelt ist und in zusätzliche Klassen und Systemservices gekapselt wurde. Aufgrund der modularen Architektur können Systeme auf Basis von RT-Android flexibel konfiguriert und an die konkreten Anforderungen angepasst werden.

Die Soft-SPS Twistturn lässt sich in Structured Text …RWTH

RT-Android-App: Soft-SPS auf dem Tablet

Zur Demonstration des Potenzials von RT-Android entwickelte der RWTH-Lehrstuhl die App ‚Twistturn‘. Damit können Steuerungsprogramme auf einem Tablet sowohl programmiert als auch in Echtzeit ausgeführt werden. Gleichzeitig zeigt die App, dass sich ein Tablet für mehr eignet, als nur die Darstellung von Parametern und HMI-Aufgaben. Natürlich ist ein Tablet nicht die ideale Plattform für umfangreiche, code-intensive Programmiertätigkeiten, aber bei visuellen Programmiersprachen oder kleineren Modifikationen am Code bietet die Arbeit am mobilen Touchscreen durchaus Vorteile. Twistturn stellt daher eine mobile Entwicklungsumgebung für SPS-Programme zur Verfügung. Neben der Code-Eingabe bietet es Funktionen zur Verwaltung von Programm-Organisations-Einheiten und zur Hardware-Konfiguration. Das Bedienkonzept ist auf Touch-Bedienung und die Display-Größen eines Tablets ausgelegt. Zudem gibt es Features wie Syntax-Highlighting zur Orientierung im Quellcode und eine komfortable Projektverwaltung zum Arbeiten mit mehreren Dateien. Aktuell unterstützt die App die Entwicklung von SPS-Programmen in Structured Text und Function Block Diagram nach IEC 61131-3.

…oder per Function Blocks gemäß IEC 61131-3 programmieren.RWTH

Die Programme können auf dem Tablet direkt ausgeführt werden. Dazu wird der Steuerungscode auf dem Gerät kompiliert und in einem Echtzeit-Prozess von RT-Android ausgeführt. Der Echtzeit-Prozess erhält seine Daten zurzeit über einen mit dem Tablet verbundenen proprietären Feldgeräte-Adapter und gibt die berechneten Ausgangswerte dorthin zurück. Die Nutzung des Tablet-Bildschirms als HMI ist ebenso möglich. Ausgangsvariablen können als Graph dargestellt werden. Für Eingangsvariablen stehen Eingabemöglichkeiten bereit, um Parameter während des Betriebs über den Touchscreen zu modifizieren. So kann mithilfe von Twistturn auf zusätzliche Bedientableaus verzichtet werden.

SPS-App ist konkurrenzfähig

Die Evaluation des Systems mit einfachen Programmen ergab Zykluszeiten von wenigen hundert Mikrosekunden. Vergleiche mit konventionellen Steuerungen mit ähnlichen Hardwarekosten ergaben bis zu 40-mal kürzere Zykluszeiten. Diese Ergebnisse überraschen aufgrund der schnellen CPU des Testsystems (Google Nexus 10) nicht. Die Messungen belegen aber die Eignung eines mit RT-Android ausgestatteten Tablets für echtzeitkritische Steuerungsaufgaben.

Mit Twistturn kann der SPS-Code auf der Ausführungsplattform angepasst und zur weiteren Abarbeitung direkt übernommen werden. Dies ermöglicht einen kürzeren und einfacheren Entwicklungszyklus, insbesondere bei Änderungen an bestehenden Programmen. Es ist zu erwarten, dass die Bearbeitung von Pro- grammen über Touchscreen größere Bedeutung erlangt, wenn die Digital Natives, die mit Smartphone und Tablet groß geworden sind, in der Arbeitswelt der Auto­matisierungstechnik ankommen.

Schließlich macht Twistturn die SPS ­mobil: Die Steuerung muss nicht mehr notwendigerweise fest mit der Anlage verbunden sein und kann bei Bedarf von der Anlage entfernt werden, etwa um den Betrieb zu unterbinden. Bei einer draht­losen Verbindung zur Anlage ist innerhalb bestimmter Grenzen auch ein mobiler Betrieb möglich. Neue Einsatzgebiete über die einer konventionellen SPS hinaus sind damit denkbar.

Dank der Performance aktueller Tablets bleibt genügend Zeit für kurze Zykluszeiten und die Visualisierung.RWTH

Das fehlende Glied in der Kette: echtzeitorientiertes Wlan

Um die Mobilität nutzen zu können, muss auch die Kommunikation zwischen Steuerung und den Feldgeräten drahtlos und echtzeitfähig sein. Für RT-Android wurde dazu Wlan genutzt. Problematisch bei Funk-Standards wie 802.11b/g/n ist, dass keinerlei Übertragungszeiten garantiert werden. Dies könnte zur Folge haben, dass Steuerungsbefehle von Twistturn nicht innerhalb der geforderten Zeitspanne an die Peripherie gesendet werden können – beziehungsweise vom Feld zur SPS übertragen werden. Damit wären alle Bemühungen um eine echtzeitfähige Programmausführung mit RT-Android umsonst. Auch dafür wurde an der RWTH eine Lösung entwickelt. Die Übertragungszeiten werden bei Wlan durch zwei Faktoren beeinträchtigt: von der Datenlast auf der Kommunikationsverbindung und von externen Störungen.

Der erste Faktor lässt sich ohne Hardware-Modifikationen am Tablet durch Änderung des Kommunikationsprotokolls so beeinflussen, dass eine zuverlässigere und vorhersagbare kabellose Kommunikation möglich wird. Dazu reguliert der Wlan-Zugangspunkt unter anderem die Last der zu übertragenen Daten. Diese werden dazu in zwei Klassen unterteilt. Die erste Klasse kategorisiert alle Daten mit Echtzeitanforderungen, die innerhalb von vorgegebenen Zeiträumen übertragen werden müssen. In der zweiten Klasse sind alle anderen Daten enthalten. Der Zugangspunkt priorisiert und sendet die Daten dann entsprechend.

Eine zu hohe Datenlast hätte zur Folge, dass einzelne Übertragungspakete verzögert würden und somit echtzeitkritische Steuerungsbefehle unter Umständen nicht rechtzeitig vom Feldgeräte-Adapter empfangen würden. Ist die gesamte Datenlast für das Wlan zu hoch, werden niedrig priorisierte Daten verworfen. Durch eine Klassifizierung und entsprechende Priorisierung der Daten stellt der Zugangspunkt sicher, dass Daten mit Echtzeitanforderung nicht durch die sonstige Kommunikation beeinträchtigt werden.

Funkstörungen sind dagegen nicht durch das System selbst zu beeinflussen. Es ist lediglich möglich, diese Störungen zu detektieren. Sofern keine ausreichende Übertragungsqualität mehr gewährleistet werden kann, ist das System in einen sicheren Zustand zu überführen (Fail-Safe-Prinzip). In aktuellen Forschungsarbeiten im RT-Android-Projekt wird eine redundante Kommunikation über Bluetooth genutzt. Da die beiden Übertragungsstrecken unterschiedlich sensibel auf gleiche Störungen reagieren, verspricht dieser Ansatz eine deutlich höhere Robustheit gegen Störquellen im industriellen Umfeld.

(sk)