Recolha de Métricas

A Mirox reúne dados de desempenho das suas centrais de energia renovável num único vocabulário de métricas padronizado — a base de todas as capacidades de monitorização, análise, relatórios e previsão da plataforma. Esta página é o catálogo de referência do que é medido e de como as medições estão organizadas.

A taxonomia completa abrange 458 nomes de métricas padronizados distribuídos por doze famílias: produção da central (powerplant), armazenamento de baterias, o sistema de alarme do local, entradas meteorológicas, modelos derivados da meteorologia e várias famílias operacionais que descrevem a própria recolha — monitorização de rede, os agentes, a frota de operadores, a acessibilidade básica de rede e as fontes do scraper. As tabelas abaixo documentam as famílias que irá representar graficamente com mais frequência; as famílias operacionais estão resumidas nas secções Métricas de Rede e Métricas de Agente.

Arquitetura do Data Scraper

No núcleo da recolha de métricas encontra-se o Data Scraper, o componente de edge que recolhe dados de séries temporais das suas centrais. Em vez de um único motor de protocolo genérico, utiliza um adaptador dedicado por família de dispositivos (data loggers, inversores, contadores, sistemas de baterias), cada um construído para a interface desse fornecedor. O Data Scraper pode operar em dois modos de implementação:

Recolha Baseada na Cloud

Quando implementado na cloud:

• Liga-se aos parques solares através de ligações de internet seguras
• Agrega dados de vários locais de forma centralizada
• Gere a ligação e a lógica de repetição
• Otimiza a utilização de largura de banda através de polling inteligente

Recolha Baseada na Edge

Quando implementado na edge (no local):

• Faz interface diretamente com o equipamento local para uma latência mínima
• Opera com buffering local para lidar com falhas de internet
• Realiza validação e filtragem preliminares dos dados
• Sincroniza com a cloud quando há conetividade disponível

A arquitetura de modo duplo garante uma recolha de dados fiável, independentemente das condições de conetividade do local ou da escala do sistema.

Métricas Recolhidas

O sistema de recolha de métricas reúne um conjunto abrangente de medições que proporcionam uma visibilidade completa do desempenho das centrais de energia renovável. As métricas estão agrupadas ao longo de três eixos ortogonais:

• Métricas do Local descrevem o próprio local físico — a sua central, o seu armazenamento de baterias, o seu sistema de alarme e a meteorologia em seu redor.
• Métricas de Rede descrevem a conetividade entre o local e a cloud.
• Métricas de Agente descrevem os próprios agentes de recolha de dados — as fontes do scraper e os serviços de infraestrutura de apoio executados no dispositivo IoT.

Métricas do Local

As métricas do local são as medições brutas de séries temporais recolhidas diretamente do equipamento instalado num local de energia renovável. Estão particionadas por domínio entre a central (inversores PV, ligação à rede, etc.), o sistema de armazenamento de energia em baterias (BESS), o sistema de alarme do local e a meteorologia (previsão e modelada).

Métricas da Central

Métricas de Rede Elétrica

powerplant_grid_power é a interpolação ao minuto de powerplant_power_grid, somada sobre todos os contadores, e powerplant_grid_energy_total o contador de energia da própria plataforma (consciente dos reinícios) integrado a partir dela — a única série monótona de produção do local lida pelas análises (um parque com vários contadores tem vários powerplant_energy_grid_total em bruto). Ambas têm a label boot_time; ler o contador com sum(increase(…)).

Contadores de alimentador FV e bateria

Um parque com uma bateria (ou outro produtor) atrás do mesmo ponto de ligação à rede mede cada alimentador separadamente. A família de rede acima é o ponto de ligação, somado a nível do parque; o alimentador FV publica a família powerplant_pv_* e o da bateria a família powerplant_battery_* — as mesmas grandezas com a mesma convenção de sinal (produção / descarga positivas). Os dois contadores da bateria têm o nome do que a unidade fez: _energy_discharge_total é o que forneceu, _energy_charge_total o que absorveu. Não confundir com as famílias battery_* abaixo, que são a visão do próprio controlador da bateria sobre os níveis box, storage, módulo e célula.

Totais CA da central

