Software Safety and Development Lifecycle
Software safety and development lifecycle
This domain tests software safety requirements, the V-model, SIL-dependent techniques, verification, and the handling of pre-existing and COTS software. Expect questions on systematic capability, tool confidence, and traceability.
Core rules
- Software failures are systematic, not random; reliability growth claims and MTBF do not demonstrate software safety integrity.
- The software safety requirements specification derives from the SRS and must be complete, unambiguous, verifiable, and traceable.
- IEC 61508-3 recommends techniques by SIL: for SIL 2–3, structured methods, static analysis, boundary testing, and independent verification are typical; diversity is used where systematic common cause must be addressed.
- Tool confidence depends on tool impact and error detection; a tool used to create safety-related code needs qualification proportionate to risk.
- Pre-existing software and COTS require a specific justification, including provenance, configuration, and verification evidence.
Worked example
A SIL 2 trip amplifier uses a real-time kernel and application code. The team writes software safety requirements, designs defensive checks on sensor range and memory, uses static analysis and requirements-based boundary tests, and has an independent tester validate against the SRS. Traceability runs from hazard scenario to requirement, code, and test. A "certified compiler" alone does not make the application SIL 2; the application evidence and verification do.
Traps
- Claiming a software SIL from a vendor certificate without application-level verification.
- Treating code coverage as proof of functional correctness.
- Omitting requirements for fault response, start-up, and degraded modes.
- Failing to assess tool and pre-existing software risk.