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 para todos os apps instalados no projeto:

• 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. Instale um segundo app e ele acrescenta suas próprias tabelas ao lado das do primeiro — um projeto que roda vários apps acaba com todos os dados deles reunidos em um só lugar, consultáveis em conjunto.
• 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.
• Acesso de leitura, mediante consentimento: por padrão, um app lê apenas os seus próprios dados, mas, com a sua aprovação, um app também pode ler os dados de outro app no mesmo projeto — para que os apps possam se apoiar nas leituras uns dos outros. Você controla e revoga esse compartilhamento (veja abaixo).

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.

Transformações personalizadas

As tabelas que um app grava raramente têm exatamente o formato da pergunta que você quer fazer. A eficiência geral do equipamento combina disponibilidade, desempenho e qualidade; um relatório de turno precisa de intervalos de uma hora; comparar duas máquinas significa juntar as tabelas de dois apps diferentes. Uma transformação personalizada responde a uma pergunta dessas de uma vez por todas: é uma consulta SQL, salva sob um nome, que a partir daí se comporta como qualquer outra tabela do projeto.

Criar uma não é tarefa do desenvolvedor do app. Qualquer membro do projeto com o privilégio de Acesso a dados — o mesmo que abre o console de consultas SQL — pode salvar uma transformação, e o assistente de IA do IronFlock pode criar uma quando solicitado, sempre que um board precisar de um número que nenhuma tabela bruta contém. As transformações ficam fora de todos os apps, no espaço IronFlock do próprio projeto, de modo que uma única transformação pode ler as tabelas de todos os apps instalados no projeto.

• Escreva a consulta uma única vez. Desenvolva-a no console de consultas da visualização de dados do projeto e escolha Salvar como transformação, ou vá direto para a aba Transformações que fica ali. As tabelas de origem são referenciadas como databackend_<key>.<table> — os nomes que a árvore de dados mostra ao lado de cada app.
• Escolha como ela é calculada. Uma transformação materializada armazena o seu resultado e o recalcula em uma programação que você define, no máximo uma vez por minuto. Uma view simples é calculada a cada leitura: sempre atual, mas apenas tão rápida quanto a sua consulta.
• Descreva o que ela retorna. A transformação carrega uma descrição, e cada coluna do resultado carrega o seu próprio nome de exibição e a sua própria descrição. Eles ficam armazenados junto com a transformação no banco de dados, e é isso que o editor de widgets mostra e que o assistente de IA lê — uma transformação bem descrita é uma que o assistente ainda consegue usar corretamente meses depois.
• Vincule-a como uma tabela. A transformação aparece no seletor de dados do editor de widgets em IronFlock, ao lado das tabelas de cada app, e alimenta o mesmo canal ao vivo: quando ela é atualizada, os boards vinculados a ela são atualizados.

Escrevendo uma transformação que se comporta bem

Uma transformação retorna exatamente as linhas que o seu próprio SQL seleciona. As janelas de tempo dos widgets, os filtros de calendário e o modo latest se aplicam a tabelas e são ignorados aqui, o que torna três hábitos dignos de adoção:

• Limite o intervalo de tempo dentro da consulta, por exemplo WHERE tsp > now() - interval '7 days'. Cada leitura também é limitada a 3000 linhas, então agregue na consulta em vez de selecionar o histórico bruto.
• Ordene uma série temporal da mais recente para a mais antiga (ORDER BY <coluna de timestamp> DESC). Os widgets então recebem as linhas da mais antiga para a mais recente e, onde houver um limite de linhas, ele mantém as mais recentes.
• Selecione todas as colunas que você quiser plotar ou pelas quais quiser filtrar. Uma transformação não tem colunas ocultas de timestamp ou de dispositivo: um widget só pode usar o que a consulta de fato retorna.

Se uma transformação parar de funcionar — um app que ela lê foi desinstalado, uma coluna que ela usava desapareceu — a aba Transformações mostra o motivo, e as demais transformações continuam rodando. Ler uma transformação em um board segue as mesmas regras de acesso dos dados de qualquer app; Acesso a dados governa apenas quem pode criar uma.

