Digital Rail Summer School 2020

(Text in English below.)

Digitalisierung bei der Deutschen Bahn (und im gesamten Bahnsystem) bedeutet nicht nur die Einführung neuer Geräte und computergestützter Verfahren, sondern Digitalisierung steht auch für neue Herausforderungen bei der Aus- und Weiterbildung aller Beteiligter. Digitalisierung bei der Deutschen Bahn ist ein Querschnittsthema, bei dem Informatik-Sachverstand mit Wissen zum Eisenbahnbetrieb und zum Zulassungswesen kombiniert werden müssen. Kein einziger Studien- oder Ausbildungsgang bringt heute alle diese Aspekte unter einen Hut.

Die in der Informatik derzeit populären Programmiersprachen – wie Python, Java, JavaScript, Objective-C, oder .NET – eignen sich zwar gut für dynamische Systeme, agile, Web-basierte Verfahren und insbesondere die App-Entwicklung, jedoch ist keine dieser Programmiersprachen ohne Einschränkungen zulassungsfähig für sicherheitsrelevante Systeme im Bahnbetrieb. Gleichzeitig sind moderne, modell- und simulationsgetriebene Entwurfsverfahren unabdingbar für die Entwicklung neuer, wartbarer Software für den Bahnbetrieb.

it IT-Systeme (Software Engineering) center->it certification Zulassung center->certification railway Bahnwesen (digitale LST) railway->center

Abbildung 1: Die drei Dimensionen der Digitalisierung

Werden dagegen die betrieblich-technischen Systemfunktionen des Bahnbetriebs – wie zulässige Geschwindigkeiten, Längen/Abstände, Fahrstraßen, Fahrerlaubnisse (Fahrdienstvorschrift, Signalbuch) – als Ausgangspunkt genommen, so gibt es dort mit der Einführung digitaler Leit- und Sicherungstechnik eine Vielzahl von Veränderungen. Stellbezirke werde signifikant größer, der Übergang zwischen Bahnhof und Strecke verwischt. Diese Umstände resultieren in neuen Vorschriften (bspw. für ETCS-2-Betrieb), die im Störungsfall zu erheblichen Kapazitätseinbrüchen führen können. Störungsfälle werden im Bahnbetrieb traditionell ausführlich getestet. Allerdings finden diese Tests stets auf Ebene des Gesamtsystems statt. Im Anbetracht der Notwendigkeit Komponenten häufig zu aktualisieren ist das zu aufwändig und ineffizient. Anders als in der Informatik werden im Bahnbetrieb Aktualisierungen bislang kaum systematisch getestet (etwa durch Fehlerinjektion, agile Verfahren oder DevOps).

Das System Eisenbahn ist inhärent eng mit dem öffentlichen Raum verflochten, wodurch traditionell sehr hohe Anforderungen an die Sicherheit des Bahnverkehrs gestellt werden. Die Eisenbahn muss nachweislich jederzeit alle entsprechenden gesetzlichen Anforderungen einhalten – sowohl hinsichtlich der eingesetzten technischen Mittel, als auch im laufenden Betriebsgeschehen. Das Zulassungswesen für den Bahnbetrieb basiert bislang auf Äquivalenzbetrachtungen. Ein neues System muss mindestens so sicher sein wie das alte System. Gelingt der Nachweis (aufgrund von Redundanz, Kodierungstheorie, Zerstörungsversuchen, etc.), so kann man das neue System in Verkehr bringen. Gleichzeitig ist ein neues Zulassungsverfahren für diese Systemklasse definiert. Paradigmenwechsel, wie die verteilte Implementierung von Leit- und Sicherungstechnik oder ein Failover über Systemgrenzen hinweg, erfordern auch bei der Zulassung neue Ansätze.

