Gerenciamento de dados e arquitetura

O IronFlock oferece uma infraestrutura completa de ingestão e armazenamento de dados de ponta a ponta — do edge à nuvem — projetada para escalabilidade, segurança e propriedade clara dos dados. Seja roteando telemetria de milhares de sensores ou construindo interfaces SCADA em tempo real, a arquitetura de dados do IronFlock garante que suas informações sejam seguras, isoladas e acessíveis.

Roteamento de mensagens e realms seguros

No coração da comunicação em tempo real do IronFlock está um robusto cluster de roteamento de mensagens. Essa infraestrutura de mensageria conecta dispositivos edge diversos dentro do seu projeto entre si, e também à infraestrutura de nuvem do IronFlock.

Para garantir segurança e isolamento rigorosos dos dados, o cluster de roteamento é dividido semanticamente em realms seguros. Realms são sub-redes isoladas — mensagens ficam estritamente confinadas dentro delas, o que significa que dados e comandos nunca deixam nem atravessam realms.

Aplicações rodando nos dispositivos edge podem se comunicar através desses realms de mensagens usando o ironflock-sdk de uma das seguintes maneiras:

• Publish/Subscribe (Pub/Sub): ideal para transmitir continuamente telemetria de sensores ou mudanças de estado.
• Remote Procedure Calls (RPC): perfeito para disparar ações diretamente ou consultar o estado do dispositivo com segurança.

Bancos de dados de projeto provisionados dinamicamente

Para armazenamento persistente e análise histórica, o IronFlock provisiona um banco de dados TimescaleDB físico dedicado para cada projeto.

Este banco de dados do projeto atua como o hub central de coleta de dados:

• Backends de dados de apps: os backends de dados de todos os apps instalados no seu projeto ficam armazenados com segurança dentro deste banco de dados.
• Ingestão direta: quando apps de dispositivos publicam dados com o ironflock-sdk, esses fluxos são ingeridos e organizados diretamente no banco de dados do projeto.

Como o banco de dados do projeto atua como a fonte única de verdade para suas operações, ele desbloqueia recursos avançados:

• Consultas SQL: escreva consultas poderosas diretamente sobre as tabelas históricas brutas.
• Integração com Physical AI: deixe os agentes de IA do IronFlock extraírem, analisarem e consultarem seus dados em linguagem natural.
• Fonte para visualização: o banco de dados do projeto é a fonte de dados definitiva para boards ao vivo, painéis IoT e boards SCADA.

Propriedade de dados e o EU Data Act

O IronFlock é construído sobre um princípio claro: o proprietário do projeto é o proprietário dos dados — não o desenvolvedor do app.

Todos os dados gerados pelos apps — fluxos de telemetria de dispositivos edge, logs de eventos, análises derivadas — são armazenados no banco de dados do projeto, que pertence ao proprietário do projeto. Desenvolvedores de apps escrevem os apps, mas os dados que esses apps produzem enquanto rodam em um projeto são propriedade exclusiva do projeto que os hospeda.

Esse modelo se alinha diretamente aos requisitos do EU Data Act, que dá aos usuários de produtos conectados e serviços relacionados controle total sobre os dados gerados por seus dispositivos. No IronFlock:

• Controle exclusivo. Os proprietários do projeto têm autoridade administrativa total sobre o banco de dados do projeto — podem ler, exportar, excluir e fazer backup de todos os dados nele contidos.
• Sem coleta silenciosa de dados. Desenvolvedores de apps não têm acesso aos dados do projeto a menos que sejam explicitamente convidados a ele. Não existe um pipeline oculto de dados do projeto de volta ao desenvolvedor do app.
• Portabilidade. Todos os dados residem em uma instância padrão do TimescaleDB, então você pode consultá-los com SQL, exportá-los em formatos abertos e migrá-los à vontade — proprietários de projeto nunca ficam presos em vendor lock-in.
• Compartilhamento granular. Proprietários de projeto podem convidar desenvolvedores de apps, parceiros de integração ou outras partes interessadas para o projeto e conceder-lhes permissões de acesso granulares a áreas específicas de dados. Isso permite aproveitar suporte técnico de terceiros, manutenção remota ou serviços especializados de análise sob termos que o proprietário define — e pode revogar — a qualquer momento.

Em resumo: apps produzem dados, mas o proprietário do projeto os possui, controla e compartilha. Este modelo de propriedade é um objetivo de design de primeira classe da plataforma IronFlock, não uma consideração posterior.

Optando por sair: contornando o pipeline de dados do IronFlock

A camada de mensageria e o banco de dados de projeto do IronFlock são o caminho recomendado — fornecem roteamento em tempo real, armazenamento durável, dados prontos para painéis e garantias de propriedade integradas desde o início. No entanto, o IronFlock não obriga os apps a usar esse pipeline.

Apps rodando em dispositivos gerenciados pelo IronFlock são cargas de trabalho de contêiner comuns e mantêm liberdade total de rede e sistema. Se um proprietário de projeto ou desenvolvedor de app preferir uma pilha diferente de manipulação de dados, o app pode:

• Enviar para sistemas externos. Enviar dados diretamente para brokers de terceiros (MQTT, Kafka, AMQP), endpoints de ingestão em nuvem (AWS IoT, Azure IoT Hub, Google Cloud IoT) ou APIs REST / gRPC personalizadas.
• Usar armazenamento alternativo. Gravar em bancos de dados externos (InfluxDB, MongoDB, S3, um TimescaleDB próprio do cliente, etc.) em vez de, ou além do, banco de dados de projeto do IronFlock.
• Fazer ponte com sistemas on-premises. Integrar-se diretamente com sistemas MES, ERP, historians ou SCADA existentes pela rede local, sem passar pela nuvem do IronFlock.
• Misturar e combinar. Publicar um subconjunto de dados no IronFlock para painéis e análises de IA, enquanto transmite dados em fidelidade total para outro lugar.

Essa flexibilidade torna o IronFlock adequado tanto para implantações greenfield, onde os usuários adotam a plataforma de ponta a ponta, quanto para integração em arquiteturas de dados corporativas existentes, onde os destinos dos dados não são negociáveis.

Usando dados em painéis IoT e boards SCADA

Aproveitar os dados visualmente é simples. Ao configurar widgets em um board IoT ou SCADA, quase todas as propriedades do widget — como seu título, valores ou cor — podem ser dinamicamente vinculadas a dados ao vivo do banco de dados do projeto.

Ao editar um widget no Board Studio, há um interruptor de vinculação de dados abaixo do campo de configuração. Ao selecionar uma coluna específica de uma tabela, você estabelece um canal em tempo real para essa propriedade. Assim que novos dados de telemetria chegam ao banco de dados, a propriedade vinculada é automaticamente atualizada em tempo real, sem exigir uma atualização manual da UI.

Nota: para uma explicação detalhada de como conectar propriedades de widgets ao banco de dados, veja a seção de vinculação de dados na documentação dos painéis IoT.