Hyundai Kefico Standardizes ECU Production Test with NI PXI Hardware
Case Study Highlights
Hyundai Kefico reduced development dependency on product-specific testers by deploying a reusable, script-driven PXI-based platform across multiple ECU types.
The common test platform resulted in faster deployment for new products through quick response to test specification changes and improved test logic reusability.
“After moving to a unified NI PXI architecture, the hardware and software became consistent across projects, and many of those uncertainties disappeared. Now we can focus on the test requirements instead of dealing with system-to-system differences.”
—Won-Kyung HAM, Ph.D, Manufacturing Engineering Team 1, Hyundai Kefico
The Challenge
Complex vehicle electronics require increasing hardware, software, and communication interface interactions across a wide range of ECUs. It’s no longer sufficient to test components independently—we must ensure the system behaves consistently across many edge cases. The challenge is not just technical complexity, but keeping the test architecture stable while the product evolves rapidly.
The Solution
A common test system enables a single platform to test many products through script-driven flexibility. By building a generic and scalable functional test system, Hyundai Kefico standardized how test procedures are defined, executed, and maintained—reducing dependency on product-specific testers and improving development efficiency and production scalability.
Why Standardize Test Equipment?
Hyundai Kefico is responsible for research, development, validation, and production of a range of automotive electronic components.
As vehicles become more complex, the test equipment we develop must handle higher data volumes, more communication protocols, and tighter reliability requirements. This requirement means that production test teams focus not only on hardware-level verification but also on ensuring our test systems can support increasingly integrated and software-centric ECUs. It has pushed my role to combine deeper technical understanding with stronger coordination among the people involved in development and production.
In addition, as vehicle powertrains evolve, the range of components required to support electric, hybrid, fuel-cell, and combustion vehicles, not to mention charging infrastructure and body control modules, has expanded dramatically. This complexity creates a challenge for test teams as each product type demands different functional test procedures, but dedicated, product-specific test equipment development is not scalable.
In light of this, our team at Hyundai Kefico needed to design a standardized test architecture that could meet the following requirements:
Support multiple product types with a flexible test system
Allow engineers to develop test procedures once
Apply those procedures directly to production test equipment
The goal was standardizing execution, isolating hardware dependencies, and keeping test logic product-specific yet equipment-independent.
Architecture Requirements
Our key goals for an adaptable, reusable testing system architecture included:
Product-type flexibility—Support multiple automotive electronic components with different test procedures such as vehicle control system, battery management system, electric power control, hydrogen supply system, engine control unit, and transmission control
Separation of concerns—Decouple test procedure development from test equipment hardware
Direct applicability—Engineer-developed test procedures must run as-is on production test equipment
Reusability—Test procedures should be reusable across products and production lines
Approach
We designed a common platform (CP) around three central pillars, as depicted in Figure 1:
Script development—Engineers define test methods, sequences, and specifications as standardized test scripts
Central management—Test scripts are centrally managed and distributed
Hardware abstraction—Production test equipment executes scripts on a standardized test platform
Figure 1. Common Platform Workflow Concept
The test script layer provides a standardized test script to define product specific test logic: test methods, execution sequences, specifications, and criteria. This test logic is decoupled from the test equipment configuration and hardware, as shown in Figure 2.
The test execution framework serves as a common execution engine shared across all products. This framework interprets test scripts, controls test execution flow, handles measurements and result evaluation, and manages error handling and logging, all independent of product type.
Figure 2. Test Execution Framework Architecture
Finally, the hardware abstraction layer provides standardized control interfaces between the test execution framework and physical hardware, regardless of device type or vendor, enabling the same test scripts and execution framework to run on different hardware configurations, as depicted in Figure 3.
Figure 3. Hardware Abstraction
Hardware abstraction enables hardware flexibility without breaking test standardization.
We deployed the PXI‑based CP‑Tester by standardizing the core architecture and using PXI’s modular hardware structure, which made configuration changes much easier. The PXI platform also provided a clean software interface layer, so integrating new functions or protocols required minimal redesign. As a result, we could support major EV projects by reusing the same architecture and updating only the necessary modules.
Today, the CP-Tester is in use testing a wide range of electronic control units across Hyundai Kefico’s production facilities through several variants of this standardized platform. To standardize the testing of various ECU types with fewer than 200 pins, multiple NI PXI matrix modules are extensively utilized. In a typical configuration, two PXI chassis are connected in a daisy-chain topology. Aside from the matrix, the other modules consist of PXI modular instruments and PXI reconfigurable multifunction I/O modules. The following list provides some example tester configurations.
CP: general control unit
DUTs: main powertrain control units (ECU, TCU, PCU) and EV control units (VCU, SCU, CVMS, and more)
NI PXI hardware: matrix switches, DMM, DAQ, SMU, CAN, variable resistor
Additional hardware: power supply, dummy loads, function generator
CP: wireless RF capability test
DUTs: wireless BMU and CMU
Hardware: wireless test system, power supply, F/Q debugger with UART module
CP: motor control units
NI PXI hardware: matrix switch, DMM, DAQ, CAN, variable resistor
Value and Impact
Before using the standardized PXI-based hardware, everything felt like a black box. Each system integrator built testers differently; even basic function standardization was difficult, and every project started from scratch. A good example is the matrix switch. Before, every vendor had a different way of building the matrix, so the routing felt inconsistent. It made it difficult to standardize even simple functions. After moving to the PXI matrix switch, the routing and channel behavior became the same across all testers, so function standardization finally became straightforward.
The value of standardization on the CP-Tester includes the following benefits:
Faster deployment for new products
Quick response to test specification changes
Reduced dependency on product-specific test equipment
Improved reusability of test logic
Clear separation of test logic, execution, and hardware
After the standardized hardware and software proved reliable across multiple projects, development became much easier and we could focus on the actual test instead of building a new system every time. Over time, we realized that standardization isn’t a single object—it’s a culture. It’s a living system that breaks if we don’t keep updating it. So now the whole team stays involved to keep it running and improving across all projects.
With scalable hardware and clear test methods, I’m confident we can extend the existing system, so I focus on how to integrate new requirements without causing issues in the legacy architecture. It shifted my mindset from replacing the setup to finding controlled, scalable ways to upgrade it.