Prozeßrechner 1984

Vor etwa 25 Jahren wurde damit begonnen, Rechner mit Sensoren und Stellgliedern zu koppeln und sie unter Realzeit-Bedingungen einzusetzen. War die erste Phase der rechnergestützten Automatisierungstechnik durch große zentrale Prozeßrechneranlagen mit teilweise riesigen „Verkabelungssternen“ gekennzeichnet,setzen sich heute - der räumlichen und funktionellen Struktur der zu automatisierenden technischen Prozesse angepaßt - dezentrale, verteilte Prozeßrechensysteme durch, bei denen besonders in den Feldfunktionen direkt am Prozeß die Mikrorechner dominieren. Realzeitsysteme hatten seit Anbeginn überdurchschnittliche Softwarekomplexitäts- und -Zuverlässigkeitsprobleme. Trotz erheblicher Fortschritte bei den Realzeit-Betriebssystemen, den Anwenderprogrammsystemen für Automatisierungsaufgaben, den phasenintegrierenden systematischen Entwurfssystemen der „Realzeit“-Softwaretechnologien und den Realzeit-Sprachen sind weiter erhebliche Anstrengungen der Softwaretechnik für Prozeßrechensysteme erforderlich.Die besonders durch die Mikroelektronik und neuen Nachrichtenübertra-gungstechniken forcierte integrierte Informationstechnik und die steigende Bedeutung der Informatik werden auch zukünftig die Automatisierungstechnik unter starken Wandlungsdruck setzen.Beispiele sind: einheitliche Kommunikationstechnologien (ISO-OSI-Schichtenmodell) innerbetrieblich und überörtlich; Verbesserung der Mensch-Automatisierungssystem-Schnittstelle auch unter Einbeziehung von Verfahren der Künstlichen Intelligenz und die Verteilung von Datenbeständen auf viele - auch Arbeitsplatz- - Rechner.

Die Architektur zukünftiger Prozeßrechnersysteme wird bestimmt durch technologische Basisentwicklungen, welche die Realisierung weitgehend dezentraler Systemstrukturen begünstigen. Hierarchien von Bus-Systemen dienen als Kommunikations-Infrastruktur, Verarbeitungsmoduln wirken als Träger der immer besser standardisierbaren Prozeßautomatisierungsfunktionen. Die Systemsoftware unterstützt die Verteilung solcher Funktionen auf die Verarbeitungsmoduln sowohl bei der Projektierung als auch bei der Ausführung.

The paper describes current status and future trends of the technologies which have been applied to the process control systems, process computers and peripheral devices of Japan.

Leistungsfähige Informationssysteme sind als unerläßliche Hilfsmittel für Wirtschaft und Verwaltung seit langem im praktischen Einsatz /18/. In jüngster Zeit ergeben sich verstärkt Möglichkeiten, sie auch im technischen Bereich - Produktion, Labor und Infrastruktur - zu nutzen. Während in der fertigungstechnischen Industrie mit ihren stückorientierten und arbeitsteiligen Abläufen die Steuerung der Produktionsprozesse und der Einsatz von Robotern weit entwickelt ist, sind di∈ Systeme zur Unterstützung verfahrenstechnischer Abläufe zwar in rascher Entwicklung, aber ihre Komplexität erfordert auch heute noch einen hohen Entwicklungsaufwand.

Die Software-Erstellung hat in den ca. 25 Jahren ihrer Entwicklung den Wandel von der „Kunst“ weniger Spezialisten zu einer neuen Ingenieurdisziplin erfahren. In Anlehnung an andere bewährte Verfahrenstechniken ist eine Software-Erstellung nach industriellen Maßstäben gekennzeichnet durch Zerlegung in Arbeitsschritte und deren Abgrenzung durch Dokumente, arbeitsteilige Organisation, rechnergestützte durchgängige Methoden und Werkzeuge sowie Mehrfachverwendung von Softwarebausteinen durch konsequente Standardisierung.Im Vortrag wird über die Prinzipien einer derartigen Softwaretechnik sowie über das mit ihrer Einführung verbundene Akzeptanzproblem berichtet. Darüber hinaus wird ein Ausblick auf die zu erwartenden Einflüsse der zukünftigen verteilten Rechnersysteme und der künstlichen Intelligenz (KI) auf die Softwaretechnik gegeben.

Es werden Erfahrungen beim Einsatz von Softwaretechnologiemethoden bei der Entwicklung eines großen Realzeitsystems dargelegt. Betrachtet werden Kriterien zur Auswahl von Methoden und Werkzeugen, die Verwendung eines Phasenmodells, Softwarearbeitsplätze und eine rechnergestützte Projektbibliothek, sowie der projektspezifische Zuschnitt von Methoden und Werkzeugen für die verschiedenen Projektphasen.

In zunehmendem Maße werden den mit Entwicklung und Einsatz von Software verbundenen Kosten Beachtung geschenkt. Dabei zeigt sich, daß neben den Entwicklungskosten eines Projektes vor allem die Aufwendungen, die während des Produkteinsatzes z. B. durch Nachbesserungen, Fehlerbehebungen entstehen, starken Einfluß auf die Gesamtkosten haben. Diese „Maintenance-Kosten“, die wesentlich durch die Qualität des Produktes bestimmt werden, erreichen nicht selten die Größenordnung der Entwicklungskosten. Deshalb erhält Qualitätssicherung während der Produktentwicklung einen besonderen Stellenwert.Der Vortrag erläutert anhand eines realisierten Projekts auf dem Gebiet der Systemsoftware, wie mit relativ einfachen Mitteln qualitätssichernde Maßnahmen durchgeführt werden können, und gibt Erfahrungen wieder.

Nach einer Einführung in das Einsatzgebiet der Anwendersoftware, die zum Teil durch Sicherheitsverantwortung des Softwaresystems gekennzeichnet ist, werden die Softwareentwicklung und das Testverfahren erläutert. Der Test von Programmen geschieht zur Zeit halbautomatisch. Aufgrund von Testblättern werden Kommandofiles erstellt, mit denen ein Testhilfeprogramm versorgt wird. Es werden Wege aufgezeigt, wie der bisher manuell durchgeführte Ergebnisvergleich ebenfalls automatisiert werden kann.

