Coletor de Dados

O Coletor de Dados é o motor central de recolha de dados dentro do Mirox-Agent, recolhendo ativamente informação em tempo real de todos os equipamentos monitorizados na sua central. Liga-se aos seus loggers, inversores, contadores e sistemas de baterias através de uma biblioteca de adaptadores específicos de cada fornecedor, normaliza tudo num vocabulário de métricas consistente e encaminha o resultado para o resto da plataforma — enquanto executa um conjunto crescente de análises no edge (performance ratio, registo de curtailment, baselines de céu limpo, previsão e monitorização de rede) diretamente na central.

Finalidade e Função

O Coletor de Dados serve uma finalidade única e focada: recolher ativamente medições em bruto dos equipamentos e encaminhá-las para processamento. Atua como a ponte entre os diversos equipamentos dos fabricantes e a plataforma Mirox unificada, traduzindo formatos de dados proprietários em métricas normalizadas.

Responsabilidades Centrais:

• Ligar-se a data loggers e dispositivos de monitorização através de adaptadores específicos de cada fornecedor
• Recolher medições em bruto em horários configuráveis
• Transformar dados específicos do fabricante num formato de métrica normalizado
• Detetar e acompanhar automaticamente os componentes da instalação
• Monitorizar a atividade e o estado operacional dos componentes
• Executar análises no edge (potência esperada, performance ratio, curtailment, céu limpo e previsões)
• Inspecionar a rede local da central e auditar o acesso aos dispositivos
• Encaminhar métricas para a Time-Series Database e para o serviço Digital Twin
• Reportar a saúde e o estado operacional dos componentes à IoT Cloud

Esta separação de responsabilidades mantém o Coletor de Dados leve, focado e implementável de forma independente.

Visão Geral da Arquitetura

O Coletor de Dados funciona como um serviço assíncrono e orientado a eventos, onde múltiplas tarefas de recolha de dados são executadas em simultâneo:

Princípios Arquiteturais Fundamentais:

• Sem estado (Stateless): Sem estado persistente entre reinícios
• Baseado em Adaptadores: Um adaptador dedicado e específico de cada fornecedor comunica no protocolo de cada dispositivo
• Auto-recuperável: Recuperação automática de erros com backoff exponencial
• Concorrente: Cada fonte de dados é recolhida de forma independente
• Implementado no Edge: Executado na central ou perto dela, próximo do equipamento que lê

O Sistema de Adaptadores

Conceito

Um adaptador é um módulo conector específico de fornecedor que sabe como comunicar com uma determinada família de dispositivos. Cada adaptador é construído manualmente e desenvolvido por engenharia reversa sobre a própria interface web, API ou base de dados desse dispositivo — não existe um único motor que "fale qualquer protocolo". O sistema de adaptadores é o mecanismo central de extensibilidade: suportar um novo dispositivo significa adicionar um novo adaptador, algo que fazemos a pedido (ver abaixo).

Cada adaptador é um módulo autónomo responsável por:

1. Gestão de Ligação - Estabelecer e manter a comunicação
2. Recolha de Dados - Obter medições utilizando o protocolo apropriado
3. Transformação de Dados - Converter para o formato de métrica normalizado

Todos os adaptadores herdam de uma classe base que fornece monitorização de saúde, lógica de repetição automática, backoff exponencial em caso de falhas, validação de métricas e reporte de estado à plataforma IoT.

Gestão de Saúde

Cada adaptador implementa uma máquina de estados automática:

• INITIALIZING: A iniciar e a estabelecer as primeiras ligações
• HEALTHY: A funcionar normalmente, com recolhas de dados bem-sucedidas
• UNHEALTHY: A registar erros, mas a tentar continuar
• RECONNECTING: A executar ações de recuperação após falhas repetidas
• FROZEN: O dispositivo está a devolver dados obsoletos — os mesmos valores repetem-se, ou não chegou nenhuma leitura nova dentro da janela esperada
• PAUSED: Pausado temporariamente por comando do utilizador; retoma automaticamente quando a pausa expira

O sistema transita automaticamente entre estados, reporta o estado à plataforma e tenta a recuperação sem intervenção manual. O estado FROZEN é o que permite à plataforma distinguir um logger genuinamente em baixo de um que está apenas a repetir um valor bloqueado.

Dispositivos Suportados

O Coletor de Dados vem com cerca de quinze adaptadores específicos de fornecedor, cada um construído para uma determinada família de dispositivos. A lista abaixo reflete o que é suportado atualmente e cresce sempre que um novo dispositivo é integrado.

Criar Novos Adaptadores

Podem ser desenvolvidos novos adaptadores para suportar dispositivos ou protocolos adicionais. O design modular e a funcionalidade da classe base reduzem significativamente o tempo de desenvolvimento.

Compatibilidade com Equipamento Legacy: Podemos criar adaptadores para dispositivos mais antigos que nunca foram especificamente concebidos para exportar dados. Desde que o dispositivo disponibilize os seus dados de alguma forma acessível — seja através de uma API REST, interface web, base de dados, sistema de ficheiros ou qualquer outro mecanismo — conseguimos extrair e integrar esses dados na plataforma.

Recolha de Dados Sem Restrições: Os nossos adaptadores não se limitam aos formatos de exportação de dados predefinidos que os data loggers tipicamente disponibilizam. Conseguimos recolher quaisquer dados que o dispositivo disponibilize, indo além do conjunto padrão de métricas que o logger de um fabricante possa expor. Se um dispositivo tiver informação de diagnóstico adicional, parâmetros avançados ou pontos de dados ocultos acessíveis através da sua interface, conseguimos obtê-los e normalizá-los.

Onboarding Através da Plataforma

Para um subconjunto de dispositivos, pode colocar um logger online a partir da plataforma sem escrever manualmente qualquer configuração. Um assistente de onboarding pede ao agente que faça uma ligação de teste (dry-run) ao dispositivo e transmite os resultados da sondagem em direto, para que veja imediatamente se a ligação funciona antes de a confirmar. Há duas variantes:

• Onboarding sem configuração — o adaptador já detém o conjunto completo de leituras do dispositivo, pelo que o assistente apenas mostra uma pré-visualização ao vivo só de leitura e você guarda. Disponível atualmente para contadores Janitza, Huawei SmartLogger e controladores Phoenix Contact. A Janitza não necessita de quaisquer credenciais.
• Mapeamento interativo para registadores genéricos — alguns loggers expõem valores em bruto arbitrários que a plataforma não consegue interpretar por si só. Para estes, o assistente pede ao agente que enumere todos os valores em bruto que o dispositivo expõe (grupo, nome, unidade, amostra ao vivo), o operador mapeia cada um para uma métrica conhecida, e uma execução de teste (dry run) orientada pelo mapeamento pré-visualiza as métricas exatas que seriam produzidas antes de guardar. O QReader é o primeiro registador genérico suportado desta forma.

Normalização de Métricas

Todos os dados recolhidos são transformados num formato de métrica normalizado definido pela taxonomia de métricas da plataforma. Isto assegura consistência entre todas as fontes de dados e permite um processamento unificado a jusante.

Estrutura da Métrica

Cada métrica segue uma estrutura normalizada compatível com as bases de dados de séries temporais modernas:

Componentes:

• Nome: Identificador de métrica normalizado, a partir de uma taxonomia predefinida
• Valor: Medição numérica em unidades SI base
• Etiquetas (Labels): Pares chave-valor para identificação e agrupamento de componentes
• Timestamp: Preservação opcional do timestamp original do dispositivo

Etiquetas Padrão:

• Tipo de adaptador de origem e número da instância
• Nomes legíveis por humanos
• Identificadores de componente (ID do inversor, número da string, etc.)
• Informação de localização física ou de agrupamento

Convenções de Unidades

Todas as métricas utilizam unidades SI base, independentemente do que o dispositivo do fabricante reporta:

• Potência: Watts (W)
• Energia: Watt-hora (Wh)
• Tensão: Volts (V)
• Corrente: Amperes (A)
• Temperatura: Celsius (°C)
• Irradiância: Watts por metro quadrado (W/m²)

Os adaptadores convertem automaticamente das unidades específicas do fabricante (kW, MWh, etc.) para estes padrões durante a fase de transformação.

Categorias de Métricas

A plataforma define 376 tipos de métricas normalizados organizados em 11 famílias:

As expansões de etiquetas (por string, por fase, por inversor, e assim por diante) multiplicam estas em muito mais séries temporais individuais numa central real. Para a taxonomia e definições completas das métricas, consulte Recolha de Métricas.

Fluxo de Recolha de Dados

Estratégias de Polling

Os adaptadores suportam dois modos de polling:

Baseado em Intervalo (padrão): Executa a cada N segundos após a recolha anterior terminar. Simples e responsivo a durações de recolha variáveis.

Baseado em Tempo Fixo: Executa em intervalos fixos a partir da meia-noite, com offset opcional (por ex., às 00:01, 05:01, 10:01 para intervalos de 5 minutos com offset de 1 minuto). Útil para alinhamento com sistemas externos.

Pipeline de Processamento

Após a recolha, as métricas passam por várias fases de processamento:

Preparação da Métrica: São adicionadas etiquetas de origem, aplicados timestamps e validada a estrutura.

Filtragem: Os filtros configurados podem modificar valores, validar intervalos ou ignorar métricas com base em regras.

Cálculos: Calculadoras automáticas derivam métricas adicionais:

• Potência de radiação solar integrada em energia de irradiação
• Tensão × corrente da string calculada em potência
• Valores de potência integrados em energia ao longo do tempo

Deteção de Componentes: À medida que as métricas fluem, o Coletor de Dados deteta e identifica automaticamente os componentes da instalação. Esta é uma funcionalidade crucial — uma vez que o Coletor de Dados é a camada que recolhe ativamente os dados, sabe inerentemente que componentes existem e estão a fornecer dados. O sistema deteta automaticamente:

• Inversores (a partir das métricas de potência dos inversores)
• Caixas de combinação de strings / GAKs (a partir das métricas GAK)
• Strings individuais (a partir das métricas de tensão/corrente das strings)
• Sensores de irradiação (a partir das métricas de radiação)
• Pontos de ligação à rede (a partir das métricas de energia da rede)

Os componentes detetados são sincronizados com a plataforma IoT para gestão de inventário, criando um registo de equipamento em tempo real e auto-mantido, sem configuração manual.

Deteção de Produção: O sistema monitoriza o estado operacional da central:

• Deteta quando a produção começa com base na irradiância e na potência
• Identifica shutdowns inesperados durante as horas de produção
• Reporta transições de estado para alertas

Agrupamento de Métricas: As métricas são agrupadas em lotes por série temporal para otimizar o desempenho de inserção na base de dados.

Exportação de Dados

As métricas processadas são encaminhadas para dois destinos:

Time-Series Database: As métricas são enviadas em lotes com limitação de débito (rate limiting) e lógica de repetição para armazenamento de longo prazo e consulta histórica.

Webhook do Digital Twin: Uma tarefa de background separada encaminha continuamente os valores de métrica mais recentes para o serviço Digital Twin (um microserviço completamente separado) para análise em tempo real. O Coletor de Dados não tem conhecimento do que o Digital Twin faz com os dados — limita-se a fornecer as métricas. Para informação sobre o processamento do Digital Twin, consulte Digital Twin.

Funcionamento Sem Estado (Stateless)

O Coletor de Dados foi concebido para ser completamente sem estado:

• Sem armazenamento persistente — todo o estado existe apenas em memória
• Pode ser parado e reiniciado sem perda de dados
• Várias instâncias podem ser executadas de forma independente para diferentes parques
• Cada ciclo de polling é independente dos ciclos anteriores
• Resiliente a falhas, sem risco de corromper estado persistente