Totais CA ao nível da central publicados por registadores que reportam a central como uma única unidade CA (nomenclatura antiga, energy/power antes de ac).

Métricas de Inversor

powerplant_inverter_power / powerplant_inverter_energy_total são os equivalentes ao minuto, somados sobre os inversores, do par de rede acima (uma série de central com label boot_time, não uma por inversor). powerplant_inverter_data_complete é o veredicto por minuto sobre essa soma: 1 quando cada inversor esperado contribuiu, 0 caso contrário, ausente quando nenhum veredicto foi possível. powerplant_inverter_operating_state é o estado operativo padrão da plataforma derivado do código de estado do fabricante (0 desconhecido, 1 em repouso, 2 a produzir, 3 produção limitada, 4 autolimitação, 5 parado por comando, 6 parado por proteção, 7 inacessível, 8 falha — numerado para que max devolva o pior estado), enquanto powerplant_inverter_derating_reason é o código de motivo do próprio fabricante para uma limitação.

Métricas da Caixa de Junção (GAK)

Métricas de String

Métricas de aerogerador

Um aerogerador é um componente plano da central, como um inversor, identificado pela label turbine_id (com turbine_name e turbine_vendor). Os valores são as médias de 10 minutos registadas pelo controlador da turbina. powerplant_turbine_blade_pitch_angle tem uma label blade (A/B/C) e powerplant_turbine_temperature uma label sensor (caixa de velocidades, gerador, transformador, nacelle, …). As séries time_* são segundos por intervalo de 10 minutos em cada estado — disponibilidade medida, não inferida de lacunas. As séries de restrição e perda são a diferença medida entre potência possível e real, atribuída a uma parte pelo código de estado do controlador (grid = operador de rede, marketer = despacho do comercializador / controlador da central, environment = paragens por sombra / morcegos / gelo / meteorologia, command = paragens manuais ou de serviço, fault = alarme da turbina); os seus contadores _energy_total são totais acumulados mantidos pela plataforma.

Séries de informação dos componentes

Os nomes que um operador deu aos componentes, publicados como séries próprias para que os dashboards mostrem os nomes atuais sem que a telemetria os transporte como labels (uma alteração de label bifurcaria uma série). Uma série por componente, indexada exatamente como a sua telemetria (inverter_id; gak_id; string_number, com gak_id apenas atrás de uma caixa de junção; id para um contador de injeção; turbine_id) mais a label de nome (inverter_name, gak_name, string_name, meter_name, turbine_name). O valor é o instante de emissão; a série é renovada em cada sincronização da árvore, pelo que uma renomeação aparece na sincronização seguinte. Nunca grafique, some ou crie alertas sobre estas séries — junte-as à telemetria como mostrado em Criar os seus próprios dashboards Grafana.

Métricas de Controlo

Os setpoints da bateria têm sinal (positivo = descarga, negativo = carga): _external / _external_w é a ordem do comercializador, _local_w a entrada manual do operador, _applied / _applied_w o que o controlador da central realmente comanda ao armazenamento depois de fundir cada ordem e cada limite num único número. Os limites são grandezas positivas: powerplant_max_power_import_by_grid é o limite do operador de rede sobre o que a central pode consumir (100 = sem redução), e os pares battery_max_power_charge/discharge_by_grid os limites do operador de rede sobre o armazenamento dentro de uma central maior, uma via por sentido. Cada dispositivo publica a via que exprime nativamente (percentagem ou watts); a plataforma nunca converte entre elas.

Métricas de Irradiância

Métricas Ambientais

Métricas de Perda

Métricas de Relatório

Métricas do Gémeo Digital

Métricas de estado

O veredicto diário de produção da plataforma por componente: 1 quando o componente produziu normalmente, 0 caso contrário, com o estado detalhado na label status. Não confundir com powerplant_inverter_operating_state, que é o que o próprio dispositivo reporta em cada consulta.

Factos configurados

Publicados uma vez por dia local do parque pela plataforma a partir da configuração da central, nunca medidos: a potência de pico de cada componente e do parque, o limite de inversores do parque e as contagens de componentes. Os componentes ocultos são excluídos e um valor não configurado não escreve nenhuma amostra, pelo que «não configurado» continua distinguível de «configurado como zero». Leia-os como qualquer série, p. ex. last_over_time(powerplant_inverter_peak_power[1d]).

