ISO 15118-20 Protocol

ISO 15118-20 Protocol

ISO 15118-20 protocol is a specific part of the ISO 15118 standard and it is an extension of the ISO 15118-2 Protocol.

Message sequence for an ISO 15118-20 DC charging session

The charging process for a DC charging session carried out by ISO 15118-20 [2] is illustrated in Figure 1.

ISO 15118-20 protocol implementation in Typhoon HIL toolchain

Although IEC 61851 defines that the EVCC and SECC communicate using ISO 15118-20 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 of communication is implemented using ISO 15118-20 EVCC component located in the Communication → EV charging → ISO 15118-20 folder in the Schematic Editor Library.

ISO 15118-20 EVCC component

The ISO 15118-20 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.

Table 1. ISO 15118-20 EVCC component

component	component dialog window	properties
		Medium type Connection type Payment option Import folder with certificates Imported folder path Path type Supported energy service Connector type Control mode Receive Meter Info Perform Welding detection Pre-charge voltage accuracy Execution rate Logging level Charge parameters

{ 
    "maximum_charge_power": {"value": 0, 
                             "exponent": 0},
    "minimum_charge_power": {"value": 0, 
                             "exponent": 0}, 
    "maximum_charge_current": {"value": 0, 
                               "exponent": 0}, 
    "minimum_charge_current": {"value": 0, 
                               "exponent": 0}, 
    "maximum_voltage": {"value": 0, 
                        "exponent": 0}, 
    "minimum_voltage": {"value": 0, 
                        "exponent": 0}, 
    "maximum_energy_request":{"value": 0, 
                              "exponent": 0, 
                              "include": True}, 
    "minimum_energy_request":{"value": 0, 
                              "exponent": 0, 
                              "include": True}, 
    "maximum_v2x_energy_request":{"value": 0, 
                                  "exponent": 0, 
                                  "include": False}, 
    "minimum_v2x_energy_request":{"value": 0, 
                                  "exponent": 0, 
                                  "include": False}, 
    "departure_time": {"value": 0, 
                       "include": True}, 
    "minimum_soc": {"value": 0, 
                    "include": False}, 
    "maximum_supporting_points": {"value" : 1024}, 
    "target_soc": {}, 
    "target_energy_request":{"exponent": 0}, 
    "present_voltage":{"exponent": 0}, 
    "target_voltage":{"exponent": 0}, 
    "target_current": {"exponent":0}, 
    "maximum_discharge_power": {"value": 0, 
    "exponent": 0}, 
    "minimum_discharge_power": {"value": 0, 
                                "exponent": 0}, 
    "maximum_discharge_current": {"value": 0, 
                                  "exponent": 0}, 
    "minimum_discharge_current": {"value": 0, 
                                  "exponent": 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 DC_ChargeParameterDiscoveryReq, ScheduleExchangeReq, DC_PreChargeReq, PowerDeliveryReq, and CurrentDemandReq. Some of these parameters are optional and some are mandatory. Also, the presence of some of these parameters in the table depends on the selected Control Mode and Energy Service. The definitions are listed in Table 3.

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, exponent 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 RationalNumber the exponent 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 Charge Power, Minimum Charge Power, Maximum Charge Current, Minimum Charge Current, etc. On the other hand, dynamic properties change value during the charging process. The dynamic properties are Target SOC, Target Energy Request, Present Voltage, Target Voltage and Target Current. These values are specified by the input terminals on the component.

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

{
    "value": 0, 
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0, 
    "include": True
}

{
    "value": 0, 
    "exponent": 0, 
    "include": True
}

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

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

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

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

{
    "value" : 1024
}

{
    "include" : False
}

{
    "exponent" : 0,
    "include" : True
}

{
    "exponent": 0
}

{
    "exponent": 0
}

{
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0
}

{
    "value": 0, 
    "exponent": 0
}

Input/Output terminals and State values

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

If the value of an output terminal is '-1', that indicates that this particular value isn't used in the message received by the SECC. This applies to optional parameters in messages.

Not all values are acceptable and correct for all terminals. Some of them use integer values, some real and some states. The following list explains how each terminal is supposed to be used:

ISO 15118-20 EVCC component basic logic

Even though the ISO 15118-20 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-20 protocol message logging

ISO 15118-20 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_20/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 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
2. International Organization for Standardization (ISO), "ISO 15118, Road vehicle - Vehicle to grid communication interface - Part 20: 2nd generation network layer and application layer requirements", 2022, pp. 138-240
3. International Electrotechnical Commission (IEC), "IEC 61851, Electric vehicle conductive charging system - Part 23: DC electric vehicle charging station", 2014