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

[McCallum, Andy]

Most (well a lot) railway signalling is now software controlled. The first 
Solid State Interlocking (SSI) was introduced in the UK in the 1980's. Its 
widely used around the world. 

Andy

-Original Message-
From: Nick Williams [mailto:nick.willi...@conformance.co.uk] 
Sent: 05 August 2016 11:03
To: EMC-PSTC@LISTSERV.IEEE.ORG
Subject: Re: [PSES] SAFETTY FEATURES controlled by SOFTWARE

The problem with focusing on the code is that real world experience is that a 
high percentage of the failures which occur with software related safety are a 
failure of the original specification for what the software is supposed to do, 
not failures of the code to do what the programmer intended. Particular 
problems occur if the limits of operation of the equipment are not properly 
understood: a classic example being a passenger aircraft crash caused by the 
avionics being unable to detect when the aircraft wheels had hit the runway in 
very wet conditions due to aquaplaning whereas in the dry conditions under 
which the system was tested it worked perfectly. 

This is why standards which deal with software in safety related applications 
(including those derived from IEC 61508, and the medical devices software 
standard, IEC 62304) focus much more on the overall procedure for specifying 
and designing the software and then checking that the specification has been 
met, and are not overly prescriptive about language, structure or other 
detailed requirements for code. 

Nick. 


> On 4 Aug 2016, at 21:49, B Rowland  wrote:
> 
> 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 

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

[Nick Williams]

The problem with focusing on the code is that real world experience is that a 
high percentage of the failures which occur with software related safety are a 
failure of the original specification for what the software is supposed to do, 
not failures of the code to do what the programmer intended. Particular 
problems occur if the limits of operation of the equipment are not properly 
understood: a classic example being a passenger aircraft crash caused by the 
avionics being unable to detect when the aircraft wheels had hit the runway in 
very wet conditions due to aquaplaning whereas in the dry conditions under 
which the system was tested it worked perfectly. 

This is why standards which deal with software in safety related applications 
(including those derived from IEC 61508, and the medical devices software 
standard, IEC 62304) focus much more on the overall procedure for specifying 
and designing the software and then checking that the specification has been 
met, and are not overly prescriptive about language, structure or other 
detailed requirements for code. 

Nick. 


> On 4 Aug 2016, at 21:49, B Rowland  wrote:
> 
> 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 

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

[Pawson, James]

Windows for Submarines
http://www.theregister.co.uk/2008/12/16/windows_for_submarines_rollout/
Good job our nuclear "deterrent" isn't safety critical!


From: Nyffenegger, Dave [mailto:dave.nyffeneg...@bhemail.com]
Sent: 04 August 2016 19:46
To: EMC-PSTC@LISTSERV.IEEE.ORG
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: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