Como o NEVI conta o uptime — e por que o seu RMS não concorda

Todo CPO com um contrato NEVI já notou isso em algum momento. O painel do RMS do fornecedor diz que o site funcionou com 98,7% de uptime no mês passado. O analista de conformidade abre os dados, aplica a metodologia NEVI e o número volta como 91,4%. Mesmo site. Mesmo mês. Mesmos carregadores. Sete pontos de diferença.

O primeiro instinto é que alguém está errado. A resposta honesta é que ambos os números estão corretos — eles estão medindo coisas diferentes. Entender qual importa para o relatório federal é a diferença entre atingir o piso de uptime de 97% por porta e escrever um plano de ação corretiva.

A maioria dos fornecedores de carregadores define a «disponibilidade» no seu RMS como uma de duas coisas: a porcentagem de tempo em que a unidade reportou um heartbeat ao CSMS (a métrica de heartbeat), ou a porcentagem de tempo em que a unidade não estava em um estado de «Falha» conhecido de acordo com as mensagens StatusNotification do OCPP (a métrica livre de falhas). Ambas são métricas operacionais úteis. Ambas também são autorreportadas. O carregador precisa saber que está quebrado para reportá-lo como quebrado.

O RMS do fornecedor mede a opinião do carregador sobre si mesmo. O NEVI mede se um motorista poderia chegar e completar uma sessão. Esses não são o mesmo número.

Os modos de falha que o RMS do fornecedor omite sistematicamente incluem: estados de cabo preso que bloqueiam novas sessões mas deixam a unidade reportando «Disponível»; timeouts de payment rail que impedem a autorização apesar de a unidade estar tecnicamente online; erros no nível de mensagem OCPP que deixam a unidade em um estado de «pronta mas incapaz»; quedas de conectividade do lado da rede que impedem as viagens de ida e volta de autorização do CSMS; e problemas de firmware que fazem a unidade aceitar um plugue e depois se recusar a entregar energia.

Um motorista chegando a um carregador com «100% de uptime por RMS» e não conseguindo completar uma sessão não se preocupa com qual desses modos de falha foi responsável. O NEVI também não se preocupa.

A regra final do Título 23 do NEVI define o uptime por porta em termos operacionais: a porcentagem de tempo em que a porta estava disponível para entregar uma sessão de carregamento bem-sucedida. A metodologia exclui explicitamente o tempo em que a porta estava impossibilitada de entregar uma sessão por qualquer motivo, incluindo razões que o RMS do fornecedor não sinaliza. Isso inclui o tempo em que o cabo estava preso, o terminal de pagamento estava inacessível, a conexão de rede do CSMS estava instável, e a unidade estava tecnicamente «online» mas se recusando a iniciar sessões.

A lacuna existe porque as duas medições têm fontes de informação diferentes. O RMS do fornecedor vê o que o carregador reporta sobre si mesmo. O NEVI requer qual foi o comportamento efetivo da porta em relação a um motorista. Os dois só convergem no caso raro em que o carregador se autorreporta corretamente sobre cada modo de falha no momento em que ocorre — e esse caso efetivamente não existe em produção.

Os CPOs que tentam conciliar manualmente a lacuna normalmente extraem exportações de RMS de fornecedores, logs de payment rail do processador de pagamentos, dados de tickets da equipe de campo e exportações do ledger de sessões do CSMS. Eles mesclam esses dados por timestamp e tentam identificar períodos em que o carregador acreditava estar disponível mas nenhuma sessão podia ser concluída. Este é um exercício mensal de 2 a 3 semanas por site, e produz aproximações — não evidência selada.

A medição real de uptime de nível NEVI requer que as fontes de telemetria sejam correlacionadas continuamente, não reconciliadas mensalmente. Cada mensagem OCPP precisa ser pareada com o evento de payment rail que acionou (ou não). Cada StatusNotification precisa ser verificada com o ledger de sessões do CSMS. Cada minuto que a porta passou em um estado não-Disponível precisa ser classificado: um motorista pode concluir com sucesso uma sessão aqui, agora, ou não? A saída é uma linha de «disponível para sessão» por porta, desenhada ao vivo, contra um fluxo de eventos selado.

Quando a janela de relatório trimestral do NEVI abre, o pacote se rascunha sozinho: uptime por porta pela metodologia, minutos excluídos com causas documentadas, fluxo de eventos bruto anexado para qualquer auditor que pergunte. O analista de conformidade revisa em vez de montar. E quando o RMS de um fornecedor mostra um uptime que não concorda com a medição NEVI, o CPO tem a evidência específica de quais minutos divergiram — e uma conversa de gestão de fornecedores com alavancagem.