[SystemSafety] At least PBL is now talking to me again ...

Olwen Morgan olwen at phaedsys.com
Sun Jul 12 00:21:46 CEST 2020


On 11/07/2020 18:19, Peter Bernard Ladkin wrote:
> There have been very few no-fuel incidents amongst high-performance jet transports, and even fewer
> amongst 4th gen aircraft. All of them, as I recall, involved crew mishandling of some situation.
Agreed. While I was working on fuel systems, I looked up all the reports 
I could find on no-fuel incidents. AFAI recall by around 2006/7 there 
had been a little over a dozen of them. By global aviation standards, 
very few indeed.
>> The notorious Air Transat Flight 236 incident at Lajes in the Azores in 2001 comes to mind. Yet
>> when, in 2006 and 2007, I was working at the Airbus Fuel Systems Test Facility in Filton, I was
>> told that Airbus fuel monitoring systems at that time did not monitor fuel-on-board and the rate
>> of fuel consumption (by combustion or loss) against flight plan and current position.
> They didn't then and they don't now. Fuel is technical. Flight plan and current position is nav.
> Crew have been required by aviation regulations for that century to monitor and control fuel burn
> and quantity. It has nothing to do with nav.
>
> Programmers understand separation of concerns also. The word for it in programming is "modularity".
Indeed, they come under different chapters in JAR. My point, which I 
discussed at length with two Airbus fuel system design engineers, was 
that by a very modest piece of data fusion using information from 
different JAR-designated aircraft subsystems, the aircraft would be able 
to show the pilots *more salient warnings* such as "Flight Plan 
Uncompletable" to draw greater attention to the possible consequences of 
unexpected use or loss of fuel. As I envisaged it working, that message 
might have been shown to the pilots *before* the FUEL IMBALANCE alarm 
was issued. All of my proposals were directed towards issuing earlier 
more salient warnings of problems based directly on my examination of 
cases of no-fuel and low-fuel incidents.
> All Airbus aircraft have systems that monitor FOB and fuel flow. By integrating the latter and
> comparing with (initial-FOB - current-FOB) there is an immediate indication of any loss.

I know. ...

My work on that Airbus contract was concerned with testing those systems 
on the commissioned avionics test rigs. I was asked to look into how 
testing practices on fuel avionics test rigs could be improved. 
Basically my answer was "hugely". At the time nobody was able to show me 
even written test coverage criteria for all pumps, valves, piping 
branches and possible point-to-point flows in the system - and the test 
control software didn't, AFAI recall, track which of these elements were 
actually covered on the test rig. In fact, at one point I had to 
translate from French into English, four quite basic unit-testing 
standards from Airbus in Toulouse - and I considered that even they left 
much to be desired. One of them was written in some of the worst 
technical French I have ever seen.

... But it's one thing for an avionic system to show the mimnmum 
information that you need. It's quite another presenting in a way that 
focuses your attention when and where you need it to be focused - and 
that's quite apart from the problems of badly written checklists, of 
which I have been aware since I first saw some pretty dire ones at 
Airbus - more useful as bog paper IMO. (BTW: Anyone interested in 
checklist quality might find Atul Gawande's book "The Checklist 
Manifesto" a good read - find it on Amazon and then check Abe Books for 
a cheaper deal.)

