Functional Safety Certification for Cargo Drones: IEC 61508-2 Explained

Date: 2027-02-18
Location: Online
Host: Zach L

About this event

A Gap Analysis Workshop for TUV Certification Candidates pursuing functional safety certification. A live 30-minute gap analysis workshop on IEC 61508-2 (Hardware Requirements) for cargo drones, built for tuv certification candidates pursuing functional safety certification. What We'll Cover: What IEC 61508-2 (Hardware Requirements) requires and how its scope applies to cargo drones Mapping IEC 61508-2 clauses to the certification evidence assessors expect System-specific hazards and safety functions typical of cargo drones Common findings that delay certification, and how to avoid them A practical readiness roadmap for tuv certification candidates preparing for assessment Related topics: IEC 61508-2 · Cargo Drones · functional safety certification · functional safety assessment · Gap Analysis Workshop · TUV Certification Candidates · safety lifecycle · compliance evidence · SIL · PL · risk assessment · safety case Critical Systems Analysis provides embedded functional safety consulting for IEC 61508-2. Learn more: https://criticalsystemsanalysis.com Partner with us: https://meetings.hubspot.com/benjamin-twombly/strategic-partnerships

Topics

About IEC 61508-2 (Hardware Requirements)

This training provides practical skills and structured learning on the compliance requirements covered by IEC 61508-2.

Part 2 of IEC 61508 specifies the requirements for the realization phase of E/E/PE safety-related systems hardware: architecture, random hardware failure quantification, diagnostics, and the management of systematic hardware faults.

What it regulates

Hardware design and integration of safety-related systems, including architectural constraints (routes 1H/2H), failure rate analysis, and diagnostic coverage claims.

Who must comply

Hardware developers of safety PLCs, safety I/O, sensors, actuators and ASICs claiming SIL capability; integrators computing achieved SIL for assembled safety functions.

Key requirements of IEC 61508-2

Architectural constraints via Route 1H (HFT/SFF-based) or Route 2H (reliability-data based)

Quantification of random hardware failures against PFD/PFH targets

Requirements for diagnostic test intervals and coverage

Techniques and measures for avoiding and controlling systematic hardware faults

Requirements for data communication when safety data crosses interfaces

Key concepts: IEC 61508-2

Common Cause Failure (beta factor)

The susceptibility of redundant channels to fail together from a shared cause, modeled with the beta factor in reliability calculations.

Diagnostic Coverage (DC)

The fraction of dangerous failures detected by automatic diagnostic tests.

FMEDA

Failure Modes, Effects and Diagnostics Analysis — the systematic method used to derive failure rates, failure mode splits, and diagnostic coverage for hardware elements.

Lambda-D (λD)

The dangerous failure rate of an element, split into detected (λDD) and undetected (λDU) components.

Route 1H vs Route 2H

Two alternative paths to satisfy architectural constraints — 1H based on SFF and HFT tables, 2H based on field feedback reliability data with increased confidence requirements.

Frequently asked questions: IEC 61508-2

How do proof tests affect PFD?

Periodic proof tests reveal dangerous undetected faults; shortening the proof test interval reduces average PFD. The claimed proof test coverage and interval must be stated in the safety manual and honored by the end user.

What evidence does a SIL claim for hardware require?

A quantified FMEDA or equivalent analysis giving failure rates and diagnostic coverage, demonstration that architectural constraints are met via Route 1H or 2H, systematic capability evidence from the development process, and a safety manual stating the assumptions of use.

Can a single-channel (HFT 0) subsystem reach SIL 3?

Under Route 1H a Type B single-channel subsystem needs very high SFF (at least 99 percent) for SIL 3, which is rarely practical; designers usually add redundancy (HFT 1) instead. Route 2H can permit different architectures with strong field data.