Man-machine interface and anomalies

[RR_NDB]

The increasing technological sophistication in FBW planes brings benefits and challenges to the pilots and other 'players". The objective here is to discuss the "interface" and it´s components, specially when facing anomalies.

[RR_NDB]

Man machine interface should be designed to reduce the threat of "surprises"

Hi,

The man machine interface must allow us to be "intimately in touch" with the machines we are operating.

Some ideas for this thread came from the importance of Redundancy i expressed in this post.

And in many of the 400 posts related to AF447 crash. That was full of surprises may be during the last flight of F-GZCP and after that to most of us.

[Lyman]

RR_NDB

Howdy pard. I appreciate your focus on the interface. I think in the terminology is a trap, maybe. Interface suggests a "give and take", a fluctuation if you will, suggesting of two entities, Man, Machine. At no time should the two present anything but an enhanced platform, without the best performance from both, at all times. Scan, S/A, vigilance from the Human, and consistent electron behavior from the Computer. It makes NO sense to allow one or the other to get "disconnect". A Scan is a continuum, and S/A, the same. It has a history prior, it isn't "up and running" on demand. Therefore, even though the regime is based on two different "processes", a language must exist between the two formats. Cruise flight is a challenge to remain "engaged" for the Humans.

Surprises come from different areas, lack of preparation, lack of data, lack of understanding, etc. A certain baseline "anticipation" is necessary, if at any moment one must fly, one must be ready. The Air France crash is a case study, at least from what we know.

[RR_NDB]

The risks of "consensus"

Hi,

Bear:

The Air France crash is a case study, at least from what we know.

Certainly a rich "case study". A loss of this magnitude and the "surprises" requires attention.

Cruise flight is a challenge to remain "engaged" for the Humans.

I made dozens of high speed night long trips, solo in a "lethal fiberglass jeep" (non shock absorbing body). The technique used to be "calibrated aware" (during 10 hours single lane hwy) was to use the HF radio communicating world wide in phone (SSB). Much safer than hearing music, etc.

The interaction with other radio operators (with the car and HF background noise) allowed the right awareness.

I had two emergency situations (one transmitting and the other receiving -PTT off) without any difficulty to be "immediately inserted in the loop". doing immediate corrections.

In one, a truck hit a horse and i saw the animal flying against my car. In the other an indigent was walking in my lane and it was required to steer (at high speed) so violently the "tires singed". The second almost causing a LOC. In both cases the other operators told my voice sounded different. Like as of gas Helium gas respiration.

I compared when used another (quiet) car without HF gear. Impossible to have the same performance.

Man machine interface is jargon. I used the concept since 1980 in a big project where i was responsible for "testability". I will consider your comment on terminology "trap".

The emphasis i put on the interface on 447 case is "manyfold":

1) Consensus must be checked.

2) The interface is important to the proper (and safer) operation

3) The concept is not sufficiently disseminated IMO

4) It can always be improved. Endless (almost). And must be K.I.S.S.

5) Affects directly crew performance, awareness, etc.

6) Automation (and complexity) requires better interfaces

So, it's a rich field connected to Human Factors. Interesting issue.

[roulishollandais]

dynamic systems in effective aircrafts !

@ RR_NDB

Good luck to this thread !

[Lyman]

@HazelNuts39 Post #1308, Thread Seven.

[/B] Thirty knots drop of IAS in one second is not sufficient to identify UAS. It is not inconceivable that it would occur as a real change of airspeed in a windshear/downburst close to the ground or in the vicinity of the jetstream at altitude. Considering the multitude of possible causes and flight conditions, IMHO the computers cannot reliably identify UAS, but must leave the diagnosis of the problem to intelligent humans. [/B]

2:10:05 ( 04.6 ) : AutoPilot drops out

2:10:06 : "I have the controls"

2:10:10 : STALL/STALL

2;10:14 : "We haven't got a good display,,,"

2:10:18 "...of Speed"

As simply as I can, I note the Pilot is Flying one second after loss of Autopilot. Per the chronology (above) he is doing so without benefit of 'Airspeed' display. Airspeed is a result of controls input, so he begins with a RESULT, not a condition. The result on which he is to base his manual input is verbalized, we assume it is the most important thing to him as well.

