> ## Documentation Index
> Fetch the complete documentation index at: https://docs.roboticks.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Industrial Robot - ISO 10218-1:2025
> End-to-end workflow for a robot manufacturer pursuing ISO 10218-1:2025 conformity. Ingest the standard, derive requirements, write tests, structure releases, hand to TÜV or UL.
# Industrial Robot — ISO 10218-1:2025
This pattern is for **robot manufacturers** — organisations that build the industrial robot arm, its controller, and the firmware that ships with it. The conformance target is [ISO 10218-1:2025](/standards/iso-10218) and the harmonised standards stack that supports presumption of conformity to [EU MR 2023/1230](/standards/eu-mr-2023-1230).
The integrator side (the cell-building side) follows the parallel pattern under ISO 10218-2:2025, which shares most of the workflow.
**Roboticks is audit-readiness tooling, not a certified toolchain.** We assemble the evidence your notified body, certification body, or QA process ingests. We do not replace tool qualification (DO-178C, ISO 26262-8 TCL) and we do not issue conformity assessments. Verify the regulatory interpretations on this page against the standard text and your accredited assessor.
## Scenario
You manufacture an industrial robot arm. Customers will integrate it into their cells. Your obligations:
* Produce a robot that satisfies ISO 10218-1:2025.
* Provide instructions for use that let an integrator build an ISO 10218-2:2025-conformant cell.
* Document risk-reduction measures, safety-rated software, safety functions, performance levels.
* Maintain a technical file that supports EU-type examination (Annex IX of EU MR 2023/1230).
* Re-conformance on standard amendments and on substantial modifications to the product.
## Prerequisites
| Off-platform | Why |
| ---------------------------------------------------------------------------- | ---------------------------------- |
| Risk assessment per ISO 12100 | Inputs the requirement derivation |
| PL determination per ISO 13849 (or SIL CL per IEC 62061) per safety function | Drives `asil_pl` on requirements |
| Safety-rated component supplier certifications | Reference in `architecture.yaml` |
| Notified body engaged (for Annex I high-risk machinery) | They will ingest the evidence pack |
## Project setup
From the dashboard or `rbtk project create`. One project per robot product family.
```bash theme={null}
rbtk standard template apply industrial-robot-eu --project acme-robotics/firmware
```
Pins: ISO 10218-1:2025, ISO 10218-2:2025, ISO 12100, EN ISO 13849-1, IEC 62061, EU MR 2023/1230. Confirm the included subscription on Team or the additional billing on multi-standard pin.
Install the [GitHub App](/github-app/installation) and link the firmware, messages, and any subordinate repos.
Export hazards to `roboticks/hazards.yaml`. See [ISO 12100](/standards/iso-12100#the-hazardsyaml-pattern).
Write `roboticks/architecture.yaml` per [IEC 62061](/standards/iec-62061#the-architecture-as-config-pattern). Lists safety functions, subsystems, and their SIL CL or PL.
## Derivation
Author requirements covering, at minimum, every clause of ISO 10218-1:2025 that the risk assessment identifies as applicable. The platform's LLM-assisted derivation (Team and Enterprise) suggests requirement text from clauses; you ratify.
A typical industrial-robot project ends up with 150–400 requirements across:
| Area | Requirement count (typical) |
| ------------------------------------ | --------------------------- |
| Stop functions (§5.4) | 10–20 |
| Safety-rated monitored speed (§5.6) | 5–15 |
| Safety-rated monitored stop (§5.10) | 5–10 |
| Operating modes (§5.7) | 10–15 |
| Pendant / teach controls (§5.8) | 15–25 |
| Collaborative operation (§5.10–5.11) | 20–50 (if PFL) |
| Safety-rated software (§5.12) | 20–40 |
| Cybersecurity (§5.13 new in 2025) | 10–20 |
| Documentation (§7) | 20–30 |
Every requirement has `derives_from` pointing at the exact clause and edition, `asil_pl` (or `category`), `mitigates_hazards` linking to the risk assessment, and `acceptance` listing the confirming tests.
## Test patterns
The dominant patterns for an ISO 10218-1:2025 project:
| Pattern | When |
| --------------------------------------------------- | ----------------------------------------------------------- |
| `@deadline` + protective-stop assertion | Stop-function clauses |
| Parameterised scenario set + sim-measured TCP speed | Speed-limit clauses |
| Fault injection + safe-state assertion | Safety-rated monitored stop, Category 3/4 functions |
| Contact-force capture (sim or HIL) | PFL collaborative operation (cross-derives to ISO/TS 15066) |
| Coverage thresholds (`coverage_required` field) | Safety-rated software clauses |
| SARIF aggregation | Cybersecurity clauses |
| Mode-transition tests | Operating-mode clauses |
See the [SDK examples](/sdk/examples) for code-level recipes.
## Release
`rbtk release cut --tag v3.1.0` (or via dashboard).
Every required test runs on the pinned commit set. The release auto-promotes to `verified` on full pass. Gaps surface for triage.
```bash theme={null}
rbtk test evidence-pack --release v3.1.0 --format pdf,zip,reqif
```
On actual shipment to customers, `rbtk release ship v3.1.0`. The 10-year retention clock starts.
## Handoff
Hand the pack to your notified body per the [customer-handoff procedure](/evidence/customer-handoff). For ISO 10218-1:2025 specifically, expect the assessor to:
* Sample-verify the hash chain (`rbtk evidence verify-chain`).
* Drill into the safety-rated software section — coverage thresholds, SARIF findings.
* Spot-check requirements derived from §5.4 (stop functions) — the most-scrutinised clause area.
* Request MCAP restores from Glacier for specific collaborative-operation scenarios (if PFL).
* Request a re-verification on a chosen subset of tests, to confirm reproducibility.
## Maintenance
| Event | Action |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| ISO 10218-1:2025 amendment lands | [Re-conformity workflow](/compliance/re-conformity-on-amendment) |
| Substantial product modification | New conformity assessment — cut a new release with derivation impact reviewed |
| Annual surveillance audit (under Annex IX route) | Regenerate evidence pack for the year's releases; hand to assessor |
| Customer field issue | Generate ad-hoc pack scoped to the suspect commit; investigate; re-verify the latest release |
## What this pattern does not cover
* **Integrator-side (cell) conformity** — see ISO 10218-2:2025; the pattern is mirror-image.
* **Component supplier certification** — your safety-rated drives, controllers, sensors come with their own certifications. Reference them in `architecture.yaml`; do not re-certify in Roboticks.
* **Annex IV technical-file assembly beyond verification evidence** — see [EU MR 2023/1230 conformity](/compliance/eu-mr-2023-1230-conformity) for the full technical-file pattern.
## Next steps
The standard reference.
Technical-file assembly around the evidence pack.
If you are PFL.
Per-PR triage.