Das bisherige Zulassungswesen basiert auf systematischen Methoden (z. B. formuliert in EN 5012x), die einerseits die Komplexität des Eisenbahnsystems deterministisch strukturieren und auf dieser Basis eine Nachweisführung ermöglichen. Damit sind Zulassungsprozesse für Eisenbahnsysteme per se sehr aufwändig. Sie führen zu dem typischen Phänomen im Eisenbahnsektor, wonach einzelne Komponenten zur Zulassung gebracht werden und daraufhin möglichst oft und möglichst lange in andere Systeme (und nachfolgende Generationen) "vererbt" werden. All dies steht im Gegensatz zu den technischen Möglichkeiten digitaler Systeme und zu den zunehmend erkennbaren Mechanismen digitalisierter Märkte. Diese Mechanismen betreffen insbesondere der Bereitschaft, aufwändige Zulassungsverfahren durchzuhalten (und vorzufinanzieren) und den Kapitalrückfluss mit langen Produktlebenszyklen sicherzustellen. Vor allem im Verlauf der langen Lebenszyklen der Produkte im Eisenbahnsektor muss damit gerechnet werden, dass einzelne Komponenten nicht mehr lieferbar sein könnten (Obsoleszenz).

Darüber hinaus ist absehbar, dass in den kommenden Jahren lernende Systeme und Algorithmen auf Basis künstlicher Intelligenz einen Reifegrad erlangen werden, der es ihnen erlaubt Funktionen in der Betriebsführung der Eisenbahnen zu erfüllen. Diese Ansätze stehen jedoch im Gegensatz zur bisherigen "volldeterministischen" Zulassung, wonach Sicherheitsnachweise für Systeme und Komponenten nur auf einem vollständig vorhersehbaren Verhalten basieren.

All dies heißt, dass neue Ideen gefunden werden müssen, mit denen die Sicherheit des Eisenbahnsystems und des Eisenbahnbetriebs erstens tatsächlich sichergestellt ist und zweitens vorher nachweisbar ist. Als Teil der Systementwicklung ist die Nachweisführung zur Betriebstauglichkeit einschließlich Sicherheit eine Aufgabe der "Inverkehrbringer". Damit dieser Prozess möglichst zielorientiert, effizient und effektiv abläuft, bedarf es sowohl auf Seiten der künftigen Systementwickler als auch der künftigen Systemanwender einer Sensibilisierung auf die jeweiligen Rollen und Zuständigkeiten, auf das Ziel, auf den Weg dorthin, auf die Randbedingungen und vor allem auf Ideen um die Herausforderungen der Zulassung bahntechnischer Systeme im Zeitalter der Digitalisierung zu meistern.

Mit der Digital Rail Summer School 2020 (DRSS 2020) wollen wir die drei Dimensionen der Digitalisierung im Bahnbetrieb adressieren, nämlich: Informatik, Bahnbetrieb und Zulassungswesen. Als Ergebnisse der DRSS 2020 sehen wir:

  • Ein integriertes Aus- und Weiterbildungskonzept
  • Dissemination von Ergebnissen über Videos/Poster
  • Basisarbeit für Projektanträge für Digitalisierungsprojekte (mFUND, etc.)
  • ECTS-Leistungspunkte (Credits) für Studierende der beteiligten Universitäten

Partner

  • Hasso-Plattner-Institut der Universität Potsdam (HPI)
  • Fachgebiet Bahnbetrieb und Infrastruktur, Technische Universität Berlin (BBI TUB)
  • IFB - Institut für Bahntechnik Berlin (IFB)
  • DB Netze, DB Institute of Technology, DB Systel (DB)
  • TU Chemnitz (TUC)
  • TU Braunschweig (TUBS)
  • TU Dresden (TUD)

Struktur

Die DRSS 2020 besteht aus vier großen Blöcken. Auf einen einwöchigen, integrierten Vorkurs (der zweimal angeboten wird, 11.-15. Mai und 15.-19. Juni) folgt eine zweimonatige Projektphase. Die eigentliche Summer School wird vom 21.-25. September im Umfeld des Digitalen Testfelds vom DB Institute of Technology veranstaltet. Ergebnisse sollen schließlich präsentiert werden.

cluster_projekt cluster_demo cluster_dissemination vorkurse Integrierte Vorkurse Mai, Juni online projekt Projektphase Juni/Juli HPI, TUB, IFB, TUBS, TUC, TUD, DB vorkurse->projekt demo Labor- und Demophase 21.-24. September Jöhstadt, digitales Testfeld projekt->demo dissemination Dissemination (Poster, Video) 24.-25. September Jöhstadt demo->dissemination

Abbildung 2: Ablauf der Digital Rail Summer School

