Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE

[B Rowland]

Indeed, Brian, there is a difference between a provably-correct code block, and 
actual execution of the code, in other than a dedicated run-time, without 
interrupts, or real-time OS, or … interesting point about the core, whether it 
has been proven to execute correctly, in every possible case ;-)  That's a 
couple of test vectors, no?

Barry




On  04/08/2016, at 21:23 , Brian O'Connell  wrote:

> Whom considers Ada (the language name is not an acronym) provably correct? 
> How do you prove the program is deterministic? What if a Verification 
> Condition is not proven? Is the code incorrect? Is the assertion not correct 
> or incomplete? Does P = NP ? SPARK 2014 did attempt to address some of this 
> stuff, BTW.
> 
> Do not think that we will find answers to these questions in ISO8652. What 
> Ada does provide is a formalized programming method for concurrency + design 
> by contract, which offer a little more hope for code safety and test coverage.
> 
> The weakness for all human code solutions is a provable processor core where 
> the assumption is a provable algorithm. If a static evaluation indicates a 
> deterministic algorithm, and if a contract violation occurs at runtime, what 
> is 'wrong'? The language? The Compiler? The design assumptions? The processor 
> core? Once you get past Ada (or any other language) compile-time protection, 
> you return to the electronic jungle where you are part of the food chain.
> 
> Brian
> 
> 
> From: B Rowland [mailto:bfr...@direct.ca] 
> Sent: Thursday, August 04, 2016 11:33 AM
> To: EMC-PSTC@LISTSERV.IEEE.ORG
> 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
> 
> -
> 
> 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.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 
> 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.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 
Mike Cantwell 

Re: [PSES] SAFETY FEATURES controlled by ....SOFTWARE

[Brian Gregory]

 Just like CE Compliance, the scope statement is the key.  OEM's should state 
carefully where and how one does these things:the best use of language is not 
to say "it's SAFE" (unless you're a paid umpire).  I counsel my customers to 
say that products have been tested to be in compliance with the proper 
component (safety) standard(s).  Even Intertek and UL stay far away from the 
word "safe." "Safety" testing is done by product standard.  UL 508 and the like 
have sections to deal with control systems.  The best I've seen was actually in 
NFPA 79.  Woodward's nice generation control PLCs are product certified to UL 
508.  I consider this primary safety (against, fire, shock, etc.), and all 
please note that safety of control systems has been termed "Functional Safety." 
 Leave the software out of it for now. How one establishes safety of control 
systems (which run the software), is a certification to IEC 61508.61508 calls 
the control systems (and potentially, sensors):  Functional Safety of 
Electrical/Electronic/Programmable Electronic Safety-related Systems (E/E/PE, 
or E/E/PES).  Woodward generation control systems (like Mironet+) cite SIL-3 
certification for one example.  UL 1998 is still around, but in five years of 
searching, I've not found any products certified to it. There are some good 
presentations, UL and MTL Instruments are the best I've seen so far.   MTL's 
starts simple with terms like ALARP As Little As Realistically 
Practicable and concepts and goes into some level of detail for 
calculating MTBF, "dangerous failure rates" and PFD averages. MTL certifies 
systems and sensors to 61508, apparently.  Don't let the discussions of risk 
assessment/analysis make you crazy, that's just what they want!  UL's 
presentation is more friendly, far reaching and less detailed.  Slide # 19 
lists all the relevant standards from IEC, ISO, etc. Give it whirl, and watch 
your terminology! "Colorado" Brian GregoryPower Plant Electrical 
Engineer,Leidos, Inc.
720-450-4933

-- Original Message --
From: "Brian O'Connell" 
To: EMC-PSTC@LISTSERV.IEEE.ORG
Subject: Re: [PSES] SAFETTY FEATURES controlled by SOFTWARE
Date: Wed, 3 Aug 2016 16:37:02 +

Please beat a rapid and clear path to the local expert at your preferred 
conformity assessment body. In the meantime, read UL1998, IEC61508, MISRA, and 
perhaps UL991 for FIT. And there is another IEC standard for power systems SIL 
that cannot remember.

As for my employer's stuff - my 'tactic' has been to prove that the code is NOT 
a safety-critical component, rather than do a certification that plays 
probabilistic games with the "likelihood of occurrence".

Brian


From: Bolintineanu, Constantin [mailto:cbolintine...@tycoint.com] 
Sent: Wednesday, August 03, 2016 7:33 AM
To: EMC-PSTC@LISTSERV.IEEE.ORG
Subject: [PSES] SAFETTY FEATURES controlled by SOFTWARE


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 

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 
Mike Cantwell  
For policy questions, send mail to:
Jim 

Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE

[Brian O'Connell]

Whom considers Ada (the language name is not an acronym) provably correct? How 
do you prove the program is deterministic? What if a Verification Condition is 
not proven? Is the code incorrect? Is the assertion not correct or incomplete? 
Does P = NP ? SPARK 2014 did attempt to address some of this stuff, BTW.

Do not think that we will find answers to these questions in ISO8652. What Ada 
does provide is a formalized programming method for concurrency + design by 
contract, which offer a little more hope for code safety and test coverage.

The weakness for all human code solutions is a provable processor core where 
the assumption is a provable algorithm. If a static evaluation indicates a 
deterministic algorithm, and if a contract violation occurs at runtime, what is 
'wrong'? The language? The Compiler? The design assumptions? The processor 
core? Once you get past Ada (or any other language) compile-time protection, 
you return to the electronic jungle where you are part of the food chain.

Brian


From: B Rowland [mailto:bfr...@direct.ca] 
Sent: Thursday, August 04, 2016 11:33 AM
To: EMC-PSTC@LISTSERV.IEEE.ORG
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

-

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.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 
Mike Cantwell 

For policy questions, send mail to:
Jim Bacher:  
David Heald: 

Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE

[Nyffenegger, Dave]

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:bfr...@direct.ca]
Sent: Thursday, August 04, 2016 2:33 PM
To: Nyffenegger, Dave
Cc: EMC-PSTC@LISTSERV.IEEE.ORG
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" 
> 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:emcl...@gmail.com]
Sent: Thursday, August 04, 2016 10:54 AM
To: EMC-PSTC@LISTSERV.IEEE.ORG
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 
>

