Functional Safety Certification for Patient-Handling Robots: IEC 61508-2 Explained

Date
2027-01-18
Location
Online
Host
Zach L

About this event

A Lunch-and-Learn for Automation Engineers pursuing functional safety certification. A live 30-minute lunch-and-learn on IEC 61508-2 (Hardware Requirements) for patient-handling robots, built for automation engineers pursuing functional safety certification. What We'll Cover: What IEC 61508-2 (Hardware Requirements) requires and how its scope applies to patient-handling robots Mapping IEC 61508-2 clauses to the certification evidence assessors expect System-specific hazards and safety functions typical of patient-handling robots Common findings that delay certification, and how to avoid them A practical readiness roadmap for automation engineers preparing for assessment Related topics: IEC 61508-2 · Patient-Handling Robots · functional safety certification · functional safety assessment ·

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.

Standard information based on the published text of IEC 61508-2 (Hardware Requirements). Event content is provided by the host. For authoritative guidance, consult the official standard body.