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

[Peter Bernard Ladkin]

On 2020-07-11 17:26 , Olwen Morgan wrote:
>  
> To give an example, there have been several air incidents in which planes have run out of fuel. 

This is a classic aviation hazardous-to-catastrophic condition to which a lot of attention has been
paid for over a century.

The two things which pilots learn repeatedly from the very first time they set foot in a flight
school are: don't stall; don't run out of fuel. (The bit about "know where you are" comes somewhat
later.)

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.

> 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".

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.

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.

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.

>> 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.

> "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.

> 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.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
Styelfy Bleibgsnd
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20200711/b1a545c9/attachment.sig>