There are a few methods to use software as a safety system, making it approach the safety of hardware:
* Use redundancy (2 processors - 2 different pieces of software and have the two processes communicate on their status (hardware line with function safe/unsafe) AND or OR the results in hardware to create a desired potential hazardous signal (fe. CHARGE) * Use assembly code if possible * Use proven hardware (Z80 8080?) ; a method used in space vehicles * Separate safety related code from operational code in design. * Use software analysis tools to find flaws in code, unusual constructs, lack in comment, uninitialized variables and reduce complexity in general. * Use the KISS method (Keep IT Simple and Stupid) , one monitored function per software unity only * Disable all unused hardware in the processor * Fill all unused program memory with defined code * Making a reliable watchdog function is a challenge on its own. * Use a checksum method over the software code before allowing a critical function (CHARGE!) * Initialize all internal RAM, and check if something odd happens at each start-up * Checksum RAM values before shutdown, and verify on start-up * Pull up (or down) all uP outputs, so as a fail in software output initializations (I assume all uP outputs are initially input only) will not create a hazardous situation. * Do not allow for external code (internet picks, even simple routines) * Test, test and test again. * Test again by someone else * Lastly: Fix the release of compiler assembler and linker the code was written and compiled with, and do not allow any modification to the system the software is created on (switch off Windows updates, preferably disconnect from the internet) That said, the quality of the software product is inverse with its complexity, it's easy to create a software system that cannot be analysed for Regarding single fault analysis, I think the firmware and associated hardware should be considered as one component. Create a technical software construction file on how you did it. Regards, Ing. Gert Gremmen Approvals manager From: Bolintineanu, Constantin [mailto:[email protected]] Sent: Wednesday 3 August 2016 16:33 To: [email protected] 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 <[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) <http://www.ieee-pses.org/list.html> 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]>
