Startseite > Embedded > Software > Sichere Software für den Schienenverkehr

Zertifizierung

Sichere Software für den Schienenverkehr

13. September 2010, 10:31 Uhr | Von John Carbone

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Verschiedene Normen – gemeinsame Basis

Alle internationalen sicherheitskritischen Software-Standards enthalten gemeinsame Elemente, die für alle Software-Systeme unabhängig von deren endgültiger Anwendung einheitlich sind. Die verschiedenen Standards mögen sich in ihrer genauen Formulierungsweise und ihren individuellen Merkmalen unterscheiden, sie alle verlangen jedoch, dass Software nach einem umfassend dokumentierten Plan entwickelt wird und dass ihre Funktion mit diesem Plan übereinstimmt. Insbesondere muss für sicherheitskritische Software durch rigorose Tests und Dokumentation nachgewiesen werden, dass sie sorgfältig entwickelt wurde und sicher arbeitet.

Der Prozess, nach dem das Design, die Entwicklung und der Test der Software erfolgten, muss umfassend beschrieben und seine Einhaltung nachgewiesen werden. Dies wird in mehrere Unterkategorien gegliedert:

Planung – Die Zielvorgaben des Systems werden formuliert zusammen mit einem Plan für das Erreichen dieser Vorgaben und die Verifikation, dass die Vorgaben tatsächlich erfüllt wurden.

Design – Spezifikation des Systemdesigns (Hard- und Software) mit Betriebsszenarien und anderen Aspekten des Designs, mit deren Hilfe Prüfer verstehen können, wie das System seine Vorgaben erfüllen soll.

Entwicklung – Dies umfasst den Entwicklungsprozess, die verwendeten Tools, Code-Prüfungen, einen Prüfplan, Dokumentation und Personalschulung.

Anforderungen – Die funktionalen Anforderungen des Systems werden explizit bezeichnet und mit den Fähigkeiten des Systems korreliert.

Verifikation – Sicherstellung, dass sich das System spezifikationsgemäß verhält und seine Zielvorgaben erfüllt.

Konfigurationsmanagement – Kontrolle der schrittweisen Versionsstände, um die Ergebnisse reproduzierbar zu machen und zu verhindern, dass Fehler nicht mehr rückgängig zu machen sind.

Qualitätssicherung – Prozesse, die die Gewähr dafür bieten, dass das System entsprechend seinen Zielvorgaben entwickelt und produziert wurde und die angestrebten Fähigkeiten erfüllt.

Der Bereich Code bezieht sich auf den vom Entwickler bzw. von den Entwicklungswerkzeugen produzierten Code mit dem gesamten System- und Applikations-Quellcode, Testcode, Skripten und Objektcode. Dieser Code muss im Zuge des Regulatory-Compliance- Prozesses geprüft werden und mit dem tatsächlich im System eingesetzten Code übereinstimmen.
Der Bereich Test umfasst bestimmte Tests, mit denen die korrekte Funktion des Codes und seine Fähigkeit, alle Design-Vorgaben und System-Anforderungen zu erfüllen, verifiziert werden sollen. Zu den Tests gehören Code-Abdeckungs-Prüfungen und Analysen. Diese sollen gewährleisten, dass alle Programmbefehle geprüft wurden. Schließlich gehören Unit-/ Whitebox- und Integration-/Blackbox- Tests sowie die finale Abnahmeprüfung zum Testpensum.
Der Bereich Results umfasst die gesammelten Ergebnisse aller Tests, zusammengefasst in einem Unit- und Integrations- Prüfbericht.

Betriebssystem: kommerziell oder selbst entwickelt?

Die Hersteller von Eisenbahnsystemen verfügen über Entwicklungsteams, die uneingeschränkt in der Lage sind, die vorschriftsmäßige Dokumentation zur Einhaltung dieser sicherheitskritischen Standards zu generieren, und dies schon seit Jahren getan haben. Allerdings ist diese Tätigkeit auch mit Schwierigkeiten verbunden, um die sich die Entwickler gern drücken würden. Während die sicherheitskritischen Systeme ständig komplexer werden und immer leistungsfähigere Mikroprozessoren nutzen, setzen sie zunehmend auf die Technologie kommerzieller Betriebssysteme. Das Echtzeit-Betriebssystem steuert und verwaltet die Applikations- Software, um die System-Ressourcen für den jeweiligen Prozessor zu maximieren.

In der Regel umfassen solche Applikationen mehrere Applikations- Tasks bzw. -Threads und ein prioritätsbasiertes Real-Time-Scheduling- Betriebssystem mit Interrupt-Fähigkeit. Ein kommerzielles RTOS stellt diese Funktionen über ein bedienungsfreundliches API (Application Programming Interface) bereit, mit dessen Hilfe sich bei der Applikationsentwicklung viel Zeit sparen lässt. Darüber hinaus gibt ein kommerzielles RTOS den Entwicklern die Möglichkeit zur Nutzung weiterer kommerzieller Middleware-Komponenten (z.B. Netzwerk-Stacks, Grafik, USB-Kommunikation usw.).

Wird in einem sicherheitskritischen System ein kommerzielles RTOS eingesetzt, obliegt dem Entwickler die vorgeschriebene Dokumentation und Prüfung von Software, die von einer unabhängigen Instanz entwickelt wurde. Regulierungsinstanzen bezeichnen diese Art Software als SOUP (Software Of Unknown Pedigree; d.h. Software unbekannter Herkunft). Es ist schon schwierig, für den vom Team selbst entwickelten Applikations-Code die gesamte behördlich vorgeschriebene Dokumentation beizubringen, doch ungleich schwieriger gestaltet sich dies für Code, der von einer anderen Organisation entwickelt wurde. Die Zeit, die für das Erstellen und Organisieren der gesamten zum RTOS gehörenden Dokumentation aufgewendet werden muss, kann deshalb einen erheblichen Teil des Zeitbudgets für ein Projekt verbrauchen. Noch schwieriger wird es, wenn der Quellcode des kommerziellen Betriebssystems nicht in vollem Umfang vorliegt.

Diese Bedenken sind für einige Entwicklungs-Teams der Anlass, anstelle eines kommerziellen Produkts auf ein selbst entwickeltes Betriebssystem zu setzen. Zweifellos umgeht man damit das SOUP-Problem, und die Dokumentations- Aufgabe verliert erheblich an Brisanz. Allerdings entfallen bei dieser Entscheidung auch die Vorteile eines kommerziellen RTOS, sodass sich die Entwickler in einer echten Zwickmühle befinden.

Solange das RTOS mit dem vollständigen Quellcode geliefert wird und von beherrschbarer Größe ist, kann es für das Entwicklungs-Team machbar sein, die vorgeschriebenen Aufgaben intern zu absolvieren. Das Team muss allerdings in jedem Fall viel Zeit investieren, um den zugelieferten Code so fundiert zu verstehen, dass es ihn so gut dokumentieren und testen kann, wie es zur Erfüllung der behördlichen Auflagen erforderlich ist. Dieser Zeitund Arbeitsaufwand – vom Fehlerund Störungsrisiko ganz zu schweigen – lässt diesen Ansatz nach wie vor unbefriedigend erscheinen, da er mehr Zeit beansprucht und die Entwicklungskosten insgesamt in die Höhe treibt.