Mobility Platforms – A View from the Kerbside

Transport Planners and Engineers deal in physical things – buses, trains, bicycles, tickets, dual carriageways, bridges. Even our models are depictions of real life – little cars whizzing around virtual environments.

It’s not a surprise then, that when confronted with the digital world, with its concepts, metaphors and abstractions, we are not always comfortable.

Yet digital systems are transforming the transport environment, from apps such as Uber and Citymapper through to Mobility as a Service (MaaS) and autonomous vehicles – we need to catch up rapidly so that we can take advantage of the benefits that digital devices can bring.

This article explores the concept of mobility (or transportation) platforms, as viewed from my perspective of working for a local authority, charged with the responsibilities of managing and maintaining the public highway.

The article aims to simplify the terminology and to deconstruct some of the concepts, so that industry players feel better equipped for the digital future.

So prepare yourself for a world where data -simple lists of zeros and ones, the presence or absence of electrical charge – turns into interfaces and containers, structures and queries, wrappers and envelopes etc, etc, etc

Background

In an attempt to resolve some of the issues outlined above, the UK Department for Transport (DfT) has engaged a range of consultants charged with answering something akin to the following question:

What kind of platform do local authorities need to help them cope with/facilitate/drive the emerging digitisation of the transport system?

In answering this question, we first need to understand what we mean by platform in this context.

What is a Platform?

Google Trends shows a significant increase in the use of the word ‘platform’ since 2010. Vendors no longer wish to sell local authorities software or apps, they want to sell us a platform.

If you’ve spoken to me at any time over the past two weeks, I will have canvassed you by asking what you understand by the word ‘platform’. Very few have been able to provide a strict definition. Instead, many have tried to use analogies that describe some of the functionality of a platform, the epitome being a recent conference on mobility platforms. Twenty-five minutes were spent with various people discussing the topic, but by the end, I only had a definition that could equally apply to the word ‘thing’.

Even so, I did receive a few definitions, both from learned individuals and by searching online. My favourite, because it was the most reductive and simple, came from Adrian Bridgwater, writing in Forbes magazine:

The industry considers a platform to be anything that you can build upon.

Indeed, Wikipedia defines a computing platform, as:

“A framework on which applications may be run”

So (and for my first analogy) think of a platform not as a railway platform, but as a base or a plinth, providing the right surface to build your masterpiece upon.

I then expand this simple phrase, to make it closer to what we are thinking of in terms of transport:

A software platform…

because we are mostly talking about software here.

… connected to the internet…

because we need to be able to access it from anywhere.

…that provides output that you can use as inputs to another piece of software.

Perhaps this is already too complex, but what I’m really saying here is that the platform is able to output information in a form that other software can use. The fact that it is connected to the internet means a standard way of communicating between different machines already exists. Most commonly, the way in which two pieces of software talk to each other so that they understand each other is via an Application Programming Interface or API, which I will come to later.

Before leaving the subject of platforms, I should give special mention to Mark Cartwright of Centaur Consulting, who took precisely 2 minutes to come up with this technical gem:

A platform is an ordered triple (I,R,D) where:
I is an institutional structure (forum, assembly, club, working group, corporation, etc) with membership and governance rules
R is a designated set of roles and responsibilities (scope, force, accountability and authority, etc)
D is a set of (data) resources, probably evolving, which I is charged with managing and maintaining in support of the delivery of R

Despite being a complex description, I’ve highlighted a few words which describe the features a platform needs, because, in practice, my definition is oversimplified.

  • Platforms should have membership and governance rules. We need to decide who is able to access the data and how that is governed (i.e. by providing usernames, passwords, access keys and also licensing).
  • Each member/user of the platform should have roles and responsibilities that are assigned to the m— that defines what they can access and what they are able to do.
  • The data itself needs to be managed and maintained — kept up to date.

How Many Platforms do I need?

I don’t need another platform, I’ve already got more platforms than [Birmingham] New Street Station!

I overheard this from a senior colleague towards the end of a presentation from a beleaguered supplier, desperate to sell their latest platform to the authority.

I will, in fact, argue in this section that there probably isn’t an upper limit to the number of platforms that you need, more that the only thing you don’t need is a single platform to rule everything.

The benefit of having platforms that can connect and communicate with each other is that you can design a system that more closely fits your needs. If we go back to the building analogy, on top of the physical platform, or base, you could specify that an entire house is to go on top, or you could separately specify each room, furnishings, fixtures and fittings.

The diagram below shows a simple transport platform. It collects data from traffic sensors and groups it together. It also includes an API that allows other software to query the data that is in the platform with 3 examples given. At the bottom of the diagram I also show that the platform itself might be reading in data from another service, e.g. an external service that all collects traffic data.

But that’s not the whole picture. On top of this platform you might specify a platform that analyses that data to produce daily, weekly and yearly averages and to collect together different groups of sensors. Then on top of that you might have a transport model, which needs that data as an input to its calibration routines, and also a platform that produces Key Performance Indicators for decision makers, and one that produces interesting graphs and visualisations.

