You may often heard this word “Correlation” if you had some experience in developing a system with reference to other system. By reference, I mean you might have been asked to develop a production system from an R&D system as a reference. Or you might have been asked to develop a multi-line production system from the reference of single-line production system as a reference. Or within an R&D this term could be used to compare the results of similar systems which should produce similar results. Nevertheless, correlation is not limited to only such scaled or production systems.
So what is correlation?
Correlation is a systematic approach to compare the two or more similar systems. The result of that comparison would give details whether all those system produces similar/same results or if there is any deviations/mismatch between the compared systems.
How significant is this correlation?
Correlation can easily confirm if your job is done w.r.t that system which you’ve been developing, or if you still need to continue debugging that system. Correlation can help you to narrow down your debug approach. Correlation can help you to give any calibration offset required between two systems.
When to use correlation?
Whenever you’re called upon to develop a system with reference to other system, then keep this correlation in mind.
What are precautionary measures?
Ensure that reference system is highly repeatable. i.e., for the same set of inputs, does the reference-system gives the same results for numerous run.
How to do correlation?
The method to do correlation varies from system to system. Here I have tried best to generalize the correlation process.
Step 1: Run the reference system for same set of inputs and record the results. Repeat this step numerous time until you’re confident that this reference-system is consistent. If this step results are always inconsistent, then there is no point in going ahead with correlation and you would most likely see that correlation is always failing. Unless it’s repeatable in reference system, you will not have the consistent results to compare with newly developed system.
Step 2: Make note of the consistent results from reference system (ref-sys-inputs vs. ref-sys-results).
Step 3: Give the same input to the newly developed system and record the results. Same as in step 1, repeat this step numerous times. If this step results are always inconsistent, then there is not point in going ahead with correlation. Unless it’s repeatable in the developed system, you will not have consistent results to compare with reference system.
Step 4: Make note of the consistent results from developed system (dev-sys-input vs. dev-sys-results).
Step 5: Compare the results. Here you could look for exact match (in case of digital systems) or look for relative match (in case of analog systems). The comparisons depends on the project’s demand or system’s responsiveness.
Step 5a: If the results are equivalent, then your job is done..! Correlation has passed. Yay..! Your job done!
Step 5b: If the results are not equivalent, then correlation has failed. You have to continue debugging to figure out why this correlation mismatch occurs.
Correlation failure could be due to various reasons, few of them are…
- Hardware related issues.
- Software related issues.
- Mechanical issues.
- Supporting device issues. and so on and on.
The next step after failure would be to go back to system-level and check the various components in the system. Do the root-cause analysis. Figure out which component is misbehaving. Narrow down from gross level to the subtler level of components behind this failure.
Ajay is a professional developer and architect of NI-LabVIEW applications with extreme interest in getting the hardware connected to LabVIEW and automating the stuff. Recently he is also putting his hands in NI-TestStand to get very dirty on it. He is also a good mentor for the various interns in his career. He is ready to help the people in techie roles.