---

name: automotive-charging description: > 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 wireless charging systems, CISPR 25 Limits for conducted/radiated EMI in vehicles, CharIN MCS specification and more. tags: [800v-platform, adapter, automotive, automotive-charging-infrastructure, backup-power, billing, cable-cooling, camping, can-bus, ccs, chademo, charging-infrastructure, china, contactors, control-systems, dc-fast-charging, demand-response, depot-charging, derating, emc, emsp, evse, exi, firmware, gb-t, gfci, grid-impact, hardware-design, harmonics, heavy-duty, high-voltage, iec-61851, inductive-coupling, insulation-monitoring, inverter, islanding, iso-15118, liquid-cooling, llc, load-balancing, load-management, mcs, megawatt-charging, metering, nacs, ocpi, onboard-charger, optimization, payment-processing, pfc, pi-controller, pki, plc, plug-and-charge, portable-power, power-electronics, power-quality, renewable-energy, roaming, sae-j2954, sae-j3400, safety, safety-standards, sic-mosfet, smart-charging, tesla, thermal-management, tls, transformer-loading, ul-2594, ultra-fast-charging, v2g, v2h, v2l, vehicle-to-home, vehicle-to-load, voltage-drop, wireless-charging, wpt]

Automotive Charging Infrastructure

20 skill files covering charging-infrastructure domain for automotive software engineering.

Applicable Standards

• 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 wireless charging systems
• CISPR 25 Limits for conducted/radiated EMI in vehicles
• CharIN MCS specification
• GB/T 18487.1 Safety requirements for conductive charging
• GB/T 20234.1 General requirements for EV conductive charging
• GB/T 20234.2 AC charging connector (similar to IEC 62196-2)
• GB/T 20234.3 DC charging connector
• GB/T 27930 Communication protocol between EV and off-board charger
• GDPR for user data privacy (EU)
• IEC 60352-2 Solderless connections (for cooled pins)
• IEC 60364-7-722 Low-voltage installations for EV charging
• IEC 60664-1 Insulation coordination for 800V systems
• IEC 60884-1 Plugs and socket-outlets for household use
• IEC 61000-3-2 Harmonic current emission limits
• IEC 61000-6-2 Immunity for industrial environments
• IEC 61850 Power utility automation
• IEC 61851-1 AC charging requirements
• IEC 61851-1 EV conductive charging (AC)
• IEC 61851-1 EV conductive charging (safety requirements)
• IEC 61851-1 EV conductive charging systems (general requirements)
• IEC 61851-1 Load management for EV charging
• IEC 61851-21/22/23 Electric vehicle on-board charger and charging station requirements
• IEC 61851-21/22/23/24 AC and DC charging safety specifications
• IEC 61851-23 DC EV charging
• IEC 61851-23 DC EV charging (high-power extension)
• IEC 61851-23 DC EV charging station
• IEC 61851-23 DC EV charging station requirements
• IEC 61851-23 DC charging requirements
• IEC 61851-23 DC charging up to 1000V
• IEC 61851-24 Digital communication
• IEC 61851-24 Digital communication between EV and EVSE
• IEC 61980-1 Wireless Power Transfer (WPT) systems for EVs
• IEC 62052 Electricity metering equipment
• IEC 62196-3 Type 2 connector (CCS Type 2 base)
• IEC 62893 Charging cables for EVs (liquid cooling)
• IEC 62893 Charging cables for bidirectional power
• IEC 62893 Charging cables for electric vehicles
• IEEE 1547 Distributed energy resources interconnection
• IEEE 1547 Interconnection of distributed energy resources
• IEEE 2030 Smart grid interoperability
• IEEE 2030.1.1 Smart grid integration for EV fleets
• IEEE 2030.1.1 Smart grid integration for EVs
• IEEE 2030.1.1 V2G communication protocols
• IEEE 519 Harmonic limits for electrical power systems
• ISO 15118 Communication for 800V charging
• ISO 15118 Plug & Charge (future NACS support)
• ISO 15118 Plug & Charge for certificate-based billing
• ISO 15118 Smart charging profiles and schedules
• ISO 15118-1 General information and requirements
• ISO 15118-2 Communication protocol (V2G)
• ISO 15118-2 Network and application protocol (EV-EVSE)
• ISO 15118-2 V2G communication protocol
• ISO 15118-20 AC/DC charging with bidirectional power transfer
• ISO 15118-20 Bidirectional power transfer
• ISO 15118-20 Vehicle-to-Grid (V2G) for MCS
• ISO 15118-20 Vehicle-to-Grid for fleet applications
• ISO 15118-3 Physical and data link layer (PLC)
• ISO 17409 EV conductive charging safety requirements
• ISO 19363 Magnetic field wireless power transfer (safety)
• ISO 7637-2 Electrical disturbances by conduction
• JIS D 4001 Japanese automotive standards
• NFPA 70 (NEC) Article 551 Recreational vehicles
• NFPA 70 (NEC) Article 702 Optional standby systems
• OCPI 2.2.1 (Open Charge Point Interface) for roaming
• OCPP 2.0.1 Smart charging and load management
• OCPP 2.0.1 for EVSE to central system communication
• OpenADR 2.0b Automated demand response
• OpenADR 2.0b Demand response for fleet depots
• PCI DSS for payment card data security
• RFC 5246 TLS 1.2 (minimum version for Plug & Charge)
• RFC 5280 X.509 certificates for PKI
• SAE J1772 AC Level 1/Level 2 charging
• SAE J1772 AC charging connector and control pilot
• SAE J1772 AC connector (CCS Type 1 base)
• SAE J1772 Connector temperature limits
• SAE J1772 Control pilot signaling
• SAE J1772 Safety requirements for AC charging
• SAE J2954 Wireless Power Transfer for Light-Duty EVs
• SAE J2954 Wireless charging for autonomous fleets
• SAE J3068 High-power conductive charging (350 kW+)
• SAE J3072 V2L communication and control
• SAE J3271 Megawatt Charging System (MCS)
• SAE J3400 NACS connector specification (2024)
• UL 1008 Automatic transfer switches
• UL 1741 SA Inverters for distributed generation
• UL 1741 SA Inverters for grid support
• UL 2089 Vehicle battery adapters
• UL 2202 / UL 2594 EV charging system safety
• UL 2202 EV charging system safety
• UL 2202 Safety for high-voltage EV charging systems
• UL 2251 Plugs, receptacles, and couplers for EV charging
• UL 2594 / UL 2202 Electric vehicle charging system equipment
• UL 2750 Wireless charging equipment safety

Use Cases

• 800V platform EV design (Porsche Taycan, Hyundai Ioniq 5, Kia EV6)
• SiC (Silicon Carbide) inverter and OBC design for 800V
• 250-350 kW ultra-fast charging implementation
• 400V to 800V boost converter for backward compatibility
• High-efficiency powertrain (motor inverter, DC-DC, OBC)
• Onboard charger design for EVs (3.3 kW to 22 kW)
• Power factor correction (PFC) topology selection and design
• LLC resonant converter for high-efficiency DC-DC conversion
• EMC compliance (conducted and radiated emissions)
• Bidirectional OBC for V2G capability
• eMSP platform development (mobile app, billing backend)
• CPO (Charge Point Operator) network management
• OCPI roaming implementation for cross-network charging
• Tariff and pricing strategy design
• Payment gateway integration (Stripe, PayPal, credit cards)
• DC fast charging station development
• CCS controller firmware implementation
• PLC-HPGP (HomePlug Green PHY) communication stack
• Power delivery control and safety monitoring
• ISO 15118 high-level communication integration

Topics Covered

Bidirectional Charging

• v2g-vehicle-to-grid
• v2h-vehicle-to-home
• v2l-vehicle-to-load

Business Operations

• billing-roaming-emsp

Communication Protocol

• iso-15118-plug-and-charge

Dc Fast Charging

• ccs-combo-charging
• chademo-protocol
• gb-t-charging
• nacs-tesla-standard

Energy Management

• smart-charging-algorithms

Grid Integration

• charging-grid-impact

Hardware Design

• charging-station-architecture

Heavy Duty Charging

• megawatt-charging

Power Electronics

• ac-onboard-charger

Safety Compliance

• charging-safety-standards

Thermal Systems

• charging-thermal-management

Wireless Power Transfer

• wireless-charging-wpt

Constraints

• $30K-150K depending on power level)
• 5-10 kg, 5-10 liters)
• ADC noise and offset (require filtering and calibration)
• Adapter complexity for ISO 15118 to Tesla CAN translation
• Alignment sensitivity (user frustration if hard to position)
• Automotive temperature range (-40°C to +105°C ambient)
• Battery degradation from aggressive V2G cycling
• Battery degradation from cycling (need compensation or battery warranty)
• Battery degradation from cycling (though minimal for occasional V2L use)
• CAN-based protocol slower than PLC-based ISO 15118 (100 ms vs 10 ms latency)
• Cable resistance voltage drop at high currents (require compensation)
• Certificate management complexity (PKI infrastructure, OCSP, revocation)
• Certification requires CQC approval (testing in China)
• Communication latency (cloud-based optimization vs local control)
• Communication timeout handling (graceful degradation)

Required Tools

• AC outlet (NEMA 5-15R or NEMA 14-50R)
• API gateway (Kong, AWS API Gateway)
• Arc flash PPE and testing equipment
• Automatic transfer switch (Generac, Kohler, Eaton)
• Bidirectional charger with V2H capability (Wallbox Quasar, Fermata, Dcbel)
• CAN analyzer (Vector CANalyzer, PCAN-USB)
• CAN analyzer (Vector, PEAK, or Chinese brands like ZLG)
• CAN analyzer and PLC sniffer for protocol debugging
• CAN analyzer for ISO 15118-20 protocol
• CAN analyzer for protocol reverse engineering
• CHAdeMO certification test equipment
• CHAdeMO connector and cable
• CQC certification test equipment
• CharIN test suite for conformance testing
• CharIN test tools for certification

Instructions

800v-charging-architecture

Core Competencies

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.

800V Platform Overview

• Advantages over 400V:

  • Faster charging: 350 kW at 800V = 437A (vs 875A at 400V, cable/connector limited to ~500A)
  • Lighter weight: 50% reduction in conductor size (half the current for same power)
  • Higher efficiency: Lower I2R losses in cables, inverter, motor windings
  • Smaller components: Inverter, OBC, DC-DC converter can be more compact

• Production vehicles (2024+):

  • Porsche Taycan: 800V, 270 kW charging, 200 kWh/100km efficiency
  • Hyundai Ioniq 5 / Kia EV6: 800V, 350 kW charging, 18-minute 10-80% SOC
  • GMC Hummer EV: 800V, 350 kW charging, 200+ kWh battery
  • Lucid Air: 900V, 300 kW charging, luxury sedan

Battery Pack Design

• Cell configuration:

  • 400V pack: 96 cells in series (96S) @ 4.2V = 403V max
  • 800V pack: 192 cells in series (192S) @ 4.2V = 806V max
  • Alternative: Use high-voltage cells (e.g., 8.4V per cell, 96S = 806V)

• BMS considerations:

  • More cells in series -> longer voltage measurement chain (daisy-chain ADCs)
  • Higher insulation requirements (>800 kOhm isolation resistance)
  • Cell balancing: Passive or active balancing for 192 cells

• Thermal management:

  • Same heat generation per kWh (energy throughput independent of voltage)
  • But higher current density possible (better utilization of cooling system)

SiC Power Electronics

• Why SiC for 800V:

  • Higher blocking voltage: 1200V SiC MOSFETs (vs 600V Si IGBTs for 400V)
  • Lower switching losses: SiC switches faster (10x vs IGBT) -> higher efficiency
  • Higher temperature: SiC operates at 175C junction (vs 150C for Si)
  • Smaller heatsinks: 50% reduction in cooling requirements

