ISO 15118-2 Protocol

IEC 61851 standard

In order to understand the ISO 15118-2 Protocol, it is important to first mention the IEC 61851 standard that defines the use of this protocol. This section describes the standard and how ISO 15118-2 is linked to it.

The IEC 61851 - Electric vehicle conductive charging system [1] standard defines the characteristics of on-board and off-board equipment for charging electric road vehicles at standard AC supply voltages up to 1000 V and at DC voltages up to 1500 V.

In other words, the ISO 15118-2 Protocol is responsible for defining the digital communication layer between the EV and EVSE for the DC charging mode when System C is applied.

ISO 15118-2 Protocol

ISO 15118-2 (Road Vehicles – Vehicle to grid communication interface) [3] specifies the digital communication protocol between Electric Vehicles (EV), including Battery Electric Vehicles and Plug-In Hybrid Electric Vehicles, and the Electric Vehicle Supply Equipment (EVSE). As the communication parts of this generic equipment are the Electric Vehicle Communication Controller (EVCC) and the Supply Equipment Communication Controller (SECC), ISO 15118-2 describes the communication between these components.

Although ISO 15118-2 is oriented to the charging of electric road vehicles, it is open for other vehicles as well. As part of the Combined Charging System (CCS), ISO 15118-2 covers wired (AC and DC), wireless charging applications and enables the integration of EVs into the smart grid (V2G - vehicle-to-grid).

ISO 15118-2 allows the EV and charging station to dynamically exchange information based on which a proper charging schedule can be (re-)negotiated. Smart charging applications calculate an individual charging schedule for each EV by using the information available about the state of the electrical grid, the energy demand of each EV, and the mobility needs of each driver (departure time and driving range). This way, each charging session perfectly matches the capacity of the grid to the electricity demand of simultaneously charging EVs.

ISO 15118-2 also comes with a feature called Plug & Charge. Plug & Charge deploys several cryptographic mechanisms to secure this communication and guarantee the confidentiality, integrity, and authenticity of all exchanged data. This is achieved by using the Transport Line Security (TLS) protocol.

According to the protocol, the EV charging process is separated into eight functional groups [3] as shown in Table 1.

Message sequence for an ISO 15118-2 DC charging session

The charging process for a DC charging session carried out by ISO 15118-2 [4] is illustrated in Figure 1. The entities that carry out certain actions, such as sending or receiving messages and opening or closing contactors, are illustrated in the boxes at the top. States A, B, and C relate to certain voltage levels measured by the charging station and are defined in IEC 61851. ISO 15118-2 builds and expands on IEC 61851 and enables digital communication between EVCC and SECC, which starts as soon as the duty-cycle of the pulse width modulation (PWM) signal is set to 5%, as defined in IEC 61851 [2].

Message sequence for an ISO 15118-2 AC charging session

The charging process for a AC charging session carried out by ISO 15118-2 [4] is illustrated in Figure 2. The entities that carry out certain actions, such as sending or receiving messages and opening or closing contactors, are illustrated in the boxes at the top. States A, B, and C relate to certain voltage levels measured by the charging station and are defined in IEC 61851. ISO 15118-2 builds and expands on IEC 61851 and enables digital communication between EVCC and SECC, which starts as soon as the duty-cycle of the pulse width modulation (PWM) signal is set to 5%, as defined in IEC 61851 [2].

ISO 15118-2 Protocol implementation in Typhoon HIL toolchain

Although IEC 61851 defines that the EVCC and SECC communicate using ISO 15118-2 through Power Line Communication (PLC) the protocol itself is Ethernet-based, and as such is implemented in the Typhoon HIL toolchain. It is supported by the following Typhoon HIL devices: HIL402, HIL404, HIL602+, HIL604, and HIL606. To convert the Ethernet to PLC, additional modems, such as the Green Phy module, can be used.

The Electric Vehicle side communication is implemented using the ISO 15118-2 EVCC component located in the Communication → EV charging → ISO 15118 folder in the Schematic Editor Library.

The Supply Equipment side of communication is implemented using the ISO 15118-2 SECC component located in Communication → EV charging → ISO 15118 folder in the Schematic Editor Library.

