← Todos los casos

IoT Energy

Monitoreo de líneas de alta tensión: de los sensores en campo a una sola plataforma

Un fabricante norteamericano de herrajes para líneas eléctricas necesitaba una plataforma que convirtiera los sensores que instala en conductores de alta tensión en algo sobre lo que un operador de red pueda actuar. Cloudnonic la construyó de punta a punta en 2026: ingesta, capa de datos, API, aplicación web y la infraestructura AWS que hay debajo, con un solo equipo de ingeniería.
366+
Dispositivos de campo registrados en la plataformaAcelerómetros, IMUs, estaciones meteorológicas y más
21+
Líneas de transmisión monitoreadasPara operadores de red en Norteamérica y Europa
13+
Operadores y socios con su propio inquilinoCada uno con sus usuarios, roles, líneas y alertas
5+
Tipos de sensor con su propia cadena de procesamientoDel paquete crudo al indicador de ingeniería
Año2026 – Presente
UbicaciónEstados Unidos
TecnologíasFastAPI · React · PostgreSQL · AWS Lambda · Terraform
AlcanceInfraestructura cloud · Ingeniería de plataforma · Desarrollo full-stack · Datos y analítica

El problema

El cliente fabrica los herrajes que sostienen las líneas de alta tensión: grapas, amortiguadores, separadores. Con los años añadió sensores a ese hardware —acelerómetros y unidades inerciales en el conductor, galgas de deformación por flexión, estaciones meteorológicas en las estructuras— para que los operadores vieran cómo se comporta una línea con viento, hielo y carga.Los sensores funcionaban. Lo que faltaba era la plataforma detrás. Los datos llegaban a los gateways y se quedaban ahí; cada operador era una instalación aparte y no había un solo lugar donde ver la salud de la flota, el estado de una línea o una alerta cuando un conductor empezaba a moverse fuera de sus límites.El encargo era un producto, no un proyecto: multiinquilino desde el primer día, de marca blanca para que el fabricante lo venda con su propia marca, y capaz de absorber paquetes de formas de onda de cientos de dispositivos sin perder una muestra.

Qué construimos

Una aplicación web donde las líneas, los vanos y los activos viven sobre un mapa, con cada dispositivo asignado a un vano y su estado de conectividad visible de un vistazo. Organizaciones, usuarios y roles dan a cada operador su propio inquilino; reglas y alertas avisan a las personas correctas cuando una lectura cruza un umbral.Sobre los datos crudos hay dashboards por familia de sensor: indicadores de acelerómetro con las formas de onda X, Y y Z y sus espectros FFT, análisis de deformación por flexión, movimiento de conductor y amortiguador, lecturas de estación meteorológica y un chequeo de salud de toda la flota. Cada dashboard se filtra por organización, línea, activo y dispositivo, y cada gráfico se exporta.La aplicación está traducida, admite tema propio y se sirve como una single-page app estática detrás de un CDN, así que un operador nuevo es un cambio de configuración y no un despliegue.

Ingesta pensada para ráfagas

Los gateways de campo no transmiten en continuo: despiertan, envían un lote de varios megabytes y vuelven al silencio. Por eso la ruta de ingesta es serverless: una API HTTP y un puente MQTT reciben los lotes, funciones Lambda los validan y los dividen, y colas FIFO entregan cada tipo de sensor a su propia cadena de procesamiento, con cola de errores y reenvío para lo que falle.Los paquetes crudos de formas de onda se archivan al llegar, particionados por hora, de modo que cualquier indicador puede recalcularse después a partir de las muestras originales. Las lecturas procesadas aterrizan en una capa de datos PostgreSQL particionada para series temporales, que la API lee con un rol dedicado.La calibración vive en el catálogo de cada tipo de dispositivo; añadir un modelo de sensor nuevo es una entrada y una cadena de procesamiento, no una plataforma nueva.

Responsables de la infraestructura

Todo corre en AWS y está definido en Terraform: la red, un clúster Fargate para el núcleo en FastAPI, RDS PostgreSQL y Redis en subredes privadas, Cognito con autenticación multifactor, claves KMS, Secrets Manager con roles de base de datos rotados y CloudFront delante de la aplicación.Cada repositorio publica a su propio ritmo con un changelog generado, los entornos están aislados y el cliente aprueba en staging antes de que algo llegue a producción. Desde la salida a producción, la plataforma opera bajo un contrato de mantenimiento con nivel de servicio definido.

Cómo trabajamos con el cliente

El proyecto se gestiona en un repositorio de planificación compartido: modelo de dominio, decisiones de arquitectura, estándares y un backlog que el cliente puede leer. Las decisiones se registran cuando se toman, de modo que quien revise seis meses después encuentre el razonamiento y no solo el código.Cloudnonic es responsable de la ingeniería en los cuatro repositorios —frontend, API central, ingesta e infraestructura—, mientras el cliente es responsable de la dirección de producto, la aceptación y la relación comercial con los operadores que usan la plataforma.

Resultado

  • Cientos de dispositivos de campo en más de veinte líneas de transmisión reportando a una sola plataforma
  • Formas de onda de vibración convertidas en indicadores que un ingeniero de línea lee en segundos
  • Multiinquilino desde el primer día: cada operador ve solo sus líneas, dispositivos y alertas
  • De marca blanca, para que el fabricante venda la plataforma con su propia marca
  • Paquetes crudos archivados por hora y reprocesables en cualquier momento
  • Aprobación en staging por cada release y contrato de mantenimiento tras la salida a producción
CLOUDNONICCLOUDNONICCLOUDNONIC