Design Pattern for ATE

[BillMe]

Looking for suggestions on the best design pattern (using OOP) for an automated test environment application. The current code (LabVIEW only, no Test Stand) has it's own UI and support VIs for selecting the test environment, sequence of tests to run, running a sequence, evaluating test results and outputting pass/fail reports (HTML) and test measurement result files (TDM). The intent was to give the developer a framework where he/she can concentrate on writing the actual tests. Unfortunately, in the environments where it is used, developers always find the framework lacking for their needs and so tend to have their own version by the time they are done. This thing does not scale well nor is it very flexible.

This framework was originally written with LV 6.1. I put it in a LV2011 Project, but it won't build due to its sheer bulk so it's being run strictly under the development environment (which I hate doing). The whole framework needs a face lift.

Any suggestions? I've looked at the AF but it seems "over-qualified" for this, plus I don't have a bunch of parallel processes in this case. Things run pretty much sequentially from the get go just by the nature of the testing.

[Tarek]

It seems that you're trying to design your own TestStand in LabVIEW. I do not have any suggestions as I do not have enough details about your system, but I found this presentation which can be useful to have before starting.

You also have the option to contact National Instruments' Alliance Partners for help with developing your ATE.

I can be more helpful if you have specific questions in mind.

[Mark_Yedinak]

You could create pure virtual class that defines your test step API. Methods for the class would consist of things like setup, teardown, execute to name a few. Your developers could use this base class as the template and API for their tests. The methods regulate the format of the data exchange between your engine and their test. I would also recommend that you use packed libraries so that your test steps are basically plugins. Your test sequence would need to contain the name of the appropriate plugin to use in order to invoke the correct test step. This model is flexible and easy to extend.

We are actually investigating using this same approach for our test system. Our current system uses TestStand and we are going to investigate TestStand 2012 ability to use dynamic dispatch to invoke our test steps. It should be interesting. We use other features of TestStand so it would be nice if we can make this work. In your case a LabVIEW only implementation should be fairly straightforward.