The Fifth Screen.

The management-of-change form had one line for Human Factors and the project engineer had filled it in: "Additional monitor at CRO desk, ergonomic assessment required." The drawing attached showed the plant control room desk with its four existing screens and a fifth on a new arm to the right, where the desk had space. The bay itself was three months from commissioning. The control system integrator had already listed the points that would come to the desk: four camera feeds, the gate and interlock states, a gate release control, and eight alarm conditions.

"Ergonomic assessment" of a monitor is a real piece of work, and a small one. It is also the wrong question, and it is the wrong question in a way that would have been invisible if the practitioner had answered it as asked. What was being installed was not a monitor. It was a new task, the release of a gate that lets a two-hundred-tonne truck into a bay where a person works, placed on a desk that already carried a plant.

A plant control room operator runs the processing plant from four screens: an overview of the circuit, the trends and alarm list, a camera wall for the crushers and conveyors, and the fleet dispatch view. They talk to the field on two radios and a phone, keep a log, and glance at the plant itself through a window that faces west across the yard. The desk has settled over years into a layout the operators no longer think about. Their eyes go where they need to go without a decision.

Four screens is about what a seated operator can hold in view without turning the head, and four is what this desk had settled around: everything the operator needs sits inside one sweep of the eyes. That is why four screens are easy and the fifth is the case. A fifth screen is not one more of the same. It has to go somewhere the eyes do not already go, and it competes for the attention the other four already have.

The new bay adds a fifth screen with four more camera feeds and a mimic of the bay's gates and interlocks. It adds a control: the gate release, which opens the entry gate for a truck once the bay is clear. It adds a person in the loop who was not there before, the Bay Attendant, who works inside the bay between trucks and whose safety depends on the interlock and on the operator not releasing the gate while they are in it. And it adds eight new alarm conditions to an alarm list that was already, by the operators' own account, "busy at shift change".

Three things about the desk change at once. Where attention has to go now includes a screen it has never gone to. What the operator is responsible for now includes a person's position in a bay they can only see on camera. And what interrupts them now includes eight conditions nobody has yet decided are worth interrupting for. Written as a question:

Where must the bay's screen and control sit for the operator to run the gate-release task safely without degrading the plant tasks already on the desk, what does the west window do to that screen, and which of the bay's conditions genuinely need the operator's attention?

The word "safely" in that sentence is doing specific work. The gate release is the one operation on this desk that can hurt someone directly, so it gets an error analysis of its own, whatever the change form said about monitors.

The boundary: the control desk, its screens, radios and window, the bay's screen, mimic, gate release and alarms, and the radio link to the attendant are in. The bay's own interlock logic, the plant control system and the truck fleet are out, and are inputs. The roles: Control Room Operator, Bay Attendant and Shift Supervisor, as positions. The modes: normal, bay occupied, camera loss, night shift, and one the practitioner added after standing at the desk at four in the afternoon: winter afternoon, when the sun comes through the west window low enough to matter.

In ErgoSphere the roles go into the Role Register and the framing is written as the Early Human Factors Analysis, run as a wizard with the standards lens set to IOGP 454, the process-industry lens, because the wizard offers no mining lens and a mine's management-of-change process is closest to the one that standard describes. The lens sets the report's framing and file naming; the eight probes are the same under every lens, and the governing standard for the design is still ISO 11064. The change is entered as its before and after states. The Control Room Operator is the primary end-user group and the Bay Attendant the secondary, which is the first time anyone had written the attendant down as a user of this system. The eight domain probes are rated: the HMI probe high, human error potential high because of the gate release, environmental stressors medium for the window, workload medium, the physical probes considered and dismissed with their reasons. Each rated probe becomes a risk area with a recommended method, and the significance level is set at medium with its reason: one operation with a direct consequence to a person.

Mining has less Human Factors standardisation than rail or defence, and more regulation. The list is assembled the same way, top down, and the top is heavier than usual.

