Fachtagung Prozeßrechner 1981

Schlagzeilen wie „Mikroprozessor steuert Skibindung“ oder „Kochherd kennt 100 Rezepte“ erscheinen in zunehmender Zahl und machen deutlich, daß immer mehr Kleinstrechner (Mikrocomputer) zur Überwachung und Steuerung von technischen Geräten eingesetzt werden, die in sehr hoher Stückzahl gebaut werden: Die Massenanwendung von Kleinstprozeßrechnern ist also bereits Realität und wird in Zukunft mehr und mehr die Gestalt und Funktion von Gegenständen des täglichen Lebens bestimmen.

Es ist in der bildungspolitischen Geschichte der Ingenieurausbildung eine lange Tradition, daß die „Praxis“ Kritik an den Ausbildungsinhalten und -formen übt, die die Hochschule den angehenden Ingenieuren vermittelt.

Was haben Halbleitertechnologie und Prozeßtechnik miteinander zu tun? Nun, die Mikroelektronik hat als Innovationsauslöser weite Bereiche der Gerätetechnik beeinflußt, es besteht eine wechselseitige Abhängigkeit, die besonders in der Computertechnik zum Ausdruck kommt. Moderne Großcomputer wären ohne die heutige Halbleiter-Technologie überhaupt nicht denkbar und in gleicher Weise ist die heutige Halbleiter-Technologie von den prozeßbeeinflussenden Steuerungscomputern in einer Weise abhängig, daß ohne diese komplexe Halbleiter gar nicht hergestellt werden könnten. Ebenso wird der Fortschritt von Prozeßtechniken wiederum mit den Fortschritten auf dem Gebiet der Halbleiter-Technologien gekoppelt sein. Auch hier besteht eine starke Wechselbeziehung.

Es werden die folgenden 3 Fragen behandelt: 1. Mit welchen Verfahren kann man Prozeßautomatisierungssysteme mit Prozeß- bzw. Mikrorechnern zuverlässig und sicher machen? 2. Wie kann man die Zuverlässigkeit und Sicherheit bewerten bzw. nachweisen? 3. Wie kann man erreichen, daß Prozeßautomatisierungssysteme während ihrer gesamten Lebensdauer trotz Änderungen und Wartungseingriffen zuverlässig und sicher bleiben? Für die Zuverlässigkeits- und Sicherheitsverfahren wird dabei eine allgemeine Klassifizierung nach der Perfektions- und der Fehlertoleranz-Strategie eingeführt. Die besonderen Vorteile, die Spezifikationssprachen und Entwurfsunterstützende Systeme gerade bei zuverlässigkeits- und sicherheitsrelevanten Prozeßautomatisierungssystemen bieten, werden hervorgehoben und erläutert.

Es wird ein Test- und Entwicklungssystem vorgestellt, das den Entwurf, die Implementierung und schrittweise Verbesserung von Prozeßführungsprogrammen für dynamische Systeme unterstützt. Kernstück ist ein mehrstufiges Simulationskonzept, mit dem die Führungsprogramme schrittweise an die Ablaufbedingungen ihres real en Einsatzes heran- gefiihrt werden, zuletzt auf einer Zweirechneranlage, bei der ein Partner das technische System in Echtzeit simuliert. Damit lassen sich insbesondere zeitliche Engpässe, die durch das Echtzeitverhalten der Führungsprogramme, des Betriebssystems und der Prozeßrechnerhardware hervorgerufen sind, in ihren Auswirkungen auf das Regelverhalten frühzeitig erkennen und korrigieren. Das System wurde an mehreren Anwendungsbeispielen, unter anderem einer digitalen Tragregelung für eine Magnetschwebebahn, erprobt. In dieser Arbeit wird auch die allgemeinere, für Echtzeitanwendungen wichtige Frage der Simulationsgenauigkeit im Vergleich mit anderen Konzepten diskutiert.

