[Vídeo do projeto]

Equipa: Grupo 08:
Afonso Rito (Coord.) , Daniel Escadas , Gonçalo Soares , Kenji Morimoto , Paulo Carvalho
Empresa: WITHUS - Inovação e Tecnologia,Lda
Orientadores: Paulo Bartolomeu (DETI)
Emanuel Miranda (WITHUS)
Tiago Duarte (WITHUS)

O aumento da consciencialização para as alterações climáticas levou as pessoas a quererem reduzir o impacto ambiental, incluindo na área da mobilidade. A utilização de veículos elétricos é uma forma de atingir esse objetivo, mas ainda existem problemas relacionados com os postos de carregamento, no que toca às formas de pagamento. Este projeto visa criar um método de pagamento universal para os postos de carregamento, evitando a necessidade de efetuar contratos com empresas de energia ou até a transferência de aplicações. O objetivo é tornar as transações mais simples e intuitivas para melhorar a experiência do utilizador.

Equipa

Desafio

A WITHUS é responsável pela criação, desenvolvimento, testagem e validação de multíplos dispositivos, entre eles carregadores de veículos elétricos, por exemplo, wallbox’s para utilização doméstica e carregadores para a via pública. Atualmente existem múltiplos carregadores na via pública, sendo possível a sua utilização com um cartão particular obtido através de uma adesão à rede de mobilidade elétrica (Mobi.e).

O desafio proposto pela empresa tem como objetivo a criação de um terminal de pagamento universal, motivado pelo “Regulamento (UE) 2023/1804 DO PARLAMENTO EUROPEU E DO CONSELHO”, mais especificamente o artigo 5, onde se define que a partir do dia 13 de abril de 2024, qualquer ponto de carregamento instalado após este período deve permitir no minímo uma forma de pagamento universal para agilizar o serviço para o utilizador.

O projeto envolve o uso de um carregador real, um microcontrolador que se define como um componente de controlo/atuação perante mudanças no carregamento, um smartphone que assume o papel de uma tela touch-screen e, simultaneamente, representa um terminal de pagamento comercial da SIBS. Uma vez que se teve suporte da referida empresa, foram usadas funcionalidades facultadas pela mesma.

Resultados

No final do projeto concretizou-se um protótipo pronto para implementação em casos reais: dispomos de um terminal de pagamento semelhante ao da SIBS (o smartphone) em que corre a aplicação desenvolvida, este smartphone está conectado a um ESP32, que é o “cérebro” do carregador. A aplicação possibilita vários tipos de pagamento, entre eles, MBWAY, PAYPAL e leitura de cartões com NFC (Contactless).

O ESP32 comunica com a aplicação via cabo USB, enviando e recebendo informações relativamente ao carregamento; as informações enviadas do ESP para a aplicação são as seguintes: connected, authorization, operation, energy, time_hours e time_min.

Parâmetros ESP -> APP APP -> ESP
connected (bool) X -
authorization (bool) - X
operation (char) X -
energy (float) X -
time_hours (uint8_t) X -
time_min (uint8_t) X -

No momento em que o utilizador desejar carregar a sua viatura, conectará a ficha do carregador à mesma, neste preciso instante, o ESP deteta a ficha enfeixada e envia esta informação (connected) para a aplicação que, após recebê-la, mudará de screen apresentando os métodos de pagamento disponíveis, que são MBWAY, PAYPAL e Contactless estando este último a usar o leitor de NFC do smartphone.

No segundo screen o utilizador escolhe o tipo de pagamento que lhe for conveniente.

Após o utilizador efetuar o pagamento com sucesso, a aplicação envia de imediato um frame de dados em que o campo authorization é colocado a true de forma a indicar ao ESP que o carregamento pode iniciar. Após esta troca de mensagens, a aplicação irá passar para o ecrã de carregamento onde irá mostrar em tempo real informação relativa ao mesmo. Um dos parâmetros a ser apresentado será o valor a pagar caso a operação seja interrompida sendo posteriormente este valor debitado da conta do utilizador.

No fim do carregamento, a aplicação responde com uma mensagem de dados para o ESP com o campo authorization a false para informar que o utilizador não tem mais autorização para carregar o veículo. O screen apresentado irá fornecer informação sobre o tempo despendido, a energia total fornecida, tal como o preço final.

Mais informação

De forma a compreender o funcionamento do ESP e da APP, apresentamos imediatamente abaixo as explicações.

Para o ESP, foi construída uma máquina de estados com 5 estados: INIT_STATE, WAIT_CHARGER, PAYMENT, CHARGING e o ERROR. No estado inicial (INIT_STATE) todos os dados são inicializados com o valor default; após esta ação, o estado altera-se para o seguinte, WAIT_CHARGER. Neste estado, o ESP irá esperar continuamente que a ficha seja conectada à viatura; assim que esta ação seja concretizada, passa para o estado seguinte. No estado PAYMENT, o ESP espera que o pagamento seja autorizado (este passo é da responsabilidade da aplicação). No último estado, CHARGING, o carro encontra-se em carregamento, e o ESP envia dados continuamente de forma a atualizar os dados na aplicação. No final do carregamento, ao ser desconectado o veículo, o ESP informa a aplicação da ocorrência e retorna para o INIT_STATE.

No caso de ocorrer algum problema com o carregador, o ESP vai para o estado ERROR e envia uma indicação para o smartphone sinalizando que ocorreu um erro obrigando o carregador a ficar fora de serviço.

Do lado da APP, o diagrama de estados apresenta uma lógica semelhante ao do ESP contendo o ecrã inicial (INIT_STATE), o ecrã referente à escolha do método de pagamento (PAYMENT_SCREEN), o ecrã do estado em carregamento (CHARGING_SCREEN) e o ecrã de fim de operação (FINISH_SCREEN) que apresenta ao utilizador todas as informações acerca do seu carregamento. No caso de ocorrer um erro no carregador, a aplicação vai para o estado ERROR_SCREEN que apresenta o carregador como inoperacional.

De forma a entender como é realizada a troca de informações, apresenta-se o seguinte diagrama.

As mensagens que são trocadas entre o ESP e a APP contêm delimitadores no início e no fim de cada mensagem de modo a suprimir o risco de serem processadas mensagens incompletas.

Vídeo de teste do protótipo final