ISO/TS 5083: ISO/TS 5083 – Tutorial (about 60 minutes)

ISO/TS 5083 is the ISO Technical Specification that explains how to make an automated driving system (ADS) safe and how to show that it is safe, for vehicles that drive themselves at automation level 3 or level 4. It is read by safety managers, system architects, verification and validation engineers, operators of automated fleets and the assessors and regulators who review their work. After this tutorial you will be able to explain where ISO/TS 5083 came from and what it covers, use its vocabulary correctly, find your way around its clauses, and plan the main safety activities and evidence for a real automated driving feature, from defining the feature to monitoring it on the road.

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

Course overview

Edition and status: the current and only edition is ISO/TS 5083:2025, Road vehicles – Safety for automated driving systems – Design, verification and validation, edition 1, published by ISO in April 2025 and prepared by technical committee ISO/TC 22 (road vehicles), subcommittee SC 32 (electrical and electronic components and general system aspects). It cancelled and replaced the Technical Report ISO/TR 4804:2020, which had grown out of the 2019 industry white paper Safety First for Automated Driving. ISO's catalogue records that a decision to revise the document was taken on 2025-12-01 (stage 90.92, "to be revised") and lists a successor project for a second edition, ISO/WD TS 5083, still at working-draft stage (comment period closed 2026-09-15). No new edition has been published, so the 2025 edition is the one to apply and the one this course teaches. Verified 2026-10-29 against the ISO catalogue entries for ISO/TS 5083:2025 (ISO project 81920) and its successor (project 93508); clause titles below are paraphrased from the document's published table of contents and commentary, so check a purchased copy for the exact wording.

Who it is for: engineers, product owners, test and validation staff, safety and quality people, fleet operators and project managers who work on (or buy, regulate or insure) vehicles that drive without a human doing the driving, and who are new to ISO/TS 5083. People who already know ISO 26262 (functional safety) or ISO 21448 (SOTIF) will see how this document places those standards inside a wider, system-level safety argument.

Prerequisites: none. A rough picture of how a self-driving vehicle works (sensors that see the world, software that decides, actuators that steer and brake) helps. Every technical term is explained the first time it appears.

By the end of this tutorial:

You will be able to explain why automated driving at levels 3 and 4 needs its own safety approach, and trace ISO/TS 5083 back to its roots in the SaFAD white paper and ISO/TR 4804.
You will be able to define the core vocabulary: ADS, ADS feature, operational design domain, dynamic driving task, DDT fallback, minimal risk condition and manoeuvre, safety capability, risk acceptance criterion and ADS safety case.
You will be able to describe how the document is organised, from the safety strategy through safety by design, validation and operation, and what its informative annexes offer.
You will be able to walk through the top-down chain from acceptable risk to safety principles, capabilities, design elements and evidence.
You will be able to explain how conformity with a Technical Specification is shown and reviewed, and why there is no ISO certificate for it.
You will be able to apply the ideas to a realistic level 4 shuttle service, including the parts of safety that lie outside the vehicle.
You will be able to position ISO/TS 5083 next to ISO 26262, ISO 21448, ISO/SAE 21434, ISO/PAS 8800, UL 4600 and the UN regulations for automated driving.

Lesson 1 – Origins, purpose and scope

Why automated driving needs its own safety approach

For most of the history of the car, safety rested on one assumption: a human driver is in charge. Brakes, steering, airbags and even driver-assistance features such as lane keeping were designed to help that driver, who remained responsible for watching the road and correcting mistakes. If a lane-keeping camera lost the markings, the driver simply steered.

Automation levels 3 and 4 remove that safety net, fully or partly. At these levels the vehicle's automated driving system does the whole driving job on a sustained basis while it is engaged. Nobody is expected to watch the road. At level 3 a human must still be available to take over when the system asks; at level 4 the system must handle every problem itself and, if it cannot continue, bring the vehicle to a safe stop without any human help. The system therefore has to perceive, predict, plan and act correctly in an open world full of other road users, weather, road works and surprises, and it has to cope with its own failures and limitations.

The existing automotive safety standards each cover one cause of danger. ISO 26262 covers malfunctions caused by faults in electrical and electronic systems. ISO 21448 (SOTIF, safety of the intended functionality) covers hazards that come from performance limits and specification gaps even when nothing is broken. ISO/SAE 21434 covers cybersecurity threats. All three are essential for an ADS, but none of them answers the top-level questions an ADS developer faces first: How safe is safe enough? What must the system be able to do to reach that level? How do we combine fault tolerance, perception limits, human interaction, security and operations into one convincing argument? ISO/TS 5083 was written to answer those questions and to tie the specialised standards together.