Noch immer fehlen Mittel und Methoden, die es dem Software-Entwickler ermöglichen, ein Programmsystem so zu planen, zu spezifizieren und zu entwerfen, daß seine Annahmen, Folgerungen und Entscheidungen ihm selbst und anderen verständlich und prüfbar sind. Da von solchen Mitteln und Methoden, die nachfolgend einheitlich als „Spezifikationssysteme“ bezeichnet werden, eine wesentliche Verbesserung der Software-Qualität zu erwarten ist, wurde im IDT etwa seit 1976 auf diesem Gebiet gearbeitet. Zunächst wurde festgestellt, welche Spezifikationssysteme bisher verfügbar Oder vorgeschlagen sind (Ludewig, Streng, 1978) und eines davon installiert, das PSL/PSA-System vom ISDOS-Project an der University of Michigan (Teichroew, Hershey, 1977). Später wurde PCSL entwickelt (Process Control Software Specification Language, Ludewig, 1980a), eine Variante von PSL, die auf die Entwicklung von Prozeßrechner-Software zugeschnitten ist. SchlieBlich wurden die Konzepte von PCSL, die teilweise mit den durch die ISDOS-Software vorgegebenen Randbedingungen kollidierten, in ein völlig neues System eingebracht, das den Namen ESPRESO (System zur Erstellung der Spezifikation von Prozeßrechner-Software) erhielt (Ludewig, 1980c). Der folgenden Darstellung liegt diese am weitesten entwickelte Form zugrunde; die Unterschiede zwischen ESPRESO und PCSL sind in Abschnitt 9 skizziert.

Für die Projektierung und Entwicklung komplexer Automatisierungssysteme wird zur Unterstlitzung des Ingenieurs die Methode AMETHYST eingesetzt (Bild 1).

Ausgehend von einer Erläuterung der Grundprinzipien, die bei der Entwicklung des rechnergestützten Dokumentationssystems EPOS-D verwirklicht worden sind, werden zunächst die möglichen Dokumentationsarten und die verfügbaren Darstellungsmittel vorgestellt. Die Vorgehensweise bei der rechnergestützten Generierung von Dokumenten aus der EPOS-Datenbank wird anschließend erläutert, wobei auch auf die Realisierung des Dokumentationssystems EPOS-D eingegangen wird.

Die Formulierung dynamischer Abhängigkeiten zwischen parallelen Rechenprozessen bildet eine zentrale Komponente bei der Spezifikation des Entwurfs von Realzeitsystemen. Ausgehend von der Vorstellung der in EPOS für die Beschreibung der Synchronisierung zur Verfügung stehenden Ausdrucksmittel wird gezeigt, in welchem Umfang damit den Forderungen nach problemnaher Formulierung der gebräuchlichsten Synchronisierungsprobleme, nach Prüfbarkeit der Spezifikationen auf Synchronisierungseigenschaften, nach Anwendbarkeit durch Automatisierungsingenieure und Rechnerunterstützung bei Analyse, Dokumentation und Umsetzung entsprochen wird.

EPOS (Entwurfsunterstützendes Prozeß-Orientiertes Spezifikationssystem) ist ein Software-Werkzeug zur Unterstützung von Projektierung, Entwicklung, Dokumentation, Inbetriebnahme, Wartung und Handhabung von rechnergesteuerten Echtzeitsystemen [1], [2], [3]. Es beinhaltet die Sprachteile EPOS-R zur Beschreibung der Aufgabenstellung (Requirements) und EPOS-S zur Spezifikation des Hardware- und Softwareentwurfs.

Im folgenden wird über Aufgaben und Arbeitsweise eines Unterstützungsprogramms berichtet, das ein sequentielles Programm aufgrund einer Installationsbeschreibung in eine parallele Struktur gleichzeitig ablauffähiger Prozesse umwandelt. Diese Umwandlung geschieht durch Ergänzen der zur Parallelisierung und Kommunikation notwendigen Programmteile und wird unter besonderer Berücksichtigung der Installation der Programme auf einem Mehrrechnersystem durchgeführt.