Die integrierten Vorkurse müssen aufgrund der gegenwärtigen Situation in digitaler Form durchgeführt werden. Dafür werden vorproduzierte Videos bereitgestellt und interaktive Diskussionsrunden per Video-Konferenzschaltung eingerichtet. Durch verschiedene SprecherInnen (FachexpertInnen) werden folgende Themen adressiert (Liste noch nicht vollständig); die Präsentation der Themen variiert in Länge (mindestens vier Stunden) und Lehrform (z. B. Übung, Workshop, Vorlesung):

  • Erstellen von Systemspezifikationen (BBI/IFB)
  • Softwaretechnik/Softwareentwicklung-Know-how (HPI)
  • Systemgestütztes Anforderungsmanagement (IFB)
  • Bahnbetrieb im Kontext der Digitalisierung; Entwicklung und Beschaffung bahntechnischer Systeme (IFB)
  • Systementwicklung und –analyse durch Co-Simulation und Fehlerinjektion (HPI)
  • Planung und praktische Durchführung des Bahnbetriebs (TUB)
  • Safety/Security bei der Entwicklung eingebetteter Software (TUC)

Ziel der Vorkurse ist es vor allem, TeilnehmerInnen mit unterschiedlichem Vorwissen fachübergreifendes Wissen zu vermitteln. Darüber hinaus ist es möglich, domänenspezifisches Wissen zu vertiefen. Betrachtet man Abbildung 1, so bewegen wir uns entlang der Achsen in Richtung Koordinatenursprung. Mit den folgenden Projekten sowie vor allem der Labor- und Demophase im Erzgebirge wird die DRSS 2020 den Fokus auf die Integration des Wissens aus allen drei Dimensionen legen. Dazu sind weitere Vorträge von ExpertInnen im September (3. Schritt) geplant.

Zweiter Schritt nach den Vorkursen ist die Projektphase. Hier sollen TeilnehmerInnen der DRSS 2020 Erfahrungen bei der praktischen Umsetzung von Software-Projekten für den Bahnbetrieb sammeln können. Wir planen derzeit folgende Projekte:

  • EULYNX Live – Co-Simulation mit Hardware-in-the-Loop; Ansteuerung eines Weichenantriebs aus dem Simulationsmodell heraus (zunächst im universitären IoT-Lab am HPI, dann im Digitalen Testfeld)
  • Automatisiertes Fahren

Dabei wird es den TeilnehmerInnen möglich werden, unterschiedliche Schwerpunkte zu setzen. Das HPI betreut den Schwerpunkt der Systemerstellung und Programmierung, BBI und IFB fokussieren auf den Projektablauf und werden mit den TeilnehmerInnen Prozessbestandteile wie Anforderungserfassung, Risikobetrachtung und Zulassungsprozess durchlaufen.

Die TeilnehmerInnen werden sich in der Projektphase austauschen, z. B. durch Vor-Ort-Treffen oder Telefonkonferenzen.

Leistungserfassungsprozess

Die Vorkurse werden als Blockkurse durchgeführt (Montag 13:00 bis Freitag 13:00). Sie umfassen 12 Vorlesungs-/Vortrags-Einheiten von 90 Minuten und 2 Diskussionsrunden. Vom Umfang her entspricht das einer einsemestrigen Vorlesung an den beteiligten Universitäten. Die Labor- und Demophase im Digitalen Testfeld (Erzgebirge) veranschlagen wir mit demselben Umfang.

Wichtig für Studierende der beteiligten Universitäten: sowohl der Vorkurs als auch die Projektphase werden je nach Universität individuell mit ECTS-Punkten (European Credit Transfer System) veranschlagt. Die einzelnen Universitäten werden ihren Studierenden die Möglichkeit geben, eine mündliche Prüfung im Anschluss an die DRSS 2020 abzulegen und somit benotete ECTS-Punkte zu erwerben.

Universität Vorkurse Projekte
HPI

3 ECTS

(ITSE-A/E, OSIS-K/T, SAMT-K/T, CODS-K/T/S, CYAD-K/T/S)

3 ECTS

(ITSE-A/E, OSIS-K/T, SAMT-K/T, CODS-K/T/S, CYAD-K/T/S)

TUB 3 ECTS 3 ECTS
TUBS 3 ECTS 3 ECTS
TUC 5 ECTS
TUD 3 ECTS 3 ECTS

Zielgruppe

