The User Experience of F1 Telemetry

Despite the glowing brakes, you can't tell much about an F1 car's performance by just looking at it.

Formula One fans know that competing at auto racing’s highest level is as much an act of technological bravado as it is one of sport, and F1 teams are undoubtedly the sporting world’s must gluttonous consumers of information and statistics. Telemetry refers to the automatic measurement and transmission of data by wire, radio, or other means from a remote source – in this case, an F1 racing car moving at speeds up to 250mph. Massive amounts of data are involved. For example, 150,000 measurements are made by the Williams F1 BMW FW26’s on-board computer from almost 200 separate sensors on the car during a typical test run. All of this is shipped back to the pit lanes via live radio transmission or downloaded from the car’s on-board computer, and is then sent to engineers back home in the UK control room in Woking on dedicated pipes of fiber optics. (There is a good reason F1 teams seek out sponsorships from telecoms companies such as Vodaphone.) During actual races, around 25 key functions are actively monitored, with about 1MB of data per second sent back from the car. Some stats won’t surprise you since you can monitor them on your own vehicle’s dashboard, such as engine revs, water and oil temperatures, ground speed and fuel. However, you are unlikely to have a team of analysts scrutinizing the exact moment of your gear changes, your tire temperature, or your braking efforts. What do the interfaces look like that these engineers are using?

Photo of McLaren's Data Operations Center from a June 24,2010 NYTimes article.

The data from the car’s engine control unit (ECU) and a panoply of other sensors is dense and multivariate. This being sport, those that need to interpret the data need to do so in real-time, as a quick decision may affect the outcome of the race. The display configurations need to be highly flexible and personal, and show powerful relationships through visualizations. McLaren engineers are so good at interpreting data like this in order to understand complex systems that they have been involved in modeling air-traffic and taxi-ways at Heathrow, the world’s busiest airport, as well as streamlining emergency room traffic at a London hospital. What sorts of fancy software do they use? For the most part, the race engineers use MS Excel, which is hooked via ODBC to a special real-time relational database served directly from the pit lanes. (To be exact, they use a special racing-oriented client built on top of Excel, typically one of two variants provided from McLaren Electronic Systems. One is called ATLAS, the other is called System Monitor. Both clients work with a special pair of servers connected to an advanced data acquisition system. All teams use the same basic telemetry rig during the race as part of F1 regulations since 2008, but are free to use what they want during testing.)

ATLAS breaks out the various measures from the data acquisition system into three generic categories:

Engine: Revs per minute, fuel and oil pressure, water, oil, and exhaust temperatures, battery voltage, inlet air temperatures, and throttle position sensor.
Chassis: Wheel speed, steering angle, braking and cornering g-forces, damper movement, brake pressure and temperature, suspension loads, tire pressure and temperature, and various air flow and air pressure measures around key points of the car.
Driver: basically anything controlled by the driver, such as throttle, gear, steering angle, and brake pressure.

The sensors basically measure “anything and everything that moves or gets warm,” according to Sir Frank Williams in a recent NYTimes article on the subject. Movement is measured through instruments such as dynamometers and air flow sensors. Heat is measured with non-contact infra-red imaging (via thermal imaging, or thermography) and direct contact thermometers. The data from each sensor is split off as a separate “channel”, which the engineers can configure in their ATLAS client software. When an engineer is configuring their display, they have a choice of display options for any given data-stream. A single channel or combination of overlaid channels can be chosen for each tile in the monitoring interface. Time-series plots, waveforms, scatterplots, and histograms are popular choices to visualize the datastreams themselves. 3d wireframe maps of the car and 2d maps of the circuit are common display backgrounds to data-map against. Often two or more channels are overlaid – such as the delta time between laps over braking pressure – in order to tell a story with the data. In order to do this, disparate measures must share a common scale – such as % based on pre-programmed thresholds. This leads to a climate where each screen is set up to that users’ preference – not unlike the market data terminals configured for financial traders.

Example of a waveform visualization on an F1 datastream in the Atlas client.

Example of a waveform visualization using a datastream from an F1 car. The software is Atlas, which is based on MS Excel connected to a real-time database via ODBC.

