Mathematical Operation in Vspec

[sanyakamra]

• Regarding the specification for Vehicle.Timeincurrentrip, could you please clarify if it's possible to utilize the variables x and y defined in the parameters section to perform a mathematical operation in the transform block to calculate the value of Time in current trip? If so, what specific mathematical operation should be applied using these variables?

• I'm currently exploring the possibility of performing mathematical operations on two signals under a signal math transform. Specifically, I'd like to calculate the average time in the current trip by subtracting the start and stop times. Could you please provide guidance on how I can achieve this within the signal math transform?

[erikbosch]

I am not sure if I fully understand the context of the issue. We do not have Vehicle.Timeincurrentrip in the standard catalog. We have some trip-related data at https://github.com/COVESA/vehicle_signal_specification/blob/master/spec/Vehicle/Vehicle.vspec#L220

[sanyakamra]

Hi @erikbosch,

That is correct. I'm exploring the possibility of implementing mathematical operations on two standard signals to obtain their values when using the 'getValue' function on a third signal.

I've attached the current selected signal below. My question is whether we can perform mathematical operations on two standard signals within the 'math' field of another third signal.

Vehicle.Powertrain.TractionBattery.Charging.TimeToComplete:
  type: "sensor"
  datatype: "uint32"
  unit: "s"
  description: "Estimated time to full charge"
  transform:
    math: "((72 * (1 - x)) / ((y * 120) / 1000))"
  parameters:
    x: Vehicle.Powertrain.TractionBattery.StateOfCharge.Current
    y: Vehicle.Powertrain.TractionBattery.Charging.ChargeRate

[erikbosch]

That would be doable, it seems quite similar to what the Eclipse Kuksa project is doing when providing metadata fro CAN/DBC to VSS mapping, see https://github.com/eclipse-kuksa/kuksa-can-provider/blob/main/mapping/README.md.

But VSS/VSS-tools only help you with bringing the info to your target output format. Eclipse Kuksa for instance use vspec2json.py to convert the VSS catalog with the extra info given by an overlay. Then it traverse JSON itself and do what it does.

The possibility to express that a signal is derived from other signals and express how is mentioned as a useful feature now and then, but so far there have not been initiatives to standardize any specification format, or to create any helper features in vss-tools to validate/evaluate given info.

[jdacoello]

Although including that information in VSS is possible, I haven't seen a strong interest in doing so. The main reason is that such information can be part of the queries that are served by an API.

Another (simpler) example is issue #690 , where the intention was to model a property multiple times to have in the specification placeholders referring to different units. Such things can be handled in the API directly.

If having a formal specification of such derived in formation is interesting for you, then you might like the proposal to adopt the GraphQL schema language as the main language for VSS.

Your example could look like:

# Query definition
type Query {
  timeToCompleteCharging(
    stateOfChargeCurrent: Float!  # parameter x
    chargeRate: Float!  # parameter y
  ): Float
}

# Resolver function (that implements the logic)
const resolvers = {
  Query: {
    timeToCompleteCharging: (_, { stateOfChargeCurrent, chargeRate }) => {
      return (72 * (1 - stateOfChargeCurrent)) / ((chargeRate * 120) / 1000);
    },
  },
  // Other resolvers, if any
};

[nwesem]

MoM:

• request for more comments to this discussion