Die Veranstaltung richtet sich an Studierende (aller Universitäten, aller Fachrichtungen), die sich für IT-Systeme bei der Bahn interessieren. Im Mittelpunkt stehen dabei eingebettete Systeme für sicherheitsrelevante Funktionen zur Steuerung von Hardware im Bahnsystem und die Modellierung von sicherheitskritischer Hard- und Software mit Ansätzen wie SysML und SCADE.

Auch MitarbeiterInnen der Deutschen Bahn, befreundeter europäischer Bahnen sowie der Herstellerfirmen im Bereich Digitaler Leit- und Sicherungstechnik können gern an der DRSS 2020 teilnehmen.

Kosten

Für Studierende fallen für die Labor- und Demophase im digitalen Testfeld Jöhstadt Kosten von rund 120 € für Unterkunft und Verpflegung an. TeilnehmerInnen aus anderen Bereichen bitten wir die Kosten individuell per E-Mail (drss-2020-application@lists.myhpi.de) zu erfragen.



English

Digitalization at Deutsche Bahn (and throughout the entire rail system) not only means the introduction of new devices and computer-aided processes, but also represents new challenges in the training and further education of all people involved. Digitalization by Deutsche Bahn is a cross-cutting issue in which IT expertise must be combined with knowledge of railway operations and licensing. There is not a single course of study or training today which brings together all of these aspects.

The programming languages, which are currently popular in computer science – such as Python, Java, JavaScript, Objective-C, or .NET – are well suited for dynamic systems, agile, web-based processes and app development. However, none of these programming languages can be approved for safety-relevant systems in rail operations without restrictions.

it IT Systems (Software Engineering) center->it certification Certification center->certification railway Railway (Digital CCS) railway->center

Figure 1: The three dimensions of the Digitalization

On the other hand, if the operational-technical system functions of rail operations – such as permissible speeds, lengths/distances, routes, track authority (driving regulations, code of signals) – are taken as a starting point, there are a multitude of changes with the introduction of digital control and safety technology. Interlocking control areas are significantly larger, the transition between stations and route are blurred. These circumstances result in new regulations (e.g., for ETCS-2 operation), which can lead to significant drops in capacity in the event of a fault. In rail operations, malfunctions are traditionally extensively tested. However, these tests take place at the level of the overall system. In view of the need to update components frequently, this is too complex and inefficient. Unlike in computer science, updates have so far hardly been systematically tested in rail operations (for example through fault injection, agile processes or DevOps).

The rail system is inherently closely intertwined with public space, which traditionally places very high demands on the safety of rail traffic. Rail systems must demonstrably comply with all relevant legal requirements at all times – both with regard to the employed technical means and with regard to the ongoing operations. The approval processes for rail operations have so far been based on equivalence considerations: new systems must be at least as secure as the former system. If this can be proven successfully (due to redundancy, coding theory, attempts at destruction, etc.), the new system can be placed on the market. At the same time, a new approval procedure has been defined for this system class. Paradigm changes, such as the distributed implementation of control command and signaling technology or failover across system boundaries also require new approaches for their approval.

Previous approval systems are based on systematic methods (e.g., as formulated in EN 5012x), which on the one hand structure the complexity of the rail system in a deterministic manner and enable evidence to be provided on this basis. Thus, the approval processes for railway systems are very effortful. They lead to the typical phenomenon in the railway sector, which is that individual components are approved and then "inherited" into other systems (and subsequent generations) as often and as long as possible. All of this contrasts with the technical possibilities of digital systems and the increasingly recognizable mechanisms of digitized markets. These mechanisms relate in particular to the willingness to endure (and pre-finance) time-consuming approval processes and to ensure the return of investment over the long life cycles of products. Especially due to the those long life cycles in the rail sector, it is to be expected that individual components may no longer be available (obsolescence).

Furthermore, it is foreseeable that machine learning systems and algorithms based on artificial intelligence will reach a level of maturity in the near future that will allow them to perform functions in the operational management of the railways. Nevertheless, these approaches challenge to the aforementioned "fully deterministic" approval. It hence suggests itself, that for systems and components, for which safety evidence cannot be based on completely predictable behavior, new approval processes are required.

