Betriebssysteme

Bin ich auf der richtigen Bahn? Die Wahl des OS für die Zugsteuerung

| Autor / Redakteur: Terry Staycer * / Franz Graser

Ein komplexes System: Lokomotive mit vorab zertifizierten Hardware- und Softwaremodulen und Netzwerktechnologien zur Kommunikation mit und zum Steuern von diversen Systemen
Ein komplexes System: Lokomotive mit vorab zertifizierten Hardware- und Softwaremodulen und Netzwerktechnologien zur Kommunikation mit und zum Steuern von diversen Systemen (Bild: QNX)

Firmen zum Thema

Auf den Eisenbahnstrecken in der EU kommt es jeden zweiten Tag zu einer Kollision oder Entgleisung. Um diese Rate zu senken, finden zunehmend Normen für funktionale Sicherheit Anwendung.

Für den Erfolg bei sicherheitskritischen Projekten im Schienenverkehr ist der Wissensstand über funktionale Sicherheit und Zertifizierung einer der entscheidenden Faktoren. Anforderungen bei der Zertifizierung für funktionale Sicherheit bestimmen allgemein oft über Erfolg oder Misserfolg eines Projekts, denn diese Anforderungen können die Projektdauer und den Aufwand für das Projekt ganz schnell verdoppeln oder gar verdreifachen.

Die Normen für funktionale Sicherheit können auf Neueinsteiger verwirrend wirken. Die EN 50128 beispielsweise ist eine marktspezifische Norm für funktionale Sicherheit im Schienenverkehr, die von der weiter gefassten IEC 61508 abgeleitet ist, einer Norm für die funktionale Sicherheit von elektrischen, elektronischen und programmierbaren elektronischen sicherheitsrelevanten Systemen. Die Sicherheitsintegritätslevel der EN 50128 reichen von der niedrigsten Stufe SIL 1 bis zur höchsten Stufe SIL 4.

Sicherheit lässt sich nicht nachträglich draufsatteln

Um ein Gefühl dafür zu vermitteln, wie hoch die Anforderungen sind: Bei einem nach SIL 3 zertifizierten System muss die Wahrscheinlichkeit für gefährliche Ausfälle pro Betriebsstunde bei unter 1 in 10 Millionen liegen. Es ist fast unmöglich, derart strikte Anforderungen zu erfüllen, wenn funktionale Sicherheit nicht von Anfang an im Design verankert wird. Sicherheit kann nicht einfach nachträglich draufgesattelt werden.

Um einen sicheren und effizienten Betrieb zu gewährleisten, implementieren Eisenbahnen rund um die Welt Systeme wie die konventionelle Zugbeeinflussung (Automatic Train Protection – ATP), das US-amerikanische Zugleitsystem „Positive Train Control“ (PTC) oder die funkbasierte Zugbeeinflussung (Communications-Based Train Control – CBTC). U-Bahnen und andere Züge im öffentlichen Personennahverkehr setzen zunehmend auf vollautomatischen Zugbetrieb (Automated Train Operations – ATO) – Züge, die keine Fahrer haben oder bei denen die Rolle des Zugführers hauptsächlich auf Unterstützung bei Ausfällen und Notfallsituationen beschränkt ist.

Bei jedem sicherheitsrelevanten System kommt es ganz offensichtlich auf Verlässlichkeit an, also sollte das Betriebssystemdesign Garantien für Verfügbarkeit und Zuverlässigkeit bieten können. Solche Betriebssysteme werden als Echtzeit-Betriebssysteme (RTOS – Realtime Operating System) bezeichnet. Es gibt unterschiedliche RTOS-Architekturen, und eines ihrer Hauptunterscheidungsmerkmale ist, wie gut ein RTOS die EN 50128 für sicherheitskritische Applikationen unterstützt.

Ergänzendes zum Thema
 
Zusammenfassung und Ausblick

Die EN 50128 behandelt drei sehr wichtige Punkte für Software:

1. Architektur: Die Softwarearchitektur ist die Stelle, an der die grundlegende Sicherheitsstrategie für die Software und den Sicherheitsintegritätslevel der Software entwickelt wird.

2. COTS: Soll in Systemen, die nach SIL 3 oder SIL 4 zertifiziert sein müssen, COTS-Software (Commercial off-the-shelf – Standardkomponenten) eingesetzt werden, so muss „eine Strategie definiert sein, wie Ausfälle der COTS-Software erkannt werden und das System davor geschützt werden kann.“

3. Sicherheitsdesign und Validierung: Die EN 50128 sagt explizit aus, dass „kein Weg bekannt ist, auf dem sich ab einem gewissen Komplexitätsgrad die Fehlerfreiheit sicherheitsrelevanter Software beweisen ließe.“ Anders gesagt: Wenn wir ein sicheres System bauen, können wir nicht beweisen, dass das System keine Fehler enthält, sondern lediglich Belege liefern, die unsere Aussage untermauern, dass unser System so verlässlich ist, wie wir es von ihm behaupten.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44363764 / Embedded Betriebssysteme)