Breaking News
Comments
John.Donovan
User Rank
Manager
Well said
John.Donovan   4/1/2014 10:26:37 PM
An engaging keynote and an excellent article. After hearing Barr's presentation I don't plan to get within a country mile of a self-driving car!

elctrnx_lyf
User Rank
Manager
Re: Well said
elctrnx_lyf   4/2/2014 2:04:55 AM
NO RATINGS
Yes, the self driven cars are too far from reality and safety is a major challenge. But the companies definitely want to invest in this to be in race and to make the business in the future. The real challenge lies in the hands of governments to make sure the automobiles are really safe and they are tested perfectly.

LarryM99
User Rank
CEO
Re: Well said
LarryM99   4/2/2014 12:28:47 PM
NO RATINGS
There are risks in self-driving cars, but as another post in this area says humans are bad at assessing risk. They are also not that great at driving cars. A self-driving car fatality would make headlines, but the numerous daily fatalities from drivers on cell phones, falling asleep at the wheel, or otherwise just not paying attention rarely make it above the fold (obscure reference for those who still remember newspapers). This case illustrates a net lowering of the safety in the activity of driving a car, where there is real evidence that self-driving cars would raise the safety level.

Bert22306
User Rank
CEO
Re: Well said
Bert22306   4/2/2014 5:05:39 PM
NO RATINGS
Agreed, Larry. The idea that a human in control, behind the wheel, is inherently "safer" than having an algorithm do the driving is really odd. Not saying that truly autonomous cars are realistically possible right this minute, but surely, in principle, such automation can easily beat human intervention, when it comes to consistency, reliability, and consequent safety.

Perhaps the problem is that people think they are more in control of their own driving safety than they really are. Sure, I too think I'm the most expert driver on the road. My problem is all those other unpredictable half-wits around me.

Even in the simplest case, i.e. trains running on determinstic tracks, how many times have we seen recently in the news that the operator dozed off? This is safe?

sixscrews
User Rank
Manager
Re: Well said
sixscrews   4/9/2014 3:02:59 AM
NO RATINGS
elctrnx_lyf's comments don't take into account the tendancy of governments to shade things in favor of constituencies and power brokers whose interests are not in line with the end user.

He says:
"the real challenge lies in the hands of governments to make sure the automobiles are really safe and they are tested perfectly."

 After spending nearly four decades building things that are 'really safe' and 'tested perfectly' with and without a part of the US Government looking over my shoulder I beg to differ - I don't think a Government, be it stamped with US, UK, PRC or any other set of initials is capable of doing this job. It's up to the designers, developers, implementers and testers to work this out. The base is a good set of design rules followed by attention to these rules throughout the process ending in reviews and testing, testing, testing.  The reviews must pay attention to the top level design rules - violation of which is an automatic fail.  After that it's up to the testers to find all the ways a system can fail - a nearly impossible task in a complex system.

If you are testing with the expectation that the system is working correctly you are working with a black bag over your head - systems are bound to fail and it's the tester's role to find those failure modes. Problem is, I'm not sure we can find those modes once a system reaches a critical level of complexity.

This brings up the question of how to make systems simpler and, perhaps, more reliable. I don't know how to do this but one approach would be to use known building blocks (I know how a brick works, I think) to construct a more complex system the can be tested from the component level to the system level and chasing down ALL anomalies.

Perhaps this is a recipe for paralysis by analysis - we all know that things get built despite the questions - but when it comes to running a system that is supposed to protect our personal or loved one's wetware we can't afford to rely on 'trust me, I'm an engineer' anymore.

ss/wb

Max The Magnificent
User Rank
Blogger
Re: Well said
Max The Magnificent   4/8/2014 11:22:38 AM
NO RATINGS
@John Donovan: After hearing Barr's presentation I don't plan to get within a country mile of a self-driving car!

You won't need to ... they'll come to you LOL

MWagner_MA
User Rank
Manager
FMECA's, MTBF and other misguided statistics
MWagner_MA   4/2/2014 7:35:54 AM
NO RATINGS
As anyone who has done a MTBF calculation to MIL-HDBK-217 knows, you can make the numbers say what you want.  Our current culture of "sqeeze every last dollar out" of a business means that safety reviews can easily be skewed by a "severity" or "probability" rating in a FMECA analysis.  I have witnessed a similar conclusion within my own company when such a safety analysis (although not as severe as a car crash) was discussed and discounted as not enough to warrant a redesign.  Tools will have to be worked on to verify designs better.

John.Donovan
User Rank
Manager
Re: FMECA's, MTBF and other misguided statistics
John.Donovan   4/2/2014 7:58:02 AM
NHTSA doesn't have the budget to hire a crack team of software experts, and congress isn't about to give them more teeth to enforce standards. OTOH the EU could take the lead and demand that all automotive software confirm to ISO 26262 and that it be certified by an independent testing body such as Germany's TUV SUD. That would be a big step forward from having the public be the beta testers and the court the enforcers.

