DE19841194A1 - Mit Funktions- und Ablaufplänen programmierbares elektronisches System für Sicherheitsaufgaben - Google Patents

Abstract

Um für sicherheitskritische Automatisierungsaufgaben festverdrahtete durch programmierbare elektronische Systeme ablösen zu können, müssen diese mit hinreichendem Vertrauen in die Verläßlichkeit auch ihrer Software erstellt werden können, das ihre formelle Zulassung durch die Aufsichtsbehörden unter wirtschaftlichen Bedingungen erlaubt. Erschwerend kommt hinzu, daß sich integrierte Schaltkreise und Mikroprozessoren nicht ausfallsicherheitsgerichtet verhalten. DOLLAR A Die Hardware des programmierbaren Systems für sicherheitsgerichtete Anwendungen ist fehlererkennend und auf ausfallsicherheitsgerichtetes Ausgabeverhalten hin ausgelegt. Seine Mehrrechnerarchitektur erlaubt es, als Funktions- und Ablaufpläne formulierte Anwenderprogramme ohne semantische Lücke oder Betriebssystem auf die Ausführungsebene abzubilden, wo ein dezidierter Rechner Aufrufe typgeprüfter Funktionsblöcke bearbeitet, während ein anderer durch Funktionspläne dargestellte Datenflüsse zwischen Funktionsblöcken und durch Ablaufpläne beschriebene Schrittfolgen umsetzt. Die Architektur unterstützt inhärent leichte, aber dennoch strenge Nachweisbarkeit der Korrektheit von Anwenderprogrammen, indem Maschinencode durch Inspektion unmittelbar in eine graphische Form übersetzt werden kann, die direkten Vergleich mit Programmspezifikationen erlaubt. DOLLAR A Automatisierungsaufgaben mit Sicherheitsverantwortung.

Description

Wegen ihrer Flexibilität nimmt in der Automatisierungstechnik der Ein­ satz rechnergestützter Automatisierungsgeräte, insbesondere speicherprogram­ mierbarer Steuerungen, schnell zu. Daher liegt es nahe - und wird aus Ko­ stengründen zunehmend gefordert, programmierbaren elektronischen Systemen auch Steuerungs- und Regelungsaufgaben mit Sicherheitsverantwortung zu über­ tragen und sie letztendlich auch in hochkritischen Schutz- und Notabschaltsyste­ men einzusetzen.

In vielen sicherheitskritischen Anwendungen, wie z. B. in Kernkraftwerken oder explosionsgefährdeten chemischen Fabriken, in denen von der technischen Funktionalität her programmierbare elektronische Systeme eingesetzt werden könnten, werden jedoch weiterhin klassische festverdrahtete, auf der Basis von Relais-Schaltungen oder diskreter Logik aufgebaute Sicherheitssysteme bevorzugt [13]. Typischerweise werden in festverdrahteten Steuerungen logische Gatter, bi­ stabile Kippstufen, Vergleicher und ähnliche einfache Funktionen als Baugruppen eingesetzt [5, 4], die wiederum aus diskreten Komponenten wie Transistoren, Spu­ len, Kondensatoren, Widerständen und Transformatoren aufgebaut sind.

Ein besonderes Merkmal der in festverdrahteten Sicherheitssteuerungen zum Einsatz kommenden Bauelemente ist, daß sie hinsichtlich ausfallsicherheitsgerich­ teten Verhaltens sicherheitstechnisch abgenommen sind, d. h. ihnen ist im Falle aller möglichen auftretenden Fehlfunktionen ein auf Grund eines Naturgesetzes inhärent sicheres, a priori bekanntes, eindeutiges und nur in einer bestimmten Richtung wirkendes Ausfallverhalten eigen. Bei Ausfällen nehmen somit auch die Ausgangssignale festverdrahteter Steuerungen definierte Zustände an [5, 4]. Mit Hilfe dieses Effektes können technische Prozesse bei Ausfall ihrer Steuerungen in sichere Zustände überführt werden. Ausfallsicherheitsgerichtete Steuerungen sind um wenigstens eine Größenordnung teurer als Standardsteuerungen.

Bisher gibt es noch keine integrierten Schaltkreise mit ausfallsicherheitsgerich­ tetem Verhalten. Darum werden, wenn überhaupt, in festverdrahteten Sicher­ heitssteuerungen nur integrierte Schaltungen mit niedrigem Integrationsniveau verwendet [12, 4].

Die Gründe für die oben erwähnte Bevorzugung festverdrahteter gegenüber programmierten Sicherheitssystemen liegen einerseits darin, daß für erstere lang bewährte Entwurfs- und Prüfmethoden existieren, während andererseits das Ver­ trauen in die Korrektheit von Software fehlt und die sicherheitstechnische Ab­ nahme von Software zur Zeit weder befriedigend beherrscht wird noch wirtschaft­ lich durchzuführen ist. Mehr und mehr dringen die ureigenen, mit Software ver­ bundenen Sicherheitsprobleme auch in das Bewußtsein der Öffentlichkeit. Es erscheint aber unrealistisch, auf den Einsatz von Rechnern für sicherheitsgerich­ tete Automatisierungsanwendungen zu verzichten - im Gegenteil besteht kein Zweifel, daß ihre Verbreitung in solchen Anwendungsbereichen aus Kosten- und Flexibilitätsgründen schnell und deutlich zunehmen wird.

Automatisierungsanwendungen werden in textuellen Programmiersprachen jeglicher Art, aber auch in graphischen Sprachen formuliert. Zu letzteren gehören die Sprachen Kontaktplan auf niedrigem und Funktionsplan [8, 9] auf hohem Abstraktionsniveau. Die Funktionsplanprogrammierung ist an den Entwurf ana­ loger und digitaler Schaltungen auf der Grundlage des Zusammenfügens stan­ dardisierter Funktionsbausteine angelehnt. Direkte Verallgemeinerung letzterer führt zu Funktionsblöcken, die Ein- und Ausgänge beliebiger Datentypen ha­ ben und beliebige Verarbeitungsfunktionen durchführen können. Abgesehen von der Bereitstellung von Konstanten als externe Eingabeparameter sind Funktions­ blockinstanzen und durch Verbindungslinien dargestellte Parameterflüsse zwi­ schen ihnen die einzigen in Funktionsplänen verwendeten Sprachelemente. Die vom VDI/VDEGMA-Fachausschuß 5.3 erarbeitete Richtlinie VDI/VDE 3696 [11] zeigt, daß weniger als 70 Funktionsblöcke für die Formulierung der überwie­ genden Mehrheit aller in der Automatisierungstechnik eines größeren, abgeschlos­ senen Anwendungsbereiches - in diesem Fall der chemischen Verfahrenstechnik - vorkommenden Aufgaben ausreichen. Dank ihrer Einfachheit und Universa­ lität sind sie in vielen verschiedenen Zusammenhängen wiederverwendbar. Zur übersichtlichen Formulierung sequentieller Ablaufsteuerungen wurde die graphi­ sche Programmiersprache Ablaufplan [8] mit den drei Grundelementen Schritt, Aktion und Transition definiert.

Der in den Patentansprüchen angegebenen Erfindung liegt das Problem zu­ grunde, daß informationsverarbeitende Systeme zur Gewährleistung der wach­ senden Sicherheitsanforderungen mit einem hinreichenden Grad an Vertrauen in ihre Verläßlichkeit erstellt werden können müssen, der ihre formelle Zulassung - zu vertretbaren Kosten - für sicherheitskritische Automatisierungsaufgaben durch die Aufsichtsbehörden erlaubt. Die Lösung dieses Problems ist die Vor­ aussetzung dafür, festverdrahtete durch speicherprogrammierbare Automatisie­ rungsgeräte im Sicherheitsbereich ablösen zu können.

Durch geeigneten Hardware-Entwurf kann erreicht werden, daß die Ausgänge einer Steuerung bei Ausfällen einen sicheren Zustand annehmen [1]. Bei einer programmierbaren Steuerung kommt erschwerend hinzu, daß die Überleitung in einen sicheren Zustand nach Erkennung einer Fehlfunktion sofort automatisch er­ folgen muß, völlig unabhängig von der Tätigkeit des gerade laufenden Program­ mes. Der Entwurf ausfallsicherheitsgerichteter Hardware für programmierbare elektronische Systeme steht vor dem Problem, daß sich integrierte Schaltkreise einschließlich Mikroprozessoren nicht ausfallsicherheitsgerichtet verhalten. Bei Ausfällen nehmen sie zufallsbedingte Zustände an. Die erforderliche kontinuierli­ che Überwachung der korrekten Hardware-Funktion programmierbarer elektroni­ scher Systeme kann nicht wie bei herkömmlichen Geräten üblich allein mit Hilfe periodisch aktivierter Selbsttestprogramme oder einfachen "Watch-dogs" erfol­ gen, da durch diese Maßnahmen nicht alle Fehlfunktionen zu jeder Zeit erkannt werden können.

Auf dem Wege hin zur Entwicklung programmierbarer elektronischer Systeme für sicherheitskritische Automatisierungsaufgaben wird bisher fast ausschließ­ lich der Hardware-Seite Beachtung geschenkt. Demzufolge können die auf dem Markt angebotenen sogenannten "sicheren speicherprogrammierbaren Steuerun­ gen" zwar eine TÜV-Abnahme ihres Geräteaufbaus vorweisen [14], enthalten je­ doch keinerlei Vorkehrungen, die geeignet wären, die Korrektheit der darauf lau­ fenden Programme zu gewährleisten. Im Gegensatz zu den für Hardware charak­ teristischen Zufallsfehlern sind Programmfehler grundsätzlich systematischer Na­ tur und dauernd präsent. Sie werden durch mangelhafte Problemspezifikationen, fehlerhafte Programmimplementierungen oder unzureichende Übersetzer hervor­ gerufen. Um das Risiko falschen Steuer- und Regelverhaltens auszuschließen, muß streng nachgewiesen werden, daß entsprechende Programme ihre Spezifikationen erfüllen.

Deshalb verhalten sich die Zulassungsinstanzen derzeit noch sehr zurückhal­ tend bei der Abnahme ausschließlich programmgesteuerter sicherheitsgerichteter Automatisierungssysteme. Im allgemeinen werden noch keine sicherheitskriti­ schen Systeme lizensiert, die auf Software nichttrivialer Komplexität beruhen, da die Verläßlichkeit von Programmen bei weitem noch nicht den entsprechenden Stand der Hardware erreicht hat. Zwar gibt es schon eine Reihe bewährter Me­ thoden und Richtlinien wie z. B. [7], die ihre Nützlichkeit für die Entwicklung und Validierung von Programmen zur Steuerung sicherheitskritischer technischer Pro­ zesse erwiesen haben, jedoch können diese Maßnahmen beim derzeitigen Stand der Technik die Korrektheit größerer Programme noch nicht garantieren.

Dieses Problem wird durch die in den Patentansprüchen aufgeführten Merk­ male gelöst. Es wird die Architektur eines spezialisierten Mehrrechnersystems definiert, das im Rahmen verteilter Prozeßleitsysteme und speicherprogrammier­ barer Steuerungen sicherheitsbezogene Funktionen wahrnehmen kann.

In diesem durchgehend zweikanalig ausgelegten Mehrrechnersystem lassen sich Hardware-Fehler erkennen. Die Verantwortung dafür und zur Einleitung von Notabschaltungen obliegt darin neuartigen Vergleichern mit ausfallsicher­ heitsgerichtetem Ausgabeverhalten nach Patentanspruch 3, die den Geschwin­ digkeitsansprüchen von Rechnern genügen. Letzteres wird erreicht, indem zwei zu vergleichende Binärworte zunächst parallel einer zweikanaligen Vorverarbei­ tungseinheit zugeführt werden, die den Vergleich der Worte auf den zweier Bits reduziert. In einer ursprünglich zum Vergleich analoger Signale entwickelten, je­ doch durch Verwendung optoelektronischer Bauelemente dem Einsatz in der Digi­ taltechnik angepaßten, ausfallsicherheitsgerichteten Schaltung werden diese Bits verglichen. Durch Einführung von Speicherverhalten in die Vergleicherschaltung wird schließlich ermöglicht, herkömmliche, langsame ausfallsicherheitsgerichtete Logikbaugruppen in der Endstufe anzusteuern.

Ihr Schwergewicht legt die Erfindung jedoch darauf, die Verläßlichkeit von Anwenderprogrammen durch Merkmale der Architektur sicherzustellen. Ihre Ori­ ginalität besteht darin, auf einem Niveau formulierte Programme, das dem von Spezifikationen entspricht und damit deutlich über dem herkömmlicher höhe­ rer Programmiersprachen liegt, gemäß Patentanspruch 1 unmittelbar auf die ausführende Hardware abbilden zu können, wodurch die sonst für Rechner cha­ rakteristische semantische Lücke zwischen Software-Anforderungen und Fähig­ keiten der Ausführungsumgebung vermieden und ein Betriebssystem als mögli­ che Fehlerquelle eliminiert wird. Bei dem so unterstützten Programmierverfah­ ren handelt es sich um die in vielen Automatisierungsanwendungen eingesetz­ ten Funktions- und Ablaufpläne nach IEC 1131-3 [8] ergänzt um die Verwen­ dung von Bibliotheken typgeprüfter Funktionsblöcke im Sinne dieser Norm. Die Programmausführung wird auf zwei verschieden geartete Rechner verteilt, von de­ nen der eine Funktionsblockaufrufe bearbeitet, während der andere durch Funk­ tionspläne dargestellte Datenflüsse zwischen Funktionsblöcken und durch Ab­ laufpläne beschriebene Schrittfolgen umsetzt. Indem jedem solcher Schritte die gleiche Bearbeitungsperiode zur Verfügung gestellt wird und alle Datenein- und -ausgaben jeweils zu Beginn bzw. am Ende der Periode vorgenommen werden, stellt sich das Ausführungszeitverhalten des Mehrrechnersystems nach außen hin als vollständig vorhersehbar dar.

Gemäß Patentanspruch 2 sieht die Erfindung erstmalig in der Rechnertechnik die Unterstützung der Verifikation sequentieller Rechnerprogramme als Merk­ mal von Architekturentwurf und Hardware-Konstruktion vor. Orientiert an den graphischen Hochsprachen Funktions- und Ablaufplan wird für einen der beiden Rechner ein sehr kleiner Befehlssatz definiert. Darin ausgedrückte Maschinenpro­ gramme lassen sich durch von Menschen auszuführende Programminspektionen sehr leicht, schnell und mit geringem Aufwand unmittelbar in eine graphische Form übersetzen, die direkten Vergleich mit ihren ursprünglichen Spezifikationen erlaubt. So wird auch das Problem gelöst, daß es noch nicht möglich ist, die korrekte Arbeitsweise eines Übersetzers streng nachzuweisen.

Der wesentliche mit der Erfindung erzielte Vorteil besteht darin, erstmals die sicherheitstechnische Abnahme eines vollständigen programmierbaren elektroni­ schen Systems einschließlich der Anwenderprogramme zu ermöglichen. Bei der Konstruktion wurde besonderes Augenmerk auf den Software-Aspekt gelegt, da die Verläßlichkeit von Software noch lange nicht das hohe Niveau erreicht hat, das für Hardware bereits als selbstverständlich angesehen werden kann. Damit verfolgt das Architekturkonzept ein für die Rechnertechnik völlig neues Optimie­ rungskriterium, und zwar sicherheitstechnische Abnehmbarkeit, im Gegensatz zum herkömmlichen Streben nach höherer Verarbeitungsgeschwindigkeit.

Durch die Architektur des programmierbaren elektronischen Systems nach Pa­ tentanspruch 1 werden Einsatz und Wiederverwendung vorgefertigter und stan­ dardisierter Programmkomponenten und somit Programmierdisziplin erzwungen. Dieses Verlassen der Tradition der klassischen und maximale Flexibilität erlau­ benden von-Neumann-Architektur zeitigt den Vorteil, Fehlermöglichkeiten dra­ stisch einzuschränken und inhärent sicherer zu sein.

