ISO 34503: ISO 34503 – Tutorial (about 60 minutes)

ISO 34503 is the international standard that tells developers, operators and authorities how to describe the operational design domain (ODD) of an automated driving system: the set of road, weather, lighting, connectivity and traffic conditions in which the system has been designed to drive itself safely. It is used by automated-vehicle manufacturers, safety and validation engineers, mobility-service operators, city transport planners, regulators and insurers. After this tutorial you will be able to explain what an ODD is and why it matters, use the ISO 34503 taxonomy to list operating conditions, write simple ODD statements in its definition format, and connect an ODD to scenario-based testing and runtime monitoring.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current and only edition is ISO 34503:2023, Road Vehicles – Test scenarios for automated driving systems – Specification for operational design domain, first edition, published by ISO in August 2023. It was prepared by technical committee ISO/TC 22 (road vehicles), subcommittee SC 33 (vehicle dynamics, chassis components and driving automation systems testing), and belongs to the ISO 3450x family of test-scenario standards. It grew out of the UK specification BSI PAS 1883:2020. Its status is "published" (ISO stage 60.60) with no amendment, corrigendum or replacement; ISO reviews every standard at least every five years, so the first systematic review is due around 2028. In 2025 BSI published a new PAS 1883, titled Operational design domain (ODD) – Implementing BS ISO 34503, which adds practical examples and extra attributes (for example for motor-vehicle type and vulnerable road users) but does not replace the ISO standard. Verified 2026-10-29 against the ISO catalogue data mirrored by Genorma (published 2023-08-08, 29 pages, stage 60.60), the Swiss national body (SNV) catalogue entry (edition 1, current) and the BSI PAS 1883 page (the iso.org catalogue page blocks automated access).

Who it is for: engineers, product owners, safety and validation staff, quality and compliance people, and public-sector or fleet planners who are new to ODDs and need to write, read or review an ODD definition. It is also useful for people from functional safety (ISO 26262) or SOTIF (ISO 21448) who want to see where the ODD feeds their own work.

Prerequisites: none. A rough idea of how an automated vehicle works (sensors, software that interprets them, actuators such as brakes and steering) helps. Every technical term is explained the first time it appears.

By the end of this tutorial:

You will be able to explain why an automated driving system needs an operational design domain and what ISO 34503 standardises about it.
You will be able to distinguish the ODD from the operational domain, the target operational domain and the current operational domain.
You will be able to name the three top-level attribute groups of the taxonomy and place a real-world condition in the right branch.
You will be able to write ODD statements with definition modes and the include, exclude and conditional qualifiers, using objective, measurable values.
You will be able to describe how an ODD definition drives scenario-based testing, runtime monitoring and fallback behaviour.
You will be able to explain how ISO 34503 relates to SAE J3016, ISO 34502, ISO 34504, ISO 34505, BSI PAS 1883 and ASAM OpenODD.

Lesson 1 – Origins, purpose and scope

Why automated vehicles need a declared "comfort zone"

A human driver with a licence is allowed to drive almost anywhere: on motorways, in narrow city lanes, at night, in snow. We trust humans to adapt, slow down or stop when conditions exceed their ability. An automated driving system (ADS) does not adapt like this. Its cameras, radars, lidars, maps, software and actuators were designed, trained and tested for particular conditions. Outside those conditions it may still work, or it may fail in ways nobody has studied. So every ADS below full automation needs a clear, written statement of where and when it is designed to drive. That statement is the operational design domain, or ODD.

The idea of the ODD was already part of SAE J3016, the widely used classification of driving automation levels (published jointly with ISO as ISO/SAE PAS 22736). J3016 explains that a level 3 or level 4 feature works only within its ODD, while a level 5 system has no ODD limits at all. What J3016 did not provide was a common way to write an ODD down. Early ODD descriptions were free text in marketing brochures, safety reports and test permits. One company wrote "fair weather", another wrote "rain up to moderate intensity", a third listed postcodes. Comparing them, testing against them or checking them against a city's road network was hard.

From a UK specification to an International Standard

In the United Kingdom, a Publicly Available Specification (PAS) was developed with government support to fix this. The PAS, an ODD taxonomy for an ADS, was published in August 2020. In parallel, an international group of experts in ISO/TC 22/SC 33 worked on turning the same ideas into an International Standard. That work became ISO 34503, published in August 2023. Experts from WMG at the University of Warwick contributed to both documents.

