Meeting 05/23

• Not sure what all the location means
• Something like "FRONT_MIDDLE" seems to be missing
• How many positions
• One proposal FRONT_MIDDLE, FRONT_LEFT, LEFT_MIDDLE, REAR_LEFT, ... (anti-clockwise)

This is the values defined in https://android.googlesource.com/platform/hardware/interfaces/+/master/automotive/vehicle/2.0/types.hal#3537.

enum PortLocationType : int32_t {
    /**
     * Default type if the vehicle does not know or report the Fuel door
     * and ev port location.
     */
    UNKNOWN = 0,
    FRONT_LEFT = 1,
    FRONT_RIGHT = 2,
    REAR_RIGHT = 3,
    REAR_LEFT = 4,
    FRONT = 5,
    REAR = 6,
};

No further definitions, but a possible interpretation is:

enum PortLocationType : int32_t {
    /**
     * Default type if the vehicle does not know or report the Fuel door
     * and ev port location.
     */
    UNKNOWN = 0,
    FRONT_LEFT = 1, // On left side of vehicle, in front of driver position
    FRONT_RIGHT = 2, // On right side of vehicle, in front of driver position
    REAR_RIGHT = 3, // On right side of vehicle, behind last row of seats
    REAR_LEFT = 4, // On left side of vehicle, behind of last row seats
    FRONT = 5, // On vehicle front (Example for EV: Kia Niro)
    REAR = 6, // On vehicle rear (Example for combustion engine: DAF 66)
};

So FRONT could possibly be described as FRONT_MIDDLE

In COVESA VSS we (since before) also have a "middle alternative". Which maybe could be useful for mini-buses, where you maybe have the fuel-port/charge-port behind driver seat, but in front of last passenger row.

I think the first question we must agree on is how many alternatives we need for each side. Do we need 2 or 3 alternatives for left and right? (front+rear(+middle)). For front and rear - is one alternative sufficient?

I tried a picture for a "consistent" way of all possible locations to help me.

Pattern is: Side first, then position on that side. The ones in brackets I have never seen, but may be useful for consistency purposes

Might be argued whether FRONT_RIGHT RIGHT_FRONTshould really be differentiated. I think they should, as the latter implies "somewhere" on the fender, that could be quite a bit further back than the "Front" options.

Another related questions: Should we support multiple charge ports like this BYD https://carnewschina.com/2023/03/14/byd-denza-doubles-up-on-charging-power/

The signals could easily be of string[] format to allow an arbitrary number of locations. Could be useful theoretically also for combustion engines, like old Jaguars with fuel ports on both sides.

"Left field" idea. Has it been considered to use an instance for the location? That is, not defining a separate signal but instead adding instances to Fuel Port and Charge Port.

This would support multiple ports in one vehicle, with the instance defining the location (similar to rows and positions for seats).

@ppb2020 like the idea, as for example the ports may have different capabilities (i.e. the text in the BYD example seems to hint at AC only being available on one side).
I also think that there are use cases (i.e the Android cased mentioned in the intial post) where you really just want to know the position, and doing that by querying "possibly existing" Chargeport instances (where VSS has no real way of defining which instance names might be concerned valid) seems suboptimal. So I feel, that solution would still need a (list of) chargeport position(s) that would tell you where they are/what instances exist.

We have in Charging.ChargePlugType the possibility to mention multiple plug types, but all of our other signals like Charging.ChargePortFlap seems to be based on an assumption that there is only on flap, or at least that you can only connect one charger at a time, and it isn't that important knowing which plug or connector that is used.

Having an instance-branch with possibly 9 positions as in the picture from Sebastian would work, and then for each of them showing which connectors that exists there (one or many), possibly something like below. But then the question is - shall we also include separate signals for example for Charging.ChargePortFlap for each instance, and if so also keep the "global" Charging.ChargePortFlap signal? I.e. so you can have one signal that indicates "True" if any flap is open, and then individual signals to find out exactly which flaps that are open.

Charging.ChargePorts:
  type: branch
  instances: ['FRONT_LEFT', 'FRONT_MIDDLE', ...]

Charging.ChargePorts.ChargePlugType:
  datatype: string[]
  type: attribute
  allowed: [
    'IEC_TYPE_1_AC',
    'IEC_TYPE_2_AC',
    'IEC_TYPE_3_AC',
    'IEC_TYPE_4_DC',
    'IEC_TYPE_1_CCS_DC',
    'IEC_TYPE_2_CCS_DC',
    'TESLA_ROADSTER',
    'TESLA_HPWC',
    'TESLA_SUPERCHARGER',
    'GBT_AC',
    'GBT_DC',
    'OTHER'
    ]

