The flight data recorders don't contain the information from the battery monitoring unit which is responsible for battery state of charge, over charge, discharge, battery balancing, ... (Or basically every battery safety related function). The main thing noted in the event log is that the APU bus failed repeatedly and the charger attempted a number of high current charges before the entire system failed due to the battery likely catching fire. The main question I have is that none of the investigation or reports appear to inspect the firmware and design of the monitoring and safety circuit.
The main protection contactor internal to the battery was closed but not welded closed which means the BMU failed to detect cell 6's failure and did not inhibit the BCU from charging the battery (Altering the charge parameters is probably a good idea and the upgrade kit replaces the charger entirely so it is likely that the charge rates were poorly thought out).
The fact there where only two temperature sensors for the entire battery is below the standard safety thershold for battery monitoring which is good design practice to have at least one sensor per battery (especially when they are large cells and thermal lag between cells makes dual sensors insufficent to detect high internal cell temperatures)
Ideally for an aviation battery it should have two sensors per battery and individual cell protection circuits that can individually drop a cell off the stack as to not kill all power to the systems. This method would be far more fail safe and would fail gradually and provide series protection on top of the battery pack protection (Much smarter battery charge control would also be a good idea).
The main thing that stood out to me is that the 1 volt drop in pack voltage was likely the cell 6 failing and the BMU should have inhibited the BCU from attempting a 40+ Amp charge. This is an obvious and recorded firmware bug in the BCU which has not been investigated or fixed.
Compared to Toyota, Beoing seems to be getting off far too easy on what is essentially the last line of defense in a basically all-electric plane (Putting it in a stainless steal box doesn't fix the problem and in Jan 2014 another battery failed just inside the magic box). (No APU battery = No APU start without engine AC power which in a birdstrike situation similar to US Airways Flight 1549)
Boeing's solution to an obviously defective and still defective battery pack is not a software patch but a duct tape non-fix of putting it in a flame box so when it catches fire it doesn't spill everwhere. If a 787 crashes because of loss of battery backups the "fix" won't help one bit.
(Its a software and hardware bug and no one is bothering to fix it they just keep adding insulation and boxes inside of boxes...)
We have the media, lawyers, and "experts" jumping up and down over a non-issue car ECU but nothing on a clearly non-fixed system with no final report for another year and no root cause and no fix. We should just make it law to open source safety critical fail safe detection methods so no one can complain about it being unknown/unfair. (No need for everything just require publishing the raw code that runs the failsafes and a spec on how that is integrated in hardware)
It may or may not really be fixed. But the challenge is in defining the term "fixed." jet fuel is an incredibly dangerous material. It hasn't been fixed, but the vehicle has been designed to accommodate and contain that danger as much as possible.
Time will tell if the steps Boeing took will prevent battery fires all together, but my guess is that they have just reduced the probability of a battery fire and designed in containment measures in the event of a fire.
That may seem like poor quality hack and patch engineering. But, if it is, then you would have to say that any device that depends on a volatile fuel or high voltage electricity is just hack & patch engineering because the danger hasn't been remove from any of that. It's just been mitigated and contained.
The only real question is why all this was allowed to happen when they had problems during the initial testing of the Li-ion sub-system? All this could have been avoided if they had fixed the problems then.
Bill, I think it has been pretty well determined that the problem is an internal battery problem, not one of charging circuits or of load gone amuk. The fix aims to eliminate the risk of cell problems creating a hazard, and it also reduces the amount of electrical stress the cells are subjected to overall (e.g. allowing less discharge than before, and also less charge than before).
I can't imagine the hectic work environment those 200 engineers have been subjected to, in these months, to come up with a viable solution. And I can only guess at how many "I told you so"s there must have been, among many of these engineers, concerning the decision to go with Li-Ion to begin with? That's just a wild guess, I admit. I sure don't envy them.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.