VDV261 V2ICP Communication Sequences

This document visualises the typical Vehicle-to-Infrastructure Communication Protocol (V2ICP) flow defined by VDV 261. It mirrors the style used for the VDV463 communication guide so that engineers can cross-reference how the two recommendations interact during depot charging.

We assume: - ISO 15118 charging is active and the Supply Equipment Communication Controller (SECC) offers VAS 3 InternetAccess. - The Electric Vehicle Communication Controller (EVCC) is provisioned with the backend address, VIN-based credentials, and the V2ICP root certificate. - The depot backend terminates HTTPS on port 443 and exposes the /vdv261/v2icp/messages endpoint as described in the OpenAPI schema.

Participants used in the diagrams: - EV - EVCC (Vehicle) - SECC - SECC (Charging Station) - Backend - CMS Backend / CMS

---

1. VAS Discovery and HTTPS Tunnel Establishment

The vehicle activates the InternetAccess VAS during the ISO 15118 handshake so that the SECC forwards HTTPS traffic to the backend. (VDV 261 Sections 1.3 and 3.2)

sequenceDiagram
    autonumber
    participant EV as Vehicle (EVCC)
    participant SECC as Charging Station (SECC)
    participant BE as CMS Backend

    EV->>SECC: ServiceDiscoveryReq (ISO 15118)
    SECC-->>EV: ServiceDiscoveryRes (includes ServiceID 3)
    EV->>SECC: ServiceDetailReq (ServiceID 3)
    SECC-->>EV: ServiceDetailRes (ParameterSetID 4)
    EV->>SECC: Request VAS 3 InternetAccess
    SECC-->>EV: Expose HTTPS tunnel on port 443
    EV->>BE: TLS handshake via SECC<br/>Validate V2ICP root certificate
    BE-->>EV: TLS session established
    Note over EV,BE: Vehicle confirms V2ICP is enabled and credentials are present

---

2. Initial Parameter Synchronisation (seq = 0)

Once the tunnel exists, the EVCC immediately posts the complete telemetry set with sequence number 0. The backend authenticates the VIN/password combination and acknowledges with its current directives. (VDV 261 Section 3.2.1, Table 5 and Table 6)

sequenceDiagram
    autonumber
    participant EV as Vehicle
    participant BE as CMS

    EV->>BE: HTTP POST /vdv261/v2icp/messages<br/>seq 0 + full VehicleParameterSet<br/>Authorization: Basic VIN:password
    BE-->>EV: HTTP 200<br/>seq 0 + BackendParameterSet
    Note over EV,BE: Both sides reset their retry counters after a successful exchange

Example payloads

Request:

{
  "seq": 0,
  "vin": "WVVZZZ1JZX000001",
  "evccid": "00-1A-B2-C3-D4-E5",
  "parameters": {
    "odo": 18234,
    "chrg_stat": 1,
    "h2_stat": 0,
    "bat_stat": 0,
    "bat_reqtime": 40,
    "bat_eamount": 240,
    "bprec_eamount": 60,
    "prec_reqtime": 30,
    "prec_eamount": 12
  }
}

Response:

{
  "seq": 0,
  "vin": "WVVZZZ1JZX000001",
  "parameters": {
    "driveoff": 45,
    "prec_dsrd": 1,
    "prec_hvac": 3,
    "ambienttemp": 4,
    "target_dist": 120,
    "target_soc": 85
  }
}

---

3. Cyclic Delta Updates During Charging

While the charging session is active, the EVCC sends delta updates every 10 s. h2_stat and bat_stat must be present in every message; other parameters are included only when they change. The backend reuses the incoming sequence number in its acknowledgement and may adjust departure or preconditioning directives on the fly. (VDV 261 Section 3.2.1.1)

sequenceDiagram
    participant EV as EVCC (Vehicle)
    participant BE as Depot Backend

    loop Every 10 s while ISO 15118 session active
        EV->>BE: POST seq n<br/>Changed telemetry (incl. h2_stat + bat_stat)
        BE-->>EV: 200 OK seq n<br/>Optional directive updates
    end
    Note over EV,BE: Sequence counter wraps after 255 -> vehicle restarts at 0 with full dataset

Example delta update

Request:

{
  "seq": 12,
  "vin": "WVVZZZ1JZX000001",
  "evccid": "00-1A-B2-C3-D4-E5",
  "parameters": {
    "h2_stat": 0,
    "bat_stat": 1,
    "chrg_stat": 3,
    "bat_eamount": 220
  }
}

Response:

{
  "seq": 12,
  "vin": "WVVZZZ1JZX000001",
  "parameters": {
    "driveoff": 40,
    "prec_dsrd": 1
  }
}

---

4. Backend Preconditioning Directive Lifecycle

The backend can request vehicle preconditioning by toggling prec_dsrd (and optionally prec_hvac). The vehicle honours the instruction and reports energy usage and remaining time in subsequent delta updates. (VDV 261 Table 6 and Table 5)

sequenceDiagram
    autonumber
    participant EV as EVCC (Vehicle)
    participant BE as Depot Backend

    BE-->>EV: 200 OK seq 42<br/>parameters.prec_dsrd = 1<br/>parameters.prec_hvac = 2
    Note over EV,BE: Backend signals HVAC preconditioning request
    EV->>BE: POST seq 43<br/>prec_reqtime = 45<br/>bprec_eamount = 65
    BE-->>EV: 200 OK seq 43<br/>driveoff updated, ambienttemp mirrored
    loop During preconditioning
        EV->>BE: POST seq n<br/>prec_reqtime decrements<br/>prec_eamount accumulates
        BE-->>EV: 200 OK seq n<br/>prec_dsrd held at 1 until backend cancels
    end
    BE-->>EV: 200 OK seq 47<br/>parameters.prec_dsrd = 0
    EV->>BE: POST seq 48<br/>Report final prec_eamount + reset timers

Example directive exchange

Backend acknowledgement setting preconditioning on:

{
  "seq": 42,
  "vin": "WVVZZZ1JZX000001",
  "parameters": {
    "prec_dsrd": 1,
    "prec_hvac": 2,
    "driveoff": 50
  }
}

Vehicle response with updated telemetry:

{
  "seq": 43,
  "vin": "WVVZZZ1JZX000001",
  "evccid": "00-1A-B2-C3-D4-E5",
  "parameters": {
    "h2_stat": 0,
    "bat_stat": 1,
    "prec_reqtime": 45,
    "prec_eamount": 15,
    "bprec_eamount": 65
  }
}

Vehicle confirmation after backend clears the request:

{
  "seq": 48,
  "vin": "WVVZZZ1JZX000001",
  "evccid": "00-1A-B2-C3-D4-E5",
  "parameters": {
    "h2_stat": 0,
    "bat_stat": 0,
    "prec_reqtime": 0,
    "prec_eamount": 18,
    "bprec_eamount": 65
  }
}

---

5. Resilience: Retries, Idle Timeouts, and Resume

Both sides must handle transport interruptions gracefully. The EVCC retries failed POST requests up to three times with a 15 s timeout, then backs off while the charging session stays active. If the link idles for more than 61 s, the TLS tunnel is closed and the EVCC schedules reconnect attempts at 5, 15, and 30 minutes. (VDV 261 Sections 3.2.1 and 3.2.5.1)

sequenceDiagram
    autonumber
    participant EV as EVCC (Vehicle)
    participant BE as Depot Backend

    EV->>BE: POST seq 90 (attempt 1)
    Note over EV,BE: Wait for HTTP 200 up to 15 s

    alt Timeout reached
        EV->>BE: POST seq 90 (attempt 2)
        Note over EV,BE: Wait for HTTP 200 up to 15 s

        alt Backend still unavailable
            EV->>BE: POST seq 90 (attempt 3)
            Note over EV,BE: Wait for HTTP 200 up to 15 s

            alt All retries failed
                EV-->>BE: Close TLS channel after 61 s idle
                EV->>BE: Reconnect & POST seq 91 after 5 min
            else Charging session ended
                EV-->>BE: Stop retries
            end
        else Attempt 2 succeeds
            BE-->>EV: HTTP 200 seq 90
        end
    else Initial attempt succeeds
        BE-->>EV: HTTP 200 seq 90
    end

Example retry payloads

Initial attempt (no response received before timeout):

{
  "seq": 90,
  "vin": "WVVZZZ1JZX000001",
  "evccid": "00-1A-B2-C3-D4-E5",
  "parameters": {
    "h2_stat": 0,
    "bat_stat": 0,
    "chrg_stat": 1
  }
}

Retry attempt after 15 s using the same sequence number:

{
  "seq": 90,
  "vin": "WVVZZZ1JZX000001",
  "evccid": "00-1A-B2-C3-D4-E5",
  "parameters": {
    "h2_stat": 0,
    "bat_stat": 0,
    "chrg_stat": 1
  }
}

Backend acknowledgement once service recovers:

{
  "seq": 90,
  "vin": "WVVZZZ1JZX000001",
  "parameters": {
    "driveoff": 60,
    "ambienttemp": 6
  }
}

---

Key Takeaways

• Always send the full dataset when seq rolls over to 0, otherwise include only changed telemetry plus h2_stat and bat_stat.
• Maintain Basic Authentication per HTTPS session; the VIN is mandatory even when no password is configured.
• Respect the 61 s idle timeout and exponential reconnect cadence to avoid overwhelming the backend.
• Backend directives (prec_dsrd, prec_hvac, driveoff, ambienttemp) should be idempotent - each acknowledgement mirrors the latest instruction so the EVCC can recover state after retries.