FixTheRobot Explore Robotics / Systems Engineering / Design & Selection / Module 01

Design & Selection · Module 01

Selecting a robot architecture and allocating requirements

Splitting the robot into subsystems is a design decision. Allocating every requirement to a subsystem proves that the split covers the job.

  • Intermediate
  • Module 01: Robotics System Architecture & Requirements
  • Written for ROS 2 Jazzy where ROS 2 is used
  • Sources checked 2026-11-05

Assumptions: A practical template based on the NASA Systems Engineering Handbook; not a standard. All numbers in the example are illustrative and the code is executed by the site’s tests.

1. Engineering problem

A robot architecture divides the system into subsystems and decides where each function lives. A requirement that no subsystem owns will not be met; a subsystem that owns no requirement may not be needed. Allocation is the table that connects the two.

2. When is this needed?

  • After requirements and the ODD are written.
  • Before detailed design of any subsystem.
  • When a requirement changes and you need to know which subsystems it touches.

3. Selection and design decisions

ArchitectureIdeaStrengthWeakness
CentralisedOne computer runs perception, planning and controlSimple, easy to debugSingle point of failure; real-time control shares a CPU
DistributedSeveral computers or MCUs, each owning a functionIsolation, real-time control on an MCUMore interfaces, harder time sync
Layered (hierarchical)Reactive layer below, deliberative layer aboveSafety at the lowest layer, clear ratesLayer boundaries must be defined
Behaviour-basedParallel behaviours arbitratedRobust reactive responseHard to predict combined behaviour

4. Advantages and disadvantages

  • Fewer subsystems means fewer interfaces; more subsystems means better isolation and parallel work.
  • Real-time control on an MCU gives determinism; on the main computer saves hardware but needs a real-time-capable setup.
  • Put the safety function on the lowest, simplest layer so it does not depend on the complex software above it.

5. Requirements and constraints

  • Every requirement is allocated to at least one subsystem; shared allocations are explicit.
  • Every subsystem has at least one requirement.
  • Allocation names only subsystems that exist in the block diagram.

6. Architecture

requirements ──allocation table──▶ subsystems
   R1 ─▶ navigation
   R2 ─▶ drive, power
   R4 ─▶ perception
A gap on either side is a finding.

7. Implementation

  1. Start from the subsystem candidates in a reference architecture for your robot type.
  2. Write the allocation as a table or a small data file (requirement id to subsystem ids).
  3. Run the check below to find unallocated requirements, unused subsystems and typos.
  4. Resolve each finding: add a subsystem, add a requirement or reallocate.
  5. Re-run after every requirement change.
reqs = {"R1": ["navigation"], "R2": ["drive", "power"], "R3": [], "R4": ["perception", "sensing"]}
subsystems = ["navigation", "drive", "power", "perception", "safety"]
unallocated = [r for r, s in reqs.items() if not s]
unused = [s for s in subsystems if not any(s in v for v in reqs.values())]
unknown = sorted({s for v in reqs.values() for s in v} - set(subsystems))
print("unallocated requirements:", unallocated)
print("subsystems with no requirement:", unused)
print("allocated to unknown subsystems:", unknown)

Printed (checked by the site’s tests):

unallocated requirements: ['R3']
subsystems with no requirement: ['safety']
allocated to unknown subsystems: ['sensing']

Reading it: R3 is allocated to nobody; the safety subsystem owns no requirement (probably a missing safety requirement); and R4 refers to sensing, which is not a declared subsystem (a name mismatch with perception). The ids are illustrative.

8. Real examples

  • Example AMR: navigation computer (SLAM, planning), real-time MCU (velocity control, encoders, emergency stop path), motor drivers, battery and power distribution, sensor suite, fleet interface.

9. Failure scenarios

  • An important requirement (stopping distance) allocated to no subsystem and discovered in field testing.
  • Safety logic spread across layers, so no one owns it.
  • A subsystem added “because we always have one” with no requirement behind it.

10. Troubleshooting

  1. If a test fails, find the requirement and its allocation row; the owner subsystem is where to look first.
  2. If two subsystems both claim a requirement, split it into two measurable requirements.
  3. If a name does not match, fix the data, not the checker.

11. Validation

  • The allocation checker prints no findings.
  • Each requirement’s verification method (analysis, inspection, demonstration or test) is recorded in a verification matrix.
  • The architecture diagram and the allocation table agree.

12. Engineering checklist

13. Further references

  • NASA Systems Engineering Handbook, Rev 2 (2017): ntrs.nasa.gov/citations/20170001761, Appendix D (requirements verification matrix: analysis, inspection, demonstration, test), read 2026-11-05.

Related on FixTheRobot