scary about the car not braking and the missile interception
how often does the missile intercept happen and where did the missile come from?
Swiss Formula E driver Edoardo Mortara ended up in hospital after a software error left him driving into a safety wall at the ABB FIA Formula E World Championship in Diriyah, Saudi Arabia, on Saturday. In a statement issued via Twitter, the Mercedes-EQ Formula E Team blamed the code governing the race car's braking system. " …
> how often does the missile intercept happen
As often as the government's popularity polls start to show that the populace might be feeling insufficiently grateful for the important work the government does protecting them.
It's a nice soundbite, but more common is fail safe systems failing because they're not actually fail safe at all. The point of a fail safe is that it fails into a safe state. The common example being fire doors held open by an electromagnet. You can close the door manually or by pushing a button or whatever, but if everything goes horribly wrong and power is lost entirely, the door simply swings closed under its own weight. The point is that in the event of a failure, nothing should need to be actively done; rather, you need to actively prevent it from entering the safe state while things are working. Obviously there can always be other failure modes that can't be safely handled - a self-closing fire door won't work if an earthquake distorts the building structure - but the failures your system is designed to handle should be handled with no active intervention required.
If we look at this case, it's clear that there was no fail safe involved at all. If the front brakes fail, the system needs to detect the problem and actively apply the rear brakes. That's not failing into a safe state. A fail safe brake system would mean something like actively holding the brakes away from the wheels, so in the event of a failure they drop into place and stop the car. But since randomly slamming the brakes on could be just as dangerous as not having any brakes, I don't think the concept of fail safe even makes sense to think about when it comes to braking systems in racing cars.
'A fail safe brake system would mean something like actively holding the brakes away from the wheels, so in the event of a failure they drop into place and stop the car.'
You've just described the exact system used on the railway - Air is used to force the brakes open; A brake application or failure (i.e. damaged pipe) causes a loss of air and the brakes apply automatically.
And many HGV braking systems as well...
In the case of a loss of service air from the cab, the whole rig will stop, and following traffic should be able to deal with that.
On a race track the following vehicles aren't expecting random braking, just braking for corners, that's why F1 has flashing red lights not for braking, but for "This car has suddenly lost 160bhp".
There is no way a racing driver could react to brake lights.
> In the case of a loss of service air from the cab, the whole rig will stop, and following traffic should be able to deal with that
And might as well mention, a lightly loaded lorry or bus has significantly higher braking power than most cars. Keep your distance!
I did drive HGV + PCV for a while. In non-emergency vehicles we are trained to brake gently for pax comfort / load safety. What you see on a regular day is *not* what the machine can actually do. As my colleagues from the command vehicle in the fire service found out when following our new truck a bit too closely. :)
In this case it looks very similar to the A400 transport plane crash.
Config file for the brakes bad/missing so the failsafe disables the system = in this case the system being brakes.
In the transport plane the config file for the engine was missing so the failsafe system disabled the system safely = in that case all 4 engines
"In this instance, an incorrect software parameter that meant the rear brake system didn't activate as intended and the fail-safe did not kick in."
You have to wonder why such a parameter even exists?! It should be impossible for a fail-safe to be disabled, otherwise it's not a fail safe!!
The fault was primarily in the tests. Software always has bugs, and the tests are there to catch them. The more critical the software, the more comprehensive the testing should be. So the most important issue right now isn't finding the bug, it's working out how it got past the tests.
Maybe if the programmers were forced to test their own code, in-situ, they'd be a little more careful...
I never worked on automotive systems, but I did work on nuclear reactors, traffic systems and manufacturing systems and the code was always thoroughly tested before release. We'd probably spent about 2/3 of project testing, before it was released into production - and generally, you did your own unit testing, but system and integration testing had a whole dedicated team.
Having a dedicated testing person or team is really important. For one thing a programmer testing their own code will only test that it does what they think it should do, which doesn't help if they've misunderstood the specification, or missed part of it. But more importantly, test engineering is a whole different mindset - the best programmers often aren't the best test engineers, and vice-versa.
That was one of the most important things that was drummed into us in college and at my first employer.
You test what you expect to happen. Therefore you take the specification and the first thing you do is write your test cases based on the specification. Once you have your test cases finished, you can start with the programming. That doesn't make them perfect, but it means they are based on the specification and not the code you have written. That picks up a lot of common errors that would otherwise have been missed.
Unfortunately, many projects I've worked on recently have not had proper specifications and testing was cut to the bone and you had to turn out code first and write test scripts and test cases if you had time afterwards. Time scales were not realistic and the budget for the coding were much too low to do the job properly. But, hey, they are only internet facing shopping and payment systems, so doing it properly and safely isn't really necessary, after all, what could possibly go wrong?
My "best" project (as in closest to being perfectly executed) was a VisualBasic 6 system written for a large agrochemical company to collect its world-wide budgeting and sales forecasts and pushing the data into Hyperion Essbase.
The specification was pretty comprehensive and included use cases and all the business rule errors that could occur. The unit tests and system tests were written based on the spec, then we got around to coding. We had around 75,000 lines of code, when it went live. 3 programmers, 4 months of coding and testing. The system was released world-wide to over 60 national subsidiaries.
In 2 years, we had 2 bug reports. The first was a bug in Windows 98 International English edition*. The other was a simple problem with cell editing in a grid container. That is the only system I've worked on that had so few bugs reported. A shame other projects didn't run so smoothly - although I was generally assigned to projects that had already gone pear-shaped and had to help bring them back on track.
* The bug in W98 International English edition was the Win32 API for getting the localized month names. We tested it in UK English, German and French. All worked flawlessly. But a lot of Asian and South American countries were using International English editions. You gave the API function the month number and it returned the name of the month (E.g. 1 = January (EN), Janvier (FR) and Januar (DE), 2=February, Février, Februar etc.). Only in International English 1=January, 2=January, 3=January, 4=January, 5=January...12=January. In the end, HQ decided that we would just hard-code the English month names for everybody, as English was the corporate language, so we didn't have to be "nice" to the users.
I'm maths challenged. Help me out.
"We had around 75,000 lines of code, when it went live. 3 programmers, 4 months of coding and testing."
At 22 days/month, that's 284 lines of code per developer per day, not counting testing. At 30 days/month, it's 208 lines. It seems a *little* high.
Richard Feynman's annex to the Challenger Report is always a good read for anyone involved in system reliability. His section on 'Avionics' is, in my opinion, outstanding. It's relevance to software-safety is exemplary.
https://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/Appendix-F.txt
In the shuttle case it would seem to be bad project management at the top.
If you spend all your budget making insanely safe software at 1000x the cost of normal software you haven't really benefitted anyone.
The shuttle was still dangerous because of solid fuel boosters and nobody in industry benefits because none of the lessons of wiring one line of code/person/year with nines-nines safety were usable in the world.
A lot is made of the "Trickle Down Effect" of technology from racing and this is something that is pushed particularly hard in Formula-E.
If this is the sort of "improvements" we can see trickling down into standard cars the outlook is not particularly good. This stinks of Boeing type QA.
This feels like re-inventing the... braking system. Automotive brakes have been effectively fool-proof for decades. Dual-circuit hydraulic brakes virtually never failed, and the most common failure mode was visually obvious (a puddle under a wheel) or tactile (the brakes didn't feel "right"). Then ABS came along, and brake failure went through the roof (or, more accurately, brake sensor failure that didn't actually affect braking performance but lit up a warning on the dash that then needed £££ to fix went through the roof). Now fly-by-wire brakes that can fail with no warning at all. This is not a good trajectory. Let's go back to simple dual-circuit hydraulics that work.
That the brakes are completely fly-by-wire with no direct actuation from the drivers foot. That seems a tad short-sighted to me as even if the brake booster failed, a car normally can still be stopped by simply jamming your foot down harder (as people are want to do in an emergency).
"and they're incredibly safe"
Except when the braking software fails and they headbutt a wall. But yes, apart from that, incredibly!
Seriously, using regen braking is no excuse for not having some kind of mechanical fall back system. Road cars manage it. While there is a human in the cockpit system safety critical systems should not be drive by wire unless there is no option, eg ABS.
"Except when the braking software fails and they headbutt a wall. But yes, apart from that, incredibly!"
Including, even especially when the brakes fail - which more commonly happens for other reasons. These cars (and track safety systems) are designed to let drivers walk away from high speed impacts. They can therefore accept risks of things like brake failure that are utterly unacceptable in another situation.
Having a mechanical fall-back system is pointless if there's no chance anyone could activate it. (It's even more pointless if the brake failure is mechanical, which is far more common; you can yank a mechanical e-brake all you like, it won't do anything if your brake discs fell apart.)
Perhaps you haven't considered that the nature of racing means that drivers are _always_ attempting to extract the maximum performance by braking as late as possible and then hitting the brakes as hard as possible without locking the wheels. If the brakes fail under braking, even ignoring reaction time it's still too late to take alternative action. On a lot of tracks momentarily locking the inside front wheel under braking can lead to hitting the barriers, let alone losing braking entirely.
"These cars (and track safety systems) are designed to let drivers walk away from high speed impacts"
Thats what everyone thought just before Senna died.
"They can therefore accept risks of things like brake failure that are utterly unacceptable in another situation."
I suspect if you asked a racing driver whether they accept brake failure as an occupational hazard the answer would be a resounding no. They take risks but they expect their safety equipment to work - any failure should be on their part, not the machines! Using your logic you could say "Hey, so he got badly burnt, he shouldn't expect Nomex to work 100% of the time!"
"Having a mechanical fall-back system is pointless if there's no chance anyone could activate it"
God knows what thats supposed to mean.
"Perhaps you haven't considered that the nature of racing"
Haven't I? Oh ok, thanks for the heads up there Murray.
Being patronising adds precisely nothing to your already flimsy argument.
"Except when the braking software fails and they headbutt a wall."
You're equating "safe" with "not crashing". That's not what it means. "Safe" means that when the car headbutts the wall or becomes involved in any of those other "incidents" that can happen in motor racing, the driver gets out and walks away.
Nobody suggests it’s 100% safe, Jules Bianchi is a more recent tragedy.
But it is amazing and beneficial to us all that so much engineering effort goes into racing car safety that an F1 car can be sliced in two as it pierces and passes through a metal barrier, burst into a fireball and the driver can step out and hop over a fence.
Senna’s accident had an element of misfortune about it, that the high energy suspension component should impact where it did. And the Jules Bianchi incident involved a construction vehicle on the track boundary where there ought to have been, in normal circumstances, an energy absorbing barrier.
They knew exactly how dangerous open-wheel (F1) racing was at the time when Senna died. Roland Ratzenberger died during qualifying the day before.
Senna's and Ratzenberger's deaths were at the end of what Martin Brundle has described as F1's "light-bulb" years: if a driver died, they slotted another one in and carried on.
At least two marshals have died at F1 race weekends since Senna as well as Bianchi (and test driver Maria de Villota, whose death was recorded as due to her injuries sustained in a crash during testing for Marussia). Anthoine Hubert was killed in an F2 race at Spa in 2019.
"The braking system on Formula E cars is designed so that if the front brakes fail, the rear brake system is activated as a fail-safe," the Mercedes-EQ Team said. "In this instance, an incorrect software parameter that meant the rear brake system didn't activate as intended and the fail-safe did not kick in."
So software stopped the failsafe kicking in to apply the rear brakes? Jolly good. But I has questions:
1. How safe is the failsafe? Try stopping a car from speed using the rear brakes only. Easy enough to do just whip the handbrake on. Doesn't do a very good job of stopping the car does it? So you're piling down towards one of those hairping bends formula E track designers are so keen on and at your braking point you discover your front brakes have failed. How likely is the "failsafe" to stop you from hitting the wall?
2. Presumably the team are so keen to discuss the failure of the failsafe at length because that distracts from the total failure of the front brakes. So why did the front brakes fail so catastrophically?