All of this means that new ideas have to be found which firstly actually ensure the safety of the rail system and the railroad operation, and secondly which are verifiable demonstrated beforehand. As part of the system development, the verification of operational suitability and operational safety is a concern of the distributor. In order for this process to be as goal-oriented, efficient and effective as possible, both future system developers and future system users need to be made aware of the respective roles and responsibilities, the goal, the way to get there, the boundary conditions and, above all, the ideas to master the challenges of approving railway systems in the digitalization era.

With the Digital Rail Summer School 2020 (DRSS 2020), we address the three dimensions of digitalization in rail operations, namely: IT, rail operations and licensing. As the results of DRSS 2020, we see:

  • An integrated education and training concept
  • Dissemination of results via videos / posters
  • ground work for project applications for digitalization projects (mFUND, etc.)
  • ECTS credit points for students of the participating universities

Partners

  • Hasso Plattner Institute of the University of Potsdam (HPI)
  • Track and Railway Operations Group, Technical University of Berlin (BBI TUB)
  • IFB - Institut für Bahntechnik Berlin (IFB)
  • DB Netze, DB Institute of Technology, DB Systel (DB)
  • Chemnitz University of Technology (TUC)
  • Technical University of Braunschweig (TUBS)
  • Technical University of Dresden (TUD)

Structure

The DRSS 2020 consists of four large blocks. A one-week, integrated preliminary course (which is offered twice, May 11-15 and June 15-19) is followed by a two-month project phase. The actual summer school will be held from 21th to 25th September in the area of the digital test field by the DB Institute of Technology. Finally, results are to be presented.

cluster_projekt cluster_demo cluster_dissemination vorkurse Integrated Pre-courses May, June online projekt Project Phase June/July HPI, TUB, IFB, TUBS, TUC, TUD, DB vorkurse->projekt demo Lab- and Demo Phase September 21-24 Jöhstadt, digitales Testfeld projekt->demo dissemination Dissemination (Poster, Video) September 24-25 Jöhstadt demo->dissemination

Figure 2: Structure of the Digital Rail Summer School

The integrated preliminary courses are to take place at the Hasso Plattner Institute of the University of Potsdam, at the Technical University of Berlin, as well as at the Institut für Bahntechnik (Institute for Railway Technology) in Berlin. The following topics are addressed by various experts (list not yet complete); the presentation of the topics varies in length (at least four hours) and form of teaching (e.g., exercise, workshop, lecture):

  • Creating system specifications (BBI/IFB)
  • Software engineering and software development know-how (HPI)
  • System-based requirements management (IFB)
  • Railway operations in the context of digitalization; development and procurement of railway equipment (IFB)
  • System development and analysis through co-simulation and software fault injection (HPI)
  • Planning and practical implementation of rail operations (TUB)
  • Safety/security in the development of embedded software (TUC)

The primary goal of the preliminary courses is to impart cross-disciplinary knowledge to participants with different foreknowledge. Moreover, it is possible to deepen domain-specific knowledge. Looking at Figure 1, we move along the axes towards the center. With the following projects and especially the laboratory and demo phase in the Ore Mountains region, DRSS 2020 will focus on integrating knowledge from all three dimensions. Further lectures by experts are planned for September (3rd block).

The second block after the preliminary courses is the project phase. Here, participants of the DRSS 2020 are able to gain experience in the practical implementation of software projects for rail operations. We are currently planning the following projects:

  • EULYNX Live - co-simulation with hardware-in-the-loop; control of a switch motor from the simulation model (first in the IoT lab at HPI, then in the digital test field)
  • Automated driving

The participants will be able to set individual priorities. The HPI mentors the topics of system creation and programming, the BBI and IFB focus on the project process and will go through process components such as requirements recording, risk assessment and approval process with the participants.

The participants will exchange ideas in the project phase, e.g., through on-site meetings or conference calls.

Target Group

The event is aimed at students (from all universities, from all subject areas) who are interested in IT systems at Deutsche Bahn. The focus is on embedded systems for safety-relevant functions for controlling hardware in the rail system and the modeling of safety-critical hardware and software with approaches such as SysML and SCADE.

Even employees of Deutsche Bahn, European Railways partners and the manufacturing companies in the field of digital control and safety systems can participate in the DRSS 2020.

Fees

For the lab and demo phase in the Ore Mountains region, students will be charged approximately 120 € for room and board. All other participants are kindly requested to individually inquire the charges via email (drss-2020-application@lists.myhpi.de).