Univ., Diplomarbeit, 2002--Frankfurt (Main)

Zugl.: Kassel, University, Diss., 2006.

Die Eisenbahnsicherungstechnik ist eines der wenigen technischen Fachgebiete, die bis heute überwiegend national geprägt sind. Ausgangspunkt der Dissertation sind vergleichende Betrachtungen zur Bahnsicherungstechnik auf internationaler Ebene. Die Dissertation stellt Gemeinsamkeiten und Unterschiede in den Technologien heraus und führt diese auf gemeinsame Anforderungen zurück. / Railway signalling is one of the few technical fields which are still considered mainly on a national level. The basis for these doctoral thesis is an extensive comparison of railway signalling on an international level. The doctoral thesis point out main commons and differences of signalling and interlocking worldwide, and bases them on common requirements.

Diese Studienarbeit gibt einen Überblick über ausgewählte Teile des Softwareentwicklungsprozesses für sicherheitsrelevante Applikationen am Beispiel eines videobasierten Zugerkennungssystems. Eine IP-Kamera und ein externer Bildverarbeitungscomputer wurden dazu mit einer speziell entworfenen, verteilten Software ausgestattet. Die in Ada und C geschriebenen Teile kommunizieren dabei über ein dediziertes, UDP-basiertes Netzwerkprotokoll. Beide Programme wurden intensiv anhand verschiedener Techniken analysiert, die in der Norm EN 50128 festgelegt sind, welche sich speziell an Software für Eisenbahnsteuerungs- und überwachungssysteme richtet. Eine an der Norm orientierte Struktur mit Verweisen auf die diskutierten Techniken zu Beginn eines jeden Abschnitts erlaubt einen schnellen Vergleich mit den originalen Anforderungen des Normtexts. Zusammenfassend haben sich die Techniken bis auf wenige Ausnahmen als sehr geeignet für die praktische Entwicklung von sicherer Software erwiesen. Allerdings entbindet die Norm durch ihre teils sehr abstrakten Anforderungen das am Projekt beteiligte Personal in keinster Weise von seiner individuellen Verantwortung. Entsprechend sind die hier vorgestellten Techniken für andere Projekte nicht ohne Anpassungen zu übernehmen. / This paper intends to give an overview of selected parts of the software development process for safety-relevant applications using the example of a video-based train detection. An IP-camera and an external image processing computer were equipped with a custom-built, distributed software system. Written in Ada and C, the system parts communicate via a dedicated UDP-based protocol. Both programs were subject to intense analysis according to measures laid down in the EN 50128 standard specifically targeted at software for railway control and protection systems. Preceding each section, a structure resembling the standard document with references to the discussed measures allows for easy comparison with the original requirements of EN 50128. In summary, the techniques have proven to be very suitable for practical safe software development in all but very few edge-cases. However, the highly abstract descriptive level of the standard requires the staff involved to accept an enormous personal responsibility throughout the entire development process. The specific measures carried out for this project may therefore not be equally applicable elsewhere.

Die Eisenbahnsicherungstechnik ist eines der wenigen technischen Fachgebiete, die bis heute überwiegend national geprägt sind. Ausgangspunkt der Dissertation sind vergleichende Betrachtungen zur Bahnsicherungstechnik auf internationaler Ebene. Die Dissertation stellt Gemeinsamkeiten und Unterschiede in den Technologien heraus und führt diese auf gemeinsame Anforderungen zurück. / Railway signalling is one of the few technical fields which are still considered mainly on a national level. The basis for these doctoral thesis is an extensive comparison of railway signalling on an international level. The doctoral thesis point out main commons and differences of signalling and interlocking worldwide, and bases them on common requirements.

