Refrigeración inteligente DENSO: convertir las señales de control en requisitos HVAC claros

Actualización técnica

El 3 de junio de 2026, DENSO publicó una actualización sobre el cambio de enfriamiento del motor accionado mecánicamente hacia sistemas térmicos controlados electrónicamente. Se discuten bombas eléctricas de refrigerante, control de PWM y termostatos gestionados electrónicamente, junto con la necesidad de un diagnóstico a nivel de sistema. Esta es una actualización técnica del sector, no una afirmación de que cada vehículo o controlador HVAC soporta la misma interfaz eléctrica o de comunicación. [Fuente]

El tema es directamente pertinente para las investigaciones de OEM HVAC. Los clientes a menudo preguntan si un sistema tiene CAN, RS-232, RS-485 u otra interfaz antes de explicar la información que realmente necesitan. Un proveedor puede responder a la pregunta de nombre de interfaz y todavía no resolver el problema del cliente.

Este artículo establece un método más claro para definir los requisitos de control y retroalimentación. No especifica cableado para un producto en particular. Cualquier conexión, característica eléctrica o protocolo debe ser confirmado para el control exacto y la disposición del vehículo a través de los proveedores responsables.

Comience con el resultado solicitado

Pida al cliente que describa lo que el vehículo debe saber o hacer. ¿Tiene que saber si el aire acondicionado está funcionando? ¿Debe habilitar o desactivar la unidad? ¿Tiene que cambiar un ajuste de temperatura, leer un fallo o monitorear un valor medido? Estas son funciones separadas.

Un cliente que solicita únicamente una indicación de inicio/desactivación puede no necesitar un protocolo de comunicación completo. A la inversa, una solicitud de control remoto puede requerir más que una salida de estado. El proyecto no debe agregar complejidad simplemente porque un nombre de interfaz familiar aparece en un correo electrónico temprano.

Escribe el resultado en una frase corta y confirmalo con el cliente. Por ejemplo, el controlador del vehículo necesita una indicación de que el sistema HVAC está funcionando, con el significado exacto de funcionamiento que aún no se ha acordado. Esa frase revela una pregunta importante en lugar de seleccionar prematuramente un conector o autobús.

El proveedor puede entonces proponer un formulario de señal adecuado y explicar sus límites. Esta secuencia facilita la conversación técnica para ambos lados y reduce la posibilidad de que un controlador sea ordenado con la capacidad equivocada.

Separación de energía, mando, retroalimentación y diagnóstico

La energía proporciona la energía que un dispositivo necesita. Un comando pide comportamiento. La retroalimentación reporta un estado o medición. Los diagnósticos proporcionan información útil para identificar o investigar una afección. Un único arreglo de conexión puede soportar varias funciones, pero la especificación debe mantenerlas distintas.

La confusión surge a menudo cuando un comprador trata un comando como prueba de operación. Un controlador puede solicitar enfriamiento mientras el equipo está esperando una condición habilitante o operando dentro de un límite de protección. El estado solicitado y el estado alcanzado no son necesariamente idénticos.

Del mismo modo, una señal de potencia presente no prueba que un compresor o ventilador esté funcionando. Una indicación libre de fallos no demuestra necesariamente que el espacio ocupado haya alcanzado la condición deseada. El significado de cada señal debe indicarse con suficiente precisión para que el controlador receptor pueda utilizarla correctamente.

Crea una lista de señales con una fila por función. Describa la fuente, el destino, el significado y el comportamiento requerido. Esto se puede hacer antes de elegir la forma eléctrica. Da a los equipos de hardware y software una base funcional compartida para el diseño de la interfaz.

Definir lo que significa

Una petición de estado de activación/desactivación suena simple hasta que el equipo pregunta qué representa en. Podría significar que el panel de control está alimentado, que un usuario ha habilitado el sistema, que el soplador está funcionando, que el compresor está comandado o que un estado de refrigeración particular está activo. Esos significados no son intercambiables.