Durchgängige Verfahrenstechnik, Wieder Verwendbarkeit von Produkten, Normierung von Schnittstellen und qualitätssichernden Maßnahmen sind in der industriellen Welt eine Notwendigkeit - und eine Selbstverständlichkeit. Die industrielle, ingenieurmäßige Erstellung von Software zeigt heute noch einen deutlichen Nachholbedarf gegenüber etablierten Disziplinen. Diese Lücke zu schließen ist ein besonderes Anliegen der Software-Ersteller, um marktgerecht und konkurrenzfähig zu bleiben. Wesentliche Aspekte sind zum einen die Wiederverwendung durch Standardisierung sowohl der Software-Schnittstellen als auch der Kommunikationsprotokolle - und zum anderen die Bereitstellung von Dienstleistungen für den Anwender. Im Vortrag wird über realisierte Lösungen sowie über deren Auswirkungen auf den Erstellungsprozeß berichtet.

Ziel der Phase Anforderungsdefinition ist die Ermittlung der Fähigkeiten eines geplanten DV-Systems und deren Dokumentation in einem Pflichtenheft. Anhand eines konkreten Beispiels wird eine Methodik zur Erstellung des Pflichtenheftes für interaktive Prozeßinformationssysteme vorgestellt. Es besteht aus der Beschreibung der betrieblichen Abläufe, dem Entwurf eines konzeptuellen Datenbank-Schemas unter Verwendung des Entity-Relationship Modells und der Spezifikation der AnwenderSchnittstellen (Dialoge zur Durchführung technischer Prozesse, Anfragen, Berichte) mittels sogenannter Transaktionen. Ausgehend von den hiermit gemachten Erfahrungen wird auf Möglichkeiten zur rechnergestützten Erstellung und Wartung eines Pflichtenheftes eingegangen.

Bei vielen Projekten ist man bestrebt, Maßnahmen und Methoden zur Entwicklung und Inbetriebnahme von Software aufeinander abzustimmen. Für Software-Produkte mit langer Lebenszeit ist es darüber hinaus erforder1 ich, die Inbetriebhaltung durch eine Bestandsplege zu sichern. Auf der Basis eines Produkt-Modells können Merkmale zur Bestandspflege erläutert werden.Als Unterstützungshilfsmittel zur Entwicklung und Pflege von Software wird die Projekt-Dateien-Methode vorgestellt. Diese Methode hat sich als nützlich herausgestellt bei der Bearbeitung von Aufgaben in verschiedenen realen Umgebungen, gegeben durch Prozeßrechner und Mikroprozessor-Entwicklungssysteme. Sie wird in diesem Beitrag zusammen mit der Auswirkung von Werkzeugen vorgestellt. Ergebnisse von Methode und Werkzeugen werden an einem Software-Produkt mit langer Lebenszeit und einem Produkt mittleren Umfangs erläutert.

Die Führung von elektrischen Verteilnetzen erfordert ein Realtimeprozessleitsystem mit hoher Verfügbarkeit. Die unterschiedlichen Ausprägungen der jeweiligen Betriebs- philisophie erfordern große Variabilität in der Zusammenstellung der einzelnen Softwareelemente. Um diese Problemstellung in einem allgemeinen Ansatz zu lösen, ist ein modulares Softwaresystem entwickelt worden, das auf zwei Hardwareebenen (Vorrechner, Leitrechner) aufsetzt, die jeweils als redundante Doppelrechner aufgebaut sind.Die wesentlichen Module des Gesamtsystems sind: Prozeßanschaltungssoftware im VorrechnerMensch-Maschine-KommunikationBasisverarbeitungen für die verschiedenen Informationsarten des unterlagerten Fernwirknetzes (Meßwerte, Meldungen etc.)Weiterführende EVU-spezifische Verarbeitungselemente (Tarifumschaltungsprozesse etc.)Erweiterte Hilfsmittel für den Operator der WarteHöhere energieoptimierende Software.Alle diese Module sind frei miteinander kombinierbar. Jedes Modul ist in einem grossen, aber definierten Rahmen projektierbar. Die Module sind über monitor-ähnliche Systemstrukturen an die unterlegten Betriebssysteme angekoppelt; auf dem Leitrechner ist die Datenverwaltung auf einer an die Realtimeanforderungen angepaßten Datenbank aufgesetzt.

In hochverfügbaren Prozeßleitsystemen werden heute in der Regel mehrere Rechnerebenen eingesetzt. Alle Rechnerebenen sind normalerweise hardwaremäßig mit Redundanz in Form von Stand-by Prozessoren ausgestattet. Zum Betrieb eines solchen Rechnersystems sind einige systemnahe Programme erforderlich, die je nach Hardwarehersteller auch schon teilweise als Standardsoftware angeboten werden. Der folgende Beitrag beschäftigt sich anhand eines konkreten Projektbeispiels mit der erforderlichen Rechnernetzsoftware. Dabei wird schwerpunktmäßig auf die Themen Kommunikation, Überwachung und Konfiguration eingegangen.

Automatisierungssysteme mit Sicherheitsverantwortung werden heute in Mikroprozessortechnik aufgebaut. Wegen der komplexeren Struktur dieser Systeme wachsen auch die Anforderungen an die sicherheitstechnische Zuverlässigkeit. Einzelfehler in den Systemen dürfen nicht zu gefährlichen Fehlfunktionen führen. Nahezu beliebige Fehler müssen dabei ohne Betrachtung der jeweiligen Eintrittwahrscheinlichkeit unterstellt werden. Es ist erforderlich, Fehler schnell zu erkennen und im sicherheitstechnischen Sinne zu beherrschen. Die klassische Methode der Fail-safe-Technik führt zum sicherheitsgerichteten Abschalten. Soll die Überreaktion solcher Systemlösungen vermieden werden, so muß zu einem höheren Redundanzgrad übergegangen werden. Fehler müssen so toleriert werden, daß auch mit, einem vorhandenen Systemfehler die notwendigen sicherheitstechnischen Anforderungen erfüllt werden können.