Diese Studienarbeit gibt einen Überblick über ausgewählte Teile des Softwareentwicklungsprozesses für sicherheitsrelevante Applikationen am Beispiel eines videobasierten Zugerkennungssystems. Eine IP-Kamera und ein externer Bildverarbeitungscomputer wurden dazu mit einer speziell entworfenen, verteilten Software ausgestattet. Die in Ada und C geschriebenen Teile kommunizieren dabei über ein dediziertes, UDP-basiertes Netzwerkprotokoll. Beide Programme wurden intensiv anhand verschiedener Techniken analysiert, die in der Norm EN 50128 festgelegt sind, welche sich speziell an Software für Eisenbahnsteuerungs- und überwachungssysteme richtet. Eine an der Norm orientierte Struktur mit Verweisen auf die diskutierten Techniken zu Beginn eines jeden Abschnitts erlaubt einen schnellen Vergleich mit den originalen Anforderungen des Normtexts. Zusammenfassend haben sich die Techniken bis auf wenige Ausnahmen als sehr geeignet für die praktische Entwicklung von sicherer Software erwiesen. Allerdings entbindet die Norm durch ihre teils sehr abstrakten Anforderungen das am Projekt beteiligte Personal in keinster Weise von seiner individuellen Verantwortung. Entsprechend sind die hier vorgestellten Techniken für andere Projekte nicht ohne Anpassungen zu übernehmen.:1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Description of the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Real-time constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4 Safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Camera type and output format . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Real-world constrains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Train Detection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 EN 50128 requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1 Defensive Programming . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.2 Fully Defined Interface . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.3 Structured Methodology . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.4 Error Detecting and Correcting Codes . . . . . . . . . . . . . . . . 29 3.1.5 Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.6 Alternative optionally required measures . . . . . . . . . . . . . . 34 3.2 Software Design and Implementation . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Structured Methodology . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.2 Modular Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.3 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.4 Design and Coding Standards . . . . . . . . . . . . . . . . . . . . 39 3.2.5 Strongly Typed Programming Languages . . . . . . . . . . . . . . 41 3.2.6 Alternative optionally required measures . . . . . . . . . . . . . . 44 3.3 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 / This paper intends to give an overview of selected parts of the software development process for safety-relevant applications using the example of a video-based train detection. An IP-camera and an external image processing computer were equipped with a custom-built, distributed software system. Written in Ada and C, the system parts communicate via a dedicated UDP-based protocol. Both programs were subject to intense analysis according to measures laid down in the EN 50128 standard specifically targeted at software for railway control and protection systems. Preceding each section, a structure resembling the standard document with references to the discussed measures allows for easy comparison with the original requirements of EN 50128. In summary, the techniques have proven to be very suitable for practical safe software development in all but very few edge-cases. However, the highly abstract descriptive level of the standard requires the staff involved to accept an enormous personal responsibility throughout the entire development process. The specific measures carried out for this project may therefore not be equally applicable elsewhere.:1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Description of the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Real-time constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4 Safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Camera type and output format . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Real-world constrains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Train Detection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 EN 50128 requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1 Defensive Programming . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.2 Fully Defined Interface . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.3 Structured Methodology . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.4 Error Detecting and Correcting Codes . . . . . . . . . . . . . . . . 29 3.1.5 Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.6 Alternative optionally required measures . . . . . . . . . . . . . . 34 3.2 Software Design and Implementation . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Structured Methodology . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.2 Modular Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.3 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.4 Design and Coding Standards . . . . . . . . . . . . . . . . . . . . 39 3.2.5 Strongly Typed Programming Languages . . . . . . . . . . . . . . 41 3.2.6 Alternative optionally required measures . . . . . . . . . . . . . . 44 3.3 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Unsere Kunden der Eisenbahn erwarten und vertrauen auf eine sichere Durchführung ihrer Zugfahrt – zurecht. Für den guten Ruf der Eisenbahn, ein sicherer Verkehrsträger zu sein, sorgen auf operativer Ebene Betriebsvorschriften und Sicherungstechniken. Diese müssen zielgerichtet zusammenwirken, um gemeinsam die nötige Fahrzeugbewegungssicherung zu garantieren. Das gilt für den Regelbetrieb gleichermaßen wie für die Rückfallebene. Im Bereich der Zugsteuerung und -sicherung wurde und wird eine neue Systemlösung zur Fahrzeugbewegungssicherung auf schwach belasteten Strecken entwickelt – die Neue Sekundärbahn. Sie zeichnet sich durch eine Vereinfachung des historisch gewachsenen Betriebsverständnisses und eine weitreichende Reduzierung der nötigen Infrastrukturausrüstung unter Beibehaltung des zeitgemäßen Sicherungsniveaus aus. Damit ergibt sich die Notwendigkeit, auf Basis der sicherungstechnischen Spezifikationen ein Betriebsverfahren und ein zugehöriges betriebliches Regelwerk für die Neue Sekundärbahn zu erarbeiten, was zentraler Forschungsgegenstand dieser Arbeit ist. Über den Titel dieser Arbeit hinausgehend wird durch eine generische Betrachtung betrieblicher Prozesse zur Verfahrenssicherung untersucht, inwiefern das Erstellen einer generischen Basisbetriebsvorschrift möglich ist, die betriebsverfahrens- und technikunabhängig ist. Diese Frage wird anhand der neu verfassten dänischen ETCS-Vorschrift erörtert.:1 Einleitung 1 2 Abstraktionsebenen der betrieblich-technischen Schnittstelle 4 2.1 Systematische generische Beschreibungsmethode 4 2.2 Ebene des Systemverbunds Eisenbahn 6 2.3 Ebene des Prinzips der Abstandshaltung 8 2.4 Ebene des Betriebsverfahrens 9 2.5 Ebene des Regelwerks 11 2.6 Ebene der Systematisierung von Spezifikationen 12 2.7 Ebene der Systemzustände 13 2.8 Zusammenfassung 16 3 Generische Anforderungen an Betriebsverfahren und Regelwerke 17 3.1 Anforderungen zur Fahrzeugbewegungssicherung 17 3.1.1 Funktionsorientierte Anforderungen nach MASCHEK 18 3.1.2 Prozessorientierte Anforderungen nach HÖPPNER 21 3.1.3 Synthese 21 3.2 Anforderungen an Regelwerke 23 3.2.1 Integration und Modularisierung von Regelwerksinhalten 23 3.2.2 Funktions- oder prozessorientierte Darstellungsweise 24 3.2.3 Inhaltliche Anforderungen 25 3.2.4 Synthese 26 4 Europäische Aktivitäten zur betrieblichen Harmonisierung 27 4.1 Europäische Harmonisierungsprojekte 27 4.2 Status quo und Hemmnisse eines internationalen Verfahrens 28 4.3 Aktuelle Aktivitäten zur betrieblichen Harmonisierung 29 4.3.1 TSI „Verkehrsbetrieb und Verkehrssteuerung“ 29 4.3.2 ETCS-Handbuch für Triebfahrzeugführer 31 4.4 NSB – Katalysator einer betrieblichen Interoperabilität? 32 5 Systemarchitektur der Neuen Sekundärbahn 33 5.1 Gestaltung grundlegender Funktionalitäten 33 5.1.1 NSB-spezifische Komponenten der Sicherungstechnik 33 5.1.2 Wahrnehmung fahrdienstlicher Aufgaben durch den Triebfahrzeugführer 34 5.1.3 Ortung 36 5.1.4 Bedienung standardisierter ETCS-Schnittstellen 36 5.1.5 Zusammenfassung 37 5.2 Umsetzung der generischen Anforderungen 38 5.3 Exkurs: NSB als ZSS-Systemlösung mit dezentraler Logik 40 6 Betriebsverfahren der Neuen Sekundärbahn 42 6.1 Bedeutung von Kapazität und Fahrplan 42 6.1.1 Erhöhung der Kapazität durch Einrichtung von Teilblöcken 42 6.1.2 Schnittstelle zwischen Fahrplan im Datenspeicher und Sicherungslogik 43 6.2 Methode zur Entwicklung des NSB-Betriebsverfahrens 45 6.3 Realisierung der Fahrzeugbewegungssicherung 46 6.3.1 Ablauf zur sicheren Erzeugung einer Fahrtautorisierung 46 6.3.2 Sicherung durch die Technologie Fahrstraße 48 6.3.3 Gleisfreiprüfung durch die NSB-Ortung 54 6.3.4 Bahnübergangssicherungsanlagen 56 6.3.5 Wahl der ETCS-Betriebsart für NSB 57 6.3.6 Fahrzeugbewegungskategorien 58 6.4 Zusammenfassung 62 7 Auswertung des dänischen Regelwerks ORF 64 7.1 Auswahl und Eignung der ORF 64 7.2 Merkmale und Strukturierung der ORF 65 7.3 Klassifizierung der einzelnen betrieblichen Regeln 65 7.4 Eignung der ORF als generische Basisbetriebsvorschrift 69 7.4.1 Quantitative Auswertung 69 7.4.2 Qualitative Auswertung 71 7.4.3 Zusammenfassung 73 8 Regelwerk für die Neue Sekundärbahn 75 8.1 Übertragbarkeit des dänischen ETCS-Regelwerks 75 8.2 Entwicklung betrieblicher Regeln für ausgewählte Szenarien 77 8.2.1 Herangehensweise, Auswahlkriterien und Ziele 77 8.2.2 Verteilung der Mitarbeiterrollen 79 8.2.3 Erläuterungen zu einzelnen Szenarien 80 8.3 Anforderungen des Regelwerks an die NSB-Bedienoberfläche 87 8.4 Evaluation 88 8.5 Überführung in Anerkannte Regeln der Technik 92 8.5.1 Notwendigkeit von Bewertungen der Sicherheit 92 8.5.2 Ansatz für die Nachweisführung beim NSB-Regelwerk 93 8.6 Potentielle Hürden einer NSB-Realisierung 96 9 Zur Systematisierung von Betriebsverfahren 98 9.1 Zur Systematisierung anerkannter Betriebsverfahren anhand der generischen Anforderungen 98 9.2 Zur möglichen Systematisierung der NSB 101 9.2.1 Aktueller Forschungsstand nach PACHL 101 9.2.2 Erweiterung der Systematisierung auf die NSB nach FEUER 103 9.2.3 Zusammenfassung 105 9.3 Vorschlag für eine neue Regelwerkslandschaft 106 10 Fazit und Ausblick 109 10.1 Zusammenfassung 109 10.2 Weiterer Forschungsbedarf 110 / Our railroad customers expect and trust that their train journey will be carried out safely - and rightly so. Operational rules and railway signalling systems ensure the good reputation of the railway for being a safe mode of transport. Rules and interlocking have to interact in a targeted manner in order to jointly guarantee the necessary vehicle movement security. This applies equally to normal operation and to the fallback system. In case of signalling principles, a new system solution for vehicle movement safety on lightly loaded lines has been developed. It is called “New Secondary Railway”. It is characterized by a simplification of mode operation principles that have evolved over time and a farreaching reduction in the necessary infrastructure equipment while ensuring the actual level of safety. This results in the need to develop an operating procedure and an associated set of operational rules for the New Secondary Railway, which is the central research subject of this thesis. Additionally, a generic view of operational processes is used to procedureassured safety. It should be clarified if it is possible to create a generic basic operations rule book that is independent of the operating process and technology. This issue will be discussed on the basis of the newly drafted Danish ETCS rule book.:1 Einleitung 1 2 Abstraktionsebenen der betrieblich-technischen Schnittstelle 4 2.1 Systematische generische Beschreibungsmethode 4 2.2 Ebene des Systemverbunds Eisenbahn 6 2.3 Ebene des Prinzips der Abstandshaltung 8 2.4 Ebene des Betriebsverfahrens 9 2.5 Ebene des Regelwerks 11 2.6 Ebene der Systematisierung von Spezifikationen 12 2.7 Ebene der Systemzustände 13 2.8 Zusammenfassung 16 3 Generische Anforderungen an Betriebsverfahren und Regelwerke 17 3.1 Anforderungen zur Fahrzeugbewegungssicherung 17 3.1.1 Funktionsorientierte Anforderungen nach MASCHEK 18 3.1.2 Prozessorientierte Anforderungen nach HÖPPNER 21 3.1.3 Synthese 21 3.2 Anforderungen an Regelwerke 23 3.2.1 Integration und Modularisierung von Regelwerksinhalten 23 3.2.2 Funktions- oder prozessorientierte Darstellungsweise 24 3.2.3 Inhaltliche Anforderungen 25 3.2.4 Synthese 26 4 Europäische Aktivitäten zur betrieblichen Harmonisierung 27 4.1 Europäische Harmonisierungsprojekte 27 4.2 Status quo und Hemmnisse eines internationalen Verfahrens 28 4.3 Aktuelle Aktivitäten zur betrieblichen Harmonisierung 29 4.3.1 TSI „Verkehrsbetrieb und Verkehrssteuerung“ 29 4.3.2 ETCS-Handbuch für Triebfahrzeugführer 31 4.4 NSB – Katalysator einer betrieblichen Interoperabilität? 32 5 Systemarchitektur der Neuen Sekundärbahn 33 5.1 Gestaltung grundlegender Funktionalitäten 33 5.1.1 NSB-spezifische Komponenten der Sicherungstechnik 33 5.1.2 Wahrnehmung fahrdienstlicher Aufgaben durch den Triebfahrzeugführer 34 5.1.3 Ortung 36 5.1.4 Bedienung standardisierter ETCS-Schnittstellen 36 5.1.5 Zusammenfassung 37 5.2 Umsetzung der generischen Anforderungen 38 5.3 Exkurs: NSB als ZSS-Systemlösung mit dezentraler Logik 40 6 Betriebsverfahren der Neuen Sekundärbahn 42 6.1 Bedeutung von Kapazität und Fahrplan 42 6.1.1 Erhöhung der Kapazität durch Einrichtung von Teilblöcken 42 6.1.2 Schnittstelle zwischen Fahrplan im Datenspeicher und Sicherungslogik 43 6.2 Methode zur Entwicklung des NSB-Betriebsverfahrens 45 6.3 Realisierung der Fahrzeugbewegungssicherung 46 6.3.1 Ablauf zur sicheren Erzeugung einer Fahrtautorisierung 46 6.3.2 Sicherung durch die Technologie Fahrstraße 48 6.3.3 Gleisfreiprüfung durch die NSB-Ortung 54 6.3.4 Bahnübergangssicherungsanlagen 56 6.3.5 Wahl der ETCS-Betriebsart für NSB 57 6.3.6 Fahrzeugbewegungskategorien 58 6.4 Zusammenfassung 62 7 Auswertung des dänischen Regelwerks ORF 64 7.1 Auswahl und Eignung der ORF 64 7.2 Merkmale und Strukturierung der ORF 65 7.3 Klassifizierung der einzelnen betrieblichen Regeln 65 7.4 Eignung der ORF als generische Basisbetriebsvorschrift 69 7.4.1 Quantitative Auswertung 69 7.4.2 Qualitative Auswertung 71 7.4.3 Zusammenfassung 73 8 Regelwerk für die Neue Sekundärbahn 75 8.1 Übertragbarkeit des dänischen ETCS-Regelwerks 75 8.2 Entwicklung betrieblicher Regeln für ausgewählte Szenarien 77 8.2.1 Herangehensweise, Auswahlkriterien und Ziele 77 8.2.2 Verteilung der Mitarbeiterrollen 79 8.2.3 Erläuterungen zu einzelnen Szenarien 80 8.3 Anforderungen des Regelwerks an die NSB-Bedienoberfläche 87 8.4 Evaluation 88 8.5 Überführung in Anerkannte Regeln der Technik 92 8.5.1 Notwendigkeit von Bewertungen der Sicherheit 92 8.5.2 Ansatz für die Nachweisführung beim NSB-Regelwerk 93 8.6 Potentielle Hürden einer NSB-Realisierung 96 9 Zur Systematisierung von Betriebsverfahren 98 9.1 Zur Systematisierung anerkannter Betriebsverfahren anhand der generischen Anforderungen 98 9.2 Zur möglichen Systematisierung der NSB 101 9.2.1 Aktueller Forschungsstand nach PACHL 101 9.2.2 Erweiterung der Systematisierung auf die NSB nach FEUER 103 9.2.3 Zusammenfassung 105 9.3 Vorschlag für eine neue Regelwerkslandschaft 106 10 Fazit und Ausblick 109 10.1 Zusammenfassung 109 10.2 Weiterer Forschungsbedarf 110