• Motor inverter (800V):

  • Topology: Three-phase 2-level inverter (6x SiC MOSFETs)
  • Switching frequency: 10-20 kHz (2x vs Si IGBT due to lower switching loss)
  • Efficiency: 98-99% (vs 95-97% for 400V Si IGBT inverter)
  • Power density: 15-20 kW/liter (vs 8-12 kW/liter for 400V)

• SiC MOSFET selection:

  • Voltage rating: 1200V (safety margin for 800V DC bus)
  • R_DS(on): 10-20 mOhm (e.g., Wolfspeed C3M0016120K, 16 mOhm @ 25C)
  • Current rating: 200-300A continuous (for 150-200 kW inverter)

• Gate driver design:

  • Isolated gate driver with Miller clamp (prevent false turn-on from dV/dt)
  • Gate resistance: 2-5 Ohm (trade-off faster switching vs EMI)
  • Turn-on voltage: +15V, turn-off: -4V (fully enhance/deplete)

Ultra-Fast Charging (350 kW)

• Charging speed:

  • 100 kWh battery, 10-80% SOC = 70 kWh delivered
  • At 350 kW: 70 kWh / 350 kW = 0.2 hours = 12 minutes
  • Real-world: 15-18 minutes (de-rating for battery temperature, SOC taper)

• Charging curve (Hyundai Ioniq 5 example):

  • 10-50% SOC: 350 kW (800V x 437A)
  • 50-70% SOC: 250 kW (800V x 312A, battery heating up)
  • 70-80% SOC: 150 kW (voltage taper, constant voltage phase)
  • 80-100% SOC: 50 kW -> 10 kW (slow taper to protect battery)

• Charger requirements:

  • Output voltage: 400-920V (to match 800V battery at various SOC)
  • Output current: 500A max (connector rating, liquid-cooled cable)
  • Efficiency: 95-97% (SiC-based DC-DC converter)

Backward Compatibility (400V Charging)

• Challenge: 800V vehicle at 400V charger (50-150 kW DC fast chargers are 400V)

• Solution 1 - Onboard boost converter:

  • DC-DC boost: 400V -> 800V
  • Power: 50-100 kW (limits charging speed at 400V stations)
  • Components: SiC MOSFETs, inductor, controller
  • Example: Hyundai/Kia E-GMP platform has 10 kW boost converter

• Solution 2 - Split battery pack:

  • Battery divided into two 400V sections (96S + 96S)
  • Normally series (800V for driving and 800V charging)
  • Switch to parallel (400V each section) for 400V charging
  • Complex switching (high-voltage contactors, BMS coordination)

• Boost converter design:

  // 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
      }
  }
  

High-Voltage Safety

• Insulation monitoring:

  • Threshold: >500 Ohm/V (400 kOhm for 800V system, vs 200 kOhm for 400V)
  • Continuous monitoring during operation
  • Trip contactors if R_iso drops below threshold

• Creepage and clearance:

  • Per IEC 60664-1 for 800V:
    • Clearance: 4-6 mm (air gap between HV+ and HV-, or HV and ground)
    • Creepage: 6-10 mm (surface distance on PCB)
  • Use conformal coating or potting for harsh environments

• Arc flash protection:

  • 800V arcs more dangerous than 400V (longer arc length, harder to extinguish)
  • Use arc-resistant contactors, fast fault detection (<5 ms)

• High-voltage interlock (HVIL):

  • Connectors have HVIL pin (low-voltage signal loop)
  • If connector disconnected, HVIL opens -> controller opens contactors
  • Prevents accidental contact with live HV terminals

Efficiency Gains

• Powertrain losses comparison (400V vs 800V, 150 kW motor):

  | 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 |

• Range impact: 4.3% vs 2.7% loss -> 1.6% more efficient -> ~5 km extra range per 100 km

Weight and Cost

• Weight savings:

  • HV cables: 50% copper (half the current, half the cross-section) -> save 10-15 kg
  • Inverter: Smaller heatsink, compact SiC modules -> save 3-5 kg
  • Total: 15-25 kg weight reduction (1-2% of vehicle weight)

• Cost:

  • SiC MOSFETs: 2-3x cost of Si IGBTs (~$50-100 more per inverter)
  • Battery: Same cost (same kWh capacity, same cells)
  • Charger infrastructure: 800V chargers slightly more expensive (higher voltage isolation)
  • Net: $500-1000 premium for 800V platform (justified by faster charging)

Charging Infrastructure

• CCS connector: Same CCS Type 1 or Type 2 connector (supports up to 1000V)
• Charger upgrade: 400V chargers need 800V-capable DC-DC converter module
• Example chargers:
  • ABB Terra 360: 350 kW, 200-920V output (800V compatible)
  • Electrify America: 350 kW chargers (800V capable)
  • Tesla Supercharger V4: 250-350 kW, 400-1000V (supports 800V)

Motor Design for 800V

• Winding: Same number of turns as 400V (motor current same for given torque)

• Insulation: Higher voltage rating (magnet wire with thicker enamel, 1500V test)

• Efficiency: Slightly higher (inverter switching less lossy, can use higher PWM frequency)

• Example motor specs:

  • 400V motor: 200 kW, 350 Nm, 500A peak
  • 800V motor: 200 kW, 350 Nm, 250A peak (same torque, half current)

Thermal Management

• Cooling strategy:

  • SiC inverter generates less heat (higher efficiency) -> smaller radiator
  • Battery cooling: Same thermal load (energy throughput same)
  • Motor cooling: Same (losses roughly same)

• Integrated cooling:

  • Single glycol-water loop for inverter, motor, OBC, DC-DC, battery
  • 800V inverter compact -> easier integration

Approach

1. System architecture: Decide on 800V vs 400V split, boost converter for compatibility
2. Battery pack: Design 192S configuration, BMS with high-voltage protection
3. SiC inverter: Select 1200V SiC MOSFETs, design gate driver, layout for low inductance
4. OBC: 11-22 kW onboard charger with 800V output (LLC resonant converter)
5. DC-DC converter: 800V to 12V auxiliary power (for lights, HVAC, computers)
6. Safety: HVIL, insulation monitoring, arc detection, creepage/clearance compliance
7. Testing: High-voltage safety testing, efficiency measurement, EMC compliance

Deliverables

• 800V system architecture diagram (battery, inverter, OBC, DC-DC, motor)
• SiC inverter design (schematic, PCB, gate driver, thermal)
• Boost converter for 400V compatibility (optional)
• Safety analysis (insulation, arc flash, fault modes)
• Efficiency report (powertrain losses, range impact)
• Cost analysis (BOM, comparison to 400V platform)

Best Practices

• Isolation testing: Test at 2x rated voltage (1600V for 800V system) for 1 minute
• Partial discharge: Test for corona at high voltage (use PD detector)
• Thermal cycling: Verify components survive -40C to +125C (automotive range)
• EMC: SiC fast switching generates high dV/dt (requires careful PCB layout, shielding)
• Service safety: Train technicians on 800V hazards (insulated tools, PPE)

Integration

• Vehicle CAN: Communicate HV system status, voltage, current, SOC
• Charging infrastructure: CCS protocol (ISO 15118) for 800V negotiation
• Battery thermal: Precondition battery to 20-25C for 350 kW charging (BMS command)
• Motor control: Adjust inverter control strategy for 800V DC bus

ac-onboard-charger

Core Competencies

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.

OBC Architecture

• Power levels:

• 3.3 kW: Single-phase 120V/230V @ 16A (entry-level EVs)

• 6.6 kW: Single-phase 230V @ 32A (most common, overnight charging)

• 11 kW: Three-phase 400V @ 16A (faster charging, European market)

• 22 kW: Three-phase 400V @ 32A (high-end EVs, fastest AC charging)

• Block diagram: 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: AC Input → Bridge Rectifier → Inductor (L) → MOSFET (Q) → DC Bus (400V) ↓ Diode (D)

• Control: Average current mode control (ACMC)

• Inductor current follows rectified AC voltage waveform (sinusoidal shape)

• PI controller adjusts PWM duty cycle to maintain DC bus voltage (e.g., 400V)

• Switching frequency: 65-100 kHz (trade-off: efficiency vs inductor size)

• PFC control code:

// 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**:
``` DC Bus (400V) → Full-Bridge (4× MOSFETs) → Resonant Tank (Lr, Cr) → Transformer (isolation) → Rectifier → Output Filter → Battery (300V) ```

- **Key features**:
- **Soft-switching**: Zero-voltage switching (ZVS) reduces MOSFET switching losses
- **Isolation**: High-frequency transformer (100 kHz) provides galvanic isolation
- **Efficiency**: 95-98% (higher than hard-switched topologies)

- **Resonant tank design**:
- Resonant frequency: f_r = 1 / (2π √(L_r × C_r))
- Magnetizing inductance: L_m (determines ZVS range)
- Quality factor: Q = √(L_r / C_r) / R_load

- **Control**: Variable frequency control
- Above resonance (f > f_r): Output voltage decreases with frequency (regulate by adjusting f)
- Below resonance (f < f_r): Avoid (hard switching, high losses)
- Typical range: 80-150 kHz (f_r = 100 kHz)

- **LLC control code**:
```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
``` AC Input → CM Choke (L_CM) → Differential Mode Capacitor (C_X) → Common Mode Capacitor (C_Y) → PFC Stage ```

- **Common mode (CM) noise**: High-frequency noise on both AC lines relative to ground
- CM choke: Toroidal core, windings in same direction (magnetic flux adds)
- C_Y capacitors: Line to ground, typically 2.2-4.7 nF (limited by leakage current <3.5 mA)

- **Differential mode (DM) noise**: Noise between AC lines
- C_X capacitors: Line to line, 220-470 nF
- DM inductor: Optional, improves attenuation at high frequency

- **Design guidelines**:
- CM choke inductance: 1-5 mH (higher = better attenuation, but larger size)
- Corner frequency: f_c = 1 / (2π √(L × C)) ≈ 10-50 kHz (below PFC switching frequency)

### Power Factor and THD

- **Power factor (PF)**: Ratio of real power to apparent power
- PF = cos(φ) × distortion factor
- Target: PF >0.95 (EU EN 61000-3-2, US Energy Star)

- **Total Harmonic Distortion (THD)**:
- THD = √(Σ I_n²) / I_1 (ratio of harmonic RMS to fundamental RMS)
- Target: THD <5% per IEC 61000-3-2 Class A

- **Measurement**:
```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**:
```c void V2G_ControlLoop(void) { float grid_voltage = ADC_ReadVoltage(CH_GRID); float grid_freq = MeasureFrequency(); float target_power = GetV2GPowerCommand();  // From aggregator via OCPP
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(); } } ```

### Charging Curve Implementation

- **Constant Current (CC) to Constant Voltage (CV)**:
- CC phase: Charge at max current (e.g., 16A) until battery reaches max voltage (e.g., 420V)
- CV phase: Hold voltage at 420V, current tapers from 16A to <1A as battery fills

- **Control**:
```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., 16A
if (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):
```python import requests
# CPO → eMSP: Send session update def send_session_update(emsp_url, session_data, auth_token): headers = { "Authorization": f"Token {auth_token}", "Content-Type": "application/json" }
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
# Example session = { "session_id": "123456789", "energy_kwh": 25.5, "rfid_token": "AABBCCDD", "location_id": "LOC001", "evse_uid": "EVSE001", "connector_id": "1", "total_cost": 12.75 }
status = send_session_update("https://emsp-api.example.com", session, "secret_token") ```

### Tariff Management

- **Tariff components**:
- **Energy-based**: $/kWh (e.g., $0.40/kWh)
- **Time-based**: $/minute (e.g., $0.25/min, encourages fast charging)
- **Session-based**: Flat fee per session (e.g., $2 connection fee)
- **Parking-based**: Idle fee after charging complete (e.g., $0.50/min idle)
- **Time-of-use**: Variable pricing by time of day (peak/off-peak)

- **Tariff example** (OCPI format):
```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**:
```python def calculate_cost(tariff, energy_kwh, duration_minutes, start_time): total_cost = 0
# Find applicable tariff element based on time restrictions for element in tariff["elements"]: if time_matches_restriction(start_time, element.get("restrictions")): for component in element["price_components"]: if component["type"] == "ENERGY": total_cost += energy_kwh * component["price"] elif component["type"] == "TIME": total_cost += (duration_minutes / component["step_size"]) * component["price"] break  # Use first matching element
return round(total_cost, 2)
# Example cost = calculate_cost( tariff=tariff_data, energy_kwh=25.5, duration_minutes=45, start_time="2026-03-19T17:30:00Z" ) # Result: Peak pricing (17:30): 25.5 kWh × $0.40 + 45 min × $0.05 = $10.20 + $2.25 = $12.45 ```

### Payment Processing

- **Payment methods**:
- **Credit/debit card**: Stripe, Braintree, Adyen
- **Mobile wallet**: Apple Pay, Google Pay, PayPal
- **Direct carrier billing**: Charge to phone bill (for eMSP apps)
- **Fleet accounts**: Invoicing for corporate fleets
- **Ad-hoc payment**: Credit card at charger (touchscreen or NFC)

- **PCI DSS compliance**:
- Never store credit card numbers in plain text
- Use tokenization (Stripe token, PayPal token)
- Encrypt cardholder data in transit (TLS 1.2+)
- Annual security audit (PCI DSS Level 1 for >6M transactions/year)

- **Stripe integration example**:
```python import stripe
stripe.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):
```json { "id": "CDR123456789", "start_date_time": "2026-03-19T08:30:00Z", "end_date_time": "2026-03-19T09:15:00Z", "auth_id": "AABBCCDD", "location_id": "LOC001", "evse_uid": "EVSE001", "connector_id": "1", "currency": "USD", "total_cost": 12.45, "total_energy": 25.5, "total_time": 0.75,  // hours "charging_periods": [ { "start_date_time": "2026-03-19T08:30:00Z", "dimensions": [ {"type": "ENERGY", "volume": 25.5}, {"type": "TIME", "volume": 45}  // minutes ] } ], "remark": "Session completed successfully", "last_updated": "2026-03-19T09:16:00Z" } ```

- **CDR validation**:
```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**:
```python from flask import Flask, request, jsonify
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"]
# Check user balance / payment method valid user = get_user(user_id) if not user.has_valid_payment_method(): return jsonify({"error": "No valid payment method"}), 400
# Send start command to EVSE (via OCPP) session_id = ocpp_remote_start(evse_id, user.rfid_token)
# Log session create_session_record(session_id, user_id, 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 }) ```

### Business Models

- **CPO revenue**:
- Energy sales: $0.40/kWh (buy from grid at $0.10/kWh, margin $0.30/kWh)
- Parking fees: $2/hour for premium locations (airports, hotels)
- Advertising: Display ads on charger screen
- Data sales: Anonymized usage data to urban planners, automakers

- **eMSP revenue**:
- Markup on charging: Add $0.05-0.10/kWh above CPO rate
- Subscription: $5-10/month for unlimited charging or reduced rates
- Fleet contracts: Corporate accounts for delivery fleets

- **Break-even analysis** (50 kW DC fast charger):
- Installation cost: $50,000 (charger + electrical + site work)
- Electricity cost: $0.10/kWh
- Selling price: $0.40/kWh
- Margin: $0.30/kWh
- Utilization: 20% (4.8 hours/day @ 50 kW = 240 kWh/day)
- Daily revenue: 240 kWh × $0.30 = $72/day
- Annual revenue: $72 × 365 = $26,280
- Payback period: $50,000 / $26,280 = 1.9 years

## Approach

1. **Business model**: Define CPO, eMSP, or both (vertically integrated)
2. **OCPI integration**: Implement OCPI 2.2.1 for roaming (if eMSP)
3. **Tariff design**: Define pricing strategy (energy, time, session, TOU)
4. **Payment gateway**: Integrate Stripe, PayPal, or other PSP (Payment Service Provider)
5. **Mobile app**: Develop user-facing app (React Native, Flutter)
6. **Backend**: Build billing engine, session management, CDR generation
7. **Roaming hub**: Connect to Hubject, Gireve, or e-clearing.net

## Deliverables

- OCPI integration (API endpoints for locations, sessions, CDRs, tariffs)
- Billing engine (tariff calculation, CDR generation, payment processing)
- Mobile app (iOS/Android) with map, session control, payment history
- Roaming hub integration (Hubject/Gireve connection)
- Dashboard (CPO/eMSP admin panel for revenue, sessions, users)
- API documentation (REST API for third-party integrations)

## Best Practices

- **Data accuracy**: Ensure energy metering accurate (MID-certified meters)
- **CDR reconciliation**: Match CPO and eMSP CDRs (detect discrepancies)
- **User support**: 24/7 customer service (chat, phone, email)
- **Fraud detection**: Monitor for abnormal usage patterns (stolen RFID cards)
- **GDPR compliance**: Anonymize user data, provide data export/deletion

## Integration

- **OCPP backend**: EVSE management, remote start/stop, session data
- **Payment gateway**: Stripe, Braintree, PayPal for user billing
- **Roaming hub**: Hubject, Gireve for cross-network access
- **Navigation**: Google Maps API for station location, route planning
- **Analytics**: Google Analytics, Mixpanel for user behavior tracking

### ccs-combo-charging

## Core Competencies

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.

### CCS Connector Types

- **CCS Type 1** (CCS1 / Combo 1):
- Base: SAE J1772 AC connector (Type 1)
- DC pins: Two additional pins below AC connector
- Markets: North America, South Korea, Taiwan
- AC charging: J1772 pins (max 19.2 kW single-phase)
- DC charging: DC+/DC- pins (up to 350 kW)
- Control pilot: CP signal (1 kHz PWM, ±12V) for basic control
- Proximity pilot: PP signal for cable current rating detection

- **CCS Type 2** (CCS2 / Combo 2):
- Base: IEC 62196-2 Type 2 (Mennekes) AC connector
- DC pins: Two additional pins below AC connector
- Markets: Europe, Australia, China (GB/T variant exists)
- AC charging: Type 2 pins (up to 43 kW three-phase)
- DC charging: DC+/DC- pins (up to 350 kW)
- Control pilot: CP signal for basic control and state machine
- Proximity pilot: PP signal for cable presence and current rating

### Physical Layer (ISO 15118-3)

- **PLC-HPGP (HomePlug Green PHY)**:
- Frequency band: 1.8 MHz to 30 MHz (CENELEC-A band in EU: 3-95 kHz avoided)
- Modulation: OFDM with BPSK, QPSK, 8-QAM, 16-QAM
- Data rate: Up to 10 Mbps PHY, ~4 Mbps application layer
- Coupling: Capacitive or inductive coupling to CP line
- Impedance: 50Ω characteristic impedance for PLC modem

- **Signal injection**:
- Control Pilot (CP) line carries both PWM (basic signaling) and PLC (high-level comm)
- PWM duty cycle: 5% (digital communication request), 10% to 96% (current available)
- Voltage levels: +12V (state A), +9V (state B), +6V (state C), +3V (state D), 0V/-12V (fault)
- PLC coupler: Band-pass filter + coupling capacitor to inject OFDM signal

### CCS Communication Stack

- **Low-level signaling (basic charging)**:
- PWM duty cycle on CP pin indicates available current: I_max = duty_cycle × 0.6 A (for duty > 10%)
- EV changes CP impedance to signal connection state (1kΩ, 2.7kΩ, 270Ω)
- Proximity pilot (PP) resistor coding: 13kΩ = no cable, 220Ω/680Ω/1.5kΩ/3.3kΩ = cable rating

- **High-level communication (ISO 15118)**:
- SLAC (Signal Level Attenuation Characterization): EV and EVSE negotiate PLC link
- IPv6 over PLC: EXI-encoded XML messages for charging parameters
- TLS 1.2/1.3: Encrypted session for Plug & Charge certificate exchange
- Message flow: SessionSetup → ServiceDiscovery → PaymentServiceSelection → Authorization → ChargeParameterDiscovery → CableCheck → PreCharge → PowerDelivery → CurrentDemand → WeldingDetection → SessionStop

### Power Delivery Control

- **DC output stages**:
- Rectifier: Three-phase AC → DC (PFC for power factor correction)
- DC-DC converter: Buck/boost topology to match battery voltage (200V to 920V for 800V systems)
- Isolation: Galvanic isolation transformer (typically 20 kHz switching frequency)
- Output filter: LC filter to reduce ripple (<2% at rated current)

- **Current/voltage regulation**:
- EV sends target voltage and current via ISO 15118 CurrentDemand message (1 Hz to 10 Hz)
- EVSE regulates output: V_out follows EV request, I_out limited by cable/station rating
- Feedback loop: PI controller with 100 µs to 1 ms response time
- Droop compensation: Compensate for cable resistance (~50 mΩ for 5m cable)

- **Power stages** (typical CCS charger):
- 50 kW: 500V × 100A or 400V × 125A (common for urban fast charging)
- 150 kW: 500V × 300A (highway corridor charging)
- 350 kW: 920V × 380A or 500V × 700A (high-power charging, requires liquid cooling)

### Precharge and Contactor Control

- **Precharge sequence**:
1. EVSE closes positive precharge relay (series resistor ~100Ω to limit inrush)
2. EV monitors inlet voltage via isolation monitoring
3. When V_inlet ≈ V_battery (within 20V), EV signals ready
4. EVSE closes main positive contactor, opens precharge relay
5. EVSE closes negative contactor
6. Current flow can begin (ramp from 0 A to target in ~2 seconds)

- **Contactor specifications**:
- DC contactors rated for 1000 VDC, breaking capacity >10 kA
- Precharge resistor: 100Ω 50W (limits inrush to ~10A for 1000V system)
- Isolation monitoring: Measure DC+ to PE and DC- to PE (must be >100 kΩ/V per IEC 61851-23)

### Safety and Fault Detection

- **Insulation monitoring**:
- Continuously measure isolation resistance between DC+ / DC- and protective earth
- Threshold: R_iso > 100 Ω/V (e.g., >50 kΩ for 500V system)
- Method: Inject low-frequency AC test signal or DC pulse, measure leakage current

- **Ground fault detection**:
- Residual current monitoring: I_DC+ + I_DC- < 20 mA (IEC 61851-23)
- Trip time: <100 ms on fault detection
- Hall effect current sensors on both DC rails

- **Overcurrent protection**:
- Software limit: I_out < min(cable_rating, station_rating, EV_request)
- Hardware limit: Fast-acting fuse or electronic circuit breaker
- Short-circuit detection: Trip in <10 ms if I > 2 × I_rated

- **Overvoltage protection**:
- V_out must not exceed EV target + 5% (per ISO 15118-2)
- Hardware clamp: Varistor or crowbar circuit at 1050V for 1000V systems

- **Emergency stop**:
- E-stop button opens contactors and disables DC output within 500 ms
- CP signal transitions to 0V/-12V to signal fault to EV

### CCS Controller Firmware

- **State machine** (control pilot PWM):
```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):
```python def handle_current_demand(msg): # EV sends target voltage and current target_voltage = msg.EV_TargetVoltage  # V target_current = msg.EV_TargetCurrent  # A
# Apply limits actual_voltage = min(target_voltage, MAX_VOLTAGE) actual_current = min(target_current, CABLE_RATING, STATION_RATING)
# Send to power electronics controller set_dc_output(actual_voltage, actual_current)
# Respond with present values response = CurrentDemandRes( EVSE_PresentVoltage=measure_voltage(), EVSE_PresentCurrent=measure_current(), EVSE_CurrentLimitAchieved=(actual_current < target_current), EVSE_VoltageLimitAchieved=(actual_voltage < target_voltage) ) return response ```

## Approach

1. **Hardware design**: Select CCS inlet/outlet (Type 1 or Type 2), contactors, current sensors, PLC modem
2. **Power electronics**: Design DC-DC converter topology, select IGBTs/SiC MOSFETs, sizing for target power
3. **PLC integration**: Integrate HPGP modem (Qualcomm QCA7000, Broadcom BCM60333), couple to CP line
4. **ISO 15118 stack**: Integrate V2GTP library (RISE-V2G, CharIN test tools), implement state machine
5. **Safety compliance**: Implement insulation monitoring, ground fault detection, emergency stop
6. **Testing**: SLAC association test, current/voltage regulation accuracy, fault injection, protocol conformance
7. **Certification**: IEC 61851-23 compliance, CharIN certification for interoperability

## Deliverables

- CCS controller firmware (C/C++) for charge point
- ISO 15118 message handler (EXI encoding/decoding)
- Power electronics control loop (PI regulator)
- Safety monitor (insulation, ground fault, overcurrent)
- PLC modem driver and SLAC implementation
- Test reports (CharIN certification, safety compliance)

## Best Practices

- **Robust SLAC**: Retry SLAC matching if initial attempts fail (RF noise, cable quality)
- **Cable compensation**: Measure cable resistance during precharge, compensate in voltage regulation
- **Thermal management**: Monitor IGBT junction temperature, derate power if >90°C
- **Logging**: Record all ISO 15118 messages for debugging interoperability issues
- **Graceful degradation**: Fall back to basic PWM charging if PLC communication fails

## Integration

- **OCPP backend**: Report charging session, energy metering, fault events
- **Payment terminal**: Integrate credit card reader or RFID for user authentication
- **Cooling system**: Liquid-cooled cables for >200 A (monitor inlet/outlet temperature)
- **Grid interface**: Power factor correction, harmonic filtering to meet IEEE 519

### chademo-protocol

## Core Competencies

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.

### CHAdeMO Protocol Versions

- **CHAdeMO 1.0 / 1.2** (2010-2016):
- CAN 2.0B communication at 250 kbps
- Maximum power: 62.5 kW (500V × 125A)
- Unidirectional charging only (grid to vehicle)
- 10 connector pins (DC+, DC-, CAN-H, CAN-L, grounds, pilot signals)
- Communication cycle: 100 ms (10 Hz message rate)

- **CHAdeMO 2.0** (2018):
- Maximum power: 400 kW (1000V × 400A)
- Backward compatible with 1.x protocol
- Improved thermal management for high-power charging
- Enhanced safety features (insulation monitoring)
- Same CAN-based protocol with extended voltage/current ranges

- **CHAdeMO 3.0 / ChaoJi** (2020+):
- Maximum power: 900 kW (600-1500V × 600A)
- Unified with Chinese GB/T standard (ChaoJi = CHAdeMO + GB/T)
- New connector design (larger pins, liquid cooling support)
- PLC communication option (in addition to CAN)
- Supports both AC and DC charging on same connector

### Connector Pinout (CHAdeMO 1.0/2.0)

- **10-pin connector** (Yazaki YZ11/YZ12 series):
- Pin 1: DC+ (positive power)
- Pin 2: DC- (negative power, also serves as ground reference)
- Pin 3: Ground (chassis ground)
- Pin 4: Connector proximity detection (analog signal)
- Pin 5: Permission to start signal (digital, 12V logic)
- Pin 6: Charging permission signal (digital, 12V logic)
- Pin 7: CAN-H (high-speed CAN)
- Pin 8: CAN-L (low-speed CAN)
- Pin 9: Ground
- Pin 10: Reserved / Connector lock feedback

### CAN Communication Protocol

- **CAN bus parameters**:
- Baud rate: 250 kbps (CAN 2.0B, 11-bit identifier)
- Termination: 120Ω at both ends of CAN bus
- Message period: 100 ms (charger and EV both transmit at 10 Hz)
- Watchdog: If no message received for >500 ms, abort charging

- **Key CAN messages** (11-bit CAN IDs):
- 0x100: EV status (SOC, voltage request, current request, ready flag)
- 0x101: EV target values (target voltage, target current, fault flags)
- 0x102: Charger status (output voltage, output current, available power)
- 0x108: Charger capabilities (max voltage, max current, protocol version)
- 0x109: Charger control (contactor status, charging enabled, fault flags)

- **CAN message example** (EV status 0x100):
```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**:
```python def handle_v2g_discharge(): if ev_status.discharge_enabled: # EV requests negative current (discharge) discharge_current = ev_status.discharge_current  # e.g., -30A target_power = ev_status.battery_voltage * discharge_current
# Inverter converts DC to AC inverter_set_power(target_power)  # Negative power = export to grid
# Monitor grid voltage/frequency if grid_fault_detected(): stop_discharge() open_contactors() ```

### Safety Features

- **Insulation monitoring**:
- Measure DC+ and DC- to chassis ground before closing contactors
- Threshold: R_iso > 100 Ω/V (e.g., >50 kΩ for 500V)
- Continuously monitor during charging, trip if drops below 50 kΩ

- **Voltage/current limits**:
- Charger must not exceed EV requested voltage by >5%
- Current must not exceed min(EV_request, cable_rating, charger_rating)
- Overvoltage protection: Hardware clamp at 600V (CHAdeMO 1.x) or 1050V (2.0)

- **Emergency stop**:
- E-stop button immediately opens contactors (<500 ms)
- CAN communication sends "fault" status to EV
- Permission signals drop to 0V

- **Welding detection**:
- After opening contactors, charger checks if voltage still present on DC pins
- If V_pin > 50V, contactors may be welded (fault condition)
- Prevents user from unplugging live connector

### CHAdeMO Controller Implementation

- **State machine**:
```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**:
```python def transformer_loading_analysis(num_homes, num_evs, home_load_kw, ev_load_kw, xfmr_rating_kva): # Diversity factors home_diversity = 0.7  # Not all homes at peak simultaneously ev_diversity = 0.5    # Not all EVs charging simultaneously
# Peak load total_home_load = num_homes * home_load_kw * home_diversity total_ev_load = num_evs * ev_load_kw * ev_diversity total_load_kva = total_home_load + total_ev_load
# Loading percentage loading_pct = (total_load_kva / xfmr_rating_kva) * 100
# Overload assessment if loading_pct > 100: overload_kva = total_load_kva - xfmr_rating_kva status = "OVERLOAD" elif loading_pct > 80: overload_kva = 0 status = "WARNING (>80%)" else: overload_kva = 0 status = "OK"
return { "total_load_kva": total_load_kva, "loading_pct": loading_pct, "overload_kva": overload_kva, "status": status }
# Example: 10 homes, 5 EVs, 50 kVA transformer result = transformer_loading_analysis( num_homes=10, num_evs=5, home_load_kw=5, ev_load_kw=7.4, xfmr_rating_kva=50 ) # Result: {"total_load_kva": 53.5, "loading_pct": 107%, "status": "OVERLOAD"} # Recommendation: Upgrade to 75 kVA transformer or implement smart charging ```

- **Thermal aging**:
- Transformer insulation life halves for every 8°C rise in hotspot temperature
- Prolonged overload (>110%) accelerates aging → premature failure
- Solution: Upgrade transformer or manage EV charging (time-shift to off-peak)

### Voltage Drop and Regulation

- **Voltage drop in distribution feeder**:
- Ohm's law: V_drop = I × R + I × X (resistive + reactive drop)
- ANSI C84.1: Voltage at customer must be 114-126V (120V ± 5%)
- Long rural feeders: Significant voltage drop (e.g., 5V drop at end of 2-mile feeder)

- **Voltage drop calculation**:
```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**:
```python import numpy as np
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)
# Fundamental magnitude (60 Hz) idx_fundamental = np.argmin(np.abs(freqs - fundamental_freq)) i_fundamental = np.abs(fft[idx_fundamental])
# Harmonic magnitudes (3rd, 5th, 7th, ..., 40th) harmonic_sum = 0 for n in range(3, 41, 2):  # Odd harmonics dominate idx_harmonic = np.argmin(np.abs(freqs - n * fundamental_freq)) i_harmonic = np.abs(fft[idx_harmonic]) harmonic_sum += i_harmonic**2
# THD thd = np.sqrt(harmonic_sum) / i_fundamental return thd * 100  # Percentage
# Example: Measure current waveform from EV charger waveform = measure_current_waveform()  # From oscilloscope or power analyzer thd = calculate_thd(waveform, sample_rate=10000, fundamental_freq=60) # Result: THD = 8% (exceeds IEEE 519 limit of 5%) # Solution: Add harmonic filter or use charger with better PFC ```

- **Harmonic mitigation**:
- **Passive filter**: LC filter tuned to attenuate specific harmonics (5th, 7th)
- **Active filter**: Inject counter-harmonics to cancel distortion
- **Better PFC chargers**: High-quality boost PFC (THD <3%), totem-pole PFC (THD <2%)

### Power Quality Metrics

- **Voltage flicker**: Rapid voltage fluctuations (e.g., EV charger ramping up/down)
- Metric: P_st (short-term flicker severity), P_lt (long-term)
- Limit: P_st < 1.0 (IEC 61000-4-15)
- Mitigation: Slow ramp rates (1 kW/s instead of instantaneous), energy storage buffer

- **Power factor**: Ratio of real power to apparent power
- Poor PF: Higher current for same real power → increased losses, voltage drop
- Target: PF > 0.95 (utility requirement)
- EV chargers: PFC stage maintains PF >0.95

### Grid Upgrade Planning

- **Capacity planning for EV depots**:
- Scenario: 50-bus electric depot, 200 kWh per bus, 50 kW chargers
- Total energy: 50 buses × 200 kWh = 10,000 kWh/night
- Charging window: 8 hours (10 PM - 6 AM)
- Power required: 10,000 kWh / 8 hours = 1,250 kW average
- Peak demand (all chargers on): 50 buses × 50 kW = 2,500 kW
- Smart charging: Spread load → 1,500 kW peak (avoid demand charge spike)

- **Grid upgrade cost analysis**:
```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**:
```c #define GFCI_THRESHOLD_MA 20.0 #define GFCI_TRIP_TIME_MS 25
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; } } ```

### Insulation Monitoring

- **Purpose**: Detect insulation breakdown between HV (DC+, DC-) and chassis ground

- **Method**:
- Inject low-frequency AC or DC test signal between HV and ground
- Measure leakage current
- Calculate insulation resistance: R_iso = V_test / I_leakage

- **Threshold**: Per IEC 61851-23
- R_iso > 100 Ω/V (e.g., >40 kΩ for 400V system, >80 kΩ for 800V)
- Test before charging (pre-charge check)
- Continuous monitoring during charging

- **Insulation test circuit**:
``` HV+ ───┬─── 100kΩ test resistor ───┬─── Ground │                            │ IMD                      Current sensor HV- ───┴─────────────────────────┘ ```

- **IMD (Insulation Monitoring Device) code**:
```c #define R_ISO_MIN_OHM_PER_V 100.0
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; } ```

### Emergency Stop (E-Stop) System

- **Requirements** (IEC 60204-1):
- Hardwired: E-stop button directly interrupts contactor coil (not software)
- Latching: Requires manual reset (twist or pull button to reset)
- Response time: <500 ms from button press to contactors open
- Red button with yellow background (universally recognized)

- **E-stop circuit**:
``` 24V DC ───┬─── E-stop Button (NC contact) ───┬─── Contactor Coil ───┬─── Ground │                                   │                       │ │                                Safety Relay         Circuit Breaker ```

- **E-stop firmware**:
```c void CheckEmergencyStop(void) { bool e_stop_pressed = !GPIO_Read(PIN_EMERGENCY_STOP);  // Active low
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"); } } ```

### Control Pilot Safety (SAE J1772)

- **Control Pilot (CP) states**:
- State A: +12V (no vehicle connected)
- State B: +9V (vehicle connected, not ready to charge)
- State C: +6V (vehicle ready, charging allowed)
- State D: +3V (vehicle ready with ventilation required, not used in modern EVs)
- State E: 0V (short circuit, fault)
- State F: -12V (EVSE fault, no power available)

- **Safety interlock**:
- EVSE monitors CP voltage to detect vehicle connection state
- Charging only allowed in State C (vehicle ready)
- If CP transitions to State A (unplugged) while charging → immediate shutoff

- **CP monitoring code**:
```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 (240V AC) → Circuit Breaker → GFCI → Contactor → Energy Meter → Control Pilot (PWM) → J1772 Connector → EV ↓ Controller (STM32, ESP32) ↓ Communication (WiFi, 4G, Ethernet) ```

- **DC Fast Charger** (50-350 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**:
```c typedef enum { CONTACTOR_OPEN, PRECHARGE, CONTACTOR_CLOSED } ContactorState_t;
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; } } ```

### Energy Metering

- **Billing accuracy requirements**:
- MID (Measuring Instruments Directive) certified for EU: ±1% accuracy Class B
- ANSI C12.20 for North America: ±0.2% accuracy Class 0.2
- kWh resolution: 0.01 kWh (10 Wh)

- **Meter types**:
- **Direct metering**: CT (current transformer) on AC input or DC output
- **Integrated meter**: Dedicated energy meter IC (e.g., ADE7953, ATM90E36)
- **Smart meter**: Modbus RTU or Ethernet interface for remote reading

- **Meter integration**:
```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**:
``` Main Loop (1 kHz): - Read sensors (voltage, current, temperature) - Update state machine (idle, charging, fault) - Control contactors, power modules - Update display, LED indicators
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 ```

### Safety Systems

- **Ground Fault Circuit Interrupter (GFCI)** for AC:
- Detects leakage current: I_hot + I_neutral ≠ 0 (>20 mA for EV charging)
- Trip time: <25 ms
- Self-test: Monthly automatic test (simulate fault, verify trip)

- **Residual Current Device (RCD)** for DC:
- Monitors DC leakage: I_DC+ + I_DC- > 20 mA
- Sensor: Hall effect current sensors on both rails
- Trip: Open contactors within 100 ms

- **Insulation Monitoring Device (IMD)**:
- Measures DC+ and DC- to ground before charging
- Threshold: >100 Ω/V (e.g., >50 kΩ for 500V system)
- Method: Inject low-frequency AC or DC pulse, measure response

- **Overvoltage/overcurrent protection**:
- Hardware: Varistor (MOV) for transient overvoltage, fuse for overcurrent
- Software: Monitor voltage/current, trip contactors if exceed limits

- **Emergency stop (E-stop)**:
- Hardwired button (NO contact in series with contactor coil)
- Pressing E-stop immediately de-energizes contactors
- Reset: Requires manual reset (twisting E-stop button)

- **Thermal protection**:
- NTC thermistors on power semiconductors, contactors, connectors
- Derate power if temperature >80°C, shut down if >95°C

### Mechanical and Thermal Design

- **Enclosure**:
- IP rating: IP54 (indoor) or IP65 (outdoor, weatherproof)
- Material: Powder-coated steel or stainless steel
- Ventilation: Forced air cooling (fans) or natural convection for <10 kW
- Cable management: Strain relief, cable retractor for DC fast charging

- **Thermal management**:
- **Air-cooled** (<50 kW): Heatsinks with fans, 40-80 CFM airflow
- **Liquid-cooled** (>100 kW): Glycol-water loop, plate heat exchanger
- **Cable cooling** (>200A): Liquid-cooled cable (coolant channels in cable)

- **Connector mounting**:
- Holster: Wall-mounted or pedestal-mounted for cable storage
- Cable length: 3-5 meters (reach vehicle inlet from various parking positions)
- Cable weight: 3-5 kg for AC, 8-15 kg for DC (strain on user)

### Multi-Charger Depot Architecture

- **Power distribution** (10-charger depot):
``` 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**:
``` Charger Cabinet → Pump → Heat Exchanger → Coolant Inlet (cable) → Copper Conductors (removes heat) → Coolant Outlet → Return to Heat Exchanger ```

- **Coolant properties**:
- Fluid: 50/50 water-glycol mix (ethylene or propylene glycol)
- Freezing point: -37°C (for cold climates)
- Boiling point: 108°C (for hot climates)
- Viscosity: 3-5 cP at 20°C (low for efficient pumping)
- Specific heat: 3.5 kJ/(kg·K) (good thermal capacity)

- **Flow rate calculation**:
- Heat to remove: Q = I² × R = 500² × 0.050 = 12.5 kW
- Coolant flow rate: m_dot = Q / (c_p × ΔT)
- Example: 12.5 kW / (3.5 kJ/kg/K × 10 K) = 0.357 kg/s = 21 L/min
- Typical flow rate: 5-10 L/min per cable (conservative design)

### Connector Temperature Monitoring

- **Sensor placement**:
- NTC thermistor embedded in connector pin or housing
- Location: Hottest point (typically center pin, highest current density)
- Sensor type: 10 kΩ NTC, -40°C to +125°C range

- **Temperature thresholds**:
- Normal operation: <45°C (cool to touch)
- Warning: 45-55°C (reduce power by 20%)
- Derate: 55-65°C (reduce power by 50%)
- Fault: >65°C (stop charging immediately)

- **Temperature monitoring code**:
```c #define TEMP_NORMAL 45.0 #define TEMP_WARNING 55.0 #define TEMP_DERATE 65.0 #define TEMP_FAULT 75.0
float 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**:
```python def thermal_derating_factor(connector_temp, ambient_temp, duration_minutes): # Base derating from connector temperature if connector_temp < 45: factor = 1.0 elif connector_temp < 55: factor = 0.9 elif connector_temp < 65: factor = 0.7 else: factor = 0.0  # Stop charging
# Ambient temperature correction if ambient_temp > 25: factor *= (1 - 0.01 * (ambient_temp - 25))
# Duration correction (allow brief overload) if duration_minutes < 5: factor = min(1.0, factor * 1.2)  # 20% boost for short duration
return max(0.0, factor)
# Example i_rated = 500  # A temp_connector = 58  # C temp_ambient = 40  # C duration = 3  # minutes
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) ```

### Cooling System Design

- **Pump selection**:
- Type: Centrifugal pump (low pressure, high flow)
- Flow rate: 10-20 L/min (per cable)
- Pressure: 1-2 bar (overcome hose resistance, heat exchanger)
- Power: 50-100 W (electric motor driven)

- **Heat exchanger**:
- Type: Plate heat exchanger (compact, efficient)
- Hot side: Coolant from cable (40-50°C)
- Cold side: Ambient air or building chilled water
- Capacity: 15-20 kW thermal (for 350 kW charger with 5% loss = 17.5 kW heat)

- **Control strategy**:
```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**:
``` Heat Source (I²R) → Copper Conductor → Coolant → Heat Exchanger → Ambient
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!) ```

- **Transient thermal analysis** (Python example):
```python import numpy as np
def 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:

  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:

  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:

  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:

  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: List[Charger] = []
        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: List[Vehicle]) -> 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:
                    assignments[vehicle.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)); } ```

### Charging Sequence (DC Fast Charging)

- **Stage 1: Handshake and recognition** (5-10 seconds):
1. Vehicle plugged in, connector locked
2. Charger sends handshake (0x100: protocol version, charger ID)
3. EV responds with handshake (0x102: EV ID, battery capacity)
4. Charger sends capabilities (0x101: max V, max I)
5. EV sends requirements (0x103: max acceptable V, max I, battery type)

- **Stage 2: Charging preparation** (10-20 seconds):
1. Charger performs insulation test (DC+ and DC- to ground >100 kΩ/V)
2. Charger precharges DC bus to match EV battery voltage (within 20V)
3. EV sends "ready to charge" signal via A+ pin (12V)
4. Charger verifies readiness, sends status (0x105: ready flag set)

- **Stage 3: Charging execution** (main loop):
1. EV sends charging demand (0x104: target V, target I) every 250 ms
2. Charger regulates output to match demand (PI control loop)
3. Charger sends actual values (0x105: present V, present I) every 250 ms
4. EV monitors battery and adjusts demand dynamically (e.g., reduce current if hot)
5. Typical charging curve: Constant current (CC) to 80% SOC, then constant voltage (CV) to 100%

- **Stage 4: Charging termination**:
1. EV reduces current demand to <5A (near full charge)
2. Charger ramps output current to 0A over 5 seconds
3. Charger opens contactors (positive first, then negative)
4. Charger sends stop message (0x107: total energy, stop reason)
5. EV drops A+ signal to 0V (permission to charge removed)
6. Connector lock releases, user can unplug

### Safety and Protection

- **Insulation monitoring**:
- Measure R_iso between DC+ / DC- and PE before closing contactors
- Threshold: >100 Ω/V (e.g., >40 kΩ for 400V system)
- Continuous monitoring during charge, abort if drops below threshold

- **Voltage/current limits**:
- Charger must not exceed EV target voltage by >10V
- Current limited to min(EV_request, cable_rating, charger_rating)
- Hardware overvoltage protection: Varistor at 850V (for 750V max systems)

- **Emergency stop**:
- E-stop button immediately opens contactors and disables output (<500 ms)
- CAN message sent to EV indicating emergency stop
- A+ signal drops to 0V

- **Battery protection** (EV side):
- Overvoltage: Abort if cell voltage >4.25V (for Li-ion NMC)
- Overcurrent: Limit charge current based on battery temperature and SOC
- Temperature: Stop if battery >55°C or <0°C

### GB/T to CCS/CHAdeMO Adapter

- **Protocol translation** (GB/T ↔ CCS):
- CAN (GB/T 27930) ↔ PLC (ISO 15118) translation
- Message mapping: EV demand (GB/T) → CurrentDemandReq (ISO 15118)
- Timing conversion: 250 ms (GB/T) vs 100 ms (ISO 15118) update rates

- **Physical adapter**:
- GB/T male plug (charger side) → CCS female inlet (vehicle side)
- Pin mapping: DC+/DC- direct pass-through, CAN to PLC converter module
- Active electronics required (passive adapter not possible due to protocol difference)

- **ChaoJi unified standard**:
- Joint GB/T + CHAdeMO development (ChaoJi = "super charging" in Chinese)
- New connector design supporting up to 900 kW
- Compatible with both Chinese and Japanese EVs
- Expected to replace GB/T 20234.3 in future

### Charger Controller Implementation

- **State machine**:
```python class GBTChargerState(Enum): IDLE = 0 HANDSHAKE = 1 INSULATION_TEST = 2 PRECHARGE = 3 CHARGING = 4 STOPPING = 5 FAULT = 6
def 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):
```xml <SessionSetupReq> <Header> <SessionID>0x123456789ABCDEF0</SessionID> </Header> <EVCCID>DEADBEEF01020304</EVCCID> </SessionSetupReq> ```
- Text XML: ~200 bytes
- EXI encoded: ~30 bytes (85% size reduction)

- **EXI encoding in C**:
```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**:
```python def validate_contract_certificate(cert, root_ca): # 1. Check certificate not expired if cert.not_after < datetime.now(): return False
# 2. Verify signature chain to root CA if not verify_signature_chain(cert, root_ca): return False
# 3. Check revocation status (OCSP) ocsp_response = query_ocsp(cert.serial_number) if ocsp_response.status == REVOKED: return False
# 4. Check certificate purpose (must include "ISO 15118 V2G") if "ISO15118" not in cert.extended_key_usage: return False
return True ```

### ISO 15118-2 Message Flow

- **Session setup**:
1. SessionSetupReq: EV sends EVCC ID (EV Communication Controller ID)
2. SessionSetupRes: EVSE responds with EVSE ID, timestamp

- **Service discovery**:
1. ServiceDiscoveryReq: EV asks what services EVSE supports (AC, DC, Internet, V2G)
2. ServiceDiscoveryRes: EVSE lists available services (e.g., "DC charging, Plug & Charge auth")

- **Payment service selection**:
1. PaymentServiceSelectionReq: EV selects External Payment (Plug & Charge) or Contract
2. PaymentServiceSelectionRes: EVSE acknowledges

- **Certificate installation** (if needed):
1. CertificateInstallationReq: EV requests new contract certificate
2. CertificateInstallationRes: EVSE provides certificate via backend
(Typically done during initial provisioning, not every charge session)

- **Authorization**:
1. AuthorizationReq: EV sends contract certificate chain
2. AuthorizationRes: EVSE validates certificate, responds with "Accepted" or "Rejected"

- **Charge parameter discovery**:
1. ChargeParameterDiscoveryReq: EV sends battery parameters (capacity, max voltage, max current)
2. ChargeParameterDiscoveryRes: EVSE sends available power, charging profiles

- **DC charging sequence** (for DC fast charging):
1. CableCheckReq: EV checks cable insulation
2. PreChargeReq: EV requests EVSE to precharge to battery voltage
3. PowerDeliveryReq: EV requests to start power flow
4. CurrentDemandReq: EV sends target V/I every 100-250 ms
5. CurrentDemandRes: EVSE sends actual V/I
6. WeldingDetectionReq: Check for welded contactors after charging

- **Session stop**:
1. SessionStopReq: EV requests to end session
2. SessionStopRes: EVSE confirms, session data logged for billing

### Smart Charging with ISO 15118

- **Charging schedule negotiation**:
- EVSE sends charging schedule (kW available vs time)
- EV sends departure time and desired energy
- Both negotiate optimal charging curve (minimize cost or maximize renewable energy use)

- **Example charging schedule** (EVSE offers TOU pricing):
```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**:
```c #define MAX_TEMP_C 75.0 #define DERATE_START_TEMP_C 60.0
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; } ```

### Power Delivery Architecture

- **Charger topology**:
- AC input: Three-phase 480V or 690V (industrial grid connection)
- Rectifier: SiC-based three-phase PFC rectifier (>98% efficiency)
- DC-DC converter: Modular paralleled converters (10× 300 kW modules = 3 MW)
- Output voltage: 600-1500V (match truck battery voltage)
- Output filter: LC filter to reduce ripple to <1% at rated current

- **Modular architecture** (3 MW charger):
- 10× 300 kW power modules (each rated 1200V × 250A)
- Parallel output: All modules share DC bus via current-sharing control
- Redundancy: N+1 design (9 modules for 2.7 MW, 1 spare)
- Hot-swap: Failed module can be replaced without shutting down charger

- **Grid connection**:
- Transformer: 690V or 12.47 kV medium voltage to 480/690V AC
- Power factor: >0.95 with active PFC
- Harmonic distortion: THD <5% (meet IEEE 519 limits)
- Demand charge management: Integrate battery buffer to shave peak power from grid

### Communication Protocol

- **ISO 15118-20 over CAN**:
- CAN baud rate: 500 kbps (faster than 250 kbps for light-duty)
- Message period: 50 ms (20 Hz for fast response)
- EXI-encoded messages: Efficient binary XML for parameter exchange

- **Key parameters exchanged**:
- Battery capacity (kWh), current SOC (%)
- Maximum charge voltage (V), maximum charge current (A)
- Battery temperature, cell balancing status
- Desired energy to be delivered (kWh)
- Time available for charging (minutes, for depot scheduling)

- **Dynamic current control**:
```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**:
```python def depot_load_management(vehicles, total_power_available): # Sort by departure time (earliest first) vehicles.sort(key=lambda v: v.departure_time)
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
# Allocate power allocated_power = min(min_power_required, total_power_available, MCS_MAX_POWER) vehicle.charger.set_power(allocated_power) total_power_available -= allocated_power
# Redistribute unused power to lower-priority vehicles if total_power_available > 0: # Increase charge power for vehicles with flexible departure times pass ```

