DE3735682A1 - Einrichtung zum steuern eines stellwerks - Google Patents

Description

Die Erfindung betrifft eine Einrichtung zum Steuern eines Stellwerks gemäß dem Oberbegriff des Patentanspruchs 1.

Derartige Einrichtungen sind heute im Einsatz und bereits mehrfach druckschriftlich veröffentlicht worden (siehe z. B. Aufsatz von N. Siggard und N. Sorensen "Microcomputer Controlled Interlocking System" in Ericsson Review Nr. 3, 1982).

Bei derartigen Einrichtungen wird hohe Betriebssicherheit gefordert. Bei der Verwendung elektronischer Datenverarbeitungsanlagen sind aber nun eine Reihe von Fehlermöglichkeiten gegeben und es bestehen eine Reihe von Vorschlägen, diese Fehlermöglichkeiten zu eliminieren. Die Zuverlässigkeit von elektronischen Datenverarbeitungseinrichtungen kann ganz allgemein durch Verwendung eines fehlertoleranten Rechnersystems erreicht werden, wobei allerdings die Softwaresicherheit das Schlüsselproblem einer Computeranwendung für sicherheitskritische Aufgaben bleibt. Unter der Sicherheit einer derartigen Einrichtung versteht man hierbei die Wahrscheinlichkeit mit der ein System unter gegebenen Bedingungen während eines bestimmten Zeitintervalles arbeitet ohne einen Unfall zu verursachen. Neben dieser Sicherheit muß auch die sogenannte Ausfallsicherheit berücksichtigt werden, wobei hier gilt, daß ein System dann ausfallsicher ist, wenn es bei Entdeckung eines potentiell gefährlichen Fehlers in einen sicheren Zustand gebracht werden kann.

Elektronische Stellwerke sind ein klassisches Beispiel für eine ausfallsichere Echtzeitapplikation. Wann immer eine gefährliche Situation entdeckt wird, kann der Bahnhof (oder Teile davon) in einen ausfallsicheren Zustand gebracht werden, indem die Fahrsignale auf rot geschaltet werden und weitere Ausgabebefehle an die Peripherie (Weichen etc.) unterbunden werden.

Softwarefehler sind immer Entwurfsfehler; bei sicherheitskritischen Systemen sind diese Fehler potentiell gefährlich. Wenn sie nicht während der Entwurfsphase oder zur Laufzeit entdeckt werden, können sie die Systemsicherheit gefährden. Der derzeitige Stand der Softwaretechnologie erlaubt nicht die Entwicklung fehlerfreier Softwaresysteme.

Prinzipiell kann die Sicherheit einer Einrichtung der eingangs genannten Art dadurch erhöht werden, daß ein System mit zwei Softwareversionen eingesetzt wird. Ein derartiges System zeichnet sich gegenüber einem System mit drei Softwareversionen allerdings durch geringere Zuverlässigkeit, wohl aber höhere Sicherheit aus. Obwohl die Verwendung zweier Softwareversionen somit sicherlich höhere Sicherheit gewährleistet als ein Einzelprogramm besteht eine gewisse Wahrscheinlichkeit gemeinsamer gefährlicher Entwurfsfehler.

Die Hauptquelle gemeinsamer Fehler ist die gemeinsame Spezifikation aus der die Programmversionen entwickelt werden. Die Vielfalt in der Implementierung hat auch bedeutenden Einfluß auf die Wahrscheinlichkeit gemeinsamer Entwurfsfehler. Ein schwerwiegender Nachteil des N-Version Programming (NVP) sind sicherlich die Mehrkosten in Entwurf und Implementierung.

Das primäre Entwurfsziel bei der Software eines sicherheitskritischen Systems muß in der Vermeidung gefährlicher Fehler liegen. Entwurfsfehler, die "nur" den normalen Betrieb beeinträchtigen, sind unangenehm, aber nicht gefährlich. Eine mögliche Alternative besteht daher darin, die Verwendung der Entwurfdiversität auf sicherheitskritische Funktionen zu beschränken (z. B. das Wechseln des Signals von rot auf grün ist sicherheitskritisch).