But what you need will be different from others for a number of reasons: you will have different policy priorities, staff skill levels, budgets, governance procedures. You will also have existing contracts that you can’t change.

Another benefit of having a ‘constellation’ or ‘ecosystem’ of platforms is that you don’t have to replace the whole system in one go, if you want to upgrade your sensors, you can do that without changing your analysis platform or your visualisation platform.

There are disadvantages though, chiefly that the more platforms you have to integrate, the more of your time will be taken up doing it, so it’s likely that your platform will be most detailed in the areas you care about most, and will be simpler in the areas where you don’t.

In the diagram below, I’ve tried to group differing transport platform types together. This is not exhaustive and the groupings are just abstract concepts, putting similar platforms together. I’ve seen similar, but differing groupings from people who see this in a different way.

I’ve put raw data platforms at the bottom, these are the platforms that are mostly involved in getting primary data from the source. These platforms are usually involved with improving the accuracy of the data, by ensuring that everything is properly managed and maintained.

The middle layer is processing. This shows platforms that do the number crunching, so this is where the data analytics, machine learning and modelling come into play.

The top level is the user layer, usually querying and visualisation software (not always platforms, as they don’t necessarily have output APIs). This presents the data in formats that we, as humans, would like to see it in, as funky graphs, 3D flythroughs and (most importantly) Excel files and PDF’s.

The diagram is also local authority centred, in that it shows the platforms that are owned or commissioned by a Council. Increasingly though, data is brought into the Council ecosystem from independent platforms, which are collecting traffic data (such as Inrix and mobile phone operators) or map data (OpenStreetMap) and any number of other things.

As time goes by, I would expect this sort of diagram of ‘platforms you need’ to become more detailed and better thought out than mine.

A word on open data

You might have expected more emphasis on platforms as open data. Many of the will be as council data is paid for by local taxpayers and therefore will be open by default. However, there are licensing restrictions on some data provided by third parties, so your network of platforms will be a mix of open and restricted data. The diagram below sets out the open data spectrum.

source: Open Data Institute

So what is an API?

An API is a way of communicating between two pieces of software. More often than not it takes the form of a web address or url. If you ever look at these in detail you will recognise some of it.

www.myexampleapi.com/data?apikey=#A8C34F&datefrom=01/01/2018&dateto=31/01/2018&type=flow

What this does, is make a request, or query, for data from the other computer. They won’t all look exactly like this, it’s just an example. For the most part, the actual request comes after the ‘?’, different parts being separated by an ampersand. You don’t necessarily need to understand this detail but if you break it down, it is quite clear.

  • Apikey – this is a unique code to identify who (or what) is making the request
  • Datefrom – the start date of the data
  • Dateto – the end date of the data
  • Type – the sort of data you want – in this case traffic flow

What is returned (if you type this type of query into a browser it is returned as a web page or a download) is a list of the data that you asked for. This can then be used by the software that has asked for the data.

It’s really that simple, an API is just a machine asking for and then receiving some data. At its most reductive level you could think of the platform of just being its APIs – just a piece of software with the ability to communicate with another one.

Obviously there’s some complexity. Each platform can have more that one API, or at least a range of different queries that can be made, so differing platforms can ask for different things.

Equally APIs can be push as well as pull, so platforms can regularly send data to other ones, instead of waiting to be asked for these.

Standards

People who talk about mobility platforms want there to be standards.

I would argue it’s not the platforms themselves that need to be standard. They can be quite bespoke, but it’s the API’s that could be standardised.

In fact, they don’t have to be, but it would be nice if we had a common understanding of traffic flow, speed, journey time etc.

These standards already exist. Datex II for example provides standard for exchanging data between traffic centres, UTMC has data objects that describe a number of types of traffic data, Siri provides for real time information etc etc etc.

Many APIs already use these standards, but an exercise to determine which are the best, simplest or easiest to use would still have some value.

Conclusions

In this article, I have tried to describe and simplify some of the issues around mobility platforms.

What conclusions should you draw:

  • Local authorities should determine what their constellation/ecosystem of platforms needs to look like. When purchasing platforms they should specify that a well commented, open, API is provided.
  • Suppliers should provide these APIs. They should also double down on ensuring that the key features of their product are the most accurate/ cheapest/ reliable, rather than trying to build products that do everything.
  • Consultants who support local authorities need to up their game in understanding how platforms work so they can provide the right advice to authorities.
  • People that worry about standards, mainly governments and industry bodies, need to identify and specify the best standards for transport/ mobility APIs and stop worrying about trying to specify a mobility platform

Final Word

So what is the ‘mobility platform’ that we all need. If it’s anything, it’s the platform that allows people to discover what is available from each of the platforms.

You’ve designed and bought your ecosystem, but how do your partners and developers know what you’ve got.

Data discovery platforms (also called portals) already exist, data.gov.uk is one, and done right, they should enable everyone to quickly find the data that they require. My comment back to people who are seeking to develop this type of platform is that they should be:

  • more user friendly and relevant than they currently are, whilst avoiding the dataset ‘race’ of how many pieces of data have been published
  • up to date
  • frequently maintained
  • be very searchable so you can find exactly what you need