Die schematische Beschreibung logischer und funktionaler Beziehungen durch Symbole und konzeptionelle Signalflüsse darstellende Verbindungslinien in Funktions- und Ablaufplänen garantiert leichte Verständlichkeit. Weitere Vorteile dieses von der Erfindung unterstützten Programmierverfahrens sind Orientierung an der Denkweise von Ingenieuren, Klarheit und inhärenter Dokumentationswert. Die Anzahl der Lösungsmöglichkeiten für ein gegebenes Problem wird durch gra­ phische, funktionsblockorientierte Programmierung gegenüber textueller Formu­ lierung deutlich reduziert. Deshalb eignet sich die Methode insbesondere für Anwendungen mit Sicherheitsverantwortung.

Das von der Architektur nach Patentanspruch 1 unterstützte Verfahren der Inspektion zur Verifikation von Anwendungsprogrammen ähnelt stark der diver­ sitären Rücktransformation nach [10]. Im Gegensatz zu letzterer kann sie jedoch auf Grund der Merkmale nach Patentanspruch 2 sehr wirtschaftlich, d. h. effizient und kostengünstig, durchgeführt werden. Somit bleibt der Prüfaufwand immer gering. Weitere Vorteile bestehen darin, daß sie keine Spezialkenntnisse erfordert und allgemeinverständlich ist, weshalb sie von Automatisierungsingenieuren und TÜV-Prüfern leicht eingesetzt werden kann. Die Allgemeinverständlichkeit ist auch besonders im Hinblick auf Rechtsstreitigkeiten von großer Bedeutung.

Der Vergleicher für zwei Binärworte nach Patentanspruch 3 mit ausfallsi­ cherheitsgerichtetem Ausgabeverhalten ermöglicht überhaupt erst den sinnvollen Einsatz von Rechnern in sicherheitsgerichteten Automatisierungsanwendungen. Während die Arbeitsgeschwindigkeit herkömmlicher, ausfallsicherheitsgerichteter Logikbaugruppen nur etwa der festverdrahteter Relais-Steuerungen entspricht, kann der schnelle Vergleicher mit der Geschwindigkeit der Rechner in der Mehr­ rechnerarchitektur mithalten und wird so nicht zum Flaschenhals des Systems.

Ähnlich wie in der chemischen Verfahrenstechnik [11] reichen auch in ande­ ren industriellen Anwendungsgebieten relativ kleine Funktionsblockbibliotheken zur Formulierung aller bereichsspezifischen Automatisierungsaufgaben aus. So werden für Notabschaltsysteme sogar nur vier Funktionsblöcke benötigt. Um auf der Basis solcher Funktionsblockbibliotheken sicherheitsbezogene Automatisie­ rungsprogramme graphisch in der Sprache Funktionsplan entwickeln zu können, müssen die Elemente einer Funktionsblockbibliothek vor ihrer Freigabe im Rah­ men einer Typprüfung einmalig abgenommen werden. Deshalb ist später zur Verifikation auf der Basis von Funktionsblöcken konstruierter Anwendungspro­ gramme allein die korrekte Verknüpfung der vorkommenden Funktionsblockin­ stanzen nachzuweisen. Der Korrektheitsnachweis der Elemente einer Funktions­ blockbibliothek ist aufwendig und kann nur von Spezialisten durchgeführt wer­ den. Dieser Aufwand ist jedoch durch die Sicherheitsanforderungen gerechtfertigt und hält sich für jede einzelne Anwendung wegen der Wiederverwendbarkeit der Bibliotheken in Grenzen. Im Gegensatz dazu unterstützt die Architektur nach Patentanspruch 1 das allgemeinverständliche Verfahren der Inspektion zur Veri­ fikation der Anwendungsprogramme.

Zum Zwecke der strengen Verifikation einer Funktionsblockbibliothek läßt sich eine Reihe bereits eingeführter Methoden anwenden. Dazu gehören formale Verifikationstechniken, die insbesondere in sicherheitskritischen Anwendungsbe­ reichen eine inzwischen akzeptierte und teilweise sogar als notwendig erachtete Vorgehensweise zur Erzielung verläßlicher Programme sind [15]. Als die wohl am weitesten entwickelte Methode sei hier nur auf den auf Hoare und Dijkstra zurückgehenden Prädikatenkalkül [2, 3] hingewiesen. Entsprechende Beweise sind wegen der für automatisierungstechnische Anwendungen typischen relativ gerin­ gen Komplexität der Funktionsblöcke, die weder unbeschränkte Iterationen noch Rekursionen enthalten und deren Quellcodes bei Formulierung in einer höheren, textuellen Programmiersprache in keinem Fall länger als zwei Seiten sind, ihrer einfachen Datenstrukturen (Bitfolgen, logische Daten, ganze und reelle Zahlen) und der in den Algorithmen verwendeten einfachen Sprachkonstrukte auch unter Praxisbedingungen beherrschbar.

Die formale Verifikation von Übersetzern, die in Hochsprachen und somit auch in Funktions- und Ablaufplan formulierte Programme in Objektcode trans­ formieren, ist beim derzeitigen Stand der Technik noch nicht möglich. Deshalb muß sicherheitstechnischen Abnahmen von Programmen zwingend deren Objekt­ code zugrunde liegen, denn diese und nur diese Programmdarstellung wird ma­ schinell ausgeführt. Dieses Problem wird mittels der Rechnerorganisation nach Patentanspruch 2 gelöst. Weil aus bereits verifizierten Funktionsblöcken zusam­ mengesetzte Anwenderprogramme nur aus Parameterübergaben und Unterpro­ grammauftufen bestehen, sind sie um Größenordnungen kürzer und einfacher als herkömmliche Programme. Weiterhin weist die Architektur nach Patentanspruch 1 auf Grund ihrer Konstruktion keine semantische Lücke zwischen den Ebenen auf, die die Schnittstellen zum Menschen einerseits und zur Maschine andererseits darstellen. Darum ist es möglich, durch Inspektion von Maschinencode in einem einzigen und einfachen Arbeitsschritt eine äquivalente Darstellung in Form von Funktions- und Ablaufplänen zu erstellen, die die Qualität und das Niveau ei­ ner anwendungsgerichteten Problemspezifikation hat und die wiederum durch In­ spektion mit dem zu implementierenden, hochsprachlich formulierten Programm verglichen werden kann.

Da es in sicherheitsgerichteten Anwendungen nicht das Ziel sein kann, ohne­ hin immer geringer werdende Hardware-Kosten zu sparen, sondern die Verständ­ lichkeit - für den Menschen - von Automatisierungsprogrammen und ih­ res Ausführungsprozesses zu fördern, werden gemäß Abb. 1 in der Architek­ tur des programmierbaren elektronischen Systems nach Patentanspruch 1 kon­ zeptionell zwei Prozessoren vorgesehen, und zwar ein Funktions- und Ablauf­ planprozessor und ein Funktionsblockprozessor, die als separate physikalische Einheiten realisiert werden. Derart wird eine klare, physische Trennung der Funktionsblockbearbeitung im Funktionsblockprozessor von den anderen Aufga­ ben Ausführungssteuerung, Ablaufplanverarbeitung und Funktionsblockaufrufe, die dem Funktions- und Ablaufplanprozessor zugewiesen sind, erzielt. Die ei­ nerseits durch einmalige Bereitstellung von Funktionsblöcken und andererseits durch deren Verwendung in anwendungsspezifischen Diagrammen gekennzeich­ nete zweistufige Funktionsplanprogrammierung wird so direkt auf die Hardware- Architektur abgebildet. Dadurch ergibt sich die Möglichkeit, Funktionsblock­ prozessoren mit ihrer gesamten Software im Rahmen einer einzigen Typprüfung sicherheitstechnisch abzunehmen. Das Konzept stellt sicher, daß sich Anwen­ dungsprogramme allein im Funktions- und Ablaufplanprozessor befinden, auf den sich deshalb die projektspezifische Verifikation der einen Datenfluß implementie­ renden Funktionsblockverbindungen beschränken kann. Auf Grund der Natur der Software-Entwicklungsmethode bleibt der Prüfaufwand dabei immer gering.

