O que os dados de campo escondem: sinais ocultos de falha e manutenção preditiva

Um anemômetro LiDAR registrou 3,2 m/s de forma ininterrupta por 72 horas. O valor era plausível para o sítio — dentro da faixa histórica, sem flag de limite físico, sem alerta de comunicação. A série temporal chegou ao sistema, foi marcada como "disponível" e integrou o cálculo de disponibilidade com 100% de aproveitamento. Só na análise mensal — quando o engenheiro plotou a rosa dos ventos e viu uma distribuição impossível — é que a falha apareceu: o sensor havia travado.

Três dias de dados nulos disfarçados de dados reais. Num período de vento forte, com presença de eventos de rajada relevantes para classificação de sítio. Não recuperáveis.

O problema não é raro. É, de longe, a categoria de erro mais cara que encontramos em revisões de campanha: falhas que passam nos checks de range, passam nos checks de completude, e só são detectadas — quando são — num momento em que a janela de intervenção já fechou.

Três categorias de sinal oculto

As falhas que escapam da detecção básica se enquadram em três padrões, cada um com origem diferente e impacto diferente na qualidade da análise.

1. Congelamento de sensor (stuck value)

O sensor registra o mesmo valor — exatamente o mesmo, até a última casa decimal — por N registros consecutivos. Anemômetros travam por gelo, por sujidade no cabeçote, por falha de comunicação no protocolo Modbus, por bug de firmware. Piranômetros travam quando o conversor A/D trava ou quando há falha no condicionador de sinal.

O valor travado é quase sempre um valor "real" — é o último valor válido antes da falha. Por isso passa em qualquer check de range físico. A detecção requer um critério de persistência:

flag_travado = True  se  len({ x[t-N : t] }) == 1  e  N ≥ limiar
# Exemplo: 6 registros idênticos a 10 min → 1 h travado → flag

O limiar depende da variável e da resolução temporal. Velocidade de vento travada por mais de 30 minutos (3 registros a 10 min) já é suspeita — a turbulência atmosférica impossibilita valores idênticos em escala de dezenas de minutos. Irradiância solar pode ser legitimamente constante (zero) à noite, então o limiar precisa considerar o horário.

2. Deriva lenta de calibração ou sujidade

O sensor funciona — não está travado, os valores variam naturalmente — mas o sinal está sendo atenuado por sujidade acumulada no domo do piranômetro, ou deriva de calibração no transdutor do anemômetro. O dado parece normal. A anomalia só aparece quando comparada com uma referência: outro sensor redundante, o modelo de céu limpo, ou o histórico do próprio instrumento.

A técnica mais eficaz para piranômetros é o índice de céu limpo κ_cs: razão entre a irradiância medida e a prevista por um modelo de transferência radiativa (PVLIB, REST2, Ineichen) para condições de céu limpo. Em períodos consecutivos sem nuvem, κ_cs deveria permanecer próximo de 1,0 para um sensor limpo. Uma tendência de queda contínua é assinatura de sujidade.

Para anemômetros, a referência de comparação é o sensor redundante (quando disponível) ou o modelo de reanalise (ERA5, MERRA-2) para detecção de offsets persistentes. A diferença metodológica é importante: o modelo de reanalise tem incerteza da ordem de ±10% no curto prazo, então só detecta desvios sistemáticos grandes (>15%). O sensor redundante detecta desvios de 2-3% — a faixa relevante para AEP.

3. Lacunas com padrão temporal sistemático

O terceiro padrão é o mais insidioso porque não aparece como falha de sensor — aparece como ausência de dados, que já tem tratamento na norma (IEC 61400-12-1 e IEC 61724-1 definem critérios de disponibilidade mínima). O problema é quando as lacunas não são aleatórias: elas ocorrem sempre no mesmo horário, todos os dias.

Causas comuns: data logger reiniciando por watchdog às 14:00 (perda de 10 min/dia no horário de pico de irradiância), sombra de obstáculo não mapeado projetando sobre o piranômetro entre 11h e 13h, interferência de rádio de um equipamento próximo que entra em operação às 08h. Em todos os casos, a disponibilidade diária é alta (>98%), mas o dado faltante é correlacionado com o período de maior produção — o que gera um viés sistemático na estimativa de recurso que não é capturado pelo critério de disponibilidade percentual.

A detecção usa análise de autocorrelação das lacunas: se o intervalo entre gaps sucessivos tem pico de autocorrelação em 24h (ou 12h, ou qualquer harmônico diário), há um padrão temporal que precisa ser investigado antes de avançar na análise.

