ISO 15118 Protocol

Description of the ISO 15118 protocol implementation in the Typhoon HIL toolchain.

IEC 61851 standard

In order to understand the ISO 15118 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 is linked to it.

The IEC 61851 - Electric vehicle conductive charging system 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.

The standard defines different charging modes (both AC and DC) for charging the Electric Vehicle (EV). These modes are:
  • Charging Mode 1 - AC charging, EV to mains over standard 1ph/3ph sockets. Up to 16 A and 250/480 V. No protection device in the charging cable.
  • Charging Mode 2 - AC charging, EV to mains over standard 1ph/3ph 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 signaling and optional High Level Communication (HLC)
  • Charging Mode 4 - DC charging using dedicated DC charging stations. Mandatory PWM signaling and mandatory High Level Communication (HLC)
The standard then breaks down the Charging Mode 4 into 3 Systems. These systems differ in both HLC and connector used. These systems that:
  • System A - The physical/data layer is through CAN bus A interface while the application layer is defined in IEC 61851-24 standard.
  • System B - The physical/data layer is through CAN bus B interface while the application layer is defined by the GB/T 27930 standard.
  • System C - The physical/data layer is through Power Line Communication (PLC) while the application layer is defined by the ISO 15118 protocol.

In other words, the ISO 15118 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 protocol

ISO 15118 (Road Vehicles – Vehicle to grid communication interface) 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 describes the communication between these components.

Although ISO 15118 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 covers wired (AC and DC), wireless charging applications and enables the integration of EVs into the smart grid (V2G - vehicle-to-grid).

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

The ISO 15118 digital communication implements the following features:
  • security concept including encryption, signing, key management, etc.
  • robust PLC-based communications
  • automatic address assigning and association
  • IPv6-based communications
  • compressed XML messages
  • client-server approach
  • safety concept including cable check, welding detection, etc
  • extension concept for added-value services

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

Table 1. Communication function groups
Group Function Description
A START OF THE CHARGING PROCESS Initiation of the process between the vehicle and the EVSE after physically plugging-in the vehicle. Sets the basis for the on-going charging process e.g. availability of PWM, High Level Communication etc.
B COMMUNICATION SETUP Establishes the association and relevant connection between the EVCC and the SECC
C CERTIFICATION HANDLING All communication related to certificates
D INDETIFICATION AND AUTHORIZATION Methods for identification and authorization
E TARGET SETTING AND CHARGING SCHEDULING Information needed from the EV as well as from the SECC and the secondary actor to start the charging process and charging
F CHARGING CONTROLLING AND RE-SCHEDULING Commands to control elements during the charging process
G VALUE-ADDED SERVICES Additional elements not directly necessary for charging electric vehicles
H END-OF-CHARGE PROCESS Triggers for signaling the end of the charging process

Message sequence for an ISO 15118 DC charging session

The charging process for a DC charging session carried out by ISO 15118 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 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.

Figure 1. Message sequence for the DC charging session
A detailed explanation of the sequence is as follows:
  • Communication setup sequence:
    • supportedAppProtocolRequest: The EV and the charging station use this request-response message pair to agree upon a protocol version. During this transition phase, it is important that both the EV and charging station speak the same version of ISO 15118. If they are not compatible, it will not be possible to initiate an ISO 15118 charging session.
    • SessionSetupRequest: Used to assign a unique session ID for a communication session. The session can be paused and resumed later using the same session ID. In this case, the previously agreed upon charging parameters will be applied again to ensure charging continues as originally intended by the driver.
  • Identification, authentication and authorization sequence:
    • ServiceDiscovery: EV requests the charging station about its offerings. These services include AC single-phase charging or AC three-phase charging, variations of DC charging, available identification mechanisms (External Identification Means (EIM) or Plug & Charge), and optional value-added services such as Internet access to download additional data. The EV can request more details for each service by using the optional ServiceDetailRequest message.
    • PaymentServiceSelection: Once the identification mechanism, charging mode, and optional value-added services to use are clear, the EV informs the charging station with the PaymentServiceSelectionRequest.
    • CertificateInstallation: In case the EV selects Plug & Charge as an identification method, a valid digital contract certificate must be installed in order for the charging station to automatically authenticate and authorize the driver. If the EV does not yet have this certificate installed or if its existing contract certificate has expired, the EV can use the CertificateInstallation message pair to install a new contract certificate from the charging station.
    • CertificateUpdate: In cases where an EV has a soon-to-be expired contract certificate installed for Plug & Charge, the EV can be programmed to initiate a CertificateUpdate message pair to receive a new contract certificate.
    • PaymentDetails: If the EV is programmed to select Plug & Charge as its identification method, the EV will need to present its contract certificate to the charging station in order for the driver to be authenticated and authorized for charging. This is done using the PaymentDetailsRequest message.
    • Authorization: The Authorization message pair is used to avoid a replay attack. This is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated in order to gain access to a restricted resource.
  • Target setting and charge scheduling:
    • ChargeParameterDiscovery: the EV and the charging station mutually exchange their respective technical charging limits by communicating their maximal and minimal allowed voltage levels and amperage. The EV also informs the charging station of the amount of energy needed and the desired departure time provided by the driver. The SECC will then calculate a charge schedule to propose to the EV. The proposed schedule will include the maximum power with which the EV is allowed to charge while connected to the charging station as well as an optional SalesTariff. The SalesTariff includes schedules that provide information on cost over time, cost in relation to power demand and amount of energy, or a combination of these, aimed at incentivizing the EV to engage in a certain charging behavior.
    • CableCheck: For safe DC charging, a cable check shall be performed. The CableCheckReq asks for the cable check status of the EVSE and e.g. tells the EVSE if the connector is locked on EV side and if the EV is ready to charge. After receiving the CableCheckReq, the SECC sends the CableCheckRes with the information of cable check and EVSE status.
    • PreCharge: Pre charge is used for adjusting the EVSE output voltage to the EV battery voltage. The EV sends the Pre-Charge Request, which contains both the requested DC current (maximum inrush current) and the requested DC voltage. After receiving the PreChargeReq, the SECC sends the PreChargeRes informing the EV about the EVSE status and the present EVSE output voltage.
    • PowerDelivery: The Power Delivery message exchange marks the point in time when the EVSE provides voltage to its output power outlet and the EV can start to recharge its battery. After the DC supply gives feedback that it is ready for energy transfer, the EV sets the DC current request to start the energy transfer phase. By sending the PowerDeliveryReq the EVCC requests the SECC to provide power on and transmits the ChargingProfile the EVCC will follow during the charging process. After receiving the PowerDeliveryReq message, the SECC sends the PowerDeliveryRes message including information if the power will be available.
  • Charging loop/re-scheduling:
    • CurrentDemand: For DC charging control, cyclic exchange of the requested current from the EV side is necessary. Also the target voltage and the difference in current and voltages is transferred. By sending the CurrentDemandReq the EV requests a certain current from the EVSE. After receiving the CurrentDemandReq, the SECC sends the CurrentDemandRes informing the EV about the EVSE status and the present output voltage and current. We are now in a charging loop.
  • End of charging:
    • PowerDelivery: As soon as the EV intends to pause or end the charging session based on its calculated charging schedule, it will send another PowerDeliveryRequest message with its parameter ChargeProgress set to Stop. If the EV battery reaches a charge complete SoC, the charging session will be stopped.
    • WeldingDetection: The Welding Detection messages allow implementation of the Welding Detection mechanism according to IEC 61851. It is used to prevent the welding of the EV contactor.
    • SessionStop: The communication concludes with the SessionStopReq/-Res message pair. The ChargingSession parameter can be set to either Terminate or Pause. If the charging session is to be paused, certain parameters, like the agreed-upon charging schedule, are temporarily stored by the charging station so it can apply these values when charging resumes.

Message sequence for an ISO 15118 AC charging session

The charging process for a AC charging session carried out by ISO 15118 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 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.