Um Fehlfunktionen der Hardware feststellen zu können, wird durchgängig eine zweikanalige Architektur gewählt, die es auch erlaubt, Diversität in Form verschiedener Funktions- und Ablaufplan- und unterschiedlicher Funktionsblock­ prozessoren vorzusehen. Alle Verarbeitungen erfolgen grundsätzlich paralle! red­ undant auf jeweils zwei Prozessoren und alle zwischen den Prozessoren sowie nach außen hin übertragenen Daten werden einem Vergleich unterzogen. Wenigstens einer der Funktions- und Ablaufplanprozessoren sollte die im folgenden beschrie­ bene extrem einfache Organisation mit nur acht Maschinenbefehlen haben, die die Software-Prüfung durch Inspektion erheblich erleichtert. So ergibt sich die in Abb. 2 dargestellte asymmetrische und fehlererkennende Vierprozessorkonfigura­ tion aus zwei Prozessorpaaren.

Um aus Sicherheitsgründen jedwede Modifikationen durch Fehlfunktionen oder äußere Eingriffe zu verhindern, sieht die Architektur des programmierbaren elektronischen Systems grundsätzlich Nurlesespeicher für Objektcode vor, d. h. es gibt keinen RAM-Bereich für Programme. Der Code der Funktionsblöcke wird als Firmware der Funktionsblockprozessoren in maskenprogrammierten ROMs bereitgestellt, die unter Aufsicht der Lizensierungsinstanzen herzustellen und von diesen freizugeben sind. Dagegen werden die Anwenderprogramme auf der Funktions- und Ablaufplanebene vom Benutzer in PROMs abgelegt. Dieser Teil der Software muß dann noch projektspezifischer Verifikation unterzogen werden, die wiederum von den Lizensierungsbehörden durchgeführt wird, welche schließ­ lich die PROMs in den Zielsystemen versiegeln. Dies zeigt sehr deutlich, daß die asymmetrische Mehrrechnerkonfiguration gewählt wurde, um zwei Systemteile physisch voneinander zu trennen: einen, dessen Software nur genau einmal verifi­ ziert werden muß, und ein anderer mit den anwendungsspezifischen Programmen.

Die Funktionsblockprozessoren führen alle Datenmanipulationen und Ein- /Ausgabeoperationen aus. Funktions- und Ablaufplanprozessoren einerseits und Funktionsblockprozessoren andererseits kommunizieren untereinander über zwei FIFO-Puffer. In diese FIFO-Puffer integrierte ausfallsicherheitsgerichtete Ver­ gleicher überprüfen die Datenströme zur Fehlererkennung in der zweikanaligen Konfiguration. Zur Programmausführung koordinieren sie sich wie folgt. Der Funktions- und Ablaufplanprozessor beauftragt den Funktionsblockprozessor mit der Ausführung eines Funktionsblocks, indem er den Bezeichner, die entsprechen­ den Eingabeparameter und gegebenenfalls auch die internen Zustände des Blockes über einen der FIFO-Puffer dem Funktionsblockprozessor zuschickt. Dort wer­ den das den Funktionsblock implementierende Objektprogramm ausgeführt und die berechneten Ergebnisse und neuen internen Zustände dem Funktions- und Ablaufplanprozessor über den anderen FIFO-Puffer zurückgesandt. Die Bearbei­ tung des Funktionsblockes endet mit dem Auslesen des Ausgabe-FIFOs und dem Ablegen der Daten im Speicher des Funktions- und Ablaufplanprozessors.

Mit dem Vorsehen der FIFO-Puffer wurde das Entwurfsziel verfolgt, einfach zu synchronisierende und leicht verständliche Verbindungen bereitzustellen, wel­ che die Funktions- und Ablaufplanprozessoren hinsichtlich der bearbeiteten Pro­ gramme und Ausführungsgeschwindigkeiten problemlos völlig von den Funktions­ blockprozessoren entkoppeln. Jeder FIFO-Puffer besteht aus einem warteschlan­ genähnlichen Speicher und den zwei Ein-Bit-Statusregistern VOLL und LEER, die den Füllungszustand des FIFOs anzeigen und nicht benutzerzugänglich sind. Sie werden durch die FIFO-Steuerungslogik gesetzt und zurückgesetzt und be­ wirken im gesetzten Zustand, daß die Ausführung eines einen FIFO-Ein- bzw. -Ausgang ansprechenden Befehls verzögert wird.

In handelsüblichen speicherprogrammierbaren Steuerungen variiert die Ausführungszeit eines Schrittes i.a. von einem Zyklus zum nächsten in Abhängig­ keit von der Programmlogik und den jeweils angetroffenen externen Bedingun­ gen. Deshalb erfolgen Erfassung externer Signale und Ausgabe von Aktordaten gewöhnlich nicht zu äquidistant angeordneten Zeitpunkten, obwohl dies von der Problemstellung her so vorgesehen sein mag. Um das Zeitverhalten des pro­ grammierbaren elektronischen Systems völlig deterministisch zu gestalten, wird ein vom Systemzeitgeber abgeleiteter Grundtakt als Zeitreferenz der für spei­ cherprogrammierbare Steuerungen typischen Betriebsart eingeführt. Dieser Takt markiert den für die Ausführung aller Schritte im Sinne von Ablaufplänen vor­ gesehenen Zeitrahmen. Die Länge der Taktperiode wird so gewählt, daß sie der maximalen Ausführungszeit der in einer Anwendung oder Anwendungsklasse vor­ kommenden Schritte Rechnung trägt. Es wird überwacht, daß die Ausführungs­ zeit jedes Schrittes die Taktperiode nicht überschreitet, indem am Ende der Be­ arbeitung der mit einem Schritt assoziierten Aktion und nach der Auswertung der entsprechenden Transitionsbedingung die Ankunft des Taktsignals abgewar­ tet wird, das den Beginn des nächsten Zyklus markiert. Eine Überlastsituation oder ein Laufzeitfehler liegt vor, wenn das Taktsignal ein aktives Anwendungs­ programm unterbricht, woraufhin eine Notabschaltung eingeleitet wird.

Obwohl der Grundtakt die periodische Ausführung der einzelnen Schritte a priori exakt festlegt, können die Verarbeitungszeitpunkte einzelner Operatio­ nen innerhalb einer Periode immer noch variieren und bleiben so unbestimmt. Da genau festgelegtes Zeitverhalten jedoch nur nach außen hin, d. h. für Ein- /Ausgabeoperationen, wichtig ist, wird Vorhersehbarkeit dadurch erreicht, daß diese unabhängig arbeitenden, mit dem Takt synchronisierten Peripheriegeräten zugewiesen werden. Die Eingabegeräte stellen ständig aktuelle Eingabedaten be­ reit, die alle jeweils zu Beginn der Verarbeitungsperioden en bloc übernommen werden, unabhängig davon, ob sie in einer bestimmten Periode gebraucht wer­ den oder nicht. Die so erfaßten Daten werden zwischengespeichert und stehen somit jederzeit unmittelbar zur Verarbeitung bereit. Ebenso werden alle berech­ neten Ausgabedaten zunächst gepuffert und schließlich am durch den nächsten Taktimpuls markierten Periodenende gemeinsam zur Ausgabe freigegeben.

Der Funktions- und Ablaufplanprozessor führt die in seinem PROM-Speicher abgelegten Programme aus. Neben diesem Programmspeicher umfaßt sein li­ nearer Adreßraum auch einen RAM-Bereich. Er besitzt weiterhin die - Pro­ grammierern unzugänglichen - Register Programmadreßzähler (PZ) zur Angabe der PROM-Adresse der jeweils auszuführenden Instruktion, Eingang des FIFO- Puffers zum und Ausgang des FIFO-Puffers vom Funktionsblockprozessor, Tran­ sitionsbedingung (TB), Anfangsadresse des nächsten Schrittes (ANS) sowie einen vom Grundtakt im Rahmen der Zeitüberwachung gesetzten Merker (ST), der an­ zeigt, ob der nächste Periodentakt bereits eingetroffen ist. Zur Wahrnehmung seiner Aufgaben benötigt der Prozessor lediglich den in Tabelle 1 aufgeführten Befehlssatz. Ausführung der lesend auf das FIFO-Ausgangsregisters zugreifenden Befehle impliziert, daß der Prozessor warten muß, sofern der FIFO-Puffer leer ist. Analog muß er beim Schreiben in das FIFO-Eingangsregister warten, wenn die­ ses voll ist. Im Rahmen der Ausführung aller Instruktionen mit Ausnahme des SRT-Befehls wird der Programmzähler inkrementiert.