From an ethics report to a Technical Specification

The ideas behind ISO/TS 5083 developed in several steps.

In June 2017 the German Ethics Commission on Automated and Connected Driving recommended that automated driving should only be licensed if it promises a positive risk balance: overall, it should reduce harm compared with human driving.
In July 2019 eleven companies (Aptiv, Audi, Baidu, BMW, Continental, Daimler, FCA US, HERE, Infineon, Intel and Volkswagen) published the white paper Safety First for Automated Driving, usually shortened to SaFAD. It worked from the top down: how safe a level 3 or level 4 system must be, which twelve principles are needed to get there, which capabilities follow from the principles, which building blocks (elements) provide those capabilities, and how to verify and validate the result.
The SaFAD authors took the paper into ISO, where it became the Technical Report ISO/TR 4804:2020. A Technical Report is informative: it describes good practice but contains no requirements.
ISO/TC 22/SC 32 then reworked the report into ISO/TS 5083 (project registered in December 2020, published in April 2025). The main changes are a revised scope, objectives and requirements in the normative clauses (which a Technical Report cannot have), a revised overall safety strategy that also covers assumptions and requirements placed on parties outside the ADS, links to cybersecurity, and revised informative annexes with worked examples and material on the safety of artificial intelligence.

Figure 1 – The lineage of ISO/TS 5083, from an ethical principle to an industry white paper, a Technical Report and today's Technical Specification.

What a Technical Specification is

ISO publishes several kinds of document. An International Standard (IS) is the full consensus product. A Technical Specification (TS) is used when the subject is still developing quickly or when the consensus needed for an International Standard has not yet been reached, but experts agree that publishing now is useful. A TS can contain requirements, which a Technical Report cannot, and it goes through a lighter approval process. ISO reviews a TS within a few years of publication and then decides whether to confirm it, revise it, turn it into an International Standard or withdraw it. For ISO/TS 5083 the revision decision came quickly, which reflects how fast automated driving practice is moving.

Scope in plain words

What it gives: guidance and requirements for achieving and demonstrating the safety of an ADS integrated into a road vehicle, based on safety principles drawn from publications used worldwide and on top-level safety objectives.
Lifecycle covered: safety by design, verification and validation, and activities after deployment (operation in the field). It also outlines cybersecurity considerations.
Automation levels: level 3 and level 4 ADS features as defined in ISO/SAE PAS 22736, the ISO edition of the SAE J3016 level taxonomy. Level 2 driver assistance and level 5 (unlimited) automation are outside its scope.
Vehicles: road vehicles including trucks and buses; motorcycles and mopeds are excluded.
Exemption: ADS and related elements already in operation or under development before publication are exempt, so the document is aimed at new developments.
Not covered: the safety of development activities themselves, such as test drives with safety drivers on public roads, is recognised as important but is outside the document.
No normative references: the document does not make any other standard mandatory. It points to related standards (an informative annex lists them) and expects the user to apply the right ones.

Lesson 2 – Key concepts and vocabulary

ISO/TS 5083 reuses many terms from ISO/SAE PAS 22736, ISO 26262 and ISO 21448 and adapts them to ADS. Getting them right matters, because a safety argument is only as clear as its words. The definitions below are paraphrased.

