Solution for emulated hardware

[Leif]

I often find myself in the situation where I use a number of hardware devices in my application. The communication interface could be USB, RS-232, Ethernet...

When developping and debugging the "execution logistics", it would be so nice if I could emulate the hardware, but I can't find a good solution/architecture. Probably, there are lots of intelligent developers here that could help me.

Without the emulation option, the class diagram would probably look like in the picture.

The most basic emulation could be having a GUI displaying the command sent and a manual entry for the response. On the next level, I could perhaps use some intelligent code that creates a relevant response based on the command sent.
BUT: What is the best OO solution to this issue?

One thing that I want to avoid is creating one emulated class for each HW sub-class (Emulated Digital Multimeter etc).

[hooovahh]

Well in practice you could have a single Device Class, that all devices inherit from, including your Simulated Hardware Class.  But you mentioned you don't want to create a simulate class for each hardware class.  I think if you go with this override type of design you will have to.  I mean if I have a DMM Class, a Power Supply Class, and a CAN Class, they all are going to have very different needs for what to do for simulation.  Which is why you'd probably end up with a DMM Simulation Class, Power Supply Simulation Class, and CAN Simulation Class.  This does add a bunch of VIs to your project, and more things to manage for sure.

One other cheap and dirty trick that OO purist would probably not like is on your open method of your DMM class pass in a boolean that is "Simulate?" Or have a method to turn on and off simulation.  Then you still only have one class for each hardware type, and all that is needed is to have a case structure around your low level communication code.  I agree this is less scaleable, and adds more coupling, and less reuse, but it doesn't add tons of overrides, and more VIs in the hierarchy, and for non OO people it is easier to understand. 

If you can design your classes from the start to be generic enough that a single overriding class can supplement them, then a single simulation class might work.  Otherwise it seems like a lot of work.

[Leif]

Thanks for the comments, hooovahh.

Maybe, I'm not using good class names. I've got the feeling that e. g. Digital Multimeter more represents an interface to the device, rather than the device itself.

Sometimes we have like ten different hardware classes, so creating an emulating/simulating class for each makes the whole project filled with duplicate classes, where the emulating classes almost have the same functionality. This is why I want to avoid this solution.

As you mention hooovahh, I could use a boolean to indicate whether to use an emulated the hardware. However, I also want to define which type of emulation to use; the GUI solution, the more intelligent or something else. Then I think aggregating the selected emulator is better.

Earlier, I've tried using the operator as a "communication resource", simply by using dialogs with instructions ("Set DC voltage measurement") and requests ("Enter measured voltage"). This was very useful as the communication interface wasn't developed yet, but the plan was to replace the dialogs with RS232 communication. In this case, we "translated" the RS232 commands into operator instructions. However, this feels a bit like "crossing the stream to get water" (Swedish idiom). 
I've called this class Operator GUI in the picture. (Emulated ComRes may be unnecessary)

Another idea is to use file lookup tables which defines responses (e. g. "1.234 VOLT") for different HW commands (e. g. "READ DC VOLTAGE"). Without adding more intelligent, the drawback is that this always returns the same response to a command.
Anyway, I've called the class Response File.

To conclude, this is based on putting the emulation outside the HW classes as this could be generic. But is it a good solution?

[Leif]

Realised that Operator GUI is not an emulated resource as it could be used to connect to the actual hardware. Then the class diagram should look like this:

[Leif]

The class diagram has evolved and grown:

 

Let's investigate a case where Test Case is using Thorlabs OPM to test an optical power. This OPM is connected with USB.

But I also want to emulate this OPM with some software where command responses are defined in a text file (used by Response File). Each file should be device (class) specific.

In the final application, the execution would look like this:

USB calls Thorlabs OPM (buildCommand) where Thorlabs OPM builds a string (commandString) for requesting the OPM power. This string is sent over the USB bus to the OPM which responds with the power value. This value is then propagated back via Real HW Interface and Thorlabs OPM to Test Case.

I could also replace USB with Response File. getResponse looks up the commandString (get power request) in the file to find the response (power value) associated with the command, which is passed on back to Test Case. (The method send is not needed here.)

Is this a good solution? What are the pros and cons?

I realise that it's quite big and bulky, maybe a bit difficult to understand. I've also found that there are some common functionalities that cannot be reused with this solution.

Edited February 16, 2017 by Leif

[Stagg54]

On ‎2‎/‎7‎/‎2017 at 8:37 AM, Leif said:

 

The most basic emulation could be having a GUI displaying the command sent and a manual entry for the response. On the next level, I could perhaps use some intelligent code that creates a relevant response based on the command sent.
BUT: What is the best OO solution to this issue?

One thing that I want to avoid is creating one emulated class for each HW sub-class (Emulated Digital Multimeter etc).

I think you are going to find you want a seperate emulated class for each instrument.  It really depends on what are doing with the data from each instrument when you get it back.  If you are just logging it, then maybe everything is fine with just one emulated class, but if you are making any decisions based on it, then it will probably require a seperate emulator for each instrument.  

And as for manually entering the response, that works as long as the calling entity isn't going to time out.  So you either have to add intelligent code to send back the expected response, or you have disable the timeout in the calling code.