For thirteen seconds, he flies not knowing airspeed, and we also assume he doesn't know why airspeeds are bad. Like it or not, he has flown the most important part of the flight of his life, without identifying the problem that will destroy his aircraft. Now well and good, but I will offer a defense.

RR_NDB

Ebb, Flow, Consistency, Continuity. A dynamic condition cannot be entered (looped) ad hoc. We think the a/p was lost due as simple as GUSTS? So in reality, the AIRSPEED WAS NOT UNRELIABLE. It was accurate, and caused the a/p loss. Hazelnuts39 post is instructive, but it is my inference, not his. Much of the original debate on the very first thread had to do with Pilot Flying, and his Awareness.

I posited long ago that the autopilot may have been lost due to simple limit/exceedance. as did many others. Then the argument devolved to LAW, and got ever more arcane from there. Thence to STALL.

The idea in controlled systems is Seamless Transition. With seams, important stuff can fall through. If not UAS, then there is the possibility of Pilot Flying believing he is (remains) in NORMAL LAW, and his zoom becomes rather vanilla flavored, and more understandable.

The autopilot quitting becomes what esteemed members have said: not a big deal. The DEAL was Pilot unawareness. If he was piloting without an awareness of the controls degrade, then we have liftoff. The LAW degrade was annunciated at 2:10:22. 17 seconds after cause, and well into effect.

Facility, Systems, Flow.

[RR_NDB]

On "surprises": There are good ones

Hi,

Surprises "coming from her" may "startle" a pilot. But the "interface" could "help":

When at 02:11:07 Air Speed was reliable again, the System could inform the "good news" to the yet startled crew.

So:

IMHO the System should inform immediately when (after an UAS occurrence) that:

You can now rely on (Pitot's "failure" ceased) Air Speed, again.*



(*) Left and ISIS shows 183 Kts. (RH likely the same) We can assume?

[RR_NDB]

AF447 PM could better communicate with Captain

Hi,

After Captain entered crew told:

"We tried everything". (indeed not true: didn't try stall recover )

And could tell (to Cpt):

We had a "temporary UAS".

Why Captain didn't was better briefed?

Many reasons, we may understand.

One important reason:

Crew (it seems) didn't realize they had a (not important) UAS

Crew (likely) didn't know they had a TEMPORARY UAS. (Anomaly completely disappeared) at 02:11:07)

Perhaps (due UAS known consequences on related indicators, etc.) they created a model of something much more serious: An (unknown) System failure.

HF study may clarify. Anyway, crew could be better helped (by the System). It seems System aggravated the "obsolete Pitot trigger". And contributed to an ACCELERATED DEGRADATION. Perhaps even "misleading the crew" due a design IMHO could (should) be improved.

[Lyman]

Hi RR

Thanks. Doubtful RHS had ever experienced an actual a/p loss in those conditions. So his response likely was precisely as if it was Sim setting. In exercise, one knows the drill, and the actions are "pre-programmed". His taking the controls was rote, by memory, and suffered by Sim experience. He likely did not Pause, and try to become "present" in the moment. Now that may sound "New Age", but it is quite old, "get the picture".

Following his instant "I have controls" was likely an 'expected' need to orient the airframe, hence inputs. Off on the wrong 'foot', could be....?

No one can experience the conditions exactly, but it is instructive to consider them anyway. RRecent posts have illuminated the cockpit environment.

There are at least two schools of thought, separated by a chasm of ego and 'wisdom'. UAS was badly understood, or was 'a walk in the park'. I submit that UAS, even if 'well understood' by the pilots flying, would be a serious problem.

Nothing is more important in high altitude flight than smooth, consistent input and reaction. Bad start, eh? A Sim induced 'muscle memory', that Pitched up an airframe that was already Pitching up on her own? "Lose no altitude".....? Who knows.

What a pilot knows, and 'feels' ( "I feel some crazy speed..."), drives the continued safe operation of the flight. Will we ever know why the PF continued his Pull to and through 1.65 G up to 380? I believe some things are missing that would help us understand why this a/c Stalled.

No one knows the displays....will we ever? Even if the Speeds returned, the flying pilot must re develop some confidence in a system that did, after all, dump the Flight Path into his lap without a 'Heads Up'. We assume.

An assumption can go either way, just as 'assume' good displays, so to, 'assume' bad data on the screens. They did not turn off FD's, nor did they control the throttle levers. They also did not unselect the AUTOPILOT. They were early guinea pigs in the search to get a handle on UAS......

[RR_NDB]

We will have all required information?

No one knows the displays....will we ever?

It will be possible for investigators to conclude (not risking)?

[Lyman]

RR

And so, not knowing these displays, there are conclusions re: PF ? How? Sorry, insufficient data.....

No video exists of these all important reads, yet people condemn, and attack?

Instructor #1 : "Surprises",,,,,,,not good. Also, "never ASSume. Ever. Act with knowledge, you guess, you die...." "Don't make an ASS of U and ME."

Plus, (forgive): "Prior Planning Prevents Piss Poor Performance."

[Lyman]

#7 is busy, and going in several directions. "Interface". This is a word. As such, it deserves respect, both for what the creator of it intended, and what , practically, it adds to the culture, in this case, aviation?

To me it implies transparency, facile communication, and HONESTY. From these flow what you have emphasized (): CONFIDENCE. It is instructive, all these years on, that the dialogue remains unresolved.

It has been said: "And let the Humans figure out the UAS..." Well and good, and they eventually will (17 seconds too late, imo). My point from the beginning is that if the Computer is designed to reject speeds, drop the auto, and DEGRADE, somebody ought to tell the you know....Humans. It is not enough to quit, and expect a cold seat to pick it up without flaws in situational awareness, and attitude attitude.

Linguistics? Familiar. One cannot state a conclusion, (the pilots screwed up) by asking a question. "Why the chronic PITCH UP?" That is unanswered, and predates a logical conclusion, by definition.

As we see, the Pilot flying (for three seconds) appears to voice concerns about the accuracy of the aural STALL-STALL. Was it, actually, correct? It does not matter, the pilot was PREPPED to expect a faux STALL.

I reaffirm that: We know what the DFDR tells us. They did NOT know. Can anyone honestly claim that it is certain the Pilot was aware of the Controls LAW degrade? If only for a second or two, if he thought he remained in Normal LAW, his Pitch UP bobbles the airframe past a human's ability to "feel" PITCH. The displays, especially on his screen are UNKNOWN.

There is no certainty that the confusion that resulted eventually did not start even prior to the a/p loss.

One CANNOT reject the PF's handling, from the report. To do so requires facts. Facts are lacking, the most important facts, of all. Just as it cannot be claimed the Pilots did all wrong, one cannot claim the a/c performed flawlessly. This is fair, and would set the table for improvements to both.

[RR_NDB]

Current DFDR are sufficient?

(17 seconds too late, imo)

PF put the plane into Stall very fast. Fate was sealed rapidly.

Too critical for a System, REQUIRED to degrade GRACEFULLY.

(This seems accelerated degradation): 4 min from normal flight to SL. (with a ALT spike in the meantime).


We will ever know what really happened?

[Lyman]

Hi RR

The DFDR is a wonderful tool, as is the CVR. It is tempting to enjoy the luxury it affords us in hindsight. It played no role in the disaster. NONE. To the extent that anyone believes it will cement a complete knowledge of the cockpit events it is useless (but will help a partial picture). It also is useless and worse, if people misunderstand the exact events, the cheeses, and allow it to cloud an objective view.

We see how important is the language of the events, and the "reporting" of the language. To this day, there are those who have a reaction to "En ligne de Vol", and reject its nuance, in favor of bastardizing its meaning to cement a foregone conclusion.

The Human accelerometer is in the butt cheeks, and the computer in the Inner Ear. How ironic and frustrating that had the pilots been instantly privy to a readout of the guts of the boxes, this thing would not have happened. I think PF was trying doggedly to incorporate his human sensing skills into his flight Path. "I feel some crazy Speed....". Vitesse feu. Don't go there cowboy.

In that, there be demons.

BUSS takes us in the direction of the "Problem solving by computer", when the human is not equipped to figure things out, either due to lack of capacity, or shortness of time. OR the inability of the Flight computer to find the words, and the pathway, to tell him/her. Quickly.

[RR_NDB]

BUSS

Hi,

Bear

And all this stuff has it's inherent limitations. BUSS AFAIK would be useless.

Let me ask you:

From ice crystals noise (heard on CVR) til apogee how many seconds elapsed?

UAS onset certainly was well before Law change. So, if they had an UAS detector (a simple resource capable to precisely inform the impending Law change) they could had be warned how many seconds before zoom climb?

[Lyman]

RR

I think the ice crystals theory is overblown. First off, these crystals are "microcrystalline", and do not resemble Hail, or other "Solid" particles. Small droplets of water would make a great deal more noise than this "fog". We were subjected to the same professional "conjecture" re: Fuel. "Hitherto unknown characteristics of water ICE".

Flight at this height and in this region has been going on for SIXTY years. Without aircraft falling out the sky. I am sceptical. (Imagine that!).

Shall we have a listen? What shall we think, then? Is it important enough to drop an airliner, but so scary that the Public shall not hear it, lest they faint?

BEA? Hello?

I like BUSS. It int perfect, but more than a few actual experts think had 447 been so equipped, we'd be playing bridge and smoking cigars, not agonizing oer the 'interface' .

[RR_NDB]

UAS causes

Flight at this height and in this region has been going on for SIXTY years. Without aircraft falling out the sky.

With most crews respecting WX. All other flights deviated around this time.

Indeed, the plane in normal position.

The Pitot's deserve an R&D. Or be complimented by other means to have even a degraded redundancy.


We don't need to know what the plane hit (whatever) but vaporized it shortly. The System didn't wait. IMO there is a "timing" issue that could be improved. Posted this earlier.

Anyway the UAS processor i envision could help to (almost) completely avoid similar cases.

If ACARS could participate in the R&D would be great. (Data gathering to design "calibration")

[safetypee]

The initiating question infers that increasing technological sophistication has changed the balance of the man-machine interface.
The interface represents a process which takes place within a situation (context); thus any change in the process can originate either from man or machine, or from the situation. However, none of these are independent; there is human input in all aspects.

One view such a system is to use the SHEL model of human factors. Normally the focus is on the central (L), but from a technology viewpoint (H) the links remain the same. The limits of SHEL are in its simplistic view; in reality all constituent factors in each category will have some interface with the other factors, e.g. autopilot alt hold mode (H) will link with the effects of weather (E) & (S) in the choice hard/soft ride vs accuracy – a human decision in design (L) and procedures and training (S) & (L).
Thus the balance sought involves a highly complex process (a chaotic system) – where a small change in input can have an unexpected disproportionate result.

The behavior of complex systems can be analyzed with techniques such as FRAM, and FRAM intro.
Note the four steps:-
- Identify and describe essential system functions, and describe these by six basic parameters.
- Describe the context.
- Define the functional interactions
- Identify safety barriers and specify required performance monitoring.
A technological comparison: – describe the automatic system and use, the usable conditions; define the dependencies and interactions, and the safety barriers. The human is involved in these and in the basic assessment parameters – input, time, control, output, resource, and precondition; an example ‘risk assessment’.

We need not stray into higher science with these ideas, as in the broadest sense they are like managing everyday life; e.g. humans use of fire – there are advantages and hazards, we elect to use it and take precautions, fireproofing, water, restricted situations, and have procedures for guidance. The human continually assesses and adjusts activity as the situation changes; the objective is to remain in control of the situation.

In many cases it’s the increasing complexity of operational situations that demands an increase in technical capability; both operations and capability are driven by economics. The changes (input to the system) can either be proactive – the pilot wishes to achieve an objective by using automation, or reactive where pilot activity is required – normal and non-normal situations – again the objective is to remain in control of the situation.
The situational aspects are in most (all) scenarios, and where these require a change of action, i.e. a malfunction (technology, human, or situation), the human has to understand the changed situation and its significance within the larger complex situation, and then choose a revised course of action. This will be an iterative process.

The above is a very high level view; however most events with technical / operational interfaces can be viewed this way, e.g. accident investigation.

As much as technology has changed, so too may have the human due to the changes in the social environment, education, career expectation, and interaction with complexity. This does not automatically represent a change in training standards. Aspects of the context also change; economic pressure, airspace accuracy, operational need.
In addition we may be biased by the current salience of technology related accidents. The industry has a very low accident rate thus any significant event will stand out. In a complex system just because increasing automation use is seen as an input, this may not mean that it is a dominant cause of the ‘accident’ output.

[RR_NDB]

Technology for better Quality of Life*

Hi,

safetypee,

Thank you for your dense comment. Very rich and motivating.

The theme is fascinating. I did study Technology (starting in 1967) and increasingly became interested in the "Human Factors", and the non tangible aspects.

My view is Technology as a just a tool to allow us to:

1) Do more (efficiency)

2) Do it better (effectiveness)

