An architectural question: communication between 2 ATE applications

[Jumper_Bones]

I am about to embark on creating two Windows GUI-based applications: one to control our DUT (which will also be supplied to our customer) and the other to automate the control of the test system components that perform the electronic testing on the DUT (which will remain an in-house application).

The "DUT" application will be supplied in binary form to our customers most of the time.  However, there will be some customers (and technology partners) who will also get the source code.  This mandated that we use Visual Studio 2005 for its creation.

The "ATE" application can be authored using any development environment.  We bought the NI Developer Suite with TestStand for this effort.  I am envisioning that this application would most likely be built as a standalone application in Visual Studio using one of the TestStand operator interfaces that supports Visual Studio.

So the issue I'm looking to solve is:  If I have two, independant applications, each having its own GUI interface, and each has its own separate "build" and "revisioning", what is the best way to perform communication between the two of them...?  At a minimum, the communication would be one-way, with the the "ATE" application controlling the "DUT" application, and thereby controlling the DUT itself.  As an additional benefit, it would be great to have the DUT applications' GUI become "embedded" into the ATE applications' GUI somehow, perhaps in a tabbed window, or docked inside of it like the way that multi-document-interface Windows programs are  built.  Can this be done?

Thanks for helping out,

JB

[Tyler T.]

JB,

Will the "DUT" application be executed on a separate machine as the "ATE" application?

I recommend separating as much code as possible for the "DUT" into independent .NET class library assemblies.  You can have a light GUI interface that will run the "DUT" application stand alone (as an executable).  When you want to integrate the applications into one, it would then be easier to move much of that code into a single embedded MDI application because a majority of the code would exist in class libraries that are easily integrated into other applications.

TestStand would also be able to take advantage of having the "guts" of the application stored in class libraries because .NET class library assemblies are callable as code modules from TestStand.  TestStand is also capable of calling code modules on remote systems.

In the case of two executables, I recommend using a network communication protocol such as Measurement Studio DataSocket or the .NET Framework communication protocol.  Assuming that you keep the communication interface consistent, this would also make it easy to develop the two applications separately.

Let me know if you have any specific questions.

Tyler Tigue
Applications Engineer
National Instruments