Figure 2. Message sequence for the AC charging session
A detailed explanation of the sequence is as follows:
  • Communication setup sequence:
    • supportedAppProtocol: The EV and the charging station use this request-response message pair to agree upon a protocol version. During this transition phase, it is important that both the EV and charging station speak the same version of ISO 15118. If they are not compatible, it will not be possible to initiate an ISO 15118 charging session.
    • SessionSetup: Used to assign a unique session ID for a communication session. The session can be paused and resumed later using the same session ID. In this case, the previously agreed upon charging parameters will be applied again to ensure charging continues as originally intended by the driver.
  • Identification, authentication and authorization sequence:
    • ServiceDiscovery: EV requests the charging station about its offerings. These services include AC single-phase charging or AC three-phase charging, variations of DC charging, available identification mechanisms (External Identification Means (EIM) or Plug & Charge), and optional value-added services such as Internet access to download additional data. The EV can request more details for each service by using the optional ServiceDetailRequest message.
    • PaymentServiceSelection: Once the identification mechanism, charging mode, and optional value-added services to use are clear, the EV informs the charging station with a PaymentServiceSelectionRequest.
    • CertificateInstallation: In case the EV selects Plug & Charge as an identification method, a valid digital contract certificate must be installed in order for the charging station to automatically authenticate and authorize the driver. If the EV does not yet have this certificate installed or if its existing contract certificate has expired, the EV can use the CertificateInstallation message pair to install a new contract certificate from the charging station.
    • CertificateUpdate: In cases where an EV has a soon-to-be expired contract certificate installed for Plug & Charge, the EV can be programmed to initiate a CertificateUpdate message pair to receive a new contract certificate.
    • PaymentDetails: If the EV is programmed to select Plug & Charge as its identification method, the EV will need to present its contract certificate to the charging station in order for the driver to be authenticated and authorized for charging. This is done using the PaymentDetailsRequest message.
    • Authorization: The Authorization message pair is used to avoid a replay attack. This is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated in order to gain access to a restricted resource.
  • Target setting and charge scheduling:
    • ChargeParameterDiscovery: the EV and the charging station mutually exchange their respective technical charging limits by communicating their maximal and minimal allowed voltage levels and amperage. The EV also informs the charging station of the amount of energy needed and the desired departure time provided by the driver. The SECC will then calculate a charge schedule to propose to the EV. The proposed schedule will include the maximum power with which the EV is allowed to charge while connected to the charging station as well as an optional SalesTariff. The SalesTariff includes schedules that provide information on cost over time, cost in relation to power demand and amount of energy, or a combination of these, aimed at incentivizing the EV to engage in a certain charging behavior.
    • PowerDelivery: The Power Delivery message exchange marks the point in time when the EVSE provides voltage to its output power outlet and the EV can start to recharge its battery. After the AC supply gives feedback that it is ready for energy transfer, the EV sets the A0C current request to start the energy transfer phase. By sending the PowerDeliveryReq the EVCC requests the SECC to provide power on and transmits the ChargingProfile that the EVCC will follow during the charging process. After receiving the PowerDeliveryReq message, the SECC sends the PowerDeliveryRes message including information if the power will be available.
  • Charging loop/re-scheduling:
    • ChargingStatus: The Charging Status message pair provides sanity checks on the meter readings provided by the SECC. On the basis of the iteratively exchanged Charging Status messages the EV has means to check and validate the power drawn from the EVSE. Also, it allows the SECC to request the EVCC to sign the meter info record included in the ChargingStatusRes message by using the meter receipt message pair.
    • MeteringReceipt: When a MeteringReceiptReq message is sent, the EVCC acknowledges that the data elements MeterInfo record, SessionID, and SAScheduleTupleID are included in the ChargingStatusRes message prior to the reciept of the request by the SECC. This confirmation is implemented by applying a signature to the message body of the MeteringReceiptReq message. The signature applied by the EVCC is intended only to confirm that the EVCC, together with the currently applied charging contract certificate, which was selected for this charging session, has received the data elements MeterInfo record, SessionID and SAScheduleTupleID included in the Charging Status Res message prior to this request. It is not intended to confirm that the amount of energy indicated in the previous MeterInfo record is correct in the context of billing.
  • End of charging:
    • PowerDelivery: As soon as the EV intends to pause or end the charging session based on its calculated charging schedule, it will send another PowerDeliveryRequest message with its ChargeProgress parameter set to Stop. If charge complete SoC is reached by the EV battery the charging session will be stopped.
    • SessionStop: The communication concludes with the SessionStopReq/-Res message pair. The ChargingSession parameter can be set to either Terminate or Pause. If the charging session is to be paused, certain parameters, like the agreed-upon charging schedule, are temporarily stored by the charging station so it can apply these values when charging resumes.

