ISO 26262 Part 1 – Vocabulary and Key Terminology Explained

Hello, automotive engineers and functional safety enthusiasts! Welcome to the first deep-dive post in our comprehensive ISO 26262 series at PiEmbSysTech. In this article, we will thoroughly explore ISO 26262 Part 1 – Vocabulary, which defines all the terms, definitions, and abbreviations that are used throughout the entire 12-part standard.

You might think that a “vocabulary” section sounds simple or even boring. Trust me – it is one of the most critical parts of the entire standard. In safety engineering, a single misinterpreted term can lead to flawed hazard analysis, incorrect ASIL assignment, miscommunicated safety requirements across the supply chain, and ultimately, an unsafe product reaching the road. The precise definitions in ISO 26262 Part 1 form the common language that every OEM, Tier-1 supplier, semiconductor vendor, safety assessor, and tool provider must speak fluently.

By the end of this article, you will understand every foundational term in the ISO 26262 vocabulary, know the critical distinctions between commonly confused concepts like fault versus error versus failure, and be equipped with a practical reference glossary that you can return to throughout your functional safety career. Let us dive in.

1. What is ISO 26262 Part 1 and Why Does It Matter?

ISO 26262 Part 1: Vocabulary is the foundational part of the entire ISO 26262 standard series. It serves as the project glossary, providing precisely defined terms, definitions, and abbreviated terms that are referenced and applied across all 12 parts of the standard. This part was expanded in the 2018 second edition to accommodate the broader scope of the updated standard, which now covers trucks, buses, trailers, motorcycles, and semiconductors in addition to passenger cars.

In a domain where ambiguity can have life-or-death consequences, Part 1 ensures that when an engineer in Germany writes a safety requirement using the term “failure mode,” and a supplier in Japan implements that requirement, and an assessor in the United States audits the implementation – all three parties understand the term in exactly the same way. This consistency is not academic; it is operationally essential for the global automotive supply chain.

Why Engineers Often Underestimate Part 1

Many engineers skip Part 1 and jump directly to the “technical” parts – Part 4 (System Level), Part 5 (Hardware), or Part 6 (Software). This is a mistake. Without a solid understanding of the vocabulary, engineers frequently confuse terms like “fault” and “failure” (which have very specific and different meanings in ISO 26262), misapply concepts like “safe state” versus “degraded mode,” incorrectly classify faults during FMEDA analysis, or miscommunicate safety requirements in Development Interface Agreements (DIAs) with suppliers. Taking the time to master Part 1 pays dividends throughout every other part of the standard.

How Part 1 is Structured

Part 1 organizes its definitions alphabetically and assigns each term a reference number (e.g., 3.54 for “fault,” 3.50 for “failure”). Each definition includes the term name, the formal definition, and often one or more notes that provide additional context, clarification, or examples. Some terms also include references to the specific clauses in other parts where they are primarily used. The 2018 edition contains over 170 defined terms and numerous abbreviated terms – we will cover the most critical ones in this article, organized by thematic categories for easier learning.

2. The Fault → Error → Failure Chain – The Most Important Concept

If you learn only one thing from the entire ISO 26262 Part 1 vocabulary, let it be the fault-error-failure chain. This causal chain is the conceptual backbone of the entire functional safety framework. Every safety analysis method, every safety mechanism, and every hardware metric in the standard relates back to this fundamental sequence.

Fault (Definition 3.54)

A fault is an abnormal condition that can cause an element or an item to fail. A fault is the root cause – the underlying defect or abnormality that exists within a system component. A fault may exist without immediately causing any observable problem. It sits dormant, waiting for conditions that cause it to manifest.

Think of a fault like a crack in a bridge support beam. The crack exists (it is the fault), but the bridge may still carry normal traffic loads without any visible issue. The fault is present, but it has not yet caused the bridge to behave incorrectly.

Real Automotive Example: A transistor in the gate driver circuit of an electric power steering (EPS) ECU develops a microscopic defect due to electromigration after years of operation. The transistor still functions within its specifications under normal conditions, but the defect (fault) is present and could cause the transistor to fail under certain temperature or load conditions.

ISO 26262 recognizes two fundamental categories of faults. Systematic faults are caused by errors in the design, specification, manufacturing process, or documentation. They are deterministic – given the same conditions, the same fault will always manifest. Examples include a software logic error, a misunderstood specification, or a PCB layout error. Systematic faults are addressed through rigorous development processes, reviews, and analyses. Random hardware faults are caused by physical degradation mechanisms in hardware components (such as electromigration, time-dependent dielectric breakdown, or cosmic ray-induced soft errors). They are probabilistic – they occur unpredictably based on failure rate distributions. Random hardware faults are addressed through safety mechanisms and architectural redundancy.

Error (Definition 3.43)

An error is a discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. An error arises as a result of a fault manifesting within the system or component.

Continuing our bridge analogy: when a heavy truck crosses the bridge, the cracked beam (the fault) deflects more than it should (the error). The beam is bending beyond its specified tolerance – the deviation between the actual deflection and the correct deflection is the error.

Real Automotive Example: The defective transistor in our EPS ECU is subjected to a high ambient temperature during a hot summer drive. Under this thermal stress, the transistor’s on-resistance increases beyond its specified limit, causing the gate driver to produce an output voltage that is 0.8V lower than the intended value. This voltage deviation is the error – a measurable discrepancy between the actual output and the correct output.