ISO 15118-2 EVCC component

The ISO 15118-2 EVCC component implements the EV side of the protocol. It is important to specify that the component implements only the communication interface and not the controller itself. In other words, the component is used only to relay the necessary messages between the EVCC and SECC. The controller (or logic) part is left to the user to implement using Signal Processing components.

The ISO 15118-2 EVCC component is shown in Table 3.

Table 3. ISO 15118-2 EVCC component

component	component dialog window	properties
		Connection type Medium type Service category Payment options Energy transfer mode Perform welding detection Pre-charge voltage accuracy Charge parameters DC Charge parameters AC Execution rate Logging level Import folder with certificates Imported folder path Path type

Component parameters are explained in Table 4

{ 
    "departure_time": {"value": 0,
                       "include": True},
    "maximum_current_limit": {"value": 10,
                              "multiplier": 0},
    "maximum_voltage_limit": {"value": 100,
                              "multiplier": 0},
    "maximum_power_limit": {"value": 1000,
                            "multiplier": 0,
                            "include": True},
    "energy_capacity": {"value": 1000,
                        "multiplier": 0,
                        "include": False},
    "energy_request": {"value": 1000,
                       "multiplier": 0,
                       "include": False},
    "full_soc": {"value": 100,
                 "include": True},
    "bulk_soc": {"value": 80,
                 "include": True},
    "target_voltage": {"multiplier": 0},
    "target_current": {"multiplier": 0},
    "time_to_full_soc": {"multiplier": 0},
    "time_to_bulk_soc": {"multiplier": 0}
}

{
    "departure_time": {"value": 0,
                       "include": True},
    "eamount": {"value": 10,
                 "multiplier": 0},
    "max_voltage": {"value": 10,
                     "multiplier": 0},
    "max_current": {"value": 1000,
                     "multiplier": 0},
    "min_current": {"value": 0,
                     "multiplier": 0}
}

Charge parameters property value

Charge parameters are used to define the EV specification and ratings. These parameters are used across different request messages such as ChargeParameterDiscoveryReq, PowerDeliveryReq, PreChargeReq and CurrentDemandReq, in case DC charging is chosen, or ChargeParameterDiscoveryReq, PowerDeliveryReq and ChargingStatusReq, in case AC charging is chosen. Some of these parameters are optional and some are mandatory. The definitions are listed in Table 5.

The Charge parameters property is defined as a Python dictionary with pre-defined fields. All of these fields are also dictionaries with the fields value, multiplier and include. The presence of these fields correlate to the parameter itself. If the parameter is optional, the include field is mandatory, if the parameter is of type PhysicalValue the multiplier is mandatory, and if the property is static, the value field is mandatory.

Static parameters are those that are not changed during the charging process, such as Maximum current limit, Maximum voltage limit, and Full SoC, in case DC charging is chosen, or EAmount, Max Voltage, Max Current, and Min Current, in case AC charging is chosen. On the other hand, dynamic properties change value during the whole charging process. The dynamic properties are Target voltage, Target current, Time to full SoC, and Time to bulk SoC, in case DC charging is chosen. These values are specified by the input terminals on the component.

PhysicalValue is a specific type defined by the ISO 15118 standard and it consists of value, multiplier and unit. The value is a short type (-32768 - 32767) and the multiplier is byte (-3 - 3). The real value is calculated using the formula:

value * 10 ^ (multiplier)

{
    "value": 0,
    "include": False
}

{
    "value": 10,
    "multiplier": 0
}

{
    "value": 100,
    "multiplier": 0
}

{
    "value": 1000,
    "multiplier": 0,
    "include": True
}

{
    "value": 1000,
    "multiplier": 0,
    "include": False
}

{
    "value": 1000,
    "multiplier": 0,
    "include": False
}

{
    "value": 100,
    "include": True
}

{
    "value": 80,
    "include": True
}

{
    "multiplier": 0
}

{
    "multiplier": 0
}

{
    "multiplier": 0,
    "include": False
}

{
    "multiplier": 0,
    "include": False
}

{
    "value": 10,
    "multiplier": 0
}

{
    "value": 10,
    "multiplier": 0
}