Die serielle Ausführung redundanter Programme auf demselben Rechner leidet unter einem möglicherweise korrilierten Fehlerverhalten (ein Fehler einer Softwareversion könnte z. B. das Betriebssystem durcheinanderbringen). Parallele Ausführung auf getrennten Rechnern verringert die Last und entkoppelt das Fehlerverhalten.

Die Erfindung zielt nun darauf ab, die gegenüber der bloßen Anwendung fehlertoleranter Rechnersysteme oder NVP erzielbaren Vorteile weiter zu verbessern und eine Einrichtung der eingangs genannten Art zu schaffen, welche sich durch erhöhte Sicherheit durch den Einsatz von Echtzeitssystemen in Prozeßsteuerungen auszeichnet. Zur Lösung dieser Aufgabe sieht die Erfindung ausgehend von einer Einrichtung der eingangs genannten Art vor, daß dem frei programmierbaren Schaltwerk ein weiteres frei programmierbares Schaltwerk zugeschaltet ist, welchem Eingangs- und Ausgangssignale des ersten frei programmierbaren Schaltwerkes zur Verarbeitung zugeführt sind und welches unabhängig Ausgangssignale generiert, welche vor der Weiterleitung an die Stellglieder der Peripherie einem Komparator und/oder einer logischen Entscheidungseinheit (Voter), welche auch die Ausgangssignale des ersten frei programmierbaren Schaltwerkes erhalten, zugeführt sind. Das weitere frei programmierbare Schaltwerk bildet hierbei einen Sicherheitsrucksack der ständig die Sicherheit des Steuersystems und dessen Peripherie überwacht. Wann immer ein potentiell gefährlicher Fehler entdeckt wird, muß eine Handlung gesetzt werden, um den Sicherheitsstatus der Applikation aufrecht zu erhalten. Die Sicherheitsrucksack-Technik weist die folgenden Vorteile gegenüber dem konventionellen N-Version Programming auf:

• - Diversität sowohl in Spezifikation als auch Entwurf
• - geringere Komplexität, daher weniger Restfehler
• - niedrigere Entwicklungskosten
• - höhere Sicherheit

Während somit die notwendige Zuverlässigkeit durch Verwendung eines fehlertoleranten Rechnersystems erreicht werden kann, bringt die vorgeschlagene Methode des Sicherheitsrucksackes eine wesentliche Verbesserung der Systemsicherheit. Der vorgeschlagene Sicherheitsrucksack ist hierbei ein autonomes Subsystem mit der Aufgabe, die Sicherheit des Bahnhofes ständig zu überwachen. Der Sicherheitsrucksack, welcher durch das weitere frei programmierbare Schaltwerk gebildet wird, muß hierbei den ausfallsicheren Betrieb des Stellwerkes garantieren. Der Sicherheitsrucksack wird bei dem nachfolgend beschriebenen Ausführungsbeispiel als Echtzeitexpertensystem unter Verwendung einer regelorientierten Programmiersprache implementiert. Die Grundkonzepte des Sicherheitsrucksackes und sein positiver Einfluß auf die Softwaresicherheit wird in den nachstehenden Abschnitten beschrieben.

Im Rahmen der erfindungsgemäßen Einrichtung ist die Ausbildung mit Vorteil so getroffen, daß das weitere frei programmierbare Schaltwerk unabhängig von Signalen des ersten frei programmierbaren Schaltwerkes mit Stellgliedern der Signalanlagen verbindbar ist, wobei vorzugsweise das weitere frei programmierbare Schaltwerk die Eingangs- und Ausgangssignale des ersten Schaltwerkes mit dem Ist-Belegungszustand gemeinsam mit dem über einen weiteren Eingangs- und Ausgangsschaltkreis erfaßten Signalen für manuelle Verstellungen der Weichen und/oder Signalanlagen verarbeitet.

Bei der im Rahmen des Ausführungsbeispieles gewählten Software für das System wird die Fehlerprävention durch Verbindung einer geeigneten Programmiersprache (CCITT-CHILL) mit einer besonderen Entwurfmethode HCDM (Hierarchichal Chill Design Method) erreicht. Es wird dabei eine Reduktion der Restfehler um bis zu 80% erreicht.

