Windows for Submarines http://www.theregister.co.uk/2008/12/16/windows_for_submarines_rollout/ Good job our nuclear "deterrent" isn't safety critical! </sarcasm>
From: Nyffenegger, Dave [mailto:[email protected]] Sent: 04 August 2016 19:46 To: [email protected] Subject: Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE The Windows licenses prohibit use in safety critical applications. Wouldn't want that BSOD and having to re-boot in order to re-start the airplane engine at 10K feet. Still not a comfortable feeling for the average traveler to see that fatal error - reboot screen or what-have you on the seatback entertainment monitor while flying on the 777 et. al. -Dave From: B Rowland [mailto:[email protected]] Sent: Thursday, August 04, 2016 2:33 PM To: Nyffenegger, Dave Cc: [email protected]<mailto:[email protected]> Subject: Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE Hi List-colleagues; I think, if the safety-related functions are life-critical, they need to be written in a "provably-correct" language/environment, like ADA, or some equivalent. And, of course, that also means that such functionality needs to be isolated from software that is NOT provably-correct (is Windows "provably-correct" ?)... In any case, life-critical systems need to be, at least, redundant, with fail-safe shutdown if the processes do not agree at timed checkpoints, and also have hardware-based watchdog timers (sometimes built-in to the microcontroller, itself) to guarantee continued function. Furthermore, it is also typical that the software that runs on the redundant processors is written by different teams, so that an error in a program on one "side" is not duplicated in the other half/third of the redundant CPUs. Since, as some have pointed out, it is readily-accomplished to have a provably-correct hardware implementation of the safety functions that are "at the edge" of the system, FPGA's, PALs, etc., with ROM, or check-summed-on-load-firmware, are much more reliable.... In another discussion that I had, a while back, we even discussed how to ensure that the semiconductor devices, at the safety interface, are made reliable-enough to allow proper operation, even in the typical fail-short conditions. I think that this is why we have relays costing > $1000 used in train/subway applications ;-) Cheers, Barry Rowland Muenchen, Bayern On 04/08/2016, at 18:25 , "Nyffenegger, Dave" <[email protected]<mailto:[email protected]>> wrote: Which is essentially what UL 1998 requires for the product design. I agree with keeping software/programmable devices out of the safety business as much as possible so you can skip the significant engineering investment required to do it properly. -Dave From: Carl Newton [mailto:[email protected]<http://gmail.com/>] Sent: Thursday, August 04, 2016 10:54 AM To: [email protected]<mailto:[email protected]> Subject: Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE My experience with UL Medical (as an example) is that their position is that software fails 100% of the time from a safety point of view (and I agree with that view). The manufacturer would have to prove to the lab that it is fail-safe, which is probably not a desirable task on the part of the designers, and may not be possible from a practical point of view. I've been told that in those unusual cases where software/firmware has been allowed as protection against hazards is when the software/firmware is completely separated from any other system software (standalone) within the hardware architecture so that it cannot be corrupted and will have only that one dedicated function. Carl On 8/3/2016 10:32 AM, Bolintineanu, Constantin wrote: Dear Colleagues, I would like to kindly ask those who have an extensive experience regarding the above subject, to share their opinion about the following aspect: Having a circuit which is charging a battery, and having it controlled and protected by SOFTWARE ONLY from the point of view of CHARGING , DISCHARGING, OVERCHARGING, 1. How do you think that SINGLE FAULT CONDITIONS shall be applied? (without SOFTWARE working at all? Or by providing a fault on the component where the SOFTWARE is stored? OR BOTH 2. Which conditions do you think that shall be imposed to the software and/or to the memory in which it is stored? Any other suggestions/observations/comments are more than welcome. Sincerely, Constantin Bolintineanu P.Eng. ________________________________ This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments. - ---------------------------------------------------------------- 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]<mailto:[email protected]>> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe)<http://www.ieee-pses.org/list.html> List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <[email protected]<mailto:[email protected]>> Mike Cantwell <[email protected]<mailto:[email protected]>> For policy questions, send mail to: Jim Bacher <[email protected]<mailto:[email protected]>> David Heald <[email protected]<mailto:[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]<mailto:[email protected]>> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe)<http://www.ieee-pses.org/list.html> List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <[email protected]<mailto:[email protected]>> Mike Cantwell <[email protected]<mailto:[email protected]>> For policy questions, send mail to: Jim Bacher <[email protected]<mailto:[email protected]>> David Heald <[email protected]<mailto:[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]<mailto:[email protected]>> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe)<http://www.ieee-pses.org/list.html> List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <[email protected]<mailto:[email protected]>> Mike Cantwell <[email protected]<mailto:[email protected]>> For policy questions, send mail to: Jim Bacher <[email protected]<mailto:[email protected]>> David Heald <[email protected]<mailto:[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]<mailto:[email protected]>> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe)<http://www.ieee-pses.org/list.html> List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <[email protected]<mailto:[email protected]>> Mike Cantwell <[email protected]<mailto:[email protected]>> For policy questions, send mail to: Jim Bacher <[email protected]<mailto:[email protected]>> David Heald <[email protected]<mailto:[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.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) 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]>
