When the Grid Was Still Live at the Access Point: Myer, Geek+ and the Ravenhall Robot-Grid Fatality Through an ISO 14119, ISO 14118 and ISO 13849-1 Lens

Two years after a 27-year-old contractor was crushed inside an automated warehouse, the regulator has told us what it thinks was missing, and it did not say "better training" or "more careful workers." It said the access points to the robot grid were not guarded by an interlocked physical barrier, and that access did not happen only after the grid was de-energised and locked out. Those two sentences are a complete safety-requirements gap written in OHS Act language. This post translates them back into the work products that should have existed.

Everything below that concerns culpability is an allegation. WorkSafe Victoria has filed charges; no court has made a finding. I am reading the charge particulars as a statement of what the regulator believes the safeguarding architecture lacked, because that is the useful engineering signal, not because I presume the outcome.


The public record

The incident. On Monday, September 9, 2024, at about 3 pm, a 27-year-old man died at Myer's distribution facility on Momentum Way, Ravenhall, Victoria. WorkSafe's first release the next day said "it's understood the 27-year-old man was responding to a jammed item on an automated stock collection robot" and that he was caught between its moving parts (WorkSafe Victoria, September 10, 2024). Myer's executive chair, Olivia Wirth, referred to "the contractor's family, friends and colleagues," which indicates he was not a Myer employee (Star Weekly).

The charges. WorkSafe announced on September 3, 2026 that it had charged Myer Pty Ltd and GeekPlus Australia Pty Ltd. It described the death as contact with "an energised and operating automated robot" (WorkSafe Victoria, September 2026). The structure of the charges matters:

What the system is. The public record does not name the robot model involved in the incident, and I will not guess. What Myer announced at planning stage is a new national distribution centre using about 200 autonomous robots across two systems: Korber sortation robots, and a Geek+ RS8 shuttle system described as the largest of its kind in the Southern Hemisphere, which "moves products from shelves to staff" (realcommercial.com.au). The charge language, "robot grid," is consistent with a goods-to-person architecture in which robots run on or within a storage structure that people occasionally have to enter.

The commercial context. The site went live in 2024 and has since been the subject of a "series of automation and software issues" and a multi-million-dollar remediation program, with full capacity not expected until 2027 (Inside Retail). I draw no causal line from that to the death. I note only that a facility still being debugged generates more jams, and every jam is a reason for someone to reach into the machine.


The standards lens

This is a machinery-safety problem, not a robot-arm problem, so the lens is the machinery family rather than ISO 10218. A grid of shuttle robots is typically treated under the automated storage and retrieval and driverless-vehicle families (EN 528 for storage and retrieval machines, ISO 3691-4 for driverless industrial trucks where the machine falls in that scope), with the generic machinery standards doing the actual work on access. Which product standard applies to a given grid is a scoping question the manufacturer must answer in the technical file. The generic chain is not in doubt.

ISO 12100 Clause 5 and §6. The risk assessment must identify the task "clear a jam inside the grid" as a foreseeable intervention, not a misuse. §6.2 (inherently safe design) comes first: can the jam be cleared from outside the hazard zone, by a recovery tool or a cleared-from-the-edge procedure? §6.3 (safeguarding) comes second. §6.4 (information for use) comes last and is the weakest layer. The OHS Act's section 21(2)(e) supervision allegation lives in that last layer, and a supervision control is a procedural barrier standing in for an engineered one.

ISO 14120 and ISO 14119. The "interlocked physical barrier" in the charge particulars is exactly the construct these two standards define: ISO 14120 for the guard itself (fixed or movable, with dimensions and openings that resist reach and defeat), ISO 14119 for the interlocking device that makes opening the guard remove the hazard. ISO 14119 is where you find the requirements on coding level, defeat resistance and, critically, guard locking: if stopping the hazard takes time (a robot coasting, a drive stored-energy discharge), the guard must stay locked until the hazard has gone.

ISO 14118 and IEC 60204-1. The "de-energised and locked out" half of the particulars is the prevention of unexpected start-up (ISO 14118) and the isolation and energy-dissipation requirements of the electrical equipment standard (IEC 60204-1). In a grid with many independent battery-powered robots, "de-energised" has a nasty definition problem: there may be no single mains disconnect that makes it true. The isolation concept has to be designed, not assumed.

ISO 13849-1. Any safety function that stops the grid when an access panel opens needs a required Performance Level from the Annex A risk graph, an architecture category, diagnostic coverage and MTTF values. For a crush hazard from a moving machine with a person fully inside the working envelope, the risk graph will typically land at PL d or PL e, but that is the output of an assessment, not a rule of thumb, and I am not asserting what Ravenhall's number should have been.

ISO 13855 and ISO 13857. Where a person can reach or step through an opening, safety distance calculations decide whether a light curtain, a door switch or a full interlocked door is enough, and whether a person can stand in the grid behind the sensing plane. The "stand-behind" problem is the classic failure of a reach-in safeguard.

The work products that should have been on the shelf: a task-based risk assessment listing jam clearing, a safety-function specification for the access points, a PL verification record, and a lockout procedure validated by actually doing it.