ISO 15118 protocol implementation in Typhoon HIL tool-chain

Although IEC 61851 defines that the EVCC and SECC communicate using ISO 15118 through Power Line Communication (PLC) the protocol itself is Ethernet based and as such is implemented in the Typhoon HIL tool-chain. 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 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 SECC component located in Communication → EV charging → ISO 15118 folder in the Schematic Editor Library.

The ISO 15118 EVCC and SECC component supports only one version of the ISO 15118 standard with the parameters:
Table 2.
Field Value
Protocol namespace namespace: uru:iso:15118:2:2013:MsgDef
Version number major 2
Version number minor 0
Schema ID 10
Priority 1

ISO 15118 EVCC component

The ISO 15118 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 EVCC component is shown in Table 3.

Table 3. ISO 15118 EVCC component
component component dialog window properties

ISO 15118 EVCC

  • Connection type
  • Service category
  • Payment options
  • Energy transfer mode
  • Perform welding detection
  • Pre-charge voltage accuracy
  • Charge parameters
  • Execution rate

Component parameters are explained in Table 4

Table 4. Component parameter description
Name Property name Default value Description
Connection type connection_type Trusted connection Define the connection type between EV and EVSE. The value can be Trusted connection (using TCP protocol) or Secured connection (using TLS).
Service category service_category EV Charging Choose the service category that the EV intends to use. Currently, EV charging is the only available value service.
Payment options payment_options Contract Choose the payment option that the EV intends to use. Currently, Contract is the only available payment option.
Energy transfer mode energy_transfer_mode DC core Choose the energy transfer mode that the EV expects. Currently only DC options are available.
Perform welding detection include_welding_detection_request True Choose if Welding detection request message will be included in the communication session.
Pre-charge voltage accuracy pre_charge_voltage_accuracy 5 By the IEC 61851 standard, the main charging contactor on the EV side can be closed only when there is no significant offset between the EVSE output voltage and the Battery voltage in order to prevent current inrush. The Pre-charge voltage accuracy define that offset.
Charge parameters charge_parameters
{ 
    "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}
}
The Charge parameter define all the static values that define the EV request. A detailed description of all the values is in Charge parameters property value.
Execution rate execution_rate 100e-6 Execution rate of the ISO 15118 EVCC component
include_bulk_charge_complete False Define if the Bulk charge complete value will be present in the Current Demand messages for the EVCC. If the value is set to True, an additional terminal will be created on the component.
include_time_to_full_soc False Define if the Remaining time to full SoC value will be present in the Current Demand messages for the EVCC. If the value is set to True, an additional terminal will be created on the component.
include_time_to_bulk_soc False Define if the Remaining time to bulk SoC value will be present in the Current Demand messages for the EVCC. If the value is set to True, an additional terminal will be created on the component.

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. 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 or Full SoC. 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. 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)

Table 5. Charge parameter definitions
Parameter Mandatory/Optional Type Default value Description
departure_time O

unsigned int

0 - 4294967295

{
    "value": 0,
    "include": False
}
Used to indicate when the vehicle intends to finish the charging process. This value allows the EVSE to define the charging strategy. With the value 0, the EV indicates that the charging process should start right away.
maximum_current_limit M

PhysicalValue

0 - 400 A

{
    "value": 10,
    "multiplier": 0
}
Maximum current supported by the EV.
maximum_voltage_limit M

PhysicalValue

0 - 1000 V

{
    "value": 100,
    "multiplier": 0
}
Maximum voltage supported by the EV.
maximum_power_limit O

PhysicalValue

0 - 200000 W

{
    "value": 1000,
    "multiplier": 0,
    "include": True
}
Maximum power supported by the EV.
energy_capacity O

PhysicalValue

0 - 200000 W

{
    "value": 1000,
    "multiplier": 0,
    "include": False
}
Energy capacity of the EV.
energy_request O

PhysicalValue

0 - 200000 W

{
    "value": 1000,
    "multiplier": 0,
    "include": False
}
Amount of energy the EV requests from the EVSE.
full_soc O

byte

0 - 100

{
    "value": 100,
    "include": True
}
SoC at which the EV considers the battery to be fully charged.
bulk_soc O

byte

0 - 100

{
    "value": 80,
    "include": True
}
SoC at which the EV considers a fast charge process to end.
target_voltage M

PhysicalValue

0 - 1000 V

{
    "multiplier": 0
}
Voltage that the EV requests from the EVSE.
target_current M

PhysicalValue

0 - 1000 V

{
    "multiplier": 0
}
Current that the EV requests from the EVSE.
time_to_full_soc O

PhysicalValue

0 - 172800 s

{
    "multiplier": 0,
    "include": False
}
Calculated time until the Battery reaches the full SoC.
time_to_bulk_soc O

PhysicalValue

0 - 172800 s

{
    "multiplier": 0,
    "include": False
}
Calculated time until the Battery reaches the bulk SoC.

Input/Output terminals and State values

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

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:
  • PP - rather than passing the voltage level of the Proximity Pilot (PP) signal, the PP state should be passed defined as:
    • PP_STATE_ERROR = -1
    • PP_STATE_DISCONNECTED = 0
    • PP_STATE_CONNECTED = 1
    • PP_STATE_DEPRESSED = 2
  • CP - rather than passing the voltage level of the Control Pilot (CP) signal, the CP state should be passed defined as:
    • CP_STATE_ERROR = -1
    • CP_STATE_A = 0
    • CP_STATE_B = 1
    • CP_STATE_C = 2
  • EVReady - defines the EVReady value as 0 or 1
  • EVErrorCode - state values are defined as:
    • EV_NO_ERROR = 0
    • EV_FAILED_RESS_TEMPERATURE_INHIBIT = 1
    • EV_FAILED_EV_SHIFT_POSITION = 2
    • EV_FAILED_CHARGER_CONNECTOR_LOCK_FAULT = 3
    • EV_FAILED_EVRESS_MALFUNCTION = 4
    • EV_FAILED_CHARGING_CURRENTDIFFERENTIAL = 5
    • EV_FAILED_CHARGING_VOLTAGE_OUT_OF_RANGE = 6
    • EV_RESERVED_A = 7
    • EV_RESERVED_B = 8
    • EV_RESERVED_C = 9
    • EV_FAILED_CHARGING_SYSTEM_INCOMPATIBILITY = 10
    • EV_NO_DATA = 11
  • EVSoC - unsigned integer value 0 -100
  • EVTargetVoltage - unsigned integer value
  • EVTargetCurrent - unsigned integer value
  • EVChargeComplete - defines the ChargeComplete as 0 or 1
  • EVBulkChargeComplete - defines the ChargeComplete as 0 or 1
  • EVTimeToFullSoC - unsigned integer value
  • EVTimeToBulkSoC - unsigned integer value
  • SessionActive - defined as 0 or 1
  • EVSEReceivedMessage - defined as a state with values:
    • EVSE_SESSION_SETUP_RESPONSE = 0
    • EVSE_SERVICE_DISCOVERY_RESPONSE = 1
    • EVSE_PAYMENT_SERVICE_RESPONSE = 2
    • EVSE_CHARGE_PARAMETER_DISCOVERY_RESPONSE = 3
    • EVSE_CABLE_CHECK_RESPONSE = 4
    • EVSE_PRE_CHARGE_RESPONSE = 5
    • EVSE_POWER_DELIVERY_RESPONSE = 6
    • EVSE_CURRENT_DEMAND_RESPONSE = 7
    • EVSE_POWER_DELIVERY_STOP_RESPONSE = 8
    • EVSE_WELDING_DETECTION_RESPONSE = 9
    • EVSE_SESSION_STOP_RESPONSE = 10
  • EVSEResponseCode - defined as a state with values:
    • EV_NO_ERROR = 0
    • EV_FAILED_RESS_TEMPERATURE_INHIBIT = 1
    • EV_FAILED_EV_SHIFT_POSITION = 2
    • EV_FAILED_CHARGER_CONNECTOR_LOCK_FAULT = 3
    • EV_FAILED_EVRESS_MALFUNCTION = 4
    • EV_FAILED_CHARGING_CURRENTDIFFERENTIAL = 5
    • EV_FAILED_CHARGING_VOLTAGE_OUT_OF_RANGE = 6
    • EV_RESERVED_A = 7
    • EV_RESERVED_B = 8
    • EV_RESERVED_C = 9
    • EV_FAILED_CHARGING_SYSTEM_INCOMPATIBILITY = 10
    • EV_NO_DATA = 11
  • EVSEStatus - defined as a state with values:
    • EVSE_NOT_READY = 0
    • EVSE_READY = 1
    • EVSE_SHUTDOWN = 2
    • EVSE_UTILITY_INTERRUPT_EVENT = 3
    • EVSE_ISOLATION_MONITORING_ACTIVE = 4
    • EVSE_EMERGENCY_SHUTDOWN = 5
    • EVSE_MALFUNCTION = 6
    • RESERVED_8 = 7
    • RESERVED_9 = 8
    • RESERVED_A = 9
    • RESERVED_B = 10
    • RESERVED_C = 11
  • EVSEMaximumCurrentLimit - defined as a floating point value
  • EVSEMaximumVoltageLimit - defined as a floating point value
  • EVSEMaximumPowerLimit - defined as a floating point value
  • EVSEMinimumCurrentLimit - defined as a floating point value
  • EVSEMinimumVoltageLimit - defined as a floating point value
  • EVSEPeakCurrentRipple - defined as a floating point value
  • EVSECurrentRegulationTolerance - defined as a floating point value
  • EVSEEnergyToBeDelivered - defined as a floating point value
  • EVSEPresentCurrent - defined as a floating point value
  • EVSEPresentVoltage - defined as a floating point value
  • EVSECurrentLimitAchieved - defined as 0 or 1
  • EVSEVoltageLimitAchieved - defined as 0 or 1
  • EVSEPowerLimitAchieved - defined as 0 or 1

