W3C home > Mailing lists > Public > public-automotive@w3.org > March 2020

EV signals to be discussed at remote f2f

From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
Date: Fri, 20 Mar 2020 19:11:25 +0100
Message-ID: <CAHfMbK-y1ZZ9SiQYzPUwnKoS7J6Yj5iW8_Hu7_f8UgM5f909-w@mail.gmail.com>
To: public-automotive <public-automotive@w3.org>
New attempt to send the *entire* information about EV signals.

BR
Ulf

here is the PDF presentation and notes re: Geotab presentation on EV signal
requirements at the virtual F2F.

Below you will find a proposal for the VSS integration of the  three EV
"signals" being discussed.

- Delivered energy to the battery during charging (kWh).
- Consumed energy from the battery during "non-charging" (kWh).
-  Delivered energy to the battery from regenerative braking. (kWh).
- Battery state of charge. (%)

These must represent accumulated energy over time as I see it. That is, the
values are monotonically increasing (until the value hits max possible,
when it wraps around to zero).
What resolution do we believe is needed on these kWh values?
Should the number of "wrap-arounds" be stored by the vehicle?

The existing VSS tree contains the following:
Vehicle.Drivetrain.BatteryManagement.BatteryTemperature
Vehicle.Drivetrain.BatteryManagement.LowBatteryLevel
Vehicle.Drivetrain.BatteryManagement.ChargingInlet

I modified it slightly by adding one more branch -  Battery, which changes
the existing entries to:

Vehicle.Drivetrain.BatteryManagement.Battery.Temperature
Vehicle.Drivetrain.BatteryManagement.Battery.LowLevel
Vehicle.Drivetrain.BatteryManagement.ChargingInlet

The proposal for the new EV signals below uses uint32 integers to hold the
values, which have the unit Wh. Is the resolution Wh sufficient?
As it says in the presentation that a typical yearly load is about 4000kWh,
then a uint32 would take about 1000 years before wrapping around.
For these vehicles there would be no need to keep track of an eventual
wrap-around, but maybe for heavy trucks?
It would be sufficient with one wrap-around counter, as  ChargeEnergy and
ConsumedEnergy will not differ significantly. A uint8 should cover the
needs.

- Vehicle.Drivetrain.BatteryManagement.Battery.ChargeEnergy:
  datatype: uint32
  type: sensor
  unit: Wh
  description: The accumulated energy delivered to the battery during
charging.

- Vehicle.Drivetrain.BatteryManagement.Battery.ConsumedEnergy:
  datatype: uint32
  type: sensor
  unit: Wh
  description: The accumulated energy leaving HV battery for propulsion and
auxiliary loads.

- Vehicle.Drivetrain.BatteryManagement.Battery.BrakingEnergy:
  datatype: uint32
  type: sensor
  unit: Wh

- Vehicle.Drivetrain.BatteryManagement.Battery.StateOfCharge:
  datatype: uint8
  type: sensor
  unit: percent
  min: 0
  max: 100
  description: The current charging level as a percentage of original
battery performance.

  description: The accumulated energy delivered to the battery from
regenerative braking.



-- 
Ulf Bjorkengren
*Geotab*
Senior Connectivity Strategist | Ph. D.
Mobile +45 53562142
Visit www.geotab.com

Received on Friday, 20 March 2020 18:11:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 March 2020 18:11:29 UTC