A crucial point: an error can be detected by a safety mechanism (such as a voltage monitoring circuit) or it can go undetected and propagate further through the system. The ability to detect errors before they cause failures is the fundamental purpose of diagnostic safety mechanisms in ISO 26262.

Failure (Definition 3.50)

A failure is the termination of the ability of an element or an item to perform a required function. A failure occurs when an error propagates to the point where the system can no longer deliver its intended functionality. The termination can be permanent (the function is lost indefinitely) or transient (the function is lost temporarily and may recover).

In our bridge analogy: under continued heavy loading, the cracked beam (fault) that was deflecting excessively (error) finally breaks completely (failure). The bridge can no longer carry traffic – its required function has been terminated.

Real Automotive Example: The reduced gate driver voltage (error) in our EPS ECU causes the power MOSFET to operate in a partially conducting state instead of fully switching on. This results in the electric power steering motor receiving insufficient current, and the driver experiences a sudden, significant increase in steering effort at highway speed. The EPS system has failed — it can no longer perform its required function of providing power-assisted steering.

The Complete Chain in Summary

The chain flows in one direction: Fault → Error → Failure. A fault is an abnormal condition that can cause a problem. When a fault manifests under certain conditions, it produces an error – a detectable deviation from correct behavior. If the error is not detected and mitigated by a safety mechanism, it propagates and eventually causes a failure – the loss of the intended function. If that failure results in a hazardous situation at the vehicle level, it becomes a malfunction that threatens functional safety.

Understanding this chain is essential because the entire ISO 26262 approach to safety is built around breaking this chain at different points: preventing faults through rigorous development processes (addressing systematic faults), detecting errors through safety mechanisms before they cause failures (diagnostic coverage), tolerating failures through redundant architectures (fault tolerance), and transitioning to safe states when failures cannot be prevented (fail-safe design).

Failure Mode (Definition 3.51)

Closely related to failure is the concept of failure mode, which is defined as the manner in which an element or an item fails to provide the intended behaviour. While “failure” tells us that something stopped working, “failure mode” tells us how it stopped working. For a temperature sensor, possible failure modes might include “stuck high” (always reports maximum temperature), “stuck low” (always reports minimum temperature), “drift” (reports gradually increasing error), or “erratic” (reports random values). Identifying and classifying failure modes is a fundamental step in FMEA and FMEDA analyses under Parts 4 and 5 of the standard.

Malfunction (Definition 3.90) and Malfunctioning Behaviour (Definition 3.91)

A malfunction is defined as the failure or unintended behaviour of an item with respect to its design intent. Malfunctioning behaviour takes this a step further – it is the failure or unintended behaviour of an item with respect to its design intent that constitutes a hazard. The key distinction is that a malfunction becomes a concern for functional safety when it creates a hazardous condition at the vehicle level. Not every failure is hazardous – for example, the failure of the interior ambient lighting system is a malfunction but typically does not constitute malfunctioning behaviour from a functional safety perspective because it does not create a hazard.

3. Core Safety Terminology – The Foundation

Beyond the fault-error-failure chain, ISO 26262 Part 1 defines several foundational terms that form the conceptual pillars of the entire standard. Every engineer working with ISO 26262 must internalize these definitions.

Functional Safety (Definition 3.67)

Functional safety is defined as the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of electrical and electronic (E/E) systems. This is the central concept of the entire standard. Notice the precision of this definition: it concerns itself specifically with risk arising from malfunctions (not intended behavior), and specifically with E/E systems (not purely mechanical or hydraulic systems, unless their behavior is controlled by E/E systems). The term “unreasonable risk” acknowledges that zero risk is impossible – the goal is to reduce risk to a level that is acceptable given societal expectations and the state of technology.

Item (Definition 3.84)

An item is a system or array of systems to implement a function at the vehicle level, to which ISO 26262 is applied. This is one of the most important terms in the standard because the item is the starting point for the entire safety lifecycle. Everything begins with the item definition – the description of the item’s boundaries, interfaces, functions, and operational context. For example, an “electric power steering system” is an item. An “adaptive cruise control system” is an item. The item is the highest-level object to which the safety lifecycle is applied, and all hazard analysis is performed at the item level.

Element (Definition 3.41)

An element is defined as a system, component (hardware or software), hardware part, or software unit. It is a general term used throughout the standard to refer to any constituent part of the item hierarchy at any level of abstraction. When “software element” or “hardware element” is used, it denotes an element within the software or hardware domain respectively. The term is deliberately broad to allow flexibility in how organizations structure their system hierarchies.

Component (Definition 3.21)

A component is a non-system level element that is logically and technically separable and comprises more than one hardware part or one or more software units. A component is larger than a part but smaller than a system. For example, a microcontroller is a component (it contains multiple hardware parts like CPU, memory, peripherals). A software driver module is a software component.

Hardware Part (Definition 3.71)

A hardware part is the lowest level of hardware that cannot be further subdivided. Examples include a resistor, a capacitor, a transistor, a specific flash memory array within a microcontroller, or the CPU core of a microcontroller. Hardware parts are the level at which failure rates are assigned in FMEDA analysis.

Hardware Sub-Part

