Building a Charging Station Management System with AWS

One of the main actors within the EV charging industry are Charging Point Operators (CPOs). CPOs are responsible for managing charging infrastructure availability and associated operational costs. According to the International Energy Agency (IEA), the global number of installed public charging points was up 40% in 2023 relative to 2022, and growth for fast chargers outpaced that of slower chargers¹. As the number of chargers to be managed grows, CPOs will require a software architecture capable of supporting their business needs at scale. In this blog, we will explore common implementation patterns which have operated successfully at scale, detailing the pros and cons of each option. The objective is to provide insights to help inform CIOs, Solutions Architects, and key stakeholders within CPOs as they consider potential approaches for building their Charging Station Management System on AWS.

Charging Station Management Systems

A Charging Station Management System (CSMS) is the software responsible for connecting charging points using different protocols, operating them to provide charging services, and monitoring them in real-time to help maximize their availability.

One of the protocols commonly required to be supported by CPOs is the Open Charge Point Protocol (OCPP). OCPP is a communication standard for EV charging session management between the CSMS and the charging point or EV Supply Equipment (EVSE).

When implementing CSMS to support OCPP, CPOs base their decisions on their specific business objectives and position in the EV charging value chain. Pure-play CPOs leverage OCPP to maximize the variety of chargers they can manage and optimize their charging network operations. Utility companies focus on OCPP’s smart charging capabilities to better integrate EV charging with grid management. Automotive OEMs aim to use OCPP to better enable plug-and-charge experiences for their customers. Additionally, some charging hardware manufacturers adopt OCPP as their primary protocol to control and manage both private and public charging infrastructure consistently.

Any of those CPOs, when implementing their CSMS on AWS, can take advantage of AWS fully managed services to help minimize their IT spend and reduce operational overhead.

The following sections present two implementation patterns based on serverless technology, which support this strategy of offloading infrastructure management to AWS managed services: Container-based and API Gateway-based. Then, we explore how AWS IoT services can help enhance both designs to better fit CPOs’ future needs as their charging networks and CSMS requirements evolve.

Container-based Charging Station Management Systems

A Container-based pattern focuses on delegating the complexity of infrastructure management and scaling operations while also providing building blocks for EV chargers management, transaction management, and smart charging. The custom logic that handles, monitors and operates the charging sessions can be hosted using AWS Fargate. AWS Fargate helps remove the heavy lifting of managing the infrastructure used to run containerized workloads. It can also help scale the compute and memory resources allocated by the CPO up and down according to the required load.

One complexity that CPOs face is the need to implement other charging protocols besides OCPP, since not all public charging points are OCPP compatible. Moreover, they have to support multiple versions of OCPP concurrently, as charging points in their network may be running different OCPP versions. To mitigate the impact of protocol additions or changes, a best practice is to decouple the protocol-specific logic from the backend logic of the CSMS. To achieve this decoupling, connection handlers are used in this pattern; these handlers are responsible for managing all protocol-specific messages and emit protocol-agnostic events to a common backend logic. In the case of OCPP, the connection handlers manage the WebSockets connections with the chargers, handle OCPP sessions, and interface both inbound and outbound OCPP messages with the agnostic CSMS backend.

The reference architecture for this implementation pattern in Figure 1 showcases the guidelines above. Each functional block uses fully managed services to help the functional aspects of a CSMS. The complete description can be found in the public guidance available here.

Figure 1: Container-based Charging Station Management Systems architecture

The main advantages of this implementation pattern are: 1/ the ability to reuse much of the codebase when migrating container-based solutions; and 2/ the possibility for the CPO to decide to implement an event-driven or service-driven architecture with the same technology.

However, when a CPO is starting a new project from scratch using this pattern, the need to develop and maintain custom components can potentially delay the time to market. For example, custom code must be written so that it can handle WebSocket management and implement necessary security controls around it.

API Gateway-based Charging Management System

In the pattern above, the WebSockets are managed by custom logic running in a container.

An improvement to this approach is to delegate the handling of the WebSockets to AWS by using Amazon API Gateway. This can help reduce the operational overhead required to maintain and secure that custom logic. Compared to standard WebSockets, the OCPP WebSockets specification requires WebSockets URL to have the ID of the EV charger in the path (OCPP-j-spec:3.1.1). This type of path currently cannot be handled by Amazon API Gateway at the time of writing, so it cannot be used as-is.

In order to use Amazon API Gateway to handle OCPP WebSockets, CPOs can manipulate the request and move the EV charger ID from the URL to the header of the request. They can assign this responsibility to Amazon CloudFront, specifically using a Amazon CloudFront function. Given the usage of Amazon CloudFront, this pattern is applicable only to those chargers which are connecting to their CSMS via the public internet. Some CPOs prefer to enforce the connection between the charger and the CSMS to be always private, even if encrypted; in that case this pattern cannot be considered.

Figure 2: Request manipulation using Amazon CloudFront Functions

Another behavior to be accounted for is that chargers will reconnect every 2-hours, given the duration limit for Amazon API Gateway WebSockets connections; this is not an issue per se but needs to be taken into account when configuring reporting and alerting. Besides those considerations, there are several advantages to utilizing this pattern: 1/ WebSockets are completely delegated to API Gateway; 2/ AWS Lambdas can be used to handle OCPP messages; 3/ Amazon CloudFront reduces the connection latency being connected from the point of presence; 4/ additional custom request manipulation logic can be delegated to the Amazon CloudFront function.

AWS IoT in Charging Station Management Systems

In an EV charging station, there are various devices besides the EV charging points, such as Local Controllers, Point of Sale systems, and Smart Cameras. These devices require centralized monitoring and control. Additionally, if a CPO is also a charger manufacturer, they must handle the telemetry for each charger and evaluate their status in real-time. Since charging point telemetry streaming is not within the scope of OCPP, a separate channel is required.

In both scenarios, the CPO, in addition to managing charging sessions, must also connect and monitor different devices using various industry-specific protocols.

To address this need, CPOs can use a set of purpose-built IoT services provided by AWS. These services are designed to connect and control devices while also providing monitoring features for connection and security. AWS IoT provides native support for the MQTT protocol, which means that MQTT-based devices can be integrated directly into your CSMS. However, for devices that use other protocols, such as OCPP, an adapter is required.

This approach is similar to the first pattern we discussed, where adapters are used to integrate chargers with the backend system. In this case, the adapter converts the specific protocol (e.g., OCPP) into MQTT. Meanwhile, all other MQTT connections, charger telemetry data, private chargers, and other devices can be connected to the CSMS without needing an additional adapter. In this way, all connections and devices are handled by a single broker, the AWS IoT Core, a fully managed MQTT message broker.

AWS doesn’t provide a managed OCPP adapter as of now, but has developed sample code and also works with AWS Partners to help customers integrate OCPP in their CSMS.

Figure 3: EV charging OCPP Handler with AWS IoT

The main advantages of using an AWS IoT based CSMS are: 1/ the ability to integrate MQTT enabled devices without the need to implement a custom MQTT handler; 2/ the reduced impact of introducing new protocols, thanks to the decoupling function of the IoT layer; and 3/ the reduced number of features to be maintained when also using AWS Managed Services, such as AWS IoT Rule engine, AWS IoT Registry, and AWS IoT Shadows.

The main complexity to this approach is the adapter layer, specifically in the synchronization logic between the OCPP web-sockets connections and the MQTT connections; another downside is the required proficiency in AWS IoT services, especially when coming from a non-IoT based architecture.

For further details on the implementation guidance you can navigate to this link.

Edge Logic and CSMS on AWS

One of the complexities of the growing charging network facing CPOs is the constraints imposed by existing grid infrastructure. To overcome these limitations, many operators are adopting energy management solutions at the site. These solutions enable them to install more chargers than the grid can typically support by balancing the load among them as needed. This type of feature generally requires a local device which performs controls on the charging points. This edge logic is complex to develop, distribute and update over time, with custom solutions required to be developed from scratch.

To help maintain and update the software at the edge, CPOs can utilize AWS IoT Greengrass given its purpose-built out of the box features. AWS IoT Greengrass helps enable local processing, messaging, data management, ML inference, and offers prebuilt components to accelerate application development. CPOs can use it to help manage the software running in the EV charger and/or in a local controller. AWS IoT Greengrass is designed to operate in disconnected environments while supporting complex logic at the edge. This feature helps support use cases such as energy management (i.e. smart charging) and load distribution.

Figure 4: Integration of Greengrass enabled Controller or Charge Point

This approach can assist CPOs as they evaluate whether to manufacture their own chargers, as well as manufacturers exploring whether to provide their own charging services.

To better understand how AWS IoT Greengrass and AWS IoT Core can work together to connect and control Distributed Energy Resources, you can refer to this blog.

Conclusion

In this blog post, we presented two popular implementation patterns for building Charging Station Management Systems (CSMS) on AWS and we discussed how to enhance them using AWS IoT Services. Companies are already successfully using AWS Services to power their CSMS solutions, and help reduce operational and infrastructural costs. Regardless of the chosen pattern, AWS provides a robust and scalable cloud for building CSMS solutions. However, every organization’s needs are unique. Get in touch with your AWS Account manager and request a specialist to help on your project to build or modernize your CSMS!

[1] https://www.iea.org/reports/global-ev-outlook-2024/executive-summary