Digital twin

Scenario comparison

Ten preset scenarios across cars, EVs, vans and motorcycles, each showing the selected profile and the reasoning layers.

Simulated real-world data being used for demonstration purposes

Scenarios

AB12 CDE

2024 Example EV Crossover

Front target

39PSI

Rear target

43PSI

Load profileHEAVY

Load index6.70

Temp allowance0 PSI

JourneyLong journey

Layer 1 - manufacturer profile matched for 2024 Example EV Crossover (Dual Motor).

Layer 2 - wheel/tyre specification 235/50 R19 103W.

Layer 3 - approved heavy load profile selected (load index 6.70).

Layer 4 - tyres cold (17°C): readings comparable with cold specification.

Layer 5 - AiR safety rules: targets clamped inside the manufacturer envelope; no independent override.

Evidence base

Why these scenarios and not others

Each twin scenario isolates a variable that the literature identifies as first-order: axle load, temperature, tyre size, duty cycle and vehicle mass.

Load transfer scenarios

Approved tables change pressure with axle load, and rear pressures typically rise first as occupancy and luggage are added.^2025,1981

Temperature scenarios

Gas-law behaviour on absolute pressure gives the measurement offset between a warm and a cold tyre.²⁰⁰⁶

Heavy-vehicle and EV scenarios

Higher mass and higher tyre load utilisation increase the energy dissipated in the contact patch, which is what abrasion tracks.^2008,2020

Handling scenarios

Cornering stiffness and relaxation length move with pressure, so an under-inflated axle changes the vehicle's response, not just its wear.^2012,2008

Cited on this page

European Tyre and Rim Technical Organisation (2025). ETRTO Standards Manual - load capacity and inflation pressure tables. ETRTO, Brussels, annual edition.
Gent, A. N. and Walter, J. D. (eds.) (2006). The Pneumatic Tire. US National Highway Traffic Safety Administration, DOT HS 810 561.
Pacejka, H. B. (2012). Tire and Vehicle Dynamics (3rd edition). Butterworth-Heinemann / Elsevier.
Grosch, K. A. (2008). Rubber Abrasion and Tire Wear. Rubber Chemistry and Technology, 81(3), 470-505.

These are published third-party sources, not AiR simulation. The full bibliography - peer-reviewed papers, reference monographs, government reports, international standards and official statistics - lives in the science lab.

Open the research and full bibliography

Edge session, synchronised

The same edge-compute session drives the twin

Scenario comparison and the edge workload simulator share one persisted session, so the federated-learning and data-flow behaviour shown here is exactly what the simulator is currently modelling.

F1 · Jetson Orin NXFull cloud-connectedMains, nominal thermals1,000 nodes62% host share cap45% duty cycle

Available per node

157TOPS

157 TOPS peak, power derated

Safety reservation

43.9TOPS

Never pre-empted

Shared compute

97.3TOPS

62% of the node

Fleet useful capacity

141,200TOPS

0.0455% of the 100 MW reference

Scheduler allocation

Tyre-safety control looprunning18.9 TOPS

On-unit local intelligencerunning25 TOPS

Federated fine-tuningrunning40.8 TOPS

Scheduled tenant inferencerunning56.5 TOPS

Federated round in this session

Participating nodes947

Queued for later delivery53

Aggregate delta volume246.2 MB

Round duration6.1 min

Rounds per day59

Fleet compute draw36 kW

A host share above 60 percent should be contracted with an explicit thermal, power and privacy schedule.

Federated learning behaviour

Local trainingFine-tuning runs on data that never leaves the node or its regional trust boundary.

Update extractionOnly model updates or anonymised aggregates are transmitted, never raw vehicle or user records.

Secure aggregationRegional anchors aggregate updates so the control plane cannot attribute an update to one node.

Differential privacyNoise is added where a research use case justifies it, at the cost of some model fidelity.

National reconstructionThe central model is reconstructed from aggregates and redistributed as a signed package.

Tenant isolationExternal compute tenants run in separate namespaces with no route to vehicle, driver or safety data.

Data flow, stage by stage

01
Sense · Node, L0
Pressure, temperature, valve state and session context captured at the channel. Raw sensor data never leaves the enclosure in raw form.
02
Decide locally · Node, L1
The deterministic engine selects an approved profile, applies the thermal allowance and safety clamp, and drives the channels. No network dependency exists at this stage.
03
Infer and redact · Node, L2
Onboard inference runs anomaly, leak-pattern and integrity checks, then the redaction pipeline strips identifiers and derives features before anything is queued for transport.
04
Sign and classify · Node, L2
The session record is signed with the device key and each outbound message is tagged P0 to P4, which fixes its transport, priority and residency for the rest of its life.
05
Transport by class · L3
P0 and P1 take whichever path is available, LoRa included. P2 to P4 wait for IP. Bulk traffic is deferred to off-peak windows and never touches the resilience plane.
06
Broker regionally · Anchor, L4
Anchors cache models, broker compute work units, forward Reticulum traffic and hold store-and-forward queues for nodes that are currently unreachable.
07
Reconcile centrally · Control plane, L5
Signed sequence numbers and idempotent processing mean queued events replay safely when IP returns. Duplicate delivery over two planes is expected and harmless.
08
Aggregate and serve · L6
Personal records land in the UK sovereign service, anonymised trends in the analytics plane, tenant outputs in an isolated namespace. The three are never joined.

Adjust this session in the edge workload simulator

One engine, many scenarios

The same deterministic model drives every surface in the platform.

/Ten scenarios/Side-by-side logic/Load index/Temperature allowance/Approved envelope/Per-axle targets/Ten scenarios/Side-by-side logic/Load index/Temperature allowance/Approved envelope/Per-axle targets

Digital twin

The same engine, run against every awkward case

The twin exists so the pressure logic can be interrogated rather than trusted. Change the vehicle, the load or the weather and watch the target, the reasoning and the safety clamp move together.

Scenarios modelled

Inputs per recommendation

Vehicle, occupants, cargo, journey, warm state, ambient, tyre temperature.

Deterministic replays

Seeded simulation, identical output for identical input.

Targets outside the approved envelope

Every recommendation begins with the manufacturer table for that vehicle and tyre size. A load index is derived from occupancy and cargo, which selects the light, normal or laden column - never an invented value between them.

A temperature allowance is then applied to the measurement, not to the specification, so a warm tyre is not accidentally left under-inflated once it cools.

Load index maps continuous inputs onto discrete approved columns
Journey type biases towards the laden column for sustained motorway running
Rear axle moves first on most passenger profiles as weight transfers rearwards
The final target is clamped to the approved minimum and maximum

Questions

Straight answers

In this demonstration they are representative values held in the simulation engine. In production they would come from a licensed manufacturer data feed with a versioned audit trail.

TPMS warns when a tyre is already dangerously low, typically 25 percent below specification. It does not tell the driver the correct pressure for today's load, and it cannot correct anything.

No. It is seeded, so the same scenario always produces the same starting pressures, faults and results - which is what makes the twin useful for review.