An alternative solution that we have used now and then instead of instances is to use two signals with arrays, and say that the relative positions matter. Like if we keep Charging.ChargePlugType as is and introduce a new signal which states position for each plug type included in the other signal.

Refactored PR based on comment. For now using two arrays with "soft" dependency by relative indexing. But having instances would work as well - as long as we design it so it cover the case where one location might have multiple plugs/ports. Using struct would be a different alternative but require even more discussion.

Please review

Could we take this opportunity to harmonise and correct our terminology? Specifically, the term "plug" is currently used here, however, a plug is part of a cable that connects to a port. EVs therefore have ports not plugs (unless anyone knows of an EV that has a cable permanently attached?). We should also use this term when talking about refuelling position too, just to be consistent.

Therefore, I propose the following changes for consistency and correctness:

1. Change RefuelPosition to RefuelPortPosition
2. Change ChargePlugPosition to ChargePortPosition
3. Change IsFuelDoorOpen to IsFuelPortFlapOpen (aligns with ChargePortFlap)

In the next major version of VSS, we may also want to rename "ChargePlugType" to "ChargePortType", but not in 4.1 as that would be a backwards incompatible change. Or can we flag it here in 4.1 that we intend to rename it in 5.0 e.g. in the Deprecated field?

Could we take this opportunity to harmonise and correct our terminology? Specifically, the term "plug" is currently used here, however, a plug is part of a cable that connects to a port. EVs therefore have ports not plugs (unless anyone knows of an EV that has a cable permanently attached?).
...
In the next major version of VSS, we may also want to rename "ChargePlugType" to "ChargePortType", but not in 4.1 as that would be a backwards incompatible change. Or can we flag it here in 4.1 that we intend to rename it in 5.0 e.g. in the Deprecated field?

I have no objection referring to port rather than plug. Did you had time to discuss it on the meeting yesterday or it something that we better shall discuss next week? Concerning name changes - for existing signals, if we assume that next release will be VSS 4.1 the historical approach is to copy the old signal and change name on the copy. Then for now keep the old signal but add "deprecation: V4.1 renamed to Vehicle.XXX.YYY". that way both will exist in VSS 4.1 (and VSS 4.2 if it will exist), but the old name will be removed in VSS 5.0

Meeting notes:

• Erik to update to port instead of plug (considering the deprecation/compatibility topic)
• When updated please review, so it possibly can be merged next week

Please can we rename the new instance of RefuelPosition to RefuelPortPosition? This not only provides consistency within VSS (i.e. with ChargePortPosition) but also better separates the new definition from the old (which will be deprecated at the next major release).

I also proposed renaming IsFuelDoorOpen to IsFuelPortFlapOpen, in order to align with ChargePortFlap. Can this be included in this PR, or should it be in a separate PR?

Please can we rename the new instance of RefuelPosition to RefuelPortPosition? This not only provides consistency within VSS (i.e. with ChargePortPosition) but also better separates the new definition from the old (which will be deprecated at the next major release).

I also proposed renaming IsFuelDoorOpen to IsFuelPortFlapOpen, in order to align with ChargePortFlap. Can this be included in this PR, or should it be in a separate PR?

I think it better could ve done in this one. I will update the PR

Thanks, the changes look good to me now.

In order to spice it up a bit. What if we have inductive charging. :) https://t.ly/A6nZ

Looks good to me.

I would be happy for a PR addressing inductive charging. But I know too little about it to be able to provide something useful. I do not even know if you (as owner) need to know where the inductive charging point is on your vehicle so that you can park the car as needed for charging to start

Meeting notes:

• Update signal
• Then it can be merged after sanity check

Please do a sanity check after update @nickrbb @adobekan

Please do a sanity check after update @nickrbb @adobekan

In the case when port is not there (Hybrids) do we need as well NOT_AVAILABLE status or you would expect that this scenario is handled inside deployment specification?

@erikbosch Looks good to me now, thanks for your hard work making everything align.
@adobekan I think the same could be said for all of our boolean signals, in which case, such handling would need to be done as part of deployment i.e. a signal discovery procedure, which could be as something as simple as attempting to read its status and getting back a certain error e.g. HTTP 501 (Not implemented).

@erikbosch Looks good to me now, thanks for your hard work making everything align. @adobekan I think the same could be said for all of our boolean signals, in which case, such handling would need to be done as part of deployment i.e. a signal discovery procedure, which could be as something as simple as attempting to read its status and getting back a certain error e.g. HTTP 501 (Not implemented).

Sounds good to me.