top of page

Siemens Uses cRIO, LabVIEW to Determine Root Cause of High-Voltage Transients

*As Featured on

Original Authors: Ryan Parkinson, Siemens

Edited by Cyth Systems

Determining Root Cause of High-Voltage Transients Using Ni cRIO.
Determining Root Cause of High-Voltage Transients Using Ni cRIO.

The Challenge

Determining the source of electrical high-voltage transients to prevent light-rail car failure.

The Solution

Combining the benefits of the field-programmable gate array (FPGA) and processor in NI CompactRIO hardware to create a rugged, semipermanent monitoring system that records multiple data formats and rates, synchronizes the data, and performs real-time analysis to remotely monitor sensors in an industrial environment for extended durations.

Governing subsystem interactions is a fundamental challenge for system integrators. Despite defining exhaustive I/O limits, sometimes failures occur and it is not clear which subsystem interaction generated the destructive element. It is difficult to request subsystem vendor's resources to troubleshoot a problem that did not clearly originate from their equipment, and testing each system in isolation may not account for all interactions. In these cases, the system integrator may be best positioned to monitor the relevant parts of the overall system, isolate the problem source, and assign the appropriate resources to resolve the issue. The Siemens Rail Systems Division recently successfully performed this system integrator's task.

Over the past three years, one of our customers faced a recurring issue with our SD160 light-rail transit vehicles. Denver RTD, a bus and light-rail service operating in Denver, Colorado, has 170 Siemens vehicles in operation. These vehicles receive power from an overhead catenary system (OCS), which in turn receives power from RTD's power distribution network. The auxiliary power supplies (APS) on board each vehicle receive power from the OCS and condition it for use by most of the other onboard vehicle subsystems. This APS had a high failure rate, which caused a critical failure for the vehicle. The failure log reported a high-voltage transient on the power input to the APS, which led the vendor to believe that either Denver RTD or the onboard propulsion subsystem (which provides power to the APS during electro-dynamic braking) were providing power outside the acceptable transient limit. However, both RTD and the propulsion unit supplier confirmed that their systems should not generate such a transient. Each light-rail vehicle failure was extremely expensive and time-consuming for Siemens and our supplier, and the failures caused operating delays for our customer. We needed to monitor the situation, establish the root cause, and find a solution as quickly as possible.

Preliminary Diagnostic Efforts

Initially, engineers at RTD verified OCS voltage levels met specifications. Subsequently, engineers from the APS vendor confirmed voltage transients that could contribute to the equipment failures, although when inducing these transients through various test routines, the APS always performed as designed. This testing required removing the vehicle from passenger service so personnel could monitor portable scopes. This method was inconclusive because high-voltage transients don’t occur very frequently and it is unlikely that a rare, damaging transient would occur during a short test period. It became clear that more comprehensive testing on vehicles in transit was needed to accurately characterize actual operating conditions.

The APS vendor built its own remote data logger to permanently install on an SD160 vehicle. It could obtain snapshots of system-level voltage data, but the data was insufficient to understand the surrounding environment and what was causing the transients. These approaches helped us realize that we needed to see the complete picture to diagnose the issue. We decided to build on these earlier efforts and design a rugged, remote system to monitor the trains for long periods of time to find and correct the problem.

System Definition

We needed a highly flexible, yet powerful monitoring system to accommodate the variety of sensors and communication protocols from the different subsystems. We defined the following requirements:

  • Continuous multichannel voltage sampling at >10,000 Hz to monitor six inputs for high-voltage transients

  • At least three different configurable sampling rates to optimize each signal class data rate and minimize storage requirements

  • A serial input using standard protocols to interface with the GPS antenna and provide location information for events

  • Real-time calculations to provide output responses to interact with the sensors

  • Pre- and posttrigger (event) data recording without saving nontrigger data to optimize analysis and minimize storage needs

  • Large storage capacity

  • Video management

  • Automatically synchronize all inputs regardless of data rate or format

  • Automatic downloads for extended operation with minimal personnel interactions

  • Vibration and temperature operating ranges acceptable for installation on a rail vehicle

  • Small footprint for installation in an electrical compartment

Left: Permanent CompactRIO Installation, Right: High-Voltage Transducers and Fuse Installation

Programming With LabVIEW

We programmed our system exclusively with NI LabVIEW system design software, using the LabVIEW Real-Time and LabVIEW FPGA modules. We programmed the FPGA to acquire high voltages, currents, and vehicle diagnostics. We programmed the processor to acquire GPS locations and vehicle speeds, to perform daily housekeeping, and to perform postprocessing which allowed us to erase nontrigger data and minimize storage requirements since we were recording about 1 GB of data every 30 minutes. With automated postprocessing, we stored only about 5 GB per day. NI has a great database of prewritten code. Plugging in GPS software modules and general templates for the FPGA and processor software layout saved us a significant amount of time. After attending LabVIEW Core 1 and Core 2 classes in San Diego, we progressed from first-time users to advanced programmers in only a few months. Due to the intuitive nature of LabVIEW and previous programming experience, we completed and tested the software in less than six months.

Benefits of CompactRIO

FPGA and Processor

Perhaps the greatest benefit of CompactRIO is the FPGA/processor combination. Because the FPGA is reconfigurable, the achievable data rates and sampling accuracy are comparable to most state-of-the-art scopes. We can perform real-time calculations and outputs with no processor delays. Once the data is timestamped and buffered, the processor advantages come into play. Software engineers can take advantage of the full breadth of the processor’s flexibility to achieve extended and remote FPGA operation and manage large data sets. The buffered data can be retrieved and written to a USB drive, making its storage capabilities comparable to a laptop. The GPS signal is monitored and recorded. Scripts are run to postprocess, erase nontrigger data, and prepare the data for analysis. Daily tasks are performed and automated FTP uploads to a server can be executed each evening.

Rugged and Reconfigurable

The CompactRIO exceeded all our environmental requirements. It handles a temperature range of -40 °C to 80 °C, so we mounted the unit externally in an electrical compartment. Its small footprint and excellent vibration/shock resistance allowed for easy, semipermanent installation.

CompactRIO is highly customizable. We knew we needed to conduct multiple phases of investigation, and the ability to reconfigure the system to hone in on potential problem areas was a significant benefit. After performing preliminary voltage analysis, we discovered that it would be beneficial to monitor two current signals. Adding these two signals was a very simple task. Using a CompactRIO with swappable input modules, we could monitor almost any conceivable input.

Original Authors:

Ryan Parkinson, Siemens

Edited by Cyth Systems


bottom of page