Maturing ITxPT marketplace part 1(3)

Life cycle management

When investing in an onboard IT solution, you need to think about the whole life-cycle of the system (i.e. more than 10 years for on-board solutions). An important question arises: Exactly what technology is to be installed and what applications are to be used in the vehicle for the next 10 years? If you cannot answer the question, which you probably can’t, you need to know how to handle the effects of a fast evolving reality.

In this article we will supply some basic information that will help you meet the future with confidence, knowing that you have done what you can to prepare for the exponential development pace in the field of IT solutions for public transport, with new possibilities, demands and requirements. The key words are dynamic, modular and scalable. We wish you a happy reading.

Scalable and modular infrastructure

Even if no-one probably would buy an IT system without thinking about the life cycle management any more, there are some issues that you should be extra careful to incorporate in your planning process, to cope with the fact that you don’t know what you are going to add to it or use it for, ten years from now.

First of all, the infrastructure needs to be scalable and modular. This way you can add functionality and expand the system step-by-step. The infrastructure needs to be prepared even if you don’t know the exact requirements and needs. If you assign an integrator to supply the system, and help you manage it, the integrator role needs to be defined, both in terms of technical architecture and in terms of integration software responsibility. These issues need to be carefully planned, so that you are able to choose between all the different module suppliers that are emerging within the ITxPT (Information Technology for Public Transport) ecosystem, even ten years from now. Even if you are going with a single supplier, you need to think about putting in paragraphs in the agreement with sub-suppliers regarding life-cycle management and future compatibility with upgrades.

Integrator core minimum

What does the core minimum offering look like that an integrator need to supply in order to take on the integrator responsibility? This question is based on the assumptions that there needs to be an integrator role in order to have multiple suppliers involved each carrying their own responsibilities for their respective offerings. To define the integrator role, we will go through the technical and structural responsibility the role carries. What does the integrator have to supply?

Communication

The integrator needs to supply communication to back-office for onboard devices as well as connection between the different connected modules in the network. Normally this takes place through Ethernet and APN (Access Point Name) for mobile connection. The network can be both low speed or high speed, e.g. WIFI 4G. There is a possibility that redundancies can be requested.

Surveillance, monitoring and faults

Other functions that the integrator needs to supply is for example surveillance and monitoring of communication and connection to internet (WAN) Wide Area Network and the communication to and between connected devices (LAN) Local Area Network, including up-time, fault codes and so on. Support for faults is another issue that needs to be covered, with surveillance and fault management, logging ability onboard and support for complex faults that include many actors.

Software

There needs to be a place to run software in order to handle the interface to multiple attached systems. E.g MQTT (Message Queuing Telemetry Transport) runs here with a possible link to a workgroup handling virtualization. The MQTT is an ISO standard messaging protocol, designed for connections with remote locations where a “small code footprint” is required or the network bandwidth is limited. Services can run here such as GPS and FMS-to-IP etc. Broker [MQTT] and logs can also be executed etc.

Software download and Automatic configurations

This is a core functionality to be able to correct faults and also to implement new integration software. In large fleets, vehicles also need to be configured automatically, based on back-office defined profiles or similar functionality. There is also a continual need for software developments both off- and onboard.

Hardware

There is a core basic of hardware that is needed as well for an onboard network solution to function, where the central part is the Vehicle Gateway, could be described as an advanced router with functionalities and solutions for integration of the different onboard systems. There is also a need for a processor, memory, connectors, IP network (Ethernet). The vehicle CAN (Controller Area Network) will also be a part of the architecture, as well as Legacy system I/O’s (Input/Output through computer/device interface).  

Other issues

There is a need for a system architecture, which controls how things are connected and implemented. This goes for both hardware with it’s connectors etc. and software interfaces such as mDNS and others. The complete system is also in need of management throughout the complete life cycle. There is a need for an IP plan and let’s not forget the need for project management skills.

Maintaining the core minimum