A hardware sub-part is a portion of a hardware part that can be logically divided and represents the second or greater level of decomposition below a hardware part. For example, if a CPU of a microcontroller is a hardware part, then the ALU (Arithmetic Logic Unit) within that CPU is a hardware sub-part. This level of decomposition is particularly relevant for semiconductor analysis under Part 11.

System (Definition 3.163)

A system is a set of elements (at minimum a sensor, a controller, and an actuator) that relates at least a sensor or an input to an actuator or an output using a control algorithm. A system typically includes sensors that detect the state of the environment or the vehicle, a processing unit (controller) that runs control algorithms, and actuators that influence the physical world based on the controller’s decisions. Communication paths between these elements are also part of the system.

Hazard (Definition 3.75)

A hazard is a potential source of harm (physical injury or damage to the health of persons) caused by malfunctioning behaviour of the item. This definition is restricted to the scope of ISO 26262 – in general safety engineering, “hazard” has a broader meaning. Within ISO 26262, a hazard is always linked to a malfunction of the item under analysis. For example, “unintended acceleration” is a hazard caused by the malfunctioning behaviour of the engine management system.

Hazardous Event (Definition 3.77)

A hazardous event is a combination of a hazard and an operational situation. This is the level at which ASIL classification is performed. A hazard alone does not determine the risk level – the risk depends on the driving situation in which the hazard occurs. “Unintended acceleration” on an empty parking lot at 5 km/h is very different from “unintended acceleration” on a crowded highway at 120 km/h. The hazardous event combines the hazard with the specific operational scenario to create a complete risk picture.

Harm (Definition 3.73)

Harm is defined as physical injury or damage to the health of persons. ISO 26262 is fundamentally concerned with protecting people – vehicle occupants, pedestrians, cyclists, and other road users. Property damage is not directly within the scope of the standard’s risk classification, although it may be considered indirectly.

Risk (Definition 3.128)

Risk is the combination of the probability of occurrence of harm and the severity of that harm. This is a standard definition in risk management and forms the basis for the ASIL classification system – where severity, exposure (which relates to probability of the hazardous situation), and controllability (which relates to the probability that the harm can be avoided) are the three parameters used to evaluate risk.

Residual Risk (Definition 3.127)

Residual risk is the risk remaining after safety measures have been deployed. ISO 26262 does not claim to eliminate all risk — it aims to reduce risk to an acceptable level. The residual risk is what remains after all safety goals have been implemented through safety mechanisms, safety architectures, and verified development processes.

Safe State (Definition 3.131)

A safe state is an operating mode, in case of a failure, of an item without an unreasonable level of risk. When a safety-critical system detects a failure that cannot be tolerated, it must transition to a safe state. The safe state is defined during the concept phase as part of the functional safety concept. For some systems, the safe state is “system off” – for example, if the electric window lift control fails, the safe state might be to stop the motor. For other systems, the safe state might be a degraded operating mode – for example, an EPS system might switch to a reduced-assist mode rather than completely shutting off, because a sudden loss of all steering assist at highway speed could itself be hazardous.

Fault Tolerant Time Interval – FTTI (Definition 3.62)

The Fault Tolerant Time Interval (FTTI) is the minimum time span from the occurrence of a fault in an item to a possible occurrence of a hazardous event, if the safety mechanisms are not activated. FTTI is a critical timing parameter in functional safety design. It defines the time budget that safety mechanisms have to detect a fault, diagnose it, and either correct it or transition the system to a safe state before the fault can lead to a hazardous situation at the vehicle level. Safety mechanisms must have a diagnostic test interval and response time that are significantly shorter than the FTTI. For example, if the FTTI for an EPS failure is 100 milliseconds (the time from fault occurrence to potential loss of steering control), then the diagnostic safety mechanism must detect the fault and activate the safe state within a fraction of that time – typically within 10–50 milliseconds.

4. ASIL and Risk Classification Terminology

ASIL – Automotive Safety Integrity Level (Definition 3.6)

The Automotive Safety Integrity Level (ASIL) is one of four levels (A, B, C, D) that specifies the item’s or element’s necessary safety requirements for achieving an acceptable residual risk. ASIL D represents the most stringent requirements (highest integrity), and ASIL A represents the least stringent (lowest integrity). Additionally, QM (Quality Management) represents the case where no ISO 26262 safety requirements apply, and standard quality processes are sufficient.

A common mistake in the industry is using the phrase “ASIL level” – since ASIL already stands for “Automotive Safety Integrity Level,” saying “ASIL level” translates to “Automotive Safety Integrity Level level,” which is redundant. The correct usage is simply “ASIL D” or “an ASIL of D.”

Severity (Definition 3.152)

Severity is an estimate of the extent of harm to an individual that can potentially result from a hazardous event. Severity is classified into four levels: S0 (no injuries), S1 (light and moderate injuries), S2 (severe and life-threatening injuries, with survival probable), and S3 (life-threatening injuries with survival uncertain, or fatal injuries).

Exposure (Definition 3.48)

Exposure is the state of being in an operational situation that can be hazardous if coincident with the failure mode under analysis. It is classified into five levels: E0 (incredible – the situation essentially never occurs), E1 (very low probability), E2 (low probability), E3 (medium probability), and E4 (high probability – the situation is encountered frequently in everyday driving).

Controllability (Definition 3.25)

