Simulation - What to look for

The field of Pedestrian Simulation is not well understood and the expertise lies in the hands of a few people, organisations, scientific bodies and academic institutions.

For example, the process of calibration has been consistently confused with fitting to a situation.  Calibration should be an independent process from any project and should not be linked to a validation process in order to maintain validity.

Legion, together with its scientific partner, the Maia Institute (, have been leading pioneers in this field.  The value of predictive simulation is enormous, but the value of non predictive animations are limited.  It is vital, therefore, to understand the difference and the easy signs and tests to look for in order to make these distinctions.

In an attempt to de-mistify and make simulation assessment more accessible, here are a list of quick tests / things to look for:

General Model Questions / Hurdles:

  • Make sure that any model is based on real crowd data measurements captured in a scientific way.

  • Find out how the model has been calibrated and then independently validated. 

  • Does the model use a Grid System?  If so, it cannot be predictive (see "Evaluation of Grid based models.pdf").

  • What outputs are available.  The fewer the outputs, the greater the likelihood that the simulation is not predictive.  If the software allows the user to investigate simulation results in great detail, it can show irregularities and incorrect results.

  • Examine the outputs carefully.  Do people ever "walk through each other"?  If so, results cannot be trusted.

  • Does it work in CAD?  If not, it is unlikely to be using exact measurements.  Therefore, outputs are likely to be  eroneous.

  • Validation:  How has this been done?  Has the software been through an independent test?  Ask for validation evidence. 

Necessary Functionality:

Aside from its validity as a predictive tool, Pedestrian Simulation Software also must be able to deal with all situations and events that occur regularly in pedestrian environments.  The following are some of the basic functionality requirements that any software should have

  • Ability to model multi levels easily and seamlessly
  • Ability to model Fare/entry gates, stairs & escalators, lifts/elevators, platforms, ramps, purchase points, etc.
  • Full queuing functionality to represent different queue types.  Remember - queuing behaviour is different from walking.
  • Ability to handle events of any kind, including multiple destinations, change of goals, announcements, etc.

Some detailed specifications are available for download.  These specifications have been released by public agencies as RFPs over the course of the last few years.