1. The regulator and the site's own hazard plans. The state's mining safety regulation places duties on the operator for control rooms and for vehicle and pedestrian interaction, and the site discharges them through its hazard management plans. The plan for vehicle and pedestrian interaction is the criterion document for the gate release: it says what "bay clear" has to mean.
2. The site's management-of-change procedure. The document that made this work happen. It sets the gate the work has to pass and the sign-offs it needs.
3. The governing design standard. ISO 11064, the control-centre standard, in the parts this change touches: part 3 for the layout of the room, because a screen and a window are in the same field of view; part 4 for the workstation; part 5 for displays and controls; part 6 for the environment, which is where lighting and glare live. It governs because the site's engineering specification adopts it for control rooms and because it is written for exactly this workstation. It also supplies its own numbers, viewing angles, gaze limits and distances, so this example needs no second standard for criteria.
4. Alarm management good practice. EEMUA 191, which the site's alarm philosophy already cited, and which gives the alarm-load benchmarks the rationalisation is tested against.
5. Interior lighting good practice. AS/NZS 1680, read for the control room lighting clauses and the glare limits they point at.

ISO 11064 is not in the Standards Register's library, and that is the normal condition: no library holds every standard a site can call up. The register's Custom tab is for exactly this. The governing standard is entered as a requirement set with its code, title, edition and type, Prescriptive, and then its sections and clauses are added by hand, only the ones this change touches. Four sections went in, one per part, with the clauses on the arrangement of displays relative to windows, workstation dimensions and viewing angles, display and control layout, and lighting and glare. Typed clauses are not transcriptions, so the professional judgement on each records the edition it was taken from and the page of it. The set is then screened section by section like any library standard, Applicable, Partial or N/A with a dated decision, and it appears in the applicability statement with the same standing a library standard would have. A standard entered by hand is not a lesser standard. It is the governing one, and the register treats it so.

EEMUA 191 and AS/NZS 1680 shaped decisions without going into the register clause by clause. EEMUA 191 is the benchmark the alarm rationalisation tool builds in, so it is cited from there. AS/NZS 1680 supplied the lighting context the glare analysis was read in. The hazard plan is held in the Document Register as the criterion for the gate release, and every requirement and finding that answers to it names it. Read but not loaded is recorded as such in the judgement of the clauses each one informed.

• Attention. Where does the operator look and reach now, how often, and how much does each link matter? Only then: where should the new screen go so the links it adds are short and the links it crosses are few?
• Fit. Given a candidate position, does every display sit in an acceptable visual zone for the whole operator population, and does the release control sit within reach?
• Light. What does the west window do to that position across the year, in a number the requirement can be read against?
• Interruption. Of the eight new conditions, which need a person to act, how fast, and what does the worst bay upset do to the alarm list?
• Error. On the gate release, what can go wrong, how badly, and what would catch it?

The constraints: the bay was three months out, so nothing could be measured on the real system; the desk and the room existed, so both could be modelled from survey; and two shifts of observation were available, one of them a winter afternoon.

ErgoCompass, industry set to Manufacturing as the nearest of its options to a processing plant, problem kind set to human error or reliability for the gate release with the HMI question in the problem statement, ranks its palette and flags the methods native to the industry. The foundations panel is answered honestly: data gathering addressed by the two shifts of observation, HTA addressed for the gate release only, decomposition addressed, triangulation addressed by the two placement methods. The justification record's "considered and set aside" field holds the four forks above. Send to HFIP carries the set into the Integration Plan, whose screening reads Modified, High and Demanding, and whose activity-by-phase table puts eye tracking against commissioning.

Two shifts at the desk with a tally sheet. Every element the operator uses is listed: the four screens, the two radios, the phone, the log, the window, and, as a placeholder, the bay screen and the release control. Every time the operator's attention moves from one element to another, that is a link, and it is tallied. At the end of the shift each link has a frequency, and in the debrief each is given an importance from the operator's own account of what happens if that link is slow. The gate-release sequence was walked as a talk-through, since the bay did not exist, and its links were added with the frequency the bay's expected traffic implied.

