Open jdacoello opened 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
@erikbosch And what about defining a charging port as an struct? And then having an array of ports in the specification?
MoM: Daniel will create PR, let's give it a try with struct.
I tried modelling multiple charging ports in two ways: (a) with Structs, and (b) with branch instantiation.
# 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[]
Position
can be explicitly specified as a property in the struct.
PortType
), whereas other dynamic (e.g., isFlapOpen
). Hence, creating a mismatch.charging session
with the data of the charging port
involved).Charging.ChargingPort:
type: branch
instances: ["FRONT_LEFT", "FRONT_RIGHT"]. # instances names imply the position
Charging.ChargingPort.PortPosition:
...
Charging.ChargingPort.PortType:
...
charging session
with the data of the charging port
involved).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.
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?
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.
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.Alternative
Here are a couple of ideas for supporting instantiation of charging ports:
Charging
forChargingPort
and making it a branch with multiple instances, such that:ChargingPort.ChargePortType:
Remains unchanged
...
ChargingPort.ChargePortPosition:
Remains unchanged
... ...