I would recommend developing a robust program for testing electromagnetic susceptibility for any system that uses software for safety functions. You may be able to accept transient behavior for computers and other products, but not for safety systems. It will likely not be acceptable to have an event that requires user action for recovery.
I have seen things as simple as having ESD put an IC into a latch up condition. ESD or EFT could cause other transient effects with undesirable results. Depending on the inputs to the safety system, radiated or magnetic field immunity tests may be required at elevated levels to ensure robustness. I'll also add to the recommendation others have given for using a state machine. In my opinion, it makes review and testing much easier. You will likely want to make sure that if anything does go wrong, the system fails into a safe state, and that can be easier to check in a state machine where there are only a limited number of states possible. Ted Eckert Microsoft Corporation The opinions expressed are my own and do not necessarily reflect those of my employer. -----Original Message----- From: Brian O'Connell [mailto:oconne...@tamuracorp.com] Sent: Wednesday, August 3, 2016 12:03 PM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE Would suspect principle reason is that FPGAs and ASICS, when viewed as a 'code block', tend to be deterministic and relatively easy to map a finite number of paths, so the coverage analysis comes as part of the design, and more so when done as a pure state machine. That said, VHDL/system C *is* code, and DO 178/254 and EN50129 have discussed this stuff (latter is for trains). Military software safety tends to suck, because no matter what happens, the end result almost always needs the weapon system to be able to say "boom". That is, the mission-first philosophy. PALs and ROMs are essentially pure state machines. And Von Neumann stuff, cannot be eliminated for many designs, as it tends to drive or receive from a parallel device where you cannot keep the control loop closed. So the only truly non Von Neumann hardware would be ASICs and FPGAs, but there is still a microcontroller or DSP core in there that is a serial Von Neumann machine. So code safety assessment remains a dog's breakfast. Woof. Brian -----Original Message----- From: Gary McInturff [mailto:gary.mcintu...@esterline.com] Sent: Wednesday, August 03, 2016 11:06 AM To: Brian O'Connell; EMC-PSTC@LISTSERV.IEEE.ORG Cc: Gary McInturff Subject: RE: [PSES] SAFETTY FEATURES controlled by ....SOFTWARE Well software types are devious by nature and probably one of the reasons the FAA kinda-sorta strong arms developers in to using ASICS, PALS and EPROMS and the like. The theory is that this devices are not Von Neumann architecture with various entry/exit decision points that lead to a plethora of test cases, and as such have a finite number of test vectors which have exact outputs which can be measured and verified. 2^N (number of data pins). Test vectors can be written and run which report the output state of the device exactly and repeatably. They also have a software standard that would be used for multipurpose processors etc - but as I understand it is really pretty ugly and intensive. One might consider putting the safety critical features inside a PAL etc. -----Original Message----- From: Brian O'Connell [mailto:oconne...@tamuracorp.com] Sent: Wednesday, August 03, 2016 10:10 AM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: [EXTERNAL] 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 <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> - ---------------------------------------------------------------- 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>
