Two Controllers, One Drone.

The operator was to trial forward control. A drone would be launched and flown out by a Mission Controller at a rear station, handed to a Forward Controller at a small station inside the battlespace area, tasked from there for the middle of the mission so that the ground element it was supporting could direct its sensor without a relay, handed back to the Mission Controller at the edge of the area, and recovered from the rear. The vendor's control page for the forward station existed as a software baseline. The trial's sponsor had to accept it or send it back before the next one, and the question they asked was the one that comes with every capability that adds a job to a person: "Can the forward station take it?"

Asked as written, the question invites an opinion, and a confident one from anyone who has controlled a drone. The practitioner's job is to turn it into something a method can answer, and the first move is to find out what the person at the forward station actually does.

The Forward Controller is not someone with nothing to do but fly a drone. They are part of a ground element, inside the area the drone is working, with their own communications to keep, their own position and security to think about, and a Ground Commander beside them who wants the picture and wants it now. Adding a drone to command does not add a task to that list. It adds a second thing's state to hold in mind, a control page to work under field conditions, and two transactions with a person at another station that have to succeed at a particular place and time.

Flying the drone in the employ phase was not, on inspection, the hard part. Once it is over the area it holds its pattern and does what it is tasked to do, and the Forward Controller monitors it the way they monitor anything else. The hard parts are the edges. The handover in, when the drone crosses into the area and the Forward Controller must verify it is what the Mission Controller says it is and accept it. The hand back at the edge of the area, when the Forward Controller must put it in a safe state, offer it, confirm the Mission Controller has it and release it. And the move on immediately after, when the Forward Controller has to stop thinking about an aircraft they no longer control and start thinking about their own comms, their own position and the element's next move.

Of those three, the hand back is the one that lands on top of something. The handover in happens while the element is static and waiting for the drone. The hand back happens because the element is about to move, which is the moment the Ground Commander wants the last of the picture and the move time, and the station itself has to be closed down. So the change is not "one more thing to control". The change is that a multi-step transaction with a person at another station, one that has a window and a wrong answer, now happens under interruption, at the busiest point of the Forward Controller's own job. The question the work has to answer:

Can the Forward Controller hand the drone back to the Mission Controller inside the procedure's window, while doing the work the Ground Commander and the move are asking for, reliably enough to accept, and what has to be true of the control page for that to hold?

Two things follow. The measure is time, distributed across many attempts, not an average. And the condition is interruption, which means the analysis has to model the Forward Controller doing something else in the middle of the hand back.

The boundary: the forward station's control page, its displays and alerting, the handover procedure and the voice exchange with the Mission Controller are in. The drone's own autonomy, the datalink hardware, the rear station and the airspace rules are out, and are treated as fixed inputs. The lost-link drill is out of scope on this page: it is a procedure of its own and it is assessed as one. The roles: Forward Controller, Mission Controller and Ground Commander, recorded as positions. The modes: the baseline tasking without the drone, so there is something to compare against; the forward-controlled mission in its four phases, receive, employ, hand back and move on; a hand back that is offered and not acknowledged; and a link lost during the employ phase, which stays in the list even though its drill is out of scope, because the analysis, not the sponsor, decides what is credible.

In ErgoSphere the roles go into the Role Register as positions, and the framing is written as the Early Human Factors Analysis, run as a wizard with the standards lens set to MIL-STD-1472H. The change is entered as two states, the baseline tasking and the forward-controlled mission; the Forward Controller is the primary end-user group; the control page and the two handovers are the elements of note; and of the eight domain probes, workload and vigilance and the HMI probe are rated high, human error potential and task novelty high, and the environment probe medium because the station is used in the field, with the remaining physical probes considered and dismissed with a rationale. Every session that follows is named for its phase and condition, "Hand back, alone" and "Hand back, under the move", which is a practitioner's habit rather than a feature, and it is what lets the results sit side by side at stage 5 without anyone asking which was which.

Defence programmes make this step easier in one way and harder in another. Easier, because the contract carries a Human Factors integration requirement and an applicable documents list, so the top of the hierarchy is written down. Harder, because the list is long, much of it is about the whole system rather than one station, and the practitioner has to say which parts bite on this change.

