Announcement Digital Rail Summer School (DRSS) 2020

Announcement (by Deutsche Bahn) in English, French, and Russian

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


  • 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)


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

Preliminary Courses

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).

Project Phase

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.

Lab- and Demo Phase

The lab and demo phase consists of one week with talks held by experts from academia and industry, as well as excursions. Through this event, the Digital Rail Summer School creates a platform for mutual teaching, exchange and networking.

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 (

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.