Application of LabVIEW State Machine in Motor Control Unit Testing

In the automotive industry, the validation of electronic control units, particularly motor control units, is critical for ensuring vehicle safety, performance, and reliability. Traditional testing systems, such as dSPACE HIL or NI HIL, offer robustness but often suffer from limited compatibility due to their proprietary hardware-software integration. This constraint drives the need for flexible, cost-effective alternatives. In this context, I present a novel upper-computer testing software developed using LabVIEW’s state machine architecture, specifically designed for comprehensive testing of automotive motor control units. This approach leverages existing hardware resources, such as microcontrollers, to create a versatile testing environment that emphasizes automation, signal processing, and intelligent state management. The core innovation lies in the state machine design, which incorporates string-based state control, sophisticated signal conversion methods, and robust interrupt handling—features that address common pitfalls in automated testing frameworks. This article details the system’s design, implementation, and application, with a focus on enhancing testing efficiency for motor control units through advanced LabVIEW programming techniques.

The testing system is architected around a hierarchical structure involving an upper computer (PC), a lower computer (microcontroller), the motor control unit under test, and simulated loads. The upper computer runs the LabVIEW state machine software and communicates with the microcontroller via a USB-to-TTL serial interface. Test commands are sent from the upper computer to the microcontroller, which then generates corresponding radio frequency signals to stimulate the motor control unit. Upon receiving these signals, the motor control unit outputs control signals to drive the simulated loads, such as actuators or relays. The microcontroller captures these control signals and transmits the data back to the upper computer for processing, analysis, and judgment. This setup enables real-time monitoring and validation of the motor control unit’s functionality under various conditions. The integration of a state machine in LabVIEW allows for sequential test execution, dynamic state transitions, and adaptive responses to test outcomes, making it ideal for rigorous motor control unit evaluation.

The state machine design in LabVIEW is built upon a while loop structure with shift registers nested within a case structure. A key highlight is the use of string arrays as state control types, enabling flexible state transitions by inserting or modifying strings. This design contrasts with conventional enumerated type state machines, offering greater adaptability for complex test sequences. The state machine’s data is managed using clusters, which bundle various data types—such as arrays for test items, results, and parameters—into a single, readable-writeable entity. This facilitates seamless data flow between states and supports automated test execution. For instance, test parameters for the motor control unit are stored in an Excel “Functional Configuration Table,” which is read by the LabVIEW software using Excel General functions. The extracted data populates the cluster arrays, driving the test sequence. The state machine progresses through states like “Initialization,” “Signal Acquisition,” “Data Processing,” and “Result Logging,” with transitions determined by string comparisons in the case structure. This string-based approach allows for on-the-fly state modifications based on test results, enhancing the intelligence of the motor control unit testing process.

To achieve high-fidelity testing, the system implements five core functionalities, each addressing specific aspects of motor control unit validation. These functionalities are summarized in Table 1, which outlines their purposes and key features in the context of motor control unit testing.

Table 1: Core Functionalities of the LabVIEW State Machine for Motor Control Unit Testing
Functionality Description Key Feature
Automated Testing Enables simultaneous testing of multiple motor control units with configurable cycle counts. String array-based state control for dynamic sequencing.
Signal Conversion Converts discrete TTL signals to high/low-level signals for load action analysis. Algorithmic processing of discrete data strings.
Filtering Removes transient noise signals (≤20 ms) to assess motor control unit抗干扰能力. Time-based filtering logic.
Interrupt Jump Allows seamless interruption and state transition during tests without multi-threading issues. Event-driven state insertion in default case branch.
Response Time Evaluation Measures the latency from command issuance to load action for motor control unit performance. Dual-timer differential calculation.

The first functionality, automated testing, is realized through the state machine’s iterative structure. The while loop continuously executes, with the shift register storing a cluster that includes a “test state array.” This array holds strings representing upcoming states, such as “Test Item A” or “Test Item B.” By inserting strings into this array, the state machine can jump to any state, enabling parallel testing of multiple motor control units. For example, if testing three motor control units (A, B, C), the software sequences through test items for each unit by updating the state array. The number of test cycles is user-configurable, allowing stress testing of motor control units over extended periods. The automation reduces manual intervention and ensures consistent test conditions, which is vital for reliability assessments of motor control units in automotive applications.

The second functionality involves converting discrete digital signals into high/low-level signals to monitor load actions. The microcontroller transmits raw data as strings of discrete values derived from voltage measurements across simulated loads. These values are processed in two steps. First, the discrete string is transformed into a binary string of 0s and 1s, where values ≥200 correspond to high level (1) and <200 to low level (0). This conversion is mathematically expressed as:

$$ \text{Binary Value} =
\begin{cases}
1 & \text{if } V_{\text{raw}} \geq 200 \\
0 & \text{if } V_{\text{raw}} < 200
\end{cases} $$

where \( V_{\text{raw}} \) is the raw voltage value. The conversion process in LabVIEW uses functions like “Decimal String to Number” and “Boolean to (0,1) Conversion.” Second, the binary string is further processed to group consecutive 1s or 0s, representing sustained high or low states. This is achieved by replacing transitions (“01” or “10”) with delimiters, then splitting the string into an array of uniform substrings. The number of high-level substrings indicates load action counts, and the duration is calculated by multiplying the substring length by the sampling period \( T_s \). For a motor control unit, this allows precise measurement of output signal characteristics, such as pulse width and frequency, which are critical for validating control algorithms.

The third functionality adds filtering to enhance the motor control unit’s抗干扰能力 assessment. In real-world environments, motor control units may experience brief noise-induced signal spikes. The filtering logic distinguishes between valid signals and transient noise based on duration. If a high-level signal lasts ≤20 ms, it is considered noise and filtered out; otherwise, it is treated as a valid load action. This is implemented using conditional checks on the processed data array. Let \( D \) be the array of uniform substrings, and \( t_{\text{sub}} \) be the duration of a substring calculated as \( t_{\text{sub}} = n \times T_s \), where \( n \) is the substring length. The filtering criterion is:

$$ \text{Valid Action} =
\begin{cases}
\text{True} & \text{if } t_{\text{sub}} > 0.02 \, \text{s for any high-level substring} \\
\text{False} & \text{otherwise}
\end{cases} $$

This ensures that motor control units are evaluated for robustness against short-duration interference, balancing cost and performance in automotive designs.

The fourth functionality, interrupt jump, addresses a common challenge in state machine design: allowing users to pause or skip tests without complex multi-threading. Traditional methods either poll for events in every state (inefficient) or use separate threads (prone to synchronization issues). Our solution employs a hybrid approach. The state machine includes a dedicated state labeled “Recognition” that checks for a “Pause Test” button press after each test item completion. If pressed, the string “No Action” is inserted into the state array, transitioning to a default case branch where an event structure handles other user inputs (e.g., “Resume,” “Skip”). This design minimizes CPU usage by limiting event checks to specific intervals (e.g., every 90 seconds per test item) and avoids thread conflicts by keeping event handling within the state machine loop. This interrupt capability is essential for interactive testing of motor control units, allowing engineers to adapt tests in real-time based on observed behavior.

The fifth functionality evaluates the response time of the motor control unit, a key performance metric. For instance, in testing an auto-relock feature, the time from command issuance to load action is measured. The implementation uses two timers: Timer1 starts when the test command is sent, and Timer2 starts when the microcontroller confirms data collection completion (indicated by a “&” character). The response time \( t_{\text{response}} \) is computed as:

$$ t_{\text{response}} = t_{\text{Timer2}} – t_{\text{Timer1}} $$

This measurement is critical for assessing the real-time responsiveness of motor control units, which directly impacts vehicle safety and functionality. The LabVIEW code integrates these timers within the state machine, ensuring accurate synchronization with test sequences.

To illustrate the state transitions and data flow, Table 2 provides a summary of key states in the LabVIEW state machine for motor control unit testing, along with their actions and transition conditions.

Table 2: State Machine States and Transitions for Motor Control Unit Testing
State Name Action Next State Transition Condition
Initialize Read configuration table, set up communication. Proceed to “Acquire Data” if successful.
Acquire Data Send commands to microcontroller, receive raw signals. Move to “Process Signals” after data receipt.
Process Signals Convert signals, apply filtering, calculate metrics. Jump to “Evaluate Response” or “Log Results” based on outcomes.
Evaluate Response Measure response times for motor control unit actions. Transition to “Next Test Item” or “Interrupt” if paused.
Log Results Record test data, generate reports for motor control unit. Return to “Initialize” for next cycle or end testing.
No Action (Default) Wait for user events (e.g., pause, resume). Insert new state string based on event trigger.

The signal conversion process is further detailed through mathematical formulations. Let the raw data string from the microcontroller be \( S_{\text{raw}} = \{s_1, s_2, \dots, s_m\} \), where each \( s_i \) is a decimal string representing a voltage sample. Step 1 converts each \( s_i \) to a binary value \( b_i \) using a threshold function \( f \):