Bei Systemen, deren undefinierter Ausfall Personen- oder hohe Sachschäden verursachen kann, wie z. B. Steuerungen von Schienenfahrzeugen, ist ein fail-safe-Verhalten gefordert. Bei Verwendung von Rechnern mit undefiniertem Ausfallverhalten bedeutet dies, dass das ordnungsgemässe Arbeiten durch Vergleich der Verarbeitungsergebnisse redundanter Rechneranordnungen überprüft werden muss.Als Lösung für den Vergleicher bietet sich, insbesondere bei Mikrorechnern, zwei Möglichkeiten an: Vergleich durch rechnerexternen VergleicherGegenseitiges Einlesen der Ergebnisse und rechnerinterner Vergleich.Die beiden Möglichkeiten werden vorgestellt und ihre Vor- und Nachteile werden erläutert. Weiterhin wird die Möglichkeit der Erweiterung zu hochzuverlässigen und sicheren Systemen diskutiert.

Dieser Beitrag berichtet über die industrielle Entwicklungstechnik sicherheitsverantwortlicher Prozessautomatisierungs - Software aus dem Bereich der Eisenbahn-Signaltechnik. Nach einem kurzen Überblick über die technischen Besonderheiten dieses Bereiches werden folgende Punkte behandelt: a)Welche Methoden werden bei der Herstellung der Software verwendet, um Fehler von vorneherein zu verhindern?b)Welche Methoden werden verwendet, um doch entstandene Fehler zu offenbaren?c)Wie erfolgt der Funktionsnachweis und dessen Prüfung durch eine Abnahmeinstanz?Das geschilderte Vorgehen resultiert aus mehrjährigen Erfahrungen der Firma SEL. Die Grundprinzipien wurden ausserdem durch die Deutsche Bundesbahn genormt und stellen insofern einen allg. Industriestandard dar /2/.

Es werden die Anforderungen an ein fehlertolerantes sicheres Rechnersystem und deren Realisierung beschrieben. Speziell wird die Funktionsweise und das Arbeitsprinzip dargestellt und die sich daraus ergebenden Möglichkeiten bezüglich des fehlertoleranten Verhaltens bei Störungen und Ausfällen.

Das Konzept und die Realisierung des Experimentdatenerfassungs- und Analysesystems EDAS wird beschrieben. In diesem System sind Experimentrechner und zentrale Großrechner integriert. Auf diese Weise können flexibel Rechen- und Speicherkapazitäten für die anfallenden Datenmengen aus kernphysikalischen Experimenten am UNILAC zur Verfügung gestellt werden.

Im Beitrag wird eine Überwachungseinrichtung für die große Windenergieanlage GROWIAN dargestellt. Drei Rechner, der im Rotor mitdrehende Rotorrechner, ein Maschinenhaus-rechner an der Turmspitze und ein Rechner im Betriebsgebäude am Turmfuß dienen zur Meßdatenerfassung und -Verarbeitung. Die Einrichtung liefert im Falle von Grenzwertverletzungen Alarme und Abschaltsignale.Da es sich bei GROWIAN um eine Prototypanlage handelt, wurde der Überwachungseinrichtung auch die Funktion einer Inbetriebnahmemeßeinrichtung übertragen. Einige der für diese Aufgaben verwirklichten Details werden beschrieben.

PROSIT ist ein Programmsystem zurPrognose des Gasverbrauchs und zur vorausschauenden instationären Gasnetzsimulation. PROSIT ist online an den Prozeß gekoppelt und erlaubt eine realistische Berechnung des Netzverhaltens über einen Zeitraum von 48 Stunden voraus. Die Ergebnisse ermöglichen die Überprüfung geplanter Steuermaßnahmen und die Optimierung der Gasnetzführung in der Leitwarte.

Ausgehend von den Merkmalen von Industrieanlagenprozessen werden die Randbedingungen für die Auslegung verteilter Prozeßleitsysteme dargestellt. Es werden Kriterien angegeben, nach denen der Anwender bei Realisierung einer Leitanlage vorgehen kann, um Art und Struktur der Aufgabenstellung des Prozesses optimal zu berücksichtigen. Es wird ein Vorschlag für die Systematik der Vorgehensweise gemacht sowie ein Ausblick auf weitere Entwicklungstendenzen gegeben.

Die für Dialogkomponenten neue Umgebung zwingt den erstellenden Software-Ingenieur, stärker als bisher unter Ergonomie nicht nur die Physis, sondern insbesondere die Psyche der mit der Maschine kommunizierenden Menschen zu berücksichtigen. Dieses führt zu besonders harten „Konstruktionsforderungen“. Darüber hinaus sind mit Rücksicht auf den hinter der Realisierung stehenden Produktionsbetrieb Begriffe wie „Fehlersicherheit“oder „Fehlertoleranz“nicht nur leere Schlagworte, sondern unverzichtbare Forderung.

Es wird die Entwicklung und der Aufbau einer mikrocomputergesteuerten Plasma-Nitrieranlage (IONITRIER®-Anlage) exemplarisch beschrieben. Die bisher verwendeten analogen Steuerungen und Regelungen wurden durch ein modulares Rechnersystem auf der Basis des Prozessors 8085 ersetzt. Die Rechnerkonfiguration sollte möglichst einfach und kostengünstig sein. Der Schwerpunkt der Entwicklungsarbeit konnte durch Kauf der Hardware voll auf die Software-Entwicklung gelegt werden. Wegen des vorwiegend langsam ablaufenden Prozesses war es möglich, die höhere Programmiersprache PL/M 80 zu verwenden. Bei der Software-Erstellung wurde besonders auf einfache Bedienung der Anlage und auf Servicemöglichkeiten vor Ort geachtet.

Gegenstand der empirischen Untersuchung sind die Gestaltungsmethoden für computergestützte betriebliche Informationssysteme, dargestellt am Beispiel von Prozeßdatenverarbeitungssystemen. Die Zielgruppe der Erhebung waren die Hersteller dieser Informationssysteme wie Software-Häuser, Unternehmensberatungen, Fördermittelhersteller und Anwender.Es wurde davon ausgegangen, daß der Einsatz von Methoden und Werkzeugen einen wesentlichen Einfluß auf die Produktivität bei der Herstellung sowie die Qualität der hergestellten Software-Produkte ausübt. Die Zielsetzung der Untersuchung ist es, diese Einflüsse zu analysieren. Es wird das Herstellerprofil und die Rahmendaten der verwendeten Methoden und Werkzeuge aufgezeigt. Anschließend erfolgt eine Darstellung des Unterstützungsgrades durch Methoden und Werkzeuge. In einer analytischen Betrachtung werden die Wirksamkeit und die Erfahrungen mit Methoden und Werkzeugen sowie deren Einflüsse auf die Ergebnisse des Softwareproduktionsprozesses in Abhängigkeit vom Unterstüzungsgrad untersucht.

Ausgehend von einer allgemeinen Beschreibung des Genehmigungsverfahrens für sicherheitsrelevante technische Systeme wird insbesondere die Problematik eines Sicherheitsnachweises für Software erläutert. Es wird eine anerkannte Vorgehensweise für einen Sicherheitsnachweis dargestellt, nach der Software als fehlerfrei anzusehen ist, wenn bestimmte (konstruktive) Maßnahmen zur Fehlerabwehr und bestimmte (analytische) Maßnahmen zur Fehleroffenbarung nachweislich angewendet werden. Zur Festlegung derartiger konstruktiver und analytischer Maßnahmen, die mit der entsprechenden Aufsichtsbehörde oder anerkannten Sachverständigen abgestimmt sein müssen, sind bei AEG-TELEFUNKEN interne Richtlinien ‐ zur Erstellung‐ und zur internen Prüfung sicherheitsrelevanter Software aufgestellt worden. Diese Richtlinien, die erstmals im Zuge des Projektes „M-Bahn Berlin“angewendet werden sollen, werden im folgenden in ihren Grundzügen vorgestellt.

Die primäre Aufgabe der Industrieroboterprogrammierung ist es - ähnlich wie bei der Programmierung numerisch gesteuerter Werkzeugmaschinen - Bewegungsabläufe festzulegen. Für einfache Anwendungen ist die reine Bewegungsprogrammierung - üblicherweise im Teach-In-Verfahren - verbunden mit einer einfachen Schnittstelle zur Prozeßsynchronisation über binäre Signale völlig ausreichend. Für den Einsatz der Roboter in flexiblen Automatisierungssystemen muß die Steuerung jedoch weitere Funktionen zur Verfügung stellen. Dazu gehören vor allem die Sensordatenverarbeitung, eine erweiterte Schnittstelle zum Prozeß für die Steuerung roboternaher Peripherie sowie eine Schnittstelle zur übergeordneten Fertigungssteuerung mit der Möglichkeit der schnellen Anpassung des Programms beim Produktwechsel.

Es werden die Anforderungen, sowie methodischen Konzepte und integrierten Werkzeuge im durchgängigen und universellen Entwicklungssystem CAMIC/S beschrieben. Dieses Entwicklungssystem befindet sich seit 1982 in der Industrie für die Realisierung von Mikroprozessor-Software im Einsatz. Abschließend wird ein Erfahrungsbericht über den Einsatz in einer Elektronik-Abteilung bei MAN-Roland in Augsburg gegeben.

Dieser Vortrag hat zum Ziel, dem Leser zu zeigen, daß die herkömmliche Form der Verwaltung von Software als überholt gelten muß: Seit kurzer Zeit existieren auf dem Markt Werkzeuge, mit denen man nicht nur einzelne Dateien, sondern nun auch ganze Softwaresysteme in beliebig vielen Versionen übersichtlich und ökonomisch verwalten kann. Mehr noch, diese Werkzeuge sind - wie z.B. die Projektbibliothek PAPICS -‐ nicht nur ideal zum Configuration Management,‐ sondern auch wirkungsvolle Hilfe beim Projekt-Controlling. Das Papier gliedert sich in vier Abschnitte: 1.Die konventionelle Form der Produktverwaltung2.Wie man Software heute verwalten sollte3.Beispiel eines modernen Systems: Die Projektbibliothek PAPICS4.Erfahrungen bei Einführung und Anwendung von PAPICS

Die BEB Gewerkschaften Brigitta und Elwerath Betriebsführungsgesellschaft (BEB) errichtete eine neue computergestützte Leitzentrale zur Überwachung und Steuerung der Anlagen für die Produktion, den Transport und die Verteilung von Erdgas. Bei dem Projekt hatte der Komplex „Engineering“eine besondere Bedeutung. Diese Tätigkeit umfaßte die konkrete Planung und den Entwurf des Prozeßrechnersystems, die Planung der Projektabwicklung, Kontrolle der Projektabwicklung sowie die Planung und Durchführung aller Tests. Es wird über die Engineeringtätigkeiten im einzelnen sowie über Erfahrungen und Erkenntnisse aus der Sicht des Anwenders berichtet.

Ausgehend von einer Übersicht über die für Realzeitsysteme relevanten Entwurfsmethoden wird gezeigt, wie diese unterschiedlichen Vorgehensweisen in das Software/Hardware-Entwicklungssystem EPOS integriert sind und welche Rechnerunterstützung bei der Anwendung dieser Methoden zur Verfügung gestellt wird.

Die Erfahrung hat gezeigt, daß die Verwendung getrennter Software-Werzeuge zur Unterstützung der Entwicklung, der Projektführung und der Produktverwaltung technischer Projekte unzureichend ist. Integrierte Entwicklungs- und Managementunterstützende Systeme müssen eingesetzt werden, um den steigenden Anforderungen an die Erstellung zuverlässiger, leicht wartbarer Systeme und an die wirtschaftlich erfolgreiche Durchführung von Projekten gerecht zu werden.Es wird gezeigt, wie beim Softwarewerkzeug-System EPOS (Entwicklungs- und Projekt-management-Orientiertes Spezifikationssystem) die Integration der Managementunterstützung auf der Grundlage einer gemeinsamen Projektdatenbank realisiert ist.

In nahezu allen Publikationen über Themen der Anforderungsspezifikation ist unbestritten festgestellt worden, daß ‐ die Kosten der Herstellung von Software,‐ die Zuverlässigkeit der Softwareprodukte und‐ der Grad der Erfüllung der ursprünglichen Anforderungen auch in Automatisierungsprojekten vor allem durch die Vollständigkeit, Widerspruchsfreiheit und Verträglichkeit der anfänglichen Anforderungsspezifikation bestimmt werden. Diese letztgenannten Eigenschaften sind aber nur durch einen hohen Grad an Formalisierung in der Spezifikation erreichbar.Dieser Beitrag stellt ein Hilfsmittel, das System SARS• vor, das die Formalisierung der Anforderungen unterstützt. Die formale Sprache dieses Systems

Grundlage für jeden Fehlertoleranzmechanismus eines Rechnersystems ist die Fehlererkennung. Es müssen sowohl permanente als auch transiente Fehler erkannt werden, insbesondere, wenn das Rechnersystem für Prozeßautomatisierungsaufgaben eingesetzt wird. Diese Aufgabe kann dem Anwender oder dem Betriebssystem aufgebürdet werden und wird vorteilhaft durch einen Vergleichs-oder Votiermechanismus wahrgenommen. Um den Anwenderprogrammierer von Problemen der Fehlertoleranz zu befreien, muß die Fehlererkennung und -erholung durch Betriebssystemfunktionen wahrgenommen, die an markanten Punkten des Anwenderprogramms automatisch aktiviert werden.Nach der Diskussion von Fehlerarten und Methoden der Fehlererkennung werden einige Fehlererholungsstrategien erläutert und am Beispiel des FUTURE-Systems konkretisiert.

Der Einsatz dynamischer Redundanz bei freiprogrammierbaren Rechnern benötigt ein effizientes Zustandssicherungsverfahren. Hierzu lassen sich bei MSR-Aufgaben mit Vorteil systemtheoretische Ansätze verwenden, die die Reduktion der Häufigkeit, des Datenumfangs und des on-line Verwaltungsaufwandes erlauben. Dies bedingt spezifische Sprachelemente zur Kennzeichnung zyklischer und sequentieller Programmtypen, zur direkten Bearbeitung von Vektoren und Matrizen sowie zum Zugriff auf die Echtzeit. Die damit erreichbaren Ergebnisse werden durch Versuche mit dem FTR-Experimentalsystem verifiziert.

Entwurfs- und Programmierfehler in zyklisch aufgerufenen Automatisierungsprogrammen können bewirken, daß falsche Ausgangsgrößen ermittelt werden, oder daß in einem Zyklus kein Resultat errechnet wird. Es werden zwei bekannte Methoden zur Erzielung von Fehlertoleranz für Anwendungen mit hohen Verfügbarkeitsanforderungen erläutert, nämlich die “Recovery-Block”-Methode und die „N-Version-Programming“-Methode. Anschliessend wird als neues Verfahren die Methode der „zyklischen Abwechslung“ vorgestellt. Diese Methoden werden am Beispiel einer fehlertoleranten Programmierung eines Regelalgorithmus für einen Mikrorechner als Regler miteinander verglichen. Das neue Verfahren der „zyklischen Abwechslung“ wird außerdem an Hand eines Modellprozesses getestet. Die Ergebnisse werden aufgezeigt und diskutiert.

Dieser Beitrag beschreibt als Teil 1 die Realisierung eines fehlertoleranten Rechnersystems für Prozeßsteuerungen. Die Fehlertoleranz wird durch hierarchisch abgestufte Hardware- und Software-Maßnahmen bewirkt. Anwendungsbereiche dieses Systems sind u.a. Regelungsaufgaben in Flugzeugen. Teil 2 befaßt sich mit der besonderen Problematik der Programmierung von Avionik-Regelungsaufgaben. Die zu beachtenden Restriktionen und die spezifische Software-Struktur werden beschrieben.

Es werden die benutzten Arbeitsbegriffe „Führungs- und Waffeneinsatzsystemm“..(FÜWES), FÜWES-Architektur und FüWES-Struktur erläutert. Nach einer Einteilung der FÜWES- Strukturen wird für die voll distributive Struktur eine DV-Architektur angegeben, aus der sich alle anderen Strukturen ableiten lassen. Es werden die wichtigsten Komponenten dieser DV-Ar chitektur vorgestellt, die von der Firma Siemens AG, München, konzipiert wurde. Es ist ein „Schiffsintegriertes Fiberoptisches Netzwerk“ (SIFONET).

Die Struktur der Hardware und Software des Mehrprozessorrechners MPR 1300 wird beschrieben. Die Vorteile der Struktur aus parallelen, gleichberechtigten Prozessoren, die über vier Busse auf den gemeinsamen Speicher zugreifen, werden diskutiert. Über einige Probleme und ihre Lösungen bezüglich der Organisation der Prozessorvergabe, der Synchronisation, des Interruptverhaltens und der Fehlertoleranz wird berichtet. Der erzielte Durchsatz in Abhängigkeit von der Zahl der Busse und der Prozessoren wird vorgestellt.

Für die Rechner der Siemens Systeme 300/6.000, Modellreihen SICOMP/6.680 wurde in Zusammenarbeit mit dem Kernforschungszentrum Karlsruhe, Institut für Datenverarbeitung in der Technik (KfK/IDT), ein Serviceprozessorsystem entwickelt. Dieses aus Hard- und Softwarekomponenten bestehende Diagnosemittel ist für den Einsatz in den Entwicklungs-/Servicezentren und im Feld geeignet. Es ist weitgehend von der zu diagnostizierenden Anlage entkoppelt. Die wesentlichen Eigenschaften sind eine hardwaremäßige, unverzögerte Ereignisanalyse und eine zeitgleiche, selektive Diagnosedatenerfassung in einen Mithörpuffer. Ein Mikroprozessor auf der Anschaltung ermöglicht die Kombination der Basisfunktionen, eine Datenvorauswertung und die Datenerfassung per Software. Auf dem selbständigen Serviceprozessor steht ein umfangreiches aufgabenbezogenes Softwarepaket zur Parametrierung und zur Auswertung der Diagnosedaten zur Verfügung.

Es wird ein System zur Visualisierung von Anlagenzuständen vorgestellt, das im Zuge eines Lieferauftrags für das KKW-Kalkar völlig neu entwickelt wurde. Die wesentlichen Komponenten des Systems werden zudem in den im Bau befindlichen Kernkraftwerken sowie in den Konvoi-Projekten der Kraftwerk Union eingesetzt.Die Modularität des Systems genügt höchsten ebenso wie weniger hohen Anforderungen, zugeschnitten auf die jeweilige leittechnische Aufgabe. Die enorme Prozessorleistung erlaubt den Ausbau eines kompletten Rechnersystems, das Betriebssystem und die von ihm unterstützten Hochsprachen erlauben, die gesamte Systemsoftware in diesem System zu implementieren.

