4 ms·

> there won't be 2 breaking systems competing with one-another. Different systems controlling the same end-points is never a good idea. Aerospace engineer here

> there won't be 2 breaking systems competing with one-another. Different systems controlling the same end-points is never a good idea. Aerospace engineer here. Different systems controlling the same end-points is literally a basic engineering safety technique. Not only you have the human pilot as a competing system controlling the same end-points as the autopilot, you may have even different competing autopilots. I had a professor at the Uni who was part of the engineering team of the flight computer of a certain jet fighter. Two engineering teams were given the specs of the system and told to produce a flight computer. The two teams weren't allowed to talk to each other to prevent bugs cross-pollinating the two systems. After all, what good is to have two identical system for redundancy if they can be affected by the same bug? (That's also why pilots eat different meals in-flight!) Then, the two completely different systems are installed, duplicated, into the plane and put to the test. The four computers must perform equally as per the specs. If the recommended output of a single computer diverges from the other three, that computer is faulty and disregarded. If two computers of the same design have a bug and start giving out-of-envelope readings but the other two are consistent, control is handled to them. I'm certainly very appalled to see in this thread how safety engineering techniques that every engineer learns in University is completely disregarded or even reversed. At least in the aerospace community, development and implementation of these safety techniques has been paid in blood. These are lessons that shouldn't be forgotten when developing other transport technologies IMHO.

jschwartzi 9y ago
Most of the commenters did not study engineering. They studied computer science. So the only exposure they would have had is working with someone like you.
- JorgeGT 9y ago
  I wonder if those in self-driving development at Uber et al. share the same non-engineering background. I think it would be ultimately in the interest of these companies that stringent regulation is enacted, so the public can feel as safe and confident riding self-driven vehicles as they feel riding a thin aluminium tube with two gigantic kerosene hairdryers flying at 35,000 ft.
jacquesm 9y ago
Software people as a rule absolutely suck at dealing with exceptions and in general tend to make a ton of assumptions about the underlying hardware and sensors that may not hold up in practice. The 'happy path' is where 90% of the attention goes, when actually 90% of the attention should go to the exceptional bits. But as an industry we're slowly learning and the habits and practices of other engineering disciplines are slowly seeping into to software. Aerospace (and medical) is where things are much better.

jschwartzi 9y ago

Most of the commenters did not study engineering. They studied computer science. So the only exposure they would have had is working with someone like you.

JorgeGT 9y ago
I wonder if those in self-driving development at Uber et al. share the same non-engineering background. I think it would be ultimately in the interest of these companies that stringent regulation is enacted, so the public can feel as safe and confident riding self-driven vehicles as they feel riding a thin aluminium tube with two gigantic kerosene hairdryers flying at 35,000 ft.

jacquesm 9y ago

Software people as a rule absolutely suck at dealing with exceptions and in general tend to make a ton of assumptions about the underlying hardware and sensors that may not hold up in practice. The 'happy path' is where 90% of the attention goes, when actually 90% of the attention should go to the exceptional bits. But as an industry we're slowly learning and the habits and practices of other engineering disciplines are slowly seeping into to software. Aerospace (and medical) is where things are much better.