In many road projects, traffic microsimulation remains an offline planning artefact. The model informs a design or operating decision, then gets revisited periodically, if at all. The model may still be sound, but the network it describes might already have moved on.
The useful question about any twin is narrower than model quality. Does the model receive live data, and do its predictions come back into operations? That is what turns simulation into an operational capability.
Live calibration separates digital twin solutions from studies
A model calibrated once at commissioning is a snapshot. Recalibrating it overnight produces a more recent snapshot. Neither helps the operator watching a queue build on screen right now.
In RM-Hub, the simulation twin recalibrates every cycle from traffic counters, radar and incident detection. The same real-time traffic monitoring that populates the operator’s display also parameterises the model behind it, so the display and the model read the network from the same current data.
The difficult part is maintaining that data path between simulation and operations. In many projects, the simulation and the control system arrive through separate scopes, with no operational connection specified between them.
The decisions worth testing before they reach the road
In our implementation, four intervention types illustrate the decision loop: opening the hard shoulder, changing a speed plan, adjusting a ramp metering rate and closing a section. Each is reversible, but each can materially change traffic conditions once applied.
The operator normally sees only the outcome of the chosen option. A live twin can also estimate what the network would do under the alternatives before one of them reaches the road.
The twin returns four predictions per option: average speed, throughput, queue length and clearance time. These remain estimates and inherit the uncertainty of the underlying calibration. Their operational value comes from comparing the options currently on the table against the network state measured now.
That also changes the discussion around digital twin return on investment. Traffic flow optimisation can be evaluated before an intervention is committed, rather than reconstructed only in the review afterwards.
The proposal layer and the control layer have different jobs
In our architecture, automated optimisation sits in the decision-support layer. Safety-critical execution remains in the deterministic control layer and follows the configured authorisation workflow.
The platform can propose a plan and show the predicted effect of each available option. The configured operating workflow determines who may approve or execute it, while the record retains which option was proposed, which was selected and by whom.
We have written previously some articles about why pre-engineered response cases and documented authorisation matter in tunnel control; the same design principle applies here. Once an optimiser is permitted to execute a road intervention directly, its role extends beyond decision support, and the control architecture must govern it accordingly.
For us, the live twin fits into the existing control-room workflow as an additional decision-support layer.
Why digital twin solutions should be inspectable
Our twin runs on Eclipse SUMO, the open-source microscopic traffic simulation suite started in 2001 at the German Aerospace Center’s Institute of Transportation Systems. SUMO became an Eclipse Foundation project in 2017, with the code migration completed and the first Eclipse release in 2018, and is licensed under EPL 2.0 with a secondary GPL-2.0-or-later licence.
Naming the simulation core matters. An open engine gives the authority a clearer route to independent model review, scenario reproduction and inspection of how calibration was performed. It also reduces one source of supplier lock-in when the modelling environment has to change hands.
The systems integrator’s value remains in the network model, calibration, live data path, and operational integration. Opening the simulation core does not remove that engineering work. It makes the underlying engine inspectable.
What we demonstrated on Hungary’s M1 motorway
We built a live digital twin in a proof of concept on Hungary’s M1 motorway. The twin used live field data to maintain its current network state, and we presented intervention comparisons within the operational workflow.
The proof of concept established something narrower and more useful at this stage: the live data path can be built, the simulation can stay connected to the current network state, and intervention comparisons can be brought into the operator workflow before a decision reaches the road.
The question for your own control room
Model quality is where digital twin solutions are usually compared, and calibration quality, data quality and the assumptions behind each prediction all belong in that comparison. Operational usefulness adds another requirement: the model must stay connected to the current network state, and its outputs must reach the people making the next decision.
Offline simulation remains valuable for planning against assumed conditions. A live twin adds the ability to compare the next intervention against the network state now.
Does the model in your organisation stop at the study, or does its output reach the control room?
Lillyneir designs and integrates traffic management platforms for motorway operators and road authorities. RM-Hub combines live network monitoring with a continuously calibrated simulation twin, so you can compare intervention options before committing. To discuss what closing that loop would involve on your network, contact our team.
