State Of Charge Manipulation
State Of Charge or SOC is the batteries level of charge, usuailly expressed as a percentage of full. It is similar to a fuel guage, such that 25% SOC is 1/4 full. Depth Of Discharge or DOD is another term used which describes how empty the battery is, DOD is the opposite of SOC so 25% SOC is equal to 75% DOD. Since in a Hybrid the battery is recharged from gas the SOC usuailly has a target of about 3/4 full. This is unlike an all battery electric vehicle or BEV whos SOC would fall from full to empty untill refuelled just like a traditional car. In a PHEV we usuailly want the SOC to act more like that of a BEV up to a point, we want a lower target SOC so that there is more room to recharge from offboard sources such as the grid. Though it is also important not to reach to deep a DOD so that the car will still have electric assist power and to prevent problems with certain battery chemestries which can be damaged by deep discharges.
The Prius' battery management computer (BMS, called the Battery ECU) communicates to the main hybrid computers via the CAN bus. It indicates battery voltage, current, temperature, and its estimates of state-of-charge (SOC), and maximum allowable charge and discharge current.
The BMS' estimate of SOC is critical, as the hybrid controller keeps SOC within 40-80% (the lower and upper limits of the (nonlinear) display graph), and tries to keep it around 60%. When the SOC is above 60%, the hybrid controller works to discharge the battery by using battery power (and less gasoline) even during normal cruise. This increases to around 30A (~6kW) at 70% and above.
When the SOC is below 60%, the hybrid controller works to charge the battery by making the ICE work extra hard even during normal cruise. Below 40% SOC, stranger things happen and it is difficult to get the engine to put out much power at all.
For a PHEV, the object of SOC spoofing is to keep the BMS's indicated SOC at 80% or above until the battery is discharged enough to accept significant regenerative braking current; then between 70-80% -- to force less gasoline use even during non-EV-only mode -- until the battery's real state-of-charge has come near its lower limit. At that point, the BMS's indicated SOC should hover around 60% to keep the battery's real state-of-charge from trending further downward (bad for the battery) or upward (thereby wasting gasoline).
Dan Kroushl did some experiments with higher voltage batteries that proved that the BMS's indicated SOC can be spoofed (Thanks, Dan!). That led me to do enough further experimentation to discover that it is definitely possible to do what I indicated in the above paragraph, and generally how to do it. However, the circuitry and programming to do so is still in development. It generally involves, as needed, providing a higher voltage to the BMS than the actual battery voltage.
Toyota's BMS also checks the voltage of 13 taps on the OEM battery. These voltages must be equal to each other or the BMS will indicate a fault. Since few PHEV battery packs, unlike the OEM pack, are divisible into 14 equal subpacks, these tap voltages must be spoofed, too. Fortunately, it has been found that a fairly simple voltage divider can accomplish this.
Because of all of the above, CalCars' overall PRIUS+ circuit diagram is still in flux, and definitive answers about it are as yet unavailable.
Here is the minimum needed in terms of a computer for spoofing the Prius' built-in BMS:
- CAN message reading and parsing (CAN bus writing is NOT necessary or even desirable)
- The ability to separately close and open two reed switch contacts based on CAN information
- one to set EV-only mode, based on it not already being set, speed <34 mph, power request <120 (out of 200), SOC >49%, and a few other parameters.
- one to set a voltage boost (to be explained later) to keep perceived SOC within a given range until the battery is sufficiently depleted
- Amp-hour integration and display from the appropriate CAN bus messages
- HV battery voltage and current display (both analog and digital desirable) from the appropriate CAN bus messages
- Display of trip info (since reset): # of CAN errors (important for debugging), odometer, milligallons of gasoline used, Amp-hr and/or kWh used, trip milligallon/mi, Wh/mi, and mpg, highest peak charge and discharge currents, highest and lowest HV battery voltages, and the battery's internal resistance (beginning, current, and end)
Additional displays, desirable but not necessary:
- Not strictly necessary, but SUPER desirable: storage of CAN trip running data on a removable medium (like a CompactFlash card) for later analysis.
- Small graphical engine tachometer (but see rectangular suggestion below)
- Gasoline use rate (milligallon/min and/or milligallon/mi (inverse of mpg), or just a binary for gasoline being used
- Tiny graphical brake cylinder pressure (sum of that for each wheel), to indicate amount of non-regenerative braking being used
A very cool display would be two rectangular graphs indicating engine and electric power:
- Engine power (e.g. blue for combustion): vertical: RPM, horizontal: torque
- Electric (e.g. red for discharge, green for charge): vertical: HV battery voltage; horizontal: HV battery current (absolute value)
The areas can be calibrated so that they show the relative power being produced by the electric motor vs. the engine. The same pair of rectangles could display and compare the power going into regenerative braking vs. that being wasted in the friction brakes.