Crew Communication

Communication among the crew is crucial for safe operation. In fact, crew resource management is an area of training in aviation that attempts to avoid human error that can have devastating effects on air safety. When IA systems are used in place of humans, seamless and unambiguous communication is of utmost importance. This is because poor or nonexistent communication between the existing automation/user-interface and crew has been reported as a significant factor in many accident inves- tigations. Hence, one has to assess the various kinds of human-automation interaction that can take place in a cockpit.

Communications can be as simple as sharing and acknowledging information giving specific direc- tions in both verbal and non-verbal form. For instance, pilots may physically point to a reading to indicate an anomaly or may nod the head as an acknowledgement. Further, since interactions are often multi-step, the context of the conversation has to be tracked by the IA system. For instance, pronouns may be used following a discussion, like “reset that” . While such interactions are natural to humans, the automation shall be built with the ability to precisely recognize the voice, accent and gestures by the crewmate. IA communications, alerts and responses should not cause undue annoyance or distraction to the human crew mate. Cockpit voice recordings of various air disasters tragically reveal first officers and flight engineers attempting to bring critical information to the captain’s attention in an indirect and ineffective way. By the time the captain understood what was being said, it was too late to avert the disaster. Hence, when designing an IA system, the way it communicates with the pilot – both when it is in the PM and PF role should be explicitly stated as well as elaborately simulated and tested.

Further, one of the common concerns with automation is “automation surprises”, i.e. situations where crews are surprised by actions taken (or not taken) by the automation. The IA system shall unam- 46

4.5 Requirements Categorization

biguously communicate what it is doing to the pilot as well as explain the rationale and intent of its actions when queried by the crew mate, in a way that can be “understood” by the human. Hence, one of the aspects when defining requirements of an IA system is to obtain agreement before it performs any action that are not prompted from the crew mate; same way, if an action is called out by the pilot, the IA system shall either confirm after performing the action, or clearly explain why the action was not taken.

Let’s consider a concrete scenario of applying speed brakes, discussed in Flight Controls category. When we consider a “pro-active” IA system that prompts the PF before performing the action:

While the role of IA system is PM, when the conditions to deploy speed brakes are true, then message to PF shall be ‘Can I deploy the speed brakes’.

On the other hand, if the IA is not proactive, i.e., it has to wait for the PF to give directions on deploying the speed brakes, then the requirement of such a system shall be:

While the role of IA system is PM, when the conditions to deploy speed brakes are true and message from PF is ‘deploy speed brakes’ and speed brakes are deployed, then the message to PF shall be ‘speed brakes are deployed’.

In the event of a problem or erroneous situation, the IA system shall be capable of clearly communi- cating the action and the rationale for it.

While the role of IA system is PM, if the speed brakes have not been deployed due to hardware error, then message to PM shall be ‘speed brakes have not been deployed, since there is a hardware error with the speed brakes’.

When the IA system is prompted by the PF to deploy speed brakes, but the IA system decides that it is not the right time for the action since some necessary conditions are violated, say air speed is too high, then it shall communicate that clearly:

While the role of IA system is PM, when the conditions to deploy speed brakes are false and the message from PF is ‘deploy speed brakes’ , the message to PF shall be ‘The air speed is too high. Are you sure you wanted the speed brakes to be deployed? It could be hazardous’.

Whether the pilot can override such advice from the IA system and command it again to deploy the speed brakes depends upon the level of automation and authority for the IA system. In any case, the IA system shall also be capable of repeating the explanation, when asked by the PF. In situations where the rationale is not immediately communicated, when prompted for explanation from the PF, the IA system shall be capable of providing a reason. For instance:

While the role of IA system is PM, when the previous message to the pilot is ‘speed brakes cannot be deployed’ and query from pilot is ‘Why’ or ‘What‘s wrong’ , then the message to the pilot is ‘aircraft has to be in approach mode for speed brake deployment’.

When the IA system is the PF, then the IA system may be designed to apply the speed brakes as 47

4 SAFETY RELEVANT REQUIREMENTS IN IA SYSTEMS

appropriate and just inform the other crew mate. Again, depending upon the type of advances of the IA system, the requirement may vary. In its simplest form, a typical requirement shall be:

While the role of IA system is PF, when the conditions to deploy speed brakes are true, then speed brakes shall be deployed and message to PM shall be ‘speed brakes have been deployed’.

These phrases and sentences used in the above requirements are just used to illustrate the possible communication patterns. However, when defining the requirements of a real IA system, the protocol of communication that typically occurs in the cockpit has to be adequately accounted, so that the message is understood and interpreted precisely by the pilots.