Skip to content
Arc
Menu

Robotics

Requirements management for robotics teams.

Connect robot requirements, sensors, control software and test evidence. Review changes against the configuration and operating conditions they affect.

Book a demo

02Engineering challenges

Review the whole robot behind each update.

Hardware, models, calibration and operating conditions all shape the behaviour under review.

  1. The configuration keeps changing

    Model and firmware releases can reach several sensor and hardware variants. A version label alone does not describe the robot.

  2. Interfaces shape system behaviour

    Sensor and controller changes can affect timing, reference frames and invalid-data handling beyond the model benchmark.

  3. Earlier results need another look

    A passing test belongs to the configuration and conditions tested. Its applicability to an update needs review.

03How Arc helps

Connect robot behaviour to the configuration behind it.

Keep intended behaviour, interface assumptions and test evidence connected as hardware and software evolve.

Robot and operating context

Define the behaviour in context.

Connect requirements to sensors, control software and interfaces. Retain timing definitions, operating conditions and the owner responsible for each behaviour.

Inspect the fictional robot requirement

Illustrative engineering example: WR-01 is a fictional supervised indoor warehouse replay bench. Historical CFG-A and candidate CFG-B differ only in the perception-model reference.

The 80 ms target is fictional bench timing, not operational safety proof or a customer result. Arc manages engineering records and review. It does not train the model or control the robot.

Illustrative engineering example · WR-01 model update

Requirement

SYS-PER-01 · v1

  • SYS-PER-01 · v1measured at

    Interface timing

    IF-DET-01 · v1

    Measurement delivery event

  • SYS-PER-01 · v1assessed within

    Replay dataset

    DSET-07 · v1

    LOAD-02 teaching load

  • SYS-PER-01 · v1reviewed for

    Candidate configuration

    CFG-B

    M2 · CAL-07 applicability open

    Pending

Awaiting engineer review

Requirement record
RequirementSYS-PER-01v1
Programme
WR-01 supervised indoor warehouse replay bench
Interface
IF-DET-01 v1
Dataset
DSET-07 v1
Load condition
LOAD-02
Target
80 ms fictional bench timing
Candidate evidence
EVID-LAT-B Pending
Owner
Perception, interface and test owners

Awaiting engineer review

Illustrative engineering example. WR-01 is a supervised replay bench, not a deployed robot or a safety demonstration.
Arc FOREST-3 demo requirements table with REQ-013 marked Needs re-verification
Arc FOREST-3 demo. REQ-013 has a candidate change from 150 to 200 W and is marked Needs re-verification.

Configuration changes and agents

Review the complete robot configuration.

Follow a model or sensor update into the affected requirements and tests. Distinguish the changed element from shared hardware, firmware, calibration and map references.

Inspect the fictional model comparison
Illustrative engineering example · WR-01 model update

WR-01 configuration manifest · CFG-A → candidate CFG-B

Perception model

Current

M1

Proposed

M2

Hardware
H1Unchanged
Sensor
L1Unchanged
Firmware
F1.4Unchanged
Calibration
CAL-07Unchanged
Map
MAP-03Unchanged
Requirement
SYS-PER-01 v1Unchanged
Dataset
DSET-07 v1Unchanged
Load condition
LOAD-02Unchanged
Interface
IF-DET-01 v1Unchanged
Bench timing target
80 msUnchanged

PendingCAL-07 applicability to M2 remains open

Affected records

  • WR-01 configuration manifest · CFG-A → candidate CFG-B

    IF-DET-01 v1

    Timing measurement and delivery event

  • WR-01 configuration manifest · CFG-A → candidate CFG-B

    EVID-LAT-B

    Pending candidate timing evidence

  • WR-01 configuration manifest · CFG-A → candidate CFG-B

    CAL-07

    Calibration applicability review remains open

  • Only the perception-model reference changes, M1 → M2.
  • CAL-07 retains its manifest label. Applicability to M2 remains open.
  • 80 ms is fictional bench timing, not an operational safety limit.

Awaiting engineer review

Full change comparison
WR-01 configuration manifest · CFG-A → candidate CFG-B
Record / valueCurrentProposed
HardwareUnchangedH1H1
SensorUnchangedL1L1
FirmwareUnchangedF1.4F1.4
Perception modelM1M2
CalibrationUnchangedCAL-07CAL-07
MapUnchangedMAP-03MAP-03
RequirementUnchangedSYS-PER-01 v1SYS-PER-01 v1
DatasetUnchangedDSET-07 v1DSET-07 v1
Load conditionUnchangedLOAD-02LOAD-02
InterfaceUnchangedIF-DET-01 v1IF-DET-01 v1
Bench timing targetUnchanged80 ms80 ms

Unchanged constraints

  • Only the perception-model reference changes, M1 → M2.
  • CAL-07 retains its manifest label. Applicability to M2 remains open.
  • 80 ms is fictional bench timing, not an operational safety limit.

Affected records

IF-DET-01 v1
Timing measurement and delivery event
EVID-LAT-B
Pending candidate timing evidence
CAL-07
Calibration applicability review remains open

Awaiting engineer review

Illustrative configuration comparison. Only the perception-model reference changes. Calibration applicability remains open.

Make agent findings reviewable.

Agents help trace configuration dependencies and flag requirement or evidence gaps. Engineers inspect the sources and decide which proposed actions to accept.

Inspect the fictional agent proposal
Illustrative engineering example · WR-01 model update

Sources

  • SYS-PER-01 · v1
  • CFG-A → CFG-B
  • IF-DET-01 · v1
  • EVID-LAT-B

Finding

Candidate CFG-B has no supplied timing evidence, and retaining the CAL-07 label does not resolve calibration applicability to M2.

Proposed action

Review calibration applicability and prepare the scoped timing check for CFG-B. Record the result and its assessed configuration before requesting acceptance.

Engineer review

Awaiting engineer review

Historical CFG-A evidence establishes neither a pass nor a failure for CFG-B. This authored proposal is not an executed model or robot test.

Source and proposal detail

Sources

  • SYS-PER-01 · v1

    80 ms fictional bench target within the defined replay scope.

  • CFG-A → CFG-B

    Only M1 → M2 changes. H1, L1, F1.4, CAL-07 and MAP-03 labels remain.

  • IF-DET-01 · v1

    Timing delivery event with DSET-07 v1 and LOAD-02.

  • EVID-LAT-B

    Pending. CAL-07 applicability to M2 remains open.

Finding

Candidate CFG-B has no supplied timing evidence, and retaining the CAL-07 label does not resolve calibration applicability to M2.

Proposed action

Review calibration applicability and prepare the scoped timing check for CFG-B. Record the result and its assessed configuration before requesting acceptance.

Awaiting engineer review

Historical CFG-A evidence establishes neither a pass nor a failure for CFG-B. This authored proposal is not an executed model or robot test.

Illustrative sourced proposal. It supplies no executed model benchmark or candidate timing result.
Arc FOREST-3 demo impact analysis showing a proposed branch and conflict notice
Arc FOREST-3 demo. The impact view shows an unapproved branch and a conflict notice for review.

Evidence and release review

Identify what each test supports.

Keep the model, firmware, calibration, dataset and operating conditions with each evidence reference. Review applicability before carrying a result into a candidate configuration.

Inspect the fictional evidence trail
Illustrative engineering example · WR-01 model update
  1. 01

    Requirement and event

    SYS-PER-01 · v1

    IF-DET-01 v1 · 80 ms bench target

    assessed within
  2. 02

    Replay scope

    DSET-07 · v1

    LOAD-02

    represents
  3. 03

    Assessed candidate

    CFG-B

    Hardware / sensor
    H1 / L1
    Firmware / model
    F1.4 / M2
    Calibration / map
    CAL-07 / MAP-03

    Pending

    documented in
  4. 04

    Candidate timing evidence

    EVID-LAT-B

    Pending

    reviewed for
  5. 05

    Applicability decision

    CAL-07 applicability to M2 remains open

    Pending

No CFG-B pass or failure is inferred. The bench target and replay scope do not demonstrate operational safety.

Illustrative evidence sequence. The 80 ms target does not prove operational performance or safety, and no CFG-B result is supplied.

Review the update across disciplines.

Bring hardware, perception, control and test owners into the same proposed branch. Keep the configuration decision and pending verification visible before acceptance.

Inspect the fictional configuration review
Illustrative engineering example · WR-01 model update
Main developmentProposed branch
  1. 01Historical configuration

    WR-01 / CFG-A

    Main development
  2. 02Candidate model change

    CFG-B: M1 → M2

    Proposed branch
  3. 03Interface timing review

    IF-DET-01 v1

    Proposed branch
  4. 04Open decision

    CAL-07 applicability

    Proposed branch
  5. 05Pending evidence

    EVID-LAT-B

    Proposed branch
  6. 06Awaiting engineer review

    Perception, interface and test owners

    Proposed branch
  7. 07Pending decision

    Merge only after approval

    Proposed branch

Responsible review

  • Perception, interface and test owners