A worked snippet

Here is how I would write the access hazard as a risk-assessment row. All values below are illustrative engineering judgments for demonstration, not facts from the record.

| ID | Task / phase | Hazard | Foreseeable event | Severity | Exposure | Avoidance | Required PL | Risk reduction | |----|--------------|--------|-------------------|----------|----------|-----------|-------------|----------------| | RA-07 | Clear jam inside grid | Crushing between moving robot and structure | Person enters grid while neighbouring robot is energised and moving | S2 (fatality) | F2 (frequent in commissioning) | P2 (cannot reliably avoid) | PL e | Interlocked, guard-locked access door; zone isolation before entry | | RA-08 | Clear jam from edge | Crushing at reach-in point | Reach through opening toward moving robot | S2 | F2 | P1 | PL d | Opening geometry per safety distance; reach-in zone muted by sensing | | RA-09 | Restart after clearing | Unexpected start-up with person inside | Remote or automatic restart while person is in zone | S2 | F1 | P2 | PL d | Restart only by deliberate reset, performed from where the whole zone is visible |

And the fault tree for the top event the charges describe:

TOP: Person inside grid zone while a robot in that zone is energised and moving
 |
 +-- OR ---------------------------------------------------------------+
 |                                                                     |
 A. Access opened without hazard removal             B. Person enters without opening a door
 |                                                    |
 +-- A1 No interlock on access point                  +-- B1 Opening large enough to step through
 +-- A2 Interlock defeated / bypassed                 +-- B2 No sensing of presence behind opening
 +-- A3 Interlock monitored but zone not isolated     +-- B3 Edge-recovery procedure not available
 +-- A4 Lockout procedure not applied (social control)
 |
 +-- C. Hazard not removed after access granted
      +-- C1 Zone isolation does not cover adjacent robots
      +-- C2 Remote restart / traffic manager re-dispatches into zone
      +-- C3 Stored energy or coasting not accounted for in guard locking

Branch A4 is the one every incident investigation finds, and it is the weakest control in the tree: it is the section 21(2)(a) lockout allegation and the section 21(2)(e) supervision allegation in one box. A and C1-C3 are the engineering branches. Notice that C2, the traffic manager re-dispatching a robot into a zone where a person is working, is a software-and-fleet problem, not a mechanical one, and almost no one writes a requirement for it until a zone-based restart has been designed to be impossible.


Derived requirements (excerpt)

Traceable to RA-07 to RA-09. The timing and threshold values are placeholders that a real project would derive from stopping-time measurement and the ISO 13855 calculation for its specific geometry.

| ID | Requirement | Verification | |----|-------------|--------------| | SR-GRID-001 | Every opening into the grid working envelope shall be closed by a guard meeting ISO 14120 whose opening is monitored by an interlocking device meeting ISO 14119 with guard locking. | Design review; ISO 14119 coding and defeat-resistance check | | SR-GRID-002 | Opening an access guard shall cause every robot in the associated zone to reach a safe state, with all drive energy removed or disabled, within 2.0 s of the request, and the guard shall not unlock until stop confirmation is received or a measured run-down time of 5.0 s has elapsed. | Stopping-time measurement per robot type, worst-case payload | | SR-GRID-003 | The access safety function shall achieve at least the PL determined in RA-07 (PL e as illustrative) with architecture, diagnostic coverage and MTTF documented per ISO 13849-1. | ISO 13849-1 verification record; fault-injection test | | SR-GRID-004 | The traffic and fleet manager shall be unable to dispatch, wake or restart any robot into a zone while a zone-access request is open or a personal lockout key is held. This shall be enforced by the safety channel, not by the fleet software alone. | Fault-injection test with fleet software forced to command motion | | SR-GRID-005 | Return to automatic operation shall require a deliberate reset at a location with unobstructed view of the whole zone, and shall not occur if a zone-presence check reports occupancy. | Commissioning test; walk-through with test person |

SR-GRID-004 is the one I would fight for in a design review. A guard-locked door is a decades-old solved problem. A fleet manager that does not know a human is inside its map is the new hazard that grids introduce.


What the headline really tells us

The headline says a worker died inside an automated warehouse and two companies were charged. Read as an engineering artifact, it says that the cheapest, oldest control in machinery safety, a door that cannot be opened while the machine is dangerous, is alleged to have been absent where the people-versus-robots interface was busiest. That is not a novel-technology problem. Interlocked guards and lockout are taught on the first day of any machinery safety course.

What is novel is the exposure pattern. A warehouse grid is a machine that jams routinely and is run by a business that earns money only when it keeps moving. That combination produces constant, economically motivated entry. A risk assessment that treats entry as an exception will generate controls (training, supervision, a laminated procedure) that wear out under production pressure. One that treats entry as a daily operating mode generates a rated safety function, an isolation concept and a recovery tool, because entry is what the machine will actually do.

The missing artifact is a maintenance-access safety function specification with a verified Performance Level, authored before commissioning and tested against the real fleet software. If you operate or build a grid, ask for it. If the answer is a procedure document, you have found your next finding.

— Jherrod Thomas, The Lion of Functional Safety™

Sources