1. The contract. The Human Factors programme requirement and its applicable documents list. In this scenario the list calls up MIL-STD-1472H for the design of the forward station's displays, controls and alerting, which makes it the governing design standard of this example: the control page's information content, its controls and its alerting are assessed against its clauses directly, not through another standard. MIL-STD-1472H is the standard Australian defence programmes most often call up for operator station design, and it is the one this example teaches. In the rail example it does not appear at all, because rail has its own governing standard and a control-centre standard for the numbers.
2. The operator's own orders. The handover procedure, with the window it gives the hand back, is the operator's document. It is not a design standard, but it is the criterion the analysis will be read against, so it goes in the basis.
3. The interoperability standard. STANAG 4586, which defines the levels of control a station can hold over an uncrewed aircraft and the transfer of control between stations. Read to establish what the forward station is: a controlling station with the drone's flight under its command, not a terminal with a picture of it. That distinction decides how much of the standard's control and alerting material applies.
4. The operator's aviation safety management system and the assurance its regulator expects, read for the form the argument at stage 7 has to take, not for design criteria.
5. Good practice on handover in other domains, air traffic control and the process industries in particular, where the transfer of control between two people has been studied for decades and the failure modes are well described.

MIL-STD-1472H is in the Standards Register's library, and it arrives as a tree of sections and clauses with the standard's own text. Screening runs section by section with three chips, Applicable, Partial or N/A, and each decision records who made it and when. For this change the sections on the content and arrangement of displayed information, on controls and on visual and auditory alerting are Applicable in full, because the control page is new and every clause under them bears on it. The sections on display coding and the identification of items are Partial, decided clause by clause, because only the parts about telling the state of one thing apart from the state of another matter here. The sections on the environment are Partial too, because the station is used outdoors and the clauses on legibility in daylight apply. The sections on workstation dimensions and reach are N/A, because the station's hardware is unchanged, and the rationale box says so. The rest of the standard, which runs to hundreds of pages about things this change does not touch, is N/A section by section with its reason, and Confirm locks each record.

STANAG 4586 shaped the work without being worked through clause by clause. It told the practitioner that the level of control the forward station holds during the employ phase is the level at which the station commands the drone's flight, and that the transfer of that control between stations is a defined transaction with a defined end. Both facts mattered. The first ruled out an easy answer that had been floated, that the Forward Controller was "only tasking the sensor" and the page could be treated as a picture. The second is what gave the hand back a beginning and an end that could be timed. The standard is cited in the professional judgement of the clauses it informed. Read but not loaded is a legitimate status, as long as the trail says which decisions the document touched.

• Description first. What does the Forward Controller actually do, from the drone crossing into the area to the element moving on? Every goal, every operation, in order, with the decisions and the plans. Nothing else can be chosen until this exists, because until it exists nobody can say where the risk is.
• Time, as a distribution. How long does the hand back take, across hundreds of attempts, alone and under the interruption of the move, before the control page exists in a trial rig to measure it on?
• Validation. When the trial rig is available, do the Forward Controller's workload and awareness in each phase stay within the margins the requirements set, against the baseline tasking?

The constraint that shaped everything: the trial rig was booked twelve weeks out, and the software baseline decision was due in six. Whatever answered the time question had to answer it without the rig.

Also considered and set aside, and both recommended for the next phase: ErgoAIR, to rationalise the drone's alerts before they are routed to a station in the field where the person has other things to listen to, and ErgoTrace, an STPA of the control structure linking the two stations, the drone and the datalinks, which is the right method for the question "what unsafe control actions does shared control make possible". Both are bigger questions than the sponsor asked. Both are in the report as the work that should follow if the page is accepted.

ErgoCompass, with the industry set to Aviation and the problem kind to mental workload, ranks its palette and records the justification in the same five fields as Example 01, with the three forks above in the "considered and set aside" field. Send to HFIP carries them into the Integration Plan, and here the plan is worth a sentence of its own: with the standards lens on MIL-STD-1472H the wizard produces a Human Engineering Program Plan in the sixteen-section structure defence programmes expect, so the sponsor's Human Factors lead receives a document shaped like the ones they already review. The screening answers are Modified, High and Demanding. Two things are then done deliberately. ErgoNeuro goes into the plan's Planned and not applied section with its reason, so it reads as a decision and not an omission. And the ErgoAIR and ErgoTrace recommendations go into the activity-by-phase table against the next phase, so the next practitioner on the programme inherits them.

The procedure gave the skeleton. Two people who had held the forward role gave the rest, in a talk-through at a desk with the control page on a laptop and the Mission Controller played by the practitioner: what they would look at first when the drone was offered, what they would say and to whom, what they would want to know before accepting it, and what the Ground Commander would be asking for at the moment they were trying to give it back. The talk-through is where the analysis found that the hand back is not one operation but seven, that three of them require the Forward Controller to read the drone's state off three different pages to confirm it to the Mission Controller, and that "release" is a thing the Forward Controller does after the Mission Controller's acceptance, not at the same time as it, which is the gap "who has it" lives in.

