Functional Safety Certification for Autonomous Trains and Metros: IEC 61508-3 Explained

Date
2026-10-22
Location
Online
Host
Zach L

About this event

A Worked-Examples Session for TUV Certification Candidates pursuing functional safety certification. A live 30-minute worked-examples session on IEC 61508-3 (Software Requirements) for autonomous trains and metros, built for tuv certification candidates pursuing functional safety certification. What We'll Cover: What IEC 61508-3 (Software Requirements) requires and how its scope applies to autonomous trains and metros Mapping IEC 61508-3 clauses to the certification evidence assessors expect System-specific hazards and safety functions typical of autonomous trains and metros Common findings that delay certification, and how to avoid them A practical readiness roadmap for tuv certification candidates preparing for assessment Related topics: IEC 61508-3 · Autonomous Trains and Metros · functional safety certification · functional safety assessment · Worked-Examples Session · TUV Certification Candidates · 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

Registration

View event page

About IEC 61508-3 (Software Requirements)

This training provides practical skills and structured learning on the compliance requirements covered 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.

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