The human-factors gap in detect-and-avoid procedures – what happens after detection?

By Manuel Ignacio Pérez Pan

A traffic alert can be entirely correct and still fail to prevent an unsafe encounter. The aircraft has been detected. The warning has reached the control station. What remains uncertain is whether the remote crew can do enough with that information, in the time available, to change the outcome.

For beyond visual line of sight (BVLOS) operations, that uncertainty deserves as much attention as detection performance. A pilot expected to act on detect-and-avoid (DAA) guidance must first recognise what requires attention, understand the developing conflict and select a response that the aircraft can actually execute.

Depending on the installation, that may involve interrupting a payload task, changing the active control window, coordinating with air traffic control (ATC) or working out which automation mode currently has authority. The aircraft must then receive the command and achieve the intended flight path. A sensor specification tells us very little about how reliably this whole sequence will work during an ordinary mission, let alone an abnormal one.

So what should we be asking the remote pilot to achieve after the alert?

The question is already present in the standards work. EUROCAE’s ED-271A, published in November 2024, addresses DAA against conflicting traffic for certified-category remotely piloted aircraft systems (RPAS) operating under instrument flight rules in airspace Classes A to G. Its public revision description specifically includes assumed remote-pilot behaviour in relation to remain-well-clear alerting and guidance. Human response is part of the performance argument. The standard’s scope is specific, however; it cannot simply be carried across to every low-level BVLOS operation. [1] Between the response assumed by a design and the response achievable in service lies the human-factors gap. It need not begin with a defective sensor or an inattentive pilot. Guidance may be understood but awkward to enter. A command may be transmitted while another flight mode prevents the expected manoeuvre. An alert may draw attention successfully yet leave the crew uncertain about the urgency. These are interactions between equipment, procedures and people. Testing the components separately can miss them.

ICAO gives this discussion an aeronautical foundation. Annex 2 addresses the rules of the air, while Annex 19 establishes the overarching safety-management framework. ICAO’s RPAS Concept of Operations for International IFR Operations considers DAA alongside command and control (C2), remote pilot stations and human performance. The version publicly linked by ICAO is marked as an unedited publication not approved in final form, a qualification that matters when using it. Its definition of DAA encompasses recognising conflicting traffic or other hazards and taking appropriate action. Read on those terms, the concept requires us to follow the response through to its effect on the aircraft. [2] [3]

ICAO’s Human Factors Training Manual, Doc 9683, and Manual on Remotely Piloted Aircraft Systems, Doc 10019, provide further background, alongside the Safety Management Manual, Doc 9859. None should be cited as evidence for a universal human reaction time without identifying a provision that actually supports that claim. A useful assessment has to describe the task, the interface and the operating conditions under which a response is expected. [4] [5]

That may sound obvious until the term “response time” appears in a test report. Does the clock stop when the pilot acknowledges the warning, selects a heading, transmits a command or starts turning? Does it stop only when the aircraft has achieved the required avoidance effect? Those measurements answer different questions. A rapid acknowledgement can coexist with a late manoeuvre.

The starting point matters just as much. First detection is not necessarily the point at which a usable track exists. Track formation, processing and communications can consume part of the available margin before the pilot sees anything. Once the alert appears, interpretation and any required coordination take place within what remains. Some activities overlap; others must wait for an earlier step to finish. Adding a set of independent average delays can therefore give an incomplete picture of the encounter. The assessment needs the actual sequence, including the combinations of delay that the operation could experience, and a stated endpoint against which success can be judged. Nor is time to closest point of approach a countdown that the pilot is free to use in full. The aircraft may need to begin its manoeuvre well before that point. A relevant well-clear boundary may be reached earlier still. Relative motion, vertical development and aircraft performance all affect when action must begin; terrain or other operating constraints may narrow the available options. Without those conditions, a detection range cannot establish how many seconds the crew has to decide.

NASA’s Collision Avoidance, Self-Separation, and Alerting Times (CASSAT) study examined timing alongside the way alerts were presented. The pilot phase of the study evaluated alert times of 40, 60 and 75 seconds within its configured DAA concept. It also compared two alerting structures. Participants preferred one structure, with the report recording objections to the alternative’s use of two red icons. These were experimental settings and user findings, rather than general response-time requirements. They show why evaluating the warning’s timing without its presentation leaves part of the task unexplored. [6]

