In high-precision optics manufacturing, dual-component module assembly faces significant yield challenges due to the complex interplay between component tolerances and final performance. Current inefficiencies stem from poor pairing and uncertain specification limits, necessitating a resource-intensive "mix-and-match" bottleneck that results in substantial labor and material losses.
This paper presents a data-driven solution using multivariable regression (MVR) modeling to establish a transfer function. By defining module key performance output variables (KPOV) as a function of component key performance input variables (KPIV), the model identifies critical to quality (CTQ) drivers and their specific sensitivities, enabling precise performance prediction prior to physical assembly.
The implementation of virtual component selection facilitates strategic digital pairing to ensure compliance with performance targets. This approach successfully resolved the physical "mix-and-match" bottleneck, yielding an operational efficiency gain of 30 labor hours and a financial reduction of $11,000 per week. Furthermore, the model directly improved both component and module yield while enhancing overall module performance. It also enabled the refinement of specification limits based on empirical sensitivity analysis rather than theoretical estimates.
By transitioning from reactive testing to proactive virtual selection, this scalable framework provides a robust methodology for improving assembly yields and performance. This approach effectively reduces operational overhead and offers a template for optimizing complex multicomponent processes to module products across various technical sectors.

Today, I'd like to introduce so-called virtual component pairing of our optical system by using so-called multivariable regression modeling. Here, my name is Weonwoo Kim. We have some collaborators from MKS.
Here, I would like to mention first what actually motivated our study here. I want to start from the so-called problem statement. In our module, we have some issue in two ways. One is that we do have low yield to assemble this module, where we actually measure so-called Zernike coefficients. As you see here, this is nothing, but we are actually evaluating so-called geometric distortion of the optical wavefront.
Even though the two components for this module build, they are all within spec. However, we have experienced a lot of the yield issues. That means we have to do couple of the rework or iterations of the assembly, at the same time, the testing.
We had to do a lot of the iterations of the mix and match of the component and then testing. It really dragged us down in terms of the operational efficiency, and then again, back to the low yield. In the beginning, we tried to use this module versus two components as the data to evaluate or to validate multivariate regression modeling.
However, we did have only eight modules at that time, about 6 month ago. We actually jumped on the other case where we do have more data collection. By using the module A, we actually have another module, so-called module B, so that we can actually send these two modules to our customer where they actually do system integration.
In our case, we do have two modules, and then we have to collect the data, so-called Zernike coefficients, Z2 through Z9, total eight. Then in the system level, customer measures so-called Strehl ratio.
The ratio is basically they have the ideal target wavefront. Then because we have to integrate multiple modules, and within module, we have, again, multiple optical lenses. That's why there might be some distortion, or there is some changes. So Strehl ratio actually indicates that after this integration, how well this wavefront actually match to the ideal target of the system.
So ideally, one is the best number, and below one is getting worse and worse. So that for this presentation, our goal is that by using these two modules and to collect the system data, we try to apply the multivariable modeling.
From there, as an application, we try to get not only spec setting or spec optimization of these two modules based on system spec; also, we try to actually focus on how we are able to actually pairing module one, module two to have the better performance, and so on, which I try to address in the following slide.
This is for beginner of the multivariable regression: what it's all about. In this case, we use JMP software. Then the goal is that, based on our measurement data, collected data, we try to generate transfer function. This is nothing but actually assembly process integration to product.
We try to actually understand what is the relation between those of the input variables against the output performance. Once we have the transfer function, we can have so-called key performance input variable from module input parameters so that, by using transfer function, we are able to find out what might be the key performance input variable out of many input variables which actually driving the system performance.
Once we have that, we actually go to next step, so-called sensitivity between the key input variables against output performance. In this case, by doing that, we are able to rank what might be the most critical among key performance input variables, by which you are able to actually focus on which should be most critical in terms of the customer or system performance.
This is basic groundwork; once we have this identified, then time to apply our learning, so we can define the spec of our module, or even if spec is already given from the customer, then based on the system spec or requirement, we can actually fine-tuning our input variables based on this transfer function.
Another application is that because we are using two different modules for final system, and then we should have two group of the assembly component. For example, module A, we have 10, module B, we have another 10. Then, rather than just mix and match by trial and error, we can do actually using transfer function so that we already know, based on this transfer function, we already know that what is the output performance.
So 10 by 10, for example, we can generate 100 output performance. From there, we can select from the best, and then down one by one until we use up all 10 combinations. That's we try to address from this presentation.
Before we actually jump on the actual transfer function or plot, we just want to share that what might be the R-squared versus residual because we need to find out is it really reliable data or not, so sanity check. This is the one. In this case, we use about 34 data sets. Then, if you see, we have the R-squared about 0.56. That means our correlation is about 0.75. I think that seems to be pretty acceptable value. Also, we can see the root-mean-square error, and so on.
The other checkpoint is that we have actually more relative residual between the measurement of data and our modeling. Two things: one is that based on different values, we have pretty much symmetrical spread out, even though we have a little bit skewed here.
Same data set, but if we convert into so-called standardized results and residuals, more absolute comparison, and then we can see that mostly within 2-sigma, we have some 3-sigma. However, the bottom line is that everything is less than 4-sigma range, so that I do have the confidence that, yeah, we have some reasonable transfer function, and I can use it for further study.
Now, let's go to next step here. Here, it looks it is a little bit busy chart, several key observation here. One is that, based on the transfer function, we visualize it. Number one, in terms of the key performance input variables, we start with two modules.
Each module have eight Zernike coefficients, where we actually try to take short table to explain what is the physical meaning of each Z values here. We have eight and eight from two modules, total 16 input parameters. However, based on the module data and then system data, we are able to generate the transfer function.
Finally, we have six key variables. We do see here from module A, we found out four should be a critical one out of eight. However, in case of the module B, where we don't suffer any yield issues, where only two Zernike coefficients are critical out of the eight. That's actually one point we try to address because now we do know where we need to focus our engineering or operation resource to actually make it better.
The other one is that if you look at the graph here, we can see sensitivity from key six input parameters. For example, in case of the module A Z3, once we're at the center, by a couple of the plus/minus tolerances, it does not affect our system performance.
However, if you go really close to the control limit or spec limit - this is not your spec, that's why I call the upper limit - and then we start to see the marginal performance, and then we are losing the yield.
However, the other case, for example, module A Z6, you can see what it means. From the target, we have the tolerance plus/minus. In case we actually go to the lower side, yeah, we start to see marginal performance.
However, if you go to the higher upper level from the Z6 point of view, it actually improve the performance of the system. That said, in this case, module A Z6, we should have some proper low spec limit.
However, in case of the opposite side, actually, we don't have to have any spec. Then, in case of the module B, for example, we start with some reasonable so-called control limits, and then based on this study, we see that, okay, we can actually make it wider, bigger tolerances with this specific Zernike coefficient.
That's the things we are going to collaborate with the customers. So I want to say, based on we found out the key performance input variables with sensitivity, and then there is some room to improve or to finalize the spec based on the customer input.
The other one point before we go to next step, as you said in the problem statement, in module A, we did suffer low yield because of so-called module A Z9. This is nothing but the mismatch between the center image versus the edge of the mirror. However, we identified that module A Z9 should not be really critical in terms of the system performance.
I think that it may be in system side, more care about the center image rather than the edge of the wavefront. That might be the real case so that we can actually negotiate with the customer, is there any opportunity to open up the tolerance of Z9 spec? That's the learning.
Once we have this spec potential spec negotiations, and now I really want to focus on the remaining time on so-called, we try to leverage the virtual pairing of the module. Because as I said, we do have, we just applied the two modules to customer.
In this case, I want to use 34 module A and then another 34 module B against the system performance. This is the actual system data of 34 system data, actually 34. Then because we did have the module data of each 34 and 34, and plus, we actually developed the transfer function. So now, 34 by 34, so we can have more than 1,000 of the system output data.
Now, because we do have 1,000 data rather than 34, we can pick one by one from the best module A, module B combination, and then next one, another combination, and so on.
This is what we have done by using the transfer function we developed. Here's actual our data here. If you compare this baseline we already built in the customer system, and this is the likelihood we can actually have. If you compare between baseline and the virtual pairing, in average, you see that virtual pairing definitely have the better performance, higher values with good statistics here.
The other one is if you look at distribution, so we have more symmetric for the actual build. However, if you use so-called virtual pairing, not only better in average performance, but we actually have much, almost 2x better actually the output performance by using so-called virtual pairing. That is the key actually the takeaway from this transfer function development.
As I said in the previous slide, Z9 case, we should have some opportunity to actually open up the current tolerance. We talked with the customers, and then we actually built three module A with actually out-of-spec so that we try to actually verify our projection whether these three out-of-spec can pass their system requirement.
We actually sent it months ago, and we start to have the output. Then, because we do have transfer function, so I use our three out-of-spec module data of that module A, by using existing, which we already shipped to the customer almost for past 2 years, we use 46 module B with three module A.
We did the same approach here, and then we found out that at least two should be passed based on the current spec from customer, and one seems to be marginal one.
We looked at more carefully about this one marginal module A because we have all the collected coefficient of the Zernike. We found out that the Z4 and Z6 of this one marginal one is actually in the edge of the spec. So Z4 is basically focusing, and then Z6 is nothing but astigmatism. We do know why the third one is marginal performance.
We do have our projection based on the transfer function we developed. The customers start to actually integrate it, and then they report us that one passed out of three, and they're going to finish up the integration by end of next month, September.
So that might be another check of this validate our projection of the modeling. This is the key takeaway, optimization by using multivariate regression and virtual pairing. Then based on that, we have the next step. So we already know that module A, we have some opportunity to negotiate with customers in terms of spec.
The other one is that in the problem statement, we mentioned that module A, even though the two components pass the spec, we have hard time to actually make this module pass.
We are going to build more components for this module A so that we have some preliminary data about eight modules with this component. However, we actually are building more component one and two so that we have more robust actually the transfer function based on the sample size. So that is actually ongoing right now, and we try to finish up in next quarter. That's the planning we are actually shooting for.
Then, if I sum up our learning, based on the collected data of two modules and the system output performance, we are able to generate the transfer function by which you are able to identify what should be the key performance input variables of the modules.
From there, based on the sensitivity of the output and the input variables, we identify which might be the first one to attack in terms of the performance or yield. As an application side, because right now, spec is borderline, I mean, it's in the middle of the setting point, so we can actually help the customer to set not only the target, but also the spec limit. Then also, even necessary, we can do additional fine-tuning based on our transfer function.
Then again, we actually addressed that by using this transfer function, we can do virtual pairing of module A, module B. By doing that, we can really reduce the assembly rework because we are able to identify which is the best pairing one by one. At the same time, we can actually reduce the testing iterations.
So this is actually key takeaway from our company side, not only in spec, but also in operation side. If I summarize it, basically, we can maximize the manufacturing performance and efficiency in terms of the improvement in yield, in two ways.
One is that spec negotiation and then cycle time because you are able to use the virtual pairing. Also, we are able to predict the customer performance, so that we can make the better quality. Because of the virtual pairing, we are able to reduce dramatically so-called mix and match and then testing of the rework.
We actually identified those things in terms of business side. This is very accepted from the management, so we are going to continue for the plan we have addressed in previous slide. Thank you for your understanding. Then thank you. Thank you for your attendance.
Thank you.
Presenter
Skill level
- Beginner
- Intermediate
- Advanced