In ErgoSphere the elements go into the model with their positions and the links into the LINKS table with From, To, frequency, importance and distance. The weighting is on the page in the tool's own notation, link value equals frequency times its weight plus importance times its weight, so a reviewer can see how the number was made. The current desk is the baseline scenario; two more scenarios place the bay screen on the right, as drawn, and centre-left, between the overview and the trend screen, and each scenario reports a layout efficiency and a weighted travel figure against the baseline. The diagram draws the links by value, so the thick ones are the ones that matter.

The finding was not subtle once drawn. The gate-release sequence links the bay screen to the plant overview, where the interlock mimic also shows, and to the radio. On the right, that link crossed the whole desk and the highest-value link on the new screen became the longest one on the desk. Centre-left, it was adjacent to the overview and the radio, and the plant's existing high-value links were untouched.

The room is modelled from the survey: the desk, the seat, the four screens, the release control panel where the integrator proposed it, and the west wall with its glazing as a real surface, because the glare analysis will need it. The Basis is set before anything is read: percentile, sex selection, the anthropometric population the site's specification uses, reference posture seated. The assessed eye reference point is computed from those, the figure at the seat is illustrative with its own eye marked, and the vision cone standard is set to ISO 11064, because it is the governing standard and the one UR-01 cites; the selector offers others, and the session report names the one used.

The two candidate positions from 4.1 are modelled in turn. On the right, the bay screen sat in the secondary zone at Acceptable for the 95th percentile and the tertiary zone at Marginal for the 5th, and the panel's glare risks row already showed a veiling angle against the west glazing before ErgoGlare had been opened. Centre-left, it sat in the primary zone at Optimal for both, the plant overview stayed Optimal, and the release control on the panel came inside the preferred reach area. The Findings page reports every item with its angles, distance, zone and compliance, and Capture embeds the views into the session report.

Glare is two problems that get one word. Light reflecting off the screen, which is a matter of the screen's surface and the angle of the source; and the window itself sitting bright in the operator's field of view beside the screen, which is discomfort glare and is what the Daylight Glare Probability measures. UR-02 is written for the second, because it is the one that determines whether the operator can look at the bay screen at all at four in the afternoon, and it is the one a physically based simulation can put a number on.

ErgoGlare's indoor mode takes the ErgoDesign model, the room, the glazing, the desk, and the operator's assessed viewpoint looking toward the bay screen, and runs the physically based lighting engine on it. The output is an HDR render from the operator's own eye, with an exposure slider and tone-mapping so the practitioner can see what the number describes, the DGP for that view at that time, and an annual sweep across occupied hours, with a per-sensor heatmap across the desk. The site is geolocated, so the sun is where it really is.

The integrator's list: gate open while bay occupied, emergency stop pressed, presence detected at a closed gate, wash pump fault, water tank low, camera feed lost, bay occupied, light curtain broken. All eight configured as alarms. ErgoAIR's worksheet takes each one and asks the questions the integrator was not asked: what is the failure the operator must respond to, what indication tells them, what is the response, how severe is the consequence if they do not, and how long do they have. Priority resolves from the severity-by-time matrix, and the threshold line then separates true alarms from alerts, prompts and event-log entries.

Three stayed above the line as alarms: gate open while occupied, emergency stop, and light curtain broken, all with a person's safety as the consequence and seconds as the time. Presence at a closed gate became a prompt, because the response is to start the release sequence and not to react to a hazard. Camera loss became an alert. Wash pump fault and water low became events, unless the bay is occupied, in which case pump fault becomes an alert. "Bay occupied" is not an alarm at all: it is a state, and it belongs on the mimic as an indication. Eight alarms became three.

Then the part the site had not thought to ask. The worksheet surfaces shared indications and shared responders as single points of failure, and it flagged that the only indication of "bay clear" on the operator's side was the camera feeds. The light curtain guarded the gate line, not the bay. Nothing independent of a camera told the operator whether a person was inside. That flag became UR-04 in its final form, and it was the most important finding in the example. It came from an alarm tool.

The gate release is one operation on a busy desk and the only one that can hurt someone directly, so it gets its own tree, short and complete, from a talk-through with two operators and the bay's designer. The plan carries the safety logic: nothing is released until the bay is confirmed clear, and a stop call from the attendant overrides everything.

