Entwicklung eines rechner-betriebssystems für die labordatenerfassung

Annlyiica

Chimica _4cto, 95 (1977)

161-175

Computer Techniques and Optimization 0 Elsevier Scientific Publishing Company,

Amsterdam

-Printed

in The Netherlands

ENTWICKLIJNG EIM3!3 RECHNER-BETRIEBSSYSTEMS LABORDATENERFASSUNG

W. EICHELBERGER*,

BASF Aktiengeselfschaft, (Eingegangen

G. BAUMANN

FiiR DIE

und H. GUiVZLER

6700 Ludwigshafen

(Rundesrepublik

Deutschland)

den 11. Mai 1977)

ZUSAMIvlENFASSUNG Fii einen in der Labordatenerfassung eingesetzten Proze&echner IBM-System/7 wurde ein Betriebsystem entwickelt und auzgetestet. Dieses Betriebssystem basiert auf der Methode der ADUSelbstsynchronisation 2L5 Taktgeber fti verschiedene Funktionen ade 2-B. die Dateniibertragung sum HostComputer. Die Interrupt-Bedienung wird asynchron in die Synchronisationszyklen der Analog-Digital-Umsetzer eingespielt. Die benuttte Strategic eignet sich f& mittelhohe his hohe Rechnerbelastungen durch die angeschlossenen Geriite. SUMMARY

The development of a computer opemtional system for data acquisition 4n operational controller, run on an IBM Systeml7. has been developed and tested for analytical data acquisition. This control system is particularly satisfactory with high external interrupt rates. It is based on self-synchronization of the analog-digital converters. The synchronization cycles serve as the trigger for various functions, e.g. for data transfer to the host computer. The interrupt servicing is done intermediately in an asynchronous manner.

Die zentralen analytischen Laboratorien in der chemischen Industrie sind im allgemeinen Servicebetriebe, die, soweit sie tti Forschunq und Verfahrensentwickhmg arbeiten, Routineaufgaben nur in untergeordnetem Umfang zu l&en ha’oen S&dig wechseinde Aufgabenstelhmgen erfordem eine Vielzahl von Methoden und MeBverfahren mit einer Vielzahl verschiedener Analysengeriite. Dabei sind einerseits oft mehrere Auswertemethoden fiir dasselbe Analysengefit erforderlich, andererseits k&men dieselben Auswertemethoden fti mehrere Typen von G&ten sinnvoll verwendet werden. Die Auswertung iiber Computer entlastet das Laborpersonal von der mechanischen Tstigkeit des Ausmessens von Registrierkurven und vergr%ert damit die Gedteauslastung bzw. den Probendurchsatz pro Mitarbeiter. Gleichzeitig erfordert die eindeutige analytische Bestimmung einer Substanz oft mehrere Analysen nach verschiedenen Verfahren, &od& der durch Korrelation und Zuordnung erforderiiche nicht unbetr2chtliche Verwaltungsaufwand durch zentrale Auswertung mittels Datenve_rarbeitung eher noch vergr33ei-t wird.

162

Die wachsende Zah! von Analysengetiten im Analytischen Labor der BASF zwangen in der Vergangenheit zu einer Trennung der drei Teilaufgaben Datenerfassung, Datenorganisation + VerwaItung sowie Ausmertung, so da13 eine hierarchische Rechnerorganisation gew%lt worden war (Abb. 1) [ 1] . Erhijhter Durchsatz und weitere Analysengetite (Verdoppelung der Zahl der Analysen/Tag innrerbalb eines Jahres bei leicht reduziertem Personaleins&z) zwangen im Teilbereich Datenerfassung zum Uberdenken des Erfassungssystems und der Methodik der Datenerfassung. DATENERFASSUNGSSYSI’EM AnzuschMknde

IBM/7

LabormeBgemSe

Die durch das Computersystem zu bedienenden Labormel3getite samt den zu iibemehmenden MeOwert-Z-ten lot sich als Anforderungsmatrix darstellen (Tab. 1). Die insgesamt anzuscbIieI3ende Zabl der Analysengtite betriigt 64. Wenn alle Getite simultan mit maximal mijglicher Z&hate hetrieben wiirden, w8.re eine Gesamterfassungsratevon 21000 M&we&n s-’

zu erwarten. Da diese Z2hlrate nicht zu bew2ltigen ist, muJ3der simultane Betieb der beiden schnellsten GerXe ausgeschlossen werden. Unter Wegfali

eines der beiden Geriite “Massenspektrometer, hochaufl?_jsend” (MSH) und “GC-MS-Kopplung” (MSK) ergibt sich im ungiinstigeren Fall eine maximale Z&hate von 13000 MeI3werte d’ und im Norma&II (GC-Getite mit 2 MeBwerten d’) eine Z&Irate von 12300 Megwerten s-l. Es ist also ein

Betriebssystemzu konzipieren, das erlaubt, aus 11 Getitetypen mit insgesamt 64 MeBgergteneine Z2hhate von ca. 13000 MeA3wertens-i zu erfassen und

