Transport for London Andy Emmonds GraphSummit 2022

1. 1
London’s – Operations Digital Twin
Andy Emmonds – Transport for London - July 2022

2. 2
Operations Digital Twin - The Presentation
Digital Twin
• Definition and a simple model of complexity
Context of London Road Space
• Business requirements – New paradigm
• Proof of Concept – ULEX zone – October 25, 2021 – Demo
Components and Critical Factors for Success
• The five layers of the Operations Digital Twin
Applications and Next Steps
Thoughts on What it takes to Deliver a Successful Digital Twin

3. 3
What is Digital Twin - Definition
A digital twin can be defined as an integrated simulation of a
real-life system that uses models, sensor information and
input data to mirror, predict and control the activities and
performance of its corresponding physical twin.
Kraft, E. M. (2016).
Two essential elements stand out:
1. There is a connection between the physical model and the corresponding virtual model and
2. this connection is established by generating real-time data (e.g., through using sensors).

4. 4
A Simple Model of Digital Twin Complexity
1 = Simple 5= Advanced
A basic model of a map.
Click to add text
.
Some capacity for feedback
and control,
Provide some predictive
maintenance, analytics and
insights
Capacity to learn efficiently &
automated recommendations
Ability to autonomously
reason & replace humans
Click to add text
Autonomy - The autonomy
of a system
Intelligence - Can it replicate
human cognitive processes
and perform tasks.
Learning
The ability of the system to
learn from data
Fidelity - The level of detail:
• No of parameters,
• Synchronisation frequency
• Accuracy

5. 5
Context for the Operations
Digital Twin

6. 6
Context
for Digital
Twin Data
London Road Network – Challenges
Factors that
make it
difficult to
deliver
effective
intelligence
Data Network Attributes
Open network with little
control over demand
Heterogenous road
layout especially London
Dynamic changes in
network design and layout
Don’t know how to
measure demand and
capacity effectively
Poor quality data
Poor spatial and temporal
coverage
Lack of Cycle, Ped and
freight data
Poor innovation in
sensors and new data
§Understand network
outcomes but not what
influences them
Network Properties
Stochastic properties
of traffic because they
are driven by driver
behaviour
Exhibit “Emergent
behaviour” and the
same values for many
measures can be
arrived at for different
traffic assignment
configurations on the
network

7. 7
Disparate Data Sets
Explain outcomes
Real Time Data
Cars to Multi Modal
Lack of sensors
Changing objectives
Trips and Routing
One version of the truth
What caused the problem?
Operational responsiveness
Multiple objectives, safety, AQ, etc.
Constant improvement data quality
Flex priorities by location and time of day
How did our customers respond?
Why Build a Digital Twin for the London Road Network?
Business Needs
Business Challenge
Framework to Align Data
Lots of Meta-data
Graph Database
Agile & Adaptive Response
Scalability & Data Fusion
Low Granular Data
Graph Database
How to Respond?

8. 8
Normal Paradigm Alternative Paradigm
• Adapt a current business data architecture
• Build a bespoke application to answer a set of very
specific requirement/s
• Scope creep leads to over engineering
Ends in Redundancy
What if we turn this on its head and built a model
that could:
• Answer 90% of all business cases
• Respond to changes in business needs
• Can answer a range of complex problems
• Scale and adapt to new data sources and London
road contexts
This thought process led to the
Operations Digital Twin
New Technologies and Capabilities allows us to rethink
this:
Cloud Services / Graph Data Bases / Open-Source
software, e.g., R / Data Science skills

9. 9
UTC
(V19c P2)
CCTV
ASTRID
SCOOT
(MMX 6.1-2)
SFM
Playbook
TIMS
Current Future
TfL ITS
Systems
Overview
Digital
Twin

10. 10
Digital Twin Proof
of Concept
Introduction of
ULEX – 25th
October 2021
Detected 5
Incidents unseen
by the Traffic
Control Centre

12. 12
Process
Business requirements were assessed across the full
customer base, Network Management, TDM, City Planning,
sponsorship etc.
Data
components
Example
outcomes
Each requirement is broken down to its lowest granularity in
space and time. Focusing on key roads dimensions such as
JT's, flows, OD's, trips & Metadata
Tactical level
vehicle
emissions
Delta – speeds
Mode share
Demand & JTs
AIR QUALITY
Different data brought together in a Common Framework same space and time
Road Safety both
Links and Junctions
Prioritise PT
Bus JTs
Peds crossing at junctions
Mode demand link
Modal speeds by link
Bus demand & JT
GT demand & JT
Roadworks etc
ROAD SAFETY BUS PRIORITY
1. Digital
Twin Data

