Gestión de Datos y Arquitectura

IronFlock proporciona una infraestructura completa y end-to-end de recolección y almacenamiento de datos, diseñada para escalabilidad, seguridad y una propiedad de datos clara — desde el edge hasta la nube. Ya sea que enrute telemetría de miles de sensores o construya interfaces SCADA en tiempo real, la arquitectura de datos de IronFlock asegura información segura, aislada y accesible.

Enrutamiento de mensajes y realms seguros

El núcleo de la comunicación en tiempo real de IronFlock es un robusto clúster de enrutamiento de mensajes. Esta infraestructura conecta diversos dispositivos edge dentro de un proyecto entre sí y con la infraestructura cloud de IronFlock.

Para garantizar aislamiento y seguridad estrictos, el clúster se particiona semánticamente en realms seguros. Un realm es una sub-red aislada en la que los mensajes están estrictamente contenidos; los datos y comandos no pueden cruzar de un realm a otro.

Las aplicaciones que corren en sus dispositivos edge usan el ironflock-sdk para comunicarse a través de estos realms:

• Publish/Subscribe (Pub/Sub): Ideal para transmitir continuamente telemetría de sensores o cambios de estado.
• Remote Procedure Calls (RPC): Perfecto para disparar acciones directas o consultar de forma segura el estado de un dispositivo.

Bases de datos de proyecto provisionadas dinámicamente

Para almacenamiento persistente y análisis histórico, IronFlock provisiona una base de datos TimescaleDB dedicada y física para cada proyecto.

Esta base de datos del proyecto sirve como el punto central de recolección de datos para cada app instalada en el proyecto:

• Backends de datos de las apps: Todos los backends de datos de las apps instaladas en su proyecto están alojados de forma segura en esta base de datos. Instale una segunda app y esta añade sus propias tablas junto a las de la primera — un proyecto que ejecuta varias apps termina con todos sus datos recolectados en un mismo lugar, consultables en conjunto.
• Ingesta directa: Cuando las apps de dispositivo publican datos con el ironflock-sdk, ese flujo se recibe y organiza directamente en la base de datos del proyecto.
• Acceso de lectura, con consentimiento: Por defecto, una app solo lee sus propios datos, pero con su aprobación una app también puede leer los datos de otra app del mismo proyecto — de modo que las apps pueden construir sobre las lecturas de las demás. Usted controla y revoca esa compartición (vea más abajo).

Al ser la única fuente de verdad para sus operaciones, la base de datos del proyecto habilita capacidades avanzadas:

• Consultas SQL: Escriba consultas potentes directamente contra sus tablas históricas.
• Integración con Physical AI: Deje que el agente de IA de IronFlock extraiga, analice y consulte sus datos usando lenguaje natural.
• Fuente para visualizaciones: La base de datos es la fuente definitiva para live boards, dashboards IoT y boards SCADA.

Transformaciones personalizadas

Las tablas que escribe una app rara vez tienen exactamente la forma de la pregunta que usted quiere hacer. La eficiencia general de los equipos combina disponibilidad, rendimiento y calidad; un informe de turno necesita intervalos horarios; comparar dos máquinas implica unir las tablas de dos apps distintas. Una transformación personalizada responde una pregunta así de una vez por todas: es una consulta SQL, guardada con un nombre, que a partir de entonces se comporta como cualquier otra tabla del proyecto.

Crearla no es tarea del desarrollador de la app. Cualquier miembro del proyecto con el privilegio de Acceso a datos — el mismo que abre la consola de consultas SQL — puede guardar una transformación, y el asistente de IA de IronFlock puede crear una a petición cuando un board necesita una cifra que ninguna tabla en bruto contiene. Las transformaciones viven fuera de toda app, en el espacio IronFlock propio del proyecto, de modo que una sola transformación puede leer a través de las tablas de todas las apps instaladas en el proyecto.

• Escriba la consulta una sola vez. Desarróllela en la consola de consultas de la vista de datos del proyecto y elija Guardar como transformación, o vaya directamente a la pestaña Transformaciones que hay allí. Las tablas de origen se referencian como databackend_<key>.<table> — los nombres que el árbol de datos muestra junto a cada app.
• Elija cómo se calcula. Una transformación materializada almacena su resultado y lo recalcula según una planificación que usted fija, como máximo una vez por minuto. Una vista simple se calcula en cada lectura: siempre actual, pero solo tan rápida como su consulta.
• Describa lo que devuelve. La transformación lleva una descripción, y cada columna del resultado lleva su propio nombre para mostrar y su propia descripción. Se almacenan junto a la transformación en la base de datos, que es lo que muestra el editor de widgets y lo que lee el asistente de IA — una transformación bien descrita es una que el asistente todavía puede usar correctamente meses después.
• Enlácela como una tabla. La transformación aparece en el selector de datos del editor de widgets bajo IronFlock, junto a las tablas de cada app, y alimenta el mismo canal en vivo: cuando se refresca, los boards enlazados a ella se refrescan.

