Author: cjois

Cognitive Psychology in Aviation

~ cjois

Failures in prospective memory (PM) are the reason why we fail to perform intended or required actions. There is increasing interest in the topic of prospective memory and the reasons for failures of such memory. While this subject is still under intense debate, according to one school of thought, prospective memory recall is driven by the process of monitoring. Another view is that it occurs as part of spontaneous retrieval.

In either case, the intention for the planned task is retrieved which then allows for action. Distractions are one source of why action is forgotten. Interruptions of any kind can be a cause (Shorrock, 2005; Sternberg & Sternberg, 2016). A telephone call or request for information can be sufficient cause to not return back to the ongoing task. The variety of peripheral tasks that controllers need to perform often conflict with the primary task of maintaining separation. Such tasks could include scanning displays, accepting aircraft, gathering and relaying weather advisories and responding to pilot requests.

Prospective memory recall is predicated on cues. A cue or trigger is necessary for prospective memory to work. As described earlier, to recall the intent, the human mind constantly polls for such items. When polling is not invested in, such as when we are preoccupied with other task(s), then the intent is not recalled and action is termed as ‘forgotten’. Under another school of thought, spontaneous retrieval occurs on account of a system within our brain that causes automatic retrieval of items at the appropriate times. Once again, when tasks preoccupy, spontaneity drops and we tend to forget the intent. Proximity, recency and task regularity could all affect prospective memory (Vortac, Edwards & Manning, 1995).In the context of ATC, prospective memory failures can prove to be catastrophic.

The incident at San Francisco of a controller positioning an aircraft on the runway for takeoff, forgetting about it, and further clearing an aircraft to land on the same runway is a case in point (Loft, 2014). They can affect controller actions such as separation, scope monitoring or performing other tasks such as flight strip updates, aircraft transfer, peer collaboration and shift transitions. Inaccurate recall of information on a strip, failing to observe conflicts and failure to annotate strips correctly are all examples of PM failures. Controllers may intend correctly but then fail to follow through on that thinking because they simply “forgot to do so”. In the realm of ATC, cues are either based on time or based on events (Loft, 2014; McDaniel & Einstein, 2007). However, monitoring takes a cost in the form of “brain cycles” and therefore impacts performance. Such impacts could come in the form of slowing down a certain action in order to devote time to monitoring.External cues are an effective way to mitigate the risks of prospective memory failure (Vortac & Edwards, 1995).

Memory aids are useful and can be any tool, prop or other aid that could serve as a reminder (FAA Video, 2015). They need to be incorporated into the routine though and not be ad-hoc. Mnemonics and placards are one way to avoid prospective memory errors (Loft, 2014; Stein, 1991). Using free text to jot down notes is another option. Memory aids must be effective. A good example from the video is that of holding a strip in hand as a reminder when there is a vehicle inspecting the runway.

There is a growing interest in having the system alert and warn if an action is overdue. The sophistication available today makes it possible to code rules into the system and have it warn the controller. However, this may lead to the same type of over dependence on automation and sense of complacency that we find occur in pilots. 

References

Federal Aviation Administration. (2015, September 02). Retrieved April 25, 2017, from https://www.faa.gov/tv/?mediaId=1151

Federal Aviation Administration. (2015, September 02). Retrieved April 25, 2017, from https://www.faa.gov/tv/?mediaId=1152

Loft, S. (2014). Applying psychological science to examine prospective memory in simulated air traffic control. Current Directions in Psychological Science, 23(5), 326-331.

McDaniel, M. A.. & Einstein G. (2007). Prospective Memory. Thousand Oaks: SAGE Publications. Retrieved from https://ebookcentral.proquest.com/lib/erau/detail.action?docID=996509

Shorrock, S. T. (2005). Errors of memory in air traffic control. Safety science, 43(8), 571-588.

Stein, E. S., & Federal Aviation Administration Technical Center (U.S.). (1991).

Air traffic controller memory: A field survey. (). Springfield, Va;Atlantic City International Airport, N.J;: Federal Aviation Administration Technical Center.

Sternberg, R. J., & Sternberg, K. (2016). Cognitive psychology. Nelson Education.

Vortac, O. U., Edwards, M. B., & Manning, C. A. (1995). Functions of external cues in prospective memory. Memory, 3(2), 201-219.

Fatigue on the FlightDeck

~ cjois

Generally speaking, ‘Fatigue’ is predominantly influenced by sleep loss and circadian rhythm disruptions (Salas & Maurino, 2007). Fatigue is not a problem that is specific to one area of Aviation. All forms of aviation are at risk. While much of the research focuses on long-haul aviation, a lone GA pilot battling cognitive overload can quickly turn into a fatigue-crisis (Guastello et al., 2012). In addition, few General Aviation pilots have adequate training or resources to detect onset, and/or remedy, Fatigue (Harris et al., 1995) 

