Hyundai Kefico estandariza la prueba de producción de ECU con hardware NI PXI

​¿Por qué estandarizar el equipo de prueba? 

​Hyundai Kefico es responsable de la investigación, desarrollo, validación y producción de una gama de componentes electrónicos para automóviles.  

​A medida que los vehículos se vuelven más complejos, los equipos de prueba que desarrollamos deben manejar mayores volúmenes de datos, más protocolos de comunicación y requisitos de confiabilidad más estrictos. Este requisito significa que los equipos de prueba de producción se centran no solo en la verificación a nivel de hardware, sino también en garantizar que nuestros sistemas de prueba puedan soportar ECU cada vez más integradas y centradas en el software. Me ha llevado a combinar una comprensión técnica más profunda con una mayor coordinación entre las personas que participan en el desarrollo y la producción. 

​Además, a medida que evolucionan los trenes motrices de los vehículos, la gama de componentes necesarios para soportar vehículos eléctricos, híbridos, de pila de combustible y de combustión, por no mencionar la infraestructura de carga y los módulos de control de carrocería, se ha ampliado drásticamente. Esta complejidad crea un desafío para los equipos de prueba, ya que cada tipo de producto exige diferentes procedimientos de prueba funcionales, pero el desarrollo de equipos de prueba específicos para cada producto no es escalable. 

​A la luz de esto, nuestro equipo en Hyundai Kefico necesitaba diseñar una arquitectura de prueba estandarizada que pudiera cumplir con los siguientes requisitos:  

• ​Soporte para múltiples tipos de productos con un sistema de prueba flexible 

• ​Permitir a los ingenieros desarrollar procedimientos de prueba una vez 

• ​Aplicar estos procedimientos directamente a los equipos de ensayo de producción 

​El objetivo era estandarizar la ejecución, aislar las dependencias de hardware y mantener la lógica de prueba específica del producto pero independiente del equipo. 

​Requisitos de arquitectura 

​Nuestros objetivos clave para una arquitectura de sistema de pruebas adaptable y reutilizable incluyeron: 

• ​Flexibilidad del tipo de producto: admite múltiples componentes electrónicos automotrices con diferentes procedimientos de prueba, como el sistema de control del vehículo, el sistema de gestión de baterías, el control de energía eléctrica, el sistema de suministro de hidrógeno, la unidad de control del motor y el control de la transmisión  

• ​Separación de preocupaciones: desacoplar el desarrollo del procedimiento de prueba del hardware del equipo de prueba 

• ​Aplicabilidad directa: los procedimientos de prueba desarrollados por ingenieros deben ejecutarse tal cual en los equipos de prueba de producción 

• ​Reusabilidad: los procedimientos de prueba deben ser reutilizables en todos los productos y líneas de producción 

   

​Enfoque  

​Diseñamos una plataforma común (CP) alrededor de tres pilares centrales, como se representa en la Figura 1: 

• ​Desarrollo de guiones: los ingenieros definen los métodos, secuencias y especificaciones de prueba como guiones de prueba estandarizados 

• ​Gestión centralizada: los guiones de prueba se gestionan y distribuyen de forma centralizada 

• ​Abstracción de hardware: el equipo de prueba de producción ejecuta scripts en una plataforma de prueba estandarizada 

   

   

  

​Figura 1. Concepto de flujo de trabajo de plataforma común

​La capa de guion de prueba proporciona un guion de prueba estandarizado para definir la lógica de prueba específica del producto: métodos de prueba, secuencias de ejecución, especificaciones y criterios. Esta lógica de prueba se desacopla de la configuración del equipo de prueba y el hardware, como se muestra en la Figura 2.

​El marco de ejecución de pruebas sirve como un motor de ejecución común compartido en todos los productos. Este framework interpreta scripts de prueba, controla el flujo de ejecución de pruebas, maneja mediciones y evaluación de resultados, y administra el manejo y registro de errores, todo independiente del tipo de producto. 

​Figura 2. Arquitectura de marco de ejecución de pruebas

