Functional Safety Certification for Entertainment and Theme-Park Robots: IEC 61508-2 Explained

Date: 2026-08-10
Location: Online
Host: Zach L

About this event

A Compliance Clinic for System Integrators pursuing functional safety certification. A live 30-minute compliance clinic on IEC 61508-2 (Hardware Requirements) for entertainment and theme-park robots, built for system integrators pursuing functional safety certification. What We'll Cover: What IEC 61508-2 (Hardware Requirements) requires and how its scope applies to entertainment and theme-park robots Mapping IEC 61508-2 clauses to the certification evidence assessors expect System-specific hazards and safety functions typical of entertainment and theme-park robots Common findings that delay certification, and how to avoid them A practical readiness roadmap for system integrators preparing for assessment Related topics: IEC 61508-2 · Entertainment and Theme-Park Robots · functional safety c

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

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.