There is positive evidence, too. In a Federal Aviation Administration study by K. W. Williams, 32 instrument-rated pilots flew a simulated unmanned aircraft on a firefighting mission, locating and photographing hotspots. Five intruder aircraft generated traffic alerts. Three encounters called for monitoring without manoeuvring; two required avoidance. The experiment examined suggested manoeuvre information, alert placement and aural alerting. Under the full-mission conditions tested, the effectiveness of the display with suggested manoeuvre information was retained, and the reported results did not warrant changing the Phase I minimum operational performance standards (MOPS) alert timing requirements. [7]

That finding deserves space in a discussion of human limitations. Decision support can help a crew perform the task successfully. The difficulty is preserving the conditions on which that success depends when a tested concept becomes an operational service.

Take a change in duties. A pilot who previously monitored flight and traffic may be assigned responsibility for payload quality as well. The DAA equipment can remain exactly as tested, yet an alert now arrives while the pilot is engaged in a different activity. Or the traffic presentation may be moved to a secondary display to accommodate a new mission application. Such changes warrant examination because the human task has changed without a corresponding change to the sensor’s performance specification. The case for carrying over earlier evidence needs to address that difference.

The type of alert also matters. Traffic awareness, remaining well clear and collision avoidance have different purposes. NASA’s work on DAA integration has examined the relationship between an earlier well-clear function, a final collision-avoidance layer and compatibility with ATC and existing airborne collision-avoidance systems. The terminology and allocation depend on the architecture being used. For the remote crew, the practical requirement is to understand what the particular alert asks them to do. [8]

A colour, tone or label has operational consequences. The pilot needs to know when continued monitoring is appropriate, when a manoeuvre is needed to preserve well clear and when the immediate threat requires the applicable collision-avoidance response. Acknowledgement should have a defined meaning within that sequence. If it silences a tone, it should not be mistaken for acceptance of guidance; if it initiates a command, that consequence must be clear before the encounter. Recording an acknowledgement as a successful intervention risks ending the analysis before the safety-relevant action has occurred.

Mica R. Endsley’s work on situation awareness offers a useful way of examining what happens between seeing a symbol and acting on it. Her framework distinguishes perception of relevant elements, comprehension of their meaning and projection of their future state. Applied to remote DAA, the pilot may notice the traffic yet still lack enough context to judge its relevance or anticipate how the encounter will develop. Endsley’s work with E. O. Kiris also addresses the out-of-the-loop performance problem in automation. [9]

For a control-station designer, this leads to a specific question. Can the pilot understand the relationship between the unmanned aircraft, the conflicting traffic and the available manoeuvre without assembling it from several unrelated windows?

Endsley and Debra G. Jones develop the design implications in Designing for Situation Awareness. The book’s third edition, published in 2025, covers issues that include remotely operated vehicles, uncertainty, alarms and automation. That emphasis on the user’s understanding is relevant to DAA displays: showing more data does not necessarily make the impending conflict easier to comprehend. The operational application is to organise information around the decision the pilot must make, while retaining access to technical detail where it helps diagnose a problem. [10]

A traffic symbol, for example, can look equally precise whether it represents a recent measurement or an extrapolated position. The pilot may need to know that updates have become stale without having to inspect an engineering page during the encounter. At the same time, displaying every uncertainty metric permanently could make the immediate task harder. The design has to identify which changes in data quality affect the action being supported and make those changes recognisable. The relevant indication has to be usable during the encounter, including when the pilot has little time to look away from the main flight display.

The same difficulty appears when several surveillance sources are fused. A merged track can reduce duplicate information, but it should not conceal a deterioration that changes how much confidence can be placed in the predicted trajectory. Showing the sources separately introduces a different risk: the pilot may have to decide whether two symbols represent one aircraft. Integrators need to test how the display behaves as sources disagree, disappear or recover. Nominal screenshots reveal little about those transitions.

DAA technology already reaches well beyond displaying surveillance returns. NASA’s DAIDALUS, the Detect and Avoid Alerting Logic for Unmanned Systems library, is an open-source reference implementation of functional requirements associated with RTCA DO-365. It includes detection, alerting and manoeuvre guidance. NASA’s formal-methods programme documents related research on sensor uncertainty and dynamic well-clear volumes, with contributions from specialists including César Muñoz, Anthony Narkawicz, Aaron Dutle and Maria Consiglio. That work connects the mathematical assessment of an encounter to guidance about possible responses. [11] [12] For an operator, the next question is what the guidance has taken into account. A manoeuvre assessed against the traffic in a DAA calculation may still need to be evaluated against terrain, obstacles or other constraints outside that calculation’s scope. If the remote pilot is expected to perform those remaining checks, the integration has assigned a further task to the crew. Its information needs and time cost belong in the assessment. Otherwise, guidance can appear authoritative while leaving an essential part of the decision unresolved.