Pregunte al cliente qué decisión tomará el sistema receptor desde la señal. Si sólo ilumina un indicador de estado, el significado requerido puede diferir de una señal utilizada para coordinar la asignación de energía u otra función del vehículo. La consecuencia de la señal determina con qué precisión debe definirse.

También definir los estados de transición. ¿Qué debe mostrar la salida durante la puesta en marcha, una pausa temporal o una parada protectora? Una señal binaria puede ser suficiente, pero su comportamiento debe ser documentado. Si una representación binaria no puede apoyar la decisión del cliente, el equipo puede necesitar una descripción de estado más rica.

El resultado debe ser un pequeño cuadro de estado que ambos proveedores aprueban. Es mucho más útil que una declaración sin reservas de que la unidad tiene una señal de activación/desactivación. La tabla evita desacuerdos posteriores sobre si una salida técnicamente operativa está informando el estado que el cliente pretendía.

Elija la forma eléctrica después del significado

Una vez definida la función, el proveedor del controlador puede identificar posibles formas eléctricas. El sistema del vehículo receptor debe confirmar lo que puede aceptar. Las dos partes deberían acordar los niveles pertinentes, la referencia, el aislamiento cuando sea necesario y la disposición de conexión para el diseño real.

No deduzca esos detalles de una etiqueta casual como contacto seco, señal de voltaje o salida de comunicación. La aplicación exacta es importante. El proveedor debe proporcionar la información técnica necesaria para el ingeniero del sistema receptor e identificar cualquier condición o limitación.

La especificación de la interfaz debe incluir la definición del conector y del pin, las condiciones de funcionamiento permitidas y los arreglos de protección o aislamiento requeridos según lo determinen los diseñadores responsables. También debe indicar qué organización suministra el arnés o el adaptador y verificar la conexión completada.

Este artículo no prescribe valores eléctricos porque deben provenir del equipo real. El requisito de la contratación es obtener y conciliar esos valores antes de la instalación. Adivinar un nivel de señal de una familia familiar de productos puede dañar el equipo o producir comportamiento engañoso.

Un nombre de protocolo no es un acuerdo completo

CAN, LIN, RS-232 y RS-485 describen diferentes aspectos de la tecnología de comunicación, pero un nombre de interfaz por sí solo no define los mensajes de aplicación o el comportamiento esperado por el vehículo. Debe confirmarse el protocolo y la configuración exactas.

Para una interfaz de datos, pregunte qué comandos y valores de estado son soportados, cómo están representados y con qué frecuencia son transmitidos o solicitados. Identificar las versiones requeridas y cualquier configuración necesaria en ambos extremos. El sistema receptor debe interpretar la información de la misma manera que el remitente lo pretende.

El proyecto también debe definir cómo se maneja la información faltante, inválida o inválida. Un controlador que sigue mostrando el último valor recibido sin indicar la pérdida de comunicación puede crear una impresión engañosa de la operación actual. El comportamiento requerido pertenece a la especificación funcional.

Un proveedor puede proporcionar un documento de protocolo u otro paquete de interfaz técnica acordado. El comprador deberá entonces organizar una prueba de compatibilidad para las funciones solicitadas. Los conectores similares o la tecnología de un autobús compartido no sustituyen esa prueba.

Utilice una tabla de estados para exponer la ambigüedad

Considere un sistema HVAC hipotético con cinco estados: alimentado pero deshabilitado, habilitado y esperando, enfriando activamente, temporalmente limitado y fallado. Un cliente pide una única señal marcada AC. El equipo debe decidir cuál de esos estados produce una indicación activa.

Si el cliente sólo quiere saber si el operador ha habilitado el sistema, la señal puede permanecer activa mientras la unidad está esperando. Si el cliente necesita confirmación de refrigeración activa, ese mismo comportamiento sería inadecuado. La solicitud original usó las mismas palabras, pero las decisiones previstas son diferentes.

