_{The arm is upstream's own image (media/v1.1_2.png, Seeed Studio, CC BY-NC-SA 4.0), set into the banner by docs/assets/rebot/banner.py. This fork is not affiliated with or endorsed by Seeed Studio.}

The engineering assurance record for a safety-assured fork of the reBot-DevArm desktop robot arm: machinery risk assessment under ISO 12100 and ISO 10218, a hardwired safety chain with a Performance Level target, collaborative-operation limits, cybersecurity and machine-learning safety, and a safety case published as it is built.

Built on Seeed Studio's reBot-DevArm. For the arm itself (assembly, bill of materials, software, tutorials) see upstream's repository and documentation.

Documentation  ·  Wiki  ·  Record status  ·  Architecture  ·  Standards  ·  Roadmap  ·  Known gaps  ·  Getting started  ·  Contributing  ·  Upstream reBot-DevArm

Why the record exists

The reBot Arm B601-DM is an open mechanical and actuator design with a broad software ecosystem, sold as a kit for embodied-AI research and teaching. What it lacks, by the fork's own concept-phase review, is the safety engineering a machine needs before it may work with a person in reach: there is no emergency stop in the documented design, no supply disconnect or fuse, no watchdog between the host and the actuators, no operating-mode state machine, no declared joint limits, no reliability data, no force or pressure measurement, no validation, and the software lives outside the fork. This fork keeps upstream's design and adds the record around it, under the standards that apply to an industrial robot.

The concept-phase engineering package the fork published first (reBot_DevArm_Safety_Case.xlsx and its companions in this folder: 34 hazards, 31 safety functions, 28 gaps, 104 requirements, 127 test cases) is the input to the record; its identifiers are kept and its gaps are re-stated as GAP-01 to GAP-36.

Record status

Every work product lives under assurance/, numbered in lifecycle order, with a document-control header that says what it is, which clauses it answers to, and whether anyone has reviewed it. Nothing is marked complete before its review, and every number below is computed from the records by make_assets.py and checked by CI on every pull request.

P0 Governance · no gate passed · 90 work products (30 draft, 60 skeleton, 0 approved) · 36 gap findings (19 high) · 3 decisions open · 1 of 11 cross-domain interfaces open · 0 of 22 confirmation measures performed · records digest 5bd183fe53cb

What the card guarantees
A gate counts as passed	only when its record in 10-safety-case/gates/ says Pass; a skeleton generated from the process model is not a record
A work product counts as approved	only after a verification review by someone other than its author (WP-P-05); a confirmation measure counts only by its record under confirmation/
The Living Safety Case dashboard	is generated from the records in assurance/case/: claims, evidence with review state, defeaters, actions, configurations and reviews, with a validator that refuses an accepted claim whose evidence is not available and accepted or whose defeater is open
The records digest	identifies the exact state of the register, the gap assessment, the decision register, the process model and the gate and confirmation records these figures describe, so two readers can confirm they saw the same state

Development · baseline BL-001 at 206ebda · 21 claims (0 with accepted evidence) · 20 evidence items (0 accepted) · 36 open defeaters · records digest b6ab708350b6

Start here: assurance strategy (WP-M-01) · safety plan (WP-M-02) · process model and maps (WP-P-11) · powered-test hold point (WP-V-07) · decision register

Assurance status represents recorded engineering evidence and review state. It does not constitute certification or approval for operation with a person in reach.

Safety architecture

The argument is a doer-and-checker argument with one more step. The host stack proposes; the controller safety layer checks; and a hardwired safety chain is the checker of last resort that nothing in software can override. Only the chain carries a Performance Level target. The safety layer and the host stack are hardened so that the chain is rarely demanded, and recorded as defence in depth.

Layer	Role	State
Host stack	The SDK, the ROS 2 driver, Pinocchio, the LeRobot policies, the web UI; everything that decides where the arm goes	Inherited and upstream; hardening proposed once forked (DQ-007)
Controller safety layer	Validates, clamps, times out and reports every command before it reaches the motor bus; the mode machine	Does not exist yet. Where it runs is DQ-020
Hardwired safety chain	Emergency stop, enabling, manual reset, power removal by contactor	Does not exist yet. Bench version first (WP-V-07, DQ-006), product version in the SRP/CS architecture
Safety and assurance	Risk assessment, safety functions and PLr, PL calculation, validation, cybersecurity, safety case	Draft and skeleton work products, not yet reviewed

More in the architecture overview and WP-M-01 §6.

Standards and engineering framework

The arm is machinery and an industrial robot, so the frame is the machinery set, applied with one method: one hazard log, one requirements database, generated figures, a safety case with its defeaters published. Work products are structured after these standards and cite their clauses; no compliance is claimed, because no assessment has been performed and no standard is held. WP-M-01 §4 explains how each standard is used and where it is tailored; the wiki's How we use each standard is the plain-language version.

Topic	Standard	Main work products
Risk assessment and reduction	ISO 12100:2010	Item definition · Risk assessment · Risk reduction concept
Industrial robots and robot applications	ISO 10218-1:2025, ISO 10218-2:2025	Safety functions and required PL · Operating envelopes
Collaborative operation	ISO/TS 15066:2016	Human-robot interaction · Collaborative operation validation
Safety-related parts of control systems	ISO 13849-1:2023, ISO 13849-2:2012	SRP/CS architecture · PL calculation · Safety validation
Where ISO 13849 runs out	IEC 62061:2021, IEC 61508:2010	Software safety requirements · Confirmation measures
Electrical equipment, emergency stop, gaps and distances	EN 60204-1:2018, ISO 13850:2015, ISO 13854:2019, ISO 13855:2024, ISO 13857:2019	Electrical safety · Mechanical analysis · Stopping and separation budget
Cybersecurity	IEC 62443-4-1:2018, IEC 62443-4-2:2019	Threat and risk assessment · Cybersecurity plan
Machine learning in safety functions	ISO/IEC TR 5469:2024	ML component definition · ML safety plan
Regulatory	Regulation (EU) 2023/1230 (Machinery), Regulation (EU) 2024/1689 (AI Act)	Regulatory conformity strategy
Safety case structure	UL 4600 principles	Safety case

Supporting practice	Where it is applied
Integrated process model	WP-P-11: activities, lanes, cross-domain interfaces and gates as data; generated swimlane maps and gate skeletons
Process capability	ASPICE self-assessment, WP-M-12
Performance limits of sensing and the learned policy	ISO 21448 used as a method, not a standard, in the insufficiency analysis
Safety analysis	FMEA · FTA · CCF · STPA · Independence of the chain
Independent review	Confirmation measures plan · Verification and review procedure
Decisions	Decision register: every question for the project lead, self-contained, in batches of ten

Roadmap

Status is taken from what exists in the repository. "Draft" means written but not reviewed; "skeleton" means the structure and clause map exist and the content is still to be written.

Phase	Work	Status
1 · Foundation	Assurance strategy, safety plan, confirmation measures, regulatory strategy	Draft
	Baseline gap assessment	Draft
	Work product register, process model and maps, decision register	Draft; checked by CI
	Living Safety Case records and dashboard	Draft: records at BL-001, validated and drawn by CI
2 · Safety engineering	Item definition, operating envelopes, risk assessment, safety functions and PLr, interaction and misuse	Draft, from the concept-phase package
	Risk reduction concept, insufficiency analysis, cybersecurity threat assessment, ML component definition	Skeleton
	Powered-test hold point	Draft; the bench chain waits on the lead (DQ-006)
3 · Build and verify	Bench safety chain, software fork and safety layer, chain architecture and PL calculation, stopping and holding tests, fault injection	Planned
4 · Validate and release	Safety validation, assessment, technical documentation, release record, field monitoring	Planned

Known gaps

The project publishes its own counter-evidence. The baseline gap assessment reviewed the hardware record and the concept-phase package, finding by finding, against the standards above. The findings that shape everything:

	Finding	Closes through
GAP-08	No emergency stop exists in the documented design; the only stop is a software command on the motor bus	The bench chain before any powered test with a person in reach (WP-V-07, DQ-006); the hardwired chain (WP-S-03)
GAP-09, GAP-11	No supply disconnect or fuse; an open-frame mains supply with exposed terminals	Electrical safety (WP-H-05)
GAP-16, GAP-17, GAP-18	The software is outside the fork; no mode machine; a lost connection holds the last command	Fork the software (DQ-007) and build the controller safety layer (WP-W-03)
GAP-19, GAP-02, GAP-03	No declared joint limits, end-stops, mass or fixing	Mechanical analysis (WP-H-08) and the parameter sets (WP-W-09)
GAP-28, GAP-06	No force or pressure measurement; no separation-distance plan	The collaborative-operation decision (DQ-005) and its validation (WP-V-03)
GAP-22, GAP-23	Anyone with the CAN adapter or the network can move the arm	Cybersecurity requirements and architecture (WP-C-08, WP-S-07)
GAP-14, GAP-31	No reliability data, no validation of any safety function	Supplier data (DQ-019), the PL calculation (WP-H-04) and the validation plan (WP-V-01)

Every finding becomes a defeater against a claim in the safety case and stays open until the work product that closes it is reviewed.

Hazard scenes on the real CAD

Fifteen hazards of the risk assessment are drawn on upstream's v1.1 CAD, posed by a joint rig at the moment the hazard occurs, with a person where the interaction analysis puts them and the link gap or distance against the ISO 13854 minimum gaps beside the package's rating and the stop functions that do not exist yet (WP-P-12, gallery). They are pictures for review: synthetic, no evidence credit, and nothing in the safety case rests on them.

Getting started with the record

Only Python 3 is needed (PyYAML for the decision register):

git clone https://github.com/jherrodthomas/reBot-DevArm.git
cd reBot-DevArm
python3 assurance/01-management/decisions/check_decisions.py     # the questions for the lead
python3 assurance/process/tools/process_model.py --check         # process maps and gate skeletons current
python3 assurance/tools/folder_index.py --check                  # folder indexes match the register
python3 docs/assets/rebot/make_assets.py --check                 # README figures match their generator
python3 tools/wiki/build_wiki.py                                 # the wiki pages check clean

On an arm: the fork publishes no software build and changes no hardware yet. No arm is powered with a person inside its 650 mm reach under the fork's control until the conditions of WP-V-07 hold: a fused and switched 24 V supply, a dual-channel emergency stop through a safety relay, the arm fixtured, pinned software with the watchdog on, and nobody but the operator at the bench.

Contributing to the record

Contributions are welcome in machinery and robot safety, safety-related control systems, electrical and mechanical engineering, embedded and ROS 2 software, cybersecurity, verification, documentation and review. Safety-relevant changes need a rationale, an impact analysis and appropriate verification.

Contributing	Rules for safety-relevant changes and assurance records
Issues · Pull requests	Problem reports, safety concerns, reviews of the analyses; pull requests target main
Security policy	Private vulnerability reporting
Wiki	Orientation: processes, process maps, how each standard is used, glossary, how decisions are made. Kept in wiki/ and mirrored on merge
Upstream reBot-DevArm	The arm this fork is derived from

The concept-phase engineering package

The package of 2026-05-04 stays at the repository root as the record's input; the files are not edited.

File	Purpose
reBot_DevArm_Safety_Case.xlsx	15-tab preliminary safety case (ISO 12100 / 10218 / TS 15066 / 13849 / 9001 / 60204-1): 34 hazards, 31 safety functions, 28 gaps
reBot_DevArm_Safety_Case_Report.docx	Narrative safety case
reBot_DevArm_Safety_Case_Summary.pdf	2-page executive summary
reBot_DevArm_DFMEA.xlsx	AIAG-VDA 2019 DFMEA: 27 failure modes (11 high action priority)
reBot_DevArm_Requirements.xlsx	SyRS, SRS and HwRS: 104 requirements, traced
reBot_DevArm_Architecture.docx	5 architectural views with embedded diagrams
reBot_DevArm_TestPlan.xlsx	V-model test plan: 127 cases, ISO 13849-2 and TS 15066 V&V matrices
reBot_DevArm_Trace_Memo.docx	Cross-package traceability verification
reBot_DevArm_Engineering_Bundle.pdf	Single-file stakeholder bundle
01_hero_banner.png … 05_mode_fsm.png	The package's banner, KPI, envelope and architecture figures

Maintainer and upstream attribution

Jherrod Thomas maintains this record as an open engineering initiative: a public demonstration of safety-lifecycle development, systems engineering and assurance practice on a real robot arm.

reBot-DevArm is designed and published by Seeed Studio under CC BY-NC-SA 4.0. This fork keeps that licence for the whole repository, including the record, and is non-commercial; hardware/ is upstream's record, merged and never edited here. The fork is an independent project and is not affiliated with or endorsed by Seeed Studio; it carries no reBot trademark claim.

Open-source licensing does not establish machinery safety certification, CE marking, or suitability for operation with a person in reach.