In den letzten Jahren haben sich datenorientierte Entwurfsmethoden in vielen Anwendungsfällen durchgesetzt. Es sind lehrbare und praktisch anwendbare Methoden erarbeitet worden. Diese Methoden basieren stark auf Gedankengangen und Datenverstandnis der kommerziellen Datenverarbeitung.Untersuchungen und praktische Anwendungen bei der Erstellung von Prozeßrechner-Software haben gezeigt, daß der BEgriff der Datenstrukturierung fßr die Prozeßrechnertechnik erweitert und verallgemeinert warden kann. Damit können die Entwurfsmethoden auf Prozeßrechneraufgaben übertragen warden. Die dabei entstehenden Modelle für strukturierte Daten vertiefen das Verständnis fü die Struktur von PRozeßprogrammen.Die Methoden sind heute soweit entwickelt, daß sie Eingang in die Praxis finden können.

Seit etwa Juni 1980 ist die Implementierung des Software-Entwurfswerkzeugs B0IE auf der VAX 11/780 bei PSI abgeschlossen. Bereits vor diesem Zeitpunkt wurde BOIE firmenintern bekanntgemacht und von vielen Personen probeweise benutzt. Nachdem Bedienungsanleitungen für die einzelnen BOIE-Werkzeuge und ein Werkzeughandbuch zur Verfügung stehen und nachdem einige Trainingsseminare stattgefunden haben, beginnt nun der universelle Einsatz von BOIE in PDV-Projekten bei PSI.

In der Kernforschungsanlage Jülich befindet sich das Plasmafusionsexperiment TEXTOR in einer forgeschrittenen Aufbauphase. Am Beispiel der Steuerung und Datenverarbeitung für dieses Experiment sollen neuere Tendenzen in der Struktur und Organisation von Prozeßrechnersystemen aufgezeigt werden.

In der nuklearen Wiederaufarbeitungs-Versuchsanlage nahe Karlsruhe sind mehrere Wieder-aufarbeitungskampagnen erfolgreich durchgeführt worden /1/. Aufgrund des Mangels an aus-reichender In-line-Instrumentierung benötigt die Prozeßkontrolle einer Wiederaufarbeitungsanlage ein effizientes Analytisches Labor für die Bestimmung der Uran- und Plutoniumkonzentration, der Radioaktivitat und der Säure-Molarität. Durch die systematische Einführung eines Datenverarbeitungssystems ist — darauf weisen Erfahrungen der Wiederauf arbeitungsanlage in Barnwell hin /2/ — eine Erhohung der Zuverlassigkeit der Analysenergebnisse zu erwarten.

Die Forderungen der Prozefirechner-Anwender nach hoher Verfügbarkeit, kurzen Reparatur- und Wiedereinschaltzeiten, bei stark steigenden Einsatzstuckzahlen in neuen Märkten des Automatisierungs- und MDT-Bereiches, bedingen leistungsfahige Service- und Diagnoseeinrichtungen.

In dieser Arbeit wird ein Vorschlag zur Leistungssteigerung von Prozeßrechnern gemacht: Für den Ablauf des Betriebssystems wird ein zusätzlicher Prozessor vorgesehen, so daß der eigentliche Prozeßrechner fast völlig von Betriebssystemaufgaben befreit ist. Hieraus ergeben sich verschiedene Vorteile, insbesondere bezüglich des Antwortzeitverhaltens des Prozeßrechensystems. Es wird gezeigt, daß sich sowohl die Antwortzeiten von Tasks als auch die Reaktionszeiten auf Unterbrechungssignale verbessern; demgegenüber zeigt die Diskussion anderer Zwei-Prozessor-Konfigurationen, daß diese nur zu einer einseitigen Verbesserung der Taskantwortzeiten oder der Reaktionszeiten führen.

RADAR80 ist ein “Realzeitbetriebssystem auf Basis der ADA-Rendezvoustechnik. Es erschließt diese Technik für 8080/85 M ikroprozessoren; die ADA-Formen werden dabei auf PL/M abgebildet. Leistungen und Aufbau von RADAR80-Systemen werden beschrieben ; die wichtigsten Rendezvous-Dienste werden an Beispielen erläutert.