GA would benefit from a simple model that can consume simple parameters such as flying conditions, route of travel,  pilot health, sleep history, pilot flying history etc. and provide a risk score to a pilot based on which a decision to fly can be made.

 I believe that even knowing that there is a level of risk given all the parameters that exist is a great thing to have. The IMSAFE checklist is good, however, when one goes through the checklist  it is indeed hard to have a true assessment. I have seen many times that GA pilots run through teh checklist quickly and decide to fly. However, I have often thought whether a GA Pilot would reject a decision to fly based on knowing that the pilot has had a growing sleep deficit over the past week or month; or whether a forecast indicated sharp temperature drop between altitudes (indicating turbulent air in that region) combined with a sleep deficit should deter a pilot from flying that day. 

Fatigue can occur pretty rapidly even in a fully fit individual in a GA cockpit (with little automation). When combined with other factors, the situation can unravel very quickly (Salas & Maurino, 2010). I know from experience that there have been days when I have gone out for a recreation flight in the local area and after battling turbulent air in single piston aircraft for 90 minutes, I have landed and felt really worn out from the experience – add a situation of 4-5 hours of sleep the prior night and this fatigue multiplies multi-fold.

They highlight the mission-critical dependence on human performance in some industries or professions. I don’t believe that this dependence, or impact,  is even comprehended by most outside these professions. I have felt that even working for an airline experiencing the pressures involved in keeping a real-time operation running optimally does not fully clarify the complexity. The body of literature on this topic is immense and just reading a few of the papers (infinitesimal, compared to the literature available) on the subject of shift scheduling in some industries has evolved my thinking on the topic. The references below indicate some of the papers that I found very helpful in getting to understand some basic facets of this subject. The integration of fatigue models into scheduling algorithms was a very interesting topic (Ta-Chung & Cheng-Che, 2014). One conclusion I draw… scheduling in some industries is not merely about managing time and people. It is multi-dimensional and mission-critical. 

References

Barton, J., & Folkard, S. (1993). Advancing versus delaying shift systems. Ergonomics, 36(1-3), 59-64. doi:10.1080/00140139308967855

Caldwell, J. A., Mallis, M. M., Caldwell, J. L., Paul, M. A., Miller, J. C., Neri, D. F., & Aerospace Medical Association Fatigue Countermeasures Subcommittee of the Aerospace Human Factors Committee. (2009). Fatigue countermeasures in aviation. Aviation, Space, and Environmental Medicine, 80(1), 29-59. doi:10.3357/ASEM.2435.2009

Guastello, S., Boeh, H., Schimmels, M., & Shumaker, C. (2012;2011;). Catastrophe models for cognitive workload and fatigue. Theoretical Issues in Ergonomics Science, 13(5), 586-17. doi:10.1080/1463922X.2011.552131

Harris, W. C., Hancock, P. A., Arthur, E. J., & Caird, J. K. (1995). Performance, workload, and fatigue changes associated with automation. The International Journal of Aviation Psychology, 5(2), 169-185. doi:10.1207/s15327108ijap0502_3

Knauth, P. (1996). Designing better shift systems. Applied Ergonomics, 27(1), 39-44. doi:10.1016/0003-6870(95)00044-5

Salas, E., & Maurino, D. E. (2010). Human factors in aviation (2nd ed.). Boston, Mass;Amsterdam;: Academic Press/Elsevier.

Smith, L., Hammond, T., Macdonald, I., & Folkard, S. (1998). 12-h shifts are popular but are they a solution?International Journal of Industrial Ergonomics, 21(3), 323-331. doi:10.1016/S0169-8141(97)00046-2

Ta-Chung, W., & Cheng-Che, L. (2014). Optimal work shift scheduling with fatigue minimization and day off.Mathematical Problems in Engineering, doi:http://dx.doi.org/10.1155/2014/75156

Task Management on the FlightDeck

~ cjois

One of the highlights of this week’s readings was the aspect of coherence (Salas & Maurino, 2010). For coherence to be effective, pilots need to have a deep understanding of the underlying logic, systems and automation impacts. The cognitive load has grown significantly over the years and continues to grow even faster today. While it is possible to acquire and display a lot more data in the form of meaningful information on extra-rich customizable displays, an important consideration would be to understand at what point this reaches practical human limits.

In the end, there is no limit on information that can be provided or assimilated by the crew. What matters is how much can be meaningfully assimilated in limited amounts of time (many times minutes or seconds) and most importantly, acted upon to achieve an outcome.

