search

COVESA / vehicle_signal_specification

Vehicle Signal Specification - standardized way to describe automotive data
Mozilla Public License 2.0
316 stars 163 forks source link

Allow instantiation of charging ports #753

Open jdacoello opened 1 month ago

jdacoello commented 1 month ago

Right now, the charging port is modelled assuming the car has a unique port. However, there might be cases where multiple ports exist. Hence, the following suggestion is made:

Current

Some properties of the port are modelled under the Charging branch. 

Charging:
  type: branch
  description: Properties related to battery charging.
...
Charging.ChargePlugType:
  deprecation: V4.1 renamed to Charging.ChargePortType
  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'
    ]
  description: Type of charge plugs (charging inlet) available on the vehicle.
               A charge plug type may occur multiple times in the list if there are multiple instances of that charge
               plug type.
               IEC types refer to IEC 62196,  GBT refers to  GB/T 20234.
  comment:     A vehicle may have multiple charging inlets.
               The signal Charging.ChargePlugPosition can be used to indicate position of the charge plug.
               IEC_TYPE_1_AC refers to Type 1 as defined in IEC 62196-2. Also known as Yazaki or J1772 connector.
               IEC_TYPE_2_AC refers to Type 2 as defined in IEC 62196-2. Also known as Mennekes connector.
               IEC_TYPE_3_AC refers to Type 3 as defined in IEC 62196-2. Also known as Scame connector.
               IEC_TYPE_4_DC refers to AA configuration as defined in IEC 62196-3. Also known as Type 4 or CHAdeMO connector.
               IEC_TYPE_1_CCS_DC refers to EE Configuration as defined in IEC 62196-3. Also known as CCS1 or Combo1 connector.
               IEC_TYPE_2_CCS_DC refers to FF Configuration as defined in IEC 62196-3. Also known as CCS2 or Combo2 connector.
               TESLA_ROADSTER, TESLA_HPWC (High Power Wall Connector) and TESLA_SUPERCHARGER refer to non-standardized charging
               inlets/methods used by Tesla.
               GBT_AC refers to connector specified in GB/T 20234.2.
               GBT_DC refers to connector specified in GB/T 20234.3. Also specified as BB Configuration in IEC 62196-3.
               OTHER shall be used if the vehicle has a charging connector, but not one of the connectors listed above.
               For additional information see https://en.wikipedia.org/wiki/IEC_62196.

Charging.ChargePortType:
  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'
    ]
  description: Type of charge ports (charging inlet) available on the vehicle.
               A charge port type may occur multiple times in the list if there are multiple instances of that charge
               port type.
               IEC types refer to IEC 62196,  GBT refers to  GB/T 20234.
  comment:     A vehicle may have multiple charging ports.
               The signal Charging.ChargePortPosition can be used to indicate position of the charge port.
               IEC_TYPE_1_AC refers to Type 1 as defined in IEC 62196-2. Also known as Yazaki or J1772 connector.
               IEC_TYPE_2_AC refers to Type 2 as defined in IEC 62196-2. Also known as Mennekes connector.
               IEC_TYPE_3_AC refers to Type 3 as defined in IEC 62196-2. Also known as Scame connector.
               IEC_TYPE_4_DC refers to AA configuration as defined in IEC 62196-3. Also known as Type 4 or CHAdeMO connector.
               IEC_TYPE_1_CCS_DC refers to EE Configuration as defined in IEC 62196-3. Also known as CCS1 or Combo1 connector.
               IEC_TYPE_2_CCS_DC refers to FF Configuration as defined in IEC 62196-3. Also known as CCS2 or Combo2 connector.
               TESLA_ROADSTER, TESLA_HPWC (High Power Wall Connector) and TESLA_SUPERCHARGER refer to non-standardized charging
               ports/methods used by Tesla.
               GBT_AC refers to connector specified in GB/T 20234.2.
               GBT_DC refers to connector specified in GB/T 20234.3. Also specified as BB Configuration in IEC 62196-3.
               OTHER shall be used for charging ports not included in the list above.
               For additional information see https://en.wikipedia.org/wiki/IEC_62196.

Charging.ChargePortPosition:
  datatype: string[]
  type: attribute
  allowed: ['FRONT_LEFT', 'FRONT_MIDDLE', 'FRONT_RIGHT',
            'REAR_LEFT', 'REAR_MIDDLE', 'REAR_RIGHT',
            'LEFT_FRONT', 'LEFT_MIDDLE', 'LEFT_REAR',
            'RIGHT_FRONT', 'RIGHT_MIDDLE', 'RIGHT_REAR']
  description: Location of the charge port(s).
               First part indicates side of vehicle, second part relative position on that side.
               If supported, the list in this attribute shall have the same length as Charging.ChargePortType,
               and use same the relative order.
  comment: Example - If this signal is [LEFT_FRONT, RIGHT_FRONT] and Charging.ChargePortType is
           [IEC_TYPE_2_AC, GBT_AC] that means that there is Mennekes port on the left side of the vehicle near
           the front, and a GB/T AC port on the right side, near the front.
...

Alternative