das nach den modernen Ansprüchen an ein Informationssystem konzipiert ist. Als Grundlage für eine hohe Flexibilität und Benutzerfreundlichkeit ist die relationale Datenbank ORACLE in das Anwendungssystem integriert. Durch den Betrieb als Doppelrechnersystem ist eine hohe Verfügbarkeit gewährleistet.

In zunehmendem Maße werden Industrieroboter zur Automatisierung von Fertigungseinrichtungen eingesetzt. Die Erfahrungen, die beim Aufbau des in diesem Beitrag vorgestellten Flexiblen Fertigungssystems für Rotationsteile gewonnen wurden, und die daraus abgeleiteten Anforderungen sind nicht nur auf diese Systemlösung beschränkt, sondern gelten allgemein auch für andere Systeme.

Die Steuerung eines Industrieroboters bestimmt in großem Maße dessen Leistungsfähigkeit und Einsatzbreite. Dieser Beitrag beschreibt eine Neuentwicklung auf diesem Gebiet, die 1984 in verschiedenen Anwendungsfällen zum Einsatz kommt. Dazu werden zunächst einige allgemeine Gesichtspunkte wie Aufgabenstellung und Anforderungen an derartige Systeme behandelt. Nach einem kurzen Abriß des gerätetechnischen Aufbaus wird auszugsweise auf das ausgeführte Betriebssystem eingegangen.

Einschneidende technologische, wirtschaftliche und gesellschaftliche Veränderungen in den letzten Jahrzehnten haben die industriellen Herstellungsprozesse in zunehmendem Maße erschwert.

Zur Überwachung von KWU-Kernkraftwerken werden schon seit Jahren die umfangreichen Meßdaten von Prozeßrechnern erfaßt und in aussagekräftige Informationen über den thermohydraulischen und nuklearen Zustand der Anlage transformiert. Beim zukünftigen Einsatz moderner 32-Bit-Rechner, die zunächst nur zur Datenverdichtung und -darstellung benutzt werden, können recht anspruchsvolle Modelle und Programme online eingesetzt werden. Der Kernsimulator ABCBOX zur Berechnung der Leistungsdichteverteilung ist ein erster Schritt in diese Richtung. Die Vorteile der Verwendung von ABCBOX im Kernüberwachungssystem werden dargelegt und kurzfristig realisierbare Modellerweiterungen diskutiert.Weitergehende Fortschritte auf dem Gebiet der Anlagensimulation sind durch die Entwicklung neuer Rechnerstrukturen, mathematischer Verfahren und ihre Parallelisierung zu erwarten.

Prozeßrechner werden in Kernkraftwerken zur Überwachung und Dokumentation des Betriebsablaufs verwendet. Sie geben Störungsmeldungen über Sichtgeräte aus, erstellen Protokolle, und führen kerntechnische Berechnungen durch. Das PROZESSRECHNERINFORMATIONSSYSTEM für Kernkraftwerke soll neben den bisherigen Aufgaben zukünftig Prozeßinformationen hochwertig aufbereiten und über Grafiksichtgerätesysteme ausgeben. Für diese Aufgaben wird ein leistungsfähiges, redundantes Rechnersystem mit dezentralen Grafiksichtgerätesteuerungen eingesetzt.

Der Entwurf eines Betriebsleitsystems zur Prozeßsteuerung von Magnetschnellbahnen ist eng mit dem Entwurf des Bahnsystems verknüpft. Die verkehrlichen Anforderungen wie die unkonventionelle Technologie bestimmen maßgeblich das funktionale und technische Konzept der prozeßnahen Steuerungseinheiten. Dafür wird ein Verbund aus dezentralen Rechensystemen zur lokalen Optimierung, Regelung und Sicherung der Fahrzeugbewegung auf der Grundlage von Instanzen- und Petrinetzen entwickelt.

Im Rahmen des Neubaus eines Kunststoffolienkalanders in 1978 wurde erstmalig ein Prozeßrechner in die Anlage integriert.Das Ziel war eine möglichst umfassende Meßdatenerfassung/Speicherung/Auswertung zur Verbesserung der Fahrweise des Kalanders angesichts des auch heute noch quatitativ nicht beschreibbaren Kalandrierprozesses. Eingeschlossen ist die traversierende Dikkenmeßanlage.Die nicht am Kalander automatisch erfaßbaren Daten (Rezepturen, Qualitätsdaten) müssen im Dialog eingegeben werden.Angesichts der Vielfalt an Daten und ihrer Verknüpfungen wurde beschlossen, von Anbeginn Datenbanken einzusetzen, um die Anwender-Programmierung zu vereinfachen und die Datenverknüpfung flexibel zu gestalten.Zum Einsatz gelangte ein Prozeßrechner Hewlett-Packard HP 1000 mit dem serienmäßigen Datenbanksystem IMAGE. Das Prozeßrechner-System arbeitet im 24-Stunden-Betrieb. Realtime- und Datenbankprogramme laufen gemeinsam und ohne Probleme. 5 Datenbanken (Sollwerte, Istwerte, Auftragsdaten, Qualitätsdaten, Rezepturen) umfassen 25 MB.Im Rahmen eines seit 1980 laufenden BMFT-Fördervorhabens laufen Arbeiten zur weiteren Automatisierung des Kalanderprozesses. Hier wurden für Teilautomatisierung untergeordnete freiprogrammierbare Steuerungen sowie Diodenzeilenkameras eingesetzt. Für diese Arbeiten sowie auch bei Aktualisierung der System-Software wurden die Datenbanken mit Hilfe serienmäßiger Utilities ohne Datenverlust entladen und wieder beladen.Gleichzeitig mit dem Realtime-Betrieb werden Datenauswertungen inklusive Plots und statistische Auswertungen (Regressionsanalysen) durchgeführt.

In der Papier- und Kunststoffindustrie werden flaechige Gueter in kontinuierlichen Prozessen hergestellt.

