cwatters:
Initially the voltage only falls 1V which is probably not enough for the BMU to see it as a fault (The battery voltage might vary that much due to normal load variation?). That might explain why it continues charging for another few seconds. Only when the voltage has fallen far enough does it realise there is a battery fault and issue the EICAS message.
If the battery was charging at all, then the BCU would have seen current going into the battery. Hopefully one of the things it was looking at was the reading from the Hall Effect current sensor which is directly on one of the battery leads on the battery side of the BCU connection. And if it was checking frequently enough, it would have seen the voltage drop happen while the net current into the battery was still positive. Hard to explain that away (from its point of view) as the effect of a change in load. It may not have applied that logic, but maybe it should have?
I notice the battery voltage falls to 0V and returns to 28V. I wonder if that was caused by the contactor trying to disconnect the battery? I hope the board controlling the contactor doesn't need a functioning battery to provide power to control the contactor?
My expectation is that both the primary contactor and the backup contractor open when unpowered, and energy to close the contacts comes from either the BCU or the battery itself, under the direction of the BMU. But if the BMU circuits got fried quickly, they might not have been able to enforce their intention to open the contactor. This happened some time (a few seconds) after the initial observed event and we really don't know when the first damage was done to the BCU. Or the battery voltage dropped below the hold voltage of the contractor or the decision threshold of the BMU, causing it to open, the battery voltage could then have rebounded enough to close it again.
Not enough information.
