Fachgruppe 4.4.2
Echtzeitprogrammierung
PEARL
|
Fachgruppe 4.4.2
|
News
Mitteilungen
2/97
der GI-Fachgruppe 4.4.2
Echtzeitprogrammierung
PEARL
| Herausgeber |
GI-Fachgruppe 4.4.2 Echtzeitprogrammierung PEARL |
||||||
| Sprecher |
Dr. H. Windauer Werum GmbH Erbstdorfer Str. 14 D - 21337 Lüneburg
|
||||||
| Stellvertreter |
Dr. P. Holleczek Universität Erlangen-Nürnberg Regionales Rechenzentrum Martenstraße 1 D - 91058 Erlangen
|
||||||
| Redaktion |
Prof. Dr. L. Frevert Auf dem Heuplacken 10 D - 32105 Bad Salzuflen
|
Layout | Holleczek | ||||
| Redaktionell geschlossen: 08. 11. 1997 |
| 1. | Objektorientierte Programmierung mit PEARL90 |
| 2. | Die Fachgruppe im Internet |
| 3. | Bericht "Echtzeit '97" |
| 4. | Berichte aus den Arbeitskreisen |
Das Tagungsprogramm von PEARL '97 mit den beiden Vorträgen zur objektorientierten Programmierung hat mich angeregt zu versuchen, ein objektorientiertes Programm mit PEARL90 zu schreiben. Es ging überraschend gut:
Als kleine Aufgabenstellung habe ich die Steuerung einer Straßenkreuzung gewählt, die durch Lichtsignale - durch Verkehrsampeln - gesteuert wird. Normalerweise wurde ich den Steuerzyklus als eine einzige endlos laufende Task programmieren. Man kann aber auch zwei Zyklen nehmen, die mit einem Semaphor so koordiniert werden, da nicht beide Straßen gleichzeitig Grün haben. Das Objekt mit dem Namen "kreuzung" besteht dann aus zwei Straßen "kreuzung_westost" und "kreuzung_nordsued" und einer Kreuzungsfläche "kreuzung_flaeche", jede Straße hat zwei Ampel(maste)n "_hin" und "_her", jede Ampel besteht aus der Hardware und einem Bild auf einem Sichtgerät.
Es gibt also die Objektklassen KREUZUNG, STRASSE, FLAECHE, AMPEL, AMPELHARDWARE und AMPELBILD. Sie sind als Datentypen vereinbart, welche die für die Objekte erorderlichen Daten enthalten. Die Methoden der Objekte sind als PEARL90-Prozeduren geschrieben; um sie ansprechen zu können, besitzen die Typvereinbarungen Zeiger auf diese Prozeduren. Damit diese Prozeduren auf die Daten der Objekte zugreifen können, werden ihnen die Objektnamen als Parameter vergeben.
Weil ein Objekt der Klasse AMPEL aus einem Ampelbild und der Ampelhardware besteht, enthält es Zeiger auf diese beiden Bestandteile:
TYPE AMPEL STRUCT[status BIT(3),
ampelbild REF AMPELBILD,
ampelhardware REF AMPELHARDWARE,
init REF PROC(INV REF AMPEL),
stellen REF PROC(INV REF AMPEL, AMPELSTATUS)];
Die Variable status ist eine Bitkette, die angibt, welche Signale leuchten sollen. Die Methoden "init" und "stellen" sind als Prozeduren realisiert, die schnell zu schreiben sind und Botschaften an die Hardware und das Bild senden:
AMPEL_stellen:PROC(ampel INV REF AMPEL, status AMPELSTATUS);
ampel.status:=status;
ampel.ampelhardware.steuern(ampel.ampelhardware, status);
ampel.ampelbild.male(ampel.ampelbild, status);
END;
AMPEL_init : PROC(ampel INV REF AMPEL);
ampel.ampelhardware.init(ampel.ampelhardware);
ampel.ampelbild.init(ampel.ampelbild);
END;
Die Vereinbarungen der zwei Ampeln der Straße "kreuzung_westost" lauten dann:
DCL kreuzung_westost_hin AMPEL INIT('000'B, kreuzung_westost_hin_bild,
kreuzung_westost_hin_hardware, AMPEL_init, AMPEL_stellen);
DCL kreuzung_westost_her AMPEL INIT('000'B, kreuzung_westost_her_bild,
kreuzung_westost_her_hardware, AMPEL_init, AMPEL_stellen);
Man sieht an diesen Beispielen, daß man zur Erzeugung beliebig vieler Objekte nur die INIT-Listen von Deklarationen auszufüllen braucht, wobei viele Eintragungen bei allen Objekten identisch sind. Es läge daher nahe, sich diese Aufgabe durch einen Preprozessor zu erleichtern.
Die Klassendefinition der Klasse STRASSE ist in meinem Beispielprogramm etwas
umfangreicher, weil ein Objekt dieser Klasse mehr Parameter enthält und mehr Methoden
kennt; sie soll daher nicht hier angegeben werden.
Interessant ist jedoch die Methode "blinken". Die Ampeln der beiden Straßen sollen ja
gleichzeitig und beliebig lange blinken; das Blinken unterscheidet sich daher von den
normalen Methoden, die so schnell wie möglich in der Reihenfolge ihres Anstoßes ausgeführt
werden. Deshalb besteht das Blinken aus den Methoden "blinken.init", "blinken.start",
"blinken.stop" und
"blinken.beendet". Der Ablauf des Blinkens selbst wird durch ein Objekt der Klasse ZYKLUS
bewirkt. Es enthält unter anderem eine Task, die den Blinkauftrag ausführt. Die Typvereinbarung der Klasse ZYKLUS besitzt einen Zeiger auf diese Task. Sie wird durch die Methode
ZYKLUS.start aktiviert.
TYPE ZYKLUS STRUCT[init REF PROC(REF ZYKLUS, REF STRUCT[], ! Auftraggeber
REF PROC(REF STRUCT[],REF BIT(1)), ! dessen Prozedur
REF BIT(1)), ! Steuerbit
start REF PROC(REF ZYKLUS),
stop REF PROC(REF ZYKLUS),
beendet REF PROC(REF ZYKLUS),
auftraggeber REF STRUCT[],
auftrag REF PROC(REF STRUCT[],REF BIT(1)),
auftragsteuerbit REF BIT(1),
task REF TASK,
endesema REF SEMA];
ZYKLUS_init:PROC(zyklus REF ZYKLUS,
auftraggeber REF STRUCT[],
auftrag REF PROC(REF STRUCT[],REF BIT(1)),
auftragsteuerbit REF BIT(1));
zyklus.auftraggeber:=auftraggeber;
zyklus.auftrag:=auftrag;
zyklus.auftragsteuerbit:=auftragsteuerbit;
END;
ZYKLUS_start : PROC(zyklus REF ZYKLUS );
CONT zyklus.auftragsteuerbit:='1'B;
ACTIVATE zyklus.task;
END;
ZYKLUS_stop : PROC(zyklus REF ZYKLUS);
CONT zyklus.auftragsteuerbit:='0'B;
END;
ZYKLUS_beendet : PROC(zyklus REF ZYKLUS);
REQUEST zyklus.endesema;
END;
Objekte der Klasse ZYKLUS sind polymorph: sie können für Auftraggeber aus unterschiedlichen Klassen arbeiten. Die Namen von Auftraggeber, Auftrag und Auftragsteuerbit werden dem ZYKLUS-Objekt bei seiner Initialisierung als Argumente übergeben. Der Auftrag ist im Falle des Blinkens eine Methode der Klasse STRASSE, eine Prozedur, die eine Schleife enthält, welche wiederum Botschaften an das betreffende Straßen-Objekt sendet, bzw. dessen Parameter benutzt:
STRASSE_blinken_prozedur:PROC(strasse INV REF STRASSE, steuerbit REF BIT(1));
WHILE CONT steuerbit REPEAT
AFTER strasse.blinkzeit RESUME;
strasse.gelbschalten(strasse);
AFTER strasse.blinkzeit RESUME;
strasse.ausschalten(strasse);
END;
END;
Ein Objekt der Klasse ZYKLUS enthält eine Task und einen Semaphor, die zusätzlich zur Datenstruktur deklariert werden müssen:
kreuzung_westost_blinken_zyklus_task:TASK;
kreuzung.westost.blinken.auftrag (kreuzung.westost.blinken.zyklus.auftraggeber,
kreuzung.westost.blinken.zyklus.auftragsteuerbit);
RELEASE kreuzung.westost.blinken.zyklus.sema;
END;
DCL kreuzung_westost_blinken_zyklus_sema SEMA PRESET(0);
DCL kreuzung_westost_blinken_zyklus ZYKLUS INIT(
ZYKLUS_init,
ZYKLUS_start,
ZYKLUS_stop,
ZYKLUS_beendet,
NIL, ! bekommt seinen Wert bei init-Aufruf
NIL, ! desgleichen
NIL, ! desgleichen
kreuzung_westost_blinken_task,
kreuzung_westost_blinken_zyklus_sema);
Die meisten der bisher erwähnten Objekte sind in andere Objekte eingebettet und werden nur von letzteren benutzt, sind also privat. Deshalb bedarf ihre Nutzung keiner Vorsichtsmaßnahme. Eine Ausnahme bildet das Objekt "kreuzung_flaeche" der Klasse KREUZUNGSFLAECHE: es wird von beiden Straßen der Kreuzung indirekt dadurch benutzt, da es nach dem Grünschalten der Ampeln befahren werden kann. Deshalb muß dafür gesorgt werden, daß diese Nutzung nicht durch beide Straßen gleichzeitig erfolgen kann.
Die Klasse KREUZUNGSFLAECHE hat daher neben der Methode "init" die Methoden "besorgen" und "freigeben"; "besorgen" reserviert die Kreuzungsfläche exklusiv und wartet gegebenenfalls, bis das mglich ist. Im PEARL90-Code der Methoden geschieht das selbstverständlich durch eine REQUEST-Anweisung.
Die Methode "besorgen" muß von einer Straße als Botschaft an die jeweilige Fläche (deren Name ist Argument bei der Initialisierung der Straße) gesandt werden, bevor die Ampeln grüngeschaltet werden; "freigeben" erfolgt selbstverständlich nach dem Rotschalten. Die wiederholte Ausführung des gesamten Schaltablaufes ist ein Auftrag an ein Objekt der Klasse ZYKLUS, das weiteres Teilobjekt der Straße ist.
Auf den ersten Blick erscheint das komplette objektorientierte Ampelprogramm reichlich kompliziert. Es enthält eine Vielzahl von Zeigern, von INIT-Listen mit ellenlangen Namen und von Prozeduren, die nichts weiter tun, als andere Prozeduren aufzurufen und dabei Parameter weiterzureichen. Es war jedoch unschwer zu programmieren, nachdem die Konzepte und zugehrigen Rezepte zur Namensfindung usw. entwickelt waren. Es hat nämlich eine Grundstruktur, die es ermöglicht, da es weitgehend durch einen Programmgenerator erzeugt werden könnte. Letzterer mte Objektdeklarationen anhand von Klassenvereinbarungen in PEARL90-Code umsetzen (was ich jetzt in Handarbeit getan habe). Auf diese Weise könnte man die Vorteile der objektorientierten Programmierung auch bei PEARL90 relativ mühelos genießen, ohne daß eine Spracherweiterung notwendig wäre.
Das komplette Programm ist als Entwurf kreuzung.dsg über
http://fh-bielefeld.de
erhältlich. Der Entwurf kann durch das Werkzeug proker in ein PEARL-Programm umgewandelt werden.
L. Frevert
Die Fachgruppe geht mit der Zeit. In den letzten News wurde die Präsenz der Fachgruppe 'im Web' angekündigt. Dort findet man sie mittlerweile auch wirklich unter der URL http:///www.real-time.de. Außerdem gibt es inzwischen auch eine
Einige Nutzer des Echtzeitbetriebssystems RTOS-UH haben angeregt, eine Newsgroup für Fragen zu Echtzeitanwendungen einzurichten. Diesem Wunsch sind wir jetzt nachgekommen.
In dieser Newsgroup sollen alle an Echtzeitproblemen Interessierten, nicht nur RTOS-UH Anwender/Entwickler, ein Diskussionsforum finden. Denn der Blick über den Tellerrand war und ist uns sehr wichtig.
In der Newsgroup könnte z.B. diskutiert werden:
Mitarbeiter des Institutes für Regelungstechnik werden die Newsgroup regelmäßig lesen.
Wie können Sie teilnehmen?
Die News-Group befindet sich auf unserem Server unter der Adresse
news://news.irt.uni-hannover.de
und ist unter dem Namen
hannover.uni.comp.rtos-uh
zu erreichen. Wir haben unseren News-Server erst einmal so konfiguriert, daß alle Teilnehmer mit der Endekennung ".de" teilnehmen dürfen. Falls Sie eine andere Kennung haben und teilnehmen wollen oder Probleme auftauchen, wenden Sie sich bitte an mich.
Verschiedene Rechenzentren der Fachhochschulen / Universitäten Niedersachsens spiegeln die Gruppen der Uni-Hannover. Auch wir streben eine entsprechende Spiegelung an. Näheres demnächst.
Wir freuen uns, Sie begrüßen zu dürfen.
Thomas Probol
| P.S. | Diese Newsgroup wird umso lebendiger, je mehr Menschen von ihr wissen. Bitte leiten Sie diese Nachricht entsprechend weiter. | ||||||
| P.P.S. |
Unsere WWW-Adressen haben sich geändert:
|
Thomas Probol
Institut fuer Regelungstechnik
Appelstrasse 11
30167 Hannover
0511/762-4516 (Sekretariat: -4512)
Die Echtzeit '97 fand dieses Jahr vom 9 - 11. Sept. in Wiesbaden statt. Kongreß und Messe
haben sich an die Messcomp angelagert. Das Tagungs programm wurde erheblich gestrafft:
Es wurde bewußt auf Parallelsitzungen verzichtet. Der Qualität der Vorträge hat dies sicher lich nicht geschadet. Trotzdem ist der Grundsatz gewahrt worden, alle wesentlichen Ideen und
Produkte zu präsentieren. Besonders erwähnen möchte ich hierbei, daß sich Universitäten und
Fachhochschulen rege am Kongreß programm beteiligt haben.
Bei den aktuellen Themen hat sich die Verlagerung zum System- und Software-Entwurf
fortgesetzt. Objektoriertierte Techniken stehen dabei im Vordergrund. Das Interesse an
verteilten Anwendungen und den hierfür notwendigen Implementierungstechniken hat spürbar
zugenommen. Wie bereits im letzten Jahr feststellbar, erwartet man von
den Entwicklungswerkzeugen und Methoden nicht nur eine Verbesserung
hinsichtlich der Kosten und der Funk tionalität der Anwendung,
sondern auch unter dem Schlag wort Time to Market.
Offensicht lich ist die rechtzeitige Präsenz auf dem Markt
zu einem wesentlichen (vielleicht dem wesentlichen)
Faktor gegenüber der Konkurrenz geworden. Highlights waren auch einige
Beiträge zum Thema Windows und Echtzeit. Neben einem sehr guten Überblick als
Eröffnungsvortrag stellten verschiedene Firmen ihre Konzepte für eine "Cohabitation" vor.
Unter den Neuigkeiten ist insbesondere zu erwähnen: Mikrocontroller werden web- fähig! Für
die Ferndiagnose und Fernwartung ergeben sich hierdurch zahlreiche sehr interessante
Aspekte. Über eine einheitliche Schnittstelle können Informationen nahezu beliebiger Art
abgefragt und gegebenenfalls Eingriffe in das zu überwachende System vorgenommen werden.
Man denke nur daran, welche Vielfalt von Möglichkeiten sich hierdurch z. B. für das Facility
Management ergeben. Am Mittwoch Nachmittag wurde wieder zu einer Dis kussionsrunde
eingeladen. Es drehte sich um Java, und das Thema war etwas provokant mit "Koffein für's
Marketing, Schlaftablette für Echtzeitanwendungen" umschrieben. Die Diskussion blieb
jedoch weitgehend an bekannten Positionen hängen. Wirklich aufgeweckt wurden die Zuhörer
von der zum damaligen Zeitpunkt brandneuen Mitteilung des Vertreters von SUN, daß seine
Firma Chorus Systems aufgekauft hat. Offensichtlich hat SUN zukünfig mit Echtzeit doch
mehr am Hut.
Als Gesamteindruck ergibt sich: Trotz gestiegener Qualität der Vorträge ist die Teilnehmerzahl gesunken. Da tröstet es wenig, wenn der Einbruch nicht so verheerend wie bei der
Hauptveranstaltung, der Messcomp, war. Veranstalter des Kongresses war in diesem Jahre
wieder die Elektronik-Redaktion. Die Messe hat sich an die Messcomp angelagert, wobei
Organisation und Durchführung wieder in den Händen der Network GmbH lag.
Prof. Dr. H. Rzehak
Universität der Bundeswehr München
Werner-Heisenberg-Weg 39
D - 85579 Neubiberg
Telefon und FAX: 089 / 6004-3397
E-Mail:
rz@informatik.unibw-muenchen.de
Das PEARL-User-Group-Treffen 1997 hat am Donnerstag, 22. Mai 1997, am Institut für Regelungstechnik mit 24 Teilnehmern stattgefunden. Die wichtigsten Punkte des Treffens:
PEARL90 Weiterentwicklungen:
Compiler und Laufzeitsysteme: Statusbericht und Ausblick:
RTOS-UH und PEARL auf dem PowerPC:
Neue RTOS-UH/PEARL Implementierungen:
Berichte aus den Ingenieurbüros, Entwicklungsabteilungen und Forschungsinstituten:
Der Bericht ist auch unter der URL
http://www.irt.uni-hannover.de/~lilge/pug1997.html
im WWW zu finden und steht somit auch als HTML-Datei zur Verfügung.
Torsten Lilge
Institut für Regelungstechnik
Universität Hannover
Appelstr. 11
D-30167 Hannover
Tel.: +49-511-762-4515
Fax: +49-511-762-4536
E-Mail:
lilge@irt.uni-hannover.de
http://www.irt.uni-hannover.de/~lilge/
Die Aktivitäten im vergangenen Jahr fielen gegenüber den Vorjahren vergleichsweise
bescheiden aus. Nach wie vor besteht das Angebot, Tools für PEARL abrufbar über FTP
(Host: neptun.informatik.unibw-muenchen.de) zur Verfügung zu stellen. Es wäre schön, wenn
wir hier nicht nur auf Angebote aus dem eigenen Hause zurückgreifen könnten.
Zu Informationen aus dem eigenen Hause: Wir sind dabei, unseren Pool von PEARL- PCs für
den Übungsbetrieb - derzeit 8 Arbeitsplätze - von einem gemeinsamen Server zu administrieren. Die Übersetzungsläufe sollen dann auf dem Server ausgeführt werden. Hauptsächliches Ziel ist es, den Personalaufwand zu reduzieren. Über die Erfahrungen wird zu berichten
sein.
Die Informationsverteilung über elekronische Medien ist noch nicht so recht vorangekommen.
Sicherlich habe ich dies zu wenig energisch vorangetrieben. Dies soll sich ändern. Für jede Art
von Informationsrückfluß bin ich dankbar.
Prof. Dr. H. Rzehak
Universität der Bundeswehr München
Werner-Heisenberg-Weg 39
D - 85579 Neubiberg
Telefon und FAX: 089 / 6004-3397
E-mail:
rz@informatik.unibw-muenchen.de
Durchgeführte/geplante Aktivitäten
Normung von PEARL 90
Wie bereits unter "Aktuelles" in den PEARL-News 1/97 mitgeteilt wurde unter Berücksichtigung der aus dem Kreis der FG 4.4.2 (Prof. Dr. L. Frevert, FH Bielefeld; Prof. H. Kaltenhäuser, FH Hamburg; Prof. Dr. Rainer Müller, FH Furtwangen; Prof. Dr. Rolf Müller, HWTK Leipzig und Prof. Dr. G. Thiele, Uni Bremen) eingegangenen (redaktionellen) Vorschläge (Abgleich/Bereinigung von Syntax-Angaben in Text und Anhang B; Verbesserung der Lesbarkeit/Vervollständigung semantischer Formulierungen; Vervollständigung von Aufstellungen und Tabellen; Ergänzung und Erweiterung von Beispielen; Beseitigung von Druckfehlern) die Weißdruckvorlage erarbeitet und dem NI-22 des DIN vorgelegt. Zwar konnte der ursprünglich genannte Termin für das Erscheinen wegen Überlastung des DIN nicht eingehalten werden, inzwischen liegt aber eine mündliche verbindliche Zusage für Dezember 97 (auf der 27. Sitzung des NI-22 am 6./7. Oktober 97 in Dresden) vor.
Vortrag
Auf dem IMACS-Welt-Kongreß in Berlin (24.-27. August 97) wurde PEARL90 im Rahmen eines eingeladenen Vortrags vom Sprecher des AK5 vorgestellt. Leider waren in der (gut besuchten) Sitzung im wesentlichen nur deutsche Teilnehmer, sodaß sich die Hoffnung auf stärkeres internationales Bekanntwerden auf die Proceedings stützt:
G. Thiele, H.J. Beestermöller (1997).
Problem-oriented Real-Time Programming of Embedded Systems with PEARL90.
In: A. Sydow (Hrsg.): Proc. IMACS World-Congress 1997, Berlin,
Wissenschaft und Technik Verlag, Vol.6, pp. 475-480, und Abstracts, p. 754.
Englische Version des Sprach-Reports
An der englischen Fassung des Sprachreports (Prof. Dr. W. Halang, FernUni Hagen) wurde redaktionell im Hinblick auf die begriffliche Abstimmung zur Norm mitgearbeitet. Die internationale Reaktion auf die Veröffentlichung wird mitentscheidend dafür sein, inwieweit eine vom NI-22 angeregte Initiative zur internationalen Standardisierung realistisch ist.
Deutsche Version 3.0 des Sprach-Reports
Nach Erscheinen der englischen Fassung des Sprachreports ist eine Überarbeitung der deutschen Version 2.0 geplant.
Recherche zu PEARL in der Ausbildung
Die Fortsetzung der Recherche ergab den PEARL-Einsatz in der Labor-Ausbildung an der FH Hamburg (Prof. Dr. R. Luttmann, FB Bioingenieurwesen, Produktionstechnik und Verfahrenstechnik; Dr.-Ing. K. Gollmer, Gesellschaft für Biotechnologische Forschung).
AK5 - Sitzungen
Ein außerplanmäßiges Treffen einiger AK5-Mitglieder fand am Rande der 11. FGL-Sitzung der FG 4.4.2 am 25.6.97 in Frankfurt statt. Die nächste reguläre Sitzung (7.) des AK5 findet wieder am Rande des Workshops PEARL 97 am 27.11.97, 11 Uhr, in Boppard statt.
Mitglieder
Neue Mitglieder bzw. auch die Mitarbeit von Nicht-Mitgliedern sind jederzeit willkommen.
G.Thiele
Universität Bremen, FB1/NW1
Kufsteiner Str.
28359 Bremen
Tel. (0421) 218-2442
Fax.(0421) 218-4707
E-mail:
thiele@iat.uni-bremen.de
Protokoll der "1,5." Sitzung des Arbeitskreises
| Ort: | Werum GmbH, Erbstorfer Landstr. 14, 21337 Lüneburg |
| Zeit: | Donnerstag, 25.01.1996, 10:30 bis 15:00 Uhr |
| Teilnehmer: | Herr Arlt, esd, Hannover Herr Prof. Dr. Baran, FH Hamburg Herr Griem, Werum GmbH, Lüneburg Herr Prof. Dr. Heinecke, FH Dortmund Herr Dr. Windauer, Werum GmbH, Lüneburg (zeitweilig) |
Organisatorisches
Mitarbeit im AK
GI-Empfehlung "Benutzungsschnittstellen von CAD-Systemen"
Der Sprecher stellt die GI-Empfehlung vor und verteilt Arbeitsexemplare an die Anwesenden. In der Diskussion wird festgestellt, daß diese Empfehlung in ihrem Aufbau und zum Teil auch inhaltlich als Grundlage für die Arbeit des AK dienen kann. Als wichtigste Unterschiede zum Bereich CAD werden herausgearbeitet:
Es wird entschieden, die GI-Richtlinie als Ausgangsbasis für die Arbeit des AK zu benutzen. Die Empfehlungen zur Ein-/Ausgabe werden durchgegangen und überprüft, ob sie für Echtzeitsysteme übernommen werden können.
Weitere Arbeitsplanung
Verschiedenes
Beiträge hierzu liegen nicht vor. Der Sprecher dankt der Firma Werum für die freundliche Aufnahme und Bewirtung.
| 21.10.1997 |
Prof. Dr. Andreas M. Heinecke, Sprecher des AK E-Mail: amh@compuserve.com |