Vehicle Networks & Communication
A practical engineering model for building and validating vehicle-to-grid communication for EV charging, from requirements and interface definitions to captured traffic and repeatable tests.
Engineering model
ISO 15118 governs communication between an EV and a charging system during an EV charging interaction. Development depends on translating requirements into message and state behavior, connecting that behavior to the Battery Management System (BMS), and validating actual exchanges with PCAP evidence. The communication implementation must be treated as a stateful interface rather than a collection of independent messages.
Core concepts
The implementation must move through the expected charging interaction states in the correct order, preserve relevant context, and handle incomplete or unexpected exchanges without treating each message as an isolated event.
The interface specification defines the messages, fields, directions, and conditions that connect the vehicle and charging system; development turns those definitions into encoders, decoders, validation, and state transitions.
The ISO 15118 communication behavior must reflect the battery conditions and limits made available by the BMS, while keeping communication decisions separate from battery monitoring and control responsibilities.
PCAP data, requirements, and repeatable test results provide different views of the same implementation: intended behavior, observed behavior, and verified behavior.
Start by defining the boundary between the communication implementation, the charging system, and the BMS. This prevents protocol behavior from being mixed with battery-control logic.
Treat ISO 15118 as a stateful interface. Requirements describe what the interaction must accomplish, the interface specification describes how information is exchanged, and the implementation maintains the current state of the interaction. A useful design separates message parsing, message construction, state transitions, requirement checks, and BMS data access so that each can be tested independently.
| Engineering input | Primary question | Implementation use |
|---|---|---|
| Requirements | What behavior is required under each operating condition? | Define expected states, decisions, limits, and test assertions. |
| Interface specification | What information is exchanged, in which direction, and under what condition? | Define message models, validation, sequencing, and interface adapters. |
| PCAP | What traffic was actually observed? | Compare observed exchanges with expected ordering, values, and timing evidence. |
Most integration failures appear at state boundaries: an implementation accepts a message too early, loses context between exchanges, or reports success before the underlying condition is satisfied.
Derive the meaningful phases from the requirements and interface specification. Give each phase explicit entry conditions, expected messages, allowed transitions, and completion criteria.
Decode incoming information into a validated internal representation before applying state or charging decisions. This makes malformed or incomplete input observable.
For every expected exchange, specify what happens when data is missing, inconsistent, out of sequence, or no longer supported by the BMS.
Record the state, relevant message information, and decision result so an engineering analysis can connect a failure to the exchange that caused it.
The BMS is a source of battery status and operating constraints, while ISO 15118 carries communication behavior between the vehicle and charging system. The integration boundary needs clear ownership.
Define an interface from the communication implementation to the BMS that identifies which values can be read, which requests can be accepted, and how unavailable or stale data is represented. The communication layer should not silently invent battery values when the BMS has not provided valid data. Conversely, BMS behavior should not depend on undocumented assumptions about message order.
| Boundary concern | Communication implementation owns | BMS integration must provide |
|---|---|---|
| Validity | Reject or classify unusable communication data | Indicate whether battery information is current and usable |
| Limits | Communicate only values accepted by the interaction rules | Provide applicable battery and charging limits |
| Availability | Represent unavailable vehicle information in the interaction state | Expose defined availability and fault conditions |
| Traceability | Record which BMS data influenced a decision | Provide identifiable data sources for analysis |
An ECU simulator and an automated test suite allow the interaction model to be exercised before every physical dependency is available or stable.
Use the ECU simulator to reproduce defined interface behavior, including normal sequences and deliberately incomplete or inconsistent exchanges. The simulator should expose controllable inputs and produce observable outputs so a test can distinguish a parser issue, a state-machine issue, and an integration issue.
For each requirement, define setup conditions, the exchange sequence, expected state changes, and the result that constitutes a pass.
Include missing data, invalid values, unexpected ordering, repeated exchanges, and BMS information that is unavailable or no longer valid.
Check state transitions and validation decisions, not only the final charging result. Intermediate assertions narrow the location of a failure.
Where suitable, use PCAP observations to refine scenario inputs and compare simulator output with known interaction behavior.
Troubleshooting is strongest when packet evidence, implementation state, and requirements are reviewed together instead of treating the first unusual message as the root cause.
Use the PCAP to order the exchanges and identify where the interaction first differs from the expected behavior.
Determine which state the implementation believed it was in and whether that state permitted the observed exchange.
Compare the relevant communication data with the BMS information and integration assumptions available at the same point.
Record whether the evidence indicates an implementation defect, an interface interpretation issue, missing input, or an environment-dependent observation.
Turn the observed sequence into an automated test or ECU simulator scenario before changing implementation behavior.
A useful engineering analysis links each finding to evidence: the relevant PCAP exchange, the applicable requirement or interface specification entry, the implementation state, and the test that reproduces or challenges the finding. This makes the conclusion reviewable without assuming that the first visible symptom is the cause.
The communication implementation is part of a larger vehicle network and must be evaluated at its actual integration boundaries, including any network gateway and Automotive Ethernet path used by the surrounding system.
Document where ISO 15118 data enters and leaves the vehicle-side implementation, which component owns translation or forwarding, and how the BMS interface is reached. A network gateway can change visibility and timing of traffic, so troubleshooting should distinguish an issue in the communication state machine from an issue at the network boundary.
Engineering pitfalls
Handling messages independently can accept an exchange in the wrong phase or lose information needed by a later decision. Model explicit states and permitted transitions.
Observed traffic is evidence of one interaction, not proof of all required behavior. Compare PCAP data with requirements and the interface specification.
This makes battery validity, communication validity, and state transitions difficult to test separately. Keep the BMS boundary explicit and validate its data before using it.
Normal exchanges do not expose behavior for unavailable data, unexpected ordering, or invalid values. Add negative and boundary scenarios to the automated test suite.
A visible symptom may originate at the network boundary, interface mapping, state model, or BMS integration. Preserve evidence and reproduce the condition before selecting a correction.
Automotive Ethernet may be part of the surrounding vehicle network, but it does not replace the ISO 15118 state and interface model. Document the actual integration boundary.
FAQ
Engineering support
Need focused ISO 15118 development, testing, simulation, or troubleshooting support? Define the evidence and integration boundaries for the next engineering step.