IT Systems in Public Transport: Information Technology for Transport Operators and Authorities

By Gero Scholz

At first glance, public transport in the majority of cities and regions around the world would not be considered high-tech by most passengers. However, when taking a closer look at the systems that are necessary to attract/retain passengers and ensure efficient operations, the importance of IT and the high-tech nature of the public transport sector becomes clear. Transport operators use advanced information technology products in order to plan, optimise and manage their fleets and staff. Sophisticated software systems support and drive these tasks. Furthermore, these systems are used to manage daily operations, which includes monitoring and dispatching of rolling stock and crew, providing passengers with realtime information, electronic ticketing and much more.

As in many industries, public transport and associated IT standards vary around the world. Several operators have invested significantly in public transport, while others have a great deal of catching up to do. Strategic investments in public transport can significantly improve the quality of life in cities and regions. IT systems play a vital role in supporting this aim.

Why write this book? For what purpose and for which audience? Above all, this book is intended for those who develop, implement and operate public transport IT systems. These readers need to be familiar with the software and understand public transport IT systems both at a high level and in detail. 

This is achieved through descriptions of public transport business processes and a detailed illustration of a comprehensive systems data model. Furthermore, the book was written for professors and students of transport and IT, at universities and other institutes of higher education. Finally, the book is intended for those in the public transport industry who use these systems and want, or need, to understand the systems in further detail.

• Language: English
• Publisher: dpunkt.verlag
• Release date: Aug 24, 2016
• ISBN: 9783960880523

Book preview

cover-image

During his studies at LMU Munich, Dr. Gero Scholz focused on the area of operations research. After obtaining his doctorate in logistics he was responsible for various large projects at ds&m in Munich, including for Deutsche Bahn and Lufthansa. From 1995 to 2003 he was director of the central IT department at Dresdner Bank and following this, he became CIO of the transaction banking company division. From 2004 to 2007 he was director of development at IVU Traffic Technologies AG and from 2008 to 2010 chief software architect. He is currently active as an independent consultant in the field of transport and logistics.

IT Systems in Public Transport

Information Technology for Transport Operators and Authorities

Gero Scholz

Dr. Gero Scholz

IVU Traffic Technologies AG

Bundesallee 88, 12161 Berlin, Germany

Telephone: [phone]

Fax: [phone]

E-Mail: [e-mail]

Editor: Dr. Michael Barabas

English translation: Hannah Sheeran

Copy-Editing: Dr. Claus Dohmen, Dr. Olaf Föllinger

Layout: Birgit Bäuerlein

Production: Susanne Bröckelmann

Cover design: PLEX Berlin, www.plexgroup.com

Printer: Schleunungdruck, Marktheidenfeld.

Bibliographic Information published by the German National Library (DNB): The German National Library lists this publication in the German National Bibliography; detailed bibliographic data can be found on the website at http://dnb.dnb.de.

ISBN 978-3-86490-430-1

Copyright of the English edition © 2016 dpunkt.verlag GmbH

Copyright of the original German edition © 2012 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

This publication is protected by copyright. All rights reserved. The use of text and images, even in extracts, without the written consent of the author represents a violation of copyright and is therefore punishable by law. This applies in particular to the reproduction, translation or usage in electronic systems. Please note that the software and hardware designations used in the book, as well as the brand names and product names of the respective companies are generally protected by trademark, brand or patent law. All of the information in this book has been extensively checked. However, neither the author nor the publisher can be held responsible for any damages associated with the usage of this book.

5 4 3 2 1 0

Foreword

Even if it does not seem so at first glance: the bus used in public transport (PT) is a hightech vehicle. This is not only apparent when you look at the built-in hardware, but is also due to the diverse software that runs on it and interacts with central IT systems, connected via multifaceted radio technology.

German transport companies work with information technology at the highest level for planning, optimising and controlling their fleets. They use sophisticated software systems in order to create timetables and implement them in vehicle workings and driver duties, dispatch vehicles and personnel, control and monitor the rolling stock fleet, provide the passengers with information, sell tickets, and much more.

This information technology not only helps companies to organise their operations in an efficient way, but also provides passengers with a high level of reliability, comfort and information when they travel with PT. An example of this are passenger information services – in other words, the displays at stops with the current departure times. These displays have been well received by the public and it is now difficult to imagine a city without them. You can find out which complex IT systems are required for this purpose by reading this book.

For decades, the companies in this industry – the transport and IT providers – have developed systems together in such a way that there are now standard solutions, which means that individual developments are/should be no longer required. The Association of German Transport Companies (Verband Deutscher Verkehrsunternehmen) has made a substantial contribution to this with its VDV standards. They standardise the hardware used in buses just as they do for interfaces between central software systems.

Many other countries in Europe also have the same high standards as Germany; however, in many parts of the world, the public transport and its IT are lagging behind in their development. It is clear that public transport plays an important part in creating a liveable environment, particularly in large metropolitan areas which are suffocating from too much private transport. There are many parts of the world where great efforts have been made and a great deal has been invested in order to improve public transport – for example, in eastern Europe, in Arabic countries and in South America; I am familiar with the plans there myself.

However, the German methods and systems cannot be exported automatically. A German planner works out his timetables to the exact minute, whereas the Chilean prefers to generate the timetable automatically, with only a few conditions that have to be fulfilled. The work time rules are much simpler in Dubai than in Germany, where these times are regulated by trade unions. Even EU rules on work time are not implemented in the same way in every country – the break rules in Dublin are different to Budapest, which in turn has different rules to Berlin.

There are some significant differences in ticketing, in other words in selling and paying for trips. In Germany, we have a long tradition of paper tickets that can be printed from a machine or bought from the bus driver if we do not have a monthly ticket (I remember the conductor who used to go through the tram and sell tickets when I was a child – this no longer exists). The ticket price comes from a fare system, usually with distance zones. The locals are familiar with this system, whereas tourists and visitors are usually left staring hopelessly at the machine.