an den Verwaltungsrechner IBM 1800 weiterzugeben. Die Realisierung einer derartigen Aufgabenstellung [Z] und Bausteine fti die Entwicklung von Betriebssystemen (3-53 sind verbffentlicht. 1053

1816

1442

1443

-I

DO-IX 6 IR,uvl,

16M/7

16 bit par

IBM

1800

6sc

HB 607(

4000 -i

DO-D1

2 NMR g K, Wcrte i-ztnbd

8bitWr:gEiyme

I 8 t_uftne&Efae 6 tJibOftWlliMk

3 x B&F

I616

(3x7

6111

hlBl

T-IT I200 b/s \

I

TS-Tenrind

Abb. 1. Rechnerhierarchiefti das Analytische Labor der BASF Aktiengesellschaft.

163 TABELLE

1

Anforderungsrnatrix

fiir die Datenerfassungsleistung

Geriiteart

Zahf der Gedte

hlef3wert Z&Irate

AnschluR Art

Dynamik (bit)

Auf5 sung (bit)

l-20 l-20 100-200 100 40

analog analog analog analog digital

23 24 14 14 12 bit* lO’/lWf

14+Vorz. 14 14 14 12+Vorz.

Massenspektrometer niedrigauflasend

1000

analog

Massenspektrometer ho&auf&end

max. 8000

GC--MS-Kopptung

10000

digital Abszise + Ordinate analog

Ramanspektrometer UmweItiiberw8chung LuftmeOgerste

1 0,s

digital nnalog

(5-l ) Gas-Chromatographen Typ 1 GasChromatographen Typ 2 Infrarotspektrometer Ultmviolettspektrometer Kernresonanzspek~mmeter

36 7 3 + la 2 2

10' 14bit*l 14bit*16 Abszisse: 28 BCD Ordinate: 14bit*l 14bit*l6 ASCII 14

14 8 8 14 ASCII 14

aIn Vorbereitung.

Betriebssystem-Konzept Es gibt prinzipiell verschiedene MBglichkeiten, Proze(Jperipherie (hier: LabormeBgeriite) zu bedienen, die sich zwischen den Extremen: Bedienung auf Anforderung (Interrupt) und Zyklische Bedienung (Polling) bewegen. Einfache Uberlegungen zeigen, daJ3im Falfe der maximalen Ausfastung (worst case) die zykIische Bedienung hahere Erfassungsmten erlaubt, als die Bedienung auf Anforderung, wo im auemeinen pro IMeUwert zwei Interrupts zu bedienen sind: 1. Interrupt: Melfgetit fordert Ubemahme eines M&werts an, Analog-Digit4 Converter (ADU) wird adressiert. 2. Interrupt: AnalogDigital Umsetzung beendet, MeBwert kann eingelesen werden. Bei zyklischar Bedienung enffiillt dagegen der Getiteinterrupt zur Adress&rung des ADU soPrie die damn anschlS3ende Wartezeit (Convertzeit), his der digitalisierte Mei3wert iibemommen werden kann. Im Falle niedriger Au&stung ist die Bedienung auf Anforderung giinstiger, da der durch das Interrupt-Handling notwendige System-Overhead in die ohnedies freien Beserven des Recbners fait. In einem Labor tit unvorhersehbarer A~o~~ng~i~hte kann aIs0 nur e.ine Kombination beider Grenzfiille sin praktikables Ezgebnis liefem. Im e&&en muf3die Ubergangsstelle bzw. die Artder Kombination durch Lastberechnung gefwden werden, d-h, die fiir die einzelnen Verarbeitungsrout&en notwendigen Designarbei”Lenmiissend~chg~~ und der dazu

3.64 erforderliche Code ausge&hlt werden. Fiir die zeitkritischen Routinen sollte vrenigstens ein Alternativdesign erstellt und die Optimierungsmiiglichkeiten des Codes untersucht werden. Dabei ergibt sich “nahezu von selbst” die Verarbeitungsstrategie und daraus clas Gesamtdesign Im einzelnen zeigte sich, da.8 folgende Punkte einer genaueren Untersuchung bedurften: (a) Verwaltung der leeren und vollen MeOwertPuffer fiir die verschiedenen Geriite; (b) Strategie der Selbstsynchronisation der ADU’s und Generierung einer Convert-Tabelle; (c) Interrupt-Erkennung aufgrund des rechnerspezifischen Hardwarffiruppeninterrupts, Festlegung der Interruptpriorit%en; (d) Verteilung der Getite und Software-Moduln auf die Hardware-Levels des Rechners; (e) Codeoptimierung beziiglich Codehinge (Kernspeicherverbrauch) und Laufzeit. (Je vielf5ltiger die Anforderungen sind, desto kier mug die Laufzeit des Einzelmoduls werden, urn ilberlappte Verarbeitung zu ermijglichen). Verwaltung der MeBweri-Pu#er_ Jedem aktiven LabormeBger?it mul3 ein Mebwertpuffer bereitgestellt werden, in welchem die vom ADU gelieferten digitalisierten MeDwerte eingespeichert werden. Durch Wechselpuffertechnik ist sichergestellt, da.8 jedem Gerlit such dann ein Puffer zur Verfiigung steht, wenn der gerade gefilte Puffer noch nicht abgearbeitet, d.h. zur IBM 1800 iioertragen worden ist. Ein dynamisch verwalteter Pufferpool enthat somit leere und voile Puffer, wobei ln einer Verwaltungstabelle jeder.P’uffer “gekennzeichnet” sein mu& Fiir die Pufferverwaltung stehen drei Altern&iven zur AuswahI: (a) Die Verwaltungstabelle enth?ilt die Adressen aller Puffer mit Belegungskennzeichnung. Es wird sequentiell der nachste nicht belegte Puffer gesucht. Das Fiillen geschieht “von vome nach hinten”, das .Abarbeiten von “hinten nach vome”. Die Puffertabelle entspricht einem “Keller”, dessen Fiillhijhe ein Ma13fdr die momentane Last darstellt (wichtig fiir statistische Zwecke). Der Nachteil des Verfahrens besteht darin, da13die Suchzeit nach einem leeren Puffer bei hijchster Last am grijgten ist, weil dann der erste leere Puffer weit hinten steht. (b) Eine “Einworttabelle” enthat das Belegungsabbild des zugehijrigen Pufferpools bzw. Teils des Pufferpools (bit i = 1: Puffer i leer, bit i = 0: Puffer i voll). Die Suche nach einem leeren Puffer wird nach dem Zweierschrittverfahren (Wageverfahren) der Eixiworttabelle durchgeftirt, desgleichen die Abarbeitcng. Dieses Verfahren hat den Vorteil koristanter Suchzeit unabh’dngig von der momentanen Rechnerlast. Die Modul-Laufieit ist also berechenbar. (c) Es wird in Ringgufferteclmik gearbeitet. Eine Tabeile enthat die Adressen. aller Puffer. Zus%zlich existieren clrei Pointer; der erste zeigt auf den r&h&en freien Puffer (empty pointer), der zweite auf den tichsten voilen Puffer (ready pointer) und der dritte schlief3lich auf den letzten vollen Puffer (end pointer). Die Suche nach einem leeren Puffer besteht aus der indirekten Adressierung mittels empty pointer, die Abarbeitung geschiebt von ready pointer bis end pointer. (Der Unterschied zwischen end pointer und empty

166 pointer zeigt diejenigen Puffer an, die gerade aktiviert d-h. teilgefiillt sind. Wenien anstatt einer Tabelle mit drei Pointern zwei Tabellen mit je 2 Pointem verwendet, erspart man sich einige Priifungen, was zu kiirzeren Laufzeiten fiihrt. Beim Vergleich der drei Altemativen ergibt sich nach entsprechender Optimierung, da13Verfahren (a) wegen zu langer Lallfzeit ausscheidet, Verfahren (b) die kilrzeste Laufzeit hat, und Verfahren (c) in mehrere Teilaufgaben auftrennbar ist; die gesamte Laufzeit ist jecioch M. 15% lZnger als diejenige nach (b). Bei verschachtelter Abarbeitung der Anforderungen mu2 das Hauptgewicht auf mijglichst kurze Laufzeit der Teilaufgaben gelegt werden, so da2 die Entscheidung wegen der Auftrennbarkeit zugunsten Verfahren (c) fieL Stmtegie der ADU-SeZbstsynchronisation. Die Forderung nach maximaler Durchsatzleistung verbietet die Realisierung eines reinen Anforderungskonzepts. Es wurde daher davon ausgegangen, da13im Falle eines Meawe& ~bernabme-Interrupt der digitalisierte _4nalogwert bereits vorliegt und zwar in einem jedem Mel3getit zugeordneten “Einwort-Puffer”. Die dem ubernahmeInterrupt zugeordnete Verarbeitungsroutine kopiert nun sofort den aktuellen MeBwert aus dem Einwort-Puffer in den Mef3we&Puffer, ohne die Convertierungszeit des ADU abwarten zu m&en. Der ADTJ l&&t. dabei im “free-rum mode”, d-h. mit Selbstsynchrcmisation. Bei IPL (Initial Program Load) wird die erste Adresse des ADUMultiplexors adressiert und eir, Convertbefehl aufgesetzt. Nach Ende der Konver, ?rungszeit liefert die ADU-hardware einen “Convert-complete-Interrupt”. Das zugehijrige Modul iibemimmt den Digitabvert in den der Multiplexoradresse zugeordneten Einwortpuffer und setzt danach einen neuen Convertbefehl fti eine neue Multiplexoradresse auf. Damit verschieden schnelle Gex5te verschieden oft vom Converter bedient werden, muf5 eine “Converttabelle” generiert werden, in welcher die Folge der Multiplexoradressen einzutragen ist. Schnellere Getite treten also in der Converttabelie haufig auf, mittelschnelle weniger hlufii und langsame Geriite__nur einmal. Nachdem die Converttabelle dieses ADU abgearbeitet ist, wird entweder auf einen weiteren ADU und dessen Converttabelle umgeschaltet oder wieder von vom begonnen. Die zeitaufwendigen Analog-Digital-Umwandhmgen werden also in Eigensynchronisation nach einem durch die Converttabelle definierten priorit$tsgesteuerten Polling durchgefilhrt, wodurch such bei maximaler Erfassungslast die geftirchtete Lnterruptverklemmung verhindert Wild.

Das Erfassungssystem IBM/7 arbeitet mit vier unabh5ngigen HardwareLevels (Level 0 bis Level 3). Auf Level 0 mit der hijchsten Priorit.% wurde ein ADU mit den schnelleren GerZten generiert (ADU 1). Dieser ADU liefert bei einer Convertzeit von 50 ps eine maximale Leistung von 20000 Konvertierungen s-‘. Fiir die ZZhlrate von 10 kHz fiir GGMS-Kopplung enth5lt die Converttabelle also an jeder zweiten Stelle dessen Multiplesoradresse. Die Adresse des niedrigauflijsenden

166

i%ssenspektrometers (MN) tritt an jeder 10. SteUe ti diejenige jades Inftarotgeriites sp%estens an jeder 50. Stehe auf.. A& Level 1 xvw&tn zwei ADU’s fiir die GGGerSe generiert (ADU 2 + 3). Sic haben wegen der hijheren Dynamik eine maximale Wiederhotfrequenz van 7000 Konve&zungn ~9. Die Convertfabelleenthiiltjedes angeschlossene GerZt nur einmal. Die beiden oberen Levels der IBM/? sind somit jeder Kir sich “eigensynchron-getaktet”. Durch einen extemen “Interrupt-Timer” wird, wie in “Codeoptimienmg” (s.u.) niiherbeschrieben,der Betriebszustandund die ArbeitsweisedieserTaktungen iiherwacht. In den 20-kHz-Takt von Level 0 wird der Da$entransfer von /7 znr 1Ri.i 1800 zwangssynchronisiert eingeschleust (1 Wort pro Takt), so da.6die maximal mijghcheTransferratemit 20 kHz die Ehfassungsieistung an der Proz&peripheriemit Sicherheitiibersteigt. Nach jeweils 220 Worten liefert die 1800 einen Quittierungsinterrupt,der anzeigt, d&3 ein Makro-Puffer gefiilltund auf den niichstenumgeschahet worden ist. Da dieser Quittierungsinterruptmit einer Verzogerungvon ca. 500-700 jis abgesetzt wird, mUa der Pufferpool der f7 w?ibzenddieser Zeit die angekonunenenMeDwerteaufnehmen und balten konnen. Die erhohte Absetzgeschwindigkeit wZhrend der eigentlichen Obertragungszeit steltt jedoch sicher, da2 ein tfberlaufen des /7Pufferpools ausgeschlossen ist. In den 7 kHz-Takt von Level I werden die MeBwert-ffbemahme4nterrupts eines TeiIs der Meageriitevan ADU 1 asynchron eingeschleust.Urn eine Synchron--Async~n-Verklemroung auf diesem Level zu vermeiden, werden nur die schneilsten Getite auf Level 1 bedient. Alle ttbemahmeInterrupts der langsamerenGer%tevon ADU 1 sowie diejenigen&ntEcher GerZte van ADU 2 + 3 werden auf Level 2 bedient; damit wird Level 2 voilstiindig asynchron, d-h. im Anforderungsmodus betrieben. Bei dieter IConfigurationm&3 sichergestelitwenien, da13die Sunune al.Ier Modul-Laufzeiten die CPU nicht iiberlasten.Durch AuszZhlen und Eintragen auf einer Zeitachse kann dies veriflziertwerden. Intempt-Prioritliten. Da die Hardwareder IBM/7 Iediglichden Gruppeninterruptliefert, mu6 in einer Interrupt-Behandlungsroutine aus den 16 moglichen das richtigeInterrupt-bitgesucht, d.h. das unterbrechendeGerEt Iokalisiertwerden, Die Strategicder minimalenmEtieren &ker&ngszeit ist einiach; bei AnschluQvon Getitxm gleicherPrioritiitwird das Wiigeverfahrenauf denInterruptvektorangewandt,wodurch sich konstante Suchzeiten ergeben. (In bekannterWeise Iiegtder “break-even point” der Suchzeit meischensequentioneller Suche und Wiigcverfahrenbei 7 Ger%en). Bei GerWm tit yezschiedener ZMrate liegt es r&e, die 2-k aIs~~o~~~~*~r. aufzufassen und sequentielleSuche irn Interruptvektoranzuwenden, Das G&it mit hcchster EMrate wird aB Geriit I-, d.h. auf Bit 0 des Intarruptvektorskonfiguriert.

167

Danach folgen die Gertite nach falienden Ziihlraten. Ein Interrupt von GC-MS-Kopplung wird somit mit minimaler Suchzeit, d-h. im ersten Schritt erka-nnt. Gem”te-und Modulrzuffeilung auf die Hardware-Leveis des Recliners. Die IBM/? besitzt 4 Hardwarelevels (Level O-Level 3), deren jeder 16 Sublevels (SL O-SL 35) a&we&. IWhre~ld sich die Hardwarebvel in ihrer Prior&it unterscheiden, sind die Sublevels jedes Levels untereinander gleichrangig. Die Einsprungadressen f& die Sublevels werden also nach dem FIFO-Prmzip in die Warteschlange eingetragen. Verarbeitungsmoduln auf tiefer liegenden Levels kijnnen durch “Maskienmg” vor dem Verlust der Rechnerkontrolle durch Mod&n oder Int~p~out~en hoherfiegender LeveIs bewahrt werden. Diese Maskierung ist notwendig, urn Datenbereiche verschiedenen Levels zugQ$ich zu machen, deren jedes “Read/Write-Erlaubnis” hat. Es ist offenbar, d& der maskierte Bereich eines Moduls eine Laufzeit haben mu& die kiirzer ist aIs das jeweihge “Laufzeitloch” zwischen den Mociuln der hijheren Levels, gegen die die Maskierung wirksam zu sein hat. Dariiber hinaus mu13bei Maskierungen im einzelnen untersucht werden, ob infofge eines asynchronen Interrupts auf der Synchronebene eine Btockierung eintreten kann, we1che.z.B. durch einen doppelten Interrupt ausgelijst wird (Interrupt pending). Die Berechnung der maximai zuI%sigen Maskiertmgszeit w$-d naturgemiia umso komplexer, je mehr hoherliegende Levels maskiert wenlen. Dabei kann der zu berechnende Uberlapp seIbst zeitabhbgig sein. In der vorfiegenden Systemstrategie ist es fedigiich notwendig, die PufferverwaItungsroutinen zu maskieren,~weiI sie von drei verschiedenen Levels angesprochen werden und zwar: von Level 1 und 2 durch die MeRwertiibemahmeroutinen, wenn ein MeSwertpuffer voll ist und ein leerer Puffer bereitgestellt werden mu& durch die ~eh~~un~rou~en bei Start 5zw. Ende einer von Level 3 Messung, wo jeweils der erste leere Puffer bereitgestellt bzw. der let&e, teilgefiite Puffer zur U?ertragung freigegeben werden mug. Von den insgesamt 4 Teilroutinen der Pufferverwaltung hediirfen zwei der Maskienmg; die Maskierungszeit konnte durch Iangwieriges Optimieren auf 4 bzw. 6,8 fitsbesc&i.nkt werden. Im iibrigen ist die Systemstrategie so a~usgeiegt,da3 weitem Maskierungen nicht notwendig sind. Die Verteilung der synchron und asynchron betriebenen Levels trug wesentfich zu diesem Ergebnis bei. Die Verteilung der wichtigsten Verarbeitungs- und Organisationsmoduln auf die vier Hardware-Levels der /7 ist in Tab. 2 zusammengefaljlt. Codeoptimierurrg beziiglicir Ccxieriinge und Loufreit. Die fIir die Erfassung van I,,abo~aten eingesetzte IBM/7 ist mit 8K Worte Kernspeicher ausgetistet. ES konnte vermutet werden, d&5 dieser Ausbau f& die abzuwickelnden Aufgaben ausreicht. Da@ dabei optimaler Cude VOmweSetzt Werden mu% zei& sich bei iiberscbhigiier Bechncng (Tab. 3). Dm den g&&spezifischen Code mit weniger als 30 Befehlen/Ger% zu

168

TABELLE 2 Z;lordnung von Software-Moduln zu /?-Hardware-Level; Level 0 ADU I-Synchr.: 1800-ubertzagung: PufferpooIver<ung Level 1 ADU 2 + 3 Synchr.: teilw. Mefiwertiihemahme fiir ADU 1 (schnelle Gedte) Level 2 M&wertiibemahme fiir ADU 1 (langsame GerPte). ADU2+3 Level 3 KonsoIe/b%zssungStart/Ende/Rechnerstatustiberwachung/tiror Recoverytext.. Interrupt-Timer

realisieren, miissen die Gergtegruppen zusammengef&t Routinen

bedient werden.

Da der Compiler

und durch generalisierte

keinen reentrant

Code liefert, die

IBM/7 andererseits maschinenseitig kein BAR (Basisadressregister fti im Speicher verschiebliche Programme) aufweist, urn das gerade zu bedienende G&it innerhalb der GerZtegruppe durch einfache Indexienmg zu beschreiben, wird eine selbstverwaltete Basisadresse sowie ein Indexwort benulzt, welches erlaubt, ein an einer beliebigen Stelle des Kernspeichers liegendes Programm in einfacher Weise mit einer bestimmten Stelle .einer Getitetahelle zu verkniipfen. TABELLE 3 Kernspeicherbelegungfiir ein 8K-Datenerfassungssystem Verarbeitungsblock Systemroutinen Konfierationsmakros Pufferpool Pufferverwaltung,Tabellen Synchronisation, Tahellen Interrupterkelmung, Tabellen -Jerwaltingsroutinen: Messung Stsrt/Ende Rechnerstats Error-Recovery Zwischensumme Rest fiir gedtespaifischen Code (= CodeI&ge/Gedt) Free-core fiir Erweiterungen Summe

Systemdesign Vorallssch%itzung

Erreichte optimale Codelkge Worte

3K

2471

1K

882

1,5K

1502

0.75K

513

6,25K

5368

1,75K e 1752W (28W)

(23)

0

1367

8R

8192’

1457

169

Die konsequente Durchfiihrtmg dieser Strategic fiihrte zu dem Ergebnis, da& die Einzelmoduln extrem kurz werden. die meisten Moduln mehrfach benutzbar sind. Tabellen (Getitetabellen, Puffer-pool) von verschiedenen Moduln auf verschiedenen Levels ia ve_schachtelt benutzt werden k&men; ein GroBteil der Maskierungen wird dabei iiberfliisig; der Code und die Funktionen leicht durchschaubar und einfach zu dokumentieren s&d. da.s benutzerorientiertes E’ehlerhanw in einfacher Weise gerkikpezifisch cod.ie.& werden kann, da die Basisadressen der Tab&e sowie die Indexnummem des Ce&es direkt in den Indexregistern stehen. Allerdings sind nun Kontrollblijcke innerhzdb des ger~tespezifkcben Codes (10-15 Worte je Gruppe) notwendig. Die Laufzeit eines Einzelmoduls mui dabei umso kiirzer sein, je hoher seine Prioritit ist. sind 7 Moduln implementiert mit Laufzeiten zwischen Auf Level 0 2,4 ps und 17,6 ps. beta&t die maximale Laufieit des umfangreichsten Auf Level 1 Moduls 20,s gs. Auf Level 2 werden di& MeBwert-~bemahme_Interrupts bedient mit msti~.11 ~_lsLaufzeit. residieren die umfangreicheren Verwaltungsmoduln: Auf Level 3 . OperatorStation mit einigen Sekunden Aktivzeit, Eixterner-Interrupt-Timer mit 1 s Takzeit, Messung-Start/ Messung-Ende, Lampenschaltung mit ea. 50 ,us Laufzeit. Insgesamt sirxt nahezu 1uO Benutzermoduln implementiert. Das System ist volhsttidig in Assembler programmiert. Zuslitzlich wurden folgende IBMSystem-Maluos bent&at IS-95 : Konfiiurationsmakros, Initialisierungsmakros, Operatur-Station, Elrror-Processing (nicht Error-Wand&g). Das Verzweigungsmakro SPI ist implementiert, wird jedoch nicht benutzt. Weiterhin wurde der Timer nicht kor&guriert, da sein Zeitverbrauch mit ca. 200 @ri [6] fir den verlangten Durchsatz zu hoch ist. Es wird daher mit einem Externen InterruptTimer gearbeitet. ~xterner-Interrupt-Timer. Wegen des hohen Zeitverbrauchs des SystemTimers wurde auf einen fieien interrupt-Eingang ein quarzstabilisierter Uhrimp&generator gelegt, der in regelmtiigen Abstiden in ein auf Level 3 residierendes Pro~m-Modul verzrveigt. In diesem Modul werden einerseits Betriebszustandspriifungen fiir die ADU’s durcQe%hrt, andererseits jene X&s&e iiberwachf die kein ergenes StartJStopSignal liefern. Wenn not@, werden fiir diese C&ite die entsprechenden Start-bzw. Messung-Ende-Moduln a.ngestoBeh. Wenn eine “BetriebsstGrung” auf dem Synchron-Level 1 auftritt, so daB die Selbstsyn&rxksation der ADU’s auf3er ‘Bitt g&t, wird der betroffene ADU nach Durchlaufen einer Riickstellroutine neu ~estartet. Tritt die Stiirung auf Level 0 auf; wo die sclinell-en Ger8t.e konf&uriert sind, wini nicht neu gestartet, da i?IeOwerte verloren gegangen sein kijnnen-

170 ZEITF’LAN, PERSONAL-EINSATZ

Das gesamte Entwicklungsprojekt wurde nach zeitlichem Ablauf und personellem Einsatz gegliedert. J?eitZicherAblaufi Es Iassen sich unschwer 5 Pbasen selektieren. Phase 1: Grundsatzdebatte, Vordesign; Phase 2: Suche nach Alternativen, Systemdesign; PImse 3: Programmienmg und VortestlCfe; Phase 4: Optimierung und Testl.&fe; Phase 5: ‘l’estweiser On-line-Betrieb, Programmierung des Error-handling und des automatic-restart. Der zeithche Ablauf und der Uberlapp der einzelnen Phasen -%tin Abb. 2 d,argesteht.Nach jeder der drei em&enPhasen war eine Aufgabe des Projekts ohne alIzu grogen verlorenen Personaleinsatz mijglich gewesen. Pemneller Einsatz und Vemntwortiichkeiten. Es wurden vier Zust%digkeitsbereiche (ZB 1-ZB 4) definiert: ZB I Systemdesign (Strategie) und Koordination; ZB 2 Moduldesign, Programmierung und Optimierung; ZB 3 Programmienmg und SchnittsteUe 1800; ZB 4 Hardware, Leitungsinstallation. Die Durchflihnmg der Tests ist naturgema Aufgabe des Teams Der personelle Gesamtaufwand bis zur Obemahme des Sy=&rns in den Routinebetrieb (priiirz77) belauft sich auf ca. 23 Mannmonate; das Aktivit%sprofl ist in Abb. 3 dargestellt. TESTLAUFE UND TESTWEISER ON-LINE-BWRIEB

Die Reihe der Testliufe zieht sich nahezu iiber die H%te der Projektzeit. Durch diese permanente Riickkopplung der Ergebnisse auf die Programm+ung konnten Fehientwickhmgen vermieden, wertvoller Input fiir die Optimienmgsaufgabe und eine stufenweise fortschreitende Erfolgffiewil3heit erreicht werden. Der Zeitveriust durch die Notwendigkeit, _Hilfsmoduln fti Verwaltung und Errorhandling der einzelnen Testphasen mehrmals schreiben zu m&en, wurde bingenommen im Hinbhck auf die durch die Tests erreichbare friihzeitige Riiekkopplung.

Abb. 2. (lmks) Zeitlicher Ablauf Abb. 3. (1~2~~s) Aktivitiibprofil

der Projekt - I??~. des Penxmaleinsatzes

nach Z&digkeitsberei&en.

171

Einzeifests Im wesentlichen wurden Tests gem% Tab. 4, gegebenenfalls mehrmals, durchgefiihrt, urn das entsprechende Planziel (Designziel bzw. Ergebnis von Vorausberechnungen) zu erreichen. lMit den Ergebnissen wurde der Einsatz unter Prtibedingungen risk&t. On-line Betrieb Es war zu erwarten, da6 sich im Dauerbetrieb Systemabstiirze ergeben wiirden, die unter Testbedingungen nicht reaiisiert werden kijnnen. Aufgrund der praktischen Erfahrungen mug das Error-recovery und der automaticrestart nach error realisiert werden. Beim on-line-Ems&z zeigten sich folgende Fehler: (a) Interrupt-pending auf Level 2, behoben durch Ersetzen des System-Timers durch Extem-Interrupt-Timer(b) Asynchroneitit des ADU 2 auf Level 1 (intermittierend), behoben durch Extem-Interrupt-Tuner. (c) tiberlastung der IBM 1800 bei Vol.&t auf /7 und gleichzeitig aktivem I/O-intensivem Programrn auf 1800, behoben durch organisatorische Ma!3nahmen in der Jobverteilungstabelle der 1800. (d) Ausbleiben des Quittierungssignals der 1800 nach 220 iibertragenen Me6werten. Der Fehler trat nur selten auf, Ursache nicht genau bekannt. gLe)&T-input error, device-busy bei ADU 2, behoben durch error handling.

Aufgrund dieser Fehler und einiger durch den Vollastbetrieb zutage &tender Hardwareprobleme wurden alle erkannten Hardwarefehler behoben. W&end der zwangsweise dabei auftretenden Denkpause wurde ei?e weitere Codeoptimierung an den weniger wichtigen Moduln durchgefiihrt und der Systemtimer durch den Externen Interrupt-Timer ersetzt. Dazu mugten nicht nur die entsprechenden Installationsiinderungen durchgefw, sondern such das dem Timer zugeordnete Verarbeitungsmodul neu geschrieben werden. Das nunmehr irnplementierte neue System lief nach kurzer Zeit einwandfrei. AUSBLICK

Fiir die Labordstenerfassung im Analytischen Labor der BASF wurde ein Rozel3rechnerBetriebssystem fti eine IBM/7 entwickelt, das auf komplexe Arbeitsweise mit hoher Erfassungsrate zugeschnitten ist. Mit Ausnahme der beiden schnellsten GerZte - Msssenspektrometer hochauflosend und GC-MSKopplung - die nicht gleichzeitig aktiv sein diirfen, kijnnen s%mtliche 63 Laborm&geriite simultan in Betrieb sein. Die maximal zu bewgtigende Prozel3datenrate betrZgXl2300 bzw. 13000 MeJ3werte s-l. Das Betriebssystem wurde so konfiiert, d& die reine Datenerfassung im Pollingverfahren mit Rioritiitstabelle. d.h. nach einem selbstsynchronisierenden Modus erfolgt, wobei auf zwei verscbiedenen Hardware-Levels der IBM/7 zwei getrennte, voneinander unabhiingige, gegeneinander asynchron

Messungder differcntiellen zusiitzlich zu 2: Mel3wcrtiiberLinenritiit eineg ADU-Eingo.nga nnhmo fiir GCGeriite bei selbstaynchronizierter Eetriebp w&e

Mausungder frelen CYWelt fiir VerwnltungeoufgabenIn hbhiingigkeit v! dor Intcrruptziihlrnto

8

4.

g

6

Mesdungder Lastgrcnze fir ext. hiterrupte

2

CPU~belnstung:64-0716

ElgObfliS

Meatiungder mnximalen Belaetbtikeit fir alle AD&

zusiitzlich zu 6: MeRwertiibcrnahme fii alle Geriite

FaetgrenzeLcval 0.ADU: 11,6 kHz (c 11,7 kHz) LastgrenzoLcval-l.ADU’s: > 400 ItHz (von der Geriitekonfiguration her zu erwartende maximale Bclastung: 200 Hz) --_____ _ _..

0% 0,92%

lntorrupt

33,4% 26,3% 17,6% 1.7%

10 kHz 12,G kHz 17 kliz 18 kHz

IObt

Idle Zeit Ziihlmto

h$en,ungder Laartseaze fir ext. zusiitzllch zu 9: Pufferverwaltung Interruptbelaetung ~.‘Intenupthunter EinacblufJvon Menwertiibertragungzur 1800. < 13,s kHz Pufferverwaltung und M&wcrttiber16kHi tregung zur 1800

wie 3

0% 0,07% 19,2%

lost interrupt

mittl. diff. Nichtlinenritlit 0,28% max, diff. Nichtli<~aritft 0,68% bei II.1,4% Vollnussteuorung

zusiitzlich zu 1: Intenuptcrkcn. Interruptbelastung nun& (keine Mcflwertbehondlung) c 17 kHz 20 kllz 26 l&z

Polling mit Prioritiit, SynchroModuln; Ausleaondes Digi. ttrlwerts uue ADU

3 ADU aynchron auf 2 Hordwnroloveln. CPU-lastd 66%

1

Konfiguration

Planziel

Test

Funktiona- und Auslastungs.Testswiihrend der PhtIS@ dcr flyetemontwicklung

TAUELLl!i 4

Entscheidung fiir Zntorrupterkonzuaiitziich zu G: ~oqu&tiolle tiungaroutino: Wiigevcrfahrcn ader Interrupt-Erkonnung s@quontiell mit Prioritiitszuordnung dcr Geriite

Beotimmung der CPU-h8erVe fiir zuaiitzlich zu 7: Verweltungeaufgnben auf nied. Hilfstoutino fiir Level 3 rigstom Level (Level a)

On line Test mit 2 schnellen Gcrii- zusiitzlich zu 7: Verwaltungston tm Level-O-ADU, zusiitzlich routinon ohne error-recovery 17 Gerlite an Level.l.ADU

7

I)

9

lost interrupts: 0

Lovel.O-ADU: 10 kHz * 0,2 kHz Level-l-ADU: 17 + 2 Hz Levol.3: 38 Vorwaltungsanfragen invgcsamt 700 000 Melltiertc in 08 8,

‘Interruptbel&tung: In,7 kHz CPUZcitreserve: en. 18%

1 kHz 0% 1,s ktfz 0% 2 kHz 0% 2,G kHz kcine Puffer mehr vcrfligbnr

Lcvcl&ADU: l&l kHz auf Bingang mit h~clletcr Ptioritiit Level-1-ADU: Eingnng mittlcrer Prioritlit Znhlriite lost interrupt --

betriebene Syncbronisieriingcn benutzt werden. Die Dateniibernabme,

die Pufferverwaltung sowie die ahgemeinen Verwaltungsaufgaben werden nach dem Anforderungsverfahren asynchron in die Synchronperioden der hIas&iue eingestreut bzw. auf e’mem eigenen Priorii%sIevel &gearbeitet. Dabei wurde sichergestellt, daS Geriite, die mit einer dem einen der beiden Synchrontakte Zhnlichen Frequenz oder deren Oberwellen laufen, asynchron in den anderen der beiden Synchrontakte eingespielt werden, so da13ein

Lastaufschaukeln und daraus resultierende Synchrrnverklenimu~ vermieden whd. Fiir die auf niedrigstem Hardware-Level abzuwickelnden aRgemeinen Verwaltungsaufgaben steht bei Maxima&& eine.mittlere CPU-Zeit-Reserve (idle time) von ca. 18% zur Verfiigung. Diese Reserve reicht aus, um das

Errorhandling und einen automatic-restart zu reahsieren. Dabei mul3 weitgehend auf das betriebssystemeigene error-fitidling venichtet werden, deqfeichen reicht die i&e-time nicht aus, standardmiif3ig komfortable Systemmeldungen iiber die System-Konsole auszugeben. Bei der Programmierung des error-hanciling wurde davon-ausgegangen, daf3 ein Fehler im “Zustiindigkeitsbereich” des Level-O-ADU (schnelle MeBgex%e) zu so groan Erfassungsverlustenfiibrt, daf3 ein automatisches Wiederstarten der Aniage nicht sinnvoil ist. Im Bereich des Level-l-ADU (GGGe.r%e) ist & automatiorestart vo&ei&aft wenn sichergestelit werden kann, daI3 mu wenige, h&b&ens drei Mef3werte’verloren gegangen sind. Dann wird den betroffenen Labors die Tatsache verlorener MeBwerte mitgeteilt, die Datenerfaswgeht jedoch weiter; das Labc auf3 also im Einzelfall selbst entscheiden, ob die mit “Aussetzem” bebaftete Messung verwendbar i.st oder wiederholt w Jrden mu& Das Betriebssystkm ist vollstZndig im Assembler programmiert, nur wenige Systemrnakros v&den benutzt. Die hohe Durchsatzleistung bei geringem Kemspeicherausbau (8K Werte) erfdrderte eine ausgekhigelte Progmmmierung, die erst nach umfangreichen Designarbeiten und Optimierungdiiufen durchgeftihrt wurde. Dabei ergab sich, da8 die fiinf zeitlichen Phasen (Vorarbeit,

Systemdesign, Programmierung, Optimierung und on line-Test) etwa gleich groS waren. Die Programmcodierung selbst erfolgte unter Time-Sharing am Grokechner. Durch die mit dem neuen Betriebssystem erreichbare hohe Erfassungsleistung ist eine weiter gesteigerte Durchsatzleistung in-den Labors zu erwarten. Dadurch steigt der Verwaltung&~and in den Labors sowie &n

Verwaltungsrechner IBM 1800. Es i.st deshalb eine Erwetierung dieser IBM 1800-Konfiguration geplant, die am Rechnek &Ibst einen Kernspeichetiusbau urn 8K, an der Rechnerperipherie eine 50% ige:Erhijhiing der Zahl der Laborterminals voisieht; Dadurch soil sich&gestellt~werden, daO der zu erwartende hijhere Analysendurchsatz von aen’ Lahor&iterSeitern such bewiiltigt werden kann, d-h. daC3SchIange-S&&en an den Terminals vkmieden wini. Eine ErhShung des Analysendurchsatzes urn den Faktor 13-2 scheint im Bereich des Mijghchen zu Beeen.

175

Die Autoren danken Herm E. Fahlbusch und Herm K.-H. Fouwet fiir deren Engagement in alien Phasen der Entwickhmg sowie den pertinlichen Einsatz m&end der TestGiufe. Der Dank gilt such den Mitarbeitem der bkoffenen lkboratorien. LITERATUR 1 H. Giinzler, Chem. Ing. Techn. 42 (1970) 877. 2 D. Mann und H. Riipcke, IBM-Nachr. 24 (1974) 308. 3 D. I-I&e, Hardwarenahe Elementarfunktionen der Ablaufsteuerung fti Prozel3rechner betriebssysteme, KFK-PDV 16. Geseliscbaft fiir Kernforsehung Karisruhe, 1973. 4 R. Werthmann, Entscheidungstabellengenerator (Systementwurf) KFK-PDV 3, Geseils&aft fi Kernforschung Karbrruhe, 1973. 5 W. Hinderer und W. Werum. Methoden rum Testen und Generieren von EchtxeitBetriebssystemen, KFK-PDV 64, Gesellschaft fi Kernforschung Karlsruhe, 1976. 6 hISPI Macro LibrJReloc., Processing macros, IBM GC 34-0008-5. 7 MSP/7 Macro LibrJRefoc., I/O macros, IBM GC 34-0020-3. 8 System/7 Macro Assembler. IBM GC-34-0018-3. 9 System17 Functional Ccaracteristics, IBM GC-34-0003-5.