Defining the operational design domain

1. Engineering problem

Every robot is designed and tested for some conditions. If they are not written down, the robot is silently expected to work in all of them: in rain, on ramps, at night, in crowds. The ODD is the written boundary: conditions inside it are the design’s responsibility; conditions outside it need a defined response (slow down, stop, ask for help).

2. When is this needed?

• Right after the concept of operations, before sensor and drive selection.
• When extending a robot to a new site or season.
• When a field failure happens: was the robot inside or outside its ODD?

3. Selection and design decisions

The term operational design domain is defined in the automated-driving standard SAE J3016 as the conditions under which a driving automation system is designed to function. The same idea applies to robots.

4. Advantages and disadvantages

• A wide ODD serves more customers and multiplies design cost, test effort and the number of failure modes.
• A narrow ODD is cheaper and safer to validate, and the robot is less useful the moment conditions drift.
• Hard edges vs graceful degradation: a robot can slow down as lighting fades instead of stopping at a sharp threshold: define both the edge and the behaviour near it.

5. Requirements and constraints

• Each ODD limit must be measurable by the robot or by the operator (the robot cannot respect a limit it cannot detect).
• The ODD must be consistent with the requirements (a 1.0 m/s speed requirement and a 5° slope limit fix the drive torque).
• Limits should be justified by data from the site: measure slopes, light levels and traffic.

6. Architecture

conditions (sensed or declared) ─▶ ODD monitor ─▶ inside: normal operation
                                              └▶ near the edge: reduced speed, extra caution
                                              └▶ outside: stop / hand over / request help (defined behaviour)

7. Implementation

1. List the dimensions above and fill each with a range or a set of allowed values, from the site survey and the concept of operations.
2. For each limit, write how the robot knows (a sensor reading, a map layer, an operator setting, a schedule).
3. Write the response for “near the edge” and “outside”: speed reduction, stop, notify, return to base.
4. Derive requirements from the ODD (for example drive torque from the maximum slope).
5. Design tests at the boundaries and just outside them.

ODD = {"surface": {"indoor flat floor", "ramp"}, "slope_deg": (0, 5), "temperature_c": (5, 35),
       "illuminance_lux": (50, None), "people_density": {"sparse", "moderate"}, "speed_limit_mps": (0, 1.0)}
def check(c):
    out = []
    for k, rule in ODD.items():
        v = c[k]
        if isinstance(rule, set):
            if v not in rule:
                out.append(f"{k}={v!r} is outside the ODD")
        else:
            lo, hi = rule
            if (lo is not None and v < lo) or (hi is not None and v > hi):
                out.append(f"{k}={v} is outside the ODD {rule}")
    return out or ["inside the ODD"]
print(check({"surface": "ramp", "slope_deg": 4, "temperature_c": 22, "illuminance_lux": 300, "people_density": "sparse", "speed_limit_mps": 1.0}))
print(check({"surface": "outdoor grass", "slope_deg": 8, "temperature_c": 22, "illuminance_lux": 20, "people_density": "dense", "speed_limit_mps": 1.0}))

Printed (checked by the site’s tests):

['inside the ODD']
["surface='outdoor grass' is outside the ODD", 'slope_deg=8 is outside the ODD (0, 5)', 'illuminance_lux=20 is outside the ODD (50, None)', "people_density='dense' is outside the ODD"]

Reading it: the first set of conditions is inside the ODD; the second is outside on four dimensions (surface, slope, light and crowd density) and the checker names each one, which is what an ODD monitor logs and what an operator needs to see.

8. Real examples

• Indoor delivery robot: flat floors and ramps up to 5°, 5–35 °C, at least 50 lux, sparse to moderate foot traffic, 1.0 m/s maximum; outside: stairs, outdoors, dense crowds.
• Agricultural rover: row crops, defined slope and wetness limits, GNSS with an RTK correction link; outside: heavy rain, standing water.
• Warehouse AMR: mapped aisles, marked pedestrian zones, floor flatness within a tolerance, Wi-Fi coverage map.

9. Failure scenarios

• A robot tested only in one building and sold for “indoor use”.
• An ODD that lists conditions the robot cannot detect, so it cannot know when it has left it.
• No behaviour defined outside the ODD: the robot continues at full speed.
• ODD limits copied from a competitor rather than measured.

10. Troubleshooting

1. After a field failure, list the conditions at the time and check each against the ODD.
2. If the conditions were inside the ODD, the design or the test coverage failed: add tests.
3. If they were outside, check why the robot did not detect or respond: add a monitor or widen the design.
4. Update the ODD and the requirements, then re-run the affected tests.

11. Validation

• Every ODD dimension has a range or a set of allowed values and a source for the number.
• Each limit has a detection method and a defined response near and beyond the edge.
• Tests exist at and just beyond each boundary.
• The checker example prints the values above (executed by the site tests).

12. Engineering checklist

• All dimensions covered (environment, surface, weather, light, agents, speed, infrastructure, duty, exclusions)
• Values from site measurements
• Each limit detectable
• Near-edge and outside behaviour defined
• Requirements derived from the ODD
• Boundary tests planned
• ODD reviewed after each field failure

13. Further references

• SAE J3016, “Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles”: sae.org (the operational design domain concept originates in this document; its text is behind SAE’s publication model and was not read here, so the definition above is paraphrased).
• NASA Systems Engineering Handbook, Rev 2 (2017): ntrs.nasa.gov/citations/20170001761, concept of operations and operations concept (read 2026-11-05).

Related on FixTheRobot

• Engineering Trade-offs and Safety Cases Navigation · Lesson