Métricas descontinuadas

Mantidas apenas para dashboards que já as usam — os novos dashboards devem usar powerplant_solar_radiation e powerplant_inverter_frequency.

Métricas de Análise no Edge

O Data Scraper calcula um conjunto de análises diretamente na central e publica-as como séries representáveis em gráficos, juntamente com as medições brutas. Estas são as séries por detrás das funcionalidades de performance ratio, curtailment e liquidação da plataforma. A maioria das famílias existe uma vez por fonte de irradiância — escrita <source> abaixo, uma de pyranometer (sensores no local), satellite (irradiância derivada de satélite para o local) ou weather (irradiância modelada a partir de dados meteorológicos) — para que cada fonte mantenha as suas próprias séries independentes e uma entrada com desvio nunca possa distorcer silenciosamente as restantes.

Irradiância e produção modelada

A irradiância no plano dos módulos vista por cada fonte e a produção teórica (sem curtailment) da central modelada a partir dela. Um conjunto por fonte — 13 séries no total.

Performance ratio

A produção real comparada com a produção modelada — uma via de PR independente por fonte de irradiância, ao nível da central. Consulte Potência Esperada e Performance Ratio para saber como funcionam os filtros.

Potência e energia esperadas

A expectativa calibrada pelo PR — a produção modelada escalada pela eficiência real da central. Esta é a baseline com que o watchdog de saúde dos componentes compara a produção em direto.

Modelo e performance ratio por componente

O análogo ao nível do componente do modelo de toda a central: produção teórica e PR de um único inversor, caixa de junção (GAK) ou string, utilizando a orientação e a potência de pico do próprio componente. Emitido para as fontes weather e pyranometer; as séries transportam as labels de identidade do componente. <component> é um de inverter, gak, string — 12 séries no total, mais o marcador diário de conclusão.

Vias de potência em direto e de previsão

Referências de produção em tempo real e prospetivas.

Curtailment

Produção não realizada atribuída à sua causa — <party> é grid (um setpoint do operador de rede limita a produção) ou marketer (o limite do comercializador direto limita a produção). Cada combinação é emitida como potência instantânea e energia cumulativa, em duas variantes: a série consolidada e uma série live calculada em tempo real. 24 séries no total.

Famílias de liquidação

Séries que sustentam a liquidação e a compensação de curtailment. A família fixed (taxa fixa) implementa o método de liquidação independente da fonte: a referência é a potência de rede média medida nos 15 minutos anteriores ao início do curtailment, congelada para toda a medida — sem necessidade de qualquer entrada de irradiância. A família Mischpreis valoriza a energia de curtailment com o preço misto de quarto de hora do mercado alemão, dando um valor de receita em EUR por intervalo de 15 minutos.

Famílias de liquidação eólica

A eólica onshore liquida a restrição por turbina e soma numa via de parque: os pontos por turbina têm uma label turbine_id, a soma do parque não tem nenhuma — separe-os com turbine_id!~".+", pois um simples sum(...) sobre ambos conta a dobrar. Três métodos partilham a mesma matemática e as mesmas labels: nacelle (o anemómetro da própria turbina alimenta a curva de potência certificada), windref (o padrão — a velocidade do vento de uma turbina de referência ou de um serviço meteorológico) e windfixed (forfetário: a última potência medida sem restrição, congelada durante toda a medida). A injeção Marktprämie é a injeção na rede medida com cada quarto de hora de preço negativo posto a zero, uma cópia por negative_price_rule. <party> é grid ou marketer.

Métricas de Bateria

A família battery_* é o vocabulário de métricas independente do fornecedor para qualquer Sistema de Armazenamento de Energia em Baterias (BESS). Segue uma hierarquia de componentes estrita em que a identificação da instância reside nas labels, e não no nome da métrica:

battery_environment_*       sensores ambiente em torno do BESS
battery_pcs_*               Power Conversion System ligado à rede, à frente da caixa
battery_box_*               uma caixa / contentor BESS — a bateria DC
└── battery_storage_*       um armário / rack dentro da caixa
    └── battery_module_*    um módulo dentro do armário
        └── battery_cell_*  uma célula individual dentro do módulo