Here are a couple of ideas for supporting instantiation of charging ports:

  1. Changing Charging for ChargingPort and making it a branch with multiple instances, such that: 
    
ChargingPort:
type: branch
description: Properties related to battery charging.
instances: [FRONT_RIGHT, REAR_RIGHT, etc...]
...
ChargingPort.ChargePlugType:
# Remains unchanged
...

ChargingPort.ChargePortType:

Remains unchanged

...

ChargingPort.ChargePortPosition:

Remains unchanged

... ...


2. Keeping `Charging` and including a sub-branch `ChargingPort` with multiple instances, such that:
```YAML
Charging:
  type: branch
  description: Properties related to battery charging.

Charging.ChargingPort:
  type: branch
  description: Charging port whose instances imply the position in the car.
  instances: [FRONT_RIGHT, REAR_RIGHT, etc...]

...
Charging.ChargingPort.ChargePlugType:
  # Only path changes
  ...

Charging.ChargingPort.ChargePortType:
    # Only path changes
  ...

Charging.ChargingPort.ChargePortPosition:
    # Only path changes
  ...
...
Charging.ChargePlugType:
  # Deprecate
  ...

Charging.ChargePortType:
    # Deprecate
  ...

Charging.ChargePortPosition:
    # Deprecate
...
erikbosch commented 1 month ago

Actually the current design is intended to be able to represent multiple ports.

Assume you have 1 IEC_TYPE_2_AC at front left and 1 at right rear, and in addition you also have a TESLA_SUPERCHARGER at front left.

Then that could be represented as:

Charging.ChargePortType = [IEC_TYPE_2_AC, IEC_TYPE_2_AC, TESLA_SUPERCHARGER]
Charging.ChargePortPosition = [FRONT_LEFT, RIGHT_REAR, FRONT_LEFT]

The disadvantage from a modeling perspective is that those two arrays are not linked from a formal perspective. Having ChargePort as instances and then a list of supported ports for that instance might be better from modelling perspective. I.e. representing the example above as something like

Charging.ChargePort.FrontLeft.Type = [IEC_TYPE_2_AC, TESLA_SUPERCHARGER]
Charging.ChargePort.FrontRight.Type = [IEC_TYPE_2_AC]
Charging.ChargePort.FrontMiddle.Type = [] # Or not defined at all
jdacoello commented 1 month ago

@erikbosch And what about defining a charging port as an struct? And then having an array of ports in the specification?

adobekan commented 1 month ago

MoM: Daniel will create PR, let's give it a try with struct.

jdacoello commented 1 month ago

I tried modelling multiple charging ports in two ways: (a) with Structs, and (b) with branch instantiation.

(a) with Structs

# In the Structs file
# -----
Types:
  type: branch

Types.ChargingPort:
  type: struct
  description: An individual charging port that is available in the vehicle with its associated properties.

Types.ChargingPort.PortPosition:
  ...

Types.ChargingPort.PortType:
  ...

# In the vspec file
# -----
Charging.ChargingPortList:
  type: sensor
  datatype: Types.ChargingPort[]

Pros

(b) with branch instantiation.

Charging.ChargingPort:
  type: branch
  instances: ["FRONT_LEFT", "FRONT_RIGHT"]. # instances names imply the position

Charging.ChargingPort.PortPosition:
  ...

Charging.ChargingPort.PortType:
  ...

Pros

Decision

I will create a PR with the option (b). However, it's important to notice to in either case, the limitation of cross-referencing has to do with the limits of the VSS itself because of being a single tree hierarchy. A few months ago, such limitations were presented with a possible way to solve it by adopting a language that naturally support a graph for cross references.

SebastianSchildt commented 1 month ago

Thanks. I agree that, a charge port not being an "atomic thing" (like structs are good for), using instances is better.

Wrt to the shameless GraphQL plug :), I remember there was the idea to have some GraphQL representation maybe as new 'new source of truth', that could be back converted to "classic VSS tree", I wonder where are we tooling wise? I.e. is https://github.com/COVESA/vss-tools/blob/master/docs/VSS2GRAPHQL.md currently already supporting some version of grpahql that you would see as a starting point for a GraphQL based VSS? Any way back currently?

jdacoello commented 1 month ago

Thanks @SebastianSchildt for pointing that out.

...idea to have some GraphQL representation maybe as new 'new source of truth', that could be back converted to "classic VSS tree"

Yes, that is indeed the proposal I presented at the last AMM in April 2024.

I wonder where are we tooling wise? @danielwilms and I started working on that tooling. While we've not been actively working on that lately, I'll retake that to push some changes (or additions) to the vss-tools. We're open if you, or someone else, would like to contribute and join efforts to realise that idea of adopting an established language to represent a data specification that resembles a semantic network and not only a tree.

is https://github.com/COVESA/vss-tools/blob/master/docs/VSS2GRAPHQL.md currently already supporting some version of grpahql that you would see as a starting point for a GraphQL based VSS?

Yes, that initial export script was taken as the starting point. However, we identified some modelling decisions there that, in our opinion, were not optimal. We are changing the structure of that export. Then, next step is to do the opposite conversion and test for completeness of the original vspec.