Functional Safety Certification for Autonomous Mobile Robots (AMRs): IEC 61508-2 Explained

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

About this event

A Mock Exam Session for Field Service Engineers pursuing functional safety certification. A live 30-minute mock exam session on IEC 61508-2 (Hardware Requirements) for autonomous mobile robots (amrs), built for field service engineers pursuing functional safety certification. What We'll Cover: What IEC 61508-2 (Hardware Requirements) requires and how its scope applies to autonomous mobile robots (amrs) Mapping IEC 61508-2 clauses to the certification evidence assessors expect System-specific hazards and safety functions typical of autonomous mobile robots (amrs) Common findings that delay certification, and how to avoid them A practical readiness roadmap for field service engineers preparing for assessment Related topics: IEC 61508-2 · Autonomous Mobile Robots (AMRs) · functional safety certification · functional safety assessment · Mock Exam Session · Field Service Engineers · 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 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

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.

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.

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.