boblespam
User Rank
CEO
Re: FMECA's, MTBF and other misguided statistics
boblespam   4/2/2014 9:38:54 AM
There's one good Dilbert strip about this story... from 2004-01-27 !

http://dilbert.com/fast/2004-01-27/

Some Guy
User Rank
CEO
Re: FMECA's, MTBF and other misguided statistics
Some Guy   4/2/2014 12:07:00 PM
While you may be able to skew the predictions and rationalize not doing a good job, you can't fool the field results. It's unfortunate that this had to take lawsuits to get in front of this, but given the analysis by the plaintifs experts, it's abundantly clear that they not only screwed up, but didn't even have the first clue on how to do real-time, let alone saftey-critical software.

Moreover, really Toyota has three HUGE problems they have to fix. In addition to the SW problem, they also lacked a proper design validation program that should have alerted them to the design flaw early, and they weren't tracking their field failures and getting to root cause in a day. Very uncharacteristic for a Japanese company, especially Toyota.

Finally, humans are notoriously bad at assessing risk. Even NASA, the world leaders in safety-critical systems blew it with Challenger and Columbia. At least they try (and got in trouble when they cut corners trying.) With Toyota's ignorance of how to even DO real-time safety-critical software, is it any surprise that they totally whiffed the risk ANALYSIS?

To me the takeaway as a consumer is not to avoid the benefits of new auto technology, but to make sure there is a hardwired physically-interrupting-the-power OFF switch (which Toyota also missed).

john_e_k
User Rank
Rookie
Two ways of constructing SW...
john_e_k   4/2/2014 12:13:35 PM
NO RATINGS
We had the answer in 1980:

"There are two ways of constructing a software design.
One way is to make it so simple that there are obviously no deficiencies.
And the other way is to make it so complicated that there are no obvious
deficiencies."
-- C. A. R. Hoare, 1980 Turing award lecture

 

TrishRobina
User Rank
Rookie
For our safety
TrishRobina   4/2/2014 12:37:37 PM
NO RATINGS
Aboe all concerns one thing that concerns me a lot is the safety of all people in here. - Feed the Children Reviews

markmhel
User Rank
Rookie
Re: For our safety
markmhel   4/10/2014 11:42:20 PM
NO RATINGS
To keep this will make the reason for having it everyhting could done for. - BrandStar Entertainment

DrQuine
User Rank
CEO
Successful Testing to Ensure Safe Cars?
DrQuine   4/2/2014 5:33:39 PM
NO RATINGS
Given the extraordinary effort that has been expended to identify the root cause of the observed Toyota accidents (for which the failure mode is known with 20-20 hindsight), I would say it seems unlikely that proactive testing could anticipate such failures. We also know that the hardware induced accidents represent a very small fraction of the total automobile accidents each year - most can be attributed to driver error. That said, certainly we want the cars to support drivers in their efforts to be safe. The nightmare scenario of a car thwarting the driver's efforts to drive safely is one we all want to avoid. Perhaps simple solutions are the most reliable: a means to ensure that brakes override accelerators. Ironically, the solution we heard as children (pull the keys out of the ignition) has an unintended side effect as illustrated by the GM ignition recalls: it locks the steering and disables the air bag safety devices when the car subsequently crashes.

Bert22306
User Rank
CEO
Re: Successful Testing to Ensure Safe Cars?
Bert22306   4/2/2014 6:04:16 PM
NO RATINGS
Dr Quine, just to be scrupulously accurate about this, the GM ignition key problem does not lock the steering. What happens is that if your keychain is too heavy, in these small GM cars, and you hit a big bump or such, the key may move to the ACC position. Not to the locked steering column position.

GM is saying that for the time being, until they get their parts in dealerships, people should remove all items from the ignition key, including the fob thingie. That would prevent the key from exerting any counterclockwise torque on the ignition switch.

DrQuine
User Rank
CEO
Re: Successful Testing to Ensure Safe Cars?
DrQuine   4/2/2014 6:20:10 PM
NO RATINGS
@Bert22306 Your point is well taken. Pulling the keys out of the ignition to thwart run away Toyota acceleration would lock the steering wheel and (from the GM experience) disable the airbags. The GM ignition switch issue should not lock the steering wheel (unless the key continued past ACC to LOCK). It would, however, disable the power steering and make steering a little more difficult.

jeremybirch
User Rank
CEO
Re: Successful Testing to Ensure Safe Cars?
jeremybirch   4/3/2014 7:15:21 AM
You cannot anticipate all failure modes, but you can use a wealth of tools to find holes in the software and provide mechanisms to recover. So you can run code such as Purify, Coverity etc to spot basic software engineering flaws, you can use code practices that make the code quality higher, and you can run long simulations with focussed and randomised inputs to see if the expected happens.

