Suitable Architecture - Discussion

[venky_in]

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 1^st 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 100^th 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

   

[paulmw]

My suggestions... 

Definitely reuse your code.  Don't reinvent the wheel.  Use a source code control program to track revisions.

Use TestStand to deploy your test applications as separate "releases".  The deploy tool will create a "package" of all* VI's in the sequence and workspace and re-link all references.  This deployment package will only contain what is needed for that application.  It basically creates a copy.  Look up this tool in the online help to understand its options and functionality (it can also create an install which can be handy)

If a VI changes from subsequent development it will not automatically break the previously deployed version.  If it is a bug fix that is needed for the previous deployment you will have to incorporate the bug fix and create a new versions of the deployment.

With this deployment approach you may end up with multiple versions of the same VI on one computer but it shouldn't affect the other applications functionality.

Another suggestion that I have found useful is to have one computer to develop on and another that only runs the deployed test and is not used for development.  The prevents the opportunity of using the wrong version of a VI because the development computer only has one version that is linked to the source code control program.

[venky_in]

Hi,

 

Thanks a lot for the suggestion; definitely this will work well as long as user is not installing different releases in a same folder.

 

Right now I have modified TestStand process model to search and list all DUT sequences to the user, so that user can choose a DUT type to test. Placing all DUT sequences in a single folder irrespective of releases will simplify the programming to some extent. We can maintain different folders only for LabVIEW code. We can also find a way to navigate through multiple folders to list DUT types; just some more work.

 

Other than this, is there any other approach we can take to reduce future maintenance time?

 

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.

 

Thanks,

Venkatakrishna

[F._Schubert]

Just some idea to brainstorm: Whenever you release a set of VIs for DUT n, you put a postfix for of DUT number like __001, while keeping the name intact. Once you find that MyVIWithABug__79 has a bug fixed, you easily see which other previously realesed test might be affected by the same bug. That way you at least know, which tests are affected and don't need to go through alle DUT tests.

Of course, this involves a lot of manual work of keeping reused VIs in sync, document which have been checked in, which were not updated yet ...

I think there is an OpenG tool to create such naming conventions (or can be modified to do so).

An approach I started to use comes from the other way round, I mark certain VIs as being reusable by putting them in a specified 'reusable' folder. These VIs are created with special care (documentation, graphical icon, default values, testing ...) and I'm aware that any change/bug fix will affecta lot of my projects. Propaby for those VIs, a document should be provided to see which projects (in a general sense of project not lvlib) link to them.

In addition there could be a set of (top level) VIs, that are not for reuse  With those you would be free to play.

Okay, it's just thoughts at night from my side. But I'm interested what evolves out of this discussion for my own work as well. Also thanks to Partha which brought my attention to this thread after the holidays.

Felix

[paulmw]

---

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.