Functional Safety Certification for Autonomous Underwater Vehicles (AUVs): IEC 61508-2 Explained

Date: 2026-12-11
Location: Online
Host: Zach L

About this event

An Executive Briefing for Early-Career Engineers pursuing functional safety certification. A live 30-minute executive briefing on IEC 61508-2 (Hardware Requirements) for autonomous underwater vehicles (auvs), built for early-career engineers pursuing functional safety certification. What We'll Cover: What IEC 61508-2 (Hardware Requirements) requires and how its scope applies to autonomous underwater vehicles (auvs) Mapping IEC 61508-2 clauses to the certification evidence assessors expect System-specific hazards and safety functions typical of autonomous underwater vehicles (auvs) Common findings that delay certification, and how to avoid them A practical readiness roadmap for early-career engineers preparing for assessment Related topics: IEC 61508-2 · Autonomous Underwater Vehicles (AUVs

Topics

Registration

View event page

About IEC 61508-2 (Hardware Requirements)

This event covers the compliance, engineering, and verification requirements defined 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.