La tabla de estados debe describir la salida requerida en cada estado y el tiempo asociado con las transiciones. También debe identificar el comportamiento cuando el controlador pierde energía o la conexión se interrumpe. Los ingenieros responsables determinan la implementación apropiada y el retroceso.

Este ejemplo no es una especificación para ningún controlador VETHY. Demuestra por qué la aclaración funcional debe preceder a una promesa de compatibilidad. Una tabla corta puede prevenir un problema de integración mucho mayor después de que el hardware ha sido comprado e instalado.

El tiempo importa incluso para una simple retroalimentación

El sistema receptor necesita saber cuán rápido una señal sigue un cambio y cómo se representan las condiciones temporales. Un estado que se actualiza lentamente puede ser aceptable para una pantalla, pero inadecuado para otro propósito de control. El tiempo requerido debe seguir el caso de uso real.

Defina si una breve transición debe notificarse inmediatamente o tratarse de acuerdo con una regla de filtrado acordada. El proveedor debe explicar el comportamiento de su controlador real. Evite asumir que una salida cambia al mismo instante que el proceso físico subyacente.

Para las interfaces de datos, distinga el tiempo de transmisión de la edad de la medición subyacente. Un mensaje transmitido con frecuencia todavía puede contener un valor que no ha sido actualizado como se esperaba. La interfaz debe proporcionar la información necesaria para interpretar su moneda cuando ello sea importante.

Durante la prueba, grabar comandos, estados reportados y observaciones pertinentes con una base de tiempo consistente. Esto ayuda al equipo a entender los retrasos y la secuencia. Una captura de pantalla de un valor puede confirmar que un mensaje existe sin demostrar que se comporta correctamente a través del ciclo de operación.

Plan de pérdida de energía o comunicación

Cada interfaz debe haber definido el comportamiento cuando la ruta de información normal no está disponible. La respuesta correcta depende de la función del vehículo y debe ser determinada por los ingenieros responsables. No debe ser improvisado por un instalador en el punto de conexión.

Pregunte lo que ve el sistema receptor cuando el controlador HVAC no está alimentado, desconectado o reiniciado. Distinguir esas condiciones de un estado fuera válido cuando sea necesario. Una única señal puede ser ambigua a menos que el diseño explique cómo están representados los fallos y los estados normales.

El controlador del vehículo también debe tener una respuesta definida a la información no disponible. Tal vez sea necesario indicar incertidumbre, utilizar un revés aprobado o adoptar otra medida especificada en el diseño del vehículo. La clave es que el comportamiento es acordado y probado en lugar de suponer.

Registrar las limitaciones en el alcance técnico orientado al cliente. Una salida básica de estado puede proporcionar intencionalmente menos información que una interfaz de diagnóstico. Eso puede ser aceptable cuando se ajusta al requisito, pero el cliente no debe esperar detalles de falla que el arreglo elegido no puede entregar.

Construir una prueba de compatibilidad alrededor de las funciones reales

Una prueba útil comprueba los comandos y estados que el cliente pretende utilizar. Debe incluir el funcionamiento normal, las transiciones pertinentes y los casos definidos de información no disponible. El método exacto debe ser adecuado al equipo y aprobado por los equipos responsables.

Utilice las versiones de controlador previstas y la configuración cuando sea práctico. Si se utiliza un simulador o una interfaz temporal, documentar cómo representa el sistema final del vehículo y lo que queda por comprobar más adelante. Un exitoso intercambio de banco no necesariamente establece el comportamiento instalado completo.

El registro de prueba debe identificar hardware, software, cableado o arreglo de conexión y el resultado esperado para cada caso. Registrar el resultado observado y cualquier desviación. Esto crea pruebas que pueden ser revisadas por ambos proveedores sin contar con una declaración verbal de que la comunicación funcionó.