$$ b_i = f(s_i) = \left\lfloor \frac{\text{int}(s_i)}{200} \right\rfloor \quad \text{where } \lfloor \cdot \rfloor \text{ denotes integer division (result 0 or 1)} $$

This yields a binary string \( B = \{b_1, b_2, \dots, b_m\} \). Step 2 groups consecutive identical bits by introducing a delimiter at transitions. Define a transition index set \( T = \{j \mid b_j \neq b_{j+1}, 1 \leq j < m\} \). Then, split \( B \) at indices in \( T \) to form substrings \( G = \{g_1, g_2, \dots, g_k\} \), where each \( g_j \) consists entirely of 0s or 1s. The load action count \( C \) is the number of substrings with all 1s:

$$ C = \sum_{j=1}^{k} I(g_j \text{ is all 1s}) $$

where \( I(\cdot) \) is the indicator function. The duration of each action \( g_j \) is \( d_j = \text{len}(g_j) \times T_s \), with \( T_s \) typically in milliseconds. For a motor control unit, this analysis verifies output signal integrity, such as ensuring that a control pulse meets minimum duration requirements.

Filtering is formalized using time-domain analysis. Let \( g_{\text{high}} \) be a high-level substring with duration \( d_{\text{high}} \). The filter function \( \phi \) classifies it as noise or valid:

$$ \phi(g_{\text{high}}) =
\begin{cases}
\text{Filter out} & \text{if } d_{\text{high}} \leq 0.02 \, \text{s} \\
\text{Retain} & \text{otherwise}
\end{cases} $$

This simple yet effective rule is implemented in LabVIEW by iterating through the substring array \( G \) and applying the condition. It enhances the accuracy of motor control unit testing by ignoring insignificant fluctuations, which is crucial for evaluating performance in noisy automotive environments.

The interrupt jump mechanism is modeled as a state insertion process. Let the current state array be \( A = [a_1, a_2, \dots, a_n] \), where each \( a_i \) is a state string. Upon detecting a “Pause” event in the “Recognition” state, the array is updated to \( A’ = [\text{“No Action”}, a_2, \dots, a_n] \). This forces a transition to the default case branch, where event handling occurs. When a “Resume” event is triggered, a new state string (e.g., “Acquire Data”) is inserted, yielding \( A” = [\text{“Acquire Data”}, a_2, \dots, a_n] \), and the state machine resumes testing. This approach eliminates the need for global variables or complex synchronization, streamlining the testing workflow for motor control units.

Response time evaluation incorporates timing precision. Let \( t_{\text{cmd}} \) be the time when the test command is sent to the microcontroller, and \( t_{\text{ack}} \) be the time when the acknowledgment string (“&”) is received. The response time \( t_{\text{resp}} \) is:

$$ t_{\text{resp}} = t_{\text{ack}} – t_{\text{cmd}} $$

In practice, multiple acknowledgments may be received for different motor control unit channels. The LabVIEW code uses a counter to wait for all expected acknowledgments before stopping Timer2, ensuring comprehensive measurement. This metric is vital for benchmarking motor control units against industry standards, such as response times for safety-critical functions like braking or steering control.

The advantages of this LabVIEW state machine design are manifold. Firstly, it decouples software from specific hardware, enabling compatibility with various microcontrollers and motor control units. Secondly, the string-based state control offers unparalleled flexibility, allowing test sequences to be modified without recompilation. Thirdly, the signal processing algorithms provide high accuracy in converting and analyzing motor control unit outputs. Finally, the interrupt handling ensures user-friendly operation without sacrificing reliability. These features make the system a cost-effective alternative to proprietary HIL systems, particularly for small to medium-scale automotive testing facilities focused on motor control unit development.

In conclusion, the LabVIEW state machine approach presented here offers a robust framework for testing automotive motor control units. By integrating automation, advanced signal processing, filtering, interrupt capabilities, and response time evaluation, it addresses key challenges in electronic control unit validation. The use of string arrays for state management, coupled with mathematical formulations for data conversion, provides a scalable and intelligent testing solution. This methodology not only enhances testing efficiency but also reduces costs by leveraging existing hardware, making it accessible for widespread adoption in the automotive industry. Future work could extend this design to support more complex motor control unit protocols, such as CAN or Ethernet communication, further broadening its applicability in vehicle electrification and autonomous driving contexts.

Scroll to Top