Safety, Redundancy and Regulation

Safety is a structured claim about a defined feature, vehicle, operating domain and version, supported by evidence before deployment and monitored evidence after deployment. It spans functional safety, sensing limitations, human factors, cybersecurity, operations and regulation; no demonstration, test or mileage figure covers all of it.

Start with a safety case

A safety case is a reasoned argument, supported by evidence, that a system is acceptably safe for a specific use and environment. It connects top-level claims to hazards, requirements, tests, results and operating controls.

The scope must be exact. Evidence for a low-speed service in dry conditions does not establish safety on a motorway in snow. Evidence for one vehicle platform or software release does not automatically transfer to another.

Developers use different frameworks, but a credible safety case should address at least:

competent behavior during normal operation;
detection and management of faults;
limits in intended functionality and perception;
safe interaction with users and other road users;
operational practices, maintenance and incident response;
cybersecurity and controlled software updates; and
evidence that in-service risk remains acceptable.

Public summaries are useful for scrutiny, but they are not the complete case and do not replace regulatory assessment.

Several safety disciplines overlap

Functional safety addresses hazards caused by malfunctioning electrical and electronic systems. ISO 26262 provides the automotive lifecycle framework for this work.

Safety of the intended functionality, covered by ISO 21448, addresses hazards when a system works as designed but the specification, sensor performance or algorithm is insufficient for the situation.

AI safety in road vehicles, addressed by ISO/PAS 8800, covers risks from AI output insufficiencies, systematic errors and random hardware errors.

Cybersecurity engineering, covered by ISO/SAE 21434, manages vehicle cybersecurity risk across the lifecycle.

These disciplines complement rather than replace one another. A perfectly reliable camera can still be unable to classify a novel scene. A capable perception model can still be unsafe if a compromised update changes it.

Redundancy must address the failure

Redundancy is useful only when the alternative path survives the failure being considered. Two computers on one power supply do not protect against loss of that supply. Two cameras behind the same obstruction do not protect against blocked vision.

Higher-automation architectures can separate:

electrical power and communication paths;
sensing modalities and fields of view;
primary compute and independent safety monitoring;
steering and braking actuation paths;
localization sources; and
normal control and minimal-risk control.

The safety analysis determines where diversity or separation is needed. More components can also create more interfaces and failure modes, so hardware count is not a safety metric.

The target is controlled degradation. The vehicle should detect the fault, retain the capability required for the immediate situation and reach its defined minimal-risk condition.

Human dependency changes by level

At Level 2, the human is part of the control loop and must monitor the road continuously. Safety depends on capability limits, clear instructions, driver monitoring, timely alerts and protection against foreseeable misuse. This remains true when a point-to-point system follows a destination route, turns at junctions and stops for traffic controls.

At Level 3, the user may divert attention but must remain available. The system needs a managed transition that accounts for the time required to regain situational awareness.

At Level 4, there may be no driver. The system and its operational support must handle fallback. Remote assistance can supply context, but it should not be disguised as autonomy if a remote human is actually performing the driving task.

Mode confusion is a hazard. The interface must make it clear whether the human or system is driving, what the system can currently do and what response it expects.

Validation needs complementary evidence

No practical road test can encounter every important scenario at useful statistical frequency. No simulation perfectly represents reality.

A mature program combines:

requirements and design analysis;
component and integration tests;
software- and hardware-in-the-loop testing;
scenario simulation and recorded-data replay;
closed-course testing;
supervised public-road testing;
independent review and regulatory tests; and
monitored in-service performance.

Scenario tests answer whether the vehicle handles defined hazards. Exposure data answers how the deployed system performs across real operation. Both need denominators and scope.

A million motorway kilometres cannot validate an urban-intersection claim. A low crash count is not informative without distance, road type, severity, reporting threshold and a comparable human benchmark. Company-reported results should be read with the published methodology and uncertainty.

Waymo’s public Safety Impact dashboard is a strong example of exposure-based reporting because it supplies rider-only distance, outcome definitions, human-benchmark methods and downloadable data. It is still evidence for Waymo’s service domains, not proof that every automated-driving design is safe.

Cybersecurity and updates are safety issues

Connected vehicles expose interfaces through diagnostics, apps, wireless networks, cloud services and supply-chain software. An attacker or corrupted update can affect confidentiality, availability or physical behavior.