The tree is written from the Forward Controller's point of view. Their own tasks for the ground element, the comms, the position, the security, are not decomposed here. They are the background the tree runs against, and at node 3 the plan says so.

Read the plans, not just the nodes. Plan 1 has a decline path. Plan 3 says the whole phase runs alongside a job this tree does not show. Plan 4 has a window and a failure branch, 4.7, that the procedure did not have until the talk-through asked what happens if the Mission Controller does not answer. And node 5.1 exists because both people, unprompted, said the first thing they would want to do after release is get the page off the screen. The tree found the question the rest of the work answers: node 4, under the conditions of node 5.

ACT-R is a cognitive architecture: a model of how perception, memory retrieval, decision and motor action take time and sometimes fail, built from decades of experimental data. Modelling a task in it has traditionally meant writing production rules by hand, which is why so few Human Factors programmes have used it. ErgoAct replaces the hand-written model with a storyboard: the task is laid out as a sequence of seven block types, Look, Listen, Recall, Decide, Act, Speak and Wait, each with its parameters, and the tool compiles the storyboard into a real ACT-R model and runs it.

The storyboard follows HTA node 4, operation by operation. Confirming that the task is complete is a Look at the sensor picture and a Decide. Commanding the safe state is three Acts through the control page's menus, each a Press with its distance and target size, and a Look to confirm each has taken. Offering control is an Act and a Speak. The state confirmation at 4.4 is where the storyboard grows: as the page is designed, mode, fuel and payload are on three different pages, so it is three Looks with a menu Act between each and a Recall of the handover point's identifier, which is set to Familiar rather than Well-learned because the point changes with the task. Then a Speak with the utterance length the controllers actually use. Receiving acceptance is a Listen and a Decide. Release is an Act and a Speak.

The second variant models the hand back under the move. It opens with the blocks the Ground Commander's question triggers, a Look at the sensor picture and a Speak, so the hand back is entered from somewhere else, and it inserts a Recall of where the hand back had got to, and a Decide to resume it, after the Ground Commander's second question lands between 4.4 and 4.5. The identifying Look at 4.4 is set to two similar items in view with the familiar-layout option off, because the drone's fuel page and the station's own status page are styled alike, which forces the serial search a real controller would make. Everything else is identical, and the operator profile on the Model tab, skill, fatigue and stress, is the same for both.

The generated model is there to read. It is a real ACT-R model, declarative memory chunks and production rules, read-only and copyable. A reviewer who knows the architecture can check it; one who does not can at least see that there is something to check. That matters more than it sounds. A model nobody can inspect is an opinion with a progress bar.

Each variant is then run five hundred times from the Run tab with a fixed seed, so the run is reproducible. The results page leads with six tiles: mean total time, the 5th to 95th percentile spread across runs, time spent waiting, retrieval failures per run with the share of runs that ended unrecovered, the busiest cognitive module, and task success, which says how many runs proceeded on a guess, omitted a step or aborted. Under them, the completion-time histogram, the step breakdown, and a findings list the tool writes itself. Two of its sentences on the interrupted run were the finding in a line: completion time varies widely between fast and slow runs, and a retrieval that fails after an interruption is the step most often omitted. The step it named was the resumption after the Ground Commander's question, and what was omitted, in the runs that omitted it, was the confirmation at 4.4. The alone model is pinned as the baseline so the interrupted histogram is drawn over it.

Twelve weeks later, the trial rig: the forward station on a bench against a synthetic environment, with a rear station played by the trial team. Six Forward Controllers, two runs each in a balanced order, the baseline tasking and the forward-controlled mission, with the mission rated phase by phase: receive, employ, hand back, move on. The Ground Commander was played by a briefed role player who asked for the last of the picture and the move time at the moment the hand back began, because that is what a Ground Commander does. After every phase, NASA-TLX for perceived workload across its six scales, and SART for situation awareness across its three dimensions, both captured live in session in ErgoSphere, one session per phase and condition, named for it.

The trial ran on the control page after the changes from 4.4 had been made, because the model had already failed the original design and there was no point spending rig hours confirming it. That ordering is the entire argument for doing the analysis first.

The timeline view of the interrupted run put the added time in two places. The first was node 4.4: reading the drone's mode, fuel and payload off three pages, with a menu Act between each, and recalling the handover point, took a sequence that the Ground Commander's question could land anywhere in, and when it did, the Recall of where the sequence had got to sometimes failed. The second was the gap between 4.5 and 4.6: after the Listen for acceptance, the model had to Recall whether release had already been commanded, and under interruption that retrieval was the one most often wrong. Neither is a workload problem. Both are interface problems, and interface problems can be tested in the model before anyone builds them.