Electronic ticketing (eTicketing) should help to solve this problem. This is actually more sophisticated in the PT systems of developing countries than here. There are two main reasons for this: simple fare structures and closed traffic systems. For example, a simple fare structure has a single price for each trip. When you transfer to a different vehicle, you pay for a second time – ideally, the second trip is somewhat reduced in price. eTicketing uses a chip card. The fare is deducted from the card when you scan it at a validation machine. If this action opens a barrier to an otherwise closed platform, then you can be sure that the passenger has paid. We do not have this kind of fare structure and locked entries to platforms in Germany, and we do not like it either. This is why eTicketing is more common in China and South America.

IT in PT is an extensive field, diverse, interesting and sophisticated, both technically and in terms of business, at a national and international level. This branch leads a rather shadowy existence in the sometimes glamorous IT world, probably because we – quite rightly – tend to see public transport as something natural and unspectacular, and expect it to run smoothly. Only the experts know that this is not self-evident. This is something I have learnt during the eight years that I have been working in this sector.

Why write this book? For what purpose? For whom? First of all, for ourselves, for our employees, those who develop these systems, install them for our customers and deploy them. They need to know the software and understand it in and out. The book is the basis for this understanding. Of course, it is also a book for our customers and the entire industry; for those who use these systems and want to find out how it all works. I also think it can provide useful teaching material for university professors in transport technology and informatics departments. It is not a book about IVU.suite, our family of software systems, which covers almost all of a transport company‘s requirements for efficiently planning, optimising and controlling its fleets. Extensive information on IVU.suite, which is of course based on the foundations described here, is available elsewhere.

I hope that this book has many readers who will help us to improve it through constructive feedback.

Ernst Denert

Introduction

Transport is an exciting topic – public transport in particular. In order to plan and operate large transport networks, transport companies use specialised computers, which are incredibly varied and complex.

The German company IVU Traffic Technologies AG has been dedicated to this small but mighty subject for over 40 years now. Even if the meaning of the three letters has changed, the core has always remained the same. I stands for Informationsverarbeitung (information processing) and Informatik (informatics), V for Verkehr (transport) and U for Unternehmensforschung (operations research) and Umwelt (environment).

The industry itself has also remained attractive: transport and logistics are perennial issues that involve people, goods, cities and societies. In other words, an area of application, which makes it easy to vividly explain to your mother-in-law what you do all day. In principle, you should keep it simple, because what start out as very clear questions can soon turn into complicated constructs that can only be understood by those in the know, e. g. a detailed and lengthy definition of duty and payroll rules for train personnel, or how to precisely determine the ticket prices in network structures.

At the same time, the importance of IT solutions for transport companies has increased dramatically. Tight public budgets and increasing competition put pressure on traditional service providers. The last efficiency reserves need to be unlocked without the quality of the transport services suffering as a result. Passengers expect the services to be easy to use, with comprehensive information throughout the entire journey. Moreover, the personnel themselves want customised duty schedules, perfect driver assistance systems and wages that are accurate to the penny.

IT can really make the difference here – on a variety of different levels: as an electronic pen, i. e. the technician no longer has to complete tedious routine tasks as computers and printers replace paper and pen. The most important result of this is the clear, attractive and easy to modify printout (on-street schedules, duty schedules, driver boards etc.) Also as a calculator, i. e. the IT system takes over time-consuming calculations, e. g. for pay slips, ticket sales etc.

The importance of interfaces is often underestimated: Transferring information via printouts or voice messages is replaced with electronic data – the receiver no longer has to read and input data manually. The next level is process integration: sequential editing methods are replaced with integrated processes; planners always have quick and up-to-date access, from the stop to the driver accounts, which means that they can easily take into account or adopt upstream and downstream process steps. Something else that is nice to have: the optimisation: the efficiency of the resource deployment for personnel and vehicles is increased via clever algorithms that provide solutions to unsolvable calculation problems. Technicians control the results by means of guidelines, rules and parameters.

In the following chapters, we will learn a number of things about all of this: in a neutral manner, in accordance with IVU‘s range of services for the most part, but also consciously remaining open to other providers, as a kind of general contractor who cannot do everything himself but must ensure the interaction between his own systems and external systems.

As a supplier of ITTC (IT systems for transport companies), IVU is particularly reliant on good communication with the actual users of ITTC – in other words, with the people who plan, execute and invoice the public transport with trains and buses. Good communication is helped by a common understanding, to which this book makes a contribution.

Aside from reaching an agreement on the technical content and functional requirements of IT solutions, there is also the world of implementation, project work, application management and software maintenance. There are many challenges lurking here. IT should be quickly available and easy to use, but also able to accomplish everything without being too expensive. It should continually develop itself, without any difficulties arising when new versions are adopted. And, preferably, it should set standards, which should also fit to each company´s own often very individual requirements.

In this respect, this book is a way of bridging the gap in order to create a common understanding of the contents and high complexity of the subject matter, thereby enabling cooperation between a supplier and a transport company, as well as between multiple suppliers and multiple transport companies. And perhaps it will also help your mother-in-law understand your job a little better :-)

Martin Müller-Elschner

Acknowledgements

IVU has been developing software systems for transport companies for more than 40 years. And this still has a special allure, presenting a particular challenge: demanding optimisation processes, graphical interfaces with maps, radio technology and on-board computers, tracking vehicle fleets in the currently running operations – these are all parts of the IT system in public transport.

When young computer scientists leave university, they first have to immerse themselves in the specialist knowledge of this area of application before they can really hold discussions with the experts in a transport company on an equal footing and solve problems with them. This book can help them to do this.

When experienced software developers and customer service advisors think about how a complex planning or control system should be set up, they take into account the individual customers and constraints in many different countries. They stand on the shoulders of their predecessors, who created today’s solutions yesterday and earlier with methods and tools that are now obsolete, and whose point of view or objective was focused on certain aspects that were particularly important at that time.

To advance a software system, you have to dig deep and think about special cases that may only seldom occur: for example, data containing errors, interfaces that are not available and human users who do not act in the exact way that the developer had imagined, but rather in the way that they intuitively feel is right. Unfortunately, this is not always the same.

It is, however, more important to step back once in a while and sort out ideas and software modules, combine things that have developed in parallel, break away from old habits and always search for a clear direction. Acknowledging that this is necessary is a sign of strength.

Software systems for PT are so complex that they can only be developed with a division of labour. The more comprehensive the understanding of each employee, the better they can understand their job in the context of the whole process and the easier it is for them to tailor their work to the targets of the customers and the architecture of the systems. If you are only partially familiar with these two things, you will be less productive – and probably less happy. Constantly taking on a new perspective is stressful, for example in sales meetings, for customer support or when implementing software. Solutions that prove successful in practice can only be created if nothing is lost during the long journey from a technical idea to an installed system ready for operation.

This is how the idea came about to summarise technical and PT specific aspects in one book, a book for border crossers, so to speak. It should shed light on the diversity of PT and describe common solutions for information technology. In both cases, it is more about covering the area in its entirety than exploring every last detail.

Each transport company sees itself as something special, but also wants to have a standard product. So what is this standard? Where is the generally applicable common denominator between the duty scheduling for a Norwegian ferry company and the Swiss railway? Does fleet management function differently in Colombia than in Holland? From an IT point of view, what is the difference between a bus company in regional transport and pure local transport?

This book describes a reference model that covers the core topics and offers connecting factors for specific extensions. It helps to ask the right questions and formulate them in the correct way. It therefore prepares the ground for a future-proof upgrade of our products. The choice of words remains neutral here. You maintain a better clarity of thought when you keep your distance from the product name and the individual historical eventualities.

I would like to thank all of the colleagues at IVU whose help and advice have contributed to the creation of this book. Oliver Grzegorski, Perry Prust and Oliver Koch delved into the depths of the class model with me, Katrin Barthel, Bastian Dittbrenner, Olaf Föllinger, Simon Heller, Ulrike Orlowski, Martin Stiel and Thomas Langkamm contributed a multitude of details on the planning and dispatch of trips, duties and vehicles, Andreas Müer on information service systems. Lutz Trostorf has sharpened my view on the business relationships between operators and public transport authorities, Sebastian Adlers-Flügel provided me with an understanding of the special attributes involved in regional transport. As an untiring proofreader and sparring partner, Claus Dohmen helped to put the control centre, passenger information and automotive technology in the right light. Rainer Schibilla brought the software layers of an on-board computer to life in conversation. Helmut Bergstein and Dik Lokhorst stood at the cradle of the book and ensured the right balance between business processes and system technology. Andreas Langenhan proofread the entire manuscript and gave many helpful tips.

I would also like to thank my conversation partners from the transport companies who helped me to sort the important from the unimportant and still take one or two individual particularities into account. I would like to thank Ms. Elke Fischer from VDV for her comments on ticketing.

In particular, I would like to mention that the background chapter on public transport was penned by the chairman of IVU, Mr. Martin Müller-Elschner.

Last but not least, I would like to thank the former chairman of IVU, Prof. Dr. Denert, who provided the inspiration for this book, as well as the space to bring together and arrange the relevant expert knowledge. His critical view and insistence on structural clarity continually gave me valuable support.

I hope you enjoy exploring the exciting world of public transport and its IT systems!

Dr. Gero Scholz

Table of Contents

1       Introduction

1.1     IT systems in PT are complicated!

1.2     Standardisation

1.3     Challenges for system providers

1.4     The significance of a domain model

1.5     What awaits you in this book ...

1.6     What you will not find ...

Part I Overview

2       IT System Landscape of a Transport Company

2.1     Systems and business processes at a glance

2.2     Actors and roles

2.3     Special requirements for systems in PT

2.3.1     Multitenancy

2.3.2     Versions and variants

2.3.3     Special notation for rules

2.3.4     Cross-process optimisation

3       The ITTC Core Model

3.1     Tips on notation

3.2     Defining the contents

3.3     The structure of the ITTC class model

3.4     The most important relations in the core model

3.4.1     The network: locations and links

3.4.2     Travel paths and routes

3.4.3     Calendar and time of day

3.4.4     Transport services: trip and connection

3.4.5     Vehicles and vehicle workings

3.4.6     Driver and duty

3.4.7     The link between trips and duties

3.5     Outlook

Part II Business Processes and IT Systems

4       Vehicles, Vehicle Types and Vehicle Formations

4.1     Identifying objects – using the example of vehicles

4.2     How vehicles are equipped: Groups of attributes

4.3     Configurable attributes

4.4     Extract from the class model

4.5     Creating formations

4.6     Vehicle types

4.7     Maintenance

4.8     Vehicle equipment

4.9     Communication architecture in the vehicle

4.10   The software architecture of an on-board computer

4.11   Hardware for the on-board computer

5       The Traffic Network and Routes

5.1     Modelling the network in IT systems

5.2     Representation of the network in the user dialog

6       Planning/Scheduling

6.1     Taking irregularities into account (aspects)

6.2     IT architecture of planning systems

6.3     Timetable planning

6.3.1     Trips

6.3.2     The timetable planner’s working process

6.3.3     Connections

6.3.4     Timetable display and information

