New generation IT for public transport has a lot to offer. Connected cloud-based services and on-board apps can help to save money, increase safety, enhance driver job satisfaction, and reduce pollution. But how can public transport authorities and operators move quickly and efficiently to such new solutions, without negative impact on existing investments? How can new on-board systems be fitted to fleets of vehicles in daily operation that use older generation systems? The challenge is to keep disruption and costs to a minimum, while transitioning to the new environment and its benefits.
Good migration planning meets this challenge. It optimizes the steps to extend existing legacy systems to a plug-and-play on-board architecture that is ITxPT-compatible (Information Technology for Public Transport). This compatibility makes it simple to connect different modules and functions, such as video surveillance and ticketing. The ITxPT standard, incorporating the 3iBS (intelligent, innovative, integrated Bus Systems) guidelines for on-board installation, helps system suppliers, vehicle manufacturers, and bus operators converge on new improved solutions today. Once adopted, it also makes future migrations easier too.
Reasons for Wanting to Migrate
The main reason is to improve public transport and make it more attractive for passengers. Digitalization is one of the main tools. The digitalization makes it possible to move an organization and its processes from an analogue environment to a digital one. However, there may be other reasons. For instance, existing digital systems may not be able to meet new needs, such as the addition of a passenger counting module. In that case, a new way forward must be found. PTAs and PTOs may see a possibility to clearly improve their operations by using KPIs (key performance indicators) and intelligent scorecards, which in turn require new solutions to be installed. Plans to improve the driver environment can also trigger a need to manage migration.
It makes sense to check that all the people concerned, the stakeholders, share the enthusiasm about a migration – or, at least, are willing to work together to make it a success. Senior executives who are convinced of the business benefits are stakeholders, but so are IT staff who will be working with the systems, and drivers who will be using them every day. Open discussions that pay attention to the WIFM (“What’s in It For Me”) for each group help to create a positive attitude all round.
Integration of Legacy IT Systems
A big advantage of an ITxPT-compatible platform is the sharing of information. This is at the heart of the benefits of safer, cleaner, more cost-effective and more enjoyable public transport. The aims of integration of legacy IT systems with the new platform are then to:
- Use a common communication channel (TCP/IP)
- Share information over that channel between all the systems, new and existing
- Get the status of each legacy system for maintenance purposes
- Monitor all the connected systems.
Joint system monitoring is a crucial part of the process the operators today wants surveillance in one interface and not coming from different systems.
Some legacy systems may already offer suitable interfaces for linking them into a new IT environment. They may use up-to-date network protocols that make communication easy. On the other hand, other legacy systems may be using connection methods from the Stone Age – so to speak! Different ways of integrating a legacy system, according to the nature of the system, are:
- Over an Ethernet-compatible connection, ideally with a standard RJ 45 physical connection and standard TCP/IP networking stack. This typically makes it easy for the legacy system to provide its system codes to the central surveillance system.
- Via a serial or IBIS (Input/Output Buffer Information Specification) interface. This also allows possibilities for providing system codes.
- Other analogue/digital interfaces. Diagnostics may be more rudimentary here, possibly only at the basic level of “working” or “not working”.
Levels of Systems Integration
Connection at the physical and network levels (see above) is a first step. The more integration can also be done at the other levels, the more possibilities there are for legacy systems to contribute to operations in the new environment. This helps to get the most out of existing investments, while reaping the benefits of new information technology.
Depending on the systems involved, we might aim at the following levels of integration (in increasing order of sophistication):
- Surveillance of the legacy system
- Extract information from the legacy system, for example, by logging into it.
- Change of the communication channel into a joint communication channel
Steps to Migration
At a technical level, the basic steps of a migration to the new information-sharing platform can be summarized as:
- Assess the possibilities of the legacy systems currently being used
- Integrate according to these possibilities and using integration guidelines from Pilotfish
- Perform testing of the integration to verify correct operations
- Roll out the new technology to the fleet of vehicles in general.
Each step must be carried out successfully, before moving to the next one. There is a wide variety of migration possibilities. Although the objective of a given step is the same in each case, different projects often require different solutions.
1. Assess Existing Legacy Systems
In most cases, customers have some kind of legacy system in place. The first task is to see if the legacy system works with, or can be adapted to, IP networking or European standards. The projected lifetime of the legacy system is also a factor here. For instance, it may not make economic sense to try to adapt a system with a total lifetime of 10 years, with only two more years left to run. In this case, a simple protocol gateway application to translate communications from one side to the other may be a more cost-effective solution. In other cases, a legacy system may control other sub-systems, such as cameras, validators and sensors. These will need to be considered when assessing overall connectivity choices.
2. Integrating the Legacy Systems
The willingness of the legacy system supplier to collaborate can make a difference, especially if the design specifications of the legacy system are not available. Ideally, the supplier will cooperate, if only to maintain a good business relationship with the customer. If the supplier is unavailable, some detective work may be necessary to extract legacy system information and enable a central surveillance console to log in to control or monitor. It may also be necessary to protect older systems better by adding an extra layer of security.
3. Integration Testing – Factory and Production
The first phase of integration testing (factory testing) is between suppliers’ systems. The second phase (production testing) is done in a real life environment, such as a bus running to a normal working schedule. Proper testing of integration also requires good test cases. Some PTAs and PTOs have well-developed test methodologies that help ensure that systems are properly tested in realistic conditions. Tools for automated code testing may be also provided by customers in some cases.
4. Rolling out the New Platform and Technology
Public transport fleets, not surprisingly, are usually in use. Operators want to optimize their return on investment. Apart from a few buses that are kept at a depot as standby or back-up vehicles, the others are likely to be out serving passengers and communities. As a result, time windows for installation of new on-board systems may be small. Buses may only come back to the depot for a couple of hours in the day, or even only at night. Careful planning of rollouts is therefore also important. If a migration can be done incrementally, implementing one module or function at a time, this may ease the problem of these small windows of availability.
As open standards become a larger part of digital systems used in public transport, migration will become easier too. New vehicle and IT equipment purchases can be made with migration in mind, specifying ITxPT compatibility from the outset. Legacy systems will always exist, by definition: they are the systems in place at the moment when a new module or new environment is to be used. However, legacy systems should increasingly facilitate migrations in the future. The ultimate goal is to be able to decide whether to migrate based simply on the advantages to be gained, without being held back by technical issues from the past.
Resources and References