Safety certification — where the time actually goes

Every team building a safety-critical product underestimates the certification timeline. The mistake is always the same: they budget for implementation and testing, then discover that the assessment, iteration, and re-review phases take as long as the engineering itself.

IEC 61508 defines a safety lifecycle with 16 phases, covering everything from initial concept through operation and decommissioning. Mapped to a project timeline that an early-stage team would actually plan against, these phases collapse into seven practical blocks.

Phase 1: Concept and hazard analysis (1–3 months). This is where the SIL target is determined. Techniques like HAZOP and FMEA are used to identify hazards, assess risks, and allocate safety functions. The output — a risk assessment and a SIL determination — defines everything downstream. Skip this or rush it, and every subsequent phase inherits the error.

Phase 2: Safety requirements specification (1–2 months). Each safety function is formally specified: what it does, what SIL it must meet, how it allocates between hardware and software, and what the acceptance criteria are for verification and validation. The Safety Requirements Specification (SRS) is the contract between design and assessment.

Phase 3: Architecture and design (3–6 months). Hardware architecture: Hardware Fault Tolerance, Diagnostic Coverage, Safe Failure Fraction calculations. Software architecture following the V-model. Redundancy design. Common cause failure mitigations. This is where the fundamental safety decisions are made — dual-channel vs. single-channel, diverse vs. homogeneous, hardware-logic vs. microcontroller.

Phase 4: Implementation and unit testing (3–8 months). Hardware build. Software coding using the techniques and measures specified in IEC 61508-3. Unit testing with code coverage requirements that increase with SIL level — branch coverage for SIL 1-2, MC/DC (modified condition/decision coverage) for SIL 3-4. Tool qualification for any development or testing tools used in the safety lifecycle.

Phase 5: Integration and validation (2–4 months). Hardware-software integration testing. System-level validation against the Safety Requirements Specification. Fault injection testing — deliberately introducing faults to verify that the system responds safely. Environmental testing under the conditions the product will actually operate in.

Phase 6: Independent assessment (2–6 months). This is where teams are always surprised. A third-party assessor — TÜV, UL, or exida — reviews the entire safety case: documentation, architecture, design rationale, test results, and traceability. The first review cycle almost always produces findings — gaps in documentation, insufficient test coverage, architectural questions, missing traceability links. Resolution takes time. A second review cycle is standard. For complex products, a third is not unusual. The level of assessor independence required increases with SIL: for SIL 1, an independent person within the same organization may suffice; for SIL 3-4, the assessor must be from an independent organization.

Phase 7: Certification and follow-up (1–2 months). Certificate issued. Then: annual surveillance audits. Any modification to the certified product — hardware change, software update, component substitution — triggers an impact analysis and potentially a re-assessment. Certification is not a one-time event. It's an ongoing obligation.

Total realistic timeline: 12 to 24 months for a typical SIL 2 product. For SIL 3, add 6 to 12 months. The individual phase ranges above sum to more than that, and deliberately so — in a real project several of them overlap. Architecture work continues into implementation, and assessment findings are resolved while integration testing is still running. The calendar total is shorter than the sum of its parts.

Two caveats a reader deserves. First, these are planning estimates drawn from the structure of the lifecycle itself, not a surveyed average. No certification body publishes duration benchmarks. TÜV SÜD, TÜV Rheinland, exida and UL between them have certified thousands of products and none of them publishes how long it takes. That absence is itself worth noticing in an industry whose product is assurance.

Second, duration is the wrong unit anyway. The one substantive public attempt at quantification — Solcept's, which opens by conceding that little public information exists — measures effort multipliers rather than calendar time: roughly 5× normal development effort for IEC 61508 SIL 1–2, and 7× for SIL 3–4, with software effort ranging from 125–500 person-hours per thousand lines of code at SIL 1–2 and 400–2,500 at SIL 3–4. That framing is more honest, because the calendar is dominated by how big the product is and whether functional safety was planned from the concept phase — not by the SIL number on its own.

For anyone writing a safety-critical product plan: double whatever your engineers told you, then add a quarter. The engineering is the part you can see. The assessment is the part you can't — and it's where the schedule breaks.