3) Do it safer

4) To help for Quality of Life

All this require proper use of it (technology). Requiring adequate understanding, (of what you are doing, using, etc.). Adequate in some adverse situations could mean: Deep understanding.. Just (operation) training could be insufficient.

I will study the links you provide. As a researcher (working in R&D) currently working in 2 projects (and a family of products) the concepts of this thread are also important to me. I visited your thread on Monitoring & Intervention and will be a pleasure to do an effort with you, may be useful to professionals who emphasizes Safety. As a way to preserve human life and have better Quality of Life.

* And last not least to do more, including high ROC to reach new heights in non tangible and also in tangible aspects.

In a complex system just because increasing automation use is seen as an input, this may not mean that it is a dominant cause of the ‘accident’ output.

Sure.

The initiating question infers that increasing technological sophistication has changed the balance of the man-machine interface.

I see the "interface" as being necessarily SOPHISTICATED in the meaning Leonardo da Vinci put: Simplicity is the ultimate sophistication.

My feeling is the "interface" don't receive the "required attention", the necessary investments. Complex Systems to be operated safe need you can be in control (full) control if necessary. This requires a lot of "features" in the Project.

What we need is "Fault tolerance and Graceful Degradation" (System + Man). With a good "interface" the man can do better. With less stress on his shoulders. When extreme situations occur. Anomalies of all types simply occur. And you not need to be a Chuck Yeager or Bob Hover. "Trained" to the highest requirements.