Desenvolvedores de apps podem, em vez disso, entregar transformações junto com um app, declaradas no seu esquema de dados — veja Tabelas de Transformação. Os dois tipos são lidos da mesma forma.

O armazenamento de arquivos do projeto

Nem tudo que um app produz cabe em uma tabela. Além do banco de dados do projeto, todo projeto recebe um armazenamento de arquivos privado para objetos — frames de câmera, relatórios em PDF, imagens de firmware, clipes de áudio, exportações — regido exatamente pelos mesmos princípios do banco de dados.

• Todo app recebe armazenamento automaticamente. Quando um app é instalado, o IronFlock provisiona uma área de armazenamento privada para ele no armazenamento de arquivos do projeto, assim como provisiona as tabelas de banco de dados do app. Vários apps reúnem seus arquivos no único armazenamento do projeto, com os objetos de cada app claramente separados dos demais.
• As mesmas garantias de propriedade se aplicam. Os arquivos pertencem ao proprietário do projeto, não ao desenvolvedor do app. Você pode navegá-los, baixá-los, limitá-los e excluí-los, e o desenvolvedor de um app não consegue ver os arquivos que ele coleta enquanto roda no seu projeto.
• Os arquivos se vinculam diretamente aos seus dados. Um objeto armazenado carrega uma URL permanente e com controle de acesso que um app pode gravar em uma coluna do banco de dados — assim, um widget de painel renderiza a imagem ou o documento sem trabalho adicional, e revogar o acesso de um usuário ao projeto também revoga a capacidade dele de buscar os arquivos.
• Você controla o orçamento. As configurações de armazenamento de cada app mostram quanto ele está usando e permitem definir um limite de armazenamento, esvaziar uma tabela ou excluir todos os arquivos de um app. E para ferramentas fora da plataforma — um analista com DuckDB, um backup noturno — você pode emitir credenciais S3 somente leitura restritas aos arquivos de um único app.

O armazenamento de arquivos pode ser navegado ao lado das tabelas: a visualização de dados do projeto mostra uma entrada Arquivos para cada app, listando cada objeto armazenado com seu tamanho, tipo e data. Para os detalhes do lado do desenvolvedor — declarar armazenamento, namespaces, retenção e as chamadas do SDK — veja Armazenamento de Arquivos.

Compartilhamento de dados entre apps

Apps no mesmo projeto são isolados por padrão: cada um lê e grava apenas as suas próprias tabelas e os seus próprios arquivos. Esse é o ponto de partida seguro — um app que você instalou para medir energia não tem por que ler as fotos de inspeção de outro app, a menos que você decida que ele deve.

Mas muitas vezes os apps devem trabalhar juntos — um app de análise lendo o histórico de um app de monitoramento, um app de relatórios puxando fotos de um app de qualidade. O IronFlock torna isso possível por meio de uma única decisão de consentimento que você controla, nas configurações do app consumidor:

• Você aprova exatamente quais provedores um app pode ler, e vê o motivo que o app apresenta para querer acesso. Nada é compartilhado sem a sua aprovação explícita.
• Uma única concessão cobre as duas metades do hub — as tabelas compartilhadas do app provedor e os seus arquivos compartilhados. Você não gerencia as permissões de banco de dados e de arquivos separadamente.
• O acesso é somente leitura. Um app consumidor pode ver os dados de outro app, mas nunca alterá-los ou excluí-los.
• Você pode revogar a qualquer momento, e o acesso é interrompido imediatamente.

O que é sequer oferecido para compartilhamento é decisão do desenvolvedor do app, tomada por tabela e por namespace de arquivos — alguns dados um app mantém estritamente internos, e esses nunca aparecem como algo que você poderia conceder. Do que é compartilhável, você decide se de fato o compartilha. A mecânica do lado do desenvolvedor está documentada em Consumindo Dados de Outros Apps.

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.