Sowohl auf nationaler als auch internationaler Ebene sind bei elektronischen Stellwerken der ersten Generation die Schnittstellen zwischen den Bestandteilen der Leit- und Sicherungstechnik (LST) überwiegend herstellerspezifisch gestaltet. Das EULYNX-Konsortium befasst sich in Europa aus diesem Grund mit der Spezifizierung von standardisierten Schnittstellen im Bereich der LST. Die wesentlichen Ziele, welche es unter der Nutzung von konventioneller Netzwerktechnik und durch eine Entkopplung der Anlagenbestandteile zu erreichen gilt, sind das Fördern des Wettbewerbs zwischen der Signalbauindustrie, das Reduzieren der Lebenszykluskosten und das Verhindern der Obsoleszenz. Die Professur für Verkehrssicherungstechnik strebt für eine aktive Beteiligung an der Weiterentwicklung von standardisierten Schnittstellen den Aufbau von EULYNX-Versuchsständen an. Dazu betrachtet diese Masterarbeit die Hochrüstung der im Sicherungstechnischen Labor vorhandenen Bahnübergangssicherungsanlage (BÜSA) BUES 2000 auf eine EULYNX-Schnittstelle und analysiert verschiedene Varianten zur Gestaltung einer umgebenden Laboranlage sowie eines Versuchsstandes. Ein weiterer Forschungsgegenstand ist dabei die Recherche der erforderlichen Voraussetzungen zur Nutzung der konzipierten Laboranlage für Validierungsaufgaben. Den Abschluss dieser Ausarbeitung bildet ein Testkonzept, welches in der Form von Testspezifikationen sowohl für die Integration als auch die Validierung des Versuchsstandes verwendet werden kann.