A hierarquia da bateria (caixa → armazenamento → módulo → célula) descreve a própria bateria DC. O PCS (battery_pcs_*) é o conversor AC↔DC ligado à rede que fica à frente da caixa — detém o lado AC do BESS mais a sua própria telemetria de conversor, e é identificado por dispositivo pela label pcs. Modelá-lo como componente próprio permite que a bateria e o seu conversor sejam recolhidos como dois dispositivos independentes para o mesmo contentor, sem que as suas séries colidam.

Esta é uma especificação apenas de recolha — os adaptadores publicam os valores brutos exatamente como o fornecedor os expõe, sem agregações, derivações, modificadores _min / _max / _mean, nem indicadores de estado / saúde. Toda a interpretação, agregação e geração de alarmes são responsabilidades a jusante do gémeo digital.

Ambiente

Sensores ambiente em torno do BESS — distinguidos pela label sensor.

Nível de PCS

O Power Conversion System ligado à rede — o conversor AC↔DC à frente da caixa da bateria. Detém o lado AC do BESS (que a bateria DC nunca mede), mais a sua própria leitura do barramento DC, o estado da bateria que retransmite e a telemetria do lado do conversor. Um PCS é um dispositivo distinto, identificado pela label pcs; phase distingue as grandezas AC por fase. Convenção de sinal: positivo = a carregar (rede → bateria); a direção é resolvida a partir dos contadores de energia direcionais, nunca a partir de um bit de estado.

Barramento DC

A visão própria do conversor sobre a ligação DC — o estado DC autoritativo da bateria permanece ao nível da caixa.

Lado AC

Setpoints

Vista só de leitura dos alvos de despacho ativos.

Contadores de energia

Publicados exatamente como os próprios contadores de vida útil do dispositivo os reportam — contadores direcionais separados, pelo que não é necessária nenhuma decisão de sinal.

Estado da bateria retransmitido e limites do conversor

O PCS retransmite um resumo da gestão da bateria e reporta os seus próprios limites operacionais dinâmicos. Onde o sistema de gestão da bateria é recolhido diretamente, battery_box_soc é autoritativo e o valor retransmitido é redundante; num local apenas com PCS, é o único estado de carga disponível.

Nível de Caixa

O topo do lado da bateria — uma caixa / contentor BESS. Label obrigatória: box. Labels opcionais: inverter, phase. As métricas do lado AC só estão presentes quando a conversão AC↔DC reside fisicamente ao nível da caixa.

Fluxo de energia do lado AC

Interface do lado DC

Química & estado

Nível de Armazenamento

Um armário / rack dentro de uma caixa. Labels obrigatórias: box, storage. As métricas AC são raras neste nível — só estão presentes quando a conversão AC↔DC reside fisicamente ao nível do armazenamento.

Fluxo de energia do lado AC

O mesmo vocabulário AC do nível de caixa, sem variantes por fase nem de setpoint.

Interface do lado DC

Química & estado

Nível de Módulo

Um módulo dentro de um armário — a unidade mais pequena que possui o seu próprio chip BMS. Labels obrigatórias: box, storage, module. As métricas AC praticamente nunca estão presentes aqui.

Interface do lado DC

Química & estado

Nível de Célula

A unidade física mais pequena. As células estão ligadas em série dentro de um módulo e partilham a corrente do módulo, pelo que a corrente e a potência por célula não são significativas. Labels obrigatórias: box, storage, module, cell.

Métricas de Previsão Meteorológica

Métricas Meteorológicas Diárias

Métricas Meteorológicas de 15 Minutos

Métricas de Cálculo Meteorológico

Métricas de Modelo Meteorológico

Métricas de Potência do Modelo Meteorológico

Métricas de Potência do Modelo Clearsky

Métricas do Sistema de Alarme

A família alarm_* é a sinalização de alarme do próprio local. Nada nela é medido: cada valor é a posição de um contacto de relé lido através das entradas digitais de um controlador — as saídas de relé de uma central de alarme antintrusão, mais os contactos de supervisão do armário de comunicações a que a central está cablada.

