“Hello Mr. EV Charger, I’m a flat car battery!” (Part-2)


By enabling interoperability, EV Charging standards ensure that EV owners can charge their cars from any compatible EV Charger. The IEC 61851 standard defines Analog Signalling that ensures electrical safety and facilitates basic communication between the EV Charger and the car. Basic communication includes features such as plug-in detection and readiness to charge. The Combined Charging System 2 includes real-time digital communication over Power Line Communication (PLC), also known as High-Level Communication, which is defined by the ISO 15118 standard. This forms a complete e-Mobility communication system for EV Charging. It ensures that the charging requirements, capabilities and limitations of both the EV Charger and the car are understood and synchronized throughout the charging session. During the charging session, the EV Charger communicates with the car using High-Level Communication. This enables the EV Charger to pass information about the car to backend Charging Management Software (CMS) over the Open Charge Point Protocol (OCPP).


How does an EV Charger know how much energy to pump into a car battery? How does it know that the battery is flat currently so it needs to be charged at maximum current? How does the EV Charger know the time of departure desired by the user? And how does it correctly display the remaining time to charge?


Welcome back to the world of EVSE-EV communications. In the previous (first) part of this article, we discussed the 2 types of communication between the EV Charger and the car. In the Combined Charging 2 system, these are:

1. Analog Signalling (AS), defined by the IEC 61851 standard (the successor of the US SAE J1772)
2. High-Level Communication (HLC), defined by the ISO 15118 standard (the successor of the German DIN SPEC 70121)

In the previous (first) part, we had deep dived into AS. In this (second) part, we take a closer look at how HLC works, and how it is related to AS.

Why HLC?

So, if AS already serves the purpose of handshaking between the EV Charger and the car regarding plug in events, the readiness for charging and negotiation of charging current for the session, then why is HLC required? Are there any features provided by HLC over and above AS?

The short answer is Yes. HLC enables enhanced features, like the exchange of charging parameters between the car and the EV Charger. Like the requested energy and charging current, as well as information like state of charge (SoC) of the battery, remaining time to charge etc. It also opens up the possibility for the Charging Operator to operate a Cloud based (*) billing and payment system that is critical for public charging infrastructure.

(*) Cloud — Most modern EV Chargers are connected to the Cloud, where a Charging Management Software (CMS), that is owned and operated by the Charging Operator, provides high level services like authorization, billing and payment. The CMS links up all EV Chargers under the same operator. Communication between the EV Charger and the CMS uses the Open Charge Point Protocol (OCPP), which is a TCP/IP based de-facto standard led by Charge Point, USA.

HLC Standards

HLC standards for EV Charging were pioneered by the Japanese with their CHAdeMO system. In Europe, the Germans introduced HLC in the CCS2 system with the DIN SPEC 70121 in 2012, that was an interim standard for DC Chargers. However, it did not support AC Charging, Plug & Charge or Smart Charging features. The German standard was later superseded by the ISO 15118 standard in 2014, that covers both DC Chargers and AC Chargers and includes Plug & Charge and Smart Charging enhancements. The CCS2 system that India has adopted is the most prevalent system in Europe.

HLC offers several enhancements over AS, including Smart Charging and Automated Authentication and Authorization mechanisms. Smart Charging allows for cost effective AC or DC charging by scheduling the charging operation during off-peak hours and considering the availability of renewable energy in the grid. It can also optimize charging based on the battery’s State of Health (SoH) and is useful for fleet charging scenarios for balancing power provision. Additionally, HLC allows for quick re-negotiation of charging schedules between the EV Charger and the car in response to unforeseen changes in the grid.

Automated Authentication and Authorization (A&A) mechanisms in HLC can be achieved using External Identification Means (EIM), such as an RFID card or QR code scan from a mobile app with multiple options for spot payment. Alternatively, A&A could be achieved using secure Plug & Charge (PnC), where an E-Mobility contract is signed with the Charging Operator. Digital XML signatures & Digital Certificates installed in the car use TLS security, and the car only needs to be plugged in for the user to be authorized and for automated billing and payment at the backend.

