docSechs Beine und ein Linux-Hirn
download 
Denúncia Transcrição
Sechs Beine und ein Linux-Hirn
Sechs Beine und ein Linux-Hirn — Steuerung eines Industriehexapoden mit Linux — Ingenieurgemeinschaft IgH Essen Februar 2003 Dieser Text1 ist in der Zeitschrift Linux-Magazin“, Ausgabe 03/03, erschienen. ” Die Wiedergabe erfolgt mit freundlicher Genehmigung des Verlages. Der Text ist urheberrechtlich geschützt. Der Text ist urheberrechtlich geschützt. Ingenieurgemeinschaft IgH Heinz-Bäcker-Str. 34 D-45356 Essen Tel.: +49-201-619931 Fax.: +49-201-619836 E-mail: [email protected] 1 hexapod, Revision: 1.1 , Stand: Date: 2003/05/09 13:27:37 Zusammenfassung Ein Linux-System steuert eine Prüfmaschine für Wagenheber. Um die komplexen Bewegungsabläufe und Kräfteverhältnisse beim Heben eines Autos in Echtzeit nachstellen zu können, genügt ein Kernel-Modul. Gleichzeitig überwacht das LinuxSytem noch den Prüfstand und bietet weitreichende Steuermöglichkeiten über das Internet sowie webbasierte Dokumentenpräsentation. Ein Wagenheber muss handlich und preiswert sein, aber auch sicher. Deshalb treiben die Automobil-Zulieferer erheblichen Aufwand, um ihn unter allen denkbaren Belastungszuständen zu prüfen. Schwierig wird das, weil die anzuhebenden Autos manchmal noch gar nicht existieren, wenn der Wagenheber dazu entwickelt wird. Ein Prüfstand muss also das Verhalten des Autos nachbilden. Zu diesem Zweck wandert der angenommene Aufnahmepunkt des Fahrzeugs auf einer räumlichen Bahnkurve und simuliert dabei das Fahrzeuggewicht. Diese Aufgabe ist geradezu prädestiniert für einen Hexapoden. Das griechische Wort steht für einen Sechsbeiner. Das Funktionsprinzip beruht darauf, dass die sechs räumlichen Freiheitsgrade einer Bewegung, nämlich die Verschiebungen längs dreier Raumachsen und die Drehungen um drei Körperachsen durch sechs Hydraulikzylinder abgebildet werden. Diese sechs Zylinder stehen auf einem gemeinsamen Fundament und sind kopfseitig über eine Platte gekoppelt. Sie können unabhängig voneinander ein- und ausfahren und ermöglichen damit nahezu beliebige Bewegungen der Kopfplatte. Diese fährt auf und nieder, hin und her, vor und zurück und taumelt dabei nach Belieben um ihre Achsen. Dieses trickreiche Prinzip wird gern in Flugsimulatoren und auch zur hochpräzisen Steuerung von Werkzeugmaschinen verwendet. Anspruchsvoll ist jedoch die Ansteuerung eines solchen Hexapoden; im vorliegenden Fall erledigt sie ein Linux-System. Alle Steueraufgaben im engeren Sinne sind in einem Kernel-Modul ausgeführt. In der Steuertechnik existiert generell ein Trend hin zum PC. Prozessoren, Bussysteme und entsprechende I/O-Karten sind flexibel und leistungsfähig. Die PC-Architektur erlaubt außerdem den Einsatz gängiger, verbreiteter und durch massenhaften Einsatz gut getesteter Software. Obwohl Linux eigentlich für Zwecke der Datenverarbeitung konzipiert wurde, besitzt es auch für Steuerungs- und Regelungsaufgaben viele Vorteile: Der verfügbare Quellcode 1 Abbildung 1: Hexapode im Wagenheberprüfstand - sechs Hydraulikzylinder belasten den Wagenheber längs der Hubkurve ermöglicht Anpassungen an spezielle Hardware, Skalierbarkeit, gezielte Optimierungen, um etwa Latenzzeiten zu verringern, sowie tiefreichende Diagnose. Kernel-Module lassen sich unkompliziert einbinden, Linux erlaubt zudem umfangreiche Einblicke in die Kernelstrukturen zur Laufzeit. Gnu-Tools und aller anderen unix-typischen Entwicklungswerkzeuge stehen für Analyse, Test und Optimierung bereit. 2 1 Echtzeit – eine echte Herausforderung Ein System arbeitet echtzeitfähig, wenn es garantiert innerhalb einer definierten maximalen Antwortzeit auf ein Ereignis reagiert. Die Dauer dieser Antwortzeit ist naturgemäß vom Prozess abhängig, der kontrolliert werden soll. Echtzeitfähigkeit ist nicht notwendig gleichzusetzen mit Schnelligkeit! Zwischen einem Ereignis und der Antwort des Echtzeitsystems verstreicht grundsätzlich eine gewisse Zeit, die sogenannte Latenzzeit. Die Streuung der Latenzzeit bei wiederkehrenden Ereignissen wird Jitter genannt. Echtzeitverhalten ist eine notwendige Eigenschaft eines Betriebssystems für Steuerungsaufgaben. Für Linux existiert eine Reihe von Erweiterungen, die eine tatasächliche Echtzeitfähigkeit verbessern oder gewährleisten, zum Beispiel RT-Linux [1] oder RTAI [2]. Allerdings stellte sich in der vorliegenden Aufgabe zunächst die Frage, ob diese Erweiterungen für steuerungtechnische Aufgaben wirklich erforderlich sind. Der Vorteil der har” ten“ Echtzeitfähigkeit wird bei diesen Systemen durch Einschränkungen hinsichtlich der verfügbaren Software und lizenzrechtliche Probleme erkauft. Aus diesem Grunde entschieden wir uns, sehr gut beraten von Professor Quade von der Fachhochschule Niederrhein, einen Standard-Kernel zu verwenden. Als Experte für Embedded Systeme ermutigte er uns unumwunden, auf Linux zu setzen. Er sollte Recht behalten. Digitale Steuerungen und Regelungen verfügen über einen Taktgeber, der die entsprechenden Berechnungsroutinen in äquidistanten Zeitschritten aufruft. Dabei liegen die Abtastraten für die hier betrachteten Systeme zwischen 100 Hz und 10 kHz. Die weitaus überwiegende Zahl der industriellen digitalen Regelungen arbeiten mit Abtastraten in diesem Bereich. 2 Eigenschaften von Linux beim Echtzeiteinsatz Alle Berechnungen, die in Echtzeit ausgeführt werden müssen, führt ein Kernelmodul als Interruptroutine aus. Als Interruptquelle dient ein Timer, der zyklisch die Abarbeitung der Routine auslöst. Jeder PC verfügt über einen programmierbaren Timerbaustein, der zyklische Interrupts generieren kann. Multitasking-Betriebssysteme nutzen diesen Timer grundsätzlich, um zum Beispiel regelmäßig den Scheduler zum Taskwechsel aufzurufen. Die Taktfrequenz wird so gering wie möglich gehalten, damit der Anteil der Taskwechselzeit an der CPULast gering ist, aber so hoch, dass flüssiges Arbeiten mehrerer Prozesse nebeneinander möglich wird. Bei i386-kompatiblen Rechnern unter Linux hat der Timerinterrupt eine Frequenz von 100 Hz. Diese Frequenz lässt sich einfach ändern. Sie steht zentral in der Datei /usr/src/linux/include/asm-i386/param.h. Ein Auszug ist in Abbildung 2 wiedergegeben. 3 Abbildung 2: Frequenz des Timerinterrupts /* Die Frequenz des Timerinterrupts wird eingestellt in /usr/src/linux/include/asm-i386/param.h: */ #ifndef _ASMi386_PARAM_H #define _ASMi386_PARAM_H #ifndef HZ #define HZ 100 #endif <----------- hier #define EXEC_PAGESIZE 4096 #ifndef NGROUPS #define NGROUPS #endif 32 #ifndef NOGROUP #define NOGROUP #endif (-1) #define MAXHOSTNAMELEN 64 #ifdef __KERNEL__ # define CLOCKS_PER_SEC 100 #endif #endif /* max length of hostname */ /* frequency at which times() counts */ Bei einigermaßen schnellen Rechnern, (ab 500 MHz CPU-Geschwindigkeit) kann diese Rate ohne weiteres bis auf 1000 Hz erhöht werden. Die Änderung der Taktrate erfordert die Neukompilation des Kernels und aller Module. Das System fühlt“ sich bei der praktischen ” Arbeit danach nahezu unverändert an. Um den Takt für die Regelung zu nutzen, gibt es zwei Möglichkeiten, die Standard“-Timerqueue oder eine eigene Interrupt-Routine. Im einfach” sten Fall registriert man also die Regelroutine durch den Systemaufruf queue_task(&meineRegelroutine, &tq_timer); in der Standard“-Timerqueue ” des Kernels, die bei jedem Auslösen des Timer-Interrupts in dessen Bottom-Half des Timerinterrupts aufgerufen wird. Die Routine wird dann jeweils in der Bottomhalf des Timerinterrupts ausgeführt. Die Reihenfolge, in der die Queue abgearbeitet wird, lässt sich nicht beeinflussen. Daher muss man mit einem erhöhten Jitter rechnen. Reduzieren lässt sich der Jitter hingegen durch das Registrieren einer eigenen Interrupt-Routine neben der Standard-Interrupt-Routine. Eigene Messungen haben das bestätigt. 4 3 Ein Interrupt, viele Routinen Seit dem Aufkommen des PCI-Buses ist es gang und gäbe, dass sich mehrere Komponenten eine Interruptleitung teilen. Deshalb können auch mehrere Routinen für einen Interrupt registiert werden. Die einzelnen Routinen müssen dann jedoch selbständig entscheiden, ob der gerade ausgelöste Interrupt für sie bestimmt war. Dies tun sie üblicherweise indem sie ein Flag auf der eigenen“ Hardware abfragen, anhand dessen sie erkennen, ob ” der Interrupt von dort kam. Um eine zweite Interruptroutine für den Timerinterrupt zuzulassen muss, dieser das Flag SA_SHIRQ (sharable) bekommen. Hierzu ist in der Datei /usr/src/linux/arch/i386/kernel/time.c etwa in Zeile 560 die Strukturdefinition zu ändern: static struct irqaction irq0 = { timer_interrupt, SA_INTERRUPT, 0, "timer", NULL, NULL}; nach static struct irqaction irq0 = { timer_interrupt, SA_SHIRQ | SA_INTERRUPT, 0, "timer", NULL, NULL}; Diese Änderungen am Kernel sind marginal, nachteilig ist jedoch die erforderliche Neukompilierung des Kernels und aller Module. Verwendet man eine weitere Interruptquelle, zum Beispiel eine I/O-Karte mit eigenem Timer, dann kann man sogar den unmodifizierten Kernel verwenden. Die Regelroutine wird für den verwendeten Interruptkanal registriert und arbeitet dann in der Taktrate, die man komfortabel zur Laufzeit einstellen kann, indem man das Timingverhalten der gewählten Interruptquelle justiert. 4 Jittermessungen Der Jitter des Aufrufes der Interruptroutine resultiert daraus, dass der Steuerrechner üblicherweise nur über einen Prozessor verfügt, der auch die Interruptanforderungen nur nacheinander verarbeiten kann. Unter Linux ab Kernel 2.4.x werden Interrupts ununterbrechbar bearbeitet. Für die Dauer der aktuellen Interruptroutine werden also alle anderen gesperrt. Auch verfügen vielen Systemaufrufe über Interruptsperren. Dabei stellt sich die Frage nach der Dauer der längsten Sperre. Diese Zeit ist nicht a priori bestimmbar, weil sie sich durch das Eintreten mehr oder weniger stochastischer Ereignisse ergibt und deshalb mit statistischen Methoden ermittelt werden muss. Sie bestimmt letztendlich die 5 Latenzzeit und gibt eine Aussage über die Echtzeitfähigkeit des Systems. Es stehen einige Tools in Form von Patches für ältere Kernel zur Verfügung, um beim laufenden System die Dauer von Interruptsperren zu messen [3]. Im vorliegenden Fall zeichnet aber ein eigens dafür geschriebens kleines Kernelmodul den Jitter der Timerinterruptroutine auf. Tabelle 1 zeigt typische Ergebnisse nach einem mehrstündigen Testlauf auf einer 500 MHz Pentium III Maschine, die unter der Last von Benchmark-Tests ächzte. Man sieht, dass 99,8% aller Interruptanforderungen innerhalb von 42 µs nach Anforderung bearbeitet werden. Es gibt aber auch einige wenige Verzögerungen von bis zu 1 ms. Weitergehende Experimente zeigen, dass es nur zwei Quellen von langen Sperren gibt, die sich einfach vermeiden lassen. Lange Sperren von mehr als 1 ms werden vom Consolentreiber beim Wechsel der Console verursacht. Der Festplattentreiber verursacht sehr lange Sperren von über 100 µs, wenn DMA deaktiviert ist. Alle anderen relevanten Treiber wie zum Beispiel Netzwerk- und Grafikkarte, Maus und Tastatur arbeiten ihre Interrupts in sehr kurzer Zeit ab. Tabelle 1: Jittermessung eines nicht optimierten Systems Dauer der Messung: 120 min Anzahl der Interrupts: 21699717 Klasse(µs) Anzahl Prozent Summe-Prozent 2 17175311 78.7410 78.7410 4 3712813 17.0216 95.7626 10 754003 3.4568 99.2194 21 62944 0.2886 99.5079 42 65874 0.3020 99.8099 107 28255 0.1295 99.9395 214 7767 0.0356 99.9751 300 2133 0.0098 99.9848 429 2026 0.0093 99.9941 1074 1279 0.0059 100.0000 2149 0 0.0000 100.0000 4298 0 0.0000 100.0000 Vermeidet man Konsolenwechsel und optimiert den Festplattenzugriff mit hdparm dann bleibt der Jitter auf einer 500 MHz-Maschine sehr zuverlässig unter 40 µs. Abhängig vom Anwendungsfall ist dies akzeptabel, so dass die für eine Steuerung erforderlichen Echtzeitbedingungen bereits auf einem Standardkernel mit einigen wenigen Einschränkungen erfüllt sind. 6 5 Floating Point Operationen im Kernel Im Standard-Linuxkernel und auch in den Modulen ist keine einzige Floating-Point Berechnung zu finden. Dies ist in der Regel auch nicht notwendig, da keine Betriebssystemfunktionalität zwingend auf Fließkommaberechnungen angewiesen ist. In einigen wenigen Fällen, wie zum Beispiel bei der Berechnung von Zeiten wird Festkomma-Berechnung auf Integerarithmetik abgebildet. Aus diesem Grund ist die Zeit in einer Struktur kodiert: struct timeval { long tv_sec; long tv_usec; }; /* seconds */ /* microseconds */ Für Steuerungsaufgaben, bei denen wie im Falle des Hexapoden komplexe Regelungen und Koordinatentransformationen durchgeführt werden, sind jedoch Fließkommatberechnungen unverzichtbar. Allein die räumlichen Berechnungen erfordern massenhaft trigonometrische Kalkulationen. Da die gesamte Steuerungssoftware als Kernelmodul realisiert ist, müssen nun auch im Kernelspace Fließkommaberechnungen durchgeführt werden. Dabei sind zwei Punkte zu beachten. Die mathematischen Routinen müssen verfügbar sein, um auch im Kernel etwa trigonometrische Funktionen nützen zu können. Die Math-Bibliothek ist also statisch zum Kernelmodul zu linken. Dazu dient die Linker-Option LDFLAGS = -L/usr/lib -lm Der zweite Punkt betrifft das Retten der Floating-Point Register. Aus Geschwindigkeitsgründen werden bei Interruptaufrufen des Kernels die Floating-Pointregister nicht gesichert, weil sie normalerweise unverändert bleiben. Anders ist dies im Falle der Hexapodensteuerung. Hier werden alle echtzeitrelevanten Programmteile, also Regler, Koordinatentransformation und Zustandsmaschine in einer Interruptroutine ausgeführt. Da diese zyklisch die Userspace-Applikationen, also Anwenderprogramme und Daemonen unterbricht, in denen Fließkommaberechnungen durchgeführt werden, müssen in der Interruptroutine alle Floating-Point-Register gesichert und am Ende der Routine wiederhergestellt werden. Abbildung 5 zeigt den Rumpf einer Routine, die Fließkommarechnung nutzt. Floating-Point-Berechnungen im Kernel, die nicht in einer Interruptroutine, sondern im Kontext eines Userprozesses ausgeführt werden, müssen nicht gesondert behandelt werden, da die Register vom Betriebssystem schon beim Taskwechsel für den Userprozess gesichert wurden. Dies gilt beispielsweise für Berechnungen in den Read/Write-Funktionen eines Kernel-Moduls. 7 Abbildung 3: Fließpunktarithmetik im Kernel */ Quellcodeauszug nach Vorlage von P. Mantegazza ([email protected]), um im Kernel Fließpunktoperationen ausführen zu können. (Retten und Wiederherstellen der Floating-Point-Register) */ #define #define #define #define save_cr0_and_clts(x) restore_cr0(x) save_fpenv(x) restore_fpenv(x) __asm__ __asm__ __asm__ __asm__ __volatile__ __volatile__ __volatile__ __volatile__ ("movl %%cr0,%0; clts" :"=r" (x)) ("movl %0,%%cr0": :"r" (x)); ("fnsave %0" : "=m" (x)) ("frstor %0" : "=m" (x)); /* Interruptroutine */ void msr_run_interrupt(int irq, void *dev_id, struct pt_regs *regs) { /* Variablen für temporäre Sicherung der notwendigen Register */ unsigned long cr0; unsigned long linux_fpe[27]; /* Register sichern */ save_cr0_and_clts(cr0); save_fpenv(linux_fpe); /* ab hier Floating Point Berechnungen */ .... /* bis hier Floating Point Berechnungen */ /* Register wiederherstellen */ restore_fpenv(linux_fpe); restore_cr0(cr0); } 8 6 Struktur des Kernelmoduls Initialisierung 1. Initialisieren und Parametrieren der I/O-Karten 2. Registrieren der Interruptroutinen beim Betriebssystem 3. Registrieren der Kommunikationsschnittstelle beim Betriebssystem 4. Initialisierung vom proc-Filesystem 5. Registrierung von Parametern und Kanälen an der Kommunikationsschnittstelle 6. Start des Steuer- und Regelteils. Steuerung und Regelung 1. Auslesen der I/O-Karten (digital und analog) 2. Skalieren der analogen Werte 3. Dekodieren der digitalen Werte 4. Grenzwertüberwachung 5. Berechnung von Zwischengrößen 6. Ausführung der Zustandsmaschinen 7. Berechnung der Regler 8. Berechnung der Ausgabewerte (analog und digital) 9. Beschreiben der Ausgangskanäle 10. Ablegen der Messdaten in einem Kanalringpuffer Kommunikation 1. Schreiben von Parametern 2. Auslesen von Kanälen 3. Darstellung von Diagnose-Informationen 9 7 Kommunikation über ein Device Die Kommunikation mit dem Modul erfolgt über ein Character-Device, das von beliebig vielen Prozessen zum Lesen und Schreiben geöffnet werden kann und dabei diese Prozesse jeweils getrennt verwaltet. Dieses Verfahren wird ganz ähnlich für /dev/tty angewandt. Der Datenaustausch geschieht rein ascii-basiert mit einer XML-ähnlichen Syntax. Hierzu verfügt das Kernelmodul über einen vereinfachten XML-Parser und Interpreter. Der Userprozess greift über simple Standard-IO-Funktionen auf das Device-File zu, das beispielsweise den Namen /dev/msr besitzen kann. Um den Steuerrechner etwa anzuweisen, Messdaten zu senden, genügt ein echo <start_data> > /dev/msr Anschließend können die Daten endlos vom Device gelesen werden: cat /dev/msr ... <D 1.05, 3.64, 2.98> <D 1.23, 3.55, 3.07> ... Über das Device-File können entsprechend Parameter auf dem Modul gelesen und geschrieben werden, sowie das dauerhafte Senden von Messwerten gestartet und gestoppt werden. Diagnose-Informationen des Moduls werden in guter Linux-Tradition über Dateien im Verzeichnis /proc präsentiert. Variablen auf dem Modul können wahlweise als Parameter oder Kanäle registriert werden. Dies geschieht bereits im Quellcode, da die Bedeutung einer Variablen bereits bei Programmerstellung zugewiesen wird. Parameter sind überlicherweise Einstellwerte von Reglern. Kanäle sind in der Regel von der I/O-Karten erfasste Messwerte. Während Parameter sowohl gelesen als auch geschrieben werden können, können Kanäle nur gelesen werden. Da die Daten in den Kanälen im Takt der Abtastrate anfallen, verfügt jeder Kanal über einen eigenen Ringpuffer, in dem alle aufgenommenen Werte abgelegt werden. Umfang und Takt der Kanaldaten, die der Kernel über das Device-File sendet, werden zur Laufzeit per Kommando festgelegt. Dabei kann eine Untermenge aller registrierten Kanäle bei reduzierter Abtastrate zum Senden ausgewählt werden. Alle Kanäle und Parameter werden während der Initialisierung des Moduls von den Registierungsfunktionen in entsprechend verkettete Listen eingetragen, die dann der Kommunikationsschnittstelle zur Verfügung stehen. Der prinzipielle Aufbau des Kernelmoduls ist in Abbildung 4 wiedergegeben. 10 Abbildung 4: Kernelmodul – Aufbau, Funktion und Anbindung 11 8 Kommunikation via Netzwerk Nachdem es verhältnismäßig einfach ist, per Device- oder Proc-File mit dem Kernel zu kommunizieren, stellt sich die nächste Aufgabe nach der netzwerkbasierten Kommunikation mit dem Kernel. In unserem Falle war sowohl eine Fernbedienung des Prüfstandsystems als auch eine Fernbeobachtung wünschenswert. Die betreuenden Ingenieure sollten also die Möglichkeit erhalten, von ihrem Arbeitsplatz oder von zu Hause aus das Prüfgeschehen zu verfolgen und gegebenenfalls einzugreifen. Da aber nicht nur die Tester selbst, sondern auch Entwickler und Konstrukteure sind am Prüfgeschehen interessiert sind, stellt die zusätzliche Möglichkeit der netzbasierten Online-Beobachtung auch über große Strecken hinweg einen enormen Vorteil dar. Das Netzwerkkonzept ist in Abbildung 5 dargestellt. Die Kommunikation mit dem Kernelmodul erfolgt lokal über das oben beschriebene Device-File. Als Schnittstelle zum Netz dient ein kleines Perlscript, das als Daemon zwischen Netzwerk-Socket und Device-File nach dem Prinzip des Multithreaded Server arbeitet, um auch eine Vielzahl von Clients bedienen zu können. Via Netzwerk erhält der Steuerrechner vom Bedien-Rechner, der ein beliebiger PC im Netzwerk sein kann, Anweisungen zur Prüfstandsarbeit. Erhält er den Befehl zum Beginn einer Prüfung, dann zeichnet er alle relevanten Messwerte in einer ASCII-Datei auf. Nach Anforderung übermittelt er diese Daten auch online auf beliebige PC im Netz, die damit das Prüfgeschehen beobachten können. Ein Eindruck von einer derartigen Prüfstandsbeobachtung ist in Abbildung 6 wiedergegeben. Der Screenshot zeigt die Betriebsdaten in verschiedenen Diagrammen. Links ist etwa die Last auf den Wagenheber über der Hubhöhe dargestellt. Rechts daneben ist der zeitliche Verlauf mehrerer Hübe erkennbar. Unten werden mit Balkenanzeigen aktuelle Werte online präsentiert und rechts liegt ein Feld mit diversen Statusanzeigen. Nach Ablauf der Prüfung wird das Abnahmeprotokoll geschlossen und auf einen Fileserver übertragen. Idealerweise übernimmt dieses System weitere Dienste wie Backup und Zeitsynchronisation, zwei oft sträflich vernachlässigte Dienste. Arbeitet der Fileserver unter Unix, dann erfolgt der Transfer via NFS. Alternativ steht Samba zur Verfügung, das den Mount einer UNC-Share erlaubt. Das Dateisystem des Fileservers dient dem Webserver des Prüfstandsrechners als Datenquelle. Die Prüfprotokolle werden bei Anfrage dynamisch erzeugt und physikalisch auf dem Fileserver hinterlegt. Außerdem präsentiert der Webserver das Bild einer Webcam im Prüfraum. Der Steuerrechner ist bei Bedarf über Ssh zur Fernwartung und -diagnose erreichbar. Der Vorteil dieser Option führt gar zum Verzicht auf den Einsatz einer Industrie-SPS, die sich gegen internetbasierte Fernwartung in der Regel sehr widerborstig zeigt. 12 Optional lässt sich das Netzwerkskonzept auch bis hin zur Anbindung von Außenstellen oder Kunden erweitern. Prüfprotokolle werden hier auf Mirror-Servern abgelegt, während gesicherte Verbindungen via Internet die Online-Beobachtung ermöglichen. 13 Abbildung 5: Netzwerkkonzept des Prüfstands - Bedienung, Dokumentationssystem und Fernwartung 14 Abbildung 6: Screenshot der Prüfstandsfernbeobachtung – Last- und Hubverlüfe, Prüfstandsparameter und -zustände 15 9 Und der Client? Das Bedienprogramm läuft standardmäßig unter Windows und ist in Delphi geschrieben. Um das Programm flexibel an unterschiedliche Prüfaufgaben anpassen zu können, sind spezielle Delphikomponenten entwickelt worden, die selbständig über TCP/IP mit dem Steuerungsrechner die für sie bestimmten Informationen austauschen. Beispielsweise kann eine Edit-Komponente direkt einer Parametervariablen auf dem Echtzeitprozess zugeordnet werden. Die Komponente ist dann selbst dafür verantwortlich, sich den Inhalt der Variablen vom Echtzeitprozess zu holen, zu aktualisieren und zu schreiben. In ähnlicher Weise lassen sich Plotfenster unterschiedlichen Kanälen des Echtzeitprozesses zuordnen, um Signalverläufe online zu visualisieren. Aktuell wird bei der IgH an einer Portierung der Kommunikationsbibliotheken nach Kylix gearbeitet, so dass in Zukunft die Clientsoftware auch unter Linux laufen wird, soweit dies vom Kunden gewünscht wird. Abbildung 7 zeigt die Portierung des Diagnosetools Taskbrowser“ mit dem die Kanäle und Parameter eines Echzeitprozesses zu Diagnose” zwecken beobachtet, eingestellt und modifiziert werden können. Im linken Teil des Hauptfensters befindet sich eine Baumdarstellung aller verfügbaren Parameter und Kanäle. Diese können per Drag and Drop auf ein Instrument, welches sich auf der rechten Fensterseite befindet, gezogen werden. Es steht eine Sammlung verschiedener Instrumente zur Verfügung, die dynamisch auf dem Arbeitsblatt positioniert werden können. 16 Abbildung 7: Diagnosetool für das Linux-Echtzeitmodul – hier dargestellt sind Aufrufund Laufzeiten des Kernelmoduls 17 10 Fazit Linux als Betriebssystem für industrielle Steuerungsaufgaben hat mehrfach seine hervorragende Eignung unter Beweis gestellt. Selbst in nahezu unveränderter Fassung arbeitet es außerordentlich zuverlässig auch unter hoher Belastung durch umfangreiche Fließkommaberechnungen und intensiven Netztraffik inklusive webbasiertem Dokumentenmanagement. Der hohe Entwicklungsstand dieses Betriebssytems in Kombination mit dem Open-Source-Prinzip bildet die ideale Voraussetzung zur Realisierung auch komplexer Steuerungs-, Regelungs- und Dokumentationsaufgaben. Literatur [1] FSM-Labs RT-Linux Projekt: www.fsmlabs.com [2] www.aero.polimi.it/~rtai/index.html RTAI Homepage [3] Kernel Latency Patches: http://www.mvista.com/realtime/latency/results-analysis.html [4] www.hs-niederrhein.de/fb03/ Fachhochschule Niederrhein - Krefeld [5] Beck, M.: Linux-Kernelprogrammierung, Algorithmen und Strukturen der Version 2.4; Addison Wesley [6] Herold, H.: Linux- Unix- Systemprogrammierung; Addison Wesley [7] Rubini, A.: Linux-Gerätetreiber; O’Reilly 2002 A Die Autoren Wilhelm Hagemeister und Torsten Finke arbeiten als Geschäftsführer und Entwicklungsingenieure in der Ingenieurgemeinschaft IgH in Essen www.igh-essen.com an Projekten des Sondermaschinenbaus. Ein Schwerpunkt liegt im Bereich der Spezialprüftechnik. Beide Autoren verfügen über langjährige und umfangreiche Erfahrungen mit Linux. Bei Interesse an den Quelltexten möge man sich mit den Autoren in Verbindung setzen. 18
