VDV Recommendation 261, Edition 2/2023

Introduction

Before defining requirements, this chapter first explains relevant basics and background. An essential component of the communicative connection of the bus to a back-end system defined in this paper is the use of Value Added Services (VAS), i.e. value-added services within the charging communication according to ISO 15118.

What are Value Added Services?

Value Added Services are optional services within ISO 15118-2, Ed. 1 that the charging station (EVSE) can offer to the vehicle (EV).

The following services are defined in ISO 15118-2, Ed. 1.

ServiceID (unsigned short)	ServiceName	ServiceCategory	Description
0	Reserved by ISO/IEC	-	-
1	AC_DC_Charging	EVCharging	All charging services as defined by SupportedEnergyTransferMode in subclause 8.5.2.3.2
2	Certificate	ContractCertificate	Service allowing to update or install Contract Certificates
3	InternetAccess	Internet	Service for standard protocols like HTTP, HTTPS, FTP, etc.
4	UseCaseInformation	EVSEInformation	Service enabling the exchange of use case specific information about the EVSE.
5 - 60000	Reserved by ISO/IEC	-	-
60001 - 65535	Reserved for implementation specific use	-	-

The services to be used must be known to both the charging station as well as the vehicle. The VAS used for the communication defined in this recommendation has the ServiceID 3 and is called Internet Access. Within this VAS, the standard protocols such as HTTPS can be used.

System architecture

graph LR
    EVCC["EVCC<br/>Vehicle"]
    SECC["SECC<br/>Charging Station"]
    VAS["VAS Tunnel<br/>(HTTPS over VAS 3)"]
    DMS["Depot Management System<br/>(Backend)"]
    OCPP["OCPP Backend<br/>(Charge Point Management)"]

    EVCC -- ISO 15118 (PLC) --> SECC
    SECC -. presents .-> VAS
    VAS --> DMS
    SECC -- OCPP --> OCPP
    DMS -.Operational data.-> OCPP

    style EVCC fill:##cce5ff,stroke:##3366cc,color:##000
    style SECC fill:##cce5ff,stroke:##3366cc,color:##000
    style VAS fill:##ffe5cc,stroke:##cc6600,color:##000
    style DMS fill:##d5f5e3,stroke:##2e8b57,color:##000
    style OCPP fill:##f9e79f,stroke:##b7950b,color:##000

This section presents an exemplary system architecture, cf. Figure 2, for connecting an electric bus to a dispositive backend, here depot management system (DMS). The Electric Vehicle Communication Controller (EVCC) communicates with the Supply Equipment Communication Controller (SECC) via Power Line Communication (PLC) to charge the bus according to ISO 15118 [1].

As described in section 1.3 the use of the VAS "InternetAccess" is initiated and in this way direct communication between the vehicle and the backend is enabled via an IPv6 network.

The charging station acts as a gateway for an HTTP connection and does not interpret the communication content for its own purposes. This has the advantage that no adjustments have to be made to the charging station for backend communication. Any charging station can be used that can offer the corresponding VAS according to ISO 15118 and can be integrated into the IPv6 network of the DMS.

In addition, the charging station also communicates with the backend, e.g. via the OCPP. In this way, technical monitoring of the charging station can take place. In addition, control variables, such as the maximum charging power of the charging station, can be limited by the DMS.

Data, the so-called "application layer messages" according to ISO 15118 [1], which are exchanged between the vehicle and the charging station, e.g. the current state of charge of the traction batteries, can also be communicated to the DMS and therefore do not have to be integrated into the V2ICP.

How can VAS be used?

The basic prerequisite for using VAS is an already established encryption of the charging communication using Transport Layer Security (TLS) between the vehicle and the charging station.

Provided that the VAS to be used are known to the vehicle and the charging station, the VAS must be offered to the vehicle during service discovery in accordance with [1]. The VAS must then be requested by the vehicle. This is done within the charging communication via the message pairs "ServiceDiscoveryReq/-Res" and here the ServiceID 3 for the VAS used as well as the "ServiceDetailReq/-Res" with the ParameterSetID 4.

