That Day the CPK Report Came Out, the Room Was Silent for Three Seconds, and the Boss's Face Turned Green
Remember? About five years ago, our factory's newly introduced gallium nitride (GaN) power component project had just entered mass production. One afternoon, the Reliability Manager suddenly rushed into the conference room, pale-faced, holding a report. He threw the report onto the table, where large red letters declared: System-level MTBF was only 50,000 hours. The entire room fell silent for three seconds, and then the boss's face immediately turned green, because the original commitment to the customer was 100,000 hours. The conference room instantly erupted into a heated discussion, with everyone starting to say, "My module has no problems!" "My yield Cpk is 1.08 here!" But the problem was, the overall system simply didn't meet the standard. So who was ultimately responsible?
Where Was the Problem? Not a Single Component Issue, But an 'Overall' Issue
To put it plainly, this scenario is a typical "Reliability Apportionment" problem. Frankly, many times we engineers are only concerned with making our own components or modules the best they can be, thinking that if my Cpk is 1.33, and my DPMO is only 50, then all is well. But did you know? A complex system is composed of thousands of components. Even if the reliability of each component is "not bad," when put together, the system's overall reliability might greatly surprise you.
So the key is that reliability apportionment is a method that allows you to reasonably break down and allocate a "system-level" reliability goal to each "subsystem" or "component." This way, everyone knows what their department's goal truly is, rather than blindly saying, "I'll just do my best." This is like a company setting an annual revenue target and then breaking it down to each business unit and each product line.
How Is It Actually Done? Working Backwards from System Goals
In practice, we usually start by working backwards from the "system goal" given by the customer or market. For example, the customer requires your power supply system MTBF to be at least 100,000 hours. At this point, you can't just tell all departments, "Everyone make your MTBF 100,000 hours"; this is unrealistic, and some components are inherently more prone to failure.
You can do this:
- Draw a system architecture diagram: Break down your entire system into several main subsystems, and then further down to key components. This diagram should be clear, like a block diagram.
- Define the importance and complexity of each component: Some components are core functions; if they fail, the system crashes directly. Others are just auxiliary and have little impact. Some components are highly complex, expensive, and difficult to repair. All these must be considered.
- Choose an apportionment method: Common methods include "equal apportionment," "weighted apportionment," or the "Mendel-Grodsky method," among others. To be honest, the most common method we use in our factory is a modified weighted apportionment method, which assigns different weights based on factors such as component failure rate, complexity, and repair cost.
* The main control board might have a risk weight of 0.4 due to a large number of components and complex signals.
* The power module, because it withstands high voltage and high current, is a failure hotspot, so its weight is set to 0.5.
* The cooling module is relatively simple, with a weight of 0.1.
* In this case, the target MTBF for the main control board will be much more stringent than that for the cooling module, possibly needing to reach 250,000 hours, while the cooling module only needs 1,000,000 hours (this is just an example; actual calculations would be more complex).
In other words, you must impose stricter reliability requirements on components that are "more prone to failure" or "have a greater impact."
The Most Common Pitfalls: 'Guessing' Numbers and 'No Ownership'
The biggest pitfall we've encountered is "guessing" the apportionment numbers off the top of our heads. Sometimes, to rush things, or because no one really understood reliability apportionment, a few arbitrary numbers were just handed out to various departments. The result was that some departments felt the target was too high and impossible to achieve; others felt it was too low, easily met the target, but actually had room for improvement, thereby dragging down the overall performance.
Another major pitfall is "no one taking ownership." The Reliability Manager allocated the numbers, but department heads felt it wasn't their business, or thought the target was unreasonable, and simply ignored it. The result was that when the system test failed, everyone started to shirk responsibility. Reliability apportionment is not just the Reliability department's business; it requires all-hands involvement.
One Thing You Can Do Today
Go back and look at the product you're working on, and try drawing a simple system architecture diagram.