Skip to main content

OCPP (Open Charge Point Protocol): o guia definitivo para quem opera, integra e desenvolve infraestrutura de recarga

Erik Perin
12 de setembro de 2025
Acessos: 18

Assuntos

Compartilhe com seus amigos

Se você já se perguntou como um carregador “fala” com a plataforma que monitora sessões, autoriza usuários, aplica tarifas, atualiza firmware e equilibra cargas, a resposta é: Open Charge Point Protocol (OCPP). Criado e mantido pela Open Charge Alliance (OCA), o OCPP padroniza a comunicação entre a Charging Station (o hardware de recarga, também chamada de EVSE) e o Charging Station Management System (CSMS, o “cérebro” na nuvem ou on-premise). Essa padronização evita vendor lock-in, permite misturar marcas de hardware e software, e acelera a inovação em toda a cadeia da eletromobilidade.

O que é, exatamente, o OCPP?

O OCPP é um protocolo de aplicação, neutro e aberto, que define mensagens, estados e fluxos para tudo que envolve a operação de um carregador conectado: do “alô” inicial (BootNotification) às batidas de coração (Heartbeat), da autorização de uso ao registro de medições, da gestão de falhas à atualização segura de firmware. Até hoje, é o padrão de fato do setor e, desde dezembro de 2024, tornou-se também um padrão internacional IEC 63584, baseado no OCPP 2.0.1 — um marco que elevou a interoperabilidade a outro patamar.

Em 2025, a OCA publicou o OCPP 2.1, evolução compatível com o 2.0.1 e com foco em recursos avançados como suporte nativo ao ISO 15118-20 (incluindo V2X), novas formas de smart charging, integração com sistemas de gestão de energia (EMS) e melhorias de usabilidade e pagamentos.

Como o OCPP funciona (por dentro)

Arquitetura em linhas claras

O carregador estabelece uma conexão persistente com o CSMS, tradicionalmente via WebSocket com JSON (OCPP 1.6 também admite SOAP/XML). Sobre esse canal, trocam-se mensagens com identificadores, tipos e campos rigorosamente definidos, permitindo telemetria, comandos remotos, autorização e faturamento. O 2.0.1 consolidou esse modelo e introduziu uma estrutura documental mais clara (Partes 0 a 6, perfis de certificação), tornando a implementação e os testes mais previsíveis.

Fluxos essenciais

  1. BootNotification: o carregador se apresenta ao CSMS e informa capacidades, firmware etc.; se aceito, passa a enviar Heartbeats.
  2. Authorize: o usuário é validado (cartão RFID, app, AutoCharge/placa MAC, cartão EMV em 2.x).
  3. Sessão: no 1.6, o trio StartTransaction / MeterValues / StopTransaction carrega o relato da recarga; no 2.0.1, tudo foi unificado em TransactionEvent com fases (Started/Updated/Ended), sequência e compactação opcional de WebSocket para reduzir dados. Isso melhora latência, resiliência offline e reconstrução cronológica no backend.

Dois pilares que mudaram o jogo no 2.0.1

  • Device Model: o carregador descreve sua “árvore” de componentes e variáveis, permitindo inventory, configuração alinhada a componentes e monitoramento customizável (alertas por limiar, amostragens periódicas). Resultado: menos visitas em campo e diagnóstico remoto muito melhor.
  • Segurança end-to-end: perfis de segurança, gestão de certificados do lado do carregador, firmware assinado e trilhas de eventos. Parte desses recursos foi retroportada ao 1.6-J por whitepaper oficial da OCA.

Aplicações práticas (do dia a dia)

Operação & manutenção: o CSMS monitora estados, recebe falhas, dispara diagnósticos, agenda firmware e aplica configurações em massa. Com o Device Model, alarmes ficam situados no componente exato (ex.: temperatura do conversor AC/DC do EVSE #1), permitindo manutenção preditiva.

Experiência do usuário: o 2.0.1 adicionou mensagens ao display, idioma do usuário, AutoCharge, e custo em tempo real/final da sessão — recursos valiosos para transparência tarifária.

Smart charging: o 1.6 introduziu charging profiles e balanceamento; o 2.0.1 refinou o tema e preparou a casa para ISO 15118 e cenários avançados. No 2.1, surgem estratégias explícitas (setpoint central/local, frequency support, local load balancing) e DER/V2X com parâmetros de rede (fator de potência, droop, rampas).

Plug & Charge e ISO 15118: o 2.0.1 suporta nativamente ISO 15118-2 (contratos/certificados, renegociação de perfil); o 2.1 traz suporte nativo ao ISO 15118-20 e cadeias de certificado maiores, CRLs e múltiplos contratos, essenciais para V2X e ecossistemas multi-EMSP.

Integrações em carregadores públicos

Em redes públicas, o OCPP faz carregador ↔ CSMS. Já roaming, interoperabilidade entre redes e faturamento entre CPOs/eMSPs acontecem por protocolos complementares, como OCPI. Em resumo: OCPP cuida do “tempo real” da estação; OCPI conecta operadores e provedores de serviço para que o motorista use várias redes com uma única conta. Pense em OCPP como o “RAN” e em OCPI como o “roaming” da telefonia móvel.

Pagamentos ad hoc (cartão EMV, smartphone, terminal local) e cálculo de custo local ganharam use cases maduros no OCPP 2.1, inclusive pré-pago e topologias com terminal acoplado ao carregador ou via CSMS — item prático para rodovias e varejo.

E em versões residenciais? Como fica o OCPP em casa?

No residencial, há dois cenários:

  • “App do fabricante” (proprietário): simples e suficiente para muita gente, mas fechado.
  • Carregador com OCPP (tipicamente 1.6-J ou 2.0.1): permite integrar o wallbox a CSMS/HEMS de terceiros, ativar controle dinâmico conforme tarifa (TOU, bandeiras), fotovoltaica e limites de demanda do quadro da casa. O 2.1 documenta topologias de EMS local, inclusive interceptando OCPP para somar potência de PV e priorizar cargas — sem depender da nuvem.

Funcionalidades úteis no lar: lista local de autorização (uso familiar sem internet), comportamento offline robusto, load balancing entre múltiplas vagas, exibição de custo/consumo e firmware seguro. Para quem participa de agregação/V2H/V2B, o 2.1 abre a porta para estratégias de injeção/absorção coordenadas.

As versões do OCPP — diferenças que importam

OCPP 1.6 (2015)

Foi o salto que popularizou o padrão: Smart Charging, JSON/WebSocket (além de SOAP), trigger messages, diagnósticos, reservas e availability. Até hoje domina o parque instalado. Segurança avançada exige a extensão oficial da OCA (1.6-J Security Whitepaper) para TLS, eventos de segurança e firmware assinado.

Quando faz sentido: retrocompatibilidade, integrações legadas e residenciais simples. Limitações: device model ausente, transações fragmentadas, integração ISO 15118 restrita a notas de aplicação.

OCPP 2.0.1 (2020)

É uma reengenharia do protocolo: Device Model, TransactionEvent, perfis de certificação (Core e estendidos), segurança com PKI, WebSocket compression, melhor UX (mensagens, idioma, custo em tempo real) e suporte completo a ISO 15118-2 (incluindo Plug & Charge e gestão de certificados). Não é compatível com 1.6.

Quando faz sentido: novos projetos, fast chargers, redes em crescimento e diagnósticos avançados.

OCPP 2.0.1 Edition 3 (2024–2025)

Edição que consolida erratas e clarificações, servindo de base para o 2.1 e que foi aprovada como padrão IEC 63584. Se você vai certificar hoje, ed3 é a referência.

OCPP 2.1 (2025)

Evolução compatível com 2.0.1, com ISO 15118-20 nativo, BPT/V2X, DER control, novas estratégias de smart charging, reset com retomada de transação, pré-pago, pagamento local/adhoc e integração EMS local. É a versão para quem quer ir além do charging-only e explorar V2H/V2B/V2G e serviços de rede.

OCPP em ação: do projeto à operação

Planejamento & aquisição

  • Defina a versão-alvo: 2.0.1 ed3 para robustez atual; 2.1 se V2X/DER/EMV local estiverem no roadmap.
  • Exija certificação (1.6 Security; 2.0.1 Perfis): isso reduz riscos de integração e garante interoperabilidade entre marcas.

Implantação

  • Para estações públicas, combine OCPP + OCPI: o primeiro para operação do hardware; o segundo para roaming, settlement e experiência multi-rede do motorista.
  • Em condomínios/empresas, use smart charging para respeitar a demanda contratada; o 2.1 permite estratégias locais e com EMS para priorizar veículos críticos sem disparar custos.
  • Em residências, habilite lista local, agendamentos por tarifa e, se houver FV, carregamento “solar first”. Para o futuro, considere wallbox preparado para V2H (2.1).

Operação contínua

  • KPIs: taxa de sucesso de sessão, MTTR, alarmes por componente, eficiência de compressão WS, e economia via load shedding.
  • Segurança viva: rotação de certificados, firmware assinado, auditoria de eventos; no 1.6-J, siga o whitepaper de segurança.

Perguntas frequentes — na prática

O OCPP cuida de pagamento e roaming? Não diretamente. OCPP é carregador↔CSMS. Roaming, settlement entre CPOs/eMSPs e descoberta de estações vêm de protocolos como OCPI.

1.6 ainda vale a pena? Sim, para brownfields e cenários simples. Mas novos investimentos colhem ganhos claros com 2.0.1/2.1 (diagnóstico, segurança, ISO 15118, TransactionEvent).

O que mudou com a IEC? O OCPP 2.0.1 ed3 virou IEC 63584:2024, trazendo reconhecimento formal mundial e referência unificada de conformidade.

Posso fazer V2G no OCPP hoje? Com OCPP 2.1 (e hardware/EV compatíveis), sim: há use cases de Bidirectional Power Transfer, integração com ISO 15118-20 e estratégias de setpoint/frequency/local balancing.

Em uma frase

O OCPP transformou o carregador em ativo de rede inteligente: interoperável, seguro, observável e pronto para a próxima década — do AC residencial ao hyper-charger com V2X, passando por integrações EMS, PV e roaming entre redes. Se você está desenhando um projeto novo, planeje-o em OCPP 2.0.1 ed3 (ou 2.1 quando V2X/DER estiverem no horizonte) e exija certificação: sua operação — e o motorista — agradecem.