Suchen

Engineering-Software

Das Plus für den Pinguin

| Redakteur:

Linux gewinnt auch in der Automatisierung immer mehr an Bedeutung. In vielen Anwendungen sind jedoch Echtzeitfähigkeiten nötig, die das System nicht von Haus aus bietet. Echtzeiterweiterungen...

Firmen zum Thema

Linux gewinnt auch in der Automatisierung immer mehr an Bedeutung. In vielen Anwendungen sind jedoch Echtzeitfähigkeiten nötig, die das System nicht von Haus aus bietet. Echtzeiterweiterungen ermöglichen die Realisierung von Linux-basierten Echtzeitlösungen, wie hier am Beispiel des SPS-Laufzeitsystems von infoteam gezeigt wird. Von großer Bedeutung ist dabei das Anwendungsdesign.Marc Pullmann*Dass Linux, wie auch die Desktop-Varianten von Windows und andere Multitasking-Betriebssysteme, zunächst nicht echtzeitfähig ist, liegt an vielerlei Gründen. Als wichtigste sind zu nennen: Die eingeschränkte Verdrängbarkeit des Kernels bei der Ausführung von Systemaufrufen, die virtuelle Speicherverwaltung (Speicherseiten können auf die Festplatte ausgelagert sein und ihre Wiedereinlagerung hat einen kaum vorhersehbaren Zeitbedarf), sowie ganz allgemein die Auslegung solcher Systeme auf Fairness und im Mittel gute Ergebnisse für alle laufenden Prozesse.Es existieren jedoch verschiedene Erweiterungen, um Linux als Basis für ein Echtzeitsystem zu verwenden. Der leistungsfähigste Ansatz ist dabei das Konzept der Interrupt Abstraction. Hier wird zwischen der Hardware und dem Linux-Kernel ein möglichst kompakter und leistungsfähiger Echtzeit-Kernel eingefügt, der die Kontrolle über die Interrupts übernimmt und ein eigenes, streng nach Prioritäten gesteuertes Scheduling durchführt. Ein bekannter Vertreter dieses Konzepts ist RTAI (Realtime Application Interface) in Verbindung mit dem Adeos-Nanokernel. RTAI entstand an der Politecnico in Mailand, ist quelloffen und kostenlos. Echtzeit-Tasks laufen bei RTAI direkt unter dem Echtzeit-Kernel und im selben Adressraum wie dieser. Der Linux-Kernel stellt den Echtzeit-Task mit der niedrigsten Priorität dar. Er selbst und alle normalen Linux-Anwendungen laufen nur im Hintergrund, also immer dann, wenn keiner der Echtzeit-Tasks ausgeführt werden muss.Die Ausführung von Echtzeit-Tasks geschieht Timer-gesteuert. RTAI bietet die Wahl zwischen einem periodischen Timing in regelmäßigen, festen Zeitabständen und einem One-Shot-Timer, der nach jeder Ausführung einer Task neu programmiert werden muss. Außerdem lassen sich ereignisgesteuerte Systeme durch die Registrierung von Echtzeit-Interrupt-Handlern realisieren. Durch die Vergabe von Prioritäten unter den Echtzeit-Tasks wird die tatsächliche Ausführungsreihenfolge bestimmt. Wenn eine höher priorisierte Task laufbereit wird (das heißt, wenn ihr Timer abgelaufen ist) verdrängt sie sofort eine bereits laufende Task mit niedrigerer Priorität.Beachten, was im Echtzeit-Task realisierbar istDie Installation von RTAI verläuft in drei Schritten: Zunächst wendet man einen Patch auf einen Standard-Linux-Kernel an, welcher darin den Adeos-Nanokernel verankert. Dann konfiguriert, übersetzt und installiert man diesen gepatchten Kernel. Schließlich erfolgen noch Konfiguration, Übersetzung und Installation der RTAI-Module selbst. Ergebnis ist ein echtzeitfähiges Linux-System, das sich wie gewohnt mit grafischer Oberfläche und allem sonstigen Komfort nutzen lässt. Derzeit unterstützte Plattformen sind x86, PowerPC, ARM, IA64 sowie der Blackfin-DSP.Nun fehlen nur noch Echtzeit-Anwendungen, um das System zu nutzen. Grundsätzlich werden solche Anwendungen als Kernel-Module programmiert und mit den dort üblichen Systemwerkzeugen gestartet und gestoppt, nämlich mit dem insmod-Befehl zum Laden sowie dem rmmod-Befehl zum Entladen. In der Praxis nutzt man hierfür ein mit RTAI geliefertes Skript, das sich gleich um das Laden aller benötigten RTAI-Module kümmern kann. Es gilt jedoch eine wichtige Einschränkung bei der Programmierung von Echtzeit-Tasks für RTAI: Es können keine Systemaufrufe benutzt werden, die vom Linux-Kernel bereitgestellt werden. Darunter fallen beispielsweise Dateioperationen und auch die Datenübertragung über Netzwerke. Funktionen der Standardbibliotheken sowie normaler C-Code sind hingegen verwendbar.Beim Entwurf einer Echtzeit-Anwendung ist daher sowohl zu beachten, welche Teile der Anwendung sich überhaupt in einer Echtzeit-Task realisieren lassen, als auch, welche Anforderungen jeweils an die zeitliche Zuverlässigkeit gestellt werden. Für Anwendungsteile, die Linux-Systemaufrufe benötigen und für solche, die keiner Echtzeitverarbeitung bedürfen, realisiert man normale User-Space-Programme, welche über echtzeitfähige Inter-Prozess-Kommunikation (IPC) an den oder die Echtzeit-Tasks angebunden werden.Ein Beispiel für die Portierung einer bestehenden Automatisierungs-Anwendung auf RTAI-Linux ist SmartPLC, das SPS-Laufzeitsystem der infoteam Software GmbH. Ihre Hauptaufgabe ist die Abarbeitung von SPS-Programmen, die im IEC 61131-Programmiersystem infoteam OpenPCS entstehen. Hauptanforderung an die Echtzeit-Umsetzung eines solchen Systems ist die garantiert rechtzeitige Ausführung der SPS-Programme, denn hier findet die Verarbeitung der äußeren Ereignisse und Bedingungen statt, aus der wiederum die Reaktion des Systems resultiert. Alle umgebenden Funktionen, die damit nicht in direktem Zusammenhang stehen, müssen niedriger priorisiert werden oder können ganz aus dem Echtzeitbereich ausgelagert werden. SmartPLC besteht aus zwei großen funktionalen Einheiten, nämlich einem Teil zur Abarbeitung der SPS-Programme (Interpreter Main Loop) und einem Teil zur Kommunikation mit dem Programmiersystem (Command Main Loop). Beide Teile laufen unter Nicht-Echtzeit-Systemen meist in einem Thread, also synchron miteinander. Dies darf in einem Echtzeitsystem nicht so sein, denn hier soll die Steuerungsaufgabe nicht durch Kommunikationsvorgänge verzögert werden können. Kontakt mit dem Programmiersystem ist ohnehin hauptsächlich nur während der Entwicklung einer SPS-Anwendung nötig. Im produktiven Einsatz läuft die Steuerung normalerweise autonom.Ein wichtiger Schritt bei der Umsetzung von SmartPLC für RTAI war daher die Parallelisierung der beiden Hauptteile. Der Kommando-Teil könnte prinzipiell auch außerhalb des Echtzeitbereichs ablaufen, da er nicht zeitkritisch ist. Die Überbrückung der relativ großen Schnittstelle zwischen Kommando- und Interpreter-Teil wäre allerdings sehr aufwendig. Daher läuft im derzeitigen Design der Kommando-Teil neben dem Interpreter-Teil als zweite Echtzeit-Task mit niedrigerer Priorität. Auf diese Weise ist gleichfalls sichergestellt, dass die Ausführung der SPS-Programme immer zuverlässig erfolgt und nicht durch andere Vorgänge beeinträchtigt wird."Kommunikationsproxy" einfügenTrotzdem benötigt auch SmartPLC für RTAI einen Programmteil, der außerhalb des Echtzeitbereichs läuft. Weiter können bestimmte Unterstützungsfunktionen wie die Programmpersistenz (die dafür sorgt, dass SPS-Programme auch nach einem Ausschalten der Steuerung oder einem Stromausfall erhalten bleiben) oder Retain-Variablen (also Variablen, deren Werte Ausschaltphasen überdauern) mit Hilfe von Dateioperationen ausimplementiert sein. Auch die Unterstützung hierfür muss außerhalb des Echtzeitbereichs geschaffen werden. Zu diesen Zwecken wurde in die Architektur der SmartPLC ein Kommunikations-Proxy eingefügt, der über Inter-Prozess-Kommunikation eine Brücke in den User Space zur Verfügung stellt. Über ihn können sowohl Netzwerkübertragungen als auch Dateioperationen vom Echtzeitteil aus angestoßen werden. Die für die Kommunikation zum Programmiersystem eingesetzte Netzwerkschicht bleibt dabei weiterhin austauschbar je nach Steuerungshardware kommen hier etwa TCP/IP, V.24 oder CAN zum Einsatz. Die Inter-Prozess-Kommunikation des Proxy ist mittels Echtzeit-Fifos (Named Pipes) und einem geeigneten Übertragungsprotokoll umgesetzt, so dass sich praktisch ein Fernaufrufmechanismus über Fifos inklusive Übergabe aller referenzierten Daten ergibt. Der Vorteil von Fifos liegt hier darin, dass auf Anwendungsseite keine Synchronisation erforderlich ist und die auftretenden variablen Nachrichtenlängen komfortabel handhabbar sind. Eine zweite Schnittstelle zwischen Echtzeitteil und User Space besteht zum Zweck der Anbindung einer grafischen Benutzeroberfläche an das SPS-Laufzeitsystem. Mittels dieser Oberfläche können Laufzeitdaten visualisiert und überwacht sowie grundlegende Steuerungsfunktionen (zum Beispiel Start, Stop und Reset) auf dem Steuerrechner selbst ausgeführt werden. Die Schnittstelle besteht aus einem Shared Memory, in den das Laufzeitsystem periodisch aktuelle Daten schreibt, während die Benutzeroberfläche diese Daten regelmäßig ausliest und grafisch darstellt. Beim Absetzen von Steuerungskommandos von der Oberfläche aus gehen die Daten den umgekehrten Weg. Falls der Zugriff durch die Oberfläche blockiert ist, arbeitet das Laufzeitsystem sofort weiter und aktualisiert die Daten erst bei einem späteren Versuch.Die Ausführung der beiden Echtzeit-Tasks des Laufzeitsystems erfolgt, basierend auf einem periodischen Timer, also in einem festen Zeitraster. Mit jedem Timer-Tick der Interpreter-Task wird ein SPS-Zyklus abgearbeitet. Ergebnis ist ein zeitgesteuertes System mit dem Vorteil gegenüber ereignisgesteuerten Systemen, dass keine Überlastung durch zu viele Ereignisse pro Zeiteinheit eintreten kann. Jedoch muss die Timer-Periode der Interpreter-Task an die konkrete SPS-Anwendung angepasst werden. Am besten wählt man sie etwas größer als die maximal mögliche Zykluszeit der Anwendung, so dass auch noch Rechenzeit für andere Tasks übrig bleibt. Die Anpassung der Timer-Periode stellt eine vertretbare Einschränkung dar. Die Anpassung an den konkreten Einzelfall ist in Echtzeitsystemen also unerlässlich. *Marc Pulmann, Mitarbeiter infoteam Software GmbH, Bubenreuth.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 174653)