{"id":5919,"date":"2020-03-16T17:54:51","date_gmt":"2020-03-16T16:54:51","guid":{"rendered":"https:\/\/www.electronic.se\/2020\/03\/16\/emc-in-product-development-part-8\/"},"modified":"2020-03-16T18:15:50","modified_gmt":"2020-03-16T17:15:50","slug":"emc-in-product-development-part-8","status":"publish","type":"post","link":"https:\/\/www.electronic.se\/en\/2020\/03\/16\/emc-in-product-development-part-8\/","title":{"rendered":"EMC in Product Development (Part 8)"},"content":{"rendered":"

We were actually done with this article series, but some engineers \u2013 if there are any left that I have not yet scared away from reading \u2013 might wonder: is there a faster and more simple way?<\/span><\/p>\n

 <\/p>\n

All that we have covered in the previous articles are now questioned: does it really have to be soo<\/i> complicated? Why not just get on with? We are in a hurry!\u00a0<\/span>Did we overdo it?<\/span><\/p>\n

 <\/p>\n

We have previously looked at how we handle the EM environment, requirements, possible disturbance risks and the design of prototypes including a set of pre-compliance testing. As a summation of all this work, the product is verified in a final verification test and all documentation is generated. <\/span><\/p>\n

 <\/p>\n

This article will discuss how to slim down the work to make it feasible for smaller companies with a minimized handling. To summarize things, we combine all<\/i> the blocks in Figure 1 in this text. If it is hard to follow my line, I recommend reading the previous articles in the series.<\/span><\/p>\n

\"\"
Figure 1:<\/strong> Picture of typical project flow.<\/figcaption><\/figure>\n

When can we make use of a Fast Track?<\/span><\/h3>\n

Using a fast track approach – at the same time as we are keeping the risk of failure low \u2013 requires a set of preconditions:<\/p>\n

    \n
  1. We have a stable starting point: we have made a similar design before.<\/li>\n
  2. We have a tight design team who has personal experience of the previous projects and know what to look for and how to apply the documents available.<\/li>\n
  3. We have a documentation from the previous projects that is possible find, read, and understand.<\/li>\n<\/ol>\n

    When looking at this list, we find that it is hard to apply the fast track to the following:<\/p>\n

      \n
    1. New innovative designs \u2013 they are starting from scratch.<\/li>\n
    2. Large companies \u2013 they do not have small design teams.<\/li>\n
    3. Companies without structured project management, product and design documentation – they cannot reuse the knowledge from previous projects.<\/li>\n<\/ol>\n

      That means that an effective combination of Fast Track and low risk is mainly relevant to small and medium companies who are using the major parts of the EMC Management scheme I have described in the previous articles. For those of you who feel comfortable with this description, this article will hopefully be useful. In theory, the complexity of the product does not matter since we are making use of readymade blocks. In reality, high complexity by nature makes it more difficult to keep track of all things so more care is needed.<\/p>\n

       <\/p>\n

      But: just because we are calling this handling “the Fast Track” does not mean that we are without EMI risks \u2013 without time delays. Surprises will always happen; the challenge is to minimize these risks at the same time as keeping a small project size and maintaining the speed in the development project. The solution is to make use of existing documents and results as much as possible. Tracing of product information and templates that are kept up to date is crucial.<\/p>\n

       <\/p>\n

      So, in this article I will not repeat all the details but group them together in a reduced set of critical actions and refer to the previous articles for details.<\/p>\n

      Preliminary Study and Requirements<\/span><\/h3>\n

      One critical aspect of keeping up the speed in the EMC work is to be keep your eyes open for changes both inside and outside the company.<\/span><\/p>\n

       <\/p>\n

      Inside the company:<\/strong>
      \nhave a regular look at the incoming field problem reports. There may be a need for stricter corporate internal EMC requirements if some weaknesses can be related to EMI.<\/span><\/p>\n

       <\/p>\n

      Outside the company:<\/strong>
      \nOnce every year we take look at the IEC homepage (or the equivalent organization for your standards) and check if there is some rework being started on the specific standard we are using. Is there smoke at the horizon? Nope. All right, business as usual \u2013 for some time at least. That means the standards we are applying will be stable for at least a year or so. Consequently, we do not need to update our documentation either. I inform my boss, and he will be relaxed.<\/span><\/p>\n


      \nVersion 2: we find that some work is in progress. If this is a vital document, you try to get a draft version as soon as possible to see what is changing. In any case, you will have a head notice of the change and if you get the final version right when it is published you will have an implementation period for the standard to use for your own adaptation.<\/span><\/p>\n

      The Concept Phase \u2013 EMI Risk Analysis<\/span><\/h3>\n

      If I would have to pick one single project activity for EMC, it would be the EMI risk analysis. In the reduced project flow, we combine a set of investigations into one block \u2013 based on that we have a lot of information readymade, see Figure 2. Now, we can focus on the changes<\/em> compared to the previous projects. What is new or different in respect of<\/p>\n

        \n
      • Standards<\/li>\n
      • Functionality, such as new types of cables, displays and other interfaces<\/li>\n
      • New application areas<\/li>\n<\/ul>\n

        If we find some changes, we document them and make adjustments on the Zoning concept that will guide the design work in the following steps. For instance, it could be that we are offering the product in a new application where the ESD threat is more prominent. We adjust the test level to a higher value and add a warning to the designer to make a more detailed assessment of arcing risks (or something similar depending on the design). Another example would be that we have replaced a signal cable with a radio interface. In this case, we have virtually opened the Pandora\u00b4s box, having to add a totally new product regulation and an additional set of standards. Possibly, you can make use of a pre-certified interface, but you have to make 100% sure that your supplier is backing you up on all details in that case \u2013 and that you can make use of it in your design.<\/p>\n

        \"\"
        Figure 2:<\/strong> Condensed EMI risk analysis.<\/figcaption><\/figure>\n

        System and Detail Design<\/span><\/h3>\n

        In the system design, which can be a seamless interaction with the EMI risk analysis (but we separate them with a Toll gate), we make use of our previous analysis and create action points. If we find that we cannot go on with business as usual \u2013 that is seldom the case, the new product should provide something new to the customer \u2013 there are update actions to be made, as shown in Figure 3.<\/span><\/p>\n

         <\/p>\n

        The design specification needs to be changed. In our case, it could be the an enforced ESD protection or the integration of a radio interface with minimized radio range degradation.\u00a0<\/span>As I have described in previous articles, we write an updated EMC verification specification (by some called EMC test plan) well in advance of the detail design. The designer gets an early warning of the new tests to be made, and you save time by using the previous version.<\/span><\/p>\n

         <\/p>\n

        With the new verification specification, we get a good template for making the new pre-compliance tests \u2013 such as an expanded ESD test or a spurious emission measurement due to the radio interface.<\/span><\/p>\n

        \"\"
        Figure 3:<\/strong> System design analysis.<\/figcaption><\/figure>\n

        Having made a thorough EMI risk analysis, we have a very good basis for making EMC design reviews (as in Figure 4) when we get the first versions of the mechanical design, the schematics and the layout. The risk analysis guides us in the review on what to look out for. When the results from the pre-testing arrives, we can study the deviations and on top of that discuss and select different options for design solutions. These proposals will then be based on a technical rationale rather than being just a wild guess on what to do about it.<\/span><\/p>\n

         <\/p>\n

        In the event of having a good success in the pre-tests, we can look for potential overkill design measures and trim down the production cost. Some people do this during the final testing, but I warmly recommend having the final test on a prototype that is not altered during test to get a clear record.<\/span><\/p>\n

        \"\"
        Figure 4:<\/strong> EMC design review.<\/figcaption><\/figure>\n

        Final Testing<\/h3>\n

        The final test is supposed to be a receipt on the design efforts described above. This test is documented in an EMC Test report. Quite often, we find engineers making tailoring during the final testing, which makes it hard sometimes to sort out: what version of the product did we actually get a pass for? That is why the EMC verification report is important. This is where you document the reasoning for the resulting compliance before you forget it. As a bonus, you can refer to the report rather than finding yourself in discussion meetings.<\/p>\n

         <\/p>\n

        Even without tailoring during the test, the verification report is needed when<\/p>\n

          \n
        • The testing was made on a reduced test object, or possibly a combination of worst-case combinations.<\/li>\n
        • Just a sub-range of the tests were made, and you make use of previous tests on similar products or possibly use a supplier\u00b4s documentation to make a complete set of compliance records.<\/li>\n
        • There are no simplifications made in the testing, and you state this in a very short summary report to make clear that this is a solid standalone EMC test record.<\/li>\n<\/ul>\n

          Pre-Series and Production \u2013 the Documentation Stage<\/h3>\n

          After the final testing, the approval documentation is finished in the form relevant for the product requirements \u2013 Declaration of Conformity, type approvals or the use of Notified Body etc. possibly, there will also be some changes of the design after the first production samples. Rather than having to retest it all again, you update the EMC verification report with the new information \u2013 possibly with the addition of a repeated sub-test. With proper templates and documentation structure, you can keep this work to a reasonable size.<\/p>\n

          Closing Remark<\/span><\/h3>\n

          With this article, I hope that I have been able to address those people who think all the previous articles were exaggerated. \u201cThis is too much, we will never have the time to do all this\u201d.<\/span><\/p>\n

           <\/p>\n

          Trimming down the process for smaller companies can be effective \u2013 but also providing a risk of fooling yourself, missing out on critical aspects. The Fast Track without detailed documentation and design steps is very risky. Quite often, it is based on having a Chief Design Engineer who keeps track of Everything within her own brain. That works as long as this person is healthy and does not change jobs.<\/span><\/p>\n

           <\/p>\n

          By adding a set of procedures and templates, you spread the knowledge and reduce the pressure on the designer who knows it all.<\/span><\/p>\n

           <\/p>\n

          Again: EMC Management is not a one-off activity but needs a process driven workflow. <\/span><\/p>\n

           <\/p>\n

          By the way, the methods above can also be applied to article writing. This article was written very fast \u2013 since I had written all the previous articles and had a template\u2026in my own mind. Nothing new, really. However, now it is also put in printing.<\/span><\/p>\n

           <\/p>\n

           <\/p>\n

          Lennart Hasselgren, Lic Eng.
          \nEMC Services, lennart@emcservices.se<\/address>\n
          \u00a0<\/address>\n
          If you have ideas and comments on this article, please feel free to mail me! Some might also recognize my short examples, and if you want to add something that would be an interesting talk.<\/address>\n

           <\/p>\n

           <\/p>\n","protected":false},"excerpt":{"rendered":"

          This article is a part of a series of texts that will deal with the EMC challenge in terms of project management and the practical EMC activities at different stages in the project flow. Different companies all have their own way of describing their project flow, so to keep it simple we will use the labels as given in Figure 1. We can call it a generic project flow. The picture only describes the basic outline of the work packages. These articles will describe the actual practical work we want to do in the project to \u201cmake EMC work\u201d in a time- and cost-efficient way. Each part of our series will fill in the details for each part piece by piece.\u00a0This is the final 8th part \u2013 The Fast Track \u2013 in the series of articles.<\/p>\n","protected":false},"author":2,"featured_media":5909,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[41,35,314,34],"tags":[],"class_list":["post-5919","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article-archive","category-emc-en","category-emc-in-product-development-en","category-home"],"_links":{"self":[{"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/posts\/5919","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/comments?post=5919"}],"version-history":[{"count":1,"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/posts\/5919\/revisions"}],"predecessor-version":[{"id":5921,"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/posts\/5919\/revisions\/5921"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/media\/5909"}],"wp:attachment":[{"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/media?parent=5919"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/categories?post=5919"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.electronic.se\/en\/wp-json\/wp\/v2\/tags?post=5919"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}