To Send or Not To Send
Whether you are a mechanic or an engineer, there will come a time where you are responsible for the car not being ready on time. That is not to say you have not done your job well, but simply the issues that have arisen have not been rectified in the time available to you. This causes issues.
Another emotional weekend at the races has just passed, with several ups and down, mechanical and electrical failures showing up here and there, and a general firefighting approach to get the cars to the grid.
The anecdote I share this week is one that everyone at the sharp end of motorsport will have encountered countless times over their career, and something to be aware of as you start out. That issue is do you send the car to the track before you are happy with it? And it is never black and white.
At Silverstone this week Free Practice one went reasonably well. The cars came back in one piece, time was made up, and the cars were solidly “middle of the pack”. Nothing exceptional, but exceptional is not what is expected after FP1. In the hunt for a little extra time, there were some setup changes required to the electronics on the car. The different ways in which the car communicates to the drivers, and the information that is displayed for him can help to find some extra time on track
The setup changes were completed with about 5 minutes to spare to pitlane open, and should take around 30seconds to upload to the car. So here we go…
Plug in, open the setup, click the “Send” button… the computer freezes.
Cancel that and try again. The computer freezes again.
At this point the data engineer approached me for assistance and I set about work. There are strange demons in the software code (both the data software and the operating system, both of which shall rename unnamed), and these demons cause strange behaviour. Familiar with similar problems from the past, I looked in to security and firewall policies, anti-virus software conflicts, hardware issues, network adaptor settings and a plethora of other usual suspects that were easily and quickly checkable. Nothing worked and the pitlane opened…
So, do you send the car in a less than optimised state, potentially putting the session in to jeopardy? Potentially you risk making the entire session’s performance be off true pace. But on the flip side, this is Free Practice 2; how critical is it really? (If you’ve read the last post, you will be aware that FP2 defines your qualifying setup. So it can be fairly critical to your weekend!)
Making the call to hold up a car during a live session is not something to be taken lightly. This is competitive running time that you are losing out on and therefore you are going to be at a disadvantage to your competitors.
What would you have done?
Ultimately, I decided to send the car without the new setup. My reasons for this are as follows:
The changes in the setup can be compensated for during the post-process data analysis. We can work out the benefit had we been able to send it.
This was only FP2. Had this been qualifying, the decision would have been a trickier one!
I could not say how long this issue would take to resolve. If I had known that it could be fixed within a few minutes, I probably would have held the car up. Holding the car up and not fixing the issue would not go down well with the other engineers or the driver.
What is important to note is that there are a lot of things that would have changed my mind before sending. As an engineer, and as someone in charge of a system or systems on a car, you must be prepared to make tough decisions such as holding a car up. You can however, only do this once you have the authority and experience to do so. Be brave enough to do it when you need to, and smart enough to know when that is.
For those interested, this issue turned out to be related to an anti-virus software update that had happened overnight. The resulting definitions of what was “dangerous” were over-zealous and did not work with our racing car. A silly problem, but one that took a lot of head scratching!
