Breaking News
Comments
Newest First | Oldest First | Threaded View
<<   <   Page 2 / 3   >   >>
Antony Anderson
User Rank
Rookie
Re: What is covered in school these days
Antony Anderson   11/9/2013 6:16:52 AM
NO RATINGS
What I would hope would be to encourage the next generation of engineers to read not just about engineering successes, but engineering failures. It is not the making of mistakes that matters, but the failure to learn from them.

Although an electrical engineer, I remember being shown a  film about the Tacoma narrows bridge disaster - Galloping Gertie  and it really stuck in my mind. It really illustrates dramatically system instability and eventual collapse.

There is now a wealth of material available via U tube that could set the scene for classes in safety and reliability. Otherwise Failure modes and effects analysis or component reliability classes will seem incredibly boring.

Antony Anderson
User Rank
Rookie
Re: Time to market pressure, less time for QA and lack of test engineers
Antony Anderson   11/9/2013 5:59:00 AM
NO RATINGS
May I suggest having a look at Professor Nancy Leveson's Home page at

http://sunnyday.mit.edu/

and especially:

System Safety in Computer-Controlled Automotive Systems, by Nancy G. Leveson, SAE Congress, March, 2000. (Postscript), (PDF).

 An invited paper that summarizes the state of the art in software system safety and suggests some approaches possible for the automotive and other industries.

and what I think is a  brilliant read:

High-Pressure Steam Engines and Computer Software by Nancy Leveson. Presented as a keynote address at the International Conference Software Engineering in Melbourne Australia, 1992 and published in IEEE Computer, October 1994. (PostScript) (PDF ).

A comparison between the history of steam engine technology and software technology and what we can learn from the mistakes made with steam engines.

Quite a lot, as it so happens! May I wish everyone a happy reading weekend!

 

 

Antony Anderson
User Rank
Rookie
Re: discussion among professional bodies?
Antony Anderson   11/9/2013 5:19:24 AM
NO RATINGS
The IET (Used to be the IEE) has done some useful work on Electromagnetic Compatibility for functional safety. They also have a Functional Safety Network that anyone can join.

http://www.theiet.org/factfiles/emc/

See also this fact file:

http://www.theiet.org/factfiles/emc/emc-factfile.cfm

See also this factfile:

http://www.theiet.org/factfiles/emc/emc-factfile.cfm

esrnetw
User Rank
Rookie
Re: Toyota Failure
esrnetw   11/8/2013 8:52:56 PM
NO RATINGS
No need to kill everything, just the engine....leave the brakes and all safety systems intact. First rule of problem resolution - when you find yourself in a hole you can't get out of - stop digging then solve the problem!

W1PK
User Rank
Rookie
Re: Toyota Failure
W1PK   11/8/2013 7:08:44 PM
NO RATINGS
I think much of the discussion may be missing the point.

My previous experience with safety-critical systems was with burner safety controls, at Fireye, Inc.  We designed and verified our products under UL 372.  The centerpiece of regulatory approval was the Failure Mode Effects Analysis, in which we had to enumerate each of the physically possible failure modes of each of the components, and show by analysis or experiment that each of those failures would lead to a safe condition; the unit would either close the fuel valve or operate to spec.  If it continued to operate, then we had to hold that fault and enumerate every other possible fault in combination with the non-shutdown fault.  I've seen FMEA tables that ran to 1500 pages.  We had to do it.  No excuses.

Similarly, if the product had internal programming, we had to show that it was physically impossible for a software failure or memory corruption to cause an unsafe failure.

For safety-critical aircraft software there is RTCA/DO-178, which requires an excruciatingly rigorous development and validation process to eliminate all possibility of a dangerous bug.  This is not pie in the sky, this is legally mandatory.  And then, formally correct software can't be relied on if the hardware platform is buggy; for that there is RTCA/DO-254 to ensure that the hardware is logically correct.

