Fwd: Remote meeting schedule and agenda update

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  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. (%)

The first three 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?

- 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.

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