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 <emc-p...@ieee.org <mailto:emc-p...@ieee.org>>
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 <sdoug...@ieee.org <mailto:sdoug...@ieee.org>>
Mike Cantwell <mcantw...@ieee.org <mailto:mcantw...@ieee.org>>
For policy questions, send mail to:
Jim Bacher <j.bac...@ieee.org <mailto:j.bac...@ieee.org>>
David Heald <dhe...@gmail.com <mailto:dhe...@gmail.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 <emc-p...@ieee.org>
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 <sdoug...@ieee.org>
Mike Cantwell <mcantw...@ieee.org>
For policy questions, send mail to:
Jim Bacher: <j.bac...@ieee.org>
David Heald: <dhe...@gmail.com>