Es wird ein problemorientiertes Entwurfs- und Spezifikationssystem vorgestellt, das speziell für die Automatisierung von diskreten technischen Prozessen konzipiert und entwickelt wurde.Ausserdem wird ein vollständiger Satz von Software-Werkzeugen erläutert, der aus der Spezifikation automatisch Programme generiert, die projektbegleitende Dokumentation übernimmt und rechnergestützte Hilfsmittel für Diagnose und Test zur Verfügung stellt, so dass die Zuverlässigkeit wesentlich erhöht und die Kosten erheblich reduziert werden.

Der Interpreter CADCO stellt ein kleines Betriebssystem dar, das für den Bereich regelungstechnischer CAD-Systeme konzipiert wurde, aufgrund seines nicht-problemorien-tierten Aufbaus aber auch in anderen Bereichen einsetzbar ist. Der Beitrag stellt zu-nächst in Form eines Pflichtenhefts die von dem Interpreter als zentrales Verwaltungssystem geforderten Funktionen zusammen und beschreibt das daraus abgeleitete Konzept des CADCO-Systems und des entworfenen Dateiensystems, welches die Flexibilität erhöht und die Lernfähigkeit hinsichtlich des verfügbaren Kommandosatzes ermöglicht. Der Erläuterung der Semantik und der Syntax der Kommanodsprache, der Kommunikation mit dem Benutzer sowie der ihm zur Verfügung stehenden Systemhilfen folgen einige Angaben zur programmtechnischen Realisierung und erste Erfahrungen im Einsatz.

Für einen Prozeßrechner läßt sich ein allgemeines Zustandsmodell erstellen. Mit diesem und aufgrund der Anlagengröße, der Programmierarbeiten und des Umfeldes können die Ausfallhäufigkeit und die Verfügbarkeit eines Prozeßrechners ermittelt werden. Bei der Berechnung werden die latenten, nicht statisch anstehenden Mängel mit berücksichtigt.

RDHS, ein portables Datenbanksystem für 16-und 32-Bit-Mini- und -Mikrorechner, wird vorgestellt. RDHS ist besonders für solche Anwendungen geeignet, welche die Speicherung und Verarbeitung unterschiedlich organisierter und vielfältig verknüpfter Daten in einer Rea1zeit-Umgebung erfordern. Das Datenbanksystem bietet verschiedene Formen der Datenorganisation mit unterschiedlichen Zugriffsmöglichkeiten und gewährleistet transaktionsorientierte Datensicherung. RDHS bietet flexible Anpassungsmöglichkeiten an Haupt- und Hintergrundspeieher, es erlaubt den Multi-User-Betrieb und kann im Drei-Schicht-Betrieb ohne Reorganisationsläufe genutzt werden.

Zur Formulierung zuverlässiger Software für zeitkritische Anwendungen fehlen in den verfügbaren Prozeßprogrammiersprachen problemorientierte Sprachkonstruktionen zur Synchronisation, zur Ereignisüberwachung und zum Ausdruck des Zeitverhaltens. Die Sprache Pearl wird deshalb durch geeignete Erweiterungen, deren Syntax und Semantik beschrieben werden, entsprechend angepaßt. Weiterhin werden bisher noch nicht realisierte Betriebssystemdienste, die für ein zuverlässiges und genau vorhersehbares Programmverhalten notwendig sind, und die sie steuernden Anweisungen diskutiert. Die Implementation solcher Elemente dürfte ein wichtiger Schritt hin auf dem Wege zur Ermöglichung der sicherheitstechnischen Abnahme von Software sein.

Für die Programmierung eines Betriebsleitsystems für einen großen öffentlichen Verkehrsbetrieb wurde eine erweiterte Version der Programmiersprache BASIS-PEARL verwendet. Anhand der dabei gewonnenen Erfahrungen werden verallgemeinerte Aussagen zur Eignung von PEARL vorgetragen.

Der Beitrag befaßt sich mit der Integration der Planung und Strukturierung von Prozeßleitsystemen in die Gesamtplanung und Erstellung von Chemieanlagen. Es wird ein Konzept dargestellt, das Methoden und Werkzeuge zur rechnerunterstützten Bearbeitung der Funktionsbereiche „Messen, Regeln, Melden“ sowie „Steuern“ und „Bedienen und Beobachten“ für die einzelnen Projektphasen beschreibt. Auf die bereits realisierten Programmpakete wird besonders hingewiesen.

Im vorliegenden Beitrag wird versucht, einige allgemeine Schlußfolgerungen für die Gestaltung von modernen digitalen Prozeßautomatisierungsanlagen für chemische Großanlagen zu ziehen, wobei Erfahrungen dargelegt werden, die beim Aufbau und beim Betrieb solcher Systeme für neue petrolchemisehe Produktionskomplexe gewonnen wurden.

Ausgehend von der Problematik des Steuerungsbaues für Kleinserien relativ komplexer Maschinen wird in diesem Beitrag der Einsatz eines Mu1ti-Mikrocomputersystems begründet. Im weiteren wird das VOEST-ALPINE-Konzept dargestellt, das in allen Stufen — selbstent-wickelte Hardware, System- und Anwendersoftware, Installation etc. — durch hohe Modularität und Flexibilität gekennzeichnet ist. Abschließend behandelte, kurze Beispiele zeigen die konkreten Anwendungungsbereiche.

Die Realisierung von Fehlertoleranz in verteilten PDV-Systemen erfordert bestimmte Eigenschaften der Systemarchitektur und angepasste Methoden zur Interprozesskommunikation. MARS (MAintainable Realtime System) ist ein verteiltes System für PDV-Anwendungen, das diese Anforderungen erfüllt. Die zur Verfügung gestellten Sprachkonstrukte unterstützen die Realisierung redundanter Verarbeitungseinheiten, die Implementierung replizierter Datenspeicher und den Einsatz redundanter Schnittstellen zum zu steuernden, technischen Prozess.

Die Entwicklung der Datenverarbeitung führte in den letzten Jahren von einer zentral orientierten EDV zu einer stark dezentralisierten Datenverarbeitung. Dies wurde durch den Einsatz außerordentlich leistungsstarker Klein- und Kleinstrechner möglich. Die so entstehenden dezentralen Strukturen werden durch lokale Kommunikationswege zusammengefaßt, so daß Datenströme zwischen den Teilnehmern eines solchen Netzes neue, nicht zentral orientierte Verbindungen schaffen und zu außerordentlich effizienten Organisationsstrukturen führen.Der Einsatz von Lichtwellenleitern für die Datenübertragung und preisgünstigen Kommunikationsrechnern als Netzwerkadapter sowie entsprechende Softwarepakete zur benutzernahen Anwendersystemintegration sind die Basis eines ILAN, eines „Industrial Local Area Network“.