ISO 15118 EVCC component basic logic

Even though the ISO 15118 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.

The transition from Pre-charge to Current Demand will occur when the difference between EV Target Voltage and 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 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 SECC component

The ISO 15118 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 SECC component is shown in Table 3.

Table 6. ISO 15118 SECC component
component component dialog window properties

ISO 15118 SECC

  • EVSE ID
  • Supported energy modes
  • Supported payment options
  • Free service
  • Metering receipt required
  • Notification maximal delay
  • Station parameters
  • Execution rate

Component parameters are explained in Table 7

Table 7. Component parameter description
Name Property name Default value Description
EVSE ID evse_id
{
    "country_code" : "FR", 
    "operator_id" : "A23", 
    "power_outlet_id": "45B*78C" 
}
Any ID that uniquely identifies the EVSE and the power outlet the vehicle is connected to.
Supported energy modes supported_energy_transfer_modes
["AC three phase core", 
"AC single phase core"]

Available energy transfer modes supported by the EVSE.

AC_single_phase_core - AC single phase charging according to IEC 62196.

AC_three_phase_core - AC three phase charging according to IEC 62196.

Supported payment options supported_payment_options External payment

This type includes the list of payment options an SECC offers to the EVCC indicating what method could be chosen to pay for the services.

Currently, only the External payment option is supported.

Free service free_service True This element is used by the SECC to indicate if a service can be used by the EVCC free of charge or not. If FreeService is equal to true, the EV can use the offered service without payment. Currently only this option is available.
Metering receipt required include_metering_receipt_response False This element is used by the SECC to indicate that the EVCC is required to send a MeteringReceiptReq message for the purpose of signing the meter info record.
Notification maximal delay notification_max_delay 1 This value is the time in seconds from the point in time this message is sent (relative time) and expected to perform the action immediately. The SECC uses the NotificationMaxDelay element in the EVSEStatus to indicate the time until it expects the EVCC to react on the action request indicated in EVSENotification.
Station parameters station_parameters
{ 
    "max_current": {"value": 32,
                    "multiplier": 0},
    "nominal_voltage": {"value": 230,
                        "multiplier": 0},
}
The Station parameter define all the static values that define the EVSE. A detailed description of all the values is in Table 7.
Execution rate execution_rate 100e-6 Execution rate of the ISO 15118 EVCC component

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. Some of these parameters are optional and some are mandatory.

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.

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)