- **V2G for depot**:
- Discharge truck batteries to power depot operations during peak demand
- Reduce demand charges (utility tariff based on peak 15-min power draw)
- Example: 10 trucks × 500 kWh each = 5 MWh storage, provide 1 MW for 2 hours during peak

### Safety Systems

- **High-voltage isolation**:
- Insulation resistance: >500 Ω/V (e.g., >750 kΩ for 1500V system)
- Test method: DC voltage injection (500V test voltage), measure leakage current

- **Arc flash protection**:
- Arc detection: Optical sensors detect UV flash from arc
- Fast disconnect: Open contactors within 5 ms of arc detection
- Energy limitation: <40 cal/cm² incident energy (per NFPA 70E)

- **Ground fault protection**:
- Differential current sensing: I_DC+ + I_DC- < 50 mA (tighter than 20 mA for light-duty)
- Trip time: <20 ms for fast fault clearing

- **Connector interlock**:
- Weight: Cannot be lifted manually while energized (electric actuator required)
- Sensor: Verify connector fully seated before energizing (contact pressure switch)

### Installation Requirements

- **Physical infrastructure**:
- Concrete pad: Reinforced for charger weight (2-3 tons per charger)
- Cable management: Overhead cable retractor or floor-mounted dispenser
- Lighting: 200 lux minimum for nighttime operation

- **Electrical infrastructure**:
- Service entrance: 480V/690V three-phase, 3000A+ for 3 MW charger
- Transformer: Padmount or indoor, 3-5 MVA rating for multi-charger depot
- Switchgear: Medium-voltage (12.47 kV) for large depots (10+ chargers)

- **HVAC**:
- Charger cooling: Air-cooled heat exchanger or glycol-to-water (if building chilled water available)
- Ambient temperature: Charger rated for -30°C to +50°C operation

## Approach