Communicating end points

As for any data communication, at least 2 entities are required for HLC — the EV Charger and the car. Although EV Chargers with multiple charging guns presents a 1-to-many relationship with only one EV Charger and multiple cars, we will consider only the 1-to-1 case for simplicity sake.

In HLC defined by ISO 15118, the communicating end point inside the EV Charger side is called Supply Equipment Communication Controller (SECC) and its counterpart inside the car is called Electric Vehicle Communication Controller (EVCC).

Communicating end points in HLC

So, although loosely saying that the EV Charger and the car participate in HLC is not incorrect, it would be technically accurate to say that the SECC (in the EV Charger) and the EVCC (in the car) participate in HLC.

Data communication model

The SECC (in the EV Charger) and the EVCC (in the car) establish a data communication network by establishing the 7 functional layers as outlined in the well-established ISO/OSI data communication model. As per the model, each layer builds upon the functionality that is provided by the underlying layers, starting with the physical layer at the bottom all the way up to the application layer at the top.

ISO/OSI data communication model (Diagram courtesy: Tesla)

Layers 1 & 2

The physical and data link layers are implemented as per Part-3 of ISO 15118 using Power Line Communication (PLC), that typically uses a HomePlug Green PHY (IEEE1901) modem. At the physical layer (layer 1) the modems at both ends connect to the same physical line of the Control Pilot (CP), over which a high frequency carrier in the 1.8MHz to 30MHz range is transmitted. The carrier wave is modulated with the HLC message data packets, achieving a maximum data rate of 10Mbps.

The CP line therefore is multiplexed across the 2 modes of communication, as follows:
1) AS: +12V/-12V 1000Hz square wave (between the IEC 61851 compliant circuitry at both ends)
2) HLC: 1.8MHz to 30MHz PLC carrier wave, modulated with data message packets (between the SECC and EVCC as per ISO 15118)

The media access/data link layer (layer 2) is managed by the Signal Level Attenuation Characteristic (SLAC) protocol as defined by the HomePlug Green PHY v.1.1.1 specification. SLAC is designed for automotive applications, where multiple EVs could connected simultaneously to an EV Charger. The carrier signal’s attenuation level from each car is measured at the EV Charger during the Association Procedure in order to uniquely determine the identity of the cars. Security is optionally added using public key signature.

The layer 2 SLAC protocol stack is typically provided by HomePlug Green PHY compliant silicon vendors, like Qualcomm. SLAC sets up a reliable and secure frame transfer mechanism between the 2 nodes over the physical medium, guaranteeing error free transfers. During the SLAC initialization procedure, the PLC modem at the SECC (in the EV Charger) and EVCC (in the car) get unique MAC addresses. After the SLAC handshake is successful, the PLC modems at the SECC and the EVCC form a logical network.

Layers 3 & 4

The network layer (layer 3) is an IPv6 stack that layers over the MAC address. DHCP is used for host configuration and ICMPv6 to send network layer error messages. Each node therefore gets an IPv6 address. The transport layer (layer 4) stacks — TCP (reliable), UDP (fast), and optionally Transport Layer Security/TLS (safe) get layered on top of the IPv6 (layer3) stack. TCP provides flow control, congestion control and triggers retransmissions upon error conditions for guaranteed delivery.

Applicability of the different Parts of ISO 15118 to the 7-layered V2G Protocol Stack (Diagram courtesy: Tesla, Switch)

Layers 5, 6 & 7

The V2G Transfer Protocol (V2GTP) is (layer 5/session) layered over the transport layer for session management between the EV Charger (also called “grid side” **) and the car. The presentation layer (layer 6) consists of encoding and decoding between application (XML) format and network Efficient XML Interchange (W3C EXI 1.0) format and negotiating/establishing an application layer protocol along with version number. The application (layer 7) V2G messages that have specific meanings in the context of the charging process/session are communicated between the SECC (in the EV Charger) and the EVCC (in the car) utilizing the completed layers of the underlying protocol stack. Domain Name Service (DNS) and SECC Discovery Protocol (SDP) protocols at layer 7 help resolve addresses and discover the SECC respectively. V2G stacks that implement layer 3 to layer 7 are available as open source as well as proprietary.

Data packet format, with layer-wise headers (Diagram courtesy: Tesla)

Like every layered communication model, each layer adds its own header to the original payload received from its upper layers during transmission. Vice versa during reception — each layer strips off its header before passing on the payload to its upper layers. Now, doesn’t the above description, layering and packet diagram look very familiar!

Before diving deeper into HLC, let us first examine how it is related to AS.

Close relationship — HLC and AS

The lifecycle of a charging session involving the EV Charger and the car consists of the following state sequences, that are managed together by AS and HLC.

· Unmated — EV not yet connected (State-A)

· Mated — EV detected, not ready to charge (State-B)

· Initialize — EV detected, ready to charge (State-C), Initialize HLC

· Cable check — Connector is locked on the car side for safe DC Charging

· Pre-charge — Adjust EV Charger’s output voltage to the car’s battery voltage

· Charge — Control actual power transfer

· Power down — EV still detected, but no longer ready to charge (State-B)

· Unmated — EV no longer connected (State-A)

IEC 61851 that defines AS describes different modes of charging, as follows with the last section in bold of special interest to us:

  • Charging Mode 1 — AC charging from mains over standard 1phase/3phase sockets. Up to 16 A and 250/480 V. No protection device in the charging cable.
  • Charging Mode 2 — AC charging from mains over standard 1phase/3phase sockets. Up to 32 A and 250/480 V. Protection device integrated in the charging cable.
  • Charging Mode 3 — AC charging using dedicated AC charging stations. Mandatory PWM signalling and optional High-Level Communication (HLC)
  • Charging Mode 4 — DC charging using dedicated DC charging stations. Mandatory PWM signalling and mandatory High-Level Communication (HLC)

We can see that mode 4 is the charging mode for DC charging from a DC Charging Station using mandatory AS and mandatory HLC.

IEC 61851 further classifies the Charging mode 4 (above) into 3 systems, as follows with the last section in bold of special interest to us.

  • System A — The physical/data layer is CAN bus A interface. The application layer is defined by IEC 61851–24. (This is used in CHAdeMO system)
  • System B — The physical/data layer is CAN bus B interface. The application layer is defined by the GB/T 27930 standard. (This is used in the Chinese system)
  • System C — The physical/data layer is Power Line Communication (PLC). The application layer is defined by the ISO 15118 protocol. (This is used in the CCS2 system)

We can see that in System C which has been adopted by the CCS2 system, ISO 15118 specifies the usage of Power Line Communication (PLC) for HLC. We can therefore think of IEC 61851 as the “mother” standard that defines the context and the need for ISO 15118 as the “daughter” standard. Needless to say that mother historically precedes daughter.

Initiating HLC

We saw in the previous (first) part how the AS session is initiated by electrically detecting the event of plugging in the car to the EV Charger. So how is the HLC session initiated? Well, it turns out that it is AS itself that initiates HLC! Let us see how.

We had seen that the valid range of PWM duty cycle between the EV Charger and the car is between 10% and 96%. Why these figures, precisely? At 96% duty cycle, we hit the maximum current of 80A as defined by IEC 61851. And at 10%, we are at 6A which is the lowest current rating of any common domestic power outlet. That should have meant that any value of the duty cycle less than 10% (or greater than 96%) should have been invalid. But no! They chose a special value of 5% duty cycle for a very special purpose — to signal the need for HLC.

The 5% duty cycle waveform in AS, that triggers HLC

Hence if the duty cycle is set to 5% in AS, then it is an indication that additional HLC is required. In practice, there is a small tolerance around the 5%, so actual duty cycles could vary between 3% and 7%.

