IIoT · Instrumentación · Sistemas embebidos
Instrumentamos plantas, fincas y equipos en campo: el sensor, la red que lo une, y la pantalla donde se ve. Diseñamos la placa, el firmware y la plataforma — sin repartir el problema entre tres proveedores.
Y cuando el problema es de los difíciles —interferencia, consumo, latencia— no improvisamos: tenemos investigación publicada sobre exactamente eso.
Con qué venimos ayudando
Si alguno le suena, la conversación empieza más cerca del final.
Casi siempre es el WiFi de la propia planta: los puntos de acceso reasignan canal solos y se meten encima de los sensores. La lista negra del estándar reacciona tarde — cuando bloquea el canal, el interferente ya se movió.
Salto de canal que decide en el propio nodo, ranura a ranura. Medido contra un interferente real.
La radio es lo que gasta, y lo que decide cuánto está encendida es la planificación. Los planificadores de fábrica son estáticos: reservan para el peor caso y encienden de más el resto del tiempo.
Planificación que aprende del tráfico real y reparte las ranuras donde hacen falta, con la energía como objetivo y no como resultado.
Un valor en una pantalla no es histórico. Sin la serie al lado, cada incidencia se investiga desde cero y la experiencia no se acumula.
Telemetría guardada con su política de retención, eventos con número de orden —para saber si falta alguno— y el rastro de quién cambió qué.
La placa es de uno, el firmware de otro y la nube de un tercero. Cuando algo no cuadra, cada uno enseña que lo suyo funciona y el problema se queda sin dueño.
Las tres capas de la misma mano, con un contrato en medio que impide que se contradigan.
Qué hacemos
Lo de arriba lo hace mucha gente. Lo que no es tan común es que quien cablea el tablero sea también quien sabe por qué esa red pierde paquetes los martes por la tarde.
Medida de energía por circuito, agua por pulsos, entradas y salidas aisladas de campo con detección de rotura de hilo y carga abierta. Tableros, protecciones y puesta en marcha firmada.
IEEE 802.15.4 y TSCH, RPL, 6LoWPAN, Thread, LoRaWAN, BLE. Y redes definidas por software para sensores, que es donde empezó nuestro doctorado.
ARM Cortex-M (STM32, CC2538), MSP430, RISC-V y ESP32. Contiki-NG, FreeRTOS, ESP-IDF y desnudo. C por capas, con las dependencias comprobadas por herramienta.
Esquemático, layout multicapa, DRC limpio y gerbers listos para fábrica, con el power tree y el presupuesto de potencia calculados y no estimados.
Telemetría, histórico, administración de flota y multi-sitio. MQTT con tópicos y esquemas que salen de un contrato, no de un documento que alguien recuerda.
Modelos que caben donde no cabe nada: políticas neuronales en punto fijo, con aritmética entera, decidiendo en el propio nodo. Nuestra última, 1,88 KB de ROM y 184 B de RAM sobre un firmware TSCH/IPv6/RPL completo.
Multiobjetivo y con restricciones, con variables enteras y continuas. Recocido simulado, heurísticas a medida y predicción ligera para decidir antes de que haga falta — energía, latencia, fiabilidad y espectro a la vez.
Para protocolos y sistemas, no para demos: planificación de ranuras, salto de canal, selección de padre, movilidad. Jerárquico y federado cuando el problema lo pide.
TLS mutuo, arranque y actualizaciones firmadas, credenciales con custodia y recuperación probada. El valor por defecto nunca concede.
No trabajamos con un solo microcontrolador ni con una sola pila de red. Lo que se repite de un proyecto al siguiente es el método; el silicio se elige por el problema.
Por qué lo podemos prometer
Todo lo de arriba se puede decir sin haberlo hecho nunca. Esto es lo que salió cuando lo medimos, en bancos de pruebas abiertos y con revisión por pares.
Una red de sensores salta de canal para esquivar interferencias, pero la secuencia del estándar no puede seguir a un interferente que se mueve — el WiFi de la propia planta, que reasigna canales solo. Cuando la lista negra reacciona, el interferente ya cambió, y lo que se ve arriba es una red que falla a ratos sin motivo aparente.
Una política neuronal en punto fijo que decide usar o saltar cada ranura, en el propio nodo y con aritmética entera.
Los planificadores de fábrica son estáticos o por reglas: reservan para el peor caso y encienden la radio mucho más de lo necesario el resto del tiempo. Eso son baterías que duran la mitad. Y energía, latencia, fiabilidad y espectro tiran cada uno para un lado.
Predicción ligera de tráfico más optimización multiobjetivo por recocido simulado, distribuida: cada nodo padre decide sus propias ranuras.
Cuánto escucha un nodo, qué tamaño tiene la trama y cómo se reparten las ranuras son tres decisiones acopladas que se toman a mano y se quedan fijas para siempre.
Aprendizaje por refuerzo para cada una — escucha dinámica, tamaño de slotframe y planificación jerárquica para IIoT.
Medido en bancos abiertos —FIT IoT-LAB, FlockLab— y no sólo en simulador. La diferencia entre «funciona» y «funciona en campo» se mide, y es donde se cae la mayoría de lo que se publica.
Caso · FAEC V1
Acceso por NFC, medida de energía en dos fases, agua por pulsos, riego programado, 16 entradas y 16 salidas aisladas. Tres placas, firmware por capas y una plataforma multi-sitio.
Y un principio que ordena todo lo demás: la finca sigue siendo una instalación eléctrica funcional aunque toda la electrónica inteligente deje de existir.
Censo aplicadov 41
Última alarmaFAEC-MET-003
Datos de ejemplo. La demo pública corre contra un simulador, nunca contra una instalación real.
Cómo trabajamos
No es proceso por el proceso. Es lo que hace que el sistema lo pueda mantener alguien que no lo escribió.
Cada requisito lleva un identificador, y cada pieza del sistema se traza hasta uno. Lo que no se puede trazar, no se compra.
Las decisiones que costaron discusión quedan en un documento con lo que se descartó y por qué. Es lo que impide volver a discutirlas en seis meses.
Códigos de error, listas cerradas, rutas y tópicos viven en un contrato del que se genera el código. Firmware y servidor no pueden contradecirse.
Un simulador que habla el contrato de verdad permite escribir y enseñar la interfaz con las placas todavía en el correo.
Las reglas del proyecto las hace cumplir CI, no la memoria de nadie. Si falla, dice el fichero y la línea.
Un protocolo por fases que se marca y se firma mientras se arma el tablero. El dossier as-built es parte de la entrega.
Nada de esto se contrata entero de golpe. Se empieza por un diagnóstico de una o dos semanas que termina en un documento —y el documento es tuyo aunque después no sigamos.
Quién lo hace
Poner una planta en manos de un firmware es una decisión de confianza, y quien la toma tiene derecho a saber quién lo escribió.
Doctor en Ingeniería por la Universidad de Melbourne
Doctorado en redes IoT definidas por software, investigador postdoctoral en la Universidad Técnica de Dinamarca y co-investigador principal del proyecto europeo DAIS. Ingeniero electrónico por la Universidad del Valle, con matrícula de honor.
Antes de la investigación, campo: integración y pruebas de servicio prepago de energía eléctrica dentro de una red inteligente, en Empresas Municipales de Cali.
publicaciones revisadas por pares
3 más en revisión
citas
índice h de 9
socios en el proyecto DAIS
11 países, co-investigador principal
Cifras a septiembre de 2026.
TSCH, RPL, 6LoWPAN y LoRaWAN — planificación, encaminamiento y consumo. Publicado en IEEE Transactions on Mobile Computing, IoT Journal, TCCN, Systems Journal y Sensors Journal.
Protocolos evaluados en bancos abiertos a escala —FIT IoT-LAB— y con medida precisa de tiempos y potencia en FlockLab. La diferencia entre «funciona» y «funciona en campo» es la única que le importa a una planta, y se mide.
Sistemas operativos para IoT en la Universidad Técnica de Dinamarca; diseño de sistemas embebidos y electrónica en la Universidad de Melbourne. Cuatro proyectos de máster y grado dirigidos.
Por dónde empezar
El primer bloque es corto y termina en un documento que puedes llevarte, aunque después no sigamos.
Sabes que hay que instrumentar algo y no cuánto ni con qué.
Vamos, medimos lo que ya hay y escribimos qué se puede saber de esa instalación, con qué sensores, por dónde pasan los cables y qué se rompe primero.
Te llevas
El diagnóstico dice que sí y hay que verlo funcionando.
Una instalación de verdad, con su tablero, su firmware y su panel. No una maqueta: el equipo que se queda puesto.
Te llevas
Un equipo funciona y hay que poner veinte.
Producción, actualización remota con vuelta atrás, gestión de flota e integración con lo que ya usas.
Te llevas
Ya tienes equipo y hardware. Lo que no tienes es que aguante.
Planificación y salto de canal en TSCH, encaminamiento que no mate al nodo del medio, consumo, coexistencia con el wifi de la planta, optimización con restricciones, aprendizaje automático dentro del microcontrolador.
Te llevas
Esto es literalmente el tema de las publicaciones: planificación TSCH, encaminamiento y consumo, con revisión por pares.
Escribe qué hay que instrumentar. Si no es lo nuestro, lo decimos.
Una finca, una planta, una flota de equipos en campo. Si hay que medirlo, controlarlo y que siga funcionando sin red, es nuestro trabajo.