sequenceDiagram
    participant EV as EVCC (Vehicle)
    participant SECC as SECC (Charging Station)
    participant VAS as VAS Catalog
    EV->>SECC: ServiceDiscoveryReq<br/>Request VAS list
    SECC-->>EV: ServiceDiscoveryRes<br/>Includes ServiceID 3 (InternetAccess)
    EV->>SECC: ServiceDetailReq<br/>Request parameters for ServiceID 3
    SECC-->>EV: ServiceDetailRes<br/>ParameterSetID 4 (Internet access details)
    EV->>VAS: Activate VAS InternetAccess
    Note over EV,SECC: HTTPS/TLS session carries V2ICP traffic once VAS 3 is active

The VAS can then be used as long as there is an active charging session between the vehicle and the charging station.

Requirements for V2ICP

In order to be able to use the Vehicle to Infrastructure Communication Protocol, there are some standards and mechanisms that the vehicle, the charging station, and the backend must control.

These are listed in Table 2 as an overview.

Requirement	Vehicle	Charging station	Backend
ISO 15118 Communication [1], [2]	X	X
IPv6 Capability	X	X	X
Certificate handling	X	X	X
TLS	X	X
VAS-Internet-Port 443	X	X	X
HTTPS capability	X		X
OCPP 2.0.1 Use-Case A02/03*	X	X	Recommendation

The basic requirement for V2ICP communication is communication between the vehicle and the charging station according to ISO 15118-2,-3 [1], [2]. Based on this, secured communication (TLS) in accordance with ISO 15118 is then required in order to be able to offer and utilize Value Added Services (VAS).

Included in ISO-15118 communication is an IPv6 capability for the vehicle and the charging station, but this is also mandatory for the backend and in particular the network technology between the charging station and the backend.

Likewise, the vehicle, charging station, and backend must handle certificates according to ISO 15118. In addition, the vehicle and the backend must support the HTTP protocol in order to exchange data. In order to install suitable certificates for the TLS connection on the charging station and to update them later, an OCPP 2.0.1 or higher implementation is recommended in the charging station and the backend.

The IPv6 network configuration that is actually required and the network services that are included in this depend heavily on the selected operating environment and on the usage variants described/selected in the following sections, which are defined via parameters of the V2ICP coupling. The use of an IPv4 network configuration, however, is excluded.

Variants for Backend Accessibility or Address Resolution

The vehicle must be able to reach the backend via a predefined IP address or via a URL/FQDN. Depending on the selected variant, different network services are required, which are described below. The decision tree summarizes the variants and the necessary network services.

flowchart TD
    A[Backend accessibility requirement] --> B{How should the vehicle reach the backend?}
    B -->|Static IP known| V1[Variant 1<br/>Fixed IP addresses<br/>Prerequisite: Configure backend IP in each vehicle]
    B -->|URL or FQDN| V2[Variant 2<br/>Name-based addressing]
    V2 --> C{Single network?}
    C -->|Yes| D[Deploy DNS server<br/>Statically configure DNS address<br/>V2ICP-pre-3]
    C -->|No| E[Multiple networks<br/>Advertise DNS dynamically<br/>V2ICP-pre-4]
    E --> F{How to publish DNS address?}
    F -->|SLAAC + RDNSS| G[RFC 6106 Router Advertisement<br/>V2ICP-pre-5 limitation: legacy OS support]
    F -->|DHCPv6| H[DHCPv6 option for DNS<br/>Provides additional network parameters]
    G --> I[Project planning decides actual provider device]
    H --> I
    V1 --> I
    D --> I
    I[Document chosen network service in project planning]

Variant 1 - The vehicle should use a static IP address

If a network is used that uses clearly static IP addresses, no further network services are mandatory. Every communication participant, that is, every vehicle, must have the IP address of the backend permanently stored or know that address.

Variant 2 - The vehicle should use a URL/FQDN