So, while the Control Pilot (CP) and Protective Earth (PE) lines of the EV Charger and the car are connected (mated), and when a 5% duty cycle square wave is detected, it causes the HomePlug Green PHY modems at the SECC (EV Charger) and the EVCC (car) to establish a physical link over the 1.8MHz-30MHz carrier wave signal, thereby establishing layer-1 of the HLC protocol. What an ingenious way to electrically initiate the transition to setup a data communication stack!

Just a trigger, not a participant

It may be worth clarifying here that although AS is responsible for triggering HLC by issuing the 5% duty cycle square waveform on the CP line, once HLC is established between the EV Charger and the car over PLC, AS has no role to play in the data communication session. Like a mother marrying off her daughter and letting her live by herself! Which means that AS is totally transparent to the SECC and EVCC in the context of digital communication, and is separately handled by the EVSE controller (on the EV Charger) and the base controller (on the car), both of which implement the IEC 61851 protocol.

Multiplexing physical lines across AS and HLC modes

SECC (EV Charger) and EVCC (car) are involved only in HLC over PLC carrier wave. They are not involved in AS, although the same physical lines of CP and PE are shared between the 2 modes. Like the mother and the married daughter still share their family car for shopping together, but keep their bags separate! AS is handled through discrete voltage levels and square wave PWM by means of separate analogue circuitry on the EV Charger side (also called “grid side” **) and in the car, as per IEC 61851, as we saw in the previous (first) part of this article.

(**)”grid side” : Now we know why HLC is also commonly known as V2G (Vehicle-to-Grid), and in some instances V2H (Vehicle-to-Home). For the car, the EV Charger represents the front end to the home or/and the grid.

HLC architecture

HLC is a Client/Server protocol, where the EVCC (car) acts as the Client and the SECC (EV Charger) acts as the Server. It is based on a “request — response” mechanism as defined by Part-2 of ISO 15118, that defines a set of V2G request/response messages between the EVCC and the SECC. As per this mechanism, the car always sends request messages and the EV Charger sends back the corresponding response messages.

An example of a request — response message pair illustrating car-initiated V2G messages, is as follows:

Request message (from car) — SupportedAppProtocolReq
Response message (from EV Charger) — SupportedAppProtocolRes

The car sends this request message at the beginning of the charging session to find out the V2G protocol version supported by the EV Charger. All subsequent message exchange is possible only after the both handshake on the protocol version.

A few exceptional messages are triggered by the EV Charger, although not sent by it. As mentioned above, the EV Charger never directly sends a request message. In the exceptional cases, a message sequence is triggered indirectly by the EV Charger by setting a flag in its (previous) response message. The car responds to this by sending a new request message. Hence, request messages are always sent by the car. Renegotiation of the charging schedule when the grid undergoes unexpected demand fluctuations is an example of this exceptional case.

Message Timings

The car sends a new message every 60 seconds at the latest. The EV Charger must respond within 2 (to 5) seconds (depending on the message) to the incoming request. A few messages like CertificateInstall/Update and CableCheck have a larger timeout value.

V2G message sequences

The HLC model consists of various stages of the charging sequence as shown below, which also forms the basis of meaningful grouping V2G messages:

A. Start of charging process

B. Communication setup (meaning HLC)

C. Certificate handling

D. Identification and Authorization

E. Target setting and charge scheduling

F. Charge controlling and rescheduling

G. Value-added services

H. End of charging process

The following table describes V2G messages in more detail, though not exhaustively. The “Req” suffix indicates a request message sent by the car. There will be a corresponding “Res” response message sent by the EV Charger.

V2G message sequences in HLC

From the EVEnergyRequest parameter of the ChargeParameterDiscoveryReq message, the EV Charger comes to know how much energy the car is requesting to transfer into the battery.