Formal verification is valuable precisely because it can establish defined properties under explicit assumptions. The surveillance feed, the installed display and the aircraft’s response each need their own evidence. So does the interface through which the crew acts. Keeping those boundaries visible allows the assurance work on an algorithm to be used properly within a wider safety case.

The Airborne Collision Avoidance System X (ACAS X) family uses explicit collision-avoidance logic. MIT Lincoln Laboratory describes surveillance and tracking used to estimate the relative state of nearby aircraft, followed by evaluation of possible actions and the provision of avoidance guidance when needed. ACAS Xu is tailored to unmanned aircraft. RTCA’s SC-147 currently reports completed work on ACAS Xu and ACAS sXu, for unmanned aircraft systems (UAS) and small UAS respectively, with work continuing on ACAS Xr for rotorcraft and advanced air mobility applications. SC-228 separately covers standards work for DAA equipment, C2 data links and navigation. [13] [14] [15] These developments make “latest-generation DAA” too broad a description to carry much operational meaning on its own. A sensing product, an alerting function and collision-avoidance logic can all contribute to a system, but they leave different responsibilities with the crew. Publication of a standard also does not establish approval of every installation that references it. Buyers need to know which function they are acquiring and how it will work with the aircraft and control station they intend to use.

The response itself warrants scrutiny. Sydney M. Katz and colleagues, including Mykel J. Kochenderfer, examined speed-change collision-avoidance advisories in a 2022 study using modelling and Monte Carlo simulation. Within the encounter models evaluated, speed advisories reduced collision risk but performed less well in safety and operational efficiency than the horizontal and vertical alternatives. That result is bounded by the models studied. It is nonetheless a useful reminder that a seemingly conservative action still needs to be assessed against the trajectory it produces. [16]

Stopping the mission does not necessarily resolve the encounter.

A hold, return or landing command may be appropriate in a defined contingency. Its suitability as an avoidance response depends on the aircraft, the geometry and the surrounding constraints. Training should examine whether the pilot understands the distinction when using familiar contingency controls during a traffic encounter. The crew needs to understand what those controls will make the aircraft do, and whether that behaviour addresses the traffic threat. Procedures should settle that relationship for the approved operating concept; the pilot should not be left to improvise it from the name of a button.

On the sensing side, current products support different ways of obtaining the traffic picture. Echodyne describes EchoFlight as an airborne DAA radar measuring azimuth, elevation, range and Doppler velocity, with interfaces for flight-control and autonomy integration. uAvionix describes cooperative surveillance capabilities alongside Casia G ground-based computer-vision sensing for non-cooperative traffic. These are the manufacturers’ descriptions, useful for identifying the sensing approaches offered. They do not independently establish the safety performance of a complete installation. [17] [18]

Where machine learning is used for detection or classification, the operational claim should remain specific. Recognising an aircraft in an image is one step. Producing a timely track suitable for conflict prediction requires further evidence, as does selecting and executing an avoidance manoeuvre. An operator evaluating such a capability should be able to trace those steps through the proposed installation, including the handling of degraded information. The pilot’s interface needs to convey whether the credited function remains available; a classification label cannot answer that question by itself.

Where the processing takes place changes the dependencies. Ground-based surveillance may feed a remote operations centre, while an airborne system may assess the threat locally. An installation may then advise the pilot, request approval or execute a response automatically within a defined envelope. For each arrangement, the operating concept needs to identify what reaches the crew and what continues to function if a supporting service is lost. The placement of decision authority deserves the same attention as the placement of the sensor.

Automation can shorten a response that would otherwise depend on the pilot receiving an alert and sending a command. It can also leave the pilot supervising a process whose abnormal behaviour is difficult to diagnose. In his NASA presentation on human-factors design for complex systems, Daniel Wallace addresses the risk of introducing automation without adequately considering human performance under off-nominal conditions. Reducing routine workload does not settle the separate question of what happens when intervention becomes necessary. [19]