Controllability is the ability to avoid a specified harm or damage through the timely reactions of the persons involved (typically the driver, but also other road users). It is classified into four levels: C0 (controllable in general – almost everyone can handle it), C1 (simply controllable – more than 99% of drivers can typically manage it), C2 (normally controllable – most drivers can manage it, but some may not), and C3 (difficult to control or uncontrollable – even skilled drivers may be unable to prevent the harmful outcome).

Safety Goal (Definition 3.139)

A safety goal is a top-level safety requirement for the item, resulting from the hazard analysis and risk assessment, expressed as a condition or behaviour to be maintained or avoided. Safety goals inherit the ASIL of the hazardous event they address. For example: “The EPS system shall prevent unintended steering torque application” [ASIL D]. Safety goals are always expressed at the vehicle level and describe what must be achieved, not how it should be implemented.

Safety Requirement (Definition 3.140)

A safety requirement is a requirement that, by being implemented, contributes to the achievement of a safety goal. Safety requirements exist at multiple levels of the hierarchy – functional safety requirements (abstract, architectural), technical safety requirements (system level), hardware safety requirements, and software safety requirements. Every safety requirement must trace back to a safety goal.

5. Safety Requirements Hierarchy Terminology

Functional Safety Concept (Definition 3.65)

The functional safety concept specifies the functional safety requirements, with associated information necessary for defining the technical safety concept, including the preliminary architectural design, the assignment of functional safety requirements to elements of this preliminary architectural design, and the definition of the operating modes and safe states. It is developed during the concept phase (Part 3) and sits between the safety goals and the technical safety concept.

Technical Safety Concept (Definition 3.166)

The technical safety concept specifies the technical safety requirements and describes the implementation of the functional safety requirements in the system architectural design. It is developed during system-level product development (Part 4) and translates the abstract functional safety requirements into concrete technical requirements that can be allocated to hardware and software.

Functional Safety Requirement (Definition 3.66)

A functional safety requirement is a specification of implementation-independent safety behaviour or implementation-independent safety measure, including its safety-related attributes. These requirements describe what the safety function must do in terms of behaviour, without specifying the hardware or software implementation details.

Technical Safety Requirement (Definition 3.167)

A technical safety requirement is a requirement for the implementation of a functional safety requirement. Technical safety requirements are allocated to specific system elements – hardware components, software modules, or communication interfaces — and define the concrete, measurable requirements that each element must satisfy.

6. Fault Classification Terminology

ISO 26262 has an elaborate and precise vocabulary for classifying different types of faults. Understanding these classifications is essential for performing FMEDA analysis, calculating hardware architectural metrics, and designing effective safety mechanisms.

Safe Fault

A safe fault is a fault whose occurrence will not significantly increase the probability of violation of a safety goal. Safe faults are essentially benign from a functional safety perspective – they do not affect safety-related functions. For example, a fault in a hardware register that is only used for non-safety-related diagnostic logging would be classified as a safe fault.

Single-Point Fault (Definition 3.156)

A single-point fault is a fault in an element that is not covered by a safety mechanism and that leads directly to the violation of a safety goal. Single-point faults are the most dangerous category because there is no defensive layer between the fault and the safety goal violation. The entire philosophy of safety architecture design in ISO 26262 is fundamentally about eliminating or minimizing single-point faults, particularly for higher ASIL levels.

Residual Fault

A residual fault is the portion of a fault that, by itself, leads to the violation of a safety goal, occurring in a hardware element where that portion of the fault is not covered by safety mechanisms. If a safety mechanism provides 90% diagnostic coverage for a particular failure mode, the remaining 10% that escapes detection constitutes the residual fault.

Multiple-Point Fault (Definition 3.97)

A multiple-point fault is an individual fault that, in combination with other independent faults, leads to a multiple-point failure. Unlike single-point faults, multiple-point faults require two or more independent faults to coincide before a safety goal violation occurs. This provides an additional layer of protection, since the probability of two independent faults occurring simultaneously is much lower than the probability of a single fault.

Dual-Point Fault (Definition 3.38)

A dual-point fault is an individual fault that, in combination with another independent fault, leads to a dual-point failure. A dual-point fault is a specific case of a multiple-point fault where exactly two faults must combine. The standard pays special attention to dual-point faults because they are the most likely category of multiple-point faults to actually occur.

Latent Fault (Definition 3.85)

A latent fault is a multiple-point fault whose presence is not detected by a safety mechanism nor perceived by the driver within the multiple-point fault detection interval. Latent faults are particularly dangerous because they silently degrade the system’s safety capability without anyone knowing. If a latent fault exists in a safety mechanism (say, a monitoring circuit has failed undetected), and then a separate fault occurs in the main safety-related element, the combination can lead to a safety goal violation that was supposed to be prevented. This is why ISO 26262 requires the Latent Fault Metric (LFM) to ensure that latent faults are adequately detected.

Detected Fault

A detected fault (specifically, a detected multiple-point fault) is a multiple-point fault that is detected, within a prescribed time, by a safety mechanism. This detection prevents the fault from remaining latent and allows the system to take corrective action — either by compensating for the fault or by transitioning to a safe state before a second fault can combine with it.

Perceived Fault

A perceived fault (specifically, a perceived multiple-point fault) is a multiple-point fault whose presence is perceived by the driver within a prescribed time interval. For example, if a warning indicator illuminates on the dashboard informing the driver that a safety mechanism has degraded, the underlying fault is considered “perceived” – the driver is now aware and can take appropriate action (such as visiting a service centre promptly).

