At the first CharIN Testival saw interoperability testing for ISO 15118 onboard charge controllers.

‍

Whether you are a passionate RISE V2G aficionado already, or you are looking for a way to get started with ISO 15118 and wondering how to set up a test system: this is the article for you. Elaad hosted its first-ever CharIN Testival (video included) event at its Arnhem headquarters on Oct 30 and 31, 2019. There, I visited with representatives from KOSTAL who were testing their charging station setup against various electric vehicles (EVs). KOSTAL is a reputable 1st Tier supplier for the automotive industry and has been selected as a system supplier for one of the largest car manufacturers in Europe. The event was full of testing opportunities. KOSTAL brought the test setup they use in their test labs to test On-board Battery Chargers (OBCs) of major EV manufacturers.

Fun fact: KOSTAL uses RISE V2G, the only open-source implementation of ISO 15118, to successfully conduct their tests. I’ve included a few videos within this post to share the complete hardware and software setup with you.

The test setup

The test setup consists of three main components:

1. The graphical user interface (GUI) on a laptop that allows the user to control and view the complete charging communication process between the EV communication controller (called EVCC) and the charging station’s communication controller (called SECC). The “SE” in SECC is short for Supply Equipment and represents the electrical device that controls the power flow to the EV.
2. The On-board Battery Charger (OBC) of the EV, which contains the EVCC.
3. The “EVSEpi” board KOSTAL created, which is a mainboard that contains several devices needed for testing charging communication. This board also contains the SECC that runs on RISE V2G. We’ll get into this more soon.

In the video below, the OBC is hidden beneath a piece of paper as the car manufacturer who provided this controller does not allow public demonstration.

This video shows the technical setup, with a laptop running the GUI to control the charging communication process on the left, the OBC located in the middle, and the EVSEpi board on the right. Note that there is no real power flow taking place, but everything else is exactly as it would be in a real charging scenario.

‍

KOSTAL test setup with RISE V2G at 1st CharIN Testival

The EVSEpi board

KOSTAL invented the EVSEpi board to serve as a simulated charging controller that replicates the behavior of a charging station. It includes the following elements:

• Powerline communication (PLC) chip from Qualcomm (QCA7000)
• Analog-to-digital converter (ADC), which is an electronic device that converts an input analog voltage or current to a digital number representing the magnitude of the voltage or current
• Controller Area Network (CAN bus) controller, which is usually used for the communication exchange of information between various microcontrollers within a vehicle
• Raspberry Pi Compute Module 3, which runs the RISE V2G stack (ISO 15118) on a 1.2 GHz quad-core processor
• Further peripheral equipment that you’ll find on a Linux machine, like Ethernet RJ45, HDMI, USB, etc.

The Raspberry Pi operating system (Raspbian) runs on a MicroSD card, which hosts a Debian GNU/Linux.

Why we need the QCA7000 Chip

At the beginning of a wired charging communication based on ISO 15118, we need to set up a data communication link. This is where the PLC comes in. To avoid the well-known crosstalk problem on PLC links, ISO 15118-3 describes a protocol that eliminates this problem. The solution is called SLAC, which is short for Signal Level Attenuation and Characterization. In order to perform the SLAC process, both EVCC (the on-board charger in our test setup) and SECC (running on the Raspberry Pi Compute Module 3) need to be connected to a HomePlug GreenPHY-compliant modem. That is exactly what the QCA7000 chip is for. The implementation of the SLAC process is based on open-plc-utils, an open-source power line toolkit provided by Qualcomm to ease working with their PLC chips.

Once the data link has been established using SLAC and the QCA7000 chip, the EVCC initiates the high-level communication via ISO 15118 with the SECC.

In order for the OBC (the on-board controller that is usually within the EV) to accept the simulated charging station, KOSTAL also needed to implement a pulse-width modulation (PWM) signal.

Why we need PWM

Before the charging process can start, an analog signalling communication takes place between the EV and the charging station using the Control Pilot (CP) pin which is integrated into the charging plug. The CP pin allows for distinguishing between different connection states by measuring the electrical resistance in Volts. This takes place within the cable.

IEC 61851 defines an analog pulse-width modulation (PWM) signalling mechanism.  PWM is a modulation technique used to encode information – such as the maximum allowed charging current – into a pulsing signal. This allows the charging station to communicate the maximum available charging current to the EV by applying a pulse-width modulation of the CP signal. The charging station controls the PWM signal, whereas the EV controls the voltage (and therefore the connection state).

In Figure 1, the voltage is illustrated on the y-axis and the time is illustrated on the x-axis. The most important CP states are:

• State A (+12 V)
  The EV is not connected to the charging station
• State B (+9 V)
  The EV is connected to the charging station but not yet ready for charging (a resistor in the charge plug pulls the voltage down to 9 V)
• State C (+6 V)
  The EV is connected to the charging station and ready for charging (another resistor in the cable called S2 pulls the voltage further down to 6 V)

‍

