Suitable Architectu​re - Discussion

Question

Hi,
  I am thinking about an architecture which should offer both better software reusability and should include less testing time for following requirement. Application needs to be developed for testing 100 different DUT’s and application will be developed in stages – like 1st month for 10 DUT’s (including testing and validation of the test program) and in the second month for next 20 DUT’s like that. We can use TestStand and LabVIEW for this. I have following architecture in mind.
  For better software reusability we can create set of reusable VI’s and these VI’s can be called from TestStand sequence. Individual sequence can be created for each DUT and this sequence will pass required information to LabVIEW VI based on DUT type.
  Using this approach we can reuse all LabVIEW modules. This approach will work well as long as there is no change in LabVIEW code.
  If I want to change any of the LabVIEW module which is called by all DUT test sequences than we have no option but to change the code and test all test sequences. So when we are closing to release 100th DUT sequence and if we are changing one LabVIEW module which is called by all sequences than we need to test all 100 DUT sequences which is not at all reasonable.
  To avoid this problem we can develop a separate VI, when we want to change a reusable VI, so all existing sequences won’t change in any way and new sequences will call this new VI so that we don’t have to test old sequences.
  I am seeing a problem here, if we are going to add new VI’s for each change, than in the end we will have many VI’s with slight changes and maintenance will be a real problem.
  Is there any better way to overcome this? Is there any other better architecture to approach this kind of applications? Kindly update me with your thoughts
  Thanks,
Venkatakrishna

Answer 1

Thanks a lot for the suggestion; definitely this will work well as long as user is not installing different releases in a same folder.   
Yes, this would be a requirement not to overwrite VI's.  I like your idea of having the sequences in local folder and maintaining the "released" VIs in separate folders.  Not sure what you mean about "We can also find a way to navigate through multiple folders to list DUT types; just some more work", it must be specific to your setup.
Right now I am using TestStand just to call VI’s and to move parameters to them. I have LabVIEW code module which will do complete testing and will pass results to TestStand. Breaking this LabVIEW code in to drivers and calling them from TestStand will help us in implementing this better? I am sure this will slow down the execution speed because TestStand is much slower than LabVIEW especially when VI is called in a TestStand loop.
I have seen maintenance benefits by creating sequences/subsequences that replace "bloated", test all-in-one, VI's.  If the VI is written cleanly with good use of subVI's it is not too tough to migrate a top level VI to an equivalent subsequence.  It could actually improve performance in some cases.  For example the initializing of instruments in a single setup section.  However, your example loop example may be better suited in a VI.  I am not sure though, if the TestStand loop would perform that bad if it is optimized.  For example, it would help to be run in a subsequence with the tracing off...
Overall, my main suggestion is to share code in a development environment, using source code control tool.  Literally sharing the exact same VI on an executing machine will cause the maintenance headaches that you have already anticipated. 
I agree with Felix that you should keep track of VI versions.  I have used MKS Source Integrity in the past and it was a good SCC tool that would generate reports so you could get a quick snap shot of which projects use which versions of code.  It also provided a checkpoint feature that would resynchronize your sandbox to the versions of coded that were checkpointed. Good tools like these can really make your life easier unfortunately it is not a free tool.  I am not sure what features the free ones have. Changing the VI name could work but it could come at a cost of reloading all the sequence prototypes and re-linking VI's depending on when the name change occurred.