O único estado persistente existe externamente:

• Ficheiros de configuração (controlados por versão)
• Time-Series Database (sistema externo)
• Registo de componentes da IoT Cloud (sistema externo)

Este design assegura simplicidade operacional, fiabilidade e escalabilidade horizontal fácil.

Separação de Responsabilidades

O Coletor de Dados tem uma responsabilidade estreita e focada que permite uma separação clara dos restantes componentes da plataforma:

Coletor de Dados:

• Recolhe medições em bruto dos equipamentos
• Transforma os dados para o formato padrão
• Deteta e acompanha componentes
• Monitoriza o estado de atividade dos componentes
• Encaminha métricas para outros serviços

Digital Twin: Valida contra modelos físicos e deteta anomalias e perdas

Time-Series Database: Armazena dados históricos, fornece interface de consulta

IoT Cloud: Mantém o registo de componentes, acompanha o estado dos dispositivos, gere o inventário de equipamento

Esta separação permite o desenvolvimento, teste, implementação e escalabilidade independentes de cada componente, garantindo ao mesmo tempo que cada serviço se foca na sua competência central.

Funcionalidades Avançadas

Monitorização Automática de Saúde

Cada adaptador implementa uma máquina de estados que acompanha a saúde operacional, com reporte automático à plataforma e exposição através da API de métricas para monitorização operacional.

Deteção Automática de Componentes

A posição do Coletor de Dados como camada de recolha de dados confere-lhe uma vantagem única: sabe inerentemente que componentes existem numa instalação porque interage diretamente com as métricas que produzem. À medida que as métricas fluem pelo sistema, os componentes são automaticamente detetados a partir das etiquetas das métricas e registados na plataforma IoT.

Processo de Deteção:

1. As métricas chegam com etiquetas identificadoras (ID do inversor, número da string, localização do sensor, etc.)
2. O Coletor de Dados extrai a informação do componente a partir dessas etiquetas
3. Os novos componentes são automaticamente registados na IoT Cloud
4. Os metadados do componente (tipo, identificador, localização) são sincronizados
5. A plataforma mantém um inventário de equipamento atualizado sem introdução manual

Este mecanismo de auto-deteção assegura que a plataforma sabe sempre que equipamento existe na instalação, eliminando a necessidade de configuração manual e reduzindo o tempo de implementação.

Deteção do Estado de Produção

O serviço monitoriza o estado operacional da central e deteta inícios de produção, shutdowns inesperados durante as horas de produção e transições de estado para alertas e análise, reportando apenas quando o estado efetivamente muda. Vigia também a sobreprodução — saída acima do modelo de céu limpo durante um período sustentado — que pode sinalizar um logger a devolver valores bloqueados e, nesse caso, recorrer ao modelo de céu limpo para que o fluxo de dados se mantenha coerente. Isto proporciona consciência operacional em tempo real, para além de apenas medições em bruto.

Métricas Calculadas

Várias calculadoras derivam automaticamente métricas a partir de medições em bruto — radiação solar integrada em energia de irradiação, potência da string calculada a partir da tensão e da corrente, e valores de potência integrados em energia ao longo do tempo. Estes cálculos acontecem de forma transparente, enriquecendo o fluxo de dados sem exigir configuração explícita.

Análise no Edge

Para além da recolha em bruto, o Coletor de Dados executa um conjunto de análises diretamente na central, calculadas a partir do feed de métricas em direto e exportadas como séries temporais representáveis em gráficos, juntamente com os dados em bruto.

Potência Esperada e Performance Ratio

O agente calcula a potência esperada de cada central a partir das suas fontes de irradiância (piranómetro no local, radiação por satélite ou modelo meteorológico) e compara-a com a saída real para derivar o performance ratio (PR) — uma medida normalizada do grau em que a central converte a luz solar disponível em eletricidade. O PR é calculado por dia e tem em conta clipping, geada e filtros de qualidade de dados, de modo a que dias anómalos não distorçam o resultado.

