Qualidade de dados em ativos renováveis: o que QA e QC significam na prática

Engenheiros de recurso renovável usam "QA/QC" como uma sigla composta — quase um único substantivo. Faz parte do vocabulário do setor desde sempre. O problema é que QA e QC são coisas diferentes, acontecem em momentos diferentes do projeto, e confundi-las tem um custo operacional concreto: projetos que investem em QC e negligenciam QA gastam dez vezes mais para chegar ao mesmo resultado — quando chegam.

Esta nota não é uma introdução à ISO 9000. É sobre o que a distinção muda no dia de trabalho de um engenheiro que lida com dados diários de campanha solar ou eólica.

De onde vem a distinção

A definição formal vem da família de normas ISO 9000, que separa as duas funções de forma precisa:

Quality Assurance (QA) — garantia de qualidade — é o conjunto de atividades planejadas e sistemáticas que estabelece confiança de que um produto ou serviço satisfará os requisitos de qualidade. QA atua no processo. Seu objetivo é evitar que defeitos aconteçam.

Quality Control (QC) — controle de qualidade — é o conjunto de técnicas e atividades usadas para verificar se os requisitos de qualidade foram atendidos. QC atua no produto. Seu objetivo é detectar defeitos que já aconteceram.

A diferença não é de intensidade, mas de temporalidade e objeto: QA olha para o futuro (como vamos garantir que o dado será bom?), QC olha para o passado (o dado que chegou é bom?).

O que o engenheiro faz às 8h

Em uma campanha ativa — solar ou eólica — a primeira tarefa da manhã costuma ser a mesma: abrir o painel de dados, ver o que chegou do logger durante a noite, e identificar se há algum problema. Isso é QC puro.

As ações são de verificação e inspeção:

• Baixar os dados do período e checar integridade da transmissão
• Verificar se o count de registros está correto (esperado: 144 registros de 10 min por dia)
• Rodar checks de range físico (GHI < 0, velocidade < 0, temperatura fora de faixa)
• Checar persistência: algum valor repetido por mais de N registros consecutivos? (ver NT.12)
• Comparar com o sensor redundante: alguma divergência fora do esperado?
• Calcular o κ_cs do dia anterior: continua a tendência de queda de sujidade?
• Documentar qualquer flag novo no registro de incidentes

Tudo isso é verificação do produto (o dado que chegou). O engenheiro não está mudando o processo de medição — está inspecionando o resultado dele.

O tempo que esse processo leva é diretamente proporcional à qualidade do QA que foi feito antes da campanha. Com boa QA, a revisão diária é rápida: os checks automáticos rodam sem intervenção, os flags são raros e bem categorizados, e o engenheiro termina em 30 minutos. Com QA ruim — sensores mal calibrados, redundância ausente, protocolo de naming inconsistente — cada dia de dados exige investigação manual que pode consumir horas.

O que define antes da primeira medição

QA, em campanhas de recurso renovável, acontece principalmente em dois momentos: durante o planejamento da campanha e durante a instalação dos instrumentos. Essas decisões determinam a estrutura de qualidade que o QC vai ter que inspecionar nos meses seguintes.

Durante o planejamento:

• Especificação do instrumento conforme a norma de referência (piranômetro ISO 9060 Classe A para IEC 61724-1, anemômetro certificado MEASNET para IEC 61400-12-1)
• Definição de redundância: quantos sensores por variável, configuração de backup
• Protocolo de naming de variáveis (consistência entre projetos do portfólio)
• Calendário de calibração e manutenção (intervalo máximo entre limpezas para piranômetros em clima semi-árido)
• Definição dos critérios de validade do dado: quais checks automáticos vão rodar, em que sequência, com quais thresholds
• Protocolo de gap-filling: quando interpolar, quando usar reanalise, quando invalidar o período

Durante a instalação:

• Alinhamento do piranômetro (horizontalidade, orientação, sombreamento livre para ângulo zenital < 85°)
• Posicionamento do anemômetro (distância de obstáculos, ângulo livre de esteira da torre, boom orientation conforme MEASNET)
• Configuração do data logger (taxa de amostragem, formato de timestamp, resolução decimal)
• Verificação de comunicação e primeira série de dados de comissionamento

Nenhuma dessas atividades é "inspeção do dado" — são decisões de processo que determinam se o dado vai existir e com que confiabilidade. São QA.