Baseline and configuration detail
Main developmentProposed branch
  1. 01Historical configuration

    WR-01 / CFG-A

  2. 02Candidate model change

    CFG-B: M1 → M2

  3. 03Interface timing review

    IF-DET-01 v1

  4. 04Open decision

    CAL-07 applicability

  5. 05Pending evidence

    EVID-LAT-B

  6. 06Awaiting engineer review

    Perception, interface and test owners

  7. 07Pending decision

    Merge only after approval

Programme baseline
Meaning
A named robot-programme record of agreed requirement, interface and configuration revisions, including open decisions.
Assessed configuration
Meaning
For candidate CFG-B: H1, L1, F1.4, M2, CAL-07 and MAP-03, with DSET-07 v1 and LOAD-02. Candidate evidence and calibration applicability remain pending.
Illustrative review path. Candidate CFG-B and its verification decision remain pending. The example does not show an approved merge.
Arc FOREST-3 demo test record with a retained Pass marked Needs re-verification
Arc FOREST-3 demo. A retained Pass is marked Needs re-verification. The screenshot shows no rerun.

04Standards and assurance scope

Match the safety scope to the robot’s intended use.

Select the standards and editions that apply to the robot’s intended use. Industrial arms, driverless industrial trucks and personal care robots have different scopes.

Connect the applicable obligations to robot requirements, interfaces and verification. Record the intended-use boundary, agreed tailoring and accountable review owners.

Organising requirements and evidence supports safety review. It does not certify the robot, qualify a tool or prove that a model benchmark meets a system safety obligation.

ISO 10218
Industrial robots and industrial applications or cells.
ISO 3691-4
Applicable driverless industrial trucks and their systems.
ISO 13482
Personal care robots within its stated application scope.

Connect model and test references through API and MCP.

Retain model, firmware, simulation and bench references with their measurement definitions and operating conditions. Agree supported exchanges with your development tools.

APIMCPSecurity and deployment
API and MCP
Connect supported records through the API, or give a compatible agent permitted programme context and tools through MCP. Agree mappings, permissions and review for the workflow.
Deployment and AI keys
Discuss deployment in your own AWS or Azure infrastructure under an agreed setup. Bring your own key is available for supported AI providers. Agree access, processing locations and retention for the programme.

05FAQ

Frequently asked questions

What engineering records can Arc connect for robotics?

Arc connects robot requirements, sensors, models, control software, interfaces and test evidence. Configuration references and operating conditions help reviewers understand which robot behaviour a requirement or result addresses.

How does Arc support review of a perception-model update?

Trace the proposed model change through connected interfaces, requirements and verification records. Keep hardware, firmware, calibration and map references distinct. In the fictional WR-01 example, only M1 changes to M2 and candidate evidence remains pending.

Which robotics standards can Arc help organise?

The applicable scope depends on the robot’s intended use. ISO 10218 addresses industrial robots and applications or cells, ISO 3691-4 addresses applicable driverless industrial trucks and ISO 13482 addresses personal care robots within its scope. Arc connects the selected obligations to requirements and review evidence.

Does a passing model benchmark verify the robot system?

A benchmark supports the configuration, dataset and measurement conditions assessed. Review its relationship to the system requirement, interface timing and operating boundary before using it as robot evidence. The fictional 80 ms example is a supervised replay-bench target.

How can hardware, perception and control teams coordinate?

Connect each requirement and interface to its owner and source revision. Review a proposed branch with the affected disciplines, retain the current baseline and record which configuration and evidence are candidates.

Can Arc’s agents approve a robot configuration?

Engineers decide whether a configuration or proposed change is acceptable. Agents help inspect requirements, dependencies and evidence gaps, with their sources and findings available for review. Arc manages engineering records and review rather than training a model or controlling a robot.

Can robotics tools connect through API or MCP?

Use supported API operations or permitted MCP tools within an agreed workflow. Define model, sensor, configuration and evidence mappings with their permissions and review process. Customer-owned AWS or Azure deployment and supported AI-provider keys can be discussed for the setup.

What can a robotics team explore in an Arc demo?

A demo can follow intended robot behaviour through a model or interface change and the evidence needed for configuration review. Book a demo to discuss your hardware, software and verification workflow.

06Engineering resources

Engineering resources

Browse the blog
  1. Writing robotics requirementsDefine measurable behaviour, interfaces and verification responsibilities.Guide
  2. Reviewing robotics changesTrace a proposed model change through the records and evidence that need review.Guide
  3. Configuration-specific evidenceAssess which robot state a result supports.Guide

07Next step

Review your next robot update in Arc.

See how robot requirements, configuration changes and test evidence come together for review.

Book a demo