ISO 34503 sits in a family of standards about test scenarios for automated driving systems: ISO 34501 gives the shared vocabulary, ISO 34502 the scenario-based safety evaluation framework, ISO 34504 the categorisation (tagging) of scenarios, and ISO 34505 the evaluation of scenarios and the generation of test cases. ISO 34503 supplies the piece that all of them depend on: a precise, shared description of the operating conditions the scenarios must cover.

What the standard sets out to do

The introduction of ISO 34503 frames the purpose around safety and trust. If users, operators and authorities clearly understand an automated vehicle's capabilities and limits, they can use it in a state of "informed safety". The first step towards that understanding is a well-written ODD. In its own scope statement the standard does two things:

It specifies requirements for a hierarchical taxonomy of operating conditions, a structured tree of attributes from which an ODD can be assembled.
It specifies requirements for a definition format, the way ODD statements built from that taxonomy are written.

The scope also makes three boundaries clear. First, the standard is mainly aimed at level 3 and level 4 systems; a level 5 system by definition can operate anywhere, so its ODD is unlimited. Second, it does not define the test procedures used to verify individual attributes; that belongs to other documents in the family and to each developer's own methods. Third, it does not set requirements for how the vehicle monitors its ODD attributes at runtime, although it explains why such monitoring is needed.

Who uses it

The standard names a wide audience. Manufacturers of level 3 and level 4 systems use it to state their system's operating capability and to build the safety case, the structured argument with evidence that the system is acceptably safe. Organisations running trials, test programmes and commercial deployments use it to agree where vehicles may operate. Insurers, regulators, service providers and national, regional and local governments use it to understand what a given system can do and to write their own requirements. A city council, for example, can describe the conditions of a planned shuttle route as part of a procurement, and bidders can answer with the ODD of their system in the same vocabulary.

Lesson 2 – Key concepts and vocabulary

ISO 34503 relies on terms from ISO/SAE PAS 22736 (the ISO edition of SAE J3016) and ISO 34501, and adds a few of its own. The definitions below are explained in plain words, not quoted.

Automated driving system (ADS) – the hardware and software that together perform the whole driving task on a sustained basis, whether or not it is limited to an ODD. In the J3016 scheme this means levels 3, 4 and 5.
Dynamic driving task (DDT) – the real-time work of driving: steering, accelerating and braking, plus sensing the environment, recognising objects and events and responding to them. It excludes trip planning such as choosing a destination.
Operational design domain (ODD) – the conditions under which a particular ADS is designed to perform the DDT safely. It is a property of the system, decided by its designers.
Operational domain (OD) – any set of operating conditions, described with the same kind of attributes, for whatever purpose: a real road network, a region's climate, or a set of synthetic conditions for a simulation. The ODD is a special case: the OD that a system is designed for.
Target operational domain (TOD) – the real-world conditions found where an ADS will be deployed and expected to operate, such as a city route or a motorway corridor. The TOD describes the place, not the system.
Current operational domain (COD) – the conditions that exist right now around the vehicle, as it perceives or is told them: the rain falling at this moment, the lane it is in, the traffic around it.
ODD attribute – one named characteristic in the taxonomy, such as rainfall, lane width or junction type. Attributes form a tree: a parent attribute (for example "junctions") has sub-attributes (for example "roundabout" and "intersection").
Scenery element – a non-movable part of the operating environment, such as a road, a junction, a tunnel or a traffic light. Non-movable does not mean unchanging: a traffic light changes colour and a lifting bridge opens, but both stay in the same place.
Environmental condition – weather and other atmospheric conditions, plus other environmental factors that are not scenery, including illumination and information-technology connectivity.
Dynamic element – anything in the ODD that moves during the driving task, such as other road users and the subject vehicle itself.
Traffic agent – any road user, including those on pavements and other spaces next to the road.
Vulnerable road user (VRU) – an unprotected road user such as a pedestrian, cyclist, motorcyclist, horse rider or a person with reduced mobility.
Subject vehicle – the vehicle equipped with the ADS whose ODD is being described, often called the ego vehicle. Its own speed is an ODD attribute.
Minimal risk manoeuvre (MRM) – a manoeuvre the ADS starts and carries out itself to reach a minimal risk condition, such as slowing down and stopping on the hard shoulder.
Minimal risk condition (MRC) – a stable, stopped or otherwise low-risk state the vehicle reaches when a trip cannot or should not continue.
Transition demand – a request from a level 3 system to the fallback-ready user, the human who must be ready to take over, to resume driving. SAE J3016 calls this a request to intervene; "transition demand" is the term used in UNECE and UK automated-driving rules.
ODD boundary and ODD exit – the edge where included conditions end, and the moment the vehicle crosses it or is about to cross it.
Qualifier – the keyword at the start of an ODD statement that says whether a value is inside the ODD (include), outside it (exclude) or inside only under a stated condition (conditional).
Definition mode – the rule for how attributes that a definition does not mention are treated: as inside the ODD (permissive), as outside (restrictive), or as not relevant (default).
Operational design conditions (ODC) – a wider idea, described in an informative annex, that adds the vehicle's own internal state (for example sensor health or occupant status) to the external ODD conditions.

