As a compliance engineering professional, you may encounter situations when you must consider how multiple and often conflicting requirements apply to your product and how to deal with them effectively. Things can get real confusing, real complicated, real fast. You may determine after a product has been released to production (when it is too late to make cost-effective design changes) that you may have missed a key requirement that your product should have met but does not because you overlooked it. Knowing all the requirements that apply to your product ahead of time will help you design the product to meet the harshest requirements and also design pre-compliance tests that represent the highest severity immunity test levels and lowest limit emissions levels you need to test the product against. This can be a big time saver because you can skip the formal full-compliance test setup, quickly determine pass/fail of the product, make design changes as necessary, then come back and run formal compliance tests knowing the product will likely pass. If you need to make design changes later, you can skip straight to running the harshest test levels to determine whether or not the change affected compliance.
Organization
The first step in dealing with conflicting requirements is to get organized. Think about all the various requirements the product has by type. For electromagnetic compatibility (EMC) tests, the product probably has requirements for conducted RF immunity (C-RFI), electrostatic discharge (ESD), electrical fast transient burst (EFT), emissions, radiated RF immunity (R-RFI), surge, etc. For environmental tests, the product probably has requirements for temperature testing for Cold, Dry Heat, Damp heat Cyclic, and Damp Heat Steady State, etc. Vibration testing may include tests for Shock, Bump, Seismic, and others. Write all the various requirements down by name. I like to place them in alphabetical order. You can organize yours how you wish.
The next step of the process is to determine what tool you will use to keep track of the requirements. The two easiest choices for me are a word processing program or a spreadsheet program. I elected to organize my conflicting requirements using a spreadsheet program with each tab or worksheet containing the comparison of conflicting requirements for one of the areas identified in step one (ESD, for example).
Figure 1 is an example of the tabs used in my standards comparison spreadsheet.
Notice that I arranged the tabs in alphabetical order. You may elect to order the tabs by type, such as all EMC-related requirements are placed first, followed by vibration, then environmental. However you want to do it is up to you. The important thing is to be able to locate the information in a hurry when you need it. It is almost impossible to remember it all.
I have seen others use a word processing program where they inserted a table for each item they wanted to compare. Your organization may use some other requirements tracking program.
The third step is to start filling in details for each requirement. You will need a copy of each of the readily available standards you are interested in comparing.
Figure 2 is an example of the conflicting requirements I put together for emissions. I have filled in as much information as possible without overly complicating it with too much detail.
Figure 3 is an example of the conflicting requirements for ESD.
The examples above will give you a good idea of what information should be used to compare conflicting requirements.
Criteria for Acceptance
You may have noticed that I have left out criteria for acceptance in the above conflicting requirements comparisons. This is because I wanted to keep things simple. By adding criteria for acceptance, each comparison would have been much harder and more confusing to read. This does not mean that knowing the criteria for acceptance is not important. It certainly is. The problem is that each standard has its own definitions about what defines pass/fail under various conditions. Some standards require only testing for correct functionality after the test has been performed. Other standards require all functions to continue showing no degradation during the test. I feel that the comparisons for the conflicts in criteria for acceptance are best left to a separate document.
Conclusion
Part of the job of a compliance engineering professional is to effectively communicate the regulatory requirements to all key stakeholders of the product currently in design or production. Often these requirements are conflicting. The best way I have found to perform this task effectively is to get organized and construct a conflicting requirements document that maps out where conflicts exist. Once constructed, this document becomes one of the most useful items found in a compliance professional’s “bag of tricks.”
