ebook img

Pearl 93: Workshop über Realzeitsysteme Fachtagung der GI-Fachgruppe 4.4.2 Echtzeitprogrammierung, PEARL Boppard, 2./3. Dezember 1993 PDF

182 Pages·1993·11.906 MB·German
Save to my drive
Quick download
Download
Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.

Preview Pearl 93: Workshop über Realzeitsysteme Fachtagung der GI-Fachgruppe 4.4.2 Echtzeitprogrammierung, PEARL Boppard, 2./3. Dezember 1993

Informatik aktuell Herausgeber: W. Brauer im Auft rag der Gesellschaft fUr Informatik (GI) Peter Holleczek (Hrsg.) PEARL 93 Workshop tiber Realzeitsysteme Fachtagung der GI-Fachgruppe 4.4.2 Echtzeitprogrammierung, PEARL Boppard, 2./3. Dezember 1993 Springer-Verlag Berlin Heidelberg New York London Paris Tokyo Hong Kong Barcelona Budapest Herausgeber Peter Holleczek Universitat Erlangen-Niirnberg Regionales Rechenzentrum MartensstraBe 1, D-91058 Erlangen Programmkomitee Ch. Andres Miinchen W. Gerth Hannover W. A. Halang Hagen K. Mangold Konstanz H. Rzehak Neubiberg U. Schneider Mittweida G. Thiele Bremen H. Weber Esslingen H. Windauer Liineburg CR Subject Classification (1993): C.3 lSBN-13:978-3-540-57473-6 e-lSBN-13:978-3-642-78658-7 DOl: 10.1007/978-3-642-78658-7 Dieses Werk ist urheberrechtlich geschiitzt. Die dadurch begriindeten Rechte, insbesonde re die der Ubersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfaltigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfaltigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestim mungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland yom 9. September 1965 in der jeweils geltenden Fassung zulassig. Sie ist grundsatzlich vergiitungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. © Springer-Verlag Berlin Heidelberg 1993 Satz: Reproduktionsfertige Vorlage yom AutorlHerausgeber 33/3140-543210 - Gedruckt auf saurefreiem Papier Vorwort Die GI-Fachgruppe 4.4.2 Eehtzeitprogrammierung, obwohl gerade 'im zweiten Jahr', zeigt eine erfreuliehe Resonanz: Die Mitgliederzahl iiberstieg bereits Anfang '93 die Zahl 100. Zuriiek blieken kann die Faehgruppe aueh auf eine erfolgreiehe Jahrestagung 1992 mit lebhaftem Besueh und engagierten, teils sogar kontroversen Vortragen und Diskussionen. Es war daher wohl keine Frage, daB die Faehgruppe aueh 1993 in vergleiehbarem Gewande eine Jahrestagung abhalten wfude. Als Leitthema gab sieh die Faehgruppe fUr dieses Jahr die 'Programmentwieklung fiir verteilte Echtzeit-Systeme', wohl wissend, daB mittlerweile mit dem Umsiehgreifen von Reehnemetzen in Produktions- wie Biiroumgebung verteilte Systeme nahezu die Regel sind. Dem Gewinn an Leistung bzw. Funktionalitat dureh verteilte Systeme steht leider aueh das Problem der Komple xitat und Handhabbarkeit entgegen. Hohe Anforderungen an die Qualitat der Programmentwiek lung sind quasi ein Gebot. Dem Leitthema sind demzufolge eine Reihe von Vortragen gewidmet, die fUr eine Aufarbeitung in konzeptioneller wie teehnologiseher Sieht dienen sollen. Aueh der Frage der Wahrung der Eehtzeitfahigkeit wird von versehiedener Seite Raum gegeben. Beriehte aus der Praxis namhafter deutseher Firmen untermauem die Bedeutung verteilter Eehtzeitsysteme in der Ausriistung von Automatisierungsanlagen. Zu einem der Hohepunkte der Veranstaltung konnte sieh gleiehwohl ein Berieht tiber einen nieht unwesentliehen Teilaspekt der deut~ehen Weltraum-Mission D-2 entwiekeln: Die Methoden zur Erfassung, Visualisierung und Abspeicherung der Experimentdaten in Eehtzeit und die Bedeu tung, die sie im Laufe der Mission erlangt haben. Nieht auBer Aeht gelassen werden sollen je doeh die Entwieklungen im Umfeld, ohne die aueh die etwas spektakulareren Anwendungen keine Basis batten. Bemerkenswert war ein deutlieher Anstieg der Qualitiit der eingereiehten Beitrage auf breiter Front, die dem Redaktionskollegium ein Zuriiekweisen aufgrund des begrenzten Veranstaltungs rahmens sehwer maehte. Publiziert werden die Beittage zu dieser Veranstaltung wieder in der Springer-Reihe Informatik aktuell, die es erlaubt, dem sorgsam erarbeiteten Inhalt aueh ein an spreehendes Erseheinungsbild zu verleihen. Die Veranstaltung ware sieher nieht moglieh gewesen ohne eine groBztigige Unterstiitzung der Firmen Siemens, Digital, ATM und Werum. Ich darf der Veranstaltung -aueh im Namen des Redaktionskollegiums und der Faehgruppe - viel Erfolg wiinsehen, verbunden mit der Hoffnung, die Veranstaltung moge sieh von der im Lande andauemden Rezession weiterhin so unbeeindruekt zeigen wie bisher. P. Holleezek Erlangen, September 1993 Inhaltsverzeichnis Seite Programmierkonzeote Entwicklung verteilter Realzeitprogramme: Eine Ubersicht A. Fleischmann, Digital Equipment, MUnchen . . . . . . . . . . . . . . . . . . . . . . . . . . . .... Ausnahmebehandlung in verteilten Realzeitprogrammiersprachen R. Schorr, Universitiit Erlangen-Numberg ................................. 33 Programmierumgebungen PEARL als Spezifikationssprache W.A. Halang, RI. Kriimer, Femuniversitiit Hagen ........................... 43 Interpretation graphischer Echtzeit-Spezifikationen mittels Graphgramrnatiken Ch. Feder-Andres, sd & m, MUnchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52 Erarbeitung einer integrierten Entwicklungsumgebung fUr PEARL 90-Programrne fUr SUN-kompatible Workstations S. Weidlich, Technische Universitiit Dresden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63 Kommunikationskonzepte Kommunikationsunterstiitzung fUr verteilte Transaktionen mit Echtzeitanforderungen G. Dobler, M. Slopianka, Regionales Rechenzentrum der Universitiit Erlangen-Numberg 74 Die Zeitabhlingigkeit als maJ3gebliche Konsistenzbedingung und ihre Zusicherung durch ein neues fehlertolerantes Commit-Protokoll K. Stieger, Universitiit Neubiberg ....................................... 84 PEARL und Komrnunikation in der MAP-rrOP-Umgebung Ch. Andres, CMG, Munchen, S. List, Universitiit Erlangen-Numberg . . . . . . . . . . . . .. 101 Anwendungen Kommunikation und Realzeit in der Fabrikautomatisierung R. Besold, Siemens AG, Numberg ................... . . . . . . . . . . . . . . . . . .. 113 Zur Echtzeitreaktivitiit von Feldbussen H. Husmann, Universitiit Hannover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 118 Echtzeitflihige Simulation dynamischer Systeme auf Kleinstrechnern K. Schulze, Foxboro GmbH, DUsseldorf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 129 Experiment-Datenverarbeitung bei der deutschen Spacelab-Mission D-2 C. Sommer, Werum GmbH, Laneburg ................................... 138 VIII Sprachen und Betriebssysteme Rechnerunterstiitzte Verteilung eines Ada-Programms auf mehrere UNIX-Prozesse K. Mangold, ATM Computer GmbH, Konstanz ....• 148 I I I I • • • • • • • • • • • • • • • • • • •• Komfortables Multitasking mit PEARL 90 auf unterschiedlichen Betriebssystemen E. Kneuer, Werum GmbH, Laneburg .................................... 157 Homogener Entwurf einer Rechnerkernarchitektur fUr harte Echtzeitanforderungen H.-P. Meske, Femuniversitiit Hagen .................................... 166 Ent wicklung verteilter Realzeitprogramme Eine Obersicht Albert Fleischmann Digital Equipment GmbH MOnchen 1. Einleitung Betrachtet man den Begriff Realzeit im engeren Sinn unterliegen a11e Programme Zeitrestriktionen und sind damit Realzeitprogramme. Ein Schachprogramm das viele Stunden oder sogar Tage braucht um einen Zug zu berechnen wird nur von wenigen Benutzern akzeptiert werden, obwohl die errechneten SchachzOge von hOchster Qualitat sein konnen. Bei dieser Art von Program men sind die Auswirkungen von nicht eingehaltenen' Zeitbe dingungen lediglich ungehaltene Benutzer (weiche Zeitbedingungen), was jedem auch beim Kauf einer Zugfahrkarte oder eines Flugtickets hinlanglich bekannt sein dOrfte. Dagegen konnen nicht eingehaltene Zeitbedingungen bei Avionikprogrammen katastrophale Auswirkungen haben (harte Zeitbe dingungen), Programme mit harten als auch weichen Zeitbedingungen sind heute fast immer auch verteilte Programme, da durch die Verteilung die Rech nerleistung zum Einhalten der Zeitbedingungen gezielter ereicht werden kann. Die Rechnerleistung kann dort eingebracht werden wo sie am besten zum Erreichen der Zeitrestriktionen beitragt. Beispiele fOr verteilte Programme mit Realzeitanforderungen sind Kommunikationssoftware, Programme zur Kontrolle von Fertigungsanlagen aber auch kommerzie11e Anwendungen fOr die automatische Abwicklungen von Geschaftsvorfa11en wie z.B. EDI Anwendungen (EDI Electronic Data = Interchange ), 2. VerteUte Systeme und Verteilte Programme Verteilte Systeme: Dem Autor ist keine a11gemein akzeptierte Definition fOr den Begriff 'verteiltes System' bekannt. Deshalb soU durch die Beschreibung einiger wesentlicher Charakteristiken eines verteilten Systems dem Leser ein GefOhl vermittelt werden was damit gemeint ist (siehe auch ISLKR87I,JNEHM851 IBST A88/), Verteilte Systeme bestehen aus einer Menge von Rechnern die durch ein Kommunikationsnetz verbunden sind. Programme die auf den einzelnen 2 Rechnerknoten eines so1chen verteilten System ausgefuhrt werden, konnen uber das Kommunikationsnetzwerk Informationen austauschen. AuHerdem konnen Rechnerknoten eines verteilten Systems aus mehreren Prozessoren bestehen die uber gemeinsamen Speicher gekoppelt sind. ParaUele Programme: Par allele Programme sind charakterisiert durch eine Menge von Anweisungsfolgen wobei jede dieser Anweisungsfolgen durch einen oder mehereren voneinander unabhangigen selbstandigen Kontrol1f10ssen ausgefOhrt wird / ANSC83/. Die Anweisungsfolge die durch einen selbstandigen Kontrol1fluB ausgefOhrt wird, wird Mufig ebenfalls als ProzeB bezeichnet. Programme die irgendwelchen Zeitbedingungen unterliegen sind fast immer auch Programme die als ein System von parallelen Prozessen realisiert werden. Die Zeitanforderungen aus Benutzersicht werden auf Zeitan forderungen for die AusfOhrung einzelner Prozesse heruntergebrochen. Prozesse werden benutzt um Aufgaben zu zuordnen. So sind z.B. bestimmte Prozesse, unter BerOcksiehtigung von Zeitrestriktionen, fOr die Behandlung von bestimmten zusammengehOrigen externen Ereignissen zustandig. Prozesse die fOr bestimmte Aufgaben zustandig sind arbeiten mit anderen Prozessen zusammen, um das gemeinsame Ziel zu erreichen. Dazu tauschen Prozesse Informationen aus und synchronisieren ihre Aktivitaten. Werden die einzelnen Prozesse eines Programms auf verschiedenen Rechnern eines verteilten Systems ausgefOhrt wird es verteiltes Programm genannt. Betrachtet man Programme die auf verteilten Systemen ausgefOhrt werden kann zwischen Network Computing und Cooperative Computing unter schieden werden /SHATZ89/,/COOO88/. Network Computing: Network Computing ist charakterisiert durch eine Menge von Prozessen die mehr oder weniger unabMngig voneinander auf verschiedenen Rechner knoten eines verteilten Systems ausgefOhrt werden. Ein ProzeB fOhrt dabei aus Sieht des Benutzer ein Anwendungsprogramm unabhangig von anderen Anwendungsprogrammen aus. Das verteilte System dient im wesentlichen dazu, daB Prozesse Resourcen gemeinsam nutzen. Beispiele fOr gemeinsam benutzte Resourcen sind Drucker oder gemeinsame Daten. Ein spezieller Drucker steht nur an einem bestimmten Knoten des verteilten Systems zur VerfOgung. Zu druckende Dateien werden zu diesen Knoten gesendet, wo sie dann ausgedruckt werden. Dieser Knoten wird dann zusammen mit der entsprechenden Systemsoftware aus Sieht der Benutzer (den Clients) als Druckserver bezeiehnet. Weitere Beispiele fOr Server sind Mailserver, Daten bankserver, CAD-Server etc .. Clients fordern von den Servern also ent sprechende Dienste an wobei die Clientprogramme voneinander unabhangig sind. Das folgende Bild zeigt das Prinzip dieser sogenannten Client/Server Systeme. 3 I!il::~~!~~~~:::j;~: :!I::!:~~~~~::l Reques t message .••••••••. ::.~:.~:.~:.~:.~:..~~::.~:.~., ~.~.~ !IjIjI~!~!!IiII.... s:n~Q~:~~y .f.ii..•: .:.• .:..:..., :.. :..'' .: I'--Rep-ly -me-ssa-ge- -..: ::::::::" .':':':':':" .~:~:~:~:~:~:::::::::::::::::::::::::::::::::::::::::::::~:~:~:~:~:~:: :::::::::::::;:::::::;:::::::::::::::::::::::::::::::::;:::::::;::::: .:.::::::=::.:.:.:::.:::::::::::::::::::::::::::::::::::::::::::::::: ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Bei Client/Server Systemen reprasentiert ein Client den Benutzer eines verteilten Systems. Server reprasentieren die einzelnen vom System bereitgestellten allgemein benotigten Dienste. vergleiehbar den Funktionen eines Betriebssystems. Das folgende Bild zeigt ein Beispiel fOr ein Network Computing System. Netzwerk station 1----1 Fileserver Druckserver Work station Mail server 1----1 Aus Benutzersieht kann ein Client/Server System nahezu nieht von einem zentralen System untersehieden werden. Der Benutzer oder sogar der Pragrammierer eines Client/Server Systems sieht nahezu nieht wenn das Anwendungsprogramm (Client) Funktionen benutzt. die auf einem anderen Reehnerknoten (Server) ausgefOhrt werden. Bin wesentlieher Vorteile eines Client/Server ist. daB es leieht dureh weitere Server erweitert werden kann und es in der vertrauten Form eines Zentralsystems benutzt werden kann. Bin Client aktiviert die Funktionen von Servern meistens dureh sogenannte Remote Procedure Calls (RPC oder Fernaufrufe). Ein RPC ist wie ein Prozeduraufruf fOr verteilte Systeme. Naeh der AusfOhrung des Fernaufrufs wird das aufrufende Programm am Clientknoten angehalten. der KontrollfluB wandert zum Server. wo die entspreehende Servicefunktion ausgefOhrt wird. naeh dessen Beendigung wandert der KontrollfluB wieder zum Client zurOek wo das angehaltene Clientprogramm fortgesetzt wird. 4 Das folgende Bild zeigt die Struktur eines Client Server Systems basierend auf Remote Procedure Calls. Application • • • • • Application • • • • • Network • • • • • Cooperative Computing Bei cooperative Computing wird eine Menge von Prozessen auf verschiedenen Knoten eines verteilten Systems ausgefOhrt. Allerdings sind dies gleichberechtigte Prozesse die zusammenarbeiten um ein gemeinsames Ziel zu erreichen. Bei kooperativen Zielen wird die Parallelitat bzw. Verteilung eines Programms nieht hinter Programmkonstrukten wie z.B. RPCs verborgen. Die Zusammenarbeit von Prozessen wird realisiert durch den Austausch von Informationen und die Synchronisation ihrer Aktivitaten. Das folgende Bild zeigt die Struktur von Cooperative Computing Systemen. unication and Network

See more

The list of books you might like

Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.