Contrary to what most people believe, high reliability, short development time and low cost are not mutually exclusive factors in developing new products.

By Susanne Otto, FORCE Technology

Currently, there is a wide range of reliability tools that are used by companies to varying degrees. These are tools such as requirement specification, DFMEA (Design failure mode effect analysis), design review, derating, HALT, design for vibration, shock, thermal, humidity and EMC requirements, lifetime estimation, CALT, HASS and more.

The tools and their use are extensively described in the literature, including in the SPM report 181:” Practically applicable reliability tools”. Yet, some companies find that they get lost in the jungle of reliability tools and have doubts as to which tools they should focus on in order to get the most value with regard to the effort put in. Likewise, they may also have doubts concerning how and when in the development process the tools are most optimally implemented.

If they don’t have the necessary knowledge in-house, they need some assistance to develop a reliability strategy with clear goals in terms of desired product lifetime, acceptable rate of failure or service period and to determine which reliability tools are most important in achieving those goals. FORCE Technology has developed this knowledge in connection with the performance contract entitled” A proactive paradigm for electronic product reliability.”

The project builds on the range of tools such as lifecycle estimation, module-level error analysis methods, and Root Cause Analysis developed in collaboration with Danish companies in the previous project “Reliable product development based on the Physics of Failure.”

The path to reliability strategy

The results of the project bring about a paradigm, or a system, that helps companies to define a reliability strategy that prioritises the necessary reliability activities in relation to where the companies are in their development process, product type, use environment, quantities, price, available knowledge and resources, as illustrated in Figure 1.

Figure 1. The paradigm converts relevant conditions for product development into a strategy on reliability, listing the tools that are proposed as priority.

In practice, users answer 20 questions about the product, its use and the company. The paradigm then converts the answers to the questions into a proposal for a prioritised list of the reliability tools that are considered most important to implement in the given situation. Lists of prioritised tools are followed up with links to guidelines and checklists on the application of the individual tools.

These guidelines and checklists are based on new knowledge from the project combined with many years of experience. All this is made available to Danish companies.

If needed, the paradigm is supplemented with consultancy on and facilitation of the use of the tools as well as new tools that are developed upon requirement.

Practical cases

The development of the paradigm and the new tools is, to a large extent, based on acquired international knowledge and a number of cases within the development of software, hardware and mechanics.

At present, a comprehensive case is being worked on with a start-up that is developing a household appliance from scratch. The case demonstrates the establishment of coherent strategy on reliability and the optimisation of the use of reliability tools through the development process (see Figure 2).

The actual tools, such as requirements specification, SW review, etc., are implemented as the product is developed and the effect of the various tools is subsequently evaluated in collaboration with the company. Moreover, the case is used in connection with the verification of the paradigm.

Figure 2. Reliability strategy and associated tools for a household appliance.

A precise requirements specification is an important foundation of most reliability strategies. This also applies to the start-up company. Significant time and money can be saved in the development process by choosing clear success criteria and specific procedures to verify every requirement in terms of:

  • hardware
  • software
  • mechanics
  • lifetime
  • use environment.
It is FORCE Technology's experience, that reliability and robustness issues often can be traced back to a requirements specification that does not contain all the relevant parameters or is not adapted to a given product's actual usage or use environment. In some cases, the requirements specification from a previous product is reused, without taking the application of the new product into account.

Thorough analysis reveals ambiguities and uncertainties 

A thorough analysis of existing materials that relate to the new product's actual situation often reveals ambiguities and uncertainties that span multiple fields, thus leading to the risk of not taking altered requirements and conditions into account. A review of the requirements specification, or a requirements specification workshop concerning software and hardware, are effective tools for revealing this.

Another case deals with conformal coating of electronics for challenging environments. The case forms the basis for developing a decision tree or a methodology for making decisions regarding the introduction of conformal coating. The decisions relate to, for example, what extent it is relevant to introduce conformal coating, whether cleaning before coating is necessary as well as choices between different types of conformal coating. Moreover, different methods are examined in order to test the reliability of the coating. 

In practice, a test print has been developed with different variants of conformal coating and cleaning. The prints are exposed to environmental effects such as temperature variations, humidity and salt. Furthermore, different methods are evaluated; SIR and CoRe to quickly assess the quality of conformal coating.

Scaling between exposure of components, modules and systems is a major factor in the strategy on reliability and intelligent testing. Methods to determine whether influences such as temperature, humidity, vibration, shock, and EMC conditions remain unchanged, become worse or better as one transitions between the different levels are developed in conjunction with the paradigm.

However, the most important part of the reliability strategy is the understanding of where protection is placed in relation to environmental or functional influences such as EMC. Is it most optimal to introduce protection on a system level, print level or on the individual component? For large systems, such as wind turbines, it may be obvious that it is not optimal to protect the electronics exclusively on a system level.

The methodology is demonstrated on a streetlamp with electronics modules. In connection with the case, the streetlamp including converter for supplying the LED lamp with solar energy is subjected to temperature, humidity and electromagnetic fields.

Finally, various SW tools are tested in connection with other cases. It is partly about tools that help with modelling and development of SW, so the developer has the opportunity to think at a higher level of abstraction, and partly about tools that support an agile development.

Reliability from an international perspective

In connection with the project, a fully booked conference ”Reliability strategy and tools” was held at FORCE Technology in Hørsholm, Denmark on 13 November 2019. The conference provided the latest knowledge on reliability from both Danish and international perspectives, along with practical cases on reliability.

At the conference, Albertyn Barnard from ASML in Eindhoven, Holland and former Lambda Consulting, South Africa, gave an outstanding presentation on common mistakes in reliability engineering and how to avoid them. The presentation is based on the chapter written by Albertyn Barnard for the book "Reliability Characterisation of Electrical and Electronic Systems."

Peter Drennan from Baxter in Lund presented his decision matrix for determining whether a system-level or a component-level reliability demonstration test must be performed. The decision matrix was demonstrated on medical products developed by Baxter.

The conference also offered the opportunity to hear about the results of the project, the paradigm and its use, as well as some of the cases that have been part of the background of the project.