Por que essas falhas passam despercebidas

A armadilha é estrutural: os três padrões passam nos checks de qualidade mais comuns porque os checks padrão verificam o que o dado é, não como o dado se comporta no tempo.

* Apenas se os dois sensores não compartilharem o mesmo data logger — senão a lacuna sistemática afeta ambos simultaneamente e a comparação cruza como "ambos indisponíveis".

A implicação prática: um sistema de QA/QC baseado apenas em checks de range e disponibilidade está cego para as falhas mais caras. Checks de persistência e slope precisam ser parte do fluxo automático, não da revisão manual mensal.

O custo da janela de detecção

O impacto de cada falha cresce de forma não linear com o tempo até a detecção. As três janelas críticas são: detecção automática em horas, revisão semanal, e revisão mensal — com consequências completamente distintas.

A detecção em T+1h custa essencialmente o tempo de revisão do log e a execução do reboot — o impacto no cálculo de disponibilidade é de horas, não de dias. A detecção a T+7d já cria uma lacuna que, dependendo do período (vento de pico estacional, dia de céu limpo de referência), pode não ser recuperável por interpolação — e exige documentação explícita no laudo técnico do impacto na incerteza. A detecção a T+30d é o cenário mais caro: os dados desse período estão comprometidos, há risco de viés na sazonalidade, e o reprocessamento pode requerer um novo laudo — o que impacta diretamente o cronograma de bankability e, em projetos com prazo para financiamento, pode atrasar a tomada de decisão por meses.

Implicações para a vida útil do ativo

O custo visível da falha não detectada é o dado inválido. O custo oculto é a degradação do instrumento que a falha revela — e que, sem detecção, continua acontecendo.

Um piranômetro com sujidade acumulada que gera deriva de 0,15%/dia não está apenas produzindo dados imprecisos: está operando num estado que aumenta o risco de dano ao domo e ao sensor de temperatura. Se a sujidade incluir materiais corrosivos (fuligem, sais marinhos em sítios costeiros), o silício do domo começa a ser atacado — e o custo de substituição do domo é significativamente menor que o custo de substituição do sensor inteiro. A detecção no dia 14 permite uma limpeza de campo antes que a sujidade cause dano físico; a detecção no dia 60 já pode ser tarde.

Para anemômetros LiDAR, o congelamento do sinal pode indicar acúmulo de gelo no cabeçote óptico — que, se persistir, causa dano por expansão térmica ao ciclo de gelo/degelo. A detecção em T+1h permite acionar o sistema de aquecimento ou agendar uma intervenção de campo antes do dano estrutural. A detecção em T+7d pode encontrar o cabeçote já comprometido.

A lógica, em última análise, é a mesma da manutenção preditiva industrial: o sensor que está falhando de forma contínua e silenciosa — degradando gradualmente — é o mais caro de substituir, porque só se manifesta quando o componente já atingiu falha total. A detecção precoce converte falha total em manutenção programada.

Como estruturar o monitoramento

A implementação de monitoramento eficaz segue três camadas, em ordem crescente de sofisticação:

As camadas 1 e 2 são implementadas no próprio data logger ou no software de análise de campanha (BORA para eólico, NT.10 para o fluxo solar via SOLANO). A camada 3 requer processamento de uma janela de dados acumulados — no mínimo 7 dias limpos para o slope κ_cs, e ao menos 4 semanas de dados para a autocorrelação de gaps ser estatisticamente robusta.

O resultado de cada camada deve gerar um flag estruturado — não apenas um alerta genérico, mas um registro com: variável afetada, período, tipo de anomalia, severidade estimada e ação recomendada. Esse flag entra na trilha de auditoria do projeto, discutida em NT.05, e compõe o histórico de incidentes que o financiador verifica em due diligence. Um projeto com flags documentados e resolvidos tem mais credibilidade que um projeto sem flags — a ausência de flags numa campanha de 12 meses é suspeita, não tranquilizadora.

A cadeia de disponibilidade discutida em NT.01 para campanhas LiDAR assume que os dados marcados como "válidos" realmente são válidos. As três categorias de falha discutidas aqui violam exatamente esse pressuposto: contam como dados disponíveis sem sê-lo. A disponibilidade calculada com stuck values incluídos não é disponibilidade — é disponibilidade de transmissão, que é uma métrica diferente e substancialmente menos útil para bankability.