Questions Clients Ask Before Starting

Cuando un cliente industrial se acerca por primera vez, no suele preguntar por el precio ni por los plazos. Las preguntas reales son más específicas y revelan lo que realmente importa en un proyecto de firmware embebido o redes M2M. He recopilado las que más se repiten en las consultas previas.

La primera suele ser: "¿Cómo garantizan que no se pierdan datos en un entorno con interferencias electromagnéticas?" No es una pregunta teórica. En una planta con soldadura por arco o motores de alta potencia, el ruido eléctrico puede corromper tramas Modbus o provocar reinicios inesperados. La respuesta pasa por el diseño del hardware —filtros en las líneas de comunicación, optoacopladores— y por el firmware: buffers circulares con verificación CRC32 y timeouts configurables. No hay una solución única, pero sí un conjunto de prácticas que se ajustan a cada instalación.

Otra pregunta recurrente: "¿Qué pasa si un nodo de campo deja de responder?" En una red M2M con 200 nodos, un fallo individual no debería detener todo el sistema. Por eso implementamos watchdogs externos en cada microcontrolador STM32, y un mecanismo de heartbeat que el concentrador supervisa. Si un nodo no responde tras tres intentos, se marca como fuera de servicio y se genera una alarma en el tablero SCADA. El resto de la red sigue operando sin interrupción.

También preguntan por la latencia. "Necesito que el comando llegue al actuador en menos de 5 milisegundos. ¿Es posible?" Depende de la topología. Si usamos Profibus con un bus de 12 Mbps y un planificador RTOS bien ajustado, sí. Pero si hay que atravesar una pasarela Modbus TCP con cifrado TLS, la latencia sube. En esos casos, lo honesto es decir cuánto se puede garantizar y ofrecer una alternativa: un canal directo sin cifrar para las órdenes críticas y otro cifrado para el monitoreo.

Y una que parece simple pero no lo es: "¿Qué mantenimiento necesita el sistema después de instalado?" El firmware embebido no se actualiza cada mes como una app de celular. Pero sí requiere revisiones periódicas: verificar que los buffers no se desbordan con el tiempo, que los watchdog no se disparan por condiciones nuevas, y que los certificados TLS no han expirado. Dejamos documentado un plan de revisión semestral con procedimientos concretos.

Estas preguntas no son obstáculos. Son señales de que el cliente entiende su entorno y quiere asegurarse de que el sistema funcione ahí, no en un laboratorio. Responder con honestidad y con datos concretos —no con promesas genéricas— es lo que construye una relación técnica sólida.