Software architecture for modular measurement system in a battery and electronics testing laboratory

[kelendas]

Greetings, 

To set the scene, our University wants to build a laboratory where we can test batteries and electronic devices with our equipment. Just to list a few of them we have: 
- Climate chamber
- cRIO-9039 for data acquisition and safety control
- Electronic load
- Multiple power supplies
- Multimeters
- Oscilloscope
- LCR meter
- EIS measurement instrument
and so on.... 

All of these devices can be interfaced through LabVIEW, and I am certain that this list will increase in the future. 
The main concept:
- We have a sotfware, where we can create the test sequence, step by step (i.e.: Configure powersupply, delay(ms), enable ps. output, delay(ms), disable output ). The output would be a recipe file, which include each step, and its parameters.
- The main software, where you can import the test sequence, and execute it. The sequences can include multiple measurement instruments. The data logging is continuous.  If there is an emergency, the measurement is aborted. 
   The imported sequence file would be executed step by step in a case structure (or if there is any other possibility). 

My question is: What kinf of architecture would be suitable for the main software? I have already developed larger applications using QMH, but I have experienced its limitations. Im also looking at OOP concepts, but I have no experience with it so far. As I mentioned earlier, I am certain we will need to be able to add more measurement instruments to the code, so please take that into consideration. 
I know that TestStand is similar to our needs, but currently we dont have a budget to purchase it.

Thank you for your help

[wiebe@CARYA]

QMH, AF, DIY, that's mostly a matter of taste.

I'd advice you to look into OO, as it could help you a lot. I wouldn't try to make something like this without OO. I did in the past though, but OO simply makes it a lot easier (iff done right).

I'd stay away from HALs. This is incredibly hard to do right. There's also little need for or benefit from it. A HAL can pay off, but you need to know exactly what you're doing with OO, but also what you want your HAL to do, and what not. It's simply very hard to do a complete HAL that covers life, the universe and everything.

I'd make each device an actor. Not with AF per se, it can be something dynamically started.

Each device actor simply response to commands, and can access a current value table (again, lots of options) to read\write values.

The UI can be an actor, pretty much like a device. After all, the display is a device, and it will read (to display) and write (to update) values.

A trend can be another actor.

Obviously the recipe can be a device actor too, it's basically an automated UI.

The architecture is pretty straightforward, but the devil is in the details. There will be a lot of them. Tags have properties, like number of decimals, if it can be written or not, alarm limits maybe. But these values could be individual tags too. Is historical data global, or do trends keep local a copy or copies? You'll run into more and more of these 'tiny' problems that need to be solved.

Most of these issues come down to the scope of the data and how you deal with it. Some data is global, some is local, some should be private. Making the actors work together without giving everything access to everything.

Making it configurable is another level of complexity. Now everything you make needs to somehow inform the user what it can do. But the configurator part is in it's basis completely separated from the 'main software', so do you separate the entire code base?

Of course if you write the code well, you should be able to completely switch strategies or even architecture without too much problems 😊.