Robot safety requirements traceability should preserve the path from an established safety function and authorised integrity target to allocated requirements, architecture, configuration and evidence. Keep the target decision, design verification and application validation distinguishable. A target label or component certificate alone cannot show that the complete function has been specified, integrated and reviewed for its intended use.
This guide is for robotics safety leads, control-system engineers and verification managers who already have identified risk controls and now need to manage their downstream engineering work. Its deliverable is a safety-function evidence thread with separate verification and validation dispositions. It does not select a safety function, calculate PLr or SIL or establish that a design is adequate.
Start with an established safety-function decision
Begin with the approved risk-control decision and the resulting function to be implemented. Identify the scope, intended operating modes and source authority. If the function or its purpose remains disputed, carry that as an open decision. A traceability tool cannot resolve an incomplete safety assessment by assigning a status.
The robotics hazard-to-requirement guide addresses the upstream hazard, control and residual-risk chain. This guide begins downstream of that chain. It helps the team preserve what the established function means as the work moves through requirements, allocation, implementation and evidence.
Separate the decision to require a function from the decision about its integrity target. They may involve different sources and reviewers. Record the determination method, assumptions, target and authority. If a target has not been approved, make it an explicit gap rather than copying a value from a similar machine.
Confirm the method and edition
The public ISO 13849-1:2023 scope concerns design and integration of safety-related parts of control systems, including software. It explicitly states that the document does not specify the safety functions or required performance levels to be used in particular applications. That limit is central to this workflow: the catalogue cannot choose your function or PLr.
The public IEC 62061 catalogue names design, integration and validation of machinery safety-related control systems, and design and verification for its stated demand-mode scope. The current product title identifies IEC 62061:2021+AMD1:2024+AMD2:2026 CSV, edition 2.2, published on 20 March 2026. The paid text and amendments were not reviewed for this guide.
Record which method and edition the programme has adopted and why. Keep any regional adoption, contractual reference or legal presumption separate from the international publication record. A recent catalogue edition does not automatically become the project’s governing text. Conversely, an older project reference needs a deliberate review when a changed design or contract raises an edition question.
Do not treat PLr and SIL as interchangeable record labels. Any decision about method, target or evidence relationships requires competent assessment against the full applicable documents. This guide supplies a way to retain those decisions and their evidence, rather than a shortcut for making them.
Specify the complete function boundary
Describe the initiating condition, required response, affected equipment, modes and interfaces. Identify where the function begins and ends. A record limited to a sensor output can miss the downstream logic and actuated behaviour on which the intended control depends. A record limited to a controller can miss input assumptions or application conditions.
Allocate requirements to the elements responsible for sensing, processing, communication, actuation and other consequential behaviour. Use allocations that match the architecture, while retaining a system-level requirement for the complete function. Record assumptions about external equipment and operational conditions so their owners can confirm them.
Give response constraints an explicit source and measurement boundary. If timing matters, define the event from which it is measured, the state that ends the measurement and the conditions under which the requirement applies. This article does not provide a universal response time or protective distance. Such values need application-specific sources and engineering analysis.
Include required behaviour for relevant faults, invalid information and recovery conditions as determined by the applicable design process. Keep operator procedures and maintenance commitments distinguishable from product behaviour. Each can matter to the safety argument, but each needs the correct owner and evidence role.
Build a safety-function evidence thread
The worksheet below is a proposed traceability method, not a clause-by-clause standard specification. Use it to make the function’s decisions and gaps reviewable across disciplines.
| Thread element | Record | Required review question |
|---|---|---|
| Function authority | Established risk-control reference, function ID, operating scope and responsible decision | What need does the complete function address? |
| Target authority | Selected method, applicable edition, approved PLr or SIL determination, assumptions and reviewer | Who authorised this target on what basis? |
| Boundary and allocation | System requirement, trigger and response endpoints, allocated requirements and interfaces | Do the allocations cover the complete required behaviour? |
| Architecture evidence | Design description, relevant analyses, component claims, configuration and limitations | Which design claim does each artifact support? |
| Verification disposition | Method, procedure or analysis, criterion, actual result, deviation and acceptance owner | Has the defined requirement been demonstrated for this configuration? |
| Validation disposition | Intended application, validation question, relevant evidence, remaining assumptions and authority | Does the reviewed function address the intended use and conditions? |
| Change and effectivity | Applicable baseline, affected equipment and changes that reopen the thread | Which decisions and evidence need reassessment after this change? |
Use distinct states for target approval, design evidence review, requirement verification and application validation. Their terminology can follow the programme’s approved process. The point is to avoid a single “safety complete” checkbox that obscures which question has actually been answered.
Maintain the relationship between evidence and claim. A component report may support a parameter or component behaviour under specified conditions. A system analysis may depend on that report, architecture assumptions and other inputs. Preserve those dependencies so an outdated component record can be assessed against the actual system claims it affects.
Review design evidence and test evidence together
Test results are one part of the thread. Depending on the adopted process and function, design review, analyses, software evidence, component information and integration results may support different claims. Do not infer complete adequacy from the presence of one artifact category. Determine required evidence from the full applicable sources and the application assessment.
For each artifact, retain the version, configuration, supported claim, assumptions and known limitations. If a report refers to an approved parameter set, connect that set to the reviewed build. If an analysis relies on architecture details, connect it to the controlled architecture revision. A correct calculation for the wrong design is not evidence for the proposed release.
Give deviations a disposition against the affected requirement and decision. A rerun can add evidence without resolving a design assumption. A revised analysis can address a model input without demonstrating the installed interface. Select closure work according to the gap, and retain the authority that accepts the closure.
The robotics configuration-evidence guide provides the underlying result record. This thread adds the function and target authority, architecture dependencies and the separate validation question.
Keep verification and validation dispositions visible
Verification asks whether the specified requirements have been met by the identified design and configuration. Validation addresses the intended application and conditions, using the programme’s applicable definitions and process. The work can share evidence, but its review questions should not collapse into a single result label.
An interface test could verify a specified signal response while leaving an application assumption unresolved. Equally, an application review could reveal that the specified response needs revision even though a test demonstrated the old requirement. Retaining both dispositions lets the team see why further work is needed.
Record review scope and authority. If the governing process requires particular competence or independence, establish that from the applicable source and retain the arrangement. The public catalogues do not provide enough detail for this article to prescribe a complete validation organisation or claim that its worksheet satisfies one.
Worked example: an unexecuted access-function review
The following example is entirely fictional and unexecuted. Project LANTERN-3 proposes function SF-63 for an access request at a pallet-transfer station. Its risk-control decision would already need approval outside this example. Proposed baseline LN-B6 comprises input arrangement IN-4, logic revision LG-9 and output interface OUT-2. No PLr or SIL is selected, no calculation is performed and no test result is claimed.
| Thread record | Proposed content | Disposition |
|---|---|---|
| SF-63 / TA-63 | Function scope links to the established control decision. Target determination and method authority are required. | Target approval remains open. A similar station’s target cannot be copied without assessment. |
| SFR-63A / SFR-63B | Allocated input and output requirements would define trigger, required state and interface conditions. | Boundary review must confirm the complete path, including OUT-2’s receiving equipment. |
| AE-63 | Architecture evidence would connect IN-4, LG-9, OUT-2 and reviewed supporting component information. | Evidence is planned. Component documents alone cannot close the integrated design claim. |
| VE-63 | Planned verification work would evaluate defined requirement criteria against LN-B6. | No execution exists. Procedure approval and applicable criteria are needed before result review. |
| VA-63 | Separate validation work would assess the function against the intended station use and assumptions. | Application disposition remains open even if future requirement tests pass. |
| CH-63 | A proposed LG-10 revision would change the logic path. | Impact review must identify affected architecture, verification and validation claims before any baseline decision. |
The useful result is a clear recovery path: approve the target basis, complete the boundary allocations, define and assess the evidence, then retain the authorised verification and validation dispositions. These are distinct work items. The example does not establish an acceptable design or operation.
Reassess the thread after change
A change to an input, logic, output, parameter, interface or intended condition can affect the function. Trace the proposal to the target assumptions, architecture and evidence it touches. Decide which records remain applicable and which need revised work. Keep the historical configuration and its decisions intact.
Use the robotics change-impact review for the broader review and affected owners. Within that review, the safety-function thread makes the function-specific authority, design claims and validation questions available to the people deciding the change.
Manage the evidence thread in Arc
Arc’s public traceability capability connects requirements, architecture, interfaces and evidence with coverage and impact paths. Its verification records connect methods, procedures, configurations, executions and results. A team can configure the function and disposition records and maintain their relationships.
Review records preserve attributable decisions and reviewed context, while controlled changes preserve proposals and baseline history. These mechanisms help organise the evidence thread. Arc does not select the safety target or determine that the design and validation evidence are sufficient.
Evaluate one function thread
Bring one established safety function, its authorised target record, one architecture artifact and representative evidence to an Arc demo. Connect the records, identify an open assumption and propose one interface change. Ask the reviewer to reconstruct the target authority and explain which verification and validation questions reopen.
Use synthetic or agreed evaluation material and confirm data handling before adding programme information. The useful result is a traceable decision and an explicit gap, with evidence scope that another engineer can inspect.
Sources and method
Arc prepared this educational guide and sells requirements management and systems engineering software.
Prepared on 26 October 2026 from the EVS public ISO 13849-1:2023 scope, the IEC public consolidated-edition catalogue and Arc’s canonical capability-page source. Full paid standards and amendments were not reviewed. The worksheet is an editorial method. No target, calculation, normative clause obligation, architecture adequacy or validation sufficiency is asserted. Arc capability records retain their 4 September 2026 public review date.
Frequently asked questions
Does ISO 13849-1 specify the PLr for my robot?
The public ISO 13849-1:2023 scope explicitly says it does not specify the safety functions or required performance levels for particular applications. The programme needs an authorised target determination using the applicable sources and risk-assessment process. This guide does not choose or calculate a PLr.
Can a SIL value be treated as the same requirement as a PLr?
Do not substitute the labels or values without an assessed basis. Record the selected method, applicable source, target, rationale and decision authority for each function. Any relationship between methods or evidence needs competent review using the full relevant standards.
What should a safety-function evidence record trace?
Trace the established safety function and target authority to its system boundary, allocated requirements, interfaces, architecture evidence, configuration and verification work. Retain a separate validation question and disposition for the intended application, with open assumptions and deviations visible.
Does a component certificate validate the complete robot function?
A component certificate may support a defined component claim under stated conditions. Review its scope, configuration and limits, then identify the system evidence still needed. It does not by itself establish the complete function’s design, integration or application validation.
Which IEC 62061 edition was checked for this guide?
The IEC public catalogue reviewed on 26 October 2026 identifies IEC 62061:2021+AMD1:2024+AMD2:2026 CSV, edition 2.2. The paid text and amendments were not reviewed. The project must separately record its applicable edition and any regional adoption or legal reference.