RE: [PSES] Toyota -- Comment on Software and Electronics for Safety
Bill: I had always assumed similar to you; that the plane overshot the desired touchdown point and then just did a rather nice flat float into the trees. However, the document said that this was a take-off crash, with several factors added to make it more difficult (center of gravity, engine power, hydraulic fault). The report talks about severe pitch and roll issues (>30 degree nose up) that happened before the video record that we see. The preceding seconds of that take-off was a very wild event; it would be interesting to see the full video. Ed Price ed.pr...@cubic.com mailto:ed.pr...@cubic.com> WB6WSN NARTE Certified EMC Engineer Electromagnetic Compatibility Lab Cubic Defense Applications San Diego, CA USA 858-505-2780 Military & Avionics EMC Is Our Specialty From: emc-p...@ieee.org [mailto:emc-p...@ieee.org] On Behalf Of Bill Owsley Sent: Tuesday, March 02, 2010 6:45 PM To: Pettit, Ghery; John M Woodgate; EMC-PSTC Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety I think I recall that video from years ago. If so, I thought it came in high and stayed high when it should have touched down on pavement WAY earlier which would have triggered the reverse thrusters and brakes, etc. with a final rollout at the camera location for successful landing -ta dah! It looked more like an altitude setting wrong, and the plane stayed on the glide path but the low wing configuration has interesting phenomena of 'floating' on the pressure wave just before touch down, makes for a softer more often touchdown, but that takes correct altitude settings and throttle back and such to drop through the float. The ILS should have indicated beginning runway and initiated such proceedings, or too high to make runway and gone to flyby settings. Maybe an unaccounted for tailwind, and several other "assumed" nominal settings could have conspired to have sent the airplane further down the runway than intended. We should have seen a plane passing by on afterburners, or a fine rollout. Maybe the crew was the "first" ones to fly a recent purchase off the ground, sort of like the "second" crew the drove the fancy luxury liner into the blast barrier at near launch speed that we seen the photos of. - Bill In the event of a national emergency, click on the following links to provide directions to your duly elected mis-representative. http://www.usa.gov/Contact/Elected.shtml or... https://writerep.house.gov/writerep/welcome.shtml http://www.senate.gov/general/contact_information/senators_cfm.cfm From: "Pettit, Ghery" To: John M Woodgate ; EMC-PSTC Sent: Mon, March 1, 2010 7:38:03 PM Subject: RE: [PSES] Toyota -- Comment on Software and Electronics for Safety This has been well discussed in aviation circles. The fly by wire systems in the Airbus will not allow the pilots direct control. The pilot tells the computer what he wants to do and the flight rules programmed into the computer limit the aircraft to a certain performance envelope. In the Paris incident the pilots tried to exceed the performance envelope to clear the trees and the computer wouldn't let them. I've seen video of the crash. Not good. Ghery S. Pettit From: emc-p...@ieee.org [mailto:emc-p...@ieee.org] On Behalf Of John M Woodgate Sent: Monday, March 01, 2010 4:26 PM To: EMC-PSTC Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety In message , "McInturff, Gary" writes >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. Even so, if it is true, it shows that the software just wasn't intelligent, or, more likely, informed enough to cope with the situation. It didn't know about the trees, but if it did know, it should have allowed a low-angle climb to clear them. It must be a general principle that if a quasi-intelligent system does not know a key fact, it may implement a dangerous sequence of actions. What you don't know will kill you. -- This is my travelling signature, adding no superfluous mass. John M Woodgate - 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 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. Web
Re: [PSES] Toyota -- Comment on Software and Electronics for Safety
I think I recall that video from years ago. If so, I thought it came in high and stayed high when it should have touched down on pavement WAY earlier which would have triggered the reverse thrusters and brakes, etc. with a final rollout at the camera location for successful landing -ta dah! It looked more like an altitude setting wrong, and the plane stayed on the glide path but the low wing configuration has interesting phenomena of 'floating' on the pressure wave just before touch down, makes for a softer more often touchdown, but that takes correct altitude settings and throttle back and such to drop through the float. The ILS should have indicated beginning runway and initiated such proceedings, or too high to make runway and gone to flyby settings. Maybe an unaccounted for tailwind, and several other "assumed" nominal settings could have conspired to have sent the airplane further down the runway than intended. We should have seen a plane passing by on afterburners, or a fine rollout. Maybe the crew was the "first" ones to fly a recent purchase off the ground, sort of like the "second" crew the drove the fancy luxury liner into the blast barrier at near launch speed that we seen the photos of. - Bill In the event of a national emergency, click on the following links to provide directions to your duly elected mis-representative. http://www.usa.gov/Contact/Elected.shtml or... https://writerep.house.gov/writerep/welcome.shtml http://www.senate.gov/general/contact_information/senators_cfm.cfm From: "Pettit, Ghery" To: John M Woodgate ; EMC-PSTC Sent: Mon, March 1, 2010 7:38:03 PM Subject: RE: [PSES] Toyota -- Comment on Software and Electronics for Safety This has been well discussed in aviation circles. The fly by wire systems in the Airbus will not allow the pilots direct control. The pilot tells the computer what he wants to do and the flight rules programmed into the computer limit the aircraft to a certain performance envelope. In the Paris incident the pilots tried to exceed the performance envelope to clear the trees and the computer wouldn't let them. I've seen video of the crash. Not good. Ghery S. Pettit From: emc-p...@ieee.org [mailto:emc-p...@ieee.org] On Behalf Of John M Woodgate Sent: Monday, March 01, 2010 4:26 PM To: EMC-PSTC Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety In message , "McInturff, Gary" writes >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. Even so, if it is true, it shows that the software just wasn't intelligent, or, more likely, informed enough to cope with the situation. It didn't know about the trees, but if it did know, it should have allowed a low-angle climb to clear them. It must be a general principle that if a quasi-intelligent system does not know a key fact, it may implement a dangerous sequence of actions. What you don't know will kill you. -- This is my travelling signature, adding no superfluous mass. John M Woodgate - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald: - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald: - This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e
RE: [PSES] Toyota -- Comment on Software and Electronics for Safety
I believe aircraft (at least, fighters) had a "War Emergency" throttle setting that was accessed by breaking some glass by pushing the throttle (and prop and mixture?) forward extra hard. A "give it all it's got, to heck with longevity" setting that was not normally used. It would be interesting to read the French equivalent of the US NTSB report on that airbus crash. In any case, every comment I've read blames the plane for not allowing the pilots to push the envelope a bit trying to avoid those trees. Ghery S. Pettit From: emc-p...@ieee.org [mailto:emc-p...@ieee.org] On Behalf Of John Woodgate Sent: Tuesday, March 02, 2010 1:46 PM To: emc-p...@ieee.org Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety In message <4c5e6457cd7911469a07260381288c2860f54...@orsmsx502.amr.corp.intel.com>, dated Mon, 1 Mar 2010, "Pettit, Ghery" writes: > In the Paris incident the pilots tried to exceed the performance >envelope to clear the trees and the computer wouldn't let them. I've >seen video of the crash. Not good. So the computer crashed the plane from level flight to prevent it stalling and crashing. But the performance envelope limits surely have a 'safety factor' built in, so the plane might not have stalled if the pilots tried to gain JUST enough height, not pulled the stick back regardless. I think a re-think is indicated. Didn't WW2 US naval craft have an engine telegraph position 'Flank speed', aka 'GTHOH', which 'pushed the envelope' quite hard? -- OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK I should be disillusioned, but it's not worth the effort. - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald: - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald:
Re: [PSES] Toyota -- Comment on Software and Electronics for Safety
In message <4c5e6457cd7911469a07260381288c2860f54...@orsmsx502.amr.corp.intel.com>, dated Mon, 1 Mar 2010, "Pettit, Ghery" writes: > In the Paris incident the pilots tried to exceed the performance >envelope to clear the trees and the computer wouldn't let them. I've >seen video of the crash. Not good. So the computer crashed the plane from level flight to prevent it stalling and crashing. But the performance envelope limits surely have a 'safety factor' built in, so the plane might not have stalled if the pilots tried to gain JUST enough height, not pulled the stick back regardless. I think a re-think is indicated. Didn't WW2 US naval craft have an engine telegraph position 'Flank speed', aka 'GTHOH', which 'pushed the envelope' quite hard? -- OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK I should be disillusioned, but it's not worth the effort. - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald:
RE: [PSES] Toyota -- Comment on Software and Electronics for Safety
Yes, it is. And jet engines don’t spool up as quickly as piston engines. Ghery S. Pettit From: emc-p...@ieee.org [mailto:emc-p...@ieee.org] On Behalf Of ralph.mcdiar...@ca.schneider-electric.com Sent: Monday, March 01, 2010 4:49 PM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety I remember that video and it seemed to me, a layman, that the aircraft was in a flared attitude as it would be just before touchdown. It looked to me as if it intentionally landed well past the end of the runway, into the trees. To climb, isn't a large increase in thrust necessary? ___ _ Ralph McDiarmid | Schneider Electric | Renewable Energies Business | CANADA | From: "Pettit, Ghery" To: EMC-PSTC@LISTSERV.IEEE.ORG List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org Date: 03/01/2010 04:39 PM Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety This has been well discussed in aviation circles. The fly by wire systems in the Airbus will not allow the pilots direct control. The pilot tells the computer what he wants to do and the flight rules programmed into the computer limit the aircraft to a certain performance envelope. In the Paris incident the pilots tried to exceed the performance envelope to clear the trees and the computer wouldn't let them. I've seen video of the crash. Not good. Ghery S. Pettit From: emc-p...@ieee.org [mailto:emc-p...@ieee.org <mailto:emc-p...@ieee.org> ] On Behalf Of John M Woodgate Sent: Monday, March 01, 2010 4:26 PM To: EMC-PSTC Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety In message , "McInturff, Gary" writes >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. Even so, if it is true, it shows that the software just wasn't intelligent, or, more likely, informed enough to cope with the situation. It didn't know about the trees, but if it did know, it should have allowed a low-angle climb to clear them. It must be a general principle that if a quasi-intelligent system does not know a key fact, it may implement a dangerous sequence of actions. What you don't know will kill you. -- This is my travelling signature, adding no superfluous mass. John M Woodgate - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald: - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald: 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 discu
Re: [PSES] Toyota -- Comment on Software and Electronics for Safety
I remember that video and it seemed to me, a layman, that the aircraft was in a flared attitude as it would be just before touchdown. It looked to me as if it intentionally landed well past the end of the runway, into the trees. To climb, isn't a large increase in thrust necessary? ___ _ Ralph McDiarmid | Schneider Electric | Renewable Energies Business | CANADA | From: "Pettit, Ghery" To: EMC-PSTC@LISTSERV.IEEE.ORG List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org Date: 03/01/2010 04:39 PM Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety This has been well discussed in aviation circles. The fly by wire systems in the Airbus will not allow the pilots direct control. The pilot tells the computer what he wants to do and the flight rules programmed into the computer limit the aircraft to a certain performance envelope. In the Paris incident the pilots tried to exceed the performance envelope to clear the trees and the computer wouldn't let them. I've seen video of the crash. Not good. Ghery S. Pettit From: emc-p...@ieee.org [mailto:emc-p...@ieee.org <mailto:emc-p...@ieee.org> ] On Behalf Of John M Woodgate Sent: Monday, March 01, 2010 4:26 PM To: EMC-PSTC Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety In message , "McInturff, Gary" writes >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. Even so, if it is true, it shows that the software just wasn't intelligent, or, more likely, informed enough to cope with the situation. It didn't know about the trees, but if it did know, it should have allowed a low-angle climb to clear them. It must be a general principle that if a quasi-intelligent system does not know a key fact, it may implement a dangerous sequence of actions. What you don't know will kill you. -- This is my travelling signature, adding no superfluous mass. John M Woodgate - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald: - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald: 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 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://ww
RE: [PSES] Toyota -- Comment on Software and Electronics for Safety
This has been well discussed in aviation circles. The fly by wire systems in the Airbus will not allow the pilots direct control. The pilot tells the computer what he wants to do and the flight rules programmed into the computer limit the aircraft to a certain performance envelope. In the Paris incident the pilots tried to exceed the performance envelope to clear the trees and the computer wouldn't let them. I've seen video of the crash. Not good. Ghery S. Pettit From: emc-p...@ieee.org [mailto:emc-p...@ieee.org] On Behalf Of John M Woodgate Sent: Monday, March 01, 2010 4:26 PM To: EMC-PSTC Subject: Re: [PSES] Toyota -- Comment on Software and Electronics for Safety In message , "McInturff, Gary" writes >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. Even so, if it is true, it shows that the software just wasn't intelligent, or, more likely, informed enough to cope with the situation. It didn't know about the trees, but if it did know, it should have allowed a low-angle climb to clear them. It must be a general principle that if a quasi-intelligent system does not know a key fact, it may implement a dangerous sequence of actions. What you don't know will kill you. -- This is my travelling signature, adding no superfluous mass. John M Woodgate - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald: - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald:
Re: [PSES] Toyota -- Comment on Software and Electronics for Safety
In message , "McInturff, Gary" writes >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. Even so, if it is true, it shows that the software just wasn't intelligent, or, more likely, informed enough to cope with the situation. It didn't know about the trees, but if it did know, it should have allowed a low-angle climb to clear them. It must be a general principle that if a quasi-intelligent system does not know a key fact, it may implement a dangerous sequence of actions. What you don't know will kill you. -- This is my travelling signature, adding no superfluous mass. John M Woodgate - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald:
RE: [PSES] Toyota -- Comment on Software and Electronics for Safety
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: emc-p...@ieee.org [mailto:emc-p...@ieee.org] On Behalf Of McInturff, Gary Sent: Monday, March 01, 2010 3:57 PM To: ralph.mcdiar...@ca.schneider-electric.com; EMC-PSTC@LISTSERV.IEEE.ORG 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:ralph.mcdiar...@ca.schneider-electric.com] Sent: Monday, March 01, 2010 2:42 PM To: EMC-PSTC@LISTSERV.IEEE.ORG 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 To: EMC-PSTC@LISTSERV.IEEE.ORG List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org 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
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:ralph.mcdiar...@ca.schneider-electric.com] Sent: Monday, March 01, 2010 2:42 PM To: EMC-PSTC@LISTSERV.IEEE.ORG 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 To: EMC-PSTC@LISTSERV.IEEE.ORG List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org 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
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 To: EMC-PSTC@LISTSERV.IEEE.ORG List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org List-Post: emc-pstc@listserv.ieee.org 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 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 mai
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 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 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/ - 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 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 Mike Cantwell For policy questions, send mail to: Jim Bacher: David Heald:
