Hello Brian, ISPCE has had some coverage of code safety, but it is typically in the medical track. This is one area where code review has been standard for some time. However, I have found attendance for the medical presentations to be among the lowest for any of the ISPCE presentations. Personally, I go to medical presentations to try to broaden my understanding of safety. Even though I don't handle medical products, there are topics, such as software safety, that I find can provide insight to issues I do face with my own product lines.
ISPCE is dependent on voluntary submittals. The technical program committee does occasionally try to solicit specific subjects, but they cannot compel authors to write on topics. The bulk of the presenters from industry come from the computer and information technology industries. These presenters come from a world where companies avoid having any safety function in software. Wearable devices are designed and marketed to avoid being medical devices. They are "fitness bands" or "smart watches", but not medical devices. Getting FDA approval is challenging enough. Having to do a full safety review of code can slow down product development to a crawl. Industry presenters also have to be careful that anything they present may either disclose confidential information or may not pass review from their legal department. The second largest group of presenters at ISPCE come from the various test laboratories, and they are likely to provide presentations on topics that their labs can sell as test services. Only a few do software safety and they haven't submitted abstracts for review to the technical program committee. The medical industry has had to deal with software safety issues for a long time. The Therac 25 is used as a classic example of what happens when hardware safety functions are shifted to software without sufficient testing. The automotive industry also has experience with software safety and it is becoming a much larger part of their reviews. The recent FCA recall of the Jeep automatic transmission will be fixed in software likely by having vehicles shift into park if a door is opened when the vehicle is not in park. BMW made a similar software change on their transmission. (This upset a few BMW drivers who like to crack open their door to see the parking lines when backing into a parking space.) Home appliance manufacturers are also looking at software safety for products such as ovens that can turn on based on a timer or electronically controlled stove tops. The computer industry, which dominates ISPCE submittals, will lag behind. ISPCE 2017 will be in San Jose California next May and this would be a great topic. I would recommend that list server subscribers interested in the subject come up with an idea for a presentation they can give. The ISPCE technical program committee would likely be very interested in adding such presentations to the schedule. Ted Eckert Microsoft Corporation The opinions expressed are my own and do not necessarily reflect those of my employer, IEEE PSES or the ISPCE technical program committee. -----Original Message----- From: Brian O'Connell [mailto:oconne...@tamuracorp.com] Sent: Wednesday, July 6, 2016 5:09 PM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Electronic versions of standards and DRM - off topic Greetings to Human-unit RalphMcDiarmid, Suppose that you could be found in attendance during Darmouth's 50th anniversary celebration for basic? Upon my imperial (empirical?) appointment, will require all engineering students to undergo the Klingon Rite of Ascension to earn their right to do basic code. Bazillions of years past, did a quicky control system for weapons turret in a rommable interpreted basic that was available on some off-the-shelf 6811 SBCs, as a proof of concept. Because there was no memory vector control, errant code execution (due to an adjacent radar and radio), caused the Mk 19 to prematurely send a round downrange. The thing about interpreters and weakly-typed languages is that they are neither determinate temporally or in memory space. Re-coded the control system in C/assembly where WDT and other problems always jumped to safe state, and where unused and 'boundary' memory locations filled with single jump instruction to safe state. This was burned to a huge EEPROM disk emulator that sat on a headless IBM XT motherboard running an embedded version of MSDOS. It functioned with zero errors and impressed the doo-doo out of the jarheads until an over-driven motor and caused a slip ring failure, which ended the test because there was no budget to repair a weapons station salvaged from DRMO. Many older C compilers were actually weakly and statically typed, so stuff such as pointers and integers could resolve to same memory space with no complaint at compile or link time. This, and the many other perceived evils of C's ability to stomp and play with any memory location, and its standard libs, have been long since been addressed by ISO9899 and TS17961, where dynamic dispatch is clearly separated from static dispatch. The 'swiss-knife' languages, such as Python (much beloved in this engineering group), are both statically typed and strongly-typed, and use complex allocation and garbage collection schemes to provide immense power to mortals. But an extremely high abstraction level render Python, Ruby, JS, etc as inappropriate for safety-critical machine control. ANSI C + MISRA C + TS17961 seem to be the most effective tools earthlings have for safety-critical code (yes, have used Ada). Ya just need to read the standard and understand what is implementation dependent, what is not defined, and what is not specified. And must understand that an interpreter does not have the different 'build' behaviors, or the ability to control, that is imposed by compile time vs link resolution vs run time allocation. Parting thought - was disappointed that code safety and code test coverage was not pushed to the fore for the 'IoT' and wearables presentations at the 2016 ISPCE. Brian -----Original Message----- From: Ralph McDiarmid [mailto:ralph.mcdiar...@schneider-electric.com] Sent: Wednesday, July 06, 2016 11:43 AM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Electronic versions of standards and DRM - off topic And, after all, what's wrong with BASIC? It's not the language, but rather how you use it. I've seen great programs in BASIC and horrible ones in C. Ralph McDiarmid Product Compliance Engineering Solar Business Schneider Electric -----Original Message----- From: John Woodgate [mailto:jmw1...@btinternet.com] Sent: Tuesday, June 28, 2016 11:17 AM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Electronic versions of standards and DRM Hey, my mother programmed in BASIC. Show respect! At the end of March, IEC told CENELEC that it wasn't happy about the copyright status of ENs derived from IEC standards. However, IEC doesn't bother to copyright translations into minority languages, so in future we can have European standards only in Anglo-Saxon, Welsh, Breton, Swabian, etc.. National standards bodies will run compulsory 14-day total immersion courses in the appropriate language. But they will be free of charge. With best wishes DESIGN IT IN! OOO – Own Opinions Only www.jmwa.demon.co.uk J M Woodgate and Associates Rayleigh England We live in exiting times -----Original Message----- From: Brian O'Connell [mailto:oconne...@tamuracorp.com] Sent: Tuesday, June 28, 2016 6:32 PM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Electronic versions of standards and DRM This was the general sentiment for the same discussion we previously had on this, which was memorialized in EDN or ED (do not remember). Am not certain that many standards are developed with public monies, as the ANSI, ISO, and IEC are NGOs, so the EN/UL/CSA/etc adoption of a national version of their standards still requires someone to pay the bill. What is not understood is that since the vast majority of standards are written by volunteers from industry and other concerns, there should be minimal direct cost to these documents. Perhaps it is time to look at ANSI's non-profit status. As most of my engineering colleagues are far more civilized and pragmatic than myself, will have to assume that there will be no engineering version of the storming of Bastille in our near future, or any other such technoid-revolutionary flashpoint. But what can be done is to appeal to the corporate bottom line. Let them influence the system and see what mountains can be moved. But am still open to a well-organized IEC insurrection at the steps of their Swiss HQ. We can drink good ale and eat burritos while camped out in Geneva a la the 'Occupy' movement. And our front-line protestors can hurl horrendous insults and biting epitaphs such as "your mother programs in basic", or "your computer does not meet class B limits". Brian -----Original Message----- From: John Woodgate [mailto:jmw1...@btinternet.com] Sent: Tuesday, June 28, 2016 9:53 AM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Electronic versions of standards and DRM Standards produced by tax-payer funded bodies should be free to citizens, shouldn't they? With best wishes DESIGN IT IN! OOO – Own Opinions Only www.jmwa.demon.co.uk J M Woodgate and Associates Rayleigh England We live in exiting times -----Original Message----- From: Cortland Richmond [mailto:k...@earthlink.net] Sent: Tuesday, June 28, 2016 5:27 PM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Electronic versions of standards and DRM On 6/28/2016 10:59 AM, John Woodgate wrote: > ny standards publisher that makes it difficult to use their standards > qualifies for a Darwin Award. How stupid can you get? (We don't know, > we aren't extinct yet.) Hmm... Can I expect C63 etc. free on the FCC site? No? What a shame... Cortland Richmond - ---------------------------------------------------------------- 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>