Table 8. Charge parameter definitions
Parameter Mandatory/Optional Type Default value Description
nominal_voltage M

unsigned int

0 - 1000 V

{
    "value": 230,
    "multiplier": 0
}
Line voltage supported by the EVSE. This is the voltage measured between one of the phases and neutral.
max_current M

PhysicalValue

0 - 400 A

{
    "value": 32,
    "multiplier": 0
}
Maximum allowed line current restriction set by the EVSE per phase.

Input/Output terminals and State values

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

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:
  • PP - rather than passing the voltage level of the Proximity Pilot (PP) signal, the PP state should be passed defined as:
    • PP_STATE_ERROR = -1
    • PP_STATE_DISCONNECTED = 0
    • PP_STATE_CONNECTED = 1
    • PP_STATE_DEPRESSED = 2
  • CP - rather than passing the voltage level of the Control Pilot (CP) signal, the CP state should be passed defined as:
    • CP_STATE_ERROR = -1
    • CP_STATE_A = 0
    • CP_STATE_B = 1
    • CP_STATE_C = 2
  • EVSENotification - this value is used by the SECC to influence the behaviour of the EVCC. The EVSENotification contains an action that the SECC wants the EVCC to perform. The requested action is expected by the EVCC until the time provided in NotificationMaxDelay. If the target time is not in the future, the EVCC is expected to perform the action immediately. During normal operation the value of EVSENotification is set to None. The EVSENotification should be passed defined as:
    • NONE = 0
    • STOP_CHARGING = 1
    • RE_NEGOTIATION = 2
  • RCD - indicates the current status of the Residual Current Device (RCD). If RCD is equal to true, the RCD has detected an error. If RCD is equal to False, the RCD has not detected an error. This status flag is for informational purpose only. The RCD should be passed defined as:
    • TRUE = 1
    • FALSE = 0
  • SessionActive - defined as 0 if the EVCC is not connected and as 1 if the connection is established
  • EVReceivedMessage - defined as a state with values:
    • EV_SUPPORTED_APP_PROTOCOL_REQUEST = 1
    • EV_SESSION_SETUP_REQUEST = 2
    • EV_SERVICE_DISCOVERY_REQUEST = 3
    • EV_SERVICE_DETAIL_REQUEST = 4
    • EV_PAYMENT_SERVICE_SELECTION_REQUEST = 5
    • EV_CERTIFICATE_INSTALLATION_REQUEST = 6
    • EV_CERTIFICATE_UPDATE_REQUEST = 7
    • EV_PAYMENT_DETAIL_REQUEST = 8
    • EV_AUTHORIZATION_REQUEST = 9
    • EV_CHARGE_PARAMETER_DISCOVERY_REQUEST = 10
    • EV_POWER_DELIVERY_REQUEST (ChargeProgress = START) = 11
    • EV_CHARGING_STATUS_REQUEST = 12
    • EV_METERING_RECEIPT_REQUEST = 13
    • EV_POWER_DELIVERY_REQUEST (ChargeProgress = STOP) = 14
    • EV_SESSION_STOP_REQUEST = 15
  • RequestedEnergyTransferMode - selected energy transfer mode for charging that is requested by the EVCC, may be:
    • NONE = 0
    • AC_single_phase_core = 1
    • AC_three_phase_core = 2
  • DepartureTime - defined as a floating point value
  • EAmount - defined as a floating point value
  • EVMaxVoltage - defined as a floating point value
  • EVMaxCurrent - defined as a floating point value
  • EVMinCurrent - defined as a floating point value

ISO 15118 EVCC component basic logic

Even though the ISO 15118 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_DICONNECTED and PP != PP_STATE_ERROR and CP != STATE_A and CP != CP_STATE_ERROR.

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 forecefully closed.

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.