Recorded data?
 

Hi,

syseng68k:

The fact that there's been no news about this suggests that either
a) It's not built into the design, or b) The function was on the internal
boards that were cooked in the fire. In either case, not very helpfull.
Otherwise, it would logically be the first place to look for the events
that led up to the failure.

c) Or this will surface soon. I hope!

The alternate way will be "look" to the other 47 planes and related batteries.

As what was commented earlier by EEngr

Quote:

---

Mysterious indeed...

---

Anxiety mounting...

There are two nations' regulatory agencies involved in the preliminary investigation. And some of us have multiple agencies with skin in the game (NTSB, FAA). And getting through the layers of subcontractors resembles peeling an onion (tears and all:{), I'm wondering how soon 'soon' will be.

Back when I worked at Boeing (and we still had some involvement in the design game), I could run down the hall and go talk to some engineer responsible for another subsystem. Maybe dash off a memo to record things. But once we adopted the outsource everything model (thanks, McDonnell Douglas), the equivalent communications had to go through 'proper channels' to ensure contractual compliance.

It would be interesting to see if the same is happening now. That is: Does the NTSB receive data from the actual responsible parties directly? Or does it have to work its way through both the contractual and international regulatory maze?

RR_NDB.
The diode module is not "the switch that puts the bat on the bus" as you say. The diode module is between the bat and the hot bat bus. The hot bat bus is only connected to a main DC Bus when there is no other supply and the bat switch is on. The bat is not discharging unless there is a power failure of the main DC busses.
Hope this helps.



Posted from Pprune.org App for Android

Testability issue
 

Hi,

old dawg and EEngr

Both comments makes me remember on Testability. I was concentrated on that issues on System, PCB and IC (LSI) level during many years. And i always had a great interest because worked before in Maintenance where i observed many difficult situations and even some unexplained facts "coming from design". Actually i designed for Testability, many items.

Both comments from you make me present the questions:

1) The batteries were subjected before to the same (routinely) conditions the 787 fleet experienced? Or even more demanding (routinely) concerning charging current, discharging current and temperature?
2) Are these batteries being exposed TODAY to this conditions in the Lab? (Yuasa or Thales) Or we would need to analyze the 94 remaining batteries.
3) In this case WHO would lead (and pay) the work?
4) The new battery (first use as main in an airliner) was equipped with enough data logging in order to analyze it´s performance after incidents or accidents?
5) Considering the current batteries are not just "cells in a package" how to manage the required work to explain WHY both cases happened?

Time is the only Testability "solution" really effective*. We never know how new components will perform in real life. Time proven parts are required in critical subsystems.

The Test Engineers responsible fort he new battery so important for a ~ US$40 Billion program indeed had a very complex and important task.

And the Decision Making (inside Boeing) was a critical, very critical one.

I hope someone is properly testing the Thales batteries right now.

(*)Yes, i know the JAL (main) battery was very young.

Could this be a cause for a virtual stalemate? And prolonged grounding?

TURIN, important detail. Will comment in few minutes!

Switching (clever design)
 

Hi,

TURIN:

Exactly what i expected! And showing a VERY GOOD APPROACH used by the colleagues. :)

First a briefing on the DIODE function. Actually it is a SWITCH. A fast switch. What flips the switch? The voltage between the 2 (only) terminals. They are used as switches since the beginning. (there are other uses).

As i can imagine in 787 main battery circuit the diode has the (Safety) function:

Make impossible the DC bus charge the main battery. This as i commented earlier would not be the safer way to charge the critical cells. Reasons: The bus voltage varies (due varying loads on it) and the current management (to charge the battery) would require a more complex and costly scheme. They designed very well, imho.

As i can imagine the designers put a redundancy (wisely) with 2 "means" to turn off the battery, as you made implicit. I probably would design exactly the same. :)

The switching function i mentioned in earlier post actually is the inherent diode function:

When the bus falls below (i estimate ~ 30 V) the battery power (kept at it´s top-nominal capacity by a charger certainly connected between the diode module and the battery) flows AUTOMATICALLY to the bus. As we may imagine, several important modules would die (reset) if the DC bus fails. The bus voltage would be not less than battery voltage level (decaying) minus the diode module voltage drop (less than ~2 Volts).

To be continued

In the meantime please comment on RAT and it´s relation to the important DC bus.

Data from the charger?
 

I'm brand new here and am neither a pilot nor an engineer. But I have a strong interest in the 787 problem -- and in a solution -- and have found this board very informative.

This is from the Securaplane website:
"Securaplane battery chargers store every fault including battery over-temperature, cell unbalance, defective temperature sensors, defective charger/battery connection and GMT time/date of fault period. Our chargers possess extensive diagnostics such as charger microprocessor status and permanent memory of faults with readout to the integrated 8-character alphanumeric display."