If a configuration is necessary in which the backend is to be reached from the vehicle via a URL/FQDN, further network services are required depending on the configuration of the entire network.

The use of URL/FQDN generally requires a DNS server that provides the vehicle with the appropriate IP address for the URL.

a) Configuration of the network with a DNS server

The IP address of this DNS server can be stored statically in all vehicles.

b) Configuration in different networks

If communication is to take place in different networks, different DNS servers may exist. This requires a network service that makes public the DNS server that can be reached in the respective network or its IPv6 address.

Configuration of the network via RDNSS option

There are two ways for a host to get the IPv6 address of the DNS server. As part of Stateless Address Autoconfiguration (SLAAC), router advertisements include the RDNSS option for name server addresses. Alternatively, the name server address can be announced via DHCPv6.

Originally, DNS server addresses were distributed via an additional DHCPv6 server. It was not until RFC 6106 that the RDNSS option (Recursive DNS Server) was defined as part of SLAAC with router advertisements. With the RDNSS option, IPv6 autoconfiguration takes place together with the IPv6 addresses of one or more DNS servers. Further parameters of a network configuration will then require DHCPv6.

Both methods, SLAAC and DHCPv6, have the disadvantage that they do not work well on their own. This is because IPv6 is only insufficiently implemented in older operating systems.

Which network service is to be used concretely and which element in the network provides these services depends on the physical device structure and must be determined during project planning.

Vehicle to Infrastructure Communication Protocol (V2ICP)

The V2ICP must be used to exchange parameters between the vehicle and the infrastructure that are not part of the vehicle-to-grid (V2G) communication.

Parameter structure

In this section the necessary parameter structure is shown.

Vehicle parameters

The vehicle parameters listed in Table 3 are necessary to ensure a successful data exchange. In any case, it must be possible for the user to set the parameters for the vehicle, e.g. via the vehicle's diagnostic tool.

Table 3: Vehicle parameter

Parameter	Values	Description
Address type	Unsigned integer: -0 -1 -2	-V2ICP deactivated -Fixed IP-address -URL
V2ICPURL	String max. 150 Bytes	IP address or URL as free text. If a URL is used, it must start with a letter.
V2ICPPath	String max. 150 Bytes	String specifying which path below the URL should be used (can also be empty).
V2ICPPassword	String max. 150 Bytes	Password for the HTTP basic authentication. No entry will result in no basic authentication being performed.

• The entire URL string must be created in accordance with RFC3986: V2ICP URL: V2ICP Port/V2ICP Path
• The entire URL string may not exceed a length of 249 characters.
• The IPv6 server address must be enclosed in square brackets in accordance with RFC6874. Example: http://[::1]

Parameters for the backend

Table 4: Parameters Backend

Parameter	Values	Description
Address type	Unsigned integer: -1 -2	- Fixed IP-address - URL
V2ICP-URL	String	IP address or URL as free text
V2ICP-Path	String	String specifying which path below the URL should be used (can also be empty).
Preconditioning type	-0 -1	- Preconditioning request only, type of preconditioning is determined by the vehicle. - Type of preconditioning is determined by the vehicle.

The backend must be able to manage a username and password of the data type string for each vehicle.

The following applies here:

• Username – Vehicle Identification Number (VIN)
• Password - to be assigned individually.

hen assigning the password, the backend should take into account that the password has to contain at least:

• one upper-case letter
• one lowercase letter
• one number
• one special character out of: _-+##*!()?

and is at least 8 characters long and consists exclusively of visible ASCII characters.