1. **Fleet analysis**: Determine vehicle battery capacity, daily energy consumption, charge windows
2. **Power planning**: Calculate total power required (# vehicles × avg energy / charge time)
3. **Grid interconnection**: Work with utility for service upgrade (may require substation transformer)
4. **Charger selection**: MCS charger vendor (ABB, Siemens, ChargePoint, etc.)
5. **Installation**: Site work, electrical, coolant plumbing, communication network
6. **Commissioning**: Test each charger, verify cooling system, grid power quality
7. **Fleet integration**: Connect to fleet management system for charge scheduling

## Deliverables

- MCS charger specification (power, voltage range, cooling requirements)
- Depot layout design (charger placement, cable routing, electrical single-line)
- Load management system (software for smart charging)
- Safety analysis (arc flash study, ground fault coordination)
- Installation drawings (civil, electrical, mechanical)
- Commissioning test reports (power delivery, cooling, safety, communication)

## Best Practices

- **Redundancy**: N+1 charger design (spare charger for high-uptime fleets)
- **Battery buffer**: 1-2 MWh stationary battery to reduce grid peak demand charges
- **Preventive maintenance**: Monthly coolant testing, quarterly connector inspection
- **Cable strain relief**: Proper support for heavy cables (avoid kinking, dragging on ground)
- **Monitoring**: 24/7 remote monitoring with alerts for faults, performance degradation

## Integration

- **Fleet management**: API to telematics system (vehicle SOC, location, route plan)
- **Energy management**: Integrate with building energy management system (BEMS)
- **Utility demand response**: Curtail charging during grid peak events (earn incentive payments)
- **Payment**: Automated billing for mixed fleets (owner-operator trucks at public depot)

### nacs-tesla-standard

## Core Competencies

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.

### NACS Overview

- **History**:
- 2012: Introduced by Tesla as proprietary connector for Model S
- 2022: Tesla opens connector design to other manufacturers
- 2024: SAE publishes J3400 standard, officially named NACS
- 2025+: Major OEMs transition to NACS for North American vehicles

- **Key advantages**:
- Compact size: ~40% smaller than CCS1 connector
- Single connector for AC and DC (CCS requires separate pins for DC)
- High power capability: 1 MW DC potential (current Superchargers: 250 kW)
- Simpler cable: Lighter, easier to handle than CCS cable
- Ubiquity: 20,000+ Tesla Supercharger stalls in North America

### Connector Physical Design

- **Pin configuration** (5 pins total):
- Pin 1: AC/DC power (+) or L1 for AC
- Pin 2: AC neutral (N) or DC power (-)
- Pin 3: Control pilot (CP) signal, similar to J1772 PWM
- Pin 4: Proximity pilot (PP) or data communication (CAN/PLC future)
- Pin 5: Ground (PE, protective earth)

- **Mechanical**:
- Connector body: Thermoplastic with IP55 rating (dust/water resistant)
- Latch mechanism: Spring-loaded push-button release (single-hand operation)
- Cable retention force: >200 N (prevents accidental disconnect)
- Pin contact rating: 500A continuous (liquid cooling required for >300A)

### AC Charging (Level 1 / Level 2)

- **AC power delivery**:
- Single-phase: 120V or 240V (North America)
- Maximum current: 80A (19.2 kW at 240V)
- Typical home charging: 48A / 11.5 kW (Tesla Wall Connector)
- Pin usage: Pin 1 = L1 (hot), Pin 2 = N (neutral), Pin 5 = ground

- **Control pilot signaling** (J1772 compatible):
- PWM at 1 kHz, ±12V square wave
- Duty cycle indicates available current: I_max = duty × 0.6A (for 10% < duty < 96%)
- State detection: EVSE monitors CP voltage to detect vehicle connection
- State A: 12V (no vehicle)
- State B: 9V (vehicle connected, not ready)
- State C: 6V (vehicle ready, charging allowed)

- **Communication**:
- Basic charging: PWM duty cycle only (no data communication needed)
- Future: PLC or CAN on Pin 4 for advanced features (ISO 15118 support planned)

### DC Fast Charging

- **Power levels**:
- Tesla Supercharger V2: 150 kW (400V × 375A)
- Tesla Supercharger V3: 250 kW (400V × 625A, requires liquid cooling)
- Tesla Supercharger V4: 350 kW+ (500V × 700A or 800V × 437A for 800V vehicles)
- Future: Up to 1 MW for Semi (1000V × 1000A with Megacharger cable)

- **DC power delivery**:
- Pin 1: DC+ (positive rail)
- Pin 2: DC- (negative rail, isolated from chassis ground)
- Pin 5: Protective earth (chassis ground)
- Voltage range: 50V to 1000V (future: up to 1500V for Megacharger)

- **Control protocol** (Tesla proprietary, being standardized):
- Low-level: CP PWM for basic signaling (similar to CCS)
- High-level: CAN bus communication (250 kbps or 500 kbps) on Pin 4
- Message exchange: Vehicle sends target V/I, charger responds with actual V/I
- Update rate: ~10 Hz for current demand messages

- **Precharge sequence**:
1. Vehicle and charger handshake via CAN (exchange capabilities)
2. Charger precharges DC bus to match battery voltage (within 20V)
3. Charger signals "ready" via CAN
4. Vehicle closes contactors
5. Current ramps from 0 to target over ~2 seconds

### NACS Adapter Design

- **NACS to CCS1 adapter** (for non-Tesla EVs using Tesla Superchargers):
- Physical: NACS male plug on cable side, CCS1 female inlet on vehicle side
- Signal conversion: CP PWM (same on both sides, no conversion needed)
- DC pins: Direct pass-through (NACS Pin1→CCS DC+, NACS Pin2→CCS DC-)
- Communication: Translate Tesla CAN messages to ISO 15118 PLC (complex!)
- Contactors: None in passive adapter; vehicle controls contactors
- Limitation: Passive adapters may not support full Supercharger power (protocol mismatch)

- **CCS1 to NACS adapter** (for Tesla vehicles using CCS chargers):
- Tesla provides "CCS Combo 1 Adapter" for Model 3/Y/S/X
- Translates ISO 15118 messages to Tesla CAN protocol
- Enables Tesla to charge at Electrify America, EVgo, etc.
- Power limit: Typically 250 kW max (adapter thermal limit)

- **Active adapter implementation**:
```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**:
```python def thermal_derating(connector_temp, cable_temp, ambient_temp): max_current = 500  # Rated current at 25°C
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 ```

### Safety Features

- **Insulation monitoring**:
- Measure DC+ and DC- to ground before closing contactors
- Threshold: >100 Ω/V (e.g., >40 kΩ for 400V system)

- **Ground fault detection**:
- Hall effect sensors on DC+ and DC- rails
- Trip if I_DC+ + I_DC- > 20 mA (residual current)

- **Emergency stop**:
- E-stop button on charger opens contactors within 500 ms
- CP signal drops to 0V/-12V to signal fault

- **Connector lock**:
- Motorized or solenoid lock prevents unplugging while energized
- Vehicle or charger controls lock (released only when safe)

## Approach

1. **Connector sourcing**: NACS inlet/outlet from Tesla or third-party (e.g., Phoenix Contact)
2. **Power electronics**: DC-DC converter (50-1000V output, 250-500 kW typical)
3. **Communication**: Implement Tesla CAN protocol (if available) or wait for ISO 15118 standardization
4. **Cooling system**: Design liquid cooling loop for cables (pump, heat exchanger, sensors)
5. **Adapter development**: For CCS compatibility, develop active protocol translator
6. **Testing**: Interoperability testing with Tesla and non-Tesla NACS vehicles
7. **Certification**: UL 2202, SAE J3400 compliance testing

## Deliverables

- NACS charger controller firmware (C/C++)
- CAN protocol stack for Tesla communication
- Protocol translator for NACS-CCS interoperability (if needed)
- Thermal management system (cooling pump control, temperature monitoring)
- Safety monitor (insulation, ground fault, emergency stop)
- Test reports (power delivery, thermal, safety, interoperability)

## Best Practices

- **Backward compatibility**: Support both Tesla and non-Tesla NACS vehicles (different protocols)
- **Load sharing**: For multi-stall stations, implement dynamic power distribution
- **User experience**: Clear status LEDs, app notifications for charge start/stop/errors
- **Maintenance**: Monitor coolant level, filter cleanliness, connector wear
- **Future-proofing**: Design for 1 MW capability even if deploying 250 kW today

## Integration

- **OCPP backend**: Report sessions, energy, faults to central management system
- **Fleet management**: API for fleet operators (Tesla Fleet API, third-party fleets)
- **Payment gateway**: Integrate Stripe, PayPal, or direct credit card processing
- **Grid services**: Participate in demand response programs (curtail charging during peak)

### smart-charging-algorithms

## Core Competencies

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.

### Smart Charging Objectives

- **Cost minimization**: Charge when electricity is cheapest (off-peak, high renewable generation)
- **Grid support**: Avoid peak demand periods, participate in demand response programs
- **Renewable integration**: Maximize charging from solar/wind (time-shift to match generation)
- **Load balancing**: Distribute available power across multiple EVs (avoid overloading circuits)
- **User satisfaction**: Ensure vehicle ready by departure time with desired SOC

### Time-of-Use (TOU) Optimization

- **TOU rate structure** (example utility):
- Off-peak: $0.08/kWh (midnight-6 AM)
- Mid-peak: $0.15/kWh (6 AM-4 PM, 9 PM-midnight)
- On-peak: $0.35/kWh (4 PM-9 PM, summer weekdays)

- **Optimization algorithm**:
```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**:
```python def dynamic_load_balancing(evs, max_power_available): # Priority: Earliest departure time, lowest SOC evs.sort(key=lambda ev: (ev.departure_time, ev.soc))
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
# Allocate power (up to EV max, charger max, or remaining grid capacity) allocated = min( ev.max_charge_power, ev.charger_max_power, min_power_required * 1.2,  # 20% margin remaining_power )
allocated_power[ev.id] = allocated remaining_power -= allocated
if remaining_power <= 0: break
# EVs not allocated power will wait (lower priority or already charged enough) for ev in evs: if ev.id not in allocated_power: allocated_power[ev.id] = 0  # Wait for higher-priority EVs to finish
return allocated_power
# Example evs = [ EV(id=1, soc=20, target=80, departure="07:00", max_power=7.4), EV(id=2, soc=50, target=90, departure="08:00", max_power=7.4), EV(id=3, soc=30, target=80, departure="06:30", max_power=11.0), # ... 7 more EVs ] allocation = dynamic_load_balancing(evs, max_power_available=50) # Result: EV3 gets 11 kW (earliest departure), EV1 gets 7.4 kW (lowest SOC), etc. ```

### Renewable Energy Integration

- **Solar PV integration**:
- Home solar: 5 kW system produces 20-30 kWh/day
- Maximize solar charging: Shift EV charge to midday (10 AM - 4 PM)
- Net metering: Charge from solar instead of exporting to grid (avoid low export rates)

- **Solar forecast-based charging**:
```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 import
charge_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)**:
```python def handle_demand_response_event(event): # Event: {signal: "MODERATE", duration: 120 min, start: "16:00"}
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
# Apply reduction to all active chargers for charger in active_chargers: original_power = charger.current_power new_power = original_power * (1 - reduction_factor) charger.set_power(new_power)
# Log for settlement (prove load reduction for payment) log_dr_event(charger.id, original_power, new_power, event.duration)
# Schedule return to normal after event ends schedule_task(event.start + event.duration, resume_normal_charging) ```

- **Revenue calculation**:
- Baseline: 10 EVs × 7.4 kW = 74 kW
- Event: Reduce to 0 kW for 2 hours
- Load reduction: 74 kW × 2 hours = 148 kWh
- Payment: 148 kWh × $2/kWh = $296 per event
- Frequency: 10-20 events/year → $3000-6000 annual revenue

### Fleet Depot Charging Optimization

- **Fleet scenario**: 50 electric buses, overnight charging (8 PM - 5 AM)
- **Constraints**:
- Total power: 2 MW (50× 50 kW chargers would be 2.5 MW)
- Each bus needs 200 kWh (30% → 100% SOC, 300 kWh battery)
- Staggered departure times (routes start 5:00 - 7:00 AM)

- **Optimization objective**: Minimize peak demand charge ($15/kW/month)

- **Smart depot charging**:
```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**:
```python def v2g_arbitrage_optimization(ev, tou_schedule, departure_time, min_soc_at_departure): # Find cheapest period to charge, most expensive to discharge charge_period = min(tou_schedule, key=lambda x: x.rate) discharge_period = max(tou_schedule, key=lambda x: x.rate)
# Charge during cheap period energy_to_charge = ev.battery_capacity * 0.6  # 60% of battery charge_schedule = { "start": charge_period.start_time, "power": ev.max_charge_power, "energy": energy_to_charge, "cost": energy_to_charge * charge_period.rate }
# Discharge during expensive period (but ensure min SOC at departure) energy_to_discharge = ev.battery_capacity * 0.4  # 40% of battery discharge_schedule = { "start": discharge_period.start_time, "power": -ev.max_discharge_power,  # Negative = discharge "energy": energy_to_discharge, "revenue": energy_to_discharge * discharge_period.rate }
# Ensure min SOC at departure (recharge if needed) final_soc = ev.soc + (energy_to_charge - energy_to_discharge) / ev.battery_capacity if final_soc < min_soc_at_departure: # Add make-up charge makeup_energy = (min_soc_at_departure - final_soc) * ev.battery_capacity charge_schedule["energy"] += makeup_energy
return charge_schedule, discharge_schedule ```

### Machine Learning for Charging Prediction

- **Use case**: Predict user charging behavior to optimize preemptively
- **Inputs**: Historical data (arrival time, departure time, SOC at arrival, target SOC)
- **Model**: Random forest or neural network to predict next session parameters

- **Training data**:
```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)

```c
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): Grid ────┬──── ATS ────┬──── Main panel (non-critical) │ │ │ └──── Critical loads panel (2-3 kW) │ Solar ───┴──── EV bidirectional inverter ───┘

Islanding Detection and Anti-Islanding

• Islanding scenario:

• Grid outage occurs while EV is discharging

• EV must detect outage and disconnect (anti-islanding protection)

• If ATS present: EV switches to backup mode (continues powering home in islanded mode)

• If no ATS: EV must shut down immediately (IEEE 1547 requirement)

• Detection methods:

• Passive: Monitor voltage (88-110% of nominal) and frequency (59.3-60.5 Hz for 60 Hz grid)

• Active: Inject disturbance (frequency shift, impedance measurement), detect grid disconnection

• Transfer trip: Utility sends signal to disconnect (requires communication)

• Anti-islanding with ATS:

# 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**:
```python def load_management(soc, critical_loads): max_power = 10000  # 10 kW inverter rating
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
# Turn off loads exceeding max_power total_power = sum(load.power for load in allowed_loads) if total_power > max_power: # Shed lowest priority loads first allowed_loads.sort(key=lambda x: x.tier, reverse=True) while total_power > max_power and allowed_loads: shed_load = allowed_loads.pop() shed_load.turn_off() total_power -= shed_load.power
return total_power ```

### Backup Duration Calculation

- **Energy available**:
- EV battery: 75 kWh (usable capacity, 10-90% SOC)
- Reserve for driving: 15 kWh (20% SOC, ~60 miles range)
- Available for home: 60 kWh

- **Home consumption**:
- Critical loads: 2 kW average
- Backup duration: 60 kWh / 2 kW = 30 hours (>1 day)
- Full home: 5 kW average → 12 hours backup

- **Real-world factors**:
- Inverter efficiency: 90-95% (lose 5-10% in conversion)
- Cold weather: Battery capacity reduced by 20% at 0°F
- Load diversity: Actual consumption varies (refrigerator cycles on/off)

### Integration with Solar and Battery

- **Solar + V2H**:
- During outage: Solar charges EV, EV powers home (extend backup duration indefinitely)
- Typical home solar: 5 kW system produces 20-30 kWh/day
- Strategy: Use solar to recharge EV during day, discharge EV at night

- **Stationary battery + V2H**:
- Powerwall (13.5 kWh) + EV (75 kWh) = 88.5 kWh total
- Powerwall handles short-duration outages (few hours)
- EV provides extended backup (multi-day outages)
- Coordination: Discharge Powerwall first (smaller, dedicated for backup), then EV

- **Coordinated control**:
```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**:
``` HV Battery (400V DC) ↓ DC-DC Converter (400V → 120V DC) ↓ Inverter (120V DC → 120V AC @ 60 Hz) ↓ GFCI Protection (30 mA trip) ↓ Circuit Breaker (15A) ↓ NEMA 5-15R Outlet (120V AC, 1800W max) ```

### Protection Circuits

- **Ground Fault Circuit Interrupter (GFCI)**:
- Detects leakage current >30 mA (person touching hot wire to ground)
- Trip time: <25 ms (prevents electrocution)
- Required for outdoor outlets per NEC

- **Arc Fault Circuit Interrupter (AFCI)** (optional):
- Detects arcing faults (damaged cords, loose connections)
- Reduces fire risk

