Fixing and Updating TestStand & LabVIEW for a New Power Distribution Product

Dealing with frustration from a prior development effort and wanting to update testing capabilities with LabVIEW and TestStand

Client – Starline, a Brand of Legrand, a global leader in customizable power distribution solutions

Challenge

In their ongoing pursuit of high-quality products, Starline, a Brand of Legrand, wanted to regression test the firmware being developed for the M70 Critical Power Monitor, one of their new electrical power metering products. Starline requested Viewpoint to step into a project that was already underway.

Starline had existing TestStand / LabVIEW code already in place from a prior generation of the meter, but it had performance issues and, more importantly, it didn’t support the next generation of product. The existing code was developed both internally and externally in collaboration with another system integrator; however, Starline was in search of a new partner to help take the project across the finish line.

We needed to quickly learn the existing codebase to deliver the requested enhancements while rebuilding trust after Starline’s difficult experience with the previous system integrator.

Solution

Starline developed a detailed Statement of Work as guidance for the outstanding tasks. The initial scope was directed at supporting the new product line, which the existing software did not include.

Going through the process of learning the existing software, we noticed several areas in which the code was ”fragile” due, in part, to:

  • Inadequate architectural design choices,
  • Duplicated code blocks, which complicated bug fixes and maintenance,
  • Telnet comms rather than more basic serial comms,
  • Misalignment in capability between the test software and the product firmware,
  • False Pass conditions due to inadequate error handling, and
  • UI complexities, which made it challenging for the operator to manage the test flow.

In collaboration with Starline, we agreed to strengthen the architecture and codebase before introducing new capabilities, then return to the original objective of supporting the new products.

Working Together

We were able to gain Starline’s trust by showing them our collaborative process through resolving issues within the existing code architecture and code base. We were then able to work together to define the tasks required to correct these issues.

Throughout the work, project management went smoothly. Starline’s project manager was detail-oriented, engaged, and approachable. Software tasks were managed with Jira and tasks were reviewed at weekly status meetings. This approach ensured that all issues were being tracked and that everyone was aware of progress being made to resolve them.

Our involvement in this project was completely remote (i.e., we were ready to go on-site but it was not needed). Admittedly, there were minor challenges around this work arrangement, but we were able to work together to iron out the wrinkles. For example, because the firmware was still in development, sometimes the Unit Under Test (UUT) would freeze due to a change in the latest firmware. A reboot of the UUT was needed, which required a person to power cycle the UUT. After a discussion, we decided to expose the soft front panel of the power supply so we could remotely power-cycle the UUT.

This simple and cost-effective solution helped illustrate the importance of a great relationship between the test system integrator and the client.

Benefits

  • Test system software refactoring increased maintainability and reduced fragility
  • Cleaner code enabled easier development and long-term support
  • Refactoring simplified implementation of communication interfaces
  • Improved test coverage – Creation of new comms messages and handling their responses, including all types of “corner” cases for extreme testing that their firmware would function in all modes of operation

How we helped

We were able to help Starline by providing:

  • Software architecture and development expertise from seasoned test engineers
  • Project management collaboration
  • Mentoring to ramp up one of Starline’s test engineers on the inner workings of the software so we could step back into an advisory role in the future.

System Overview

The new product line is aimed at supporting the ever-growing need for high-density power in data centers, high performance computing, and AI centers by providing data on real-time voltage, current, and power. Standard communication protocols are used to ensure seamless integration with virtually any Building Management system (BMS) or Data Center Infrastructure Management system (DCIM).

Since the product and its various configurations were completely testable through various communication protocols, the test system was able to run all tests by sending commands to the unit and reviewing its responses.

In the real world, certain configurations of the product would connect to external equipment, or the product might have some additional subassemblies installed.

Starline determined they would develop special firmware to simulate these additions. This prototype test firmware would simulate responses to messages as in the real-world. In similar fashion, faults were simulated with this prototype test firmware. Then, the test system was able to test all configurations, real and simulated, for a comprehensive exercise of the product’s firmware.

We used both serial RS-485 and Ethernet for baseline communications with support for several protocols, such as:

  • Serial RS-485
  • SSH
  • ModbusTCP
  • ModbusRTU
  • BACNet
  • SNMP v1
  • SNMP v2
  • SNMP v3
  • SNMP v3 Traps

Because our involvement was requested after the project had already been started, Starline provided the test system hardware and initial software. Our job was to refactor, clean, and add functionality to the software to test the new product’s firmware.

 

SOFTWARE FUNCTIONS
TestStand
LabVIEW

 

HARDWARE USED
USB to RS-485 serial converter
Ethernet