Zunehmend werden technische Systeme automatisiert, die strengen Sicherheitsanforderungen genügen müssen. Wesentliche Elemente der Automatisierung sind heute Prozeßrechner und vor allem Mikroprozessoren bzw. Mikrorechnersysteme. Daher werden dringend Methoden benötigt, die die Konstruktion nachweisbar sicherer und zuverlässiger Hardware/Software-Systeme ermöglichen.

Ein Verfahren zur Steiqerung der Softwarezuverlassigkeit besteht darin, diversitar zu programmieren, d. h. voneinander unabhangige Programme zu erstellen, die das gleiche Problem losen. Der Vergleich der Rechenergebnisse der einzelnen zueinander diversitaren Teile erlaubt es, wahrend des Programmeinsatzes auftretende Fehler zu erkennen.Die zur Problemlosung erforderlichen Strategien konnen sich z. B. auf die KontrollfluBstruktur, die Datenstruktur oder die verwendeten Algorithmen stützen.Bei der quantitativen Beurteilung der durch die Diversitat erzielten Zuverlässigkeitsgewinne geht man zweckmäßigerweise von den Programmei- genschaften aus. Man kann zeigen, daß sich gemeinsame Fehler in diversitaren Systemen hyper-geometrisch oder binomisch auf diese Eigenschaften verteilen. Hieraus lassen sich Wahrscheinlichkeiten, Erwartungswerte und Streuungen fur gemeinsame Fehler gewinnen.Weitere Berechnungen führen auf Wahrscheinlich-keitsaussagen für gemeinsames Versagen diversitarer Programme im Betrieb und auf die Verfügbarkeit eines diversitären Programmsystems. Auch bei Abmilderung der zunächst zu treffenden strengen Unabhängigkeitsvoraussetzung für die Programmerstellung kann man noch zu quantitativen Aussagen kommen.Der besondere Vorteil eines diversitären Programmsystems liegt in der relativ geringen Test-anzahl, die man brauchtr um bestimmte kleine Versagenswahrscheinlichkeiten pro Anforderung nachzuweisen. Bei Programmsystemen, die aus einer Mischung diversitärer und nicht diversitärer Teile bestehen, muß man die nicht diversitären Teile entweder mit Hilfe systematischer Verfahren verifizieren oder auf woanders gemachte Betriebserahrungen zurückgreifen.

Über die Entwicklung von Software für Systeme mit Sicherheitsverantwortung und über den zugehörigen Sicherheitsnachweis liegen noch wenig Erfahrungen vor. Deshalb werden zuerst allgemeine Lösungsmöglichkeiten vorgestellt und diskutiert. Über erste Erfahrungen beim Entwurf eines Systems mit zweikanaliger diversitärer Software/Hardwarestruktur wird anschließend berichtet. Entscheidungsgrundlagen werden erläutert, aufgetretene Probleme diskutiert und das Konzept für den Sicherheitsnachweis vorgestellt.

Datenflußuntersuchungen in Programmen sind wichtige Hilfsmittel zur Fehlerauffindung und bei der Begutachtung von Programmen. Im folgenden Beitrag wird zunächst kurz die prinzipielle Vorgehensweise zu Datenflußuntersuchungen geschildert. Danach wird anhand mehrerer Ausgaben gezeigt, wie der Datenfluß in PEARL- Moduln durch ein Testwerkzeug automatisch dargestellt werden kann. Bei der Gesellschaft für Reaktorsicherheit wird gegenwärtig ein solches Test- Werkzeug, der PEARL- Analysator, entwickelt.

Bei der Steuerung und Regelung von Prozessen werden heute in großem Umfang Rechner eingesetzt. Dieser Trend hat sich durch die Fortschritte der Mikroprozessortechnik noch verstärkt.