Cuando se encuentre un problema, actualice el documento de interfaz o la implementación a través del control de cambios. Reprueba las funciones afectadas y cualquier comportamiento relacionado identificado por los ingenieros. La compatibilidad se convierte en un resultado controlado del proyecto en lugar de una demostración única que es difícil de reproducir.

Diagnosticar el sistema en lugar del componente más visible

El control térmico electrónico puede producir síntomas que requieren tanto investigación física como a nivel de señal. El taller necesita comprender la relación entre una solicitud, la respuesta del controlador y el comportamiento real del equipo. La sustitución de un componente sin ese contexto puede dejar sin resolver la causa.

Un registro de servicio útil incluye el modo solicitado, el estado notificado, las condiciones de suministro pertinentes y la información de fallo disponible a través de la interfaz aprobada. Debe identificar las versiones instaladas del controlador y cualquier cambio reciente. Los datos recogidos deben responder a una pregunta de diagnóstico en lugar de simplemente acumular valores.

El equipo de servicio debe saber qué observaciones provienen de los sensores y cuáles son los estados inferidos o comandados. Una solicitud de bomba o compresor no puede ser una medición directa del funcionamiento físico. Las etiquetas claras ayudan a prevenir una conclusión incorrecta.

El fabricante o el proveedor de servicios calificado debe definir los controles apropiados para el sistema. Este artículo no sustituye a esos procedimientos. Su punto práctico es que la especificación de la interfaz y la documentación diagnóstica deben desarrollarse juntos, porque ambos dependen de una comprensión compartida del estado y la responsabilidad.

Mantener la personalización del controlador dentro de un ámbito definido

Si actualmente no se admite una interfaz solicitada, el proveedor puede proponer personalización. El comprador debería solicitar un ámbito de desarrollo que cubra las funciones, los cambios de hardware o software, el proceso de muestra y las responsabilidades de validación. Una declaración de que la personalización es posible no es un diseño completo.

Identificar quién es el dueño del protocolo o la información de señal requerida y quién puede aprobar el resultado. El proveedor puede necesitar detalles del fabricante del controlador principal del cliente. Sin esos insumos, no puede prometer la compatibilidad o estimar el trabajo de forma fiable.

En la cita se debe distinguir la capacidad existente de los nuevos desarrollos. Indicar los resultados y los criterios de aceptación para el trabajo a medida. Esto protege a ambas partes del tratamiento de un debate preliminar como un compromiso de producción incondicional.

Después de la aprobación, conserve la configuración personalizada en el registro del producto. Los reemplazos de servicio deben coincidir con la versión pertinente o seguir una ruta de actualización aprobada. Una interfaz personalizada pierde valor si el proceso de reemplazo más tarde suministra un controlador estándar que no proporciona la función requerida.

Una entrega concisa del proveedor

La entrega más útil comienza con el resultado requerido del cliente: qué información debe recibirse o qué acción debe comandarse. A continuación identifica el controlador receptor, el formulario de señal propuesto si se conoce y el contexto del vehículo.

Pida al fabricante del controlador que confirme si el diseño actual admite esa función. Si lo hace, solicite la definición eléctrica y funcional, la información del conector y la aplicabilidad de la versión. En caso contrario, solicitar el alcance y las pruebas necesarias para una posible modificación.

Incluya el momento, los estados normales y el comportamiento requeridos cuando la información no esté disponible. Indicar si la función es para exhibición, coordinación u otro propósito. Esto da al proveedor el contexto necesario para juzgar si una simple salida es suficiente o una interfaz más detallada es necesaria.

La respuesta debe revisarse con el ingeniero del sistema receptor antes de su instalación. Las dos partes deben acordar la misma función y la misma aplicación. Esta conciliación final es lo que convierte una lista de funciones de interfaz en una integración real del vehículo.

Una mesa de estado funcional antes de un dibujo eléctrico

