OSO-19/20 — Safe Recovery from Human Error & HMI

Summary

Joint compliance route for OSO#19 (systems detecting / recovering from human errors per industry best practice) and OSO#20 (HMI clearly and succinctly presented; HF evaluation done) at SAIL III low assurance. The applicant performs a Human Factors evaluation scaled to the level of novelty / complexity / integration / criticality of the design, then completes a structured compliance checklist (Annex I) covering CMU ergonomics, controls, information presentation, system behaviour & automation, error management, multi-CMU/multi-UAS handovers, and the flight manual. Compliance is declared on the basis of HF Inspection report, HF Analysis, or scenario-based HF evaluation (≥3 representative crews in real conditions / sim / test bench).

Operation Safety Objective

OSO#19: "Systems detecting and/or recovering from human errors are developed according to industry best practices." Examples: functional tests, safety pins, acknowledgment features, fuel/energy consumption monitoring.
OSO#20: "The UAS information and control interfaces are clearly and succinctly presented and do not confuse, cause unreasonable fatigue, or contribute to remote crew errors that could adversely affect the safety of the operation."

Low-assurance: OSO#19 satisfied when designer declares the integrity criterion is achieved; OSO#20 satisfied when manufacturer conducts an HF evaluation to determine HMI is mission-appropriate (inspection or analysis based) and declares adequacy.

HF Evaluation Process

Describe → Derive → Assess → Identify → Evaluate/Analyse → Declare

Describe: affected equipment, involved crew, deployment scenarios, tasks.
Derive: equipment/scenario list, affected procedures.
Assess four drivers (the depth of HF assessment is driven by these): - Novelty (primary driver) — new functions / new design items not previously evaluated by the same designer - Complexity - Integration - Criticality — High when a single human error can cause LoC of operation (or any catastrophic hazard) or immediate correct crew action is required to mitigate a foreseeable event
Identify: equipment/scenario level of scrutiny, requirements list, assessment method(s).
Evaluate/Analyse with one of: - Inspection / analysis — identify controls, info & system behaviour involving crew interaction; analyse crew tasks; evaluate system appropriateness. - System assessment — focused on a specific design item; in-depth functional/operational assessment; covers all relevant operational procedures. - Scenario-based — most onerous; ≥3 crews representative of future users; real conditions in test bench, simulator, or operations; detailed HF test objectives; triggering events likely to provoke crew errors; realistic task sharing & workflows.
Declare compliance to MoC OSO#19/20.

HF Analysis output must contain

In-depth analysis of observed HF findings
Conclusions on related HF test objectives
Mitigation proposals (design mods, procedure improvements, training)
All HF concerns recorded, investigated, analysed (even if outside primary objective)

Systems-design-approach domains

Manpower · Personnel · Training · Human Engineering · System Safety · Health Hazards.

Compliance Checklist (Annex I — structure)

Designer input towards other OSOs (assessed elsewhere; designer must surface info in flight manual)

A1 — OSO#08 Operational procedures: flight planning, pre-/post-flight inspections, env-condition evaluation, coping with adverse env, normal/contingency/emergency, pre-flight briefing.
A2 — OSO#09 Remote crew trained & current; theoretical/practical knowledge for normal/abnormal/emergency situations from technical issues, human errors, critical env conditions; proficiency & recurrence.
A3 — OSO#16 Multi-crew coordination: task assignment + step-by-step communications/phraseology.
A4 — OSO#17 Designer has accounted for crew fitness requirements + safety instructions.

B — Human Factor Evaluation Process

B0 — process established (covers full design scope; pre-/post-flight + external systems considered; crew tasks/procedures considered; methodology established to identify/manage design-related HF issues; novelty/complexity/integration/criticality identified per system; level of scrutiny driven by most constraining outcome; representative users & operational scenarios describable).
B1 — Inspection/analysis based: reference HF evaluation available + representative; appropriateness confirmed when ConOps deviates.
B2 — Scenario-based (10 sub-items): scope; comprehensive HF design principles list; objective + subjective data collection (per AMC to CS27.1302 §3.3.2); operationally representative scenarios; HF eval plan documenting objectives, crew profiles, scenarios; representative test config + justified deviations; ≥3 crews; HF test protocols capturing deviations; HF analysis incl. mitigations; all HF concerns recorded.

C — UAS HF Design Principles