I would therefore want a DAA safety case to state the human role in operational terms. Approving a manoeuvre before it begins is different from monitoring an automatic response. Taking over after a failure is different again, particularly if the person has to reconstruct the situation first. Each role brings a different timing requirement and needs different information. Describing all of them as supervision makes it harder to see whether the allocated task is achievable. Mode awareness is part of that problem. The crew should be able to distinguish an advisory function from one armed for automatic intervention, recognise when DAA is actively controlling the aircraft and understand the consequences of degradation. The interface also needs to make sense when mission navigation or a contingency function is demanding another flight path. Priority between incompatible commands should be established in the design and tested. A pilot cannot be expected to infer which function has prevailed solely by watching an unexpected turn develop.

An automatic response may be the appropriate choice for an encounter that leaves too little time for remote intervention. Human-factors work remains necessary in that architecture. It moves into the conditions for enabling the function, understanding its limits and managing the flight after the immediate response. Retaining human responsibility is credible only where the person has the information and control needed to exercise it.

Training has to follow that allocation of tasks. Gary Klein’s Sources of Power examines how professionals make decisions under time pressure and changing conditions, including in aviation. His naturalistic decision-making approach considers how experience supports intuition and analysis. For remote DAA, training can apply that perspective by connecting encounter cues to the consequences of action. The pilot needs to understand why a response is appropriate as well as how to enter it. [20] A training event can usefully examine why the pilot acted as they did, even when the manoeuvre succeeded. Did the pilot understand the guidance, or happen to select a response that worked in that geometry? Could the same reasoning lead to a different outcome if the intruder’s trajectory changed? Debriefing should use the information available to the crew at the time. Revealing additional traffic data afterwards may help explain the encounter, but it should not become the basis for judging a decision that had to be made without it.

Representative training also needs encounters in which manoeuvring is unnecessary. If every exercise ends with an avoidance command, the assessment says little about the crew’s ability to distinguish an alert requiring monitoring from one requiring action. Changes in guidance, delayed commands and uncertainty about execution deserve attention as well. The aim is to establish that the crew can use the system under the conditions credited in the operation, including circumstances in which the expected response does not occur. How much simulation and flight testing is needed will depend on the claim being made and the parts of the system each method can represent faithfully.

There is a procedural trap here. Asking the pilot to obtain further confirmation before acting may sound prudent, but that confirmation has to be available and worth the time it consumes. Where an approved response is intended to follow instrumented traffic information, procedures should define the conditions under which that information is sufficient. If a separate check is required, its purpose and timing need to be accounted for. An unwritten expectation to “make sure” can leave the crew with a task for which the architecture provides neither information nor time.

ATC coordination can add another dependency. NASA’s UAS Air Traffic Controller Acceptability Study 2 examined one-way voice delays of 0, 400, 1,200 and 1,800 milliseconds in simulation. Long delays were problematic in the high-traffic-density environment tested; controller comments described blocked or overlapping transmissions and repeated exchanges. These were voice delays, not measurements of C2 command-link latency. The finding is relevant because a coordination exchange can take more than the transmission time of one message. [21] An operating procedure should distinguish the coordination associated with an early conflict from the response to an immediate collision threat, following the applicable rules and equipment guidance. The remote crew and the relevant air traffic services unit need a common understanding of expected aircraft behaviour and reporting. If the safety case assumes a particular sequence of coordination, the assessment should establish that the sequence can be completed within the available margin. Merely including a radio call in a flowchart does not demonstrate this.

The team around the remote pilot deserves similar attention. A mission operator may be monitoring the payload while a supervisor supports flight decisions, or a technical specialist may be available to diagnose a fault. Those contributions can be useful, provided the crew knows who has aircraft control and how supporting information reaches that person. Adding people can also add exchanges at a time when attention is already divided. A team assessment should examine what the arrangement enables the pilot to achieve during the encounter, including whether another crewmember can handle communications or monitor execution without creating conflicting instructions.

Handover tests whether that shared understanding survives a change of pilot. Transferring control authority is a technical event; the receiving pilot also needs the current operational picture. Active traffic concerns, automation state and any relevant degradation must remain intelligible across the transfer. The organisation should establish when a handover is inappropriate and how an unavoidable transfer during an abnormal condition will be managed.

