Safety First

Critical Systems Analysis
Critical Systems Analysis
  • 0.0 (0)
  • Technology

Learn about the world of functional safety.

  1. 5h ago

    UL 4600 Fault Models: The UL 4600 Perspective

    So let's zoom all the way in. Past the safety case, past the risk assessment, down to one quiet demand that UL forty-six hundred makes of you: name your faults. Remember, this standard isn't a checklist. It's built as a safety case — a structured argument that your autonomous product is acceptably safe, held up by claims, reasoning, and evidence. Part of the Critical Systems Analysis functional-safety series on UL 4600. In this episode: First, the term.Now picture your development as a row of gates.So here's the split.Watch what that does to your favorite fix.Every standard in this family leans on one lever: rigor.Reference: UL 4600 (ANSI/UL 4600, Standard for Safety for the Evaluation of Autonomous Products, first published 2020) is a claims-based safety-case standard. It deliberately does NOT prescri More in this series: ADAS and Autonomous Driving Safety | SOTIF (ISO 21448) — Safety of the Intended Functionality | Safety of Autonomous Vehicles (SOTIF and UL 4600) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    UL 4600 Fault Models: The UL 4600 Perspective

  2. 13h ago

    UL 4600 in Practice: Fault Model Sample Database

    Alright, movement four. We're zooming all the way in now, past the lifecycle, past the safety case as a whole, down to one specific demand U-L forty-six hundred makes of you: build a fault model. Not a hand-wavy list of things that might go wrong, but a structured, maintained model of the ways your autonomous product can fail. And here's the part people skate over. Part of the Critical Systems Analysis functional-safety series on UL 4600. In this episode: Picture your test suite as a row of gates.So let's separate the two ways things actually break.And that last line is the whole ballgame.So if you can't buy safety with a number, how do you earn it? You climb.Which brings us to the bespoke piece for this standard, the fault model, and the thing that feeds it.Reference: UL 4600 deliberately avoids prescriptive integrity levels (no SIL/ASIL-style tiers); safety is established through the credibility of the safety-case argument and its evidence. The More in this series: ADAS and Autonomous Driving Safety | SOTIF (ISO 21448) — Safety of the Intended Functionality | Safety of Autonomous Vehicles (SOTIF and UL 4600) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    UL 4600 in Practice: Fault Model Sample Database

  3. 21h ago

    Fault Model : Sensors (UL 4600 Explained)

    So let's drop all the way down into one clause of U L forty-six hundred: the fault model. U L forty-six hundred doesn't just ask, "is your autonomous product safe?" It asks you to prove it, in writing, with a safety case. And a safety case is only as honest as its list of the things that can go wrong. That list is the fault model. Part of the Critical Systems Analysis functional-safety series on UL 4600. In this episode: Fault model, sensors.Every autonomous product runs the same loop: sense the world, decide what to do, then act on it.U L forty-six hundred requires a fault model: a deliberate, written-out account of the ways each sensor can fail.So how do sensors really fail? They get blocked or blinded, by mud, by fog, by sun straight into the lens.Now the universal move.The dangerous and undetected failure.Reference: UL 4600's full title is the Standard for Safety for the Evaluation of Autonomous Products (first edition 2020, revised editions since). It is a safety-case-based standard: it requi More in this series: ADAS and Autonomous Driving Safety | SOTIF (ISO 21448) — Safety of the Intended Functionality | Safety of Autonomous Vehicles (SOTIF and UL 4600) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    Fault Model : Sensors (UL 4600 Explained)

  4. 1d ago

    Operational Design Domain ODD Description | UL 4600

    So let's zoom all the way in. Past the safety case, past the top-level claims, down to one of the load-bearing pieces the whole argument rests on: the operational design domain description. In U L forty-six hundred, before you are allowed to argue that your autonomous product is safe, you have to state exactly where and when it is supposed to work. That statement is the ODD. Part of the Critical Systems Analysis functional-safety series on UL 4600. In this episode: This is the operational design domain description.Start with the definition.Here is the failure this clause is guarding against.Now place this in the lifecycle.So what makes a description strong enough to build on.This is the part people get wrong.Reference: No specific UL 4600 clause or section numbers are cited anywhere in the script, because I am not certain of the exact numbering in the current edition. UL 4600 organizes its conten More in this series: ADAS and Autonomous Driving Safety | SOTIF (ISO 21448) — Safety of the Intended Functionality | Safety of Autonomous Vehicles (SOTIF and UL 4600) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    Operational Design Domain ODD Description | UL 4600

  5. 1d ago

    What UL 4600 Says About Operational Design Domain ODD Requirements

    So far we've mapped the whole U L forty-six hundred lifecycle from a distance. Now zoom all the way in on one clause — the one that draws a line around where your autonomous product is even allowed to operate. This is the Operational Design Domain, the O D D. Part of the Critical Systems Analysis functional-safety series on UL 4600. In this episode: U L forty-six hundred, and today's clause: the Operational Design Domain requirements.First, the term itself.So draw the box.Where does this sit in the process? Define the O D D first, then run your hazard analysis, then build the safety case argument, then monitor the field.Now name what can go wrong — the insufficiency this clause exists to catch.So how risky is any given out-of-domain condition? Here's the move that runs through this whole pack: risk is not one number.Reference: Clause number intentionally not cited. UL 4600 (Standard for Safety for the Evaluation of Autonomous Products) addresses the Operational Design Domain, but I did not want to invent More in this series: ADAS and Autonomous Driving Safety | SOTIF (ISO 21448) — Safety of the Intended Functionality | Safety of Autonomous Vehicles (SOTIF and UL 4600) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

  6. 1d ago

    Understanding Operational Design Domain ODD Changes Under UL 4600

    We just walked the whole UL forty-six hundred lifecycle. Now zoom all the way in, past the safety case, past the hazard log, down to one line that quietly decides whether your autonomous product is still safe tomorrow: the operational design domain, and what happens the day you change it. Because in UL forty-six hundred the O-D-D is not paperwork you write once. Part of the Critical Systems Analysis functional-safety series on UL 4600. In this episode: Standard: UL forty-six hundred, the standard for the evaluation of autonomous products.First, the term, because everything hangs on it.So here is what this part of UL forty-six hundred is really about.Watch how that turns into harm.Where does this sit in the UL forty-six hundred flow? You are past initial hazard analysis and past your first safety case.Now the core move.Reference: UL 4600 is a safety-case standard (claims, arguments, evidence) and is technology-neutral. It does NOT prescribe a severity-times-exposure-times-controllability table or ASIL-style More in this series: ADAS and Autonomous Driving Safety | SOTIF (ISO 21448) — Safety of the Intended Functionality | Safety of Autonomous Vehicles (SOTIF and UL 4600) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    Understanding Operational Design Domain ODD Changes Under UL 4600

  7. 2d ago

    Back to Basics — Operational Design Domain ODD Violations in UL 4600

    So let's zoom all the way in. Past the whole U L forty-six hundred lifecycle, down to one idea that quietly sinks more autonomous programs than almost anything else: the operational design domain, and what your product owes you the instant it reaches the edge of that domain. Every self-driving system is only ever designed to work in a specific slice of the world. Part of the Critical Systems Analysis functional-safety series on UL 4600. In this episode: This is the part of U L forty-six hundred that governs the operational design domain, your O D D, and the O D D violation.Start with the boundary itself.Now the hazard, and it's subtle.So let's name it precisely, because the name changes how you treat it.Here's what makes autonomy different, and it's the whole reason this standard exists.Which brings us to the core move of every video in this pack.Reference: Clause and section numbers were deliberately NOT cited. Before publishing, verify the exact UL 4600 clause references for the operational design domain, for the required detection More in this series: ADAS and Autonomous Driving Safety | SOTIF (ISO 21448) — Safety of the Intended Functionality | Safety of Autonomous Vehicles (SOTIF and UL 4600) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    Back to Basics — Operational Design Domain ODD Violations in UL 4600

  8. 2d ago

    UL 4600 in Practice: Operational Design Domain Environmental Aspects

    Okay — let's drop all the way down. Past the safety case, past that whole lifecycle map we just walked, into the single clause that decides whether your autonomous product is even allowed outside: the Operational Design Domain, and the environmental slice of it in particular. Remember, UL forty-six hundred is a safety-case standard. Part of the Critical Systems Analysis functional-safety series on UL 4600. In this episode: Here's the clause we're living in for the next few minutes: the Operational Design Domain, environmental aspects.Start with the domain itself.Zoom into just the environmental corner of that promise and you get an envelope.Now, why does UL forty-six hundred sweat the weather this hard? Because environmental conditions are the classic trigger for what it calls an insufficiency — a place where your system is doing exactly what it was built to do, and it is still not enough.So where does this sit in the work? In your safety case, environmental aspects show up as a chain: first you define the domain, then you enumerate every environmental condition inside it, then you hunt for the insufficiencies each one can trigger, then you assess how risky each is, and finally you argue that risk down to acceptable.Here's the move most people miss.Reference: Exact clause/section number in UL 4600 for the Operational Design Domain and its environmental aspects was not verified; the video describes the concept and never cites a clause nu More in this series: ADAS and Autonomous Driving Safety | SOTIF (ISO 21448) — Safety of the Intended Functionality | Safety of Autonomous Vehicles (SOTIF and UL 4600) Explore more from Critical Systems Analysis. Partner with usFollow on LinkedInVisit our websiteRead our feature on Automate.org

    UL 4600 in Practice: Operational Design Domain Environmental Aspects
See All (184)

About

Learn about the world of functional safety.

Information

More From Critical Systems Analysis