Der Befehlssatz wurde unter den Gesichtspunkten minimalen Umfangs bei gleichzeitiger optimaler Unterstützung von Menschen durchzuführender Programminspektionen definiert. Die acht Befehle des Satzes sind alle vom Typ Datentransfer, die in zwei Fällen bedingt auszuführen sind. Deshalb kann die Steuereinheit des Funktions- und Ablaufplanprozessors in Form eines endlichen Moore-Automaten mit bedingter Auswahl implementiert werden. Da diese se­ quentielle Schaltung nur recht wenige Eingänge und innere Zustände besitzt und ihre Komponenten zur Erzeugung von Adressen und Ausgaben rein kombinato­ risch sind, läßt sich die Steuereinheit durch vollständigen Test verifizieren.

Die vom Funktions- und Ablaufplanprozessor auszuführenden Programme bestehen aus Abfolgen von Schritten im Sinne der Ablaufplansprache. Dabei sind nur lineare Schrittfolgen und Alternativverzweigungen solcher Sequenzen wie in Abb. 3 dargestellt zugelassen. Aus Sicherheitsgründen müssen die in der Norm IEC 1131-3 [8] ebenfalls eingeführten Parallelverzweigungen entweder mit­ tels Hardware-Parallelität implementiert oder bereits beim Entwurf durch expli­ zite Serialisierung aufgelöst werden. Das Programmsegment eines jeden solchen Schrittes endet mit einem SRT-Befehl, der überprüft, ob das Segment innerhalb der Taktperiode ausgeführt wurde. War dies nicht der Fall, so wird ein Notab­ schaltungssignal erzeugt. Terminiert die Segmentausführung jedoch vor Ankunft des nächsten Periodentaktimpulses, so wartet der Prozessor bis zum Ende der andauernden Periode. Wenn das Taktsignal schließlich eintrifft, werden der Pro­ grammzähler aus dem Register ANS mit der Anfangsadresse des dem nächsten auszuführenden Schritt zugeordneten Segmentes geladen und das Transitionsbe­ dingungsregister TB gelöscht. Geladen wird das Register TB mit vom Funkti­ onsblockprozessor erarbeiteten logischen Werten im Rahmen der Ausführung von ETB-Befehlen. Wird dabei eine logische Eins empfangen, so wird das Register ANS aus dem Programm-PROM neu geladen. Da Programmverzweigungen nur in dieser äußerst restriktiven Form möglich sind, wird ein sehr effektiver Spei­ cherschutzmechanismus realisiert.

Weil die Inhalte von RAMs nach dem Einschalten der Stromversorgung zufällig sind, muß der RAM-Bereich des Funktions- und Ablaufplanprozessors bei Betriebsbeginn initialisiert werden. Dies erfolgt durch einen Hardware- Mechanismus, der einen (P)ROM ausliest und damit alle Speicherstellen des RAM mit anwendungsspezifischen Anfangswerten vorbesetzt. Weiterhin werden die Register PZ, TB, ANS und ST gelöscht, weshalb das erste in einem Programm auszuführende Segment an der Programmspeicheradresse Null beginnen muß.

Der Vergleich aller zwischen den beiden Funktions- und Ablaufplanprozes­ soren einerseits und den beiden Funktionsblockprozessoren andererseits ausge­ tauschten Daten auf Gleichheit wird von zwei in die FIFO-Puffer integrierten Komparatoren durchgeführt. Sie erkennen alle intermittierenden und dauer­ haften Fehlfunktionen, die sich in Unterschieden zwischen diesen Daten äußern. Sendet einer der Funktions- und Ablaufplanprozessoren auf Grund eines Fehlers einen unvollständigen Parametersatz, so beginnen die Funktionsblockprozesso­ ren nicht zu arbeiten, was zu einem Laufzeitfehler und zur Notabschaltung am Ende der laufenden Verarbeitungsperiode führt. Da den - notwendigerweise einkanalig ausgelegten - Vergleichern in der zweikanaligen Konfiguration die Verantwortung zur Fehlererkennung obliegt, müssen sie höchsten Verläßlichkeits­ anforderungen genügen. Eine auf Software basierende Lösung für diese Aufgabe scheidet aus, da sie, auch wenn sie selbst korrekt wäre, auf jederzeit korrekt ar­ beitende und ausfallfreie Hardware angewiesen wäre. Aus diesen Gründen sind die Vergleicher in ausfallsicherheitsgerichteter Hardware zu realisieren. Um die Arbeitsgeschwindigkeit des Gesamtsystems nicht zu vermindern, müssen die Ver­ gleicher mit der Geschwindigkeit der Datenübertragungen mithalten können, d. h. Vergleiche in wenigen Mikrosekunden durchführen. Weil die marktüblichen aus­ fallsicherheitsgerichteten Komparatoren für einen Vergleich jedoch mehrere Mil­ lisekunden benötigen, bedarf es eines hinreichend schnellen ausfallsicherheitsge­ richteten Vergleichers, wie er im folgenden beschrieben wird.

Nach Abb. 4 ist ein Komparator jeweils mit vier FIFO-Puffern verbunden, zwei eingangs- und zwei ausgangsseitigen. Die jeweils ersten Datenelemente der eingangsseitigen Puffer werden in Halteregistern zwischengespeichert und dann miteinander verglichen. Bei Ungleichheit wird ein Fehlersignal erzeugt, das das gesamte System abschaltet. Andernfalls wird das Datenelement zu den beiden ausgangsseitigen FIFOs weitergeleitet. Die Komparatoren werden durch Par­ allelschaltung aus einem Grundelement zusammengesetzt, das selbst wiederum aus einer Primäreinheit zur Umwandlung der Eingangszustände in alternierende Rechtecksignale und aus einer Sekundäreinheit zum Vergleich letzterer besteht. Die Primäreinheit ist ein aus integrierten Standardbauelementen zusammenge­ setzter und deshalb zweikanalig ausgeführter 4-Bit-Vergleicher, der aber immer noch viel kleiner als ein einkanaliger, diskret aufgebauter Vergleicher für 4 Bits ist, und die Sekundäreinheit ein ausfallsicherheitsgerichteter 1-Bit-Vergleicher. Ist ein Komparator aktiv, sind die Vergleichssignale gleich und arbeiten alle Ele­ mente normal, so führt sein Ausgang logisch Eins. Bei Unterschieden in den Da­ ten oder Hardware-Fehlern wird der Ausgang auf logisch Null gesetzt, was auch der sichere Zustand ist. Dieses Ausgabesignal wird dann bis zu einer expliziten Initialisierung beibehalten.

In der in Abb. 5 dargestellten Primäreinheit vergleichen zwei integrierte Kom­ paratoren U1 und U2 zwei über die Leitungen A0-A3 und B0-B3 von den Halteregistern der FIFO-Puffer angelegte 4-Bit-Worte. Dabei arbeitet U2 mit invertierten Daten. Die Ausgaben an Q1 und Q2 sind gleich, sofern U1 und U2 korrekt arbeiten. Die sich relativ langsam verändernden Eingaben werden in­ nerhalb der Komparatoren mittels der vom Rechteckgenerator US erzeugten und an die Kaskadeneingänge A=B direkt und A<B invertiert angelegten Frequenz in alternierende Signale umgewandelt. Mithin erscheinen an den Ausgängen Q1 und Q2 entweder identische Rechtecksignale, falls die Worte an A0-A3 und B0-B3 gleich sind, oder logisch Null. Das Ausgabeverhalten ist bei Auftreten eines Fehlers innerhalb eines der integrierten Komparatoren nicht vorhersehbar.

Ein Fehler bleibt unerkannt, wenn der Schaltkreis das Rechtecksignal noch un­ verfälscht übertragen kann. Ansonsten nehmen die Ausgänge Q1 und Q2 ver­ schiedene Zustände an, die von den weiteren Schaltungskomponenten erkannt werden, was letztendlich zur Notabschaltung führt.

Die in Abb. 6 dargestellte Sekundäreinheit vergleicht die Ausgangssignale Q1 und Q2 der Primäreinheit. Ihr Entwurf beruht auf dem des Analogsignalverglei­ chers von Schuck [12]. Letzterer formt zwei zu vergleichende Analogsignale in der Eingangsstufe zunächst in bistabile Rechtecksignale um. Dazu wird ein aus Operationsverstärkern und Potentiometern zum Setzen geeigneter Schaltspan­ nungsniveaus aufgebauter analoger Komparator verwendet. Dieser Teil wird in dem Entwurf nach Patentanspruch 3 durch die beiden Optokoppler U1 und U2 ersetzt. Deren Eigenschaft, ihr Ausgangssignal durch Anlegen von logisch Null an Pin 7 abschalten zu können, wird dazu verwendet, die Komparatorausgabe in einen sicheren Zustand zu bringen. Um die Arbeitsgeschwindigkeit des Kompa­ rators zu erhöhen, wurden gegenüber der Schaltung aus [12] die Induktivitäten aller Übertrager und die Kapazität des Kondensators C1 modifiziert sowie der Kondensator C7 entfernt. Das wichtigste neue Merkmal des Vergleichers nach Patentanspruch 3 ist der selbsthaltende sichere Zustand, den er nach Erkennen beliebiger Signalunterschiede oder eigener Fehlfunktionen annimmt. Dies wird durch Steuerung des Durchschaltens der Eingangssignale durch die Optokopp­ ler mit Hilfe des Ausgangssignals VGL erreicht. Dadurch wird der Vergleicher als Ganzes zu einem Speicherglied, ist also nicht mehr nur eine kombinatorische Schaltung wie die nach [12]. Dieses Speicherverhalten ist erforderlich, um das nachgeschaltete und viel langsamer arbeitende ausfallsicherheitsgerichtete Gat­ ter vom Typ F3105 in HIMA-Planar-Logik in die Lage zu versetzen, sich in sehr kurzen Änderungen im Ausgangssignal des Vergleichers ausdrückende Datenin­ konsistenzen überhaupt erkennen zu können.

Durchschalten der Signale Q1 und Q2 durch die Optokoppler U1 und U2 erfordert Logisch-Eins-Zustand am Abgriff des Potentiometers PR1, der mit den Optokoppler-Pins 7 verbunden ist. Wegen seines Speicherverhaltens muß der Vergleicher nach dem Einschalten mit dem Signal RESET initialisiert werden. Dazu wird PR1 über das Relais PK1 mit der Spannung UC verbunden. Wenn die ganze Einheit aktiviert ist und am Ausgang VGL logisch Eins erscheint, wird zwar das Relais abgeschaltet, jedoch verbleibt die Spannung weiterhin an PR1, jetzt von VGL übertragen über die Dioden D1-D3. Andererseits lassen diese die Spannung UC bei eingeschaltetem Relais nicht zum Ausgang VGL durch. Bei fehlender Aktivierung liegt an PR1 keine Spannung an, weshalb die Optokoppler U1 und U2 gesperrt bleiben und somit den Ausgang VGL im Zustand logisch Null halten.

Nach Verstärkung durch die Transistoren T1 und T3 beeinflussen die recht­ eckförmigen Ausgangssignale der Optokoppler U1 und U2 die Transistoren T2 und T4, die in ihren Emitterkreisen die Ubertrager TR1 und TR2 enthalten.

In deren Sekundärwindungen werden Impulse erzeugt, die die Transistoren T5 und T6 kurzzeitig leitend werden lassen. Dies erfolgt gleichzeitig, falls die Ein­ gangssignale Q1 und Q2 identisch sind, wodurch Oszillationen in dem aus dem Kondensator C1 und der Primärwindung des Übertragers TR3 gebildeten Reso­ nanzkreis ausgelöst werden. Die Schwingungen werden von TR3 übertragen und durch die Transistoren T9 und T10 verstärkt, sofern diesen Energie zugeführt wird, was von der Schwingungsübertragung durch die beiden anderen, aus den Transistoren T7 und T8 bzw. T11 und T12 gebildeten, Verstärker abhängt, die die Übertrager TR4 und TR5 zur Energieübertragung benutzen. Natürlich die­ nen letztere gleichzeitig auch zur galvanischen Trennung. Das vom Transistor T10 erzeugte Signal wird von T13 verstärkt und vom Übertrager TR6 an den Gleichrichter GL3 weitergegeben. Der Kondensator C2 dient zusammen mit R0 zur Filterung. Die an C2 anliegende Spannung stellt das Ausgabe- und Steue­ rungssignal VGL der Optokoppler U1 und U2 dar. Der Kondensator C2 wird fortwährend mit den an TR1 und TR2 erscheinenden Pulsen ge- und über den Eingangswiderstand R0 des nachgeschalteten F3105-Gatters und das Potentio­ meter PR1 entladen.

Verschwinden eines oder beide der Signale Q1 und Q2 vorübergehend oder andauernd, geraten diese Signale aus der Phase oder fällt ein Bauelement aus, so erreicht die Rechteckfrequenz die Übertrager TR1 und TR2 nicht mehr, es werden keine Schwingungen erzeugt und die Spannung an C2 fällt ab. Dadurch werden die Optokoppler U1 und U2 gesperrt, was diese Spannung ganz auf Null bringt. Der Ausgang VGL verbleibt dann im Zustand logisch Null, bis das Relais PK1 zur Initialisierung geschaltet wird.

Das vom Generator U5 in der Primäreinheit erzeugte Rechtecksignal hat die Frequenz 100 kHz. Der Vergleicher ist sehr empfindlich: sein Ausgang VGL geht auf Null, sobald die Sekundäreinheit einen Impuls nicht mehr überträgt. Des­ halb sind 10 µs die kürzeste Vergleichszeit. Der sichere Zustand wird wegen der exponentiellen Entladung des Kondensators C2 nach etwa 40 µs angenom­ men. Die nachgeschalteten HIMA-Module reagieren nach 10-20 ms, indem sie das Gesamtsystem abschalten und seine Prozeßausgänge in den sicheren Zustand überführen.

Auch die von Funktionsblockprozessoren erzeugten Ausgabedatenworte müssen vor dem Aussenden an externe technische Prozesse mit Hilfe ausfallsi­ cherheitsgerichteter Komparatoren auf Gleichheit überprüft werden. An diese werden jedoch wesentlich geringere Geschwindigkeitsanforderungen gestellt, da Ausgaben mit der Frequenz des Taktes der Schrittperiode erfolgen. Deshalb kann für diese Anwendung auf marktübliche Komponenten [6, 4] zurückgegrif­ fen werden. Die von beiden Funktionsblockprozessoren erzeugten Ausgabeda­ tenworte werden zuerst verglichen, bevor sie in Ausgangshalteregister gebracht werden. Bei Ungleichheit wird wieder ein Notabschaltungssignal erzeugt. Die Ausgabedaten werden erst mit Beendigung der aktuellen Verarbeitungsperiode freigegeben. Auch die vom technischen Prozeß kommenden Eingabedaten gelan­ gen zunächst in Halteregister. Erst mit dem nächsten Taktimpuls werden sie beiden Funktionsblockprozessoren bereitgestellt.

Jedes der oben beschriebenen 4-Bit-Komparatormodule und jeder Vergleicher von Prozeßausgabedaten erzeugt sein eigenes Korrektheitssignal, das bei Fehl­ funktionen zur Notabschaltung des Gesamtsystems führen soll. Dazu verarbeitet die in Abb. 7 dargestellte, mit ausfallsicherheitsgerichteten Logikelementen aus dem HIMA-Planar-System aufgebaute Schaltung diese Signale zu einem globa­ len Korrektheitssignal OK, das bei Annahme des Nullzustandes alle Prozessoren anhält und die Prozeßausgaben in den sicheren Zustand überführt. Das Modul wird nach dem Einschalten mit dem Signal HIMA_RESET initialisiert, das vom Optokoppler OP und einem Eingangsverstärker vom Typ F3105 an die aus ei­ nem Oder- und einem Und-Gatter in einem Baustein des Typs F3317 aufgebaute Leistungsendstufe weitergeleitet wird. Ihr Ausgang OK ist logisch Eins, wenn sowohl HIMA_RESET und der Ausgang des Und-Gatters vom Typ F4112 logisch Eins sind. Dieses Gatter faßt die Ausgaben der den Datenaustausch über die FIFO-Puffer überwachenden schnellen Vergleicher (VGL1, VGL2) und die Kon­ sistenzsignale der Prozeßausgabedaten zusammen. Durch Rückkopplung von OK in das Oder-Gatter des Bausteins F3317 bleibt OK nach dem Verschwinden von HIMA_RESET im Zustand logisch Eins. Jede zu einem Spannungsabfall an min­ destens einem der Eingänge des Bausteins F4112 führende Fehlfunktion läßt das OK-Signal den Zustand logisch Null annehmen.

Die Durchführung strenger Verifikation auf dem oben beschriebenen program­ mierbaren elektronischen System für Sicherheitsaufgaben ablaufender Anwender­ programme durch Inspektion wird nun anhand eines ausgearbeiteten relativ ein­ fachen, aber sehr typischen Beispiels dargestellt. Die beiden äquivalenten Dar­ stellungsformen eines Programmes, nämlich Funktionsplan und Maschinencode für den Funktions- und Ablaufplanprozessor der Architektur, werden im Detail gezeigt. Es wird deutlich werden, daß es sehr leicht unmittelbar möglich ist, nach einem gegebenen Maschinenprogramm einen entsprechenden Funktionsplan zu zeichnen.

Abb. 9 zeigt ein typisches industrielles Automatisierungsprogramm in graphi­ scher Form, welches einen Behälterdruck regelt und überwacht und das die einem Schritt in einem, ähnlich dem in Abb. 8 wiedergegebenen und [11] entnommenen, Ablaufplan zugeordnete Aktion zusammen mit der Berechnung der nachfolgen­ den Transitionsbedingung darstelle. Das Programm ist durch Zusammenschal­ tung in der Richtlinie [11] definierter Standardfunktionsblöcke formuliert. Eine analog gemessene Variable, die zu regelnde Größe, wird vom Eingabekanal mit der Adresse INADR durch einen Funktionsblock des Typs IN_A erfaßt und zu einer physikalischen Größe mit der Einheit XUNIT im Bereich zwischen XMIN und XMAX skaliert. Die zu regelnde Variable wird an einen Funktionsblock des Typs C weitergegeben, der eine Proportional-Integral-Differential-Regelung unter Verwendung der Regelparameter KP, TN und TV durchführt. Die resultierende Stellvariable wird durch einen Ausgabefunktionsblock vom Typ OUT_A in einen Analogwert konvertiert und auf den durch OUTADR adressierten Kanal geschal­ tet. Zusätzlich wird die geregelte Variable mit Hilfe zweier Instanzen des Stan­ dardfunktionsblocktyps SAM zur Grenzwertüberwachung beobachtet, um festzu­ stellen, ob sie zwischen den von den beiden Parametern ls und hs vorgegebenen Bereichsgrenzen liegt. Wenn die geregelte Variable diesen Bereich überschrei­ tet, wird eine der QS-Ausgaben der beiden SAM-Instanzen und somit auch die Ausgabe des Funktionsblocks vom Typ OR logisch wahr, der die Disjunktion implementiert. Dies wiederum bewirkt, daß zum nächsten Schritt übergegangen wird, da hier der Ausgang des OR-Funktionsblocks zum Setzen der Transitions­ bedingung verwendet wird. Den Eingängen der Funktionsblöcke, die weder von extern sichtbaren Eingängen des Programmes selbst noch intern von Ausgängen anderer Funktionsblöcke gespeist werden, werden vorgegebene konstante Werte zugewiesen.

Das graphische Beispielprogramm sei nun auf irgendeinem Wege in den in Abb. 10 in Form einer leicht lesbaren mnemonischen Darstellung aufgelisteten Maschinencode des Funktions- und Ablaufplanprozessors übersetzt worden. Von den verschiedenen im Beispiel instanziierten Funktionsblocktypen hat C drei und SAM eine interne Zustandsvariable.

Der in Abb. 10 aufgelistete Maschinencode stellt ein Segment dar. Ein Seg­ ment ist die Einheit der Programmausführung während der Taktperiode eines Schrittes und besteht aus einer sequentiellen Abfolge von Aufruffolgen, die sich wiederum aus den Maschinenbefehlen SID, SKN, SVR, SIZ, EVR, EIZ und ETB des Funktions- und Ablaufplanprozessors nach Tabelle 1 zusammensetzen, ge­ folgt und abgeschlossen durch eine SRT-Instruktion. Ein Programm hat minde­ stens ein Segment. Die Anzahl der Segmente entspricht der der Schritte. Jeder in einem Funktionsplan erscheinenden Funktionsblockinstanz entspricht genau eine Aufruffolge. Mit ihr werden Parameter und gegebenenfalls interne Zustände vom Funktions- und Ablaufplanprozessor zum Funktionsblockprozessor übertra­ gen und nach Ausführung des Funktionsblocks die berechneten Ergebnisse und eventuell neue interne Zustände in Empfang genommen.

Eine Aufruffolge beginnt mit einer SID-Instruktion, die den Bezeichner (z. B. ID-C) des jeweiligen Funktionsblockes zum Funktionsblockprozessor überträgt. Danach werden die Eingabeparameter des bezeichneten Funktionsblockes bereit­ gestellt. Dies erfolgt für Konstanten mit SKN-Befehlen. Variablen und Zwischen­ werte werden mit SVR- und, sofern vorhanden, Werte interner Funktionsblock­ zustände mit SIZ-Befehlen von ihnen zugeordneten RAM-Speicherstellen gelesen und zum Funktionsblockprozessor gesandt. Für jede Instanz eines Funktions­ blocks mit internen Zuständen wird eine Menge entsprechend gekennzeichneter (z. B. B2-isv1) Speicherzellen angelegt. Wenn der Funktionsblockprozessor alle diese Parameter erhalten hat, führt er den bezeichneten Funktionsblock aus und liefert die zugehörigen Mengen von Werten an Ausgabeparametern und neuen in­ ternen Zuständen zurück. Diese werden vom Funktions- und Ablaufplanprozessor mittels EVR- bzw. EIZ-Befehlen empfangen und dann in entsprechenden RAM- Zellen abgelegt. Die Anzahl der SKN-, SVR-, SIZ, EVR- und EIZ-Instruktionen ist funktionsblockspezifisch. Sie müssen in einer vorgegebenen Reihenfolge aus­ geführt werden, die die korrekte Zuordnung von Werten zu Parametern und Zuständen auf Seiten beider Prozessoren bestimmt. Eine Verbindung zwischen einem Ausgang eines Funktionsblockes und einem Eingang eines anderen wird mit einem EVR- und einem SVR-Befehl implementiert: der erste speichert den Aus­ gabewert in einer RAM-Zelle für einen temporären Wert (z. B. TMP-X) ab und der zweite lädt ihn von dort. Die Implementierungsdetails der Funktionsblöcke sind Teil der Architektur des Funktionsblockprozessors und bleiben daher auf der Ebene der Anwendungsprogrammierung unsichtbar.

