Everyone's Worried About the Wrong Thing
Every time autonomous robots make the news, the conversation goes straight to whether or not they're going to take over the world. The real story in this industry right now is genuinely hard engineering work, under real pressure, with standards that weren't written to be easy to read. I wrote this guide because the gap between what teams expect functional safety certification to look like and what it involves is wide.
One thing upfront: the goal of a functional safety program is not to make the safest possible product, as you can never make something 100% perfectly safe. The goal is to understand your system's risks clearly, design appropriate safeguards, and document the evidence in a way a certification body can verify.
The Standards Landscape
If you're building robotic systems, autonomous vehicles, or industrial machinery, the standard you'll encounter most often is IEC 61508. It introduced the concept of Safety Integrity Levels (SIL), which is a quantitative measure of the required reliability for a safety function.
From IEC 61508, a set of sector-specific standards has been developed:
ISO 13849: Covers safety-related control systems for machinery and uses Performance Level (PL) as its risk metric.
IEC 62061: The machinery sector standard that stays closer to the IEC 61508 framework and uses SIL directly.
ISO 26262: Covers road vehicles.
ISO 3691-4: Applies to industrial trucks, including autonomous guided vehicles.
ISO 12100: Addresses general machinery safety and provides the foundational risk assessment methodology.
Where Most Projects Get Into Trouble
The reasons projects get into trouble are remarkably consistent across different domains:
Starting Safety Too Late: The instinct to get the product working first and handle safety documentation near the end is the most expensive mistake in this space. Safety requirements need to influence design, not document it after the fact.
The Junior Engineer Problem: Many companies hire outside help expecting consultants to own the safety program, but instead get engineers who need direction and oversight from the client's own team.
Misunderstanding What the Standard Requires: The goal is risk reduction to a tolerable level, not the elimination of all risk. A consultant who applies requirements more conservatively than the standard demands creates schedule problems and cost overruns.
The Internal Hiring Trap: Hiring safety engineers without an existing safety infrastructure often goes wrong because those engineers, while capable, may not have run a complete certification from scratch before.
How Safety Gets Built In
Safety is a design feature, not a cost center. The decisions that determine whether a system will certify are mostly made in the first third of the development process. The two core analytical tools that support this work are FMEA and FTA.
FMEA (Failure Mode and Effects Analysis): Examines each component to identify how it can fail and builds a bottom-up picture of failure behavior.
Fault Tree Analysis (FTA): Works top-down from an undesired system-level event to trace back through combinations of component failures.
Documentation and Traceability
Every safety requirement needs to be traceable to a finding in the hazard analysis. Every design decision that implements or affects a safety function needs to be traceable to a requirement, and verification testing must be traceable to the requirements it's testing. That discipline is what separates documentation that actually supports certification from documentation that just fills a folder.
About CSA
Critical Systems Analysis (CSA) is an independent firm with no vendor affiliations or connections to any certification body. We’ve built relationships with assessment bodies over years of working alongside them, and we understand what they're looking for in a way that only comes from experience on both sides of the table.
Ready to talk?
Please send an email to info@criticalsa.com to start the conversation about your safety program.