- **Overcurrent protection**:
- Circuit breaker: 15A or 20A (trips if load exceeds rating)
- Electronic current limit: Inverter shuts down if output current >120% rated for >30 seconds

- **Overvoltage/undervoltage**:
- Shut down if output voltage <102V or >132V (for 120V nominal)
- Protects connected equipment from damage

- **Thermal protection**:
- Monitor inverter temperature, derate power if >80°C
- Shut down if >95°C (prevent thermal runaway)

- **Battery protection**:
- Reserve SOC: Disable V2L if battery <20% (ensure enough charge to drive to charger)
- Low voltage cutoff: Stop discharge if battery voltage drops below minimum (prevent cell damage)

### Control Logic and User Interface

- **Activation**:
- Button on dashboard: "V2L Enable" (some vehicles require vehicle in Park and key on)
- Automatic: Plug in device, inverter activates (Hyundai/Kia approach)
- App control: Enable/disable V2L remotely via mobile app

- **Power management**:
```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**:
``` Runtime (hours) = (Battery Capacity × Usable SOC × Inverter Efficiency) / Load Power
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 ```

- **Variable loads**:
- Refrigerator: Cycles on (150W) for 20 min/hour, off for 40 min/hour → average 50W
- Power tools: Intermittent use → average 30% duty cycle
- Lights: Continuous → 100% duty cycle

## Approach

1. **Requirements**: Determine power level (1.5 kW standard or 3.6 kW high-power)
2. **Inverter design**: Pure sine wave, isolated topology, THD <3%
3. **Outlet selection**: NEMA 5-15R (120V 15A) or NEMA 14-50R (240V 50A) for high-power
4. **Protection**: Integrate GFCI, circuit breaker, thermal shutdown
5. **Integration**: Connect to vehicle CAN bus for SOC monitoring, user interface
6. **Testing**: Load testing (resistive, inductive, capacitive), efficiency measurement, safety compliance

## Deliverables

- V2L inverter design (schematic, PCB layout, thermal analysis)
- AC outlet integration (mounting, wiring, weatherproofing)
- Protection circuits (GFCI, breaker, overvoltage/undervoltage)
- Control software (battery management, user interface, fault handling)
- Test reports (power quality, efficiency, load testing, safety compliance)
- User manual (operation, compatible loads, runtime estimation)

## Best Practices

- **Reserve SOC**: Always maintain 20% battery for driving (avoid being stranded)
- **Load matching**: Do not exceed inverter rating (1.5 kW typical)
- **Thermal management**: Ensure adequate cooling, avoid continuous operation at max power in hot weather
- **User education**: Teach users about runtime estimation, compatible loads, safety
- **Maintenance**: Inspect outlets for damage, test GFCI monthly

## Integration

- **Mobile app**: Display V2L status, power consumption, estimated runtime
- **Smart home**: Control V2L remotely (enable/disable via app)
- **Fleet management**: Track V2L usage for work trucks (job site power consumption)
- **Emergency systems**: Integrate with disaster response (mobile charging station for phones, medical devices)

### wireless-charging-wpt

## Core Competencies

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).

### WPT Technology Overview

- **Inductive power transfer**:
- Primary coil (GA): Installed in ground or pavement, generates AC magnetic field
- Secondary coil (VA): Mounted under vehicle, couples with GA field to induce current
- Air gap: Typically 100-250 mm (ground clearance of vehicle)
- Frequency: 85 kHz (SAE J2954 standard frequency)
- Efficiency: 85-93% (system level, including coil coupling and power electronics losses)

- **Power levels** (SAE J2954 classification):
- WPT1: Up to 3.7 kW (Level 1 equivalent, overnight home charging)
- WPT2: Up to 7.7 kW (Level 2 equivalent, typical home/workplace)
- WPT3: Up to 11 kW (three-phase equivalent, faster charging)
- WPT4: 11-22 kW (high-power wireless, commercial/fleet applications)

- **Coupling types**:
- Circular coils: Traditional design, good for centered alignment
- DD (Double-D) coils: Rectangular, better lateral tolerance
- DDQ (Double-D Quadrature): DD + Q coil for improved misalignment tolerance
- Bipolar coils: Two coils with opposite polarity for cancellation of stray fields

### SAE J2954 System Architecture

- **Ground assembly (GA)**:
- Primary coil: Litz wire (copper strands for reduced skin effect at 85 kHz)
- Ferrite core: Increase flux concentration, reduce stray fields
- Shielding: Aluminum plate below ferrite to block downward flux (protect underground utilities)
- Enclosure: IP67 rated, vehicle-rollover resistant (40 kN load)
- Power electronics: Inverter to convert DC to 85 kHz AC

- **Vehicle assembly (VA)**:
- Secondary coil: Litz wire, similar size to GA coil (200-300 mm diameter)
- Ferrite core: Improves coupling coefficient (k = 0.1 to 0.3 typical)
- Shielding: Aluminum plate above ferrite to protect vehicle components from EMF
- Rectifier: AC to DC converter, outputs to vehicle battery
- Mounting: Integrated into vehicle underbody, clearance ~150 mm from ground

- **Communication**:
- Low-power Bluetooth or Zigbee for initial pairing
- In-band communication: Modulate 85 kHz signal for real-time data (power level, alignment)

### Coil Design and Coupling

- **Coupling coefficient** (k):
- Perfect alignment, 150 mm gap: k ≈ 0.25
- 100 mm lateral offset: k ≈ 0.15 (significant power drop)
- Formula: k = M / sqrt(L1 × L2), where M is mutual inductance, L1/L2 are self-inductances

- **Compensation topology**:
- Series-series (SS): Both GA and VA coils in series with capacitors (resonant at 85 kHz)
- LCC: Inductor-capacitor-capacitor network, better tolerance to load variation
- Resonance: Tune to 85 kHz ± 1 kHz (tight tolerance for max efficiency)

- **Power transfer equation**:
``` P_out = k² × Q × P_in
where: 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**:
```python def align_coils(): # Energize GA with low power (100W) to sense VA position ga_energize_low_power()
# Measure induced voltage in VA, estimate position va_voltage = measure_va_voltage() offset_x, offset_y = estimate_offset(va_voltage)
if abs(offset_x) > 25 or abs(offset_y) > 25: # Move GA or provide driver feedback move_ga(offset_x, offset_y)
# Verify alignment improved if coupling_coefficient() > 0.2: return ALIGNED else: return MISALIGNED ```

### Foreign Object Detection (FOD)

- **Objective**: Detect metal objects (coins, tools, cans) in air gap before energizing
- **Detection method**:
- Q-factor measurement: Metal object reduces coil Q (increases losses)
- Baseline Q (no object): 250, with object: <200 → FOD triggered
- Sweep frequency: Measure impedance from 80-90 kHz, detect anomalies

- **FOD threshold**:
- Small objects (<10 g metal): May not trigger (acceptable risk)
- Medium objects (10-100 g): Detected, abort charging
- Large objects (>100 g): Easily detected, alert user to remove

- **FOD sequence**:
1. Before charging: Perform Q measurement sweep (takes ~1 second)
2. If FOD detected: Display warning, do not energize GA
3. User removes object, retry FOD check
4. During charging: Continuously monitor Q, abort if sudden drop (object fell into gap)

### Living Object Protection (LOP)

- **Objective**: Detect animals (cats, rodents) or humans (hands, feet) in magnetic field
- **Detection method**:
- Proximity sensors: Capacitive or infrared sensors around GA perimeter
- Motion detection: PIR (passive infrared) sensor to detect movement
- Temperature sensing: Thermal camera to detect warm-blooded creatures

- **Action on detection**:
- Reduce power to minimum (100W) for sensing only
- Alert user (horn, app notification) to check area
- Do not energize at full power until area clear for 10 seconds

### Power Control and Regulation

- **Constant current (CC) to constant voltage (CV)**:
- Initial: Charge at max current (e.g., 32A at 240V DC = 7.7 kW)
- As battery reaches 80% SOC: Transition to constant voltage (battery voltage setpoint)
- Taper: Current gradually reduces to <2A at full charge (100% SOC)

- **Feedback loop**:
- VA sends battery voltage and current to GA via in-band communication
- GA adjusts inverter duty cycle to maintain target power
- Update rate: 10 Hz (100 ms loop time)

- **Detuning compensation**:
- Temperature changes → capacitor value drift → resonance shift
- Adaptive tuning: Measure phase between voltage and current, adjust freq slightly (85 ± 0.5 kHz)

### EMC and Safety

- **Magnetic field limits** (ISO 19363):
- At 300 mm from GA edge: <27 µT (microtesla) at 85 kHz
- Shielding effectiveness: >40 dB (aluminum + ferrite)
- Exposure limits: ICNIRP guidelines for general public (0.2 µT continuous exposure)

- **EMI (electromagnetic interference)**:
- Frequency stability: 85 kHz ± 1 kHz (avoid ISM band interference)
- Harmonic suppression: <1% THD (total harmonic distortion) at AC input
- Conducted emissions: Meet CISPR 11 Class B limits

- **Electrical safety**:
- Isolation: >10 MΩ between coil and chassis
- Ground fault: Monitor leakage current, trip if >30 mA AC
- Arc flash: Low voltage DC (400V max) reduces risk vs high-voltage DC fast charging

### Dynamic Wireless Charging (In-Road)

- **Concept**: Coils embedded in road surface, charge while vehicle drives
- **Implementation**:
- Segmented coils: Every 2-3 meters, energize only when vehicle overhead
- Vehicle detection: Inductive loop sensors or cameras detect approaching EV
- Handoff: Seamlessly transfer power from coil N to coil N+1 as vehicle moves
- Efficiency: ~70-80% (lower than static due to speed, shorter dwell time)

- **Power delivery**:
- Speed: 60 km/h (16.7 m/s)
- Coil length: 3 m → dwell time = 180 ms per coil
- Power per coil: 20 kW × 0.18 s = 1 Wh per coil
- 1 km of road = 333 coils = 333 Wh delivered per pass (range extension: ~1.5 km)

- **Challenges**:
- Cost: $1-2 million per lane-km for installation
- Maintenance: Road work requires excavation to access coils
- Efficiency: Lower than static charging, high losses in pavement

## Approach

1. **Site survey**: Measure ground clearance of target vehicles, parking surface (concrete/asphalt)
2. **GA installation**: Embed coil in pavement or use surface-mount pad (for retrofit)
3. **VA integration**: Mount secondary coil to vehicle underbody (aftermarket or OEM)
4. **Power electronics**: Install inverter (GA side) and rectifier (VA side)
5. **Alignment system**: Camera + LED guidance for manual parking, or automated XY table
6. **FOD/LOP**: Integrate sensors, calibrate detection thresholds
7. **Testing**: Efficiency measurement, EMC testing, safety compliance (UL 2750)

## Deliverables

- WPT system design (coil dimensions, power level, efficiency target)
- GA installation drawings (civil work, electrical conduit, waterproofing)
- VA mounting bracket design (vehicle-specific)
- Alignment system (visual or automated)
- FOD/LOP sensor integration
- Test reports (efficiency, EMC, safety, interoperability)

## Best Practices

- **Weatherproofing**: GA must withstand rain, snow, vehicle traffic (IP67 minimum)
- **Thermal management**: Ferrite core can heat up; add cooling fins or airflow if >10 kW
- **User experience**: Alignment must be intuitive (frustration if too finicky)
- **Compatibility**: Follow SAE J2954 for interoperability across OEMs
- **Cost**: Wireless charging typically 2-3× cost of wired Level 2 charger

## Integration

- **Smart home**: Integrate with home energy management (charge during cheap electricity hours)
- **Fleet**: Wireless charging ideal for buses (fixed parking, automated alignment)
- **Autonomous**: Essential for robotaxis (no human to plug in cable)
- **Grid services**: V2G via wireless (bidirectional WPT, discharge to grid during peak)