In this article, we move to the second block in the flow chart – setting the EMC requirements . This is an activity I have noticed is briefly touched in projects, and many times only referred to as finding some type of standard as fast as possible, so that we can go on with the real work – design. I will try to lift up the status for this work and maybe make it more concrete – what are the actual activities?

Attitude to requirements

First of all – why do we do this? What is the intention of having EMC requirements?

The requirements are your defense and not your obstacle. They are your solution to make sure that you will have as few problems in the future – in the project and in operation (customer claims etc.). So do not go for the lowest and – as you were hoping – cheapest requirements. Pick the correct and relevant requirements.

 

EMC requirements are meant to prevent inter-system degrading influence. That means, that you will never see these problems when running your component in your development lab. But, your customer will notice when they do not get their radio communication needed or when the lightning strikes nearby. It is better that you find the problems before them. So do not regard EMC as something you have to sneak around, cutting the corners in some cunning way. Correct requirements will help you in the long run.

Understanding the requirements

Do not just copy-paste old requirements. Take your time to understand the technical intention with them. Part of that work is done in the prestudy as described in the previous article. Here, we talk more about the paperwork part of it. What reference documents are we using, and why? Do the previous requirements meet the expectations of our customers today? Maybe the standards have been updated, which means new tests may have been added (or removed).

Also, do not try to negotiate with the customer about using older requirements, believing that they are easier to pass. You must ask yourself the question: why did they update the specification at all? Many times it can be that:

• The older limits were extreme, and it turned out that no one passed them. After a review, a more realistic level was introduced.
• The older test proved to be virtually impossible to create in a normal lab, and no one thought of that when they extrapolated the test level with a straight line. And those capacitors in the setup are in the wrong place, by the way.
• That old test was invented in the 70:s by a clever engineer when commercial test equipment was not yet available. Now, when he is retired, someone finally had the courage to replace that test with a modern setup that is possible to calibrate.

In addition, be aware of that standardized requirements are based on diplomatic compromises in standardization committees. You may need to add requirements based on the actual environment. For instance, companies manufacturing keypads and touch panels know that enhanced protection for ESD is needed when selling to e.g. northern Sweden.

What requirements shall be included? Some may be too high to design for, so let us handle that with a disclaimer or some amount of warranty cost. Examples: damages caused by direct lightning strike; new failures because the customer extends signal cables outside expected range; customer co-location of your product with very sensitive equipment.

Selecting standards

Many engineers expect that this is the only thing you do when you talk about EMC requirements. Ask the EMC lab what standards they can recommend, and then we will hopefully get a pass when we test. Let us say you would do the same when selecting your DC power?

 

“What voltage do we need for the PCB input?”

“Well, I am not sure, but let’s try 12VDC. Pick one of those DC/DC converters, solder it to the wires and then we will see how it goes in the power lab next month. It will probably work fine”

 

No, you would normally check your preconditions, and also include temperature, electrical safety and other aspects. The same goes for EMC – in addition to the radiated emission limit you also check for the need of immunity to RF field, pulses, power quality, ESD and so on.

“We have done this before, so it is not much difference” – you might say. OK, you have reference projects to look at when you start the new one, and that is excellent! But still: why did you have to design a new product? Why not keep selling the old one?

 

No, something has changed, and you have made improvements and maybe also have expanded the scope for the application. So, the preconditions have changed and consequently also the requirements – including EMC. You will then have to look into the EMC standards and select the ones that covers

• The intended use of the product (including all options)
• Different frequency ranges for the requirement (like power frequency harmonics and RF emission)
• Both immunity and emission (sometimes they are split up)
• Different markets

One way is to look for existing published standards – surfing the CENELEC site for instance. Before you buy the standard, you can read the scope in a preview and see if it is relevant for your application. You may also want to check for upcoming revisions of the standards you are going to use. At IEC (and CENELEC), you can search for draft and work in progress. ETSI is very generous in providing free drafts in advance, providing you with all the details about what is around the corner. Take the opportunity to test against future requirements while you are at it, and your approval documentation will last longer.

 

For some products, you will receive a specific EMC requirement from the customer – such as vehicle manufacturer or the military ones. So, you do not have to look around, but these might be very complex and you might have to look through the references to check what they really contain. Some of the specifications are new and fresh, other ones should have been updated long time ago (in my view).

Setting preconditions

