Validierung von Bahnsystemen neben DOORS

Die Wirkungsliste für die Belegung

Welche Prüfung den Prüfstand bindet, welche das Fahrzeug, welche nur die Dokumentation. Die Betroffenheit kommt aus dem Vergleich gegen die Vorgängerfassung, nicht aus dem Link-Status. Ihr entscheidet, ob neu geprüft, nachdokumentiert oder eine Abweichung festgehalten wird. Dieselbe Liste geht über ReqIF und CSV zurück nach DOORS.

DOORS führt die Anforderungen. Das bleibt so.

DOORS ist das führende System für die Anforderungen, und das aus gutem Grund. Module, Verknüpfungen, Baselines, Historie, Zugriffsrechte: das Werkzeug kann das, und es sitzt seit Jahren. Wer ein solches Projekt führt, hat die Struktur nicht aus Nachlässigkeit so gebaut. Sie ist gewachsen, weil das Fahrzeug, die Varianten und die Change Requests gewachsen sind. Cevelar ersetzt das nicht. Es setzt dort an, wo aus einer geänderten Anforderung ein Prüfplan werden muss.

Was die Suspect Links nicht entscheiden

Die Prüfmethode an der Anforderung ist in DOORS ein Attribut. Aufwand, Dauer und welche Ressource gebunden wird, stehen daneben, meist in einer eigenen Liste. Der geführte Nachweis (gegen welche Fassung, unter welchen Randbedingungen) ist kein Objekt im Werkzeug. Ob er nach einem Change Request weiterträgt, ist eine Bewertung, keine Ableitung. Wiederverwendung über Fahrzeugprojekte hinweg ist dasselbe in größerem Maßstab: eine manuelle Einschätzung, die jemand mit dem alten Bericht und dem neuen Lastenheft nebeneinander vornimmt.

Cevelar führt Prüfmethode und Aufwand an der Anforderung selbst, nicht als Nebenliste. Suspect Links in DOORS sind die richtige Meldung. Sie sagen nicht, welcher Prüfstand noch gilt, welcher Fahrzeugversuch neu muss, und welche Belegung sich daraus verschiebt.

Change Request 19 an der Türsteuerung

Eine Türsteuerung, SIL 2. Die Anforderung SYS-0218 verlangt die Freigabe erst unterhalb einer Geschwindigkeitsschwelle. Nachgewiesen ist sie über Prüfstand und Fahrzeugversuch, geführt gegen 5 km/h, Lastenheft Rev. C. Alle Angaben in diesem Abschnitt sind Demo-Daten.

Der Betreiber schickt Change Request 19 (CR-19). Die Schwelle wird 3 km/h. In DOORS werden die Verknüpfungen von SYS-0218 verdächtig. Das ist die richtige Meldung. Sie endet dort. Sie sagt nicht, ob der Prüfstandsbericht aus V&V-0312 weiterverwendet werden kann, ob der Fahrzeugversuch neu aufgesetzt werden muss, oder ob nur die Dokumentation der Randbedingungen nachzuziehen ist.

Offen bleibt, was der geführte Nachweis noch wert ist. Der Prüfstand war gegen 5 km/h aufgebaut. Die neue Schwelle ändert die Randbedingung, nicht unbedingt den Prüfaufbau. Ob der Nachweis weiterträgt, hängt davon ab, was am Stand wirklich gemessen wurde, und nicht vom Anforderungstext allein. Ein Aufbau, der die Freigabe über den gesamten Geschwindigkeitsbereich erfasst hat, kann die schärfere Schwelle bereits enthalten. Ein Aufbau, der nur den alten Grenzwert bestätigt hat, nicht. Das steht selten im Attribut, oft nur im Versuchsbericht.

Der Fahrzeugversuch hängt an der ausgerollten Softwarefassung und an dem Fahrzeug, das damals verfügbar war. Auch er kann wahr bleiben und trotzdem nicht mehr tragen: dieselbe Messung, eine andere Geltung. Die SIL-Einstufung folgt nicht aus der Schwelle. Sie bleibt eine eigene Bewertung.

Wer nach CR-19 pauschal neu prüft, bindet einen Prüfstand und ein Fahrzeug, die Monate im Voraus vergeben sind. Wer pauschal stehen lässt, trägt die Nachweislage in die nächste Gutachterrunde. Beides sind Kategorien, keine Preise: eine Belegung, eine Runde, im schlechten Fall eine verschobene Inbetriebnahme.

Was Cevelar in der Prüfplanung führt

Der Bestand kommt aus DOORS. Cevelar erfasst die Anforderungen nicht neu. Es liest den Stand (Modul, Baseline, Änderungen gegen die Vorgängerfassung) und leitet die Betroffenheit aus dem Vergleich selbst ab. An derselben Anforderung SYS-0218 stehen dann Methode, Aufwand und der geführte Nachweis mit Fassung und Randbedingungen.

