This TED video offers some interesting thoughts on self driving cars. There are a lot of decisions we need to make as a society before we get to widespread autonomous car use.
Why why WHY is everyone so sold on this idea when computers are NOTORIOUS for not doing what we want, when we want it, the way we want it, and when software has NO WARRANTY and the computer industry has effectively ZERO accountability??
Now we're talking about excusing these companies from safety standards?? Just to do testing? As if that slippery slope won't result in the "relaxed" safety regulations staying relaxed permanently.
the automotive industry is historically known for destroying mass transit. So the USA became an addict to cars and our mass transit sucks. Now the autonomous car proponents' number one justification for autonomous cars is "bad drivers". Solution? Not our society investing in mass-transit infrastructure! No, of course it's going to be an investment in over-complicated, inherently risky autonomous cars from the industry that benefits from the continued crippling of mass-transit, and the industry that has zero oversight, zero warranty, zero accountability, and the most "special pleading" excuses for why things can't be expected to be reliable. Because capitalism and gadgetry.
This is NOT sensible. It is just another symptom of a plutocratic oligarchy, supported by almost every tech gadget geek because... geeky.
Waiting to see what their reaction will be when the first death caused by a software bug will occur ....
(NB : my background is in certification of critical embarked aerospace software (=Level A; ED-12B/C ; DO-178B/C))
what did they do after the first death caused by hardware failure? nothing new.
What you call "hardware failure" can be, either : a design problem, or, a manufacturing problem (the design is OK, but wrongly implemented on a limited subset of the production). Design problems are generic. The specificity of software is that it is a pure design activity, without any "manufacturing" or "production" steps (the only one being reduced to the download of the software into the processor that runs it).
Any area of design can introduce problems, possibly catastrophic ones. The "traditional" areas of design (mechanics, etc..) are considered as "safe", in process terms, because unless you do wrong calculations, the law of physics will give you the correct answer. This is not the situation in software, and this is why the particular concerns raised by software (but also "complex" electronics) have justified in aeronautics specific regulatory documents such as ED-12B/C ; DO-178B/C or the equivalent in electronics. These documents put constraints on the design process (here, the software design process).
When a new model of plane is designed, it has to be approved by a safety authority, which checks if the regulatory requirements are fulfilled (this is the Airworthiness activity). In addition to the process constraints mentioned before, the plane (or the engine) have to undergo standard tests (or demonstrate compliance through calculations, if this is an accepted compliance mean for the authority).
The same situation exists for cars (although I do not live in the United States, I suppose it is the same as in Europe. e.g. you now have crash tests to pass with success, but so far, until now, no requirements on the design process.
In practice the vast majority of "hardware" car problems are, I believe, of manufacturing origin, and this is why the safety authority is not concerned, because no generic design flaw explains the problem, and in case there is, it is not a violation of applicable safety requirements.
The normalized tests required by regulatory documents deal with situations which go far beyond what will the product encounter in commercial exploitation. Their logic is to concentrate on safety issues alone (and only the most critical ones). the manufacturer is supposed to design a product which runs according to its intended use, keeping in mind that if it is not the case, his product will not appeal to the consumer, and this is not problem of the safety authority....
Of course, in case of problems, the manufacturer can be in trouble with the authority, but only in case of a violation of applicable regulations (the worst for him being to lose confidence from the authority), but also it has to face legal consequences, and this is a strong incentive (may be the more important, in particular in the United States, where justice can settle punitive damages at a level we have trouble to figure out in Europe).
This TED video offers some interesting thoughts on self driving cars. There are a lot of decisions we need to make as a society before we get to widespread autonomous car use.
Comments
http://arstechnica.com/cars/2016/01/assists-autopilot-and-more-ars-talks-about-autonomous-driving-with-audi/
Now we're talking about excusing these companies from safety standards?? Just to do testing? As if that slippery slope won't result in the "relaxed" safety regulations staying relaxed permanently.
the automotive industry is historically known for destroying mass transit. So the USA became an addict to cars and our mass transit sucks. Now the autonomous car proponents' number one justification for autonomous cars is "bad drivers". Solution? Not our society investing in mass-transit infrastructure! No, of course it's going to be an investment in over-complicated, inherently risky autonomous cars from the industry that benefits from the continued crippling of mass-transit, and the industry that has zero oversight, zero warranty, zero accountability, and the most "special pleading" excuses for why things can't be expected to be reliable. Because capitalism and gadgetry.
This is NOT sensible. It is just another symptom of a plutocratic oligarchy, supported by almost every tech gadget geek because... geeky.
What you call "hardware failure" can be, either : a design problem, or, a manufacturing problem (the design is OK, but wrongly implemented on a limited subset of the production). Design problems are generic. The specificity of software is that it is a pure design activity, without any "manufacturing" or "production" steps (the only one being reduced to the download of the software into the processor that runs it).
Any area of design can introduce problems, possibly catastrophic ones. The "traditional" areas of design (mechanics, etc..) are considered as "safe", in process terms, because unless you do wrong calculations, the law of physics will give you the correct answer. This is not the situation in software, and this is why the particular concerns raised by software (but also "complex" electronics) have justified in aeronautics specific regulatory documents such as ED-12B/C ; DO-178B/C or the equivalent in electronics. These documents put constraints on the design process (here, the software design process).
When a new model of plane is designed, it has to be approved by a safety authority, which checks if the regulatory requirements are fulfilled (this is the Airworthiness activity). In addition to the process constraints mentioned before, the plane (or the engine) have to undergo standard tests (or demonstrate compliance through calculations, if this is an accepted compliance mean for the authority).
The same situation exists for cars (although I do not live in the United States, I suppose it is the same as in Europe. e.g. you now have crash tests to pass with success, but so far, until now, no requirements on the design process.
In practice the vast majority of "hardware" car problems are, I believe, of manufacturing origin, and this is why the safety authority is not concerned, because no generic design flaw explains the problem, and in case there is, it is not a violation of applicable safety requirements.
The normalized tests required by regulatory documents deal with situations which go far beyond what will the product encounter in commercial exploitation. Their logic is to concentrate on safety issues alone (and only the most critical ones). the manufacturer is supposed to design a product which runs according to its intended use, keeping in mind that if it is not the case, his product will not appeal to the consumer, and this is not problem of the safety authority....
Of course, in case of problems, the manufacturer can be in trouble with the authority, but only in case of a violation of applicable regulations (the worst for him being to lose confidence from the authority), but also it has to face legal consequences, and this is a strong incentive (may be the more important, in particular in the United States, where justice can settle punitive damages at a level we have trouble to figure out in Europe).