Modernizing legacy EV charging management systems on AWS

Context

Workloads on Electric Vehicle Charging domain typically consists of Chargepoint Operations (CPO) and E-mobility services (eMSP). These services bring physical and digital together to provide charging experience to EV users. ChargePoint operations include CPMS (charge point management system) or CSMS (charging station management systems) to handle connections from physical chargers, and communicate with the firmware on the devices.

A widely adopted protocol in this space is OCPP (open charge point protocol). OCPP defines message types and payloads for messages between chargers and CPMS systems for handling operational and transactional communications.

Customer Problem

Early implementations of CPMS systems include monolithic applications developed with PHP and MySQL supporting SOAP/XML. OCPP version 1.6 onwards supports WebSocket with JSON transport. With increased demand on EV charging, new feature requirements, and newer versions of the protocols, these monolithic implementations have been difficult to scale and slow to evolve.

A typical CPMS implementation is depicted below using a monolithic architecture deployed on a single EC2 instance.

In monolithic architectures, the system is unable to scale services independently, and suffers from slow development processes due to monolithic deployment. As the number of chargers grow the load on the services and the database needs larger instances and start to hit limits.

Layered architectures are also common, where a WebSocket proxy is implemented separately from CPMS backend (to add support for OCPP1.6J chargers), CPMS backend and Database in separate layers.

In Layered architectures, teams can scale the CPMS backend and Database independently, and make use of managed databases to offload a host of maintenance tasks to AWS. The layer handling OCPP connections (WebSocket proxy) needs to manage each charge point connection and route messages back and forth between an internal HTTP interface and external WebSocket connections. Customers find it difficult to scale this layer because multiple instances introduce complexity due to each CPMS backend message needing to be routed to the proxy instance which has the WebSocket connection open to a particular charger specified in the message. In addition to this additional database for connection lookup and internal load balancers are needed to route traffic. This layer usually becomes a bottleneck and a single point of failure.

Modernization Strategy

Customers can use AWS modernization pathways to modernize legacy CPMS systems on AWS. The modernization pathways we apply are:

• Move to cloud native, by implementing a serverless, event driven WebSocket gateway
• Move to containers and strangle monolithic CPMS backend into micro-services

First step for modernization is to implement a serverless event-driven WebSocket gateway, to reduce the coupling between CPMS backend and WebSocket proxy. For this purpose we can use AWS IoT core topics. We choose IoT core topics over Amazon Kinesis, or Amazon EventBridge in this case so that we can support direct MQTT transport for OCPP messages without much refactoring.

Customers can use open-source AWS OCPP Gateway implementation which provides an AWS ECS Fargate based gateway to transform OCPP WebSocket messages into MQTT and vica versa. This solution automatically scales, and can support mutual TLS authentication for charge points.

Customers can also implement a serverless OCPP gateway using API Gateway WebSocket APIs, Amazon CloudFront, Lambda, and DynamoDB. This solution provides built-in high availability and even less operational maintenance as you won't need to maintain container images for the gateway.

In this architecture, CloudFront distribution handles incoming WebSocket connection requests over TLS. OCPP WebSocket endpoints for each charger also include charge point id in the URL path (e.g. wss://endpoint.url/<charger_id>) . We use CloudFront functions to move the ID from the request URL to a request header and forward the requests to API Gateway WebSocket API endpoint. WebSocket connections, authentication, and messages are handled by individual lambda functions. Connections are stored in a DynamoDB table. A publish/subscribe mechanism implemented with MQTT decouples the Gateway from the Backend.

Once we achieve the decoupling of the CPMS backend services from the WebSocket gateway, other modernization pathways are now open.

• We can containerize the CPMS backend and run using ECS Fargate.
• We can use strangler fig pattern to further decompose the monolithic CPMS backends into micro-services.
• We can implement brand new functionality outside of the legacy CPMS backend, and reduce the load on the CPMS database.
• We can even replace CPMS backend with a SaaS vendor using the REST API interface.

Summary

In order to modernize CPMS systems on AWS, we need to decouple the OCPP gateway component from the CPMS backend functions, so that we can introduce high availability and scalability for handling large number of chargers. This unlocks further modernization pathways to improve the rest of the system.