What PLATO taught me about the power of simple models
Recently I've been thinking a lot about how complex transport modelling has become, and the advantages of keeping things simple. I hope to write some more about this, but it particularly got me thinking back to my first job in transport modelling, using what I now realise was a VERY simplistic model, which nonetheless delivered powerful insights.
I'm referring to a model of London rail commuting called 'PLATO'. PLATO stood for 'Peak Loadings Analysis of Train Operations' (acronyms were a big thing back then), and was used by London train operators to balance their timetables and rolling stock to reduce crowding. It was complex simply because of the vast number of trains, stations and routes, producing a huge number of options for allocation of train capacity, which were tied up with passenger choices.
PLATO was in many ways a very simple model: it predicted how heavily loaded peak commuter trains would be, based on an input demand matrix and desired arrival times at work. The only decision it modelled was passengers shifting between trains, balancing their desired arrival time against the level of crowding on the train.
Though pretty simplistic, PLATO was popular among train operators because it helped the tricky balancing act of demand vs supply when potential outcomes were too complex to deal with manually. It also performed the classic modelling trick of making several weak datasets more than the sum of their parts:
By balancing and calibrating these, we were able to fill in the gaps to replicate 'current' travel patterns, and predict responses to timetable and capacity changes. The results were described as 'spookily accurate' by experienced planners. The process had the bonus that we were able to pinpoint where the most fare-dodging was taking place!
So there was much to learn about the value of simple modelling with sketchy data.
领英推荐
But the fundamental lesson I've always taken from PLATO is how it simply got across a really fundamental point about the trade-off of 'supply and demand'. You see, in those early days of privatisation new operators had entered the market with bold ambitions and promises to rethink how the railways worked. A popular idea was that crowding on peak commuter trains was caused either by a lack of rolling stock or just poor planning of capacity against demand. If more carriages were purchased, and the most crowded trains lengthened, surely the problem could be solved, and commuters need never stand again!
Naturally, some railway managers who suspected it wasn't as simple as that, but lacked the means to express their concern. PLATO proved a good tool for illustrating where this idea fell down: in reality, the most crowded trains were popular because they arrived in London precisely at the peak. The 'shoulder peak' trains were less crowded, but passengers on them were keen to switch to a peak time if only there was just a little more space. So ultimately adding more carriages to the crowded trains resulted in those trains remaining as crowded, but the other trains being emptier.
In fact, we were demonstrating with PLATO that the level of discomfort on a peak train was in perfect balance with the desire to travel at the peak time! We were able to show this in a simple model because it represented the three vital elements: the overall travel demand, the travel options available, and the trade-offs being made by each passenger.
You could of course argue that it was still worthwhile to provide more peak capacity, as allowing more people to travel at their preferred time creates value. But the fundamental point remains that eliminating crowding (or congestion) is seldom possible simply by adding capacity, because there is 'suppressed demand' which will quickly use up the capacity and return to an equilibrium. This was either not immediately obvious or was very hard to express for many of those involved.
Lessons in Supply and Demand
Many transport professionals will recognise the themes discussed above from other forms of modelling, notably highway models. Both the difficulties with data, and the trade-off of supply and demand are something we face everyday. And yet in modern highway and multi-modal models, we frequently go to great pains to add in detail, and validate our models BEFORE we are able to draw broad conclusions.
I would argue that this often hinders rather than helps us in communicating key lessons. To provide both good value modelling, and timely advice, we mustn't let overcomplex modelling get in the way of key messages.
Project Engineer, Highway Network Analysis at Norfolk County Council: Environment, Transport and Development
3 年Thinking of highway models, I was on the A14 Huntingdon Bypass Friday last week and the westbound traffic was very slow moving mid afternoon from Cambridge to Kettering. I thought it couldn't be the forecast traffic demand had already been reached.
Sarn Deva
3 年Aha, the importance of knowing the right question!
Head of Rail Strategy and Planning at WSP in the UK
3 年I absolutely agree. It's always a question of the right tool for the job. I like to think sometimes you can get more insight from a really simple model - if you can get ten, or fifty, results in an hour then you can get an understanding of a system in a way which just isn't possible in a model which takes hours or days to run ...but I'd also be the first to say you likely still need the more powerful model to prove the validity of the approximation.
Rail Operations Consultant and Managing Director at Rail Aspects Limited
3 年Nice article, Tim. MOIRA2 shows what happens when one takes a simple model and tries to do too much clever stuff with it!
Head of Appraisal and Model Development at Transport Scotland
3 年I would presume that complexity is related to how many different questions we want our models to answer and I suspect that relationship is exponential as every new dimension adds another feedback loop. Is the real problem more about how do we keep the number of questions to be answered as few as possible rather than whether our models are too complex?