Most EV charger manufacturers are delivering products that can share data to a cloud layer. Most of those manufacturers are also making sure to provide this data through an open communication protocol in an attempt to adhere to informal open standards for communication. This data sharing protocol, known as the Open Charge Point Protocol (OCPP), has matured at pace with the evolving Electric Vehicle Supply Equipment (EVSE) market, however, now that the protocol is in its 2.0 revision, the way it is being implemented and the expectations of the market are not always equal.
The image below depicts the protocol; the charging stations to the left, communicating to a central management platform, through OCPP. In theory, such a cloud platform can be designed with expectations of some minimum charging transaction and status data being shared. Charge point operators (CPO) can get critical status details, and energy consumption data that is found in transaction details of the protocol, to do great things like charge scheduling for energy cost avoidance. The EV drivers can also get valuable information, often through a phone app that reports the vehicle state of charge. All of this seems so simple, and simple images help sell complex solutions.
In reality, the effort to get a charger sending its data to a cloud platform doesn’t always feel so “open”. To send data to a cloud platform, a charger must be equipped with a network interface card, or network gateway (cellular modem, ethernet adapter, etc). The OEM manufacturer likely needs to be able to send OCPP data in one direction, and proprietary diagnostic data in another, often through a separate secure WebSocket connection. To get a charger initiated and commissioned, having both of those data streams pointed to the OEM’s backend cloud services allows them to control the onboarding and initialization process. Critical firmware patches can be downloaded to the charger on the first power cycle, so the customer starts their experience with the latest charger bug fixes in place. Since the OEM doesn’t know who your cloud service provider maybe (if not them), they are inclined to have each charger’s OCPP data stream pointed to them as well.
OCPP Data Redirection
You are the consumer, and you want your data, so of course, you made a charger selection that advertises OCPP integration. However, when you go to send your charging data to a third-party cloud EV service provider (EVSP) you find that the EVSP can’t actually go get your data themselves. You need to redirect the OCPP data to your EVSP’s backend URL and upload a certificate to the charger that authorizes this data to flow to the EVSP. How do you do that? Whose responsibility is that? Since the data goes to the OEM’s backend, out of the box, chances are you’ll need their help.
If the OEM’s operator manual simply directs you to an online portal or customer support center, which will redirect the data freely, it may be just a small inconvenience in the process. If they have a phone app, or way to redirect through the local charger itself, even better. However, be wary of an OEM that first tries to motivate you into leveraging their own EVSP solution, or worse charges you a fee to take your data to someone else.
Networks and How
Before you can get your charging data, you need to establish the IoT pipework to transmit the data. If you have charger locations that prohibit local area network connections (rural charging?), then you have likely searched for chargers with onboard SIM/cellular modems. This does provide a lot of flexibility in where you place a charger, and the distance from WAN/LAN technologies, but it introduces other problems.
Cell data plans are not cheap, and when enabled on a flexible rate structure, they can become exponentially so; imagine a charger needing hundreds of megabytes of data for software and firmware patches due to manufacturer defects. Why should you pay twice for their mistake? Who foots the bill? Further, when an OEM designs a charger with a cellular modem, they don’t often get the flexibility to point to OCPP and vendor-specific data streams in two different locations. You will then find that both data streams flow through the OEM's backend servers, and they simply bounce/redirect the OCPP channel to your desired third-party EVSP. If you are a customer with a data security requirement, you need to know where your data is flowing.
Even if you’re able to connect the charger directly into your network, the OEM will now require firewall access to retrieve either data stream. Who is validating the security vulnerabilities, and who is responsible for being a steward to the charging data? The OEM, EVSP, or you?
Vaguely Standard
One of the great advantages of having IoT-connected devices is that they can call you when they need support or repair. When you manage a large fleet of chargers it’s easier to know when one is out of service, rather than combing the fleet at intervals. You will likely want smart monitoring software, that can receive and interpret alarms and status codes, and report them to operations teams. You would also likely want that list of alarms to not be overly complex and tied to proprietary charger diagnostics.
The OCPP does a good job of trying to require OEMs to adhere to some standard list of alarms. However, in trying to standardize a status code for chargers, that may each be designed with a wildly different assortment of electrical components and layout. The result is a list of very generic and vague status codes; for example “chargerFaulted” which is one of several alarm notifications in the OCPP. Imagine you get that status code displayed on the screen, or a text on your phone that reads, “Charger 3 – Status = Faulted”. If you have a warranty, an OEM with a large fleet of service persons, and a backup charging plan, you may not worry at all. If you have none of those things, “Status = Faulted” doesn’t tell you much about where to begin your repair prognosis. Is it a blown fuse? Is it a burned-up resistor? Maybe the flux capacitor is experiencing turbulent axial delamination?
It’s not all dreary and scary, and the fact that the market is working towards standards adherence is a wonderful thing. I emphasize these concerns only so that the market consumers make sure their voice is heard, as those standards get established. Make sure you are loud and communicative with your suppliers and partners. Make sure they carry your voice into the standards committee meetings and product development workshops. In the meantime, keep asking questions about how the whole experience and value chain flows for every EV solution you procure.
Within the Hitachi cloud ecosystem, we are focusing on ways to make sure that data is accessible freely. We are working to make sure that the necessary operational details are delivered at the pace and complexity that your operations require. We are also delivering service options that expand the overall capabilities of a digital monitoring platform, wherever you choose to procure it. If you’d like to know more about how we can help you select the right charging hardware, software, and cloud service ecosystem elements, tailored to your exact fleet needs, please reach out to our team at Hitachi at HitachiEBD@hal.hitachi.com.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Read More
