- From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
- Date: Fri, 20 Mar 2020 19:11:25 +0100
- To: public-automotive <public-automotive@w3.org>
- Message-ID: <CAHfMbK-y1ZZ9SiQYzPUwnKoS7J6Yj5iW8_Hu7_f8UgM5f909-w@mail.gmail.com>
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
Attachments
- application/pdf attachment: EV_data_access_requirements_for_GENIVI___1_.pdf
- application/pdf attachment: Fleet_EV_and_Electricy_Utility_EV_Load_Use_Cases_-_for_GENIVI__PUBLIC_.pdf
Received on Friday, 20 March 2020 18:11:27 UTC