It can be a thing of nightmares for those who have had bad experiences, or just another point on the Gantt chart for others. But it’s certainly a delicate subject that often doesn’t get enough attention.
This article discusses pre-compliance testing, which can greatly reduce the risks during formal compliance testing, but which can get put off or is by-passed altogether for a variety of reasons.
As product developers, pre-compliance is all about reducing risk and validating product design. So, it makes no sense to put it off. After all, why avoid mitigating risks during the development cycle? Generally, we find there are four main reasons why companies don’t always validate their product against defined standards, which ultimately reduces the need for last-minute changes:
The product isn’t developed enough
When budgets are tight and the pressure is on to be as efficient as possible, it can be tempting to put off pre-compliance until you have finished the prototype development. Perhaps you already know there will be changes to the PCB, the form factor or the layout, or you don’t have the peripherals and mechanical parts yet.
Requirements and specifications haven’t yet been frozen
It can be hard to know how to approach pre-compliance if you don’t yet know what all the product requirements are. Maybe certain markets are still being discussed or not all product applications have been considered, such as using it in an ATEX or medical lab environment.
The software isn’t ready yet
Initial testing has highlighted some software bugs and with looming deadlines all the effort gets diverted into fixing bugs and developing more features. The thought of using limited software resources to implement test modes and support pre-compliance can be quite daunting.
The rest of the system isn’t ready
Sometimes the full system comprises a number of products and it’s natural to want to wait until all components are ready before testing. This can provide more representative measurements and reduce overall costs, but it may mean the product development cycle is already finished by the time you are ready.
Ultimately, there are lots of compelling reasons why putting off pre-compliance seems like a good idea. But each one pushes the risk further back and quite often makes implementing any fixes much more difficult with issues such as:
- Going round the development loop again – If you’ve waited until the product has been developed and is ready for formal compliance, then any identified problems can take you back round the development cycle. This might mean having to re-do system testing, updates to manufacturing packs, re-doing any other formal compliance measurements, and getting back team members who have moved on to other projects.
- Increased overall cost and timescales – Catching product design issues later in the development stage almost always has a bigger impact on project costs and timescales than if they had been identified earlier. Additionally, lead times for re-booking test houses and having new parts made can significantly increase overall timescales and/or be very expensive.
- Mismanaged expectations – If customers or clients believe the design to be complete, frozen, and ready for formal compliance, a failure closer to market launch can be a huge blow. Marketing and sales teams may have to have difficult conversations to change expectations on the product and justify delays to timescales.
- Target markets not being achievable – Unless you are familiar with the particular standards, markets and test methods, then the pre-compliance testing stage may be the first time you truly understand exactly what is involved. This can be a shock if you find out that the current design needs to be tested in tens of different configurations which can make it very expensive.
What can go wrong?
It’s also worth considering the effect on team morale through all these consequences. It can be very deflating and stressful to try to implement a fix for a product that the team thought was complete.
Two recent projects highlight just what can go wrong when companies don’t validate their product at an earlier stage in the development cycle against defined standards.
In the first example, 42 Technology were appointed to re-develop an established small personal radio device with the aim of improving its robustness and reducing manufacturing costs. However, as this product was already on the market the development cycle had a very short lead time. There were also constraints on the product dimensions so that current customers would be satisfied with the new design.
To keep costs down we tried to develop a simple PCB solution, which followed reference designs, but it didn’t have a good enough ground return path to radiate effectively.
Ultimately, the unit failed on the third harmonic emissions and forced a more complex PCB re-spin. In an attempt to limit the potential cost increases, we then developed both monopole and chip antenna variants.
In the end, a more complex PCB with a monopole antenna had to be used because there wasn’t sufficient space to isolate the chip antenna from the rest of the PCB. This process resulted in a very rushed and stressful development cycle with a product solution that wasn’t the lowest cost option.
Things could have gone worse, but the lesson here is that a longer development cycle, with fewer constraints from earlier versions, could well have led to a smoother compliance process and lower product manufacturing costs.
In the second example, we were appointed to help turn a prototype that hadn’t undergone any pre-compliance into a certified product.
The client had rapidly developed a prototype to solve a customer’s requirement for their system. After finding great success with it, they wanted to produce a larger quantity of units but certified for other target markets and customers.
During pre-compliance testing, it immediately became apparent that the prototype architecture would never pass formal compliance tests. Additionally, an antenna added by the customer to the product also meant there was an infinite number of ways to test it for FCC compliance because the end user could change the antenna length according to their specific needs.
It was a major blow when the client realised their product would need a full redesign, the installation process would need completely changing and the timescales were not achievable; particularly as they had end-customers waiting who thought the solution was only a few months away. All these issues could have been alleviated with pre-compliance measurements before releasing the prototype.
Investing in pre-compliance
So, when is the best time to invest in pre-compliance testing? And the answer is: as early as possible.
We always recommend clients set pre-compliance as a project milestone when starting their planning process and they need to stick to it too.
It’s all about risk management and unfortunately the impact of failing compliance tests can be very significant, costly and damaging both to the business and its customers.
- 42 Technology (42T) is a product design and innovation consultancy, based near Cambridge (UK), that helps to create products and manufacturing processes for some of the world’s best-known brands, as well as start-ups and SMEs. It works across three key sectors: industrial including transport and energy, consumer, and healthcare and life sciences.
Author details: Rowan Beale is an engineering physicist and project manager at 42 Technology
