Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add battery precondition signals #703

Merged
merged 1 commit into from
Feb 13, 2024
Merged

Conversation

erikbosch
Copy link
Collaborator

Electrical vehicles may have a system that prepares the traction battery for driving or charging by making sure that the battery has an optimal temperature for driving or charging. This PR proposes a set of signals for this purpose. The idea is that the signals should be quite generic and fit various type of implementations of a battery precondition system.

@erikbosch erikbosch marked this pull request as ready for review January 4, 2024 14:41
@ppb2020
Copy link
Collaborator

ppb2020 commented Jan 9, 2024

Looks like a good start.

Regarding times, shall we require they be in UTC and ISO 8601 format?

I haven't worked through use cases, but the definitions should take into account what happens when "plans change". That is, the battery was being conditioned for a specific time and the vehicle is no longer parked or plugged in, etc. Indeed, the logic will be implemented in the vehicle, but we may need to have signals that represent the state or cause for interruption of the conditioning.

type: actuator
datatype: uint64
description: Start time for battery conditioning, if Mode is not INACTIVE.
unit: unix-time
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Pierre Pierre brought up the topic of time representation.

We now have two time units; unix-time (to be used with uint32/uint64/int64) and iso8601 (to be used with string). Historically we have favored iso8601 over unix time, but we do not have a deliberate decision. Technically we could use iso8601 here as well, so what do we prefer?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we had several discussion wrt ti time #667 , #525 and favoring iso is a more "recent" historical decisions.

I think personally some of you guys convinced me to prefer iso instead of unix timestamps in the past :D In any case it is what we are recommending in the documentation: https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/data_types/#timestamps and I would agree in terms of VSS data model (an implementation can still use faster/more primitive timestamps for internal representation)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Meeting notes:

  • Pierre Pierre - if using ISO string advantage is that time zone is explicit.
  • AP: Erik change to iso time

@erikbosch
Copy link
Collaborator Author

MoM:

  • Some parts to be removed from PR, like "START OF PART NOT TO BE MERGED"
  • AP: Erik to update
  • Will be merged next week unless comments/remarks at next meeting

Signed-off-by: Erik Jaegervall <[email protected]>
@erikbosch
Copy link
Collaborator Author

Removed some comments not intended for merging from PR

@erikbosch erikbosch added the Status:Meeting Intended to be discussed at next VSS-project meeting label Feb 13, 2024
@erikbosch
Copy link
Collaborator Author

MoM : Merge

@erikbosch erikbosch merged commit f28c3e7 into COVESA:master Feb 13, 2024
4 checks passed
@erikbosch erikbosch deleted the erik_precond branch February 13, 2024 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status:Meeting Intended to be discussed at next VSS-project meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants