Road vehicle functional safety

An electronic vehicle function can fail through hardware, software or interactions between systems. ISO 26262 addresses functional safety in that road vehicle context, with its scope focused on safety-related electrical and electronic systems and hazards from malfunctioning behavior. The first question is the item being developed and how it interacts with the vehicle and users. A component’s safety claim does not establish the safety of every vehicle integration, and functional safety does not encompass every possible hazard associated with road use.

The series separates vocabulary, management and technical lifecycle subjects. The selected ISO Open Data records identify Parts 1 and 2 and describe their road vehicle scope. The 2018 scope should not be replaced by limitations quoted from older studies of earlier editions. An engineering program needs the relevant parts and the actual development context. This reference does not reproduce the series’ integrity classification or technical development requirements, and it does not treat a family citation as a completed safety argument.

Selected ISO metadata: ISO 26262-1:2018 (edition 2, published 2018-12-17); ISO 26262-2:2018 (edition 2, published 2018-12-17). The selected ISO records are Parts 1 and 2 of the 2018 series. They do not represent every part needed for a complete development program. NHTSA’s published research illustrates an application of a concept-phase process; it is not a current legal adoption of every ISO 26262 provision or a replacement for the series’ own edition records. The selected official records were checked on 19 October 2026; no unverified day has been added to a year-only or month-only record.

For a steering-related electronic function, the item definition needs to identify operating modes, dependencies and interfaces with other systems. An assumed vehicle response or driver action can affect the safety concept. The development evidence connects hazards, safety goals and allocated requirements to verification of the implemented design. A supplier element can support that work when its assumptions and conditions of use are visible. Integration then checks whether those conditions hold in the actual vehicle configuration rather than transferring a component claim unchanged.

NHTSA’s published research includes a functional safety study of a generic automated lane-centering system using an ISO 26262 concept-phase process. This demonstrates a research use, not incorporation of the entire standard into U.S. vehicle law. Applicable Federal Motor Vehicle Safety Standards, certification duties and defect responsibilities require their own legal analysis. A voluntary technical process and a statutory vehicle compliance obligation can be relevant at the same time without being equivalent.

Identify the item, vehicle assumptions, operating situations and affected interfaces. Can safety goals be followed into allocated requirements and verification evidence? Are hardware and software versions consistent across the records? Do supplier assumptions, diagnostics and degraded operation match the integration? Changes in a platform, control strategy or operating domain can affect the original analysis. An integrity label on a component provides incomplete evidence if the system-level assumptions and the actual allocation of the safety function are not available.

The key finding is that functional safety evidence is tied to a defined item and its integration. A process certificate or component claim cannot establish that every vehicle-level hazard has been addressed. Public metadata and NHTSA research support the distinction between a sector framework, its application and legal compliance. This reference does not assign an automotive safety integrity level, validate a vehicle safety concept or determine conformity of a particular electronic system to the complete ISO 26262 series.

Functional safety supplies the general system context, while software product quality concerns a different quality model. Industrial cybersecurity helps distinguish malicious threats from malfunctioning behavior, although automotive-specific sources remain necessary. Follow the transport and energy subject to keep vehicle technical evidence separate from battery transport and market-specific vehicle obligations.

Sources were checked on 19 October 2026. The NHTSA source describes research, not a rule or approval service. Publication metadata is from ISO Open Data; the full standard and the specific vehicle regulatory requirements are separate sources. ISO metadata is attributed under ODC-By 1.0. The examples and evidence questions are original. Submit a correction request with the reference, statement and supporting official material for review.