Robotics requirements allocation gives hardware, control and AI teams explicit contributions to a system obligation while keeping the system acceptance decision with a named owner. Before subsystem handoff, agree the parent requirement, child criteria, shared interfaces, performance budgets and assumptions, then identify how their combined evidence will close the parent. A complete allocation matrix should expose any part of the system claim that no team has accepted.
For a systems architect or engineering manager, the review question is practical: can the requirements workflow preserve that agreement as each team develops and verifies its part? Use the prospective allocation record below to review the work before a collection of local pass flags becomes the delivery argument.
Start with the obligation the robot must meet
A hardware team can meet a stiffness target, a controller can track a commanded pose and a perception model can estimate a feature accurately. Their results may still describe different frames, operating conditions or points on the robot. Allocation establishes how those contributions fit together. The parent owner must be able to explain why meeting the children is expected to satisfy the parent and what evidence will test that expectation.
NASA’s requirements-management guidance describes decomposition and allocation across levels, bidirectional traceability and checking whether lower-level requirements fully address their parent. It also recognises justified self-derived requirements. These are useful process principles for robotics. NASA’s programme phases and approval roles do not automatically govern a commercial robot project.
Keep relationship meanings clear. A requirement can derive from a parent, allocate to a system element, constrain an interface and be assessed by a verification activity. Those links answer different questions. The requirements traceability matrix guide explains the shared definitions. This worksheet concentrates on choosing contributions and retaining the integration responsibility.
A fictional tile-inspection robot before subsystem handoff
TILE-21 is an invented stationary inspection robot that positions a probe above marked tiles in a fixture. The example is prospective and unexecuted. Its values, configuration labels and proposed review decisions are teaching material, with no customer result or operational safety approval.
The declared planning configuration is TILE-C1: camera CAM-210, mechanics MECH-210 v1, controller CTRL-210 v1, estimator EST-210 v1 and transform set TF-TILE-21 v1. TILE-MODE-01 v1 describes slow nominal positioning with the fixture and selected poses defined in SETUP-21 v1. The example proposes 18–26 °C and a specified probe load. A real team must establish the fixture geometry, load, speed, image conditions and selected pose range before these labels support an evidence claim.
SYS-POS-210 v1: In TILE-MODE-01 under SETUP-21 v1, the norm of the translational difference between the settled probe centre and the commanded tile target, expressed in fixture_frame, shall not exceed 4.0 mm at each specified assessment pose.
The target is a nominal positioning obligation. It does not set an allowable contact force, protect people or define full motion-path accuracy. Those jobs need their own requirements and authority. A second parent, SYS-VAL-211 v1, requires that the controller issue no new pose command derived from an observation marked invalid under VALID-21 v1. This concerns information use in the exercise, with no claimed safety function.
The systems owner is accountable for both parent claims. Hardware, perception, controller and interface owners contribute defined obligations. A verification lead owns the combined assessment plan. These are roles to assign to real people. No appointment or approval has occurred.
Use a parent and child allocation matrix
For each row, state what contribution the child makes, who controls it and what it assumes from adjacent elements. A local verification reference is a planned activity, not evidence that the requirement has passed.
| Parent and child | Allocated contribution | Accountable contributor | Local verification and integration condition |
|---|---|---|---|
| SYS-POS-210 → EST-POS-210 | Estimated tile-target translation error ≤1.2 mm for the agreed valid image conditions. | Perception owner | PLAN-EST-21 compares against an independently characterised target reference. Contribution must be expressed in the agreed frame at the same observation state. |
| SYS-POS-210 → CAL-POS-210 | Residual translation contribution from camera-to-fixture mapping ≤0.8 mm over SETUP-21. | Calibration and frame owner | PLAN-CAL-21 assesses TF-TILE-21 applicability. Define which errors are included so estimator evidence does not count them twice. |
| SYS-POS-210 → CTRL-POS-210 | Settled tracking-error contribution ≤1.0 mm at the defined probe reference. | Control owner | PLAN-CTRL-21 uses the agreed command and independent position observation. Include settling definition, payload and selected poses. |
| SYS-POS-210 → MECH-POS-210 | Mechanical deflection contribution ≤0.5 mm under the specified probe load. | Mechanical owner | PLAN-MECH-21 checks the load and geometry represented. The contribution excludes deflection already included in the controller’s measurement. |
| SYS-VAL-211 → EST-VAL-211 | Publish the VALID-21 status and observation identity for every proposed target. | Perception owner | PLAN-VAL-21 challenges the defined validity cases. IF-POSE-21 v1 must explain status meaning, identity and absent observations. |
| SYS-VAL-211 → CTRL-VAL-211 | Issue no new pose command derived from an observation whose VALID-21 status is invalid. | Control owner | PLAN-INH-21 checks invalid inputs. The integrated case must associate observations with actual command decisions. |
| Parent closure retained | SYS-POS-210 combined error and SYS-VAL-211 producer-to-consumer behaviour. | Systems owner, with verification lead | PLAN-SYS-21 measures probe-to-target error and challenges agreed validity cases in TILE-C1. No system result is supplied. |
The last row is deliberate. Allocation does not remove the need to judge the complete system. An estimator test in camera coordinates and a controller test at the flange cannot simply be placed in neighbouring cells and called coverage of the probe centre in fixture_frame.
Check the budget and expose its assumptions
The proposed position budget uses a conservative sum of bounded contributions: 1.2 + 0.8 + 1.0 + 0.5 = 3.5 mm. Against the 4.0 mm parent limit, that leaves 0.5 mm of unallocated reserve. This is budget arithmetic, not an observed result. The reserve is not permission for measurement uncertainty to be ignored.
The sum is meaningful only if the contributors describe compatible errors under the same conditions and their definitions avoid double counting. For additive vector error contributions expressed in one frame, the triangle inequality provides a bound on the norm of their sum. The team must justify whether that model represents this robot. It cannot replace a measurement model with a convenient list of tolerances.
Do not combine worst-case limits with standard deviations or root-sum-square estimates without a justified model. Correlation, geometry and reference-point changes may alter the argument. A control measurement that already includes mechanical deflection would require a revised partition. The verification lead also needs a decision rule for uncertainty in the eventual system measurement.
| Assumption | Why it matters | Owner and closure evidence |
|---|---|---|
| ASM-21: common pose and frame | Every contribution must refer to the same target, probe reference and assessment state. | Frame owner supplies the convention, transforms and pose mapping for SETUP-21. |
| ASM-22: error partition | Estimation, calibration, tracking and deflection must form a defensible contribution model. | Systems and verification owners review included terms, exclusions and possible double counting. |
| ASM-23: agreed conditions | A local result at another load, temperature or image condition may not support the allocated bound. | Each contributor identifies its planned coverage and gaps against SETUP-21. |
| ASM-24: invalid-data contract | A producer’s invalid status must have the same meaning at the controller. | Both IF-POSE-21 endpoint owners agree validity, association, expiry and recovery behaviour. |
NASA’s technical-planning guidance calls for interface authorities and responsibilities, attention to assumptions and constraints, and configuration control of analysis. Applied here, each assumption needs a reference, a responsible owner and a decision about what remains provisional.
Review coverage before accepting the allocation baseline
Read each parent across its children. Ask whether the combination covers its conditions and criterion, whether an obligation sits between teams and whether the proposed integrated verification can observe the complete claim. For SYS-VAL-211, checking that the estimator emits an invalid flag is only one contribution. The receiver’s association and command decision are part of closure.
NASA’s product-verification guidance connects verification to the product, requirements baseline, plan and enabling products, and explains the value of end-to-end compatibility assessment. In TILE-21, that informs the planned integrated activity. It does not mandate a particular robot test rig.
A proposed review entry for ALLOC-REV-21 would state: child limits drafted, 0.5 mm reserve retained, ASM-21 through ASM-24 unresolved, local and integrated plans pending. The proposed disposition is hold allocation-baseline approval until those assumptions have a defensible resolution or an explicitly bounded authorised treatment. There is no completed review or executed evidence.
After allocation approval, a request to increase EST-POS-210 to 1.8 mm would raise the sum to 4.1 mm. That exceeds SYS-POS-210 before reserve. The allocation authority must choose a revised contribution model, reductions elsewhere or a separately justified parent revision. Use the existing robotics change-impact review for the later dependency sweep. This page owns the agreement before handoff.
Evaluate Arc with one parent and an incomplete contribution
Arc’s connected programme model supports requirements, systems, interfaces and verification records with configured ownership and relationships. Its traceability capability makes linked context available for review, while controlled change preserves proposed differences before baseline merge.
In a demo, create SYS-POS-210 and its four proposed children, assign contributor roles, link the assumption record and PLAN-SYS-21, then deliberately leave one child’s frame agreement incomplete. Ask whether the reviewer can find the gap, preserve the parent owner and record the held allocation decision. Show a proposed 1.8 mm estimator allocation and inspect the revised budget and affected evidence plan.
The worksheet fields and budget calculations need an agreed customer representation. Arc’s published capabilities support the connected records and review history. They do not establish an automatic budget solver, robot controller or autonomous engineering approval. Engineers judge the allocation model and evidence sufficiency.
Questions to settle before allocation approval
Can one robot requirement be allocated to several teams?
Yes. Give each team a defined contribution, its own acceptance condition and the assumptions it depends on. Keep one accountable owner for the parent requirement and its integration closure. Shared contribution should not leave the system decision with several unnamed owners.
Do passing subsystem tests close the system requirement?
Only when the approved verification approach demonstrates that the combined evidence covers the parent claim. Check common conditions, interfaces, interactions and the allocation model. An integrated activity may still be needed even when every local result meets its criterion.
Should an AI confidence score become a hardware requirement?
Allocate the required behaviour to the element that can realise and verify it. A confidence score can inform an agreed validity rule, but the consumer still needs a defined action for invalid or absent observations. The score alone does not establish physical positioning accuracy or safe operation.
Who may spend the unallocated performance reserve?
Use the programme’s named allocation authority. Record the proposed transfer, revised child limits, affected assumptions and verification actions before approval. Reserve is part of the parent budget, so a subsystem owner should not silently absorb it.
Can allocation review start before all assumptions are resolved?
Yes, as a draft review with owned actions and explicit limits. A baseline decision must state which assumptions are established and which remain open. Keep evidence closure pending where an unresolved assumption affects the claim.