Two design changes were proposed and storyboarded. A handover summary: one page that presents the drone's mode, fuel, payload and link state together, with the handover point named on it, so 4.4 becomes one Look and a Speak and the Recall disappears. And a positive control-state indication, Mine, Offered or Theirs, that changes on the Mission Controller's acceptance and not on the Forward Controller's command, with release a deliberate confirmed action that is only offered once the state reads Theirs. In the storyboard the Recall before release becomes a Look, because the controller now reads the state instead of remembering it. The interrupted storyboard was saved as a new model, edited to match, and run with the same seed. Compare Models then puts the two persisted runs side by side without recomputing either, and a sensitivity sweep over stress checked that the tail stayed inside the window as the operator's stress setting rose, which matters more here than in most settings, because the person is in the field.

The anatomy is unchanged from Example 01: who, shall, what, under which condition, to what criterion, verified how. And the timing is the same: the set is written now, after the results, because the findings are where most of it comes from. The handover summary and the control-state indication became UR-03 and UR-04 the moment the model showed where the tail came from; the clean break on release became UR-07 the moment the debriefs explained the SART dip. What is different here is that the criterion for UR-02 comes from the operator's procedure, not from the standard. That is normal. The standard says the state must be displayed and the control must be deliberate; the procedure says how fast.

Every requirement has a criterion someone can fail. UR-02 is verified twice: first by analysis, so the design can be changed before the rig time is booked, and then by test, because a model is evidence for a decision and not a substitute for measurement. Writing both verification steps on the requirement, in that order, is what makes the model's role clear to a reviewer who is suspicious of models. UR-01 and UR-04 are the pair that answers "who has it": one says the display must show it, the other says the control must not let the Forward Controller get ahead of it. Either alone is half an answer.

The seven go into the HF User Requirements Register, each in its requirement group, with its end-user group, its verification method and stage, an owner and a status of Open. The register does not point at a clause; it carries a source narrative in plain words, and the one worth noticing is UR-02, whose narrative names the operator's handover procedure rather than a standard. The procedure itself is held in the Document Register, so the narrative names a record and not a sentence in a report. The clauses' own side of the story, their compliance status and evidence, waits in the Requirements workspace until stage 7.

Four issues carried the work, each raised from the session that found it so the provenance is the tool's and not typed. The handover summary and the control-state indication with confirmed release, both High, both owned by the vendor, both required before the page is accepted. The clean break on release, Medium, owned by the vendor, targeted at the baseline after next, because it is a display change and not a control change. And the failure branch at HTA 4.7, which the procedure did not have: Medium, owned by the operator's standards cell, to write the "hand back not acknowledged" drill into the procedure. Each links to the user requirements it answers, and the two vendor changes carry the ErgoAct comparison as evidence of effect. When the operator took the procedure change into its own process, that issue was set to Transferred, not Closed, and the register keeps the distinction wherever a number is shown.

In the Requirements workspace the MIL-STD-1472H alerting clauses are set Compliant with the trial sessions under Linked Assessments and a professional judgement statement each. The displayed-information and controls clauses are Partially Compliant, with the summary and control-state issues raised against them, and will move when they close. The workspace's cards show the standard answered where it can be and open where it honestly is. The word in the report is "evidence provided against", and the claim of acceptability is the sponsor's to make on that evidence, which is exactly what they asked for at 1.1 without quite saying so.

The Early Human Factors Analysis from stage 1 and the Program Plan from stage 3 are finalised and signed, which freezes each as a dated, hashed version. The close-out wizard then builds the assurance report as an argument: each of the seven requirements closed with its evidence named, every issue traced to its requirement, and the four sub-claims positioned and reasoned. The Influence sub-claim, the one the wizard says should carry rejected recommendations, took the ErgoAIR and ErgoTrace work the sponsor chose not to fund this phase. The conclusion was Implemented with conditions, the two vendor issues being the conditions, and the completeness check listed the open High issues by name. The compiled deliverable is Part I, the assurance summary; Part II, the frozen EHFA; Part III, the frozen plan, with ErgoNeuro visible in its Planned and not applied section; then one appendix per session: the HTA, the three ErgoAct models, and the NASA-TLX and SART sessions from the trial, phase by phase.

The reports were marked ready, composed into one package and issued as Revision A to the sponsor for the free Viewer. The reviewer who had been most sceptical of "a model" opened the generated ACT-R model in the Viewer, read the production rules, and sent the package back with one comment anchored to the ErgoAct assessment asking why the state confirmation Speak was as long as it was. Import a Returned Package verified the review chain against what had been issued and filed the comment where it was written. The answer, the controllers' actual phraseology timed in the talk-through, went into Revision B, and the comment was resolved against it. That is what an issued deliverable is for.