Model or Parameterisation? What a Team Really Brings to a Simulator

When a team asks to run “its own model” on a simulator, it is usually talking about two different things at once.

In everyday conversation, “the model” covers everything that makes the simulated car behave like the real one. In engineering terms, it is more precise to separate the model from its parameterisation. The distinction matters, because it determines what a team can bring, what has to be added for driver-in-the-loop simulation, and where correlation work begins.

Two layers, one car

The model is the structure. It defines the topology of the car: how the suspension, steering, powertrain, aerodynamic platform and tyres are represented, and how forces travel between them.

The parameterisation is the set of numerical data that turns that structure into a specific car. Masses and inertias, suspension geometry, spring and damper characteristics, aerodynamic maps, tyre data. Two cars can share the same model and behave nothing alike, because their parameterisations differ.

As Barney Hassell, Head of Vehicle Dynamics, explains:

As far as a customer is concerned, we often refer to the parameterisation as the model. Technically, it is more correct to differentiate the model from the parameterisation.

That precision is not pedantry. It is what allows both sides to agree on what is being delivered, and on what still needs to be done before the car is ready to drive.

What teams usually bring

In practice, what most teams bring is a parameterisation: detailed data on their own car, gathered through design work, rig testing and track running.

For the formula cars we have run so far, we have built the parameterisation ourselves, working from detailed information supplied by the team. In GT3, we have also taken parameterisations prepared by teams and run them in our own standard vehicle model.

In those cases, the team’s starting point was not very different from the one we would have created. The differences lay less in the data itself than in how it was processed, and in the experience needed to estimate the parameters that cannot be measured directly.

What real-time simulation adds

A parameterisation built for offline analysis is not automatically ready for a driver-in-the-loop simulator.

A real-time dynamic model has to compute the state of the car at a fast, fixed rate, step after step, with a driver reacting to everything it produces. That brings requirements a team rarely meets in its usual engineering work: parameters, and sometimes whole subsystem models, that only matter when a human is driving the car in real time.

There are some areas of parameterisation, and subsystem models, that are required specifically by the dynamic real-time model and for driver-in-the-loop simulation. The customer does not normally have experience of these, so we normally need to add them ourselves.

This is where simulator experience counts. Knowing which additional parameters the real-time model needs, and how to estimate them credibly, is what turns a team’s data into a car the driver can trust.

Bringing a complete model

Some programmes go further than a parameterisation and require a specific vehicle model, one the team already uses across its engineering toolchain.

That is also possible. Alongside our standard model, our team has integrated third-party vehicle models at customers’ request. How that integration works in practice is the subject of a separate article by Fabian Bräu, our CTO.

Whether a team brings a parameterisation or a complete model, the principle is the same: its data is the starting point, not something that has to be replaced.

Correlation closes the gap

Whatever the starting point, the next step does not change.

Always, it is then necessary to go through a correlation process, where the parameterisation, and sometimes the model, are fine-tuned.

Correlation compares what the simulated car does with what the real car does on track, and with what the driver reports. Where the two differ, parameters are refined and the loop runs again. Over successive sessions, the simulated car converges towards the real one.

That process is continuous rather than a single milestone, and it applies equally to a model we have built and to one a team has brought.

Why the distinction matters

For a team considering simulation, separating the model from the parameterisation clarifies three things.

First, what to prepare. Detailed data on the car is valuable whatever simulator it ends up running on.

Second, what to expect. A parameterisation is a strong starting point, not a finished simulator car. Real-time requirements and correlation work still lie ahead.

Third, where the value is created. It lies in the combination: the team’s knowledge of its own car, our experience of real-time, driver-in-the-loop simulation, and a correlation process that brings the two together.

Your data is the starting point. Correlation does the rest.

‍