{
    "value": 10,
    "multiplier": 0
}

{
    "value": 0,
    "multiplier": 0
}

Input/Output terminals and State values

The Signal Processing signals are passed to and from the ISO 15118-2 EVCC component using its terminals.

ISO 15118-2 EVCC component basic logic

Even though the ISO 15118-2 EVCC component implements only the protocol interface and the controller logic is defined externally using Signal Processing components, some basic logic still exists. This logic defines when the new session starts, when it is closed and some state transitions.

When the simulation starts, the component will initialize a new communication session only when PP = PP_STATE_CONNECTED and CP = CP_STATE_B.

The component will issue a session stop message if any of the following conditions are met: PP != PP_STATE_CONNECTED, CP = CP_STATE_ERROR, EVChargeComplete = True.

When DC charging, the transition from Pre-charge to Current Demand will occur when the difference between the EV Target Voltage and the EVSE Present Voltage is less than (or equal to) the Pre-charge voltage accuracy defined in the component property.

ISO 15118 EVCC example

An example on how to use the ISO 15118-2 EVCC component can be found in the Examples Explorer, under communication protocols → iso 15118 → electric vehicle charge controller.

In this example, the EV part is modeled as a simple battery and a main contactor. The EVSE side is modeled as a Signal controlled Current source. The PP and CP detection circuit is modeled according to the IEC 61851 standard, without the PWM duty-cycle and frequency measurement. Basic voltage levels are used.

The EV charge controller logic is implemented following the IEC 61851 diagrams for Normal Start up, Normal Shutdown and Emergency Shutdown.

ISO 15118-2 SECC component

The ISO 15118-2 SECC component implements the SE side of the protocol. It is important to specify that the component implements only the communication interface and not the controller itself. In other words, the component is used only to relay the necessary messages between the SECC and EVCC. The controller (or logic) part can be implemented separately using Signal Processing components.

The ISO 15118-2 SECC component is shown in Table 6.

Table 6. ISO 15118-2 SECC component

component	component dialog window	properties
		Medium type EVSE ID Supported energy modes Supported payment options Free service Notification maximum delay Station parameters Execution rate Logging level Include isolation status Import folder with certificates Imported folder path Path type Metering receipt required

Component parameters are explained in Table 7.

{
    "country_code" : "FR", 
    "operator_id" : "A23", 
    "power_outlet_id": "45B*78C" 
}

["AC three phase core", 
"AC single phase core"]

{ 
    "max_current": {"value": 32,
                    "multiplier": 0},
    "nominal_voltage": {"value": 230,
                        "multiplier": 0},
    "maximum_current_limit": {"value": 32,
                    "multiplier": 0},
    "maximum_voltage_limit": {"value": 230,
                    "multiplier": 0},
    "maximum_power_limit": {"value": 20000,
                    "multiplier": 0},
    "minimum_current_limit": {"value": 0,
                    "multiplier": 0},
    "minimum_voltage_limit": {"value": 0,
                    "multiplier": 0},
    "current_regulation_tolerance": {"value": 20,
                    "multiplier": 0,
                     "include": True},
    "energy_to_be_delivered": {"value": 100,
                    "multiplier": 0,
                     "include": True},
    "peak_current_ripple": {"value": 32,
                    "multiplier": 0},
    "present_current": {"multiplier": 0},
    "present_voltage": {"multiplier": 0}
}

Station parameters property value

Station parameters are used to define the SE specification and ratings. These parameters are used across different request messages such as ChargeParameterDiscoveryRes, PowerDeliveryRes, and ChargingStatusRes for AC charging, and ChargeParameterDiscoveryRes, PowerDeliveryRes, PreChargeRes, and CurrentDemandReq for DC charging. Some of these parameters are optional and some are mandatory.

The Station parameters property is defined as a Python dictionary with pre-defined fields. All of these fields are also dictionaries with the fields value, multiplier and include. The presence of these fields correlate to the parameter itself. If the parameter is optional, the include field is mandatory, if the parameter is of type PhysicalValue the multiplier is mandatory, and if the property is static, the value field is mandatory.