flowchart LR
    subgraph Shared["Shared interface"]
        SH1["TLS certificates<br/>(installed via ISO 15118/OCPP)"]
    end
    subgraph Vehicle["Vehicle configuration"]
        VP1["Address type<br/>0=Off, 1=Fixed IP, 2=URL"]
        VP2["V2ICPURL / V2ICPPath<br/>(IPv6 literal or URL + resource path)"]
        VP3["V2ICPPassword<br/>HTTP basic auth secret"]
    end

    subgraph Backend["Backend configuration"]
        BP1["Address type<br/>Fixed IP or URL"]
        BP2["V2ICP-URL / V2ICP-Path<br/>Endpoint accepting POST"]
        BP3["Credential store<br/>VIN as username + policy-compliant password"]
        BP4["Preconditioning type policy"]
    end

    VP1 --> SH1
    VP2 --> BP2
    VP3 --> BP3
    BP1 --> SH1
    SH1 --> BP2
    BP4 --> VP2

    classDef vehicle fill:##cce5ff,stroke:##3366cc,color:##000;
    classDef backend fill:##d5f5e3,stroke:##2e8b57,color:##000;
    classDef shared fill:##ffe5cc,stroke:##cc6600,color:##000;
    class VP1,VP2,VP3 vehicle;
    class BP1,BP2,BP3,BP4 backend;
    class SH1 shared;

The communication protocol must use the following protocols:

• Ethernet (Powerline)
• IPv6
• TCP
• HTTP 1.1 in accordance with RFC2616
• HTTPS in accordance with RFC2818
• TLS 1.2 in accordance with RFC5246
• JSON in accordance with RFC4627

Background: The protocol only supports IPv6 communication, as this is also used within ISO 15118. For the V2ICP, the leaner JSON format is used instead of XML, since this leads to a reduction in data traffic and thus also in volume.

Communication

The vehicle must check the following conditions before exchanging data via V2ICP:

• The charging station has offered the Internet service as a Value Added Service, cf. Table 1.
• This service must be offered as a free service via HTTPS over port 443.
• V2ICP is activated by parameter.

HTTP

Any request from the vehicle must be done using the HTTP POST method.

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

    EVCC->>SECC: ISO 15118 session<br/>TLS negotiation + select VAS 3
    SECC-->>EVCC: HTTPS tunnel on port 443 established
    EVCC->>BE: POST seq=0<br/>VIN + basic auth credentials<br/>Full parameter set
    BE-->>EVCC: HTTP 200<br/>Full backend parameter set
    Note over EVCC,BE: Idle timeout 61 s at EVCC and backend
    loop Every 10 s while charging
        EVCC->>BE: POST seq=n<br/>Changed parameters<br/>Always include h2_stat & bat_stat
        BE-->>EVCC: HTTP 200 response
    end
    alt No response within 15 s
        EVCC->>BE: Resend request (max three attempts)
    else Connection idle >61 s
        EVCC-->>SECC: Close TCP/TLS channel
    end
    alt Charging session still active
        EVCC->>BE: Reconnect after 5, 15, 30 min
    end

Vehicle

The following header information must be included in each request:

• User-Agent: V2ICP-Client/1.0.0 for V2ICP in accordance with VDV recommendation 261, Ed. 1/2020
• User-Agent: V2ICP-Client/2.0.0 for V2ICP in accordance with VDV recommendation 261, Ed. 2/2023
• Content-Type: application/json; charset=US-ASCII

The EVCC must send all requests to the URL address as described in section 3.1.1.

VAS backend

For each request initiated by the vehicle, the backend must respond according to the HTTP POST method.

Authentication and authorization

Before communication can take place between the vehicle and the back end, the participants must first be authenticated and authorized.

Authentication and authorization - Vehicle

The vehicle must use the HTTP basic authentication method to identify itself to the backend. This authentication involves logging in using a username and password.

The EVCC must use the “VIN” (vehicle identification number) as the username and the password as described in section 3.1.1 for one-time authentication per communication session. If no password is stored (string length is 0), no basic authentication is required.

Authentication and authorization - Backend

The vehicle logs in to the backend using HTTP basic authentication. The operator must define the performance ability of its backend so that authorization for its amount of vehicles is enabled by means of user name and password.

After termination of the HTTP connection and a still active charging session, the vehicle shall attempt a resumption of V2ICP communication.

Address triggering using DNS

If the backend address is stored as a domain name in the EVCC, a DNS server is required. The DNS server resolves the domain name to the correct global IP address.

Address triggering using DNS – Vehicle

The EVCC must use the DNS server IP address distributed via DHCP or RDNSS option.

Address triggering using DNS – Backend

Within the backend, a resolution of the domain name into an IP address must take place.

Transport Layer Security (TLS)

To prevent eavesdropping or manipulation of the exchanged data, it is imperative to secure the communication between the vehicle and the backend. Analogous to the V2G communication between EVCC and SECC, Transport Layer Security (TLS) is used for this purpose.

Transport Layer Security (TLS) – Vehicle

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 encryption must be used for the TLS connection. During connection establishment, server authentication must be performed using a pre-installed V2ICP root certificate. If the authentication is not successful (e.g. expired certificate), the V2ICP connection must be terminated.

The V2ICP root certificate must be installable on the vehicle by means of a diagnostic tester by the operator. The validity of the certificate should therefore be sufficiently long so that no updates are necessary.

A V2ICP root certificate (X.509) must have the following attributes:

• Encryption analogous to V2ICP-15 and V2ICP-16
• Type: Final instance
• Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Key Agreement
• Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication
• Maximum length: 800 Bytes

Transport Layer Security (TLS) – Backend

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 encryption must be used for the TLS connection. The backend must have a V2ICP root certificate installed. During authentication, the backend must send the public key to the EVCC.

TCP connection

The connection is based on TCP/IP. In case of a timeout, the connection must be actively terminated.

TCP connection EVCC

The idle timeout for the TCP connection of the V2ICP communication must be set to 61 s. If no request or response is sent within this time interval, the TCP/IP connection is automatically terminated. After disconnection and with an active charging session, the vehicle shall attempt a resumption of V2ICP communication (5 min, 15 min, 30 min retry intervals).

TCP connection backend

The idle timeout for the TCP connection of the V2ICP communication must be set to 61 s.

IPv6

The V2ICP protocol must, as with V2G communication, use an IPv6 configuration, cf. ISO 15118, Ed. 1. The EVCC must support Stateless Address Autoconfiguration (SLAAC) in accordance with RFC 4862.

V2ICP protocol

This section describes the requirements and the mechanism of communication.

V2ICP request

Communication must always be initiated by the EVCC by means of a request. A correct response is expected for each request. If no response is received within 15 s, the EVCC must resend the same request. After three failed attempts, the TCP connection must be terminated.

V2ICP request - Vehicle

The EVCC must send a new request every 10 s when a valid response is received. Each request must contain seq, vin, evccid, and parameter list in a JSON object. Sequence numbers start at 0 and roll over after 255.

The vehicle must always send all available parameters when seq=0. For subsequent messages, only modified parameters are sent, except for h2_stat and bat_stat which must always be included.

V2ICP request – Backend

The backend should verify the transmitted VIN and ignore unknown parameters.

V2ICP response – Vehicle

The vehicle accepts responses only if HTTP code = 200, and if seq and vin match. Unknown elements are ignored. Payload must not exceed 512 bytes.

V2ICP response – Backend

The backend must send HTTP code 200 for valid data. Responses must not be empty and must include at least seq and vin. If seq=0, all parameters must be included. Empty parameters should include SNA values. Payloads should avoid unused spaces.

Parameters to be sent from the vehicle to the backend

Signal	Parameter	Type	Unit	Resolution	Range of values (phys)	SNA	Background
Vehicle identification number (VIN)	vin	string	—	—	—	—	—
MAC address	evccid	string	—	—	—	—	—
Mileage	odo	signed integer	km	1 km/bit	0 .. 21055406	-1	—
Required duration for preconditioning of the HV battery	bat_reqtime	unsigned integer	min	1 min/bit	0 .. 250	-1	Time required for tempering the HV battery for a charging process in relation to the available charging power. A preconditioning duration > 250 min isn’t considered relevant because preconditioning itself doesn’t take longer and longer-term predictions (e.g., changing outside temperature) aren’t useful.
Energy required for charging	bat_eamount	signed integer	kWh	1 kWh/bit	0 .. 1000	-1	Energy required to charge the HV battery; if necessary, includes additional energy for tempering the HV battery.
Energy required to precondition the vehicle	prec_eamount	signed integer	kWh	1 kWh/bit	0 .. 1000	-1	Energy requirements of all HV systems for preconditioning the vehicle.
Required duration for preconditioning the vehicle	prec_reqtime	signed integer	min	1 min/bit	0 .. 250	-1	Maximum time to precondition the vehicle considering all relevant HV systems.
Vehicle charging status	chrg_stat	signed integer	—	—	Enum (0..4)	-1	Enum values: 0 = Ready to charge — Vehicle can draw power. 1 = Charging active — Active charging session; drawing power. 2 = Charging not available — Vehicle currently unable to absorb power (malfunction). 3 = Charging and preconditioning — Active charging and consuming power; preconditioning in parallel as requested via prec_dsrd and prec_hvac. 4 = Preconditioning — No charging power drawn; only preconditioning takes place.
Hydrogen leak detection	h2_stat	signed integer	—	—	Enum (0..1)	-1	Enum values: 0 = Hydrogen system is okay 1 = Hydrogen system is not okay Provides leak information for the hydrogen line to enable a depot management warning/prevention system.
Battery status	bat_stat	signed integer	—	—	Enum (0..1)	-1	Enum values: 0 = Status of battery is okay 1 = Critical battery status Indicates possible HV-battery abnormality that could pose a fire risk; supports depot battery-fire warning/prevention systems.

Parameters to be sent from the backend to the vehicle

Signal	Parameter (ID)	Type	Unit	Resolution	Range / Enum (phys)	SNA (raw)	Background
Scheduled departure time	driveoff	signed integer	min	5 min/bit	0 … 1440	-1	Vehicle must be ready to depart within the next 24 hours; preconditioning should be completed. If the available time is too short, the vehicle should meet the specs as best as possible. Sent as a countdown, e.g., “depart in 10 minutes,” not as a wall‑clock time.
Pre‑conditioning request — depot management system	prec_dsrd	signed integer	—	Enum	0 = “no” 1 = “yes”	-1	Backend can set a general preconditioning request; the contents of this preconditioning are manufacturer‑specific.
Pre‑conditioning request — HVAC	prec_hvac	signed integer	—	Enum	0 = “only hot water and ventilation” 1 = “hot water and heating” 2 = “no hot water, cooling or ventilation” 3 = “no climate preconditioning or automatic preselection by the vehicle”	-1	Backend can select specific interior A/C preconditioning; the vehicle should be prepared accordingly at departure. Note: May be ignored if the vehicle has automatic A/C mode; in that case the backend should send value “3”.
Ambient temperature outside of the garage	ambienttemp	signed integer	°C	1 °C/bit	-50 … 70	-51	Can be sent when the vehicle is stored indoors to enable preconditioning relative to the expected outdoor temperature at departure (forecast).
Target distance	target_dist	signed integer	km	1 km/bit	0 … 1000	-1	Used to determine operating strategy before service. Example: a battery bus with a fuel‑cell range extender might keep the fuel cell off for short trips but enable it from the start for longer trips.
Target SOC (state of charge)	target_soc	signed integer	%	1 %/bit	0 … 100	-1	Relevant when only a fraction of battery energy is needed; for some chemistries this helps conserve the battery long‑term.

Legend: SNA (raw) = special raw value indicating “signal not available / not applicable.”

Example of the structure of the requests and responses

Example request (seq=0) and response (seq=0) shown in JSON format, followed by a reduced example with seq=1.

Initial Request/Response (seq=0)

The initial request starts with seq = 0 and must transmit the full set of parameters:

{
  "seq": 0,
  "vin": "AABBCCDDFFGGHHIIJ",
  "evccid": "000102030405",
  "odo": 5000,
  "bat_eamount": 20,
  "bat_reqtime": 40,
  "prec_eamount": 10,
  "prec_reqtime": 100,
  "chrg_stat": 1
}

The initial response uses the same seq and must also transmit the full set of parameters:

{
  "seq": 0,
  "vin": "AABBCCDDFFGGHHIIJ",
  "driveoff": 12,
  "prec_dsrd": 0,
  "prec_hvac": 3,
  "ambienttemp": 0
}

Subsequent Delta Updates (seq=1+)

The next request has a reduced scope, as all parameters that have not been changed can be omitted:

Delta Request:

{
  "seq": 1,
  "vin": "AABBCCDDFFGGHHIIJ",
  "evccid": "000102030405",
  "bat_reqtime": 39
}

Delta Response:

{
  "seq": 1,
  "vin": "AABBCCDDFFGGHHIIJ",
  "prec_dsrd": 1
}

Error memory entries - diagnostic trouble codes (DTC) Vehicle

Incorrect parameter configuration

The EVCC shall create a diagnostic trouble code (DTC) if one of the following conditions is met:

• Invalid characters or length in one of the V2ICP-URL or V2ICP-password parameters
• IP address cannot be read from the V2ICP-URL parameter
• HTTP communication cannot be established

V2ICP-57: The error should be reset as soon as the above-mentioned conditions are no longer met.

V2ICP-77: The V2ICP communication is to be discontinued. The EVCC is to remain in this status until the next time the charging connection is established and then start another charging process.

Communication error detected

The EVCC shall create a fault memory entry (DTC) if any of the following conditions are met:

• Response length exceeds 512 bytes - The length of the received response exceeds 512 bytes
• HTTP status code ≠ 200 - The received HTTP response code is not equal to 200
• Invalid JSON string - A non-valid JSON string was received
• Backend timeout - The backend does not respond within 3 attempts
• Certificate issues - Certificate is invalid, expired or cannot be read

V2ICP-58: The error should be reset as soon as the above-mentioned conditions are no longer met.

If the backend does not respond within 3 attempts, V2ICP communication is to be terminated. The EVCC is to remain in this status until the next time the charging connection is established and then start another charging process.

graph TD
    DTC[EVCC DTC Trigger] --> ConfigError[Incorrect parameter configuration]
    ConfigError --> InvalidChars[Parameter contains invalid characters or exceeds length]
    ConfigError --> IpUnreadable[IPv6 address cannot be read]
    ConfigError --> HttpUnavailable[HTTP client cannot be initialised]

    DTC --> CommError[V2ICP communication error]
    CommError --> Resp512[Backend response > 512 bytes]
    CommError --> HttpStatus[HTTP status ≠ 200]
    CommError --> JsonInvalid[JSON parsing failed]
    CommError --> Timeout[No response after 3 retries]
    CommError --> CertIssue[TLS certificate invalid/expired]

    Timeout --> Reconnect[V2ICP session halted until next charging cycle]
    CertIssue --> Reconnect
    HttpUnavailable --> Reconnect

    classDef config fill:##ffe5cc,stroke:##cc6600,color:##000;
    classDef comm fill:##cce5ff,stroke:##3366cc,color:##000;
    class ConfigError,InvalidChars,IpUnreadable,HttpUnavailable config;
    class CommError,Resp512,HttpStatus,JsonInvalid,Timeout,CertIssue,Reconnect comm;

Conformance Testing

As all three components are normally developed by different manufacturers or suppliers, it should be ensured as far as possible that the interoperability of EVCC, SECC, and backend is guaranteed in the sense of the V2ICP specification by means of specified conformance tests.

Here, the correct implementation of all testable requirements from this specification is checked by corresponding test cases. The tests are defined in the form of Black-Box. In Black-Box tests, the system under test (SUT) is addressed or observed exclusively via the specified system interface. Beyond that, there is no further interface to the system that would provide, e.g., internal system states or likewise.