From the optional EVRESSSOC parameter of the ChargeParameterDiscoveryReq message, the EV Charger learns the State of Charge (SoC) of the battery (in %).

# From the CurrentDemandReq message it knows how much charging current the (BMS of the) car is requesting.

The user sets the departure time on the car’s dashboard. From the DepartureTime parameter of the ChargeParameterDiscoveryReq message, the EV Charger learns the time of departure desired by the user.

#From the TimeToFullSOC parameter of the ChargeParameterDiscoveryReq message, the EV Charger knows the remaining time to charge.

It looks like some light has started shedding on the basic questions that we set out with! Meanwhile, the optional nature of some of these parameters in ISO 15118 is driven by European GDPR regulations on how much information the user wants to share.

Industry trends

Many advanced features of EVSE-EV communications are getting incorporated into ISO 15118, and commercial products implementing these features are steadily hitting various global markets. Imagine the richness of features that we are going to witness in the near future in emerging economies like India, as EVSE-EV communication tries to cover new scenarios, such as:

  • Plug & Charge — Just plug in the car, and the EV Charger recognizes the owner! No more RFID, QR code, mobile App etc.
  • Smart Charging — Synchronize with the grid through EV Chargers on charging schedules and charging currents of cars based on overall loading conditions of the grid, like charging at off-peak hours
  • Demand-based responsiveness — Dynamically synchronize through EV Chargers the charging of millions of EVs, especially at the time of unforeseen grid power fluctuations to avoid overwhelming the historically shaky grid capacity

At SFO Technologies (the flagship company of NeST group), we test our EV Charger designs using a Battery Communications Simulator. The Simulator works exactly like a car, providing the same connector pins that work on AS as defined by IEC 61851 and capable of the HLC as defined by ISO 15118. Such is the beauty of standardization that compliance during design ensures that the EV Charger will work correctly when deployed in the field with any compliant car model (mechanically, electrically, communication-wise and software-wise).

Specifically, Part-20 of ISO 15118 that was released last year (2022) includes certain futuristic features such as:

  • Bidirectional Power Transfer (BPT) — Feeding the car battery’s power back to the home, or into the grid. Imagine charging the car at off-peak hours and feeding power back (selling) to grid at peak-hours (at better rates)!
  • Wireless Power Transfer (WPT) — Zero contact for power transfer while charging your car! Also called inductive charging, the transmitter coils (source) are encased in a plate embedded on the ground, for instance at a car parking. The receiver coils (load) are installed in the car conveniently close to the battery, which is anyway located at the floor of the chassis in most EV designs. So, one needs to just position the car using the guidance markings, so that the pair of coils align properly and charge by inductive coupling.
  • Automated Connection Device (ACD) — Space-age robotic arms that would avoid the manual operation of plugging in the charging gun to the charging inlet of the car. Pantographs are already popular with bus fleets. This would be useful especially for heavy water-cooled cables of Ultra-fast Chargers, and for autonomous vehicles. Imagine the irony of having to manually charge a driverless car!


From the above concentrate of the wide spectrum of EV Charging standards juice, we can see that AS and HLC combine symbiotically to establish a complete e-Mobility communication system for EV Charging. So, the next time you plug in your electric car to an EV Charger, you will know better that it’s not just all voltages and currents. The software engineer in you can now visualize the 7-layer protocol stacks being loaded at both ends of that cable and V2G message sequences going back and forth even before power starts flowing into your car battery. You will probably smile knowing that the cable that is electrically charging your car is also buzzing with V2G activity literally all the time!

Leave a Reply

Your email address will not be published. Required fields are marked *

Get updates on our Insights

Stay connected with NeST Digital to get timely updates of our thought leadership posts by filling the below details.

Please enable JavaScript in your browser to complete this form.
Please enable JavaScript in your browser to complete this form.

Get in touch with us

2023 © All rights reserved. NeST Digital Pvt Ltd.    |    Legal Disclaimer |    Disclaimer: Fraud Recruitment Offers    |    A NeST Group Company