Short, focused videos mapping the practical ISO 26262 workflow — from item definition and HARA to tool qualification and safety mechanisms — onto the qualified Simulink toolchain.
⬇ Download Free TrialFree Trial · All Features · No Credit Card
Safety standards feel abstract until you see them land in a real model. Each short video takes one ISO 26262 concept — item definition, HARA, ASIL, tool qualification, diagnostic coverage — and shows where it belongs in your Simulink workflow. Made for function developers, verification engineers and safety managers. New to the modeling tools? Start with MATLAB, Simulink and Stateflow.
The Item Definition is the prerequisite for hazard analysis and describes, at the vehicle level, how the functionality is intended to work. It details the item’s interactions with the driver, with the surrounding environment, and with other relevant items in the vehicle. It draws on existing product presentations, drawings and specifications, in a form similar to a patent application. Without an adequate understanding of the item, the analysis of malfunctions, failure modes and hazards cannot be performed reliably.
During Hazard Analysis we systematically identify the hazardous events that can occur at the vehicle level. We describe all operational situations and operating modes relevant for the item, then all possible malfunctions of the item, assuming no internal safety mechanisms are present. By combining these operating conditions with the possible functional failures, we determine how each malfunction can compromise safety, and produce a structured list of hazards and their related malfunctions for further assessment.
Risk is defined in ISO 26262 as a combination of the probability of exposure to a hazardous situation and the severity of the resulting harm. In some situations the risk can be reduced by the driver’s ability to avoid it (controllability). Each identified hazard is classified by Severity, Exposure and Controllability, and this classification determines an Automotive Safety Integrity Level (ASIL). For every hazardous event with an ASIL above QM, a top-level safety goal is derived at the vehicle level.
SOTIF — Safety Of The Intended Functionality (ISO 21448) — addresses hazards that arise not from failures, but from the limitations and unintended behavior of a correctly implemented function. This is especially relevant for sensing, perception and driver-assistance functions, where the system may misinterpret a situation it was never designed to handle. SOTIF complements ISO 26262 by focusing on performance limitations, foreseeable misuse and the boundaries of the operational design domain.
The Safety Plan organizes all the activities, work products and responsibilities required to achieve functional safety for the item. It defines the safety lifecycle, schedules the required verification and validation steps, and assigns roles for each phase of development. It references the safety case in which evidence is progressively collected, and establishes the tailoring of activities according to the ASIL. A well-structured safety plan keeps the development traceable, auditable and aligned with ISO 26262 from the start.
Confirmation measures provide independent assurance that functional safety has actually been achieved. ISO 26262 defines three types: confirmation reviews, functional safety audits and the functional safety assessment. Each is performed with a level of independence that increases with the ASIL, so that higher-risk items receive more rigorous scrutiny. The purpose is to confirm that the safety activities were carried out correctly, that the work products are complete, and that the resulting safety argument is sound.
Independence is a central principle in ISO 26262: the person or team checking a work product must be sufficiently separate from the person or team that created it. The required degree of independence — from a different person, to a different team, to a different organizational unit (I1, I2, I3) — increases with the ASIL. This separation reduces the chance that the same blind spot which produced an error also lets it pass review, and it underpins confirmation measures and safety assessments.
The Functional Safety Concept derives functional safety requirements from the safety goals and allocates them to the preliminary architecture. It specifies the safety mechanisms needed to detect faults, transition the system to a safe state, tolerate faults, or warn the driver, together with the fault-tolerant time interval within which the system must react. Each functional safety requirement inherits the ASIL of its safety goal and is traceable back to it, forming the bridge to the technical safety concept.
The Verification Plan defines how each work product and requirement will be checked, and provides the evidence that the item satisfies its safety requirements. It specifies the verification methods — reviews, analyses, simulation and testing — along with the pass/fail criteria and the required level of independence for each. Planning verification early ensures that requirements are written to be testable, that coverage is complete, and that the resulting evidence can be assembled directly into the safety case.
Software tools used in a safety-related development may themselves introduce or fail to detect errors. ISO 26262 Part 8 Clause 11 requires each tool to be evaluated for its Tool Impact (TI) and the likelihood that its errors are detected (Tool error Detection, TD). Together these yield a Tool Confidence Level (TCL) that determines whether, and by which method, the tool must be qualified. Qualification provides documented confidence that the tool behaves correctly for its intended use in the toolchain.
Random hardware failures are quantified in ISO 26262 using the Failure In Time (FIT) rate — the number of failures expected in one billion operating hours. These rates feed the hardware safety analyses, including single-point, residual and latent fault metrics, and the probabilistic metric for random hardware failures (PMHF). The higher the ASIL, the stricter the quantitative targets. Estimating and budgeting FIT rates across components lets the architecture be dimensioned to meet the required hardware safety goals.
A cascading failure occurs when a fault in one element causes a fault in another, without the two elements being intended to influence each other. Because the failures are dependent, redundancy alone does not protect against them. ISO 26262 requires dependent-failure analysis to identify coupling factors — shared resources, interfaces, power or timing — that could propagate a single root cause across supposedly independent channels. Understanding these paths is essential before claiming freedom from interference between elements.
Redundancy improves safety by providing more than one means of performing a function, so that a fault in one channel does not lead to failure of the whole. It can be implemented in hardware, in software, or through diverse information sources. Redundancy is most effective when the channels are genuinely independent; if they share a common cause of failure, the benefit is lost. It underpins fault detection, fault tolerance and safe-state transitions, and is a common building block of technical safety concepts.
Technological diversity strengthens redundancy by making the redundant channels different in principle, not just duplicated. Using dissimilar sensor technologies, algorithms or hardware reduces the chance that a single systematic fault or environmental condition defeats all channels at once. For example, pairing a robust passive sensor with a precise active one yields a combination that is both reliable and accurate. Diversity is a key defence against common-cause and cascading failures in safety-related architectures.
Diagnostic coverage is the fraction of a component’s dangerous failures that are detected by its safety mechanisms. It is a primary lever for meeting the hardware fault metrics required by a given ASIL: the higher the coverage, the more failures are caught before they can cause harm. Coverage is evaluated for both single-point and latent faults, and depends on how thoroughly the diagnostics exercise the component. Achieving and demonstrating adequate diagnostic coverage is central to the hardware safety argument.
In an item without a safety mechanism, a fault can directly cause hazardous behavior. A safety mechanism is a technical solution that detects faults and controls them in time to maintain or reach a safe state. The interval between a fault and the resulting hazard is the fault-tolerant time interval, and the mechanism must react faster than that. Fault handling consists of fault detection followed by fault reaction — typically a transition to a safe state or a driver warning — often confirmed over several diagnostic cycles.
Static model analysis verifies the model at rest, without executing it, and is highly cost-effective because it catches modeling errors early in development. It covers the definition of modeling guidelines, the analysis and correction of the model, the handling of justified check exclusions, and the documentation of results. Static verification is a required method at every ASIL. The resulting reports provide the evidence of conformance for each guideline and deviation, which makes automated checking with a tool like EverCheck essential for practical use.
Where static analysis verifies the model at rest, dynamic model analysis verifies its behavior by executing it. It covers what ISO 26262 expects of a verification tool such as EverTest: generation of test harnesses and test cases, coverage of design ranges and requirements, back-to-back testing between model and generated code (SIL and PIL), closed-loop reactive testing, step-by-step debugging, and the verification report that provides evidence for the assessor. Together with static analysis, it forms the complete verification workflow.
See the full safe MBD workflow for software development.
Beyond the short concept videos, the course includes longer, structured chapters — each a complete lesson covering processes, guidelines, verification and architecture for ISO 26262 compliant Model-Based Design. Some chapters are password-protected; write to support@everbits.com to request access.
ISO 26262 addresses hazards caused by malfunctions of electrical and electronic systems — a sensor fails, a computation is wrong. SOTIF (Safety Of The Intended Functionality, ISO 21448) addresses hazards that occur without any failure: performance limitations and foreseeable misuse of a correctly implemented function, such as a perception system misreading a situation it was never designed for. The two standards complement each other, and driver-assistance functions typically need both.
The Automotive Safety Integrity Level classifies the risk of a hazardous event, from ASIL A (lowest) to ASIL D (highest). During hazard analysis and risk assessment each hazardous event is rated by Severity, probability of Exposure and Controllability by the driver, and the combination of the three determines the ASIL. Events without safety relevance are rated QM and handled by normal quality management. The ASIL then scales the rigor of the required development and verification activities.
ISO 26262-8 Clause 11 requires an evaluation of every software tool in the development flow: the possible Tool Impact and the probability of detecting a tool error determine the Tool Confidence Level (TCL). Tools classified TCL2 or TCL3 need qualification measures such as validation or increased confidence from use. The classification always depends on your specific use case and workflow — the same tool can be TCL1 in one process and TCL3 in another. The tool qualification article walks through the evaluation for a Simulink toolchain.
Yes — verification reviews of work products such as models require independence, starting at level I1: the reviewer must be a different person than the author. In practice the reviewer often has no MATLAB installation, which is why a self-contained model export such as EverView is a practical way to give reviewers, suppliers and assessors full access to the model hierarchy in a browser.
The short concept videos are free to watch and require no registration. The longer in-depth chapters are partly password-protected — write to support@everbits.com to request access. The course is made for function developers, verification engineers and safety managers who work with Simulink, Stateflow or TargetLink, and assumes working knowledge of the modeling tools.
Working through ISO 26262 on a real Simulink project and unsure how a concept applies? Write to us — you’ll reach an engineer, not a sales desk.
⬇ Download Free TrialFree Trial · All Features · No Credit Card
Or write to us at support@everbits.com