Systematic Fault (Definition 3.164)

A systematic fault is a fault in the development or manufacturing process that results in a systematic failure. Systematic faults are deterministic — they are built into the product through design errors, specification errors, or manufacturing process deficiencies. They are not addressed through probabilistic hardware metrics but through process rigour – reviews, analyses, testing, and the application of development methods prescribed by the standard for each ASIL level.

Random Hardware Failure (Definition 3.120)

A random hardware failure is a failure that can occur unpredictably during the lifetime of a hardware element and that follows a probability distribution. These failures are caused by physical degradation mechanisms and are addressed through safety mechanisms, diagnostic coverage, and architectural redundancy. The hardware architectural metrics (SPFM, LFM) and the probabilistic metric (PMHF) are specifically designed to evaluate the system’s robustness against random hardware failures.

7. Hardware Metrics and Quantitative Terminology

Part 1 defines several terms that are central to the quantitative hardware safety evaluation required by Part 5. Understanding these terms is critical for hardware engineers and safety analysts.

Hardware Architectural Metrics (Definition 3.70)

Hardware architectural metrics are metrics for the assessment of the effectiveness of the hardware architecture with respect to safety. The two hardware architectural metrics in ISO 26262 are the Single-Point Fault Metric (SPFM) and the Latent Fault Metric (LFM).

Single-Point Fault Metric – SPFM

The Single-Point Fault Metric (SPFM) reflects the robustness of the item’s hardware architecture against single-point and residual faults. A high SPFM value means that the proportion of faults that can directly violate a safety goal without being detected or mitigated is very low. Target values are: not defined for ASIL A, ≥90% for ASIL B, ≥97% for ASIL C, and ≥99% for ASIL D.

Latent Fault Metric – LFM

The Latent Fault Metric (LFM) reflects the robustness of the item’s hardware architecture against latent faults. A high LFM value means that faults in safety mechanisms and redundant elements are effectively detected, preventing them from remaining hidden. Target values are: not defined for ASIL A, ≥60% for ASIL B, ≥80% for ASIL C, and ≥90% for ASIL D.

Probabilistic Metric for random Hardware Failures – PMHF

The PMHF is a quantitative evaluation of whether the residual risk of safety goal violations due to random hardware failures is sufficiently low. Unlike SPFM and LFM (which are relative metrics expressed as percentages), PMHF is an absolute metric expressed as a probability per hour of operation. Target values are: no target for ASIL A, <10⁻⁷/h for ASIL B, <10⁻⁷/h for ASIL C, and <10⁻⁸/h for ASIL D.

Diagnostic Coverage (Definition 3.32)

Diagnostic coverage is the proportion of the failure rate of a failure mode of a hardware element that is detected or controlled by the implemented safety mechanism. It is expressed as a percentage and classified into categories: Low (≥60%), Medium (≥90%), and High (≥99%). Diagnostic coverage is a fundamental input to FMEDA analysis and the calculation of SPFM and LFM.

Diagnostic Test Interval

The diagnostic test interval is the amount of time between the executions of online diagnostic tests by a safety mechanism. The diagnostic test interval must be shorter than the FTTI to ensure that faults are detected before they can lead to hazardous events.

Failure Rate (Definition 3.53)

The failure rate is the probability density of failure divided by the probability of survival for a hardware element. It is assumed to be constant over the device’s operational lifetime and is typically denoted by the symbol λ (lambda). Failure rates are usually expressed in units of FIT (Failures In Time), where 1 FIT = 1 failure per 10⁹ device-hours of operation.

Failure Mode Coverage – FMC

Failure mode coverage is the proportion of the failure rate of a failure mode of a hardware element that is detected or controlled by the implemented safety mechanism. This is essentially the same concept as diagnostic coverage but specified at the failure mode level rather than the overall element level.

8. Development Process Terminology

Safety Mechanism (Definition 3.142)

A safety mechanism is a technical solution implemented by E/E functions or elements, or by other technologies, to detect faults or control failures in order to achieve or maintain a safe state. Safety mechanisms are the active defensive measures in a safety architecture. Examples include watchdog timers, redundant sensor readings with cross-comparison, memory ECC (Error Correcting Code), plausibility checks on sensor data, and lockstep CPU configurations.

Safety Element out of Context – SEooC (Definition 3.143)

A Safety Element out of Context is a safety-related element that is not developed in the context of a specific item. Instead, it is developed based on assumptions about the safety requirements and operating conditions it will encounter when integrated into a final item. The OEM or integrator must validate these assumptions during integration. SEooC is essential for the multi-tier automotive supply chain, where semiconductor vendors and software suppliers develop components without knowing the specific vehicle they will be used in.

Item Development (Definition 3.83)

Item development is the complete process of implementing an item, from the concept phase through to production readiness, including all phases of the safety lifecycle.

Proven in Use Argument (Definition 3.119)

A proven in use argument provides evidence, based on field experience, that an element fulfils the safety requirements and can be reused. If a component has extensive, documented field operation history with no safety-related failures, this history can be used to argue for its safety suitability without repeating the full ISO 26262 development process from scratch. Specific conditions and documentation requirements must be met.

Distributed Development (Definition 3.35)

Distributed development is the development of an item or element with development responsibility divided between the customer and one or more suppliers. A Development Interface Agreement (DIA) is used to define the responsibilities, deliverables, and interfaces between the cooperating parties.

Development Interface Agreement – DIA

A Development Interface Agreement is an agreement between customer and supplier that specifies the shared responsibilities for safety activities in distributed development. The DIA defines who is responsible for what, which work products must be exchanged, and how safety requirements flow between the parties.

Confirmation Measure (Definition 3.23)

Confirmation measures are measures to ensure the correctness, completeness, and consistency of the safety activities and their work products. The three types of confirmation measures are: confirmation reviews, functional safety audits, and functional safety assessments. The required independence of the person performing the confirmation measure depends on the ASIL level.

9. Safety Management and Confirmation Terminology

Safety Culture (Definition 3.133)

Safety culture is the enduring set of values, attitudes, motivations, and knowledge of an organization in which safety is prioritized. ISO 26262 recognizes that tools, processes, and documents alone are insufficient – the people in the organization must genuinely value safety, and this value must be embedded in the organizational culture.

Safety Case (Definition 3.130)

A safety case is an argument that the safety requirements for an item are complete and satisfied by evidence compiled from the work products of the safety activities during development. The safety case is the definitive compilation of all safety evidence that demonstrates the item meets its safety goals.

Safety Plan (Definition 3.138)

A safety plan is a plan to manage and guide the safety activities, including dates, milestones, tasks, deliverables, and responsibilities. The safety plan ensures that functional safety activities are properly planned, resourced, and tracked throughout the development lifecycle.

Functional Safety Assessment (Definition 3.63)

A functional safety assessment is an examination of whether the functional safety achieved by the item, performed by a person or persons with sufficient levels of independence, complies with ISO 26262. This is the highest level of confirmation measure and is typically performed by a qualified external assessor or an internal assessor with sufficient organizational independence.

Functional Safety Audit (Definition 3.64)

A functional safety audit is an examination of an implemented process with respect to the planned process. While an assessment evaluates the product’s safety, an audit evaluates whether the development processes were followed correctly.

Work Product (Definition 3.179)

A work product is a documentation result of a safety activity. ISO 26262 defines specific work products for every safety activity across all parts of the standard — including requirements specifications, analysis reports, test reports, design documents, and review records. Maintaining complete and traceable work products is essential for demonstrating compliance.

10. Analysis and Verification Terminology

Verification (Definition 3.175)

Verification is the assurance that a work product of a particular phase of the safety lifecycle fulfils the requirements of the previous phase, through evidence obtained from analysis, testing, or expert judgement. In simple terms, verification answers the question: “Did we build the product right?”

Validation (Definition 3.173)

Validation is the assurance that the safety goals are sufficient and have been achieved. Validation answers a different question: “Did we build the right product?” Validation is typically performed at the vehicle level to confirm that the safety goals are met in the real operational environment.

HARA – Hazard Analysis and Risk Assessment (Definition 3.76)

HARA is the method used to identify and categorize hazardous events of items and to specify safety goals and ASILs related to the prevention or mitigation of the associated hazards. HARA is performed during the concept phase (Part 3) and is the entry point for the entire safety-driven development process.

FMEA – Failure Mode and Effect Analysis

FMEA is a systematic, bottom-up (inductive) analysis method that identifies potential failure modes of components, traces their effects through the system hierarchy, and evaluates their impact on safety goals. FMEA is widely used during system-level and hardware-level development in ISO 26262.

FTA – Fault Tree Analysis

FTA is a top-down (deductive) analysis method that starts with an undesired top-level event (such as a safety goal violation) and traces backward through the system to identify all possible combinations of lower-level faults that could cause it. FTA uses Boolean logic gates (AND, OR) to model fault propagation paths.

FMEDA – Failure Mode Effects and Diagnostic Analysis

FMEDA extends traditional FMEA by including the evaluation of diagnostic coverage provided by safety mechanisms for each identified failure mode. FMEDA is the primary analysis method for calculating hardware architectural metrics (SPFM and LFM) and is defined in detail in Part 5 of the standard.

Dependent Failure Analysis – DFA

Dependent failure analysis addresses failures that are not statistically independent. DFA examines three types of dependent failures: common cause failures (a single root cause triggers faults in multiple elements), cascading failures (the failure of one element causes the failure of another), and common mode failures (different elements fail in the same manner due to a common external influence). DFA is critical for validating architectural independence, especially in the context of ASIL decomposition.

11. Architecture and Design Terminology

ASIL Decomposition (Definition 3.5)

ASIL decomposition is the apportioning of redundant safety requirements to elements, with sufficient independence, conducive to the same safety goal, with the objective of reducing the ASIL of the redundant safety requirements that are allocated to the corresponding elements. For example, an ASIL D safety requirement can be decomposed into two ASIL B(D) requirements allocated to sufficiently independent elements. The notation “(D)” indicates the original ASIL from which the decomposition was derived.

Freedom from Interference (Definition 3.61)

Freedom from interference is the absence of cascading failures between two or more elements that could lead to the violation of a safety requirement or a safety goal. This concept is crucial when elements with different ASIL levels coexist on the same hardware platform (such as mixed-ASIL software partitions on a single microcontroller). The higher-ASIL element must be protected from interference by lower-ASIL or QM elements.

Fault Tolerance (Definition 3.60)

