Functional Safety Certification for Disinfection Robots (UV-C): IEC 61508-2 Explained

Date
2027-08-02
Location
Online
Host
Zach L

About this event

A Tabletop Exercise for Reliability Engineers pursuing functional safety certification. A live 30-minute tabletop exercise on IEC 61508-2 (Hardware Requirements) for disinfection robots (uv-c), built for reliability engineers pursuing functional safety certification. What We'll Cover: What IEC 61508-2 (Hardware Requirements) requires and how its scope applies to disinfection robots (uv-c) Mapping IEC 61508-2 clauses to the certification evidence assessors expect System-specific hazards and safety functions typical of disinfection robots (uv-c) Common findings that delay certification, and how to avoid them A practical readiness roadmap for reliability engineers preparing for assessment Related topics: IEC 61508-2 · Disinfection Robots (UV-C) · functional safety certification · functional s

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.

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.