Cada série é um indicador 0/1 normalizado de modo a que 1 signifique sempre «a condição está presente» (porta aberta, alarme disparado, UPS em bateria, disjuntor disparado) e 0 signifique normal, qualquer que seja a polaridade do contacto. A ausência nunca é um zero: um sinal que o dispositivo não serviu neste ciclo não é publicado de todo, e um contacto que o operador declarou não cablado é retido em vez de ficar permanentemente em alarme. A identificação da instância vive na etiqueta alarm — o sistema de alarme a que os sinais pertencem — nunca no nome da métrica.

Todos os sinais exceto alarm_door_open abrem ainda um evento de parque com o mesmo nome enquanto estiverem ativos; uma porta aberta é rotina e fica apenas como série. Consulte Sistema de Alarme para a página que estas séries alimentam.

Métricas de Rede

As métricas de rede descrevem a conetividade entre o dispositivo IoT e a cloud, independentemente de qualquer scraper ou serviço específico.

Métricas de monitorização de rede

As verificações ativas do próprio agente (ICMP, TCP, HTTP) aos dispositivos da rede da central. As séries por dispositivo têm device_ip, device_name, device_type e device_vendor; as verificações TCP acrescentam a porta, as HTTP o endpoint. netmon_park_network_up é uma série de resumo por central.

Métricas SNMP

Lidas de dispositivos com SNMP na rede da central (switches, routers, gateways). As séries de dispositivo têm as mesmas labels que acima; as séries de interface acrescentam if_index, if_name e if_type.

Métricas de Agente

As métricas de agente descrevem os próprios agentes de recolha de dados — tanto o estado por fonte de cada adaptador individual do scraper, como a saúde global e o tráfego dos agentes e da conetividade de apoio. Estas métricas permitem que os seus dashboards correlacionem lacunas de dados com falhas de adaptadores ou de conetividade, em vez de com o equipamento em medição.

Métricas das Fontes do Scraper

O Data Scraper emite um conjunto destas métricas por cada fonte de adaptador ativa. As séries são distinguidas pelas labels source, source_num e name, de forma a que as lacunas de dados possam ser correlacionadas diretamente com a saúde do adaptador, em vez de com o equipamento em medição.

• scraper_health_state: Estado atual do adaptador, codificado como um inteiro: 0 = a inicializar, 1 = saudável, 2 = não saudável, 3 = a reconectar, 4 = congelado (o logger devolve valores obsoletos/bloqueados), 5 = em pausa.
• scraper_cycles_total: Número de ciclos de recolha que o adaptador executou desde o arranque do processo (reinicia ao reiniciar).
• scraper_errors_total: Número de ciclos de recolha que terminaram numa exceção desde o arranque do processo (reinicia ao reiniciar).
• scraper_last_success_timestamp: Segundos da época Unix do último ciclo de recolha bem-sucedido. Apenas emitido após o primeiro sucesso.

Métricas dos Serviços de Agente

Estas métricas acompanham a saúde e a utilização de rede dos serviços de agente individuais (Data Scraper, Digital Twin e serviços de apoio) em execução num dispositivo, para que possa perceber se uma lacuna de dados se deve ao equipamento ou ao próprio agente.

Tráfego de Rede

Saúde do Agente

VPN da Organização

Conetividade e tráfego da ligação VPN ao nível da organização entre a central e a cloud.

VPN Direta

Conetividade e tráfego de cada túnel VPN direto (por central). As séries incluem uma label vpn_name para que cada túnel seja identificado individualmente.

VPN SaaS

Conetividade e tráfego do túnel integrado agente-cloud que transporta o tráfego de acesso remoto da plataforma até à central.

Servidor VPN

Quando o próprio agente atua como servidor VPN para ligações de entrada, estas métricas reportam o estado do servidor e cada peer que se liga. As séries por peer transportam as labels interface, peer_uid e peer_kind, para que os dashboards possam distinguir ligações de utilizadores de ligações entre locais.

