Skip to content

Conversation

@FaHaGit
Copy link
Contributor

@FaHaGit FaHaGit commented Feb 2, 2026

Describe your changes

There are EV implementations that can configure request messages within a few milliseconds, which can currently trigger a flood of internal communication. To avoid performance issues, we should therefore wait a certain amount of time after receiving a request message before sending the next response message. The delay of maximum 100 ms should not cause any problems, as the most critical time of the ISO 15118-20 (V2G_SECC_Msg_Performance_Time of the charging loop) is 250 ms.

Already successfully tested in the SIL environment (with a higher delay, because the josev lib based implementation needs ~500ms to configure a request message).

Changes:

  • introduce MIN_RESPONSE_INTERVAL_MS to manage time between responses
  • add last_response_tx_time to track last response timestamp
  • implement delay to ensure minimum interval between response messages

Issue ticket number and link

Checklist before requesting a review

  • [X ] I have performed a self-review of my code
  • I have made corresponding changes to the documentation
  • [X ] I read the contribution documentation and made sure that my changes meet its requirements

There are EV implementations that can configure request messages within a few milliseconds, which can currently trigger a flood of internal communication. To avoid performance issues, we should therefore wait a certain amount of time after receiving a request message before sending the next response message. The delay of maximum 100 ms should not cause any problems, as the most critical time of the ISO 15118-20 (V2G_SECC_Msg_Performance_Time of the charging loop) is 250 ms.

Changes:
- introduce MIN_RESPONSE_INTERVAL_MS to manage time between responses
- add last_response_tx_time to track last response timestamp
- implement delay to ensure minimum interval between response messages

Signed-off-by: Fabian Hartung <[email protected]>
@FaHaGit FaHaGit force-pushed the feature/libiso_add_response_msg_interval_control branch from 3d894d5 to a010967 Compare February 2, 2026 14:28
@SebaLukas SebaLukas self-assigned this Feb 2, 2026
Copy link
Member

@SebaLukas SebaLukas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I like the PR. Wait for some time before sending the response is a good idea.

My problem with this implementation is that it blocks the whole process for 100ms.
That could be really a problem in some cases.

I need to think how to fix this problem not blocking the whole process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants