Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.07.1975

Die schwache Seite der Prozeßrechner

Prof. Dr.-lng. Rudolf Lauber Direktor des Instituts für Regelungstechnik und Prozeßautomatisierung der Universität Stuttgart

Der Prozeßrechner als modernes Hilfsmittel der Automatisierung hat trotz seiner noch jungen Geschichte schon eine Reihe von "Generationen" hinter sich. Dabei hat er sich stark vermehrt. Er ist in die verschiedensten Anwendungsbereiche vorgedrungen: Bei der Automatisierung der Keksfertigung ist er ebenso zu finden wie bei der optimalen Steuerung von Klärwerken. Auch haben sich vielerlei Arten herausgebildet: Das Spektrum der angebotenen Anlagen reicht heute von Mikro- über Mini-Computer bis hin zu "Maxi-Prozeßrechnern", die in ihrer Rechenleistung den Großrechnern in den Rechenzentren nur noch wenig nachstehen.

Ein Ende der schnellen Weiterentwicklung ist noch nicht in Sicht. Der Trend zum noch kleineren, noch billigeren und trotzdem noch leistungsfähigeren Prozeßrechner hält unvermindert an. Dieser Trend wird dazu führen, daß flexible, hochverfügbare dezentrale Prozeßrechensysteme schon bald die heutige Generation von zentral strukturierten Prozeßrechnern ablösen werden. Andererseits ist abzusehen, daß die sogenannten Mini-Computer (bei denen der Ausdruck "Mini" nur noch bezüglich des Volumens und des Preises gerechtfertigt ist) so leistungsstark werden, daß sie ihren großen Brüdern aus dem Lager der kommerziellen EDV Konkurrenz zu machen drohen.

Das bisher geschilderte Bild vom unaufhaltsam zu weiteren Erfolgen voranschreitenden Prozeßrechner verliert allerdings viel von seiner Leuchtkraft, wenn man nicht nur auf die Gerätetechnik, sondern auch auf die Software-Entwicklung blickt. Ernüchtert stellt man fest, daß es sich bei den Prozeßrechnern offenbar um Halbstarke mit kraftstrotzender Hardware und unterentwickelter Software handelt. Darüber kann auch die hochtrabende Ausdrucksweise der sogenannten Software-Experten (die sich vornehmlich durch eine möglichst häufige Verwendung von Worten wie "System" und "Prozeß" auszeichnen) nicht hinwegtäuschen.

Die Schwäche, ja Rückständigkeit der Prozeßrechner-Software wird bei einem Vergleich mit den Rechenanlagen für technisch-wissenschaftliche und kommerzielle Anwendungen deutlich. Die Benutzung anwenderfreundlicher und portabler höherer Programmiersprachen ist dort längst eine Selbstverständlichkeit. Nicht so bei Prozeßrechnern: Hier wird in aller Regel noch wie eh und je in Assemblersprachen programmiert. Zwangsläufig ergibt sich daraus ein zweistufiges, schwerfälliges Vorgehen bei der Erstellung von Automatisierungssystemen: In einer ersten Stufe führen Ingenieure - oft in diesem Zusammenhang etwas herablassend als die "Technologen" bezeichnet - eine Systemanalyse durch und legen die Automatisierungsverfahren aus. In einer zweiten Stufe setzt dann ein erfahrenes Programmierer-Team (aus einer Software-Abteilung des Herstellerwerks oder aus einer Software-Firma kommend) die Automatisierungsverfahren in Assemblerprogramme für den Prozeßrechner um. Über hohe Kosten, lange Entwicklungszeiten und viel Ärger bei der Inbetriebnahme und dem späteren Betrieb braucht man sich dann bei einem so umständlichen Verfahren nicht zu wundern.

Natürlich hat es nicht an Versuchen gefehlt, diese Schwäche des Prozeßrechners mit geeigneten Heilmitteln zu kurieren. Die von einigen Herstellern für ihre jeweiligen Rechner und Betriebssysteme propagierten REAL-TIME-FORTRAN's und REAL-TIME-BASIC's erwiesen sich als wenig wirkungsvoll. Auch den Sprachen wie CORAL 66 und POLYP, bei denen die Schwierigkeit der Echtzeit-Sprachelemente von vornherein ausgeklammert wurde, blieb ein Heilungserfolg versagt.

Ein grundlegender Wandel scheint sich erst jetzt mit ganz neuen Sprachentwürfen abzuzeichnen. Die zur Formulierung algorithmischer Zusammenhänge erforderlichen Sprachmittel (die zum Beispiel aus vorhandenen höheren Programmiersprachen entnommen werden können) werden bei diesen Entwürfen mit Sprachelementen für die Echtzeitprogrammierung vereinigt. Große Erwartungen werden vor allem in die Prozeßprogrammiersprache PEARL gesetzt, die in Deutschland entwickelt wurde und deren Implementierung, Erprobung und Einsatz auf mehr als 10 Prozeßrechnertypen vom Bundesministerium für Forschung und Technologie im Rahmen des PDV-Projekts gefördert wird. Die ersten Ergebnisse zeigen, daß mit dieser Sprache tatsächlich ein "einstufiges" Vorgehen bei der Erstellung von Automatisierungssystemen möglich wird: Die "Technologen" sind damit in der Lage, ihre Automatisierungsverfahren selbst (ohne Zuhilfenahme von Programmierexperten) in lauffähige Prozeßrechnerprogramme umzusetzen.

Ein zu lauter Jubel wäre jedoch verfrüht, da die echte Bewährungsprobe erst noch bevorsteht. Vor allem aber muß gewährleistet sein, daß die für ein Automatisierungsprojekt erstellten PEARL-Programme auch portabel, das heißt auf andere Rechner übertragbar sind. Aus der Geschichte der Programmiersprachen kennt man die Gefahr, daß es durch die Eigenwilligkeit der Entwickler schnell zu Dialekt-Bildungen und schließlich zu einer babylonischen Sprachverwirrung kommen kann. Dies gilt um so mehr bei einer Echtzeitsprache, für die nicht nur ein Compiler, sondern auch ein sprachorientiertes Betriebssystem erforderlich ist.

Wenn es nicht gelingt, diese Gefahr bei PEARL zu meistern, sind alle Hoffnungen und alle Förderungsmittel vergebens. Hier ist schnelles und energisches Handeln aller Verantwortlicher geboten.