> Seems wild that they can code and deploy an update of a critical-seeming component in the field like that. I thought such a firmware update would need extensive QA in the lab, along with root causing why this bug slipped through their processes anyway.

These cars are in a perpetual Q&A state, they are getting modified between races. That's true for the "big teams", small teams don't have the resources, they're just "happy to be there". That's why it's possible to see stories like Brawn GP[^1]. That's what makes the sport fascinating, because the overtakes are not as much as one would hope for a ~2-3 hours race. But every little thing counts. In the last race 1st and 2nd had ~103ms diff or something like that for example, which is something that didn't happen for 15-20 years (maybe more).

[^1]: https://www.youtube.com/watch?v=jd3miTpvUmI

This reminds me of a story how Deep Space 1 was fixed from 100 million miles-away. [1]

[1] https://gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-t... (the last paragraph, search for "remote debugging" in the page)

It seems they simply disabled a bunch of power limits. Probably just settings, rather than an actual code update.

F1 are effectively prototype cars.

Every GP is a slightly different car running bleeding edge tech and code.

It was very unlikely there was actual coding involved, as even the C++ build and test toolchain would run for ages (in my automotive days it would run for 45 minutes and that was just build, link and static analysis). In this case it's probably just a config change.

I'm wondering how good the simulators are. At the start of the season, they were still learning the systems trying to figure out why they were losing power in the straights. So depending on the driver, issues may or may not become apparent. That's like trying to debug why an email can only be sent to a recipient less than 500 miles away.

It was probably just "config" changes or changing some hard-coded constants. So relatively straightforward.

It was probably just a json with settings.

Disabling code is usually safer than enabling, seems they were able to pinpoint this rather quickly.

I have no idea if modern-day SV’s “tests pass… idfk, it’s a web app… LGTM I guess” coding ethos was the cause of this particular bug. However, it’s a great, relatively benign demonstration of why it has absolutely zero fucking place controlling extremely dangerous hardware shooting a human around a race track surrounded by people.

They rolled out a prepared safe defaults version with lots of checks, including the crashing one, removed.

I think those engineers had some memories of their FSAE / FSUK days during that patch.

They didn't, it just needed a restart. From the first reports the first car's software genuinely glitched out because of the new track/rain/etc and had to be restarted, the other cars got anti-traction control triggered because going this slow for this long unspools the turbo, which got so bad the detection software made a false positive.