Sometimes, you may sell to a customer having a specified scope. For instance, you may sell to a military customer who declares that the product will be installed in a protected environment (e.g shielded enclosure having lightning protection). Make sure to have this in writing, since this will drastically influence both design and testing! This precondition needs to be included both as design and test input, as well as the user instructions. A well formulated disclaimer is always good to have – users can often be very innovative, and then possibly blame the manufacturer when it brakes.

 

Another example is the vehicle industry. Here, the manufacturer of the vehicle has two options for approvals (the homologation process): either complete vehicle type approval – or approval by subcomponent. As a supplier of the component, you must be sure to check with the customer which way to go. Will you have to make a component approval, or can you leave that to your customer (who makes a complete vehicle approval).

Document structure

A way to keep track of things is to have a specific record for how the approvals for the product is to be achieved. Create a Product Approval Specification – PAS. This is a high-level document containing a list of

• End-user applications (domestic, industrial, marine etc.)
• Specific customers request (e.g. a US company having their own references)
• Market needs (Australian specialties)
• Legal requirements (CE etc)
• Product variants (Radio added to some of them)

A part of this document is the time plan for approvals: what approvals do you need, and how long ahead do you need to plan for it? Things you need to check are:

• What certification is needed? What is the source for the requirement? Legal reference, customer reference, rumor (someone said he/she thought it was necessary, but did not know why)
• Where can we get the stamps? What options do we have, and when do we need to book the lab?
• Lab capacity, can we pick any one or do we need a specific one with particular competence/equipment (example, capacity to handle high mechanical loads, cooling, weight etc)

Example of approvals that are common are:

• CE self approval
• CE with type approval module
• Local national approvals (outside EU)
• E-marking (vehicles)
• Ships classification (insurance company requirement)
• Lab accreditation (customer requirement)

In addition: do not mix up EMC requirements with other approvals. Someone at the market department may say, that we need a CB certificate for this country. However, a CB certificate (CB = Certification Bodies) is mainly relevant for electrical safety, as is UL (Underwriter’s Laboratory, the US/international S-marking). They can not be used for EMC. Also, you will sometimes hear that an accredited laboratory is absolutely needed, but no one knows why. Be aware, that lab accreditation is only required for a reduced range of testing. Quite often, an EMC lab meeting the technical performance for the tests is quite sufficient. There are several labs with some 30 years of experience who never bothered about the cost of accreditation (e.g. working with military testing), but still know their stuff. If you have a set of favorite labs that you work with – including non-accredited ones – you might enjoy a better flexibility in your test planning. The difference is that you will have to check the credibility of the lab yourself, which is not too bad. It forces you to know more about EMC testing, which will be crucial in the coming articles.

 

I often meet customers who ask me these types of questions at a very late stage in the project, and I realize that they should have prepared these issues a long time ago. And now they find themselves in a bad situation, where they can not find the resources in time – so the project time plan is delayed, managers are pushing, discussions go on for long times and the cost goes up. And they also discover that the testing was more complex than they hoped for (will be discussed in later articles).

 

On the other hand, there may be engineers who say this processing is a drastic overkill. “We go to the EMC lab and use the generic EMC standards every time, so what is the problem?” And of course, if you have a tight group of experienced design engineers, they know their job well. Small companies often work faster and more efficient with EMC (if they have the experience). But new colleagues will join you, and for them this is not self-explaining. When the guy who kept all the know-how and spread the word in the good old analogue way (talking to each other) retires or quits, the cost for re-inventing the wheel of EMC will go up.

Tracing

One hidden cost in a product manufacturing company is the time allocated to discussions about the requirements. Why do we have them, and why these levels? One good way to reduce this cost is to write these things down on a paper that you can find. There are two major obstacles in this process:

• Write it down (when you have the time)
• Find the document afterwards (what ID shall it have, and where to store it)

The solution can be to assign time to the most experienced engineer (who does not actually have time for this, since everybody is asking questions about the requirements… but still), in combination with having a document structure not only for the production but also for supporting documents. While you are at it, do not only put a tag on the requirement. Take the time to append at least the following information:

• What is the actual threat that the test is simulating?
• From where did we get the test levels?
• When and how did we say that we needed these requirements?

Example: space industry is very good at tracing their requirements, and also in some military industries. This tradition is now spreading into the vehicle industry, where some manufacturers are migrating into using links in data bases instead of referring to a corporate standard in the shape of a PDF document.

