Mobility-as-a-Service (MaaS) needs data for it to work. More specifically it needs data about the transportation purchases and usage of its customers. Therefore having access to a broader and more comprehensive set of mobility data over a decent period of time (and over all modes of transportation) provides a better understanding of the different transportation needs of each of those customers.
In short, MaaS can only be truly successful if it joins up the data from all different transport providers that its customers actually use.
So whether the data comes from rail, bus and subway services or taxis, micro-mobility services and commercial cycle hire schemes… this combined data (using either an aggregated or federated approach to join it all up)… all helps to enable more tailored transport services to be delivered to individuals or supports the ability to better match them to existing services.
Open Transport provides an Open Standard for the interoperability of data in customer transport accounts. It is a free standard that does not have to be restricted just to public transit services. Plus if implemented once, it offers the potential to integrate to any other service that also adopts it.
One (and perhaps the foremost) aim of Mobility-as-a-Service (MaaS) is to put the travelling customer at the core of the service and offer them tailor-made mobility solutions based on their specific needs.
2 very different approaches: To do this effectively MaaS requires one of two approaches to customer data:
An aggregated approach: The customer needs to have all their mobility data residing in the same place (e.g. a centralised online service). Meaning that every transport provider in that mobility ecosystem then needs to be part of a single MaaS Platform.
A federated approach: The customer allows their data residing in a number of different places (e.g. multiple online transport provider accounts) to share enough so that a complete picture of their transportation purchases and usage can be constructed.
To-date most MaaS efforts and initiatives have used the aggregated approach. This typically means a transport authority selects a single vendor for an entire geographic or legislative region and combines each participating transport provider’s data into a single database. The customer therefore has one account to access, view and use all this data.
However, this aggregated approach has several possible down-sides:
The participating transport providers are mainly restricted to public transit services such as rail, bus and subway.
Private operators, such as taxis, micro-mobility services and commercial cycle hire schemes tend not to be included (either because they do not want to be or because the barriers-to-entry are too high)
The participating providers typically do not have a direct relationship with their customers, they are simply part of a wider service.
Any vendor in a monopolistic position of running a large Maas Platform is less likely to innovate or invest in developing their product
The boundary (area of responsibility) of the MaaS platform is restricted by the reach of the transport authority, not by the journeys the customers want to make.
A different approach Open Transport, by providing a free standard for mobility account interoperability enables a federated approach instead. Transport providers adopting this Open Standard not only mean their customers can integrate a number of different accounts they own, but can then chose to manage this data in the account of their choice (e.g. the one that gives them the most useful or feature-rich experience).
Open Transport is an initiative that has released two different Open Standards for transport and mobility account interoperability. But one of the most common questions we get asked is about whether our work is really free or not.
Why standards? Standards are needed with technology, to ensure that more than one developer or vendor can work together on a technical product or solution.
Why Open Standards? Open Standards are standards that have been made publicly available and that can have various rights to their usage. Their purpose is to ensure that application developers (and therefore their clients) are not locked in to a specific technology or vendor. Open Standards also help make applications more functional (as more than one organisation can develop their ideas in parallel) and interoperable (as more than one product or service can be developed to align to these standards).
But… FREE? Yes. To ensure that our work has the greatest chance of adoption across the transport and mobility sectors, we have decided that the Open Transport standards are completely free to adopt, by any organisation, transport provider, authority, etc. There are no conditions or caveats to this, this work can be viewed, downloaded and used by anyone, anywhere. https://opentransport.co.uk/open-standard/
What do we want in return? Nothing. Since our aim is uniform and mass adoption of a consistent transport account interoperability standards across the mobility ecosystem, this alone would be sufficient reward for all the work that has been put in. But if any adopter wanted to credit Open Transport by mention us and this website in their terms & conditions or code, that would be fine too.
CR002 Change of API structure to align to PAS212, the automatic resource discovery for the ‘Internet of Things’ specification. Also now reflected in our Operator-Info API reference implementation at https://open-transport.azure-api.net/operator
CR003 Expansion of the look-up service to include MIPTA (Mobile Interface for Public Transport Assets) asset registry endpoint location (URL)
When we set-out to create the Open Transport standard, we had in our minds the problem that many transportation customers have:
Multiple online / self-service accounts Typically one for each transport provider and another for each Mobility-as-a-Service (MaaS) platform.
Multi-modal journeys Those commuting, business and pleasure trips that involve more than one mode of transportation.
Limited time Or perhaps just a frustrated need to have things “work as I want, when I need them to”.
So we created a common interoperable specification for allowing any transport or mobility account to share transportation-specific data (only). And we made it available as an Open Standard, for free and without caveat or constraint.
So now, this enables a customer to link their participating transport accounts and then use a single website or app to view all this data in a consolidated way.
Today we are announcing a update of our “customer-account” API specification to version 1.0.1
This small-but-important update from our original Open Standard is backwards compatible with v1.0 , with the addition of an “account-balance” for each purchase / product. Therefore making the standard more useful for the interoperability of those accounts that store a monetary amount, such as an Account Based Ticketing (ABT) proposition or a pre-paid Mobility-as-a-Service (MaaS) scheme.
As part of our standards work, we quickly realised that we needed to centralise around a common definition of the “mode” of transport. Other definitions of the “method of conveyance” that were identified during the evolution of the standard we created were either too restrictive (e.g. just covering public transit) or proprietary (and therefore not suitable for a truly open specification).
However, after consulting with another European public sector transport body, we published the following list of modes:
001 = on foot (for complete end-to-end journey mapping) 002 = cycle (includes both human-powered pedal cycle and ebike, typically rented or shared but also possibly privately owned for complete end-to-end journey mapping) 003 = moped & motorbike (shared & privately-owned self-powered vehicles, for complete end-to-end journey mapping) 004 = scooter (includes human and electric/battery powered where passenger steps in/on) 005 = segway (includes any motorised self-balancing personal platform and also electric unicycles) 006 = car (includes any vehicle where the driver is also a passenger, such as: car / van vehicle rental, car pool & car club) 007 = bus (includes any vehicle typically greater than 8 seats.. such as a mini bus) 008 = tram (includes any guided vehicle such as a streetcar and also trolleybuses that are limited by overhead power lines) 009 = metro & subway (includes any light rail transit and their interconnecting systems) 010 = train (includes intercity, Eurostar / TGV, etc.) 011 = water bus (includes river buses, typically just passenger service with multiple stops) 012 = water ferry (includes passenger only and also passenger & vehicle) 013 = air (aeroplane, helicopter, etc.) 014 = car parking (includes on-street & off-street) 015 = taxi (includes any vehicle where the driver is NOT a passenger) Since January we have also now:
Received a Change Request to add a further 16th mode: 016 = suspended cable car (includes any aerial cable cars, such as London “Emirates Air Line”, Barcelona Montjuïc & Port Cable Cars and New York Roosevelt Island Tramway)
Note: This change has now been accepted and we are now in the process of updating our specification
The transport and mobility sector is not known for the pace of innovation that some others have (e.g. FinTechs).
To help change this we firmly believe that the new world of transport & mobility needs to be open (not proprietary).
This means: an open ecosystem, open technology and easy collaboration between services using open APIs.
Adopting this openness means transport providers and Mobility-as-a-Service (MaaS) Platforms can connect to a wider external ecosystem of suppliers and consumers of their services. They can then potentially collaborate much easier on new product offerings. This all helps to reduce development time & costs and reducing vendor lock-in.
Embracing this open movement means newer entrants be introduced much easier. Putting the power to innovate firmly back in the hands of those most able to provide it.