• agent_vpn_server_peer_last_handshake: Segundos da época Unix do último handshake concluído do peer; 0 significa que o peer nunca concluiu nenhum. Para peers OpenVPN, que não expõem um timestamp por handshake, o momento desde o qual o peer está ligado é publicado sob a mesma métrica, para que uma única consulta cubra ambos os protocolos.

Métricas do Operador

A frota de operadores envia métricas de infraestrutura para a monitorização de túneis VPN e para a saúde do operador, permitindo-lhe ver o estado da conetividade do lado da cloud que liga as suas centrais à plataforma.

Métricas de Túnel VPN

• operator_vpn_connected: 1 se o túnel VPN tiver um handshake recente (nos últimos 3 minutos), 0 caso contrário
• operator_vpn_rx_bytes: Total de bytes recebidos através do túnel VPN (contador)
• operator_vpn_tx_bytes: Total de bytes transmitidos através do túnel VPN (contador)

Métricas de Saúde do Operador

• operator_health: 1 se o operador tiver uma ligação ativa à cloud, 0 se estiver em estado de timeout
• operator_uptime_seconds: Segundos desde o arranque do processo do operador
• operator_cloud_response_age_seconds: Segundos desde a última resposta bem-sucedida da API da cloud
• operator_cloud_liveness_age_seconds: Segundos desde a última confirmação de que o processo na nuvem está vivo (endpoint de saúde) — mantém-se atualizado mesmo enquanto a API principal devolve erros, sendo por isso a salvaguarda

Processo de Recolha

O processo de recolha de dados segue um fluxo de trabalho estruturado:

1. Descoberta: O sistema identifica todos os componentes a monitorizar com base na configuração do parque
2. Agendamento: Os agendamentos de recolha são otimizados com base na importância e variabilidade das métricas
3. Obtenção: O data scraper liga-se aos dispositivos e recolhe as medições brutas
4. Validação: Os dados recolhidos são validados quanto à exatidão e ao cumprimento dos intervalos
5. Enriquecimento: É adicionada informação contextual (timestamps, identificadores de componentes, etc.)
6. Transmissão: Os dados são transmitidos de forma segura para a Base de Dados de Séries Temporais
7. Verificação: O sistema confirma o armazenamento bem-sucedido e a disponibilidade

Pontos de Integração

O sistema de recolha de métricas integra-se com outros componentes da plataforma:

• Dashboard de Monitorização: Proporciona a visualização de dados em tempo real
• Deteção de Eventos: Fornece dados para a identificação de anomalias e problemas
• Motor de Relatórios: Fornece medições para os relatórios de desempenho
• Sistema de Análise: Alimenta os dados em cálculos avançados de desempenho
• Módulo de Previsão: Fornece dados históricos para os modelos de previsão

Segurança dos Dados

Todas as métricas recolhidas são protegidas através de várias medidas de segurança:

• Encriptação: Os dados são encriptados tanto em trânsito como em repouso
• Controlo de Acesso: As métricas estão sujeitas ao mesmo modelo de permissões que os restantes recursos
• Auditoria: Todos os acessos aos dados das métricas são registados para fins de conformidade
• Anonimização: Os dados agregados utilizados para benchmarking são anonimizados

Extensibilidade

O sistema de recolha de métricas foi concebido para a extensibilidade:

• Novas Famílias de Dispositivos: Construímos um adaptador dedicado para cada família de dispositivos mediante pedido — se a sua central utilizar um logger, inversor, contador ou sistema de baterias que ainda não suportamos, pode ser adicionado sem recorrer a uma solução genérica universal.
• Métricas Personalizadas: Suporte para medições específicas do local ou do equipamento.
• Fontes de Dados Externas: As séries de meteorologia e de irradiância de referência são integradas em conjunto com os dados da sua central para alimentar a análise e a previsão.

Funcionalidades Relacionadas

• Data Scraper — o agente de edge que recolhe estas métricas com um adaptador dedicado por família de dispositivos
• Digital Twin — transforma as métricas brutas em produção simulada, rácio de desempenho e deteção de perdas
• API de Exportação de Métricas — consulte e descarregue estas métricas para utilização própria
• MiroxQL — o formato de consulta para acesso programático e bruto às métricas recolhidas
• Monitorização em Tempo Real — dashboards ao vivo construídos sobre as métricas recolhidas