All emc-pstc postings are archived and searchable on the web at: 

Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE

[B Rowland]

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"  
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:emcl...@gmail.com] 
> Sent: Thursday, August 04, 2016 10:54 AM
> To: EMC-PSTC@LISTSERV.IEEE.ORG
> 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 
> 
> 
> 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 
> Mike Cantwell 
> 
> For policy questions, send mail to:
> Jim 

Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE

[Nyffenegger, Dave]

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:emcl...@gmail.com]
Sent: Thursday, August 04, 2016 10:54 AM
To: EMC-PSTC@LISTSERV.IEEE.ORG
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 
>

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 >
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.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 >
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.ieee-pses.org/emc-pstc.html

Attachments are not permitted but the IEEE PSES Online Communities site at 

Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE

[Richard Nute]

> my 'tactic' has been to
> prove that the code is NOT a safety-critical
component 

Amen!

Rich

-

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.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 
Mike Cantwell 

For policy questions, send mail to:
Jim Bacher:  
David Heald: 

Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE

[Carl Newton]

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 >


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 >
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.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 
Mike Cantwell 

For policy questions, send mail to:
Jim Bacher:  
David Heald: 

Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE

[Michael Derby]

I guess you would get a similar answer from Volkswagen these days.   :-)


Michael.


-Original Message-
From: Brian O'Connell [mailto:oconne...@tamuracorp.com] 
Sent: 03 August 2016 18:10
To: EMC-PSTC@LISTSERV.IEEE.ORG
Subject: Re: [PSES] SAFETTY FEATURES controlled by SOFTWARE

Dear Hardware People on the third rock from Sol,

Software beings (self included) are idiotically clever and tend to be rather
subversive. We can devise profoundly evil schemes that can 'go around' fault
conditions in electrical components that forces our equipment to pump out
giggle watts of power while the surrounding creation melts down.

Pro-tips for future compliance engineers:
0. Never trust any software types; not even a single one among us. If your
significant other is a software engineer, learn to sleep with eyes open.
1. learn how to read code like a book (which means you will need to
understand the language's basic syntax and structural characteristics).
2. learn how to run code in an emulator that can run under fully static
clock conditions.
3. learn how to determine code coverage.
4. carry a large hammer to meetings with the s/w dev team.

Brian


From: Richard Nute [mailto:ri...@ieee.org] 
Sent: Wednesday, August 03, 2016 9:41 AM
To: EMC-PSTC@LISTSERV.IEEE.ORG
Subject: Re: [PSES] SAFETTY FEATURES controlled by SOFTWARE

I have virtually no experience in software safety.  I'm a hardware guy.

I suggest simulating failures in the sensors (hardware) that gives the
software info about what state the battery is in.  And, simulating failures
of the hardware controlling the charging, discharging, and overcharging the
battery.  In this way, you have accounted for the worst-case failures of
both the hardware and the software.  

Rich


From: Bolintineanu, Constantin [mailto:cbolintine...@tycoint.com] 
Sent: Wednesday, August 03, 2016 7:33 AM
To: EMC-PSTC@LISTSERV.IEEE.ORG
Subject: [PSES] SAFETTY FEATURES controlled by SOFTWARE


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 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.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 
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.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 
Mike Cantwell 

For policy questions, send mail to:
Jim Bacher:  
David Heald: