I'm trying to avoid having a Windows computer per test station, so one computer controlling multiple independent test stations (with multiple deployment licenses). If they were not independent I could consider each station to be a test socket, but batch testing would not be best for DUT (UUT) throughput in my case.
I can think of numerous architectures, but the simplest would be to have a Teststand sequence sending commands via Ethernet to a command server running on an inexpensive Linux box. The command server on the Linux box would control the station, and return data to Teststand.
The ultimate goal (aside from not adding a Windows box to each test station) is to allow an operator to control tests on a group of like stations from a single computer.
TestStand can only run on windows right now, this is because it is built on ActiveX.
You can certainly have a single station that sends commands via ethernet to linux machines. You would have to build your own code on the linux boxes to listen for the commands and handle them appropriately. On the single Windows machine running TestStand you would have to spin up a different instance of the UI for each "node" (linux box). Then just make sure each one is talking to the right node.
Our HAL actually does something similar to this. We can have remote instruments that are on a completely different machine and just running a small server to talk to the host machine. So basically the linux machines would just be talking to instruments and the UUT. Then TestStand would be on a Windows machine calling the HAL. Underneath the hood the HAL would be talking to the HAL on the linux boxes and commanding the instruments and UUT. PM me if you want to go into more depth on this.
Hope this helps,
To add to jigg's post take a look at the following link that provides support to talk to NI Instruments using a gRPC server.