AgriRover: The Missing Timing Budget

This is not a vendor nonconformance; it is a requirements and interface decomposition failure. The stop-distance requirement is really a system timing budget: 0.4 m at 1.2 m/s allows 333 ms from obstacle presence to full stop. The allocation gave perception 150 ms and left actuation, transport, processing, and jitter unallocated, so the parts were never required to sum to the whole. The ICD controlled message syntax and nominal rate but not worst-case latency, jitter, or timestamp semantics, so neither party owned the emergent end-to-end property. Acceptance tests were scoped per subsystem, which is precisely where the property does not live.

Artifacts to change: (1) derive an explicit timing budget with margin, for example perception 150 ms, transport 20 ms, controller processing 30 ms, actuation 120 ms, reserve 13 ms; (2) replace '200 ms typical' with a statistical bound tied to defined operating conditions, for example 99.9th percentile no more than 150 ms under stated foliage and lighting, plus a hard maximum; (3) add latency, jitter, and timestamp requirements to the ICD; (4) add a system-level end-to-end timing verification requirement; (5) flow the same bound and evidence rights into the vendor contract.

Budget: 333 ms total from obstacle presence to full stop. Allocate perception 150 ms, transport 20 ms, controller processing 30 ms, actuation 120 ms, reserve 13 ms. The observed 380 ms perception spike alone consumes the budget before braking begins: 380 + 120 = 500 ms, which at 1.2 m/s means about 0.6 m of travel, exceeding the 0.4 m requirement with no margin.

Verification must be system-level and statistical because latency is stochastic. Use hardware-in-the-loop testing with injected latency distributions drawn from field data, including the 99.9th percentile and the canopy end-of-row case. Measure at the physical events, obstacle present to brake pressure applied, not at software timestamps. Since the property is a percentile, define a test plan with sample size and confidence, for example 3,000 trials to demonstrate the 99.9th percentile with 95% confidence plus a hard maximum. Include message loss, out-of-order timestamps, and degraded sensor modes. Field measurement is required because dense foliage is an operational condition, not a lab condition. Finally, add the timing test to the regression suite so later firmware or configuration changes cannot silently erode the margin.

The vendor is right on the contract and wrong on the system. 'Typical' is not a verifiable requirement; it cannot be tested, and it silently transfers the emergent risk to the integrator. Renegotiate around the system requirement: define the operating envelope, the percentile and hard maximum, the measurement method and instrumentation, and the evidence the vendor must supply. The commercial lever is that the vendor's obligation should be derived from the customer's stop-distance requirement, not negotiated in isolation.

If the vendor cannot meet 150 ms, treat it as a system trade rather than a perception fix. Options: reduce vehicle speed, since 0.6 m/s allows about 667 ms and would restore margin even with the observed 500 ms; add a close-range redundant sensor with a short, deterministic path into the brake controller; move emergency-stop logic into a dedicated low-latency channel; or change the operating envelope to exclude dense canopy at speed. Each option has different cost, certification, and operational impact, so evaluate them against the customer requirement. Until closed, record a deviation, restrict the demonstration to the verified envelope, and do not present the system as meeting the 0.4 m requirement.