As you by now might conclude, to maintain the basic level is not in itself an easy task. If you for example would invest in the hardware and then run the system, you would find yourself facing the task of solving all integration issues with silo solutions, to monitor the system and keep the uptime high, and to keep all parts of the system updated. There is a need for constant development to maintain the service of keeping the communication running without disturbances. Unless you want to handle all updates manually inside the vehicle, you also need to see to it that you have the possibility to remotely download and install updates to all the different onboard systems.

You need to keep the system up and running all the way from the onboard systems, via the connection to the server and the back-office system, as well as to develop any software applications you need in the vehicle, in the back-office and any supporting smartphone- and back-office applications. No doubt is it possible, but it is questionable if it is economically viable to keep that level of specialized IT competence inhouse to develop your own solutions, and in a way reinventing the wheel. If you still feel that this is the model for you, then you really need not read any further. We just wish you the best of luck! However, if you feel that there is something to be found in the idea of outsourcing the IT solutions, we will do our best to serve you with some useful information about where the branch stands today, and where we believe it is heading. We have cooked it down to the essentials with broad, general strokes of the past, the present and the future as we see them.

What does the marketplace look like?

The marketplace of the ITxPT (Information Technology for Public Transport) ecosystem? Who do the PTA/PTO buy from today? There are a few different suppliers of solutions or whole ecosystems, and a general overview would suggest that the options for the customer boils down to the following list:

1. Total responsibility suppliers with all applications and modules.
2. In vehicle application supplier with their own modules (hardware carrying an application such as passenger counting) – and its respective back-office. They can take responsibility for one or several applications and/or services.
3. In-vehicle applications running on other supplier’s module in the vehicle and its respective back-office. Linked to virtualization.
4. Pure back-office applications that are served by information emanating from the vehicle modules.
5. Pure module suppliers more focussed on supplying hardware than software, can often include a service but not a whole application.
6. Integrator platform suppliers.
7. Integrators, can have their own integrators platform or not.
8. Telecom network suppliers, can have direct sales to end-customer or go through either category 1, 2 or 3.

Dynamic world – dynamic solutions

The technical development of the world today moves very fast, which means that state of the art products from this year might be outdated next year. As an example, we moved from 2g to 3g and 4g in just a few years. The IT development pace is faster than development in other fields, which means that some products have a considerable longer lifespan than the IT solutions that might be connected to them. This is the case for public transport vehicles and their on-board IT solutions. A vehicle’s lifespan is maybe three to four times as long as the time a static IT solution remains relatively up to date. This is also true for some of the analogue onboard systems supported by the IT environment, which means that a system with continuous software updates has considerable benefits, since it prevents from having to change the software solution or even exchange functional hardware, just because they aren’t up to date from an IT perspective. The more fast-moving and dynamic the IT evolution becomes, the more the demand increases for a system that evolves with the rest of the world. As mentioned above, one of the most vital parts of a vehicle IT system of today is that it supports remote download of software updates. You also need the possibility to support installers/maintenance personnel with advanced fault searching tools and knowledge (e.g. logging).

Sophisticated systems

A vehicle is not an isolated product that stays the same, from manufacturing all the way to the scrap yard. More and more systems are added to the IT environment of public transport vehicles, driven by evolving customer behavior and demand, as well as demand from clients and authorities. Since hardware might not be subject to the same fast development, the focus in terms of new functionality gradually shifts over to development of software and services. The hardware needed to build an onboard IT environment could very well, in a not too distant future, become a standard hygiene factor that supports the software solutions. The more sophisticated a system becomes, the more it moves towards software- and service deliverance. The evolution has gone from pure hardware, to hardware with software support and then further to software with hardware support. Now we are starting to shift from software to service. Software today, is much more dynamic than before, which means that what you want is a service, or rather a selection of services which cater to your needs in an evolving IT ecosystem. The demand moves to where you can add new functionality in the same way we have become used to, through our mobile devices or computers.

Until next time

In the first of three parts in this blog post about the ITxPT marketplace we have gone through the life-cycle management of an fleet IT solution as well as what the minimum requirements look like to make it work and the importance of a dynamic solution.

In the next part we will cover the global phenomenon from other industries with service subscription, complimentary hardware and the evolution of Internet of Things.

Disclaimer: The content of this blog post is the author’s opinion and doesn’t reflect the opinion of any other person or organisation.