ODD, OD, TOD and COD in one picture

The most important distinction in the standard is between the ODD, a specification of a system, and the TOD, a description of an environment. A manufacturer writes the ODD; a road authority, operator or city may describe the TOD. In practice the two never match perfectly. The real world of a TOD almost always contains rare conditions that no ODD lists, such as a flooded underpass once a decade. Where the TOD contains conditions outside the ODD, the system needs mechanisms to detect the ODD exit and fall back safely, and the deployment may need extra risk-reduction measures. The COD is the live snapshot the vehicle compares with its ODD, moment by moment.

Figure 1 – The ODD (a system specification) and the TOD (a deployment environment) are both operational domains; gaps between them call for mitigations, and the live COD is checked against the ODD to trigger fallback.

Notice the direction of each arrow. A TOD can be read as a requirement: any ADS that wants to serve that environment needs an ODD that covers it, or a convincing argument for the uncovered parts. An ODD can be read as a promise: inside these conditions the system has been designed and tested to behave safely.

Lesson 3 – Structure of the standard

ISO 34503 is a short document of around thirty pages. Its clauses build up from concepts to taxonomy to format. The descriptions below paraphrase the clause titles and purpose; they do not reproduce the text.

Clause	Title (short form)	What it does
1–4	Scope, normative references, terms, abbreviations	Sets the aim (taxonomy and definition format), draws shared terms from ISO/SAE PAS 22736 and ISO 34501, and defines ODD-specific terms such as scenery element, TOD and COD.
5	ODD and target operational domain	Explains the difference between a system's ODD and a deployment's TOD, and why the boundary between them must be objective.
6	ODD and scenario relationship	Shows that ODDs and scenarios are related but distinct, and makes the ODD an input to the ISO 34502 scenario-based evaluation.
7	ODD requirements and application	Covers the level of abstraction of a definition, why attributes must be monitorable, and the consequences for scenario-based testing.
8	ODD taxonomy	Gives general rules (extensibility, measurement units, placement of new attributes) and the three top-level groups.
9	Scenery elements	Zones, drivable area, junctions, basic road structures, special structures and temporary drivable area structures.
10	Environmental conditions	Weather (temperature, wind, rainfall, snowfall), particulates, illumination and connectivity.
11	Dynamic elements	Traffic agents and the subject vehicle.
12	ODD definition format	Definition modes, human readability, include/exclude/conditional qualifiers, extensibility and relationships, objective boundaries, and statement composition.
Annex A	Operational design conditions (informative)	Extends the external ODD with vehicle-internal aspects.
Annex B	Examples of ODD definitions (informative)	Worked definitions for different regions and use cases.

The taxonomy (Clauses 8 to 11)

At the top, every ODD is split into three groups of attributes, all of equal importance:

Scenery elements – the spatially fixed parts of the environment. Their state may change over time (a reversible lane, a lifting bridge, a traffic signal), but their location does not, so they belong here.
Environmental conditions – weather and atmosphere, light, and connectivity. These can affect every part of an ADS: perception through visibility and sensor quality, planning, and control through changes in road grip, and the communication links the system relies on.
Dynamic elements – the things that move: other traffic and the subject vehicle itself.

Figure 2 – The ISO 34503 taxonomy starts with three top-level groups; each branches into sub-attributes that can be refined further to the level of detail a definition needs.

