Sechs Beine und ein Linux-Hirn

Сomentários

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