Static parameters are those that are not changed during the charging process, such as Max Current, and Nominal Voltage for AC charging, or Maximum Current Limit, Maximum Voltage Limit, Maximum Power Limit, Minimum Current Limit, Minimum Voltage Limit, Current Regulation Tolerance, Energy To Be Delivered, and Peak Current Ripple, for DC charging. On the other hand, dynamic properties change value during the whole charging process. The dynamic properties are Present Voltage and Present Current for DC charging. These values are specified by the input terminals on the component.

PhysicalValue is a specific type defined by the ISO 15118 standard and it consists of value, multiplier and unit. The value is a short type (-32768 - 32767) and the multiplier is byte (-3 - 3). The real value is calculated using the formula:

value * 10 ^ (multiplier)

{
    "value": 230,
    "multiplier": 0
}

{
    "value": 32,
    "multiplier": 0
}

{
    "value": 32,
    "multiplier": 0
}

{
    "value": 230,
    "multiplier": 0
}

{
    "value": 20000,
    "multiplier": 0
}

{
    "value": 0,
    "multiplier": 0
}

{
    "value": 0,
    "multiplier": 0
}

{
    "value": 20,
    "multiplier": 0,
    "include": True
}

{
    "value": 100,
    "multiplier": 0,
    "include": True
}

{
    "value": 32,
    "multiplier": 0
}

{
    "multiplier": 0
}

{
    "multiplier": 0
}

Input/Output terminals and State values

The Signal Processing signals are passed to and from the ISO 15118-2 SECC component using its terminals.

ISO 15118-2 SECC component basic logic

Even though the ISO 15118-2 SECC component implements only the protocol interface and the controller logic is defined externally using Signal Processing components, some basic logic still exists. This logic defines when the server will be started and when it will be forcefully closed.

When the simulation starts, the server will initialize only when PP = PP_STATE_CONNECTED and CP = STATE_C.

If the session is active and PP = PP_STATE_DICONNECTED or PP = PP_STATE_ERROR or CP = STATE_A or CP = CP_STATE_ERROR the connection will be forcefully closed.

ISO 15118-2 Protocol message logging

ISO 15118-2 provides three different logging outputs for logging messages.

Console output directs logging messages from the system to stdout (standard output). The messages displayed on the standard output can be seen if the HIL is connected via serial communication to a PC and an SSH client software (e.g. PuTTY) is used to display the console.

File output directs logging messages from the system to the text file "iso15118.log", which, after the program is finished, can be found on the HIL at the path "/mnt/ext_files/iso15118/iso15118.log". One way to access the text file is through the WinSCP software.

UDP output directs logging messages from the system to the UDP broadcast port. In order to receive the messages, it is necessary to run the script "\examples\models\communication protocols\iso 15118\electric vehicle charge controller\udp log receiver.py" from the terminal on the computer before the model from Schematic Editor is compiled and run in HIL SCADA. For message reading to be possible, the HIL and the computer must be on the same broadcast address (they must be on the same subnet and must be networked with an Ethernet connection). Messages can be read on several different computers that are connected to the same broadcast address as the HIL device.

Virtual HIL support

Virtual HIL currently does not support this protocol. When using a Virtual HIL environment (e.g. when running the model on a local computer), inputs to this component will be discarded and outputs from this component will be zeroed.

References

1. International Electrotechnical Commission (IEC), "IEC 61851, Electric vehicle conductive charging system - Part 1: General requirements", 2010, pp. 14
2. International Electrotechnical Commission (IEC), "IEC 61851, Electric vehicle conductive charging system - Part 23: DC electric vehicle charging station", 2014, pp. 33-70
3. International Organization for Standardization (ISO), "ISO 15118, Road vehicle - Vehicle to grid communication interface - Part 1: General information and use-case definition", 2013, pp. 1-45
4. International Organization for Standardization (ISO), "ISO 15118, Road vehicle - Vehicle to grid communication interface - Part 2: Network and application protocol requirements", 2014, pp 11-104
5. M. Multin, "ISO 15118 as the Enabler of Vehicle-to-Grid Applications," 2018 International Conference of Electrical and Electronic Technologies for Automotive, 2018, pp. 1-6, doi: 10.23919/EETA.2018.8493213.