Un desarrollador conecta la IA al diagnóstico de un Jeep de 1994 con un kit de $15

Los equipos antiguos pueden tener una electrónica que funciona, pero ofrecer un acceso poco práctico a sus datos. Para conectarles un agente de IA, primero hace falta un puente entre el conector físico y el software. El desarrollador MZULALI ha mostrado uno de estos puentes en un Jeep Cherokee de 1994: el proyecto xj-scanner permite a un agente obtener datos de diagnóstico mediante Arduino y Python. Para los desarrolladores, lo útil es el propio esquema de integración: proporcionar al modelo un conjunto limitado de comandos claros y obtener resultados que se puedan verificar.

Cómo dar al agente acceso al motor

El repositorio de xj-scanner describe un montaje con tres cables, un Arduino Nano y un portátil. La placa se conecta al puerto de diagnóstico situado bajo el capó y al ordenador mediante USB. El autor calcula que el kit cuesta aproximadamente $15, sin incluir el portátil.

Cada componente tiene su función. Arduino se encarga de la comunicación con la electrónica del vehículo, el programa del ordenador ofrece los comandos de diagnóstico y el agente elige cuáles ejecutar en función de la petición del usuario. Esta separación de responsabilidades resulta útil: permite comprobar la gestión del protocolo de forma independiente al razonamiento del modelo.

Un posible caso de uso sería el siguiente: el propietario indica que el motor funciona de forma irregular después de calentarse. Se pide al agente que recopile lecturas y las compare a lo largo del tiempo. Después, una persona revisa el registro obtenido y las explicaciones propuestas. Es un ejemplo de aplicación, no el resultado publicado de una reparación: el mero acceso a los sensores no confirma que el diagnóstico sea correcto.

En este trabajo, lo que importa es la cadena de evidencias. ¿Qué datos se solicitaron? ¿Qué devolvió realmente el coche? ¿En qué observación se basa la hipótesis? Si la respuesta del agente no puede vincularse a mediciones concretas, una explicación elegante sirve de poco en el taller.

Qué pueden aprovechar los desarrolladores

El proyecto muestra cómo ampliar las capacidades de un agente mediante la línea de comandos. El repositorio incluye un escáner, herramientas auxiliares e instrucciones para el agente. También dispone de un modo DEMO que simula un vehículo y permite probar el software antes de conectarlo al coche. Estas funciones se describen en el README del proyecto.

De ahí se desprende una conclusión práctica de ingeniería: conviene que el primer paso de una integración de este tipo sea crear una herramienta independiente. Debe funcionar mediante un comando explícito y devolver un resultado comprensible. Así resulta más fácil analizar el comportamiento de todo el sistema: si un error se produjo en la comunicación con el dispositivo, en el procesamiento de la respuesta o en las conclusiones del modelo.

En un producto también importa cómo se presenta el resultado al usuario. Las mediciones, las suposiciones y las propuestas de comprobación deben identificarse por separado. La frase «el sensor registró este valor» tiene un peso distinto de «es posible que esta sea la causa». Mezclar estos niveles genera una falsa confianza incluso cuando el hardware funciona correctamente.

Por último, conviene conservar la posibilidad de repetir una acción manualmente. Cuando el usuario puede ver el comando ejecutado y la respuesta original, puede comprobar el trabajo del agente o entregar el material a un especialista. Una interfaz así hace que la automatización resulte más comprensible y facilita la búsqueda de errores.

Dónde termina la demostración

El autor probó el sistema en un único Jeep Cherokee XJ de 1994 con motor de 4,0 litros. Se prevé que sea compatible con otras unidades de control de la familia SBEC de vehículos Jeep y Chrysler de 1991–1995, pero esa compatibilidad no se ha confirmado mediante pruebas. El código se publica bajo GPLv3; las condiciones y los límites del proyecto figuran en el repositorio.

También existe una diferencia importante entre observar y actuar: el escáner admite las pruebas de actuadores incorporadas. Por eso, al desarrollar un producto propio, conviene configurar por separado el acceso a la lectura de datos y a los comandos que modifican el estado del equipo. Aquí entran en juego el diseño de la interfaz y los permisos del agente.

Por ahora, es un proyecto de aficionado con una compatibilidad verificada muy limitada. Ofrece a los desarrolladores material concreto para estudiar: un puente de hardware, comandos de diagnóstico, un modo de demostración e instrucciones. Para los responsables de producto, es una oportunidad de poner a prueba su idea en una parte pequeña del trabajo: qué mediciones ayuda realmente a obtener y comprender el agente, cuántos pasos ahorra y en qué puntos una persona todavía tiene que volver a comprobar sus conclusiones.