Durch eine standardisierte elektronische Übergabe von Planungsdaten können deutliche Effizienzsteigerungen im Planungsprozess von technischen Anlagen erreicht werden. Für das Gewerk der Leit- und Sicherungstechnik (LST) wurde mit dem PlanPro-Datenmodell die Grundlage für eine solche durchgängige digitale Arbeitsweise geschaffen. Neben der Vermeidung von wiederholter manueller Datenerfassung trägt die Nutzung der PlanPro-Schnittstelle selbst bereits zu einer grundlegenden Qualitätssicherung bei. Darüber hinaus bietet die automatisierte Testung von Planungsdaten jedoch weiteres Beschleunigungspotenzial, das genutzt werden muss, um das zukünftig anstehende Projektvolumen bei gleichzeitig begrenzten Planungs- und Prüfressourcen bewältigen zu können. Die vorliegende Arbeit beschreibt einen Ansatz für eine automatisierte Prüfung von LST-Planungsdaten im PlanPro-Format mittels Schematron. Aufbauend auf einer allgemeinen Betrachtung zu den Möglichkeiten der Qualitätssicherung von XML-Daten und der Beschreibung der Schematron-Technologie werden Anforderungen an ein Testwerkzeug für den Einsatz bei der Planung von LST-Anlagen definiert. Thematisiert werden in diesem Kontext die Erstellung und Klassifizierung von Prüfregeln, die nutzergerechte Aufbereitung von Feststellungen sowie die Umsetzung im PlanPro-Werkzeugkoffer. Eine sicherheitsbezogene Bewertung, Erfahrungen aus der praktischen Anwendung und eine Analyse zur Übertragbarkeit des Ansatzes auf andere Datenformate runden die Arbeit ab.:1 Einleitung 1.1 Ausgangssituation 1.2 Zielstellung 1.3 Abgrenzung 1.4 Vorgehen 2 Grundlagen 2.1 Grundsätze des XML-Standards 2.1.1 Struktur des PlanPro-Datenmodells 2.2 Verankerung fachlicher Zusammenhänge im XML-Schema 2.2.1 Einschränkung der Befüllung mit Hilfe von Basistypen 2.2.2 Einschränkung der Befüllung mit Hilfe von Pattern 2.2.3 Pflichteigenschaft und Gruppierung von Attributen 2.2.4 Gegenseitiger Ausschluss von Attributen und Attributgruppen 2.2.5 Sicherstellung der Existenz von Verweiszielen mittels Key/Keyref 2.2.6 Flexibilisierung des Datenmodells für verschiedene Anwendungsfälle 2.3 Semantische Prüfung von XML-Daten 2.3.1 Technische Umsetzungsmöglichkeiten 2.3.2 Allgemeiner Ablauf einer Schematron-Prüfung 2.3.3 Anwendungsgebiete 2.3.4 Inhalt und Aufbau von Schematron-Regeln 2.3.5 Zuordnung von Regeln zu Mustern 2.3.6 Instanziierung von Schematron-Regeln 3 Einsatz von Schematron bei der Digitalen LST-Planung (PlanPro) 3.1 Integration in die funktionale Systemarchitektur PlanPro 3.2 Anforderungsspezifikation PlaZ LST 3.2.1 Allgemeine fachliche Grundsätze 3.2.2 Einbindung von PlaZ LST in den LST-Planungsprozess 3.2.3 PlaZ LST als Bestandteil des PlanPro-Werkzeugkoffers 3.2.4 Ablauf einer Prüfung 3.2.5 Ergebnisdarstellung (Ausgabeformate) 3.2.6 Ausgabe LST-fachlicher Bezeichnungen 3.2.7 Statusvergabe 3.2.8 Sortierung und Filterung der Ergebnisse 3.2.9 Gestaltung der Benutzeroberfläche 3.2.10 Technische Umsetzung 3.3 Konzept zur Erstellung und Verwaltung von Prüfregeln 3.3.1 Arbeitsablauf 3.3.2 Datenhaltung 3.4 Erstellung von Prüfregeln 3.4.1 Mindestanforderungen 3.4.2 Schwierigkeitsgrade 3.4.3 Optimierung von Prüfregeln und Modellierung 3.4.4 Optimierung und Verallgemeinerung von Prüfregeln 3.4.5 Statistische Auswertung erfasster Regeln 3.5 Nutzergerechte Aufbereitung von Fehlerausgaben 3.5.1 Visualisierung der Feststellungen 3.5.2 Optimierung von Fehlertexten 3.5.3 Verknüpfung von PlanPro-Werkzeugkoffer und LST-Planungswerkzeugen 3.6 Umsetzung PlaZ LST im PlanPro-Werkzeugkoffer 3.6.1 Vollständiger Feststellungsberichts als PDF 3.6.2 Feststellungsbericht in dynamischer HTML-Anzeige 3.7 Sicherheitsbezogene Bewertung des Schematron-Einsatzes bei der Prüfung von LST-Planungsdaten 3.8 Erfahrungen aus praktischer Anwendung (Fallstudien) 3.8.1 Musterbahnhof P-Hausen 3.8.2 Referenzprojekte 3.8.3 Pilotprojekte – Digitaler Knoten Stuttgart 3.8.4 Erkenntnisse und Erfahrungen aus BIM-Projekten 4 Übertragbarkeit des Ansatzes auf andere Datenformate (EULYNX DataPrep) 4.1.1 Semantische Übertragbarkeit der Prüfregeln 4.1.2 Technologische und technische Übertragbarkeit 5 Zusammenfassung und Ausblick 5.1 Zusammenfassung 5.2 Ausblick Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Literaturverzeichnis Erklärung Danksagung Anhang A: Spezifikation Plausibilitäts- und Zulässigkeitsprüfung LST (PlaZ LST) Anhang B: Semiformale Definition LST-fachlicher Bezeichner und Sortierkriterien Anhang C: Erweiterter Ablauf für die Erstellung und Änderung von PlaZ-Regeln Anhang D: Regeldokumentation / With a standardized electronic transfer of engineering data, significant increases in efficiency can be achieved in the engineering process of technical facilities. With the PlanPro data model, the basis for such a continuous digital working method has been created for control-command and safety systems (CCS). In addition to avoiding repeated manual data entry, the use of the PlanPro interface itself already contributes to fundamental quality assurance. Beyond that, the automated testing of engineering data offers further acceleration potential, which must be used to be able to cope with the future project volume with simultaneously limited engineering and checking resources. This paper describes an approach for an automated verification of CCS engineering data in PlanPro format using Schematron. Based on a general overview showing the possibilities of quality assurance for XML data and the description of the Schematron technology, requirements for a test tool to be used in the CCS engineering are defined. In this context, the creation and classification of test rules, the user-friendly presentation of findings, and the implementation in the PlanPro toolbox are handled. A safety evaluation, experiences from practical application and an analysis of the transferability of the approach to other data formats complete the work.:1 Einleitung 1.1 Ausgangssituation 1.2 Zielstellung 1.3 Abgrenzung 1.4 Vorgehen 2 Grundlagen 2.1 Grundsätze des XML-Standards 2.1.1 Struktur des PlanPro-Datenmodells 2.2 Verankerung fachlicher Zusammenhänge im XML-Schema 2.2.1 Einschränkung der Befüllung mit Hilfe von Basistypen 2.2.2 Einschränkung der Befüllung mit Hilfe von Pattern 2.2.3 Pflichteigenschaft und Gruppierung von Attributen 2.2.4 Gegenseitiger Ausschluss von Attributen und Attributgruppen 2.2.5 Sicherstellung der Existenz von Verweiszielen mittels Key/Keyref 2.2.6 Flexibilisierung des Datenmodells für verschiedene Anwendungsfälle 2.3 Semantische Prüfung von XML-Daten 2.3.1 Technische Umsetzungsmöglichkeiten 2.3.2 Allgemeiner Ablauf einer Schematron-Prüfung 2.3.3 Anwendungsgebiete 2.3.4 Inhalt und Aufbau von Schematron-Regeln 2.3.5 Zuordnung von Regeln zu Mustern 2.3.6 Instanziierung von Schematron-Regeln 3 Einsatz von Schematron bei der Digitalen LST-Planung (PlanPro) 3.1 Integration in die funktionale Systemarchitektur PlanPro 3.2 Anforderungsspezifikation PlaZ LST 3.2.1 Allgemeine fachliche Grundsätze 3.2.2 Einbindung von PlaZ LST in den LST-Planungsprozess 3.2.3 PlaZ LST als Bestandteil des PlanPro-Werkzeugkoffers 3.2.4 Ablauf einer Prüfung 3.2.5 Ergebnisdarstellung (Ausgabeformate) 3.2.6 Ausgabe LST-fachlicher Bezeichnungen 3.2.7 Statusvergabe 3.2.8 Sortierung und Filterung der Ergebnisse 3.2.9 Gestaltung der Benutzeroberfläche 3.2.10 Technische Umsetzung 3.3 Konzept zur Erstellung und Verwaltung von Prüfregeln 3.3.1 Arbeitsablauf 3.3.2 Datenhaltung 3.4 Erstellung von Prüfregeln 3.4.1 Mindestanforderungen 3.4.2 Schwierigkeitsgrade 3.4.3 Optimierung von Prüfregeln und Modellierung 3.4.4 Optimierung und Verallgemeinerung von Prüfregeln 3.4.5 Statistische Auswertung erfasster Regeln 3.5 Nutzergerechte Aufbereitung von Fehlerausgaben 3.5.1 Visualisierung der Feststellungen 3.5.2 Optimierung von Fehlertexten 3.5.3 Verknüpfung von PlanPro-Werkzeugkoffer und LST-Planungswerkzeugen 3.6 Umsetzung PlaZ LST im PlanPro-Werkzeugkoffer 3.6.1 Vollständiger Feststellungsberichts als PDF 3.6.2 Feststellungsbericht in dynamischer HTML-Anzeige 3.7 Sicherheitsbezogene Bewertung des Schematron-Einsatzes bei der Prüfung von LST-Planungsdaten 3.8 Erfahrungen aus praktischer Anwendung (Fallstudien) 3.8.1 Musterbahnhof P-Hausen 3.8.2 Referenzprojekte 3.8.3 Pilotprojekte – Digitaler Knoten Stuttgart 3.8.4 Erkenntnisse und Erfahrungen aus BIM-Projekten 4 Übertragbarkeit des Ansatzes auf andere Datenformate (EULYNX DataPrep) 4.1.1 Semantische Übertragbarkeit der Prüfregeln 4.1.2 Technologische und technische Übertragbarkeit 5 Zusammenfassung und Ausblick 5.1 Zusammenfassung 5.2 Ausblick Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Literaturverzeichnis Erklärung Danksagung Anhang A: Spezifikation Plausibilitäts- und Zulässigkeitsprüfung LST (PlaZ LST) Anhang B: Semiformale Definition LST-fachlicher Bezeichner und Sortierkriterien Anhang C: Erweiterter Ablauf für die Erstellung und Änderung von PlaZ-Regeln Anhang D: Regeldokumentation

