[conspire] Added carrier scrutiny
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Tue Apr 9 03:50:23 PDT 2019
I guess - for better and/or worse (probably fair bit 'o both), I come from
a somewhat different perspective on these (e.g. airline safety/incident)
matters.
Teensy bit 'o background. Once upon a time, in ancient history (I was a
kid), my career ambition was commercial airline pilot. Well, some fair
number of years later (when I was about 12..13) my career goals shifted
from that, to electronics-->(mostly) digital-->computers-->Unix-->Linux.
Regardless, I continued and continue to have an interest(/curiosity)
regarding and around aviation ... not that I (generally) follow it all
that closely, but ... sometimes I do (and/or portions thereof ... and
generally much more so than at least the general public).
Also, as a (more-or-less) engineer in the electronics/computers/
operating system(s)/Unix/Linux/software realm - I've lots of interest(s)
there, ... and including "all" the things that can and do go "wrong"(/fail).
And in engineering, and learning about such, there's also much overlap
in other more-or-less related fields - so I tent to at least loosely follow
some 'o that too - not uncommonly lessons learned in one area can also be
well applied to many other fields (but also, sometimes too, don't
work/fit/apply to some - or not nearly as well or suitably).
So, sure, lots more out there but, among my readings and stuff I do follow /
have followed ...
read _Computer Related Risks_ - Peter G. Neumann
http://www.csl.sri.com/users/neumann/neumann-book.html
(*Highly* recommended for engineers (practically all, as most all
now use/overlap computer technology these days), programmers/developers,
QA folks, and those that manage any of the preceding)
semi-regularly follow Risks Digest
http://catless.ncl.ac.uk/risks/
I also - at least once-upon-a-time, read the compendium summary
of data from Risks Digest - I think at the time it was between 50 and 85
pages of one-line summaries of particular risk incidents (pretty good
way to get relatively fast overview of varieties of types of risks,
impacts, and approximate frequency distribution).
Anyway, semi-regularly read fair bits of more-or-less related stuff
(what goes wrong, and how to "fix"/prevent it, are of general interest
to me)
Once upon a time, I read Bugtraq for quite a while (some years or so) ...
but after a while I found it pretty redundant (mostly folks making the
same stupid mistakes over and over and over and over again - rarely anything
fundamentally new).
Bit more specific about my aviation readings ...
'da Interwebs ... pretty sure it was the TWA 800 - if I recall correctly
(blew up over ocean - around wing area ...). So stuff happens, it gets
reported (often short over-simplified, and often significantly incorrect),
major incident like that, roughly about a year or so later, if one might
happen to hear/notice it ... a "final report" (e.g. NTSB) comes out. That
typically gets negligible news coverage/mention - it's mostly a whole lot
of details that aren't, "sexy" to most (don't boost news ratings).
Anyway, the (TWA 800 - if I recall correctly) final report came out ...
we (semi-barely) had 'da Interwebs by then ... and ... the report was
available on-line - full report ... so I snagged a copy, ... and ...
read it. I found it pretty dang interesting/fascinating. So, ... I
started reading the final reports, doing backwards, chronologically,
covering about a decade or so. Pretty dang, uh, "interesting", to
say the least - and quite informative. So ... among all that, and
other areas/fields too (e.g. software, operating systems, computer
security) ...
I find these larger systems are generally, to large/most extent, quite
complex. Often news/public only has patience for a short
(over)simple(/ified) "answer"/snippet - they don't want a whole lot of
detail, and all the contributing factors - they want a sound bite,
a snippet, some photos, maybe some quotes, and some few
person(s)/company(/ies)/department(s)/agencies to blame.
Well, ... the reality is generally much more complex than that - at least
typically.
Let's peek a bit at the current Boeing Max ... mess. And my take on it,
and some other semi-random bits. General public? Short attention span.
They're probably mostly not much beyond:
Boeing
two big planes crashed, everybody died on both
Sounds like Boeing's fault - some flight control software glitch.
Planes grounded - USA about last on that - Trump/FAA messed up too?
I think my perspective on it is something more like approximately this
(and pardon's if I don't get some details (quite) right):
Overall I find Boeing likely quite to highly culpable, but there's
a whole lot 'o "contributing factors". In perhaps rough order of
weighting of "contributing factors" - I might rank 'em roughly as
below ... but also some of 'em form sub/super-sets, overlap, may not
be (easily) directly compared, etc. - so ordering probably very rough
approximation at best (and thanks to those that have provided details too,
many of which I'd have otherwise been unaware of):
Boeing MACAS software - nasty violation of principle of least surprise
software overrides stick/yoke - pilots unable to countermand with, e.g.
more force to stick/yoke
inadequate (about non-existent) relevant training - pilots mostly unaware
MACAS able to exert control/influence (about?) 10x certified
(reminds me also of effective but safer semi-automated systems, e.g at
speed limit boundary, gas pedal becomes significantly more difficult
to depress further, but can still quite easily be so depressed by
applying a fair bit more pressure ... just not very/highly comfortable
to apply that continued additional pressure for long periods of time -
quite effective at reducing speeding, while also still allowing such
quite enough for emergencies, overtaking and passing, and sometimes
even avoiding being hit ... so rather seems to me, yoke/stick, don't
let the software override the pilot's manual input - but probably okay
for more force (within reason) to be required, if some automated
something-or-another on the plane thinks (quite possibly incorrectly)
that's a bad idea).
(Boeing) airframe design (engines, etc.) - not(/marginally) airworthy?
More complex system(s), more difficult to fly, less stable, more
complexity needed to compensate airframe design - more stuff to go "wrong"
aerodynamics may make it "impossible" to correct certain situations
(jackscrews jacked from perssure), unless unconventional (roller
coaster) procedures are also well(/sufficiently) known
Airline(s) - failed to heed related earlier incidents - lack of action
(De)regulation / airline self-regulation - conflicts of interest, "wrong"
priorities, etc. Bloody politics & $$s (most likely) too.
If one really wants to go to "self-"regulation, could it be done in
a *competitive* way that (mostly) works? E.g. Lockheed (and everyone
but Boeing) regulates Boeing - and vice versa for Lockheed, etc.?
And make sure it's as open a process as feasible? And that there's
sufficient oversight it doesn't get corrupted or turn into an
"I'll scratch your back, if you scratch mine."? Or maybe some
hybrid approach(es)?
What's the culture/influences, motivations, conflicts, within the
regulatory environment? What's broke, and how did it break? Was it
(mostly) working before? How does it compare to other regulated areas
where safety is particularly relevant - and likewise compared to other
countries/cultures?
Poor design(s) - e.g. safety bits as "optional features"
lack of transparency (it cost how much? Which airlines installed?)
lack of clear information to pilots (by default (no options)) of
what's going on, why, what the failure/issue is - e.g. nothing clearly
saying, "Hi, I'm MACAS, I've taken control and am flying your plane now.
If you've got a problem with that, my off switch is the big flashing
lit MACAS In Control button right next to ..."
What's the environment within which all this happens?
Designed/built - safety culture? Feedback - safety vs. other factors,
and up/down chain from CEO/shareholders to night janitor. What's
"broken", and what can be done about it? Where/how did it break (or
was it always broken)? What caused/changed that?
How does it compare to - other companies, countries, environments,
cultures. Who does it better / much better - and how? Who f*cks it
up lots worse too - so we can also learn by counter-example and perhaps
extrapolate.
Airline/pilot environment - likewise,
culture/feedback - airlines, pilots, on reporting possible issues,
protesting or refusing to fly something that may be unsafe
how does it vary among airlines, and airlines in other countries?
What about laws/regulations protecting, e.g. whistleblowers? Are
they effective?
$$s - incentives to make more - over safety, etc.
shareholders, quarterly returns,
buy/sell/trade with zero(/negligible) fees - reduces long-term
financial incentives and comparatively promotes short-term
"go for broke" - company financially squeezed - less risk adverse? Are
there ways to counter-balance that? Especially on safety? Aren't there
similar issues in many other industries, where health/safety may be
significantly/substantially put at risks? Are there lessons learned /
effective practices there that could/should be applied to airline industry?
"Responsibility" blaming/jailing persons is often at best semi-effective.
Not that (I think) there shouldn't be any penalties/prosecutions as/when
appropriate - but, as feasible, prevention is generally much better.
How do we (re)adjusts incentives/motives/attention *much* earlier on,
to more so prevent these types of problems?
Sh*t happens - not that I'd necessarily advocate going a "blameless"
route, but there are (some) advantages of approaches "without" (or
lessening) "blame". Can (some of?) that be useful here? At least
in part?
Complex systems (general) - e.g. this case, I see a lot of stuff that
interacts/contributes, ...
selling features - "just like" ... (almost) "no need to (re)train"
(ostensibly) more cost effective - longer body, bigger more
efficient engines
(original) design pushed past(?) it's limits - and/or requiring much
more complexity to fly/manage (and more stuff to fail/break)
$$s pressures on companies (manufacturers, airlines, ...)
safety features not required? Sell as add-on options
want ostensibly more cost effective? Don't buy optional safety items
What's the flight crew environment?
What did(/didn't) they know?
What *could* they have (possibly/reasonably) found out?
Should there be / is it feasible for pilot environment/qualifications
to push/insist on getting (at least as feasible) all relevant
information?
Should it be possible / would it be feasible, to set up environment
where flight crew could demand *all* relevant information about the
planes, and could refuse to fly - without repercussion - if they had
any reasonable reason to believe the plane may not be safe (including
also lack of potentially relevant information). Is there anywhere on
the planet that works like this for flight crews? Smaller planes?
Spacecraft? Ships? Other fields or other relevant position(s)
of oversight in such fields? Nuclear power plants? Medicine?
Public water treatment systems? Hazardous waste? ???
Is it even feasible? It's certainly not done, e.g. by general
public driving cars - that's mostly done with large #s of vehicles,
not as/so (absurdly?) complex, much lower per-vehicle risk, and
comparatively un-(well, minimally)qualified operators. Sort'a seems
to me, commercial passenger jets are relatively the flip of that -
(much) more qualified operators, far fewer "vehicles" ... and
extrapolating, spacecraft would be the extreme of that.
Manned spacecraft typically doesn't have major software problems
that destroy craft - what can be learned from that (without going
"too"/infeasibly extreme)?
So ... probably lots of other details I'm forgetting that may also be
relevant.
So, ... while the general public might typically think something like:
That's a cr*p but in that Boeing software - they should patch it and
get those planes flying again - and maybe spank the person that wrote
that bug.
And various person(s) may be (rightfully and appropriately!) digging into
various details, ... as for myself, I'm thinking the problem is much
more complex - at least typically - in such systems/environments (that
"software bug" didn't come to exist out of a vacuum), and am thinking
more along the lines of what I outlined above.
"Defense in depth" - I also think like security and defense in depth.
Lots of contributing factors - all add up to failure/breach/disaster.
But fix most any, and that bad negative is (narrowly) averted.
Fix a bunch of 'em, and it's overall much safer, as it would require
many of them to fail / be breached - to have an overall failure event.
> From: Texx <texxgadget at gmail.com>
> Subject: Re: [conspire] Added carrier scrutiny
> Date: Mon, 8 Apr 2019 23:56:45 -0700
> So the latest on this caper is that it seems there was an official Boeng
> solution when the pilot was in a fight with the MACS.
> If you couldnt do anything else, you pull the fuse on the jack screws on
> the rear elevator plane.
> This basically disables the MACS.
> It turns out thats exactly what Etheopean Air did.
> Of course this now gives you a dead tail.
> So the crew did exactly what Boeing told pilots to do and the plane STILL
> crashed.
More information about the conspire
mailing list