Per-MW pricing, regional variance, and cost drivers for owners scoping hyperscale & AI builds.
Salary benchmarks across the 14 mission-critical disciplines.
If I own the project, I can’t leave robot safety scope to the OEM or integrator. Under ISO 10218 and ANSI/RIA R15.06, the robot maker covers the robot, but I still need to define the cell, site limits, risk review outputs, safeguard rules, test checks, and turnover documents before design starts.
Here’s the short version:
A lot of project delays come from late safety decisions. Guarding height, access paths, interlocks, and stop logic affect layout, hardware, wiring, testing, and schedule. If I wait until commissioning, I’m more likely to get redesign, retesting, and added cost.
What I take from this article is simple: the owner has to set the safety target first. That means writing down intended use, manual and automatic modes, foreseeable misuse, facility limits, approval roles, required safety outputs, and startup proof. If that scope is clear at the start, the design team knows what they have to build and prove.
ISO 10218 vs RIA R15.06: Robot Manufacturer vs Owner-Integrator Scope
ISO 10218 comes in two parts, and that split shapes the whole project scope. Part 1 covers the robot product. Part 2 covers the installed cell. In the U.S., ANSI/RIA R15.06 adopts ISO 10218-1 and 10218-2 for robot manufacture, integration, installation, and safeguarding.[9][3][10]
That distinction matters more than it may seem at first. If an owner focuses only on buying the robot arm, they're looking at only part of the job. For owners, the scope has to cover the installed system, not just the robot itself. Compliance is judged at the cell level, so anyone who scopes only the arm misses the cell-level duty.[5][9]
The robot supplier's job ends with the product. The integrator and the owner take on the installed cell.
Under ISO 10218-1 and R15.06 Part 1, robot manufacturers are responsible for the robot's built-in safety features and the documents that support safe use. That includes inherent safe design, safety-related control functions such as emergency stop circuits, safe stop categories, and motion limits.[4][5][7]
But the robot product is only one piece of the final system. The manufacturer does not take responsibility for the workcell layout, guarding, end-of-arm tooling hazards, or how the robot connects with nearby equipment.[8][5]
Everything beyond the robot itself shifts to the integrator and owner. ISO 10218-2 and R15.06 Part 2 require the installed cell to be engineered around a task-based risk assessment. They also cover the safeguarding layout, interlocks and emergency-stop design, a safety-rated control system, and validation of the protective measures in the final installed setup.[8][5]
This is where projects can go sideways. A conveyor feeding a robot without proper safeguards, a maintenance access route left unprotected, or stop logic that was never validated are all integration failures. And the standards hold the full system accountable.[6][7][8]
This boundary is the key owner-side scoping question.
That line between product scope and cell scope drives the owner's scoping decisions.
ISO 10218-2 and R15.06 also make it clear that safety rules apply across the full lifecycle of the robot installation.[7][9] So the scope shouldn't stop at design and startup.
Owners should cover:
One of the best ways to avoid late surprises is to require the integrator to document safety requirements and procedures for each lifecycle phase.[8][9]
With the boundary between robot product scope and cell scope set, the next move is to document intended use, operating modes, and site constraints.
Most commissioning issues start with scope. If the scope is set before procurement, owners can avoid redesigns, extra hardware, and schedule delays. These early calls also set the inputs for the risk assessment, the safeguard layout, and the validation criteria.
Before sending out any bid package, owners need a written application definition for each cell. That definition should cover the main task, the product range, the weights the robot will handle, the target cycle time, expected throughput, and each operating mode. That includes automatic production, manual intervention, teaching with a pendant, recovery or jam clearing, maintenance, and cleaning. It should also spell out who will enter the cell, how often, and why, including operators, mechanics, sanitation crews, quality inspectors, and outside contractors.[16][22]
That detail matters more than it may seem at first glance. A cell built for fully automatic operation, with only occasional human entry, needs a very different safeguarding approach than a cell where people step in several times per shift for checks or changeovers. Those differences shape choices around safety-rated speed functions, enabling devices, interlocked access points, and presence-sensing coverage.[16][18]
ISO 12100 defines predictable misuse, or reasonably foreseeable misuse, as use of a machine in a way not intended by the designer but resulting from readily predictable human behavior.[1][20][21] In plain terms, people do not always work the way the procedure says they should. Owners and EHS teams should write down misuse scenarios that are realistic for their site, such as:
Without that input, the risk assessment can end up describing a perfect world instead of the one on the plant floor.
Those use cases then shape the layout and access limits that come next.
The Basis of Design (BoD) should reflect the site as it actually is, not as people wish it were. It needs to define the cell footprint and clearances, minimum walking aisles, maintenance access zones, ceiling height, and nearby traffic paths, including conveyor routing, pallet lanes, and AGV travel routes. The goal is simple: give the integrator enough detail to place interlocked doors, emergency stops, and egress paths correctly the first time, instead of fixing them later through redesign, extra purchases, and startup delays.[14]
U.S. guidance calls for fixed perimeter guarding at least 60 inches (1,524 mm) high with no more than 6 inches of clearance at the floor, so guarding geometry should also be written into the BoD.[14]
ISO 10218-2 adds another layer. It requires access paths that do not expose operators to slipping, tripping, or pinch-point hazards, and it says openings for material entry and exit should be kept to a minimum.[6][12] If the cell sits next to a manual packing station, a forklift aisle, or a busy walkway, that interaction should be spelled out up front, not left for the integrator to spot during a site visit.
In life sciences or GMP spaces, the BoD also needs to cover cleanroom classifications, gowning rules, material segregation requirements, and any limits on wall or ceiling penetrations that could affect guarding or enclosure design. Utility interfaces belong there too, including 480 V three-phase service, compressed air pressure and flow, vacuum, safety network architecture, and any process utilities. Those details drive the location of disconnects and lockable isolation points.[16]
Once those site limits are clear, the next step is to decide who owns the safety calls.
Someone must be accountable for the risk assessment, and that decision should happen before the bid package goes out, not after purchase orders are signed. ISO 10218-2 and RIA R15.06 make it clear that the end user keeps ongoing responsibility for the safe use of the installed system and must approve the final risk-reduction measures.[17][19] The owner keeps approval authority, while the integrator carries out the assessment.
Procurement documents should say this plainly: the integrator must produce a formal risk assessment using ISO 12100 and ISO 10218 methods, and the owner’s EHS representative must review and sign off before the design is frozen. The BoD and contract exhibits should also name the minimum qualifications for the person leading the assessment, such as a certified safety professional or an engineer with documented robotic safety training, and list the required review workshops and sign-off milestones.[17][18]
That structure helps keep safety decisions from being made on the fly under schedule pressure by project managers or vendors who are not the right people for the job.
The ownership split is straightforward:
These choices become the direct inputs for the risk assessment and safeguarding design discussed next.
Hiring for a mission-critical build? Get a pre-qualified shortlist.
iRecruit.co specializes in construction recruiting for data center, energy, and advanced-manufacturing projects — project managers, MEP coordinators, commissioning leads, and more. We pre-screen every candidate so only qualified professionals reach your hiring team.
Get Started
Success-based pricing · 90-day replacement credit · No upfront fee on single roles
Owners should put these safety outputs into the scope before procurement. The risk assessment should be scoped as a design input, not a closeout document. That way, it produces the hazard register, safety-function list, residual-risk notes, and open-item register needed all the way through turnover.
Once ownership is assigned, the assessment needs to produce the documents that set the safety basis. Require a task-based hazard register tied to each hazard, task, severity, probability, and residual-risk note. That register should cover robot motion envelopes, tooling and end effectors, pinch and crush points, stored energy sources, dropped or suspended loads, unexpected startup or restart after power loss, and interface hazards at conveyors, pallets, AGVs, and manual load/unload stations.[21][23]
The assessment should also produce a safety-function list that names each required control, explains which hazard it addresses, and defines the safe state it must achieve. Keep an open-item register for unresolved hazards, temporary safeguards, bypasses, and pending field changes. That register should stay active through design, commissioning, and turnover.
The safety file should show these items in order:
That sequence needs to be clear in the record.[32][21] If even one piece is missing, the assessment is not finished.
Require drawings that show fixed guards, interlocked gates, presence-sensing devices, safe access zones, reach-distance clearances, reset points, lockout points, and maintenance access provisions. The documents should spell out where a person can stand, reach, or enter, and how the system blocks exposure during automatic cycles, manual setup, and fault recovery.[13][29][11]
Use fixed guards to block access. Use interlocked guards to stop motion when access is opened. The risk assessment should decide which one applies at each access point based on the highest-risk task and hazard combination.[23][26]
Emergency-stop details should be set up front: placement, labeling, stop behavior, and restart rules. Restart after an interlock trip, e-stop, or power loss should require a deliberate, verified reset.[13][28][29]
Acceptance criteria for emergency stops should call for accessible placement, confirmed stop response, and tested restart logic under actual operating conditions. A factory demo alone isn't enough.
Every safety-rated control function - safe torque off, safe stop, safe speed monitoring, safe position limiting, protective stop logic, and restart interlocking - should be named in the scope and tied to a specific hazard and a defined safe state.[29][31]
The integrator should also document interface points between the robot controller, safety PLC, drives, gate interlocks, and upstream/downstream machines. If that handoff isn't clear, hazard-control paths can get muddy across vendors or subsystems.[27][32]
Stopping performance verification must happen under actual operating conditions. Require measured stop time or distance with configured tooling, normal payloads, realistic speeds, and fault, jam, and maintenance conditions. Acceptance criteria should state the measured stopping distance or time, the test conditions used, and confirmation that the hazard stays outside the reachable zone before motion ends.[30][13]
These scope items should be written as explicit deliverables for integrators and vendors, with validation checkpoints before startup.
Once the risk assessment outputs and safeguarding criteria are set, the next job is making sure they show up in contracts and startup plans, not just in design files. This is where a lot of projects slip. Owners assume integrators know what to deliver. Integrators assume owners will ask. Then startup gets held up because a safety file is missing or a test never happened.
Require a signed compliance statement from the integrator and key vendors confirming that the robot, robot cell, and safety systems are designed and implemented in line with ISO 10218-1/2 and ANSI/RIA R15.06, including RIA TR R15.306 when it is used for risk assessment methodology. The statement should name the standards and revision levels used and note any justified deviations.[4][25][24]
Require a completed, documented risk assessment for the robot system and cell, prepared and owned by the integrator. It should cover task and hazard identification, initial risk estimation, risk reduction measures, residual risk evaluation, and verification and validation of the risk reductions. That assessment should be updated as the design develops and finalized before commissioning.[16][1][2][24]
Safety function descriptions should spell out the function, triggering devices, safety category or performance level, safety PLC or relay architecture, and reset/restart behavior.[11][24][8] Also require the engineering backup: safety I/O lists, wiring diagrams, safety logic narratives, device data sheets, manuals, and spare parts lists.[16][33][11][8] Training plans belong here too, with the audience, duration, content, and competency verification methods clearly defined.[33][1][8]
That split should be written into contracts before procurement closes:
Every one of these items should be listed as a contractual submittal with a due date tied to design milestones, not closeout.[16][33][11][8] That point matters. If you wait until the end, you're already behind. Safety I/O lists, wiring diagrams, and logic narratives also matter long after startup. Maintenance teams need them to troubleshoot faults and make later changes without weakening safety performance.[16][33][11][8] Use these submittals as the backbone for FAT, SAT, and startup approval.
Use FAT and SAT to prove the safety functions listed above under actual operating conditions. Require integrators to build structured test plans that cover the checkpoints below before any startup approval is granted:
FAT testing at the vendor's facility is only a starting point. SAT needs to repeat and extend those checks after installation at the actual site, with real products, normal speeds, usual staffing patterns, and fault scenarios that match day-to-day operation. That is what shows whether safeguards still work the way they should when the cell is running the way it will run in practice.[16][1][11]
After SAT passes, lock down the full turnover package before startup approval. The package should include the final signed risk assessment record, approved safety drawings and layouts, FAT/SAT test results, punch list closure confirmation, residual risk communication in plain language for operators and supervisors, training records for all relevant personnel, inspection and maintenance procedures for safety devices, and change-control rules for future program, tooling, layout, or safety changes.[15][34][33][11][8]
Change-control rules need special attention. Any change to robot programs, tooling, layout, or safety systems after startup should go through a defined review, approval, and revalidation process so the system does not drift out of compliance over time.[2][24] Require integrators to hand over those rules as part of the package, not as an afterthought.
The project owner has the final say on robot cell safety compliance. They can hand off technical tasks like risk checks and design work to project teams, vendors, or integrators. But the owner still carries the top-level responsibility for the facility’s goals and safety standards.
Compliance also means building safety zoning into the design from the start. That includes measures like physical guarding, light curtains, and interlocked sensors. Those controls need to line up with OSHA and ANSI/RIA standards.
Before design starts, set the safety scope in a formal Owner’s Project Requirements (OPR) document. That document should spell out measurable goals for performance, safety, and compliance. If those targets are vague at the start, teams usually pay for it later.
It also helps to run a safety scope workshop early. Use it to map work packages against ISO 10218, RIA R15.06, OSHA, and NFPA, so everyone is working from the same playbook. At that stage, define safety zoning as well. That gives the design team clear boundaries before layouts and controls start to harden.
Keep a centralized risk register from the beginning, with input from both commissioning and safety teams. That way, issues don’t get buried in separate spreadsheets or left hanging between design, build, and startup.
Before startup, project owners should put together a turnover package that shows the facility is ready to run. Think of it as the handoff file that proves the job is done and the site can move into operation.
This package usually includes as-built drawings, vendor installation and operation manuals, calibration records, and equipment material certificates.
It should also include:
In regulated environments, add validated commissioning, qualification, and training records.
