top of page
divebomb.co

Formula 1 and AWS: How it works

Over the last couple of years, Formula 1 – together with Liberty Media, the owners of the sport since 2017 – has put a lot of focus onto giving viewers a greater amount of insight into both the on- and off-track action.

Written by: Oskar Yigen, Edited by: Justin Tan and Daniel Yi

First of all, F1’s different social media platforms are much more active than they were only 2-3 years ago. Secondly, live television coverage of the races is now more sophisticated, professional, and detailed, whilst at the same time being relatively easily understandable for new and/or casual fans. This is of course not to mention the cooperation with Netflix in creating the annual Drive To Survive series, which gives insight into the inner workings of F1.

However, something has also been done to keep the hardcore fans entertained – and by hardcore fans, I mean the ones who read articles such as these, watch every single session of an F1 weekend, follow feeder series like Formula 2 and 3, and know everything noteworthy about the sport they love. Whilst these fans are certainly not the majority, they are very important, something which rightly has been recognised by FOM (Formula One Management) and Liberty Media, despite the two’s primary focus over the last few years having been making F1 as accessible as possible.

The main initiative to treat the hardcore fanbase has been that of implementing Amazon Web Services, abbreviated “AWS”, into the live broadcast of races – and to some extent practice and qualifying sessions – since 2019.

According to Amazon’s website, AWS in F1 is used to ‘’extract critical race performance statistics, make race predictions, and give fans insight into the split-second decisions and strategies adopted by teams and drivers’’. An example of this is the pit stop battle function, which predicts where any given driver will appear on the track in accordance to another driver – for instance, to show whether or not an undercut attempt will be successful.

However, the one function that AWS has gained most of its publicity for is undoubtedly the tyre performance graphic, which illustrates how much life a given driver has left in his tyres. The publicity isn’t exactly positive though, as this particular graphic more often than not turns out to be painfully wrong in its assessment of tyre performance – leading to tons of memes, critical tweets and all things alike on a race-by-race basis.

Another function that has been introduced over the last season is the car performance graphic. Rating any given teams’ performance in certain parts of the track, it compares the different cars’ performance, scoring them out of 10 in low-speed corners, medium-speed corners, high-speed corners and straights respectively. This function has received a fair amount of critique as well though, most fans finding certain aspects of it puzzling. For example, it often happens that the best car in one of the four categories doesn’t score 10/10 – which doesn’t make much sense, considering that this car should be the benchmark in that exact type of corner or straight.

As you can see, AWS is a somewhat flawed concept. But whilst the idea in itself is good enough, many spectators have raised questions as to where it gets the data that it bases its assessments, predictions and illustrations off, since the graphics are so often wildly incorrect. So how does AWS truely work? How much and what data does it have available? Which tools does it use? And why does it end up being wrong so often? Let’s find out.

First of all, AWS is not designed specifically for F1, nor is it only used there. AWS is an extremely broad term, which covers a multitude of features and services within those features. Ranging from providing computing power, databases, networking, and content storage, to offering features as data analytics and machine learning, it’s used by small start-up businesses, as well as large companies, all being able to choose a package that fits their exact needs. And since AWS has such a wide spectre of tools and features, we’re going to put our focus towards the ones F1 makes use of.

Data transfer and preparation

Every time a Formula 1 car is on track, sensors placed all over it transmits telemetry live back to its team. According to AWS’ website, 120 sensors on each car generate 3 GB of data, and 1,500 data points are generated every second. Before the introduction of AWS, spectators didn’t have much insight into this data. However, since the start of the 2018 season, all this data has been sent from the racetrack to Formula One Management’s headquarters in Biggin Hill, Great Britain, where F1’s data center is located. There, the data is received and extracted using Amazon API gateway. Following Amazon’s own description, it’s ‘’a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the ‘front door’ for applications to access data, business logic, or functionality from your backend services’’.

After being received by the API, the data from the cars and the timing data is synchronized using AWS Lambda, which is a tool that handles all management, processing, scaling and patching of any input it receives, in this case F1 data. Essentially, it works as an easier alternative to having multiple servers which are manually set up handling inputs, as these servers require high maintenance and often don’t meet the capacity criteria that a given program has.