With multiple aircraft under one person’s supervision, the problem becomes more demanding. A manageable nominal workload says little about simultaneous exceptions. One service failure may affect several flights, generating competing demands for intervention. Moving attention to another aircraft takes time and can leave the first response only partly monitored. The operating concept should therefore address correlated events and the protection available to aircraft that are temporarily outside the pilot’s immediate attention. The staffing case needs evidence for those conditions before nominal capacity is treated as a safe operating limit. Aircraft identity must remain unambiguous throughout. A warning that clearly identifies a conflict can still lead to the wrong command if the active vehicle changes between windows or the pilot acts from the wrong control panel. Safeguards against that error need to be assessed together with their timing cost. Extra confirmation steps are useful only if they support the required response within the conditions being claimed.

C2 degradation makes these dependencies particularly visible. A station may retain enough downlink information to display traffic while the path needed to command avoidance is no longer dependable.

If the mitigation relies on that command path, its availability has changed even though the display still looks informative. Where onboard protection remains active, the pilot needs to know what it will do. Where the credited protection has been lost, the operating concept must define the response to that loss. Surveillance availability and control authority need to be assessed together.

The crew also needs evidence that the aircraft has responded. Transmission, acceptance and execution are separate events. A control station that reports the first without making the others clear leaves uncertainty about whether the intended manoeuvre is under way. Monitoring must continue as the encounter evolves, including when the intruder changes course or another aircraft becomes relevant. If the information used for that monitoring is delayed, the crew needs an intelligible indication of the limitation.

The disappearance of an alert is not, by itself, a clearance to resume the mission.

After avoidance, the aircraft may be off its planned route, at another altitude or in a different flight mode. The crew needs to establish whether automatic return to the route is enabled and whether that route remains suitable. Any required coordination has to follow the applicable procedure. Recovery should be assessed as part of the operation because a successful initial manoeuvre can leave a new set of constraints. Closing the test at the end of the warning would miss that work.

James Reason’s Managing the Risks of Organizational Accidents provides a wider perspective on where a late or ineffective response can originate. His subsequent paper, Human error: models and management, describes how weaknesses in organisational defences can combine to permit an accident. Applied to DAA, this directs attention to the way design, procedures and operational decisions interact. The pilot’s last action is a point from which to investigate those interactions; it cannot explain them all. [22] Consider what happens when a commercial assumption becomes an operational assumption. A service is planned around a certain number of aircraft per pilot, or a new task is added to make better use of a quiet phase of flight. Either may be reasonable, but a credited intervention still has to fit within the resulting workload. A review limited to changes in airborne hardware could miss the effect entirely. The relevant question is whether the crew can still deliver the response on which the safety argument depends.

Software changes can be less obvious. Adjusting an alert threshold may change how often the crew is interrupted. Altering the presentation of track quality may change what degradation the pilot notices. A revised mode priority may change the result of a familiar command. These are reasons to link configuration management to the assumptions about human performance, and to identify which changes require further validation or training. A product name remaining the same is not evidence that the task has remained the same.

ICAO’s published explanation of the fourth edition of the Safety Management Manual emphasises operating context, proportionality to organisational size and complexity, safety culture and the use of data to manage performance. For DAA, I would apply that approach by monitoring whether the credited response remains effective in service. The measures proposed here are an operational application of safety-management principles, rather than an ICAO-prescribed DAA checklist. [23]

Useful records would allow an event to be reconstructed from the crew’s perspective. The alert, guidance and information quality should be connected to the selected action and the aircraft’s actual response. Relevant C2 status, automation transitions and coordination may be needed to explain the sequence.

A replay that presents the investigator with a clearer picture than the pilot ever had can produce a misleading account of why the decision was made.

Alert counts need context, too. A false alert is different from a valid warning that is operationally unhelpful, and both differ from an alert followed by successful avoidance. A reduction in alerts could reflect better planning, changed thresholds or reduced surveillance coverage. Looking only at the total would not distinguish these explanations. The organisation needs definitions and exposure information that let it examine usefulness and burden alongside the outcome of the encounter. Potential indicators include delayed responses, failed command execution and loss-of-well-clear events under the definition applicable to the system. The time spent with a degraded mitigation may also be relevant. Such measures need to be selected for the operation and interpreted against what actually happened; they should not turn every acknowledgement into a success or every alert into a failure. Where the record is incomplete, the uncertainty should remain visible in the analysis.

ICAO’s Safety Intelligence Manual, Doc 10159, expands guidance on collecting, processing and analysing safety data and information. ICAO also reports adoption of Amendment 2 to Annex 19 on 23 June 2025, with applicability on 26 November 2026. As of 13 September 2026, that applicability date remains ahead. The distinction matters when describing current obligations, which must be tied to the rules and approvals governing the operation concerned. [5] [24]

Successful human contributions deserve examination as well. NASA’s Jon Holbrook has discussed the limitations of judging aviation’s human contribution predominantly through errors and accidents, while routine successful performance receives less attention. In unmanned operations, a decision to reduce exposure or discontinue a mission may prevent an urgent DAA intervention from becoming necessary. Understanding such decisions can help identify which protections depend on the crew and what would need to be preserved if duties were automated or reassigned. [25]

The validation programme should reflect this wider view of the task. A focused demonstration is useful for checking a function, while a representative mission can reveal demands that the demonstration excludes. Simulations can introduce unexpected traffic, degraded information and competing duties; flight testing can address behaviour that depends on the real aircraft and installation. Each test should have a stated purpose and a link to the safety claim it supports. The person who developed an interface may operate it fluently, but the intended operational users need to be represented in the evidence.

Particular care is needed with average response times. An encouraging mean can conceal encounters in which the available margin was largely or entirely consumed. Late actions, incorrect actions and non-responses need to remain in view, with the conditions that produced them. The statistical treatment and acceptance criteria should follow the safety objective. Removing unsuccessful encounters from a response-time calculation without explaining how they are assessed elsewhere would make the result difficult to use.

User feedback has a different, complementary purpose. A pilot may find a display comfortable while misunderstanding an important limitation. Another may perform the task correctly while reporting excessive workload. Both observations deserve investigation. Connecting subjective feedback to the recorded sequence is more useful than treating either comfort or a successful single manoeuvre as sufficient proof of usability.

These questions are easier to address before procurement fixes the architecture. A request for a DAA capability should describe the intended mission and ask what response is required from the crew. The supplier’s evidence should make clear the functions included, the operating assumptions and the dependencies that can remove the claimed protection. The operator can then trace those assumptions into procedures and training, and identify what still needs to be demonstrated with the intended installation. Detection range belongs in that discussion, alongside the time and authority needed to act on the result.

A remote pilot can contribute judgement about the wider operation, recognise a developing limitation and adapt when the situation changes. Those contributions require access to the relevant information and an achievable opportunity to act. Assigning responsibility to the person at the control station while leaving an unresolved delay, an ambiguous mode or an unreliable command path does not provide that opportunity.

The evidence has to continue after the alert. It should show that the crew or automation can select a suitable response, that the aircraft can achieve it within the available margin and that the resulting flight can be managed safely. That is the point at which detection becomes an effective operational protection.

(Image: Shutterstock)

Manuel Ignacio Pérez Pan is a UAS operations and unmanned aviation safety professional with more than 4,000 flight hours and operational experience across Europe and Latin America. His work covers BVLOS operations, critical infrastructure inspection, flight testing, system validation, operational risk management and professional UAS training. His postgraduate research in Aeronautical Sciences focused on the implementation of an unmanned traffic management system. He is the founder of BVLOS Safety Academy.

References