Por que o laudo exige os dois

O laudo técnico bankável não é apenas um documento de resultados — é a evidência documentada de que um processo de qualidade foi seguido. Quando um financiador encomenda uma revisão independente (due diligence técnica), o revisor faz dois conjuntos de perguntas distintos:

Perguntas de QA (processo):

• O instrumento era adequado para a norma aplicável? (ISO 9060 Classe A para IEC 61724-1?)
• A instalação seguiu o protocolo de referência? (boom orientation documentado?)
• O intervalo de calibração foi respeitado? (certificado de calibração dentro do prazo?)
• Havia sensor redundante para a variável primária?
• O protocolo de gap-filling foi definido antes do início da campanha ou ad hoc durante a análise?

Perguntas de QC (produto):

• Quais flags foram gerados e como foram resolvidos?
• Qual a disponibilidade final por variável e por período?
• Quais gaps foram preenchidos, com que método e com que incerteza adicionada?
• Há evidência de deriva de calibração ou sujidade nos dados?
• A consistência cruzada entre sensores foi verificada?

Um laudo que responde bem às perguntas de QC mas não às de QA levanta dúvida sistêmica: o dado pode estar bem tratado, mas e o processo que o gerou? Um laudo que responde bem às de QA mas não às de QC levanta dúvida pontual: o processo era bom, mas o dado foi cuidado? As duas dimensões são necessárias.

A retroalimentação que fecha o ciclo

A distinção entre QA e QC só gera valor operacional quando existe um mecanismo de retroalimentação funcionando: o que o QC encontra deve atualizar o QA.

Exemplos concretos:

• QC detecta sujidade progredindo mais rápido que o esperado no verão → QA atualiza o protocolo de limpeza para intervalo mensal em vez de bimestral para campanhas na região
• QC identifica stuck value recorrente no mesmo sensor às 14h → QA investiga configuração de watchdog do data logger e corrige o firmware antes do próximo projeto
• QC encontra gap sistemático em 72 horas de dados toda vez que há chuva → QA revisa a especificação de proteção IP do data logger para o próximo projeto em clima tropical

Sem esse mecanismo, a organização executa cada projeto do zero do ponto de vista de QA — e o QC continua encontrando as mesmas falhas repetidamente, em cada campanha diferente. O custo acumulado é invisível porque aparece distribuído entre projetos, mas é real.

O custo de encontrar a falha tarde

A curva de custo cresce de forma não linear porque o que está sendo corrigido muda conforme a fase avança. No planejamento, corrigir um protocolo inadequado custa uma reunião e uma atualização de documento. Na instalação, corrigir um sensor mal especificado custa o retrabalho de campo. Durante a operação de dados, corrigir um problema identificado pelo QC diário custa horas ou dias de dados (como discutido em NT.12). Na análise, corrigir um problema que deveria ter sido resolvido antes pode exigir refazer meses de processamento. Após o laudo, o que estava errado no processo de medição exige uma nova campanha — e novo laudo, novo prazo, nova rodada de due diligence.

A confusão que custa caro

O equívoco mais frequente em projetos que chegam para revisão não é o de fazer QC de má qualidade. É o de investir muito em QC e pouco em QA — e depois se surpreender que o QC encontra problemas que não podem ser resolvidos.

Um engenheiro que revisa dados diários com rigor (bom QC) mas que operou com um único piranômetro sem redundância (QA insuficiente) vai identificar a falha do sensor no dia certo — e não terá como reconstruir os dados daquele período. O QC detectou; não havia dado para recuperar. Boa QA teria garantido um sensor backup: quando o primário falhou, o secundário teria continuado registrando.

Inversamente, um projeto com boa QA — sensor calibrado, instalação conforme norma, redundância configurada — produz dados que exigem muito pouco do QC diário. Os flags são raros porque o processo estava correto desde o início. O engenheiro revisa em minutos e segue para a análise. A carga de QC é proporcional à qualidade do QA anterior.

Na prática dos ativos renováveis, a disponibilidade discutida em NT.01 e os checks de QA/QC de piranômetros de NT.03 são ferramentas de QC — inspeção do produto. O protocolo de medição que define quais desses checks serão executados, com quais thresholds, em qual software, com qual trilha de auditoria — esse protocolo é QA. Não existe QC eficaz sem QA que defina o que o QC deve verificar.