-
Notifications
You must be signed in to change notification settings - Fork 170
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
Conversation
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
3553cec
to
2ec862f
Compare
MoM:
|
Signed-off-by: Erik Jaegervall <[email protected]>
2ec862f
to
6b0371f
Compare
Removed some comments not intended for merging from PR |
MoM : Merge |
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.