C.1 Environment & Ergonomics — CMU ergonomics fit-for-purpose (no distractions, suitable for crew range, alertness across shift, handheld CMU constraints); foreseeable physical environments (wind, humidity, precip, temperature, illumination, noise); PPE & clothing used in assessment; CMU integration with wider UAS environment.
C.2 Controls — clarity, accessibility, distinguishability; readable labels in foreseeable lighting; consistent motion sense; multi-crew control rules (priority for cursor devices, PIC confirmation of co-pilot inputs, multi-function single-control caution); feedback (clear/unambiguous, prevent inadvertent operation of LoC-leading controls — switch guards, interlocks, confirmations; access during failures; tactile feedback when looking elsewhere).
C.3 Presentation of information — clear, unambiguous, appropriate resolution, accessible, usable; awareness feedback; UA control info (CMU compensates lack of natural perception; readable in normal posture; cross-cockpit readability if applicable); display uncluttered; standard colour scheme; alert colour codes (red warning, amber caution, green safe-op, grey = unavailable/old/invalid); accessibility of info during system failures; flight/nav data, propulsion data, C2 link availability/strength/integrity, lost-link status, external systems deterioration; alerts understandable; manual direct piloting alerts approaching unsafe condition + envelope-protection engagement awareness.
C.4 System & automated system behaviour — crew can perform tasks across normal/abnormal/emergency in acceptable workload; system enables timely failure detection & intervention; behaviour unambiguous & predictable; intervention provisions (terminate flight, RTH, abort take-off, go-around); state/intention info (entries, present state, actions, future states, transitions); auto-operation awareness (commanded vs actual; near-limit alerts); shared awareness; review/accuracy check before activation (except built-in fail-safes).
C.5 Management of error — control-mode indication (direct / partially auto / fully auto); uncommanded mode reversions annunciated; error detection info & reversal/mitigation controls; transitory-error history log with timestamps available on demand.
C.6 Multiple CMU & multiple UAS — handovers safe (offer / exchange info / accept / confirm); inter-pilot info exchange list (flight mode, parameters, status, position, plan, NOTAMs, weather, ATC clearance & freq, error/warning history, control settings alignment); minimum crew for multi-UA scenarios; UA data displayed without confusion; controls per UA; clear indication which UA the CMU has command of.
C.8 Flight Manual — operating limitations defined unambiguously; fatality/injury risks identified with mitigations; physical safety elements (lock pins, safety chains, propeller covers) clearly visible.

Documentation & Record-Keeping

Designer declares achievement of integrity criteria, evidence = testing/analysis/simulation/inspection/design review/operational experience (or combination). Evidence may not have to be delivered with declaration but must be collected & retained for authority on request.

Link With Other OSOs

Designer needs OSO#08/#09/#16/#17/#18 inputs (procedures, training, multi-crew coordination, fitness, envelope protection) to perform meaningful HF evaluation. OSO#18 envelope-protection function itself is excluded from HF assessment but related crew-interaction procedures are considered.

Definitions (key)

Alert — generic indication to attract crew attention to non-normal condition (warnings/cautions/advisories).
Automation — controlling apparatus/process/system electronically/mechanically, replacing human in sensing, decision-making, and deliberate output.
Clutter — excessive symbols/colours/info reducing access to relevant info.
CMU — area where the primary flight-controls displays are located.
Controls / control device — physical control manipulation; control device = equipment for crew interaction with virtual controls (keyboards, touchscreens, cursor devices, knobs, voice).
Human error — deviation from contextually-correct behaviour (incl. specification/design errors leading to human errors).
Abnormal/malfunction or emergency conditions — require crew to apply different procedures from normal; both normal and abnormal procedures must be in flight manual.

References

CAP 722 — UAS Operations in UK Airspace
NATO STANAG / AEP-83 — Light UAS Airworthiness Requirements
GAMA Publication #10 — Cockpit/Flight Deck Design (Part 23)
GAMA Publication #12 — Integrated Flightdeck/Cockpit (14 CFR Part 23 or equivalent)
FAA AC 23-23 — Standardization Guide for Integrated Cockpits in Part 23
FAA Human Factors for Maintenance Handbook
CS 27.1302 and related AMC (best practices for HF assessment, AMC §3.3.2)
ASTM F3298-19 — Design, construction, verification of lightweight UAS
ASTM F3478-20 — Durability and Reliability Flight Demonstration Program (Low-Risk UAS, FAA oversight)

MoC Index
OSO-05 — System Safety and Reliability
OSO-06 — C2 Link — alerts/monitoring HF
OSO-18 — Automatic Protection of Flight Envelope from Human Errors — excluded from HF eval but interactions considered