Safety First

Zachary Paul Lukasiewicz

Learn about the world of functional safety.

  1. 7h ago

    Functional Safety versus Safety of the Intended Function (ISO 26262-11 Explained)

    Two standards walk into a semiconductor design meeting. One defines how to make chips safe when they fail—whether through systematic design flaws or random hardware faults in the field. That's functional safety, the domain of ISO twenty-six-two-sixty-two Part eleven: Guidelines on application of ISO twenty-six-two-sixty-two to semiconductors. Part of the Critical Systems Analysis functional-safety series on ISO 26262-11. In this episode: ISO twenty-six-two-sixty-two Part eleven is the semiconductor-specific application guide for functional safety.Functional safety in semiconductors rests on three pillars.Now contrast that with SOTIF—Safety of the Intended Function.The distinction is fundamental to understanding semiconductor safety.Imagine a neural-network accelerator chip designed for automotive perception: it computes inference results flawlessly, with all safety mechanisms functioning exactly as specified.Both standards are necessary because they address different risk mechanisms.Reference: ISO 26262-11 is officially 'Guidelines on application of ISO 26262 to semiconductors'; it extends functional-safety concepts to semiconductor-specific failure modes (systematic and More in this series: ASIL, HARA and the ISO 26262 Safety Lifecycle | Automotive Functional Safety for Engineers | ISO 26262 — Automotive Functional Safety | ISO 26262 for Safety Managers | ISO 26262 Hardware Metrics (SPFM, LFM, PMHF) | Semiconductor Functional Safety (ISO 26262-11) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    Functional Safety versus Safety of the Intended Function (ISO 26262-11 Explained)

  2. 15h ago

    ISO 26262 Revisited: Safety Analyses — FMEA, FTA, and FMEDA

    If you're building a safety-critical system, you must prove it can fail safely. That proof lies in ISO 26262, and specifically in Part 9, Clause 8: Safety Analyses. This episode dives into the three foundational methods—FMEA, FTA, and FMEDA—that turn abstract safety concepts into concrete, verifiable evidence that your hardware can withstand random failures and meet your safety integrity level targets. The standard makes a critical distinction: two directions of analysis. Inductive analysis starts at a component failure and traces upward to its effects—this is the domain of Failure Mode and Effects Analysis (FMEA), which excels at breadth and exhaustive coverage. Deductive analysis reverses the flow: start at the hazard and dig down to root causes—this is Fault Tree Analysis (FTA), which catches combinations of faults and single points of failure that inductive methods miss. Neither alone is sufficient; a rigorous safety analysis uses both to achieve comprehensive hazard analysis and risk assessment. In this episode: Inductive analysis (FMEA) traces upward from a component failure to its system effect and whether it violates a safety goal, giving you exhaustive, bottom-up coverage of single failures.Deductive analysis (FTA) works top-down from a hazard, using logic gates (OR and AND) to expose combinations of faults and single points of failure that lack redundancy protection.FMEDA adds quantitative rigor by applying failure rates, diagnostic coverage percentages, and strict fault classification, rolling the result into the hardware architectural metrics that Part 5 of ISO 26262 demands.The Single-Point Fault Metric (SPFM) and Latent Fault Metric (LFM) climb with ASIL level: SPFM targets 90% for ASIL B, 97% for C, and 99% for D; LFM targets 60%, 80%, and 90% respectively.The Probabilistic Metric for Hardware Failures (PMHF) caps dangerous random-hardware failures: below 100 FIT for ASIL B and C, below 10 FIT for ASIL D, but these metrics never govern systematic failures like bugs or specification errors.Master the direction of each tool—inductive for breadth, deductive for combinations, FMEDA for metrics—and verification and validation stops being paperwork and becomes proof.This episode covers ISO 26262-9:2018, Part 9, Clause 8, "Safety Analyses," which establishes the inductive and deductive framework for safety analysis methods and their quantitative integration into hardware architectural metrics. If you're an engineer or manager certifying safety-critical systems in automotive, industrial, medical, or rail—any domain where random hardware failure cascades to harm—follow "Critical Systems Analysis" for the complete functional safety series on ISO 26262, from requirements through certification. Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    ISO 26262 Revisited: Safety Analyses — FMEA, FTA, and FMEDA

  3. 15h ago

    ISO 26262 Revisited: Safety Analyses — FMEA, FTA, and FMEDA

    So we have zoomed all the way in. Out of the whole ISO twenty-six two-six-two lifecycle, we land on Part nine, Clause eight, titled Safety analyses. This is the clause where the standard stops asking, in the abstract, what could go wrong, and hands you actual methods to prove how your system fails. And its first move is to split the world in two. Part of the Critical Systems Analysis functional-safety series on ISO 26262. In this episode: Here is the clause we are living in for the next few minutes: Part nine, Clause eight, Safety analyses.First the vocabulary, because in functional safety the vocabulary is normative.Line the two directions up.Watch F M E A run.Now flip the direction.Third tool, and the one people constantly confuse with the first: F M E D A, Failure Modes, Effects, and Diagnostic Analysis.Reference: ISO 26262-9:2018, Clause 8 is titled 'Safety analyses' and frames the distinction between inductive (bottom-up) and deductive (top-down) analysis methods; this is the correct ancho More in this series: ASIL, HARA and the ISO 26262 Safety Lifecycle | Automotive Functional Safety for Engineers | ISO 26262 — Automotive Functional Safety | ISO 26262 for Safety Managers | ISO 26262 Hardware Metrics (SPFM, LFM, PMHF) | Semiconductor Functional Safety (ISO 26262-11) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    ISO 26262 Revisited: Safety Analyses — FMEA, FTA, and FMEDA

  4. 23h ago

    ISO 26262: Transitioning to a Safe State

    When a fault appears in a safety-critical system, your design cannot shrug. ISO 26262 demands a deliberate, defined response: transitioning to a safe state before the fault cascades into harm. This episode unpacks the exact mechanism that separates a controlled degradation from a catastrophic failure. In functional safety, a safe state is not a feeling. It is a specific operating mode of your item—defined, reachable, and stable—that keeps residual risk at an acceptable level. Whether that means switching the function off entirely, shifting to degraded operation, handing control back to the driver with a warning, or switching to a redundant channel, the principle is identical: you must land there before the fault tolerant time interval expires. That interval is your entire budget. It spans from the instant a fault occurs to the moment a hazardous event could begin—measured as if no safety mechanism acts at all. Within that window, your diagnostic must detect the fault, and your safety mechanism must react and reach the safe state. Miss the deadline, and the fault progression continues unchecked. The reaction splits into two carefully managed pieces. Detection time is driven by how frequently you run your diagnostic test. Reaction time flows from the moment of detection to actually being in the safe state. Add those together, and the sum is what must fit the interval. This is not estimation; it is engineered precision. But what happens when you cannot stop instantly? Killing power to brakes or steering mid-corner creates a worse hazard, not a safer one. ISO 26262 allows emergency operation: a limited-time bridge mode that keeps the item usable when a true safe state is not immediately reachable. But emergency operation is a loan, not a destination. The system still must transition to a defined safe state before the emergency interval expires. In this episode: Understand the exact definition of a safe state and why it must be designed, not assumed.Learn how the fault tolerant time interval sets your budget and how detection plus reaction must fit inside it.Discover the four concrete forms a safe state can take and when each is appropriate for your function.Explore emergency operation as a time-limited bridge mode when safe states cannot be reached instantly.Apply the four-point checklist that validates any transition to a safe state in your design.See how the same fault leads to either catastrophic failure or controlled risk depending on whether you designed a place to land.This episode covers the foundational concept of safe-state definition, fault tolerant time intervals, emergency operation modes, and the diagnostic-plus-reaction framework that is central to ISO 26262-1:2018 functional safety vocabulary and technical safety concept development. If you design, manage, or verify safety-critical systems in automotive, industrial, or cyber-physical domains, follow Critical Systems Analysis for the complete exploration of ISO 26262 across all safety lifecycle phases. Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    ISO 26262: Transitioning to a Safe State

  5. 23h ago

    ISO 26262: Transitioning to a Safe State

    So let's zoom all the way in on one clause: transitioning to a safe state. In ISO twenty-six two sixty-two, a safe state is not a vibe, and it is not a feeling that things are probably fine. It is a defined operating mode of your item, one without an unreasonable level of risk. So when a fault shows up, your system does not get to shrug. Part of the Critical Systems Analysis functional-safety series on ISO 26262. In this episode: Start with the exact clause in scope: transitioning to a safe state.Here is why any of this matters.So how much time do you actually have? The standard gives you a name for it: the fault tolerant time interval.Now the path you actually want.That budget splits into two pieces, and you have to spend both wisely.So what does a safe state actually look like? It depends on the function.Reference: No clause or section numbers are cited anywhere in the script; all references are described conceptually to avoid inventing numbering. If on-screen citations are wanted, confirm ag More in this series: ASIL, HARA and the ISO 26262 Safety Lifecycle | Automotive Functional Safety for Engineers | ISO 26262 — Automotive Functional Safety | ISO 26262 for Safety Managers | ISO 26262 Hardware Metrics (SPFM, LFM, PMHF) | Semiconductor Safety — FMEDA and Metrics Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    ISO 26262: Transitioning to a Safe State

  6. 1d ago

    ISO 26262 in Practice: Where Each Applies

    When you're building safety-critical systems—autonomous vehicles, industrial robots, medical devices—you need to prove that the system won't hurt someone. That's where functional safety comes in. But there's a trap that catches teams over and over: you can run the entire ISO 26262 safety lifecycle, close every safety goal, and still ship a real hazard. This episode unpacks why, and introduces the complementary standard that catches what ISO 26262 misses. ISO 26262 defines functional safety as the absence of unreasonable risk from malfunctioning behavior of electrical and electronic systems. That definition is precise: it owns the hazards that come from failures—from something breaking or going wrong. But what about the hazards that show up when nothing breaks? When the sensor is healthy, the software runs exactly as designed, and the function is simply not good enough for the situation? That's the territory of SOTIF—Safety Of The Intended Functionality, published as ISO 21448. The distinction is clean: Did something malfunction? If yes, you're in ISO 26262. If no, everything worked as intended but the risk is still real, you're in SOTIF. A lidar on your bumper that stops working due to a power short is an ISO 26262 fault. A lidar that's perfectly healthy but can't detect matte black paint or gets washed out by road spray is a SOTIF insufficiency. Same sensor, two completely different safety questions. In this episode: Functional safety means proving the absence of unreasonable risk, but ISO 26262 owns only the risk from malfunctioning behavior—a distinction that catches teams running the full lifecycle and still missing hazards.ISO 21448, known as SOTIF, covers the hazards that show up when nothing is broken: the sensor works perfectly, the software runs as designed, and the function is simply insufficient for the situation.The two standards use radically different methods—ISO 26262 relies on failure analysis and ASIL ratings derived from severity, exposure, and controllability; SOTIF relies on scenario-based validation to hunt triggering conditions.They are complementary siblings, not rivals; a safe system needs both to close, especially anything that senses and interprets the real world.The real organizational risk hides in the seam between teams—degraded-but-not-failed cases, hybrid scenarios, and ambiguous ownership can cause a hazard to slip through unowned.Drawing the boundary before you build—and writing down who owns the hybrid cases—is the single most effective practice to avoid shipping a gap in the safety argument.This episode references the scope and definition of functional safety as foundational to ISO 26262 and Part 1 vocabulary, and explores how SOTIF (ISO 21448) explicitly addresses its complement: hazards from functional insufficiency where no fault or malfunction is present. If you're an engineer or manager building safety-critical systems—especially in automotive, robotics, or medical devices—follow Critical Systems Analysis for the full series on these standards, and learn how to integrate functional safety with real-world validation to ship systems that won't hurt anyone. Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    ISO 26262 in Practice: Where Each Applies

  7. 1d ago

    ISO 26262 in Practice: Where Each Applies

    Now zoom all the way into the one line that starts this whole standard: the scope, at the very front of ISO two six two six two. It defines functional safety as the absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical and electronic systems. Read that slowly, because that sentence is doing two jobs at once. Part of the Critical Systems Analysis functional-safety series on ISO 26262. In this episode: Let's start where the standard itself starts, that scope line defining functional safety as the absence of unreasonable risk from malfunctioning behavior of electrical and electronic systems.So let's re-anchor what this standard actually owns.Now meet the sibling standard that catches the shadow-braking case: ISO two one four four eight, known as SOTIF, Safety Of The Intended Functionality.Here's the cleanest way to tell them apart, and it comes down to one question.Let's make that boundary physical.SOTIF hands you a mental map for this.Reference: No specific clause or sub-clause numbers are cited anywhere, by design. References to 'the scope' and 'the definition of functional safety' are conceptual; functional safety is def More in this series: ASIL, HARA and the ISO 26262 Safety Lifecycle | Automotive Functional Safety for Engineers | ISO 26262 — Automotive Functional Safety | ISO 26262 for Safety Managers | ISO 26262 Hardware Metrics (SPFM, LFM, PMHF) | Semiconductor Safety — FMEDA and Metrics Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    ISO 26262 in Practice: Where Each Applies

  8. 1d ago

    Safety Culture in Practice — An ISO 26262 Deep Dive

    What happens when safety collides with cost, schedule, and ego? Most engineers think ISO 26262 is a technical standard about fault trees, test results, and verification methods. But Part 2 of the standard—Management of Functional Safety—asks a different question entirely: how does your organization actually behave when no one is auditing? This episode zooms into the part of ISO 26262 that most people miss. Safety culture isn't a poster in the break room or a checkbox in a compliance database. It's the shared values and behaviors that decide whether your team raises the uncomfortable concern or buries it. Whether bad news travels to leadership or dies two levels down. In ISO 26262-2, culture is positioned at the very front of overall safety management—upstream of every requirement, every test, every design review. The standard's bet is simple: if the organization doesn't genuinely value safety, no amount of process will save you. In this episode: Safety culture is defined not as attitude but as shared behaviors: what your team does when nobody is watching, measured against whether safety wins or loses when it conflicts with cost and schedule.ISO 26262 places safety culture at the beginning of overall safety management, before any technical requirement is written, because organizational behavior is upstream of all verification and validation work.Named accountability at the organization and project level—including a dedicated safety manager role—transforms an invisible culture into something auditable, documented, and traceable.The safety plan becomes the spine of functional safety: every activity listed with an owner, timing, and a required work product that feeds into the safety case as evidence of achievement.Confirmation measures scale to risk: at higher ASIL levels, independent confirmation review, functional safety audit, and functional safety assessment by departments or external organizations ensure no internal bias obscures whether safety integrity has actually been met.Development Interface Agreements across organizational boundaries eliminate silent responsibility gaps by explicitly assigning who owns which safety activities, work products, and confirmation roles when multiple companies share the development.If you design, verify, or manage safety-critical systems in automotive or other functional safety domains, follow the Critical Systems Analysis series for the complete technical and governance framework that makes ISO 26262 practical. Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    Safety Culture in Practice — An ISO 26262 Deep Dive
See All (99)

About

Learn about the world of functional safety.

Information

  • Creator
    Zachary Paul Lukasiewicz
  • Years Active
    2026
  • Episodes
    99
  • Rating
    Clean
  • Copyright
    © Zachary Paul Lukasiewicz
  • Show Website
    Safety First