Obwohl derartige Fehlerpräventionstechniken dazu beitragen, die restlichen Softwarefehler (und daher auch potentiell gefährliche Fehler) zu minimieren, werden zur Maximierung der Softwaresicherheit noch zusätzliche Fehlererkennungsmechanismen eingeführt.

Die erfindungsgemäße Ausbildung wird an Hand der Technik des Sicherheitsrucksackes in der Folge näher erläutert. In der Figur ist ein grundlegendes Architekturmodell eines gemäß der Erfindung ausgebildeten Stellwerks dargestellt.

Das Stellwerk gliedert sich in drei funktionelle Ebenen:

• - Bedienerschnittstelle (Graphische Ein-/Ausgabe)
• - Stell- und Sicherheitsebene
• - Peripherieansteuerung

In der Figur ist die Architektur horizontal in ein Stellwerks-Subsystem A und ein Sicherheits-Subsystem B unterteilt.

Das Stellwerks-Subsystem bietet alle zur Steuerung eines Bahnhofs notwendigen Funktionen. Befehle des Bedieners werden mittels Lichtstift über die mit Farbgraphikmenü gesteuerte Bedienerschnittstelle eingegeben. Nach Vorverarbeitung durch einen Video Master Prozessor VMP werden die Befehlseingaben an einen Interlocking Prozessor ILP gesandt.

Der Interlocking Prozessor ILP hat Zugang zum kompletten Systemstatus und übersetzt, gemäß den Sicherheitsregeln, Befehle vom Video Master Prozessor VMP in einen Satz peripherer Steuerungsbefehle, die an einen Elementansteuerprozessor ECPA gesandt werden. Der Interlocking Prozessor ILP führt ein ständiges Update der Datenbasis durch, die den Systemstatus gemäß der vom Elementansteuerprozessor ECPA empfangenen Statusmeldungen enthält. Der Interlocking Prozessor ILP muß auch rechtzeitig auf gewisse Ereignisse reagieren (z. B. ein Signal von grün auf rot umschalten, wenn ein Zug vorbeifährt). Der Video Master Prozessor VMP wird vom Interlocking Prozessor ILP mit Statusinformation versorgt.

Nach Empfang eines Steuerbefehls von Interlocking Prozessor ILP, speichert der Elementansteuerprozessor ECPA diesen und leitet ihn an einen Sicherheitsprozessor (SBP) weiter. Der Sicherheitsprozessor SBP prüft, ob die Ausführung des Befehls die Systemsicherheit gefährden würde. Besteht der Befehl alle Prüfungen, sendet ihn der Sicherheitsprozessor SBP an einen dem Sicherheits-Subsystem B angehörenden weiteren Elementansteuerprozessor ECPB. Würde der Befehl eine gefährliche Situation hervorrufen, wird er gesperrt und dem Bediener ein Alarm signalisiert. Aus Gründen der Synchronisierung und um eine vollständige Sicherheitsprüfung zu ermöglichen, erhalten der Sicherheitsprozessor SBP (vom Video Master Prozessor VMP) auch alle Befehle, die von diesem an den Interlocking Prozessor ILP gesandt werden.

Nach Erhalt einer Befehlsanforderung vom Sicherheitsprozessor SBP, sendet der Elementansteuerprozessor des Subsystems B, ECPB, diese an den Elementansteuerprozessor ECPA zurück und gibt einen Steuerbefehl an die Peripherie aus. Nachdem der Elementansteuerprozessor ECPA diese Befehlsanforderung erhalten hat, vergleicht er sie mit der entsprechenden, vom Interlocking Prozessor ILP erhaltenen. Sind beide identisch, gibt auch der Elementansteuerprozessor ECPA einen Steuerbefehl an die Peripherie. Die elektrischen Befehlsignale, die von den Elementansteuerprozessoren ausgehen, werden durch eine zusätzliche, in Hardware ausgeführte Vergleichsschaltung (Hardware Voter) verglichen und nur bei Gleichheit an das Peripherieelement weitergegeben. Beide Elementansteuerprozessoren überwachen außerdem ständig den Peripheriestatus und geben alle Änderungen an den Interlocking Prozessor ILP und den Sicherheitsprozessor SBP weiter.

