Software Automation Options for Aerovironment Battery Test and Fuel Cell Test Systems

Software Automation Options for Aerovironment Battery Test and Fuel Cell Test Systems

Lately, DMC has been working on several "Green Engineering" and "Clean Energy" programs to develop test systems for clients developing or evaluating Battery and Fuel Cell Power Systems.

Along the way, we have run into some fairly common battery and fuel cell testing equipment in these laboratories, which are produced and sold by Aerovironment (AV).

These systems are basically a combination of a big, variable DC power supply and a big, variable DC load. Folks in the industry use them to charge and discharge their electrical storage devices (ie. Battery, Fuel Cell, Super-Capacitor, etc.) as part of their routine testing strategies. Since they are used to repeadly "cycle" electrical energy storage systems, they are frequently called a "Cycler".

Aerovironment's DC Electric Power Systems









According to their website, "AV has been a leader in Electric Vehicle (EV) test systems and technology since the 1990s. AV’s EV test systems have been used to develop, test and integrate fuel cell and hybrid energy systems for a variety of applications. AV’s EV test systems can be used to simulate any DC supply or load requirement - for testing anything from lead acid to the latest Li-ion batteries, to fuel cells with integrated power electronics."

The Aerovironment Cyclers are a great product for many battery testing and fuel cell testing systems.  However, to get the fully integrated solution most people need, they require some additional automation and customization, which can be challenging.  Based on my experience, I would definitely recommend end users consider working with a third party expert.  Let me go into more detail about some of your options and challenges.

AV's DC electric power systems come bundled with a standard software package to enable PC control of their hardware.

Using the front panel of the Aerovironment hardware only allows you to run a constant set-point for Power, Voltage, or Current. Typically, end users want to run complex P, I, or V profiles that vary over time to simulate their product’s performance under real-world conditions. Unless you have a volunteer with very quick fingers, who is also willing to stand at the machine all day changing your set-points, you need PC control of the system.

To get PC control, you have some options provided with your AV hardware purchase.

First is a C-based scripting engine, which AV calls the "Remote Operation System (ROS)". Second, AV also supports third-party, Windows-based languages, such as National Instruments' (NI) LabVIEW. AV provides a DCOM Windows driver which connects to their hardware using an RS232 serial port on your PC. They also offer optional CAN bus interfaces for some of their hardware which can be used to control the AV and ABC series machines.

While the AV hardware is rock-solid and a mainstay in the industry, at least in my experience, their software interfaces are not very easy to use.

Using the ROS system basically requires C programming experience. That's fine if you're not easily intimidated, have some time to spare, and do not mind brushing up on your C skills. However, if you're not up to the challenge, it is just not an option. Even if you are a stellar C programmer, can you or your operators live without a customized and user friendly GUI?

Your second option is to use the RS232 serial DCOM driver provided by AV within the programming language of your choice.

For me, that is NI LabVIEW 8.6. I have written LabVIEW drivers that use the DCOM driver provided by AV. The provided DCOM-based drivers worked well, but not without some significant programming and debugging efforts. I won't go into details, as that would spoil your fun, but will warn you that the LabVIEW example AV provided was written in LabVIEW 4.1. As a side note, if you are considering non-Windows based platforms, or a Windows Real Time or Embedded approach, you as basically out of luck, since they do not support DCOM interfaces. In the end, I would have preferred to write my own low-level serial driver directly in LabVIEW, but it seems the serial protocol is proprietary.

Your next option is to buy a CAN hardware and software interface for your PC and use your favorite programming language to write a custom driver.

I have also taken this approach. I would consider it the preferred way to go, since the AV CAN protocol is documented. You also get more information from the machine, can update it faster, and can control the dual independent power outputs from two separate PCs. While it may be the preferred route, it is not for the faint of heart. Again, I will not go into details, but if you have to know, send me an email.

I guess your last option, as always, is to pay someone to do all of this programming for you.

I would highly suggest this route, especially if the first three options here made little sense to you. Even if you followed all that techno-jargon, definitely consider this last option seriously before diving in.

You can always save time and money by choosing an experienced integrator!

Author Note 2/12/2010:  Check out our new white paper on EV Battery Pack Testing

Learn more about DMC's Battery Pack and BMS test system services.


There are currently no comments, be the first to post one.

Post a comment

Name (required)

Email (required)

Enter the code shown above:

Related Blog Posts