Existierende Buszugriffsverfahren erfüllen die Anforderungen der Prozessdatenverarbeitung nicht optimal. Das hier beschriebene Protokoll kombiniert die Eigenschaften von TDMA-, CSMA/CD- und Token-Protokollen so, dass insbesondere die Rechtzeitigkeitsforderung an Echtzeitsysteme eingehalten werden kann.

Der verstärkte Einsatz modernster Mikroelektronik im Bereich der Mensch-Maschine-Kommunikation eröffnet neue Gestaltungsmöglichkeiten und Marktchancen. Das Fraunhofer Institut für Arbeitswirtschaft und Organisation (IAO)Stuttgart hat für die Gestaltung solcher Systeme eine systematische Vorgehensweise auf der Grundlage gesicherter arbeitswissenschaftlicher und speziell software-ergonomischer Erkenntnisse entwickelt.

Je mehr Arbeitsprozesse technisiert werden, um so mehr stoßen arbeitsorganisatorische Maßnahmen zur Schaffung von Tätigkeitsbildern mit qualifizierten Arbeitsinhalten an die Grenzen der vorgefundenen Technik. Denn von ihrer Gestaltung hängt es zunehmend ab, was an qualifizierten Arbeitsinhalten überhaupt noch zur Verfügung steht und wie es auf die betroffenen Arbeitnehmer verteilt werden kann. Eine Fehlgestaltung der Technik — vor allem nach der Richtlinie, den „Kosten- und Risiko-Faktor Mensch“ weitestgehend einzusparen - hat nicht nur „Fehlverhalten“ der Technik zur Folge, sondern auch eine „Fehlbeanspruchung“ der damit arbeitenden Menschen. In entsprechend gestaltete Prozesse ist „technisches oder menschliches Fehlverhalten“ als vordergründige Ursache vieler Stör- oder gar Unglücksfälle schon einprogrammiert. Diese Erfahrung ist Ausgangspunkt, den tieferliegenden, eigentlichen Ursachen nachzugehen und einige wichtige Anhaltspunkte zu liefern, wie Technik, speziell Informationstechnik, auszulegen ist, um Tätigkeitsbilder mit qualifizierten Arbeitsinhalten zu erzielen.

In den letzten Jahren ist die Einsicht gewachsen, die Schnittstelle zwischen dem Rechner und dem Benutzer auch nach arbeitswissenschaftlichen Kriterien auszulegen. Nach grundlegenden Untersuchungen über die ergonomisch-technische Gestaltung von Bildschirmgeräten (hier sind u.a. die Arbeiten von Cakir zu nennen), hat man sich in den letzten beiden Jahren verstärkt der Software-mäßigen Gestaltung der Informationsdarbietung und des Dialogablaufs angenommen. Diese Forschungsrichtung wird als „Software-Ergonomie“, „kognitive Ergonomie“ oder „Informationspsychologie“ bezeichnet.

Die derzeit in Bau befindlichen deutschen Konvoi-Kernkraftwerke erhalten, ein rechnergestuetztes Prozessinformationssystem, zu dessen Aufgaben die Ausgabe von Prozessgrafiken auf Farbsichtgeraeten zaehlt. Dieser Beitrag berichtet ueber wesentliche Systemmerkmale und ueber Zweck, Inhalt, Darstellungstechnik und Bedienung der vorgesehenen Bilder. Es werden intelligente, die Hauptrechner entlastende Sichtgeraetesteuerungen eingesetzt, mit denen sich anspruchsvolle voll- und semigrafische Bilder erzeugen lassen. Ziel ist ein benutzerfreundliches System, das den Operateuren mittels bildschirmgerechter Visualisierungstechniken und einfacher Bedienung ein Hoechstmass an konzentrierter Prozess-Uebersichtsinformation anbietet.

Die Erstellung von Dialogsystemen in bildschirmgestützten Prozeßleitwarten durch „klassische Ausprogrammierung“ bedeutet zunehmend größere Realisierungsaufwendungen. Dies gilt insbesondere bei der Berücksichtigung unterschiedlicher Benutzer des technischen Systems und den resultierenden Anforderungen an die Mensch-Prozeß-Schnittstelle.Es müssen Lösungen geschaffen werden, die auch eine benutzeradaptive Dialogführung ermöglichen.Beispielhaft wird das Prinzip der bausteinorientierten Methodenkonstruktion und seine Implementierung in dem Allgemeinen Dialog- und Bediensystem ADBS aufgezeigt: um eine Ablaufsteuerung als invarianten Kern werden anwendungsorientierte Schalen gelegt, bestehend aus Eingabe- und Ausgabeverarbeitungsbausteinen, Kommunikationsbausteinen und anwendungsspezifischen Funktionsbearbeitungsbausteinen. Mit Hilfe von Ablaufsteuerungsdaten für eine Methode (als Kombination von Bausteinen) wird ein dynamisches Binden und Parametrieren der Bausteine erreicht. Die Bearbeitungsergebnisse werden zwischen den Bausteinen über die standardisierten Schnittstellen weitergereicht. Der inter- pretative Bearbeitungsaufwand bleibt gering; eine starre unflexible Verknüpfung der Softwarebausteine wie durch „ausprogrammierte Funktionen“ wird dennoch vermieden.Das Implementierungsprinzip von ADBS wurde erfolgreich angewendet in einem Beobachtungs- und Bediensystem für konventionelle Kraftwerke, an dem Einsatz für verfahrenstechnische Prozesse mit anderen Darstel- lungs- und Bedienfunktionen wird gearbeitet.

Die Mikroprozessorenentwicklung hat zu freiprograitimierbaren dezentralen Leitsystemsn geführt. Die Einführung damit verbundener rechnergestützter Planungs- und Fertigungsmethoden wird uns in Richtung elektronische Selbstdokumentation der leittechnischen Produkte weiterbringen.