SHERPA in Classic mode, Import from HTA, one row per bottom-level operation, the error mode picked from the taxonomy for each credible failure, with description, mechanism, consequence, recovery, probability and criticality, and the remedial strategy under Equipment, Training, Procedures and Organisational. The rows that mattered:

Three of the four high-criticality rows have the same shape: the declaration of "clear" rests on the operator's senses and discipline, and the release control does not care whether the declaration was made. The Equipment remedial strategy on row 4 says what the design has to do about that: a presence indication in the bay independent of the cameras, and a release control that is inoperable while it shows occupied. That is UR-04, rewritten from a procedure into equipment.

Same anatomy: who, shall, what, under which condition, to what criterion, verified how, and written now, after the results, because that is where they come from. Two of these have a criterion that is a number from the literature rather than from a standard, and the page says where the number comes from. UR-04 is the clearest case of a finding wound back into the design: at concept it was going to be a procedure, and the error analysis at 4.5 turned it into equipment.

Every requirement can be failed. UR-01 fails if a screen lands in the tertiary zone. UR-02 fails on a number. UR-03 fails if the rationalisation leaves an event configured as an alarm. UR-04 fails on inspection. UR-05 fails if the link analysis puts a high-value link across two head movements. None says "ergonomic", which is the word the change form used, because "ergonomic" cannot be failed.

The five go into the HF User Requirements Register with New Requirement, each fixed into its group: UR-01, UR-02 and UR-05 in System, UR-03 in System with the alarm configuration as its owner, and UR-04 in Procedure until the error analysis moved its substance into equipment. The Bay Attendant is the end-user group on UR-04, which is the point of it. Each carries a source narrative in plain words, a verification method and stage, an owner and a status of Open. The register does not point at a clause; the narrative names it, and the clause's own compliance is set later in the Requirements workspace.

Five issues, each raised from the session that found it. The independent presence indication and interlocked release, Critical, owned by site engineering, a condition of commissioning. The bay screen relocation to centre-left, High, owned by the project. The blind schedule on the west glazing, Medium, owned by facilities. The alarm configuration change from eight to three, Medium, owned by the controls engineer, and set to Transferred once it entered the site's own change process, because the register keeps "someone else owns this" apart from "this is done". And the truck queueing at the gate, Medium, owned by dispatch, which is the issue that surprised the meeting most. Each carries its linked user requirements and the session as evidence.

In the Requirements workspace the ISO 11064 workstation and display clauses are set Compliant on the ErgoDesign session, the lighting and glare clause Compliant on the ErgoGlare session with the blind schedule named in the justification, and the part 5 clauses on alarms and their presentation Compliant on the ErgoAIR worksheet. The clauses on grouping displays and controls are Partially Compliant until the relocation is installed, with the relocation issue raised against them and a residual risk statement. Every clause in the workspace came in through the Custom tab, and nothing in the cards, Designated, Compliant, Non-Compliant, Not Assessed, treats a typed standard differently from a library one, which is as it should be.

The EHFA from stage 1 and the Integration Plan from stage 3 are finalised and signed, freezing each as a dated, hashed version. The close-out wizard then asks for the argument: each requirement closed with its evidence, every issue traced to a requirement, and the four sub-claims positioned and reasoned. The Influence sub-claim carries the finding the project pushed back on hardest, the relocation, and the way it was resolved: the render from 4.3 shown at the change meeting. The conclusion was Implemented with conditions, the conditions being the presence indication and the relocation, both due before commissioning. The compiled deliverable is Part I, the assurance summary; Part II, the frozen EHFA; Part III, the frozen plan; and one appendix per session: the link analysis, the ErgoDesign model, the ErgoGlare study, the ErgoAIR worksheet, the HTA and the SHERPA.

Reports marked ready, composed into one package, issued as Revision A to the site's engineering manager for the free Viewer. The comment that came back was anchored to the ErgoGlare assessment: the facilities lead wanted to know whether a film on the glazing would do instead of a blind. The model answered it in an afternoon, a film alone came in at 0.36, and Revision B carried the answer with the blind schedule kept and the film noted as the fallback if the blind failed. Import a Returned Package had filed the comment where it was written, and it was resolved against the revision that answered it.