This week, two of our board members (Marcus and Hayden) presented to the Open Banking World Congress on the context, history and future of Open Transport.

In a 40 minutes session called “Advancing Towards Open Transport” they explained the use cases and benefits of an Open Standards for mobility account interoperability.

Although the Open Banking World Congress 2020 is now closed, it is still possible to register for the on-demand archive of presentations that should be available soon:
https://openbankingworldcongress.com/register/

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.

This update has been published online here:
https://app.swaggerhub.com/apis/open-transport/customer-account/

Amendment process:
If anyone would like to consider any additions or changes to these, please see our published amendment process:
https://opentransport.co.uk/2020/02/03/amendment-process-for-our-open-standards/

We have been asked by several organisations to publish a table of mode definitions, as used in our Open Standard:

ID	Mode	Description
001	on foot	where the person is a pedestrian (used 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)
003	moped & motorbike	includes shared & privately-owned self-powered vehicles (for complete end-to-end journey)
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 streetcars (motor or cable-powered) and also trolleybuses that are limited by overhead power lines
009	metro & subway	includes any light rail transit and their interconnecting systems, whether over or under the ground (e.g. Glasgow subway & London DLR)
010	train	includes intercity, Eurostar / TGV, funicular, etc. carried on either tracks or mono-rail (incl. MagLev)
011	water bus	includes river buses, typically just passenger service with multiple stops
012	water ferry	includes passenger only and also passenger & vehicle (especially ‘roll-on roll-off’)
013	air	includes aeroplane, helicopter taxi, etc.
014	car parking	includes on-street & off-street (e.g. dedicated building or airport short & long stay)
015	taxi	includes any vehicle where the driver is NOT a passenger
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

If anyone would like to consider any additions or changes to these, please see our published amendment process:
https://opentransport.co.uk/2020/02/03/amendment-process-for-our-open-standards/

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:

• Deployed our list of transport & mobility modes as a sample “mode” API :
  https://open-transport.azure-api.net/mode
• 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.

Our Founder, Hayden Sutherland, was recently interviewed by a University student on the topic of innovation.

Here are the questions & answers provided:

Q1 : Did you use a specific innovation model or follow a process when carrying out your innovation?

A1: When originally coming up with the original idea, there was no specific model or approach used. However, to get this idea to actually become the reality of an accepted & published Open Standard, there was an established process to go through:

• Collate a pool of experts from as wide & diverse group as possible to create a “straw man” concept of the specifications
• Invite others to participate in workshops and an online community to evolve the specifications
• Publish the draft specifications
• Issue an open invitation to provide input and general feedback from the entire international community (if you want nice feedback ask a friend, but if you want real criticism … ask an enemy)
• In addition, and to get the widest possible reach and honestly, an event was organised by MaaS Scotland (the industry body for the transport and mobility sector in Scotland) where I got to present my latest specification and future direction to my peers. This “technical Dragons Den” was very useful as many different specialists got to: listen in full, ask specific questions and even bounce ideas of each other to challenge the draft spec. This all helped to refine the detail and really ratify the work that had been done
• Publish the specifications as an official version (v1.0) of the Open Standards, along with content on their free usage and a clear process for requesting changes and improvements in the future.

Q2: How did you make decisions throughout the process? Did you use any models here?

A2: There were no set models used for decision making. But from the beginning and throughout the entire process I was very aware that a potential barrier to us achieving the best decisions was if they were made by just one person (me). To therefore make certain this did not happen, I ensured I was significantly guided, challenged and helped by a wide group of industry specialists, who are each experts in their field or mode of transport. The most foolish thing would have been to have brought together a group of people who were all specialists and then not continually listen, ask, consult and more generally work with them.

Q3: Did the culture of the group support innovation?

A3: Yes, the group’s culture was particularly important and this really helped to get the standards published in such a comparatively short space of time.
If you want to get the best out of people (and I wanted to, see answer 2 above), you have to ensure that they have all the right inputs, cues or data (e.g. a firm understanding of when this innovation will and will not be used or applicable) and also are able to speak their mind and develop the ideas of the others in the group.

We regularly get asked for a short description of what Open Transport specifically is (our ‘elevator pitch’). So, we thought we would share this here:

Open Transport is the first & only Open Standard for Transport and Mobility account interoperability. It is best described simply as the “Open Banking for Transport”.

The standard, released on 3rd January 2020, is made up of two different two Application Programming Interface (API) specifications that can be used separately or together to help provide an open mobility system:

1. Customer-account API
   A standard way to expose mobility account data (not personally identifiable data) owned by a customer when integrating to another account, regardless of transport mode or system. Thus potentially allowing the customer to view all their transportation and associated data in one place. Properly implemented, this means the travelling customer has no more continual searching across various apps and websites to join-up journey, ticket and discount data.
   https://app.swaggerhub.com/apis/open-transport/customer-account/
   
2. Centralised Operator-info API
   A design for a centralised look-up for all transport operators and Mobility-as-a-Service (MaaS) platforms. This first-of-a-kind transport directory service (similar to the sort code directory within the Financial Services Industry) will provide unique reference information about each mode of transport or mobility organisation, including Customer-account API locations.
   https://app.swaggerhub.com/apis/open-transport/operator-info/

We have a published process for suggesting further amendments and improvements to this Open Standard. So if it does not exactly meet the needs of a specific transport provider or mobility service, we can look to amend our specifications in a backward compatible way .

Plus, being a truly Open Standard… both API specifications are free to adopt and adapt, without conditions. All we ask is that Open Transport is informed and publicly mentioned when either is used.

Want to know more? contact@opentransport.co.uk

The two Open Transport API specifications were published as Open Standards on 3rd January 2020. Since then the Board has received the following Change Requests to modify and improve these designs:

CR001
API: Centralised Operator-info API
Change: The addition of another “mode”, that of: “016: suspended cable car”.
Plus also some mapping work to clarify the use of Open Transport “modes” against those used in the GTFS standard.

CR002
API: Centralised Operator-info API
Change: Change of API structure to align to PAS212 (the Internet-of-Things directory standard)
In effect, making the Open Transport Centralised Operator-info API a mobility industry-specific implementation of PAS212.

CR003
API: Centralised Operator-info API
Change: Expansion of the centralised look-up service to include an additional MIPTA (Mobile Interface for Public Transport Assets) asset registry endpoint location (URL)

CR004
API: Customer-account API
Change: Add “account balance” to add “account balance” to “purchase” data
This exposed the transport credit balance of any account based travel (ABT) system or stored value product. So that the balance can be viewed in another integrated transport provider account.

On the assumption that these Change Requests are accepted, this will result in a version update to both API specifications.

In a recent interview with Cliff Notes Podcast host Tristan Bailey, Hayden Sutherland Founder and Chair of the Open Transport initiative shares his thoughts on Transport and Mobility account interoperability.

In the interview they cover:
– What the Open Transport standards?
– What is an Open Standard?
– What are Open Transport helping businesses with?
– Is there a cost or saving?
– Who benefits from Transport and Mobility account interoperability?

You can here the whole interview here:
https://cliffnotespodcast.com/podcasts/30/