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
.....
~/o request su~rout~z_~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
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 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
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--
// __/___;
-.~;7
-
Darstellung
2
~/__
Stellgr~l~e
/4
,
.~,~ 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
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 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 0RI3.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 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-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>{(
> 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
>(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 0NSIGNAL eines ProzeB-SteuerEPSZeit/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