Race engineers are basically focused on two areas: 1) monitoring anything that can cause the car to break down, such as gearbox and various hydraulic temperatures, and 2) looking at areas that can be tuned during the race, such as the car’s differential (which allows the two rear wheels to spin at different rates and is crucial for things like corner entry and exit). This year in F1 the regulations allow telemetry to be only one way -meaning that engineers can no longer radio changes directly to the car – but they use the information coming from the car to communicate strategy to the driver and make any changes they can in the pit lanes. Drivers use the telemetry data to study their own input, such as braking, steering trajectories, and throttle. You will see drivers looking at “traces” in the pit lanes to help monitor and improve their performance.

Example of the telemetry "traces" of driver inputs such as steering, braking, and throttle. source: James Allen on F1

You will see, in any bank of monitors focused on telemetry data, that about half of the screens have a black background and half of them have a white background. The black background displays tend to be time-series plots where the most important information to follow are the wavy lines – which are often high resolution, very subtly distinguished in terms of color, and closely packed to one another. The black background provides excellent contrast against colors with high luminosity, such as yellow, or the alerting colors of green and red. White background displays tend to be used for numeric data that is viewed in grid form, providing a quieter environment of increased scannability and readability. There are no hard and fast rules here, however. Partly the black backgrounds are cultural – a holdover from days when serious looking interfaces were called “terminals” and had a look and feel to match.

Telemetry traces of a single lap at Silverstone, shown as a histogram from logged data.

Telemetry traces from a single lap at Silverstone, displayed as a time-series plot from logged data. Laps are marked with the thin purple lines (that extend above and below the grid lines.) Note how, as with many time-series data visualizations, the mere passage of time is not a good explanatory variable. Things look very similar from the "10,000 foot view."

Zooming in on turn 1 at Silverstone ("Copse Corner".) The Blue line is the throttle, the white line is the engine RPM, and the yellow line is the road speed. You'll notice that road speed and throttle are tightly correlated. This is because F1 cars have very low inertia (they slow down rapidly when not accelerating).

A real-time car monitoring interface is set up to warn the race engineer about key reliability indicators. Green and red warning lights are used to create awareness of when conditions are within a safety threshold, and supporting data is nearby for troubleshooting. Notice how some of the telemetry channels are grouped in buckets corresponding to the warning lights, but that they are spatially discontiguous. Other channels do not correspond to the warning lights and are themed separately, such as "car status." The telemetry interfaces are, as a rule, highly personalized.

F1 engines are different from road car engines in a few notable ways, one of them being increased TE (thermal efficiency). Of the fuel energy that is initially put into a cylinder, only about 1/3 emerges as horsepower in any engine – but an F1 car optimizes this by at least 30% using minutely controlled ignition timing, fuel flow to the cylinders, air flow, and via advanced materials in the engine’s construction. All of this is accomplished through careful monitoring of the data in accordance with each team’s performance model. F1 engines also rev outrageously high compared to an engine on a road car, or even other racing cars – up to 18K RPMs. This generates an incredible amount of mechanical wear, which is another reason why F1 engines are carefully monitored during their short life spans (about 400km!). Some parts, such as valves, need to be very lightweight to handle such rapid and repetitive movement. This can create complex engine designs where software is needed to deal with the fragility. But while all F1 teams use the same information from the same ECU now, the exact data used to tune the engine varies and is a key part of race engineering strategy.

It's hard to snoop on a real F1 team's telemetry strategy due to the competitive nature of the sport, but enthusiasts can use the rFactor simulation software to supposedly get close to the real thing. Here's a fictional look at various engine temperature parameters and how they respond to subtle changes to factors such as air intake, etc.

Some Formula One teams now provide the telemetry data from the car to the public, and an interesting sub-culture of mash-ups and experimental visualizations has emerged.

A Driver DNA chart for Lewis Hamilton - not based on his biology, of course, but his driving habits such as throttle and braking. This is an example of the sort of experimental visualizations that are now popping up since McLaren has made their telemetry stats public. Source: OUseful.info

Solid State UX