Vehicle Charging Control Unit

ECU Development Experiences

V1.0.1 | 2017-04-27
 Introduction
Interaction with CCS Type-2 Inlet
Power-Line Communication
Backend Communication
Summary

Introduction
 Introduction
System Environment

 ECU is part of charging system for electric city-bus

 DC-charging via CCS2 standard
 Support of DIN70121 and ISO15118 (EIM / PNC)

ECU responsibilities:
 Interaction with CCS2 inlet
 Coordination of charging-related vehicle functions
 Coordination of HV-switches between inlet and DC-link
 Vehicle state-management according to charging schedule (wake-up / sleep)
 Communication with customer backend

3
 Introduction
 Interaction with CCS Type-2 Inlet
Power-Line Communication
Backend Communication
Summary

Interaction with CCS Type-2 Inlet

 Interaction with CCS Type-2 Inlet
Sensors / Actuators

Input Signals: Output Signals:

 Proximity Pin (PP)  Coupler Locking Mechanism
 Control Pilot Signal according to IEC61851 (CP)  LEDs (User-Interaction)
 Coupler Lock-State
 Temperature Sensors (AC, DC+, DC-)
 Push-Button (User-Interaction)

PP
CP 3x CAN
Multiple I/O
Lock Control
Lock State
3x Temp

3x LED
1x Button
CCS Type-2
Phoenix Contact VCCU Vehicle

5
 Interaction with CCS Type-2 Inlet
Proximity Pin

 Evaluation of PP signal and electrical diagnostic based on ADC signal

 Voltage segments are influenced by three resistors:
 Pullup-resistor in ECU (R4)
 Resistor in inlet (R5)
 Resistor in coupler (RC)

 Development according to IEC61851:2010 (Annex A – B.5)

 Resistor in inlet specified to 4k7 instead 2k7
 ECU pullup-resistor has to be adapted to optimize voltage segments (no overlapping)

Short to Plug present Plug present Plug present Plug present Plug not present Open- Short to
GND 100 Ohm 220 Ohm 680 Ohm 1500 Ohm Load battery
0V 0,3V 0,7V 1,6V 2,4V 3,8V 4,7V …36V

6
 Interaction with CCS Type-2 Inlet
Control Pilot Signal

PWM signal encodes following information:

 Duty-cycle: Maximum current (0 to 100%)
 Voltage: Charging state (-12V to +12V)

Frequency and duty-cycle:

 Captured via AUTOSAR MCAL module ICU
 Timer unit of microcontroller guarantees high
resolution

Voltage:
 ADC signal
 Trigger of ADC conversion is challenging
(maximum rise time 2us)

7
 Interaction with CCS Type-2 Inlet
Control Pilot Signal – Voltage Measurement

Options for ADC conversion trigger (microcontroller-dependent):

 Software trigger
 Delayed by interrupt locks and jitter

 Hardware trigger:
 Rising-Edge
> Not reliable if edge steepness is not high enough
 Streaming
> High CPU-load caused by interrupts and processing algorithm

 Final solution: Combination of streaming-mode and DMA unit

1 kHz / 1ms
50us

5%

ADC conversion
8
 Interaction with CCS Type-2 Inlet
Coupler Lock Mechanism

 Not standardized interface

 12V DC-motor controlled via ECU

 Specific parameters may be supplier-specific

 Different solutions for lock-state detection already available:

 Detection via light barrier or via micro-switches
 Two states (open / closed) or three states (open / driving / closed)

open
open
vs. driving vs. ?
closed
closed

Risk: Not all inlets provide same interfaces to ECU! Hardware re-design could be required to fit new inlet model

9
 Interaction with CCS Type-2 Inlet
Extension of Product Portfolio – Split of IEC 61851 relevant components

1. I/O Hardware Abstraction:

 Depends on microcontroller and ECU-hardware
 Transforms input values into physical/logical value,
e.g. CP frequency
 Controls outputs (e.g. S2 state)

2. Sensor/Actuator components
 Hardware-independent
 Calculates overall state,
e.g. combination of CP frequency and voltage
 Provides services, e.g. BCB toggle to wakeup EVSE
 Can be modelled as AUTOSAR software component

Sensor/Actuator components are generic and

could be part of future product versions.

10
 Introduction
Interaction with CCS Type-2 Inlet
 Power-Line Communication
Backend Communication
Summary

Power-Line Communication
 Power-Line Communication
Integration of Qualcomm QCA7005

 Firmware consists of
 Softloader
 Firmware
 Configuration-File (PIB)

 Maintained by Qualcomm
 Provided as binary HOST <SPI> <PLC>
QCA
CPU
 Storage of QCA firmware
1. Separated flash-chip Ext.
> Additional costs Flash?
> Firmware-update more complex
2. Host CPU
> Additional startup-time due to firmware download
> Firmware-update straightforward
> On-the-fly parameter update (e.g. MAC address)

12
 Power-Line Communication
QCA7005 – PIB File

 PIB File can be customized

 Settings for functional behavior,
e.g. SLAC as EVSE or EV
 Parameters (e.g. MAC address)

 Tone map
 Controls amplitude of all carriers used by Power-
Line communication
 Important parameter to optimize the EMC results
 Required by ISO15118-3:
> Calibration of transmission power must be performed
at CCS2 inlet
> Therefore individual for each vehicle platform

13
 Power-Line Communication
QCA7005 – Tone Map

 Carriers > 28Mhz notched

14
 Power-Line Communication
Communication Stack

Charging Application

RTE

JSON/
EXI Infra- EXI
SCC structure
XML
Comm. DNS
Sec

V2GTP HTTP

TLS

Eth
TCP/IPv6
SM

EthIf

Eth

EthTrcv

SPI

Product Project 3rd Party

15
 Power-Line Communication
TLS Communication / Plug and Charge

 TLS mandatory for PNC

Application
 Set of certificates must be stored in ECU
SCC

 Installation of OEM provisioning certificate:

 Non standardized interface (UDS diagnostic routine, CAN, …) V2GTP

 Confidential data (private key) TLS

 ECU-specific
TCP

 Installation of V2G root certificate: IPv6

 Non standardized interface

Ethernet
 Can be customer specific

 If certificate updates required during lifetime,

updates must be supported by OEM aftersales process
 Encryption for confidential data
 Real-time tracking of certificates (vehicle  customer/contract)

16
 Introduction
Interaction with CCS Type-2 Inlet
Power-Line Communication
 Backend Communication
Summary

Backend Communication
 Backend Communication
Communication to Backend-Server

 Intention  Requirements:
 Data exchange with fleet-operator  Bi-directional data exchange with backend
 Coordination of vehicle fleet  Several data objects
 Optimal preparation of vehicle for next drive  Security
> Authentication
> Encryption

 Possible solutions:
 Extension of V2G protocol (schema)
 New message type for V2GTP
 Proprietary protocol based on TCP/UDP
 HTTP / HTTPs
 External ECU (via CAN)

18
 Backend Communication
Extension of V2G Protocol

 Variant A: Extension of V2G schema

Usage of existing V2G communication Application

Adaption of EV- and EVSE-basic-software required

SCC
Original schema must be still supported SCC Appl.

V2GTP V2GTP

TLS TLS

 Variant B: New message type in V2GTP

TCP TCP
Usage of existing V2G communication
Message can be simply forwarded to backend IPv6 IPv6

Adaption of EV- and EVSE-basic-software required

Ethernet Ethernet

Variant A Variant B

19
 Backend Communication
Proprietary Protocol

TCP or UDP used as transport protocol

No adaption of EV- and EVSE-basic-software required
Communication based on proprietary protocol
DNS/DHCP for address resolution required
Application

TLS

UDP TCP

IPv6

Ethernet

20
 Backend Communication
HTTP / HTTPs

 Communication via internet possible

 Well-known protocols / techniques
Application
 Authentication:
 TLS Server- and/or Client-Authentication JSON

 Basic HTTP HTTP

 Encryption via HTTPs TLS

 Internet access requested as Value Added Service (VAS) TCP

 DNS/DHCP for address resolution required
IPv6
 JSON used as data format:
 Small overhead Ethernet

 Easy to parse in ECU

 Entire communication stack available as MICROSAR components

21
 Introduction
Interaction with CCS Type-2 Inlet
Power-Line Communication
Backend Communication
 Summary

Summary
 Summary
Lessons Learned

Interaction with CCS Type-2 Inlet

 Potential for new product components (Basic-SW)
 CCS2 interfaces could be incompatible to ECU hardware since not standardized

Power-Line Communication
 Entire communication stack available as Basic-SW components
 Storage of firmware on host controller
 PIB file offers many optimization parameters

Backend Communication
 HTTPs fulfills all requirements
 Low project-specific development effort

23
 For more information about Vector
and our products please visit

www.vector.com

Author:
Epping, Michael
Vector Germany

24 © 2017. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0.1 | 2017-04-27