Three rules of aviation relating to the Airbus –
1. Look what it's doing now! 2. It just did it again! 3. How do we make it stop doing that? Ghery S. Pettit From: [email protected] [mailto:[email protected]] On Behalf Of McInturff, Gary Sent: Monday, March 01, 2010 3:57 PM To: [email protected]; [email protected] Subject: RE: [PSES] Toyota -- Comment on Software and Electronics for Safety Ralph, When you get into designing things for the FAA, depending on the criticality of the system, it becomes almost impossible to use any CPU or von Nuemann architecture. Because of the V & V requirements (verification and validation) requirements for those systems CPU’s are usually replaced with PALS, ASICS and the lot when ever possible simply because there are a finite number of input states in the PAL, (and I would presume ASICs etc) and one can write test vectors for all input states and then measure the all the output states. Software state machines are often replaced with shift registers that decode specific outputs to insure the input into the system gives you one and only one output. Writing simple software for earthbound control equipment might be 10’s of thousands of dollars for simple things, for aircraft the scale goes to 100’s of thousands. If you look at all of the work that goes on in trying to keep our bottom’s from bouncing off runways it becomes apparent why airplanes take the time they do to get out of development and why they cost big money. None of that keeps things from going wrong though. The Airbus crash at the Paris air show a few years go back was a case of the software being smarter than the pilots and having full authority to override pilot decisions. As I understand it The pilots made a pass over the crowd at low and slow speeds. They got to the end of the pass saw the trees and tried to pull up, but the software looked at the flight envelope and said no because the low airspeed meant that they were at a critical point on the flight envelope and raising the nose at that speed would put it too close to the stall point of the aircraft. I certainly wasn’t involved in the crash investigation rather having just read this is some journal somewhere – so I certainly could have this wrong – but like I said – as I understand it. Thoughts for what is worth. Gary McInturff 208 635 8306 ________________________________ From: Ralph McDiarmid [mailto:[email protected]] Sent: Monday, March 01, 2010 2:42 PM To: [email protected] Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety It seems to me that the 'wrong position' is difficult to define and equally difficult to protect against. Would a watch-dog circuit always detect firmware departing from normal control flow into an unintended state? If the unintended state was caused by the instruction pointer fetching from the wrong address, then maybe a watchdog would always catch that error. In that state, I assume the microprocessor would begin executing instructions at random, never to return to its intended execution loop. _______________________________________ _____________________________________________ Ralph McDiarmid | Schneider Electric | Renewable Energies Business | CANADA | From: John Barnes <[email protected]> To: [email protected] List-Post: [email protected] List-Post: [email protected] List-Post: [email protected] Date: 03/01/2010 12:33 PM Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety ________________________________ Brian, Several years ago, in a workshop at one of the first Product Safety' Engineering Society (PSES) symposiums, the question came up: "How can you certify software for safety-critical applications?" One of the people in the audience answered "Treat the software as a switch with two positions, ON or OFF. Then ask yourself, what will happen if the switch is in the wrong position?" At that time our answer was that you need hardware to provide safety-- electronic, electrical, mechanical, or something. But don't trust software. With the advent of lead-free, RoHS-compliant electronics, I now don't trust electronics either. When it is *my* health or safety on the line, I ask: * What can happen if *any* one solder joint goes open? * What can happen if *any* two points within 10mm of each other-- that aren't separated by some kind of physical insulating barrier-- become shorted to one another? (But see "conductive anodic filaments", CAF, where short circuits can develop inside of lead-free printed circuit boards.) Because of the conversion to lead-free electronics, I don't trust *any* electronic device, or item with a high electronic content, manufactured after 2005. I'm only buying new (built after 2005) electronics if: 1. I can't find a suitable item manufactured before 2006 (maybe used, such as from E-bay). 2. I figure it will repay its purchase cost within 3 months (I believe that *most* lead-free electronics will last at least one year, versus 20+ years use that we can get from lead-based electronics). AND 3. It is not manufactured in Europe. If the only suitable product is manufactured in the European Union, which passed the RoHS Directive starting all of this mess, I will do without... For electronics manufactured since the beginning of 2006, I recommend to friends: * If it is AC powered. unplug it when it is not in use. * If it is battery powered, remove or disconnect the battery when it is not in use. I have been studying electronics for 49 years, and working fulltime in the electronics/computer industry for 37 years. I spent 2003 writing my books Robust Electronic Design Reference Book, Volumes I and II http://www.dbicorporation.com/book-out.htm <http://www.dbicorporation.com/book-out.htm> on how to design and develop electronic products and equipment. Since December 2004 I have been studying lead-free electronics, to see if there is a way to make high-quality, reliable, long-life electronics that are also RoHS-compliant. So far I haven't seen any way to meet both sets of requirements simultaneously... My 1,000+ page, nearly 4MB Bibliography for Designing Lead-Free, RoHS-Compliant, and WEEE-Compliant Electronics is at http://www.dbicorporation.com/rohsbib.htm <http://www.dbicorporation.com/rohsbib.htm> and covers over 250 books, over 220 PH. D. and Masters theses, and well over 15,875 papers, magazine articles, reports, web pages, etc. on these topics. John Barnes KS4GL, PE, NCE, NCT, ESDC Eng, ESDC Tech, PSE, SM IEEE dBi Corporation http://www.dbicorporation.com/ <http://www.dbicorporation.com/> - This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <[email protected]> All emc-pstc postings are archived and searchable on the web at: http://www.ieeecommunities.org/emc-pstc <http://www.ieeecommunities.org/emc-pstc> Graphics (in well-used formats), large files, etc. can be posted to that URL. Website: http://www.ieee-pses.org/ <http://www.ieee-pses.org/> Instructions: http://listserv.ieee.org/request/user-guide.html <http://listserv.ieee.org/request/user-guide.html> List rules: http://www.ieee-pses.org/listrules.html <http://www.ieee-pses.org/listrules.html> For help, send mail to the list administrators: Scott Douglas <[email protected]> Mike Cantwell <[email protected]> For policy questions, send mail to: Jim Bacher: <[email protected]> David Heald: <[email protected]> ________________________________________________________________________ This email has been scanned for SPAM content and Viruses by the MessageL abs Email Security System. ________________________________________________________________________ - This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <[email protected]> All emc-pstc postings are archived and searchable on the web at http://www.ieeecommunities.org/emc-pstc Graphics (in well-used formats), large files, etc. can be posted to that URL. Website: http://www.ieee-pses.org/ Instructions: http://listserv.ieee.org/request/user-guide.html List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <[email protected]> Mike Cantwell <[email protected]> For policy questions, send mail to: Jim Bacher <[email protected]> David Heald <[email protected]> - This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <[email protected]> All emc-pstc postings are archived and searchable on the web at http://www.ieeecommunities.org/emc-pstc Graphics (in well-used formats), large files, etc. can be posted to that URL. Website: http://www.ieee-pses.org/ Instructions: http://listserv.ieee.org/request/user-guide.html List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <[email protected]> Mike Cantwell <[email protected]> For policy questions, send mail to: Jim Bacher <[email protected]> David Heald <[email protected]> - This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <[email protected]> All emc-pstc postings are archived and searchable on the web at http://www.ieeecommunities.org/emc-pstc Graphics (in well-used formats), large files, etc. can be posted to that URL. Website: http://www.ieee-pses.org/ Instructions: http://listserv.ieee.org/request/user-guide.html List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <[email protected]> Mike Cantwell <[email protected]> For policy questions, send mail to: Jim Bacher <[email protected]> David Heald <[email protected]>