6.4     Vehicle working scheduling

6.4.1     Vehicle workings in the ITTC class model

6.4.2     Building vehicle workings from trips

6.4.3     Planning deadhead trips

6.4.4     Linking vehicle workings

6.5     Optimisation of trips and vehicle workings

6.6     Duty scheduling

6.6.1     Overview

6.6.2     Duties in the ITTC class model

6.6.3     The duty scheduler’s working process

6.6.4     Duty sequences

6.6.5     Optimising duties and duty sequences

6.7     Integrated vehicle working and duty scheduling

7       Dispatch

7.1     Personnel dispatch

7.1.1     Work processes

7.1.2     Personnel dispatch in the ITTC class model

7.1.3     IT systems for personnel dispatch

7.1.4     Automatic dispatch and optimisation

7.2     Vehicle dispatch

7.2.1     Work processes

7.2.2     Vehicle dispatch in the ITTC class model

7.2.3     IT systems for vehicle dispatch

8       Transport Control

8.1     Base data in the control system

8.2     Geolocating

8.3     Fleet control through control circuits

8.4     The model: events and actions

8.5     Operating an operation control system

8.6     System monitoring

8.7     Communication system

9       Dynamic Passenger Information

9.1     Dynamic information

9.2     Situations and types of passenger information

9.3     ITTC sub-model: DPI

9.4     Scope

9.5     Preparing and displaying information

9.6     Forecast

9.7     DPI installations/stop computer

9.8     Transferring data between the control centre and DPI displays

9.9     Automated processing of actions

9.10   Deleting the display when the vehicle departs

9.11   Operating a DPI system

9.12   Joint DPI for multiple transport companies

10     Sales and Distribution

10.1   Ticketing class model: Overview

10.2   Ticketing role model

10.3   Access control

10.4   Products and fares

10.5   Sales

10.6   Payment flows and background systems

10.7   Paper tickets

10.7.1   Carrier material and security precautions

10.7.2   Usage

10.8   Online tickets

10.8.1   Carrier material

10.8.2   Security precautions

10.8.3   Example: HandyTicket from the VDV

10.9   eTickets

10.9.1   Carrier material

10.9.2   Security precautions

10.9.3   Digression: the basics of security in eTicketing

10.9.4   Usage

10.9.5   The VDV core application

10.9.6   Example: Touch&Travel

10.10 Hardware for ticketing

11     Settlement, Performance Analysis and Quality Management

11.1   Transport contracts

11.2   The class model as the basis of all reports

11.3   Typical evaluations

11.3.1   Analysing passenger demand

11.3.2   Evaluating the transport service

11.3.3   Evaluating the quality of service

11.3.4   Evaluating ticket revenue

11.4   Platforms for evaluations

11.4.1   A conceptual model of a data warehouse

11.4.2   Technology for data warehouses

11.4.3   How it is displayed

Part III Background Knowledge

12     Passenger Transport

12.1   Why does public transport exist?

12.2   Public transport and the market economy

12.3   Profitability

12.4   Public transport organisation

12.5   Subsidies and competition

12.6   Public transport vs. private transport

12.7   Success factors for public transport

12.8   Safety

12.9   A look at the world

13     Informatics

13.1   Description methods – a look back

13.2   Designing IT architecture

13.3   Tools for modelling

14     Modelling Methods

14.1   Creating sub-models

14.2   Displaying classes

14.3   General naming rules

14.4   Packages, classes, attributes, functions

14.5   Temporal patterns and events

14.6   Functionally unique key terms

14.7   Class instance attributes

14.8   Consistency conditions

14.9   Navigating along relations

14.10 Conditions for relations: Invariants

14.11 Recursive relations

14.12 Ambiguous relations

14.13 Aggregations

14.14 Inheritance and typing

14.15 Corresponding class hierarchies

14.16 Composite pattern

14.17 Interfaces

Appendix

A      System Landscape

A.1     Business processes and systems at a glance

A.2     Systems and data flows in detail

A.2.1     Planning

A.2.2     Dispatch

A.2.3     Transport control

A.2.4     Dynamic passenger information

A.2.5     Ticketing

A.2.6     Evaluation, quality management

B      Packages and Classes

B.1     Connections

B.2     Aspects

B.3     BasicTypes

B.4     Company

B.5     DutyExecution

B.6     DutyScheduling

B.7     PassengerInformation

B.8     TimetablePlanning

B.9     TripExecution

B.10   Vehicles

B.11   VehiclePeripheralEquipment

B.12   Calendar

B.13   Communication

B.14   ConfigurableAttributes

B.15   Customer

B.16   CustomerSpecificTypes

B.17   Routes

B.18   Network

B.19   Location

B.20   Personnel

B.21   DisruptionManagement

B.22   Fare

B.23   Ticket

B.24   VehicleWorkingScheduling

B.25   Validation

B.26   Sales

B.27   TransportPlanning

B.28   Payment

C      Glossary

D      Literature

D.1     Public transport in general

D.2     Vehicles

D.3     Transport service, demand analysis

D.4     Timetable planning

D.5     Connection planning

D.6     Timetable information

D.7     Vehicle working scheduling

D.8     Duty scheduling

D.9     Integrated planning

D.10   Dispatch

D.11   Control

D.12   Dynamic passenger information

D.13   Fares, ticketing

D.14   Quality management, accounting

D.15   Transport policy, transport companies, associations

D.16   Software modelling

Index

1 Introduction

My bus is coming!

We have probably all said this at some point in our lives. But what exactly do we mean by it? Is our bus really a physical vehicle? In such cases, the passenger is not usually thinking about a very specific vehicle. From the passenger’s point of view, it is important that the bus or tram arrives at the stop at the correct time and travels in the right direction.

Bus – Trip

However, if our passenger happens to be a computer scientist and is particular about terms, then he might say: My trip is coming! This sounds quite strange, doesn’t it? Granted, but what happens when we are at the airport?

Aeroplane – Flight

Our flight is delayed. I heard that the plane hasn’t even landed yet.

Everyday language makes a clear distinction between the plane and our flight. At this point, it is still a foreign machine – it only becomes our plane when it begins our flight. We have booked a flight and not a specific aeroplane.

Trip = route, direction, time/place

But let’s return to earth. We might have noticed that our bus is often very full in the morning. Actually, we should formulate this as follows: The trip on route 12, which, according to the timetable, is supposed to depart at 6:50 from the stop Cherrytree Road, travelling in the direction to Exhibition Centre, is close to full capacity. Somewhat wooden, but correct. By specifying the route number and direction of travel along with a stop and departure time at this stop, we are able to identify the trip.¹

Vehicle type

One day we are standing at the stop 10 minutes earlier. Even more people are waiting than usual. We have already mentally prepared ourselves for a standing place, but, when a vehicle arrives at 6:43, we see that it is a large articulated bus. The transport company clearly deploys a variety of vehicle types on this route in order to adjust the transport capacity to the demand.

Vehicle

One morning, after exiting the vehicle, we realise that we have left our umbrella in the bus. As we can see the stop from our office window, we keep glancing at it and wondering if the vehicle with our umbrella might drive by again. According to the timetable, the entire runtime from the initial stop to the final stop takes 45 minutes. This means that our vehicle should actually come back here in 90 minutes. Or perhaps even earlier, but in the opposite direction?

Vehicle workings, break times, driver changeover, vehicle swap

One colleague thinks that we should take our time, because a break for the driver is always scheduled at the final stop. Another colleague argues that the driver is sometimes changed at the final stop. Does this mean that the break for the vehicle consequently does not take place? Eventually, someone declares that he has never seen an articulated bus after 9am.

Disruptions

Recently there was a traffic jam and the driver asked us to exit and wait for the next vehicle. Then our vehicle turned around and drove straight back. After much heartening encouragement from our colleagues, we decide to ask the transport company directly about our umbrella in the afternoon.

Dispatch

The friendly employee on the phone tells us: A driver on route 12 found a green checked umbrella today at the final stop at Exhibition Centre. He told us about it via the on-board computer in his bus. The vehicle is still being operated, but the driver has already finished his shift. The driver who is driving the bus now will take the umbrella to the depot tonight. We will make sure that you are handed your umbrella tomorrow morning when you board the bus at Cherrytree Road. It will be a different vehicle and a different driver – but that is nothing for you to worry about! Just give the driver the code word when you board the bus: Top class service."

Thus, we have reached the – perhaps slightly fanciful – end of our short introduction. We have encountered a number of aspects that will be described in more detail later on in the book: stops, links, travel paths, routes, vehicles, vehicle types, trips, drivers, duties, break rules, dispatch managers – in short: the entire, astonishing diversity of public transport (PT).

1.1 IT systems in PT are complicated!

In terms of subject matter, IT systems in public transport are astoundingly complicated, in addition to being very sophisticated from a technical point of view:

Buses with electronics

The bus in public transport can do more than just drive: it knows its timetable, announces the stations, reports to the traffic lights and continually informs its control centre of its current position. Aside from that, it takes care of selling tickets and calculating revenues – as well as displaying possible transfer connections, both based on the timetable and in real time.

Algorithms

Designing timetables is a very demanding job. A complicated network of vehicle movements and driving duties needs to be drafted in order to provide cost-effective transport services. The optimisation of timetables and duty schedules is still a current field of research at universities; from a certain size of transport company upwards, the deployment of scientific procedures² is absolutely essential.

Complex databases

IT systems in transport companies are based on databases with hundred of tables; you come into contact with complicated mechanisms for historisation, versioning of timetables, multi-tenant capability and numerous methods for optimising performance.

Real graphics

The user interface not only contains the usual graphical screen forms, but also real graphical user interfaces, i. e. maps and schematic route plans, track outlines, etc.

Special hardware

You encounter multi-level client-server landscapes and there are even special hardware components such as on-board computers in the vehicles, as well as ticket machines and special electronic display screens.

Innumerable logs

In parallel to the physical networking of the traffic systems and passenger flows, the networking of IT systems between different PT companies continues to progress – as a result, there are countless interface standards and protocols at all levels of the ISO layer model, as well as numerous converters.

Security, certificates

Security plays an important role in the deployment of smart cards for passengers (electronic ticketing) and drivers (for the purpose of authorisation and calculating cash revenues). There have been many technical studies and experiments in the ticketing field, e. g. paying by mobile phone.

Communication and monitoring in realtime

Finally, you have to deal with special communication technology (radiotelephony, data radio), which creates realtime demands – in both the control centre and the vehicle. The monitoring and control of a vehicle fleet takes place online. Anyone working as a computer scientist for PT therefore needs to know how software architecture can be designed to handle concurrent processes.

1.2 Standardisation

The German transport market is highly developed – as is the market for IT systems that support transport companies. Many providers have established themselves in this lively competition. They usually specialise in specific functional branches from their company history.

System diversity

As a result of this, it is not unusual for transport companies today to use software systems from multiple manufacturers at the same time. This has made it necessary to create interfaces. Instead of leaving this to the bilateral agreement between individual manufacturers, transport companies already advocated collaboration across the industry at an early stage.

Standardisation in Germany

Coordinated by the Association of German Transport Companies (VDV), a variety of recommendations have been devised, by which all software providers must abide today.

In Germany, transport companies refer to the so-called VDV standards³ when purchasing IT systems. This gives them the benefit of being offered systems that fit together functionally and technically, at least in principle.

