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]> 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]] > Sent: Thursday, August 04, 2016 10:54 AM > To: [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]> > > 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]> > > > - > ---------------------------------------------------------------- > 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]> > > - > ---------------------------------------------------------------- > 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]> > - ---------------------------------------------------------------- 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]>