My question: I haven't seen anything in the press or on this site (unless I've missed something) about whether the diagnostic information from the charger(s) is available and, if so, whether it has been helpful. Do any of you have knowledge or comments?

How data can solve when incident facts were lost
 

Hi,

From the blog of John DeLisi, NTSB chairman:

787 case seems could require (and benefit from) the same approach.

How many months? :confused: :mad:

I would call them a flow gate before calling them a switch! :}

EEngr:

But would that stop you from calling the engineer to have an informal
chat, then formalise the results later to keep the paperwork straight ?
If not, how do you ever finish any complex multivendor project if even
a nut and bolt change has to go through formal channels ?.

Sounds familiar though. It can be bad enough within the same organisation.
I worked on a project with a large multinational computer company.
We were building a special system for a large customer. The computer
board had onboard firmware to allow bootstrap from a variety of hardware
devices and we needed to add some code to allow boot from an
unsupported device. The division that made the processor board were
in the US (we in UK) and flat refused to supply the source code. It
was only with the intervention of a very senior manager that we gained
access. Crazy, both working for the same company and assumed to be
working for the common good of the company.

Brookes wrote a book about big project management called "The Mythical
Man Month", iirc, in the 1970's, about software project management within
IBM. Well worth a read, software or not, even now...

Regards,

Chris

so much for RNP idle descent...

I knew it was a bad idea! :\

RNP idle descent...
 

FlightPathOBN:


:ok: :):)

Process of Change on the fly (in a Turbulent flight)
 

syseng68k:

Lessons from the GURU (GE)

http://www.deansutton.com/wp-content...ch-300x200.jpg

Quote:

---

“Formality is the most silly thing in the world. Bunch of pompous bureaucrats! Formality slows a company down. Change is what excites people. If you’re stagnant, you’re dead. You’ve got to get people to embrace change, and not be paralyzed by it. People want CEO’s that care. Authenticity is enormous. Candor counts.”

---

Question:

How to proceed with world wide outsourcing in a threatening scenario?

How critical they are
 

Hi,

Li Ion cell operating window

http://www.mpoweruk.com/images/lithium_window.gif

Cycle life and temperature

http://www.mpoweruk.com/images/age_temperature.gif

Source

So, why they are wonderful for a new design? They "seduce". :) The performance is because they are "tuned".

If dangerous (critical) in airliners (air conditioned)...:} I prefer not think they working in GA. :{

Testability issue
 

To be reviewed

Hi,

787 innovative design introduced Li Ion as main battery for the first time in (av) industry. We may think the battery will sit and wait most of their lifetime "waiting" for an emergency" in the DC bus. A very rare (very low probability) event.

If it happens how we can guarantee it will be able to supply the required power to the bus. (If it is not being used). Redundant elements (kept "offline") poses a Testability problem to the designers.

I don´t know how Boeing dealt with this issue. You may apply short duration pulses (discharge) to the cells to check it´s voltage "under "heavy" load.


The harness showed in battery pictures could be connections to the many cells and constituents of a BITE. We will be able to later verify that. The Built In Test Equipment could also be used to limit the cell voltages considering the series charging requires it due cells mismatch in the stack.

To be reviewed

A Stuxnet equivalent that piggybacks on the charging circuitry software logic? ;)

the experiment I would suggest
 

temperature sensors are never sitting at hottest spot and in this case they are sitting far away of this hottest spot I would expect in the middle of the cell.

now provoke a rapid thermal runaway by eg provoking short circuit in the center of the cell.

compare real temperature in the center of the cell with temperature measured at now given location to find out difference of these temperatures.

if measured temperature at given position eg shows 80 degrees when real temperature runs through critical tmperature adjust charging soft- or hardware and figure out how much energy content the battery still has compared to minimum required.

fly if still sufficient or go for bigger batteries...

Malware
 

ross_M:

:)

OTOH in an investigation EVERYTHING must be verified. (Trust but verify)

Why?
 

fuelevaporator:

Certainly both batteries failed (thermal runaway) when "floating"

And thermal inertia (delays, sensor location, etc.) were not important.

:confused:

Japan shifts Boeing 787 investigation from battery maker
 

Cells not found at fault, so far, so good.

From: Japan shifts Boeing 787 investigation from battery maker | HeraldNet.com - Work
I guess Kanto is responsible for the PCB's from the bat box.

Hi,

Bjm bi @ (#246)

Welcome. Useful info on Securaplane features.

We may suspect important info was lost from BOS JAL APU battery due fire. Amazingly from the pictures the 2 connectors (PCB) didn´t melt.

We may strongly suspect the information was lost. IIRC NTSB chairman mentioned .PCB destruction.