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 “make EMC work” in a time- and cost-efficient way. Each part of our series will fill in the details for each part piece by piece. This is the 7th part – The aftermath – in our process.
We have previously looked at the EM environment, requirements, possible disturbance risks, and we have designed prototypes including a set of pre-compliance testing. As a summation of all this work, we have performed a final verification resulting in a Pass. So, we should be all set for production and deliver our products to a large group of satisfied customers: EMI problems should be ruled out. Now, this article will discuss some EMC aspects of what comes next – the aftermath, when we thought we were done. To simplify things, we combine all the three last blocks in Figure 1 in this text.
The Scope of post verification work
We have made the final verification test on our brand new product and got a pass and a nice test report. All details about the tailoring of the testing and the evaluation of the test results has been reviewed and documented, data sheets, operating and services manuals and approval documents are done and put into service. Truly the right time for rejoicing! However…
New activities pop up – we are not quite done yet. I have grouped these activities in four types:
- Product modification and trimming
- Market surveillance
- Standard updates
- Field problems
All of these can be both time consuming as well as neglected. Many times I find that this work is not including the EMC aspect in a proper way due to lack of efficient EMC management, tools and checklists. The previous articles have described these, and here I will refer to these without digging down in too much detail.
Product modification and trimming
How to handle modifications in production.
You thought you were finished with the design project – but then comes all modifications due to cost reduction, production problems, obsolete components going out of production (so called LTB = Last Time Buy). It may also happen, when you are stepping out of the EMC test chamber with the approved product, that you are called to a meeting with the market department. They have some requests on product changes based on recent findings on new user needs for additional interfaces.
How shall we handle the modifications?
There will be questions on the possible EMC degradation due to the changes and how big they are. Do we need to retest? Is a complete testing required, or could we reduce the amount to a tailored test suite? Maybe we do not need to do any testing at all, and perform a theoretical EMC Analysis instead? How do we do this, and who has the knowledge to perform it?
Note that the legal requirement is that you shall be able to provide evidence that you comply with the levels expected, e.g. by conforming to an EMC standard. Some sort of test report is generally required, but you have the option of combining it with some sort of analysis – or combination of old and new reports covering sub-parts of the requirement. The question is how to do it in a cost effective way – at the same time maintaining the quality of the compliance records.
Using the zoning analysis, you can answer the question: is it OK to change this component to this other type? Do we disrupt any zone boundaries, or do we increase the emission generator, or do we make the product more sensitive to disturbance?
Using the EMI risk analysis, (which was the basis for the zoning) we can map the design changes against the identified risks and make an assessment on how much testing and/or analysis that is needed.
Test or analysis – or both?
Figure 2 describes a general case of product modification. A set of tests (if they are necessary) must be prepared in an analysis, where we map the design changes against the risks. The result of the testing must also be reviewed in an analysis (which may be an updated version of the first analysis, to keep the number of documents down). If the results are positive, we reach a Pass result; otherwise we need to redesign and repeat the loop.
There is also the possibility of making an EMC analysis review only, which gives you a less tight compliance record but can be used for simpler changes. This can be a lot faster and cheaper than testing a complex product. On the other hand, the risk of misjudgment is greater and sometimes it is better to have a clean and straight test record to keep down internal discussions and provide a fresh benchmark (e.g. if this is the 4th update in a row without testing).
There is a market surveillance action from the authorities. Your product is selected, either by random or due to a complaint (e.g. by a competitor). How do you handle that? You do not want a fail in their testing (which is performed in a laboratory that has not seen your product before), so rather than keeping your head down and try to erase the problem with some sort of “Men In Black flash” gadget (which makes everyone lose their memories, if you have seen the movie), you set up a team that will assist in the product check as much as possible.
So, you provide the authorities with
- Test reports and DoC
- Product drawings if requested. Make sure to request a non-disclosure agreement, so not to make your drawings public for your competitors.
- Your own optimized EMC test plan – which you have stored in your compliance folder (and not just the test report). The laboratory does not know your product, so you must inform them and guide them to test the way you intend (still within the standard).
- Offer your dedicated Auxiliary Equipment, minimizing the influence of possibly poor gadgets that is not within your control.
By doing this, you will have less risk of faulty testing that can be hard to discuss afterwards (especially if it is an authority as well as laboratory far away). Also, by being an active part you will also have a chance of a better discussion with the authorities if there would be an issue.
Once you have finished the design and put it in production, the legal requirement is that the product shall conform to the actual requirements – traditionally a published valid product EMC standard. Now, this requirement is put on your product at the time of sales, and not the time of design. And of course, the user does not know when you designed it. They know when they bought it. That means that your compliance record can be outdated, even though you have made no product changes.
The reasons for updates of the standard can be:
- The EM environment has changed, e.g. with the use of new radio frequencies, and consequently the scope of testing is increased.
- The description of how to perform the test has been improved.
- More details on how the test object shall be configured has been updated, e.g. specific operating modes.
- The standardization committee finally agreed on a common decision on an update on a critical test parameter or limit (but still the same test range). Standards are both technical and political documents.
- New types of tests are included, e.g. conducted emission on signal interfaces.
- Old test methods are replaced by new modern ones (or made available in parallel to existing methods).
Let us say you are reviewing a presumed new sub-supplier of a component to your system, and you discover some old references to technical standards that you know are outdated. Immediately, your feeling of doubt is rising in your mind. If the document is old, then what about the product? The same will happen to you if send old documentation to a new customer. They might wonder:
If they did not bother to check the validity of the relevant EMC standard – did they bother to make a robust EMC design? If there is a document error, we might also have the risk of finding a technical one.
Keeping old references is an unnecessary risk of being questioned by a customer who – alerted by the old outdated references – does not believe that your product is good enough. So, make sure to keep this door of distrust shut by having a regular check on the validity of your approvals. It makes engineering life easier in the long run. As long as no one discovers the approval gap everything is fine, but when it happens there will be an urgent request for action – generating unnecessary stress and overtime work.
Another variant of need for standard update is if you change the market specification or the intended operator use for the product. Let us say you have a product that is designed to comply with an industrial environment. At the market department they discover that there is an opportunity to sell this product on the marine market. Is that OK? Can we sell it tomorrow? No, by changing the intended use you alter the electromagnetic (EM) environment, and consequently you need to investigate the consequence of applying a new EMC standard that covers this case.
If you are lucky, you find in your test reports that the test levels applied covers even this new application. Then you would only need to update your papers and make the responsible person sign it. Otherwise, re-testing and possibly re-design – in the same way as for a product modification.
We have a field problem with EMI. How do we handle that? To begin with, we need to gather information about the problem – as well as the actual EMC status for the product of interest:
- Failure reports
- Interview material from customers, their maintenance personnel and your own personnel on site. In house maintenance personnel can be an invaluable resource in this work.
- EMC test reports
- EMC verification reports (containing the assessments of the results)
- Pre-compliance testing results
- EMI risk analysis from the development project
If we made some extra testing with increased test levels in the pre-compliance testing, we might have valuable information there on how the product responds to extra high transients, ripple, or other disturbing scenarios. We could also have some extra information on how erroneous installations affects the products. If we have stated these restrictions in the operating manuals, it is easier to describe the problem for the customer. The EMI risk analysis from the development project (which we started creating during the concept phase) can be very helpful in these cases.
Causes of the deviations in the product behavior may be:
- We forgot to perform some tests.
- Blind testing, our monitoring of the behavior was too poor.
- Laboratory errors due to misunderstandings between the parties involved.
- Test setups were not mean enough (e.g. transient pulses did not run through the PCB as in real life).
- Levels in real life are higher than we expected and tested with.
- The customer is using the products in a way we did not expect (like routing very long signal cables).
- A deviation in the production (e.g. surface treatment by a supplier, or new assembly procedures in your own plant).
The troubleshooting will most likely be a lot easier and faster with the assistance of all the reviews, test reports, EMC zoning maps and EMI risk analysis. One major obstacle may arise – where do I find these documents? And did anyone update them with the latest relevant information?
This type of Ghost Buster expeditions can be very challenging and inspiring – or frustrating, since we do not find any clues. It is important to be persistent and not give up. The risk analysis we performed could be perfectly fine, but it only includes the information on what we knew (and nothing about a possible new situation). It may very well have to be refined and combined with new design testing based on engineering assumptions. Sometimes, wild guesses could be a seed for new trails of thought. New types of tests may be created.
This is one of the few occasions when the design engineer is joyful when something breaks in the lab. We have managed to reproduce the error! At last, we can see the ghost and fight it with some kind of measure! But instead of making wild guesses, we have a map to follow: the EMC zoning map and the EMI risk analysis as described above.
Updating of Sign-off and approval documentation
If you have made any of the activities above, it is essential that you do not stop there but stick to it to the end – documentation of the updates and the corresponding approval.
In short, one or more of the following documents will be updated and stored:
- EMC verification plan (test plan)
- EMC test record
- EMC verification report
- Type approvals (if relevant)
- Declaration of Conformity (DoC)
- Compliance sign-off
- New instruction to the user of the product, e.g. avoiding ESD damage
- New instruction for the installation of the product, e.g. restricted length of signal cables
Input and output
As a summary, we find the following interface conditions to the other parts of the project flow.
Input from previous work (one or more of the following):
- list of product modifications
- EMC verification plan
- Failure and warranty reports
- Pre-compliance test results
- EMI risk analysis
- New version of used standard
Output from this stage – updates on one or more of the following:
- Complimentary EMC test report
- Updated EMC verification report, including both old and new test reports
- Compliance sign-off
- Type approvals (if relevant)
- Declaration of Conformity (DoC)
- Compliance matrix
- Updated with status from the new tests
- Lessons learned document
Product maintenance and modification can in many ways be experienced as a tedious work that goes on and on. So, even more there is a need to minimize the effort by having effective routines and templates! In this article I have tried to give you an incentive to make use of the work process and engineering documents that were generated in the design project.
Hopefully you will find that you can gain time and money twice: in the design process, and in the post verification parts. EMC Management is not a one-off activity but needs a process driven workflow.
Lennart Hasselgren, Lic Eng.
EMC Services, firstname.lastname@example.org 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.