Well, there are a lot of possible solutions... but you haven't given enough information really on what the communication looks like between the test computer and the subsystems. Is this entirely up to you on what to implement? I'm going to assume it is, but the solution would probably change if the protocol over RS485 is already defined or selected.
Most communications protocols at this sort of level will contain some type of addressing built in.
If you're comfortable with sending binary structures around, then just define a structure that every message starts with that contains:
- The length in bytes of the entire message
- The address of the subsystem you are trying to talk TO
- The address of the subsystem you are talking FROM (optional)
- The command you are trying to issue to the subsystem
You would start every message with this header, then pass any needed data, and finally you would optionally (but it's highly recommended on RS485-style links) send a checksum or CRC of the header and data.
The main computer at that point doesn't need to do anything but read the message header, see the length, and pass that to the appropriate subsystem. It doesn't even have to know where the addresses are... you could simply broadcast the message to all three subsystems. As the commands change and the data changes the message format does not... so the main computer's logic can remain the same.
The response from the subsystem should be in the same format.
It's useful to put the address of the FROM node in so that the subsystem knows who to reply back to. In some situations that's never going to change so you can hard code that. I usually prefer to put the FROM node address in anyway as you never know how the network topology might change later on.
On last thing. Since you're calling this the "main computer", I'm assuming you may be talking about a real PC. With real PCs running a modern OS like Windows, OS/X, or Linux you're going to have latency in how quickly the application on that computer can respond... so build appropriately large timeouts into your protocol. Many serial-based protocols are a real pain in the butt on modern PCs due to tight timeouts allowed on responses, etc. You probably couldn't pass MODBUS through a modern PC in the way you describe, for example... at least not without either special serial device drivers or violating the timing (which is sometimes okay for fixed solutions) By the time the main computer read the response from the test computer, broadcast it to the subsystems, got the responses, and rebroadcast that to the test computer several hundred milliseconds could elapse.