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.

Sign up for GitHub

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

Jump to bottom

Allow instantiation of charging ports #753

Open
jdacoello opened this issue Jul 8, 2024 · 7 comments
Open

Allow instantiation of charging ports #753

jdacoello opened this issue Jul 8, 2024 · 7 comments

Comments

@jdacoello
Copy link
Contributor

jdacoello commented Jul 8, 2024 •
edited
Loading

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
  ...
...
  1. Keeping Charging and including a sub-branch ChargingPort with multiple instances, such that:
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
Copy link
Collaborator

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
Copy link
Contributor Author

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

@adobekan
Copy link
Collaborator

adobekan commented Jul 9, 2024

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

@jdacoello
Copy link
Contributor Author

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

  • Position can be explicitly specified as a property in the struct.

Cons

  • The specification starts to encapsulate instances that will become only evident after the elements in the array of structs are created.
  • All the properties in the struct are supposed to be read or written in a single operation. However, some information might be static (e.g., supported PortType), whereas other dynamic (e.g., isFlapOpen). Hence, creating a mismatch.
  • Limitation will be encountered as soon as cross-references are needed (e.g. relating the data of a charging session with the data of the charging port involved).

(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

  • Specification of instances is given upfront.
  • All properties inside the branch can be individually accessed or modified.

Cons

  • Limitation will be encountered as soon as cross-references are needed (e.g. relating the data of a charging session with the data of the charging port involved).

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.

@jdacoello jdacoello mentioned this issue Jul 15, 2024
Merged
@SebastianSchildt
Copy link
Collaborator

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
Copy link
Contributor Author

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.

@jdacoello
Copy link
Contributor Author

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.

As an update to your question, @SebastianSchildt, I documented the ongoing work for adopting graphql schema language on this COVESA Wiki.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@adobekan @SebastianSchildt @jdacoello @erikbosch