Der Sicherheitsprozessor erhält alle peripheren Statusmeldungen vom Elementansteuerprozessor ECPB und führt ein ständiges Update der eigenen Echtzeitdatenbasen unter Beschreibung des Systemzustandes durch. Im Fall notwendiger Reaktionen auf Ereignisse an der Peripherie gibt der Sicherheitsprozessor autonom die erforderliche Befehlsanordnung an den Elementansteuerprozessor ECPB aus.

Der Sicherheitsrucksack ist hier ein autonomes Rechnersystem, welches ständig den Sicherheitsstatus des Steuerungssystems und dessen Peripherie überwacht. Alle Aktionen und Reaktionen des Systems werden ein zweites mal daraufhin überprüft, ob sie den Sicherheitsregeln entsprechen.

Der Sicherheitsrucksack besteht aus folgenden zwei Teilen:

Passivteil:Alle von der Steuersoftware ausgegebenen sicherheitskritischen Aktionen werden anhand der Sicherheitsregeln überprüft, bevor sie an die Peripherie gesandt werden können (z. B. bevor ein Signal von rot auf grün umgeschaltet werden kann). Alle gefährlichen Handlungen werden gesperrt. Aktivteil:Der Sicherheitsrucksack gewährleistet, daß alle sicherheitskritischen Reaktionen rechtzeitig stattfinden (z. B. Wechseln eines Signals von grün auf rot bei Durchfahrt eines Zuges). Wird eine sicherheitskritische Reaktion von der Steuersoftware unterlassen, so stellt der Sicherheitsrucksack sicher, daß dies bemerkt wird.

Um den Sicherheitsstatus des Gesamtsystems analysieren zu können, muß der Sicherheitsrucksack in seiner Echtzeitdatenbasis über einen vollständigen Satz Informationen über Topologie und Konfiguration des Systems verfügen. Der Sicherheitsrucksack muß außerdem kontinuierlich alle Meldungen über den Peripheriestatus erhalten.

Die Aufgaben des Sicherheitsrucksacks (Sicherheitsüberwachung) weichen beträchtlich von denen der Steuerungssoftware (z. B. Betrieb des Stellwerks) ab. Beide Pakete haben daher unterschiedliche Spezifikationen und folglich eine beträchtlich verringerte Wahrscheinlichkeit gemeinsamer Fehlerzustände.

Neben der Diversität der Spezifikationen, wird auch maximale Entwurfsdiversität der Stellwerkssoftware und des Sicherheitsrucksacks erreicht.

Die Stellwerksteuersoftware führt in der Hauptsache konventionelle Prozessteueraufgaben durch, und die Verwendung von CHILL als Programmiersprache und eines prozeduralen Programmierparadigmas stellt daher dafür eine geeignete Wahl dar. Die Hauptaufgabe des Sicherheitsrucksacks ist die ständige Überprüfung des Status der Peripherie aufgrund von Sicherheitsregeln. Solche Regeln können idealerweise in einer regelbasierten Programmiersprache ausgedrückt werden. Der Sicherheitsrucksack wurde daher zweckmäßig als Produktionensystem - einer besonderen Art von regelbasiertem Expertensystem - implementiert.

Die Ablauflogik von Produktionensystemen unterscheidet sich in ihrer Art ganz wesentlich von jener von Programmen, die in einer prozeduralen Programmiersprache wie CCITT-CHILL geschrieben sind. Einer der Hauptunterschiede liegt in der Verwendung von datensensitiven, ungeordneten Regeln durch das Produktionensystem (sogenannte "Produktionen") anstelle einer Sequenz von Anweisungen als Grundeinheit der Programmausführung.

Ein wichtiger Grund für die Auswahl eines Produktionensystems war die hohe Ausführungsgeschwindigkeit die sich mit einer derartigen Architektur erreichen läßt. Eine compilierte Wissensbasis, kombiniert mit einem sehr wirkungsvollen Mustervergleichsalgorithmus (dem sogenannten RETE-Algorithmus) ermöglicht eine Durchschnittsleistung von bis zu 100 Regeln pro Sekunde.