Automated driving system (ADS) – the hardware and software that together can perform the entire driving task on a sustained basis, whether or not this is limited to a particular domain. In this document the term means a level 3 or level 4 system.
ADS feature – a specific application of an ADS at a given automation level within a given operating domain, such as a motorway pilot or automated valet parking. One ADS can offer several features.
Dynamic driving task (DDT) – everything needed in real time to drive in traffic: steering, accelerating and braking, monitoring the surroundings, responding to objects and events, planning manoeuvres and making the vehicle visible (lights, signals). Trip planning and choosing destinations are not part of it.
Object and event detection and response (OEDR) – the part of the DDT that watches the environment and reacts appropriately to what it finds.
Operational design domain (ODD) – the operating conditions a feature is specifically designed for: road types, geography, speed range, weather, light, time of day, traffic situations and similar limits.
DDT fallback – the response when the driving task cannot continue normally, because of a relevant system failure or because the vehicle is leaving its ODD. Either a human takes over the driving or a minimal risk condition is reached, by the human or by the ADS.
Minimal risk condition (MRC) – a stable, stopped state that lowers the risk of an incident when a trip cannot or should not go on, for example stopped on the hard shoulder with hazard lights on.
Minimal risk manoeuvre (MRM) – the vehicle movement, directed by the ADS or by a fallback-ready user, that brings the vehicle into a minimal risk condition.
Fallback-ready user – at level 3, the qualified person who is able to drive and stays receptive to the system's requests to intervene and to obvious failures, ready to perform the fallback.
Driver, passenger and other road user – the document separates the roles people play. A driver performs some or all of the DDT or the fallback; a passenger has no role in operating the vehicle; another road user (a pedestrian, cyclist, or the driver of another car) has no role with respect to the subject vehicle but affects what it must do. The same person can change role during a trip.
Safety capability – a property the ADS needs for safe operation. Capabilities cover nominal driving as well as degraded operation and the fallback.
Risk acceptance criterion – a criterion that expresses what "no unreasonable risk" means for this feature. It can be qualitative or quantitative, for example a maximum rate of incidents per operating hour, a physical threshold for hazardous behaviour, or the ALARP principle (as low as reasonably practicable).
Unreasonable risk – risk judged unacceptable in its context according to valid societal moral concepts (the ISO 26262 meaning). "Safe" means free from unreasonable risk; it never means zero risk.
ADS safety case – a structured argument, supported by evidence, that makes a compelling, understandable and valid claim that the ADS-equipped vehicle achieves safety for a given feature in a given environment.
Verification – activities that show an examined object meets its specified safety requirements ("did we build it right?").
Validation – activities that show the operation of the ADS-equipped vehicle actually achieves safety for the feature in its intended environment ("did we build the right thing, and is it safe enough?"). The intended environment can be wider than the ODD, because the vehicle must also behave safely at and beyond the ODD boundary.
Incident – an event that caused, or could have caused, harm or damage, or an anomaly that could lead to harm later. Near misses count as incidents, which matters for field monitoring.

Fallback in action

The DDT fallback is where level 3 and level 4 differ most, and it shapes many design decisions. At level 3, when the ADS reaches a situation it cannot handle, it issues a request to intervene and must keep driving safely for long enough for the fallback-ready user to take over. If the person does not respond, the system performs a minimal risk manoeuvre. At level 4, no human is needed: the ADS itself must always be able to complete a minimal risk manoeuvre, even after some of its own components have failed. Figure 2 shows these paths.

Figure 2 – DDT fallback: after a failure or at the ODD boundary, a level 3 feature asks the fallback-ready user to take over, while a level 4 feature performs the minimal risk manoeuvre itself.

"Safe enough" as an explicit target

A key idea in ISO/TS 5083 is that "safe" must be made explicit before engineering starts. Older driver-assistance projects could lean on the driver as the final barrier. An ADS cannot, so the organisation has to decide and write down its risk acceptance criteria. A common starting point, inherited from the Ethics Commission and SaFAD, is the positive risk balance: the automated feature should cause less harm than comparable human driving in the same kind of traffic. Because accident statistics differ between countries, road types and conditions, the comparison must be made for the feature's actual ODD, not against a global average. Other criteria are added on top, for example that the vehicle must never cause certain types of collision that a careful human would avoid, or that it must obey traffic rules. Positive risk balance on average is therefore necessary but not sufficient.

Lesson 3 – Structure of the document

ISO/TS 5083 follows the usual ISO layout. Clauses 1 to 4 are the scope, normative references (none), terms and definitions, and abbreviations. The technical content sits in clauses 5 to 10, each normative clause stating objectives first and then requirements and recommendations, often followed by "example solutions". Informative annexes then give worked examples and further guidance. The description below is a paraphrase of the published table of contents and commentary.

Clause	Topic	What it does, in short
5	Document overview and motivation	Purpose and goals, how to apply the document, the safety lifecycle, what an ADS safety case is, the ADS's role within safe vehicle operation, how other standards apply, and the safety principles of ADS.
6	Safety strategy	Define the ADS feature (including its ODD), define the risk acceptance criteria, and derive safety requirements.
7	Safety by design	Design the ADS to meet the requirements; state the prerequisites and assumptions placed on things outside the ADS; verify the ADS; verify and confirm the external aspects.
8	Validation	Show the ADS-equipped vehicle achieves the risk acceptance criteria in its intended environment, with example approaches such as safety metrics, computed collision rates and evidence for injury-risk assumptions.
9	Operation of the ADS-equipped vehicle	Post-deployment duties: field monitoring, incident handling, cybersecurity monitoring and vulnerability analysis, and managing changes safely.
10	Verification and validation considerations	Cross-cutting considerations for planning and combining V&V methods, with an example solution.

The informative annexes

An example application of the document's concepts, including how user roles change during a trip.
Safety of artificial intelligence applied to ADS, for example machine-learned perception.
A list of related standards.
The safety principles for ADS, which trace back to the twelve SaFAD principles.
Example solutions that show possible ways to meet the objectives of the engineering clauses, from the safety strategy to verification and validation.

Note the balance: much of the 158-page document is informative guidance and examples rather than requirements. The document is deliberately not a cookbook. It sets objectives and requirements, then shows example ways to meet them, leaving room for different technical solutions.

Figure 3 – How ISO/TS 5083 is organised: foundations in clause 5, an engineering flow from strategy to operation in clauses 6 to 9, and supporting guidance from clause 10 and the annexes.

The SaFAD principles behind the structure

The safety principles at the heart of the approach come from SaFAD, which named twelve: safe operation, safety layer, operational design domain, behaviour in traffic, user responsibility, vehicle-initiated handover, vehicle-operator-initiated handover, interdependency between the vehicle operator and the ADS, safety assessment, data recording, security, and passive safety. Each principle is a short statement of a goal, for example that the system must recognise when it is about to leave its ODD and respond safely, or that relevant data must be recorded so incidents can be analysed.

Principles alone cannot be implemented, so the approach breaks them down. Principles lead to capabilities: things the system must be able to do, such as localising itself, perceiving relevant objects, predicting their behaviour, planning a safe path, executing it, interacting with other road users, and detecting when its own nominal performance is no longer achieved. SaFAD sorted these into fail-degraded capabilities (keep driving safely for a limited time until a minimal risk condition is reached) and fail-safe capabilities (after a failure the risk stays small or is covered by degraded operation). Capabilities are then provided by elements, the building blocks of the architecture: sensors, perception and fusion functions, HD maps, planning, actuators, power supply, a monitoring channel and so on. The elements are arranged into an architecture, and the whole chain is verified and validated.

Figure 4 – The top-down chain: acceptable risk drives principles, principles drive capabilities, capabilities drive the design, and verification and validation evidence feed the safety case.

Lesson 4 – How it works in practice

This lesson follows the safety lifecycle that ISO/TS 5083 describes, from the first definition of a feature to its life on the road. In practice the steps overlap and loop, but the order shows the logic.

Step 1 – Define the ADS feature

Everything starts with a precise description of the feature: its automation level, what it does, its ODD, how it is engaged and disengaged, which users are involved and in which roles, what the vehicle does at the ODD boundary, and which external services it depends on (maps, connectivity, remote assistance, depot staff). A vague feature definition is the most common root cause of weak safety arguments, because every later step depends on it. Engagement and disengagement sequences that people could reasonably foreseeably trigger, including mistakes, belong in the definition.

Step 2 – Define risk acceptance criteria

Next the organisation decides what "no unreasonable risk" means for this feature, as explained in Lesson 2. Good criteria are explicit, measurable where possible, tied to the ODD, and agreed by people with the authority to accept risk on behalf of the company. They usually combine an overall target (for example a positive risk balance against human drivers on comparable roads, expressed as a rate of injury crashes per operating hour or distance) with behavioural rules (obey traffic law, keep safe distances, never create certain critical situations) and principles such as ALARP. Cybersecurity is part of this step: the results of the threat analysis are considered when deciding what risk is acceptable, because an attack that disables braking is as harmful as a fault that does.

Step 3 – Derive safety requirements

The criteria and the safety principles are broken down into safety requirements on the ADS and, importantly, on things outside it. ISO/TS 5083 asks developers to be clear about which requirements and assumptions they place on the vehicle platform (for example braking and steering redundancy), on infrastructure, on map providers, on remote operators and on the people who use or maintain the vehicle. Each external assumption becomes something that must later be checked.

Step 4 – Safety by design

The ADS is designed to provide the required safety capabilities. Typical design patterns include:

Diverse sensing: combining sensors with different physical principles (for example camera, radar and lidar) so that one weakness does not blind the whole system.
Redundancy and degradation: enough redundancy in computing, power, braking and steering that a single failure still allows a minimal risk manoeuvre.
A safety layer or monitor: an independent channel that checks the main planner's decisions against simple safety rules and can override them.
ODD monitoring: functions that detect when conditions are leaving the ODD (heavy rain, unmapped road works) early enough to react.
Clear human interaction: HMI (human machine interface) designs that make the current role of each person obvious and that give a level 3 user enough time and information to take over.
Machine learning with safeguards: treating learned components as software components with their own data, training, evaluation and monitoring requirements (Annex B), and limiting what they are trusted to do.
Data recording: recording the data needed to reconstruct and learn from incidents.

Step 5 – Verification

Verification checks that each element, and the integrated ADS, meets its safety requirements. Because the scenario space is enormous, verification uses a mix of methods: reviews and analysis, unit and integration tests, simulation with many variations of scenarios, hardware-in-the-loop rigs, proving-ground tests of critical manoeuvres, and limited public-road driving. The external prerequisites are verified or confirmed too, for example that the HD map supplier's update process meets the accuracy and freshness that the design assumed.

Step 6 – Validation

Validation asks whether the complete vehicle, operating in its intended environment, really meets the risk acceptance criteria. Driving alone cannot prove a rare-event rate: the RAND Corporation's 2016 study Driving to Safety showed that demonstrating a fatality rate lower than human drivers by road testing alone would take hundreds of millions of miles. ISO/TS 5083 therefore points to combinations of methods and gives example solutions: defining safety metrics, computing expected collision rates from component and scenario data, building evidence for injury-risk assumptions (how likely a given collision speed is to injure someone), scenario-based testing with coverage arguments, and statistical field data. Validation also covers behaviour near and beyond the ODD boundary, where the vehicle must still act safely.

Step 7 – Build the ADS safety case and decide on release

All the claims, arguments and evidence are assembled into the ADS safety case: the top claim that the feature is free from unreasonable risk in its environment, broken down into sub-claims about the design, the verification, the validation, the external assumptions and the operational processes, each backed by evidence. Release for deployment is a management decision based on that case and on any open issues and restrictions (for example a narrower ODD at launch).

Step 8 – Operation after deployment

Deployment is not the end. Clause 9 sets expectations for operation: monitor the fleet in the field, detect and analyse incidents and abnormal operations (including near misses), monitor cybersecurity and analyse new vulnerabilities, assess whether each finding affects the safety case, and manage changes so that updates, map changes and ODD extensions are introduced without reducing safety. Field data then feeds back into the feature definition, the criteria and the design, closing the loop.

Figure 5 – The ISO/TS 5083 safety lifecycle as a loop: field findings that affect safety trigger a managed change that re-enters the lifecycle at the feature definition.

Roles and artefacts

The document is meant for everyone in the chain: technology and component suppliers, system integrators, vehicle manufacturers, transport service providers and fleet operators, and regulators. In a typical programme you will find a safety manager who owns the safety case; system architects who own the capability breakdown and architecture; perception, planning and platform teams who own element requirements; a V&V team who own the test strategy, simulation and metrics; an operations team who run field monitoring and incident response; and a cybersecurity team who run threat analysis and vulnerability management. Typical artefacts are the feature and ODD description, the risk acceptance criteria rationale, the safety requirements with their allocation (inside and outside the ADS), the architecture and design rationale, verification and validation plans and reports, the safety case, and the operational monitoring and change records.

Lesson 5 – Assessment, certification and compliance

There is no ISO/TS 5083 certificate

ISO writes standards but does not certify against them, and there is no ISO-operated certification scheme for ISO/TS 5083. A Technical Specification also has a softer status than an International Standard: it represents expert agreement that is still maturing. Organisations therefore talk about applying or aligning with ISO/TS 5083 rather than being certified to it. Some testing, inspection and certification companies offer gap analyses, training and independent assessments against it; any statement they issue is their own conformity statement, not an ISO certificate. Be wary of anyone selling an "ISO/TS 5083 certification" as if it were an official scheme.

How conformity is actually judged

Because the document is built around objectives, requirements and a safety case, assessment focuses on whether the safety case convinces a competent, independent reviewer. Typical questions are:

Is the feature, including its ODD and user roles, defined precisely enough to analyse?
Are the risk acceptance criteria explicit, justified for this ODD, and approved by people with authority to accept risk?
Does every safety principle trace to capabilities, requirements and design measures, and are assumptions on external parties written down and confirmed?
Do the verification and validation methods together cover the scenario space, including rare and boundary situations, and do the results meet the criteria with enough confidence?
Are cybersecurity threats considered in the safety argument, and are vulnerabilities monitored in operation?
Do field monitoring, incident handling and change management actually work, and do they feed back into the safety case?

Evidence is reviewed in safety case reviews, audits of the processes that produced it, and confirmation reviews by people independent of the development team, the same kind of independence that ISO 26262 asks for with its confirmation measures.

Regulation and type approval

ISO/TS 5083 is voluntary. Regulators, however, decide whether automated vehicles may be sold or operated, and they increasingly ask manufacturers to demonstrate a safety management system and a documented safety argument. Examples include UN Regulation No. 157 on automated lane keeping systems (a level 3 motorway function approved under the UNECE 1958 Agreement) and the European Union's Implementing Regulation (EU) 2022/1426 for the ADS of fully automated vehicles produced in small series. Such rules usually describe what must be shown rather than naming one standard. A well-built ISO/TS 5083 safety case is a recognised way to show the state of the art and to organise the evidence that an approval authority, technical service, insurer or customer will ask for; it does not replace any legal requirement. Check the current regulations for your market, because this area changes quickly.

Status of the document itself

Because ISO decided to revise the document in December 2025, an organisation that adopts ISO/TS 5083 now should record which edition its process follows and plan to review the revision when it is published. The underlying approach (explicit acceptance criteria, top-down capabilities, combined V&V, safety case and field monitoring) is stable even if details change.

Lesson 6 – Worked example: a level 4 campus shuttle

To tie the ideas together, follow a fictional company, CityLoop Mobility, which builds and operates small electric shuttles that carry up to ten passengers around a business and university district. The shuttle has no steering wheel used in service; an operations centre can give remote assistance (advice such as confirming that it may pass a parked delivery van) but does not drive the vehicle in real time.

1. Feature definition

The team defines the feature "Campus Loop", a level 4 ADS feature. The ODD is a fixed 6 km route of mapped two-lane streets with a speed limit of 30 km/h, two signal-controlled junctions and twelve stops; daytime and night with street lighting; dry or light rain; no snow or ice; mixed traffic with pedestrians, cyclists, cars and delivery vans. Passengers have no driving role, so they are passengers in the ISO/TS 5083 sense. The document lists the external dependencies: the HD map supplier, the city's traffic signal data feed (used only as a hint, never trusted alone), the operations centre and the depot maintenance staff. It also lists foreseeable human behaviours: passengers standing when the shuttle starts, a passenger pressing the emergency stop, pedestrians walking out between parked cars.

2. Risk acceptance criteria

Using police and insurer statistics for urban streets with similar speed limits, the team estimates the injury-crash rate of human-driven minibuses and sets the overall target to be clearly below that rate per operating hour. It adds behavioural criteria: obey traffic rules except when needed to avoid a collision; never hit a stationary object within the ODD; keep braking gentle enough that standing passengers are not likely to fall, except in an emergency; and reach a minimal risk condition within a defined distance after any single failure. ALARP applies to residual risks. The cybersecurity team's threat analysis shows that spoofed traffic-signal data could matter, which is one reason that feed is never trusted on its own. The criteria are signed off by the managing director and the head of safety.

3. Safety requirements and capabilities

From the principles, the team derives capabilities and requirements. Examples: the ADS shall detect pedestrians and cyclists within the stopping distance in all ODD lighting conditions (perception); the ADS shall localise itself on the route even if satellite positioning is lost for a stated time (localisation); the ADS shall recognise when rainfall exceeds the ODD limit and stop at the next safe stop (ODD monitoring); after any single failure in computing, power, braking or steering, the shuttle shall complete a minimal risk manoeuvre to the kerb (degraded operation); the shuttle shall record data before and after any emergency braking (data recording). External requirements are written for the map supplier (update within 24 hours of a reported road change), the operations centre (staffing and response times) and the depot (daily sensor cleaning and calibration checks).

4. Design

The architecture uses lidar, radar and cameras with overlapping fields of view, two independent computers (a main planner and a simpler safety monitor that can command a controlled stop), redundant brake actuation, dual low-voltage power supplies and a dedicated event data recorder. The pedestrian detector is a neural network; following the AI guidance, the team documents its training data coverage for the ODD (night, rain, children, wheelchairs, people carrying large objects) and adds a non-learned obstacle check from lidar as a backstop. Passenger information screens announce stops, delays and any minimal risk manoeuvre.

5. Verification

Each element is verified against its requirements: sensor detection ranges in a test hall, safety monitor logic by analysis and fault-injection tests, brake redundancy on the proving ground. Integrated tests run in simulation using a scenario catalogue built from the ODD description (pedestrian emerging from behind a van, cyclist overtaking at a stop, signal failure at a junction), with thousands of parameter variations. The map supplier's update process is audited against the 24-hour requirement, and the operations centre's procedures are rehearsed.

6. Validation

The team combines several sources of evidence. It drives the route for several months with a trained safety operator on board (development testing, whose own safety is outside ISO/TS 5083 but handled under the company's test safety plan), logging every disengagement and every situation where the safety monitor intervened. It computes expected collision rates by combining measured perception performance with the frequency of relevant scenarios on the route, and checks injury-risk assumptions against published data for low-speed impacts. Scenario coverage metrics show which situations have been tested and which remain. The validation report states the remaining uncertainty openly.

7. Safety case and release

The safety case's top claim is that Campus Loop operates without unreasonable risk within its ODD and at its boundary. Sub-claims cover the feature definition, the criteria, the capabilities and design, verification, validation, external dependencies, cybersecurity and operations. An independent internal assessor reviews the case and finds one gap: there is no evidence that the minimal risk manoeuvre works on the two short sections without a kerbside stopping place. The team adds a requirement to stop in the lane with hazard lights and an alert to the operations centre on those sections, verifies it, and the case is approved for a limited launch (daytime only for the first three months).

8. Operation

In service, every shuttle uploads summaries of hard braking events, safety monitor interventions, remote assistance requests and near misses. A weekly review classifies findings. After two months the data shows frequent hard braking near one stop, caused by cyclists cutting in. The team analyses whether this affects the safety case (passenger falls are part of the criteria), changes the approach speed for that stop through a managed software update with regression testing, and records the change. Meanwhile the cybersecurity team learns of a vulnerability in an open-source communication library used by the telematics unit; they assess its effect on safety functions, apply a patch through the same change process and update the threat analysis. Only after six months of field data that meets the criteria does the company extend the ODD to night operation, again through the full lifecycle.

Lesson 7 – Relationship to other standards and frameworks

ISO/TS 5083 is an umbrella. It sets the overall safety strategy for an ADS and relies on other documents for specialised topics. Knowing who does what avoids both gaps and duplicated work.

Document	Main focus	How it relates to ISO/TS 5083
ISO 26262:2018 (third edition in development)	Functional safety of electrical and electronic systems: avoiding and controlling systematic and random hardware faults, with ASIL classification	Applied to the ADS hardware and software elements to deal with faults; ISO/TS 5083 borrows its notions of harm, unreasonable risk, verification and independence.
ISO 21448:2022 (SOTIF)	Hazards from functional insufficiencies and reasonably foreseeable misuse, without faults	Applied to perception and decision limits of the ADS; its idea of acceptance criteria for residual risk is close to the risk acceptance criteria of ISO/TS 5083.
ISO/SAE 21434:2021	Cybersecurity engineering across the vehicle lifecycle, including threat analysis and risk assessment (TARA)	Provides the security engineering process; ISO/TS 5083 links its results into the safety strategy and expects security monitoring in operation.
ISO/PAS 8800:2024	Safety and artificial intelligence in road vehicles	Deepens the AI safety topics that ISO/TS 5083 introduces in an annex, such as data and model assurance for learned components.
ISO/SAE PAS 22736:2021	Taxonomy and definitions of driving automation levels 0 to 5	Source of the level 3 and level 4 definitions and of many terms (ADS, DDT, ODD, MRC).
ISO 34502:2022	Scenario-based safety evaluation framework for ADS	Offers a structured way to build scenarios for the verification and validation that ISO/TS 5083 requires.
ANSI/UL 4600	Evaluation of autonomous products through a safety case, with detailed prompts on what the case should cover	A complementary safety-case standard from UL Standards & Engagement; both expect a structured argument with evidence and field feedback.
UN Regulation No. 157 and EU 2022/1426	Legal approval requirements for specific automated driving systems	Regulatory duties; an ISO/TS 5083 safety case helps organise the evidence they ask for but does not replace them.

A simple way to remember the split

Think of three causes of harm and one umbrella. Faults are ISO 26262's job; insufficiencies of the intended function are ISO 21448's job; attacks are ISO/SAE 21434's job. ISO/TS 5083 sits above them for level 3 and level 4 systems: it asks how safe the whole automated driving feature must be, which capabilities it needs, how the vehicle, the people and the external services share responsibility, how to validate the complete vehicle and how to keep it safe in operation. It then uses the other standards as tools to meet parts of that goal. UL 4600 and ISO 34502 provide additional methods for the safety case and for scenarios, and regulations decide what is legally required.

Common pitfalls and best practices

Pitfalls

Treating ISO 26262 compliance as enough. A fault-free ADS can still be unsafe because of perception limits, poor behaviour in traffic or human confusion about roles. ISO/TS 5083 expects all causes to be argued together.
Leaving "safe enough" implicit. Without written, justified risk acceptance criteria, validation has no target and reviewers cannot judge the result.
Comparing against the wrong baseline. Benchmarking against a global average of human driving instead of comparable roads and conditions in the actual ODD can make the target far too easy or impossibly strict.
Forgetting assumptions outside the vehicle. Maps, remote operations, maintenance and infrastructure carry safety assumptions; if nobody owns and checks them, the safety case rests on hope.
Relying on mileage alone. Driving distance on its own cannot prove rare-event rates; it must be combined with simulation, analysis and scenario coverage.
Stopping at release. Without field monitoring, incident analysis, vulnerability management and controlled change, the safety case decays as the world and the software change.
Claiming an official certificate. There is no ISO certification for this Technical Specification; overstating assessment results misleads customers and regulators.

Best practices

Write the feature and ODD definition first, and in detail, including user roles, engagement sequences and behaviour at the ODD boundary.
Trace top-down: from criteria to principles, capabilities, requirements, design elements and evidence, so every claim in the safety case has a source and a test.
Allocate and confirm external requirements through contracts, audits and operational checks, and include them in the safety case.
Design for degradation: plan from the start how the vehicle reaches a minimal risk condition after any single failure, and test it.
Combine verification and validation methods (analysis, simulation, proving ground, road testing, statistical arguments) and state the remaining uncertainty openly.
Integrate cybersecurity by feeding threat analysis results into the risk acceptance decision and by running security monitoring alongside safety field monitoring.
Use independent review of the safety case and of the processes behind it, by people who did not build the system.
Treat ODD extensions as new features, taking them through the full lifecycle rather than through a quick configuration change.

Summary and key takeaways

ISO/TS 5083:2025 is the ISO Technical Specification for the safety of level 3 and level 4 automated driving systems in road vehicles; it replaced ISO/TR 4804:2020, and ISO has decided to revise it.
It grew from the positive risk balance idea and the 2019 SaFAD white paper, and keeps their top-down logic: acceptable risk, principles, capabilities, elements, verification and validation.
Its normative clauses run from document overview and safety strategy, through safety by design and verification, to validation and operation, with long informative annexes of examples, AI guidance and related standards.
Making "safe enough" explicit through risk acceptance criteria tied to the ODD is the starting point for all later work.
The ADS must handle its own fallback at level 4, and must give a fallback-ready user enough time at level 3; minimal risk manoeuvres and conditions are central design targets.
Safety also depends on parties outside the ADS, so assumptions placed on maps, infrastructure, operators and maintenance must be stated and confirmed.
The ADS safety case collects the argument and evidence; field monitoring, cybersecurity monitoring and managed change keep it valid after deployment.
There is no ISO certificate for ISO/TS 5083; it complements ISO 26262, ISO 21448, ISO/SAE 21434 and regulations rather than replacing them.

Reflection questions

Pick an automated driving feature you know (or imagine one). Write its ODD in five lines. Which conditions would be hardest for the system to detect at the boundary, and what should it do there?
How would you justify a risk acceptance criterion for that feature to a sceptical regulator? Which human-driving baseline would you use, and which additional behavioural criteria would you add?
List three assumptions your feature makes about parties outside the vehicle. Who owns each one, and how would you confirm it holds before and after launch?
Your validation evidence comes from 200,000 km of road testing, one million simulated scenarios and a component-based collision-rate calculation. What claim can each source support, and where would a reviewer look for gaps?
After launch, field data shows a type of near miss you did not foresee. Describe the steps you would take, from detection to a decision about changing the feature, and how the safety case would be updated.