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 Saturday 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 Sunday at 12:31 PM by viSci

[ShaunR]

On 5/4/2025 at 1:28 PM, viSci said:

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.  

You can script with text files with #1. Just adding a feature to delay N ms gets you most of the way to a full scripting language (conditionals and for-loops are what's left but a harder proposition). However, for a more general solution I use services in #2  with queue's for inputs and events for outputs. There was a discussion ages ago at whether queues were needed at all since LabVIEW events have a hidden queue but you can't push to the front of them (STOP message ) and, at the time, you couldn't clear them so I opted for proper queues. So, architecturally, I use "many to one" for inputs and "one to many" for outputs.

[hooovahh]

I work in a battery test lab and was the architect for the testing platform we use.  Our main hardware is an embedded cDAQ, or cRIO running Linux RT.  This is the hardware that runs the actual sequence, and talks to the various hardware.  We use the RT platform more for reliability, and less for its determinism.  Timing is of course important, but we don't have any timed loops. mS precision is really all we care about. The architecture is built around User Events with asynchronous loops dedicated to specific tasks.  These events can be triggered from the RT application, or from a device on the network using Network Streams. A low level TCP would probably be better, but the main sequence itself isn't sent, step by step from Windows. Instead the sequence file is downloaded via WebDAV, then told to run it. The RT then reads the file and performs the step one at a time. Windows from this point is just for monitoring status, and processing logs. This is important to us since Windows PCs might restart, or update, or blue screen, or have any other number of weird situations, and we wanted our test to just keep going along.  This design does mean that any external devices that use Windows DLLs for the communication can't be used. But network controlled power supplies, loads, cyclers, chambers, and chillers all are fine. Same with RS-232/485.  Linux RT supports VISA, and we plugged in a single USB cable to a device that gives us 8 serial ports.  If money were no object I suppose we would have gone with PXI but it is pretty over kill for us.

On the Windows side we do also have a sequence editor.  The main reason we didn't go with TestStand is because we want that sequence to run entirely on Linux RT.  Because the software communicates over User Events, and Network Streams sending User Events, we can configure the software to run entirely on Windows if we want.  This of course takes out many of the safety things I talked about, but to run a laptop to gather some data, control a chamber, battery, cycler, or chiller for a short test is very valuable for us.

As for the design, we don't use classes everywhere. Mostly just for hardware abstraction.  The main application is broken up into Libraries, but not Classes.  If I were to start over maybe I would use classes just to have that private data for each parallel loop, but honestly is isn't important and a type def'd cluster works fine for the situation we use it in.

[ShaunR]

48 minutes ago, hooovahh said:

and Network Streams sending User Events

How does this work?

[hooovahh]

3 hours ago, ShaunR said:

How does this work?

I have a network stream actor (not NI's actor but whatever) that sits and handles the back and forth. When you want work to happen like "Set PSU Output" you can state which instance you are asking it to (because the actor is reentrant), and which network location you want. The same VI is called, and can send the user event to the local instance, or will send a user event to the Network Stream loop, which will send the request for a user event to be ran on the remote system, and then reverse it to send the reply back if there is one.  I like the flexibility of having the "Set PSU Output" being the same VI I call if I am running locally, or sending the request to be done remotely.  So when I talked about running a sequence, it is the same VIs called, just having its destination settings set appropriately.