FIAP + GoodWe · EV Challenge 2026 Turma: 1CCPG Status: Fluxo principal funcional e implantado — protótipo físico e integração de pagamento em desenvolvimento
O ChargeGrid Intelligence é uma plataforma de gestão de recarga de veículos elétricos para ambientes comerciais (shoppings, estacionamentos, postos de combustível). O sistema orquestra múltiplos carregadores da linha GoodWe HCA G2, controla a demanda de energia em tempo real, cobra os usuários por sessão de recarga e serve tanto o motorista quanto o operador do estabelecimento.
| Pilar | Descrição | Status |
|---|---|---|
| Controle de Demanda | Algoritmo de rebalanceamento (water-filling) que distribui a potência disponível entre carregadores de capacidades diferentes (7kW/11kW/22kW), sem desperdiçar capacidade contratada | Implementado e testado |
| Protocolos Abertos | Linha HCA G2 se comunica via Modbus TCP (confirmado pela GoodWe); protótipo físico (ESP32 + NFC) em desenvolvimento como interface com o backend | Simulado por eventos — hardware real em prototipagem |
| Tarifação e Pagamento | Cobrança dinâmica por sessão, ajustada por horário de pico, demanda da rede e modo de carregamento escolhido | Cálculo implementado; Gateway de pagamento simulado |
| IA Aplicada | Motor de regras que decide tarifa e distribuição de energia em tempo real — o “raciocínio” por trás do sistema, não uma interface decorativa | Implementado; Previsão preditiva de picos é próximo passo |
Implantado publicamente:
O esquema completo de integração dos componentes, fluxo de dados, mapa de registradores e conexão com os conteúdos da disciplina estão documentados no relatório técnico e a avaliação e resultados no relatório da sprint 4:
Sprint 3: relatorio.pdf
Sprint 4: avaliacao_e_resultados.pdf
| Interface 1 — Dashboard do Operador | Interface 2 — PWA do Cliente |
|---|---|
| Painel com todos os carregadores em tempo real | Login, cadastro e perfil |
| Métricas agregadas (demanda, sessões ativas, capacidade usada) | Vínculo de sessão via cartão RFID |
| Criação e encerramento manual de sessão | Personalização (limite de valor + modo de carregamento) |
| Log estilo OCPP das transações (será substituído por Modbus) | Acompanhamento sob demanda + fatura + pagamento |
| HTML5 · CSS3 · JavaScript (Vanilla) | HTML5 · CSS3 · JavaScript (Vanilla) · PWA instalável |
1. Cliente aproxima o cartão RFID no carregador
↓
2. Backend cria a sessão (status: "iniciada")
↓
3. Cliente lê o mesmo RFID no celular (PWA) e personaliza a recarga
↓
4. Sessão transiciona para "carregando" — dispara rebalanceamento
↓
5. Cliente, operador ou o carregador físico podem encerrar a sessão
↓
6. Backend calcula energia, tarifa e custo — gera a fatura automaticamente
↓
7. Pagamento confirma a fatura e libera o cartão/carregador
Todo o rebalanceamento e as atualizações de status acontecem por evento (início e fim de sessão) — não há polling contínuo no backend. A checagem de consumo em tempo real (GET /sessoes/status/:id) é feita sob demanda, quando o PWA ou o dashboard pedem, não em loop.
| Componente | Tecnologia | Situação |
|---|---|---|
| Back-end | Node.js + Express | Em produção |
| Banco de Dados | MySQL (via mysql2/promise) |
Em produção (Railway) |
| Front-end (Dashboard) | HTML5, CSS3, JavaScript (Vanilla) | Funcional |
| Front-end (PWA) | HTML5, CSS3, JavaScript (Vanilla), Service Worker, Web App Manifest | Funcional e instalável |
| Pagamento | Confirmação de status real via API própria | Gateway externo (Mercado Pago/PIX) ainda não integrado |
| Comunicação com o carregador | Simulação orientada a eventos via API REST | Modbus TCP real é o protocolo confirmado da linha HCA G2; ainda depende de acesso ao hardware físico |
| Protótipo físico | ESP32 + leitor NFC | Em desenvolvimento — simula o carregador comunicando via REST com o backend |
| Lógica Inteligente | Módulo de regras em JavaScript (tarifação dinâmica + rebalanceamento) | Implementado; Previsão preditiva de picos é roadmap |
| Hospedagem | Railway (Backend + MySQL) | Ativo |
chargegrid-intelligence/
│
├── src/ # Servidor Node.js
│ ├── server.js # Ponto de entrada + arquivos estáticos
│ ├── db.js # Conexão MySQL
│ ├── logic.js # Regras de negócio (tarifa, rebalanceamento, etc.)
│ ├── routes/
│ │ ├── sessoes.js
│ │ ├── carregadores.js
│ │ ├── pagamento.js
│ │ ├── rfids.js
│ │ └── usuario.js
│ ├── models/
│ │ ├── SessaoModel.js
│ │ ├── CarregadorModel.js
│ │ ├── UsuarioModel.js
│ │ ├── RFIDModel.js
│ │ └── FaturaModel.js
│ ├── config/
│ │ └── modbusConfig.js # Endereços de registrador, escalas e mapa de status
│ │ # (única fonte de hipóteses/decisões de interpretação)
│ └── services/
│ ├── modbusClient.js # Cliente Modbus TCP — lê e traduz os registradores
│ └── modbusSimulator.js # Servidor Modbus TCP simulado (substitui o hardware)
│
├── sql/
│ └── schema.sql # Script do banco
│
├── frontend/
│ ├── tela-cliente/ # PWA (Interface 2)
│ │ ├── login.html
│ │ ├── menu.html
│ │ ├── manifest.json
│ │ ├── sw.js
│ │ ├── style/
│ │ ├── script/
│ │ └── icons/
│ └── tela-operador/ # Dashboard (Interface 1)
│ ├── dashboard.html
│ ├── style/
│ └── script/
├── scripts/
| ├── demo-modbus.js # Demonstração do ciclo completo de uma recarga
| └── ler-carregador.js # Leitura avulsa, útil contra hardware real
├── docs/
| ├── relatorio.pdf
| └── avaliacao_e_resultados.js
├── .env.example
├── package.json
└── README.md
O back-end fica na raiz do repositório (não numa subpasta) para simplificar a configuração de deploy no Railway.
1. Clone o repositório
git clone https://github.com/LuRSousa/ChargeGrid-Intelligence.git
cd ChargeGrid-Intelligence
2. Instale as dependências
npm install
3. Crie o banco de dados
CREATE DATABASE chargegrid_db;sql/schema.sql4. Configure as variáveis de ambiente
Copie .env.example para .env e preencha:
PORT=3000
DB_HOST=localhost
DB_USER=root
DB_PASS=SUA_SENHA
DB_NAME=chargegrid_db
5. Inicie o servidor
node src/server.js
6. Teste a conexão
Acesse http://localhost:3000/health — deve retornar {"status":"ok","db":"connected"}
7. Acesse as interfaces
http://localhost:3000/login.htmlhttp://localhost:3000/dashboardAmbas as interfaces são servidas pelo próprio Express — não precisam de um servidor separado.
O backend está implantado no Railway, junto com o banco MySQL, permitindo que qualquer integrante da equipe — e o protótipo físico (ESP32) — testem contra o mesmo ambiente, sem depender de uma máquina local ligada.
Além da simulação por eventos que já roda em produção, o projeto tem um módulo independente que implementa a comunicação Modbus TCP com base no mapa de registradores da linha HCA G2.
Diferente de um simulador que responde por chamada de função, este sobe um servidor Modbus TCP de verdade: o cliente se comunica seguindo o mesmo padrão de comunicação Modbus TCP utilizado para a comunicação com um equipamento físico — socket TCP, cabeçalho MBAP, function code, frame de resposta. A arquitetura foi preparada para que o cliente possa apontar para um equipamento físico por meio das configurações de host, porta e parâmetros Modbus, sem alterar a lógica de interpretação dos dados.
| Registrador | Campo | Tipo | Escala |
|---|---|---|---|
| 10015 | Potência de carregamento | U16 | ÷10 → kW |
| 10016 | Energia da sessão atual | U16 | ÷10 → kWh |
| 10017 | Status do carregador | U16 | 11 estados oficiais |
| 10500–10506 | UID do cartão RFID | STR (14 bytes ASCII) | — |
Os endereços e escalas seguem o mapa utilizado pelo módulo; parâmetros de função Modbus e offset permanecem configuráveis conforme a documentação/equipamento utilizado.
Este módulo não está conectado às rotas da API nem ao banco de dados — por decisão consciente, para isolar o risco enquanto o fluxo principal (sessões, tarifação, pagamento) já está validado em produção. A integração com o protótipo físico (ESP32 simulando o carregador via Modbus TCP) é o próximo passo natural deste módulo.
Como testar isoladamente:
# Terminal 1 — sobe o carregador simulado
npm run simulator
# Terminal 2 — lê os registradores dele
npm run ler
# Ou roda a demonstração completa do ciclo de vida de uma recarga
npm run demo
O que ainda está por vir, tratado como evolução consciente do projeto, não como pendência escondida:
| Papel | Responsabilidade | Status |
|---|---|---|
| M1 — Backend Foundation | Servidor Node.js + Express + MySQL | Concluído |
| M2 + M6 — Protótipo Físico | ESP32 + leitor NFC simulando o carregador, integração via API REST | Em desenvolvimento |
| M3 — API REST | Rotas de sessões, carregadores, RFID, usuários e faturas | Concluído |
| M4 — Interface do Cliente (PWA) | Scripts de login e menu, integração com a API | Em desenvolvimento |
| M5 — Interface do Operador (Dashboard) | Estrutura, integração com a API, métricas | Concluído |
| M7 — Pagamento + IA | Fluxo de fatura, lógica de tarifação dinâmica | Fatura concluída; gateway externo pendente |
| Nome | RM |
|---|---|
| Caio Henrique Ferraz da Silva | RM568992 |
| Enzo Caruso Peter | RM570908 |
| Leonardo Figueredo dos Santos | RM573653 |
| Leonardo Robert Maulicino | RM570329 |
| Lucas Ramos de Sousa | RM573901 |
| Matheus Pimenta Martini | RM569400 |
| Pablo Renato dos Santos Sobral de Carvalho | RM569894 |