1. EUROCAE. ED-271A: Minimum Aviation System Performance Standards for Detect and Avoid Traffic for Remotely Piloted Aircraft Systems in Airspace Classes A–G under IFR. November 2024. Public scope and revision description. EUROCAE catalogue.
2. ICAO. Remotely Piloted Aircraft System Concept of Operations for International IFR Operations. Publicly linked unedited version, explicitly marked not approved in final form. Definitions and sections 1.4, 2.4 and 2.6. ICAO document.
3. ICAO. Standards and Recommended Practices: Annex 19 — Safety Management. Official explanation of the framework and its development. ICAO overview.
4. ICAO. ICAO References. Official bibliography listing Human Factors Training Manual, Doc 9683; Manual on Remotely Piloted Aircraft Systems, Doc 10019; and associated guidance. Background references. ICAO bibliography.
5. ICAO. Guidance Material. Official descriptions of Safety Management Manual, Doc 9859, and Safety Intelligence Manual, Doc 10159. ICAO guidance.
6. Comstock, J. et al. Unmanned Aircraft Systems Human-in-the-Loop Controller and Pilot Acceptability Study: Collision Avoidance, Self-Separation, and Alerting Times (CASSAT). NASA/TM-2016-219181, 2016. Pilot-phase settings and alerting-structure findings. NASA report.
7. Williams, K. W. Minimum Information Requirements for an Unmanned Aircraft System Detect-and-Avoid Traffic Display under Full-Mission Conditions. DOT/FAA/AM-20/06. FAA catalogue gives report date August 2019 and page update 13 May 2020. Study design and reported conclusion. FAA report record and abstract.
8. Consiglio, M.; Muñoz, C.; Hagen, G.; Narkawicz, A.; Upchurch, J.; Comstock, J.; Ghatas, R.; Vincent, M.; Chamberlain, J. Human-in-the-Loop Experimental Research for Detect and Avoid. DASC, 2015. Historical research concept, not a statement of current universal operating requirements. NASA paper.
9. Endsley, M. R. Toward a Theory of Situation Awareness in Dynamic Systems. Human Factors, 37(1), 32–64, 1995. See also Endsley, M. R., and Kiris, E. O. The Out-of-the-Loop Performance Problem and Level of Control in Automation. Human Factors, 37(2), 381–394, 1995. Author’s publication bibliography.
10. Endsley, M. R., and Jones, D. G. Designing for Situation Awareness: An Approach to User-Centered Design. Third edition. CRC Press, 2025. Edition and subject coverage verified through the publisher-supplied book record. Book record and preview.
11. NASA. Detect and Avoid Alerting Logic for Unmanned Systems: DAIDALUS. Official repository and functional description. NASA repository.
12. NASA Langley Formal Methods Programme. DAIDALUS. Technical description and research bibliography, including Narkawicz, A., Muñoz, C., and Dutle, A. Sensor Uncertainty Mitigation and Dynamic Well Clear Volumes in DAIDALUS, DASC 2018. NASA programme page.
13. MIT Lincoln Laboratory. Airborne Collision Avoidance System X. Official description of tracking, action evaluation and ACAS Xu. MIT project page.
14. RTCA. SC-147: Traffic Alert and Collision Avoidance System. Committee description covering ACAS Xu, ACAS sXu and ACAS Xr. RTCA committee page.
15. RTCA. SC-228. Committee scope covering DAA, C2 data links and navigation standards. RTCA committee page.
16. Katz, S. M.; Alvarez, L. E.; Owen, M.; Wu, S.; Brittain, M.; Das, A.; Kochenderfer, M. J. Collision Risk and Operational Impact of Speed Change Advisories as Aircraft Collision Avoidance Maneuvers. 2022. Author-posted research paper; simulation findings bounded by the models evaluated. Research paper.
17. Echodyne. Safer Skies with Airborne Radar. Manufacturer description of EchoFlight and its sensing and integration functions. Manufacturer source.
18. uAvionix. Airspace Awareness for UAS. Manufacturer description of cooperative surveillance, Casia G and related capabilities. Manufacturer source.
19. Wallace, D. Human Factors Design Considerations for Complex Systems. NASA Engineering and Safety Center Academy. Published presentation abstract. NASA source.
20. Klein, G. Sources of Power: How People Make Decisions. Twentieth Anniversary Edition. MIT Press, 2017; first published 1998. Publisher’s description of naturalistic decision-making. MIT Press.
21. Comstock, J. R., Jr.; Ghatas, R. W.; Consiglio, M. C.; Chamberlain, J. P.; Hoffler, K. D. UAS Air Traffic Controller Acceptability Study 2: Evaluating Detect and Avoid Technology and Communication Delays in Simulation. NASA/TM-2015-218989, November 2015. NASA report.
22. Reason, J. Managing the Risks of Organizational Accidents. Ashgate, 1997. Bibliographic details and barrier-model context also documented in Reason, J. Human error: models and management. BMJ, 320, 768–770, 2000. DOI: 10.1136/bmj.320.7237.768. Article record and bibliography.
23. ICAO. Safety Management Manual, Fourth Edition: Highlights. Official presentation describing the 2018 edition’s structure and emphasis. ICAO presentation.
24. ICAO. Safety Management. Official update on Annex 19 Amendment 2, adopted 23 June 2025, with applicability 26 November 2026. ICAO update.
25. Holbrook, J. Exploring Human Performance Contributions to Safety in Commercial Aviation. NASA Engineering and Safety Center Academy. Published presentation abstract. NASA source.

Source review and editorial revision: 13 September 2026.