The voltage amplitude provided to the outlet of the charging station is controlled by turning the switch between supply and load on and off at a very high rate (1 kHz). The longer the switch is turned on compared to the off periods, the higher the available charging current. This proportion(between time it is turned off and time it is turned on) is called a “duty cycle” and expressed in a percentage. On the right side of Figure 1, you can seethe mapping between PWM duty cycles and available charging currents.

IEC 61851 defines that at a 5 % duty cycle, external digital communication (e.g. via the ISO 15118 protocol) must be applied to control the charging current.

This is exactly what this PWM module on KOSTAL’s EVSEpi board is doing: making sure the EVCC and SECC can properly communicate via ISO 15118 by applying a +/-12 V PWM signal with a 5% duty cycle on the CP pin. For more information on PWM signalling, see section 2.3 of the ISO 15118 Manual. Sign up for a free excerpt of the manual.

Why we need an ADC

The EVSEpi board also displays the voltage swing on the CP line via an analog-to-digital converter (ADC), which enables the board to exactly determine the CP state. This way, KOSTAL can distinguish between the states CP_STATE_A_IDLE (+12 V), CP_STATE_B_VEHICLE_CONNECTED (+9 V), and CP_STATE_C_VEHICLE_CHARGE_REQUEST (+6 V), as illustrated in the video below.

Demonstration of Control Pilot (CP) state change and illustration in KOSTAL graphical user interface (at 1st CharIN Testival)

Where RISE V2G comes into play

The conversion from an analog signal to digital signal happens through an additional circuit that delivers the PWM duty cycle as an interrupt. KOSTAL needed to write a kernel driver to start the measurement precisely at the rising edge of the duty cycle. Furthermore, different kinds of charging cables can be simulated via software by providing a proximity pilot (PP) pin. All in all, the EVSEpi board can do pretty much anything a charging station can do, except the high-voltage power transfer.

KOSTAL runs RISE V2G as a completely self-sufficient process on the EVSEpi board that manages the high-level communication (at 5 % duty cycle), all according to ISO 15118. The first step is a mutual discovery of IP addresses and ports using the SECC Discovery Protocol, called SDP for short. To get a glimpse at the complete communication sequence specified in the ISO 15118 standard, have a look at the ISO 15118 Manual.

The video below shows the simulation of a charging session using the Web UI KOSTAL programmed for their testing purposes. At the beginning of the video, the PLC modem is not active (the “PlcModemAktivieren” checkbox on the right is not checked and the AAG graph on the left is empty). This means that no ISO 15118 messages have been exchanged so far. These messages are listed in the “V2G” part on the left screen.

You will observe the following actions within this video:

• 0:30: The PLC modem is activated on the right.
• 0:37: The attenuation profile of the PLC signal, which is needed for the SLAC process, is illustrated in the AAG graph on the left.
• 0:44 – 01:02: The EVCC and SECC exchange ISO 15118 messages during a simulated charging session, starting with an SDP request and stopping with a SessionStopResponse.
• 01:05: More details of the SessionStopRequest message that the EVCC sends to the SECC. The field “ChargingSession” is set to “PAUSE”, indicating that the EV would like to pause (but not yet terminate) the charging session. On the right side of the screen, you see three input fields that can pause a charging session: PauseResumeAmount, PauseTimeDefault, and PauseTimeCurrent. The first input field indicates how many pauses shall be simulated, the second indicates the length of the pause, and the third displays how many seconds are left until the pause ends.
• 01:14: Here, you can see that the first SessionSetupResponse message, which the SECC sent to the EVCC, contains the field “ResponseCode” (set to “OK_NEW_SESSION_ESTABLISHED”). Once the pause ends and the charging session resumes, the communication session starts again. But, this time the EVCC will communicate the SessionID from the previous communication session. This should prompt the SECC to send a SessionSetupResponse message with a response code set to “OK_OLD_SESSION_JOINED”.
• 01:33: The EVCC receives a SessionSetupRespone from the SECC with the response code set to “OK_OLD_SESSION_JOINED”.
• 01:45: The EVCC terminates the communication session by setting the field “ChargingSession” to “TERMINATE”.

‍

An ISO 15118 charging communication session using  RISE V2G as the ISO 15118 software stack on the KOSTAL charging controller

The RISE V2G code running on the Raspberry Pi Compute Module 3 is doing all the magic on the SECC side – the code has not been touched by KOSTAL.

This is a great opportunity to showcase the production-ready and mature nature of RISE V2G to anyone who is interested in using this open-source software for their testing purposes – or in deploying it within a charging station in the field.

What did you think of this article? Was the information new to you? If so, was it presented in an understandable way? I’d very much appreciate a quick email so I can continue refining these articles and resources for the EV community at large. Together, we can demystify tough concepts and all of us (and the industry as a whole) will be better off for it. I’m at marc.mueltin@v2g-clarity.com and hope to hear from you soon.

‍
One more thing…

I plan to get more involved with SLAC by implementing an open-source software running the SLAC procedure (in Python) and writing a detailed article on exactly how SLAC works. Stay tuned for that and let me know if that would be of value for you.