Software que tiene que hablar con máquinas
Equipos anteriores a la nube, protocolos documentados en un PDF que nadie escaneó, y un dispositivo que responde en once milisegundos o no responde. Este es el trabajo donde no podés iterar hasta que pase: una escritura equivocada para una línea, y el entorno de prueba es una operación andando.
Hablar con un ingenieroCuándo nos llaman
- Una máquina habla un protocolo que el fabricante documentó una vez, en 2009, y la persona que lo entendía ya no está.
- Llega telemetría y nadie confía en ella: las lecturas se pierden cuando el enlace se degrada y nada deja constancia de que se perdieron.
- El dispositivo anda en el banco de pruebas y falla a campo, donde la red es intermitente, la energía no es limpia y la temperatura no es la de una oficina.
- Un comando de control tiene que ser idempotente porque la conexión reintenta, y hoy mandarlo dos veces hace la cosa dos veces.
- La planta tiene un sistema de operaciones y uno administrativo, y se intercambian planillas a mano, una vez por día.
- La plataforma de llamadas corta el audio bajo carga, y los registros describen la aplicación, no el tráfico SIP.
Qué construimos
Telemetría que informa sus propios huecos
Ingesta por MQTT y protocolos industriales donde una lectura faltante queda registrada como faltante, no salteada en silencio. Un dato cuya ausencia es invisible es peor que no tener el dato: alguien va a decidir sobre un promedio que excluyó justo las horas que importaban.
Control de dispositivos que sobrevive a un reintento
Comandos con clave de idempotencia, confirmación, tiempo de espera y un estado definido cuando la respuesta nunca llega. En una red que se corta, «¿se ejecutó?» tiene que poder contestarse sin pedirle al operario que vaya a mirar.
Puentes hacia sistemas sin API
Equipos viejos y software administrativo conectados sin reemplazar ninguno de los dos. Leer un formato propietario, envolver un protocolo serie, o manejar una interfaz que nunca se pensó para automatizarse.
Condiciones de campo diseñadas, no descubiertas
Conectividad intermitente, almacenamiento local mientras no hay enlace, reenvío ordenado al reconectar, desfasaje de reloj entre dispositivos. El banco de pruebas no es el campo, y esa diferencia es de donde salen los incidentes.
Voz y señalización en tiempo real
Asterisk y Kamailio, manejo de tráfico SIP y sistemas de centro de llamadas, instrumentados a nivel de protocolo y no sólo de aplicación.
Proyectos típicos
Conectar un equipo a un sistema que pueda usarlo
Leer de la máquina, normalizar, y entregarlo donde se toman decisiones —con los huecos visibles y el historial intacto—.
Reemplazar una exportación manual entre dos sistemas
La planilla diaria pasa a ser una integración, con conciliación para que una diferencia se detecte en lugar de descubrirse a fin de mes.
Instrumentar una telemetría en la que nadie confía
Encontrar dónde se pierden lecturas, hacer explícita esa pérdida, y darle a operaciones una forma de distinguir un sensor roto de un enlace roto.
Estabilizar una plataforma de voz bajo carga
Instrumentar la capa SIP, encontrar dónde se degrada el audio, y corregir la causa en vez de agregarle capacidad alrededor.
Qué se lleva
- Una integración andando en tu infraestructura, en tu repositorio
- El comportamiento del protocolo escrito, incluidas las partes donde la documentación del fabricante se equivoca
- Instrumentación que distingue una falla del dispositivo de una falla de red
- Pruebas que ejercitan los modos de falla: enlace caído, comando duplicado, relojes desfasados
- Una entrega con la gente que opera el equipo, no sólo con la que escribe código
Preguntas que nos hacen
¿Por qué no hacer que una IA escriba esta integración?
Va a escribir código verosímil para un protocolo que aprendió de documentación pública. El problema es que la máquina que tenés adelante no siempre sigue esa documentación, y la única forma de saberlo es conectarse y mirar. Ese conocimiento no está en internet: está en el equipo y en la gente que lo opera.
¿Trabajan en el lugar?
Cuando el trabajo lo requiere, sí, junto al equipo del cliente. Buena parte de la integración se puede hacer en remoto una vez que hay forma de observar el dispositivo, y conseguir esa observación suele ser la primera tarea.
Tenemos equipos que ya nadie entiende. ¿Se puede trabajar así?
Es el caso habitual. Empezamos mirando qué hace realmente en lugar de qué dice el manual, y escribiendo la diferencia. Muchas veces ese documento vale más que la integración.
¿Con qué protocolos trabajan?
MQTT para telemetría, protocolos serie e industriales donde el equipo lo exija, SIP para voz. Si tu equipo habla algo que no vimos, el primer paso es una investigación corta para caracterizarlo, acotada por separado —y si resulta que no encaja, te lo vamos a decir—.
¿Y si la falla sólo aparece en producción?
Es la mayoría, y por eso la instrumentación va primero. Una falla que no se puede observar no se puede corregir bajo presión, y una planta es mal lugar para estar adivinando.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.