4 Things to Look For When Interpreting Standard Requirements

Craig Fanning, EMC Lab Manager

Today's Elite Expert is Craig Fanning, our EMC Lab Manager, US National Committee Technical Advisor for CISPR-D, and advisor on many other industry committees. Read below to see what he has for us this week. 

 

Being on several standards committees, I get a lot of questions about how to interpret the information provided in standards and specifications. Sometimes this is from a colleague who is thoroughly reviewing a specification in preparation for a quality audit. As a result of the thorough standard review and the possibility of being assessed a “deficiency” during the audit, they become overly concerned about all parts of the standard. Other times, the person has already been audited and overlooked a requirement. This resulted in a “deficiency” during the audit. The standards committees have content rules (what is and is not a requirement and how is that defined in the standard) that must be followed when a standard is being developed or revised. In addition, quality auditors are only supposed to audit against the requirements of a standard. Here is brief summary of what is a requirement within a standard…

1. Main Body of the Standard: In general, information provided in the main body of the standard and prefaced with the word “shall” is a requirement. Dimensions and values are also a requirement. If no tolerances are provided in the standard, then general tolerance rules apply (or the tolerances specified in the base standard of a series of standards would apply). Any information prefaced with a should, could, may, etc. (anything other than a shall) could be considered informational and not a requirement. 

2. Notes: Notes in a standard are for information purposes only. You will notice that notes within a standard do not contain the word “shall”. Do not confuse “Notes” with “Footnotes”. Notes will always be prefaced with the word “Note:” Footnotes are used many times in tables and can contain very important information. So pay close attention to footnotes (especially in tables).

3. Annex (Normative or Informative): At the beginning of each Annex (sometimes referred to as Appendix in some standards), the word “Normative” or “Informative” will appear. If the Annex is “Normative”, then the information in the annex is a requirement (again keeping in mind the preface word of “shall”). If the Annex is “Informative”, then the annex is for information purposes and is not a requirement.

4. Interpretations: Although the standards committees try to make the information provided within a standard as clear as possible, something always seems to get into the published standard which may need interpretation or clarification. In these instances, the reader will have to use good engineering judgment. When this happens, it is a good idea to ask others in the industry (especially persons on the standards committee responsible for the standard generation) how they interpret the information provided in the standard. They most likely have had the same question and have addressed the issue.

I realize that this is a “crash course” in standards interpretation, but it should provide someone with the basics for interpreting standards. Knowing the basics and what to look for in a standard (also what can and cannot be audited) can really be helpful during a quality audit.

Do you have any questions about EMC Standard Interpretation, EMC Testing, or other related topics? Please share your comments or questions below and this week's expert, Craig Fanning, will get back to you as soon as possible. 

Evaluating & Designing Around Specification Requirements

This week's Elite Expert is Craig Fanning. Elite's EMC Lab Manager since 1995 and one of our Sr. EMC Engineers, Craig has overseen scores of test projects over the past 27 years with the company. He is also an iNARTE Certified EMC Laboratory Engineer and author of several papers for the IEEE EMC Symposium.  Finally, as a member of SAE EMI and EMR Committees, as well as a US National Committee technical advisor for CISPR-D, our EMC Lab Manager undoubtedly likes to stay active in the EMC community. Read below to see what he has for us today.

Nothing is worse than going to the EMC lab and failing an emission test. This is especially true when you figure out that an operating frequency of the Device Under Test (DUT), that you designed, is causing excessive emissions within a frequency band which has a low limit. We see this time and time again in the test laboratory.

The best way to prevent this from happening is to evaluate the specification requirements before you start picking out clock frequencies and communication rates. If you look at the specification limits before you design, or during the design phase, you can determine frequencies that you should stay away from. Don’t select operating frequencies that fall into frequency bands with low emissions limits. Also look at the harmonic frequencies (especially the odd harmonics of the operating frequency) to see if a harmonic will fall into a frequency band with low limits. If possible, pick operating frequencies that fall into frequency bands with higher emissions limits.

Many times communications rates can be adjusted through firmware. This is something that can be in your “bag of tricks” when designing the product and/or troubleshooting a failure. When it comes to designing for good EMC performance…review and design to the specification. If you do, this will save a lot of future headaches and re-design costs.

Do you have any questions about CISPR Emissions Testing, Design, or other related topics? Share your comments or questions below and our expert, Craig Fanning, will get back to you. 

Craig is also guest-presenting a webinar, "EMC for Vehicles: Truly Mobile Electronics", with Washington Labs on Thursday, August 15, 2013.  Please follow the link if you would be interested in learning more.