Fachgruppe 4.4.2
Echtzeitprogrammierung
PEARL
|
Fachgruppe 4.4.2
|
News
Mitteilungen
1/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: 27. 06. 1997 |
| 1. | Nachlese zu PEARL'96 |
| 2. | Entwicklung der Fachgruppe '96/'97 |
| 3. | Zaubereien mit Zeigern |
| 4. | Akuelles (PEARL als Norm, die Fachgruppe im Web) |
Auch im vergangenen Jahr fand der Workshop über Realzeitsysteme wieder Ende November in Boppard statt. Wetter und Straßenverhältnisse waren dieses Mal so schlecht, daß einer der Autoren es für ratsam hielt, sich den Abstecher nach Boppard zu ersparen. Sein Vortrag allerdings ist mit den anderen zehn wieder in der Reihe "Informatik aktuell" des Springer Verlages mit P. Holleczek als Herausgeber erschienen. Die Teilnehmerzahl war - entgegen dem allgemeinen Trend - in diesem Jahr mit 54 sogar noch um etwa 20 % höher als im Vorjahr, so daß sich die Tagung auch heuer finanziell selbst trug.
Die erste Sitzung am 28. 11. 96 befaßte sich mit Betriebssystem-Aspekten. B. Wolter (IRT, Uni Hannover, mit W. Gerth) berichtete in "PowerPEARL auf einem transferassemblierten Echtzeitbetriebssystem zur Steuerung schneller Maschinen" über die Implementierung des RTOS/UH-PEARL auf dem PowerPC-Prozessor. Das ursprünglich für die 68k-CISC-Prozessoren geschriebene Betriebssystem hat einen Umfang von reichlich 200000 Assembler-Anweisungen. Da eine manuelle Kodierung im Code des RISC-Prozessors zu viel Arbeitszeit verschlungen hätte, wurde ein Transfer-Assembler für die Portierung entwickelt; auf diese Weise konnte das bewährte Betriebssystem ohne Einschleppen von Fehlern auf den neuen Prozessor portiert werden. Den gezeigten Tabellen war zu entnehmen, daß das System auf einem MPC604(100 MHZ) sehr effizient läuft und einem 68040(25 MHZ)-System in der Reaktionszeit auf Interrupts mit 7 gegenüber 33 Mikrosekunden deutlich überlegen ist.
Der zweite Vortrag "Betriebssystem-Voraussetzungen für die Integration von Prozeßführungs-, SPS- und B&B-Aufgaben in Einprozessor-Applikationen" handelte von einem Dilemma: für ein PC-Betriebssystem wie Windows gibt es eine standardisierte Oberfläche für Graphik und Bedienung und viel preiswerte Software, aber es hat nicht die für Prozeßsteuerungsaufgaben notwendige Echtzeitfähigkeit und Stabilität. Ein Realzeitbetriebssystem (RMOS) hat zwar letztere, bietet jedoch nicht den erstgenannten Vorteil. Deshalb werden häufig zwei komplette selbständige Systeme für die Mensch-Maschine-Schnittstelle bzw. für Steuerung und Regelung eingesetzt. M. Wrobel (Siemens Fürth) zeigte, wie man eine Symbiose beider Betriebssysteme und zusätzliche Funktionalität einer speicherprogrammierbaren Steuerung (SPS) auf einem einzigen Industrie-PC erreichen kann, wobei Abstürze von Windows die Prozeßsteuerung nicht beeinträchtigen können.
Die wachsende Zahl der Mikrocontroller in Kraftfahrzeugen hat dazu geführt, daß führende Firmen der Automobil- und Zulieferindustrie nach anfänglichem Wildwuchs einen gemeinsamen Standard für Software-Schnittstellen auf Steuergeräten in Kfz definiert haben. J. Spohr (ATM Computer Konstanz) stellte in "OSEK-Standardschnittstellen für die Elektronik im Kraftfahrzeug" diese Schnittstellen für Betriebssystem, Kommunikation und Netzwerkmanagement in ihren wesentliche Zügen vor und berichtete über erste Implementationserfahrungen.
Nach der pünktlichen Kaffeepause - die Grenzen für Vortrags- und Diskussionszeiten wurden immer vorbildlich eingehalten - sollte es um Anwendungen gehen. H. J. Beestermöller (Uni Bremen, mit G. Thiele) erläuterte in "Wirtschaftliche Fehlertoleranz in Funktionsblock-konfigurierbaren Feldstationen", daß Fehlertoleranz in verteilten Feldstation-Systemen nicht nur durch Hardware-Redundanz, sondern - insbesondere gegenüber temporärer Überlast - wirtschaftlicher auch durch zeitweisen Lastabwurf bzw. Rekonfiguration erreicht werden kann. Als Beispiel diente die "PEARL-SPS", bei der die Anwendungsprogrammierung durch Konfigurierung von Funktionsblöcken erfolgt, die in PEARL90 programmiert sind.
Auch die nächste Anwendung hatte PEARL als Grundlage. Th. Eymann (Uni GH Essen, mit M. Polifke, E. Schmachtenberg und R. Tracht) berichtete in "Automatisierte Dosierung von metallischen Legierungen mittels kontinuierlich fördernder Pumpen" über die Automatisierung der Kernherstellung für Spritzgießen von Kunststoffteilen mit verlorenem Kern. Dabei hatte sich gezeigt, daß sich die für kleine Serien notwendige Flexibilität nicht mit einer speicherprogrammierbaren Steuerung erreichen ließ; statt dessen wurde ein Industrie-PC eingesetzt, der in PEARL programmiert wurde.
Die letzte Sitzung des Tages stand unter der Überschrift "Sprachentwicklung". In meinem eigenen Beitrag "PEARL90 in der Lehre -Erfahrungsbericht" legte ich daher den Schwerpunkt weniger auf die guten Erfahrungen mit PEARL90, wie sie im Tagungsband geschildert sind, sondern auf die Beobachtung, daß es den meisten Programmierern und Sprachentwicklern anscheinend mehr Spaß macht, Fehler mühsam erst im Test zu entdecken und zu beseitigen, anstatt zu verlangen, daß Irrtümer möglichst schon bei der Kompilation gemeldet werden. Letzteres erfordert bekanntlich, daß Sachverhalte in Programmen redundant formuliert werden (können). Das wiederum führt selbstverständlich zu etwas mehr Schreibarbeit bei der Kodierung, erspart jedoch erfahrungsgemäß sehr viel höhere Testzeiten.
Die Sitzung endete mit Berichten über die Arbeitskreise. Besonderes Interesse fand der Stand der Normung von PEARL90. Eine gemeinsame Sitzung der GI-Fachgruppen 4.4.1 und 4.4.2 schloß sich an, und dann traf man sich traditionsgemäß zum Weingenuß bei "Opa und Oma".
Der Freitag begann mit "Zur Unterstützung der Vorhersehbarkeit von Programmausführungszeiten in PEARL", vorgetragen von W. A. Halang (FernUni Hagen, mit D.Verber und M Colnaric). Er stellte dar, wie in eingebetteten Echtzeit-Systemen völlig deterministisches Zeitverhalten erreicht werden kann: durch eine spezielle Rechnerarchitektur mit einem dedizierten Betriebssystem-Prozessor und Task-Prozessoren, die voraussagbare Befehls-Ausführungszeiten haben, und durch ein abgemagertes PEARL, bei dem Code-Laufzeiten durch einen speziellen Kompilierer berechnet werden können. Bei modernen RISC-Prozessoren und Transputern sind Befehlsausführungszeiten nicht vorhersagbar, weshalb sie für den eben geschilderten Zweck untauglich sind. In Fortsetzung der Arbeiten soll übrigens PEARL auch als Spezifikationssprache für die Hardware eingesetzt werden.
Ging es eben um die Möglichkeit der Vorausberechnung von Ausführungszeiten, so handelte der nächste Beitrag "Ein Verfahren zum Erwerb und zur Bereitstellung von Betriebserfahrungen", von B. Bousoffara (und P. Elzer, TU Clausthal) darüber, wie neu gewonnene Betriebserfahrungen bei der Bedienung komplexer Systeme sofort in einer Wissensbasis gespeichert und damit dem Vergessen entrissen und auch anderen Bedienern zugänglich gemacht werden können, ohne daß es eines Wissensingenieurs bedarf.
Auch im nächsten Vortrag "Echtzeit-Expertensystem-Shell mit Simulatorkopplung" von R. Müller (und A. Kroll, J. Pietsch, HTWK Leipzig) spielte ein Expertensystem die Hauptrolle: es wurde mit einem Simulationssystem gekoppelt, um ersterem Prognosedaten zur Verfügung zu stellen und damit die Möglichkeit zu gewinnen, Störungen frühzeitig zu erkennen. Ziel der Arbeit war, den Studenten zu zeigen, wie man mit Expertensystemen umgeht.
In der letzten Sitzung über Perspektiven benutzte K. Mangold (ATM Computer Konstanz) in "Zuviel Elektronik verdirbt den Brei - Embedded Systems aus Nutzersicht" seine Betriebserfahrungen mit einem mikroprozessorgesteuerten Herd, um grundsätzliche Überlegungen zu eingebetteten Systemen darzubieten. Seine Definition für Benutzerfreundlichkeit soll hier nicht unterschlagen werden: "Trotz aller Probleme soll der Benutzer zu seinem System freundlich sein!" Kurz, es wurden ernste Sachverhalte sehr eingänglich behandelt.
Zum nächsten Beitrag "Zum patentrechtlichen Schutz von Software" war der Autor H. Springorum (Mönchengladbach) verhindert (im Tagungsband gedruckt), so daß die Tagung programmgemäß mit der Übersicht "Java & Echtzeitsysteme?" von U. Rastorfer (mit J. Kleinöder, Uni Erlangen-Nürnberg) endete. Besonderes interessant für einen Workshop über Echtzeitsysteme waren dabei die inzwischen vorgeschlagenen Spracherweiterungen für Echtzeit-Anwendungen.
Das letzte Ergebnis der Tagung bestand darin, daß beschlossen wurde, sich angesichts des neuerlichen Erfolges am 27./28. 11. 1997 wieder in Boppard zu treffen.
L. Frevert
Während der Mitgliederversammlung anläßlich des PEARL Workshops in Boppard stellte ich den Stand unserer Fachgruppe dar: Die Fachgruppe hat derzeit 111 Mitglieder, davon gehören 31 nicht der GI an. Die finanzielle Situation stellt sich wie folgt dar:
a) Verfügungsrahmen aus Tagungsüberschüssen
| Stand 1.1.1996 | DM | 2.734,91 |
| Zugang PEARL'95 | DM | 1.459,70 |
| Abgang Echtzeit'96 | DM | 1.545,-- |
| ---------- | ||
| Stand 1.1.1997 | DM | 2.649,61 |
b) Beitragskonto
| Stand 1.1.1996 | DM | 19.431,45 |
| Zahlungseingänge 1996 | DM | 2.719,84 |
| Spendeneingänge 1996 | DM | 630,-- |
| Ausgaben 1996 | DM | 8.455,05 |
| ----------- | ||
| Stand 1.1.1997 | DM | 14.326,24 |
Die Ausgaben entstanden im wesentlichen durch die englische Übersetzung des PEARL-Sprachreports (DM 6.400,--), Reisekostenzuschüsse für Treffen des AK 5 mit Vertretern des DIN/NI und Porto für die Verschickung der PEARL News.
Im November 1996 waren mir der Ausgabenumfang und die Höhe des Spendeneingangs 1996 noch nicht bekannt. Deshalb ging der Haushaltsplan für 1997 noch von vorsichtigeren Schätzungen aus:
Haushaltsplan für 1997
| Stand 1.1.1196 voraussichtlich | DM | 12.000 | |||
| Einnahmen | |||||
| DM | 2.900 | ||||
| DM | 500 | ||||
| ---------- | |||||
| DM | 3.400 | DM | 3.400 | ||
| Ausgaben | |||||
| DM | 1.500 | ||||
| DM | 750 | ||||
| DM | 750 | ||||
| DM | 2.000 | ||||
| DM | 2.000 | ||||
| ---------- | |||||
| DM | 7.000 | DM | 7.000 | ||
| Stand 31.12.1997 voraussichtlich | DM | 8.400 | |||
Nach heutigem Wissen (12.06.1997) wird der Stand des
Beitragskontos am Ende diese Jahres
ca. DM 10.700,- betragen.
Die genauere Entwicklung in 1997 und den Haushaltsplan
1998 werden wir anläßlich der
Mitgliederversammlung in Boppard besprechen.
Hans Windauer
Dynamische Beschaffung von Speicherplatz als lokale Variable von Prozeduren.
In normalen Programmiersprachen ist es zumindest sehr schlechter Stil, mit einem Zeiger, der außerhalb einer Prozedur oder eines Blockes deklariert worden ist, auf ein Objekt innerhalb der Prozedur zu zeigen. Wenn nämlich das Programm im Laufe seiner Abarbeitung den betreffenden Block verlassen hat, wird der für die blocklokale Variable benutzte Platz im Speicher wieder freigegeben, der Zeiger zeigt sozusagen ins Leere und ist ein "dangling pointer".
Anders in PEARL90. Dort kann sich eine Task sehr lange in einer Prozedur aufhalten, und es kann durchaus sinnvoll sein, während dieser Zeit von außen auf eine Variable innerhalb der Prozedur zu zeigen. Das folgende Beispiel macht das deutlich:
In PEARL-Anwendungen kann es passieren, daß eine nicht zeitkritische Task eine Störung meldet (z. B., daß ein Drucker kein Papier mehr hat) und dann darauf wartet, daß der Fehler behoben wird. Danach sollte sie durch Quittierung der Störung benachrichtigt werden, daß sie weiterlaufen kann.
In Fällen, wo mehrere derartige Störungen gleichzeitig anliegen, kann es notwendig sein, sie in anderer Reihenfolge zu beseitigen als sie gemeldet worden sind, so daß z. B. die Task mit der zeitlich letzten Störung als erste die Quittierung erhält und fortgesetzt wird.
Es ist natürlich wünschenswert, eine derartige Strategie nicht individuell für jede einzelne Task, sondern durch eine entsprechende Prozedur allgemeingültig zu verwirklichen. Die Tasks sollen ihren Fehler melden und dann innerhalb der Prozedur in einen Wartezustand gehen. In der Prozedur halten sich dann mehrere Tasks gleichzeitig auf, was ja in PEARL durchaus erlaubt ist. Sie sollen erst weiterlaufen und die Prozedur verlassen, nachdem die von ihnen gemachte Meldung nach Fehlerbeseitigung quittiert worden ist.
Dabei gab es im "alten" PEARL jedoch eine Schwierigkeit: Weil innerhalb einer Prozedur nicht festgestellt werden konnte, von welcher Task sie aufgerufen worden war, waren die Tasks innerhalb einer Prozedur sozusagen anonym; deshalb bestand die einzige Möglichkeit, eine der in der Prozedur wartenden Tasks fortzusetzen daraus, daß bei Quittierung einer Meldung alle Tasks prüfen mußten, ob es sich um ihre eigene Meldung handelte; die eine Task, bei der das zutraf, konnte dann weiterlaufen, während die anderen sich wieder in den Wartezustand begeben mußten. Diese Strategie ließ sich zwar mit drei Semaphoren und einigen Merkvariablen realisieren, war jedoch nicht leicht zu programmieren.
In PEARL90 kann der Name bzw. die Adresse einer Task mittels der Einbaufunkton TASK ermittelt werden. Deshalb kann jetzt eine Task diese ihre Adresse zusätzlich zu ihrer Meldung in eine Liste schreiben und sich selbst mit SUSPEND suspendieren; beim Quittieren einer Meldung nach erfolgter Fehlerbehebung kann dann die Meldungsliste nach dieser Meldung durchsucht, die zugehörige Adresse gelesen und die Task mit CONTINUE Adresse fortgesetzt werden. Als Pseudocode formuliert lautet die Prozedur zur Bearbeitung einer Meldung:
Die Prozedur zum Quittieren einer Meldung lautet dann:
In PEARL gibt es bekanntlich innerhalb der Sprache keine direkte Möglichkeit, sich Speicher dynamisch zu verschaffen wie z. B. in Pascal mit NEW. Deshalb besteht bei der eben beschriebenen Strategie auf den ersten Blick die Notwendigkeit, für die Meldungen samt der zugeordneten Adressen ein Feld zu deklarieren, das so lang ist wie die Maximalzahl der möglicherweise gleichzeitig anstehenden Meldungen.
Indirekt kann man sich jedoch auch in PEARL Speicherplatz dynamisch beschaffen: jede Prozedur, die auf Modulebene deklariert ist, ist in PEARL90 reentrant-fähig; das heißt, es können sich mehrere Tasks gleichzeitig in ihr aufhalten. Dazu muß das System die Parameter der Prozedur und sämtliche lokal deklarierten Variablen für jede Task neu anlegen, welche die Prozedur aufruft. Wenn sich also fünf Tasks gleichzeitig innerhalb der selben Prozedur aufhalten, ist eine lokale Variable in Wirklichkeit fünfmal vorhanden.
Für die oben beschriebene Strategie braucht man deshalb nur in der Fehlermeldungs-Prozedur eine lokale Variable zu deklarieren, die die jeweilige Meldung und die zugehörige Task-Adresse aufnehmen kann und Platz für Zeiger enthält. Diese lokale Variable wird dann in eine Liste verkettet, deren Anker auf Modulebene deklariert ist. Dadurch ist diese Liste automatisch immer genauso lang, wie sich Tasks in der Prozedur aufhalten, das heißt, sich mit SUSPEND in den Wartezustand begeben haben.
Beim Quittieren einer Meldung wird dann diese verkettete Liste durchsucht, die zur Meldung gehörende Taskadresse ermittelt, das Listenelement (die prozedurlokale Variable) ausgekettet und die Task mit CONTINUE fortgesetzt. Da das Ausketten geschieht, bevor die betreffende Task die Prozedur verläßt, gibt es auch keine Zeiger, die "ins Leere" zeigen.
Die Meldungsliste besteht so aus prozedurlokalen Elementen, die mit einem modulglobalen Anker verkettet sind. Da jede Task, die die Prozedur aufruft, ihre Auflage des Elementes in die allgemeine Meldungsliste einketten muß, stellen diese Zugriffe (und das Durchsuchen und Ausketten beim Quittieren) kritische Abschnitte dar, die mittels Semaphor oder Bolt koordiniert werden müssen.
Bei der Verwendung von Zeigern ist häufig die Fehlersuche dadurch schwierig, daß kaum festgestellt werden kann, wohin ein fehlerhaft gesetzter Zeiger eigentlich zeigt: das "alte PEARL" bot dazu nur die Möglichkeit, mit Vergleichen wie IF zeiger IS NIL oder IF zeiger IS variable zu arbeiten oder nur indirekt Aufschluß zu gewinnen, indem der Inhalt der Variablen ausgegeben wurde, auf die der Zeiger zeigt.
PEARL90 ermöglicht durch die Einführung von Zeigern (REF STRUCT[]), die nicht an einen bestimmten Datentyp gebunden sind, die Ausgabe eines Zeigerinhaltes (einer Variablenadresse) als FIXED(31)-Zahl. Im Programmbeispiel werden der Prozedur zeigerwertausgabe ein erläuternder Text und der Inhalt des Zeigers iRGendeinzeiger übergeben; letzterer ist nicht typgebunden.
In der Prozedur sind zwei Datentypen vereinbart, die genau gleich lang sind, aber einmal einen Zeiger und das andere Mal eine FIXED(31)-Zahl enthalten. Zu Sicherheit werden zwei Variablen dieser Typen vereinbart, um überprüfen zu können, ob sie wirklich gleiche lang sind. Dann wird der Zeiger-Eingabeparameter in diejenige Variable zugewiesen, die einen Zeiger enthalten kann. Mit Hilfe des Zeigers aLLeszeiger wird dann auch der Zeiger fIXedzeiger auf diese Variable eingestellt und nach diesem Betrug der Zeigerinhalt als FIXED-Zahl ausgegeben.
Beim Aufruf der Prozedur können dann beliebige Zeigerinhalte bzw. Objektnamen, insbesondere auch die Namen von Prozeduren und Tasks usw., an die Prozedur zeigerwertausgabe übergeben werden, um die (relativen) Adressen auf Maschinenebene auszugeben. Bei Prozedur- und Tasknamen sind die Objekte, auf die sie sich beziehen, Konstante; deshalb wurde der formale Parameter iRGendeinzeiger als konstanter Zeiger auf ein konstantes Objekt beliebigen Typs vereinbart.
zeigerwertausgabe : PROC(text CHAR(30),
iRGendeinzeiger INV REF INV STRUCT[]);
TYPE REFSTRUKTUR STRUCT[zEIger REF INV STRUCT[]];
TYPE FIXEDSTRUKTUR STRUCT[zahl INV FIXED(31)];
DCL fixedstruktur FIXEDSTRUKTUR; ! nur zur Laengenpruefung
DCL refstruktur REFSTRUKTUR;
DCL aLLeszeiger REF STRUCT[] INIT(refstruktur);
DCL fIXedzeiger REF FIXEDSTRUKTUR;
IF SIZEOF fixedstruktur /= SIZEOF refstruktur THEN
PUT 'refstruktur und fixedstruktur sind ungleich lang'
TO display BY A,SKIP;
FIN;
refstruktur.zEIger:=iRGendeinzeiger;
fIXedzeiger:=aLLeszeiger;
PUT text,fIXedzeiger.zahl TO display BY A,F(12),SKIP;
END;
|
L. Frevert
PEARL '90 als Norm
Nachdem der Gelbdruck der PEARL 90 -Norm seit Anfang Oktober 1996 zur Verfügung
stand, ist mit dem 31.1.97 auch die für Normen übliche Einspruchsfrist abgelaufen. Es gab
keine inhaltlichen Einsprüche von nationaler oder internationaler Seite.
Die aus dem Kreis der FG 4.4.2 eingegangenen redaktionellen Vorschläge, die ca. 50 Seiten
betrafen, wurden vom AK5 berücksichtigt und eingearbeitet und die überarbeitete Version als
Weißdruck-Vorlage dem NI22 des DIN am 23./24.4.97 in Frankfurt/Main auf dessen 26.
Sitzung vorgelegt. Zitat aus dem Protokoll der Sitzung: "Der NI22 nahm mit Genugtuung zur
Kenntnis, daß nach dem ordnungsgemäßen Abschluß der Einspruchsphase nun automatisch
die Veröffentlichung des Weißdrucks erfolgt". Geplant ist, nach Absprache mit Herrn
Kutschke, daß dies spätestens zum 15. IMACS Weltkongress in Berlin (24.-29. August 1997)
der Fall sein wird, auf dem der Sprecher des AK5 PEARL 90 im Rahmen seines Vortrages zu
dem Beitrag
vorstellen wird.
G. Thiele
Die Fachgruppe im Web
Mühsam war's, doch endlich ward's. Achten Sie in nächster Zukunft doch einmal auf die WWW-Domäne real-time.de. Vielleicht entdecken Sie dort etwas neues, auch wenn es für's erste recht vorläufig aussieht.
Etwas weiter ist da bereits unser AK1. Unter
http://www.ifm.uni-hannover.de/IRT/wiss-lg/pug.html
findet man Wissenswertes, Termine und anderes.
P. Holleczek