Structured entry point for key terms, abbreviations, and work products in functional safety. Written for engineers, project leads, and safety roles that need to place ISO 26262 terms quickly.
ASIL stands for Automotive Safety Integrity Level. It describes the required safety integrity level of a safety goal and drives the rigor expected for requirements, architecture, verification, reviews, and evidence. ASIL ranges from A to D, with ASIL D requiring the highest methodological rigor; QM means that no ISO 26262 functional safety path is continued for that case.
Read ASIL articleFunctional safety means absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical or electronic systems. In ISO 26262, the focus is therefore not every aspect of vehicle safety, but hazards that result from faulty E/E system behavior and need to be controlled by suitable safety measures.
ISO 26262 is the central standard for functional safety of electrical and electronic systems in road vehicles. It defines a safety lifecycle from the concept phase through system, hardware, and software development to production, operation, and decommissioning. The standard is risk-based and uses ASIL to determine the necessary rigor of safety activities.
An item is the function or system scope to which ISO 26262 activities are applied. It describes the vehicle function, system boundaries, interfaces, operating conditions, and assumptions under consideration. A clear item boundary is required before HARA, safety goals, and later requirements derivation can be robust.
An E/E system is an electrical or electronic system in the vehicle, for example an ECU, sensor, actuator, communication path, or software function. ISO 26262 addresses functional safety where malfunctioning behavior of such E/E systems can lead to safety-relevant hazards.
QM in ASIL classification describes a case where no further specific ISO 26262 functional safety activities are required. This does not mean that the function is irrelevant or untested. It means that conventional quality processes and standard development assurance are sufficient from the HARA perspective.
A safety goal is a top-level safety objective at item or vehicle level. It is derived from a hazardous event in the HARA and carries the corresponding ASIL. Safety goals describe which hazardous behavior must be prevented or limited without already prescribing the technical solution.
A work product is a documented result of an ISO 26262 activity, for example HARA, safety concept, safety plan, review record, or test evidence. Work products are the technical basis for reviews, audits, assessments, and the safety case. They need to be current, reviewed, and under configuration control.
Controllability describes how well an average driver or road user can control a hazardous event after it has occurred. The evaluation does not assume technical safety mechanisms. Short reaction times, high speed, or situations that are hard to perceive usually lead to a more critical classification.
Exposure describes how often or how likely a relevant operating situation occurs during normal vehicle use. It does not describe the probability of a technical fault, but the frequency of the situation in which malfunctioning behavior could become hazardous. This distinction prevents artificial risk reduction in the HARA.
HARA stands for Hazard Analysis and Risk Assessment. It identifies safety-relevant hazards, combines them with operating situations into hazardous events, and evaluates them through severity, exposure, and controllability. The output is a set of safety goals with ASIL classification.
Read HARA articleA hazardous event is the combination of a hazard, a concrete operating situation, and relevant boundary conditions. Only this combination makes a risk assessable. Example: unintended steering torque is the hazard; at high speed in dense traffic it becomes a specific hazardous event.
The item definition describes the scope for the safety activities. It contains the function, operating boundaries, assumptions, interfaces, and relevant dependencies of the item. Without a robust item definition, the HARA lacks clear boundaries and later safety goals can become ambiguous.
Severity describes the degree of possible injury if a hazardous event occurs. The evaluation focuses on harm to people, not property damage or loss of comfort. The classification ranges from no injuries to life-threatening or fatal injuries.
The functional safety concept describes how the safety goals derived from the HARA are to be fulfilled at functional level. It contains functional safety requirements and remains largely solution-neutral. It answers which safe behavior is required before that behavior is technically implemented in the TSC.
Read FSC articleA functional safety requirement refines a safety goal at functional level. It describes the required safe or degraded behavior while remaining largely technology- and architecture-neutral. FSRs are created in the functional safety concept and must trace clearly back to safety goals.
A hardware safety requirement describes safety-relevant requirements for hardware elements, such as sensors, actuators, supply, diagnostics, or monitoring. It is derived from technical safety requirements and forms the basis for hardware architecture, FMEDA, verification, and safety evidence.
A software safety requirement describes safety-relevant software behavior, for example plausibility checking, diagnostic evaluation, fault reaction, state logic, or timing behavior. It must be verifiable, ASIL-consistent, and clearly allocated to a higher-level technical safety requirement.
The technical safety concept refines functional safety requirements at system and architecture level. It contains technical safety requirements, architecture decisions, safety mechanisms, and allocation to system elements. It bridges toward hardware and software development.
Read TSC articleA technical safety requirement translates functional safety requirements into concrete technical requirements at system level. TSRs describe aspects such as architectural allocation, diagnostic mechanisms, reaction times, safe states, or interface behavior. They bridge the functional safety concept and system, hardware, and software development.
Traceability is the documented linkage between safety goals, requirements, architecture, implementation, tests, and evidence. It must work forward and backward: it should be possible to show how a safety goal is implemented and why a test or work product is safety-relevant. Without traceability, the safety case becomes difficult to assess.
Confirmation measures are independent activities used to check whether safety-relevant work products, processes, and the overall safety argument are sufficient. They include confirmation reviews, functional safety audit, and functional safety assessment. The required level of independence depends, among other factors, on the ASIL.
The development interface agreement governs safety-relevant collaboration between customer, supplier, and potentially further parties. It defines who is responsible for which safety activities, work products, evidence, assumptions, and interfaces. An effective DIA prevents gaps and duplicated assumptions in distributed development projects.
The functional safety assessment evaluates whether functional safety of the item has been sufficiently achieved. It does not only review individual documents, but the overall safety argument including safety case, work products, open points, and evidence. Depending on ASIL and project context, independent assessment is required.
The functional safety audit checks whether the applied processes and organizational measures fit ISO 26262 and have been implemented in the project. It mainly evaluates process conformity, roles, planning, reviews, and safety management activities. It does not replace the technical evaluation of the safety case.
The safety case is the structured safety argument for an item. It connects claims, arguments, and evidence and shows why safety goals are fulfilled, ASIL-classified requirements are implemented, and residual risks are acceptably controlled. It is therefore a central basis for assessment and release recommendation.
Read safety case articleThe safety plan describes which functional safety activities, roles, responsibilities, milestones, and confirmation measures are planned for the project. It is a control document for safety management and must be maintained as the project progresses. An outdated safety plan quickly creates evidence gaps.
Dependent failure analysis investigates dependent failures that can affect several supposedly independent safety mechanisms at the same time. This includes common causes, cascading effects, or shared resources. DFA is especially important when architecture concepts rely on redundancy, independence, or ASIL decomposition.
FMEA is a systematic bottom-up analysis of possible failure modes and their effects. It helps identify weaknesses in components, functions, or processes and derive suitable measures. In ISO 26262, it supports evaluation of systematic and technical fault paths.
FMEDA extends FMEA with quantitative information such as failure rates, diagnostic coverage, and safety metrics. It is primarily used for hardware safety evidence to evaluate random hardware faults and diagnostic effectiveness. Its results typically feed hardware metrics and the safety case.
FTA is a top-down analysis that starts from an undesired top event and logically decomposes possible causes. It is useful for understanding combinations of faults that can lead to a safety-critical event. It complements bottom-up methods such as FMEA or FMEDA.
A release recommendation is a technical recommendation from a functional safety perspective. It is based on the safety case, open points, verification and validation results, and confirmation measures. It does not replace a management decision, but provides the safety-related basis for it.
Residual risk is the risk that remains after all safety measures have been implemented. In ISO 26262 projects, it must be shown that this residual risk is acceptable and that no unreasonable safety risk remains. The safety case makes this argument traceable.
A safety anomaly is a safety-relevant deviation, finding, or open issue that must be assessed and controlled. It can arise from tests, reviews, analyses, or field observations. The impact, risk, decision, and closure must be documented in a traceable way.
Start of production marks the transition into series production. From a functional safety perspective, the relevant safety activities should be completed, open points assessed, and the safety case sufficiently robust before SOP. SOP is therefore an important reference point for assessment and release recommendation.