When transport companies decide to enter into a cooperation or even fuse with a neighbour company, the integration of the IT systems is always a challenging topic – however, thanks to the existing interface standards, there is often less dynamite here than in other industries. The VDV interface standards are even sometimes used in German-speaking neighbouring countries.

Standardisation in Europe

Some neighbouring countries in Europe have also developed standards for designing IT systems. It is important to mention Transmodel⁴ here, which is an approach that resulted from the project SITP, supported by the French Ministry of Transport. Transmodel is increasingly endorsed in Great Britain, the Netherlands and Germany⁵. The Service Interface for Real Time Information (SIRI) is based on it⁶ and has become a CEN standard. Scandinavian countries also took part in creating it. A particularly important area for standardisation is the paperless ticket. If a single transport company wants to introduce electronic ticketing on its own, there is a high risk of bad investment. This is because passengers will eventually assume that they can use a smart card as their ticket in the same way for all transport companies, at least in their home country. Standardisation is progressing quickly in this area (VDV core application, SDOA, ITSO).⁷

railML

Finally, a note on RailML: RailML.org® is an association of different European railways, universities, software developers and engineering firms who have been working together since 2001 in a partnership to standardise software interfaces in the railway sector based on XML notation.

International competition

For German software providers, the modularity of their systems can be an advantage in international competition. Partial updates are often made in existing system landscapes. The interface capability of the new components is crucial here.

However, in today’s international environment – particularly outside of Western Europe – it is often a matter of setting up new, complete IT systems in the context of large tenders. In some cases, the transport company itself is even founded at the same time.

When setting up new systems, the manufacturers in countries with simpler, monolithic systems have the upper hand. Metaphorically speaking, these systems carry less interface agreement baggage around with them. As a result, you can make changes more quickly without needing to think about compatibility with the systems of competitors in the domestic market. It is also easier to make technical gains in efficiency when you, as the software provider, only have your own system in mind.

Fig. 1-1 Countries and standards

Immaterial value

If a transport company is convinced of the long-term, strategic benefits of modular systems, then it can take this aspect into account when purchasing and updating its systems. However, from the purchaser’s point of view, this is not easy, because providers tend to make generous promises when they are in a competitive situation, and it is difficult to measure the modularity, flexibility, expandability and robustness of software solutions.

Standardisation and innovation

Transport companies must – especially in a highly developed market such as Germany – contribute to the standardisation of interfaces and take increasingly international aspects into account. It is important to create the basis for competition and make sure that tenders are created efficiently and quotations are comparable. Transport companies insist on continuity and are often tempted to even request downward compatibility for very outdated systems. At the same time, they need to find ways to exploit the full potential of new technology and push the providers to the limit of what can be achieved.

1.3 Challenges for system providers

The central challenge for German system providers in the PT industry is to continue placing sophisticated partial solutions on the largely saturated domestic market, as well as reusing as many components as possible, if they provide complete system solutions at an international level.

Extending the portfolio

You need to round out your product range, be it through your own development or additionally purchasing other products, through holding stakes of other software companies or at least through cooperation arrangements. This requires both circumspection and sustainable development, as it takes many years for a formerly external product and corresponding development team to be organically integrated into a company. Pure business coexistence is not enough – the customer expects an integrated product and not a shopping basket full of individual software items.

Product strategy

System houses must be able to exhibit a long-term product strategy in order to be taken seriously as a partner for large-scale projects. To do this, they need to continually develop their established products and make modifications to the product strategy in small doses, without irritating their regular customers. New or newly purchased products must be fully integrated and not just stuck on.

Fig. 1-2 Interplay between norms and product strategy

1.4 The significance of a domain model

In this context, it seems logical for software producers to create a domain model as the basis for their own product development.

Domain model as basis of product development

The ITTC domain model described in this book⁸ incorporates experiences from the German market and from the VDV model. It also includes ideas from Transmodel and SIRI. As an object-oriented UML model⁹, it methodically goes beyond the current pure data models and creates a common denominator that can also be passed on to other countries. As a graphically visualised and well-documented domain model, during discussions with customers and interested parties it provides a map on which it is possible to jointly localise the often quite abstract structures of software systems. In this way, you can quickly find out whether or not the expectations of a transport company can be covered by a particular software solution.

A basis for discussion for transport companies

The ITTC model visualises the construction plan for software. It does not have the character of a binding standard, but rather represents a frame of reference that allows transport companies to talk to software producers on a clear, medium abstraction level and disclose the relevant specifics. In a typical IT project requests and ideas should initially be reflected in an adjustment of the model, which is made by the software producer and transport company together. In this way, both partners get a feeling of how far an intended modification will deviate from the current framework, whether it would be a small addition to a peripheral area or would have a significant effect on certain structures. Then thought should be given as to whether or not an adjustment is worthwhile and which long-term maintenance costs come with it.

Bridges to private transport

It is not only in PT that a consensus needs to be reached when it comes to modelling processes and data structures. In the realm of private transport, there are also initiatives under the heading Intelligent Transport Systems with the goal of defining an integrated architecture, which brings the traffic control systems on motorways together with inner-city parking systems and traffic signals. You can image that public and private transport not only grow together in terms of intermodal journey planning, but that future systems from both worlds will check for alternatives while a journey is being carried out and make suggestions specially tailored to fit the current situation. For example, think of the usage of a park-and-ride service when approaching the city centre. The ITTC model offers links for this purpose.

__________________

Publishing the domain model

We, IVU Traffic Technologies AG, have summarised our understanding of the PT industry in the ITTC model in a neutral form. We are publishing the model in detail because we assertively use it in the manner described above as an instrument for dialogue with our customers and competitors. Furthermore, we regard it as a commitment for our employees and as a guideline for the expansion of our company’s product range. The published model is a development framework that acts as the basis for designing our products and is still substantially refined. Of course, we would be delighted if our thoughts and materials had some influence on the further development of the VDV model and on future European standards as a result.

