Functional Safety Certification for Service Robots: IEC 61508-3 Explained

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

About this event

A Deep-Dive Seminar for Design Engineers pursuing functional safety certification. A live 30-minute deep-dive seminar on IEC 61508-3 (Software Requirements) for service robots, built for design engineers pursuing functional safety certification. What We'll Cover: What IEC 61508-3 (Software Requirements) requires and how its scope applies to service robots Mapping IEC 61508-3 clauses to the certification evidence assessors expect System-specific hazards and safety functions typical of service robots Common findings that delay certification, and how to avoid them A practical readiness roadmap for design engineers preparing for assessment Related topics: IEC 61508-3 · Service Robots · functional safety certification · functional safety assessment · Deep-Dive Seminar · Design Engineers · safety lifecycle · compliance evidence · SIL · PL · risk assessment · safety case Critical Systems Analysis provides embedded functional safety consulting for IEC 61508-3. Learn more: https://criticalsystemsanalysis.com Partner with us: https://meetings.hubspot.com/benjamin-twombly/strategic-partnerships

Topics

About IEC 61508-3 (Software Requirements)

This event covers the compliance, engineering, and verification requirements defined by IEC 61508-3.

Part 3 of IEC 61508 defines the software safety lifecycle: requirements specification, architecture, design, coding, verification, integration, validation, and modification of safety-related software, with techniques graded by SIL.

What it regulates

Embedded and application software performing or supporting safety functions, including the selection of languages, coding standards, verification techniques, and tool qualification.

Who must comply

Developers of safety PLC firmware and runtime systems, application programmers of safety logic, and suppliers of software elements or libraries claiming systematic capability.

Key requirements of IEC 61508-3

Software safety requirements specification

Software architecture and support tools/languages selection

Detailed design, coding standards, and defensive programming

Verification: reviews, static analysis, and testing graded by SIL

Software aspects of validation, modification, and impact analysis

Annexes A/B: technique tables recommended or highly recommended per SIL

Key concepts: IEC 61508-3

Software safety validation

Demonstration against the software safety requirements in the target environment, distinct from module and integration verification.

Defensive programming

Coding practices that detect and contain runtime anomalies, such as range checks, plausibility checks, and control flow monitoring.

Structural coverage

Test-completeness metrics (statement, branch, MC/DC) whose expected rigor increases with SIL.

Technique tables (Annex A/B)

Normative tables mapping development and verification techniques to SIL levels as Recommended or Highly Recommended, driving the rigor of the software process.

Tool confidence level (T1/T2/T3)

A classification of software tools by their potential to introduce or fail to detect faults, determining the qualification evidence required.

Frequently asked questions: IEC 61508-3

Do software tools such as compilers need certification?

Tools are classified T1-T3; a T3 tool (whose output goes into the safety system, like a compiler or code generator) needs qualification evidence — certified status, proven-in-use history, or validation of its output — proportionate to the SIL.

How is pre-existing or open-source software handled?

As a pre-existing software element it must be justified via the routes the standard allows: compliant development evidence, proven-in-use data, or assessment of the element against the requirements for its role, plus wrapping and constraints defined in the safety manual.

Which programming languages are acceptable for SIL software?

The standard favors languages, subsets and coding standards that support unambiguous, analyzable code — for example limited-variability languages for application logic, or C constrained by a recognized subset with static analysis. Justification of the language and subset choice is part of the compliance argument.