13. 13
INRIX
General
Traffic JT’s
SCOOT
Flows
Bus
Journey
Times
Roadworks
TIMS
Incidents
Current Future
Digital
Twin
Data ANPR / Digital
Camera flows
Waze/Horus
Incidents
Freight
Telematic
Data
OD Trip
data
RTO Signal
Data
Real Time:
On 60,000 links at 5-minute level – TLRN, BPRN and all
the routes buses travel on - Not residential roads
30+ billion rows = Big Data
Historic:
Real Time:
Aspiration to be fully multi modal
1. Digital
Twin Data

14. 14
• Aggregated main strategic roads only
• Split by Major junction; Traffic control points; Road characteristics; Directionality
• Process creation from OS Highways to CORN fully automated in FME renewed
every 6 months
Rules/Principles
Common Operational Road Network - CORN
An operational common road geography which will align road network control and reporting
60,000 inks for London including Boroughs 1:7 decrease on OS Highways, avg 200 m
• Computationally efficient
• Common geography for whole business to use
• Appropriate scale for operational reporting and road network control
2. Framework

15. 15
CORN
Analysis
Decision
Support
Predictive
analysis
Input
Data
Aligned Layer Output Function Business Use
Alignment of Data and Analytics in Space and Time
Incident
identification
Visuals
Traffic
Management
Modelling
Analysis
Business
Cases
Big Data
Sets
Assets
Works –
planned
events
Traffic
management
Inputs
include all
Meta Data
Such as
Road
attributes;
Operating
Parameters
2. Framework

16. 16
.
• A Database of nodes, properties and relationships. The power behind Google, Twitter, etc.....
• Nodes are mapped to a framework of 60,000 London road links
• Node relationships are directional and allow millisecond calculations in real time
• All data is aligned spatially and temporally in real time
• It allows cause effect relationships to be established
3. Graph
Database
Technology
Model the Road Network
• Include all contextual Metadata
• Map key relationships between
entities by link, junction and direction

17. 17
Using the CORN, our directed road network, and the mirroring of our key
live road metrics we can then use the power of the graph to find and
measure disruption.
• CLUSTERING - Find clusters of connected roads where each segment’s
metrics are worthy of attention.
• CENTRALITY – Within each cluster find the least connected nodes to
get the outermost points.
• ROUTING – Within each cluster, calculate all possible routes between
the outermost points….
Then we can provide a real-time estimate on the impact the average road
user would experience in delay on any of those routes.
3. Graph
Database Ana
lytics
The primary business case for the development of the
digital twin is the detection of incidents

18. 18
Representing Reality in Real Time on London’s Roads
4. Visual Layer
• Cognitive Efficiency
• CORN Link design
• Keep it Simple – Toggle data layers
• Scaling, colours and line widths
• Focus on outcomes then causal factors
• Representing Reality in Real Time
• Partition data by meaningful thresholds
• Slow data sufficiently so it reflects reality
• Provide controls for operator to change
thresholds
• Enable data labels for context

19. 19
Visualisation of our data allows us to make better
decisions in the future.
e.g., COVID impact on traffic flows in London
4. Visual Layer

20. 20
A Modular Design allows for Partitioning of the Workload
5. Plug and Play
Situational Awareness
Air Quality / Emissions 3 D – Operations LIVE
Planning and Context

21. 21
Operations Live – 3D – real time in London - DEMO
5. Plug and Play

22. 22
Operations Digital Twin – Next Steps
Incident Detection Module
• Utilise Graph technology across different data sets to provide real time alerts
Decision Support System in the London Network Management Control Centre
• Expand the use of Graph technology to understand assignment across the network
Operations Live – 3 D – real time in London
• With the modelling team develop the module to be used for virtual 3D Planning and Stakeholder
Management

23. 23
Operations Digital Twin – Thoughts 1
Stick to the principle that the Business only wants one version of the truth
Be clear in understanding the path between your data and the delivery of key business insights
Be clear on purpose and objectives:- Don’t over-reach what a Digital Twin can deliver
A Digital Twin needs context:- Invest heavily in your Metadata and align via a Framework with your Graph
Database
Think through what the Graph Database can deliver by utilising its functionality. Leverage that functionality via
your Meta-data. It adds massive value to what you can do with your data
Think through how a modular design ( 5 layers in our DT) can by judicious re-combination and aggregation of your
data provide for multiple outcomes. Ultimately it simplifies your architecture and allows you to achieve much more

24. 24
Operations Digital Twin – Thoughts 2
Success needs strategic alignment of different layers
Business Requirements and Data – Break problems into their data components
and think about how you can reassemble them to answer many different questions
The Business Framework – Aligns data into same geography and time and allows you to leverage metadata. But
you must invest time and energy into your businesses metadata
The Graph Database – strategic alignment with your framework allows you deliver in real time but also to
multiply to your advantage the algorithms in the graph database, e.g., Clustering and Routing
Visualisation Layer – Achieve cognitive and computational efficiency. Make it usable by humans
Plug and Play – A modular design partitons the workload. Think about the digital, framework and graph
database componets as your real time provisoning layer of contextual data - let different modules take the strain
of processing specific algorithms to provide business intelligence