The Engineering Awesomeness of F1

... or what software engineers could learn with F1

See that smoke behind the car? Not good...

For a long time, the main requirement for Formula 1 racing was power. Everything in the car but the pilot would last for only one race, if much - very often engines or gearboxes would blow up in the middle of a race. Indeed, within the same Grand Prix (i.e., practice sessions, qualifying and the race itself) different engines could be used.

But, of course, it was not all about engines. Every team updated their cars during the season, changing aerodynamic parts, suspension, breaks, etc. And how did they know whether an update designed for the car was really working? Unlimited testing. Even so I suppose it was still difficult to measure evolution due to environmental conditions (going from track grip and temperature to evolution of the driver himself). Nonetheless, with enough mileage, statistics was a friend.

But then, in the last decade, everything changed. Let's talk about F1 challenges for engineering in 2013.

Only 8 engines can be used by a driver throughout the entire year, which means an average of more than 2 Grand Prix (GP) per engine. Gearboxes must last at least 5 GP. We can say that reliability became a main concern. Refueling is not allowed during races, thus low fuel consumption is a must. Power, of course, is still important. Driveability, which is the engine's response to drivers input (through the throttle pedal), can be changed from race to race. What about space? The smaller the engine, the better the car can be designed around it. Oh, that remembers me of weight, which has big effects on the car's performance. Now, that's a good looking list of non-functional requirements, right? All of this in a very competitive environment where thousandths of a second can make a big difference.

I think it's fair to say that F1 is the place where trade-offs on non-functional requirements are the most visible. This constant trade-off between performance, reliability and packaging in its different measures is present in the design of all elements of the car, including engines, gearboxes, brakes, KERS, and suspension. All of this within strict regulations that define maximum/minimal size and weight of some specific components, and at the same time exploring the breaches in the regulation to create innovative solutions and gain an edge against competition. After design, there is car set-up, changed on every race, seeking for the best compromise of qualifying performance, race pace, tyre consumption, heavy-load pace, light-load pace and pit-stop strategy. Lastly, after the initial design, and in addition to set-up changes, we go back to evolution, in terms of updates to the car.

If in the not-so-old days the teams had unlimited testing, allowing to evaluate their updates, nowadays it is very, very limited. It consists pretty much of a few collective pre-season testing sessions, 4-days each, plus 4 days of straight-line tests for each team. I'm sad for the drivers - after all even in programming, which is far more theoretical than race-driving, it is difficult to improve without practicing. However, from the engineering point of view, this is just awesome. What teams do in order to compensate this lack of on-track testing?

• Computer simulation - Now the teams rely a hell of a lot more on computer models to understand the effect of changes in the car. As aerodynamics are so important for performance, a key factor here is computational fluid dynamics (CFD). But not just that, top teams also develop simulators which probably are the most realistic racing video-games ever made.
  
• Wind tunnels - this is when you build a scale model of your car, take it to a tunnel with a huge fan, and see how the air flows through and around the car. The limitation here is that the scale model has to be at most 60% of the real size, while the maximum speed is 180km/h. Compare that with last Spanish GP, where the maximum speed during qualifying was 318.5 km/h. The more marginal the gains to be obtained, the more important is the precision of the models.
  
  Due to these limitations, the last resort is to evaluate updates during the GP weekend, in the...
• Practice sessions - In a GP weekend, the qualifying session is preceded by 3 free-practice sessions. Usually, 2 sessions of 1.5-hour on Friday, plus a 1-hour session on Saturday. It amounts to 4 hours of on track action, which used to serve to acclimatize drivers to the track and to adjust car set-ups. Now, they also use it to evaluate new parts for the car, specially during the first session. So, the testing is very time-constrained, in a track shared with all the other cars, tyres degrade really fast, and, you know, changing some parts of a car can be time-consuming as well. Oh, and don't forget that rain can ruin the engineers attempt to evaluate updates.

What looks like green paint is used to check air flow

With so many constraints, it's incredible that they are actually able to improve a lot throughout the year. Nonetheless, some top teams eventually faced big problems - in 2012, it was Ferrari; now, 2013, it is McLaren. The guilty is only one: correlation. This is similar to Brian Smith's discussion about computing on models and acting on the real world, which (as he argues) explains why proving correctness of a software does not give us any guarantee that it will behave correctly once it's out there in the real world. So, designers make models and simulations and find out that some changes will make the car behave in a specific way, but when it hits the track, they eventually find out that it's not the case. Then, it doesn't matter what 'virtual' improvements are made, since they will not reflect on actual improvements. When this happens, what is really important is to fix the correlation issue, i.e., to ensure that the model being used corresponds to the real world.

Then, there is the last F1 aspect I'd like to discuss (for now), which is all about Big Data. F1 cars feature hundreds of sensors, which send real time data about the car, from brakes temperatures to lateral acceleration and component failures. This is used during a race, for instance, to identify problems with the car (and possibly fix it), to inform the driver where (and how) he can improve, to decide when to pit-stop, and to estimate target times for each lap. For these last two it is also required to have information about the other cars on track.

Additional sensors behind the left tyre; these are not used in races.

Besides all these challenges, there are the more specific aspects of automotive technologies, such as combustion, energy recovery, materials, and so on. Anyway, summing up just the challenges we discussed, we have:

• Difficult compromises between non-functional requirements, in a very competitive environment, with strict technical regulations;
• Lack of on-track testing forcing the teams to rely on models and simulations;
• Gathering and processing big data in real time.

Pretty awesome, right? I bet we, software engineers, could learn a bit or two with these guys.


Images copyright: Ferrari with blown engine, from http://www.dailymail.co.uk. Mercedes with sensor, from http://www.crash.net. Red Bull with flow viz, from http://www.auto123.com.