Fault tolerance is the ability to deliver a specified functionality in the presence of one or more specified faults. A fault-tolerant system continues to operate correctly even when certain faults occur. This is typically achieved through redundancy — if one element fails, another independent element can continue to provide the function.

Redundancy

While not defined as a single term in Part 1, the concept of redundancy pervades the standard. Homogeneous redundancy uses multiple but identical implementations of the same requirement (same hardware, same software). Diverse redundancy (diversity) uses different solutions satisfying the same requirement to achieve independence. Diversity is generally preferred for higher ASIL levels because it addresses certain types of common cause failures that homogeneous redundancy cannot.

Intended Functionality (Definition 3.82)

Intended functionality is the behaviour specified for an item, system, or element, excluding safety mechanisms. This is the “normal operation” behavior — what the system is designed to do when everything is working correctly. The distinction between intended functionality (covered by SOTIF ISO 21448) and safety mechanisms (covered by ISO 26262) is important for understanding the boundary between the two standards.

Operational Situation (Definition 3.104)

An operational situation is a scenario that can occur during the life of a vehicle. Operational situations are combined with hazards during HARA to form hazardous events. Examples include “driving at highway speed in heavy rain,” “parking in a tight space at low speed,” or “starting the vehicle on an incline.”

12. Complete List of ISO 26262 Abbreviations

The following table provides a comprehensive reference of the most commonly used abbreviations throughout the ISO 26262 standard. Bookmark this section — you will refer to it frequently.

Abbreviation	Full Form	Primary Part(s)
ASIL	Automotive Safety Integrity Level	Part 3, 9
DFA	Dependent Failure Analysis	Part 9
DIA	Development Interface Agreement	Part 8
E/E	Electrical and/or Electronic	All Parts
ECU	Electronic Control Unit	All Parts
FMEA	Failure Mode and Effect Analysis	Part 4, 5
FMEDA	Failure Mode Effects and Diagnostic Analysis	Part 5
FTA	Fault Tree Analysis	Part 4, 5, 9
FTTI	Fault Tolerant Time Interval	Part 3, 4, 5
FuSa	Functional Safety	All Parts
HARA	Hazard Analysis and Risk Assessment	Part 3
HSR	Hardware Safety Requirement	Part 5
LFM	Latent Fault Metric	Part 5
MC/DC	Modified Condition/Decision Coverage	Part 6
OEM	Original Equipment Manufacturer	All Parts
PMHF	Probabilistic Metric for random Hardware Failures	Part 5
QM	Quality Management	Part 3, 9
SEooC	Safety Element out of Context	Part 10
SoC	System on Chip	Part 11
SOTIF	Safety of the Intended Functionality (ISO 21448)	Complementary
SPFM	Single-Point Fault Metric	Part 5
SSR	Software Safety Requirement	Part 6
TCL	Tool Confidence Level	Part 8
TSC	Technical Safety Concept	Part 4
TSR	Technical Safety Requirement	Part 4

13. ISO 26262 vs IEC 61508 Terminology Comparison

Since ISO 26262 is derived from IEC 61508, many engineers transitioning from other industries (process, railway, medical) need to understand how familiar terms map to the automotive vocabulary. The following comparison covers the most commonly encountered differences.

SIL (Safety Integrity Level) in IEC 61508 maps conceptually to ASIL (Automotive Safety Integrity Level) in ISO 26262, although the calculation methodology is different. SIL uses quantitative probability of failure targets, while ASIL uses a qualitative assessment of severity, exposure, and controllability.

Safe Failure Fraction (SFF) from IEC 61508 does not have a direct equivalent in ISO 26262. Instead, ISO 26262 uses SPFM (Single-Point Fault Metric) and LFM (Latent Fault Metric), which evaluate the hardware architecture’s effectiveness from different perspectives.

Hardware Fault Tolerance (HFT) from IEC 61508 is conceptually present in ISO 26262 through the concept of fault tolerance, but ISO 26262 does not mandate specific HFT levels as a function of ASIL. Instead, it uses the metric-based approach (SPFM, LFM, PMHF) to evaluate hardware safety.

Process Safety Time from IEC 61508 maps roughly to Fault Tolerant Time Interval (FTTI) in ISO 26262 — both represent the time available from fault occurrence to potential hazardous event.

Safety Instrumented System (SIS) from IEC 61508 does not have a direct automotive equivalent, but the concept of a safety mechanism in ISO 26262 serves a similar purpose — a dedicated function that detects faults or controls failures to maintain safety.

The addition of the Controllability parameter in ASIL determination is unique to ISO 26262 and has no equivalent in IEC 61508’s SIL determination. This reflects the automotive-specific reality that a human driver can often intervene to prevent an accident, at least in current non-autonomous vehicles.

14. Common Terminology Mistakes and How to Avoid Them

Based on years of industry experience, certain terminology mistakes recur frequently in ISO 26262 projects. Being aware of these common pitfalls will help you communicate more precisely and avoid errors in safety analysis.

Mistake 1: Using “fault” and “failure” interchangeably. These are fundamentally different concepts. A fault is an abnormal condition (the cause); a failure is the loss of function (the effect). A fault can exist without causing a failure, and a failure is always the result of one or more faults. Using them interchangeably in requirements, FMEA reports, or safety analyses creates dangerous ambiguity.

Mistake 2: Saying “ASIL level.” Since ASIL stands for “Automotive Safety Integrity Level,” saying “ASIL level” is redundant — it means “Automotive Safety Integrity Level level.” The correct form is “ASIL D” or “an ASIL of D,” not “ASIL level D.”

