AEP-4685 human systems integration guidance for unmanned aircraft systems

What it is

AEP-4685 is the NATO Allied Engineering Publication that gives Human Systems Integration (HSI) guidance for the design, acquisition and operation of unmanned aircraft systems (UAS). It exists because safety investigations kept finding human error behind UAS mishaps, and because a UAS is not just an airframe: "a UAS is comprised of an unmanned aircraft, ground components, and other architectural elements, each with their attributes and which collectively interact to exhibit emergent system-level properties." The human crew at the Ground Control Station shapes the system's overall safety and performance even though no one is aboard the aircraft itself.

It is guidance rather than a specification, and it is carried by STANREC 4685: the Letter of Promulgation records that "the agreement of nations to use this publication is recorded in STANREC 4685," which means nations are invited rather than committed to use it. It reaches a supplier the way any Allied Publication does, because a specific NATO UAS programme's own agreement or contract calls for it. The current edition is Edition A, Version 1, promulgated February 2022 and effective on receipt. It is unclassified and free of charge, published by the NATO Standardization Office for the nations in the NATO Naval Armaments Group and produced for the Joint Capability Group Unmanned Aircraft Systems (JCGUAS), whose Flight in Non-Segregated Airspace working group commissioned it to reduce human performance related accidents and support routine UAS flight alongside manned aircraft.

The five HSI domains

The guidance sorts human-related issues into five domains that "should not be considered as separate entities; rather, they need to be related to each other": Manpower/Personnel (the numbers, skills and selection of people needed to operate and maintain the UAS), Training (the instructional systems and on-the-job training needed to reach a specified level of effectiveness), Safety and Health (minimising injury, illness and discomfort from noise, chemicals, vibration and radiation), Organizational and Social Characteristics (trust and information-sharing across distributed, multi-national teams), and Human Factors Engineering (matching the design to human cognitive, physical and sensory limits). A decision in one domain, automating a function, say, almost always has consequences in another, which is the reason the guidance insists they be worked together rather than as a checklist.

HSI goals, and building the baseline

Thirteen HSI goals, listed in section 3.1, "shall be fully pursued to achieve satisfactory outcomes" in every UAS project, including planned consideration of human factors from outset to disposal, a user-centered or interaction-centered design approach, and "involvement of users in system and equipment design and evaluation." Before analysis starts, a project has to establish an HSI baseline: collecting documents and assumptions bearing on the human component, distinguishing "what is 'fact' and what is 'assumption'" and recording both, then building a Context of Use covering the physical, organisational and social environment the UAS will be used in, a project-specific Target Audience Description covering the operating population's skills and training needs, and a review of legacy system data and lessons learned.

Early Human Factors Analysis and the Issue Log

Early Human Factors Analysis (EHFA) is a three-stage process, establish the baseline, log the issues, then assess and plan mitigation, run to surface human-related risks while they are still cheap to fix. The guidance is emphatic that it "should never be omitted on the basis that 'it is now too late'." Every issue identified, "including assumptions, constraints, user needs, risks, associated mitigations, opportunities and outcomes," has to go into an HSI Issue Log that is maintained for the life of the contract and expected to "form part of the contract deliverables." The guidance notes, in section 3.2.2.4, that "typically, the top ten issues account for 80% of the HSI risk on any particular project."

NATO Human Views

An architecture-framework overlay of eight products described in section 3.2.3, HV-A Concept through HV-H Human Dynamics, captures the human role in a UAS's architecture: the constraints on the human, the tasks assigned to people, the roles they occupy, how they communicate as teams, training impact, performance metrics, and how these change over time. An annex to the document cross-walks each Human View against the technical activity, mission analysis, functional analysis, task analysis, job and role design, human reliability assessment, equipment design, training development, and performance analysis, that produces it, so a reviewer can trace a piece of analysis to the Human View it is meant to feed.

Human-Related Requirements and acceptance

Requirements are grouped as overarching (arising simply because humans are part of the system), service-specific (arising from a particular military branch), and capability-specific (arising from what personnel must achieve). For each one, "an acceptance process must be in place to determine whether or not a HRR has been met," and the contractor has to "identify and propose appropriate means of demonstrating compliance with each requirement in the contract and submit them to the acquirer for agreement." Acceptable means include consensus based on judgment or on evidence, design inspection, functional demonstration, task walkthrough, or operability trial. Trade-off decisions between competing requirements have to be recorded and kept as contract deliverables too.

Management, technical work, and the HSIP

After development decisions, an HSI Working Group resolves conflicts between specialist requirements, escalating to the acquirer only when it cannot. Technical activities, mission analysis, functional analysis and allocation, task analysis, job and role design, human reliability assessment, equipment and workspace design, training development, and performance analysis, run iteratively rather than in a strict sequence. The outputs feed a Human Systems Integration Plan, described as "an evolutionary and continuous product" best updated annually alongside the UAS engineering plan, and a Project Test and Evaluation Plan carrying the HSI acceptance results.

How you are evaluated

AEP-4685 sets out no certification scheme, and no accredited or notified body certifies a project "to AEP-4685." Assessment happens directly between contractor and acquirer: "acceptance must specify how contractors will be assessed against the HSI requirements and constraints in terms of the characteristics of the UAS (including conformance to standards) and performance." What gets examined is the evidence itself, design inspection results, functional demonstrations, task walkthroughs, operability trials, the HSI Issue Log and the HSIP, checked by the acquirer against criteria the contract itself sets. It is the acquirer auditing its own supplier's evidence, not a third-party certification.

Standards named alongside it

AEP-4685's structure and terminology are drawn from ISO/IEC 15288:2008, the systems and software engineering life cycle standard, and its user-centered design approach references ISO 9241-210:2010, with its Context of Use concept drawn from ISO 9241-11:2000 and ISO 13407:1999. Its Human View framework is adapted from the NATO Human View Quick Start Guide, TR-HFM-155. The guidance states plainly that it "extracted the high-level process-related elements from the United Kingdom Ministry of Defence Standard 00-250, Human Factors for Designers of Systems," which is its principal source document. It is carried by STANREC 4685, the NATO recommendation that records nations' agreement to use it.