​Finalmente, la capa de abstracción de hardware proporciona interfaces de control estandarizadas entre el marco de ejecución de pruebas y el hardware físico, independientemente del tipo de dispositivo o proveedor, lo que permite que los mismos scripts de prueba y marco de ejecución se ejecuten en diferentes configuraciones de hardware, como se representa en la Figura 3.

​Figura 3. Abstracción de hardware

​La abstracción de hardware permite flexibilidad de hardware sin romper la estandarización de prueba.

​Implementamos el CP-Tester basado en PXI estandarizando la arquitectura central y utilizando la estructura modular de hardware de PXI, lo que facilitó mucho los cambios de configuración. La plataforma PXI también proporcionaba una capa de interfaz de software limpia, por lo que la integración de nuevas funciones o protocolos requería un rediseño mínimo. Como resultado, podríamos apoyar grandes proyectos de EV reutilizando la misma arquitectura y actualizando solo los módulos necesarios.

​Hoy en día, el CP-Tester está probando una amplia gama de unidades de control electrónico en las instalaciones de producción de Hyundai Kefico a través de varias variantes de esta plataforma estandarizada. Para estandarizar la prueba de varios tipos de ECU con menos de 200 pines, se utilizan ampliamente múltiples módulos de matriz NI PXI. En una configuración típica, dos chasis PXI están conectados en una topología de cadena de margaritas. Aparte de la matriz, los otros módulos consisten en instrumentos modulares PXI y módulos de E/S multifunción reconfigurables PXI. La siguiente lista proporciona algunas configuraciones de probador de ejemplo.

​CP: unidad de control general

• ​DUTs: unidades de control del tren motriz principal (ECU, TCU, PCU) y unidades de control del EV (VCU, SCU, CVMS, y más)

• ​Hardware NI PXI: conmutadores de matriz, DMM, DAQ, SMU, CAN, resistencia variable

• ​Hardware adicional: fuente de alimentación, cargas ficticias, generador de funciones

   

​CP: prueba de capacidad de RF inalámbrica

• ​DUTs: BMU inalámbrica y CMU

• ​Hardware: Wireless Test System, fuente de alimentación, depurador F/Q con módulo UART

   

​CP: unidades de control del motor

• ​Hardware NI PXI: interruptor de matriz, DMM, DAQ, CAN, resistencia variable

   

​Valor e impacto

​Antes de usar el hardware estandarizado basado en PXI, todo parecía una caja negra. Cada integrador de sistemas construyó probadores de manera diferente; incluso la estandarización básica de funciones fue difícil, y cada proyecto comenzó desde cero. Un buen ejemplo es el interruptor de matriz. Antes, cada proveedor tenía una forma diferente de construir la matriz, por lo que el enrutamiento se sentía inconsistente. Dificulta la normalización de funciones incluso simples. Después de pasar al conmutador de matriz PXI, el enrutamiento y el comportamiento del canal se volvieron los mismos en todos los probadores, por lo que la estandarización de funciones finalmente se volvió sencilla.

​El valor de la estandarización en el CP-Tester incluye los siguientes beneficios:

• ​Implementación más rápida para nuevos productos

• ​Respuesta rápida a los cambios en las especificaciones de prueba

• ​Reducción de la dependencia del equipo de ensayo específico del producto

• ​Mejora de la reutilización de la lógica de prueba

• ​Separación clara de la lógica de prueba, la ejecución y el hardware

   

​Después de que el hardware y el software estandarizados resultaran confiables en múltiples proyectos, el desarrollo se volvió mucho más fácil y pudimos centrarnos en la prueba real en lugar de construir un nuevo sistema cada vez. Con el tiempo, nos dimos cuenta de que la estandarización no es un solo objeto, es una cultura. Es un sistema vivo que se rompe si no seguimos actualizándolo. Así que ahora todo el equipo sigue involucrado para mantenerlo funcionando y mejorando en todos los proyectos.

​Con hardware escalable y métodos de prueba claros, estoy seguro de que podemos ampliar el sistema existente, por lo que me concentro en cómo integrar nuevos requisitos sin causar problemas en la arquitectura heredada. Cambió mi mentalidad de reemplazar la configuración a encontrar formas controladas y escalables de actualizarla.