Die Synchronisierungs- und Kommunikationsprobleme wurden dadurch gelöst, daß das komplette Expertensystem (Wissensbasis, Datenspeicher und Schlußfolgerungsmaschine) in eine CHILL-Umgebung eingebettet wurde. In dieser Umgebung sieht das Expertensystem wie ein gewöhnlicher CHILL-Prozeß aus und kann auf die Echtzeit-Datenbank zugreifen und mit anderen Prozessen kommunizieren.

Eine Prozedurschnittstelle gibt dem Expertensystem Zugriff auf alle benötigten Funktionen des Betriebssystems. Anstatt über eine Dialogschnittstelle mit einem Anwender zu kommunizieren, tauscht das Expertensystem in seiner CHILL-Umgebung CHILL-Nachrichten ("Signale", "Buffer" und "Events") mit anderen CHILL-Prozessen und Datensätze mit der Echtzeit-Datenbank aus.

Die Realisierung des Sicherheitsnetzes als Expertensystem bringt ein Höchstmaß an Unterschiedlichkeit, da sowohl deklaratives (regelorientiertes) als auch prozedurales (CHILL) Programmieren zum Einsatz kommt. Ein weiterer positiver Faktor besteht darin, daß die Sicherheitsregeln in einer regelorientierten Programmiersprache formuliert werden können. Die Regeldarstellung kann beinahe als formale Spezifikation angesehen werden, die direkt, ohne zusätzliche Codierung, ausgeführt wird. Die Codierung der Sicherheitsregeln in CHILL würde weit mehr Aufwand erfordern und außerdem noch die Gefahr zusätzlicher Programmierfehler in sich bergen. Die Ausführung der Sicherheitsprüfung durch den Sicherheitsrucksack geht in den folgenden drei Phasen vonstatten:

• 1. Vorprüfungsphase
  • - Befehlsdefinition: Die laufende Befehlsanforderung (für gewöhnlich eine vom Applikationsprozess empfangene Nachricht) wird in ein Zielelement übersetzt.
  • - Datenladen: Laden der benötigten Datenobjekte, die den tatsächlichen und den Zielsystemzustand darstellen. Auf die in der Echtzeitdatenbasis befindlichen Datenobjekte wird unter Verwendung der CHILL-Primitives ′get-record′ und ′put-record′ zugegriffen. Sie werden dann in Ziel- und Zustandselemente umgewandelt und im Arbeitsspeicher gespeichert.
• 2. Sicherheitsprüfungsphase: Ausführung der Sicherheitsregeln.
• 3. Nachbeurteilungsphase: Das positive Beurteilungsergebnis wird an den entsprechenden Prozeß gesandt oder eine Alarmaktion gesetzt (z. B. Sperren des gefährlichen Befehls und Alarmmeldung an den Fahrdienstleiter).

Die folgenden vereinfachten Programmbeispiele zeigen, wie Definitionen von Datentypen, Zielen und Regeln des Sicherheitsrucksacks aussehen können. Das in der Tabelle 1 gegebene Beispiel zeigt eine Typendeklaration für ein Datenobjekt, das den Sicherheitsstatus einer Eisenbahnweiche beschreibt. Der Sicherheitsrucksack enthält Typendeklarationen für jede Art von Peripherieelementen (verschiedene Signalarten, Gleise, usw.).

Nach Erhalt einer Befehlsanforderung (z. B. Weiche umstellen) holt der Sicherheitsrucksack die relevante Statusinformation von einer externen Echtzeitdatenbasis (Vorprüfungsphase) und speichert sie in einer Instanzierung eines Datenobjekts entsprechenden Typs (diese Datenobjekte werden im Arbeitsspeicher abgelegt). Während der Sicherheitsprüfung werden diese Datenobjekte mit den in den Sicherheitsvorschriften angeführten Bedingungen verglichen.

Tabelle 1

Beispiel einer Typendeklaration eines Datenobjekts, das den Zustand einer Weiche beschreibt

