I have not spent nearly as much time on standards committees as the esteemed Mr. Nute. However, my experience has shown that there is an effort to ensure that there is science backing up the work. IEC 60950-1 has a long history and stems from older standards. We constantly have to balance new science against those on the committee who want older requirements put into new standards because they appeared to work in the past and it makes it easier to ensure continuity of design. IEC 62368-1 adoption is a problem partly because the requirements based on research result in compliance requirements that differ from those in IEC 60950-1. The same design engineers who complain that IEC 60950-1 is no good because it isn’t properly based on science now complain that IEC 62368-1 is no good because they don’t like what the results of the scientific research will make them do.
I don’t intend it to be a slight at Rich, but I also object to giving in to design engineers who hate safety standards based on a quote from an unnamed source. We started out with discrepancies of no more than a few percent in values and that isn’t enough to state that a standard should be invalidated for insignificant mathematical rigor. There is an underlying problem here that the design engineers don’t want to face. Nobody wants to pay for any significant new research to develop better standards. Let’s take lithium-ion batteries as an examples. There have been recent issues with batteries that passed the certification standards yet had field failures. The field failure rate may have still been less than 10 parts per million. If you want to develop a battery standard that will prevent these issues, you need extensive and expensive research. Who is going to pay for it? Battery manufacturers do their own research, but they keep much of it proprietary. Universities don’t have the facilities or finances to build thousands of batteries with dozens of different constructions to validate theories. Forensics companies that look at battery failures are normally under non-disclosure agreements that strictly limit what information they can publish. We are stuck with battery standards that don’t describe much in regards to construction and instead just pose a series of tests that must be passed. Even if these tests are performed on a thousand samples, they may not find a 10 ppm failure. More than a billion devices with lithium-ion batteries are sold each year, so a 10 ppm failure rate would still result in a lot of fires. I know I’m oversimplifying this with the battery example, and I’m sure my colleagues will disagree with me. I’m open to their opinions. For that matter, everything I’ve said is open to debate, and I’m sure it will be debated extensively in this forum. Finally, for those who object to a standard because it isn’t close enough to the scientific truth, I recommend Isaac Asimov’s essay “The Relativity of Wrong<https://en.wikipedia.org/wiki/The_Relativity_of_Wrong>” along with Michael Shermer’s commentary “Wronger than Wrong<https://en.wikipedia.org/wiki/Wronger_than_wrong>” on the Asimov essay. Ted Eckert The opinions expressed are my own and do not necessarily reflect those of my employer, IEC TC108, any TC108 national or subcommittees, Isaac Asimov, Michael Shermer or the scientific community as a whole. The opinions should be considered the ranting of a slightly insane safety engineer who hasn’t had enough coffee on a Saturday morning. From: Doug Powell [mailto:doug...@gmail.com] Sent: Friday, March 31, 2017 11:06 PM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] IEC/ANSI/UL/CSA 60950-1 ed.2 Mains Vrms vs Vpeak "Unlike all other engineering disciplines, safety engineering is consensus driven, not research driven. It is almost devoid of physical laws to guide its practitioners.” Yikes! This sounds rather subjective and flies in the face of one of my arguments to design engineers who say these rules are just opinions and therfore invalid. My answer to them usually is, while it is true that many requirements are a result of litigation and CYA, much of it is also based in real science. I usually point to IEC 60664-1. Now I am hearing that the 60950 committee did not use the document so much as I had originally thought. I'm not sure I'm happy with this idea. Maybe those design engineers have a point after all. -- Doug Douglas E Powell doug...@gmail.com<mailto:doug...@gmail.com> From: ri...@ieee.org<mailto:ri...@ieee.org> Sent: March 31, 2017 5:11 PM To: doug...@gmail.com<mailto:doug...@gmail.com>; EMC-PSTC@LISTSERV.IEEE.ORG<mailto:EMC-PSTC@LISTSERV.IEEE.ORG> Reply-to: ri...@ieee.org<mailto:ri...@ieee.org> Subject: RE: [PSES] IEC/ANSI/UL/CSA 60950-1 ed.2 Mains Vrms vs Vpeak Hi Doug: From your message, I don’t know if your question is about the concept of “significant digits” or the standard itself. Perhaps I can answer both. The number 300 can have one, two, or three significant digits. One, for sure. If we multiply by the square root of 2 to get the peak, and if we follow the significant digits rules, we can only say 400, not 420 or 424 without knowing the significant digits in the value of 300. 0.300 x 103 would be three significant units, in which case the peak value would be 424. (Standards committees have little understanding or patience for significant digits.) In the standard, the 300 volts was chosen because, throughout the world, mains voltages are either comfortably below or above that value, e.g., 220, 230, 240, including tolerances. 240 +10% would be 264, which is comfortably below 300. Working backwards, 420 divided by the square root of 2 is 296, still comfortably above 250. This bit of discrepancy doesn’t get in the way of determining the clearance for almost any of the world’s mains voltages, including tolerances. If you look at the “rms” values for Table K, they are: 50.2 rms for 71 peak (for 50 rms) 148 rms for 210 peak (for 150 rms) 296 rms for 420 peak (for 300 rms) 593 rms for 840 peak (for 600 rms) Etc. Maybe you can round to the nearest 10 when multiplying by square root of 2. But, it may not always work since committee judgement was used to arrive at the values. You may have to resort to something like “If more than 150 and not more than 300, then Table K.” Table L only applies when the “working voltage” exceeds the mains voltage. This was to account for the switching voltage of a SMPS exceeding the mains voltage. Back in the days of IEC 60950-1, 2nd, little attention was paid to IEC 60664-1. One of my colleagues said: “Unlike all other engineering disciplines, safety engineering is consensus driven, not research driven. It is almost devoid of physical laws to guide its practitioners.” Best regards, Rich From: Doug Powell [mailto:doug...@gmail.com] Sent: Wednesday, March 29, 2017 5:49 PM To: EMC-PSTC@LISTSERV.IEEE.ORG<mailto:EMC-PSTC@LISTSERV.IEEE.ORG> Subject: [PSES] IEC/ANSI/UL/CSA 60950-1 ed.2 Mains Vrms vs Vpeak All, I am reviewing the requirements of "2.10.3.3 Clearances in primary circuits" and it seems interesting to me that the math is off by just a little bit. In particular "For an AC MAINS SUPPLY not exceeding 300 V r.m.s. (420 V peak)". When in actuality the calculated peak of 300 Vrms is 424 Vpeak. Using three significant digits instead of two. This value is important to spacings determination in that it invokes using tables 2K plus 2L instead of table 2K alone. I checked the Edition 2 of IEC, ANSI/UL and CSA standards and they all have the same statement. Edition 1 of IEC 60950-1 does not include this value within parenthesis which tells me it was probably added as a clarification by the committee in Edition 2. I am one to build excel-based spacings calculators and this has changed the math somewhat, rounding up to the nearest 10 Volts =IF(10*ROUNDUP(Vrms*SQRT(2)/10,0)>420,"Tables 2K + 2L","Table 2K") instead of using =IF(Vrms*SQRT(2))>424,"Tables 2K & 2L","Table 2K") (Note: use of =MROUND() could potentially round down and not up) In several other sections of the standard another pair of voltages appear together in at least 8 locations and are rendered "42,4 V peak, or 60 V d.c"; which is correct for three significant digits. I know the consequences are probably minimal and it has raised my curiosity as to why this happened. Was anyone in this forum present during this part of the revision discussions and can shed some light? thanks Doug -- Douglas E Powell doug...@gmail.com<mailto:doug...@gmail.com> http://www.linkedin.com/in/dougp01 - ---------------------------------------------------------------- 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<mailto: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)<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 <sdoug...@ieee.org<mailto:sdoug...@ieee.org>> Mike Cantwell <mcantw...@ieee.org<mailto:mcantw...@ieee.org>> For policy questions, send mail to: Jim Bacher <j.bac...@ieee.org<mailto:j.bac...@ieee.org>> David Heald <dhe...@gmail.com<mailto: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>