Seit einem Jahrzehnt wird der Einsatz von Prozeßrechnern für Sicherheitsaufgaben in Kernkraftwerken diskutiert. Eine ganze Reihe von Systemen ist mittlerweile realisiert. Trotzdem besteht auch heute bei der Projektierung noch häufig eine große Unsicherheit darüber, ob für das in Angriff genommene System der Sicherheitsnachweis erbracht werden kann. Diese Unsicherheit rührt zumindest für die Kern- technik — wie z.B. Diskussionen auf der 2. Fachtagung 1977 in Augsburg deutlich zeigten — mit daher, daB die Reaktorschutzrechner für die Kernkraftwerke Brunsbüttel und Philippsburg nicht zum closed loop Einsatz kamen.

In modernen Prozeßführungssystemen hat sich der Einsatz dezentraler Intelligenz zur Entlastung der Zentralrechner bewährt. Bei BBC wurde ein MMK-Konzept entwickelt, das es erlaubt, bereits in der Phase vor der Systemintegration alle intelligenten Systemkomponenten „Standalone“ zu spezifischen Projektierungsaufgaben unabhängig voneinander heranzuziehen (Bildaufbau, Konstanteneingabe, Dialogdefinition).

Im Produktionsbereich sind Terminal-Dialogsysteme mit Prozeßrechner seit etwa 10 Jahren im Einsatz. Dabei ist in den letzten 2–3 Jahren ein über proportionaler Anstieg der Anwendungen zu verzeichnen.

This paper deals with the development of systems assisting the operators in nuclear power plants in diagnosing disturbances. The systems described are process-computer-based and provide an efficient tool for on-line disturbance analysis. It is also discussed which measures from the plant may best be selected to yield a good quality of information conveyed to the operators by these systems. The selection criteria are also used as a basis of quantitative assessment of the improvement of operator diagnosis of plant disturbances. A layout of experiments to be carried out to obtain empirical data on operator capabilities of plant diagnosis, where plant simulators are used, are also described.

Ausgehend vom Einsatz eines graphischen Systems (GMB300) bei Prozeßautomatisierung wird über die dabei gewonnene Erfahrung berichtet: welche Änderungen und Ergänzungen z.B. aufgrund des Prozeßbetriebes notwendig waren.Anschließend wird als zukünftig zu verwendendes System das Graphische Kernsystem (DIN-Normungsvorschlag für graphische Systeme) betrachtet und die Verwendbarkeit, die notwendigen Erweiterungen bzw. Möglichkeiten diskutiert.

Die Einsatzmoöglichkeiten grafischer Systeme sind außerordentlich vieifältig. Sie reichen von der einfachen Balkendarstellung auf herkömmlichen s/w-Terminals (etwa im kaufmännischen Bereich) über schematisierte Anlagendarstellungen auf semigrafischen Farbsichtsystemen (z. B. im Prozeßbereich) bis hin zu volIgrafischen Systemen im Bereich von CAD. Wir wollen uns hier auf den Prozeßbereich beschränken.

Durch den zunehmenden Einsatz der Automatisierungstechnik, insbesondere der Prozeßrechner, haben sich die Arbeitsaufgaben, Arbeitsanforderungen und Arbeitsbedingungen der betroffenen Beschäftigten verändert.

Der Übergang zu höheren Blockleistungen und Übertragungsspannungen im Bereich der elektrischen Energieversorgung führt zu einer zunehmenden Zentralisierung der leittechnischen Aufgaben. Unterstützt wird diese Entwicklungsrichtung durch die Notwendigkeit bestehende Anlagen mehr und mehr auszulasten, da der Neu- und Ausbau auf der anlagentechnischen Seite nicht immer entsprechend den Erfordernissen des Bedarfes durchgeführt werden kann. Fur die Zentralisierung der leittechnischen Aufgaben spricht die damit verbundene vollständige Übersicht über das Betriebs- geschehen. Allerdings ist dabei eine Reihe technischer Probleme zu beachten, die zu einem Kompromiß zwischen zentraler und dezentraler Leittechnik führen. Da es sich bei einem elektrischen Energieversorgungsunternehmen normalerweise um ein geographisch sehr ausgedehntes System handelt, müssen bei einer rein zentralen Leittechnik sehr viele Daten über z.T. große Distanzen übertragen werden, bevor sie am zentralen Rechner verarbeitet und angezeigt werden. Die Anforderungen sowohl an das Informations-Übertragungssystem als auch an die Größe des zentralen Rechners machen deutlich, daß nur soviel Information an den zentralen Rechner übermittelt werden soil als zur Lösung zentraler Aufgaben unbe- dingt erforderlich ist. Auf diese Weise kommt man zu einem hierarchisch gegliederten Leitsystem, das in Abschnitt 2 dargestellt wird.

Als Betriebsleitsystem wird im öffentlichen Personenverkehr ein Informationssystem bezeichnet, das dem Betreiber der Stadtbahn, Straßenbahn oder der Omnibusse einen vollständigen und genauen Uberblick über den Betriebszustand gibt und ihm damit erlaubt, kurzfristig dispositiv oder langerfristig planend sein Verkehrsangebot qualitativ zu verbessern und den Einsatz der Verkehrsmittel zu optimieren.

Der Betrieb eines Fernsprechnetzes erfordert die Erfassung der Gesprächsgebühren sowie die routinemäßige Funktionsprüfung der Vermittlungseinrichtungen und Übertragungsstrecken. Im folgenden wird gezeigt, wie diese Aufgaben in einem diensteintegrierenden Breitbandnachrichtennetz mit dezentraler Vermittlungsstruktur gelöst werden konnen. Die angegebene Lösung wurde im Rahmen eines Experimental systems des Heinrich-Hertz-Instituts Berlin „Breitbandkommunikation mit optischen Kanälen“ in Zusammenarbeit mit Siemens E STE 241 realisiert.

Die Kernforschungsanlage Jülich GmbH (KFA) ist eine vom Bund und vom Land NRW getragene Großforschungseinrichtung mit ca. 4400 Mitarbeitern; davon sind annähemd 850 Wissenschaftler. Von der KFA wird ein thematisch weit gefächertes Forschungsprogramm in mehr als 25 Instituten und anderen Organisationseinheiten durchgeführt.

Die Aufgabenstellungen fur Datenverarbeitungssysteme werden komplexer durch zunehmende Interaktion von Einzelaufgaben mitFunktions- und Datenkopplung über größere Entfernungen undortsunabh%#x00E4;ngigem Datenzugriff.

Für Echtzeitanwendungen in Bord- und Geräterechnern, in Führungssystemen und komplexen Waffensystemen zeichnet sich immer stärker ein Trend zu verteilten Systemen ab, worin jeder Rechner bestimmte Aufgaben über nimmt und mit den anderen Rechnern kommuniziert. Bei Dornier System wurden verteilte Systeme von Mikroprozessoren und Prozeßrechnern konzipiert, die lose miteinander gekoppelt sind, die also keinen intensiven Datenaustausch benötigen. Dies ist möglich, wenn jeder Rechner einen genau definierten und abgegrenzten Aufgabenbereich hat („dedicated systems“). Aus den bei Dornier System anstehenden Aufgaben heraus mußten dabei die wichtingsten Anforderungen hohe Laufzeiteffizienzminimaler Speicherbedarfleichte Programmierbarkeit

Es wird der Aufbau eines einfachen Basic-PEARL-Systems beschrieben, welches seit Anfang 1980 im Einsatz ist. Es ist speziell für die Programmentwicklung auf ausgesprochenen Kleinstkonfigurationen zugeschnitten. Durch vollständig virtuelle Befehlscodierung des Compilers und einen halbvirtuellen Laufzeitcode ergeben sich eine Reihe von Vorteilen. Besonderes Augenmerk wurde auf einen späteren Einsatz in Mikrocomputern gelegt.

Bei der Erstellung von Software für Microcomputer tendiert man auch bei Echtzeitanwendungen dahin, weg von den Assemblersprachen hin zu höheren Programmiersprachen zu kommen. In der vorliegenden Arbeit wird ein von Dornier System entwickeltes PEARL-Softwaresystem beschrieben, das für zwei Zielrechner (Dornier MUDAS 432 und AEG 80–20) bereits implementiert wurde und für Anwendungen eingesetzt wird.Es werden die einzelnen Teile des Softwaresystems beschrieben und deren Aufgaben erklärt. Weiter werden die Testmoglichkeiten aufgezeigt, die dem Benutzer zur Verfiigung stehen. Zum SchluB wird noch auf die Implementation eingegangen und es werden Erfahrungswerte aus der praktischen Anwendung genannt.

Die System-Sprache META-S ist im Zeitraum 1978/79 in unserem Hause entstanden. Die Entwicklung verlief parallel und koordiniert zu der Entwicklung unserer neuen RechnerIinie EPR 1300/1500.

Auch in der Prozeßrechnertechnik ist der Einsatz höherer Programmiersprachen sinnvoll und notwendig, dies steht angesichts der zunehmenden Verlagerung der Kosten von der Hardware auf die Software außer Frage. Um einen effecktiven Einsatz von höheren Programmiersprachen zu erlauben, sollten aber vor allem die Test- und Diagnosehilfen für den Programmierer auf einer möglichst hohen Ebene zur Verfügung stehen. Hier liegen im wesentlichen Nachteile der üblichen Rechnerarchitekturen, die auf konventionellen Maschinensprachbefehlen aufbauen.

Das Datenbanksystem BAPAS-DB organisiert den Zugriff konkurrierender (Rechen-) Prozesse und Dialogbenutzer auf Datenbestände. Durch seine Programmierung in PEARL ist BAPAS-DB unabhängig von einem konkreten Rechner. Es kann auf jeden PEARL-Rechner genügend hohen Sprachniveaus transportiert werden.Das Datenbanksystem ist offen für die schnittstellenneutrale Änderung, Auswechslung oder Hinzunahme von Zugriffstrategien und die Anpassung der Benutzerschnittstelle entsprechend einer gewünschten Anwendersprache.

Bei der Kombination der Aufgaben prozeßnahe Datenerfassung und gleichzeitige kommerzielle Verarbeitung der erfaßten Daten, erweisen sich weder Datenbanksysteme noch die herkömmlichen Datenverwaltungssysteme als geeignet. Diese Ausgangssituation führte zur Neuentwicklung des Daten-verwaltungssystems DVS 300. Die Konzeption und die Struktur dieses Systems werden im folgenden bezüglich Zugriffsmöglichkeiten, Transferoptimierung, Datensicherungsmöglichkeiten und Systemarchitektur vorgestellt.

Der Einsatz von Datenbanken im Bereich der Automatisierung technischer Prozesse mit Prozeßrechnern steht erst am Anfang der Entwicklung. An fortgeschrittene Automatisierungssysteme wird heute die Forderung gestellt, unterstützendes System für das gesamte Spektrum von der Planung bis zur Wartung einer Prozeßanlage zu sein. Als Lösung bietet sich eine Datenbasis auf dem Konzept relationaler Datenbanken an, da einerseits die Prozeßdatenstrukturen in sichtgeräte-orientierten Warten- und Leitstandsystemen komplex und umfangreich sind, andererseits fast ausschließlich Zugriffe zu den Datenstrukturen über den Signalnamen als Primärschlüssel vorkommen. Für den interaktiven Zugang zur Datenbank wird eine lichtgriffelgestützte Anfrage- und Manipulationssprache vorgestellt, die Projektierungsingenieuren und Wartenpersonal gleichermaßen Zugang zur Datenbank erlaubt. Um echtzeitbezogene Zugriffszeiten von Programmen zu gewährleisten, sind besondere Maßnahmen zur schnellen Adressierung der gespeicherten Daten notwendig.Die Realisierung einer relationalen Prozeßdatenbank in PEARL, verbunden mit einer tabellengesteuerten Anfragesprache für den Entwurfs- und ProgrammierungsprozeB von Pro- zeBrechnern, zeigt die Anwendungsbreite von PEARL und auch Wege zur Rationalisierung des Entwurfs- und Programmierungsprozesses für Prozeßrechner mit MSR-Standardaufgaben.