One way that more expensive safety critical systems survive is to actually have 3 independently designed systems taking the same inputs and voting on the outcomes - it is unlikely that any 2 will have the same bug (unless the bug was in the original spec). If this is too expensive to implement in a car then do this at the simulation stage - have the real software and at least one other version and run them for a long time with lots of input data and spot when they disagree - that could indicate a bug.

For recovery in a real car there is no real excuse not to have watchdog timers - as I understand it in the Toyota case the software on one processor crashed and caused acceleration and the disablement of the brakes. The cures here are:

1) make sure the brakes are not on the same processor as the acceleration, and go through such a simple system that there is no way that pushing the pedal does not slow the car down - ie fail-safe. By all means put in all sorts of fancy stuff to make braking better, but ensure that it will always happen when the user presses the pedal (eg if the user presses the pedal hard for more than one second - apply the brakes no matter what the rest of the software is thinking)

2) use a watchdog timer to spot when a processor has crashed or deadlocked or livelocked, and then reset the processor. This may be non-ideal but would at least mean that a fraction of a second after the software malfunctioned it would be back on line. Of course the software would then need to be designed to expect the possibility that when it awoke the car would be travelling at speed, rather than at the kerbside

 

Tim W
User Rank
Manager
Re: Successful Testing to Ensure Safe Cars?
Tim W   4/3/2014 1:45:16 PM
Two simple words for exhaustive software testing:  code coverage.  Evaluate software on drive-by-wire software to the same standards as does the FAA.   

One possible way forward would be to isolate engine management into a stand-alone box which could be networked to the transmission controller and other systems in the vehicle.  Make it run on a safety-certified RTOS and certified to a given SIL  

Automakers build (or buy) incredibly reliable under-hood electronics which operate successfully in enviromnets equally hostile to those specified for mil-spec parts.  Give them regulatory cover to develop software to the same level of reliability.

Chris Cole
User Rank
Rookie
RIsk Estimation
Chris Cole   4/2/2014 9:23:19 PM
NO RATINGS
From Some Guy's post:

"Finally, humans are notoriously bad at assessing risk. Even NASA, the world leaders in safety-critical systems blew it with Challenger and Columbia."

Actually humans can be pretty good at accessing risk when they stick to the science. During early years of the shuttle program, I had friends working on it at Rockwell International, one of the main contractors. They had told me that the predicted rate of shuttle failure to be about 1 in 100 flights or 1%. Since this was not acceptable, the failure rate was continuously recalculated over the years until it was officially about 1 in 100,000 by the time the shuttle started flying. While the calculations changed, the shuttle remained basically the same. In total there were 135 shuttle flights with 2 lost, which is a 1.5% failure rate. Those early, unbiased risk estimates turned out to be pretty good.

ajawamnet
User Rank
Rookie
Take a look at Page 17 of the NASA report
ajawamnet   4/12/2014 1:15:45 PM
NO RATINGS
http://nepp.nasa.gov/WHISKER/reference/tech_papers/2011-NASA-GSFC-whisker-failure-app-sensor.pdf

And this from page 15:

" Resistance measurements between all combinations of
external APP sensor connector pins detected an
intermittent resistive short between VPA1 and VPA2
– Measurements made using multiple multimeters
– Initially, ~3.5M   , dropping to ~5k   ,  and then remaining
between 238    to 250   , until the pedal assembly was
mechanically shocked
– Mechanical shock to the pedal assembly returned the resistance
to ~3.5M    and further pedal actuations dropped the resistance
again to ~5k    and finally to the range between 238    to 250
– This shorting resistance remained unchanged throughout the
entire range of travel of the pedal, except when mechanical
shocks were delivered"

 

And this from the Summary:

•   A tin whisker induced short was responsible for the failure of a 2003
Toyota Camry Accelerator Pedal Position (APP) Sensor based on a Dual
Potentiometer Design
–   NHTSA report states warranty analyses identified at least two additional failures due to
tin whiskers in similarly designed APP sensors

 



EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Creating a Vetinari Clock Using Antique Analog Meters
Max Maxfield
55 comments
As you may recall, the Mighty Hamster (a.k.a. Mike Field) graced my humble office with a visit a couple of weeks ago. (See All Hail the Mighty Hamster.) While he was here, Hamster noticed ...

EDN Staff

11 Summer Vacation Spots for Engineers
EDN Staff
11 comments
This collection of places from technology history, museums, and modern marvels is a roadmap for an engineering adventure that will take you around the world. Here are just a few spots ...

Glen Chenier

Engineers Solve Analog/Digital Problem, Invent Creative Expletives
Glen Chenier
11 comments
- An analog engineer and a digital engineer join forces, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
45 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...

Flash Poll
Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)