Security therefore covers architecture, authentication, secure boot, key management, access control, monitoring, vulnerability response and supplier processes. Privacy is related but distinct: the system can be secure while collecting more occupant or street data than users expect.

UN Regulations 155 and 156 establish frameworks for manufacturer cybersecurity and software-update management systems in applying markets. An over-the-air update to a driving feature should be traceable, authenticated, validated and monitored. Expansion of the operating domain is a safety-relevant product change, not routine infotainment maintenance.

Approval follows the feature and jurisdiction

“Approved” can refer to different legal steps:

a vehicle or component type approval;
permission to test on public roads;
authorization to operate a commercial driverless service;
recognition of an approval in another country; or
compliance with road-traffic rules governing what the human may do.

These are not interchangeable. An SAE level describes the allocation of the driving task and fallback; it is not an approval certificate.

For driver-controlled assistance, UN Regulation 171 establishes requirements for Driver Control Assistance Systems in applying markets. WP.29 adopted a second series of amendments in June 2026 as part of the continuing development of these rules. Because the driver remains responsible, a system approved through a Level 2 or driver-control route does not become an Automated Driving System merely because it follows a route or handles city intersections.

UN Regulation 157 covers Automated Lane Keeping Systems and has provided a route for approved Level 3 motorway features in applying markets. The European Union’s Implementing Regulation 2022/1426 sets type-approval rules for fully automated vehicles in defined use cases, including predefined areas, hub-to-hub routes and automated valet parking.

Tesla FSD (Supervised) in Europe

On 10 April 2026, the Netherlands Vehicle Authority, RDW, granted Tesla FSD (Supervised) a European type approval with provisional validity in the Netherlands. RDW describes it as a driver-controlled assistance system, not self-driving: the driver remains responsible, must monitor traffic and must be able to take over immediately.

RDW also states that European and US versions are not comparable one-to-one. The European assessment therefore does not approve every FSD feature or software version sold elsewhere.

The Netherlands decision was not blanket EU-wide approval. RDW said wider validity requires submission to the European Commission, a vote by member states and majority support in the responsible committee. Until that process is complete, national authorization or recognition must be checked country by country.

The June 2026 UN framework for driverless ADS

On 24 June 2026, UNECE’s World Forum for Harmonization of Vehicle Regulations, WP.29, adopted the first global regulatory framework for fully driverless Automated Driving Systems. The decision comprised a new UN Regulation under the 1958 Agreement and a parallel Global Technical Regulation under the 1998 Agreement, accompanied by amendments to about ninety existing UN vehicle regulations.

This framework addresses systems that perform the complete dynamic driving task, not supervised Level 2 assistance. Its core requirements include:

an audited, lifecycle-wide Safety Management System;
a structured safety case showing no unreasonable risk;
credible simulation, track and real-world validation;
performance that matches or exceeds a competent human driver;
continuous in-service monitoring and reporting; and
storage of safety-relevant automated-driving data.

The framework can cover highway and urban operating domains and can accommodate vehicles without conventional driver controls. It is a major harmonization step because manufacturers and authorities now have a common outcome-focused safety structure for ADS approval.

It is not one worldwide permission slip. Contracting parties still implement the applicable instruments, approve exact vehicle systems and determine where driverless operation is legal. Local road law, operating permits and service conditions remain relevant. The decision also does not reclassify FSD (Supervised), city NOA or other continuously supervised features as autonomous driving.

The United States uses a different path

In the United States, federal vehicle-safety oversight, state operating law and local deployment rules interact. Manufacturers generally self-certify compliance with federal motor-vehicle safety standards, while regulators investigate defects and enforce requirements in use.

NHTSA’s Standing General Order requires specified crashes involving Level 2 systems and automated driving systems to be reported. State and local authorities may separately govern testing and commercial driverless operation. A federal exemption, a state testing permit and permission to carry paying passengers are different decisions.

What credible safety communication looks like

A strong public claim states:

the exact automation level and human role;
the vehicle, hardware, software version and operating domain;
the fallback and minimal-risk behavior;
the approval or permit actually held;
the territory in which it is valid;
the test and operational evidence, with denominators;
known exclusions and unresolved limitations; and
how incidents and updates are monitored.

Vague claims such as “safer than humans” are incomplete without a matched domain, outcome definition, exposure and uncertainty. Safety is not a finish line reached once. The case must be maintained as software, hardware, roads and operations change.