Registo de Curtailment em Direto

Quando uma central produz menos do que poderia, o agente atribui a produção perdida à sua causa: curtailment pelo comercializador (um limite deliberado, motivado pelo mercado) versus curtailment pelo operador de rede. Esta distinção é importante para a contabilização de perdas e o reporte contratual. O curtailment é registado por minuto e emitido tanto como potência instantânea como energia cumulativa. Consulte Deteção de Perdas para ver como o curtailment se enquadra na atribuição global de perdas.

Baseline de Céu Limpo e Previsão

• Baseline de céu limpo: uma curva PV teórica em condições ideais, mantida como registo de longo prazo, dando-lhe uma referência estável para comparar com a saída real.
• Previsão para o dia seguinte (day-ahead): uma previsão de produção PV de horizonte curto derivada de dados meteorológicos, para que possa antecipar a saída do dia seguinte. São baseadas em física meteorológica, não em estimativas estatísticas.

Preenchimento Histórico (Backfill)

Quando uma central é ligada pela primeira vez ou após uma lacuna, o agente pode fazer backfill dos dados históricos — reproduzindo leituras em bruto e voltando a derivar as análises acima para uma janela solicitada, entregando depois o resultado aos pipelines em direto, para que os gráficos estejam completos desde o primeiro dia, em vez de começarem vazios.

Monitorização de Rede

O Coletor de Dados inclui um inspetor de rede local integrado, que é executado em paralelo com a recolha de dados e mapeia a rede no local da central. Deteta dispositivos nos intervalos de rede configurados, varrendo à procura de hosts alcançáveis, lendo a tabela de endereços, identificando fornecedores a partir dos endereços de hardware e sondando dispositivos para obter a sua identidade. Os dispositivos detetados são classificados em relação a uma vasta biblioteca de perfis de equipamento de rede conhecidos, e um passo de identificação de dispositivos por IA ajuda a reconhecer famílias de dispositivos que as regras simples não captam.

Uma vez conhecidos os dispositivos, o inspetor consulta-os quanto à acessibilidade e à saúde (tempo de resposta, estado das interfaces e dos recursos) e reporta os resultados à plataforma. Pode iniciar ou parar um scan de deteção, voltar a verificar um dispositivo individual e rever a rede detetada — consulte Inspetor de Rede Local.

Auditoria de Proxy

Para centrais acessíveis através do Mirox Browser Proxy, o agente audita o acesso humano às interfaces dos dispositivos locais. Agrupa a atividade de cada pessoa em sessões, oculta dados de consulta sensíveis antes de qualquer coisa ser armazenada e pode produzir um resumo gerado por IA do que uma sessão fez. Isto alimenta o registo de auditoria de acessos da plataforma — consulte Registo de Auditoria de Acessos.

Características de Desempenho

Desempenho Típico:

• Frequências de polling: 1-300 segundos por adaptador (configurável)
• Adaptadores concorrentes: mais de 20 a funcionar em simultâneo
• Débito: mais de 10.000 métricas por minuto, de forma sustentada
• Latência: inferior a 100 ms desde a recolha até à inserção na base de dados
• Utilização de recursos: 5-15% de CPU, 100-500 MB de memória em hardware de edge

A arquitetura assíncrona assegura uma elevada concorrência sem bloqueios, permitindo uma recolha eficiente a partir de muitas fontes em simultâneo.

Funcionalidades Relacionadas

• Digital Twin — o motor de análise baseado em física que consome as métricas recolhidas pelo Coletor de Dados
• Visão Geral do Mirox-Agent — como o Coletor de Dados se enquadra no agente edge mais amplo
• Opções de Implementação — compromissos entre implementação no local e na cloud para o agente
• Recolha de Métricas — a taxonomia completa de métricas normalizadas
• Inspetor de Rede Local — a superfície de monitorização da rede no local
• Deteção de Perdas — como o curtailment e outras perdas são atribuídos