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) e um watchdog de saúde dos componentes contínuo 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
• Vigiar continuamente a saúde dos componentes e o estado da ligação, e gerar eventos de parque para interrupções de produção, conflitos de medição e problemas de ligação
• 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 base de dados própria: Nenhum estado de análise sobrevive a reinícios; os dados não entregues são guardados em buffer no disco local até poderem ser enviados
• 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 vinte 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 dezassete famílias de dispositivos: contadores Janitza, Huawei SmartLogger, controladores Phoenix Contact, inversores Fronius, data loggers Solar-Log, SMA Sunny Central, SMA Power Manager, logger Sungrow, Zebotec, Becker PV-Control (Prometheus), armazenamento em bateria FREQCON, Wattkraft Parkcontrol, conversores de bateria NR Electric, baterias em contentor Linyang/Xieneng relés de proteção SEG HighPROTEC, baterias INTILION scalecube e o controlador de alarme WAGO PFC200. Várias destas — por exemplo, Janitza, Fronius e Wattkraft — não necessitam de quaisquer credenciais; o SMA Power Manager e o logger Sungrow são integrados com credenciais do dispositivo e reportam ainda automaticamente o seu próprio inventário de dispositivos (lista de componentes, números de série, firmware) em vez de o pedir por escrito. O controlador de alarme WAGO é a única exceção ao caminho rápido: nada no fio indica que programa está a correr numa WAGO, pelo que nunca é detetado automaticamente — é adicionado através de Adicionar Registador, escolhendo à mão o adaptador e o respetivo perfil de integrador.
• 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 e o Bluelog são integrados 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 451 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 não mantém nenhuma base de dados própria e não conserva estado de análise entre reinícios:

• 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
• As medições e os relatórios de estado que não podem ser entregues — por exemplo, durante uma falha de internet — são guardados em buffer no disco local e entregues automaticamente assim que a conectividade regressa, para que nada se perca (a resiliência de "Retenção Local / Retoma Automática" descrita na Visão Geral do Mirox-Agent)

O único estado persistente é o buffer local de entrega dos dados ainda não transmitidos, mais o que reside 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
• Vigia em direto a saúde dos componentes e o estado da ligação, abrindo e fechando eventos de parque
• 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 continuamente a potência esperada de cada central e compara a produção real com ela sob a forma de um performance ratio (PR) — uma medida normalizada do grau em que a central converte a luz solar disponível em eletricidade. Em vez de confiar numa única entrada, várias fontes de irradiância independentes são monitorizadas em paralelo, e cada fonte tem a sua própria série de PR — para que um sensor no local com desvio nunca possa distorcer silenciosamente a sua baseline:

• Piranómetro no local — os sensores de irradiação da própria central, disponíveis em quase tempo real
• Satélite — irradiância derivada de satélite para a localização exata da central
• Modelo meteorológico — irradiância modelada a partir de dados meteorológicos

Conversão para o plano dos módulos (POA). Todas as fontes são convertidas em irradiância no plano dos módulos (plane-of-array, POA) — a irradiância que atinge efetivamente os módulos — utilizando a hierarquia de componentes da central (a árvore do parque): cada string transporta a sua própria orientação, um grau de azimute e uma inclinação, configurados pelo operador ou detetados pelo motor de análise. A irradiância horizontal é decomposta nas suas componentes direta e difusa e transposta para cada plano de módulos distinto com física de posição solar padrão da indústria, para que campos de módulos orientados em direções diferentes recebam cada um a sua própria expectativa correta. As expectativas das strings são somadas em curvas de caixa de combinação e de inversor e limitadas à potência nominal AC de cada inversor.

Filtragem de anomalias. Antes de um momento no tempo poder contar para o PR fiável ("limpo"), uma bateria de filtros mascara todas as situações em que um rácio baixo não significaria uma falha:

Um PR por fonte. O performance ratio é então calculado separadamente para cada fonte de irradiância — publicado tanto em bruto (todos os valores calculáveis) como limpo (apenas os valores filtrados e fiáveis) — ao nível do parque e por componente (inversor, caixa de combinação, string). A média móvel do PR limpo também auto-calibra o modelo de potência esperada: a expectativa adapta-se automaticamente à eficiência real de cada central, e é esta mesma expectativa que o watchdog de saúde dos componentes compara com a produção em direto.

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.

Watchdog de Saúde dos Componentes

Para além de recolher dados, o agente avalia continuamente se cada componente produtor — inversores, caixas de combinação (GAKs), strings e sensores de irradiação — está de facto saudável, e converte as suas conclusões em eventos de parque que vê na plataforma. Duas perguntas são feitas ininterruptamente: o componente continua ligado e está a produzir o que deveria?

Monitorização de Conectividade

A conectividade é acompanhada como uma cadeia causal estrita — ligação do parque, dispositivos de rede, data loggers, componentes — e o watchdog diferencia as formas como uma ligação pode falhar, cada uma com o seu próprio evento:

Um alarme por causa raiz. Cada camada só gera eventos enquanto todas as camadas acima dela estiverem saudáveis: uma interrupção em todo o parque gera exatamente um evento ao nível do parque e retém silenciosamente tudo o que está abaixo, um switch morto gera um evento de dispositivo, e só quando o caminho de rede e o logger estão comprovadamente bem é que um componente silencioso se torna uma falha de componente. Todas as transições são estabilizadas (debounce) contra reinícios e interrupções breves, e cada evento fecha automaticamente com a recuperação, indicando a duração da interrupção.

Verificações de Potência e Produção

Em paralelo, o watchdog compara a potência medida de cada componente com o modelo de potência esperada em janelas de avaliação curtas. Um zero ou um défice só conta como evidência quando um filtro ambiental comprova que as condições justificam produção — irradiância sustentada suficiente, sem neve, geada ou nevoeiro, sem curtailment ativamente vinculativo e um caminho de rede saudável — para que uma manhã escura de inverno nunca possa alertar ninguém.

Antes de um alarme abrir, a conclusão é contrainterrogada com testemunhas independentes: os filhos do componente um nível abaixo na hierarquia, o seu próprio contador de energia acumulada e uma auditoria noturna de energia entre progenitor e filhos. O resultado decide que tipo de evento recebe:

• Interrupção de produção — o componente deixou realmente de produzir em condições nas quais deveria produzir
• Conflito de medição — o componente está a produzir, mas a sua própria leitura está errada (uma falha de dados a investigar, nunca contabilizada como produção perdida)
• Sem comunicação — o componente deixou completamente de reportar; a produção é desconhecida e deliberadamente não é contabilizada como perda
• Produção reduzida — o componente está a produzir, mas muito abaixo da sua expectativa modelada (avaliado tanto em direto como numa auditoria noturna do dia completo)

As strings e os sensores de irradiação recebem investigações faseadas em vez de veredictos instantâneos: uma string silenciosa abre primeiro uma investigação de baixa prioridade e só é confirmada como interrupção ou defeito com prova de nível físico — por exemplo, saída zero sob um céu encoberto enquanto as suas strings irmãs produzem — enquanto zeros recorrentes que seguem o percurso do sol são reconhecidos e registados como sombreamento, não como defeito. Um sensor cujo canal de irradiância fica às escuras enquanto os seus outros canais permanecem ativos é reportado como sujidade (limpar a cúpula) em vez de um defeito de hardware.

Sinais Vitais dos Inversores

As verificações acima perguntam se um inversor ainda produz. Um segundo conjunto de verificações pergunta se um inversor que está a produzir caminha em silêncio para um defeito — lendo os sinais que o agente já recolhe de cada inversor mas que nunca usou para o avaliar: temperatura, resistência de isolamento, correntes e tensões por fase e o lado DC (tensão e potência).

Uma via de manutenção própria. Estas constatações nunca chegam como uma avaria: o inversor está a produzir e ainda nada se perde. Abrem como conclusões de manutenção, deliberadamente mantidas à parte dos eventos de avaria acima — os relatos de saúde de rotina de um inversor em produção nunca podem fechar uma constatação de manutenção, e uma constatação de manutenção aberta nunca pode impedir a abertura de um alarme de avaria real. Também nunca mexem num número de produção: um inversor com uma constatação de manutenção continua a contar como produtor onde quer que a plataforma conte componentes em produção, porque está a produzir.

Cada constatação é um evento próprio. Já não existe uma entrada genérica de "Manutenção necessária do inversor": cada constatação é reportada com o seu próprio nome descritivo (Temperatura elevada, Isolamento em degradação, Desequilíbrio de fases, Rendimento decrescente), e cada inversor tem no máximo um evento aberto por constatação. Várias constatações podem, por isso, coexistir na mesma unidade, cada uma com o seu raciocínio, o seu histórico e a sua recuperação, em vez de se fundirem numa única entrada que apenas diz "há aqui algo a ver".

A vigilância vê-se; o veredicto espera. Uma suspeita recente já não desaparece na contabilidade interna do agente. Assim que uma verificação tem motivo para reparar nela, abre um evento de observação de prioridade baixa — "Observação: temperatura elevada", "Observação: desequilíbrio de fases", e assim por diante, com o mesmo ícone da constatação confirmada, num tom mais claro. A lista de atividade da central mostra assim exatamente o que o sistema está a vigiar, e desde quando. O que um evento destes deliberadamente não faz é alterar a saúde de um componente: as observações nunca aparecem nas vistas de saúde — páginas de análise e de produção, chips de componentes, coluna de componentes das estações e as suas contagens — porque aí a plataforma só emite um veredicto quando tem certeza. Uma observação é uma pista, não um veredicto.