> The crew had the information. One of the main phenomena in that incident is that they did not
> believe the information which they were receiving. You might like to check out my note on the
> "Azores glider" on ResearchGate. It still gets a number of reads a week.
I read bits of the more detailed official account in other sources but 
your paper corresponds with what I remember from those sources. BTW, the 
diagram of the A330 fuel system in your paper looks very much like it's 
based on a cleaned-up screenshot of the Tcl/Tk GUI that the A330 fuel 
systems avionics test rig uses. I was working with the guy who developed 
that test control software.
> Airbus did reconsider quite thoroughly at the time what needed to be annunciated.
> I then came up with a> handful of suggestions that could give pilots early warning of unexpected loss or deficiency of
> fuel
> by monitoring just a few readily available scalar parameters.
>
> If you are talking five years later, I can assure you that they had completed their reconsideration
> years before that.
>
And, AFAI could see, they were revisiting the issue in 2006/7 owing to 
concerns over the saliency and timeliness of warnings. By then, some 
Airbus fuel system engineers were also beginning to wonder whether more 
salient warnings derived from data from different JAR subsystems might 
be worth having. I was having an ongoing dialogue about it with an 
engineer who had been asked to investigate possible problems and 
opportunities for systems improvement and I wrote a couple of internal 
technical memoranda on the subject.
>>> The proof of that lies before our eyes in this case. As I noted, Boeing knew all they needed to know
>>> technically about the specific safety properties of MCAS in March 2016.
>> What they "needed to know" was that the system was potentially very dangerous (to put it mildly).
>> Did they know it?
> Didn't I answer that question in my last emails? The DoT IG answered your question definitively.
>> I think that they believed MCAS was safe when it wasn't but simply failed adequately to consider any reasons why
>> that belief might be mistaken.
> You are wrong in that supposition, according to the DoT IG.
>
With all due respect, Peter, that is not my reading of the relevant 
sections of the DoT IG report. I read it as a groupthink-like pattern of 
cognitive dissonance. And that's not intended to be weasel-wording. On 
consideration, I very much incline to the belief that that's what 
happened - if only on the grounds of preferring the cock-up theory to 
the conspiracy theory whenever there seems to be a plausible choice.
>> "specific safety properties". Right now, it's not very clear to me what you intended that
>> terminology to encompass. Are we talking short-span or long-span properties?
> We are talking the properties defined in 14 CFR 25, alternatively EASA CS25.
Again, with all due respect, Peter, after searching my Inbox, I can't 
find any prior reference to 14 CFR 25 or EASA CS25 in this thread. Had 
you *more helpfully* given a specific reference into some particularly 
relevant part of their several hundred pages -  I would have looked them 
up before replying. Strange though it may seem to those with better 
memories, I don't walk around with codes of airworthiness requirements 
in my head. It's not my cognitive style to remember vast corpora of 
information - a grave failing that, if what he said is to be believed, I 
share with the late Albert Einstein: ... "Never memorise something that 
you can look up." ... Why do you think I keep saying, "AFAI recall ...." 
and inviting people to correct me?
>> And that assumption could have been shown to be shaky by using HMI expertise to devise
>> out-of-left-field (OOLF) crew reactions or non-reactions to throw against the system in stress
>> testing.
> Good idea. But not original. Aircraft manufacturers already have people whose job it is to do
> exactly that. In simulators and in real airplanes. They are called test pilots. It is test pilots
> who found the breach of 14 CFR 25.175 which led to MCAS, and it is test pilots who found that, with
> runaway stabilator due to unintended MCAS activation, you entered a hazardous condition after 4
> seconds and a catastrophic condition after 10 seconds if you didn't cancel runaway trim.

I never claimed it was original. Most of my gripes in systems 
engineering are about engineers not learning age-old lessons. And, in 
any case, I'm inclined to think that well-designed test-rig based 
simulated stress testing would still have stood a good chance of 
spotting the MCAS problem *before* more costly test flights began. ... 
Not that that would necessarily have broken in on a groupthink 
mentality, but it would at least have been an opportunity for earlier 
and more economical problem detection. A test rig simulation is somewhat 
cheaper to conduct than a test flight.


And I fancy I see a possible basis of our apparent differences of 
perspective. You were looking at the evidence (which I would never 
disparage). I was following my customary cognitive maxims of:

1.    Whenever you see a box, try to think outside of it.

2.    Whenever you see a system, try to think of how you - and others - 
might subvert it.

I will, however, readily concede that these habits have been reinforced 
- possibly to an undue degree - by the frustrations of working in Cystopia.


Olwen





More information about the systemsafety mailing list