From Lambda, the data is transferred across to Amazon DynamoDB, a tool which basically scales the entire system’s performance capacity up or down, depending on the requirements of the specific data being fed to it at any given moment – thus making sure that the system isn’t either overworked or ‘’underworked’’ (having too much spare capacity). In other words, it does much of the same work as Lambda, but is more focused on system performance scaling.

Another AWS tool used by F1 is Amazon S3, which is ‘’an object storage service that offers industry-leading scalability, data availability, security, and performance’’. Or in basic terms, it’s a service that stores data. This is where non-live data (ie. historic data or data from earlier parts of the ongoing race) is stored. All data that goes through the system is stored in S3, making it available for future graphics and illustrations.

Creating the graphics

And it’s at this point where we get to the tool that’s responsible for creating the actual graphics. But before we get into that, you need to know what Machine Learning is, as that’s what this tool does.

Machine Learning, or just ML, is the study of computers that learn to recognize patterns or make predictions based on data that they’ve been given. A simple example of this would be when you’re searching for images on google. Let’s say you search for ‘’red phone’’. You click on the ‘images’ tab, and countless pictures of red phones appear on your screen. A human might not place much significance to this, as for us it’s extremely easy to differentiate between pictures that feature a red phone, and pictures that don’t. However, if you think about it – how is a computer able to tell whether or not a picture features a red phone? Well, just like humans, they have to be taught. This is – quite simply – done by giving the computer a set of pictures, some that feature a red phone, some that don’t, and then tell the computer which is which. From this, the computer will be able to find key traits of the pictures which feature a red phone, and from then on it will be able to make the distinction between pictures containing red phones and the ones that don’t.

Similarly, computers can be taught to detect certain patterns in data and from there make predictions based on that data existing historical data. This is also known as ‘’Predictive Analytics’’. To visualize this, let us use an example from F1; often you’ll hear commentators talking about how hard or easy an overtake on a given track will be (AWS also produces a graphic which does exactly that). If you’ve watched F1 for long enough yourself, you’ll probably know by instinct how hard an overtake is going to be. And why is that? Because, from experience, you know that a driver on soft tyres will have an easy time overtaking a driver on hards, and you know that at a circuit like the Baku street circuit, overtaking is easy and doesn’t require too much of a pace advantage, whilst at circuits like the Hungaroring it requires quite a significant pace advantage. Instead of memorizing it like humans, computers can – with the help of certain tools – make those predictions based on machine learning models created using historical data.

So, now to the tool which F1’s insight uses: Amazon SageMaker, created specifically for Machine Learning. In F1’s case it contains a couple of models; one for the pit stop battle function (explained previously in this article), one for the on-track battle function (which predicts when on-track battles will occur between two cars, and how difficult making an overtake will be in the given situation), one for the car performance scores graphic, and one for the tyre performance graphic, which we’ll get back into in a minute. Using the data that it’s being fed from Lambda and S3 (DynamoDB doesn’t actually transfer data directly to SageMaker itself, instead it sends the data back to Lambda which then transfers it to SageMaker), SageMaker then produces these three graphics which the production team can then choose to show on the live broadcast if they find it useful.

The team in charge of AWS in F1 won’t give any information about how the models behind the two graphics specifically work, but we can make some assumptions as to what data they use; the pit stop battle function is likely based on the average time lost during pit stops at the given track, the two cars in questions’ current pace, and historical data showing how powerful either the under- or overcut is at the given circuit. The on-track battle function is probably also based on the two cars’ current pace, as well as historical data of how difficult following other cars and overtaking is at the given track.

The tyre performance graphic

Out of the four main graphics that AWS produces for F1, the pit stop battle, on-track battle, and car performance scores graphic work relatively well, producing largely accurate predictions – with a few slip-ups here and there. However, the final graphic – the tyre performance graphic – well, let’s just say it hasn’t worked out quite so nicely. Actually, it has worked out pretty terribly.

