The Integrator's Guide to the System-Level Safety Case

ISO 10218-2 is the safety standard for integrated robot applications and robot cells, and it assigns responsibility for system level safety to the party that builds the system. That party is the integrator, and the robot manufacturer's obligations end well before the cell exists.

That single allocation of responsibility surprises more integration teams than any other fact in robot safety. The robot arrives with all the right markings. The gripper is CE marked. The safety PLC is certified to the highest performance level money can buy. And none of it certifies the cell those components now live in.

Certified components don't add up to a certified system. The standard is explicit about why: hazards emerge from integration itself. The reach of the arm plus the layout of the fencing. The speed of the conveyor plus the position of the operator station. The interaction between the robot's safety functions and the cell's control architecture. No component supplier assessed any of that, because no component supplier could. Those hazards didn't exist until the pieces came together.

What does ISO 10218-2 actually require from integrators?

Part 1 of ISO 10218 covers the robot as a machine. Part 2 covers everything the integrator adds: the application, the cell, the safeguarding, and the validation that the assembled system is safe. The 2025 revision of both parts made the split even more explicit, expanding the integration requirements and pulling collaborative applications into the main standard.

For the team that assembles the cell, the obligations cluster into four kinds of work:

A risk assessment of the integrated system. ISO 10218-2 points to ISO 12100 methodology: identify the hazards of the assembled application, estimate and evaluate the risks, and reduce them to an acceptable level. This is the document your customer's insurer, auditor, or assessor will ask for first.

Safeguarding decisions with rationale. Fencing, light curtains, speed and separation monitoring, safe zones. Every choice needs a documented reason connected to a hazard instead of a habit carried over from the last project.

Functional safety verification. The safety functions of the cell, from the emergency stop chain to the interlocks, have to achieve the performance levels the risk assessment demands. ISO 13849 governs that math.

Validation of the assembled system. Evidence that the cell, as built, behaves the way the safety design says it does. Written test records with dates and signatures.

Assemble all four with traceability between them and you have a system level safety case: the documented argument that this specific cell, in this specific application, is safe to operate.

Why do integrators get caught by this?

Because the purchase conversation happens long before the safety conversation. The purchase order covers robots, tooling, controls engineering, and commissioning. Safety engineering appears nowhere as a line item, so nobody scopes it, prices it, or assigns it. Then the end customer's procurement checklist asks for the risk assessment, and the integrator discovers they own a deliverable they never planned.

The industry pattern behind this is familiar. Safety work at most companies runs on a patchwork of disconnected tools: risk assessments in spreadsheets, requirements in documents, test evidence in another system entirely. For an integrator running multiple concurrent projects, that fragmentation means every new cell starts from a blank page, and 60% of the safety effort goes to documentation instead of actual engineering judgment.

Integrators who learn the responsibility allocation after the purchase order eat the cost. The ones who know it going in write better contracts, scope the risk assessment at kickoff alongside the electrical design, and hand their customer a complete safety case at commissioning. That second group has turned a legal obligation into a selling point. In a market where most cells ship with a shrug, a complete, traceable safety case wins contracts.

What does a system level safety case include?

A defensible safety case for a robot cell contains six connected elements:

1. Hazard identification for the assembled application, covering normal operation, setup, maintenance, and foreseeable misuse.

2. Risk evaluation for each hazard, using ISO 12100 methodology, with the required risk reduction stated.

3. Safety requirements derived from that evaluation, including required performance levels per ISO 13849.

4. Safeguarding design showing how each requirement is met, with the rationale recorded next to the decision.

5. Verification evidence that the safety functions achieve their required performance levels.

6. Validation records demonstrating the cell as built matches the safety design.

The hard part is the connections between those six elements. An assessor, an auditor, or a customer's safety engineer will pick a hazard and trace it forward to the test record that proves it's controlled. If the thread breaks anywhere, the questions start, and every question costs schedule.

How ASAP handles the integration safety case

ASAP was built around exactly this traceability problem. The platform guides the full sequence, from an ISO 12100 compliant hazard analysis that updates dynamically as the design changes, through requirements definition, reliability modeling for Performance Level and SIL calculations in the browser, to assessor-ready documentation generated with one click. Pre-configured templates for autonomous mobile robots, collaborative robots, and industrial machinery mean an integration project starts from a structured baseline instead of a blank page.

For integrators, the practical difference is reuse. The hazard patterns of a palletizing cell or a cobot station don't reinvent themselves on every project. A structured platform lets the second project inherit the framework of the first, so the safety case becomes faster with each cell instead of starting over.

The methodology has scale behind it. ASAP was developed over 5 years inside Amazon Robotics, where it protects a fleet of more than 1 million robots in 24/7 operation. It carries T2 Tool Qualification from both TUV Rheinland and HORIBA MIRA, which means the toolset itself has been independently audited to confirm it reveals defects without introducing errors. When the safety case you hand your customer comes out of a qualified toolchain with the traceability built in, the review conversation gets short. One team's assessor didn't even ask follow-up questions. They just asked for the output.

If your next integration project includes a safety case your customer expects and your team hasn't scoped, that's a solvable problem. Talk to Fennec about structuring it.