Uma única cadeia, da primeira suspeita à constatação. Quando chega a evidência confirmatória, a observação é fechada e no seu lugar abre a constatação confirmada, com prioridade normal, ligada à observação de que nasceu. As duas leem-se como um único histórico — vigiado a partir daquele dia, confirmado neste — e o fecho da observação não anuncia qualquer recuperação, porque nada recuperou: a constatação apenas subiu de etapa. Só a partir da confirmação é que aparece nas vistas de saúde. Se a corroboração nunca chegar, a observação volta simplesmente a fechar quando a condição desaparece, e nunca se afirmou nada.

Os eventos de manutenção nomeiam o componente inversor real e transportam o mesmo raciocínio em linguagem simples que qualquer outro evento, com os números concretos por trás — o excesso medido, a comparação com as unidades vizinhas, o número de dias observados. Por agora são deliberadamente silenciosos: aparecem na lista de eventos da central, mas ficam abaixo de todos os limiares de notificação, enquanto as novas verificações são calibradas com dados reais da frota. Eventos do inversor explica o que abre, confirma e fecha cada uma delas.

Evidência de Causa em Eventos Existentes

Dois dos sinais agora lidos não geram eventos próprios — reforçam os que já existem:

Lado AC ou lado DC? Quando o watchdog abre uma interrupção de produção de um inversor, lê também a tensão DC exatamente nas janelas diurnas em que a unidade não entregou nada. Um barramento DC apagado significa que a causa está do lado DC (strings, aparelhagem DC); um barramento com tensão significa que o gerador está intacto e a falha está na própria unidade ou no seu lado AC. O veredicto — lado AC, lado DC ou indeterminado — entra no raciocínio do evento de avaria e decide que deslocação de serviço faz sequer sentido. A testemunha depende do fabricante: alguns equipamentos — a Huawei entre eles — nunca reportam um barramento apagado, pelo que aí só pode ilibar o lado DC, nunca acusá-lo.

Uma redução causada pela rede não é um defeito. Quando um único inversor mantém a sua tensão AC em 1,10 vezes a tensão nominal ou acima durante uma janela de baixo desempenho, está a limitar a saída de propósito, seguindo a regra volt-watt do código de rede — está a obedecer à rede, não a falhar. Essas janelas são mantidas neutras em vez de contadas como défice, para que uma ligação de rede rígida nunca se acumule num falso defeito.

Com Que Rapidez São Detetados os Eventos?

Estes detetores não vigiam continuamente. Correm uma vez por noite — mais uma vez pouco depois do arranque do agente — e reconstroem a sua evidência a partir do histórico guardado em cada passagem. Uma condição que persiste há semanas é, por isso, encontrada na primeira avaliação assim que a sua verificação estiver armada, e não semanas depois. O que demora é a própria evidência: cada verificação exige um histórico mínimo e uma sequência de persistência antes de dizer o que quer que seja. A primeira coluna abaixo indica o ponto em que a observação abre — prioridade baixa, visível na lista de atividade da central, deliberadamente ausente das vistas de saúde. A segunda indica o que é preciso para que essa observação seja substituída pela constatação oficial, a única que essas vistas mostram.

Uma central acabada de integrar vê, por isso, as suas primeiras observações de temperatura ao fim de cerca de três semanas e as primeiras observações de eficiência ao fim de cerca de dois meses, enquanto a testemunha DC e a ilibação de rede funcionam desde o primeiro dia.

Vale a pena conhecer dois limites:

• Um grupo de comparação precisa de pelo menos seis inversores comparáveis. Todas estas regras são relativas às unidades vizinhas — cada equipamento é avaliado face aos seus irmãos, nunca face a um limiar absoluto, porque os limites absolutos escalam com o tamanho do gerador e com o fabricante. A consequência é deliberada: se todo um grupo de comparação se degradar da mesma forma ao mesmo tempo, esse desvio comum não é detetável por este método.
• A cobertura é por inversor e é ditada pelos dados. Uma verificação só se arma onde o logger do fabricante entrega realmente a métrica — nenhum interruptor de configuração a ativa. Por isso, a cobertura difere de central para central e de fabricante para fabricante.

Eventos Que Se Explicam a Si Próprios

Cada evento transporta um raciocínio em linguagem simples: o que foi medido, em que condições, que evidência independente o corroborou ou contradisse, e o que o resolveria. Os eventos fecham automaticamente com a recuperação comprovada, são reclassificados no próprio local quando a evidência muda de opinião (nunca um vaivém de fechar e reabrir) e respeitam as suas decisões — um evento que fechar permanece fechado até a falha voltar a justificar plenamente um novo. Um único evento-resumo "componentes em baixo" ao nível do parque transporta o verdadeiro alarme do operador: abre quando pelo menos um inversor ou uma caixa de combinação está em baixo há um período sustentado, lista os componentes afetados e notifica apenas na primeira abertura e na recuperação final.

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
• Eventos — como os eventos de parque do watchdog chegam até si