La siguiente tabla es una herramienta de aclaración hipotética. No describe una salida VETHY existente y no especifica un voltaje, conector o circuito. Su propósito es ayudar a un cliente a decidir qué información necesita realmente antes de pedir al fabricante del controlador que la implemente.

El ingeniero del sistema receptor debe explicar qué decisión sigue cada respuesta. Si la señal sólo impulsa una pantalla, una definición simple puede ser adecuada. Si coordina otra función, la información requerida y el retroceso pueden ser diferentes. La aplicación debería seguir ese objetivo.

Una vez acordada la mesa funcional, el proveedor del controlador puede proponer el formulario eléctrico o de comunicación. El proveedor del lado del vehículo verifica la compatibilidad. El documento de interfaz final debe conectar el significado funcional a la implementación exacta para que ninguna de las partes tenga que inferir la relación.

Este pedido es eficaz porque impide que el equipo debata CAN, enlaces serie o contactos antes de saber si el cliente necesita un estado o varios. También puede revelar que una función soportada existente es suficiente, evitando personalización innecesaria.

Durante las pruebas, utilice la tabla como el registro de resultados esperados. Observar cada estado relevante a través de un método aprobado y registrar lo que el sistema receptor muestra o hace. Una prueba que sólo muestra el estado activo deja sin resolver la espera ambigua y los estados no disponibles.

Mantenga la tabla aprobada con el registro de la versión del controlador. Si el software cambia, revise si el significado reportado o los cambios de tiempo. No debe suponerse que un reemplazo físicamente idéntico sea funcionalmente idéntico sin la información de configuración pertinente.

Para una respuesta orientada al cliente, el proveedor puede entonces indicar la función confirmada en lenguaje simple y adjuntar la definición técnica. Esa respuesta es más útil que decir sólo que una interfaz es soportada, porque le dice al cliente lo que el vehículo realmente sabrá.

Preguntas frecuentes

Si un cliente sólo necesita una señal de activación/desactivación, ¿debe usar el sistema CAN?

No necesariamente. La forma apropiada depende de la función y del controlador receptor. Defina primero el significado y los requisitos eléctricos, luego obtenga confirmación de ambos proveedores. Una interfaz más sencilla puede ser suficiente, pero debe ser especificada correctamente.

¿Es una entrada habilitada lo mismo que la retroalimentación operativa?

No. No, no. Un habilitar las solicitudes de entrada o permite el funcionamiento. La retroalimentación reporta un estado definido. El equipo puede no funcionar exactamente como se solicita, por lo que las dos funciones deben permanecer separadas en la especificación.

¿Puede una etiqueta compartida de RS-485 o CAN demostrar la compatibilidad?

No. No, no. El protocolo de aplicación, la configuración y el comportamiento deben coincidir. Solicite la información técnica pertinente y pruebe las funciones requeridas por el vehículo en lugar de basarse únicamente en el nombre de la interfaz.

¿Qué puede confirmar VETHY antes de hacer prometer una interfaz?

VETHY debe confirmar el requisito con el cliente y obtener la capacidad exacta del proveedor del controlador. La respuesta debe identificar el modelo, la versión, la definición de la señal y cualquier trabajo de desarrollo. Las funciones no verificadas CAN, serie o estado-feedback no deben ser anunciadas como características estándar.

Hacer que el requisito comprensible antes de hacerlo técnico

La especificación de interfaz más fuerte comienza con una frase operativa clara y termina con un acuerdo eléctrico o de comunicación probado. Esa secuencia evita la complejidad innecesaria y expone la información faltante temprano.

La actualización de DENSO es un recordatorio útil de que los sistemas térmicos dependen cada vez más de controles y de hardware. Los compradores pueden responder separando las solicitudes, estados, mediciones y diagnósticos, y luego pedir a los proveedores que confirmen las funciones exactas de sus necesidades de vehículo.