Auf Grund der oben beschriebenen Struktur der Maschinenprogramme des Funktions- und Ablaufplanprozessors stellen sich Inspektion und Rücküberset­ zung von Objektcode als sehr leicht dar. Dazu wird zunächst der Inhalt des (P)ROMs geprüft, aus dem der einem Programm zugeordnete RAM-Bereich in­ itialisiert wird. Dann werden die SRT-Befehle gesucht, die die verschiedenen, den Ablaufplanschritten des Programmes zugeordneten Segmente klar vonein­ ander trennen. Der Code zwischen zwei SRT-Befehlen entspricht genau einem Funktionsplan. Die Rückübersetzung eines solchen Segmentes beginnt mit der Interpretation der ersten Instruktion, die immer ein SID-Befehl sein muß. Sie identifiziert eine in den Funktionsplan einzuzeichnende Funktionsblockinstanz. Vergleicht man die nachfolgenden Befehle mit der entsprechenden, in einer Bi­ bliothek enthaltenen Funktionsblockbeschreibung, so kann die korrekte Parame­ terübergabe leicht nachgeprüft werden. Darüber hinaus wird für jede SKN-, SVR- und EVR-Instruktion eine Verbindung in den Funktionsplan eingezeich­ net. Es gibt zwei Arten von Verbindungen. Die erste sind Verbindungen von Programmeingängen oder Konstanten zu Eingängen von Funktionsblöcken oder von Funktionsblockausgängen zu Programmausgängen. Die zweite Art sind Ver­ bindungen von Funktionsblockausgängen zu benannten Verbindungspunkten im Funktionsplan oder von solchen Punkten zu Funktionsblockeingängen. Wenn ein Funktionsplan vollständig gezeichnet ist, können die Namen dieser Punkte ent­ fernt werden. Für die internen Zustandsvariablen muß nur geprüft werden, daß die neuen, aus einer Ausführung einer Funktionsblockinstanz resultierenden und mit EIZ-Befehlen empfangenen Werte in genau denselben RAM-Stellen abgelegt werden, von denen die internen Zustände im Zuge des entsprechenden Aufrufes mit SIZ-Befehlen gelesen wurden. Der Vorgang der Funktionsblockidentifizie­ rung, der Prüfung der Parameter- und Zustandsübergaben sowie des Zeichnens des Blocksymbols und der entsprechenden Verbindungen wird solange wieder­ holt, bis die nächste SRT-Anweisung erreicht wird, die den Schritt und somit den entsprechenden Funktionsplan beendet.

Enthält ein Segment keinen ETB-Befehl, so wird der entsprechende Schritt als Endlosschleife ausgeführt. Mit einem ETB-Befehl wird das Ergebnis der Be­ rechnung einer Transitionsbedingung als Ausgabewert eines Funktionsblockin­ stanzenaufrufes empfangen und im Transitionsbedingungsregister TB abgelegt. Im Rahmen der Inspektion ist im Funktionsplan eine Verbindungslinie vom ent­ sprechenden Ausgang am Symbol der Instanz zu einem zu markierenden Punkt am rechten Rand des Planes einzuzeichnen. Weiterhin muß die im ETB-Befehl enthaltene Anfangsadresse des Folgesegmentes als Beginn des als nächsten vor­ gesehenen Ablaufplanschrittes verifiziert werden. Enthält ein Segment mehrere ETB-Befehle, so führt dies bei der Rückübersetzung zu ebenso vielen Verbin­ dungspunkten am rechten Funktionsplanrand. Sofern das Register TB während einer Segmentausführung auf 1 gesetzt wurde, wird mit dem Segment fortgefah­ ren, dessen Anfangsadresse von dem ETB-Befehl in das Register ANS geladen wurde, der als letzter TB auf 1 gesetzt hat. Auf diese Art werden Alternativver­ zweigungen in Ablaufplänen implementiert.

Literatur

[1] ABB Industrial Systems: ABB Master Safeguard 3000 Product Guide. Oslo 1994.
[2] Baber, R.L.: Fehlerfreie Programmierung für den Software-Zauberlehrling. München-Wien: Oldenbourg-Verlag, 1990.
[3] Backhouse, R.C.: Programmkonstruktion und Verifikation. München-Wien: Hanser-Verlag, 1989.
[4] GTI Industrial Automation: An Introduction to Maglog 24 Inherently Fail- Safe Logic Technology - Eliminating the Unexpected. Apeldoorn 1993.
[5] Paul Hildebrandt GmbH & Co. KG: Main Catalogue - The HIMA-Planar- System. Brochure HK 90.11. Brühl 1991.
[6] Paul Hildebrandt GmbH & Co. KG: Fail-Safe Electronic Controls - The HIMA-Planar-System. Brochure TI 92.08. Brühl 1992.
[7] Internationale Norm IEC 880: Software for Computers in the Safety System of Nuclear Power Stations. Genf: Internationale Elektrotechnische Kommis­ sion, 1986.
[8] Internationale Norm IEC 1131-3: Programmable Controllers, Part 3: Pro­ gramming Languages. Genf: Internationale Elektrotechnische Kommission, 1992.
[9] Internationaler Normentwurf TC65/WG6(PT1WD)7: Function Blocks for Industrial Process Measurement and Control Systems, Part 1: Architecture. Genf: Internationale Elektrotechnische Kommission, 1996.
[10] Krebs, H., und Haspel, U.: Ein Verfahren zur Software-Verifikation. Rege­ lungstechnische Praxis rtp 26, 73-78, 1984.
[11] Richtlinie VDI/VDE 3696: Herstellerneutrale Konfigurierung von Pro­ zeßleitsystemen. Berlin: Beuth Verlag, 1995.
[12] Schuck, H.: Analoger Fensterkomparator in Fail-safe-Technik. Technische Universität Braunschweig, Braunschweig 1987.
[13] Storey, N.: Safety-Critical Computer Systems. New York: Addison-Wesley) 1996.
[14] TÜV Rheinland, Institut für Software, Elektronik, Bahntechnik: Liste bau­ mustergeprüfter speicherprogrammierbarer Steterungen (List of Type Appro­ ved Programmable Electronic Systems), Version 3.1, Köln, Oktober 1997.
[15] Zentralstelle für Sicherheit in der Informationstechnik: Kriterien für die Be­ wertung der Sicherheit von Systemen der Informationstechnik. Köln: Bun­ desanzeiger, 1989.

Claims (3)

1. Mehrrechnerarchitektur, die in Form von Funktions- und Ablaufplänen formulierte Anwenderprogramme ohne semantische Lücke auf die Ausführungsebene abzubilden erlaubt, dadurch gekennzeichnet, daß die Programmausführung auf zwei verschieden geartete Rechner ver­ teilt wird, von denen der eine Funktionsblockaufrufe bearbeitet, während der andere durch Funktionspläne dargestellte Datenflüsse zwischen Funkti­ onsblöcken und durch Ablaufpläne beschriebene Schrittfolgen umsetzt, und daß kein Betriebssystem benötigt wird.

2. Durch Konstruktion nach Patentanspruch 1 leichte, aber dennoch strenge Nachweisbarkeit der Korrektheit von Anwenderprogrammen, dadurch gekennzeichnet, daß sich in dem an den Hochsprachen Funktions- und Ablaufpläne orientier­ ten, sehr kleinen Befehlssatz eines der beiden Rechner ausgedrückte Maschi­ nenprogramme durch Inspektion unmittelbar in eine graphische Form über­ setzen lassen, die direkten Vergleich mit ihren Programmspezifikationen erlaubt, und daß die dem anderen Rechner zugeordneten Funktionsblöcke als Systemprogramme nur einer einmaligen Typprüfung unterzogen werden müssen.

3. Schneller Vergleicher zweier Binärworte mit ausfallsicherheitsgerichtetem Ausgabeverhalten, dadurch gekennzeichnet, daß durch eine zweikanalige Vorverarbeitungseinheit der Vergleich zweier Binärworte auf den zweier Bits reduziert, daß durch Verwendung optoelek­ tronischer Bauelemente eine ausfallsicherheitsgerichtete Schaltung zum Ver­ gleich analoger Signale dem Einsatz in der Digitaltechnik angepaßt und daß durch Einführung von Speicherverhalten die Ansteuerung herkömmlicher, langsamer ausfallsicherheitsgerichteter Logikbaugruppen in der Endstufe ermöglicht wird.