Skip to content
Sign in
Artwork for IEC 61508 — Functional Safety Foundations
Technology

IEC 61508 — Functional Safety Foundations

Zachary Lukasiewicz

"IEC 61508 — Functional Safety Foundations" is a serial video course from CSA, published weekly in strict curriculum order — building from foundational terms and structure through lifecycle practice to advanced, assessor-level topics. Designed for working functional-safety engineers and managers, not beginners or students.

CSA is a functional safety, reliability, and certification consultancy serving robotics, autonomous systems, transportation, and industrial equipment manufacturers. CSA provides end-to-end safety engineering services: preliminary gap analyses and safety audits, SIL/PL determination, FMEA and FMEDA execution, fault tree analysis, safety case development, hardware metrics (SPFM/LFM/PMHF), lifecycle documentation, and embedded safety engineering support. CSA engineers work alongside product teams from architecture through final functional safety assessment, and support companies seeking NRTL, CE, ATEX, ISO 26262, and UL 4600 marks. Contact: Sales@criticalsa.com.

This series is part of the CSA Functional Safety Network — a coordinated set of weekly video courses covering IEC 61508, ISO 26262, ISO/SAE 21434, SOTIF (ISO 21448), UL 4600, IEC 62443, ISO/PAS 8800, ISO 13849, machinery safety, safety analysis methods, and more. Each show links to the others so practitioners can follow the thread that matches their project.

Play
Open in
  • 20 episodes
  • Avg 6 min
  • English

Episodes 20

NewestOldestLongest
All20Unplayed20In progress0Played0
  • S1 · E40
    August 22 · 5 min

    IEC 61508: Proof Testing and the Proof-Test Interval

    We've walked the whole safety lifecycle, from hazard analysis down to the wiring in the field. Now zoom all the way in, past the block diagrams, to a single line item in your maintenance plan: the proof test. Here's the uncomfortable truth the standard forces you to face. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Let's open the part of IEC 61508 that deals with periodic proof testing, and how that testing feeds straight into your failure-on-demand math. So what is a proof test, in the language of the standard? It's a test you run on a schedule to reveal the dangerous failures that have piled up unseen, and to bring the function back to an as-good-as-new condition. First, find the subject. Now classify how that hardware fails, using the taxonomy the whole standard runs on. Here's why proof testing exists at all. Picture the risk over time. Reference: Proof test is a defined term in IEC 61508-4 (Part 4, definitions/abbreviations). I described the concept (periodic test to reveal dangerous-undetected faults and restore the functi More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E39
    August 22 · 7 min

    IEC 61508: From SIL Target to Verified Design — Worked Example

    So far we have flown over the whole safety lifecycle. Now zoom all the way in, to the hinge that the entire standard turns on: the moment a fuzzy wish — "this has to be safe" — becomes a hard, testable number. In IEC 61508, that hinge is the Safety Integrity Level, the SIL. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Start by naming the thing everything else orbits: the Safety Integrity Level, or SIL. Move one: name what can go wrong. Here is the idea that drives the whole standard. Locate yourself in the lifecycle. Move two: risk is never one number. Move three: those separate factors map, through a lookup, to a single level. Reference: SIL target failure measures are stated correctly: low demand mode uses average probability of failure on demand (PFDavg) with SIL 2 spanning ten to the minus three up to ten to the More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E38
    August 22 · 7 min

    IEC 61508: Random vs Systematic Failures

    So far we've stayed up at the altitude of the whole safety lifecycle. Now zoom all the way in, to the single idea that the rest of IEC 61508 is built around. The standard splits every dangerous failure into two families, and it treats them in completely opposite ways. Part 4 gives you the definitions: random hardware failure, and systematic failure. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Picture your development pipeline as a row of gates: review, integration test, validation. Here's the core split. The standard is precise about that right-hand column. Now here's the line that matters, and it's the whole reason this video exists. So if you can't calculate your way out of a systematic fault, what do you do instead? You apply rigor, and you scale it. Reference: Definitions of 'random hardware failure' and 'systematic failure' live in IEC 61508-4 (definitions and abbreviations); I described the concepts and edition rather than citing speci More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E37
    August 22 · 7 min

    IEC 61508: Fault Avoidance vs Fault Control

    So far we've walked the whole safety lifecycle, cradle to grave. Now zoom all the way in on one idea that sits underneath every single phase of it. IEC 61508 fights failure two different ways at once, and it never, ever lets you blur them together. One way is keeping faults out in the first place. The other is catching faults once they're already in. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Here's the confusion this episode kills. Quick re-anchor on scope, so we're all standing in the same place. So here are the two approaches laid side by side. Now the key that unlocks the whole thing. Draw it as a two-by-two. Let's make the boundary concrete. Reference: Specific clause and annex numbers were intentionally not asserted. In IEC 61508-2 the 'techniques and measures' tables for control of failures and for avoidance of failures live in More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E36
    August 22 · 7 min

    IEC 61508: Residual Error Rate of Safe Communication

    Zoom all the way in now. Past the standards family, past the safety lifecycle, past the big hardware chapters, until you land on one quiet requirement in Part 2 of IEC 61508 : the rules for safe data communication. Here is the problem it solves. Your sensor and your logic solver almost never sit in the same box. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: IEC 61508, safe communication. Start with the loop every safety function runs: sense, decide, act. Let's define that idea. Every failure sorts into the same two-by-two this whole hardware pack uses: safe or dangerous, detected or undetected. The standard makes you enumerate the ways a message can go wrong and pair each one with a defense. That question has a name: the residual error rate, written with the Greek letter lambda. Reference: Clause location: IEC 61508-2:2010 contains the data-communication requirement (widely cited as clause 7.4.11, 'Requirements for data communication process'). The narration names it More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E35
    August 22 · 6 min

    IEC 61508: Common Cause Failures and the Beta Factor

    We've zoomed a long way down. From the whole family of safety standards, into IEC 61508 along its safety lifecycle. Now we drop into one specific, uncomfortable corner of the hardware world. Here's the setup. When one channel isn't reliable enough, you add a second one. Two channels, either can do the job, and now both have to fail before the safety function is lost. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: So let's name the clause. First, locate the hardware. Here's the promise you were sold. But there are two very different ways for that pair to die. What actually ships the same fault to both channels? Almost always something they share. So the standard gives you one number to capture all of that. Reference: The common cause failure quantification method is in IEC 61508-6:2010, Annex D (the beta-factor model with a scored checklist and conversion tables). Confirm the exact edition/anne More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E34
    August 22 · 5 min

    IEC 61508: Risk Reduction and the ALARP Principle

    You've walked the lifecycle. Now zoom all the way in on the one question every safety function exists to answer: how much is enough? IEC 61508 doesn't let you guess. It draws a line from the risk your equipment poses when nothing protects it, down to a level of risk people can actually live with. The distance between those two lines is the necessary risk reduction. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: This is IEC 61508, the standard for functional safety of electrical, electronic, and programmable electronic safety systems. Start with what can go wrong. Where are we in the work? You've already identified the hazards and estimated the risk each one carries. Here's the trap: risk is not one number. Picture two levels stacked up. How do you turn those factors into a target level? One method in Part 5 is the risk graph. Reference: ALARP is not a core normative requirement of IEC 61508; the ALARP model and the three risk regions (intolerable / tolerable-if-ALARP / broadly acceptable) are presented in the info More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E33
    August 22 · 5 min

    IEC 61508: Functional Safety Assessment (FSA)

    Movement four. We stop circling the safety lifecycle and drop the camera straight onto one clause. Open part 1 of IEC 61508 turn to clause 8. Its title is Functional Safety Assessment. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: So here is where we are standing. Start with what the phrase actually means, because it is easy to misread. It is tempting to blur assessment into verification and validation, so let us split them. The assessor works across the whole picture, not one document. Here is the move that makes clause 8 bite. Those three levels have precise meanings. Reference: IEC 61508-1:2010 Clause 8 is titled 'Functional safety assessment' (objectives in 8.1, requirements in 8.2). High confidence, but confirm exact sub-clause numbering before final re More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E32
    August 22 · 6 min

    IEC 61508: Building an IEC 61508 Compliance Plan

    Now we zoom all the way in on one clause. In IEC 61508, part 1, this is Clause 6 — the management of functional safety. People skip past it looking for the exciting engineering, but this is the clause that decides whether all that engineering is worth anything. It is the governance spine of the whole standard. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Here is the session in one frame. Start by killing the biggest myth. So what is functional safety management, plainly? It is the set of management activities that make safety actually happen and keep happening. Picture the overall safety lifecycle. Your functional safety management plan is the spine that holds all of this upright. Let us make accountability concrete, because this is where the whole pack lives. Reference: Clause 6 of IEC 61508-1 is titled 'Management of functional safety' — this is confirmed and is the correct anchor clause for a functional safety management plan. More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E31
    August 22 · 6 min

    IEC 61508: The Safety Requirements Specification (SRS)

    So far we've zoomed all the way out — the whole functional safety lifecycle of IEC 61508, from concept to decommissioning. Now zoom into one box near the front of that lifecycle: the Safety Requirements Specification. This is the hinge of the entire standard. Everything before it is analysis — figuring out what can hurt someone. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Here's the clause. Locate yourself. Start where the standard starts — with something that can go wrong. And here's the move at the heart of this whole series. Now compare two levels. That required risk reduction maps onto a ladder of four rungs — the safety integrity levels, one through four. Reference: Clause numbers were deliberately kept out of the narration (to avoid reading digits and to avoid inventing). For on-screen reference, verify against your edition: IEC 61508-1:2010 More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E30
    August 22 · 6 min

    IEC 61508: Allocating Safety Functions and SIL Targets

    So far we've floated over the whole safety lifecycle from the top. Now let's drop down into one box on that map, the moment where you stop describing hazards and start assigning responsibility for them. In IEC, six-one-five-oh-eight, that's the allocation step. You take each safety function you need, and you pin a hard integrity target onto it. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: This is Part 1, clause 7.six, overall safety requirements allocation. Here's exactly where you're standing. Start with the thing that goes wrong. Now, the standard won't let you just eyeball how risky something feels. Part 5 hands you a tool called the risk graph, and it breaks that likelihood down into real, answerable questions. Those parameters feed a lookup. Reference: Allocation is treated as IEC 61508-1, Clause 7.6 'Overall safety requirements allocation,' which follows Clause 7.4 (hazard and risk analysis) and Clause 7.5 (overall safety requir More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E29
    August 22 · 6 min

    IEC 61508: Safe Communication and the Black-Channel Approach

    Now zoom all the way in — past the standards family, past the lifecycle — into part 2 of IEC 61508, to the requirements for data communication. Here the standard asks a blunt question: what happens when your safety function has to talk across a wire, a bus, or a network it does not control? Notice what the clause does not say. It does not tell you to build a perfect network. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: This is safe communication under IEC 61508 the idea at its core: the black-channel approach. Start where the hardware lives. Here is the trick the standard plays. Contrast that with the other option — the white channel — where every switch and every cable is designed and validated to the full standard. So assume the black channel will abuse your messages. Now sort those against the universal taxonomy: safe or dangerous, detected or undetected. Reference: Requirements for safety-related data communication live in IEC 61508-2 (the hardware part). In the 2010 edition this is the data-communication requirement generally cited as clause More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E28
    August 22 · 7 min

    IEC 61508: What Trustworthy Software Requires (Part 3)

    Zoom all the way into one box on that lifecycle map — the one marked software. That's IEC 61508, part 3. Parts one and two handed you the hardware and the overall safety functions. Part 3 asks a harder question: when a safety function lives in code, what makes that code trustworthy enough to bet a life on? And it opens with an uncomfortable truth. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: So let's name it plainly. Part 3 leans on one normative definition, so let's get it exactly right. Here's the split that runs through the whole standard. If you can't quote a probability, what can you claim instead? The standard gives you systematic capability — graded from S C one up to S C four. This is the heart of part 3, and it's drawn as a V. The V is the same shape at every safety integrity level — but how hard you push on each step is not. Reference: IEC 61508-3 is the part covering software requirements; the software safety lifecycle is genuinely depicted as a V-model in Part 3, with development phases on the descending arm an More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E27
    August 22 · 7 min

    IEC 61508-3: Software Requirements and Architecture

    Now zoom all the way in. This is IEC 61508, part 3, the software part of the family. And the box we are standing in is software architecture design, clause 7.four point three. The phase above just handed you two things. First, a software safety requirements specification: what the software must actually do to keep the system safe. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Start by finding yourself on the map. This is the input that descended onto your desk. So how hard must this software not fail? That is what the SIL answers. Before you draw a single module, draw a boundary. Now lay out the safety function as software, the sense, process, act skeleton. Here is the move that turns a top level requirement into engineering. Reference: Clause 7.4.3 'Software architecture design' is the correct location in IEC 61508-3:2010; exact sub-clause numbers (e.g. 7.4.3.x) were not cited to avoid inventing them and should b More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E26
    August 22 · 6 min

    IEC 61508: Hardware Fault Tolerance (HFT), Explained

    So far we've stood back and looked at the whole safety lifecycle. Now zoom all the way in, down to Part 2 of the standard, clause 7.four point four, the architectural constraints on hardware safety integrity. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Welcome inside clause 7.four point four. First, locate the thing we're measuring. Part 4 of the standard defines it cleanly. Now classify how that hardware fails, because not all failures are equal. Here's what actually moves the number: redundancy. Hardware fault tolerance never travels alone. Reference: Clause references: architectural constraints on hardware safety integrity are in IEC 61508-2:2010, clause 7.4.4. Route 1H and Route 2H are its sub-clauses (Route 1H the safe-failur More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E25
    August 22 · 6 min

    IEC 61508: Systematic Capability and Route 1S/2S/3S

    So the lifecycle tells you what to do and when. Now zoom all the way in on one question it keeps asking: when an element's worst failures were never random to begin with, how do you earn the right to trust it? That question lives in part 2 of the standard, eye ee cee 61508, inside the requirements for the avoidance and control of systematic faults. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Here is where we stop zooming out and start zooming in. Picture your quality gates: review, integration, test, sign-off. The standard splits failures by where they come from. So when you quote a target failure measure, whether it is average probability of failure on demand or dangerous failures per hour, be honest about its border. If you cannot measure systematic integrity, you have to build it in, and then prove how hard you tried. That name is systematic capability, defined in part 4 of the standard, rated from one to four. Reference: Routes 1S, 2S, and 3S are specified in IEC 61508-2 (2010 edition) within the requirements for avoidance and control of systematic faults; they are commonly cited at clause 7.4.2.2. More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Work with us | LinkedIn | criticalsystemsanalysis.com All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E24
    August 22 · 7 min

    IEC 61508-3: Techniques and Measures Tables, Explained

    So let's zoom all the way in — past the family tree, past the lifecycle — down to the part of IEC 61508 that trips people up the most: part 3, the software part. And inside part 3, right at the back, live two annexes — Annex A and Annex B. Page after page of tables. Rows of techniques with names like static analysis, defensive programming, formal methods. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Here's the clause. Start with the failure we're trying to catch. And that's the split at the heart of this standard. Let's pin the word down. So if you can't calculate your way to confidence, what do you do instead? You earn it — with rigor. And this is the mechanism — the tables themselves. Reference: IEC 61508-3 Clause 7 specifies the software safety lifecycle requirements and its subclauses reference the Annex A tables for each phase. Verify the exact clause-to-table cross ref More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E23
    August 22 · 8 min

    IEC 61508: Managing Systematic Faults (Part 2)

    So let's zoom all the way in. Part 2 of the standard is the hardware book: the requirements for your electrical, electronic, and programmable electronic hardware. Most engineers open it hunting for the random-failure math, the architectural constraints and the probability of a dangerous failure per hour. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Picture your development process as a line of gates. So the standard splits the world in two. Let's pin the term down, because the standard is precise. If you cannot measure it, how do you control it? You buy confidence with rigor. Rigor earns a rating, and the standard gives it a name: systematic capability. Reference: Exact clause numbers were deliberately not stated in the narration to avoid inventing them. In IEC 61508-2:2010 the concepts map roughly to: requirements for the avoidance of syste More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E22
    August 22 · 6 min

    IEC 61508: Route 1H vs Route 2H, Explained

    We've walked the whole safety lifecycle. Now zoom all the way in, to one corner of part 2 of IEC 61508: the architectural constraints on hardware safety integrity, clause 7.four point four. Here's the twist most people miss. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Start with what these two routes have in common. First, where do these constraints bite? Take any safety loop, a sensor senses, a logic solver decides, a final element acts. Before Route one-H will even talk to you, it needs to know what kind of box you've got. Both routes ultimately care about how hardware fails, and the standard sorts every failure into four bins along two axes: is the failure safe or dangerous, and is it detected or undetected by your diagnostics. Route one-H turns those bins into a single number: the safe failure fraction. Now the lookup. Reference: Clause references (architectural constraints 7.4.4; Route 1H 7.4.4.2; Route 2H 7.4.4.3) are stated per IEC 61508-2:2010. Confirm exact clause numbering against the edition being ci More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Partner with us Follow on LinkedIn Visit our website Read our feature on Automate.org All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

  • S1 · E21
    August 22 · 5 min

    IEC 61508: Functional Safety Management

    So let's zoom all the way in — past the lifecycle diagram, past the safety integrity targets — to the one clause that decides whether any of it actually happens. In IEC 61508, part 1, clause 6 is titled, plainly, Management of Functional Safety. It looks short. It looks boring. Part of the Critical Systems Analysis functional-safety series on IEC 61508. In this episode: Here's the reframe. And that management has a home. So what is it, exactly? Management of functional safety is the set of activities that make sure the right safety work gets done — by competent people, in the right order, with proof left behind. First question an assessor asks: who's responsible? Clause 6 says you must specify responsibilities — by name — for every activity in the safety lifecycle. All of that gets written into one governing document — the functional safety management plan. Now, how do you prove the plan was actually followed? Every phase of the lifecycle takes inputs and produces outputs — and in this world, the outputs are documents. Reference: Clause numbers used are correct for IEC 61508-1:2010: Clause 6 is 'Management of functional safety' and Clause 8 is 'Functional safety assessment'. The overall safety lifecycle (re More in this series: IEC 61508 — Functional Safety Foundations | Functional Safety Assessment and Services Explore more from Critical Systems Analysis. Work with us | LinkedIn | criticalsystemsanalysis.com All shows on Apple Podcasts: AI & ML Safety | Fault Tree Analysis | FS Assessment | Safety Analysis | IEC 61508 | IEC 62443 | ISO 10218 | ISO 12100 | ISO 13849 | ISO 26262 | ISO/PAS 8800 | ISO 26262-11 | V-Model | UL 4600.

Showing 1–20 of 20 episodes