This figure shows the three different test architectures for conformance testing of the vehicle (EVCC), V2ICP backend, and charging point (SECC) in accordance with the V2ICP specification.

flowchart LR
    subgraph Config1["Config 1 – VAS-EVCC (Vehicle under test)"]
        TC1["Test Controller"]
        SECC1["SECC Emulator"]
        EVCC1["EVCC (SUT)"]
        BackendStub1["Backend Stub"]
        TC1 --> SECC1
        SECC1 --> EVCC1
        EVCC1 --> BackendStub1
        TC1 -. monitor .-> BackendStub1
    end

flowchart LR
    subgraph Config2["Config 2 – Backend under test"]
        TC2["Test Controller"]
        EVSim2["EVCC Emulator"]
        SECC2["SECC Emulator"]
        Backend2["Backend (SUT)"]
        TC2 --> SECC2
        EVSim2 --> SECC2
        EVSim2 --> Backend2
        TC2 -. collect logs .-> Backend2
    end

flowchart LR
    subgraph Config3["Config 3 – SECC under test"]
        TC3["Test Controller"]
        EVSim3["EVCC Emulator"]
        SECC3["SECC (SUT)"]
        BackendStub3["Backend Stub"]
        TC3 --> SECC3
        EVSim3 --> SECC3
        SECC3 --> BackendStub3
        TC3 -. supervision .-> BackendStub3
    end

Test case description

Case descriptions are defined in the form as shown in Table 7.

Table 7: Test case description template

Field	Description
TC Id	The TC Id is a unique identifier for a test case.
Testing objective	Description of the testing objective in terms of a requirement from the protocol specification.
Referenced requirement (en)	The referenced requirement(s) that will be checked as part of the test case. Reference according to the naming convention for requirements in this document.
Config Id	The configuration ID is a unique identifier for the underlying configuration used to execute the test case.
PICS	Selection of PICS necessary for the execution of the test case. Definition PICS → Configuration information at the test system's side.
PIXIT	Selection of PIXIT necessary to execute the test case. Definition PIXIT → Configuration information at the test system's side.
Precondition	The precondition describes the state in which the system under test and the test system must be before the actual test behavior is executed to verify the testing objective. If the precondition is not fulfilled, this leads to an inconclusive test verdict.
Test behavior	Definition of the response of a system under test to stimuli of the test system defined in the context of the test behavior.

Test case example

flowchart TD
    Start([Start test case])
    ISOCase[Run ISO 15118 well case<br/>EVCC↔SECC negotiation]
    TLS[Establish TLS tunnel via VAS 3]
    Preconditions{Preconditions satisfied?}
    RequestSeq0[Send V2ICP POST<br/>seq = 0, mandatory fields]
    ResponseCheck[Backend returns HTTP 200?<br/>Payload includes all parameters?]
    VerdictPass([Pass])
    VerdictFail([Fail / Inconclusive])

    Start --> ISOCase --> TLS --> Preconditions
    Preconditions -->|No| VerdictFail
    Preconditions -->|Yes| RequestSeq0 --> ResponseCheck
    ResponseCheck -->|Yes| VerdictPass
    ResponseCheck -->|No| VerdictFail

TC Id: TC_BE_VTB_V2ICP_XXX Testing objective: The test system executes an ISO 15118 well case, establishes a V2ICP connection to the backend, and sends a valid V2ICP request with all mandatory fields to the backend. The sequence number (seq) element is set equal to 0. The test system then checks whether the backend returns a V2ICP response with all parameters according to table X. Referenced requirement(s): V2ICP-98 Config Id: Config 1 PICS: TBD PIXIT: TBD Precondition: The test system runs an ISO-15118 well case and establishes a TLS connection to the backend based on the VAS negotiation. Testing behavior: The test system sends a valid V2ICP request with all mandatory fields to the backend. The element for the sequence number (seq) is set equal to 0. The test system then checks whether the backend returns a V2ICP response with all parameters as shown in Table 6.