De reparar placas a virtualizar la máquina: caso terminal de apuestas MAX-3000

Todo jefe de mantención conoce esta situación: un equipo crítico que ya no se fabrica, sin planos, sin repuestos y con un fabricante que está lejos o ya no responde. Mientras funcione, nadie lo toca. Cuando falla, el problema es de la planta completa.

Este caso cuenta cómo enfrentamos ese escenario con un equipo muy particular: las terminales de apuestas Autotote MAX-3000 de un importante hipódromo de la región. La historia no parte con una máquina virtual. Parte con años de reparaciones a nivel componente, con herramientas compradas para entender el equipo y con muchas horas de banco. La máquina virtual fue el resultado de todo eso.

Reparar la placa madre, una y otra vez

La MAX-3000 es una terminal de ventanilla: pantalla LCD, teclado propio, impresora térmica de boletos y una línea de comunicaciones hacia el sistema central de apuestas. Su placa madre reúne procesador, memorias con el programa, comunicaciones serie, lógica programable y una memoria con respaldo a batería para la configuración: electrónica de los años 90, sin repuestos en el mercado.

Durante años esas placas llegaron a nuestro banco con fallas variadas: problemas de alimentación, comunicaciones que se caían, terminales que no cortaban el boleto y placas que no llegaban a quedar operativas. Algunas se explicaban por la memoria con respaldo a batería, pero no hay una falla única: cada placa exigía diagnóstico propio. En paralelo comparamos placas buenas y malas de distintas revisiones (B y E) para entender qué cambiaba entre ellas.

Primer acercamiento: sacar el ticket con un analizador lógico

El primer paso para entender la máquina "desde adentro" no fue leer su programa: fue escucharla. Con un analizador lógico capturamos las señales que la placa envía a la impresora y, a partir de ellas, reconstruimos la imagen del ticket.

Ese ejercicio nos confirmó algo clave: la máquina se podía entender por sus señales, sin depender de documentación del fabricante. Fue el punto de partida de todo lo que vino después.

Invertir en herramientas para hablar con el procesador

Para ir más allá de la reparación había que conectarse directamente al procesador y leer su programa. Eso significó invertir, sin garantía de resultado:

• Interfaces NXP con BDM (Background Debug Mode), herramientas de depuración para trabajar directamente con el procesador.
• Raspberry Pi como puente y banco de pruebas para las interfaces de depuración y de comunicaciones.
• Trazador de curvas para comparar, sin energizar, la firma eléctrica de cada pin entre una placa buena y una mala.
• Programadores de memoria para respaldar y regrabar las memorias de la placa.
• Repuestos escasos y caros, que hubo que conseguir para reparar y para tener placas de referencia.

En esta etapa también ordenamos la documentación técnica disponible y fotografiamos la placa pieza por pieza para cruzar cada componente con su función.

Reconstruir el firmware completo

Con las herramientas listas respaldamos el programa de la terminal y lo reconstruimos completo, verificando el resultado por varias vías independientes antes de darlo por bueno.

Después vino el trabajo largo: entender cómo el programa usa cada parte de la placa, contrastándolo con lo que ya sabíamos del hardware. Es un trabajo de meses, hecho con herramientas profesionales de análisis de software.

La información acumulada reparando esta misma placa durante años fue la que permitió interpretar el firmware: cada componente que habíamos cambiado en el banco tenía ahora una función clara en el programa.

La máquina virtual

Con todo ese conocimiento construimos una máquina virtual: un programa que se comporta como la placa madre y ejecuta el firmware original de la terminal. Lo que en la máquina real es hardware, en la virtual es software: la pantalla se dibuja en una ventana, el teclado se opera desde el computador y la impresora genera cada ticket como imagen.

La prueba más clara fue el ticket de prueba: la máquina virtual imprime el mismo ticket que la terminal física.

Conectarla a la red real y validarla

Una máquina virtual que solo funciona en el escritorio no le sirve a nadie. El paso final fue llevarla a la instalación real, con una interfaz de hardware diseñada por nosotros y en pruebas coordinadas con el área de soporte del hipódromo, cuidando en todo momento no afectar la operación.

Hubo que resolver problemas que no aparecen en ningún manual: la máquina virtual tenía que replicar con exactitud los tiempos de la electrónica original.

El resultado: la terminal virtual llegó al mismo estado de comunicaciones que una terminal física, con una validación clara del equipo técnico del cliente.

Qué significa esto para tu planta

La MAX-3000 es un equipo de apuestas, pero el problema es el mismo que tienen un PLC descontinuado, una HMI sin repuesto o un controlador de máquina que ya nadie fabrica. Frente a un equipo obsoleto hay tres salidas, y se pueden combinar:

1. Reparar a nivel componente para mantenerlo operando hoy.
2. Documentar: respaldar su firmware y su configuración, y levantar sus circuitos, antes de que la próxima falla lo haga imposible.
3. Virtualizar o reemplazar funcionalmente cuando el hardware ya no da más, conservando el programa y la forma de operar que tu equipo conoce.

No todos los equipos necesitan llegar a la tercera etapa. Pero el respaldo de la segunda conviene hacerlo siempre, y mientras el equipo todavía funciona. Si quieres ver más sobre el servicio, revisa Ingeniería inversa de PCB o nuestro artículo sobre la reparación de terminales MAX-3000.