Scenery elements are the richest branch. Zones capture areas with special rules or boundaries, such as geofenced areas, regions or states, school zones or traffic-management zones. The drivable area is broken down into its type (for example motorways, distributor roads, minor roads, parking areas and shared spaces), its geometry in the horizontal, longitudinal and transverse planes (curves, slopes, divided or undivided carriageways), its lane specification (lane width, markings, lane type, number of lanes, direction of travel), its signs (fixed or variable), its edges (line markings, barriers, shoulders) and its surface (surface type, surface features such as potholes, and conditions induced by weather such as standing water). Junctions cover roundabouts and intersections of various layouts, signalised or not. Further groups cover basic road structures (such as buildings, street lights and vegetation beside the road), special structures (such as tunnels, bridges, toll plazas, pedestrian crossings and level crossings) and temporary structures (such as road works and diversions).

Environmental conditions cover weather (ambient air temperature, wind, rainfall and snowfall, usually expressed in bands of intensity), particulates (for example mist and fog, sand and dust, smoke and pollution, or volcanic ash), illumination (day, night, low sun, artificial lighting) and connectivity (for example vehicle-to-infrastructure communication and positioning services such as satellite navigation).

Dynamic elements cover traffic agents (their types, how many there are, how traffic flows, whether special vehicles such as emergency vehicles are present) and the subject vehicle (most importantly its speed range).

The lists above are illustrative. The standard is designed to be extended: if a deployment needs an attribute that is not in the tree, such as tram tracks, stakeholders may add it, provided it does not conflict with existing attributes, sits at the right level of the hierarchy with a justification, and comes with an objective measurement unit. Extra grouping layers between parent and child attributes are also allowed.

The definition format (Clause 12)

The second half of the standard turns the taxonomy into something you can write. Clause 12 covers six topics:

Type of definition mode – how unmentioned attributes are treated: permissive (inside unless excluded), restrictive (outside unless included) or default (treated as having no effect on performance, so inside but not necessarily monitored).
Human readability – statements are meant to be read by people, including users, dispatchers and authorities, not only by machines.
Inclusion, exclusion and conditional – the three qualifiers that start each statement.
Extensibility and relationships between attributes – how to add attributes and express dependencies, such as a lower speed limit in rain.
Objective boundaries – values must be measurable (a rainfall rate, a lane width in metres, a temperature range), not subjective words like "bad weather".
Statement composition – every statement names a qualifier, an attribute and its value or range; a conditional statement adds the inner include or exclude and the attribute metric it depends on.

Lesson 4 shows how these pieces are used together.

Lesson 4 – How it works in practice

Step 1: agree who the definition is for

The standard accepts that an ODD can be written from two perspectives. An end user perspective, for example a passenger-service operator or a city council, tends to be high level: "suburban streets, daylight, no snow". A system specifier perspective, for example the perception team, needs fine detail: exact lane widths, rainfall bands, sun angles. Both are legitimate and can coexist, but both must be objective enough to avoid misunderstanding. The ADS developer is responsible for the ODD itself, and before deployment should compare it with what the stakeholders require of the operational domain, individually or in consultation.

Step 2: choose the level of detail carefully

The hierarchy has a powerful consequence that beginners often miss. If you include a high-level attribute, you are implicitly claiming every predefined sub-attribute beneath it. Including "rainfall" with no further detail means your system claims to handle drizzle and cloudbursts alike. If the system can only cope with light rain, the definition has to go down to the rainfall-intensity sub-attribute and give the measured limit. The rule of thumb: the narrower the real capability, the deeper the definition must go.

Step 3: pick a definition mode

The mode decides what silence means. In permissive mode, anything not mentioned is inside the ODD, so the author lists the exclusions. This is concise when the system is broadly capable, but risky: if the taxonomy later gains a new attribute, it silently becomes "included". In restrictive mode, anything not mentioned is outside, so the author lists the inclusions. This is safer and easier to defend, but long. Modes can be set for the whole definition and then changed for individual branches, so an author can be permissive about scenery and restrictive about weather. Research on machine-readable ISO 34503 languages, such as the WMG work at the University of Warwick, shows exactly this kind of mixed-mode definition. The default mode is a middle path: unmentioned attributes are treated as not affecting the system, so they count as inside the ODD, but only the attributes explicitly named are expected to be monitored.

Figure 3 – Writing an ODD definition: the mode decides how silence is read, the qualifiers state explicit inclusions and exclusions, and conditional statements capture dependencies between attributes.

Step 4: write statements with objective values

Each statement has the same skeleton: a qualifier, an attribute and a value, list or numeric range. Written in a simple text style similar to the examples presented by the standard's authors, a few statements for a low-speed shuttle might look like this:

Include number of lanes is [1, ∞]
Include lane width is [3.0, ∞] m
Exclude roundabouts are [all]
Exclude rainfall is [heavy rain, violent rain, cloudburst]
Include ambient temperature is [-15, 35] °C
Include subject vehicle speed is [0, 25] km/h

Lists use the names defined in the taxonomy (or in an agreed extension), and numbers carry units. The important design property is that each statement can be checked: a sensor, a map, a weather service or a dispatcher can tell whether the current condition satisfies it.

Step 5: express dependencies with conditional statements

Real capabilities are rarely independent. A shuttle might drive at up to 25 km/h on dry roads but only at 15 km/h when it rains; it might handle curves in general but not curves tighter than a certain radius. The conditional qualifier links such attributes. In one illustrative text style a condition is declared once and then referenced by the statements that depend on it:

Cond_1 Conditional rainfall is [light rain, moderate rain]
Cond_1 Include subject vehicle speed for [light rain, moderate rain] is [0, 15] km/h

The exact syntax is not the point; different tools and the ASAM OpenODD format express it differently. What matters is that the dependency is stated explicitly, in a fixed format, with measurable values, so that both people and the vehicle can apply it.

Step 6: make the ODD monitorable

While driving, the ADS perceives its surroundings and builds a near-real-time picture of the COD. It must compare that picture with the ODD in order to decide when to issue a transition demand (level 3) or start a minimal risk manoeuvre (level 4). During trials, a safety driver or remote dispatcher may do part of this monitoring. The standard therefore stresses that attributes should be defined so that the system can tell whether it is still inside them. Good monitoring also looks ahead: an approaching ODD boundary, such as a tunnel two kilometres away or a weather front, should be forecast with enough time to react. When an exit is imminent, the design may reach a minimal risk condition, hand over to the fallback-ready user, or switch to a degraded mode with lower performance. Boundaries can include time elements too, for example tolerating a short burst of heavy rain but not a sustained one.

Step 7: connect the ODD to testing and the safety case

An ODD definition is a key work product in the safety case. ISO 34503 positions it as an input to the scenario-based safety evaluation of ISO 34502. The typical flow is shown below. Engineers analyse the ODD to derive test scenarios; they combine an instance of the ODD (for example "two-lane suburban road, light rain, dusk") with desired and undesired behaviours of other road users to form scenarios; and they refine those from functional (described in words) through abstract and logical (with parameter ranges) to concrete scenarios (with exact values). The ODD also lets testers label each scenario as inside the ODD, at its boundary, or outside it, and compare the scenario set with the ODD to measure coverage.

Figure 4 – The ODD definition feeds scenario-based testing: scenarios are derived from it, tested inside, across and outside its boundary, and checked for coverage before the evidence enters the safety case.

Testing outside the ODD is not a waste of effort. It checks that the system refuses to engage, warns or falls back when it should, which protects against misuse in conditions it was never designed for. Because development is iterative, the ODD may grow or shrink over time as testing reveals capabilities and limits, and each change ripples through the scenarios and the safety case.

Roles and artefacts

ODD owner (usually in systems or safety engineering) maintains the definition and its change history.
Perception, planning and control teams supply the evidence for each limit, such as sensor range in fog or braking on wet asphalt.
Validation team derives scenarios and reports coverage.
Operations (fleet, dispatch, safety drivers) applies the ODD day to day and reports exits and near misses.
External stakeholders (cities, road authorities, regulators, insurers) supply TOD descriptions and review the ODD.

Typical artefacts are the ODD definition itself (often in a table or a machine-readable file), a TOD description for each deployment, a gap analysis between them, the monitoring and fallback concept, the scenario catalogue and coverage report, and the safety case section that ties them together.

Lesson 5 – Assessment, certification and compliance

No certificate for ISO 34503 itself

ISO 34503 is a product-specification standard, not a management-system standard like ISO 9001. There is no accredited certification scheme that awards an "ISO 34503 certificate" to a company or a vehicle, and you should be cautious of any offer that claims one. What an organisation can do is claim that its ODD definition conforms to ISO 34503: that it uses the taxonomy (and documented extensions), follows the definition-format requirements, and is used in the ways the standard describes, for example as an input to scenario-based evaluation.

Who looks at an ODD definition

Internal safety assessment. Safety teams review the ODD as part of the safety case, together with work products from ISO 26262 (functional safety) and ISO 21448 (SOTIF). A SOTIF analysis, for example, needs to know the operating conditions in which triggering conditions are searched for.
Independent assessors. Third-party assessors who review safety cases against standards such as UL 4600 check that the ODD is complete, objective and backed by evidence, because the whole safety argument is bounded by it.
Regulators and permitting bodies. Authorities that approve automated driving systems or grant trial and deployment permits commonly require a description of the ODD and of the system's behaviour at its boundary. The European Union's type-approval rules for the automated driving systems of fully automated vehicles (Implementing Regulation (EU) 2022/1426), for instance, require the manufacturer to describe the ODD and the system's behaviour at its limits. ISO 34503 is a convenient, recognised way to write that description, although a regulation may set its own content requirements.
Customers and procurers. A city or operator that publishes a TOD can ask bidders to answer in ISO 34503 terms and then compare the answers attribute by attribute.

A practical review checklist

Whoever reviews an ODD definition, the same questions help judge its quality:

Is the definition mode stated, for the whole definition and for any branch that differs?
Does every attribute come from the taxonomy or from a documented, justified extension placed at the right level?
Is every value objective and measurable, with units, rather than a subjective word?
Is the level of detail deep enough where the system's capability is narrow (no high-level inclusion that implicitly claims too much)?
Are dependencies between attributes captured as conditional statements rather than left in prose?
Can each attribute be monitored at runtime by the ADS or by a dispatcher, with enough look-ahead to fall back safely?
Has the ODD been compared with each TOD, and is every gap either mitigated or justified?
Do the test scenarios cover inside, boundary and outside conditions, and is coverage reported against the ODD?

Lesson 6 – Worked example

The situation

Harbourline Mobility, a fictional company, builds a small electric level 4 shuttle with no driver controls. A coastal city wants a free shuttle service on a 6 km loop linking its ferry terminal, railway station, old town and a business park. The route includes two-lane urban streets, a pedestrian-priority shared space in the old town, one signalised crossroads, one roundabout and a short lifting bridge over the harbour. A remote supervisor in a control room can watch several vehicles and stop or recall them.

Step 1 – The city describes the TOD

The city's transport team uses the ISO 34503 taxonomy to describe the route as a target operational domain, as part of its procurement. Scenery: the drivable-area types along the loop, lane widths between 2.9 and 3.5 m, the roundabout, the crossroads, the shared space, the lifting bridge as a special structure that is sometimes open, and seasonal market stalls as temporary structures. Environment: temperatures from about −10 °C to 35 °C, rain all year, occasional snow, frequent sea fog in spring, low sun along the harbour in winter evenings, and mobile coverage with one known dead spot near the bridge. Dynamic elements: many pedestrians and cyclists near the ferry terminal, delivery vans, buses, and emergency vehicles from a nearby fire station.

Step 2 – Harbourline writes its ODD

Harbourline's safety team chooses restrictive mode for environmental conditions (their perception has known weather limits, so they want to list exactly what is supported) and permissive mode for scenery within the geofenced route (the route was mapped in detail, so they list the few exclusions). Their key statements include:

Zones: include the geofenced route only; exclude everywhere else.
Drivable area: include lane widths of 2.8 m and above; include shared space; exclude unmarked gravel surfaces and standing water deeper than a set threshold.
Junctions: include the signalised crossroads; include single-lane roundabouts; exclude multi-lane roundabouts.
Special structures: conditionally include the lifting bridge, only when the bridge signal reports "closed and locked".
Weather: include temperatures from −10 °C to 35 °C; include no rain, light rain and moderate rain; exclude snowfall of any intensity.
Particulates: include visibility of 150 m and above; exclude anything lower.
Illumination: include day and night with street lighting; conditionally include low sun only when the forward camera's glare monitor reports acceptable image quality.
Subject vehicle: include speeds from 0 to 25 km/h; conditionally limit speed to 12 km/h in the shared space and to 15 km/h in rain.

Step 3 – Compare ODD and TOD

The comparison shows three gaps where the city's TOD is wider than the shuttle's ODD: snow, sea fog below 150 m visibility, and the mobile dead spot near the bridge (the ODD includes cellular connectivity because the remote supervisor depends on it). Each gap needs a response. For snow and fog, Harbourline proposes operational rules: the control room checks the forecast and suspends service, and vehicles already running perform a minimal risk manoeuvre to the nearest of six marked safe stopping points if the condition appears during a trip. For the dead spot, the city agrees to install a roadside unit at the bridge, which changes the TOD rather than the ODD. Market days are handled by a conditional route variant that avoids the stall area.

Step 4 – Design monitoring and fallback

For each ODD attribute the team names a monitor: map and localisation for zones and road type; the bridge's infrastructure signal for the lifting bridge; on-board rain and visibility estimation cross-checked with a weather service; a temperature sensor; camera image-quality checks for glare; the vehicle's own speed control for speed. Look-ahead matters: the shuttle receives the bridge status before it reaches the approach, and weather alerts from the control room arrive several minutes before conditions change. Fallback options are a degraded mode (lower speed), a stop at the next safe stopping point, or an immediate stop in lane as a last resort.

Step 5 – Derive and run scenarios

The validation team derives scenarios from the ODD following ISO 34502. Inside the ODD: a cyclist swerving in light rain at night; a delivery van stopped on the roundabout exit. Across the boundary: visibility falling from 200 m to 120 m during a trip; the bridge signal changing to "opening" as the shuttle approaches. Outside the ODD: an attempt to start a trip in falling snow, which the shuttle must refuse. Scenarios are tagged (in the spirit of ISO 34504) by ODD attributes and behaviours so they can be found again, and the team reports how much of the ODD's attribute space the tests cover.

Step 6 – Operate, learn and update

In the first winter, the shuttle performs four minimal risk manoeuvres due to fog, all at safe stopping points, and one unexpected one when a crane at the port blocked part of a lane. The crane is a temporary structure the ODD had not considered. The team adds it as a documented extension under temporary drivable-area structures, writes an exclusion for lane-blocking cranes, adds a scenario, and issues a new ODD version to the city with a change note. The safety case is updated to match.

The example shows the value of a shared format. The city and the developer described the same route with the same vocabulary, the gaps were visible attribute by attribute, and each gap had an owner and a response. Without that common structure, "occasional fog" in a brochure and "visibility above 150 m" in an engineering file might never have been compared.

Lesson 7 – Relationship to other standards and frameworks

ISO 34503 is one link in a chain. It depends on a vocabulary of automation levels, feeds a scenario-based testing process, and is put into machine-readable form by other specifications. The table summarises the most important neighbours.

Standard or framework	Owner	Main question it answers	Relationship to ISO 34503
SAE J3016 / ISO/SAE PAS 22736	SAE International and ISO	What are the levels of driving automation, and what do terms like DDT and ODD mean?	Provides the concept of the ODD, the levels and core terms; ISO 34503 provides the structure for writing an ODD.
ISO 34501	ISO/TC 22/SC 33	What vocabulary do test-scenario standards share?	Source of shared terms such as scenario.
ISO 34502	ISO/TC 22/SC 33	How should the safety of an ADS be evaluated with scenarios?	Uses the ODD definition as a required input for deriving and judging test scenarios.
ISO 34504:2024	ISO/TC 22/SC 33	How should scenarios be categorised with tags?	Tags often reuse ODD attributes, making scenario libraries searchable by ODD.
ISO 34505:2025	ISO/TC 22/SC 33	How are scenarios evaluated and turned into test cases?	Works on the scenario space that the ODD bounds, turning evaluated scenarios into concrete test cases.
BSI PAS 1883	BSI (UK)	How should a UK project specify an ODD in practice?	The 2020 edition was the starting point for ISO 34503; the 2025 edition is a guide to implementing it, with more examples and attributes.
ASAM OpenODD	ASAM e.V.	How can an ODD be exchanged in machine-readable form?	Provides a data model and formats (version 1.0.0, released April 2025) that make ODD definitions processable by tools; ISO 34503 leaves a machine-readable language to the ASAM OpenODD project.
ISO 21448 (SOTIF)	ISO/TC 22/SC 32	How do we handle hazards from performance limits of a fault-free system?	Its analysis of triggering conditions is carried out within, and at the edges of, the ODD.
UL 4600	UL Standards & Engagement	What must a safety case for an autonomous product contain?	Requires the ODD to be defined and argued; an ISO 34503 definition can serve as that part of the case.

How the pieces fit

A simple way to remember the chain: J3016 says an ODD must exist; ISO 34503 says how to write it; ASAM OpenODD says how a computer can read it; ISO 34502, 34504 and 34505 say how to test within it; ISO 26262, ISO 21448 and UL 4600 use it to bound the safety argument; and regulators ask to see it. When you work on an automated driving programme, the ODD definition is often the single document that the most teams, and the most outside parties, refer to.

It is also worth knowing what ISO 34503 is not. It is not a test procedure, not a monitoring specification, not a scenario format (ASAM OpenSCENARIO plays that role) and not a regulation. It is a shared language for one essential input, and its value comes from being used consistently by everyone in the chain.

Common pitfalls and best practices

Pitfalls

Subjective limits. Writing "good weather" or "light traffic" instead of measurable ranges with units. Nobody can test or monitor a word like "good".
Claiming too much by staying high level. Including a parent attribute such as rainfall without detail, which implicitly claims every intensity beneath it.
Forgetting what the mode implies. Using permissive mode and then not noticing that a newly added taxonomy attribute is automatically treated as included.
Confusing ODD and TOD. Treating the city's description of a route as if it were the vehicle's capability, or the reverse, and so never doing the gap analysis.
Unmonitorable attributes. Listing conditions the vehicle and dispatcher cannot detect in time, such as black ice with no sensing or forecast source.
Hidden dependencies. Leaving relationships, such as lower speed in rain, in prose or in a developer's head instead of conditional statements.
Static ODD. Not updating the definition, scenarios and safety case after field events reveal new conditions.

Best practices

Start from the taxonomy and extend it only with documented, justified attributes placed at the right level, never with conflicting duplicates.
State the mode explicitly for the definition and for any branch that differs; prefer restrictive mode where capability is narrow or evidence is thin.
Use numbers and units for every boundary, and record where each number comes from (test data, sensor specifications, field logs).
Pair every attribute with a monitor and a fallback, and design look-ahead for boundaries the vehicle will reach soon.
Compare against each TOD before deployment and give every gap an owner and a mitigation.
Test inside, at and outside the boundary, including refusal to engage outside the ODD, and report coverage against the ODD.
Keep two views in sync: a readable summary for users and authorities and a detailed specification for engineers, generated from the same source where possible.
Version-control the ODD like code, with change notes that flow into scenarios and the safety case.

Summary and key takeaways

ISO 34503:2023 (first edition, ISO/TC 22/SC 33) standardises how to describe an automated driving system's operational design domain: a hierarchical taxonomy plus a definition format.
The ODD specifies the system; the TOD describes a deployment environment; the COD is the live situation. Gaps between ODD and TOD need mitigations, and the COD is monitored against the ODD.
The taxonomy has three equal top-level groups: scenery elements, environmental conditions and dynamic elements, each refined into extensible sub-attributes.
Definitions are written with a mode (permissive, restrictive or default) and statements that start with include, exclude or conditional and give objective, measurable values.
Including a high-level attribute claims all of its sub-attributes, so narrow capabilities need detailed definitions.
The ODD is a key input to scenario-based safety evaluation (ISO 34502) and should drive tests inside, across and outside its boundary.
There is no certification for ISO 34503 itself; the ODD is judged as part of safety cases, independent assessments and regulatory approvals.
BSI PAS 1883:2025 helps implement it and ASAM OpenODD makes it machine-readable.

Reflection questions

Pick an automated feature or service you know of (a motorway pilot, a robotaxi, a campus shuttle). Which three ODD attributes do you think limit it most, and how would you express each as a measurable statement?
For your organisation or a project you know, would you choose permissive, restrictive or default mode for environmental conditions? What evidence would you need to justify the choice to an independent assessor?
Think of a place you travel through often. Describe it as a TOD in the three top-level groups. Which conditions there would most often fall outside a typical shuttle ODD?
Which attributes in your example could the vehicle not monitor reliably on its own? What infrastructure, data service or human role could close that gap?
Imagine a field incident reveals a condition your ODD never mentioned. Outline the steps you would take, from updating the taxonomy to updating the safety case, and who would need to agree to each step.