Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Expert skill in 800V EV platform architecture design, covering SiC power electronics, ultra-fast charging (250-350 kW), backward compatibility with 400V infrastructure, and efficiency advantages. Covers 20 topics across charging-infrastructure domain. Includes 20 skill files covering ANSI C84.1 Voltage ratings for electric power systems, CHAdeMO 1.0/1.2 (up to 62.5 kW), CHAdeMO 2.0 (up to 400 kW), CHAdeMO 2.0/3.0 CAN-based protocol, CHAdeMO 3.0 (up to 900 kW with ChaoJi), CISPR 11 EMC limits for
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-06 | ✗→✓ | ▲ Improved | 4198% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 1501% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 2056% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 2250% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 1586% | 0% |
20 skill files covering charging-infrastructure domain for automotive software engineering.
Expert in 800V electric vehicle platform architecture, enabling ultra-fast charging (10 minutes for 80% SOC), higher efficiency powertrains, and reduced weight through smaller conductors and components, while maintaining backward compatibility with 400V charging infrastructure.
c // Simplified boost control void BoostConverter400to800(void) { float v_input = ADC_ReadVoltage(CH_INPUT); // 400V from charger float v_output = ADC_ReadVoltage(CH_OUTPUT); // 800V to battery float i_input = ADC_ReadCurrent(CH_INPUT);
float v_target = 800.0; float duty = 1.0 - (v_input / v_target); // Ideal duty cycle for boost
// PI controller fine-tunes duty cycle duty = PI_Update(&pi_boost, v_output, v_target, 0.0001);
PWM_SetDuty(duty);
// Current limit (don't exceed charger rating) if (i_input > 125.0) { // 50 kW / 400V = 125A duty -= 0.01; // Reduce duty to limit current } }
| Component | 400V Loss | 800V Loss | Improvement | |-----------|-----------|-----------|-------------| | Inverter | 3 kW (2%) | 1.5 kW (1%) | 50% reduction | | Motor copper | 2 kW (1.3%) | 2 kW (1.3%) | Same | | Cables (HV) | 1 kW (0.7%) | 0.25 kW (0.17%) | 75% reduction | | DC-DC conv | 0.5 kW | 0.3 kW | 40% reduction | | Total | 6.5 kW (4.3%) | 4.05 kW (2.7%) | 38% loss reduction |
Expert in onboard charger (OBC) design for electric vehicles, converting AC grid power to DC for battery charging, covering power factor correction, LLC resonant topology, control strategies, thermal management, and EMC compliance for automotive environments.
AC Input (L1, L2, L3, N) → EMI Filter → PFC Rectifier → DC Bus (400V) → LLC DC-DC Converter → Battery (200-420V) ↓ Controller (DSP, STM32) ↓ CAN (to BMS), CP Signal (to EVSE) ```### Power Factor Correction (PFC) Stage - **Objective**: Convert AC to DC with high power factor (>0.95) and low THD (<5%) - **Topology options**: - **Boost PFC**: Most common, single-phase, continuous conduction mode (CCM) - **Totem-pole PFC**: Higher efficiency (99%), uses GaN FETs, bridgeless design - **Vienna rectifier**: Three-phase, three-level output, high power density - **Boost PFC circuit**:
c void PFC_ControlLoop(void) { // Voltage outer loop (slow, 1 kHz) float v_dc_bus = ADC_ReadVoltage(CH_DC_BUS); float v_dc_ref = 400.0; // Target DC bus voltage float i_ref_peak = PI_Update(&pi_voltage, v_dc_bus, v_dc_ref, 0.001);// Current inner loop (fast, 100 kHz) float v_ac_rectified = ADC_ReadVoltage(CH_AC_RECTIFIED); float i_L = ADC_ReadCurrent(CH_INDUCTOR); float i_ref = i_ref_peak * v_ac_rectified / V_AC_PEAK; // Sinusoidal reference float duty = PI_Update(&pi_current, i_L, i_ref, 0.00001); PWM_SetDuty(duty); } ``` - **Component sizing**: - **Inductor**: L = (V_AC_peak × D) / (f_sw × ΔI_L) - Example: (325V × 0.5) / (100 kHz × 2A) = 812 µH → use 1 mH - **Capacitor**: C = (P_out × Δt) / (V_DC × ΔV_DC) - Example: (6600W × 0.01s) / (400V × 20V) = 8.25 mF → use 10 mF (electrolytic) - **MOSFET**: 600V or 650V rating (for 400V DC bus), R_DS(on) <50 mΩ (e.g., IPW60R045CP) ### LLC Resonant DC-DC Converter - **Topology**: Full-bridge LLC resonant converter (soft-switching for high efficiency) - **Circuit**:
c void LLC_ControlLoop(void) { float v_battery = ADC_ReadVoltage(CH_BATTERY); float i_battery = ADC_ReadCurrent(CH_BATTERY); float v_target = GetBatteryTargetVoltage(); // From BMS via CAN// PI controller adjusts switching frequency float freq_ref = PI_Update(&pi_llc, v_battery, v_target, 0.0001); // Clamp frequency to safe range if (freq_ref < 80000) freq_ref = 80000; if (freq_ref > 150000) freq_ref = 150000; PWM_SetFrequency(freq_ref); } ``` - **Component selection**: - **MOSFETs**: 600V, low Q_g (gate charge) for high-frequency switching (e.g., IPP60R045C7) - **Transformer**: Ferrite core (3C95, 3F3), Litz wire for reduced skin effect - **Diodes**: Fast recovery or SiC Schottky for rectifier (e.g., C3D10060A) ### EMI Filter Design - **Objective**: Reduce conducted emissions to meet CISPR 25 Class 5 (automotive) - **Filter topology**: Two-stage LC filter
python def calculate_thd(current_waveform, fundamental_freq): # FFT to extract harmonics fft = np.fft.fft(current_waveform) freqs = np.fft.fftfreq(len(current_waveform), sample_rate)# Fundamental (50 or 60 Hz) i1 = abs(fft[freqs == fundamental_freq]) # Harmonics (2nd, 3rd, ..., 40th) harmonic_sum = 0 for n in range(2, 41): in_harmonic = abs(fft[freqs == n * fundamental_freq]) harmonic_sum += in_harmonic**2 thd = np.sqrt(harmonic_sum) / i1 return thd * 100 # Percentage ``` ### Thermal Management - **Heat sources**: - PFC MOSFETs: ~30W loss @ 6.6 kW (conduction + switching) - LLC MOSFETs: ~20W loss (ZVS reduces switching loss) - Transformer: ~15W loss (core + copper) - Rectifier diodes: ~25W loss - **Cooling methods**: - **Air-cooled**: Heatsink + fan, 100-200 CFM airflow (for 3.3-6.6 kW) - **Liquid-cooled**: Glycol-water loop, cold plate (for 11-22 kW, shared with motor/inverter cooling) - **Thermal design**: - Junction-to-case: θ_JC = 0.5°C/W (typical for power MOSFET) - Case-to-heatsink: θ_CH = 0.2°C/W (with thermal interface material) - Heatsink-to-ambient: θ_HA = 1.0°C/W (forced air cooling) - Total: θ_JA = 0.5 + 0.2 + 1.0 = 1.7°C/W - Junction temp: T_J = T_ambient + P_loss × θ_JA = 25°C + 30W × 1.7 = 76°C (OK, <150°C max) ### Bidirectional OBC (for V2G/V2H) - **Topology**: Bidirectional PFC and bidirectional LLC - Forward (G2V): AC → DC (charging) - Reverse (V2G): DC → AC (discharging) - **Bidirectional PFC**: - Replace diode bridge with active rectifier (4× MOSFETs) - Control: Grid-tied inverter control (synchronize with grid voltage and frequency) - **Bidirectional LLC**: - Replace output rectifier with active bridge (4× MOSFETs) - Control: Phase-shift control for power flow direction - **V2G control**:
if (target_power > 0) { // Charging mode (G2V) PFC_ChargingMode(); LLC_ChargingMode(); } else if (target_power < 0) { // Discharging mode (V2G) PFC_InverterMode(grid_voltage, grid_freq); LLC_DischargingMode(); } else { // Idle PFC_Disable(); LLC_Disable(); } }
c void ChargingCurve(void) { float v_battery = ADC_ReadVoltage(CH_BATTERY); float i_battery = ADC_ReadCurrent(CH_BATTERY); float v_max = GetBatteryMaxVoltage(); // From BMS, e.g., 420V float i_max = GetBatteryMaxCurrent(); // From BMS, e.g., 16Aif (v_battery < v_max * 0.95) { // CC mode SetChargerCurrent(i_max); } else { // CV mode SetChargerVoltage(v_max); // Current will naturally taper } if (i_battery < 1.0) { // Charging complete StopCharging(); } } ``` ## Approach 1. **Topology selection**: PFC (boost, totem-pole) + LLC (full-bridge, half-bridge) 2. **Component selection**: MOSFETs, diodes, magnetics (inductor, transformer) 3. **Control design**: PI loops for PFC and LLC, voltage/current regulation 4. **EMI filter**: Design CM/DM filter, verify with spectrum analyzer 5. **PCB layout**: Minimize parasitic inductance, separate high-current and low-current traces 6. **Testing**: Efficiency measurement, THD analysis, EMC pre-compliance, thermal testing ## Deliverables - OBC design (schematic, PCB layout, BOM) - Control firmware (PFC and LLC loops, charging curve logic) - Magnetics design (inductor, transformer specs) - EMI filter design and simulation - Test reports (efficiency, power factor, THD, EMC compliance) - Thermal analysis and cooling design ## Best Practices - **Soft-start**: Ramp inrush current limiter (NTC thermistor or relay) to protect AC input - **Overtemperature**: Derate power if heatsink >80°C, shutdown if >95°C - **CAN communication**: Coordinate with BMS for voltage/current limits, SOC, temperature - **Safety**: Isolation monitoring, ground fault detection, fuse/circuit breaker - **Efficiency optimization**: Operate LLC near resonance, use SiC MOSFETs for low R_DS(on) ## Integration - **BMS**: CAN messages for battery voltage, current limits, SOC, temperature - **EVSE**: Control pilot (CP) PWM signal for available current, proximity pilot (PP) for cable rating - **Vehicle CAN**: Report charging status, faults, estimated time to full - **Thermal system**: Share cooling loop with motor inverter and DC-DC converter ### billing-roaming-emsp ## Core Competencies Expert in electric vehicle charging billing, roaming network operation, and e-Mobility Service Provider (eMSP) platform development, covering OCPI protocol for interoperability, tariff management, payment processing, Hubject integration, and business models for charging networks. ### EV Charging Ecosystem Roles - **CPO (Charge Point Operator)**: - Owns and operates charging stations - Manages hardware, electricity costs, site leases - Provides charging services to end users (directly or via eMSPs) - Examples: Electrify America, EVgo, ChargePoint - **eMSP (e-Mobility Service Provider)**: - Provides user-facing app/card for charging access - Contracts with multiple CPOs for roaming (user can charge anywhere) - Handles billing, customer support, payment processing - Examples: Shell Recharge, PlugSurfing, Chargemap - **Roaming Hub**: - Intermediary connecting CPOs and eMSPs - Enables interoperability (one app to charge at any network) - Examples: Hubject (Intercharge), Gireve (France), e-clearing.net - **NSP (Navigation Service Provider)**: - Provides route planning with charging stops - Integrates with eMSPs for real-time availability, pricing - Examples: Google Maps, Tesla navigation, ABRP ### OCPI (Open Charge Point Interface) Protocol - **Purpose**: Enable roaming between CPO and eMSP (cross-network charging) - **Key entities**: - **Locations**: Charging station sites (address, coordinates) - **EVSEs**: Electric Vehicle Supply Equipment (physical chargers) - **Connectors**: Charging outlets (CCS, CHAdeMO, Type 2) - **Sessions**: Charging sessions (start time, energy, duration, cost) - **CDRs (Charge Detail Records)**: Final billing records for completed sessions - **Tariffs**: Pricing structures (per kWh, per minute, flat fee) - **Tokens**: User authentication (RFID card ID, mobile app token) - **OCPI message flow** (roaming scenario): 1. User (with eMSP A card) arrives at CPO B charging station 2. User taps RFID card → CPO B sends authorization request to eMSP A (via OCPI or roaming hub) 3. eMSP A validates user, responds "Accepted" → CPO B starts charging 4. During charging: CPO B sends periodic session updates to eMSP A (energy, duration) 5. Charging ends: CPO B sends CDR (Charge Detail Record) to eMSP A 6. eMSP A bills user, pays CPO B (minus roaming fee) - **OCPI API example** (CPO pushes session update to eMSP):
payload = { "id": session_data"session_id"], "start_date_time": "2026-03-19T08:30:00Z", "kwh": session_data"energy_kwh"], "auth_id": session_data"rfid_token"], "location_id": session_data"location_id"], "evse_uid": session_data"evse_uid"], "connector_id": session_data"connector_id"], "currency": "USD", "total_cost": session_data"total_cost"], "status": "ACTIVE", # ACTIVE, COMPLETED, INVALID "last_updated": "2026-03-19T09:00:00Z" } response = requests.put( f"{emsp_url}/ocpi/cpo/2.2.1/sessions/{session_data'session_id']}", headers=headers, json=payload ) return response.status_code # 200 OK = eMSP acknowledged
status = send_session_update("https://emsp-api.example.com", session, "secret_token")
json { "id": "TARIFF001", "currency": "USD", "elements": [ { "price_components": [ { "type": "ENERGY", "price": 0.40, "step_size": 1 // 1 kWh increments }, { "type": "TIME", "price": 0.05, "step_size": 60 // 1-minute increments } ], "restrictions": { "start_time": "16:00", "end_time": "21:00", "day_of_week": ["MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY"] } }, { "price_components": [ { "type": "ENERGY", "price": 0.25, "step_size": 1 } ], "restrictions": { "start_time": "21:00", "end_time": "16:00" // Off-peak pricing (lower rate) } } ] } ```- **Tariff calculation**:
return round(total_cost, 2)
python import stripestripe.api_key = "sk_live_..." def charge_user(user_id, amount_usd, session_id): # Retrieve user's saved payment method (Stripe token) user = get_user(user_id) payment_method = user.stripe_payment_method try: # Create payment intent payment_intent = stripe.PaymentIntent.create( amount=int(amount_usd * 100), # Stripe uses cents currency="usd", payment_method=payment_method, confirm=True, description=f"Charging session {session_id}", metadata={"session_id": session_id, "user_id": user_id} ) if payment_intent.status == "succeeded": log_payment(user_id, session_id, amount_usd, "success") return True else: log_payment(user_id, session_id, amount_usd, "failed") return False except stripe.error.CardError as e: log_error(f"Card error: {e.user_message}") notify_user(user_id, f"Payment failed: {e.user_message}") return False # Example success = charge_user(user_id=12345, amount_usd=12.45, session_id="123456789") ``` ### Roaming and Interoperability - **Hubject (Intercharge)**: - Largest roaming platform in Europe - Connects 800+ CPOs, 1000+ eMSPs - Uses OICP (Open InterCharge Protocol) or OCPI 2.2 - **Hubject integration**: 1. CPO registers stations with Hubject (location, EVSE, connectors, tariffs) 2. eMSP registers users with Hubject (RFID tokens, mobile app tokens) 3. User charges at any Hubject-connected station 4. Hubject routes authorization, CDRs, and settlement - **Settlement process**: - CPO sends CDR to Hubject: 25.5 kWh @ $12.45 - Hubject takes roaming fee: 10% = $1.25 - Hubject pays CPO: $11.20 - Hubject bills eMSP: $12.45 - eMSP bills user: $12.45 (or adds markup, e.g., $13.45) ### CDR (Charge Detail Record) Generation - **CDR fields**: - Session ID, user token, location, EVSE, connector - Start/end timestamp, total energy (kWh), total duration (minutes) - Tariff applied, total cost (currency) - Meter readings (start/end kWh for billing accuracy) - **CDR example** (OCPI format):
python def validate_cdr(cdr): errors = []# Check required fields if not cdr.get("id"): errors.append("Missing CDR ID") if not cdr.get("total_energy") or cdr["total_energy"] <= 0: errors.append("Invalid total energy") if not cdr.get("total_cost") or cdr["total_cost"] < 0: errors.append("Invalid total cost") # Check energy vs cost consistency estimated_cost = cdr["total_energy"] * AVERAGE_RATE if abs(cdr["total_cost"] - estimated_cost) > estimated_cost * 0.5: errors.append(f"Cost mismatch: expected ~${estimated_cost}, got ${cdr['total_cost']}") return errors # Example errors = validate_cdr(cdr_data) if errors: log_warning(f"CDR validation failed: {errors}") ``` ### eMSP Mobile App Features - **User registration**: Email, password, payment method (credit card) - **Map view**: Display nearby charging stations (location, availability, price) - **Start/stop charging**: Remote start via app (ISO 15118 or OCPP) - **Session monitoring**: Real-time energy delivered, cost, estimated time remaining - **Payment history**: View past sessions, download receipts - **RFID card management**: Associate physical RFID cards with account - **App backend API example**:
app = Flask(__name__) @app.route("/api/v1/start_session", methods="POST"]) def start_session(): data = request.json user_id = data"user_id"] evse_id = data"evse_id"]
return jsonify({"session_id": session_id, "status": "started"}), 200 @app.route("/api/v1/session_status/<session_id>", methods="GET"]) def get_session_status(session_id): session = get_session(session_id) return jsonify({ "session_id": session_id, "status": session.status, # ACTIVE, COMPLETED "energy_kwh": session.energy_kwh, "duration_minutes": session.duration_minutes, "cost_usd": session.cost_usd })
Expert in Combined Charging System (CCS) implementation for DC fast charging infrastructure, covering both CCS Type 1 (North America, based on SAE J1772) and CCS Type 2 (Europe, based on IEC 62196-2), including PLC communication stack, power electronics control, and safety systems.
c typedef enum { STATE_A, // No vehicle connected (12V) STATE_B, // Vehicle connected, not ready (9V) STATE_C, // Vehicle ready, charging allowed (6V) STATE_D, // Charging with ventilation (3V, not used in CCS) STATE_E, // No power, CP shorted (0V) STATE_F // Fault, negative voltage (-12V) } CPState_t;void CheckCPState(float cp_voltage) { if (cp_voltage > 11.0 && cp_voltage < 13.0) { current_state = STATE_A; } else if (cp_voltage > 8.0 && cp_voltage < 10.0) { current_state = STATE_B; } else if (cp_voltage > 5.0 && cp_voltage < 7.0) { current_state = STATE_C; // Charging allowed } else if (cp_voltage < 1.0) { current_state = STATE_E; // Fault OpenContactors(); } } ``` - **ISO 15118 message handling** (simplified):
Expert in CHAdeMO protocol implementation for DC fast charging stations, covering CAN-based communication between EV and charger, bidirectional power flow (V2G/V2H/V2L), and all protocol versions from 1.0 to the latest 3.0 ChaoJi standard.
c typedef struct { uint8_t version; // Protocol version (0x01 for CHAdeMO 1.x) uint8_t soc; // State of charge (0-100%) uint16_t target_voltage; // Target battery voltage in 0.1V units uint16_t charging_current; // Requested current in 0.1A units uint8_t fault_flags; // Bit field: 0=OK, 1=battery overheat, etc. uint8_t status_flags; // Bit field: vehicle_ready, charge_enable, etc. } __attribute__((packed)) EVStatus_t;void SendEVStatus(void) { EVStatus_t msg = { .version = 0x01, .soc = battery_soc, // e.g., 45% .target_voltage = (uint16_t)(battery_voltage * 10), // e.g., 3800 = 380.0V .charging_current = (uint16_t)(requested_current * 10), // e.g., 1000 = 100.0A .fault_flags = 0x00, .status_flags = 0x03 // Ready + enable }; CAN_Send(0x100, (uint8_t*)&msg, sizeof(msg)); } ``` ### Charging Sequence - **Initialization** (before contactors close): 1. EV and charger exchange capabilities (max V, max I, protocol version) 2. Charger checks connector lock, insulation resistance (>100 kΩ/V) 3. EV sends permission signal (pin 6 goes high, 12V) 4. Charger verifies vehicle is ready (CAN status flags) - **Precharge and contactor close**: 1. Charger precharges DC bus to match EV battery voltage (within 20V) 2. Charger sends "ready to charge" status via CAN 3. EV gives final permission via CAN (charge_enable flag = 1) 4. Charger closes positive and negative contactors 5. Current starts flowing (ramp from 0 to target in ~2 seconds) - **Power delivery loop** (10 Hz cycle): 1. EV sends target voltage and current every 100 ms (CAN 0x101) 2. Charger regulates output to match EV request (within 2% tolerance) 3. Charger sends actual voltage and current back to EV (CAN 0x102) 4. EV monitors for faults (overvoltage, overcurrent, temperature) 5. EV can reduce current request dynamically (e.g., battery heating up) - **Charging termination**: 1. EV reduces current request to 0A when battery full (or user stops) 2. Charger ramps current to 0A within 5 seconds 3. Charger opens contactors (positive first, then negative) 4. Charger discharges DC bus to <60V within 5 seconds 5. EV signals "charge complete" via CAN, permission pin goes low 6. Connector lock releases, user can unplug ### Bidirectional Power Flow (V2G/V2H) - **Vehicle-to-Grid (V2G)** CHAdeMO 1.2+: - EV can discharge battery back to grid (reverse power flow) - CAN message includes "discharging mode" flag - Charger becomes inverter: DC from EV → AC to grid - Power range: 10 kW to 50 kW typical for V2G - **Vehicle-to-Home (V2H)**: - Similar to V2G but for home backup power during outage - Requires islanding detection (detect grid failure, disconnect safely) - Automatic transfer switch (ATS) to isolate home from grid - EV acts as backup generator (40-60 kWh battery = 1-3 days of home power) - **Discharge control**:
c typedef enum { IDLE, // No vehicle connected CONNECTED, // Vehicle plugged, connector locked INSULATION_TEST,// Measuring isolation resistance PRECHARGE, // Matching DC bus to battery voltage CHARGING, // Power delivery active DISCHARGING, // V2G/V2H active STOPPING, // Ramping current to zero FAULT // Error state, contactors open } ChargerState_t;void StateMachine(void) { switch (current_state) { case CONNECTED: if (insulation_test_passed()) { current_state = PRECHARGE; } break; case PRECHARGE: if (abs(dc_voltage - ev_battery_voltage) < 20) { close_contactors(); current_state = CHARGING; } break; case CHARGING: if (ev_current_request == 0 || fault_detected()) { current_state = STOPPING; } break; case STOPPING: if (output_current < 1.0) { open_contactors(); current_state = IDLE; } break; } } ``` ## Approach 1. **Hardware selection**: CHAdeMO connector (Yazaki), CAN transceiver (TJA1050), DC contactors 2. **CAN stack**: Implement CAN driver (250 kbps), message parsing, 100 ms periodic transmission 3. **Power electronics**: DC-DC converter with bidirectional capability for V2G 4. **Safety circuits**: Insulation monitoring device (IMD), residual current device (RCD), fuses 5. **Protocol implementation**: State machine for charging sequence, CAN message handlers 6. **Testing**: CHAdeMO compliance testing (Japan Automobile Research Institute), interoperability tests 7. **Certification**: CHAdeMO Association certification for charger and EV ## Deliverables - CHAdeMO protocol stack (C/C++) with CAN driver - EV or charger state machine implementation - V2G/V2H bidirectional control logic - Safety monitor (insulation, voltage, current, welding detection) - Test reports (protocol conformance, safety compliance) - Integration guide for power electronics and contactors ## Best Practices - **CAN bus robustness**: Proper termination, shielded cables, EMI filtering - **Timing accuracy**: 100 ms message period must be precise (use hardware timer) - **Fault tolerance**: Implement watchdog timeout, abort if communication lost >500 ms - **Connector lock**: Verify lock engaged before precharge, release only when safe - **V2G grid codes**: For V2G, comply with IEEE 1547 (anti-islanding, voltage/freq limits) ## Integration - **OCPP backend**: CHAdeMO session data (energy, duration, cost) to central system - **Payment**: RFID reader or credit card terminal for user authentication - **CCS adapter**: Some vehicles use CHAdeMO-to-CCS adapter (protocol translation required) - **Home energy management**: For V2H, integrate with home battery, solar inverter ### charging-grid-impact ## Core Competencies Expert in assessing electric vehicle charging impact on electrical distribution grids, covering transformer loading analysis, voltage drop calculations, harmonic distortion mitigation, power quality assessment, and planning grid upgrades to accommodate high EV penetration. ### Grid Impact Overview - **Key concerns**: - **Transformer overload**: Residential transformers designed for 5-10 homes, not 5-10 EVs charging simultaneously - **Voltage drop**: Long feeders experience voltage sag during high EV charging load - **Harmonic distortion**: Charger power electronics inject harmonics (3rd, 5th, 7th), degrade power quality - **Peak demand**: Uncontrolled charging coincides with evening peak (5-9 PM), exacerbates grid stress - **EV penetration scenarios**: - **Low (5-10%)**: Minimal grid impact, existing infrastructure sufficient - **Medium (20-30%)**: Localized transformer upgrades, voltage regulation needed - **High (50%+)**: Widespread feeder upgrades, substation capacity expansion ### Transformer Loading Analysis - **Residential transformer sizing**: - Typical: 25-50 kVA transformer serves 5-10 homes (diversified load ~5 kW/home) - Without EVs: Peak load = 10 homes × 5 kW × 0.7 diversity factor = 35 kW → 35 kVA - With EVs (50% adoption): Peak load = 35 kW + 5 EVs × 7.4 kW × 0.5 diversity = 35 + 18.5 = 53.5 kVA → Overload! - **Transformer thermal model**:
return { "total_load_kva": total_load_kva, "loading_pct": loading_pct, "overload_kva": overload_kva, "status": status }
python def voltage_drop_analysis(feeder_length_miles, feeder_impedance_ohm_per_mile, load_kw, voltage_nominal): # Convert miles to total impedance r_total = feeder_length_miles * feeder_impedance_ohm_per_mile # Ω (simplified, R only)# Current i_amps = (load_kw * 1000) / voltage_nominal # A (single-phase approximation) # Voltage drop v_drop = i_amps * r_total # V # Voltage at load v_load = voltage_nominal - v_drop # Compliance check v_min = voltage_nominal * 0.95 # 114V for 120V system if v_load < v_min: status = "VIOLATION" else: status = "OK" return { "v_drop": v_drop, "v_load": v_load, "status": status } # Example: 2-mile feeder, 0.5 Ω/mile, 50 kW load (7 EVs), 120V result = voltage_drop_analysis( feeder_length_miles=2, feeder_impedance_ohm_per_mile=0.5, load_kw=50, voltage_nominal=120 ) # Result: v_drop = (50,000 / 120) × (2 × 0.5) = 417A × 1Ω = 417V (unrealistic, need three-phase model) # Realistic (three-phase): v_drop ~10-15V → v_load = 105-110V (VIOLATION) # Solution: Voltage regulator at mid-feeder, or reduce load via smart charging ``` - **Voltage regulation solutions**: - **Line voltage regulator (LVR)**: Step-up transformer at mid-feeder (boost voltage by 5-10V) - **Capacitor banks**: Provide reactive power support, reduce voltage drop (inductive loads) - **Smart inverters (EVs)**: Inject reactive power (Volt-VAR mode) to support voltage ### Harmonic Distortion - **Harmonics from EV chargers**: - Charger AC-DC rectifier (PFC stage) generates harmonics: 3rd (180 Hz), 5th (300 Hz), 7th (420 Hz) - Total Harmonic Distortion (THD): Ratio of harmonic content to fundamental (60 Hz) - IEEE 519 limits: THD_I < 5% for current, THD_V < 3% for voltage (at PCC, Point of Common Coupling) - **THD calculation**:
def calculate_thd(waveform, sample_rate, fundamental_freq): # FFT of current waveform fft = np.fft.fft(waveform) freqs = np.fft.fftfreq(len(waveform), 1/sample_rate)
python def grid_upgrade_cost(current_capacity_kw, required_capacity_kw): upgrade_needed_kw = max(0, required_capacity_kw - current_capacity_kw)if upgrade_needed_kw == 0: return {"upgrade_needed": False, "cost": 0} # Cost factors transformer_cost_per_kw = 150 # $/kW (new transformer) feeder_cost_per_kw = 50 # $/kW (upgrade conductor) substation_cost_per_kw = 300 # $/kW (substation expansion, if needed) # Check if substation upgrade needed if required_capacity_kw > 5000: # >5 MW → substation upgrade total_cost = upgrade_needed_kw * substation_cost_per_kw upgrade_type = "Substation expansion" elif upgrade_needed_kw > 500: # >500 kW → feeder upgrade total_cost = upgrade_needed_kw * feeder_cost_per_kw upgrade_type = "Feeder upgrade" else: # <500 kW → transformer upgrade total_cost = upgrade_needed_kw * transformer_cost_per_kw upgrade_type = "Transformer upgrade" return { "upgrade_needed": True, "upgrade_kw": upgrade_needed_kw, "upgrade_type": upgrade_type, "cost_usd": total_cost } # Example: Depot needs 1,500 kW, current capacity 500 kW result = grid_upgrade_cost(current_capacity_kw=500, required_capacity_kw=1500) # Result: {"upgrade_needed": True, "upgrade_kw": 1000, "upgrade_type": "Feeder upgrade", "cost_usd": $50,000} ``` - **Utility interconnection process**: 1. Submit interconnection application (utility form, site plan, load estimate) 2. Utility conducts impact study (transformer loading, voltage drop, protection coordination) 3. Utility determines upgrade requirements (transformer, feeder, substation) 4. Developer pays impact fee (proportional to load added, e.g., $100-500/kW) 5. Utility performs upgrades (3-12 months timeline) 6. Interconnection approved, charger installation proceeds ### Load Diversity and Coincidence - **Coincidence factor**: Probability of multiple EVs charging simultaneously - Residential: Low (0.3-0.5) — people arrive home at different times - Workplace: Medium (0.5-0.7) — arrive in morning, plug in - Depot: High (0.8-1.0) — all vehicles return at same time, charge overnight - **Diversity factor**: Inverse of coincidence (1 / coincidence_factor) - Used to reduce oversizing of transformers ### Grid Simulation and Modeling - **Software tools**: - **OpenDSS**: Open-source distribution system simulator (EPRI) - **GridLAB-D**: Agent-based grid simulation (PNNL) - **PowerWorld**: Commercial power flow analysis - **MATLAB/Simulink**: Custom grid models - **Simulation workflow**: 1. Model distribution feeder (transformers, lines, loads) 2. Add EV charging loads (time-series data, charging profiles) 3. Run power flow analysis (voltage, current, losses at each node) 4. Identify violations (overvoltage, undervoltage, overload) 5. Test mitigation strategies (smart charging, voltage regulators, energy storage) ## Approach 1. **Data collection**: Gather feeder data (conductor size, transformer ratings, historical load) 2. **EV adoption forecast**: Estimate EV penetration over time (5%, 20%, 50%) 3. **Load modeling**: Create EV charging profiles (uncontrolled vs smart charging) 4. **Power flow simulation**: Run grid simulation with EV loads (OpenDSS, GridLAB-D) 5. **Impact assessment**: Identify overloaded transformers, voltage violations, harmonic issues 6. **Mitigation planning**: Design upgrades (transformer, feeder, voltage regulators) 7. **Cost-benefit analysis**: Compare grid upgrade cost vs smart charging benefits ## Deliverables - Grid impact study report (transformer loading, voltage drop, harmonics) - Load flow simulation results (voltage profiles, equipment loading) - Upgrade recommendations (transformer sizing, feeder conductor, voltage regulators) - Cost estimate for grid upgrades (equipment, installation, utility fees) - Smart charging strategy (time-shift charging to off-peak, reduce peak demand) ## Best Practices - **Conservative assumptions**: Use 1.0 coincidence factor for worst-case analysis - **Validation**: Compare simulation results to field measurements (voltage, current) - **Utility coordination**: Engage utility early (avoid delays, surprises) - **Phased approach**: Start with pilot (10-20% EVs), monitor, expand gradually - **Data-driven**: Use actual charging data (not assumptions) for load profiles ## Integration - **SCADA**: Real-time monitoring of transformer loading, feeder voltage - **Smart meters**: AMI data for EV charging detection, load profiling - **OpenADR**: Demand response signals to reduce charging during peak - **DER management**: Coordinate with solar, battery storage for grid support ### charging-safety-standards ## Core Competencies Expert in electric vehicle charging safety standards, regulations, and certification processes, covering ground fault protection, insulation monitoring, emergency stop systems, electrical safety interlock, arc flash protection, and comprehensive hazard analysis for charging infrastructure. ### Key Safety Standards - **IEC 61851-1**: General requirements for EV conductive charging - Safety classification, protection against electric shock - Control pilot function (PWM signaling for current limit) - Ground fault protection (RCD) requirements - Connector safety interlock - **IEC 61851-21/22/23/24**: Specific requirements - 61851-21: On-board charger requirements - 61851-22: AC charging station requirements - 61851-23: DC charging station requirements (high power) - 61851-24: Digital communication for control (ISO 15118 integration) - **UL 2594 / UL 2202** (North America): - UL 2594: EV charging system equipment (US/Canada) - UL 2202: EV charging system equipment (older standard) - Fire safety, overcurrent protection, grounding - Environmental testing (temperature, humidity, vibration) - **SAE J1772**: AC connector and control pilot safety - Mechanical interlock (cannot unplug while energized) - Control pilot states (A, B, C, D, E, F) - Proximity pilot (cable current rating detection) ### Ground Fault Protection - **AC ground fault (GFCI)**: - Detects leakage current: I_hot + I_neutral ≠ 0 (>20 mA for EV, vs 5 mA for household) - Trip time: <25 ms per IEC 61851-1 - Self-test: Monthly automatic test (inject fault signal, verify trip) - **DC ground fault (RCD)**: - Residual current device: Monitors I_DC+ + I_DC- (should be zero if no leakage) - Threshold: >20 mA (IEC 61851-23) - Sensor: Hall effect current sensors on both DC rails - Trip time: <100 ms - **GFCI implementation**:
typedef struct { float i_hot; float i_neutral; uint32_t fault_start_time; bool fault_active; } GFCI_t; void GFCI_Monitor(GFCI_t gfci) { gfci->i_hot = ADC_ReadCurrent(CH_HOT); gfci->i_neutral = ADC_ReadCurrent(CH_NEUTRAL); float residual_current = fabs(gfci->i_hot + gfci->i_neutral) 1000.0; // mA if (residual_current > GFCI_THRESHOLD_MA) { if (!gfci->fault_active) { gfci->fault_active = true; gfci->fault_start_time = GetTickCount(); } if (GetTickCount() - gfci->fault_start_time > GFCI_TRIP_TIME_MS) { // Trip GFCI OpenContactors(); LogFault("GFCI trip: residual current %.1f mA", residual_current); } } else { gfci->fault_active = false; } }
HV+ ───┬─── 100kΩ test resistor ───┬─── Ground │ │ IMD Current sensor HV- ───┴─────────────────────────┘ ```- **IMD (Insulation Monitoring Device) code**:
float MeasureInsulationResistance(float v_hv) { // Apply test voltage (e.g., 50V) between HV+ and ground float v_test = 50.0; ApplyTestVoltage(v_test); Delay_ms(100); // Allow settling // Measure leakage current float i_leakage = ADC_ReadCurrent(CH_IMD_LEAKAGE); // µA // Calculate insulation resistance float r_iso = v_test / (i_leakage / 1e6); // Ω RemoveTestVoltage(); return r_iso; } bool CheckInsulationIntegrity(float v_hv) { float r_iso = MeasureInsulationResistance(v_hv); float r_iso_min = R_ISO_MIN_OHM_PER_V v_hv; if (r_iso < r_iso_min) { LogError("Insulation fault: R_iso=%.0f Ω (min=%.0f Ω)", r_iso, r_iso_min); return false; } return true; }
24V DC ───┬─── E-stop Button (NC contact) ───┬─── Contactor Coil ───┬─── Ground │ │ │ │ Safety Relay Circuit Breaker ```- **E-stop firmware**:
if (e_stop_pressed) { // Immediately open contactors (hardware does this, firmware confirms) OpenAllContactors(); DisablePowerElectronics(); // Log event LogCritical("Emergency stop activated"); // Require manual reset while (!GPIO_Read(PIN_EMERGENCY_STOP_RESET)) { DisplayMessage("Emergency stop active. Reset to resume."); Delay_ms(100); } LogInfo("Emergency stop reset"); } }
c typedef enum { CP_STATE_A, // No vehicle CP_STATE_B, // Vehicle connected, not ready CP_STATE_C, // Vehicle ready, charging allowed CP_STATE_E, // Fault, short circuit CP_STATE_F // EVSE fault } CPState_t;CPState_t ReadCPState(void) { float v_cp = ADC_ReadVoltage(CH_CONTROL_PILOT); if (v_cp > 11.0 && v_cp < 13.0) return CP_STATE_A; if (v_cp > 8.0 && v_cp < 10.0) return CP_STATE_B; if (v_cp > 5.0 && v_cp < 7.0) return CP_STATE_C; if (v_cp < 1.0) return CP_STATE_E; if (v_cp < -10.0) return CP_STATE_F; return CP_STATE_E; // Unknown state = fault } void CPSafetyMonitor(void) { static CPState_t prev_state = CP_STATE_A; CPState_t current_state = ReadCPState(); if (current_state == CP_STATE_C) { // Charging allowed if (prev_state != CP_STATE_C) { LogInfo("Vehicle ready, charging allowed"); } } else { // Not in State C, stop charging immediately if (prev_state == CP_STATE_C) { OpenContactors(); LogWarning("CP state changed from C to %d, charging stopped", current_state); } } prev_state = current_state; } ``` ### Overcurrent and Overvoltage Protection - **Overcurrent**: - Hardware: Circuit breaker or fuse (40A for Level 2, 500A+ for DC fast) - Software: Monitor current via hall effect sensor, trip if >120% of rated for >1 second - **Overvoltage**: - Hardware: Varistor (MOV) for transient spikes (e.g., lightning) - Software: Monitor voltage, trip if >110% of rated for >100 ms - **Short circuit**: - Hardware: Fast-acting fuse or electronic circuit breaker - Software: Detect current spike (>200% rated), trip within 10 ms ### Arc Flash Protection - **Hazard**: High-voltage DC arcs difficult to extinguish (no zero-crossing like AC) - **Detection**: - Optical sensor: UV photodetector senses arc flash (bright UV signature) - Current sensor: Detect sudden surge (arc creates low-impedance path) - **Mitigation**: - Fast disconnect: Open contactors within 5 ms of arc detection - Arc-resistant contactors: Magnetic blowout coil to extinguish arc - Energy limitation: Limit stored energy in DC bus capacitors (<40 cal/cm² per NFPA 70E) ### Welding Detection - **Scenario**: Contactor contacts weld closed (high inrush current causes welding) - **Detection**: After opening contactor, measure voltage across contactor - If V_across_contactor = 0V → contactor welded (still conducting) - If V_across_contactor = V_bus → contactor open correctly - **Response**: If welded, abort session, display error, require service ### Hazard Analysis (FMEA / FTA) - **FMEA (Failure Modes and Effects Analysis)**: - Identify failure modes (e.g., contactor fails closed) - Assess severity (1-10), occurrence (1-10), detection (1-10) - Calculate RPN (Risk Priority Number) = S × O × D - Prioritize mitigation for high RPN items - **Example FMEA entry**: | Component | Failure Mode | Effect | Severity | Occurrence | Detection | RPN | Mitigation | |-----------|--------------|--------|----------|------------|-----------|-----|------------| | Contactor | Fails closed (welded) | Cannot de-energize, user shock hazard | 9 | 3 | 5 | 135 | Add welding detection, redundant contactor | - **FTA (Fault Tree Analysis)**: - Top event: "User receives electric shock" - Decompose into contributing faults (GFCI fails + insulation fault + user touches HV) - Calculate probability of top event (AND/OR gate logic) ### Safety Certification Process - **UL 2594 certification** (North America): 1. Submit design documentation (schematics, BOM, test plan) 2. UL lab conducts tests: Dielectric strength, ground continuity, leakage current, temperature rise 3. Environmental testing: Rain, humidity, vibration, impact 4. EMC testing: Conducted/radiated emissions (FCC Part 15) 5. UL issues certificate, periodic factory audits - **CE marking** (Europe): - Self-declaration or third-party (TÜV, Intertek) - Directives: LVD (Low Voltage Directive), EMC, RED (Radio Equipment for wireless) - IEC 61851-1/22/23 compliance testing - **Typical timeline**: 6-12 months from design freeze to certification ## Approach 1. **Standards review**: Identify applicable standards (IEC 61851, UL 2594, SAE J1772) 2. **Safety system design**: GFCI/RCD, insulation monitoring, E-stop, CP monitoring 3. **Hazard analysis**: Conduct FMEA and FTA, identify high-risk scenarios 4. **Prototype testing**: Bench testing of safety functions, inject faults to verify response 5. **Certification prep**: Prepare technical files, test plans, user manuals 6. **Lab testing**: Submit to UL, TÜV, or other certification body 7. **Field validation**: Pilot deployment, monitor for safety incidents ## Deliverables - Safety system design (GFCI, RCD, IMD, E-stop schematics and firmware) - Hazard analysis reports (FMEA, FTA) - Test procedures (ground fault injection, insulation test, E-stop response time) - Certification documentation (technical files, test reports, manuals) - Training materials (for installers and service technicians) ## Best Practices - **Redundancy**: Dual safety systems (e.g., two independent contactors in series) - **Fail-safe design**: Default to safe state on power loss or fault - **Regular testing**: Self-test safety functions monthly (GFCI, CP monitoring) - **User education**: Clear labeling, warning signs, user manual - **Field updates**: OTA firmware updates for safety-critical bugs (with rollback capability) ## Integration - **Charger controller**: CAN or Modbus for safety status reporting - **OCPP backend**: Send fault events, safety trips to central system - **Maintenance**: Remote diagnostics for safety system health - **Emergency services**: Integrate with building fire alarm (E-stop on fire alarm activation) ### charging-station-architecture ## Core Competencies Expert in EVSE (Electric Vehicle Supply Equipment) hardware architecture design for both AC Level 2 and DC fast charging stations, covering power electronics topologies, contactors, energy metering, communication systems, and multi-layered safety protection. ### System Architecture Overview - **AC Level 2 Charger** (7.4-19.2 kW):
Grid (480V 3-phase) → PFC Rectifier → DC-DC Converter → Isolation → Contactors → Energy Meter → CCS/CHAdeMO Connector → EV ↓ ↓ DC Bus (750V) Controller (ARM, x86) ↓ PLC Modem (ISO 15118) or CAN ↓ Backend (OCPP, Cloud) ```### Power Electronics Design - **AC Level 2** (no onboard power electronics): - Grid AC passed directly to vehicle onboard charger - EVSE provides: Switching (contactor), protection (GFCI), metering, communication - Contactor: 40A or 80A rated (single-pole for L1, double-pole for L1+L2) - **DC Fast Charger Power Stages**: - **Three-phase rectifier with PFC**: - Input: 480V AC 3-phase (or 400V in Europe) - Output: 750V DC bus (or 800V for high-power chargers) - Topology: Vienna rectifier or 6-pulse diode bridge with boost PFC - Power factor: >0.95 (meet grid code requirements) - THD: <5% (IEEE 519 harmonic limits) - **DC-DC converter**: - Input: 750V DC bus - Output: 200-1000V DC (variable to match EV battery voltage) - Topology: LLC resonant converter, dual-active bridge (DAB), or phase-shifted full bridge - Isolation: High-frequency transformer (20 kHz switching, galvanic isolation) - Efficiency: 95-98% at rated power - **Output filter**: - LC or LCL filter to reduce voltage ripple (<2% at rated current) - Capacitor: 1-5 mF electrolytic or film capacitor bank - Inductor: 50-200 µH, rated for 500A+ current - **Semiconductor selection**: - **IGBTs**: Traditional choice, 1200V or 1700V rating (for 750V DC bus) - **SiC MOSFETs**: Higher efficiency (lower conduction and switching losses), 1200V or 1700V - **Cooling**: Liquid-cooled heatsink for >100 kW (glycol-water loop) ### Contactor and Switching - **AC contactors** (Level 2): - Rating: 40A or 80A, 240V AC - Coil: 24V DC or 120V AC (controlled by microcontroller relay) - Auxiliary contacts: For feedback (verify contactor closed) - **DC contactors** (DC fast charging): - Rating: 1000V DC, 500-700A continuous - Breaking capacity: >10 kA (interrupt fault current safely) - Arc suppression: Magnetic blowout or vacuum contactors - Precharge relay: Series resistor (100Ω, 50W) to limit inrush current - **Contactor control logic**:
void ContactorStateMachine(void) { static ContactorState_t state = CONTACTOR_OPEN; float v_bus = MeasureDCBusVoltage(); float v_battery = MeasureBatteryVoltage(); // From EV via ISO 15118 switch (state) { case CONTACTOR_OPEN: if (ChargingRequested()) { ClosePrechargeRelay(); state = PRECHARGE; } break; case PRECHARGE: if (fabs(v_bus - v_battery) < 20.0) { // Within 20V CloseMainContactor(); OpenPrechargeRelay(); state = CONTACTOR_CLOSED; } break; case CONTACTOR_CLOSED: if (ChargingComplete() || FaultDetected()) { OpenMainContactor(); state = CONTACTOR_OPEN; } break; } }
c typedef struct { float voltage; // V float current; // A float power; // kW float energy; // kWh float power_factor; } EnergyMeter_t;EnergyMeter_t ReadEnergyMeter(void) { EnergyMeter_t meter; // Read from meter IC via SPI or UART meter.voltage = ReadRegister(VRMS_REG) * V_SCALE; meter.current = ReadRegister(IRMS_REG) * I_SCALE; meter.power = meter.voltage * meter.current * meter.power_factor / 1000.0; // kW meter.energy = ReadRegister(ENERGY_REG) * E_SCALE / 1000.0; // kWh return meter; } ``` ### Communication and Control - **Controller options**: - **Low-cost (AC Level 2)**: STM32F4, ESP32 (WiFi built-in) - **High-performance (DC fast)**: Raspberry Pi 4, NVIDIA Jetson (for ISO 15118 EXI processing) - **Industrial**: Siemens PLC, Beckhoff IPC (for multi-charger depot) - **Communication interfaces**: - **Local**: UART, CAN, Modbus RTU (to power modules) - **Backend**: WiFi, 4G LTE, Ethernet (OCPP to central system) - **PLC**: HomePlug Green PHY modem (ISO 15118 to EV) - **User interface**: NFC, RFID, touchscreen LCD - **Firmware architecture**:
Communication Tasks: - OCPP handler (100 ms, WebSocket to cloud) - ISO 15118 handler (100 ms, PLC to EV) - Modbus slave (10 ms, for local monitoring) Safety Monitor (10 kHz): - Overvoltage, overcurrent, ground fault detection - Emergency stop button input - Watchdog timer refresh
Grid (480V 3-phase, 1000A service) ↓ Main Distribution Panel ↓ ├─ Charger 1 (50 kW) ← Subfeed breaker 125A ├─ Charger 2 (50 kW) ├─ ... └─ Charger 10 (50 kW) ↓ Total: 500 kW (but diversity factor: 70% = 350 kW actual demand) ```- **Load management controller**: - Central controller monitors total power draw - Sends power limit commands to each charger (via Modbus or OCPP) - Example: 400 kW available, 10 chargers → 40 kW each, or prioritize some at 50 kW - **Communication network**: - Ethernet switch: Connect all chargers to central controller and cloud - Redundancy: Dual WAN (wired + 4G LTE) for internet connectivity ### Bill of Materials (BOM) Example for 50 kW DC Charger | Component | Description | Quantity | Unit Cost | Total | |-----------|-------------|----------|-----------|-------| | PFC Rectifier Module | 60 kW, 3-phase | 1 | $8,000 | $8,000 | | DC-DC Converter | 50 kW, 200-1000V | 1 | $12,000 | $12,000 | | DC Contactors | 1000V, 500A | 2 | $500 | $1,000 | | Energy Meter | MID certified | 1 | $300 | $300 | | CCS Connector | Type 1 or Type 2 | 1 | $1,000 | $1,000 | | PLC Modem | QCA7000 | 1 | $200 | $200 | | Controller | Raspberry Pi 4 + IO board | 1 | $400 | $400 | | Enclosure | IP65, steel | 1 | $2,000 | $2,000 | | Cooling System | Fans, heatsinks | 1 | $500 | $500 | | Display | 7" touchscreen | 1 | $300 | $300 | | Safety Devices | GFCI, RCD, E-stop | 1 | $400 | $400 | | Cable | 5m, liquid-cooled | 1 | $1,500 | $1,500 | | | | **Total BOM** | | **$27,600** | - Add 30-50% for assembly, testing, certification → **$35K-40K per 50 kW charger** ## Approach 1. **Requirements**: Define power level, connector type, communication (OCPP, ISO 15118) 2. **Power electronics**: Select topology (PFC, DC-DC), semiconductor (IGBT vs SiC), cooling 3. **Control system**: Choose controller, implement state machine, safety monitors 4. **Metering**: Integrate MID-certified meter for billing accuracy 5. **Communication**: Integrate PLC modem (EV), WiFi/4G (backend), touchscreen (user) 6. **Safety**: GFCI/RCD, insulation monitoring, emergency stop, thermal protection 7. **Mechanical**: Enclosure design, cable management, cooling system 8. **Testing**: Power delivery, efficiency, safety compliance (UL 2202), EMC (FCC Part 15) ## Deliverables - System architecture diagram (block diagram, single-line electrical) - Power electronics design (schematic, PCB layout, thermal analysis) - Firmware (state machine, OCPP/ISO 15118 stack, safety monitors) - BOM with cost analysis - Mechanical drawings (enclosure, cable assembly) - Test reports (power quality, efficiency, safety, EMC) - Certification documentation (UL, CE, FCC) ## Best Practices - **Redundancy**: Dual contactors for fail-safe (if one welds, other can open) - **Derating**: Size components for 80% of rating (extend lifetime, reduce failures) - **Modularity**: Use standard power modules (easy to replace if failed) - **Remote monitoring**: Telemetry for voltage, current, temperature (predictive maintenance) - **User feedback**: LEDs, display, audio alerts (clear status indication) ## Integration - **Grid**: Utility interconnection (breaker, meter, power quality monitoring) - **Backend**: OCPP to central management system (session data, billing, firmware updates) - **Payment**: Credit card reader, RFID, mobile app integration - **Fleet management**: API for depot operators (schedule charging, monitor SOC) ### charging-thermal-management ## Core Competencies Expert in thermal management for electric vehicle charging systems, covering cable and connector cooling for high-power charging (>200A), temperature monitoring, derating strategies, liquid cooling system design, and thermal modeling to ensure safe operation and maximum performance. ### Thermal Challenges in EV Charging - **I²R losses** in cables and connectors: - Power loss: P = I² × R - Example: 500A through 50 mΩ cable → P = 500² × 0.050 = 12.5 kW heat generation! - 5-meter cable: 12.5 kW × 5m = 62.5 kJ/s → cable heats rapidly without cooling - **Temperature limits**: - Copper conductor: <90°C continuous (insulation rating) - Connector pins: <60°C (UL 2251 limit for touch-safe operation) - Ambient: Up to +50°C in direct sunlight (outdoor charger) - **Consequences of overheating**: - Insulation breakdown → short circuit, fire hazard - Connector melting → damage to vehicle inlet - Reduced efficiency (resistance increases with temperature: R(T) = R₀ × (1 + α × ΔT)) ### Air-Cooled vs Liquid-Cooled Cables - **Air-cooled** (up to ~200A): - Natural convection or forced air (fan) - Cable diameter: 20-30 mm (larger copper cross-section needed) - Weight: 2-4 kg for 5-meter cable - Typical use: AC Level 2 (up to 80A), DC fast charging up to 150 kW - **Liquid-cooled** (>200A, up to 500A): - Coolant channels in cable (glycol-water mix) - Cable diameter: 30-50 mm (copper + coolant hoses) - Weight: 5-10 kg (heavier due to coolant and fittings) - Typical use: DC fast charging 250-350 kW (CCS, MCS) ### Liquid-Cooled Cable Design - **Cable construction**: - Copper conductors: 35-50 mm² cross-section (for 500A) - Coolant channels: 2× 8-10 mm ID hoses (inlet and outlet) - Insulation: XLPE or silicone rubber (rated for 1000V, 105°C) - Outer jacket: TPU or neoprene (abrasion and weather resistant) - **Coolant circuit**:
c #define TEMP_NORMAL 45.0 #define TEMP_WARNING 55.0 #define TEMP_DERATE 65.0 #define TEMP_FAULT 75.0float ReadConnectorTemperature(void) { uint16_t adc_value = ADC_Read(CH_CONNECTOR_TEMP); float resistance = ADC_ToResistance(adc_value); // NTC lookup float temp = NTC_ToTemperature(resistance); // Steinhart-Hart equation return temp; } void ThermalProtection(void) { float temp = ReadConnectorTemperature(); if (temp < TEMP_NORMAL) { // Normal operation, full power max_current = 500.0; } else if (temp < TEMP_WARNING) { // Warning, reduce power 20% max_current = 400.0; LogWarning("Connector temperature elevated: %.1f C", temp); } else if (temp < TEMP_DERATE) { // Derate, reduce power 50% max_current = 250.0; LogWarning("Connector temperature high, derating: %.1f C", temp); } else if (temp < TEMP_FAULT) { // Fault, stop charging max_current = 0.0; OpenContactors(); LogError("Connector overtemperature fault: %.1f C", temp); } else { // Critical fault, emergency stop EmergencyStop(); LogCritical("Connector critical overtemperature: %.1f C", temp); } SetMaxChargingCurrent(max_current); } ``` ### Thermal Derating Algorithms - **Ambient temperature compensation**: - Nominal rating: 500A at 25°C ambient - Derate: 1% per °C above 25°C - Example: At 45°C ambient, max current = 500A × (1 - 0.01 × (45-25)) = 400A - **Continuous vs intermittent**: - Continuous (>15 min): Use conservative rating (80% of max) - Intermittent (<5 min): Can use 100% of max (thermal mass absorbs heat) - **Derating curve**:
return max(0.0, factor)
factor = thermal_derating_factor(temp_connector, temp_ambient, duration) i_max = i_rated factor # Result: 500 0.9 0.85 1.2 = 459A (reduced from 500A due to heat)
c void CoolingSystemControl(void) { float temp_coolant_out = ADC_ReadTemperature(CH_COOLANT_OUT); float temp_connector = ReadConnectorTemperature();// Variable speed pump (PWM control) if (temp_coolant_out > 45.0 || temp_connector > 50.0) { pump_speed = 100; // Full speed } else if (temp_coolant_out > 35.0 || temp_connector > 40.0) { pump_speed = 70; // Medium speed } else { pump_speed = 50; // Low speed (minimum flow) } PWM_SetDutyCycle(CH_PUMP, pump_speed); // Fan control for heat exchanger if (temp_coolant_out > 40.0) { GPIO_Set(PIN_FAN, HIGH); // Turn on fan } else if (temp_coolant_out < 35.0) { GPIO_Set(PIN_FAN, LOW); // Turn off fan (hysteresis) } } ``` ### Thermal Modeling and Simulation - **1D thermal network model**:
Thermal resistances: R_copper_to_coolant = 0.05 K/W (convection in coolant channel) R_coolant_to_hx = 0.02 K/W (heat exchanger effectiveness) R_hx_to_ambient = 0.10 K/W (air-side heat transfer) Total thermal resistance: R_total = 0.05 + 0.02 + 0.10 = 0.17 K/W Temperature rise: ΔT = P × R_total = 12.5 kW × 0.17 K/W = 2.1 K Copper temperature: T_copper = T_ambient + ΔT = 25°C + 2.1°C = 27.1°C (excellent!)
python import numpy as npdef transient_thermal(power, duration, thermal_mass, thermal_resistance, ambient_temp): # Thermal time constant: tau = R * C tau = thermal_resistance * thermal_mass # Time vector t = np.linspace(0, duration, 100) # Temperature response (exponential rise) T_steady_state = ambient_temp + power * thermal_resistance T = T_steady_state * (1 - np.exp(-t / tau)) + ambient_temp return t, T # Example: 12.5 kW heating, 5-minute charge session t, T_copper = transient_thermal( power=12500, # W duration=300, # seconds thermal_mass=500, # J/K (copper mass × specific heat) thermal_resistance=0.05, # K/W (copper to coolant) ambient_temp=25 # C ) import matplotlib.pyplot as plt plt.plot(t, T_copper) plt.xlabel("Time (s)") plt.ylabel("Copper Temperature (°C)") plt.title("Cable Heating During 350 kW Charge") plt.show() ``` ### Cable Maintenance and Inspection - **Regular inspection**: - Visual: Check for damage, kinks, abrasion on outer jacket - Connector pins: Inspect for discoloration (indicates overheating), pitting, corrosion - Coolant level: Check reservoir, top off if low (evaporation over time) - **Coolant testing**: - pH: 7-9 (acidic coolant corrodes copper, basic causes scaling) - Glycol concentration: 40-60% (use refractometer) - Contamination: Check for particles, discoloration (flush and replace if dirty) - **Thermography**: - Infrared camera: Scan cable during charging (identify hot spots) - Typical reading: Uniform temperature along cable (<40°C) - Hot spot (>60°C): Indicates poor contact, damaged conductor, or cooling blockage - **Replacement criteria**: - Connector pins discolored or pitted → replace connector assembly - Cable outer jacket cracked or abraded → replace cable (insulation compromised) - Coolant leaks → replace hose fittings or entire cable assembly - Resistance increase >20% from baseline → replace (conductor damaged) ### Advanced Cooling Strategies - **Peltier cooling** (for extreme cases): - Thermoelectric cooler (TEC) in connector - Active cooling below ambient temperature - High power consumption (COP ~0.5), only for specialized applications - **Phase-change cooling** (future): - Refrigerant (R-134a, R-1234yf) evaporates in cable, absorbs heat - Compressor recondenses refrigerant in charger cabinet - Very high cooling capacity (50+ kW per cable) - Complex, expensive, but enables >1 MW charging (MCS) - **Immersion cooling** (research): - Dielectric fluid (fluorinated liquid) directly contacts conductors - No insulation needed (fluid is insulating) - Extremely high heat transfer coefficient - Challenges: Sealing, fluid compatibility, cost ## Approach 1. **Thermal analysis**: Calculate I²R losses, estimate temperature rise 2. **Cooling method**: Select air or liquid cooling based on current rating 3. **Component selection**: Pump, heat exchanger, hoses, fittings, thermistors 4. **Control design**: Temperature monitoring, derating algorithm, pump/fan control 5. **Testing**: Thermal imaging, coolant flow measurement, long-duration soak test 6. **Maintenance plan**: Inspection schedule, coolant testing, replacement criteria ## Deliverables - Thermal analysis report (I²R losses, temperature distribution, cooling capacity) - Cooling system design (schematic, pump/heat exchanger specs, plumbing) - Derating algorithm (code, thresholds, test data) - Temperature monitoring system (sensor placement, ADC interface, calibration) - Maintenance manual (inspection procedures, coolant testing, troubleshooting) - Test reports (thermal imaging, ambient soak test, coolant flow verification) ## Best Practices - **Safety margin**: Design for 1.5× worst-case heat generation (account for aging, fouling) - **Redundant sensors**: Multiple temperature sensors (connector, cable mid-point, coolant) - **Fail-safe**: If sensor fails (open circuit), assume worst-case and derate aggressively - **User feedback**: Display connector temperature on charger screen (transparency) - **Data logging**: Record temperature, current, ambient for predictive maintenance ## Integration - **Charger controller**: CAN bus or Modbus for temperature data, derating commands - **OCPP backend**: Send temperature alerts, derating events to central system - **Vehicle BMS**: Share temperature data (EV may also derate if inlet too hot) - **Building HVAC**: Coordinate with building cooling system (reject heat to chilled water) ### dc-fast-charging-control ## Core Competencies Expert in DC fast charge controller design and firmware development, covering high-level communication (ISO 15118, CHAdeMO), low-level control pilot signaling, closed-loop power regulation (PI/PID), precharge sequencing, and multi-layered fault protection. ### Controller Architecture - **Hardware platform**: - **Microcontroller**: STM32H7 (400 MHz, FPU for fast control loops), NXP i.MX8 (Linux for ISO 15118) - **Communication**: CAN controller (CHAdeMO), PLC modem (CCS/ISO 15118), Ethernet (OCPP backend) - **Analog inputs**: 16-bit ADC for voltage/current sensing (1 MHz sampling) - **Digital I/O**: Contactor control, pilot signals, emergency stop input - **Power supply**: 12V or 24V from AC input, with backup battery for contactor control - **Software architecture**: ``` Real-time layer (RTOS or bare-metal, 10 kHz): - ADC sampling (voltage, current, temperature) - PI control loop (current/voltage regulation) - Safety monitors (overvoltage, overcurrent, ground fault) - Contactor state machine Application layer (Linux or FreeRTOS, 10 Hz): - ISO 15118 or CHAdeMO protocol handler - OCPP client (WebSocket to backend) - User interface (display, RFID reader) - Data logging (session energy, faults) ``` ### Communication Protocols - **CCS (ISO 15118-2/3)**: - Physical: PLC (HomePlug Green PHY) at 85 kHz on Control Pilot line - Data link: IPv6 over PLC, TCP for reliable delivery - Application: EXI-encoded XML messages (SessionSetup, ChargeParameterDiscovery, CurrentDemand) - Message rate: 100 ms to 250 ms (10 Hz to 4 Hz) - **CHAdeMO**: - Physical: CAN 2.0B at 250 kbps - Application: Binary CAN messages (EV status, charger status, target V/I) - Message rate: 100 ms (10 Hz) - **Control Pilot (CP) low-level signaling**: - PWM at 1 kHz, +/-12V square wave - Duty cycle: 5% = digital communication request, 10-96% = available current encoding - EV changes CP impedance (1kOhm -> 270Ohm) to signal state transitions ### Precharge Sequencing - **Objective**: Match charger DC bus voltage to EV battery voltage before closing main contactors (avoid inrush current) - **Sequence**: 1. Charger DC bus at 0V (contactors open) 2. Measure EV battery voltage via ISO 15118 or CHAdeMO (e.g., 350V) 3. Charger ramps DC-DC converter output to 350V (no load, open circuit) 4. Close precharge relay (100Ohm series resistor limits inrush to ~3.5A) 5. Wait for voltage to equalize (within 20V), typically 1-2 seconds 6. Close main positive contactor 7. Open precharge relay (no longer needed) 8. Close main negative contactor 9. Current can now flow (ramp from 0A to target over 2 seconds) - **Precharge control code**: ```c typedef enum { PRECHARGE_IDLE, PRECHARGE_RAMP_VOLTAGE, PRECHARGE_WAIT_SETTLE, PRECHARGE_CLOSE_MAIN, PRECHARGE_COMPLETE, PRECHARGE_FAULT } PrechargeState_t; void PrechargeStateMachine(void) { static PrechargeState_t state = PRECHARGE_IDLE; static uint32_t settle_timer = 0; float v_dc_bus = ADC_ReadVoltage(CH_DC_BUS); float v_battery = GetEVBatteryVoltage(); // From ISO 15118 or CHAdeMO switch (state) { case PRECHARGE_IDLE: if (ChargingRequested()) { SetDCDCVoltage(v_battery); // Command converter to battery voltage state = PRECHARGE_RAMP_VOLTAGE; } break; case PRECHARGE_RAMP_VOLTAGE: if (fabs(v_dc_bus - v_battery) < 50.0) { // Within 50V GPIO_Set(PIN_PRECHARGE_RELAY, HIGH); // Close precharge relay settle_timer = GetTickCount(); state = PRECHARGE_WAIT_SETTLE; } break; case PRECHARGE_WAIT_SETTLE: if (GetTickCount() - settle_timer > 2000) { // 2 second settle time if (fabs(v_dc_bus - v_battery) < 20.0) { // Within 20V state = PRECHARGE_CLOSE_MAIN; } else { state = PRECHARGE_FAULT; // Voltage didn't equalize } } break; case PRECHARGE_CLOSE_MAIN: GPIO_Set(PIN_MAIN_CONTACTOR_POS, HIGH); Delay_ms(50); // Wait for contactor to close GPIO_Set(PIN_PRECHARGE_RELAY, LOW); // Open precharge relay Delay_ms(50); GPIO_Set(PIN_MAIN_CONTACTOR_NEG, HIGH); state = PRECHARGE_COMPLETE; break; case PRECHARGE_COMPLETE: // Ready to start current flow break; case PRECHARGE_FAULT: OpenAllContactors(); LogFault("Precharge failed: voltage mismatch"); break; } } ``` ### Closed-Loop Current and Voltage Regulation - **Control objective**: Track EV requested voltage and current with <2% error - **Dual-loop control**: - **Outer loop** (voltage control): PI controller, 100 Hz update rate - **Inner loop** (current control): PI controller, 1 kHz update rate (faster response) - **PI controller implementation**: ```c typedef struct { float Kp; // Proportional gain float Ki; // Integral gain float integral; // Integral accumulator float setpoint; // Target value float output_min; // Anti-windup limit float output_max; } PIController_t; float PI_Update(PIController_t* pi, float measured_value, float dt) { float error = pi->setpoint - measured_value; pi->integral += error * dt; // Anti-windup: Clamp integral term if (pi->integral > pi->output_max) pi->integral = pi->output_max; if (pi->integral < pi->output_min) pi->integral = pi->output_min; float output = pi->Kp * error + pi->Ki * pi->integral; // Clamp output if (output > pi->output_max) output = pi->output_max; if (output < pi->output_min) output = pi->output_min; return output; } // Example: Current control loop at 1 kHz void CurrentControlLoop(void) { static PIController_t pi_current = { .Kp = 0.5, .Ki = 50.0, .output_min = 0.0, .output_max = 100.0 // PWM duty cycle percentage }; float i_measured = ADC_ReadCurrent(CH_OUTPUT); float i_target = GetEVCurrentRequest(); // From ISO 15118 pi_current.setpoint = i_target; float pwm_duty = PI_Update(&pi_current, i_measured, 0.001); // dt=1ms SetPWM(pwm_duty); // Update DC-DC converter PWM } ``` - **Tuning**: Use Ziegler-Nichols method or manual tuning (Kp first, then Ki) - Kp: Proportional response (too high = oscillation, too low = slow) - Ki: Eliminates steady-state error (too high = overshoot) ### Cable Voltage Drop Compensation - **Problem**: At 500A, 5m cable with 50 mOhm resistance drops 25V (5% error at 500V) - **Solution**: Measure voltage at EV inlet (via ISO 15118 feedback), not at charger output - **Compensation**: ```c float CompensateCableVoltage(float v_target_at_ev, float i_output) { const float CABLE_RESISTANCE = 0.050; // 50 mOhm float v_drop = i_output * CABLE_RESISTANCE; float v_charger_output = v_target_at_ev + v_drop; return v_charger_output; } // In control loop float v_ev_inlet = GetEVInletVoltage(); // From ISO 15118 message float i_output = ADC_ReadCurrent(CH_OUTPUT); float v_target_charger = CompensateCableVoltage(v_ev_inlet, i_output); SetDCDCVoltage(v_target_charger); ``` ### Fault Detection and Protection - **Overvoltage**: - Threshold: EV_target_voltage + 5% (e.g., 525V for 500V target) - Action: Reduce voltage immediately, if persists >100ms -> open contactors - **Overcurrent**: - Threshold: min(EV_max_current, cable_rating, charger_rating) + 10% - Action: Reduce current, if exceeds 120% for >1 second -> trip - **Ground fault** (DC residual current): - Monitor: I_DC+ + I_DC- (should be zero if no leakage) - Threshold: >20 mA - Action: Open contactors within 100 ms - **Insulation fault**: - Test before charging: Measure R_iso (DC+ and DC- to ground) - Threshold: <100 Ohm/V (e.g., <50 kOhm for 500V) - Action: Abort charging, display error - **Thermal fault**: - Monitor: Inverter temperature, connector temperature, cable temperature - Derate: Reduce power if temp >80C - Shutdown: If temp >95C - **Communication fault**: - Watchdog: If no message from EV for >500 ms (ISO 15118) or >1 second (CHAdeMO) - Action: Ramp current to zero over 5 seconds, open contactors - **Fault handling code**: ```c typedef enum { FAULT_NONE = 0, FAULT_OVERVOLTAGE = (1 << 0), FAULT_OVERCURRENT = (1 << 1), FAULT_GROUND_FAULT = (1 << 2), FAULT_INSULATION = (1 << 3), FAULT_THERMAL = (1 << 4), FAULT_COMM_TIMEOUT = (1 << 5), FAULT_EMERGENCY_STOP = (1 << 6) } FaultFlags_t; uint32_t CheckFaults(void) { uint32_t faults = FAULT_NONE; if (v_output > v_target * 1.05) faults |= FAULT_OVERVOLTAGE; if (i_output > i_max * 1.20) faults |= FAULT_OVERCURRENT; if (fabs(i_dcplus + i_dcminus) > 0.020) faults |= FAULT_GROUND_FAULT; if (temp_inverter > 95.0) faults |= FAULT_THERMAL; if (GetTickCount() - last_ev_message_time > 500) faults |= FAULT_COMM_TIMEOUT; if (GPIO_Read(PIN_EMERGENCY_STOP) == LOW) faults |= FAULT_EMERGENCY_STOP; if (faults != FAULT_NONE) { HandleFault(faults); } return faults; } void HandleFault(uint32_t faults) { // Ramp current to zero for (float i = i_output; i > 0; i -= 10.0) { SetCurrent(i); Delay_ms(100); } // Open contactors OpenAllContactors(); // Log fault LogFault(faults); // Notify backend OCPP_SendStatusNotification("Faulted", faults); } ``` ### Dynamic Current Control - **Scenario**: EV battery heating up during charging, reduces max current from 150A to 100A - **Response**: Charger must follow EV current request dynamically (update every 100-250 ms) - **Slew rate limiting**: ```c float SlewRateLimiter(float target, float current, float max_slew_rate_per_sec, float dt) { float delta = target - current; float max_change = max_slew_rate_per_sec * dt; if (delta > max_change) { return current + max_change; } else if (delta < -max_change) { return current - max_change; } else { return target; } } // In control loop (10 Hz update) float i_target_ev = GetEVCurrentRequest(); // From ISO 15118 float i_command = SlewRateLimiter(i_target_ev, i_output, 50.0, 0.1); SetCurrentSetpoint(i_command); ``` ### Charging Profile and Curve - **Typical DC fast charging curve**: - 0-10% SOC: Constant current (CC) at 80% of max (e.g., 120A for 150A max) -- battery cold - 10-80% SOC: Constant current at 100% of max (150A) -- optimal charging - 80-100% SOC: Constant voltage (CV) taper -- current drops from 150A to 10A as battery fills - **Charger must follow EV current request** (EV BMS controls curve based on battery temp, SOC, cell balance) ## Approach 1. **Hardware design**: Select microcontroller, ADCs, CAN/PLC interface, I/O for contactors 2. **Firmware architecture**: RTOS or bare-metal, separate real-time control from application logic 3. **Control loops**: Implement PI controllers for current and voltage, tune gains 4. **Communication**: Integrate ISO 15118 or CHAdeMO stack, handle message timeouts 5. **Safety**: Implement fault detection, slew rate limiting, watchdog timers 6. **Testing**: HIL (Hardware-in-Loop) with DC power supply and electronic load, simulate EV ## Deliverables - Controller firmware (C/C++) with state machines, control loops, fault handlers - PI/PID tuning parameters (Kp, Ki, Kd values) - Communication protocol stack (ISO 15118 or CHAdeMO) - Test reports (step response, steady-state error, fault injection) - Integration guide (ADC calibration, PWM configuration, CAN setup) ## Best Practices - **Safety first**: Multiple layers of protection (software limits, hardware limits, fuses) - **Calibration**: ADC offset and gain calibration (use precision voltage/current source) - **Anti-windup**: Clamp integral term in PI controller to prevent overshoot - **Watchdog**: Independent watchdog timer (reset if firmware crashes) - **Logging**: Record all faults, voltage, current, temperature for post-mortem analysis ## Integration - **Power electronics**: PWM signals to IGBT/MOSFET gate drivers (optoisolated) - **Sensors**: Voltage dividers (1:100 ratio), Hall effect current sensors (+/-1% accuracy) - **Backend**: OCPP for session data, fault reporting, remote diagnostics - **User interface**: Display charging power, SOC, estimated time remaining ### fleet-charging-management # Fleet Charging Management ## Overview Fleet charging management orchestrates the charging of multiple electric vehicles within a depot or distributed network, optimizing for operational requirements, energy costs, grid constraints, and vehicle availability. ## Key Concepts ### Charging Scheduling - Route-based scheduling aligns charging with departure times - Priority queuing ensures mission-critical vehicles charge first - Staggered charging prevents grid overload during peak demand - Opportunity charging during breaks and layovers ### Load Management - Dynamic load balancing across multiple chargers - Peak demand shaving to reduce utility demand charges - Time-of-use rate optimization for lowest cost charging - Grid capacity monitoring and automatic throttling ## Implementation Guide ### Fleet Charging Scheduler (Python)
from dataclasses import dataclass from datetime import datetime, timedelta from typing import List import heapq
@dataclass class Vehicle: id: str soc: float # Current state of charge (0-100) target_soc: float # Required SOC at departure departure: datetime # Scheduled departure time battery_kwh: float # Battery capacity max_charge_kw: float # Max charging rate
@dataclass class Charger: id: str max_kw: float available: bool = True
class FleetChargingScheduler: def __init__(self, grid_limit_kw: float): self.grid_limit_kw = grid_limit_kw self.chargers: ListCharger] = ] self.schedule = ]
def calculate_charge_time(self, vehicle: Vehicle) -> float: energy_needed = (vehicle.target_soc - vehicle.soc) / 100.0 vehicle.battery_kwh return energy_needed / vehicle.max_charge_kw # hours
def schedule_fleet(self, vehicles: ListVehicle]) -> dict: # Priority queue by urgency (earliest departure, lowest SOC first) priority_queue = ] for v in vehicles: charge_hours = self.calculate_charge_time(v) slack = (v.departure - datetime.now()).total_seconds() / 3600 - charge_hours heapq.heappush(priority_queue, (slack, v.soc, v.id, v))
assignments = {} while priority_queue: slack, soc, vid, vehicle = heapq.heappop(priority_queue) for charger in self.chargers: if charger.available: assignmentsvehicle.id] = { "charger": charger.id, "start": datetime.now().isoformat(), "charge_hours": self.calculate_charge_time(vehicle), "urgency": "HIGH" if slack < 1.0 else "NORMAL" } charger.available = False break return assignments
### Load Balancing Algorithm
def balance_load(chargers, grid_limit_kw): active = c for c in chargers if c.active] if not active: return fair_share = grid_limit_kw / len(active) for charger in active: charger.set_power(min(fair_share, charger.max_kw))
## Best Practices
- Always maintain minimum SOC buffer (10-15%) for unexpected dispatches
- Implement pre-conditioning during charging to optimize battery temperature
- Use historical route data to predict energy consumption accurately
- Monitor charger health and schedule preventive maintenance
- Integrate with fleet management systems via OCPP 2.0.1
## Cost Optimization Strategies
- Shift charging to off-peak hours (typically 10pm-6am)
- Negotiate demand charge reduction with utility through load management
- Participate in demand response programs for revenue generation
- Use on-site solar and battery storage to reduce grid dependency
## Troubleshooting
- Charger communication failures - check OCPP WebSocket connections
- Uneven load distribution - verify current transformer readings
- Missed departure targets - review scheduling algorithm priority weights
- High demand charges - analyze 15-minute demand peaks with utility data
### gb-t-charging
## Core Competencies
Expert in GB/T (Guobiao Tuijian, Chinese National Standard) charging system implementation for electric vehicles, covering both AC (GB/T 20234.2) and DC (GB/T 20234.3) charging standards, CAN-based communication protocol (GB/T 27930), and integration with Chinese smart grid and payment systems.
### GB/T Standards Overview
- **GB/T 20234.1** (General requirements):
- Overall framework for EV conductive charging
- Safety requirements, connector specifications
- Interoperability testing procedures
- **GB/T 20234.2** (AC charging):
- AC connector: 7-pin design, similar to IEC Type 2 (Mennekes)
- Single-phase: 230V, up to 32A (7.4 kW)
- Three-phase: 400V, up to 63A (43 kW)
- Control pilot: PWM signaling at 1 kHz (like J1772/IEC 61851)
- **GB/T 20234.3** (DC charging):
- DC connector: 9-pin design (5 power + 4 communication)
- Voltage range: 200V to 750V (typical: 300-500V)
- Current range: Up to 250A (125 kW at 500V)
- Communication: CAN 2.0A at 250 kbps (GB/T 27930 protocol)
- **GB/T 27930** (Communication protocol):
- CAN-based message exchange between EV and DC charger
- Handshake, charging parameters, real-time control, fault handling
- Similar to CHAdeMO but with different CAN IDs and message structure
### AC Connector (GB/T 20234.2)
- **Pin configuration** (7 pins):
- Pin 1: Ground (PE, protective earth)
- Pin 2: Control pilot (CP, PWM signal)
- Pin 3: L1 (phase 1 / single-phase live)
- Pin 4: L2 (phase 2, optional for three-phase)
- Pin 5: L3 (phase 3, optional for three-phase)
- Pin 6: Neutral (N)
- Pin 7: Connection confirmation (CC, analog voltage divider)
- **Control pilot signaling**:
- PWM at 1 kHz, ±12V square wave (identical to IEC 61851-1)
- Duty cycle encodes available current: I_max = duty × 0.6A
- States: A (12V, disconnected), B (9V, connected), C (6V, charging), E/F (fault)
### DC Connector (GB/T 20234.3)
- **Pin configuration** (9 pins):
- Pin 1: DC+ (positive power, up to 250A)
- Pin 2: DC- (negative power, return path)
- Pin 3: Ground (PE, protective earth)
- Pin 4: A6 (low-voltage auxiliary power +12V from charger)
- Pin 5: A7 (auxiliary ground)
- Pin 6: S+ (CAN-H for GB/T 27930 communication)
- Pin 7: S- (CAN-L for GB/T 27930 communication)
- Pin 8: A+ (charging enable signal from EV)
- Pin 9: A- (charging enable ground)
- **Mechanical**:
- Connector body: Larger than CCS Type 2, smaller than CHAdeMO
- Latch: Manual release button (some variants have electronic lock)
- IP rating: IP54 (dust/water protection)
### GB/T 27930 Communication Protocol
- **CAN bus parameters**:
- Baud rate: 250 kbps (CAN 2.0A, 11-bit identifier)
- Bus termination: 120Ω at both ends (EV and charger)
- Message period: 250 ms for most messages (4 Hz update rate)
- Watchdog: Abort if no message received for >1 second
- **Key CAN messages** (GB/T 27930):
- 0x100: Charger handshake (protocol version, charger ID)
- 0x101: Charger ready (max voltage, max current, charger status)
- 0x102: EV handshake (EV ID, battery capacity)
- 0x103: EV charging parameters (max voltage, max current, battery type)
- 0x104: EV charging demand (target voltage, target current, SOC)
- 0x105: Charger status (output voltage, output current, faults)
- 0x106: EV status (battery voltage, battery current, temperature, SOC)
- 0x107: Charger stop (stop reason, final energy delivered)
- **Message structure example** (0x104: EV charging demand):void SendEVDemand(float v_target, float i_target, uint8_t soc) { EVChargingDemand_t msg = { .target_voltage = (uint16_t)(v_target 10), .target_current = (uint16_t)(i_target 10), .charging_mode = (soc < 80) ? 0x00 : 0x01, // CC until 80%, then CV .soc = soc, .remaining_time = calculate_remaining_time(soc) }; CAN_Send(0x104, (uint8_t)&msg, sizeof(msg)); }
python class GBTChargerState(Enum): IDLE = 0 HANDSHAKE = 1 INSULATION_TEST = 2 PRECHARGE = 3 CHARGING = 4 STOPPING = 5 FAULT = 6def state_machine(): if state == GBTChargerState.HANDSHAKE: send_charger_handshake() if ev_handshake_received(): state = GBTChargerState.INSULATION_TEST elif state == GBTChargerState.INSULATION_TEST: r_iso = measure_insulation() if r_iso > 100000: # >100 kΩ for 1000V system state = GBTChargerState.PRECHARGE elif state == GBTChargerState.PRECHARGE: if abs(dc_voltage - ev_battery_voltage) < 20: close_contactors() state = GBTChargerState.CHARGING elif state == GBTChargerState.CHARGING: regulate_output(ev_target_voltage, ev_target_current) if ev_target_current < 5 or fault_detected(): state = GBTChargerState.STOPPING ``` ## Approach 1. **Standard compliance**: Study GB/T 20234.3 and 27930 specifications (Chinese language) 2. **Connector sourcing**: GB/T inlet/outlet from Chinese suppliers (e.g., WOER, Kayal) 3. **CAN stack**: Implement GB/T 27930 message handlers (250 ms periodic transmission) 4. **Power electronics**: DC-DC converter (200-750V output, 50-125 kW typical) 5. **Safety circuits**: IMD (insulation monitoring device), RCD (residual current device) 6. **Testing**: Interoperability testing with Chinese EV brands (BYD, NIO, XPeng, Li Auto) 7. **Certification**: CQC (China Quality Certification Centre) approval ## Deliverables - GB/T charger controller firmware (C/C++) - GB/T 27930 CAN protocol stack - Insulation monitoring and safety system - Charger to EV handshake and parameter negotiation - Test reports (protocol conformance, safety, interoperability) - Integration guide for Chinese payment systems (WeChat Pay, Alipay) ## Best Practices - **Language barrier**: GB/T standards in Chinese; work with translation or local experts - **CAN timing**: Strict 250 ms message period (use hardware timer, not software delay) - **Insulation test**: Perform before every charge session (mandatory per GB/T 18487) - **SOC accuracy**: Chinese EVs expect accurate SOC reporting (calibrate BMS) - **ChaoJi readiness**: Design for future ChaoJi migration (higher power, new connector) ## Integration - **Payment**: WeChat Pay, Alipay QR code scanning at charger - **Grid**: Integration with State Grid Corporation of China (SGCC) smart grid - **Fleet**: API for Chinese fleet operators (DiDi, Geely, BYD fleets) - **Roaming**: Cross-operator charging via Chinese roaming platforms ### iso-15118-plug-and-charge ## Core Competencies Expert in ISO 15118 implementation for advanced electric vehicle charging, covering Plug & Charge automated authentication using X.509 certificates, EXI-encoded message exchange, high-level V2G communication protocol, and integration with charging infrastructure backend systems. ### ISO 15118 Overview - **Purpose**: - Enable Plug & Charge: Automatic authentication without RFID card or app - Smart charging: EV and EVSE negotiate power schedules dynamically - Bidirectional V2G: Vehicle can discharge battery to grid (ISO 15118-20) - Future-proof: Support AC, DC, wireless, and inductive charging - **Protocol versions**: - **ISO 15118-2** (2014): V2G communication for AC and DC charging - **ISO 15118-20** (2022): Enhanced for bidirectional power transfer, improved smart charging - **Communication layers**: - Physical: PLC (PowerLine Communication) via Control Pilot (CP) line - Data link: HomePlug Green PHY (HPGP) for OFDM modulation - Network: IPv6 (link-local addresses, no router needed) - Transport: TCP for reliable message delivery - Application: V2GTP (Vehicle-to-Grid Transfer Protocol), EXI-encoded XML messages ### SLAC (Signal Level Attenuation Characterization) - **Purpose**: Establish PLC link between EV and EVSE before high-level communication - **Process**: 1. EV broadcasts CM_SLAC_PARM.REQ (request SLAC parameters) 2. EVSE responds with CM_SLAC_PARM.CNF (confirmation, EVSE MAC address) 3. EV sends CM_START_ATTEN_CHAR.IND (start attenuation characterization) 4. EVSE sends multiple CM_ATTEN_CHAR.IND (attenuation measurements on different subcarriers) 5. EV evaluates signal quality, selects best EVSE (if multiple nearby) 6. EV sends CM_SLAC_MATCH.REQ (request to establish connection) 7. EVSE responds with CM_SLAC_MATCH.CNF (confirm, provide network ID and key) 8. PLC link established, IPv6 addresses assigned - **Timing**: SLAC typically completes in 2-5 seconds (depends on RF environment) ### IPv6 and V2GTP - **IPv6 link-local addressing**: - EV: fe80::1 (or auto-generated from MAC address) - EVSE: fe80::2 - No DHCP needed (link-local scope sufficient for direct EV-EVSE communication) - **V2GTP (V2G Transfer Protocol)**: - Thin protocol layer above TCP (port 15118) - Encapsulates EXI-encoded application messages - Header: Version, PayloadType (EXI or SDP for discovery) - Used for service discovery and main charging messages - **SDP (Service Discovery Protocol)**: - UDP broadcast to discover EVSE on network - EV sends SECC Discovery Request - EVSE responds with SECC Discovery Response (IP address, port, security level) ### EXI Encoding - **EXI (Efficient XML Interchange)**: - Binary encoding of XML (10× smaller, 100× faster to parse than text XML) - Schema-informed: EV and EVSE share XSD schema (ISO 15118-2 message definitions) - Compression: Huffman coding for element names, values - **Example message** (SessionSetupReq):
c #include <openv2g/appHandshake.h> #include <openv2g/xmldsig.h>int encode_session_setup_req(uint8_t* buffer, size_t max_len) { bitstream_t stream; struct SessionSetupReqType req; // Initialize bitstream bitstream_init(&stream, buffer, max_len); // Populate message req.Header.SessionID.bytesLen = 8; memcpy(req.Header.SessionID.bytes, session_id, 8); req.EVCCID.bytesLen = 6; memcpy(req.EVCCID.bytes, evc_id, 6); // Encode to EXI encode_v2gSessionSetupReqType(&stream, &req); return stream.byte_pos; // Return encoded length } ``` ### Plug & Charge Authentication - **Certificate hierarchy** (PKI): - Root CA: OEM or mobility operator root certificate - Sub-CA1: Provisioning certificate (for initial vehicle enrollment) - Sub-CA2: Contract certificate (for billing, issued to driver account) - Leaf certificate: Vehicle certificate (unique per EV, tied to VIN) - **Certificate provisioning**: 1. Vehicle installed with provisioning certificate at factory 2. Driver creates account with eMSP (e-Mobility Service Provider) 3. eMSP issues contract certificate to vehicle via backend (OTA update) 4. Vehicle stores contract certificate in secure element (TPM or HSM) 5. At charge session, vehicle presents contract certificate to EVSE 6. EVSE validates certificate chain, checks revocation (OCSP or CRL) 7. If valid, EVSE grants access without RFID/payment card - **TLS handshake**: - Client (EV): Presents contract certificate - Server (EVSE): Validates certificate, checks expiry, revocation status - Mutual TLS: EVSE also presents certificate (authenticates charging station) - Session key: Established for encrypted message exchange (AES-128 or AES-256) - **Certificate validation**:
return True
(Typically done during initial provisioning, not every charge session)
python charging_schedule = { "schedules": [ {"start": "22:00", "duration": 180, "power_limit": 7.4, "price": 0.10}, # Cheap overnight {"start": "01:00", "duration": 300, "power_limit": 7.4, "price": 0.08}, # Super cheap 1-6am {"start": "06:00", "duration": 120, "power_limit": 3.6, "price": 0.25} # Peak morning ] }# EV selects schedule to charge during cheapest hours ev_schedule = optimize_charging( current_soc=20, target_soc=80, battery_capacity=60, # kWh departure_time="07:00", schedules=charging_schedule ) # Result: Charge 7.4 kW from 22:00-01:00 (22.2 kWh), then 7.4 kW 01:00-06:00 (37 kWh), done by 6am ``` ### Bidirectional V2G (ISO 15118-20) - **Discharge to grid**: - EV sends "Discharging mode" flag in PowerDeliveryReq - Negative current: EV supplies power to grid (instead of drawing) - Use case: Grid frequency regulation, peak shaving, backup power - **V2G schedule**: - Grid operator sends discharge request (e.g., "Need 10 kW from 5-6 PM") - EV checks battery SOC, user preferences (minimum reserve for driving range) - If acceptable, EV discharges at requested power level - **Revenue model**: - EV owner compensated for energy exported ($/kWh) and grid services ($/kW capacity) - Example: $0.40/kWh for peak discharge + $5/kW/month for capacity reservation ## Approach 1. **PLC modem integration**: Integrate HPGP modem (Qualcomm QCA7000, Broadcom) 2. **ISO 15118 stack**: Use open-source library (RISE-V2G, OpenV2G) or commercial (Vector, Siemens) 3. **Certificate management**: Set up PKI infrastructure (root CA, provisioning, contract certs) 4. **EXI codec**: Integrate EXI processor (ExiCPP, OpenEXI) 5. **Backend integration**: Connect EVSE to eMSP for certificate validation, billing 6. **Testing**: Use CharIN test suite, interoperability testing with multiple EVs ## Deliverables - ISO 15118 protocol stack (C/C++/Java) - PLC modem driver and SLAC implementation - EXI encoder/decoder for message serialization - Certificate provisioning and validation logic - Backend API for billing, authorization, session logging - Test reports (CharIN compliance, interoperability) ## Best Practices - **Security**: Store private keys in secure element (TPM, HSM), never in software - **Certificate expiry**: Auto-renew contract certificates before expiry (OTA update) - **OCSP stapling**: Cache OCSP responses to reduce latency during authorization - **Fallback**: If Plug & Charge fails, fall back to RFID or app-based authentication - **Logging**: Record all ISO 15118 messages for debugging interoperability issues ## Integration - **OCPP**: ISO 15118 session data (energy, duration) sent to CSMS via OCPP - **eMSP**: Backend validates certificates, manages billing, sends invoices - **Vehicle backend**: OEM server provisions certificates, monitors charge sessions - **Grid operator**: V2G schedules sent from utility to EVSE to EV ### megawatt-charging ## Core Competencies Expert in Megawatt Charging System (MCS) implementation for heavy-duty electric vehicles including trucks, buses, construction equipment, and marine vessels, covering ultra-high-power delivery (up to 3.75 MW), liquid-cooled cables, and charging orchestration for depot and corridor charging. ### MCS Overview - **Target vehicles**: - Class 7-8 electric trucks (e.g., Tesla Semi, Freightliner eCascadia) - Electric buses (battery capacity: 300-600 kWh) - Construction equipment (excavators, loaders, dump trucks) - Port equipment (gantry cranes, straddle carriers) - Marine vessels (electric ferries, tugboats) - **Power levels**: - MCS1: Up to 1 MW (1000V × 1000A) - MCS2: Up to 1.5 MW (1250V × 1200A) - MCS3: Up to 3 MW (1500V × 2000A) - MCS4 (future): Up to 3.75 MW (1500V × 2500A) - **Charging speed examples**: - 500 kWh battery at 1 MW: 30 minutes to 80% SOC (400 kWh delivered) - 1 MWh battery at 3 MW: 20 minutes to 80% SOC (800 kWh delivered) ### SAE J3271 Connector Specification - **Physical design**: - Connector weight: ~3-5 kg (without cable) - Cable diameter: 50-70 mm (includes coolant hoses) - Pins: 4 power + 4 communication + 2 cooling + ground - Locking mechanism: Electric actuator (manual unlocking impossible at this size) - IP rating: IP67 (submersible for outdoor/marine use) - **Pin configuration**: - Pin 1: DC+ (positive power, 1000-1500V) - Pin 2: DC- (negative power return) - Pin 3: Ground (PE, protective earth) - Pin 4: DC+ sense (voltage measurement for droop compensation) - Pin 5: DC- sense (voltage measurement) - Pin 6: CAN-H (communication, 500 kbps) - Pin 7: CAN-L (communication) - Pin 8: Auxiliary power (12V/24V for connector lock, cooling pump) - Pin 9: Coolant inlet (glycol-water mix) - Pin 10: Coolant outlet (return to charger heat exchanger) ### Liquid Cooling System - **Thermal challenges**: - Cable power loss: ~1 kW heat generation at 2000A (50 µΩ/m × 5 m cable) - Connector contact resistance: ~50 µΩ per contact → 200W heat at 2000A - Pin temperature limit: <80°C (derating required above this) - **Cooling loop design**: - Coolant: 50/50 water-glycol (ethylene glycol or propylene glycol) - Flow rate: 5-10 L/min per cable (maintains conductor <60°C at 2000A) - Pump: Centrifugal pump in charger cabinet, 1-2 bar pressure - Heat exchanger: Plate heat exchanger, coolant to ambient air or water - Hose diameter: 1/2" (12.7 mm) for inlet/outlet in cable - **Temperature monitoring**: - NTC thermistors at connector inlet, cable mid-point, charger outlet - Safety threshold: Abort charge if any sensor >75°C - Derating: Reduce current by 10% per 5°C above 60°C - **Coolant control**:
float CalculateMaxCurrent(float connector_temp) { float max_current = 2000.0; // Rated 2000A if (connector_temp > MAX_TEMP_C) { return 0.0; // Emergency stop } if (connector_temp > DERATE_START_TEMP_C) { // Derate 10% per 5°C above 60°C float derate_factor = 1.0 - 0.1 ((connector_temp - DERATE_START_TEMP_C) / 5.0); max_current = derate_factor; } return max_current; }
python def mcs_charging_loop(): while charging: # Receive vehicle demand (20 Hz) vehicle_msg = can_receive(0x200) target_voltage = vehicle_msg.target_voltage # V target_current = vehicle_msg.target_current # A# Apply system limits actual_current = min( target_current, CHARGER_MAX_CURRENT, CABLE_MAX_CURRENT, thermal_limit(connector_temp) ) # Compensate for cable voltage drop cable_drop = actual_current * CABLE_RESISTANCE # e.g., 2000A × 0.05Ω = 100V charger_output_voltage = target_voltage + cable_drop # Send to power modules set_output(charger_output_voltage, actual_current) # Report back to vehicle can_send(0x201, present_voltage, present_current, charger_status) time.sleep(0.05) # 50 ms loop ``` ### Depot Charging Management - **Fleet scheduling**: - Vehicles return to depot at staggered times (evening for buses, night for trucks) - Charging priority: Route assignment for next day (high priority), battery health (low SOC first) - Load balancing: Distribute available grid power (e.g., 10 MW) across 20 chargers - **Smart charging algorithm**:
for vehicle in vehicles: energy_needed = (vehicle.target_soc - vehicle.current_soc) vehicle.battery_capacity time_available = vehicle.departure_time - current_time min_power_required = energy_needed / time_available
Expert in NACS (North American Charging Standard), the connector and protocol originally developed by Tesla and now adopted by major automakers (Ford, GM, Rivian, Hyundai, Nissan, etc.), covering both AC (up to 19.2 kW) and DC (up to 1 MW) charging on a single compact connector.
c // Example: NACS-CCS protocol translator typedef struct { float target_voltage; // V float target_current; // A float present_voltage; // V float present_current; // A bool charging_enabled; } ChargingState_t;void TranslateNACSToISO15118(ChargingState_t* state) { // Receive Tesla CAN message (0x210: target V/I) TeslaCAN_Msg_t tesla_msg; if (CAN_Receive(&tesla_msg)) { state->target_voltage = tesla_msg.target_voltage; state->target_current = tesla_msg.target_current; } // Send ISO 15118 CurrentDemandReq via PLC ISO15118_CurrentDemandReq_t iso_msg = { .EV_TargetVoltage = state->target_voltage, .EV_TargetCurrent = state->target_current, .EVReady = state->charging_enabled }; PLC_SendMessage(&iso_msg); // Receive ISO 15118 CurrentDemandRes ISO15118_CurrentDemandRes_t iso_res; if (PLC_ReceiveMessage(&iso_res)) { state->present_voltage = iso_res.EVSE_PresentVoltage; state->present_current = iso_res.EVSE_PresentCurrent; } // Send back to Tesla vehicle via CAN (0x220: present V/I) TeslaCAN_Msg_t tesla_res = { .present_voltage = state->present_voltage, .present_current = state->present_current }; CAN_Send(&tesla_res); } ``` ### NACS Charging Station Implementation - **Supercharger architecture**: - Power cabinet: 12-16 charger modules per cabinet (each ~30 kW) - Dynamic load sharing: Distribute total power across 4-8 stalls (e.g., 1 MW cabinet shared) - Liquid cooling: Glycol-cooled cables for >300A charging (3/8" coolant hose in cable) - Central controller: Manage load balancing, user authentication, billing - **Authentication**: - Tesla vehicles: Automatic (vehicle VIN sent via CAN, linked to Tesla account) - Non-Tesla vehicles: Supercharger app (select stall, authorize payment) - Future: ISO 15118 Plug & Charge for all NACS vehicles (certificate-based auth) - **Billing integration**: - Energy metering: MID-certified meter in power cabinet (kWh accuracy ±2%) - Pricing: Per-kWh or per-minute (varies by location, time of day) - Payment: Credit card on file (Tesla account) or app-based for non-Tesla ### Thermal Management - **Cable cooling** (for >250 kW charging): - Liquid-cooled cable: Copper conductors + coolant channels - Coolant: 50/50 water-glycol mix, circulated by pump in power cabinet - Flow rate: ~2 L/min per cable (prevents >60°C conductor temperature) - Connector temperature sensor: NTC thermistor in inlet, abort charge if >70°C - **Thermal control logic**:
if connector_temp > 60: max_current = 400 # Derate 20% if connector_temp > 70: max_current = 0 # Emergency stop if cable_temp > 50: max_current = min(max_current, 350) return max_current
Expert in smart charging algorithm development for electric vehicles, covering load balancing, demand response, time-of-use optimization, renewable energy integration, and coordination of charging across multiple EVs to minimize cost, reduce grid impact, and maximize renewable energy utilization.
python def tou_optimize(arrival_time, departure_time, current_soc, target_soc, battery_capacity, charge_power): energy_needed = (target_soc - current_soc) * battery_capacity # kWh charge_duration = energy_needed / charge_power # hours# Get TOU schedule for charging window tou_schedule = get_tou_rates(arrival_time, departure_time) # Sort periods by rate (cheapest first) tou_schedule.sort(key=lambda x: x.rate) # Allocate charging to cheapest periods charge_schedule = [] remaining_energy = energy_needed for period in tou_schedule: if remaining_energy <= 0: break period_duration = min(period.duration, remaining_energy / charge_power) charge_schedule.append({ "start": period.start_time, "duration": period_duration, "power": charge_power, "rate": period.rate }) remaining_energy -= period_duration * charge_power return charge_schedule # Example schedule = tou_optimize( arrival_time="18:00", departure_time="07:00", current_soc=20, target_soc=90, battery_capacity=60, # kWh charge_power=7.4 # kW ) # Result: Charge 0:00-5:36 @ $0.08/kWh (42 kWh × $0.08 = $3.36) # vs. dumb charging 18:00-23:40 @ $0.35/kWh (42 kWh × $0.35 = $14.70) # Savings: $11.34 per charge session ``` ### Load Balancing for Multi-EV Charging - **Scenario**: 10 EVs in apartment building, shared 50 kW service - **Challenge**: Without load balancing, 10× 7.4 kW = 74 kW demand (exceeds 50 kW) - **Solution**: Dynamic load management distributes 50 kW across EVs based on priority - **Load balancing algorithm**:
allocated_power = {} remaining_power = max_power_available for ev in evs: # Calculate minimum power needed to reach target by departure time_to_departure = (ev.departure_time - current_time).total_seconds() / 3600 energy_needed = (ev.target_soc - ev.soc) ev.battery_capacity min_power_required = energy_needed / time_to_departure
allocated_powerev.id] = allocated remaining_power -= allocated if remaining_power <= 0: break
return allocated_power
python def solar_forecast_optimization(solar_forecast, ev_arrival, ev_departure, energy_needed): # Solar forecast: kW output for each hour # Goal: Maximize charging from solar, minimize grid importcharge_schedule = [] remaining_energy = energy_needed # Sort hours by solar output (highest first) solar_sorted = sorted(solar_forecast, key=lambda x: x.solar_kw, reverse=True) for hour in solar_sorted: if remaining_energy <= 0: break # Charge during high solar periods if hour.time >= ev_arrival and hour.time < ev_departure: charge_power = min(hour.solar_kw, 7.4, remaining_energy / 1.0) charge_schedule.append({ "time": hour.time, "power": charge_power, "source": "solar" if charge_power <= hour.solar_kw else "mixed" }) remaining_energy -= charge_power # If not enough solar, fill in with grid power during cheap hours if remaining_energy > 0: charge_schedule += tou_optimize(ev_arrival, ev_departure, remaining_energy) return charge_schedule # Example solar_forecast = [ {"time": "10:00", "solar_kw": 3.5}, {"time": "11:00", "solar_kw": 4.2}, {"time": "12:00", "solar_kw": 4.8}, # Peak solar {"time": "13:00", "solar_kw": 4.5}, {"time": "14:00", "solar_kw": 3.8}, {"time": "15:00", "solar_kw": 2.9}, ] # Result: Charge 12:00-15:00 from solar (15 kWh), then overnight from grid (remaining) ``` ### Demand Response Participation - **Demand response programs**: - Utility sends signal: "Reduce load by 50% for next 2 hours (peak event)" - Smart charger responds: Pause charging or reduce power - Incentive: $1-3/kWh for load reduction - **OpenADR (Open Automated Demand Response)**:
if event.signal == "MODERATE": reduction_factor = 0.5 # Reduce charging by 50% elif event.signal == "HIGH": reduction_factor = 1.0 # Stop charging completely else: reduction_factor = 0.0 # No reduction
python def depot_charging_optimization(buses, total_power_limit, start_time, end_time): # Sort by departure time (earliest first = highest priority) buses.sort(key=lambda b: b.departure_time)# Time-step simulation (15-minute intervals) time = start_time while time < end_time: # Allocate power each interval remaining_power = total_power_limit for bus in buses: if bus.soc >= bus.target_soc: continue # Already charged # Calculate time remaining to departure time_remaining = (bus.departure_time - time).total_seconds() / 3600 if time_remaining > 0: # Minimum power needed to finish by departure energy_needed = (bus.target_soc - bus.soc) * bus.battery_capacity min_power = energy_needed / time_remaining # Allocate power (respect charger limit and grid limit) allocated = min(bus.charger_max_power, min_power * 1.1, remaining_power) bus.charge(allocated, duration=0.25) # 15 min remaining_power -= allocated time += timedelta(minutes=15) return buses # Return charged buses with SOC and power profiles ``` - **Result**: Spread charging evenly across 9 hours → 2 MW sustained vs 2.5 MW peak - Demand charge savings: (2.5 - 2.0) MW × $15/kW = $7500/month = $90K/year ### Vehicle-to-Grid (V2G) Optimization - **Bidirectional power flow**: Charge when cheap, discharge when expensive or needed by grid - **Arbitrage opportunity**: - Charge overnight: $0.08/kWh - Discharge during peak: $0.35/kWh - Profit: $0.27/kWh (minus battery degradation ~$0.03/kWh) = $0.24/kWh - **V2G scheduling**:
return charge_schedule, discharge_schedule
python training_data = [ # Day, arrival_time, departure_time, arrival_soc, target_soc, day_of_week {"day": "2024-01-15", "arrival": "18:30", "departure": "07:00", "arrival_soc": 35, "target_soc": 90, "dow": "Mon"}, {"day": "2024-01-16", "arrival": "19:00", "departure": "07:30", "arrival_soc": 40, "target_soc": 90, "dow": "Tue"}, # ... thousands of records ]# Train model model = RandomForestRegressor() X = [[record["dow"], record["arrival"], record["arrival_soc"]] for record in training_data] y = [record["target_soc"] for record in training_data] model.fit(X, y) # Predict for new session predicted_target_soc = model.predict([[day_of_week, arrival_time, current_soc]]) # Use prediction for smart charging optimization ``` ## Approach 1. **Data collection**: Gather TOU rates, solar forecast, EV parameters, user preferences 2. **Algorithm selection**: Choose optimization method (linear programming, heuristic, ML) 3. **Implementation**: Code algorithm in Python/C++, integrate with charger control 4. **Testing**: Simulate scenarios (high solar day, demand response event, multi-EV) 5. **Deployment**: Roll out to chargers, monitor performance, iterate 6. **User interface**: Mobile app to show schedule, estimated cost, override options ## Deliverables - Smart charging algorithm (Python/C++ code) - Optimization models (TOU, load balancing, renewable integration, V2G) - Integration with OCPP or ISO 15118 for charging control - User interface (mobile app or web dashboard) - Simulation results (cost savings, grid impact reduction) - Documentation (algorithm logic, tuning parameters, API) ## Best Practices - **User control**: Allow manual override (user can force charge if urgent) - **Margin of safety**: Add 10-20% buffer to ensure SOC target met by departure - **Transparency**: Show user why charging delayed (cheaper rate coming, solar forecast) - **Fallback**: If optimization fails, default to immediate charging (safety net) - **Privacy**: Anonymize user data for ML training, secure communication ## Integration - **OCPP**: Send smart charging profiles to chargers (SetChargingProfile message) - **ISO 15118**: Negotiate charging schedule directly with EV - **OpenADR**: Receive demand response signals from utility - **Home energy management**: Coordinate with solar inverter, battery, HVAC - **Fleet management**: API for fleet operator to set priorities, monitor progress ### v2g-vehicle-to-grid # Vehicle-to-Grid (V2G) Implementation ## Overview Vehicle-to-Grid enables EVs to provide grid services by discharging stored energy back to the power grid. This creates revenue streams for EV owners while helping stabilize the grid during peak demand or renewable intermittency. ## Key Concepts ### Bidirectional Power Flow - AC V2G uses bidirectional on-board chargers (OBC) - DC V2G uses bidirectional off-board chargers (EVSE) - Power factor correction required for grid code compliance - Anti-islanding protection per IEEE 1547 ### Grid Services - Frequency regulation (primary, secondary, tertiary reserves) - Peak shaving and load leveling - Demand response (curtailment and dispatch) - Voltage support and reactive power compensation - Spinning reserves and capacity markets ## Implementation Guide ### V2G Controller (C Implementation)
typedef struct { float grid_frequency_hz; float target_frequency_hz; float deadband_hz; float droop_percent; float max_discharge_kw; float battery_soc; float min_soc_limit; } V2GController;
float v2g_frequency_regulation(V2GController ctrl) { float freq_error = ctrl->grid_frequency_hz - ctrl->target_frequency_hz;
// Deadband - no action needed if (fabs(freq_error) < ctrl->deadband_hz) return 0.0f;
// Droop control float power_setpoint = -(freq_error / (ctrl->target_frequency_hz ctrl->droop_percent / 100.0f)) ctrl->max_discharge_kw;
// SOC protection if (ctrl->battery_soc <= ctrl->min_soc_limit && power_setpoint > 0) return 0.0f;
// Clamp to rated power if (power_setpoint > ctrl->max_discharge_kw) power_setpoint = ctrl->max_discharge_kw; if (power_setpoint < -ctrl->max_discharge_kw) power_setpoint = -ctrl->max_discharge_kw;
return power_setpoint; }
### ISO 15118-20 V2G Communication
class V2GSession: def __init__(self, evse_id, vehicle_id): self.evse_id = evse_id self.vehicle_id = vehicle_id
def negotiate_energy_transfer(self, direction, max_power_kw): msg = { "session_id": self.session_id, "energy_transfer_mode": direction, "max_power_kw": max_power_kw, "schedule": self.get_schedule() } return self.send_v2g_message("EnergyTransferRequest", msg)
def get_schedule(self): return {"start": "22:00", "end": "06:00", "mode": "CHARGE", "kw": 7.4}, {"start": "17:00", "end": "20:00", "mode": "DISCHARGE", "kw": 5.0}, ]
## Revenue Model
- Frequency regulation markets pay $20-40/MWh
- Capacity markets pay $50-150/kW-year
- Peak shaving saves $10-15/kW in demand charges
- Battery degradation cost must be factored ($5-15/MWh equivalent)
## Best Practices
- Always maintain user-configured minimum SOC for driving needs
- Factor battery degradation costs into revenue calculations
- Implement thermal management during V2G to reduce battery stress
- Use forecasting to optimize charge/discharge schedules
- Comply with local utility interconnection requirements
## Troubleshooting
- Anti-islanding protection triggering falsely - verify impedance settings
- Power quality issues - check THD and power factor at coupling point
- Communication timeouts - verify ISO 15118 TLS certificate chain
- Revenue below expectations - review market pricing and scheduling
### v2h-vehicle-to-home
## Core Competencies
Expert in Vehicle-to-Home (V2H) systems enabling electric vehicles to power residential loads during grid outages or peak demand periods, covering bidirectional inverter control, automatic transfer switch integration, islanding detection, and coordinated operation with home solar and battery storage.
### V2H System Architecture
- **Components**:
- **EV battery**: 40-100 kWh energy storage (enough for 1-3 days of home power)
- **Bidirectional charger**: 6-10 kW typical (V2H-capable EVSE or onboard inverter)
- **Automatic Transfer Switch (ATS)**: Switches home from grid to EV during outage
- **Critical loads panel**: Separates critical loads (fridge, lights) from non-critical (AC, pool pump)
- **Energy management system (EMS)**: Coordinates solar, battery, EV, grid
- **Operating modes**:
- **Grid-connected**: Normal charging, EV battery replenished from grid or solar
- **Backup mode**: Grid outage detected, ATS switches home to EV power
- **Peak shaving**: Discharge EV during high electricity rates (4-9 PM)
- **Solar time-shift**: Charge EV from solar during day, power home at night
### Automatic Transfer Switch (ATS) Integration
- **ATS function**:
- Normally connected: Grid → home loads
- Outage detection: Grid voltage drops or frequency out of range
- Transfer: Disconnect grid, connect EV inverter to loads (<1 second)
- Retransfer: Grid restored, switch back after 5-minute delay (avoid false switching)
- **ATS types**:
- **Open transition**: Break-before-make (momentary power loss during switch)
- **Closed transition**: Make-before-break (seamless, but requires synchronization)
- **Soft load**: Gradual ramping of EV power to avoid inrush current spike
- **Critical loads selection**:
- Essential: Refrigerator (500W), lights (300W), furnace blower (600W), garage door (200W)
- Non-essential: Air conditioner (3000W), electric stove (5000W), water heater (4500W)
- Typical critical load: 2-3 kW continuous, 5 kW peak
- **ATS wiring** (simplified single-line diagram):python def anti_islanding_control(): grid_voltage = measure_grid_voltage() grid_frequency = measure_grid_frequency()# Check for grid outage if grid_voltage < 106 or grid_voltage > 132: # For 120V nominal grid_outage_detected = True elif grid_frequency < 59.3 or grid_frequency > 60.5: grid_outage_detected = True else: grid_outage_detected = False if grid_outage_detected: if ats_installed: # Switch to backup mode ats_transfer_to_ev() inverter_mode = ISLAND_MODE # EV forms voltage reference log("V2H backup mode activated") else: # Shut down per IEEE 1547 inverter_shutdown() log("Grid outage detected, inverter shut down") ``` ### Load Management - **Load prioritization**: - Tier 1: Life-safety (medical equipment, sump pump, heat in winter) - Tier 2: Comfort (lights, refrigerator, TV, internet router) - Tier 3: Convenience (microwave, coffee maker, phone chargers) - Tier 4: Optional (washing machine, dryer, dishwasher) - **Dynamic load shedding**: - Monitor EV battery SOC during outage - If SOC drops below 30%: Shed Tier 4 loads - If SOC drops below 20%: Shed Tier 3 loads, keep only Tier 1+2 - Reserve 10-20% SOC for emergency driving (evacuation scenario) - **Load shedding algorithm**:
if soc < 20: # Critical only: Fridge, lights, furnace allowed_loads = load for load in critical_loads if load.tier <= 2] max_power = 2000 # Limit to 2 kW elif soc < 30: allowed_loads = load for load in critical_loads if load.tier <= 3] max_power = 5000 # 5 kW else: allowed_loads = critical_loads # All loads
return total_power
python def solar_ev_battery_coordination(): solar_power = measure_solar_output() # kW home_load = measure_home_consumption() # kW battery_soc = get_stationary_battery_soc() ev_soc = get_ev_soc()if grid_available: # Grid-connected mode if solar_power > home_load: # Excess solar: Charge EV or battery excess = solar_power - home_load if ev_soc < 80: charge_ev(excess) elif battery_soc < 100: charge_battery(excess) else: export_to_grid(excess) else: # Solar deficit: Draw from grid deficit = home_load - solar_power import_from_grid(deficit) else: # Backup mode (grid outage) net_load = home_load - solar_power if net_load > 0: # Need more power if battery_soc > 10: discharge_battery(net_load) elif ev_soc > 20: discharge_ev(net_load) else: load_shed() # Not enough energy else: # Excess solar: Charge EV or battery if battery_soc < 100: charge_battery(-net_load) elif ev_soc < 80: charge_ev(-net_load) ``` ### Peak Shaving Use Case - **Demand charges**: - Some utilities charge based on peak 15-minute power draw (e.g., $15/kW/month) - Example: Home peaks at 10 kW for 15 minutes → $150/month demand charge - V2H discharge during peak → reduce to 5 kW → save $75/month ($900/year) - **Time-of-use (TOU) arbitrage**: - Charge EV overnight: $0.08/kWh (off-peak) - Discharge to home during peak: $0.35/kWh (4-9 PM) - Arbitrage: $0.27/kWh × 15 kWh/day = $4/day = $1460/year ### Safety and Compliance - **Electrical code (NEC)**: - Article 702: Optional standby systems (V2H falls under this) - Separate critical loads panel required - ATS must be listed (UL 1008) and properly rated - Bonding: Neutral-ground bond only at one point (avoid ground loops) - **Permit and inspection**: - Electrical permit required for ATS installation - Inspector verifies: Proper ATS wiring, critical loads sizing, grounding - Some jurisdictions require engineer stamp for >10 kW systems - **Utility notification**: - Inform utility of V2H installation (may require interconnection agreement) - Bidirectional meter if exporting to grid (V2G mode) - If backup only (no export), notification may be sufficient ### User Experience - **Automatic operation**: - Plug in EV at night → charges normally - Grid outage → ATS switches automatically, home stays powered - User may not even notice outage (if loads within EV capacity) - **Mobile app**: - Monitor EV SOC, home power consumption, backup duration estimate - Alerts: "Grid outage detected, running on EV power (18 hours remaining)" - Manual override: "Reserve full EV battery for trip tomorrow" (disable V2H) - **Notifications**: - Grid outage: SMS/push notification - Low EV SOC: "Battery at 25%, consider reducing loads" - Grid restored: "Power restored, EV resuming charging" ## Approach 1. **Load analysis**: Measure home energy consumption, identify critical loads 2. **Sizing**: Determine EV inverter capacity (typical 6-10 kW) and ATS rating 3. **Electrical design**: Critical loads panel, ATS location, conduit routing 4. **Equipment selection**: Bidirectional charger (Wallbox Quasar, Fermata, Dcbel), ATS (Generac, Kohler) 5. **Installation**: Licensed electrician, permit, inspection 6. **Commissioning**: Test outage scenario, verify load shedding, user training ## Deliverables - V2H system design (single-line diagram, load calculations) - Equipment specifications (bidirectional charger, ATS, critical loads panel) - Electrical permit drawings - Load management software (prioritization, shedding algorithm) - User manual (operation, mobile app, emergency procedures) - Test report (ATS transfer time, inverter performance, backup duration) ## Best Practices - **Reserve for driving**: Always keep 20% SOC minimum (emergency evacuation) - **Maintenance**: Test V2H system monthly (simulate outage, verify ATS operation) - **Battery health**: Limit V2H cycling to 20-80% SOC (minimize degradation) - **Solar integration**: Prioritize solar charging during outages (extend duration) - **User education**: Train homeowner on load management, SOC monitoring ## Integration - **Home energy management**: Coordinate with smart thermostat, appliances (OpenHAB, Home Assistant) - **Solar inverter**: Data sharing via Modbus or API (SolarEdge, Enphase) - **Stationary battery**: Powerwall API for coordinated dispatch - **Utility programs**: Demand response enrollment (earn incentives for peak shaving) ### v2l-vehicle-to-load ## Core Competencies Expert in Vehicle-to-Load (V2L) systems enabling electric vehicles to supply AC power to external loads via built-in outlets or adapters, covering onboard inverter control, protection circuits, power management, and use cases for portable power delivery. ### V2L System Overview - **Purpose**: Use EV battery as mobile power source (40-100 kWh = portable generator) - **Power levels**: - Standard V2L: 1.5-1.9 kW (15A @ 120V, single outlet) - High-power V2L: 3.6-3.8 kW (30A @ 120V or 15A @ 240V, dual outlets) - Heavy-duty V2L: 7.2-9.6 kW (40A @ 240V, for power tools, RV) - **Outlet locations**: - **Interior cabin**: Under rear seats or in cargo area (Hyundai Ioniq 5, Kia EV6) - **Exterior**: Hidden behind charge port door or bumper panel (Ford F-150 Lightning) - **Adapter**: Plug into charge inlet, convert to AC outlet (Nissan Leaf, Tesla with third-party adapter) - **Duration**: - 75 kWh battery @ 1.5 kW load → 50 hours continuous (2 days+) - 75 kWh battery @ 3.6 kW load → 20 hours continuous (overnight camping) ### Onboard Inverter Design - **Inverter topology**: - Pure sine wave: THD <3% (clean power for electronics, motors) - H-bridge: 4 IGBTs or MOSFETs, LC filter for smooth waveform - Isolated: Transformer isolation for safety (EV battery high-voltage DC isolated from AC output) - **Power stages**: - DC-DC converter: Step down HV battery (400V or 800V) to 48V or 120V DC bus - Inverter: 120V DC → 120V AC @ 60 Hz (or 230V AC @ 50 Hz in Europe/Asia) - Output filter: LC filter to reduce switching harmonics (<3% THD) - **Efficiency**: 85-92% (losses in DC-DC conversion and inverter switching) - **Cooling**: Air-cooled heatsink for <2 kW, liquid-cooled for >3 kW (shares vehicle thermal system) ### AC Outlet Integration - **Outlet types**: - **NEMA 5-15R**: Standard 120V 15A outlet (North America) - **NEMA 5-20R**: 120V 20A outlet (T-slot for 15A or 20A plug) - **NEMA 14-50R**: 240V 50A outlet (RV, high-power tools) — Ford F-150 Lightning - **NEMA L14-30R**: 240V 30A twist-lock (generator-style) — work trucks - **Outlet placement** (interior cabin example): - Under rear seat or in center console - Weatherproof cover (IP54 rating if exposed to spills) - LED indicator: Green = power available, Red = fault, Off = inverter disabled - **Outlet circuit**:
python def v2l_control(): battery_soc = get_battery_soc() outlet_current = measure_outlet_current() inverter_temp = measure_inverter_temp()# Safety checks if battery_soc < 20: disable_v2l() display_message("Battery too low for V2L (reserve for driving)") return if inverter_temp > 95: disable_v2l() display_message("Inverter overheat, V2L disabled") return # Thermal derating if inverter_temp > 80: max_current = 12 # Derate from 15A to 12A else: max_current = 15 # Current limit if outlet_current > max_current: trip_circuit_breaker() display_message("Overcurrent, breaker tripped") # Normal operation enable_inverter() update_display(battery_soc, outlet_current, remaining_runtime()) ``` - **Display information**: - Battery SOC: 65% - Output power: 1.2 kW (outlet load) - Estimated runtime: 38 hours (based on current draw) ### Use Cases and Applications - **Camping and outdoor recreation**: - Power camping stove, portable fridge (50-100W), lights, phone chargers - Example: 75 kWh battery → run 200W of loads for 375 hours (15 days!) - **Tailgating and events**: - Portable speakers, TV (100W), grill fan, string lights - Example: 3-4 hours of tailgating @ 500W → 1.5 kWh used (2% battery SOC) - **Job sites and construction**: - Power drills, saws, compressor (1-2 kW intermittent) - Example: Full day of work @ 1.5 kW average → 12 kWh used (16% SOC) - **Emergency power**: - During natural disaster or grid outage: Power fridge, medical devices, lights - Example: 3 days @ 1 kW average → 72 kWh (nearly full EV battery) - **RV and trailer power**: - Plug RV into EV V2L outlet (30A @ 240V for high-power V2L) - Run RV AC, fridge, water pump without generator or hookup - Example: Overnight RV use @ 2 kW → 16 kWh (21% SOC) - **Mobile food trucks**: - Power freezer, cooking equipment, POS system - Example: 8-hour event @ 3 kW → 24 kWh (32% SOC) ### Adapter-Based V2L (for EVs without built-in V2L) - **Charge port adapter**: - Plugs into vehicle charge inlet (J1772 or CCS) - Contains inverter (converts DC from charge port to AC outlet) - Power: Typically 1.5-1.9 kW (limited by charge port communication) - **Communication**: - Adapter signals to vehicle: "I am a charger, please provide DC power" - Vehicle responds: "OK, providing DC power to charge port" - Adapter inverts DC to AC and outputs to NEMA 5-15R outlet - **Limitations**: - Vehicle must support bidirectional communication (CHAdeMO easier than CCS) - Power limited by charge port rating (typically <2 kW) - Not officially supported by most OEMs (aftermarket solution) - **Example products**: - Nissan Leaf: CHAdeMO to AC adapter (Japan market, 1.5 kW) - Tesla: Third-party adapters exist but not OEM-supported ### Safety Considerations - **Carbon monoxide**: No risk (EV has no exhaust, unlike gas generator) - **Shock hazard**: GFCI required, proper grounding to vehicle chassis - **Fire hazard**: AFCI recommended, overcurrent protection mandatory - **Battery depletion**: Reserve SOC to avoid being stranded (20% minimum) - **Inverter overload**: Do not exceed rated power (will trip breaker or damage inverter) ### Power Quality - **Voltage regulation**: ±5% (114-126V for 120V nominal) - **Frequency stability**: ±0.1 Hz (59.9-60.1 Hz) - **Total Harmonic Distortion (THD)**: <3% (clean sine wave) - **Power factor**: >0.95 (efficient for inductive loads like motors) - **Compatible loads**: - Resistive: Heaters, incandescent lights, toasters (power factor = 1.0) - Inductive: Motors, compressors, power tools (power factor = 0.6-0.8) - Capacitive: LED drivers, switch-mode power supplies (power factor = 0.9+) - **Incompatible loads** (may damage inverter): - Extremely inductive: Large welders, arc furnaces (high inrush current) - Sensitive electronics: Medical equipment requiring <1% THD (inverter THD may be too high) ### Runtime Estimation - **Formula**:
Example: Battery: 75 kWh Usable SOC: 70% (from 20% to 90% SOC) Inverter efficiency: 90% Load: 1.5 kW Runtime = (75 × 0.70 × 0.90) / 1.5 = 31.5 hours
Expert in wireless power transfer (WPT) systems for electric vehicles using inductive coupling, covering ground assembly (GA) pad installation, vehicle assembly (VA) coil integration, alignment systems, foreign object detection (FOD), and living object protection (LOP).
P_out = k² × Q × P_inwhere: k = coupling coefficient (0.1 to 0.3) Q = quality factor of coils (typically 100-300) P_in = input power to GA Example: k=0.2, Q=200, P_in=10kW → P_out = 0.04 × 200 × 10 = 8 kW (80% coupling efficiency) ``` - **Efficiency optimization**: - Maximize k: Precise alignment (use visual or sensor feedback) - Maximize Q: Low-resistance Litz wire, minimize capacitor ESR - Tune resonance: Temperature-stable capacitors, adaptive tuning if needed ### Alignment Systems - **Visual guidance**: - LED strips on GA pad (green = good alignment, yellow = acceptable, red = poor) - In-vehicle display: Camera view with overlay showing target position - Ultrasonic sensors: Measure distance from VA to GA, guide driver - **Automated alignment** (for autonomous vehicles or robotic systems): - Stepper motors in GA to move pad ±200 mm in X/Y directions - Vehicle assembly fixed; ground assembly adjusts position - Alignment time: 5-10 seconds (detect VA position via induced current sensing) - **Positioning tolerance**: - Optimal alignment: ±25 mm (maintains >90% efficiency) - Acceptable: ±50 mm (80-90% efficiency, charges slower) - Unacceptable: >75 mm (power transfer drops to <70%, may abort) - **Alignment algorithm**:
if abs(offset_x) > 25 or abs(offset_y) > 25: # Move GA or provide driver feedback move_ga(offset_x, offset_y)
Other measured skills in the registry, with their headline benchmark lift.