Mistake 3: Confusing “safe state” with “system off.” The safe state is not always “turn everything off.” For many safety-critical systems, abruptly turning off can itself be hazardous. The safe state must be specifically defined for each item based on its vehicle-level function and the operational context. For EPS, the safe state might be “reduced assist mode” rather than “no assist at all.”

Mistake 4: Conflating “safety mechanism” with “safety function.” A safety function is the overall function that achieves or maintains a safe state. A safety mechanism is the specific technical solution (hardware circuit, software routine, or algorithm) that detects faults or controls failures. Multiple safety mechanisms may be needed to implement a single safety function.

Mistake 5: Thinking HARA classifies components. HARA classifies hazardous events at the vehicle level, not individual components. The ASIL is assigned to the hazardous event and inherited by the safety goal. It then propagates to elements through the safety requirements hierarchy. An individual component does not inherently “have” an ASIL – it inherits the ASIL of the safety requirement allocated to it.

Mistake 6: Assuming “proven in use” means “it has been in production for years.” Proven in use requires formal, documented evidence of field operation under comparable conditions, with adequate failure data collection and analysis. Simply having a product in the field for many years, without formal tracking of safety-relevant failures and operating conditions, does not satisfy the proven in use requirements.

Mistake 7: Confusing ISO 26262 scope with SOTIF scope. ISO 26262 addresses hazards caused by malfunctions (the system breaking). SOTIF (ISO 21448) addresses hazards caused by limitations of the intended functionality (the system working correctly but encountering scenarios it was not designed for). A camera failing to detect a pedestrian because the camera hardware is faulty is an ISO 26262 issue. A camera failing to detect a pedestrian in heavy fog because the algorithm was not designed for that visibility condition is a SOTIF issue.

15. Frequently Asked Questions

Q1: Is ISO 26262 Part 1 normative or informative?

Part 1 is a normative part of the standard. The definitions it provides are binding and must be used consistently throughout all work products, analyses, and documentation produced under the ISO 26262 framework.

Q2: How many terms are defined in ISO 26262 Part 1?

The 2018 second edition of Part 1 defines over 170 terms and numerous abbreviations. This is an expansion from the first edition (2011), which had fewer terms due to the narrower scope of the original standard.

Q3: Can I use different terminology in my safety documentation as long as the meaning is the same?

It is strongly recommended to use the exact ISO 26262 terminology in all safety work products. Assessors, auditors, and customers expect standard terminology. Using alternative terms — even if you believe they are equivalent – creates opportunities for misinterpretation and can be flagged as a non-conformity during assessment.

Q4: What is the difference between an “element” and a “component” in ISO 26262?

“Element” is the broadest term – it can refer to any part of the item hierarchy, from a complete system down to a software unit or hardware part. “Component” is more specific – it refers to a non-system-level element that is logically and technically separable, comprising more than one hardware part or one or more software units. In practice, “element” is the safe, general-purpose term when you are not sure of the exact level.

Q5: Why does ISO 26262 distinguish between “detected,” “perceived,” and “latent” faults?

Because the effectiveness of the safety architecture depends on how quickly faults are identified. A detected fault (automatically found by a safety mechanism) can be immediately addressed. A perceived fault (noticed by the driver through warnings or symptoms) relies on human response, which is slower and less reliable. A latent fault (undetected by either mechanism or driver) is the most dangerous because it silently degrades safety until a second fault occurs. The hardware metrics (SPFM, LFM) are designed to minimize and control these different fault categories.

Q6: Is the FTTI (Fault Tolerant Time Interval) defined in Part 1 or Part 5?

FTTI is defined in Part 1 (Vocabulary) and its application is primarily discussed in Parts 3, 4, and 5. The definition in Part 1 provides the formal meaning, while the other parts describe how to determine, use, and verify FTTI values in practice.

16. Conclusion

The ISO 26262 Part 1 vocabulary is far more than a dry glossary – it is the shared language that makes the entire functional safety framework operational across the global automotive industry. Every term we have covered in this article – from the foundational fault-error-failure chain to the precise definitions of ASIL, FTTI, SPFM, LFM, and PMHF – carries specific, carefully crafted meaning that you must understand and apply correctly in your daily engineering work.

Mastering this vocabulary is the first and most important step in your ISO 26262 journey. With these definitions internalized, you will be equipped to engage with every subsequent part of the standard with clarity and confidence – whether you are performing HARA (Part 3), designing safety architectures (Part 4), calculating hardware metrics (Part 5), implementing safety-critical software (Part 6), or developing semiconductors for automotive applications (Part 11).

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. Be sure to explore the main hub page for the complete list of deep-dive posts covering every part and topic of the standard. Next up in our series: ISO 26262 Part 2 – Management of Functional Safety, where we will explore the organizational and project-level requirements that ensure functional safety is not just a technical exercise but an embedded organizational capability.

Bookmark this vocabulary reference, share it with your team, and come back to it whenever you need to clarify a term. At PiEmbSysTech, we believe that clear communication is the foundation of safe engineering.

Stay safe. Stay precise. Keep engineering the future.

— The PiEmbSysTech Team

Discover more from PiEmbSysTech - Embedded Systems & VLSI Lab

Subscribe to get the latest posts sent to your email.