Lecture Notes in Computer Science Edited by G. Goos, Karlsruhe and J. Hartmanis, Ithaca
12 GFK-Gesellschaft far Kernforschung mbH, Karlsruhe GI-Gesellschaft f~ir Informatik e. V., M~Jnchen GMR-VDt/VDE-Gesellschaft Me6- und Regelungstechnik, DfJsseldorf
Fachtagung Prozessrechner 1974 Karlsruhe, 10.-11. Juni 1974
Herausgegeben von Gerhard Krager und R(Jdiger Friehmelt
Springer-Verlag Berlin-Heidelberg New York 1974
Editorial Board: P. Brinch Hansen • D. Gries C. Moler • G. Seegmeller • N. Wirth Prof. Dr. Gerhard Kr0ger (Vorsitzender des Programmkomitees) Gesellschaft for Kernforschung mbH, Karlsruhe Institut for Datenverarbeitung in der Technik Dr. R0diger FrJehmelt Gesellschaft for Kernforschung mbH, Karlsruhe Institut for Datenverarbeitung in der Technik
AMS Subject Classifications(1970): 0 0 A 1 0 , 68-02, 6 8 A 0 5 , 6 8 A 2 0 , 68 A30, 90 B 3 5 CR Subject Classifications (1974): 2.1,3.34,3.36,3.54,3.8,4.1,4.2, 4.3, 6.1, 6.2, 6.3, 8.2
ISBN 3-540-06?86-8 Springer-Verlag Berlin • Heidelberg • New York ISBN 0-387-06?86-8 Springer-Verlag New Y o r k - Heidelberg • Berlin This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically those of translation, reprinting, re-use of illustrations, broadcasting, reproduction by photocopying machine or similar means, "and storage in data banks. Under § 54 of the German Copyright Law where copies are made for other than private use, a fee is payable to the publisher, the amount of the fee to be determined by agreement with the publisher. © by Springer-Verlag Berlin • Heidelberg 1974. Library of Congress Catalog Card Number 74-7905. Printed in Germany. Offsetdruck: Julius Beltz, Hemsbach/Bergstr.
VORWORT Die Fachtagung
"PROZESSRECHNER
liche Veranstaltung
1974" ist die erste gro~e wissenschaft-
in der Bundesrepublik
schlieBlich mit den grundlegenden Programmierung
Deutschland,
und der Einsatzprobleme
und Regelungstechnik den Vorst~nden Folgezeit
fGr Informatik,
nachdrGcklich
Die Gesellschaft
schungsschwerpunkts
Anwendungen
Hbernommen
die von und in der
verstgrkt
sich bereit,
Tagung auf dem Gel~nde des Kernforschungszentrums
und
im Rahmen des
Forschungs-,
in der Datenverarbeitung
hat, erkl~rte
und die ~ber-
mit DV-Anlagen"
und Konstruieren"
der Bundesregierung
und Koordinierungsaufgaben
in der Technik"
"Proze~lenkung
Entwickeln
aufgegriffen
Me~-
die durch die Bildung des For-
"Datenverarbeitung
"RechnerunterstGtztes 2. DV-Programms
bevon Mit-
wurde.
fur Kernforschung,
nahme der Projekttrggerschaften
fur Kernforschung,
vorbehaltlos
unterstGtzt
Initiative
der
der VDI}VDE-GeSellschaft
und der Gesellschaft
der Gesellschaften
Aufbaus,
yon Proze~reehensystemen
fa~t. Den Ansto~ zu der Tagung gab eine gemeinsame gliedern der Gesellschaft
die sich aus-
Fragen des technischen
P!anungs-
f~r technische
die Ausrichtung Karlsruhe
der
zu ~ber-
nehmen. Der Breite der Themenstellung schaften Repr~sentanten Software-Bereichen,
angemessen
baten die drei Tr~gergesell-
der DV-Hersteller-lndustrie
der jungen Wissenschaftszweige formatik um Mitwirkung
der Proze~rechentechnik
im Programmkomitee,
W. Ammon, AEG-Telefunken, Technische
H. Bollmann,
Universit~t
MGnchen
Siemens AG, Erlangen
R. Gnatz, Technische
Universit~t
G. KrUger,
Gesellschaft
R. Lauber,
Universit~t
P. Namneck,
Frankfurt/Main
BASF, Ludwigshafen
R. Baumann,
MGnchen
f~r Kernforschung,
Karlsruhe
Stuttgart
SCS, Hamburg
D. Stams, Gesellschaft G. Strohrmann,
f~r Kernforschung,
Chemische
Karlsruhe
Werke H~is, Marl
M. Syrbe, Fraunhofer-Gesellschaft,
und
und Vertreter
und Proze~in-
das aus folgenden Herren
bestand:
T~. Ankel,
aus Hardware-
erfahrene Anwender von Proze~rechnern
Karlsruhe
IV Bei der Auswahl der thematischen
Schwerp~nkte
davon aus, dab die Notwendigkeit
eines breiten Einsatzes
rechnern
in praktisch
f~r die Automatisierung
duzierenden
Wirtschaft,
technischen
Systemen wle dem Verkehrsbereich,
zusehen,
nomischen
Zuwachs
Zukunft
Bedingungen
tisierung wesentlich wirtschaft
zur ~brigen Datenverarbeitung
in Zukunft
eine durch konsequente
Produktivit~t
und Rohstoffverwendung
sein, eine angemessene
lungstechnischen
aller Sparten der Volksund der Notwendigkeit
eine der wesentlichsten
wirtschaftliehe
der Proze~rechner
Einrichtungen,
rung~ in die vielf~itigen einrichtungen
Entwicklung
auch
in die me~-,
Gebiete
betrachtet,
Neue Hardware-Technologien,
yon Beitr~gen behandelt
werden,
und ihren - vorzugsweise
der Mensch-Maschine-Kommunikationsvorzugsweise
in der Entwicklung
erstellung,
die wir v o n d e r
bei der "Software"
Systemauswahl,
den Techniken
Beitr~ge
andererseits,
des 2. DV-Programms
sen Gebieten gearbeitet
der Programm-
der Abnahme und der kommunikativen
scheiden aus. Wie konzentriert wird,
im wei-
des Rechner-
bis hin zu systematischen
steuerung dutch den Menschen verstehen wollen, durch die Ma~nahmen
eine Ver-
fur die es keinen
Wirtschaftlichkeitsplanung
-pr~fung und -~bertragung
fahren der Installierung,
der Rechner
der modernen Technik gibt.
nehmen sich die Fortschritte
der methodischen
bewirkt,
der "Hard-
in einer Reihe
- Peripheriekomponenten
Vergleich
einsatzes,
ein Verdienst
haben in der Ger~tetechnik
digitalen
des Preis-Leistungs-Verh~Itnisses
testen Sinne,
ist, unter wirtschaft-
wie sie exemplarisch
besserung
Demgegen~ber
steuer- und rege-
in die Pr~ffeld- und Laborautomatisie-
und der Nachrichten~bertragung
lichen Gesichtspunkten
maGhen.
5ko-
Automa-
sicherzustellen.
Das rasche Vordringen
gegangenen
auch in
Wird doeh unter den ver~nderten
der Weltwirtschaft verst~rkte
Energie-
Voraussetzungen
ware".
anh~it.
sozio-
Es ist voraus-
an Proze~rechner-lnstallationen
bei sinkendem Arbeitskr~ftepotential
sparsamster
der pro-
der Vet- und Entsorgung
keiner Begr~ndung mehr bedarf.
da~ der schon jetzt im Vergleich
der ~berschaubaren
von Proze~-
allen Bereichen
dar~ber hinaus aber auch in allgemeineren
und dem Gesundheitswesen weit ~berproportionale
ging das Programmkomitee
vergleichsweise
wesentlich
Ver-
Betriebsbe-
gef~rdert
der Bundesregierung,
auf die-
zeigt nicht zuletzt die F~lle der ein-
zur Software,
die den Hauptteil
der Tagung aus-
Lassen Sie uns abschlie~end Zuerst den Autoren, kurz bemessenen einzuhalten,
einige Worte des Dankes sagen:
die durch ihre Bereitschaft,
Fristen f~r die Fertigstellung
eine rechtzeitige
Herausgabe
die notwendigerweise
der druckreifen
des Tagungsbandes
Beitr~ge
zu Beginn
der Tagung ermSglichten. Weiterhin den Mitgliedern
des Programmkomitees,
siertes Bewertungsverfahren Entscheidungen Besonders
auferlegten,
um zu m6glichst
~ber die Auswahl der Beitr~ge
der drei Tr~gergesellschaften,
Dr. M. Syrbe
(VDI/VDE-GMR),
und Dr. D. Stams wirkungsvoll Grauer,
(GfK/PDV),
das reibungslose
(VDI/VDE-GMR),
im Organisationskomitee,
yon Mitarbeitern
der Gesellschaft
Dr. R. Gnatz
(GI)
dessen Arbeit sehr
f~r Kermforschung,
wurde.
im April 1974
Zu-
vertreten durch die Herren
Fraulein M. Joram, Fraulein A. Eigl und Herrn Dipl.-Ing.
unterst~tzt
Karlsruhe,
M.A. Kaaz
objektiven
zu ge!angen.
hervorheben mSchten die Unterzeichneten
sammenwirken
besondere
die sich ein formali-
Die Herausgeber
insH.
INHALTSVERZEICHNIS
E I N F O H R U N G IN DEN K O N G R E S S
.........................
I
E i n f G h r u n g in den Kongre~ aus der Sicht der V D l / V D E - G e s e l l s c h a f t Me~- und R e g e l u n g s t e c h n i k Dr. Otto Winkler, Marl, V o r s i t z e n d e r der V D I / l ~ E - G e s e l l s c h a f t MeB- und R e g e l u n g s t e c h n i k
.....
3
Prof. Dr. Heinz Gumin, President der G e s e l l s c h a f t fGr I n f o r m a t i k ........................
9
T e n d e n z e n in der P r o z e 6 r e c h n e r t e c h n i k
HAUPTVORTREGE
......................................
13
O r g a n i z a t i o n of Software for M u l t i c o m p u t e r Process Control Systems J. D. S c h o e f f l e r
...................................
14
Stand und T e n d e n z e n auf dem Gebiet der P r o z e ~ r e c h n e r Hardware U. Offer
...........................................
63
R e l i a b i l i t y and Integrity of Large C o m p u t e r Programs C. V. Ramamoorthy,
R. C. Cheung, K. H. Kim .........
G E R ~ T E T E C H N I K DER P R O Z E S S R E C H N E R
...................
86
163
A u s w i r k u n g e n der M i k r o p r o z e s s o r - T e c h n i k auf Einsatz und Struktur z u k G n f t i g e r P r o z e S r e c h e n a n l a g e n *) G. F~rber
..........................................
164
Die serielle D a t e n G b e r t r a g u n g im C A M A C - S y s t e m zur dez e n t r a l e n D a t e n e r f a s s u n g und P r o z e ~ s t e u e r u n g H. K l e s s m a n n
.......................................
Ein C A M A C - u n t e r s t G t z t e s Me~datenerfassung *) P.-M.
175
P e r i p h e r i e - S u b s y s t e m zur
Czaikowski, D. Reimer, H.-J.
Schuiz
..........
188
Das Plasma Display - ein digitales grafisches Sichtger~t J. Zahn, P. Abend,
Z. Komor
........................
200
VIII Datensichtger~te fGr grafische Darstellungen V e r w e n d u n g yon F e r n s e h m o n i t o r e n *) R. Zimmermann Frequenzanaloges
unter
...................................... Proze~fGhrungssystem
211
*)
H. Kalis, M. Klinck, G. Landvogt, J. Lemmrich, G. Schr6der ........................................
222
Spezifische E i g e n s c h a f t e n eines proze~rechnergefGhrten Instrumentierungssystems mit Frequenzumsetzung *) F. Freyberger,
Ch. GeiBler,
MENSCH-MASCHINE-KOMMUNIKATION
H.-R. Tr~nkler
.........
IM PROZESSBETRIEB
233
.... 245
E x p e r i m e n t e l l e r Vergleich paralleler und serieller Stelleingriffe in einen gest8rten ProzeB *) W. Schumacher
......................................
Anthropotechnische Grundlagen der Informationsdarstellung auf p r o z e ~ r e c h n e r g e s t e u e r t e n Sichtger~ten R. Moog
246
*)
............................................
256
Ein K o m m u n i k a t i o n s s y s t e m zur on-line E r f a s s u n g und real-time V e r a r b e i t u n g von klinisch-chemischen MeSwerten K. Killian,
M. Knedel
..............................
271
Dialogf~higes A u f t r a g s d i s p o s i t i o n s s y s t e m auf der Basis r e c h n e r u n t e r s t G t z t e r B e t r i e b s d a t e n e r f a s s u n g und -verarbeitung *) T. Pfeifer,
U. B~ck
................................
Organisation und Funktion eines Systems Proze~verfolgung *) A. SchGring
283
zur grafischen
........................................
297
M U L T I - L E V E L DIALOG LANGUAGE M U L T I - L E V E L DIALOG SYSTEM - modifizierbare Sprachmittel fGr den Dialog zwischen Mensch und rechnergesteuerten Abl~ufen *) I. Schnarre
........................................
308
IX
ZUVERL~SSIGKEIT
UND SICHERHEIT
.....................
E r f a h r u n g e n fiber die Verf~gbarkeit Systemen in einem H~ttenwerk *) G. Wiethoff,
H.-J.
St~bler,
K.-H.
Wobig
.............
J. Bancsich,
syntaktisch
G. Vinek
Leistungskriterien
repr~sentierter
..........................
344
353
yon Proze~rechnersystemen
..........................................
Echtzeit-Nachbildung prozesse *)
diskontinuierlicher
M. Week, A. Sch~ring Zur E n t w u r f s m e t h o d o l o g i e ProzeZrechner W. Gottschalk
334
Zu-
..............................
PLANUNG UND PROJEKT!ERUNG
320
mit Mehrrechner-
........................................
Parallelkontrolle standsfolgen
R. Lauber
von on-line PDV-
R. He~ling
Sichere P r o z e ~ d a t e n v e r a r b e i t u n g systemen *)
319
Fertigungs-
............................... von Programmsystemen
354
f~r
......................................
PROGRAMMERSTELLUNG
+)
DT~D PROZESSSPRACHEN .............
365
377
Wege zur rationellen Softwareerstellung f~r Grundaufgaben der P r o z e ~ b e r w a c h u n g , Steuerung und Regelung R. Wendelin Programmieren V. KUssl
........................................ yon Proze~datenbanken
378
mit A d r e ~ v a r i a b l e n
...........................................
Das P r o z e ~ - L e i t - S y s t e m in der Forschung und E n t w i c k l u n g der V o l k s w a g e n w e r k AG, Wolfsburg Struktur des Betriebssystems H. Relier ..........................................
389
++)
X Erfahrungen bei der E r s t i m p l e m e n t i e r u n g Subsets *) J. Heger,
G. Koch
Proze~zust~nde P. Rieder
eines PEARL-
..................................
bei E c h t z e i t p r o g r a m m i e r s p r a c h e n
*)
..........................................
PROCESS BASIC - Ein P r o g r a m m i e r s y s t e m lenkung mit Kleinrechnern *) F. Wagner,
H. Woda
HShere P r o z e S s p r a c h e n Beispiel BASEX A. Go!denberg,
Ch. Schlier,
415
f~r Proze~-
................................. fGr kleinere
401
425
Rechner - das
W. Schupp
..............
436
Die O b e r s e t z u n g der CAMAC-Sprache unter V e r w e n d u n g der Zwischensprache IML - E r f a h r u n g e n bei der implem e n t i e r u n g von CAMAC-Compilern W. Kneis, K. H. Degenhardt, Ein Verfahren
..............
zur Optimierung von Systemprogrammen
P. J. Brunner,
W. Hinderer,
REALZEIT-BETRIEBSSYSTEME Ablauf-Kontrollstrukturen organisationen -) J. Nehmer
W. Woletz
W. Werum
*)
...............
O. Eggenberger
fur ProzeSrechner-Betriebs-
Adaptierbare Funktionen zum stufenweisen ProzeSrechner-Betriebssystems
Der Kern eines allgemeinen PEARL-Betriebssystems
Funktionsbausteine H. Hotes
506
Programmiersprache
D. D~rr, S. Eichentopf, U. Prahl, G. Siegel, G. Tebling .........................................
A. Tarabout,
494
Aufbau eines
.................................
SL3 - Eine maschinenorientierte auf ALGOL68-Basis
H. BSsmann,
480
fur die Proze~kommunikation *)
.....................................
W. R~b, G. Schrott
458
479
. . . . . . . . . . . . . . . . . . . . . . . . . . .
..........................................
Ein integriertes Konzept in Prozegrechensystemen
447
W. Werum
*)
..................
f~r Realzeit-Betriebssysteme
517
528
*)
...........................................
544
$BERTRAGBARKEITVON
PROGRAMMEN
.....................
555
Modu!test als Spezialfall gezielter Portabi!it~t L. Stolze
..........................................
556
Software Portability via an Intermediate Language W.M. Waite .........................................
564
Ein portabler Obersetzer ffir einen Subset der Proze~Programmiersprache PEARL *) B. Eichenauer ......................................
576
ANSCHRIFTEN DER AUTOREN ............................
617
*) Dieser Beitrag enthfilt Ergebnisse aus einem Forschungsund Entwicklungsvorhaben des "Projekts Proze~lenkung mit DV-Anlagen (PDV)" im 2. DV-Programm der Bundesregierung.
+) Manuskript versp~tet eingegangen, siehe Seite 586 ++) Manuskript verso~tet eingegangen, siehe Seite 602
E I N F D H R U N G
IN
DEN
KONGRESS
EINFOHRUNG
IN DEN KONGRESS AUS DER SiCHT DER VDI/VDE-GESELLSCHAFT MESS- UND REGELUNGSTECHNIK Dr. O. Winkler~
Marl
Meine Damen und Herren! Wie Sie der Einladung ge Einf~hrungsworte
zu dieser Tagung entnehmen k~nnen,
an Sie richten,
der VDl/VDE-Gesellschaft Diese Aufforderung ja ein Konzentrat sellschaft
die, wie es heist, aus "der Sicht
Me~- und Regelungstechnik"
~bersteigt
ob es eine einzige
"Sicht"
der Gesellschaftsarbeit
abspielt.
in dieser Tagung gehaltenen Vortr~ge Einleitungsworte
st~ndige Bereich stellung, vortragen,
die aus meiner langen Berufspraxis
Beschreibung
graven, Eigenschaften Bereieh erstrecken. und Aktivit~ten
berichte,
in der letzten Zeit entabgefa~t hat.
Erfahrungen
und Ansichten
als Anwender von Rechnern
stammen.
hat zun~chst
einmal Arbeiten durchge-
auf die Zusammenstellung,
von Begriffen,
und Schnittstellen verfolgt
Definition
charakteristisehen
im hardware-
und notwendige
Kenn-
und software-
Es wurden ferner die internationalen
aufmerksam
die der zu-
auf die letzte Zusammen-
Herr Dr. Theo Ankel,
will ieh lhnen einige allgemeine
4 der Gesellschaft
als es einige
dab ich lhnen aus der Gesellschafts-
4 "Technik der Proze~rechner"
f~hrt, die sich im wesentlichen
treffen einige der
verm~gen.
ich st~tze mich dabei weitgehend
und funktionelle
in der Ge-
genauer auf zur Zeit anstehende
nur etwas ~ber die Aktivit~ten
im Bereich der Verfahrenstechnik Der Bereich
Schlie$1ich
darzustellen
die der Bereichsleiter,
Anschlie~end
ich
Au~erdem ist es sicher fraglich,
Bild der Sachverhalte,
Ich hoffe Sie damit einverstanden, arbeit einleitend
sind.
m~te
gibt, daf~r sind die einzelnen Teilbereiche
zu vielf~Itig.
Probleme und geben ein klareres
wickelt hat.
abgefa~t
weitaus meine M~glichkeiten,
dessen anbieten k~nnen, was sich insgesamt
im Rechnerbereich
allgemeine
soll ieh eini-
Entwicklungen
Stellungnahmen
er-
arbeitet. Die Arbeit wird vorwiegend sch~ssen erledigt, Der Arbeitskreis fragebogen"
in ad-hoe-Arbeitskreisen
und Redaktionsaus-
die nach Belieben eingerichtet
und aufgel~st werden.
Proze~rechner-Leistungskriterien
hat einen "Norm-
erstellt mit relevanten
und anwendungsabh~ngigen
en, mit dessen Hilfe der Anwender die Leistungsf~higkeit dener Proze~rechnersysteme
untereinander
eine allgemeine
eines Realzeit-Betriebssystems
Gliederung
vergleichen
Kriteri-
verschie-
kann. Es wurde in ein-
zelne
Programm-Module in Vorsehlag
Der A r b e i t s k r e i s schaften" beitung Blatt
gebraeht.
"Funktionelle
Besehrelbung
hat die f u n k t i o n e l l e
Besehreibung
ausgef~hrt
und seine V o r s t e l l u n g e n
2 "Unterbreehungseingabe"
5 Sehiehten
zur B e s c h r e i b u n g
yon B e t r i e b s s y s t e m - E i g e n der U n t e r b r e e h u n g s b e a r in den D I N - E n t w u r f
eingebracht.
Ein S c h i c h t b i l d
der B e t r i e b s s y s t e m f u n k t i o n e n
66 216, aus
wurde
ent-
worfen. Ein RedaktionsausschuS entworfen~ zeBreehnern nisehen
hat eine R i e h t l i n i e
in der die w i c h t i g s t e n unter B e r U c k s i c h t i g u n g
und e n e r g i e t e e h n i s e h e n
In einem A r b e i t s k r e i s an einer R i c h t l i n i e
nahmen Der
der Probleme
Prozessen
"StSrfreiheit
zum Einsatz
von Pro-
bei v e r f a h r e n s t e c h -
zusammengestellt
sind.
von M e ~ - und S t e l l s i g n a l e n "
d b e r die S t ~ r s i c h e r h e i t
im P r o z e B r e c h n e r b e t r i e b StSrbeeinflussung
"Einsatzvorbereitung"
Gesiehtspunkte
gearbeitet~
in der einmal
selbst b e s e h r i e b e n
wird
bei S i g n a l ~ b e r t r a g u n g e n die E i g e n a r t
w i r d und e n t s p r e e h e n d e
der
Gegenma~-
e m p f o h l e n werden.
Ihnen a l l e n b e k a n n t e
auf Basis
"Purdue W o r k s h o p "
F O R T R A N hat V o r s e h l i g e
tensiven Diskussionen
fur eine R e a l z e i t s p r a e h e
e r a r b e i t e t 9 die G e g e n s t a n d
w a r e n und zur F o r m u l i e r u n g
yon in-
von E i n s p r ~ c h e n
f~hrten. Die bisher soweit
genannten
man a u f
An l a u f e n d e n -
Erstellung
Arbeiten
diesem
Arbeiten
Gebiet
sind
dberhaupt
Durchsicht "Hardware
yon 2 Entwiirfen zur
-
und E r a r b e i t u n g Testing
Der ursprdnglich Experiment die
yon einem AbschluB reden
kann.
Process
integriert
tionale
No r m u n g e i n g e r e i e h t .
zum I S A - E n t w u r f
Computers".
"PEARL"-Arbeitskreis
Realtime
definiert
und Ortung von H a r d w a r e -
einer S t e l l u n g n a h m e
selbst~ndige
sprache
"Erkennung
bei ProzeBreehnern".
of Digital
Automation
Gesellsehaft
AbschluB gelangt,
sind z u erw~hnen:
f e h l e r n und S o f t w a r e f e h l e r n -
zu e i n e m g e w i s s e n
Language)
worden.
is,
Er hat
vor die
entwiekelte
u n d a n d e n FNI z u r W e i t e r l e i t u n g Auch w i r d
(Process einiger
versueh%~
in die
die
and
Zeit
in
ProzeBinterna-
Sprache
PEARL
in Kleinreehnern Diese
kurze
einsatzf~hig
Aufstellung
zustandigen
Bereiehes
beitskreise
hier
Hilfe
an der
s~nliehe
zeigt
allgemeinen
Freude
Ihnen,
4 reeht
anwesend an der
zu maehen. dab d i e
groB ist.
sind,
danke
Breite
Soweit ieh
und E r f o l g
mit
Die nun folgenden allgemeinen Bemerkungen tet, aus der Sieht und Berufspraxis
Aktivitit
des
Mitarbeiter
der
fGr die
selbstlose
Ihnen
Saehe und wiinsche I h n e n Arbeit
der
auch
Ihrer
stammen,
in
Ar-
Zukunft
per-
Arbeit. wie sehon angedeu-
eines Anwenders yon Reehneranla-
gen. Aber aueh der Hersteller yon hardware und software wird sie nieht auBer aeht lassen k~nnen,
da ja nur das in der Praxis gut lau-
fende System seine eigenen Gedanken und Ideen best~tigen Es i s t
die
und d l e s e
Frage
wiederum mit
d e n muB. V i e r -
gestellt
worden, Hilfe
weshalb
der Rechner
Gesichtspunkte
bejahen
Die GrSBe der Einzelanlage
und ob d i e -weiter
diese
kann.
Automattsierung
vorangetrieben
wer-
Fragestellung:
ist erheblieh gewaehsen,
well sonst
eine wirtsehaftliehe
Erzeugung nicht mehr m~glieh ist. Dieser
Trend ist allgemein~
er gilt ffir den Dampfkessel,
die chemisohe Verfahrensanlage
-
den Hoehofen,
und den fertigungsteehnisehen
Pro-
duktionsbetrieb.
-
Einzelbetriebe
sind zu Systemen zusammengewaehsen,
sehr kompliziert so daB alleine
ungenau und unvollst~ndig
Die sicherheitstechnischen lagen
einen
Pflicht bier
erheblichen
ffir Sehutz
Apparatur
selbst
synonym fdr
peraturen, rial
yon Leib
alle
Beteiligten
werden.
VersehleiBwerden.
Das W o r t
und S t o f f s t r S m e
che Pr~zision
der
Reehner
einspringen
der
steht
hohe
Tem-
Verfahrens-
GrGnden, werden.
groBen Systemen
Informationsdarbietung helfend
muB a u c h d i e "sieher"
und E r m f i d u n g s p r o b l e m e am M a t e -
ausgenutzt
in
den GroBan-
Hohe D r f i c k e ,
Grenzbedingungen
vertretbar,
meist
der
und Leben d e r
in
selbstverst~ndlichen
mdssen aus wirtsehaftlichen
sieherheitstechnisch
nur
verlangen
Neben der
gefahren
ohne den
bleiben muB.
Auslegungsspielarten.
Korrosions-,
Energie-
Anforderungen Aufwand.
"sicher"
m~ssen bew~ltigt
Produktionsteehnik der
diese sind dann
und aueh r~umlieh welt ausgedehnt,
sehon die D a t e n e r f a s s u n g und -verarbeitung
Reehner-Einsatz -
und vielf~Itig
so n a h w i e
Die Dynamik
fordert
eine
und - v e r a r b e i t u n g , kann,
und
sold ab
wogegen der Menseh
allein
hoffnungslos
gezeigt,
Uberfordert
daft d e r R e c h n e r
die
das
mensehliche
ses
noeh rund
zwangsl~ufig
Uhr,
ins Gewicht
Personal
eines
erhebliehen
herangezogen
software
EinsatzmGgliehkeiten
net
sozusagen
sind
-
bedeutungsvoll Der erste
der
Bereieh
einmal
unfibersiehtliehen das
in
spiele
sind
geht
die
direkt
der
Endes
anderes
lich
Genauigkeit
in
u.a.m,
nur
Zeit
ihrer
-
so auszuwerten,
als
die
ob b e i
die
etwa einer
Analysenteehnik
der
im A b -
Wenn man d i e in
klar
die
hinsicht-
Stahlindustrie,
dfirfte
und d a m i t
Bei-
Forsehungslabors,
Unzulinglichkeiten
fiberlegt,
dab
oder
Analysensysteme,
gro~en
An-
Anwendungsziel
der Kraftfahrzeugherstellung,
etwas
der
Aussage
zur VerfUgung steht.
Aufwand a u s z u s c h a l t e n .
Analysenzentren, bei
Das Z i e l in
Das z w e i t e
ganzer
zeitlichem
Industrie,
groBe Bereieh
verstindlieher
Schadensanalyse gedrUckt satzteilen, zeitig
Verfahrensteehnik
sein,
in
der
der Mate-
d ab n o c h
auch Entwieklungsarbeiten
liegen.
Der zweite fort
ver-
Umfang.
Digitalreeh-
im S t a h l e r z e u g u n g s b e r e i e h
wollen,
AnwendungsmGglichkeiten uns
fur
primiren,
in kurzer
und m e n s c h l i c h e
oder
soleher
rialprfifung vor
die
"im Klartext"
Integration
niehts
zu r a t i o n a l i s i e r e n
Bedeutung
wieder
auf wesentlieh
Laboratoriumsteehnik.
yon Gaschromatographen
lauf
Chemisehen
muf bier
und Herstel-
begrenztem
Einsatzbereiche
eigentliehen
Richtung,
Spektralanalyse
in Richtung
letzten
Allerdings seinerseits
allerdings
und K e r n r e s o n a n z s p e k t r o m e t r i e .
groBen Zahl
viele
der
die
Analysenwerte
Analysenresultat
Massen-
werden.
geworden.
ist
wendung geht
am R a n d e d e r
verlangen
aus der Einzelaufgabe.
zur Systemanalyse
beda~f,
bzw.
Monat usw.
fdr Uberwaehungsaufgaben
Ebene und in zeitlieh
Zwei g r o ~ e
kann, und d i e -
fur
dab der Reehnereinsatz
beruflieher
ferner
vermag,
Personalkosten
des Mensehen
Personaleinsatzes
lung der fertigen sehiedener
Monat
fallenden
mug weitgehend
und Steuerungsfunktionen sehon bemerkt werden,
Tag,
hat
ausfUhren
darzustellen
Tag f u r
eine Herausl~sung
Das beteiligte
Die Erfahrung
Sicherheitsstrategien
VermGgen n i e h t
um d i e
Die immer starker
wKre.
geht
ist
wird,
der
Bereieh
w e n n man d i e
und S e h a d e n s v o r a u s s a g e e s um d i e
wenn d a s
zur Verf~gung
Frage,
gerade steht
der
Begriffe
ausfallende
mir Teil
Anlage
der
so-
Schadenserkennung,
hinzuzieht.
was n ~ t z t
und d i e
Anlagenwartung,
ein nieht
Sehr groBes oder
ausgefallen
primitiv
aus-
Lager
an E r -
nieht
reeht-
ist.
Hier
tech-
nisch richtig zu liegen und dennoeh wirtschaftlich ten, ddrfte eine hohe Kunst sein. erlaube
ich mir die Bemerkung,
aueh systemtheoretischer l~st anzusehen.
optimal
zu arbei-
Ohne Faehmann im Detail zu sein,
dab es noch vieler Detailarbeit
neuer Ans~tze bedarf,
Die Frage beginnt in groBen V e r f a h r e n s p r o z e s s e n
schon mit der Frage nach Einfach-,
Parallel-
Reicht die prophylaktisehe
te Schadenserkennung klar erkenntlich,
einge-
Methode aus, sell ieh nur aku-
betreiben und das mit welcher Methode? Hier ist
dab wir noeh nieht am Ende des Weges
Eine letzte allgemeine den m~ehte,
ja
oder M e h r f a c h s y s t e m e n
und sehlieBt aueh die Frage ein, welche Erkennungsstrategie setzt wird.
und
um das Problem als ge-
Frage,
sind.
die ich in dieser EinfUhrung anschnei-
ist die Frage der Struktur der eingesetzten R e c h n e r s y s t e -
me. Soll ein vollst~ndiges len hierarchlsche
sog. back-up-System vorhanden
Strukturen das Problem besser
sieh gegenseitig kontrollierender
l~sen,
Parallelbetrieb
sein,
sol-
oder ist ein
zweier Reehner die
beste LSsung?
Die Erfahrung
zeigt,
auBerdem zeigt ternehmen,
dab jedes
k~nnen aber
einige
rungsbereich Konferenz 1974,
bei
einer
hat.
Als Basis
H. Amrehn a u s dem E r f a b d e r 4.
Internationalen
in ZUrich,
19.
-
22.
M~rz
Letzten
aus,
der Rechner oder die
Endes geht
DaB d i e
MTBF z w i s c h e n Abschatzung
auBerhalb
e s um d i e Anlage,
primitive
Jahren
62 u n d 72 T a g e n .
Frage:
eigenen
ausdrUcklieh
verbesserte
VerfUgbarkeit Hier
der Ausfallwahrschein-
u n d was p a s s i e r t
der Absch~tzung der Gef~hrdung wesentlich
Die in den letzten
eine
der Rechnerzust~ndigkeit
der Anlage inh~renten
Beriehterstattung
eine
yon 10,1Stunden.
es n u r a u f
MTBF y o n e t w a 62 T a g e n l e i c h t
nen.
ergibt
MTBF (mean ~ i m e ~ e t w e e n ~ a i l u r e ) Reparaturzeit
bringen
dab eine
der Anlage selbst
sorgf~ltigen
gibt,
g r S B e r e n Un-
Doppelrechnersystem
mittleren
99,73 % und eine erkennen,
g e n muB, um e t w a e i n e
Ausf~llen?
Problematik
d i e Dr.
1967 b e t r i e b e n e s
Einzelrechner
9 9 , 5 ~ bzw.
k a n n man k l a r lichkeit
eigene
von 99,92 % und eine
458 T a g e n ,
PatentlSsung
hat.
Oktober
Die beteiligten yon
System seine
Zahlen dienen,
keine
in einem einzigen
d e r C h e m i s c h e Werke HUls AG a u f
VerfUgbarkeit von
Erfahrung
Uber ProzeBrechneranwendungen
mitgeteilt
Ein seit
dab es m i t S i c h e r h e i t
die weitere
sind,
ertragen Wer f i l l t bei
vorliezu k~n~fter
den einzelnen
Gefahrenquellen sol1
vermerkt
Zuverl~ssigkeit
bei
aus GrUnden der werden. und die
Preis-
wUrdtgkeit Strategie einer
Reihe
st~ndig den" der
heutigem
Zum Schlu8
ihre
Vertreter Stand
sehr
der
gute
zur
isolierten
das
und i h r der
Aufgaben
Gesiehtspunkte.
eines
Funktionen als
aus
zwar selb-
"WohlbefinPartners auf.
ob d i e s e s
tuft
Es h a t System fur
hat.
auf die E i n s t e l l u n g
der G e s e l l s e h a f t
hierarehisehe Gesamtsystem
eigenes
Bei Unwohlsein
~bernahme
Aussichten
andere
ortsgebundene
Dinge den Anschein,
darf ich n o c h m a l s
ieh w d n s c h e
die
eine besteht
Resultate
"Chef" weitergeben.
aus der "Sieht" keine
aber
l~Bt
ausgedrUckt
yon Kleinrechnern,
Chef einen Zukunft
Kleinreehnern
Vereinfacht
erledigen,
an e i n e n
naeh die
von sog. zu.
zurfiekkommen.
zum R e c h n e r - P r o b l e m
Sie sehen,
Wir h a b e n g e m e i n s a m e
uns allen GlUek und Ausdauer,
die Probleme
es gibt
Probleme,
und
erfolgreieh
zu bearbeiten. Der Tagung selbst ten
einen
wiinsche ich
zufrtedenstellenden
einen
guten
Verlauf.
Erfolg
und a l l e n
Beteilig-
Tendenzen Prof.
in der Prozessrechnerteehnik
Dr. Heinz Gumin
Einstmals
aus einer stattlichen
schrumpfte
der Prozessrechner,
des Prozessrechners, kreistechnik, den Umfang
dank der erheblichen
im Verlauf yon weniger
eines Schrankes
Steuerungen, Komponenten
zur Miniaturisierung
von Komponenten
wird sich in den vor uns liegen-
bestehende
komplexe,
schliesslich
mGssen.
Bausteine
reduziert
Kernspeicher
im wesentlichen
eine Weiterentwicklung Ersatz
erlangen,
realisierte
einer Realisierung -MikroprozessorenIndustrieelektronik
in gewissem
Software
bisher aus KostengrHnden sein,
zu ersetzen,
einschliesslich
Halbleiterspeicher.
immer preisg~nstigerer
Rechnerbausteine
des Prozessrechners
in die
Bisher noch festverdrahtete
in zunehmendem Masse durch Mikroprozessoren Sinne gegenl~ufige
zu beobachten.
sten for Software
bleibt von dieser Ent-
Stellen yon Interesse
welter beschleunigt.
Inwieweit
absehen.
durch Hardwaremodule
wird die Integration
werden
Ein zumindest
ist erkennbar.
dureh mikroprogrammierte
Durch die Verf~gbarkeit
Basis ar-
auf dem Prozessrechnerge-
Die MSglichkeit,
Abl~ufe
weimhen
Magnetband)
erfahren.
sich noch nicht
Hardware/Betriebssystem
wird an verschiedenen
Eine
Datendichte
fGr Anwendungen l~sst
wicklung nicht unberUhrt.
werden
Platte,
dutch Halbleiterspeicher
Die Schnittstelle
Funktionen
auf elektromechanischer
(Trommel,
bezGglich
andere Speicherprinzipien
in Software
erhalten blei-
wird er aber doch dem Halbleiterspeicher
Die heute
bier Bedeutung
wird auf werden.
selbstverst~nd-
Der schon h~ufig totgesagte
beitenden Hintergrundspeicher teilweiser
aus einer
Ger~t Prozessrechner,
wird zwar sicher noch einige Jahre als Arbeitsspeicher ben,
Tendenz
ersetzt.
ist auf dem Gebiet der
Bei sinkendem Hardwareanteil
am Gesamtaufwand
auf
z.B. bei NC-
nur noch eine yon mehreren
bleibt die Speichertechnik
lich nicht ausgenommen.
Jahrzehnten
dar.
Das ursprGnglich
eine geringe Anzahl hochintegrierter Von dieser Entwicklung
der Schalt-
In vielen FAllen,
eines Schrankes
den Jahren weiter fortsetzen.
die Zentraleinheit
Fortschritte
als eineinhalb
zusammen.
stellt der Prozessrechner innerhalb
Diese Tendenz Vielzahl
Zahl yon Schr~nken bestehend, genauer gesagt,
machen die Ko-
fGr eine Prozessrechneranlage
heu-
te bereits mehr als 50 % aus. Dies ist nut zum Tell dutch die sin-
i0
kenden Hardwarepreise immer komplexer;
zu begrGnden.
die Programmpakete
Die zu 16senden Aufgaben wurden nahmen dementsprechend
an Umfang
ZU.
Die Aufgabe
fGr die Zukunft kann nun nicht darin bestehen,
te schon recht umfangreichen
Programmkomplexe
durch blosses Hinzu-
f~gen neuer Aufgaben noch weiter zu komplizieren. Ans~tze
zu einem streng modularen
intensiv welter verfolgt werden. strukturen
zu kommen,
freiheit
ausgetestet
Ein wesentlicher
Bereits vorhandene
Aufbau der Programmsysteme Das Ziel muss
sein,
zu
vertretbarem
mGssen
Programm-
die in ihrem Aufbau Gbersichtlich
mit zeitlich und wirtschaftlich
die heu-
bleiben und
Aufwand bis zur Fehler-
werden kSnnen.
Grund fGr den hohen Softwareaufwand
ist wohl darin
zu suchen,
dass auch heute noch der grSsste Teil der Prozessrechner-
programme,
insbesondere
geschrieben
die Echtzeitprogramme,
werden mGssen.
in Maschinensprache
Dies ist eine zeitlich recht aufwendige
und fGr den Ingenieur ungewohnte
Form der Formulierung
seiner Pro-
bleme. Folgende
Ans~tze
zur LSsung dieses Problems
sind zu erkennen und
mGssen welter ausgebaut werden: -Schaffung ben
einer prozedurorientierten
-Formulierung Aufgaben
Sprache
von Standardprogrammsystemen
-Schaffung von Projektierungshilfsmitteln gel~ufigen Form, die ihm das eigentliche ersparen Die Schaffung ben,
einer prozedurorientierten
als Gemeinschaftsarbeit
und der Anwender.
haben
von Herstellern
in einer dem Ingenieur Programmieren weitgehend
Sprache kann nur Sinn ha-
aller Interessierten,
Ihre Anwendung
auch internationaler
Zielsetzung
fGr h~ufig wiederkehrende
der Hersteller
Hier kann es sich nicht datum handeln,
Sprache mehr zu schaffen. mSglichst
fGr real-time-Aufga-
Basis durchsetzen
sich bereits Ende der sechziger
und Hochschulinstituten
zu ~hnlichen
Teams
Die Arbeiten
fGhrten
in europ~ischen
eine
muss sich auch auf breiter, lassen.
Unter dieser
Jahre Fachleute
zusammengesetzt
und Kontakte
L~ndern und in den USA geknGpft.
zu Spezifizierungen
der Prozess-Sprache
Sie wurden dutch Mittel
des Bundes gefSrdert
±m Rahmen des Projektes
"Prozesslenkung
PEARL.
und laufen seit 1972
mit Datenverarbeitungsanla-
gen", fHr das die Gesellschaft f~Jr Kernforschung die Projekttr~gerschaft dbernommen hat. Eine andere MSg!ichkeit zu Arbeitsvereinfachungen Schaffung yon Standardprogrammsystemen gaben° Die Messwertverarbeitung,
zu kommen,
ist die
fdr h~ufig wiederkehrende Auf-
insbesondere in so komplexen Prozessen wie
dem konventionellen W~rm~kraftwerk oder dem Kernkraftwerk,
bietet
sich fGr ein solches Unterfangen an. Die Erfassung yon Analogwerten, ihre Pr~fung auf gleitende oder feste Grenzen, die Weiterverarbeitung zu Kennwerten ist ein gutes Beispiel hierfGr. nalverarbeitung, der StSrungsanalyse ben liegen die Dinge ~hnlich.
Bei der Bin~rsig-
oder bei Protokollierungsaufga-
Es kommt dabei darauf an, einmal die erforderlichen Programmbausteine zu schaffen und zum anderen ein Generatorprogramm zu erstellen, das die fdr eine besteimmte Anlage ben~tigten Module unter Ber~cksichtigung der erforderlichen Mess-Stellen automatisch zu einem Anwenderprogramm zusammenbindet.
Die Aufgabe des Projektierenden be-
steht dann z.B. bei der Analogwertverarbeitung
darin, in einer Mess-
stellenliste alle abzufragenden Mess-Stellen zusammenzufassen,
die
erforderlichen Parameter (z.B. Crenzen) festzulegen und die gewiLnschten Programmbausteine auszuw~hlen. Eine WeiterfHhrung dieses Gedankens besteht darin, zu einem Verfahren zu kommen, das es dem Ingenieur erlaubt, ohne die Kenntnis einer Programmiersprache unter Beachtung einer relativ geringen Anzahl yon Vereinbarungen,
Automatisierungseinrichtungen
dardprogrammsystems
zu projektieren.
mit Symbolen" bezeichnen. rungseinrichtung, fGgt, die wiederum
im Rahmen eines Stan-
Man k~nnte es als "Programmieren
Dabei wird die Struktur der Automatisie-
z.B. ein Regelkreis dutch Haftbilder zusammengeProgrammbausteinen
entsprechen.
bildern sind die gewiinschten Parameter einzutragen.
In den HaftDie weitere Be-
arbeitung ist Routine und kann yon weniger qualifizierten Kr~ften ausgefGhrt werden. Softwaresysteme nach diesem Verfahren wurden von uns mit Erfolg auf verschiedenen Gebieten eingesetzt, z.B. - automatisches An- und Abfahren yon Dampfkraftwerken -
Kdhlmitteltemperaturregelung
an einem Druckwasserreaktor
12
-
Regelung
einer Zement-RohmGhle
Wenn man von speziellen Grossteil
Einzweckaufgaben
der bisher verwirklichten
charakteristisch,
der eine Vielzahl
sich wohl nur aus der Historie lagen im Preis
so hoch,
zu rechtfertigen st~nden
so ist fur einen
Anlagen der zentrale
Rechner
yon Aufgaben hat. Dies l~sst
erkl~ren.
Die ersten Prozessrechner
dass ein Einsatz wirtschaftlich
vielfach nur
war, wenn eine grosse Anzahl von Aufgaben,
auch kommerzieller
Komplizierte
absieht~
unter Um-
Art, damit gelSst wurden.
Programmpakete
und hohe VerfGgbarkeitsforderungen
waren
die Folge. Als Folge der inzwischen
eingetretenen
Preisreduktionen
ware steht dem Einsatz von MehrrechnerlSsungen
fur Hard-
in hierarchisch
stuften Systemen vom Preis her nichts mehr im Wege.
In solchen An-
ordnungen hat ein einzelner Rechner nur noch Teilaufgaben Damit ergeben
sich neue M8glichkeiten,
ge-
zu 18sen.
das Problem der VerfGgbarkeit
anzugehen. Einen erheblichen
Einfluss
hat das Aufkommen
der Warte,
zess ausgefibt.
Kamen doch Mittel der Kommunikation
zum Einsatz,
die fur das Wartenpersonal
Sichtger~te).
Ihre konstruktive
nicht abgeschlossen. bietung,
werden
hat erst begonnen.
einer
Zusammenfassend stellt,
gen Komponenten Wichtige -
dem Betreiber werden
Anordnung
ist noch
InformationsdarDarstellung
auf
der Athropotechnik
der Ein-/Ausgabemedien
Zukunft
erwarten,
die die Halbleitertechnologie
zu einer Integration
des Prozessrechners
der Industrieelektronik
mGssen technisch
vernGnftige muss
dass es
zur Ver-
mit den Gbri-
zu einem Gesamtsystem
werden dabei zu beachten
- die Abwicklung beim Hersteller siert und vereinfacht werden -
in die Warte
zur sequenziellen
darf man fur die absehbare
Einflussgr~ssen
mit dem Prozess (Blattschreiber,
parallelen
Neue Erkenntnisse
auf
Mensch/Pro-
in der Warte der Zukunft finden.
mit den neuen MSglichkeiten, fUgung
Eingliederung
"menschengerechten"
ihren Niederschlag
Schnittstelle
neu waren
Der 0bergang v o n d e r
z.B. Mosaikschaltbildern,
Sichtger~ten bezGglich
der eigentlichen
des Prozessrechners
die Gestaltung
kommt.
sein:
L~sungen
angeboten
soweit als mGglich
systemati-
die Systeme selbst mGssen in ihrer Kombination aus Hardware und Software ein Maximum an Zuverl~ssigkeit, 0berschaubarkeit, Inbetriebsetzungsfreundlichkeit und Bedienbarkeit bieten.
HAUPTVORTR~GE
ORGANIZATION OF SOFTWARE FOR MULTICO~UTER PROCESS CONTROL S Y S ~ M S by James D. Schoeffler Systems Research Center Case Western Reserve University Cleveland, Ohio, U.S.A.
Abstract The trend toward multiple computers for process control applications is accompanied by the introduction of line sharing input/output systems and microprocessors for general use.
As a result, many different structures for multiple computer pro-
cess control applications become practical.
Software costs are still dominant how-
ever, and it is important that any multi-computer structure
be
supported by soft-
ware which is compatible with process control objectives and economical to implement. Of particular importance is the need for an integrated data base and graceful degradation in case of failure.
The organization of process control software for
single computer systems is used as the starting point to evaluate the desirability of various software organizations for several multi-computer ring-connected systems. Compatibility with line-sharing I/0 systems is discussed.
I.
Introduction Many process control applications make use of several computers to carry out
portions of the task rather than using a single large central computer.
This trend
can be traced to several motivations: i.
The application can grow by the addition of new computers to control additional process units without major upset of previously installed systems,
2.
Decreasing computer mainframe hardware costs allow smaller applications to be cost justified than were possible in the past and these tend to proliferate.
3.
Software costs are lower in a dedicated, smaller installation.
4.
Smaller applications permit faster implementation and quicker payback.
5.
Multicomputer systems can degrade gracefully in case of failure of any computer in the system,
The use of multiple computers is not equivalent to the paralleling of single process control computer systems.
There is usually the need for an integrated
data base for report generation, operator communication~ overall plant control, etc, Furthermore, the desire to gain reliability often leads to the partitioning of tasks
15
computer with each co~puter assigned to half the process, The use of multiple computer systems in this way further implies that software organization must be compatible.
Hence, process control software for multiple
computer systems is often organized differently from that used in single computer systems. A further complication is the trend toward line sharing I/0 systems, input/ output devices connected in parallel to a bus which in turn is connected to the computer itself.
Sharing of I/0 is not necessarily best done by connecting com-
puters differently.
The practicality of various network-like connections of com-
puters for process control is more assured today because of the availability of very low cost microprocessors.
These computers whose size is essentially that of a
single small printed circuit card permit many different configurations to be realizedo
The single overriding conslderationp however, is software oganization.
A
structure which is practical must be one for which software implementation is economical. The objective of this paper is to describe the alternative structures for multieomputer process control systems, and examine the software organization of process control software for single computer systems is first discussed. computer network structures are discussed to
Then various
determine how existing software is
compatible with that found successful for process control applications.
Finally,
the impact of line sharing I/0 systems and microprocessor networks on this software organization is discussed. II.
Process Control Software Structure for Single Computer Systems Process control applications using only a single computer vary a great deal
in size and complexity, but are usually organized around a real-time executive control program.
However~ such systems further divide into two classes: those in
which the only standard software is a general purpose real-time executive control program, and those in which special purpose application packages, higher level languages, and other facilities unique to process control are imbedded in the overall real-time executive 1,2.
The two approaches have differing advantages and dis-
advantages and are discussed below. 2.1
General Purpose Real-time Software for Process Control One school of thought argues that the variety of applications in process and
manufacturing control dictate the need for a general purpose real-time executive which is capable of supporting user-written application programs (Figure 2.1). Furthermore, applications differ so much, that application programs have widely varying response time requirements, S~zes, communication requirements, etc. so that the only economic solution is to provide a very good executive which can support any specific set of application programs.
The actual implementation of an applica-
16
tion then involves the user partitioning of programs
his application
can be written to cooperatively
in such a way that a set
carry out the application.
tive provides all the facilities needed to control priority, management,
interprogram communication, ~ 3,4,5,6 trol applications
The execu-
response time, memory
and other critical aspects of process con-
The resulting real-time executives have evolved into a variety of forms but all have five problems to contend with, and the way these problems are solved defines the characteristics interprogram 2o1.1
of these
communication,
executives. input/output,
They are: memory management, and interfacing
scheduling,
to application programs.
Memory Management It is unlikely that the set of programs making up a process control application
will always be resident in the main memory and hence there is a need to choose a way to manage memory when there is a conflict between tasks scheduled to execute.
Clear-
ly fast response tasks cannot be in bulk storage at the moment they are scheduled to execute if a fast response is to be guaranteed. cannot be permitted ly overcome
to remain arbitrarily
Furthermore,
low priority tasks
long in memory for they can then effective-
the higher priority of tasks in bulk soorage which cannot get into main
memory at all.
Buffers for I/0 devices pose a similar problem for the overall
buffer space in main memory is normally limited. task to fill I/0 buffers is tantamount
Hence,
to permit a low priority
to preventing higher priority tasks from
proceeding° To guarantee adequate response time for tasks, priority is usually used and the memory management
scheme must be such that lower priority tasks cannot delay or lock
out higher priority tasks. Memory management
decisions are complicated by the ability or lack of ability
of computer hardware to dynamically relocate programs.
That is, it is not feasible
to run a program at an arbitrary location if the program cannot be loaded and run without extensive
change,
memory management
freedom°
Hence, position independent
code is necessary
for complete
Most short word length machines do not have the capability of machine independent programs or at least without sacrificing
generality.
Consequently,
are prepared to run in a fixed, known location in main memory. general spproaches
programs
This leads to four
to memory management.
First are those executives which assume all programs run at the same location in main memory and hence permit only one program at a time in memory. support priorities,
this program can be interrupted,
priority task rolled ino cution continues.
Later,
the interrupted program is rolled back in and exe-
The advantage of this organization
is that maximum memory space
is available for the program in memory s o larger programs major disadvantage
In order to
rolled-out and the higher
can be supported.
The
is that response time is slow -- the time to roll out and roll in
17 two perhaps large programs.
Furthermore,
I~0 buffers must be maintained
in memory
(or else the program cannot be rolled out until its internal buffers empty) and the rolled-in program may be blocked because buffers are full.
Further,
on the bulk storage channel is high in such a system for programs,
the load
are in effect
loaded several times. This organization permitting response
for memory management
critical programs
can be improved in some instances by
to be permanently main memory resident.
time because no buik-storage
transfer takes place when it is time to exe-
cute one of the high priority memory resident programs. less likely
(or maybe not even necessary)
program so that it can run to completion.
This implies that it is
to interrupt the non-permanently
resident
In these cases, the system is attractive.
A second form is to make use of overlay techniques
to permit the program
currently in memory to control the loading of other programs. an application
This improves
Thus, for example,
can be organized as a single program which in turn loads other tasks
within its area and passes control at the appropriate program then acts as both a memory management
time.
In effect,
and a scheduling
task.
the user
This is fea-
sible and useful in certain well defined applications where the response time is so critical that a general purpose executive cannot be trusted to respond correctly. However,
these applications
are usually associated with smaller systems, not the
larger ones for which general purpose executives A major disadvantage multiprogram, according
are attractive anyway.
of this approach is that the user program cannot readily
that is, transfer control from one task within itself to another
to some priority assigned to these tasks except by explicitly providing
test points within these tasks where time is checked,
etc.
This is rather awkward
in practice. A variation
on this form is to provide a scheduler within the executive but re-
quire the program to do the memory management.
In such a system, a set of tasks
might be loaded as one program with one task setting up task blocks for each of the task within that program° uling, transferring
Then the scheduler in the executive does all sched-
of control, etc.
med by the executive°
In this case, the tasks can be multiprogram-
All memory management
is the responsibility
of the applica~
tion programmer however. The fourth form of memory management permits multiple programs in memory at one time.
In this case, control can be switched back and forth as
priority requires and the system can be truly multiprogrammed. does not support position indepdndent locations,
to be resident
called partitions
can be resident at a time.
If the hardware
code, programs are designed to run in specific
(Figure 2.2).
Within a partition,
The option of interrupting programs
only one program in a partition,
rolling them out and rolling in a higher priority program is available systems.
However~
in many
in most cases~ it is observed that the limited resource is not
memory utilization but rather bulk storage channel utilization.
Hence,
it is de-
18
Multiple tasks cooperating
Working memory
to carry out a process control application Memory
Interprogram
~anagement
Communication
I/O Routines
Task Scheduling
Shared Subroutine:
Figure 2.1 Structure of a General Purpose Executive For Process Control Software
Working Memory programs in positi~pende~ Partition 1
[-
Z2 oo 4J.~ 4~
Partition 2
~m
M Partition 3
I
Memory Management Module
EE3
Working memory partitioned into N usually fixed partitions Figure 2.2 Memory Management
19
sirable to minimize use of this channel by assigning the same priority to all programs designed to run in a given partition. interrupted tasks.
This results in no rolling-out of
High priority tasks share one partition, low priority another,
etc. and system response time is guaranteed by multiprogramming and proper specification of number and size of partitions.
Note that this implies that a partition
size must be large enough to take the largest program of that priority. If the hardware supports position independent code, it is possible to dynamically allocate memory, that is, find room for a task when it is needed rather than pre-assigning it.
Except for the problem of fragmented memory, this form of memory
management is attractive.
Memory fragmentation is aggravated by the difficulty of
relocating an interrupted program since even position independent code picks up absolute addresses during execution and hence must be reloaded to the same memory location after it is interrupted and rolled out.
The most attractive compromise
is to provide a set of partitions most of which are restricted to one program at a time but with (usually) one partition which is dynamically allocated.
The latter
is used for less time critical tasks and to remove the burden of relating size and priority. 2.1.2
Interprogram Communication The tasks of a process control application communicate with one another ex-
tensively both by sharing data and by scheduling one another.
Clearly the latter
requires some scheduling capability within the executive as discussed below. former is a thorny problem in many executives, however.
The
Data can of course be
shared by allocating it to a permanently resident memory area (e.g., Fortran COMMON) but this scheme is limited to smaller data bases and those which are common across all programs.
More generally~ modern executives provide a file system which per-
mits common data bases to be maintained in bulk storage with access by different programs on a controllable basis (Figure 2°3).
The advantage of large areas for
interprogram communication is partially offset by the longer
access time but this
is necessary for many higher level process control applications such as those involving plant scheduling where
the data base cannot be maintained in memory.
Validity and safety of the data base is an important reason for using a good file system for it is possible to let the system maintain audit trails and error recovery systems°
In contract, application programs must necessarily be respon-
sible for the data base if it is built and maintained by them in permanent memory. A compromise which increases response time is available in
several executives,
namely the capability of transmitting a message from one task to another which contains a limited amount of data.
For small intercommunication tasks, the message
transmission scheme is useful and increases the response time of the tasks since it is essentially done through main memory.
Parallel tasks can be synchronized
through message transmission, a useful job for interprogram communication.
20
/
File System
/ ~
~
Fixed mem°ry COMMON area
~
L Y
1
L-T"" Message TransmissionRoutines ~ / "
~
E~xe Schedule
Figure 2.3 Interprogram Communication low priority
medium priorit~ high priorityS: I: R:
S
I
i i ' Ri I, Ri
II
I I S
I i I
: i R
I
R
I I I B U C
I.'........ " I' 1 I I , , S B Ut C I
scheduled to begin execution at this time interrupted to perform higher priority task resume after interruption
I
............time C ~-
~ time
~- time
B: I/O block U: I/O unblock C: complete execution
Figure 2.4 Scheduling multiple tasks in main memory Via multiprogrammingwith priority
21
Another i~porta~t form of interprogram communication is the sharing of subroutines both for I/0 and communication with modules in the executive (everlay~ scheduling~ etc~) (Figure 2.3).
In a multiprogramming situation, interrupts can
occur during the execution of these shared routines and the problem of re-entering a shared subroutine must be solved in the executive.
There are a number of ways to
handle this important interprogram communication problem including: i.
Lockout of another users when a subroutine is busy
2.
Making a subroutine re-entrant so re-entrancy is permitted
3o
Duplication of the subroutine (one copy per program needing it)
4o
Inhibiting of interrupts during execution of shared subroutines.
For subroutines not likely to be called by programs simultaneously resident in main memory~ duplication of the subroutine is by far the simplest solution° Since one copy need he present anyway, no penalty is paid in main memory by providing a copy to each program which calls it except in the rare situation when both programs enter memory at the same time.
At least there is no re-entrancy problem.
This is often done for scientific subroutines and other subroutines which do no I/0 or executive calls.
This solution is not feasible for routines which do I/0 or
enter the executive and in these cases many executives either lock out other programs from re-entering when the subroutine is busy or else inhibit interrupts during the execution of the subroutine.
Where the hardware makes re-entrant sub-
routines economical and efficient~ it is sometimes more desirable to make them reentrant and this also is done. 2.1.3
Scheduling Most process control applications require priority scheduling of multiple tasks.
In fact, to achieve adequate response time and utilization of co~mnon resources (I/0 devices main m~nory and bulk storage channels) it is usually necessary to multiprogram them also (Figure 2.4).
Thus, the scheduler module must be capable of
switching control from one task to another, restarting tasks when requested I/0 operations have completed, etc. (Figure 2.5)°
In a limited memory management en-
vironment, there is little scheduling to be done but in the more general schemes, scheduling is important.
The decision of the scheduler is simply either to run a
program to completion before switching to another task or to interrupt and switch context.
If the bulk storage channel is the limiting resource, it is co~mon to
run to completion which in effect is enforced by allocating the same priority to all programs running within the same partition (Figure 2.6)°
Even if different
priorities are assigned to programs prepared to run in the same partition, it is common to run the one in memory to completion before selecting the next scheduled highest priority program to run in that partition.
This minimizes bulk storage
channel usage and with proper application program design and choice of priorities usually leads to adequate response time without locking up the system.
Moreover,
22
queue of tasks waiting for execution (all lower priority than currently executing task)
currently executing task
newly scheduled higher priority task
inttrr t
Figure 2.5 Scheduling via Task Swapping memory contains one task per partition partition
partition
I
partition /
queues of tasks waiting to execute in specific partitions - - ordered by priority
I •
Scheduler
I multiprograms tasks in memory and maintains queues of waiting tasks
Figure 2.6 Run - To - Completion Scheduling of Tasks Within Partitions
25
the executive scheduling algorithm is simpler. As mentioned earl~e~, some e~ecutl~ves leave the 8chedulin~ to the user on the grounds that it may be too critical in some applications to use general purpose algorithms (Figure 2.7). to the user.
This is less co?anon than is leaving the memory management
Of course all executives have subroutine calls which permit an appli-
cation program to schedule itself and other application programs in a rather flexible manner.
Scheduling by the clock is most common.
scheduling which is available on some°
Of some interest is event
In this situation~ an application program
can schedule itself or another Program for execution when a logical combination of events occur°
l~he scheduling module is responsible for monitoring these signals
and actually scheduling the tasks waiting for a certain signal.
This action is
somewhat similar to a program which is blocked waiting for an I/0 operation to complete.
The completion is monitored by an I/0 routine which in turn notifies the
scheduler to unbloek the waiting program. 2.1.4
Input~output Routines With multiple tasks competing for shared resources such as I/O devices~ it is
necessary for an executive to provide I/0 handlers and drivers as well as I/0 subroutines to interface to the application programs.
The drivers are responsible for
control of the hardware device itself, responding to interrupts to output or input data and signaling the 1.0 subroutines when a requested input-output operation has been completed. grams.
The I/0 subroutine is responsible for interfacing to the user pro-
The main tasks are to provide information about the state of the I/O device
(busy or not, for example) and to pass I/0 requests either to the driver or to a queue (Figure 2.8). Alternate methods of operation include buffered and nonbuffered requests.
The
former pass the requests to a queue if they cannot be immediately fulfilled and return control to the user or application program.
The latter also queue the re-
quest but do not return control to the application program until the operation is complete.
The advantage of the latter is that I/O operations do not have to be
multiply buffered so that minimum main memory area is used for I/0. tage is that tasks block waiting for I/0 and
The disadvan-
hence their response time can be in-
fluenced significantly by lower priority tasks utilizing I/0.
Many executives pro-
vide limited capability for control over I/O devices arguing that a general purpose solution is less than adequate for process control applications.
Instead the
burden of controlling competition for I/0 devices is left to the user, usually by suggesting that all ~/0 be done by a single program whlch then is in a position to judge what should be done first and how.
Process operator communication is
the most common example here with all messages funneled through one program.
The
most frequently cited example where this pays off is the error message which is generated repeatedly by an application program.
The single operator communication
24
Subtask 1 one
Subtask 4
Subtask 2
program
I
Subtask 3 Main control task
1
Overlay routines
Task control blocks created by main control task I Executive ~_~ multiproI gramming / schedule for t tasks in memory
l f
I sT1
J
t ST3
t[ j--I ST 2
Figure 2.7 Run-to-completion task with subtasks and Local scheduling
t ~ '~
i l
~,o jl
Formatting Task
l Tosk 2 ......I
I !
|
L orivtr 1 { ......... ~
I Devic ~
I ~
~
1
L~~~ I/O buffers if ~eparate from task
Figure 2.8 Organization of I/O Routines
25
program can recognize such repeated messages and delete them whereas the application program may find it difficult to do this. Since I/0 subroutines are used by many different programsp they generally must solve the re-entraney problem,
In particularp they must either be re~entrant
or else lock out multiple entry during their critical portion.
Both solutions
are used in conventional general purpose executives~ 2.1o5
Application Programming Languages and Program Preparation
Any general purpose executive will support application programs written in a 7~13 , All exe-
higher level language as well as those written in assembly ±anguage cutive and I/0 functions
are provided by subroutine calls into the system.
The
major difference in the executives lies in the way higher level languages llke real~time Fortran do I/0,
Often the choice of buffered or unbuffered I/0 is not
available unless the user drops into assembly language. Although real-tlme languages such as Fortran have been extended considerably during the past few years, system implementation languages (system programming Languages) have not become coTanon on minicomputers9
One would expectp however~ them
to become more common in the future with (possibly)
the executive itself written
in such a language for ease of tailoring on the part of the user.
This would
eliminate many of the disadvantages of the general purpose executive alluded to above since optional scheduling and i/0 strategies could be added or deleted with a simple recompilation of the operating system,
Such capabi!itywould go a long
way toward eliminating the disadvantages of the general purpose executive for realtime process eo~Rtrol applications, Experience with general purpose executives is improving every year.
The most
notable failing in the past has been the revision of executives from various vendors with new executives incompatible with older ones.
It still happens that an
executive for a system without bulk storage may differ from one supporting bulk storage.
Nonetheless, the value in perfecting good general purpose real-tlme exe-
cutives has been recognized and they can be expected to improve even further with time. 2.2
Integrated Packages and Process Control Executives The wide variety of designs of general purpose executives for process control
applications carries a message: namely, different applications require much different solutions to the memory management, interprogram communication, scheduling, and I/0 problems.
The second approach to process control software argues that the
specialized nature of many applications precludes the use of a general purpose executive without ectensive system programming for many applications.
On the other
hand, they argue that it is possible to identify and isolate certain widely used general applications and
produce special packages which handle these applica-
26
tions 1,2@
This is most common in the very time critical applications Cdata ac-
quisition, data point scanning, dizect digital control, sequencing control, etc.) and those applications which have a volume of data handling which swamps any general purpose I/0 system (most common in operator communication situations) 15, 16, 17, 18, 19
14,
In these situations, those portions of the application which are most critical are implemented with general purpose packages which then yield two very distinct advantages: I.
The application can meet its critical response or data volume requirements because the package is tailored specifically to that task.
2~
The general purpose executive need no longer be so general purpose because now the critical tasks are not carried out under its control. That is, it is no longer responsible for critical time response tasks or large volume I/0 requests or whatever~ and hence many of the simpler solutions to the memory management, interprogram communication, scheduling, and I/0 problems discussed earlier can be used.
Thus, if successful packages can be developed for critical parts of process control applications, simpler, more reliable executives can be used in conjunction with them to handle the non-standard parts of the application (which presumably are also less time or volume critical) (Figure 2°9)° The critical parts of process control applications are generally identified to be maintenance of a central data base (interprogram communication problem), precisely timed data acquisition and direct digital control (memory management and scheduling problem), error recovery (interprogram communication primarily), and general purpose operator communication.
Offsetting the advantages to the simpli-
fication of the executive is the large expense of such packages, necessitating that they be used again and again so that their cost need not be written off on one application° To achieve application independence, packages are usually designed to be table driven and to have complete control over any I/O devices they need.
Thus,
data acquisition and control packages handle all analog input and output with other application programs getting information from a common table.
This, of course, re-
moves the I/O driver and subroutines for analog input and output from the executive which couldnTt handle the volnme of small requests which would arise in a moderate sized process control system. Designing a package to be table driven means that the actual implementation of a specific the tables°
application of that package involves only the loading of data into This can be done either through off-line program preparation or
through on-line operator communication consoles
designed specifically for the task.
This leads to the general software structure shown in Figure 2,9 where the
27
communication between the various paekage~odules and the general purpose execu~ tire and the
application programs is through common tables,
Thus, the executive
must support good interprogram communication even though the inclusion of packages may have relieved the critical time and volume response requirements.
Most often,
the tables are divided between those which are main memory resident and those which reside in a general purpose file system belonging to the executive. The main memory resident tables must be present to insure fast respons~ o~ critical modules such as direct digital control packages ~ignre 2 . 1 0 b
A task ~s
a sequence of functions to be performed as for example in the acquisition of data from a given sensor.
All parameters, addresses~
data, names~ ere. associated
with a task are stored in one row of the table with one row allocated to eac~ task. There is a conflict in the design of the tables,
In order to simplify operator
communication, it is desirable to make the format of the table as fixed as posslb!e 17.
Thus, in a data acquisition application, several standard formatsmight
be permitted for various kinds of sensors (cog,, thermocouples qersus flow sensors[, On the other hand, generality demands that provision for inclusion of various non~ standard algorithms for special applications be made,
The net resnlt is perhaps
extra space left in standard formats to permit addition of constants~ data~ and parameters for nonstandard algorithms to be included in the
processing.
natively, links to dynamically allocated memory might be provided.
Alter-
In any case,
management of the tables and efficient utilization of all space in the tables becomes more difficult.
Another approach is to organize the table by function rather
than task (Figure 2.11) o That is, instead of executing a sequence of different functions for task i, another sequence for task 2, etc., function i is executed for all tasks requiring it, then function 2 for all tasks specifying it, etc.16~ This organization permits the storage to be associated with the functions rather than the tasks, and to be allocated only for those tasks specifying the function. Thus, format problems are alleviated at tbeexpense of fixing the sequence in which functions are performed independent of the task.
Certain combinations of functions
cannot be obtained this way easily but in general the method is effective.
Notice
that the need for control over the task definitions is dictated by the very important problem of operator communication.
If parameters and data are stored in non-
fixed formats~ a name-table structure must be used to locate them for display, change and other operator corauunication purposes.
The fixed format of the table
also helps in system documentation since the functions actually being performed can be easily recreated
from a copy of the fixed format table.
Error recovery
also is facilitated since periodically the table can be copied to bulk storage and cold start tables can be kept in bulk storage for special circumstances~ Memory management problems are alleviated with this arrangement because the critical programs are essentially self allocating and control themselves. same is true for the scheduling module°
The
The input/output portion of the executive
28
Task Name - List of functions, parameters,
and data
Task name - List Task name - List
~__[ Select next scheduled task
,I
I
Carry out those functions listed with appropriate data for this task r Modules used £o-carry out basic functions
I
Figure 2.10 Task Oriented Table Organization Application programs
o
interprogram communication I Communication area: Data, tables defining application
[ ~
General purpose exec: memory management scheduling interprogram commun. I/O routines System subroutines
II/O devices not~ Idedica ted to I I any package |
data ~- --~acquisitio~
A/D and
I D/A
II/O device
operator console package
l operator I console t ~/o
Figure 2.9 Organization of Integrated Packages With General Purpose Executive
29
is greatly simplified at least for tko~e dayica~ aGsociated with the dedicated application packages,
The cc~p$1catlon of operatoz ceI~munlcatlon is totally re~
moved from the exec~ti~fe, The r e ~ n g that it is common to s ~ l y
~f0 de, Ices are less ti~e critical so
51ock a task ~aklns an ~/0 request ~ntll the request
is completed~ rather than complicate the ~/0 ~outi~e with extensive 5uffering, etc. Since the time critical tasks have Been removed from the executive's control, little penalty is associated with this convention, A side effect of this organization is also apparent from Figure 2,9.
Since
the package which car~led out the application and the communication routines which build the application communicate through tables, it is not necessary that the language used by the application programmer (e.g., the operator or process engineer) be at all ~elated to the internal operation of the package. languages which are
That is,
attractive to certain industries or types of users can he
defined and translators written which load appropriate data into the tables. The same package can, therefore, be used in a variety of industries and by a variety of people with differing levels of computer and process control know-how by providing adequate languages and translaters,
This possibility also lends it-
self to an increase in the utilization and liftime of such packages, The package concept cannot he universally applied, however, due to the variety of applications in process control,
Yet the general purpose language and execu-
tive also have limitations as we have seen.
One other approach to these problems
is to provide a higher level language with sufficient generality to support special purpose applications but to interpret rather than compile the resulting programs in order to gain the advantages of the higher level language and at the same time the simplicity of the executives associated with packages.
That is, an
interpretor, although slower in execution than a compiled program, maint ins complete control over the time at which events and interrupts can occur.
Thus,
problems of conflict for resources, lockout of common files, re-entrant routines, etc. are easily and simply solved because the interpreter has complete control over the times at which control is switched from one program to another and the way in which subroutines are called and I/0 requested,
Multiprogra~ing
is facilitated
for switching can be made to take place at times at which registers do not have to be saved, etc,
Programs are no~ compiled and hence there is no problem about
posltion-independent code, As long as the speed of execution is adequatep the result is a greatly simpli ~ fled s~ste~,
Note also that programming errors are easily caught so that system
integrity is not threatened.
Certain languages such as extended basic and subsets
of Fortran have been successfully used in an interpretive~ode.
In most implemen-
tations, it is possible to document the program being executed by either reading the contents of main memory directly (if the program is stored in actual source code for~) or by passing it through a simple translator ~if the source code has
3o been manipulated to speed up the interpretation process~,
In either case, programs
are easy to debug ~nd change even on~%ne, With the ever i~creasing speed of mln~ce~puters, more ~nd more o2 this type of software can be expected mainly because the chief disadvantage [execution speed or throughput) can 5e compensated by using faster hardware,
~t Is common to find
such systems on mlnlcompute~ families whlchhave similar instruction sets but different execution speeds so that the user buys Just enough hardward to give him the throughput he needs, The combination of dedicated packages (especially for analog scanning and direct digital control) with interpretive languages is attractive because of the reliability of the resulting system and because there are many (small and large) applications which can make use of such software,
Function
1
Function
2
.......
Function
N
I Jt
~
•
\ i"
~List "which
~-- S e l e c t n e x t f u n c t i o n I out
of parameters and data to this function is applied to be c a r r i e
\i ApplY
L..--
this f u n c t i o n
..........
to all data l i s t e d
I Figure
Function
M o d u l e s to c a r r y out each basic function 2.11
oriented
table organization
51
III.
Multicomputer Systems Multicomputer applications in process control usually are organized in a
hierarchical or star-like connection with communication lines extending from one computer to several others rather than between all pairs of computers.(25-38) The hierarchy may have more than two levels but essentially the communication problem at any time is between pairs of computers.
In contrast~ much effort
is going into minicomputer networks in which a true message switching network structure is assumed.
In the network structure, communication can take place
between any pair of computers in the system and the messages may be routed through still other computers.
Although the network structure is not availa-
ble today in standard process control software systems, there is sufficient interest to indicate that systems suppliers and/or minicomputer vendors might produce such software for other applications and this in turn would lead to its use in general purpose process control systems. 3.1
Star Connected Multicomputer Systems Especially attractive in the star connected system of Figure 3.1 is the
possibility of dedicating the first level computers to rather standard funections with the attendant possibility of using standard application packages there perhaps even without any general purpose executive or at least with a greatly simplified one.
Examples abound in testing situations in many process
industries where test stands doing essentially identical operations are under computer control and where the second level computer is used to maintain the central data base, produce reports, etc.
In any case, as many options are
available in each machine as in single computer systems. is the need for communication software.
The major difference
These systems essentially extend stan-
dard process control or general purpose realtime software by making the remote computer look like an I/O device so that conventional I/O subroutines can be used for the generation and handling of communication between machines.
Thus
each machine connected to the second level computer in Figure 3.1 would be assigned a different logical device number and messages would be output and input just as though it were a disk file or other I/O device directly connected to the machine.
This has the distinct advantage of minimizing the effect of
the multi-computer system on the single computer software system. 3.2
The Cgmmunication Linkage Hardware interfaces to computers standardly provide for either direct or
switched network connection. (20, 21~ 22, 23) Communication can be either bit serial but is logically organized as a byte stream with bytes being transmitted either synchronously or asynchronously depending upon the speed of operation. The channel may be either full or half duplex (that is, capable of transmitting in both direction at the same time or in only one direction at a time).
The
32
I
Plant level
I
c°mputlr
I
direct~c~a~ne
s
Figure 3.1 Hierarchical Computer System
BID
for lines
POLL
remote
or terminals
ENQ> ENQ~.
SOH
ACK < NAK
.... STX .... ETB
......... ETX
Initialization
che~k
_ACK
,EOTz> ENQ ACK NAK SOH
= = = =
i
Message transmission
ACK
Termination
Enquiry Acknowledgement non-acknowledgement start of header
STX ETB ETX EOT
= = = =
Start of text End of text block End of text End of transmission
Figure 3.2 Control Character Oriented Transmission
53
actual hardware interconnection tion as implemented 3.3
is of less concern than the logical interconnec-
in the software.
Communication Protocols In order for messages
to be exchanged between two computers,
the receiving mode and one in the transmitting mode. means for synchronization
one must be in
Furthermore,
correctly interpreted.
In general,
be uniquely interpreted
to determine the state ot the communication
philosophies
of organization
control characters are necessary which can
emerge.
Two
in some standard code (eg ASCII, EBCDIC)
to define a subset of the allowable characters as con-
trol codes and use them exclusively
for this purpose.
The other point of view
argues that message contents cannot always be distinguished ters since arbitrary combinations
from control charac-
of bits can make up legitimate control charac-
ters and hence message structure should have some standard format. can be distinguished
line.
In the first, it is assumed that all communi-
cation consists of sequences of characters and hence it is possible
there must be
of the two machines so that bit patterns received are
if all messages consist of character
Clearly they
streams to be output
on standard i/o devices for example but cannot if messages consists of arbitraty data words. The most common example of the first communication nary synchronous
communication
line-control
procedure)
protocol is Bisync
(Bi-
which is used extensively
for communication between remote terminals and large computers and between computers themselves.(24) tems.
The code is also used for minicomputer
communication
sys-
The procedure assumes a set of control characters which are used to sig-
nal start and finish or portions of messages, tain requeBts,
etc.
header section, Initialization ledgement
involves establishing
that the receiving
and the termination section
communication
or
(Figure 3.2).
between terminals with acknow-
Next follows the text portion with
indicating when text ends~ error correction information begins~
should be returned etc.
to the control mode so that communication Of central importance
Finally termination returns the system can be established with another computer.
is the hand-shaking which goes on continuously.
message is terminated until the receiver has indicated error-free.
to cer-
terminal is indeed ready to receive a message and
that the proper terminals are communicating. control characters
responses
Each message consists of three parts, an initialization
the message text portion,
acknowledgements
synchronization,
No
that it has been received
Detection of an error is indicated and the message or a portion of
it is retransmitted.
Only if multiple tries fail to transmit the message correct-
ly is the communication
aborted and control returned to error handling procedures.
Error detection is very important and based on the assumed communication protocol as follows.
First, the unique control characters
the message which can be checked.
define a format for
Thus missing or garbled control characters
34
indicate an error.
Secondly,
control characters
the format assumes acknowledgement
after certain
(such as when a terminal is being polled to determine whether
or not it wishes to transmit) and failure to receive the expected control character within a reasonable
time is taken to mean a communication
the format is found to be correct, sage contents itself.
error occurred.
If
there remains the error checking of the mes-
This depends somewhat upon the code used but always in-
volves parity checking of the individual characters plus an overall message logical check (such as logical sum over all characters--logical ing--or use of an error detecting polynomial--cyclic
redundancy check-
redundancy block checking).
As mentioned above, detection of an error in the message causes a line turn around with a request for re-transmission
of the message or at least the last
block of the message which was error checked. The problem with the above schemes lies in the transmission of arbitrary data where control characters correspond this p r o b l e m w i t h escape)
to legitimate data.
Bisync handles this
a special mode in which the special character DLE (data link
is used as the only recognizable
mission is initiated by the transmission (data link escape-start
to text).
control character.
This mode of trans-
of the two character Sequence DLE-STX
From then on, any character is taken to be
data except the DLE character and it too is accepted as data if two follow one another in the text stream.
Finally this mode terminates when a DLE character
is followed by any character other than another DLE.
The second character
in-
dicates whether control returns to the usual mode, the message is complete, error has occurred,
etc.
The second organization control characters
an
for a communication
(mainly to synchronize
scheme is to use a minimum of
the communication
messages whose format is contained within the message itself
line) and transmit (Figure 3.3).
Thus
a header of fixed format can indicate the type of message and the length of the message so that the receiver can determine when the message has been totally received.
Error detection procedures are normally the same as above except that
there is necessarily less format error checking. The handshake procedure which communicates whether ornot the previous message was received correctly is not entirely trivial since the acknowledgement message itself can be received in error and hence require transmission. complexity of the software also depends upon the hardware interconnection
The in the
sense that a direct connection between two computers can be reversed quickly so that there is little penalty for transmitting handshakes being returned. a rather l o n g t i m e
one message at a time with only
On the other hand, the telephone network may require
for reversal due to the need for switching of echo suppression
filters so that overall bandwidth is effectively reduced by the transmission of short handshake messages.
The combination of a message and error indicators
for
55
Synchronizing control characters Start of message control character Previous message error state Fixed format header Message Message text
Error detecting characters Figure 3.3 Non-control character oriented message
system ] Interprogram~___~ 3ubr°utinesl ~ communication area and
application
\
\
file system
i single communication preg~m II
programs
~ _ , ~
to and from remote processor
Figure 3.4 Processor to Processor Communication
36
the previously received message can be combined effectively in this situation without great complexity. 3.4
Process to Process Co~m~unication The contents of the messages and the organization of the software determine
the generality and complexity of the overall system.
For example, messages may
be restricted to be processor-to-processor implying that one program in one computer can communicate with a single program in another computer (Figure 3.4).
In
the process control environment, it may be desirable to let any task in one computer eouununicate with any task or file or device in any other computer. case, it is necessary to have process-to-process communication.
In this
In effect, the
communication line is dedicated to one program in each computer in the first ease but shared among programs in the two computers in the second case.
The latter
situation is very desirable in software preparation and restart procedures in first level computers for a message might be transmitted to the second level computers to rean an arbitrary program or data file for loading into the first level computer after a failure has occurred. Process-to-process communication requries a structure in the message itself which is interpreted by the handler in much the same way I/0 from devices shared by many tasks is handled, including buffering or messages, requests, blocking of waiting tasks, return of control to tasks when a message is complete, etc. (Figure 3.5).
The tradeoff depends again upon the volume of communication involved
for just as it often pays to restrict use of an I/O device to a single dedicated program for operator communication or speed or response purposes, it may pay to funnel all communication through a dedicated task which knows how to handle special situations like downline loading of software, error recovery, audit trail building etc. As one would expect, a general purpose executive approach to process control software organization is most compatible with a general communication capability (process-to-process). (25, 26) One example of such software offers communication capability in three optional levels. ( 25 ) The simplest form permits only downline loading from a known area in bulk storage and hence is essentially equivalent to a bootstrap loader from an I/O device.
The advantage of quick
loading from another machine after a failure is very great.
Moreover, data areas
can be initialized with this level of communication package also.
In the cited
example, the software is actually the same size as the bootstrap loader (64 words). The second optional level is essentially a simple message communication system which extends the normal operator communication program to communicate with the remote computer.
Thus requests for executive operations (execution of tasks,
utilities, etc) may be made from the remote computer. appear remotely or locally.
Furthermore, output can
The communication system is not process-to-process
37
Interprogram communication area
~
application
system
and file system
programs
S
<2> .....
~/o request su~rout~z_~i<
communication ine , .driver ......
~X--
~
/
to and from remote processors Figure 3.5 Process to process communication
Computer
!
computer
1 RI = Ring Interface
RI
RI
computer ~7~~a~in Figure 3.6 Ring structured computer systems
e
38
in this case of course. The highest level option permits complete process-to-process conununication so that reading, writing, and creation of files, as well as program preparation and execution can be handled from any computer as though the remote computer executive and libraries and files were in the terminal computer.
The size of this
software is of course much larger than the 64 word size for the lowest level (about 4K in the cited example).
For a process control application organized
around general purpose executives, complete flexibility and freedom for program preparation, allocation of tasks to different computers, etc is obtained with such a system.
For a process control system structured so that dedicated tasks
run at the lowest level computer, such generality is not necessary and may be undesirable from a reliability point of view. 3.5
Ring Interconnect Multicomputer Systems A structure much different from the point-to-point structure is the ring-
structured network wherein all computers are connected into a ring-like form with a communication channel between adjacent pairs of computers (Figure 3.6). The advantage of such a system for process control lies in the installation costs wherein a single communication line runs around the process with computers connected as are generators on an electric power bus.
Messages are passed from
computer to computer in sequence, passing around the ring from source to destination.
The capability of any computer to coummnicate directly with any other is
offset by the delay time for messages to pass around the ring.
In such a struc-
ture, it is straightforward to implement either computer-to-computer or processto-process communication.
Of major concern is the communication protocol.
One such network, DCS (Distributed Computer System), uses a synchronous binary colmm/nication scheme around the ring with messages being sent bit serial and with a one bit delay in each computer interfaced to the ring. (39, 40, 41, 42) No one computer assumes control over the ring.
Rather the computers vie for the
shared resource, namely the capability of transmitting a message. Messages inserted onto the ring ~must of course be eventually removed.
Since
it is desirable to acknowledge receipt of a message, it is not convenient to have the receiver remove the message and replace it by an acknowledgement.
Rather it
is easier to let the message (or at least its header) continue around the ring with only a status change indicated by the receiver. status and removes the message.
The sender then notes the
This has the advantage that messages can be
broadcast to all processors on the ring but of course has the disadvantage that the bandwidth of the ring is not fully utilized.
Depending upon the speed, mes-
sage rate, number of processors, and the like, various tradeoffs can be made here. In general it is desirable when only a limited number of processors are connected on the ring.
In the ring-like line sharing systems discussed in the next section,
39
it is less desirable, and modified so that only the message header is circulated back to the transmitter.
Since the ring acts much like a shift register with
messages being shifted circularly, it is not clear how a message can be inserted onto the ring without destroying information already there. can be taken.
Three approaches
The first is to fix the length of messages and let blocks of this
length circulate around the ring either filled with a message or empty. Any processor finding an empty block merely inserts its message with appropriate control codes so that successive computers can recognize that the block is not empty and examine the message to determine if it is addressed to that computer (Figure 3.7). zation.
The use of revolving blocks has been termed a "lazy susan" organi-
Note that if the communication rate is very high for each processor, it
may be most efficient to permanently assign a block to each processor, which might simplify the interface.
Such an organization would be a true time division multi-
plexing scheme. A second approach is to permit only one processor to transmit a message at a time (Figure 3.8). the ring.
In this scheme, a control "token" or signal is passed around
Any processor can transmit a message when it receives the control token
by simply deleting the token, inserting its message on the output line, and discarding any input received while the message is being transmitted. terminated with the control token.
The message is
Thereafter that processor simply passes on any
bits received at its input terminals, until the original message returns whereupon it is deleted.
In this scheme, messages can be of arbitrary length since
no information can be behind the control token on the ring (all previous messages may result in the message returning to the processor before the end of the message has been transmitted.
If this is possible, that processor can not merely dis-
card input whi%e transmitting the message but must watch for its own message to return so that it can discard it.
This is the communication control scheme used
for the DCS system. The third scheme is that used in certain line-sharing systems discussed in the next section and uses inserted delays (Figure 3.9).
In order to insert a
message on the ring without destroying information circulating, it is possible to switch in a delay equal in length to the message length.
Then in between mes-
sages circulating, the ring can be conceptually broken, the delay (with the message to be added to the ring in the delay buffer) inserted and operation continues.
In effect:, incoming message bits or bytes are delayed while the new message
is added to the ring.
Of course in this scheme no other message can be transmit-
ted by that processor until the delay buffer is again switched out of the ring and this is feasible only when the delay buffer contains no message.
Thus if any
empty block is circulated around the ring, the delay can be switched out without loss of any message.
Then when that processor is ready to transmit another mes-
4O
i
C
C
C: C o m p u t e r M: Message filled block E: e m p t y block
'
any c o m p u t e r may
insert a m e s s a g e in any •
empty b l o c k
F i g u r e 3.7 "Lazy Susan" P r o t o c o l
Source deletes m e s s a g e w h e n it returns source generates m e s s a g e
Isource "I
[...... c i
i...... °...... .....
~ess~e ~/1/
[c
i
I/,,/17"21'It
I i
J
~o~o~ t
j d e s t i n a t i o n signals acceptance and copies the m e s s a g e w i t h o u t d e l e t i n g it Figure 3.8 C o n t r o l Token P r o t o c o l
41
sage, the message is inserted into that buffer and it is again switched into the ring in between two other messages on the ring. some processor to remove messages, mitting processor
As before, it is necessary for
either the receiving processor or the trans-
or some combination of the two.
In a ring communication
scheme such as this, process to process communication
can be rather easily implemented.
In particular,
the message format must clearly
contain the address of both the source and sender no matter how the communication system is organized.
In a rigid system, these addresses can correspond
to compu-
ters themselves or be composed of two parts, the computer number and the number of the process within that computer. process communication the appropriate
Thus processor-to-processor
or process-to-
is simply a matter of how addresses are assigned
sotware to control these messages,
do error checking,
(along with buffering,
etc). An even more general scheme which could be very significant trol software is used in the DCS system. particular processors
for process con-
Rather than associating addresses with
or even programs within a specific processor,
addresses can
be replaced by names of processes with no assumption at all about where the processes actually reside
(Figure 3.10).
is then to examine messages,
determine the process names corresponding
sending and receiving processes, whether~those face.
The function of each interface on the ring
and then determine
to the
(by table look up for example)
processes currently reside in the processor connected to that inter-
Once determining
that the process is in that processor,
the protocol con-
tinues as before when addresses were used. The advantages dresses.
of this scheme are in the dynamic binding of names and ad-
Tasks making up a process control application
side in any processor.
could conceptually
Files and I/0 devices could be separate.
re-
Communication
of data to a control tasks is a via a message with the name of that control process used as the destination.
Output from that control program is to an output
process via a message addressed by name.
Now system software can organized
that messages are used for communication between all processes within the same processor.
With this convention,
so
includin$ those
it is immaterial
(except from
a response time and reliability point of view) whether programs cooperating carry out an application As an example,
to
lie in the same or different processors.
consider a process control applicatiQn
quisition from an instrument
involving data ac-
(beta guage on a paper machine say), control compu-
tation, and output of setpoints to analog flow controllers
(Figure 3.11).
A
single paper ~mchine control would use only one computer with all computation done in that machine.
An application
involving many paper machines might call
for several computers to handle all the data acquisition tion portions of the application.
and operator communica-
The rate at which the control computation is
42
incoming character
outgoing character a
buffer
I
incoming character
""N.
l~~byte
-
outgoing
1
1 byte buffer
N byte buffer to hold message switched in between circulating messages and switched out when all null characters fill it Figure 3.9 Delay Insertion Protocol
Message to Named Process X
local processes
I I
1 I PrOcess
l <
in this
~
y~
A
L
~°m~5~ ~< y
~ S e n d it directly ~ to Process X
I Process ~L_ B
transmit it ~ on the r l n g ~ " ~
~
Ring
/
~k
[
Interface
\,c--7
%
~
megaton
,~
l list of
jloca~
--.<.o~~
I
1
.~ Copy i t and send to local process X
Figure
3 .i0
Use of Names Rather than Addresses In Messages
r
43
done however might be such that a single program could be shared for all the paper machines.
In this case, separate data acquisition tasks could be used for
each paper machine with all data being periodically transmitted to one control task (process) in only one of the computers.
In these two applications, messages
generated with names of processes would result in absolutely identical software and it would not matter where the control program was actually operating at any time.
The system could gracefully degrade if a computer failed (only the paper
machines whose data acquisition was done by that computer would be affected) and this would require no special software.
To be practical, such a software organi-
zation must insure that the time delay introduced with the communication system does not upset the need to guarantee adequate response for control applications. This is not easy to do if there are many computers in the ring as might be the case with an application involving many microcomputers each doing only a small part of the overall task.
DA C OP P
= = = =
This problem is discussed further in the next section.
data a c q u i s i t i o n p r o c e s s control process operator communication process p r o c e s s (physical) u n i t s
OP
.C m e s s a g e s to n a m e d r i n g if p r o c e s s e s
Ring
communication
<
t--
/
- -t --l
I
I
J-
....
[ m
! !
......
/~j
r
P
oA
system
-------------------/-~ - -~
t
!
destination circulate around are n o t in same m a c h i n e
............
f, P "t
Figure Examples
T
J
3.11
of D i s t r i b u t e d Software
Control
1 i
44
IV.
Line Sharing Systems The input-output
structure of conventional minicomputers
control essentially assumes a number of devices connected speed bus and that the devices,
used for process
in parallel on a high
or at least their controllers,
to the machine so that the transmission
are very close
time along the bus is not appreciable.
This leads to computers with space for device controllers as an integral part of the machine itself.
Process control applications
generally need a different
structure however for the location of the computer and the locations of sensors and perhaps operator consoles and the like are often not close together. leads to the use of long cables cennecting It is not uncom~on to have installation
This
inputs and outputs to the computer.
costs for these lines to far exceed
overall hardware and software cost of the remainder of the system. A line sharing system may be the answer to this problem. is a bus-like organization
for input/output
(43)
Such a system
devices which operates at communica-
tion rates rather than the high speed rates found inside computer buses 4.1).
(Figure
The line sharing system is then connected to the computer itself through
a single interface. interface,
The result is that all input and output passes through one
removing all the controllers
its hardware structure.
from the computer iflself and simplifying
Since all devices are remote,
cate with the devices using communication-like installation
software drivers communi-
protocols described below.
The
cost is greatly decreased since only one cable need be strung from
the computer on which all devices
(and their bus interfaces)
Line sharing has many advantages
are connected.
even for a single computer
system.
Con-
nection of I/O devices to a central computer through a bus like communication system leads to standardized
interfaces and flexibility
in the implementation
of
computer control systems, easy addition or deletion of devices from a system, and ease of connecting remote I/O devices to a central system. tension of this idea to connect computers themselves system since most communication high speed memory-to-memory are comparable
It is a natural ex-
through the line sharing
links of any interest are too far apart for
links to be used and consequently
to those envisioned
communication
rates
for line sharing buses.
One line sharing system is organized around groups of analog controllers, inputs, and outputs. controllers
44, 45
For example, one group might contain up to 16 analog
in which three analog signals can be remotely communicated:
troller set point, the controller is useful in process supervisory analog inputs.
input, and the controller output. control.
the con-
Such a group
Another group might contain up to 48
The system is organized as though it were a communication with
standard format messages.
Messages are sent bit serially at a 50 kilobit rate.
Command messages are generated in length (Figure 4.2).
from the computer, with each command being 32 bits
Five of the bits are for error detection with the others
45
Computer
medium speed I communication< line ~ e [.....7.~.. /(bidirectional or / unidirectional) t interface , control ]e~s .....
~ _ _ _ ~ _ _ ~ ~
~ - ~ 7 I .... /_~
>[ I
device
[device
Figure 4.1 Line Sharing System
Analog module Command Word Channel address: Module Address: Selected input: Mode: Unused: Error detection:
4 4 2 2 i0 5
bits bits bits bits bits bits
Analog module Response Word Channel address: Failure detection: Signed value: Module identy: Unused: Error detection:
27 bits Figure 4.2 Line Sharing System Command and Reply Word Message Formats
4 1 13 2 2 5
bits bits bits bits bits bits
27 bits
46
completely specified and indicate addresses,
function,
etc.
Response to each
command is a single 32 bit message or a sequence of such messages.
Again,
each
bit field is in fixed format so that it can be interpreted by the hardware. Commands are available to input and output analog values~ read set points, and other standard operations useful in a process control application. of the limited nature of the communication,
Because
standard length messages are used
and response rates can be kept rather high despite the relatively low communication rate.
Thus to read one group of 16 analog signals requires one command
message and 16 replies.
This requires a total of 17 times 32 or 544 bits.
50,000 baud, this implies a minimum time of !l milleseconds. carries out this operation in 12 milleseconds head or deadtime exists in the communication nature of the messages
indicating that very little oversystem because of the restricted
(notice that in the communication
cribed, a number of synchronizing
systems previously des-
and control characters would have to be added
to each message along with hand shakes or acknowledgements cantly decrease
the communication
At
The system actually
rate).
which would signifi-
The only difficulty with a system such
as this is the eventual addition of new modules which then require new message formats for adequate communication. not general purpose,
That is, since the system communication
it is more difficult
is
to add different elements at a later
time. Other line sharing systems have been proposed, has been widely considered.
one of which,
serial CAMAC,
(46, 47, 47 ) The CAMAC system consists of a set of
crates such containing a number of devices connected together into a ring-like structure. ver.
The interface from the computer to the line is called a serial dri-
Associated with each crate is a serial crate controller or llne interface.
CAMAC is a message oriented line sharing system in the sense that each module has an address and any communication with a particular module is carried out by transmitting
a message to the appropriate
The line sharing system is organized
address. in the form of a ring with communica-
tion always taking place in the same direction aroung the ring starting from the computer interface,
passing through the crates in sequence and finally returning
to the computer interface. no time synchronization
Transmissions
of bytes.
around the ring are byte oriented with
Bits within a byte are synchronized.
Trans-
mission consists of a i0 bit sequence for each 8 bit byte with one bit leading and one trailing for synchronization is arbitrary.
purposes.
The time between successive bytes
The line acts somewhat like a shift register in that each crate
controller receives bytes at its input terminals and in return transmits bytes out of its output terminals. transmitted
Thus a message consisting of several bytes being
around the line is passed byte by byte from controller
each at its own rate.
to controller
Interfaces between devices on the line satisfy the RS-232
47
standards.
Three types of messages are used in the CAMAC system.
The first type is the conmmnd message which contains the address of the destination
(crate, module, and function)
the command is read or write. transmitted
together with an indication of whether
In the case of a write command,
to the addressed module is also contained
the data to be
in the message.
The se-
cond type is the reply message which is sent from a crate back to the computer interface and, contains its address along with status information
coded into one
byte and the requested data if it was previously commanded to read. The CAMAC system assumes a data width of 24 bits divided among 4 data bytes. Thus a co~mmnd message contains either 5 or 9 bytes depending upon whether the 4 bytes of data are contained in the message.
Similarly,
rains ~ither 4 or 8 bytes depending on whether
the 4 bytes of data are contained
in the reply message. system.
Two special bytes are used as control characters
The first is the null bytes
(all ones).
the reply message con-
in the
(all zeros) and the second is the idle byte
The null byte is used to signify the end of the message.
Transmission
of a command-write message from the computer to a module then
consists of the sequential
transmission
of 9 bytes along the line.
first byte is recognized by the addresses
When the
controller,
it passes this byte along
but then replaces all succeeding bytes by null bytes.
Null bytes are interpre-
ted by controllers
as no information on the system so that another controller
further downstream can replace the null bytes by a message of its own. increases the utilization of the line while still retaining mitting
the check of trans-
the original first byte around the ring until it returns to the origina-
ting device
(which of course then removes it).
If the computer had been sending a read message, 5 byte of information
to the addresses
crate.
dresses crate can send its reply promptly, is necessary,
it would need to send only
In order to insure that the ad-
and so that no queing of such replies
the originating message transmits the first four bytes of its mes-
sage and then inserts sufficient space for the addresses
idle bytes prior to its final null byte to leave
crate to insert its reply message.
the sequence of bytes being transmitted
originator,
Thus
As explained below, no device can
interrupt and transmit a message except after a null byte. prevents any other message delaying
(Figure 4.3).
to a device carries within itself space
for the reply to guarantee quick response.
the reply.
Hence this convention
When the message returns to the
the reply is in a known location and may easily be found.
The third type of message is a demand message which is analogous terupt
This
(Figure 4.4).
to an in-
A demand message contains 4 bytes and may be inserted into
the byte stream anytime a crate passes a null byte.
That is, any crate may in-
sert a 4 byte demand message in between other messages.
In order to be able to
do this, each crate has a switchable 4 byte delay capability built into it so
48
that it may switch in the delay any time it needs to insert a demand message. too insures prompt recognition and transmission tem.
This
of demand messages around the sys-
The demand message is interpreted by the computer to identify the crate, the
module, and the type of service requested. issued to carry out the desired service.
A read or write command can then be The design is very attractive for a line
sharing system especially the way the pile up of messages and replies is avoided. At a bit rate on the order of 20,000 bits/second,
a 9 byte message takes 90
bits, resulting in a message rate on the order of 200 messages/second, ble to a relay speed multiplexor
for example.
compara-
The software problems are similar
in that the line sharing system's response time is long compared to computer speeds and hence must be organized just as for interrupt driver electromechanical devices.
Thus requests for analog input from a device on the line must be queued
through I/O request subroutines with the appropriate program or task being notified when the request is complete. no software differences
At the user programming
level, there need be
at all since the way the request is carried out needn't
be reflected in the form of the call.
On the other hand, such a line sharing
system lends itself to a more regular usage as for example by dedicating
the line
to the control of a single program which then passes all input and output through a common table to other routines. Dedication of the line to a single task facilitates situations
including errors, devices off-line,
demand messages,
the handling of special
failures of devices,
unanswered
etc.
Future additions to line sharing systems may prove complicating tating the use of dedicated packages even more. of the line sharing system makes it difficult consoles,
special purpose controllers
factors dic-
The limited message structure
to support devices such as operator
(which may be dedicated computers them-
selves) and other devices which may be useful for online systems but which do not act like simple I/O devices with small amounts of data to be transmitted. voluminous
data transfer,
especially
Any
if it involves repeated messages and re-
plies, reduces throughput of a line sharing system quickly, and hence the rate at which I/O devices on the line can work.
A dedicated package could better con-
trol traffic on such a line and maximize its effectiveness. The line sharing systems discussed above are essentially a ring structure which was discussed in the previous munication organization.
section as a basis for a multi-computer
Because the elements on the ring are hardware devices,
there is little need for the generality of process-to-process Nonetheless,
com-
communication.
examination of the DCS ring computer network shows immediately that
it need not be restricted
to having computers
interfaced
to the ring.
any device which can obey the ring protocol can be connected.
In fact
Thus any I/O de-
vices including bulk storage units, bulk core units, operator consoles,
etc.
49
could beadded provided the interface is capable enough. Using microcomputers as interfaces makes these possibilities rather practical.
i
of h e a d e ~
~
.
~
/
Nulls L!
/
Reply Header I Text of ~ ] Reply I
/
/
~est.inat!o~-~
~
/ / ~ J < /_ ,
\ . \ \Device \
~
\~
V
Figure 4.3 CAMAC Insertion of Replies
Incoming charac%er ]
outgoing character if no delay
outgoing cha/l~acter /
delay path I
.....J
four byte delay Figure 4.4 Demand message inserted between messages Through use of four byte delay buffer
5o
V.
Microcomputer Networks in Process Control A microprocessor is a low cost, physically small computer which together with
its memory and I/O control fits on a small printed circuit board.
Although these
machines are a factor of 5 to 20 times slower than current minicomputers,
their
low cost make them attractive candidates for use in on-line control systems for two reasons: I.
49, 50
The control task can be divided among several microprocessors each of
which is dedicated to a small fraction of the total task.
For example, a direct
digital control application involving i00 loops might be divided among i0 microprocessor systems each of which controls i0 loops.
This leads to highly reliable
control hardware. 2. software.
The dedication of a computer to a task leads to simpler, less expensive Implementation costs far exceed hardware costs today.
Any approach
which decreases software costs then significantly affects overall system implementation costs. It is necessary for on-line control systems to maintain an integrated • data base in order to support operator communication and higher levels of control reliably and efficiently.
This requirement is in conflict with the desire to par-
tition the task and dedicate microprocessors to particular parts of the task. Thus it is necessary that the microprocessors be interconnected and that software systems be used which are efficient for the implementation of dedicated applications but which at the same time support an integrated data base. Unlike a network of minicomputers or larger computers used for process control, where the number of computers is relatively small, it is advantageous to use many microcomputers with each dedicated to a small part of the applications. This means that the cost of a general purpose communication package in each computer in the network becomes a serious consideration.
Should memory costs continue
to decrease and should microcomputer structures continue to evolve so that they can support large memories,
it is feasible to interconnect a number of microcom-
puters in the same way one connects multiple minicomputers today in a network for process control applications.
In this case, the software for such systems will
be similar to that described in the previous section. It is more likely that that will not be the case.
The advantages of decen-
tralization are lost when each component becomes critical to the overall operation or when the cost of integration gets too high.
Thus, the use of microcom-
puters as dedicated machines essentially implementing one of the applications previously described as suitable for packaging in special purpose software is more desirable and likely.
For example, rather than a package within a general
purpose computer implementing data acquisition, direct digital control, sequencing control, operator communication,
etc, it is feasible to remove the package
51
Minicomputer
I~"
[Mcf
MC ....I
[
~
Figure 5.1 Point to point microcomputer process control system
rl
52
altogether from the computer and implement that part of the application in a dedicated microcomputer.
The advantages of reliability, complete parallel opera-
tion, etc. are all gained this way.
Moreover, the general purpose computer gains
the same advantage as before, namely that the response time of the general purpose executive is less critical and hence that software can be simpler.
The dis-
advantage of course is that it is more difficult for tasks to share data and cooperate to carry out an application since they are in different machines. To minimize the cormnunication software requirements in the microcomputers, standard message formats and communication protocols can be adopted similar to those discussed for line sharing systems.
The software in the microcomputer can
be minimized this way provided that the generality of the fixed format messages is general enough to support the variety of applications for which microcomputers can be used. Thus microcomputer networks may evolve into the form shown in Figure 5.1 with co~unication between higher level larger computers and microcomputers organized in the point-to-point manner shown.
Of course process control applica-
tions imply much input/output to the microprocessor. connected to the microprocessor itself.
That figure shows all I/0
The same technology that makes the mi-
croprocessor feasible also leads to standard and more complex I/0 interfaces being available.
Reliability and interchangability then imply that the line shar-
ing system for connection of I/0 devices to a computer (mini or micro) is more probable in the future.
Thus the structure in Figure 5.2 results.
The essential
advantage of this structure is the separation of the communication between computers and the communication between computer and I/O device.
If the response time
and communication volume permits, the form shown in Figure 5.2 becomes desirable, a line sharing system for cor~nunication with all computers and I/O devices connected to the same line.
Of course in practice an application would use several
such rings rather than one for reliability purposes, with perhaps all rings interfaced to a higher level computer as shown.
The basic idea here is that a
standard line sharing system interface could be used for a variety of different configurations.
Note that this configuration does not preclude the use of I/0
devices connected directly to one computer. The essential software questions to be answered are twofold: I.
Can a line sharing communication protocol be developed which can sup-
port both microcomputers doing dedicated process control types of applications as well as instruments and controllers? 2.
Can process control software systems be developed which retain the ad-
vantages of integrated data base, multiple tasks for specific parts of process control applications and still be compatible with the varied configurations possible with microcomputers and minicomputers communicating through a general pur-
53
L
Minicomputer
J
line sharing interface/controller
J...........
IC: interface controller MC : microcomputer P: physical
process
~c I
Me I l
l,,~
1 r Figure
Process .............
5.2
Line Sharing Microcomputer System
Process Control
1
54
pose line sharing system? The feasibility of dedicated packages for process control applications mean that the critical need for configuration independent software is an integrated data base and it may be possible to organize the system so that ~his is feasible. The voluntary virtual space software system was developed with exactly these objectives in mind.
(51, 52)
This software system views a set of interconnected
computers as a multiprocessor, that is~ a number of processors operating off a single large shared memory.
The system assumes that application software (in-
cluding interpretive packages) may be implemented within an effectively unlimited memory space.
The actual task is then carried out by the differentprocessors
or cpu's executing in parallel.
This has the effect of eliminating most consi-
derations of size and computer structure from the package design. The large memory is called the virtual address space and is divided into eight sectors, each of which is subdivided into 256 pages. unit (ALU) or smallest page size is then defined. taken to be k ALU long. is one ALU in length.
A basic allocation
Pages in the kth sector are
Thus, sector one consists of 256 pages each of which Sector two consists of 256 pages each of which is ALU
long.
Finally, sector eight consists of 256 pages each of which is eight ALU
long.
Data or programs on any page are referenced by their virtual address
which consists Of a sector number, a page number, and a relative address or displacement on a page.
Because of the different length pages in the different sec-
tors, the total virtual address varies from 17 to 20 bits in length. The system is actually implemented by maintaining the virtual space on some bulk storage device in the system.
Each processor in the system has its own high
speed local memory in which it keeps only those few pages which it needs at any instant of time.
Thus individual processors reference pages which are usually
in their own local high speed memory.
Only when a page is referenced which is
not present in local memory is there recourse to the communication system connecting the computers and this then requires a swapping of pages between the requesting processor and the bulk storage.
Application packages are then construc-
ted in this virtual space and distributed to the various computers in the system by assigning pages from certain sectors to each of these computers. Intercommunication is facilitated by providing connection between the computers through which pages can be swapped back and forth.
The tradeoff between
fast response of a processor and its memory size may be carried out by varying the number of pages allotted to main memory.
For high speed, fast response sys-
tems, more space is maintained in main memory for pages.
In either case, there
is no need to modify the software as the number of computers changes nor as the distribution of effort among the computers changes. Programs themselves are designed as a set of interconnected modules each of
55
which is constrained to fit on a page from some sector.
This minimizes the num-
ber of virtual addresses actually used by the software because of the obvious overhead required to translate virtual addresses to physical memory addresses. Hence modules are written with normal addresses and normal code and execute with normal machine speed.
Transfer of control between modules is through use of vir-
tual addresses and requires translation overhead time.
Since virtual addresses
are used explicitly by the applicatlon program, the system is termed voluntary in contrast to many time shared computers which use virtual addresses exclusively with hardware translation to minimize overhead.
Figure 5.3 lists the routines
by which application programs voluntarily use the virtual space. The adw~ntages of serial CAMAC discussed earlier led to its use (with modification) (53) for the communication protocol for the microcomputer based line sharing system (Figure 5.4).
The particular problem faced is efficient co~mnuni-
cation of messages of long length, necessitated by the use of computers on the line sharing system in addition to normal I/0 devices.
Efficiency dictates that
such communications not be broken into many messages or packets with as few as 24 data bits per message.
If general messages could be transmitted, the proto-
col becomes rather complex.
In the voluntary virtual space organization however,
the only messages of long length transmitted are pages and these can easily be broken into packets whose length is fixed at the length of a single ALU. implementations use 64 word ALU units.
Current
As a consequence, the only need is to
transmit messages of short length as. currently done in CAMAC or longer lengths of fixed format (so that ALU units may be transmitted between computers).
The
amount of control in the microprocessor then becomes quite small since the communication system becomes so fixed. Microprocessors are added to allowable CAMAC elements by treating each as though it were a crate.
This makes available all the addresses of modules which
would normally reside in a crate for use to differentiate between functions to be performed by the microprocessor. The CAMAC system co~m~unicates using messages which are of several possible lengths.
The system is designed however so that message length is not essential
to the control system.
That is, messages are in effect a sequence of bytes se-
parated by one (or more) unique bytes called null bytes.
Controllers recognize
null bytes and then interpret the non-null bytes following as a message.
The
message terminates with the next null byte. It is convenient to take advantage of this design feature of serial CAMAC in order to make available messages of other than the standard lengths.
In particu-
lar, messages long enough to carry an ALU are desirable as are messages which can carry a virtual address and possibly one more word (two bytes) of data.
Hence
the serial CAMAC system is modified in this specification to permit these cases.
56 Messages from any processor to an I/0 device follow exactly the standard serial CAMAC specifications. ing upon the message type.
Other messages may have different lengths dependThus each message addresses to the second level com-
puter or any microprocessor must be interpreted by that processor to determine the type of message and from that information determine the length and interpretation of the contents of the various bytes. One substantial modification of the CAMAC system is necessary to support the microprocessors running in a voluntary virtual space environment.
It is
necessary to be able to transmit groups of data (I ALU in length) between the main computer and any microprocessor.
The standard CAMAC system is restricted
to the transmission of a maximum of 24 bits of data in a message.
As a conse-
quence, 32 messages would have to be transmitted to send one ALU to a microprocessor.
At 6 milleseconds per command-reply pair, the system would be too slow.
Consequently the command and replymessage formats are modified to permit an entire ALU to be transmitted within either message type.
Thus for msot messages,
commands are of length 5 or 9 bytes and replies 4 or 8 bytes.
When an ALU is
to be transmitted in either direction, the length of the command message becomes longer by 124 bytes.
Hence the transmission of an ALU t o a microprocessor in-
volves a eom~mnd message with the usual first four bytes followed by 128 bytes containing the 64 words to be read into the ALU followed by the message termination byte.
Similarly, a command to read an ALU into the central computer is a
four byte command followed by 132 idle bytes followed by a terminating null byte. The 132 idle bytes provide the space for the addresses microprocessor to insert its reply message with the usual 4 byte preamble followed by 128 bytes containing the ALU. The CAMAC system assumes that one computer controls many modules in crates. As a consequence, command messages originate only with the control computer and not with crates or modules.
As long as a microprocessor communicates only with
the central computer, command messages need originate only with the second level computer.
However it is desirable to permit microprocessors on the line to use
I/O devices which are modules in CAMAC crates elsewhere on the line.
In order
for this to be possible, a microprocessor must be capable of originating a standard length CAMAC command message.
Consequently the CAMAC design is further modi-
fied to permit microprocessors to generate read/write meassages (meassages of 5 and 9 byte lengths respectively).
However microprocessors are not permitted to
originate conmmnd messages of extra long length (that is, those which contain space for an ALU). Only the seccnd level computer is capable of originating extra long messages. This is feasible because ALU messages need be transmitted only when page faults arise and the second level computer is necessary to service these faults anyway.
5? The added flexibility of permitting the microprocessor
to generate normal length
command messages lets any microprocessor
communicate with any CAMAC crate and
module and with any other microprocessor
on the network.
With these changes, microprocessors to the CAMAC line sharing system.
can be connected in a very flexible way
Notice that this design makes no assumptions
about where input-output modules are connected. connected directly to a microprocessor line sharing system at all. system.
Thus microprocessors
That is, I/0 modules might be
and hence not be connected directly to the
Also, however, any CAMAC module can be added to the in the system can communicate
way with the process by using the line sharing capabilities in crates coDnected In summary,
in a straightforward (addressing modules
to the system) or by having its own dedicated
the serial CAMAC design is maintained
I/0 devices.
intact with the exception
of the following: i.
Extra length read-write messages are permitted so that one ALU can be
transmitted 2.
in a single message.
Demand messages originating
in microprocessors
may be longer to include
a virtual address in the demand message. 3.
Certain command messages may originate in microprocessors
the line as well as the second level computer for line-sharing
connected to
I/0 purposes.
Due to these changes there is the need for extended delay buffers in the microprocessors.
Device interfaces are not affected.
It is instructive microprocessor.
to look at the maximum transfer rate feasible with the
Assuming that one word is transferred
rupt and the response routine takes i00 microseconds, ly 6.5 milleseconds memory,
in response to an interit follows that approximate-
of CPU time is needed to transfer one ALU in or our of main
a maximum read-write rate of 70 ALU per second.
is near the burst rate considering microprocessor limitations Experimental
Thus a i00 kilobit rate
limitations.
Clearly these
could be removed by using a DMAC channel with appropriate controller. evaluation of this network scheme is currently underway.
It should be noted that the use of virtual addresses for programs, files, etc. is equivalent
data bases,
to using names for processes rather than addresses.
That is, the software organization uses virtual addresses rather than process names but just as in that case, the binding of that "name" to an actual processor and address is dynamic.
For example, a message can be sent to a data base by
means of a "remote put" command which is identical
to an ordinary "put" command
if the virtual address is resident in the local processor but results in a message broadcast
to all processors and received by that one containing
it is not local.
the page if
58
Minicomputer I
Virtual Spac~ Executive J
~
tly
Line sharing communication line
I
pages transmitted via messages
"window" space
into virtual
Figure 5.4 Process control network organized Around Voluntary virtual Space
PUT: GET: MPUT: MGET: RPUT: RGET: LOCK: UNLOCK: BRANCH:
store one word at a virtual address read one word from a virtual address store an array at a virtual address read an array from a virtual address remote put (no page transfer if non-resident) remote get (no page transfer if non-resident) lock a page into a local microcomputer release a locked page branch to program at a virtual address (with or without return specified) Figure 5.3 User program subroutines for access To the Voluntary Virtual Space
59 Vl.
Summary and Conclusions Process control software for single computer systems is very well developed
today.
Its use in multicomputer situations is less than satisfactory, requiring
modification of the software for each specific configuration even when the applications are essentially the same, but the sizes varies. trol of multiple paper machines illustrates this problem.
The cited example, conThe control task can
be shared although the data acquisition tasks may be duplicated in multiple computers.
At present, specific co~m~unication routines must be generated for the
specific configuration and size of the application to get the data to the control program at the right time and to guarantee adequate responses. The trends toward line sharing systems for I/O devices coupled with the ever increasing capability of microprocessors makes computer networks involving many computers inevitable.
To be economical, process control software will have to
become network oriented so that it does not have to be custom made for each application. The most critical need of the process control field today is the definition of the alternative modes of network communication so that those which are effective can be found and perhaps even standardized.
One the basic communication
protocols and structures are agreed upon, standardization of interfaces and software can follow.
It is important that this bedone quickly because the investment
in process control application packages cannot really proceed until this overall system structure has been fixed. References i.
Schoeffler, J. D.,
"The Development of Process Control Software", Spring
2.
Pike, H. E.,
3.
Hewlet-Packard Co.,
4.
Data General Corp.,
5.
Foxboro Co., Fox i Software, Publication 264, 1971.
6.
Digital Equipment Corp,
7.
Williams, T. J.,
Joint Comp. Conf., 1972, 907-914. "Process Control Software", IEEE Proc., Vol 58, No. i, Jan.
1970, 87-97. "Realtime Executive Software System", Document No. 2005-
900001, October, 1971. "Real-time Disk Operating Sy~m", No. 012-000040, South-
boro, Mass.
"RSX-IID System Description", Document No. 6701
00972 2444/1, Maynard, Massachusetts. "Minutes of Workshops on Standardization of Industrial
Computer Languages", Purdue Laboratory for Applied Industrial Control, Purdue Univ., W. Lafayette, Indiana. 8.
Foxboro Co., "FPL Language", Publication 327-5, Foxboro, Mass.
9.
Sevcik, K. C., J. W. Atwood, M. S. Grushcow, R. C. Holt, J. J. Horning, D. Tsichritzis,
"Projects SUE as a Learning Experience", Fall Joint Comp.
6O Conf., 1972, 331-338. i0.
Aramaki, I., T. Ohta, T. Kawabata, J. Shibata,
"A Language for Logical De-
sign Implementation and Checkout", Sumitomo Electric Technical Review, No. 16, Nov., 1973, 56-69. ii.
Donal, M., B. Girard, P. H. Guillier, J. Levy, D. Lorho, "A Language for the
12.
Ritout, M., P. B. Onnard, P. Hugot,
Programming of Industrial Applications,"
for Process Control,"
"Procol:
CECI-SESA manual. A Programming System Adapted
Committee of Automation, Delegation Generale a
La Recherche Scientifique et Technique. 13.
Taylor Instrument Co.,
"Process Oriented Language POL-I",
14.
Abascal, R. E., D. R. Kuehn, G. W. Markham, R. O. Martin, cation Program Generator for Sensor-Based Systems,"
Rochester N.Y. APG/7:
An Appli-
27th ISA Conf.,
October, 1972. 15.
General Electric Co.,
16.
Metromation Inc.,
"BICEPS Supervisory Control", GET-6064, 1970.
"Basic Control System Specifications", No. BCS 1000-90,
August, 1973. 17.
Honeywell Corp.,
"DDC System Applications Reference Manual", Doc. 130071884A,
18.
I B M Corp.,
19.
Marathon Oil Company,
20.
Digital Equipment Corp.,
21.
Data General Corp.,
June, 1968. "Prospro/1800 Process Supervisory Program",
Publ. H20-0473,
1967. "Marathon Analog Scan and Control System,"
Findley,
Ohio, February, 1970. "PDP-II Multiple Processor System Options", No.
ii01 00173 2464 f 14 04, Maynard, Mass.. "Remote Synchronous Terminal Control Program", No. 021-
000048, Southboro, Massachusetts. 22.
Digital Equipment Corp.,
23.
F. W. T~oburn,
Product Summary Dec Comm, Number ii01 X 00672 L 14 20
24.
Cullen, J. W.,
25.
Hewlett Packard Corp.,
26.
Calva, J. R.,
27.
C. J. Ball, Communications and the Minicomputer, COMPUTER, Sept., 1971, 13-21.
28.
Newport, C. B.,
'~ Transmission Control Unit for High-Speed Computer-to-Compu-
ter Communication, IBM J. Res. Develop., Nov. 1970, 614-619. "Binary Synchronous Communications", IEEE Intl. Communications
Conf., Philadelphia, Pa., June, 1968.
"PCOS:
"Distributed Systems", No. 5952-1646, 1973. A Process Control Extension to Operating System/360,
IBM J. Res. Develop., Nov., 1970, 620-632. "Small Computers in Data Networks", Spring Joint Computer
Conf., 1969, 773-775. 29.
Aydelotte, W. M.,
30.
Herzog, B.,
"Communications Message Switching-An Analysis", Computers
and Automations, July, 1971, 8-13. "Computer Networks",
Intl. Computing Symposium April, 1972, Ve-
61 nice, Italy. 31.
Farber, D. J.,
"Networks:
An Introduction,"
Datamation, April, 1972, 37-40.
32.
Kahn, R. E.,
33.
Heart, F. E., S. M. Ornstein, W. R. Crowther, D. C. Walden,
"Resource-Sharing Computer Communications Networks", IEEE Proc.,
Nov., 1972, 111-121. "The Interface
Message Processor for the ARPA Network", Spring Joint Computer Conf., 1970, 139-155. 34.
Falk, H.,
"Data Communications",
35.
Bell, C. G.,
IEEE Spectrum, January, 1974, 36-39.
'~More Power by Networking", IEEE Spectrum, February, 1974,
40-51. 36.
Falk, H.,
"ACheckup:
Minicomputer Software",
IEEE Spectrum, February,
1974, 52-56. 37.
Doll, D. R.,
38.
Winkler, S. and L. Danner,
39.
Rowe, L. A., M. D. Hopwood, D. J. Farber,
tion",
"Teleeo~mlunications Turbulence and the Computer Network EvoluComputer, February, 1974, 13-22. "Data Security in the Computer Communication En-
viroument", Computer, February, 1974, 23-31. "Software Methods for Achieving
Fail-Soft Behavior in the Distributed Computing System",
Technical Re-
port, Department of Information and Computer Science, University of California, Irvine, California. 40.
Farber, D. J., J. Feldmmn, F. M. Heinrich,
41.
Farber, D. J., F. R. Heinrich,
"The Distributed Computing System",
Seventh Annual IEEE Computer Society Intl. Conf., Feb., 1973. tem",
'The Structure of a Distributed Computer Sys-
Proc. Intl. Conf. on Computer Communications, October, 1972, 364-
370. 42.
Loomis, D. C.,
"Ring Communication Protocols", UC Irvine Distributed Computer
43.
Aronson, R. L.,
44.
Foxboro Co.~
"Spec 200", Bulletin C-200, 1972, Foxboro Mass.
45.
Foxboro Co.,
"Interspec Technical Information", Bulletins 2DC-100, 2DN-II0,
46.
Hippert, Jr,, R. 0o,
47.
Hooton, I. N., R. C. M. Barnes,
48.
European Standards Organization for Nuclear Electronics - DatawayWorking
Project, Report 46-A, May, 1972. "Line Sharing Systems for Plant Monitoring and Control", Con-
trol Engineering, January, 1971.
240-100, 240-101, and 240-102, 1973, Foxboro, Mass. "IBM 2790 Digital Transmission Loop", IBM J of Res. Dev-
elop., Nov., 1970, 662-667. "A Standardized Data Highway for On-Line Com-
puter Applications", Fall Joint Computer Conf., 1968, 1077-1087. Group," Proposed Standard Organization of Multi-Crate Serial CAMAC Systems", 1973. 49.
Falk, H.,
"Computer Hardware/Software",
IEEE Spectrum, January, 1974, 39-43.
62 50.
Holt, R. M.,
M. R. Lemas,
51.
Schoeffler, J. D.,
"Current Microcomputer Architecture",
Computer
Design, Feb, 1974, 65-73. L. R. Bronner,
"Data Management Software For Minicompu-
ter Production Monitoring and Control Systems,"
Proc. IEEE, Vol. 61,
No. ii, Nov., 1973, 1563-1570. 52.
Schoeffler, J. D., L. R. Bronner,
53.
Schoeffler, J. D.,
"A Virtual Memory Organization for Mini-
computer Process Control Software",
Automatlca, Vol. 9, Sept., 1973.
C. W. Rose, E. Linn, R. J. Wolpe,
"Organization of Hard-
ware and Software for a Microprocessor Network Used for On-Line Control", Systems Research Center Report (in preparation), 1974.
STAND UND TENDEN2EN AUF DEM GEBIET DER PROZESSRECHNER-HARDWARE Udo Offer Ubersicht Aufgrund der schnellen technischen Fortschritte in der Elektronik und insbesondere bei den Halbleiter-Bauelementen hat sich die ProzeBrechner-Hardware in den letzten Jahren grundlegend gewandelt. Sie ist vor allem preisgGnstiger und kompakter geworden° Dadurch ergeben sich wiederum viele neue Einsatzgebiete fur ProzeBrechner-Systeme. Momentan w~chst der ProzeBrechner-Markt weltweit mit Gberdurchschnittlichen Jahresraten. Mitte 1974 werden mehr als 6ooo ProzeBrechner in der Bundesrepublik installiert sein. FGr die ProzeBrechner-Anwendungen wird ein breites Spektrum unterschiedlicher Hardware-Produkte ben8tigt (Bild I). Im wesentlichen handelt es sich dabei um Zentraleinheiten, Standardperipherie- und ProzeBperipherie- sowie DatenGbertragungs-Einheiten. Ober Stand und Tendenzen auf diesen Gebieten wird im folgenden berichtet. Zentraleinheiten Struktur Die Struktur einer Zentraleinheit wird bestimmt durch die Grundeinheiten Zentralprozessor, Zentralspeicher und Ein/Ausgabe-Einheiten, die in geeigneter Weise dutch Datenwege verbunden werden. Eines der ~ltesten Konzepte bestand in der zentralen Stellung des Zentralprozessors, der s~mtliche Operationen wie Speicher- und Ein/Ausgabe-Transfers Gbernahm (Bild 2a). Um den Nachteil der geringen Geschwindigkeit und hohen Zentralprozessor-Belastung beim Ein/Ausgabe-Verkehr zu umgehen, wurde der direkte Zentralspeicher-Zugriff (DMA) eingeffihrt, womit jedoch 2 unterschiedliche Nahtstellen zum PeripherieanschluB entstanden, n~mlich Programmkanal und Datenkanal. Die weitere Entwicklung fGhrte daher zwangsweise zu Bus-orientierten Systemen, in denen Speicher- und Ein/Ausgabe-Nahtstellen zusammengelegt wurden (Bild 2b), um sowohl DMA- wie Programm-Verkehr zu tragen. Dieses Verfahren wurde soweit getrieben, dab jede Einheit Transfers initiieren und mit jeder anderen Einheit verkehren konnte. Dabei kSnnen jedoch Probleme im Zeitverhalten des Gesamtsystems dutch gegenseitige Blockierung au£treten. Man hat daher in jGngster Zeit versucht, diesen ~ n g e l n
durch mehrfache Bus-Systeme abzuhelfen. Ent-
scheidende Vorteile ergeben sich jedoch erst dutch eine zentrale Steue-
64 rung des Verkehrs, die sternfSrmig alle Anforderungen aufnimmt und nach Priorit~t die Verkehrswege zuteilt (Bild 2c). Mit den reduzierten Halbleiter-Preisen und der MSglichkeit preisg~nstiger Mikro-Programmierung haben sich jetzt in verst~rktem MaBe eigene Ein/AusgabeProzessoren durchgesetzt, die den DMA-Verkehr ersetzen und fur ProzeBaufgaben besonders leistungsf~hige Funktionen zur VerfGgung stellen (Bild 2d). Bei mittleren bis groBen Anlagen werden zudem in einigen F~llen Multiprozessor-Systeme aufgebaut, die die Simultanarbeit mehrerer Verarbeitungs- und Ein/Ausgabe-Prozessoren an unabh~ngigen Speichermoduln gestatten (Bild 2e).
Zentralprozessoren Bei den Zentralprozessoren von ProzeBrechnern hat sich die Registerstruktur als Standard durchgesetzt. Moderne Rechner haben meist 16 Register, die weitgehend universell eingesetzt werden kSnnen: als Rechenregister und Ergebnisspeicher (Akku) sowie ffir Adressmodifikationen, z.B. als Index- oder Basisregister. Die Vorteile sind nicht nut schnelle Register-Register-Operationen, sondern auBerordentlich leistungsf~hige Formen der Operandenadressierung, z.B. bei der Bearbeitung von Datenfeldern durch automatisches Fortschalten der Adressen. Als Wortbreite hat sich 16 Bits bei den kleineren und 32 Bits bei den grSBeren Rechnern durchgesetzt. Sie stellt einen gGnstigen KompromiB hinsichtlich Datendarstellung und Adressierungsvolumen dar. Allgemein wird bei kleineren Anlagen 32K bis 64K W8rter als obere Grenze des Adressierungsvolumens erreicht, w~hrend bei grSBeren zunehmend durch AdreBumsetzungen (z.B. virtuelle Adressierung) der Speicherausbau Gber 64K WSrter hinaus m~glich wird. Auch der Befehlsvorrat moderner ProzeBrechner hat gewaltige Erweiterungen nach Zahl und Leistungsf~higkeit erfahren.Bei kommerziellen Anlagen sind ladbare Speicher fGr Mikroprogramme vorgesehen worden, um den Befehlssatz ~lterer Maschinen zu emulieren und so eine Programmkompatibilit~t erreichen zu k8nnen. Auch bei kleineren ProzeBrechneranlagen war anfangs dieses Verfahren propagiert worden (kundenspezifische Befehle), hat aber aufgrund der nicht vermeidbaren Nachteile (Wartung, System-Software, verringerte Geschwindigkeit bei hSheren Kosten) keine sehr groBe Verbreitung gefunden. Die n~chste Zukunft wird dutch unabh~ngige Mikroprogrammierung yon Teilkomponenten des Rechners mit klei-
65 nen und schnellen bipolaren Halbleiter-Festwertspeichern gekennzeichnet sein, die ein Optimum in Kosten und Geschwindigkeit darstellen.
In der Vergangenheit war f~r den schnellen, programmentkoppelten Ein/ Ausgabe-Verkehr fast ausschlieBlich der direkte AnschluB externer Steuerungen an den Zentralspeicher verwendet worden. Die Nachteile lagen im mehrfach wiederkehrenden Aufwand der Steuerungen (z.B. komplette Adressansteuerungen),in der mangelnden Betriebssicherheit mad vor allem in der Abh~ngigkeit der Steuerungen v o n d e r
Speichernaht-
stelle. Man ist daher bei kommerziellen Anlagen sehr frHh dazu Gbergegangen, den Au£wand in komplexen Ein/Ausgabe-Werken zu zentralisieren und die peripheren Steuerungen vom Speicher zu entkoppeln. Auch bei mordernen ProzeBrechnern der mittleren Leistungsklasse sind heute bereits leistungsf~hige, mirkoprogrammierte Ein/Ausgabe-Prozessoren zu finden, die zudem in ihren Funktionen speziell auf die Erfordernisse der ProzeBtechnik abgestimmt sind. Sie leisten beispielsweise -
AdreBverwalt~ng beim Transfer sequentieller DatenblScke
- wahlfreie Adressierung peripherer Einheiten (z.B. Signalformer) Gber AdreBlisten -
wahlfreie Adressierung des Zentralspeichers durch die Peripherie
-
Z~hlen in Speicherzellen
-
automatische Kettung von Ein/Ausgabe-Prozessor-Funktionen
- Multiplexbetrieb an den AnschluBstellen bei gleichzeitig hoher Sicherheit durch FehlerGberwachung und Speicher-Schreibschutz. Dar~berhinaus l~Bt sich durch optimale Zusammenarbeit von Ein/Ausgabeund Zentral-Prozessor ein maximaler Systemdurchsatz erreichen. Ferner werden auch die Voraussetzungen fHr standardisierte Nahtstellen geschaffen, die ein einheitliches Peripheriekonzept bei ProzeBrechnerFamilien ermSglichen und damit auch dem Anwender Vorteile beim Ubergang zu anderen Zentraleinheiten und Erweiterungen der Familie bringen. Dieser Trend wird in der Zukunft in verst~rktem MaBe zu beobachten sein.
Der Zentralspeicher stellt nach wie vor einen wesentlichen Teil des Rechnerkerns sowohl vom Umfang als auch vom Preis dar. Parallel zum
66 Verfall der Preise ist n~mlich im gleichen Umfang der durchschnittliche Speicherausbau gestiegen. Dazu haben nicht zuletzt die steigenden Personalkosten auf der Softwareseite beigetragen, die vermehrt zur Programmierung in h~heren Sprachen ge~t~hrt haben. Da ein ~ n l i cher Verfall der Halbleiterpreise auch fGr den Verarbeitungsteil gG1tig ist, hat damit der Anteil des Speichers an den Kosten der Zentraleinheit nicht abgenommen. Vom Prinzip her kann man zwischen Festwertspeichern und Schreib-LeseSpeichern unterscheiden. Der Einsatz von Festwertspeichernwurde bereits bei der Mikroprogrammierung yon Zentralprozessor-Befehlen erw~hnt. Sie werden auch zur Speicherung von zwei Makroprogramm-Typen eingesetzt: Grundprogramme wie Urlader, Wartungs- und Testhilfen - Anwendungsprogramme bei kleineren Steuerungs- und Ger~terechnern, die in grGBerer StUckzahl mit gleichem Programm laufen und oft keine Bedienger~te aufweisen.
-
~ h r e n d frGher eine groBe Anzahl von Speicherprinzipien angewendet wurde~(z.B, optische, kapazitive und induktive Festwertspeicher), sind moderne Rechner fast ausschlieBlich mit bipolaren Halbleiterspeichern ausgerUstet. Entscheidend dafGr ist ihre leichte Handhabung (Programmierung, Austausch) und ihr gHnstiger Preis. Die weitere Entwicklung zielt auf Halbleiterspeicher, die nicht nur bei Spannungslosigkeit beliebig lange Zeit ihre Information behalten, sondern auch 1Gschbar sind oder sogar im Rechner neu beschrieben werden k8nnen (MNOS-Speicher). Das Gebiet der Schreib-Lese-Speicher
ist derzeit durch einen auBeror-
dentlich scharfen Konkurrenzkampf zwischen Kern- und Halbleiterspeichern gekennzeichnet (Bild 3 und 4). Die Kernspeicher konnten beim Preisverfall in den letzten Jahren entgegen manchen Prognosen durchaus mithalten und bestimmen weiterhin die Anwendungen bei kleinen bis mittleren ProzeBrechneranlagen, da sie bei Spannungsausfall ihre Information nicht verlieren und so auf eine Pufferung der Spannungsversorgung verzichtet werden kann. In Teilbereichen sind Ha!bleiterspeicher bereits unterschiedlich stark vorgedrungen: - Bei kleinsten Steuerungs- und Ger~terechnern bringt die einfache Integration statischer bipolarer oder MOS-Speicher Kostenvorteile bei kleinen Speicherausbauten bis 4K oder 8K WGrter.
67
Bei groBen Rechenanlagen werden bereits in st~rkerem MaBe bipolare
-
Schnellspeicher als Teile des Zentralspeichers -
angeboten.
Bei groBen Speicherausbauten ist der Grundaufwand dynamischer MOSSpeicher in Ansteuerung und Stromversorgung von geringerer Bedeutung. Ein g~nstigerer Preis von hochintegrierten Bausteinen l~Bt hier ein weiteres Vordringen erwarten. Die Kosten kSnnen durch neue Bausteine von 4K Bits/Chip bis zu 16K Bits/Chip wesentlich gesenkt werden.
Bei groBen Anlagen wird man zunehmend Hierarchien von schnellen, teueten aber kleinen und groBen, langsamen aber billigen Speichersystemen finden, um eine optimale LGsung zwischen Geschwindigkeit und Kosten zu erreichen. Konstruktiver Aufbau Die Aufbautechnik moderner Zentraleinheiten wird im wesentlichen durch die Packungstechnik integrierter Bauelemente bestimmt. Die Bausteine, meist in genormten Plastik-Geh~usen, werden auf ein- oder mehrlagigen Leiterplatten eingel~tet, die in subtraktiven ~tzverfahren oder additiven, galvanischen und drucktechnischen Verfahren hergestellte Leiterverbindungen tragen. Bei ausgesprochenen Kleinrechnern werden GroBplatten bis zu 15"x15" eingesetzt (Bild 5). Grthqde dafUr sind: Einsparung von Querverdrahtungen, Herstellung von autonomen Funktionseinheiten in einem Arbeitsgang oder auch die Anpassung an die BaugrSBe fremd bezogener KernspeicherModuln. In dieser Bauform sind auch Rechnermoduln zur Integration in Kundensysteme erh~ltlich; doch dGrfte diese Zielsetzung durch konstruktive Schwierigkeiten (fehlende internationale Normen) beschr~nkt sein. Wesentlich einfacher ist der Einsatz von eigenst~ndigen 19"-Geh~usen, die komplette Rechnersysteme mit Prozessor, Speicher und Anschaltungen zum AnschluB yon Peripherie-Ger~ten enthalten. Die mechanische Zuverl~ssigkeit dieser Aufbauten (z.B. FGhrung der Flachbaugruppen, direkte oder indirekte Steckung) ist fGr den ProzeBrechnereinsatz wichtig. Vor allem die Hersteller leistungsf~higer ProzeBrechner haben trotz hGherer Kosten auch bei kleineren Rechnern erprobte Aufbausysteme gew~hlt (Bild 6). Am h~ufigsten werden Flachbaugruppen im doppelten Europaformat (22o m m x 16o mm) eingesetzt. Dies f ~ r t zwar zur Aufteilung auf mehrere Platinen bei Zentralprozessor und Speicher, ergibt abet speziell bei den Peripherie-Anschaltungen und ProzeB~Signalformern optimale ModulgrSBen. Durch indirekte Steckung und Fein~tztechnik kann
68
eine hohe Bauteiledichte bei groBer Zuverl~ssigkeit und einfacher PrGlung durch Automaten sichergestellt werden. Um beim Einbau eine groBe Packungsdichte zu erhalten, k~nnen vorverdrahtete, 19" breite Baugruppentr~ger und Schr~nke mit einer Belegung in mehreren Ebenen eingesetzt werden (Bild 7). Eine einheitliche Durch1Gftung sowie Staubdichtigkeit kann durch den Einsatz von W~rmetauschern erreicht werden. FGr grSBere Systeme mug noch die Verkabelung gel5st werden. Die ProzeBkabel z.B. sind im allgemeinen nach 8rtlichen Gegebenheiten zusammengefaBt, w~hrend Signal£ormer meist nach Signalart und Funktion gruppiert werden. Die einzelnen Signaladern mGssen daher rangiert werden. Geschieht dies durch geeignete Ubergabemoduln in jedem Schrank, kann dieser his zum Ubergabe-Verteiler fertig verkabelt und geprGft ausgeliefert werden. Dadurch werden sich zukGnftig die Montage- und Inbetriebnahme-Zeiten verkGrzen lassen. Standardperipherie-Einheiten Einen Uberblick Gber die Standardperipherieger~te gibt Bild 8. Daraus ist zu erkennen, dab es sich bei den Standardperipherie-Einheiten (mit Ausnahme der Sichtger~te) um elektromechanische Einheiten handelt. Ihre AusfGhrung unterscheidet sich teilweise yon der bei kommerziellen Datenverarbeitungsanlagen (kleinere Leistung und niedrigerer Preis, weniger Bedienungskomfort, h6here Anforderungen an Zuverl~ssigkeit, Umgebungsbedingungen und einfache Wartung). Die Entwicklungstendenzen bei der Standardperipherie verlaufen sehr unterschiedlich. Sie reichen v o n d e r stetigen Verbesserung des Preis/ Leistungsverh~ltnisses Gber den Einsatz neuer Prinzipien bei bestehenden Ger~ten bis zu vSllig neuen Technologien, die sich erst au£ dem Markt durchsetzen mGssen.
Der Blattschreiber mit Tastatur und Anbauleser und -!ocher ist immer noch das wichtigste Bedienungsger~t f~r einen ProzeBreohner, bei Kleinanlagen oft auch das einzige. Die Weiterentwicklung der Blattschreiber zielt auf einen Ersatz yon mechanischen Teilen durch Elektronik und den Einsatz neuerer Druckprinzipien (z.B. Matrixdrucker, Thermodrucker). Steht die Bedienung - und nicht die Protokollierung - im Vordergrund, so wird der Blattschreiber durch billige Sichtger~te teilweise ersetzt.
69
Lochstreifen- und Lochkartenger~te rieger~ten.
z~hlen zu den eingeftthrten Periphe-
Obwohl ihr Anteil aufgrund von neuen Techniken (z,B. Mag-
netbandkassetten und Floppy-Disk-Speicher)
sinkt, bleiben diese Ger~te
doch weiterhin Bestandteil des Peripherieger~tespektrums. Bei Lochstreifen- und Lochkartenger~ten geht der Trend zu einer Verbesserung des Preis/Leistungsverh~ltnisses (Bild 9). Grundlegende ~nderungen sind bei diesen Ger~ten in der Zukunft nicht mehr zu erwarten. FGr die Protokollierung gr~Berer Datenmengen werden elektromechanisch arbeitende Drucker eingesetzt. Die eingef~Jhrten Trommel- und Kettendrucker stehen am oberen Ende der benStigten Leistung, aber auch des Preises. Matrixdruckprinzipien in verschiedener Form bieten bis zu einer Druckleistung yon 2oo Zeilen/Minute sehr preiswerte L8sungen und sind im Begriff, den Markt zu erobern. Es l~Bt sich jedoch absehen, dab elektromechanische Drucker bald an einer technologischen Grenze stehen werden. FGr die Zukunft dGrften daher nicht-mechanische Prinzipien, z.B. in der Form yon elektrostatischen oder thermischen Druckern wesentlich an Bedeutung gewinnen. Datensichtstationen erlauben neben den herk~mmlichen elektromechanischen Ein/Ausgabeger~ten neue MSglichkeiten des Dialogs Mensch-Rechner. DarGberhinaus gestatten sie, Informationen rasch und parallel an verschiedenen Orten anzuzeigen. Neben alphanumerischen Sichtstationen, die sich in groBen StGckzahlen durchgesetzt haben, gewinnen Sichtstationen mit zus~tzlicher graphischer Darstell~mgs- und EingabemSglichkeit stark an Bedeutung. FUr die Hervorhebung einzelner ProzeB-Graphiken ist die Farbdarstellung sehr nGtzlich (bis zu 7 verschiedene Farben). Hier bietet der Einsatz von Farbfernseh-Monitoren die preislich und technisch optimale L6sung (Bild Io). Spezielle Farb-KathodenstrahlrShren mit frei positionierbarem Elektronenstrahl sind dagegen noch sehr teuer und erfGllen hinsichtlich Farbqualit~t nicht alle AnsprGche. FGr die weitere Zukunft kSnnten Plasma-Schirme und FiGssigkristall-Anzeigen an Bedeutung gewinnen. Aufgrund der Preisreduzierung der Bauelemente werden komfortable Graphiksichtstationen mit komplexen Hardwarefunktionen einen breiteren Anwendungskreis linden, wobei die Version mit integriertem Kleinrechner als selbst~ndiger interaktiver Bildschirmarbeitsplatz dominieren wird.
7O
Plotter setzen digital aufbereitete graphische Daten in Zeichnungen um. FGr ProzeBrechneranwendungen werden aus PreisgrGnden haupts~chlich Trommelplotter eingesetzt. In der letzten Zeit wurde das Konzept der Trommelplotter vor allem in der Konstruktion verbessert. Moderne Trommelplotter mit gr~Berem Papierformat und h~herer Zeichengenauigkeit ersetzen bereits heute teilweise herk8mmliche Tischplotter. Seit mehreren J~hren ist eine neue Gruppe yon peripheren Ger~ten auf der Basis der Magnetspeichertechnik auf dem Markt: die Magnetbandkassettenger~te und die Floppy-Disk-Speicher. Diese Ger~te kSnnen nicht eindeutig einer bestimmten Peripherieger~tegruppe zugeordnet werden. Ihr Einsatz reicht vom Lochstreifenger~te-Ersatz bis zum PeripherSpeicher mit langsamem Zugriff. Die Entwicklung der Magnetbandkassette nahm in einer Gberarbeiteten I/8"-Kassette der Unterhaltungselektronik ihren Anfang. FGr erhShte Anforderungen folgt jetzt eine 1/4"-Kassette. Beide Kassetten-Typen sind inzwischen genormt. Bei der Floppy-Disk dient eine flexible Kunststoffscheibe als Tr~ger fGr die Magnetsohicht. Es werden zwei Abtastverfahren verwendet. Das eine Verfahren arbeitet mit einem auf der Oberfl~che des Datentr~gers schleifenden Schreib/Lesekopf mit der Konsequenz einer relativ geringen Datenrate von ca. 15 K WSrter/sec und einer beschr~nkten Lebensdauer des Datentr~gers. Das zweite Abtastverfahren verwendet einen auf einem Luftpolster schwebenden Schreib/Lesekopf. Die Datenrate entspricht der eines positionierbaren Plattenspeichers, die Lebensdauer des Datentr~gers ist zumindest theoretisch unbegrenzt. Der Marktanteil von Magnetbandkassette und Floppy-Disk stieg in den letzten Jahren auf Kosten der vorher eingefGhrten Ein/Ausgabeger~te an. Die Kassette hat derzeit den Vorteil, dab sie etwas l~nger auf dem Markt ist als die Floppy-Disk. Bei vergleichbarem Aufwand fGr Laufwerk und Rechner-AnschluB weist die Floppy-Disk jedoch einige Vorteile auf (kGrzere Zugriffszeit, hShere Datenrate). Die Betriebsdatenerfassung (BDE) hat die Aufgabe, zentrale und Gbergeordnete Stellen im on-line-Modus mit aktuellen Informationen aus den verschiedenen Betriebsteilen zu versorgen. FGr die Erfassung der Betriebsdaten bzw. fGr die Ausgabe yon RGckmeldeinformationen werden verschiedene Datenendger&te benGtigt. Die BDE-Terminals mGssen modular aufgebaut sein, um sich den Erfordernissen der Anwendung gut anpassen zu k~nnen. Im wesentlichen handelt es sich dabei tun Zehner- und Funk-
7~
tionstastaturen, Plastikkartenleser, Eingaberegister, Zahleneinsteller sowie Ziffernanzeigen, Ausgaberegister und Digitaldrucker. Die Anwendung dieser Ger~te wird im Rahmen der fortschreitenden Entwicklung zu maschinellen Verfahren fGr die Fertigungsregelung welter zunehmen, wobei die Forderungen an einen kompakten und flexiblen Aufbau im Vordergrund stehen.
Zur Erweiterung der in der 2entraleinheit befindlichen Zentralspeicher werden kostengGnstige periphere Speicher benGtigt. Diese Aufgaben werden derzeit haupts~chlich von elektromechanischen Speichern - Magnetplatten und Magnettrommeln - Gbernommen. Ein Kernspeicher als Peripherspeicher spielt bei ProzeBrechnern eine untergeordnete Rolle, desgleichen 9 Spur-Magnetbandger~te, die vornehmlich zur Archivierung von Daten dienen. Die Festkopfplattenspeicher bzw. Trommelspeicher werden bevorzugt eingesetzt, wenn eine kGrzere Zugri£fszeit und h~here Zuverl~ssigkeit gewGnscht wird. Wichtig ist bei diesen Ger~ten eine hermetische Kapselung und ein Minimum an vorbeugender Wartung. Durch ErhShung der Schreibdichte konnte das Preis/Leistungsverh~ltnis in letzter Zeit wesentlich verbessert werden. Die Eigenschaften der positionierbaren Plattenspeicher konnten in den letzten Jahren wesentlich verbessert werden: - verdoppelte his vervierfachte Bit- und Spurdichten (infolge verbesserter KGpfe und genauerer Positioniereinrichtungen) -
kGrzere Zugriffszeiten durch neue Positioniereinrichtungen
- gr8Bere 2uverl~ssigkeit durch die EinfGhrung staubdichter Kassetten - kompaktere Bauweise durch die Verwendung von integrierten Halbleiterbausteinen und durch gedr~ngten mechanischen Aufbau. Die Weiterentwicklung dieser Ger~te erscheint nur in beschr~nktem Umfang noch m8glich, so dab eine eventuelle sp~tere AblSsung durch neue Speichertechnologien wahrscheinlich ist. Von diesen neuen Technologien sollen hier nur Halbleiterspeicher, Magnetblasenspeicher und holographisch-optische Speicher erw~hnt werden. Der konkrete Einsatz dieser Entwicklungen dGrfte jedoch nicht mehr vor 198o erfolgen. l~schluB der Peri~heE~e~er~te an die Zentraleinheit Der AnschluB an die Zentraleinheit erfolgt Gber elektronische Anschal-
72
tungen bzw. Steuerungen, deren Funktionsumfang v o n d e r
Beschaffenheit
der Ein/Ausgabeschnittstelle der Zentraleinheit, dem Funktionsumfang der Ger~te und der Organisation des Ein-Ausgabe-Verkehrs abh~ngt. Die Aufgaben einer Anschaltung bestehen im wesentlichen darin, die Ger~teschnittstelle physikalisch an die Zentraleinheitschnittstelle anzupassen, den Daten-Transfer yon den Zeitbedingungen der Zentraleinheit zu entkoppeln, die angeschlossenen Ger~te mit den erforderlichen Parametern zu versorgen und die Meldungen von den Ger~ten auszuwerten. Die Realisierung dieser Funktionen erfolgt derzeit meist in TTL-Technik. Der Umfang reicht von einzelnen Flachbaugruppen, die direkt in die Ein/ AusgabeansehluBstelle der Zentraleinheit gesteckt werden (z.B. Lochstreifen-, Lochkartenger~te) his zur Steuerung fGr Peripherspeicher, die in einem eigenen Rahmen untergebracht ist. Die Entfernung zwischen Zentraleinheit und peripherem Ger~t h~ngt v o n d e r
Transferrate und dem
verwendeten 0bertragungsverfahren ab. Die Entfernung schwankt zwischen 5 Metern bei Peripherspeichern bis zu etwa 2oo Metern bei Ger~ten mit niedriger Datenrate. FUr die Zukunft bietet sich durch den Einsatz von Mirkoprozessoren die Realisierung von frei programmierbaren Anschaltungen an. Dadurch kann wesentlich an dem Entwicklungsaufwand einer ger~tespezifischen Hardware gespart werden. Die dann noch notwendige Anpassung des Ger~ts an die programmierbare Anschaltung l~Bt sich mit geringem Aufwand realisieren. ProzeBperipherie Die ProzeBperipherie hat die Aufgabe, die Anpassung der nach Art und Zeitverhalten sehr unterschiedlichen ProzeBsignale an die interne Daten- und Signaldarstellung des ProzeBrechners vorzunehmen und den Daten- und Signalverkehr mit der Zentraleinheit abzuwickeln° Sie ist als Koppelglied zwischen Zentraleinheit und ProzeB in Struktur und Aufbau stark von beiden abh~ngig. DiesbezGgliche nationale und internationale Bestrebungen zur Normierung sind vorerst Gber sprachliche Regelungen noch nicht hinausgekommen. Eine Ausnahme bildet CAMAC, ein nach Funktion und Aufbau definiertes System. Von seiner Herkunft her vorerst auf kernphysikalische Anwendungen beschr~nkt, konnte es in den letzten Jahren in weitere Bereiche, vorwiegend bei der Laborautomatisierung, vordringen. Da dieses System aber fGr kleine Ausbauten relativ au£wendig ist und keine so groBen Ausbaum8glichkeiten zul~Bt, wie sie in der Anlagentechnik gefordert werden, wird das Einsatzgebiet beschr~nkt bleiben.
73
Strtuktur und Atufbau Je nach Art ~md Umfang eines Prozesses kann die Aufgabenstellung f~r die ProzeBperipherie
in einem weiten Bereich variieren. Von einer uni-
versell verwendbaren ProzeBperipherie muB daher hohe Flexibilit~t in Funktion und Aufbau gefordert werden. Dazu muB sie nach einem modularen, feinsttufig erweiterbaren Bausteinprinzip konzipiert sein. Dies erfordert eine Aufteilung in prozeBspezifische
Funktionen der Signalan-
passung und in ~bergeord~qete Steuerungsfunktionen Daten- und Signalverkehrs.
zur Abwicklung des
Den so festgelegten Funktionseir~eiten mGs-
sen entsprechende Baueirdqeiten eindeutig zugeordnet werden. Eine nach einem solchen modernen Konzept erstellte ProzeBperipherie
ist durch
folgende Eigenschaften gekennzeichnet: - prozeBspezifische Ein/Ausgabeeirfi~eiten mit eir~heitlicher ScD_uittstelle f~r Daten - universelle
und Unterbrechungs-Signale
Steuerungen f~r Ein- und Ausgabe hoher 0bertragttugs-
leistung zum AnschluB einer festen Anzahl prozeBspezifischer Einbzw. Ausgabeeirdueiten in beliebiger Mischung - Aufbau komplexer Systeme nach einer Bus- oder Stern-Strtuktur - kompakter konstruktiver Aufbau. F~r den Anwender ergeben sich daraus folgende Vorteile: - feinstufige und wirtschaftliche L~sungen vom Minimal- bis zum Maximalausbau - einfache Projektierung - unproblematisches NachrGsten weiterer Einheiten - kurze Zeiten fGr Fehlersuche durch abgegrenzte Bau-Einheiten. ProzeBs~g~g_~L~ggabeeinheiten Diese Einheiten enthalten die Mittel zur Anpassung der unterschiedlichert ProzeBsignale an die interne Daten- und Signaldarstellung zeBrechner.
im Pro-
W~hrend die Schnittstellen zur vorgeschalteten Steuerung
eirflqeitlich sind, mGssen die ProzeBschnittstellen
anwendungsspezifisch
ausgef~hrt sein. Dementsprechend ist ein umfangreiches Spektrum yon solchen Ein/Ausgabeeinheiten ffir Unterbrechungseingabe, und -ausgabe sowie Analogein- und -ausgabe notwendig.
Digitalein-
Dieses Standard-
spektrum wird teilweise noch durch SonderausfGhrungen erweitert
(Zeit-
geber, Z~hler oder f~r spezielle Anwendung, wie z.B. DE~-Regelung). Konstrtfi~tiv sind diese Eir~qeiten vorwiegend als steckbare Moduln ausgefthhrt, bestehend aus einer oder mehreren Flachbaugruppen. und die Baubreite der Moduln ist abh~ngig vom Aufbau-System,
Die GrSBe wobei zur
74
Ausnutzung der hSheren Integrationsdichte ein Trend zu grSBeren Platten, etwa im doppelten Europaformat, zu beobachten ist (z.B. 32 Bin~reing~uge). Der AnschluB der ProzeBsignale erfolgt z.B. fiber Frontstekker, wodurch eine gute Entkopplung zur internen Verdrahtung des Baugruppentr~gers der Steuerung sichergestellt ist. Teilweise abweichend von diesem Konzept existieren Analogeingabe-Einheiten, die wegen des aufwendigen zentralen Teils mit A/D-Umsetzer und MeBstellenw~hler ganz in eigenen Baugruppentr~gern untergebracht sind. Steueruns~ h Sie steuern und Gberwachen den Datenverkehr der angeschlossenen prozeBspezifischen Ein/Ausgabeeinheiten von oder zur Zentraleinheit. Sie bieten dabe± als Sammler/Verteiler eine feste Anzahl von Kan~len mit gleicher Schnittstelle zum AnschluB beliebiger prozeBspezifischer Ein/ Ausgabeeinheiten. Es kSnnen in einem System mehrere Typen von Steuerungen gestaffelt nach der Leistungsf~higkeit des Datenverkehrs zur VerfGgung stehen. Eine solche Staffelung kann besonders bei umfangreichen Ausbauten preisgGnstige L~sungen bieten. Konstruktiv sind solche Steuerungen als lest verdrahtete Baugruppentr~ger (in Form von Rahmen oder EinschGben) aufgebaut, die den Steuerungsteil und zus~tzlich eine feste Anzahl von Einbaupl~tzen zur Aufnahme von prozeBspezifischen Ein/ Ausgabeeinheiten als steckbare Moduln enthalten.
~u
kom~lexerer Systeme
Das Zusammenschalten der einzelnen Steuerungen geschieht entsprechend dem Systemkonzept nach einer Bus- oder Stern-Struktur (Bild 11). Bei der Bus-Struktur erfolgt der AnschluB der einzelnen Steuerungen an einen Ein/Ausgabe-Kanal der Zentraleinheit Gber einen gemeinsamen Bus, der yon Steuerung zu Steuerung bis zum Maximalausbau weitergeschleift wird. Der Datenverkehr der Zentraleinheit mit einer prozeBspezifischen Ein/Ausgabeeinheit l~uft Gber diesen Bus und die betreffende Steuerung. Dadurch, dab alle Signale gleichzeitig an allen Steuerungen anstehen, f~llt bei einem Fehlverhalten einer Steuerung im allgemeinen das gesamte System und nur in Sonderf~llen der nachgeschaltete Tell des Busses aus. Bei gr~Beren Konfigurationen k~nnen Laufzeit- und AbschluBProbleme die Datenraten stark reduzieren. Bei der Stern-Struktur kann an jeden der Kan~le einer Steuerung wahlweise wieder eine Steuerung oder eine prozeBspezifische Ein/Ausgabeeinheit jeweils bis zum Maximalausbau angeschlossen werden. Auf diese
75 Weise sind mehrere Ausbauebenen mSglich, die jeweils durch die maximale Zahl der Steuerungen bzw. Ein/Ausgabeeinheiten gekennzeichnet sind. FHr den Datenverkehr zwischen der Zentraleinheit und einer bestimmten Ein/Ausgabeeinheit wird jeweils ein durchgehender Kanal aufgebaut, wodurch selbst bei groBen Systemen ein optimales Zeitverhalten erreicht wird. Bei einem Fehlverhalten einer Steuerung f~llt nur der nachgeschaltete Zweig, nicht aber das gesamte System aus. Der konstruktive Aufbau erfolgt in Schr~nken und Gestellen, in die die einzelnen Rahmen oder Einsch~be zusammen mit der benStigten Stromversorgung eingebaut werden. Die Verbindung der Rahmen untereinander sowie die Zuft[hrung der ProzeBsignale erfolgt mit Steckleitungen. Das Rangier e n d e r ProzeBsignale bei gleichzeitiger Umsetzung des Adernquerschnittes der Leitungen (mechanische Flexibilit~t) kann dezentral in den einzelnen S c h r ~ k e n geschehen oder erfordert speziell einen zentralen Rangierverteiler. ZukGnft~s~ Entwicklun~ Eine weitere wesentliche Verringerung des Volumens bei der ProzeBperipherie ist fGr die n~chste Zukunft nicht zu erwarten. Dabei liegt die Begrenzung vorwiegend in den physikalischen Gegebemheiten. Bei Stekkern z.B. dGrfte eine weitere Miniaturisierung wegen der erforderlichen Kriechstrecken zur Einhaltung der elektrischen Betriebssicherheit nicht welter vorangetrieben werden kSnnen. Auch bei mehradrigen Kabeln kann eine hShere mechanische Flexibilit~t dutch weitere Senkung der Adernquerschnitte nicht beliebig £ortgesetzt werden. Eine Ausnahme bilden die Einheiten fGr Analogeingabe, wo durch hShere Integration analoger Schaltkreise noch eine Reduzierung des Volumens mSglich ist. Da die Verkabelungskosten von weir verzweigten Anlagen bei einer zentral angeordneten ProzeBperipherie einen verh~ltnism~Big immer grSBeren Anteil ausmachen, dGrfte eine st~rkere Konzentration auf g~nstige L~sungsm~glichkeiten fGr dezentrale ProzeBperipherie stattfinden. Mit dem zu erwartenden Einsatz yon Mikroprozessoren ist auch bier eine AblSsung der bisher lest verdrahteten Hardware-Steuerungen zu erwarten. Durch Delegation untergeordneter Aufgaben an diese "intelligenten" Steuerungen (wie z.B. das Feststellen von Signal~nderungen durch zyklische Abfrage yon bin~ren Eing~ngen) w~re gleichzeitig eine Entlastung der Zentraleinheit yon Routineaufgaben gegeben.
76
DatenGbertragungseinheiten Die DatenGbertragungseinheiten lassen sich je nach Aufgabenstellung in Rechnerkopplungs- und Peripheriekopplungs-Einheiten unterteilen. Rechner~2~B~_n~_~B Unter Rechnerkoppltuug versteht man die physikalische und logische Verblndung zweier 2entra!einheiten° Die haupts~chlichen Anwendu~gen lassen sich in 3 Gruppen einteilen: -
-
-
Komplexe Automatisierungsaufgaben werden zur Entlastung des koordinierenden Zentralrechners auf autonome Kleinreohner verteilt. Dadurch kSnnen Alarme schneller bearbeitet und die Inbetriebnahme erleichtert werden. R~umlich voneinander entfernt anfallende Aufgaben werden yon mehreren Rechnern gel~st, wobei ein Zusammenwirken innerhalb des Gesamtsystems notwendig ist (z.B. Pipelinenetze). Sogar Mehrrechner-Systeme werden in Form von Parallel-, Stand-byund Master-Slave-Konfigurationen eingesetzt.
Aufgabe der Kopplungs-Hardware ist es, einen beliebigen Block von Daten aus dem Hauptspeicher eines Rechners in den des anderen zu Gbertragen. Durch die Eigenschaften eines Ein/Ausgabe-Prozessors wird eine weitgehende Entlastung des Zentralprozessors dadurch mSglich, dab dieser die Ubertragung nur anst~Bt bzw. yon dem AbschluB verst~ndigt wird. Da die Aufgabe, einen Block zu Ubertragen, fGr s~mtliche Anwendungsf~lle und Entfernungen gleich ist, bietet es sich an, fGr den Datenaustausch zwischen den beiden Rechnern eine einheitliche Steuerung zu verwenden. Bei der Kopplung von Zentraleinheiten, die der gleichen ProzeBrechner-Familie angeh~ren, wird der Datenaustausch dem Ein/Ausgabe-Verkehr angepaBt (asynchroner Datenverkehr, Bild 12). Unterschiede bestehen dann nur noch in der Art und L e i s t u n g d e r
Ubertragung.
BezGglich der zu GberbrGckenden Entfernung unterscheidet man den Nahbereich, den innerbetrieblichen Bereich und den Fernbereich. Im Nahbereich (bis ca. 15o m) ist durch ParallelGbertragung mit dem Gegentaktstromverfahren die h8chste Datenrate m~glich (etwa 2ook WGrter/sec). Im innerbetrieblichen Bereich (bis ca. 3 km) ist bei serieller Ubertragung und Verwendung yon TF- oder Koaxial-Kabeln eine max. Datenrate von ca. looo kBd erreichbar° Will man schon vorhandene Telefonleitungen ausnGtzen oder muB Gffentliches Gebiet GberbrGckt werden, wird die Datenrate durch die verwendete DatenGbertragungseinrichtung beschr~nkt (z.B. GDN-Modem mit 9,6 kBd). Die 0bertragung im Fernbereich erfolgt
77 fiber Stand- oder W~hlleitungen der Bundespost. Die Entfernung ist dadurch zwar u~eschr~nkt,
die Datenrate jedoch limitiert
(derzeit 4,8 kBd).
Viele Anwender sind daran interessiert, ProzeBrechner verschiedener Hersteller zu k0ppeln. Dies erfolgt wiederum fiber Postleitungen mit Modems nach genormten Prozeduren (ISO, ECMA, DIN) mit Hilfe von ~ e r t r a g u n g s steuerzeichen. Da dann der Verkehr nicht mehr optimal an die vorhandene Schnittstelle angepaBt werden kann, ist erheblicher Umsetzaufwand notwendig (Steuerung fGr synchronen Datenverkehr nach Prozedur). Hier ~ibt sich ebenfalls ein Anwendungsgebiet ffir Mikroprozessoren, die den genannten Umsetzvorgang durchft~hren. L~dt man die dafGr notwendigen Programme in programmierbare Halbleiterspeicher, kann eine Kopplung zu einem Fremdrechner ohne Anderung der familieninternen Basis-Koppelsoftware realisiert werden. Es ist m~glich, die Kopplungseinheiten z.B. auf I-2 Flachbaugruppen im doppelten Europaformat zu realisieren, so dab sie direkt in den Rahmen einer Zentraleinheit bzw. eines Multiplexers passen.
Ihre Aufgabe ist es, r~umlich entfernt anfallende Daten in einen Rechn e r e i n - bzw. von dem Rechner Gber groBe Distanzen auszugeben (z.B. in der Betriebsdatenerfassung). 0ber speziell ausgelegte Obertragungsstrecken kSnnen neben Betriebsdatenerfassungs-Stationen auch Dialogger~te der Standardperipherie sowie ProzeBperipherie-Ger~te angesprochen werden. Wegen der immer starker steigenden Softwarekosten sollte sichergestellt sein, dab sich der dezentrale vom zentralen AnschluB softwarem~Big nicht unterscheidet, was eine Entkopplung von den Zeitbedingungen der E/ASchnittstelle erfordert. Die Abwicklung der logischen und physikalischen Ubertragung erfolgt rein hardwarem~Big. Da auch die Auschaltungen der Ger~te gleich bleiben sollen, muB die volle Ein/Ausgabe-Schnittstelle auch dezentral zur VerfGgung gestellt werden. Auch hier unterteilt man in den Nahbereich, den innerbetrieblichen Bereich und den Fernbereich. W~hrend im Nahbereich die 0bertragung parallel mit dem Gegentaktstromverfahren erfolgt, findet man im innerbetrieblichen Bereich sowohl die Sternstruktur als auch die Schleifenkonfiguration (Bild 13).
78 Die Sternstruktur sollte nur bei geringem Ausbaugrad vorgesehen werden, da bei gr6Berem Ausbau die Kabel- und Verlegungs-Kosten gegenGber einer Schleifenstruktur sehr hoch werden. GGnstig ist die Sternstruktur jedoch immer bei Verwendung schon vorhandener Telefonleitungen. Es werden die in der Rechnerkopplung angefGhrten Ubertragungsverfahren verwendet. Bei der Schleifenkonfiguration kSnnen an eine hochwertige Sammelleitung bei einer maximalen L~nge bis zu mehreren Kilometern bis zu too Terminals an beliebiger Stelle angeschlossen werden. Der Abstand der Terminals von dieser Leitung kann bis zu 2oo m betragen, wobei wegen der hohen Bus-Datenrate Simultanarbeit m~glich ist. Durch neuartige Ubertragungsverfahren (induktive Einkopplung, PulsGbertragungsverfahren) bewirkt der Spannungsausfall bei einzelnen Terminals keine StSrungen auf dem Bus. Im Fernbereich sind Datenstationen gem~B dem bei der Rechnerkopplung bereits genannten synchronen Datenverkehr nach Prozeduren anschlieBbar. Die Obertragung erfolgt synchron ~ber Telefonleitungen, wobei man auch hier zwischen einer Schleifenkonfiguration und Sternstruktur w ~ len kann. Da das Gebiet der Rechner- und Peripherie-Kopplung erst jetzt grSBere Bedeutung gewinnt, k8nnen hier im Gegensatz zu den bisher behandelten Gebieten keine Tendenzen aufgezeigt werden.
Bild I
ProzeBrechner-Anlage
79
]~ ZP H PEi J
ZSP
II
i SW'
Iz l I ZP
~l
ii i
ZSP = Zentralspeicher ZP = Zentralprozessor PEi = Periphere Einheit i
b) B u s - S y s t e m mit Kettenprioritierung
P i
I
c) B u s - S y s t e m mit Sternprioritierung PRIOR = Zentrale Priorit&tssteuerung
I PEi
PRIOR
L
a) 6 r u n d - System
I
,,= ZSP-AS
i
lzspl l EA- AS ,
ZP I
I
EAP
d) System mit EA- Prozessor EAP = Ein/AusgabeProzessor ZSP - AS = ZentrelSpeicher Anschtu13 EA - AS = Ein-Ausgabe-Anschlu I3
e) M e h r p r o z e s s o r - System mit u n a b h ~ n g i g e n S p e i c h e r m o d u [n
! JI Bird 2
P = Zentral- oder Ein/AusgabeProzessor
M6glichkeiten von Zentraleinheit-Strukturen
"~////~X~
"~/7"='~
lOps
lOOt,s
Jahr
Preisentwick[ung fLir Speicher (jeweits mitt[. Geschwindigkeit)
75
Bil.d 4
lns
10ns
,02
1ms.
lOres.
lOOms
ls
lOs
l~s KSP-Systeme(l[Js) lOOns MOS-Systeme
TTL Speicher
ECL - Speicher
% MOS Boustelne
~
65 6(; 67 68 69 70 71 72 73 ?4
Jr"
Bi[d 3
0,01
0,03 "3L
0,1
0,3 -~
10 ..it
lOOs
Kernspeicher
1~8
_
o. o ,
[Bits_]
,~o
5
5
.... "
~ 30
~
~
Zusammenhang zwischen Speicher-Kapazitdt u. Zugriffszeit
Speicherkapozit~it
.............. 1'o
(TTL I ECL)
L , ~ , _ ~ Bipolare Speicher
........i',
o o° ,° -
speicher
Pf/Bit
Posittonierb. Ptattenspeicher "~ 0,1 F / / / / / / / / / J Festkopfsp e'cher ,,. 1
~
F////A
. ~ M O S - Speicher
=_ j -
i Zugriffszeit
Gr613enordnung der durchschnittlichen Kundenpreise
co O
81
Bild 5
Kleinrechner im GroBplatten-Aufbau
~ild b
Komplette Zentraleinheit mit Peripherie-Anschaltungen i~ 19"-Rahmen
82
B±ld 7 ProzeBrechner-Schrank mit Rahmen-Belegung in 2 vertikalen Ebenen
83
t i I
Blottschreiber Orucker
I
ZE
-----1
Gro.",'~.e ~,'...anu~er,s~."'e' I
I I .
~
I
Sichtstationen Plotter
.
.
.
Betriebsdatener fa ssungsTerminals
Nagnetband - Kassettenger~te FIoppy- Disk- Spei cher Positionierbare Plattenspeicher, Festkopfspeicher, Magnetbandspeicher
!
I I I Bi[d 8
I ..... I
LochstreifenLochkortenGer~te
S~andardperipherie
fLir Prozel3rechner
ZE = Zentroleinheit
Bild 9
Lochstreifenleser mit Wickelvorrichtung
84
Bild l o Fernseh-Monitor mit mehrfarbiger ProzeB-Graphik-Darstellung BUS-STRUKTU R
S T E R N - STRU KTUR
4q 1 im
2
;T
ZE 1
2
. .
.
n
J
• 1
n =-ST
2 .
13
Bird 11 M6g[ichkeiten der ProzeBeinheitkopplung ZE = Zentraleinheit
ST= Steuerung
SF= Signalformer
I I l ~ , Im
85
ZE : Zen(raleinheit LA : Leitungsanpassung Ootenverbindung S~S~
ZE
D
l - - - F ~ serie[I
~
poratlel
{ ~
' I
J (TF'Kabel)
STS = Steuerung for synchronen Do~enverkehr noch Prozedur
h ZE
STA :Steuerung for asynchronen Datenverkehr
rietl ' e~on(eitung)
Biid 12
M6glichkeiten der Rechnerkopptung
ZE : Zentroleinheit LA : Leitungsanpassung PE
PE : Periphere Einheit ST = Steuerung
I 5chleifenkonfiguration ZE
,qE]
parallel
~'~
seriell (TF- Kabel )
~
Asynchroner und synchroner Datenverkehr (Prozedur} reotisierber
~~-
seriell (Telefonleitung) Sternstruktur
Bird 13
M6glichkeiten der Peripheriekopptung
RELIABILITY AND INTEGRITY OF LARGE COMPUTER PROGRAMS C.V. Ramamoorthy, Department
i.
Introduction
i.i
Cost of software
R.C. Cheung and K.H. Kim
University of California, Berkeley of Electrical Engineering and Computer Sciences Computer Science Division Electronics Research Laboratory
It was not too long ago that programming was generally considered as an art. In these past few years, the emergence of the term 'software engineering' a major change of public opinion.
Programming
is not only considered as a science
but also as a branch of engineering where disciplines partly to more understanding pressure of economics°
can be enforced.
of the 'art' of programming
This is due
and partly to the strong
There was a time when hardware was king and every effort
possible was spent in improving
the utilization
However,
cost of the computer
the rapidly decreasing
rising salary of the human programmers improving
indicated
of the hardware of the computer. itself and the continuously
have compelled us to focus our attention on
the efficiency of software development,
For example,
software occupied
only about 25% of the United States Air Force budget for electronic data processing in 1960 (75% for hardware) while in 1973 software occupies about 80% of the USAF budget for EDP. fashion.
The cost of software is still rising continuously
This trend is expected to continue and the lopsidedness
hardware cost ratio is probably characteristic
of other organizations
Software has become big business in the United States. Air Force, an annual expenditure
too.
For the United States
of between $i billion and $1.5 billion has been
spent on software for the fiscal year of 1972. the total Air Force budget.
in a linear of the software-
[Boe 73]
This amounted
At present,
to about 4 or 5% of
overall software costs in the
United States are probably over $i0 billion every year, over 1% of the gross national product. 1.2
[Boe 73].
Problems of software Our past experiences with software development have been depressing.
the software development and cost.
projects are unsuccessful
Most of
in terms of specification,
The final software product delivered is often unresponsive
time
to the actual
needs of the organization
it was developed for.
but end up with another.
In many cases, a significant portion (up to 67%) has to
be rewritten,
after the system is delivered,
The users are promised one thing
in order to meet the operational needs
This research was sponsored by the Office of Naval Research Contract NOOOI4-69-A0200-1064.
87
of the users.
Delay in delivery is commonplace while gross underestimation
cost by a factor of four is not unusual.
For example,
one year behind schedule and was estimated
of the
the IBM 0S/360 was delivered
to cost more than 200 million dollars.
[Ale 69]. Big as these direct costs of software may be, the indirect costs due to delays and errors are even greater. all system development
Software is usually on the critical path in the over-
so that any delay in software delivery will directly upset
the schedule of the whole system, which is extremely expensive. management
Moreover,
can do very little to speed up the software development.
programmers
to a late project simply makes it later.
integration,
or documentation
To scrimp the testing,
cost much more in the long run.
Generally,
the simple solution adopted is to eliminate all expandable capabilities,
making the
system unappealing
procedures
the
Adding more
to the user.
This is especially true for many real-time
Not only is the software always late and expensive, is also very unreliable. them.
systems.
the final delivered product
Many software are released with thousands of bugs still in
Each new release of the OS/360 contains roughly I000 new software errors.
[Boe 73].
Even after the program is considered
18 discrepancies [Boe 73].
to be thoroughly
tested,
there were
found in the software during the 10-day flight of Apollo 14.
This becomes more scary when we consider
the complexity of the program
for national defense and air traffic control. 1.3
Reduction of software cost
1.3.1
Software-oriented
system design
From the discussion above we can see that cost and reliability major causes of concern about software. systems,
In many projects,
the software effort has to wait until the hardware is procured,
until the selection is made. constraints. procurement
Then the programs
This procedure has several disadvantages.
Besides,
The time spent on hardware
amount of indirect cost to the whole
see that as we approach 85% utilization software cost rises abruptly.
is shown in Figure i.
[Wil 70].
We can
of hardware speed and memory capacity,
The hardware constraints may drastically
the cost and time for software development.
the
increase
With the decreasing cost of hardware
and rising cost of software we have to avoid this unnecessary should make the hardware selection after we understand of software.
to
A typical study of the extent to which hardware
constraints affect software productivity
saturation point.
We
sufficiently well the
We would rather acquire a computer with 50% to 100% extra
capacity than to risk having a computer ware constraints
Any delay in soft-
the selection of hardware is made without much consideration
the software development.
requirements
or at least
are written under the hardware
pushes software farther out onto the critical path.
ware delivery will incur an unaccountable system.
are the two
especially real-time
too "small" for our purpose.
affect software development~
off to save on the more expensive software.
Whenever hard-
the cheaper hardware should be traded In order to get software off the
88
critical path, we have to initiate software development development programmed
cycle.
earlier in the system
The software should be specified first and a simulator or micro-
computer can be used to support the software development.
established
a solid basis in software development
its requirements, ware required
and have enough knowledge about
we will then give the detailed design specification
to support the software.
from existing systams,
a more up-to-date
of the hard-
The hardware can then be built, or selected
in parallel with the software development
this way, the hardware is more responsive
development
After we have
and testing.
to the need of the software.
technology and will probably be cheaper.
Besides,
In
It will use
hardware
requires less time than software and significant delays are rare.
-,-! -r'l
~ 0
m
•
0
~
u
Increasing
I
I
25
50
I
75
I
)
i00
Percent Utilization of hardware Effect of hardware utilization on software productivity
Figure I. 1.3.2
2
software productivity
Let us now look into methods to increase the software productivity individual programmer. productivity.
It is difficult
of each
to specify what is meant by software
A common measure is the number of source level instructions
that a
programmer produces per unit time, e.g., the number of Fortran statements per week. A study by Sackman factors up to 26:1. methods. [Sac 70].
[Sac 70] shows that the productivity The productivity
of a programmer can be improved
On-line programming may cause an improvement The selection of the right programming
special purpose language, may cause a productivity There are also tradeoffs between the productivity efficiency of the program produced.
of individuals may vary by by many
of 20% over batch programming.
language,
especially the use of
improvement
of several folds.
of the programmer and the
Other important factors that affect the
productivity may include stability of program design, amount of mathematical tructions, 1.4
number of subprograms,
Improvement
concurrent hardware development,
ins-
etc.
of program reliability
A careful reader may notice that all the factors discussed in coding of the program only.
Software development
3 phases: desisn, codin$ and testin$.
so far are involved
can be roughly divided into
A study [Boe 71] has shown that for large-
scale programs about 36% of software effort is spent in analysis and design,
19%
89 in coding and auditing,
and 45% in checkout and testing!
About half of the effort
is spent in removing errors made in design and coding of the program. improvement
Any
in the reliability of the program and cost of debugging will therefore
significantly
decrease the total software cost.
increasing reliability
The goals of reducing cost and by minimizing
the software
bugs introduced during the design and coding stages of the program.
In order to
investigate
can be achieved simultaneously
techniques for reliable programming we must first understand
of software reliability,
the characteristics
of large programs,
the meaning
and the nature and
behavior of software bugs. 1.4.1
Meaning of software reliability Software reliability
is a term that every programmer understands while
nobody can give a formal definition. in hardware reliability,
because of the basic differences the reliability
Although very meaningful work has been done
the theory cannot be immediately
in behavior and characteristics.
of a system is usually defined as the probability
function will be adequately performed for a specified general,
applied to software In hardware, that a specified
time by the system.
it is assumed that the hardware system is perfect
(100% reliable)
with and the components deteriorate with time, creating a probability In contrast,
the elementary components
does not change with time.
Besides,
of software are instructions,
these components
cannot fail.
In to start
of failure. whose behavior
Errors are not
caused by the failure of the elementary components but rather by incorrect combinations complicated
of them.
The interactions
than the interconnections
between these components are much more
of hardware components.
ware is put into operation with many bugs still in it. methods of measuring
the number of bugs in a program.
The piece of soft-
There are no feasible More complicated
still, even
when we detect a "software bug" and correct it, we are still not sure that the total number of bugs left in the system is decreased by one, since we cannot predict if our correction procedure has any side effects on the other parts of the program. The correction procedure
is not as simple as replacing
a faulty hardware component
with a good one. Serious effort has been attempted by many people in deriving a quantitative measure of the 'reliability' proposed.
Shooman
of a program.
Many reliability models have been
[Sho 73] proposed a model using a "software reliability
R(t) as the probability apparently borrowed Jelinski and Moranda
that the system will not fail up to time t.
from hardware reliability [Jel 73] have formulated
theory.
Other people,
similar models.
have been less than satisfactory because they completely behavior between software and hardware. between the parameters applicability
function"
This model is such as
All these attempts
ignore the differences
in
They failed to establish connections
of the models and actual software properties.
The
of such models is doubtful.
In here, we will not attempt to give any formal definition of the reliability
9O
of a program.
Instead, we will treat software reliability as a qualitative measure
and discuss different factors which will affect the quality of a program from a reliability point of view.
We will say that an error is committed
input value and the specifications
of the computation
if, given the
to be performed by the program,
the output value is either incorrect or indefinitely delayed. The reliability view.
of a piece of software may be evaluated from two points of
We can rate the reliability of a program by the "number" of software bugs
inherent in the program, implementation
i.e., the number of mistakes made during the design and
of the program.
Reliability
is therefore an inherent property of
the piece of software product and is subject to assessment by an analysis of the program.
However,
to quantitative
software bugs, like software reliability,
evaluation.
is not easily subject
It is not clear what is meant by the "number of soft-
ware bugs" in a program or how to measure it.
It has been suggested
that the rate
at which software errors are detected can be used as a projection of the number of software bugs still resident in the program. projection is still questionable. number of bugs in a program,
Moreover,
The accuracy and validity of such a even if we were able to measure the
there is still no convenient way for us to normalize
such a measure so that it can be used as a comparative
parameter
of the reliability
of different programs. We may also treat the reliability quality of service it gives to a user. evaluated by the correctness
of a program from the viewpoint
of the output that he receives.
program can therefore be defined as the probability
controlled by the program that performs the required the reliability
sequence of codes executed of the input parameters,
created)
(the process created)
this definition
function according
Therefore,
the correct result will
the reliability of the program should
to the distribution
of the given user environment.
Since the
is heavily dependent on the values
the probability of obtaining
seems to be a more reasonable
Since it is the process
computations,
of the process rather than the program.
depend on the input data selected. be a weighted
The reliability of a
that a run of the program will
give the desired output with a valid set of input data.
really measures
of the
To a user, the reliability of a program is
of the input data (the process
It depends on the user environment.
evaluation of the reliability
This
of the program because
there may be a part of the program that is full of bugs but rarely used.
These
software bugs will not affect the operation of most users and are therefore harmless. This definition of reliability activated by a set of input. criticality and penalty-cost
is related to the probability As an extension,
that a software bug is
we should also take into account the
of the software error.
A software bug in the missile
firing procedure of a defense missile system may make the whole program unacceptably unreliable,
even if the rest of the program is error-free.
The user-viewpoint The reliability
definition of software reliability
is not an inherent property of the program.
has other drawbacks. The incorrect
91
functioning
of a program may be due to some prosram independent
the program were perfectly coded, operator,
the compiler and assembler,
caused by the incompatibility resources may be requested truncation or imprecision extremely difficult of the variables. data-sensitive
errors.
Even if
there may be mistakes due to the key-punch and the operating
system.
Errors may be
of the program and the computer hardware.
than the computer can supply.
Too much
Bugs can occur due to
in the calculation by the hardware.
These errors are
to detect since they only arise with the "right combination" Other hardware malfunctions,
including
transient errors and
faults, will also give us the wrong result.
Input-output
oriented
errors are not uncommon since many devices have different idiosyncrocies. can also be c ~ s e d systems,
by parallel and asynchronous
operations.
typical errors may include resource deadlocks,
timing and scheduling anomolies.
Errors
In multiprocessing
storage encroachments,
These program independent
errors are particularly
serious to real-time programs and should be checked before the program is put into operation. operating self.
If we desire a reliable
system~ we have to take into account the
environment of the program besides the reliability
However,
from now on, we will only restrict ourselves
errors and discuss different
techniques
to minimize
of the program itto program dependent
these errors,
leading to a more
reliable program. 1.4.1
Characteristics Large programs
of large programs (or programming
systems),
as referred
ized by complex structure and many instructions. it is usually developed locations.
to here, are character-
Due to the size of the program,
by a large number of programmers,
sometimes
There will be a large number of program components with complicated
interactions.
It is very difficult for a person to have a good understanding
the whole system.
testing is unfeasible.
are not expected to be completely error free.
For this reason,
its reliability.
There are a number of differences
between small and large programming
as the methods of implementation,
phase structure,
tolerance to user abuse. different validation
systems,
such
expansion of the system, and
These will affect the extent and effectiveness
of
techniques.
Since the small system has limited authorship,
Consequently,
such programs
The number and critical nature of
errors or possible errors in the software product will determine
are homogeneous,
of
A large program will contain a significant number of possible
flow paths so that exhaustive
the implementation
techniques
i.e., similar methods are used to solve a given type of problem.
if a given method is validated for one occurrence,
for other occurrences. programmers,
in different
By contrast,
it is also validated
large systems are developed by large numbers of
each having his own way of thinking.
Problems
in communication may
prevent them from arriving at a common optimal solution for a problem. various implementation validation procedures.
techniques are used for the same purpose,
Instead,
requiring additional
92
The simple data structure of small systems is contrasted with the complex structure of data bases employed by large systems.
The former allows an intuitive
understanding of the use of data while the latter obscures the meaning and use of variable names and provides more opportunities for misuse of data.
It is also very
difficult to provide an effective data structure for a data base used by different programmers in a variety of ways. The phase structure of a system is another important aspect in validation. Small systems tend to have independent phases with limited interaction.
Consequent-
ly it may be possible to exercise all possible paths and check interactions by examining the data dependencies of each phase.
Large systems, however, will contain
complex interactions among functional tasks which are coordinated by a supervisory system.
Dependencies are expressed in the supervisory calling sequence.
For these
systems a thorough investigation of all paths is not feasible and more sophisticated techniques are required to validate interfaces. The expansion and modification of a system will require re-evaluation and validation.
For small systems this task is relatively simple since the effects of
changes are limited and easily traced. more far reaching effects and their
Modifications to large systems may have
acceptance by all other parts of the system
must be certified. The detection and correction of operational errors depends on the system's tolerance to user abuse.
Small systems are employed in a limited user community.
This implies adequate communication between developer and users to specify program requirements and locate faults.
On the other hand, large systems often have a
wide community of users and communication is hindered.
The detection of faults is
more difficult and subtle faults may be propagated through the system.
The
complexity of the system inhibits understanding by the user. The problems associated with large programming systems are largely the result of faulty integration of system components, due to communication problems among programmers and lack of understanding of the whole program.
The segmentation and
interaction between components of large systems presents several types of problems, including data integrity, interface problems, and ~equencing problems.
In addition
to these considerations, there are also errors common to smaller programs such as semantic errors, unreachable code, logic errors, etc.
The nature of errors will be
investigated in the next section. 1.4.2
Nature of software bugs in large programs In order to gain some insight into the nature of software bugs, let us
briefly review the typical steps of the development of a large software system: i) Specifications of the requirements of the system. 2) Design of the overall structure and decomposition of the program in flowchart form and the descriptions of the different software modules. 3) Coding of each software modules in some suitable programming language,
93 usually a "high level" language. 4) Debugging
of each software modules with testing sample data.
5) Integration of the tested software modules and debugging
of the whole system.
6) Check out of the whole system for delivery. In all the above steps there are sources of error. may be incomplete,
leading to ambiguities
The program specifications
or software bugs.
The designer may have
failed to understand fully the problem or have conceived a faulty algorithm. have overlooked
special cases of the input data.
there are even more errors. constructs,
not unusual.
etc.
During the coding of the program,
Errors may arise from incorrect semantics and language
such as the misspelling
mode operations,
of variables
and labels, incorrect use of mixed-
Logic errors such as "off by i" in indexing or shifting are
Array over-write and wrong initialization
The use of certain statement constructs Fortran are error-prone. for determination
are other eom~non errors.
such as computed GO TO statements
in
This type of statement depends on the value of a variable
of transfer locations.
A bug would cause the transfer
or to an unexpected part of the program.
Structural
etc.
to nowhere
errors of the program are also
cormnon, such as incorrect flow of control, unreachable program segments, path from a segment,
He may
no exit
An additional area of concern is that of loop termination.
A program loop may be executed an incorrect number of times or even indefinitely, depending on combinations
of variable values in conditional branches and limits of
explicitly defined loops. Difficult as it may be, these errors can be pretty well controlled with a little bit of care and patience from the programmer. arise from the faulty integration development
The real problems usually
of the software modules.
process in which a large number of programmers
This is due to a are involved.
An
individual working on a single system component may overlook certain obscure but possible conditions.
The lack of complete and rigorous
coupled with the misunderstanding
interface specifications,
of the scope or intent of component operation,
may lead to improper use or unforeseen
side effects.
The flow of information from
one component to another is often the source of interface errors. consider
the passing of parameters
in calling a subroutine.
and type of parameters are not consistent, modifications
to the parameters
incorrect parameters.
For example,
If the number, format,
the subroutine may make unexpected
or improper operation due to the passing of
In a large program errors can also arise from the improper
sequencing of operations,
which is obscured by the complexity
and number of flow
paths. The order of operations for a certain process may be changed when integrated with other processes.
For example,
a certain sequence may be disrupted
a routine which accesses and transforms data in if a second routine alters the same data.
Improper interface and sequencing may lead to errors in data integrity. integrity refers to the maintenance
Data
of proper data in correct locations at the
94 prescribed
time.
are destroyed, variables
Errors include overruning array bounds,
and non-alignment
of common data blocks.
of different names may cause the unexpected
variable when the value of its equivalent Therefore,
so that adjacent data Equivalences
between
change in the value of one
is altered.
we can see that the most common errors in implementation
scribed in roughly 5 major categories according i) Interfaces,
(2)
language constructs,
Sequencing,
(5)
(3)
Data integrity,
(4)
Semantics and
Structure and well-formation.
These are not intended to be all-encompassing and overlapping,
can be de-
to the place where they are found:
and there will be some interaction
but most errors are traceable to one (or more) of these problem
areas. 1.4.3
Behavior of software bugs in large programs In general,
the complexity of a system will depend on the number and inter-
action of system components,
while at the component level, complexity depends on the
number of branches and external references. is unfeasible.
Therefore
the design,development development
For a large program,
exhaustive testing
such programs always contain residual errors which survive
and debugging
stages.
of the progrmn may be expected
The occurrence of errors in the
to follow a general pattern as in
Figure 2. Initial use will uncover increasing numbers of errors as the system is used more frequently and to fuller capacity.
The correction of major errors will then
result in a gradual decrease in error detection until only infrequent The piece of software becomes "operational"
than a certain number epsilon, which represents to software bugs.
the level of tolerance of the user
It may seem strange to note that the number of errors that are
detected and fixed after the system is operational One may expect a monotonically effort,
errors occur.
when the rate of errors fbund is less
seems to be almost constant.
decreasing number of errors with our debugging
since bugs are constantly detected and removed from the program.
in the process of correcting a detected error,
introduce some subtle errors in other parts of the program, documentation
is not available.
However,
the programmer may unintentionally
A study by McGonagle
especially if good
[McG 71] shows that 19% of
the errors of a set of programs resulted from unexpected
side effects to changes.
Another reason for the constant error rate is that a large portion of the program is not tested or exercised.
Errors in this large portion of the code remain dormant
until much later. The behavior
of systems with several releases may present a pattern similar to
that of Figure 3, since every release represents specifications
and modification
a major revision of the program
on the program code.
If the residual type of
errors can be detected and corrected before a program is released for use, the peaks of these curves will be effectively reduced, level and reliability
of the program.
thus improving
the confidence
This is the objective of the evaluation and
95
validation process.
Operational o o o
Number of runs of the program (Cumulative usage of the program) Figure 2.
Oo=
Behavior of software errors
Release #i
Release #2
Release #3
o
I
I
Z
Time since initial release
Figure 3. 1.5
Errors in multiple release program
Conclusion From our discussion above, we can see that the main fundamental reasons for the
large number of errors are the complex system application, together with the large number of programmers.
the loose specifications,
The inefficiency
is due to the lack of software validation and evaluation
tools and methodologies.
The reliability of a program can be improved by 2 approaches: approach and the 'constructive approach'. developing more reliable software, defense.
of 'bug removal'
the 'analytic'
The latter includes methodologies
such as structured programming
for
and software
The former approach is primarily concerned with testing and validating
the program after it is written, using techniques ness and automated
such as proving program correct-
tools. In large real-time programs like those in ballistic missle
defense and air-traffic
control,
errors are very disastrous.
After the removal of
critical software errors, one still has to worry about the integrity of the program at the moment it is being executed in order to ensure the reliable operation of the
96
system.
Security measures have to be implemented
unauthorized
tampering of the program.
to protect the program against
All of these will be discussed in the
following sections. 2.
The analytic approach to improve software reliability The analytic approach is primarily concerned with the validation of the
reliability of the program after it is written. of the program after it is coded.
It is done through an analysis
Roughly speaking,
The first approach involves the proof of correctness means.
two approaches
can be taken.
of the program by some formal
A proof of correctness can, of course, establish our confidence on the
reliability of the program.
However,
size of the program is large. 433 Algol statements.
this approach becomes infeasible when the
The largest program proved by this method has only
[Goo 68].
The second approach has the more humble goal of
detecting and removing errors from the program. method of debugging. completely reliable,
This is the more conventional
Although this method can never show that a program is it is practical for a large program because a lot of the
techniques can be automated.
The computerized
debugging effort of the programmer.
assistance greatly facilitates
After the major errors are removed,
the
the
program may be quite reliable. 2.1
Proving program correctness The process of proving prosram correctness
is an analytic method tO show that
the program, with inputs satisfying some constraints,
will terminate and will
produce outputs which are specified functions of the inputS, provided that the program is correctly compiled and executed in a 'perfect computer'. computer',
we mean the Utopia of every programmer,
large enough for any program, off, underflow, consider
correctness provided
overflow,
the compatibility
By a 'perfect
with such features as a memory
an arithmetic processor with no errors due to round-
etc.
Although proving program correctness does not
of the program and the machine,
it does prove the
of the coding of an algorithm in a suitable programming
that syntactic errors are absent.
Hence,
on the reliability of the program and reduces
it establishes
language,
our confidence
the testing cost of the program.
In fact, most of the software errors are caused by the incorrect coding of the program by the programmer. Rigorously speaking, a proof of correctness termination. steps.
should include a proof of program
In practice, we may separate the verification procedure into two
The first step is a proof of partial correctness,
yields the correct answer if it terminates; termination of the program. Two approaches
(Some procedures
can be taken in establishing
i.e., that the program
the second step will be a proof of can perform both steps simultaneously.)
the correctness
of a program, namely,
by an informal proof, or by a formal proof utilizing a mechanical
theorem prover.
9?
2.1.1
Informal approaches
to proving program correctness
The approach towards an informal proof of program correctness dates back to the days of Goldstine and Von Neumann verified,
at least in principle,
[Gol 63], who noted that the program can be
if the programmer
can describe the state of all
the program variables after each step, or possibly after some selected steps, of the program. McCarthy
An inconsistency
at any point will indicate a programming
[McC 62, 63, 67], used a function-theoretic
error.
approach similar to this.
He
assumes that at the start of a computation each cell of the computer memory contains a number.
An ordered sequence of these numbers is the "state vector" of the
computation.
Each computer operation is considered as a transformation
existing state vector into another state vector.
Therefore
considered as a function in the state vector space. (conditional
the program can be
McCarthy
introduced a formalism
forms) for defining programs as recursive functions.
process of verifying
the correctness
function theory a1~ a method
of the
Afterwards,
the
of the program reduces to a problem in recursive
(recursion induction)
can be used.
Essentially,
reeursion induction is a set of axioms that can transform a recursively defined function into an equivalent approach
function.
McCarthy and Painter
such an approach by considering
a vector of symbolic values rather than numeric values, of -i, 2.3, etc.
Computer operations
obtain symbolic expressions Logical connectives
~_xpress the transformations approach,
the state vector as
e.g., X, Y, and Z instead
are carried out with these symbolic values to
such as X + Y and X - Y as new elements can be introduced
the conditions leading to different
The symbolic outputs therefore
the program performs on the input variables.
since there will he too many symbolic expressions,
very complicated
in the state
to accommodate branches by indicating
symbolic values.
known as the proof of algorithms by seneral snapshots
is unpractical become
have used this
to verify a very simple compiler.
Naur [Nau 66], generalizes
vector.
[McC 67]
This
(state-vectors), each of which
can
even for a small programl
A natural simplification only the transformations
of the above procedure to make it practical is to trace
of important variables
and to develop symbolic expressions
for these variables only at strategic locations within the program.
Hence, we are
using only a subset of the elements of the state vector and the "stat~' of these variables are updated only after some computations, operation.
Therefore,
"assertions" program.
not after each computer
the sequence of specified state vectors becomes a set of
about the relationships
The process of verifying
of important variables
the correctness
scattered
through the
of the program becomes a proof
that each assertion is true every time it is reached by the program.
In order to
]prove an assertion, we can assume that all previously reached assertions There is no well-defined general,
procedure
to formulate and locate these assertions.
there is a tradeoff between the complexity of the assertions
number of assertions
are
that we have to use.
Floyd
[Flo 67]
develops
true. In
and the
the logical
98 foundations for the informal-assertion method of proving program correctness, and subsequently suggests how the process of verification can be mechanised.
Let us
illustrate with an example the process of assigning assertions to a flowchart program and the proof of consistency of an assertion as a function of the previously reached assertions. Example: This simple example illustrates the informal inductive assertion method of proving program correctness.
This program divides a positive integer X by another
positive integer Y by repeated subtraction. remainder.
Let Q be the quotient and R the
The flowchart of the program is shown in Figure 4.
~ ¢
: (X>0) A ( Y > 0 )
I N+-X' Q+-02 .... s~l:
1 (X=QY+N) A (N ~ 0)
7
s
l
"6q
[
Figure 4:
Flowchart of the example
The input assertion, denoted by ~, specifies the domains of the input variables and the relationship between their values. (X > 0) A (Y > 0).
In this example,
the input assertion is
The output assertion, denoted by ~, specifies the desired
relationship between the output variables and the input variables, i.e., the desire result from the program. (X = QY + R) A (0 ! R < assertion
In this example, Y).
the output assertion is
By examining the program we conjecture that the
(X = QY + N) A ( N ~ O)
must be satisfied any time the program control
is at point Q . In order to prove the correctness of the program by the inductive assertion method, one must show that the truth of the assertion at the beginning of each path of the program, followed by the execution of the path, implies the truth of the assertion at the end of the path.
First of a%l~ we must show that ~, together with
the execution of the path (1, 2), implies that ql is true, i.e., (X > 0) A (Y > 0), together with the execution of
(N ÷ X) A (Q ÷ 0)
implies
(X = QY + N) A (N ~ 0).
It does not take too much effort for the reader to see that this is true. ql
is satisfied when control first passes to point O "
Therefore
Next, we must show that if
is satisfied any time control is at point ~,__ then ql must also be satisfied ql whenever (if at all) control returns to point Q . Therefore we have to show that ql' followed by the execution of the path (3, 4), implies ql itself,
i.e.,
99 (X = QY + N) A if N > Y.
(N~
0)
is still satisfied
after the operation
(N ÷ N-Y) A(Q ÷ Q+I),
This is obviously true since X = QY + N can be rewritten
X = (Q + I)Y + (N - Y) and (N - Y) ~ 0 since N ~ Y. matter how many times the loop is executed. result is indeed produced.
ql is satisfied no
Now we must show that the correct
We have to show that ql' followed by the execution of
the path (3, 5, 6) implies ~, i.e., the operation R ÷ N, implies that very easily.
Therefore,
as
(X = QY + N) A
(N ~ 0) A
(N < Y), together with
(X ='QY + R) A (0 ! R < Y).
The partial correctness
This can be verified
of the program is therefore validated.
question of termination of the program can be answered easily by observing loop can only be executed a finite number of times since every time the loop is executed and
Y > 0.
N
The
that the
is decreased by
Y
The correctness of the program is hence
established. After the example, systematic way.
let us describe the inductive assertion method in a more
As presented here, the formulation is as described by Good.
A program is a finite ordered set of statements,
with the first statement as start
and the last one as halt, and the remaining statements as null, assignment, way branch statements.
An assertion is a predicate attached
The first assertion is the input assertion, and specifies values.
denoted by ~.
of statements
denoted by *.
the desired result from the program.
(SI, $2, ..., Sn)
or two-
to a point in a program.
It is attached
the domains of the input variables and the relationship
The last assertion is the output assertion,
to halt, and specifies
[Goo 70].
to start,
between their
It is attached
A ~ath is a sequence
such that it is a valid execution sequence of the
program. Let (S I, S 2, " ' ' ' u S ) be a path with assertion ql attached to S 1 and assertion q2 attached
to S n.
The path is said to be verified
satisfied if ql is satisfied at the beginning SI, $2, ..~, Sn_ 1 are executed.
of the path and the statements
A verification
condition for a path is the condition
that must be satisfied in order to verify the path. the program consists of choosing and attaching
if it can be shown that q2 is
The proof of correctness
the inductive assertions
locations and of verifying all the paths in the program by constructing the verification
for
at different and proving
conditions.
The first step of the process is to choose a subset C of statements from the program to which assertions have to be attached. first
(start) and last (halt) statements,
loop in the program. is to allow breaking
The set C should contain the
and at least one statement from every
The reason for choosing at least one statement from each loop the program into loop-free paths.
to supply the assertions for every statement in C.
Then the programmers have
The assertions will include
and ~.
The choice of assertion is very closely related to the choice of statements
for C.
The assertions can be quite simple if they are appropriately
Therefore,
located.
it requires much insight of the programmer about the behavior and
structure of the program.
Still the method of choosing assertions
is more like an
i00
art than a science and no general guideline seams feasible.
It is similar to the
choice of the induction hypothesis of mathematical induction.
Therefore, this is
the most difficult part of the process and it does not seam hopeful that this part can be automated, although it can be computer-aided. After the assertions have been supplied and attached to the program, we have to construct a verification condition for every path that proceeds from one assertion ql (a statement in C) to another q2' with no other assertions in between. Therefore, the verification condition depends on the initial and final assertions, together with the operations performed by the statements in between.
The forward
accumulatiom method of construction of a verification condition is presented here. The verification condition of a path P is formed as ql A (assignment terms) A (traversal conditions) ~ q 2 ' where the assignment terms are the operations of the assignment statements along the path and the traversal conditions are the logical conditions for the branch statements along P under with the path P will be taken.
The assignment terms and
traversal conditions do not include the last statement in the path since the assertion q2 has to be satisfied before the statement to which it is attached is executed.
The construction of the verification conditions can be fully automated
by using predicate calculus.
Afterwards, the conditions can be mechanically
proved in order to validate the correctness of the program, if the program is indeed correctly coded. Systems have been implemented to automate part of the process of proving program correctness.
The philosophy is to let the computer take over as much of
the burden as possible.
Two of the most well-known ones are that implemented by
King [Kin 69], and by Good. [Goo 70].
King's Program Verifier only accepts a
special Algol-like language, with only integer variables and one-dlmensional arrays. Relational operators ("greater than", etc.), "GO TO"s, and logical connectives ("and", "or", etc.) are included. by the programmer.
The verification conditions are generated automatically using a
backward traversal of the path. these conditions. implemented.
The assertions are Boolean expressions supplied
An automatic theorem prover is then used to prove
King's system is the most automated system of this kind yet
Good's system, on the other hand~ is an interactive Program.
uses a programming language similar to King's.
It also
Assertions are manually supplied.
The verification conditions are automatically generated by the system. programmer then supplies proofs of the verification conditions.
The
The proofs are
accepted by the system without question and stored in the computer.
When all such
proofs have been supplied, the computer outputs the completed proof. The proof of program correctness by such an approach has certain degree of success.
However, it can only be applied to programs of relatively small size.
The largest programs proved by hand using such an approach consist of several hundred instructions.
The most automated systems have only proved programs of less
101
than a hundred instructions.
Besides, many of the assertions and the proofs have
to be supplied by the programmer himself. the program.
This process is as fallible as writing
In order to make advances in this area, it seems that a completely
mechanical verifier is the only foolproof approach. will require more formalism in the proofs.
Such fully automated approach
In the next section we will briefly
describe some of the formal approaches to the proving of program correctness. 2.1.2
Formal approaches to proving program correctness As concluded in the last section, it seems that a formal mechanical approach
to program verification appears to be the most reliable, although the efficiency is expected to be low.
The verification of a program can be reduced to the proving of
a theorem in the first-order predicate calculus.
Speaking very informally, the
first-order predicate calculus is a formal system which consists of constants, variables, functional constants, predicates, (false), the logical symbols
A,
V,
~,
D,
the logical constants T (true) and F ~, V, and
3,
which can be combined
to form well-formed formulas of first-order logic according to some rules with the aid of commas and parentheses for punctuation marks.
(A formal and complete
description of formal logic is beyond the scope of this paper. are referred to the discussion by Manna.
[Man 69a]. )
Interested readers
With this in mind, the
section attempts to give the reader some intuitive feelings about the formal approach. The discussion will be very informal and interested readers are encouraged to read the referenced papers for a more rigorous and complete treatment. Most mechanical theorem-provers for first-order logic employs the resolution principle.
This is an indirect proof of a theorem: we assume the negation of the
theorem and try to derive a contradiction.
There are systematic methods to construct
such a proof and the process can be made more efficient by introducing some heuristic procedures.
This resolution process works very satisfactorily if the conjectured
theorem is indeed true, but very inefficient otherwise. Manna [Man 69b] has proposed a formal approach to proving program correctness. He shows that one can set up well-formed formulas in the first-order predicate calculus corresponding to an arbitrary flowchart program.
In order to facilitate
the conversion, the program is expressed in a standardized form such that for every program statement i, we can define a well-formed formula W i.
(Wi is very similar
to an "assertion" in the Floyd-Naur sense and qi is the predicate associated with Wi.)
A well-formed formula [P, ~] is then formed as ql A W1 A W2 A "'" A Wn
where ql is an unspecified predicate associated with W I.
Then Manna's Satisfiability
Theorem states that the program P is partially correct with respect to ~ (input assertion) and ~ (output assertion) if and only if Wp[~, ~] is satisfiable (i.e., is true under some interpretation of the predicate symbols qi' for example,as the Floyd assertions), where
102
w [~, ~]: P
( V x) {¢(x)
o
[P, ~1 (x)} .
We can see that this theorem is essentially equivalent to Floyd's results. The more important work is the Unsatisfiability Theorem program P is correct with respect to @ and ~ if and only if
which states that the Wp[6, ~]
is
unsatisfiable (i.e., is false under every interpretation of the predicate symbols qi ) , where
Wp[~,~]:
(3 x) {~(x)
A[P, ~ 1
(x)} •
Therefore, a program can be demonstrated to be totally correct in a single proof process.
However, the disadvantages of this approach is that the theorem prover is
very complex and the entire program is treated as a single entity and thus decomposition of theverification process is impossible.
It also requires the
program to be written in a special language so that a well-formed formula W i can be easily generated from statement i. The interest in the formal proof of correctness of programs has produced a new area of research, that of automatic program synthesis. been done by Manna and Waldinger [Man 71].
Much interesting work has
The programmer would only supply the
input-output relationship of the desired program, together with some assertions about the program algorithm.
Theorem-proving techniques can be used to prove the
correctness of the assertions and the proof itself can be used to build the desired program. 2.1.3
This program, generated by the computer, would hopefully be free of errors. Conclusion An assessment of the techniques for proving program correctness has been
discussed by Elspas et al. [Els 72].
The reader is also referred to the complete
bibliography of London [Lon 70] for more information. infeasible for any sizable programs. [Lin 72].
All these techniques are
In order to make meaningful advances
in this field, more research works are still needed in the field of formal specifications of programs, formal semantics of programming languages, and mathematical theory of computation.
A concise and precise specification of the program will
allow us to know effectively what the correct program should do.
Formalization of
language semantics will allow us to convert a source-language program into a canonical model easily.
Mathematical theory of computation enables us to develop
the verification conditions and the proof of the program.
Before any significant
breakthroughs have been achieved in these areas, mechanical verifiers will continue to be very inefficient.
Automatic program synthesis will be a very distant goal.
In the meantime, we just have to settle for the use of the informal techniques for proving program correctness.
Though inefficient, these techniques are very
effective when we integrate the proof with the program design, especiallywhen applied selectively to the critical sections of the program.
They are also useful
for the testing of small modules of the program before integration.
However, these
I03
techniques are subjected to human errors and are very 'unreliable' for large programs.
Automated software evaluation and validation systems seem to be the
more feasible analysis tools for large programs. 2.2
Automated Evaluation and Partial Validation
2.2.1
Introduction The current trend in software shows an increasing demand of the large real-
time software.
At present, the techniques in proving program correctness are
infeasible to solve the problem of reliability in large software systems. Naturally it has become necessary to use a more cost-effective and practical approach.
In order to analyze any sizable programs efficiently, computer
assistance becomes essential.
Since a complete validation of the correctness
of a program is impractical, we will only aim at a partial validation of the program, using techniques that are subject to a high degree of automation.
The
objective of automated evaluation and partial validation is to achieve an acceptable degree of assurance of the reliability and performance of the produced software to be put into operation. The characteristics of any computing system can be classified into two categories:
the structural characteristics and the behavioral characteristics [Ram 67].
A program is usually specified by its behavioral properties, such as the relationship between its inputs and outputs.
The structure of the program, however,
is usually left to the discretion of the designer.
The program can then be looked
upon as the superposition of behavioral characteristics of the components on its structural form.
The complete validation of the program means to verify the
correct operation of the system for all possible inputs, by obtaining and evaluating the complete behavioral characteristics.
However, the collection and
examination of all behavioral characteristics is practically an infeasible task, especially in the case of a large program. A more feasible approach would be to decompose those characteristics into a certain number of classes and then to validate each class of characteristics to a limited extent.
This is the basic idea underlying the partial validation.
Decomposition of behavioral characteristics is a non-trivial task.
Fortu-
nately, the careful examination of the structural characteristics reveals various useful informations which could help devising the decomposition scheme and the validation strategy.
Naturally, the analysis of structural characteristics forms
the important initial basis for most automated evaluation and validation systems (AEVS). 2.2.1.1
Error detection techniques
Different types of software errors in large programs have already been discussed in section 1.4.2.
Most of them have to be detected and corrected
during the debugging phase of the program.
Considerable attention has been given
104
to debugging systems, resulting in sophisticated techniques for trapping and tracing variable values, interactive step-wise execution of programs, and many other features [Rus 71].
These conventional systems have been successful in pro-
viding very useful aids to programmers in correcting errors.
However, there are
certain limitations which present problems in debugging large programs.
For
example, the amount of information necessary to determine long and complex paths through a large program may be prohibitive.
Additionally, debugging systems are
basically designed to £race the source of known errors which occur during execution with various test cases.
Therefore~ they do not necessarily predict errors
or possible errors. Efforts to detect residual errors must go beyond traditional debugging systems to provide a more complete program analysis.
Various techniques employed
in validation systems are now discussed. (i)
The checking of component interfaces requires a description of the
system structure and detailed information on parameters and information passed between components~
Graphical analysis is particularly useful in this area
since it provides a means of displaying the program structure at various hierarchial levels.
The interrelation and interdependency of components can be
determined from this graphical representation and, together with lists of the data passed, can be examined to uncover interface errors. (2)
Sequencing errors can be detected through the automatic extraction from
program code of certain specified events.
The flow paths defined by these
sequences of events can be compared with the proper sequences. (3)
The problem of data integrity necessitates a detailed examination of
variables and their use throughout a program.
This includes a mapping of data
common to various components, locations where this data is used and modified, etc.
This information can be used to detect such errors as unauthorized use or
availability of data.
The use of execution-time monitors is also important in
checking the values of critical variables such as array indices, conditional branch expressions, etc. (4)
Semantic errors and error-prone constructs can largely be detected by a
detailed examination of the program source code.
This is most easily accom-
plished by an automatic language processor which examines each program statement, recording pertinent information and recognizing the error-prone conditions peculiar to that language, (5)
Program structure is easily determined by graphical techniques as
previously mentioned.
The graphical representation can be examined for its
connectivity characteristics, thus exposing errors in the well-formation of a program. From the above description, it is evident that many of the residual errors present in large systems can be detected using the techniques outlined.
It is
105 assumed here that, once detected~
these errors may also be easily corrected.
These techniques are used throughout However,
the structure of the large validation
error detection is only one of the functions
of any AEVS.
system.
The other vali-
dation functions are discussed in the next section. 2.2.1.2
Validation
functions
The correct operation of a large real-time software system has two aspects. The system not only has to produce the correct output for the given input but also has to satisfy the performance space constraints,
etc.
requirement
Therefore, validation
roughly into two groups:
such as execution time bound~ functions can be classified
erro T d iasnosis and performance verification.
former is supported by a d i a g n o s i n ~ a i d an evaluation aid system.
The
system~ while the latter is supported by
The AEVS is an integration of both aid systems.
The implementation of these functions has appeared in various forms: debugging~
simulation,
formal proof of program correctness,
Here testing is a systematic process which mainly determines exists, while debugging
validation According either
them.
to error detection.
This doesn't mean that software
the
testing is
As will he seen later, it can support other
functions such as error location and performance verification,
too.
to the type of the function it provides it is further characterized
functional
testing or performanc ~ testing
The essential requirement bility to automation.
a large software.
as
[Elm 71].
for an effective validation process is the amena-
Software testing is extensively
due to its high adaptiveness
2.2.1.3
that an error
is regarded as a fellow-up process which localizes
cause of errors and corrects restricted
software testing, etc.
employed in most AEVS's
to automation and its effectiveness
This and other processes
are discussed
in validating
later in detail.
Structure of the AEVS
The common philosophy
in most AEVS's is to provide automated
relieve the programmer of collecting characteristics
data about both structural and behavioral
and assist him in evaluating
those systems are generally of two types. validation
the collected data.
One is a hierarchical
in which each module is (partially or completely)
then the validation of module interactions a hier@rchical
top-down validation
tools which
and interfaces
in which validation
program and proceeds to the smaller segment
Strategies
in
bottom-up
validated
follows.
first and
The other is
starts with the global
(or module) with the increasing
assurance. Each of these two has its own advantages and suitable application ments.
environ-
Where the program contains abundant bugs, the bottom-up approach will be
more effective since validation can proceed in more straightforward out much interference
from multiple errors.
approach will be more cost-effective
fashion with-
On the other hand, the top-down
where the program is expected to have a small
i06
number of bugs. correct.
In this paper we assume that the program is at least syntactically
Although not essentialj the top-down approach is implicitly adopted in
several places. From the implementation point of vlew~ an AEVS consists of two parts: anal~sls and dynamic analysis.
static
The static analysis is the validation process
performed only by examining the external form of the software, i.e. code itself, without executing it.
It reveals most of structural characteristics.
able amount of behavioral characteristics are also verified by it.
A consider-
On the other
hand, the dynamic analysis is the process of software testing performed by running the software with the devised test inputs and evaluating the output results.
Its
function is to validate various behavioral characteristics which cannot be efficiently identified by the static analysis.
The performance of the dynamic ana-
lysis is enhanced on the basis of informations provided by the static analysis. Various techniques employed in both parts are discussed in subsequent sections.
Most of them can be found in two representative systems, ACES [Mee 73,
Ram 73a, Ram 73b] and PACE [Bro 72a, Bro 72b].
Before going into those vali-
dation techniques, techniques of modelling programs are examined since the efficient program model is a cornerstone for automated validation. 2.2.2
Overview of Program Models The purpose of modelling programs is to obtain an easy-to-use representation
of only those informations relevant to the intended analysis, while unnecessary details are masked.
The model must be simple.
and manipulated in a computer.
They must be easily represented
The representation of the process must be homo-
geneous such that the same analytical tools can be used at any level.
This implies
that by choosing the proper level of representation, details not useful for the problem at hand must be masked out.
Another important requirement is that the
modification on the program being modeled should not be cumbersome in simulation. Since the structural characteristics serve as useful guidelines for the costeffective validation~ the model should be suitable for an efficient structural analysis. Among various models three representative ones are briefly reviewed in this section:
finite-state-machine (FSM) model, decision-table model and directed-
graph model [Ram 71b]. 2.2.2.1
FSM model
In this model, the computer (the sequential machine) is taken from state to state by a transition table (procedure) and a set of inputs (data).
Therefore
all behavioral characteristics are embedded in this model without being abstracted. It is evident that the size of the model becomes unmanageable in the case of a large program due to the rapid increase in the number of states.
Although
107
certain formal proof techniques benefit from this model
[Man 69b], the inability
of the model to contend with a sizable program is a serious drawback. 2.2.2.2
Decision-table
model
In this model, a program is represented by a decision table [Kin 67]. rudimentary
decision table is illustrated
in Fig. 5.
Action i Condition i
Y
N
Condition 2
Y
-
Condition 3
N
Fig. 5 The vertical
-
Example of a decision table
coordinate lists a set of conditions
all possible combinations. be taken by the program. statements.
The horizontal
that may or may not occur in
coordinate lists a set of actions to
These could be different procedures
or merely GO TO
Each column of the table indicates the subset of conditions
must be satisfied Y
Action 2
if the action listed under that column is to be carried out.
stands for yes and
N
stands for no, and a dash (don't care symbol)
fies that the ]particular condition involved is irrelevant corresponding
that
signi-
to the action in the
column.
A decision table contains less information for the same logical process.
than a corresponding
flow-chart
A flow-chart of a conditional phrase contains the
logical rules of the problem and also specifies the order in which various will be carried out.
The decision table does not indicate how the logic should
be structured in terms of program steps. exploration
Consequently,
and analysis of the structural
drawback making the model inefficient
the program and an assistance Directed-graph
characteristics.
in generating
In this model,
directed graph where each node corresponds a possible
When each node represents
statementsj
a large pro-
of the logical correctness
of
model
tually simple and natural.
node.
This is the major
test inputs.
This model has its root in the flow-chart.
directed arc represents
it doesn't support the
for the purpose of validating
gram, though it provides a partial verification
2.2.2.3
tests
The representation
a program is abstracted
is concepinto a
to a set of statements and each
transfer of control from one node to another
one statement or a set of sequentially
a graph model of a program is called a program graph.
example of a program graph is shown in Fig. 6.
executed
A simple
i08
t" i k_ 2
Vl = PI I=0 50
I = I+i V2(1) = P2(1)
3 k_
IF (I.EQ.10) GO TO I00
4< 5
--GO TO 50 I00 V3 = SUM(V2)
6
IF (V3.GT.100) GO TO 150
7<
--GO TO 200
(- 150 --8 k_ GO TO 200 ( - 2 0 0 Vl = VI+V3 9 k_ RETURN Fig. 6
Example of a program graph
This model clearly reveals structural characteristics of a program, while unnecessary details about functional characteristics are masked out.
Necessary
functional characteristics are selectively associated with each node depending upon the intended analysis.
All possible paths, loops, entries and exits can be
easily detected. The size of the program graph is generally in direct relation with the size of the program.
The complexity of the analysis increases more rapidly with the
size of the program graph.
Therefore, it becomes desirable to devise a procedure
by which a large object can be attacked piece by piece where the size of each piece as well as the complexity of its analysis becomes more manageable. niques of iterative abstraction have been developed. contains two aspects:
Tech-
The iterative abstraction
loop abstraction and link-subgraph abstraction.
a program has often been an obstacle in efficient validations.
A loop in
It contributes
to increases not only in the number of logical paths and the structural complexity but also in the undeeidable properties.
The separation of a loop and the manipu-
lation of a loop independent of the one of the rest of the program graph makes the total validation process simple and uniform.
This is the motivation behind the
loop abstraction. A maximal strongly q onngeted (MCS) subgraph is a strongly connected subgraph that includes all possible nodes which are strongly connected with each other. The replacement of every MSC subgraph in the program graph by a single node transforms the program graph into the reduced program graph (RPG) [Ram 66, 67]. shows the RPG corresponding to the program graph of Fig. 6.
Fig. 7
~09
CD i
Fig. 7
The RPG of the program graph of Fig. 2
This loop abstraction contributes to the significant reduction in the size of the model and the structural complexity.
If further abstraction is desirable due to
the large size of the RPG, then the link subgraph abstraction can be applied.
A
link sub~raph is a subgraph that contains no strongly connected subgraphs or unconnected subgraphs in it [Ram 67].
Fig. 8 is the result of the application of
the link subgraph abstraction to the RPG of Fig. 7.
This is called the basis
sraph.
? l
(5,6,7,8,© Fig. 8
The b a s i s g r a p h of t h e program graph i n F i g . 3
On t h e b a s i s o f t h i s m o d e l l i n g t e c h n i q u e , v a r i o u s a n a l y s i s can be p e r f o r m e d . t n g e n e r a l , t h o s e can be c a t e g o r i z e d i n t o two t y p e s a c c o r d i n g to t h e o r d e r o f abstractions analyzed: strategy is as follows. analysis. necessary.
top-down and bottom-up.
The basic idea of top-down
First~ the basis graph or RPG is used by the first-step
As a result, the more detailed analysis of a certain node becomes Then the subgraph corresponding to this node is taken for the next-
step analysis.
If the subgraph is a link subgraph, there is no difference between
the first-step analysis and the second-step analysis.
If it is a MSC subgraph,
then the technique can be applied for ~pening the loop with the removal of feedback arcs [Ram 67].
This is illustrated in Fig. 9.
110
?
Fig. 9
Loop opening and reduction
Thereafter the modified subgraph can be used by the second-step analysis or abstracted into the RPG and then analyzed.
Therefore~ the analysis is
essentially of iterative nature. In the bottom-up strategy the analysis proceeds in the reverse order of the top-down analysis.
Subgraphs at the lowest level are taken for the first-
step analysis and abstracted into a node in the graph model for the next-step analysis.
The graph model used by the last-step analysis is the abstraction of
a total program. A number of techniques for manipulating the graph model by the computer are available.
Some basic ones appear in Appendix A.
In the rest of the discussion,
this graph model is used as a basis in describing various validation strategies. 2.2.3
Static Analysis As mentioned earlier, an organized validation effort can be developed
using the two step approach: static analysis and dynamic analysis.
The former
is based on the examination of the program code while the latter is based on the test runs of the program.
The static analysis part of the AEVS is discussed
here and the dynamic analysis part is discussed in section 2.2.4. The main objectives of the static analysis are (i) to analyze the program for the detection of various semantic and structural anomalies~ and (2) to provide backgrounds for the efficient dynamic analysis.
That is, various structural
characteristics are identified and unreliable constructs are pointed out as the target of the dynamic analysis.
In pursuit of these objectives, a large amount
of repetitive scanning processes are involved.
In order to increase the effi-
ciency of the analysis, the generation and use of the data base are common to most AEVS's.
Therefore~ the static analysis contains three ma~or aspects:
data base generation, structural analysis, and detection of vulnerable constructs. 2.2.3.1
Data Base Generation
The construction of a data base is intended to provide a convenient means of retrieving various program characteristics.
The philosophy here is to
111
relieve both the program investigator and the analyzer of the tedious process of examining program listings for information required to validate the program. Furthermore, it forms the basis for other validation techniques, thus eliminating much duplication of effort. For the sake of clarity, the discussion on data base proceeds with typical examples rather than general arguments. two systems, ACES and PACE. following components:
Most of the examples are extracted from
Typical examples of data bases consist of the
symbol table, symbol use table, statement type table, global
storage map and the program graph. The symbol table and symbol use table are illustrated in Fig. i0.
Name
Symbol Table (HashCoded) Module # Type Pointer
VARIABLEI
II
Symbol Use Table K St~ement# Bkwd. Ptr. Fwd. Ptr. II
0
12
l
13
,
~
J
~
II ~-- 12
Fig. i0
13
0
Examples of symbol and symbol use tables
The symbol table normally contains information regarding all variables, items, functions, macros and labels used in a program.
An entry in this table consists
of the symbol n~me, module number, type and linkage to the symbol use table. On the other hand, the symbol use table contains a record of each use of a symbol name in a program.
An entry consists of an indicator for the type of use
(either input or output to the statement)~ the statement number in which the symbol was used, and linkage to other references to the symbol contained in the table. The use of a hashing technique seems to be suitable for providing an
112
efficient access to the symbol table.
That is~ the address of the storage where
a symbol name is stored is determined by the hash-coding with the character code for the characters making up a symbol name.
This technique provides a good dis-
tribution of table entries and a rapid access to any particular entry.
The
linked list structure of the symbol use table provides immediate access to the chain of occurrences references)
for each symbol name, while information
pertaining
(llst of symbol
to a given statement are grouped in sequential locations
of the table. These two tables provide complete static information on all program symbol names and statements in a neat way and allows the retrieval of answers to questions such as the following. (I)
Does variable
V.
appear as an input
(output) to any of the following
l
statements:
sl,s2,...,Sk ?
(2)
In what statements does
(3)
What are the inputs
V.
occur?
(4)
Does any variable appear as an output and not as an input?
(5)
What are the inputs for conditional
1
as outputs?
(outputs) to statements
branch
What are the inputs to these statements?
Sk?
s°? Where do they appear l (In this manner the user
can determine which variables and statements affect the outcome of a conditional branch statement.) This information anomalies.
is important in the analysis of semantic properties
Moreover,
it is an useful aid to implementing
program modifications,
and changes in programming
and
changes in syntax,
practices.
For example~
the
effects of changes in a program variable, macro or label can be easily determined by accessing the list of references
to that symbol in the program module
and other related modules. The statement type table is simply a list of codes indicating type of each statement
in the program.
stored either in a connectivity matrix
The logical structure of a program is [Appendix A] or in a successor table, a
modified version of a connectivity matrix.
This is shown in Fig. ii.
*ointer
program graph
successor
link
i
3
1
2
2
4
2
3
I
3
6
3
4
2
4
7
4
7
0
5
8
5
5
0
6
9
6
6
5
7
0 pointer-array
Fig. ii
the statement
0
7
7
0
8
7
0
9
7
0
Storage of program structure table
113
The successor table consists of a pointer-array and a table. contains an entry for each node. entries in the table. node.
The pointer-array
Each entry consists of a pointer to a chain of
Such a chain represents all possible successors of the
That is, a row in the table contains a successor node and a pointer for
chain linkage.
For example, an entry for node 3 in the pointer-array of Fig. 2
points to the chain of successors
(6,5)
in the table.
This table together
with symbol and symbol use tables are used as the basis for the extraction of structural characteristics of a program. As mentioned earlier, integration of independently developed modules is the source of a large number of errors.
A substantial portion of these errors can
be detected by the static analysis.
For this purpose, information on global
storages and interfaces needs to be stored in the structural data base.
Those
information are typically stored in two tables, a common table and a module interface table. A module interface table consists of an actual parameter table and a formal parameter table.
Fig. 12 illustrates a graph representing module interfaces
and the corresponding module interface table.
module interfaces called module 2 3 4 4 5 6 ...... 5 6
calling module
2 3 4 5 6
actual ~arameters -+ -+ -+ -+
Var. Var, Var. Var.
1 2 3 4
in symbol table " " " " " " " " "
101 102 103 104
in symbol table " " " " " " " " "
An actual parameter table called module
formal tarameters
2 3 4 5 6
--+ Vat. -+ Var. --+ Vat. --+ Var.
A formal parameter table Fig. 12
An example of a module interface table
114
This table together with others provide a convenient means for the detection of various structural flaws and semantic anomalies.
It is a simple matter to check
the consistency of types and numbers between actual parameters meters and to detect the recursive calling~ the determination
etc.
Moreover~
and formal para-
they can be used for
of the affected areas when a few modules are modified.
A common table consists of a common storage table and a common variable table.
An example a p p e a r s i n block name i I
storage address
Fig. 13. variable name A B C B D
)ointer
5O
'i'2o 2 2 2,, 2
5O 51
link
?
60 70
common variable
common storage table Fig. 13
statements
in the source program.
one row for each continuous
table
An example of a common table
These tables are constructed by examining all declaration EQUIVALENCE)
module number i 2 3 2 2
dimension 2 2 2 48 70
and homogeneous
(especially COMMON and
The common storage table contains
segment of global storage.
In Fig.
13, memories i and 2 in a block 1 are always referenced by the same variable, i.e,, by A in module i, B in module
2, or C in module
3.
The third column in
the common storage table contains a pointer to the set of common variables referencing
to the storage segment.
The common variable
table contains informa-
tion regarding variable name~ dimension and module number for each common variable.
An array type of common variable is sometimes divided into several
rows in the table when the referenced common storage is divided into several rows in the common storage table. example.
The common variable B of module
On the basis of these and other tables, procedures
the detection of misequivalencing, variable type or dimension,
unnecessary
[Bro 72b].
information required by various validation procedures,
also a strong assistance
in maintenance
and modification
of a program.
but
Thus it
to take the generation of the data base as an integral part of
program documentation. 2.2.3.2
of
this data base provides not only an efficient and convenient
means of retrieving
is desirable
can be designed for
and inconsistency
It is also feasible to design a system for the
optimal allocation of global storages In summary,
declaration
2 in Fig. 13 is an
Structural analysis
The analysis of program structure is essential to the validation process
115
since :it all~ws the detection of structural flaws and the identification tical or interesting information
flow paths in the program.
The data base contains necessary
for this analysis in a well-structured
tural analysis are well-formation
Well-fommation
labels, unreachable
~d
path identification,
the program structure
unreliable
to see
It includes the detection of unreferenced
statements and statements with no successors.
teristics do not necessarily undesirable
Included in the struc-
etc.
check is a process of examining
if there is any structural flaw.
form.
check, loop enumeration,
and reaching and reachable vector generation,
of cri-
These charac-
lead to the run-time error, but these are unplanned,
(error-prone)
ones.
Fig. 14 shows examples.
GO TO i0 A = B+C
/
~ 20 40
unreachable
statement
I = I+I D = P(1)*A
unreferenced
label
GO TO 30 ~i0
D = A*E
~
GO TO 20 3O
S
A+D
=
statement with no successor
END
Fig. 14
Examples of structural
flaws
Loop detection is performed by applying the procedure described in Appendix A to the program graph. intrinsic,
An analysis of each loop characterizes
deterministic
or non-deterministic
one.
the loop as
An intrinsic loop is the one
which can be determined not to terminate by the static analysis. to be either deterministic
or non-deterministic
of iterations
can be determined
of iterations
in the case of a deterministic
by the static analysis or not.
Fig. 15 illustrates each type of loop.
A loop is said
according to whether the number Thus the number
loop is apparently data-independent.
READ I,N
DO i0 I=i,i00 I0
DO i0 I=I,N
A (I) = B (I)*C (I)+D (I) i0
Non-deterministic loop
Deterministic loop
Intrinsic loop
Fig. 15
A(1) = B (1)*C (I)+~ (1)
Types of loops
After the loop detection, the reduced program graph (RPG) is generated and kept for the subsequent analysis. A logical path in the program is represented by a path in the program graph. In general, a path may contain loops in it and two paths containing the same loop are considered as two different ones when the number of iterations of the loop is not the same for both paths.
The number of paths in a large program is nor-
mally prohibitive, especially where the program contains a few loops.
Therefore,
a definition of an interesting path is adopted for the purpose of practical validation such that the number of paths becomes much reduced while no useful information for validation is lost by the use of interesting paths.
There exist
several approaches to the definition of an interesting path [Mil 74, Ito 73].
A
typical definition [Ram 74b] which is also adopted in the rest of the discussion is either a path in an RPG or an interesting path in each MSC subgraph. in an RPG is a series of arcs from entry to exit. graph is defined as follows.
A path
An interesting path in an MSC
A node in a graph is said to be essential if it is
reachable from an entry node and an exit node is reachable from it. feedback arcs from an MSC graph produces the following two subgraphs.
Removal of One con-
sists of all essential nodes and all arcs between them, while the other consists of the remaining nodes, arcs and removed arcs.
The former is called a forward
subgraph and the latter is called a backward subgraph. transformed into RPGts, respectively.
Both subgraphs are then
Now an interesting path in an MSC graph is
defined as a path in the RPG of either the forward subgraph or the removed subgraph.
Fig. 16 illustrates interesting paths in an MSC graph. ".{eedback path , 2
/ ~
~
~ interesting paths for the ~': MSC graph:
/~"~/' • ~ ~ / / interesting ~ / .' paths for this ~/~h~.'" MSC subgraph: ~kl2-'' path I: (5,2) path 2: (2,3,5) path 3: (2,4,5) Fig. 16
path path path
i: (7,1) 2: (1,2',7) 3: (1,6,7)
Interesting paths in an MSC graph
117
Hereafter~
an interesting path and a path are intermixed
of a path is of iterative nature. of abstraction. (2,3,4,5)
in use.
This definition
Paths are defined in accordance with the level
For instance, paths inside the strongly connected
in Fig. 16 are irrelevant
subgraph
to the definition of paths for the global
MSC graph. All paths in an RPG can be easily identified MSC subgraph,
a procedure
[Har 65].
In the case of an
is applied to remove a few backward arcs and then both
forward and backward suhgraphs are identified.
Thereafter,
both subgraphs are
reduced and interesting paths are identified by the procedure used for an RPG. An additional
feature,
the path identification.
the detection of non-physical
paths, is included in
A logical path is said to be non-physical
to the program can lead to the execution of the path.
if no inputs
An example of a non-physi-
cal path is shown in Fig. 17.
non-physical paths: (1,3,5,6,8) (1,4,5,6,8)
Fig. 17 Although
Examples of non-physical
the complete detection of non-physical
paths
paths is infeasible and it may
involve an exhaustive process of logical inference,
a substantial
amount of non-
physical paths can be detected by the static analysis and the detection is an important
support to the dynamic analysis.
The structural analysis also includes the generation able vectors for a specified set of statements.
of reaching and reach-
The reachin$ vector of a parti-
cular statement provides a list of those statements whose execution may lead to the execution of the statement in question.
On the other hand, the reachable
vector is a list of those statements which may be reached after the execution of the statement
in question.
This information
can be easily extracted by manipula-
tion of the program graph (i.e., connectivity matrix or successor in Appendix A and by the consideration 2.2.3.3
Detection
of vulnerable
of non-physical
table) as shown
paths.
constructs
Since we assume that the program is at least free from syntactical errors, our concern in static analysis is in the detection of semantic errors or anomalies.
This ~malysis will provide not only the running configuration
of a program
118
to be used in dynamic analysis but also the guidelines testing processes. of this analysis.
Included in this analysis are the detection of redundant
ments, uninitialized constructs,
for more cost-effective
The data base forms the basis for the efficient performance
statements,
interfacing anomalies,
undependable
state-
language
etc.
A typical example of a redundant
statement considered here is an assignment
statement whose left-hand side variable never appears in predicates right-hand sides of later statements. the ones whose right-hand
Analogously,
uninitialized
side variable never appear
sarily lead to run-time errors.
areas,
sub-
These code-segments
though those constructs do not neces-
A misspelling
leads to these types of constructs.
statements are
in input statements,
routine calls or in the left-hand s i d e of earlier statements. in a program are highly error-prone
or in the
or mistake in keypunching
The detection of these constructs
performed on the basis of the data base.
often
can be
Fig. 18 shows examples of these
constructs. N = i00 N = M+I
EiLRORK
-
=
ERROR**2
uninitialized statement because of a mistake in keypunching
-
-
-
redundant statement
SUM = SQRT(ERROR)
Fig. 18
Examples of redundant and uninitialized
statements
Interfacing anomalies refer to various semantic anomalies occurring from the integration
of independently
developed modules.
The module interface
the common table are effective supports to the analysis of these. information
in module interface,
matter to detect mismatches formal parameters
table and
Using this
symbol and symbol use tables, it is a simple
in types and numbers between actual parameters
as well as recursive calling.
and
On the other hand, the common
table provides a convenient basis for the detection of anomalies in global storage allocation such as misequivalencing, mension declarations,
inconsistency
and allocation of unnecessary
Use of certain features available
A computed GO TO statement
storage.
though it may increase the execution
in FORTRAN is an example.
statement depends on the value of a variable for determination tions.
This type of
of transfer loca-
It often happens that the value of this variable exceeds the limit and
possibly catastrophic statements quently,
type or di-
in the language often result in the de-
graded reliability of the produced program, efficiency.
of variable
transfers occur.
It has been pointed out that even GO TO
are generally harmful to the program reliability
it is desirable
[Dij 68a].
Conse-
to include in the AEVS a feature detecting these
ii9
vulnerable constructs and pinpointing those areas for the thorough dynamic analysis, 2.2,4
Dynamic Analysis The dynamic analysis in automated evaluation and partial validation is a com-
plementary process to static analysis.
It is intended to verify various behavioral
characteristics which remain unchecked by static analysis.
It is basically a pro-
cess of software testing consisting of driving the program with the devised test inputs and evaluating the outputs. assisted by the static analysis.
As mentioned earlier, this process is greatly The static analysis provides information which
can be used as guidelines for cost-effective testing.
Dynamic analysis performs
both validation functions, that is, error diagnosis and performance verification. Although both static and dynamic analyses participate in error diagnosis, performance verification is mainly achieved by dynamic analysis.
A typical implemen-
tation of these validation functions takes the forms of program profile generation and diagnostic and performance testing.
These are discussed in sequel in the
following sections. 2.2.4.1
Program profile generation
The term2rosram profile is used to mean a table of frequency counts which record how often each statement is performed in a typical run [Knu 7Cb]. In a more general sense, it refers to a collection of statistics on program behavior shown in typical runs.
Information contained in the profile is typically execution fre-
quency of each statement, execution time of each statement, frequency of successes on the logical test for each conditional branch statement, maximum and minimum values of instances of certain variables, frequencies of references to certain variables, etc.
Fig. 19 shows an example of a program profile. Statements
Executions
DO 25 1--23,24 IF (CHAR(1),EQ.SPACE) GO TO 18 DO 15 J=l,ll IF (CHAR(1),NE.SPCHAR(J)) GO TO 15 GO TO (100, 90, 70),J
Time
200
400
1354
4170
1246
2492
12344
61488
232
464
15
CONTINUE
12112
12112
25
CONTINUE
1154
1154
Fig. 19
Successes
108
12112
Example of program profile
This program profile serves as an useful basis in various phases of software design.
We discuss techniques of obtaining program profiles first and then jus-
tify the usefulness of the profile on validation processes. The typical approach to the generation of a table of frequency counts is
120
based on the use of software counters automatically appropriate
locations inside a program.
inserted by the system at
This frequency counter is an element of
a more general class of software termed monitor or self-metric the monitor or self-metric
software.
software refers to the program-segment
That is,
inserted inside
the target program and used as tools for obtaining execution characteristics the program. sections.
Other monitors will be introduced as it becomes necessary
The physical implementation
either a counter-incrementing increments
the appropriate
of
in later
of a frequency counter takes the form of
statement or a call to the subroutine which in turn
counter.
This is illustrated
in Fig. 20.
SUB COUNT(l)
ICOUNT (i0) = ICOUNT (i0)+i
CALL COUNT (I0)
ICOUNT (I) = ICOUNT (I)+l
RETURN END incrementing
statement
subroutine
Fig. 20
call
Example of a frequency counter
A consideration must be given to the artifacts accompanied with frequency counters.
That is, the effects on the program execution due to insertion of
counters must be considered. critical,
If memory constraints
or timing constraints
the addition of a counter may cause unacceptable
of the measurement
perturbations
overhead or the increased storage requirement.
are because
In the case
where a program is running on a computer system with a paged memory,
the insertion
of counters may lead to the different paging traffic. With regard to this, it is desirable to insert a minimum number of counters sufficient
for profile generation.
A technique i s ~ a i l a b l e
to determine
a minimum
number of counters and suitable locations for the insertion of them [Che 74]. is based on the manipulation The measurement
It
of a program graph.
of total execution time of each statement is based on the use
of both execution frequency and estimated time for one execution of the statement. A reasonable estimation can be made by the syntactic analysis of each statement with respect to the number and types of operators,
etc.
Then, the total execution
time is the product of this estimated time and execution frequency. simple matter to extract frequencies
It is also a
of successes on branches from the information
provided by frequency counters. Now that the generation of a profile is discussed, we consider the usefulness of program profile in regard to software validation. First, program profile aids in diagnostic for an effective testing.
In general,
testing.
It provides guidelines
the most active or frequently executed
121
portions of a program are thoroughly tested while the less active portions receive inadequate
testing.
Program-segments
with zero or low frequency counts
could be given more attention in testing and singled out for early and intensive testing. Second, profile often provides useful information for error detection.
The
statistics on branches and calls leave a record of what happened and often it is sufficient
to indicate errors.
The number of iterations
of each loop is often
useful for checking convergence of an employed algorithm. Third~ profile plays a significant examination segment,
of a profile,
especially
is often sufficient
Furthermore,
role in performance verification.
The
statistics on execution time of each code-
to check if the performance meets the requirement.
it simplifies the improvement
in the performance
of a program.
Since
it is generally true that most of execution time of a program is spent in a relatively small portion of program code, portions with the high frequency counts can be designated
as candidates for program optimization.
Ingalls reports in [ING 71]
that in a typical program only 3% of the statements make up 50% of the program's execution
time.
unsatisfactory effective
When either testing or examination performance
of a profile reveals the
of the produced program, profiles can guide cost-
strategies of program optimization.
Besides these, usefulness phases of a ]program's
life.
of program profile can be recognized
Indication of good algorithms
analysis of ]program performance
in other
and sensitivity
to the change in the system environment
could be
supported by the use of program profile. 2.2.4.2
Diagnostic
testing
As mentioned earlier,
testing is regarded as a systematic process of error
detection by means of exercising
the program with test inputs and evaluating
the
outputs, while debugging is regarded as a process of error location and correction.
However,
testing can often assist error location as will be shown later.
The complete testing refers to a testing with all possible inputs.
It is a pro-
cess too exhaustive to be practical in the case of a large program.
Naturally,
a more practical
testing which establishes
a sufficient degree of confidence in
the reliability of a program becomes desirable. the behavioral
characteristics
class to a practically
The common philosophy
into a number of classes and then to verify each
sufficient
extent.
Structural
by the static analysis provides useful information behavioral
characteristics
approach is to decompose
characteristics
the behavioral
such that each class corresponds
recognized
for the decomposition
which in turn supports testing strategies. characteristics
of the
This
into a number of classes
to one or a set of logical paths.
are the interesting paths identified by the structural analysis 2.2.3.2.
is to view
Paths here
in section
In any case, testing of each path in a program is a fundamental
and
122
primitive operation.
In order to manipulate paths, each path must be identified
and then isolated whenever desired. Isolation of each path can be performed in several ways. one among them is to install and operate a new type of monitor.
The most convenient The concept of
the blocking gate (BG) approach to the hardware diagnosis [RAM 71d] can be easily transported to the software diagnosis.
A blocking gate (BG) is a device in-
stalled on the connection between two system elements, which blocks or unblocks the transfer of information under the control of a test driver.
In the case of
software, it is another kind of software monitor which blocks or unblocks the transfer of control between program segments.
Blocking could mean an execution
of STOP statement or a transfer to the test driving system. By the same reasoning applied to frequency counters, it becomes clear that the minimum number of BG's capable of isolating every path is
desirable.
A
technique is available to find such a set of BG's and suitable locations for installation [Ram 745].
It turned out that the same locations can be used for
installation of various other types of monitors useful to validation processes. These are introduced in later sections.
The physical function of a BG depends
upon the testing strategy and thus is discussed together with each strategy. 2.2.4.2.1
Test input generation
When testing is performed with randomly generated inputs, it is called the random-input testin$.
On the other hand, when test inputs to exercise a certain
path or set of paths are devised either manually or by the system using the information provide4 in the course of design, the testing is called the synth esized-inpu~ testing.
In the former case, input variables together with asso-
ciated types are available from the data base and each input variable is assigned a random value of the specified type.
It is often necessary to use some
information provided by the designer even in this case.
It is unpredictable
which path will be exercised and thus the physical implementation of a BG takes the form of a code which transfers the control to the test driver when the path is blocked.
This is illustrated in Fig. 21.
I
' I
Test input generator
i I l
~rogram
I. . . .
'
'
'
|
I
IF BG(3) = 'unbiock' THEN GO TO NEXT I INFORMATION = 'CONTROL CAME TO BG #3' ,~ GO TO test driver / NEXT: Fig. 21
A BG in the random input testing
123
In the latter case, it is known a priori which path or one of a set of paths will be exercised. safety device,
The physical implementation
That is, it detects unexpected
of a BG in this case becomes a situations where the control gets
out of the range of paths for which the inputs have been synthesized.
This may
occur due to either the incorrect synthesis of test inputs or the errors in a program.
Therefore~
design errors.
a BG plays a role of the detector of both program and test
Now we proceed to discuss several testing strategies based on the
operation of BG's or other types of monitors. 2.2.4.2.2
Path-by-Path
testing
The strategy of this testing is to test every interesting path at least once.
That is~ a set of test paths is a set of interesting paths defined in
section 2.2.3.2. exist.
Besides this~ several approaches
to the selection of test paths
This is mainly due to loops, especially non-deterministic
loops.
One
example is to define all test paths as a set of all paths in the program graph under the constraint iterations
that no path may contain more than a certain number
of a loop [Ito 73].
be determined with the consideration
of the size of a program,
in the degree of assurance and the amount of testing costs. tested,
it is desirable
to sensitize
systematic and cost-effective. active path ~ i l e
k
of
The suitable definition of all test paths should the requirement
When each path is
it since the overall testing becomes more
That is~ it is desirable to make it the only
all other paths are blocked.
The simplest way of sensitizing
a path is to block all BG's except the ones installed on the path to be sensitized.
In addition,
the BG's on the sensitized path may be transformed
other useful types of monitors variables~
etc.
Either random inputs or synthesized
case of the random-input lend to automation. ware monitors
such as out-of-bounds
testing,
Although,
inputs may be used.
In the
the evaluation of test outputs does not easily
run-time checks facilitated
in the system or soft-
installed on the path can detect various erroneous conditions~
manual inspection
is inevitable
includes corresponding
the
in general.
On the other hand, the generation of synthesized
outputs.
into
detector for interesting
test inputs normally
outputs or criteria for determining
In this case, the validation
the correctness
of
of outputs becomes more amenable to auto-
mation and the speed of the whole testing process can be increased.
The current
trend in software design is to take the synthesis of test inputs and outputs as an integral
step of the design process.
test inputs are hardly expected.
ing a certain test path are missing. cases becomes generally
infeasible
However,
the completeness
It is quite probable Moreover,
of synthesized
that test inputs exercis-
the synthesis of complete test
in the Case of a large program,
though it sim-
plifies the testing to a large extent.
Therefore,
dom-input
testing would be the most practical
strategy.
testing and synthesized-input
the combination of both ran-
~24
There is one more obstacle commonly encountered in most testing strategies. It is a non-physical path.
Although the detection of non-physical paths can be
performed to a certain extent by the static analysis~ the complete detection is not feasible in general.
In fact, this is one of the factors obscuring the syn-
thesis of complete test cases.
The practical approach to the solution is to
iterate random-input testing to exercise the interesting path and regard it as the non-physlcal one when the path is not exercised within a certain limit of time or iterations.
The accurate decision whether it is a non-physical path is
again subject to the manual inspection. 2.2.4.2.3
Test point insertion
In testing a subgraph, two approaches are possible.
One way is to sensitize
the path in the global program graph leading to the subgraph and then to sensitize each path inside the subgraph. to the global program graph.
Test input always enters through the entry
The other way is to install test points right be-
fore the entry to the subgraph and after the exit from the subgraph and then to enter test inputs through the first test point and evaluate outputs at the second test point.
Although this method requires an analysis for obtaining input
variables and output variables to be used in each test point, it could speed up and simplify the testing process. In addition~ the test point together with the segmentation can be applied to further simplify the testSng process in a large program [Ram 71a].
This is
illustrated in Fig. 22.
~ ~
Total 4 × 4 = 16 paths
Fig. 22
Testt~ Poin
~
4 paths
I__
+
-]--
4 paths
~--
Total 8 paths
Example of test point
That is, the number of test paths can be reduced by installing test points on the locations determined by the segmentation algorithm.
The validation of the
first segment will provide the legitimate values of the state vector which will be in turn used as test inputs for the validation of the second segment. 2.2.4.2.4
Other simple testing strategies
There could be almost an infinite number of testing strategies in addition to the strategies discussed in the preceding section.
In this section, some
strategies simpler than the ones already discussed are briefly introduced.
The
125 comlon philosophy
in those strategies
paths as test paths.
The consequence
is to take a suitable subset of interesting is that the testing becomes less expensive
though the assurance provided is also reduced.
A typical one is to test only a
minimum set of paths covering all arcs in the program graph. is
called a c:overing set of paths.
Such a set of paths
Another is to test only a minimum set of
paths covering; all nodes in the program graph.
When the software
is supposed to
have few bugs, these strategies become more cost-effective. 2.2.4.2.5
Error location
Upon the detection of errors on a certain test path, a process of error location and correction must be followed. resides as a host.
regard to error location.
paths has a high probability
that the cross-
of containing bugs.
the diagnosing aid system can be built in such a way that as soon as
a malfunctioning
path is detected,
tified and scheduled for testing. testing.
of testing in
The idea is based on the principle
section of two malfunctioning Therefore,
This is the area where debugging
In this section we discuss the usefulness
all paths crossing the detected one are idenThis mode of testing is called the cross-
The extent of debugging will be significantly
The software monitors
reduced in this way.
embedded on the detected path can provide additional
infor-
mation useful to error location. 2.2.4.2~6
Path frequency counting
There is still another mode of testing. In this approach, randomly generated
a program is continuously inputs.
of the whole test run.
additional
tes1=s.
frequencies
Test outputs are evaluated
collectively
During the test run of a program,
of each path is counted. garded as sufficiently
It is called stochastic
testing.
tested with a sufficient number of
Paths with high frequencies
at the end
frequency of traversal
of traversals may be re-
tested, while paths with low frequencies may be taken for
In order to test paths with low frequencies,
ones with high
are blocked by BG's so that the testing efficiency may be increased.
In addition, tain extent,
the detection of non-physical
Path-frequency
tool for path-frequency path-frequency
paths can be achieved
to a cer-
counts can be contained in a program profile.
counter installed on the same location as a BG.
In other words,
counters installed on same locations where BG's are resident are sufficient count all path--frequencies. 2.2.4.2.7
to
The detail is referred to in [Ram 74b].
Performance verification
Program profile discussed assistance
The
counting is another type of software monitor called a
in section 2.2.4.1 provides a certain degree of
in performance verification.
Based on it, the total execution time
of a program c~m be measured and compared to the performance ever, from the general nature of a profile,
requirement.
How-
it shows only general tendency but
126
doesnVt provide sufficient confidence in performance for various inputs.
More
thorough performance verification becomes desirable and it can be achieved to a certain extent by the testing with the sufficient number of test inputs.
When-
ever the testing is performed for error diagnosis, an additional check can be made if the execution time on the path has been within a certain bound.
Once the
path whose execution time exceeds the limit is detected, the execution-time profile can pinpoint the major candidate for optimization for that path.
In addi-
tion, this combination of diagnostic and performance testing identifies a set of critical paths.
Thereforep both error diagnosis and performance verification are
performed interchangeably and implemented in a AEVS, an integration of diagnosing aid and evaluation aid systems. 2.2.5
Operational practices of AEVS's In this section, the current status of AEVS's and the practical experiences
in using those systems are briefly reviewed.
There have been a number of reports
on successes resulting from the utilization of AEVS's in the development and maintenance of various software systems. The ACES [Ram 73a, Mee 73] contains features such as data base generation, thorough structural analysis, unreliable constructs detection, profile generation and critical variables monitoring.
This system has been successfully used by the
SAFEGUARD Systems Evaluation Agency as a gross survey of substantial amounts of program code.
For example one partial process -- a small portion of the complete
software system -- which was analyzed by the ACES~ consists of 90 routines and subroutines containing approximately 23,000executable statements.
Results showed
unreliable practices such as computed GOTO statements with untested jump parameters, DO-loops with untested initial or final values of the loop parameters, and transfers of control into the middle of DO-loops.
These conditions were fur-
ther investigated by the user and either resolved or reported to the developer for modification. In testing and maintenance of the Houston Operations Predictor/Estimator (HOPE) program, cost savings achieved by the use of the PACE [Bro 72a, 72b] was $8000 per year.
The PACE disclosed that the existing test file consisting of 33
test cases covered 85% of the subprograms and that one-half of this number were
exercised by almost every case.
It required 4.5 hours of computer time and 35~50
man-hours of test results evaluation.
Consideration of these statistics initiated
the subsequent analysis to produce a more effective test file. cases was generated.
A file of six
These tested 93% of the subprograms, hut they required less
than 24 man-hours of test results examination.
Similarly, the cost required in
verification and retesting of the Automated Verification System (AVS) was reduced by $i000 per year by the use of automated tools.
These are representative exam-
ples and similar reports are becoming more frequent.
127
The operating cost of the AEVS is worth receiving attention. cost is dependent upon the organization
and capability of the AEVS as well as
the size and nature of the source program. at present.
The precise
Available statistics are very limited
The observation made during experiences
general tendency that the construction
of the ACES showed the
of data base took approximately
one and
an half times as much as the compile time and the size of the data base was two and an half times as large as the size of the object code.
Instrumentation
of
the program generally resulted in 20% expansion in the program size and the execution
time.
A fully automated validation is beyond the capability of current AEVS's.Although it is premature to make a rigorous quantitative examples,
the increasing availability
judgement on the basis of these
of similar reports substantiates
the
prediction of more successes of future AEVS's on software validation. 2.2.6
Sun,mary In this section, we have examined features of currently available AEVS's.
At present,
the partial validation and automated evaluation appears to be the
most effective approach to the validation absolute correctness
of a large program.
cannot be proved by this approach,
Although the
the degree of assurance
obtained by the assistance of the sophisticated AEVS will be acceptable in most practical
situations.
The success and efficiency of this approach depends
largely upon the approach in software design. can simplify the validation processes tivenss in validation.
The well conceived design process
to a great extent and increase the effec-
On the other hand, the design process could become more
efficient on the basis of powerful AEVS.
The largest obstacle on the way to the
fully automated validation has been the synthesis of test inputs. encountered reappears
in the program correctness
in the automated
software design processes
Problems
approach to the validation of a large program
synthesis of test inputs. such that validation,
Future works on structuring
especially
the test input generation
becomes highly amenable to automation will be of great significance. 2.3
Conclusion The analytic approach to improve software reliability has been reviewed.
The
proof of program correctness approach enables us to validate many simple but frequently used algorithms.
Hopefully,
we can build up a library of validated
algorithms which can be used to construct more complicated algorithms. automated
tools for evaluation and partial validation is an increasingly
approach to i~)roving both the productivity of the program.
Although at present,
manual labour are involved,
of the programmer
a considerable
The use of popular
and the reliability
amount of human judgement and
the validation procedure can be much simplified
program is prepared with the goal of reliability
in mind.
if the
L28
3.
The constructive
approach to improve software reliability
We can see that the analytic approach has several disadvantages is written without any consideration developed become infeasible, large.
for its reliability.
if the program
All the techniques
ineffective and inefficient when the program is too
The analytic approach is designed for detecting and correcting errors.
There is no guarantee
that the end product after extensive debugging is free of
error, as Dijkstra pointed out, "Program testing can be used to show the presence of bugs, but never to show their absence."
[Dij 69a]. There are no criteria to
determine when our debugging effort should end. a waste of effort on something
debugging is
(bugs) which should not be there in the first place.
Why should we spend 45% of our effort mistakes
Besides it seems that
(in debugging and testing)
to get rid of the
that we made in the first 55% of our work (in the design and implementation
stages)?
More care and time in design and implementation
are clearly needed since
it will not only reduce our debugging effort but also give us a more reliable program. The constructive
approach to improve software reliability
has the objective of
never finding the first error in the program.
The design and implementation
program are carefully and patiently performed,
always keeping
the reliability
correctness
two approaches
can be taken.
of the program in mind.
collection of programming
Basically
techniques,
c a l l e d " s t r u c t u r e d programming",
of the and A
can be used
to develop more reliable software by better design, management and coding methods. Programming redundancies,
called software defenses,
system to detect and contain error propagation 3.1
can also be introduced
in real-time
to the
systmns.
Structured programming Structured prosrammin$,
a term mentioned
ered as a "major intellectual
invention",
so often these days, h a s b e e n
routine concept and even the stored program concept. really "invented" Dijkstra,
structured programming.
have contributed
philosophies
consid-
one that can be compared to the sub[McC 73].
A few people,
However,
no one
especially Professor E.W.
a great deal to the formulation and consolidation
of "reliable programming",
of the
which then become known collectively as
"techniques for structured programming". The term "structured
programming"
has been associated with many meanings
literature due to the broad spectrum of techniques it encompasses. it has been associated with the syntax rules of a program, against the GO TO statement structures
[Dij 68a] and restrictions
that can be used to code a program.
in the
In some places,
especially as a case
placed on the type of control
[Lis 71, Mil 71].
In other contexts,
it has been used to denote a design method for reliable systems,
the so-called "top-
down approach".
[Mil 71].
"chief programmer Dijkstra designer's)
teams".
It has even been related to the managing
technique called
[Bak 72a].
[Dij 68b] defines structured programming
as "to construct his (the
mechanism in such a way, i.e., so effectively
stage of the testing procedure
the number of relevant
structured,
that at every
test cases will be so small
129
that he can try them all."
It is therefore,
that it can be "exhaustively"
a method of structuring
tested and confidently verified.
defines it as "a method of programming according program's readability programming
and maintainability".
style for clarity.
organization and discipline
Mills
the program so [Bak 72a]
to a set of rules that enhance a
Hence, it can be considered as a
[Mil 71] defines it as "a complex of ideas of
in the programming
then both a design methodology
Baker
process".
Structured
and a technique for coding programs
programming
is
such that the
resulting software product is more reliable than an equivalent program developed using conventional methods. 3.1.1
Structured programming
3.1.1.1
as a coding technique
"GO TO" - free.programming The enghusiasm in structured programming
famous letter from Dijkstra
is often traced back to the
[DiJ 68a], "Go To Statement Considered Harmful",
in
which he suggested that "the GO TO statement should be abolished from all high level programming
languages" because "it is too much an invitation
of one's program".
Dijkstra pointed out that it is the process controlled by the
program that accomplishes
the desired effects for a programmer.
minimize logical errors, one must "shorten the conceptual program and the dynamic process,
to trace the progress
by examining the static program. (process)
between the program
(spread out in time) as trivial as
With the unrestraint use of the GO TO statement,
extremely difficult
it will become
of the dynamic process evolving in time
Consider
trying to understand
in the middle of a large program.
then it is necessary
the effect of the code at the destination of the GO TO before the
algorithm can be understood. environment.
a small algorithm
If the algorithm has a conditional
GO TO statement which transfers control outside the algorithm, to understand
In order to
gap between the static
to make the correspondence
(spread out in text space) and the process possible".
to make a mess
This requires examining the effect of the external
If this GO TO leads to another and then another,
external environment may eventually
the tracing of the
obscure all our understanding
of the algorithm
since the control or decision statements are separated in space on the page from the computations ward directions and difficult
evoked from them.
These jumps,
sometimes
in the program, make it difficult
to follow the logic of the program
to visualize at any given point of the program what the present
conditions are (such as the sequence of operations variables,
in both forward and back-
etc.)
executed,
the state of the
The program text does not correspond in space on the page listing
to the execution of the program in time.
Furthermore,
as a program is debugged and
changes are made to correct errors or to meet new specifications, the program grows rapidly.
the complexity of
Any change in an algorithm with GO TO's can have "side
effects" in control on the environment may jump out of its local environment
in which it is used because this algorithm and affect other parts of the program.
bugs are created due to these unanticipated
side effects of the changes.
New
If, on
130
the other hand, an algorithm has no GO TO statements,
then the effect of the dynamic
process created by the algorithm can be understood very easily as the cumulative effect of all its statements without worrying about the external environment of the algorithm
(except for the state of the input variables).
process is "localized" the "local" process.
in the static code. As a result,
After all the discussions
computations
on the evils of the GO TO statement,
to write programs without
execution
them, and whether
one may still the replacement
We would like to replace the GO TO statement
that will force the decisional
evoked by them.
to the density
[Dij 68a].
will create the same kind of problems. with statements
that Dijkstra remarked
seems to be inversely proportional
of GO TO statements in their programs.
wonder if it is possible
It is also very easy to modify, debug
It is therefore not surprising
that the quality of programmers
the dynamic
the user has more confidence in the program since
it is readily readable and understandable. and maintain the program.
Therefore
Any change in the code will only affect
statements
Then the computational
to be associated with the
process evoked by the program
(in time) will correspond more closely to the program text and becomes
more easily understood.
Bohm and Jacopini
[Boh 66] have laid down the theoretical
basis for structured programming by showing that it is possible to write any program using only three control structures.
A program in this language will be a compound
statement formed by simple assignment statements
and predicates
according
to the
following rules: i.
If Sl and $2 are statements, statement.
then the concatenation
of S1 and $2 is a
(SEQUENCE).
2.
If S1 and $2 are statements and P is a predicate,
3.
If S is a statement and P a predicate,
statement IF P THEN S1 ELSE $2 is a statement.
WHILE P DO S
is a statement.
then the conditional (IF THEN ELSE).
then the iterative statement
(DO WHILE).
A program written in this language will have a flowchart made up only of the singleentry single-exit
structures as shown in Figure 23.
be replaced by one of the three structures.
Each block in the figure may
Therefore
the control structures can
be nested. Programs written in this block structured programming simple control structure. a direct correspondence during its execution. control structures, program.
There are no GO TO statements
language has a very
and no labels.
There is
between the static form of the program and the dynamic flow Using only concatenation,
alternation and iteration as the
the process is "localized" with the flow of control in the
The computations
evoked by a decisional
statement can be closely followed.
A predicate is defined as an logical expression which when evaluated will yield a value which is either TRUE or FALSE.
131
..
4
J
I
I
SEQUENCE
IF THEN ELSE
DO WHILE Figure 23
Control structures for structured programming
There is no back~tracking. unidireetionally.
Without GO T0's, transfer of control always proceeds
A structured program can be broken down into meaningful
which have only one entry and one exit.
Execution always proceeds from the single
entry point to the single exit point of a subprogram of control makes it no longer necessary
segments
(block).
This simplification
to flowchart a subprogram.
In fact, as a
general rule of thumb, a structured program which cannot be understood without flowcharting is too complicated
and should be broken down into modules.
The straight-
forward control transfer in structured programming
is also very helpful for proving
program correctness.
of a program which does not
The proof of the correctness
contain GO TO's becomes much simpler since the termination of the program depends only upon iteration statements
(not upon a possibly infinite transfer of control).
If a block of code contains a GO TO statement, we have to examine, understand,
and
prove the termination of the block of code to which the GO TO statement transfers control.
A chain of GO TO statements will make the understanding
termination very difficult. executed sequentially
If, however, we restrict
and proof of
the program blocks to be
or at most in an iterative fashion, we can explicitly
the conditions under which a block of code terminates.
state
Without GO TO statements,
the proof of a program breaks down naturally into the proof of separate program components.
Also the proving process is much simplified because the program is
clearer and easier to understand. statements corresponds
Each method of combining
to a rule of inference.
the simple assignment
Concatenation
is understood by
enumeration,
conditional
statements by case study and iterative statements by
mathematical
induction.
Programmers
[Lis 71]. correctness
Therefore,
are familiar with these rules of inference.
it becomes feasible
of a large program.
to prove, at least informally,
the
Dijkstra by using structured programming has
developed and informally proved an entire operating system.
[Dij 685].
132
3.1.1.2
Objections to structured programming There are, however, some programmers who question the merits of such
restrictions imposed by structured programming.
Objections to structured programming
usually come from one of two sources: basic programmer conservatism and concern about efficiency of the programs produced.
The conservative reaction comes about because
structured programming is a new technique which may be more difficult to learn and to use than conventional programming.
It will also require a change of programming
habits, which may affect the software productivity of the programmer. actual degree of difficulty may be overestimated.
However, the
At the University of California
at Santa Clara, only structured programming is taught.
Their experiences indicate
no unusual problems in teaching and learning structured instead of unstructured programming.
Experience reported by Baker [Bak 72a] on the development of the New
York Times Information Bank showed that software productivity of a programmer is increased slightly rather than decreased by using structured programming.
Besides,
there is always the advantage of a r e d u c t i o n i n debugging time. There is also the concern about the efficiency of the program in terms of execution time and memory storage required.
Knuth and Floyd have discussed
techniques to avoid GO TO statements in a program by using recursive procedure method and by duplication of code. [Knu 70aI increase in memory storage and execution time.
Both of these methods will cause an Ashcroft and Manna have shown that
every flowchart program can be w r l t t e n w i t h o u t GO TO statements by using WHILE statements.
[Ash 71].
Given a set of inputs, the WHILE program will produce the
same set of results as the original program but need not perform the same computation sequence although the topology of the original program is presented.
However, new
variables are introduced to preserve the values of certain variables at particular points in the program or alternatively special boolean variables are introduced to keep information about the course of the computation.
In general, it is always
necessary to add extra variables in order to translate a flowchart program into an equivalent WHILE program.
Therefore, it may mean an increase in memory storage.
However, Ashcroft and Manna have reported the same order of execution time efficiency for the structured WHILE program.
It is still unclear if there will be
any inefficiency when the program is flowcharted with structured programming in mind.
Dijkstra feels that structured programs are just as likely to lead to
effielent code as any other type of program.
He also feels that an increase in
efficiency always comes from an exploitation of program structure.
[Dij 65].
Furthermore, structured programs will be written in high level languages and a powerful optimizing compiler can be used to produce efficient code. 3.1.1.3
Other considerations for a structured programming language Structured programming is a technique that reduces a program's complexity,
increases its clarity, and results in easy understanding and maintenance.
A reliable
program should have very simple structure and that its structure should be clearly
133
visible by an examination of the code.
To achieve these goals with the mere
elimination of the GO TO statement appears to be a simplistic approach.
Reducing
a progrmn's complexity can be thought of as a process of removing obstacles from the program:
complicated
control paths, obscure structures,
unnecessary jumps, redundant and obsolete code, ambiguous Restricting
the programmer's
and WHILE m a y a l s o
use of control structures
lead to unnecessary
inconvenience
restricted use of 'GO TO' have been proposed, [Wul 71] and the COME FROM by Clark [Cla 73]. statement
[Don 73]° to~e
that the single-exit
sometimes.
IF THEN ELSE,
Different forms of
It has been suggested that the CASE control structures.
law be relaxed for abnormal
program: meaningful names, informative
clean interface,
termination.
It is c l e ~
that structured programming
can be achieved with a combination
The drawbacks of existing programming
[Ker 73].
rather than cryptic.
to error.
should not contain
even by the programmer himself after some
The language should have a rich and descriptive
For example,
syntax, making
even by people who are not familiar with the
in APL, ÷
means "IF x > y, GO TO 6".
6 x i(x > y) However, ÷
a statement
6 x (x > y)
means "IF x > y, GO TO 6, ELSE RETURN".
The hidden "RETURN" is often overlooked.
of treatment of the same syntax construct in different
is another drawback of many languages.
statement,
[Els 71], and Kernighan and
It should encourage concise expression
to understand,
it very easy to read and understand,
constraints
on the integer expression, an I/0 statement,
For example,
in Fortran,
environment
there are different
according to whether they appear in a DO
a subscript,
a computed GO TO, a declaration,
A programmer would much prefer only one integer expression usable anywhere. other irregularities However,
of
A language like APL is an open invitation for clever tricks
which are very difficult time has elapsed.
by Elspas et al.
A good language for structured programming
features that are conducive
Irregularities
good documentation,
style and language design.
languages have ]been investigated
language.
cormments, clear code layout and
more levels of modularization,
etc.
good programming
time.
[Mil 71].
Improving program clarity can he thought of as a process of adding things
indentation for readability,
Plauger.
to SEQUENCE,
comments,
etc.
such as the EXIT statement in BLISS
(as used in ALGOL) be added to the allowable
It is also suggested
uninformative
constructs,
are provided in order to save the programmer
etc. Some
some keypunch
saving a few characters can sometimes create a lot of confusion.
Algol 68 allows the statement label; as a legal branch to be interpreted
as "GO TO label".
These irregularities
should
134
be removed.
The language specification becomes bigger, and thus enlarges the
compiler size.
The cryptic expression makes error checking very difficult.
Also
these special cases may be treated differently in different installations, thus affecting the transportability of the program. encourage uniformity and generalization. aspect.
Therefore a good language should
Algol 68 has some good features in this
Statements and expressions are treated as the same thing in Algol.
CASE statement encourages a uniform organization of the progra=,ner. and commenting can affect the readability of the program drastically. should allow free-format input and proper indentation.
The
Program layout A language
The compiler should also
improve the readability of the program by providing optional informative outputs of the program layout besides the standard listing.
This may be a listing of the
program with information about its topology, such as the loops and the branches. Comments are crucial to the understanding of a program. uninformative comments are written by the programmer.
However, too often It may not be a bad idea at
all to design a "structured" language for commenting a program.
Con~nents written
in the form of assertions used in proving program correctness may be useful in understanding the program. A good language for structured programming should also encourage a programmer to write reliable programs, even at the expense of additional constraints on his style.
This affects the syntax of the language, its semantics, and even the prag-
matlcs of implementation. action.
The language syntax should be descriptive of the desired
Language redundancy can also provide error protection.
The requirement
of the programmer to declare all program variables and the way they are used in Algol 68 helps to reduce errors due to misspelling of identifiers.
During program
execution, array-bound checking should be provided by using special hardware (as is done in the BbO00) or by run-time system software to verify that subscript values do indeed fall in the declared range.
Descriptive and meaningful names should be
used and clarity of expression should be emphasized.
The compiler should also
perform some semantic checking on the program to reveal semantic errors, which may be very helpful for debugging. Therefore we can see that a good language for structured programming should support the three types of well-structured control structures: SEQI~NCE, IF THEN ELSE, and DO WHILE.
Unrestricted use of the GO TO statement should not be allowed.
It should encourage concise and clear expressions, clear code layout and indentation for readability, and informative comments.
It should have a rich and descriptive
syntax, uniformity in language constructs, and clear precise semantics. contain error reducing properties, such as language redundancy.
of the language should try to improve the reliability of the program. programming languages have all these properties. three basic control structures.
It should
The implementation No existing
PL/I and Algol can support the
Therefore they can easily be used for writing
structured programs by eliminating the features that are conducive to error.
Other
135 modifications of their syntax and semantics for more reliable programming are also very desirable.
Kelley [Kel 73] has developed an experimental programming language
called APLGOL ~hich adds structured programming facilities to the existing framework of APL.
The conventional semantics of APL is unaltered and only minor changes are
incorporated in the syntax. A good program design can also help to produce reliable software.
Many program
errors can be avoided hywriting the code first in some "virtual language" and then expand and translate into the desired high level language.
This two-step coding
procedure will increase the reliability and intelligibility of the resulting program, besides helping the programmer to write informative comments and useful documentation. The "virtual l~guage" need not be formal hut should be precise and descriptive of the action to be performed.
For a large programming system it may be advantageous
for the program~lers to agree on such a "virtual language" so that uniform documentation can be provided, making the programs easier to understand by all programmers. In a way, this can be considered as similar to the top-down approach of design of structured programs to be discussed in the next section. 3.1.2
Structw:ed programmingas a design technique We notice that structured progra[mning aims at simplifying the control paths
of the program so that it becomes more readable and understandable.
However, even
when a program is well structured, it may still be very difficult to understand if it contains DO loops with thousands of instructions and IF-THEN-ELSE statements taking up twenty or thirty pages.
The program has to be divided up into smaller
subprograms of more manageable size called program modules, a common practice called modularization. independently.
Modularity allows modules to be written, compiled, and tested Traditionally the process of modularlzation i s performed in a care-
less and arbitrary fashion.
The division of a program into modules is usually done
according to the boxes of the flowchart of the program. programs.
This may work in small
In large programs, there are complicated interactions among the modules.
Modules interact in control (via the entry and exit points), in data (through shared data or arguments passed between them), and in the service which they provide for one another.
An arbitrary modularization may obscure many of these interactions
(interactlon complexity) so that subtle software bugs may be created.
It may also
introduce unnecessary functional complexity by putting~too much functions in a module or by failing to abstract a common function shared by several different modules. From these considerations, we notice that in a good modularization, we should minimize the assumptions that the modules make about each other (to reduce interaction complexity) and we should also limit the s~ze of the modules (to reduce functional complexity).
Parnas [Par 71] has also made other suggestions on the
modularization of the program. which are likely to change.
The modules should be defined around assumptions
In specification of modules, we should specify
136 identities or relations between the externally visible aspects of the module rather than the internal construction. In terms of structured programming~ techniques.
good modularization
The first, levels of abstraction,
complexity of the system by conceiving abstract machines.
The second,
can be achieved by two
[Dij 68b] allows us to resolve the
the system as a hierarchy of levels of
top down desisn,
[Mil 71], enables us to develop
a large program as a tree structure of functional modules. 3.1.2.1
Levels of abstraction Levels of abstraction was first proposed by Dijkstra for the design of the
T.H.E. Multiprogramming tested exhaustively. of abstractmachines, each level,
System so that it can be proved logically correct and
[Dij 68b].
The system is designed as a hierarchy of levels
the lowest levels being those closest to the machine.
the abstract machine allows us to understand
level without requiring For example,
the detailed knowledge of how the operations
At
at that
are carried out.
the virtual memory can be considered as a level of abstraction while
the physical memory is a lower level of abstraction. formulation
the operations
of levels of abstractions.
Two rules are used for the
Each level owns resources
exclusively for
its own use and these resources are not accessible from other levels.
Lower levels
are not aware of the existence of higher levels and therefore may not refer to them in any way.
For example,
the disk and core are resources owned by the physical
memory level while pages and segments are resources in the virtual memory level. The physical memory is not aware of the existence of the virtual memory. Each level of abstraction contains a collection of related functions. Operations level.
in each level are interpreted by the abstract machine on the next lower
Higher levels are supported by lower levels.
obtain service and information from lower levels. accessible the level.
Therefore,
high levels may
Each level may contain externally
functions in addition to internal functions used exclusively Since each level has its own resources,
as a level of abstract resources.
The division of resources
that each level has to be 'complete'.
into levels implies
The operations at one level have to be
supportable by the abstract resources provided by the underlying The hierarchy arrangement modularization
of the system.
to support
each level can be considered
levels.
of levels of abstraction allows us to design good Subtle errors due to shared resources are controlled
by treating the ownership of resources in a rigorous fashion.
The interface problem
is reduced by defining system primitives which must be used for communications between levels. synchronizing
The cooperation of processes are regulated by a set of formal
primitives.
However,
the success of the design of the entire system
depends critically upon the design of the top level.
The design of this level
depends on the experience and judgement of the programmer, standing of the system.
Dijkstra suggests
delayed as long as possible
as well as his under-
that, in general,
(hold onto the abstractions
decisions
should be
as long as possible).
137
Whenever possible, we should gain more understanding a decision.
If a module is too large,
of the system before we make
the principle of "divide and rule" can be
applied to decompose it into smaller modules.
Besides the program should be
designed for adaptability by considering potential generalizations the design.
Specifications
are likely to be changed while the system is being built because of
more understanding
of the system.
Modifications
are always necessary after the
system is put into operation for system optimization convenience.
Therefore,
structured programming
the system for maintenance
and tuning, as well as user
should also be used for implementing
and modifications.
Dijkstra also gave some design rules for the specifications [Dij 65].
at each stage in
This helps us to gain insights into the structure of the system.
His "principle of non-interference"
constructed
to satisfy specifications
so that they are independent of each other
and independent of the context in which they will be used. independent
of the modules.
states that modules should be
so that they can be designed and constructed
The modules are logically
independently.
Independence
implies that all interfaces have been defined and that all conflicts over resources have been resolved.
When the modules are integrated
together,
the correct working
of the system can be established by considering only the exterior specifications (an abstraction) construction. gration~
of the modules without requiring knowledge about the interior
Therefore,
the correctness
starting from the lowest level, at every stage of interof the system can be proved by an exhaustive case analysis.
Dijkstra concluded that a designer should structure his program so that the number of relevant
test cases is so small that they can be exhaustively
Besides the T.H.E. abstraction,
System,
such as the Venus system designed by Liskov
system designed by Madnick and Alsop. 3.1.2.2
[Dij 68b].
[Lis 72a] and the file
[Mad 69].
To~ down design There are basically
or from the top down.
two approaches
to build a system:
In the bottom up approach,
initial design which identifies are implemented
the tasks.
implementation
The most elementary
from the bottom up begins after an (low-level)
functions
first and then used as building blocks to compose more complicated
tasks, and so on.
In this way, debugging of the code is easier and can be performed
in parallel with the design of more complicated
components.
several dangers with this "building block" approach. implemented before the system is well-defined. components
tested.
there are other systems constructed with levels of
in building
the system.
there are
The building blocks are
They may not be the most useful
Modifications
frequently necessary when difficulties
However,
of these building blocks are
are encountered
in the higher levels.
System
integration is difficult because the interfaces between programs are not rigidly defined and modifications Worse than all these,
of building blocks often create subtle side-effects.
the existence of these building blocks may influence
the
138 system design.
Therefore, the design of the system is constrainted by decisions
made before we have an overall understanding of the system. The top down approach uses the opposite philosophy.
[Mil 71].
The highest
level, which represents a rather formal description of the overall system, is specified first.
It describes the flow of control among the major subsystems,
each having a functional specification.
Each of these subsystems is then expanded
into an intermediate system of code and functional subspecifications. is carried on until all functional specifications are coded.
This process
Therefore the system
is organized as a hierarchy of levels of fun ct%on specifiqations.
(Note that the
levels used here are different from levels of abstraction because they are not associated with the ownership of resources.) There are several disadvantages associated with the top down approach.
The
specification of the components are rigidly defined, including the data structures it employs, without much consideration to how the components will be implemented. This may lead to problems of inefficient implementation.
The design may also be
complicated since the system is very complex and it may be difficult to write down all the specifications at each level.
To understand the operation of the system,
one may have to simulate the system as the design proceeds in order to debug his specifications, as suggested by Randell.
[Ran 69].
H. Mills, an advocate of the top down design, showed that most of these problems can be overcome by the introduction of structured programming.
[Mil 71].
Mills
views the functional specifications as similar to mathematical functions which map initial data into final data for some codes yet to be specified.
The whole
organization is based on functipnal prosrammin~, defining composite functions in terms of other functions.
The design structure is carried out directly in code,
which can be at least syntax checked, with "program stubs" representing functional subspecifications.
This process of functional expansion is carried on, with new
functional subspeeifications represented by names of dummy members of a programming library, until the whole system is defined.
Each functional subspecification,
called a segment, may consist of a mixture of control statements, and macro calls (to lower level segments) with possibly a number of initializing, file or assignment statements as well. Mills also put other restrictions on the construction of a segment.
Only
structured programming techniques can be used, implying that the control structure will only consist of sequencing, IF-THEN-ELSE, and DO-WHILE.
The size of the
segment is limited to about 50 lines of code or one page of listing, so that each segment is small enough to be readable and understandable. restricted to have only a single entry and a single exit.
A segment is also Therefore, a segment
behaves as a simple data transformation function independent of the environment in which it is used so that there are no side effects in the program control.
Segments
are stored under symbolic names in a library and are substituted at any point in the
139
program by a macro-like call. specification at the root.
The segments form a tree structure with the system
The system is written from top down and at each level
we can verify that the intermediate system is logically equivalent to its predecessor system.
Therefore, the system can be verified to be correct one level at a time by
functional expansion up to the lowest level, i.e., the code of the program. each segment is small and well-structured, simplified.
Since
the proof of correctness is much
Interfaces between segments are rigidly defined, minimizing the inter-
face problem.
Documentation is automatically provided by the functional specifica-
tions and the verification procedure.
The finished system also contains traces of
the design process, which is very helpful for the maintenence and modification of the program.
It is also possible to execute the system at any intermediate level
by "simulating" modules that are not yet implemented. checked out independent of the system.
The modules are never
Therefore, conflicts over resources are
detected and resolved early in the design process. Mills' approach of system design has been carried out by Baker [Bak 72a] in the design of an information bank system for the New York Times.
It was reported that
programming productivity was substantially improved and the system had no serious errors for the first twenty months. 3.1.3
Structured programming as a management technique Reliable programs cannot be produced efficiently without a good management
policy.
Communication problems among programmers are the chief source of program
errors.
Conventional management approaches often suffer from the lack of functional
separation, communication, discipline and team work.
The hierarchical arrangement
of a structured program provides a natural organization for the assignment of Jobs. The communication problems are minimized by rigid specifications of the components and the interfaces.
All these give us an opportunity to use a more systematic
approach of management.
The Chief Programmer Team approach has been proposed by
Mills [Mil 73] and Baker [Bak 72a] as a way to improve the manageability, quality and productivity of programming.
The nucleus of a chief programmer team consists
of a chief programmer, a backup programmer, and a programming secretary. personnel
Other
can be added at the discretion of the chief programmer. ~ The main
objective is to structure "programming work into specialized jobs, ships among specialists, and stress discipline and teamwork".
define relation-
[Bak 73].
The chief programmer is a technical manager whose principal work is to design and code central, critical segments of the system and make specifications of programs to be assigned to other programmers. integrates programs coded by other programmers.
Besides, he also reviews and then The backup programmer is another
person who is completely familiar with the design and development of the program by working closely with the chief programmer. test
planning for the system.
He reviews decisions and provides
He also formulates programming strategy and
tactics, relieving the chief programmer to concentrate on the central problems of
140
system development.
Therefore he is both an assistant and a back-up man for the
chief programmer. The programming
secretary
is responsible for maintaining
the current status and
previous history of the project in the Development Support Library an internal
(machine readable)
and an external
(human readable)
(DSL) in both
form.
[Bak 73].
The DSL contains all the project programs and data files in the computer and all the project documentation, or not.
listings,
and outputs,
including
A detailed history of the development
test runs, whether successful
of the program is kept.
ming secretary has to collect from the programmers
The program-
the project notebooks containing
changes to be made in the internal programs and data files.
Then he prepares the
input and excutes the project programs on the computer, with the help of keypunch operators.
The machine executes the program while updating the library data in the
internal library file.
The secretary obtains the output and enters them with the
new source listings in the project notebooks of the external library, with the necessary documentation. logged in chronological Therefore releives
The outdated documents, journals.
the programming the programmers
all project records,
He then returns
however,
are not destroyed but
the notebooks
to the programmers.
secretary is also a key personnel in the nucleus.
He
of most of the clerical and secretarial work for maintaining
current status, and test data so that they can work more
effectively and efficiently. The DSL represents
a concept of moving the programming
private art to public practice.
assets and the visibility of the DSL simplifies programmers. maintenance [Wei 71].
the communication problem among the
The record of the history of project development of the program.
facilitates
The concept of "egoless programming"
The chief programmer has to read, understand,
data developed by other programmers
on the team.
on programs written by the chief programmer faces.
production process from
All computer runs and program data become public
the
is also adopted.
and verify all program
They, in turn, have to do the same
to define the specifications
This ensures that at least two programmers
fully understand
and inter-
every line of
the developing program. About i00,000 lines of source code seems to be the maximum size properly assigned
to a single team.
of chief programmer
teams.
In really large programs, we have to define a hierarchy A team of skilled programmers may start out the system
with the overall system design.
After the design is completed,
each member in this
team may become the chief programmer of the other teams responsible for the next level of design and implementation,
and so on.
The evolution of assignment in a top-
down fashion will retain the spirit as well as the discipline of the Chief Programmer Team. 3.2
Software defenses Although structured programming
can help us to construct reasonably reliable
software we are still not certain that no critical error will ever occur.
In some
141
real-time
systems,
technique,
even this low error rate cannot be tolerated.
called software defense,
propagation
[Cha 73]
can be used to trap and contain the
of software errors in a real-time system.
precautionary
A protection
This technique is a
procedure to make sure that there will not be a catastrophic
even when a software error occurs. that it is very difficult
These techniques are highly goal-oriented
to generalize
them.
[Cha 73].
There are two types of software defense techniques: The former includes
so
They have been proved to he very
useful in the ESS of the Bell Telephone Company
methods and audits.
disaster
defensive programming
techniques used in the design of the
program and data to detect software errors before they cause system misbehavior. The latter are used to detect, contain, they have occurred. program,
and possibly correct software errors after
Since audits are used primarily to protect the integrity of the
they will be discussed
in the next section.
Defensive programming may include a variety of methods. precaution procedures
to be implemented
of a software error.
They are dependent
of the programmer.
They are special
in the program to reduce the possibility on the purpose of the program and the style
A commonly used technique is the range check.
be performed on the values of data, memory locations accessible areas where a program control can be transferred the system indicators
to.
Range checks can
to a program,
and
A state check to verify that
and the actual states of the resources are in agreement before
a resource is allocated can reduce many system errors and mutilation of potentially valuable data. misbehavior
Reasonableness
checks on the input data can eliminate many system
due to abnormal input data.
A reverse check is also an effective
to ensure the correct operation of the system. procedure
is employed
to search a file, we should examine some characteristics
the file searched before any modification correct file.
Whenever a translation
be done as a check.
tool
For example, when a complicated of
to make sure that we are operating on the
is performed,
The defensive programming
redundancy
to improve the reliability
techniques
should be applied must be considered
a reversed
translation can also
techniques can be viewed as software
of the program.
The degree to which these
carefully in order not to degrade
the efficiency of the program significantly. In a multiprocessor
system,
software defense can be provided by the architecture
of the operating
system.
the processors.
The design of an operating
The operating system functions
enables us to achieve a fail-soft behavior operating
can be distributed
system with distributed
among
intelligence
in presence of a software error.
The
system of the PRIME System is an example.
PRIME, developed at the University of California, time-sharing
system designed for continuous
effectiveness. dynamically processors.
[Bas 72].
designated
Berkeley,
availability,
It is a multiprocessor
is an experimental
data privacy,
and cost
system in which one processor is
the job of the control processor and the rest problem
The technique of d~namic verification
is used in the construction of
142
the operating system to ensure continuous availability and the data privacy of a user even in the presence of a single hardware or software fault.
[Fab 73].
Furthermore, multiple faults will not lead to unreliable operation unless they reinforce each other.
Dynamic verification of a decision implies that every time
the operating system makes a decision there is a consistency check performed on the decision using independent hardware and software. control monitor of the operating system.
This technique is applied in the
The control monitor performs the functions
of scheduling of processes to be run on problem processors, the allocation of memory pages and disk cylinders to processes, and the management of a virtual communication system.
St consists of two parts, the central monitor (CCM) add the extended control
monitor (ECM).
The CCM is written in a high level language and is executed only by
the control processor.
The ECM, resident in the problem processors, is microcoded
and acts as a local representative of the CCM to enforce its decision.
However,
dynamic verification is possible because the CCM does not interact directly with the ECM hut rather by sending messages to the ECM.
Each time a decision is made
by the CCM~ such as starting a process sending a message to a process, or allocating a resource, the ECM can verify if the action of the CCM is appropriate.
Enter-
process cormnunications are performed through messages and are similarly checked by the ECM's.
The decision making and decision checking processes are performed by
different hardware and using different algorithms.
Therefore, the integrity of the
system is maintained in the presence of a single hardware fault or software error. Such decision verification procedures can also he applied to other software architecture with distributed intelligence. 3.3
Conclusion Several programming systems of considerable size have been developed using the
constructive approach, notably the THE System~ the information bank of the New York Times, etc.
All these systems have shown to be very reliable after it has been
put into use.
For example, the information bank of the New York Times has been put
into operation for 13 months before the first error was detected that resulted in system failure.
The acceptance test took a total of 9 weeks and only 21 errors
were detected, all of which were fixed in one day [Boe 73].
The productivity of
the programmers is high, 83000 lines of high-level language source code produced in Ii man-year
(6 men and 22 months).
The reliability of the program is high,
with only 25 errors in over a year's operation.
This corresponds to approximately
one error for each 5 man-months of effort on the project, which is quite remarkable. [Bak 725].
As a result of using the constructive approach
to
reliable programming,
the project cost was cut by 50% and development time was reduced to 25% of the initial estimate!
[Boe 73].
The mission simulation system developed for the
Skylab operations by IBM has similar success.
400,000 lines of code w e r e
produced in 2 years and the software was delivered on the original schedule in spite of 1,200 formal changes
in the requirements.
[Bak 73].
143
The constructive approach therefore appears to be a very useful way of designing and i ~ l e m e n t i n g
reliable programs.
are skeptical of its success. relatively
time programmers THE System.
The number of programmers
They are experienced,
like the national
involved are small, six full-
well discipllned
in the
with leader-
It may be doubtful if the same remarkable
in a large programming
programmers.
guidelines and principles
(mostly mathematicians
training in the THE System), and under excellent
ship (Mills, Baker and Dijkstra). can be achieved
to really large programs
in the New York Times Project and six half-time programmers
5 to 8 years of university
unexperienced
there are still people who
The systems constructed by this approach so far are
small and simple compared
missile defense programs.
However,
project involving,
success
say, 2000 relatively
Besides, most of the theory developed in this area are rather than procedures which a prograrmmer
by step to construct his program,
especially
in the design stage.
can follow step Many of the tasks
have to be performed manually and decisions have to be made arbitrarily without any methodology
to evaluate
them before,
or even after,
they are made.
the system depends as much on the experience and judgement the programmer.
For example, Dijkstra
suggested
in a way so that the number of relevant
tested.
However,
that will enable us to arrive at this end product.
there is no
There may even be
cases where this is impossible, when the decisions are tightly "interwoven' In the design of the system with the "top-down" approach,
difficulties
are encountered
program.
the structural programming
be able to mechanise
tools can be used to help us to design, in validating
stage is clearly very valuable.
necessary for the end product. improve program reliability
4.
Integrity of a program
4.1
Introduction
Therefore,
and evaluating Obviously,
of software.
some of the procedures
implement and test the our decisions during the
such tools are still
it seems that the analytic methods
to
approach, when the program is too large and complex.
By now we have already surveyed different methods Reliability
approach makes
are still essential for assuring the quality of programs
developed by the constructive
ware.
When
easier.
Computer assistance
development
Besides,
in a level, it may be necessary for us to go back and
Fortunately,
It is highly desirable for us to so that automated
level.
procedure of large modules is done in an arbitrary fashion.
modify the higher levels. such modification
together.
approach or the "levels of abstraction"
it is difficult for us to decide how to form a "complete"
the decomposition
too much
that the program should
test cases at each stage of
testing will be so small that they can be exhaustively general method
as on the intuition of
In general, we know what the end product should be without
idea on how to arrive at it. be structured
The design of
to construct reliable
soft-
implies the ability to perform a specific function by the piece
However,
the correct operation of the process created by the piece of
the software cannot be achieved
if its integrity cannot be guaranteed.
Integrity
144
is a particularly controlling
serious problem in large real-time systems since the program is
an on-going physical process such as a nuclear reaction,
control system or a national anti-ballistic
missile defense system.
the security of a program is as important as its reliability. is usually associated with malicious unauthorized
air traffic In many cases,
Loss of integrity
tampering of the code of a program by an
intruder in a hostile environment.
This is not necessarily
the case.
Loss of integrity may be caused by a subtle software bug inside the program itself. Modification
of code by another user may be unintentional,
operating system.
Transient hardware faults can also cause tampering of codes
which are very difficult
to detect.
Real-time systems are especially vulnerable
to intrusions since they have to he on-line and accessible users.
due to a flow in the
This makes protection quite difficult.
in a multi-processor
system since processes
to a large number of
Things are even more complicated
are created and destroyed
and they may even co-operate in a mutually suspicious manner. such software systems has to be safeguarded
in real-time
The reliability of
against intentional or unintentional
intrusion. If an intruder can masquerade procedures
ingeniously as a legal user, follow normal
and perform normal operations,
detect it in real-time.
there is very little that we can do to
An intrusion is usually detected by abnormal phenomena,
such as a user accessing a part of the memory not assigned to him, a user's attempt to read a file with the wrong password, authorization.
or an execution of a program without
Since a residual software bug can also cause such derivations
the normal behavior,
all of these can be viewed as software bugs, either in the
user program or in the operating system. reliability
from
and integrity of the program.
There is a close relationship Security safeguards
between the
can therefore be
considered as a form of software bug trapping mechanism in real-time.
The integrity
of a program is protected by security measures, which protect the program from accidental or intentional disclosure
to unauthorized
users and from unauthorized
modification. In real-time systems particularly banking,
it becomes particularly
those dealing with national defense and
important for the security of the system to be
sure that the program contains no critical software bugs and that the system will not compromise
the sensitive information when there is a hardware failure.
The
software bugs in the program can lead to a breach of security and may he planted by an infiltrator.
A large computer program must necessarily
number of programmers.
An intelligent
stage when the program is most vulnerable, software errors can be introduced conditions arise. infiltrator
involve a considerable
infiltrator will therefore start at the namely, when it is being written.
Subtle
to make the program inoperative when special
Secret entry points and loopholes can also be created by the
for later usage.
when these errors are
Not only are these bugs difficult
discovered,
the ingenious infiltrator
to find but even
can always appear
145
as an ingenuous programmer be fired!)
to releive the blame.
The risk of the infiltrator
countermeasure
is to validate
(However,
in any case, he should
is therefore minimal.
The only effective
the system with automated tool so that it operates
correctly as required for all the inputs at all time. Active infiltration different ways. questions.
into the system during its operation can be achieved in
[Pet 67].
A person may use legitimate access to ask unauthorized
He may find subtle entry points or "trap doors" which may exist by
virtue of the combinatorial also masquerade
aspects of the many system control variables.
as a legitimate user by unlawfully obtaining
tion such as a password or by intercepting sign-off signals,
followed by continued
method of infiltration
and cancelling
He may
the proper identifica-
the legitimate user's
operation under his name.
Another common
is by examining the contents of core memory left behind by
the previous user to look for useful information
such as passwords,
file names,
An intruder may also force his entry into a critical program and execute it.
etc.
More-
over, a clever person may be able to put his process into supervisor mode and then virtually do anything that he likes.
Protection of the integrity and privacy of
programs must be provided against all these active threats. 4.2
Security analysis Security is the process of detecting and preventing unauthorized modification,
access and snooping of sensitive information. safeguards built into the management As in any large-scale is possible
system,
This implies the necessity of adequate
and hardware/software
aspects of the system.
the analysis effort is considerably reduced when it
to arrange the system in a hierarchical
fashion.
Then we can conven-
iently concentrate our effort at one level at a time, starting from the lowest level.
At each level, we can neutralize
"hardcore"
the threats,
to work on the next higher level.
a hierarchy of 6 levies, according
thus providing a secured
A secure system can be arranged into
to the vulnerability
to threats.
(See Figure 24)
The lowest or the most critical area which must be secured is the program specification.
Inconsistent
or poorly defined specifications
ready means to introduce programming
would provide the
bugs, such as trap doors and loopholes.
specification must be very rigid, providing no reason for ambiguity. of security involves execution.
the operating system,
The operating
The
The next level
since it could modify any program under
system must be checked to see that it interacts with the
job program properly and would not modify it in an unknown way. security is concerned with the program implementation
The third level of
process of the specification.
The program design must be such that the behavior of the execution sequence must be clearly visible from an examination of the static code. analysis
In other words,
a static
of the code should reveal all actions the program takes very clearly.
This
implies that the program must be structured and modular. The next level of security involves computer operator,
since bad maintenance
the machine diagnostic aspects and the procedures
could reveal the contents of the
146
memory or an unscrupulous computer operator may modify the contents of the memory without proper authorization. security.
The next level of
execution time interferences.
Hardware faults are also threats to the system security will consider the active threats, which are Here the safeguards would involve authentication of
entries of users into the system, real time sequence checking (relay runner) and real time validation of code before execution.
The last level of security
would
be threats which involve stealing the information physically from storage devices or by monitoring the radiation emanated bv the electrical devices.
Figure 24
4,3
Levels of Security Analysis
Security safeguards
4.3.1
Safeguards against software and hardware errors. The first three levels of security can be protected by validating the
program against software errors. can be used. committees.
Techniques for constructing reliable programs
Precise and unambiguous specifications should be formulated by The programs should be written as structured programs so that high
leVel personnels can understand and verify them.
Well-structured programs make
loopholes and planted bugs easily visible.
The interface between the program and
the operating system should be validated.
After that, automated tools can be used
to analyse and test the system for security. The maintenance engineer and console operator have direct access to the machine.
Reliable personnel should be employed in these important positions (from
a security point of view).
The integrity of the hardware system can be checked
by performing periodic diagnosis.
Techniques for protecting the system from hard-
ware malfunctions are well-known [Ram 74a], though rarely implemented, due to the high cost.
Thus the fourth level of security can be satisfactorily protected.
147
4.3.2
Safeguards against active threats
4.3.2.1
Introduction Hardware and software safeguards can he used in this level of security.
Hardware safeguards can be used to make sure that privileged instructions can only be executed in the supervisor state.
Privileged instructions prevent the user from
interfering with the operating system or another user's file or program.
Various
types of memory protection schemes are useful to protect the integrity of user programs and data, such as relocation and bounds registers (in CDC 6000 series), lock and key scheme (in IBM 360 series), paging (in XDS 940), segmentation (in Honeywell 645), etc.
The ring structure in Multices can also provide adequate
protection of user privacy.
Other types of hardware countermeasures include built-
in identification codes for computers (such as the IBM 370) or terminals, microcode, etc. Software safeguads can be provided by access management and threat monitoring. Access management deals with the methods of accessing information and service in the computer and determining who is going to get what.
Different ways of
authentication and identification of users can be used, such as passwords,
authentication algorithms, and proferring of physical items like badges, fingerprints, etc.
Threat monitoring keeps a record of all access or attempts to access
sensitive data and service.
A log of all sensitive operations can he kept,
recording who got access to what.
A review of this record periodically can detect
unauthorized attempts to use sensitive information or service.
All successful
breach of security are also recorded, allowing the system manager to close these trapdoors.
Besides, it is an effective tool against intrusions based on a trial
and error strategy.
Threat monitoring should always be active as long as the
computer is operating.
Therefore, we must make sure that it will not be deactivated
hy a privileged instruction. All these safeguards have been discussed extensively in current literature. [Hof 73]°
However, all these techniques can only be used in the design of the
hardware and software of the system. in the security of the system.
The user remains a helpless prey of loopholes
It is highly desirable for a user to have program-
ming techniques which he can use to protect critical sections of his program.
The
"relay-runner" scheme in the next section is such a technique. 4.3.2.2
The "relay-runner" scheme In order to prevent illegal or execution, we can authenticate all entries
into the system by means of passwords~ etc. [Gar 70].
If the intruder enters the
system masquerading as a legal user, the "relay-runner" scheme can be used effectively to neutralize his threats.
The "relay-runner" scheme provides
protection against illegal execution of the code by an infiltrator as well as prohibits illegal jumps and modifications that may be due to software errors or hardwaremalfunctions
in the system.
This is achieved by detecting all illegal
148
changes in the execution sequence. Consider the case of a simple assembly language program with no branchings no loops.
This piece of code can be partitioned
checkpoints.
These checkpoints
system,
into blocks separated by relay
are conditional statements
flow carries the valid, up-to-date relay code.
and
to test if the program
The user, upon legal entry into the
enters the program and executes from the first executable statement.
it stores the first of a series of relay codes
(baton) in some address,
Here
say, RYCI.
Then the normal program begins execution.
When program execution reaches the first
relay checkpoint,
the content at RYCI with a preset code
number.
the instruction compares
If the codes agree, the content of RYCI is changed to some other number,
and a new relay code is stored in location RYC2. the test at the first relay checkpoint, discontinued.
If the codes do not agree during
a trap routine is invoked and execution is
This process is carried on at suitable intervals
program, with the "baton" carried along.
This is analogous
the next relay-runner will not continue unless he receives previous runner. sequence.
This prevents the programmer
If he jumps ahead by one step the relay-point
execution, discontinue
its execution.
The "relay-runner"
where
the execution
is not yet activated and
If the programmer backtracks
the old "baton" value is already lost and the relay-polnt
into the program for unauthorized
the
the "baton" from the
from modifying
so the program will not continue its execution.
throughout
to a relay-race,
in his
check will also
protocol also prevents illegal entry
code execution since the intruder will not possess
the correct "baton", which is generated in real-time.
The use of "relay-runner"
checks therefore reduces the legal entry points into one, which can be tightly protected.
Depending
on how closely the relay checkpoints
degree of security is obtained. rity.
are installed,
a varying
Closely installed checkpoints give tighter secu-
Fig. 25a gives a graphical representation
of the Relay Runner concept.
To visualize how the program of Figure 25a is protected
from illegal execution,
assume the legal user has just executed the instruction p3 in Figure 25b and is in waiting state because of some resource request.
An infiltrator
of codes and starts executing the instruction at PI.
enters this piece
He will be successful until
program control reaches RP2, at which point the content of RYC2 is compared with 15. Since the legal user has executed Therefore,
the instruction at CP21, RYC2 now contains 200.
the test fails and the trap routine will be invoked.
If branching exists in the original program, ment of relay codes and checkpoints
care must be taken in the place-
such that every possible path of program flow
is covered, and that the setting and resetting of relay codes do not interfere. general,
the programmer
should organize his program so that all branches
emerge from one common exit. at the exit point.
In this case,
the relay checkpoint
Figure 26 shows one way of achieving
this.
In
should
can be placed right
lq9
Start
>I, RYCI(--5 -]
Entry
? CODES T
RYCI*-5 CODES RYCI=5? RYCI<--I00 RYC2~--15
RPI CPII CPI2
First Relay Checkpoint I RYCI~I00 RYC2+-]5 1
CODES
I
+coo i
Second Relay Checkpoint
Pl RP2 CP21 CP22
RYC2=I5? RYC2*-200 RYC3~155
0
CODES
$
RP3 CP31 CP32 p3
> r
Figure25b Existence of :ritical Points within the Protected Program.
Figure 2 ~ A Partial Flowchart for a program with the Relay Runner scheme implemented.
If loops exist in the program,
relay checkpoints may be placed right before
and after the loops if they are small.
But if much input/output
the loop, the programmer may wish to put checkpoints is advisable, single-exit
in most cases, to organize
fashion.
RYC3=155? RYC3<--89 RYC4F756
is done within
inside the loop as well.
the loops and branches
It
in a single-entry/
A tagging strategy may also be used to indicate the specific
paths traversed so that the proper relay codes are addressed at the common checkpoints.
Reset RYC , F ~ - ~ ('onditional S t a ~
II ~ J
I
Relay checkpoint Ye~s' Figure
26
Configuration
to handle Branching inside Program.
Some programs using this technique were run on a CDC 6400 system with COMPASS support.
The objective is to obtain some overhead figures for various block sizes
and sub-block sizes. resemblance
The structure of the actual program used bears a close
to the one described
in Figure 27
[Ng 73].
With a mean program length of 80000 COMPASS
instructions,
run-time overhead
150
figures are obtained for programs with block sizes up to 5000.
The results are
summed up by the graphs of Figure 28.
~"1
Start
1
KODE(5)+-123 IXle-9
'J
i
n Instructions
I
& IXl+-IXI-4 ¢
I
.......I
], ,, n Instructions
J
I'
IXI~-IXI +20
1
j
n Instructions
I
[,
I Xl<--I X1-20 "" ,,,--]
JKODE(a) --KODE(5)-26 IXN--IXl-19 A refined relay-runner implementation using indexing
Figure 27
oo
I00
~
Block size = 20
size : 150 O0
10
> O a)
E
"~~: lO00
1
2OOO
Block size : 5000 4-J eU
~
o.1
I
1o
Figure 28 For sizes of to 0.89%.
I
Ioo
16o
Run-time overheads for some simulation runs n
ranging from 3 to i000, the run-time overhead varies from 55%
Since these are average figures,
the user has the freedom to protect the
critical parts of his codes with a small block size. While overhead figures of 25% or 50% may sound high, typical programs do not
i5i
have large critical areas, so that large block sizes can he tolerated.
Note that
overheads between i% and 10% can be achieved by using block sizes of 2000 and smaller.
Therefore,
the Relay Runner scheme is a valuable
illegal executions due to ur~arranted
tool for controlling
intrustions or unpredicted
errors in real
time programs. The above discussions procedures 4.3.2.3
and schemes are equally applicable
and shared codes provided
to protecting pure
that users have their own data storage.
Integrity checks Even with all these safeguards
that the system is absolutely penetration
secure.
implemented,
there is still no guarantee
A real subversion is usually caused by a
that has not been detected.
illegally modified can be disastrous.
'The execution of a program that has been It is desirable
therefore to be able to
check the integrity of the system periodically
or just before critical programs are
executed.
of damage is very important.
In real-time systems,
thedetection
many cases, we would rather stop a process performed
than allow a wrong operation to be
since many of the results are inevoeable.
To ensure that the code to be executed is not illegally modified, validate
In
the code just before execution.
one could
A simple scheme for this will be to
develop a check sum of the contents of the code to be executed and compare it against the correct check sum that is stored at a secure place. check sum agrees, recompute
the sub-program
is allowed to be executed.
the check sum for validation
modifications
If the computed
It is important
to
of the sub-program if some authorized
are made during execution.
The integrity of the hardware of the system can be checked by periodic diagnosis.
The design of systems which can tolerate hardware faults has been
investigated control,
intensively.
[Ram 74a]. However,
in systems employing stored program
software problems can also destroy the integrity of the system, and then
the user programs. maintenance,
Software errors can come from residual design errors,
or intrusions
from external sources.
integrity of the system for continuous defenses can be used.
[Con 72].
sequence of operations
They include circuits
interpreted
by program action.
as a software error.
the proper
timer which have to be
A failure to reset the timer will be
In-line program checks can be provided by the or abnormal states of the
These will also include defensive programming
last section.
to monitor
of the program and trigger recovery action if an error is
program itself to check for "impossibl~'conditions program.
that monitor program operation,
Circuits can be designed
An example is the use of an external "watchdog"
reset periodically
for the environment
Some techniques used by the ESS system of the Bell System
in-line program checks, and audits.
detected.
different kinds of software
These defenses are highly specialized
in which they are used. are presented here.
operation,
incorrect
In order to protect the
techniques discussed in the
152
Audits are a collection of independent correct errors in memory content.
check programs which detect and
These techniques are especially necessary for
systems employing stored program control,
such as the ESS.
Audits can use the
redundancy in the software structure to perform logical cheeks to locate errors and inconsistencies.
Sometimes the redundancy
as a linked list. for audit programs. frequently
is inherent in the data structure,
In other cases, it may be necessary
In these systems, audits have to be run periodically
to ensure the integrity of the memory content.
system reinitializatlon
such
to expand the data structure
during recovery from an error.
and
They are also run during
Audit programs can be used
to check that a linked list structure is intact or to verify the integrity of data constants and parameters
stored in a writable memory by consistency
less volatile backup record.
checks with a
Integrity checks can be performed by comparing
some
redundant data stored in different parts of the system to detect state discrepancies of facilities
involved.
Timing checks can also be used to ensure that no facility
is being used beyond its maximum allowed time-limit. facilities due to an error.
Audits are integrated
This prevents the loss of
into the system software.
can be run in an interleaved
fashion with normal system operations.
of errors by audit programs,
a recovery procedure follows.
be used to return the software to a "safe" state. system reinitialization 4.3.3
Safeguards
They
After detection
Backup information can
If the error is serious, a
may be performed.
against passive threats
Passive threats consist of different means to obtain information illegally, including wiretapping,
unauthorized
effective countermeasure
access to data in removable files, etc.
against these threats is encryption.
form of privacy transformations,
The
Encr~ption is a
which takes data in its natural form and transforms
it by scrambling so that it is hopefully unrecognizable
by unauthorized
Therefore even if a person is able to obtain the information,
people.
it will be meaningless
to him. An encryption system can be visualized
I
Source Text M
1 M
in Figure 29.
T(M'K) ]Ciphertext I T'I(M'K) 1 ~ >. Transmitting I ~,. ~ ReceivinqDeDevice(CiPher,| . ~ n , ~ j vice(Dec~Dher)I '" Key Source
Figure 29
An encryption scheme
The operation done on the source text called the "key".
characters
M
depends on an input parameter
K,
This key is essential for us to perform the decipher process.
Only authorized people possess this key. substitution
Key Source
Some simple encryption procedure includes
of one character strings for another,
to message characters
algebraic addition of key
to form encoded messages,
or rearrange~ment of the
153
ordering of characters referred
in a word.
For different encryption schemes
to the famous book "The Codebreakers".
4.3.4
, the reader is
[Kah 67].
Conclusion We can see that the reliable operation of a large program depends on the
integrity of the program, which in turn hinges on the integrity of the system. number of security measures discussed here.
A
to protect the integrity and privacy of the system are
These techniques can be applied to protect the system against
simple hardware and software errors internal to the system as well as intrusions and threats from outside the system.
However,
a user must always bear in mind that
these security measures do impose a cost on the user, in the form of longer execution
time, larger memory storage, hardware redundancy,
inconvenience.
The extensiveness
on the sensitivity successful
to which these techniques
of the information
intrusion.
are tailored
should be applied depends
to be protected and the penalty-cost
A cost-effectiveness
urgently needed in the near future.
software redundancy and
of a
analysis of each of these techniques
Unfortunately,
to certain specific environments.
is
however, many of these techniques
It is very difficult
to generalize
many of these techniques for analysis. After the safeguards have been implemented, to evaluate the effectiveness
of the protection
different means to improve the protection measurement
and modelling.
ADEPT-50 Model from perfect,
[Wei 692,
that they provide to the system and
economically.
This can be achieved by
Several models have been proposed, Turn's Model
they represent
[Tur 72], etc.
some significant
evaluation of security systems.
including Weissman's
Although these models are far
efforts towards the performance
Of course, all these safeguards would be wasted if
we do not have a good administrative to achieve this goal are discussed 5.
it is desirable for us to be able
and physical security.
The techniques required
in the book by Van Tassel
[Van 72].
Conclusion From the discussion
in the previous sections, we have surveyed different prob-
lems of developing large reliable computer programs and different techniques improve the reliability and their weakness.
of a program.
Fortunately
to
All of these techniques have their advantages
these techniques complement
each other and a com-
bination of these techniques can enable us to produce a piece of reasonably reliable medium-sized
software.
For really large computer programs,
to be done, as indicated throughout
a lot of work still need
the text.
We are proposing the following scheme as a reasonable approach to develop reliable large-scale
software:
(i)
Specifications
(2)
Design of the structure,
of the system.
with the specification
decomposition,
and modularization
of each module.
(3)
Coding of the system in a suitable programming
(4)
Debugging,
integration
language.
and check out of the system.
of the system,
154
(5)
Software evaluation and partial validation with the help of automated
(6)
Software fail-safe fail-secure instrumentation.
(7)
Validation of protection and security measures.
tools.
The specification of the program has to be concise and precise, providing the implementor all the informations that he needs in order to complete the program. uniform specification language should be used for modules at different levels.
A The
language should be sufficiently formal and yet descriptive, allowing a programmer to understand all the exterior properties of the module easily.
Some formal languages
for the specification of software modules have been proposed, such as by Parnas [Par 72].
However, the usefulness and effectiveness of specification using a formal
language still need to be evaluated since not enough experience has been reported. The investigation of the relationships between the external properties and the internal attributes of a program is also needed. The design of the program involves the decomposition of the program into smaller modules and the organization of these modules. been discussed in section 3.1.2.
Some design methodologies have already
Liskov has also proposed some guidelines for the
design of reliable software systems [Lis 72b].
Abstraction is a very useful concept
to simplify and order the compexity of the system. being done without the details of how it is done.
The abstraction specifies what is The identification of abstractions,
however, depends very much on the designer and the concept that he wants to support and clarify. system.
In some systems, abstractions of resources are used to structure the
In systems for supporting a data base, the characteristics of data structure
may form good abstractions.
In order to make the modules for different levels of
abstractions to be logically independent, the combined activity of the functions in a level of abstraction should only support that abstraction and nothing else. The system should be designed for maintainability and adaptability.
ILls 72b]
The levels of
abstractions should be arranged in a heirarchy fashion (as discussed in section 3.1.2.) and data used by 2 different levels should be passed as explicit arguments only.
The distribution of system resources in this hierarchy should also be deter-
mined before implementation starts.
The design of the program is still an art
although much discipline have already been introduced by the concept of structured programming.
Since the development of the program depends very critically on the
initial design, much research work is urgently needed for methodologies to evaluate the design and propose improvements before the actual implementation of the program takes place. The implementation of the system should be carried out with discipline. philosophies of structured programming should be enforced. written for readability and understandability.
The
The program should be
Wherever the restrictions of struc-
tured programming (as presented by Dijkstra and Mills) seriously affect the productivity of the programmer and the efficiency of the program module, these restrictions
155
should be relaxed in a local level,
i.e., the program module should behave like a
structured program when used externally although it may be "unstructured" extent internally.
Attributes
cussed in section 3.1.1.3. "structure documentation" correctness
for a structured programming
Some equally important areas of research may include and "structured"
techniques
for an informal proof of
of each module.
The debugging of the program should be carried out in a bottom-up ing from the individual modules. structural flows.
A compiler with powerful diagnostics
programming
The development
should be used at this stage
(This optimizing
compiler,
of course, has
of verifying compiler for potential structured
languages are also very valuable,
such languages.
start-
An optimizing compiler may be used to generate
code after the debugging stage.
to be very reliable.)
fashion,
The compiler can locate syntax errors as well as
rather than one with high efficiency. efficient
to a certain
language have been dis-
since it will also help us to design
Assertion languages will also enable us to establish our confidence
on the program by an informal proof. When the modules are integrated validation logically
together,
systems can be used effectively. independent,
abstraction
automated evaluation and partial
Since the modules are written to be
the number of relevant test cases for modules in 2 levels of
is the sum of the relevant test cases for each level, not the product.
The testing of combinations
of modules requires only the validation of the interface
(input and output parameters) between modules.
of the modules since this is the only interaction
There are no complicated
interaction
in control or implicitly
data because the program is written with structured programming.
Therefore,
see how design can simplify the testing and check-out of the program.
of the program is very easy.
is still far from satisfactory helpful for the programmer's corrected,
Automated
synthesis of test data.
to collect program behavior This piece of self-metric measures of the system.
data base
generation of test inputs
although computerized
assistance is very
When an error is discovered and
the AEVS can also help us to avoid introducing undesirable
other parts of the program.
development
at present,
we can
The automated
evaluation and partial validation systems also will build up a maintenance so that modification
shared
Different monitors can be introduced
side-effects
to
into the system
statistics and provide run-time analysis of the program.
software may also enable The development
us to quantify some reliability
of a useful reliability model for software
is urgently needed.
After all these careful development be quite reliable. cannot be tolerated.
However,
and extensive validation,
for some real-time systems,
Software fail-soft
instrumentation
the program should
such low error-rate still can then be applied to detect
and contain software errors in real-time using software defenses.
Hopefully,
unde-
sirable actions due to software errors can be avoided and damages minimized when such errors are detected as early as possible.
Fail-secure
instrumentation
to protect the integrity and security of the information intrusions
or system software and hardware errors.
are designed
in the system against active
These instrumentations
depend
156
very much on the operational environment of the system.
Therefore, these protection
and security measures have to be validated in the appropriate environment.
Appendix A.
Techniques for the manipulation of the graph model
For any,model, the essential requirement is that the manipulation techniques must be amenable to automation.
Various techniques for manipulating the graph
model are available.
The most representative approach is based on the use of a
connectivity matrix.
The graph is represented by a connectivity matrix
which one row and one column correspond to each node and
C
in
C.. = 1 if and only if 13 Fig. A.I is the
there is a directed arc from node i to node j in the graph. connectivity matrix of the program graph of Fig. 6. 123456789 1 2 3 4 5 6 7 8 9 Fig. A.I
010000000 0 0 1 0 0 0 0 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 1 0 0 0 0
0 0 0 0 1 0 0 0
0 0 0 0 1 0 0 0
0 0 0 0 0 1 1 0
The connectivity matrix of the graph of Fig. 6
On the basis of this representation, various manipulations can be performed in a convenient way,
The suitability of this machine representation mainly comes from
its structural resemblance to the storage structure of most computers. basic techniques are mentioned here,
Some of the
A node j is said to be reachable from node i
if there is at least one directed path from node i to node j.
All nodes reachable
from each node can be easily found.
is a matrix in which
A reachability matrix
one row and one column correspond to each node and is reachable from node i. is an unit matrix. j in
R
R = lim (C+I) N where I N-~= A more efficient algorithm was developed in [Ram 66]. A column
represents all nodes which can reach to
M.
Moreover~ if
Mi # 0~
correspond to the nonzero columns of
1
[Pro 59]
j.
By using
First a new matrix
R,
all MSC sub-
M = RAR T
is
The number of MSC subgraphs is given by the number of distinct nonzero
row vectors of
columns of
if and only if node j
It was shown in [Pro 5 9 ] i t ~ t
graphs can be simply identified as follows. obtained.
R.. = i
R
M2. are
(2,3p5).
So~
then the nodes of the MSC subgraph
Mi.. In Fig. A.2~ M2. # 0 and the nonzero (2,3,5)
are all nodes in that MSC subgraph,
Prosser, R., "Applications of Boolean Matrices to the Analysis of Flow
Diagrams" Proc. Eastern Joint Comp. Conf. 1959.
~
0
or' f0
~1
~ ~
~
~
r l~
N
~,
~.
F,~
o ~c~
0
~
~
F.'-
c~
I~,
re
0 I:I ~, o
H MI
B
F~-
o
F~.
m
Mh
0
I--i
m
~
~1
o
I~~
~
m
~
~"
m
~,~
0
0
0
0
0
o
0
0
0
O0
O0
O 0
Oo
0 0 0 0 0
0 0 0
0 0 0
OOC)
II
D I.-3
I-~ F-,
I.,.~ F,.~ F'* I-',~
O F ~
0
0 o o 0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
o o o
0
LTI -'-.l
158 REFERENCES [Ale
69]
Alexander, T. "Computers Can't Solve Everything," Fortune, May 1969.
[Ash
71]
Ashcropt, E and Manna, Z. "The Translation of 'go to' Programs to 'while' Programs," Stanford AI Memo AIM-138, STAN-CS-71-188, January 1971.
[Bak
72a]
Baker, F. T., "Chief Programmer Team Management of Production Programming," IB_M Syst. J., 1972, pp. 56 - 73.
[Bak
72b]
Baker, F. T., "System Quality Through Structured Programming," Fall Joint Computer Conference, 1972, pp. 339 - 343.
[Bak
73]
Baker, F. T. and Mills, H. D., "Chief Programmer Teams," Datamation, December 1973, pp. 58 - 61.
[Bas
72]
Baskin, H. B., Borgerson, B. R. and Roberts, R., "PRIME - A Modular Architecture for Terminal-Oriented Systems," Spring Joint Comp. Conf., 1972, pp. 431 - 437.
[Ben
73]
Benson, J. B., "Structured Programming Techniques," Record of the 1973 IEEE Symposiumon Computer Software Reliability, May 1973, pp. 143 - 147.
[Boe
71]
Boehm, B. Wo, "Some Infolunation Processing Implications of Air Force Space Missions: 1970-1980," Astronautics andAeronautics, January 1971.
[Boe
73]
Boehm, B. W., "Software and Its Impact: DATAMATION, May 1973.
[Boh
66]
Bohm, C. and Jacopini, G., "Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules," C o m m o f ACM, May 1966, pp. 366-371.
[Bro
72a]
Brown, J. R. and Hoffman, R. H., "Evaluating the Effectiveness of Software Verification - Practical Experience with an Automated Tool," AFIPS FJCC, 1972.
[Bro
72b]
Brown, J. R. and Hoffman, R. H., "Automating Software Development: A Survey of Techniques and Automated Tools," TRW Tech. Rep., May 1972.
[Cha
73]
Chang, H. Y., "Topics in Designing Maintainable Real-Time Systems," Proceedingof the 2nd Texas Conference on Computing Systems, Nov. 1973.
[Che
74]
Cheung, R. C., Kim, K. H., Ramamoorthy, C. V., and Reddi, S. S., "Automated Generation of Self-Metric Software," 7th Hawaii International Conferenc__eon $~stems S qiences , January 1974.
[Cla
73]
Clark, R. L., "A Linguistic Contribution to GOTO-less Programming," DATAMATION, December 1973, pp. 62 - 63.
[Con
72]
Connet, J. R., Pasternak, E. J., and Wagner, B. D., "Software Defenses in Real-Time Control Systems," Digest of Papers of the 1972 International Symposium on Fault-Tolerant Computing, June 1972, pp. 94-99.
[Dij
65]
Dijkstra, E. W., "Programming Considered as a Human Activity," Information Processing 65, W. A. Kalenick, (ed.). Proc. of IFIP Congress 6~, V l, Spartan Books, Inc., Washington, D.C., 1965.
[Dij
68a]
Dijkstra, E. W°, "GO TO Statement Considered Harmful," Comm. of ACM, March 1968, pp. 147 - 148.
[Dij
68b]
Dijkstra, E. W., "The Structure of the "THE" - Multiprogramming Comm. ACM, 1968, pp. 341 - 346.
[Dij
69a]
Dijkstra, E. W., "Structured Programming," Software Engineering Techniques Report on a Conference sponsored by the NATO Science Committee Rome, Italy, J.N. Buxton and B. Randell (eds), 1969, pp. 84 - 88.
[Dij
69b]
Dijkstra, E. W. Notes 0n Structured Programming, Eindhoven, Netherlands, August, 1969.
[Dij
73]
A Quantitative Assessment,"
System,"
Teshnische Hogeschool,
Donaldson, J. R., "Structured Programming," DATAMATION, pp. 52 - 54.
December 1973,
159
[EIs
71]
Elspas, B., Green, M. W., and Levitt, K. N., "Software Reliability," Computer, January 1971, pp. 21 - 27.
[Els
72]
Elspas, Levitt, Waldinger, and Waksman, "An Assessment of Techniques for Proving Program Correctness," Computin~ Surveys. June 1972, pp. 97 - 147.
[Elm
71]
Elmendorf, W. R., "Disciplined Software Testing," Courant Symposium on Debugging Technique in Large Systems, 1971.
[Fab
73]
Fabry, R. S., "Dynamic Verification of Operating System Decisions," Comm. of ACM, November 1973, pp. 659 - 668.
[Flo
67]
Floyd, R. W., "Assigning Meanings to programs," Mathematical Aspects of Computer Science, Vol. 19, 1967, pp. 19 - 32.
[Gar
70]
Garrison, W. A. and Ramamoorthy, C. V., "Privacy and Security in Data Bank," Technical Memorandum No.?4, Information Systems Research Lab., University of Texas at Austin, 1970.
[Gol
63]
Goldstine, H. H. and yon Neumann, J., "Planning and Coding Problems for an Electronic Computer Instrument, Part 2, Vol. i - 3," John yon Neumann collected works, Vol. 5, Pergamon Press, New York, 1963, pp. 80 - 235.
[Goo
68]
Good, D. I. and London, R. L., "Interval Arithmetic for the Burroughs B5500: Four Algol Procedures and Proofs of Their Correctness," Computer Sciences Technical Report No. 26, University of Wisconsin, June 1968.
[Goo
70]
Good, D. I., "Toward a Man-Machine System for Proving Program Correctness," Ph.D. Thesis, Dept. of Comp. Sci., Univ. of Wisconsin, Madison, Wisconsin, 1970.
[Har
65]
Harary, T., Norman, K. Z. and Cartwright, D., "Structural Models: An Introduction to the Theory of Directed Graphs," John Wiley & Sons, 1965.
[Hof
73]
Hoffman, L. J. (ed.), Security an d Privacy in CpmPuter Systems, John Wiley & Sons, 1973.
[Ing
71]
Ingallo, D., "The Execution Time Profile as a Programming Tool," Courant Symposium on Compiler optimization, 1971.
[Ito
73]
Itoh, D. and Tzutani, T., "TABEBUG-I, A New Tool for Program Debugging," !EEE Symposium on C_omputer Software Reliability, 1973.
[Jel
73]
Jelinski, Z. and Moranda, P. B,, "Application of a Probability-Based Model to a Code Reading Experiment," Record of the 1973 IEEE Symposium on Computer Software Reliability, May 1973, pp. 78-81.
[Kah
67]
Kahn, D., The Codebreakers, MacMillan Co., 1967.
[Kel
73]
Kelley, R. A., "APLGOL, An Experimental Structured Programming Language," January 1973, IBM J. Res. Develop., pp. 69-73.
[Ker
73]
Kernighan, B. W. and Plauger, P. J., "Programming Style for Programmers and Language Designers," Record of the 1973 IEEE Symposium on Computer Software Reliability, May 1973, pp. 148-154.
[Kin
69]
King, J. C., "A Program Verifier,"Ph.D. Thesis, Carnegie-Mellon Univ., Pittsburg, Pa., 1969. King, P. J. H., "Decision Tables," Comput. J., August 1967.
[Kin
67]
[Knu
70a]
Knuth, D. E. and Floyd, R. W., "Notes on Avoiding 'go to' Statements," Computer Science Department, Technical Report No. CS 148, Stanford University, January 1970.
[Knu
70b]
Knuth, D., "An Empirical Study of FORTRAN Programs," CS-186, Dept. of Computer Science, Stanford Univ., 1970.
[Kra
73]
Krause, K. W., Smith, R. W. and Goodwin, M. A., "Optimal Software Test Planning Through Automated Network Analysis," !EEESymposium on Computer Software Reliabilitx, 1973.
160
[Lin
72]
Linden, T. A., "A Summary of Progress Toward Proving Program Correctness," Fall Joint Computer Conference, 1972, pp. 201-211.
[Lis
71]
Liskov, B. H. and Towster, E., "The Proof of Correctness Approach to Reliable Systems," The MITRE Corporation MTR 20.73, Bedford, Massachusetts, 1971.
[Lis
72a] Liskov, B. H., "The Design of the Venus Operating System," Comm. ACM, 1972, pp. 144-149
[Lis
72b]
Liskov, B. H., "A Design Methodology for Reliable Software Systems," Fall Joint Computer Conference, 1972, pp. 191-199.
[Lon
70]
London, R. L., "Bibliography on Proving the Correctness of Computer Programs," Machine Intelligence, 1970, pp. 569-580.
[Mad
60]
Madnick, S. and Alsop, J. W., II, "A Modular Approach to File System Design," AFIPS Conference Proceedings 34, 1969, pp. 1-13.
[Man
69a] Manna, Z., "Properties of Programs and the First-Order Predicate Calculus," Journal of ACM, April 1969, pp. 244-255.
[Man
69b] Manna, Z., "The Correctness of Programs," J. of Computer and System Sciences, May 1969, pp. 119-127.
[Man
71]
Manna, Z. and Waldinger, R. J., "Towards Automatic Program Synthesis," Comm. ACM, March 1971, pp. 151-165.
[McC
62]
McCarthy, J., "Towards a Mathematical Science of Computation," Proc. IFIP Cong., 1962, pp. 21-28.
[McC
63]
McCarthy, J., "A Basis for a Mathematical Theory of Computation," Computer Programming and Formal Systems, N. Holland Publ. Co., Amsterdam, 1963, pp. 33-70.
[McC
67]
McCarthy, J. and Painter, J. A., "Correctness of a Compiler for Arithmetic Expressions," Mathematical Aspects of Computer Science, Vol. 19, 1967, pp. 33-41.
[McC
73]
McCracken, D. D., "Revolution in Programming - An Overview," DATAMATION, December 1973, pp. 50-52.
[McG
71]
McGonagle, J. D., A Study of a Software Development Project, James P. Anderson and Co., September 21, 1971.
[Mee
73]
Meeker, R. E. and Ramamoorthy, C. V., "A Study in Software Reliability and Evaluation," Tech. Memo No. 39, Electronics Research Center, The University of Texas at Austin, February 1973.
[Mil
71]
Mills, H. D., "Top-Down Programming in Large Systems," Debugging Techniques in Large Systems, R. Rustin (ed), Prentice Hall, 1971, pp. 41-55.
[Mil
73]
Mills, H. D., "On the Development of Large Reliable Programs," Record of the 1973 IEEE Symposium on Computer Software Reliability, May 1973, pp. 155-158.
[Mil
74]
Miller, E. F., Paige, M. R., Benson, J. P., and Wisehart, W. R., "Structural Techniques of Program Validation," Proc. COMPCON, 1974.
[Nau
66]
Naur, P., "Proof of Algorithms by General Snapshots," BIT, 1966, pp. 310-316.
[Ng
73]
Ng, F., "Run-Time Protection Schemes for User Software," Master Thesis, University of California, Berkeley, 1973.
[Pai
73]
Paige, M. R. and Balkovieh, E. E., "On Testing Programs," IEEE Symposium on Computer Software Reliability, 1973.
[Par
71]
Parnas, D. L., "On the Criteria to be Used in Decomposing Systems into Modules," Technical Report CMU-CS-71-101, Carnegie-Mellon University, 1971.
161
[Par
72]
Parnas, D. L., "A Technique for Software Module Specification with Examples," Comm. of ACM, May 1972, pp. 330-336.
[Pet
67]
Petersen, H. E. and Turn, R., "System Implications of Information Privacy," Spring Joint Comp. Conf., 1967, pp. 291-300.
[Ram
66]
Ramamoorthy, C. V., "Analysis of Graphs by Connectivity Considerations," JACM, ]1966.
[Ram
67]
Ramamoorthy, C. V., "A Struetural Theory of Machine Diagnosis," AFIPS SJCC, 1967.
[Ram
71a]
Ramamoorthy, C. V. and Chang, L. C., "System Segmentation for the Parallel Diagnosis of Computer," IEEE TC, March 1971.
[Ram
71b]
Ramamoorthy, C. V., "Computer Program Models," Symposium on Computers and Automata, Polytechnic Institute of Brooklyn, April 1971.
[Ram
71c]
Ramamoorthy, C. V., "Fault-Tolerant Computing: Overview," IEEE TC, November 1971.
[Ram
71d] Ramamoorthy, C. V. and Mayeda, W., "Computer Diagnosis Using the Blocking Gate Approach," IEEE TC, November 1971.
[Ram
73a]
Ramamoorthy, C. V., "Error Control, Protection and Security of Real Time Computer Programs," Invited paper at the InternatiOnalComputer Conference in Taiwan, August 1973.
[Ram
73b]
Ramamoorthy, C. V., Meeker, R. E., and Turner, J., "Design and Construction of An Automated Software Evaluation System," IEEE Symposium on Computer Software Reliability , 1973.
[Ram
74 a ] Ramamoorthy, C. V. and Cheung, R. C., "Design of Fault-Tolerant Computing Systems," to be published in Applied Computation Theory (ed. by R. Yeh), Prentice Hall, 1974.
[Ram
74h]
[Ran
69]
Randel, B., "Towards a Methodology of Computer Systems Design," Software Engineering, January 1969, pp. 204-208.
[Rus
71]
Rustin~ R. (ed), Debugging Techniques in Large Systems, courant Symposium, 1971.
[Sac
70]
Sackman, H., Man-Computer Problem ' Solving, Auerbaek Publishers, Inc., 1970.
[Sho
73]
Shooman, M. L., "Operational Testing and Software Reliability Estimation During Program Development," Record of the 1973 IEEE Symposium on Computer Software Reliability, May 1973, pp. 51-57.
[Tur
72]
Turn, Ro and Shapiro, N., "Privacy and Security in Databank Systems: Measures of Effectiveness, Costs, and Protector - Intruder Interactions," RAND Corporation Memo P-4871, July 1972.
An Introduction and
Ramamoorthy, C. V., Kim, K. H., and Chen, W. T., "The Blocking Gate Approach to Software Testing," in preparation.
[Van
72]
Van Tassel, D., Computer Security Management, Prentice Hall, 1972.
[Wei
69]
Weissman, C., "Security Controls in the ADEPT-50 Time-Sharing System," Fall Joint comp. Conf., 1969.
[Wei
71]
Weinberg, G. M., The Psychology of Computer Programming, New York, Van Nostrand Reinhold, 1971.
[Wil
70]
Williman, A. O. and C. O'Donnell, "Through the Central 'Multiprocessor' Avionics Enters the Computer Era," Astronautics and Aeronautics, July 1970.
[Wul
71]
Wulf, W. A., Russell, D. B., and Habermann, A. N., "BLISS: A Language for Systems Programming," Comm. of ACM, December 1971, pp. 780-790.
G E R K T E T E C H N
IK
DER
P R O Z E S S R E C H N E R
Auswirkunqen der Mikroprozessor-Technik
auf Einsatz
und Struktur ZukUnftiger Prozess-Rechenanlagen yon G. F~rber
I.... Definition und Ei~enschaften von Mikroprozessoren Seit etwa zwei Jahren sind Mikroprozessor-Baugruppen verfUgbar.
auf dem Markt
Damals gelang es erstmals, komplexe Prozessor-Bausteine
und sogar komplette Prozessoren auf einem Halbleiterkristall
zu inte-
grieren und diese Produkte auch industriell zu fertigen. Heute vergeht kaum ein Monat ohne die Ank~ndigung eines neuen, noch leistungsf~higeren Mikroprozessors.
In Bild I wird der Versuch unternommen,
die heute bereits zahlreich
verfHgbaren oder angekHndigten Mikroprozessoren und damit verwandte Baugruppen
zu klassifizieren und durch einige typische Eigenschaften
zu beschreiben.
ZumVergleich
sind auch die entsprechenden Daten des
klassischen Minirechners mit aufgefUhrt
(Spalte I). Im folgenden wer-
den die einzelnen Prozessortypen kurz charakterisiert und auf ihre Eignung fur die ProzeBrechnertechnik
Spalten-Nr.
I MiniiComputer
2 3 4 5 7 6 Mikroprc " MikroMulti-ChipSingle-ChipMikroprozessoren Mikroprozessoren grammie~ - typei zuibare Pro -Computer heute kHnft~ gi zessorer heute kHnftig
z%l-
Zahl der Befehle
24-400
20-60
SpeicherzugriffsBefehle
ja
Pointer
Wortl~nge
8-32
4-8
Ausfilhrungs zeit ~ s e c )
I-6
5-30
ProzessorPreis (TDM) SystemPreis (TDM) Bild
10-50
0, I-1
i >
20
hin untersucht.
25-400
25-400
sehr groB
25-400
Pointer
ja
ja
nein
ja
8
8-16
8-32
~ 10
5-15
>0,01
~
50
8-24
4-16
1-6
0,2-1
4-16
0,5-3
< I
s-2o
0,5-2
>5
>5
>1o
.... >5
~>0,1
>5
(>1) : Klassifizierung und Eigenschaften von Mikroprozessoren
165
Single-Chip-Mikroprozessoren
(Spalte 2) v e r f ~ g e n bei einer V e r a r b e i -
t u n g s b r e i t e von 4 - 8 Bit Hber 20 - 60 Befehle, w o b e i der Zugriff zum A r b e i t s s p e i c h e r Gber einen P o i n t e r erfolgt,
der zuvor durch zus~tz-
liche Befehle g e s e t z t w e r d e n muB. FHr eine durch einen e i n z e l n e n Minirechner-Befehl
l~sbare A u f g a b e w e r d e n daher m e i s t m e h r e r e M i k r o p r o -
z e s s o r - B e f e h l e benStigt.
Daraus e r g e b e n sich - trotz der b e r e i t s r e c h t
k u r z e n B e f e h l s a u s f H h r u n g s z e i t e n - r e l a t i v hohe P r o g r a m m l a u f z e i t e n ; zukommt,
hin-
dab im P r o z e B r e c h n e r b e r e i c h eine W o r t l ~ n g e von 4 oder 8 Bit
m e i s t nicht ausreicht, e r f o l g e n muB.
so dab die V e r a r b e i t u n g in m e h r e r e n S c h r i t t e n
I n t e r e s s a n t ist der sehr n i e d r i g e P r o z e s s o r - P r e i s ;
lerdings zeigt es sich, dab die Kosten fHr k o m p l e t t e Systeme s c h l i e B l i c h S p e i c h e r und Peripherie),
al-
(ein-
auch w e n n sie sehr k l e i n sind,
w e s e n t l i c h h 6 h e r liegen und dab die T a u s e n d - D M - G r e n z e auch bei sehr h o h e n S t H c k z a h l e n und k l e i n s t e r K o n f i g u r a t i o n k a u m u n t e r s c h r i t t e n werden kann.
Die Tendenz z u k H n f t i g e r L o w - C o s t - M i k r o p r o z e s s o r e n her e i n e r s e i t s
(Spalte 3) geht da-
zu h S h e r e r A r b e i t s g e s c h w i n d i g k e i t und zu einer die Mehr-
w o r t - A r i t h m e t i k u n t e r s t H t z e n d e n Befehlsstruktur,
zum anderen darf sich
die H a l b l e i t e r t e c h n o l o g i e nicht auf den P r o z e s s o r beschr~nken. Nur w e n n b i l l i g e Speicher- und P e r i p h e r i e - B a u s t e i n e direkt, lichen S c h a l t k r e i s a u f w a n d ,
d.h. ohne zus~tz-
mit dem P r o z e s s o r g e k o p p e l t w e r d e n k6nnen,
ist ein E r r e i c h e n der H u n d e r t - D M - G r e n z e bei groBer StHckzahl denkbar, w o m i t die P r o z e B r e c h n e r - T e c h n o l o g i e ("Consumer Elektronik",
Multi-Chip-Prozessoren
in ganz neue A n w e n d u n g s b e r e i c h e
vgl. A b s a t z 2) E i n g a n g finden kSnnte.
(Spalte 4) sind w e s e n t l i c h l e i s t u n g s f ~ h i g e r und
e i g n e n sich b e s s e r fHr P r o z e B r e c h n e r a n w e n d u n g e n . dabei um ein 4 - B i t - P r o z e s s o r - E l e m e n t , (meist 16 Bit) Steuerelemente,
M e i s t h a n d e l t es sich
das zu b e l i e b i g e r W o r t l ~ n g e
z u s a m m e n g e s e t z t w e r d e n kann,
sowie um ein oder m e h r e r e
die die P r o z e s s o r - S t r u k t u r festlegen. Mit d i e s e n Bau-
s t e i n e n k~nnen P r o z e s s o r e n a u f g e b a u t werden, w e l c h e b e z H g l i c h des Bef e h l s i n v e n t a r s k l a s s i s c h e n M i n i r e c h n e r n gleichen, w ~ h r e n d ihre Ausf U h r u n g s z e i t e n nur um den Faktor 2 bis 4 h ~ h e r liegen. Zuk~nftige Multi-Chip-Prozessoren
(Spalte 5) w e r d e n sich von den heu-
tigen vor allen D i n g e n durch h ~ h e r e A u s f ~ h r u n g s g e s c h w i n d i g k e i t e n unterscheiden.
Bereits heute sind sehr s c h n e ! l e b i p o l a r e 4 - B i t - E l e m e n t e
angek~ndigt:
Ihr Einsatz w i r d zum Bau yon P r o z e s s o r e n f~hren, w e l c h e
hinsichtlich
ihrer L e i s t u n g den h e u t i g e n M i n i r e c h n e r n
nachstehen, schlieBt.
in k e i n e r W e i s e
so dab sich h i e r der Kreis zwischen Mini- und M i k r o r e c h n e r
166
W~hrend der Begriff "Mikroprozessor"
f~r die vorstehend aufgef£1hrten
Prozessoren seine Ursache in der Kleinheit der Baugruppe hatte, verdanken mikroprogrammierte
Prozessoren
(Spalte 6) ihren Namen der Tat-
sache, dab die Befehle in Elementarbestandteile, schritte,
die Mikroprogramm-
zerlegt werden° Mikroprogrammierte Prozessoren verf~gen ~ber
eine groBe Zahl elementarer Befehle, welche in sehr kurzer Zeit ausgefdhrt werden k~nnen. Auch hier gilt, dab mehrere Mikroprogrammschritte ben~tigt werden, um dieselbe Wirkung zu erzielen wie ein Minirechnerbefehl. Mikroprogrammierte Prozessoren werden heute auf der Basis von bipolaren MSI-Bausteinen aufgebaut; Prozessor-Elemente
die oben erw~hnten bipolaren
k~nnen hier ebenfalls Anwendung finden.
Zum AbschluB sei noch eine Variante des Mikroprozessors, type-Computer
(Spalte 7), erw~hnt,
der Mikro-
der technologisch sowohl auf dem
Mikroprozessor als auch auf dem mikroprogrammierten Prozessor aufgebaut werden kann. FUr den Anwender unterscheidet er sich vom Minicomputer nur dadurch,
daS die Ausftthrungszeit um den Faktor 2 bis 4 h~her
liegt und dab der Preis entsprechend reduziert ist. Daraus ergibt sich eine FOlle von Anwendungsm~glichkeiten,
bei welchen niedere Kosten ent-
scheidend sind, w~Lhrend an die Verarbeitungsgeschwindigkeit
nicht so
hohe Anforderungen gestellt werden. Mikroprozessoren kOnnen als selbstMndige Kleinst-ProzeBrechner setzt werden, wobei sich viele neue Anwendungsbereiche
ergeben.
kOnnen auch in Verbindung mit klassischen ProzeBrechenanlagen f~itige Aufgaben wahrnehmen.
eingeSie
viel-
Einige dieser Anwendungsm~glichkeiten
werden in den beiden folgenden Abschnitten untersucht. Abschnitt 4 ist schlieBlich den Tendenzen gewidmet, welche sich aus dem Mikroprozessoreinsatz
f~r zuk~nftige ProzeBrechenanlagen
ergeben°
2. Anwendun~en als Kleinst-PrgzeBreChne [ Viele Anwendungen,
etwa Datenerfassungs-
oder Steuerungsaufgaben,
lassen den Einsatz eines klassischen ProzeBrechners
aus Kostengr~nden
nicht zu. In diesen F~llen behilft man sich heute mit spezieller Hardware. Hier bietet sich der Einsatz von Mikroprozessoren an, wobei das Mikroprozessor-Programm
fest gespeichert sein kann, so dab sich das
System nach auBen verh~it wie zuvor die Hardware. Zur Datenerfassung werden heute oft verh~itnism~Big wenig flexible Datalogger eingesetzt, welche die Datenerfassung nur nach einem starren Schema durchf~hren k~nnen.
Dieselbe Aufgabe kann von einem Mikro-
167 prozessor-System Hbernommen werden, wobei die freie Programmierbarkeit eine wesentlich beitung)
flexiblere Datenmanipulation
gew~hrleistet.
(z.B. auch Datenvorverar-
Auch fur Steuerungsaufgaben
Steuerung von Werkzeugmaschinen
- insbesondere zur
- k~nnen Mikroprozessoren eingesetzt
werden. Die g~nstigen Kosten der Mikroprozessoren erm6glichen den Einsatz eines eigenen Prozessors bei jeder Werkzeugmaschine.
E s mHssen
also nicht aus KostengrHnden an einen ProzeSrechner mehrere Maschinen angeschlossen werden, was zu einer erheblichen Komplizierung der Programmstruktur sowie zu einer zuverl~ssigkeitseinschr~nkung
f~hrt. Ge-
gen~ber den klassischen Steuerungssystemen bietet der Einsatz des Mikroprozessors
insbesondere dann Vorteile, wenn man am Werkst~ck oder
Werkzeug Messungen vornehmen kann und die Steuerung in Abh~ngigkeit vonder
Messung beeinfluBt.
In diesem Fall arbeitet der Mikroprozessor
in einem Closed-Loop-System.
Ein weiteres typisches Beispiel liefert die Laborger~te-Automatisierung. Viele Laborger~te machen eine gewisse Verarbeitung der erfaBten MeBwerte erforderlich.
Gelegentlich werden bereits heute f~r derarti-
ge Aufgaben kleinere ProzeBrechenanlagen
eingesetzt, was oftmals dazu
f~hrt, dab das Laborger~t selbst wesentlich billiger ist als die nachgeschaltete Verarbeitungsanlage.
Mikroprozessoren bieten aufgrund
ihrer gUnstigen Kostenstruktur die M~glichkeit, ger~te mit einer Verarbeitungsanlage bar, dab die Laborger~te-Hersteller
auch kleinere Labor-
auszustatten.
Es ist sogar denk-
selbst den Verarbeitungsteil
stan-
dardm~Big mit anbieten.
Erfolgversprechend
ist auch die Automatisierung von PrOfger~ten mit
Hilfe von Mikroprozessoren.
FHr diese Aufgabenstellung werden heute
h~ufig wissenschaftliche Tischrechner eingesetzt, welche jedoch nicht ~ber ein geeignetes einfaches Interface zur Ankoppelung der ProzeBPeripherie verfUgen. Meist beschr~nkt man sich auch auf die Erfassung und nachfolgende statistische Verarbeitung von MeBwerten. Yon einem Mikroprozessor k~nnen jedoch auch Steuerungsfunktionen wahrgenommen werden, welche zus~tzlich von den gewonnenen MeBergebnissen abh~ngen k6nnen
(Closed-Loop-Betrieb).
SchlieBlich ergeben sich vielf~itige Einsatzm6glichkeiten der "Consumer Elektronik".
im Bereich
In den USA haben Mikroprozessoren bereits
in erheblichem Umfang Eingang gefunden in die Spielautomatenindustrie; Mikroprozessor-gesteuerte schirm geh6ren bereits
Verfolgungsjagden auf dem Farbfernsehbild-
zum Alltag, und selbst GetrMnkeautomaten werden
i68
bereits mit "Computer" ausgestattet. Bei genGgend niedrigen Systemkosten erSffnet sich den Mikroprozessoren ein riesiger Markt in der Haushaltsger~tetechnik elektronik
(Programmsteuerungen),
(z.B. Antiblockiersysteme,
der Spielwarenindustrie.
in der Kraftfahrzeug-
Einspritzsteuerungen)
sowie in
Obwohl dafGr das ganze Rechnersystem nur etwa
hundert bis fGnfhundert DM kosten darf, muB es doch alle fGr den ProzeBrechner typischen Eigenschaften aufweisen, da es sich hier um echte ProzeBrechneranwendungen handelt. 3. Anwendungen in Verbindung mit ProzeBrechnern In modernen ProzeBrechenanlagen, welche auf der Basis von klassischen ProzeBrechnern aufgebaut sind, gibt es fGr Mikroprozessoren zahlreiche Einsatzm~glichkeiten.
In Bild 2 ist angedeutet, an welchen Punkten ei-
ner ausgedehnten ProzeBrechenanlage Mikroprozessoren Anwendung finden k6nnen, wenn man das klassische Schema der sternf~rmigen Verkabelung aller ProzeBgr~Ben zum Zentralrechner hin verl~Bt.
ProzeBrechner
Konzentrator
IKonzentrator
m
ProzeB' Terminall
.......
I
ProzeBI Terminal
~ r~,~, I PrOzeBIPr°z'eBTerminal I I .......... ITerminal
I
I
Bild 2: Einsatz yon Mikroprozessoren in ProzeBrechenanlagen
Zun~chst k6nnen Mikroprozessoren als Ein-/Ausgabe-Prozessoren direkt am ProzeBrechner eingesetzt werden. Sie Gbernehmen dort die Funktion eines komplexen Kanalwerks und sind in der Lage, zus~tzliche Datenvorverarbeitungsaufgaben wahrzunehmen.
Sie kSnnen beispielsweise mit der
Leitungssteuerung zu untergeordneten Konzentratoren oder Terminals beauftragt werden, so dab der ProzeBrechner nur mehr zu den in einem definierten Kernspeicherbereich stehenden Daten Zugriff nehmen muS. Mikroprozessoren kSnnen in einem solchen dezentralisierten ProzeBPeripheriesystem als Konzentratoren dienen. Sie Gbernehmen dabei die Aufgabe der Leitungskonzentration und steuern die entsprechenden Da-
169 ten0bertragungsoperationen.
Sie k 6 n n e n m i t P u f f e r n a u s g e s t a t t e t sein,
so dab e v e n t u e l l a u f t r e t e n d e W a r t e s c h l a n g e n p r o b l e m e g e l ~ s t w e r d e n k6nnen;
sind gr~Bere P u f f e r vorhanden,
so k S n n e n die K o n z e n t r a t o r e n
s ~ t z l i c h zur D a t e n s i c h e r u n g for den Fall b e n u t z t werden,
zu-
dab der zen-
trale P r o z e B r e c h n e r v o r H b e r g e h e n d nicht a r b e i t s f ~ h i g ist. Eine interessante V a r i a n t e e r g ~ b t sich aus der M6glichkeit, h e r s t e l l e r s p e z i f i s c h e Terminals kleine Systeme, b e i s p i e l s w e i s e
zu simulieren.
mit dem K o n z e n t r a t o r
So k 6 n n e n auch sehr
f~r die B e t r i e b s d a t e n e r f a s s u n g ,
direkt
m i t e i n e m G r o B r e c h n e r g e k o p p e l t werden, w o b e i durch die T e r m i n a l - S i m u lation s i c h e r g e s t e l l t ist, dab der K o n z e n t r a t o r als E i n - / A u s g a b e - E i n heit vonder
Software des G r o B r e c h n e r s u n t e r s t H t z t wird°
S c h l i e B l i c h dienen M i k r o p r o z e s s o r e n in P r o z e B - T e r m i n a l s dazu, vor Ort die A n k o p p l u n g an den P r o z e B vorzunehmen.
Ein typisches A n w e n d u n g s b e i -
spiel ist etwa der E i n s a t z von P r o z e B - T e r m i n a l s
im k l i n i s c h - c h e m i s c h e n
Labor. J e d e m L a b o r g e r ~ t ist ein P r o z e B - T e r m i n a l
zugeordnet, w e l c h e s
die D a t e n e r f a s s u n g ,
die V o r v e r a r b e i t u n g ,
iokale S t e u e r u n g s f u n k t i o n e n
sowie die A u f b e r e i t u n g der an [ibergeordnete Stationen gehenden Nachrichten ~bernimmt.
Heute v e r f ~ g b a r e P r o z e B - T e r m i n a l s
sind m e i s t f e s t v e r d r a h t e t e
Spezialeinheiten;
f~r diese A u f g a b e
fHr jeden der vielen La-
b o r g e r ~ t e t y p e n muB ein eigenes spezielles P r o z e B - T e r m i n a l v o r h a n d e n sein. Der E i n s a t z von M i k r o p r o z e s s o r e n g e s t a t t e t die K o n s t r u k t i o n eines e i n h e i t l i c h e n P r o z e B - T e r m i n a l s , w e l c h e s einerseits mit e i n e m kleinen H a r d w a r e - A d a p t e r ,
andererseits durch ein g e r ~ t e - s p e z i f i s c h e s Ter-
m i n a l - P r o g r a m m an das j e w e i l i g e L a b o r g e r ~ t a n g e p a B t wird. Die sich daraus e r g e b e n d e n V o r t e i l e w i e Flexibilit~t,
Modifizierbarkeit,
Aus-
t a u s c h b a r k e i t der Ger~te liegen auf der Hand.
ProzeB-Terminals
k~nnen im A u f g a b e n b e r e i c h
und F e r t i g u n g s s t e u e r u n g einerseits b e n e r Information,
andererseits
I n f o r m a t i o n e n e i n g e s e t z t werden. a r b e i t u n g eingesetzt, w o b e i minal ausgefHhrt,
der B e t r i e b s d a t e n e r f a s s u n g
zur A u f n a h m e von m a n u e l l eingege-
zur direkten E r f a s s u n g von M a s c h i n e n Sie w e r d e n
zur lokalen A l a r m v o r v e r -
z e i t k r i t i s c h e R e a k t i o n e n direkt vom Ter-
u n w i c h t i g e A l a r m e u n t e r d r ~ e k t und nur w i c h t i g e Alar-
me an d b e r g e o r d n e t e S t a t i o n e n w e i t e r g e g e b e n werden. A n a l o g - S i g n a l e k 6 n n e n so ~ b e r w a e h t werden,
dab das T e r m i n a l s e l b s t A l a r m e erzeugt,
wenn vorgegebene Grenzwerte ~erschritten
Der Einsatz Yon M i k r o p r o z e s s o r e n
werden.
in d e z e n t r a l i s i e r t e n P r o z e B r e c h e n a n -
lagen b i e t e t viele Vorteile, w e l c h e im folgenden kurz d i s k u t i e r t werden sollen. Da P r o z e B - T e r m i n a l s eine geringe A n z a h l von A l a r m e n bedienen mHssen, e r g i b t sich eine raschere R e a k t i o n auf ProzeB-Alarme.
170 F~r den ProzeBrechner bedeutet dies, dab seine Reaktionsf~higkeit auf Alarme nicht mehr ganz so ausgepr~gt sein muB wie dies heute der Fall ist; daraus ergeben sich wesentliche Vereinfachungen fur das Betriebssystem. Nat~rlich wird der ProzeBrechner auch dadurch entlastet, eine Reihe von Vorverarbeit~ngsfunktionen
dab
bereits im ProzeB-Terminal
oder in den Konzentratoren durchgef[ihrt wird. Der ProzeBrechner kann statt dessen entweder andere,
z.B. Optimierungsaufgaben wahrnehmen,
oder es kann eine kleinere, preiswertere Anlage verwendet werden. dem sind durch die Vorverarbeitung
Zu-
im ProzeBterminal die Anforderun-
gen an die Geschwindigkeit von Ubertragungsleitungen wesentlich geringer.
Aufgrund ihrer freien Programmierbarkeit
verfUgen ProzeB-Terminals
Konzentratoren ~ber eine gewisse Autonomie;
das bedeutet,
und
dab sie die
ihnen zugeteilten Aufgaben zum groBen Teil auch dann noch ausfOhren k6nnen, wenn die dbergeordneten Systeme nicht arbeitsf~hig sind. Daraus ergibt sich eine erh~hte Zuverl~ssigkeit des Gesamtsystems:
Selbst
wenn der zentrale ProzeBrechner oder ein Konzentrator ausf~llt, k~nnen yon den ProzeB-Terminals
noch Teilfunktionen wahrgenommen werden
(z.B. Aufrechterhaltung des gerade bestehenden ProzeB-Zustands).
Die
~bertragungssicherung der von einem Teilsystem zum anderen ~bertragenen Daten kann infolge der Intelligenz der Teilsysteme an die jeweils bestehenden Umgebungsverh~Itnisse
angepaBt werden.
Da die jeweils mit einem Mikroprozessor ausgestatteten Teilsysteme eine gewisse Autonomie haben, vereinfacht sich die Inbetriebnahme des Gesamtsystems.
Teilsysteme k~nnen unabh~ngig voneinander in Betrieb
genommen werden,
und ihr Output kann zur Inbetriebnahme des Zentral-
rechners relativ einfach simuliert werden. Ein entscheidender Vorteil des dezentralisierten re Verkabelungsaufwand
Systems ist schlieBlich der wesentlich geringe(Verkabelungskosten k~nnen bei heutigen Syste-
men die Gr6Benordnung der ProzeBrechnerkosten
erreichen).
Da alle Teilsysteme aus den selben Baugruppen bestehen,
vereinfacht
sich die Ersatzteilhaltung sowie die Wartung des Gesamtsystems erheblich. Die Flexibilit~t der frei programmierbaren Mikroprozessoren erlaubt die Anpassung an ge~nderte ProzeBbedingungen oder an Erweiterungen des zu steuernden Prozesses. Vorteil,
SchlieBlich bietet das System den
dab es eine Rechner-unabh~ngige
Schnittstelle bietet. Dieser
Gesichtspunkt ist insbesondere fdr System-H~user von Bedeutung, welche f~r verschiedene Anwendungen verschiedene ProzeBrechner verwenden m~chten.
171
4. Entw:Lcklungstendenzenlf~rdie ProzeBrechentechnik Betrachtet man Bild 2) und h~It sich vor Augen, dab jeder Block durch einen eigenen Prozessor repr~sentiert ist, so erkennt man, dab diese Struktur ein Rechnernetzwerk wiedergibt. Man kann diesen Gedanken weiter ausbauen und gelangt so zu einer Struktur, wie sie im Bild 3) wiedergegeben ist. Die einzelnen Teilsysteme (Prozessoren) sind hier nicht mehr 0her eine einfache Verbindung, sondern tiber mehrfache Datenleitungen miteinander verkoppelt. Es gibt also mehrere redundante Wege, ~ e r welche eine Nachricht von einem ProzeB-Terminal zumProzeBrechner, zu einem anderen Konzentrator oder zu einem anderen Terminal ~bertragen werden kann. Es liegt nun nahe, auf diese Struktur ~hnliche Prinzipien anzuwenden, wie sie bei groBen Rechnernetzwerken entwickelt wurden. Dazu geh~ren Methoden der laufenden Leitungs%iberwachung, des automatischen "Routing" (also des Aussuchens eines geeigneten Weges) sowie die uberlegung, ob fur ProzeBrechneranwendungen Packet-SwitchingVerfahren geeignet sind. Diese Verfahren haben den Nachteil einer relativ langen Laufzeit vonder Datenquelle zum Empf~nger, bei ihrem
I---
--
I
I
i
I ProzeBrechne r
I
l I , i. . . . .
I I I ~
. . . .
) P r e s a g e
r
Massen- I speiche~
I Massen- I speiche~ Ko z :or.........~... n !itrat°r
Proze8-
~ Bild 3: Mikroprozessor-Netz
K°nzentra~/ir
nals
172
Einsatz muB also sichergestellt sein, dab die zul~ssigen Reaktionszeiten durch eine hin- und zur0cklaufende Nachricht nicht Hberschritten werden. Die DatenHbertragung
zwischen den einzelnen Netzwerkknoten selbst er-
folgt ~ber gesicherte digitale Schnittstellen, chrone Ubertragungsverfahren
wobei am besten syn-
eingesetzt werden. K6nnen sich Rechner-
systeme der hier angedeuteten Struktur durchsetzen,
so wfirden dadurch
die heute heftig diskutierten Bus-Prinzipien ~berholt sein. Betrachtet man beispielsweise den mit dem CAMAC-Serial-Loop-System unterbreiteten Vorschlag,
so zeigt es sich, dab die Ubertragungsproze-
dur so komplex ist, dab der Einsatz eines Mikroprozessors Crate-Controller die 5konomischste LSsung darstellt. Hber Intelligenz im Crate-Controller,
im Serial-
Verf~gt man aber
so ist nicht einzusehen, warum
man sich auf die reine Ring-Struktur mit ihren Nachteilen beschr~nken soll.
Verfolgt man den Gedanken des Mikroprozessor-Netzwerks
weiter,
so
stellt sich die Frage, warum nur Datenerfassung und -vorverarbeitung dezentralisiert werden° Ebenso besteht die M6glichkeit,
die gesamte
Verarbeitung zu dezentralisieren und auf mehrere Prozessoren aufzuteilen. Dasselbe gilt f0r die Verteilung der Massenspeicher, chen die ProzeBdaten bzw. ProzeB-Modell-Daten
auf wel-
gespeichert sind. Auch
sie kSnnen statt dem zentralen ProzeBrechner den einzelnen dezentralen Prozessoren zugeordnet sein. So gelangt man schlieBlich Frage, ob ein besonders ausgezeichneter
zu der
zentraler ProzeBrechner er-
forderlich bleibt oder ob nicht alle Aufgaben verteilt werden kSnnen. Bei diesen Uberlegungen steht nat~rlich der Zuverl~ssigkeitsaspekt mit im Vordergrund.
Bisherige Strategien, welche bei hohen Zuverl~ssig-
keitsanforderungen
an ProzeBrechneranlagen
dundante Doppel- oder zwei-aus-drei-Systeme
verwendet werden,
sehen re-
vor, wobei jeder einzelne
Prozessor so ausgelegt sein muB, dab er die gesamte ProzeSaufgabe 15sen kann. Das ist genauso wenig optimal wie bei der Datendbertragung die zwei- oder dreifache Ubertragung der Nachricht. Andere Strategien werden jedoch erst dann einsetzbar, wenn eine grSBere Anzahl von Prozessor-Elementen
zur Verf~gung steht
gr~Beren Blockl~nge bei der Daten~bertragung).
(Analogie zur
Bei solchen Systemen
wird es also notwendig sein, andere Zuverl~ssigkeitsbetrachtungen
an-
~73 zustellen und System-Redundanzin anderer Weise als bei Duplex- und Triplex-Systemeneinzuplanen. 5. SchluBbetrachtun@en Im Bild 4) wird versucht, ein Mikroprozessor-Anwendungsspektrumwiederzugeben und eine Verteilungder einzelnenProzeBrechner-Aufgaben auf die verschiedenenMikroprozessortypenvorzunehmen.Mikroprogrammierbare Prozessorendienen als Prozessorkernfur konventionelleMinirechner, sie eignen sich zumAufbau von schnellenRechenwerkensowie fur schnelle Spezialanwendungen.Sie k6nnen als Basis fur den Aufbau von Mikro-type-Computernverwendetwerden, beide Mikroprozessortypen sind zum Einsatz als I/O-Prozessorenund als Kommunikationsprozessoren geeignet. Mikroprozessorenim eigentlichenSinn sind besonders gut als Herz von ProzeB-Terminalsgeeignet, sie eignen sich zur Laborger~teautomatisierungsowie fur Anwendungen im Bereich der ConsumerElektronik. In einem weiten Bereich tiberdeckensich die Anwendungsm~glichkeiten mit denen des Mikro-type-Computers.
]--Mikroprogram~~ren /
Mini~ ~ ~
/ I~~~
]
[ Mikro, Pr?zessoren Mikr°-type~ Computer
Schnelle I/OI ~
/
i ~
"- ,," ns~nal~gue~~'{~iiI I
Bild 4: AnwendungsspektrumMikroprozessoren
lnl
i74
Eine mit dem Einsatz von M i k r o p r o z e s s o r e n
z u s a m m e n h ~ n g e n d e Problema-
tik ergibt sich im w i r t s c h a f t l i c h e n Bereich: W ~ h r e n d die H a r d w a r e immer b i l l i g e r wird,
steigen die Software- und S y s t e m - E n g i n e e r i n g - K o s t e n
st~ndig an. Diese Kosten sind aber n a h e z u u n a b h ~ n g i g davon, ob ein P r o b l e m mit e i n e m k l a s s i s c h e n M i n i r e c h n e r oder mit einem M i k r o p r o z e s sor g e l 6 s t wird.
Frtther w a r es z u m i n d e s t in g e w i s s e m U m f a n g noch m6g-
lich, solche Kosten auf die Hardware abzuw~izen, heute b e s t e h t das P r o b l e m darin,
dem A n w e n d e r k l a r z u m a c h e n ,
dab solche z u s ~ t z l i c h e n Ko-
sten e n t s t e h e n und auch in R e c h n u n g g e s t e l l t w e r d e n mOssen.
Dabei zeigt
es sich, dab der Einsatz von M i k r o p r o z e s s o r e n w i r t s c h a f t l i c h nur dann w e s e n t l i c h e V o r t e i l e bringt, w e n n d a s s e l b e S y s t e m m e h r f a c h r e a l i s i e r t w e r d e n kann,
da dann die S y s t e m - E n g i n e e r i n g - K o s t e n e n t s p r e c h e n d auf-
geteilt w e r d e n k6nnen.
Zum A b s c h l u B e r s c h e i n t die F e s t s t e l l u n g wichtig,
dab P r o z e B r e c h e n a n -
lagen der h i e r a n g e d e u t e t e n Struktur schon in naher Zukunft realisierbar und auch w i r t s c h a f t l i c h e i n s e t z b a r werden.
Bereits heute sollten
sie bei der E r a r b e i t u n g von neuen Hardware- und S o f t w a r e - K o n z e p t e n , i n s b e s o n d e r e bei der F e s t l e g u n g von N o r m e n b e r O c k s i c h t i g t werden. H a r d w a r e s e i t i g gilt dies b e i s p i e l s w e i s e ProzeBperipheriesystemen,
for die S t a n d a r d i s i e r u n g von
s o f t w a r e s e i t i g sollte man bereits
dem Einsatz von m e h r e r e n v e r t e i l t e n P r o z e s s o r e n rechnen.
jetzt mit
DIE SERIELLE D A T E N U B E R T R A G U N G IM C A M A C - S Y S T E M ZUR D E Z E N T R A L E N D A T E N E R F A S S U N G UND P R O Z E S S - S T E U E R U N G
H. K L E S S M A N N
I. E i n l e i t u n q
Zur I n s t r u m e n t i e r u n g von P r o z e B r e c h e n s y s t e m e n bei der L a b o r a u t o m a t i s i e rung, bei w i s s e n s c h a f t l i c h e n E x p e r i m e n t e n und in der i n d u s t r i e l l e n MeBund P r ~ f t e c h n i k hat das in E u r o p a und USA i n t e r n a t i o n a l e i n g e f H h r t e C A M A C - S y s t e m w e i t e V e r b r e i t u n g gefunden.
Dieses a l l g e m e i n e I n s t r u m e n t i e -
r u n g s s y s t e m w i r d in g r o B e m Umfang zur D a t e n e r f a s s u n g und P r o z e B s t e u e r u n g eingesetzt,
in z u n e h m e n d e m MaBe aber auch als Interface for die Stan-
d a r d - P e r i p h e r i e g e r ~ t e von P r o z e B r e c h n e r n sowie zur K o p p l u n g von ProzeBr e c h n e r n als S a t e l l i t e n mit einer gr6Beren, anlage.
zentralen D a t e n v e r a r b e i t u n g s -
Das C A M A C - S y s t e m ist m o d u l a r und u n a b h ~ n g i g von b e s t i m m t e n Rech-
n e r t y p e n konzipiert,
so dab es Hber k o m m e r z i e l l e r h ~ i t l i c h e Interface-
S t e u e r u n g e n m i t P r o z e B r e c h n e r n der v e r s c h i e d e n s t e n Typen und H e r s t e l l e r b e t r ± e b e n w e r d e n kann.
Die S y s t e m s p e z i f i k a t i o n e n u m f a s s e n w e i t g e h e n d e
V e r e i n b a r u n g e n 0ber die e l e k t r i s c h e n und m e c h a n i s c h e n E i g e n s c h a f t e n der S y s t e m b a u s t e i n e und ihrer Nahtstellen,
so dab dem A n w e n d e r ein breites
S p e k t r u m k o m p a t i b l e r e l e k t r o n i s c h e r Ger~te der v e r s c h i e d e n s t e n Ger~tehersteller
zur V e r f ~ g u n g steht°
Der D a t e n v e r k e h r
zwischen den in einem C A M A C - R a h m e n z u s a m m e n g e f a B t e n
A n w e n d e r - M o d u l n und der R a h m e n s t e u e r u n g erfolgt ~ber einen s t a n d a r d i s i e r ten Datenbus,
den Dataway /I/. Dieser gestattet,
p a r a l l e l in b e i d e n Richtungen,
Daten bis zu 24 Bit
sowie S t e u e r b e f e h l e an die P r o z e B p e r i p h e -
rie wie auch A n f o r d e r u n g e n von e x t e r n e n G e r ~ t e n an den P r o z e B r e c h n e r zu ~bertragen.
FOr gr6Bere I n s t r u m e n t i e r u n g s a u f g a b e n
ist im C A M A C - S y s t e m
der Anschlu~i mehrerer Rahmen an einen s t a n d a r d i s i e r t e n r e c h n e r u n a b h ~ n gigen,
ebenfalls
24 Bit breiten,
b i d i r e k t i o n a l e n Datenbus m~glich.
ser, als v i e l a d r i g e s Kabel ausgef~hrte,
Die-
Branch Highway /2/ w i r d f~r Da-
t e n U b e r t r a g u n g e n mit hohen D a t e n r a t e n - bis zu etwa I Mio Worte/s - und im N a h b e r e i c h des Rechners - bis etwa 50 m - fHr den Betrieb bis zu 7 C A M A C - R a h m e n eingesetzt.
176
2. Die E i ~ e n s c h a f t e n des S e r i e l l e n U b e r t r a ~ u n g s s y s t e m s
Als w i c h t i g e E r g ~ n z u n g des CAMAC-Systems,
insbesondere fur die industri-
steht nunmehr auch ein Serielles Ubertragungssystem
ellen Anwendungen,
/3/ zur Verf0gung, welches ebenfalls in enger i n t e r n a t i o n a l e r Zusammenarbeit zwischen d e m E S O N E - K o m i t e e ~ in E u r o p a und dem AEC N I M - C o m m i t t e e e~ in USA e n t w i c k e l t wurde. Steuerinformation
Bei d i e s e m S e r i e l l e n S y s t e m w e r d e n Daten und
zwischen P r o z e B r e c h n e r und C A M A C - I n s t r u m e n t i e r u n g
ent-
weder bit - oder b y t e - s e r i e l l ~bertragen, mit b e s o n d e r e n M a B n a h m e n zur Der Serial Highway g e s t a t t e t den A n s c h l u S von maximal
Datensicherung. 62 C A M A C - R a h m e n , w e r d e n k6nnen.
die mit U b e r t r a g u n g s r a t e n bis zu 5 M Byte/s b e t r i e b e n
Der fur die N a h t s t e l l e n d e f i n i e r t e
(balanced current)
S i g n a l s t a n d a r d e r m 6 g l i c h t die direkte S i g n a l H b e r t r a g u n g Hber private L e i t u n g e n bis zu E n t f e r n u n g e n von etwa 1000 m. Zum Betrieb Hber gr~Bere E n t f e r n u n g e n oder Hber das ~ f f e n t l i c h e F e r n s p r e c h w ~ h l n e t z k~nnen in jedem A b s c h n i t t des S e r i e l l e n Highways andere U b e r t r a g u n g s e i n r i c h t u n g e n , wie Modem8 e i n g e s e t z t werden.
Der serielle H i g h w a y w i r d an den ProzeB-
rechner Hber einen S e r i e l l e n Treiber als Interface angeschlossen.
Die
N a h t s t e l l e und das Format der N a c h r i c h t e n des Seriellen Highways
sind
jedoch so spezifiziert, fachen A d a p t e r - v o n
dab das Serielle System auch - Uber einen ein-
einem S t a n d a r d - C o m m u n i c a t i o n - I n t e r f a c e mit asyn-
chroner TTY- oder C C I T T / V 2 4 - N a h t s t e l l e b e t r i e b e n w e r d e n kann, die bei allen m o d e r n e n P r o z e B r e c h n e r n v e r f H g b a r sind.
In d i e s e m Fall w e r d e n die
E r z e u g u n g und der E m p f a n g der N a c h r i c h t e n durch die Software des ProzeBrechners organisiert,
so dab kein spezieller,
auf die K a n a l s t r u k t u r
des jeweils v e r w e n d e t e n Rechners e n t w i c k e l t e r CAMAC System C o n t r o l l e r e r f o r d e r l i c h ist. Dadurch kann das serielle S y s t e m auch bei sehr einfachen I n s t r u m e n t i e r u n g s s y s t e m e n ,
mit nur einem oder w e n i g e n CAMAC-
Rahmen und im N a h b e r e i c h des Rechners, v o r t e i l h a f t e i n g e s e t z t werden.
Diese g r u n d s ~ t z l i c h e n E i g e n s c h a f t e n lassen erkennen, dab das Serielle System den p a r a l l e l e n Branch Highway h e r v o r r a g e n d erg~nzt und besonders g e e i g n e t ist fur den Einsatz
- bei g r 6 B e r e n U b e r t r a g u n g s e n t f e r n u n g e n ,
ggf. unter B e n u t z u n g des
6 f f e n t l i c h e n F e r n s p r e c h w ~ h l n e t z e s mit Hilfe von Modems, - bei g e s t ~ r t e n U b e r t r a g u n g s k a n ~ l e n ,
die eine Sicherung gegen Fehler
der D a t e n ~ b e r t r a g u n g erfordern,
•m
ESONE
E u r o p e a n Standards of N u c l e a r E l e k t r o n i c s
AEC NIM
Atomic Energy C o m m i t t e e on Nuclear Instrument Modules
"177
-
bei umfangreichen Instrumentierungssystemen,
in denen mehr als
7 CAMAC-Rahmen mit insgesamt niedriger DatenHbertragungsrate
betei-
ligt sind, - oder bei kleinen Instrumentierungssystemen,
in denen der besonders
einfache AnschluB eines oder mehrerer CAMAC-Rahmen an einen Rechner Hber international standardisierte Kommunikations-Interfaceeinrichtungen von Bedeutung ist° 3. Die Struktur des Seriellen SlTstems Die grundlegende Struktur des Seriellen Systems ist durch eine unidirektionale Ringleitung gekennzeichnet, dem Rechner verbunden sind
(Abb.
~ber die alle CAMAC-Rahmen mit
I). Diese Ringleitung bildet eine ge-
schlossene Schleife zwischen der Ausgangs- und Eingangs-Nahtstelle eines Seriellen Treibers
(genannt Serial Driver SD), der als Interface
zum Rechner dient und in einfachen F~llen ein simpler Adapter fHr beispielsweise eine Teletype-Nahtstelle des Rechners sein kann. Die Rahmensteuerungen
(genannt Serial Crate Controller SCC) sind ~ber defi-
nierte Eingangs- und Ausgangs-Nahtstellen geschleift.
in den seriellen Highway ein-
Bis zu 62 Rahmen k~nnen an jeder beliebigen Stelle der Ring-
verbindung eingesetzt werden. Anstelle der CAMAC-Rahmen k~nnen auch Nicht-CAMAC-Ger~te
an den seriellen Highway angeschlossen werden, wenn
diese Ger~te die definierte Nahtstelle sowie bestimmte minimale Bedingungen der Ubertragungsprozedur des Systems befriedigen. Alle Nachrichten
(messages) durchlaufen die Ringleitung in gleicher Rich-
tung. Jede Rahmensteuerung Oberwacht die an seinem Eingang ankommenden Nachrichten und ist f~r alle nicht an sie adressierte Nachrichten transparent. Auf diese Weise wird ein vom Seriellen Treiber SC ausgesandter "Befehl"
(command message) von allen dazwischenliegenden Rahmensteue-
rungen bis zum Eingang der adressierten Rahmensteuerung SCC weitergegeben.
GleichermaBen wird auch die von einer adressierten Rahmensteue-
rung ausgesandte
"Antwort"
genden Rahmensteuerungen ter~bertrageno
(reply message) von allen stromabw~rts lie-
bis zum Eingang des Seriellen Treibers SD wei-
Jede Rahmensteuerung kann auch "Interruptanforderungen"
(demand messages) aussenden, die in gleicher Weise an den Eingang des Seriellen Treibers ~bertragen werden. Offensichtlich wOrde eine Unterbrechung des seriellen Highways auch den Zusammenbruch des gesamten Systems zur Folge haben. Durch zus~tzliche Einrichtungen k~nnen daher individuelle Rahmensteuerungen ~berbr~ckt
178
oder auch gr~Bere Teile des Highways umgangen werden
(By-Pass bzw. Loop-
Collapse, Abb. 2). Dadurch bleibt das System auch funktionsf~hig, wenn einzelne Rahmensteuerungen wegen Ausfall der Netzversorgung oder aus Wartungsgr~nden aus dem Verkehr gezogen oder andere Teile des Highways wegen St~rung oder Unterbrechnung abgeschaltet werden m~ssen. Diese Umschalteinrichtungen k6nnen vom Rechner durch Befehle ~ber den seriellen Highway gesteuert werden. 4. Die Daten~bertragung Alle Nachrichten sind aus mehreren, aufgebaut.
aufeinanderfolgenden
8 Bit-Bytes
Die Nahtstelle der Rahmensteuerungen und des Seriellen Trei-
bers ist daher so definiert,
dab eine byte-serielle oder auch bit-seri-
elle Ubertragung der Nachrichten m~glich ist
(Abb. 3):
- F~r die byte-serielle Ubertragung enth~lt die Nahtstelle acht DatenLeitungen und eine Bytetakt-Leitung,
so da6 w~hrend jeder Bytetakt-
Periode ein Byte ~ber die acht Daten-Leitungen ~bertragen wird. Bei der bit-seriellen Ubertragung werden nur eine Daten-Leitung und eine Bittakt-Leitung genutzt.
In diesem Fall wird jedes Byte in einem
Rahmen yon 10 oder 11 Bit Obertragen,
d.h. einem Startbit,
tionsbit und einem oder zwei Stopbit.
Dabei wird der in jeder Rahmen-
steuerung erforderliche
8 Informa-
interne Byte-Takt von dem gerahmten Byte und
dem Bittakt abgeleitet. An der definierten Nahtstelle werden die Daten als non-return-to-zeroSignale mit einem ~ber eine getrennte Leitung gef~hrten Taktsignal ~bertragen.
Sowohl die Daten als auch der Takt sind als symmetrische
Signale spezifiziert,
so dab unter Verwendung kommerziell verfUgbarer
Leitungstreiber und -empf~nger bei mittleren Entfernungen von mehreren hundert Metern die Rahmensteuerungen direkt ~ber private Leitungen mit verdrillten Aderpaaren verbunden werden k6nnen. Der Systemtakt wird zentral im Seriellen Treiber SD erzeugt und durch die Verarbeitungsgeschwindigkeit Ubertragungsgeschwindigkeit
der Rahmensteuerungen
der Verbindungen bestimmt.
sowie durch die Die maximale
Bit- oder Byterate ist auf 5 MHz festgelegt, die von einer im Anhang der Systemspezifikation
ausfOhrlich und beispielhaft beschriebenen
Rahmensteuerung SCC Typ L I verarbeitet werden kann. Das serielle CAMACSystem l~Bt jedoch auch den Einsatz von Rahmensteuerungen mit geringerer
179
maximaler DatenGbertragungsrate
zu.
In jedem A b s c h n i t t des s e r i e l l e n Highways, ten Nahtstellen,
d.h.
zwischen zwei d e f i n i e r -
k6nnen auch andere, vom Benutzer a u s g e w ~ h l t e Ubertra-
g u n g s e i n r i c h t u n g e n e i n g e s e t z t werden, um seine b e s o n d e r e n A n f o r d e r u n g e n an die Entfernung,
die S i c h e r u n g der D a t e n G b e r t r a g u n g oder die B e n u t z u n g
des 8 f f e n t l i c h e n F e r n s p r e c h n e t z e s
zu erfGllen.
Dieser nicht s p e z i f i z i e r -
te Teil des s e r i e l l e n H i g h w a y s muB fur die U b e r t r a g u n g der N a c h r i c h t e n t r a n s p a r e n t sein und k a n n u.U. die U b e r t r a g u n g s r a t e des G e s a m t s y s t e m s , d.h. den S y s t e m t a k t bestimmen,
jedoch sind die M o d u l a t i o n der Daten-
und T a k t i n f o r m a t i o n sowie die S i g n a l p e g e l nicht definiert.
5. Das Format der N a c h r i c h t e n
In dem S e r i e l l e n S y s t e m treten 3 v e r s c h i e d e n e A r t e n von N a c h r i c h t e n auf,
(command message), die Antw o r t (reply message) sowie die U n t e r b r e c h u n g s a n f o r d e r u n g (demand message). Alle diese N a c h r i c h t e n sind aus 8 Bit-Bytes aufgebaut, mit jeweils die in Abb.
4 d a r g e s t e l l t sind: Der Befehl
6 Informationsbit,
einem D e l i m i t e r b i t
sowie einem P a r i t ~ t s b i t
zur N a c h r i c h t e n s y n c h r o n i s i e r u n g
(mit u n g e r a d e r Parit~t)
zur Fehlererkennung.
(SUM-Byte), mit einer (CHECKSUM) Gber die I n f o r m a t i o n s b i t in den v o r a n g e -
Jede N a c h r i c h t enth~it am Ende ein S u m m e n - B y t e modulo-2-PrHfsumme
g a n g e n e n Bytes der Nachricht.
Die K o m b i n a t i o n von t r a n s v e r s a l e r Pari-
t~t in jedem Byte und l o n g i t u d i n a l e r Parit~t Gber alle Bytes einer Nachricht ist eine A b w a n d l u n g des b e k a n n t e n g e o m e t r i s c h e n F e h l e r e r k e n n u n g s Codes und ist sowohl einfach r e a l i s i e r b a r als auch ~uBerst leistungsf~hig zur E r k e n n u n g e i n z e l n e r oder in Gruppen a u f t r e t e n d e r Fehler.
Eine B e f e h l s n a c h r i c h t
(command message) w i r d vom S e r i e l l e n Treiber SD
erzeugt und zu der R a h m e n s t e u e r u n g SCC dbertragen, die durch das erste Byte a d r e s s i e r t isto Die N a c h r i c h t enth~it somit -
die Z i e l a d r e s s e SC eines C A M A C - R a h m e n s ,
- die S u b a d r e s s e SA, den F u n k t i o n s c o d e SF und die S t a t i o n s n u m m e r SN zur A d r e s s i e r u n g eines Modules und eines Registers in d e m a d r e s s i e r ten C A M A C - R a h m e n sowie zur K e n n z e i c h n u n g der a u s z u f ~ h r e n d e n O p e r a t i o n - sowie 24 Bit D a t e n im Falle einer Schreiboperation.
Auf den Befehl folgen m i n d e s t e n s sind, um die A n t w o r t
soviel S P A C E - B y t e s wie e r f o r d e r l i c h
(reply message) v o n d e r
rung e i n f ~ g e n zu k~nnen.
adressierten Rahmensteue-
Diese Folge wird durch ein E N D - B y t e abgeschlos-
~80 sen, bei dem das Delimiterbit auf logisch I gesetzt ist.
Bei allen Bytes, einschlieBlich den SPACE- und END-Bytes enth~It die Bitposition 8 ein ungerades Parit~tsbit.
Die SPACE-Bytes d0rfen jeden
beliebigen Code haben, vorzugsweise jedoch logisch "I" auf allen Bit (mit Ausnahme des das Ende einer Nachricht kennzeichnenden Delimiterbits).
Durch dieses bevorzugte Bitpattern wird erreicht, dab SPACE-
Bytes von einer Rahmensteuerung,
die beispielsweise auBer Synchronismus
geraten ist, nicht als Rahmen-Adresse miBverstanden werden k6nnen, da die h~chste Rahmen-Adresse oktal 77 in dem System nicht zugelassen ist. Eine Antwortnachricht
(reply message) wird yon einer adressierten Rah-
mensteuerung SCC als Erwiderung auf einen empfangenen Befehl erzeugt und zurHck zum Seriellen Treiber SD Hbertragen. -
-
-
die Herkunftsadresse
Die Antwort enth~it
SC des CAMAC-Rahmens,
Statusinformation der Rahmensteuerung
(ERR, SX, SQ und Delayed ERR)
24 Bit Daten im Falle einer Leseoperation
- sowie ein SUM-Byte zur longitudinalen Parit~tspr~fung.
Zugleich ist
in diesem Byte das Delimiterbit auf logisch "I" gesetzt, um das Ende der Antwortnachricht
zu kennzeichnen,
so dab dieses Byte als ENDSUM-
Byte bezeichnet wird. Diese Antwort wird yon der Rahmensteuerung anstelle der SPACE-Bytes ausgesandt, die vom Seriellen Treiber fur das EinfHgen der Antwort in den Byte-Strom in h~nreichender Anzahl bereitgestellt werden. Als dritte Nachrichtenart tritt schlieSlich die Unterbrechnun~s-Anforderun~
(demand message) auf, die von einer Rahmensteuerung SCC erzeugt
und zum Seriellen Treiber SD Hbertragen wird, um anzuzeigen, diesem Rahmen von einem Ger~t eine LAM-Anforderung
dab in
(Look-at-Me)
auf Be-
dienung durch den Rechner gestellt wurde. Diese Anforderungsnachricht enth~It -
die Herkunftsadresse
SC des CAMAC-Rahmens,
- eine 5 Bit-Graded L-Information,
die beispielsweise direkt die Quelle
der in einem Rahmen gestellten Anforderung identifiziert, - sowie ein ENDSUM-Byte zur longitudinalen Parit~tspr~fung und zugleich (durch das Delimiterbit)
zur Kennzeichnung,
daS die Anforderungs-
Nachricht beendet ist. Die verschiedenen Nachrichten-Arten kSnnen durch eine 2 B i t - N a c h r i c h tenidentifikation
im zweiten Byte einer jeden Nachricht unterschieden
181
werden.
Tats~chlich ist diese Identifikation nur f~r den Seriellen Trei-
ber beim Empfang der verschiedenen Nachrichten von Bedeutung. der Nachrichten h~ngt v o n d e r (ob Lese-, Abb.
jeweils auszufOhrenden CAMAC-Operation ab
Schreib- oder Steueroperation)
4 dargestellt.
Die L~nge
und ist in einer Tabelle in
Daraus ergibt sich, dab eine Befehls-Antwort-Sequenz
(command-reply) bei einer Lese- oder Schreiboperation insgesamt 12 Bytes und bei einer Steueroperation nur 8 Bytes erfordert. forderungsnachricht
Dagegen hat die An-
eine feste L~nge von 3 Bytes.
6. Der Ablauf einer Befehls- und Antwort-Nachricht
(command-reply-message sequence) ist in Abb. 5 fur eine Leseoperation dargestellt. Das Schema
Der Ablauf einer Befehls- und Antwort-Nachricht
zeigt insbesondere auch den byte-getriebenen Ablauf in dem System: Der Serielle Treiber SD erzeugt eine Folge von Bytes. Dieser Bytestrom wird von jeder Rahmensteuerung SCC weitergegeben und durchl~uft den seriellen Highway synchron mit dem Byte-Takt.
FUr jedes am Eingang einer
Rahmensteuerung eintreffende Byte wird am Ausgang der Rahmensteuerung ein entsprechendes Byte generiert. Rahmensteuerungen unterdr0cken.
Das heist mit anderen Worten:
k~nnen an ihrem Ausgang Bytes weder hinzufHgen noch
Und alle vom Seriellen Treiber ausgesandten Bytes bewir-
ken den Transport der auf dem Seriellen Highway befindlichen Nachrichten. In einem bit-seriellen System erkennt eine Rahmensteuerung erst am Ende des ersten Bytes eines Befehls, daS dieser Befehl an sie adressiert ist. Die Rahmensteuerung gibt daher das erste Byte eines Befehls unver~ndert als Befehlskopf
(command header) an seinen Ausgang weiter, w~hrend die
folgenden Bytes des Befehles durch END- bzw. WAIT-Bytes substituiert werden.
Sowohl END- ais auch WAIT-Bytes geh~ren zur Klasse der Delimi-
ter-Bytes,
die den stromabw~rts liegenden Rahmensteuerungen das Ende
einer Nachricht bzw. den Ruhezustand des Systems mitteilen. miter-Bytes haben das gleiche Bitmuster,
Beide Deli-
ihre unterschiedliche Bezeich-
nung soll nur ihre verschiedene Funktion hervorheben. Nach vollst~ndigem Empfang und Fehlerpr~fung des Befehls wird yon der Rahmensteuerung die entsprechende CAMAC-Operation, Zyklus ausgefHhrt.
d.h. ein Datenweg-
Danach erzeugt die Rahmensteuerung eine Antwort-
nachricht, mit Rahmen-Adresse,
Statusinformation und Lesedaten.
jedoch durch die Fehlerpr~fung ein Ubertragungsfehler de, f~hrt die Rahmensteuerung keine Datenweg-Operation erzeugt eine Fehler-Antwortnachricht,
Falls
festgestellt wuraus, sondern
bei der das Fehlerbit ERR im
182 Statusbyte gesetzt ist. Das letzte Byte der Antwort-Nachricht
ist das ENDSUM-BYTE, welches
die longitudinale Pr~fsumme enth~It und durch das Delimiterbit allen stromabw~rts
liegenden Rahmensteuerungen
sowie dem Seriellen Treiber
das Ende der Antwort anzeigt. Auch der Serielle Treiber sender - am Ende einer genOgenden Anzahl von SPACE-Bytes - ein END-Byte, welches durch das Delimiterbit allen, auch den stromaufw~rts
liegenden Rahmensteuerungen anzeigt, dab die Befehls-
Antwort-Sequenz vollst~ndig abgeschlossen ist. Dieses END-Byte f~llt mit dem ENDSUM-Byte der Antwort-Nachricht
zusammen, wenn die Anzahl
der vom Seriellen Treiber ausgesandten SPACE-Bytes genau der erwarteten Antwort-L~nge entspricht.
Es darf jedoch auch zu einer sp~teren
Byte-Zeit ausgesendet werden, woraus sich eine sehr einfache Prozedur ergibt: Der Serielle Treiber sendet solange SPACE-Bytes,
bis er die
vollst~ndige Antwort empfangen hat, und sendet erst dann ein END-Byte, um auch den stromaufw~rts fehls-Antwort-Sequenz
liegenden Rahmensteuerungen das Ende der Be-
anzuzeigen.
7. Die Nachrichten......... und Byte-S[nchronisierun@ Zwischen den Nachrichten sender der Serielle Treiber st~ndig WAIT-Bytes ~ber die Ringleitung.
WAIT-Bytes geh6ren - wie END- und ENDSUM-Bytes -
zur Klasse der Delimiter-Bytes,
die sich durch das Delimiterbit auf
Bitposition 7 eindeutig yon allen anderen Bytes unterscheiden. Alle Delimiter-Bytes dienen der Nachrichten-Synchronisierung, auf ein Delimiter-Byte
folgende Nondelimiter-Byte
als erstes
da jedes (Adress)-
Byte einer Nachricht interpretiert wird. WAIT-Bytes kennzeichnen weiterhin den Ruhezustand des Seriellen Highways und dienen dazu, die auf dem Highway befindlichen Nachrichten (insbesondere die in den Pausen zw±schen den Nachrichten abgesetzten Anforderungs-Nachrichten)
tiber die Ringleitung weiterzutreiben.
Bei der
bit-seriellen Ubertragung dient das ausgezeichnete Bitpattern der WAITBytes auch zur Byte-Synchronisierung
der Rahmensteuerungen.
Da WAIT-
Bytes st~ndig zwischen den Nachrichten gesendet werden, wird die ByteSynchronisierung
sehr h~ufig gepr~ft oder wiederhergestellt.
183
8. Die Ubertragun~ von Anforderun~en
Anforderungs-Nachrichten
(demand messages) werden von einer Rahmensteue-
rung zum Seriellen Treiber Hbertragen,
um anzuzeigen, dab von einem Ge-
r~t in diesem Rahmen eine LAM-Anforderung auf Bedienung durch den Rechner gestellt wurde. Diese Anforderungen k~nnen zu jeder beliebigen Zeit und in jedem beliebigen Rahmen auftreten.
Es muB daher sichergestellt
werden, dab durch das Aussenden der Anforderungs-Nachricht
eine andere,
gerade auf dem Highway umlaufende Nachricht nicht gest~rt wird. Sicherlich darf die 3 Byte lange Anforderung v o n d e r
Rahmensteuerung
nur zwischen zwei Nachrichten in den Byte-Strom auf dem Seriellen Highway eingef~gt werden, d.h. - nach einem Delimiter-Byte -
in dem Zeitabschnitt am Ende einer Nachricht
und vor dem Empfang des ersten
(Adress-)
Bytes einer Nachricht bzw.
eines Befehlskopfes.
Diese Regel wird dadurch erfOllt, d a b in einer Rahmensteuerung die Anforderung nach Passieren eines Delimiter-Bytes
im Bytestrom freigegeben
und durch einen Befehlskopf oder Nondelimiter-Byte
gesperrt wird.
Um auch wdhrend des Aussendens der 3 Byte langen Anforderungs-Nachricht eine Kollision mit gerade ankommenden Bytes einer Nachricht zu verhindern, schaltet die Rahmensteuerung
einen 3 Byte-Umwegspeicher
in den
Seriellen Highway ein. Durch das EinfHgen dieser Verz6gerung wird der Ruhezustand
auf dem Seriellen Highway zeitlich verl~ngert,
ungHnstigsten Fall die Anforderungs-Nachricht
so dab auch im
vollst~ndig ausgesendet
werden kann. Dieser Umwegspeicher kann zu einem sp~teren Zeitpunkt wieder entfernt werden, n~mlich dann, wenn der Umwegspeicher nur WAIT-Bytes enth~it und das zuletzt aus dem Speicher Hbertragene Byte ein Delimiter-Byte war. Dadurch wird effektiv der Ruhezustand des Seriellen Highways um ebensoviel Bytes verkHrzt, wie er zuvor veri~ngert worden ist.
(beim Einschalten des Umwegspeichers)
184
LITERATUR
/I/ CAMAC - A M o d u l a r I n s t r u m e n t a t i o n System Revised D e s c r i p t i o n and S p e c i f i c a t i o n -
-
E U R A T O M Report EUR 41OOe
(1972)
AEC N I M Report TID 25875
(1972)
/2/ CAMAC - O r g a n i s a t i o n of M u l t i c r a t e Systems S p e c i f i c a t i o n of the Branch Highway and Crate C o n t r o l l e r Type A -
-
E U R A T O M Report EUR 46OOe
(1972)
AEC NIM Report TID 25876
(1972)
/3/ CAMAC - Serial S y s t e m O r g a n i s a t i o n A Description -
-
ESONE
Report ES
I
AEC NIM Report TID 26488
/4/ Barnes,
R.C.M.,
(Dec.
1973)
(Dec.
1973)
The CAMAC Serial Highway
CAMAC Bulletin, No.
8, Nov.
1973, p. 5 - 6
/5/ Machen, D.R., The CAMAC Serial Systems D e s c r i p t i o n For Long Line, M u l t i c r a t e A p p l i c a t i o n s IEEE Trans.
on Nucl.
Science, NS - 21, No.
I, Febr.
1974
185
I
I croto 21sc;
--
I
OUT
T
IN
Icr° '621s]c
SCC Serial Crate Controller (Rahmensteuerung)
(Maximum)
1
lout ,N
I
Serial DriverSDII
SDrial
Driver
(Port Adapter ~(Serieller Treiber)
COMPUTER Abb.
1 : STRUKTUR
DES
SERIELLEN
Ic~te 2 l~oI~ ' ~,r" ] _
|l i
oo
,IC'°~e~,I=u
Abb.
I
oo IOutput T°,
/ ExternalBypassControl ' ~--/ Exterr~:ll J ~"-~"Loop~-- C_i~--[lapselControl
"-/
,
.IJDi
COMPUTER
-"i
CAMAC-SYSTEMS
,
I
I Input
ISedalDriverSD
'/
~'~
~.~
\1
ICrate 3
/J! I
I"
"x....-~',---~.-C-~ IcroteZ, Isccll
Di
2: B Y - P A S S und L O O P - C O L L A P S E - E I N R I C H T U N G E N BEIM S E R I E L L E N C A M A C - S Y S T E M
l~
CRATE CLUSTER
186
SD or SCC
IOUTPUT
~------Or~From, ~
1
ISTART
OA,A
INPUT I SD or SCC STOpI
'o'1
I
" I'1'
{11~2 I 34
DATA I
5 6 7 8 910111
BIT CLOCK
BIT CLOCK 1
I
I
t
I
--,,-I
I
Port
~
~
1
BitPedod
I
I
i
I
Port
BIT- SERIAL
DATA1
I/e
I
" •
I •
~
~
,~
I
I ,'4
I BYTE CLOCK
DATA1
I
I
l
I
.
I
I
•
[
I
~
Port
BYTE CLOCK
-~
Port
~,~--OneByte Period
BYTE-SERIAL Abb.
3: D A T E N U B E R T R A G U N G
[JBER DIE D E F I N I E R T E
REPLY
DE MAND
(From SCC to SD|
(From SCC to SO)
COMMAND (From SD to SCC} 1
8
8
8
1
P1 0
SC(6}
P= 010 I1 Hsolsxl ,;
2
P2 0 1
SGL(5)
PI 1 ENDSUM-Byte
SC(6)
1
m 0! ....
2
P2O ooJsA
3
P3 0 R
SF {5)
P3 0 Msg
SR(6)~
3
L.
P4 0 R
SN (5)
P4 0
SR(6) 3
3
5
P5 0 MSB
SW(6)~
P5 0
SR { 6 ) 2
6
P6 0
SW(6} 3
P6 0
SR(6)1LSB
7
P7 0
SW(6) 2
PZ t
8
P8 0
SW{6)ILS, s
9
P;E 0
l
Pi,P~E; transv, parity (odd) SUN, ENDSUM:tongffud. pority (Mod - 2 sum )
ENDSUM-Byte Delimiter Bit
SUM-Byte Function ....
PSO 0
Abb.
S76
READ 1
1
1
1
IP l , 1 i t
Error Detection :
3or7 L
| [ - - Delimiter Bit
5or9
I1 I I
1
1
P1 0
sc(6)
NAHTSTELLE
1
o
1
1
0
0
L
Delimiter Bit
0
1
CONTROL WRITE
0
4: DAS FORMAT
DER N A C H R I C H T E N
01/1
SF8
Commond
Repfy
Total
0
5
?
12
1
5
3
8
t
9
3
12
187
Abb.
5: A B L A U F E I N E R B E F E H L S - / A N T W O R T - N A C H R I C H T BEI E I N E R L E S E O P E R A T I O N
" EIN C A M A C - U N T E R S T U T Z T E S DATENERFASSUNG
P.M. C z a i k o w s k i ' ~
I.
P E R I P H E R I E - S U B S Y S T E M ZUR M E S S -
"
D. Reimer'',
H.J.
Schulz"
Einleitung
U n t e r den G e s i c h t s p u n k t e n der F l e x i b i l i t ~ t und der M o d u l a r i t ~ t w u r d e auf der Basis y o n C A M A C ein h i e r a r chisch strukturiertes MeBdatenerfassungssystem siert,
reali-
das f o l g e n d e n s p e z i e ! l e n R a n d b e d i n g u n g e n genH-
gen sollte: mSglichst
-
einfache Programmierung
des z e n t r a l e n
ProzeBrechners - g e r i n g e B e l a s t u n g des B e t r i e b s s y s t e m e s zentralen Prozessors
und des
(wenig I n t e r r u p t s ~
nut B l o c k -
transfer Hber autonome Kanalwerke) -
Teilautonomie
des S u b s y s t e m e s
- d e z e n t r a l e r ~ u m l i c h e S t r u k t u r mit g r ~ B e r e n E n t f e r n u n g e n z w i s c h e n den e i n z e l n e n S i g n a l q u e l l e n und der Z e n t r a ! e - h o h e A u s f a l l - und 0 b e r t r a g u n g s s i c h e r h e i t D a t e n w e g e n yon der P e r i p h e r i e Das b e s c h r i e b e n e
S y s t e m w u r d e in g e m e i n s a m e r
lung y o n A E G - T e l e f u n k e n und D o r n i e r auf der B a s i s des D i g i t a l r e c h n e r s Prozessors
DO 2 0 0 - 2 9 5 4 r e a l i s i e r t .
"
AEG-Telefunken
"*
Dornier Systems
auf den
zur Z e n t r a l e .
Systems
Entwickzun~chst
TR86 und des C A M A C -
189
2.
Hardware-Struktur
2.1
0bersicht Das periphere D a t e n e r f a s s u n g s s y s t e m aus einem zentralen Master Crate, rieller 0 b e r t r a g u n g s s t r e c k e n
(Fig. I) besteht
an das mittels
se-
sternf~rmig bis zu 14
dezentra!e Crates angeschlossen werden kSnnen. Die Steuerstation des zentralen Crates wird von dem CAMACProzessor DO 200-2954 belegt; 0bertragungsstrecken
Sender und Empf~nger
als normale CAMAC-Einschubmoduln nen des zentralen Crates. Obertragungsstrecke
der
zu den d e z e n t r a l e n Crates belegen (EAS) weitere Statio-
Sender und Empf~nger
zum Ubergeordneten
TR86 werden Hber eine ebenfalls fdhrte Interface-Karte
(ARC)
der
ProzeBrechner
als CAMAC-Modul
ausge-
an den Datenweg des Master
Crates angeschlossen. Die A n s t e u e r u n g
aller Kabelsender-
von dem Datenprozessor
und empf~nger
erfolgt
aus Hber den normalen CAMAC-Da-
tenweg ohne jede Zusatzverdrahtung~
d.h. alle entwickel-
ten Moduln entsprechen im vollen Umfang der Spezifikation EUR 4100.
2.2
KoDplun q zwischen zentralem ProzeSrechner und peripherem DatenerfassunqssMs%e ~ Die serielle U b e r t r a g u n g s s t r e c k e Master Crate
zwischen TR86 und CAMAC-
(MSE) - eine Standard-Komponente
des TR86-
Systems - wird an das autonome Multiplexkanaiwerk TR86 angesch!ossen.
des
Die 0 ~ e r t r a g u n g s s t r e c k e MSE besitzt
Hardware-Einrichtungen fehler und ermSglicht
zum Schutz gegen U b e r t r a g u n g s im Halbduplex-Betrieb
raten his zu 20 Kiloworten pro Sekunde.
0bertragungs-
Die maximale
Entfernung kann 1000 m betragen. Bei direktem AnschluB
des Interface-Moduls
ARC an das
190
Multiplexkanalwerk
2.3
des TR86 sind Ubertragungsraten
his zu &00 Kiloworten
pro Sekunde m~glich.
Ubertraqunq innerhalb
des Datenerfassunqssystemes
Die von einem EAS-Modul gungsstrecke
zu einem dezentralen
den in dem dezentralen Modul
ausgehende
serielle UbertraCrate wird Hber
Crate Aufnahme
findenden CAS-
an die Branch Highway-Schnittstelle
dardisierten
des stan-
Crate Controllers
CCA angeschlossen.
Diese LSsung wurde in Hinblick
auf eine mSglichst
weitgehende
Verwendung
handelsUblicher
CAMAC-Kompo-
nenten gew~hlt. Die ~bertragungsrate nach Entfernung kunde.
2.4
zwischen
Die maximale
sicherung
liegt bei Halbduplexbetrieb 20 und 50 Kiloworten
Entfernung
erfolgt durch Bi!dung
D atenverkehr
Die Adressierung im Master Crate. Crate Controllers prozessor
Crates
eines dezentralen
Im CAS-Modul
Crates
Der zur Ansteuerung dienende NAF-Befehl
wird vom Daten-
des Master Crate
eine Speicherung
so dab er in dem Betriebsmodus ohne erneute Ubertragung
EAS-Moduls
des dezentralen
und yon dort zum CAS-Modul erfolgt
erfolgt
N des entsprechenden
Hber die Write-Leitungen
zum EAS-Modul
pro Se-
200 m. Fehler-
eines Parity-Bits.
mit den dezentralen
~ber die Stationsnummer
gelangen
betr~g%
je
Hbertragen.
dieses Befehls~
"Befehlswlederholung"
beliebig
oft zur AusfHhrung
kann.
Der CAS-Modul Controller
reagiert
anstehenden
auf jede Anderung GL-Pattern
Read-GL-Operation
und Hbertr~gt
an den EAS-ModuI~
der seinerseits
Crate erzeugt. im EAS-Modul
tenweg-Operation
lesen.
mit einer
das neue GL-Pattern
Der Datenprozessor
anstehende
des im Crate
automatisch ein L-Signal
im Master
kann daraufhin
neue GL-Pattern
das
mit einer Da-
igi
In E A S - M o d u l fHgung, -
steht ferner ein S t a t u s r e g i s t e r
das f o l g e n d e
Informationen
zur V e r -
liefert:
Ende einer U b e r t r a g u n g
- Parityfehler - Q im d e z e n t r a l e n
Crate
fehlt
- X im d e z e n t r a l e n
Crate
fehlt.
A u c h dieses R e g i s t e r
kann von dem D a t e n p r o z e s s o r
einer D a t e n w e g - O p e r a t i o n 2.5
Funk t i o n s q r u p p e n
mit
g e l e s e n werden.
des D a t e n p r o z e s s o r s
und des z e n t r a l e n
Crates Der D a t e n p r o z e s s o r sowie
selbst e n t h ~ l t m a x i m a l
ein F u n k t i o n s w e r k
und logischer
zum D u r c h f H h r e n
VerknHpfungen.
den C A M A C - T i m i n g der S p e z i f i k a t i o n einem normalen
Der D a t e n p r o z e s s o r
sowie alle C A M A C - S i g n a l e EUR 4600,
64 R e g i s t e r
arithmetischer
entspricht
Crate Controller.
erzeugt
entsprechend
insofern
Zur M a r k i e r u n g
also be-
stimmter
Betriebszust~nde
ist ein F l a g - R e g i s t e r
gesehen.
Flag I wird z.B.
dutch das ODER der G L - S i g -
nale g e s e t z t
und e r m ~ g l i c h t
Der zum D a t e n p r o z e s s o r gemischter ausgebaut Crates
Bestdckung werden.
damit die A l a r m a b f r a g e .
geh~rige
Speichermodul
Der RAM kann v o m D a t e n w e g
des M a s t e r
Die v e r b l e i b e n d e n
Stationen
fur eine F u n k t i o n s t a s t a t u r
des M a s t e r C r a t e s w e r d e n
des D a t e n p r o z e s s o r s ,
Clock/Timer
dem I n t e r f a c e
zum L a d e n des RAM sowie bis
belegt.
4K
werden.
von dem I n t e r f a c e steuerung
kann in
mit PROM und RAM his maximal
aus g e l e s e n w e r d e n oder b e s c h r i e b e n
Lochstreifenleser
vor-
zur AnfHr einen zu 3
192
3.
Software-Struktur
3.1
~bersicht Das auf dem Datenprozessor PROCAM
(Fig. 2) dbernimmt
realisierte Programmsystem die Aufgaben der zyklischen
Abfrage von digitalen und analogen Eing~ngen,
der Zwi-
schenpufferung yon MeSdaten und der priorit~tengesteuerten Abhandlung von Hardware-Alarmen.
AuBerdem werden
der Verkehr mit der an CAMAC angeschlossenen Bedienperlpherie
sowie die Ubertragungsprozedur
len ProzeSrechner 3.2
zum zentra-
abgewickelt.
Systemker D Die in Fig.
2 gekennzeichneten Moduln
WAIT~ ALARM, VERT, CONTROL, den Kern des Systems PROCAMo nur fur den in Fig.
(INIT, URLAD 9
PUVEWA)
bilden
Dieser Systemkern ist
! gekennzeichneten Hardware-Rumpf
des Datenerfassungssystemes h~ngig sowohl v o n d e r konfiguration
DECRA,
spezifisch,
jedoch unab-
jeweils angeschlossenen Ger~te-
als auch yon dem ~bergeordneten
ProzeS-
rechner. Die den Systemkern bildenden Moduln haben folgende wesentliche Funktionen: - Urladen und Initialisieren - U n t e r s u c h e n der GL-Pattern
sowohl des zentralen
als auch der dezentralen Crates - A n m e ! d e n der dutch Hardware-A!arme Software-Befehle
(CONTROL)
initialisierten Pro-
gramme bei dem Regieverteiler - Pufferverwaltung ~bertragung
(ALARM) oder
(VERT)
und Initialisierung
der Daten-
zum zentralen ProzeBrechner.
193
Die wesentlichen systemes tellers
Echtzeiteigenschaften
des Betriebs-
werden durch die Organisation gegeben,
vorgegebenen
der die angemeldeten
Priorit~ten
Unterbrechbarkeit
entsprechend
der einzelnen
des RegieverProgramme starter.
programmiert
Die
Softwaremoduln
durd~ Abfrage von Flag ~ den Anforderungen
den kann
gem~B
werden.
Die Moduln ALARC,
INARC,
rechnerspezifische sie beinhalten
OUTARC
Erweiterung
(Fig.
2) stellen die
des Systemkerns
die zum Verkehr
dar;
mit dem TR86 notwen-
digen Treiber und Prozedurabwickler. Wesentliche
Teile dieses
erweiterten
Systemkerns
sind
auf PROM gespeichert. 3.3
Anwendunqsspezifische Der erste Einsatz systemes
erfolgt
datenerfassung wachung.
Erweiterunqen
des beschriebenen im Bereich
speziell
Signale
(Abtastfrequenzen frequenzen
Dementsprechend
eingeteilt
repr~sentieren
die "iangsamen"
der Pufferverwaltung Die Programme
transfer
(Abtast-
werden.
die Moduln MESSIN-I
Ger~teprogramme,
I his n einlesen und
SIGIN-I bis SIGIN-m erm~glichen Signale.
MeBwerte
werden
zum zentralen
weise Entleerung
di-
sofort in einem Block~bertragen.
Da
damit fHr die Dauer einer
belegt
Start einer schnellen
die
Die eingelesenen
ProzeBrechner
die ()bertragungsstrecke schnellen Abtastung
die
Hbergeben.
"schneller"
gitalisierten
"langsam"
unter 50 Hz) und'~chne!l"
Daten yon den Eingabemoduln
Erfassung
kSnnen die zu
in die zwei Kategorien
his zu I kHz)
his MESSIN-~
MeB-
zum Zweck der Intensiv~ber-
Im Rahmen dieser Anwendung
erfassenden
Datenerfassungs-
der medizinischen
ist,
erfolgt vor dem
Signalabtastung
eine zwangs-
des im RAM vorgesehenen
Puffers.
194
Diese MaBnahme parallel
ist n o t w e n d g, da der Datenprozessor
zu einer laufenden
same" Signale einlesen
schnellen Abtastung
kann,
"lang-
deren Werte im Puffer
abgelegt werden. Zur Triggerung
der Signalabtastung
Crate bis zu 3 Wecker vorgesehen.
sind im Master Uber CONTROL
die Eintragun g der auf einem Weckerimpuls den Programme TROL
(TIMCO)
Programme Weitere der
in einer Liste veranlaBt
; das Programm TIME CON-
die Anmeldung
der zu startenden
beim Regieverteiler.
anwendungsspezifische
Ansteuerung
tur (INTAST)
dem Uber den Datenweg
yon Information
Speichers
da nicht alle Programme resident
als
a ~ ladbaren RAM gespeichert.
eines peripheren
Datenprozessors
werden in
sowohl vom Lochstreifenleser
kann die Programm-Kapazit~t
erh~ht werden,
auf
(SIGOUT). Softwaremoduln
auch vom zentralen Rechner Durch Benutzung
dienen
yon CONTROL Hber eine Funktionstasta-
Die anwendungsspezifischen
!en Rechners
Programm-Moduln
sowie der Ausgabe
einem Speicheroszillographen
3.4
erfolgt
zu starten-
des zentra-
des Subsystemes im Speicher
des
sein m~ssen.
Benutzer-Schnittstelle Die Adressierung und Modul-Nummer. Crate
aller Programme
Im Regieverteiler
steht fHr das Master
sowie fHr jedes angeschlossene
je ein 24-Bit-Register meldung
zur Verf~gung,
eines Programmes
den Bits erfolgt. Hardware-Alarm
dezentrale
durch Setzen des entsprechen-
in Form eines GL-Signales
erfolgen.
Crate
in dem die An-
Das Setzen eines Bits kann durch einen
oder durch einen Software-Befehl TIMCO)
erfolgt Hber Crate-
(ALARM,
(CONTROL,
DECRA)
indirekt
195
Durch A u s n u t z e n der von nicht aktiven C A M A C - M o d u l n (z.B. Speichermodul
) belegten Stationen kSnnen vir-
tuelle Moduln eingefHhrt werden,
indem die betreffen-
den M o d u l n u m m e r n bestimmten Software-Moduln net werden.
Durch zus~tzliches
zugeord-
EinfHhren virtueller
Crates kann der AdreBvorrat beliebig erweitert werden. Das Programm CONTROL kann sowohl Hber eine manuelle Eingabe als auch von dem Hbergeordneten Rechner
an-
gesteuert werden.Zum Start eines bestimmten Programmes N~ssen dem System lediglich die Nummern C, N (Crate-Nr.,
Modul-Nr.)
und gegebenenfalls
ein fHr
das zu startende Programm spezifischer Versorgungsblock: mitgeteilt werden. Treiber und Prozedurabwickler ner sind in Assembler Anwender
im zentralen ProzeBrech-
programmiert,
als FORTRAN-SubrQutine
kSnnen jedoch vom
mit CALL CAMAC
(C,N,A)
aufgerufen werden. A ist ein mit Dimension vereinbartes Feld fester L~nge,
in das der Anwender vor dem
Aufruf die V e r s o r g u n g s i n f o r m a t i o n
fHr das mit C,N auf-
gerufene Programm des Datenprozessors (z.B. Abtastfrequenz,
eintragen muB
Anzahl der Zyklen,
Verst~rkungs-
faktor).
4.
Vorteile des Systemes
Das beschriebene entwickelt,
System wurde unter dem Gesichtspunkt
die bekannten Vorteile von CAMAC wie
- modulare Systemstruktur - Transformationseigenschaften
bez~glich der Hard-
ware-Schnittstellen - Standardisierung unter den besonderen,
eingangs beschriebenen
Randbe-
196
dingungen nutzbar zu machen.
Die zu diesem Zweck ent-
wickelten C A M A C - M o d u l n entsprechen im vol!en Umfang den CAMAC-Spezifikationen. Durch Implementierung Prozessors
eines programmierbaren CAMAC-
in das periphere D a t e n e r f a s s u n g s s y s t e m
konn-
ten drei wesentliche Ziele erreicht werden: -
Autonomle
-
Entlastung
des Subsystemes des zentralen Rechners
- einfache Benutzerschnittstelle. Die sich hieraus
ergebenden Einsparungen
chenzeit als auch an Programmieraufwand B e t r i e b s k o s t e n des Gesamtsystemes
sowohl an Revermindern die
und mHssen in Zusam-
menhang mit den bekannten Vorteilen yon CAMAC gesehen werden° FUr den zentralen Rechner
stellt sich das auf der Basis
yon CAMAC entwickelte D a t e n e r f a s s u n g s - S u b s y s t e m autonomes ProzeBkanalwerk befehle
a!s ein
dar,das durch einfache Makro-
angesprochen werden kann.
Das zun~chst im Bereich der m e d i z i n i s c h e n MeBdatenerfassung eingesetzte
System ist grunds~tzlich
auch fHr zahl-
reiche andere A n w e n d u n g e n der automatisierten MeBdatenerfassung geeignet.
197
Zusammenfassung
Es wird ein C A M A C - S y s t e m v o r g e s t e l l t 9 das a!s Subsystem eines Hbergeordneten ProzeBrechners Datenerfassung bei dezentraler
fHr die
r~umlicher Anordnung
der Signalqueilen konzipiert wurde.
Zu diesem Zweck
kSnnen his zu %4 Crates Hber serielle Ubertragungsstrecken sternf~rmig an ein Master Crate angeschlossen werden. U m den zentralen Rechner und dem Benutzer
eine einfache Schnittstelle
fHgung zu stellen, CAMAC-Systemes eingesetzt.
zu entlasten zur Ver-
wurde zur autonomen Steuerung des
ein programmierbarer
Datenprozessor
198
lTRy6'
ZentraterRechner mit Multiplexkanalwerk und rechnerseitigerMSE
T
bis 1000 m
20 Kiloworte/s InterfaceKonsole InterfaceLSL EAS-Moduln /~chermodul
I MSE I
/
/
Datenprozessor
ClockTimer
M°dilis200m 20 - 50 Kiloworte/s
|
-
-
D
Bedienkonsole
DezentraleCrates ~
Lochstreifenleser
CAS-Moduln CrateControllerCCA
Fig. 1 : Hardware-Strukturdesauf CAMACbasierendenDatenerfassungssystems. Die umrahmtenKomponentenentsprechendem Hardware-Rumpfdes Systems.
199 I INIT,,H URLAD I ALARM
Systemkern
I CONTROL i
DECRA
VERT
i
T, T 'NARC 11=I I
WAIT
ALARC I
PUVEWA
INTAST !
________•! .I MES.SIN1
MESSINn
SIGIN1 i
7 s'~'~n I J
"i
T~MCO!
-,"S,GOOTI Fig. 2:
Struktur desProgrammsystemsPROCAM.Der umrahmteTeil repr~isentiert den Systemkernsowiedie rechnerspezifischenErweiterungenALARC, INARC und OUTARC.
DAS P L A S M A DISPLAY - EIN DIGITALES GRAFISCHES SICHTGERAT J. ZAHN, P. ABEND,
Z. K O M O R
FGr den d i r e k t e n Dialog zwischen dem M e n s c h e n und einer P r o z e S r e c h e n anlage w e r d e n heute in g r o B e m Umfang g r a f i s c h e S i c h t g e r ~ t e eingesetzt. AIs A n z e i g e e i n h e i t e n wurden dabei bisher immer E l e k t r o n e n s t r a h l r ~ h r e n verwendet,
in den letzten Jahren h~ufig auch F a r b b i l d r 6 h r e n oder R~h-
ren mit Speicherbildschirm. In der T e c h n i k der e l e k t r o n i s c h e n D a t e n v e r a r b e i t u n g erfolgt die logische V e r a r b e i t u n g der R o h i n f o r m a t i o n auf d i g i t a l e m Wege und auch die E r g e b n i s s e liegen in d i g i t a l e r Form vor, wobei zur a n s c h a u l i c h e n grafischen D a r s t e l l u n g h~ufig groBe I n f o r m a t i o n s m e n g e n a u s g e g e b e n werden. A n z e i g e e i n h e i t e n mit E l e k t r o n e n s t r a h l r ~ h r e n sind fur diese Zwecke oft nur mit E i n s c h r ~ n k u n g e n brauchbar.
Ihre N a c h t e i l e sind in erste Linie
die b e g r e n z t e B i l d s c h i r m g r ~ B e
-
- die e r f o r d e r l i c h e D i g i t a l / A n a l o g - W a n d l u n g der Information - die b e g r e n z t e D a r s t e l l u n g s k a p a z i t ~ t bei S i c h t g e r ~ t e n mit zyklischer Bildwiederholung bei S p e i c h e r b i l d r 6 h r e n das Fehlen der selektiven L ~ s c h u n g
-
-
der hohe e l e k t r o n i s c h e A u f w a n d
- die im A n a l o g s y s t e m b e g r H n d e t e n F e h l e r m 6 g l i c h k e i t e n Die w i c h t i g s t e n A n f o r d e r u n g e n an g r a f i s c h e A n z e i g e e i n h e i t e n sind: - hohe L e u c h t d i c h t e bei m ~ g l i c h s t h o h e m W a n d l e r w i r k u n g s g r a d (in Lumen/Watt) -
-
-
groBer K o n t r a s t hohe A u f l ~ s u n g
(RastermaB < 0 , 3 mm)
groSfl~chige Bildschirme
(Raster I K x I K Punkte)
- hohe S c h r e i b g e s c h w i n d i g k e i t
(kurze Adressierzeit)
- inh~renter Speicher mit selektiver L6schung) -
einfache A d r e s s i e r e l e k t r o n i k
- D i a l o g v e r k e h r Hber den B i l d s c h i r m -
geringe Kosten
In den letzten J a h r e n wurden eine Reihe von n e u a r t i g e n d i g i t a l e n Anz e i g e e i n h e i t e n entwickelt°
T e c h n i s c h am w e i t e s t e n f o r t g e s c h r i t t e n sind
die G a s e n t l a d u n g s - A n z e i g e e i n h e i t e n
(Plasma-Sichtger~te).
P l a s m a - A n z e i g e n sind M a t r i x a n o r d n u n g e n aus einer V i e l z a h l von kleinen Dipl.-Ing.
J. Zahn und Dipl.-Ing.
P. Abend sind M i t a r b e i t e r am Hahn-
M e i t n e r - I n s t i t u t fHr K e r n f o r s c h u n g Berlin GmbH, Dipl.-Ing. Inst.
f. Kernforschung,
Swierk
(Polen),
Z. Komor,
ist zur Zeit Gast am HMI-Berlin.
201
G a s e n t l a d u n g s s t r e c k e n in flachen Geh~usen.
D u r c h g e e i g n e t e Wahl der
g e o m e t r i s c h e n A b m e s s u n g e n der Zelle, der B e t r i e b s w e r t e und der Gaszus a m m e n s e t z u n g bildet sich in einer solchen G a s e n t l a d u n g s s t r e c k e im wesentlichen die p o s i t i v e S~ule, das
"Plasma", aus, das sich d u r c h eine
hohe L e u c h t d i c h t e auszeichnet. Man u n t e r s c h e i d e t bei P l a s m a - A n z e i g e n zwischen dem G l e i c h s t r o m - ( D C - ) V e r f a h r e n mit V o r i o n i s a t i o n und d i s k r e ten Z e l l b o h r u n g e n /I/ und dem H o c h f r e q u e n z - ( A C - ) V e r f a h r e n ,
das auf Ar-
b e i t e n yon B I T Z E R und S L O T T O W basiert /3,4/. Als V e r t r e t e r des ersten Typs ist seit e i n i g e n J a h r e n das S e l f - S c a n - P l a s m a - P a n e l der Fa. B u r r o u g h s fur a l p h a n u m e r i s c h e A n z e i g e n auf d e m Markt /2/. Als Beispiel fHr das AC-Verfahren
soll im f o l g e n d e n das P l a s m a - S i c h t g e r ~ t MDXVI der Firma
O w e n s - I l l i n o i s v o r g e s t e l l t werden /5/: Hier wird die offene B a u w e i s e angewendet.
Der A n z e i g e s c h i r m b e s t e h t
aus zwei etwa 6 mm starken p l a n p a r a l l e l e n Glasplatten, die in ~quid i s t a n t e m Abstand d H n n e G o l d e l e k t r o d e n tragen
(Abb.1). Das A C - V e r f a h -
ren g e s t a t t e t eine Isolation der E l e k t r o d e n v o m Gas, w o m i t R e a k t i o n e n z w i s c h e n beiden v e r m i e d e n w e r d e n k~nnen. Daher sind die E l e k t r o d e n mit einer d ~ n n e n d i e l e k t r i s c h e n G l a s s c h i c h t ~berzogen.
Die G l a s p l a t t e n
w e r d e n mit den i n n e n l i e g e n d e n E l e k t r o d e n im A b s t a n d von etwa 0,2 m m angeordnet, wobei die E l e k t r o d e n orthogonal o r i e n t i e r t sind. Dieses Sandwich wird mit Neon und e i n e m g e r i n g e n Zusatz an Xenon g e f H l l t und versch!ossen. Das P l a s m a - S i c h t g e r ~ t Eine e i n z e l n e
stellt eine M a t r i x von k l e i n e n K o n d e n s a t o r e n dar.
Zelle wird 0ber die d a z u g e h ~ r i g e n A d r e B e l e k t r o d e n ange-
w~hlt und gezi~ndet. Der g e z H n d e t e Zustand bleibt a u c h nach W e g n a h m e des Z ~ n d i m p u l s e s b e s t e h e n
bis die Zelle g e l 6 s c h t wird.
Diese S p e i c h e r u n g wird d u t c h eine W e c h s e l s p a n n u n g erzielt, die ]parallel an allen E l e k t r o d e n anliegt, aber u n t e r h a l b der Z H n d s p a n n u n g liegt
(Sustaining Voltage) in ihrer A m p l i t u d e
(Abb.3). B e i m A d r e s s i e r e n eines
P u n k t e s w i r d den A d r e B l e i t u n g e n je eine S p a n n u n g U A zugefHhrt, die a d r e s s i e r t e
so dab
Zelle m o m e n t a n eine g e s a m t e Spannung von U S + 2-U A er-
h~it, die die G a s e n t l a d u n g zHndet. Die bei der G a s e n t l a d u n g e r z e u g t e n Ionen und E l e k t r o n e n w e r d e n infolge des e l e k t r i s c h e n Feldes auf der O b e r f l ~ c h e der d i e l e k t r i s c h e n S c h i c h t e n a u f g e s a m m e l t ,
bis das r e s u l t i e -
r e n d e Feld n a h e z u Null g e w o r d e n ist, w o m i t die G a s e n t l a d u n g nach etwa 1~s erlischt.
W e c h s e l t U s seine Polarit~t,
te Ladung eine V o r s p a n n u n g ,
so bewirkt die g e s p e i c h e r -
die Wandspannung,
eine erneute G a s e n t l a d u n g hervorruft. jeder Periode v o n U S zweimal,
die U S u n t e r s t ~ t z t und
Dieser Wechsel v o l l z i e h t sich in
so dab eine einmal g e z U n d e t e Zelle bei
einer F r e q u e n z yon 50 kHz als k o n t i n u i e r l i c h g l i m m e n d erscheint.
202
Eine gez~ndete Zelle wird gel~scht,
indem durch erneutes Adressieren
im richtigen Zeitpunkt die auf dem Dielektrikum angesammelte Ladung zu Null gemacht wird. Das Problem, die statistische Komponente der Ionisationsverz~gerung zu eliminieren,
d.h. eine beliebige Einzelzelle w~hrend eines einma-
ligen Adressierens
sicher zu z~nden, wurde gel6st,
mehrere Reihen st~ndig gezHndeter
indem man am Rand
Zellen angeordnet hat. Diese bewir-
ken bei mittleren Display-Gr6Ben eine genHgende Vorionisation. Vor einigen Jahren wurde am HMI - Berlin ein grafisches Sichtger~t mit der Speicherbildeinheit
Tektronix 611 f~r den Einsatz an ProzeBrechen-
anlagen entwickelt und an mehreren unterschiedlichen ProzeBrechnern erfolgreich eingesetzt /7/. Die Speieherr6hre bietet gegenHber Anzeigeeinheiten mit Bildwiederholung den Vorteil einer v611ig flackerfreien Darstellung auch sehr groBer Informationsmengen. holungsspeicher,
Es entf~llt sowohl ein separater Bildwieder-
noch muB ein Teil des Arbeitsspeichers
wiederholung bereitgestellt werden.
f~r die Bild-
In Verbindung mit einer beliebig
langsamen Ubertragungsrate entlastet dies den Rechner. Einen Vergleich
zwischen dem Plasma-Sichtger~t und dem Speicher-Sicht-
ger~t Tektronix 611 zeigt die Tabelle
(Abb. 2).
Als Nachteile der Speicherr6hre gegenHber Sichtger~ten mit Bildwiederholung sind zu nennen: - Markieren oder Zeichnen mittels Lichtgriffel ist nicht m~glich -
-
keine Intensit~tssteuerung
der Bildpunkte
keine Realzeitdarstellung.
Gerade diese Betriebsarten werden aber beim Einsatz an ProzeSrechenanlagen in groSem Umfang genutzt. Daher wurden von uns brauchbare technische L6sungen gefunden, um diese Nachteile zu umgehen. Anstelle eines Lichtgriffels kann eine Rollkugel benutzt werden. Man verschiebt damit ein Fadenkreuz,
das nichtspeichernd geschrieben wird
und dessen Mittelpunktskoordinaten Die Intensit~tsmodulation
zum Rechner Obertragen werden kSnnen.
(z.B. bei MAP-Darstellungen)
wurde durch ei-
ne Variation der Punktgr6Be mittels eines Spiralgenerators ersetzt. Die Realzeitdarstellung
wurde je nach Anwendungsfall
ne SchnappschuBdarstellung
ersetzt durch ei-
(Neuschreiben des Bildes in zeitlichen Ab-
st~nden yon mehreren Sekunden)
oder durch zyklisches Uberschreiben des
Bildes an bestimmten Stellen bei h~ufiger ~nderung der Information (z.B. bei MeBwerten). Beim Plasma-Sichtger~t
liegen die Probleme ~hnlich.
Die Realzeitdar-
stellung ist voll realisierbar durch die M~glichkeit,
Einzelpunkte
203
selektiv zu l~schen und durch die kurzen L~schzeiten von nur 20 us je Punkt bzw. fur das ganze Bild. Die zu ~ndernde Darstellung wird ge16scht und durch die neue Information ersetzt, der Rest bleibt unver~ndert. Eine Intensit~tssteuerung
ist bei dem hier beschriebenen Plasma-Sicht-
ger~t ebenfalls nicht m6glich,
auch ein analoger Spiralgenerator nicht.
An dem Problem der Erzeugung von Halbt6nen wird bei den Herstellern gearbeitet /8/. Die L~sung gestaltet sich beim AC-Verfahren jedoch wesentlich schwieriger als beim nichtspeichernden DC-Verfahren.
Als Er-
satz bietet sich hier fur die MAP-Darstellung ein Punktmustergenerator an, der entsprechend den Punkten mit unterschiedlichen Durchmessern Anordnungen von Punkten vorsieht, die sich in Zahl und Geometrie von einander unterscheiden. Die M6glichkeit des Lichtgriffeleinsatzes
beim AC-Verfahren ist prin-
zipiell gel6st /9/, jedoch bei dem vorliegenden Typ noch nicht realisiert. W~hrend der interaktiven Phase
(Abb.3~) l~Bt sich durch geziel-
tes Adressieren der Zustand einer Zelle fragen,
(gezOndet oder gel6scht)
ab-
zum anderen aber auch durch zeilen- und spaltenweises Abta-
sten aller Zellen mit einem ZOnd/L~sch-Zyklus das kurzzeitige
ZOnden
einer mit dem Lichtgriffel markierten Zelle detektieren. Prinzipiell l~Bt sich auch beim Plasma-Sichtger~t
eine Marke auf dem
Bildschirm erzeugen, die mittels einer Rollkugel verschoben werden kann. Von Nachteil ist hierbei, dab die Marke bei Positions~nderungen zun~chst gel~scht werden muB, wobei Punkte, die gleichzeitig formationsdarstellung
zur In-
geh6ren, ebenfalls gel~scht werden.
Unter Ber~cksichtigung dieser Faktoren und der Erfahrungen, der Entwicklung einer Steuerung fur das Speichersichtger~t
die bei Tektronix
611 und dem Einsatz als grafisches Sichtger~t an ProzeBrechnern gewonnen wurden,
ist fur das Plasma-Sichtger~t
entwickelt worden
eine ~hnliche Steuerung
(Abb. 4).
Diese Steuerung ist fur den Betrieb im CAMAC-System ausgelegt, aber bei Austausch des CAMAC-spezifischen mit Teletype-Schnittstelle
kann
Interfaces gegen ein so!ches
auch an einer seriellen Daten~bertragungs-
strecke betrieben werden. Die Steuerung gestattet zwei Darstellungsarten,
Vektoren und alpha-
numerische Zeichen und Symbole. Der Betriebszustand wird ~ber ein dem Datenblock vorangestelltes
Befehlswort eingestellt.
ist aus Abb.5 ersichtlich.
Es wurde f~r den parallelen und seriellen
Die Datenstruktur
Betrieb eine m~glichst ~bereinstimmende Byte-Struktur legt.
zugrunde ge-
204
Beim C A M A C - I n t e r f a c e w u r d e die W o r t l ~ n g e zu 16 Bit gew~hlt. Befehle
(Abb.6)
Die C A M A C -
steuern den V e r k e h r zwischen dem D a t e n w e g und den ein-
zelnen Registern,
sowie die A n f o r d e r u n g s b e a r b e i t u n g .
Um die A u s g a b e g e s c h w i n d i g k e i t
zu erh6hen, w e r d e n die D a t e n w o r t e in ei-
nem D a t e n p u f f e r z w i s c h e n g e s p e i c h e r t ,
so dab bereits nach Ubergabe ei-
nes W o r t e s an den e n t s p r e c h e n d e n G e n e r a t o r w ~ h r e n d der V e k t o r - oder Z e i c h e n e r z e u g u n g ein neues LAM gesetzt und das n ~ c h s t e Wort vom Rechner a b g e r u f e n w e r d e n kann. Das B e f e h l s w o r t steuert die B e t r i e b s a r t des S i c h t g e r ~ t e s ~ber die A S C I I - Z e i c h e n IS 4...IS 1. N e b e n d e n G e n e r a t o r e n zum E r z e u g e n von Zeichen und V e k t o r e n k a n n in einer w e i t e r e n B e t r i e b s a r t eine m i t einer R o l l k u g e l v e r s c h i e b b a r e n Marke d a r g e s t e l l t werden. Die P o s i t i o n der M a r k e kann m a n u e l l oder d u r c h R e c h n e r b e f e h l
zum R e c h n e r ~ b e r t r a g e n w e r -
den. F e r n e r e n t h ~ i t das B e f e h l s w o r t I n f o r m a t i o n e n Uber b e s o n d e r e Bet r i e b s z u s t ~ n d e der G e n e r a t o r e n
(Submodes)
und F a r b d a r s t e l l u n g e n im Hin-
blick auf ein in naher Zukunft zu e r w a r t e n d e s 3 - F a r b e n - P l a s m a - S i c h t g e r~t /6/. W e i t e r e F u n k t i o n e n tion)
(Bild l~schen,
selektives L~schen,
Rota-
k 6 n n e n durch ein P a r a m e t e r w o r t a u s g e l ~ s t werden. A u c h ist das
S t e u e r w e r k bereits fur den Betrieb einer A n z e i g e e i n h e i t mit einer Aufl~sung von 1024 x 1024 P u n k t e n ausgelegt. Der V e k t o r g e n e r a t o r
i n t e r p o l i e r t digital
zwischen A n f a n g s - und E n d p u n k t
des d a r z u s t e l l e n d e n V e k t o r s und erzeugt eine d u r c h g e z o g e n e oder gestrichelte Gerade oder gibt nur den E n d p u n k t h e l l g e t a s t e t aus. Dabei kann die K o o r d i n a t e n a n g a b e entweder absolut
- b e z o g e n auf den linken
u n t e r e n E c k p u n k t des B i l d s c h i r m e s - oder r e l a t i v V e k t o r a n f a n g s p u n k t - erfolgen.
-bezogen auf den
Die absolute P o s i t i o n
(vergleichbar mit
der P o s i t i o n eines E l e k t r o n e n s t r a h l e s bei h e r k ~ m m l i c h e n Bildr~hren) ist fur X und Y in e i n e m Z~hlregister enthalten, rator i n k r e m e n t i e r t oder d e k r e m e n t i e r t wird.
das vom V e k t o r g e n e -
Durch v o r z e i c h e n r i c h t i g e s
V e r t a u s c h e n der Z ~ h l r e g i s t e r e i n g ~ n g e ist eine R o t a t i o n der g r a f i s c h e n D a r s t e l l u n g um 90 ° , 180 ° oder 270 ° m~glich. Das Z ~ h l r e g i s t e r g e s t a t t e t die A d r e s s i e r u n g eines 12 Bit x 12 Bit g r o B e n Feldes,
aus d e m der d a r z u s t e l l e n d e B e r e i c h
(512x512 Punkte)
d u r c h A d d i t i o n des Inhaltes eines G r u n d p o s i t i o n s r e g i s t e r s a u s g e w ~ h i t w e r d e n kann. Der Z e i c h e n g e n e r a t o r a r b e i t e t m i t M i k r o v e k t o r e n .
Er g e s t a t t e t die Er-
zeugung von 96 d a r s t e l l b a r e n a l p h a n u m e r i s c h e n Zeichen im A S C I I - C o d e in drei Zeichengr~Ben.
Die k l e i n s t e S c h r i f t g r 6 B e e r l a u b t auf d e m
512 x 5 1 2 - P u n k t e - S c h i r m die D a r s t e l l u n g von 85 Z e i c h e n / Z e i l e und 42 Zeilen/Bild. Der Z e i c h e n v o r r a t kann d u r c h einen w e i t e r e n F e s t w e r t s p e i c h e r
(ROM) er-
205
weitert werden, der h~ufig benutzte Symbole, wie z.B. die for die MAP-Darstellung erforderlichen Punktkonfigurationen, die Umschaltzeichen
enth~it und durch
SO/SI anstelle des Zeichengenerators
angesprochen
wird. Einen weiteren Vorteil bietet der flache Bildschirm: Von der ROckseite her k6nnen auf den Schirm Bilder projiziert und so der Bildschirmdarstellung unterlegt werden. Im Rahmen der Entwicklung des grafischen Sichtger~tes mit Speicherschirm ist ein modulares Teilprogrammsystem figkeitsverteilungen arten entstanden,
zur Darstellung von gemessenen H~u-
(Vielkanalanalyse)
in verschiedenen Darstellungs-
das auch for das Plasma-Display verwendet werden kann.
So existieren Funktionsbausteine
zur Ausgabe for zweidimensionale Daten-
mengen mit Skalierung und Ausschnittswahl. k6nnen als Raster-
jektiod auf eine Ebene ausgegeben werden. darstellung)
Dreidimensionale Datenfelder
(Map) oder Konturdarstellungen
(Isolinien)
Dazu k~nnen Schnitte
als Pro(Relief-
ausgew~hlt und dargestellt werden. Diese Darstellungsarten
sind besonders for die quantitative Auswertung geeignet.
FOr eine quali-
tative Beurteilung von Messungen ist jedoch eine perspektivische Darstellung weitaus besser geeignet.
DafOr sind Bausteine for Isometrie-
bzw. Netzdarstellung vorhanden. Die genannten Funktionsbausteine steht eine Aufrufnahtstelle
haben zwei Nahtstellen.
zur Verf~gung.
Dem Anwender
Uber diese Nahtstelle wird
der Baustein aktiviert und es werden die notwendigen Parameter ~bergeben. Eine einfache Bedienungsroutine Bedienungsanweisungen tennahtstelle,
anzusprechen.
erlaubt es, die Bausteine auch Ober Die zweite Nahtstelle
an die verschiedene Ger~te-Treiberroutinen
ist eine Daangeschlossen
werden k6nnen. Eine solche E-A-Treiberroutine muB die normierten Daten, die yon den Funktionsbausteinen
erzeugt werden,
tespezifische Datenstruktur umwandeln.
in die jeweilige ger~-
Besitzen die Ger~testeuerungen
keine oder nur einen Teil der Funktionsgeneratoren, Routinen softwarem~Big realisiert.
so sind diese in den
Die Routinen enthalten auBerdem die
Ausgabe an das jeweilige Ger~t. Es existieren Ger~te-Treiberroutinen das Plasma-Display, plotter
for das Speichersichtger~t
sowie for einen Trommel-
(Calcomp 565).
Die Funktionsbausteine Sprache
f~r
und die Ger~te-Treiberroutinen
(PROSA 300) programmiert.
und logische Befehle verwendet.
sind in Assembler-
Dabei wurden nur einfache arithmetische
Gleitkommaoperationen
sche Funktionen wurden nicht benutzt.
und trigonometri-
Dadurch wurde erreicht,
Speicherbedarf und die Rechnerbelastung
dab der
gering gehalten werden und die
ProzeBdaten schnell und unverz~gert grafisch dargestelit werden k~nnen.
206
E
l
e
k
t
r
~
o
d
~
~ S u b s t r a t g l a s :i
!:
~
~ Dielektrische
S t Dichtung~
-~"_.ZZ2Z--
... ~
TZT-
'Z::~~"~'T'~ _-~-"7 -'TZ-
~ 0 , 2 mm /
Elektroden /
"'"
Abb.l: Aufbau Plasma Display
Direct View Storage Tube
(Digivue MDXVI) Bildschirm Aufl6sung
(Tektronix 611) 210 x 162 mm
216 x 216 mm
40 Pkte/cm
24 Pkte/cm
Punktgr6Be
0,25 .... 0,3 mm
Adressierbares Raster
512 x 512 Pkte
0,25 mm (gespeichert) 1400 x 1024 Pkte (beim HMI-Sichtger~t)
Helligkeit Kontrast
50 ft.L.
Z 6 ft.L.
> 25:1
Z 6:1
Punktschreibzeit
20 us
5 Us
Vektorschreibzeit
2000 cm/s
1000 cm/s 80.000 Pkte/s
50.000 Pkte/s
(beim HMI-Sichtger~t) L6schen
nur ganzes Bild
Bild und Einzelpunkte
Punktl6schzeit Bildl6schzeit LSschvorgang
20
us
20
us
0,5 s
ohne Aufleuchten
mit hellem Aufleuchten
des Bildschirmes !
Abb.2: Vergleich Plasma-Sichtger~t - Speicherbildr6hre
Emittiertes
Licht
Zellenspannung
UZOND
UZOND
~
I
Spannung zwischen Elektrode und O b e r f l a c h e des D i e l e k t r i k u m s
Spannung zwischen den E l e k t r o d e n einer Zelle
10
us
--I
--
I I
I
-US-
UZtind US . . . . . . .
Abb.3:
I
A
~
Schreiben US÷ 2 " U A s _
I
A
Impulsdiagramm
I
A
I__1
[--]
A I
_
II
_
interaktive Phase
I
A
t-J
A I
I
i
I
I--I-I__' I--F
I 2"UAL/~-
I__1
I
L6schen
o
rD
~ ~
~
Y..
i
(%
)deu. s ibm )deR .~g.
p iram .~ter
RON
........T..
Abb.4:
CAMAC-Steuerung
Register laden
(Ereuz)
I MARKEN-GENERATOR
1024 x 8 Bit
I
ZEICHEN-GENERATOR 96 darst. Zeichen 7 Formatsteuerz. ASCII 3 Zeichen~r6Ben
VEKTOR-GENERATOR relativ/absolut durchgez/gestrich/ Endpunkt ,,
Register lesen
i
f
>
Z~HLREGISTER
>
fur Plasma-Display
LOSCH..........S...TEUERUNG ...
)
I
f
GRUNDPOSIT.REGISTER
+
Ij DISPLAY I 512x512 | (I024x1024~
Po o co
209
Parallel
~0 0', Mode
Seriell
IP Io o; Mode ] P I1 IFarbe ISubm-t
N11FarbelSubm.J Befehlswort
IS 4...IS 1
~]0 0:1 1 0 1 1 [ ~
Parameter
'1
IPI o o:1 1 o ,,!,,,,,,i]
Parameterwort
ESC
IP 1
Parameter
J
1 Alphanum. Zeichen
IPI
Zeichen
I
I Vektoren 1.Teilw.
IPIV V I
Datenworte N
1.Zeichen
N
2.Zeichen
7-Bit-ASCII
NI I N v ~I
11 Bit X
OIIIV
11 Bit
Y
I Vektoren 2.Teilw.
L-vorzeichen
5 X~
]
IPll II sx.
I
IP IV V',
5 Yh
]
IPlrli
sY.
I
nur 10 Bit
--Intensit~t Abb.5: Datenstruktur
Lesen Lesen
Test Schrei- Selekt. Selekt. LAM ben Setzen LSschen
F(0)
F(8)
F(1)
F(16)
Pufferregister
A (0)
x
Zahlregister X
A (1)
x
F(19)
F(23)
Zahlregister Y
A (2)
x
Markenpos.-Reg. X
A (3)
x
Markenpos.-Reg. Y
A (4)
x
Grundpos.-Reg. X
A (5)
x
Grundpos.-Reg. Y
A (6)
x
LAM-Status
A(12)
x
LAM-Maske
A(13)
x
LAM-Anforderung
A(14)
LAM
A(15) Abb.6:
X(Q) CAMAC - Befehle
210
Literatur:
/I/ H o l z ,
G.E.:
Proc.
SID
I_~3, 2 - 5
W.J.:
Electronics
/3/ B i t z e r ,
D.L.,
Slottow,
H.G.:
AFIPS
Bitzer,
D.L.,
Slottow,
/4/ J o h n s o n , 642 - 649 /5/ J o h n s o n , /6/
Hoehn,
/7/
Zahn,
/8/ P e t t y , /9/ M i w a , /10/Weber,
R.L.,
L.J.:
R.A.:
HMI-Bericht
Slottow,
et al:
L.R.,
Schmersal,
Martel,
et al:
W.D., H.
120 - 125
(1970)
Conf.
Proc.
H.G.:
29
IEEE
(1966) Trans.
E D - 18,
(1971) W.E.,
H.J., J.
43,
(1972)
/2/ H a r m o n ,
Proc.
Johnson,
H.G.:
B-IO0
SID
I_~3, 56 - 60
E D - 20,
(1966)
1078 - 1081
(1973)
(1970)
IEEE-Trans.
S I D 14, R.L.:
Proc.
IEEE Trans.
34 - 38
IEEE-Trans.
E D - 18,
654 - 658
(1971)
(1973) E D - 20,
1082
- 1091
(1973)
DATENSICHTGER~,TE FOR GRAFISCHE DARSTELLUNGEN UNTER VERWENDUNG VON FERNSEHMONITOREN
Rolf Zimmermann
1. DATENSICHTGERATE ALS UNIVERSELLE ANZEIGEGERATE Datensichtger~ite sind die universellsten bekannten Anzeigeeinheiten. Sie werden nicht nur zur Ausgabe von Zahlenwerten und alphanumerischen Texten sondern auch zur Darstellung von Diagrammen, Blockbildern, Kurven und Strichzeichnungen und sogar filr fl~ichige Bilder verwendet und kOnnen daher die Anzeigefunktionen konventioneller Rechner-Peripherieger~ite (z.B. Blattschreiber, Kurvenschreiber, Ziffernanzeiger6hren, Zeichengeriite) iibernehmen und noch bessere Darstellungsformen als diese erm6glichen. Die hohe Flexibilit~ universeller Datensichtger~te ,und spezielle Eingabeger~te wie Lichtgriffel, Steuerkniippel oder BeriJhrungsfelder erlauben auPoerdemauch neuartige Dialogformen fiir den Verkehr zwischen Mensch und Rechner, z.B. die MENU-Technik ("Speisekarten"-Wahltechnik) zur Auswahl zwischen verschiedenen auf dem Bildschirm stehenden Zeichen, Namen und Funktionen und die Auswahl von Punkten in Bildern (z.B. die Auswahl eines Mel~punktes im Blockschaltbild einer rechnergesteuerten Anlage) mit automatischer Anzeige der Bezeichnung dieses Punktes, aktueller Melt- und Grenzwerte oder zeitlicher VerI~iufe dieser Werte usw. [5, 7, 13, 22, 24] L~Et man diese Dialog-und BedienmSglichkeiten eines Datensichtge#ites aul3er Betracht, so lassen sich f~ir die eigentliche Anzeige eines universellen Sichtger~ites die folgenden Forderungen benennen [15,17,23,32]: -
-
Darstellung von Texten, Einzelzeichen und zus~tzlichen Symbolen Darstellung von einfachen Blockbildern, Diagrammen und Tabellen Darstellung ft~chiger Balken- und S~ulendiagramme Darstellung von Kurvenverl~iufen Darstellung von Strichzeichnungen jeder Art Darstellung von fl~chigen Bildern Schneller Aufbau des Gesamtbildes Schnelle Anderung beliebiger einzelner Bildteile (0berschreiben, L6schen, Verschieben, usw.) Ausreichende AuflSsung Einblendung yon bereits vorliegenden Bildern anderer Art (Fotos, Radarbilder, Fernsehkamera) Darstellung in unterschiedlichen Farben, Helligkeiten, btinkend Anpassung von Bildhelligkeit und Kontrast an die Raumhelligkeit Verwendung von Bildschirmen wiihlbarer Gr61~e Anschlu£ von Parallelbildschirmen, eventuell Projizierm6glichkeit Anschlul~ von Bildaufzeichnungs-, Bildiibertragungs- und Kopierger~iten
2. TECHNISCHE REALISIERUNG VON DATENSICHTGERATEN Die allgemeinen Funktionen und Besonderheiten unterschiedlicher Datensichtger~ite lassen sich am einfachsten mit Hilfe eines Blockschaltbildes erl~utern; Bild 1. ] schnittstelle fiir I ISichtger~itesteuerung I j Generat°ren fiir Zeichen' H J Rechner und ~ e i n s c h l . Zeitsteuerung, ~ Symbole, Vektoren, evtl. J - ~ Helligkeitssteuerung Dateneingabege- ! I Daten- u. Koordinaten- I J Bildwiederholspeicher I ! r~ite I I register, evtl. Bildwieder- I ..... li ...... I holspeicher I _1 Ablenksteuerung fiir X- ' U Bildschirm, evtt. speichernd ,,, / ....J - ~ und Y-Richtung 17
I
Bild 1 :
AIIgemeines Blockschaltbild eines Datensichtgeriites
212
Bei einem Datensichtger§t werden die vom Rechner oder direkt von einer Eingabeeinheit (z.B. Tastatur oder Lichtgriffel) stammenden Daten mit eventueller Zwischenpufferung entgegengenommen und zur Erzeugung des Bildes weiterverarbeitet. Die Libertragenen Daten k6nnen aut~er Zeichen- und Vektor-Codes auch Funktionssteuerzeichen oder Bildkoordinaten sein und werden in der Steuereinheit des Sichtger~itesweiterverarbeitet. Um auf dem Bildschirm das erw~inschte Bild zu erzielen, mLissendie entsprechenden Bildpunkte angesteuert werden und in der richtigen Helligkeit aufleuchten. Die einzelnen Ausf~ihrungsformen yon Datensichtger~ten unterscheiden sich technisch in erster Linie durch die verwendete Anzeigeeinheit (normalerweise KathodenstrahlrShre), die Art der Ablenkung bzw. Koordinatenadressierung und die Art der Speicherung. In Tabelle 1 sind einige Beispiele fi~r Anzeigeger~iteaufgefShrt, ktassifiziert nach dem Typ der Anzeigeeinheit und der Art der Speicherung. [4,9,11,13,t9,26]
Speicherprinzip
Anzeigeeinheit Kathodenstrahlr6hre
Sonstige
Keine Speicherung
Oszillograph, Fernsehen, Radar
Megger~te, Lampen
Speicherung von kodierter Bildinformation
X-Y-Display (Vektor-Display), alphanumerisches Video-Display, Video-Kurven-Display
Leuchtdiodenmatrix, FISssigkristallmatrix
Speicherung von Einzelpunkten
Video-G rafik-Display
Lampenmatrix, z.B. f~ir Leuchtschriften
Speicherung im Bildschirm
Speicheroszillograph, Speicherr6hrendisplay
Plasmadisplay
Tabelte 1:
Beispiele fi~r Anzeigeger~ite mit unterschiedlichen Anzeige- und Speicherprinzipien
Bei den Datensichtger~ten mit Kathodenstrahlr6hren und zus~itzlichem Bildwiederholspeichergibt es nun noch eine Vielzahl yon AusfLihrungsformen, die sich unter anderem durch die Art der Ablenk- und Helligkeitssteuerung unterscheiden. I nzwischen am meisten verbreitet sind hierbei die Datensichtger~te mit Anzeige nach dem Fernsehprinzip (Video-Displays, TV-Displays). Als Anzeigeeinheit wird bei diesen Ger~ten ein handelsSblicher oder geringfSgig modifizierter Fernsehmonitor oder Fernsehempf~nger verwendet, dem normalerweise Standardsignale nach CCI R-Norm zugef~ihrt werden. H ierdurch besitzen solche Displays automatisch viele der im ersten Abschnitt geforderten Eigenschaften, die Kosten sind gering, die Wartung ist einfach, fast unbeschr~nkt viele Bitdschirme beliebiger Gr6Ee und auch Projektionseinrichtungen k6nnen unmittelbar oder r~umlich entfernt angeschlossenwerden, und die Darstellungsm6glichkeiten umfassen nahezu beliebige Farben, Helligkeiten und Blinkfrequenzen und das Einblenden von Fernsehbildern anderer Quellen (z.B. yon 0berwachungskameras). [8, 29, 30, 31,35, 36, 37, 38, 39] Kennzeichnend fLir das Fernsehverfahren ist die Ablenkung des Elektronenstrahls in einem festen ZeilenRaster, Zeile f~ir Zeile nacheinander. Das Bild wird dabei durch entsprechende Modulation der Helligkeit erzeugt. Das zum Monitor LibertrageneSignal besteht ~iberwiegendaus dieser Helligkeits- (bzw. zus~tzlicher Farb-) Information und enth~lt augerdem Synchronsignale, durch die Bild- und Zeilenanf~nge festgelegt werden. Die eigentliche Ablenkung erfolgt im Monitor selbst~ndig aufgrund dieser Synchronsignale. Wegen der festen und niedrigen Bild- und Zeitenfrequenzen ist die Ablenksteuerung relativ einfach aufgebaut, hohe Anforderungen werden jedoch an die Bandbreite der Helligkeitssteuerung gestellt (ca. 5 MHz bei normaler Aufl6sung, bis ca. 30 MHz bei Spezialmonitoren mit erh6hter Aufl6sung). [12, 18] Den oben genannten Vorteilen des Fernsehverfahrens stehen die oft nicht ausreichende Aufl6sung und die sichtbare Rasterung des Bildes entgegen, so dal~ fijr die Darstellung sehr komplexer Zeichnungen (z.B. bei
213
rechnergestLitzten IEntwurfsverfahren) Datensichtger~te mit freier Elektronenstrahlablenkung bessergeeignet sind. Bei diesen X-Y-Displays (Vektor-Displays) ist die Ablenkung bildabh~ngig. So k6nnen Zeichen, Vektoren und gekrSmmte Linien durch eine ihrer Form entsprechende Elektronenstrahlablenkung in einem Zug geschrieben werden, also in einer fLir Fernsehdisplays nicht m6glichen Weise. Aufwendige Systeme dieser Art besitzen eine sehr hohe Aufl6sung, und farbige Darstellungen mit bis zu 4 Farben (z.B. rot, orange, gelb, gr(Jn) sind bei Verwendung von Multiphosphor-Durchdringungsr6hren m6cjlich. Die Ablenkung des Elektronenstrahls kann rein analog gesteuert sein, z.B. durch Analog-I ntegrierer oder Lissajous-Generatoren, oder durch Z~ihler, Addierwerke und nachgeschaltete DigitaI-Analog-Umsetzer erfolgen. [1,16, 21] 0blicherweise werden bei Vektor-Displays die Bildschirmpunkte in beliebiger Reihenfolge durchlaufen, entsprechend erh~lt der BildwiederholspeicherfiJr die Zeichen und Vektoren deren Codes und Anfangskoordinaten in beliebiger Reihenfolge. Die Bildwiederholrate von ca. 50 Hz, die fSr ein flimmerfreies Bild erforderlich ist, und die Bandbreite der Ablenkeinheiten und damit die Schreibzeit je Linie beschr~nken jedoch die Zahl der darstellbaren Linien. 0bliche Maximal-Anzahlen reichen fLir Strichzeichnungen im allgemeinen aus, nicht aber f~ir umfangreiche Balkendarstellungen und sonstige fl~chige Bilder. In vielen Anwendungsf~llen, speziell bei der Prozel3datenverarbeitung, sind aber gerade solche Darstellungen erwLinscht und andererseits ist eine 5berm~iEigfeine Aufl6sung des Bildes nicht unbeclingt erforderlich. Es liegt daher nahe, fq'~rsolche Anwendungen Verfahren zu entwickeln, die die Erzeugung grafischer Darstellungen auf Fernsehdisplays ermSglichen. 3. DATENSICH'FGERATE MIT ANZEIGE NACH DEM FERNSEHPRINZ|P
In Europa [Jbliche Fernsehsysteme zerlegen das Fernsehbild in 625 Zeilen. Dieses Bild wird in zwei kammartig gegeneinander versetzten Halbbildern mit je 312,5 Zeilen 5bertragen. Dieses Verfahren, bei dem in einem Halbbild alle "'ungeraden" und im anderen alle "geraden" Zeilen Libertragen werden, heil~t Zeitensprungverfahren. Infolge der Wiederholungsrate von 50 Halbbildern je Sekunde (25 Bilder je Sekunde) wirkt das erzeugte Bild flimmerfrei, wenn das Verh~ltnis aus Betrachtungsabstand und Bildschirmgr61~eso grol~ ist, dad die einzelnen Zeilen nicht mehr getrennt gesehenwerden. Bei der Anwendung als Datensichtger~t ist dies meist nicht der Fall, so dal~ das Bild nur flimmerfrei erscheint, wenn die Information jeder Zeile 50 mal je Sekunde wiederholt wird. Dies erreicht man bei Erzeugung yon zwei v611ig identischen, nicht gegeneinander versetzten Halbbildern mit z.B. je 312 Zeilen. Datensichtger~ite ohne Zeilensprungverfahren verwenden also z.B. 312 Zeilen und eine Bildwiederholfrequenz von 50 Hz. Die Schreibzeit f~ir ein Bild betr~igt 20 ms, die Zeit fSr eine Zeile 64/zs. Da die Bandbreite der Helligkeitssteuerung handels~iblicher Fernsehger~te 4 bis 5 MHz betr~gt, sind bei einer digitalen Rasterung innerhalb einer Zeile Rasterfrequenzen von 8 bis 10 MHz m6glich. FSr ein rechteckig berandetes Feld auf dem Bildschirm stehen jedoch nicht die voile Zeilenzahl und die voile Zeilenzeit zur VerfiJgung, sondern infolge der ElektronenstrahI-RScklaufzeiten und der nicht nutzbaren Randbereiche nur ca. 270 Zeilen und ca. 45/~s je Zeile. Ein flimmerfreies digital gerastertes Bitd zur Anzeige auf Fernsehger~ten normaler Bandbreite und Zeilenzahl besitzt daher meist ein Raster aus 256 Zeilen und bis zu 384 Spalten. Zeichen, Vektoren und sonstige 8ildelemente werden aus Punkten dieses Rasters aufgebaut. Alphanumerische Zeichen fSIlen dabei meist ein Feld aus 5 x 7 Punkten aus, Vektoren bestehen aus einer Aneinanderreihung von Rasterpunkten und wirken daher je nach Schr~glage mehr oder weniger gestuft. Bei einem Raster yon 256 x 384 Punkten, einer Zeichengr61~evon 5 x 7 Punkten und je einem Punkt Zwischenraum kSnnen auf diese Weise 32 Textreihen mit je 64 Zeichenpl~tzen, also bis zu 2048 Zeichen, wiedergegeben werden. Neben diesen digital aufgebauten Bildern (Punkte in einem festen Raster) k6nnen auf einem Fernsehger~t auch ~ibliche "analoge" Fernsehbilder ausgegebenbzw. zus~tzlich eingeblendet werden. Bildquellen k6nnen
214
Fernsehkameras und Videoaufzeichnungsger~itesein, andere Biidwandier wie Flying-Spot-Scanner und ScanConverter oder auch Ausgangssignalevon Analogrechnern und ~ihnlichen Get,ten, Das bedeutet under anderem, dal~ mit Hilfe von Fernsehkamerasoder Scan-Convertern die grafischen Darstellungen eines X-Y-Displays auch auf Fernsehmonitoren wiedergebbar und auch mit Bildern anderer Quellen mischbar sind. Solche ger~tetechnischen L6sungen werden hier jedoch nicht welter ausgefi~hrt,sondern nur Verfahren zur digitalen Erzeugung grafischer Darstellungen auf Fernsehmonitoren. [16] 4. VIDEO-DATENSICHTGERATE MIT DIGITALER BILD-ERZEUGUNG 4.1 ALLGEMEINES BLOCKSCHALTBILD Das allgemeine Blockschaltbild eines Datensichtgeriites wird hier noch einmal wiedergegeben,jedoch modifiziert f(Jr digitate Datensichtger~itenach dem Fernsehprinzip; Bild 2, i
i
Schnittstelle fSr ! I Sichtger~testeuerung I i Datenkonverter 1, ! I Datenkonverter 2, I Ausgabespeicher, Rechner und ~ einschl. Zeitsteuerung, ~ Bildwiederholspeicher, Helligkeitssteuerung DateneingabeDaten- u. Koordinaten- ~ I evtl. Zwischenspeicher ger~te register, Funktionsi ~ register ~_~Synchronsignal-ErzeuFernsehmonitor I I I gung
H
Bild 2:
AIIgemeines Blockschaltbild digitaler Video-Datensichtger~ite
Die vom Rechner oder einer Dateneingabeeinheit stammenden Daten werden vom Sichtger~t entgegengenommen, mit den Informationen von Funktions-, Koordinaten- und sonstigen Datenregistern gemeinsam verarbeitet und gelangen nach entsprechender Umsetzung (Datenkonverter 1) in einen Bildwiederholspeicher. F(]r die Wiedergabe wird die gespeicherte Information yon dort direkt oder ~ibereinen Zwischenspeicher abgerufen und f~ir die Erzeugung der Videosignate weiterverarbeitet. Die bei dieser Verarbeitung (Datenkonverter 2) entstehenden digitalen Signale werden meist nochmals zwischengespeichert, bevor daraus das analoge Videosignal entsteht. [25] Die einzelnen Video-Datensichtger~iteunterscheiden sich vom Prinzip her durch die Aufgaben der beiden Datenkonverter des Blockschaltbitdes (z.B. Adregsortierung oder Zeichenform-Erzeugung) und die Inhalte der einzelnen Speicher (z.B. Bildwiederholspeicher fSr Zeichencodes oder f/ir Bildpunkte). Am deutlichsten lassen sich die einzelnen Ger~tetypen dabei anhand des lnhalts des Bitdwiederholspeichers ktassifizieren, so wie es im weiteren geschieht. [4, 27, 28, 30, 34] 4.2 VIDEO-DATENSICHTGERATE MIT ZEICHENPLATZBEZOGENER CODIERTER SPEICHERUNG (ALPHANUMERISCHES VIDEO-DISPLAY, HALBGRAFISCHES VIDEO--DISPLAY) Zum Verst~ndnis diesesVerfahrens, das bei alphanumerischen Video-Datensichtger~ten allgemein Liblich ist, stelle man sich eine Aufteilung des Bildes in feste Zeichenpl~itzevor, z.B. in 32 Textreihen mit je 64 Zeichenpl~itzen. An jedem dieser Zeichenpl~tze kann genau ein Zeichen wiedergegebenwerden. Beschr~nkt man den Zeichenvorrat auf die 64 ASCII-Zeichen, so mug der Bildwiederholspeicher 32 x 64 = 2048 Worte mit je 6 bit enthalten. AIs Speicher kommen solche mit direktem Zugriff (z.B. Kernspeicher oder elektronische RAMs) oder zyklische Speicher (z.B. Schieberegister oder Verz6gerungsleitungen) in Frage. Da beim ~iblichen Zeichenaufbau aus 5 x 7 Punkten jedes Zeichen w~hrend siebenaufeinanderfolgender Zeilen erzeugt wird, mul~ fLir jede Zeichenreihe der gespeicherte Code siebenmal zur Verf~jung stehen. Bei zyklischen Speichern wird daher die Information einer Textreihe (z.B. 64 Worte je 6 bit) am Anfang der Reihe in einen ebenfalls zyklischen Zwischenspeicher/Jbernommen, an dessen Ausgang sie dann in jeder der nachfolgenden sieben Zeilen zur Verf~gung steht. Man beachte aul~erdem, dab bei obigem Beispiel (64 Zeichen in ungef~hr 45 #s)die Zugriffsfrequenz der Speicher bei Liber 1 MHz liegt. [3]
215
Zus§tzliche Zeichen und Symbole (auch aus mehr als 5 x 7 Punkten) sowie Unterstreichungen, Tabulierungen und Variationen der Zeichen durch Farbe, Helligkeit und Blinken erfordern zus~tzliche Bitstellen je Wort, z.B. 1 bit fik die Verdopplung des Zeichenvorrats auf 128 Zeichen und Symbole, 3 bit fSr die Vorgabe von 7 Farben. Falls Farben, Unterstreichungen usw. nur in Leerpl~itzenund nicht innerhalb eines Textwortes wechseln sollen, ist die Verwendung von Funktionszeichen sinnvoll. Ein solches Funktionszeichen wird an einen sonst leeren Zeichenptatz geschrieben und hat z,B. die Bedeutung "Beginn der Farbe gelb und gleichzeit[g Beginn einer Unterstreichung". Durch Verwendung dieser Funktionszeichen, die sich auf alle folgenden Pl~itzeauswirken, kann der Speicherbedarf je Zeichenplatz verringert werden. [30] Charakteristisch fEr Ger~itedieser Art ist die feste Zuordnung zwischen Speicherplatz und Zeichenplatz, bei Eingabe eines neuen Zeichens mul~ daher der Speicher entsprechend der gew~inschtenr~umlichen Lage des Zeichens adressiert werden (Datenkonverter 1 in Bild 2). Die Zeichen- und Symbolgeneratoren (Datenkonverter 2) werden mit dem Zeichencode und der Zeilennummer innerhalb der Textreihe angesteuert und geben die f5r diesesZeichen in der angesteuerten Zeile relevante Bildpunktinformation (z.B. 5 Punkte) aus, die zur Erzeugung des Videosignals verwendet wird. Die Zusatzinformation der Funktionsbits oder Funktionszeichen wird zur Modifizierung des Videosignals (z.B. Farbwahl) verwendet. Nimmt man in den Zeichenvorrat auch aneinander anschliel~endeSymbole auf, so lassensich mit diesen Ger~iten auch einfache Zeichnungen, speziell Blockbilder, in guter Form wiedergeben. Mit weiteren Symbolen, z.B. ausgefiJllte Zeichenpl~tze oder Teilfl~chen davon, sind auch Balkendarstellungen und grobgerasterte Kurven m6glich; rnit Verbindungslinien zwischen den Punkten des linken und rechten Zeichenfeldrandes als zus~itztichenSymbolen sind sogar die meisten Kurven (wenn auch nur mit lest vorgegebenerLage der St~zpunkte) darstellbar; Bild 3. [2, 6, 28, 30]
I
Bild 3:
@
Grafische Darstellungen auf einem Video-Datensichtgeriit mit zeichenplatzbezogener Speicherung
Beliebige Kurven und Zeichnungen sind bei diesem Verfahren jedoch nicht m6glich; besondersdann nicht, wenn sich Linien kreuzen oder schneiden. Aber auch geringf~gige Lageabweichungeneinzelner Zeichen (z.B. for Hochzahlen und Indizes) sind ebenso wenig realisierbar wie geringf~gigedynamische Verschiebungen, Verl~ngerungen oder Drehungen von Linien.
4.3 VIDEO-DATENSICHTGERA, TE MIT CODIERTER SPEICHERUNG ENTSPRECHEND DER Z E I CHENPLATZFOLGE Kennzeichnend f~ir das im vorigen Abschnitt beschriebene Verfahren ist die feste Zuordnung zwischen Speicherplatz und Bildschirm-Zeichenplatz, wodurch einerseits je Zeichenplatz nur genau ein Symbol darstellbar
216
ist und wodurch andererseits Speicherpli~tzeauch fiJr die vielen ZeichenpI~tze benOtigt werden, die leer sind. Diese beiden Nachteile lassensich durch die folgende andersartige Organisation des Bildwiederholspeichers vermeiden, bei der die feste Aufteilung des Bildschirms in Zeichenpl~tze und die damit verbundenen Nachteile (vgl. Ende des Abschnittes 4.2) erhalten bleiben. Die Information ist ebenfalls genau in der Reihenfolge im Bildwiederholspeicher abgelegt, wie sie fSr die Darstellung auf Fernsehmonitoren ben6tigt wird. Die Speicherpl~tze sind jedoch den Zeichenpt~tzen nicht fest zugeordnet, sondern jeder Speicherplatz kann entweder einen Symbolcode oder die Zeichenplatzadressedes niichstfolgenden darzustellenden Symbols enthalten. Normalerweise folgen im Bildwiederholspeicher also abwechselnd Adressen und Symbolcodes. Stehen zwei oder mehr Symbolcodes unmittelbar hintereinander, so werden die zugeh6rigen zwei oder mehr Symbole im gleichen Zeichenfeld abgebildet, sich kreuzende Linien sind also darstellbar. Die Anzahl der in einem Feld gleichzeitig abbildbaren Symbole h~ngt u.a. vonder Geschwindigkeit der Symbolgeneratoren und dem Aufwand fiir den hierbei benOtigten Ausgabe-Bitdpunktspeicher ab, die Zahl der Symbole je Zeichenfeldreihe bzw. des Gesamtbildes h~ingtvon der Gr6ge des Zwischenspeichersbzw. des Bildwiederholspeichersab (vgl. Bild 2), [28] 4.4 VIDEO-DATENSICHTGERATE MIT ZEILENBEZOGENER CODIERTER SPEICHERUNG (VIDEO-KURVEN-DISPLAY) F~Jrdie alleinige Darstellung von Kurven ist ein anderes Verfahren mSglich, n~mlich bei vertikalem Kurvenverlauf die Speicherung eines Kurvenpunktes je Fernsehzeile. Der Bildwiederholspeicher fiir eine Kurve ben6tigt dann je Zeile genau ein Wort. 0blich sind je Kurve 256 Worte mit je 8 oder 9 bit., in jeder Zeile ist daher genau ein Kurvenpunkt aus 256 oder bis 512 Punkten adressierbar. Die Kurven k6nnen sowohl aus Einzelpunkten bestehend als auch mit waagerechten Verbindungslinien dazwischen wiedergegebenwerden; au8erdem ist es m6glich, die Bereiche zwischen den Kurven fl§chig (farbig) auszuf~illen; Bild 4.
Bild 4:
UnterschiedlicheDarstellungsmSglichkeitenauf Video-Kurven-Displays
Hauptanwendungen von Video-Kurven-Disptays sind Darstellungen zeitabh~ngiger Vorg~inge,z.B. Mer~wertverl~iufe iiber lange Zeitr~iume, Speicherung einmaliger sehr kurzer Abl~iufe, repetierende Me~wertdarstellungen usw. Wird eine waagerecht verlaufende KurvenanzeigeerwiJnscht (z.B. bei medizinischen EKG-Monitoren), so wird iiblicherweise der Bildschirm oder das Ablenksystem um 90° gedreht, Texteinblendungen sind dann nur mit erheblichem Aufwand mOglich. Eine echte waagerechte Kurvendarstellung ist realisierbar, erfordert jedoch wesentlich hShere Verarbeitungsgeschwindigkeiten. [1,6,20,33]
2i7
4.5 VIDEO-DATENSlCHTGERATE MIT BILDPUNKTBEZOGENER SPEICHERUNG (VIDEOG RAFI K-DISPLAY) Bei diesen Ger~iten enth~ilt der Bildwiederholspeicher bereits die Information getrennt fLir jeden Punkt des Bildrasters. Er besteht bei einem Raster von z.B. 256 Zeilen und 384 Spalten aus fast hunderttausend Worten. Mit 1 bit je Wort sind einfarbige Darstellungen m6glich, mit 3 bit je Wort z.B. 7 Farben oder 7 Graustufen. Zus~tzliche Bits sind f~ir Angaben Liber Blinken und Blinkfrequenzen erforderlich, Der Aufbau eines Bildes erfolgt punktweise ~hnlich wie bei einem Speicherr6hrendisplay, im Gegensatz dazu ist jedoch auch punktweises L6schen m6glich. Bei manchen Ger~ten mu6 das darzustellende Bild Punkt for Punkt vom Rechner berechnet und [ibertragen werden. Die meisten Ger~te besitzen jedoch eigene Zeichen- und Vektorgeneratoren, so da6 sich der Datentransfer auf Anfangsadressen und Zeichencodes bzw. Endpunktadressen beschr~inkt. Wegen der gro6en Zahl yon zu speiehernden Worten werden als Bildwiederholspeicher au6er Schieberegistern h~iufig auch digitale Plattenspeicher verwendet. Ger~ite dieser Art erlauben innerhalb des gegebenen Punktrasters die Darstellung von Strichzeichnungen und von fl~ichigen Bildern. Wegen der Liblichen zyklischen Speicherung (Schieberegister oder digitale Plattenspeicher als Bildwiederholspeicher) ben6tigt man bei den meisten Ger~ten for das Schreiben aller Punkte eines Vektors einen Speicherumlauf. Die Schreibrate ist dann mit 50 Vektoren oder 50 Zeichen je Sekunde so niedrig, da6 dynamische Darsteltungen nicht oder kaum reatisierbar sind. Ein weiterer Nachteil dieser Ger~ite besteht darin, dal&z.B. beim L6schen einer Linie, die eine andere Linie oder Symbole kreuzt, auch alfe Kreuzungspunkte gel6scht werden; Bild 5.
eeeet
R-1
log tNl~
B |oOZe8 oO," Bitd 5:
ee~ I
ee
I0
,,...
,,,o
Darstellungen auf einem Video-Grafik-Display
4.6 VIDEO-DATENSICHTGERATE MIT LAGEUNABHANGIGER CODIERTER SPEICHERUNG (VIDEO-BI LDELEMENTE-DISPLAY) Allen bisher beschriebenen Video-Datensichtger~ten ist gemeinsam, dal~ der Bildwiederholspeicher bildschirmorientiert aufgebaut ist, d.h. jedem Platz des Bildwiederholspeichers entspricht in vorgegebener Reihenfolge ein Zeichenplatz, eine Zeile oder ein Rasterpunkt auf dem Bitdschirm. Die im Bildwiederholspeicher abgelegten Worte enthalten codierte Information 5ber die Darstellung fiJr die Zeichenpl~tze, jede Zeile bzw. jeden Rasterpunkt. Da bei den meisten Displayanwendungen nur ein Teil der Zeichenpl~itze bzw. nur ein ganz geringer Bruchteil der ansteuerbaren Rasterpunkte for die Darstellung ben6tigt wird, ist es sinnvoll, nur die f~ir das darzu-
218
stellende Bild relevante Information in codierter Form so zu speichern, dal~ die Gr6f~e des Bildwiederholspeichers der Anzahl der tats~chtich darzustellenden Bildelemente entspricht. Wenn dabei die Freiheitsgrade eines Video-Grafik-Displays nach 4.5 erreicht und die Nachteile des in 4.3 beschriebenen Verfahrens vermieden werden sollen, mul~ jedes Bildelement (Zeichen, Symbol, kompletter Balken, Vektor, Vektorsegment usw.) unabh~ngig von seiner Lage auf dem Bildschirm in einem Wort gespeich@rtwerden, das aul~er dem Zeichencode, der Balkenl~ingeetc. auch die genauen Anfangskoordinaten und weitere Angaben zur Farbe und Darstellungsart des Bildelementes enth~lt (und dadurch relativ lang ist). Diese optimale Art der Kodierung und lageunabh~ngigenSpeicherung ist bei X-Y-Displays Liblich und bereitet dort keine Schwierigkeiten, da die einzelnen Bildelemente wegen der beliebig ansteuerbaren Elektronenstrahlablenkung auch in beliebiger Reihenfolge geschriebenwerden k6nnen. Bei Fernsehdisplays ist die Elektronenstrahlbewegung jedoch fest vorgegeben.WSrde man dort auf einen Zwischenspeicher verzichten, so mLil~tewiJhrend der Darstellungszeit eines Bildpunktes (ca. 100 ns) der gesamte Bildwiederholspeicher durchlaufen und daraufhin (Jberpr(Jftwerden, ob und wie (z.B. in welcher Farbe) dieser Bildpunkt darzustellen ist. Eine solche L6sung ist zur Zeit nicht realisierbar. Ein Verfahren mit lageunabh~ngigerSpeicherung der Bildinformation ben6tigt daher einen ausreichend grol~en bildpunktbezogenen Zwischenspeicher, in den bei einem Durchlauf des Bildwiederholspeichers die f(Jr ein bestimmtes Bildschirmgebiet relevante Information nach deren Berechnung eingeschriebenwird. Zur Ermittlung der optimalen Gr6i~edes Bildwiederholspeichers und des Zwischenspeicherswurden 5bliche Darstellungen in Prozel~wartenund sonstigen Anzeigesystemen mit dem Ergebnis analysiert, dal~die meisten benStigten Bilder aus nur 100 bis 400 Bildelementen bestehen. Das Blockschaltbild eines hieraus konzipierten Datensichtger~tesist in Bild 6 wiedergegeben.
Schnittstelle fur !
Sichtger~testeuerung Rechner und I einschl. Zeitsteueru ng, Dateneingabe- ~.= Daten- u. Koordinatenregister, Funktionsger~te register
I
tAufbau der Speicherworte, I ! Steuerung yon Bildmani- I I pulationen, Bildwiederhol- ~ _ ~ speicher fSr z.B. 512 Wor- I -I te je ca. 40 bit I I
I I
- - ~ SynchronsignaI-Erzeugung H Bild 6:
Generatoren fSr Zeichen, Symbole, Liniensegmenteund Balken, WechselpufferZwischenspeicher, Helligkeitssteuerung Fernseh,monitor
Blockschaltbild eines Video-Datensichtger~ites mit codierter Bildelementspeicherung
Der Bildwiederholspeicher hat eine Gr61~evon 512 Worten und kann also bis zu 512 Bildelemente speichern. Der lnhalt diesesSpeichers wird w~hrend einer Fernsehzeile (64/~s) komplett bearbeitet und die dabei gewonnene Bildpunktinformation der jeweils n~chsten Fernsehzeilewird zwischengespeichert. Der Zwischenspeicher besteht bei z.B. 384 Bildpunkten einer Zeile aus 384 Worten mit z.B. je 3 bit fiJr 7 darstellbare Farben. Yon diesen Speichern werden zwei ben6tigt, die als Wechselpuffer abwechselnd dutch wahlfreie Adressierung von den Zeichen- und Vektorgeneratoren gefiJltt (folgende Zeile) bzw. mit fortlaufender Adressierung zur Bild-Erzeugung ausgelesenwerden (aktuelle Zeile). F~ir die Bearbeitung jedes Wortes des Bildwiederholspeichers stehen bei 512 Worten und 64/zs Gesamtzeit nur ca. 100 ns zur Verf~ung, bzw. die Bearbeitung mug in Taktschritten yon ca. 100 ns Dauer erfolgen. Mit geringem Aufwand sind in einer so kurzen Zeit nur einfache Operationen mSglich, z.B.: -
-
PrLifung,ob Teile des Bildelementes in die n~chste Zeile fallen evtl. Adressierung des Zwischenspeichersaufgrund der gespeicherten X-Koordinaten evtl. Zeilen-Adressierung der Zeichengeneratoren aufgrund der gespeicherten Y-Koordinaten und der Y-Koordinate der zwischenzuspeichernden Zeile Lesender Zeichengeneratoren und Bildpunk~ransfer in den Zwischenspeicher.
219
Diese Operationen sind in der gegebenen Zeit durchfiJhrbar. Wesentlich aufwendiger w~re eine echte Berechnung der Punkte einer Linie aus ihrem Anfangs- und Endpunkt. Da beliebig gerichtete Linien zumindest in den unter.,~JchtenAnwendungsbeispielen nur sehr selten vorkommen (mit Ausnahme der h~ufig ben6tigten senkrechten und waagerechten Linien), wird in der einfachsten Ausbaustufe eine Linie aus kurzen Segmenten zusammengesetzt, deren Verlauf einem Symbolgenerator fLir ein Fetd yon 8 x 8 Punkten entnommen wird. Ein solches Bildelement besteht also aus h6chstens 8 Punkten und wird durch seinen Anfang und den relativen Endpunkt ( - 7 bis + 7 Punkte in X- und Y-Richtung ) beschrieben. Waagerechte und senkrechte d6nne Linien oder Balken k6nnen dagegen eine beliebige L~nge besitzen, ihre Erzeugung erfolgt nach einem anderen Prinzip. Ein Datensichtger~it nach diesem Verfahren ben6tigt zwar sehr hohe interne Datenbearbeitungsgeschwindigkeiten, erlaubt andererseits aber beliebige farbige grafische Darstellungen aller Art mit relativ geringem Speicheraufwand und clamit auch geringen Kosten und geringem Bauvolumen. Seine Besonderheiten sind im einzelnen: -
echte farbige grafische Darstellungen mit geringem Speicheraufwand
-
Erweiterungen auf beliebig viele Farben und Gr.austufen mit jeweils nur geringer Speichererweiterung
-
schneller Datentransfer, da jeder Platz des Bildwiederholspeichers alle 64 #s zur VerfiJgung steht und da die Reihenfotge der Daten im Bildwiederholspeicher ohne Bedeutung ist
-
einfacher Bildaufbau, z.B. Vorgabe eines Balkens durch nur ein Wort und nicht aus einzelnen fl~chigen Teilsymbolen zusammengesetzt
-
gemeinsame Bildmanipulationen (z.B. L6schen, Verschieben) von mehreren Bildelementen durch zus~tzliche Kennzeichnung zusammengeh6riger Bildelemente auf einfache Weise m6glich
-
beim L6schen und Verschieben von einzelnen Bildelementen kein Mitl6schen geschnittener Punkte anderer Bildelemente
-
Erweiterungen zu trickfilm~hnlichen fl§chigen Darstellungen auf einfache Art m6glich, indem zum Beispiel Liniensegmente als linke bzw. rechte R~inder einer Fl~che bezeichnet und weiterverarbeitet werden.
5. GEGENOBERSTELLUNG VON VIDEO-DATENSICHTGERATEN UNTERSCHIEDLICHER
A U S -
F O H R U N G S F O R M E N
Vergleicht man die fLinf verschiedenen AusfLihrungsformen fLir Video-Datensichtger~ite nach ihren Leistungen und dem erforderlichen Hardware- und Software-Aufwand, so zeigt sich, daiB Displays mit zeichenplatzorientierter Speicherung entsprechend 4.2 und 4.3 ausreichen, wenn 5berwiegend Texte, Tabellen etc. dargestellt werden sollen und wenn f(Jr eventuell ben6tigte grafische Darstellungen das relativ grobe und feste Zeichenraster nicht st6rt. Sind bildliche Darstellungen mit feinerem Raster und gr61~ererDynamik erwSnscht, so ist das in 4.6 vorgeschlagene Bildelemente-Display vorzuziehen, das in wenigen Anwendungsf&llen eventuell erweitert werden mul~. Ein herk6mmliches Bildpunktdisplay nach 4.5 ist wegen des wesentlich h6heren Speicheraufwandes und damit gr6Eerer Bauform und h6herer HerstelI- und Wartungskosten nur bei sehr grol~r Informationsdichte auf dem Bildschirm sinnvoll und wenn die Zeit fSr den Bildaufbau wenig Bedeutung besitzt. Das ist der Fall bei komplexen Grafiken (z.B. Computer Aided Design), fLir die jedoch Video-Displays wegen ihrer Rasterung und der schlechten Aufl6sung nur in seltenen F~llen geeignet sind.
220
6.
LITERATURVERZEICHNIS
1
AMELI NG, W.; ASSELN, J.: Digitale Speicherung von Graphiken und Kurven und deren Darstellung auf Datensichtger~ten. Nachrichtentechn.Z. 25, K209-K213 (1972)
2
AMELING, W.; REIMEN-TOMASKOVA, V.: 8ymbolgeneratoren zur Darstellung yon Schaltkreisen bei Datensichtger~itennach dem Fernsehprinzip. Nachrichtentechn.Z. 25, K148-K152 (1972}
3
AMELING, W.; SCHMIDT, M.: Bildwiederholspeicher und Zeichenerzeugungbei Datensichtger~ten nach dem Fernsehprinzip. Nachrichtentechn.Z. 25, K114-K118 (1972)
4
AMELING, W.; ZIMMERMANN, R.: Prinzipien und Kenngr61~ender Funktionseinheiten von Datensichtger~ten. Nachrichtentechn.Z. 25, K89-K92 (1972)
5
AMELING, W.; ZIMMERMANN, R.; SCHMIDT, M.: Eingabe- und Bedienungselementevon Datensichtger~ten. Nachrichtentechn.Z. 25, K178-K182 (1972)
6
AUMAYR, G.; BINDEWALD, K.; KORNER, H.: Bildschirmeinheiten fiJr die Siemens-Prozel~rechner 320 und 330. Siemens-Zeitschrift 47, 546-552 (1973)
7
BISHOP,P.G.: Display and input software for on-line control. DISPLAYS, lEE Conf. Publ. 80, 19-26 (1971)
8
BRYDEN, J.E.: Visual display systems. Telecommunications 6, 22-31 (5/1972)
9
DAVIS, S.: Computer data displays. Englewood Cliffs: Prentice Hall 1969
10
GOODSTEIN, L.P.: Operator communications in modern processplants. DISPLAYS, lEE Conf. Publ. 80, 149-t53 (1971)
11
GRABMAIER, J.G.; KROGER, H.H.: FItissigeKristalle, Grundlagen und technische Anwendungen. V D I-Zeitschrift 115, 629-638 (1973)
12
HENDRICKSON, H.C.: A highprecision display system for command and control. AG A R D-CP-23, 235-245 (1969)
13
JOHNSON, E.A.: Touch displays: a programmed man-machine interface. Ergonomics 10, 271-277 (1967)
t4
KAWARADA, H.; OHSHIMA, N.: DC-electroluminescent materials for flat-panel TV display. Proc. of the IEEE 61,907-915 (1973)
15
KELLEY, C.R.: Display layout. In: Displays and Controls. Amsterdam: Swets & Zeitlinger 1972, 41-52
t6
KORNEI, T.V.: The graphic video generator. Computer, 35-38 (4/1973)
17
KRAISS, K.F.: Technische und anthropotechnische Probleme elektronischer Anzeigen. INTERKAMA 1971. Mtinchen: Oldenbourg 1972, 182-191
18
KREITZER, N.H.; FITZGERALD, W.J.: A video display for image processing by computer. IEEE Transact. on Comp. C-22, 128-134 (1973)
19
KROGER, U.; PEPPERL, R.; SCHMIDT, U.J.: Electrooptic materials for digital light beam deflectors. Proceedingsof the IEEE 61,992-1007 (1973)
20
KORNER, H.: Kurvensichtger~te fur Prozel~rechner.Regelungstechn.Praxis15, 80-85 (1973)
21
MARTIN, A.F.: Penetration color tubes are enhancing information displays. Electronics, 155-160 (1973)
22L
22
MOTT, E,M.: A transparent touch screen device for interactive computer-graphics displays. Rutherford High Energy Laboratory, Febr. 1972
23
FIAO, K.C.M.: The use of computer driver~displays in the supervision and control of large power systems, D ISPLAYS, I EE Conf.Publ. 80, 277-282 (I 971 )
24
RI DSDALE, B.: The non-specialist user and the computer terminal, lEE Conf.Publ. 68, 102-112 (1970)
25
SCHMIDT, M.; AMELING, W,: Erzeugung von Videosignalen f{Jr Datensichtger~te. Nachrichtentechn.Z. 25, K153-K156 (1972)
26
SH ER R, S.: Fundamentals of display system design, New York: Wiley I nterscience 1970
27
SHERR, S.: Technology and equipment. SID-Symposium New York, 1973 Symp. Digest, 172-173
28
THORNHI LL, D.E.; CHEEK, T.B.: Raster-scantube adds to flexibility and lower cost of graphic terminal. Electronics, 95-10i (7, Febr. 1974)
29
ZEIDLER, H.: Datensichtger~te auf dem deutschen Markt. Computer Praxis, 109-113 (1972)
30
ZIMMERMANN, R.: Anwendung eines Fernsehger~tesals Anzeigeeinheit einer Datensichtstation. Nachrichtentechn.Z. 25, K93-K99 (t972)
31
ZIMMERMANN, R.; AMELING, W.: Das Angebot von Datensichtger~ten auf dem deutschen Markt. Nachrichtentechn.Z. 25, K229-K234 (1972)
32
ZIMMERMANN, R.; AMELING, W.: Datensichtger~te in Video-Kommunikationssystemen. NTZ-Report 15, 58-61 (1973)
33
ZIMMERMANN, R.; BUSSMANN, W.-D.; SCHMIDT, M.; AMELING, W.; EFFERT, S.: R6ntgenvideometrische Verfahren zur Ventrikelvolumenbestimmung unter Verwendung eines Video-Lichtgriffels und digitaler Konturenspeicher. Biomedizinische Technik 18,124-132 (1973)
34
ZIMMERMANN, R.; ETSCHBERGER, K.: Optische AnzeigesystemefLir Prozel~warten.PDVBericht 19. Karlsruhe: Gesellschaft fLir Kernforschung 1974
35
Conference on Displays. lEE Conf,Pubh 80 (1971)
36
Datensichtger~te: Grundlagen, Aufbau, Anwendungem NTZ-Report 15. Berlin: VDE-Verlag 1973
37
Special Issueon Information Display Devices. I EEE Trans. Electron. Dev. ED-18,613-832 (9/1971)
38
Special Issueon New Materials for Display Devices. Proc. of the I EEE 61,804-t056 (7/1973)
39
The Computer Display Review. GML corporation, Lexington USA (1973)
FREQUENZANALOGES PROZESSFOHRUNGSSYSTEM H. Kalis, M. Klinck, G. Landvogt, J. Lemmrich (Vortragender), G. SchrSder
Zus~mmenfassung Einf6b_rend wird das ubliche Proze~instrumentierungssystem beschrieben und seine Aufgaben werden erlautert. Ihmwird ein frequenzanaloges Proze~instrumentierungssystem gegen~bergestellt. Es benutzt als informationstragende GrS~e die Frequenz elekt~ischer Signale und zeichnet sich daher dutch besondere Storsicherheit und einfache Digitalisierbarkeit der Proze~signale aus. Anhand einer Tabelle mit verfugbaren frequenzanalogen Instrumentierungskomponenten wird die Vollstandigkeit des Instrumentierungssystems diskutiert. Einen besonderen Vortell der frequenzanalogen Signaldarstellung bietet die Moglichkeit, neuartige DDA-Prozessoren mit Proze~rechnern zu koppeln. DDA-Elemente benutzen Frequenzsignale. Sie arbeiten parallel und quasikontinuierlich, so da B komplexe dynamische Vor~Auge bis ca. 60 Hz in Echtzeit gerechnet werden kSnnen. Abschlie~end werden Gesichtspunkte zur praktischen Ein~tuhrung eines frequenzanalogen Proze~instrumentierungssystems besprochen. Es ergibt sich eine gute Kompatibilitat mit rein digitalen bus-line-Systemen. Eine Kombination beider Systeme empfiehlt sich in Zukunft dort, wo ausgedehnte Systeme in stark gestorter Umgebung betrieben werden mussen. I. Aufbau und Eigenschaften konventioneller Proze~f'uhrungssysteme Wegen der Komplexit~t vieler industrieller Prozesse ist eine Steigerung ihrer Wirtschaftlichkeit nur durch eine umfassende Automatisierung unter Einbeziehung von Rechenanlagen moglich. Daher werden Proze~rechner zur Realisierung technisch-wirtschaftlicher Forderungen wie: gro~tmoglicher Wirkungsgrad und beste Ausnutzung der Gesamtanlage, optimaler Betrieb von Teilanlagen, hohe und reproduzierbare Qualitat der Produkte und geringstmogliche Beeintrachtigung der Umwelt eingesetzt. Daneben werden von ihnen auch ~bergeordnete Aufgaben f~r Organisation und Verwaltung bearbeitet° Proze~rechner wurden erst nachtraglich an schon vorhandene analoge Instrumentierungskonzepte E 11 angekoppelt. Auf diese Weise hat sich alas in Bild I dargestellte Proze~f'6hrungskonzept herausgebildet°
223
Ubertrogungsleitung
Sensoren
I ~T
tt
Mel3stellen-
I I
t
i ....
/
I-~ &
Proze~
Digitole\Signole_ -/
I
TI[
I
~
--
Ste!Igliede;
L
I I
I~ ....
i
~
~rozeN"echnel
I Abtast- und I Haltekreise n-
P3O-Regler jI
l / Signalkonver ter
U
NI-
I
Bild S: Gebrauchliches Proze~instrumentierungssystem Mit ihm versucht man, alle mit der Automatisierung zusemmenhangenden Teilaufgaben zu losen. Seine Funktion soll im folgenden kurz beschrieben werden: Die analogen Me~werte gelangen uber parallele Signalleitungen zur Proze~warte; dort werden sie digitalisiert und im Rechnerspeicher abgelegt. Das Rechnerprogrnmm verknupft sie nach aufgabenspezifischen A1gorithmen mit vorgegebenen Eingabedaten. Als Ergebnisse stehen Informationsdaten, Sollwerte, Parameterwerte oder Stellgro~en zur Verfugang; diese werden - wiederum auf parallelen Kan~len - entweder direkt zu den Ausgabegeraten geleitet oder in Analogwerte umgewandelt und dann den Reglern und Stellgliedern zugefuhrt. Der Proze~fuhrung mit Rechnern liegen mehrere Aufgabenkategorien zugrunde: I. Me~werterfassung und -verarbeitung (z.B. Speicherung, Filterung, Skalierung, Grenzwertkontrolle, Alarme usw.) 2. Proze~ablaufsteuerung 3. Proze~regelung, u.a. \ 3.1. DDC - bei Annahme fester Regelkreisparameter 3.2. SSC J
224
3.3. DDC mit adaptiven Regelalgorithmen zur optimalen, vom Arbeitspunkt unabhangigen Proze~regelung. Diese typischen Aufgaben lassen sich mit unterschiedlichem Ergebnis von dem beschriebenen P r o z e ~ h r u n g s s y s t e m erfullen: 2u I. Durch Einsatz prBziser Me~aufnehmer k a n n m a n die Me~werte mit befriedigender Genauigkeit erfassen. Jedoch stellen der Me~stellenumschalter und der A/D-Wandler sehr kritische Glieder dar. Den analogen Signalen kSnnen sich zudem insbesondere auf langen Obertragungsstrecken StBrungen uberlagern, die sich nur schwer wieder herausfiltern lassen. Die vielen paral!elen Obertragungskan~le verursachen gro~e Investitionen. Die Konzentration elektrischer Komponenten an einem Ort (z.B. Me~warte) bereitet bei umfangreichen Systemen Schwierigkeiten. Die A-D-Wandlung wird u.U. mit einer im Verhaltnis zur Proze~dynamik relativ geringen Wiederholungsrate ausge~tuhrt. 2u 2. Proze~ablaufsteuerungen lassen sich oh~e Schwierigkeiten mit guten Ergebnissen realisieren. Zu 3. Prozesse mit bekannten bzw. festen Regelkreisparametern kSnnen im allgemeinen problemlos nach dem DDC-Verfahren geregelt werden; aus Gr~nden der Betriebssicherheit, ~ersichtlichkeit usw. zieht man aber haufig "supervisory setpoint control", "(SSC)" vor. Die oft proklamierten adaptiven Regelmethoden mit on-line-Identifikation und Reglerstruktur- und Reglerparameterumschaltung, erlauben zwar eine echte Optimierung, erfordern jedoch eine au~ergewohnlich hohe Rechengeschwindigkeit. Dies liegt an der seriell-iterativen - und damit zeitraubenden - Arbeitsweise von Proze~rechnern, die sich besonders bei der ~6sung von Differentialgleichungen bemerkbar macht. Man setzt daher manchmal ~ur Jede Regelkreisoptimierung je einen Kleinrechner ein. Damit steigen der hardware- und der software-Aufwand des Gesamtsystems. Die Ausgangssignalwandlung ins Analoge und die 0bertragung zu den Reglern bzw. Stellgliedern ist naturlich mit ahnlichen Mangeln behaftet wie auf der Me~seite. Diese kritische Betrachtung zeigt, da B wichtige Proze~f6hrungsaufgaben heutzutage nur unbefriedigend gelost werden kSnnen. Dies liegt weniger an mangelhaften Komponenten, sondern an dem einmal zugrundegelegten Konzept.
225 2. Alternativsystem mit frequenzanaloger Signaldarstellung
Benutzt man als Signaltr~ger ~ur die Proze~variablen nicht die Amplitude, sondern die Frequenz, so l ~ t sich ein "Frequenzanaloges Proze~instrumentierungssystem" aufbauen (s. Bild 2), das vielerlei technische Vorteile gegen~ber dem konventionellen Instrumentierungssystem attfweist [ 2 - 4 ] .
Frequ.-anal. Sensoren oder Konverter
Obertrogungsleitung
F/D- Konvers. Zahler Puffer ^
I
i'
J Frequ"onol~qL[1 I Signole I~ I
--ProzeN!
_r ' ~
,,
~ F ~ r e q u - - o n a ~ fi
J
1
Prozer}rechner
I-. -.
' - - - o~iog__~r-A_jzo~otzJ_.
S~ellglieder
"E
~,
I
Signalkonverter
Bild 2: Frequenzanaloges Proze~instrumentierungssystem I. Frequenzanaloge (d.h. frequenzmodulierte) Signale sind weitgehend unempfindlich gegen au~ere elektrische Storungen, denen sie insbesondere auf langen 0bertragungswegen ausgesetzt sind. Der Gewinn an Storbefreiung verglichen mit ausschlagsanalogen Signalen ist durch den Faktor Af/fg (Af = Frequenzhub, fg = in der Proze~gro~e enthaltene Signalfrequenz) gegebenund kann den Wert 100 ubersteigen. 2. Leitungsparameter und alterungs- bzw. umweltbedingte Veranderungen von Bauelementen haben kaum Einflu~ auf die Genauigkeit von Systemkomponenten. 3. Die Digitalisierung (Demodulation) frequenzanaloger Signale bereitet heutzutage wegen des vielseitigen Angebots an hoher integrierten
226 Digitalkomponenten keine Schwierigkeiten. Das geringe Bauvolumen und die Preiswurdigkeit der dafur einzusetzenden 2ahlschaltungen erlauben eine parallele Digitalisierung der Proze~variablen, d.h. man ordnet jedem Kanal eine eigene Digitalisierungseinheit zu. Dies hat eine Steigerung des Rechnerzugriffs zu aktuellen Daten, der ~ersichtlichkeit und der 2uverlassigkeit zur Folge. Im Gegensatz zur A/D-Wandlung entstehen bei der F/D-Wandlung station~rer Signale keine zusatzlichen Digitalisierungsfehler auger den typischen Torfehlern, die sich noch durch interpolierende Messung vermeiden lassen. Die Digitalisierung durch Auszahlen hat die Wirkung einer Tiefpa~filterung. Dies ±st ~6r die Unterdruckung von Storsignalen vorteilhaft. Um eine unerw~nschte Beelntr~chtigung der Proze~danymik durch diese Filterung zu vermeiden, mu~ die Ausz~hlperiode naturlich genugend klein sein gegenuber der Periodendauer des hSchstfrequenten Spektralanteiles der betreffenden Proze~grS~e. (Abtasttheorem). 4. Viele Proze~variable lassen sich direkt als frequenzanaloge Signale erzeugen, manche sogar erheblich genauer als auf analoge Weise (Drehzahl, Durchflu~); haufig ist eine Frequenz selbst Proze~variable und brauchtdann nat~lich nicht umgewandelt zu werden. Aus diesen technischen Vorz~gen ergeben sich unmittelbar folgende wirtschaftliche Vorteile: I. Es kSnnen preiswerte, ungeschirmte Vielfachkabel verwendet werden. Frequenzmultiplexverfahren konnen empfohlen werden, denn sie lassen sich ~ur frequenzanaloge Signale einfacher und preiswerter realisieren, als f ~ analoge Signale. Bei k~rzeren ~bertragungsstrecken sind aber Vielfachkabel mit einfach ausgenutzten Aderpaaren wirtschaftlicher und u.U. auch zuverl~ssiger. 2. Die gruyere 2uverlassigkeit (durch Fehlen der empfindlichen Me~stellenumschalter, der Abtast- und Haltekreise usw.) erspart Wartungsund Ausfallkosten. 3. Komponenten im frequenzanalogen Proze~instrumentierungssystem Um die Vorteile der frequenzanalogen Signaldarstellung konsequent nutzen zu konnen, mussen alle ~6r ein Instrumentierungssystem notwendigen Komponenten verfugbar sein. Tabelle I stellt eine - naturlich nicht vollstandige - Auswahl von Instrumentierungskomponenten dar, die jetzt schon verfugbar sind oder sich in der Entwicklung belinden. Sie £st untergliedert in Sensoren, Konverter, Stellglieder, Regler und Rechner.
227
Tabelle
1 : Komponenten
im Frequenzanalogen
Instrumentierungssystem
1. Sensoren 1.1Verlagerungsaufnehmer
: Ober IndukLivitAisversiimmung
1.2 Kraftaufnehmer
: mit schwingenderBlattfeder
1,3 G~schwindigkeitsaufnehmer
: z.B. Impulsgeberoder Orehfeldsysleme
1.4 OurchfluBmesser
: nachdem Ovalrad- oder Turblnenprtnzip
t.5 Frequenz
: als selbst~ndigeMeBgr~Be
2. Konverter 2.1Widerstands-Frequenz-Konverter
: harmonischer oder Relaxationsoszillator
2.2 Spannungs-Frequenz-Konverter
: Relaxationsosztllator
2.3 Kapazit~s-Frequenz-Konverter
: Relaxationsoszillator
2.k Frequenz-Digital-Konver~er
: Z~hlprinzlp~en
2.5 Digi~a1-Frequenz-Konver~er
: Einstellbare Teilung einer Taktfrequenz
2.6 S~ellgrBBen-Konver~er
: z.B. Frequenz.Oruckusw. (vgl. Stellglieder)
3, Stellglieder 3,1Schrittmotore 3.2 S~romrichter : Wechselrichter, Gleichstromsteller
3.3 geregelte elektrische An~riebe
4. Regler (Verwendungszweck:Einzelregler, %ack-up"-Regler) 4,10igitale Soltver~vorgabe k.2 Frequenzanaloge SolIwer~vorgabe : verallgemeinertes "Phase-lock"-Prinzip
5. Rechner 5.10igl~alrechner 5.200A-Rechner
228
Die Aufstellung der Sensoren zeigt, dab es ft~r viele wichtige Proze~gro~en Wandler mit unmittelbarer Umsetzung in eine Frequenz gibt. Problematisch hierbei ist jedoch, da~ diese Sensoren haufig nicht f6r alle Me~bereiche zur Verfugung stehen, gewissen technischen Anforderungen wie Dynamik, Genauigkeit, Robustheit usw° nicht genugen oder zu teuer sind. 2ukunftige Arbeiten auf dem Gebiet der frequenzanalogen Proze~instr~mentierungmussen sich daher zielbewu~t mit der Untersuchung von Sensoren befassen. Die Ergebnisse werden naturlich allen rechnergef6hrten Instrumentierungssystemen zu Gute kommen. Sollen Proze~variable erfa~t werden, fur die keine unmittelbare Umwandlung in eine Frequenz moglich ist, so konnen konventionelle Analogsensoren mit Signalkonvertern kombiniert werden° Dieser Weg ist sehr aussichtsreich, denn viele bew~hrte Sensortypen lassen sich mit Konverterschaltungen zu einem vorteilhaften Aufnehmer verschmelzen. Beispiele hierf6r sind Schaltungen mit Dehnungsme~streifen, Halbleiterthermometern, Feldplatten usw. Die Arbeiten an Sensorproblemen reichen daher in das Gebiet der Konverter hinein° Frequenz-Digital-Konverter und Digital-Frequenz-Konverter stellen die Koppelelemente zwischen Rechner und 0bertragungsstrecke dar. Neben der eigentlichen Signalkonversion besteht auch die MSglichkeit einer Skalierung. Skalierungsbeiwerte konnen vom Rechner vorgegeben werden. Viele Stellglieder arbeiten inkrementell oder sind als Schaltverstarker ausge~6hrt. Es ist daher prinzipiell nicht schwierig, sie in ein frequenzanaloges Instrumentierungssystem einzupassen° Dies gilt - wie die Tabelle zeigt - insbesondere fur elektrische Antriebe und Stromrichter. Falls es unumganglich ist, ein Stellglied mit einem Analogsignal anzusteuern, so kann auch hier ohne weiteres ein Konverter eingesetzt werden. Es hat sich als vorteilhaft erwiesen, selbstandige Regler in einem Proze~instrumentierungssystem beizubehalten° Fur frequenzanalog gemessene Proze~variable bieten sich Regler mit digitaler oder frequenzanaloger Sollwertvorgabe an. Diese Regler lassen sich ~berwiegend mit Bauelementen der Digitaltechnik realisieren. Sie bieten gegenuber analogen Reglern eine Reihe yon Vorteilen wie z.B.: keinen Abgleich in der Fertigung, beliebig gro~e Integrierzeiten, fehlerlose Integration und keine Offset- und Drifterscheinungen.
229 Um dem Proze~rechner die Aufgabe der Proze~optimierung zu erleichtern bzw. uberhaupt erst zu ermSglichen, sollte man ihn mit einem DDA-Zusatzrechner koppeln *) (s. Bild 3).
DatenundAdressen I
i,
•~
ProzeN-Rechner
--T-~-~-T--
//
Standard Peri pherie
ODA-Zusatz
o °
.... I
Prozen -
TT ..... T------verbindg.
__~__L_L_J~_~requenz ! ~ a n a l o g . ~
~
Prozen
-
Idigital}
1
Bild 3: Kopplungsschema fur DDA-Rechenwerk, Proze~ und Proze~rechner Der DDA-Rechner kann als Bestandteil des Standard-Interface-Systems betrachtet werden [5]. Er besteht aus steuerbaren 2ahlern und Teilern, die bezuglich ihrer Ein- und Ausgangssignale (Frequenzen bzw. Zahlenwerte) je nach Schaltungsart als Integrator, Multiplizierer, Summierer, Komparator, Potentiometer, Totzeitglied usw° arbeiten konnen. Durch die Verkopplung dieser Elemente untereinander uber je zwei Leitungen (Impulse + Vorzeichen), die auch vom Digitalrechner progr~mmgesteuert ausgeftuhrt werden kann, lassen sich dynamische Schaltungen gleich denen auf dem Analogrechner realisieren. Die Verbindung zum Rechner erfolgt uber einen Digitalbus; der Proze~ wird parallel wahlweise frequenzanalog, digital und auch analog angekoppelt. Durch genugend hohe AmflBsung und Taktfrequenz erreicht man quasikontinuierliche Arbeitsweise. Die Vorteile des Analogrechners: kontinuierliche und parallele Verarbeitung und deswegen hohe Rechengeschwindigkeit werden bei diesem System beibehalten, wahrend dessen Nachteile:
*) DDA ist die Abkurzung f~r digital differential analyzer
230 Drift, fast ausschlie~lich manuelle Bedienbarkeit und schlechte Koppelmoglichkeit mit dem Digitalrechner entfalleno Eine Proze~optimierung mit Identifizierung kann nun zoB. einfach durch Modellbildung im DDA-Teil durchgef6hrt werden. Die DDA-Parameter konnen jederzeit vom Proze~rechner gesteuert und die Modell-Signale a b g e r u f e n u n d verarbeitet werdeno Neben vie len anderen Anwendungen lassen sich mit dem DDA-Teil nat~rlich auch Reglerfunktionen bilden. Mit diesem Rechnerverbundsystem last sich eine vorteilhafte progr~mmgesteuerte Arbeitsteilung zwischen beiden Rechnern aus~uhren: Ablaufsteuerungen und arithmetische Operationen werden vom Digitalrechner, dynamische Probleme bis zu einer Grenzfrequenz von ca. 60 Hz in Echtzeit vom DDA-Rechner bearbeitet. 4. Einfuhrung eines frequenzanalogen Proze~instrumentierungssystems Teilaspekte des beschriebenen Systems werden schon seit langerem genutzt [6]. Auch werden mehrere der hier aufge~uhrten Komponenten in der Praxis mit gro~em Erfolg eingesetzt [7]. In allen Anwendungsf~llen handelt es sich aber entweder um einzelne Komponenten, die unmittelbar an Signalkonverter gekoppelt sind oder bestenfalls um ein Teilsystem z.B. eine Me~kette. Um das frequenzanaloge Proze~instrumentierungssystem erfolgreich einzu~uhren, mussen noch einige Voraussetzungen geschaffen werden: I. Es sollten einige Pilotprojekte aufgebaut werden. A r b e i t e n u n d Untersuchungen an solchen Projekten decken Lucken auf und bringen wertvolle Erfahrungen. 2. Es mussen f6r die ganze Anwendungspalette S e n s o r e n u n d Stellglieder verfugbar sein bzw. vorteilhafte Kombinationen mit Konvertern empfohlen werden kSnnen. 3. Man sollte einen Normfrequenzbereich f6r die Proze~signale schaffen ahnlich der Norm (z.B. 4 - 20 mA) f6~ analoge Signale. Wie vertr~gt s~ch nun ein frequenzanaloges Proze~instrumentierungssystem mit dem yon verschiedenen Seiten vorgeschlagenen digitalen bus-line-System? Ein bus-line-System erscheint dannvorteilhaft, wenn die z u u b e r m i t telnden Daten schon konzentriert v o r l i e g e n u n d die S~mmelleitung au~erdem nicht durch eine von StSrungen zu stark verseuchte Umgebung
231 f~hrt ~8]. Zukunftige Proze~instrumentierungssysteme sollten dsher in einer Hybridform die Vorteile der Frequenzanalogietechnik nutzen (s.
Bild
4,).
Konverter
Rechnerinterfac~ ~rozefl rechner
ProzeN
digitale 'busline'
groNe Distanz
~ild 4: Hybrides Proze~instrumentierungssystem Frequenzanaloge Signale ubertragen die Proze~information zwischen dem starker gestorten Proze~ und festgelegten S~mmelstellen. Dort findet die F/D- bzw. D/F-Konversion statt; der Informationsaustausch mit dem Rechner verl~uft von hier an digital. Diese Struktur ist vorteilhaft, well sowieso ein Tell der Proze~signale in Frequenzform vorliegt und bei einem anderen Teil die Digitalwandlung uber Frequenzkonversion ausgefuhrt werden kann. Durch Verlagerung der Schnittstellen: F/D- bzw° D/F-Konversion vom Rechner zum Proze~ erhalt man e i n e n ~ e r g a n g vom frequenzanalogen zum rein digitalen Proze~instrumentierungssystem. F~gt man die Schnittstelle in den Ubertragungsweg ein, so stellt dies das eben erlauterte Hybridsystem dar. Die Frage, welche dieser Strukturen im Einzelfall einem Proze~instrumentierungssystem zugrundegelegt werden soll, ist daher hauptsachlich eine Frage der Schnittstellen und nicht so sehr der Komponenten.
232 Aus heutiger Sicht kannman als naheliegende Alternative zum konventionellen Proze~instrumentierungssystem ein frequenzanaloges Proze~instrumentierungssystem empfehlen, da nur dieses ein stSrungsfreies und wirtschaftliches Arbeiten im Hinblick auf die eingangs gestellten Forderungen gewahrleistet. Fur ausgedehnte Systeme stellt die hybride, frequenz-analog-digitale Struktur in Zukunft, wenn alle offenen Fragen der sicherenundwirtschaftlichen Signal~bertragung auf "bus-lines" geklart sind, eine optimale LSsung dar; ~ur kleine Systeme hingegen sollte auch spater das frequenzanaloge Proze~instrumentierungssystem am g~ustigsten sein. LITERATUR [1] Anke, K., Kaltenecker, H., 0etker, R.: Proze~rechner, Verlag O1denbourg 1970. [2] Gossel, D.: Frequenzanalogie - ein Konzept fur Me~- und Regelsysteme mit digitaler Signalverarbeitung. ET2-A, Bd. 93, (1972) H. 10. [3] Landvogt, G., Meyer-Ebrecht, D.: Frequency Analogy, a Powerfull Tool for Process Instrumentation. Proceedings of the IFAC 5th World Congress, Paris 1972. [4] Landvogt, G., Schroder, G.: Frequenzanaloges Instrumentierungssystem, rtp 16, (1974), H. 4. [5] Kalis, H.: Ein DDA-Proze~rechner-Zusatz ~6r Proze~automatisierungszwecke. Lecture Notes in Economics and Mathematical Systems, Bd. 93, S. 195-206, Springer Verlag 1974. [6] Steinhauer, J.: Elektromechanische Waagen mit frequenzanalogen Me~wandlern. rtp 15 (1973), H. 3, S. 65-71. ~7] Haug, M.: Frequenzanaloge Messungen mit Widerstandsaufnehmern, der Elektrotechniker, H. 5/73, S. I-6. [8] Meyer-Ebrecht, D., Schroder, G.: Rechneranpassung frequenzanaloger Me~systeme. Vortrag a u f d e m 6. Kongre~ der IMEKO, Dresden, 17. bis 23. Juni 1973.
SPEZIFISCHE
EIGENSCHAFTEN
TIERUNGSSYSTEMS F.Freyberger,
EINES
Ch.GeiBler,
FUr
eine w i r t s c h a f t l i c h e ,
mit
ProzeBrechnern
sind
nenten wesentliche analogen
digitalen
Wunschbild Stand
Eine
nur
in D i g i t a l s i g n a l e
sehr
gegenw~rtig
direkt
Frequenzsignale
einfacher
Gbliche
se D b e r l e g e n h e i t signale
begritndet,
len mit
den Vorteilen
andrerseits
in der
Schaltkreise,
die
einerseits
die
es
steh t w o h l
Gesichtspunkt in d e r
und dynamischer Anhand
einiger
prozeBrechnergefLhhrten aufgezeigt
werden.
und integrierende Probleme seizers
eines
erfGllen
StSr-
als das Die-
der F r e q u e n z -
von Amplitudensigna-
Signaldarstellung
zu k o m b i n i e r e n ,
Technologie
elektronischer
notwendigen
Umformungen,
zu v o l l z i e h e n .
yon Frequenzsignalen statischer
Umset-
E i n entbe-
(Genauigkeit)
Anforderungen. spezifische
Eigenschaften
Instrumentierungssystems
Die b e i d e n
der K o n z e p t ~ o n und
Mitteln
Ein Instrumentie-
Zwischenstellung
Austauschbarkeit
sollen nun
Filterung
einfachen
Zuverl~ssigkeit,
besser
wirtschaftlich
(Umsetzzeit)
be-
zum Pro-
zukiinftig die A n f o r d e r u n g e n
~dr den E i n s a t z
einfachen
Beispiele
alle
ProblemlSsung
mi%
die V o r t e i l e
fortschrittlichen es g e s t a t t e t ,
zu v o l l z i e h e n .
Die v o m P r o z e B
kSnnen
wirt-
Instrumentierungssystem.
in der
erlaubt,
zungen und Rechenoperationen scheidender
Umsetzung
Genauigkeit,
der d i s k r e t e n
erst
Diesem
und StellgrSBen
erachtete
SignaiGbertragung
amplitudenanaloge
±st
umzusetzen.
und umgekehrt. kann
yon direkt
es n a c h d e m g e g e n w i r t i g e n
MeB-
aussichtsreich
Wirtschaftlichkeit,
und
dab
digitale
werden
die F o r d e r u n g ,
mit Hilfe
u n d die R e c h n e r s i g n a l e
der F r e q u e n z s i g n a l e .
umgesetzt
ProzeBftthrung
Instrumentierungskompo-
resultiert
StellgrSBen
wenige
mit Frequenzumsetzung
hinsichtlich sicherheit
einige
die
dbertragenen
rungssystem
optimale
Prozesses
die T a t s a c h e ,
fGr
sich der T e c h n i k
zeBrechner
eines
in a n a l o g e
ist,
fGr
Daraus
in Digitalsignale
widerspricht
mGglich
und
digitalfreundliche
am S t e l l o r t
gegenwirtig
dient
zuverlissige
Betriebsvariablen
der T e c h n i k
schaftlich
mit F r e q u e n z u m s e t z u n g
Voraussetzung.
MeBumformern
unmittelbar
INSTRUMEN-
H.-R.Trinkler
1. I n s t r u m e n t i e r u n g s s y s t e m
die
PROZESSRECHNERGEFOHRTEN
MIT FP~QUENZUMSETZ~G
ersten
Beispiele
mit
und Realisierung
frequenzge~dhrten
eines
Frequenzumsetzung
behandeln
bei Frequenzsignalen.
eines
Abtastfehler
AnschlieBend
werden
Digital-Fr~quenz-Um-
Servok~eises
behandelt.
234
2. A b t a s t f e h l e r bei der F r e q u e n z - D i g i t a l - U m s e t z u n g Der r e l a t i v e A b t a s t f e h l e r Fre I b e r e c h n e t s i c h bei der V e r w e n d u n g nes e i n f a c h e n H a l t e k r e i s e s
in F o r m eines d i g i t a l e n S p e i c h e r s
ei-
zu
sin(~To/2 )
Frel
=
~To/2
1 = si(~
f/fo)
-
1
D a b e i b e d e u t e n f die h G c h s t e M e g f r e q u e n z u n d f o = I / T o die A b t a s t f r e quenzo
Dutch Reihenentwicklung
(~: e/fo)2
Fre I = F~r f < fo genGgt wicklung.
3;
(re/fo)4 5
zur A u s w e r t u n g das
Man e r h ~ l t
Abtastfrequenz
+
ergibt s i c h fthr d e n A b t a s t f e h l e r
found
...
I
erste G l i e d d i e s e r R e i h e n e n t -
so die h ~ c h s t e M e 6 f r e q u e n z
f als ~ t i o n
der
des z u l ~ s s i g e n r e l a t i v e n F e h l e r s Fre I zu
I f/fo- = --
~ ! Frel
Die g r a f i s c h e A u s w e r t u n g n a c h B i l d
I l~Bt erkermen,
dab z.B. bei ei-
n e m z u l ~ s s i g e n r e l a t i v e n F e h l e r y o n - 5 . 1 0 -3 die h S c h s t e M e ~ f r e q u e n z 5,5 % der A b t a s t f r e q u e n z b e t r a g e n kann° Bei der F r e q u e n z - D i g i t a l - U m s e t z u n g
l a s s e n sich die A n f o r d e r u n g e n
die D y n a m i k
(Abtastperiode T o = Torzeit)
18sung
To )-I in e i n f a c h e r W e i s e g e g e n s e i t i g a u s t a u s c h e n .
( Af
Tatsache,
der b e s o n d e r s
im A n f a h r b e t r i e b
Eine
gro~e B e d e u t u n g zukommt.
k a n n bei F r e q u e n z z ~ h l u n g u n d k o n s t a n t e r F r e q u e n z s p a n n e b e t r i e b die A b t a s t p e r i o d e
an
und an die e r r e i c h b a r e A u f -
~f
So
im A n f a h r -
z u g u n s t e n der D y n a m i k tun e i n e n b e s t i m m t e n
F a k t o r k v e r r i n g e r t werden.
Im g l e i c h e n M a 6 e
B e i m ~Tbergang zum N o r m a l b e t r i e b
sinkt d a n n die A u f l S s u n g .
steht d a n n bei der u r s p r G n g l i c h e n Ab-
t a s t p e r i o d e die fGr eine o p t l m a l e P r o z e B f ~ h r u n g n o t w e n d i g e hohe A u f 18sung wieder
zur V e r f G g u n g o
3. I n t e g r i e r e n d e
F i l t e r u n g be± s k a l i e r e n d e r
Ist das N u t z f r e q u e n z s i g n a l Frequenzhub
fm mit
fh f r e q u e n z m o d u l i e r t ,
f-D-Umsetzung
einer S t S r f r e q u e n z so b e t r ~ g t
fst bei e i n e m
der M o m e n t a n w e r t
der
Frequenz
~(t) : fm + fh ° ° s ( % t t ) Bei s k a l i e r e n d e r F r e q u e n z - D i g i t a l - U m s e t z u n g
w e r d e n w ~ h r e n d der T o t -
235 zeit
t
gerade
O
~N
Impulse
erzeugt.
Z~hlimpulse
in d e n A u s g a n g s z ~ h l e r ,
unterdrGckt
werden.
zeit
Es da
Im ung~instigsten
gelangen in e i n e m
Fall,
wenn
gerade symmetrisch zum F r e q u e n z m a x i m u m e sich der naeh der f-D-Umsetzung erhaltene
N = - No
+
fm
-to/2 = - N O + fmto
+ f h cos
nur
Vorzihler
t
gibt
jedoch
N
Tor-
kommt,
Zihlerstand
O
Impulse
o freilaufende
die
zu l i e g e n
mstt ) dt
N = ~%N-N
N
er-
zu
=
2f h +
sin(0~stto/2 ) ~st
Das Nutz-StSr-Verh~ltnis Fehler
unter
gangssignals. oberen
und
Die
ergibt
sich
Fehler
N F zu
die
dieser
also
aus
f2 - fl
NF
fh
Torzeit
t o ein
so e r g e b e n
sich naeh
Voraussetzung
sam und Anteile
sieh
der
aus
den Endwert ~f
Frequenzgrenzen
solutem
Nm
auf
Frequenzspanne
unteren
h~ltnis
Ist
bereehnet
Bezugnahme
dem reziproken
N=Nm=Z~f.t ° des
stellt f2 u n d
dabei fl
dem Quotienten
die
dar.
relativen
digitalen
Differenz
Das
Ausder
Nutz-St8r-Ver-
yon Bezugswert
N
und
m
ab-
~fstto sin ~fstto ganzzahliges
Bild ist
2 Pole also
die
modulierenden
Vielfaches
f~r
das
der
Periodendauer
Nutz-StGr-Verhiltnis.
integrierende StSrfrequenz
Filterung
ideal
fst w e r d e n
Tst , Unter wirk-
vollst~ndig
unterdrGckt. Bei
der Realisierung
reichende
Freiheitsgrade
zeitiger untere
Frequenzgrenze No -
Dutch
N=0
geeignete also
und
Bedingung auf
to
die
der
der
eine
Filterung gelten
notwendige
nimlich
die
Wahl
der
Skalierung
f2
=
t
integrierenden Vielfaehe
fl
Digitalsignal
Filterung
der
gleich-
obere
und
Nm+N o =
o
n
N o und
Anfangsfrequenz
i n das
aus-
Beziehungen
Voreinstellungen der
bei
F~ir d i e
Nm+N o f2
n Tst
verbleiben
Skalierung
durchzufthhren.
No -
Endfrequenz
ganzzahlige
Frequenz-Digital-Umsetzers
um
integrierender
fl
kann
eines
legt
Periodendauer
Tst
des
Faktors
in das
n=to/Tst
Ausgangssignal
N=N m erfolgen.
Die
lediglieh
die
n.Tst
$tSrfrequenz
der
Torzeit
lest. 4. D - f - U m s e t z e r
Die
Umse%zung
nach
der
dem Frequenz-Synthesizer-Prinzip
~ber
den
Da%enbus
vom
ProzeBrechner
gelieferten
t
o
236 Digitalsignale le g e s c h i e h t dynamischen Prozesses eine
in l i n e a r
abh~ngige
Ubertragungseigenschaften
angepaBt
sein.
Quantisierung
ausreichend.
Als
FUr h o h e
entsprechend
typischer
fGr v e r f a h r e n s t e c h n i s c h e angesehen
werden.
charakterisiert,
Die dab
ist
Umsetzers
steine Das
PLL)
Blockschaltbild
lel a n f a l l e n d e n
Pufferspeicher
aus N v u n d N k d i e n t N2,
der sich
eigentliche
Teiler
NI
Der PK,
tots
dutch
(locked
loop
Frequenz
Gber
muB
den Daten-
am E i n g a n g
ein
die E i n g a n g s -
wird nach
seiner Ab-
eine k o n s t a n -
gegebene
Wertever-
haben,
zur V o r e i n s t e l l u n g
wird
beide mu~
an-
des
in d e r R ~ e k f ~ h r u n g s s c h l e i -
Zihler
N2 b i l d e t
Phasenregelkreis
mit
d e m Kom-
setzt
sich
aus
TP und dem sparmungsgesteuerten
vergleicht
der g e w S h n l i c h
die
f r e f mit
Phase
Frequenzen
dutch
Oszillators
das A u s g a n g s s i g n a l zugefiihrt.
des
als den
dem dutch N2 herabge-
spannungsgesteuerten
Steuerspannung
des
VC0.
Phasenkompara-
D a im v e r r i e g e l t e n
am P h a s e n k o m p a r a t o r
der s p a n n u n g s g e s t e u e r t e
Nach
Zustand den glei-
Oszillator
die
f r e f ( N v + N k ) / N I abgeben.
~ndert
sich n u n das
stellt
s i c h a u c h d e r VCO
ein,
wird,
des
condition)
fref/N1
N
Phasenkomparator,
Referenzsignals
den TiefpaB
d e m V C O als
chen Weft
Der
ausgefthhrt
teilten Ausgangssignal Glittung
Der
dem TiefpaB
zusammen.
skalierten
werden,
y o n N k k a n n der
befindet.
Multiplizierer
PLL-Bau-
die b i t - p a r a l -
v den P a r a l l e l a d d i e r e r
parator
VC0
(phase-
nach dem Frequenz-
Nachdem
der bei A d r e s s i e r u n g
Gber
f2 zu-
Digital-Frequenz-
integrierte
PrezeBrechner
Eingangssignal
fe des P h a s e n r e g e l k r e i s e s
0szillator
eines
D-f-Umsetzers
vom
ist d a d u r c h Ausgangsfrequenz
an d e n gew/inschien A u s g a n g s f r e q u e n z b e r e i c h
Bin~rz~hlers
dem Phasenkomparator
Zeit
kann
100 ms
k~nnen.
gestellt
Mit H i l f e
Die S u m m e
eine E i n h e i t .
Anforderungen
Phasenregelkreises
3 dargestellt.
werden,
Zum v a r i a b l e n
des E i n g a n g s s i g n a l s
pragrammierbaren
einiger
des
erscheint
obere A u s g a n g s f r e q u e n z
des
werden
dem Umsetzer
N k addiert.
werden.
seit
zur V e r f G g u n g
im P u f f e r s p e i c h e r
te B i n ~ r z a h l
gepaBt
das P r i n z i p
und
j e d o c h 8 Bit
yon minimal
0 eine u n t e r e
eine
realisierten
vorgesehen
daten Gbernimmt.
dynamischen
eine U m s e t z z e i t
sind
Ubertragungskennlinie
ist in B i l d
Daten
bus nut k u r z z e i t i g
fGr die
eingesetzt
eines
Anforderungen
F/it die K o n z e p t i o n
an, n a c h d e m
statischen
an die A n f e r d e r u n g e n
gew~hnlich
Eings_ngssignal
sich heute
Synthesizer-Prinzip
rat
statische
wirtschaftlich
speicherung
Weft
statische
PeriodendauersignaDie
12 Bit,
Prozesse
oder u m g e k e h r t .
bietet
locked-loop,
oder
mGssen
dem Eingangssignal
fl u n d d e m m a x i m a l e n georduet
Frequenz-
in e i n e m D i g i t a l - F r e q u e n z - U m s e t z e r .
Eingangssignal
um den verriegelten
auf eine Zustand
N v in e i n e n n e u e n W e r t Nv+ANv, neue
Frequenz
aufrecht
so
fref(Nv+~Nv+Nk)/N I
zu erhalten.
Die V C 0 - A u s -
237
gangsfrequenz
weist
Gber
dem
digitalen
f
den ~[nderungen
aus die PLL-Schaltung Das
N3
auf
die
gangsfrequenz
die
gew~inschte
mit
wird
lineare
auf.
Damit
Abhingigkeit das
gegen-
Ausgangssignal
N
schnell folgen kann, wird v hohen Frequenzen betrieben.
mSglichst
VC0-Signal geforderte
des
N
v Eingangswertes
des
intern
hochfrequente
lets
somit
Eingangssignal
anschlieSend
Ausgangsfrequenz
mit
Hilfe
eines
heruntergeteilt.
Digital-Frequenz-Umsetzers
berechnet
Tei-
Die Aus-
sich
deshalb
zu Nv + Nk faus
-
fref N I • N3
Die
statische
Genauigkeit
fref b e s t i m m t .
renzfrequenz tot
abgeleitet~
einen
ist
der
in
Temperaturgang
vorwiegend
Sie
einem
wird
ks/in d e s h a l b
rungseinfluS
yon maximal
im
deshalb
die
yon
Temperaturbereich
yon maximal
statisierung
dutch
Konstanz
einem
yon
lO-5/Jahr
Auf
verziehtet
kann
praktisch
Quarzoszilla-
-20 bis
10 -5 K -1 b e s i t z t .
allgemeinen
der Refe-
+70
eine
werden.
°G
ThermoDer
Alte-
vernaehl~ssigt
wet-
den. Die
Phase1~omparatoren
als M u l t i p l i z i e r e r . quenz~
die
lagert
ist,
wird
diesen
Bet
einem
yon
12 B i t
deshalb
ein Baustein
stSrenden
wurden
gangsfrequenz
yon
am Eingang
800
Eigenschaften
zierbarkeit, t~t
ggf.
rechnergefithrter der
Funktion
Stellgerites lung
auf
yon
mit
erst
arbeiten
doppelten
Phasenkomparators
Fre~ber-
2400 Hz kann
einem
verwen-
erzeugt.
150 ms b e i m
erreicht.
mit
Phasenkomparator
gar nicht
f~r e i n e n E i n g a n g s s i g n a l b e r e i e h
yon
ether
Stellgeriten
Linearitit f~r
Prozesse.
Stellgerite,
u_nd d e m S t e l l g l i e d Die
des
der
F~r
Ubergang eine
der Aus-
Ausfiihrungsform
Einstellzeit
yon
etwa
20 ms
Servokreise
si~d mitbestimmend
ponenten
wegen
werden.
5- F r e q u e n z g e f t L h r t e
Die
Anteil
Einstellzeiten
yon nur
gerechnet
am Ausgang
ausgefiihrten D-f-Umsetzer
8 Bit
tritt
unerw~nsehte Frequenzmodulation auf. I m R e a l i s i e r u n g s -
eine
det,
der
F~llen
der Gleiehspannung
beispiel
integrierten P L L - B a u s t e i n e
der meisten
In diesen
der
des
Gite
Sie
ergeben
also
der
Stellelektronik
zu unterscheiden.
Eingriffs
die
(Stellventil)
weitgehend
hinsichtlich
bestimmt. Arbeitet
und
Genauigkeit, ihrer
der Regelungen sich
aus
Steuerun~en
dem
der Kom-
Stellan~rieb
Stelleingriff.
als wird
Hier das
Langzeitstabili-
und
dem Verhalten
Stellelektronik,
Reprodu-
dutch sind
die
Betriebsweise
Steuerung
Stellgerit
und
im Sinne
des
Folgerege-
ether
Ste~e-
238
rung,
so p a ~ t
stungsm~Big glied
an.
triebe dern.
Beispiele
oder Bei
erh~lt
Stellelektronik
des R e g l e r s
rakteristisches regelte
sind
Beispiel
zus~tzlich
weitere
Folgeregelkreis
ProzeBrechners Betriebsweise
bei
nik
Beispiel
heitsdrucksignal Die A u f g a b e
Stellger~te
te
dessen
gebr~uchlich
werden
statische
f
fN=I/TN
die
die
fur
passung
an
Kennlinie
lel
rein
digitale
Diese das
der
eines
die
eines
fitr E i n -
Dreipunkt-
folgende
Glei-
Istfrequenz, und
und/oder
und
Antrieb,
~f
die
a das
normier-
seriell
Gew~hrleistung weitere
Programmierbare
verschwindende
MSglichkeit
digitalen
Totzone
Verzicht
Schaltpunkten,
fGr
den
zur
dureh auf
An-
hohe
diskrete
Einbau
Vorbereitung Eingabe
hoher
Anforderun-
Totzeit
Komparators,
Einsteller, den
der
bestehen
Aus~tthrung:
an
yon
einer
fiir Sollwert
paral(Ffih-
Istwert.
Anforderungen erste
einbeziehen.
f-p-Umsetzer
BezugsgrG~e
Kennlinie
des
analoge
und
s i c h mit V o r t e i l der S t e l l e l e k t r o -
d u t c h die
Reproduzierbarkeit
jeweiligen
und
digitalen
den
zen-
amplitudenana-
und Wirkungsweise
f
als
dieser
Hystereseeigensehaf%en
rungsgrSBe)
des
Dreipunkt-Sehaltgliedes.
Verarbeitungsgeschwindigkeit Bauelemente
dutch
(fw-fx+~f/2)TN]/2
+ sgn
Normalfrequenz
und
den
- l~St
entspricht
Fiihrungsfrequenz,
Verwirklichung
eine
in der L i n e -
x
des
Langzeitstabilit~t gen
stellungsge-
ist
mit F r e q u e n z u m s e t z u n g
Eigenschaften
(fw-fx-~f/2)TN
dabei
der
cha-
wird
Ausgangssignal
Neben
Ein
Entlastung
u n d der E i g e n s c h a f t e n
w
Totzon%
sind
- in h e r k S m m l i e h e n
in e i n e m f o l g e g e r e g e l t e n
a = [sgn
bedeuten
Sollwertver-
(RGckkopplungsprinzip)
Frequenzkomparators
chung beschrieben
ES
des
aufgezeigt.
des
schaltgliedes,
die F u n k t i o n e n
gleichzeitiger
in ein I n s t r u m e n t i e r u n g s s y s t e m
Frequenzkomparators
als F o l g e r e g e l k r e i s
EinsatzmSglichkeit
der Stellger~te
der R e a l i s i e r u n g
Als k o n k r e t e s
Stellan-
oder T r i a c - S t e l l g l i e -
zu sehen.
logen Instrumentierungssystemen hinsichtlich
lei-
Stell-
des R G c k f i i h r s i g n a l g e n e r a t o r s .
fGr d e r a r t i g e
Eine
und
an das
geschwindigkeitsgesteuerte
des S t e l l g e r ~ t e s
ggf.
struktur-
unmittelbar
mit T h y r i s t o r -
yon Stellventilkennlinien
ausgelagerten
Diese
und
Stellventile.
arisierung
tralen
hierfGr
das S t e l l s i g n a l
oder/und
Leistungsstellger~te
einer Betriebsweise
die
gleiohs,
die S t e l l e l e k t r o n i k
an d e n S t e l l a n t r i e b
(~i.l.d..4)
lassen eine
sich
dutch
zeitparallele
tung y o n Ist- u n d F ~ h r u n g s f r e q u e n z
zwei ~nd
mit
Konzepte damit
etwas
erfGllen,
zeitminimale
vergrSBertem
wobei Verarbei-
sohaltungs-
239
technischem Aufwand gegen~ber dem zweiten die A u s w e r t ~ g
(Bild 5) durch~tihrt, das
y o n Ist- u n d Ftihrungsfrequenz z e i t s e r i e l l v o r n i m m t .
B e i m K o m p a r a t o r n a c h B i l d 4 erfolgt der V e r g l e i c h der E i n g a n g s f r e quenz f
W
und f
X
d u r c h S u b t r a k t i o n der Z ~ h l e r s t ~ n d e
Parallelsubtrahierer.
Z w = N fN T w Bei F r e q u e n z z ~ h l u n g
ergibt
ergebnis vorgenommen.
einer N a s k e w i r d im f o l g e n d e n B l o c k die
Im N o r m i e r u n g s b l o c k
e r f o l g t s c h l i e B l i c h die B i l -
a n a c h der B e z i e h u n g
(zw-zx-
z/2) +
(z-zx+Az/2
/2
s i c h fGr V i e l f a c h p e r i o d e n a u s w e r t u n g
oo
÷
u n d bei F r e q u e n z z ~ h l u n g
die b e r e i t s
Die F r e q u e n z k o m p a r a t o r s c h a l t u n g
angegebene
gew~nschte Beziehung.
nach Bild 5 unterscheidet
der B i l d u n g des S u b t r a k t i o n s e r g e b n i s s e s .
dab der d u r c h V o r w ~ r t s z ~ h l e n
s p r e c h e n d fw bzw.
gebildete
Tw, tun d e n Z ~ h l e r s t a n d
d u t c h R G c k w ~ r t s z ~ h l e n v e r m i n d e r t wird. Z~hlers mit d e m W e f t ~ Z / 2 symmetrische Kennlinie.
vor
Tx,
gew~hrleistet
die
E i n s t e l l u n g der T o t z o n e und
l~t
sich a u c h d u t c h
eine E r w e i t e r u n g der
in den S c h a l t p u n k t e n v o r n e h m e n .
Im v o r l i e g e n d e n A n w e n d u n g s f a l l heitsdrucksignal
ent-
im w e s e n t l i c h e n wie b e i m Fre-
jeweils v o r a n g e g a n g e n e n W e c h s e l
Schaltung durch Hysterese
Zw,
Zx, e n t s p r e c h e n d fx bzw.
q u e n z k o m p a r a t o r ~ a c h B i l d 4. A n d i e s e r Stelle S p e i c h e r u n g der
Es w i r d d a d u r c h
Eine ¥ o r e i n s t e l l u n g des V/R-
Die n a c h f o l g e n d e erfolgt
s i c h nut
Z~hlerstand
jedem R e c h e n v o r g a n g
die B i l d u n g des A u s g a n g s s i g n a l s
siert wurde,
TN TorSffnungs-
Tx=l/f x Periodendau-
im p a r a l l e l d i g i t a l v o r l i e g e n d e n S u b t r a k t i o n s -
d u n g des A u s g a n g s s i g n a l s
erzielt,
fN N o r m a l f r e q u e n z ,
der Fiihrungsfrequenz,
N a c h Art
E i n s t e l l u n g der T o t z o n e
hinsichtlich
in e i n e m
X
Zx = TN fx
zeit, T w = l / f w P e r i o d e n d a u e r
D a m i t ergibt
und Z
sich
Dabei bedeuten N Vorteilungsfaktor,
a = [sg
W
Zx = N fN Tx
Zw = T N fw
er der I s t f r e q u e n z .
Z
Es gilt f~r V i e l f a c h p e r i o d e n a u s w e r t u n g
eines F r e q u e n z - D r u c k - U m s e t z e r s
fGr Ein-
(Bild 6), fGr den ein K o m p a r a t o r n a c h B i l d 4 r e a l i -
konnte
auf diese E r w e i t e r u n g v e r z i c h t e t w e r d e n o
Dieser
240
Frequenz-Druck-Umsetzer dauern
der Fiihrungsfrequenz
sten Daten yon
fiihrt e i n e n V e r g l e i c h
sind:
1,6 kHz
Untere
fGr die
Zykluszeit
Neben
~
= k . 0 , 4 8 8 " I 0 -3
des K o m p a r a t o r s
solcher
in F ~ h r u n g s r e g e l k r e i s e n fGr die I n d i k a t i o n
anpaBbar
der S t a b i l i t i t
Totzone
an die A r t
wichtig-
bezogen
auf
k =1,3,7)~
des
Stellan-
die S t a b i l i t ~ t
Frequenzkomparatoren
fGr S t e l l g e r ~ t e ,
im Z u s a m m e n h a n g
Seine
Frequenzspanne
der
der R e f e r e n z f r e q u e n z . als
eignen
yon Frequenzinderungen
rungsgesch~indigkeit
eine
der P e r i o d e n -
(k e i n s t e l l b a r ,
3,27 MHz q u a r z s t a b i l ;
entspricht
dem Einsatz
~ 5 ms,
dutch.
800 Hz u n d
Ftthrungssignal-Istfrequenz;
Referenzfrequenz
Schaltpunkte
u n d der I s t f r e q u e n z
Frequenzgrenze
die P e r i o d e n d a u e r s p a n n e
triebs;
bezGglich
mit
und
Dreipunktschalter
sie
sich hervorragend
zur Bestimmtung der ~ d e -
der 0 b e r w a c h u n g
yon Proze~-
grGSen.
6.
Zusammenfassung
Anhand
spezifischer
die M S g l i c h k e i t e n
Eigenschaften
eines
mit Frequenzumsetzung quenz,
abh~ngig
te d a r g e l e g t
aufgezeigt.
unter
welchen
bei
gleichzeitiger
erfolgen
kann.
SchlieBlich
eines
Stellkanals
dutch
Frequenzkomparator quenzgeftLhrten Die
Vorteile
das
Schaltungen
erst
in d i g i t a l e r
eines
d e n im b e s o n d e r e n
Instrumentierungsmethoden oder
an die
Dieser
statische
Bericht
desministers
verGffentlicht
f~r F o r s c h u n g
Forschungsvorhabens
gen
im R a h m e n
(PDV)
wortung
des
fGr den I n h a l t
gefGrderten
nich%
liegt
Unternehmen.
mit
kann.
Ein
in fre-
Frequenzumsetzung
werden
e i n e m mit
(Kennzeichen
kSnnen.
Mitteln
ProzeBlenkung
M - IMR/I
bei
des Bun-
D V 5.505)
ge-
mit D V - A n l a -
der B u n d e s r e g i e r u n g .
ausschlieBlich
wer-
~blichen
an die S i g n a l G b e r t r a g u n g
aus
des P r o j e k t e s
P 2.1/2;
der Technologie
werden
den gegenw~rtig
erf~llt
Ergebnisse
2.DV-Programms
Ein neuarti-
der P h a s e n -
kann mit Vorteil
wenn mi%
und Technologie
fSrderten
Es k o n n -
integrierende
werden.
die A n f o r d e r u n g e n
Genauigkeit
Prinzips
eingesetzt
Realisierung
eingesetzt
offenkundig,
eine
die F o r t s c h r i t t e
Instrumentierungssystems dann
berechnet.
behandelt.
sich des
wirtschaftlich
Servokreisen
Abtastfre-
Instrumentierungskompo-
mit Frequenzumsetzung
regelschleife
wurden
im F r e q u e n z - D i g i t a l - U m s e t z e r
wesentliche
bedient
(PLL),
die n o t w e n d i g e
Anforderungen
Skalierung
wurden
Komponenten
Instrumentierungssystems
Voraussetzungen
get D i g i t a l - F r e q u e n z - U m s e t z e r
integrierter
spezifischer
Es w u r d e
y o n den d y n a m i s c h e n
werden,
Filterung
nenten
und
prozeBrechnerge~/arten
den A u t o r e n
Die V e r a n t bzw.
den
241
Literaturhinweise F r e y b e r g e r F., T r i n k l e r H.-R., Art u n d A n f o r d e r u n g e n ten eines proze~rechner-orientierten Basis
der F r e q u e n z u m s e t z u n g ,
auf der
6-IMR-9/73
GeiSler
Ch., E i n n e u e r D i g i t a l - F r e q u e n z - U m s e t z e r ,
GeiBler
Ch., T r i n k l e r H.-R.,
gital-Frequenz-Umse%zers
an die K o m p o n e n -
Instrumentierungssystems
11-IMR-I0/73
Zel!er P., E n t w u r f und A u f b a u eines Di-
auf der Basis
der F r e q u e n z s y n t h e s e ,
12-IMR-
11/73 T r i n k l e r H.-R.,
D i g i t a l e M e B m e t h o d e n u n d V e r f a h r e n f~r die I n s t r u m e n -
tierung rechnergef~hrter
Tr~nkler K0
VI,
H.-R., 17.-23.Juni
Prozesse~
Rechnerangepa~te 1973,
Dresden,
i n t e r n e r Bericht~
MeDglieder B-314,
mit Acta
5-IMR-8/73
Frequenzausgang,
Imeko
1973
IMP-
242
10 o -5 -2 0-1
0-2 ±
-5 -2
J
J
J
-5
fo
10 -3 y -5 -Frel -22 5 2 5 2 5 2 5 2 5 I i i i I t L,t 10 -4 I i 10-3 t0 -2 t(~ 1 10-6 10-s 10-z~
Bild
I
Abtastfrequenz
und Abtastfehler
I 6~I !11 ill Ill ltX/ Ill IIX ILY' ii
,f
.y-]
n=fst-t o 0 0 Bild
2
Integrierende
Filterung
2
3
4
vom
Rechner
Speicher
i.~..l r
~ " ~ f
---~I
[
Paralleladdierer
i 1 ffeset ~ I k I L_. . . . . . . . . 1- - J Programmierbarer ;~hler
J
PLL-Baustein Bild ~
Digital-Frequenz-Umsetzer
6
yon Frequenzsignalen
h l ~
Daten
5
nach
dem P L L - P r i n z i p
ref
243
fw
Z~hter Z w
A2-~AT
Normierer
Subtrahierer
l
Z6h[er Zx
fx Bild 4
Frequenzkomparator,
parallele Signalverarbeitung
fw-
H
Normierer
fxBild ~
fw
Frequenzkomparator,
~!. . L _ ~ " S c h r itt motor - L ~ . ~ ' ~ l ~ --I ~oml:~rator ~ ansteuerung~ ..... F--~
/ Bild 6
serielle Signalverarbeitttng
,
Frequenz-Druck-Umsetzer
iv
olJ
~tir Einheitsdrucksignal
PI
_=p
EXPERIMENTELLER VERGLEICH PARALLELER UND SERIELLER
STELLEINGRIFFE IN EINEN GESTORTEN PROZESS
WILFRIED SCHUMAOHER
I. Zusammenfessung
Mit dem Einsatz von Bildsichtger~ten mit serieller Informationsdarstellung, verbundsn mit einsr Reduzisrung der Anzahl der Leitger@ts, wird sine Verkleinerung der MeBwarten angestrebt. Die vorliegsnds Untersuchung dient zur Ml~rung der Frage, wie wait man die Reduzisrung der Anzahl der Leitger~te bel gegebener Anzshl von zu fOhrenden Teilprozessen und dem gleiehzsitigen Auftreten von mehreren ProzeBst~rungen treiben darf. Es wird sin Vergleich parslleler und eerieller Stelleingriffe in einen ProzeB durohgef8hrt. Als FshlermaB wird des Zsitintegral des Betrages des Regelfehlets oberhalb einer Schwelle gemessen. Der Regelfehler steigt mit zunehmender Anzahl von Streoken und abnehmsnder Anzahl von Lsitger~tsn stark an. Im Einzslfall ist zu pr~fen, ob die Verschlechterung der Regelg8te zul~ssig ist. Im andsren Fall ist es erforderlich, mindsstarts so vials Leitger~te zur VerfOgung zu stsllen, wie gleichzeitig gest8rte Strecken auftreten k~nnen.
2. Einleitung
Technische Prozesse warden in zunehmendem MaB von ProzeBrechnern gefOhrt und Oberwacht. In den zugehSrigen Wartsn und Leitst~nden muB Vorsorge getroffen warden, um den ProzeB bei StSrungen dutch den Mensehen Oberwaehen und fOhren zu kSnnen und so den St~rungen entgegsn zu wirken. Beim Auftreten einer StSrung und der damit verbundenen Alarmmeldung hat der Bedienungsmann nach einer von ihm zu ermittelnden Strategie mit Hilfe der Bedien- und LeitgerQte so in den ProzeBablauf einzugreifen, dab schwerwiegende Folgen der St8rung vermieden warden. Ein solcher Eingriff ksnn von airier einfachen Schaltsrbet~tigung oder einer Sollwertverstellung bis hin zum Abfahren des Prozesses gehen. In konventionellen Warten ist jeder anzuzeigenden GrSBe sin eigenes Instrument bzw. die Lamps sines AnzBigefsldas zugeordnet; entsprschend ist for jade zu steusrnde Gr88e sine Eingriffsm8gliohkeit vorgesehen. Dadurch ist sine parallels, d.h. gleiohzsitigs Oberwachung und Steusrung mehrerer TeilvorgQnge des
247
Prozesses mBglich. Mit grOBer werdenden An!agen warden auch die Warten grOBer und unObersichtlicher. Das Bedienungspersonal wird im Sterungsfall 8berfordert. AuBerdem wird mlt dam Einsatz eines ProzeBrechners eine so umfangreiche Instrumentierung nur selten benBtigt. Es warden deshalb kleinere, Obersichtlichere und basset zu 8berwachende Warten angestrebt. Dutch den Einsatz van rechnergesteuerten Sichtger~ten zur informationsausgabe sowie dutch eine Reduziarung der Anzahl der Leitger~te wird eine Verkleinerung der Warte erreicht. Auf dam Sichtger@t warden ProzeBbilder, Meldungen und MeBwerte angegeben. StSrmeldungen warden in Obersiohtlicher Form dargestellt, die Suohe nach den St~rungen wird erleichtert. Die Informationen liegen allerdings nieht mehr glaichzeitig und st~ndig Vat, sondern mOssen in der Regel auf eine Alarmmeldung hin nacheinander angew~hlt warden; die Informationsdarstellung erfolgt seriell. Die Reduzierung der Leitger~te bedeutet, dab mehrere Regelkreise des Prozesses dutch ein Leitger~t in der Warte repr~sentiert warden. Beim Auftreten einer Signalsterung muB das Leitger@t mit dam betroffenen Regelkreis verbunden warden. Sind mehrere Streeken gleichzeitig gest~rt, so wird das Leitger~t nacheinander auf die verschledenen Strecken geschaltet. Treten St5rungen bei den einzelnen Stricken in solchen Zeitabst~nden nacheinander auf, da6 eine St~rung vellig behoben werden kann, bevor die n~ohste eintrifft, unterscheidet sich die serielle van der parallelen EingriffsmSglichkeit nut dadurch, dab der Bedienungsmann im letzteren Fall seine Instrumentenbeobachtung auf mehrere Instrumente richten kann und so St5rtendenzen schon beobachten kann, bevor es zu einem Alarm kommt und u.U. die M8glichkeit besitzt, diesen zu verhindern. Die Sterbehebung naoh einem Alarm ist in beiden F~llen gleioh gut meglich. Liegt die Alarmgrenze tief, so sind dis beiden Eingriffsm~glichkeiten gleichwartig. Mritisch wird die Reduktion der Anzahl der LeitgerQte (Grenzfall: nur ein Leitger~t) balm gleichzeitigen Auftreten mehrerer £tSrungen. Dann besteht die Gefahr, dab ain Teilvorgang in den Alarmbareich gBr~t, w~hrend gerade die Sterung eines anderen beantwortet wird. Es erhebt sioh die Frage, ob bei einer so weitgehenden ~nderung des WartenkonzeptBs die Vorteile der besseren Oberschaubarkeit nicht dutch sine Erschwerung der Informationsverarbeitung infolge der seriellen Arbeitsweise erkauft warden.
248
Theoretische Modellvorstsllungan for so komplexe Systems liegen nioht vat und k8nnen deshalb nicht zur Beantwortung der Fragen herangezogsn warden. Praktisehs Erfahrungen liegen ebenfalls zur Zeit noah nicht in ausreichendem MaBe vat. Es wurdBn deshalb sxperimsntelle Arbeiten durchgsf8hrt, um zu einem Vergleich der konventionellen Warts mit dem neusn Wartenkonzept zw galengen und um Gestaltungshinweiss for dis Informationsdarstellung auf SichtgerQten zu erhalten. Bei einem experimentellen Vergleioh verschiedener Anordnungen erfolgt auf jsdan Fall sine Reduktion der in der Praxis wirkenden Parameter. Monkrete Betriebssituationen lassen sioh auoh bei grSBtsm technisohen und finanziellen Aufwand nut unvollkommen im Labor nachbilden. Motivation, Ausbildungsstand und soziologische Verflschtung des in einer Warts besch~ftigten Personals sind daneben bei Versuchspersonen prinzipiell nioht wiederholbar. Des hat zur Folge, dab experimentell gewonnene Befunde nioht for einen speziellen konkreten Anwendungsfall volle GOltigkeit bssitzen. Auf der andsren Seite abet hat gerads die Abstraktion van den vielf~ltigen Gegebenheiten der Praxis den Vorteil, de8 die Befunde nicht nur for einen spezifisehen Anwsndungsfall van Belang sind, eondern auf mehrere in den Einzelheiten versohiedenartige praktische Situationan Obertragen werden kBnnen. Voraussetzung ist jsdsoh, dab Versuohsaufbau und DurchfOhrung des Experimentes die Grundstruktur des zu untersuchenden praktischen Vorganges widerspiegeln. Es wurde daher sine Aufgabe formuliert, die sine typische Aufgabe sines Bedienungsmannss naohbildet und einen VBrgleich aerialist mit parallslsr Informationsdarstellung bzw. Bedienbarkeit ermBglicht. Dis vorlisgsnden Untersuohungen dienen grunds~tzlioh zur Ml~rung der Frage, wie wait man die Reduzierung der Zahl der Leitger@ts bei gegebsner Anzahl van zu fOhrenden Teilprozesssn und dam gleichzeitigsn Auftrstsn van mehreren St8rungen treiben darf, ohne ein zu hohes Sichmrheiterisiko einzugehen.
3. VersuchsdurchfGhrung
Mit einem elektronisoh simulierten, in seiner Momplexit~t in gewissen Grenzen variisrbaren ProzeBverl~uf wird untmrsuoht, inwiewsit sioh parallsle (konventionelle) und
seriells
Eingriffs in den ProzeB voneinander untsrschsiden.
Dabei wird dutch sohrittweise Verringarung der Zahl der Lsitger~te festgsstellt, ob sine eindeutigs 8renze der Rsduzisrung der Lsitger~ts im Hinblick auf des durch die Leistungsgrenzen des Menschen bedingte 8icherheitsrisiko gefunden warden kann.
249
Es ergebsn sich folgende unabh~ngige Variablen:
I. Zahl der gleichzeitig gest8rten Strecken 2. Zahl der zur Verf~gung stehenden LeitgerQte. Als abh~ngige Variable wird die Regelabweichung nach Oberechreiten einer Schwelle registriert. FOr die experimentellen Untersuchungen wurden 2 bis 4 Strecken mit StBreignalen beaufschlagt. Bild I zeigt des Blocksohaltbild des Versuchsaufbaus. Die Streoks besitzt einfaches I-Verhalten mit der Integrationszeitkonstanten T I. Des St8rsignal greift am Eingang der Strecke sin. Regeleingriffe warden Ober einen Momentenkontaktsohalter durch Impulseingabe bewirkt. Ein weiterer Integrator mit der gleichen Integrationszeitkonstanten T I dient als Speicher for die eingegebenan Impulse. Angezeigt warden die StBllgrB88 und die Regelabweiohung. F~r des Regelverhalten des MBnschen entspricht der gesamte Kreis einer Strekke mit Doppel-I-Verhaltsn mit Impulseingabe mit Anzeige einer ZustandsgrBBe und der Regelabweichung der Strecke. Ale Fehlerma8 wird das Zeitintegral des 8etrags des Regelfehlers oberhalb sines beetimmtsn Schwellwertes S gemessen. Der VP wird durch Aufleuchten einer roten Lamps signalisiert, daB die Regelabweichung einer Strecke diesen Schwellwert Qberschritten hat. Die VP hat dann des Leitger~t Ober einen Mlinkensteoker mit der gest8rten Strecke zu verbinden und disse durch Aufschaltsn siner Stsllgr88e mit dam Momentsnkontaktsohalter m8glichst schnell auszuregsln. Warden mehrere Strecken durch sin Leitger~t gefOhrt, geht die Zeit for des Umsteoken der Hlinkenstscker in des Ergebnis ein; eine Anwahl Ober sin Tastenfeld beansprucht wahrscheinlich weniger Zeit. Trotzdem words der Versuchsaufbau mit Mlinkenstecker gew~hlt, d a e r
wesentlich einfaoher ist (sine gegansei-
tige Verriegelung der Tasten entf~llt) und keine Zuordnungsschwierigkeiten zwischen Strecken und Leitger~ten bestehen. Der EinfluB der Anwahlzeiten auf des Ergebnis mu8 untersuoht warden. Bild 2 zeigt des Trajektorienfeld der Regelstreoke, das je nach Polarit~t der Stellgr8Be aus Parabeln mit unterschiedlichen Offnungsrichtungen besteht. Die
250
Regelabwsichung ist dutch x I gsgeben, die differenzierte Regelabweichung dutch x 2. Da dis Strecke aus zwei Integratoren besteht, k~nnte man x I ale den Wag, x 2 ale die Gesohwindigkeit und die Stellgr~Be als Beschleunigung auffassen. Ein sprungf~rmiges St~rsignal wirkt dann wie sin Geschwindigksitssprung, d.h. sin Sprung der Zustandsgr~Be x 2. Beim Auftreten sines St~rsignalsprungs wird der Regelfehler x I nach der Funktion x 2 = const bis zum Eingreifen der VP ansteigen. Nach Aufschalten der StellgrSBe wird sioh der Zustandspunkt entlang ainer Parabel bewegen. Verh~lt sioh die VP wie sin zsitoptimaler Regler, wird sis die Polarit§t der Stellgr6Be umschalten, wenn die optimale Schaltkurve S(~) erreicht ist, um dann den Zustandspunkt entlang der Sohaltkurve in die Ruhelage zu bewegen. Der Aufbau der Versuohsapparatur geht aus Bild 3 hervor. Das Geh~use hat die Form einer Konsole. Auf der schr~gen Frontplatts sind 10 L~mpohen mit Mlinkenbuohsen angeordnet, von dsnen je zwei einer Sireoke dutch Umschaltung zugeordnet sind, dami@ sioh die VP nicht sin bestimmtes Bild einpr~gen kann. Auf dam horizontalen Tail dar Frontplatte sind die MeBinstrumente und die Stellglieder der Leitger~te angeordnet. Die Instruments zur Messung der Regalabweichung sind senkrecht, dis Instruments zur Anzeige der StellgrSBe waagereoht eingebaut. Im ersten Versuchsabsohnitt wurden als Integrationszeitkonstanten der Strekken T I = 2 s, also relativ schnelle Strecken, gew~hlt, um dis Leistungsgrenzen des Menschen zu erfassen. Im zweiten Abschnitt sind die Zeitkonstanten mit TI = 30 s denen in der Verfahrenstechnik hBufig vorkommenden Werten angepaBt. Im staten Abschnitt wurde mit einer Versuchsdauer von 2oo s gearbeitet. Ale StSrsignal wurdsn Reohteckspr8nge verwendet, bei denen im Mittel alle 50 s sin Sprung auftrat. Dis StSrsignale sind auf einem Tonband aufgezeichnet, je Spur sin Starsignal, so daB gleichzeitig mehrere Strecken gestBrt warden kBnheR,
Die StSrsignale setzen auf den einzelne~ Man~len in ainem Abstand von etwa 10 s ein, damit die VPn genOgend Zeit finden, die ProzeBstBrungen zu beantworten. Bei einBr sofortigen Aufschaltung eller StBrsignale zeigten slch such ge8bte VPn Bberfordert. Dis gegenseitige Lags der SignalstBrungen auf den einzelnan Man~len ist so angeordnet, dab auch mehrere StBrsprOnge gleichzeitig auftreten k~nnen, ansonsten abet ein stochastlsches Auftreten gew~hrleistet ist.
251
FSr den zweiten Versuchsabschnitt wurde sin StSrsignal verwendet, das im Mittel slle 100 s einen Sprung aufweist und mit verschisdenen Amplitudenstufen auftrat (Bild 4). Die Versuchsdauer betrug hier wegen dsr wesentlich langsamersn Strecken 500 s.
4. Varsuchsergebnisse Die Ergebnisse der Messungen for die sohnellen Strecken sind in Bild 5 dargestellt. Aufgetragan sind die Medianwerte des Betrages der mittleren Regelabweichung Obsr der Anzahl der gleichzeitig gest8rten Streoksn und der Anzahl der Leitger~te. AuBer den Msdianen sind die quartilen eingezeichnet. Dabei ist der Median der Weft, der das geordnete Werte-Mollektiv halbiert, d.h. unter- und oberhalb van ibm liegen je die H~lfts aller Warts. Die Quartile sind entspreohende Warts for 25 % und 75 % des Mollektivs. Das Werte-Mollaktiv besteht mus den aufgezeichneten mittleren Regelfehlern aller Versuchspsrsonen Ober alle Strecken und Einzelvsrsuche, wobei jade Versuchsperson for jeden Punkt 10 Einzelversushs durchgefOhrt hat. Die Abbildung zsigt, dab sin fast linearer Anstieg der Murven mit zunehmender Strscken- und abnehmendsr Leitger~teanzahl zu verzeichnen ist. Eine Erh~hung der Zahl der gsstGrten Strecken bei gleichzeitiger Erh~hung der Leitger~te ergibt eine Versohlechterung,
z.B. um den Faktor 5 bei der Erh~hung von 2
auf 4 Strscken. Eine Verringerung der Leitger~te macht sich ebenfmlls in einem sehr starken Ansteigen des Fehlers bemerkbar. So ergibt bei einer Regelung von zwei Strekken mit einem LeitgerQt gegenGber einer Rmgelung mit 2 Leitger~ten eine Verschlechterung um den Faktor 5. Bei diesen Ergebnissen ist zu berOcksichtigsn, daB die Absolutwerte nut for den untersuchten Parametersatz gelten. Doch gilt der grunds~tzliche Zusammenhang aush for andere Parameter, wie die Ergebnisse for die langsamen Strecken (Abb. 6) aufzeigsn. Dsr prinzipielle Verlauf der Murven ist also unabh~ngig v o n d e r Wahl der Integrationszsitkonstante,
da bei grBBeren Zeitkonstanten auch l~ngere Eingriffs-
zeiten der VP erfordarlich sind. Als vorl~ufigss Ergebnis l~Bt sich sagen, dab bsi den untersuchten Bedingungen sine deutliche Vergr~Berung des Rsgelfehlers eintritt, wenn weniger Leitger~te als gleichzeitig gest~rte Strecken zur VerfOgung stehen. Im Einzelfall ist zu prOfen, ob die Verschlechtsrung dsr RegelgOte zul~ssig ist. Im anderen Fall
252
ist es erforderlich, mindestens so viele Leitger~te zur VerfQgung zu stellen wie gleichzeitig gestBrte Strecken auftreten kSnnen. Das Bereitstellen eines Leitger@tes f~r jede Strecke des Prozesses ist allerdings nicht erforderlich. Dieses Ergebnis setzt voraus, dab als Bewertungskritsrium der mittlere Regelfehler ausreichend ist. Genauere Untersuchungen Bber die Ursachen der Verschlechterung liegen nooh nicht vor. Durch Analyse des Verhaltens der VP (Umschaltzeiten, Regelungszeiten/Strecken, Umschalth~ufigkeiten, Augenbewegungen) sollen Hinweise zur Umschaltstrategie der VP gewonnen werden. Weitere Versuchs zielen dmrauf ab, die Umsohaltzeiten zu verkOrzen, den Einflu8 einer automatischen Umschaltung der Lsitger~te (zyklisch oder abh~ngig vom St~rzustand) zu untersuohen und den EinfluB einer parallelsn Anzeige a!ler Streckenzust~nde auf dem Sichtger~t bei seriellen Eingriffsm~glichkeiten zu untersuchen.
253
ZU) SchwellweHs~ha/te~ B mitll.Rege/fehler Y Botrogsbildung
tyi=~lyldt Uv
i
f leitgerot
~lld 1;
BiDckschaltbild de~ V e ~ u c h ~ B u r b a u 6
J
_,
(~
t,yt>s
,~/ormme/dung
254
Bild 3: VersuchsBpparatur
l
I
/
Bild 5 :
/
/
/
4
~"/
der Anzahl
/
/
,/e
Leitg;rdte
/
I
Regelfehlers
I
/
der Strecken und Leitger~te
als Funktion
des mittleren
I
/
/
I
(Mediane und Quartile)
3
/
I
i
UR = IOV
__>__/___;
-.~;7
-
Darstellung
2
~/__
Stellgr~l~e
/4
,
.~,~<,,,f,
/
T
Tz = l, Ss
_ L2 . _#._ 12
S t 6 r $ i g n a l U Z IV, fz~ 10-2 H z
Strecke
2
/ i
/
I/ i,'"
~
[. .
/
,I<-~-.."
~ ~
i ---
Bild 6:
1
il_
,
,'~.-" .-" I
/ 3
l
/ 4
Leitger~te
.
Regelfehlers
I
der Anzahl der Strecken und Leitger~te
als Funktion
des mittleren
i
(Mediane und Quartile)
Darstellung
2
t
"~s ~ . - / - - :,;- - - ~ . ~ , . ~ .
/ i
UR = 5 V
Stellgr6Be:
,'!,'"'"--.:,,D'Y~
,,','
fz ~ 5.10 -3 H z
St6rsignal:
V ,v----;,'-~--~----7,s
't /
T~
1 " s2
Tz =2 7 s
z
f
Strecke : ~2
ANTHROPOTEOHNISCHE GRUNDLAGEN DER INFORNATIONSDARSTELLUN6 AUF PROZESSREGHNERGESTEUERTEN SICHTGERATEN
R. NOOG
Aua anthropoteohnisoher Sioht wird sin Oberblick Ober grundlegande ZusammenhBnge zwischen menschliohsn Wahrnehmungsleistungen und versohiedenen MenngrBBen dsr Darstellung yon Information zu Montrollzweoken auf Siohtger~ten, insbesondare Fernsehmonitoren gegeben. Siohtgar~tewird man in Z~kunft in Wartenoft finden~Ihre speziellanEiganschaften mOseen beim Einsatz ber~cksichtigt werden, um im Rahmen des taohniseh und 8konomisoh NSgliohen zu einer optimalen Daratellung der Information zu kommen. Bei der Gestaltung der Informationsdarstellung auf SichtgerQten scheidet das langsame Mumulieren yon praktischen Erfahrungen als Wag zur Verbesserung der Nensch-Naschine-Mommunikation aus Zeit- und RisikogrQnden weitgehend aus. Somit mOssen anthropotechnische Gestaltungsregeln dutch Obertragung von Erfahrungen und auf Grund gezielter experimanteller Untersuchungen gewonnen werden. Bsi der Oberwachung sines Prozesses auf einem Bildschirm ist vom Beobachter in vielen F~llen aus einsr groBan Mange von Informationen eine bestimmte, for den vorliegenden Fall relevante Information herauszufinden. Diese Aufgaben bilden die meisten neueren Experimente nach, die sich mit der Erkennbarkeit von Symbolen besch~ftigen. Als abh~ngige Variable dienen meist Fehler oder ZeitmaSe (z.B. Zeit bis zum Auffinden der gewOnsohten Information). Weitere experimentells Zug~nge bestehen z.B. in der Messung der Zeit, die benStigt wird, um ein allein dargebotenes Symbol zu erkannen oder in der Ermittlung der Fehlerrate bei beschr~nkter Darbietungszeit des Symbols. Die LeistungsfQhigkeit des Systems Sichtger~t-Mensoh h~ngt von den technisohen Eigenschaften des Sichtger~tes, den physiologischen und psychologischen Eigenschaften des Menschen, v o n d e r gew~hlten Darstellungsart dee 8ildes und den Parametern der Darstellung ab. Auf die dabei auftretenden Problems wird hingewiesen und weiterfOhrende Literatur angegeben; einzelne ausgew~hlte Themen werden genauer behendelt. In naher Zukunft warden aus MostengrOndan im wssentlichen Fernsehmonitore Verwendung linden. Die Angabsn im vorliegenden Berioht beziehen sich deshalb haupta~ohlioh auf Fernsehmonitore und deren spezielle Eigensohaften (zeilenfSrmige Rasterung, Bildwiederholung, aktiv strahlend). Bai der Anwendung der Ergebnisse auf andere Systems (z.B. Dioden-Arrays mit Punktraster, FIOssigkristallanzaigen in Auf- oder Durchlioht, Spaichersichtger~te) ist die Obertragbarkeit zu prQfen. Das AuflBsungsverm~gen eines Fernsehmonitors h~ngt im wesentliohen ab yon der Zeilenzahl, der Bildweohselfrequenz und der Bandbreite des Videosignals.
257
FOr die Informationsdarstellung auf Sichtger~ten wichtige sinnesphysiologisohe Eigensohaften des visuellen Systems sind: - AuflGsungsvermBgen -
Sehwinkel
- Farbempfindlichkeit -
F!immerverschmelzungsfrequenz
N~heres findet sich z.B. in Gould (1968), Sohober (1964), Sherr (1970), Stevens (1966). Auf Grund der Eigenschaften des visuellen Systems lessen sioh sinnvolle Darstellungsparameter
(z.B. Halligkeit, Detailgr8Ge) w~hlen.
Die Information wird in Warren in codierter Form dargestellt. Codes sind so zu w~hlen, dab die verarbeitbare Informationsmenge groB, die Reaktionszeit kurz und die Fehlerrate klein warden. Obersioht Ober Eigsnscheften einiger Godierungeartsn Mc Cormick (1970); MIL-STD-1972 A; Morgan
(1963); Woodson e t a l . ,
- Farb-Oodierung: - ~-numarische Codierung
-
Formoodierung
(1973)
3-5 Stufan, besonders geeignst for Suchaufgaben
: GroGs Anzahl von Stufen, besonders geeignet for Identifikationsaufgaben : 10 bis max. 100 Stufen
- GrGBencodierung: 3 Stufen (log.Abstufungen sind vorzuziehen). Einfache MGglichkeit, Elemente in Listen hsrvorzuheben, geeignet zum grobsn Anzeigen der GreBe einer Variablen -
Blinken
: 3 Stufen (Bei einem Hell/Dunkel-Verh~ltnis yon I/I kommen ale Blinkfrequenzen I, 2-5 und 5 Hz in Frege. Blinkzeichen unterschiedlioher Frequsnz sollen keine Phasenverschiebung aufweisen,
auGerdem ist zu beachten~ de8
ein Fsld mit mehreren Blinkzeiohen unterschiedlicher Frequenz auf dis Dausr verwirrsnd wirkt.) Zur Darstellung yon gef~hrlichen ZustBnden empfohlen. - Helligkeitsoodierung -
Bewegungsoodierung
2 Stufen Geeignet zur Anzeige der FluS- oder Wirkungsriohtung
W~hrend Ober die Erkennbarkeit einzelner Symbole in Abh~ngigkeit von den Darstallungsparametern umfangreiohe experimentelle Untersuohungen vorliegen, ist die Frage der Verarbeitung komplexer Information und die Entsoheidungsfindung sin weitgehend ungelGstes Problem. Entspreehend liegen auBer einigen sehr allgemeinen Aussagsn (z.B.: Stalls nicht mehr Information dar, els for die Auf-
258
gabs erforderlich) ksine Gsstaltungsvorschl~ge
vat. Solche offenstehenden Fra-
gen sind z.B. - sinnvolle Symboldichte im Bild - Verh~ltnis Nutz-Gesamtinformation - Organisation der Information o Hierarohischer Aufbau • Entsohsidungshilfen Im folgenden wird dis Erkennbarkeit ~-numerischer und einfacher gsometrisoher Symbols bei der Darstellung auf dem Sichtger~t abh~ngig van verschiedenen EinfluBgrSBen unter besondsrer BerOcksichtigung der Rasterung behandelt. In der Regal let bei Fsrnsehsvstemen
die AuflSsung dee Bildschirms kleiner als
die dee menschlichen Augss. Aus MostengrOnden wird man besonders bei der D~rstellung van Svmbolen , dis slektronisch gespeiohert werden, die Rasterung magliehst grab w~hlen. Die Zeilenzahl sines 8ildschirms einerseits und die Rasterung sines Svmbols snderersaits bestimmen die Zahl der gleichzeitig dargestellten Svmbole. Je mehr untsrscheidbare Linien pro l~ngster Symbolachse aufgewendet werden, je fein~r man raster, um so weniger Svmbole kann man auf einem gegebenen Monitor darbieten. Andersrseits verringert sieh die Lesbarkeit der Svmbole, wenn die Anzahl dar untersoheidbaren optischen Linien oder Punkte pro l~ngster Svmbolachse,
also dis Svmbolaufl~sung
unter sin bestimmtes Minimum
sinkt. Die 1°Abbildung veranschaulicht die in diesem Zusammenhang wiehtigen geometrischen Variablen. Die Erkennbarkeit van Symbolen h@ngt u.a. ab van - der SymbolauflSsung -
dam Blickwinkel
- den absoluten Leuchtdichten - den Leuchtdichteverh~ltnissen (Hintergrund-, -
Svmbol-, Umgsbungsleuchtdichte)
den geometrischen Eigenschaften des Monitors (Verzerrungen)
-
der Blickrichtung des Beobachters
-
der Sehsch~rfe des Beobachters
Die einzelnen Gr~Ben sind dabei nioht unabh~ngig voneinander in ihrem Einflu8 suf dis Erkennbarkeit der Symbole. So kann z.B. dis Zeilenzahl nut dann getrennt vom Bliokwinkel untersuoht werden, wann einausreiohend
groBer Bliokwin-
kel vorliegt. ~-numerische Symbols in Punktrastern Die Mindestanzahl der benStigten Rasterpunkte pro ~-numerischem Symbol in Punkt-
259
rastern untersuehts VARTEBEDIAN (1970). Durch Mnopfdruok konnte sich die VPn einen Buchstaben w~hlen, der wieder verschwand, wenn die VPn den Mnopf loslieS. Gemessen wurden die Antwortzeit und die Fehler (Tab.2). VARTE8EDIAN fend, dab Buchstaben in 5 x 7 Rastern schlechter
erkannt warden als Buohstaben in 7 x 9
Rastern, schr~g gestellte GroBbuchstaben schlechter als ssnkrecht stehende Gro8buchstaben und Buchstaben aus in horizontaler Richtung gezerrten Rasterpunkten schwsrer zu erkennen sind als Buehstaben, die aus unverzerrten runden Punkten gebildet warden. In elmer weiteren Arbeit zeigte VARTEBEDIAN (1971), daB Worte aus GroSbuchstaben besser erkannt warden als Worte aus Mleinbuchstaben (Abb.3). In diesem Experiment verwendete er sine andere experimentelle Vorgehensweise. Er gab 27 Worte aus jeweils 5 Buchstaben pro Durchgang vet. 8el jedem Durchgang war sines der 27 Worts herauszusuohen. Wis Abb.3 zeigt, bestehen keine bedeutsamen Unterschiede zwischsn der Darstsllung van Buchstaben in 7 x 9 Punktrastern und in kontinuierliohsr Strichdarstellung. Der gleiehe Aurar entwickelte sin gOnstiges Alphabet for ~-numerisohe Symbole und einiga Sonderzeichen im 7 x 9 Raster (1973; Abb.4). Geometrische Symbols in Punktrastern Acht gerasterte Bildzeichen gleioher Momplexit~t, wie sie z.B. in Mosaikwarten Verwendung finden (Transformatoren, offene und geschlossene Schalter) wurden im Institut for Informationsverarbeitung in Technik und Biologie, Marlsruhe, untersueht. Dis Symbole wurden im 7 x 7 Punktraster, im 14 x 14 Punktrsster und ungerastert dargestellt (Abb. 5a, 5b). Wie Abb.6 zeigt, treten bedeutsame Unterschieds zwischsn des Darstellungsarten auf. Die Ergebnisse wurden mit Dies gewonnen, berOcksichtigen also nicht die spszifischen Eigsnschaften van Fernsshmonitoren. ~-numerische Symbols in Zeilenrastern Die n~chsten baiden Abbildungen geben typisohe Ergebnisse fQr ~-numerisohe Symbols im Zeilsnraster wieder (Abb.9 und 10). Bedeutsam ist, dab sinnvolle Worts aus 5 Buohstaben sins geringere SymbolauflBsung (?Zeilen) benatigen als einzelne ~-numerisehe Symbole bei gleicher Fehlerrate (99%). Die Lesegeschwindigkeit ist aber bei 10 Zeilen/Symbolh8ha bedeutend gr88er. Ein geeignetes Alphabet for Zeilenraatar stellt SHURTLEFF e t a l .
(1966) vet (Abb. 11).
Empfehlungen for ~-numerisehe Symbols in Zeilenrastern Die Symbolaufl8sung sollte minimal -
10 Zeilen pro HShe der ~-numsrischen Symbols betragen, wenn dis Erksnnungszeit bins Rolls spielt.
260
- 8 Zeilen pro SymbolhBhe betragen, wenn die Erkennungszeit keins odsr nut sine geringfOgige Rolls spislt. Geometrische Symbols in Zeilenrastern Die Erkennbarkeit einfaoher, aehr gut unterschsidbarer Symbols in Zeilenrsstern untersuchten ERIMSON e t a l .
(1969; Abb.7 und 8). 10 Zailen pro SYmbolh8he er-
soheinen for gut unterscheidbare Symbole ausreiohend. Auch wenn Bin einzelnee Symbol leicht zu erkennsn ist, kann seine Unterscheidbarksit nur im Zusammsnhang mit den Bbrigen Symbolen bestimmt werden. Z.B. kann sin Winkel leieht von einem Mreuz und sinem Mreis untarsohieden werden, schwieriger wird as seio, Quadrat, Rechtsck und Raute zu unterscheiden. Ein optimales Alphabet geometrisoher Symbole wird sich in absehbarer Zeit nut experimentell finden lassen. Auf jeden Fall eollte vsrmieden werden, mshr Symbols zu verwenden, ale unbedingt bsnBtigt werden. Empfehlun~en for einfaohe geometrische Symbols in Zeilenrastern -
Spielt die Erkennungszeit keine oder nur eine geringfOgige Rolle und Bind dis Symbols sehr gut zu unterscheiden, sell die minimale SymbolauflBsung 10 - 12 Zeilsn betragen.
-
Spielt die Erkennungszeit sine Rolls und sind die Symbols nicht optimal unterseheidbar, so ist sin Raster von mindsstens 14 x 14 Punkten zu wOhlen. Aussagen 8ber die Unterscheidbarkeit yon Symbolen sind experimentell zu ermitteln.
Blickwinkel Neben der SymbolauflSsung hat auoh der Bliokwinkel, unter dam Symbols erseheinan, sine Bedsutung for ihre Erkennbarksit. SEIBERT (naoh SHURTLEFF e t a l .
1963)
legte entsprechende Ergebnisse for ~-numerisehe Symbols vor (Abb. 12). Wesentlich gr88ere optimale Bliokwinkel als SEISERT land GIDDINGS (1972; Abb. lJ a/b). Empfehlung: - FOr ~-numsrische Symbols liegt der minimale Bliokwinksl, unter dam die l~ngste Aohse der Symbole erseheinen sell, bsi 12'. -
Slelohss gilt far optimal unterseheidbare gsometrische Symbols; bel Symbolen mit geringer Untersoheidbarkeit ist eher sin gr8Berer Blickwinkel zu empfehlen.
Zusammenhang zwischen Rasterung und Blickwinkel - FOr ~-numerische Symbole und die Symbols dsr Abb.7 1Bat sich in grober
26:~
N~herung ssgen, dab bei Zeilenrasterung
95 % richtige
Reaktionen zu er-
wartsn sind, wsnn gilt:
ZEI = 90' {12' ~ B ~ 16'} Debei ist Z die Zeilenzahl for die l~ngste Achse des Symbols (Symbolauflasung), B der Blickwinkel. Die Erkennbarkeit von Symbolsn verringert sich, wsnn die SymbolauflSsung kleiner wird. In dem oben angesprochenen Bereich l~Bt sich die Verschlechterung der Erkennbarkeit, die mit sbnehmender SymbolauflOsung eintritt, durch eine VergrSBerung des Blickwinkels ausgleichen. Abschlie8end werdsn einige welters Empfehlungen for die Darstellung von Symbolen zusammengestellt: -
Die optimale Strichdioke geometrischer Symbols betr~gt 1/10 bis I/8 der SymbolhShe (BOWEN et al.; 1960). Verh~ltnisse von 1/10 bis 1/6 werden for a-numsrische Symbols empfohlen. Nsch MOORE (1958) betr~gt dsr optimale horizontale Abstand zwischen a-numerischen Symbolen 10 bis 20 % der SymbolhGhe uod die optimals Symbolbrsite ~ 75 % der SymbolhShe. Diese Forderungsn kBnnen a-numerische Symbols in 7 x 9 Rastern reoht gut erfOllen.
- Die Striohleuchtdichte bei durchschnittlicher Umgebungsleuchtdichte soll mBglichst 50 fl. betragsn. Dos Montrastverh~ltnis zwischen Strichleuchtdichte und Leuchtdiohte des unbeschriebenen Schirms soll etwa 90 % betrsgen. Die durohschnittliche Umgebungslsuchtdichts soll nicht wssentlioh gr8Ber oder kleiner als die Leuchtdichte des Schirms sein. - Beobachtungswinkel gr8Ber 30 o sind zu vermeiden.
262
Literaturverzeichnis BOWEN, H., ANDREAS, J., TURAX, S., ORLANSMI, J.;
Optimum Symbols for Radar Displays, Human Factors 29 - 33 (1960)
Identification via Television: Size and Scan Lines
ERIMSON, R.A., HEMINGWAY, J.C.;
Nato Symposium, Munich, Germany, 29 - 59 (1969)
GIDDINGS, B.J.;
Alpha-Numerics
for Raster Displays, Ergonomics 15,
65 - 72 (1972)
GOULD, J.D.;
Visual Factors in the Design of Computer Controlled CRT Displays; Human Factors 10 (4), 359 - 376 (1968)
MOSMIDER, G. YOUNG, M.;
Studies in Display Symbol Legibility Part VIII: Legibility of Common Five-Letter Words, Mitre Corp. Bedford, Mass., TM-4 39 PT B ESD TR 65 - 385 (1966)
MC CORMICM, E.J.
The Human Engineering;
New York: Mc Craw Hill 1970
MIL-STB-1472 A
Department of Defence; Military Specification:
Human
Engineering Requirements for Military Systems, Equipment and Facilities; MOOG, R.:
1970;
Abh~ngigkeit der Erkennbarkeit sinfachsr geometrischer Symbole van dsr Anzahl der Rasterpunkts und dam Blickwinkel; unver~ffentlichter
MOORE, C.C., NIDA, P.M.;
Bericht (in Vorbereitung)
An Analysis of Lettering Styles for an Improved RasterType Data Display, Federal Aviation Agency,
Indianapo-
lis, 1958 MORGAN, C.T. et el.
Human Engineering Guide to Equipment Design; New York: No Grew Hill 1963
SCHOBER, H.;
Das Sehsn I, II; 3. Aufl., Leipzig: VEB Fachbuchverlag 1964
SHERR, S.;
Display System Design, New York: John Wiley & Sons 1970
SHURTLEFF, D . ,
Studies of Display Symbol of the Ratio of Width of In-
BOTHA, B., Young, M.;
active to Active Elements within a TV Scan Line and the Scan Pattern Used in Symbol Construction;
Mitre
Corp. Bedford, Mass., ESD TR 63 - 440 (1963) SHURTLEFF, D., OWEN, D;
Studies in Display Symbol Legibility Part VI: LEROY and COURTNEY Symbols, Mitre Corp. Bedford, Mass. TM 4212 ESD TR 65 -
136 (1966)
263
STEVENS, S.S.; Herausg. VARTEBED IAN, A.G.;
Handbook of Experimental Psychology, New York: John Wiley & Sons 1966 The Effect of Symbol Generation Method Slanting Dot Matrix Size, and Dot Geometry on Legibility, Information Display ~, 23 - 26 (1970
VARTEBED ]:AN, A.G.;
The Effects of Letter Size, Base and Generation Method on GRT Display Search Time, Human Factors, (1971) 363 - 368
VARTEBEDIAN, A.G.;
Developing a Graphic set for Gathode Ray Tube Display Using 7 x 9 Dot Pattern; Applied Ergenomics, 11 - 16 (1973)
WOODSON, W.E. and CONOVER, D.W.
Human Engineering Guide for Equipment Designers; Berklay-Los Angeles-London: University of California Press 1973
Abb.
1:
-
-
A1 :
:
:
A2
D
-
-
-
:
---
:
auf
Symbol
der
Darstellung
- Bildschirm
Ferllsehmonitar
bel
Beobachter
Symbol
Abstand
H5h9
Breite
Blickriohtung
Bllckwinkel
einem
Variable
van
Symbolen
Geometrlsche
Tab. 2:
677
659
814
6,7
4,5
7,7
3,2
2,6
2,9
% Fehler
1970)
Darstellungsarten van Buehstabsn (VARTEBEDIAN;
Reaktonszeiten und Fehlsr for versohiedene
schrQg gestellte Buehstaben; 5trichd.
8trichdarstellung
? x 9 Raster schr~g gestellte Buchstaben, in vsrtikaler Richtung verzerrte Rasterpunkte
678
602
7 x 9 Raster MreisfOrmige Punkte 7 x g Raster in vertikaler Richtung verzerrte Rasterpunkte
697
Reaktlonszelt
5 x 7 Raster 5reisfSrmige Punkte
Darstellungsart
DO
Abb.
N,7
3:
1971)
van der DarstellungBart der BuchBtaben und
der Ar~ der Buchstaben (VARTEBEDIAN;
Klein = Buch = slaben
t9.6 B l i c k w l n k e t
ReBktlanszeiten for Worte in Abh~ngigke~t
lZ2
Strich- O r
I
Abb. 4
.ill~ J.-.,
.~7 t
li_iit
ll_
irr:r.]..,~ ~lllk L= .,I/It, i+ill. ] E t[ , 'l . LLti
ETi
:
schlagene Alphabet
Das yon VARTEBEDIAN (1973) for Punktraster vorge-
f4,~7~
t~-N:I
~iTtlllZf
llti,'i~i r
k_q
266
Abb. 5 a:
Die von MOOG untersuchten
Svmbole
@~@@@
S°*~ °S
r
Abb. 5 b: Bildzelchen fQr Drosselspule in 7 x 7, 14 x 14 Raster und ungerastert
Abb. 6:
1
2
3
4
6
7
nicht gerostert
7X71~x14/~
=
...... D
~
Blickwh~ke!
Blickwinkel 110!
55 ~
Rasterpunktzahl pro Symbol (Moog)
geometrischen Svmbolen von Blickwinkel und
Abh@nglgkeit der Erkennbarkeit von 8 einfachen
.<
o
N
e}
Abb. 7:
~-
A
~
4~
A
0
Svmbole
untersuchten
©
0
0
Die von ERIMSON et. al. ( 1 9 6 9 )
-,'~-
A
E]
IX.,) ~4
Abb. 8:
r~
aj
o
0
j-
............ I !
5 10 15 Zeilen pro SymbolhShe [ Symbolaufl6sung ]
I
/
(nach ERIMSON; 1969)
Symbolen (s. Abb. 7) v o n d e r
Svmbolaufl6sung
Abh~ngigkeit der Erkennbarkeit von einfachen
~'0
0"
80
90 ¸
100
Blic'cwinkel 10.2 Minuten
O
C:
Abb. 9:
/
Y
Zeilen pro l~ngster Symbolochse
s ~ 7 ~ ~ lo h 12 1~
/
/
/
./
36 Symbole,
81ickwinkel 111 (SHURTLEFF und OWEN; 1966; s. auch Abb. 10)
Versuchspersonen;
beim Erkennen yon ~-numerlschen Svmbolen. HochgeObte
EinfluB der vertikalen Auf168ung auf die Fehlerzahl
T___ ..........
80
85'
90
95
100
fO O~ CO
269
CJ ~J
~0,8
"'%..
O,7 ~, 0.5 t
~o,s a 0,4 O.3 0.2 0,1 I
I
5
6
'
I ....
7
I
I
8
I
~
:
:
/~
9 10 11 12 13 oo Zeilen pro SymbolhShe
Abb. 10: EinfluB der vertikalen AuflSsung auf die Geschwindig keit, mlc der ~-numerische Symbole erkannt werden (s. auch Abb. 9) -o--~.~
nach SHURTLEFF und OWEN (1966) einzelne ~-numerische Symbole, Blickwinkel 11' nach MOSHIDER et.al. (1966) sinnvolle Worte (5 Buchstaben)
ABCDE
F GHI J kLMN
STUVWXYZ
Abb.
11:
Verbessertes (nach
OPQ R
123456789J~
LEROY-Alphabet
SHURTLEFF
et.
al.
for
1966)
Zeilenraster
270
c 100 C
.o 9 0 4~
80
o
Symbo/oufldsung -~ ~20
70. o .~ GO,
:
,u 5 0
x - - x 12
2"
40-
/
/"
/
30"
./
/
20"
=1G
~(
/
/
./
10" ..... I .......
I
,
I,,,
!
5
7
8
9
10
G
/7
,
A
'1,.
12
1G Blickwinkel
Abb. . . . 12: .
Erkennbarkeit ~-numerischer (Zeilen pro l~ngster
SHURTLEFF
Symbole
Symbolachse).
und SymbolauflSsung
sec (SEIBERT et. a. nach
~ 1.0"
~-. . . .
,, /x~
•~ 0.8
yon Blickwink81 4 Symbole/lO
et. a l . 1963)
1.0 0.9
in Abh~ngigkeit Darbietungszeit
in Minufen
/,,/~,'it'~!
~" " ~ - . . . . . " ~
""-
Y
:~ 0.9
~ o.8
~ 07 ~ 0.s § 0.5
,Y,'
//
!Z:;
///'
~:
.~
Zitfern
Woete
~
05
/
/
~ o.~ 0.3
Ziffern
~. O2
"~z 0.2
'.
~ 0.1
0.1 o
~,,
~,;'
I~" 21" 28' fickwinkel
A~b. 13 ~. 13 b: Relative £rkennungsgeschuindigkeit
Worte
0.3
o
~,
~,'
I~' 2~" BEckwinkel
.~8"
und relative Anzehl richtiger Reaktlonsn einzelner
Ziffern und Worte in Abh~ngigkeit vom Blickuinkel pro Symbolh0he ; 18' entsprechen 0,156 in. und 14 zeilen pro Symbolh6he ; 21 t 0,187 in. und 15 zeilen pro Symbolh~he. Die dis durchgezmgenen Linian umschlleBenden Linien geben das g5 % Konfidenzintervall an (nach GIODINGS;1972)
EIN KOMMUNIKATIONSSYSTEM ERFASSUNG VON
UND
ZUR
REAL-TIME
VERARBEITUNG
KLINISCH-CHEMISCHEN
K. KILLIAN,
M.
ON-LINE
MESSWERTEN
*
KNEDEL
i. Einleitung In klinisch-chemischen ster Linie dessen in kiirzester matischer Das
F~higkeit
Verarbeitung
der Patienten
Ausgabe
demnach
der Untersuchung Computer
den Dialog und Fehlern
gestatten.
,,,
N U T Z
R
E
E
I A Z T
~ ~.
mug.
FEHLERANZEIGEN AUSGEBEKR!TISCHERWERTE 8EDIENUNGSANWEISUNGEN VERLAUFSMELDUNGEN
PROGRAMMGENERATIONSANNEISUNGEN VERFAHRENSSPEZIFISCHE PARAMETER SUCHFRAGEN STEUERANWEISUNGEN ERGE8NISBERICHTE KONTROLLJOURNALE 6ER~TEAUSLASTUNG HATERIALVER8RAUCH mit d e m
MeI~platz
der Information
zur An-
Computer
OV-ProjektDVM004 des Bundesministers forForschun9undTechnologie
=
noeh im
daI~ jeder Arbeitsplatz
Hierbei
ausgetauscht.
MESSNERTE HESSBEREICH HESSART VEROUNNUNGSSTUFE FUHKTIONSUNDFEHLEREENNZEICHEN GERATEPARAHETER STEUERTNSTRUKTIONEN
Bild I: Informationsaustausch
Versorgung
als auch die kontinuierliche
VERFAHRENSKENNZEICHEN SERIENSTARTSEREENENDE NIEDERHOLUNG S~REN VONHESSWERTEN STEUERANWEESUNGEN
8 E
E
Daten
mathe-
zu pr~sentieren.
einzelnen
Dies hat zur Folge,
zusammenarbeiten
einfaeher
auf eine optimale am
in er-
Zahl von Informationen
zeitgerecht
zur Vervollst~ndigung
die in Bild 1 zusammengefagten
~ ~
*
im Hinblick
sowohl
eines Computers
und nach meist
m6glichst
Megergebnissen
yon Ergebnisberichten
autark mit dem lich
mug
Einsatz
eine sehr groge
zu korrelieren
und Kontrolle
im Krankenhaus
zeige yon kritischen
wird beim
ausgenutzt,
Zeit zu erfassen,
Programmsystem
Verlauf
Laboratorien
werden
grunds~tz-
272 Auger
dem
f~lr den Routinebetrieb
schiedenen
Arbeitspl~tzen
ger~te und Verfahren tet, dab w~hrend z.B.
des Labors
notwendigen
verlangt die stiirmische
Dialog
Entwicklung
an den ver-
neuer
den direkten Eingriff in das Programmsystem.
des Laborbetriebs
aus einer Modulbibliothek
auch ffir alle Anderungen
im Dialog neue
zusammengestellt
im Formularaufbau
AnalysenDas
bedeu-
Verarbeitungsprogramme werden
mfissen.
der Befundberichte
Dies gilt und der Unter-
suchungsantr[ge. 2. Die hard-ware Der
Struktur
on-line Anschlu~
l~i~t sich nach dem lisieren.
des Laborsystems von verschiedenen
Analysenger~ten
heutigen Stand der Technik
an einen
auf vier verschiedene
Computer Arten
rea-
Bild 2
J PROZESSELEMEN mT -, J" i PROZESSRECHNE iR
~
A I EIHA ' UsGABE I EINHEII
-i ~i MESSWERVTORVERARBET IUNGS~4'~ ~I J COMPUTEIR I ~ INHEIT "
B
BUS
GERXT EINBABEEINHEH
STEUERUNqG AUSGABEEINHEIT
Bild 2: on-line Anschlu~arten Fall mu2
zu einem
Mensch-Ma6chine-Dialog
zwischen
jedoch neben
den drei Partnern
J
"1
PROZESSRECHNER
I
I
von Analyseger~ten
In jedem
sein. Dies verlangt yon dem
']
der on-line Me~werterfassung
die M6glichkeit
fiber Ein- und Ausgabeeinheiten
Dialogsystem Mei~ger~t,
die Koordination
Mensch,
Computer.
realisiert
eines Gespr~ches Das
Pr~if- und An-
273
weis~mgsprogramm wenn
kann demnach
alle zum
matisch
Me~wert
arbeitenden
eingegeben
wird,
M6glichkeit
gehSrigen
Angaben
Me~pl~tzen,
ist dieser
Bild 3 zeigt, k6nnen bationszeiten
erst dann eine sinnvolle
bei denen
asynchrone
mehrere
Mel~werte
vorhanden
rnern im Computer
werden
gespeichert
wert vorgenommen,
sen,
eine weitere
I-
dieses Systems
ist jedoeh,
auftreten kann.
entweder
im Programm
eine hard-ware
Bild 3: Externe
Synchronisation
Da der Speicherplatz
im Computer
vollst~ndige
Vergesslichkeit
zu kostbar
Ergebniss~tze
Schnittstelle
ter nicht mit der Abwicklung
Me{~ger~t,
Mensch,
am
ist und ferner
Arbeitsplatz
Puffer oder
auch ohne on-line
vorliegen
sollten, wur-
Sie bieten au~erdem
den Vorteil,
filr alle verschiedenen
des Signalspiels
Maschine
einfacher
Ger~te
zur Datenerfassung
der Compuiiber Prozel~-
belastet wird.
Fall D in Bild 2 kann als Idealfall eines dialogf~ihigen
werden,
ein
..I
far die Unterbringung
Bild 2 B) bis D) entwickelt.
daI~ ~iber eine genormte
Der
zu 16-
'I,°-. i I
des Dialogs,
Zeitkontrollroutinen
den die L6sungen
element
Diez. ]3.
Verbindung
L.
Verbindung
iVief~-
J
~ ' TASTATJIR"I' [S C IHTGERL [~T
komplizierter
die Num-
COMPUTER ] J"% 1VERARBET I UNGS)I PROGRAMM
I
........
_
die
wird.
" _
hat damit
den eintreffenden
oder durch menschliche
STEUERUNG l
]
und Inku-
Erfassung
eine Verschiebung
Vereinbarung
sodal~ bei Ausfall einer Leitung
Wie
Mischvorg~nge
durch
Nachteil
(i) oder durch
eingeblendet
problematisch.
irn Fall der getrennten
und die Zuordnung
Zeitfenster
"Pseudodatensatz"
durch
manuell
vor oder nach der Untersuehungs-gut-Zu-
dab bei Ausfall eines der beiden Kan~le
vorgegebene
bei halbauto-
sein. Die Assistentin
(Fist in, fist out). Der
ser Fall ist nur durch
sind. Gerade
Dialog besonders
die Patientenidentifikation Hierbei
durchffihren,
die Patientenidentifikation
im Mel~ger~it hervorgerufen
f~ihrung einzugeben.
durch
vorhanden
Ausgabe
der entsprechend
B mit SILAB l~uft. Hierbei
dem
heutigen
Stand der Technik
- Mel~wertvorverarbeitungseinheiten werden
zur Eingabe
Me~platzes
angesehen
in der Ger~iteanordnung
(2) bereits im Routinebetrieb
meist R6hrchenleser,
Tastaturen,
Markierungs-
274
leser eingesetzt drucker
und zur Anzeige
von Fehlern
und Bedienungsanweisungen
Klein-
oder Sichtger~te.
3. Die v e r s c h i e d e n e n F o r m e n des Me n s q h - M a s c h i n e - D i a l o g s in k l i n i s c h e n L a b o r a -
torien E i n f u n d a m e n t a ~ e s M o d e l l ffir den M e n s c h - M a s c h i n e - D i a l o g i s t das yon NEWMAN (3) a n g e g e b e n e
Z w e i k r e i s s y s t e m Bild 4. Jeder Kreis
e i n t e i l e n : die P h a s e d e r D a t e n e r m i t t l u n g bzw.
l~Bt sich in vier Phasen
Datenverarbeitung,
d e r D a t e n an d e n A n d e r e n , die W a r t e z e i t w~hrend
der andere
das Abgeben
Proze~
l~uft und
d e r e r n e u t e E m p f a n g yon D a t e n . ,
DER8ENUTZERLIEST OIE AUSGABE
I
OER8ENUTZER l ERMTTTELTNEUEOATEN DER8ENUTZERGIBT ~.,OIEOATENEIN ; BENUTZER
OAS PROGrAMM ~'~ LIEST OIE OATEH OAS PROGRAMN VERARBEIET OIE OATEH OAS PROGRAMN GIBT OATEN A~ OAS PROGRAMM NARTET
k,
J PROGRAMM
Bild 4: Das f u n d a m e n t a l e D i a l o g m o d e l l von NEWMANN Betrachtet m a n zun~chst den Startpunkt der beiden Zyklen, so liegt die Initialisierung des Dialogs hervorgerufen durch den freien Arbeitsablauf im Laboratorium grunds~tzlich auf der Benutzerseite. Das P r o g r a m m
m u ~ demzufolge stets
auf einem Eingabestatement stehen oder aber der Computer fiber eine externe Interrupteinrichtung verffigen. (Prozei~rechner) Bei d e m Anschlu~ m e h r e r e r Mel~ger~te m u ~ das Modell erweitert werden. Hierbei treten die yon W O H L R A P P
(4) angegebenen Typen der Prozel~organisation auf.
• Sequentielle Auftragserteilung und Durchffihrung Vom
Programm(soft-ware
device-polling)oder yon einem freilaufen-
den externen Multiplexer(hard-ware
device-polling)wird ein Eingangs-
kanal (Ger~t) naeh d e m anderen sequentiell oder nach festgelegten internen oder externen Priorit~ten bedient, wobei jeweils auf das Ende tier Durchffihrung jedes Auftrages gewartet wird. oParallele Auftragserteilung und Durchffihrung Vom Programm
oder yon einem freilaufenden externen Multiplexer
werden sequentiell oder nach intern oder extern vorgegebenen Prio-
275
rit~ten die Eingangskan~le bedient ohne das Ende der Auftragsdurchf0hrung abzuwarten. Bei der parallelen Abarbeitung entsteht, bezogen auf die Gesamtheit der Analysenger~te, ein a s y n c h r o n e r Dialogbetrieb, der sich d u t c h die festen Taktzeiten mit denen die Analyseautomaten ihre Me~werte ermitteln in der L a b o r a u t o m a t i s i e r u n g d u r c h g e s e t z t hat. Der einzelne Mel~platz arbeitet hingegen auf Grund der Ger~testeuerung sequentiell. Bei Systemen (z. B. SILAB-System ( 2 ) ) bei denen durch externe Multiplexer bzw. Adre~steuerwerke nut je ein Eingangsund Ausgangskanal zum Computer existiert (Bild 5) muI~ ffir diesen asynchrone n Dialog auf der Eingangsseite und der Ausgangsseite ein Informationspuffer P E ' PA vorhanden sein. Der Eingangspuffer l ~ t sich so als Serien-paratlel-Wandler, der Ausgangspuffer als P a r a l l e l - S e r i e n w a n d l e r auffassen. Hierbei ist es jedoch wichtig, dab vor Eintreffen der n~chsten Daten desselben Arbeitsplatzes die V e r arbeitung und eine gegebenenfalls notwendige Ausgabe stattgefunden hat. D STEUERUNG
~6:SEII~;6BEEREI;HEIT D-DEUCKER Bild 5: Anschluf~schema m e h r e r e r dialogf~higer Arbeitspl~tze m i t Bausteinen des S I L A B - S y s t e m s (2) Der Zugriff zu den beiden Puffern P E und PA erfolgt fiber Zeiger, deren Anderung verbunden mit dem Einschreiben bzw, Auslesen bet paratlelen Systemen einen sogenannten kritischen P r o g r a m m a b s c h n i t t (5) bildet, der mit Hilfe einer Sperrvariablen
m
(Semaphor)
bar ablaufen mul~. Der
(6)die mit + linitialisiert ist, nicht unterbrech-
Zugriff zu solchen Puffern l~uft demnach
nach folgendem
Schema: P (PE'
m)
weit
Information
eintragen
< ZeigerE~
+ Informations--~Zeiger l~nge
V (PE' m)
P (PE' m)
E
Information
auslesen
< ZeigerA~+
Informationsl~nge -~ Zeiger A
V (PE' m)
276
IF
ZeigerE~ = ~ZeigerA~ THEN e n d e E L S E weit Analog PA
mit
P
= S p e r r o p e r a t i o n ffir d a s B e t r i e b s s y s t e m
m i t Hilfe d e s S e m a p h o r s V = Freigabeoperation
m
ffir das Betriebssystem
mit Hilfe des Semaphors
m
Eine weitere Einteilung des Mensch-Maschine-Dialogs Verarbeitungsprogramms
ist dutch die Struktur des
g e g e b e n . H i e r l a s s e n s i c h die d r e i A r t e n : Dialog mit vorgegebener Tabetle Dialog mit Modell der Au2enwelt Dialog mit Befehlen
u n t e r s c h e i d e n , d i e in d e n f o l g e n d e n K a p i t e l n irn E i n z e l n e n d i s k u t i e r t w e r d e n . 3.1. Dialog mit vorgegebener Tabelle B e i S y s t e m e n z u r r e i n e n D a t e n e r f a s s u n g z . B . die A u f n a h m e d e r S t a m m d a t e n d e r P a t i e n t e n f i b e r S i c h t g e r ~ t , die E i n g a b e yon M e 2 w e r t e n fiber T a s t a t u r bzw. F e r n s c h r e i b e r o d e r d a s E i n l e s e n yon L a b o r a n f o r d e r u n g e n auf M a r k i e r u n g s f o r m u l a t e n fiber B e l e g l e s e r l~l~t s i c h d i e P r o g r a m m s t r u k t u r
des Dialogprograrnms
p r i n z i p i e l l in e i n e r T a b e l l e f e s t l e g e n , die s e q u e n t i e l l a b g e a r b e i t e t w i r d . D e r Dialogbetrieb ist damit rein sequentiell. Die T a b e t l e h a t in s o l c h e n P r o g r a m m e n A.
I
ART AUS
El
ART EIN
AUSGABEADRESSE
das grunds~tzliche Format:
AUSGABETEXTFO~HAT,
i EINGA~/~ESSE
,,,,,, EINGA~TEXY~MAT
D e r K o n t r o l l c o d e gibt d i e F o l g e d e r P r o g r a m m e
KONTROLLCOOE
ERGE~IS~ES~
an die z u r P r f i f u n g d e r e i n g e -
g e b e n e n D a t e n d u r c h l a u f e n w e r d e n m u ~ . H i e r k 6 n n e n auch in A b h ~ n g i g k e i t d e r e i n g e g e b e n e n D a t e n Sprfinge in d e r L i s t e a n g e g e b e n w e r d e n . W i r d z . B . b e i d e r P a t i e n t e n a u f n a h m e d a s G e s c h l e c h t m i t " w e i b l i c h " a n g e g e b e n , so e r w a r t e t d a s Programm
als n~chstes die Eingabe des M~dchennamens.
Bei tier Eingabe
" m ~ n n l i e h " w i r d die A b f r a g e i i b e r s p r u n g e n . Eine weitere Besonderheit dieser Dialogtechnik, -Bild 6 zeigt die Me~werterfassung fiber Fernschreiber,
wahlweise Verfahrens-
oder Patientennummern
277
orientiert-,
ist die Ausgabe
der yore Programm
festgestellten
Fehler.
MEPA;; 10 MEPA 7053 - 8572 BELEGT GI B BLATTSCHREIBERNUMMER O; EINGABE VON MESSWERTEN IN DIE PDAT DATUM:07.03. I~,;
UHR: 12;
PNR/VNR/TAG/ENDE PNR; PNR: 444717;B R A N D H 0 F E R VNR: 9[]9~;MW :98.~;ZI :H; VNR: ;
PNR: ; PNR/VNR/TAG/ENDE 10 MEPA
ENDE;
7053 -
Bild 6: Me~werterfassungsdialog
8572 FREI
fiber Fernschreiber
Im einfachsten
Fall erfolgt nach Eingabe
Fehlermeldung
F
r
des r-ten durch
einer Information
den Kontrollcode
entsprechend
E. die J Programms
angesprochenen
K
. Dies hat zur Folge, da/~ die restlichen n-r Kontrollen nicht durchlaufen wurr den und damit bei Neueingabe wieder ein Fehler auftreten kann. Es ist demnach sinnvoll,
alle Fehlerprogramme
fehlermeldung
K 1 bis Kn
zu durchlaufen
und dann eine Sammel-
F 1 bis Fn auszugeben.
Bei vollautomatischen
Arbeitspl~tzen
reicht beim
wertsatz
E. nicht aus,
urn alle Fehler
entsprechend
Starten einer Serie ein Me~zu erkennen,
soda~ hier
Ej, Ej+ 1, Ej+ t die Sammelfehlermeldung, gegebenenfalls das Neustarten der Serie anzeigt.
erst nach einer Folge
3. 2. Dialog mit Pr~ifung am Zerlegt
man
Modell
den technologischen
ne Elementaroperationen der T~tigkeit durch
de r AuSenwelt ProzeS
an den Mei~pl~tzen
der Automatisierungsgrad
angeben:
aiti (0i) A=
i=l n biti (0 i) i=l
wobei
in einzel-
01 his 0n und mist die Zeit ti (0 i) f~ir die Durchffihrung
0i, so l~St sich nach H. KORTUIV[
die Formel
im Labor
ai~
[0, I}
0 1
=~ A=
nicht automatisiert automatisie rt
A
278 F
b i 6 J0, 1|
0
i
nicht mechanisiert
1
~-
mechanisiert
D e r A u t o m a t i s i e r u n g s g r a d A ffir die A r b e i t s p l ~ t z e w i r d d e m n a c h e i n e r s e i t s d u r c h die M e c h a n i s i e r u n g d e r s e l b e n (z. B. s e l b s t a t i g e P r o b e n z u f u h r , Verdfirmung, M i s c h u n g m i t R e a g e n z i e n usw. ) und a n d e r e r s e i t s d u t c h die S t r u k t u r des P r o g r a m m s y s t e m s i m C o m p u t e r b e s t i m m t . F i i r den M e n s c h - M ~ s c h i n e - D i a l o g b e deutet d i e s , dab m S g l i c h s t v i e l e E t e m e n t a r o p e r a t i o n e n 0. d e n F a k t o r a.=l e r h a l 1
1
t e n und n u t die a u ~ e r h a l b d e r R o u t i n e l i e g e n d e n S o n d e r f ~ l t e m a n u e l l b e h a n d e l t w e r d e n . D i e s e a l s M A N A G E M E N T BY E X C E P T I O N b e z e i c h n e t e Methode, die dem B e n u t z e r n u r d i e j e n i g e I n f o r m a t i o n z u l e i t e t , auf die e r r e a g i e r e n mu~, l ~ t s i c h i m C o m p u t e r d u r c h e i n M o d e l l d e r Au~enwelt (7) r e a l i s i e r e n . B e t r a c h t e t m a n das T e i l g e b i e t d e r M e l ~ w e r t k o n t r o l l e und V e r a r b e i t u n g so e r g e b e n s i c h die in Bild 7 d a r g e s t e l l t e n B e r e i c h e , die u n t e r s c h i e d l i c h e R e a k t i o n e n des P r o g r a m m s y s t e m s
auslSsen.
NERT !
!
l
N~
I
~I Wi .....
l
I
'~INi
A2 Ni
MESSGENAUIGKEITSINTERVALL HELDEBEREEH
~ Ni
~ Wi
A3 Wi
Bild 7: Entscheidungsbereiche Systems
!
yon WOLTERS
ANWEISUNGSBEREICH
bei der Me~wertkontrolle (8)
(Erreichung
des
)
S t r e u e n die M e ~ w e r t e W i i m B e r e i c h + ~ 1Wi so r e a g i e r t d a s P r o g r a m m f i b e r haupt n i c h t auf die a n k o m m e n d e n W e r t e und l e i t e t die V e r a r b e i t u n g ein. D e r D i a log w i r d d e m n a c h i m halb d e r B e r e i c h e
C o m p u t e r u n t e r d r f i c k t . L i e g e n die W e r t e W i j e d o c h a u ~ e r -
+ A 2Wi so w i r d e i n e b e t r e f f e n d e M e l d u n g a u s g e g e b e n und d e r
F e h l e r i n t e r n b e h o b e n , soda~ tier D i a l o g i n d i e s e m F a l l auf d e r B e n u t z e r s e i t e aufh6rt. Als B e i s p i e l h i e r f i i r s e i die e i n f a c h s t e F o r m d e r a u t o m a t i s c h e n D r i f t k o r r e k t u r g e n a n n t , b e i d e r alle n - W e r t e z w i s c h e n zwei K o n t r o l l p r o b e n K z m i t Ki + 1 b e k a u n t e n E r g e b n i s w e r t m i t e i n e m F a k t o r h K.-K. h
= F
(Ki-Ki+ I, n)
=
l
z + 1
n+l
W'.j = j . h W . 1 angeglichen werden.
j = 1,2,3,
.... n
279
Zu d i e s e m B e r e i c h g e h S r e n auch B e d i e n u n g s f e h l e r , die vom C o m p u t e r d u r c h e n t sprechende U m r e c h n u n g oder durch Ger~tesignale behoben werden k6nnen. E r gibt s i c h z . B . d e r E r g e b n i s w e r t E . , d e s V e r f a h r e n s j aus d e r B e z i e h u n g 1j Eij = aj l g W i j so rnfi~te am G e r ~ t d e r F a k t o r a. e i n g e s t e l l t und die T a s t e lg gedrfickt s e i n . I s t J d i e s n i c h t d e r F a l l , so k a n n e n t w e d e r fiber S t e u e r s i g n a l e die E i n s t e l l u n g a u t o m a t i s c h v o r g e n o m m e n o d e r a b e r die m a t h e m a t i s c h e U m f o r m u n g m i t d e m i m P r o g r a m m a n g e g e b e n e n F a k t o r a, d u r c h g e f f i h r t w e r d e n . 3 Bet W e r t e n i m B e r e i c h + ~ 3 w e r h ~ l t die A s s i s t e n t i n e i n e h i e r f f i r b e s t i m m t e B e d i e n u n g s a n w e i s u n g Bild 8
FOT1 K K AUTI AUT!
VERD.FAKTOR - 0 SETZEN PRAEZIS IONSKONTROLLE AUSSERHALB SERIEBIS 94.2 GESPERRT TNR 162 PEAK FEHLT TNR I(;2 MESSG,.WlEDoHOL°
Bild 8: Bedienungsanweisungen Das
Programm
behebung
bricht die Messung
wieder
Ein Sonderfall
bet diesem
modellgesteuerten
yon Mefiwerten.
jedern Fall eine Fehlerkorrektur so erfolgt schon
sichtlich zurn Zeitpunkt nungsanweisung
.....
s°LLI...........
zu einem
,..,..~
Bild 9: Trend
zeigt Bild 9, ffir die Kon-
Hier wird im Bereich
durchgeffihrt.
Zeigi n~mlich
frfiheren Zeitpunkt
........
im Korrekturbereich
.'...~...;....)
....
.... 1 .... L'
.........
L l_, _ -r,.-F-. i I i '1:1 '1:2
2Wi nicht in
die Me6serie
ger~t und damit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.'. ........................
+ ~
t~ die Meldung,
wird.
.... ".__-,:f F ........ I
Dialog
t 2 die Serie au2er Kontrolle
notwendig
_ ....
Fehler-
fort.
trolle fiber den Verlauf
Trend,
ab und setzt sie erst nach erfolgter
einen
daf~ vorauseine Bedie-
28o
3. 3. Dialog mit Befehlen In vielen F~llen ist es notwendig, den Computer zu speziellen T~tigkeiten zu veranlassen, d.H. der Dialog bezieht sich nicht auf die Diskussion der eingegebenen Information, sondern auf die darin enthaltene Anweisung. Hierzu m u ~ ein sogenannies "Bedienungsprogramm"
existieren, das m6glichst die gewfinschten T~tig-
keiten gegebenenfalls dutch Bereitstellen und Starten der entspreehenden Programme
durchffhrt. Im Laboratoriumsbetrieb ergeben sich die folgenden M 6 g -
lichkeiten ffir diesen Betrieb: Eingabe von Codeworten z.B. L J S D Laborjournal drucken PJSD
Pr~zisionsjournal drucken
LAEN
Laborsystem beenden
NFRE
14-20 MeSwerte yon laufender Nummer
14 - 20 sperren
E i n g a b e von b e s t i m m t e n P a t i e n t e n n u m m e r n d i r e k t v o m A r b e i t s p l a t z aus in die S e r i e z . B . 999
Serie starten
939
S e r i e s p e r r e n h i s zu m l e t z t e n r i c h tigen Kontrollwert
942
Pr~zisionskontrolle
Eingabe yon speziellen Zusatzinformationen z. B. Verd0nnung = 9, Serie abbrechen E i n g a b e von e x t r e m e n M e 2 w e r t e n z. B. 90 S k a l e n t e i l e z u m S t a r t e n e i n e r S e r i e m i t gleichzeitige r Synchronisation We r t - P a t i e n t e n i d e n t i f i k a t i o n E i n S o n d e r f a l l d i e s e r D i a l o g a r t i s t die i n t e r a k t i v e V a r i a t i o n yon P r o g r a m m e n d u r c h : 4 n d eru n g o d e r N e u e i n g a b e yon P a r a m e t e r n
und L i s t e n i m r e a l - t i m e B e -
t r i e b . D a m i t l~fit s i c h d e r n o c h l a u f e n d e D i a l o g an den e i n z e l n e n A r b e i t s p l ~ t z e n d u r c h e i n e n z e n t r a l e n E i n g r i f f v e r ~ n d e r n , w o d u r c h yore e i n z e l n e n A r b e i t s p t a t z b e t r a c h t e t d e r C o m p u t e r g e z i e l t s e i n e M e i n u n g w e c h s e l t . M e ~ w e r t e , die s o e b e n
281
noch
als richtig angenommen
Grenzen
mit entsprechender
4. Schlu~beme
jederzeit und Computer
Programm
durchfiihren
zentraler
Anderung
der
verworfen.
eine Forderung,
aller mSglichen
Zust~nde
tabellentechnik
und dutch
werden
klinisch-chemischer
kann.
aller notwendigen
die nut dutch Funktionen
computergerechte
zwischen
Dies verlangt
auf alle Situationen,
mit deren
Laboratorien
ein Gespr~ch
zu kSnnen.
und den Empfang
die Reaktionen
kSnnen:
bearbeitet
so nach
an allen Arbeitspl~tzen
gabe aller Funktionsdaten
werden
Fehlermeldung
fflr die Rationalisierung
MSglichkeit MefSger~t
werden
rkung
Entscheidend
vom
wurden,
die vom
systematische z.B.
vom
ist die
Mensch, Ger~i
Steuersignale Benutzer
die Abund
ausgelSst
Zusammenstellung
mit Hilfe der Entscheidungs-
Analysenger~te
zufriedensiellend
282
(1)
A. PORTH Probleme,
praktische L6sungen
benidentifizierung ehemischen
(2)
und theoretische Begrfindungen
beim Einsatz yon Proze6rechnersystemen
Laboratorium
mit on-line angeschlossenen
V. BECKMANN,
W.
HAAS,
Automatisierung
klinisch-chemischer
der Pro-
irn Klinisch-
Analysenger~ten.
K. KILLIAN Laboratorien
durch EDV
Diagnos-
tik 6/72 M. KNEDEL Datenverarbeitung
im Klinisch-chemischen
Institut am St~dt. Krankenhaus
Mfinehen-Harlaching Ein System Siemens
(3)
W.
M.
im Aufbau
Sehrift MC
C. Hanser
"Display use for Man-Machine-Dialog"
Verlag 1972
E. WOHLRAPP Auftragsbeziehungen Elektronische
(5)
1972
NEWMAN
Tagungsbericht
(4)
50/1016/
in Betriebssystemen
Rechnanlagen
F. L. BAUER,
2/72
G. GOOS
Informatik zweiter Tell Springer Verlag Heidelberger
(6)
E. W.
(7)
ACM,
"THE"-
Multiprograrnming
System
Vol. 11/1968
K. STEINBUCH Taschenbuch
der Nachrichtenverarbeitung
2. Auflage Springer-Verlag
(8)
Band 91/1971
DIJKSTRA
The Structur of the Comm.
Taschenbficher
M.
1967
F. WOLTERS
~Iber einige Perspektiven Vortrag
"VISODATA
der Mensch-Maschine-Kooperation
73" M~nehen
1973
DIALOGF~IIGES AUFTRAGSDISPOSITIONSSYSTEM AUF DER BASIS RECHNERUNTERST~TZTER BETRIEBSDATENERFASSUNG UND -VERARBEITUNG
T. Pfeifer,
U. B~ck
Die Rationalisierungsbem~hungen tierter Produktionsprozesse
innerhalb
fertigungstechnisch
orien-
sind in zunehmendem MaSe auf die Automati-
sierung des immer komplexer werdenden
Informationsflusses
Der Grund hierf~r
dab sich das reale Betriebsge-
ist darin zu sehen,
schehen zu einem e n t s c h e i d e n d e n A n t e i l der Fertigung
selbst vollzieht.
in der Planung und Durchf~hrung
Gerade in diese zentralen Bereiche
flieBt jedoch zur Zeit auch in Unternehmen, sationsstruktur der Produktion
verf~gen,
Planungsmechanismen, im Fertigungsablauf
Informationen
bereits ge~nderten
notwendig werden. allerdings
Fertigungsgeschehen
In speziell diesem
st~tzt.
aktueller Daten
Treffen zu sp~t
und daraus abgeleitete MaSnahmen
Betriebszustand,
auf einen
so wird das aus FertigungsprozeB
nes rechnerunterst~tzten
Betriebsdatenerfassungssystems
ROckkopplung
k~n-
nur dann wirkungsvoll
Regelungssystem
Fertigungsproze8
ist.
jedoch auch aufgrund
und Steuerung bestehende verzSgerungsfreie
oder
die heute im allgemeinen mit Hilfe
wenn er sich auf eine Mindestmenge
aus dem augenblicklichen vorliegende
durchzuf~hren
durchgefOhrt werden,
Fall kann ein Umdispositionsvorgang durchgef~hrt werden,
besonders
vom reinen Auftrags- bzw. Fertigungsprofil
von Datenverarbeitungsanlagen von St~rungen
wird in Betrieben mit
eine neue Dispositionsrechnung
in relativ kurzen Zeitspannen
Neben einer Abh~ngigkeit hen derartige
aus des
geringen Fertigungsst~ckzahlen
da hier ganz zwangsl~ufig
Umdisposition
Datenmenge
Informationsr~ckkopplung
in die Planungsebene
groBem F e r t i g u n g s s p e k t r u m u n d sp~rbar,
die ~ber eine gute Organi-
meist nur eine unzureichende
zur~ck. Diese mangelhafte
realen Produktionsgeschehens
ausgerichtet.
instabil.
Ziel und Aufgabe eimu~ daher die
einer Betriebsinformationsmenge
aus dem
sein. Um die mit einem solchen Datenerfassungssystem
gewonnene hohe Fertigungstransparenz
voll aussch~pfen
zu k~nnen,
ist
darOber hinaus die Verbindung
zu vorgelagerten
wie Terminplanung,
Durch die ~bernahme des mittels Modular-
progrmnmen
notwendig.
auf einem Betriebsrechner
erstellten Maschinenbelegungsplans
in den betriebsnahen
Fertigungsrechner
Informationsr~ckflu~
vonder
den Rechner zu schlieSen. die Verarbeitung, durch,
Bereichen und Vorg~ngen,
ist es weiterhin mSglich,
Fertigungssteuerung
Der Fertigungsrechner
his zum
f~hrt in diesem Fall
t~berwachung und Ausgabe von eingeplanten
so dab eine rechnerunterst0tzte
zeBnahen Steuerungsebene
vorliegt,
mal einem Tag ber~cksichtigen.
den
ProzeB ~ber
Auftragsdisposition
Auftr~gen auf der pro-
die einen Planungszeitraum
Das System ist dadurch
von maxi-
in der Lage, die
284
angestrebte kurzfristige
~bermittlung
so dab dem Maschinenbediener nes Auftrages die Belege
von Steueranweisungen
unmittelbar
daS ein nach dem bisher ~blichen
Arbeitsablauf bei StSrungen ge~ndert werden muB.
Im Bild 1 ist ein Fertigungssteuerungssystem zwischen zwei Planungsstufen
unterschieden,
dargestellt.
Im folgenden soll die dargestellte
fassung und Auftragszuordnung
ergeben.
On-line-Betriebsdatener-
in einem dynamischen
Bedingungen vollzieht,
hohen Planungsfrequenzen,
ProzeB unter stets
werden sich in der
wie einem Tag,
P taxis auch bei
stets Abweichungen
vom Plan
Aus diesem Grunde muB unmittelbar bei der Durchf~hrung
Mensch noch eingeschaltet bleiben, menschliche
Entscheidungen,
Anweisungen
umgesetzt werden.
Das Dispositionssystem
so dab Rechnerentscheidungen
begr~ndet auf Systemauskunft,
erh~it v o n d e r
festen Rahmen und muS nach dem Prinzip ten. Das bedeutet, einzugreifen.
notwendig
Fertigungsplanung automatisch
sein kann, manuell
Die Funktion des Menschen
der dutch
in konkrete
einen
"Management by Exception"
dab die Auftragszuordnung
es nur im St~rungsfall
t~g-
und Steuerungssystem
n~her behandelt werden.
Da sich die "Durchf~hrung" wechselnden
Es wird
wobei die Feinplanung
lich einen Teilplan an das On-line-t~berwachungs~bergibt.
ei-
f~r einen neuen zu bearbeitenden Auftrag ~ber-
mittelt werden. Dadurch wird vermieden, System ausgegebener
auszuf~hren,
nach einer Fertigmeldung
arbei-
abl~uft und
in den Systemablauf
in diesem Kommunikationssystem
"Mensch - Maschine" wandelt sich dabei sehr stark. Es ist ibm ein flexibles, reaktionsschnelles
Fertigungslenkungsinstrument
stellt. Angaben ~ber abgearbeitete disch,
zur Verf~gung ge-
und Restarbeitsauftr~ge
werden perio-
z.B. t~glich der n~chst h~heren Stufe zur Verf~gung gestellt.
neu erstellte Maschinenbelegungsplan
Der
wird danach vom On-line-System
~bernommen. Informationsgliederunq: Die in der Fertigung
zu erfassenden Daten kSnnen in folgende Hauptgrup-
pen aufgeteilt werden: - maschinenbezogene
Daten zur Maschinen~berwachung
- auftragsbezogene Daten zur Auftragsverfolgung, Materialflu~steuerung und Kostenrechnung -
transportbezogene
- qualit~tsbezogene - personanbezogene
Termin~berwachung,
Daten zur Transportanalyse Daten zur Qualit~ts~berwachung Daten zur Lohnabrechnung
Hierbei wird durch eine geeignete Datenerfassung
(Grund-Software)
ange-
285
strebt,
s~mtliche
den Informationen der erfaSten geordnet,
fur
Daten kSnnen die
ausgewertet
gespeichert
die verschiedenen
Betriebsbereiehe
Informationen
und e r n e u t
mittels
in Dateien
o d e r i n Form von B e r i c h t e n
als
yon Displayger~ten
die MSglichkeit,
Informationen
durch ein kurzfristiges
Eingreifen
bung yon Unregelm~Sigkeiten zyklisch
ablaufen,
quasi-kontinuierlich gangs erw~hnt,
erfolgt,
auf die Benutzerw~nsche auszugeben,
wo-
zur Behe-
Da d i e Z u s a t z p r o g r a m m e
der Daten mit der Grundsoftware
werden sinnvollerweise,
die anfallenden
Rechnersystemen
an die verschie-
in das Betriebsgeschehen ist.
Daten ab-
durch den Einsatz
und ~bersichtlich
ermSglicht
das Erfassen
besteht
gezielte,
schnell
Zusatzprogramme
hSherwertige
und Protokollen
denen Benutzer ausgegeben werden° Weiterhin zugeschnittene
interessieren-
in das System aufzunehmen (Bild 2)° Durch Verkn~pfung
jedoch
wie bereits
Aufgaben yon zwei voneinander
ein-
getrennten
ausgefShrto
Ein weiterer Vorteil dieser Rechnerhierarchie
ist in der hSheren Flexi-
bilit~t zu sehen, die dutch die dezentralisierte
Datenverarbeitung
und
eine autarke Erfassungszentrale
erreicht werden kann. Zudem wird die
Programmerstellung
da die Aufgaben auf mehrere Einheiten
vereinfacht,
verteilt und unabh~ngig ausgetestet werden kSnnen. die NotbetriebsmSglichkeiten Um die f~r eine einfache die verschiedenen zu erreichen, organisation
durch das autonome
Systemeinf[ihrung,
Benutzerwunsche
ist es unerl~Slich, diesen Forderungen
Betriebsdatenerfassung
SchlieSlieh werden
Subsystem verbessert.
Erweiterung
erforderliche
und Anpassung an
hohe ProgrammflexibilitHt
dab die Programmstruktur
entsprechend
gestaltet
und Datei-
sind.
im Zusammenhang mit der DNC-Technik:
Im fertigungstechnisch orientierten Produktionsproze~ ist die rechnerunterst~tzte Betriebsdatenerfassung numerischen
Steuerung
mit der DNC-Teehnik,
yon WZM, verbunden.
erster Linie historisch
bedingt,
der einze!nen Produktionsbereiehe
Dieser Zusammenhang
eine informationschldssige
Konstruktion,
direkten zmmerischen
Arbeitsvorbereitung
Steuerung yon Werkzeugmasehinen
und
zur
va/rde diese Ent-
dab nunmehr auch eine On-line-Ver-
bindung zwisdlen ProzeS und Rechner zur Verfugung Voraussetzung
NC-
Kopplung
realisiert wurde. Mit der Einf~hrung von Proze~rechnern
wicklung welter dadurch abgerundet,
steht, die als ideale
fur eine Integration yon Betriebsdatenerfassungssystemen
in DNC-Systeme Innerhalb
ist in
da bereits in der konventionellen
Technik fdr ausgew~hlte Teilaspekte Fertigung
d.h. der direkten
eines
anzusehen ist. DNC-Systems k a n n a u f g r u n d
der unterschiedlichen
Steuerungs-
286 ausf~hrungen erfassung
zwischen drei
unterschieden
Erfassungsstrategien
f~r die Betriebsdaten-
werden:
Datenerfassung bei NC-Maschinen im BTR-Betrieb (Behind Tape Reader) 2.
Datenerfassung
an und dutch Rumpfsteuerungen
3o
Datenerfassung
mit Hilfe
AnknGpfend an die arbeitung
soll
yon Kleinrechnern
erw~hnten Vorteile
im f o l g e n d e n
einer
auf die dritte
nehmend a n B e d e u t u n g g e w i n n t ,
und intelligente
eingesetzt
dezentralisierten Erfassungsstrategie,
wird,
der primer
fGr ProzeS-
wird zus~tzlich
Erfassungszentrale
als
Datengewinnung direkt
in eine, bracht
fur
werden kontrolliert die weitere
und b i s
zu i h r e r
ganisationsprogramm rechner
a u s dem F e r t i g u n g s p r o z e S
Verarbeitung
oder einer
zur Steuerung
verwendet.
Bei manueller Die erfaSten
in Gruppen sortiert
und Auswertung g~nstige hinterlegt.
des Dateaverkehrs
Form g e -
Uber e i n O r -
z w i s c h e n dem K l e i n -
werden nach Beendigung eines
Geschehens
Uberwachungsperiode die zur Dokumentation bestimmten Daten-
blScke einem Koordinierungsprogramm gestellt.
d.h°
Auswertung in Dateien
u n d dem F e r t i g u n g s r e c h n e r
bzw° NC-
eine automatische
ermSglicht.
aufbereitet,
Der
Datenkonzentrator
~bernimmt der Reehner die Eingabesteuerung.
Betriebsdaten
die zu-
f~r mehrere Arbeitspl~tze
Durch Abfrage yon Gebern, Kontakten und Z~hlern ist Dateneingabe
Datenver-
n~her eingegangen werden (Bild 3).
im S u b s y s t e m v o r h a n d e n e K l e i n r e c h n e r , Steuerungsaufgaben
oder CNC-Steuerungen.
Dieses
orientierten
Programm h a t
Auswerteroutinen
Massenspeicher
zu s t a r t e n
und Protokolle
und d i e E r g e b n i s s e
Dialoginstrument
oder personenbezogene
Displayger~t
zur Verf~gung benutzerauf einem
abzulegen.
Als bequemes und schnelles transport-
im F e r t i g u n g s r e c h n e r
die Aufgabe, die entsprechenden
eingesetzt.
f~r auftrags-,
Fertigungsdaten
ist
F~r zu d o k u m e n t i e r e n d e
anderem ein
Ausk~nfte,
Mitteilungen
werden zweckm~Sigerweise ein Drucker,
oder eine Hardeopyeinrichtung
maschinen-,
unter
Z.Bo e i n T e l e t y p
verwendet.
Auftragsverteilung Der i n d e r T e r m i n p l a n u n g e r s t e l l t e gibt
die
t~glichen
Plan werden die Auftr~ge
Auftrages
wieder.
f~r wenigstens
g r a m m s y s t e m im F e r t i g u n g s r e c h n e r Rechner f~hrt
Maschinenbelegungsplan
Belastungssollwerte
zwei Planungsperioden
zur Auftragszuordnung
die Auftragsverwaltung
zu den j e w e i l i g e n
( o b e n i n B i l d 4)
Aus d i e s e m v o r g e g e b e n e n
sowie die zeitliche
Maschinen selbst~ndig
einem Pro-
~bergeben.
dureh.
Der
Zuordnung des Eine mittels
287 des Datenerfassungssystems erkannte Auftragsende-Meldung bewirkt eine Dokumentation des Ist-Zustandes und im Auftragszuordnungsprogramm eine Auswahl und Ausgabe eines neuen Auftrages. Dabei wird einem Arbeitsplatz nach Termin- und Priorit~tskriterien ein neuer Auftrag zugeordnet, r~chdem die Freigabevoraussetzungen, wie z.B. Material, Programmvorhanden, vorher geprGft wurden. Zur Ausgabe yon Auftragsdaten, Arbeitspapieren, Anweisungen sowie Transportauftr~gen werden dezentral oder zentral im Fertigungsbereich Fernschrelber eingesetzt. Dutch die Ubernahme yon Stammdaten besteht welter die MSglichkeit, den Erfassungsaufwand im Betrieb zu verringern und durch gezielte Dateneingabe Funktionen zur Plausibilit~tsprfifung im System aufzunehmen. Nach Ablauf der Planungsperiode wird der Restbestand an Auftr~gen zwecks Angleiches an den IstZustand der hSheren Planungsstufe zur VerfGgung gestellt. Der neu berechnete Masehinenbelegungsplan wird danach vom Fertigungsrechner fibernommen. Voraussetzung f~r ein System zur Auftragszuordnung ist die Aufnahme y o n R o u t i n e n ist
zur Materialflu~fiberwachung
es erforderlich,
und n a c h M a s c h i n e n wird.
Auf d i e s e
fassendes damit
st~ndige
eine
sondern
fiber alle
MaterialbewegungenBuch das dureh
die
Grundlage
gefGhrt
den Gesamtbetrieb
die
Integration
ablaufsbedingter
Schwachstellenanalyse
Hierzu
prozeGbegleitend
ein umfangreiches,
nur die Ermittlung gleichzeitig
und -steuerung.
MaterialfluGdatei
Fertigungslenkungssystem, nicht
licht,
geordnet
Weise entsteht
portwesens
planung
dab in einer
des Trans-
Wartezeiten
und
des Transportvorganges ffir eine
optimale
um-
ermSg-
Termin-
darstellt.
Die eng mit der Terminplanung rung wird aus zyklisch Der Fertigungsrechner Soll-Termindaten
zusammenh~ngende Auftragspriorit~tensteue-
gestarteten ffihrt
ffir jeden
Terminfiberwachungsroutinen
d a z u im V e r g l e i c h Auftrag
zun~chst
abgeleitet.
mit den vorgegebenen eine
Abfrage
bezfiglich
Terminunter- bzw. -fiberschreitung durch. Ubersteigt der ermittelte Terminverzug einen lest vorgegebenen Toleranzwert, so wird dem entsprechenden Auftrag automatisch eine hShere Priorit~t zugeordnet. Durch diese MaSnahme kann ein aufgetretener Terminverzug innerhalb der Planungsperiode wieder aufgefangen werden, wobei die Auftragspriorit~t zurfickgesetzt wird. Software-Ubersicht Wie bereits erw~hnt, besteht im fertigungstechnischen Bereich eine enge gewachsene Kopplung zwischen der Betriebsdatenerfassung einerseits und dem ProzeSsteuerungssystem, auch DNC-{ystem genannt, andererseits. Die folgenden Ausf~hrungen uber ein On-line-Auftragsdispositionssystem sind
288
daher
ebenfalls
schwerpunktm~Gig auf
die DNC-Technik abgestimmt.
in einem DNC-System der Fertigungsreehner technologischen
ProzeGablauf
verzSgerungsfrei
Programme zur Fertigungslenkung Programmpriorit~t zu durchaus
ablaufen.
in der Lage,
kernspeicherresidenten lieh
auszuffihren.
diesen In Bild
5 ist
Zu e r k e n n e n
eine sind
zu f i b e r w a c h e n d e r
stungsf~higes
eine
e i n MaG ein
lei-
Die Anwenderpro-
Laufbereichausnutzung mu~ d i e
Vielzahl
werden in einem Laufbereich vom KOOR b e r e i t -
Wartesehlange
priorit~tsgem~G
der yon den Programmen ben~tigten
werden. fiber die
benStigten
sowie Platzbedarf,
Kernspeicher
und Externspeicher,
wiedergegeben.
sowie eines
modulartigen
d e n y o n dem K o o r d i n i e r u n g s p r o g r a m m Der gesamte
wachung und Systemkommunikation
Programmoduln,
die
gegliedert
nach
Dank e i n e r
Systemaufbaus
verwalteten
Auftragsdisposition, betr~gt
er-
geeigneten ist
es gelun-
Laufbereich
Kernspeicherplatzbedarf
gramme z u r B e t r i e b s d a t e n e r f a s s u n g , Programmbibliothek
kommt
D i e U b e r w a e h u n g und
(KOOR) e r f o l g e n .
BerGcksichtigung
Ubersicht
K Wort zu begrenzeno
den
dargestellt.
mug d e s w e g e n d u r c h
Uberwaehungsdateien
gen,
hier-
w i e mSg-
Bei einer
forder!ichen
Dateiorganisation
zu sehen,
so klein
Programmstruktur
Anlage.
sind,
Hierbei
abgearbeitet
6 ist
darin
Programmorganisation
im R e c h n e r
optimaler
und g e s t a r t e t .
Einrichtungen In Bild
die
Koordinierungsprogramm
unter
der Reehner
(ALMI) und R e c h n e r k o p p l u n g s -
der gesamten
externspeicherresident
und f o l g e r i c h t i g
ist
Systemorganisation
Programmsysteme ist
Berfcksichtigung
gestellt
m~ssen die
mit niedriger
Software
Programmwarteschlange.
der Programmabl~ufe
gramme, die unter
gestaltete
AlarmauflSsungs-
Leistungsf~higkeit
Steuerung
aufgebaute
den
entgegen.
derartig
ein
vielmehr
fGr die
Da
Aufgabe hat,
zu f G h r e n , Grfnden
das Problem ist
programm (MISI) sowie eine ffir die
Aus z e i t l i c h e n
Eine modulartig sehr
die
im R e c h n e r h i n t e r g r u n d
Platzbedarf
Bedingungen
primer
ffr
auf
die
2
Pro-
Transportfber-
nur 3 K Worte, obwohl die
gesamte
f i b e r 20 K W o r ~ g r o g i s t .
Erw~hhnt s e i n o c h , d a 8 e i n e S y s t e m e r w e i t e r u n g lediglich e i n e Zunahme der Fertigungsdatenbank i n A b h ~ n g i g k e i t d e r zu f b e r w a c h e n d e n M a s c h i n e n zur Folge
hat.
erweiterung autarkes
ist
Sie betr~gt nicht
bei
Betriebsdatenerfassungs-
Kleinrechnern
64 M a s e h i n e n
erforderlieh.
aufzubauen.
Es i s t
54 K W o r ~ somit
Eine Kernspeicher-
auch m~glich,
und F e r t i g u n g s l e n k u n g s s y s t e m
ein mit
289
Kommunikatignsbeispie!e In Abhfingigkeit vom Informationsbedarf tigungsprozeS, aufzuteilen, -
-
die yon folgenden
Stellen angesprochen werden:
Meister Terminplanung,
(Fertigungs]eiter)
Kostenrechnung
Anhand einiger Kommunikationsbeispiele
usw. soll der DatenfluS zwischen den
einzelnen Ebenen und dem Fertigungsrechner
verdeutlicht werden.
schr~nkt sich die Eingabe des Bedienungsmannes Angaben ~ber Material, Systemausgabe
erh~It
An- und Abgang sowie StSrungsmeldungen. er Auftrags- und Transportanweisungen, Auftrag zuzuordnen
fber Maschinenbelegung
sowie den Auftragsstatus
weiterhin die MSglichkeit, zahl zu korrigieren~
fber den Schaden zu informieren
Der Fertigungszentrale
stehen
alle
Hier kann bei Maschinenausfall
gungsablauf
anfordern.
einzugreifen
eine Umdisposition scheidungshilfe
direkt
oder Ent-
Angaben fiber Aus-
und die an den verschiedenen
Maschinen
herangezogen werden. die hSchste Kommunikations-
ebene, die Kommunikation
zwischen dem Fertigungsreehner
ordneten Betriebsrechner
zu erkennen.
einen optimalen Maschinenbelegungsplan
und dem fberge-
Der Fertigungsrechner
ffr eine erneute Terminplanung
stellt die
zur Verffgung und erh~It
ffr die n~chste Planungsperiode
zurfck.
Anhand einiger Beispiele tionsergebnisse
ge-
in den Ferti-
eine Priorit~ten~nderung
Im unteren Tell yon Bild 7 ist schlieSlich
als neue Soll-Vorgabe
zur Verf~gung.
fiber d i e momentane F e r -
vom R e e h n e r z u r V e r f f i g u n g g e s t e l l t e
Maschinenkapazit~t
Ist-Situation
StSrungsdauer
Auftr~ge vornehmen. Dabei k~nnen als
weichmaschinen sowie die ben~tigte eingeplante
sich
(der automatiseh
die M6glichkeit,
und kann z.B.
einzelner
wie z.B. Maschinen-
Systeminformationen Informationen
Er h a t
oder Stuck-
ist es dessen Aufgabe,
oder Terminverzug
der Fertigungsleiter
tigungssituation
informieren und hat
und die voraussiehtliche
mitzuteilen.
meldet wird)
sind. Der Meister kann slch
Beim Auftreten yon StSrungen,
dem Dispositionssystem
Als die dem
Vorgabedaten wie z.B. Vorgabezeit
die dem Meister gemeldet werden,
So be-
auf Auftragsanforderung,
gerade abgesehlossenen
ausfall,
ist der Fer-
in vier Kommunikationsebenen
Bedienungsmann
- Fertigungszentrale -
und den Befugnissen
wie in Bild 7 dargestellt,
sollen abschlieSend
gezeigt werden.
representative
Kommunika-
In Bild 8 ist eine am Arbeitsplatz
fber
290 Teletype
vom D i s p o s i t i o n s s y s t e m
yon Vorgabezeiten, zeitig
ausgegebene Auftragsanweisung
m i t Angabe
Programmnummern und R ~ s t a n w e i s u n g e n zu s e h e n .
mit dieser
Ausgabe wird auch eine Transportanweisung
gerade abgeschlossenen
Auftrag
ausgegeben,
sie
ist
fur
Gleichden
o b e n im B i l d z u e r -
kennen° Auf d e r z w e i t e n gestellt
der Meisterebene,
kann jederzeit
w e r d e n , wo im S y s t e m u n d i n w e l c h e m S t a t u s
befindet.
Oben im B i l d i s t
Im u n t e r e n
Bildteil
Anhand d i e s e r -
Ebene (Bild 9),
ist
ein derartiges
sich
k6nnen folgende
Welehe A u f t r ~ g e m~ssen h e u t e
ein Auftrag
Kommunikationsbeispiel
eine Maschinenbelegungs~bersicht
Ubersicht
festgezeigt.
dargestellt°
Fragen beantwortet
werden:
noch auf der Maschine X bearbeitet
werden? - Welche d i e s e r
Auftr~ge
werden heute -
liegen
In welcher Reihenfolge
- Wie h o c h i s t ~erstunden
die
gegenw~rtige
komplette
schritt
s~mtlicher
die Auftr~ge bearbeitet Auslastung
im S y s t e m a u f g e n o m m e n e r A u f t r ~ g e w i e d e r g e b e n ,
Unter Status,
Auftrag
rechts
im B i l d ,
ist
in Arbeit,
Material
wartet
Betrieb,
z.B.
schinenbelegungs~bersicht
Bild
ausgegeben werden (Bild 11)° so kann der Auftrag
das Ergebnis
Ist
1344 d e r a l s
nach ausgef[hhrter
und Material
angegeben.
kann eine aktuelle
i n F r a g e kommenden M a s c h i n e 5 k u r z f r i s t i g
12 z e i g t
an der Maschine
auf Transport
Maschinenausfall,
z.B.
auf diese
Art kompensiert
Madie
Ausweichsma-
zugeordnet
Umdisposition.
ordnung yon Uberstunden an Maschine 5 kann der aufgetretene ausfall
ausge-
der augenblickliche
Hier werden Meldungen vie Material
Maschine 8 ausgefallen, schine
i n B i l d 10 d a r g e -
die den momentanen Fertigungsfort-
wird yon Maschine X bis Maschine Y transportiert, Bei g e s t S r t e m
werden?
d e r M a s c h i n e ? M~ssen
kSnnen, wie beispielhaft
Auftragsberichte,
Zustand aufgef~hrt. vorhanden,
vor der Maschine und welche
werden?
In der Fertigungszentrale
geben werden.
sollen
aD~esetzt
stellt,
bereits
noch eintreffen?
werden. Dutch AnMaschinen-
werden°
Systemsimulatio n Zur Durchf~hrung eines Unterst~tzung
Systemtestes
m o d e l l d e s zu s t e u e r n d e n setzt.
in der Entwicklungsphase
w~hrend der Systemeinf~hrung
Auf e i n e r
Plantafel
ist
und zur
ein Hardwaresimulations-
und ~berwachenden Fertigungsprozesses ist
die Fertigungsanlage,
bestehend
eingeaus
291 Eingangslager, lager
Transporteinrichtungen,
nachgebildet.
StSrungen
simuliert
Werkzeugmaschinen
Der Proze~ablauf
kann zeitlich
und Auswirkungen
yon eingeleiteten
studiert
werden kSnnen.
terminal
zugeordnet.
Jedem Arbeitsplatz
Eingegeben
ist
und Fertigteil-
gerafft
ein
werden,
wobei
Gegenma~nahmen
einfaches
Eingabe-
werden kSnnen die Funktionen:
Materialankun~t Materialabgang Auftragsanforderung
oder Auftragsende
Maschine ausgefallen Masehine wieder D i e dem A u f t r a g ter
zugeordnete
eingestellt.
rungslampe
Der Belegungszeit Programm zur um d a d u r c h Operateur bildet.
Simulation dieser
Zeit
Simulation
Quittierungslampe
sind
Felder,
und Transportanweisungen
weise
die
des Prozesses
das Ziel
einer
integrierten
simuliert. erreicht
und der
wird
nachge-
~hnlich
Hierdurch
werden.
wie
kann der
Die Ausgabe yon angekom-
Fernschreibero den Rechner
Proze~ablaufes
zu n u t z e n
Fertigungssteuerung
Der Mensch wird yon der Aufgabe der Arbeitsverteilung wachung entlastet
zurGck-
d e n m o m e n t a n e n Modus d e s
die MSglichkeit,
des organisatorischen
Paletten
sowie die Meldur~ "Transport
zentralen
System zeigt
kleiner
gesetzt,
B e i d e r vom
Lampe vom R e c h n e r
Der Transportablauf
der Maschinenbelegungszeit
Gber einen
zu markieren.
wird die
werden mittels
angebraeht. Ablauf
die
des Auftrages
Fertigmeldung
Arbeits-
nalisierung
wird ein
zur VerfGgung gestellt.
zeitliche
Das vorgestellte
genommenen A u f t r a g e s
vom R e c h n e r
richtige
men" g e s c h i e h t
wie Blockie-
der Bearbeitungszeit
Maschine
darstellen,
Kontrollampen
wird
Die Materialbewegungen An j e d e r
sind
vorgesehen.
in Angriff
die Fertigstellung
Auftrages die
des gerade
ausgefGhrten
gesetzto
Au~tragsnummer wird auf einem Dekadenschal-
Zwecks Eingabekontrolle
und Quittierungssignal
Nach Ablauf
einsatzbereit
dazugehSrige
umfangreiche
fur
die Ratio-
und schritt-
zu realisieren. und TerminGberInform~tionsfluS
weitgehend automatisiert. Durch die
direkte
gleichm~ige und e i n e werden.
Arbeitszuteilung
Maschinenauslastung,
davon abh~ngige
kann eine eine
Reduzierung
Vermeidung yon Verzug,
Verk~rzung
der Durchlaufzeiten
der Werkstattbest~nde
erreicht
eine
292
r~n
B i l d I:
F - ~±~° - ~
-
on-ll~-Au~r~dts~osl~lo~
I
I w : : z IL T.H.AACHEN
Lebtzuhl M,Wlck
U. 8 k k
T.PfeJ[er I
Bild 2 :
~
Grun ~q~en
I
slufen der 8~rte~enerfl~ss~g
ng
W Z L
T,H.AACHEN
t,h,=,hl M,W"~
Bild 3:
293
U. B~ct(
L lll~irer 04~-~8-~5.059
Bild
Ab~uf~Au~r~s = diSpOSflionu.~-Vertdlungim rech~erun~r~Otde~ Fertigungslenkungssy~tem
4:
w~
L
I~H.AACHEN Lehrstuhl MWIck
Bild 5 :
~.~
Organlll~ ~ Rech~hkde~r ur~d~v]J~t~
J
pl/z
/
1" W:~ 1. ~H, A A C H E N
ElngaberoutlnmiSoil) Mat.-flulZObe,r~hur~9 (Ankun~,A~ang) ~u~rzsz~ungspr~.
I
S~r~u~s~rogr~m~ to -.
--
/
o 10 20 ~ 40 50 60 ?O ~sch.
{N~asch.,Auffr.,13~er) uindispositionspro9ra• m An(~erung~ienst Termine Vor~,e*erte Arbeits~nge " 2.* Ookummtatlon,Aus~lbe BOEJJoku~tatlon Auswede-Aur,~abe~pr~. Ze~n~e~hun~
/ / /
/
Bild
6:
~Z0 K,v
Maschln~bel~un9 13 ~ : r i l~nr,pei¢h~b~darf
~. "~
Transp~tDberw~hun9 li~ezeilol~r ~qchunu Lafleroberv~hun~
~ 6 J~Wfor ]D MmSch.
Exl~nsDelcher
Pr~r*mmunc~DatmorgmdSal[mlIm F*dtg~*r~h~r
I W ~ I ! T~H,AACHEN Le~tr~i M+Wick
294
Bild 7:
Fm%u~sttucru~
I
b:e~e:l:;
~
t
Term{. . . . . .
Wetiztu~w Miter ~llbertit~l, . . . .flu.ng,I
L
J 0 0
TRANSPORTA~YgEISUNG:
0
M A T E R I A L V0N A U F T R A G
O
AUFTRA3SANVEISUNG:
0
AUFT.N~ ARBG.NR ~UESTZT
0
134~ 1 10
134l
TEIL~N~ GP.ANFT
VORG.ZT 394387
V0N HAl0 ZU HAl5 T P A N 5 P O R T I E R E N
1 2 4 5 8 ZEICHNR 1~! ~SH.NR
25
BELEGZT
9~3121 10 510
STUEOKZ 2~ PRIORIT 3 STATUS: IARB
SPANNVORRICBTUNG693
PRO3,N~, ~ERKZEUG~R,
6943
POSITION
~ERKZEUGNRo
5341
~ERKZEUGNRo
7415
POSITION 2 POSITION 3
1
0
Bild
8:
0
D a t e n a u s g a b e am A r b e i t s p l a t z (Ausgabebeispiel)
0
295
{COD~40RTISAUF)~S~UF;;1341;
Bild
9 :
•
•
0
~SCHI.E..RI
•
k"FT.WR I~
~
0
k~G*~R
GP*A~T le3
RELEGZT
pRIC~IT
ST*TUS 0
5~5
EINGEPLkNTEH~SCHIMENKAP&ZlTXET l+~ff~IM.
U,BaCk
Bild
Kommunli~t|~sbe}splele
|
L
10:
(Prototol busschnltt) ~-~7N5.~
.~SC..NR:
Bild
~ ' : ~
,,,,,,,,,,,,
,,,,,,,, ,
,,,
T+H,AACHEN t ~ | s t ~ t M.WKk
5
Ii :
°"i
(Pr otol(oliausschrlltt)
,r.L
I:H.AACHEN
296
'.A.SC~N~.~eL~GU.GSUEeE~S~C,,L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .SvsTE~ . . . . . . .~. . . . . . . . . . . . . . . ST,HD~ . . . . . . ,.e~.7~ ,Z.~S~,n ~*SCS*Ne:
Bild 12 :
u~B~ i
0~67-379T5, 068
o
u~,spo~r,,,~ , ~ - ~
ufsimuLation
B i l d 13 : ~_r2222~~ -Abgang~
Har~re~II
~s org~n~l~che~ Prc~e~ab~aufes
zur Stmu~t~
iLehlst W ~uhlLM,Weck T.H.A--
ORGANISATION UND FUNKTION EINES SYSTEMS ZUR GRAFISCHEN PROZESS-
~fERFOLGUNG Alfred SchGring
I.
Einf£ihrung
Zur Ubel~achung diskontinuierlicher ner gef[~rt hen an,
werden,
bietet
sich
Prozesse,
der Einsatz
auf denen die Bewegungen der Objekte
stands~nderungen
grafisch
Die Datensichtstation indirekt
~ber diesen
formationen
ist
wiedergegeben
die
grafischer
Datensichtstatio-
im P r o z e S u n d a n d e r e
Zu-
werden kSnnen.
m i t dem P r o z e 2 r e c h n e r
Anschlu2 Informationen
dienen zur Darstellung
yon einem ProzeBrech-
zu k o p p e l n und e r h ~ l t
a u s dem P r o z e ~ .
des Proze2geschehens
Diese
In-
f~r Uberwachung
und Bedienung. Zun~chst wird festzuhalten zu welchem Z e i t p u n k t wie diese der
sein,
dargestellt
welche Informationen werden sollen.
in welcher
Danach ist
Art und
zu p r ~ f e n ,
Anforderungen mit der gegebenen Hardware und den M~glichkeiten
Software verwirklicht
Aufgabe~ das grafische
werden k~nnen. Schlie21ich
besteht
noch die
U b e r w a c h u n g s s y s t e m i n d e n Rahmen d e s S t e u e r u n g s -
systems zu integrieren. Der i n d i e s e m B e i trag
behandelte
Proze2 besteht
aus
einem automatisierten Fertigungssystem, d a s im B i l d a l s dellzeichnung dargestellt
Mo( B i l d 1)
ist:
Die
Fertigungseinrichtungen
-
numerisch ge-
steuerte maschinen
Werkzeug(NC) - s i n d
~ber Transporteinrichtungen
miteinander
verkettet.
Im S y s t e m
findet ein automatischer Werkstuektrans-
Bild I: Numerisch gesteuertes Fertigungssystem f~r ~ichtrotationsteile (Firma: Burkhardt & Weber)
298 port
statt,
der
der
yon e i n e m F e r t i g u n g s r e c h n e r
schon erw~hnten Datensichtstation
st~cke
in den Transportstrecken,
den Puffern
sowie andere
hinaus
die
einer
soll
aktuellen
oder
im D i a l o g
ProzeSsituation
Uberwachungssystems
werden.
Dar~ber
zur Erl~uterung ~ersichten
und e i n e r
Hardware-Konfiguration
sowie Organisation
und F u n k t i o n
behandelto
A u f g a b e n und O r g a n i s a t i o n
schritthaltend
m i t dem P r o z e 8
mSglichst
kontinuierlich
nach der
Dar~ber
wird
zu b e s t i m m t e n
- Einheit Zeiten
sein,
taillierte
Informationen
tionseinheiten
der
es sinnvoll
im P r o z e S
arbeitet,
zu h a b e n .
Objekte
wartet,
mit Tabellen,
sie
sind
ist
werden,
dab sich
und p e r
haben gew3hnlich
speichern
zu k 6 n n e n .
weniger
geeignet,
dauernd
wird
zu v e r l a s s e n gar
ist
es erund d e -
von einzelnen
Funk-
auch noch an den
statistischen
Ubersichten,
Sonderfunktionen
wie Farb-
dienen
F~llen
sogar
nicht als
werden,
eingebracht
Bildinformationen
k6nnen:
konstant,
die
Ger~te
Statische
dynamische
Eigenschaft,
nur
uner-
in Informationen
dagegen werden
aufzunehmen,
erforderlich zyklisch
Bildinhalte
mit Speicherbildr3hren
~nderungen
mit eigenem Bildwiederholspeicher versorgt
Funktions- dauernd
Programm ver~ndert.
st~ndig
Aufbau des gesamten Bildes
die
lassen
w~hrend des ProzeSablaufes
Datensichtger~te
F~llen
ist
dem B i l d s c h i r m .
gestSrt
des Bildes
in einigen
auf
Bewegungen
Forderung
anzusehen.
und d y n a m i s c h e a u f t e i l e n
v o n ibm b e e i n f l u S t
oder
SchlieBlich
die
einzelner
In besonderen
y o n S y m b o l e n und S c h i e b e n
Hilfsmittel
sollen
Eine weitere
Zust~nde
und a n d e r e m zu d e n k e n .
kann schon erkannt
Speicher
die
von Untersystemen
verf~gbar
Blinken
~nderungen
einzelnen
auszugeben.
zur ErhShung des Komforts,
bleiben
dabei
d e n Rahmen d e r G e s a m t d a r s t e l l u n g
Kommunikationsfeldern
statische
Bewegungen der Objekte
werden.
sein,
Wechsel des Uberwachungsbildes
l~81iche
die
nachzuzeichnen;
wiedergegeben
forderlich
gebung,
sind
Identifizierbarkeit
hinaus
einheiten
Hier
Informationen
Forderungen
Softwarestruktur
des ProzeSablaufes
oder
d e n M a s c h i n e n und i n
i n Form von s t a t i s t i s c h e n
Zur Verfolgung
die
Mit Hilfe
Bewegungen der Werkauf
im P r o z e ~ w i e d e r g e g e b e n
zus~tzlicher
Ausgehend yon den g e s t e l l t e n
2.
die
wird.
mSglich sein.
w e r d e n im f o l g e n d e n dieses
sollen
der Aufenthalt
Zust~nde
Anforderung
gesteuert
oder
einen
selbaber neuen
machen. Dagegen werden Ger~te solche,
die
neu g e s c h r i e b e n ,
werden k3nnen.
da s i e
sind
Unterschiede
yon einem externen so dab jederzeit gibt
es aber
noch
299 hinsichtlich
der speicherinternen
wird die von den ZeichenInformation Nutzdaten.
gespeichert, Bei bin~rer
und Vektorgeneratoren im a n d e r e n F a l l Proze~rechner
mationsmenge der Bildpunkte des Proze~rechners
ist
zu f d h r e n .
beschr~nken
Die elementaren sich
des Cursor's.
Darauf aufbauend sind
die konzentrierte
erstellung
da d i e
Infor-
Infor-
belegen
e i n A b b i l d im Z e n t r a l s p e i c h e r Ausgabe-Funktionen
nun die erweiterten werden,
der
I J~]n
I
Funktionen,
software~Sig
ProzeB-L~-outLI [
Dazu s o l l z u n ~ c h s t d e r Vorgang der Programm-
und
und Z e i c h e n und das P o s i t i o n i e r e n
gefordert
lichen.
Leit-
gewShnlich auf das Zeichnen yon Vektoren
das LSschen yon Bildern
yon der Problemstellung
ist
zu s p e i c h e r n ,
dann also
und Zeichen, sie
binRre Bildpunkt-
e i n e n zu g r o ~ e n S p e i c h e r b e r e i c h
zum B i l d s c h i r m
Bildgeneratoren
erzeugte
Im e i n e n F a l l
die konzentrierten
Bildpunktspeicherung
m a t i o n vom a n g e s c h l o s s e n e n w~rde. Parallel
Informationsdarstellung:
wie
zu v e r w i r k -
Pr~rammierraster ~//
betrachtet
werden: Ausgehend yon d e r A n o r d n u n g im r e a l e n Proze~ wird ein trisches gelegt,
Lay-Out ~estdas f~r eine
zweidimensionale stellung
die
2) l i n k s
Struktur
£st. 0,..9
man oben
I v~ktO~ J ze~h~'~ J r~ J Pos~t~0n I
Program-
Bild
2: Programmierung des Proze~-Abb£1des
~bertragen
Statt jedes Bildelement
Symbole und Formelemente Die Aufteilung bereitung,
einzeln zu programmieren,
sowie d e r e n A d r e s s e
der Schirmebene
mentaren Informationen
und Farbe angegeben werden.
ist Aufgabe des Programmierers,
wie aus den Programmieranweisungen
zum Z e i c h n e n d e s g e s a m t e n B i l d e s
Der Vorgang der Softwareerstellung Stufe~ der Problemstufe~
sche Struktur portnetz
k~nnen Zeichen, die Auf-
Ablage und Ausgabe wird ihm jedoch vom System abgenommen.
Im folgenden wird gezeigt,
obersten
=
1' Symb00 1
die auf
ein kariertes mierraster
~" "
F0re0o0t0 11
des Trans-
portsystems,
wird.
Dar-
geeignet
Im B i l d e r k e n n t (Bild
PROGRAMM lJ Formel Symbol ee ~ ement Adressen
geome-
d e s zu e r s t e l l e n d e n
wird in Elemente,
l~uft
die ele-
gewonnen werden.
i n m e h r e r e n P h a s e n a b : Auf d e r
w i r d a u s g e h e n d vom P r o b l e m ,
die stati-
Bildes
Das T r a n s -
festgelegt
wie Transportstrecken,
(Bild 3).
Werkst~ckpuffer,
Bear-
3OO beitungseinheiten,
Lager,
Ein- und Auslaststellen
Elementen werden Daten zugeordnet, system und sp~tere die
Inkremente
Zeit
u n d Weg d i e A r t
Diesen
die f~r die Einordnung in das Gesamt-
Objektverfolgung
z.B.
aufgeteilt.
yon Bedeutung sind.
So b e s t i m m e n
ffir
d e r O b j e k t b e w e g u n g im betrachteten
Element.
Nachdem a l l e
im P r o z e S
wiederzugebenden mente derart sind,
Ele-
definiert
werden die Element-
daten auf Lochkarten kodiert
Listengenerator lesen.
I oAdresse,Position[ t ~ Zeitinkrement j
und y o n e i n e m einge-
Dieser
generator
1
Listen-
den Elementdaten
i
Bild 3: Aufbau statischer
baut
er eine Bildliste des Bildes
nStig
sind.
Form a l l e
Daten aufnimmt, die
Dar~ber hinaus
fung der Elementdaten aufgebaute
Bildliste
diesem Bereich
kann schlieSIich
sind alle
die
off-line
er einen Listenbereich werden.
im Z e n t r a t s p e i c h e r
erzeugten
gebraucht
f~r das Zeichnen
Bilder
abgelegt
an,
in
Nach P r ~ fertig
werden.
gespeichert,
In
die
werden.
der
abgelegten
Bilder
gezeichnet
werden~
vonder
legt
und a k t u a l i s i e r t
in einem Externspeicherbereich
w~hrend des ProzeSablaufes nun eines
Bitddaten
auf,
dem d i e d y n a m i s c h e n D a t e n g e s p e i c h e r t
Problem-
Software-Stufe hend bis
L'"°'
Aus
welche in konzentrierter
sind
i'~ --statisci~-~=======I 8itr~,
erf511t
mehrere Funktionen:
Soil
I * Eiementdaten I I prOf.... d I I ~B:l~lis~:nnExtern.t ~
ausge-
zur Ausgabe
der Kodeinformationen noch weitere
Stufen
zu p a s s i e r e n
(Bild 4).
Auf d e r z w e i t e n warestufe
werden die
programmierten elemente, Rechtecke,
SoftForm-
wie G e r a d e n ,
Dreiecke
BZI~ 4:
Software-Stufen Datensichtger~ten
bei
rechnergekoppelten
301
und S y m b o l e a u s V e k t o r e n aufgelSst
und a n d i e
Prozeduren einzeln Stufe
dritte
durchlaufen,
der untersten
Stufe
an die III
in horizontale,
enth~lt
gesammelt,
vollzogen Paketes die
die
auf
und b l o c k w e i s e
Gbertragen
werden.
oder
Die
des Cursor's.
beiden
mittleren
die
Stufen
Ein weiterer fGr eine
lag
zun~chst
als
waren;
die
i n FORTRAN g e s e h r i e b e n Assemblersprache Schritt
einfache
konnte
war dann die
Systemprogrammbibliothek
Voraussetzung
erzeugen,
zur PrGfung,
der
werden.
H i e r w e r d e n nun
noch kodiert
weitere
Vektoren
Hilfsfunktionen
Programme in eine
in die
Gbergeben. und N u t z d a t e n
eventuell
hinaus
und d i a g o n a l e
M o d u s u m s c h a l t u n g und P o s i t i o n i e r u n g
yon U n t e r p r o g r a m m e n v o r , gung dieser
Leit-
des Datensichtger~tes
dar~ber
Bildinitialisierung, Das S o f t w a r e p a k e t
Software-Stufe
welche die
Steuerung
vertikale
relativ
eine
Ubertraleicht
Eingliederung
der ProzeSrechenanlage.
stufenweise
Erstellung
Menge
dieses Damit war
der
Bilddaten
geschaffen. (Bild 5 ) Mit
Hilfe
dieser
Pro-
grammoduln war eine weiterung lichen
Er-
s
der ursprGng-
0 F
Hardwarefunktio-
hen angedeutet,
I
denen
W
das Lesen von alphanumerischen
Zeichen
hinzuzufGgen
A
noch
w~re.
R
Das
E
Mischen des digitalen Bildpunktrasters analogen
VIDEO-Infor-
mationen
erweitert
Sichtger~ten, die MSglichkeit
mat-Grafik Zeichnen
nach Datensichtstation
Bei
keine
oder
verwirklicht Funktionen,
Bild 5 : Hardware- und Softwarefunktionen der
der Vektorgeneratoren mi t
bestimmten
werdeno Die dar~ber beschrieben. die
besitzen,
durch Verwendung spezieller
von Vektoren
wurde bereits
LOSCHEN II P°S1~'l lW~U'~l AUS
arbeiten,
Bilddarstellung. die
I SCHREIB~(FaF~D I f
bei
die
dem T V - P r i n z i p
Ger~ten,
T:';:"T'I'"~ "............. " 7 ............. ~........~....'. L i ~
mit
aus der
ze~zustands~nderungen dynamik zu linden.
zur
ist
Zeichen auch per
einer
For-
das Software
Gruppe von Softwarefunktionen
Block beinhaltet
Problemstellung
A u f b a u und d e r E r z e u g u n g d e s B i l d e s
grafischer
Einschr~nkungen
liegende
Der obere
kann mit Hilfe
herr[ihren: dort
quasi-kontinuierlichen
die
die
komplexen
N e b e n dem i n t e r n e n Interpolation
yon P r o -
Wiedergabe der Proze~-
302 Ist
der Ausgabebereich
Proze~abbild durch
vergrS~ern,
gef~hrt
l~t
lichkeiten
kSnnen auf
ein
betrRchtlich
diese
erweitert
Weise die
werden.
ProzeSrechensystems
beschrieben.
durch
Austausch
ze~ auftreten.
Software
Im f o l g e n d e n
Zusammenwirken ,tit
angepaSt
w i r d nun d i e anderen
und
Funktion
Teilen
des
Das i s t
zum B e i s p i e l auf
Transportstrecke kann aber
dem b i e r
behandelten
nommen w o r d e n ,
gemeldet
-
-
eine
ist
Transport
diese
feine
Elementes
Somit liegen
nach Art der
~ber eine
FSrderstrecke
aufgefa~t
werden. nicht
kontinuierlicher
Zustands~nderungen,
Transportelementes
"Fertigwerden
eines
Identifikation
die
In
vorgeTrans-
dem F e r t i -
Elementes"
an einer
interne Zustands~nderungen
Steuerdatenverteilung
beim Wechseln
vor bei
Wechsel eines
fische Uberwachungssystem
Werkst~ck von
Unterteilung ein
im P r o -
Je
Lesestelle.
Sp~ter wird noch gezeigt, vie im U b e ~ a c h u n g s s y s t e m deten weitere
gekennzeichnet.
z.B.
Verzweigungsweiche.
Zustands~nderung
dieses
werden,
wenn e i n
~berwechselt,
getaktete eine
Beispiel
da i n n e r h a l b
-
auf als
angenommen w u r d e .
gungsrechner
anderes
ist
wenn Z u s t a n d s ~ n d e r u n g e n
der Fall,
ein
auch der
zu T a k t j e w e i l s
und F e r t i g u n g s r e c h n e r
und S t e u e r d a t e n
immer d a n n s t a t t ,
von Takt
port
wird.
yon d e r H a r d w a r e g e g e b e n e n MSg-
geeignete
yon P r o z e ~ m e l d u n g e n
finder
einem Transportelement Steuerung
"im Dunkeln" ausgegeben
der Datensichtstation
den Austausch
yon e i n e r
um d a s g e s a m t e
softwarera~Big da-
Teilbereich
Das Z u s a m m e n w i r k e n z w i s c h e n T r a n s p o r t p r o z e ~ Dieser
grog genug, Bereich
im Z e n t r a l s p e i c h e r
dutch
und i b r
Funktion
dieser
bestimmter
der Datensichtger~te
der Datensichtstation
3.
nicht
sich
da~ das gesamte Bild
und a u f A u f f o r d e r u n g
Offensichtlich sogar
des Bildschirmes
wiederzugeben,
zwischen die gemel-
eingeschoben werden.
wurde an ein Programmsystem
Das gra-
zur zentralen
an die Maschinen und zur Steuerung des Transport-
systems angelagert (Bild 6). Im linken Tell des Bildes ist dessen Aufbau dargestellt. Die ProzeSalarme bewirken einerseits die Ubertragung yon NC-Steuerdaten andererseits
vom Externspelcher
~ber Wechselpuffer
an die Mascbinen,
die Ausgabe von Steuerdaten an die Verkettungseinrichtungen.
Die Transportsteuerung
~bertrRgt nun alle f~r die ProzeSverfolgung
tigen ZustandsRnderungen
an einen Umlaufspeicher,
zwischen beiden Systemen anzusehen seits wird zyklisch veranlaBt,
rich-
der als Nahtstelle
ist. Das Uberwachungssystem
seiner-
auf etwaige ~nderungen zu reagieren.
Es
3O3 aktualisiert als
die hier
Proze~ged~chtnis
bezeichneten
Bildlisten
und den Bildinhalt
auf
dem S c h i r m . Aus d i e s e m Proze~ged~chtnis jederzeit
kann
der aktuelle
Proze~zustand
gewonnen
u n d im 3 t S r u n g s f a l l
kon-
serviert werden. Der Ablauf des Transportgeschehens wird nur yon der Transportsteuerung beeinfluGt und vom Uberwachungssystem
Bild 6 : A u f b a u d e r P r o g r a m m s y s t e m e z u r
Gber-
S t e u e r u n g u n d U b e r w a c h u n g yon
nommen. Daher entf~llt
Fertigungssystemen
die Aufgabe der Verkn~plung der einzelnen
Transportelemente
schen Proze~abbildes.
Das L e s e n d e s U m l a u f s p e i c h e r s
gende ~nderung des Bildes Proze~ leicht
bei der Programmierung des stati-
verzSgert
wird gegenGber der echten
ablaufen,
beeintr~chtigt
und d i e d a r a u f f o l Zustands~nderung
aber
nicht
im
die ProzeG-
Gberwachung durch die Bedienungsmannschaft. Das n ~ c h s t e 7) g i b t
Bild
einen
(Bild
Uberblick
[xternsDeicher
Gber d i e F u n k t i o n e n Speichern,
Bereitstellen
u n d B e d i e n e n im U b e r wachungssystem.
" Beciienung ' ~ ' - ~
F~r ein
Beclienungsfu nktio~en
neues Bild werden zu•
n~chst
die
statischen
Bilddaten
vom E x t e r n -
speicher
in den Lauf-
bereich speichers
des Zentral-
• Detailauswahl • Blinken yon ~jek~en • I-lelUD u nt¢~I-T~stu ng
Gbertragen.
Nach A u f b e r e i t u n g konzentrierten gelangen
8ild '~n £x~emspeicher ]aden und l~schen
sie
£iber d i e
Bildgeneratoren
Bild
7: B e d i e n u n g u n d D a t e n f l u G i m grafischen
Uberwachungssystem
des
Datensichtger~tes der noch leere
dieser
Daten
in d e n bin~ren Bildwiederholspeicher.
Listenbereich
Gleichzeitig
£~r die Proze~dynamik Zentralspeicher-
wird
304 resident
angelegt.
Die eintreffenden
ProzeSalarme
gungen in diesem Bereich und die Ubertragung Soll
der aktuelle
ProzeSzustand
dynamischen Bilddaten speicher
gerettet
an die Datensichtstation.
werden,
in den entsprechenden
bewirken dann Eintrasind jedoch
Bildbereich
nur die
a u f dem E x t e r n -
zur~ckzuschreiben.
Diese Funktionen andererseits
kSnnen einerseits
ternspeicher. angefordert,
auch das L6schen yon Bildern
Werden y o n d e r B e d i e n u n g z w i s c h e n z e i t l i c h so k a n n d a s u r s p r G n g l i c h e
Anordnung ist
in einem Meister-Terminal Im f o l g e n d e n
sol1
Instrument
einzusetzen
nun auf die
notwendig ist.
flexible
Interpolation
kontinuierliche
quasi-kontinuierliche
yon ZustandsRnderungen
jedoch
recht
zu R a s t e r p u n k t
wird. viel
Punktraster
erreieht,
Rechenzeit
wenn d a s zu b e gel6scht
wird bei einer
beanspruchen.
des
werden. Eine
fortschreitend
Dieses Verfahren
Weg- bzw. Z e i t i n k r e m e n t
im
yon Bewegungsvorg~ngen
Bewegung d a r g e s t e l l t
Bewegung w i r d am b e s t e n
und wieder eingeschrieben
werden. das nicht
Entscheidungshilfe
Genau genommen k a n n a u f dem d i g i t a l e n keine
wegende Objekt yon Rasterpunkt
n~nftiges
geschaffen,
ist.
ProzeB eingegangen werden, die zur Darstellung Bildschirmes
a u f dem E x -
andere Bilder
im D u n k e l n w e i t e r g e f ~ h r t
ein flexibles
nur zur ProzeBGberwachung, sondern auch als
Objektzahl
im Programm a b l a u f e n ,
a b e r a u c h vom B e d i e n u n g s m a n n a n g e s t o G e n w e r d e n . Dazu g e h S r e n
a u g e r dem L a d e n u n d S p e i c h e r n
Mit dieser
automatisch
gr6Beren
D a h e r mu~ e i n v e r -
f~r den Bewegungsvorgang gewRhlt werden.
W o l l t e man a u f d i e s e n Effekt tion
der
ELEMENTK
Interpola-
yon Bewegungsvor-
g~ngen verzichten, w~rden die Objekte zwischen den Unstetigkeitsstellen ProzeS springen.
im Da-
d u r c h w~rde das B i l d sehr
~
-\Tk] Imll ~o~oo~ I ®1~t.
"prozeBinitiiert"
..... i/ "interpolierte IL> Zustands~nderung" [
unruhig werden
und die Betrachtung der Vorg~nge erschwert.
[,C,~;;~-;]1 L
t
I tJ
Bild 8: Organisation
I
I
t zur Abbildung der ProzeS-
dynamik in Zentralspeicher-Listen
305 Im d y n a m i s c h e n T e i l
der ProzeSverfolgung
Elementen durch einzelne aktuelle
Zellen
Belegungssituation
dem E l e m e n t im P r o z e ~ i s t Liste
sind
sind
repr~sentiert
des betreffenden eine
die Zwischenpl~tze
derartige
(Bild
8),
welche die
Elementes wiedergeben.
Liste
zugeordnet.
in der Elementliste
Programmhinterlegt.
Je-
Im Kopf d e r
n~here Angaben ~ber die Art der Behandlung dieses
dutch das verarbeitende
in den
Elementes
Das A u f r ~ c k e n d e r O b j e k t e
w i r d m i t d e n im Kopf e n t h a l t e n e n
Angaben interpoliert;
d e r W e c h s e l v o n e i n e m E l e m e n t I zum E l e m e n t K d a g e g e n w i r d y o n e i n e r Proze~meldung, die eine Die Anzahl der Pl~tze aufteilung
ab;
sie
echte
einer
Zustands~nderung
Elementliste
signalisiert,
angestoSen.
h~ngt yon der Feinheit
wird neben anderen Parametern
d e r Weg-
an den Listengenerator
~bergeben. Im f o l g e n d e n
Zustands~n~erungen im Pr0ze8
Bild
( B i l d 9) w i r d d e r Z u sammenhang z w i s c h e n eehten
\
und interpo-
lierten
;\
Zustands~nde-
rungen verdeutlicht. Die internen
eitinkremente[nes
]
~ ,nderungen 1 _.~/ l~nl..... Be~ung, ablaufes] \,, Immm m ......
\\
ZustandsVerfol~jImgsListen
~nderungen werden dutch die Echtzeituhr
U
s G A
des
Fertigungsrechners
be-
wirkt. Dem Zeitinkrement der betrachteten Bild
Bewegung entsprechend
9:
Interpolation
yon ProzeG-Zustands-
wird das Objekt in
~nderungen f~r die grafische
seinem Element sehritt-
verfolgang
weise vorger~ckt,
bis
e s d a s Ende e r r e i c h t blockiert die
ist.
internen
scheidet gibt
h a t o d e r d u r c h a n d e r e v o r ihm l i e g e n d e
Durch die
sich
n a c h und n a c h e i n t r e f f e n d e n
Bewegungsabl~ufe jeweils
die Feinheit
der nachgebildeten
des Taktes
Bewegungsabl~ufe.
zwangsl~ufig
ein stSrender
Station
noeh z w e i k o n k r e t e gegeben werden.
Beispiele
Ist
diese
Objekte
Proze~alarme
synchronisiert.
der Eehtzeituhr
Nach B e h a n d l u n g d e r o r g a n i s a t o r i s c h e n sollen
Prozeg-
Nicht
werden
zuletzt
ent-
~ber die Gleichm~igkeit Taktfrequenz
zu g r o ~ ,
er-
R h y t h m u s im B e w e g u n g s a b l a u f . und funktionellen f~r den Einsatz
Zusammenh~nge
einer
derartigen
306 4.
EinsatzmSglichkeiten
Zur Uberwachung der ~i~:{
Vorg~nge in einem flexiblen
rechnerge-
steuerten
Fertigungs-
system
~ ~
.....
~ D
r T -~
~
~'~:~
( B i l d 10) w u r d e
die bier
iiCf
beschriebene
Datensichtstation
mit
dem F e r t i g u n g s r e c h n e r gekoppelt
und e i n P r o -
~.;~
EINESFERTIGUNGSSYS TEMS" .....
grammsystem zur grafi-
KOMMUN IKATIONSFELD .....
i~:~~!:~~!~*!i~ i!~i.~!!: ~';i!'!J:.~:'~*~:~
~
schen Uberwachung an das zur ProzeSsteuerung angelagert.
Das B i l d
a u f dem S c h i r m g i b t eine
Bild
10: Uberwaehung eines
bestimmte Proze~-
situation
wieder.
Teile
sich
repr~sentiert
m e h r e r e W e r k s t d c k e im P r o z e S . und k S n n e n so l e i c h t
S und K werden gerade
Die Teile
sich
identifiziert
werden. Die
y o n d e n M a s c h i n e n MO1 u n d MO2 b e a r b e i t e t .
in der Waschstation,
Weiche gedreht.
U b e r d a s im B i l d
Ein weiterer
Rangieranlage
Im G e g e n s a t z zu dem v o r i g e n ist
sich
hinsichtlich
die
existiert
hier
identifizierbar
auf einem passiven
den. Darer ist
in den K~stchen stehenden
ein wesentlich
gr5Serer
Schirm,
Ausschnitt
dergabe der Erkennungsnummern verzichtet Wagen g e s u c h t w e r d e n ,
so w i r d s e i n e
das System aufgefordert, Identifizierung
eines
gearbeitet
"Identifizieren"
diesen
kleiner
Zahlen identifiziert
wer-
Ausschnitt
Allerdings
werden.
Soll
begrenzt.
Bildschirm,
Auf wird
mug a u f d i e W i e nun ein bestimmter
Erkennungsnummer eingetastet
Wagen d u r c h B l i n k e n
Wagens a u f dem B i l d s c h i r m
werden.
In der einzel-
einem aktiven
geboten.
m~ssen.
ein relativ
Dort kSnnen die
aber dann auch der darstellbare
dem im B i l d u n t e n d a r g e s t e l l t e n
eine wesentlich
sein
Bildschirm
d e r zu ~ b e r w a c h e n d e n A n l a g e w t e d e r g e g e b e n .
h e n Wagen ~ b e r d i e
werden.
der grafischen
b e i d e r Bahn ( B i l d 1 1 ) .
Beispiel
grS~ere Anzahl yon Objekten, oberen Blldh~lfte
V wird gerade auf einer
u n d dem S y s t e m d u r c h g e f ~ h r t
Anwendungsfall ergibt
Uberwachung einer
das Tell
Das T e i l
u n t e n zu s e h e n d e K o m m u n i k a t i o n s f e l d
kann ein Dialog zwischen Bediener
griffel
Sie sind durch
R u n d F w a r t e n v o r d e r M a s c h i n e MO1 a u f B e a r b e i t u n g .
B befindet
Tell
Datensichtstation
Um
1 5 . 4 7 Uhr b e f i n d e n Buchstaben
mit grafischer
Fertigungssystems
anzuzeigen.
und Zur
kann mit einem Licht-
Z u n ~ c h s t w i r d a u s dem F u n k t i o n e n - M e n u e d a s
ausgew~hlt und darauf
d e r zu i d e n t i f i z i e r e n d e
Wagen
3O7
G15 FIT3-IFO~I'TdFII II
954 11138 IfB9 I
I-o~-I~,~
G1.6 I o93 it o94 t It
Bteis 15 Weiche Gleis 16
Passiver Schirm
Bild
11: G r a f i s c b e
Uberwachung einer
Rangieranlage
ber~hrt.
b e i d e r Bahn
Auf einem Kommunikatlonsfeld
erscheint dann die Nummer des
Wagens. Diese Beispiele
zeigen
Datensichtstation.
Grafische
f~r
den Menschen leicht
f~r
diese
Ger~te,
Wiedergabe,
deutlich
die Vorteile
rechnergesteuerten
Zusammenh~nge u n d d e r e n D y n a m i k k S n n e n i n
erfa~barer
insbesondere
sind auch heute
einer
f~r
Form d a r g e s t e l l t solche
noch nicht
werden. Die Kosten
mit grafischer
zu u n t e r s c h ~ t z e n .
Datensichtstationen
wegen i h r e r , g e g e n ~ b e r k o n v e n t i o n e l l e n
zeigen
erweiterten
betr~chtlich
Flexibilit~t
bei verschiedenen
MSglichkeiten
und i h r e r
Aufgaben vorzuziehen.
und f a r b i g e r Dennoch sind Hardwareanbesonderen
MULTI-LEVEL DIALOG LANGUAGE BULTI-LEVEL OIALO6 SYSTEM MOOIFIZIERBARE SPRACHMITTEL FOR DEN DIALOG ZWISCHEN MENSCH UND
RECHNER-GESTEUERTEN ABL~UFEN I. Schnarre,
HamburR
I. Problem-Abgrenzung Unter "Oialogsprache ~ soil in den vorliegenden Spracbe zur Programmierung
Aus£Ohrungen
eine Kommando- oder Steuersprache verstanden warden, Control-Language
nicht eine
im Dialog, wie etwa BASIC oder APL, sondern ~Gnlich der Job-
in einem Stapelverarbeitungs-Bystem.
Eine solche Dialogsprache dient der Vermittlung menscblicher Eingri~fe in Vorg~nge,
die im Rechner oder durch den Rechner gesteuert warden.
In
der PDV handelt es sich hierbei gew~hnlich um Eingriffe in dle Steuerung eines industriellen
Prozesses,
z.B. eine Fertigungs- oder eine Re-
gallager-Bteuerung. Oialogsysteme Umgebungen
finder man im praktischen
Einsatz in den verschiedensten
hinsichtlich Betriebssystem und Hardware de r EDV-Anlagen
(einschlieBlicb der verwendeten ernden Prozesee andererseits. unterschiedlicben
Terminals)
einerseits und der zu steu-
Dig Vielfalt der Anwendungen mit ihren
Aktionen hat dazu ge{Ohrt,
stamen auch unterschiedlich Abl~ufe vorliegen, Funktionsprogrammes
zu behandeln,
n~mlich Ermittlung,
diese in den Oialogsy-
obgleich prinzipiell Aleiche
Versorgung und AnstoB eines
unter der Kontrolle des Dialogsystems au{grund von
Eingaben am Terminal. Recht unterschiedlich
sind auch die Anforderungen
Modalit~ten der Kommando-EingaBe
gen, h~ufig handelt es sich um EDV-Laien.
Kommando durcheus untarschiedliche
mandos
Dokumentations-
AbB. I zeigt, dab for dasselbe
der L~nge der Namen und dam Einga-
Texte sind aktiv einzugeben,
hen vom System abge{ragt werden]. Dialogsprache
Umfang,
die Obrigen kGn-
Die Anwendungs-Orientierung
drBckt sich darin ads, dab dig verwendeten
(CodewGrter]
zie-
Oars@ellungen denkbar sindj sie un-
terscheiden sich in den Oelimitern, (unterstrichene
ist sehr inhomo-
Die Benutzer-BedOrfnisse
fen haupts~chlich auf Komfort bei der Eingabe, Wart und Lesbarkeit des Eingabe-Textes;
bemodus
der Benutzer an die
-- der Benutzerkreis
und Spezifikationen
einer
Namen von Kom-
au{ die Terminologie der Anwen-
309
Abb.
1 Zwei
(wirkungsgleiche)
dung bezogen Kommandos,
sind.
Oarstellungen
Die aus derselben
n~mlich
"Kommandoname,
desselBen
ABbildung
Anwendungen -
jeweils
kaum in der Struktur abh~ngig
(gleiche
6aben die in A66. 2 gezeigte
messen
siert~
dessen
AnstoB
solcher
im Zeichenvorrat
Den BBnutzer
Leistung
ebenfalls
star-
EntscQlOsselungs-
Daten an einen Steuder An~endung
essoziierte
ange-
meistens
ist efn Funktionsmodul
und Ablauf dieser Funktionsmoduln Der AnschluB
relativ
sind programmtechnisch
Oedem Kommando
Ablau# die mit dam Kommando
kontrolliert.
Dialogsprachen
hat zur Formulie-
zugeschnittener
und gibt aufbereitete
und Steuerungsteil
getrennt.
°'klassiscQer"
Menge vom Kommandos
Ein hierauf
der in seiner
ist~ Analyse-
rungsteil
sich
und -Vorrat,
Struktur.
die Eingaben
waiter,
nicht voneinender geordnet,
Terminals
eine vorgegeBene
zur VerfOgung.
analysiert
erungstell
sie unterseheiden
"Grammatiken ")
zur Realisierung
rung seiner Einga6en Modu]
Kdo.-EndBgemeinsam.
Systeme"
Die Dialogsysteme
ran Aufbaus
Oialogsprachen
eines
Funktionstasten)
stark im Kommando-Vokabular
2. "Klassiscbe
Struktur
gibt es ?Or eine groBe Anzahl yon
Dialogsprachenj
yon den eingesetzten
[Spezialtastaturen, -
Unterschiede
spezielle
ablesbare
Folge yon Spezifikationen,
Symbol ~, iet in genau dieser Form den meisten Wager der oben gBnannten
Kommandos
zu-
Aktion reali-
warden yon dam Steue-
der Funktionsmoduln
an den Analy-
31o se- und Steuerungsteil zu steuernden schieden.
ist gew~hnlich auch eu~ die Erfordernisse dos
Prozesees eusgerichtet und somit yon Fall zu Fall ver-
Die verzehnte Schnittlinie
in A~b. 2 soll endeuten,
fig keine explizite Trennung zwischen dem eigentlicben Iogsystems und den Aktionsprogrammen
A6b. 2
Dialogsystem~
klassisch8
vorgesehen
Kern des Oia-
ist.
(problemintegrierte)
Bei diesen auf spezielle Anwendungssysteme
de8 h~u-
L~sung
ausgerichteten
Dialogsy-
stemen ergibt sich eine Reihe yon Nachteilen: nachtr~gliche Erweiterungen schlOsselung,
bedeuten einen Eingrlff in die Ent-
d.h. vom Benwtzerstandpunkt
aus eine ~nderun~ yon
Systemprogrammenj -
jegliche Modifikation des Systems Obersetzung verbunden,
let mit einer anschliegenden
Neu-
also nicht im lauCenden Betrieb dureh¢~hr-
bar; nacbtr~gliche
Integration yon urspr~nglich
unabh@ngigen Teilsystemen
311
wird dutch sprachliche
-
des System i s ~
Inkompatibili~ten
erschwert~
e n l a g e n a # h ~ n g i g mi& den d a r a u s r e s u l L i e r e n d e n
be-
kannten N a c h L e i i e n . Wegen d e r genannen engen B e z i e h u n g z w i s c h e n Anwendung und D i a l o g s p r a che s o w i e d e r e r h e b l i c ~ e n
Unterschiede
zwiscQen den e i n z e l n e n
Ten s i n d Versuche d e r S ~ e n d a r d i s i e r u n g und 5 i s l a n g
n u r a u { eng b e g r e n z t e n
yon D i a l o g s p r a c h e n
Teilge~ie~en
den Programm-SysLemen z u r R e a l i s i e r u n g jedoch,
w~e d i e e i n g a n g s a u { g e z e i g t e n
Sprachen andeu~en, sierra
Anwendung zu Anwendun~ u n ~ e r s c h i e d l i c h e n !eich~
modifizierbar
sind;
Be[
von D~al,ogsprachen l a s s e n s i c h struk&urellen
etwe kOnnen Ober T a b e l l e n
FunkLionsmoduln erleichterL
sehr erschwer&
vor~enommen w o r d e n .
durchaus Verallgemeinerungen
EntsehlOssler
Anwendun-
Gemeinsamkeiten yon
vorstellen. ar6eiten,
Generali-
w e l c h e d i e von
S a c h v e r h a l L e e n ~ h a l t e n und
eine vereinhei~lichte
Sc6ni~tlinie
den A n s c h l u ~ b e I i e b i g e r
zu den
AkLionsprogremme.
3. Des MULI-Sys~em Hiervon
ausgehend
soll des vorgeschlagene
ne Standardisierung heir des Benutzers Abb. 3)
ermOglichen, wesentlich
einzuschr~nken.
kann d e r B e n u t z e r s e i n e
baron Sprachebenen f o r m u l i e r e n , ne b e s t i m m t e Anwendung r e l a t i v (DECODER) i s t
for
Dielogsprachen Form e i n e r Tabellen
Ta5elle
wird
die
DIALOG SYSTEM eiFormulierungsfrei-
In diesem System
Eingaben auf b e l i e ~ i g
yon denen n u t d i e U n t e r s t e ~ e s t engenommen w i r d .
der je~eils
gOiLige
a u B e r h e l b des e i g e n t l i c h e n
als
w~hl-
for
el-
Der E n t s c S l O s s l e r Varianten
yon
Delimiter-Sa~z
lieg~
Codes.
weiterer
Z u o r d n u n g z w i s c ~ e n den e i n z e l n e n
Funk~ionsmoduln hergestell~;
(siehe
v~elen ~rei
A n a l y s e d e r g@ngigen s y n t a k t i s c h e n
ausgeteg~
entsprechenden Tabellen
die
MULTI-LEVEL
ohne die notwendige
MitLels
in
Kommandos und den
durch Manipulation
kann d i e s e m a n ~ i s c h e Bedeutung yon EingaBen b e l i e b i g
dieser ge~ndert
warden. Oer Steuerungsteil
parametrisiert
Ober eine standardisierte rungsteil,
also der eigentliche
den Anwendungsprogrammen Kern a u f g e t e i l t Teil,
triebssystem
Kern des Dialogsystems,
sind wesentliche
Teile
DarOber hinaus
und Steues]nd somit von ist dieser
antagenunab6~ngi~en TeiI
Bez0ge a u f d i e A n l a g e ,
des j e w e i l s
die Funktionsmoduln
EntschlOsseIungs-
sauber getrennt.
in einen gr6Beren,
welcher die
und kontroIliert
Scbnittlinie.
d,h,
zugrundelfegenden
die
und e i n e n
Nardware und des Be-
Recbners e n t 6 ~ l t j
hierdurc6
des D i a l o g s y s ~ e m s auch a n l a g e n u n a b h ~ n g i g ,
312
Abb. 3 3.1
Dielogsystem,
Ober MULI angestrebte
"Mu I t i - L e v e l " - E i g e n s c ha4~@en
Die MULTI-LEVEL-DIALOG-Spreche unabh~n~iA~ menfassung
weiterh&n bestehender
Sprachebene definiert
im Prinzip
ist zun~chst
gestattet Kommandos
wie deren Paremetrisierung,
belieBig
Technik die Zusem-
zu neuen, m~chtigeren
wodureh oBerhaIb
elementaren
viele weitere
Ebene s i n d
~Kommandoname-Funktionsmodul"
Schnittlinie
per de~initionem maschinen-
eine makroBhnliche
Anweisungen
einer ersten,
so-
elementaren
Level yon SpracSmitteln
werden kSnnen.
D i e Kommandos d e r le
LSsung
an g e w O n s c h t e
Gber die
(TASK L I S T )
Akt~onen
o.g.
sow~e d i e
im R e c h n e r g e k n S p ~ t .
Zuordnungstabelstanderdis~erte Au{ d e r
n~ch-
313
sten
Eb,ene warden d i e s e Elementerkommendos zu Benutzerkommandos zusam-
m e n g e f a S t , d~e i n
ibrer
sprachlie6en
F o r m u l i e r u n g an des j e w e i l i g e
lem a n g e p a B t warden kSnnen und d u t c h w e i t g e h e n d e P a r a m e t r i s i e r u n g
Probvolle
A u s n u t z u n g des z u g r u n d e l i e g e n d e n Systems e l e m e n t a r e r L e i s t u n g e n e r l e u ben, Wenn etwa d e r B e n u t z e r im V e r I a u T s e i n e r
T~tigkeit
ne b e s t i m m t e F o l g e yon ElementarEommandos h ~ u f i g
am T e r m i n a l e i -
e r n e u t e i n g e b e n muB,
wird
e r genau d i e s e Sequenz zu einem neuen Kommando zusammenfassen w o l -
len,
m i t welchem e r d i e s e l b e n A k t i o n e n z u k O n f t i g
kannj
solcherert
"deTinierte"
Abb,
Kommandos
4 zeigt
Kommandos:
eine
und
Antrieben SON,
SETP
und
e£nes
Ventilen
gegebenenfa3is
HierarchLe
Kommando
Einschalten
zum Einschalten
genannt.
solche
des def,
Elementarkommandos wertes
geschlossen auslSsen
zusammengefaBte Kommando-Makros warden im f o L g e n d e n
von d e f i n i e r t e n
STELLE
(siehe auch
und SON z u s a m m e n g e s e t z t
e i n e s Antr/ebs)3 etc.
umfaBt
das
mit m e h r e r e n
STELLE-KommanOo
mehrfach.
t KOMMANDO$
I
DEFINIERTE KOMM~'~DOS
EL~6MENTA RE
l
PROEEDL~REN
i ~INSTELLEN AKTIONEN
SOLLWERT.GEBEIK
F~NSCHALTEN ANTRIEB
A USSC~JALIEN ANTR~B
Abb. 4 K o m m a n d o - N i e r a r c ~ i e , Ebenen e l e m e n t a r e r und d e f S n i e r t e r
elementaren
I) ist aus oen
(ELnstellen
DEFL~IERTE
KOMMA~DOS
und
das d e f i n / e r t e
grSlSeren Aggregates
jewe13s
Abb,
Kommandos
eLnes
Kommando
Sell-
AGGEIN
SoI3wertgebern, sowie
SETP
und
3i4
Diesel h e ~ a k r o t e c h n i k
wird
bei der Bildung
Zusammenfassung beliebiger teren
de~inierten
Sprachmittel probleme
einerseits
anzupassen,
[z.U.
Lagerist,
Eine neue zuf~gung
verschiedene
Manager)
Spezifikationen beIiebig
zu s c h e f f e n .
Kommando-Definition oder V e r B n d e r u n g
mit
an einer
rungen
[DECODING
LIBRARYJj
stehen
spezielle
Elementarkommendos
dieser
Art
ohne P r o g r a m m i e r a r b e l t e n
des S y s t e m s
und s o m i t
Spraehebenen
bei
System
internen
nut
for
weni-
nocn w e n z g e n o ~ e r
elngebracht
Lists yon
Manipulationen
zur
Klas-
ass
sind.
in des
for soZche
for
und B e d O r f n i s s e n
denen Stan~ard&eistungen
abru~bar
wird
~e
Anwendungs-
Benutzerebenen
Kenntnissen
bestehen, elnfech
es m S g l i c h ,
spez[eilen
w e r d e n aus Kommandos m i t
durch
Komman~os zu we~-
ist
an d i e
unterschledlichen
Benutzer
Gesamt-Systems
Hierdurch
leicht
andererseits
mit
Ingenieur,
sachkundige
gap keinen
Oberheupt
Spracbebenen
und d e f i n i e r t e r
Kommandos a n g e w e n d t .
sen yon B e n u t z e r n ger
elementerer
weiterer
VerfOgung,
Hin-
Kommen~o-Vereinbaam O z a 3 o g - S y s t e m
sodaB
und a n s c h ± i e B e n d e
Bedar~ auch on-line
dutch
Anpessungen
Neuubersetzung
vorgenommen werden
KSn-
nen.
Oer interne Bei
Kommendo-Ketalog
Elementarkommandos
Namen
und der
entb~It
bestebt
auBerdem
der V e r e i n b a r u n g s - R u m p f nach w e l c h e r
mentare n
und evtl.
5 zeigt
gestellte
yon bierin
Ober mehrere weiss wird
in sine
Stufen Folge
aus der TASK
diese
Information
Kommandos
in Form
dem S t e u e r u n g s Durch des
Ansto6
E×ECUTER
sozierte
Kommando-
Kommandos
wird
dle Z e r l e g u n g s v o r -
in eine
Kommandos
aus d i e s e r
Kommando.
aus dem
Foqge
aufzu±6sen
Liste f~r die
yon
ele-
1st.
in Abb.
4 ~er-
Kommando-Hierarcbie.
Bei der E n t s c h l O s s e l u n g aufgrund
d.b.
Kommando
definierten
Ausschnitt
for jedes
bei d e { i n z e r t e n
engegeben,
des b e t r e f f e n d e
wiederum
einen
Eintreg
im w e s e n t ± l c b e n
Lists der S p e z i f i k a t i o n e n ;
schrift,
Abb.
einen
dieser
eines
eingegebenen
eingeschachte±ten gehen yon
kann,
wird
Leistung
des
Elementarkommandos3
zusammen
mit den
aktueIlen
AusfOhrung
erbrecbt.
definierten
zu jedem
[EXECUTERJ
des
die
Kommandos
diese
schrltt-
Elementarkommen~o ermittelt
und
Spezifikationswerten an die
der F u n k t i o n s m o d u l n
schlieBlich
Kommandos,
MULI-System
Funktionsmodu~
Bescbreibungsblocks
und A u s f O h r u n g s t e i l
und
welteren
zerlegt
LIST der z u g e o r d n e t e
sines
definlsrten
des
Wartescblangen Systems
vor
Obergeben.
unter der Kontrolie
die mit dem e l n g e g e b e n e n
Kommando
as-
315
elementare Korpman~o~ (unterste Sprachebene) cname (:~ame ~narne
SETP SON $OFF
¢soecifs (SETP-ID, VALUE) ~specif~ (DRIVE-ID} ~!fs {DRIVE-ID}
definierte Kommandos {h6bere Sprachebene| cname STELLE ¢sDe~ifs (VENTIL, PROZENT (100)), SETP, ref VENTIL, Z~f PROZENT. SON , r e f VENTIL. Cname AGGEIN ocsoecifs
(AGG-ID),
SETP, ~ A G G - / D I! SO2, 100. SETP, ref AGG-ID • SO4, 80.
STELLE, ~ AGG-IDII V01, 50. STELLE, r/el AGG-IDII VO2, 70,
SON SON
Abb.
5
Eintr~ge
Abb.
6 gibt einen Oberblick
6
Obersicbt
,
in Liste der Kommando-Vereinbarun~en 0bet die Beusteine,
und Dateien des MULI-Systems
Abb.
, ref AGG-ID II A02, r__e/_AGG-ID II AO4.
MULi-System
und die Beziehungen
d.h.
Programm-Modul
zwischen
ihnen.
316
3.2......Flexibi/it~t,
AnPassung,,en
Des M U L l - S y s t e m insgesemt setzt slch zusammen aus einem Minimal-System, welches die G r u n d f u n k t i o n e n Menge yon Optionen, Oefault-Werten,
Funktionsmodul
ist
oder der direkte
und einer
der Be-
FOr e~ne konkrete
Implemen-
S y s t e m - G e n e r i e r u n g des j e w e i 3 s angemessene d,h,
aus dem M i n i m a l s y s t e m und Oen Up-
[ s i e h e Abb, 7J e i n den E r f o r d e r n i s s e n
e n g e p a B t e s System zusam-
menzubauenj
hierfSr existiert ein G e n e r i e r u n g s p r o g r a m m mit den ent-
sprechenden
Steuer-Parametern,
bedarf
(Code- und Listenl~ngenJ
fluBt werden, 8enutzer
Mit diesem kBnnen zum einen und Zeitverhalten
zum enderen teilweise auch dis spezlelle Schnittlinie zum
(z.B. Delimiter~
festgelegt werden.
o
Se~splel fur Aus~gun9
MULI-
Kernspeicher-
des Systems beeln-
ox,mo,-Sys,em 0%
Abb, 7
oOer
I n f o r m a t i o n s a u s t a u s c h zwischen
und B e n u t z e r am Terminal.
im Rehmen e i n e r
MULI-System zu " k o n { i g u r i e r e n " , tionen
umfaBt,
die P r l o r ± t ~ t s - S t e u e r u n g v e r s c h i e d e n e r Benutzer,
trieb im Request-Mode
tierung
eines Dialog-Systems
b e i s p i e 3 s w e i s e die Zu±assigkeit yon FOlltexten
System-Ausbau
~v ~
317
In der
Generierungsphase
vorgenommen,
d.h.
Kerns
a u c h Abb.
lsiehe
die
das D i a l o g - S y s t e m tabilit~t
v.
3]
So{twareJ
Kommandos tionen
die Die
betceffende hierbei
POLYP z u r
die
Anlegen-Anpassung des
umgesteIZt
und i n [Por-
im wesentlicben
aus dec Verwendung
des M U L I - S y s t e m s ,
ist schlieB±ich
in einer
an die jeweilige
Initialpbese
etabliert,
bestehend mindestens
zur Anspraehe
der zur Steuerung
sowie den dazugshSrenden
Anlage
Tei3e
gegebensn MSgliehkeiten
Codierung
System
hierzu wird
ferner
und b e t c i e b e s y s t e m a b b @ n g i g e n
ecgeben sich
generierte
dung anzupassenj mandovorrat
auf
eingefOgt,
dec Programmiersprache
Das solcherert
des S y s t e m s w i r d
hardware-
des Betriebs
Anwen-
ein Kom-
aus einem Satz elementerer
des Prozesses
Funktionsmoduln.
notwendigen
Dies gesehieht
Ak-
bereits
im Dialog mittels
s p e z i e l l e r zum MULi-System
geh~render
mandos.
yon den Elementarkommandos
k6nnen nun unter Ausnutzung
Ausgehend
der in Absehnitt
3.1 vorgeetellten
get neuer Kommendos
auf hBheren
der Kommando-Vereinbarungen) Anwender-Funktionen die verwendeten
M~glichkeiten
Spraehebenen,
weitere
zur VerfOgung
Namen for Kommsndos
Rest der sprachlichen
Die verschiedenen
sung sind
im Zusammenhang
werdenj
bel±ebi-
der Liste
zur Benutzung
der
hierbei wire dutch
und Spezifikationen
Schnittlinie
angepaBt.
(Definition
Modifikation
Spraehmittel
gestellt
Eintrage-Kom-
zug3eioh
zum Benutzer an dessen
Aspekte yon System-Generierung
und Anpas-
aus Abb. 8 ersichtlicb.
in Initial-Phase yoreBenutzeroufgebaut
und im Be~r~_K~b (~nder~ KommandoVokabulof, - Mdch|igkeit
[ANWENDUNGJ rat, Fur'~tionsmodukt
etementarer_ b, gdo.-Vet
Fo~ma|ismen / der Kdo.-Eingobe,
DIALOG-
Leistung
SYSTEM
durch .~y s..~eJ~ ~en~=deru_~n&
~ F
~- Betriebsr System
L
HardworeEigenschaften
definier!
Abb. 8
Schnittlinien
Oialogsystem/Umgebung,
Anpaseungen
der
BedOrfnisse
318 Mit diesen M6glichkeiten Sprachmittel
parallel
d e r System-Anpassung und d e r M o d i ~ i k a t i o n
zum B e t r i e b
Werkzeug ~Or den D i a l o g
das MULI-System e i n f l e x i b ± e s
z w i s c h e n Mensch und t e c h n i s c h e m Proze6 d a r .
Das Vorhaben w i r d g e £ 6 r d e r t D V - A n l a g e n " im 2.
stellt
der
im Rahmen des P r o j e k t e s
"Preze61enkung mit
DV-F~rderungsprogramm d e r B u n d e s r e g i e r u n g ,
ERFAHRUNGEN ~BER DIE VERFOGBARKEIT VON 0N-LINE PDV-SYSTEEEN IN EIN~E HOTTENWERK von G. W i e t h o f f , H . - J . S t ~ b l e r u n d R.HeBling
Zusammenfassun ~ Es wird Gber ein Programmsystem berichtet, das es erlaubt, Erfahrungswerte Gber StSrungen, Wartungsarbeiten und VerfGgbarkeit von on-line PDV-Systemen zu gewinnen. Bisherige Erfahrungen an mehr als 10 im HGttenwerk eingesetzten Systemen werden mitgeteilt. I. Einleitun~ In neuen Produktionsanlagen der HGttenwerke werden heute im zunehmenden HaBe ProzeBrechner fGr aktive Steuerungsaufgaben eingesetzt. Damit steigt die Gefahr, dab bei einem Rechnerausfall ganze Produktionskapazit~ten stilliegen. Es wird daher immer wieder die Frage nach dem damit verbundenen Risiko und der Notwendigkeit von Doppel-Rechnersystemen oder sonstigen Back-up-Einrichtungen gestellt. Die Beantwortung dieser Fragen h ~ g t wesentlich v o n d e r effektiven VerfGgbarkeit der Rechner in den Produktionsbetrieben
ab.
Die Hoesch HGttenwerke AG hat deshalb im Rahmen einer vom 2. DV-Programm der Bundesregierung unterstGtzten Forschungsarbeit ein System entwickelt, um Erfahrungswerte Gber die effektive VerfGgbarkeit von on-line PDV-Systemen zu gewinnen. Das System beruht darauf, dab alle StSrungen, Ausf~lle oder sonstigen Arbeiten an den zur Zeit etwa 15 eingesetzten PDV-Systemen nach einheitlichen Gesichtspunkten in ablochf~higen Uraufschreibungsbelegen erfa2t und anschlieBend im Rechenzentrum mit Hilfe eines FORTRAN-Programms ausgewertet werden. Bei den PDV-Systemen handeltes sich um ProzeBrechner verschiedener Hersteller fGr Steuerungsaufgaben in Hochofen-, Stahlwerks-~ Walzwerksbetrieben und Labors, sowie um Betriebsrechner fGr dispositive Aufgaben der Produktionsbetriebe. 2. Erfassun ~ der StSrun~en Zum Erfassen jeder StSrung PDV-System ausgewirkt hat, oder Ingenieur den in Bild
oder sonsti~en Arbeiten am PDV-System oder sonstigen Arbeit, die sich auf das fGllt der verantwortliche EDV-Techniker I dargestellten Beleg "Arbeiten am PDV-
321
AM PDV
•
~IRMA
~.#,,.,..~~
*
DIV,,*..~. ~ o
2
FREbfuF/RMA
I
DATENTYP~! "
,.~"~
-~
GERUFEN
~
SEGINN
3,AU~,FA._L~-_~l ~ WAN R EN D PRODUKT!ONSSTILLSTAND
, PnV-~"STEI,I~ ~
"
"
ENDE
ENDE 5.STtLLSTAND 6 AUSW~RKUNG AUF
~ROD.-BETR~EB HARDWARE
92_s@
1. . . . . .
19. AUSGEFOHRTE ARBEITEN I..................... 10 TEXT £
Bild 1.
IERFA~T:
Beleg mit Eintragung einer St6rung des Hochofensteuerungsrechners Siemens 301 vom 1.1.73. Ausfallzeit 6 h mit Stillstand des Rechners. Ein 8chreib- und Lesekopf des Plattenspeichers muBte durch den Wartungsservice des Herstellers ausgewechselt werden. Der Hochofenbetrieb wurde zwar gest6rt, konnte jedoch mit einer vereinfachten Back-up-Steuerung in seinen wesentlichen ~ J ~ t i o hen weitergefahren werden.
L:~i,,'t'J
322
System" aus. Es werden mit Hilfe einer SchlGsseltabelle die Nummer des PDV-Systems, - die Ausfallzeit, gegebenenfalls die Inanspruchnahme tungsdienstes des Herstellers,
eingetragen:
-
eines War-
- ein Betriebsstillstand der Produktionsanlage w~hrend der Ausfallzeit des Rechners, - die Auswirkungen auf den Produktionsbetrieb und - n~here Angaben ~ber StSrungsursache und ausgefGhrte
Arbeiten.
AuBerdem wird angegeben, ob das Rechnersystem zum Stillstand kam. Die Belege werden direkt dem Rechenzentrum zugeleitet und dort abgelocht. Im Jahre 1973 wurden fGr alle Systeme etwa 1000 Belege ausgefGllt. 3. Pro~rammsystem zur Auswertun~ Das zur Auswertung erstellte Programmsystem ±st in FORTRAN-IV ges c h r i e b e n u n d l~uft auf einer IBM 370-155. Ein vereinfachter DatenfluBplan ±st in Bild 2 dargestellt. Da die Daten Gber l~ngere Zeitr~ume ausgewertet werden sollen, wurde eine BestandsfGhrung aufgebaut. Bevor die Heldungen in den Bestand aufgenommen werden, werden sie zun~chst im ersten Programm einer umfangreichen, bestandsUnabh~n~igen Formalfehler-PrGfung unterworfen. U.a. wird die GGltigkeit des 0rdnungsbegriffs (System, Ausfallbeginn) und der benutzten SchlGssel GberprGft. S~tze mit fehlerhaftem 0rdnungsbegriff werden abgewiesen, andere Fehler fGhren zur Kennzeichnung des entsprechenden Feldes im Datensatz. Alle S~tze werden mit den fehlerfreien S~tzen an das Programm "BestandsfGhrung" weitergegeben. S~tze mit Ordnungsbegriffsfehler w e r d e n h i e r ins Fehlerprotokoll geschrieben, ebenso Fehler, die dutch bestandsabh~ngige PrGfungen (z.B. ZeitGberschneidungen mit bereits vorliegenden Heldungen) in diesem Programm ermittelt werden. $~tze mit einzelnen, fehlerhaften Feldern werden zwar ebenso protokolliert, jedoch auch mit den fehlerfreien S~tzen in den Bestand aufgenommen. Die fehlerhaften Felder bleiben in diesem Fall gekennzeichnet und kSnnen Gber Korrekturen beim n~chsten Lau£ ver~ndert werden. Abgewiesene S~tze mGssen neu aufgegeben werden. Der Bestandszugang wird in einem Bestandszugangsprotokoll erfa~t. An diese BestandsfGhrung schlieBen sich 4 Arten von Auswertungen an, die unabh~ngig voneinander abgerufen werden kSnnen. Unter Hinzuzlehung der Planbelegungszeiten der Betriebsanlagen und einer parame-
323
Korrekturen t Neuzug~nge
1
II I
..... i
[ Fehlerprotokolle I [ zugangs- [[ AuswertungsL Zeitraum
--111' |
~ Parameter
',
Auswertung der | Ausfallzeiten
Jl Bild 2.
Auswertung der Ausfallhgu figkeit
i
II "11' Auswertung der ~emdfkmen-~Eins~tze
List d!
DatenfluBplan des Programmsystems zur Auswertung
AuszUge ausdem Bestand
1
324
trischen Auswahl des Auswertungszeitraumes
wird eine Liste der Aus-
fallzeiten erstellt. Hier gehen die St~rungen ein, bei denen es zum Stillstand bzw. off-line-Betrieb des Rechners kam. Die n~chste Auswertung bezieht sich auf die Ausfallh~ufigkeit net Systemteile mit Summenbildung fGr
einzel-
Ausf~lle einzelner Ger~te, getrennt nach Ursachen Ausf~lle einzelner Ger~te, getrennt nach ausgefGhrten Arbeiten
-
-
Ausgef~hrte Arbeiten, getrennt nach Ursachen dieser Ausf~lle.
-
Ferner gibt eine weitere Auswertung einen 0~oerblick Gber FremdfirmenEins~tze im Rahmen der Wartung. SchlieBlich lassen sich, gesteuert durch Auswahlparameter, AuszGge aus dem Bestand machen. Die Laufzeiten auf der IBM-Anlage betragen bei einer gemeinsamen Auswertung aller Systeme: - fGr die BestandsfGhrung ca. 5 Minuten - fGr die Zeitauswertung ca. 3 Minuten - fGr die H~ufigkeitsauswertung ca. 3 Minuten - f~r die Auswertung "Fremdfirmeneinsatz" ca. 5 Minuten. Die BestandsfGhrung l~uft monatlich, die Auswertungen normalerweise viertelj~hrlich. 4. Protokollierun~ der ~rfaBten Anla~enstillst~nde Der erste Ausdruck des Programmsystems gibt je PDV-Anlage chronologisch die Meldungen wieder. Hierbei werden die verschlGsselten Eintragungen Gber Texttabellen in Klartext umgesetzt. Im Bild 3 sind der Ausdruck des in Bild I dargestellten Beleges (Hardware) und ein Software-Ausfall eines anderen Systems wiedergegeben. Die Ausdrucke sind in 6 wesentliche Spaltenunterteilt. Im 2. Fall gilt: - Datum u n d U h r z e i t mit Ausfallzeit z.B. 6.2.73/5.20 Uhr als Anfangszeit, 6.2.73/8.08 als Endzeit 2,48 h als Zeitaufwand Hinweise auf die Auswirkung der StSrungen auf das PDV-System, wie Stillstand des Systems, Notbetrieb, Inbetriebnahme. -
-
Im Beispiel nein, ungestSrt, somit kein EinfluB auf den Betrieb. KGrzerer verbaler Text, maximal 20 Stellen. Im Beispiel wird ein Hinweis auf das P r o g r a m m u n d platz gegeben, 0520 HW 01170.
den Speicher-
~
~ ~ ~~ : i
an 2 PDV-Systemen.
Der Hardware-
-
............................... K Z ..........AEFSC~E"FUE~H'RTE "~R:BE~IT ....
mit einem Hardware-
............... O~ ,~.,.0 ..................,.:,~.=~,~~ = = ~
ausfall gibt die M e l d u n g in B i l d I wieder.
u n d einem S o f t w a r e a u s f a l l
aus dem Z u g a n g s p r o t o k o l l
.......... .................................
ZT;~ F
........................................................................................... T~g~-ZT
Ausschnitt
~ : ~ = :::~ ; ~ : ~ , T O ~ . ~ y
B i l d 3.
.............................................................. ~:~
TF~7
P~,,V=SYST~
ZTaU IF~ P R U D = ~ E
ZT ;
...........................................................
L~AI E FT
kJ4
326
- Datum und Uhrzeit des Produktionsstillstandes, der Grund gibt einen Hinweis auf die Auswirkungen des PDV-Stillstandes. Im Beispiel "keine Produktion", somit auch keine Auswirkungen auf den Betrieb. - Fehlerursache mit Kennzeichnung der betroffenen Hardware und Hardware-Fehlerbeseitigung. Die im Beleg erfaSten Kenn-Nr. fihren zu dem Ausdruck des festgelegten Textes. -
Einsatz der Fremdfirma mit Datum und Uhrzeit einschl, der Angabe des Ruf-Zeitpunktes ~ s t im Ausschnitt des Bildes 3 nicht enthalten).
5. Zeitauswertun5 der Rechnerstillst/nde Zeitauswertungen und die Verfdgbarkeit je System werden in einem Protokoll "Auswertung der StSrungszeiten am PDV-System" zusammengefaBt. FGr diese Auswertungen werden nur StSrungen bzw. Arbeiten berdcksichtigt, die zu einem Rechnerstillstand fGhrten. Dieser ksn~ sowohl dutch Hardware-, als auch Softwareursachen ausgelSst sein. Einerseits wetden alle Ausfille auf die Kalenderzeit bezogen. Diese Betrachtung geht davon aus, dab das PDV-System eigentlich "fund um die Uhr" einsatzbereit sein muS. Andererseits werden die Ausfille in einer getrennten Berechnung auch aus der Sicht des Produktionsbetriebes gesehen, d.h. Rechnerausf~lle, die sich mit einem Produktionsstillstand aus anderen GrGnden (z.B. Reparaturschicht) Gberdecken, werden nicht gewertet. Bild 4 zeigt am Beispiel der Jahresauswertung 1973 des Hochofen-Steuerungsrechners Siemens 301 welche Daten des Protokoll u.a. enthilt. In Zeile 3 sind fGr die Stillst~nde des Rechners einschl. Wartung 35 Ausf~lle angegeben, mit insgesamt 198 h 42 min Ausfallzeit. AuBerdem sind angegeben: eine mittlere Ausfallzeit yon 5 h 40 min, eine Standardabweichung der Ausfallzeit yon 6 h 39 min, eine minimale Ausfallzeit von 6 min, eine maximale von 33 h, eine Ausfallzeit bezogen auf die Kalenderzeit yon 2,3 %, eine VerfGgbarkeit von 97,7 % und eine MTBI (Mean time between incidents) zwischen zwei Stillst~nden yon 244 h. In den Zeilen I und 2 sind diese Stillst~nde aufgeschlGsselt in StSrungen (31) und Wartungsarbeiten (4). Zeile 4 zeigt die Rechnerstillst~nde aus der Sicht des Hochofenbetriebes: Sie stSrten in 29 F~llen. Da einige Rechnerstillst~nde mit
327
AU$WERIUNG DER SIO~kUNG~LEiIEN AM PDV-SYSIEM
SYSTEM: 38HO~-S|EMENS 301,LEJIRAUM~
EANZL. SUMME B I T / . SIAND I DER D£~ ~ERT ARgA~ I AUS- AUSFALL AUSF. WEICM IF~ELZEITEN Z £ 1 1 O~G I LE H I M I N N/M|N HIMIN R EC HN E RE I !.
SI ILLSIAND !
2,,
WARTUNG
~,,
SUMME
M t
31 4
1 I i
35
151-Z7
RECHNER VER~ URSACHTE I $IOERUNGI I
GARANTIEGERAETE 5-
Bild 4.
NG
67.15 11o@8 14.22
1.00 33.00
0.5
0.0b 33.00
2 . 3 97.7
244
1.6 98.~,
.263
0 . 9 99.Z
789
198.~2
126.02
6.35
5.~0
T
~.20
MI T
11
W ARTU
AUSF VER MTBI ZI / FUE@ ~.~EREb~N. BEZ. B A R LEIfKAUM ZElT KEII % i HIM~N
1.7 98.3
~ l
SIILLSIAND E DURCH ZE,PZE I EXIEgNSPEICH. X
MAX. AOSFALL- FALLZEII ZEIT H/MEN H/BIN ALS-
0.06 Z3.08
MI
29
MEN.
@.53 ~.53
PROOUKTION E I 4
T
i. 1.73 5~S 5 I . L Z . 7 ~
78.3fi
7°08
277 2 178
WA R T U N G
*°42
0.06 23.08
WA R T U N G
6.41
O.~O 23.08
Ausschnitt aus dem Protokoll "Auswertung der StSrungszeiten" fur das Jahr 1973 des HochofenSteuerungsrechners Siemens 301.
328
geplanten Ofenstillst~nden Gberlappten,
ergibt sich eine etwas h~here
VerfGgbarkeit des Rechners von 98,4 % fGr den Betrieb. Die Bezugszeit in dieser Berechnung ist die geplante Produktionszeit des Hochofens im Jahre 1973 mit 7761 h (Planbelegungszeit). SchlieBlich sind in Zeile 5 die Hardwareausf~lle der Zentraleinheit, des Plattenspeichers und des Proze~elementes (Interface) angegeben, sofern sie zum Rechnerstillstand fGhrten. Die 1 1 A u s f ~ l l e dauerten im Mittel 7 h 8 min. Die HardwareverfGgbarkeit neranlage betrug 9 9 , 1 %
fGr diesen Kern der Rech-
und die NTBI 789 h.
Im nachfolgenden Beispiel wird die Anlaufphase dieses Rechners mit Hilfe der Auswertung entsprechender 3-Monats-Protokolle 6. Erfahrun~en mit einem Hqchofen-Steuerun6srechner
behandelt.
im ersten Jahr
nach Inbetriebnahme Ende August 1972 wurde ein neuer Hochofen in Betrieb genommen, dessen gesamte Beschickung mit Einsatzstoffen vom ersten Tag an mit dem Siemens-Proze~rechner 301 gesteuert werden muBte. Aus Sicherheitsgr~nden ist eine festverdrahtete Back-up-Steuerung vorhanden, die bei Rechnerausfall nur unbedingt notwendige Funktionen vereinfacht aufrechterh~lt. In den Bildern 5 und 6 sind die wesentlichen Ergebnisse der Zeitauswertungen in den ersten 4 Quartalen (August 1972 bis August 1973) dargestellt 1). Sie lassen erkennen, dab im I. Quartal noch erhebliche Schwierigkeiten auftraten, die d a n n b i s zum 4. Quartal stetig geringerwurden. Im Bild 5 sinkt die Anzahl der Rechnerstillst~ude von 36 h auf 2 h und die gesamte Stillstandszeit je Quartal von 137 h auf 8 h, w~hrend die mittlere Stillstandszeit zwischen 4 und 6 h liegt. Sehr stark fallen die Ausf~lle infolge SoftwarestSrungen ins Gewicht. Sie verursachen im I. Jahr mehr als die H~lfte der Stillst~nde.
1) Forschungsbericht der Hoesch HGttenwerke AG im Rahmen des 2. DVProgrammes, Projektbereich P 6.2/30, :'Steuerung eines Hochofens, Siemens 301 mit back-up".
329
is°t
Anzahl der RechnerstiUstande und Ursachen
40
30
c- 20 C~ N C 10 < 0
Softwarefehler.. 22 Hardware und s o n s t i g e Fehter Hardware
6
Rechnerkem
1.
wahrend Prod.-Stillstand
28 //
100
/
50
7
/
w~hrend / Produktion --_______ /
/
103
/ /
" " 64 .
Prod.-Stil[stand wurde verursacht
6
/ /
24
"
//91
// i, /
/,
6 r'-'q 2
4. Quartal
3.
Ivlittlere Stillstandszeit
t
138
h
1. Bild
"
.
2.
1. t0 L
10
//
/
// 0
/..Ouartal
2.
Stillstandszeit im Quartal
150
h
I i;.;...d
~z
.
.1oil .. L 2.
3.
/..Quartal
Betriebssicherheit des PR Siemens 301 zur Hochofensteuerung in den ersten 4 Ouortolen noch Inbetriebnohme
330
Im Bild 6 ±st die Zunahme der VerfGgbarkeit und der MTBI des Rechners in den 4 Quartalen dargestellt, und zwar Jeweils fGr den Rechner w~hrend der Kalenderzeit, fGr den Hochofenbetrieb w~hrend der Planbelegungszeit und fGr die Hardware des Rechnerkerns, Zentraleinheit, Plattenspeicher und Interface. Han erkennt, dab schlieBlich im 4. Quartal mit 99,6 %, 99,9 % und 99,7 % sehr zufriedenstellende Werte der VerfGgbarkeit und Gber 80 Tage MTBI aus der Sicht des Betriebes erreicht wurden. Es wird irides auch deutlich, wie komplex der Anwender die Betriebssicherheit solcher Anlagen sehen muB und wie lange die Anlaufphase aus den verschiedenen Grt~nden dauert. 7- Verffi~barkeit von PDV-Systemen Im Bild
7
wurde der Versuch gemacht, die VerfGgbarkeit der wichtigsten
PDV-Systeme der Hoesch HGttenwerke zusammenfassend darzustellen. Als Auswertezeitraum wurde entweder das gesamte Jahr oder das 4. Quartal 73 gew~hlt, je nachdem wie lange die Systeme schon in Betrieb waren. Au~erdem wurde unterschieden nach Systemen mit einem Gesamtaufwand fGr Hardware und Software yon unter und Gber I Hio DM. Es best~tigt sich, dab die grS~eren Systeme oft eine geringere Verf~gbarkeit aufweisen als die kleineren. Dies dGrfte z.T. mit der schrittweisen Inbetriebnahme neuer Programmkomplexe bei bereits laufenden Grundfunktionen zusammenh~ngen. Ein grSBeres System, das bereits seit 1967 in Betrieb ist und an dem nicht mehr ge~ndert wird, besaB 1973 eine VerfGgbarkeit yon Gber 99,7 %. 8. Auswertun~ und Analyse der I n s t a n d h a ! t ~ ~ Das sinnvolle Auswerten der Erfassung der Arbeiten an den PDV-Systemen besteht nicht nut in der Stat~tik, wie VerfGgbarkeit oder HTBI, sondern auch in der Analyse der Daten. HierfGr sind weitere GegenGberstellungen programmiert worden. -
Bei allen M i e t a n l a g e n u n d in vielen F~llen auch be± Kaufanlagen wird fGr die Instandsetzungs- und Wartungsarbeiten die Lieferfirma hinzugezogen. HierGber gibt eine Aufstellung ~ber den Fremdfirmeneinsatz Auskunft. Wichtige Kriterien sind hier die H~ufigkeit des Einsatzes und die Rufzeit° So wurden be± 836 untersuchten Systemstillst~nden nut in 18 % der F~lle die Firmen zu Hilfe gerufen. DaB es sich hierbei um schwierige St~rungen
331
VerfQgbarkeit 100 -
99,9 99,7 99,6
9!9 98
t
%
97,2
97 96
95,5
95
95,4
9/,,9
9/,,1 93 92 91 90
1. 2. 3. 4.Ouartai Mittlere Zeit zwischen zwei RechnerausfaUen(MTBI) 2000 -
/
#
1500
1000
h
./
500
/
-"\\ /
8O
70 60 50 I 40 -30 • -20 ~-
0
1.
Bild 6.
2. 3. &Quartal PDV Anlage Aus Sicht des Prod.-Betriebes Hardware Rechnerkern Betriebssicherheit des PR Siemens 301 zur Hochofensteuerung in den ersten 4 Quartalen nach Inbetriebnahme
95
97
w~hrend Inbeffiebnahme
4.Ouartal
Siemens 306
&Quartet
Siemens 306
4.O,uartat
AEG 6050
wdhrend Inbetriebnahme
L,.O,uar ta[
Siemens Duplex 305 Jahr
AEG 3x 6 0 - 1 0
System > 1 Mio DM Hardware + Software
.I
seit 1967
Jahr
PRODAC 550
Bild 7. VerfQgbarkeit von PDV-Systemen
Berne rkung
Auswertezeitraum I973
Rechner typ
%
98
99
PDV Anlage [ ] Aus Sicht des Prod.- Betr. [ ] Hardware Rechnerkern
4.Quarfal
Siemens 301
Jahr
Siemens 301
Jahr
AEG 6010
seit 1967 Erweite rung 1973
Jahr
Siemens 30A
off-line System
Jahr
Siemens. 305
System < Mio DM Hardware + Software
ilill
k~4 r'o
333
handelte,
zeigen die Zahlen der StSrungsdauer,
die im Hittel Gber
alle F~lle bei 3,9 h, jedoch in den F~llen mit Fremdfirmeneinsatz bei 8,2 h lagen° Nicht zu vernachl~ssigen ist auch die Rufzeit, sie bet~Ig im Mittel 1,4 h. Aus diesen Angaben kann die Konsequenz gezogen werden, dab ein eigener Wartungsdienst fHr die einfacheren StSrungsf~lle die rentabelste LSsung ist. Weiterhin kann diese Auswertung als Unterlage fHr die Abrechnung der Ausfallzeiten bei Hietanlagen dienen. In 3 Hatrixlisten werden StSrungsursache, betroffene Hardware und ausgefGhrte Arbeiten gegenGbergestellt. In der ersten Aufstellung werden die StSrungen nach den Ger~teeinheiten, den gestSrten Elementen und der Ursache analysiert. So zeigt sich, dab die Zentraleinheit und der Verkehrsverteiler bzw. ProzeBdatenformer in 60 % von 800 F~llen beteiligt war. Die n~chste Liste gibt einen Einblick in die St6rungsbehebung. Die ausgefGhrten Arbeiten, wie Wechseln von Bausteinen, Reinigen yon Kontakten, Beseitigen von Programmfehlern, Wiederanlauf, sind den Fehlerursachen, wie Halbleiter, Elektronik-Baugruppen, Stromversorgung und auch Betriebssystem- oder Anwenderprogrammen gegenHbergestellt.
66 % der Ausf~lle konnten durch SoftwaremaB-
nahmen beseitigt werden. In einer w e i t e r e n A n a l y s e werden die ausgefGhrten Arbeiten auf die betroffene Hardware, d.h. die Ger~teeinheiten, bezogen. Hier kristallisiert sich damn auch der groBe EinfluB der Programmfehler heraus. Dieser EinfluB ±st w~hrend der Inbetriebnahme und nach jeder Programm~nderung deutlich erkennbar und muB zu entsprechenden, grunds~tzlichen Ma~nahmen AnlaB geben. 9- SchluBbemerkun~ Das Programmsystem liefert erst seit kurzem die beschriebenen Auswertungen. Sie zu nutzen, wird Aufgabe der n~chsten Zeit sein.
SICHERE
PROZESSDATENVERARBEITUNG
KARL-HEINZ
Die MSglichkeit, den analogen
Proze[~steuerung bzw.
sprechen.
eleklronischer
Prozessen
erschwert
bet dem
Einrichtungen
problematisch
erscheinen
sobald die steuernden
Einfallen der Bremsst~be
gnale und Ansprechen
zum
da~ bet St6rungen
keine falschen Signale abgegeben, bezeichnet
abgeschaltet,
Bahnen
Verhalten
schnelle Fehlererkennung.
Nach
der
bestimmter
der Aufdeckung
Technik
auf eine Reserveeinheit
sen Fortffihrung Seit langem genommen
Umschalten
Haltstellen der SiHier muI~ "nurt'
werden.
ist eine sichere und
n~mlich
dem
ist es meist Abschalten
nur noch des Systems
zur unterbrechungslo-
des Betriebes.
ist das Prinzip werden
eines Ergebnisses
z. B. wer-
abgeschaltet
eines Fehlers
oder
- dem
bekannt,
nach dem
kann: die gleichzeitige in zwei (oder mehr)
heiten und dern Vergleich
der Ergebnisse
eine derartige
Fehlererkennung
oder nacheinanderfolgende
gleichartigen, in einem
voneinander
an diesem
der Bundesregierung
Vorhaben
untersttitzt.
wurden
unabh~ngigen
sicher arbeitenden
mit Mitteln aus dem
vor-
Erarbeitung Ein-
Vergleichs-
element. *) Die Arbeiten
Zu-
des Steuersystems.
Reaktion,
noch
ungef~hrliehen
durch
ein kleiner Schritt zu der gewGnschten - besser
f~ihrt.
spzifischer
Kernreaktoren
alle Steuersignale
eingesetzten
oder der zu
oder des Steuersystems
dies auch als das "Fail-safe-Verhalten"
fiir ein solches
Ein Beispiel
zurn Absturz
Stillstand gebracht.
des Prozesses
sondern
und sich selbst
der Steuersysteme
die auf Grund
des Ver-
die ihren Ein-
darstellen.
Signale ausfallen.
der Bremssysteme
dafiir gesorgt werden,
Grundlage
ist es jedoch,
Wahrscheinlichkeil
Prozesse,
der
Wahrscheinlichkeit
des Menschen
mit gro~er
fiir Zwecke
hat, die - unkontrolliert
ein Versagen
entspre-
ist nut einer der Griinde,
selbstt~tig in einen fiir den beteiligten Mensehen
stand fibergehen,
Man
Technik
die anfallen-
Ausgabe
Datenverarbeitungsanlagen
- eine potentielle Gef~hrdung
Eigensehaften
und durch
Die nicht vernachl~ssigbare
der Fehlfunktion
kontrollierenden
zu kontrollieren,
schnell zu verarbeiten
yon eleklronischen
hierffir ist der Flugverkehr,
den durch
gleichzeitig
sofort und feinffihlig zu reagieren,
satz bisher bet solehen Gberlassen
Datenquellen
und digitalen Daten
Steuersignale
Weniger
*)
yon Prozessen
zahlreiche
die fiir den Einsatz
sagens
MEHRRECHNERSYSTEMEN
WOBIG
Die sichere Steuerung
chender
MIT
2. DV-Programm
335 Wetter
ist das Problem
eintr~chtigen
bekannt,
kann: Die Gefahr
die Ergebnisse arbeitender
beider
Kan~le
Vergleicher
gleichartig
Konsequenzen
darf nicht flbersehen
verarbeiten, anfallenden cher
des Auftretens
das Problem Ergebnisse
durchzufiihren
noch
die Sicherheit
von Doppelfehlern,
d.h.
so daft auch
hat, dies Ergebnis
be-
Fehlern,
die
ein einwandfrei
als falsch zu erkennen
zu ziehen.
werden,
da~ das UnvermSgen,
nur verlagert, sicher
Verfahren
verf~ischen,
keine MSglichkeit
und die entsprechenden Schlie~lich
das bet diesern
indem
man
zu vergleichen.
als die sichere
nunmehr
Letzteres
Verarbeitung
die Daten gezwungen
sieher
zu
ist, die
ist in jedern Falle
einfa-
als realisierbar
voraus-
und wird
gesetzt. Die Kfirze de~ Zeit erlaubt Doppelfehlern folgend
und
mehrere
ihre Ergebnisse wollen
bier auf die Ursachen
und evil. Gegenma~nahmen
die primate
sch~ftigen,
es nicht,
zun~chst
n~her
wenig
ohne
Schwierigkeiten
ausgehen,
in einern sog.
arbeiten
verglichen dessen
"Voter"
vielrnehr
erscheinende
so parallel
miteinander
yon einern 3-Reehner-System
beiteten Steuersignale,
einzugehen;
problematisch
Verarbeitungseinheiten
und Auswirkungen
einer
yon
soll uns nach-
Aufgabe
be-
zu lassen,
daft
werden
Ergebnisse,
k6nnen.
Wir
also die erar-
2-von3-Auswahl
unterzogen
werden. Der
Einflu~
des zu steuernden
Prozesses
auf das Konzept
Urn die hierbei
evtl. auftretenden
Schwierigkeiten
es vorteilhaft,
vorn zu steuernden
Proze~
Die einfachste
aller denkbaren
dem
Proze8
zu verarbeiten.
bestirnrnter
welches
die Bremsst~be
leranzgrenzen systems
bestirnrnter
der thermonukleare
tungen
Itch u.U.
Proze~grS~en
Proze~
einer
recht folgenschwere
bereits
angedeutete
Ausfall
eines
Rechners
der
Betrieb
ist
die aus
Ja/Nein-Aussage
ein Dauersignal
festh~It.
oder
St6rungen
bzw.
des
Ausfall
die Brernsst~be Durch
Betriebshemmung
dieses
Betriebes
des Schutzfallen ein und
technischen Diese
Einrich-
wirtschaft-
ist der Grund
yon Drei-Rechner-Systernen, und
der To-
Fail-safe-Verhal-
verrnieden.
unterbrechungslos
bet in-
abzugeben,
~Jberschreitungen
- und der kostspieligen
Unterbrechung
Propagierung
in der Aufgabe,
sicheren
Position
zurn Stillstand.
des Menschen
zu bewerten,
eines Reaktorschutzsysterns, Proze~
des Steuersignales,
kommt
Inkaufnahrne
best~nde
einzigen,
verlaufendem
Abschalten
eine Gef~hrdung - unter
zu einer
in gehobener
und
auszugehen.
die Grundfunktion
Toleranzen
fiihren zum
ten wird
Daten
So isi z.B.
nerhalb
zu erkennen
Proze~steuerungen
aufgenornrnenen
des Rechnersystems
fiir die
da bet diesen sicher
auch
bet
rnit zwei
336
Rechnern Den
fortgesetzt werden
n~ichsth6heren
Grad
f~inger allein, sondern Ja/ Nein-Aussagen ernden
Schaltern,
len und Weichen. Voter yon einem keine besonderen der Praxis
kann.
an Komplexit~t eine grS~ere
gesteuert
bieten Prozesse,
Zahl yon Elementen
werden.
Beispiele
Ventilen oder - im Bereich Solange eigenen
jeder Empft[nger Rechnerausgang
Schwierigkeiten.
Das
tungssystems
werden
Hier mu~
sichergestellt
wird,
- Signa-
Vergleicher
ergeben
Bild ~[ndert sich jedoch,
bzw.
sich aueh hier
wenn
- wie es in
ht[ufig der Fall ist - die Empf~nger am
Ausgang
des Verarbei-
(Bild i).
seth, da~ die Reehner
tenbits irn richtigen Augenblick dies nicht, so komrnt weichungen
es zwar
beider Kan~le
Absehaltungen
M
m
m
arbeitenden
nicht unrnittelbar
Proze~typ,
Empftinger
- Telegramme
und damit
n[iher befassen,
werfen
der sich aus dem
nicht einzelne - angeboten
Da-
Geschieht durch
die Ab-
und unnStigen
die Wirtschaftlich-
Gleichlauf der
parallel
erforderlich. wir noch einen kurzen
eben geschilderten
Ja/Nein-Aussagen,
werden
etc. ). Ein Beispiel f~ir derartige
rung yon Bahnen
anbieten.
jedoeh zu unerw0.nschten
ist also unbedingt
Blick auf einen weiteren
die einzelnen
zu ether Geft[hrdung,
d.h. die Verfiigbarkeit
wir uns mit dieser Aufgabe
forrnationen
Vergleieher
sinken u. U. betr~[chtlich ab. Ann~hernder
Einheiten
da~ dem
dem
und in gleicher Reihenfolge
voneinander
des Prozesses;
keit des Systems
adressen
mit zu steu-
Ausgabe von Steuerbefehlen aus einem Mehrreehnersystem mit 2v3 - Auswahleinrichtung (Voter)
Bild i :
ergibt,
einfache digitale
der Eisenbahnsignaltechnik
angesteuert
~
Bevor
nicht ein Emp-
hierfiir sind Prozesse
(iber einen einzigen Vergleicher
versorgt
dureh
Gber einen eigenen
aus Griinden der Wirtsehaftlichkeit
zeitlich nacheinander
bet denen
dadurch
l~ngere
(digitalisierte Analogwerte,
Prozesse
rnittels Linienzugbeeinflussung.
sondern
In-
Unter-
ist die Oeschwindigkeitssteue-
Hier k6nnen
sich Problerne
selbst
337 dann ergeben,
wenn
jedem
Empf~inger
dieser aber die Telegramme Dauer
bitweise vergleicht.
eines Bits - gegeneinander
verschobene
ffihren sofort zur StSrungsmeldung Probleme
des Synchronlaufs
Wodurch
Irn wesentlichen
dutch
Vergleicher
Ausgaben
die unterschiedliche
aus den beiden Kan~len
eines Systems
Rechner
und darnit die unterschiedliche
der einzelnen
asyrnmetrische
ner (ether der Rechner
hat z.B.
zus~tzlich die Bedienung
ger~tes
o. ~. )
Vor allem
Verarbei-
Rechner,
eine h~ufig nicht zu vermeidende
zu fibernehmen
entschei-
entstehen?
zu unterscheiden:
Taktfrequenz
tungsgeschwindigkeit
das Verfahren
die
den Vergleicher.
Lauf der einzelnen
sind vier Ursachen
zu externen
wurde,
Zeitlich nur geringffigig - um
- offenbar die Brauchbarkeit
asynchroner
unterschiedliche
zugeordnet
der Rechner
kann nun ein solcher
dend beeinflussender-
ein einzelner
Programrnlaufzeiten
Belastung
einzelner
Reeh-
eines Datensicht-
infolge schwankender
Zugriffszeiten
Speichern, der ProzeS-Dateneingabe.
der zuletzt genannte
Grund
erscheint
wesentlich
und so]/darum
n~her
be-
trachtet werden. Hinsichilich
der Eingabeverfahren
lassen sich zwei grunds~tzlich
verschiedene
Sy-
sterne unterscheiden: die Abfragesysteme
und
die Veranlas sungs systeme. Kennzeichen Abfrage
eines Abfragesystems
ist die zentrale Initiative, d.h. der Zeitpunkt der
der - jederzeit ansprechbaren
eine vorgeschaltete
Hardware-Einheit
halten sich passiv;
sie rnelden weder
Werte
yon sich aus. Die Abfrage
~nderungen
rnuS darum
~'~hnlich wie bet der geschilderten sich auch fGr die Dateneingabe
- Datenquellen (Multiplexer)
Ausgabe
verschiedene
wird dureh bestirnmt.
den Rechner
noch Uberschreitungen
auf jeden Fall periodisch von Steuersignalen
oder
Die Datenque]/en
bestimrnter erfolgen.
an den Proze~
bieten
MSglichkeiten:
-
jeder Rechner
ist mit jeder Datenquelle
direkt verbunden;
-
jeder Reehner
ist rnit jeder Datenque!le
fiber einen Multiplexer
ver-
verbunden,
338 der es gestattet, die Rechner
die Datenquellen
sind gemeinsam
eines eigenen,
vom
Reehner
mit einem
festen Taktes
her einzeln zu adressiern;
Multiplexer
die Daten
verbunden,
der rnittels
zykliseh abfragt und den Rechnern
an-
bietet (Bild 2).
l-f,-I
I
l I I I I I i
Bild 2:
Eingabe yon Informationen in ein Mehrrechnersystem fiber gemeinsamen Multiplexer (M)
Die dritte Methode den Vorteil,
bietet als einzige hinsichtlieh des Synchronlaufs
da~ die Daten
chert Reihenfolge
automatisch
iibermittelt werden,
im Ansehlu~
an eine Dateneingabe
ben kSnnen.
Das
bedaten
Verfahren
len unn6tig oft abgefragt Bezug
dadureh
des Multiplexers
Ergebnisse
gekennzeichnet,
keine Differenzen
der Einga-
zu sein, die wiederum
~nderungen
erge-
so
im Proze~geschehen
da~ eine ganze Reihe von Datenquel-
werden.
geschilderten
Das
Verfahren
Abfragesystemen
arbeitet also in
sind Veranlassungssysterne
da~ die Initiative zur Dateneingabe
(Umschalten
der sofort
relativ unwirtschaftlich.
ist, d.h. die Datenquellen
rung eines Zustandes
Vergleich
mit der Bearbeitung
gebunden
hat zur Folge,
der Rechner
zu den eben
te fibergegangen
Das
und ausgewertet
auf die Auslastung
Im Gegensatz
erarbeiteten
da~ auch sehr sehnell verlaufende
noch sicher erfa~t werden.
gleichzeitig und in der glei-
so dab sich bet einem
hat jedoch den Nachteil,
an die Taktfrequenz
grof~ sein mu~,
allen Rechnern
der Rechner
melden
eines Kontaktes,
auf die Proze~elemen-
sich nut dann,
wenn
LIbersehreiten
die ~nde-
eines Grenzwer-
tes) dies erfordert. Als Vorteil dieses Verfahrens eingabe
und -verarbeitung
ist zu werten,
in Anspruch
da~ die Rechner
genornmen
werden,
nur dann mit Daten-
wenn
der Proze~
dies
wirklich erfordert. Als Naehteil ist einmal notwendigen
Kriterien
der hShere
Aufwand
fiir die Veranlassung
in der Proze~ebene zur Daten{ibernahme
hinzustellen,
da die
durch die Reehner
339
bereits dort abgeleitet bzw. lelbetrieb yon Rechnern tenquellen
Uhren
einzelnen bzw.
yon Ferniibertragungen,
sogar vertauscht
zu den Ausgabezeitpunkten,
gabe liegen, Ursache
ist. Da der Voter
Rechnern
fibereinstirnrnen,
Aufgabe
des Voters
zeigen und yon der weiteren geschilderten
Verfahren
keit des Systems Folgerungen
wird durch
Aus-
die Verfahren
zyklische
henfolge der Verarbeitung
Abfragesysternen Hat man Daten
durch
Rechner
der Sicherheit
ergeben
abgeschaltet
eintreten. anzu-
und die Verfiigbar-
Eingabernethoden werden,
d.h.
Teil naeh dern Ver-
hat: ist die Rei-
und darnit die Art des Eingabever-
F[llen ist ein Gleichlauf der Rechner
Abfrage
zwangslfiufig
(selbstsynehronisierende
zu tun, bet denen
Initiative eingegeben Weise
sich bisher hinsichtlich der ver-
ergibt sich wiederurn
rnit Systernen
wird,
wenigstens
oder besser
Systerne). ein Teil der
rnu~ der erforderliche
Koordination
parallel arbeitender
denkbar:
Einrnal besteht die MSglichkeit
der direkten "Abspraehe"
un-
bet reinen
hergestellt werden.
Synchronisation
sind folgende Verfahren
2 yon 3
zu erkennen,
und einern Bit Steuerinforrnation
rnit zyklischer
periphere
Defekt die
Darnit wfirde bet dern
ein anderer
was
in den Rechnern
Gleichlauf
Gleiehlauf auf andere Ffir eine derartige
die in wenigstens
h[ufig kornbiniert
Abfrage,
In allen anderen
es dagegen
nicht alle
zur Datenein-
kein technischer
Rechner
werden
ilbernornrnen.
und Eingabeverfahren
Dieser
in den
haben
asynchron
auszuschlie~en.
Sicht-
Einsatz
Bet nur einern Datenernpf[nger
erl[~lich.
weitergibt,
noeh einrnal zusarnrnen,
fahrens unkritisch.
(Beispieh
verschoben
Dadurch
nur selten eine der hier geschilderten
in die Rechner
wit zun[chst
schiedenen
zueinander
so
werden.
vielrnehr werden
anlassungprinzip
obwohl
relativ h~ufig ein Rechner
wird man
ein Teil der Daten
Fassen
Verarbeitung
beeintr[chtigt
allein vorfinden,
kSnnen.
einen abweiehenden
ffir den praktischen
In der Praxis
werden
kann keine Beeintr[chtigung
ist es jedoch,
Da-
angeschlossen,
da~ die Verarbeitungsschritte
vorliegen,
nur Ergebnisse
rnehrere
Datenaustauschsteuerungen,
die selber wieder
die gleichen Ergebnisse
fiir den Paral-
Sind wiederurn
u. U. zeitlich irnrner rnehr gegeneinander
in der Reihenfolge
3 Rechner
anderes:
Wesentlich
zeitlich unkorreliert
etc. ). Dies hat zur Folge,
Rechnern
miissen.
Initiative gleichzeitig an die Reehner
Anforderungen
gleichzeitJ(ger Ansehlu~ ger[ten,
werden
ist aber noeh etwas
rnit peripherer
kornrnen die einzelnen
erarbeitet
der Rechner
340 untereinander,
die hierffir fiber Koppelelernente
ringfSrrnig miteinander neu ab s welche ausgegeben mu~
verbunden
Eingangsdaten
sind. Die Reehner
als n~chste
k6nnen.
Dureh
sichergestellt
werden,
daft sich alle Rechner
dann,
wenn
Nach
Schrittes
aufwandes
Absch~tzungen
bzw.
ein ausgeklfigeltes
sich jedesrnal
welche
Ergebnisse
Quittungsverfahren
hinsichtlich des n~chsten
stets einig sind, vet allem und gerade
ether der Rechner
unseren
stirnmen
bearbeitet
werden
zu unternehrnenden
(Datenaustausehsteuerungen)
auch
gest6rt ist und gar nicht oder falsch reagiert. bleibt dieses Verfahren
und darnit verbundener
hoher
trotz hohen Software-
zeitlicher Belastung
der Rechner
unbefriedigend. Das
Koordinator-Elernent
Eine andere
MSglichkeit,
besteht darin, Darunter
die Programme
diese Aufgabe
einem
in den Rechnern
unabh~ngigen
soll eine spezielle Hardware-Einheit,
den werden,
der sternfSrmig
aufeinander
HSchiedsrichter"
abzustimrnen,
zu fibertragen.
der Systern-Koordinator,
rnit allen Rechnern
verbunden
verstan-
ist (Bild 3).
K
Bild 3:
Dabei
Mehrrechnersystern
ist dafiir zu sorgen,
ten Ansto~es Elements vor,
mit Koordinator
dab keiner der Rechner
ein Prograrnm
zu besitzen.
dinator fibergeben. der Koordinator,
starter,
Erst nach Vorliegen
Fall, wird den Rechnern dieses!-
Programrns
die durch
asynchron
Rechner
Startanforderungswort
ob alle Rechner in Form
erlaubt.
infolge eines asynchronen
der SAW
(SAW)
Verfahren ausgel6st
des Koordinator-
notiert und dies dem
auch der ilbrigen Rechner
einer HStartfreigaber'
Daten
~u~e-
eine Programm-Startanforderung
das gleiche Prograrnrn
Diesem
eintreffende
(V)
ohne hierffir die Zustirnrnung
Liegt also in einem
so wird sie in einem
(K) und Voter
starten wol!en. der Start dieses
sind alle Programme werden
Koorpriift
Ist dies der -und nur unterworfen,
und zu Ergebnissen
filhren
341
oder beitragen, me
die anschlie~end
ausgegeben
dfirfen nach ihrer Startfreigabe
Verarbeitungsroutinen
durch
unterbrochen
ten Zeit nach Eintreffen
des ersten SAW
beirn Koordinator
festgestellt,
Rechner
wird abgeschaltet fortgesetzt.
Durch
dieses Verfahren in jedem
ten, zurn anderen
nach dem
kann.
Wenn
Ergebnisse
in dem
n~mlich
~bernimmt
auf, die noch
es gelingt, einen Defekt
d.h. die sogenannte
des betr. Rechners
Fehler-
der Reehner
und damit
Abweichungen
auftrat,
wird durch
kSnnen veranla~t
Programm
der Be-
werden. wesentliche
indern es ein "Aus-
unnStige Abschaltungen
und damit
und zu
und beur-
dann Wiederholen
tier Verffigbarkeit,
der Zeitpunkt
und damit
gestarteten
ebenfalls vergleichen
friihzeitig erkennt
die knrzen
zu vergleichen
synchronisiert
vermeidet.
und die defekten Rechner
Dadureh, aus dem
als auch der Programrnabschnitt,
festhalten und so die Fehlersuche
die Reparaturzeit
~bernornmen
ist, die Startanforderungen
bet Mehrrechner-Systemen
in~. Hinblick auf eine ErhShung
liehkeit yon Doppelfehlern
in der Lage
Abweiehungen
das Koordinator-Element
der Fehler
bet, die yore Koordinator
oder Zwischenergebnisse
zieht, lassen sich sowohl
stfitzen, was
ver-
Situation f~ihren. Eine derar-
je schneller
auch die yon einem
oder Abschalten
fluSt. Schlie~lich
star-
von Doppelfehlern
zeitlich zu Gberwachen,
Bet eventuellen
da~ es au~erdem Verkehr
dies Element
liegt es nahe,
einanderlaufen"
da~
mit den intal~en zusamrnen
die beiden defekten Einheiten
Aufgabe
entgegenzunehmen,
teilen zu lassen.
Funktionen
wird dafilr gesorgt,
so kurz wie rnSglich zu halten.
werden
Damit
ohne Unterbre-
ebenfalls ein Fehler
Einheit stillzulegen,
tr~gt aueh noeh eine andere
arbeitung
Rechner
unwahrscheinlicher,
Hierzu
erarbeiteten
die weiterhin
der anderen
und die betreffende
offenbarungszeit
Rechnern
Rechner
im gleichen Augenblick
und so zu einer gef~hrlichen
tige Situation wird umso
beantworten,
zeigt. Dieser
sehr schnell erkannt und abgeschaltet.
Prinzip der 2 v 3-Auswahl
intakte "~berstimmen"
dreier Rechner
Verhalten
die Wahrscheinlichkeit
in einem
rnil dem
wird mittels 2 v 3-Entscheidung
Programme
Rechner
teilnehmen,
Tritt n~mlich
zu erkennen
gemeldet,
weil defekte Einheiten,
an der Proze~fiihrung
kSnnen
gestSrte
einer bestimm-
nicht auch die iibrigen Rechner
ein abweichendes
Fall die gleichen
Die Program-
keine anderen
sich innerhalb
wird zweierlei erreicht: Einmal
werden
Dies ist wichtig,
grS~ern.
Haben
werden. dutch
und der Betrieb mit den verbleibenden
chung
die Rechner
den Koordinator
werden.
gleichen Startwunsch welcher
und verglichen
entscheidend
ebenfalls die Verfiigbarkeit Fehleroffenbarungszeiten
yon Gef~hrdungen
reduziert.
unter-
positiv beein-
die Wahrschein-
342
Trotzdem
braueht das Koordinator-Elemenl
sein, d.h. fail-safe-Eigenschaften dungen
selbst nieht signalteehniseh
zu besitzen.
falseh sein sollte, wird alas endgGltige
Kornmandos Systems
imrner
noch yon dem
sieheren
Selbst wenn
aufgebaut
wurde,
trotzdem hat andere
Vergleicher
dern gesehilderten
Konzepi
h~ngen,
Verffigbarkeit
ist dessen
Systems.
kreissystern
umschalten
Das Wiedereinfiigen
Reehner
Auf eine nicht zu untersch~tzende
auftretende
und damit
Schwierigkeit
matisch,
als "Aktualisieren" wenn
rnehr abfragbar
nicht dern Proze2
sind), sondern
es dann fiberne-hrnen,
unter Fortfiihrung
mit den benStigten
DatenblScke
von rnehreren
da~ sich w~hrend haben kSnnen Rechner
der Dauer
zu ziehen,
wieder Vorgang
selbst entnehmen
angewiesen
des laufenden
erh~It,
handeln!
der Ubertragung
kannt werden
u. U. mehrfach
am
Proze~
be-
Rechner
Betriebes
den reparierten
Hierbei
Erschwerend
wenigstens
ein Zustand,
schwer
kommt
bereits wieder
wiederholt
werden
rnu2,
Vergleich
hinzu, ge~ndert bis alle
tier Daten
I%echner keine
zwei der Rechner
der bekanntlich
beeintr~chtigt.
rnGssen
kann es sich urn
seth, da[~ der zu aktualisierende
bes~2en,
kann und die Sieherheit
wird dann proble-
kann (weil sie dort nieht
einige Daten
da sonst anschlief~end
gleichen falschen Informationen
eingef~gt werden.
ist. Diese
zu versorgen.
tausend WSrtern
sichergestellt
auch schnellst-
teilweise auf die in den intakt gebliebe-
Daten
Informationen
und das Verfahren
fehlerhaften Werte
we-
defekte Rech-
sie mfissen
auf dern gleichen Stand sind. Sehlie21ich rnuf~ durch
vor der ]~bertragung
irn Schalt-
eines solchen
getan,
die ffir die Teilnahme
wenigstens
gespeicherten
bet der Realisierung
bezeichnete
Rechner
nen Nachbarrechnern
Rechner
Fehler
auf eine bereitstehende
in das System
eines Rechners
der zuzuschaltende
nStigten Informationen
ab-
des ganzen
die Reparaturzeit
Es ist nicht damit
und aus dern Verkehr
rnSglich repariert und unlerbreehungslos Dieser
nach
in das System
set noch hingewiesen:
her schnell zu erkennen
der Rechner
zu kSnnen.
ausgefallener
Mehrrechnersystems
des
realisierten
ffir die Verffigbarkeit
sentlich zu verkfirzen oder aber sogar unterbreehungslos Reserveeinheit
Ausgang
des Koordinator-Elernents
bietet dabei den Vorteil, anzuzeigen
am
Hause
Da n~rnlich die Funktionen
mitentscheidend
sofort und automatisch
Voter
Fail-safe-Technik-URTL-
allein yon den Reaktionen
Die URTL-Technik
bzw.
des in unserem
in einer integrierten
Grfinde.
eine seiner Entschei-
Urteil fiber die Zul~issigkeit eines
gef~llt. Daft das Koordinator-Elernent
Mehrrechnersysterns
sicher zu
die
nicht er-
343 Zusamrnenfassung Je nach Art des zu steuernden arbeitenden henfolge
Rechnern
ablaufenden
zu koordinieren.
nung und -lokalisierung
ist es erforderlich,
Programme
Darfiber
hinsichtlich
die in parallel
Startzeitpunkl
hinaus ist eine mSglichst
nicht nut aus Gr0nden
dern auch zur Verringerung gerung
Prozesses
und Rei-
schnelle Fehlererken-
der Verffigbarkeit
der Doppelfehlerwahrscheinliehkeit
erwfinscht, und damit
sonzur Stei-
der Sicherheit.
Beide Aufgaben der Weise
durch
- Koordinierung ein spezielles
mit den zu 0berwachenden erweitertes angestrebten
Koordinator-Element
Rechnern
3-Rechner-System Einsatz
und Fehlererkennung
verbunden
yon Bahnen
in zufriedenstellen-
erfiillt, welches
ist. Ein
wird auch Aufgaben
fllr die Steuerung
- werden
um
gerecht,
sternfSrmig
ein derartiges
Element
die fiber den zun~chst
weir hinausgehen.
PARALLELKONTROLLE SYNTAKTISCH REPR~SENTIERTER ZUSTANDSFOLGEN J.
1)
BANCSICH
G, VINEK
2)
1) Einleitun~
Der vollst~ndige steuerndes
Ersatz des Menschen
Element
fortsohreitender
im Rahmen
Entwicklung
nioht immer m~glich. Systemen
sinnvoll,
Prozesses
Vielmehr erscheint
Mensch
zwisehen
und Maschine
deren
ErfOllung
entsprechen,
des
vorerst mittels
not-
Grundregeln
Aktionen
der Beziehung
"Herrensystem",
ent-
geprOft warden,
Ablauf des Prozesses
vom Reehner die gew8nschten
Menschen
sines
Oabei kann eine
mit Regeln
die den vorgegebenen
um ein sogenanntes
Entscheidungen
komplexen
und Oberwachung
aufzuteilen:
Entscheidungen
Es handelt sioh also dabei bezOglich und Maschine
ist auch bei
und Rechner in der Weise erfolgen,
for den fehlerfreien
werden
es bei solchen
auf Obereinstimmung
Bei Ablauffolgen,
und
Abl~ufen
ProzeBkontrollsysteme
der Steuerung
Mensch
dab vom Bediener vorgsgebene sprechender Programme wendig ist.
entsprechender
die Aufgabe
zwisohen
Arbeitsteilung
als entscheidendes
von komplizierten
versnla6t.
zwischen
Mensch
bei dam der Rechner
formal kontrolliert.
2) Problemstellun~ Zu Oberwachen
sind somit Abl~ufe,
airier Reihe yon Einzelschritten bestimmten
Grundregeln
folgenden
geschilderten
sein,
bei denen die zeitliche
nicht vollkommen
unterworfen
ist /I/.
Oberwachungsalgorithmen
die nicht dutch einen Setz kontinuierlich
sondern
dutch die zeitliche
beschreiben sowohl
sind.
Im allgemeinen
dutch Aktionen
aus dam ProzeBgeschehen
OberprOft.
mitgeteilt
warden,
Ober die Abfolge
I) Extraordinariat 2] Lehrstuhl
Im zweiten
f.med.
Gr6Ben,
diskreter ZustBnde
zu
Im ersten Fall trifft
der
der Einzelschritte, mit den vorgegebenen
Fall soll die Oberwachungsfunktion
Computerwissenschaften
for Operations
also Vorg~nge
ver~nderlicher
als auch dutch ROckmeldungen
der Rechner deren Obereinstimmung
Grundregeln
sollen
sondern
der im
kann dam Rechner der Zustandswechsel
des Bedieners,
Bediener die Entseheidung w~hrend
Aufeinanderfolge
beliebig,
Gegenstand
Abfolge
Research,
Hochschule
Universit~t Linz
Wien
345
des Rechners
dazu eingesetzt
warden,
sierung
des ProzeBgeschehens
wirken.
Im Falle eines VerstoBes
mit den Aktionsn
hat.
so Obernimmt
der darau~hin
dieser Zusammenh~nge
|®~®®
PrOfung
an den ProzeB. zeigt Abb.
zur
positiv aus,
geeignetsr ProzeBperipherie
des Bedienerbefehles
zu be-
Grundregeln
die MBglichkeit
die entsprechende
der Rechner mittels
Weiterleitung Oarstellung
F~llt hingegen
Synchroni-
des Bedieners
gegen die vongegebenen
wird dies dem Bediener angezeigt, Korrektur
um eine zeitliche
die
Eine schematische
I:
I~
.} l === gediener
~:~',,,,fS~euer- ~ /oe4"e./de
Prozegwarte
ProzeBrechner I
Abb,
FUr die Entwicklung Aufgaben
erfOllen,
geeigneter
dargestellt,
NachtsiI
Flexibilit~t
implizit
Zustandsfolgen
der zu Grunde gelegten
Regeln.
liegt sowohl
ProzeB-
Abl~ufen.
zwischen 0er
in der geringen der zu Grunde
UnObersichtlichkeit Beides zusammen
des Programmes
GOnstiger
ergibt
gegenOber ~nderungen
erweist sich daher sine
Programmierung
0abel wird explizit
unterschieden
das ProzeBgeschehen
bestimmendsn
der deren Einhaltung heitlichen
diskriminieren.
gegenOber Ab~nderung
bei komplexeren
0bar
dutch eine Folge yon
die an jedem Punkt des Ablaufes
eine geringe Wartungsfreundlichkeit
b) Problem-freie
die gesamte Information
als auch in airier zunehmenden
des Programmaufbaues
Wage a n :
0abei sind die den korrekten
dieser Methode
des Programmes
Regeln,
enth~lt
Grundregeln
und nicht erlaubten
wesentliche gelsgten
selbst
Zustandsfolgen.
ablauf beschreibenden erlaubten
die die geschildert~n
Programmierung:
0as 0berwachungsprogramm
Entscheidungen
Programme,
bieten sich zwei verschiedene
a) Problem-bezogene
alia erlaubten
Proze8
Notation
Probl~munabh~ngigkeit
0berwacht.
zwischen
der 0arstellung
Grundregeln
Unter der Voraussetzung
der Grundregeln
der for
und dem Algorithmus, einer ein-
kann damit eine vollkommenB
des 0berwachungsalgorithmus
erzielt werden,
der
346
somit auch gegen~ber Modifikationen invariant mBglich,
bleibt. simultan
Aus dam selben
entsprechende
dieser Art mit dam selben
zu kontrollieren~
kann sich aber bei der gleichzsitigen Ober einer Problem-bezogenen rithmus
in dam dieser jeweils
Tabellen mit den jeweiligen
Anzahl solcher Zustandsfolgen
Regeln
zugreift
Oberwachung
einer gr888ren
sin geringerer Speicherbedarf Programmierung
euf
Oadurch gegen-
des Oberwachungsalgo-
ergeben.
3] Syntaktische
Darstellung
Die spezielle Struktur stimmten warden,
Regeln
von Zustandsfol~eq: '
der betrachteten
unter~orfene
legt den Gedanken
stellen.
O.h., bestimmte
Abfolge
nabs,
Vorg~nge~
diese in syntaktischer
Folgsn von Zust~ndsn~ Geschehens
Produktionsregeln
repr~sentiert,
einer Syntax
und des Prozesses
bilden.
zur Darstellung
in Form yon mehreren fiche Symbol J
Alternativen
erweitete
Forderungen.
B.N.F.
Dabei bedeutet
heir gesetzte I n t e g r a l z e i e h e n maximal m-mal wiederholt
mu6 es die
erlauben,
bestimmte
oder unbeschr~nkt
sein,
sine Produktion
Eine um des metasprach-
der Syntax
leistet
die ge-
des vor eine syntaktisohe
, de8 diese mindestens
warden
FOr n = o ist die nachfolgende bei Fortfall
anzugeben.
des Bedieners
zu k~nnen,
beschr~nkt
Notation
als
Darstellungsweise
Metasprache
Ebenso mu8 es m~glich
werden
deren Terminalsymbole
yon Seiten
einer solchen
als optional,
anzugeben.
die einem korrekten
berOcksichtigen
der Syntax v e ~ e n d e t e
Tails einer Produktion wiederholbar
Umbei
der Abfolge
aufgefaBt
Form darzu-
entsprechen~
die Menge s~mtlicher EingabemSglichkeiten alle M6glichkeiten
die als sine be-
yon Einzelersignissen
Ablauf des zu kontrollierenden
nannten
Grundregeln
Grund ist es aber somit auch
mehrere Prozesse
Oberwachungsalgorithmus
der vorgegebenen
n-mal
Einund
darf. syntaktisehe
der oberen Schranke
Einheit
m unbeschr~nkta
optional,
w~hrend
Wiederholbarkeit
angezeigt wird. Sofern
nun die zu Oberwachenden
syntaktisohen Konzeption Analyse
Form dargsstellt
Vorg~ng8 warden
des Ober~achungsalgorithmus
an, wie sis auch in Compilern
also die einzelnen, Eingabezeichen vorgegebenen ehemBglichst
Zust~nde
interpretiert,
f~r Zeichen
erkennt warden.
der syntaktischen
angewendet warden
Syntax formal gsprOft warden.
diese PrOfung Zeiohen
bieten sich for die
die Techniken
aufeinandsrfolgenden
eines Compilers
in der eben beschriebenenj
kBnnen,
erfolgt,
/2/.
Es warden
als Sequenz
von
von dam sie an Hand der
Wssantlich
dabei
sodaB fehlerhafte
ist,
de8
Abl~ufe
347
Oie Oberwachung von Prozessen, Zust~nde
ablauTen,
Kontrollen z.B.
sein, ProzsBdaten,
des Systems
Sequenz auszuwerten.
Oas Ergebnis
durch~Ohren zu kBnnen, geordnete es dann,
Sequenzen
nach Vorliegsn einer bestimmten
dieser Auswertung
des Prozesses
Bediener vor' Fehlhandlungen
schOtzen.
entscheidsn
ist es er~orderlich, Routinen
Lind Aktionen
tischer Routinen
durchzu~Ohren.
zu bestimmten
folgt am gOnstigsten
der Syntax eine semantische Routine sich TOr die Konzeption mQB zusammengehSrige
beim Vorliegen
von
eindeutig zu-
Oeren Au~gabe ist
PrO~ungen
hinausgehenden
von Einzelschritten
sr-
dab ~Or jade einzelne Produktion vorgesehen wird.
der Syntax die Forderung,
Zustands~olgen
dieser Art
Oie Zuordnung solcher seman-
Sequenzen
in der Weiss,
und somit den
automatisch
zu exekutieren.
alle Ober die rein syntaktischen
Kontrollen
sollte dann Ober
Um Kontrollen
yon Einzelschritten
"semantische"
So k a n n e s
die bei einer Folge van
erfaBt wurden,
welters mBgliche Abl~ufe
bestimmten
aber zumeist neben rein syntaktischen
noch zus~tzliche OberwachungsmBglichkeiten.
srTorderlich
Zust~nden
erTordert
die in Form von Folgen diskretsr
Oadurch ergibt
jeweils sinnge-
in den Produktionen wiederzu-
geben. Ein Oberwachungsalgorithmus, tischen PrO~ungen Obernimmt,
der neben der Ourch~Ohrung aller syntak-
die unmittelbare Aus~Ohrung semantischer Routinen
leistet somit Shnliches wie ein Interpreter,
~Or syntaktisch Oieses Konzept
kann noch inso~erne e#~eitert werden,
mshrsre Prozesse vom selben Oberwachungsalgorithmus warden
kBnnen.
briner.
als simultan kontrolliert
Jeder einzelne Proze8 wird dann dutch sine spezi~ische
Syntax mit angeheTteter Semantik bsschrieben, wachungsalgorithmus eignisses
der jedes
richtig be~undene Statement zur Exekution
beim Eintritt eines entsprechenden
zugegri~Ten wird.
Parallelkontrolle
aug die vom OberProzeBer-
In diesem Sinne kann somit von einer
syntaktisch
reprQsentierter Zustands~olgen
ge-
sprochen werden. Abb. 2 zeigt im Grobflu5diagramm semantischen PrOfungen,
den Ablaut von syntaktischen
und
3~8
E~GCIIS /
I ~
Ar,F~EIGE.
I
R.OUTINEN
EXiT
P
...I....EXIT ..'~
"NIEIN . ~J/NEIN
...
L
J
I i:~tl 9OSITI VIE. !TTIER,UI~6
...........
3A>
Abb.
2
4),,H,,,a,rdwareko,0,,,zeption Die in den vorigen Abschnitten stellung
erfordert
wesentlichen
haben
beschriebene,
auch spezielle diese zwei
a) Identifikation
spezielle
zentrale
der einzelnen
Aufgaben
~orderlich, Zeichen
Identif±kation
der einzelnen
um die Zustandsfolge
kation dutch Eingaben setzt wurde,
des Bedieners
selbst.
zwischen
Bediener
ProzeBschr±tte
zur syntaktischen
Ausgel6st wird die Obertragung
Prozeegeschehen
zu 16sen:
ist er-
in Form einer Reihe yon einzelnen
an den Oberwachungsalgerithmus
weiterzugeben.
Im
ProzeBschritte
b) Interaktive Kommunikationsm6gliehkeiten und Rechner Eine eindeutige
Problem-
Hardware-Einrichtungen.
Analyse
einer Schrittidentifi-
oder dutch ROckmeldungen
De von dem zu 8berwachenden
dab es nut sine beschr~nkte
Anzahl
eus dem
System vorausge-
verschiedener Schritte
~49
durchlaufen
kann,
kBnnen diese z.B. in Form eines Bin~rcodes
deutig dargesLell~
ein-
und in disse# Form vom Rechner als Zeichen
inter-
pretierL werden. Eine interaktive Kommunikationsm~glichkeit Rechner ist auf Grund der vorgegebenen
zwischen Bediener und
Arbeits~eilung
und Masohine bei der Steuerung des ProzeBgeschehens der Eingabeseite mu8 es for den Bediener mBglich for die e±nzelnen Schritte
des Proze6ablaufes
zwischen
Nensch
unerl~Blich.
Auf
sein, Steuerbe~ehle
an den Rechner abzu-
geben. Umgekehrt mu8 es for den Rechner m~glich
sein,
die erhalteneo
Befehle positiv oder negativ zu qui~tiBren. Ebenso mu8 der Bediener jederzeit Ober den M o m e n t z u s ~ n d zesses
informiert sein. Alle genannten
Konzept einer ProzeBleitwar~e, sowie optischen
Hard-
Laborbetrieb
ger~tetechnischen
teristische
Abl~ufe
nahezu Oberall durch charak-
~Or die Gewinnung
auch eine aktive Oberwachung der Arbeitsabl~ufe
gekennzeiohnet,
richtiger Resultate
ist. Oer Einsatz eines ProzeBrechners
nannten Anforderungen
di~erieren
untereinander ziBmlich stark.
nicht nur auf eine passive Obernahme
von Me6daten
der Arbeitsl~ufe
sollte sich daher bBschr~nken,
ermBglichen.
sondern
Oie ge-
fOhren somit auf die s y n t a k t i s c h 8 0 a r s t e l l u n g
bei den einzelnen MeBpl~tzen~
universellen Oberwachungsalgorithmus kBnnen.
Sowohl auf Grund
von einzelnen Arbeitsschritten
deren strikt8 Einhaltung wesentlich
Oabei sollen
15 Arbeitspl~tze
der 8inzelnen Arbeitspl~tze
aber ist die Arbeltsweise Abfolgen
insgesamt
in
als auch wegen der unterschiedlichen
Ausstattung
die dabei zu OberwachBnden Andererseits
entwickelt.
Labors Oberwacht werden.
der verschisdenen Au~gaben
eines Laborbetriebes.
und Ergebnisberechnung
mittels eines zentralen ProzeBrechners in zwei verschiedenen
ist.
und Softwarekonzept wurds zur
der MeBwerterfassung
8inem klinisch-chemischen
Funktionstasten,
ausgerOstet
im Rahmen der Automatisation
Das im vorigen beschrieben8n Automationsation
Anzeigen
des Pro-
fOhren auf das
die mit beleuch@baren
und akkus@ischen
5) Anwendungsbeispiel
Fordsrungen
FOr die erforderliche
Rechner wurde dabei ein spezielles aus die Ab~olge d~r einzelnen
simultan
Kommunikation
die mittels
8ines
kontrolliert werden
zwischen Bediener und
Laborterminal
Arbeitsschrit@e
8ntwickelt~
yon dem
in den ProzeBrechner
35O
eingegeben werden kann. Vom Rechner erkannte Fehlersituationen werden dort a n g e z e i g t .
Anhand einBs FotomBterarbeitsplatzes,
sin im
klinisch chemischen Betrieb sehr h~ufig angewendetes Analysenger~t, soll abschlieBend die geschilderte Methodik konkret erl~utert werden. Ein Fotometer ist sin Analysenger~t zur quantitativen Bestimmung der Konzentration bestimmter LBsungen, etwa des Zuckergehaltes Dabei bsdient man sich des Lambert-Beer'schen
im Blur.
Gesetzes, wonach die
Durchl~ssigkeit einer L~sung for sine bestimmte Wellenl~nge u.a. proportional zur Konzentration des gel~sten Stoffes ist /3/. Oer Arbeitsablauf zerT~llt dah~r nach der Auswahl eines bestimmten Analyseverfahrens
in eine Eichphase und eine MeBphase. W~hrend der
Eichung erfolgt die Eingabe mehrerer Eichpunkte,
die zur Festlegung
einer Eichgeraden dienen. Oie einzelnen Eichpunkte werden dutch Messung bei vollkommen abgedunkeltem Strahlengang
(Ounkelwert)~ sines
Lserwertes sowie verschiedener Konzentrationen bekannter GrBBe ermittelt. Die MeBphase selbst wiederum besteht aus der Eingabe einer Identi~ikation zum Zwecke der Zuordnung des Ergebnisses zu Stammdaten des Patienten, Verd~nnungsfaktors
einer optionalen Eingabe eines zus~tzlichen
sowie der Obernahme des MeBwertes.
ist ein for einen Fotometerarbeitsplatz mit £olgenden Funktionstasten
Dementsprechend
vorgesehener Laborterminal
ausgerOstet: Funktionen
Tastenkurzbezeichnung IVF
Auswahl sines bestimmtsn AnalysBverfahrens
NULL
Eingabe des Lee rwertes
DUNK
Eingabe des Ounkelwsrtss
ST
Eingabe eines Standards
NWO
Obernahme eines MeBsignals
.0123456789
Numerische Tastatur
CL
LSschzeichen for numerisohe Eingab8
Unter Ve~sndung
derselben Kurzbezeichnungen for
Tasten
sin Ausschnitt
l~Bt
sich
Weise s y n t a k t i s c h
die elnzelnen
des A r b e i t s a b l a u f e s
in folgender
beschreiben:
~Arbeiten~ :' =~Verfahrensauswahl~ ~ Ei ch en~J~<Mes s e n k ~Verfahrensauswahl~ : :=#IVF <Eichen~:- ~ ~ Eichpunkt> <Eichpunkt>.' :=~Leerwert>j ~Dun kelwert> l~St an dard~
::=S NULL "< MeBwertObernahme> ~MeBwertObernahme~: : = . MWO
351
< S t a n d a r d > : : = f S T
Eingabe~<MeBwertObernahme>
xNumerzsche E i n g a b e > : = = ~ Z a h l >
CL
Zahl
< Zahl>::= < g a n z e r Te)l>~< Bruchteif> < g a n z e r Teil~::=~ ::= 0/I/2/3/4/5/6/7/8/9 <MeBwert Obern ahme~ ~Identi£izieren~ : := ,~Paramet
ereingabe~
. ....
: : = ....
Au{ Grund der somit festgelegten Syntax {Or den Arbeitsablau~ an einem FotometermeBplatz ergibt sich z.B., dab naeh Auswahl eines bestimmten Ver{ahrens
(Bet~tigung der Taste IVF) nut sine der
Eingaben IVF, NULL, DUNK odor ST syntaktisch richtig anerkannt wird, w~hrend numerische Tastatureingaben odor MWO zurOckgewiesen wOrden.
Umgekehrt sind nach Bet~tigung der Taste ST nut numerische
Eingaben syntaktisch erlaubt.
Die Rolle der im vorigen Abschnitt
genannten "semantischen" Routinen kann an Hand des Beispiels sehr gut illustriert warden. So ist es z.B. AuTgabe der der Produktionsregal
Eichen
zugeordneten Routine,
aus den bei der Eingabe der
einzelnen Eichpunkte vom ProzeBrechner er{aBten MeBwerten die Parameter der Eichgeraden abzuleiten.
Aufgabe einer der Produktionsregel
Eiehpunkt zugeordneten semantischen Routine kBnnte es so±n, einen zus~tzlich bestimmten Eichpunkt auf Vertr~glichkeit mit einer bereit ermittelten Eichgeraden zu OberprO~en und ihn ~allweise zu deren Verbesserung heranziehen.
Ebenso mOssen auch allen anderen Produk-
tionsregeln entsprechende semantische Routinen zugeordnet sein, die eine korrekte Weiterverarbeitung leisten,
des gewonnenen Datenmaterials
und bei Nichter{Ollung notwendiger Bedingungen ~Or die
sinnvolle Aus{Ohrung weiterer Arbeitsschritte diese verriegeln. 6)
Zusamms,n,,,£,assun ~
Vorgestellt wurde sin Ver{ahran zur Darstellung yon diskreten Zustands{olgen eines Systems in syntaktischer Form. Die gew~hlte Darstellungsweise erlaubt den Einsatz sines vollkommen problem{rei gehaltenen Oberwachungsalgorithmus, der unter Einsatz der Methoden der syntaktischen Analyse die AbTolge der Einzelschritte an Hand eines Satzes yon Produktionsregeln beschreiben.
OberprO{t,
die den Arbeitsablau{
Durch eindeutige Zuordnung semantischer Routinen zu den
352
einzelnen Produktionen
kann die Aus{~hrung bestimmter Verarbeitungs-
vorg~nge gesteuerfi werden.
Literaturverzeichnis /1/
Anke - Kalfienecker - Volker: Proze6rechner, WirkungsweCse und Einsatz R. Oldenburg MOnchen 1970 2. Aufl.
/2/
D. Gries: Compiler Construction ~or Digital Computers John Wiley & Sons 1971
/3/
K. Richterlich: Klinische Chemie Birkh~userverlag
Basel 1971
3, A u f l ,
ECHTZBIT-NACHBILDUNG DISKONTINUIERLICHER FERTIGUNGSI~OZESSE M a n f r e d Week, A l f r e d
1.
Sch~ring
Einf~hrung
Diskontinuierliche ineinander
Prozesse
beschrieben.
stands~nderungen. kontinuierlich
im P r o z e B b e w i r k e n Z u -
Der A b l a u f z w i s c h e n zwei Z u s t a n d s ~ n d e r u n g e n
sein,
aber auch interne
Welche Uberg~nge als Gesichtspunkten
werden d u r c h Z u s t ~ n d e und d e r e n 5-berg~nge
Bestimmte Ereignisse
ab,
Diskontinuit~ten
Zustands~nderungen unter
nach Aufgabenstellung,
angesehen werden, h~ngt yon den
denen der Proze8 betrachtet
z.B.
zur ProzeSanalyse,
wachung, werden Abl~ufe in einzelne
kann selbst
beinhalten.
Abschnitte
werden soll.
-steuerung
Je
oder -~ber-
untergliedert
oder als
zusammenh~ngend angesehen. In diesem Vortrag
sol-
len Fertigungsprozesse angesprochen
werden,
die yon einem ProzeBrechner als
- im w e i t e r e n
Fertigungsrechner
bezeichnet werden. ist
- gesteuert
Im B i l d
( B i l d 1)
das Modell eines
sogenannten
flexiblen
oder auch integrierten Fertigungssystems gestellt.
dar-
Es s i n d
Bild
1: Numerisch gesteuertes
Fertigungssystem
mehrere Werkzeug-
f~r Nichtrotationsteile ( F i r m a : B u r k h a r d t & Weber) yon einem Fertigungsrechner numerisch gesteuert
m a s c h i n e n zu e r k e n nen, die
Untersystem als hin,
zur Verteilung
DNC-System b e z e i c h n e t
yon Steuerdaten (Direct
Numerical Control).
Man e r k e n n t
dab die Maschinen ~ber Werkst~cktransporteinrichtungen
verkettet
sind.
Damit sind die Voraussetzungen
Ablauf des Werkst~cktransportes
w e r d e n . Das
an die Arbeitsmaschinen
wird weiter-
miteinander
f~r einen automatischen
und d e r V e r t e i l u n g
der Steuerdaten
ge-
geben. In der Praxis (Bild 2),
werden heute
die meistens
eine
auch lediglich
reine
DNC-Systeme e i n g e s e t z t
grSBere Zahl yon Maschinen beinhalten
als
355
in Fertigungssystemen. C~gen~ber der
Steuerung
yon Transportvorg~ngen ist
die Verteilung
Steuerdaten feineren
der
in einem
Zeitraster
betrachten;
zu
mit wach-
sender Maschinenzahl w i r d d e r DNC-Proze~ zeitlich als
eher kritisch
der Transport-
proze~.
Die Investi-
tionskosten f~r derartige flexible Fertigungssysteme sind Bild
au~erordentlich hoeh.
2: DNC-Systemmit konventionellen
NC-
Maschinen
Die gesamte Anlage ist daher hinsiehtlich der Auslegung und Ablaufsteuerung
sehr
der KomplexitRt der Fertigungssysteme Simulationstechnik sich
in den verschiedenen
einsetzen, bildet
sich
zu p r o j e k t i e r e n . als
Entwurf und Implementierung
Phasen einer
Projektierung
und analysiert
die lassen
Simulationsverfahren vorab nachge-
werden kSnnen.
wird die Technik der ProzeSsimulation
in Echtzeit
die nach der vorangegangenen "Entwurfs-Simulatio~'
tierungsphase
Wegen
Hilfsmittel
mit denen das gesamte System oder Untersysteme
Im f o l g e n d e n ben,
2o
an: F~r Planung,
sorgfRltig bietet
einzusetzen
beschrie-
in der Implemen-
iSto
Simulationsverfahren
Es w u r d e s c h o n a n g e d e u t e t , m~igerweise Entwurf ist einzelnen Bildh~lfte
da~ Planung und Entwurf des Systems zweck-
rechnerunterst~tzt die
durchzuf~ihren sind.
Systemauslegung,
Funktionseinheiten ( B i l d 3) i s t
d.h.
eine
Die Zielsetzung
detaillierte
Auslegung der
und deren Zusammenwirken. In der unteren
ein Verfahren
angedeutet,
b e i dem d a s g e s a m t e
System durch Rechenprogramme auf einem Gro~rechner nachgebildet werden die wichtigsten Transport-
Systemfunktionen
und Rechensystem"
die Ergebnisse
statistisch
Vorgehensweise dargestellt, liegt.
Dort geht es nicht
beim
in den Untersystemen
in einem zeitdiskreten
ausgewerteto
Dort
Modell simuliert
Im o b e r e n B i l d t e i l
der auch eine andere
ist.
"Maschinen-,
Zielsetzung
mehr um d e n G e s a m t e n t w u r f ,
ist
eine
und andere
zugrunde
sondern darum, ein
356
bereits
in der Auslegung defi-
ntertes
System zu p r o g r a m m i e -
ren und auszutesten, der Proze~ real
Proze~simulationin Echtzeit:
[
--~[--~L
bevor
vorliegt
Impulsgenerat0ren oee
oder Magnetbandger~ t
m i t dem F e r t i g u n g s r e c h n e r gekoppelt
ist.
Das P r o z e S -
rechensystem, stellt
als
arbeitet
rechts
mit seiner real,
wird.
Standardnachge-
Auf d e r l i n k e n
M6glichkeiten
SystemGroBrechner Beschreibungs-. I Nachbildunqderwichtigsten Systemlunktionen " I in einerProqrammiersprache Daten Iz.B.GPSSSIMSCRIPT.GASP ' FORTRAN,,,'. '
zur Simulation
wiedergegeben.
Eine einfacbe
L~sung besteht
darin,
generatoren
Impuls-
einzusetzen:
9
Gesamt-SimulationdurchRechenpr~ramme:
sind verschiedene
bilden
ONC IMo,
E L
Eingabe-~ Proze(~rechner ~ ] z ~ : ~ mit flexiblem Simulati0nsDaten | Programm
w~hrend der
Proze~ in Echtzeit Seite
SystemhSr I [
E
darge-
areIlre"
e i n DNC-System,
peripherie bildet
P R 0 Z E
i
Sie Bild 3: M~glichkeiten
Anforderungen der
der Nachbildung
yon DNC-Systemen
Maschinen auf NC-Steuerdaten nach. Jeder Maschine wird eine
Impulsfolge
Arbeitsweise
konstanter
Frequenz zugeordnet,
Eine der Realit~t mehr entsprechende magnetischen Aufzeichnungsger~tes
ist mit Hilfe eines
tats~chlicher Maschinen
bespielt.
Die
forderungen
laufen unabh~ngig
ein. Dieser Nachteil
nicht berucksichtigt.
yon der aktuellen
wecker und Zufallsgeneratoren
Warteschlangenl~ngen
Situation im System starr
arbeiten
jedoch
mit wenig flexiblen
sind daher Grenzen gesetzt,
der Reaktionszeiten
genannten Nachteile
als
die
Ger~ten.
Der
au~erdem
kaum m S g l i c h . A u s l a s t u n g s g r a d
im F e r t i g u n g s r e c h n e r
sind aber weniger interessant
Kurzzeit-
aufheben.
der Simulationsaufgaben Erfassung
Die Maschinenan-
IRSt sich durch den Einsatz steuerbarer
Die erw~hnten Verfahren
f~r das
In beiden Verfahren werden jedoch die Reak-
im Fertigungsrechner
Alle bisher
ProzeBsimulation
ein, sondern sind charakteristisch
verteilt.
tionszeiten
eine
eine erste
dar.
treffen gegen~ber der ersten L~sung bei der Wieder-
gabe nicht mehr periodisch Werkst~ckprogramm
Prozesses
m~glich: Das Bandger~t wird vor der
Simulation mit dem Anrufspektrum Datenanforderungen
ist
eine periodische
d e r M a s c h i n e n a n g e n o m m e n . D i e s e Annahme s t e l l t
N~herung in der Nachbildung des wirklichen
Variation
also
und
kSnnen zwar gemessen werden,
entsprechenden
kSnnen yon einem als
G r S ~ e n im P r o z e B . Proze~simulator
ar-
357 beitendem
freiprogrammlerbaren
Simulator
ist
ProzeBrechner
m i t dem F e r t i g u n g s r e c h n e r
kann i n Form yon Programmen s e h r den.
AuSerdem ist
lationsdaten
eine
mSglich.
an die
zeitdiskrete
system
f~r
die
Erfassung
Verfahren
Gesamtsimulation
Steuerung
eines
ohne Bindung an den realen
gekoppelt.
umfangreich
detaillierte Dieses
aufgehoben
der
f~r
gestaltet
wet-
und A u s w e r t u n g y o n S i m u -
Proze~simulation Prozesses
ProzeS erstellen,
Dieser
D as S i m u l a t i o n s m o d e l l
und f l e x i b e l
den Entwurf
bestimmten
werden.
an. l~t
schlieSt
D as P r o g r a m m sich
austesten,
sich
im Labor
beurteilen
und
optimieren. Im n ~ c h s t e n
Bild
werden Entwurfs-
(Bilu
4)
SIMUIAIIONSTECHNIK
und
Zeildiskrete Gesamtsimulalion
Proze~simutation in Echtzeit
gesamtes System
Proze(t
Implementierungsverfahren
gegen~bergestellt.
Die Ereignisse dell
der
tion
treten
Kleinrechner,gekoppelt mff Fertigungsrechner
GroBrechner (meistens)
Gesamtsimulaauf.
Falle
ereignis-
einer
orientierten die
(~is~ntinuierlich, ereignis oder perio(lenorlentiert
qu~si-~ontinuierlich in Echt zeit
roblemorientiert, ~mul~ionssprache
maschinenorientiert
Im
Simulation
Zeit
Ereignis
Fertigun~sr~chnermit Stan~rdperipheri~
zu diskreten
Zeitpunkten
wird
Rechenprogramme
Rechenprograrnme
im Mo-
yon
zu E r e i g n i s
weitergeschaltet. Zeitinkremente
Sys ementwurf und Vorabanaiyse
Programmierung,Test und Optimierung
- Medeliflexibilit~ - Zeitraffung
hohe Abbildungstreue
beschr~nkte Abbiidungs~rel~e
Simuiationsdauer
Die der
Bild 4: Gegenfiberstellung
yon Simulations-
Echtzeitsimulation
techniken f~r Entwurf und Entwick-
sind
lung yon Fertigungssystemen
gegen~ber
den
Operationszeiten
im
Proze8 so klein zu w~hlen,
dab von einem quasi-kontinuierlichen
gesprochen werden kann. Vorteilhaft
ist das Verfahren
lation wegen der hohen zeitlichen Abbildungstreue. Simulationsdauer
anzusehen,
sofern das Experiment
Ablauf
der Eehtzeitsimu-
Als Naehteil
ist die
~ber einen l~ngeren
Zeitraum beobachtet werden muS. In beiden F~llen bestehen die Simulationsmodelle aus Rechenprogrammen~
die gegenuber ~nderungen
flexibel aufge-
baut werden kSnnen.
3.
Verfahren
Im f o l g e n d e n (Bild deutet ner
ist
5).
der Echtzeit-ProzeSsimulation wird
das Verfahren
Der zu s t e u e r n d e
- wird
auf
- bier
einem ProzeBrechner
m i t dem S t e u e r -
menwirken mit
der Echtzeit-ProzeSsimulation
Proze8
seiner
oder
als
Transport-Lay-out
simulierto
auch Fertigungsrechner
Hardware-Echtzeituhr
bildet
Dieser
ange-
Simulationsrech-
gekoppelt. er alle
erl~utert
Im Z u s a m -
in diesem
358 Zusammenhang i n t e r e s s i e renden ProzeSoperationen zeitlich
n a c h . An d e n
Steuerrechner
~bertr~gt
-I
e r d i e M e l d u n g e n a u s dem simulierten
ProzeB,
ProzeBverfolgung
yon c::l c:~ c:~
ihm e r h ~ l t befehle
er
Steuer-
an den ProzeS.
Der S t e u e r r e c h n e r arbeitet
ein
ver-
Steuerpro-
Simulierter Proze~
grammsystem, das fdr den sp~teren Einsatz
erstellt
die
I I I I I J
wirklichen
Zun~chst ist roll,
1
wurde.
es sinn-
Systeme zur
Steuerdatenverteilung Bild
und Transportsteuerung wegen ihres
Zeitrasters
trennt
zu behandeln;
koppelter
ge-
Sichtger~t
sich
n~tzlich
in einem System ge-
ausgetestet
werden. Die Transportvor-
Gerade f~r die
sein,
zu e r f a s s e n
veil
Simulation
gekoppelten wird diese
die Proze~dynamik grafisch
ist,
als
~ber alphanumerische
geber. Der " T r a n s p o r t - S i m u l a tor"
( B i l d 6) b e s t e h t
aus mehreren Programmmoduln, die das Verhalten der Transportelemente an den Unstetigkeitsstellen
w~hrend des Trans-
portvorgangs
beschrei-
ben. Diese Elemente sind Strecken,
W e i c h e n , Ma-
schinen~
Werkst~ck-
wechsler
und E i n - / A u s -
lasteinrichtungen. erhalten
Ferti-
Proze8recnner
a u f e i n e m m i t dem S t e u e r r e c h n e r
verfolgen.
vom B e t r a c h t e r
eines
so
unabh~ngig voneinander
g~nge lassen besonders
gungssystems
unterschied-
lichen
kSnnen sie
5: E c h t z e i t - S i m u l a t i o n
Sie
vom F e r t i g u n g s -
Bild 6: Transport-Simulator
grafischen
M~glichkeit
viel
einfacher
Informations-
359 rechner
Steuerbefehle,
und das Verhalten
welche die zugeh6rigen
der entsprechenden
deren Ablauf werden intern an den Fertigungsrechner
Ereignisse bewirken,
g a n g s v e r b u n d e n m i t dem A u f l a u f e n
Programmoduln anstoBen
Elemente zeitlich erzeugt,
wie z.B. auf eine
d a s Ende e i n e s Lesestelle.
Proze~alarm wird dann die Kennung des Werkst~cktr~gers Die Steuerdatenverteilung Fertigungsrechners
i n e i n e m DNC-System i s t
aufgrund
nachbilden.
Nach
welche Proze~meldungen
der Datenanforderung
Transportvor-
Zus~tzlich
eine Reaktion einer
zum
angeboten. des
Maschine (Bild
7).
Im D N C - S i m u l a t o r w e r den derartige
Daten-
anforderungen
an den
Fertigungsrechner
ab-
gegeben und die zugeh~rigen Reaktionszeiten errant. Auf
Fer~igung!" Rechner
beiden Seiten des
,
NC-Satz-
Bildes sind die Ein-
H
Endezeiten
und Ausgabeschnittstellen des Simulalerte-
tors angedeutet.
In
einer Erelgnisliste sind die sogenannten aktuellen NC-Satzzeiten,
Bild 7: Prinzipielle
also Zeiten
Wirkungsweise
eines
Echtzeit-DNC-Simulators
f~r elementare Maschinenoperationen, yon einer
f~r jede Maschine gespeichert.
Echtzeituhr
zyklisch
um e i n Z e i t i n k r e m e n t
bestimmten Rhythmus wird die Ereignis-Liste zeit
mit der Simulations-Istzeit
simulierter
Maschinensatz
wartet
die zugehSrige
daten.
In beiden F~llen
Fertigungsrechner Steuerda~en
ist
abzugeben.
zeit
markiert
Leere".
ein Anforderungssignal Betrieb
ein
Die beim Simulator
und d i e
eintreffende
u n d zum a n d e r e n
Die w~hrend einer
Werkzeugmaschine ablaufende
Werkst6ckbearbeitung
an den
daraufhin
der Fertigungsrechner
n~chsten Maschinenoperation. nachgebildet.
ist
bei Zeit~berschreitung
an den Simulator
einmal die Reaktionszeit
In einem
und die NC-Soll-
Bei Zeitgleichheit
W~hrend im e c h t e n ~bertr~gt
wird
auf Versorgung mit neuen Steuer-
vom S i m u l a t o r
ausgegeben werden, "ins
verglichen.
Maschine bereits
erhSht.
durchlaufen
gerade abgearbeitet,
n~chste Maschinenoperationszeit Steuerda~en
Die Simulationszeit
auch
bier
die
restlichen neue Maschinen-
d a s Ende d e r
NC-Satzbearbeitung
an der
dagegen wird nicht
360
Die Simulationsmodelle sind
so angelegt,
da8
das Simulationsobjekt, also
SIMULATORKERN
die nachgebildeten
Ferttgungs-
und T r a n s -
porteinrichtungen,
in
Anzahl und Auslegung leicht
variiert
werden
kSnnen (Bild 8). Simulatorkern alle
Der
enth~lt
A
notwendigen Bau-
steine
zur Nachbildung
PARAMETER • Maschinenzahl • Steuerungsarten • Fertigungsaufgaben
der Funktionseinheiten im P r o z e S . hinaus
gibt
weiteren
Dar~ber der
Ablauf
der Simulation
steuert.
Den D a t e n v e r k e h r Kopplungsteile
Bild 8: P r o b l e m s p e z i f i s c h e
• OperatJonszeJten • Zahl der Funktionseinheiten
in beiden Rechnern.
Ferttgungsrechners.
Aktualisierung
des Simulatorkerns
zwischen Fertigungsrechner
zum s i m u l i e r t e n
und S i m u l a t o r
Aus d i e s e m G r u n d r a g t
ermSglichen die
Schnitt-
Proze~ gering~Ggig in den Softwarebereich
Vor B e g i n n e i n e s
kern entsprechend
de~ n a c h z u b i l d n e d e n
zu a k t u a l i s i e r e n .
Schlie~lich
die sich
•
UND EtNGANGSDATEN
Transport, Lager Gaometrie
es einen
Baustein,
den zeitlichen
stelle
A
Fertigung
aus der konkreten
Simulationslaufes
ist
des
der Simulator-
Problem ~ber den Parameterbaustein
sind noch die Eingangsdaten
Fertigungsaufgabe
herleiten
bereitzustellen,
lassen.
Das n~chste Bi]d z e ~ t den z e i t l i c h e n
_._t__L
Abla~£
±::
:t-
.,,
eines D a t e n a u s t a u s c h e s z w i s c h e n Simulator und
--~AV
',. . . . .
i
i,,
~- TAV ~
',
t --.
I
Fertigungsrechner
IIIIIIIII!IIII lllllllll~iI~UtATiO~S'fAk'flll IIIIIIIIIIIIIIIIIIIIIIII
(Bild 9). Die Echtzeituhr des Simulationsrechners
inkrementiert
mit einer R a t e 1/TST die per Software gebildete Simulationszeit.
Die
I FERTIGUNGSRECHNER I TST Simulationstakt TKD Kalenderclurchiauf TAV Au~rz6gerung TKZ Kalenderzyktus TMS NC-Maschinensatz TR ReaMionszeit
,~, z~
I A't°'~
NC-DatenEmpfang
Feinheit dieses R a s t e r s begrenzt die Genauigkeit, mit der zeitliche Vorg~nge im Simulator
B i l d 9 : Z e t t d i a g r a m m e zum S t e u e r d a t e n austausch
361 erfa~t
werden k~nnen. Gegenfiber diesem Simulationstakt
mit der der Ereigniskalender periode
TKZ i s t
konstant,
Zustand des Kalenders ist
vom S i m u l a t o r
punkt ist
die
Kalenders
tritt
als
ab.
durchlaufen
vorgegebene
Nach A b l a u f e i n e r
Maschinenoperationszeit
Sollzeit.
wird.
Wegen d e r s e r i e l l e n
Nach d e r
verstreicht
w f i n s c h t e n D a t e n am S i m u l a t o r
eintreffen.
ffir den technologischen innerhalb
Bearbeitungsfehler
Wartezeit
nicht
als
vielmehr
fiberschritten
sicherzustellen,
sich
also
TAV v e r z S g e r t
Zeitraster
sein,
der Zeit
Allerdings
l~t
ffir einen Durchlauf
Forderungen - niedrige - -
die Verim F e r -
m~glich,
zeitlich
k~nnen
gut auszuWartezeiten
einer
Zeitanteil
Zeit
ist.
zu s t e l l e n , sich bis
schnelle
verschiebt
Diese Verf~lschung sehr
HShere Ansprfiche sind die
in einem sehr
feinen
die Aufl~sung der
Simulationszeit
der Simulationstakt
TST g l e i c h
des Uhrprogramms ist.
an den Simulator
Datenanfor-
ffir den Kalenderzyklus
Die Genauigkeit
I n d i e s e m Zusammenhang s i n d
hohe z e i t l i c h e
-
nicht
wird auch yon den Ubertragungszeiten
den Rechnern beeinflu~t. zeitlichen
Um d i e s e n
Operationszeit
n u r so w e i r v e r b e s s e r n ,
Proze~nachbildung
Ist
sie
Daher g e h t es i n DNC-Systemen
NC-Maschinensatzes.
wenn d i e
der Reaktionszeiten
liegen.
theoretisch
der Maschinen
Aktivit~ten
da~ die kritischen
wird.
eines
gegenfiber der mittleren
an die Erfassung
an
ge-
Bedeutung sind
dab der vorgegebene Zeitpunkt
die Operationszeit
wird zu vernachl~ssigen klein
die
werden.
Es w u r d e s c h o n e r w ~ h n t , d e r u n g um d i e Z e i t
des
gr~Ser
neben anderen Zeiten
wegen a n d e r e r
weniger darum, den vorhandenen Fertigungsrechner lasten,
bis
A b l a u f im Z e r s p a n p r o z e S .
der erlaubten
nicht
Datenanforderung
Von g r ~ S e r e r
am W e r k s t f i c k a u f t r e t e n .
TMS Zeit-
Bearbeitung
Diese Wartezeiten wirken sich
der Maschinen aus.
sorgung der Maschine mit Steuerdaten tigungsreehner
tats~chlichen
vom
Dieser
die jedoch
eine ReaktionszeitTR
Steuerdatenanforderung
auf die Auslastung jedoch
Die Durchlauf-
TKD h ~ n g t g e r i n g f f i g i g
e i n e A u s g a b e v e r z S g e r u n g TAV e i n ,
ein Kalenderzyklus
einer
geringer.
die Rate,
die Durchlaufzeit
ein neuer NC-Maschinensatz anzuforderno
den Fertigungsrechner aufgrund
wird,
ist
der
zwisahen den beihaupts~chlich
diese
zu s t e l l e n :
Aufl~sung des Simulationstaktes
Zykluszeit
for
Ubertragung
einen Kalenderdurchlauf
zwischen Simulator
und F e r t i g u n g s -
rechnero Je besser
diese
Forderungen
genauer wird der Simulator. der
Lage,
reichender
"schnelle
erffillt
Prozesse"
Genauigkeit
werden,
desto
leistungsf~higer
Ein in diesem Sinne guter mit vielen
nachzubilden.
parallelen
Simulator
und ist
in
Vorg~ngen mit aus-
362 4.
Eingangsdaten
f~r die
Simulation
Der Ablauf in einem Simulationsmodell daten
bestimmt,
und A u s w e r t u n g wird entscheidend
welche auf das Modell einwirken.
yon den Eingangs-
Diese Daten lassen
aus den Aufgaben ableiten,
d i e im S y s t e m b e a r b e i t e t
e i n e m DNC-System s i n d
vor allem die Raten der Steuerdatenanforderun-
dies
gen durch die Maschinen. Die Anforderungsrate s~chlich
y o n dem g e r a d e b e a r b e i t e t e n
Einzeloperationen derungsraten
bewirken eine
und v i e l e n
Fertigungsrechners. bilden
Eine ~hnliche Da d i e 5fteren bilden
Zugriff
Viele
kurze
Bei hohen Anfor-
e i n e hohe B e l a s t u n g
des
dab sich Warteschlangen
vergrSBern.
gewShnlich nicht
vom E x t e r n s p e i c h e r
geholt
zum E x t e r n s p e i c h e r ,
werden,
satzweise
Informationsmenge. sondern in grS~eren
bewirken lange
v o r dem s i c h
ebenfalls
S~tze einen Warteschlangen
kSnnen.
Die TransportvorgRnge verteilung lich.
sich
dann wieder,
Wirkung haben MaschinensRtze mit gro~er
Steuerinformationen
Einheiten
WerkstUckprogramm ab.
Maschinen ergibt
In
Maschine h~ngt haupt-
hohe Anforderungsrate.
Daraus folgt
und die Reaktionszeiten
einer
werden sollen.
sich
viel
seltener
Die zeitlichen
System werden geblich zeiten
sind
g e g e n ~ b e r dem A b l a u f d e r z e n t r a l e n
und belasten
VerhRltnisse
den Fertigungsrechner
Steuerdatennut unwesent-
bei der Steuerdatenverteilung
also ma~-
i m DNC-
NC - Maschinen
yon den Satz~;;gel~nis der Analyse iiii]iHii]]iiilH I~ufigkeitsverteilungen ) ]ii]m]i]ii]iH]
und den Satzl~n-
gen beeinflu~t.
Analyse der NC-Sleuerdaten
Das f u r
e i n DNC-System v o r g e gebene WerkstUckspektrum ist lich
also
dieser
analysieren
hinsicht-
/
G r S ~ e n zu /
(Bild 10).
Die Daten werden statistisch daraus
/ /
NC - Satzzeiten
erfaSt
und
NC ~ SalzI~ngen
/ I
/
/
charakteristische
Eingebedaten
I simuli ~ions-1 modelI
•
H~ufigkeitsverteilungen erstellt. tige
Zwei d e r a r -
Verteilungen
Bild
10: Erzeugung yon Eingabedaten die
be-
schreiben
also
einzelnes
oder eine Gruppe ~hnlicher
speieher
yon DNC-Systemen
ein
Simulationslaufes ten Verteilungen
Simulation
fur
W e r k s t U c k e . Vor d e r A u s f U h r u n g d e s
w e r d e n n a c h dem MONTE-CARLO-Verfahren d e n g e s p e i c h e r entsprechend
des Fertigungsreehners
Zufallszahlen hinterlegt.
generiert
u n d a u f dem E x t e r n -
Wie s c h o n a n g e d e u t e t ,
werden
363
bei einer
Datenanforderung
Steuerdaten
Gbertragen,
Maschinensatz.
reeht
viel viel
darin,
leichter
Allerdings
und Rechenzeit.
Operationen
in einer
f~r
der Einspeisung
die Zufallszeiten
zu e r z e u g e n .
Speicherplatz
arithmetischen line
besteht
selbst
ProzeS nicht
sondern die Operationszeit
Eine andere MSglichkeit
in den Simulator im S i m u l a t o r
vom s i m u l i e r t e n
die eigentlichen den n~chsten der Eingangsdaten
w~hrend des Experiments
beansprueht
diese
AuSerdem l a s s e n
problemorientierten
sich
L6sung diese
Spraehe off-
programmieren.
Fertigungsrecflner~.//~,.,.,..~..~)/~-/-~
Z///N/Z/i/IiI////IN/ZI22Z
W~hrend der Simulation wer-
I
den eine ganze Reihe yon Daten gesammelt,
die f~r
~ Simu~or.. I,,, N
DatenfQr dieAuswertung
...............
F/_/Z~
] WartendeMaschinen
die Auswertung des Ver-
......
II~
I
il
I
suches yon Bedeutung sind (Bild 11). Dabei interessieren besonders Wartezeiten und Belegungsgrade einzelner Funktionseinheiten. Einige Daten werden im Fertigungsrechner
gesam-
melt, andere sind nut im
m m N
Simulator zu erfassen. Auf die Bedeutung der
........
Wartezeiten zwischen An-
forderung
iiii::ii:=iiiiiiiiiii~'Si'ai~'o~i're'r'qeiii'ui"~iiiiiiiiiii?::ii:~iii l A~f
und Ausgabe
yon Steuerdaten
I
==========================-_:.
wurde
sehon hingewiesen. Allerdings sinnvoll
wird es nicht sein,
jede
zelne Reaktionszeit
Bild 11: Auswahl einiger Daten fGr die
ein-
Auswertung der DNC-Simulation
f~r
die Auswertung abzuspeiehern, platz Viel
beansprucht interessanter
Klassen,
und die Daten in wenig ~bersichtlicher ist
dagegen die Einteilung
die vor Beginn definiert
Die Belastung
Simulationszeit
l~t
Warteschlangen,
und Proze~ausgabe
Form a n b i e t e t .
der Reaktionszeiten
in
werden.
des Fertigungsrechners
L~nge d e r p r o g r a m m i e r t e n speicher
da dieses Verfahren sehr viel Speicher-
u n d dem A n t e i l
sich
unter
anderem aus der
dem B e l e g u n g s g r a d der freien
yon Extern-
Rechenzeit
an der
ableiten.
W~hrend die Transportvorg~nge
determiniert ablaufen,
ist der DNC-Proze~
364 wegen der scheinbaren treffen,
als
Simulation
Regellosigkeit
stochastisch
auch nieht
Auswertung liefert
m i t dem d i e D a t e n a n f o r d e r u n g e n
zu b e z e i c h n e n .
determiniert
Daher kann dieser
ausgewertet
z.B. Mittelwerte
Tell
ein-
der
werden. Die statistische
fiber d i e A n z a h l d e r a u f V e r s o r g u n g
w a r t e n d e n M a s c h i n e n o d e r d e n Grad d e r E x t e r n s p e i c h e r b e l e g u n g .
Diese
statistischen
werden.
die
Ergebnisse
Simulationsdauer
z.B.
w e r t e wegen z u k l e i n e r richtig
wieder.
statistischen
Von ~ h n l i c h e r
zu e r f f i l l e n ,
die wahren Verh~ltnisse
die Abgrenzung der Anlauf-
Allerdings
da e s m i t u n t e r
ist
diese
schwierig
Mittel-
der
und A u s l a u f p h a s e
Forderung gar nicht ist,
diese
Ist
nicht
Bedeutung ffir die Zuverl~ssigkeit
ist
Verlauf.
abgesichert
nur kurz gewesen, geben die berechneten
Stichprobenzahl
Ergebnisse
vom s t a t i o n ~ r e n leicht
mfissen m i t P r f i f v e r f a h r e n
so
Phasen w~hrend
d e s V e r s u c h e s zu u n t e r s c h e i d e n . Zur A b s i c h e r u n g und A u s w e r t u n g d e r g e m e s s e n e n und b e r e c h n e t e n der bisher geeignet
maschinenorientiert
sein
empfiehlt
als
und d o r t
weniger
Fertigungsrechner.
nach Ablauf der Simulation zu f b e r t r a g e n
Daten wird
Simulationsrechner
der groBzfigiger ausgestattete
es sich,
den Fertigungsrechner
5.
program~ierte
die
Daher
gesammelten Daten an
auswerten
zu l a s s e n .
Zusammenfassung
Das g e s c h i l d e r t e liche
Prozesse
allgemein
Verfahren in Echtzeit
Steuerrechner
der ProzeBsimulation so n a c h z u b i l d e n ,
ohne wirklich
Laborbedingungen programmiert bisweilen der ersten
recht
so f u n k t i o n i e r e n ,
Prozesses
ger~tetechnische
sollte
Verfahren
noch d a r a u f
kaum z u v e r t r e t e n
sollte
des Steuerrechners
parallele
Vorg~nge des
nachgebildet
hingewiesen
werden,
ist.
in
z u k ~ n n e n . Dazu s o l l t e
Genauigkeit
mehrfaeh bei der L6sung gleicher
lungen einzusetzen, sein°
dab zeitlich
oder gfinstigen
werden kann. Dabei wird es
studieren
und P r o g r a m m i e r a u f w a n d a l s
Systemimplementierung
dab der Fertigungs-
das Verhalten
mit hinreichender
k~nnen. Abschlie~end
diskontinuier-
vorhandenen Proze8 unter
und g e t e s t e t
sein,
Phase der Implementierung
der Simulator simulierten
interessant
erlaubt,
Hilfsmittel Gelingt
dab der
ffir eine
es jedoch,
oder fihnlicher
der einmal geleistete
werden einzige dieses
Aufgabenstel-
Aufwand z u r e c h t f e r t i g e n
ZUR
ENTWURFSMETHODOLOGIE
VON
PROGRAMMSYSTEMEN
F~IR PROZESSRECHNER WERNER Der
GOTTSCHALK
wachsende
Umfang
und die zunehmende
langen eine Systematisierung
der Entwurfsarbeit,
wurfsmethodologie
voraussetzt.
rungen
Eisenbahnsignaltechnik
im Bereich
schweig
ein Beitrag
Prinzip
des Entwurfsverfahrens
Das
Ergebnis
gro~en
ist dadurch
gekennzeichnet,
rerseiis
durch
einer Ent-
soll aus den Erfah-
Form
werden
in Braun-
und die Spezifikation
die Logik der Auf-
ausfiihrlich erarbeitet
entwiekelten
Formalismus,
wird.
dab es fflr einen mSglichst
eingehend
verst~ndlich
geprfift werden
des programmiertechnischen
kSn-
LSsungsverfah-
ffir die Implementierung
mit der Aufgabenstellung
Das
der den Zeit-
Rechnerkenntnisse
und Vollst~indigkeit
Einzelheiien
Vergleich
dab zun~chst
aueh ohne spezielle
schon jetzt Richtigkeit
rens ausgearbeiiet
ver-
Akliengesellschaft
niedrig h~ill, so dargestellt,
Kreis yon Mitarbeiiern
hen. Erst danaeh
Ausffihrungen
der Siemens
in rein problemorientierter
fiir die Fixierung
ist, damii
die die Entwicklung
In den folgenden
wird mit Hilfe eines besonders
aufwand
der Softwaresysteme
geleistet werden.
Entwurfsverfahren
gabenstellung
Komplexit~it
aufgestellt0
leicht kontrollierbar
die ih-
sind.
Proze ~steuerung Der
Ablauf eines Prozesses
bestimmt,
die den Betriebszustand
Die Betriebsereignisse wie beispielsweise rekt verursaeht bewegung.
st~indig ver~indert. gesteuert,
die Bildung
der Fahrstra~en
in einer Eisenbahnanlage
oder indi-
Beispiel die durch
die Signalgebung
yon funkiionell eng zusammenh~ngenden soll als Betriebsvorgang
fiber jeden neu eintretenden
Entscheidungsfindung
Objektsyslems
direkt vorn Proze~rechner
das bedarfsweise
unter Modell
des gesieuerten
yon Betriebsereignissen
dabei entweder
Eine Folge
Die Meldungen
eine Folge
werden
wie in diesem
und Betriebszust~nden
system,
(Bild I) wird dutch
mu~
durch
eine vereinfaehte
stehen ist. Sie beschr~[nkt Zwecks
wesentlieh
Modell,
das den jeweiligen
bezeiehnet
Nachbildung
informieren
des Prozesses
der technologischen
sich auf die Fakten,
sind. Hier soll unterschieden Betriebszustand
werden.
die direk%e Steuerung
es dabei fiber ein Modell
die zum werden
Zug-
Belriebsereignissen
Betriebszustand
Kommandos
ausgel6ste
das Steuer-
vornimmt.
Zur
verffigen,
wobei
Wirklichkeit
zu ver-
Erffillen eines bestimrnten zwischen
eines Prozesses
durch
einem
statisehen
Markierungen
in
366
Froze8 (Objektsystem)
ProzeBrechner
i
(Steuersyste=)
I
I lz.,,.u. '"l
t
I
,,,T
i H'ld°"g~_I ,el~.,,gs-
8etriebszustand !
I -!
empfang
ModellS I
~_~
(star.)
I
i indirekt
! i
gesteuerte Betriebsereignisse
auslGsende
mitwirkende
Betriebszust~nde
!
Betriebszust~nde
!
,e=:'elJ°"
Betriebs- I
Steuerfunktionen
_t ,°,.1,°I (dyn.)
-~
ereignisseI
Entscheidungen Kommandoausgabe
I
.•
Arbeitsdaten
Bild 1. Prinzip der Steuerungeines Prozesses
Speicherelementen zugeordnet zesses
abbildet,
die den einzelnen
sind, und einern dynamischen
durch einen Algorithmus
wartenden scheidungen
ProzeSablaufs
Systemelementen
Modell,
welches
erkl~[rt. Es ermSglicht,
aufzustellen
des Objektsystems
das Verhalten Prognosen
und bet Alternativl6sungen
des Pro-
eines zu eroptimale
Ent-
zu treffen.
Entwurfs stufen D e n Entwurfsstufen liegt das Denken in Systembegriffen zugrunde. Ein System stellt die zielorientierte funktionelle Einheit m e h r e r e r Elemente dar, deren Relationen untereinander die Struktur des Systems ergeben. Dabei ist wesentlich, da~ jedes Element aus der Sicht einer tiefer gelegenen Abstraktionsebene wieder als selbst~ndiges System aufgefaGt und in gleicher Weise analysiert werden kann, so da~ sigh eine Hierarchie von Systemen herausbildet (Bild 2). Dabei wird die hShere Ebene als U m g e b u n g s s y s t e m der tieferen Ebene bezeichnet.
367
Gesamtsyste= (durch Rechner gesteuerter ProzeB)
ProzeBebene
Problemanalyse I
($leuersystem) Rechner
Anlagenebene
Software ebene
Problemanalyse II Programm .ammentwurf II-
~grammeniwurf I
ebene
I!
Anwendungs-
$peicher
programme
I
I
Rechnerinterne Programme
$peicherlisten
ebene
Bild 2 Systemhierarchie der ProzeBsteuerung
Problernanalyse I In der ersten Entwurfsstufej der "Problemanalyse I"j wird die Aufgabenstellung fNr die A n w e n d u n g s p r o g r a m m e
aus d e m Proze~geschehen abgeleitet. M a n fa~t da-
bei die von einem Rechner gesteuerte Anlage als G e s a m t s y s t e m auf~ in welchem'der Proze~ als Objektsystem°
der Proze~rechner als Steuerungssystem,
die Bedienungs-
einrichtungen usw. die Elemente bilden. Diese Abstraktionsebene wird ProzefSebene genannt. Die Hauptaufgabe besteht darin, die Zielsetzung fur die einzelnen Elemente festzulegen und ihre Relationen untereinander zu ermitteln. In einer darunter gedachten dataillierteren Abstraktionsebene,
der "Rechnerebene"
stellt der Proze~rechner ein selbst~ndiges System dar, f~r das die Proze~ebene das U m g e b u n g s s y s t e m
bildet. Hier wird zun~chst die Hardware von den weiteren
368 Betrachtungen
ausgeschlossen,
eines Hilfssystems
Tr~iger der Software
lediglich die Rolle
spielt und erst sparer bet der Implementierung0
schlu~ des Entwurfs, Systemelemente,
wieder
n~mlieh
aus der Zielsetzung stem
weil sieals
in Erscheinung
die Programme
tritt. Das
Softwaresystem
und Speicher,
aufgelDst.
fiir das Softwaresystem
die Ziele ffir die einzelnen
also nach Ab-
und den Relationen
Programme
und Speicher
wird in die Dann
zum
leitei man
Umgebungssy-
ab und bestimmt
ihre Re-
lationen untereinander. Programmentwurf
I
. . . . . . . . . . . . . . . . . . . . . .
Die darunter n~chste
Entwurfsstufe,
und Speicher dem
anschlieSende
beschriebenen
Implementierung
Prinzip
Man
Ebene,
enih~it die
die Programme
15st die Programme
in Sysiemelemente,
Systeme
der Speicher
I". Hier werden
betrachtet.
ebenfalls
als getrennte
durch
Problemanalyse
Systeme
in der untersten
Die Datenstruktur
fehlsebene
die "Programmebene",
den "Programmentwurf
als selbst~ndige
auf, die schlie~lich
den.
Abs%raktionsebene,
die "FunktionsblScke",
der "Befehlsebene",
im Rahmen
in die Programmiersprache
wird in Listenform
programmiertechnische
nach
der
umgesetzt
wer-
aufgeffihrt und in der Be-
Details erg~nzt.
II und Programmentwurf
II
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Der
Ablauf der Anwendungsprogramme
zus~tzlich kSnnen,
Funktionen,
verlangt
die nicht alle durch
so z. B. Speicherverwaltung,
ffir den Overlay-Betrieb, dafiir wird ebenfalls dungsprogramme
abgeleitet und mit "Problemanalyse der Speicher
werden
realisiert und heiSen "Programmentwurf
Der
auf der Grundlage
des Systemdenkens
wird auch "Top-down-Specification"
ist ein streng modularer
Aufbau
und Anderung
erleichtert
wesentlich
ebenso
noeh
werden
iV[anipulationen
Die Aufgabenformulierung Zusammenwirken If" bezeichnet.
der AnwenProgramment-
wie bet den Anwendungsprogram-
II". stufenweise genannt.
des Programmsystems, und Voraussetzung
vorgenommene Der
Entwurfs-
Vorteil des Verfahrens der Fertigung,
Prfifung
ffir eine rationelle
Arbeits-
ist.
Problemanalyse folgenden
aus dem
Betrieb
abgedeckt
spezielle
das sog. Anwendungssystem.
men
methode
das Betriebssystem
Kanalvermittlung,
in der Programmebene
wurf und Spezifizierung
proze~
im rechnerinternen
I und Programmentwurf
an einem
I von Anwendungsprogrammen
kleinen Beispiel veranschaulicht
werden.
sollen im
369 Problemanalyse Problem~Lbersicht Zur
kurzfristigen
mierfachkr~fte sammenh~nge bremse,
Information
Problem
erkl~irt die Problemiibersicht des Problems.
schwindigkeit
werden.
Fahrzeuge
sofort ein und 18st sie dann wieder, auf den Wert
die Funktion
eingesetzt
wird.
sollen in der Bremse
Schaltel man
die Bremse wenn
Va abgesunken
Program-
Ziigen die wesentlichen
Bild 3 zeigt beispielsweise
Ve einlaufenden
te Geschwindigkeil
noch nicht vertrauten
in groben
die im Betrieb eines Rangierbahnhofs
keit Va abgebremst zeuges
der mit dem
einer Gleis-
Die mit der Geauf die Geschwindig-
beirn Ann~hern
die durch
Zu-
eines Fahr-
ein Radarger~t
ist~ wird der Proze~
fiberwach-
den gestrichelt
Objektsystem Ablauf A
Ablauf B
' , Glels i..~..__~..,
!
I
]
0 0 Gleisbruse ]
B'tr'ebsv°r angls .
I
tI
TB I,
\
\
\
t6
\
gekennzeichneten bis zu einem reicht,
Zeitpunkt,
das Fahrzeug
zu verzSgern blem
Verlauf
\
Blld 3.
',,
nehmen. bei dem
ProblemUbersicht der Steuerung einer G1elsbremse
Verschiebt
man
dagegen
die noch erzielbare
bis zurn Verlassen
(durchgezogene
besteht darin,
\
den zeitgerechten
Bremswirkung
der Brernse
Linie), erreicht man
den Einsatz
der Bremse
gerade
auf die Geschwindigkeit
einen Zeitgewinn
Bremseinsatzpunkt
tG. Das
T B zu ermitteln.
ausVa Pro-
370 L
Achsen
H
E
Ablauf 14eSstrecke
Sytezelemente Betriebsvorgange
Gleisbremse
Regelverlauf Abtauf zu schnell/zu schwer Einholen zweier Abl~ufe Oatenausfall KoniaktstGrun9
1 2 3 4 5
E erste, L letzte, M Ubrtge Achseneines Ablaufs Ablaufrlchtung Bild 4
Proze6definierung
Proze2definierung H i e r w i r d das O b j e k t s y s t e m ( U m g e b u n g s s y s t e m ) d u t c h e i n e g r a p h i s c h e D a r s t e l l u n g (Bild 4) b e s e h r i e b e n , die d u t c h k u r z e E r l ~ u t e r u n g e n d e r e i n z e t n e n F u n k l i o n s e l e m e n te e r g ~ n z t w i r d . D a z u g e h S r t n o c h e i n e A u f l i s t u n g a l l e r B e t r i e b s v o r g ~ n g e , die d u t c h das S t e u e r s y s t e m b e h e r r s c h t w e r d e n s o l l e n . Die P r o z e ~ d a t e n (~u~ere R e lationen) werden t a b e l t a r i s c h erfa2t. Zielsetzung des Systems der Steuerung Modellentwurf Das s t a t i s c h e M o d e l l u m f a 2 t e i n e L i s t e a l l e r Daten, rail d e r e n Hilfe d e r Z u s t a n d de s P r o z e s s e s i m R e c h n e r n a e h g e b i l d e t w e r d e n s o l l , b e i s p i e l s w e i s e d e r Inhalt yon A c h s z ~ h l k r e i s e n zurn K e n n z e i c h n e n d e r B e s e t z u n g yon G l e i s e n , das M a r k i e r e n yon B e t r i e b s z u s t ~ n d e n , die D a t e n d e r A c h s g e w i c h t e und A c h s z a h l e n d e r e i n z e l n e n F a h r zeuge. Das d y n a m i s c h e M o d e l l enth~lt den A l g o r i t h m u s zu m B e s t i m m e n d e s B r e m s e i n s a t z p u n k t e s , t i e r aus d e r D i f f e r e n t i a l g l e i c h u n g fGr den B r e m s v e r l a u f a b g e t e i t e t w i r d . A l s Parameterwerte
d i e n e n d a b e i die E i n l a u f g e s c h w i n d i g k e i t d e s F a h r z e u g s und die Z a h l
d e r g l e i c h z e i t i g in d e r B r e m s e b e f i n d l i c h e n A e h s e n . FunktionsGbersieht .
--
~
.
.
.
.
.
.
.
t
o
Das P r o b l e m bei d e r S p e z i f i z i e r u n g d e r S t e u e r f u n k t i o n e n l i e g t d a r i n , da2 j e d e s e i n z e l n e S y s t e m e l e m e n t ganz v e r s c h i e d e n e A k t i v i t ~ t e n a u s l 5 s e n kann~ je n a c h d e m , u m w e l c h e n B e t r i e b s v o r g a n g e s s i c h g e r a d e handelt. D i e s e v i e l f ~ l t i g e n Verknfipfungen
371 zwischen Betriebsvorg~ngen und Steuerfunktionen lassen sich in a11gemeiner F o r m durch die Funktionsmatrix
Tabelle i veranschaulichen.
Darin ist jeder Zeile ein Betriebsvorgang und jeder Spalte ein Systemelement zugeordnet. Die einzelnen Felder enthalten die Funktionselemente fij, wobei unter einem Funktionselement die Aktivit~t des Betriebsvorganges mit der dazugehSrigen Steueraufgabe zu verstehen ist.
Systemelemente
1 Betriebsvorg~nge
j
m
fll ...... flj ........ flm fil ....... fij ........ rim n
fnl ...... ~nj ....... fnm
Tabelle 1
Funktionsma~rix
Es kann definiert werden: Ein vollst[ndiger
Betriebsvorgang
Betriebsvorgang m
B = K j
und die gesamte
Steueraufgabe
fij =
1
fiir ein Systemelement
des Objektsystems
Steueraufgabe n
8
Das
systematische
Erfassen
und Aufzeichnen
Funkiionsmatrix)
ist unerl~liche
Programmierung.
Das formale
in der alle Betriebsvorg~nge beherrschenden
StSrungsf~lle
ne Betriebsereignis
= > fij i = I
aller Betriebsvorgange
Voraussetzung
(Zeilen der
fi]r eine exakte und rationelle
IIilfsmittel dazu ist die Funktionsi~bersicht in problemorientierter tabellarisch
(B) aufgefHhrt,
z.B.
Ordnung
errant werden. E/RM2
einschlieSlich
Dabei
(erste Achse
(Bild 5)~ der zu
wird jedes einzel-
Nberf~hrt
Kontakt
372
B S
Betrlebsvorg~nge Steueraufgaben
I ProzeOablauf, Elemente des Objektsystems
Ablaufbetrteb, eln Ablauf in der Bremse Wagendaten bekannt,
RM1/RM2- RK1
RK2
Regelfall
S E/RM2 S Geschltndigkeitswert Ubernehmen Simulation starten m
m
m
$1Parameterwert (Achszahl)der Simulation erhbhen
B2 E,K/RK2 $2 Parameterwert (Achszahl)der Simulation vermindern Simulation ermlttelt Bremselnsatzpunkt. Bremse und Radar mlt berechnetem Vorhalt einschalten.
B1M,L/RK1 $1Vorhalt erhdhen B2 E,M/RK2 $2 Vorhalt vermindern L/RM1
j
Zeitmessung fur folgenden Ablauf vorbereiten B L/RK2 S Grundstellung der Bremse und des Steuersystems herstellen
E erste, L letzte, M Ubrige Achsen eines ^blaufes
Bild 5. FunktionsObersicht der Gleisbremse (Auszug) RM2)
und die zugehSrige
graphische Diagramms
Darstellung den Vorgang
Steueraufgabe in Form
(S) kurz umrissen.
eines Zustandsdiagramms
Bedarfsweise
kann eine
oder eines Zeit/Weg-
veranschaulichen,
Funktionsbedingungen Zum
Aufstellen der Algorithmen
Elemente
des Objektsystems
zelnen Funktionselemente gen"ffir jedes Programm Ein hervorragendes
ausffihren,
werden
die die Steueraufgaben
aus der Funktionsfibersicht
ermittelt und unter der Be zeichnung getrennt zusammengefa~t
zweifelsfreier
der verschiedenen
Form,
Betriebsvorg~nge
f0r die die ein-
"Funktionsbedingun-
(Spalten der Funktionsmatrix).
Hilfsmittel dafiir ist die Entscheidungstabellentechnik
Sie gestattet in rationeller, Steueraufgaben
filr die Programme,
die Algorithmen
(Tabelle 2).
ffir die einzelnen
als Entscheidungsregeln
(Rn)
373
darzustellen ErhShung
und zu pr~zisieren.
der Verst~indlichkeit
Die Bedingungen, im Bedarfsfall
Aktionen
durch
und Regeln
zus~tzliche
kSnnen
Erkl,~rungen
zur
erl~u-
tert werden.
Funktionsbedingungen RN1 (Tell 2)
R1 R2 R3 R4 R5 R6 R1
B1Undefinierte Achsen und/oder Grund- j N N N N N zustand markiert B2 Wagendaten markiert JJNNN B3 Wagendaten verfUgbar --JJN B4 iVorl~ufer in der Bremse JNJ B5 !Achsen des Ablaufes (E, M, L) -HLEEE
A11Oatenfehlmeldung A2Bremsung des Vorl~ufers abbrechen A3iZeitmessung fur Folgeablauf vorber. A4 Ende zu 82/65: Wagendaten vorhanden Wagendaten nicht vorh. zu B4:
N N N N E
X X X
X X X XX XX
X X
kann nicht erste Achse sein muss erste Achse sein
Vorl~ufer wird nur bei erster Achse festgestellt
Tabelle 2. Entscheidungstabelle der Funktionsbedingungen RM1 (Tell 2)
Es ist anzustreben~ und fiberschaubar sammenhang rechten
zu machen.
durch
Balken
Zerlegen
Es ergeben
Verlauf
des Balkens
dere die Bedingungen
Ausg~nge
Ausg~nge
deren
wird.
Zu-
Die senk-
beschrieben,
genannt werden.
vorhanden
sein
BS, das die einzel-
entgegennirnrnt. Form
klein
stets oben ist, w~h-
das Betriebssystern
in knapper
fiir die einzelnen
Tabellen,
der Eingang
einer oder rnehrere
starlet und ihre Vollzugsrneldung
mSglichst
(Bild 6) beschrieben
dar, wobei
Linie syrnbolisiert
Seite des Bildes sind die Funktionen
in Teilproblerne
sich also mehrere
die Funktionsablaufstruktur
Die senkrechte
nen Programme
dureh
stellen je eine Tabelle
rend irn weiteren kSnnen.
die Tabellen
Auf der linken wobei
insbeson-
374 8S
1. PrUfung des BetMebsvorganges
ET1
1.1. Frei/Besetzt--Neldung 1.2. RichtungsprUfung a) berg,~rts: E b) talw~rts: 2 2. Steuerfunktionen bei lalrichtung 2.1. ZeitmeSeinMchtung bedienen 2.2. Vorl~uferbehandlung 2.3. OatenprUfung: E
ET2
BS BetMebssystem, ET Entscheidungstabelle E Ende des Funktionsablaufs Bild 5. Funktionsablaufstruktur RM1
Programmentwurf
. s.p.~.~±h%Kp~.~" ~f}kA tj % _ Die Speicher
zur Aufnahrne
Markierungen, weges
die sieh aus der Realisierung
ergeben,
genauen
der Daten des statischen Modells
sind in geeigneter
Ansprechen
Ordnung
des
prograrnrntechnischen
listenfSrmig
ist dabei jede Information
sowie der Daten
und
LSsungs-
zusarnrnenzustellen.
Zurn
durch eine Inforrnationsnurnrner
zu
ke nnze ichne n. Prograrnrnspe
zifikation
Die Funktionsbedingungen spielsweise durch
die Bedingung,
die Kontaktrneldung
erkennen,
da~ die erste Achse gestartete
rekt errnitteln. sehe Modell
Au~erdern
hier werden
RMI
Form,
durch
weitere
nicht
rnu~ also bei der Spezifikation Algorithrnen
Betriebszustand Funktionen
bei-
passiert hat. Das
kann aber aus der Meldung Man
sind noeh weitere
erg~nzen,
aus dern Modell
erforderlieh,
indi-
die das siati-
laufend akiualisieren.
und zu erweiiern; die entstehenden
jedes Programrn
tionsbl~cke"
den Kontakl
handelt.
herrschenden
Die f~r die Funktionsbedingungen rnodifizieren
in problemorientierter
Prograrnrn
die Funktionsbedingungen
den zurn Startzeitpunkl
gehalten;
die Vorg~nge
ob es sich urn die erste Achse
der Programme welche
erkl~ren
aufgeteilt.
aufgestellten darnit werden
Entscheidungstabellen die Programme
Entscheidungstabellen
Darnit wird die angestrebte
spezifiziert.
durch AuflSsen
ist in leicht iibersehaubare
sind also zu
rnSglichst klein
Funktionseinheiten,
Modularisierung
Auch
die'~unk-
erreicht.
375 Ein Beispiel
3: "Bremsensteuerung
zeigt Tabelle
ET 3 Bremsensteuerung vorberetten
vorbereiten".
R1 R2 R3 R4 R5 R6
,i
B1 Wagendatenmarkiert B2 WagendatenverfUgbar
J
J
B3 Kontaktz~hter = kbl. Achsen
J
N
B4 Z~hlkreis RH1 - RK2 ~ 1
N J
N N J N
N N
J
N
J
N
X X
X X X X X
X X
A1 Kontaktz~hler + 1
A2 Kontaktz~hler l~schen A3 Zeitmessung fur Folgeabl. vorber. k4 ~rkierun9 HH1 setzen Kontakiz~hler = 1 setzen k6 Markierung NIGE setzen A7 Textausgabe: WAGENNIGHTGEFUNDEN A8 Gehe nach ET 4 A9 Ende
X X
X
X
Tabei|e 3. Entscheidungstabelle des Funktionsblock 3 Die logische
Verkn0pfung
der einzelnen
se wie bei den Funktionsbedingungen Seite 12) ausgedrfickt. senkrechter
Dabei
wird zus~tzlich
ist die Spezifizierung
abgeschlossen.
so daS die Wahrscheinlichkeit
gischer
in der Aufgabenstellung
klein gehallen werden
kann.
Beim
semblers
vor,
die notwendigen Makros
usw.
Informationen
erg~nzt
wird.
Speichern
yon FORTRAN
rechnertechnischen
die mit Zif-
austauschen.
Dadurch
erlaubt eine gr~nd-
iinderungen
wegen
kSnnen
die Entscheidungs-
jedoch die Anwendung aufzustellen
Manipulationen,
lo-
Implementierung
in die Programmiersprache
herrsch%
Li-
gemacht.
nachtr~glicher
so da~ hier noch ein Programmablaufplan speziellen
in Form
Die gestrichelten
Die Darstellungsform
unmittalbar
In der Proze~steuertechnik
(Bild 7,
Speichersymbole
bei der anschlie~enden
Gebrauch
tabellen mit Hilfe des Voriibersetzers gesetzt werden.
durch
tiber den Inforrnationsflu~
fiche Priifung, Fehler
ein Ablaufstrukturdiagramm
mit den bezeichneien
gekennzeichneten
eine Aussage
wird in gleicher Wei-
Seile des Bildes erg~nzt.
da~ die FunktionsblScke
fern und Richtungsangabe
Damit
durch
wird die Darstellung
Linien an der rechten
nien bedeuten,
Entscheidungstabellen
urndes As-
ist, der dureh
Unterprogramme,
376
1. Besetzt-/Frelmeldun~
BS
KORBWAGDAVORG
t.t. Erste Achse Ta]richtung= Besetztmeldung: 2 1.2. Letzte kchse Bergrichtung= Frei~eldung: E 1.3. Ubrige Achsen: 2 2. Betriebszustand der BremseprUfen
2.1. Bremse nicht rechnergesteuert: 2.2. Undefinierte Achsen im Bre~sbereich: E 2.3. Bremsefrei oder mit bekannten Fahrzeugen besetzt: 3 3, Breesensteuerun~vorbereiten 3.1. Erste Achse: Wagendatenermitt Metdung, wenn nicht gefunden 3.2. Kein Vor1~ufer im Bremsenberei Vor1~ufer im Bremsenbereich: 4 4. Vortauferbehandlung 4.1. Bremse15sen, Radar ausschalte 4.2. Grundstellung fur Nachfolger herstellen: E
KORB, WAGOA,VORG Speichermit Informationsnummern BS Betriebssystem, FB Funk~ionsblock E Ende des Funktionsablaufs, Ziffer n~chsterFunktionsblock Bild 7. Programmablaufstruktur RMI
WEGE ZUR RATIONELLEN
SOFTWAREERSTELLUNG
FOR GRUNDAUFGABEN
DER PROZESSUBERWACHUNG ~STEU~ERUNG UND REGELUNG .
.
.
.
,,
Roland Wendelin I. Das Problem Die Erfahrung
beim Einsat~ yon ProzeBrechnern
Kesten fGr die Erstellung
der Software
kosten - unverh~ltnism~Big nngunsten
der Software
Besonders aufgaben
st~rend
wobei als charakteristisch
stellnngskosten Die folgenden
zu suchen,
Uberlegungen
angesehen
nicht allein die Erstellung
(on-line-Programme)
Aufgaben
"bedienbar"
betrachtet
Grundaufgaben
in Software
Problemkreisen
der pri-
werden darf.
wird derjenige,
umzusetzen
hat,
im wesent-
zumindest
dab weitere
in gewissen
Programme
die das Andern yon Parametern,
und L6schen yon Bearbeitungsfolgen aufbau durchfUhren,
der Er-
konfrontiert.
sein. Das bedeutet,
schaffen werdeu mUssen,
Es liegt
erwarten lassen.
• In der Regel m~ssen diese on-line-Programme Grenzen
wird.
die eine Rationalisierung
im Bereich der obengenannten
der technologische
groBer Mengen yon Pro-
gehen davon aus, dab fGr die Bewertung
yon RationalisiernngsmaBnahmen
lichen mit zwei weiteren
Grund-
Steuerung und Regelung,
die Verarbeitung
in diesem Bereich
m~ren ProzeBprogramme Gerade
bei immer wiederkehrenden
einfachen Algorithmen
nach Mitteln
zu
Zeit nur noch grSBer werden kann.
ist diese Tatsache
zeBdaten bei relativ
dab die
an den Hardware-
hoch sind und dab dieses MiBverh~ltnis
in n~chster
im Bereich der ProzeBUberwachung,
also nahe,
hat gezeigt,
- gemessen
bis hin zum kompletten
ohne daa Pro~eBgeschehen
ge-
Eintragen
nachhaltig
Programm-
zu beein-
flussen. . Abet auch im Bereich der Erstellung vet allem bei groBen Datenmengen, meln und Umsetzen
der ProzeBparameter
Mittel
existieren,
der Daten im Rechenzentrumbetrieb
sollten,
die das Samvereinfachen
und erleichtern. Erst wenu auch f~r die Erstellung ProzeBbedienungssoftware zeBparametern
wirkungsvolle
rung des eingangs Analysiert genden
(technologisch
Hilfen existieren,
zu erzielen,
die beschritten
wurden,
erwartet
on-line-Programme,
um
werdeno
um Rationalisie-
so erkennt man zwei Extreme,
im Hinblick auf die Problemkreise
• Effektive
orientierter)
kann eine Verminde-
genannten KostenmiBverh~ltnisses
man die Wege,
rungseffekte
yon
und ffir das Sammeln und Umsetzen yon Pro-
die im fol-
3?9
• Bedienungsprogramme und • Programm- und Datenhandling betrachtet werden sollen. 2. Modulate Techniken Der einfachste Weg findet sich in der Definition yon modularen Programmfunktionen und ihrer Realisierung in einer Bibliothek yon Programmbausteinen.
Die Zusammenstellung
zu Anwenderprogrammen
dabei in der Regel mit Hilfe yon Makrosprachen,
erfolgt
wobei zur Erzielung
speichereffektiver Programme ausgefeilte Unterprogrammtechniken Gblich sind. Der Beuutzer solcher Modulsammlungen kann sich zwar brauchbare Teilfunktionen ausw~hlen und, was natGrlich yon Vorteil sein kann, nach eigenem Ermessen kombinieren,
erweitern oder sogar ab~ndern.
Ober
die Anordnung seiner Programme Gber Strukturen yon Code und Daten mu2 er sich jedoch eigene Gedanken machen. Ergebnis sind hochgradig individuelle Programmstrukturen. FUr das Problem der ProzeBbedienung bietet eine rein modulare Technik wenig Unterst~tzung,
da wegen nicht definierter Strukturen
auger einigen trivialen Konvertierungsroutinen kaum Programmoduln definierbar sind, die typische modulate Bedienungsabl~ufe
abwickeln
k~nnten. Beider
eigentlichen Programm- und Datenerstellung findet der Anwen-
der praktisch keine Hilfestellung fur das Formalisieren der Parametererstellung in Form yon Formularen,
die notwendige Parameter-
sammlung ist - mit allen Konsequenzen - das Programm selbst. F~r das Umsetzen yon vorgegebenen Parametern ist er in der Regel auf Komfort und Leistung der verwendeten Programmiersprache
angewiesen.
3. Programm~akete Das andere Extrem umfa2t die Schaffung komplexer Programmpakete. Diese
zu entwickelu lohnt immer dsnn, wenn fest umrissene Aufgaben
definlerbar sind, die mehr als einige wenige Einsatzf~lle
erwarten
lassen. Solche Aufgaben sind im Bereich der Grundaufgsbeu fur den ProzeBrechnereinsatz beispielsweise "Analogwertversrbeitung", "Ablaufsteuerung", "Textaufbereitung", "StGrungsanalyse" oder "DDC" Der Anwender w~hlt dutch Auswahl aus logischen Funktionsschematas, die den jeweiligen "Masterstapel" beschreiben,
Teilmengen zur LS-
sung seiner Probleme aus und bekommt dazu festgelegte Formulate zum
380
Sammeln der notwendigen technologischen Parameter. Die eigentliche Programmerstellung erfolgt Gber Programmgeneratoren aus dem "Masterstapel ~ und Gber Datengeneratoren. Die Form dieser Programmerstellung pr~gte den Begriff "Formularsprachen" (Bild I). Charakteristisch fur solche Programmpakete ist, dab der Anwender sich keine Gedanken ~ber Strukturen yon P r o g r a m m u n d Daten machen muB. Er w~hlt als Technologe Fu~tionen, die Realisierung interessiert ihn solange nicht, solange diese Funktionen fur ihn ausreiehen. Da Programm- und Datenstrukturen klar definiert sind, kSnnen komfortable ProzeBbedienungsprogramme geliefert werden, die Bedienungsf u ~ t i o n e n weit ~ber reine Parameter~nderungen hinaus zulassen. Dieser LSsungsweg findet in der Praxis Kritik wegen der oft zu starten Programmabl~ufe und wegen au~erordentlich begrenzter Erweiterbarkeit dutch den Anwender. Jede Anderung der betroffenen Programme bedeutet letzten Endes Eingriffe in Masterstapel, Systemgeneratoren und Bedienungsprogramme. 4. Ein Mittelwe~ Es lag nahe, nach Wegen zu suchen, die die Vorteile beider Extreme in sich vereinigen, ohne dab allzu viele Nachteile mit iu Kauf genommen werden mUssen. Im folgenden wird eiu solcher Mittelweg beschrieben. Er baut auf der Erkenntnis auf, dab im Bereich der Grundaufgaben des ProzeBrechuereinsatzes fur die on-line-Programme einige wenige Programmund Datenstrukturen den meisteu Anforderungeu Gen~ge leisten. 4.1Das
on-line-Pr0~Ea_mm
Dss logische ProgrammgerGst der on-line-Programme umfaBt dabei die Elemente Steuerprogramm, Programmbausteine und Ablaufdaten (Bild 2). Die Ablaufdaten stellen das eigentliche Anwenderprogramm dar. Primer bestehen die Ablaufdaten aus "Bsusteinaufrufen" und den zugeh~rigen Parsmetern. Dabei um£aBt der "Parametersatz" die Menge der statisch vorgebbaren Parameter, die fur einen Bausteindurchlauf benStigt werdeu. Die Anordnung der Parameter innerhalb des Parametersatzes bestimmt ausschlie~lich der Programmbaustein. Ein Wechsel yon Bausteinaufrufen und einzelnen Parameters~tzen entspricht dem Typ der "meBwertweisen" Verarbeitung, Bausteinaufrufe mit mehreren Parameters~tzen entsprechen "blockweiser" Verarbeitung.
381
Die Programmbausteine sind das wesentlichste Relikt von Modularit~tsbestrebungen. Sie l~sen teehnologische Teilfunktionen, die der Anwender zu definieren hat, und sind nach bestimmten formalen Vorschriften zu erstellen. FGr die Programmierung der Programmbausteine kGnnen jedoch eine Reihe yon Systemfunktionen Gber Makroaufrufe zur VerfUguug gestellt werden. Solche Systemfunktionen kSnnen sein: Springen in den Ablaufdaten, Abwicklung des E/A-Verkehrs auf logischer Ebene, Start-Endefunktionen, Koordlnierungsfunktioneu und dergl• mehr. Die Programmbausteine finden beim Ansprung an definierter Stelle die Adresse des aktmellen Parametersatzes. Der Zugriff zum Parametersatz erfolgt durch den Bausteiu. Das Steuerprogramm interpretiert ~un~chst die Bausteinaufrufe in den Ablaufd~kten und Gbergibt die Adresse des aktuellen Parametersatzes dem aufgerufenen Baustein. DarGber hinaus sind weitere Steuerfunktionen sinnvoll. Die Segmentierung der Ablaufdaten bei "langen" Programmen, die auf Externen Speichern hinterlegt sind ebenso wie die DurchfUhrung logischer Datenzugriffe einschlie~lich notwendiger Transferbereichsverwaltungen (z.B.: Programmresidentes "Datenpaging"). Au~erordentlich praktisch erweisen sich "Bausteinfolgen" und "Funktionen". Erstere erlauben, immer wiederkehrende Sequenzen von Bausteinaufrufen (mit jeweils neuen Parameters~tzeu) zu Makrobausteinen zusammenzufassen und als solche aufzurufen. Entsprecheude BuchfUhrungen und Steuerabl~ufe sind Leistungen des Steuerprogrammes. "Funktionen" erm~glichen die Zusammenfassung yon Abschnitten in den Ablaufdaten aus technoligischer Sicht mit der M~glichkeit, sie aufzurufen (Einschleifwirkung wie bei einem Unterprogramm) oder zu starten (Sporadische Verarbeitung yon Teilabschnitten). 4.2 Notation und Generierun~ yon on-line-Pro~rammen Die im vorhergehenden Abschnitt beispielhaft angedeutete Definition yon Grundfunktionen und on-line-Programmstrukturen darf den Anwender bei Formulierung seines Problemes nieht belasten. Dies kann nmr verhindert werden, wenn ihm eine "Sprache" zur VerfGgung gestellt wird, die folgende wesentliche, auf das System bezogene Leistungen vermittelt (Bild 3): • Auswahl yon Steuerfunktionen, • Einbr±ngen "eigener" Programmbausteine, • Formale Beschreibung der bausteinbezogenen Parameters~tze,
382
. Formulierung
des Programmes
. Unterst~tzung
(Ablaufdaten
!) und
bei der Umsetzung yon vorgegebenen
in den Parameters~tzen
erforderliche
Form
Parametern
in die
(auch algorithmisch)
zur Generierzeit. Ein zugeh~riger
Systemgenerator
es beeinflussen
kann,
erzeugt
immer "gleiche"
dann, ohne da~ der Anwender
on-line-Programmstrukturen.
4.3 Bedienun~. yon on-line-Pro~rammen Die eindeutig definierten das Programmes
normierte
gen, die das generierte kann eiue Bibliothek werden,
. Ermittlung
BuchfUhrungen
seien folgende
. Definition
Funktionen
Bausteinaufrufe
genannt:
in den Ablaufdaten in den Ablaufdaten
yon Bausteinaufrufen
yon Bausteinaufrufen
tererkl~rungen
(Reihenfolge
der Bearbeitung)
stelle und einen Zentralteil, den Programm durchf~hrt, Strukturen,
Bedienungsaufgaben
beider
im Aufbau
in einen ger~te-
eine programminterne welcher
die Eingriffe
so ist erkennbar, BuchfUhrungen
erhebliche
rung yon Zentralteileu
im zu bedienen-
dab durch die vorpro-
und Programmbausteine
Erleichterungen
zu erwarten
Bedienungsnaht-
beider
fur
Programmie-
sind.
Dateq~ener~eEBB~
Lle~e man es im Bereich der Programmnotatlon
bei einer
angedeuteten
UnterstUtzung
Handling
Parame-
und ~hnliche.
Ein-/Ausgabeteil,
4.4 Hilfsmittel
in den Ablaufdaten
aufgrund yon bausteinspezifischen
Gliedert man Proze~bedienungsprogramme
grammierten
kenneu und Mauipulationen
yon Bausteinfolgen
. Konvertierungsroutinen
orientierten
gestellt
solcher Programmbausteine
• Aufbau und LSschen yon Bausteinaufrufen . Rangierung
zur Verf~gung
aus Satznamen
. Eintragen und Lesen yon Parametern . "Ein- und Ausschalten"
zu erzeu-
Darauf aufbauend
Aufgaben yon Prose~bedienungsprogrammen.
yon Satznummern
. Suchen bestimmter
und Namenslisten
Die Funktionen
sich aus modularen
es, beim Generieren
"beschreiben".
yon Programmbausteineu
ermGglichen.
Beispielsweise
erlauben
BuchfGhrungen Programm
die diese normierten
im Programm ergeben
Strukturen
Sinne bewenden,
wGrde keinerlei
bei groBen Parametermengen
vorhanden
sein;
"Sprache"
fur das
das Programm
selbst w~re mit allen Nachteilen die formlose "Parametersammlung". Jeder Anwendungsfall w~rde zumindest ein neuerliches 0odieren des gesamten Programmes
erforderlich
machen.
im
383
An dieser Stelle lassen sich Mittel zur Beschreibung yon Formularen und MeBstellenbl~ttern sowie Zugriffsfunktionen, die zur Generierzeit die 0bertragung yon Parametern aus den Formularen in das Programm erm~glichen, definieren (Bild 4). Im Prinzip wird dabei ein Formular Gber Zeilen und Spalten definiert. Eine "einfache" Zugriffsfunktion erm6glicht im Programm anstelle der Parameter eines Bausteinaufrufes einen Verweis auf ein Element (Zeilenname, Spaltenname) eines Formulares. Eine "komplexere" Zugriffsfunktion erlaubt die Definition einer Zeilengruppe (zeilenname bis zeilenname) und die Anwendung der "einfachen" Zugriffsfunktion fGr jede Zeile der Zeilengruppe. Im stark vereinfachten Beispiel in Bild 4 fUhrt dies dazu, dab beim Generieren des Programmes der Bausteinaufruf fur jede Zeile des Formulares abgesetzt wird. Das Schema in Bild 4 l~Bt erkennen, dab auf diese Weise theoretisch die vollkommene Entkopplung eines einmal geschriebenen Programmes von den in Formularen sammelbaren Parametern erreicht werden kann und darGber hinaus auch die Auswahl yon Programmfunktionen aus einem "Masterprogramm" mSglich wird (Einfacher Zugriffsalgorithmus: Bausteinaufrufe werden nut dann abgesetzt, wenn alle formalen Parameter vorgegeben sind). 5. Abschlie~ende Bemerkungen Der angedeutete Weg zur rationelleren Anwendersoftwareerstellung l ~ t die gesamte Bandbreite von rein modularer Technik bis hin zu starren~ generierbaren Programmpaketen mit immer gleichen, logischen Grundstrukturen bestreichen. Die erzeugten Programme sind in ihrem Aufbau, ihrer ~uBeren Form und in der Handhabung einander ~hnlich~ was auf lange Sicht auch eine Senkung von Test- und Inbetriebnahmeaufwand erwarten l ~ t . Zur Zeit werden aufbauend auf diesem Weg fur die Siemens-ProzeBrechner 320/330 eine Reihe flexibler, technologisch orientierter Anwenderprogrammsysteme erstellt. Zur Notation und Realisierung der Generierprobleme hat sich die Makrosprache dieser Proze~rechner als leistungsf~hige Basis erwiesen.
384 Funktionsauswahl
!
Datensammlung Ob.Grenze SPGI 25 200.0 STR7 137 125.5
Name Nr~
o
v
V D
FUNC7 ..... \ JFUNC4 \1
FUNC3 ~
ListenGenerator o
IIProgramm- . . . . ~
J I Code ~
~DaDaten~
Q
• •
@
•~
MasterStapel Bild1:Handhabungvon Programmpaketen/ Formularsprachen
~o
Assembler
ladbares~I Programm
385
Interpreter Daten auf Peripherspeicher
Steuermodule
E/A-Treiber
o
BuchfGhrungen (Bausteinfolgen, Funktionen, ) Hilfsspeicher
Transferpuffer
Anwenderbaustein BI
f
Ablaufdaten auf Peripherspeicher
LAufruf B1 Parame~er--satz zu a
Anwenderbaustein B2
Transferbereich
i
wertwei se
Aufruf B2 P__arametersatzl zu b__ blockweise Parametersatz2 zu b Parametersatz3 zu b Verarbeitung
fGr aktuelle Ablaufdaten
Bild2 : Grundstruktur der "online"-Programme
SPROGRAMM" name "l~ng e" segment i erung" ..... ;
Bild 3 : N o t a t i o n s s c h e m a
SPROGRAMMENDE;
der P r o g r a m m e
p a r k l n " p a r k 2 n " ..... / ;
S B A U S T E I N A U F R U F " B - n a m e k " p a r k l I "park21 " .... / / park12"park22".
S B A U S T E I N A U F R U F " B-namei "pari I "pari2", o. / ;
SHILFSSPEICHER"I~nge ;
S T R A N S F E R B E R E I C H " dat einame I "pufferbereichl 1
S B A U S T E I N D E F I N I T I O N " B - n a m e l "paramet e r e r k l ~ r u n g e n " . . . "/ "befehlsfolge ;
$ S T E U E R F U N K T I O N 2 " ..... ;
$STEUERFUNKTION1 "par"... ;
Anwenderprogramm
I
Definitionsbereich
(DO
2223
28
Bild4 / Teil I:
Formulardefinition und Formularzugriff
SBAUSTEINAUFRUF"BI"$FORMULARZUGRIFF"MESSWERTI"sp-name2;/; $BAUSTEUNAUFRUF"B2~$~EILENGRUPPENZUGRIFF~G-name~($FORMULA~ZUGRIFF"~sp-name2;/);; $~EILENGRUPPENZUGR~FF~ZG-name"($BAUSTEINAUFRUF~B3~$F~RMULARZUGRIFF""sp-name3;/; SBAUSTEINAUFRUF"B4"$FORMULARZUGRIFF""sp-name4;/;);
$PROGRAMM" .... ;
SZEILENGRUPPENDEFINITION"ZG-name"MESSWERTI"MESSWERTn!
parn3 I
par12 Ipar13 ' par22 ipar23
MESSWERTnj !arnl parn2
MESSWERTI ~rJl MESSWERT2,ar21
SFORMULAR"F-name; 1011 ~617
A
i
s.a.
Teil2
SFORMULARDEF INIT ION"F-name" sp-name I :I- I0" sp-name2 :11 - 16"sp-name 3 :17- 22" sp-name4 :23- 28 ;
k~
--------*
"generiert" Gber Formularinhalt
Formularinhalt
im Programm:
"generlert"Hber
entsprechend Teil I
wertweise Verarbeitung
blockweise Verarbeitung
einfacher Zugriff
Bild 4 / Teil 2 : Ergebnis aus Formularzugriff
SBAUSTEI NAUFRUF" B 3 "p a rn2 / ; SBAUSTEINAUFRUF" B4"parn3 / ;
SBAUSTEINAUFRUF"B4"par 13/; SBAUSTEINAUFRUF"B3" par22 / ; SBAUSTEINAUFRUF" B4"par23/;
parnl / ; SBAUSTEINAUFRUF"B3"parl2 / ;
SBAUSTEINAUFRUF" BI "parl 1 / ; SBAUSTEINAUFRUF"B2"par par21 11 ~ ]
Der markierte Bereich aus Teil I ergibt logisch folgende Aufrufkette
co
PROGRAMMIEREN VON PROZESSDATENBANKEN MIT ADRESS-VARIABLEN Volkmar Kussl
1. Leistung und Abgrenzung Informationssysteme beschreiben die Eigenschaften und Beziehungen von Objekten. ProzeBdatenbanken sind eine besondere Form der Informationssysteme, in denen die Objekte rasch Eigenschaften und Beziehungen ver~ndern. Der Umfang der ProzeBdatenbanken i s t ebenfalls starken Schwankungen unterworfen (Belegungsschwankungen der ProzeBstrecke). ProzeBdatenbanken sind bei StUckprozessen (Fertigungssteuerung, BearbeitungsstraBen, Hochregallagern und Transportstrecken, ZUgen und Bahnen, Auskunftssystemen usw.) von Bedeutung. Die Dienstleistungen
einer Datenbank sind:
a) Abschnittsverrechnung (Antwort auf die Frage: Welche Objekte befinden sich im Abschnitt X?), b) EinzelstUckverfolgung (Antwort auf die Frage: In welchem Abschnitt und in welchem Zustand befindet sich das EinzelstUck Y?). c) Beziehungsermittlung (Antwort auf die Frage: Welche EinzelstUcke und Werksauftr~ge geh~ren zu dem Kundenauftrag Z?). d) Organisation yon Warteschlangen mit variabler P r i o r i t ~ t der Objekte (Verwaltung des Stau~ vor Fertigungsmaschinen, Zugriffsregelung zu Date~en usw.). e) Suchen yon Objekten vorgegebener Eigenschaften (z.B. Lagerfach der GreBe A mit Fl~chenbelastung K in Giftzone). f) Reorganisation (Zusammenschieben von Lagerbest~nden oder Dateien). Adress-Variable (indirekte Adressierung) erlauben eine wirtschaftliche und anschauliche Programmierung. Das Hin- und Herbewegen von Dateien im Rechner oder auf externen Speichern e n t f ~ l l t . Zeit und Raum kann in erheblichem Umfang eingespart werden. Die indirekte Adressierung i s t nur im Assembler und dann in den hochorgani'sierten Programmiersprachen wie PL/I und ALGOL 68 m~glich (nicht jedoch in FORTRAN oder ALGOL 60). In ALGOL 68 wird die indirekte Adressierung Uber Variable zur Referenzstufe 2 r e a l i s i e r t . In dieser Arbeit wird jedoch PL/I benutzt, da fur den Referenten der PL/I-checkout- und optimizing-Compiler zug~nglich i s t . Alle hier erl~uterten Programmelemente wurden an der TSO-Datenstation entwickelt und im Simulationsbetrieb getestet.
390
2. Objektvektoren Die geeignete Organisationsform einer ProzeBdatenbank i s t die Gliederung in Objektvektoren. Jedem StUck (Objekt) in der ProzeBstrecke wird ein Objektvektor in der Datenbank zugeordnet. Der Objektvektor enth~It a) Eigenschaftsdaten (Stammdaten, Bestandsdaten und Bewegungsdaten), b) Beziehungsdaten (Bezugszeiger oder Beziehungszeiger usw.). Die Eigenschaftsdaten nennen die inh~renten Eigenschaften eines Objekts, die Beziehungsdaten die Relation oder Verbindung zu anderen Objekten. Ein Objektvektor wird zweckm~Big als PL/I-Struktur der Speicher-Zuteilungsklasse BASED vereinbart (BASED-Variable). Speicherplatz fur jeden Objektvektor wird im Arbeitsspeicher (ASP) erst dann zugewiesen, wenn das Objekt entsteht und in die Datenbank e i n t r i t t (Anweisung ALLOCATION, ALLOC). Verschwindet das Objekt (z.B. Teilung in Scheren, Montage oder Lieferung), so wird der Speicherplatz wieder freigegeben (Anweisung FREE). Zu jeder Datengeneration einer BASED-Variablen kann zugegriffen werden. BASED-Variable sind im ASP verschiebbar (Kettung an Zeigervariable). 3. Zeigervariable Es i s t zweckm~Big, die Eigenschaftsdaten als Variable zur Referenzstufe 1, die Beziehungsdaten als Variable zur Referenzstufe 2 (Zeiger, Attribut POINTER, PTR) zu vereinbaren. Um diese beiden Klassen von Daten besser zu unterscheiden, erhalten Zeiger einen Namen, der mit zwei gleichen Buchstaben beginnt (z.B. ZZ). Zeiger haben Adressen (yon Eigenschaftsdaten oder von Beziehungsdaten) zum Inhalt. Zeigern werden wie folgt Werte zugewiesen: a) AdressenUbergabe mit der Standardfunktion ADDR (z.B. PP : ADDR(P); dem Zeiger PP wird die Adresse von P Ubergeben, man sagt PP zeigt auf P. b) Wertzuweisung Uber die SET-Option der Speicherplatzzuweisung (z.B. ALLOC BV SET(QQ); der BASED-Variablen BV wird Speicherplatz im ASP zugewiesen, die Adresse des zugewiesenen Speicherplatzes wird im Zeiger QQ hinterlegt), c) Adressen-Kopieren Uber Ergibtanweisungen (z.B. KK = PP; der Inhalt yon PP ~ird aucb Inhalt yon KK. PP und KK zeigen dann auf dieselbe Variable, z.B. P). d) NULL-Anweisung (z.B. PP = NULL; der Zeiger PP i s t "stumpf").
39~
Hat ein Zeiger eine Adresse zum Inhalt, dann d e f i n i e r t er einen bestimmten Ort im ASP. Auf diesen Speicherplatz kann nun mit dem Pfeil-Operator "->" eine BASED-Variable geschoben werden. Die Formel PP->BV l i e f e r t den Inhalt der BASED-Variablen BV an der S t e l l e , deren Adresse der Zeiger PP e n t h ~ I t ; man sagt kurz: " I n h a l t yon BV an der S t e l l e PP".
"ADDR" und "->" sind damit reziprook. Mit "ADDR" wird einem Zeiger die Adresse einer beliebigen Variablen Ubergeben, mit dem P f e i l (arrow) "->" wird eine verschiebbare Variable (BASED-Variable) an eine S t e l l e im A r b e i t s s p e i c h e r geschoben, die durch einen Zeiger bestimmt i s t . 4. Organisation v e r z e i g e r t e r Datenbanken Das S k e l e t t der ProzeBdatenbank sind die Beziehungen j e k t e n , w i t unterscheiden: a) b) c)
zwischen den Ob-
Sternnetz-Beziehungen ( S t e r n s t r e c k e n ) , LIFO- ( l a s t in f i r s t out) Beziehungen (LIFO-Strecken) und FIFO- ( f i r s t in f i r s t out) Beziehungen (FIFO-Strecken).
Die Beziehungen der Objekte werden durch die Verzeigerung der Objektvektoren programmtechnisch d a r g e s t e l l t : Ausgangspunkt einer Verzeigerung i s t der Ankerzeiger (Head). Der Bezugszeiger eines Objektvektors verweist ( d e u t e t ) a u f das folgende Objekt. Der Bezugszeiger am Ende einer verzeigerten Strecke (Kette) e n t h ~ I t den Wert NULL. Die Verzeigerungsarten sind: a) b) c)
Ein--Bahn-Verzeigerung, Zwei-Bahn-Verzeigerung und Ein-Bahn-Verzeigerung mit Suchalgorithmen.
Die Ein-Bahn-Verzeigerung mit Suchalgorithmen a n s t e l l e der Gegenbahn i s t w i r t s c h a f t l i c h e r und anschaulicher als die Zwei-Bahn-Verzeigerung. Andert ein Objekt in der ProzeBstrecke seinen Ort ( S t e l l e , Lagerfach), so wird in der ProzeBdatenbank nur die Verzeigerung ge~ndert (Umh~ngen an einen anderen Anker), n i c h t jedoch der Speicherplatz des zum Objekt geh~rigen Objektvektors
(wichtiger
s t r a t e g i s c h e r Grundsatz).
5, Datenbank-Algorithmen 5.1, Grundalgorithmen Alles Geschehen in ProzeBdatenbanken s e t z t sich aus wenigen Grundalgorithmen zusammen, die durch normierte und m o d i f i z i e r b a r e Programm-Module zusammengesetzt werden k~nnen.
392 Diese Grundalgorithmen werden an einem reduzierten 0bjektvektor vorgefUhrt: 00040 00050 00060 00070 00080 00090 00100 00110 00120 00130 00140 00150 00160
DCL 10BJ BASED / * OBJEKTVEKTOR * / , 2 EIFEL CflAR(3), / * EIGENSCHAFTSFELD */ 2 LL POINTER / * BEZIEHUNGS-ZEIGER * / ; DCL / * LIFO - STRECKE : */ / * ANKERZEIGER : * / qql POINTER INIT (NULL), / * STUECKZAHL: * / Z1 BIN FIXED(15) INIT (1); DCL / * FIFO - STRECKE : * / / * ANKERZEIGER : * / QQ2 POINTER INIT (NULL), / * STUEKZAHL: , / Z2 BIN FIXED(15) INIT (1); DCL / * HILFSZEIGER: , / (QQ, FF) POINTER, (NULL, TIME) BUILTIN; DCL / * HOECHST-STUECKZAHLEN : , / (HZ1, HZ2) BIN FIXED(15);
Die Sternstrecken sind ein einfacher Sonderfall der LIF0- und FIF0Strecken:
Sternpunkt i s t ein Ankerzeigerbereich (DCL AA(N) POINTER;
N ::= Anzahl der Zweige des Sterns). 5.1.1. Eingabealgorithmen Eingaben in die LIF0-Strecke 00730 00740 00750 00760 007'70 00780 00790 00800 00810 00820
ZIEL(3): LIFOEIN: IF Z1 > HZI THEN BEGIN; PUT FILE(SYSPRINT) LIST ('UEBERBELEGT') SKIP; GOTORUHE; END; ALLOC OBJ SET(QQ); QQ->OBJ.LL : QQ1; QQ1 : QQ; PUT FILE(SYSPRINT) LIST ( 'GEBEN SlE WERT EIN')SKIP; GET FILE(SYSIN) LIST (QQ->OBJ.EIFEL); Z1 : ZI + I ;
Im Kernteil des ProgrammstUckes wird (in 760) dem neuen 0bjekt Speicherplatz zugewiesen, die Adresse wird in QQ h i n t e r l e g t . In 770 wird die Verzeigerung e r w e i t e r t : der Bezugszeiger LL des neuen 0bjektes zeigt nun auf das Folgeobjekt. In 780 wird der Ankerzeiger auf das neue 0bjekt g e s t e l l t . Dadurch zeigt der Ankerzeiger stets auf das zuerst auszugebende Objekt. Diese Vereinbarung g i l t FIFO-Strecke.
ab hier sowohl fur die LIF0- als auch fur die
Eingabe in die FIF0-Strecke Nach Platzzuweisung und AdressenUbergabe (890) wird das neue 0bjekt als l e t z t e s markiert (900). I s , die Strecke leer (QQ2=NULL), so wird l e d i g l i c h die Adresse des H i l f s z e i g e r s QQ vom Anker QQ2 Ubernommen. Im anderen Fall (ELSE-Zweig) mu~ erst das l e t z t e Objekt der Strecke ge-
393
00860 00870 00880 00890 00900 00910 00920 00930 00940 00950 00960 00970
00980 00990
ZIEL(4): ~IFOEIN: IF Z2 > HZ2 THEN BEGIN; PUT FILE(SYSPRINT) LIST ('UEBERBELEGT')SKIP; GOTO RUHE; END; ALLOC OBJ SET(qQ)~ QQ->OBJ.LL = NULL; IF QQ2=NULL THEN QQ2 = QQ; ELSE DO; FF = QQ2; DO WHILE(FF->OBJ.LL ~= NULL); FF = FF->OBJ.LL; END; FF->OBJ.LL =QQ; END; PUT FILE(SYSPRINT) LIST( 'GEBEN SIE WERT EINV)SKIP; GET FILE(SYSIN) LIST(QQ->OBJ.EIFEL); Z2 : Z2 + 1;
sucht werden (920 bis 930). Zu Beginn der Anweisung 940 z e i g t FF auf das b i s h e r l e t z t e Objekt. In 940 Ubernimmt der Bezugszeiger des b i s h e r l e t z t e n Objektes (der b i s h e r NULL war) die Adresse des neuen Objektes. 5 . 1 . 2 . Ausgabealgorithmen Da vereinbarungsgem~B der Ankerzeiger s t e t s auf das auszugebende Objekt z e i g t , sind die Ausgabeprozeduren f u r a l l e Strecken g l e i c h . Wir k~nnen uns deshalb auf die Ausgabe der LIFO-Strecke beschr~nken. 01240 01250 01260
Z I E L ( 6 ) : LIFAUS: / * AUSGABE AUS LIFO-STRECKE * / IF QQI:NULL THEN DO; PUT FILE(SYSPR|NT) LIST('LIFO-STRECKE IST LEER')SKIP;
01270 01280 01290 01300 01310 01320
GOTO RUHE; END; QQ = QQ1; QQ1 = QQI->OBJ.LL; PUT FILE(SYSPRINT) EDIT( 'AUSGABEAUS LIFO-STRECKE: ' , QQ->OBJ.EIFEL)(SKIP, A,A); FREE QQ->OBJ; Z1 = Z1 - 1; GOTO RUHE;
Der Wert vom Ankerzeiger QQ1 wird an den H i l f s z e i g e r QQ Ubergeben (1280). Dann wird der Ankerzeiger QQ1 auf das dem auszugebenden Objekt f o l g e n de Objekt g e s t e l l t (1290). J e t z t kann das an QQ h~ngende Objekt ausgegeben werden (1310). Anschlie~end wird der S p e i c h e r p l a t z des auszugebenden Objekts
freigegeben.
5 . 1 . 3 . Ablaufen e i n e r v e r z e i g e r t e n Strecke. KernstUck eines jeden L a u f - A l g o r i t h m u s entlang e i n e r v e r z e i g e r t e n S t r e k ke i s t eine Wiederholungsanweisung (DO-Schleife) mit e i n e r Verweilbedingung (WHILE-Option). Ein F o r t s c h a l t e z e i g e r weisung
FF ( L a u f z e i g e r )
erh~It
vonder
Fortschaltean-
FF = FF->0BJ.LL; einen neuen Wert, er z e i g t dann auf das folgende 0 b j e k t . Der L a u f z e i g e r FF wird zu Beginn an den Anfang der abzulaufenden Strecke g e s t e l l t . Da
394 das Ablaufen einer leeren Strecke sinnlos i s t , NULL fur den Laufzeiger verboten. weder a) eine 0bjekteigenschaft oder
i s t der Anfangswert
Die Verweilbedingung b e t r i f f t ent-
b) eine 0bjektbeziehung. Die Verweilbedingung der D0-Schleife hat die Form: WHILE(verweilargument ~= endekriterium); I s t das Endekriterium eine 0bjektbeziehung, dann sind zwei F~lle zu unterscheiden: a) Endemarke (NULL) einer verzeigerten Strecke oder b) Adresse einer Zwischenstelle (z.B. ADDR(GEG) oder ein Zeiger, z.B. FF2 als Knotenpunkt innerhalb vermaschter Strecken. 5.2. Zusammengesetzte und ab~eleitete Al~orithmen 5.2.1. Suchen eines Kriteriums Um ein 0bjekt mit einem bestimmten Kriterium zu suchen, i s t eine verzeigerte Strecke abzulaufen. Das l e t z t e 0bjekt des Laufalgorithmus i s t das gesuchte Objekt. Der Laufzeiger muB deshalb bei diesem 0bjekt stehen bleiben. Die Verweilbedingung hat deshalb die Form WHILE(FF->0BJ.EIFEL~=KRIT);KRIT ::= gesuchtes Kriterium, oder WHILE(FF->0BJ.LL~=NULL); z.B.: Suchen des letzten Objektes einer FIFOStrecke zur Eingabe, Anweisung 930. Folgendes ProgrammstUck i s t ein Beispiel fur eine Objekteigenschaft als Verweilargument. 01020 ZlEL(5): SUKRIT: / * SUCHEN NACH KRITERIUM IN LIFO-STRECKE */ 01030 FF = QQ1; 01040 IF FF=NULL THEN DO; 01050 PUT FILE(SYSPRINT) LIST(WSTRECKE LEER~)SKIP; 01060 GOTO RUHE; 01070 END; 01080 DCL SZ / * PLATZZAHL * / BIN FIXED(15)s 01090 KRIT / * SUCHKRITERIUM */ CHAR(3); 01100 PUT FILE(SYSPRINT) LIST ( 01110 'GEBENSlE SUCHKRITERIUM EIN')SKIP; 01120 GET FILE(SYSIN) LIST (KRIT); 01130 DO SZ=I BY 1 WHILE(FF->OBJ.EIFEL ~= KRIT); 01140 FF = FF->OBJ.LL; 01150 IF FF=NULL THEN DO; PUT FILE(SYSPRINT) EDIT( 01160 'STUECKMIT DEN SUCHKRITERIUM ' , KRITt ' NICHT VORHANDENt)(SKIPt3(A)); 01170 GOTORUHE; END; 01180 END; 01190 PUT FILE(SYSPRINT) EDIT( 01200 'STUECKMIT DE~4 SUCHKRITERIUM 's FF->OBJ.EIFELt 01210 ' IST AN ' , SZt ' . STELLE VORHANDEN')(SKIP, 3(A)t F(3), A);
395
5,2.2, Soll
Gekettete Verarbeitungen
jedes 0 b j e k t
in e i n e r v e r z e i g e r t e n Kette v e r a r b e i t e t
(Streckenberichte, ist
B e a r b e i t e n der 0 b j e k t e ,
wieder der L a u f - A l g o r i t h m u s z u s t ~ n d i g .
verarbeitet
werden
Strukturver~nderungen), Da auch das l e t z t e
werden muB, mu5 der L a u f z e i g e r h i n t e r
dem l e t z t e n
so
0bjekt 0bjekt
zur Ruhe kommen. Die V e r w e i l b e d i n g u n g hat deshalb die Form: WHILE(FF~=NULL);
Betspta] etner g e k e t t e t e n Verarbeitung: Z I E L ( 2 ) : F]FBERZ PUT FILE(SYSPRINT) EDIT( 'STRECKENBERICHT FIFO-STRECKE',
00590 00600 00610 00620 00630
00640 00650 00660 00670 00680 00690 00700 5.2.3.
'STUECK-NR. WERT')(SKIP, A); IF QQ2:NULL THEN DO; PUT FILE(SYSPRINT) LIST( 'ABSCHNITT LEER')SKIP; GOTO RUHE; END; ELSE DO; FF : QQ2; DO I=1 BY 1 WHILE(FF ~ : NULL); PUT FILE(SYSPRINT) EDIT( I , FF->OBd. EIFEL)(SKIP, X(4), F ( 3 ) , X(13), A ) ; FF = FF->OBd. LL; END; PUT FILE(SYSPRINT) EDIT('ENDE BERICHT ' , TIME)(SKIP, A, A ( 4 ) ) ; Streckenwechsel
Andert ein 0 b j e k t
die P o s i t i o n ,
dann i s t
ein Eingabe- und ein Ausgabe-
A l g o r i t h m u s h i n t e r e i n a n d e r z u s c h a l t e n . Die ALLOC- und FREE-Anweisungen entfal~en. 00530 005~0. 00550 00560 00570 00580 00590 00600 00610 00620
STREWE: PROC; / * UNTERPROGRANH STRECKENWECHSEL * / IF QQ1 = NULL THEN DO; PUT FILE(SYSPRINT) LIST ( 'STRECKE ST1 IST LEER') SKIP; GOTO AUS; END; IF ZAST2 > 8 THEN DO; PUT FILE(SYSPRINT) LIST ( 'ST2 tST UEBERBELEGTV)SKIP; GOTO AUS; END; IF QQ2 = NULL THEN QQ2 = QQ1; ELSE DO; / * PHASE 1: * / QQ = QQ2; DO WHILE( QQ->OBJ.LL ~= NULL); QQ = QQ->OBd. LL; END; / * PHASE 2: * / QQ->OBJ.LL = QQ1; END; / * PHASE 3: * / QQ = QQI->OBJ.LL; QQI->OBJ.LL = NULL; QQ1 = QQ; ZAST1 : ZAST1 - 1; ZAST2 = ZAST2 + 1; AUS: EMD;
00630 00640 00650
5.3.
Invertierte
5.3.1,
Dateien
Bedeutung und Vereinbarung
Die E i g e n s c h a f t e n eines 0 b j e k t e s mUssen w i r in a) i n d i v i d u e l l e b) k o l l e k t i v e trennen. Individuelle
E i g e n s c h a f t e n und Eigenschaften
E i g e n s c h a f t e n s i n d e i n m a l i g oder s e l t e n .
s c h a f t e n sind v i e l e n Objekten gemeinsam. Es i s t kollektiven
E i g e n s c h a f t e n nut einmal
vektor wird d i e k o l l e k t i v e
(zentral)
Kollektive
Eigen-
nun w i r t s c h a f t l i c h , zu s p e i c h e r n ,
E i g e n s c h a f t durch einen Z e i g e r v e r t r e t e n .
Auf e i n e k o l l e k t ~ v e E i g e n s c h a f t zeigen dann a l l e
die
Im O b j e k t -
Eigenschaftszeiger
396
(z.B. Kundenzeiger, Werksauftragszeiger) der betroffenen 0bjektvektoten ( B i l d ) .
ITITN
TT (2) ~ . . ~
TT(~)1 "]
KNN KN
KN(2)
KN(2}
WN{I) WN
WN(2/
WN(3]
INVERTIERTE DATEI Neben der Vereinbarung des 0bjektvektors 00090 DCL 10BJ BASED, / * OBJEKTVEKTOR * / 00100 2 EIFEL, / * EIGENSCHAFTSFELD * / 00110 3 INEIG CHAR(3), / * INDIVIDUELLE EIGENSCHAFTEN */ 00120 3 KOLEIGo / * KOLLEKTIVE EIGENSCHAFTEN * / 00130 4 KK POINTER, / * KUNDENZEIGER */ 00140 4 WW POINTER, / * WERKSAUFTRAGSZEIGER * / 00150 2 LL POINTER; / * BEZIEHUNGSZEIGER * / sind zus~tzlich die k o l l e k t i v e n Eigenschaften als Bereiche zu vereinbaren. 00170 00180 00190 00200 00210 00220 00230 002~0 00250 00260
/ * WERTE DER KOLLEKTIVEN EIGENSCHAFTEN : * / DCL (-KN(3) / * KUNDEN-NUMMER * / INIT(WK1~, tK21, ' K 3 ' ) , WN(3) / * WERKSAUFTRAGS-NUMMERN * / INIT('WI', tW2 e, IW31))CHAR(2); / * OBJEKT-DATEN : * / DCL #FS / * FERTIGUNGSSTELLE * / BIN FIXED(15), #1NEIG CHAR (3), / * INDIVIDUELLE EIGENSCHAFT * / (#KN / * KUNDEN-NR * / , #WN / * WERKSAUFTRAGS-NR. * / ) CHAR(2); DCL MASKE CHAR(2) BASED; OBZL = 0; DCL OBZL(3) / * OBJEKTZAEHLER * / BIN FIXED(15);
5.3.2. Eingabe in d!e Datei ..... Die Verzeigerung des 0bjektvektors mud nun a u f g e t e i l t werden in die Wertzuweisung fur den Beziehungszeiger (Anweisung 740 bis 790) und in d~e Verzeigerung der Kollektiv-Eigenschaften (Anweisung 820 bis 870). Zur Verzeigerung der Kollektivdaten i s t zun~chst der Index fur den
397
i n d i z i e r t e n Namen zu e r m i t t e l n (Anweisung 830 und 860). Dann kann die Adresse der zentral gespeicherten Kollektiv-Eigenschaft vom K o l l e k t i v Zeiger Ubernommen werden (Anweisung 840 und 870). 00740 00750 00760 00770 00780 00790 00800 00810 00820 00850 00840 00850 00860 00870 00880 5.3.3.
FIFOEIN: ALLOC OBJ SET(QQ); QQ->OBJ.LL = NULL; IF TT(#FS)=NULL THEN TT(#FS) = QQ; ELSE DO; FF = TT(#FS); DO WHILE(FF->OBJ.LL ~= NULL); FF = FF->OBJ.LL; END; FF->OBJ.LL=QQ; END; / , WERTUEBERNAHME: * / QQ->OBJ.INEIG = #1NEIG; / * VERZEIGERUNG DER KUNDEN-NR. UND WERKSAUFTR. NR. * / DO Z=I BY 1 WHILE(#KN ~= KN(Z)); END; QQ->OBJ.KK = ADDR(KN(Z)); DO Z=I BY 1 WHILE(#WN ~= WN(Z)); END; QQ->OBJ.WW = ADDR(WN(Z)); OBZL(#FS) = OBZL(#FS) + 1; Suchen von 0bjekten mit gegebenen Kollektiv-Eigenschaften
Es sollen a l l e 0bjekte a u f g e l i s t e t werden, die zu einer bestimmten Kollektiveigenschaft geh~ren, z.B. a l l e 0bjekte mit der gleichen Kunden-Nummer. Mittelpunkt fur diesen Algorithmus (Anweisung 1000) i s t eine Maske (MASKE) gekettet an den K o l l e k t i v z e i g e r (KK). I s t der I n h a l t dieser Maske - die einem Element der K o l l e k t i v - D a t e i U b e r l a g e ~ i s t - gleich dem eingelesenen Kriterium (Anweisung 950), so geh~rt das Objekt zur Menge der 0bjekte mit der gesuchten Kollektiv-Eigenschaft. Das Objekt mit dem Zeiger KK, wird selbst wieder durch einen H i l f s zeiger QQ ausgew~hlt. Der I n h a l t des H i l f s z e i g e r s QQ wird in einer Wiederholungsanweisung fortwShrend verSndert, so dab er die verketteten 0bjekte der Reihe nach abl~uft. Die Maske springt dann yon Kollektiv-Eigenschaft zu K o l l e k t i v Eigenschaft. 00930 ZIEL(2): SUEK: PUT FILE(SYSPRINT) LIST( 00940 00950 00960 00970 00980 00990 01000 01010 01020 01050 01040 01050 01060 01070
' GEBEN SIE KUNDEN-NR. EIN')SKIP; GET FILE(SYSIN) LIST (#KN); PUT FILE(SYSPRINT) EDIT( 'FERTIGUNGSORT LFMR. EIGENSCH WERKSAUFTRAG')(SKIP, A); DO I=I BY 1 TO 3;
QQ = TT(1); Z = 1; DO d=l BY 1 WHILE(QQ ~= NULL); IF QQ->OBJ.KK->MASKE : #.KN THEN DO; PUT FILE(SYSPRINT) EDIT( I , Z, QQ->OBJ.INEIG, QQ->OBJ.WW->MASKE)(SKIP, F(7), X(8), F(2), X(6), A, X(6),A); Z=Z+I; END; QQ = QQ->OBJ.LL; END; END; PUT FILE(SYSPRINT) EDIT('ENDE BERICHT ' , TIME)(SKIP,A,A(4));
398 6. Datenbanken auf Externspeichern 6.1. Bedeutung und Abgrenzung Eine Datenbank besteht aus: a) Bankprozeduren (Eingabeversuch, Ausgabeversuch, Streckenwechsel), b) Bankdaten (Nutzdaten, Verwaltungsdaten). Wenn es die ProzeBsituation verlangt, muB dauernd die geschlossene Datenbank (Prozeduren und Daten) im ASP resident sein. Oft kann jedoch die Datenbank auf den Externspeicher (ESP) ausgelagert werden. Zwischen diesen beiden Extremen sind viele Arten m~glich. FUr die Wahl der programmtechnischen Mittel sind jedoch zwei Verfahren entscheidend: a) Pendelnde Bankdaten und b) V e r t e i l t e Bankdaten. Ist die ganze Datenbank oder zumindest Teile der Datenbank auf dem ESP, und werden sie nur zur Bankprozedur in den ASP geholt, so spricht man von pendelnden Bankdaten. Bei v e r t e i l t e n Datenbanken i s t ein repr~sentativer Tell dauernd im ASP, der Rest dauernd auf dem ESP (im ASP i s t nur die Spitze eines Eisberges). Im Bedarfsfall wird von der ESP-Datei ein ausgew~hlter Satz in den ASP geholt. 6.2. Pendelnde Bankdaten Das Pendeln der Datenbanken i s t gefahrlos, wenn sie keine Zeiger (POINTER) enthalten. Kehren verzeigerte Bankdaten, die mit der ALLOCAnweisung im ASP aufgebaut wurden, wieder in den ASP zurUck, so wird ihnen vom Betriebssystem meist nicht mehr der alte Platz in der ASPLandschaft zugewiesen. Die absoluten Adressen der Zeiger sind damit
falsch. ESP
ASP DA TEl ...............
it:
~
1 l
!! I
> m I
I, I I
Zeit t2:
t
DA TEl
]>
/
/ / / /
/ /I
399
Abhilfe:
ein B a s i s z e i g e r (OFFSET) a l s r e l a t i v e r
punkt f u r a l l e Zeigerinhalte
Koordinaten-Anfangs-
Adressen. Nach dem T r a n s p o r t in den ASP werden a l l e auf die Adresse des B a s i s z e i g e r s abgestimmt.
tenbank im ASP m i t der ALLOC-Anweisung und im M u l t i t a s k i n g Dateien e r r i c h t e t
wird,
Da die Dam i t anderen
b e s t e h t die Gefahr der ZerstUckelung
(verstreu-
te t o p o g r a f i s c h e Aufbringung im ASP). Eine Datenbank, deren Elemente aber v e r s t r e u t
Uber den ASP v e r t e i l t
wand in den ESP t r a n s p o r t i e r t
sind,
kann n i c h t
ohne groBen Auf-
und d o r t geschlossen und IUckenlos u n t e r -
gebracht werden. Die O b j e k t v e k t o r e n werden deshalb in einem t o p o g r a f i schen Gebiet (AREA) gesammelt. Ein Gebiet d a r f vom B e t r i e b s s y s t e m auch nicht
zur S p e i c h e r p l a t z b e r e i n i g u n g im ASP z e r s t U c k e l t werden. Um m i t
e i n e r e i n z i g e n Anweisung (READ, WRITE, REWRITE) die Bankdaten zu t r a n s portieren,
werden s i e ~n e i n e r S t r u k t u r
( h i e r TUMPLA) zusammengefaBt:
00060 DCL 1 TUMPLA CTL, / * TUMMELPLATZ, PENDELNDER BANKANTEIL * / 00070 2 GG OFFSET(GEB), 00080 2 GEB AREA(100); 00090 00100 DCL 1 ZZ BASED, / * ZE1GERFELD * / 00110 2 ( T T ( 3 ) , / * ANKERZEIGER * / 00120 qq(2) / * HILFSZEIGER * / ) POINTER; 00130 00140 DCL I OBJ BASED, /* OBJEKTVEKTOR */ 00150 2 EIFEL CHAR(3), / * EIGENSCHAFTSFELD * / 00160 2 LL PTR; / * BEZUGSZEIGER * / 00170 00180 DCL (Z, NR) BIN FIXED(10); 00190 00200 DCL HADES FILE SEQL ENV(U); / * FXTERNE DATEI * / 00210 / * ALLOC DATASET(DAT2.DATA) FILE(HADES) BLOCK(150) SPACE(l) * / Die e x t e r n e Datei HADES, d i e die Bankdaten TUMPLA aufnehmen s o l l , zun~chst auf dem ESP m i t i h r e n S t a r t d a t e n f o r m i e r t 00250 00260 00270 00280 00290
werden:
OPEN FILE(HADES) OUTPUT; ALLOC TUMPLA; ALLOC ZZ IN (GEB) SET (GG); GG->ZZ.TT = NUt.L; GG->ZZ.QQ : NULL; DCL HULL BUILTIN; NRtTE FROM (TUMPLA) FILE (HADES); FREE TUMPt_A; CLOSE FILE (HADES);
Im folgenden D a t e n b a n k - B e t r i e b sind a l l e
Bankbearbeitungen zwischen den
beiden folgenden T r a n s p o r t - P r o z e d u r e n e i n z u b e t t e n : 00620 00630 00640 00650 und
muB
TRAIN: PROC; / * TRANSPORT VON ESP HACH ASP * / OPEN FILE(HADES) UPDATE; ALLOC TUMPLA; READ FILE(HADES) INTO (TUMPLA); END TRAIN;
400
01170 01180 01190 01200
TRAUS: PROC; / * TRANSPORT VON ASP NACH ESP * / REWRITE FROM(TUMPLA) / * NACH * / FILE(HADES); FREE TUMPLA; CLOSE FILE(HADES); END TRAUS;
Aus der Menge der Bankprozeduren sei gabe-Prozedur h e r a u s g e g r i f f e n : 00690 00700 00710 00720 00730 00740 00750
als t y p i s c h e r
Vertreter
die Ein-
GET FILE(SYSIN) LtST(NR); ALLOC OBJ IN (GEB) SET(GG->ZZ.QQ(1)); GG->ZZ.QQ(1)->OBJ.LL : GG->ZZ.TT(NR); GG->ZZ.TT(NR) = GG->ZZ.QQ(1); PUT FILE(SYSPRINT) LIST ( 'GEBEN SIE WERT EIN w) SKIP; GET FILE(SYSlN) LIST (GG->ZZ.QQ(1)->OBJ.EIFEL);
6.3. V e r t e i l e Bankdaten Die Bankdaten werden a u f g e t e i l t in a) ASP-Anteil ( S c h a t t e n b a n k ) , d e r die V e r z e i g e r u n g e n t h ~ I t und SchlUss e l , die auf die E i g e n s c h a f t s d a t e n (S~tze) im Datenbankrumpf v e r w e i s e n . b) ESP-Anteil (Datenbankrumpf), der die E i g e n s c h a f t s d a t e n e n t h ~ I t . In der Schattenbank w i r d e n t l a n g der V e r z e i g e r u n g ein SchlUssel e r m i t t e l t . M i t dem SchlUssel k~nnen dann die E i g e n s c h a f t s d a t e n des Objektes aus dem Datenbankrumpf g e h o l t werden. Im ASP i s t deshalb immer nur der b e t r o f f e n e Datensatz ( r e c o r d ) , n i c h t aber der ganze Datenbankrumpf. U.U. kann auch die n~here Umgebung eines Satzes in den ASP 9 e b r a c h t werden. Im Datenbankrumpf k~nnen sowohl s c h a f t e n u n t e r g e b r a c h t werden.
individuelle
als auch K o l l e k t i v e i g e n -
Der Datenbankrumpf i s t eine Datei mit d i r e k t e m Z u g r i f f s t r e u t e r A u f b r i n g u n g (REGINAL).
(DIRECT) und ge-
7. Datenbanken im M u l t i t a s k i n q Der Z u g r i f f mehrerer Benutzer zu e i n e r Datenbank muB durch Semaphorv a r i a b l e k o o r d i n i e r t werden (PEARL), Datenbankprozeduren sind zwischen REQUEST ( s e m a v a r i a b l e ) RELEASE ( s e m a v a r i a b l e )
und
einzubetten. Literaturhinweise: K u s s l , V.: Technik der P r o z e ~ d a t e n v e r a r b e i t u n g , Koch, Kussl:
Carl Hanser Verlag
1973
P r o z e ~ o r i e n t i e r t e Programmiersprachen, Formen und F u n k t i o n e n , 3. GI-Fachtagung Uber Programmier-Sprachen, M~rz 1974 Wedekind, H.: D a t e n o r g a n i s a t i o n , Walter de G r u y t e r 1972
ERFAHRUNGEN
BEI DER ERSTIMPLEMENTIERUNG
EINES
PEARL-SUBSETS
J. HEGER G. KOCH Im Rahmen des 2. DV-F~rderungsprogrammes desregierung
bei BBC eine Erstimplementierung
zeitprogrammiersprache gef~hrt.
wird mit Unters~ [tzung der Bun-
PEARL
eines Subs~ ;s der Echt-
PEARL fur die PDP11 von Digital-Equipment
(Process and Experiment A_utomation ~ealt~ ne Language)
wurde in Zusammenarbeit
von Hochschulinstituten
nerhalb der vorangegangenen sten prozeBorientierten
3 Jahre entwickelt
Programmiersprachen
genden werden nach Definition grammiersystem
gestellten
und d e u Bchen Firmen inund ist ,:Cine der modern-
([3],
tig abgegrenzt.
Erwartungen
AnschlieBend
[4], 15]
). Im fol-
einiger Begriffe die an ein Echtzeit-Prozusammengetragen.
dung fur PEARL wird begr~ndet und das ausgew~hlte Erfahrungen
durch-
wird der Systemaufbau
bei der Implementierung
Die Entschei-
Subset ~berblicksarbeschrieben
und ~ber
berichtet.
I. Be~riffskl~run~ Das Programm[2] Prozesses
eines ProzeBrechners
kann entweder
lemorientierten werden.
die es erlauben,
pro~rammiersprachen.
z.B. fur DDC-Aufgaben, [7] eingesetzt.
oder einer prob-
Programmiersprache
Aufgaben maschinenunabh~ngig
zeBorientierte chen
in einer maschinenorientierten
(maschinenunabh~ngigen)
Programmiersprachen,
spezifischer
[I] zur F~hrung eines technischen geschrieben
die L~sung prozeBrechner-
abzufassen,
nennen wir pro-
FUr bestimmte Einsatzobjekte,
werden mitunter
objekt~ebundene
wie
Programmierspra-
Es handelt sich dabei ebenfalls um maschinenunab-
h~ngige Sprachen
zur Beschreibung
des vorgesehenen
Einsatzbereiches.
eines speziellen Problems
innerhalb
2. Motivation Die Implementierung ProzeBrechner
hohen Aufwendungen Die vorliegenden wicklung
yon maschinenunabh~ngigen
ist nur dann sinnvoll,
Programmiersprachen
fur
wenn der zu erwartende Nutzen die
rechtfertigt.
Erfahrungen
aus der von BBC durchgefHhrten
([9J, [I~ ) zeigent dab bereits kurzfristig
Senkung der Programmier-
PASI-Ent-
durch erhebliche
und Testkosten und VerkHrzung der Realisie-
rungsdauer von Projekten die wirtschaftliche
Rechtfertigung
Bei langfristiger
sich jedoch wesentlich
Betrachtungsweise
er6ffnen
gegeben ist.
402
bedeutendere M~glichkeiten im Hinblick auf die Wiederverwendbarkeit
von
Programmen oder Programmteilen vor allem dann, wenn objektgebundene Programmierhilfsmittel
auf einer prozeBorientierten Programmiersprache
auf-
bauen. F~r neue Rechensysteme ist zwar diese Sprache erneut zu implementieren, die in dieser Sprache vorliegenden Programme und die technologischen Pakete sind jedoch unmittelbar ~bertragbar
(z.B. Programmpa-
kete fHr Lagertechnik, DDC oder Wartentechnik). Die Benutzung von maschinenunabh~ngigen Programmiersprachen hat auBerdem erheblichen EinfluB auf die Systemanalyse.
FHr den Systemanalytiker
stehen nicht mehr die speziellen Eigenschaften des verwendeten Rechensystems im Mittelpunkt sondern die Gegebenheiten der maschinenunabh~ngigen Programmiersprachen.
Die Analysen werden dadurch allgemeingHltig
und weitgehend hardwareunabh~ngig. Die Vor- und Nachteile von mit problem-orientierten mierbaren ProzeBrechensystemen
Sprachen program-
gegen~ber solchen mit Assemblersprachen
entsprechen denen im technisch-wissenschaftlichen
Bereich. Dieser Kom-
fort wird erkauft durch erh~hten Aufwand bei der ubersetzung hinsichtlich Zeit und Speicherbedarf und durch gr~Bere Zielprogramme mit l~ngerer Ausf~hrungszeit gegen~ber rechner-orientierten
Systemen.
FOr kleinere ProzeBrechner sind die erh~hten Anforderungen beim ubersetzungsvorgang dadurch zu umgehen, dab diese Arbeiten auf GroBrechnern durchgef~hrt werden und erst das erzeugte Maschinenprogramm
auf dem
ProzeBrechner ausgefHhrt wird. Der Zusatzbedarf an Kernspeicher verliert durch den Preisverfall fur Rechnerhardware und Kostensteigerung bei der Programmierung
zunehmend an Bedeutung.
Schwerer wiegt die l~ngere Laufzeit der Zielprogramme, da die AusfHhrung einer Aufgabe in einer vom ProzeBgeschehen vorgeschriebenen
Zeit-
spanne abgeschlossen sein muB. Durch den technologischen Fortschritt in Richtung besserer und schnellerer Rechner verringert sich zwar der Nachteil der l~ngeren Laufzeit,
aber der Einsatzbereich dehnt sich im
gleichen MaBe aus. Hier helfen jedoch verbesserte Compiler und Betriebssysteme. Durch Optimierungsstrategien nenprogramme erzeugt werden.
im Compiler k6nnen kHrzere Maschi-
GUnstige Rechnerstrukturen
erlauben es,
Betriebssysteme mit kHrzeren Verwaltungszeiten und schnellerer Interruptreaktion zu entwickeln. Zur Programmierung von ProzeBrechnern waren bisher im allgemeinen fundierte Kenntnisse des speziellen Rechners notwendig. die ProzeSrechnerprogrammierung
In dem MaBe wie
benutzerfreundlicher wird, d.h. prozeB-
orientierte oder objektgebundene Programmiersprachen verf~gbar sind, kann der Technologe seine detaillierten ProzeBkenntnisse gramme umsetzen.
in Rechnerpro-
403
3. Auswahl der Pro@rammiersprache Die Entscheidung f~r die Implementierung der Programmiersprache PEARL wurde Mitte 1972 getroffen.
Im Vergleich z u anderen Echtzeit-Program-
miersprachen bietet PEARL das geschlossenste Konzept. Die M~glichkeit, eine technisch-wissenschaftlich zeBanforderungen
orientierte Programmiersprache
fHr Pro-
zu erweitern, wurde verworfen, da entweder der Erwei-
terungsanteil ein mehrfaches der Grundsprache umfaBt h~tte
(z.B.FORTRAN)
oder die Grundsprache im Hinblick auf die Erzeugung optimaler und sicherer Programme h~tte abge~ndert werden m~ssen
(z.B. bei PL/I).
Die Programmiersprache PEARL besitzt folgende charakterische Eigenschaften: PEARL umfaBt alle Vorteile von Programmiersprachen
-
senschaftliche
f~r technisch-wis-
Zwecke, wobei sich die Syntax an PL/I anlehnt.
- Ein PEARL-Programm zerf~llt in einen Problemteil und einen Systemteil. Im Problemteil wird die L~sung des vorliegenden Problems ohne Bezugnahme auf die verwendete Hardware programmiert. invariant bei Wechsel des Rechners.
Dieser Tell bleibt
Im Systemteil des PEARL-Programms
wird die Verbindung zur aktuellen Hardware hergestellt. ist bei Ubergang auf andere Rechnerkonfigurationen -
Dieser Teil
umzuschreiben.
Das Modulkonzept bietet eine wirkungsvolle Entkopplung der einzelnen Bl~cke innerhalb eines Moduls bzw. der Moduln untereinander.
- PEARL enth~it alle notwendigen Statements
zur ~bersichtlichen Pro-
grammierung des Taskings und der ProzeB-Ein-/Ausgabe. - Die Sprache erlaubt durch ihre g~nstige Struktur eine recht umfangreiche Fehlererkennung w~hrend des Compilierens bzw. des Linkens und eine Ubersetzung in optimalen Zielcode. - Es sind Subsets abgrenzbar, die zur ProgrammausfHhrungszeit
nur klei-
ne Betriebssysteme voraussetzen. Um den Implementierungsaufwand
von PEARL zu reduzieren und dadurch m6g-
lichst schnell Einsatzerfahrungen mit solchen Systemen sammeln zu k6nhen, wurde ein Subset von PEARL unter folgenden Gesichtspunkten ausgew~hlt: -
Der Sprachumfang des PEARL-Subsets
sollte so groB sein, dab der Pro-
grammieraufwand weder wesentlich steigt noch die Ubersichtlichkeit des Programms leidet.
Insbesondere sollten in Statements AusdrHcke
erlaubt sein, wo dies sinnvoll ist,
wie
z.B. als Parameter bei Pro-
zeduraufrufen und als Index bei Arrayansprachen. -
Die Standard-Systemfunktionen
sollten das unbedingt erforderliche
404
MaS nicht ~bersteigen. -
Es sollten zus~tzliche Fehlerpr~fungen
zur Compile- bzw. Linkzeit
mSglich sein. -
Die Planung des Task-Speicherraumes
sollte sp~testens
zur Linkzeit
mSglich sein, d.h. alle Tasks sollten bereits zur Compilezeit bekannt sein. Nach diesen Vorgaben wurde das BBC-PEARL-Subset stenEntwicklungsstufe
ist nur ein PEARL-Modul
abgegrenzt.
In der er-
zul~ssig, der Systemteil
und Problemteil enthalten muS. Der Problemteil enth~it neben den Deklarationen Task- und Prozedurbl~cke. Modulebene
Die TaskblScke m~ssen alle auf der
liegen, sodas die Task-Speicherplanung
bereits zur Compile-
oder Linkzeit erfolgen kann. Prozedurbl~cke k~nnen sowohl auf der Modulebene als auch intern in beliebigen Task- oder Prozedurbl~cken erkl~rt sein. Alle Prozeduren sind reentrantf~hig.
Damit sind Deklara-
tionen auf jedem Blockniveau sinnvoll. Der ProzeduranschluS
erlaubt
Wert- und AdreS~bertragung wahlfrei f~r jeden Parameter festzulegen. Durch die M6glichkeit der Wert~bertragung gewinnt man gegen~ber den ProzeduranschluSm~glichkeiten wirkungsfreier AnschluS)
von PL/I zus~tzliche Sicherheit
(r~ck-
und eine Reduktion der Ausf~hrungszeit der
Prozedur. Als Problemdaten sind die Typen FIXED mazahl),
BIT
le), DURATION
(Bitkette), CHARACTER (Zeitdauervariable)
(Festkommazahl},FLOAT
(Zeichenkette),
CLOCK
(Gleitkom-
(Uhrzeitvariab-
zul~ssig. Die arithmetischen Daten
FIXED und FLOAT k6nnen mit den ~blichen arithmetischen Operatoren verkn~pft werden toren
(+, -, *, /, **). FUr Bitketten sind die logischen Opera-
(&, I, II, ") erkl~rt. Wandlungsfunktionen
erlauben den Wechsel
des Datentyps. Als Datenanordnungen
sind vorerst nur Skalare und Arrays erlaubt. Die
Erweiterung auf Strukturen ist geplant. Es sind alle wesentlichen PEARL ~ Statements wie Zuweisung,
IF-Anweisung, FOR-Anweisung,
Sprunganweisung,
Prozeduraufruf erlaubt. Bei der FOR-Anweisung ist zu beachten, dab die Laufvariable in der FOR-Gruppe FOR-Gruppe unbekannt.
lokal, d.h. ihr Wert ist auSerhalb der
Dadurch werden Code-0ptimierungen
erm~glicht.
Neben den Problemdaten gibt es Variable vom Typ LABEL, SEMA, EVENT, DEVICE und FILE. Diese Variablen m~ssen mit Ausnahme der Labelvariablen auf Modulebene erkl~rt werden,so dab sie statisch behandelt werden k~nnen, d.h. sie k~nnen zur Compilezeit mit einer Nummer versehen werden. Dadurch werden zur Ausf~hrungszeit Verwaltungsfunktionen gespart. Es wurden nur zweiwertige Semavariable
zugelassen.
Sperren
(REQUEST)
4o5
und Entsperren
(RELEASE) einer Semavariablen muB in derselben Task er-
folgen. Das Betriebssystem kann dadurch in Fehlerf~llen die Freigabe der gesperrten Semavariablen erzwingen. Versuchsweise wurden im BBC-Subset Ereignisvariable aufgenommen, um mit ihrer Hilfe den Ablauf von Tasks synchronisieren zu k~nnen. Eine Ereignisvariable hat die Zust~nde "erf~llt" und "nicht erfHllt". Die Anweisungen SET und RESET fHhren die Zustands~nderungen in "erfHllt" bzw. "nicht erf~llt" durch. Mit der WAIT-Anweisung kann in einer Task auf das Eintreten einer bestimmten Ereigniskonstellation gewartet werden. Beispiel: Durch WAIT(EI&~E2) wird die Task aufgehalten bis El den Zustand "erf~llt" und E2 den Zustand "nicht erf~llt" besitzt. Der Komplex der Tasksteueranweisungen wurde geringfHgig eingeschr~nkt: -
alle Tasks haben feste Priorit~ten, die bereits zur Compilezeit ausgewertet werden.
- alle Zeiteinplanungen sind uhrzeitinvariant
(ALL-Angabe ist verboten).
Die m~glichen Taskzust~nde und Uberg~nge sind im T a s k z u s t a n d s d i a g r a m m (Bild I) dargestellt
(s. auch
[11]).
Beispiel: AT 12.OO.OO EVERY 7 SEC UNTIL 13.10.00 ACTIVATE TI; Dieses Statement bewirkt, dab die Task mit dem Namen TI beginnend ab 12 °0 al!e 7 Sekunden bis 13 I° ausgefHhrt wird. Umfangreiche E/A-Statements erm~glichen eine ~bersichtliche und komfortable Programmierung der Ein- und Ausgabe von Daten. Zur unformatisierten Ein- und Ausgabe von ProzeBdaten dienen TAKE und SEND-Anweisungen. Die zeichenweise Ein- und Ausgabe umfaBt die aus PL/I bekannten M~glichkeiten mit und ohne Formatangabe
(EDIT und LIST).
Der Systemteil gestattet den AnschluB aller Ger~te der BBC-DPIOOO-ProzeB-Peripherie zu beschreiben. FUr alle Aufgaben des Datenverkehrs stehen passende Komponenten zur Verf~gung.
Beispiel: SYSTEM; DEVADR AIIOO3=O; TEMP MODE(5):-> AIIOO3.IO; PROBLEM; DCL TEMP
DEVICE;
Der zu TEMP geh~rende Temperaturf~h!er ist ~ber Multiplexeradresse 10 an das Analog-Input-Werk AI1003 angeschlossen. Die Baueinheit ist Hber Interface-Adresse 0 an den Rechner gekoppelt. Die Messung yon TEMP ist im MeBbereich 5 durchzuf~hren.
406 I Laden des Programms Task bekannf ( idle ) __.
i_PREVENT '9
J
1 ACTIVATE Task eingel:~ant (scheduled)
Task- Vor~lzliste [ !
I Bedir~uqlg~-~ dQr I VotcJo~ti$~ effOl/~
I
erfOllt I I I
I Wen. Tc~k g/eichen I Tosknarner~ nichf I,,akfiv" Ta3k akHv
I:yo,..., ![
Task lau{fdhig (runnoble )
(active)
]~
I
I Pl'jorJ~f.$-
I I auswol~l ~=TERMINATE I END _ STOP
[
Tosk in AusfOhrung ( runnin 9 ) Task ~uspendierf
51.L~ND DELAY"
I_I ~uspended 7t I
] "•CONTINUE")
I i NrIN , ", 3
wan" I
REQUEST
i-I '~q°="°~'- J I ,,= TERMINATE ")
-- STOP *)
..... ~*)
yore P ~ m i e r e r miP Mulfi/a.~kir~-Anvve;sung veranlaMer Obergan8 ~.- $ystemi/7~=m veranla/3t%=r Obergang hnweisung ~ n;cht in der hier /x.WodnE.fen Tosk , sondern in e;ner anderem
Bild I
Taskzustands-Diagramm
-
4o7
Ein einfaches B e i s p i e l soll einige M ~ g l i c h k e i t e n von PEARL d e m o n s t r i e ren: Der Druck einer R o h r l e i t u n g soll m i t t e l s
zweier D r u c k d o s e n mit
iinearer E i c h c h a r a k t e r i s t i k H b e r w a c h t werden, die M e B w e r t e DRUCKI DRUCK2 in A n a l o g f o r m liefern. Der Wert DRUCKI tersuchen. bzw.
Falls dieser Wert I atU
2 at~ wird,
6ffnen bzw.
und
ist jede Sekunde zu un-
ist ein Ventil
zu schlieBen.
zu
Der Wert
DRUCK2 ist alle 30"Sekunden bzgl. G r e n z w e r t U b e r s c h r e i t u n g nach oben und unten zu kontrollieren.
Bei V e r l a s s e n
des zul~ssigen D r u c k b e r e i c h e s Hber F e r n s c h r e i b e r
ist dies
zu p r o t o k o l l i e r e n .
FHr die R e a l i s i e r u n g d i e s e r A u f g a b e sei
ein D i g i t a l r e c h n e r mit der im
Bild 2 d a r g e s t e l l t e n H a r d w a r e ausgerUstet. An I n t e r f a c e - S c h n i t t s t e l l e
I
zwischen Z e n t r a l e i n h e i t und ProzeBp e r i p h e r i e ist das Werk fHr AnalogEingabe,
b e s t e h e n d aus einem AD-Um-
setzer und e i n e m s c h n e l l e n M u l t i p l e xer, angeschlossen.
Bild 2: A n w e n d u n g s b e i s p i e l : Hardware
Uber die A d r e s -
sen 270 und 273 des M u l t i p l e x e r s werden die D r u c k w e r t e fur DRUCKI
DRUCK2 angeschlossen.
und
Das Werk fur d i g i t a l e Ausgabe ist an Interface-
S c h n i t t s t e l l e O angeschlossen.
Zur S t e u e r u n g des S t e l l m o t o r s fur das
Ventil d i e n e n die Bits 0 und I auf A d r e s s e 413, und zwar fUhrt das Ausgabesignal
I auf Bit 0 zum Offnen des Ventils, das Signal I auf Bit I
zum S c h l i e B e n des Ventils.
Das P E A R L u P r Q g r a m m z u r L~sung der b e t r a c h t e -
ten A u f g a b e ist im Bild 3 wiedergegeben.
Der b e i g e f ~ g t e K o m m e n t a r be-
s c h r e i b t die W i r k u n g s w e i s e der Statements. 4. S y s t e m a u f S a u Das P E A R L - P r o g r a m m i e r s y s t e m f~r die PDP11
u n t e r s t H t z t in der ersten
A u s b a u s t u f e das im Punkt 3 grob a b g e g r e n z t e Subset. Die exakte Spezifik a t i o n ist im B B C - P E A R L - H a n d b u c h
[6] enthalten.
Das e n t w i c k e l t e PEARL-
S o f t w a r e p a k e t g l i e d e r t sich in die P r o g r a m m e zur V o r b e r e i t u n g und zum Betrieb des ProzeBrechners. 4.1. P r o g r ~ n m e zur V o r b e r e i t u n g Zur V o r b e r e i t u n g des P r o z e B r e c h e n b e t r i e b s ein Linker erforderlich.
ist ein P E A R L - C o m p i l e r und
Im ersten E n t w i c k l u n g s a b s c h n i t t wurde lediglich
408
/* P R O G R A M M - M O O U L ZUR D R U C K U E B E R W A C H U N G IN E I N E R R O H R L E I T U N G MOOULE R O H R D R U C K ; SYSTEM~ / * HARDWARE-BESCHREIBUNG DEVADR A I 1 0 0 3 = 1 ; / * ANALOGEINGABE AN INTERFACEADR.1 DRUCKI M O D E ( 5 ) : - > A I l O 0 3 * 2 7 0 ; / * DRUCK1/2 AN DEN ADRESSEN 270 DRUCK2 M O D E ( 5 ) : - > A I l O O S * 2 7 3 ; / * BZW. 273 DER ANALOGEINGABE / * GEMESSEN WtRD IM MESSBEREICH 5 DEVADR DQIO06=O; / * DIGIT.AUSGABE AN INTERFACEAOR.O VENTIL B I T ( 2 ) : - > D 0 1 0 0 6 . 4 1 3 . 0 ; / * VENTILSTEUERUNG DURCH 2 BIT VON / ~ KANAL 413 DER D I G I T . AUSGABE, / * BEGINNEND AB B I T O FERNSCHR: CON; / ~ DIE STANDARDBEDIENUNGSKONSOLE / * CON WIRD MIT DER DATEI FERNSCHR SYSEND; / * VERBUNDEN
*/
/* /*
*/ */
PROBLEM; DCL FERNSCHR PRINT, (START,TI,T2) TASK, (DRUCK1,DRUCK2, VENTIL) DEVICE;
PROBLEM-BESCHREIBUNG DEKLARATtONEN AUF MODULEBENE
*/ */ */ */ */ */ */ */ */ ~/ */ */
START: TASK MAIN; EVERY i SEC ACTIVATE T I ; EVERY 30 SEC ACTIVATE T2; END /~: START * / ;
/* HAUPTTASK, VON KONSOLE STARTBAR * / / * ZEITABHAENGIGER START VON T 1 / T 2 ~ / /*
ENDE HAUPT-TASK
*/
TI: TASK; BIN F I X E D ( 1 5 ) , DCL DRIA (DRI,AI,BI) BIN FLOAT(24), VENT BIT(2); TAKE DRIA FROM ORUCKI; D R I = F L O A T ( O R I A ) * A I + BI; IF O R I > 2 . 0 THEN VENT='OI'B; ELSE IF 0RI<1.0 THEN V E N T = ' I O ' B ; SEND VENT TO VENTIL; END /* TI */;
/* /*
TASK ZUR ORUCKREGELUNG DEKLARATIONEN AUF TASK-EBENE
*/ */
/m MESSWERT-UEBERNAHME, WANOLUNG / * IN GLEITKOMMA-DARSTELLUNG UND /* U M R E C H N U N G IN PHYSIK. WERTE
~/ ~/ */
/*
*/
GRENZWERT-KONTROLLE
/* VENTIL OEFFNEN/SCHLIESSEN
*/
/* TASK ZUR P R O T O K O L L I E R U N G VON ZU */ T2: TASK; DCL DRZA BIN F I X E D ( 1 5 ) , / * HOHEN ODER ZU TIEFEN WERTEN */ (OR2~A2,B2) BIN F L O A T ( 2 4 ) , / ~ VON DRUCK2 TEXT CHARACTER(3), UHRZEIT CLOCK~ TAKE OR2A FROM DRUCK2; D R 2 = F L O A T ( O R 2 A ) * A 2 + B2; IF 0R2>3.5 THEN 00; TEXT='OGR'; M:UHRZEIT=TIME; /* U H R Z E I T - U E B E R N A H M E ~/ PUT FILE(FERNSCHR) EDIT / ~ AUSGABE DER */ (UHRZEIT,TEXT,DR2) /* OATEN */ (SKIP~T(8),X(2),A(3),X(2),F(4,2)); I* F O R M A T L I S T E ~I~/ END~ ELSE IF D R 2 < 0 . 5 THEN DO; T E X T = I U G R I ; GOTO M~ END~ END / ~ T2 m / ; PROBEND; / * ENDE DES PROBLEM-TEILS */ MODEND / * ROHRDRUCK*/~ / * ENDE DES PROGRAMM-MODULS */
Bild
3: A n w e n d u n g s b e i s p i e l
: PEARL-Progranun
409
ein P E A R L - C o m p i l e r b e r e i t g e s t e l l t , der O b j e c t - C o d e fHr die PDP11
er-
zeugt. D i e s e r C o m p i l e r w u r d e in e i n e m Subset von PL/I p r o g r a m m i e r t und l~uft zur Zeit auf einer R e c h e n a n l a g e vom Typ IBM/370. Es h a n d e l t sich um einen 10-Pass-Compiler, der sowohl das b e t r a c h t e t e P E A R L - S u b s e t als auch das P L / I - S u b s e t ,
in w e l c h e m er g e s c h r i e b e n ist, H b e r s e t z e n kann.
Sobald die F e h l e r b e r u h i g u n g s p h a s e H b e r s t a n d e n ist, w i r d der P E A R L - C o m piler auf die PDP11 ttbernommen. D a n a c h k a n n der C o m p i l i e r p r o z e B auch auf d e m P r o z e B r e c h n e r d u r c h g e f H h r t werden,
zum L i n k e n des P E A R L - O b j e c t -
Moduls und der S y s t e m p r o g r a m m e w i r d v o r e r s t der D E C - L i n k e r LINK 11 [8] benutzt.
Der dabei e r z e u g t e L o a d - M o d u l e ist auf der PDP11 u n m i t t e l b a r
ausfOhrbar. 4.2. P r o g r a m m e zum Betrieb des P r o z e B r e c h n e r s Zur A u s f ~ h r u n g s z e i t sind neben dem P E A R L - A n w e n d e r p r o g r a m m die Systemp r o g r a m m e erforderlich.
Sie lassen sich in folgender W e i s e gliedern: -
Betriebssystem
- Treiberroutinen - Standardfunktionen -
Standardtasks
B e i m L i n k v o r g a n g eines PEARL-Anwenderprograna~s w e r d e n die e r f o r d e r l i chen P r o g r a m m e aus der S y s t e m b i b l i o t h e k dazugelinkt. 4.2.1. Bet r i e b s s y s t e m Ein kleines von BBC e n t w i c k e l t e s E c h t z e i t b e t r i e b s s y s t e m wurde f0r PEARL adaptiert.
Es b e s t e h t aus B a s i s r o u t i n e n wie Task z u r H c k s t e l l e n und Task
aufnehmen, d e m T a s k h a n d l e r , d e m C l o c k h a n d l e r , dem F i l e h a n d l e r sowie der Event- und S e m a v e r w a l t u n g .
Der S p e i c h e r b e d a r f fur dieses B e t r i e b s s y s t e m
b e t r ~ g t zwischen 1.2 und 1.5 K Worte. 4.2.2. T r e i b e r r o u t i n e n FUr jedes P e r i p h e r i e g e r ~ t
ist eine T r e i b e r t a s k vorhanden.
Sie ~ b e r t r ~ g t
die yon der A n w e n d e r t a s k b e r e i t g e s t e l l t e n I n f o r m a t i o n s b l ~ c k e P e r i p h e r i e g e r ~ t e n bzw.
zu den
sammelt I n f o r m a t i o n yon den P e r i p h e r i e g e r ~ t e n
und ~ b e r g i b t sie der A n w e n d e r t a s k .
Die K o o r d i n i e r u n g zwischen T r e i b e r -
task und A n w e n d e r t a s k ~ b e r n i m m t der Filehandler. 4.2.3. S y s t e m f u n k t i o n e n FUr die im P E A R L - S u b s e t g e f o r d e r t e n Operationen,
die nicht ins A n w e n -
d e r p r o g r a m m als C o d e s t ~ c k e e i n g e n e r i e r b a r sind,
stehen F u n k t i o n e n be-
reit. N e b e n der G l e i t k o m m a - A r i t h m e t i k und den a r i t h m e t i s c h e n S t a n d a r d f u n k t i o n e n sind die P r o z e d u r e n fHr die B e a r b e i t u n g yon K e t t e n d a t e n
~10
und die Prozeduren fur Proze8-Ein-/Ausgabe und zeichenweiser Ein/-Ausgabe vorhanden. 4.2.4. Systemtasks F~r das PEARL-System wurden eine Error-Message-Task und eine Standardbedientask entwickelt. Die Error-Message-Task protokolliert a l l e zur Laufzeit des P E A R L - S y stemserkannten Fehler, wobei die Fehlerart durch eine SchlHsselzahl charakterisiert und die Fehlerstelle durch die Aufrufkette bis zur Taskebene ausgewiesen wird. Zur Kommunikation zwischen Operator und ProzeBrechner wurde eine Bedientask entwickelt. Uber die Bedien-Console hat der Operator jederzeit Zugang zu allen Tasks. Uber Bedienungsanweisungen wird der gewHnschte Auftrag der Bedientask ~bermittelt, die dann fur die AusfHhrung sorgt. Es sind folgende Bedienungsanweisungen vorhanden: -
Taskinganweisung
- Auskunftsfunktionen - File-Ger~te-Zuordnung -
Testunterst~tzung
5. Implementierun~serfahrun~en Das ausgew~hlte PEARL-Subset hat die Erwartungen im Hinblick auf die ~bersichtliche und einfache Programmierbarkeit, auf den Einsatzbereich und auf die Compile- und Linkzeitpr~fungen erf~llt. Die Taskoperationen haben sich durch die Beschr~nkung auf statische Tasks mit festen Priorit~ten als sehr effektiv in der AusfHhrungszeit erwiesen. Die intelligente Hardware-Struktur der PDP11 und der darauf optimal abgestimmte Clockhandler ergeben eine Rechnerbelastung von 0,4% bei einem Aufl~sungstakt von 5msec. Die ProzeB-Ein/Ausgabe unterst~tzt die BBC-DPlOOO-ProzeBperipherie voll, d.h. alle erforderlichen OrganisationsmaBnahmen werden auf der Systemebene abgehandelt. Es wird zur Zeit er~rtert, ob die Verantwortung fHr die Organisation der ProzeSdatenHbertragung dem Programmierer ~berlassen werden sollte. Dadurch k~nnte in vielen F~llen Ausf~hrungszeit gewonnen werden. Beim automatischen Restart nach Netzausf~llen wurde neben den SystemmaBnahmen zun~chst nur eine Restart-Task fur die Anwenderseite vorgesehen. Gegenw~rtig wird ~berlegt, ob je Task Restart-Vorgaben program-
411 mierbar
sein sollten.
Im PEARL-Compiler
wurden bereits
pilezeit-Statements
bestinmlte ProgrammstHcke fungen)
in der ersten Entwicklungsstufe
verwirklicht,
laufzeitgHnstigen
oder speicherraumgOnstigen
verlangen.
die dem Programmierer
nenfalls darauf
Verringerung
zu
eines PEARL-Programms Einsatz
der Ausf~hrungszeit
gegebe-
wird fortgesetzt,
wobei zu-
zu verzichten.
Die Erprobung des PEARL-Programmiersystems Sprachm6glichkeiten
gung, Overlay-Vorgaben system,
(ohne Runtime-PrH-
zu arbeiten und erst beim endg~itigen
zugunsten einer wesentlichen
fHr
(mit Runtime-Pr~fungen)
Es bietet sich an, in der Testphase
mit allen Uberwachungen
s~tzliche
Zielcode
Zielcode
Com-
erlauben,
erweiterte
(wie Strukturen,
satzweise DatenHbertra-
usw.) und Systemerweiterungen
Peripherie,
Rechnerkopplung
usw.)
(wie Nachschubin die Betrach-
tungen einbezogen werden. Es wird erwartet,
dab auch die Einsatzerfahrungen
bei unterschiedlichsten scheidung
technischen
des PEARL-Systems
Prozessen die Richtigkeit
f~r die PEARL-Implementierung
best~tigen.
der Ent-
412
Literatur [I ] Normblatt DIN 66201 "ProzeSrechensysteme"
(August 1971)
[2 ] Normblatt DIN 44300 "Informationsverarbeitung"
(M~rz 1972)
3 ] Brandes u.a. : PEARL - The Concept of a Process- and Experimentoriented Programing-Language Elektronische Datenverarbeitung, 10, 429 - 442 (1970) 4 ] PEARL
- A proposal for a process- and experiment automation
realtime language KFK-PDV-I April 1973, Gesellschaft f~r Kernforschung mbH Karlsruhe 5
]
Eichenauer, B., Haase, V., Holleczek, P., Kreuter, K. und MHller, G.: PEARL, eine prozeB- und experimentorientierte Programmiersprache, Angewandte Informatik, ~, 363 - 372 (1973)
6 ] BBC-PEARL-Subset, Sprachbeschreibung Brown, Boveri & Cie Mannheim Druckschriften-Bestell-Nr.
D ZEK 40053 D
7 ] Binge, K., Koch, G.: Interpretierende, problemorientierte und objektgebundene Programmsysteme for ProzeSrechner,
5. Interkama 1971
[8 ] PDP-11 LINK-It LINKER and LIBR-11 LIBRARIAN Programmer's Manual, DEC-11-ZLDC-D, Febr. 9 ] PASI - ProzeS-Automatisierungs-Sprache
(1972)
(Sprachbeschreibung)
Brown, Boveri & Cie Mannheim Druckschriften-Bestell-Nr.: [I~
ED 1004
Das ProzeB-Datenverarbeitungssystem DP IOO0 BBC-Nachrichten, ~ / 10, 267 - 294 (1971)
11] Minutes Sixth Workshop on Standardisation of Industrial Computer Languages Purdue University, USA, Oct.
(1971)
PR0ZESSZUST~DE
BEI ECHTZEITPROGRAMMIERSPRACHEN
P.RIEDER
I. Einleitun~ In den letzten Jahren sind eine ganze Anzahl verschiedener V o r s c h l ~ e fur Echtzeitprogrammiersprachen
entwickelt worden.
Typischer Bestand-
tell allsr dieser Sprachen sind Elemente, mit denen die AusfGhrung bestimmter,
jeweils sine Einheit bildender Komplexe von Anweisungen
in Abh~ngi~keit v o n d e r unterbrochen,
Zeit und anderen ~u~eren Umst~nden gestartet,
beendet oder sonstwie gesteuert werden kann. Diese Aus-
fGhrun~ ~ewisser logisch zusammengehSriger Anweisungen als ei~enst~ndiker Vorgang ist ~emeint, wenn im folgenden von Prozs~ die Reds ist. Schon in den ersten Sprachvorschl~gen wird bin und wieder vom Zustand sines solchen Prozesses gesprochen. Auf die Idee, das Proze~steuerungskonzept einer Echtzeitprogrammiersprache
systematisch durch Zust~nde
zu beschreiben,
1961 europ~ische Mitarbeiter
scheinen aber erst Mitte
an LTPL, der vom "Purdue Workshop on Standardization of Industrial Computer Languages" angestrebten
"Long Term Procedural L a n g u a g e " ~ e -
kommen zu sein. Bei einem Vergleich der nationalen S p r a c h v o r s c h l ~ e LAI (Frankreich),
PEARL (Deutschland),
RTS (England) und SINTRAN (Nor-
wegen) entwarfen sie ein Zustandsdiagramm mit 5 Zust~nden und versuchten, die Wirkung aller Proze~steueroperationen
dutch 0berg~nge zwi-
schen diesen Zust~nden darzustellen [I]. Von da an gehSrt die EinfGhrun~ yon ProzeBzust~nden und das Aufzeichhen von Zustandsdiagrammen bei der Definition einer Echtzeitprogrammiersprache
sozusagen zum guten Ton. Der folgende Vergleich eini~er
dieser Vorschl~ge wird jedoch zeigen,
dab die Kriterien fur die Unter-
scheidung der einzelnen Zust~hade recht willk~rlich festgelegt wurden. Was als eigener Zustand angesehen wird, variiert manchmal welt mehr als die daran zu verdeutlichenden ProzeBsteuerungskonzepte
selbsto
Der Hauptteil der vorliegenden Arbeit hat deshalb zum Ziel, Prinzipien fGr sine zweckdienlichere
Definition von Zust~ndsn herzuleiten und am
Beispiel der Sprache PEARL vorzufGhren.
Dies ~ibt Veranlassung,
sine
bei derartigen Sprachen naheliegende Unterscheidung der Begriffe Proze~ und Task vorzuschlagen.
Abschlie~end wird dann ~ezeigt, wie sich aus
sinem solchen wirklichkeitsnahen
Zustandsdiagramm umgekehrt wieder
Ansatzpunkte fGr die Verbesserung der Sprache selbst er~eben, und auf Konsequenzen fur zukGnfti~e Sprachentwicklungen hingewiesen.
414
2.
Bis,her,,i,g,e,,,V o r s c h l i ~ 9
Drei
der
bisher
'
entworfenen
Diagramme
zeigt
die
folgende
I
I~
Zust~nde
~
~
i~
nonexistent
.
I+~
~
t~
~
~ h0 o ~
.
.
~
.
~
4~
o
~
I ~
r.~
~.~
~
H-P
i~
~
~
~
~
,~,~
~4 ~
~
~
~h0
~o
~
~
~
.
/
.
.
.
+
+
-
-
-
/
-
+
+
&
&
-
/
&
active
+
+
_
_
+
/
.
suspended
+
+
-
-
-
/
-
nonexistent
.
dormant
+
.
idle
+
+
.
runnable
+
+
o
o
-
+
+
.
suspended
+
+
o
o
-
o
-
&
scheduled
+
+
&
&
_
/
.
.
running
+
+
o
o
+
+
.
.
dormant
+
+
.
Waiting on time
+
+
-
. .
. .
. .
.
I +~
mR
existent
.
~
.~o)
potentially active
.
C~
+~
~o
m-~ ~
~
~
~
~
\
I,
I ,r~
1 4~
4.~
Tabelle
. .
.
. .
.
-
.
.
.
.
-
-
-
-
&
&
.
. .
.
.
&
. .
.
-
& .
. .
.
¢~
.
.
.
.
.
0
.
.
.
& . .
&
. .
.
. .
&
&
. .
.
u
.
.
.
.
/
)
_
_
_
-
+
-
÷
-
-
-
-
+
o
-
o
-
/
/
waiting . . . . . . . . . . . . . . . . . on event + + o -
-
o
-
/
/ ,,,h,
~
waiting 0n release
+
+
.
runnable
+
+
o
o
-
+
running
+
+
o
o
÷
+
.
.
.
.
/
"2
+
/
/
-
/
. . . .
H
Die
Zeichen
-
-
-
bedeuten:
+
das
Merkmal
mu~
-
das
Merkmal
dar£
&
mindestens
o
das
Merkmal
darf
vorhanden
/
das
Merkmal
wird
nicht
eines
vorhanden nicht der
sein
vorhanden so
sein
bezeichneten sein
angegeben
oder
Merkmale fehlen
mu~
vorhanden
sein
415 Die in den ursprKnglichen
Zustandsdefinitionen
schaften wurden in dieser Obersicht Vorhandensein terungen
oder Fehlen von
der Merkmale
genannten
zum besseren Vergleich
12 Merkmalen
zurUckgefGhrt.
stehen Uber den einzelnen
geben an, welche Auspr~gung
Proze~eigen-
der Merkmale
Spalten;
auf das Kurze Erl~u-
die Zeilen
zu einem bestimmten
Zustand
gehSrt. Die Zeichen & bzw.
o dienen nur zur Verminderung
Man kSnnte den gleichen
Zustand
Zeilen reiner Ja/Nein-Entscheidungen sentlich
dies nicht Zustand zu gro~, chenden
Gber die Merkmale
ist nur, da~ unter Umst~nden
dener Ja/Nein-Kombinationen so w~re und
aufgefa~t
zusammen
einen Zustand
wGrde,
Die Auffassungen wesentlich
voneinander
In dem erw~hnten
Zust~nden
Diagramm
sind, weichen aber z.T. genUgt
es, einige weni-
zu betrachten.
der Europ~ischen
einer gewissen
tralprozessor
oder sonstige
ially active"
zusammengefa~t;
nisse kennzeichnet
LTPL-Entwickler,
Demgegen~iber wird
dem ersten
gerechnet.
mit dem Warten auf den Zenzu einem Zustand
"potent-
"suspended". Vorschlag
im 0ktober
- yon P.Lindes
auger dem Zentralprozessor Die Gbrigen
bei einer Ta-
1971 vorgelegt [2 ] - das Warten in "potentially
teilt Lindes auf zwei Zust~nde
mit zum Zustand active"
auf, n~mlich
enthaltenen
"scheduled"
das Warten auf den Start dutch ein Signal oder die ErfUllung Zeitbedingung
umd "runnable"
tralprozessor.
fGr das Warten auf nichts
Neu eingefGhrt
schen "dormant"
und "idle";
benen MSglichkeit, auszufUhrenden
wurde von Lindes
sie erfolgte
Tasknamen-Gr~Ben
Anwelsungen
Signal
das Warten au£ die Ubrigen vier Ereig-
im n~chsten
auf alle Betriebsmittel
Zeitspanne
Betriebsmittel
den Zustand
gung des Purdue Workshop
Wartef~lle
zuzuordnen
dem gleichen
wird das Warren auf den Start durch ein ~u~eres
oder den Ablauf
"suspended"
Merkmalskombinationen
ab. Um dies zu zeigen,
ge Zeilen in der Tabelle n~her
der Ubersicht,
viel
der entspre-
zu sein.
darGber~welche
und welche verschiedenen
Wenn
als eigener
Zust~nde
des Proze~modells
We-
verschie-
definieren.
w~re die Anzahl verschiedener
vom Nutzen
viele
darstellen.
erst eine ganze Anzahl
jede zul~ssige Merkmalskombination
um noch fur die Beschreibung Sprache
der Schreibarbeit.
jeweils auch dutch entsprechend
fGr
einer
als auf den Zen-
die Unterscheidung
wegen der z.B.
zwi-
in PEARL gege-
erst bei der Aktivierung
mit den
zu verknUpfen.
Den AbschluB
der Obersicht
nes Diagramm die Merkmale
wom November 1973 [4].Es zeichnet sich dadurch aus, dab "wartet auf Signal", "wafter auf Zeitablauf" und "wartet
auf Fortsetzbefehl"
bildet
ein fur Proze~-FORTRAN
nicht wie sonst dem gleichen,
vorgeschlage-
sondern drei vet -
416 schiedenen
Zust~inden zugeordnet
salt, da~ ein Proze~ tel verliert,
w~hrend
Warten auf andere Zuteilung
on event"
on release"
von Betriebsmitteln
an Hand von Priorit~ten
tens auf Synchronisation
ist jedoch
beabsichtigt.
Der We£fall
des War-
da es in Proze~-
gibt.
an Zustandsdefinitionen
Nur wenige Abweichungen schieden
darf.
ist; an sich ist eine
ist dagegen berechtigt,
FORTRAN keine Synchronisationsoperationen 3. Forderun~en
bei "waiting variieren
als den Zentralprozessor
was sicher ein Versehen
ge-
alle Betriebsmit-
je nach Betriebssystem
Betriebsmittel
vorgesehen,
Dabei wird ausdrGcklich
"waiting
die Zuteilung
on time" und "waiting nirgends
werden.
im Zustand
zwischen den Zustandsmodellen
in den zugrundeliegenden
sind mit Unter-
Programmiersprachen
zu erkl~ren.
Sonst mGBte wenigstens der Lindes'sche Vorschlag, der erkl~rtermaBen als universelles Modell fGr alle damals vorliegenden Echtzeitpro~rammiersprachen
gedacht
dem 4 Spezialf~lle
war,
solcher
ist abet offensichtlich
eine 0bermen~e Sprachen
run~skonzeptes
Zust~nde
bestimmt wird.
~e Gber alle relevanten An~aben Gber bestimmte bemerkt.
Spraehe
relevant,
beitragen,
unwesentlicher
DaB der Begriff Ei~enschaften Merkmale
Was in den bisheri~en
ist manchmal
zum Verst~ndnis
von Merkmalskombinationen
dutch die Ubereinstimmung M@rkmale
Teilaspekte Zustand
Vorschl~gen
nut besa~t,
bedeutsam
Beispiel
Signal,
auf das Verstreichen
sollte,
als Zustand
wurde nicht
bezeichnet
wird,
die an einem Proze~ in der betreffenden
"suspended",
ProzeB wartet.
mu~ man aber zus~tzlich einer Zeit,
sind wirkungslos,
der praktisch
Um diesen Wartezustand
noch wissen,
ob auf ein
auf einen expliziten
befehl, auf eine Synchronisationsoperation eines bestimmten Betriebsmittels gewartet zite Fortsetzbefehle
die Aussa-
und daher einzelne
machen
dafGr ist der Zustand
zu k~nnen,
der verschiedenen
sind.
da~ der betreffende
beenden
allzu sehr
ei~entlich
impliziert
GberflGssig
dab
ist die Tatsache,
n~mlich fGr die Wirkung von Anweisungen
Ein typisches
in Dies
des Proze~steue-
zu Zust~nden
nur eine yon vielen Eigenschaften,
Programmiersprache
sein,
sollen.
und zugleich der Grund dafGr,
nur weni£
der jeweiligen
da~ die Zuordnung
werden
nicht der Fall.
Ursache der meisten Abweichun~en die eingefGhrten
des europ~ischen
beschrieben
Fortsetz-
oder auf die Zuteilung wird. Noch so viele expli-
wenn der Proze~
in Wirklich~
keit auf das Ende einer Zeitspanne wartet. Merkmale, lassen,
die die gleichen
Steueranweisungen
wie diese verschiedenen
unterschiedlich
Wartevorschriften
wirken
den expliziten
Fort-
417 setzbefehl,
sollten unbedin~t
verschiedenen
den, wie dies bei ProzeB-Fortran
~eschehen
noch das Warten auf Betriebsmittel Wird
immer konsequent
binationen die Wirkung
darauf ~eachtet, Untersehiede
yon Anweisungen
belle aufstellen,
angegeben
werden.
da~ verschiedene
zusammengefaBt haben,
wird,
Merkmalskom-
werden, w e n n die
in der Auspr~gung
keinen Einflu~
wer-
ist. Dort mGBte allerdin~s
der Merkmale
auf
so kann man sine Ta-
in der zu jedem Ausgangszustand
Proze~steueroperationen
zugeordnet
mehr berGcksichtigt
nur dann zu einem Zustand
dabei vernachl~ssigten
Zust~nden
fGr alle m~glichen
in welchen
Zielzustand
sie fGh-
ten. Da~ sine derartige "Ubergangstafel" wesentlich mehr als die bloke EinfGhrung von Zust~nden dazu beitr~gt, die Beschreibung des Proze~steuerungskonzeptes
einer Echtzeitpro£rammiersprache
leicht verst~ndlich
zu machen,
Als Voraussetzung Zusammenfassung stimmen,
und
liegt auf der Hand.
dafGr ist offenbar nut n~tig,
zu Zust~nden
Gbersichtlich
die Merkmale
so auf die Steuerungsoperationen
und ihre abzu-
da~ gilt
I. Die Wirkung
der 0perationen
Ausgangszustand
sich als Ubergang
zu einem Zielzustand
2. Der dutch eine Operation vom Ausgangszustand 3. Bei verschiedenen
von einem
darstellen;
zu erreichende
Zielzustand
fGhrt mindestens
system automatisch
zu verstehen,
ausgeGbten
sine Ope-
Zielzust~nden.
sind dabei nicht nur die in der Sprache
Proze~steueranweisungen
h~ngt nur
ab;
Ausgan~szust~nden
ration nach verschiedenen Unter 0perationen
l~t
enthaltenen
sondern auch die vom Betriebs-
Nebenwirkun~en
anderer Anweisungen
auf
Prozesse. Von der ersten Forderung gramms Ausnahmen
mu~ man im Interesse
zulassen;
dies hat nur zur Folge,
male dutch das Zustandsmodell schla~gebend
nicht
durch den Wegfall
w~hrend
Dia-
da~ gewisse Merk-
erfaBt werden.
ist die zweite Forderung,
wisse 0ptimierung
eines einfacheren Eigentlich
aus-
die dritte nur eine ge-
GberflGssiger
Zust~nde
bedeutet.
4. Anwendungsbeispiel. Die folgende vom April
Tabelle
2 gibt ein Proze~modell
1973 [ 3 ] wieder,
entwickelt
wurde.
de; sie ergeben einem Proze~
das nach den eben abgeleiteten
Es enth~It~Zust~nde,
darunter
sich aus 3 verschiedenen
einzeln oder in beliebiger
hen, n~mlich Warten auf Synehronisatlon, stimmten
Zeitspanne,
fGr den Pearl-Vorschla~ allein
Grunds~tzen
7 Wartezust~n-
Warteverpflichtungen, Kombination
auferle~t
die sein k~n-
Warren auf das Ende einer be-
Warten auf einen expliziten
Fortsetzbefehl.
Zur
4~8
Beendigung n~mlich auf
der
eine
Wartepflicht
Nebenwirkun~
Synchronisation,
systems chef
beim
ein
Warten
Fortsetzbefehl
Wirktung wird,
jeder
Tabelle
ein
einer AnstoB
auf
das
aus
einem
dieser
entspricht
temerk~nale
fGhrt
der
eigener
nut
die
passende
Synchronisationsoperation aus
Ende
der
einer
anderen
Operationen
wegen
jeweils
Zeitspanne
davon
obigen
beim
Zeitverwaltung
Proze~
im
abh~ugt,
Forderung
2
und
des ein
dritten ob
ausdrGckli-
sie
der
Warten
Betriebs-
Fall.
auf
jedem
Operation,
Da
die
gewartet
erw~hnten
War-
Zustand.
2
\ nicht
definiert
vereinbart
+
o
-
-
-
o
eingeplant
+
+
&
&
-
o.
konkurrierend
+
+
o
o
o
o
~
o
angehalten
+
+
o
o
-
o
-
unterbrochen
+
+
o
o
-
o
doDpeibehlndert
+
+
o
o
-
verzSgert
+
+
o
o
angehalten und verzSgert
+
+
o
+
+
+
+
unterbrochen und verz~gert do~pelbehindert una verz~ger~ Zu
Kombinationen
aus
anderer
weisun~ alle
dieser
Ursache
wird.
Wartemerkmale
der fGr
/
-
-
/
-
-
-
/
-
-
-
+
/
-
-
-
-
-
/
-
+
o
-
-
+
/
-
+
-
o
-
-
-
/
+
-
o
-
o
-
-
+
/
+
-
o
o
-
o
-
-
-
/
+
+
o
o
-
o
-
-
+
/
+
+
Warteverpflichtun~en
wartender
Bevor
-
Proze~
betroffene sich
durch
.
kommt
Ziel
Proze~
.
-
einer
-
.
es,
wenn
DELAY-oder
weiterlaufen
entsprechende
ein
schon
SUSPEND-An-
kann,
0perationen
mGssen beseiti£t
werden. DaB
man
braucht~ die
nicht
~hnlich
sondern
mit
Betriebsmittel
werden
k~nnen.
Ob
in ein
viele
Zust~nde
"konkurrierend" PEARL Proze~
nicht gerade
fur
das
allein explizit auf
Warten
auf
Betriebsmittel
auskommt,
lie~t
angefordert
und
Betriebsmittel
daran,
da~
frei~e~eben
wartet
oder
Gber
419
alle benStigten verfUgt, hat auf die Wirkung von PEARL-Anweisungen yon der Definition der Sprache her keinen EinfluB. FUr die Beschreibung des ProzeBsteuerungskonzeptes wird daher sin getrennter Zustand "laufend" nicht gebraucht. Unbedingt erforderlieh ist dagegen der Zustand "eingeplant". Er kann mit keinem der besprochenen Wartezust~hude zusammengelegt werden, da nahezu alle Operationen anders, meist gar nicht wirken, wenn sich ein ProzeB im Zustand "eingeplant" befindet. Er kann dann z.B. nicht durch DELAY verzSgert oder durch TERMINATE am Ablauf gehindert werden. Die weitere Auftei!ung danach, ob der Start durch ein Signal oder durch Zeitablauf veranla~t werden soll, ist dagegen nicht sinnvoll. Da beides in PEARL in beliebiger Kombination und Vielfachheit verlangt werden kann, br~uchte man fur eine Beschreibung unbeschr~hqkt viele Zust~nde. Man fUhrt deshalb zweckm~igerweise eine besondere Einplanungsliste ein und unterscheidet durch den Zustand nur, ob diese Liste leer ist oder nicht. 5. 0ber~an~stafel FGr dieses Zustandsmedell l~2t sich jetzt auch eine Ubergangstafel aufstellen. Sie gibt Auskunft darUber, wie 14 verschiedene 0perationen bei 11 mSglichen Zust~nden wirken. Nur ein Tell dieser Operationen ist dabei zeitlich direkt mit dem Durchlaufen gewisser Anweisungen gekoppelt; vielfach findet die AusfGhrung des durchlaufenen Statements erst bei sp~terer Gelegenheit statt, und manche 0perationen sind Gberhaupt nut indirekte Wirktungen bestimmter Anweisungen. Die folgende Liste z~hlt auf, bei welcher Gelegenheit die verschiedenen Operationen erfolgen (in Gro~buchstaben: PEARL-Elemente): Vereinbaren:
Wenn der Block mit der entsprechenden TASK- oder
Einplanen:
Wenn ein ACTIVATE mit Einplanungsliste (z.B. ALL 5
TASKNAME-Deklaration betreten wird; MIN) durchlaufen wird; Aktivieren:
Wenn ein ACTIVATE ohne Einplanungsliste durchlaufen wird;
Starten: Unterbrechen:
Wenn der eingeplante Anla6 gekommen ist; Wenn ein SUSPEND ausgefUhrt wird;
Anhalten:
Wenn die AusfUhrung einer Synchronisationsfunktion zum Warten zwingt;
Freigeben: Weiterf~hren:
Wenn die AusfGhrung einer Synchronisationsfunktion das Fortsetzen erlaubt; Wenn ein CONTINUE ausgefUhrt wird;
Beenden:
Wenn ein TERMINATE ausgefUhrt wird;
420
Absetzen: Streichen:
Wenn ein PREVENT ausgefGhrt wird; Wenn im AnschluB an eine Operation
Tilgen:
Wenn der Block mit der entsprechenden
VerzSgern:
Wenn ein DELAY ausgefGhrt
Enthemmen:
Wenn der Ablauf der Verz8gerungsfrist
nungsliste
"Beenden"
die Einpla-
leer ist;
Deklaration
TASK- oder TASKNAME-
verlassen wird; wird; das ?ortsetzen
erlaubt. Die angekiindigte Ubergangstafel Spalten darin entsprechen die Elemente
ist in Tabelle
den Zust~nden,
in den Kreuzungspunkten
Wirkung
der betreffenden
Tabelle
3
Operation
Die
symbolisieren
die
Zustand.
4
5
6
7
8
~
~
•
o
,.el
•H
~
~
~
~
(D
-r~
0
Einplanen
3
E
E
E
Aktivieren
4
4
F
Starten
-
4
Unterbrechen
iV
0perationen
2
Zeile - Spalte
beim jeweiligen
3
~
1
3 dargestellt.
die Zeilen den Operationen;
9
10
11
~
e~:o o : o
,..c~:o
~
:o
~ h.
~ ~-
~ ~,
E
E
E
E
E
E
F
F
F
F
F
F
F
P
P
P
P
P
P
P
P
N
6
7
N
N
10
11
N
IV
~
5
.
9
de
~ O
Vereinbaren
2
Anhalten ~reigeben
.
WeiterfGhren
-
N
N
Beenden
-
N
Absetzen
-
Streichen
.
.
.
.
.
.
.
.
.
4
-
N
N
4
5
N
N
8
N
3
3
3
3
3
3
3
N
2
E
E
E
E
E
E
E
E
-
-
2
.
VerzGgern
-
N
N
8
Enthemmen
.
.
.
.
.
.
.
.
Tilgen
.
.
.
.
9
.
10
.
11
N
N
N
N
4
5
6
7
421
Dabei zeigt sich ein weiterer wichtiger Vorteil der ~berga~gstafel gegenGber dem Zustandsdiagramm allein: Statt des Zielzustandes (oder zus~tzlich) kann man erforderlichenfalls leicht andere Wirkungen der Operation angeben° Im vorliegenden Fall bezeichnen Zahlen die Spaltennummer des jeweiligen Zielzustands. Ein "-" zeigt an, da~ die Operation nicht vorkommt° Die Buchstaben bedeuten: F: Fehlerfall, Resultat nicht definiert; N: Die Operation ist wirkungsl~s; E: Die Operation bewirkt eine ~nder~ug in der Einplanungsliste; B:
Die Operation bewirkt eine 1~uderung in der BuchfUhrung Uber die Fortsetzzeit;
P: Der Start wird gepuffert. Auf Einzelheiten dieser Sonderwirkungen kann hier nicht eingegangen werden. 6. Proze~ und Task Die EinfUhrung der Operation "Streichen" stellt bei genauer Betrachtung einen Kunstgriff dar, um auch fur die Operation "Beenden" die obige Forderung 2 erfUllen zu kSnnen° Bei Lindes fUhrt noch "terminate" in den Zustand "scheduled", wenn weitere Starts eingeplant sind, und in den Zustand "dormant", wenn dies nicht der Fall ist. Im vorliegenden PEARL-Modell wird dieses "terminate" in die zwei getrennten Operationen "Beenden" und "Streichen" aufgeteilt, von denen die erste in den Zustand "eingeplant" und die zweite in den Zustand "vereinbart" fGhrt. Statt vom Inhalt der Einplanungsliste abh~ngen zu lassen, wie ein und dieselbe Operation wirkt, braucht jetzt nach dem gleichen Kriterium nur entschieden zu werden, ob nach der ersten, immer ausgefUhrten Operation "Beenden" automatisch noch eine zweite, eben "Streichen", folgen soll° Wenn diese zweite Operation "Streichen" jedoch nicht erfolgt und der Proze~ im Zustand "eingeplant" verbleibt, erhebt sich die Frage, was eigentlich beendet wurde. NatUrlich war es die zuletzt aktuelle DurchfUhrung der zum Proze~ gehSrenden Anweisungen; diese DurchfUhrung kann dann abet nicht mit dem weiter eingeplanten Proze~ identisch sein. Was unter Beibehaltung seiner Identit~t infolge gewisser 0perationen Zustandswechsel ausfUhrt, ist etwas anderes als die dynamische DurchfGhrung einer bestimmten Menge von Anweisungen; das Wort Proze~ sollte daher nur fur eines der beiden 0bjekte verwendet werden.
422
Da in den bisher
entwickelten
Echtzeitprogrammiersprachen-
ohnehin nicht von Prozessen, st~nden die Rede ist,
sondern h~chstens
liegt es nahe,
auch PEAEL-
von T~sks und ihren Zu-
die zweite
Alternative
zu w~hlen
und zu definieren: Ein ProzeB
ist die Ausf~hrung
mit gewissen
einer gewissen
Daten zu einer gewissen
DaB die Operanden yon Anweisungen meist als Task, eigentlich
jedenfalls
Zeit.
mit ProzeBsteuerungswirkung
nie als ProzeB bezeichnet
Namen erreicht
und Zeit ihrer Ausf~hrung blone dieser Prozesse, dem Namen verknUpfte
mal den anderen individuellen
angegeben wird,
n~mlich
ist h~chstens
der - m~glieherweise
Code und der AdreBraum,
Schablone
nung Proze~ Umgekehrt
verstehen,
fur die Operanden
nur momentan
fiziert werden.
- mit
Realisierung
so w~re die Bezeich-
am Platz. Sprachen
Durchftthrung gewisser Anweisungskomplexe
Unter dem Aspekt
der ProzeBschablone
identi-
scheint
es ange-
zu definieren:
Eine Task ist die Zusammenfassung sungen,
einer gewissen
die sich auf einen festen Datenraum
informationen Anweisungen Die exaktere
~ber die bisherige
als mindestens
Menge von Anwei-
beziehen,
und zukGnftige
mit Steuer-
AusfGhrung
Definition yon ProzeB und Task zwingt keineswegs
Wartezustande
z.B.
fallen zu lassen.
abet einem ProzeB
zugeschrieben
Proze~
in Verbin-
aller durch die Task repr~sen-
Da es jedoch Zust~nde
ist es einfacher,
dazu,
Die verschiedenen
sind eher mit einem individuellen
dung zu bringen als mit der Gesamtheit tierten Prozesse.
dieser
ein ProzeB.
den Begriff des ProzeBzustandes
nioht
selbst,
sollte Task nicht wie in PEARL und einigen weiteren
mit der dynamischen
messen,
sondern diese
die ~cha-
auf den er sich bezieht.
W~rde man unter dem Begriff ProzeB nicht die individuelle dieser
ist
gerechtfertigt:
man je nach Art der Anweisung
mal den einen,
Was in der Anweisung
bisher
wurden,
nur bei der eben eingeftthrten Definition
Unter ein und demselben ProzeB.
Menge yon Anweisungen
gibt,
die zwar einer Task,
werden k~nnen
die Zust~nde yon vornherein
(z.B."vereinbart"),
auf Tasks zu beziehen.
7. Sorachverbesserung Die Aufstellung besprochenen
eines Zustandsdiagramms
Grunds~tzen
Sprachbeschreibung, werden
sollte:
mit ~Jbergangstafel
stellt ein Hilfsmittel
dar, das nicht nut zur
sondern auch zur Sprachverbesserung
Wenn man auf grund einen vorl~ufigen
ProzeBzustandsdiagramm
erarbeitet
nach den
eingesetzt
Definition
hat und dann fe~tstellt,
ein
dab es un-
423
n~tig komp!iziert ist, nachtr~glich die Semantik der 0perationen so zu ~ndern, dab eine Vereinfachung des Diagramms eintritt. Dies ist ~Lu PEARL geschehen, und zwar dadurch, dab definiert wurde: Es ist gleichgGltig, ob auf den Ablauf einer Zeitspanne oder auf einen expliziten Fortsetzbefehl gewartet wird. SUSPEND auf eine Zeitablauf wartende
Task
schon auf
bewirkt keinen Zustandswechsel. Umgekehrt
hat CONTINUE die Fortsetzung einer Task auch dann zur Folge, wenn diese zun~chst auf den Ablauf einer noch nicht verstrichenen Zeitspanne wartete. Bei der beschriebenen Umdef~nition von PEARL werden also die Zust~nde "unterbrochen" (wartet auf Fortsetzbefehl) und "verzSgert" (wartet auf Zeitablauf) zusammengelegt. Dies macht auch die kombinierten Wartezust~nde "angehalten und verz~gert",
"unterbrochen und verz~gert" und
"doppelbehindert und verzSgert" hinf~llig,
so da2 yon Tabelle 2 nut
die ersten 7 Zeilen flbrig bleiben. Entsprechend k~nnen in der tibergangstafel yon Tabelle 3 die letzten 4 Spalten und auch die beiden letzten Zeilen entfallen. Das zugeh~rige einfache Zustandsdiagramm zeigt die folgende Figur.
doppelbehindert
ni cht definiert
~
unterbrochen
~
angehalten
vereinbart ~
~_~
einge~lant
konkurrierend
Welche Operationen zu den Zustandswechseln ~ h r e n ,
steht in Tabelle 3.
424
8. Liter~turhinweise [ I ] Minutes of the 4th Technical Meeting of the LTPL European Grou~ Reading, England (Juni 1971) [2]
P. Lindes, Tasking Facilities: Minutes of the Sixth Worksho~ on Standardization of Industrial Computer Languages, 80-90. Purdue Laboratory for Applied Industrial Control, Purdue University, Lafayette/Indiana (Oktober 1971)
[ 3]
K.H. Timmesfeld, B. Sch~rlein, P. Rieder, K. Pfeiffer, G. ~iller, K. Kreuter, P. Holleczek, V. Haase, L. Frevert, P. Elzer, S. Eichentopf, B. Eichenauer, J. Brandes: PEARL, A prGposal for a process- and exDeriment automation realtime language. PDVbericht K~K-PDVI, Gesellschaft f~r Kernforschung mbH Karlsruhe (April 1973) Dort weitere Literaturangaben.
[ 4]
ad-hoc-Arbeitskreis "PrGze~-FORTRAN" des VDE/¥DI-Ausschusses "Programmiertechnik": PrGposal for Task Management. Private ~itteilung (NGvember 1973)
PROCESS BASIC - EIN PROGRAMMIERSYSTEM FOR PROZESSLENKUNG MIT KLEINRECHNERN Frledrich Wagner, Dr.Helmut Woda
Einleitung Seit der Entwicklung und EinfiJhrung h6herer Programmlersprachen fur den Rechenbetrieb mit Standardperipherie ist immer wieder der Versuch unternommen worden, diesen Schritt auch bei Prozel3rechnern zu macheno Dal3 bei dieser Rechneranwendung heute noch die Programmierung in symbolischer Maschlnensprache (Assembler) weit verbreitet ist, ist auf die Schwierlgkelt zu-
rUckzuRJhren, mit einer h~heren Programmsprache die Vielfalt der an einen Proze~3rechner anzuschliel3enden Ger~ite zu bedleneno Versuche, bereits bestehende Sprachen RJr ProzeBrechner verwendbar zu machen, hatten uneinheitllche Sprachgebilde zum Resultato Eine Prozel]sprache kommt ohne maschinennahe Ausdrucksmittel nicht auso FL~rviele, mit der Prozel31enkung verbundene komplizier~ere Berechnungen ist abet die Assemblerdarsteltung zu umst~ndlich und zeitaufwendigo Hier ist eine h~here Programmiersprache unerl~ssllcho Eine Prozel3sprache mull sowohl problemnah als auch maschinennah sein. Diese Bedingungen k~nnen dann am besten erfUllt werden, wenn Assembler (maschinennah) und eine h~here Programmsprache (problemnah) zu elnem geschlossenen Programmlersystem integriert werdeno PROCESS BASIC setzt sich aus der Maschlnensprache, Makroinstruktionen und BASIC zusammeno
Diese 3 Sprachebenen sind zeilenweise mischbaro Die in elner der Ebenen definierten symbolischen Namen sind auch in den belden anderen gUItig. Das System enth~ilt komfortable Makrolnstruktionen und vlelseltige, reichhaltige Ein- und Ausgabem~glichkeiteno Der 0bersetzer arbeitet generativ, da man bei einem interpretativen Ubersetzer einen erhebtlchen Verlust an Programmlaufzeit in Kauf nehmen m~Jsste. Das Obiektprogramm kann im Ein-Phasen-Verfahren direkt im Kernspeicher generlert oder in einem verschiebbaren Code auf einem Externspelcher abgelegt werden. Der Binder I~dt den verschiebbaren Obiektcode und verknupft ihn mit weiteren Objektprogrammen und I~st programminterne und -externe Referenzen auf (1/2 Phase)°
Es hat sich gezeigt,, da~ es yon grol~em Vorteil ist, Sprache und Betriebssystemgleichzeitig zu entwickeln.. Das Betriebssystemsieht einen programmierten E/A-Prozessor im Cycle-SteallngModus zur slmultanen Ein/Ausgabe bellebiger Informationsmengen auf mehreren Ger~ten mlt Formatierung (fUr Standard- und nicht Standardperipherieger~te) und elne priorit~tsgesteuerte
Interruptorganisatlon mit bis zu 12 Anwendungsprogrammebenen voro lm Kern des Betriebssystems sind elnfache SoFtwareschnlttstellen so definlert, dal3 vom Anwender gefahrlos iederzeit ~,nderungen der Gerdteorganisatlon und der Anschlul] weiterer Gerdte vorgenommen werden k~nneno
426
FUr BASIC ist elne Laufzeitunterstgtzung (Indexrechnung etc.) erforderlich° Diese wird vom LauFzeitsystem durchgeflJhrt. Ein Testmakro, das an beliebiger Stelle des Programmes und auf allen Interruptebenen eingesetzt werden kann, erm~glicht die fJberprgfung und Ver~nderung von Daten und Programmen zur Laufzeit° Um PROCESS BASIC der praktischen Erprobung zug~ngllch zu machenr wurde es auf einer UNICOMP 201 implementiert. [ 1 ] Alle genannten Systemteile: Betriebssystem, Ubersetzer, Binder und Laufzeltsystem sind in 8k/20 bit Kernspeicher untergebracht. Sie slnd so konzipiert, dad sie in ROM-Speichern elngefroren werden k~nnen. Dadurch wlrd der Stand-Alone-Betrieb (Programmerstellung, -test und -ablauf auf den Klelnrechner) wlrtschaftlicht dessen Vorz~Jge durch die gegenw~rtlge Entwlcklung (Speicher werden immer billiger) starker zum Zuge kommen werden° 1. Das Programmiersystem PROCESS BASIC ist ein Prograrnmiersystemr das die parallele Verarbeitung mehrerer Programme gestattet. Ein Prograrnm kann zus~tzllch zum Hauptprogramm bis zu 12 Interruptroutinen (Interruptebenen) enthalteno Das Hauptprogramm und iede lnterruptebene besitzen einen Stack zum Speichern von Zwischenergebnissen. PROCESSBASIC setzt sich aus 3 Sprachebenen zusammen° Jede Anweisung ist einer von ihnen zugeordnet°
Die Sprachebenen haben folgende Eigenschaften:
1.1 Maschinenbefehle Unter dleser Kategorle slnd alle Funktionen zu finden, die Ublicherwelse auf e~nen Rechner elngebaut sind, z.B° Register laden, umspeichern, addieren, sprlngen. Sie haben folgenden Aufbau: (Operatlonscode), (Modifikation), (Operand). Mit Hilfe der Modifikation kann die Adresslerungsart und die Operandenherkunfl ausgew~hlt werden° Die Schnittstellen zur Rechnerperipherie slnd f'gr Maschinenbefehle unmittelbar verF~Jgbar° t °2 Makroinstruktionen Es sind 46 Makrolnstruktionen vorgesehen° Ihrer Funktion nach bestehen sie aus 4 Gruppen:
427 a) Arlthmetische Makroinstruktionen b) Funktions-Mak rolnstruktionen c) Realzeit-Makroinstruk tlonen d) Ein/Ausgabe-Makroinstruktionen Sie haben folgenden Aufbau: (Befehlscode), (Adre~typ), (Operand), (Indexspezifikation). Der Adrel3typ gibt die Operandenherkunft (Konstante, Programmspelcher, Datenspeicher) und den Datentyp 0¢Vortl~nge, Integer, Floating Point) an° AIs Operanden k~nnen demnach z~B° auch Gleitpunktzahlen auftreteno Die Indexspezlfikation erlaubt sowohl indlrekte Adresslerung wie auch automatische Inkrementierung bzwo Dekrementierung von indizierten Adressen. Die M~glichkeiten der Operandenherkunft, des Datentyps und der lndizlerung sind frel mischbaro (AdreBtyp) und (lndexspezit:ikation) k~nnen entfallen, sie werden dann aufomatisch zugeordneto 1°2.1 Arithmetische Makroinstruktionen Diese enthalten die 4 Grundrechnungsarten, Laden in und Umspeichem aus dem Akkumulatorregister sowie alle Shlftoperationen. Diese Operationen k~nnen auch entsprechend den SpezifikaHonen des elngesetzten Rechners dutch Maschinenbefehle ausgeRJhrt werden. Stlmmen die Datentypen der beiden Operanden einer arithmetischen Operation nicht Uberein, so erfolgt automatisch eine Datentypwandlung in Richtung gr~erer Zahlenbereicheo Die AusfUhrung der Operation wird in der dem Datenfyp entsprechenden Arithmetik durchge~:~Jhrt (integer, Gleitpunkt) o Bei der lnstruktion "Umspeichem" enColgt, wenn erforderlich, eine Wandlung gemdi~ dem Datentyp der Zieladresse,
Belspiel: DIMENSION E * A ; D * B
A als Integer-Einwort-, B als Integer-Doppelwortvariable definieren
BRA
A
Lade A in das Akkumulatorreglster
MUL
B
Multipliziere mit B (Doppelwortinteger)
UMA
C
Ergebnis nach C (als Gleitpunktzahl)
Durch die Dimensiondeklaration wurde A als E~nfach-, B als Doppelwort-lnteger festgelegt° Das
428
Ergebnis steht auf Adresse C als Gleitpunktzahl, da die Variable C nlcht deklariert und daher impliziert als Gleltpunktvarlable elngestut:t wurde.
AIs Operand kann auch der Stack der [eweillgen Ebene angegeben werden.
Beispiel :
BRA
A
Lade A in das Akkumulatorreglster
DIV
*
Divisor aus dem Stack; Divission ausfiJhren
UMA
*
Quoflenten in den Stack speichern
Die von Adresse A geladene Gleitpunktzahl wird durch das n~chste Stackelement dividiert und das Ergebnis im Stack gespeichert. Der Stack arbeitet nach dem Prinzlp: last in - first out°
1o2o2 Funktlons-Makroinstruktionen
Unter dieser Gruppe sind eine Reihe von Ublichen Funktionen realisiert, Datentypwandlung, Winkelfunktionen etc,°
t .2.3 Realzeit-Makroinstruktionen
Durch diese Makrobefehle wird die Zuordnung und Steuerung der Interruptroutinen festgelegt und durchgefiJhrt. Es k~nnen 12 lnterruptebenen definiert werdenr die priorlt~tsgesteuert sind. Der Start eines Interruptprogrammes |st entweder auf ein externes Signal oder auf den Start eines programmierten Interrupts (Makro) zur~JckzufUhren° Beim programmierten Interrupt kann der Start um elne programmgesteuerte Zelt verz~gert werden (Zeltauftrag) o E~n Interruptprogramm kann fur eine programmgesteuerte Zeit verlassen werden (zyklische W~ederholung eines Programmes, Verz~gerungen) 0 Wdhrend des Programrnablaufesk~nnen einzel ne oder alle lnterruptebenen fur die AusfUhrung gesperrt oder zugelassen werdeno
1 ° 2 . 4 Ei n / A u s g a b e - M a k r o i n s t r u k t i o n e n
Durch diese Makroinstruktlonen wlrd die Ein-, Ausgabe (E/A)r die Zuordnung von Nurnmern zu Gerdten und die Meldung Uber den Ger~tezustand abgewlckelto Es k~nnen 16 Ein- und 16 Ausgabeger~te deflnlert werden. Der Arbeitsspeicher kann als Ein- und Ausgabeger~t spezlflziert werden° Die E/A kann simultan oder nichtsimultan in aktiven Ger~ten und Programmen mlt oder
429 ohne Codewandlung gepuffert, ungepuffert, sequentlell oder random erfolgeno Die Ausgabe kann ~hnllch FORTRAN formaHert werdeno
Der E/A-Prozessor ist elne elgene Systemebeneo Er kann von jeder Programmebene gestartet wetden o
Durch den Aufruf von Definltionsmakros werden weitere Ger~te angeschlossen. Dabei k~nnen vom Anwender erstellte Ger~teroutinen in die E,/A-Organlsation elngebettet werdeno Dem E/A-Prozessot sind maximal 32 Ger~te bekannt. Am Systemkern k~nnen darUber hinaus weitere Ger~te angeschlossen seino
1.3 BASIC
BASIC ist fur PROCESS BASIC in bezug au{: die ubtlchen sprachlichen Darstellungsm~glichkeiten wesentlich erweitert worden. Hier ist die Verarbeitung symbollscher Namen als "Labelnumbers", die Verwendung beliebiger symbolischer Namen fur Variable und die Verarbeitung von 4 Datentypen zu nennen. Die Vorschrifb eTne Labelnumber ie Anwelsung zu verwendenl entF~llto Die bei der Schleil:enverwaltung (FOR - NEXT) und der lndexrechnung bei indizlerten Variablen verwendete Arlthmetik wird durch den Datentyp der (Schleifen-)Varlabten bestimmto Input und PHnt wurden wesenfl ich komfortabler gestalteto
Eine in BASIC erstellte Anwelsung wird vom (Jbersetzer in eine Sequenz von Maschinen und Makrobefehlen aufgel~sto FUr besondere Funktionen (Indexrechnung, Schleit:enorganisation) steht ein Laufzeitsystem zur VerfiJgung. Anforderungen des Laul:zeltsystemstreten im Code als Erwelterung der Menge der Makroinstruktionen in Erscheinungo
Wird elne Ebene h~herer Prioritdt gestarte b so wird die AusfUhrung einer BASIC-Anweisung an jeder beliebigen Slelle unterbrochen und nach Beendigung des Interruptprogrammes fortgesetzto
Durch dle Anweisungen Common und Dimension wlrd sowohl fur BASIC als auch fur den Makroteil
und fur Maschinenbefehle die Speicheraufteilung sowie von der Gleitpunktdarstellung abweichende Datentypen der Variablen festgelegt. Auf ein einfach oder zweifach indizlertes Feld kann sowohl mit BASIC als auch rnit Makrobefehlen mit lnkrementlerung oder DekremenHerung sowle mit Maschlnenbefehlen zugegriffen werden0 Unmittelbar vor und nach elner BASIC-Anwe[sung k~nnen Maschinen- oder Makrobefehle stehen.
430 2. Anwendungen yon PROCESS BASIC
Bei der Realisierung eines Computerelnsatzes'in der Prozei~lenkung haben die Eigenschaften der Peripherle und des Rechners grol~en Einflul3 auf den eingeschlagenen L~sungsweg. Die Assemblerdarstetlung RJr speziflsche Programmteile ist hler ein unerlasstiches Hilfsmittel° Selbst wenn das System "schl0sselfertig" war, ist es in vielen Fallen erforderlich, zur Beurteilung des Prozel3verlaufes und der Prozel3ergebnlssegenaue Kenntnisse der Lenkungsalgorithmen zu haben, sle zu verandern oder zu erweltern. In PROCESS BASIC sind daher die Funktionsebenen des Betrlebssystems fur die Programmlerung offen0 Im Folgenden soil Schritt fiJr Schrltt der Weg vom dlrekten Zugrif~: auf elne Prozel3schnittstelle bls zur Verwendung von BASIC aufgezeigt werden.
2.1 Zugriff auf eine Prozel3schnittstelle
Dieser Zugrifl: kann an beliebiger Stelle im Programm durch AusfiJhrung eines Maschinenbefehles ert:olgen.
2.2 Anschlul3 eines Gerates
Das zugeh~rlge Gerateprogramm kann getrennt oder als Teil des vom Benutzer erstellten Anwendungsprogrammes in den Kernspeicher geladen werden° Soil es seine Aufgabe ausRJhren, so wird es dynamisch 0bet eine einfache Schnittstelle an die Kette der bereits aktiven Gerateprogramme angehangt und am Ende seiner Tatlgkeit wieder abgetrennt.
2.3 Definition eines Gerates
Durch diesen Vorgang, fur den ein Makrobefeht zur Verf~Jgung steht, wlrd elne Geratenummer einem Gerdteprogramm zugeordnet und beide Informatlonen im Ein/Ausgabe-Prozessor eingetragen. Dadurch kann das Gerat mit den Ublichen Ein/Ausgabe-Makros angesprochen werdeno Alle Verarbeitungsmodi, wie in 1o2.4 ausgeFL~hrt, k~nnen in Anspruch genommen werdeno
2°4 Eingabe in BASIC
Nach AusfOhrung des Vorganges nach 2°3 ist die Eingabe in BASIC mlt der Anweisung INPUT unter Angabe der festgelegten Ger~tenummer m~glich° Dadurch kann zoB. die direkte E~ngabe elner vom Prozel3 gelieferten Information auf den angegebenen Spelcherplatz elner ~ndizierten Variablen erfolgen.
43i 2.5 Zeltoptimale inhere Schleil:en
Programmteile, die sehr oft durchlaufen werden, belsplelsweise die innerste Schlelfe in elnem Nest von I:OR-Schleifen, k~nnen zur VerkiJrzung der AusRJhrungszeit in Assembler geschrieben werden° Hier erm~gllcht die zeilenweise Mischbarkeit cler Sprachebenen in PROCESS BASIC elne optimale Codeauslegung. 3~ Das Betriebssystem
Das Betriebssystem fur PROCESS BASIC wurde glelchzeitig mit der Sprache entwickelt. Dadurch konnten die Nachteile und Einschri~nkungen vermieden werden, die bei nachtr~glicher Anpassung einer Sprache an ein bereits bestehendes Betriebssystem bel den Spracheigenschaften und durch eingefl~ckte Systemfunktionen entstehen k~nneno Die gleickzeitlge Entwi~klung war auch deshalb s~nnvoll, da wegen der bei Prozel3rechnern fur d~e Programmierung erwiJnschten Maschinenndhe das Betrlebssystem fiJr dle Anwendungsprogrammlerung leicht zug~ingllch sein sol lte.
Das Betrlebssystem von PROCESS BASIC enRJllt folgende Anforderungen: ° Simultanarbeit mehrerer Ger~te • Anschlul3 und Betreuung bellebiger Get,ire, flexible E/A-Verfahren • prlorit~itsgesteuerte Taskverarbeitung, flexible Taskstruktur . Verwaltung yon Zeitauftr~gen • lelchter und iJbersichtlicher Eingriff durch clie Anwendungsprogrammierung. Im folgenden soJten die belden wichtigsten Teile des Betriebssystems n~her beschrieben werden: 3°1 Zentrale Betrlebsmittelverwaltung Die
Benutzerinterrupterkennungund unmittetbare
Betreuung aller Ger~ite (z.Bo Ausgabe eines
Zeichens) ist auf der Systemebene h~chster Prioritdt angeordnet0 Fin periodischer Interrupt unterbricht in konstanten Zeitabst~nden das gerade laufende Programm und fiJhrt in die zentrale Betrlebsmittelverwaltung. Darln werden Aktivit~lten erkannt oder fortgesetzt sowie festgestellt, ob ein Benutzerinterrupt aufgetreten ist.
432 Auf dieser Ebene stehen 2 Zeitraster zur VerfLigung,
1 o die durch die lnterruptperiode gegebene Zeit, 2o elne Uhr mit einer Periode von 3 msec°.
Die Ger~teprogramme sind zu 2 Ketten zusammengefasst. Diese Ketten k~nnen verl~ingert oder an bellebiger Stelle ge~fFnet und weitere Ger~teanschlusse elngefUgt werden. Die Reihenfolge in der Kette kann ebenso nach den Anforderungen der ieweiligen Konfiguration ausgelegt werden. In der zentralen Betriebsmlttelverwaltung wird die BenutzeHnterruptorganisatlon durchgefUhrto Die einzelnen Interruptroutinen sind hler nach elner Liste von Zust~nden eingeordnetl nach denen die Ablaufsteuerung erfolgt. Eine Interruptebene kann folgende Kennze~chnungen aufweisen:
a) nicht vorhanden b) gesperrt c) startbar (Start noch nlcht m~glich, da die laufende Ebene h~here Priorlt~it hat ocler erst elne speziflzierte Zeitspanne verstre~chen muB) d) latent (Fortsetzung erst bei extemem Signal oder programmiertem Interrupt oder nach Ablauf einer spezifizierten Pausenzeit) e) unterbrochen (durch eine Interruptebene h~herer PrioHt~tt oder durch den E/A-Prozessor) F) aktivo 3o2 Der Ein/Ausgabe-Prozessor Der E/A-Prozessor ist eln Systemprogrammr das die Aufbereitung von Informafionselnheiten zu Einzelzelchen (nach einer Formatliste) bzwo die Auf'arbeitung von Einzelzeichen zu lnformationseinheiten (Konstante, Hexstring, Name, Text) erm~gllcht. Er arbeltet auf elner Systemebene variabler Priorit~t. Er ist das Bindeglied zwischen den Gerdteprogrammen der zentralen Betriebsmlttelverwaltung und den Ein- oder Ausgabe-Makroinstruktionen des Anwendungsprogrammes0 0ber den E/A-Prozessor kann die Simultanarbeit von 16 Ein- und 16 Ausgabegerdten abgewickelt werdeno Bel der Definition eines Ger~ttes fur den E/A-Prozessor erfolgt die Zuordnung elner Gerdtenummer zu einem Ger~teprogrammo Diese Zuordnung kann w~hrend des Programmablaufes jederze~t neu festgesetzt werden0 Ein vom Anwender selbst erstelltes Ger~teprogramm kann uber eine einfache Schnittstelle in das System eingebettet werdeno Von der Hauptprogrammebene und von ieder der 12 Interruptebenen kann elne Ein- oder Ausgabe gestartet werdeno Erfolgt sle, wie in 2o 1 und 2°2 beschrieben, wird sie unmittelbar ausgeRJhrt.
433 En%lgt sie nach 2.3 und 2.4, wlrd erst der E/'A-Prozessor gestartet. Dadurch wird die Ebene als Ebene mit Ein/'Ausgabe gekennzelchneto Sie kann vom E/'A-Prozessor unterbrochen werdeno Der E/'A-Prozessor ist daher immer nur dann aktlv, wenn noch nlcht alle E/'A-Auftrage abgearbeltet slnd und ,die aktive Ebene das E/'A-Kennzelchen tragto Auf dlese Weise ist sichergestelh, dab elne Interruptebene, die mit m~gllchst geringer Verz~gerung auf elne lnterruptbedlngung reagieren soil, vom E/'A-Prozessor nlcht unterbrochen werden kann.
Die dabei entsfehenden zeitllchen Verhaltnisse slnd in dem folgenden Zeitdlagramm an 2 Ebenen dargestellt:
Priorit~t Programm
12
6
mit Priorit~t
E/A
:
3
I"
/t '1,,,
3
Programm mit Priorit~Jt
ROckkehr zu Ebene 3 E/A Prozessor /
Prozessor
i
I
\ I
5
I
V-"
1 0
Gerdtenummer
1 2
T Jr
I
Gerat aktiv Start der Ein IAusgabe auf Gerd'[ Nr. 1
S tart der Ein/Ausgabe aut Gerat Nr. 2
~-Zeit Ausgabe beendet
4. ~bersetzer und Binder
Der (Jbersetzer arbeitet generatlv, da bel der Interpretation des Quellprogrammes zur Laufzeit Zeltverluste und Einschr~inkungen des Echtzeitverhaltens entstehen. Der [Jbersetzer ist eln 1Phasen-Ubersetzer, wenn das Programm direkt in den Kernspeicher genedert wird, oder ein 1 1/2-Phasen-Ubersetzer, wenn er elnen verschlebbaren Objektcode auf einem Externspeicher ablegto In der 1/'2 Phase werden vom Binder die noch nicht aufgel~sten programmlnternen und -externen Referenzen bearbeltet.
434
Das Programm besteht aus Anwelsungen, die zeilenwelse einer der Sprachebenen zugeordnet werden. Diese Zuordnung erfolgt durch ein SchlUsselwort. Dem Schlusselwort kann eine numerlsche oder alphanumerlsche Programm-Marke vorangehen, Es besteht keln Zwang, jede Anweisung mlt elner Nummer zu versehen, Jeder symbolische Name beglnnt mlt einem Buchstaben und kann bel leblg lang seln. Es werden nur die ersten 6 Zeichen ausgewertet. Jedem Namen wlrd eine Adresse zugeordnet. Diese Zuordnung ist FUr alle Sprachebenen verbindlich. Ein Name kann mehrfach verwendet werden: als Programm-Marke~ als Variable~ als |ndlzlerte Variable. Es k~nnen 1 Gleltpunkt und 3 Integerdatentypen verelnbart werden, Der 0bersetzer braucht fur die Verknupfung von unterschledlichen Datentypen in arlthmetlschen AusdrLicken keine Vorkehrungen zu treffen~ da solche VerknUpfungen zur Laufzeit ohne Genauigkeitsverluste ablaut:en k~nnen.
Der Binder I~dt elnen verschlebbaren Obiektcode von einem extemen Datentr~iger und speichert ihn ab der speziflzTerten Adresse im Kernspeicher abo Der Binder kann Verkettungen weiterer Objektprogramme mlt oder ohne gegenseltige Ref'erenzen durchfUhren. Sowohl der ~)bersetzer als auch der Binder k~nnen die Spelcherbelegung vollautomatlsch oder nach Angaben des Benutzers durchfUhreno 5. Laufzeitsystem und Test
Der Ablauf von BASIC-Anwelsungen wird durch Laufzeitfunktlonen unterstUtzt (Ein-, Ausgabe, lndexrechnung, Schleifenarithmetlk etc.). Wurde im Quellprogramm der Datentyp elner Schlelfenvarlablen als Integer spezlfizlert, so kann fur den Ablauf elner Schlelfe ein erhebllcher Gewlnn fur die Verarbeitungsgeschwlndigkeit erzielt werden. Der Ablauf des Laufzeitsystems ist dutch eine Ebene h~herer Prlorit~it jederzelt unterbrechbar, das Laufzeltsystem steht dann der neuen Programmebene zur VerfUgung (Reentrant-Eigenschaff)o
In PROCESSBASIC ist eln Testmakro vorgesehen, das an belieblger Stelle im Programm und auf" allen tnterruptebenen eingefUgt werden kanno Der Ablauf wird in der jeweiligen Ebene an der Stelle des Testmakros unterbrochen° 0ber das I
435 6. Implementation Um die praktischen M~gllchkelten der Anwendung von PROCESSBASIC festzustellen, wurde PROCESS BASIC auf einer UNICOMP 201 imptementiert. Finlge Musteranwendungen wurden realislert, eine St6rstel lenuberwachung, eine Frequenzanalyse, eine Wagensteuerung.
Literatur: 111 Wagner F., Woda Ho: Handbuch PROCESSBASIC (1974) Firma UNICOMP, 7501 Blankenloch, Singerstral3e 3 [21 Fr6hllch Do: UNICOMP SYSTEM 201 - BASIC (1972) Firma UNICOMP~ 7501 Blankenloch, Singerstral3e 3 [3] Erb H.: SAMMI-Bedienungsanleitung (1971) Firma UNICOMP, 7501 Blankenloch~ Singerstral3e 3 I~l
Fr~hlich D.: Programmierung der Datenverarbeitungsanlage UNICOMP SYSTEM 201 Betriebssystem MIMOSA (1970) Firma UNICOMP~ 7501 Blankenloch, Singerstraf3e 3
[61 Haase V. : Which Programming Languages for Minicomputers ~n Process Control? Transcrlpta Books, Computing with Real-Time-Systems, Vol.2 (1972)
Dieser BerTcht ver6ffentllcht Ergebnlsse aus einem mit Mitteln des Bundesminlsters fgr Forschung und Technologie (Kennzeichen DV 5.505) gef~rderten Forschungsvorhaben des Projektes Prozel3lenkung mit DV-Anlagen (PDV) im Rahmen des 2. DV-Programmes der Bundesregierung. Die Verantwortung fur den Inhalt l iegt ausschlief31ich be i den Autoren bzw. den gef~rderten Unternehmen.
HUHERE PROZESS-SPRACHEN FOR KLEINERE RECHNER - DAS BEISPIEL BASEX A l l Goldenberg~ Christoph Schlier und Wolfgang Schupp
1. Einleitung Die derzeitige Situation l~Bt ein
sich
auf dem Gebiet der Programmierung von Prozessrechnern
nur markthistorisch verstehen. W~hrend im Bereich der "Universalrechner"
MarktfUhrer dafUr sorgte, dab FORTRAN und sparer PL/1 praktisch den Charakter
eines
Standards bekamen, hat
MarktfUhrerschaft interessiert.
es bei
Prozessrechnern weder eine
so starke
gegeben, noch war der a l l f ~ l l i g e Marktfdhrer sehr an Software
So kommt es,
Sprache FORTRAN folgte,
dab es nur 4 Jahre dauerte, bis auf die IBM 701 die w~hrend heute -
14 Jahre nach der PDP1 - noch keine
allgemein akzeptierte h~here Prozessrechner-Sprache abzusehen i s t . Dabei gibt
es seit Jahren immer wieder Vorschl~ge, wie man eine solche Sprache
ausstatten k~nnte [Z.B. 1, 2, 3, 6, 8, 9], und man muB feststellen, dab die Mehrzahl der
vielleicht
50000 ProzeBrechner
Anwenderprogramme
auf
schon vorhanden sind
der W e l t
soweit
immer noch in
nicht
fertige
Assembler- oder
Makroassemblersprachen programmiert wird. Nun werden h~here Programmiersprachenden Assembler bei ProzeBrechnern so bald sicher nicht
ganz verdr~ngen. Wo z.B. in Serienfertigung kleine Rechensysteme in
Ger~te eingebaut werden, die der Benutzer Uberhaupt nicht frei programmieren w i l l oder s o i l , wird es wirtschaftlich sein, das Programm "von Hand", d.h. per Assembler zu optimieren. DemgegenUber stehen mindestens zwei Bereiche, wo sich das Fehlen einer h~heren Programmiersprache einerseits
bemerkbar macht. Wir denken dabei
an groBe industrielle ProzeBsteuerungen (Kraftwerke, Verfahrenstechnik,
Fertigungstechnik), Herstellung
wo wegen der GreBe der Programme rationellere Methoden ihrer
verlangt
Fertigstellung Systeme
effektivit~tssch~digend
werden, selbst wenn man solche Programme nach ihrer
"einfriert",
insbesondere
bei
andererseits der
an den Bereich kleiner und mittelgroBer
MeBdatenverarbeitung (Laborautomatisierung,
Testsysteme, Oberwachunssysteme), wo v i e l l e i c h t die Programme nicht ganz so groB sind, dafUr aber ~fter einmal ge~ndert werden sollen nicht-spezialisiertem Personal. FUr diesen letzteren entwickelt
und in
-
m~glichst
sogar von
Anwendungsbereich haben wir BASEX (BASic for EXperiments)
einer ersten
Version implementiert.
Das folgende Kapitel
beschreibt die dabei angewandte "Philosophie". Im dritten Kapitel werden die haupts~chlichen Erweiterungen yon BASEX gegenUber BASIC dargestellt. Kapitel 4 gibt einige Details der Implementierung an.
437 2. Die "Philosophie" von BASEX Die
Entwicklung
Vorstellung kleiner
von
und
einer
ihrem
neuen Programmiersprache verlangt als erstes eine klare
Anwendungsbereich.
mittelgroBer
FUr BASEXwurde dieser als der Bereich
ProzeBsteuerungen
charakterisiert,
in
dem nicht-
s p e z i a l i s i e r t e Benutzer Programmieraufgaben Ubernehmen mUssen. Von daher lassen sich folgende Anforderungen an die Programmiersprache ableiten: a)
~ie
Sprache
Programmieren
soll
dem n i c h t - s p e z i a l i s i e r t e n
erlauben.
Dieser
Benutzer
Benutzer
kann schon in
ein
einer
komfortables der
Ublichen
problemorientierten Sprachen progammieren, er durchschaut auch den ProzeB, den es zu programmieren
gilt.
Er
Hardware-Ankopplung m~glichst bereit
nichts
w~re,
ist
nicht
identisch
mit
der
Person,
die
die
zu tun haben. Er hat auch nicht soviel Informatik gelernt, dab er
ohne Not
Assemblerprogramme zu konstruktionen
jedoch
(das Interfacing) zu verantworten hat und m~chte mit Elektronik LUcken in fUllen.
neu zu
der
Er
hat
Sprachdefinition durch selbstgeschriebene eine
Abscheu davor, komplizierte Sprach-
lernen, die er eigentlich gar nicht braucht, bloB weil etwa
ein Betriebssystem anders nicht anzusprechen i s t . Daraus f o l g t al)
die
Sprache
problemorientierten
muB l e i c h t
erlernbar
sein.
Sprachen einigermaBen
Dazu muB sie
~hneln.
Wenn m~glich
den Ublichen sollte
die
Programmerstellung und -austestung im Dialog m~glich sein. a2) den
Die
Sprache
muB vollst~ndig sein, d.h. sie muB Ausdrucksmittel sowohl fur
vollen Bereich numerischer und einfacher nichtnumerischer Datenverarbeitung als
auch fur die ProzeBsteuerung haben. Ersteres verbietet es im allgemeinen, Sprachen, die zum Schreiben von Betriebssystemen entwickelt wurden, z.B. BCPL [7] einzusetzen, letzteres
verlangt,
zeitabh~ngigen nicht
einem
dab Ein- und Ausgabe und die Bedienung von Unterbrechungen und
ProzeBstarts Supervisor-Call
mit
Mitteln
der Sprache f o r m u l i e r t werden k~nnen und
aufgebUrdet
werden mUssen. Im Sinne dieser zweiten
Forderung sind etwa CORAL 66 [10] oder RTL/2 [nach 12] unvollst~ndig. b)
Die
kleinen eine von
Sprache
soll vom Umfang her so beschaffen sein, dab sie auch auf einem
ProzeBrechner
Kleinplatte vorneherein
vorgesehen
ist.
(Kernspeicher
ab 8K a 16 b i t , Hintergrundspeicher h~chstens
oder Kasettenmagnetband) implementierbar i s t . Damit erstreben wir einen Die
Programmieraufgaben
merklich Vorstellung,
fur
kleinere
kleineren dab
Sprachumfang, als er fur PEARL [ i ,
sich
mit
ProzeBrechner
Hilfe l~sen
von
11]
Cross-Compilern die
lassen,
halten
wit
fur
unrealistisch. Die
Sprache
Architekturen
soll zu
dabei universell genug sein, um nicht bei bestimmten Rechner-
Schwierigkeiten
bei der Implementierung zu fUhren, sie soll auch
nicht a l l z u spezielle Betriebssysteme verlangen. Es i s t so
k l a r , dab die Forderungen a) und b) sich der Tendenz nach widersprechen,
dab man Kompromisse schlieBen muB, was v i e l l e i c h t manchmal Ubersehen wird. Die
Tatsache,
dab sch~ne Sprachkonstruktionen o f t von den Benutzern garnicht angenommen
435 werden einer
[5]
,
zeigt im Ubrigen, dab m~glicherweise der optimale Komplexit~tsgrad
hUheren Programmiersprache garnicht
offene
Frage
zu
sein,
die
breitgef~cherter Benutzerkreise
allzu
hoch l i e g t . Es scheint uns eine
nur dutch Analyse der Programmiergewohnheiten zu beantworten sein wird,
welche Sprachmittel
wirklich dringend gebraucht werden. Eine dem
im Sinne von b) an kleinere Rechner (und nicht zu groBe ProzeBsteuerungen)
Umfang nach angepaBte Programmiersprache
kostengUnstig zu
implementieren.
zwar Uber dem von BASIC aber eher unter Nebeneffekt dabei i s t ,
dab dies
veraltete Rechner- Architekturen
ist
natUrlich
auch r e l a t i v
Der Aufwand zur Implementierung von BASEX l i e g t dem von ANSI FORTRAN. Ein nUtzlicher
dem Trend entgegenwirken kann, technologisch zu
konservieren,
blo6 well die in die Software
gesteckten Investitionen zu hoch sind. Von dieser Ausgangsposition ausgehend, erhebt sich als n~chstes die Frage, ob man eine
Sprache ganz neu erfinden
s o i l , ode~ ob man sich besser an eine vorhandene
problemorientierte Sprache anlehnt. speziell
Cdr BASIC [4] . Diese Programmiersprache wurde nicht etwa for Kleinrechner
erfunden, aber
Wir haben uns fur das letztere entschieden,
sondern FOr ein
als
einfache,
benutzerfreundliche
groBes "educational time-sharing system". Sic hat sich
leicht
zu
lernende
und durch ihren
Dialogcharakter
Programmiersprache fur kleine Rechner durchgesetzt, obwohl sie
vom Standpunkt des Informatikers manche M~ngel haben mag.
3. Die Sprachelemente von BASEX Wir
setzen im folgenden BASIC als
allerdings
bekannt vorauso Genaugenommen i s t
BASIC
eher eine Klasse von Dialekten als eine einheitliche Sprache, sodaB wir
unseren Bezugspunkt speziell als Dartmouth-BASiC [ 4 ] definieren mUssen. a) 5 Erweiterungen, die nicht prozeB-orientiert sind: Solche haben wir
nur sehr z6gernd vorgenommen, um die Sprache BASEX nicht yon
vorneherein aufzubl~hen, auch sollte Jedoch
sie weitgehend Obermenge von BASIC bleiben.
schien es uns im Interesse des oben beschriebenen Benutzers n~tig,
mnemotechnische Namen fdr
Variable zuzulassen; die L~nge dieser Namen wurde auf 4
Zeichen beschr~nkt, z.B. TEMP, VAL3, ERR5 , FNCORR(X). Wenig ver~ndert haben wir die Zahl der Datentypen. Insbesondere haben wir keinen Typ
< integer> eingefUhrt. Mit der Entwicklung schneller b i l l i g e r Gleitkommarechen-
werke erscheint er immer weniger notwendig. Im Gegensatz zur Folklore i s t es ja so, dab Rechnungen, die ganzzahlig begonnen werden und bei Festkomma im Ring der ganzen
*
Die folgende Beschreibung i s t informell. Eine BNF-Syntax kann als Report C-25 vom
zweiten Autor angefordert werden.
439
Zahlen bleiben, nicht
diesen auch auf einem ordentlich aufgebauten Gleitkomma-Rechenwerk
verlassen. (Das g i l t nicht Fdr Funktionen wie SQR, aber SQR() i s t
auch sonst stets vom Typ .) Auch sind Pseudo-integer-Rechnungen auf einfachen Gleitkomarechenwerken
durchaus schneller
als
der
real-Opelrationen, da weniger zu normalisieren i s t . nicht-spezialisierte Benutzer bei sollte,
Durchschnitt beliebiger
Wir glauben, dab gerade der
arithmetischen Problemen keinen AnlaB haben
lange Uber Datentypen nachzudenken. Obernommen haben wir auch die Eigenheit
von BASIC, Variable vom Typ wie Zahlen zu behandeln. Konstruktionen wie (A < B) ~÷ 5 s i n d dann zwar erlaubt - der Normalverbraucher wird sie jedoch nicht anwenden, wenn man sie ihn nicht lehrt. Ver~ndert gegenUber Dartmouth-BASIC haben wir die Textverarbeitung. Es erschien notwendig, die L~nge von Zeichenketten durch CHAR< string-variable-name> ( < numeric-constant > ) zu deklarieren,
falls
sie
aus mehr als
10 Zeichen bestehen. Ferner hal ten wir
Zeichenmanipulation Fdr wichtiger als Listen und Tabellen, daher bedeutet AB$(5,8) nicht
ein
Element der Tabelle AB$ sondern ein aus 8 Zeichen bestehender Teilstring
der Zeichenkette ABe, der bei ihrem 5. Zeichen beginnt. Ferner i s t die Konkatenation durch z.B. LET C$= erkl~rt.
AS B B$
Die Konversion des Datentyps < string > in den Typ < real> und umgekehrt
kann mit
Hilfe der Systemfunktion CHG durchgefUhrt werden, wobei jeweils 2 Zeichen
mit ihrem ASCII-Code einer Pseudo-integer-Zahl zugeordnet sind, z.B. LET PRINT
X
:
CHG ( A S )
CHG ( U + V ).
Im Sinne der Reduktion der Zahl der Datentypen haben wir keinen Datentyp eingefUhrt, sondern behandeln diesen als Zeichenkette. Es g i l t : <string-const.>
::= < ascii-string-const.>l
::= < hexa-string-const. >
"{},"
: := %{< hexa-character>}~%
FUr Ketten, die damit sowohl Zeichenketten wie Bitketten repr~sentieren, sind die bitweisen Operationen < string-operator>
::=
ANDS
I ORS I NOT~
440
erkl~rt.
Sie dUrfen allerdings
nur in
Zuweisungen (LET) stehen. Die Aufgabe,
abh~ngig vom dritten Bit (von vorn) einer Zeichenkette ZUSTSvon 16 bit L~nge eine Entscheidung zu treffen, kann z.B. durch CHARZUST$(2), AS(2) LET AS = ZUST$ANDS%2000% IF AS = %2000%THEN. . . . gel~st werden. Weiter sei erw~hnt, dab wir in Erweiterung von Dartmouth-BASIC aber in Obereinstim~ung mit vielen anderen Dialekten in Bedingungen (IF) die logischen Operatoren ::=
AND I OR [ NOT
zwischen Relationen zulassen. SchlieBlich haben wir eine CALL-Anweisung eingefUhrt, um auf alle F~lle die M~glichkeit zu geben, Assemblerprozeduren, seien sie vom Hersteller, seien sie vom Benutzer programmiert, mit
dem BASEX-Progra~ zu verknUpfen. CALLgehorcht der
folgenden Syntax: < call-stat. > ::=
CALL<subroutine-name>{(]< single-string> 3 {, I< si ngl e-stri ng>}~)}
<single-string>
::= <string-variable>[<string-constant>
< subrouti ne-name> : := Es k~nnen also null bis vier Parameter (Zahlen, Feldnamen oder Zeichenketten) Ubergeben werden und zwar Feldnamen "by reference", Zahlen und Zeichenketten "by val ue". Wie Ublich hat unser Interpreter eine "Generierungsphase", wenn er neu gestartet wird. Hier wird der Benutzer gefragt, welche eingebauten Funktionen (SIN etc.) und welche vom Hersteller u.U. eingebauten Unterprogramme er nicht braucht, damit ihm Speicherplatz freigemacht werden kann. (Wichtig fur Minimalausstattungen.) Benutzer-Unterprogramme werden am Ende dieser Generierung im Dialog eingelesen. Wir halten hier also dem Hersteller und dem Benutzer eine HintertUr offen, um "im Ernstfall", z.B. wenn bestimmte Reaktionen des Systems besonders schnell ablaufen sollen, doch noch zur Assemblerprogrammierung zu greifen. Auch hier erlaubt der Dialogbetrieb bei der Generierung einen ungew~hnlichen Komfort.
441 b)
Erweiterungen zur ProzeB-Ein/Ausgabe: Das Problem, Ein- oder Ausgabeanweisungen fur die Prozei~-Peripherie zu schreiben,
i s t Cur den bloBen Programmierer unl~sbar, solange ihm nicht von demjenigen, der die ProzeBkopplung hardware-m~Big festlegt gesagt wird, eine
- im folgenden Systemintegrator genannt - ,
was er hinschreiben muB, um z.B. einen Z~hler CNTR(5) einzulesen oder
Temperatur TEMP von einem TemperaturfUhler zu bekommen. Das kann so geschehen,
dab der Systemintegrator im Falle von PEARL eine stellt,
in einer CAMAC-Sprache ein StUck der
BASEX ein
Equipment-Makro b e r e i t s t e l l t ,
Solange nicht werden (wie utopisch
wirklich z.B.
zu sein
der
zur VerfUgung
c-name-section schreibt oder aber in
das der Programmierer abschreiben kann.
Schnittstellen samt ihren Namen im Klartext standardisiert Kartenleser
in
FORTRAN) -
was im Proze~bereich vorl~ufig
scheint - , kann man den nicht spezialisierten Programmierer nur
dadurch entlasten, einbaut),
device-connection
dab man ihm ProgrammstUcke Ubergibt (oder sie in das System
wenn man ein Ger~t anschlieBt. Bei CAMACi s t es vorstellbar, dab solche
ProgramJr~tUcke fur die wichtigsten Rechner zusammen mit dem Ger~t verkauft werden. In
BASEX sind fdr den AnschluB nicht standardisierter Gef6te Makros vorgesehen,
die durch eine Equipment-Anweisung definiert werden: <equi-stat.> ::=
EQUI<process-input-var.-name>{()It =<machine-code >
< equo-stat. > ::=
EQUO<process-output-var.-name>{(< numeric-var.-name>)}~ =< machine-code>
< process-input-var.-name>
::= < numeric-var.-name>
< process-output-var.-name> ::= < numeric-var.-name> < machine-code > Diese Deklaration
definiert
::= < hexa-string > zugleich
eine
ProzeBvariable mit
der folgenden
Syntax: < process-.input-var. > ::= < process-input-var.-name > {(< numeric-expr. > )}~ < process-output-var.> ::= < process-output-var.-name>{(< numeric-expr. > )}" Die
ProzeB-Variablen stellen
ausfUhrbaren
e i n e n neuen Variablentyp
Anweisungen syntaktisch
nicht
dar,
der
in
den
von gew~hnlichen Zahlenvariablen
unterschieden wird, auBer dab er h~chstens einfach i n d i z i e r t werden darf. Semantisch beziehen sich
diese Variablen
in
demselben Sinn auf
(=ProzeBgeschehen) des Rechenprozesses, wie
das ~uBere Environment
sich normale Variable auf das innere
Environment (=Rechenanlage) beziehen. Bei jeder Benutzung wird der durch das Makro angegebene
Ein-
o d e r AusgabeprozeB eingeleitet.
Eingabe sieht
(ProzeB-Variable bier zur Verdeutlichung unterstrichen):
also
so aus
442 PRINT INP(3) LET A = LOG(50 + SOND(I+3~K)) LET WORTS= CHG(REG(2+I)) IF TEMP< TO THEN... LET TP = TEMP , TP = 0.8 * TP + 0 . 0 0 3 , TP * TP Dabei i s t
verabredet, dab das Makro ein externes 16-bit Wort in den Akkumulator
des Rechners schaffen Der
Index der
muB, yon woes z.B. einer Variablen zugewiesen werden kann.
ProzeBvariablen
steht
dem Makro in
einem festen
Register zur
Verfugung. Diese Konventionen k~nnen u.U. je nach Rechner ge~ndert werden. Bei
der
Ausgabe unterscheiden
wir
solche, die ein 16-bit Wort Ubertragen und
solche, die nut ein unver~nderliches Ausgabesignal erzeugen, im Beispiel: LET OUTP(5) = 1024~X PUT VALV Im ersten
Fall
wird der ganzzahlige Anteil des Wertes des Ausdrucks 1024~X dem
Makro EQUO OUTP(1)=.... lediglich
im Akkumulator zur VerfUgung g e s t e l l t , im zweiten l~uft
das durch EQUOVALV=.... definierte Makro ab. FUr den Index g i l t dasselbe
wie oben. In allen F~llen kann das Makro weitere Steueroperationen ausfUhren, es hat nur
nicht Zugriff zu mehr Variablen. Auf diese Weise i s t es z.B. sehr einfach, eine
CAMAC-Steuerung zu beschreiben, bei der ja Ublicherweise mehrere Register-Transfers fur einen CAMAC-Transfer zu machen s i n d . Es hat
sich
standardisieren,
als
nUtzlich
erwiesen,
bestimmte Ein- und Ausgabe-Transfers zu
indem man bestimmte Equipment-Makros von vorneherein
in
den
BASEX-Obersetzer einbaut. Es sind dies Ein- und Ausgaben von Registerbits, Registern und Analogsignalen, deren Name mit bestimmten Pl~tzen im Koppelwerk ein fur allemal verbunden i s t . Bits
:
INB(n) , OUTB(n)
Worte
:
INW(n) , OUTW(n)
Analog-Kan~le :
INA(n) , OUTA(n)
< n > : := < numeric-expr.> Auch diese Benutzung
ProzeBvariablen
erspart
k~nnen v ~ l l i g
Schreibarbeit,
mnemotechnisch signifikante
hat
frei
in AusdrUcken vorko~men. Ihre
a b e r den Nachteil,
Namen verzichtet,
Anweisung als weiteres Sprachmittel zu]~Bt.
dab man damit
auf
sofern man nicht eine EQUIVALENCE-
443 c)
Behandlung yon Unterbrechungen und Zeitbedingungen: Hier mUssen die
Sprachmittel festgelegt werden, die es erlauben, asynchron vom
~uBeren ProzeB her oder ebenfalls asynchron vonder im Rechner gefuhrten Realzeit her ProgrammstUcke (wir vermeiden das Wort "Task", da alle Variablen global sind) zu starten. Wir verwenden < on-int-stat. > ::=
ON INT< interrupt-number> :< operation-l-stat. >
wo < operation-l-star. > die Anweisungen LET, PUT, GOTO, CALL und END bedeuten kann. Die Deklaration ON INT koppelt also ein ProgrammstUck, das i.A. durch GOTOerreicht wird,
an e i n e von endlich vielen numerierten Unterbrechungen. Die Unterbrechung
selbst kann mit ENAB < interrupt-number> {, < interrupt-number>l DISAB< interrupt-number > {,< interrupt-number>} freigegeben bzwo verhindert werden. Weiter i s t syntaktisch < interrupt-number> ::= < numeric-expr.> - dabei wird ggf. der ganzzahlige Teil des Wertes genommen. Das Ende eines durch eine Unterbrechung angestoBenen Programmteils wird durch STOP vorgeschrieben. FUr die
Behandlung zeitabh~ngiger Auftr~ge wird das Vorhandensein einer Uhr
vorausgesetzt, die die reservierten SystemvariablenHOUR, MIN, SEC und MSECauf dem laufenden h~It.
Dies geschieht im Betriebssystem, dem Programmierer stehen die
Variablen wie interne Variable zur VerfUgung. Zum Starten von Programmteilen in Abh~ngigkeit von einer Zeitbedingung haben wir vorl~ufig nur die Relation AFTEReingefUhrt (die Zeit i s t in ms anzugeben): < after-stat. > : := AFTER :< operation-l-star.> Will
man zu einer bestimmten Zeit starten, etwa zur 45ten Minute der laufenden
Stunde, so kann man z.B. schreiben: AFTER((45
- MIN) *
Regelm~Sige Starts
60 -
SEC) ~
1000 : GOTO. . . .
erzeugt man durch einen Zeitauftrag eines zeitabh~ngigen
ProgrammstUckes auf sich selbst (dies s t e l l t keine Rekursion dar!): 100 REM REGELMAESSIGEABLESUNG JEDE MINUTE 101 AFTER 60000 : GOTO101 102 LET X(1) = INW(1) , I = I + 1 103 STOP Eine verz~gerte Unterbrechung sieht z.B. so aus: 200 ON INT 3
: GOTO500
. t , .
500 AFTER 60000 : GOTO1000 510 STOP 1000 REM UNTERBRECHUNGS-SERVICE 1010 LET A = INA(1) oloo
1090 STOP NatUrlich ein
sollte es in einer ProzeBsteuersprache auch die M~glichkeit geben, dab
ProgrammstUck wartet,
bis
ein
anderes, z.B. eine Unterbrechungs-Bedienung,
f e r t i g i s t . Wir haben uns damit begnUgt, hierfUr ein < wait-stat. > : : : zur
WAIT < numeric-expr. >
VerfUgung zu stellen.
Jeder Zahlenausdruck kann also mit seinem Wert (=0
entspricht "false", ~0 entspricht "true") als "flag" benutzt werden.
4. Diskussion und SchluB Der Platzmangel verbietet es, mehr Details und einige andere Erweiterungen von BASEX gegenUber BASIC darzustellen. (Hierzu geh~rt ein begrenztes Multitasking, eine begrenzte Segmentierung yon Programmen bei Plattensystemen, auBerdem die noch nicht implementierten Sprachmittel,
um Datens~tze auf
der Platte
vom Programm her
anzusprechen.) Es i s t uns wichtig festzustellen, dab wir BASEX nicht als "endgUltig" betrachten, sondern als Betriebserfahrung nahe legt.
Vorschlag,
den
man ver~ndern muB, wenn es die
Um diese Erfahrung zu gewinnen, haben wir BASEX auf einem Rechner MINCAL 621 der Fa.
H.
benutzt
Dietz eine
umkodiert
in
Form eines Interpretierers implementiert. Diese Implementierung
Zwischensprache, in
wird
(und
aus
der
die bei
der Quellencode bei
der Syntaxanalyse
LIST zurUckgewandelt wird),
was einen
445 Geschwindigkeitsgewinn von wenigstens einem Faktor Interpretierern
gibt.
Der
Speicherplatz
fur
3 gegenUber Ublichen BASIC-
eine
Implementierung im oben
beschriebenen Umfang (ohne hier nicht beschriebene Erweiterungen) betr~gt etwa 12 Kbyte (ohne Verwendung eines Hintergrundspeichers), wovon ein Teil wie beschrieben dutch Eliminieren nicht
ben~tigter Standardfunktionen gespart werden kann. ber
Implementierungsaufwand fJr den hier dargestellten Umfang i s t vonder GFdBenordnung 3 Mannjahre (im Universit~ts-Environment). Zusammenfassend m~chten wir sagen, dab unseres Erachtens zwischen dem Niveau von PEARL bzw. PL/I und dem Makro-Assembler ein weiteres Sprachniveau l i e g t , f u r das von den Anwendungen und der beweisen
nicht
Hersteller Adapts
und
Ukonomie der
ProzeBrechner her ein Bedarf besteht. Das
z u l e t z t die vielen ad-hoc Erweiterungen yon BASIC, die verschiedene
anbieten,
z.B.
COSMIC
Integrationsgrad
der
BASlC-RT und
von
Varian.
Realzeit-Elemente
aus und dUrfte daher benutzerfreundlicher sein.
(auf
Industrial
BASlC von Digital Equipment,
BASEX zeichnet
Kosten
sich
durch
einen
h~heren
und der Ein/Ausgabe-Anweisungen vor diesen etwas
Die Einzelheiten des Sprachumfangs wurden in
aufwendigerer
zum Teil
Implementierung)
harten Diskussionen
festgelegt, an denen auch die Herren P. Dietz und A. Frick ihren Anteil haben, wofUr wir ihnen danken mdchten. Ferner danken wir der Deutschen Forschungsgemeinschaft fur die F~rderung unserer Arbeiten im Bereich der Informatik.
5. Literatur
[i]
Brandes, J. et al. :
[2]
Diehl, W. , Mensch, M. :
Elektronische Datenverarbeitung 1_~2,429-442 (1970). IFAC/IFIP Symposium, Toronto 1968, abgedruckt in Schoeffler, J. D. , Temple, R. H. : Minicomputers, New York : IEEE Press 1972.
[3]
Gertler, J., :
[4]
Kemeny, J. G. , Kurtz, T. E. :
[5]
Knuth, D. E. :
Software Practice and Experience ~, 105-133 (1971).
[6]
Musstopf, G. :
Angew. Informatik 14, 441-448 (1972).
[7]
Richards, M. :
AFIPS Conf. Proceedings 34 (SJCC 1969), 557-566.
ComputerJournal 13, 70-75 (1970). BASICProgamming, New York : Wiley 1971.
446
[8]
Schoeffler, J. D. , Temple, R. H. :
[9]
o. Verf. :
Proc. IEEE 5__88,98-111 (1970).
A Language for Real Time Systems, Computer Bulletin 1~I, 202-212 (1967).
[io]
o. Verf. :
Official Definition of CORAL66, H. M. Stationery Office, London 1970.
[11]
o. Verf. :
PEARL
-
A proposal for a process- and experiment automation
realtime language, Bericht KFK-PDV 1, Gesellschaft f u r Kernforschung, Karlsruhe, April 1973.
[12]
o. Verf. :
Final Report and Recommendations of the Real Time Language Study undertaken on behalf of the European Space Operations Centre, Software Sciences Lid, Jan. 1972. Report No. N72-28205.
DIE UEBERSETZUNG DER CAMAC-SPRACHE UNTER WERWEI~DUNG DEB INL -ERFAHRUNGEN
ZWISCHENSPRACHE
BEI
DER
IMPLEMENTIERUNG
VON CAMAC COMPILERN
W. Kneist Berlin
GrK/Z~/klotron~
1. CAbIAC SPRACIIE Die
Karlsruhe9
iche
fuer
die
SPRACHE
CAMAC IML
Grundmotivation
Programmierung
erleichtern
bei
(01)
(IML)
(02)
der Kommunikation Rechner
bzw.
Operationen
CAMAC-S~/st em
die
~inae r ~ n f o r m a t i o n .
Probleme
keine
der
verwen d e t ,
bis
heute
eines
zwei CAMAc
ermoeglichen.
Der
bei
CL und
beiden
Die
CAMAC-sNstemabhaengig
und
yon
~eide Sprachen s i n d an
besehriebene CAMAC-Hardware und
Sprachen
IML basieren
Datenmanipulation
D a r s t e l lung
Datenaustausch zwischen Bechner und
~data--processing*
werden.
<-> CA~AC-Peripherie zu
rechnerunabhaengige
fixiert.
erfolgt
besitzen
hat
Prcgrammierung
(CL)
im E u r a t o m - B e r i c h t , EUR 4100 ( 0 3 ) ,
deren
Sie
die
(SWG)
der D e f i n i t i o n der CAMAC-Sprachen i s t ,
CAMAC-Peripherie-Funktionen zu die
HMIt
t:
- die CAMAC -
W° N o l e t z t
CAMAC IML
Vorschlaege
Systems entwickel
die
De.qeohardt~
ESONE-CAMAC-Software-Working-Gruppe
grundsaetzl
Die
K.H.
prinzipiell
ueber
auf dem H o s t - F a r a s i t e - K o n z e p t .
Instruktionen.
und - a r i t h m e t i k
~as
bedeutetl
muss e i n e
CAMAC-Sprachen
Host-Sprache
sind
andererseits
fuer
einersei ts
rechner-
und
c o n t r o l le ru nabhaengi go Ziel die
ist es~
CAMAC--s p e z i f i s c h e n
uebersicht Form
der CL
licher
einer
definiert~
Form
dem P r o g r a m m i e r e r Teile
zu
high- leve I (lass
sie
den
seines
schreiben.
die
Pro qrammes Aus
i~
diesem Grund
Frog rammie rsprache. niedr igsten
Foeg|ichkeit
IMI.
zu
geben~
einfacher hat
die
hingegen
und
CL d i e ist
so
imp I emen t i e r ung s u n a b h a e n g i g e n
448
S o f t ua r e - L e v e l besitzt.
ueber
Die
eine
IML
eines
als
IML
IML h a t
CL
I~ptementierung
eines
Vet fuegbarkeit
yon
er fahren.
(~C)
zu
autonomen
r e c h n e r--
fuer
im L a u f e
der
der
definieren
Prozessors
CA~AC-SNstems
letzten
Negen
des
CAM•C-Compilers
Eigenschaf
ten
und
VC
den
auszustatteno
relativ
grossen
wird
man eines
mit
den
Gleichzeitig
Gutput
nach
eines
HauptauEgabe yon IML d a r i n gesehen, CAMAC-Software r e l a t i v
der
schneller
j uengster
in
Jahre
Aufwandes
u n d dem N u n s c h
CAMAC-Softwa re
zwei hat
con trol 1er unabhaeng iger
und
dienen.
des
Urspruenglich
Beschreibung
als
Controllers
Eigenschaften
Compilers
yon
Veraenderung
igt,
'vlrtuellen'
sollte
Hardwar espez i f ika t ion
Konzeption
gewisse
beabsicht
der
Zeit
die
e l n f a c h und
s c h n e l l i ~ p l e m e n t i e r e n zu koennen,
1.1 K o n z e p t
Die dem
des
virtuellen
gegenwaertig
Nunsch
nach
Controllers
vorliegende
teicht
zu
auf e i n e
konsequente
bereits
gewonnene
Erfahrungen
IML z u r u e c k z u f u e h r e n
an
Anwendung
wie
Z*B.
S.vnchronisationsinstruktionen~ se~antische
yon
der
nun
bei
der
nicht
keine
und
Implementierung Funktionsaufrufe
Task-schedul
ing-Au fr u fe
beschraenkt
sich
Camac-Peripheriefunktionen
zwangslaeufig
man von
yon
E i g e n s c h a f t en abgeieiteter der
Prozessor
Rueckwirkunge~
der Korrespondenz
Instruktionsmenge
Definiticn
sein,
sondern
yon
was
oder
auf die
twine
auf
Basis
der
EUR 4100 ( 0 3 ) und EUR 4600 ( 0 9 ) ° Diese 9eraenderung im IML-Design
besitzt Wean
Definition
entspricht
des Host-parasite-Konzeptes
spezifiziert
Sie
IML ( 0 2 )
C~M~C-Software,
(04,05,06,07,08)
ist.
Betr iebssNs teme ~
yon
implementierender
zuletzt
yon
Definition
IML eines
VC
yon
zwischen
IML
a|lei~
aut o n o m en
wird d a h e r
der
VC n u t
dutch
kann
aus
abgeleitet
Prozessor s
zwangslaeufig
definitionsgemaess wird
VC
die
ein
einzelne
der
nicht
~JC und
gegenwaertigen
Ein
autonomer ist.
des VC.
des
werden,
besi tzt.
rechnerunabhaengig die
Kcnzeption
der F u n k t i o n s m e n g e
ausgeht,
kein
auf
der
die
aus
IML
Prozessor
Zum autonomen
Implementierung.
Er
ist
q49
i. m p l e m e n t i e r u n g s a b h a e n g i g .
damit
1.2 S t r u k t u r E]n
von CL und IML
in
CL g e s c h r i e b e n e s
ProbleA~teil
zur
Beschreibung
System
(Fig.
unterteilt
dec
Namen
Hardware-Einheiten
ist
einen
Peripherie
wieder.
Die
und danach
Moduls,
und e i n e n
im u e s e n t l i c h e n und g i b t
Eaumstruktur (z. B.
mit H i | f e
Register)
System-
dient
H a r d w a r e - K o m p o n en ten
zu .~eben (z.B.
in
Der S y s t e m t e i l
CAMAC-spezifischen
groesseren
s.vmbol~sche
1).
Baumstruktur
vorgegebene
zunaechst
Programm
erlaubt
Branch,
dieser
die
Namen
vom es,
Crate ) kleinere
zu definieren.
HARDWARE KONFIGURATION
NO) CLOCK
C(~I CONTROLCRATE
l ~Ec°"°~°'l
/
F
Bystemtefl:
s~stemteil:
EXPERIMERT = B ( I ) .
LOCD T I M E , Q , 3
CONTRCLCRATE CLOCK
= EXPERIRENTC(1). = CONTROLCRATE N { 1 ) .
LOCM TIMEARRAY,A,2~,5 LOCR R3,STAT,3,K,TALLY
SECO.DS
= CLOCK A(o). = CLOCKA(~). = CLOCKA{2).
MINU~ ~OURS
P~obl~tell:
Fig.
werden
aehnlicher im
Speicherbereiche
1,1,1,0
1.1,1,1
1,1,~.2
Problemte~1:
"EAD TI~E (c:)) TZ~ARBAY ( 1 : ) ) ;
In
S{1) EXPERIMENT
i.
CL,
MA READ, TIME, T I M E A ~ R A Y , R )
IML Programm B e i s p i e l e
Weise werden
S~/stemtei 1 definiert.
die
Interrupts fuer
(LAMs) den
deklariert°
CAF,A C - I / f i
Daneben
benoetig tev
450
Die in
eigentliche
Problemtei
Kommunikation
I
dutch
Executive-Statements
ist
<->
Transfer-,
beschrieben.
CAM~C-Peripherie
Con t r o l -
Die
~
FOrM d i e s e r
Stanch-
wird t
und
runtime-Statements
im u e s e n t l i c h e n :
Sin
IML-Programm
Problemteil
ist
gegtiedert
CL-Programmes
ist
(Fig.
hierj die
Knotenpunk te
beschriebe
n
genannt
und
Branch.
Crate~
Interrupts
( LA~s )
werdeno
und
EL9
al lerd ings
yon in
IHL-Aktions-Instruktion
action'9
und
Uergleich der
Dieser
Unterschied
in
Lisle
der
ein
eben fal Is sieht
sondern
yon
e wird
Werten
Deklarat
fuer
ion
Beschre ibung
die
ihre ihrer
Knotenpunkt
Die
dutch
eines
Ltste
4-tupel
I~L
I~L beinhaltet anderer
yon
ihrer
Deklara lion
den
<dev.
transfer'
acher
yon
Aktions-Statements ForM.
Sine
t ~/p l s c h e
die
oder
drei
der
INL
mit
Sprachen
in
der
in
CL
Action--Statements
moegllchen
'multiple
zwischen
CL
<mere. a d d r . >
addr.>
I/idersprueche
beiden
ist
aehnliche
syntakti
Modes b e s c h r e i b t
'block
Unterschiede
liegen.
eine
und
spezifiziert:
A n g a b e des
Unterschiede
S~vstemstruktur
A-Subst ation.
<mode>
Ein
zum S ~ / s t e m t e i l
dutch
Die
in S£stem-
vor.
Problemteil
'single
die
charakterisiert
geschieht
Der
Die
CL-Programm
Der Unterschied nicht
A u s s e rdem
Speicherbereichen
wie
ein
CAMAC-Regi s t e r t
N-Station
EAMAC-Adresseno
<destination>o
wie
!)-
dass
t
CAMAC-Adresse
<source>
ebenfalls
Grundbausteine
1.3
gechner
der
zeigt
action'.
CL u n d II~L t
dass
die
PrograBBierung
uebersichtlicher ist
in
Aktionsarten~
er~ter
wesentlichen
des S~/stemtei]s
und sicherer. Linie
Der
s~/ntaktischer
Art.
St n i g e Inkompatibilitaeten
grundsaetz
Iiche
zulschen
Schwier lgkel ten
CL
und
£ML.
So i s t
here iten
Z.Bo
gewi sse
in CLder
Mode
451
mit
der
Device-hdresse
Mode
bei
den
IML
fuer
t block-transferl (word
Inkompatibllitaeten Definition
Definition
der
im
yon
der
in
In
wird.
'multiple
wesentlichen
IML d e r Ferner
nicht
in In
jeweilige
sind
action'
CL
IHL b e g r u e n d e t .
CL g e a e n d e r t
die
in
vorge sehene n
enthalten.
Diese
der
zeittich
spaeter
solchen
Faellen
muss die
~erden°
UEBERSETZUNGSMETHODE
Da CL und IML a u f zur
etne
Zeit
eine
die
jeweil
s
Form
des
Erzeug~lng
der
an°
hoeheren
Iwplementierung
e[nes
eine
Art
Hostg
FCRTRA•)
Fal 1
(z.B.
yon der kann
Preprocessing
aufgefasst
die unter
werden.
Das
hergestellte
und Parasite-Sprachelementen
werden
IML-Preprocessors
einzusehen
Objectcodes
bleibt~
invar iant
als
in
nach e i n e m
leicht
d i e sere
sich
Einbettung
Forderung wie
Objectcode
Uetersetzun
wichtig
I n
Eietet
A nwendungs p tog ra~mi ere r
zuischen
(z.B.
des Host-Compilers
als ine
dutch
erzeugten
ab°
berueckslchtigt
nicht
Sprachen
CL i n
vom
die
solchen
Host-Uebersetzer
ln-I
Sprachen
haengt9
einem Compiler
Verknuepfung
einer
ausgeht,
yon
basierenj
Wenn man y o n d e r
Host-Sprache
Folge
dass
t
beiden
Parasite-Sprache
einer
semantische
Im
yon
v e t wende t e n
Uebersetzung
unter
Host-Sprache
der
yon Uebersetzungsarbelt
ist,
bedeutet
dem H o s t - P a r a s i t e - K o n z e p t
Implement ierung
geeignete
Minimum
muss.
Bei
"Host-Sprache allerdlngs
die
Parameteruebergsbe~
d.h.
vo~
Verwendung
yon
ist
die
fuer
genaue Kenntnis
Datenstrukturen).
IHL ali~emeinen
sind
Host-Language-Statements gewaehrleisten~ Die
~)
count.
waehrend
angebenen und
sind
erfolgten
2.1
verknuepftt
Aktions-Instruktionen
Exit-Kriterien
2.
lest
Form
der
dass
der
in e i n e m S o u r c e - P r o g r a m m
gemi scht. CL-Uebersetzer
g e n e r i e r t en
CL-Statements
Bescndere nur
IML-S tatemen t s
CL-Statements ist
und
Sprachelemente verarbeitet.
abhaengig
yon
der
452
Host-Spracheo
sich
fuer
Nird
die
Hacro--S~/ntax
Assembler
Form der
(10)
an.
Hacro-Uebersetzer, diesem
Fail
Precompi lierung
Abschnitt
2°2
die
Macro-Syntax
nicht
sich
erlaeutert
IML i n
Diese
der
Host-Sprache
IHL-Statements
der
laesst
als
in
eine
yon
der
erfordert
allen
einen
komfortablen
vorhanden
Implement ierung
erreichen,
so b i e t e t
StiG v o r g e s c h l a g e n e
S~/stemen
schne I le
I M L - S t a t emen t s
ver~endet,
uie
im
ist.
In
dutch
die
naech sten
wirdo
Assembler
In
der
vorli
I H L - A s s e m b l e r - P r o g r amm uebersetzt
(Fig.
egenden
I m p l emen t i e r u n g
i nsgesamt
in
zwei
(08}
~ird
get rennten
ein
Schritten
2).
-Tf
I
lr
IBM~360 . . . . . . . . . . .
Fig.
Im
2.
Uebersetzun.q
erst en
Hauptprozessor
Lau~
das
IML-Statemen±
I~L-Instruktion
den aus
IML-
dem
erzeugte
Assembler-Statements
dem
Assemblerlau£, des
I
I
t
1I
CDC3100
eines
dem
IML-Assembler-Programmes
P r e c o m p iler lauf
Host-Parasite-Programm, oder
IHL-Compiler
Alle
innerhalb
-
gesamte
Kont rol li nst rukt ionen gegebenenfalls
J
I I
-
analNsier t
erkennt
Assembler-Statements auf.
Der
IML-Compiler
Programm
und s c h i e b t
Folge" von
Assembter-Instruktionen
eerden
u e b e r se tzt.
anschliessend Dieser
IML-Compiler-S~/stem
in
Lauf
sondern
stattdessen
der
davon
anhand yon und
tuft
entfernt die
aus
das der
dazuischen°
naechsten
geschieht
ein
Stufe,
nicht
getrennt I dutch
mehr den
453
COMPASS-Assembler Die
Wahl
(CDC
des
Assemblersprache des
3100).
Objectcodes
bietet
eine
Uebersetzungsaufwandes.
Aasemblerlaufs
sehr
des
IML-Cempilers
Reihe yon Vorzuegen
So koennen
viele
yon einem
Rout i nearbeit en,
SNmbolt abel len~
Konst ant env erarbe it un g
Load-Funkt ionen
uebernommen
doppelten kaum i n s
3.
lexikalisehen Gewicht
werden.
und Der
und s ~ / n t a k t i s e h e n
in der Form
einer
in der R e d u z i e r u n g
sich anschliesser~len wie
Aufstellen
saemt fiche
Naehtei I ~naINse
der
wird
yon
Link-
und
tel lwei sen
dem£egenueber
fallen.
UEBERSET2EI~
3.1 T r a n s l a t o r Writing S~/stem
Der
Compiler
fuer d i e
eompi le rerzeugenden automatisch
Dabei Semantik
Tabellen
(Fig.
>
Fig.
die
S~/st em
erstellt
P~g~minL
wird in
Uebersetzung (Translator
Writing
Semontics of L
l
l
syntax- port of the metocampiler
serr~ntic-port of the metacompiler
Isyntox tableJ
Jsernentic routines I
Ein
Translator
SNntax
Form
einem
System~
TWS)
3).
Syntax of L
3. die
tier CL in IFL wird mit
yon
und FOFtTRAN-Routinen
der
Writing
Sprache
in
semantischen
transformiert.
M etocompiter
Compiler for L > Machinecode
SNstem
£ackus-Naur-Eorm Routinen
(11)
(BNF)
und
veto TWS i n
Der so erstellte
Compiler
454
arbeltet
nach sind
Compilers beschrieben9 erforderl
der
icht
vom
ein (14).
])iese
ist
vor I iegenden
sehr
3.2
kurze
Symbol
einer
erzeugten
im
falls
Input-String
Produktion
kann
des w e a k - p r e c e d e n c e - K o n z e p t e s
die
Bebandlung
TWS
ist
ein
yon
Sprachen~
Programm~
ist.
Die
mit
D a s vom TWS b e n u t z t e
werden.
des
in
yon
die
ihm
nicht
erzeugten
Laenge
Imp l e m e n t i e r u n g
ist
dee
Compi l e r t e l l
des C h a r a c t e r h a n d l i n g s
(15).
FORTRAN und
eine
in
(12113,}
yon 4k
B~/tes° fuer
in ~ssembler
In die
und der
FORTRAN g e s c h r i e b e n °
H e t a c o m p i ler
D.V.
Schorre
erzeugt
und
(16)
wird
ebenfalls
Die Komponenten
einea
Meta-Simulator
und
Compilers.
des
Implementl erung Schritten
eines
ist
Schr it t
-
(Fig.
anschliessend geschieht
auf dadu rch,
eigent der
Meta-Assembler.
Auf
der G r u n d l a g e
die M e t a - S p r a c h e
zur
Meta-S~/stems
ausgelegtt
Der
dass
uird erste
Ur--Compilers yon
liche
Basis
(17}
die
4).
Meta-Sprache~
~eschreibung
dass es
zunaechst
uebersetzen im
we s e n t l i c h e n
Schritt zu e i n e r
ist
die
erweiterten
muss.
Syntax
und
Compilers Seman t l k
~on
eines
in
Die zwei
Erueiterung
Version~
IHL bereitstellen
der
nut die
kanno
die
a|le
Der z w e i t e
IHL-compi let-Design-Phase des
yon
Kontrolle.
Compi lets
des
Meta-II/X
sind
so
Uebersetzung
die
dessen
I HL-Comp i l e r s
Selbstbeschreibung zur
Hetacompiler-SNste~s
sol chen
e igenen
ausgefuehrt
Operaticnen
-
unter
dient
System
Beschreibung
Hilfe des - auf dem M e t a - l l - P r i n z i p
der
{BNF)
Das
mlt
basierenden
laeutt
Baokus-Naur-Form
der
ein
des
~ird9
haben
Der I M L - C o m p i l e r
der
s ~
den C L - C o m p i l e r
Analyse uegen
Parser
Aktionen
Zusaetzlich
fuer
ges c h r i e b e n
fuer
lexikalische
Das
i)ie
(PL-Statement
werden.
verknuepft
erlaubt
IBH/360-As s embler Svntaxtabellen
Element
Erueiterung
sind.
duct ion s
erzeugt
Routine
Erweiterung
der
TNS
Jedes
eine
weak-precedence
Eottom-up-Analyse.
look-ahead
semantischen
Verfahren
der
FI oN d - E v a n s - P r o
in
die
durchgefuehrt einer
Hethode
-
kann
erfolgeno IHL
i n
Dies der
455
Meta-Sprache
formuliert
erweiterten des
Compiler
eerden.
in
der
austuehrbaren Programmes. mit
Hilfe
IML-Statements
Beschreibung
und
liefert
Form
e ines
uebersetzt
IML-Compi I e r s
kann
Diese
die
wlrd
den
dem
Darstellung
interne
fuer
yon
Met a - S i mu l a t o r
Ein in dieser Form vorliegender II~L-Compiler
des
M e t a - S i mu l a t o r s
eine
Oebersetzung
yon
durchtuehren.
SELBSTBESCHREIBUNGS-ZYKLUS
1.SCHRITT
ERWEITERUNGS-ZYKLUS
2.SCI4RITT
Fig.
4.
grstellung
eines
IML-Compilers
~it
~ETA-II/X
(M = M e t a - B e s c h r e i b u n g j C = C o m p i l e r )
Die im
Etgenschaften
wesentlichen
backup-freien Regetn
des
gesam t e n
Me t a - I I / X - S N s t e m s
istt
das fuer
betraegt
5-6
Stackdie
sec
und
-
auf
der
und
der
Hit
diesen
mittlere
das einer
fuer
Compilers
Produktionsregeln~
Einbettung
der
des
semantischen
Eigenschaften
vcl lstaendig IFM/360
stellt
in
ist
Subsl/ste~
ein
E~/tes
IV
90k B N t e s ~ zu bemerken~
-
IML-Compiier
nur
12-
eine
IML-Compiler~eschreibung pro
15k
FCRTRAN
ungefaehr
Hierbei
notwendige
Uebersetzun.qszeit
sind
dar. Dec K e r n s p e i c h e r b e d a r f
Sv s t e m - B u f f e r .
insgesamt
Uebersetzungszeiten und d i e
t
IHL-Uebersetzung
Heta-Simulator
T~vpische
produzierten
Linksrekursivitaet
S~/ntaxstruktur.
einschliesslich
und
Meta-II/X
S~/stem einen O n e - P a s s - U e b e r s e t z e r
geschrieben
dass
der
mit
Top-down-Parsings die
in
solches
die
eines
beansprucht°
IML-Statement
sind
ungefaehr
456 I00 mseoo
4.
AUSBLICK Wie
eine
schon
mehrmals
Host-Sprache.
Ist
Host-Parasite-Konzept leicht
zu
ein
erwaehnt,
die
beaoetigen
Host-Spraehe
integriertes
implementieren und zu handhaben
solches
Host-
Prebleme
und P a r a s i t e - S p r a c h e optimale
nicht
so
ist
das
/st. Bei Einbettung
yon CL
koennen dagegen die bereits
2) auftreten.
Ferner ist
ein
s y n t a k t i s c h e n Konzeptionen yon
gerade programmierfreundlich.
Loesung
in eine
CAMAC-Funktionen
hoehere
bietet
nut
die
Integration
Real-Time-Programmierspraehe.
yon So i s ,
der aktuellen D e f i n i t i o n yon PEARL (18) die V c r a u s s e t z u n g gegeben,
CAMAC-Software die
Abschnitt
System wegen der v e r s c h i e d e n e n
Eine
in
(siehe
Assembler,
IML
Prcgrammiers~/stem, das r e l a t i v
und [ML in eine hoehere P r o g r a m m i e r s p r a e h e aufgezeigten
so=ohl CL als auch
adaequat e ~ s t e l l e n
Aktivitaeten
E n t w i c k l ung
der
einer
zu k o e n n e n .
LTPL/E-Gruppe um f a s s e n d e n
verwiesen,
Darueber h i n a u s s e i die
ge@enwaertig a n d e r
Bea 1-T i m e - P r o g r a m m i e r s p r a c h e
E i n b e z i e h u n g des CAMAC-S.vstems a r b e i t e t .
LI TERATURANGABEN
(Ol)
CAMAC Bulletin9
(02)
L e w i s , A,,, D e f i n i t i o n o f t h e Camac I n t e r m e d i a t e Language. SNG 1/74 (1974)~ ESONE-SNG, Draft Deport.
(03)
CAMAC: h Modular Instrumentation SNstem for D a t a H a n d l i n g . EUR 4100 ( 1 9 7 2 ) , Esone Committee~ Ispra~ It alien.
(04)
K a t z , A-, CAHAC, CAMAC2 Macro Implementations. SInG 4 4 / 7 3 , 45/73 ( 1 9 7 3 ) , ESONE-SWG, D r a f t R e p o r t s .
(05)
Davies, M. P. H-9 Hagan, P. J.~ Implementation on a Mult i-User P D P - I O / P D P - 7 S v s t e m - A High Level User Language. European Decus Proceedings, Aug. 1972
(06)
Thomas, B. F . , J r . , S p e c i f i c a t i o n s f o r Standard CAMACSubroutines. CAMAC B u l l e t i n , E (1973).
5t Supplement
auf
(1972).
unter
457 (0z)
Kneis, N., General Aspects of Translation and Implementation of the CAMAC IML. SNG 13/73 (1973), ESONE-SWG, Draft R e p o r t .
(0s)
Kneis, W., Implementation of CAMAC IML in an Assembler Language Environment. (wird veroeffentlicht in-" CAM#~C B u l l e t i n , 1 0 , Juli 1974)
(09)
CAMAC: Organisation of Multi-Crate SNstems. EUR 4600 (1972), ES(]~E Committee, Ispra, Italien.
(10)
Hagan, P- J - t IML Macro-Expansion Syntax. SWG 2/74 ( 1 9 7 4 ) , ESONE-SWG, D r a f t Report.
(11)
Feldmann, J. A-, A Formal Semantics for Computer L a n g u a g e s and i t s A p p l i c a t i o n in a £ o m p i l e r C o m p i l e r . Comm. ACM, c ( 1 9 6 6 ) , p. 3°
(lz)
Evans, A-, J r . An A l g o l 60 C o m p i l e r . Ann. Rev. Automatic Programming 4 (1964), p. 87.
(13)
Flo.~d, R. W., A D e s c r i p t i v e Language f o r SNmbcl M a n i p u l a t i o n . J. ACbioS, 10 ( 1 9 6 1 ) , p. 57g.
(14,)
Knuth, D. E . , On the ~[ranslation o f Languages from L e f t to B i g h t . I n f . Contr. 8 ( 1 9 6 5 ] , p. 607.
(15)
I c h b i a h , J. D., Morse, S. P.~ A Technique f o r Generating Almost Optimal Floyd-Evans P r o d u c t i o n s , f o r Precedence Grammers. Comm. ACM, 13 (1970) po riO1.
(zs)
S c h o r r e , D. V., META I f , a s ~ n t a x - c r i e n t e d c o m p i l e r w r i t i n g language. Proc. o f the 19th N a t l . ACM C o n f . , ( 1 9 6 4 ) , DI.
(17)
Kneis, N., META-II/X - B e i s p i e l eines M e t a c o m p i l e r S~/stems. (noch zu v e r o e f f e n t l ichen).
(is)
PEARL - A Proposal f o r a Process- and Experiment Automation IRealtime Language, Ges. f u e r Kernfcrschung, KfK-.PDV1, A p r i l { 1973).
EIN VERFAHREN ZUR OPTIMIERUNG VON SYSTEM-PROGRAMMEN P.J. Brunner, W. Hinderer, W. Werum
1.
EINLEITUNG
Da h~here Programmiersprachen die Systemprogrammierung
(z.B. PL/I)
in zunehmendem MaDe auch for
eingesetzt werden,
9ewinnt die Frage, wie ei-
ne Optimierung des Codes solcher System-Programme
zur Ubersetzungszeit
m6glich ist, immer mehr an Bedeutung. Es wird hier ein Optimierungsprogramm
(Optimizer)
Auftrag der Bundesregierung als Projekt von PDV forschung)
vorgestellt,
das im
(Gesellschaft fur Kern-
im Hause Entwicklungsb~ro Wulf Werum entwickelt wurde.
Das Programm ist in PL/I geschrieben und arbeitet auf der Basis der weitgehend sprach- und maschinenunabh~ngigen
Zwischensprache
ILl, die im
gleichen Hause entwickelt wurde. Das zu optimierende Objekt-Programm wird in ILl eingegeben und, optimierten Fassung,
in ILl ausgegeben.
in der
Dadurch ist der Optimizer selbst
ebenso sprach- und maschinenunabh~ngig. Es ist gedacht, dad der Optimizer eingesetzt wird als Bestandteil eines Compilers,
der
I. das Quellprogramm v o n d e r 2. den Optimierungslauf
h6heren Programmiersprache
anschlieBt
nen, diesen Lauf unterl~Dt),
(oder wahlweise,
in ILl ~bersetzt,
z.B. bei Testversio-
und
3. das in der Zwischensprache vorliegende Objekt-Programm oder nicht optimiert)
(optimiert
in den Maschinencode des Zielrechners Obertr~gt.
Der Optimizer fOhrt folgende OptimierungsmaDnahmen
durch:
I) Beseitigung redundanter Berechnungen 2) Bewegung von Berechnungen aus Schleifen heraus vor deren Eingang 3) Reduktion von Multiplikationen,
deren einer Faktor in einer Schleife
linear fortgeschaltet wird, einschlieBlich linearer AdreD-Fortschaltung bei Feldelementberechnungen
(strength-reduction).
Zwischen der Beseitigung redundanter Berechnungen und der Bewegung von Berechnungen aus Schleifen heraus besteht ein enger Zusammenhang: Eine Berechnung der Operation OP grammstelle gilt als redundant,
(z.B. O P ~ A + B )
an einer gewissen Pro-
wenn sie auf allen mSglichen Programm-
459
verf~gbar ist, d.h. bereits vorher ausgef~ihrt wurde, ohne dab sie zwischendurch durch einen Seiteneffekt
wegen, die zu dieser Stelle fHhren,
auf 0P (d.h. auf einen ihrer Operanden, oder durch einen Prozeduraufruf,
z.B. durch eine Zuweisung A=5
der B ver~ndert)
ung~ltig wurde. In
diesem Fall kann die neue Berechnung der Operation unterbleiben und durch den - auf einer wohlbestimmten Hilfsze!le H liegenden - Wert der frHheren Berechnung ersetzt werden. Wenn nun eine Berechnung yon OP am Ende einer Programmschieife SchleifenrHckweg)
(auf dem
verfHgbar ist, und wenn auBerdem auf allen Wegen vom
Eingang der Schleife
(Schleifenkopf)
zu einer Berechnungsstelle
yon OP
innerhalb der Sch!eife kein Operand von OP modifiziert wird, dann ist die Berechnung an dieser Stelle genau dann verf~gbar, wenn sie bereits beim Eintritt des Programmab!aufs
in die Schleife verf~gbar war.
Wenn man also ggf. eine Berechnung von OP unmittelbar vor dem Schleifenkopf ins Programm einfHgt, dann wird die - i.a. wesentlich 6fter durchlaufene
- Berechnung in der Schleife redundant.
Beis~iele der vom Optimizer durchgef~hrten O~timierun~smaBnahmen I) Beseitigung redundanter Berechnungen
a) A+B <
~
A+B
H=A+B
~
H=A+B
b)
~
A
+
B ~
~
A+B
~
H=A+B
460 2) Bewegung von Berechnungen aus Schleifen H=A+B
a)
>
~H=A+B
b)
< 3)
>
> AA=+ B A+B
=A+B
Reduktion von Multiplikationenund von Feldelementberechnungen
~W=I*J+K k_/D=5*j
a)
b)
~I=I
~
I=I+X ,J)
1=I W=Adresse von A(I,J) D=X*Zeilenl~nge von A
~
W=W+D
~
indirekt
461
In den O p t i m i z e r ist als R H c k k o p p e l u n g s e f f e k t die M 6 g l i c h k e i t der Komm u n i k a t i o n mit dem P r o g r a m m i e r e r eingebaut: Nach einer ersten O p t i m i e r u n g s p h a s e wird an den P r o g r a m m i e r e r eine Liste von F r a g e n ausgegeben,
dutch deren B e a n t w o r t u n g er solche O p t i m i e -
r u n g s m ~ g ! i c h k e i t e n b e w e r t e n kann, d e r e n E f f e k t i v i t ~ t durch den Optimizer nicht a u t o m a t i s c h erkannt wird. In der zweiten Phase w e r d e n die A n t w o r t e n dann fdr die H e r s t e l l u n g des o p t i m i e r t e n Codes ausgewertet. In den obigen B e i s p i e l e n 2a, 2b, 3a w~ren Die
"Optimierung"
in 2a k6nnte n ~ m l i c h dann eine V e r s c h l e c h t e r u n g
des P r o g r a m m s bringen, d u r c h l a u f e n wird.
z.B. Fragen zu stellen:
%~enn der rechte Ast der Schleife fast nie
F r e i l i c h stellt die O p t i m i e r u n g s m a B n a h m e
schon
dann p r a k t i s c h keine V e r s c h l e c h t e r u n g dar, wenn die d u r c h s c h n i t t iiche Anzahl der D u r c h l ~ u f e d u t c h den rechten Ast pro S c h l e i f e n e i n t r i t t gr6Ber als I i s t . In B e i s p i e l 2b k6nnte es sein, dab die d a r g e s t e l l t e S c h l e i f e gar nicht "echt" ist, d . h . , d a B der e i n g e z e i c h n e t e R0ckweg p r a k t i s c h nie d u r c h l a u f e n wird. V i e l m e h r k6nnte es sein, dab eine echte Schleife
(hier n i c h t eingezeichnet)
gang l~uft. bleiben,
~ber den e i n g e z e i c h n e t e n oberen A u s -
In d i e s e m Fall sollte die O p t i m i e r u n g s m a B n a h m e unter-
da die B e r e c h n u n g von A+B viele Male umsonst d u r c h g e f H h r t
wOrde. in B e i s p i e l
3a liegt der Fall ~hnlich wie in 2a.
Die B e a n t w o r t u n g von Fragen d u r c h den P r o g r a m m i e r e r gung f0r die Optimierung.
ist nicht Bedin-
Wenn keine A n t w o r t e n gegeben werden,
werden
nur "sichere" O p t i m i e r u n g s m a B n a h m e n durchgef~hrt. Ein w e s e n t l i c h e s H i l f s m i t t e l
fur die O p t i m i e r u n g ist die sog.
zweig-
spezifische Protokollierung: Bei der B e a r b e i t u n g des P r o g r a m m s w i r d ~ber V e r z w e i g u n g e n und Z u s a m m e n fdhrungen hinweg ein P r o t o k o l l d y n a m i s c h gefHhrt. rationen,
Es enth~it alle Ope-
deren B e r e c h n u n g aktuell v e r f H g b a r ist.
Tritt eine B e r e c h n u n g einer O p e r a t i o n OP auf, aufgenommen,
so w i r d OP ins P r o t o k o l l
falls sie nicht schon drin ist(und damit die B e r e c h n u n g
r e d u n d a n t ist) . Bei einem a u f t r e t e n d e n S e i t e n e f f e k t w e r d e n alle Operationen, deren B e r e c h n u n g d a d u r c h u n g ~ i t i g wird,
aus dem P r o t o k o l l ge-
strichen. Bei P r o g r a m m - Z u s a m m e n f O h r u n g e n wird eine Synthese der V o r g ~ n g e r - P r o tokolle d u r c h g e f ~ h r t .
462
Unter BerHcksichtigung der speziellen Anforderungen der Systemprogrammierung wurde bei der Entwicklung des Optimizers davon ausgegangen, dab die f~r das zu optimierende Quellprogramm verwendete Programmiersprache die M~glichkeit der Arbeit mit Bez~gen Markenvariablen,
(Pointer, Referenzen),
Prozedurvariablen und Semaphore-Variablen
enth~it.
Dadurch wurde die Strategie for den Aufbau des Programm-Graphen
sowie
fHr die Verfolgung der VerfHgbarkeit von Berechnungen beeinfluBt. ~laschinenabh~ngige Optimierungen
(z.B. Register-Optimierung)
vom Optimizer nicht durchgef~hrt.
werden
Diese sollten auf einer maschinen-
nahen Ebene und nicht auf der Ebene einer maschinenunabh~ngigen
Zwi-
schensprache geschehen. Die Datenstruktur des Optimizers
(insbesondere die Form der Protoko!le)
ist so gew~hlt, dab nachtr~glich weitere OptimierungsmaBnahmen
einfach
eingebaut werden k6nnen.
2. DIE FUR DIE OPTIMIERUNG BENOTIGTEN INFORMATIONEN Es ist klar, dab der Optimizer das Quellprogramm nicht logisch ver~ndern darf: Die Ausgabe des optimierten Programms muB mit der des nicht optimierten Programms bei gleichen Eingabe-GrSBen Hbereinstimmen.
Zur
Durchf~hrung der Optimierung ist eine genaue Analyse des Quellprogramms nach mehreren Gesichtspunkten notwendig: Anweisungsfolge des Programms Der DatenfluB muB m~glichst genau bekannt sein. Zur Verfolgung der Verf~gbarkeit von Berechnungen mOssen alle Zuweisungen und Prozeduraufrufe auf ihre Seiteneffekte bin untersucht werden. Mit Hilfe einer Vorab-Untersuchung Peinter-Stellungen
der im Program~ vorkommenden
(Einstellung yon BezHgen) muB insbesondere er-
mittelt werden, welche realen Gr~Ben sich bei der Zuweisung zu einer BASED-GreBe
(basisbezogene Variable in PL/I, Bezugsgr~Be)
ver~ndern k~nnen. Programm-Topologie Die Ablaufm~glichkeiten
des Programms sind zu ermitteln.
gHltigen Erstellung des Programm-Graphen realen Sprung-Ziele, einer
Zur end-
ist es n~tig, dab alle
die sich hinter einer Anweisung GOTO M mit
(wom6glich BASED-)Markenvariablen M oder hinter einem Pro-
zeduraufruf verbergen k~nnen, m~glichst genau bekannt sind. Damit auch in solchen F~llen eine Verbesserung des Program/n-Codes m~glich ist, in denen die Informationen aus der Anweisungsfolge und aus
463
der P r o g r a m m - T o p o l o g i e nicht ausreichen,
ist eine w e i t e r e I n f o r m a t i o n s -
quelle eingebaut: S t e u e r - I n f o r m a t i o n e n des P r o g r a m m i e r e r s Sie w e r d e n v o m P r o g r a m m i e r e r g e g e b e n als A n t w o r t e n auf die vom Optim i z e r p r o d u z i e r t e n F r a g e n der Art: "Soll die B e r e c h n u n g der O p e r a t i o n xx in S t a t e m e n t Nr. y y vor Statement Nr.
zz g e z o g e n w e r d e n ? " oder
"Soll in S t a t e m e n t Nr. uu R e d u k t i o n bezgl, der Schleife xyz d u r c h g e fHhrt werden?" H i e r d u r c h sind auch O p t i m i e r u n g e n m6glich, die ohne die "spezie!le Erlaubnis"
des P r o g r a m m i e r e r s v e r b o t e n sind, weil sie u.U. die Pro-
g r a m m l o g i k v e r ~ n d e r n - z.B. wenn durch die H e r a u s z i e h u n g einer Ber e c h n u n g aus einer Schleife die M S g l i c h k e i t eines Z E R O D I V I D E oder eines O V E R F L O W entsteht. Die Intensit~t, mit der die g e n a n n t e n I n f o r m a t i o n e n e i n g e h o l t und vera r b e i t e t werden,
h~ngt v o n d e r
w e i s e w ~ r e es immer m~glich,
K o n z e p t i o n des O p t i m i z e r s ab. B e i s p i e l s I n f o r m a t i o n e n durch 8ichere Annahmen
zu er-
setzen: So k6nnte bei einer Zuweisung zu einer B A S E D - G r 6 B e a n g e n o m m e n werden, dab sie einen S e i t e n e f f e k t auf alle V a r i a b l e n hat. D u r c h solche s i c h e r e n A n n a h m e n w i r d jedoch im a l l g e m e i n e n d e r O p t i m i e r u n g s e f f e k £ stark b e e i n t r ~ c h t i g t . Andererseits
sind einer b e l i e b i g g e n a u e n A n a l y s e G r e n z e n gesetzt, wenn
der O p t i m i z e r nicht b e l i e b i g k o m p l e x w e r d e n soll. e i n e m e r h e b l i c h h ~ h e r e n A u f w a n d m~glich,
So w ~ r e es z.B. mit
dab der O p t i m i z e r bei einem
Sprung Hber eine M a r k e n v a r i a b l e nur die an der S p r u n g s t e l l e d y n a m i s c h m~glichen
(sich aus der G e s c h i c h t e des P r o g r a m m a b l a u f s ergebenden)
Sprungziele
in B e t r a c h t zieht.
Der hier g e w ~ h l t e M i t t e l w e g ist der, dab b e i m Sprung Hber eine M a r k e n v a r i a b l e alle M a r k e n k o n s t a n t e n , wo
deren Wert der M a r k e n v a r i a b ~ n irgend-
im P r o g r a m m zugewiesen sein kann,
als m 6 g l i c h e s
Ziel a n g e n o m m e n
werden. N i c h t zuletzt sind der O p t i m i e r u n g auch d a d u r c h G r e n z e n gesetzt, die f0r das Q u e l l p r o g r a m m v e r w e n d e t e hShere P r o g r a m m i e r s p r a c h e PL/I)
u.U.
dab
(z.B.
zu groBe M S g ! i c h k e i t e n bietet° Der v o r g e s t e ! i t e O p t i m i z e r
k a p i t u l i e r t z.B. durch eine sichere Annahme, w e n n ~ber eine B A S E D BINARY F I X E D - G r e B e ein P o i n t e r w e r t v e r s t e l l t wird.
464
3. DARSTELLUNG IN I L l In der Zwischensprache ILl liegt das Quel!programm in einer OperatorSchreibweise vor: Jedes Statement ist in eine Folge yon elementaren IL1-Operationen in der Reihenfolge ihrer tats~chlichen Abarbeitung zerlegt. Eine ILl-Operation hat das Format: Operator
Operand... Operand
Der Operator repr~sentiert elne elementare Operation
(+, *, :=, GOTO
etc.) und enth~it zus~tzlich Informationen ~ber den Typ der Operanden (z.B. gibt es einen speziellen Operator fur die Addition BINARY FIXEDEinfachwort + BINARY FIXED-Doppelwort mit dem Resultat BINARY FIXEDDoppelwort). Die Anzahl der Operanden einer ILl-Operation h~ngt vom Operator ab. Als Operanden k6nnen auftreten: Eine Variablen-Nr., eine Konstanten-Nr. oder ein Hinweis auf das Resultat einer im gleichen Statement vorangehenden ILI-Operation. Eine Variablen-Nr.
ist eine Bezugnahme auf eine eindeutige Beschrei-
bung der jeweiligen Variablen in einem Vormerkbuoh, das als Bestandteil des ILI-Programms parallel zum programmcode angelegt ist. Aus dieset Beschreibung l~Bt sich auch der Name der Variablen ermitteln. Eine Konstanten-Nr. ist eine Bezugnahme auf das ebenfalls im Vormerkbuch enthaltene Konstantenbuch. AIs Referenz-Typ enth~it jeder 0perand, der eine Variable repr~sentiert, noch den Vermerk
'Adresse',
'indirekt' oder
'direkt' und ebenso enth~It
jeder Operand, der ein Hinweis auf eine vorangehende ILI-0peration ist, den Vermerk
'direkt' oder
'indirekt'.
Eine vollst~ndige Beschreibung yon ILl ist in [11] enthalten.
4.
VORBEREITENDE UNTERSUCHUNGEN, EINTEILUNG DES QUELLCODES
4.1 POINTER- UND MARKENVARIABLEN-STELLUNGEN, Zun~chst werden alle im Quellprogramm vorkommenden Einstellungen der Pointer, Markenvariablen und Prozedurvariablen gesammelt. Hierin eingeschlossen ist die Ermittlung der aktuellen Parameter, die bei Prozeduraufrufen mit Parametern eines der genannten Typen auftreten k~nnen. Diese Daten stehen w~hrend der gesamten Optimierung zur VerfHgung.
465
Durch den A u f r u f den,
welche
einer Routine
realen
ten sich hinter zedurwariablen
Gr~Ben
einer
kann m i t
bzw.
BASED-Variablen
verbergen
festgestellt
bzw.
wer-
Prozedurkonstan-
bzw. M a r k e n v a r i a b l e n
bzw.
Pro-
k6nnen.
4.2 EINTEILUNG IN GEBIETE, N a c h d i e s e r lung des Q u e l l c o d e s
ihrer Hilfe
Markenkonstanten
Untersuchung
folgt die A u f t e i -
Optimierungsgebiete und die E r m i t t l u n g ihrer
in
Aufruf-Hierarchie: Ein O p t i m i e r u n g s g e b i e t Progr~nmteil
ren
eptimiert
sind die
(einschlieBlich
ein G e b i e t
in GI
Da d i e s e
dab GI
aus a u f g e r u f e n
biets w e r d e n
durch
4.3 ANALYSE DER erstellt
spr0nge
wird.
yon GI
an
sowie die m 6 g -
bei der O p t i m i e r u n g
anfallen,
ist daf~r
rekursive
gesorgt, falls
G2 yon der
Prozeduraufrufe
Stelle d u r c h g e s c h n i t t e n ,
Ausspr~nge
sichere A n n a h m e
wird,
dab eine A u f r u f - H i e r a r c h i e
Treten
an einer
durchlaufen
Die V e r b i n d u n g e n
werden,
des n u n m e h r
und
innersten
Ge-
ersetzt.
dieses
Graphen
repr~sentie-
Hber M a r k e n v a r i a b l e
werden
dabei
die
ohne Ein- oder A u s s p r H n g e
des G r a p h e n
eines B a s i s b l o c k e s
SprHnge
Basisbl~cken
GI aus
SCHLEIFENSTRUKTUR, FUr jedes G e b i e t wird der e n d g 0 i t i g e
vom Ende
Prozeduren
stehen
zum A n f a n g
eines N a c h f o l g e r - B a s i s -
oder A u s s p r 0 n g e
durch Verbindungen
in
f~r die A b l a u f -
aus a u f g e r u f e n e n
zu den in Frage
kommenden
dargestellt.
Schleifenstruktur
genden b e s c h r i e b e n e n gebnis
und P r o z e d u -
auf in GI be-
Gr~Ben),
Ausspr~nge
mit
(Gebietsgraph) . Die K n o t e n
sequentiell Inneren.
blockes.
Die
dieses A u f r u f s
G2 vor GI b e h a n d e l t
m6glichen
eine
Funktionen
Basisbl~oke des Gebiets, d.h. die P r o g r a m m - S e q u e n z e n ,
ren die streng
yon anderen
Wenn yon e i n e m G e b i e t
globale
Dies bedeutet,
erstellt
bzw.
unabh~ngig
- ist ein
aus G2 interessant.
und m 6 g l i c h e n
die A u f r u f - K e t t e
die S e i t e n e f f e k t e
ihrem
Parameter,
AussprOnge
wird.
Gebiet
so sind bei der O p t i m i e r u n g
Seiteneffekte
I. O p t i m i e r u n g s p h a s e
so wird
vorkommenden
I. O p t i m i e r u n g s p h a s e
Optimierungsgebiete
Graph
wird,
(aktuelle
Seiteneffekte
in der
auf,
im P r o g r a m m
liegenden
von G2 in der
fur sich,
der M A I N - P r o z e d u r ) .
nur die
kannte Variable
der
einfach:
wird.
G2 a u f g e r u f e n
der A u f r u f s t e l l e
lichen
im f o l g e n d e n
des Q u e l l p r o g r a m m s ,
Programmteilen Die G e b i e t e
- oder
in einer
Der A l g o r i t h m u s
dieses
Gebietsgraphen
wird m i t Hilfe
Schleifensuch-Algorithmus
untersucht
des
im fol-
und das Er-
Schleifenbeschreibung z u s a m m e n g e s t e l l t . arbeitet
mit
einem Keller,
in dem P r o g r a m m w e g e
auf-
466
und abgebaut werden.
Jede V e r b i n d u n g des Graphen wird dabei genau ein-
mal behandelt. Beginnend beim Eingangsknoten
(oder, falls das Gebiet m e h r e r e E i n g a n g s -
knoten hat, bei e i n e m d i e s e n allen v o r g e s c h a l t e t e n h y p o t h e t i s c h e n Eingangsknoten)
w i r d ein K n o t e n K' dann in den Keller Hbernommen, w e n n er
N a c h f o l g e r des letzten im Keller stehenden Knotens K ist und die V e r bindung K-->K' bisher noch nicht b e h a n d e l t wurde. Auf diese Weise entsteht im Keller ein Weg, der Schritt fHr Schritt f o r t g e s e t z t wird. Trifft eine F o r t s e t z u n g K-->K' auf einen bereits im Keller b e f i n d l i c h e n Knoten K', so ist d a m i t eine Schleife erkannt. dieser Schleife,
K ihr S c h l i e B k n o t e n
K' ist der K o p f k n o t e n
(latching n o d e ) u n d die V e r b i n d u n g
K-->K' ihr S c h l e i f e n r H c k w e g . Oanach wird der zuletzt e i n g e t r a g e n e Knoten K' wieder a u s g e k e l l e r t und der Weg mit einer neuen A l t e r n a t i v e K-->K" fortgesetzt. her noch nicht behandelte)
Ist keine
A l t e r n a t i v e K-->K" mehr vorhanden,
auch K und s u c c e s s i v e w e i t e r e Knoten aus dem Keller entfernt,
(bis-
dann wird solange
bis sich w i e d e r eine neue F o r t s e t z u n g s a l t e r n a t i v e bietet. Trifft eine F o r t s e t z u n g auf einen Knoten K, der zwar nicht m e h r im Keller ist, aber schon einmal darin war und zu einer bereits e r k a n n t e n Schleife S geh6rt,
deren K o p f k n o t e n KK sich noch im Keller befindet,
dann ist damit ein N e b e n w e g in der Schleife S erkannt. Der a u f g e b a u t e Weg KK-->...-->K wird dann zu S hinzugeschlagen. Wenn sich in der eben b e s c h r i e b e n e n S i t u a t i o n der K o p f k n o t e n KK der Schleife S nicht m e h r im Keller befindet, dann ist h i e r m i t ein sekund~rer E i n g a n g in die Schleife S erkannt. N a c h d e m ein N e b e n w e g in einer Schleife oder ein sekund~rer E i n g a n g erkannt wurde,
wird der zuletzt in den Keller a u f g e n o m m e n e Knoten w i e d e r
e n t f e r n t und nach F o r t s e t z u n g s a l t e r n a t i v e n gesucht
(s.o.).
Die e r k a n n t e n S c h l e i f e n w e r d e n nach f o l g e n d e n Regeln in eine S c h l e i f e n H i e r a r c h i e eingeordnet: I) Der ganze G e b i e t s g r a p h ist per d e f i n i t i o n e m eine Schleife SO, auch w e n n sie keinen w i r k l i c h e n S c h l e i f e n r ~ c k w e g enth~it.
SO umfaBt alle
anderen Schleifen und steht in der H i e r a r c h i e ganz oben. 2) Eine Schleife Sl ist in der Schleife $2 enthalten,
wenn $2 den Kopf
von Sl, aber $I nicht den Kopf yon S2 enth~it. 3) Wenn $I und $2 d e n s e l b e n K o p f k n o t e n haben, dann ist jewei!s die Schleife die umfassende, die den S c h l i e B k n o t e n der a n d e r e n enth~it. 4) W e n n $I und $2 d e n s e l b e n K o p f k n o t e n haben,
aber keine den S c h l i e ~ -
467
k n o t e n der anderen enth~it,
dann ist die S c h a c h t e l u n g dieser Schlei-
fen w i l l k H r l i c h und h~ngt v o n d e r
R e i h e n f o l g e ihrer E r k e n n u n g ab.
5) Eine S c h l e i f e S mit s e k u n d ~ r e n E i n g ~ n g e n w i r d in der H i e r a r c h i e dann nicht als eigene Schleife gefHhrt, wenn einer dieser s e k u n d ~ r e n E i n g ~ n g e auch ein sekund~rer Eingang in eine in S e n t h a l t e n e innere S c h l e i f e ist.
In d i e s e m Fall w i r d S der kleinsten,
alle V o r g ~ n g e r -
Knoten von S e n t h a l t e n d e n Schleife zugeschlagen. - Da b e k a n n t l i c h p r o g r a m m i e r t e
S c h l e i f e n mit s e k u n d ~ r e n E i n g ~ n g e n
sehr selten auftreten, b e e i n t r ~ c h t i g t diese e i n s c h r ~ n k e n d e Regel den O p t i m i e r u n g s e f f e k t nicht wesentlieh. Wie Regel
(4) zeigt, ist d i e s e r A u f b a u der S c h l e i f e n - S c h a c h t e l u n g nicht
ganz frei von WillkHr. A u c h k 6 n n t e n S t r u k t u r e n als S c h l e i f e n e r k a n n t werden,
die in W i r k l i c h k e i t nicht als solche d u r c h l a u f e n werden. Wenn
jedoch eine Schleife vom P r o g r a m m i e r e r a u s d r H c k l i c h als D O - S c h ! e i f e p r o g r a m m i e r t wurde, sonders vermerkt.
dann w i r d dies in der S c h l e i f e n - B e s c h r e i b u n g be-
In diesen F~llen e r 0 b r i g e n sich n ~ m l i c h u.U.
der vom O p t i m i z e r an den P r o g r a m m i e r e r a u s z u g e b e n d e n Fragen. B e i s p i e l eines G e b i e t s ~ r a p h e n mit S c h l e i f e n b e s c h r e i b u n g (Eingangsknoten) s
....$3 .
i
i I
Schleife SI b e s t e h t aus K3, K4 S2
K6, K7
$3
K5, S2, K8
$4
K2, $I, $3, K9
SO
K1, S4, KIO
einige
468
In der B e s c h r e i b u n g
einer Schleife
ten und U n t e r - S c h l e i f e n tragen,
S w e r d e n die
(Elemente)
in so!ch einer R e i h e n f o l g e
dab der Kopf v o n S am A n f a n g
steht und im H b r i g e n
erst nach all seinen V o r g ~ n g e r - E l e m e n t e n ist.
Dies
ist die Reihenfolge,
Protokollierung Jede
Schleife
die E l e m e n t e
erh~it
innerhalb
in der dann bei der
von S b e h a n d e l t
Stellvertreter
Kno-
einge-
ein E l e m e n t
von S a u f g e f ~ h r t zweigspezifischen
werden.
zugeordnet,
Schleifenersatzblock (SEB).
den sog.
Der SEB einer
Schleife
S entspricht
logisch
einem Basisblock,
der un-
vor d e m Kopf von S als Best&ndteil der S umfassenden Schleife
mittelbar
ins Q u e l l p r o g r a m m
eingef~gt
den Kopf hinfHhren, fenr~ckweg Kopf von
einen
in S e n t h a l t e n e n
ist. A l l e Wege,
sind dabei
auf d i e s e n
von S ist n i c h t u m g e l e n k t
S. N a c h f o l g e r k n o t e n
des
die yon a u ~ e r h a l b
SEB umgelenkt.
S auf
Der S c h l e i -
und fHhrt nach wie vor d i r e k t
SEB sind alle
zum
Ziele der A u s s p r H n g e
aus S. Der SEB d i e n t bei der O p t i m i e r u n g Schle i f e
und der sie u m f a s s e n d e n
Schleife
werden
ihres
die
dem InformationsfluB Sch!eife.
in ihr e n t h a l t e n e n
zwischen
Bei der B e h a n d l u n g
Unterschleifen
einer
einer
nur in G e s t a l t
SEB b e r H c k s i c h t i g t .
Wenn es d u r c h U m l e n k e n nennung
von S p r H n g e n
von M a r k e n m ~ g l i c h
deren E i n g a n g sisbl o c k
ist, den SEB einer
ins Q u e l l p r o g r a m m
einzuf~gen,
bzw.
Schleife
d u r c h Umbe-
tats~chlich
vor
so w i r d er als eigener
Ba-
(Vorberechnungsblock) B e s t a n d t e i l des o p t i m i e r t e n Programms.
Er e n t h ~ i t
dann die B e r e c h n u n g e n
0perationen
bzw.
te R e d u k t i o n e n zugeordneten
Die A r b e i t
der aus der S c h l e i f e
die V o r b e r e c h n u n g e n
und e n d e t m i t einer
Schleife
Sprunganweisung
Schleife,
zu den e i n g e s c h a c h t e l t e n
satzbl6cke
hergestellt
Auf d i e s e r
Ebene
geschieht
haupts~chlich
Schleifen
durch die
auf
zur ~ b e r g e o r d Schleifener-
ist.
sind u.a.
Eintr~ge
und von A n w e i s u n g
Ist die B e r e c h n u n g
zum Kopf der ihm
2 und 3 in der Einleitung) .
w o b e i die V e r b i n d u n g
neten bzw.
vorzunehmen
durchgefHhr-
PROTOKOLLIERUNG
des O p t i m i e r u n g s - A l g o r i t h m u s
der E b e n e der e i n z e l n e n
herausgezogenen
fHr ~n der Schleife
(siehe B e i s p i e l e
5. METHODE DER ZWEIGSPEZIFISCHEN
bar?
im Q u e l l p r o g r a m m
zur B e a n t w o r t u n g
zu A n w e i s u n g
der O p e r a t i o n
folgender
Fragen
zu t r a n s f o r m i e r e n :
OP an der a k t u e l l e n
Stelle v e r f ~ g -
469
Auf w e l c h e V a r i a b l e n gibt es auf i r g e n d e i n e m Weg v o m S c h l e i f e n k o p f zur a k t u e l l e n Stelle einen S e i t e n e f f e k t ? Liegt auf e i n e m Weg vom S c h l e i f e n k o p f
zur a k t u e l l e n Stelle ein Aus-
gang aus der Schleife? Konnte die B e r e c h n u n g der O p e r a t i o n OP, die am S c h l e i f e n k o p f v e r f H g oar war,
auf i r g e n d e i n e m Weg bis zur a k t u e l l e n Stelie w i e d e r v e r w e n -
det werden? Gibt es einen Weg vom S c h ! e i f e n k o p f
zur a k t u e l l e n Stelle,
auf dem
keine B e r e c h n u n g s s t e l l e der O p e r a t i o n OP v o r k o m m t ? ~elches
sind die E r s t - B e r e c h n u n g s s t e l l e n der an der a k t u e l l e n Stelle
v e r f H g b a r e n B e r e c h n u n g der O p e r a t i o n OP? Diese I n f o r m a t i o n e n sind yon der Art, dab ihr Status nach einer A n w e i sung eine F u n k t i o n des Status u n m i t t e l b a r vor der A n w e i s u n g und der Anweisung selbst ist, und dab ihr Status vor einer A n w e i s u n g eine elementare logische bzw. m e n g e n t h e o r e t i s c h e F u n k t i o n Durchschnitt)
(UND, ©DER, Vereinigung,
der Stati am Ende aller V o r g ~ n g e r - A n w e i s u n g e n ist.
Die E i n t r ~ g e g e s c h e h e n in einem sog. Protokoll.
Vor Beginn der B e a r b e i -
tung einer Schleife wird das Protokoll g e e i g n e t initialisiert, w e r d e n die Knoten der Schleife, der S c h l e i f e n - B e s c h r e i b u n g
beim Kopf beginnend,
festge!egten)
in der
dann
(bereits in
R e i h e n f o l g e behandelt,
in der
ein K n o t e n erst n a c h seinen s~hrttlichen V o r g ~ n g e r n i n n e r h a l b der Schlei.) fe u n t e r s u c h t wird. Bei einer V e r z w e i g u n g s s t e l l e wird jeder von dort a u s g e h e n d e n V e r b i n d u n g eine Kopie des aktuell g ~ i t i g e n Protokolls
zugeordnet,
so dab bei einer
n a c h f o l g e n d e n Z u s a m m e n f H h r u n g das aktuell gHltige P r o t o k o l l d u r c h eine g e e i g n e t e Synthese aus allen Protokollen, b i n d u n g e n zugeordnet wurden,
die den dort h i n f ~ h r e n d e n Ver-
e r m i t t e l t w e r d e n kann.
Die T r a n s f o r m a t i o n Hber eine innere S c h l e i f e hinweg g e s c h i e h t nur d u r c h die B e h a n d l u n g ihres SEB.
In ibm liegen die hierfHr n o t w e n d i g e n D a t e n
yon der frHheren B e h a n d l u n g der inneren Schleife bereits vor, und in ihm w e r d e n auch D a t e n fHr die w e i t e r e B e a r b e i t u n g eingetragen. Ein E i n t r a g im Protokoll,
der die O p e r a t i o n OP betrifft, b e s t e h t aus
der D a r s t e l l u n g von OP in der Z w i s c h e n s p r a c h e ILl und einer M e n g e von Zusatzinformationen
in F o r m von B i t ~ K e n n u n g e n oder in Form einer der
O p e r a t i o n a n g e f H g t e n Liste.
Sp~ter h i n z u k o m m e n d e Eintr~ge,
die OP be-
.) F~r einige vom O p t i m i z e r n i c h t d u r c h g e f ~ h r t e O p t i m i e r u n g e n ist die u m g e k e h r t e R e i h e n f o l g e v o r t e i l h a f t ( z . B . f ~ r die S p e i c h e r p l a t z - O p t i mierung)
470
treffen, w e r d e n an der g l e i c h e n Stelle eingefGgt,
so dab die ILI-Dar-
stellung von OP nicht m e h r f a c h in e i n e m P r o t o k o l l auftritt. Ein Eintrag,
der eine V a r i a b l e X b e t r i f f t
dab ein S e i t e n e f f e k t auf X n o t i e r t wird), Bits in einem Bit-Vektor,
(es tritt nur der Fall ein, g e s c h i e h t d u r c h Setzen eines
in dem jeder im V o r m e r k b u c h b e s c h r i e b e n e n Va-
riablen eine B i t - P o s i t i o n entspricht. Mit Hilfe der z w e i g s p e z i f i s c h e n P r o t o k o l l i e r u n g w i r d die V e r f G g b a r k e i t der B e r e c h n u n g einer O p e r a t i o n OP an einer P r o g r a m m s t e l l e ST auch Gber V e r z w e i g u n g e n und Z u s a m m e n f G h r u n g e n h i n w e g erkannt,
sofern die B e r e c h -
n u n g s s t e l l e n von OP in der g l e i c h e n Schleife wie ST oder in einer Hberg e o r d n e t e n Schleife liegen oder d o r t h i n b e w e g t w e r d e n k~nnen°
In sofern
ist die P r o g r a m m - A n a l y s e mit Hilfe der z w e i g s p e z i f i s c h e n P r o t o k o l l i e r u n g ~ q u i v a l e n t zu dem mit B o o l e ' s c h e n G l e i c h u n g s s y s t e m e n a r b e i t e n d e n Algorithmus von Cocke
[I]
(s.a. E a r n e s t
[6]).
A l l e r d i n g s geht die V e r f G g b a r k e i t einer Berechnung,
deren B e r e c h n u n g s -
stelle im Inneren einer Schleife liegt und nicht h e r a u s g e z o g e n w e r d e n kann, an den A u s g ~ n g e n dieser S c h l e i f e verloren, weil sonst die V e r f G g b a r k e i t b e z G g l i c h der e i n z e l n e n A u s g ~ n g e der inneren Schleife g e t r e n n t n o t i e r t w e r d e n mGBte. Beispiel: A=
A+B ST: A+B Hier w i r d die V e r f ~ g b a r k e i t der B e r e c h n u n g von A+B an der Stelle ST nicht erkannt,
so dab der W e r t im 3. Knoten neu b e r e c h n e t w e r d e n muB.
Eine V e r w e n d u n g des B e r e c h n u n g s e r g e b n i s s e s
aus dem 2. Knoten w ~ r e im
~brigen nur dann sinnvoll, wenn der Wert von A+B dort ohnehin auf einer H i l f s z e l l e a b g e l e g t w i r d und n i c h t nur w e g e n der e i n m a l i g e n V e r w e n d b a r keit a u B e r h a l b der Schleife u.U. viele Male innerhalb der S c h l e i f e zugew i e s e n w e r d e n mHBte. Diese U n t e r s u c h u n g wird vom O p t i m i z e r nicht durchgefHhrt. Die M e t h o d e der z w e i g s p e z i f i s c h e n P r o t o k o l l i e r u n g b i e t e t g e g e n ~ b e r den mit B o o l e ' s c h e n G l e i c h u n g s s y s t e m e n a r b e i t e n d e n M e t h o d e n in der H a n d h a bung einige Vorteile: Line an einer P r o g r a m m s t e l l e v e r f ~ g b a r e B e r e c h n u n g r e p r ~ s e n t i e r t sich
471
selbst im Protokoll und sie wird nicht durch eine gewisse Bit-Position in einem langen Bit-Vektor repr~sentiert.
Dadurch erspart man sich eine
Tabelle, die die Beziehung zwischen jeder im Programm vorkommenden Operation und der zugeh~rigen Bit-~osition in diesem Bit-Vektor herstellt und die dauernd im Kernspeicher gehalten werden mHBte.
Solange eine Be-
rechnung nicht oder nicht mehr verfHgbar ist, ben6tigt sie im Protokoll keinen Speicherplatz.
Es ist auBerdem leicht m~glich,
direkt an den im
Protokoll aufgef0hrten Operationen die fur die Optimierung wichtigen Informationen anzubringen.
6. DURCHFUHRUNG DER OPTIMIERUNG IN OPTIMIERUNGSL~UFE, Die Optimierung eines Quellpro-
6.1AUFTEILUNG
gramms geschieht in zwei Phasen. Die erste Phase umfaBt a) die in § 4 beschriebenen Vorbereitungen
{Analyse der Pointer-,
kenvariablen-,
Prozedurvariablen-Stellungen,
rungsgebiete,
Analyse der Schleifenstruktur),
Mar-
Einteilung in Optimie-
b) fur alle Gebiete in der Reihenfolge ihrer Aufruf-Hierarchie von innen nach auBen: • vorl~ufige Feststellung der unbedingt oder des Programmierers)
(durch eine Erlaubnis
bedingt durchf~hrbaren Bewegungen von Berech-
nungen aus Schleifen heraus, • vorl~ufige Festste!lung der unbedingt oder bedingt durchf~hrbaren Reduktionen von Multiplikationen bzw. Feldelementberechnungen, c) Erstellung der Liste der an den Programmierer
zu richtenden Fragen.
Die unter b) genannte Untersuchung jedes Gebiets geschieht schleifenweise von den inneren Schleifen zu den du~eren: Per Code jeder Schleife wird in 3 direkt aufeinanderfolgenden
rungsl~ufen untersucht und das Untersuchungsergebnis fe abgelegt.
Optimie-
im SEB der Sch!ei-
Bei der Bearbeitung des SEB einer inneren Schleife ist dort
also bereits das Untersuchungsergebnis
der drei ersten Optimierungs-
l~ufe durch diese innere Schleife vermerkt. Die zweite Phase umfaBt a) fur alle Gebiete • DurchfHhrung der Bewegungen von Berechnungen aus Schleifen heraus unter BerOcksichtigung der vom Programmierer gegebenen Antworten,
472
• D u r c h f ~ h r u n g der R e d u k t i o n e n unter B e r H c k s i c h t i g u n g der vom Prog r a m m i e r e r g e g e b e n e n Antworten, • E e s e i t i g u n g r e d u n d a n t e r Berechnungen, b) Z u s a m m e n f ~ g e n des o p t i m i e r t e n Programmcodes,
~Jobei ggf. durch Um-
lenken von A b l a u f s p r ~ n g e n V o r b e r e c h n u n g s b l ~ c k e vet die S c h l e i f e n eing e s c h o b e n werden. Die u r s p r ~ n g l i c h e R e i h e n f o l g e des Q u e l l p r o g r a m m s bleibt dabei im w e s e n t l i c h e n erhalten. Die unter a) g e n a n n t e U n t e r s u c h u n g
jedes Gebiets g e s c h i e h t w i e d e r schlei-
fenweise und zwar von den du~eren zu den inneren Schleifen.
Jede Schlei-
fe wird dabei in e i n e m 4. Optimierungslauf behandelt.
6.2 DIE 4 0 P T I M I E R U N G S L i U F E , nen O p t i m i e r u n g s l ~ u f e ben wurde,
N a c h d e m in § 6.1 die E i n o r d n u n g der einzel-
in den g e s a m t e n A b l a u f der O p t i m i e r u n g b e s c h r i e -
folgt eine F u n k t i o n s b e s c h r e i b u n g der 4 L~ufe durch eine Schlei-
fe S. In den L~ufen
1,3 und 4 wird ein P r o t o k o l l zweigspezifisch,
b e i m Kopf
von S beginnend, von I L l - o p e r a t i o n zu I L l - O p e r a t i o n bzw. vom Ende eines Blocks
(Basisblock oder SEB einer inneren Schleife)
Nachfolger-Blocks
transformiert.
zum A n f a n g eines
B e i m 2. Lauf gen~gt ein linearer D u r c h -
gang durch den Code der Schleife. Der SEB einer inneren Schleife wird im w e s e n t l i c h e n genauso g e h a n d e l t wie ein Basisblock: Die darin stehenden I L 1 - O p e r a t i o n e n w e r d e n als a u f t r e t e n d e B e r e c h n u n g e n behandelt.
Bei
(dutch eine E r l a u b n i s des PrQgrammierers)
b e d i n g t einge-
tragenen O p e r a t i o n e n wird zus~tzlich eine S o n d e r b e h a n d l u n g durchgef~hrt. S e i t e n e f f e k t e treten nicht auf, weil ILI-Operatienen, haben
(Zuweisungen, F u n k t i o n s - oder Prozeduraufrufe,
die S e i t e n e f f e k t e E/A-Anweisungen),
nicht b e w e g t werden. im A n s c h l u B an die B e h a n d l u n g der im SEB e i n g e t r a g e n e n I L 1 - © p e r a t i o n e n w i r d der D u r c h g a n g durch die innere Schleife simuliert, ihr a u f t r e t e n d e n S e i t e n e f f e k t e
(die ebenfalls
indem die in
im SEB n o t i e r t sind)
be-
r H c k s i c h t i g t werden. Ein S e i t e n e f f e k t auf eine B A S E D - G r e B e P-->B gilt stets als S e i t e n e f f e k t auf alle
"realen" Variablen,
die sich bei den v e r s c h i e d e n e n im P r o g r a m m
v o r k o m m e n d e n E i n s t e ! l u n g e n des Pointers P hinter B v e r b e r g e n kSnnen. Eine V e r w e n d u n g von P-->B als Operand einer O p e r a t i o n gilt als V e r w e n dung jener rea!en Variablen. B e r e i c h s e l e m e n t A(I) die Bereichsvariable)
Der S e i t e n e f f e k t einer Zuweisung zu einem
gilt als S e i t e n e f f e k t auf den ganzen B e r e i c h
(d.h.
A. A d r e B b e r e c h n u n g e n treten in der ILI-Fassung
473
des Q u e l l p r o g r a m m s als eigene I L 1 - © p e r a t i o n e n auf, ihre V e r f ~ g b a r k e i t geht bei einer i n d i r e k t e n Z u w e i s u n g Hber sie nicht verloren.
1. Lauf Das P r o t o k o l l enth~it an einer a k t u e l l e n Stelle innerhalb S: alle b i s h e r
(d.h. zwischen S c h l e i f e n k o p f und a k t u e l l e r Stelle)
in S
aufgetretenen Seiteneffekte alle bisher a u f g e t r e n e n Operationen,
deren B e r e c h n u n g an der aktu-
ellen Stelle dann v e r f ~ g b a r ist, w e n n man annimmt
(im folgenden wird
diese Annahme mit (V) bezeichnet), dab vor dem S c h l e i f e n k o p f alle B e r e c h n u n g e n v e r f ~ g b a r sind alle bisher a u f g e t r e n e n Inkrementierungen oder I='Ausdruck'
der Art I=I±'Ausdruck'
+ I, wobei auf keinen O p e r a n d e n des
'Ausdrucks'
bisher ein S e i t e n e f f e k t v o r k a m und I eine bisher nur durch Inkrementierungen ver~nderte BINARY FIXED-Variable Beim
ist.
A u f t r e t e n eines S e i t e n e f f e k t s w e r d e n die Operationen,
r e c h n u n g nun nicht m e h r unter der A n n a h m e P r o t o k e l l gel~scht, alisiert.
deren Be-
(V) v e r f H g b a r ist, aus dem
ebenso wird die M e n g e der I n k r e m e n t i e r u n g e n aktu-
Neu b e r e c h n e t e O p e r a t i o n e n w e r d e n ins Protokoll aufgenommen.
Bei einer Z u s a m m e n f ~ h r u n g w i r d in das S y n t h e s e - P r o t o k o l l als Seitene f f e k t - M e n g e die V e r e i n i g u n g der S e i t e n e f f e k t - M e n g e n der V o r g ~ n g e r P r o t o k o l l e eingetragen.
Eine O p e r a t i o n OP wird aus einem V o r g ~ n g e r -
P r o t o k o l l dann in das S y n t h e s e - P r o t o k o l l Hbernommen, g~nger-Protekollen,
wenn in jenen Vor-
in denen OP nicht e n t h a l t e n ist, auf keinen 0pe-
r a n d e n yon OP ein S e i t e n e f f e k t e i n g e t r a g e n ist. Auf diese Weise stehen im S y n t h e s e - P r o t o k o l l w i e d e r die Operationen, der A n n a h m e
deren B e r e c h n u n g unter
(V) nach der Z u s a m m e n f 0 h r u n g v e r f H g b a r ist. Aus den V o r -
g ~ n g e r - P r o t o k o l l e n werden d i e j e n i g e n der Z u s a m m e n f O h r u n g
Inkrementierungen
Inkrementierungen,
die auch nach
im obigen Sinne sind,
in das Syn-
t h e s e - P r o t o k o l l Hbernommen. Am Ende des I. Laufs durch S stehen also im
(SchluB-)Protokoll zur V e r -
fHgung: alle S e i t e n e f f e k t e yon S, alle Operationen, Annahme
d e r e n B e r e c h n u n g auf dem S c h l e i f e n r H c k w e g unter der
(V) v e r f H g b a r ist,
alle I n k r e m e n t i e r u n g e n .
474
~. Lauf A n h a n d der e r k a n n t e n I n k r e m e n t i e r u n g e n w e r d e n in einem linearen D u r c h gang durch S alle ILI-Operationen, den kann,
f~r die R e d u k t i o n d u r c h g e f ~ h r t w e r -
e r m i t t e l t und die fur die R e d u k t i o n n~tigen V o r b e r e c h n u n g e n
dem S c h l u B p r o t o k o l l des I. Laufs angef~gt.
3. Lauf Im 3. Lauf d u r c h S w i r d untersucht, I. Lauf ermittelten)
ob sich die H e r a u s z i e h u n g der
auf dem S c h l e i f e n r H c k w e g unter der A n n a h m e
fHgbaren B e r e c h n u n g e n lohnt und w e l c h e F r a g e n ggf.
(im
(V) ver-
zu stellen sind.
Ebenso w e r d e n den im 2. Lauf e r k a n n t e n m ~ g l i c h e n R e d u k t i o n e n ggf. F r a g e n zugeordnet. Die H e r a u s z i e h u n g der B e r e c h n u n g einer O p e r a t i o n OP lohnt sich ohne Frage dann, w e n n auf a l l e n W e g e n d u r c h S e i n e
B e r e c h n u n g s s t e l l e von OP
liegt und an jeder dieser Stellen die h e r a u s g e z o g e n e B e r e c h n u n g noch v e r f U g b a r ist. Die H e r a u s z i e h u n g lohnt sich auf keinen Fall, w e n n auf allen W e g e n durch S noch vor der e r s t e n B e r e c h n u n g s s t e l l e von OP ein S e i t e n e f f e k t auf einen O p e r a n d e n von OP auftritt. Eine Frage b e z ~ g l i c h der H e r a u s z i e h u n g muB g e s t e l l t werden, w e n n die B e r e c h n u n g vielleicht
v e r w e n d e t w e r d e n kann. Dies kann z.B. geschehen,
wenn es Wege gibt, die d i r e k t zu e i n e m A u s g a n g aus S fOhren oder w e n n eine B e r e c h n u n g s s t e l l e von OP in einem SEB liegt, in dem die B e r e c h n u n g nur b e d i n g t e i n g e t r a g e n ist. B e z ~ g l i c h einer m ~ g l i c h e n R e d ~ k t i o n w i r d immer eine Frage gestellt, auBer in dem Fall, dab die r e d u z i e r b a r e O p e r a t i o n in einer D O - S c h l e i f e liegt und bei jedem S c h l e i f e n - D u r c h l a u f p a s s i e r t wird. Die U n t e r s u c h u n g des 3. Laufs g e s c h i e h t in einem z w e i g s p e z i f i s c h gefHhrten Protokoll,
in dem fur jede im S c h i u B - P r o t o k o l l des I. Laufs
e i n g e t r a g e n e O p e r a t i o n OP ein B i t - V e k t o r t r a n s f o r m i e r t wird, der an einer a k t u e l l e n Stelle die A n t w o r t auf folgende F r a g e n gibt: Ist die B e r e c h n u n g von OP v e r f H g b a r ? Gibt es einen Weg vom Kopf zur a k t u e l l e n Stelle, auf dem die B e r e c h nung von OP stets v e r f H g b a r ist aber nie v e r w e n d e t w e r d e n kann? Gibt es einen Weg zur a k t u e l l e n Stelle,
auf dem die am E i n g a n g ver-
fHgbare B e r e c h n u n g von OP v e r w e n d e t w e r d e n kann? Kann die am E i n g a n g v e r f ~ g b a r e B e r e c h n u n g auf allen W e g e n zur aktuellen Stelle v e r w e n d e t werden?
475
Bei der B e h a n d l u n g e i n e r O p e r a t i o n im SEB einer inneren Schleife, die an eine F r a g e g e k n ~ p f t ist, w i r d untersucht, der F r a g e er~brigt,
ob sich die B e a n t w o r t u n g
etwa w e i l eine aus der inneren S c h l e i f e h e r a u s z i e h -
bare B e r e c h n u n g o h n e h i n von auBen her v e r f ~ g b a r ist. die F r a g e als b e r e i t s m i t
in d i e s e m Fall w i r d
"ja" b e a n t w o r t e t notiert. W e n n es u n m 6 g l i c h
ist, im Q u e l l p r o g r a m m vor der inneren S c h l e i f e e i n ~ V o r b e r e c h n u n g s b l o c k einzuf~gen,
w e r d e n alle Fragen mit
"nein" beantwortet.
A n h a n d des S c h l u B - P r o t o k o l l s dieses Laufs d u r c h S w e r d e n nun im Schlu8P r o t o k o l l des I. Laufs die O p e r a t i o n e n , lohnt, gestrichen.
deren H e r a u s z i e h u n g sich n i c h t
Die ~ b r i g b l e i b e n d e n O p e r a t i o n e n und die M e n g e der
S e i t e n e f f e k t e w e r d e n in den SEB von S eingetragen,
wobei den O p e r a t i o -
nen die ggf~ n o t w e n d i g e n F r a g e n a n g e f ~ g t werdem.
4. Lauf Zu Beginn des 4. Laufs liegen die an den P r o g r a m m i e r e r g e r i c h t e t e n Fra~en b e a n t w o r t e t vor. Vor der B e h a n d l u n g yon S wurde bereits die S umfassende Schleife
(und damit der SEB von S) im 4. Lauf behandelt.
SEB wurde dabei f o l g e n d e r m a S e n modifiziert:
Der
Eine dort "bedingt" ein-
g e t r a g e n e O p e r a t i o n OP wurde auf "unbedingt" gesetzt, w e n n die zugeh6rige Frage mit
"ja" b e a n t w o r t e t w u r d e oder w e n n die B e r e c h n u n g von
OP vor dem SEB v e r f ~ g b a r war. A n d e r e n f a l l s w u r d e OP aus dem SEB entfernt. Der SEB enth~it nun jene Operationen,
die sp~ter in einem V o r -
b e r e c h n u n g s b l o c k vor den E i n g a n g von S ins Q u e l l p r o g r a m m e i n g e f O g t w e r den
(wenn dies d u r c h U m l e n k e n yon S p r O n g e n m ~ g l i c h ist) .
In das P r o t o k o l l f~r den z w e i g s p e z i f i s c h e n D u r c h g a n g d u r c h S w e r d e n als I n i t i a l i s i e r u n g diese O p e r a t i o n e n eingetragen. An einer a k t u e l l e n Stelle in S e n t h ~ i t das P r o t o k o l l alle O p e r a t i o n e n ,
deren B e r e c h n u n g
v e r f ~ g b a r ist zusammen m i t der Liste ihrer E r s t - B e r e c h n u n g s s t e l l e n . Bei einer Z u s a m m e n f ~ h r u n g w i r d in das S y n t h e s e - P r o t o k o i l der D u r c h schnitt der in den V o r g ~ n g e r - P r o t o k o l l e n e i n g e t r a g e n e n O p e r a t i o n e n ~bernommen, die E r s t - B e r e c h n u n g s s t e l l e n einer ~ b e r n o m m e n e n O p e r a t i o n w e r den aus den V o r g ~ n g e r - P r o t o k o l l e n vereinigt°
T r i t t eine B e r e c h n u n g ei-
ner b e r e i t s im P r o t o k o l l s t e h e n d e n O p e r a t i o n OP auf,
so w i r d an den
E r s t - B e r e c h n u n g s s t e l l e n von OP eine H i l f s z e l l e n - Z u w e i s u n g des B e r e c h n u n g s e r g e b n i s s e s e i n g e f ~ g t und die B e r e c h n u n g an der a k t u e l l e n Stelle durch eine V e r w e n d u n g d i e s e r H i l f s z e l l e ersetzt. Einer O p e r a t i o n OP wird dabei stets eine und d i e s e l b e H i l f s z e l l e
zugeteilt.
Die B e r e c h n u n g einer r e d u z i e r b a r e n O p e r a t i o n wird ebenfalls d u r c h eine H i l f s z e l l e n - V e r w e n d u n g ersetzt, wobei diese H i l f s z e l l e
jeweils hinter
den z u g e h ~ r i g e n I n k r e m e n t i e r u n g s s t e l l e n um das Inkrement w e i t e r g e s c h a l tet wird.
476
Die E i n t r ~ g e des SEB einer inneren Schleife e r f a h r e n die S o n d e r b e h a n d lung, wie sie oben fHr den D u r c h l a u f durch die S u m f a s s e n d e S c h l e i f e b e s c h r i e b e n wurde. Eine nach dieser S o n d e r b e h a n d l u n g H b r i g b l e i b e n d e B e r e c h n u n g bleibt auch Hber den SEB verfHgbar,
(und die innere Schleife)
hinweg
falls in der inneren Schleife kein S e i t e n e f f e k t auf einen
ihrer O p e r a n d e n vorkommt.
Literatur Zur O p t i m i e r u n g I. S I G P L A N - N o t i c e s Vol.
5 No.
7
(1970)
insbes.: Allen, F.E., Control Flow Analysis,
pp.
I - 19
Cocke, J., Global S u b e x p r e s s i o n Elimination,
pp. 20 - 24
2. Gries, D., C o m p i l e r C o n s t r u c t i o n for D i g i t a l Computers, insbes.: pp. 375 ff 3. Allen, F.E., P r o g r a m Optimization, A n n u a l Review in A u t o m a t i c Programming, Vol.5
(1969) pp. 239 - 307
4. C o u r a n t C o m p u t e r Science S y m p o s i u m 5 (1972), Design and O p t i m i z a t i o n of C o m p i l e r s insbes.: Allen, Cocke, G o l d b e r g 5. Kildall, C.A., Global E x p r e s s i o n O p t i m i z a t i o n During Compilation, Diss. 6. Earnest,
1972, Univ.
C., Some Topics in Code Optimization, JACM Vol.
7. Ullmann,
of W a s h i n g t o n
21, No.
I (1974) pp.
J.D., F a s t A l g o r i t h m s
76 - 102
for the E l i m i n a t i o n of C o m m o n
Subexpressions, Acta I n f o r m a t i c a Vol.
2, No.
3 (1973) pp.
191 - 213
8. Busam, V.A., Eglund, D.E., O p t i m i z a t i o n of E x p r e s s i o n s CACM, Vol.
12, NO.
12
in FORTRAN,
(1969) pp. 666 - 674
Zur G r a p h e n t h e o r i e : 9. Tiernan,
J.C., An E f f i c i e n t Search A l g o r i t h m to Find the E l e m e n t a r y C i r c u i t s of a Graph, CACM, Vol.
13, No.
12
(1970) pp. 722 - 726
10. Sachs, H., E i n f H h r u n g in die Theorie der e n d l i c h e n G r a p h e n Hanser, M H n c h e n 1970
477
Zur Zwischensprache ILl: 11. Werum, W., Vorl~ufige Beschreibung der Zwischensprache ILl, Gesellschaft f~r Kernforschung, PDV-Entwicklungsnotizen, PDV-E 16, Dezember 1973
ABLAUF-KONTROLLSTRUKTUREN
FOR PROZESSRECHNER-BETRIEBSORGANISATIONEN
J~rgen Nehmer
1. Einleitun~ Die sehnelle Verbreitung kleiner his mittelgro~er DV-Anlagen in allen Bereichen der ProzeSautomation, Leistungsverh~itnis
die auf das sehnell fallende Preis-
in den letzten Jahren zurNekzufNhren ist, hat
zu einer kaum Nbersehbaren Konzeptvielfalt
bei den ProgrammausrN-
stungen dieser Rechner gef~hrt. Die bei konventioneller Datenverarbeitung s~tze einer Standardisierung
Proze~rechnern bisher nicht durchgesetzt. gro~en Variationsbreite
deutlich erkennbaren An-
der Betriebsorganisation
haben sich bei
Der Grund dafNr ist in der
sowohl des Aufgabenspektrums
als auch der fNr
deren L~sung eingesetzten Rechnertypen und -ausrNstungen zu suchen
13-8I. So m~ssen z.B. bei der Laborautomatisierung perimente oft mittlere Daten-Ankunftsraten beitet werden, die Reaktionszeiten
kernphysikalischer Exyon 10 KHz und mehr verar-
< 100 ~sec erfordern.
DNC-Steuerungen fNr numerische Werkzeugmaschinen verlangen Reaktionszeiten im Millisekundenbereich mittels SPC-Technik
und verfahrenstechnische
(= Super-Visory Control)
Prozesse,
gesteuert werden, weisen
nur noch mittlere Reaktionszeiten im Sekunden-Minuten-Bereich Im Bereich der Fertigungssteuerung (z.B. Produktkontrolle)
auf.
und Automation yon PrNffeldern
werden in der Regel die geringsten AnsprNche
an das Reaktionszeitverhalten Taktvorgabe
die
yon Proze~rechensystemen
gestellt.
erfolgt hier meist durch den Rechner und orientiert
ausschlie~lich an den vergleichsweise
Die sich
tr~gen mechanischen Abl~ufen
der zu steuernden Proze~hardware. In ~hnlicher Weise, wie die Anforderungen an das Reaktionszeitverhalten schwanken, werden yon den typischen Proze~rechner-Anwendungen unterschiedliche
AnsprNche an den Bedienungskomfort
des Erstellungs-
systems gestellt. Bei technischen Prozessen mit extrem hohen Datenraten wird oft aus GrNnden der geforderten Reaktionszeiten in Form yon Betriebssystemen
auf jede BasisunterstNtzung
oder h6heren Programmierspraehen
ver-
481
zichtet.
Der Anwender benutzt
Assembler und erstellt system einschlie~lich hoffentlich Anders
relativ
als Konstruktionswerkzeug
der ben~tigten
ist die Situation
auf, f~r die entweder
Sprachen geschaffen
Experimentierbetrieb
nicht
hohe ~nderungsh~ufigkeit haftesten
'fill in the blanks'-
/15].
werden
zur~ckgegriffen
der durchzuf~hrenden
immer wieder
spezielle pro-
werden /14/, oder verallgemeiner-
die z.B. durch
parametergesteuert
Im rechnergest~tzten Charakter
(das
in der Verfahrenstechnik
Hier treten grunds~tzlich
te Anwendungsprogramm-Pakete,
Standardfunktionen
Betriebssystemfunktionen
bei DDC-Steuerungen
die gleichen Problemstellungen
Formbl~tter
den
Programm-
selten ge~ndert werden mu~).
oder der Pr~ffeldautomation. blemorientierte
lediglich
in eigener Regie ein zugeschnittenes
kann im allgemeinen werden.
Der experimentelle
Automatisierungsaufgaben
der Anwenderprogramme,
in einer h~heren Programmiersprache
auf
bedingt
eine
die daher am vorteilwie z.B. PEARL /16/ for-
muliert werden. W~nschenswert
w~re eine einheitliche
samte Spektrum skizzierter derten - in Komfort,
Proze~rechnersoftware
Flexibilit~t,
gierenden Erstellungsverfahren, fischer Betriebsziele
zu versto~en
/13/. Eine derartige
h~heren Programmiersprache, garantiert,
die Kontrolle
durch den schwachen Durchgriff aber gew~hnlich
struktionsmethode einiger weniger,
Ansatz
Konflikt-
die zwar einen guten BeFunktionen
universell
einer einheitlichen geht v o n d e r
einsetzbarer
seiner speziellen
f~r die Klassifizierung
nismen der Ablaufkontrolle. hier die Regeln gemeint, Rechner erfolgt.
Kon-
Existenz
Grundtypen
Software
f~r
gew~hren
Unter einer Ablaufkontrollstruktur
nach denen die Abarbeitung
Programmes
/12/.
von Betriebsorganisa-
sich eine Einteilung nach den unterschiedlichen
zusammenh~ngenden
des Be-
aus, die dem Anwender einen gro~en Bewegungs-
spielraum bei der Einbettung AIs Ordnungskriterium
einer
des Reaktionszeitverhaltens
auf ablaufsteuernde
zur Entwicklung
weitgehend
ge-
ausschlie~t.
f~r Proze~rechnersoftware
Betriebsorganisationen
tionen eignet
anwendungsspezi-
des Reaktionszeitverhaltens
z.B. in vielen F~llen durch die Benutzung
dienungskomfort
Der hier verfolgte
der geschilstark diver-
ohne gegen die aufgef~hrten
konventionellen
triebssystems
f~r das ge-
anstelle
und Aufwand
die die Realisierung
unterst~tzt,
nerellen Design-Kriterien entsteht
Mobilit~t
- wie z.B. Kontrolle
oder Speicheroptimierung situation
Konstruktionsmethode
bzw. von unabh~ngigen
Mechasind
entweder
eines
Programmen
im
482
FUr Betriebsorganisationen Klassifizierung
von ProzeSrechnern
naheliegend,
ordinierung von Abl~ufen des technischen entsprechende
Programmst~cke
zeigen auch Beispiele trollstrukturen
Grundtypen
archisch gegliederte
in der Ko-
DV-Anlagen,
die durch
sind. Daneben
daS die Ablaufkon-
Weise die funktionelle
Zergliederung
bestimmen.
Nach einer Diskussion besonders den dargestellten
Aufgabe
Prozesses besteht,
im Rechner repr~sentiert
konventioneller
in dominierender
eines Betriebssystems
ist eine derartige
da ihre grundlegende
h~ufig auftretender
der Ablaufkontrolle
Betriebsorganisation
Satz von 'Elementarfunktionen
Kombinationen
aus
wird f~r eine hier-
mit ProzeS-Struktur
der Ablaufsteuerung'
ein
beispielhaft
ange-
geben und seine Anwendung demonstriert. AbschlieSend
wird ~ber einige Erfahrungen
befindlichen
Produktionssystem
das eine dem Anwender funktionen
mit einem in der Erprobung
f~r den Kleinrechner
zug~ngliche
$320 berichtet,
Bibliothek mit allgemeinen
f~r eine Betriebsorganisation
System-
des oben skizzierten Typs ent-
h~!t. 2. Grundtypen
der Ablaufkontrolle
Die nachfolgend
anhand der Abb.1 erl~uterten
Grundtypen
der Ablaufkon-
trolle st~tzen sich auf die von Gray u.a. in /2/ eingef~hrte tik, die unter Ber~cksichtigung feinert wurde.
Eisen~esteuerte
Eigensteuerung
Systeme
oder Fremdsteuerung
des Systems besorgt wird, der nicht yon Vorg~ngen beeinflu~t
f~hrung durch die Hardware eingesetzt
werden,
werden kann
steuerung k~nnen unterschieden
werden, deren Aus-
Sie k~nnen ~berall dort
Tabelle
erf~llt.
so-
Vier Formen der Eigen-
werden: Jeder Eintrag einer
enth~it dabei Spezifikationen
Programmschritt
!auf einer vorgegebenen
auf externe Er-
aber auch bei Fertigungssteuerungen
Form ist die Tabellensteuerung.
festformatierten
sol-
Proze~ reagieren mu~. Diese Voraussetzungen
wie im Bereich der Pr~ffeldautomation
zuf~hrenden
verstanden
gesteuert wird).
sind oft bei DDC-Steuerungen,
Die einfachste
au~erhalb
(unter Progra~mschritten
wo der Rechner nicht schritthaltend
im technischen
grob
unterscheiden.
zum n~chsten durch einen internen Me-
len hier keine Maschineninstruktionen
eignisse
zun~chst
ver-
zeichnen sich dadurch aus, da~ die Fortschal-
tung von einem Programmschritt des Rechensystems
Systema-
an Proze~rechner
Darin lassen sich alle Kontrollstrukturen
nach den Merkmalen:
chanismus
der Anforderungen
und ggf. einen Verweis
Verz~gerungszeit
~ber den durch-
auf den - n a c h
- als n~chstes
Ab-
zu bearbei-
483
Ablaufkontrollstrukturen j
Eigensteuerung
f
l
Fremdst euerung (F)
(E)
/
dutch generelle Synchronisationsmechanismen (S)
interpretativ tabellengesteuert (TAB)
unterbrechungsgesteuert (I)
dur ch Prozeduraufrufe ( PROC ) d u r e h Semaphore (SEN)
dureh Events dureh (EV) Messages
(MES)
Abb. 1
Grundtypen der Ablaufkontrolle
in Rechnersystemen
I
I
Mn
F--% 0
I
Mn- 1
I
40
b~O
40
I
~D
}
I
III
I
!
I ~0
©
M 2 "4 40 ®
M i
I....
II
M 0
Abb. 2 Treppenf6rmige
IV--}--
I
Hardware
Schnittstelle
1
zwischen Anwendersoftware
Betriebssystem bei einer Schichtenstruktur
und
des Betriebssystems.
484
tenden Tabelleneintrag. tiell
(zyklisch)
Im Regelfall wird die Tabelle
abgearbeitet,
durch einen Algorithmus
jedoch sequen-
die Abarbeitungssequenz
erfolgen,
der iterativ
kann aber auch
einen Tabellenindex
berechnet. Tabellengesteuerte
Systeme,
geschnitten werden, tionsaufgaben
lassen sich z.B. vorteilhaft
einsetzen
rend realisiert Interpretativ
die immer auf eine spezielle
tiven Sprachen,
Systeme
stellen die allgemeinste
die gew~nschten
Systeme
Die Programme
analysiert,
spezifische
Sie basieren
werden zeilenweise
Aktionen
zerlegbare
dutch einen Intereiner Zerlegung
ausl~st.
Sprachen werden im Bereich der proze~automation
Anwendungen
zeichnen
eingesetzt
(z.B.
Pr~fsprachen)
Bei der Codef~delun~
interpretativer
des Interpretierers,
code) handelt
tritt hier eine Pre-Compilationsphase,
zeilenweise
Die Sprungadressen
Aktionsprogramme,
eine
weisen
die ~blicherweise
gestartet werden und m~t einem Sprungbefehl
an die n~chste Adresse des Objektprogrammes tionsprogramme
Anstelle
analysiert,
in der aus dem Quellcode
generiert wird.
auf den Anfang der jeweiligen durch den Interpretierer
aus.
es sich um eine Misch-
und operativer Arbeitsweise.
der den Programmcode
Folge yon Sprungbefehlen
arbeitenden Systemen -
aber geringe Laufzeiteffizienz
(threaded
f~r
und sind daher
Die nach diesem Prinzip
sich - ~hnlich den tabellengesteuerten
durch hohe Speichereffizienz,
befehlsfolge
Klasse un-
auf interpreta-
schnell
der aufgrund des Ergebnisses
stark problembezogen.
form zwischen
dar.
die in der Regel eine einfache,
Syntax aufweisen.
gew~hnlich
und kostenspa-
werden.
arbeitende
Interpretative
zu-
f~r Daten-Akqu±s±-
/~I und k~nnen sehr speicher-
ter den Systemen mit Eigensteuerung
pretierer
Anwendung
des Interpretierers
des Objektprogrammes,
beendet werden.
Die Ak-
werden demnach durch die Sprungdie s i n n g e m ~
den
'Faden' bildet,
aneinandergekettet.
Bell /II spricht treffend von einer interpretati-
yen Ablaufkontrolle
ohne Interpretierer
sem Prinzip aufgebaute interpretativem Arbeitsweise
und weist nach, da~ nach die-
Systeme die Vorteile
der Speichereffizienz
Betrieb mit dem der Laufzeiteffizienz
bei
bei operativer
in sich vereinigen.
Die allgemein bekannte
Unterprosrammtechnik
rie unter den Eigensteuerungen vorher besprochenen
Technik der Codef~delung
werden durch Unterprogramme aneinandergereiht.
bildet die letzte Katego-
und stellt eine Verallgemeinerung
realisiert
der
dar. Programmschritte
und durch Unterprogrammspr~nge
Sie werden in der Regel hardwareunterst~tzt
und
485
k~nnen von Parameter~bertragungen Die vier besprochenen ben gemeinsam~
begleitet
Ablaufkontrollstrukturen
dad die zu steuernden
festgelegten,
sein. f~r Eigensteuerung
Programmschritte
durch das jeweilige Verfahren bestimmten
zum Ablauf gebracht werden. steuerung unterworfenes sequentieller
Ein ausschlie~lich
Programmsystem
Proze~ innerhalb
Reihenfolge
den Regeln der Eigen-
kann deshalb
des Rechner$
ha-
in einer vorher
immer als ein
betrachtet
werden
(Ein-
Proze~-System). Diese Voraussetzung Sie sind dadurch
gilt bei fremdgesteuerten
charakterisiert,
einer rechnerinternen erfolgt.
Aktionen
unabh~ngige
Systemen nicht mehr.
da~ der Ansto~ zur Durchf~hrung
Aktion durch ein asynchrones,
sind daher selbst asynchron
sequentielle
laufkontrollstrukturen
Prozesse
dar (Multi-Proze~-System).
f~r fremdgesteuerte
Systeme
Regeln fest, nach denen zwischen unabh~ngigen rechner-externer
Steuersignale
externes
umgeschaltet
Signal
zueinander und stellen Die Ab-
legen daher die
Prozessen
als Folge
wird.
Jeder Proze~ kann dabei intern dutch eine der vier oben angegebenen Grundtypen
der Eigensteuerung
Aus dem Vorhergesagten gensteuerung
kann unmittelbar
als Spezialfall
die damit die allgemeinere In der Systematik tersehieden:
realisiert
werden. gefolgert
werden,
in Multi-Proze~-Systemen
Betriebsorganisationsform
dab die Ei-
enthalten
ist,
darstellen.
der Abb.1 werden zwei Typen der Fremdsteuerung
dureh Unterbreehungen
und durch generelle
un-
Synchronisa-
tionsmechanismen. Ausschlie~lich sentlichen
unterbrechungsgesteuerte
auf die Reehnerhardware.
Unterbrechungssignale
aktiviert.
Unterbrechungsprozesse
prozesses
zwischen ihnen zu erreichen,
ausgestattet.
h~herer Priorit~t
unterbrochenen
Sie werden deshalb nachfolgend
oft mit priorit~tsgestaffelten
Multiregisters~tzen
st~tzen sich im weals
bezeichnet.
Um eine schnelle Umschaltung Proze~rechner
Systeme
Prozesse werden dort direkt durch
werden
Unterbrechungswerken
Die Aktivierung
und
eines Unterbrechungs-
sowie die Rettung der Registerst~nde
Prozesses werden dort per Hardware
eine Reduzierung
der Umschaltzeiten
Die allgemeinere
Form der Fremdsteuerung
Synehronisationsmeehanismen, siert sind. Sie unterscheiden
durchgef~hrt,
des die
auf ~0 ~sec und weniger bewirkt. st~tzt
die gewShnlich sich v o n d e r
steuerung dutch h~here Leistungsf~higkeit
sich auf generelle
nicht per Hardware
reali-
reinen Unterbrechungs(z.B. die F~higkeit
mit dem
486
Synchronisationsimpuls
eine beliebige
Zahl von Parametern
gen und dgl.) und kSnnen auch von den Prozessen re Betriebssystemfunktionen Eine EinfluSnahme des Rechners
(primitives)
selbst Nber elementa-
benutzt werden.
auf die Synchronisationsmechanismen
erzeugte
Signale erfordert
zu Nbertra-
dutch auSerhalb
die Zwischenschaltung
yon
Interruptprozessen. In gegenw~rtig
existierenden
sationsmechanismen
Betriebssystemen
werden drei Synchroni-
unterschieden:
- durch Semaphore, - durch Events, -
durch Botschaften
Gemeinsamer operationen,
(messages).
Kern aller drei Synchronisationsmechanismen
sind Grund-
die den Weft yon Synchronisationsvariablen
nach vorge-
gebenen Regeln ver~ndern und die Realisierung
bedingter Wartezust~nde
yon Prozessen unterst~tzen. W~hrend Dijkstra's
Semaphoreoperationen
tenzugriffssynchronisation sagesynchronisationen
eingesetzt
vorwiegend
werden,
der Kommunikation
f0r Zwecke der Da-
dienen Event- und Mes-
zwischen mehreren Prozessen
sowie zwischen Prozessen und der externen Umgebung des Rechensystems. Eine breitere EinfNhrung konzepte,
in die unterschiedlichen
auf die hier aus Platzgr~nden
Synchronisations-
verzichtet
werden muS, wird
in /17/ gegeben. Multi-ProzeS-Systeme
mit einer
Synchronisationsmechanismen
(oder mehreren)
der oben angegebenen
weisen die allgemeinste
struktur auf und werden dort effektiv eingesetzt, Ereignisse
im technischen
ProzeS schritthaltend
Dies ist oft in komplexen verfahrenstechnischen in denen eine groSe Zahl yon selbst~ndig gebern installiert Rechners
Im vorhergehenden unabh~ngige
Prozessen
reagierenden
der Fall,
Grenzwertdes
sind.
von Grundtypen
der Ablaufsteuerun$
Kapitel wurde bereits
darauf hingewiesen,
Proze~ in Multi-Proze~-Systemen
gestellten
Konzepte
strukturen
der Eigensteuerung
!~ufig enthalten.
wo auf asynchrone
reagiert werden muS.
ist, die direkt auf die Unterbrechungseing~nge
geschaltet
3. Kombinationen
Ablaufkontroll-
der Eigensteuerung
da~ jeder
intern einem der vier vor-
unterliegt,
d.h. Ablaufkontroll-
sind in Multi-ProzeS-Systemen
zwangs-
487
Dar~ber hinaus lassen sich Multi-ProzeR-Systeme mit Unterbrechungssteuerung (Fi-Systeme, vgl. Abb. 1) und Steuerung durch generelle Synchronisationsmechanismen System kombinieren.
(FS-Systeme)
zu einem universellen FIS-
Unterstellt man, dab die drei eingef~hrten Syn-
chron±sationsmechanismen wahlweise in einem derartigen System zur Verf~gung stehen, so k~nnen alle in Abb. 1 definierten Grundtypen der Ablaufkontrolle in einem System vereinigt werden, das sich damit weitgehend invariant gegen~ber den aufgez~hlten Anwendungen verh~it. Die proze~-interne Organisationsform kann dabei durchaus yon Proze2 zu Proze~ innerhalb der verschiedenen Grundtypen der Eigensteuerung variieren. Man findet diese kombinierte Ablaufkontrollstruktur, gangspunkt einer Standard-Betriebsorganisation
die hier als Aus-
gew~hlt wird~ ansatz-
weise in vielen gegenw~rtig existierenden Betriebssystemen.
Die Be-
triebsorganisation zerf~llt dort in der Regel in zwei klar voneinander trennbare Komponenten, den Nukleus und die Schale. W~hrend im Nukleus, der gew~hnlich privile$iert ist, alle Unterbrechungsprozesse
ablaufen,
wird die Schale aus einer ~blicherweise nicht festgelegten Zahl von kooperierenden Prozessen gebildet. Dem Nukleus f~llt dabei einerseits die Rolle des Bindeglieds zwischen der Au2enwelt des Rechners und dessen internen Abl~ufen zu (indem er z.B. externe Ereignisse in Synchronisationsoperationen transformiert), andererseits enth~It er die Grundfunktionen, die zur Existenz yon Prozessen der Schale notwendig sind. Drei signifikante Varianten dieser allgemeinen Betriebsorganisation k~nnen unterschieden werden: (a) harmonisch kooperierende Prozesse: Al!e Prozesse der Schale sind gieichberechtigt.
Auftr~ge zwischen
Prozessen werden kooperativ unter Zuhi!fenahme der existierenden Synchronisationsmechanismen
abgewickelt
(die im Nukleus realisiert
sind). Ein Nachteil dieser Variante ist die relativ hohe Gefahr der Entstehung yon Deadlocks dutch die Ausbildung zyklischer Auftragsverkettungen. (b) nicht kooperierende Prozesse: Alle Prozesse der Schale sind gleichberechtigt, voneinander.
aber unabh~ngig
Auftragsbeziehungen werden als Bestandteil ein und
desselben Prozesses ~ber Prozeduraufrufe zwischen Anwendungs- und Betriebssystemprogrammen
abgewickelt
werden in diesem Fall z w e c k m ~ i g
(die Betriebssystemprogramme
ablaufinvariant repr~sentiert,
488
um die Mehrfachhaltung verschiedenen
yon Kopien ein und desselben
Programmes
in
Prozessen bzw. das Sperren yon Betriebsprogrammen
gegen Unterbrechungen
bei Mehrfachbenutzung
dieser 0rganisationsvariante
ist die reduzierte
die durch Mischen von (unausgetesteten) Betriebsprogrammen und aufwendige
im Arbeitsspeicher
hardwaregest~tzte
dert sowie die Einschr~nkung prozessorsystemen)
zu umgehen).
Nachteil
Betriebssicherheit,
Anwenderprogrammen desselben
und
Prozesses
entsteht
Speicherschutzmechanismen
potentieller
Simultanarbeit
dutch die Serialisierung
erfor(in Mehr-
der Auftragsbearbei-
tung. (c) hierarchische Die Prozesse horizontal Vertikale
Proze~-Struktur: der Schale sind in Schichten
zusammengefa~t,
und vertikal Auftragsbeziehungen Auftragsbeziehungen
die in verschiedenen
werden.
k~nnen zwischen Prozessen bestehen,
Schichten
lokalisiert
von au~en nach innen gerichtet
sind. Sie m~ssen stets
sein (innen bedeutet
nah) und sind eng mit Unterprogrammschachtelungen Horizontale
wobei
unterschieden
Auftragsbeziehungen
hier hardware-
verwandt.
k~nnen zwischen allen Prozessen
einer Schicht bestehen und werden kooperativ unter Zuhilfenahme von Synchronisationsmechanismen Trotz h~herer Betriebskosten aufrufe,
die bei vertikaler
entwickelt.
f~r die Realisierung Auftragsverkettung
~ber einer simplen Unterprogrammtechnik Variante
entstehen,
aus Gr~nden der Betriebssicherheit
die g~nstigsten Eigenschaften
/i01.
des oben skizzierten ein spezifisches
wickelt und fur die hardwaren~chste der Ablaufsteuerung
ten erreicht,
Schicht
definiert
Typs wurden im Rah-
Schichtenmodell
/ll/.
Bewegungsspielraumes
bei gleichzei-
fur die Einbettung
wurden durch eine geeignete Festlegung
die als 'abstrakte Maschinen'
und dem Anwender explizit
zug~nglich
ent-
ein Satz von Elementar-
des Softwareerstellungsprozesses
tiger Wahrung des notwendigen der Anwendersoftware
dienen.
f~r ein Standard-Betriebssystem
men eines Forschungsvorhabens
Die Systematisierung
besitzt diese
Sie soll deshalb nachfolgend
FUr eine Betriebsorganisat±on
funktionen
gegen-
und Adaptierbarkeit
als Modell einer Standard-Betriebsorganisation 4. Elementarfunktionen
der Funktions-
yon Prozessen
der Schich-
aufgefa~t werden k~nnen
sind (Abb. 2).
489
Anwendungssoftware
kann zu allen Schichten der Organisationshierarchie
hinzugef~gt werden, wodurch eine treppenf~rmige Anwendungs- und Betriebssoftware
entsteht.
Schnittstelle
zwischen
Die Kenntnis von Funktionen
in tieferen Schichten wird erst dann erforderlich, wenn der Anwender sich auf das Programmierniveau der zugeh~rigen abstrakten Maschine begibt. Dem realisierten System liegt eine zun~chst auf drei Schichten beschr[nkte Struktur zugrunde:
die Schicht der
Elementarfunktionen, -
der Unterbrechungsprozesse, der Schalen-Prozesse.
-
Die Elementarfunktionen -
k~nnen in fUnf Klassen unterteilt werden:
Unterbrechungsfunktionen: sie dienen der Prim[rbehandlung
yon Unterbrechungen und umfassen
z.B. das Retten und Laden von Registern sowie Manipulationen des Unterbrechungswerkes, - Primitiv-EfA-Funktionen: durch sie wird die Ausgabe von Steuerbefehlen an die Peripherie initialisiert. - Dispatcherfunktionen: sie sind fir das Multiplexen des Prozessors in symmetrischen Mehrprozessor-Systemen)
(bzw. der Prozessoren
Uber die ablaufbereiten
Prozesse der Schale verantwortlich. - Synchronisationsfunktionen: sie koordinieren die Wechselwirkung zwischen Prozessen,
die z.B.
beim Zugriff auf gemeinsame Daten oder der Kommunikation zwischen ihnen bestehen. - Speicherhilfsfunktionen: sie unterst~tzen die Zuweisung und Freigabe yon Arbeitsspeieher, der im Bereich des Nukleus fur den Aufbau dynamisch verwalteter Datenstrukturen ben~tigt wird. Eine detaillierte Beschreibung eines kompletten Satzes der Elementarfunktionen sowie Demonstrationsbeispiele,
auf die hier aus Platz-
gr[nden verzichtet werden mud, findet sich in ]11/.
490
5. Erfahrun~en mit einem experimentellen
Pro~rammiersystem
Auf der Basis des im vorigen Kapitel besprochenen
dreischichtigen
dells wurde ein experimentelles
Programmiersystem
fGr den Kleinrech-
ner $320 yon Siemens
/18/. Der Anwender,
paket modulweise zifizieren,
Quellsprache
vorgesehen
ist die um einige Makrodefinitionen
den Programm-Module des Anwenders
Parameter
aus zwei Bibliotheken
Programmsystems, ausgelSst
vereinigt:
Bibliothek,
in der alle Elementar-
im Zweifelsfall
sind. Die Auswahl wird durch
ersetzen die vom Anwender der 8ffentlichen
s~tzlich zu den Inhalten dieser zwei Bibliotheken fGr den Anwender - einige kurze ProgrammstGcke tarfunktionen
in denen die reale Maschine
definierten
wird, wer-
der Bibliothek
(z.B. Bedienung der Standard-
usw.) enthalten
Module die Standardmodule
stem hinzugefGgt,
Assembler-
angegeben wer-
fGr die Unterbrechungsbearbeitung
Betriebssystemdienste
Texteditor
gesteuert,
schriebenen
eines kompletten
und der Gffentlichen
und allgemeine
erweiterte
Bedienungskommando
sowie Standardmodule
peripheries
zu spe-
die erstellten
zur Modulspezifikation
Bei der Generierung
die dutch ein entsprechendes
funktionen
explizit
sind.
in der SchlGsselworte
den kSnnen.
der sein Programm-
hat dort die MSglichkeit,
fGr welche Betriebsorganisationsschicht
Programm-Module
sprache,
entwickelt
entwirft,
Mo-
Standards
ge-
Bibliothek.
Zu-
werden - unsichtbar
zu dem generierten
Sy-
an die durch die Elemen-
angepaSt wird.
Im Falle der 320
umfassen diese Anpassungen: Sprungverteiler -
fGr Unterbrechungseing~nge,
den Quittungsverkehr
zwischen E/A-Ger~ten
und dem Rechner inner-
halb einer geblockten Ein/Ausgabe, - die Transformation
der Unterbrechungskaskade
auf ~ine Unterbre-
chungsebene. Durch diese Anpassungen, Hardwarebesonderheiten durch eine abstrakte erlernbarer
sehr vielversprechend konzepts
sie werden ersetzt
einheitlicher,
Die ersten Systemgenerierungen
und scheinen
zu best~tigen°
sind, nicht notwendigerweise
aufweisen mGssen.
leicht
verliefen
dab zugeschnittene Struktur-
eine kopflastige
Mit einem Arbeitsspeicherbedarf
1 K Worten fGr einen kompletten Betriebssysteme
verdeckt;
mit weitgehend
werden die
die auf der Basis eines verallgemeinerten
entstanden
ganisation
der Zielrechner Maschine
Architektur.
Programmsysteme,
die ca. 100 Befehle umfaSten,
Satz yon Elementarfunktionen
generiert we rden, die einen Gesamtbedarf
2 K Worte aufwiesen und damit bei etwa vergleichbarer
Or-
yon ca. konnten
kleiner
Leistung gGn-
491
stiger lagen als entspreohende
'handgestrickte' Versionen des Her-
stellers. Dies ist im wesentlichen auf die Wirtschaftlichkeit des strengen hierarchischen Aufbaus und die besseren MSglichkeiten einer Optimierung durch den hohen Modularisierungsgrad
zur~ekzuf~hren.
6. Schlu~bemerkun5 Die Standardisierung von Betriebssoftware,
die Gegenstand der voran-
gegangenen Ausf[hrungen war~ dient nicht nur einer Systematisierung des Software.-Design-Prozesses, tit von Anwendungssoftware.
sondern verbessert auch die Portabili-
Dies wird im wesentlichen durch die Ver-
einheitlichung der funktionellen Abh[ngigkeiten zwischen Anwendungsund Betriebssoftware erreicht. Die ~bertragung von Anwendungsprogrammpaketen auf ein anderes DV-System erfordert daher nicht notwendigerweise die 0bertragung des unterlegten Betriebssystems,
das mit iden-
tischen Schnittstellendefinitionen bereits im Zielreehner existiert. Literatur
/1I
James R. Bell Threaded Code CACM Voi.16, No.6, June 1973, 370-372
/21
J. Gray, B. Lampson, B. Lindsay, H. Sturgis The Control Structure of an Operating System RC3949, IBM-Research, July 1972
131
J,F.
Ossanna
The Current State of Minicomputer Software AFIPS SJCC 1972, Vol.40, 111-118
141
D.J. Waks, A.B. Kronenberg The Future of Minicomputer Programming A~IPS SJCC 1972, Vol.40, 103-109
151
H.E. Pike Future Trends in Software Development for Real-Time Industrial Automation AFIPS SJCC 1972, Vol.40~ 915-923
492
/6/
J.D. Schoeffler The Development of Process Control Software AFIPS SJCC 1972, Vol.40, 907-914
171
C.L. Smith Digital Control of industrial Processes Computing Surveys, Vol.2, No.3, Sept. 1970, 211-241
/8/
G. KrUger Rechnereinsatz in Laboratorien und Pr~ffeldern VDE-Fachberichte Bd. 26 (1970), 120-125
/9/
M. Syrbe Messen, Steuern, Regeln mit Prozessrechnern Akademische Verlagsgesellschaft Frankfurt a. Main, 1972
/ 1 0 / D.L. Parnas On the Criteria to be Used in Decomposing Systems into Modules CACM Vol. 15, No. 2, Dec. 1972, I053-1058 /11/
J. Nehmer
Ein Ansatz zur Standardisierung yon Betriebssoftware Lecture Notes in Computer Science Vol. 8, M~rz 1974, 175-188, Springer-Verlag
/ 1 2 / R.C. Varney, M.H. Gotterer The Structural Foundation for an Operating System The Computer Journal, Vol. 16, No. 4, 357-359
I~31 D.H. Albernathy, J.S. Mancino, C.R. Pearson, D.C. Swiger Survey of Design Goals for Operating Systems Report GiTIS-72-04, Georgia Institute of Technology, April 1972
/ 1 4 / R.A. Grimm Automated Testing Hewlett-Packard Journal August 1969, 2-20
1151 Process Systems Program (PROSPO II) iBM-Druckschrift GH20 - 4000 (1970)
493
/16/ B. Eichenauer u.a. PEARL, eine proze~- und experimentorientierte Programmiersprache Angewandte Informatik 9, Sept. 1973, 363-372 /17/ O. Eggenberger Ein integriertes Konzept f~r die Proze~kommunikation in Proze~rechensystemen Fachtagung "Prozessrechner 1974" Karlsruhe, io.-Ii. Juni 1974 /181 Lothar Metz Ein Produktionssystem fGr schichtenweise gegliederte Betriebsorganisationen am Beispiel der $320 Diplomarbeit an der Fakult~t fGr Informatik der Universit~t Karlsruhe, M~rz 1974
EIN INTEGRIERTES
KONZEPT FOR DIE PROZESSKOMMUNIKKTION
IN PROZESSRECHENSYSTEMEN
Otto Eggenberger
Einleitung Ein wesentliches Reaktionszeit technischen
Leistungsmerkmal
auf asynchrone
Ereignisse,
erfordert
zur ProzeS-Kommunikation
denden Operationen
k~nnen fur die Synchronisation
Hilfs-
Von Dijkstra
Semaphore mit den darauf anzuwen[~.
Diese Operationen
beim Zugriff zu gemeinsam benutzten
werden, wof~r sic sich bereits bew~hrt haben.
Der Einsatz von Semaphoren erfordert
leistungsstarke
P(S) und V(S) eingefNhrt
Daten direkt angewendet
ausgel~st werden.
und Synchronisation.
wurden zur Proze~synchronisation
ist die
die durch Signale aus dem
Proze~ oder dutch interne Meldungen
Eine schnelle Reaktionsf~higkeit mittel
eines Proze~rechensystems
f~r die Kommunikation
jedoch zus~tzliche
Hilfsmittel,
Prozesse von demselben Ereignis
Kenntnis
zwischen Prozessen
um zu erreichen, erhalten.
daS mehrere
Als Hilfsmittel
wurde bisher nur die Einffihrung eines Kommunikationsprozesses geschlagen,
womit aber ein zus~tzlicher
organisatorischer
sowie l~ngere Reaktionszeiten
verbunden
vielen Betriebsorganisationen
spezielle Nachrichtensysteme
Basis des Event- oder Messagekonzepts. hier jedoch an der Aufstellung nutzung der Eventvariablen
sind. Daher finder man in Generel!e
eindeutiger
LSsungen
Vorschriften
das durch die EinfNhrung
von Nachrichten Funktionen
fNr die Be-
zur Proze~kommunikation
ein Konzept vor-
eines Instruments
die Definition primitiver,
mentaren Funktionen
auf der scheiterten
oder Messagepuffer.
In diesem Bericht wird auf der Basis yon Semaphoren gestellt,
vor-
Aufwand
zur Obermittlung
jedoch leistungsf~higer
gestattet.
Nit Hilfe dieser ele-
lassen sich beliebige Event- und Messagesysteme
aufbauen. Synchr0nisation FUr die Koordination Proze~umschalter
unabh~ngiger
(Dispatcher)
fur die Koordinierung
paralleler
erforderlich.
abh~ngiger
paralleler
Prozesse
ist nut der
Dagegen ben~tigt man Prozesse
spezielle
495
Synchronisationshilfsmittel. nisationsfunktionen, der Prozesse.
unterscheiden
sogenannte
Synchro-
sich durch die Art der Abh~ngigkeit
Man kann zwei Arten der Abh~ngigkeit
- Abh[n~igkeit
unterscheiden.
durch Daten
Eine Abh[ngigkeit Existenz
Diese Hilfsmittel,
durch Daten besteht,
gegenseitig
nicht bekannt
meinsam benutzten Datenbereich griff derart synchronisiert
wenn mehrere
zu sein braucht,
zugreifen wollen.
Prozesse,
Hier mu~ der Zu-
werden, da~ nur eine begrenzte
yon Prozessen
das Zugriffsrecht
Zugriffsrecht
erhalten kann,
erhglt.
deren
zu einem geAnzahl
Wenn nut ein Proze~ das
so ist der Zugriff ausschlie~lich
(mutual exclusion). - Abh[ngiskeit
von Erei~nissen
Besonderheiten,
die au~erhalb
Ablauf eines Prozesses
Oft wird die Fortsetzung mehrerer Ereignisse
aktiviert
oder intern beim
werden als Ereignisse
eines Prozesses
abh[ngig gemacht.
da~ Prozesse vom Eintritt gebenenfalls
eines Rechensystems
eintreten,
vom Eintritt
bezeichnet.
eines oder
Hier ist es erforderlich,
der Ereignisse
benachrichtigt
und ge-
werden.
FGr diese beiden Probleme
l~t
Synchronisationsfunktionen
sich jeweils
angeben,
ein getrennter
mit denen beliebige
tionssysteme
aufgebaut
chronisation
dienen dazu, einen Puffer w~hrend der Bearbeitung
Nachrichtentexte
werden k6nnen.
Die Funktionen
Satz von
Kommunika-
gegen den Zugriff anderer Prozesse
Hilfe der Funktionen
zur Ereignissynchronisation
yon der Bereitstellung
einer Nachricht
wesentlichen positiv
aus einem Z~hler,
(einschlie~lich
Null)
Ver~nderungen
m~glich.
werden Semaphore
initialisiert genannt.
im
wird. Der Stand des Z~hDer Wert Null bedeutet, Null, da~ es frei ist.
sind nur durch die Operationen
P
(Semaphorliste)
V
(Semaphorliste)
Diese Operationen,
als gene-
eingesetzt. Ein Semaphor besteht
ist, ein Wert g r ~ e r
eines Semaphors
Mit
werden die Prozesse
dessen Wert bei seiner Einrichtung
lers wird auch Wert des Semaphors dab das Semaphor gesperrt
zu sperren.
der
in einem Puffer informiert.
Zur L6sung dieser Synchronisationsprobleme rel!e Synchronisationshilfsmittel
zur Datensyn-
die auch Proze~zust~nde
~ndern kSnnen,
496
werden so definiert,
dab ein Semaphor nur positive Werte annehmen
kann. Sie haben folgende Wirkung:
-
P (Semaphor!iste) Beim Aufruf der P-Operation werden die Werte der in der Liste angegebenen Semaphore gepr~ft.
Sind alle Semaphore frei, so werden die
Werte dieser Semaphore um Elms erniedrigt. Semaphore gesperrt ausgel~st wurde,
Andernfalls, wenn einige
sind, wird der Proze~, durch den die P-Operation
in einen Wartezustand versetzt, bis alle Semaphore
frei sind.
-
V (Semaphorliste) Dutch die V-Operation werden die Werte der in der Liste angegebenen Semaphore um Eins erhSht. Dabei kann die Situation eintreten,
dab
nun alle Semaphore frei sind, auf Grund derer ein Proze~ blockiert wurde.
Dann werden die Werte dieser Semaphore um Eins erniedrigt
und der Proze~ deblockiert. Die P- und V-Operationen sind f~r den Benutzer unsichtbare Hilfsmittel.
Sic werden nur von den Synchronisationsfunktionen
verwendet.
Modell Grundlage f~r die Entwicklung der Synchronisationsfunktionen schichtenweiser Aufbau eines Betriebssystems zun~chst zwei Teile zu unterscheiden,
ist ein
(Abb. Nr. i). Dabei sind
ein privilegierter Teil, Nukle-
us oder Kern genannt, und ein nicht privilegierter Teil, die Schale. Im nicht privi!egierten Tell k~nnen nut die allgemeinen !nstruktionen, sowie eine Instruktion zum Eintritt in den Nukleus ausgef~hrt werden.
In diesem Teil findet man die Anwenderprozesse und einige
Standardprozesse
des Betriebssystems.
Im Nukleus dagegen steht der
gesamte Befehlsvorrat des Proze~rechners die privilegierten
L~schen yon Interruptmasken
insbesondere Setzen und
oder Speicherschutzschl~sseln,
Synchronisationsinstruktionen und "reset".
zur Verf~gung,
Instruktionen wie Ein-Ausgabebefehle, "lock" und "unlock" bzw.
sow~e die
"test & set"
In diesem Tell unterscheiden wir die Schicht der Inter-
ruptroutinen und die der Elementarfunktionen.
Beim Eintritt in den
Nukleus wird hardwarem~Big durch den Interruptmechanismus trolle an eine interruptroutine ~bertragen.
die Kon-
497
<0
Software
O 40 I I
i I
I
I
I
I
I
I
I
I
I ! I
, I
I
40
Prozesse H
I
I
I
©
I
'
Interruptroutlnen
I
!I I Ii
1
~
I
l
@ ®
t
I
I
I
Elementarfunktionen
privilegierte
Instruktionen
Hardware Abb. Nr. i
Schichtenweiser Aufbau eines Betriebssystems
InterruptRoutinen
I InterruptRoutinen
I
/
llnterrupt- ] Funktionen
ElementarFunktionen
privilegierte Instruktionen
ic!er! kti°ne I LOCK / UNLOCK - Instruktion
Abb. Nr. 2 Hierarchische Anordnung der Elementarfunktionen
498
Diese kann nun selhst alle organisatorischen die Elementarfunktionen
der Ablaufsteuerung
wir die Interruptfunktionen unterbrochenen
Programms),
(Dispatcherfunktionen)
fur den Nukleus.
zug~nglich.
oder Standardteile
benutzen.
Anordnung der Schichten
erfordert,
dab Prozesse
werden mGssen,
ist jede Schicht hinzuf~gen
Dadurch ergibt sich eine treppenartige
ist nun selbst wieder hierarch-
abh~ngig von vorgegebenen
versetzt,
von Prozessen
Bedingungen
bzw. aus einem Wartzustand
benutzen die Synchronisationsfunktionen
waltung ben6tigte
alle M~g-
[21 .
bau die Elementarfunktionen beschafft.
offen zu lassen,
die Funk-
sowie die
Um dem Anwender
(Abb. Nr. 2). Da die Synchronisation
einen Wartezustand
oder
Hierzu rechnen
Er kann eigene Programmteile
Die Schicht der Elementarfunktionen isch aufgebaut
benutzen.
die Synchronisationsfunktionen,
lichkeiten des ProzeSrechensystems dem Programmierer
ausfHhren
(zum Retten und Laden des Status des
tionen zur Rechnerkernvergabe Speicherhilfsfunktionen
Aufgaben
zur Rechnerkernvergabe.
in
aktiviert als Unter-
Der zur Ver-
Speicher wird durch die Speicherhilfsfunktionen
AuSerdem benutzen alle Funktionen
"lock" und "unlock",
die Instruktionen
da der Zugriff zu den im Nukleus vorhandenen
Listen nur hardwarem~Sig
synchronisiert
werden kann.
Datens~nchronisation Die Aufgabe der Datensynchronisation derung das Zugriffsrecht zu erteilen. blockiert
ist es, Prozessen auf Anfor-
zu einem gemeinsam benutzten Datenbereich
Dazu gehGrt, daS Prozesse gegebenenfalls
werden,
his das Zugriffsrecht
verfGgbar
solange
ist. FGr die Ver-
wa!tung des Zugriffsrechts
wird jedem yon mehreren Prozessen gemein-
sam benutzten Datenbereich
ein Semaphor
sierungswert
gibt an, wieviele
des Semaphors
gleich das Zugriffsrecht
zugeordnet.
Der initiali-
Prozesse maximal
zu diesem Datenbereich
Dieser Wert ist stets grSSer als Null und kennzeichnet tialisierung
das Semaphor fGr den Gebrauch
FUr die Anforderung (Semaphorliste)" (Semaphorliste)".
yon Zugriffsrechten
definiert,
bei der Ini-
zur Datensynchronisation.
wird die Funktion
"SEIZE
fur die RGckgabe die Funktion
"RAISE
Diese Funktionen
P- bzw. V-Operatlon
zu-
erhalten k8nnen.
f~hren die eingangs
auf die Semaphore
Wirkung mit diesen identisch.
erl~uterte
aus und sind daher yon der
Die Zwischenschaltung
yon Funktionen
499
anstelle erh~hte
der direkten Anwendung Sicherheit,
Funktionen
der P- und V-0peration
da hierdureh eine Kontrolle m~glich ist, ob die
zur Datensynehronisation
phore angewendet
bietet eine
auf die hierf~r angelegten
Sema-
werden.
Erei~nissynchronisation In ProzeSrechensystemen nisse
(Events)
treten asynchron
- Ein internes Ereignis zesses,
ist eine Besonderheit
kann die Tatsache,
Puffer geschrieben
wurde, als internes
Ein externes Erei~nis Rechensystems zu melden, Prozessor
auftritt.
veranla~t,
Um den Eintritt
wird.
der Nachrieht
eines Ereignisses "Ereignis
hat jedoeh nicht geneeingetreten
!nterruptroutine
und diese Prozesse
mitgeteilt.
die Bedeutung
ist eingetreten
daher Signal genannt. tretenden
Ereignistyp
zu enthalten
Zur ~hertragung
scheidung yon Ereignissen
ent-
zu verwalten.
die Prozessen mitgeteilt
- Ereignis
festgelegt.)
wird Prozessen durch die ~bermittlung
ist eingetreten"
keine Information
ist,
eines Inter-
ist es, Prozessen auf Wunsch
mitzuteilen
ist die einzig m~gliche, Nachricht
wodurch
verst~ndliches
Die Bedeutung
ihrer Synchronisationsanweisungen
Der Eintritt
auszuf~hren,
(Ein Interrupt
Die Aufgabe der Ereignissynchronisation eines Ereignisses
Dadureh wird ein
f~r Prozesse
da~ ein externes Ereignis
rupts wird erst in der zugeh~rigen
des
eines externen Ereignisses
sondern dient lediglich als Hilfsmittel.
den Eintritt
die au~erhalb
ausgel~st werden.
in ein internes,
transformiert
rell die Bedeutung,
aufgefa~t werden.
interessieren.
eine Interruptroutine
das externe Ereignis
Zum
in einen
ob es andere Prozesse
ist eine Besonderheit,
mu~ ein Interrupt
m~ehte.
(Message)
Ereignis
Bedeutung,
gibt, die sich fur dieses Ereignis
sprechend
im Ablauf eines Pro-
da~ eine Nachricht
Es ist dabei yon untergeordneter
Ereignis
sind.
dessen Eintritt dieser Proze5 bekanntgeben
Beispiel
-
interne und externe Ereig-
auf, die wie folgt definiert
- festliegt,
braucht
(leere Nachrieht)
die
und wird
der Signale und zur Unter-
verschiedener
ein sogenannter
Diese Nachricht
werden kann. Da
Ursaehen wird f~r jeden auf-
Nachrichtenkanal
eingeriehtet.
5OO
Durch den Namen eines N a e ~ i e h t e n k a n a l s
ist der Ereignistyp
ein-
deutig bestimmt. Zum Empfang eines Signals wird ein Semaphor verwendet, oder mehrere Nachrichtenkan~le Das Semaphor,
angesahlossen
das die eintreffenden
initialisiert,
Signale
wodurch es gleichzeitig
eignissynchronisation
gekennzeichnet
mehrere Naehrichtenkan~le
werden.
z~hlt, wird mit Null
(Abb. Nr. 4), k6nnen die
Der Empfang eines Signals be-
eigene Semaphore
kan~le anzusehlieBen
oder bereits bestehende
eines bestimmten
einzurichten
Ereignisses
Hierzu dient die Funktion
eine V-Operation
ausgef~hrt
durch die Funktion auf die angegebenen bis alle Ereignisse
entspricht.
sind, wird hierdurch e±ngetreten
erfolgt
Falls noch nicht alle Erein ProzeB solange blockiert der Semaphore).
yon Null auf Eins stets nur ein
sind folgende beiden F~lle zu unterscheiden.
- Jeder ProzeB hat ein eigenes angeschlossen.
Semaphore
die der P-Operation
sind (Undverkn~pfung
Da bei der Erh~hung eines Semaphors
mitge-
(Nachrichtenkanal)",
angeschlossene
wird. Das Warten auf Ereignisse
Semaphore
ProzeB aktiviert wird,
zu benutzen.
Nachrichtenkanal
"WAIT SEMA (Semaphorliste)",
eignisse eingetreten
und an Nachrichten-
wird also durch die ~ber-
"SIGNAL EVENT
wodurch auf alle an den Nachrichtenkanal
ein-
Jeder ProzeB
Semaphore
tragung eines Signals ~ber den entsprechenden teilt.
Ereignisse
der Nachrichtenkan~le).
hat die M~glichkeit,
Der Eintritt
f~r die Er-
Ist ein Semaphor an
deutet dann nur, dab irgend eines der zugeh6rigen ge,treten ist (0derverkn~pfung
das an einen
(Abb. Nr. 3).
als Semaphor
wird.
angeschlossen
Signale nicht unterschieden
wird
Semaphor an einen Nachrichtenkanal
Dann wird jeder ProzeB beim Eintritt
des Ereig-
nisses aktiviert.
-
Mehrere Prozesse benutzen Nachrichtenkanal Ereignisses
ein gemeinsames
angeschlossen
-
das an einen
ist. Dann wird beim Eintritt
des
nur ein ProzeB aktiviert.
Unter anderem sind in diesem Konzept lich
Semaphor,
folgende
Konstellationen
m6g-
(Beispiel Abb. Nr. 5):
ein Sender~
ein Empf~nger
Ein Signal wird ~ber einen Nachrichtenkanal
geschickt,
an dem
501
Ereignis tritt ein:
Nachrichtenkanal Signal
Semaphore
Abb. Nr. 3
Ein Signal erh~ht alle an einem Nachrichtenkanal angeschlossenen
Semaphore um i
chtenkan~le
L
Abb. Nr.
4
Semap~or
Ein Semaphor ist an mehreren Nachrichtenkan~len angeschlossen
502
Nf
Nachrichtenkan~le
/
/ I I
/ /
I
/ I /
/
I
I I
/
Semaphore
I
q
~J /
/
/
/ / /
/
/ /
/ /
/
/
/
/
/
/
/
/
/
/
/
/
/ /
S~
/
/
/
/
/
/
/
/ /
/
/
/
ProzeSkontrollbl~eke
I
/
/
/
__L p____~2
_ _
S3
S4
Abb. Nr. 5 Beispiel zur Ereignissynehronisation
s4
503
ein Empf~nger
~ber ein Semaphor angeschlossen
ist.
- ein Sender~ mehrere Empf~nger Ein Signal wird ~ber einen Nachrichtenkanal
geschickt,
an dem
mehrere Empf~nger ~ber jeweils ein eigenes Semaphor angesehlossen sind. Da jeder Empf~nger das Problem beseitigt,
sein eigenes Semaphor besitzt,
weleher Empf~nger
ist
ein altes Signal zer-
stSren soll, nachdem es die Qbrigen Empf~nger
zur Kenntnis ge-
nommen haben.
-
ein Sender~
irgendein Empf~nser
Ein Signal wird ~ber einen Nachrichtenkanal mehrere Empf~nger
~ber ein gemeinsames
geschickt,
Semaphor
sind. Wenn im Moment der ErhShung des Semaphors wartet,
nimmt es der ProzeS zur Kenntnis,
Warteanweisung
gibt. Andernfalls
sich in der Liste der wartenden
an dem
angeschlossen kein Proze~
der als erster eine
wird der ProzeS aktiviert, Prozesse
der
an erster Stelle be-
finder. - mehrere
Sender~
Ein Empf~nger die jeweils
ein Empf~nger
erh~It Signale ~ber mehrere Nachrichtenkan~le,
ein Semaphor angesehlossen
- irsendwelche Ein Empf~nger
Sender,
ein Empf~nger
erh~!t Signale ~ber mehrere Nachriehtenkan~le,
jedoch alle auf dasselbe
In dem vorgestellten Verkn~pfung
zur Ereignissynchronisation
zwischen den Nachriehtenkan~len
ist nur
und eine Und-
zwischen den Semaphoren mSglich.
- Eine Und-VerknQpfung
zwischen Nachrichtenkan~len
lich, da die Nachrichtenkan~le synchronisation
darstellen,
den dynamischen
- Eine Oder-Verkn~pfung
ist nicht m~g-
Teil der Ereignis-
und die Gleichzeltigkeit
nissen nur statisch ~ber Semaphore
komplexer
die
Semaphor einwirken.
Konzept
eine Oder-Verkn~pfung
an
ist.
zwischen
logischer Ausdr~cke
von Ereig-
erfa~t werden kann.
Semaphoren und damit die Bildung ±st aus folgenden Gr~nden abzulehnen
5O4
Eine Oder-Verkn~pfung
ist nur sinnvoll, wenn der Benutzer unter-
scheiden kann, welche der durch "oder" zusammengefa~ten Teilbedingungen erf~llt sind. Da der Benutzer keinen Zugriff auf Daten des Betriebssystems
hat, m ~ t e n
die Werte der Semaphore aus dem
Nukleus in einen Proze~bereich des Benutzers kopiert werden. Dies ist jedoch nicht immer m~glich, da zum ZeitDunkt, wenn die komplexe Bedingung erf~llt ist, der betreffende Proze~ sieh nicht im Arbeitsspeieher befinden mu~. Zus~tzlieh m ~ t e
die Bedingung ein zweites
Mal, jetzt yon dem Proze~, ausgewertet werden. Es ist daher nur sinnvoll, komplexe Wartebedingungen dureh den Benutzer in seinem privaten Arbeitsbereich auswerten zu lassen.
Botschaftensysteme F~r den Austausch von Nachrichten mit Text (Message) gibt es viele Varianten,
die folgende Kennzeichen haben: Nachrichten fester oder
variabler L~nge, einfache oder mehrfache Kopien der Nachrichten, Nachrichten mit und ohne R~ckantwort, zipien der Nachrichtenpuffer,
verschiedene
unterschiedliche
lichkeiten der Nachrichtenpuffer.
Ordnungsprin-
Bearbeitungsm~g-
Beim Aufbau eines Botschaften-
systems mit dem hier vorgestellten Konzept mu~ die M~glichkeit geschaffen werden, Nachrichten mit Text ~ber die Nachrichtenkan~le zu transportieren und die Texte zu speichern.
Dies kann
auf zwei Arten erfolgen. - Erwe±terung der Semaphore Jedem Semaphor,
das an einen Nachrichtenkanal
angeschlossen ist,
wird ein Textpuffer angeh~ngt, der die empfangenen Nachrichtentexte aufnimmt.
Der Wert des Semaphors ist gleieh der Anzahl der
Nachrichten im Puffer. - Erweiterung der Nachriehtenkan~le Jedem N a e ~ i e h t e n k a n a l
wird ein Puffer zugeordnet,
in dem die zu
~bertragenden Texte gespeichert werden. Alle Prozesse, die ~ber ein Semaphor an einen Nachrichtenkanal
angeschlossen sind, haben
Zugriff zu dem zugeh~rigen Nachrichtenpuffer.
Zus~tzlich mu~ da-
f~r gesorgt werden, dab der letzte Proze~, der ei~e Nachricht erh~It, den hierf~r ben~tigten Speicherplatz wieder frei gibt.
5O5
Da solche Nachrichtensysteme stets anwendungsbezogen aufgebaut werden, sollte ihre Realisierung in ProzeBrechensystemen Aufgabe des Benutzers sein.
Zusammenfassun$ Die von Dijkstra eingefUhrten Semaphore werden nicht als Hilfsmittel zur Realisierung kritischer Abschnitte beim Zugriff zu gemeinsamen Daten betrachtet, sondern als allgemeine Hilfsmittel zur ProzeBsynchronisation.
Die Synchronisationsprobleme
in ProzeBrechensystemen
werden in zwei Klassen, Datensynchronisation und Ereignissynchronisation getrennt. Auf der Basis von Semaphoren werden fur jede Klasse Synchronisationsfunktionen definiert, wobei fur die Ereignissynchronisation als weiteres Hilfsmittel Naehrichtenkan~le eingefUhrt werden.
Litertur
Dijkstra, E.W. Cooperating Sequential Processes Mathematical Dep., Technical University Eindhoven,
Sept. 1965
Nehmer, J. Ein Ansatz zur Standardisierung yon Betriebssoftware Lecture Notes in Computer Science, Vol. 8, M~rz 1974 175-188
Ada~,,tierbar e Funktionen
zum stufenweisenAufb,au
eines ProzeSrechner-Betriebssystems W.R~b,
F~r die Programmierung der Anwender
G.Schrott
yon Proze~f~hrungsaufgaben
Funktionen
zur Ablaufsteuerung
ist es typisch,
und zum Betreiben der Ger~-
te benutzen mu~, die gew~hnlich
als grundlegende
triebssystems
Bei der Betrachtung
angesehen werden.
Operationen
stems in seinem schichtenweisen
Aufbau ~u~ert
Anwender Dienste und Funktionen
aus allen Schichten
Echtzeitsprachen, Sprachelemente
enthalten,
daran, dab die Wirkung dieser Anweisungen
eines Betriebssyexplizit
schaften ergeben.
da~ der
aufruft.
Grundsprache
mangeln heute meist
nicht exakt festgelegt
Die Ausf~hrung wird dutch das spezielle Betriebssystem wodurch sich bei ~bertragung
des Be-
sich dies darin,
die neben einer algorithmischen
zur Ablaufsteuerung
dab
auf andere Rechner
ist.
bestimmt,
andere Ablaufeigen-
Das Ziel unserer Arbeit ist es, eine Beschreibung
Echtzeitanweisungen
durch ihre Zusammensetzung
Betriebssystemfunktionen dieser elementaren
zu erm~glichen
Funktionen
von
aus grundlegenden
und einen strukturierten
zur Vereinfachung
Aufbau
ihrer Herstellung
anzugeben. Dabei werden folgende -
Ein stufenweiser
Ziele angestrebt:
Aufbau der Betriebssystemfunktionen,
sung an verschiedene spezielle
Hardware-Konfigurationen,
Proze~f~hrungsaufgaben
um ihre Anpas-
an Strategien,
und Echtzeitsprachen
an
zu erleich-
tern. -
Die Entwicklung
eines einheitlichen
dells als Grundlage
proze~orientierten
fur eine einfache ~bersichtliche
Zustandsmo-
Programmierung
der Funktionen. -
Die Verwendung
einer Systemimplementierungssprache,
che Dbertragung I. Stufenweiser
auf andere Rechner
Aufbau der Funktionen
Die von uns betrachteten des Betriebssystems
Funktionen reichen von elementaren
bis zu Systemdiensten
Eine erste Zweiteilung innerhalb
um eine einfa-
zu unterst~tzen.
der Funktionen
des Programmsystems
Funktionen
und Echtzeitsprachelementen.
ergibt
sich aus ihrer Lage
(= Betriebssystem-
und Anwenderprogram-
507
me). In jedem Programmsystem existiert eine unterste Schicht von Programmen, die direkt auf den Hardware-Eigenschaften
des Rechners aufge-
baut ist. Diese Schicht wird der Kern oder die Basisschicht Programmsystems Funktionen
genannt.
In ihr befinden sich z.B. die grundlegenden
zur Bearbeitung von Unterbrechungssignalen,
des Ablaufs der (Rechen)-Prozesse, tionen und zur Synchronisation.
zur Steuerung
zum Start yon Ein/Ausgabe-Opera-
Die Programme der h6heren Schichten
bilden die Schale des Progrsa~msystems. sind in E6~ definiert.
des
Die hier angef~hrten Begriffe
Im folgenden werden die Funktionen des Kern als
elementare Funktionen, die der Schale als h~here Funktionen bezeichnet. Eigenschaften und Beispiele finden sich in Abschnitt l.i. Adaptionsf~higkeit
3.
der Funktionen
Die Festlegung und Beschreibung der Funktionen kann als Ausgangspunkt f~r eine sp~tere Standardisierung von Betriebssystemeigenschaften als Grundlage bei der Definition von Echtzeitsprachelementen eine weite Verbreitung
und
dienen.
Um
zu erleichtern, m~ssen einmal implementierte
Funktionen mit m~$igem Aufwand an neue Konfigurationen
angepa~t oder
auf ~hnliche Rechner ~bertragen werden k~nnen. Bei der Definition der Funktionen ist daher auf eine Strukturierung
zu achten, die ein hohes
Ma~ yon Anpassungs-und ~bertragungsf~higkeit
(Adaptabilit~t und
Portabilit~t
~iI) bietet.
sungsf~higkeit
Insbesondere
soll durch eine hohe Anpas-
an verschiedene Benutzerkonzepte
schr~nkungen ein welter Anwendungsbereich erforderlich,
und Konfigurationsbe-
~berdeckt werden.
Dazu ist es
da~ sich der Anwender auf einen Teilsatz der Funktionen
beschr~nken und problemspezifische
Algorithmen einf~hren kann.
Ma~nahmen zur Erh~hung der Anpassungsf~higkeit
erleiehtern im allge-
meinen auch die ~bertragung auf andere Rechner. 1.2. Stufung der elementaren Funktionen Die elementaren Funktionen f~hren die grundlegenden Operationen des Betriebssystems
aus und bilden die Bausteine f~r h~here Funktionen.
Da
sie f~r viele Konfigurationen und Anwendungen brauchbar sein sollen, m~ssen sie in ihrer Wirkung funktionell beschreibbar Hardware-Eigenschaften
und Strategien einzugehen.
sein, ohne auf
Andererseits verlangt
die Implementierung die effiziente Ausnutzung der Hardware und den Entwurf geeigneter Verarbeitungsstrategien.
Das Problem kann durch eine
geeignete Stufung innerhalb der Funktionen gel~st werden. Figur i zeigt die logische Strukturierung und den parallel dazu laufenden stufenwei-
508
sen Aufbau.
Ziel ist die Erstellung der elementaren Funktionen, die
hier in der Stufe 3 zusammengefa~t
sind. Grundlage f~r eine Implemen-
tierung mu~ ein geeignetes proze~orientiertes
Zustandsmodell
(Abschnitt
2) sein, in dem die zur Ausf~hrung der elementaren Funktionen notwendigen ZustandsgrO~en,
deren Zust~nde und Oberg~nge festgelegt
der Festlegung der Datentypen f~r die Z u s t a n d s g r ~ e n keiten zu Wortstruktur und Zugriffseigenschaften
sind. Bei
treten Abh~ngig-
des Zielrechners
auf.
Die Stufe I innerhalb der elementaren Funktionen hat daher die Aufgabe, alle speziellen Hardware-Eigenschaften virtuellen Maschine).
Sie enth~It Funktionen
ZustandsgrS~en und Anweisungen, vonder
Hardware verdecken
brechungssignalen). Zustandsgr~en
zu ~berdecken
(Definition einer
zur Operation an einzelnen
die f~r h~here Stufen die Abh~ngigkeit
(z.B. Kanalbefehle, Maskierung von Unter-
Die Stufe 2 ist durch die Zusammensetzung
der (Rechen-)Prozesse
Einf~hrung von Ordnungsrelationen
gleicher
zu Strukturen und durch die
charakterisiert.
In dieser Stufe wird
festgelegt, wie einzelne oder Gruppen yon Z u s t a n d s g r ~ e n
zu Feldern,
Bl~cken oder verzeigerten Listen zusammengefa~t werden. Bei Listen ist die Art ihrer Verwaltung anz~geben
("FIFO", 0rdnung nach Priorit~ts-
zahlen). Damit ~berdeckt Stufe 2 alle strategieabh~ngigen Teile der elementaren Funktionen und enth~it geeignete Such- und Ordnungsalgorithmen.
Die Einf~hrung neuer Bearbeitungsstrategien
bedingt ~nderungen
in den Funktionen der Stufe 2. Nach Aufbau yon Stufe I und 2 lassen sich die Funktionen der Stufe 3 entwickeln und zusammensetzen, konkrete Datentypen und Strategien einzugehen.
R~ckkopplungen
der logischen Definition und den Implementierungserfahrungen einer wechselseitigen Verbesserung
ohne auf zwischen
f~hren zu
("multi level iterative modelling"
[3]). F~r eine genaue Abgrenzung der Funktionen oder eine feinere Stufung m~ssen Implementierungserfahrungen
abgewartet werden.
1.3. Stufung der h~heren Funktionen Die Funktionen der Stufe 4 und 5 setzen eine Basisschicht des Betriebssystems und einen Satz von elementaren Funktionen voraus. Die Programme k~nnen als (reentrant-)Prozeduren
oder asynchrone
(Rechen-)Prozesse
ab-
laufen. Die Stufe 4 setzt sich aus Funktionen f~r die spezielle Proze~f~hrungsaufgabe zusammen. Neben allgemeinen, Funktionen
(z.B. Me~werterfassung,
wender erstellte, Elemente
f~r viele Anwendungen gemeinsamen
Protokollierung)
dem Problem angepa~te Funktionen
zur Ablaufsteuerung)
werden hier vom An(Treiberprogramme,
aufgebaut.
Die Stufe 5 hat die Aufgabe, weite Anwendungsbereiche
durch Funktionen
5O9
zur Ausf~hrung yon Echtzeitsprachelementen zu ~berdecken. Die Funktionen enthalten als wesentliche Bestandteile Funktionen der Stufe 3 und 4 und sind in ihrer Wirkung durch Bezug auf Stufe 3 exakt beschre±bbar. Nach Implementierungserfahrungen kann durch eine Standardisierung der Stufe 3 eine Grundlage der Betriebssysteme geschaffen werden, die eine Ubertragung der Programme erlaubt.
Basisschicht des I Betri~bssystems I
Stufe 3 I Funktionelle Beschreibung der elementaren Funktionen
Satz yon elementaren Funktionen
Stufe 2
tSuch-undOrdnungsalgorithmen
I~
Zusammenfassung der IDaten zu Strukturen
I
Stufe 1
Zustands-I
Operationen an gr~Ben, Hardwarespezifische Operationen
I
Hardware
Stufung der Funktionen Figur 1
IDarstellung der ZuIstandsgr6~en als Daten I
Proze~orientiertes Zustandsmodell
I
Lo~ischer Aufbau
510 1.4. Portabilit~t der Funktionen Die Obertragung der Funktionen auf andere Rechner ist mit m~6igem Aufwand durch die Verwendung einer (nahezu) maschinenunabh~ngigen Implementierungssprache m~glich. Falls dieses Hilfsmittel nicht zur VerfGgung steht, kann ein System von Makroanweisungen
[I] verwendet
werden. FNr unsere Implementierung wird die im SFB 49 entwickelte Sprache Lo aus der Breitbandsprache
L
[2]
Spektrum an einfaehen Datentypen.
verwendet.
Lo
enth~it ein reiches
Die Sprache ist gekennzeichnet dutch
die Pflicht, Anpassungs- und Dereferenzierungsoperationen
expiizit
anzugeben, so dab implizite, dem Programmierer in der Niederschrift verborgene Operationen nicht auftreten. Anhang i enth~it als Beispiel eine in
Lo
programmierte Funktion der Stufe 3. Die dort beschriebene
Funktion zur Prozessorvergabe mit der Suche des n~chsten rechenwilligen Prozesses arbeitet auf einer nach Priorit~ten geordneten Liste. Die hardware-abh~ngigen Teile (Funktionen der Stufe i) sind als offene Prozeduren mit CodestNcken im Prozedurrumpf formuliert. Die Ma~nahmen zur Erh~hung der Adaptabilit~t und Portabilitlt der Funktionen sind in Tabelle i zusammengestellt. Tabelle 1 Funktionen
Funktionen anpaSbar an
Funktionen portabel durch
Echtzeitsprachelemente
Verwendung der (standar-
f~r weite Anwendungs-
disierten)
der Stufe
klassen
elementaren
Funktionen der Stufe 3 i
spezielle P r o z e ~ f ~ rungsaufgaben gew~nschten Leistungsumfang der Basisschicht (Subsetbildung) spezielle
(effiziente)
Algorithmen f~r Strate-
J
+ Verwendung einer (hSheren) Programmiersprache
J !
Systemimplementierungsi sprache i z.B. Lo> PI 360, POLYP, PS 440
gien Datentypen Hardware
Makros
511
2. Ein proze~orientiertes Grundlage
Zustandsmodell
f~r die Implementierung
eines Zustandsmodells, Ablaufsteuerung definiert.
der Funktionen
ist die Erstellung
welches die f~r die Informationshaltung
im Rechner nStigen
Zustandsgr~en
yon Betriebsmitteln,
Ereignisvariablen ZustandsgrS~en
u.s.w..
stellen.
Diese Tatsache
dargestellt
ein proze~orientiertes
werden,
man sich eine Kennzahl nung (Priorit~t)
festgelegt
ist die Darstellung
sein. Die Grund~berlegung dieser teilweise
Die h~ufigste
verarbeitet
Figur 2 gibt ein Beispiel
werden,
zu Listen.
Die
die genGgend
oft
kGnnen in zweifach
Listen gefGhrt werden.
zur Ableitung von Listendarstellungen
Die gew~hlte
in die Algorithmen
0rganisationsform der Funktionen
f~r
~u6erst dGnn
Richtung der Abarbeitung
Zusammenfassung
indizierten Bl8cken oder mehrfach verzeigerten
wesentlich
des aktuellen
zentralen Daten und alle GrSSen,
aus beiden Zugriffsrichtungen
kann
der Zeilen kann nach der Rangord-
die zeilen- oder spaltenweise
Zustandsmatrix.
nStig sind,
kann formal als Matrix
oder Liste zur Beschreibung
Die Reihenfolge
besetzten Matrix im Speicher. zur Ablaufsteuerung
0rganisations-
Speicherbelegung
sind. Als Inhalt eines Matrixelements
der Prozesse
die Implementierung
l~St.
aufzu-
in der die Zeilen den Prozessen und die Spalten den
zugeordnet
Zustands vorstellen.
angeben
Zustandsmodell
Zustandsmodell
und
dab sich bei allen
ist meist dutch die verwendeten
Das proze~orientierte
Zustandsgr8Ren
bestimmt
ist dabei,
oder
yon Semaphor-
zu den (Rechen-)Prozessen
die aus GrGnden einer 8konomischen
verborgen.
ihre Belegung
fiber ihre Verwendung
Wesentlich
eine Zuordnung
Hierzu ist es mSglich, formen,
samt ihren ~berg~ngen
Hierzu gehSren GrS~en fGr den Zustand der (Rechen-)Prozesse,
ffir ihre Lage in Haupt- und Hintergrundspeicher, Anforderung
und
aug der
der Zustandsmatrix
der Stufe 2 ein.
geht
512
Proze~orientiertes
Zustandsmodell
Beispiel i) Zustandsmodell
als Matrix
ZustandsgrS~en
;....
I
8
Pr oze~%-
SpeicherVerwaltung
ii) Darstellung
Synchr onisa- ZeittionsgrSP~enliste
des Zustandsmodells
Betrieb smit te iv erwa itmng
bei der Implementierung
wm J IIIIII
I II If m 11111¸I
I I
513
3. Beschreibung
der Funktionen
3.1. Eigenschaften
und Wirkung der elementaren
Diese Funktionen besitzen in der Basisschicht Angaben -
Funktionen
spezielle Eigenschaften,
herrUhren.
zu den Funktionen
Die Ableitung
sind in [4] und
die aus ihrer Lage
dieser Eigenschaften
[6] beschrieben:
Die Funktionen werden durch Unterbrechungssignale Calls"
(SVC-Befehle,
ersatzweise
durch Unterprogrammspr~nge) h6herliegenden
und
bzw.
"Supervisor
bei fehlender Hardwareunterst~tzung
aufgerufen.
Schicht gestattet,
Ein Aufruf ist nur aus einer
kann aber ab einer gewissen
Schicht verboten werden. -
Die Prozeduren,
aus denen sich die Funktionen
arbeiten im privilegierten ten (ge~nderten) -
Sie d~rfen
Modus,
Befehlsvorrat
(sinnvollerweise)
d.h. sie besitzen
einen erweiter-
und Adre~raum.
keine Wartezeiten
~ind w~hrend der gesamten Ausf~hrung den. Dies bedingt
zusammensetzen,
eine residente
enthalten,
d.h. sie
feat an den Prozessor
Lage der Programme
gebun-
im Hauptspei-
cher. F~r den anzugebenden
Satz yon Funktionen wird nicht gefordert,
minimal oder vollst~ndig
ist. Der Wunsch nach einer m~glichst
Anzahl ist fur StandardisierungsbemUhungen teilweise
im Widerspruch
verschieden
h~ufigen
gleichwertiger schon deshalb
zur effizienten
Inanspruchnahme
Funktionen
sinnvoll
yon Bedeutung, Implementierung.
Aus der
kann eine Aufteilung da der spezielle
formal Satz kann
Satz yon
Unterbrechungsprogrammen
des Anwenders
Basisschicht
der Stufe 3) sind folgende Funktionen
notwendig
(Funktionen
(alle Funktionen
Stufe 3 ~bergehen, a.
der Stufe i, die praktisch unge~ndert
in
werden mitaufgef~hrt):
(ZurUcksetzen)
von Registern
schen) von Innen- und Aussenmasken grammen
und Programmstatus,
Setzen
(L6-
[5], Zuordnung yon Antwortpro-
zu Unterbrechungssignalen.
Prozessverwaltung Sberg~nge
im Zustandsmodell
der Prozesse,
zesses an (yon) dem (einen) Prozessor, abzuwickelnden Prozessors, Abmelden, c.
F~r die Aufgaben der
Unterbrechungsver~rbeitung Retten
b.
hinzukommt.
geringen
steht aber
sein. Ein vollst~ndiger
nicht angegeben werden,
dab er
Proze~
~bergabe
Verdr~ngen
(Eingriffsfunktion), von P r o z e ~ g r ~ e n
Binden
(L6sen)
eines Pro-
Suche nach dem n~chsten Suche eines freien
an h6here Schichten
(An- und
yon Prozessen)
Synchronisierung Bereitstellung
von Synchronisierungs-Grundfunktionen
fur h~here
514
Schichten
(P,V-Operationen
Ereignisvariablen), Grundlage
an Semaphorvariablen,
Bereitstellung
FGhrung yon
yon Puffern und Listen als
fGr einen speziellen Botschaftenmechanismus.
d.) Ein/Ausgabe-Vorg~nge Normieren von Ger~ten,
Start Yon Ein/Ausgabe-Transfers,
Umcodie-
rungsarbeiten. e.) Speicherhilfsfunktionen Belegen und Freigeben yon Speicherbereichen, Speicherbereichen dynamischer
als "Compool"
L~nge mit gleicher
h~ufigsten Listenstrukturen
Initialisierung
fur Listen yon statischer Struktur,
(Vorw~rts-,
Listenoperationen Vorw~rts-
von
und fur die
und RGckw~rtsver-
zeigerung). f.) ZeitGberwachung Wegen der zentralen Bedeutung Realzeitsystem linden:
der ZeitGberwachung
werden sich Funktionen
Lesen und Berechnen der Uhrzeit,
Einrichten
der ZeitGberwachungsliste
in einem
hierzu in der Basisschicht Stellen des Weckers,
und Operationen
zur Eintra-
gung. Bei den Funktionen wurde bewu~t auf die Angabe von Parametern tet. Vorschl~ge
verzich-
hierzu finden sich in [4]. FGr eine s t a n d a r d m ~ i g e
Festlegung der Parameter mu~ sicher eine l~ngere Implementierungserfahrung vorliegen. grS~en),
Die Funktionen
funktionsspezifische
Blockl~nge
bei E/A-Starts)
~hnlichen Funktionen
enthalten
Parameter
und Parameter
eine umfassende
globale Daten
(Zustands-
(z.B. Start- und Zielangabe, zur Spezifikation,
wenn aus
Funktion gebildet wird.
3.2. H6here Funktionen F~r diese Funktionen Vorschl~ge
angeben,
lassen sich keine konkreten und allgemeinen da sie aus ihrer Definition
Problem oder einer Echtzeitsprache (spezielle)
Treiberprogramme,
Verwaltungsfunktionen
angepa~t
problemorientierte
Teile.
die Eingriffsfunktion
chen Eingriff
ob Vorkommnisse
Proze~ nur Eintragungen
zu einem sp~teren in den Ablauf
und vor allem
FUr den Aufbau der Ablaufsteuerung
(siehe 3.1b) das zentrale Element
hSheren Funktionen wird entschieden, oder im technischen
Botschaftsmechanismen,
fur Haupt- und Hintergrundspeicher
die ablaufstauernden
Auswertung
einem speziellen
sind. Sie beinhalten
Zeitp~nkt)
stellt
dar. In den
im Programmablauf
in der Zustandsmatrix
bewirken
(mit
oder einen zus~tzli-
(Aufruf der Eingriffsfunktion)
verursachen.
515
3.3. Beisp~el Der Inhalt der Funktionen in Abh~ngigkeit yon der Stufe soil am Beispiel der Aktivierung eines Rechenprozesses
(Task) durch die
Anweisung "activate task..." gezeigt werden. Der Aufruf als Funktion der Stufe 3 bewirkt die direkte Zuteilung des Prozessors an die Task... und den Start der Abwicklung. In Stufe 4 w~rd nach PrGfung der Anweisung auf Korrektheit der ProzeB in die Reihe der rechenwilligen Prozesse eingereiht. Falls der Anwender oder die Echtzeitsprache die Anweisung als Eingriff definieren,
erfolgt
der Aufruf der Eingriffsfunktion. In Stufe 5 kann die Anweisung mit Bedingungen (Zeitangaben, Unterbrechungssignalen u.s.w.) gekoppelt sein. Bei der Definition der Sprache mu~ mit Hilfe der Funktionen der Stufe 3 die Wirkung der Anweisungen in Abh~ngigkeit der Bedingungen und ihr Aufbau aus Stufe 3 und 4 angegeben werden. Schlu~ Eine Implementierung der hier ausgefNhrten Gedanken ist in Vorbereitung. Es wird erwartet, dab sich hierdurch eine Best~tigung und Verbesserung des stufenweisen Aufbaus der Funktionen ergibt. Diese Arbeit ist im Sonderforschungsbereich
49
Rechenanlagen und Informationsverarbeitung
-
-
Elektronische
in MNnchen entstanden.
Literaturverzeichnis [I] P.C.Poole, W.M.Waite: Portability and Adaptability. In Lecture Notes in Economics and Mathematical Systems 81, Seite 183-277. Springer Verlag, Berlin, 1973. [2] F.Geiselbrechtinger, W.Hesse, B.Krieg, H.Scheidig: Lo, the Basis Layer of the Wide Spectrum Language L. In Lecture Notes in Computer Science 1, S.188-197. Springer Verlag, Berlin, 1973 [3] F.W.Zurcher, B.Randell: Iterative Multi-Level Modelling, a Methodology for Computer System Design. In IFiP Congress 68, Seite 867871. North-Holland Publishing Company, Amsterdam (1969) [4] J.Nehmer: Ein Ansatz zur Standardisierung von Betriebssoftware. Vortrag auf der NTG/GI-Fachtagung "Struktur und Betrieb yon Rechensystemen", Braunschweig, M~rz 1974 [5] R.Baumann: Interrupt Handling in Real-Time Control Systems. Vortrag beim 2.European Seminar on Real-Time-Programming, Erlangen, 1972 [6] Funktionelle Beschreibung yon Proze~rechner-Betriebssystemen. Bericht des Unterausschusses 2 "Programmierung yon ProzeBrechnern" der Sektion 4 "ProzeBrechner zum Messen, Steuern, Regeln" der ~I/~YDE Gesellschaft f~r Me~- und Regeltechnik. im Erscheinen.
516 Anhang: Beispiel einer Funktion der Stufe 3 in Lo globale GrS~en: const int minprio ; const ref free psind; mod___~eplzeile is row ref free; row ref plzeile prioliste [32]; co Matrix mit Verweisen auf Proze~leitblScke, priorit~tsgeordnet mask M is [1..16,17..32],[i..4,5..12,13..28,33..48],[9..24,33..48]; co Proze~leitblock, gepaekt in 3 Worte ~ 48 bits oc mask zustand i~s [ ],[i..4],[ ]; Prozeduren: proc set interrupt inhibition is code [co Code f~r Setze Unterbrechungssperre o c]; proc reset interrupt inhibition is code [co Code f~r LSsche Unterbrechungssperre o~c]; pr0c load registers and status is code [co Code f~r Register und Status Laden o~c]; Pr9Q reschedule i_~s [: ref free ind, ref plzeile hl: res:
Iset interrupt inhibition;] for, prio to minprio do for pos do
nd if
subref
hl
(ind * psind)
[pes]; and
15its << deref ind part zustand : HEX3~ co psind : Verweis auf Pseudoproze~leitblock HEX3: Zustand rechenwillig
oc
then $oto disp fi od
odd; Ireset interrupt inhibition goto res; disp:
i
lload registers and statu~ ]
oc
SL3 - EINE M A S O H I N E N O R I E N T 1 E R T E P R O G R A M M I E R S P R A O H E AUF
ALGOL68-BASlS
D. DQrr, S . E i c h e n t o p f t _ U . Prahl~ G° Siegel~ G . Teblin~
E INLE ITUNG SL3 (= S y s t e m Low-Level-IIIL~nguage) wurde e n t w i c k e l t , u m auf den ProzeSrechnern der Fa° A E G - T e t e f u n k e n einen E r s a t z fQr d i e b i s h e r Qblichen A s s e m b l e r s p r a c h e n zu l iefern. Da b e i m E i n s a t z zur ProzeSsteuerung oft k t e i n e r e Rechner verwendet werden, mu8 hier auf E f f i z i e n z der S y s t e m s o f t w a r e und b e s t i m m t e r A nwendungssoftwere besonderer Weft g e l e g t w e r d e n . SL3 soil d e m n a c h d i e V o r t e i l e hSherer Sprachen ( S i c h e r h e i t , D o k u m e n t a t i o n s w e r t etc) m i t der E f f e k t i v i t & t einer A s s e m b l e r s p r a c h e k o m b i n i e r e n . Deshalb s i n d in SL3 sowohl m a s c h i n e n a b h & n g i g e ats auch m a s c h i n e n u n a b h ~ n g i g e S p r a c h t e i l e vorhanden. Die maschinenunabh&ngigen A n t e i l e b i l d e n einen Subset von ALGOL68 ~43, wobei der B e g r i f f Subset nicht a l l z u eng zu fassen i s t . Der Aufbau auf ALGOL68 fQr den oben g e s c h i t d e r t e n A n w e n d u n g s b e r e i c h e r s c h e i n t insbesondere dutch d i e hier g e gebene M S g l i c h k e i t der m o d e - D e k l e r a t i o n e n fQr h o c h o r g a n i s i e r t e Datenstrukturen s o w i e der zugehSrigen O p e r a t o r - D e k l a r a t i o n e n s i n n v o l l . Ans~tze in &hnlicher R ichtung l i n d e n sich bei EI~ _[2~ E33. SL3 s o l l nicht a l s neuer S p r a c h v o r s c h l a g verstanden w e r d e n , sondern es s o l l e n in d i e s e r A r b e i t Wege a u f g e z e i c h n e t w e r d e n , d i e es O o m p u t e r - H e r s t e l l e r n und A n w e n d e m e r l a u ben, auf der B a s i s yon ALGOL68 einen v o l l w e r t i g e n A s s e m b l e r - E r s a t z zu i m p l e m e n t ie r e n .
DIE S P R A O H E SL3 Es wurden gegen[Jber ALGOL68 E43 insbesondere d i e j e n i g e n S p r a c h e l e m e n t e entfernt, d i e in der Dmplementierung auf B e t r i e b s s y s t e m - A u f r u f e a b g e b i l d e t warden mGssen b z w . d i e einen erhebl ichen L a u f z e i t a u f w a n d nach sich z i e h e n . In b e s t i m m t e n Punkten wurde aus DokumentationsgrQnden v o n d e r A L G O L 6 8 - N o t a t i o n a b g e w i c h e n .
518
Folgende S p r a c h e l e m e n t e aus ALGOL68 wurden g e s t r i c h e n a) O o l l a t e r a l e A b a r b e i t u n g b ) Unions c)
Proceduring, r o w i n g , s l i c i n g
d) H e a p - G e n e r a t o r D i e s e S p r a c h e l e m e n t e s i n d e n t w e d e r fQr einen A s s e m b l e r - E r s a t z nicht n o t w e n d i g - b z w . lassen sich dutch andere S L 3 - K o n e t r u k t i o n e n e r s e t z e n . Folgende Erweiterungen wurden an ALGOL68 v o r g e n o m m e n - a l l e i m wesentl ichen unter d e m Gesichtspunkt~ dal3 dutch d i e I m p l e m e n t i e r u n g nicht m e h r A u f w a n d bezQglich M e n ge an Code oder L a u f z e i t e n t s t e h t , a l s der P r o g r a m m i e r e r an d i e s e r S t e t l e benStigt ° a) A u f t e i l u n g der Prozeduren in rekursive und n i c h t r e k u r s i v e Prozeduren s o w i e S u b rout inen: PROC P = (INT X~ REF INT Y ) I N T / - X - R E K U R S l V E PROC -X-/ BEGIN . . . . END PROCN Q= (REF INT Y , INT X) REF INT/-x- N I O H T R E K U R S I V E PROC -x-/ BEGIN . . . . END SUBR R = ( ) BEGIN . . . . .
END
/-x- SUBROUTINE-x-/
Sowohl PROO a l s auch PROON und SUBR b i l d e n einen eigenen m o d e . SUBR ist ebenf a l l s eine n i c h t r e k u r s i v e Prozedur, die jedoch i m m e r p a r a m e t e r l o s i s t . F a l l s doch Param e t e r auf t o g i s c h e r Ebene e x i s t i e r e n , so mul3 d i e ParameterQbergabe dutch Benutzuncj yon V a r i a b l e n m i t entsprechend gr613erem Scope yore P r o g r a m m i e r e r s e l b s t o r g a n i s i e r t w e r d e n . Auch das Retten der RQcksprungadresse mui3 v o m P r o g r a m m i e r e r s e l b s t v o r g e n o m m e n werden, so dal3 d i e SUBR genau d e m U n t e r p r o g r a m m in der A s s e m b l e r p r o g r a m mierung entspricht. b) E r w e i t e r u n g der p r i m i t i v e n m o d e s Folgende m o d e s , d i e i m ALGOL68-Report Qber m o d e - D e k l a r a t i o n e n in den s t a n d a r d prelude a u f g e n o m m e n sind~ wurden m i t l e i c h t e n ~nderungen als p r i m i t i v e m o d e s e i n g e fElhrt : FQr B i t f e l d e r e x i s t i e r e n die m o d e s L B I T l . . . / B I T 3 2
und
ABIT1...ABIT32 a l s ~.quivalent z u m A L G O L 6 8 - m o d e B I T S . W&hrend LBITi noch durch e i n e entsprechende m o d e - D e k l a r a t i o n der Form MODE LBITi = STRUCT ( [ 1 : i ]
BOOL-X-)
519
eingefOhrt gedecht werden kann, e n t s p r i c h t A B I T i d e m m o d e INT, w o b e i jedoch d i e g e naue Bitl'&nge zur internen D a r s t e l l u n g des i n t e g r a I - W e r t e s vorgegeben ist - w&hrend d i e s e b e i m m o d e INT i m p l e m e n t i e r u n g s a b h ~ n g i g i s t . Es s i n d a l s o f o l g e n d e D e k l a r a t i o n e n m6gl ich LBIT8 A , B;
ABIT8
O~ D;
INT X Den I d e n t i f i e r n A , B s o w i e C , D werden interne O b j e k t e in der Form yon B y t e a d r e s s e n zugeordnet, w&hrend d i e Zuordnung des internen O b j e k t e s zu X i m p l e m e n t i e r u n g s a b h~ngig i s t . K o r r e s p o n d i e r e n d z u m a r i t h m e t i s c h e n m o d e INT wurde noch e i n mode LOG eingefQhrt. D e f i n i t i o n s g e m A B hat LOG in der I n t e r n d a r s t e l l u n g d i e g l e i c h e Bitl@nge w i e INT, so dab z w i s c h e n LOG und INT d i e s s e t b e Beziehung herrscht w i e z w i s c h e n INTEGER und LOGICAL in FORTRAN. A l l e r d i n g s kann der S L 3 - m o d e LOG ein ganzes Iogisches B i t f e l d a u f nehmen. c) E r w e i t e r u n g e n bei der S t r u k t u r - D e k l a r a t i o n In der S y s t e m - P r o g r a m m i e r u n g t r i t t h&ufig der Fall auf, dab d a s s e l b e B i t m u s t e r - d . h . e i n b e s t i m m t e r interner Wert - auf v e r s c h i e d e n e A r t e n i n t e r p r e t i e r t werden muB. Ein solches P r o b l e m k6nnte auch m i t H i l f e der A L G O L 6 8 - " u n i o n s " nicht g e l 6 s t w e r d e n , da hier Wert und m o d e des Wertes fest aneinander g e k o p p e l t s i n d . A l s B e i s p i e l dafQr soil d i e interne D a r s t e l l u n g e i n e s r e a l - W e r t e s b e t r a c h t e t werdeno E i n mal w i r d der r e a l - W a r t in irgendwelchen r e a I - O p e r a t i o n e n a l s Ganzes v e r a r b e i t e t - a n d e r e r s e i t s mu8 bei der Oodierung yon Oonvertierungen integral nach real der interne Wert (bestehend aus V o r z e i c h e n , E x p o n e n t , M a n t i s s e ) a u f g e b a u t werden k6nnen. In SL3 s i n d dazu innerhalb der S t r u k t u r d e k l a r a t i o n A d j u s t m e n t s der e i n z e l n e n K o m p o n e n ten zueinander m ~ j l i c h ~ so dab o b i g e s P r o b l e m dutch f o l g e n d e S t r u k t u r d e k l a r a t i o n g e l 6 s t warden k6nnte : STRUOT ( R E A L R, ADR ( R , O , O )
LBIT1 V O R Z , L B I T 7 E X P ,
LBIT24 M A N T ) X~
In o b i g e m B e i s p i e l wQrde unter der V o r a u s s e t z u n g , dab zur internen D a r s t e l l u n g e i n e s r e a l - W e r t e s 32 B i t ben~tigt w a r d e n , das der S t r u k t u r X zugeordnete B i t f e l d w i e f o l g t a u f g e t e i l t werden:
52O
J~
R
11
X
,
~1
18
.......32
i VORZ Unter Benutzung der S e l e k t i o n X . R ( n i c h t R OF X w i e in ALGOL68) k6nnte der R e a l Wert als Ganzes v e r a r b e i t e t w e r d e n , unter Verwendung der Obrigen S e l e k t o r e n kSnnen d i e T e l l - B i t f e l d e r e i n z e l n angesprochen w e r d e n . D ieses Vorgehen hat den entscheidenden V o r t e i l , dab d i e Mode-PrOfungen w e i t e r h i n zur O o m p i l e z e i t ausgefQhrt werden kSnnen, w~ihrend andere Vorschl&ge [ 3 ] [ 5 ] einfach d i e m o d e - Z u o r d n u n g zu e i n e m internen Wert Andern. D a m i t w i r d abet ein m o d e - T e s t zur Oompilezeit unm~jlich gemacht. d) Generatoren Um eine M S g l i c h k e i t zu haben, S p e i c h e r z e l l e n auch ohne Z u h i l f e n a h m e des S t a c k M e c h a n i s m u s zu a d r e s s i e r e n , wurde der STAT1O-Generator.geschaffen. E i n i m S T A T I C Bereich g e n e r i e r t e s Objekt hat S p e i c h e r p l a t z m i t einer Lebensdauer, d i e g l e i c h ist der Lebensdauer des g e s a m t e n M o d u l s . Der G O l t i g k e i t s b e r e i c h des I d e n t i f i e r s r i c h t e t s i c h jedoch nach der Qbl ichen A b s c h n i t t s s t r u k t u r . -X STATIC LONG tNT L ; FOr b e s t i m m t e Z w e c k e der S y s t e m p r o g r a m m i e r u n g ist es n o t w e n d i g , R e g i s t e r aus d e m R e g i s t e r s a t z der M a s c h i n e d i r e k t anzusprechen [ 14]. Der Generator REG hat bis auf die andere p h y s i k a l ische S p e i c h e r p l a t z z u o r d n u n g d i e s e m a n t i s c h e Wirkung des LOCALGenerators. Verboten ist jedoch d i e Erzeugung e i n e r Referenz a l s Wert auf e i n e m i t R E G Generator erzeugte V a r i a b l e . REG INT I : = 3~ AI s w e i t e r e r Generator ware der G LOBA L-Generator zu erwAhnen, d e r e s e r l a u b t , E x t e m bezL~ge z w i schen get rennt Qbersetzbaren Modu I n zu d e k l a r i e r e n . E i n vergl e ichbares S p r a c h e l e m e n t findet s i c h z . B . auch in P E A R L [63 . GLOBAL PROC R = (INT X, INT Y ) BEGIN . . . . . . . . .
END
tm B e i s p i e l w i r d d i e Prozedur R a l s E n t r y - P o i n t for andere, getrennt Obersetzte Moduln dek I a r i e r t . -)e Ein A b s c h n i t t e n t s p r i c h t i m wesentl ichen d e m " B l o c k " h e r k S m m l i c h e r P r o g r a m m i e r sprachen.
no restriction
return-jumps, jumps to label constants or variables, label is a separatemode
possible by adjustment of structure elements
present
jumps to label constants
impossible
changes
many implicite
~LGOL68
Abb. 1:
only very primitive constructs (conditional jumpsetc.) collateral elaboration
0
m
!
erg~nztdurch SL3)
+ unary operators of machineassemblylanguageare realized as built-in-functions
[
if- and case-statements, do-loops, serial elaboration I no collateral elaboration I collateral elaboration
Vergleich der Sprachelementevon Assemblersprachen-L-~L~.ALGOL68(each [3]
control constructs
dosed procedureswith par~neter passing mechanism~proceduresare modes speCoSUbr.: openproc coproc l spec.subro;procn~ subr~ procinl I
only unary operators~ unary and binary operations on data of all modes, new operators are declarable operands have prim.mr spec.operat.far spec. Lo-eodes specoaperat,for spec. SL3-modes + I no types
I
I
unrestricted composition cycle, lab.el
operations
spec.modes: ~
only closed subroutim without parameter passing mechanism
spec.modes:free, t~ble, s t a c k
subroutines
restricted composition
variety of data-types (modes), newmodesare declarable
rather primitive
no types~ or only
data types
hardly possible
only leave-and returniumps, other jumps are ,rivileged
available by meansof the "mode"free
types~ no t y p e declaration
not possible
unrestricted
possible
formulas
nesting of
jumps
type-free data-handling
some implicite changes
only explicite changes
none
$L3
changes
i
I
o
L
mode
structure
block
assembly language
kJ~ Ix5
522
Es s i n d noch e i n i g e z u s & t z l i c h e Spracherweiterungen vorhanden, auf d i e hier nicht w e i tar eingegancjen warden soil I'7] • S i e ergeben sich z . T . aus den aufgefL)hrten B e i s p i e l e n . So warden in SL3 d i e W o r t s y m b o l e der Sprache nicht dutch Sonderzeichen b e g r e n z t , sondarn sind ats S c h l Q s s e l w o r t e m i t der S y n t a x einea tags r e s e r v i e r t . ( s t a r t ' B E G I N ' a l s o einfach BEGIN oder auch $ (
)
A b b . 1 z e i g t einen V e r g l e i c h von SL3 m i t ALGOL68, L ° ~_3] und A s s e m b l e r s p r a c h e n °
DER INTEGRIERTE A S S E M B L E R Durch E infQhrung der M~Sglichkeit, S p e i c h e r p l a t z fQr V a r i a b l e i m A r b e i t s r e g i s t e r s a t z der M a s c h i n e zu d e k l a r i e r e n , s i n d unter Benutzung der n o r m a l e n a l g o r i t h m i s c h e n S c h r e i b w e i s e schon fast a t l e MScjlichkeiten der A a s e m b l e r p r o g r a m m i e r u n g vorhanden. S o i l j e doch aus b e s t i m m t e n GrQnden e i n m a l eine ganz b e s t i m m t e B e f e h l s f o l g e erzeugt warden, so w a r m a n in den b i s h e r i g e n h6heren P r o g r a m m i e r s p r a c h e n gezwungen~ A s s e m b l e r e i n sch(Jbe zu g e s t a t t e n , d i e jedoch O p t i m i e r u n g e n dutch den C o m p i l e r Qber den E i n s c h u b h i n w e g ausschlosaeno In SL3 s i n d d i e e i n z e l n e n M a s c h i n e n b e f e h l e a l s l n t r i n s i c - P r o z e duren in den e r w e i t e r t e n S t a n d a r d - P r e l u d e a u f g e n o m m e n ° Die W i r k u n g s w e i s e soil an f o l g e n d e m B e i s p i e l erl&utert werden: INT A , B , C ;
(1) A : = B+O; In ( 1 ) ist in L)blieher N o t a t i o n d i e A d d i t i o n von B und C m i t Z u w e i s u n g des E r g e b n i s s e s an A d a r g e s t e l l t . E i n e entsprechende B e f e h l s f o l g e kann dutch Anwendung der i n t e g r i e r ten A s s e m b l e r s c h r e i b w e i s e erzeugt warden: INT A , B , C ;
REG INT H;
LD ( H , C ) ; AD ( H , B) ST ( A , H ) ; In ( 2 ) w i r d zus~itzlicld eine temporSre H i l f s z e l l e H i m
(2)
R e g i s t e r s a t z d e k l a r i e r t . Durch A u f -
ruf der I n t r i n s i c - P r o z e d u r e n LD, A D , ST w i r d e i n Lade, A d d i e r e - b z w . S p e i c h e r e - B e fehl g e n e r i e r t . FQr aliases v e r g l e i c h s w e i s e e i n f a c h e B e i s p i e l w i r d m a n k a u m d i e k o m p l i z i e r t e S c h r e i b w e i s e nach ( 2 ) anwenden. Diese ist eher fQr M a s c h i n e n b e f e h l e g e d a c h t , d i e auch dutch opt i m ierende Codegeneratoren schwer errei chbar s i nd, z . B . B i t - C o u n t - Befehl e u . a .
523
IMPLEMENTIERUNG Da der C o m p i l e r fQr SL3 auf k l e i n e r e n A n l a g e n ( n i c h t m e h r a l s 64K B y t e + H i n t e r g r u n d s p e i c h e r ) tauff&hig s e i n s o i l , w u r d e eine Z e r l e g u n g in mehrere S e g m e n t e g e p l a n t . U m nicht h~ufige S e g m e n t w e c h s e l durchfQhren zu mQssen, w u r d e e i n S e g m e n t i d e n t i s c h g e s e t z t n i t e i n e m Lauf. Dadurch, dab yon vornherein mehrere L&ufe g e p l a n t w a r e n , b e r e i tet
d i e A b a r b e i t u n g r e k u r s i v e r m o d e - D e k l a r a t i o n e n u . & . k e i n e S c h w i e r i g k e i t e n ° Es w e t -
den zur Ubersetzung e i n e r Quel le i n s g e s a m t 6 LAufe Qber der g e s a m t e n Q u e l l e d u r c h g e fQhrt a) l e x i k a l i s c h e A n a l y s e
2 L~ufe
b) S y n t a x - A n a l y s e
2 L&ufe
c) C o d e - G e n e r i e r u n g
2 LAufe
AlleOompiler-Teile
sind zun&chst i n e i n e r P i l o t v e r s i o n codiert in B C P L [ 1 0 ] ,
eine
z w e i t e V e r s i o n -. g e s c h r i e b e n in SL3 - ist in Vorbereitung; d i e s e Version kann dann schon d i e v o l l e Sprache SL3 ausnutzen und w i r d daher kQrzer und e f f e k t i v e r s e i n . Vor Beginn der I m p l e m e n t i e r u n g w u r d e d i e S y n t a x von SL3 n i t H i l f e e i n e s Parsergenerators ( n a c h [ 15] ) auf ihre 0 b e r s e t z b a r k e i t geprQft. 1) L e x i k a l i s c h e A n a l y s e Es n a g zun&chst verwundern, dab fQr d i e l e x i k a l i s c h e A n a l y s e 2 L~ufe b e n 6 t i g t w e r d e n . Es w u r d e jedoch e i n Tell der A L G O L 6 8 - s p e z i f i s c h e n l d e n t i f i z i e r u n g s p r o b l e m e in den 2. Lauf der l e x i k a l i s c h e n A n a l y s e v e r l e g t , so dab d i e S y n t a x - A n a l y s e w i e fQr eine norm a l e nicht e r w e i t e r b a r e k o n t e x t f r e i e Sprache ablaufen kann. D a m i t e r g i b t s i c h f o l g e n d e S t r u k t u r der b e i d e n L&ufe der l e x i k a l i s c h e n A n a l y s e : i)
1. Lauf l e x i k a l . A n a l y s e
Es werden a t l e S y m b o l e der S p r a c h e , d i e in Form yon S o n d e r z e i c h e n oder S c h l Q s s e l worten e x i s t i e r e n , erkannt° D e n o t a t i o n s yon a r i t h m ° und l o g . Werten werden durch ein S y m b o l n i t z u g e h 6 r i g e m Wert in I n t e r n d a r s t e l l u n g Qbernommen. A l l e N o n t e r m i n a l s ~ d i e d e r S y n t a x e i n e s tags genQgen~ w e r d e n dutch e i n e i n z i g e s S y m b o l n i t V e r w e i s auf e i n e S y m b o l t a b e l l e d a r g e s t e l l t ° A I s E r w e i t e r u n g gegenQber g&ngigen Verfahren d. l e x . A n a lyse t r i t t h i n z u , dab a l l e dutch m o d e - D e k l a r a t i o n e n oder p r i o r i t y - D e k l a r a t i o n e n e i n g e fQhrten neuen l n d i c a n t s ( d i e d i e S t e l l u n g yon zus&tzl ichen neuen SchlQssetworten e i n nehmen) in eine A b s c h n i t t s - s t r u k t u r i e r t e i n d i c a n t - L i s t e e i n g e t r a g e n w e r d e n ~
*
Bei p r i o r i t y - D e k l a r a t i o n e n w i r d auch d i e P l i o r i t ~ t
des Operators n o t i e r t .
Dazu muB
524 in der l e x i k a l ischen A n a l y s e schon d i e A b s c h n i t t s s t r u k t u r der Quel le erkannt w e r d e n . Dam i t ist d i e d e f i n i n g o c c u r r e n c e b z g l , der neuen i n d i c a n t s a b g e a r b e i t e t . i i ) 2. Lauf l e x i k a t . A n a l y s e Es werden a l l e S y m b o l e m i t der S y n t a x eines tags b e t r a c h t e t . S t i m m t e i n solches S y m bol innerhalb des betreffenden G Q I t i g k e i t s b e r e i c h e s ( s c o p e ) m i t e i n e m m o d e - oder o p e r a t o r - i n d i c a n t Qberein, so w i r d eine entsprechende S u b s t i t u t i o n durchgefQhrt; d . h ° d i e appl ied o c c u r r e n c e w i r d e r k a n n t . D a m i t ist e i n GroBteil der A L G O L 6 8 - s p e z i f i s c h e n ] d e n t i f i z i e r u n g s p r o b l e m e gelSst [8] , d i e m i t der IEinfQhrung neuer i n d i c a n t s und deren t e x t l i c h e r P o s i t i o n in der Q u e l l e z u s a m m e n h&ngen. ( Z . B .
a p p l i e d occurrencebei nachfolgender d e f i n i n g o c c u r r e n c e ) .
2) S y n t a x a n a l y s e Die S y n t a x a n a l y s e besteht i m wesentl ichen aus zwei L&ufen: i) ii)
Syntaxlauf Modelauf
Input der S y n t a x a n a l y s e ist eine K e t t e yon B a s i s s y m b o l e n , w e l c h e d i e l e x i k a l i s c h e A n a l y s e l i e f e r t . Der Output der S y n t a x a n a l y s e besteht aus e i n e m P l e x (&hnlich d e m P l e x , w i e er i m B O P L - O o m p i l e r [ 10] verwendet w i r d ) s o w i e e i n e m L i s t e n w e r k , in d e m j e d e s d e k l a r i e r t e Objekt s o w i e j e d e r in der Q u e l l e d e k l e r i e r t e m o d e oder Operator v e r zeichnet ist. i) Der S y n t a x l a u f Dieser Lauf fOhrt d i e s y n t a k t i s c h e A n a l y s e der angebotenen B a s i s s y m b o l k e t t e durch und baut das L i s t e n w e r k und einen P l e x (&hnlich w i e in [ 10] ) zun&chst ohne BerQcksichtigung der m o d e s auf. Grundlage d i e s e s Laufs ist ein t o p - d o w n arbeitender E B N F - P a r s e r [ 9 ] , der w e i t g e h e n d f o r m a l aus e i n e r k o n t e x t f r e i e n E B N F - S y n t a x yon SL3 p r o g r e m m i e r t w u r d e . Die S y n t a x von SL3 besteht in tier k o m p r i m i e r t e n E B N F - N o t a t i o n aus nur 25 Produktionen, so dab entsprechend nur e b e n s o v i e l e Parserprozeduren notwendig s i n d . Die Erzeugung d i e ses Parsers soil g l e i c h z e i t i g e i n e S t u d i e zur a u t o m a t i s c h e n Erzeugung von E B N F - P a r s e r n d a r s t e l l e n . T e r m i n a l s der erw~,hnten S y n t a x s i n d d i e v o n d e r l e x i k a l ischen A n a l y s e g e l i e ferten B a s i s s y m b o t e . Der Parser w i r d m i t der f o r m a l e n E r r o r - r e c o v e r y - M e t h o d e nach Bock [ 11] ausgerQstet, d i e b e r e i t s an B e i s p i e l e n erprobt i s t . In das P a r s e r - P r o g r a m m wurden S e m a n t i k - A k t i o n e n ad hoc eingefQgt, d i e folgende Aufgaben e r l e d i g e n : c~) E r s t e l l u n g des P l e x Die Methode dafQr ist e b e n f a l l s in [ 9 ] b e s c h r i e b e n . Der entstehende P l e x ist aber noch nicht bezQgl ich der m o d e s und der O o e r c i n g - Z u l & s s i g k e i t gepr~Jft° Femer sind
525
in d i e s e m P l e x d i e Operationen noch nicht bezQglich des m o d e s der Operanden i d e n tifiziert. B) Aufbau des L i s t e n w e r k e s Jedes in der Q u e l l e d e k l a r i e r t e Objekt enth< einen E i n t r a g in das sog. I d e n t i t 6 t s AdreBbuch. 1st der m o d e des O b j e k t e s kein p r i m i t i v e r m o d e , so w i r d for diesen m o d e ein m o d e - A d r e B b u c h e l e m e n t a n g e l e g t . Auch jeder in der Q u e l l e deklarierte~ d . h . neu eingefOhrte m o d e erh~lt eine m o d e - A d r e B b u c h e i n t r a g u n g . A n s c h l i e B e n d an den S y n t a x l a u f werden in zwei Z w i s c h e n p h a s e n C o m p i l e z e i t a u s d r 0 c k e berechnet s o w i e eine kanonische m o d e - R e d u k t i o n durchgefQhrt ( d . h . O b j e k t e m i t g l e i chem m o d e v e r w e i s e n auf d a s s e l b e m o d e - A d r e B b u c h - E l e m e n t ) . i i ) Der M o d e l a u f D ieser Lauf fOhrt f o l g e n d e Aufgaben durch: a) t d e n t i f i z i e r u n g der Operatoren nach d e m m o d e ihrer Operanden. b) E i n t r a g yon V e r w e i s e n auf das I d e n t i t ~ t s - A d r e B b u c h a n s t e l l e der B e z e i c h n e r , S e l e k toren oder O p e r a t o r - l n d i c a n t s i m P l e x . c) Test auf E i n h a l t e n der m o d e - B e d i n g u n g e n unter E i n b e z i e h u n g e t w a e r f o r d e r l i c h e r und zu~&ssiger C o e r c i n g s . D i e s e Aufgaben werden gelSst durch i n t e r p r e t a t i v e AusfQhrung des P l e x e s b e z 0 g l i c h der m o d e s derart, dab d i e I n t e r p r e t a t i o n e i n e s P l e x - K n o t e n s a l s Resuttat den m o d e a b l i e f e r t , den der Knoten zur Laufzeit liefern w i r d . Die PrQfung auf C o e r c i n g - M 6 9 1 i c h k e i t w i r d d a bei m i t durchgefQhrt. Das C o e r c i n g s e l b s t e r l e d i g t z . T . der C o d e - G e n e r a t o r . 3) O o d e - G e n e r i e r u n g Die C o d e - G e n e r i e r u 0 g a r b e i t e t in einer 0 b l i c h e n rekursiven Art F 12] [ 13] auf d e m P i e × . An z e n t r a l e r S t e l l e des C o d e - G e n e r a t o r s steht d i e R e g i s t e r - V e r w a l t u n g , d i e fQr eine opt i m a l e R e g i s t e r v e r g a b e zu sorgen h a t . Es w u r d e daf0r gesorgt~ dab jeder H a r d w a r e - B e f e h t unserer M a s c h i n e n generiert werden kann, f a l l s in der Q u e l l e e i n g e e i g n e t e r Operator b e nutzt w i r d - wobei d i e M S g l i c h k e i t e n des i n t e g r i e r t e n A s s e m b l e r s noch unberQcksichtigt sind° De SL3 fast a l l e S p r a c h k o n s t r u k t i o n e n b e s i t z t , w i e s i e auch andere hShere P r o g r a m m i e r sprachen b e r e i t s t e l l e n , wurde d i e Z w i s c h e n s p r a c h e ( L i s t e n w e r k u. P l e x ) so a l l g e m e i n k o n z i p i e r t , dab auch d i e C o m p i l e r anderer hSherer Sprachen ( z . B .
FORTRAN IV) in d i e s e
Z w i s c h e n s p r a c h e mQnden kSnnen. Die E n t w i c k l u n g d i e s e r Sprache wurde durch das B u n d e s m i n i s t e r i u m fQr Forschung und und T e c h n o l o g i e gefSrdert°
526
APPENDIX / ~ DEKLARATIONSTE I L -x-/ STATIC INT BVVARB~ BVVLP, BVVLK ~BVVLKP, BVVARI ~BVVBEL, BVLBEL~ BVVALB; STATIC LBIT32 BVVSPB; /-X-VARIABLE DER BVW-X-/ /-x-ES FOLGT DIE DEKLARATION DER LISTEN BVLPRO~ BVLTRA,BVLSPB~ BVLAUF IN FORM EINES GROSSEN FELDES, WOBEI JEDES FELDELEMENT IN DIE ENTSPR. 4TEILELEMENTE ZERFAELLT° JEDES DIESER 4 TEILELEMENTE IST STRUKTURIERT UND WIRD DUROH E1NE GETRENNTE MODE-DEKLARATION ALS EIGENER DATENTYP EINGEFUEHRT. DIE ABLAGE ERFOLGT NIOHT PLATZSPAREND, SONDERN Z E ITO PTIMAL.K-/ MODE LPRO = STRUOT (LBIT2 BELETYP,PROGTYP,LB1T1 PARB,LBIT3 AREAZAHL, LBIT5 SCHAETZW , A D J ( 2 , 0 ) LBIT16 STARTADR); /-X-ES WIRD ElM 32-BIT (DOPPEL-)WORT BELEGT; DUROH DEN ADJOPERATOR WIRD DAS STRUKTUR-ELEM.STARTADRESSE AUF EINE 16-BIT(WORT-) GRENZE GELEGT-X-/ MODE LTRA = STRUOT(LBIT1 NFTRA, A D J ( 1 , 0 ) LBIT24 EXTSPADR) /-X-ES WlRD ElM 32-BIT (DOPPEL-)WORT BELEGT; DAS STRUKTURELEMENT EXTSPADR BEG1NNT AUF ELMER BYT-GRENZE -X-/; MODE LSPB = STRUOT(LBIT1 AMAKRO,BELEGV,LBIT4 GESARBEDARF, A D J ( 1 , 0 ) LB1T24 SPBITMU) /-X-ES IST WIEDER ElM 32-BIT-ELEMENT VORGESEHEN, DAMIT KANN SPAETER OPTIMALER ZUGRIFF REALISlERT WERDEN-X-/; MODE LAUF = STRUCT (STRUOT(LBIT5 RETTIND,ARINDTRANS ,LBIT1 UPBESETZT, U PAUFERFOLGT) UPj A D J ( 0 , 0 ) STRUOT(LBIT6 ARINDDPAUF~LBIT3 DPANSTOSS, LB1T1 DPVERF~ DPITRANS) DP~ A D J ( 2 , 0 ) LB1T16 KETTZEIG); /-X-DIE BEIDEN STRUKTURELEMENTE U P , D P ( B E I D E SELBST WlEDER STRUKTUREN) SIND DUROH DEN ZW1SCHENGEFUEGTEN A D J ( 0 , 0 ) AUFE1NANDERGELEGT WORDEN. INSGESAMT WIRD WIEDER ElM 32-BIT(DOPPEL-)WORT BEANSPRUCHT -x-/ /-x- IDENT1TAETS-DEKLARATION DER PROGRAMMLISI'E-x-/ STATIC ( B VL) r 0 ; PROGANZ] STRUCT(LPRO BVLPRO,LTRA BVLTRA,LSPB BVLSPB,LAUF BVLAUF, A D J ( 0 , 0 ) LBIT16 PROBITS, PROSTART, LONG 1NT TRA1NF~ SPB1NF, LB1T16 LAUFBITS, AUFKETTZE1G) PROGLISTE; /-X-DIE EINZELNEN STRUKTURELEMENTE SlND DURCH LBIT16- BZW LONG 1NTELEMENTE UEBERLAGERT, UM SIE GETRENNT ALS LBIT16 BZW LONG-INTGROESSEN D1REKT ANSPREOHEN ZU KOENNEN. BE] PROB1TS UND LAUFBITS ERFOLGT DAMN KEINE SELEKTtON ~/
Abb. 2 Beispie! fQr Deklarationen in SL3
527
LITERATUR F 1]
Mark Rain, Some formal language aspects of MARY, Algol Bulletin 34, 1972, p. ,$5-80
[2]
I.F. Curie, S . G . Bond, J . D . Morison, ALGOL68-R, its implementation and use, IFIP71 - North-Holland Publ. Comp., 1972, 360-363
F3]
F. Geiselbrechtinger, W. Hesse, B. Krieg, H. Scheidig~Lo, The basic layer of the wide spectrum language L~G I-Tagungsbericht 8. - 10. Oktober 1973 Hamburg, Springer-Verlag, Bertin 1973, 188-197
r4]
A. Wijngaarden, B . J . Mailloux, J . E . L . Peck, C.HoA. Koster, Report on the Algorithmic Language ALGOL68, Num. Math. 14, 1969, 79
~-5]
H°D.Baecker, On a Missing Mode in ALGOL68j MOL Bulletin, 2. April 1973, 2.2.3
~-6]
PEARL, KFK-PDV-report 1, Ges. f . Kernforschung, Karlsruhe, W.-Germany, April 1973
[7]
D. DQrr, So Eichentopf, U. Prahl, G. Siegel, Syntax vo SL3, AEG-Telefunken, Technical report Berlin April 1973
[8]
Mailloux, On the implementation of ALGOL68, Akademo Proefschrift, Mathematische Centrum Amsterdam 1968
[9]
H. Bock, B. Schinzel, Strukturtreue Syntaxkompression und zugeh6rige Parserprozeduren~ G I-Tagungsbericht 7o-9. March 1972 SaarbrL~cken~ printed at Ges. f. Ivlathematik u. Datentechnik, St. Augustin, W.-Germany, 1972 141-163
[ 10] M. Richards, The BCPL Reference Manual Technical Memorandum Vo. 69/1, Univ. Cambridge, UK Math. Lab° [ 11] H. Bock, Error-Recovery in prozedurorientierter Syntaxanalysej Techn. report No° 12.032/73 AEG-Telefunken FI/UIm [ 12] J . P . Anderson, A note on some compiling algorithms CACM 7, March 1964, 149 ~-13] Io Nakata, On compiling algorithms for arithmetic expressionsj CAOM 10, Aug° 1967 492 r14] W . A . Wulf, D . B . Russell, A . N . Habermann, B l i s s : A language for System Prograrnming CACM 14, Dec. 1971, 780-790 [ 15] J. Loeckx, An Algorithm for the Construction of Bounded-Context Parsers CACM 13, May 1970~ 297-307
DER KERN EINES ALLGEMEINEN PEARL-BETRIEBSSYSTEMS H. B6smann, A. Tarabout
EINLEITUNG Die Entwicklung eines "Allgemeinen PEARL-Betriebssystems" erfolgt im Auftrag der Bundesregierung als ein Projekt von PDV
(Gesellschaft fur
Kernforschung) durch das EntwicklungsbHro Wulf Werum. Das Betriebssystem wird in PL/I programmiert und nach der Ubersetzung durch einen geeigneten Compiler in einer maschinenunabh~ngigen Zwischensprache
(ILl)
vorliegen. Die Wahl der Programmierhilfsmittel und die Festlegung der Schnittstellen des rechnerunabh~ngigen Betriebssystems zum Anwenderprogramm und zu rechnerspezifischen Teilen soll eine Anpassung des Systems an Einprozessoranlagen mit geringem Aufwand erm~glichen. Soweit hier vorgestellt, ist das Betriebssystem auf einer IBM-Anlage in simulierter Umgebung ausgetestet worden.
Zum Verst~ndnis der Ausf~hrungen ist die
Kenntnis von PEARL vorausgesetzt. Die Realisierung eines PEARL-Betriebssystems, die in diesem Vortrag teilweise behandelt ist, wird dem Anwender die MSglichkeit bieten, die Probleme der ProzeDautomation
(Messen, Steuern, Regeln)
in einer der
Problemste!lung angepaDten Art zu formulieren und dabei die M6glichkeiten des Rechensystems optimal auszunutzen.
CHARAKTERISTISCHE EIGENSCHAFTEN DES BETRIEBSSYSTEMS, Wir wollen erst die Hauptforderungen, die die Proze~- und Experimentautomation dem Betriebssystem stellt, kurz skizzieren: • Die zur Uberwachung und Steuerung von technisch-wissenschaft!ichen Prozessen eingesetzten Rechenanlagen sollen aufgrund von Meldungen aus diesem ProzeB in einer durch Programm bestimmbaren Weise reagieren. Dabei mud der Rechner meistens mit mehreren Vorg~ngen Nachrichten austauschen, und dar~berhinaus wird verlangt, dad er innerhalb kurzer Zeitspannen
(Rea~tionszeit) auf diese Meldungen reagiert. In
diesem Zeitraum ist die bisher bearbeitete Aufgabe zugunsten einer wichtigeren Aufgabe zur~ckzustellen und die neue Aufgabe fortzusetzen. • Charakteristisch fur ein ProzeDprogramm ist die Gliederung in mehrere Programme, die asynchron ablaufen sollen und die Synchronisierung dieser Abl~ufe. Eine h6here Programmiersprache zur Automation yon Prozessen und Experimenten zeichnet sich insbesondere dutch Anweisungen zur Steuerung und Synchronisierung der verschiedenen Programmabl~ufe
(Prozesse) aus.
529
Die B e d i e n u n g ablauf
der Ein- und A u s g a b e g e r ~ t e
erfolgen,
um die G e s c h w i n d i g k e i t
muB q u a s i p a r a l l e l
zum Rechen-
der P e r i p h e r i e g e r ~ t e
auszu-
nutzen. F~r eine g H n s t i g e
Benutzung
Hintergrundverwaltung Dem B e n u t z e r rithmen folgen
als H i l f s m i t t e l
eine P r o g r a m m i e r s p r a c h e ,
Bedingungen
folgende
die
der R e c h e n a ! g o -
parallele
Befehls-
nach p r o g r a m m i n t e r n e n
Die Sprache
PEARL bietet
und
zu d i e s e m
und der
Systemteil des P r o g r a m m s
wird, Synchronisiervariable,
Peripherieger~te
zur D e f i n i t i o n
zur S t e u e r u n g
der R e c h n e r k o n f i g u r a t i o n
in d e m s o g e n a n n t e n
fHr Prozesse,
ne Ereignisse,
tigen
die gestattet,
der B e s c h r e i b u n g
angegeben
- Anweisungen
zur B e s c h r e i b u n g
und ihre A u s f ~ h r u n g
zu steuern.
ProzeBperipherie,
- Oatentypen
und
Elemente:
- Die M 6 g l i c h k e i t
ausfOhrlich
ist eine D a t e i -
erforderlich.
zu b e s c h r e i b e n
~uBeren Zweck
dient
des A r b e i t s s p e i c h e r s
von P r o z e s s e n
von P r o z e s s e n
Zeitangaben,
exter-
und Dateien,
nach ~uBeren
und
ihrer A b h ~ n g i g k e i t e n
Bedingungen,
zur g e g e n s e i -
Synchronisierung,
- Anweisungen
zur U b e r t r a g u n g
Ein P E A R L - B e t r i e b s s y s t e m zeitbedingungen
von ProzeBdaten.
m u B also den M e h r p r o g r a m m b e t r i e b
in der d u r c h die
Semantik
vorgeschriebenen
unter Weise
Echtge-
w~hrleisten.
AUFGABENBEREICHE
DES
BS-KERNS,
BETRIEBSZIELE
Der Kern des P E A R L - B e t r i e b s s y s t e m s
l~st
folgende
Aufgaben:
• die P r o z e B s t e u e r u n g Kreieren
eines P r o z e s s e s
RechenprozeB Starten
eines
Verz~gern
Beenden malen
Endes
beitung
von
Prozesses
Prozesses
m i t SUSPEND
in dem ein
oder
"Schedule" RESUME,
m i t CONTINUE,
mit TERMINATE
oder beim E r r e i c h e n
des nor-
des Prozesses.
der O N - A n w e i s u n g e n
Schedule-Angaben)
• die A u s p l a n u n g
in den Block,
ist,
mit ACTIVATE,
Prozesses
eines
eines
• die K o p p e l u n g
Prozesses
eines
Fortsetzen
beim Eintritt
als TASK v e r e i n b a r t
der
bzw.
Steueranweisungen
an ~uBere Meldungen.
Steueranweisungen
mit PREVENT.
(durch B e a r -
53O
. das Registrieren von Meldungen und Ausf~hrung bzw. Einleitung aller daran gekoppelten Steueranweisungen oder ON-Anweisungen. • die Synchronisierung der ProzeBabl~ufe ~ber Synchronisiervariable (SEMA, BOLT) mit Hilfe yon Synchronisieranweisungen: Sperren mit REQUEST,
RESERVE, ENTER,
Sperre aufheben mit RELEASE, FREE, LEAVE. . die Kontrolle der ProzeSdatenHbertragung
(MOVE)
gem~B der im System-
teil beschriebenen Kanalstruktur. Dabei sind kurze Reaktionszeiten und hohe VerfHgbarkeit des Systems anzustreben,
d.h. das System ist fast immer bereit,
empfangene Meldun-
gen sofort zu verarbeiten und reagiert in m6glichst kurzer Zeit.
DATENSTRUKTUREN ZUM BETRIEBSSYSTEM Die Datenstrukturen, werden,
die vom Betriebssystem aufgebaut und angesprochen
sind in Bild I in soweit dargestellt,
nis der Betriebssystem-Funktionen
sI=AL A
wie dies zum Verst~nd-
n~tig ist.
)
PKS
S
SEMA BOLT
~ Bild 1: Datenstrukturen
m
531
Mit dem Symbol
>>(Vielfach-Pfeil)
w i r d angedeutet,
dab an der ange-
zeigten Stelle eine Kette bzw. W a r t e s c h l a n g e yon D a t e n s t r u k t u r e n gleicher Art beginnt. FUr jeden P r o z e B e x i s t i e r t ein ProzeBkontrollsatz
(PKS) m i t A n g a b e n
Laufzeitkeller (LZK), W i e d e r a n l a u f p u n k t , belegte Betriebsmittel. Alle PKS sind
Uber seinen Zustand,
seine Stellung in der P r o z e B h i e r a r c h i e ,
nach ihrer P r i o r i t ~ t verkettet. gesperrtes Betriebsmittel
Der PKS eines Prozesses,
z u g e g r i f f e n hat,
der auf ein
steht his zu dessen F r e i g a b e
in der e n t s p r e c h e n d e n W a r t e s c h l a n g e . Die D a r s t e l l u n g yon Synchronisiervariablen (BOLT- und SEMA-Variablen) b e s t e h t aus Z~hlern und H i n w e i s e n auf W a r t e s c h l a n g e n . A u f g r u n d von Bedingungen,
unter denen P r o z e B s t e u e r a n w e i s u n g e n
fHhren sind, w e r d e n e n t s p r e c h e n d e Einplankontrollsdtze
(EPS)
auszuf~r den
b e t r o f f e n e n P r o z e B e r z e u g t und bei den g e n a n n t e n E r e i g n i s v a r i a b l e n ang e k e t t e t bzw.
in eine Z e i t k e t t e eingeordnet.
Erei~nisvariable (ER) fUhren I n f o r m a t i o n e n ~ber den E i n t r i t t von M e l d u n g e n und w e i s e n auf die Kette der z u g e o r d n e t e n E i n p l a n k o n t r o l l s ~ t z e . Im S y s t e m t e i l des P r o g r a m m s wurde die V e r b i n d u n g zu einer A n s c h l u B stelle definiert. Die Zeitkontrollsdtze
(ZK) - da PEARL Dauer- und U h r z e i t a n g a b e n ver-
schieden interpretiert,
gibt es zwei Z e i t k e t t e n im System - e n t h a l t e n
Z~hler zum M e s s e n yon D a u e r n und Uhrzeiten,
einen Hinweis auf die War-
t e s c h l a n g e der z u g e o r d n e t e n E i n p l a n k o n t r o l l s ~ t z e und einen Zeiger auf den als n ~ c h s t e n zu b e a r b e i t e n d e n EPS. F~r E i n - A u s g a b e v o r g ~ n g e
stehen Gerdtekontrolls~tze
(GKS)
zur VerfUgung.
GKS und B e s c h r e i b u n g s l i s t e n der K a n a l s t r u k t u r fur die P r o z e B d a t e n H b e r tragung w e r d e n n a c h den A n g a b e n des S y s t e m t e i l s aufgebaut. GKS sind die g e r ~ t e s p e z i f i s c h e n
Uber einen
I n f o r m a t i o n e n wie Status, 0 b e r t r a g u n g s -
art und Treiber zug~nglich.
HIERARCHIE DER ARBEIT IM RECHNER Das B e t r i e b s s y s t e m l~Bt die R e c h e n o p e r a t i o n e n auf drei Ebenen ablaufen, indem es seine V e r w a l t u n g s t ~ t i g k e i t e n h i e r a r c h i s c h
zwischen die R e a k t i o n
auf M e l d u n g e n und die A u s f U h r u n g des A n w e n d e r p r o g r a m m s einordnet.
Da-
mit wird erreicht, dab der Rechner in jedem Fall i n n e r h a l b e i n e r gew i s s e n V e r z ~ g e r u n g s z e i t die R e a k t i o n auf eine M e l d u n g b e g i n n e n kann und a n d e r e r s e i t s b e s t i m m t e V e r w a l t u n g s a r b e i t e n u n g e s t S r t zu Ende fUhren kann.
532
Bild 2 zeigt die Untergliederung der Betriebssystemaufgaben und die Hierarchie der Rechenvorg~nge. Nach Eintritt einer Meldung wird in der Unterbrechungsebene die laufende Arbeit angehalten und der Punkt, an dem sie fortzusetzen ist, definiert. Danach wird festgestellt, welche Ereignisse Meldungen verursacht haben, um das System zu spezifizierten Reaktionen zu veranlassen. Die Entgegennahme einer Meldung wird nicht durch die einer anderen unterbrochen. Die Bearbeitung yon Unterbrechungen ist die wichtigste Aufgabe in der Bearbeitungshierarchie, da dadurch die momentane Arbeit in anderen Ebenen beeinfluSt werden kann und wichtigere als zuvor zu bearbeitende Prozesse lauff~hig gemacht werden k6nnen. Auf der Verwaltungsebene
erfolgt die ProzeBsteuerung, die ProzeSsyn-
chronisierung und die Verwaltung der Betriebsmittel. Es wird sichergesteilt, dab kein Wechsel yon Rechenprozessen (Aufnehmen eines anderen wichtigeren Prozesses)
stattfindet, solange sich die Bear-
beitung in der Verwaltungsebene befindet, damit Betriebssystemfunktionen nicht zu Zeitpunkten, in denen Datenstrukturen in einem nicht definierten Zustand sind, unterbrochen werden und evtl. unter Kontrolle eines anderen Prozesses auf eben diesen Datenstrukturen zu arbeiten versuchen. Jede dieser Systemfunktionen ist logisch unteilbar, d.h. ihre Befehlsfolge kann zwar durch Arbeit auf der Unterbrechungsebene unterbrochen werden; danach wird sie aber auf jeden Fall vor weiteren Systemfunktionen zu Ende gef~hrt. Diese Systemfunktionen werden unter Regie yon Prozessen
(Anwenderprozesse oder vom Betriebssystem kreierte Pro-
zesse) ausgef~hrt. Auf der Anwenderebene wird das Anwenderprogramm ausgef~hrt. Der Rechner arbeitet solange auf der Anwenderebene bis entweder eine Meldung ihn auf die Unterbrechungsebene anhebt oder nach Aufruf einer Systemfunktion durch den ProzeB auf der Verwaltungsebene fortgefahren wird. Um jeweils den dringlichsten ProzeB aufzunehmen, wird jedesmal beim Ende einer Systemfunktion, falls sich seit dem Verlassen der Anwenderebene das ProzeBprofil ge~ndert hat, wieder der wichtigste lauff~hige ProzeB bestimmt und aufgenommen.
BEARBEITUNG VON PROGRAMMUNTERBR£CHUNGEN Um die oben erw~hnten Bedingungen
(Programmablauf in m~glichst wenigen
und zeitlich kurzen Abschnitten nicht unterbrechbar halten; Reaktion auf Unterbrechung m~glichst schne!l anfangen)
in unserem PEARL-Betriebs-
system zu erfHllen, ist die Bearbeitung einer Unterbrechung in zwei
ProzeBpeiipherie
If
iiiiii!iiiiiii;
I
ProzeBvereinbarung
Bild 2: Hierarchie der Rechenvorg~ng£
ANWENDEREBENE
"SCHEDULE" i ON PREVENT
ACTIVATE REQUEST CONTINUE RESERVE ProzeBende ENTER
Anwenderprogramm
TERMINATE SUSPEND RESUME
falls keine Sekund~rreaktion
RELEASE FREE LEAVE
r
I MOVE
AnstoB von Datentransfer
E/A-Verw@ltung----
Koppelung bzw. Entkoppelung Kreieren Ausf~hrung der 0N<-->SIGNAL eines ProzeB-SteuerEPS<-->Zeit/I~TERRUPT Pro~esses anweisungen Synchroni~ierung
SIGNAL-Bearbeitung
.......
Standard~eripherie
Empfang, Prim~rreaktion [Einleiten der ISekund~rreaktion]
"UNTERBRECHUNGSEBENE
Zei~takt
VERWALTUNGSEBENE
Betriebssystem
J
I L I I
Meldungen~
LD k~ k~
534
Phasen eingeteilt. Die erste Phase wird auf der Unterbrechungsebene, die zweite Phase auf der Verwaltungsebene ausgefHhrt.
REAKTION AUF DER UNTERBRECHUNGSEBENE, Beim Eintritt einer Me!dung werden folgende T~tigkeiten ausgefHhrt: I. Verbieten weiterer Unterbrechungen 2. Falls ein RechenprozeS unterbrochen wurde, wird der Rechnerstatus (Befehlsz~hler, Registerinhalte)
in dessen ProzeBkontrollsatz aus-
gelagert. 3. AusfHhrung der meldungsspezifischen Prim~rreaktion
(kurze Befehls-
folge) ; evtl. notieren, dab eine zugehSrige Sekunddrreaktion
aus-
zufHhren ist. 4. Erlauben weiterer Unterbrechungen. Falls in der Zwischenzeit
(nach
AusfHhren des I. Schritts) weitere Meldungen eingetroffen sind, wird der Ablauf mit dem I. Schritt wiederholt; in diesem Fall ist kein Rechnerstatus mehr in dem 2. Schritt auszulagern. 5. Falls keine Sekund~rreaktion f0r eingetroffene Meldungen ausgef~hrt werden muB, ist die Reaktion beendet; der unterbrochene ProzeB wird fortgesetzt. 6. Anderenfalls wird abgefragt, ob sich der unterbrochene ProzeB in Bearbeitung einer Systemfunktion befand; in diesem Fall wird die unterbrochene Systemfunktion zu Ende gefHhrt. Danach wird ein im System permanent existierender ProzeB zur DurchfHhrung von Sekund~rreaktionen aufgenommen.
SEKUND~RREAKTION AUF DER VERWALTUNGSEBENE. Der ProzeB zur DurchfHhrung yon Sekund~rreaktionen auf Unterbrechungen ist der wichtigste ProzeB im Laufzeitsystem. Unter seiner Regie werden zun~chst alle von Ger~temeldungen, danach alle vom Zeittakt und danach alle yon ProzeBunterbrechungen verursachten ~nderungen der Datenstrukturen durchgef~hrt. Dieses kann insbesondere zum Einplanen yon Reaktionen bei zuk~nftigen Ereignissen fOhren. Welter werden die evtl. eingeplanten Steueranweisungen bzw. ON-Anweisungen durchgef~hrt oder soweit eingeleitet, dab sie unter Regie des betroffenen Prozesses fortgesetzt werden k~nnen. Da die Sekund~rreaktion im allgemeinen das Proze~profil ~ndert, wird bei Ubergang auf die Anwenderebene der wichtigste,lauff~hige ProzeB gesucht und mit seiner Bearbeitung begonnen.
535
EINPLANUNG EINPLANUNG V0N STEUERANWEISUNGEN, In PEARL k6nnen ProzeBsteueranweisungen unter Startbedingungen ("SCHEDULE") gestellt werden. Einplanungen werden realisiert,
indem beim Uberlaufen
Startbedin~un~en
Steueranweisun 9 ProzeB
fHr den ProzeB und die Steueranweisung iert wird, der alle Informationen sprechenden
Warteschlangen
gekettet wird;
einer Anweisung der Form [Optionen];
ein Einplankontrollsatz
des "SCHEDULE"
(Zeit- oder ProzeBunterbrechungskette)
im Kopf jedes EPS wird notiert, eingerichtet,
ordnung in die geeignete Warteschlange,
ist. Unter dem EPS-
die, neben den Daten zur Ein-
einen Hinweis auf das System-
das nach Eintritt der betreffenden
Rahmen der Sekund~rreaktion Organisation
ein-
welche Steueranweisung
f~r welchen ProzeB mit welchen Optionen eingeplant Kopf werden Einplanelemente programm enthalten,
EPS kre-
enth~it und in die ent-
Unterbrechung
im
aufgerufen werden muB. Im Bild 3 ist diese
skizziert.
PKS des betroffenen Prozesses EPS KOPF [Optionen]
ER-/Z~-
Warteschlange
};EINPLANELEMENT
ER-/ZKWarteschlange
/Programm zur AusfGhrung ~der Steueranweisung
/Programm zur Bearbeitung ~ des Einplanelementes (in | \ Sekund~rreaktion) und zum J \Aufruf der Steueranweisung / EINPLANELEMENT
Bild 3: Ein~lanun~ Wenn also eine Meldung auftritt, schiange bearbeitet,
der aufgenonmlen werden. Einplanelementes
wird die zugeh6rige
indem alle betroffenen
ER- oder ZK-Warte-
Einplanelemente
nacheinan-
Zuerst wird das Programm zur Bearbeitung
ausgef~hrt,
des
das evtl. weitere Ein- oder Ausplanungen
bestimmt und das wiederum das im Kopf des EPS notierte Programm
zur
536
A u s f ~ h r u n g der S t e u e r a n w e i s u n g aufruft;
diesem Programua sind die im
Kopf n o t i e r t e n A n g a b e n als P a r a m e t e r zur V e r f ~ g u n g gestellt.
EINPLANUNG V0N ON-ANWEISUNGEN, lichkeit,
Zn PEARL hat der P r o g r a m m i e r e r die M~g-
eigene R e a k t i o n e n auf S I G N A L - U n t e r b r e c h u n g e n einzuplanen.
B e i m U b e r l a u f e n einer O N - A ~ w e i s u n g w i r d im L a u f z e i t k e l l e r LZK des aktuellen P r o z e s s e s notiert, w e l c h e A n w e i s u n g nach E i n t r i t t w e ! c h e r SIGNALM e l d u n g a u s z u f ~ h r e n ist. Tritt eine S I G N A L - M e l d u n g ein,
so w i r d die
R e a k t i o n d u r c h U n t e r s u c h u n g des LZK bestimmt.
AUSPLANUNG V0N STEUERANWEISUNGEN.
Die A u s p l a n u n g yon S t e u e r a n w e i s u n g e n ,
d.h. das A u s k e t t e n jedes E i n p l a n e l e m e n t e s der E i n p l a n k o n t r o l l s ~ t z e , wird i n s b e s o n d e r e durch die P R E V E N T - oder die T E R M I N A T E - A n w e i s u n g im Anwenderprogram/n eingeleitet. W e n n eine P R E V E N T - A n w e i s u n g a u s z u f H h r e n ist, w e r d e n alle e i n g e p l a n t e n S t e u e r a n w e i s u n g e n fHr den b e t r o f f e n e n ProzeB erst neutralisiert,
indem im Kopf jedes EPS der Hinweis auf das
P r o g r a m m zur A u s f 0 h r u n g der S t e u e r a n w e i s u n g dutch den Hinweis auf das leere P r o g r a m m NOP ersetzt wird. Dadurch wird die A u s f 0 h r u n g der Steue r a n w e i s u n g verhindert,
falls die S t a r t b e d i n g u n g vor dem A b b a u des EPS
erf~llt ist. Das A u s k e t t e n und die F r e i g a b e des EPS, die ziemlich lang d a u e r n k6nnen, w e r d e n e i n e m im System p e r m a n e n t e n ProzeB zur D u r c h f ~ h rung von u n w i c h t i g e n T ~ t i g k e i t e n Hberlassen.
Dieser ProzeB l~uft nur,
wenn kein anderer ProzeB lauff~hig ist.
ARBEITSABWICKLUNG
AUF DER ANWENDEREBENE
Das in PEARL a n g e g e b e n e Konzept der P r i o r i t ~ t von P r o z e s s e n w i r d durch A u f b a u einer P r i o r i t d t s k e t t e yon P r o z e B k o n t r o l l s ~ t z e n realisiert, dab in der Sprache d e f i n i e r t e W i c h t i g e r - U n w i c h t i g e r - R e l a t i o n
so
zweier
Prozesse auf die V o r g ~ n g e r - N a c h f o l g e r - R e l a t i o n der e n t s p r e c h e n d e n PKS p r o j i z i e r t wird. Der w i c h t i g s t e ProzeB ist, wie schon erw~hnt, der ProzeB zur A u s f ~ h r u n g von S e k u n d ~ r r e a k t i o n e n auf U n t e r b r e c h u n g e n .
Sein PKS
(SEK) w i r d deswe-
gen am Kopf der P r i o r i t ~ t s k e t t e stehen. A n d e r e V e r w a l t u n g s a r b e i t e n des Betriebssystems
(wie F r e i g a b e einer u n b e n u t z t e n Datenstruktur,
lauf,wenn kein anderer ProzeB lauff~hig ist, ger als irgendeine sonstige T~tigkeit. Regie eines P r o z e s s e s ausgefOhrt,
Leer-
...) sind aber u n w i c h t i -
Solche A r b e i t e n w e r d e n unter
dessen PKS
(PRIOKE)
am Ende der Prio-
r i t ~ t s k e t t e steht. P r o z e B k o n t r o l l s ~ t z e von aktiven A n w e n d e r p r o z e s s e n w e r d e n zwischen SEK und P R I O K E in der P r i o r i t ~ t s k e t t e so eingeordnet,
537
dab aus ihrer S t e l l u n g ihre r e l a t i v e D r i n g l i c h k e i t a b g e l e s e n w e r d e n kann
(Bild 4).
SEK
PKS I
PKS2
PKSi
PRIOKE
Bild 4: P r i o r i t ~ t s k e t t e Die aktiven P r o z e s s e w e r d e n in lauff~hig oder b l o c k i e r t unterteilt, dem in ihren PKS entweder der A u f r u f eines S y s t e m d i e n s t e s des P r o z e s s e s
(im Bild 4 als "CALL A" bezeichnet)
die V e r k e t t u n g auf die e n t s p r e c h e n d e
in-
zur A u f n a h m e
oder der Sprung ~ber
Zelle des n ~ c h s t w i c h t i g e n PKS
(im Bild 4 als "GOTO *-->" bezeichnet)
e i n g e t r a g e n ist. Das A u f s u c h e n
des w i c h t i g s t e n l a u f f ~ h i g e n P r o z e s s e s wird d a d u r c h gel~st, dab nach dem e r s t e n Sprung in SEK die P r i o r i t ~ t s k e t t e
solange d u r c h g e s p r u n g e n wird,
bis im PKS des ersten lauff~higen Prozesses der Befehl
"CALL A" e r r e i c h t
wird.
PROZESSVERWAL.TUNG Durch P r o z e S s t e u e r a n w e i s u n g e n und S y n c h r o n i s i e r a n w e i s u n g e n kann in PEARL der P r o g r a m m i e r e r P r o z e s s e generieren, den.
verz@gern,
fortsetzen und been-
im Bild 5 sind die in P E A R L a n g e g e b e n e n A n w e i s u n g e n und ihre W i r -
kung auf den P r o z e S z u s t a n d zusammengefaSt. Die A u s f ~ h r u n g der P R E V E N T - A n w e i s u n g w u r d e im v o r h e r i g e n Kapitel erl~utert. Die SUSPEND-,
C O N T I N U E - und R E S U M E - A n w e i s u n g e n w e r d e n auf ein-
mal auf der V e r w a l t u n g s e b e n e ohne n e n n e n s w e r t e B e s o n d e r h e i t e n ausgefOhrt. Ein Proze8 kann v i e l f a c h b l o c k i e r t w e r d e n
(wenn z.B.
SUSPEND,
Startbe-
dingungen RESUME und eine S y n c h r o n i s i e r a n w e i s u n g zusammen auf ihn wirken). Um aus d i e s e m b l o c k i e r t e n Zustand h e r a u s z u k o m m e n , sprechenden A n w e i s u n g e n
zur F o r t s e t z u n g des P r o z e s s e s
m 0 s s e n alle ent(CONTINUE, RESUME-
S t a r t b e d i n g u n g erf~llt, F r e i g a b e der e n t s p r e c h e n d e n S y n c h r o n i s i e r v a r i a ble) vorkommen.
Sonst b l e i b t er blockiert.
538
Blockeintritt
if
•Blockaustritt (ProzeB unbekannt) e
PREVENT
annt
E"x n ~ "a n u /n g
ProzeB eingeplant, ~ bekannt i
•ACTIVATE
ProzeB aktiv, bek'annt [ ,eingeplant] RELEASE FREE LEAVE P rozeB lauff~hig,~ laktiv, bekannt CONTINUE I "eingeplant ] [ RESUME'Startbedingung]
_l t
erf~llt
Startbedingungen
I....
~RESUME SUSPEND
1
I
b oekier ,l
aktiv, bekannt
REQUEST RESERVE ENTER
ProzeBende
TERMINATE
Bild 5: Steuer- und Synchronisieranweisun~en KREIEREN UND AKTIVIEREN EINES PROZESSES, Zur Verwaltung des Prozesses benutzt das System einen ProzeBkontrollsatz (PKS), in dem alle Eintr~ge
vorgenommen werden, die zur Steuerung des Prozesses notwendig sind. Die Einrichtung eines ProzeBkontrollsatzes,
die Einbindung in die Hierarchie
der Prozesse und die Einkettung in die Priorit~tskette sowie die Aktivierungst~tigkeiten kosten aber Zeit. Wenn die Ausf~hrung der notwendigen Operationen auf einmal geschehen sollte, ~ r e
es unm~glich - da
solche Aufgaben auf der Verwaltungsebene logisch unteilbar sind - eine schnelle Reaktion auf eine wichtige Unterbrechung in der Anwenderebene zu gew~hrleisten. Deswegen wird das Kreieren und der Anlauf eines Pro-
539
zesses
in v i e r P h a s e n
• Beim Eintritt
geteilt:
in den Block,
wird S p e i c h e r p l a t z
in d e m der P r o z e B n a m e
fur den P r o z e 8 k o n t r o l l s a t z
ger auf den P r o z e B k o n t r o l l s a t z
dem P r o g r a m m
gabe des P r o z e B n a m e n s
Steueranweisung
kontrollsatz
Hber d i e s e n
• Wenn der Befehl Hberlaufen
wird
richteten
initia!isiert,
gung
erfHllt
ist.
Falls
puffert.
ist oder
der P r o z e B
Anderenfalls
ausfHhren
Sobald
unter
ini t i a l i s i e r t .
eingeordnet;
der P r o z e s s e
anderenfalls notiert.
wird der PKS mit dem schon
findet
statt,
falls keine
schon a k t i v
ist,
sobald
Falls einge-
eigenen
eine
Startbedin-
Startbedingung
eingeplant
notiert,
Regie die w e i t e r e n
Befehle
als w i c h t i g s t e r seiner
ProzeB
zum e r s t e n Mal
Regie der L a u f z e i t k e l l e r
D a n a c h wird die
E n d e s der
zugeh~rigen
ner T E R M I N A T E - A n w e i s u n g alle
eines
ben~tigt
Prozesses
sequentielle
aufgenommen
eingerichtet
Befehlsfolge
werden;
und
des Pro-
zu lang, w e n n
ist,
Bevor er b e e n d e t w e r d e n ebenfalls
beendet werden
die von k e i n e m
sein L a u f z e i t k e ! l e r
sein. alle
ei-
darf, Zum ihm
anderen mehr und sein Pro-
geschehen
indem das B e e n d e n
in f o l g e n d e
S c h ri t t e
aufgeteilt
falls keine
Regie des Prozesses,
sollte.
eines P r o z e s s e s
der T E R M I N A T E - A n w e i s u n g
der S e k u n d ~ r r e a k t i o n , unter
es fur ihn und seine u n t e r g e o r d n e -
auf der V e r w a l t u n g s e b e n e
die S t a r t b e d i n g u n g
im R a h m e n
werden
w i r d vermieden,
der T E R M I N A T E - A n w e i s u n g I. Sobald
Prozesse
freigegeben,
insbesondere
auf einmal
se S c h w i e r i g k e i t
werden.
des
oder d u r c h A u s f U h r u n g
vernichtet.
aber viel
ten P r o z e s s e
Befehlsfolge
m i t der T E R M I N A T E - A n w e i s u n g
Betriebsmittel
zeBkontrollsatz Dieses w ~ r e
beendet
ihm u n t e r g e o r d n e t e n
zugewiesenen
pl a n t
zum
ausgefHhrt.
logischen
Beenden
ge-
dab er !auf-
BEENDEN EINES PROZESSES, in P E A R L kann ein P r o z e B b e i m E r r e i c h e n
mHssen
ein-
erfolgt
wird die neue A k t i v i e r u n g
im PKS des P r o z e s s e s
seiner
ist - der
kann.
der P r o z e B wird
zesses
in die H i e r a r c h i e
[Optionen]; aktiv
verkn~pft.
sofort,
wird
D u r c h An-
jetzt der P r o z e B -
ProzeB
im PKS e n t s p r e c h e n d
sind,
des P r o z e s s e s
ist und unter
wird,
werden
angegeben
Einplankontrollsatz
. Die A k t i v i e r u n g
f~hig
ACTIVATE
- falls der ProzeB noch n i c h t
Optionen
Startbedingungen
zurHckgegeben. wird
ist,
und der Zei-
erreicht.
und in die P r i o r i t ~ t s k e t t e
Fehlermeldung.
Anlauf
Zeiger
[Startbedin~un~en]
wird,
ProzeBkontrollsatz gebunden
in einer
vereinbart
reserviert
Diemit
wird:
erfHllt
Startbedingung
ist, w i r d einge-
in d e m sich die T E R M I N A T E -
540
A n w e i s u n g befindet,
im P r o z e B k o n t r o l l s a t z des b e t r o f f e n e n Prozesses
und in den PKS der ihm u n t e r g e o r d n e t e n P r o z e s s e evtl.
in einer E X C E P T - O p t i o n
stehen)
notiert,
(auBer denen, die
dab die P r o z e s s e zu
beenden sind. Die p r o z e B z u g e h B r i g e n E i n p l a n b l ~ c k e w e r d e n n e u t r a l i siert
(wirkungslos).
2. Sobald ein solcher ProzeB als w i c h t i g s t e r a u f g e n o m m e n ist, wird folgendes ausgef0hrt: 2.1Der
PKS wird evtl.
aus SEMA- oder B O L T - W a r t e s c h l a n g e g e n o m m e n
und die n e u t r a l i s i e r t e n E i n p l a n b l S c k e w e r d e n dem u n w i c h t i g s t e n S y s t e m p r o z e B zum A b b a u Hbergeben. 2.2 Falls kein aktiver oder e i n g e p l a n t e r P r o z e B ihm u n t e r g e o r d n e t ist, wird sein L a u f z e i t k e l l e r freigegeben. A n d e r e n f a l l s wird der ProzeB in den Status zurHckgestellt;
"Warte auf Ende eines U n t e r p r o z e s s e s "
er wird sp~ter zur W e i t e r f H h r u n g aufgenommen,
wenn ein ihm u n t e r g e o r d n e t e r ProzeB b e e n d e t wird
(siehe Punkt
2.3); der n~chste lauff~hige ProzeB in der P r i o r i t ~ t s k e t t e wird aufgenommen. 2.3 Falls der ihm H b e r g e o r d n e t e ProzeB sich im Status de eines U n t e r p r o z e s s e s "
befindet,
"Warte auf En-
wird dieser w i e d e r zur Fort-
fHhrung seines Beendens bei Punkt 2.2 lauff~hig gemacht. 2.4 Der PKS w i r d a u s g e k e t t e t und der belegte S p e i c h e r p l a t z
freige-
geben. Das Beenden eines P r o z e s s e s beim E r r e i c h e n des l o g i s c h e n Endes der zug e h ~ r i g e n B e f e h l s f o l g e geschieht, Prozesses v e r l a s s e n w o r d e n ist
nachdem der letzte Block im Code des
(also e x i s t i e r t kein U n t e r p r o z e B mehr),
durch A u f r u f einer Systemfunktion,
die folgendes tut:
• Falls eine U S I N G - O p t i o n besteht, wird eine R E L E A S E - A n w e i s u n g auf die entsprechende
S E M A - V a r i a b l e ausgef0hrt.
• Wurde eine A C T I V A T E - A n w e i s u n g gepuffert, • Wenn eine A C T I V A T E - A n w e i s u n g
wird der ProzeB neu aktiviert.
fur den ProzeB e i n g e p l a n t ist, w i r d er
in den Status e i n g e p ! a n t und nicht aktiv gesetzt. • A n d e r e n f a l l s w i r d bei Punkt 2.3 der T E R M I N A T E - A n w e i s u n g fortgefahren.
SYNCHRONISIERUNG,
Das B e t r i e b s s y s t e m o r g a n i s i e r t die S y n c h r o n i s i e r u n g
yon P r o z e s s e n mit Hilfe yon SEMA- und BOLT-Variablen, wie sie in der P E A R L - S e m a n t i k b e s c h r i e b e n ist. Dabei sind in u n s e r e m B e t r i e b s s y s t e m zwei B e s o n d e r h e i t e n vorgesehen,
die der A u s f ~ h r u n g einer S y n c h r o n i s i e r -
anweisung gr~Bere E f f e k t i v i t ~ t gibt.
541
. Es gibt nur eine W a r t e s c h l a n g e pro BOLT-Variable. PKS als erster in der W a r t e s c h l a n g e w i c h t i g s t e der w a r t e n d e n Prozesse.
dessen
e i n g e k e t t e t ist, ist immer der Der V e r g l e i c h der W i c h t i g k e i t
er P r o z e s s e ist e r h e b l i c h v e r e i n f a c h t ,
zwei-
indem die z u g e o r d n e t e n PKS
eine absolute Priorit~tszahl beinhalten, g e r - R e l a t i o n in der P r i o r i t ~ t s k e t t e
Oer ProzeB,
die die V o r g ~ n g e r - N a c h f o ! -
spiegeln,
zus~tzlich zu den im
P r o g r a m m a n g e g e b e n e n R e l a t i v - oder S y s t e m - P r i o r i t ~ t e n .
Der in der
P E A R L - S e m a n t i k bei B O L T - 0 p t i o n e n v e r l a n g t e W i c h t i g k e i t s v e r g l e i c h w i r d d a d u r c h auf nur einen Z a h l e n v e r g l e i c h reduziert. • Bei A u s f 0 h r u n g einer S p e r r a n w e i s u n g
(REQUEST, RESERVE,
ne Liste yon S y n c h r o n i s i e r v a r i a b l e n wird,
E N T E R ) 0 b e r ei-
falls eine S y n c h r o n i s i e r -
v a r i a b l e g e f u n d e n ist, die eine S p e r r b e d i n g u n g enth~it,
der PKS des
Prozesses nut in d e r e n W a r t e s c h l a n g e e i n g e k e t t e t und der P r o z e B zur s p ~ t e r e n W i e d e r h o l u n g seiner A n f o r d e r u n g
zurHckgestellt.
PROZESSDATENOBERTRAGUNG Ein E n d g e r ~ t fur P r o z e B d a t e n kann E i n / A u s g a b e ~ber einen n o r m a l e n Kanal sowie e i n e n Teilkanal
(durch "subdivided'-connector-descriptor" im Sy-
stemteil beschrieben)
ausf~hren.
O u r c h K o m p i l i e r e n des S y s t e m t e i l s w e r d e n die G e r ~ t e k o n t r o l l s ~ t z e GKS eingerichtet.
Zum GKS geh~ren folgende Eintr~ge:
• Einsprungstellen,
die die ~ b e r t r a g u n g s a r t und die e n t s p r e c h e n d e n Un-
t e r p r o g r a m m e bestimmen. • Eine B e s c h r e i b u n g der b e n u t z t e n Kan~le: M o d e fHr a n a l o g e Ein/Ausgabe, T e i l k a n a l b e s c h r e i b u n g fur d i g i t a l e Ein/Ausgabe,
falls T e i l k a n ~ l e
b e n u t z t werden, Musterliste
fHr evtl. b e n u t z t e Teilkan~le.
Angabe zur Z e i t k o n t r o l l e der Ubertragung. . Weichen,
die die R e a k t i o n auf R ~ c k m e l d u n g und die R e a k t i o n auf Fehler
bestimmen. . Ein Zeiger auf P r o z e B k o n t r o l l s ~ t z e von evtl. w a r t e n d e n Prozessen. • Ein Zeiger auf den b e a u f t r a g e n d e n ProzeB. • V e r s c h i e d e n e P a r a m e t e r zur B e s c h r e i b u n g des Ger~tes. Da d u r c h die a s y n c h r o n e P r o z e B b e a r b e i t u n g und den p a r a l l e l e n A b l a u f der Ein/Ausgabeger~te
zur Z e n t r a l e i n h e i t des Rechners, m e h r e r e D a t e n H b e r -
542
tragungsauftr~ge
innerhalb kurzer Zeit Hber d a s s e l b e Ger~t e i n k o ~ e n
kSnnen, muB der Zugriff zu d i e s e m Ger~t zwischen den b e a u f t r a g e n d e n P r o z e s s e n s y n c h r o n i s i e r t werden.
Im Fall der D a t e n H b e r t r a g u n g mit in-
terner G e s c h w i n d i g k e i t ist n a t H r l i c h die S y n c h r o n i s i e r u n g unn6tig. Das P r i n z i p der P r o z e B d a t e n H b e r t r a g u n g
fHr langsame Ger~te ist im Bild 6
beschrieben. Falls m e h r e f e P r o z e s s e auf das gleiche Ger~t warten,
sind ihre ProzeB-
k o n t r o l l s ~ t z e in einer g e r ~ t e z u g e h 6 r i g e n W a r t e s c h l a n g e verkettet. analog sind die W a r t e s c h l a n g e n aufgebaut,
Ganz
die durch e x p l i z i t e s Sperren
mit S y n c h r o n i s i e r a n w e i s u n g e n entstehen. Zum E i n l e i t e n einer U b e r t r a g u n g • wird,
falls eine analoge U b e r t r a g u n g a u s z u f O h r e n ist, der r i c h t i g e
MeBbereich
(Mode) eingesetzt,
. w i r d im GKS bei der R e a k t i o n auf M e l d u n g e n notiert, dab eine R0ckmeldung e r w a r t e t wird, die das U b e r t r a g u n g s p r o g r a m m fortsetzen wird, . wird im GKS eine Dauer notiert,
innerhalb der eine R H c k m e l d u n g sp~-
testens erfolgt sein muB, . wird im Fall einer A u s g a b e Hber T e i l k a n a l der S t e l l w e r t p o s i t i o n s g e recht b e r e i t g e s t e l l t , . werden die P a r a m e t e r fur die S t e u e r u n g der U b e r t r a g u n g dem Ger~tetreiber ~bergeben, • wird der b e a u f t r a g e n d e ProzeB in den W a r t e z u s t a n d auf R H c k m e l d u n g zur~ckgestellt. ZumAbschlieBen
der K o n t r o l l e dber die E i n / A u s g a b e wird
. bei der R e a k t i o n auf M e l d u n g notiert, dab eine M e l d u n g aus dem Ger~t jetzt als F e h l e r b e h a n d e l t wird, • die zur Z e i t k o n t r o l l e abgelegte D a u e r gel6scht, • der b e a u f t r a g e n d e ProzeB l a u f f ~ h i g gemacht. Fehlermeldungen erfolgen . bei 0 b e r t r a g u n g s f e h l e r n , • b e i m Versuch,
ein a u s g e s c h a l t e t e s Ger~t zu benutzen,
. b e i m E i n t r e t e n einer Ger~temeldung, wenn keine D a t e n d b e r t r a g u n g eing e l e i t e t wurde, • b e i m V e r s t r e i c h e n der zur Z e i t k o n t r o l l e f e s t g e l e g t e n Dauer, bevor die
543 R~ckmeldung erfolgte. Im "Allgemeinen PEARL-Betriebssystem"sind die Ger~tetreiber sowie die Programme zur Fehlerreaktion nicht enthalten, da sie implementationsabh~ngig sind. Die Schnittstelle zu den Treibern sowie anderen Ger~testeuerprogrammen sind jedoch genau definiert. CDatenubertragung ) ausgeschaltet
Gerat/Kalal-~us?
Merke: Gerat besetzt
4
Leite 0bertragung ein (siehe Text)
besetzt Kette den PKS des beauftragenden Prozesses in ger~tezugeh6rige Warteschlange ein
Wichtigsten lauff~higen ProzeB fortsetzen / Warten auf ' RHckmeldung J
<'R~ekmeidung ) nein
Ubertragung korrekt?
~a
C Feh~ier Nimm W e r t ,
wenn E i n g a b e .
Schliege Kontrolle ~ber Ein/Ausgabe ab (siehe Text) Sind PKS in der ger~tezugeh6rigen Warteschlange eingeordnet? ,~ein
ja Nimm wichtigsten Auftrag auf I
Gib Ger~t frei
~
Wichtigsten lauff~higen ProzeB fortsetzen /
Bild 6: ProzeBdaten~bertra~un 9
J
FUNKTIONSBAUSTEINE He
FOR REALZEIT-BETRIEBSSYSTEME
imut
Ho
tes
I. A u ~ a b e n s t e l l u n ~ Ein Betriebssystem
ist aus dsr Sicht des Benutzers
anwendun~sorientierten
Funktionen.
sich sus der Summs der MaBnehmen triebssystemau~ruSs
Eine derartige
zusemmsn,
sins Menge yon Funktion
setzt
dis sis Foige sines Be-
odsr siner Programmunterbrschung
eusge$Ohrt
wer-
den. Welche anwendungsorientisrten ist in den meisten
Funktionen
ein Betriebssystem
F~llen durch die Betriebsart
fsstgslegt.
bilden, So kann
man bsim Rechsnzentrums-
oder Tims-sharing-Betrisb
Grundfunktionen
die des System enthalten muB. Oazu kSnnen
angeben,
wahlwsise weitere Komforts
Funktionsn
kommen,
art "Realzeitbetrieb", Bet Bedeutung
sondern
Start yon Programmen bsi StOckprozessen dem technischsn
such die Art dsr Anwendung
Zeitabst~nden
der Programmstart
der Bundesrsgierung
h~u?ig die Notwendigkeit,
besch~ftigt
System and ~rocess
Sahren zur Rationeiisierung
Prozessen
w~hrend aus
bestehende
Be-
oder neus Spezialsystsms
"ProzeBlenkung
mit DV-Anlagen"
sich des Vorhaben
Control ~unctions) der Ersteiiung
tierter ReeIzeit-Betriebssysteme
durch den
vorgenommen,
0araus ergibt sich bei der
und zu sPwsitern
Im Rahmen des Projekts
yon gro-
So wird beispiels-
yon Untsrbrechungssignalen
ProzeB veranlaBt wird.
zu ~ndsrn
zu entwickeln.
2. Struktur
hSheren
nicht nur die Betriebs-
bei kontinuierlichen
in ~estsn
yon ProzeBrechnern
trisbssysteme (POV)
ist dagegen
for den Au?bau des Betriebssystsms.
weise der Programmableu~
~perating
die for Ausbaustu?en
verwendet werden.
Beim Einsatz yon ProzeBrechnern
Anwendung
einsn Satz yon
COPF
(Common
mit der Au?gabe,
Ver-
solchsr anwendungsorien-
zu entwickein
(1,2).
yon Betriebssystemen
Die Auswahl
sines Seizes enwendungsorientierter
hen die Leistung
eines speziellen
er#olgt so, dab die Aufgaben bequem programmisrt
werden
anwendungsorientierten ren Aufgeben
Funktionen,
Betrisbssystems
Sestgelegt
sines Anwendungsgebistes
kSnnen.
mit dewird,
damit mSglichst
Daraus er~ibt sich, dee in einer
Funktion meist eine genze Reihe yon elemente-
des Betriebssystems
vereinigt
ist. Daher werdsn disse
545 Funktionen aus mehreren ein~echen Programmbausteinen, tionen, au~gebaut. Oie Struktur dieses Programmsystems
den Besis~unkist mehrstu-
~ig, d.h. aus den ein~achen Basis~unktionen werden Ober mehrere Zwischenebenen mit Funktionen steigender Komplexit~t die anwendungsorientierten Funktionen gebildet. De ein Betriebssystem m5glichst e~izient in bezug au~ Speicherplatzbedar~ und Laufzeit sein soll, mOseen in den Basis~unktionen die Hardwareeigenscha~ten des Rechners berOcksichtigt werden. In den anwendungeorientierten Funktionen treten diese Eigenschaften dagegen nicht mehr in Erscheinung. Bei einem geschickten stu~enweisen Aufbau scheint es mSglich, Funktionen einer mittleren Ebene zu konstruieren, die nicht mehr herdwareabh~ngig, abet auch noch nicht anwendungsabh~ngig sind. Auf diese Weise ergibt sich ein Scheme nach Bild 1: Aus einer grSBeren Anzahl ein~echer Basisfunktionen warden wenigere ZwischenSunktionen au~gebaut. Anwendungsorientierte
Funktionen warden direkt
aus den Funktionen der mittleren Ebene gebildet.
E ~ L ~
i
""
D
/
anwendungsor Funk~ionen ei n~ierte stondordi sierbare Funkt ionen
Bild ~: Hierarchischer Au~bau der Betriebssystem?unktionen
546
Die Eigsnschaft der Zwischenfunktionen, weder anwendungs- noch hardwareabh~nEig zu sein, ist sine gute Voraussetzung, s i e a l s Grundlege for sine bisher noch fehlende Standerdisierung yon Realzeit-Bstriebssystemsn zu w~hlen. Sis sollen deshalb im folgenden als standardisierbare Funktionen bezeichnet werden, x) Des Vorhaben COPF hat zum Ziel, for charakteristischs ProzeBreohnereinsetzgebiete die anwendungsorientierten
Funktionen aufzustei-
fen, daraus die gemeinsamen standardisierbaren Funktionen abzuIeiten und ihre Abbildung aug Basisfunktionen for verschiedene Rechner vorzunehmen.
Oie anwendungsorientierten
Funktionen werden dabei so
formuliert, da6 sis die Erweiterung von betriebssystemunebh~ngigen Breitbandsprachen wie CORAL 66 (4) und POLYP (5) zu anwendungsorientierten Sprachen biIden. Im folgenden soil am Beispiel der Zeitverwaltung der Aufbau des Funktionensystems
n~her eri~utert warden. Die Erfahrungen bei der
bisherigen Projektabwicklung haben gezeigt, dab die obige Oefinition der standardisierberen Funktionen nicht hinreichend ist, um des Funktionensystem eindeutig festzuiegen.
Oas soll am Beispisl
der Speicherverwaltung dargeiegt warden. 3.
Funktionen der Zeitverwaltung
3.1 Aufgaben In einem Realzeitsystem mOssen vielfach Funktionen zu vorbestimmten Zeiten ausgefOhrt werden. Beispiele sind des Fortsetzen sines Prozesses nach Ablauf einer Wartezeit oder zu einem fasten Zeitpunkt, Betriebssystemaufrufe,
die zeitverzSgert gegeben warden sollen oder
der zyklische Start eines Prozesses in fasten Zeitabst~nden. Die Zeitverwaltung nimmt ells Auftr~ge zum zeitrichtigen Start von Funktionen entgegen. Oiese Auftr~ge kSnnen yon anderen Teilen des Betriebssystems oder als Betriebssystemaufrufe
yon Benutzerprozes-
sen kommen. Ist der Zeitpunkt zum Start einer Funktion ein~etreten, so veranlaBt die Zeitverwaltung deren AusfOhrung.
Im allgemeinen ge-
schieht des durch AnstoB einer anderen Komponente des Betriebssystems. x) In einer Untersuchung Ober den Kern sines Mehrprozessor-Betriebssystems Kommt Nehmer (3) zu ~hniichen Ergebnissenj die dort mit Eiementarfunktion bezeichneten Programmbausteine entsprechen den stenderdisierbaren
Funktionen.
unter Benutzung der Programme der Zeitverwaltung, geschieht unabh~ngig vom Anwendungsfall
in der im vorigen Abschnitt geschilderten
Weiss. Demnach giiedert sich sine zeitverzSgerte Funktion in zwei anwendungsorientierte
Teile, n~mlich
- A u f t r a g s e r t e i l u n g an die Zeitverwaltung und AusfOhrung des Auftrages nach AnstoB durch die ZaitveI~valtung.
Der Aufbeu der eigentlichen Zeitverwaltung ist dagegen unabh~ngig davon, welche Funktionen zeitverzSgert ablaufen sollen. Demnach setzt sich die Zeitverwaltung aus standardisierbaran
Funktionen
zusammen. 3.3
Standardisierbere
Funktionen
3.3.1 A u f t r a g s l i s t e Die Auftr~ge an die Zeitverwaltung werden in einer Lists gespeichert. Ein Block der Lists hat folgenden Aufbau: T
Uhrzeit
AC
Auftragscode
PARI
Parameter
PAR2 ZEIGER
Verkettun£szeiger
AC bestimmt, welche Funktion zur Zeit T zu s t a r t e n i s t .
PARI und
PAR2 warden der Funktion als Startparameter mitgegeben,
PARI wird
immer benStigt, PAR2 kann bei v i e l e n Funktionsn wegfallen. Um die
Verwaltung der Auftragsliste einfach zu halten, besitzen die BlSkks feste L~ngej PAR2 bleibt dann frei. Z.B. wird bsim Starten oder
548 Fortsetzen eines Prozesses in PARt die Adresse des ProzeBkontrollblocks abgelegt, in dam sich alle weiteren Infommationen Ober den ProzeBzustend befinden, die for die Ablaufsteuerung benStigt wetden. Bei einem zyklisch zu startenden ProzeB enth~it PAR2 die Zykluszeit. Die ListenblScke warden in der Reihenfolge steigender Uhrzeit angeordnst. Um neua Auftr~ge zaitrichtig in die Lists einfOgen zu kSnnen, Bind die ListenblScke Ober ZEIGER einfach verkettet. FOr die Zeitverwaltung steht meist sine Uhr zur VerfOgung, die Unterbrechungssignale
in fasten Zeitabst~ndsn liefert. Es ist abet
auch mBglich, mehrere Wecker als Uhren zu vemwenden, die yon der Zeitverwaltung entsprechend den Auftr~gen voreingestellt werden. Dann muB for jeden Wacker Bins Auftragsliste eingerichtet warden. DiBBer Fall wird im folgenden nicht n~her betrachtet. 3.3.2 Auftrageannahme Die Annahme eines Auftrags for die Zeitverwaltung geschieht mit einer standardisierberen Funktion, die als Prozedur programmiert ist. Als Parameter wird die Adresse des Speicherblocks Obergeben, in dam die eigentlichen Auftragsparameter in der Form abgelegt Bind, wie sis als Listenblock in die Auftragsliste eingeordnet werden mOssen.
Als srstes wird der Auftragscode BUr GOltigkeit geprOft und im F e h l e r f a l l mit einer Fehlermeldung zum aufrufenden Programm zurOokgesprungen. Die Zeit k a n n a l s
Tageszeit oder als Wartezeit bis zur AusfOhrung
des Auftrags angegeben werden.
Im zweiten Fall erfolgt eine Um-
rechnung auf die absolute Zeit, weil der Wart in dieser Form in der Auftragsliste abgelegt werden muB. AnschlieBend wird der Auftragsblock in die Liste eingeordnet. Danach erfolgt der ROcksprung mit Obergabe eines ROokkehrcodes,
in dem die Annahme des
Auftrags oder sine Fehlermeldung dem Auftraggeber mitgeteilt wird. 3.3.3
Auftragsbearbeitung Die Bearbeitung der Auftr~ge wird yon einer standardisierbaren Funktion veranlaBt, die als Unterbrechungsprogramm abl~uft. DaB
549
Programm wird yon dem periodischen gestartet.
Zeitinterrupt
Es wird zun&chst geprOft,
rung des ersten Auftrags
der Realzeituhr
ob der Zeitpunkt
in der Liste gekommen
ist. Wenn das der
Fall ist, wird der erste Block aus der Liste entfernt fOhrung des Auftrags mit diesen Parametern schieht
durch Verzweigen
Auftragscode
gramms zugeordnet
angestoBen.
Ober eine Sprungleiste,
AC eine Startadresse
zur AusfOhund die AusDes ge-
in der jedem
des anwendungsorientierten
ist. Andernfalls
Pro-
geht es in das unterbrochene
Programm z u r O c k . Theoretisch
ist es mSglich,
abgewickelt
werden sollen.
beitung
nicht OberprOft.
brechung
dab zwei Auftr~ge
kann bei periodischer
eine VerzSgerung
Die Taktfrequenz
dab das for den praktischen 3.4
Zeit
Oieser Fall wird bei der Auftragsbear-
Hierdurch
durch die Realzeituhr
heir auftreten.
zur gleichen
Unter-
um eine Zeitein-
der Uhr ist aber so hoch gew~hlt,
Betrieb belanglos
ist,
Basisfunktionen Die Basisfunktionen, Zeitverwaltung baut werden,
aus denen die beiden Standardfunktionen
"Auftragsannahme"
bestehen
tung, die in der gleichen ve~endet
warden,
ver~altung
Funktionen
aufge-
zur Listenbearbei-
Form in vielen Betriebssystemkomponenten
und speziellen
Funktionan,
die nur for die Zeit-
gebraucht warden.
Zur Listenverarbeitung
-
und "Auftragsbearbeitung"
aus allgemeinen
der
Einrichten
gehSren die Funktionen
einer einfach verketteten
Liste bei der Systeminitia-
lisierung, -
Einketten
eines Auftragsblocks
entsprechend
Ti ~
-
Ausketten
i und i+1
T < Ti+ 1,
des ersten Auftragsblocks.
Sie sind Basisfunktionen, ie zerlegt werden 8chaften
zwischen den BlScken
dem Kriterium
well sie einerseits
k~nnen und andererseits
des Rachners
nung und Verarbeitung
berOcksichtigt
nicht weiter in Tei-
in ihnen Hardwareeigen-
werden mOssen.
des Verkettungszeigers
Bei der Anord-
spielan Wortl~nge,
55o
AdreBl~nge, ver~ahren
Positionierung
der Adresse
im Wort und Adressierungs-
eine Rolle,
Oie speziellen
Basisfunktionen
-
GOltigkeitsprOfung
-
Umrechnung
der Zeitverwaltung
des Au~tragscodes
einer Z e i t d i ~ e r e n z
sind
AC,
in eine Absolutzeit,
- Zeitvergleich, - Sprung in des Programm Diese Funktionen
arbeiten mit Parametern
deren Oarstellung,
4.
zur Au~tragseus~Ohrung.
L~nge und Anordnung
eus dem Auftragsblock,
herdwareabh~ngig
ist.
Gliederun~ der Speicherverweltung Die Strategie bei der Verweltung wendungsgell
ebh~ngig.
Besteht
sen mit kurzer Laufzeit, des Arbeitsspeichers ~er Leugzeit h~ngigkeit
des Arbeitsspeichers
ein Progremmsystem
zu Ende laugen
lessen.
kenn es dagegen vorteilhegt
der ProzeBpriorit~t
Die Strategie
Bei Prozessen mit inn-
sein, den Speicher
zwischenzeitlich
vonder
zwei Funktionen
wieder.
in Ab-
auch wieder zu ent-
zu Oberlessen.
spiegelt sich im Aufbau der Werteschlangen
zu ihrer Verarbeitung
anwendungsorientierte Unabh~ngig
z.B. eus Prozes-
so wird man einen ProzeB nech Zuteilung
ziehen und einem ProzeB hSherer Priorit~t
Funktionen
ist vom An-
und den
Oiese Teiie sind aiso
Funktionen.
Strategie werden
~Or die Speicherverwaltung
benStigt:
- Freigeben: Ein bisher belegter Speicherbereich
wird vom au~rufenden
Pro-
gremm ~reigegeben. - Reeervieren: Ein Speicherbereich In der ROckmeldung werden
konnte
bestimmter
GrSBe oder Lage wird ange~ordert.
wird mitgeteilt,
ob der Au~trag ausge~Ohrt
und die Adresse des Bereichs
Sie heben die bisher ge~orderten beren Funktionen,
hardware-
Obergeben.
Eigenschaften
der standardisier-
und anwendungsunabh~n~ig
zu sein.
Ihr
551
Au~bau aus Basisfunktionen mS£;lich,
ist jedoch noch aug verschiedene
die nicht allein durch die BerOcksichtigung
eigenschagten
zustande
Eine EingluBgrSBe tungseinheiten,
Weisen
von Hardware-
kommen.
ist die Strukturierung
die geste oder variable
des Speichers
in Verwal-
L~nge besitzen
kSnnen.
Als VeI~valtungsingormation
muB die Lage der Verwaltungseinheit,
ihre L~nge und ihr Zustand
(grei/besetzt)
gegOhrt werden.
Daten kSnnen in den Verwaltungseinheiten schiedlicher Verfahren thoden
Struktur
liegen.
zur Verwaltung
In einem Betriebseystem Funktionen
"freigeben"
speicher wird n~mlich Klassen
SchlieBlich
mSglich.
gindet sich bei Knuth
oder in Tabellen
unter-
sind noch verschiedene
Eine Zusammengassung
dieser Me-
(6).
werden meietens
mehrere
und "Reservieren" unterteilt,
Varianten
benStigt.
in mehrere Bereiche
yon InTormationen
Diese
der
Der Arbeits-
zur Augnahme beetimmter
z.B.
- Programmspeicher, Oatenspeicher
-
Speicher
-
und
gOr L i s t e n
des B e t r i e b s s y s t e m s .
Jeder dieser Speicherbereiche walter.
wird aug andere Art und Weiss vet-
Oaher gibt es soviele Varianten
servieren"
yon "Freigeben"
in einem System wie Speicherbereiche.
wird diese Unterscheidung
nicht sichtbar,
hen und die yon ihnen geliegerten
und "Re-
FOr den Benutzer
der Au~rug der Funktio-
ROckmeldungen
sind got alle Be-
reiche gleich. Das Beispiel
der Speicherverwaltung
zeigt,
dab die beiden Eigen-
schagten Hardwareunabh~ngigkeit -
und
Anwendungsunabh~ngigkeit
nicht ausreichend schengunktionen notwendig,
Funktionen
yon Hardware sieren. dabei
sind,
um einen Satz yon standardieierbaren
eindeutig
gestzulegen.
mit derselben
und Anwendungsgall
Die Grundstruktur
zwar erhalten,
Zwi-
Es ist vielmehr mSglich
Auggabenstellung
sug verschiedene
dee Funktionensystems
und
unabh~ngig
Weiss zu realinach Bild I bleibt
die Zahl der standardisierbaren
Funktionen
552 wird jedoch erhSht. 5.
Realisierung dss Funktioqensystems Die COPF-Funktionen warden mit dam Programmiersystem POLYP implementiert, dessen charakteristisches Merkmal die Aufteilung in eine Problem- und eine Steuersprache ist. Oie Problemsprache ist eine Breitbandsprache mit maschinennahen Eiementen, z.B. zur Positionierung von Oaten und zur AdreBrechnung, die die Erzeugung yon effekriven Objektprogrammen for verschiedene Hardwarestrukturen ermSglichen. Ein Oueilprogramm durchl~uft bei der Obersetzung zun~chst einen interpretativen Compiler, der die Eiemente der Steuersprache verarbeitet und ein modifiziertes Problemprogramm iiefert, das dann im generativan Compiler in des Objektprogramm Obersetzt wird. Die Steuersprache wird bei COPF zur Anpassung der Funktionen an verschiedene Rechnertypen benutzt. Dazu gibt es einen Setz yon Steuervariablen zur Beschreibung der Herdwareeigenschaften. Hierzu gehSren z.B. Wortl~nge, Zeichenl~nge, AdreBi~nge, AdreBposition im Wort, AnzahI der generellen Register. Am Anfang einer Obersetzungseinheit warden diesen Variablen in einer Steuerprozedur die for die Zielmaschine gOitigen Werte zugewiesen. Eine zweite Anwendung der Steuersprache ist die Unterscheidung verschiedener Varianten einer standardisierbaren Funktion mit Hiife einer Steuervariablen. Die Funktion wird als Steuerprozedur progran~niert, in deren Oeklarationsteil in Abh~ngigkeit der Steuervariablen versohiedene Problemprogramme enthalten sind, Im Prozeduraufruf wird der Steuervariablen sin Wart zugewiesen. Die Auswahi der gewOnschten Funktionsvariante geschieht damit durch den interpretativen Compiier; sie wird nicht erst im Objektprogramm durchgefOhrt, was eine VergrSBerung von Speicherbedarf und Laufzeit zur Folge h~tte.
5.
Literatur (1) Stams,D.: Des Projekt ProzeBlenkung mit OV-Anlagen, Angewandte Informatik 14, H,2, S. 67-68 (1972), (2) Hotes,H.: Structure end Implementation of dedicated RealTime Executives. 3rd European Seminar on Real-Time-Programming, Ispra (1973).
553
[3) Nehmer,J.: Oispatcher-Elementarfunktionen for symmetrische Mehrprozessor-DV-Systeme. Kernforschungszentrum Karlsruhe, Bericht KFK 1866 (1973). (4} Inter-established committee for computer applications: Official definition of CORAL 66 (197o).
(5) MuBtopf, G.: Des Progremmiersystem POLYP. Angewandt8 Informat i k .14, H.lo, S. 441-448 (1972). (6} Knuth,D.E.: (1972).
The Art of ComputBr Programming.
Reading, Mass.
MODULTEST
ALS SPEZIALFALLGEZIELTER
L.
STOLZE
1,
Ein{Ohrun
Oer N a c h w e i s
der
ein bedeutsames
Funktions£~higkeit
und schwieriges
beitung durch hohe Forderungen stems zus~tzlich Problems
versch~r{t
da5 ein Progremm
i)
"richtig"
k o m p l e x e n P r o g r a m m s y s t e m e n isb
Problem,
des in der ProzeBdatenverar-
wird.
Erstrebenswert
des Gesamtsy-
zur LSsung dieses
well man mit dsren Hil~e zeigen kann,
is~. Ihr Einsatz ist jedoch an wenigstens
gebunden:
Die Aufgabe, geeigneten
ii)
von
an die AusSallsicherheit
sind ~ormale Ver~ahren,
2 Forderungen
PORTABILITAT
die des Programm erledigen
Formelepparat
Oer B e w e i s ,
vollst~ndig
dab das P r o g r a m m genau
mechanisiert
- d.h.
unter
Einsatz
soll, muB durch einen
beschrieben
seine einer
werden
kSnnen.
Au~gabe e r ~ O l l t , Rechenanlage
muB
- geFOhrt
warden kBnnen.
Beide Forderungen soda6 Ver~ahren FOr praktische
sind heute jedoch
hOchstens
Anwendungen
Form zur~ckgreifen,
wobei mittels
geeigneter
richtig, gilt,
~alsehe
Ergebnisse
ist, die Umkehrung
wenn des Beispiel
ist es er~orderlich,
lie~ert,
undurch#Ohrbar
Ergebnisse
erweist,
Ergebnissen
2. Verbesserung
war-
kann, dab das
- das Programm
lie~ert
aufzustellen,
mifi vielen Parametern
Parameterkombinationen
au~ Richtigkeit
ist
- jedoch nicht
de man schon aus zeitlichen
nieht in der Lage ist, ella erlaubten zugehBrigen
schlieBen
Schlusses
eine Vielzahl yon Beispielen
was sich namenfilich bei groBen Programmen praktisch
nachgewiesen
Oa man nun aus der Tatsache,
dieses
richtige
Beispiele
ist, im Prinzip also die Umkeh-
rung dessen, was man eigentlich mSchte. dab ein Beispiel
er~Ollt,
ausscheiden.
muB man daher auf Testen in irgendeiner
den soil, dab ein Programm ~ehlerhaft
Programm falsch
ausnehmsweise
dieser Art aus der Betrechtung
als
GrOnden mit den
zu vergleichen.
dutch Organisation
Diesen Schwierigkeiten
muB man dutch organisatorische
nenj mit dem Ziel, die Anzahl der Programmierfehler
MaBnahmen
begeg-
und der Testf~lle
557
deutlich zu reduzieren.
2.1 Reduzieren yon Progremmierfehlern Durch die Wahl einer geeigneten der mOglichen
Programmiersprache
l~Bt sich die Zehl
Fehlerquellen und damit die Zahl der Progremmierfehler
selbst im Vergleich zu einem in Assembler geschriebenen stisch einschr~nken.
Programm dra-
Dee liegt ganz wesentlich deran, dab eine "geeig-
nete" Programmierspreche
die dem Problem angemessenen
und Operationen ale primitive
Objekte enth~it.
sam Zusammenhang vor Augen, wie schwerf~llig
Datenstrukturen
Man halte sich in die-
etwa eine Liete in Assemb-
ler zu formulieren und bei Bedarf zu ~ndern ist; i,e. mOssen dabei auch s~mtliche
Listenzugriffe
Einen weiteren dadurch
Vorteil bieten Sprechen mit Oeklarationspflicht,
FlOchtigkeitsfehler
Operationen) Namens)
ge~ndert werden. weil
(z.B. im Zusemmenheng mit typabh~ngigen
oder Ablochfehler
(unbeabsichtigtes
EinfOhren eines neuen
sehr wirksam vermieden werden k~nnen.
2,2 Reduzieren yon Testf~llen Noch wichtiger als des Ausechalten yon Fehlerquellen
ist die Vermin-
derung der zum Nachweis der "Richtigkeit ~ eines Programme erforderlichen Testf~lle,
weil man nur so either sein kenn, dab elle m6glichen
Parameterkombinationen Strukturierung
durchleufen warden.
in horizontaler
Man erreicht dies durch
(Modulerieierung)
und vertikeler
(Schich-
tung) Richtung. 2.2.1 Modularisierung Da die Funktion, die ein Progremm zu erfOllen hat, vorgegeben men im Sinne der Aufgebenstellung
nur etwas erreichen,
Progremm in einzelne Moduln zerlegt,
ist, kann
wenn man des
in denen jeweils Teilfunktionen
reelisiert werden. Unter einem Modul soll daher im Sinne der Testberkeit eine ebgeschloseene Funktionseinheit, mabgeschlossen"
sin cog.
Funktionsmodul verstanden werden, wobei
heiBt, dab der Modul seine s~mtlichen AuBenbeziehungen
nur Ober wohldfinierte
Schnittstellen
Seiteneffekte vez~neiden.
ebwickelt.
Dmdurch lessen sich
558
Ein Belcher Modul hat einen Eingang,
auf dem er angestoBen und versorgt
wird, und einen Ausgang, auf dem er die Beendigung seiner T~tigkeit signalisiert und evtl.
ErgebnisB~
noch AuBenbeziehungen, h~ngen.
zurOckmeldet.
Dansben hat der Modul i.a.
deren Art und UmTang yon seiner Funktion ab-
Dabei handelt es sich meist um Qetriebssystemaufrufe,
e~nen Satz auB einer Datel beschaffen,
die etwa
sine Zeile auf einen Bildechirm
schreib~n u.a.m. Aus der Sicht des Module existiert mithin sine Umgebung, vsrsorgt, mlt d e r e r
kommuniziert
DieBe Betrachtungsweise wird spEter benutzt werden, liert von eelner "nat~rlichen"
Effizienzverlust,
ringer Preis for dab H~chstma6 an Sicherheit, 18Be. Hier einen geeigneten
um einen Modul iso-
Umgebung testen zu k6nnen.
Zwar bedingen die jetzt notwendigen Schnittetellen zelnen Moduln einen gewissen
die ihn anst~Bt,
und an die er ErgebnisBe zurOokmeldet.
doch let dies sin gedas s~ch damit erzielen
KompromiB zu linden,
liehsten Aufgaben des Projektmanagements
zwischen den ein-
ist sine der wessnt-
in jedem Stadium der Konzep-
tionsphase. 2.2.2 Sehichtung Namentlich bei groBen, wBiteres beaohtliches
stark verzahnten
flusses zwischen den einzelnen wOnschenswerten k~nnen,
Programmsystemen
entsteht sin
Problem in Gestalt des InformationsProgrammen des Systems.
Obersichtlichen
ist e8 zweckm~Big,
und Auftrags-
Um diesen in der
und elndeutigen Weiss kanalisieren
dab ~hnlioh wie bei Betriebseystemen
zu
sine
Hierarchie der Programme bzw. Moduln dutch Schichtung definlert wird. Ein Realzeitbetriebseyetem
beiepieleweise
die lediglich BasiBfunktionen u.a.) zur VerfOgung 8tellt.
habe sine Oatenorganisation,
{primitive Dateitypen,
keine Koordination
Wenn dann das Anwendersystem komplizierte
Datei- und Zugriffsstrukturen
ben~tigt, wird man einen
"Datsiverwalter"
als Schicht zwischen Anwendersystem und Datenorganisatlon
etablieren,
und man wird inebesondere darer 8orgen, dab auch so!che Auftr~ge Ober den "Dateiverwalter" Detenorganisation
geleitet werden,
die mit den Baslsfunktionen
der
alleln auskemen.
Der Vorteil der Strukturierung dutch Schichtung wird deutlich, wenn man beim Testen sine bottom-up-Stragie duln der untersten
vBrfolgt:
Zun~chBt werden alle Mo-
Schicht vollst~ndig ~etestet.
Dann kann man beim
Obergang auf die n~chste hShere Sehicht voraussetzen,
dab alle Moduln
559
der darunterlie~enden
Schicht einwendgrei arbeiten und Fehlverhalten
aug gehlerhagte Versor~ung zurOckgOhren.
3. Testvergahren Als unmittelbare
Folge der Strukturierung
hat men die Augteilun~ der
gesemten Testerbeiten an einem Programmsystem in Modultest und Gesemttest
(Integration der Modu!n), wobei bei geschichteten
Phesen glieBend
ineinander Ober~ehen
Schicht tester,
ben6ti~t man die derunterliegenden
System beide
(wenn man Moduln einer hSheren Schichten genz oder
teiiweise und erh~it so einen Vorgrigg aug den Gesemttest).
3.1 Modultest W~hrend der Gesemttest wohl immer aug dem Rechner, entworgen wurde
(Zielrechner),
gOr den des System
erfoIgen mu6, kenn der Moduitest euch
euT einem vom Zielrechnern verschiedenen
Testrechner durch~egOhrt wer-
den. Der Diskussion dieses Sechverheltes
solien eber einige grunds~tz-
fiche Bemerkungen zur Methodik des Modultests vorengesteIlt werden. Beim eblauforientierten struieren,
Testen versucht men die Testg~lle so zu kon-
dab eIle Zweige des Moduls durchlaufen werden.
his erh~it men einen
"gormeI richtigen"
seinen Spezigiketlonen
genOgt.
Der gunktionsorientierte
besiert eug elner Definition der Modulfunktlon,
Test degegen
die nur aug solche
GrSBen Bezug nimmt, weiche an den ModulschnittsteIien gang) euftreten.
Als Ergeb-
Modul, weiB eber nicht, ob er
(Eingeng,
Als Ergebnis erh~it men einen funktionsg~higen
der eber nicht notwendig
gehlergrei
Funktion nicht beeintr~chtigende Problem des Tunktionsorientierten Oeginition der Modulgunktion
AusModul,
ist; der Modui kann gehlerhegte,
Zweige entheIten.
die
Des grunds~tzliche
Tests besteht derin, die gegorderte
zu linden.
3.1.1 Modultest aug dem Zielrechner Soll der Modultest au~ der Zielanlege durch~egOhrt werden, se neturgem~B stehen.
Aber des ist nicht die einzige Voreussetzung,
muB, um aug dem Zielrechner wirtschaTtlioh nen. Ebenso wichtig wie die Rechenanlege le Peripherie
so muB die-
in einem reletiv Tr0hen Stedium des Projekts zur Verg0~ung
(Kertenleser,
f~r die ergorderlichen Testunterstz0tzwng
in Form yon Testhilgen
zu k6n-
selbst sind eusreichend schnel-
Schnelldrucker,
Obersetzungsl~uge
die erT011t sein
SoTtware produzieren
Hintergrundspeicher usw.}
sowie hinreichend wirkseme (Dumproutinen,
Obe~echer
u.~.).
560
AuSerdem wird stillschweigend Betriebseystem
unterstellt,
ObersetzungslBufe
dab des zugrunde
erm6glich.
Unter diesen Voraussetzungen
ben~tigt man for den Test eines Module eine Testumgebung, sorgt und seine Ergebnisse Syetemkontek%e
man sie bei Benutzung 3.1.2
entgegennimmt
hingegen berei%en
liegende
(Simulation
keine besonderen
dee Zielbetriebssyetems
die ihn ver-
der Modulumgebung).
Schwierigkeiten,
direkt absetzen
well
kann.
M o d u l t e s t a u f einem F r e m d r e c h n e r
Tats~chlich wenigsten
slnd eber bei Anwendungen
der im vorigen Punkt genannten
da5 man eich nach anderen
MOglichkeiten
sich dabei vor allem die Verlagerung sogar der gesamten rechner)
der ProzeBdatenverarbeitung Voraussetzungen umsehen mu6.
erfOllt,
so-
Ale Ausweg bietet
der Testarbeiten
Softwareproduktion
die
- mOglieherweise
- auf einen Gro6rechner
(Test-
an.
Der nBchstliegende zu simulieren.
Gedanke
ist es, den Zielrechner aug dem Testrechner
Obwohl man damit Moduln in ihrer "Originalfassung ~ te-
sten kann, wird yon dieser MOglichkeit macht, well solche Simulatoren schwerf&llig
im Betrieb eind.
wie schwierig
und aufwendig
Feetkommaarithmetik derer Darstellung Eine andere,
nur auenehmsweise
teuer in der Herstellung
Gebrauch und i . a.
(Men denke in diesem Zusammenhang
auch nur die Simulation
recht elegente
daran,
einer gegebenen
auf einem Rechner mit anderer Wortl~nge negativer
ge-
und an-
Zahlen ist!) M6glicheit
des Ausweichene
auf einen Test-
rechner ergibt sich, wenn dieser Ober ein Softwereproduktionssystem fOgt, das die Herstellung Ein solches sentliche El
gezielt portabler
Produktionssyetem
hat folgende,
Software
erleubt
ver-
(z.B. POLYP).
for die Themastellung
we-
Eigenschaften:
Der Ouellcode schalteten
kann durch einen dem generativen
Makrogeneretor
in beliebiger
Compiler vorge-
Weise modifiziert
war-
den. E2
Ein dam generativen
Compiler nachgeschalteter
zeugt aus einer meechinenunabh~ngigen code for eine vorge~ebene El wird ausgenutz%,
Codegenerator
Zwischensprache
Assembler-
Maschine.
indem man alle Maschinenabh~ngigkeiten,
er-
wie
561
Variablen- und Konstentendeklaretionen Peremeterblecke
f~r Systemaufruge
bzw. Kommunikation der Moduln
untereinender mit Hilge der Mekrosprache Satz solcher Makroe, peer.
E2 garantiert
gormulisrt.
Ale Ergebnis erh~it man einen
der des Progremmsyetem an sine Zielmaschine ansodenn, dab man den yon dieser Maschine gegorder-
ten Aesemblercode erzeugen kenn, Mit den geschilderten schine ganz einfach:
Hilfsmitteln
ist der Obergang aug die Testma-
Man stellt einen wsitsren Satz yon Makros her, der
des Programmsystem an die Testmaschine zungsl~ugen
den entsprechsnd
Die prsktische weitergehende
anpaBt und benutzt bei Obersst-
Codegenerator.
DurchfOhrung des Tests ergordert ellerdings Vorkehrungen.
einige
Neben der Simulation der Modulumgebung muB
noch des Betriebssystsm dsr Zislmeschine
nachgsbildet werden.
Dies er-
weist sich jedoch meier als viel elnfscher als die Simulation des Begehlsvorrates
der Zielmasehine,
well man wohl immsr devon ausgehsn
dab des Betriebssystsm dsr Testmeschine
kann,
(Tr~gersystem) m~chtiger ist
els des der Zislmssehine. Insgesamt kann man das beschriebene sehichtsnmodell
bsschreibsn
Verfahren durch sin Umgebungs-
und der~bsr hinaus such rechtfertigen:
Anwender
zu testender Modul
simuliertes
Betriebssystem
Tr~gersystsm Dis in diesem Zuesmmenhang
sntscheidende
Eigsnschaft
ist, dab sis sich allein durch ihre Funktionen
solchsr Sichten
beschreiben
lessen,
welchs in dissem Sinne "implementetionsinvariant ~ sind. Ks ist also sue der Sicht des Anwsnders unerheblich,
ob die Funktion des zu testen-
den Module mit Bsfehlen der Zielmsschine oder der Testmeschine rsalisiert
562
wird und for den Modul gilt dies in Bezug auf des simulierte
Betriebs-
system. 3.2 Reelisierun~ Des beschriebene
Ver~ahren wurde in einem Testrahmen
erfOllt sine Reihe yon Forderungen,
realisiert.
Dieser
welche sich aus den Eigenscha~ten
der zu testenden Modul einerseits und dam geplanten Ablau~ des Tests andererseits
ergeben, wobei davon auszugehen
ist, dab sin ModuI ~Or
den Modultest nicht spezieli
~von Hand m zu pr~parieren
deren~alIs nicht unver~ndert
in den Integrationstest
ist, well er an-
Obernommen war-
den kenn. Weitere Forderungen sind: •
Naturgetreue
Nachbildungen der Funktionen,
Zielbetriebssystem •
die der Modul aus dam
benStigt.
Der Modul soil Initialwerte
haben kannen,
die vor jedem Test-
durchleuf enzunehmen sind. •
FOr dielogf~hige Moduln muB sine erwartete
Eingabe simuliert
werden k6nnen. Die Kon~iguration
der Zielmaschine mu6 eu~ bequeme Weiss,
durch Steuerkerten, •
z.B.
einsteliber sein.
Es muB au~ einfache Weiss mSglich sein, s~mtliche
Kombinationen
der Eingengsperameter zu erzeugen. .
Der Testauflauf muB steuerbar sein.
•
Des Zielbetriebssystem
soll leicht gegen ein anderes ausgewech-
seIt warden kSnnen. Diese Forderungen
lessen sich am bssten erfOllen, wenn sowohl des si-
mulierte Betriebssystem sis auch der zu testende Modul els nachladbare Prozeduren aufgefeBt warden, deren Nemen dam Steuerprogremm des Testrehmens bei seinem Start als Parameter mitgegeben warden. FOr Systemeu~ru~e bietet der Testrehmen
eine Stenderd-Schnittstelie,
an der sine die gewOnschte Systemleistung spezi~izierende
SchlOsselzehl
und sin devon abh~ngiger Versorgungsblock ~bergeben wird.
Um bezOgIich
563
der zu testenden Moduln, die ja i.a. voneinander verschiedene bedingungen besitzen,
eben~alls zu einer standardisierten
zu kommen, wird nicht der Testmodul an~eladen,
£in£an~s-
Schnittstelle
direkfi, sondern eine Steuerprozedur
die die £ingangsparameter for den Testmodul aufbaut und ihn
nechl~dt oder - sofern das simulierte Betriebssystem Ober eine Programmverwaltung verfOgt - mittels eines Systemaufrufes sich au~ ein~ache Weise der Testalgorithmus abstimmen.
startet.
Dadurch
au~ den zu testenden
So ist es z.B. ohne weiteres m~glich,
l~Bt
Modul
komple×e Overlaystruk-
turen oder das Zusammenspiel mehrerer Moduln zu testen.
SOFTWARE P O R T A B I L I T Y V I A AN INTERMEDIATE L A N G U A G E William McCastline Waite i.
Introduction A p r o b l e m solution passes through m a n y levels of abstraction be-
tween its o r i g i n a l c o n c e p t i o n and final implementation. provides
Each level
a set of p r i m i t i v e concepts and some means of combining these
concepts to c o n s t r u c t more complex concepts.
For example,
a process
m i g h t be m o d e l l e d by a d i f f e r e n t i a l e q u a t i o n e x p r e s s e d in terms of real numbers and various m a t h e m a t i c a l operations.
The real numbers
and m a t h e m a t i c a l o p e r a t i o n s are the p r i m i t i v e s of this level of abstraction; object
various rules of algebra p e r m i t us to construct a complex
(a d i f f e r e n t i a l equation)
from them.
In general, each level of
a b s t r a c t i o n provides: - P r i m i t i v e operands.
O b j e c t s w h i c h have no structure w h i c h can
be d e s c r i b e d w i t h i n this level of abstraction. - P r i m i t i v e o ~ e r a t o r s ,.
T r a n s f o r m a t i o n s w h i c h cannot be decom-
posed into a sequence of actions w i t h i n this level of abstraction. -
F o r m a t i o n rules.
M e c h a n i s m s used to create s t r u c t u r e d oper-
ands and operators. W h e n a p r o b l e m solution is e x p r e s s e d as an a l g o r i t h m at a given level of abstraction, we have two choices: and interpretation.
translation
(or modellin@)
T r a n s l a t i o n converts the given a l g o r i t h m to an
e q u i v a l e n t a l g o r i t h m at a d i f f e r e n t level of abstraction.
(The term
m o d e l l i n @ usually connotes some c r e a t i v i t y on the part of the translator, w h i l e t r a n s l a t i o n is a more m e c h a n i c a l process.) to solve our d i f f e r e n t i a l equation, terms of a m a t h e m a t i c a l program.
function w h i c h is then t r a n s l a t e d to a Fortran
The p r i m i t i v e concepts p r o v i d e d by this new level include
approximations dicates.
An a l g o r i t h m
for example, might be stated in
to real numbers,
a r i t h m e t i c o p e r a t o r s and certain pre-
F o r m a t i o n rules are available for d e c l a r a t i o n of objects,
creation of arrays and s e q u e n c i n g of operations. I n t e r p r e t a t i o n is the process of a p p l y i n g an a l g o r i t h m to obtain results.
P r i m i t i v e o p e r a t i o n s of the given level are carried out
d i r e c t l y upon the p r i m i t i v e operands by an interpreter.
For example,
the h a r d w a r e of a p a r t i c u l a r computer is the interpreter of its m a c h i n e language.
An a l g o r i t h m may be i n t e r p r e t e d at any level of
a b s t r a c t i o n if a suitable device is available to carry out the primitive operations.
I call such a device the abstract m a c h i n e for the
565 given level
[Newey 1972].
To achieve portability,
the solution to a p r o b l e m m u s t be ex-
p r e s s e d in terms of a level of a b s t r a c t i o n w h i c h can be r e a l i z e d on m a n y computers. major
The choice of an appropriate level is b a s e d upon two
factors: -
-
The range of algorithms
to be expressed.
The range of computers used for interpretation.
To a lesser extent,
the choice is i n f l u e n c e d by the set of tools at
h a n d to provide the realization.
In this paper,
relationship between algorithm specifications
I shall discuss the
and current hardware,
a t t e m p t i n g to sketch a level of a b s t r a c t i o n suitable for a v a r i e t y of algorithms
and machines.
of a b s t r a c t i o n
An i n t e r m e d i a t e language b a s e d on this level
can be used to achieve a r e l a t i v e l y high degree of
portability. I shall give the name Janus to the level of a b s t r a c t i o n w h i c h I am discussing.
Janus was the Roman god of gates and doors,
and the
p r i m i t i v e concepts of the Janus level r e p r e s e n t a gate through w h i c h a v a r i e t y of algorithms m u s t pass to reach a v a r i e t y of computers: The algorithms are to be e x p r e s s e d at the Janus level,
and then real-
ized on each target machine. 2.
Data Objects k ~ e n we solve a p r o b l e m on a computer, we use an a l g o r i t h m to
manipulate
a set of objects w h i c h d e s c r i b e d a t a that is r e l e v a n t to
the solution.
The i n t e r p r e t a t i o n of these data objects depends upon
the p r o b l e m b e i n g solved.
To implement the solution in a p a r t i c u l a r
p r o g r a m m i n g language, we m u s t encode the data objects
in terms o f the
p r i m i t i v e o p e r a n d s available in that language;
a further e n c o d i n g is
p e r f o r m e d by the t r a n s l a t o r w h e n it represents
the data objects in
terms of m a c h i n e primitives. Each e n c o d i n g is a r e p r e s e n t a t i o n a l d e c i s i o n w h i c h may o b s c u r e the o r i g i n a l
i n t e r p r e t a t i o n of the object.
ticular e n c o d i n g w h i c h is a p p r o p r i a t e all a p p r o p r i a t e
for another.
Unfortunately,
the par-
for one computer may not be at
If the o r i g i n a l
i n t e r p r e t a t i o n does
not appear at the Janus level, then there is no way in w h i c h a more a p p r o p r i a t e e n c o d i n g can be selected.
For example,
if a c h a r a c t e r is
r e p r e s e n t e d as an integer and the o r i g i n a l c h a r a c t e r i n t e r p r e t a t i o n is lost, there is no w a y to take a d v a n t a g e of a d i f f e r e n t h a r d w a r e c h a r a c t e r set on another computer.
We m u s t t h e r e f o r e defer repre-
sentational d e c i s i o n s by p r o v i d i n g a v a r i e t y of data objects at the Janus level.
T h e s e data objects can be divided into a r e l a t i v e l y
small n u m b e r of classes by a b s t r a c t i n g the p r o p e r t i e s of current
566
computers. Integer data objects reflect the concept of counting which is fundamental to the design of current computers. dex ordered sets of both data
(arrays)
They are used to in-
and computations
(iterations.)
Every computer with which I am familiar provides hardware to implement addition and subtraction operations on non-negative
integers.
Usually
there is also a natural interpretation of negative integers which is preserved by the addition and subtraction operations.
Integer multi-
plication is often used in the mapping of a multidimensional a one-dimensional
implementation than Burroughs
array to
array, but this is really more dependent upon the upon the specification of the algorithm.
5500, for example,
arrays of descriptors.
two-dimensional
On the
arrays are represented as
To reference such an array, the program places
two subscript values in the stack and specifies the base descriptor. The first subscript value and base descriptor are used by the hardware to obtain a descriptor
for the desired row, and the second value in-
dexes the desired element.
Arrays with more dimensions are treated
in the same way; no integer multiplication
is required for subscript
calculations. Integer arithmetic
is exact.
encode operands for business
Integers can therefore be used to
applications such as bank automation which
require a larger range than that needed to an array.
(say) encode the indices of
Some hardware reflects this fact by distinguishing several
lengths of integer System/360.)
(e.g. half- and full-word integers on the IBM
A language on the Janus Level should therefore permit
the programmer to specify ranges of values which are relevant for his algorithm,
leaving the choice of representation to the translator.
Note that the set of possible ranges must not be fixed,
since that
would require a specification by the programmer which does not reflect the true needs of his algorithm.
If the language is machine-indepen-
dent, any fixed set of possibilities probably has no relevance for most target machines either! The concept of a range of values must be distinguished from the concept of a mode.
Range affects the manner in which a data object is
accessed, but not its interpretation as an operand.
This can be seen
in the description of the halfword add instruction of the IBM System/ 360
[IBM 1967]:
"The halfword second operand is expanded to a full-
word before the addition by propagating the sign-bit value through the 16 high-order bit positions. bits of both operands..."
Addition is performed by adding all 32 (The last sentence quoted and the remainder
of the description is identical to that for a fullword add instruction.)
567
If a set has N elements,
they may be p l a c e d in o n e - t o - o n e corre-
spondence w i t h the integers 0,i,
...
,N-I.
The d e f i n i t i o n of such a
c o r r e s p o n d e n c e is a r e p r e s e n t a t i o n a l d e c i s i o n w h i c h m i g h t specify m o r e p r o p e r t i e s of the set than necessary.
For example,
it w o u l d impose an
i r r e l e v a n t o r d e r i n g on a set w h i c h was c o n c e p t u a l l y unordered.
To
avoid this problem, we m u s t r e c o g n i z e the i n d e p e n d e n t e x i s t e n c e of finite sets.
The p r o g r a m m e r or language d e s i g n e r can then specify
certain sets w i t h e x a c t l y those p r o p e r t i e s needed, of e n c o d i n g to the translator.
leaving the choice
E x a m p l e s of such sets {false,
and the set of characters used in i n p u t / o u t p u t
communication.
true} These
o c c u r so f r e q u e n t l y that they are d i s t i n g u i s h e d as B o o l e a n and character modes respectively. Different manufacturers
use d i f f e r e n t e n c o d i n g s
some of w h i c h are not v a l i d r e p r e s e n t a t i o n s performs special
the c o n v e r s i o n from external
for characters,
of integers.
Hardware
to internal representation,
and
instructions are often available to m a n i p u l a t e these internal
representations.
In o r d e r to retain m a c h i n e independence,
acter set m u s t be assumed to be unordered.
the char-
Thus two c h a r a c t e r mode
objects may be tested for e q u a l i t y but not for relative magnitude, nor is a s u c c e s s o r function defined.
Also,
range is a m e a n i n g l e s s
concept b e c a u s e of the lack of order. There is another i m p o r t a n t finite set whose c h a r a c t e r i s t i c s
are
d e t e r m i n e d by the h a r d w a r e and o p e r a t i n g s y s t e m of the target computer:
the set of m e m o r y
locations.
A m e m o r y location is r e p r e s e n t e d
by an o b j e c t of address mode, w h i c h may be e n c o d e d in m a n y ways. in the case of c h a r a c t e r encodings, p r e s e n t a t i o n of an integer. assumed to be unordered,
The set of m e m o r y l o c a t i o n s m u s t also be
due to the d i f f e r e n t storage a l l o c a t i o n al-
g o r i t h m s u s e d in various situations. 5000 and 6000 series computers, ments of memory.
For example, on the B u r r o u g h s
arrays are a l l o c a t e d to d i f f e r e n t seg-
The r e l a t i o n s h i p b e t w e e n the
m e n t s may v a r y d u r i n g execution, dresses may be assumed.
As
an address may not be a v a l i d re-
~ d r e s s e s of two seg-
and h e n c e no o r d e r i n g of these ad-
(The o r d e r of elements w i t h i n a single array
is defined, however.) The lack of order in the sets of characters and m e m o r y locations precludes
i m p l e m e n t a t i o n of algorithms
dynamic storage allocation.
such as text sorting and m o s t
Each of these algorithms requires
some
additional o r d e r i n g p r o p e r t y w h i c h is not s p e c i f i e d for the set.
In
the case of a sort, the desired o r d e r is fixed by the p r o b l e m specifications and is i n d e p e n d e n t of the internal r e p r e s e n t a t i o n of characters.
The storage a l l o c a t i o n problem,
on the other hand,
does not
568
d e m a n d a p a r t i c u l a r order:
It m e r e l y requires that there be some
successor function d e f i n e d on memory locations so that linear scans of the entire allocatable area are possible.
Both kinds of order can
easily be imposed by p r o v i d i n g additional p r i m i t i v e functions on the elements of the set.
These additional
functions w o u l d be u s e d to
access the r e q u i r e d p r o p e r t y explicitly, was relevant. next,
and only w h e n that p r o p e r t y
Then i m p l e m e n t a t i o n w o u l d vary from one m a c h i n e to the
d e p e n d i n g upon the r e p r e s e n t a t i o n
chosen for the set.
M o s t e n g i n e e r i n g and scientific applications require o p e r a n d s w h i c h have a larger range than can be e c o n o m i c a l l y p r o v i d e d by a single value i n t e r p r e t e d as an integer.
A l s o m o s t of these c o m p u t a t i o n s
volve m e a s u r e m e n t s w h i c h are subject to inherent errors. be traded for range w i t h o u t
in-
P r e c i s i o n may
i n c r e a s i n g the storage r e q u i r e d for an ob-
ject by i n t e r p r e t i n g it as a m a n t i s s a - e x p o n e n t pair rather than a single integer.
P r e c i s i o n is lost b e c a u s e some bits of the o b j e c t are
d e v o t e d to the exponent,
thus leaving fewer available
for the mantissa.
This new i n t e r p r e t a t i o n of the o b j e c t is d i s t i n g u i s h e d as the primitive mode floating point.
F l o a t i n g p o i n t objects are ordered, but a
s u c c e s s o r function cannot be d e f i n e d if m a c h i n e - i n d e p e n d e n c e preserved.
is to be
S p e c i f i c a t i o n of e x p l i c i t ranges is also impossible on the
same grounds. 3.
F o r m a t i o n Rules P r o g r a m structure is p r o v i d e d by the formation rules of a lan-
guage.
They are c o n c e r n e d w i t h the g r o u p i n g of data objects
ceptual units,
and the d e f i n i t i o n of control structures.
into con-
In this sec-
tion I shall not explore the full range of formation rules available, but rather shall c o n c e n t r a t e upon those which are r e l e v a n t for the Janus level b e c a u s e they are r e f l e c t e d in the a r c h i t e c t u r e of cont e m p o r a r y computers. 3.1.
Expressions.
The m a j o r reason fDr using an e x p r e s s i o n is
to avoid naming each of the intermediate results created in the course of a computation:
When an operand of an e x p r e s s i o n
result is anonymous.
is evaluated,
the
The concept of an anonymous operand appears in
h a r d w a r e as the r e g i s t e r structure.
Details vary widely, b u t five
b r o a d categories cover m o s t computers: A.
No p r o g r a m m a b l e registers. operands
(IBM 1400 series, B.
All instructions take their
from m e m o r y and return their results to memory. IBM 1620)
A single arithmetic register.
U n a r y operators
take their
o p e r a n d from the register, b i n a r y o p e r a t o r s use its content as their left o p e r a n d and take their right o p e r a n d from
569
memory.
All operators
return their result to the register.
The a r i t h m e t i c r e g i s t e r often has an extension, w h i c h does not have the full c a p a b i l i t y of the m a j o r register.
(IBM
7090, Control Data 3000 series, m a n y minicomputers) C.
M u l t i p l e a r i t h m e t i c registers.
B i n a r y o p e r a t o r s may take
their right o p e r a n d either from a r e g i s t e r or from memory; all o p e r a t o r s
return their result to a register.
Some re-
gisters may be p a i r e d to provide an analog of the e x t e n s i o n in a s i n g l e - r e g i s t e r machine, same capabilities. D.
Hierarchy.
but all have e s s e n t i a l l y the
(IBM System/360)
Both operands of a b i n a r y o p e r a t o r m u s t be in
registers,
and all registers have e s s e n t i a l l y the same cap-
abilities.
All o p e r a t o r s return their result to a register.
This type of m a c h i n e could be c o n s i d e r e d identical to type (a), w i t h the registers age hierarchy. E.
Stack.
and m e m o r y
forming a two-level stor-
(Control Data 6000,
7000 series)
The top n locations of the stack h o l d the operands of
an n-ary operator, with the right m o s t at the top.
They are
r e m o v e d by the operator, w h i c h pushes its result in their place.
(ICL KDF9, B u r r o u g h s 5000 and 6000 series)
The n u m b e r of anonymous o p e r a n d s may exceed the number of registers in all cases except ory,
(e).
Excess operands m u s t be stored in mem-
thus e f f e c t i v e l y naming them.
This
is a r e p r e s e n t a t i o n a l
deci-
sion 9 ~ i c h m u s t be made on the basis of the target m a c h i n e characteristics,
and hence the Janus level should simply deal w i t h anonymous
results
as such.
3.2.
Names.
A name is an o b j e c t w h i c h refers to a n o t h e r object.
This concept appears in h a r d w a r e as the r a n d o m - a c c e s s memory:
Each
name defines a cell w h i c h may contain any object r e f e r r e d to by the name.
The name has a d e f i n i t e lifetime,
called its extent,
during
w h i c h the content of the d e f i n e d cell may be changed w i t h o u t affecting the name itself.
W h e n the extents of two names overlap,
names m u s t define disjoint
those
cells.
Names can be r e p r e s e n t e d by identifiers,
and accesses to the cells
w h i c h the names define are i n d i c a t e d by the a p p e a r a n c e of these identifiers.
A p a r t i c u l a r i d e n t i f i e r is made to represent a p a r t i c u l a r
name by m e a n s of a declaration.
This d e c l a r a t i o n has a scope w h i c h
defines the part of the program over w h i c h it is valid. static p r o p e r t y of the program,
whereas
S c o p e is a
extent is a dynamic property.
A single o c c u r r e n c e of an i d e n t i f i e r may r e p r e s e n t m o r e than one name.
For example,
c o n s i d e r a local v a r i a b l e of a p r o c e d u r e
in ALGOL
570
60.
Consequently, a new name is created each time the procedure is en-
tered and an occurrence of the identifier represents each of these names in turn.
The extents of the names represented by a local vari-
able are not disjoint if the procedure is invoked recursively, according to Section 4.7.3 of the ALGOL 60 Report
[Naur 1963].
Objects of address mode are used to implement names.
If the ex-
tents of any pair of names represented by the same occurrence of an identifier overlap, then the translator cannot specify a complete address to implement that occurrence of the identifier.
There are three
common mechanisms for providing the information to complete the specification at execution time: A.
Program modification.
The complete memory address is com-
puted by the program and placed into an instruction which is then executed. B.
(IBM 1400 series, IBM 1620)
Indirect addressing.
The complete memory address is computed
by the program and placed into some memory location. struction references that location, prets its content as an address.
The in-
and the hardware inter-
(IBM 1620, Burroughs 6000
series, many minicomputers) C.
Address modification.
The complete memory address is com-
puted by the hardware at the time the reference is made. Part of the data required to compute the address is supplied by the referencing instruction, the remainder is obtained from one or more processor registers.
(IBM System/360, Con-
trol Data 3000, 6000, 7000 series, Burroughs 5000, 6000 series) Selection of a particular m e c h a n i s m is obviously a representational decision which should be deferred until the characteristics of the target machine are known.
This means that access information must
be included in the specification of a named operand.
For example, a
local variable in ALGOL 60 might be distinguished from an own variable or a variable local to a containing block. 3.3
Aggregates.
An aggregate is a single object which is made
up of a number of distinguishable component objects.
These components
may be unordered or ordered, and may be of the same or different modes. (Most programming languages provide only for ordered aggregates in which all components are of the same mode.)
If the components are un-
ordered, then each is identified by a component name; dered, then each is identified by an integer index. are specified literally in the source program;
if they are orComponent names
indices, however, may
be computed during the execution of the program.
571
In m a n y p r o g r a m m i n g languages, r e s t r i c t e d to a range of integers.
the indices of an a g g r e g a t e are This r e s t r i c t i o n is unnecessary;
any o b j e c t w ~ i c h b e l o n g s to a finite set could b e u s e d to index an array w h i c h had one e l e m e n t for each o b j e c t in that set.
In order to
allocate storage for the array and to access an element,
a one-to-one
c o r r e s p o n d e n c e m u s t be e s t a b l i s h e d b e t w e e n the N e l e m e n t s of the set and the integers 0,I,
...
,N-I.
This c o r r e s p o n d e n c e m i g h t not be im-
p l i e d by the d e f i n i t i o n of the set, and m i g h t not be a r e l e v a n t prope r t y of the set for any o p e r a t i o n e x c e p t array indexing.
Such con-
straints do not affect the use of the o b j e c t as an index,
although
they w o u l d r e s t r i c t the o p e r a t i o n s a l l o w e d in index expressions. example,
consider an array indexed b y characters.
the c h a r a c t e r e n c o d i n g used by the m a n u f a c t u r e r p r o v i d e s one-to-one
c o r r e s p o n d e n c e w i t h a range of integers.
array w i l l vary from one m a c h i n e to another,
For
On each computer, an o b v i o u s
The size of the
as will the p a r t i c u l a r
element s e l e c t e d by a given character. Each a g g r e g a t e is u s u a l l y i m p l e m e n t e d as a contiguous area of m e m o r y d e f i n e d by a base, w i t h the p o s i t i o n of each c o m p o n e n t specified r e l a t i v e to that base.
W h e n the components
are unordered,
then
the t r a n s l a t o r is free to r e a r r a n g e t h e m if this w o u l d be advantageous. The c o m p o n e n t name is t r a n s l a t e d into a displacement,
d e f i n e d in terms
suitable for the target computer, w h i c h does not change d u r i n g execution of the program.
An a g g r e g a t e w i t h o r d e r e d components
cannot b e
r e a r r a n g e d by the translator, b u t c o m p o n e n t r e f e r e n c e s w h i c h do not change during e x e c u t i o n can c e r t a i n l y be c o n v e r t e d to displacements. Even if the index m u s t be c o m p u t e d d u r i n g execution, ble to d e c o m p o s e the index e x p r e s s i o n v a r i a b l e part.
it m a y be possi-
into the sum of a c o n s t a n t and a
The c o n s t a n t part can then be c o n v e r t e d to a d i s p l a c e -
m e n t by the translator.
Thus a general r e f e r e n c e to a c o m p o n e n t of a
d a t a a g g r e g a t e consists of a base,
a d i s p l a c e m e n t and an index w h i c h
m u s t be c o m b i n e d at the time the p r o g r a m is executed.
The h a r d w a r e
m e c h a n i s m s l i s t e d in S e c t i o n 3.2 are used to p e r f o r m this combination. It is i m p o r t a n t to d i s t i n g u i s h all three parts of the r e f e r e n c e b e c a u s e of the ways in w h i c h m a c h i n e s example,
access these aggregates.
For
it m a y be that a p a r t i c u l a r m a c h i n e i n s t r u c t i o n specifies an
address and an index r e g i s t e r w h o s e content is to be added to that address w h e n the i n s t r u c t i o n is executed.
In this case,
it is possi-
ble for the t r a n s l a t o r to combine the d i s p l a c e m e n t w i t h the b a s e to o b t a i n an e f f e c t i v e b a s e address.
S u c h a s t r a t e g y will not work,
however,
on a m a c h i n e w h i c h addresses data aggregates
example,
on the B u r r o u g h s
indirectly.
For
6700 the base is the address of a d e s c r i p t o r
572
which contains size.
a pointer to the aggregate itself and specifies
its
In this case, even though the displacement is available at com-
pile time,
it must be added to the value of the index at run time to
form an effective
index.
The hardware then combines this effective
index with the descriptor to yield the final reference. It may be that each component of an aggregate occupies only a part of an addressable memory location on the target computer.
The
number of memory locations which the entire aggregate occupies
could
then be reduced by packing the components instead of allotting one location to each.
This usually leads to a tradeoff, because the com-
ponents may be more difficult to access individually when the aggregate is packed.
On the other hand, if the aggregate is heavily used
as a unit, the difficulty of accessing individual components may be irrelevant. aggregates
The optimum representation depends upon the number of involved,
the size of each, the frequency of access to com-
ponents and the frequency of use of the entire aggregate as a unit. 3.4.
Procedures.
There are two aspects of procedure invocation:
control interaction and data interaction.
The control interaction is
realized by instruction that transfer control to the procedure and back to the calling program,
a process that involves saving status
before the transfer and restoring it upon return.
Data interaction
is established when a procedure accesses global data or arguments passed by the calling program,
and when it returns a value to the
calling program. It is useful to distinguish three components of the control interaction: gram
call, entry and return.
The status of the calling pro-
(consisting of a program address and an environment specification)
is passed to the procedure as an implicit argument. ments,
its value is known only at the point of call.
Like all arguTransfer of con-
trol to the procedure requires establishment of only a minimal status (consisting of the program address and argument values.)
Any further
environment is established at the point of entry to the procedure, where such items as the lexicographic level and the amount of local storage are known.
The status of the calling program is available at
each point of return, the procedure.
known at this point. and the
since this status is an implicit argument of
If a value is to be returned explicitly,
it is also
Restoring the caller's status returns control,
~ l u e may be passed as though it were a parameter.
Further
action may be required at the point of call to incorporate this value into the caller's environment. Control interaction is manifested in hardware by the mechanisms
573
for status saving and t r a n s f e r of control.
There are four common
methods: A.
R e l e v a n t status is p l a c e d on a stack by the h a r d w a r e w h e n a s u b r o u t i n e jump is executed.
B.
ICL KDF9)
R e l e v a n t status is p l a c e d in a r e g i s t e r by the h a r d w a r e w h e n a subroutine 1108,
C.
(Burroughs 5500,
jump is executed.
(Data General NOVA,
IBM System/360)
R e l e v a n t status
is p l a c e d in m e m o r y by the h a r d w a r e w h e n a
s u b r o u t i n e jump is executed.
The memory l o c a t i o n b e a r s
fixed r e l a t i o n s h i p to the target of the subroutine (CDC 3000, D.
UNIVAC
Separate
some
jump.
6000, XDS 940, UNIVAC 1108)
instructions
are p r o v i d e d for saving the r e l e v a n t
status and p e r f o r m i n g the s u b r o u t i n e jump.
(GE 645)
The m a k e u p of the " r e l e v a n t status" depends e n t i r e l y upon the computer. A t the least,
it contains the return address.
There are five common p a r a m e t e r m e c h a n i s m s
used to pass data to
a procedure: A.
Call , by value - The argument is e v a l u a t e d and its value p a s s e d to the procedure. bound variable
A s s i g n m e n t s to the c o r r e s p o n d i n g
(if permitted)
do not affect the argument
value in the calling program. B.
Call by result - This m e c h a n i s m is used to return values to the calling program.
Before the call,
p u t e d for the argument. ing program,
an address is com-
As control is r e t u r n e d to the call-
the value of the c o r r e s p o n d i n g b o u n d v a r i a b l e
is a s s i g n e d to the m e m o r y element s p e c i f i e d by that address. The a s s i g n m e n t takes place upon a normal exit from the procedure,
and hence is not made if a direct jump to a global
label is e x e c u t e d w i t h i n the procedure. C.
Call by v a l u e - r e s u l t - This is a c o m b i n a t i o n of
(a) and
(b).
The a r g u m e n t value is p a s s e d to the p r o c e d u r e and the value of the c o r r e s p o n d i n g b o u n d v a r i a b l e is copied back into the calling p r o g r a m when control is returned. D.
Call by r e f e r e n c e - The address of the argument is c o m p u t e d before the p r o c e d u r e is invoked,
and this address is passed.
Access to the c o r r e s p o n d i n g b o u n d v a r i a b l e p r o c e d u r e is indirect,
from w i t h i n the
and thus the a r g u m e n t itself is b e i n g
manipulated. E.
Call by name - The a r g u m e n t e x p r e s s i o n is c o n v e r t e d to a parameterless p r o c e d u r e which, w h e n invoked,
yields
the same
574
result as the argument. variable Methods
(a) and
is accessed,
Whenever
the corresponding
this procedure
(b) are the b a s i c ones;
bound
is invoked.
the other three can be syn-
thesized from them. The element
in the calling program that defines each argument
sets up a value that is passed to the procedure. address
in cases
(d) and
is an
(e); the object program must therefore have
the ability to m a n i p u l a t e chanisms
This value
is to be used.
addresses as values
if either of these me-
Call by result does not require
be passed t_~o the procedure,
that anything
but each argument must be updated when the
invocation of the procedure has been completed. Each of the three components distinguished
invocation must be
in order to defer all representational
the characteristics call"
of the procedure
is actually
of the target computer
a broad area which begins
decisions
are known.
until
The "point of
just before
the computa-
tion of the first argument value and ends just after any actions required to incorporate It is necessary invocations them.
returned values
into the caller's environment.
to distinguish both of these limits,
on some computers
(The "mark stack"
and "enter"
instructions
6700 are an example of this situation.) entry" must be considered of the procedure
to begin
the "point of
flexibility
Again,
sequence could be marked.
statement;
in the choice of
A procedure may have several returns, both the b e g i n n i n g
each involving
and end of such a
In this case, however,
been that a single return o p e r a t i o n 4.
of the Burroughs
Similarly,
and end just before the first executable
a sequence of actions.
at each of
just before the first declaration
both limits must be m a r k e d to permit representation.
since procedure
require distinct operations
my experience
has
is sufficient.
Conclusion Once the level of abstraction has been designed,
it can be real-
ized in two ways: -
Interpretation.
The level of abstraction
hardware or firmware, the same machine
is implemented
so that a range of machines
language.
in
all provide
This approach was taken by IBM for
System/360. - Translation.
Define a h i e r a r c h y of lower levels in which
ther representational different
abstract machines
representing stack,
decisions
etc.)
are made.
implemented on a given level,
a class of real computers
fur-
There may be several each
(e.g. multi-register,
575
Both approaches are viable,
the one which you take depends upon the
degree of control which you can exercise over the manufacturer. favor translation,
I
simply because I need portable programs now.
My group at the University of Colorado has carried out two experiments designed to measure the loss of efficiency resulting from the use of the Janus level of abstraction in the translation of Pascal [Wirth 1971]
to CDC 6400 machine code.
These experiments indicate
that we can expect that increases in space and time due to the presence of the intermediate language will be less than 15%. A companion paper by Dr. B. Eichenauer of ESG describes a specific application of the Janus level of abstraction to process
control.
Acknowledgmen ~ The development of Janus was supported by the National Science Foundation
under Grant GJ-32471.
References IBM: IBM System/360 Principles of Operation. Corp. 1967.
Sixth Edition,
IBM
Naur, P. (ed.), Revised report on the algorithmic language ALGOL 60, CACM 6 (1963), 1-17. Newey, M.C., P.C. Poole, W.M. Waite, Abstract machine modelling to produce portable software, Software, Practice and Experience 2 (1972), 107-136. Wirth, N., The programming language Pascal. 35-63.
Acta Informatic 1 (1971),
EIN P O R T A B L E R UBERSETZER FOR EINEN SUBSET D E R PROZESSPROfiRAMMIERSPRACHE PEARL B. E i c h e n a u e r 3. E i n f G h r u n ~ In z a h l r e i c h e n V o r t r ~ g e n und P u b l i k a t i o n e n
(z. B.
[~,2,3]) w u r d e in
den v e r g a n g e n e n
J a h r e n auf die V o r t e i l e h i n g e w i e s e n ,
yon PEARL
bei der E r s t e l l u n K yon ProzeBautomationsprogrammen
~,~
b i e t e n wtirde. Da b i s h e r sind diese V o r t e i l e
die der Einsatz
jedoch n o c h k e i n P E A R L - C o m p i l e r v e r f ~ g b a r ist,
z. Z. n i c h t n u t z b a r und ist a u c h die E r p r o b u n g
der in P E A R L v o r g e s c h l a g e n e n S p r a c h e l e m e n t e m i e r u n g a n h a n d eines h i n r e i c h e n d
fur die R e a l z e i t p r o g r a m -
groSen Spektrums unterschiedlicher
Automatisierungsaufgaben nicht mSglich. Im R a h m e n der PDV B e m ~ h u n g e n um eine s c h n e l l e E r p r o b u n g yon P E A R L und um die B e r e i t s t e l l u n g y o n P E A R L - P r o g r a m m i e r s y s t e m e n w u r d e die A r b e i t s -
Stuttgart-M~nchen-Erlangen (ASME) I) gegr~ndet,
gemeinsehaft
V o r h a b e n in zwei
S t u f e n u n t e r g l i e d e r t hat.
In Stufe
die ihr
i soll der v o r g e -
legte S p r a c h e n t w u r f y o n P E A R L an a u s g e w ~ h l t e n A u t o m a t i s i e r u n g s a u f g a b e n die Erler~barkeit sowie H a n d h a b b a r k e i t
erprobt,
die R e a l z e i t p r o g r a m m i e r u n g
der S p r a c h e l e m e n t e
und fur die P r o z e B - E i n / A u s g a b e
untersucht
und der S p r a c h v o r s c h l a g v e r b e s s e r t u n d / o d e r p r ~ z i s i e r t werden. a u f b a u e n d soll in Stufe 2 ein m o b i l e s schiedliche
ProzeBrechensysteme
und m S g l i c h s t
adaptierbares
fur
Darauf
e i n f a c h an unter-
PEARL-ProzeBprogrammier-
system bereitgestellt werden. Auch s c h o n in der g e g e n w ~ r t i g a b l a u f e n d e n E r p r o b u n g s s t u f e war es w e ~ e n der voneinander a b w e i c h e n d e n R e c h n e r t y p e n und G e r ~ t e s y s t e m e Partner
(AEG 6 0 - 5 0 und AEG 60-10 mit A E G - P e r i p h e r i e
S I E M E N S 306 mit C A M A C - P e r i p h e r i e zweckm~Big,
I)
in Stuttgart,
S I E M E N S 404/3 in MGnchen)
T e i l e des Erprobungssystems maschinenunabh~ngig zu planen.
W ~ h r e n d bei der I m p l e m e n t i e r u n g Realzeit-
in Erlangen,
der ASME-
der B e t r i e b s s y s t e m f u n k t i o n e n
fur die
und Ein/Ausgabeanweisungen des a u s g e w ~ h l t e n A S M E - P E A R L - S u b -
In der ASME sind f o l g e n d e P a r t n e r z u s a m m e n g e s c h l o s s e n : Erlangen:
2. p h y s i k a l i s c h e s
MGnchen:
ESG,
I n s t i t u t der U n i v e r s i t ~ t
Erlangen
Stuttgart:
I n s t i t u t fGr R e g e l u n g s t e e h n i k und P r o z e B a u t o m a t i s i e r u n g
Elektronik-System-GmbH
und I n s t i t u t
fur V e r f a h r e n s t e e h n i k und D a m p f k e s s e l -
w e s e n der U n i v e r s i t ~ t
Stuttgart
577
set/1
(APS/1)
L6] aus A u f w a n d s g r U n d e n soweit wie m S g l i c h auf die
Betriebssoftware portabler
der Z i e l m a s c h i n e n z u r G c k g e g r i f f e n wurde, m u s s t e
0 b e r s e t z e r fur den APS/I e r s t e l l t werden.
der A u f b a u des 0 b e r s e t z u n g s s y s t e m s rechensysteme
ein
Im f o l g e n d e n soll
u n d seine A d a p t i e r u n g
an P r o z e B -
skizziert werden.
2. Das 0 b e r s e t z u n ~ s s y s t e m
in Stufe
B e i m E n t w u r f des E r p r o b u n g s s y s t e m s den A P S / I m S g l i c h s t f U g b a r zu m a c h e n .
I k a m es in e r s t e r L i n i e d a r a u f an,
s c h n e l l fur die o b e n g e n a n n t e n Z i e l m a s c h i n e n ver-
Dabei
sollte
der A u f w a n d
o
zur 0 b e r f ~ h r u n g
o
zur A n p a s s u n g des c o d e e r z e u g e n d e n U b e r s e t z e r t e i l s
des 0 b e r s e t z u n g s s y s t e m s
auf und an
die Z i e l a n l a g e n m ~ g l i c h s t k l e i n g e h a l t e n w e r d e n . Bei der E r f O l l u n g der e r s t e n F o r d e r u n g w u r d e d a v o n a u s g e g a n g e n , fur die m e i s t e n R e c h n e r t y p e n , ASME,
insbesondere
F O R T R A N IV i m p l e m e n t i e r t
ist.
for die Z i e l r e c h n e r
dab der
Bei V e r w e n d u n g y o n F O R T R A N k a n n
s o w o h l die F o r d e r u n g n a c h g e r i n g e m A n p a s s a u f w a n d als auch, bei geeigneter Unterteilung
des U b e r s e t z u n g s v o r g a n g s
Forderung nach geringem Kernspeicherbedarf
i n m e h r e r e L~ufe~ gut e r f U l l t werden.
h i n a u s b i e t e t F O R T R A N als E r s t e l l u n g s s p r a c h e gegen~ber
e i n e m Bootstrapp-Verfahren
Programmerstellung
die Dar~ber-
f~r das E r p r o b u n g s s y s t e m
den V o r t e i l ,
dab die i n d i r e k t e
(z. B. f~r AEG 60-I0 auf CDC 6600 in S t u t t g a r t )
ohne die E r s t e l l u n g z u s ~ t z l i e h e r C o d e g e n e r a t o r e n
f~r die G a s t m a s c h i n e n
m S g l i c h ist. Zur E r f ~ l l u n g der z w e i t e n F o r d e r u n g w u r d e der 0 b e r s e t z e r in A n l e h n u n g an b e k a n n % e
Verfahren
(z. B. [7, 8]) in e i n e n maschinenunabhangigen
und in m a s c h i n e n a b h ~ n g i g e
D u t c h den maschinenun-
Teile a u f g e s p a l t e n .
a b h ~ n g i g e n A P S / 1 - U b e r s e t z e r w e r d e n in APS/~ g e s c h r i e b e n e
Automations-
programme
y o n wo sie
mittels
in die Z w i s e h e n s p r a e h e
CIMIC/I
[9] O b e r s e t z t ,
Cedegeneratoren in den A s s e m b l e r der Z i e l r e c h n e r U b e r f O h r t
werden. Bei der K o n z i p i e r u n g zu b e r O c k s i e h t i g e n ,
des m a s c h i n e n u n a b h ~ n g i g e n
auf ~ u e l l s p r a c h e n e b e n e
Weehsel
des Z i e l m a s e h i n e n t y p s
ProzeSrechner-Geratesystems
teils
dem A P S / 1 - 0 b e r s e t z e r
beschrieben wird
(Systemteil).
in der R e g e l auch e i n e n W e c h s e l
bedeutet,
jeweils e i n g e s e t z t e n
Dazu w u r d e
war
dab in P E A R L die Konfiguration eines P r o z e S r e c h e n -
systems
die vom
Ubersetzerteils
musste
Ger~tesystem
Da der des
d a f ~ r g e s o r g t werden,
abh~ngige
in e i n f a c h e r Weise z u f ~ h r b a r ist.
eine e i n f a c h e L i s t e n s p r a e h e
entworfen,
dab
S y n t a x des System-
mit der sieh die
578
U b e r s e t z u n g s l i s t e f U r das l i s t e n g e s t e u e r t e Ubersetzers
f o r m a l d a r s t e l l e n l~sst.
liste w u r d e u n t e r w e i t g e h e n d e r V e r w e n d u n g den A P S / l - U b e r s e t z e r
A n a l y s e p r o g r a m m des APS/i-
Der G e n e r a t o r fur die ~ e r s e t z u n g s des A n a l y s e p r o g r a m m s
fur
erstellt.
Um auch die s c h n e l l e E r s t e l l u n g y o n C o d e g e n e r a t o r e n zu e r m S g l i c h e n , wurde
die Z w i s c h e n s p r a c h e
vorgeschlagene
C I M I C / I in A n l e h n u n g an das y o n W. M. Waite
JANUS-Konzept
[10, I ~
ung mit dem m o b i l e n M a k r o F e n e r a t o r kann.
Da s i c h STAGE2 i n n e r h a l b
(FORTRAN) und e i n e r M a n n w o c h e
so gewahlt,
STAGE2
[I 4
da~ die C o d e g e n e r i e r -
bewerkstelligt
(Assembler)
g e n e r i e r e n l~sst,
Z i e l r e c h n e r mit e i n e m n u t z b a r e n K e r n s p e i c h e r y o n m i n d e s t e n s schnell
werden
einer Z e i t s p a n n e y o n w e n i g e n M i n u t e n steht f~r 16 K Worte
ein S y s t e m zum b e q u e m e n E r s t e l l e n des C o d e g e n e r a t o r s
und zur
D u r c h f ~ h r u n g der C o d e g e n e r i e r u n g zur V e r f U g u n g . In Abb.
Iist
stellt.
Auf der l i n k e n Seite der A b b i l d u n g s i n d die o b e n e r w ~ h n t e n
die S t r u k t u r des 0 b e r s e t z u n g s s y s t e m s
Darstellungsformen angegeben.
eines A u t o m a t i o n s p r o g r a m m s
fur Stufe
I darge-
w ~ h r e n d der U b e r s e t z u n g
Die im m i t t l e r e n Teil der A b b i l d u n g d a r g e s t e l l t e n P r o g r a m m e :
A P S / l - U b e r s e t z e r u n d STAGE2 l i e g e n wie aueh das e r w e i t e r t e E i n / A u s g a b e p r o g r a m m y o n S T A G E 2 in F O R T R A N v o r u n d Anlage ohne Anpassaufwand Bei der U b e r f U h r u n g
lauff~hig
d U r f t e n auf einer E r S B e r e n
sein.
auf e i n e n P r o z e B r e c h n e r
des U b e r s e t z u n g s s y s t e m s
ist es i. a. z w e e k m ~ B i g ,
STAGE2 im A s s e m b l e r
k a n n der S p e i c h e r b e d a r f
fur den C o d e g e n e r a t o r
zu g e n e r i e r e n .
Dadureh
(STAGE2-Memory)
U b e r der F O R T R A N - V e r s i o n in der R e g e l um I/3 r e d u z i e r t w e r d e n . ist aus S p e i c h e r p l a t z g r U n d e n
die N e u e r s t e l l u n g
geEenWeiter
des E i n / A u s g a b e p r o g r a m m s
erforderlich. Die bei der A d a p t i e r u n g des U b e r s e t z u n g s s y s t e m s
an ein P r o z e ~ r e c h e n -
s y s t e m zu g e n e r i e r e n d e n L i s t e n sind auf der r e e h t e n Seite y o n Abb.
I
dargestellt. ~° Die Zwigphensprache
CINIC/I
C I M I C / I ist eine A s s e m b l e r s p r a e h e Sie w u r d e
fur eine a b s t r a k t e
Einadressmaschine.
s p e z i e l l fur den APS/I e n t w i c k e l t und dient als I n t e r f a c e
z w i s c h e n dem m a s c h i n e n u n a b h ~ n g i g e n
APS/~-Ubersetzer
und C o d e g e n e r a t o r e n
fur r e a l e M a s c h i n e n . A n w e i s u n g e n fur die S p e i c h e r p l a t z r e s e r v i e r u n g , arithmetisehen Programmgr~Sen sequentielle
(Ganzzahlen,
zur B e a r b e i t u n g y o n
Gleitpunktzahlen),
A b l a u f s t e u e r u n g u n d f~r die Definition
fur die
u n d den A u f r u f
yon P r o z e d u r e n w u r d e n w e i t g e h e n d dem v o n W. M. W a i t e v o r E e s c h l a g e n e n
579
I
Automations- / p,og . . . .
,nA,'s,, J
/
I
i i
i APS/1-
(FORTRAN)
ogramm CIMIC/1 --
Ein/Ausgabeprogramm
i ..
(FORTRAN oder Assembler)
!
1
-,...
STAGE 2
!/
f~ den System-
i L
teii
~ _/
Obersetzer
,,~i
(FORTRAN odeI Assembler) J
--
/
i i i i i i i i i
!
b'/ :e:m°oo. I I
i
....bler/
ogramm
I
z1imel
_
i
/
i
i
©
I
i
Abb, 1 Da$ portable Obersetzungssystem in Stufe I des ASME-Vorhabens
JANUS-Satz entnommen. Welter wurden die FormatierunEsgesetze beibehalten,
yon JANUS
um u. a. die schnelle Erstellung yon Codegeneratoren mi%
STAGE2 zu ermSglichen. W~hrend JANUS haupts~chlich den algorithmischen Tell der Zwischensprache,
d. h. den normalerweise unmittelbar in Maschinenbefehle
um-
setzbaren T e i ~ abdeckt, wurden in CIMIC/I die im APS/I zugelassenen neuartigen 0perandentypen aufgenommen.
(z. B. TASK, DURATION,
CLOCK, SEMA, DEVICE)
Es wurde abet in Stufe I) abgesehen yon wenigen Ausnahmen
580
(z. B. bei BIT, wirkende
CLOCK,
DURATION)
darauf verzichtet,
0peratoren einzufGhren.
tierungsgesetze
auf diese
Operanden
Dazu w ~ r e n E r w e i t e r u n g e n der Forma-
e r f o r d e r l i e h gewesen,
die nut z u s ~ t z l i c h e n A u f w a n d bei
der E r s t e l l u n g y o n C o d e g e n e r a t o r e n b e d e u t e n w ~ r d e n .
Da die n e u e n 0peran-
d e n t y p e n fast a u s s c h l i e B l i c h d u r e h F u n k t i o n e n des B e t r i e b s s y s t e m s b e i t e t werden,
wurden stattdessen
Standard-Prozeduraufrufe
Die f£1r das E r p r o b u n g s s y s t e m v o r g e s e h e n e e i n e m Speicher,
bear-
vorgesehen.
a b s t r a k t e M a s c h i n e b e s t e h t aus
e i n e m A k k u m u l a t o r u n d einem I n d e x r e g i s t e r .
Jedes
Spei-
c h e r w o r t u n d jedes R e g i s t e r k a n n alle a r i t h m e t i s c h e n und l o g i s c h e n Operandentypen aufnehmen. Register
Wesentliches war,
Ihre V e r a r b e i t u n g g e s c h i e h t in e i n e m der
(in der Regel im A k k u m u l a t o r ) . E n t w u r f k r i t e r i u m bei der K o n z i p i e r u n g v o n J A N U S u n d C I M I C / I
dab m S g l i c h s t
alle I n f o r m a t i o n ,
die bei der U b e r s e t z u n g
einer
A n w e i s u n g in den A s s e m b l e r einer Z i e l m a s c h i n e n S t i g ist, in der Anweisung
selbst e n t h a l t e n ist.
Auf diese Weise
sind z e i t r a u b e n d e
i n s b e s o n d e r e mit S T A G E 2 nut in sehr i n e f f i z i e n t e r Adressbuchzugriffe
und
Weise a u s f G h r b a r e
bei der C o d e g e n e r i e r u n g v e r m e i d b a r .
In C I M I C / I gibt es im w e s e n t l i c h e n die f o l g e n d e n b e i d e n F o r m a t i e r u n g s regeln: a)
o p e r a t i o ~ u m o d e u mode] .
b)
operationumodeucategoryulocationu[option ] .
Regel a) w i r d u. a. f~r R e g i s t e r - R e g i s t e r - A n w e i s u n g e n
eingesetzt.
Bei-
spielsweise wird durch C V R T INT REAL. eine im A k k u m u l a t o r
gespeicherte
G a n z z a h l in eine
Gleitpunktzahl
gewandelt. Pseudoanweisungen t i o n y o n Marken~
zur R e s e r v i e r u n g y o n S p e i c h e r p l a t z
T a s k s und P r o z e d u r e n sind wie alle O p e r a n d e n a n w e i s u n g e n
n a c h Regel b) a u f g e b a u t . code
(operation),
0peranden
sowie zur Defini-
Die A n w e i s u n g e n b e s t e h e n aus dem O p e r a t i o n s -
dem Typ des
(category),
Operanden
(mode),
der a b s t r a k t e n Adresse
der S p e i c h e r k l a s s e
des
(location) und e v e n t u e l l
aus einer y o n den e r s t e n drei A n w e i s u n g s f e l d e r n a b h ~ n g i g e n Option. Die a b s t r a k t e
A d r e s s e ist gemaS:
location ::= { symbol([ct-expression])[~ aufgebaut.
Sie b e s t e h t
vom A P S / 1 - U b e r s e t z e r
/ (ct-expression) l
in der Regel aus einem B e z e i c h n e r
g e n e r i e r t wird,
rierung auszuwertenden Ausdruck
(symbol),
der
und aus e i n e m bei der C o d e g e n e -
(or-expression).
581
Die V e r w e n d u n g
der e i n z e l n e n A n w e i s u n g s f e l d e r w i r d im f o l g e n d e n a n h a n d
y o n drei B e i s p i e l e n e r l ~ u t e r t . Speicherplatzreservierung Speicherplatzreservierungen eingeleitet.
Als
(z. B. INT,
REAL,
w e r d e n d u t c h die S P A C E - P s e u d o o p e r a t i o n
"mode" tritt ein im A P S / I z u g e l a s s e n e r D a t e n t y p CLOCK)
auf. Die S p e i c h e r k l a s s e n MODUL,
LOCAL,
CONST
und P A R A M e r m S g l i c h e n bei der C o d e g e n e r i e r u n g
die u n t e r s c h i e d l i c h e
Behandlung yon GrSBen auf Modulebene,
GrS~en,
Parametern. und aus
"ct-expression" besteht
lokalen
aus G a n z z a h l e n ,
den O p e r a t o r e n + , - , ~ , / und gibt die Anzahl
K o n s t a n t e n und
Manifestwerten der a d r e s s i e r b a r e n
E i n h e i t e n im S p e i c h e r eines
Zielrechners
dutch
GrS~e zu v e r g e b e n sind. Bei K o n s t a n t e n
"symbolt' b e z e i c h n e t e n
und e i n f a c h e n V a r i a b l e n mit Feld angegeben~
A n f a n g s w e r t e n w i r d der Wert im "option"-
Initialwerte
SPACE-Pseudoanweisungen
an, die zur D a r s t e l l u n g der
f~r F e l d e l e m e n t e
w e r d e n in w e i t e r e n
definiert.
Beispiele:
CIMIC/1
APS/I
DCL D DURATION;
SPACE D U R L O C A L D()
DCL C C L O C K I N I T I A L ( O : 1 : 2 ) ;
SPACE CLOCK MODUL
D C L K(2) R E A L I N I T I A L ( I . 5 , 7 0 . ) ;
SPACE R E A L M O D U L K ( 2 * R E A L ) +
F: F O R M A T ( F 3 , P A G E ) ;
C() 0:1:2.
SPACE R E A L M O D U L
(1) 15E-1.
SPACE R E A L M O D U L
(1) 7E1.
SPACE F O R M L O C A L F ( 4 * F O R M ) + SPACE FORM LOCAL
(1)
SPACE F O R M L O C A L
(1) F3.
.
.
(.
SPACE FORM LOCAL (1) PAGE. SPACE F O R M L O C A L
Die a b s t r a k t e
A d r e s s e w i r d wie folgt a u s g e w e r t e t :
eine a d r e s s i e r b a r e
E i n h e i t im S p e i c h e r
in festem Abstand befindliche pression"
a n g e s p r o c h e n werden.
registers wlrd durch
(1)).
"symbol" definiert
einer Z i e l m a s c h i n e .
E i n h e i t k a n n d u r c h Angabe y o n R e l a t i v i e r u n g bzgl.
DCL A(IOO) D U R A T I O N , A(I+I)
"ct-ex-
des C I M I C - I n d e x -
"+" f e s t g e l e g t .
Die A P S / 1 - A n w e i s u n g e n :
Eine d a z u
= A(I) + A(5);
IINT;
582
w e r d e n in f o l g e n d e
CIMIC/1-Anweisungen Gbersetzt:
SPACE INT C O N S T SI() E DUR.
SPACE D U R L O C A L A ( I O O * D U R ) S P A C E INT L O C A L I()
L D X I N T L O C A L I()
LAENGE EINER DUR-GROESSE
o
SPEICHERPLATZ
SPEICHERN
FUER A ANLEGEN
SPEICHERPLATZ FUER I ANLEGEN
.
LADE INDEXREGISTERMIT
.
M P X INT C O N S T $I() E DUR.
FELDELEMENTADRESSE
LOAD DUR LOCAL A(-DUR)+
A K K U M I T A(I) L A D E N
.
ADD D U R L O C A L A ( 4 " D U R )
A(5)
STORE D U R L O C A L A()+
A K K U N A C H A(I+I)
•
I
BERECPL~EN
ADDIEREN ABSPEICHERN
Taskdeklaration Eine T a s k d e k l a r a t i o n w i r d in e i n e m C I M I C / I - M o d u l mit der P s e u d o a n w e i sung: BEGIN TASK MODUL symbol() e i n g e l e i t e t und mit: END T A S K M O D U L s y m b o l ( )
.
beendet.
4. C o d e g e n g r i e r u n g mit
STAGE2
Die L a u f z e i t y o n P r o g r a m m e n , Makrogenerator H~ufigkeit
die mit dem i n t e r p r e t a t i v
STAGE2 e r s t e l l t werden,
Codegeneratoren
sondere
e r s t e l l e n zu kSnnen,
da~ die s c h n e l l
Um mit S T A G E 2 s c h n e l l a b l a u f e n d e w u r d e die S y n t a x y o n C I M I C / I so
a b l a u f e n d e n F u n k t i o n e n des G e n e r a t o r s ,
die M u s t e r e r k e n n u n g ,
Als B e i s p i e l
insbe-
m S g l i c h s t h ~ u f i g e i n s e t z b a r sind.
fur den E i n s a t z y o n S T A G E R soil im f o l g e n d e n die Code-
g e n e r i e r u n g fur die v e r e i n f a c h t e c)
e m p f i n d l i c h y o n der
ab, mit der die v e r s c h i e d e n e n P a r a m e t e r k o n v e r s i o n e n und
Prozessorfunktionen verwendet werden.
gew~hlt,
h~ngt
arbeitenden
SPACE-Pseudooperation:
SPACE ~ I I N T I u C O N S T u s y m b ° l ()u c o n s t a n t - d e n o t a t i o n . [ REAL~
auf A s s e m b l e r A S S L S ~ O 4 / 3 d a r g e s t e l l t w e r d e n .
583
Anweisungen
v o m Typ
c) k S n n e n
mit
dem f o l g e n d e n
Makro
bearbeitet
wer-
den: FOR BEISPIEL
%~o %20 %3o~
AUFRUF
DES
$
ENDE
SPACE
2
3 Das
MUSTER
I
in Zeile
' CONST
'()
I angegebene
f~r Parameter.
Die
~iO bei
der
ersetzt
werden
'.
Muster
enth~It
soll.
des M a k r o s
$ ist
CODEGENERIERENDEN
MAKRO
DER MAKRODEFINITION
Parameterkonversion
Ausf~hrung
C)
Hochkommas
als
%i0 i n Z e i l e
durch
den Z-ten
das E n d e z e i c h e n
f~r
Platzhalter
2 besagt,
aktuellen
die
Zeilen
dab
Parameter
des M a k r o -
kSrpers. Bei
der A u s f ~ h r u n g
wie
in Zeile
als
Pseudoinput
kSnnen
f~r
des M a k r o s
2 angegeben f~r
404/3
stellt
zusammen
STAGE2
u n d die
die M u s t e r e r k e n n u n g
mit
folgendem 4
REAL
Parameter
so k o n s t r u i e r t e
zur
einfachen
die a k t u e l l e n
Verfdgung.
Makro
Zeile
wieder
REAL-Konstanten
generiert
werden:
' '.
6 Die
%F12 i n Z e i l e 5 gibt an, dab die Zeile n a c h
Prozessorfunktion
Einsetzen
de]: a k t u e l l e n
Parameter
2 auszugeben
auf File
ist.
Ft[r die
SPACE-Pseudooperation SPACE wird
z. B. die
Im Fall
REAL
in Zeile
5E7. (($27)
5E7
Ganzzahlkonstanten
y o n 0 bis
generiert.
ist
zu b e r H c k -
19 auf ~ 0 ~ / 3 im B e f e h l s w o r t
sind: 7
INT
8
IF %20 GT
9
IF %20
~0
Konstante
f~r
dab die K o n s t a n t e n
darstellbar
$27()
ASSLS-Konstantendefinition:
der P l a t z r e s e r v i e r u n g
sichtigen,
Die
CONST
8 und
' '. I LINES~ I LINES~
(%10) %20%F12~
9 verwendeten
im B e f e h l s w o r t
15 SKIP
GT -I SKIP
Platz
12
IF
13
%F6+~
Makroaufrufe
findet
' GT
untersuchen,
und lassen
' SKIP
' LINES.
sich
ob die
gem~B:
584
unmittelbar
auf die P r o z e s s o r f u n k t i o n
6 y o n STAGE2 z u r G c k f G h r e n .
S p e i c h e r p l a t z f~r G a n z z a h l k o n s t a n t e n w i r d nut r e s e r v i e r t , Konstante
n i c h t im B e f e h l s w o r t
Mit ~ h n l i c h e i n f a c h e n M a k r o s Codegenerators
w e n n die
d a r s t e l l b a r ist.
l~sst
sich der ~ b e r w i e g e n d e
f~r die Z w i s c h e n s p r a c h e
Tell des
CIMIC/I aufbauen.
~. Z u s a m m e n f a s s u n ~ Bei der E n t w i c k l u n g auf ~ u B e r s t e
des d a r g e s t e l l t e n E r p r o b u n g s s y s t e m s und auf E f f i z i e n z bzgl.
Codeeffizienz
zeit z u g u n s t e n einer s c h n e l l e n V e r f U g b a r k e i t keit
des U b e r s e t z u n g s s y s t e m s
verzichtet. in Stufe
und
an die Z i e l s y s t e m e
wurde bewusst
der U b e r s e t z u n g s -
einfachen
Anpassbar-
der A S M E - P a r t n e r
Diese E i n s c h r ~ n k u n g e n w a r e n n o t w e n d i g ,
um e i n e r s e i t s
das
2 g e p l a n t e P E A R L - P r o g r a m m i e r s y s t e m y o n elmer in der A n w e n d u n g
e r p r o b t e n Basis h e r e n t w e r f e n und um a n d e r e r s e i t s portabler ProzeBprogrammiersysteme
die mit der E r s t e l l u n g
verbundenen besonderen Problem-
s t e l l u n g e n b e s s e r k e n n e n l e r n e n zu k~nnen. Die zur Zeit b e t r i e b e n e n
Strukturierungs-
an Stufe 2 des A S M E - V o r h a b e n s m i e r s y s t e m mit
und I m p l e m e n t i e r u n g s a r b e i t e n
w e r d e n zu einem p o r t a b l e n P E A R L - P r o g r a m -
der fur den i n d u s t r i e l l e n E i n s a t z
und B e d i e n u n g s e f f i z i e n z
erforderlichen
Code-
f~hren.
Literaturangaben
~1]
J. B r a n d e s
et. al.
: A Realtime Language
for m e a s u r i n g p r o c e s s e s , [~
B. E i c h e n a u e r : of i n t e r m e d i a t e Programming,
[4
[~]
R. Lauber:
IFAC Congress,
Real-time-programming level,
Erlangen
f~r P r o z e S r e c h n e r ,
Jan.
K. H. T i m m e s f e l d et. al.
A proposal
z PEARL,
automation realtime
B. E i c h e n a u e r ,
V. Haase,
eine p r o z e B -
Angewandte
Heft
Vorlaufige
9/73,
in
for a p r o c e s s Gesellschaft
KFK-PDV
E. K r e u t e r ,
und e x p e r i m e n t o r i e n t i e r t e
Informatik,
B. E i c h e n a u e r :
language,
PDV-Bericht
P. H o l l e c z e k ,
Seminar
197~
h S h e r e r A u t o m a t i k der E T H Z~rich,
PEARL,
[6]
S e m i n a r an R e a l - T i m e -
(1972)
Programmiersprachen
and e x p e r i m e n t
(1972)
using a real-time-language
Second European
K e r n f o r s c h u n g mbH, K a r l s r u h e , ~]
and its a p p l i c a t i o n Paris
I, April
f~r
1973
G. M~ller:
Programmierspraehe,
363-372
S p e z i f i k a t i o n eines
Ausgangssubsets
585
ffir die ASME, Arbeitspapier des Subset Arbeitskreis beim Projekt PDV, SAK-18-73 [7]
J. Sklansky, M. Finkelstein, E. C. Russel: A Formalism for Program Translation, JACM, Vol. 15, No. 2, April 1968, pp. 165-175
[4
M. Richards: The Portability of the BCPL Compiler, Software Practice and Experience, Vol° I, 135-I~6 (1971)
9]
CIMIC/I Vorlaufige Spezifikation, PDV-Entwieklungsnotizen, PDV-E 15
~
W.M.
(1973)
Waite: Software Portability via an Intermediate Language,
im vorliegenden Tagungsband enthalten. ~
P. C. Poole: Portable and Adaptable Compilers, Advanced Course on Compiler Construction, Techn. University of Munich, March ~97~
~2]
W.M.
Waite: Implementing Software for Non-Numeric Applications,
Pentice-Hall Inc., Englewood Cliffs, N. J. (1973)
LEISTUNGSKRITERIEN
VON
PROZESSRECHENSYSTEMEN
Rudolf Lauber Institut ffir Regelungstechnik und Prozegautomatisierung der Universit~t Stuttgart 1.
Einleitung
In Analogie zur mechanischen Leistung wird bei Rechenanlagen,
die im
Stapelbetrieb eingesetzt sind, im allgemeinen der Durchsatz(Jobs/Zeiteinheit) bzw. die Durchsatzrate als Bewertungsgr~ge ffir die Leistung verwendet [i] . Von Hellerman [2,~ wurde vorgeschlagen,ffir die Arbeit einer Rechenanlage die Ma~einheit "wit" {work bit) und entsprechend ffir die Leistung "war" (work bits/sec) einzuffihren. Im Gegensatz zu den Rechenanlagen f~r Stapelbetrieb fdhren Prozegrechenanlagen ihre Informationsverarbeitungsaufgaben im Zusammenwirken mit einem technischen Prozeg aus. Der Begriff der Leistung ist daher nur fflr das gesamte Prozegautomatisierungssystem, bestehend aus Prozegrechensystem und Prozeg, sinnvoll. Zur Bewertung eines Prozegrechensystems wird nicht nach der Leistung, sondern nach der Leistungsf~higkeit gefragt. Wegen der Wechselwirkung zwischen Prozeg und Prozegrechensystem ist die Leistungsfghigkeit nur definierbar, wenn Angaben gemacht werden ~ber - den vom Prozeg im ungfinstigsten Fall verlangten Umfang der Informationsverarbeitung w~hrend eines angenommenen Zeitraumes
(maximale Auftragslast)
In diesem Vortrag wird @ber Ergebnisse eines Arbeitskreises
"Proze~-
rechensysteme-Leistungskriterien" der VDI/VDE-Gesellschaft f~r Megund Regelungstechnik (Bereich Technik der Proze~rechner) berichtet. Derzeitige Mitglieder des Arbeitskreises: N. Gellekum, Bundesbahnzentralamt M~nchen; W. Krause, Siemens Erlangen; B. Krfiger, BBC Mannheim; R. Lauber, Universit~t Stuttgart (Obmann); O. Neff, Universit~t Stuttgart; H. Ripperger, Siemens Erlangen; N. Schwarz, AEG-Telefunken Berlin; H.J. Stfibler, Hoesch Hfittenwerke Dortmund, H. Tripp, RWE Essen.
587 -
die dabei einzuhaltenden Zeitbedingungen (bei einem P r o zeBrechner kann die E~nkaltung yon Zeitabst~nden gleich wichtig sein wie die Informationsverarbeitung
selbst).
Dar~ber hinaus m~ssen alle Eigenschaften mit berNcksichtigt werden, die in die Arbeitsf~higkeit des gesamten ProzeBautomatisierungssystems gehen, wie z. B. Zuverl~ssigkeit, Wartbarkeit,
ein-
zul~ssige Umgebungsbe-
dingungen usw. Daraus folgt, dab die Bewertung der Leistungsf~higkeit eines ProzeBrechensystems letztlich nur anwendungsabh~ngig,
d. h. f~r ein bestimm-
tes Automatisierungssystem,
mSglich ist. D e r A r b e i t s k r e i s
"ProzeBrechen-
systeme-Leistungskriterien"
der GMR, fiber dessen erste Ergebnisse hier
berichtet wird, hat sich aus diesem Grunde zur Aufgabe gestellt, anwendungsunabh~ngige
Leistungskriterien
zu erarbeiten, die dann zu einer
anwendungsabh~ngigen Bewertung der Leistungsf~higkeit einsetzbar sind. Im Folgenden soil zun~chst eine Obersicht fiber die bisher bekannten Verfahren zur Beurteilung der Leistungsf~higkeit yon Rechenanlagen und deren Anwendbarkeit auf ProzeBrechensysteme
gegeben werden. Anschlie-
Bend wird auf die Kennzeichnung der LeistungsfRhigkeit durch Leistungskriterien
(anwendungsunabh~ngig ffr die Leistungsf~higkeit wichtige Ei~
genschaften) 2..
eingegangen.
Methoden zur Bewertung der Leistungsf~higkeit
(Bild l)
Zur Bewertung der Leistungsf~higkeit yon Rechenanlagen - sei es zum Zwecke einer Kaufentscheidung oder zur optimalen Auslegung einer gegebenen A n l a g e -
lassen sich grunds~tzlich 3 Vorgehensweisen unterschei-
den: - Analytische Verfahren - Simulative Verfahren - Empirische Verfahren 2.1.
Analytische Verfahren
2.1.1. "Deterministische" Verfahren Wie oben bereits erw~hnt, wurde in [2] ein analytisches Verfahren zur Ermittlung der Rechenarbeit
(Informationsumformungsarbeit)
vorgeschla-
gen. Dabei wird davon ausgegangen, dab sich die Abl~ufe in Rechenanla~ gen in einzelne Rechenschritte zerlegen lassen und dab ffr einen Rechenschritt eine "Rechenarbeit" defiAierbar ist. Abgesehen davon, da~ es sich hier um erste - m~glicherweise
f@r die
588
Verfahrenzur Bewertung der Leistungsf~higkeityon ProzeFIrechensystemen
.~
!
|
J
J Analytische 1 Verfohren
._t..Det
erministische"I Verfahren I
._~
Simulative Verfahren J
_J Benchmark- I Tests
,, Stochasti sche" Verfohren
.~
I
Empirische J Verfahren listen yon , Eigenschaften
/I"Jl kni~pfung Li.eor, Veryon
i
i Leistungskriterien
--~
Mixe
._~ NichtlineareVer-1 kn~pfungyon J Leistungskriterien/
Bild I: Obersicht Gber die wichtigsten Verfahren zur Bewertung der Leistungsf~higkeit yon Rechensystemen. weitere Forschung fruchtbare - Ans~tze f@r ein analytisches Verfahren handelt, dGfte die bei der Anwendung auf Proze~rechner unumg~ngliche Einbeziehung zeitlicher Randbedingungen fGr die Rechenvorg~nge bzw. Rechenschritte schwierig sein. 2.1.2."Stochastische" Verfahren Das Ablaufgeschehen in Rechenanlagen umfa~t den Transport yon Befehlen und Daten zwischen Funktionseinheiten bzw. Teilsystemen und deren Bearbeitung in den Teilsystemen.
Dabei k6nnen dutch Engp~sse Wartezei-
ten eintreten. Der zeitliche Ablauf derartiger Transport -, Warte- und Bearbeitungsphasen l~gt sich als stochastischer Vorgang auffassen und mit den Methoden der Wahrscheinlichkeits- und Warte~schlangentheorie analytisch beschreiben [4] . Ziel einer darauf aufgebauten Untersuchung ist es, das Rechensystem durch GGtekriterien wie etwa mittlerer bzw.
589 maximaler Durchsatz, Wartezeitverteilungsfunktion~ mittlere Warteschlangenl~nge usw. zu beurteilen. Eine analytische Behandlung nach diesen wahrscheinlichkeitstheoretischen Verfahren ist nur mSglich, wenn stark vereinfachte Modelle ffir die Rechensysteme angesetzt werden. So wird z. B. zur Ermittlung der Verteilung der Bedienungszeit ein Prozessor durch eine mittlere Befehlsausffihrungszeit ~kennzeichnet.Wegen dieser Vereinfachungen werden diese Verfahren im allgemeinen nicht zu Leistungsvergleichen alternativer Rechenanlagen eingesetzt. Vielmehr liegt der Schwerpunkt der Anwendung bei dem Vergleich verschiedener
Organisationsstrategien
an Hand der
oben genannten Gfitekriterien, und zwar f~r Rechensysteme mit stochastischem "Ankunftsproze~" (wie z. B. Rechenanlagen im Timesharing/Multiprogramming - Betrieb oder Realzeitrechensysteme mit Dialogverkehr). FOr Proze~rechensysteme d~rfte diese Voraussetzung im allgemeinen nicht erfOllt sein, so da~ die Anwendbarkeit zur Leistungsbewertung auch aus diesem Grunde kaum in Frage kommt. 2.2.
Simulative Verfahren
Der Grundgedanke bei diesen Verfahren besteht darin, die im echten Einsatz zu leistenden Informationsverarbeitungsaufgaben einer Rechenanlage zu simulieren und die Verarbeitungszeit als Vergleichszahl f~r die Leistungsf~higkeit zu verwenden. Aus Aufwandsgrflnden werden bei der Simulation die echten Verarbeitungsaufgaben mehr oder weniger grob approximiert. Nach dem Grad der Vereinfachung unterscheidet man folgende Methoden: 2.2.1. Benchmark-Tests Hier werden die echten Verarbeitungsaufgaben durch eine Anzahl yon Testprogrammen simuliert und die Zeitdifferenz zwischen Beginn und AbschluS der Bearbeitung eines Pakets solcher Testprogramme auf verschiedenen zu bewertenden Rechenanlagen ermittelt. Die Testprogramme werden so gew~hlt, daS sie m6glichst gu~ mit dem zu erwartenden "Lastprofil" ~bereinstimmen. Bei Rechenanlagen, die im Stapelbetrieb arbeiten, l~gt sich dieses Verfahren mit Erfolg anwenden [5, 6, 7~. F~r Proze~rechensysteme, bei denen ja die Informationsverarbeitungsaufgaben yon Signalen aus dem Proze~ und yon der Erf~llung yon Zeitbedingungen abh~ngen, mu~ bei der Simulation des echten Geschehens nicht nur das Verarbeitungsprogramm im Rechner, sondern auch das Verhalten des
590 Prozesses nachgebildet werden. ~---~nlich einem in [81 ffir Realzeitsysteme im Dialogbetrieb vorgeschlagene~Verfahren mit einem Rechner als "Lastgenerator" w~re auch bei ProzeBrechensystemen die Anwendung eines zweiten Rechners zur Simulation des Prozesses denkbar. Eine Anwendung dieses recht aufwendigen Benchmark-Verfahrens
zur Leistungsbewertung ist aller-
dings bisher nicht bekannt geworden. 2.2.2. Kernels Wegen des hohen Aufwandes der Benchmark-Tests werden bei der sog. "Kernel"-Methode zwei wesentliche Vereinfachungen vorgenommen: - Es wird versucht, das "Lastprofil" der echten Informationsverarbeitungsaufgaben
durch kurze Programme
oder Programmstficke (sog. Kernel) zu simulieren [9]. Die Verarbeitungszeit der Kernels l~Bt sich dabei im allgemeinen aus den Befehlsausffihrungszeiten ermitteln. - Anstelle des gesamten Rechensystems wird zumeist mit den Kernels nur die Verarbeitungsf~higkeit
der Zentral-
einheit bewertet. F~r Prozegrechner werden gelegentlich spezielle Kernels angegeben, um z. B. die "Bit-hand!ing-Eigenschaften"
(Kurzprogramme)
zu testen ~ .
Abgesehen yon der Tatsache, dab der Aussagewert der Kernel-Methode wegender
groben Vereinfachungen grunds~tzlich zweifelhaft ist, kommt
bei der Anwendung auf ProzeBrechner noch hinzu, dab - ebenso wie bei den Benchmark-Tests--die Abh~ngigkeit vom ProzeBgeschehen nicht berficksichtigt ist. 2.2.3. Befehls-Mixe Bei diesen Verfahren wird angestrebt, die echten Verarbeitungsprogramme grob durch eine mittlere BefehlsausfO~rungszeit
zu simulieren. Ausgehend
yon einer angenommenen mittleren H~ufigkeit verschiedener Maschinenbefehlstypen wird als Vergleichszahl ffir die Leistungsf~higkeit eine Zeitspanne definiert, die sich als Summe der Ausf~hrungszeiten der mit ihrer relativen H~ufigkeit gewichteten Befehlstypen ergibt. Wegen der einfachen Anwendbarkeit haben die verschiedenen bekannten Mixe
(z. B. Gibson-Mix, GAMM-Mix) eine gro~e Verbreitung gefunden° Der
Wert der damit erzielbaren Aussagen ist jedoch - zumal bei ProzeBrechnern - recht gering.
591 2.3.
Empirische Verfahren
Aus den Erfahrungen beim Einsatz yon Prozegrechensystemen weig man, dab eine Reihe yon Eigenschaften offenbar fNr die Leistungsf~higkeit yon Bedeutung sind. Als "enpirisch" sollen daher diejenigen Verfahren bezeichnet werden, bei denen versucht wird, aus einem Vergleich solcher, aus der Erfahrung heraus als wesentlich erkannter Eigenschaften, zu Aussagen Uber die Leistungsf~higkeit des Prozegrechensystens zu kommen. Dabei ist allerdings die Auswahl der als "wesentlich" era chteton ~igenschaften yon dem zugrunde liegenden Erfahrungshintergrund abh~ngig. 2.3.1. Vergleichslisten yon Eigenschaften Die einfachste empirische Methode zur Kennzeichnung der Leistungsf~higkeit besteht darin, alle als wichtig angesehenen Eigenschaften in Form einer Liste zusanmenzustellen
(siehe z. B. [II, 12]).In der Gesantheit
dieser Aussagen ist dann inplizit ein Mag fur die Leistungsf~higkeit enthalten. Solche Zusamnenstellungen yon Eigenschaften sind fur den qualifizierten Anwender ein gutes Hilfsnittel zun Systenvergleich, falls er in der Lage ist, sie aus seiner Sicht zu beurteilen und auszuwerten. An die Liste werden allerdings teilweise gegens~tzliche Anforderungen gestellt: Einerseits sollten n6glichst alle fur die Leistungsfghigkeit relevanten Eigenschaften enthalten sein, und zwar in quantifizierbarer Form und nicht nur als allgemeine verbale Beschreibung. Andererseits wgchst nit der F~!le der aufgelisteten Merkmale auch die Un~bersichtlichkeit, so dag eine Beschr~nkung auf besonders wichtige Eigenschaften erforderlich ist. Diese Beschr~nkung nu~ allerdings anwendungsunabh~ngig erfolgen, d. h. es d@rfen nur diejenigen Eigenschaften weggelassen werden, die bei allen denkbaren Anwendungsf~llen yon geringer Bedeutung sind. Die dann noch verbleibenden Eigenschaften werden in folgenden als Leistungskriterien bezeichnet. 2.3.2. Lineare VerknUpfung yon Leistungskriterien Un aus der Liste der als Leistungskriterien definierten Eigenschaften zu einer Bewertungskennzahl fur die Leistungsf~higkeit des Proze~rechensystens zu kommen, kann man in Anlehnung an das in der Nutzwertanalyse Ubliche Verfahren El3, 14Jeine Linearkombination der Leistungskriterien bilden. Bezeichnet man die Leistungskriterien mit LI, L2,..., Ln, so ergibt sich bei diesem Ansatz als Ma~ fur die Leistungsf~higkeit
592 die Kennzahl
pals
Summe:
Ein e n t s c h e i d e n d e r V o r t e i l d i e s e r D a r s t e l l u n g b e s t e h t d a r i n , daa m i t den noch f e s t z u l e g e n d e n f r e i e n P a r a m e t e r n g i d i e Anwendungsabh~ngigkeit der Leistungsf~higkeit ber~cksichtigt werden k a n n . Werden d i e ermittelt,
n Leistungskriterien so
fgr m verschiedene
Prozegrechensysteme
erh~It man eine Matrix
rL11
L12 ... Lln~
L21
L22 ..- L2n
i i
,Lml
Lm2 ... Lmn
Mit dem Vektor der Gewichtsfaktoren gi
li I) (iii g2
g
=
n
ergeben sich die Bewertungsgr6gen f~r die Leistungsf~higkeit der Alternativen als Elemente eines Vektors
m
p:
P2
=p
= L .
m
2.3.3 Nichtlineare Verkn~pfung yon Leistungskriterien Da es sich bei den Leistungskriterien um Eigenschaften handelt, yon denen man zwar weir, dab sie in die Leistungsf~higkeit eingehen, ohne aber den EinfluS n~her zu kennen, kann ein Formelansatz einer Leistungsf~higkeitskennzahl
zur Gewinnung
zun~chst willk~rlich festgelegt wer-
den. Neben dem oben erl~uterten linearen Ansatz wurden verschiedentlich nichtlineare Verkn~pfungen vorgeschlagen. In ~15] wird z. B. ein Zusammenhang
593
ao B . ~ C~
der Form p =
T mit
B
MaB fur Befehlsvorrat
Cy Faktoren fNr Komplexit~t,
z. B.
Wortl~nge, maximaler Speicherausbau, indizierte Adressierung etc. T
angesetzt.
mittlere BefehlsausfNhrungszeit
W~hrend dabei nur Eigenschaften der Zentraleinheit betrachtet werden, enth~It eine in[16] angegebene empirische Formel auch frei w~hlbare Parameter, um die Eigenschaften des Betriebssystems wenigstens global zu ber~cksichtigen. 3.
Ziele und erste Ergebnisse des Arbeitskreises "ProzeBrechensysteme-Leistungskriterien"
der GMR
3.1. Vorgehensweise Im Jahre 1972 wurde der "ad-hoc-Arbeitskreis
Proze~rechensysteme-Lei-
stungskriterien" der GMR gebildet, um Fragen der Leistungsbewertung und des Vergleichs yon ProzeBrechensystemen
zu behandeln. Aus der Er-
kenntnis heraus, dab jede Bewertung der Leistungsf~higkeit eines ProzeBrechensystems aus den oben erl~uterten GrUnden vom speziellen Automatisierungssystem des Anwenders abh~ngt, entschied sich der Arbeitskreis fur das unter 2.3.2. beschriebene empirische Verfahren mit linearer VerknUpfung der Leistungskriterien, anwendungsunabh~ngige
da bei diesem Verfahren eine
Definition yon Leistungskriterien und eine an-
schlieBende BerUcksichtigung der Anwendungsabh~ngigkeit
durch Gewichts-
faktoren mSglich erschien. Entsprechend dieser Festlegung wurde das in Bild 2 dargestellte Vorgehen vereinbart: - Zusammenstellung einer Liste von Eigenschaften,
die fur
die Leistungsf~higkeit eines gesamten ProzeBrechensystems als bedeutsam angesehen werden. - Festlegung anwendungsunabh~ngiger
Gewichtsfaktoren zu der
Liste der Eigenschaften. - Streichung aller weniger wichtigen Eigenschaften an Hand der anwendungsunabh~ngigen
Gewichtsfaktoren zur Gewinnung
einer Uberschaubaren Liste yon echten Leistungskriterien.
594
Arbeitskreis ,, ProzeBrechensysteme- Leistungskriterien"
ProzeSrechner Anwender
I I Anwendungs- [ unabhiingige Gewichtsfoktoren
I I I
L iste von Eigenschaften
I I I .......
r
Standardis ier te 1 Liste von Leistungskriterien
~. . . . .
1
I Anwendungsab- I I h~ngige Gewichts- t I~ faktoren gi j "7 / / /
/
\
/ /
r
I I [
Vektor der Leistungsfahigke~t p= L.g
I I J
Ergebnis der Bewert ung
Arbeiten durch den Arbeitskreis ,. Prozel~systemeLeistungskriterien " Verwendung der Leistungskriterien durch Anwender zur Leistungsbewertung Bild 2: Vorgehensweise zur Rrstellung einer anwendungsunabh~ngigen Liste yon Leistungskriterien und Anwendung dieser Kriterien zur anwendungsabh~ngigen Bewertung der Leistungsf~higkeit.
In Bild 2 ist gestrichelt mit eingezeichnet, wie diese Liste der Leistungskriterien dann yon einem Anwender zur Bewertung yon ProzeBrechensystemen eingesetzt werden kann: Er bestimmt die yon seinem speziellen Anwendungsfall abh~ngigen Gewichtsfaktoren gi und berechnet damit nach dem in Abschnitt 2.3.2. angegebenen Verfahren die Leistungsf~higkeitskennzahlen fur die zu untersuchenden alternativen ProzeBrechensysteme. Eine wesentliche Schwierigkeit bleibt allerdings ungel~st: Die Frage der richtigen Festlegung der Gewichtsfaktoren. Au£ dieses Problem soll
595
in Abschnitt 3.2,
4 noch e i n g e g a n g e n w e r d e n .
F r a g e b o g e n fiber w i c h t i g e
Eigenschaften
yon P r o z e ~ r e c h e n s y s t e m e n
Bei der Erstellung der Liste yon Eigenschaften als Grundlage ffir die noch zu erstellende Liste yon Leistungskriterien
(sie liegt als erstes
Ergebnis des Arbeitskreises vor) waren zahlreiche Schwierigkeiten zu fiberwinden: -
Zur Ermittlung der Eigenschaften in quantitativer Form sind nur Fragen zul~ssig, die mit ja/nein oder durch eine Zahl beantwortet werden kOnnen. Die Formulierung der Fragen in dieser Form war, insbesondere bei der Ermittlung yon Eigenschaften des Betriebssystems,
-
eine nicht leicht zu 18sende Aufgabe.
Eine Eigenschaft kann nur dann eindeutig abgefragt werden, wenn der Beantworter einer diesbezfiglichen Frage die verwendeten Benennungen versteht.
Die Begriffe und Benennungen sind jedoch bis-
her, vor allem auf dem Gebiet der Software, noch weitgehend firmenspezifisch. Diese Schwierigkeit konnte nut so gelSst werden, dag ffir die bisher nicht in Normen festgelegten Begriffe neue Benennungen definiert wurden - die Vorschl~ge wurden inzwischen den zust~ndigen Normungsgremien zur Weiterbearbeitung
fiberge-
ben - und dag die Liste dieser Begriffe dem Fragebogen als Anhang beigeffigt wird. Bei der Festlegung und Kl~rung der Begriffe und Benennungen erwies es sich als unsch~tzbarer Vorteil, dag die drei wichtigsten deutschen Herstellerfirmen yon Prozegrechensystemen sowie Anwender aus verschiedenen Branchen im Arbeitskreis vertreten sind. In langen und eingehenden Diskussionen gelang es, trotz der zun~chst babylonisch anmutenden Sprachverwirrung, schlieglich doch zu klaren und yon allen Mitgliedern des Arbeitskreises akzeptierbaren Benennungen zu kommen. - Viele Eigenschaften des Betriebssystems sind nur im Zusammenhang mit einer - vom Anwendungsfall abh~ngigen - Konfiguration des Ger~tesystems angebbar. Um diese Eigenschaften mit dem anwendungsunabhgngigen
Fragenkatalog erfassen zu k0nnen, wur-
den sog. "Ger~temixe", d. h. genau spezifizierte, beispielhafte Ger~tekonfiguratienen eingeffihrt, und zwar je eine Konfiguratien eines kleinen Prozegrechensystems
ohne Externspeicher
(Mix I)
und eine Konfiguration eines mittelgro~en Systems mit Externspeichern (Mix 2). Die folgende Tabelle zeigt als Beispiel den vorgeschlagenen Mix I.
596 Tabelle I: Ger~temix 1 f~r ein "kleines"Prozegrechensystem
ohne
Externspeicher
I. 2.
GrS~e des Zentralspeichers Papierverarbeitende Ger~te
2.1. Fernschreiber/Schreibmaschine 2.2. Lochstreifenleser 2.3. Lochstreifenstanzer 3. Prozegein /ausgaben 3.1. Analoge Eingabesignale 3.2. Digitale Eingabesignale 3.3. Selbstmeldende digitale Eingabesignale 3.4. Digitale Ausgabesignale 4.
Zeitgeber
Anzahl
Anforderungen
16 KW
1/l~sec
1 1 1 64
i0 Z/sec ~120 Z/sec 30 Z/sec g 20 msec/W 12 bit
240 48 64 1
g IO msec/W ~ 20 msec
3.3. Beispiele f~r den Aufbau des Fragebogens zur Ermittlung der Liste yon leistungsrelevanten Eigenschaften Ein wesentliches Anliegen des Arbeitskreises war es, alle f~r die Leistungsf~higkeit bedeutsamen Merkmale zusammenzustellen und nicht nur einzelne Teile des gesamten Prozegrechensystems zu beschreiben. Insbesondere sollte der - in den meisten bisher bekannten Eigenschaftenlisten nur ungen~gend beachteten - Tatsache Rechnung getragen werden, dag die Eigenschaften des Softwaresystems f~r die Leistungsf~higkeit eines ProzeSrechensystems
ebenso wichtig sein k~nnen wie die Hardware-
Gesichtspunkte. Dieser Zielsetzung entsprechend werden Eigenschaften ~ber folgende Teilsysteme abgefragt (siehe das in der Anlage beigefGgte ausfGhrliche Inhaltsverzeichnis): - Zentraleinheit Proze~einheit (Prozegperipheriesystem) - sonstige periphere Einheiten Daten~bertragung Betriebssystem (Systemsoftware) Anwenderprogrammsysteme -
Dar~ber hinaus werden Fragen Gber die f~r die Effektivit~t eines Proze~automatisierungssystems
bedeutsamen Gesichtspunkte
Preise und Lie£erzeiten
597 Betreuung und Wartung
-
- Schulung und Dokumentation Garantie und Einsatzbedingungen
-
gestellt. Dabei k~nnen die (auf die Ger~temixe 1 und 2 bezogenen) Angaben fber Preise und Lieferzeiten natfrlich nicht ein Angebot fber ein Proze~rechensystem fur einen konkreten Anwendungsfall ersetzen, Vielmehr sollte es an Hand dieser Angaben dem Anwender erm~glicht werden, die Leistungsf~higkeit auch bezfglich der daffr aufzubringenden Kosten (z. B. in Form eines Leistungs/Preisverh~itnisses)
zu betrachten.
Um
den Aufbau des Fragebogens beispielhaft zu erl~utern, sind in den folgenden Tabellen einzelne Unterabschnitte des vorl~ufigen Eigenschaftenkatalogs wiedergegeben.
4.
Zusammenfassung und Ausblick
Als erster Schritt auf dem Wege zu einer Liste yon Fragen fber anwendungsunabh~ngige Leistungskriterien wurde eine vorl~ufige Liste yon Fragen fber leistungsrelevante Eigenschaften erstellt.
Sie wird nun in den
zust~ndigen Ausschfssen der GMR zur Diskussion gestellt. Dabei soll versucht werden, neben Verbesserungen und Erg~nzungen bez~glich der abzufragenden Eigenschaften zu einer anwendungsunabh~ngigen Gewichtung zu kommen. Das Ziel ist die Reduzierung der Anzahl des bisher aufgelisteten Eigenschaften und die Festlegung einer Liste yon Leistungskriterien, die - unabh~ngig yon der betrachteten Anwendung - so bedeutsam fur die Leistungsf~higkeit sind, daS sie nicht vernachl~ssigt werden k6nnen. Falls dieses Ziel erreichbar ist, w~re eine Standardisierung dieser Leistungskriterien denkbar. Obwohl eine solche Liste yon Leistungskriterien sowohl ffir den Anwender als auch fur den Entwickler yon ProzeSrechensystemen yon groBem Nutzen sein dfrfte, ist doch die Ermittlung einer Leistungsf~higkeitskennzahl p nach dem oben unter 2.3.2. angegebenen Verfahren schwierig, da die Gewichtsfaktoren gi "willkfrlich", d. h. auf Grund einer nicht n~her meSbaren Erfahrung des jeweiligen Anwenders,
festzulegen sind.
FUr denjenigen Anwender, der fiber diese Erfahrung nieht verffgt, w~re es sicher eine gro~e Hilfe, wenn er Anhaltswerte fber die ungef~hre GreBe der fur seinen Anwendungsfall
zu w~hlenden Gewichtsfaktoren er-
598 Tabelle 2: Fragen @ber Eigenschaften des Unterbrechungswerks (Abschnitt 2.2) AbschnittsNr. 2.2.2 .I
2.2.2.2 2.2.2.3
2.2.2.4 2.2.2.5
Frage nach Eigenschaften
Wieviel Priorit~tsebenen des Interruptwerkes gibt es im
2.2.2.7
2.2.2.8
2.2.2.9
2.2.2.10
1
]
Grundausbau Maximalausbau - Erweiterbar in Stufen yon X Ebenen
I
"
Anzahl der Interrupteing~nge pro Priorit~tsebene Die Bearbeitung der Interruptsignale erfolgt nach der - zeitlichen Reihenfolge des Eintreffens - Priorit~t Wieviel Interrupteing~nge werden ffir MIX1/ MIX2 ben6tigt Erfolgt die Identifizierung eines Interruptsignals - Hardware-m~gig(Jedem Eingang ist ein Antwortprogramm zugeordnet) - Software-m~ig mit Ereigniskennung (Eine durch einen Sammelinterrupt gestartete Routine liest die hardware-m~gig erzeugte Ereigniskennung)
~
J
-
2.2.2.6
Antwort (Zahlenwert bzw. ankreuzen)
Software-m~gig ohne Ereigniskennung
(Eine durch einen Sammelinterrupt gestartete Routine fragt alle Interrupteing~nge sequentiell ab) Ist eine Unterbrechung nach jcdem Befehl m6glich Haben die Interrupteing~nge eine Augenmaske (Sperren gegen eine Registrierung des Signals) Innenmaske (Sperren gegen eine Auswertung des Signals) Welches ist die kleinste Anzahl yon Interrupteing~ngen die separat gesperrt werden kann bei einer - Au~enmaske Innenmaske Wird ~berwacht, ob in einer bestimmten Zeit ein Interruptsignal bearbeitet wird - Einstellbarer Zeitbereich in ps Wie grog ist die Interruptreaktionszeit bis zum Start eines Reaktionsprogramms in ps
I I
!
ja
I nein]
I ja
[ neinl
l Ja
l nein~
I ~a
I nein]
[
Jd
lnein]
I ja
I nein]
I I ja [ [
I I nein] i ..1...
599 Tabelle 3: Fragen zur E/A-Organisation des Betriebssystems (Abschnitt 6.3) AbschnittsNr.
Frage nach Eigenschaften
Antwort (Zahlenwert bzw.
ankreuzen) 6.3.1
Wie verkehren Anwenderprogramme mit EA-Ger~ten? - durch Aufruf an das Betriebssystem - durch Routine im Anwenderprogramm
Ija I nein I IJa I nein I
6.3.2
MuS immer auf das Ende einer EA-Operation an der Aufrufstelle gewartet werden?
]ja I neinj
6.3.3
Wo werden EA-Daten abgelegt? im Anwenderprogramm in einem generellen Zwischenpuffer im HSP in einem generellen Zwischenpuffer auf dem PSP -
-
-
6.3.4
Wie werden mehrere Anforderungen an ein EA-Ger~t koordiniert? - durch Warteschlangen nach Priorit~t - durch Warteschlangen nach zeitlicher Reihenfolge durch Rfickweisung der weiteren Anforderungen durch das Betriebssystem durch Prfifung des Belegungszustandes desGer~tes durch das Anwenderprogramm -
-
ja ~a
nein nein nein
3a
tJ a I nei
j
IJa ! neinJ IJa I nein~ Ija
I neinJ I nein]
6.3.5
Kann ein Ger~t vorabergehend ffir ein Programm reserviert werden?
Ija
6.3.6
Kann die Reservierung eines Gergtes in Ausnahmef~llen unterbrochen werden?
Ija I
nein
6.3.7
Erfolgt die Umcodierung der Daten ffir die im Mix 2 aufgeffihrten EA-Ger~te zwischen Interncode und Ger~tecode - durch Hardware - durch das Betriebssystem durch das Anwenderprogramm
a a~ 3a
nein ~ nein neon
K6nnen Protokolle formatgerecht ausgegeben werden? - Aufbereitung durch das Betriebssystem mit Hilfe yon Formatangaben des Anwenders - Aufbereitung durch den Anwender
lja I'neln i Ija I nein ]
-
6.3.8
6.3.9
Sind die Aufrufe an das Betriebssystem und die zu fibergebenden Datenfelder in Format und Aufbau ger~teunabh~ngig (EA-Ger~te)? - Aufrufe Datenfelder
ja ja .,i
|
nein
-
6.3.10
Wird bei auftretenden Fehlern versucht, die EAOperation zu wiederholen?
lja
'i nein ]
6.3.1t
Kann bei Ger~teausfall automatisch auf ein Ersatzger~t umgeschaltet werden?
~a
I nein
6.3.12
Werden MiSerfolge yon EA-Operationen gemeldet? - dem Operator dem aufrufenden Programm
Jja
-
ja
I nein nein ,]
600 halten k~nnte. S o l c h e A n h a l t s w e r t e k 0 n n t e n ffir v e r s c h i e d e n a r t i g e
Proze~typen m~gli-
c h e r w e i s e yon P r o z e ~ r e c h n e r - A n w e n d e r n e r a r b e i t e t
w e r d e n , Auch e i n e e x -
perimentelle
Ermittlung
wie s i e
am I n s t i t u t
scheint
durchfGhrbar.
mit Hilfe verschiedenartiger
des V e r f a s s e r s
Modellprozesse,
gegenw~rtig aufgebaut werden, er-
LITERATUR
i
2 3
4
5 6
7
8
9 IO ii
12 13
14 IS
16
KUmmerle, K.: Charakteristische Gr0~en zur Beschreibung der Leistungsf~higkeit und Effektivit~t yon EDV-Anlagen. Elektronische Rechenanlagen 14 (1972) H.I S. 12-18 Hellerman, L.: A measure of computational work. IEEE Trans. on Computers C-21, (1972) pp. 439-446 Hellerman, L.: The power and efficiency of a computer system. Lecture notes in Computer Science ~ pp. 190-2OS, Springer-Verlag Berlin-Heidelberg-New York 1974 Herzog, V., KGhn, P. und Zeh, A.: Klassifizierung und Analyse yon Verkehrsmodellen fur das Ablaufgeschehen in Rechnersystemen. Nachrichtentechn. Fachberichte Bd. 44 (1972) S. 181-198 Arbuckle, C.A.: Computer Analysis and Thruput Evaluation. Computers and Automation (Jan. 1966) pp. 12-19 Schreiber, H.,Thomas, B. und Wolf F.: Beschreibung eines synthetischen Jobmix ffir verschiedene Benchmark-Tests. Lecture Notes in Computer Science ~ (1974) pp. 218-232, Springer-Verlag Berlin-Heidelberg-New York Mell, W. und Sandner, P.: DurchfUhrung und Auswertung yon CPU-orientierten Benchmark-Tests. Lecture Notes in Computer Science ~ (1974) pp. 233-244. Springer-Verlag Berlin-Heidelberg-New York Ege, A.: Leistungsmessung bei Realzeitsystemen. Lecture Notes in Computer Science ~ (1974) pp. 206-217. Springer-Verlag Berlin-Heidelberg-New York Walters, R.E.: The standardized Kernel evaluation technique. Telecommunications Headquarters. Research Department, Ipswich, England Federal Aviation Agency: Document FAA-ER-606-063 Appendix A Informationsdienst Proze~rechensysteme COMTEST. PSI Gesellschaft fur Proze~steuerungs- und Informationssysteme mbH, Berlin und Aschaffenburg Heller, G. und Popovic, D.: Datenverarbeitungsger~te fur die Automatisierungstechnik'Chemie-Ingenieur-Technik 44 (1972) S. 476-485 Zangenmeister, C.:Nutzwertanalyse in der Systemtechnik - eine Methodik zur multidimensionalen Bewertung und Auswahl yon Projektalternativen. MOnchen 1970 Baugut, G.: Modelle zur Auwahl von Datenverarbeitungsanlagen. Verlagsges. R. Mfiller, K~In-Braunsfeld 1973 Marenbach, K.: Methode f~r den Preis/Leistungsvergleich yon Proze~rechnern. AEG-Telefunken, Interne Techn. Notiz Nr. A 23/VSTF 9/68(M~rz 1968) Butler, J.L.: Comparative Criteria for Minicomputers Instrumentation Technology (1970)
601 ANHANG Ad-hoc-Ausschu~ "Proze~rechensysteme-Leistungskriterien" Ges. £@r Me~- und Regelungstechnik
der VDI/VDE
.Fragebo~en . . . . . . . . . .zur . . .Kennzeichnung ....... der. Leistungsf~higkeit yon ProzeBrechensysltemen durch elne L1ste yon E1genschaften Inhaltsverzeichnis I. Binf~hrung I.~ Leistungsbewertung yon Proze~rechensystemen 1.2 Ziele des vorliegenden Fragebogens 2. Zentraleinheit 2.1 Hauptspeicher 2.2 Prozessor 2.2.1 Prozessor allgemein 2.2.2 Unterbrechungssystem 2.3 EA-Werk 3. Proze~einheit 3.1Analogeingabeeinheit 3.2 Analogausgabeeinheit 3.3 Digitaleingabeeinheit 3.4 Digitalausgabeeinheit 3.5 Impulseingabeeinheit 3.6 Impulsausgabeeinheit 3.7 Sonstiges 4. Sonstige periphere ~inheiten 4.1Periphere Speicher 4.2 Standardperipherie 4.3 Proze~bedienperipherie 4.4 Zeitgeber 5. Daten~bertragung 5.1Allgemeine Fragen zur Daten~bertragung 5.2 Rechnerkopplung 5.3 Peripheriekopplung 6. Betriebssystem (Systemsoftware) 6.1Allgemeine Fragen 6.20rganisation des Betriebsablaufs 6.3 BA-Organisation 6.4 Kommunikation Mensch-Rechner 6.5 Datei- und Speicherplatzverwaltung 6.6 Sicherungsfunktionen 6.7 Behandlung yon Ausnahmezust~nden 6.8 Allgemeine Fragen zur Vorbereitung des Betriebsablaufs 6.9 Spezielle Fragen zu den Programmiersprachen 6.10 Spezielle Fragen zur Unterst~tzung des Betriebsablaufs 6.11 Fragen zu den Testm~glichkeiten 6.12 Generierung des Betriebssystems 6.13 Unterst@tzung des Betriebsablaufs 7. Anwenderprogramm-Systeme 8. Sonstige Gesichtspunkte f@r den Proze~rechnereinsatz 8.1 Preise/Lieferzeiten 8.2 Betreuung und Wartung 8.3 Schulung/Dokumentation 8.4 Garantie und Einsatzbedingungen Anhang: AI Ger~temix I A2 Ger~temix 2 A3 Erl~uterung von Begriffen und Benennungen
DAS PROZESS-LEIT-SYSTEM IN DER FORSCHUNG UND ENTWICKLUNG DER ¥OLKSWAGENWERK AG STRUKTUR DES BETRIEBSSYSTEMS
H.K. Reiter, Volkswagenwerk AG, Forschuag und Eatwicklung, Wolfsburg
ZUSAMME~ASSUNG: Es werdea die wesentlichen Eigenschaften des Prozess-Leit-Systems (PLS)~ das yon der Control Data GmbH (CD) in Zusammenarbeit mit Ingenieuren der Vol~swageawerk AG fir das Versuchszentrum in der Forschuag und Entwickluag in Wolfsburg entwickelt uad installiert wurde, aufgezeigt. Das PLS wurde Eade 1972 in Betrieb geaommea und ist seitdem eiae wichtige Hilfe bei der Entwickluagsarbeit. Mit dem PLS kUnnea parallel in dem Hauptsystem im Zeitscheibea-Verfahrea bis zu 62 PLS-Programme und mehrere Hintergruad-Programme und in einem dezeatralen Untersystem bis zu 16 PLS-Programme f~r den 24-Stunden-Dauerversuch bedient werden. Von dem PLS werden alle Funktionen der Prifstands-Steueruag/-Uberwachung und der Messdatenerfassung Gbernommen; weiterhin fdhrt es die Versuchsauswertung und die Ausgabe von abgeleiteten Versuc~sergebnissen in Tabellen- und Diagrammform fir Berichte dutch.
GLIEDERUNG:
1. EINLEITUNG 2. BESCHREIBUNG DES PLS 2.1. Aufgaben des PLS 2.2. PLS - Hardware 2.2.1. CD 6500 - Koafiguration 2.2.2. CD 1700 - Konfiguration 3. STRUKTUR DES PLS - BETRIEBSSYSTEMS 3.1. CD 6500 System - Module 3.1.1. Real - Time - Monitor 3.1°2o Kapazit~ts - Verwalter 3.1.3° Prozessdaten - Ein-/Ausgabe 3.1.4. Mensch - Maschine - Kommunikation 3.1.5. Dienstprogramme 3.2. CD 1700 System - Module 3.2.1. Langzeit Prozessdaten Eia-/Ausgabe 3.2.2. LITERATUR
Kurzzeit Prozessdaten Eiagabe
603 l. EINLEITUNG
In ZussLmmenarbeit mit der Firma Control Data GmbH (CD) wurde yon der Volkswagenwerk AG fur das Forschungs-und Entwickluagszentrum zum Zwecke der EntwicklungszeitverkNrzuag und Qualit~tssteigerung ein Prozess-Leit-System (PLS) entwickelt und iastalliert (vgl. Bild 1). Hit diesem Multi-Prozessor-Verbuadsystem werdea f~r bis zu 78 Pr~fst~nde Daten automatisch und kontinuierlich aufgezeichmet, ausgewertet uad Versuchsabl~ufe gesteuert.
Typische an das PLS angeschlossene PrNfstandsgruppea sind: Motor-, Rollen-, Getriebe-, Hydropuls- und Abgas-Pr~fst~ade. Eine Aazahl yon Soader-Pr~fst~adea, wie Gebl~se-, Scheibenwischermotor-~ Akustik-Pr~fst~nde etc., erg~nzen das Versuchsspe~trum der mit dem PLS vollautomatisch betriebeaea Pr~fst~ade.
Die PLS-Programme werden fur das zeatrale System CD 6500 (vgl. Bild l) in FORTRAN IV geschriebeno Alle fur die Prozessa~we~dung erforderlichen Fua~tioaea wurdea durch die Schaffung einer umfaagreichen Unterprogramm-Bibliothek ber~cksichtigt.
Das dezeatrale Untersystem CD 1700 D (vgl. Bild l) fur den 24-Stunden-Dauerver-
CD
6500
HAUPTRECHNER
,
r
CD 1700
]'
, co1 t
CD 1700
JNTERBSYSTEM~ _
co170o E
L CD,15OO
CD 1500
t
I cDl,,
t
t
Rangier -
Pt~nd
co170o
c--~;-~
Verteiler
PrSfstand (Funktions - Versuche) 1:
PLS
Konfiguration
UNTERSYSTEI DD ~
F
cD 1 ~
!
1
Bild
17oo
UNTERSYSTEIuI~rERSYSTE~ /
,,I 62
col~oo
f I I~-v~r I t 16 Priifst~nde (Dauer Versuche )
604
such wird auf der Basis yon AUTRAN fur die Versuchsanwendung wird auf dieses Untersystem aicht n~her eingegangen, auf dem "Second Testing"
International
Symposium
on Automation
programmiert.
Hier
da in London am 26.9.1973 of Engine and Emission
Ill ~ber dieses System berichtet wurde.
An Versuchen,
die inzwischen auf die automatische
gestellt wurden,
seiea beispielhaft -
Durchf~hrung mit dem PLS um-
genannt:
Strassenteillastkeanlinien;
- Motoreneinlaufprogramme; - Vollastkennlinien; -
Abgaskoazentratioas-Kennfelder;
-
K~hlgebl~se-Ken~felder;
-
Motorea-Dauerversuch-Programme;
- Scheibenwischermotor-Kennlinien; -
Kennfelder
fGr automatische
Getriebe.
2. BESCHREIBUNG DES PLS
An dieser Stelle sollen nur die wesentlichen Aufgaben und die wichtigen Hardware-Komponenten
des PLS aus der Systemsicht
Beitrag zu dem "International
werden,
da in einem
Computing Symposium 1973" in Davos
[2] in aus-
fGhrlicher Form sine Beschreibung
beschrieben
des PLS gegeben wurde.
2.1. Aufgaben des PLS
Das Prozess-Leit-System
der Volkswagenwerk AG ist sin System zur Erfassung von
Messdaten und ihrer Auswertung.
Parallel dazu kaan es Sollwerte
schlosseaen
Pr~fst~nde direkt vorgeben und somit Versuchsabliufe
~berwachen.
Mit dem Einsatz eines CD 6500 Grossrechners
verarbeitung
der Prozessdaten
dem Untersystem CD 1700 D durchgef~hrt
Infolge der Vislzahl angeschlossener
automatisch
bis zu 16 Versuche mit
werden.
und automatisch betriebener
Pr~fst~nde
auff~hren:
o Schnellere Versuchsdurchf~hrung o Versuchsergebnisse
ist das PLS-Kaupt-
auf bis zu 62 Pr~fst~nden Versuche
zu fahren. Fernerhin k~nnen in der Motorendauerpr~fhalle
lassen sich folgende Vorteile
steuera und
und durch die Echtzeit-
in den CD 1700 Prozessrechaera
system in der Lags gleichzeitig
an die ange-
auch schwieriger
Parametervariationen;
(auch komplexer Art) liegen in kurzer Zeit nach dem Ver-
suchsende aussagekr~ftig
in Diagrammform
vor;
605
Eingabe vom Prifstand
....... i
IMDC STREAM
CEM
ANALOG DIGITAL EREIGNISZKHLER
I I
ANALOG DIGITAL INTERRUPT EREIGNISZ~LER
BURST
SHOT
DIGITAL
I
ANALOG DIGITAL
I Ausgabe zum I Pr~fstand
I A/Q CER, FAILURE ACTION ANALOG DIGITAL
1
ANALOG DIGITAL
....... ~A/Q
1'1 0I~-
SH OT
ANALOG DIGITAL
Bild 2: Pr~fstands - Signale
o Versuchsobjekte
(teure Prototypen) werden vor unbeabsichtigter ZerstSruag
besser gesch~tzt; o Versuche siad innerhalb der bekannten Fehlergrenzen jederzeit,
exakt gleich,
wiederholbar.
2.2. PLS - Hardware Das PLS-~ulti~Prozessor-System besteht aus eiaer CD 6500 Eiaheit als Hautprechher und sechs direkt gekoppelten CD 1700 Prozessrechaern, die ±m Echtzeit-Betrieb Messdatea voa den Pr~fst~ndea erfassen und zum Tell bereits verarbeiten bzw. Prozessdatea an die Pr~fst~ade vorgeben (vgl. Bild 1). Die Pr~fst~nde sind mit den CD 1700 Rechnern incl. der analogen und digitalea CD 1500 Prozessperi-
606
pherie (vgl. Bild 2) und dem Rangierverteiler verbuadeno Der Zentralrechaer und f~nf ~ntersysteme sind in dem Hauptrechnerraum und das Uatersystem f~r den 24Stunden-Motor-Dauerversuch in einem ca. 1 Km entfernten dezentralen Rechnerraum iastalliert.
2.2.1. CD 6500 - Konf~g~ratioa
Der CD 6500 Hauptrechner (vgl. Bild l) ist ein Doppel-Prozessor-System (CENTRAL _PROCESSOR ~NIT=CPU) uad ±st ausgestattet mit: o 98 K Arbeitsspeicher (~ENTRAL_MEMORY=CM), Wortl~nge 60 Bit; o 250 K Externer Kernspeicher (EXTENDED ~ORE ~TORAGE=ECS), Wortl~nge 60 Bit; o lO peripheren Prozessoren (~ERIPHERAL ~ROCESSOR ~NIT=PPU) mit je 4 K Kernspeicher, Wortl~nge 12 Bit; o Platteneinheit fur 250 Mio Zeichen & 6 Bit; e Konsole (Doppelbildschirm); o 1 Kartenleser; o 1 Kartenstanzer; o 4 Magnetbandeinheiten; e 2 Schnelldrucker; o 1 On-Line Trommel-Plotter (Off-Line ist ein ~.~k_rofilm-Plotter verf~gbar); o 6 Bildschirmeiheiten, davon 2 mit Eardcopy-Einrichtung.
Eine spezielle Steuereinheit verbindet den CD 6500 Hauptrechner direkt mit den 62 Fernschreibern (TTY) in den Pr~fstandskabinen (vgl. Bild 1).
2.2.2. CD 1700 - Konf~g~ration
Jeder der CD 1700 Prozessrechner A, B, C, E und F (vgl. Bild l) ist ausgestattet mit: o 32 K Arbeitsspeicher, Wortl~nge 18 Bit; o 1 Konsolschreibmaschiae; o 1 Lochstreifenleser; o 1 Lochstreifenstanzer.
Die CD 1700 Rechner sind zus~tzlich zu ihren verschiedenen analogea und digitalea Staadard-Prozess-Signalwandlungs-Ger~te n CD 1500 mit eiaem schaellea fur das PLS entwickeltem Multiplexer (~ULTIPLEXED ~ATA ~HANNEL=MDC) ausger~stet, um mit den im PLS-Job festgelegten Frequeazen zeitgenau Messwerte und Statusworte abtasten und zwischenspeichern bzw. Sollwerte uad Funktionsworte an die Pr~fst~nde
607 --i SYSTEM CD 6500 RESOURCE ALLOCATOR
I
~
~o~~o~ F
....
I-
\
-I
ICOMMUNICATION .I
1
l
SYSTEM A,B,C
SYSTEM
SYSTEM E~F
..'.,..I
!
O~-SaOT
B~RST I MDC
Rangierve r teiler~.
I Pr~fstand 1 his 62
Pr~fstand I ° O"" 1 bi~ 16 "'O
Pr~fstands - Fernschreiber SYSTEME CD 1700
Bild 3: Ubersicht der PLS - System - Module
vorgeben zu kSanen. Die Ein-/Ausgabe zeitlich nicht garantierter einzelner Prozesswerte erfolgt dutch den sogenannten A/Q - Kanal, d.h. dutch CD 1700-Register im Gegensatz zu dem ~IRECT MEMORY ~CCESS (=DMA) bei der Arbeitsweise des MDC.
608 3. STRUKTUR DES PLS - BETRIEBSSYSTEMS
Das VW-spezifische
PLS-Spezialbetriebssystem
basiert auf SCOPE 3-3 fur die
CD 6500 und HSM f~r die CD 1700 Untersysteme; ziert und erweitert,
die Basissysteme
um die Aufgaben des PLS (vgl. Abscha.
wurden modifi-
2.1.) erf~llen zu
k~nnen.
Das PLS-Betriebssystem
l~sst sich in vier Module unterscheiden
fur:
- den Hauptrechner CD 6500; die CD 1700 Unters~steme
A, B uad C (Langzeit Prozessdaten Ein-/Ausgabe);
-
die CD 1700 Untersysteme
E und F (Kurzzeit Prozessdaten Eingabe);
-
das CD 1700 Untersystem D (Motor-Dauer-Versuche
-
im 24-Stundea-Betrieb).
3.1. CD 650o System - Module
3.1.1. Real - Time - Moaitor
Innerhalb eines Systemzyklus bis zu 62 PLS-Programme
und zwei Batch-Programme
Programm wird eatsprechend disch in jedem,
EXECUTIVE
werdea.
jedem zweiten,
vierten oder achten Systemzyklus
wird zeitkritischer
der daf~r verantwortliche
(~IME~HRITICAL=TC)
Betriebssystem-Modul
Jedes PLS-
(im ms) periobedieat. Diese Ausf~hrungs-
ist der zeatrale
(=EXEC ~) (vgl. Bild 3)-
E~EC ~berwacht peripheren
a~tiviert
yon 250 ms k~naea
seiner definierten Ausf~hrungszeit
garantierte Bedienperiode modus genannt;
(genaaat ~YSTEM ~RAME ~ I ~ = S F T )
alle Aktivit~tea
Prozessorea
der beiden Zentralrechaer ~ (CPU's) uad der lO
(PPU's) des PLS uad l~sst sich in drei Untermodule
glie-
dern (vgl. Bild 4): o MONITOR
(=MTR), einem PPU-Programmsystem,
t~tea kontrolllert
uad koordiniert;
o zentraler zeitkritischer f~hrbaren CPU-Programm, PLS-Programme
Monitor,
eiaem nicht uaterbrechbarea,
das alle zeitkritischen
±~ dea beiden Zentralrechnern
o zentraler nichtzeitkritischer brechbarem
das ~bergeordnet~ alle System-Aktivi-
aller nichtzeitkritischer
tea Uhrzeit;
Monitor,
fur die Bearbeitung
Systemaaforderungea
Eiaige der von EXEC auszuf~hrendea Fua~tionea o Lesen der System,Uhr
Systemanforderderuagen
bedient und kontrolliert
(NON T I M E ~ R I T I C A L = N T C )
Programm aotweadigen Funktionen
parallel ausder uad
eiaem unterund Kontrolle
in e±nem Systemzy~lus.
siad:
uad die Verwaltuag der im zeatralen Keraspeicher
gef~hr-
609 Bild 4: Systemzyklus im Hauptrechner CD 6500 Aktivit~t Zentraler Prozessor
_ -
cPu A
DD (PLS-Eingabe)
TC
DC (PLS-Ausgabe7
CPU B
B
~TC
PPU 0
_ i NTC/B ~
~i ~ t $
TC
-- ~ -
, _ NTC/B !
TC
~---~
_ ,~ --'" ~I L
NTC
Aktivit~t Peripherer Monitor Prozessor DD : DATA DISTRIBUTIO~ DC : DATA COLLECTION TC: TIME CRITICAL NTC : NON TIME CRITICAL B : BATCH CPU : CENTRAL PROCESSOR UNIT A, B pPuA'B: PERIPHERAL PROECESSOR UNIT (MONITOR)
Aktivit~t I
co 65o0 cp~
/3c_l
NTC/B
I
~_2c
DO
"--
_ I |..
w
l-
CD 6500 PPU W Transferzyklu
Prozessdaten- 1 transfer I zur CD 6500 v !
~i Prozessdaten~ ~ _ transfer I-- zur CD 1700~ I !
~@" I
i
i
CO 1700 A , B , C | ~ _II MDC ---Listenzykius ~ t 0 Prozessdaten - Ein-/Ausgabe in den Untersystemen,11A,B,C--] '~-
il
I
i
tl t2
t3
t4
rt0+250 ma
to: Ende der zyklischen E/A-Listen-Bearbeitung; Start des Prozessdatentransfer zur CD 6500 tl: Ende des Prozessdatentransfer zur CD 6500 t2: Start DD und DC t~: Ende DC; Start des Prozessdatentransfer zur CD 1700 t~: Ende des ~Tozessdatentransfer zur CD 1700 Bild 5: Zeit - Beziehuagen bei der Prozessdaten - Ein-/Ausgabe
610 o Weitergabe yon Auftr~gen (z.B. Ein-/Ausgabe der Zentralrechner) zur delegierten Ausf~hruag in den peripheren Prozessoren (PPU's) und Uberwachuag der Bearbeitung; o Kontrolle aller Systemaktivit~ten auf ordnungsgem~sse DurchfGhrung; iasbesoadere wird jede zeitkritische PI.S-Programmaktivit~t daraufhin ~berprGft, dass der zeitsynchrone Ablauf anderer PLS-Programme aicht gestSrt wird~ o Lesea der zu aktivierenden PLS-Programme am Beginn der garantierten Zeitscheibe bei zeitkritischer AusfGhruag in B18cken yon bis zu 4 K 60-Bit-Worten aus dem externen Kernspeicher und Zur~ckschreiben dieser B15cke mit dem neuen aktuellen Bit-Muster nach Aufgabe der Zeitscheibe (vgl. Bild 6).
EXEC verwaltet in einem Systemzyklus alle auszuf~hrenden Benutzerprogramme nach folgendem Priort~tsschema: zeitkritische PLS-Programme (Ausf~hruag entsprechead der zugewiesenen und garantierten Zeitscheibe innerhalb der Systemzyklen), nicht-zeitkritische PLS-Programme (Ausf~hrung abh~ngig v o n d e r System-Auslastung und daher in dem Systemzyklus fur die AusfUhruag ~icht festgelegt) und BatchProgramme (Ausf~hrung am Ende des aktuellen Systemzyklus, wean die nicht-zeitkritischen PLS-Programme die Prozessoren aufgegebea haben). Zum besseren verst~ndnis dieser Zusammenh~nge sei bier iasbesondere auf Bild 4 und 5 verwiesen.
3.1.2. Ka~azit~ts - Verwalter
Alle PLS-Kapazit~ten werdea entsprechend der Aufteilung auf bis zu 15 "Abteilungea" voa dem ~ESOURCE ~LLOCATOR ~ODUL (=RAM) verwaltet (vgl. Bild 3). Eatsprechend der vorgenommeaen Aufteilung kann jede organisatorische Einheit unabh~ngig yon jeder anderen frei Gber die ihr zugeteilten Kapazit~ten verfGgea.
Die Kapazit~ts-Verwaltung wird durch eiae Reihe voa Programmen, die dauernd im Zentralspeicher zur Verf~gung stehen oder nur bei Bedarf zur AusfGhrung in die peripheren Zeatralrechner geladen werden, durchgef~hrt. Das PLS-Programm muss dutch Aufruf voa Unterprogrammen alle ben~tigten Kapazit~ten f~r die Ausf~hrung des Programmes definiere2.
Der Modul Kapazit~ts-Verwalter f~hrt die zur Aktivieruag eiaes PLS-Programmea notwendigen Aufgaben der Zuweisung (allocation), des Bindens (linking) und der Listenaufbereitung (scheduling) dutch. Am Ende eines PLS-Programmes werden die freigewordenea Kapazit~ten wieder der organisatorischea Eiaheit ("Abteiluag") zur~ckgegeben und die systeminterne Zuweisung rGckg~ngig gemacht. Einige der voa RAM durchzufGhrenden Arbeiten betreffen die Verwaltung von: o Externer Kernspeicher; o Rechenzeit zeitkritischer PLS-Programme (Zeitscheibea-Verwaltuag); o Platz uad Zugriffsh~ufigkeit zeitkritischer PLS-Programme zu dem Plattenspeicher;
611
o Ein-/~usgabe
Puffer der PLS-Programme;
o Prozess - Ein-/Ausgabe o Abtastraten
- Datenraten;
fur die delegierte
Uberpr~fung ~ritischer
~reignisse
und die Ak-
tivierung von Aktionslisten.
Wean ein laufendes
PLS-Programm versucht,
zit~t zu benutzen,
wird dieses PLS-Programm durch EXEC ~ber eine "Not-Aus"-
Routine beendet. Diese Massnahme yon Kapazit~ten
ordnungsgem~ss
eine nicht yon RAM zugewiesene
ist notwendig,
ablaufender
um eine zeitsynchrone
anderer PLS-Programme
Kapa-
Zuweisung
nicht zu beein-
flussen.
3.1.3.
Prozessdaten
Die ~bertragung Prozessrechner
- Eiaz/Au~g~b ~
der Daten ven einem PLS-Job in dem Hauptrecbner CD 6500 in die CD 1700 A, B und C und umgekehrt yon den Systemen A, B, C, E
und F in die CD 6500 (vgl. Bild 1 und 3) wird dutch den Systemmodul
DATA m
DIRECTOR
(=DD) organisiert.
Seine wesentlichen Funktionen
e Ubertraguag yon zeitkritischen
Prozessdaten
sind:
zu und yon den drei CD 1700 Pro-
zessrechnern A, B und C. Die Gesamt~bertragungsrate Eingabe und 4 kHz fur die Ausgabe° Die zeitkritische
betrigt 30 kHz fur die Daten - Ein-/Ausgabe
deutet, dass die zugewiesenen Datenraten vom PLS zeitlich garantiert
be-
werden
solange der Versuch l~uft. e Ubertragung yon nicht-zeitkritischen
Prozessdaten von und zu den drei CD 1700
Rechnern A, B und C. Die Obertragung Zeitraster
gebunden;
der Betriebsmittel e Uberspielung
dieser Daten ±st nicht an ein festes
sie erfolgt zeitlich entsprechend
in der Reihenfolge
(PLAYBACK,
der Aufrufe im PLS-Job.
vgl. Bild 3) der auf Magnetband
CD 1700 E und F zwischengespeicherten erferderliche
Betriebsmittel
den Zentraleinheiten
o Aufzeichnung verarbeitung
und den peripheren
Prozessoren)
Plattenspeicher
Arbeitsmodus Arbeitsmodus
entsprechend
~OLLECTION=DC)
und die Untersysteme
in ge-
Messwerten auf Platte f~r die Nach-
Kleinere Datenmengen kSnnen von den PI~auf die Platte geschrieben
werden.
kSnnen Ein-/Ausgabe-Operationen
den verf~gbaren Betriebsmitteln
DATA DIRECTOR ist dafUr verantwortlich yen den kernspeicherresidenten
wean dafUr
Rechenzeiten
durchfUhren.
nach dem Versuchsende.
Jobs im zeitkritischen
sammeln~ATA
sind (Plattenzugriffe,
yon Rehdaten und kalibrierten
im nicht-zeitkritischen
bei den Systemen
Daten zur CD 6500 Platte,
verfUgbar
rade keine schnelle Datenerfassung
zur VerfUgung stehen-
in jedem Systemzyklus
Daten-Puffern
der PLS-Jobs
und sie an die Prozessrechner
Jobs
zu dem
ausfUhren.
die Prozessdaten
(vgl. Bild 6) zu weiterzugeben
bzw.
612 CD 6500 Zeatraler Kernspeicher
~ E / A Puffer ~Lsfjrb 1
Syste m ~ffer
Eiagabe
~
Residente Puffer
D IDAcTAoR
l
E/A Progr.
I
°
PLS.Job I TC-Bereich i
PLS ~Job TC-Bereich 2
I :
CD 1700 System Module
1
/ PLS-Job I NTC-Bereich 1
Pl~-~Job
NTC-Bereich 2
•
IJ
l
Ausfi/hrbarer Code PLS-Job 1 PLS-Job 2 Pr~fst~nde PIZ-Job n.
xterner vaernspeicher
Bild 6: Fuaktions-Diagramm des PLS-Datenflusses
von ihnen Prozessdaten zu ~beraehmen uad sie auf die keraspeicherresideatea Daten-Puffer der PLS-Jobs zu verteilen (~ATA ~ISTRIBUTION=D_~D). Vergleiche hierzu Bild 4 bis 6. Alle Prozessdate~-Puffer der PLS-Jobs und die parallel ausfihrbaren E/A-Routinen liegen ausserhalb der Feldl~nge der PLS-Jobs. Dutch diese E/A-Seperation wird es ermSglicht die Datea-Puffer fdllen und leeren zu kSnnen w~hrend sich
613
der zugehSrige
PLS-Job im externea Keraspeicher
DD- und DC-Aktivit~ten NTC-Aktivit~t).
befindet
(vgl. Bild 4 und 5:
liegen immer vor oder hinter der zugehSrigen TC- oder
Wird der PLS-Job aktiviert
(durch EXEC) hat er Nber die
E/A-Rolltinen Zugriff zu seinen Prozessdaten-Puffern
(vgl. Bild 6).
3.1.4. Mensch - Maschine - Kommunikation
Die Steuerung und ~berwachung der PLS-Jobs durch den Measchen wird mit dem System-Modul
MAN MACHINE COMMUNICATION
sowohl die Bildschirmger~te
(=MMCOM) sichergestellt.
Mit ibm werden
als auch die PrHfstands-Fernschreiber
bedient
(vgl. Bild 3).
Der Iaformationsaustausch
zwischen dem Betriebssystem,
(PLS-Jobs) im CD 6500 Hauptrechaer ermSglicht
den Versuchsprogrammen
und den Fernschreibern
an den PrNfst~nden
u.a. folgende Funktionen:
o Start und Abbruch eines PLS-Programmes; o Daten~bertragung
zum PLS-Programm
o Ausgabe yon Informationen vom PLS-Programm
(z.B. Versuchsparameter);
(z.B. Fehlermeldungen,
Bedienungsanweisungen,
Daten)
zum PrNfstands-Bediener.
3.1.5. ~i~n~t~r~gEa~m ~
Hier sind neben den Nblichen UTILITIES Hilfs- und System-Startroutinen, o Dieastprogramme
(vgl. Bild 3), wie Compiler
folgende Funktionen
etc., Lade-,
besonders hervorzuheben:
fur folgende Aufgaben:
oo Von FORTRAN IV aufrufbare
Unterprogramme
fur die Definition
der Prozess-
Aufgaben in dem PLS-Versuchsprogramm; oo Verst~rkerpr~fung; oo Kalibrierung; oo Aufbereitung
yon Submultiplexer-Daten;
oo Packea und Entpacken von Daten; oo Kodieren und Dekodieren yon Daten; o Automatische
Initialisierung
yon Batch-Jobs
zur Aufbereitung
der Plattenda-
teiem~ die durch PLS-Jobs erzeugt wurden (sog. PLS-Nachverarbeitungs-Jobs). Mit ihnen ist die schnelle Erstellung der Versuche
mSglich.
auch ein off-line
yon Diagrammen
fur die Interpretation
(Neben dem direkt ge~oppelten Trommelplotter
Mikrofilmplotter
fur grosse Diagramm-Mengen
ist z.Z.
verfNgbar.)
614
3.2. CD 1700 System ~ Module
Die f~nf zentral installierten CD 1700 Prozessrechner-Systeme 3) uaterscheidea
(vgl. Bild 1 uad
sich ia zwei Gruppea:
3.2.1. _La~g~eit Prozessdaten Eia-~A~s~a~e_
Die Systeme CD 1700 A, B u n d
C zeichaea sich durch folgende Eigenschaftea
o Echtzeit Datea - Ein-/Ausgabe
mit periodischer Abtastfrequeaz
(STREAM-Datea,
vgl. Bild 2 uad 3). Dazu werdea die Datea mit eiaem Multiplexer queazen zwischea 4 uad 1024 Hz abgetastet zwischea den CD 1700 Untersystemen kritisch im Systemzyklus o Ein-/Ausgabe
bzw. ausgegebea.
MDC mit Fre-
Die Ubertragung
und dem CD 6500 Hauptrechaer
geschieht zeit-
yon 250 ms (vgl. Bild 4 and 5).
voa Daten zu oder yon dem Prozess ia eiaem zeitlich nicht garan-
tierten E/A-Zyklus,
d.h. nicht-zeltkritisch
3) als Einzelwerte.
Die Abarbeitung
Reihenfolge
aus:
der Aufrufe im PLS-Job,
(ONE-SHOT-Daten,
kritische Grenzwerte
(incl.
Interrupt)
und Eaderungen
erfolgt in der
wobei bei jedem Aufruf aur ein Wert ~ber
den A/Q-Kanal der CD 1900 eingelesen bzw. ausgegeben o Uberwachung yon digitalen
vgl. Bild 2 and
dieser Datea - Eia-/Ausgabe
wird.
und analogen Prozess-Kaa~len
auf
(CRITICAL EVENT ~ONITORING=CEM , vgl.
Bild 2 und 3). Die Uberwachuag der Kan~le auf kritische Ereignisse kana mit Frequenzea von 4 bis 128 Hz vom PLS-Job vorgew~hlt o Automatische
Einleitung
yon dutch das PLS-Programm
(~RITICAL EVENT ~EACTION=CER, his festgestellt
wurde
werdea. festgelegten
vgl. Bild 2 uad 3), falls ein mritiscnes Ereig-
(z.B. Ausgabe von Eiazelwerten,
einer schnellen Datenerfassung,
Massnahmen
Starten oder Beeaden
Abbruch oder Start der Uberwachung
anderer
Kaa~le auf kritische Ereignisse). o Automatische
Ausf~hrung
Notabschaltungen)
yon Aktionen zum Prozess (ONE-SHOT-Ausgabea,
f~r den Fall, dass der laformationsfluss
rechner und damit zum PLS-Job unterbrochen
Die System-Software inhaltet
der CD 1700 Systeme A, B u n d
zum CD 6500 Eaupt-
(FAILURE ACTION,
vgl. Bild 2).
C ist uahezu identisch und be-
folge~de Kemponentea:
o Allgemeiaer
Monitor
o STREAM-Programm o Monitor
wird
z.B.
(~IGH ~PEED MONITOR=HSM)
f~r die Ein- uad Ausgabe
als Kern des Betriebssystems;
niederfrequeater
Programm CEM fGr die Uberwachuag kritischer
oder Uaterschreituag
yon Daten nach Amplitude
treten yon Interrupt-Sigaalen;
Daten;
Kan~le auf ~berschreitung
oder Steigung uad auf das Auf-
615 o ONE-SHOT-Programm
zur Ein- und Ausgabe yon Einzelwertea;
o Routinen f~r die COMMUNICATION
(=COM) zwischen dea CD 1700 Untersystemen
und
dem CD 6500 Hauptrechner; o Programmpa~et
zum Ladea und Starten der CD 1700 Systeme u.a. von dem Haupt-
rechner CD 6500 her; o Oa-~&ne Testprogramm.
3.2.2. Kurzzeit
Prozessdaten Ei~gab~
Die we~entlichen Funktionen
der Systeme E und F sind:
o Startea uad Beenden einer schnellen Dateaerfassung digitals u~d analoge Messwerte
(BURST, vgl° Bild 3) fur
einer vom PLS-Programm vorgegebenen Wertezahl.
Die Anweisungen kommen vom zugeh~rigen
PLS-Job im Hauptrechner CD 6500 oder
als Rea~tioa CER vom CD 1700 Uatersystem A, B oder C, falls bei der Uberwachuag auf kritische Ereignisse Grenzwerte
festgestellt
mit 50 kHz, zwei Kan~le kSanen mit je 25 kHz
werden.
Datea werden auf Magnetband
und im nicht-zeitkritischea uad auf die zugehSrigen (PLAYBACK~
der
pro CD 1700 Untersystem E und F betr~gt 50 kHz; maxi-
mal ~ana damit ein Aaalog-Kanal
o Eingelese~e
eiae ~berschreitung
wurde.
o Die Summea-Abtastfrequenz
etc. abgetastet
eines Dateakanals
(Doppel-Einheit)
zwischengespeichert
Modus auf den CD 6500 Plattenspeicher
PLS-Jobs vom System verteilt.
vgl. Bild 3) wird vom System immer daan automatisch
wenn darer erforderliche
Betriebsmittel
zeiten ia den Zentraleinheiten
verf~gbar
und den peripheren
~berspielt
Diese Uberspielung vorgenommen,
sind (Plattenzugriffe, Prozessorea)
Rechea-
uad das CD 1700
System gerade keinen BURST aufzeichaea muss.
Die System-Software
der CD 1700 Untersysteme E und F i s t
nahezu identisch und
umfas~ folgende wichtigen Kompoaenten: o Allgemeiaer
Moaitor
o BURST-Programmsystem
(HIGH SPEED MONITOR); fur die Aufzeichnung
o Routiaea fur die COmmUNICATION
hochfrequenter
Datea;
zwisc~en dem CD 1700 Untersystem und dem CD 6500
Hauptrechaer; o Programmpaket
zum Laden uad Starten der CD 1700 Systeme u.a. yon dem Haupt-
rechner CD 6500 her; o On-LizLe Testprogramm.
616
LITERATUR:
CIS Schulz, K.: Motor - Endurance - Testing in aa Automotive Company. Second International Symposium on Automation of Engine and Emission Testing, Queen Mary College, University of London, London, Sept. 1973. ~2S Bender, R°, Reiter, H.K.: Process Control System for Test Stand Data Acquisition and Control in an Automotive Company. International Computing Symposium 1973, European Chapters of the Association for Computing Machinery (ACM), Davos, Switzerland, 4 - 7 Sept. 1973.
ANSCHRIFTEN
DER
AUTOREN
618
Bancsich, Johannes; Rechenzentrum der Universit~t Wien A 1097 Wien, Garnisongasse 13 Mitautor: G. Vinek BSsmann, H.; Entwicklungsb0ro Werum 3141 Erbstorf, Waldweg 42a Mitautoren: A. Tarabout, W. Werum Brunner, P.J.; Entwicklungsb~ro Werum 3141 Erbstorf, Waldweg 42a Mitautoren: W. Hinderer, W. Werum Czaikowski, Peter-Michael; AEG-Telefunken , Abt. A511/VS 7750 Konstanz, B~ck!estr. I-5 Mitautoren: D. Reimer, H.-J. Schulz D0rr, D.; AEG-Telefunken, Fachbereich Industrieelektronik 1000 Berlin 33, Hohenzollerndamm 150 Mitautoren: S. Eichentopf, U. Prahl, G. Siegel, G. Tebling Eggenberger, Otto; Institut f~r Datenverarbeitung in der Technik der Gese!Ischaft f~r Kernforschung mbH 7500 Kar!sruhe I, Weberstr. 5 Eichenauer, Bernd; ESG 8000 M~nchen 86, Postfach 860505 F~rber, Georg; PCS GmbH 8000 M~nchen 82, Dompfaffweg 10 Freyberger, F.; Institut fur Me~- und Regelungstechnik der TU 8000 M~nchen 2, Arcisstr. 21 Mitautoren: Ch. GeiBler, H.-R. Tr[nkler Goldenberg, A.; Fakult~t fur Physik der Universit~t 7800 Freiburg, Hermann-Herder-Str. 3 Mitautoren: Ch. Schlier, W. Schupp Gottschalk, Werner; Siemens AG, Bereich Eisenbahnsignaltechnik 3300 Braunsehweig, Acker Str. 22 Hotes, Helmut; SCS 2000 Hamburg 39, 0berseering 8 Kalis, H.; Philips Forschungslaboratorium GmbH 2000 Hamburg 54, Postfach 540840 Mitautoren: M. Klinck, G. Landvogt, J. Lemmrich, G. SchrSder Killian, Klauspeter; Klinisch-Chemisches Institut am St~dt. Krankenhaus, Abt. Datenverarbeitung, 8000 M~nchen-Harlaching Mitautor: M. Knedel Klessmann, Horst; HMI 1000 Berlin 39, Glienicker Str. i00 Kneis, Winfried; Gesellschaft fir Kernforschung, Zyklotron 7500 Karlsruhe I, Weherstr. 5 Mitautoren: K.H. Degenhardt, W. Woletz
619 Koch, G.; BBC 6800 Mannheim 1, Postfach 351 Mitautor: J. Heger Kreuter, Konrad; ESG 8000 M~nchen 81, Arabellastr.
4
Kussl, Volkmar; BBC, Abt. ZAF/B 6800 Mannheim 1, Postfach 351 Lauber, R.; Institut f~r Regelungstechnik und Proze~automatisierung der Universit~t 7000 Stuttgart i, Seidenstr. 36 Moog~ Rudolf; IITB der Fraunhofer-Gesellschaft 7500 Kar!sruhe-Waldstadt, Breslauer Str. 48 Nehmer, J~rgen; !nstitut f~r Datenverarbeitung in der Technik der Gesellsehaft f~r Kernforschung mbH 7500 Karlsruhe 1, Weberstr. 5 Offer, Udo; Siemens A G E STE 4 8520 Erlangen, Werner-von-Siemens-Str. Pfeifer, T.; WZL der RWTH Aachen 5100 Aachen, W~llnerstr. 5 Mitautor: U. B~ck Ramamoorthy, C.V.; University of California Berkely, California 94720, USA Reiter~ Heinz 3180 Wolfsburg, Hochring 32 V Rieder~ Peter 7500 Karlsruhe, Am Rennbuckel 13 R~b, Werner; Mathematisches Institut der TU 8000 M~nchen 2, Barer Str. 23 Mitautor: G. Schrott Schnarre, Inger; SCS 2000 Hamburg 39, Dberseering 8 Schoeffler, James D.; Case Western Reserve University Cleveland, Ohio 44106, USA Sch~ring, A.; WZL der RWTH Aachen 5100 Aachen, W~llnerstr. 5 Schumacher, Wilfried; IITB der Fraunhofer-Gesellschaft 7500 Karlsruhe-Waldstadt, Breslauer Str. 48 Stolze, Lothar; SCS 2000 Hamburg 39, ~berseering 8 Wagner, Friedrich; Unicomp GmbH 7501 Blankenloch, Singerstr. 3 Mitautor: H. Woda
620 Waite, William M.; Department of Electronic Engineering of the University of Colorado Boulder, Colorado 80302, USA Weck, M.; WZL der RWTH Aachen 5100 Aachen, WHllnerstr. 5 Mitautor: A. SchHring Wendelin, Roland; Siemens A G E STE 3 7500 Karlsruhe, Rheinbr~ckenstr. 50 Wiethoff, G.; Hoesch H~ttenwerke AG, Neubau-Abteilung-Automation 4600 Dortmund-HSrde, HSrder Burgstr. 15-17 Mitautoren: H.-J. St~bier, R. He~ling Wobig, Karl-Heinz; Siemens AG, Bereich Eisenbahnsignaltechnik 3300 Braunschweig, Postfach 3327 Zahn, Joachim; HMI, Bereich Datenverarbeitung und Elektronik 1000 Berlin 39, Glienicker Str. 100 Mitautor: P. Abend, Z. Komor Zimmermann, Rolf; Dornier GmbH 7990 Friedrichshafen, Postfach
648