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

[Istvan K]

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 concpets, but I have no experience with i so far. 
I know that TestStand is similar to our needs, but currently we dont have a budget to purchase it.

Thank you for your help

[Gribo]

First, I'm in the same boat as you are, and here are few of my insights:
You are trying to create a test sequencer - There are off the shelf products that do that (Teststand is NI's solution - $$$). For architecture, anything from the basic QMH to a full blown actor framework with asynchronous actors can be used - in my case, I have used QMH with few extra threads for safety, logging and report generation.

OOP is a way for the designers to think about software modules and abstraction. Do you need such things? Are you planning on supporting multiple models of PSU, loads and other test instruments? If so, OOP provides a convenient way to create those abstraction layers. If you decide on using classes, you should avoid using PPL, they break each other in weird and wonderful ways.

For data logging, I suggest both a central parametric database and local Excel or Calc reports. 

Test templates and deployment: You should consider creating a standardized test template project, along with build specifications, so your operators will use an executable and not the full LV IDE. 

[rhoward991]

I'm prone to use JKI state machines for this sort of simple test sequencing. It is easy to learn, and surprisingly powerful once you become proficient with it. You can also use JKI State Machine Objects (traditional JKI SM wrapped in a class) which makes it simple to support multiple parallel state machines, and which also supports using events.

 

Regards,

Rick

 

[ShaunR]

OK. This is how I design systems like this.

1. TCP. Each subsystem has a TCP interface. This allows spinning up "instances" then connecting to them even across networks. You can rationalise the TCP API and I usually use a thin LabVIEW wrapper around SCPI (most of your devices will support SCPI). You can also use it to make non SCPI compliant devices into SCPI ones (your Environmental Chamber - EC - is probably one that doesn't support SCPI). If you do this right, you can even script entire tests from a text file just using SCPI commands.

2. Services. Each subsystem offers services. These are for when #1 isn't enough and we need state. A good example of this is your Environmental Chamber. It is likely you will have temperature profiles that  control signals and measurements need to be synchronized with. While services may be devices (a DVM, for example), services can also be synchronization logic that sequences multiple devices. If you put that logic in your EC code, it will fix that code for that specific sequence so don't do that. Instead  use services to glue other devices (like the DVM and EC) into synchronization processes. Along with #1, this will form the basis of recipe's that can incorporate complex state and sequencing. In this way you will compartmentalize your system into reusable modules. First thing you should do is make a "Logging" service. Then when your devices error they can report errors for your diagnostics. The second thing should be a service that "views" the log in real-time so you can see what's going on, when it's going on. (This is why we have logging levels).

3. Global State. If you have 1 & 2 this can be anything. It can be a text file with a list of SCPI commands (#1). It can be a service you wrote in #2, Test Stand, web page or a bash/batch script. This is where you use your recipe's to fulfill a test requirement.

4. You will need to think carefully about how the subsystems talk to each other. For example. Using SCPI a MEAS :VOLT:DC? command returns almost instantly (command-response pattern). However for the EC you may want to wait until  a particular temperature has been reached before issuing MEAS :VOLT:DC?. The problem here is that SCPI is command-response but the behavior required is event driven. One could make the the TCP interface (#1) of the EC accept MEAS :TEMP? where the command doesn't return unless the target setpoint has been reached. However, this won't work reliably and requires internal state and checks for the edge cases though. So it may actually be better in #2. There are a number of ways to address these things using #1, #2 or #3 and that is why you are getting the big bucks.

You will notice I haven't mentioned specific technologies here (apart for TCP). For #1 you shouldn't need anything other than reentrant VI's and VI Server. For #2 you can use your favourite foot-shooting method but notice that you are not limited to one type and can choose an architecture for the specific task (they don't all have to be QMH, for example). For #3 you don't even have to use LabVIEW.

Edited yesterday at 12:31 PM by ShaunR

[viSci]

Nicely described approach Shaun.  I am doing something similar with a lab automation project that involves vacuum chamber and multi-zone temperature control.  Elected to use the messenger framework, which supports 'spinning up' instances and TCP capability for remote devices like cRIO.  The messenger architecture also supports many types of asynchronous messaging beyond simple synchronous command/response.  Your idea of decoupling EC sequencing logic is good, moving it out of the EC subsystem to allow synchronization with other subsystems during ramp/soak profiles.   Hey remember Test Stand Lite?  This is where an such a scripting component would really shine and be a great benefit to the community.  

Edited 3 hours ago by viSci