Nach CR-19 steht dort, dass der Prüfstand gegen 5 km/h geführt wurde und die Randbedingung sich geändert hat; dass der Fahrzeugversuch an einer bestimmten Softwarefassung hängt; welcher Aufwand für eine erneute Bewertung oder eine Wiederholung angesetzt ist. Die Klauseln aus EN 50126 und, wo Software liegt, EN 50128 oder EN 50657 hängen an der Anforderung, nicht in einem Ordner. Ob neu geprüft, nachdokumentiert oder eine Abweichung festgehalten wird, entscheidet ihr. Die Plattform leitet den Zustand ab und hält fest, gegen welche Fassung der Nachweis gilt.

Dasselbe Teilsystem, nächstes Fahrzeugprojekt

Dieselbe Türsteuerung läuft in einem zweiten Fahrzeugprojekt, oft mit eigener Lastenheftfassung und eigenen Ländervarianten. Ein Nachweis ist wiederverwendbar, wenn nachvollziehbar ist, gegen welche Anforderungsfassung und unter welchen Randbedingungen er geführt wurde. Fehlt dieser Anker, bleibt nur der Bericht und die Erinnerung, dass „etwas Vergleichbares schon gelaufen ist“. Ohne diese Rückverfolgbarkeit wird im Zweifel neu geprüft. In Cevelar hängt der Anker am Nachweis. Beim nächsten Projekt ist die Wiederverwendung eine Abfrage gegen Fassung und Randbedingung, keine Suche im Archiv.

Wenn nicht der Betreiber ändert, sondern die Norm

Ein Change Request hat einen Absender. Jemand im Projekt weiß davon, und sei es nur, weil eine Mail ankommt. Eine Normrevision hat keinen. Das Fahrzeug läuft, der Nachweis stammt aus der Typzulassung, und die Fassung, gegen die er geführt wurde, ist seit zwei Ausgaben nicht mehr die aktuelle. Der Nachweis ist deshalb nicht falsch. Sein Geltungsbereich ist unklar.

Auffallen tut das beim Retrofit, bei der Ländervariante oder in der nächsten Begutachtung, gestellt von jemandem, der beim Erstnachweis nicht dabei war. Dann beginnt die Archäologie: welche Ausgabe galt damals, was hat sich in der neuen geändert, betrifft es die Klausel, gegen die geprüft wurde.

Das ist der Zustand, für den wir bauen: die Normfassung als Anker am Nachweis, damit aus einer abgelösten Ausgabe ein Eintrag in der Nachweislage wird statt einer Suche im Archiv. Welche Normfamilien mit welcher Tiefe abgebildet werden, entsteht mit dem ersten Bahnprojekt. Die Klauselstruktur steht, der CENELEC-Katalog wird gemeinsam aufgebaut.

EN 50126, der Sicherheitsnachweis, die Begutachtung

EN 50126 setzt den Rahmen für Verifikation und Validierung. EN 50129 verlangt den Sicherheitsnachweis mit nachvollziehbaren Ketten. EN 50657 beziehungsweise EN 50128 gelten, wo Software im Teilsystem liegt. CSM-RA bewertet die Änderung, nicht das Werkzeug.

Cevelar hängt Klauseln aus EN 50126, EN 50128, EN 50129 und EN 50657 an die Anforderung und hält Historie und Nachweisketten. Den Sicherheitsnachweis führt ihr. Die Begutachtung durch ISA, AsBo oder NoBo besteht ihr. Die Plattform sagt weder eine Typzulassung noch eine Inbetriebnahmegenehmigung zu.

Normtexte

Frei zugängliche Regelwerke (etwa TSI-Texte und die Durchführungsverordnung zur CSM-RA) sind enthalten. Kostenpflichtige Normen, darunter EN 50126, EN 50128, EN 50129, EN 50657 sowie DIN- und VDE-Normen, bringt ihr unter eurer eigenen Lizenz ein. Wir verkaufen keine Normtexte weiter. Wir verarbeiten keine kostenpflichtigen Normtexte, für die uns keine Lizenz vorliegt. Im Bahnumfeld ist das ein Prüfkriterium, kein Nebensatz: der Klauselbezug ist eine Referenz, kein Ersatz für das Normexemplar.

Woran sich das im laufenden Projekt zeigen ließe

An einer Änderung, die schon in DOORS steht, und an der dazugehörigen Prüfplanung. Welche Nachweise nach dem Delta noch tragen, welche Prüfung neu muss, welche Belegung sich verschiebt. Nicht als Einführung, sondern an dem Modul, das ihr ohnehin pflegt. Gehostet in Deutschland, On-Premise auf Anfrage.

Gebaut von Ingenieuren aus Test und Validierung, nicht aus dem Toolvertrieb. Elf Jahre Prüfstands- und Validierungsarbeit aus Batterie- und Fahrzeugtechnik stecken in der Logik hinter der Plattform. Für die Bahn bauen wir den Klauselbezug mit dem ersten Projekt auf. Wer wir sind