November 11, 2021
If you think that EV charging is just about connecting a cable from a mains source to a vehicle — you’re wrong!
There’s much more to it. And just as EV technology advances, so does charging technology. Companies are getting creative to improve the EV charging experience for drivers. This is due to the fact that many early adopters of EVs have been frustrated by a large number of apps, slow registration processes, and the number of errors that occur during charging.
But those days are finally behind us. Why? Because networked chargers are now connected to central cloud systems and continuously communicate with the Charging Point Operator (CPO). The CPO has a variety of services, monitoring systems, features, etc. connected remotely. This has opened the door to many technological advancements, such as mobile apps, RFID cards, and contactless charging.
The most common way to connect a charge point with a central cloud system for EV charging is to connect an Open Charge Point Protocol (OCPP) to the internet.
With the introduction of OCPP 1.6, there are two different types of OCPP:
JSON is more compact and runs over Websockets. It also has much better diagnostics capabilities. Receiving and sending data with JSON is simple as it uses HTTP requests.
SOAP is less compact, more complicated, and overall more difficult to maintain.
A comment in Stack Overflow sums it up nicely: “Nowadays SOAP is complete overkill, IMHO. It was nice to use it, nice to learn it, and it is beautiful we can use JSON now.” Of course, that’s only one opinion, but it’s one that we share here at Ampcontrol. As most major charge point manufacturers use OCPP clients, the role of the CPO or operator of the central system is to have a full OCPP implementation according to the OCPP guidelines. Using a non-OCPP software system can lead to expensive adaptations later on and is not advised.
The protocol is used for a large number of reasons. OCPP allows you to authorize an EV driver on a certain charging station, receive meter value (for example, Wh) during a charging process, and allows the operator to update a charger’s firmware.
Messages often include information about connectorId, chargePointId, transactionID, and other fields.
Every interaction starts with a request from the client (chargePoint) or server (central system), for example:
StartTransaction.req(connectorId, idTag, meterStart, timestamp, [reservationId]).
The other side (server or client) responds with a confirmation message such as:
In the above example, we just started a charging process for one charging station.
Every message contains a JSON file as below:
The beauty of OCPP 1.6 and beyond, is the capability to implement smart charging for electric vehicles. Smart charging means that the central system can send load profiles or charging commands to the charge point. Smart charging is mostly used for load balancing, peak reductions, cost-based optimizations, or similar.
Therefore, with OCPP, the central system sends the message SetChargingProfile.req to the charge point. After receiving the load curve, the charging point sends a setChargingProfile.conf to confirm that the device received and accepted the profile. The charging station will follow these “instructions”.
As well as the “typical” information such as connectorId and transactionId, the SetChargingProfile.req contains a part csChargingProfiles that specifies the charging profile and how the charging point must use the load profile.
Below you will find an example of a csChargingProfiles sent from the central system to a charge point.
Below you will find an overview to get a better understanding of the instructions:
Identifier of the load curve
Defines the purpose of the schedule.
TxProfile: when related to the current charging event (transaction).
TxDefaultProfile: when not related to the current charging event.
ChargePointMaxProfile: to configure the maximum power available on the entire chargePoint
Contains the charging profile information such as start, stop, duration, and the actual profile (time series
Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values.
List of ChargingSchedulePeriod elements defining maximum power or current usage over time (that’s the charging profile!). Each element contains startPeriod, limit (W or A), and numberPhases (optional)
If you already have or plan to use an OCPP backend, one of the best ways to generate charging profiles is to use the Ampcontrol app.
The process is simple:
With Ampcontrol you can set your optimization goal (e.g., peak load reduction) for each charging location or customer. The best thing is, it provides you with the correct format automatically. Every profile is sent as csChargingProfiles for your OCPP server.
The key takeaways from this article are:
Learn more about smart charging with OCPP backend here.
Ampcontrol is a cloud-based software that seamlessly connects to charging networks, vehicles, fleet systems, and other software systems. No hardware needed, just a one-time integration.
Charging point operators can use both OCPI and OCPP to develop more extensive and efficient charging networks, discover about the topic here.
The decision to use V2G technology with your electric school bus fleet depends on several factors, including charging infrastructure availability. Discover more here.