1.5 What awaits you in this book ...

System landscape

In chapter 2, we describe the system landscape of a typical transport company. The focus is on business processes and the technical functionality of applications, not the IT system technology.

Core model

After a preliminary note on methodology, chapter three introduces the functional core of the UML class model. For this purpose, we have selected representative classes from the most important packages and describe how they relate to each other.

Sub-models and business processes

The main part of the book focuses on the business processes in a transport company and describes the corresponding section of the domain model in each case. The chapters are designed in such a way that you can read them independently of one another. This means that there is some deliberate repetition and minor overlaps.

Background knowledge of transport and IT

We assume that the readers of our book have background experience in the transport sector or in informatics. To simplify the first steps in the other respective branch, background information can be found in chapters 12–14.

Appendix

All information flows, packages and classes of the model are described concisely in the appendix. The appendix also contains a glossary.

1.6 What you will not find ...

General logistics and freight transport are not dealt with here. Taxis are not featured in this book. Requested transports (on-demand buses, share taxis) are omitted because the character of their job would require very specific model extensions. We also do not go into details about concrete software and hardware systems.

The book does not contain a catalogue of functional items that would be directly suitable for a tender or product evaluation – however, it can help to ask the right questions in a decision-making situation.

Part I

Overview

2 IT System Landscape of a Transport Company

3 The ITTC Core Model

2 IT System Landscape of a Transport Company

In this chapter, we will introduce the most important processes and IT systems that transport companies use in order to organise their operations – or to be more precise, to plan, control, optimise and calculate their vehicle fleet.

Section 2.1 describes typical business processes and systems, how they interact and their spatial-organisational distribution. Commercial applications (so-called ERP systems) are not covered here. Only the interfaces for some of these systems (for personnel and financial concerns) are looked at in the context of personnel dispatch and the calculation of fare revenue.

In section 2.2, we will characterise the roles of typical users of the mentioned systems. Finally (section 2.3) we will describe certain distinguishing features of IT systems in PT.

Appendix A contains a detailed and structured description of around 40 systems that we recommend to interested readers as accompanying material or additional information.

2.1 Systems and business processes at a glance

Systems, processes, course of time, deployment location

The following discourse is oriented towards two illustrations: Table 2-1 matches the systems and devices to the transport company’s business processes, Figure 2-1 displays the course of time (horizontal) and the location (vertical) of their deployment.

Tab. 2-1 Systems and business processes (static assignment)

Generalised referential illustration

This is a generalised description, which of course does not portray the exact situation for individual companies, especially because of the fact that transport companies often use systems from different manufacturers in a wide variety of combinations. However, it claims to be a referential illustration containing as many of the functions and data as possible that are required by a transport company in any form. As a result, it is able to describe the IT for transport companies in a way that is comprehensive, universally valid and concrete at the same time.

Planning

About the business processes (Tab. 2-1):

The Planning takes place months and weeks before the actual trip.

During network planning, the routing is set and the course of the routes defined. Runtimes are calculated from the technical nature of the links and vehicles (so-called timetable development); service frequencies (headways) are determined from the transport demand.

The timetable compilation and editing creates the schedule with exact departure times, which is ultimately relevant for the passengers, who can read it in the form of on-street schedules at stops, for example.

Vehicle working scheduling is very important in operational terms. It determines how the vehicles can be deployed in order for the timetable to run as efficiently as possible.

The same applies for duty scheduling, but with regard to the drivers and other personnel (conductors, service staff). Boundary conditions such as duty times, break rules and deployment locations should be taken into account here.

The goal of the optimisation of vehicle working and duty scheduling via mathematical methods is to implement a timetable using as few resources (vehicles, staff) as possible – whilst ensuring social acceptability.

Dispatch

The dispatch, i. e. the assignment of specific vehicles and drivers to the timetable and duty schedule, takes place shortly before the start of the trip, usually a few weeks or days in advance. It deals with last-minute changes before and during the operational procedure.

Transport control

Transport control is the process of controlling and checking the fleet that is currently running. The control centre has an overview of the traffic situation; when irregularities occur (delays, accidents, etc.), it can quickly find solutions or initiate actions. In addition to this, the vehicles have on-board computers with communication and control functions, which can be used to control traffic lights or check the displays in the vehicle.

Passenger information

The passenger information serves the passengers in the form of

Dynamic passenger information, which displays the current departure times first and foremost at stops, but also online or on the passengers’ mobile phones.

Journey or timetable information, which is chiefly available online on a variety of end devices. It is part of the planning, so it is also often placed there.

Ticketing

Ticketing provides the transport company with a substantial part of its revenue. First, a fare structure is required for the ticket sales to function on a variety of different vending devices – on stationary machines and on devices in the vehicle for paper tickets, as well as increasingly electronically with smart cards.

Evaluation

The evaluation compares the Planned and Actual values and stands at the end of the chain. Its findings provide the incentive for improving the other process steps. At the same time, they act as the basis for checking and calculating the transport contracts that exist between the transport company and the public transport a ty.

__________________

Figure 2-1 shows how the systems interact with one another and the most important data flows between them.¹ There are three areas in which systems are used:

Central and regional

The timetable is developed and fares are managed in a transport company’s control centre. Important operational tasks are processed in a semi-centralised way. These tasks include dispatching resources (i. e. vehicles and staff) for specific locations, controlling traffic in the control centre² and, closely connected to this, monitoring the dynamic passenger information.

In the vehicle/decentralised