Escribir una transformación que se comporte bien

Una transformación devuelve exactamente las filas que selecciona su propio SQL. Las ventanas de tiempo de los widgets, los filtros de calendario y el modo latest se aplican a las tablas y aquí se ignoran, lo que hace que merezca la pena adoptar tres hábitos:

• Acote el rango temporal dentro de la consulta, por ejemplo WHERE tsp > now() - interval '7 days'. Además, cada lectura está limitada a 3000 filas, así que agregue en la consulta en lugar de seleccionar historial en bruto.
• Ordene una serie temporal de más nueva a más antigua (ORDER BY <columna de marca temporal> DESC). Los widgets reciben entonces las filas de la más antigua a la más nueva, y cuando se aplica un límite de filas este conserva las más nuevas.
• Seleccione todas las columnas que quiera graficar o por las que quiera filtrar. Una transformación no tiene columnas ocultas de marca temporal ni de dispositivo: un widget solo puede usar lo que la consulta devuelve realmente.

Si una transformación deja de funcionar — se desinstaló una app que leía, desapareció una columna que usaba — la pestaña Transformaciones muestra el motivo y las demás transformaciones siguen funcionando. Leer una transformación en un board sigue las mismas reglas de acceso que los datos de cualquier app; Acceso a datos rige únicamente quién puede escribir una.

Los desarrolladores de apps pueden, en su lugar, incluir transformaciones con una app, declaradas en su esquema de datos — vea Tablas de transformación. Ambos tipos se leen igual.

El almacén de archivos del proyecto

No todo lo que produce una app cabe en una tabla. Junto a la base de datos del proyecto, cada proyecto recibe un almacén de archivos privado para objetos — fotogramas de cámara, informes PDF, imágenes de firmware, clips de audio, exportaciones — regido exactamente por los mismos principios que la base de datos.

• Cada app recibe almacenamiento automáticamente. Cuando se instala una app, IronFlock le provisiona un área de almacenamiento privada en el almacén de archivos del proyecto, igual que provisiona las tablas de base de datos de la app. Varias apps agrupan sus archivos en el único almacén del proyecto, manteniendo los objetos de cada app claramente separados de los de las demás.
• Se aplican las mismas garantías de propiedad. Los archivos pertenecen al propietario del proyecto, no al desarrollador de la app. Puede explorarlos, descargarlos, limitarlos y borrarlos, y el desarrollador de una app no puede ver los archivos que esta recolecta mientras se ejecuta en su proyecto.
• Los archivos se enlazan directamente con sus datos. Un objeto almacenado lleva una URL permanente y con control de acceso que una app puede escribir en una columna de la base de datos — de modo que un widget de dashboard renderiza la imagen o el documento sin trabajo adicional, y revocar el acceso de un usuario al proyecto revoca también su capacidad de obtener los archivos.
• Usted gobierna el presupuesto. Los ajustes de almacenamiento de cada app muestran cuánto está usando y le permiten fijar un límite de almacenamiento, vaciar una tabla o borrar todos los archivos de una app. Y para herramientas fuera de la plataforma — un analista con DuckDB, un respaldo nocturno — puede emitir credenciales S3 de solo lectura acotadas a los archivos de una sola app.

El almacén de archivos se puede explorar junto a las tablas: la vista de datos del proyecto muestra una entrada de Archivos para cada app, que lista cada objeto almacenado con su tamaño, tipo y fecha. Para los detalles del lado del desarrollador — declarar almacenamiento, espacios de nombres, retención y las llamadas del SDK — consulte Almacenamiento de Archivos.

Compartir datos entre apps

Las apps de un mismo proyecto están aisladas por defecto: cada una lee y escribe solo sus propias tablas y sus propios archivos. Ese es el punto de partida seguro — una app que instaló para medir energía no tiene por qué leer las fotos de inspección de otra app a menos que usted decida que así sea.

Pero a menudo las apps deberían trabajar juntas — una app de analítica leyendo el historial de una app de monitoreo, una app de informes tomando fotos de una app de calidad. IronFlock lo hace posible mediante una única decisión de consentimiento que usted controla, en los ajustes de la app consumidora:

• Usted aprueba exactamente qué proveedores puede leer una app, y ve el motivo que la app aduce para querer el acceso. Nada se comparte sin su aprobación explícita.
• Una única concesión cubre ambas mitades del hub — las tablas compartidas de la app proveedora y sus archivos compartidos. No gestiona los permisos de base de datos y de archivos por separado.
• El acceso es de solo lectura. Una app consumidora puede ver los datos de otra app pero nunca cambiarlos ni borrarlos.
• Puede revocar en cualquier momento, y el acceso se detiene de inmediato.

Lo que siquiera se ofrece para compartir es decisión del desarrollador de la app, tomada por tabla y por espacio de nombres de archivos — algunos datos una app los mantiene estrictamente internos, y eso nunca aparece como algo que usted pudiera conceder. De lo que es compartible, usted decide si realmente compartirlo. Los mecanismos del lado del desarrollador están documentados en Consumir Datos de Otras Apps.

Propiedad de los datos y el Reglamento de Datos de la UE

IronFlock se basa en un principio claro: el propietario del proyecto es el propietario de los datos — no el desarrollador de la app.

Todos los datos producidos por las apps — flujos de telemetría de dispositivos edge, logs de eventos o analítica derivada — se almacenan en la base de datos del proyecto, que pertenece al propietario del proyecto. El desarrollador escribe la app, pero los datos que esa app genera dentro de un proyecto son propiedad exclusiva del proyecto que la aloja.

Este modelo se alinea directamente con los requisitos del Reglamento de Datos de la UE (EU Data Act), que otorga a los usuarios de productos conectados y servicios relacionados el control total sobre los datos que generan sus dispositivos. En IronFlock:

• Control exclusivo. El propietario del proyecto tiene control administrativo completo sobre la base de datos del proyecto — puede leer, exportar, borrar y respaldar todos los datos.
• Sin recolección silenciosa. Los desarrolladores de apps no pueden acceder a los datos de un proyecto sin ser invitados explícitamente. No hay tuberías ocultas desde los proyectos hacia los desarrolladores.
• Portabilidad. Como todos los datos viven en una instancia estándar de TimescaleDB, pueden consultarse con SQL, exportarse en formatos abiertos y migrarse cuando se desee — sin vendor lock-in.
• Compartición granular. El propietario puede invitar a desarrolladores, partners de integración u otros interesados al proyecto y conceder permisos finos de acceso a áreas de datos específicas. Esto facilita aprovechar soporte técnico de terceros, mantenimiento remoto o analítica especializada — en los términos que el propietario define y puede revocar en cualquier momento.

En resumen: las apps producen datos, pero el propietario del proyecto los posee, controla y comparte. Este modelo de propiedad es un objetivo de diseño de primer nivel de la plataforma IronFlock, no algo añadido después.

Opción de exclusión: evitar la pipeline de datos de IronFlock

La capa de mensajería y la base de datos de proyecto son el camino recomendado — ofrecen enrutamiento en tiempo real, almacenamiento duradero, datos listos para dashboards y garantías de propiedad integradas. Sin embargo, IronFlock no obliga a las apps a usar esta pipeline.

Las apps que corren en dispositivos gestionados por IronFlock son workloads de contenedor normales y conservan plena libertad de red y sistema. Si un propietario o un desarrollador prefiere otro stack de datos, la app puede:

• Enviar a sistemas externos. Mandar datos directamente a brokers de terceros (MQTT, Kafka, AMQP), endpoints de ingesta en la nube (AWS IoT, Azure IoT Hub, Google Cloud IoT) o APIs REST / gRPC propias.
• Usar almacenamiento alternativo. Escribir en una base externa (InfluxDB, MongoDB, S3, una TimescaleDB propia, etc.), en lugar o además de la base del proyecto IronFlock.
• Puentear a sistemas on-premises. Integrarse con sistemas MES, ERP, historian o SCADA existentes por la red local, sin tocar la nube de IronFlock.
• Combinar. Publicar un subconjunto de datos en IronFlock para dashboards y análisis de IA, y transmitir los datos completos a otro destino.

Esta flexibilidad hace a IronFlock adecuado tanto para implementaciones greenfield que abrazan la plataforma de extremo a extremo como para integraciones con arquitecturas de datos empresariales existentes donde el destino de los datos no es negociable.

Uso de datos en dashboards IoT y boards SCADA

Llevar sus datos a una visualización es sencillo. Al configurar un widget en su board IoT o SCADA, casi todas las propiedades (p. ej., títulos, valores, colores) pueden enlazarse dinámicamente a datos en vivo de la base del proyecto.

Al editar un widget en el Board Studio, encontrará un interruptor de enlace de datos bajo los campos de configuración. Seleccionar una columna específica de una tabla establece un canal en tiempo real para esa propiedad. Conforme llegan nuevos datos a la base de datos, las propiedades enlazadas se actualizan automáticamente en tiempo real, sin refrescar nada a mano.

Nota: Para profundizar en cómo conectar propiedades de widgets a su base de datos, consulte la sección detallada de enlace de datos en la documentación de Dashboards IoT.