So, the theme is vast. My idea is just put some light (i consider this important to us) on the interface because it may play a role in our Safety. Important for our life. As pilots, engineers or just SLF.

I consider important to share concepts we are convinced as important to many people. Concepts obviously not even mentioned in the marketing of the products we use.

In aviation IMHO many incidents and accidents seems received "direct contribution" from "lack of investments" in good man machine interface. Pilots vulnerability as a result. This seems not fair.

LOC (AF447 crash, Fukushima plant, etc.) may be considered as design failures where problems were a consequence of human limitations (of several types, including $) that led to disasters. Three GE engineers quit Fukushima Daichi project when realized the project was not being made in the way they considered adequate.The Tsunami was much higher than (the design specs.) and the APU's were flooded and failed triggering the LOC. In AF447 case atmospheric conditions triggered a cascade of events. But you also must think the crew triggered the disaster by entering WX. Or Fukushima was triggered by lack of enough investment (placing the APU's higher). Always there will be a trigger.

But some designs fail smoothly. Giving better chances to be saved or even, survive. Accelerated degradation has to be avoided. (By design, maintenance and operation). And it's possible (in many cases) to do much better. You need to be careful. And well prepared.

[Terraplaneblues]

Technology and Quality of Life

Misguided technology? We now have incredibly complex airplanes, where untold man decades have been spent on whether or not the throttles move or a if a computer should emit information in red or amber, that fly so slowly the passengers are in beds and the pilot unions are at odds with the authorities regarding sleep deprivation/life quality issues
v interesting thread btw.