There are mobile and stationary systems on the street; the ticket machines and the displays with the current departure times are particularly evident for the passenger. Software systems for a variety of purposes run on the on-board computers in the vehicles: selling tickets, informing the drivers of their route variation and deviation from the timetable, controlling many technical functions (radio connection to the control centre, positioning, traffic light control, door control, the vehicle’s display, and much more).

Everywhere/for the passenger

Nowadays passengers can search for and find a wide variety of information online: Timetables and fares or prices for planning journeys, current departure times, and much more.

Fig. 2-1 Systems and business processes (dynamics and spatial distribution)

Information flows: content-related

The connecti tes in Figure 2-1 have both content-related and technical aspects. For the sake of clarity, we have omitted the transported specialised content (timetables, duty schedules, status reports, dispatch instructions etc.). They are described in detail in the appendix A.2.

Information flows: technical

Wireless transfer procedures (GSM, GPRS, WiFi etc.) are only mentioned at int in Figure 2-1 in connection with the term radio. Communication technology in transport companies is particularly important and diverse – we describe it in detail in sections 4.9 and 8.7.

__________________

Temporal order of core processes

The combination of planning and dispatch, steering and evaluation results from the inherent rhythm of public transpo vices. Figure 2-2 arranges the main activities prototypically on a timeline:.

Fig. 2-2 Temporal order of core processes

Annual planning

Timetable studies are conducted in large cycles, the annual³ timetable is created with a long lead time. Fare plans are adjusted in a similar rhythm; however, the time at which they come into effect is not dependent on the timetable change. Long-term resource planning is conducted in parallel to timetable planning (annual duty schedules, holidays, training and advanced training schedule, acquiring or refitting vehicles). Link planning (track construction) has particularly long lead times in rail transport.

Quarters and months

The planning process becomes more concrete as time ticks on. Roster layouts are created, driver requests are factored in, vehicle workings are optimised, maintenance windows are set, vehicles and employees are assigned to the abstract schedules. Sometimes there is interplay between the planning steps. For example, when vehicle workings are being optimised, trips may be moved on the time axis experimentally in order to improve the vehicle utilisation.

Weeks and days

As the day of the execution draws nearer, the following question comes up more and more frequently: Should a special situation (e. g. a major road construction event) still be incorporated in the planning or should you stick to the schedule and leave it to the day-to-day operations to deal with the predictable disruptions? This often results in a compromise: you increase the number of drivers on standby and make sure that as many vehicles as possible are ready for operation. However, the control centre decides which trips are actually modified or reinforced when the time comes.

Zero hour

The traffic situation is monitored at the execution time. Any deviations from the target state trigger actions that will counteract them. A planning process is also required here. The control centre will not start looking for a detour only at the moment when the link is blocked! It is prepared for innumerable events and has a whole arsenal of actions to fall back on. This not only includes intervening in travel paths and drivers’ duties, but also directly giving information to the passengers.

Afterwards

After the execution, the paths diverge: at the operational level, the performed duties are recorded exactly, because deviations from the schedule may have repercussions on how the drivers are paid, on the required rest times or on the inspection times for vehicles – in other words, this has an effect on the dispatch for the following day, and the cycle begins once more. At the long-term level, it is important to record driving actions, calculate revenues and learn from quality defects by adjusting the plan so that connections can work out better.

2.2 Actors and roles

The organisational structure of transport companies differs depending on the company. For our model, we are primarily interested in how IT systems are used. We are looking at the roles, i. e. relevant parts of the employees’ activity profile. For example, if we are talking about a personnel dispatch manager, we mean the range of tasks connected with assigning drivers to scheduled driving duties and standby duties. In a small transport company, it is entirely possible for one person to take on this bundle of tasks (the role) and plan the duties as well (= the duty scheduler).

Activity

In the application profiles in the appendix (section A.2) we have listed the roles of the people involved. They will keep cropping up throughout the rest of the book⁴. The most important roles can be characterised as follows:

Transport planner

The transport planner analyses the current usage of public transport in a particular region and predicts changes in passenger behaviour. He takes into account sociological developments and urban development plans. The result of his work is the expected mobility demand, i. e. the amount of people to be transported, split into groups of people (commuters, schoolchildren, disabled people, etc.), relations (start and end location), zones (conurbations, districts) and time periods (days of the week, times). He creates a local transport schedule, for example, which sets the rough route structure and capacity of the service (places and service frequency for each relation).

Network planner

The network planner creates a route network based on the transport demand for a particular transport company or an association of PT companies which becomes the basis for the transport service. He defines stops, link courses, routes, runtimes and runtime profiles. Depending on the mode of transport, part of the network planning may also be conducted strategically. As a result, investment-heavy modes of transport such as trains, for example, are planned and implemented across the time period of a train generation. On the other hand, modifying or creating a bus route is also possible within a timetable, i. e. with only a few weeks of lead time. The network planner adds information relevant to fares (such as rules for determining so-called short trips) following the fare planner’s instructions in the definition of the traffic network.

Timetable planner

The timetable planner implements the transport demand on the network that has been created. The network planner and timetable planner often do not have separate roles, as both activities are closely related to each other. The timetable planner defines the trips for each route (headway and exact times) and takes connection relationships into account. He defines the vehicle type to be deployed⁵ and factors in any restrictions that may result from the routing. In addition, he specifies the necessary special equipment, such as an accessible entrance to the vehicle. The network and timetable planning may be the job of the transport company or be fixed in the transport contract, depending on how sophisticated the transport authority⁶ wants the required transport services to be.

Vehicle working scheduler

The vehicle working scheduler creates service packages for vehicles of a particular type. He lines up the trips one after the other. They will be driven later on by a vehicle in this exact order. In accordance with rules and past experience, so-called layover times are observed here. Among other things, they are important in order to ensure stability