Zielelemente werden verwendet, um die Ausführung der Regeln des Sicherheitsrucksacks zu steuern. Jede Befehlsanforderung muß in eine Instanzierung des entsprechenden Zielelements übersetzt und im Arbeitsspeicher abgelegt werden. Die Interferenzmaschine vergleicht das Zielelement mit den Zielbedingungen auf der linken Seite (LHS) der Regeln und wählt die passenden Regeln aus. Eine Regel enthält typischerweise ein Zielelement und einige zusätzliche Sicherheitsbedingungen. Tabelle 2 enthält ein Beispiel einer Typendeklaration eines Zielelementes.

Tabelle 2

Typendeklaration eines Zielelements für den Sicherheitsrucksack

Das in Tabelle 3 angeführte Regelbeispiel enthält alle für einen Weichenstellbefehl im Laufe einer Fahrstraßeneinstellung durchzuführenden notwendigen Sicherheitsprüfungen. Die linke Seite (LHS) der Regel hat zwei Bedingungen - das Zielelement wählt die Art der vom Expertensystem durchzuführenden Überprüfung, und das Weichenelement enthält die komplette sicherheitsrelevante Statusinformation einer Weiche. Die Regel muß für alle Weichenstellbefehle durchgeführt werden, die notwendig sind, um eine Fahrstraße durch einen Bahnhof zu stellen. Eine Weiche kann nur gestellt werden, wenn sämtliche Sicherheitsbedingungen dieser Regel erfüllt sind.

Tabelle 3

Beispiel einer Sicherheitsregel für eine Eisenbahnweiche. Diese Regel enthält alle Sicherheitsprüfungen, die vor einer Weichenstellung während des Stellens einer Fahrstraße notwendig sind

Zur Durchführung der Sicherheitsprüfungen muß das Expertensystem mit Daten arbeiten, die in der Echtzeitbank gespeichert sind (außerhalb des Expertensystems). Die Aktualisierung dieser Echtzeitdatenbasis im Sicherheitsrucksack wird von einer Reihe von CHILL-Prozessen aufgrund von Meldungen über den Peripheriezustand durchgeführt. Eine Synchronisation und Kommunikation des Sicherheitsexpertensystems mit anderen (CHILL) Prozessen des Sicherheitsrucksacks kann über CHILL-Synchronisationsmechanismen durchgeführt werden.

Claims (3)

1.Einrichtung zum Steuern eines Stellwerkes, insbesondere für Schienenfahrzeuge, mit Ausnehmern für den Ist-Belegungszustand und die Stellung von Weichen der Schienen und/oder Signalanlagen und einem frei programmierbaren Schaltwerk zur Auswertung der Signale der Aufnehmer sowie zum Verarbeiten von Signalen für die Stellung von Weichen und/oder Signalanlagen, dadurch gekennzeichnet, daß dem frei programmierbaren Schaltwerk ein weiteres frei programmierbares Schaltwerk zugeschaltet ist, welchem Eingangs- und Ausgangssignale des ersten frei programmierbaren Schaltwerkes zur Verarbeitung zugeführt sind und welches unabhängig Ausgangssignale generiert, welche vor der Weiterleitung an die Stellglieder der Weichen und/oder Signalanlagen einem Komparator und/oder einer logischen Entscheidungseinheit (Voter), welche auch die Ausgangssignale des ersten frei programmierbaren Schaltwerkes erhalten, zugeführt sind.

2. Einrichtung nach Anspruch 1, dadurch gekennzeichnet, daß das weitere frei programmierbare Schaltwerk unabhängig von Signalen des ersten frei programmierbaren Schaltwerkes mit Stellgliedern der Signalanlagen verbindbar ist.

3. Einrichtung nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß das frei programmierbare Schaltwerk die Eingangs- und Ausgangssignale des ersten Schaltwerkes mit dem Ist-Belegungszustand gemeinsam mit dem über einen weiteren Eingangs- und Ausgangsschaltkreis erfaßten Signalen für manuelle Verstellung der Weichen und/oder Signalanlagen verarbeitet.