Information overload occurs frequently and very rapidly. My observation is that a few different visual and aural call-outs occurring simultaneously (example: a GPWS callout and a TCAS alert) are enough to cause overload in an otherwise quiet flightdeck. If they occur to be in conflict its worse.

With rising stress levels, saturation occurs faster (Salas & Maurino, 2010).  The ability to filter, and hone in, on important elements of information being presented is the answer to avoiding overwhelm. I believe that this ability is a function of two things – a) experience and b) personality.

CJ

References

Salas, E. & Maurino, D. (2010). Human Factors in Aviation (2nd Ed.). New York: Academic Press.

The push for No-Code software

~ cjois

About 3 decades ago, there was a time when the business world pursued the automation of software engineering work. It was believed that computers could be used to automate the development of very software that would run computers. CASE – computer aided software engineering – was invested into, attempted in multiple ways. Millions of hours were invested into making it a reality. Those in the industry know where that went

We are back to it again… we just call it fancier name now – ‘No Code’ software. I firmly believe that software engineering must be simplified. Software is pervasive today. There is hardly an area of human life that software does not touch. It’s absolutely imperative that it become a whole lot easier to manage the engineering and subsequent maintenance of software.

Software is basically code. Code that tells computing resources what to do. So there is no such thing as ‘no-code’. Yes, we may aspire for the day that humans wont write the code or wont be writing as much code as in the past. However the more pervasive and extensively software is used, the lesser the chance that no-code will be a reality. Less code on the other hand is a better aspiration.

The software industry has struggled to even realize the benefits of software re-use yet. A simple assessment of a small sample of firms using software or building software will indicate that there are engineering teams still writing their own exception handlers, notification mechanisms. There is constant push needed even today to uphold the principles of object orientation and procedural programming. A significant majority of the software engineering still occurs by accident. The situations where engineering tools, stack components, patterns are chosen through thinking and deliberation are far and few. There is a lack of discipline and respect for software lifecycle models and associated artifacts. When reuse at the most basic levels is missing within teams, let alone within groups or organizations seeking rationalization of the practices at an industry level is perhaps asking for too much.

It is also surprising that this perhaps is the only industry where there is a drive to commodify a specialized engineering skillset (albeit that not too many in the industry may represent an engineering approach to software creation) into ‘nothingness’, and undermine the critical value of the engineering lifecycle. In no other industry has this happened in the past. No one ever says that we allow the car buyer to manufacture her/his own car or allow a smartphone user to build their own smartphone or allow the local community to build their bridge or lay their own electrical lines or sewers. It is mind-bogging that this notion lets allow users to build their own software. It’s one thing to increase user participation in the development of systems that serve them. Thats what ‘agile’ as a process is meant to do. The reality – agile has done little or nothing to help with it. The more the industry has spoken of agile, the fewer the outcomes that have resulted. In fact, it’s found that the higher the use of an agile mindset’ the lesser the discipline in building ‘production strength’ software. Another reality – users really have not enough time to dedicate themselves into the daily stand-ups and frequent exchange of software developed. They have full-time jobs.

Users are having difficulty using software that has been developed. Some may attribute that to the fact that ‘elite professionals’ sitting in the backroom called technology dev or IT do not understand what the users are asking for or how they will use it. Indeed it may be somewhat attributable to that. But the answer to that problem is not to say that we push the entire onus of engineering systems to the users. As it is the supposed ease of acquiring so called ‘cloud based capabilities’ brought about an era where business users were buying systems, applications, components at their will because software vendors were now knocking on their door instead of approach technology departments. The sale may been easier. However what that led to was a whole bunch isolated software systems that were islands in themselves. No external software vendor understands an organization’s entire software portfolio and can find methods to seamlessly integrate their new introduction into the existing ecosystem. They have to rely on internal software teams or departments for that help. Some can call it an elite group that holds the keys to the ecosystem, but what is new about that. Doesn’t finance hold the keys to the books of the company?, Doesn’t marketing do the same for lead generation?, doesn’t operations do the same. Nowhere does anyone ever speak about pushing those responsibilities out to the hands of users.

In summarizing, this comes down the distinction between giving the users the ability to plug their appliance into a wall socket versus letting them build their generation station. Looked at another way, we aren’t even sure how many users (i am sure there are some) want to build their own systems and sustain them.

Building and managing ‘production strength’ systems or the infrastructure beneath them is no small task. It is very inspiring to speak about no-code software and I am not saying that someday this wont be reality. However, it’s important to remain realistic about whats possible today given precedence and current context.

CJ