Of course, any hardware platform can be correct at the time of manufacture and suffer a component failure in the field.  So we assume that every physically possible failure will occur at some time in the future; it must be comprehensively proven that any failure of any component will result in a safe condition; ideally, the failure should be immediately obvious so that repairs will be performed before a second hardware failure appears.

In order that airtight proof of design correctness and comprehensive failure mode effects analysis be possible, the design must be kept simple, so that it can be completely understood by its human designers and independent reviewers.  I can't emphasize that enough; it requires a certain ruthlessness to exclude anything from the product specification that will result in complexity.  The safety-critical subsystems must be physically separated from the convenience functions, and from dangerous external influences such as high-level electromagnetic interference.

Personally, I find it unforgivable for a vehicle to be designed in such a way that it's physically possible to open the throttle without the driver's foot supplying the force to do it.  If any part of the *mechanical* linkage between the gas pedal and the throttle fails, not even God should be capable of preventing the return spring from closing the throttle.  Similarly, putting the transmission lever or its equivalent in an electric car into neutral should physically disconnect the wheels from the power source, and it should not be possible for any component failure to prevent it.  There ought be a law.  Literally.

alex_m1
User Rank
CEO
The non-embedded community's view
alex_m1   11/8/2013 6:46:29 PM
NO RATINGS
The response of the non-embedded software community is also interesting: They claim the software development processes were bad , the tools we're bad and too low level for such a complex critical software , and the education of electronics engineers is also part here - because they are'nt taught proper software engineering is  and it shows.

Here's are the relevant discussions:

https://news.ycombinator.com/item?id=6695790

https://news.ycombinator.com/item?id=6636811

junko.yoshida
User Rank
Blogger
Re: Toyota Failure
junko.yoshida   11/8/2013 6:16:25 PM
NO RATINGS
I actually saw a thread on that very issue. While it sounds good, it might be problematic if everything is killed when your car is going at a certain speed.

junko.yoshida
User Rank
Blogger
Re: What happened at NASA?
junko.yoshida   11/8/2013 6:08:04 PM
NO RATINGS
To be fair to NASA, from what I understand it, they really didn't have as much time as Michael Barr did in looking into this problem. Besides, Barr said that he was able to build his work by picking up where NASA left off. So, NASA's work is not wasted. But at the same time, NASA also made it clear in its own report: "Absence of proof that ETCS-i has caused an unintended acceleration doesn't vindiate te system."

esrnetw
User Rank
Rookie
Toyota Failure
esrnetw   11/8/2013 5:48:44 PM
NO RATINGS
There has been a lot of ink used discussing the Toyota electronic throttle issue - however, no post so far has commented on the failure of Toyota to provide a kill button that kills the power to the system of everything else fails. It would seem that looking for a tow truck is much preferable to a runaway out of control vehicle with a panicked driver and pax!

jperlick
User Rank
Rookie
What happened at NASA?
jperlick   11/8/2013 5:26:43 PM
NO RATINGS
Hmmm..NASA did a long and expensive study on the reliability of the Toyota throttle control and didn't find anything wrong!  Makes me wonder if NASA is no longer the bastion of high performance, high reliability HW/SW design.  How is it that a consultant can find the problem but NASA cannot? 

I am disappointed in NASA! 

 

<<   <   Page 2 / 3   >   >>


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

Juggling a Cornucopia of Projects
Max Maxfield
1 Comment
I feel like I'm juggling a lot of hobby projects at the moment. The problem is that I can't juggle. Actually, that's not strictly true -- I can juggle ten fine china dinner plates, but ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
26 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 ...

Karen Field

July Cartoon Caption Contest: Let's Talk Some Trash
Karen Field
127 comments
Steve Jobs allegedly got his start by dumpster diving with the Computer Club at Homestead High in the early 1970s.

Jeremy Cook

Inspection Rejection: Why More Is Less in a Vision System
Jeremy Cook
3 comments
Albert Einstein has been quoted as saying, "Everything should be as simple as possible, but not simpler." I would never claim to have his level of insight -- or such an awesome head of ...

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)