Bild 2.1 Hierarchieebenen im Automatisierungsverbund
[5]
Kurzfassung
Das Übertragungsverhalten eines SPS-Verbundes unter PROFIBUS wird durch die Einstellung der Kommunikationsparameter des Feldbussystems beeinflußt. Für den Nutzer des Verbundes bleibt das Problem, den für die jeweilige Anwendung optimalen Parametersatz zu bestimmen. Die vielfältigen Netzkonfigurationen und das laufende Anwenderprogramm in der SPS machen eine Vorhersage der optimalen Übertragungsparameter schwierig. In der Praxis werden in der Regel empfohlene Standardeinstellungen, z.B. der PROFIBUS Nutzer Organisation (PNO) verwendet, ohne das Potential zur Optimierung auszuschöpfen.
In der vorliegenden Arbeit wurde eine Applikation unter Windows auf PC erstellt, die die Übertragungsparameter nach Vorgabe eines Optimierungszieles in einer laufenden SPS-Anwendung regelt. Die Regelung erfolgt wahlweise über einen diskreten Optimierungsalgorithmus oder einen Fuzzy-Regler. Optimierungsziel ist in beiden Fällen eine Anhebung der Anzahl übertragener Datentelegramme. Zur Beurteilung der aktuellen Busreserve und des Buszustandes wird ein Fuzzy-Bewertungs-System eingesetzt.
In der heutigen Zeit der Technisierung besteht zunehmend das Problem immer komplexerer steuerungstechnischer Vorgänge. Kostengünstige und übersichtliche Lösungen setzen hierzu statt einem Zentralrechner, der alle Steuerungs- und Meßaufgaben des Prozesses übernimmt, dezentrale Module ein. Wenn man die Modularisierung geeignet vornimmt und Hierarchien einführt, spart das nicht nur Verkabelungsaufwand, sondern minimiert auch den Kommunikationsaufwand. Häufig ist es z. B. nicht notwendig, die Daten eines Sensors ständig vom Zentralrechner überwachen zu lassen. Dies ist dann die Aufgabe einer dezentralen Steuerung, die nur im Falle einer Grenzwertüberschreitung eine Meldung an den Zentralrechner weiterleitet.
Zur Kommunikation der dezentralen Steuerungen und Ein-/Ausgabegeräte hat sich in den letzten Jahren der PROFIBUS (PROcess FIeld BUS) [1] verbreitet. Der Vorteil beim PROFIBUS liegt in der europaweiten Normung, die eine weitgehende Herstellerunabhängigkeit der eingesetzten Busteilnehmer garantiert.
Bei dem PROFIBUS handelt es sich um einen seriellen Zweidrahtbus, der wie alle anderen Bussysteme eine maximale Datentransferrate besitzt. Bei komplexen Anlagen mit hohem Datenaufkommen wird diese Grenze schnell erreicht.
Der PROFIBUS stellt Busparameter bereit, mit denen der Nutzer auf das
Busverhalten Einfluß nehmen kann. Im Hause KUHNKE, wo die hier vorgestellte
Diplomarbeit [2] erstellt wurde, werden Speicher-Programmierbare-Steuerungen
(SPS) aus eigener Herstellung am PROFIBUS betrieben. Dies geschieht vorwiegend
mit den von der PROFIBUS-Nutzerorganisation empfohlenen Standardwerten. In
der vorliegenden Diplomarbeit wird eine Optimierung der Busparameter in Bezug
auf eine größere Datenübertragungsrate angestrebt. Untersuchungen
zu den Busparametern wurden mit Hilfe einer PROFIBUS Simulation [3,4] und
durch Messungen an einem Laboraufbau durchgeführt. In der Diplomarbeit
wurden ausschließlich PROFIBUS-FMS-Bussysteme berücksichtigt.
Die erstellte Software gliedert sich in folgende Tools:
Beim PROFIBUS handelt es sich um ein Kommunikationsprotokoll, das nach der Norm auf der seriellen Schnittstelle RS-485 aufsetzt. Sein Einsatzgebiet umfaßt die untersten Ebenen in der Automatisierungshierarchie, die sogenannte Zell- und Feldebene (siehe Bild 2.1).
Bild 2.1 Hierarchieebenen im Automatisierungsverbund
[5]
Hauptaufgabe ist hierbei der Informationsaustausch zwischen zum einen Sensoren
und Aktoren, die die Informationen oder Zustände eines Prozesses erfassen
bzw. verändern, und zum anderen den überlagerten Steuerungen, die
im oberen Bereich der Feldebene oder im unteren Bereich der Zellebene angesiedelt
sind. Der PROFIBUS muß unterschiedlichen Anforderungen gerecht werden.
In der Feldebene ist z. B. für Regel- und Steueraufgaben eine kurze
Reaktionszeit erwünscht. In der Zellebene werden häufig große
Datenpakete, wie z. B. neue Anwenderprogramme für die Steuerungen,
übertragen. Diese gegensätzlichen Anforderungen müssen bei
der Planung der Anlage und der Programme berücksichtigt werden.
Bild 2.2: Token passing Verfahren [1]
In einem PROFIBUS-Verbund gibt es aktive und passive Teilnehmer. Ein aktiver Teilnehmer (Master) darf, wenn er im Besitz der Zugriffsberechtigung (Token) ist, über den Bus verfügen, d.h. Nachrichten ohne externe Aufforderung aussenden, während ein passiver Teilnehmer (Slave) nur die empfangenen Nachrichten quittieren oder auf diese mit Daten antworten darf.
Das Token zirkuliert in einem logischen Ring zwischen den aktiven Teilnehmern,
wobei jeder Master seine Buszugriffszeit selbst überwacht und das Token
an den Master mit der nächst höheren Adresse weiterreicht. Der
letzte Teilnehmer sendet das Token wieder an den ersten Master (siehe Bild
2.2). Die Slaves können keine direkte Verbindung untereinander
aufbauen.
Mit den Busparametern wird der zeitliche Ablauf des PROFIBUS-Protokolls festgelegt. Der Parametersatz gilt für alle Teilnehmer des PROFIBUS-Netzwerks. Im Folgenden wird eine Auswahl der Busparameter vorgestellt.
Die Angabe der Busparameter erfolgt immer in Bit-Zeiten, d.h. es kann nur mit Hilfe der vorgesehenen Baudrate auf die Zeit umgerechnet werden:
|
Formel [2.1] |
Die Target Rotation Time TTR (Token-Soll-Umlaufzeit) ist die Zeit, die maximal verstreichen darf während das Token einmal über alle sendeberechtigten Teilnehmer gelaufen ist. Innerhalb der TTR hat jede Steuerung einmal das Zugriffsrecht auf den Bus, um mit ihren Teilnehmern zu kommunizieren. Sie stellt für zeitkritische Anwendungen sicher, in welchen maximalen Zeitabständen ein Teilnehmer angesprochen wird.
Die Slot Time TSL ist die Wartezeit, die ein Initiator (Master) maximal auf eine Rückmeldung des Responders (Slave) wartet. Läuft diese Zeit ab, wird dies als Fehler interpretiert und die letzte Nachricht wird wiederholt.
Die Station Delay Responder TSDR ist die Zeit, die vergeht vom Empfang des letzten Bits eines Telegramms bis zum ersten Bit der Antwort des Telegramms oder dem ersten Bit des Folgetelegramms, wenn es ein Dienst ohne Quittung war. Der Parameterbereich wird über zwei Angaben beeinflußt:
Der Parameter minTSDR ist die Zeit, die der Empfänger mindestens warten muß, bis er eine Antwort senden darf. Mit dieser Zeit stellt man sicher, daß auf langsame Initiatoren entsprechend gewartet wird und sie so in der Lage sind, die Rückmeldung entgegenzunehmen.
Der Parameter maxTSDR ist die Zeit, zu der der Empfänger spätestens seine Antwort an den Initiator abgesetzt haben soll. Sie stellt also die obere Grenze der Wartezeit für den Empfänger dar.
Die GAP-Update-Zeit G gibt an, nach welchem Zeitraum eine Kontrollabfrage der Teilnehmer stattfindet. Sie dient dazu, in den Adresslücken neu eingefügte Teilnehmer zu erkennen und einzubinden. Nach dem Anstoß einer GAP-Aktualisierung wird während eines Tokenhaltezyklusses mindestens eine Teilnehmeradresse überprüft. Dies wird in den folgenden Haltezyklen fortgesetzt, bis die HSA (siehe unten) erreicht ist.
Der Busparameter G ist ein Multiplikator für die TTR, gibt also an, wie oft die TTR ablaufen darf, bevor ein neues GAP-Update gestartet wird.
Die Highest Station Address HSA bestimmt die letzte Teilnehmeradresse und begrenzt die Teilnehmersuche beim GAP Update.
Die maximale Baudrate ist abhängig von den verwendeten Leitungslängen. Sie ist in den Stufungen 9.6 / 19.2 / 93.75 / 187.5 und 500 kBaud einstellbar. Bei den Versuchen dieser Arbeit wurde mit einer Baudrate von 500 kBaud gearbeitet.
Standardvorgabe für Busparameter:
Beim Betrieb des Profibusses werden folgende Standardparameter empfohlen:
Bei einer Baudrate von 500 kBaud dauert die Übertragung von einem Bit:
|
Formel [2.2] |
Mit der in Formel [2.2] berechneten Übertragungsdauer für ein Bit ergeben sich folgende Zeiten für die Standardwerte:
Die folgenden Betrachtungen beziehen sich ausschließlich auf Bussysteme mit einem Master. Der Master muß die Eingangszustände der Slaves hinreichend oft abfragen, um auch bei schnelleren Eingangsänderungen immer die aktuelle Information zu verarbeiten. Sind entsprechend viele Teilnehmer im Bussystem abzufragen und handelt es sich um schnelle Prozesse, kann es dazu kommen, daß die Eingangsdaten wegen einer Busüberlastung nicht mehr hinreichend schnell eingelesen werden können. In diesem Fall besteht die Notwendigkeit einer Optimierung der Übertragungsparameter.
Die unter 2.2 genannten Busparameter üben im wesentlichen Sicherheitsfunktionen aus. Der einzige Parameter, der eine Verbesserung des Busübertragungsverhaltens erlaubt, ist der Parameter minTSDR. Dieser ermöglicht es den Teilnehmern, schneller zu antworten.
Bild
3.1: Telegramme auf dem Bus
Das Bild 3.1 zeigt einen Zeitabschnitt aus der Busübertragung. Die Länge der einzelnen Telegramme ist fest und kann nicht beeinflußt werden. Mit konstanter Baudrate bleibt nur die Möglichkeit einer Veränderung der Pausen (Dist. Zeit) zwischen den Telegrammen über den Parameter minTSDR.
Bei einer durchschnittlichen Telegrammlänge von 16 Byte und einer Übertragung von 11 Bit pro Byte ergeben sich 176 Bit, die über den Bus übertragen werden. Dem gegenüber steht eine Pause von 500 Bit pro Telegramm. Auf dem Bus sind demzufolge wesentlich längere Pausen als Datennutzungszeiten. Dieser Zustand fordert eine Optimierung der minTSDR Zeit mit dem Ziel einer besseren Busauslastung.
Die Steuerung regelt, in Zusammenarbeit mit der PROFIBUS-Firmware, die Telegrammaufteilung so, daß alle Schreibanweisungen des Anwenderprogramms ausgeführt werden können. Die verbleibende Zeit wird für Lesevorgänge genutzt. Bei fest vorgegebenen Busparametern im PROFIBUS ist die Summe der Schreib- und Lesetelegramme konstant. Steigt die Anzahl der Schreib-Telegramme, dann nimmt folglich die Anzahl der Lesetelegramme ab. Bei einem Telegrammverhältnis von 1:1 wird die Anzahl der Schreibtelegramme von der PROFIBUS-Firmware begrenzt.
Bild 3.2: Telegrammverhältnisse abhängig
von der Belastung
In Bild 3.2 wird die Schreibhäufigkeit in Schritten von S0 bis S15 über ein Anwenderprogramm kontinuierlich erhöht. Im Gegenzug nimmt die Lesehäufigkeit ab. Ab S9 wird die Schreibanzahl begrenzt, und man muß davon ausgehen, daß nicht alle Schreibaufträge wie gewünscht übertragen werden. Auch dieser Fall stellt eine Busüberlastung dar und erfordert eine Optimierung.
Wenn man davon ausgeht, daß das Prozeßabbild schnell genug gelesen wird, ist eine optimale Busauslastung erreicht, wenn die Anzahl der Lesetelegramme leicht über denen der Schreibtelegramme liegt. Daraus ergeben sich generell zwei Optimierungsziele:
Läßt sich der Prozeßzustand nicht hinreichend schnell erfassen, muß nach einem Maximalwert der Lesetelegramme gesucht werden. Hier kann ein Standardregler (P, PI o.ä.) nicht eingesetzt werden, da der Zielwert unbekannt ist. Zur Lösung dieses Problems wurde ein diskreter mathematischer Suchalgorithmus [6] eingesetzt.
Bei Problemen mit der Schreibhäufigkeit kann ein Regelalgorithmus eingesetzt
werden, da hier eine Differenz von Schreibanzahl zu Leseanzahl explizit vorgeben
werden kann. Dieser Regler wurde als Fuzzy-PI-Regler ausgeführt.
Bild 4.3: Hardwareaufbau
An einem SPS-Verbund wird online das Telegrammaufkommen bestimmt, ausgewertet und der optimierte minTSDR Wert der Steuerung zurückgeschickt. Dies geschieht in einem Regelkreis, bei dem ein PC als Regler dient. Seine Eingangsgröße ist die Art und Höhe des Telegrammaufkommens. Die Ausgangsgröße ist der neue Busparameter.
Bei einer konstanten Busbelastung ist die Anzahl der Read-Telegramme als Optimierungskriterium geeignet. Wird auf eine maximale Anzahl von Read-Telegrammen optimiert, so steigt damit auch automatisch die Anzahl möglicher Write-Telegrammen an.
Der Hardwareaufbau ist in Bild 4.3 gezeigt.
Grundlage der Optimierung im PC ist die Information über die Art und Anzahl der Telegramme auf dem PROFIBUS im SPS-Verbund. Da die SPS diese Informationen nicht direkt zur Verfügung stellt, mußte eine Spezialversion des Monitorprogramms der SPS erstellt werden, die Zähler für die verschiedenen Telegrammarten bereit stellt.
Durch die Protokollschichten des PROFIBUS gelangen nicht alle Telegrammarten, wie z.B. die Token-Telegramme bis zum ALI, an dem der PROFIBUS-Anwender sie zählen könnte. Deshalb mußten auch Änderungen in der PROFIBUS-Firmware vorgenommen werden.
In einem Speicherbereich der SPS werden vom Monitorprogramm folgende Zähler bereitgestellt:
Das Erzeugen eines Write-Auftrags geschieht durch verändern der Zustände des Prozeßabbildes. Der ALI Task erkennt eine Änderung des Prozeßabbildes und erzeugt entsprechende Write-Telegramme. Ist die Änderungsgeschwindigkeit größer als die Übertragungshäufigkeit, so kann das ALI nur die letzte Änderung berücksichtigen.
Um alle vom SPS-Programm erzeugten Änderungen zu berücksichtigen, wurde das SPS-Programm so modifiziert, daß nach jedem Setzen eines dezentralen Ausganges das Inkrementieren eines weiteren Zählers erfolgt.
Für eine sinnvolle Auswertung ist es nötig, die Telegramme auf eine Zeitbasis zu beziehen. Deshalb wurden die Zählerstände einmal pro Sekunde abgefragt und über eine Differenzbildung zu ihrem letzten Abfragezustand der Zeitbezug hergestellt.
Es wurde eine Windows-Applikation erstellt, die mit der SPS kommunizieren kann. Dabei wurden folgende Funktionen realisiert:
Wenn ein neuer Busparametersatz an die Steuerung geschickt wurde, übernimmt sie diesen Parametersatz erst, wenn ein Reset in der Steuerung ausgelöst wurde. Da während des Resets die Steuerung das Anwenderprogramm nicht abarbeitet, muß dafür gesorgt werden, daß die Steuerung zu einem definierten Zeitpunkt zurückgesetzt wird. Hierzu wird durch die Applikation in der SPS ein Flag gesetzt, das vom SPS-Anwenderprogramm abgefragt werden kann. Das Anwenderprogramm kann nach dem Erkennen des Flags eine Funktion aufrufen, die einen kontrollierten Reset der Steuerung auslöst.
Zur Bestimmung des aktuellen Buszustands wurde eine Busbewertung auf der Basis der Fuzzy-Logik [8] erstellt (siehe Bild 4.1).
Bild 4.1: Fuzzysystem für die Busbewertung
Sie benutzt die vier Zählerstände SRDlow, Readges (Read-Telegramme), Writeges (gesendete Write-Telegramme) und Writeerz (erzeugte Write-Telegramme), um eine Aussage über den Buszustand und dessen Reserve zu liefern.
Das Modul Convert im Fuzzysystem in Bild 4.1 dient der Normierung und Vorverarbeitung der Eingangswerte. Für die Größe SRDlowrel werden die SRDlow-Telegramme auf die Summe der Datentelegramme (Read, Write und SRDlow) bezogen.
Bei einer maximalen Busbelastung werden genauso viele Read- wie Write-Telegramme übertragen. Je größer die Differenz der Read-Telegramme zu den übertragenen Write-Telegrammen ist, desto größer ist auch die Reserve (WriteReserve).
Die Überforderung des Bussystems kommt in dem Wert WriteSchlecht zum Ausdruck. Solange nicht mehr Write-Telegramme erzeugt als versendet werden, ist der Bus noch nicht überfordert. Übersteigt die Anzahl der erzeugten Write-Telegramme die der gesendeten, so ist der Bus überlastet. Je größer der Wert in WriteSchlecht, um so stärker ist der Bus überlastet.
Bild 4.2 zeigt die Fuzzyfizierung der Eingangsgrößen. Zur Bearbeitung der Fuzzy-Komponenten und zur C-Quellcode-Generierung wurde das Programm TIL-Shell [9] verwendet. An der Verteilung der Fuzzy-Sets erkennt man die Gewichtung der einzelnen Zustände.
Bild 4.2: Eingangs-Fuzzysets
Die Regelbasis ReservRegeln (s. Bild 4.3) erzeugt eine auf Leertelegramme bezogene Aussage über die Busreserve. Die Einbeziehung der nicht normierten Leertelegramme wurde gewählt, um der relativen Leertelegrammanzahl zu einer Gewichtung zu verhelfen. Vergleicht man die folgenden beiden Beispiele wird dies deutlich.
Mit einer Gesamtanzahl von 8 Datentelegrammen im ersten Beispiel, wobei hiervon 2 Leertelegramme sind, folgt ein relativer Telegrammanteil von 25%.
Bild
4.3: Regelsatz ReservRegeln
Im zweiten Beispiel sind 200 Datentelegramme auf dem Bus übertragen worden, wobei hiervon 50 Leertelegramme sind. Es folgt hier ebenfalls ein relativer Telegrammanteil von 25%, wobei aber durch die wesentlich größere Anzahl an Telegrammen eine größere Reserve als im ersten Beispiel besteht.
Die Regelbasis AuswRes (s. Bild 4.4) faßt die Reserve aus den Leertelegrammen und die Reserve aus den Write-Telegrammen zusammen und erzeugt eine Aussage über die Gesamtreserve, die in dem Bussystem vorhanden ist.
Bild
4.4: Regelsatz AuswRes
Die Regelbasis AuswBus in Bild 4.5 erzeugt aus der Reserve durch Write-Telegramme und aus der Angabe der Busüberlastung eine Aussage über den Buszustand. Dadurch, daß die Busüberlastung mit einbezogen wurde, kann bei einem schlechten Buszustand eine differenzierte Aussage darüber getroffen werden, wie schlecht er ist.
Bild
4.5: Regelsatz AuswBus
Der Optimierungsalgorithmus sucht mit variabler Schrittweite und Suchrichtung nach einem Maximalwert für Read-Telegramme:
In Bild 4.6 wird der Optimierungsvorgang an einer Funktion mit mehreren Maxima gezeigt. Offensichtlich kann der Algorithmus in einem lokalen Optimum enden. Zum Erreichen des globalen Optimums wurde ein stochastischer Suchalgorithmus [6] hinzugefügt, der nach Erkennen eines Optimums innerhalb eines Suchfensters über einen Zufallsalgorithmus nach einer Verbesserung sucht. Wird ein verbesserter Wert gefunden, dann wird an diesem Punkt der Algorithmus erneut gestartet.
Der Regelkreis des Fuzzy-PI-Reglers ist in Bild 4.7 zu sehen. Er hält die Reserve des Bussystems konstant.
Bild
4.7: Regelkreis für Fuzzy-PI
Der Aufbau des Fuzzysytems ist in Bild 4.8 dargestellt. Das Modul PI_Reg enthält einen digitalen P- und I-Regler, der einen Fuzzyregelsatz versorgt. Im Modul Begrenzung wird die Ausgangsgröße begrenzt.
Die Busbewertung und Optimierung wurde mit in die Applikation integriert. Diese bildet nun ein komplettes Optimierungs-Tool für einen SPS-Verbund unter PROFIBUS.
Bild
4.8: Fuzzysystem für PI-Regler
Die Windows-Oberfläche des Optimierungs-Tools ist in Bild 5.1 abgebildet. Sie besteht aus dem Bus-Optimierer und der Telegramm-Visualisierung zusammen. Der Bus-Optimierer stellt eine Online-Verbindung zur SPS her und führt die Optimierung durch. Über die Telegramm-Visualisierung ist das Telegrammaufkommen grafisch darstellbar.
In Bild 5.2 ist die Optimierung eines PROFIBUS-Verbundes von einem Master
und 11 Slaves dargestellt. Man erkennt, daß zu Beginn der Messung die
Anzahl der Read- und gesendeten Write-Telegramme gleich groß ist. Diese
Tatsache spricht für einen überlasteten Bus und wird durch die
größere Anzahl der erzeugten Write-Telegramme bestätigt.
Es werden bei diesem Belastungsfall ca. 50 Write-Telegramme mehr erzeugt
als übertragen werden können.
Bild 5.1: Bus-Optimierer, Telegramm-Visualisierung,
Optionen für Optimierer
Die Optimierung wurde mit Standardparametern begonnen. Der Bus-Optimierer findet nach 380 Messungen eine optimale Einstellung für minTSDR bei 80bit bzw. 160µs. Um die hundertste Messung hat der Optimierungsalgorithmus ein lokales Optimum gefunden und den stochastischen Suchalgorithmus gestartet. Erkennbar an dem unruhigen minTSDR-Verlauf.
Nach Abschluß der Optimierung werden genauso viele Write-Telegramme gesendet wie erzeugt. Durch die höhere Anzahl der Read-Telegramme gegenüber den Write-Telegrammen, hat der Bus jetzt sogar eine Reserve, die durch die hinzugekommenen Leertelegramme noch verstärkt wird. Das Anwenderprogramm kann diese Reserve durch die Steigerung der Schreibaufträge ausnutzen.
Das Übertragungsverhalten konnte bei dieser Teilnehmerkonfiguration
um 33% gesteigert werden.
Bild
5.2: Optimierung 1 Master 11 Slave
Die Applikation arbeitet nicht nur mit einem Hardwareaufbau zusammen, sondern ermöglicht auch die Zusammenarbeit mit einer PROFIBUS-Simulation auf der Basis von Petri-Netzen. Mit Hilfe der Simulation können unterschiedliche Netzkonfigurationen erstellt und anschließend mit der vorliegenden Applikation optimiert werden. Hierdurch kann bereits in der Planungsphase einer Steuerungsanlage ein geeigneter Busparametersatz gefunden werden (siehe Bild 5.3).
Das Modul PbMaster simuliert eine KUAX 680I. In dem Modul PbMaster wird eine KUAX 680S nachgebildet.Das eigentliche PROFIBUS-Kabel wird durch das Modul Busline imitiert. Mit dem Modul BusMonitor werden alle Bustelegramme protokolliert und über ExecutionTime kann die Laufzeit eines Telegramms bestimmt werden.
Bild 5.3: PROFIBUS-Simulation auf Basis von
Petrinetzen
Personenregister
Dipl.-Ing. Claus Hanelt, FH Lübeck, FB Elektrotechnik
Privat : Tel/Fax: 040/701 22 73,
eMail:
claus.hanelt@t-online.de
Prof. Dr. H. Hochhaus, FH Lübeck, FB Elektrotechnik
Tel: 0451/500 5060, Fax: 04321/97 96 41,
eMail:
hochhaus@fh-lübeck.de
Dr. M. Jotter, Kuhnke GmbH, Malente
Tel: 04523/402-272, Fax: -247, eMail:
jotter@kuhnke.cls.de
Dipl.-Ing. G. Marschall, Universität der Bundeswehr
Hamburg
Tel: 040/6541-3393, Fax: -2822,
eMail:
georg.marschall@unibw-hamburg.de
|
Claus Hanelt's Homepage |
|
mailto:claus.hanelt@t-online.de |
