COTS RTOS and Legacy Library in a SIL 3 Gas Detection System

Route 3S for the RTOS is possible only if the evidence supports the claim. Ten years of field history is useful, but it is not sufficient by itself. The supplier must show the operating environment, configuration, version history, failure reports, known dangerous failures, and evidence that the field history is relevant to this SIL 3 application. The RTOS also needs a systematic capability assessment and configuration management. If the RTOS has undocumented behavior or is used outside its field-proven configuration, route 3S cannot be accepted.

Route 1S for the application requires the full IEC 61508-3 lifecycle for SIL 3: software safety requirements specification, architecture design, detailed design, coding standard, module and integration testing, verification and validation, and configuration management. The absence of MC/DC for safety functions is a significant gap for SIL 3; the assessor will expect structural coverage or a justified alternative. The MISRA violation in a linked legacy function is also a problem: if the function is in the safety executable, the supplier must prove it cannot be called by the safety function and cannot corrupt safety data. If that cannot be proven, the violation must be corrected or the library excluded from the safety build.

The compiler must be assessed for tool impact and tool error detection. If the compiler can introduce errors into the safety executable, or can fail to detect errors in the source, it has a higher tool impact. For SIL 3, a non-certified compiler can still be used if the supplier provides a tool confidence justification: tool validation, a diverse second compiler or independent build, comparison of object code, manual review of generated code, and extensive testing. The justification must show that the tool cannot corrupt the safety function or that the corruption would be detected.

A compiler without certification is not automatically unacceptable, but it cannot be trusted by default. The supplier should document the compiler version, options, known bugs, and the validation tests performed. For SIL 3 I would expect a strong argument, such as a validated subset of the language, coding rules that avoid risky constructs, and independent verification of the generated code. If the compiler is used only for non-safety code, the justification is simpler; if it builds the safety executable, the evidence must be proportionate to SIL 3.

I would treat the library change as a safety-related modification under MOC. The first step is impact analysis: identify every safety function that links the library, determine whether the changed function is reachable from safety code, and assess whether the change affects timing, memory, data or error handling. If the function is truly not used by the safety function, the supplier must prove that through call-tree analysis, linker map review and runtime evidence. If it is used, the change is safety-related.

Verification should include regression testing of affected safety functions, structural coverage appropriate to SIL 3, static analysis against the coding standard, and independent review of the change. The software safety requirements specification and the safety case must be updated, and configuration management must record the new library version. The change should not be released until the impact analysis, verification and validation are complete and the assessor has the evidence. If the MISRA violation is in the changed function, it should be corrected rather than carried forward.