The functional performance criteria

When you set the EMC test requirements for immunity (or susceptibility, as it is sometimes called), you can not just set the test level. You must also specify the tolerable product behavior for each type of test. These are listed as generic descriptions in several EMC standards, and normally use the designation letters A, B and C. By nature, IEC can not agree with ISO on these labels – so ISO standards use roman numbers (unless you apply the older versions, where you use ABCD but of course with another content).

 

In very plain words, we could describe the meaning of the letters as follows:

A: it works OK

B: it works so-and-so, but basically not too bad

C: a bit worse than B, but some type of reset is OK

 

So, what does it mean for this particular product? The text is mostly too generic to use – you have to be specific! Letter A means that it works OK, and that range is mostly found in the design specification which focuses on the expected performance. And C could be listed as a straight forward push on the reset button. But what about letter B? Nobody specifies so-and-so behavior unless you are utterly forced to do so – like by the EMC standards.

Some engineers might say this is up to the EMC lab. They are used to EMC testing, and it is better they do it since they know what it means. Just read the standard, it is listed there. But this is regrettably impossible for the EMC lab to perform. The performance criteria are closely related to the functionality of the product. And they did not build the product – you did. So, it is the responsibility of the manufacturer to specify the criteria and deliver them to the lab so they can apply them during the tests.

 

When you do the EMC tests, you monitor the test object and check the response. Which response is it, and what does the customer expect? What percentage of variation is acceptable, and in what parameters? Write it down and pass it on to the lab! Often, the engineers writhe and squirm when faced with this question – quasi-function is not popular. Try to look at it from another perspective: let us talk about the stability of a heavy truck. When it is driving on a straight road at 90 km/h. it goes straight. Then you press the truck into a curvy road, and it wiggles a bit. How much do you accept, before you get car-sick? And finally, you drive into a sharp curve. Let us say that the truck should stay on the road at 30 km/h. At 90 km/h, you drive off the road, but the driver shall not die. If we convert this to EMC, we might say that:

• 10 V/m = straight road
• 30 V/m = curvy road
• 100 V/m = sharp curve
• Normal operating mode = 90 km/h, 30 km/h
• Monitored parameter: maybe something better than the color of your face (green/red/white).

Or: you might compare this with test levels for transients, if that is more interesting. The bottom line is that you do not have the same expectations for all tests and not even for all test levels within one test.

 

So, please, for your own good: specify the performance criteria at the beginning of the project and save a lot of discussion and time – and money!

Preparing for coming work in the project

So, when you have prepared all this information it is now time to make use of it – instead of just putting it in a folder and let it mold until you go to the EMC-lab. Make a checklist on what is to be prepared and carried out. In complicated projects where we are involved, we propose to generate an EMC Compliance Matrix. This will include the technical parts of the PAS, like the EMC standards selected. If you do not use a specific data base tool, this matrix is effectively made as a straight forward Excel spreadsheet. You can use this spreadsheet during the entire development project and follow up the progress. As time goes on, you add more detail about specific test methods (conducted emission, radiated emission etc). It will be used both as an input to the design (what to prepare for in the test) as an output (how are we doing regarding pass/fail).

 

In addition, you can use this document as a check on what you agree on with your customer, if you have a specific one (e.g. a vehicle manufacturer). Many times, such customers gladly add new requirements and – not the least – new test conditions without thinking of the consequences. Such “would be nice to have” request might make your test time explode and also the complexity in test preparation.

 

If you like, you can integrate this compliance matrix with your PAS, as separate sheets in the same document, making it easier to update.

Input and output

As a summary, we find the following interface conditions to the other parts of the project flow.

Input from prestudy:

• Types of EM environments
• Market areas – legal requirements that are need
• Expected customers – what do they expect
• Differentiation on product configurations

Output from this stage:

• Product Approval Specification (PAS), including time plan for approvals
• Requirement specification – technical, including traceability of legal and customer requirements and performance criteria
• First release of EMC Compliance Matrix

You might look at this as tedious paper work that slows down the project – but you will sleep better at night and be better prepared for questions. Hopefully, you will also have a reduced number of never-ending meetings on the subject “now, what did we say about EMC?” I believe you will gain in the end.

 

Lennart Hasselgren, Lic Eng.

EMC Services, lennart.hasselgren@emcservices.se

 

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.