The purpose of the tyre performance graphic is to give viewers insight into how much performance – and contrary to popular belief, not wear, a drives’ tyres have lost at any given point during a race. Each of the four tyres are assigned their own percentage; 100% means that the tyre is completely fresh and still has everything to give, whereas 0% means that the tyre is at the end of its effective performance range. This is where we encounter problems. What is the definition of ‘’the end of its effective performance range’’? Is it when the tyre is so worn that it is in danger of puncturing? Probably not, since F1 have made it very clear that the graphic portrays performance, not wear. So what is the answer? Well, we don’t know. No information about this has been released by F1 anywhere. And it’s not just spectators who are unimpressed with the graphic; Pirelli, Formula One’s tyre supplier, says that it’s ‘’misleading’’, and that ‘’stressing the number of variables means it is impossible to make such predictions’’. Furthermore, after the graphic’s inaugural use in the 2019 race at Suzuka Circuit, Japan, Pirelli surprisingly revealed that they were not involved in producing the graphic in any shape or form.

So if the company that manufactures the tyres doesn’t deliver it, what data does F1 use to create the graphic? According to a video released by F1 in late 2019, the data points used are: car speed, acceleration, gyro, GPS, lap times, tyre compound, and stint length. And if this is the only data being used, it’s extremely easy to see why the graphic is so often wrong. Granted, it’s all very useful, but there just isn’t enough – not to mention that there doesn’t seem to be any baseline as to what the optimal performance of the tyres are. What I mean by this is that it’s all fine knowing how aggressively a driver accelerates out of the corners, how much speed they’re carrying through them, and – using the gyroscope – how much rotational resistance and thereby load are being put on the tyres, but if there is nothing to compare this data to, you can’t make a proper estimate of the tyres’ performance.

To understand my point better, let’s take a look at an example; let’s say that a driver – during a race – goes through turn 7 at Monza, Lesmo 2, at 180 kph when they hit the apex, which puts his left-hand side tyres (since Lesmo 2 is a right-hand turn) under 1000 kgs of load. They then accelerate out of the corner to a speed of 300 kph in 5 seconds (keep in mind that these numbers are not representative of reality, they’re only supposed to act as an example). AWS supposedly uses these numbers (and more) to make an estimate of how much performance is ‘’taken out of’’ the tyres, and therefore how much is left. But this is where I believe there’s something missing, and it’s probably where the graphic goes wrong. There’s no way to know exactly how much performance going at a given speed takes out of the tyres, and as I said previously, there’s no data to compare this to. This means that even if we have all the data in the world, there would be no way of knowing how much the driver is pushing – and with that, how much of their tyres’ performance they’re using. Why, you might ask? Because that’s a fundamental part of motorsport. We don’t know where the limit is, and we have never known. There is no way for us (at least yet) to know how close the drivers are to using all of their performance potential, hence is there no way to know how much performance is left in their tyres. Besides, there’s no way to know what the reason for a driver going at a certain speed is. They might be managing their tyres, in which case they’d be going slower than if they were pushing. Is this taken account for in the making of the graphic? It certainly doesn’t seem that way.

After doing all this research, it’s in my opinion very clear that the tyre performance graphic simply isn’t good enough to be used in the live coverage yet. It’s frustrating seeing the graphic pop up during a race to tell us that a driver only has 10% performance left in his tyres, only for a radio message to be transmitted 10 seconds later in which the driver says ‘’tyres are fine’’. Clearly there is a missing link somewhere, but from an outsider looking in, it’s very hard to spot, especially considering how little F1 tells us about how the graphic actually works.

In conclusion to everything that I’ve been going through in this article, I believe that the idea behind F1 insight’s graphics has a lot of potential, but it needs to be greatly improved before I’d say it’s ready to go on air, especially the tyre performance graphic. After all, if it doesn’t work properly, it’s only going to be more confusing than helpful. But even if everything was working silky smooth, some might argue that AWS still shouldn’t be a part of F1. That’s a topic which deserves it’s own article though. For now, enough is said in that the models, the data usage, and the thinking behind it needs to be optimized before it should be implemented as one of the main aids to helping the viewers understand a race. However, it seems F1 has taken a different approach, going all in on the still largely unproven graphics, and relying on them for much of the information and insight used to paint the picture of a race. Whether or not that’s the right decision, only time will tell.

Follow DIVEBOMB on all our socials: Instagram TikTok Spotify YouTube Twitter

Comments


bottom of page