In 2019, the Dutch Ministry of Infrastructure and Water Management, together with seven regions in the Netherlands, launched seven national Mobility as a Service (MaaS) pilots.
Each had a specific scope, such as inclusion, lowering the possession rate of private cars, international travelling, rural areas, et cetera. Each pilot was tendered and granted to a consortium, with at least one MaaS service provider with a MaaS app in which one can plan, book, execute and pay for multimodal trips. Every pilot started with its own, well-known portfolio of transport services.
But the seven pilots aimed a lot higher: they had to scale up into one open, (inter)national-covering ecosystem. And comparable with the ‘hard’ infrastructure, the Ministry facilitated in setting up a ‘soft’ infrastructure - a digital infrastructure. Its vision was that this ecosystem should be federated, open, providing a level playing field, based on standards to facilitate the ease of becoming part of this ecosystem. One of the first by-products of these pilots was the TOMP-API: a MaaS standard, based on the General Bikeshare Feed Specification (GBFS), a standardised data feed for shared mobility system availability.
The ‘why’ of the TOMP-API
The evolution of mankind and its technologies went hand in hand with standardisation to understand each other better and avoid miscommunication. And that’s exactly the ‘why’ of the TOMP-API: to facilitate easy and clear technical communication between transport operators and MaaS providers. To facilitate the usage of this API, we made it a gift to mankind (or, at least, the world of MaaS): it is open-source, everyone is allowed to use it.
This precise definition of communication allows the transport operator (TO) to connect easily to multiple MaaS providers (MP), lowering the costs of operation and deployment. The same is applicable for MaaS providers: connecting to multiple TOs, using the same language, the same set of ‘sentences’ for planning requests, booking, trip execution (including support), providing information and payment. So, on a high level, you could say we only agreed on speaking one language (e.g. global English) and have a structured dialogue with a limited number of questions that can be asked and answered (‘the sentences’).
The ’how’ of the TOMP-API
How did we do this? There is only one answer: common sense, open cooperation and persistence. MPs and TOs sat together, discussing how we could create a booking method for all modalities (modes of transport), to ask each other for availability and so on. In the past two years, we managed to set up this API, based on numerous and fruitful weekly discussions and, later on, in bi-weekly meetings. A huge effort, but very valuable. The proof of the value can be found in the number of organisations that have adopted the TOMP-API, globally, but thus far mainly in Europe, Australia and North America. In the current situation (we’ve reached a long-term supported version 1.2), we look at the reported issues and try to give our vision of how they should be handled - or if needed, we can create a proposal for version 1.3.
Why is it different from other existing mobility standards? In an article from 2017, written by Sochor et al, five levels of MaaS maturity were described. The vast majority of standards for mobility are dwelling in level 1 ‘Providing information’. There are only a few standards that operate in level 2 ‘Booking, payment’. Every API at level 2 has a proprietary implementation (e.g. for Whim, Trafi), except for the TOMP-API. Although the TOMP-API started with shared bikes and cars, it soon covered all modalities.
TOMP working group
The TOMP working group is developing the TOMP-API together with the MaaS ecosystem, with the vision to provide effortless mobility for everyone. Its mission is to develop and sustain an internationally-governed, interoperable open standard for technical communication between TOs and MPs, by means of defining, improving, aligning and disseminating it.
In the near future, this will result in some extensions for ancillaries, and integrations with personal data stores, clearing houses, and discovery services for example. In short, we expect a bright future for the TOMP-API, growing into a globally-accepted standard for booking and handling MaaS-related assets, in collaboration with most established standards (for example GBFS, GTFS, and NeTEx).
Ecosystem roles
The TOMP working group is looking at organisations that are active in the MaaS ecosystems, like clearing houses, travel rights stocks, identity providers and discovery services (Yellow Pages for MaaS organisations). Part of our mission is ‘aligning’ and we take this very seriously. The TOMP-API is created in a modular way, only covering the parts specific to MaaS, allowing other APIs alongside for user registration, creation and provisioning of tickets, and clearing. These can be addressed in the relevant parts of the TOMP-API, but will never be part of it. If necessary, the TOMP working group will set up new APIs for these parts as well, in cooperation with organisations that act within these scopes.
National Access Point
As mentioned before, we see a lot of roles in the MaaS ecosystem. One of them is the discovery service, and that might be combined with the role of National Access Point (NAP) as demanded in EU Directive 2017/1926. The NAP provides a portal for the distribution of information about (micro)mobility. Hopefully, all European NAPs should be aligned and standardised as much as possible by the NAPCore project. This would make a pan-European ecosystem for MaaS easier to achieve.
The current NAP in the Netherlands provides real-time information about public transport assets, actual road situation, timetables, transit stop and station locations, charging stations (location and availability), look-up tables for MaaS providers, and MaaS types (like categories, modalities), parking lots (location and availability). This NAP will be extended to provide services for an international MaaS ecosystem, as a national access facility for mobility.
The NAP (and the Dutch government behind it) wants to facilitate the mobility sector in the transition from possession to the usage of transport modes with all kinds of data. At the same time it wants to control the ecosystem, like a shepherd, to sustain the public conditions, such as providing a level playing field, the inclusion of all travellers, privacy and data protection.
Important points during the creation of the NAP are alignment with the EU, sharing data according to the principle ‘open, unless’, the usage of international standards (or facilitate in creating them) and encouraging the usage of the gathered and shared data to set up private services. Information concerning mobility networks, aggregated travel information, and its effect on the environment also enhances mobility policies by local and national governments.
Current state
We see a lot of work being done, and we invite parties to get aligned with us, instead of solely working on their solution. This starts with governments (currently cities request a MaaS solution, without demanding interoperability with other MaaS solutions in cities nearby); MaaS providers (often invested heavily in their own, proprietary solution and not having the money to implement another, standardised solution); and transport operators (aiming to become a MaaS provider themselves, only extending their current portfolio with more first- and last-mile solutions). Their common argument: the best solution is my solution...
With this short description of the current state of play, the actions to take seem obvious: start cooperating and aligning. Not easy, with a lot of different stakeholders and intentions – and even harder when taking the international aspects into account.
Standardisation, like the TOMP-API initiative, is one of the few tools we have to start with. It might look like a battleground, it will demand a lot of effort – and it might take years to accomplish. But the goal is worthwhile: effortless mobility for everyone.
ABOUT THE AUTHOR
Edwin van den Belt is a software architect at Goudappel subsidiary Dat.mobility, and a member of the TOMP working group