In dieser Arbeit wird ein Gesamtmodell nach der Methodik des Building Information Modeling (BIM) erstellt, um einige praktische Fragestellungen bei der Integration von Planungsdaten der Leit- und Sicherungstechnik (LST) in dieses Modell zu untersuchen. Hierbei wird der Datenaustausch zwischen ProSig 7 als Planungswerkzeug für die LST und KorFin als BIM-Software über die Schnittstelle „PlanPro“ realisiert. Anhand zweier Anwendungsfälle (LST-fachliche Änderung und Änderung der Trassierung) wird ein Workflow zum Datenaustausch zwischen beiden Softwaresystemen aufgestellt. Die vorhandenen Planungsdaten müssen für die Integration ins BIM-Modell mit einer 3D-Repräsentation versehen werden. Hierfür wird ein Konzept zum automatisierten Zusammenbau von Haupt- und Vorsignalen des Signalsystems Ks aus einzelnen Bauteilen anhand der PlanPro-Daten entwickelt. Mit PlanPro existiert neben den Gleisnetzdaten (GND) eine weitere Quelle, aus der eine Trassierung ins BIM-Gesamtmodell importiert werden kann. Es werden eventuelle Unterschiede in der Gleislage in Abhängigkeit von der Datenquelle und der verwendeten Software untersucht. Dabei zeigen sich signifikante Abweichungen in der Konstruktion der Übergangsbögen zwischen KorFin und ProSig und notwendige Anpassungen bei Ableitung der Gradiente aus PlanPro-Daten im Vergleich zur Nutzung der GND. Abschließend wird auf das neue Datenhaltungssystem AVANI eingegangen und beleuchtet, inwiefern eine Integration der Speicherung der erzeugten Daten über verschiedene Betrachtungsebenen hinweg (PlanPro, BIM und AVANI) sinnvoll wäre.:Aufgabenstellung Autorenreferat Abstract Thesen zur wissenschaftlichen Arbeit Inhaltsverzeichnis 1 Motivation und Zielstellung 2 Grundlagen 2.1 Building Information Modeling 2.2 Geoinformationssysteme 2.3 Gleisnetzdaten 2.4 PlanPro 2.5 Software 2.5.1 KorFin Model und KorFin 2.5.2 ProSig 2.5.3 QGIS 3 Erstellung des Bestandsmodells 3.1 Geodaten Sachsens 3.2 Eisenbahnspezifische Daten 3.2.1 Bf Mosel 3.2.2 Bf P-Hausen 3.2.3 Warum P-Hausen? 3.2.4 Import in KorFin 3.3 Versionsverwaltung mit Git 4 Praktische Untersuchungsschwerpunkte 4.1 Entwurf eines Workflows zum Datenaustausch 4.1.1 Anwendungsfall: LST-fachliche Änderung 4.1.2 Anwendungsfall: Trassierungsänderung 4.1.3 Ableitung eines allgemeingültigen Workflows 4.2 Bauteilbibliothek LST 4.2.1 Aktueller Stand 4.2.2 Entwurf eines Konzepts zum automatisierten Zusammenbau von Bauteilen zu Signalmodellen anhand der PlanPro-Daten 4.2.3 Weitere relevante Aspekte 4.2.4 Einbindung von 3D-Modellen für die Signale im Bf P-Hausen 4.3 Single source of truth 4.3.1 Vergleich der Gleislage der GND und PP-XML in KorFin 4.3.2 Vergleich der Gleislage in ProSig mit den auf der PP-XML basierenden Gleisen in KorFin 4.3.3 Vergleich der Höhenlagen 4.3.4 Zu verwendendes Koordinatenreferenzsystem 5 AVANI 6 Zusammenfassung und Ausblick Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Quellenverzeichnis Erklärung Anhang A: Bauteilübersicht zum Konzept des automatisierten Zusammenbaus von Signalmodellen (Signalsystem Ks) Anhang B: Ausgangsdaten zum Konzept des automatisierten Zusammenbaus von Signalmodellen (Signalsystem Ks) Anhang C: Pseudocode zum Konzept des automatisierten Zusammenbaus von Signalmodellen (Signalsystem Ks) Anhang D: Datenfluss für den Import der eisenbahnspezifischen Daten ins BIM-Gesamtmodell Anhang E: Sicherungstechnische Lagepläne zum Anwendungsfall „LST-fachliche Änderung“ Anhang F: Workflow für den Datenaustausch zwischen ProSig 7 und KorFin Anhang G: Protokolle persönlicher Kommunikation / In this thesis, a 3D model is created according to the methodology of Building Information Modeling (BIM) in order to investigate some practical questions regarding the integration of signalling engineering data into this model. The exchange of data between ProSig 7 as a signalling planning tool and KorFin as a software for BIM applications is achieved through the usage of the “PlanPro” interface. Based on two specific use cases (change in signalling content and change in track layout) a workflow for the exchange of data between the two software systems is developed. To be integrated into the BIM model, the existing planning data must be enriched with a 3D representation. For this purpose, a concept is being developed for the automated assembly of distant and main signals (signalling system “Ks”) from individual components using the PlanPro data. With PlanPro, another source beside the track network data is available from which the alignment can be imported into the BIM model. Possible differences in track geometry are examined depending on the data source and the software used. Significant discrepancies in the construction of transition curves between KorFin and ProSig are revealed, as well as the need for adjusting the deduction of gradient profiles from PlanPro compared to the usage of the track network data. Finally, the new data management system AVANI is examined regarding the usefulness of an integrated data storage across different levels of perspective (AVANI, BIM and PlanPro).:Aufgabenstellung Autorenreferat Abstract Thesen zur wissenschaftlichen Arbeit Inhaltsverzeichnis 1 Motivation und Zielstellung 2 Grundlagen 2.1 Building Information Modeling 2.2 Geoinformationssysteme 2.3 Gleisnetzdaten 2.4 PlanPro 2.5 Software 2.5.1 KorFin Model und KorFin 2.5.2 ProSig 2.5.3 QGIS 3 Erstellung des Bestandsmodells 3.1 Geodaten Sachsens 3.2 Eisenbahnspezifische Daten 3.2.1 Bf Mosel 3.2.2 Bf P-Hausen 3.2.3 Warum P-Hausen? 3.2.4 Import in KorFin 3.3 Versionsverwaltung mit Git 4 Praktische Untersuchungsschwerpunkte 4.1 Entwurf eines Workflows zum Datenaustausch 4.1.1 Anwendungsfall: LST-fachliche Änderung 4.1.2 Anwendungsfall: Trassierungsänderung 4.1.3 Ableitung eines allgemeingültigen Workflows 4.2 Bauteilbibliothek LST 4.2.1 Aktueller Stand 4.2.2 Entwurf eines Konzepts zum automatisierten Zusammenbau von Bauteilen zu Signalmodellen anhand der PlanPro-Daten 4.2.3 Weitere relevante Aspekte 4.2.4 Einbindung von 3D-Modellen für die Signale im Bf P-Hausen 4.3 Single source of truth 4.3.1 Vergleich der Gleislage der GND und PP-XML in KorFin 4.3.2 Vergleich der Gleislage in ProSig mit den auf der PP-XML basierenden Gleisen in KorFin 4.3.3 Vergleich der Höhenlagen 4.3.4 Zu verwendendes Koordinatenreferenzsystem 5 AVANI 6 Zusammenfassung und Ausblick Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Quellenverzeichnis Erklärung Anhang A: Bauteilübersicht zum Konzept des automatisierten Zusammenbaus von Signalmodellen (Signalsystem Ks) Anhang B: Ausgangsdaten zum Konzept des automatisierten Zusammenbaus von Signalmodellen (Signalsystem Ks) Anhang C: Pseudocode zum Konzept des automatisierten Zusammenbaus von Signalmodellen (Signalsystem Ks) Anhang D: Datenfluss für den Import der eisenbahnspezifischen Daten ins BIM-Gesamtmodell Anhang E: Sicherungstechnische Lagepläne zum Anwendungsfall „LST-fachliche Änderung“ Anhang F: Workflow für den Datenaustausch zwischen ProSig 7 und KorFin Anhang G: Protokolle persönlicher Kommunikation