人生分享

1.     安全案例的目的

安全案例（Safety Case）是一份經過結構化整理的安全論證文件，用來提供證據，說明在系統預期使用範圍（scope）內，被評估的系統如何符合所規定的安全需求。

安全案例具有以下目的：

·        使系統的使用者能夠對系統符合既定安全需求具有信心；

·        證明系統依據 EN 50126 系列標準所規定的要求，被判定為符合既定的安全需求；

·        提供**獨立安全評估（Independent Safety Assessment, ISA）**的依據；

·        提供安全相關應用條件（Safety-Related Application Conditions, SRAC）。

安全案例的用途，是讓一方對另一方提供安全保證（assurance）。
在本標準中，此保證最終是由系統開發方（例如供應商或承包方）提供給負責營運與維護鐵路的單位（例如鐵路營運單位或基礎設施管理者）。

安全案例的範圍通常有以下兩項限制：

·        安全需求本身的正確性證明，以及相關的風險評估，通常不包含在安全案例之內；

·        對安全案例中所識別之 SRAC 的符合性證明，通常也不包含在安全案例本身。

Safety Case 不是在「算風險」而是在「說服別人：我已經把安全做好了，而且有證據」。

       它在做的事是：

• 把「安全需求已經被正確實現」這件事
  → 用有邏輯、有證據、有結構的方式講清楚
• 讓營運單位、主管機關、ISA
  → 不用相信你這個人，而是相信這套證據鏈

        通常在 PHA / FTA / FMECA / Risk Assessment / Verification 裡面完成

Safety Case 只是把「結論 + 證據來源」組織成一個可被審查的整體

對應 Safety Case 內容

Process Compliance Claim（流程符合性聲明）

實際證據來源

• Safety Plan
• Lifecycle Definition
• RAMS 活動紀錄
• Review / Audit Record

Safety Case 裡怎麼呈現？

• 不需要重講整個生命週期
• 用表格說清楚：

SRAC 是什麼？

• 「這個系統要安全使用，外部必須配合什麼條件」
• 例如：
• 維修週期
• 操作限制
• 環境假設
• 人員資格

重點（標準明講）
Safety Case 不負責證明 SRAC 已被滿足
只負責「列出來、講清楚」

Safety Case 只是：「我用這些已被接受的結果，構成一個完整安全論證」

2.     安全案例（Safety Case）的內容

A 受評估系統之定義（System Definition）

安全案例應包含對所評估系統的定義，其內容包括：

• 主要子系統／設備（key subsystems / equipment）
• 系統架構與預期行為（architecture and expected behaviour）
• 系統介面與操作環境（interfaces and operational environment）
• 安全需求（safety requirements）
• 本安全案例所適用之系統組態／版本的定義
• 對輸入安全需求及其相關風險評估分析的參考

B 品質管理報告（Quality Management Report）

應包含：

• 品質管理活動
• 相關證據

C 安全管理報告（Safety Management Report）

應包含：

• 安全管理活動
• 相關證據

D 技術安全報告（Technical Safety Report）

應包含安全保證活動與證據，其內容包括：

• 在無故障條件下的安全性保證
• 在故障與錯誤發生時的安全性保證
• 在不利外部影響下的安全性保證
• 安全相關應用條件（SRAC）

E 相關安全案例（Related Safety Cases）

應包含：

• 對所有主安全案例所依賴之子系統／設備安全案例的參考
• 證明每一份子系統／設備安全案例中所規定的 SRAC，
  已在主安全案例中被滿足，或被延續納入主安全案例的 SRAC 中

F 結論（Conclusion）

應包含：

• 對前述各部分所提出證據的摘要
• 所有具體安全主張（safety claims）的清單
• 聲明：在符合所規定的應用條件之前提下，
  該受評估系統被認定為具有充分的安全性

詳細補充說明

① System Definition

實務上通常來自：

• System Definition Document
• System Architecture Diagram
• Interface Control Document (ICD)
• Safety Requirements Specification
• Hazard Log / Risk Assessment Reference

 ISA 常抓的點：

• 版本是否一致
• 這份 Safety Case 到底是「哪一個系統狀態」

② Quality Management Report

 證明你不是亂做

實務內容通常是：

• QMS（ISO 9001 或專案品質程序）
• 設計審查紀錄（DR / PDR / CDR）
• 文件管制、變更管制紀錄

多人忽略，但 ISA 會看
因為：品質混亂 = 安全不可相信

③ Safety Management Report

證明安全是被管理的，不是臨時補的

包含：

• Safety Organization
• Safety Plan
• 角色責任（Safety Manager / Assessor）
• Safety Review / Audit

這一章是在說：

「安全不是靠英雄，而是靠制度」

④ Technical Safety Report

整份 Safety Case 的核心

• Hazard Analysis 的結果「如何被設計處理」
• Fault-free / Faulted / External influence 三種情境
• 防呆、fail-safe、degraded mode
• SRAC
  Hazard Analysis 文件不一定放這裡
  但「它們的結論一定要被用到這裡」

⑤ Related Safety Cases

系統整合專案最容易出事的地方

典型情境：

• EI 用了商用模組
• 聯鎖整合既有子系統
• COTS / Supplier Safety Case

你要證明：

• 子系統的 SRAC 沒有被忽略
• 沒有「責任被丟來丟去」

ISA 最愛問的一句話：「這個條件，到底誰負責？」

⑥ Conclusion

標準格式邏輯是：

1. 證據我已經列完
2. 主張我已經說清楚
3. 在這些條件成立下
   → 系統可以被接受為安全

一定會有條件（SRAC）
沒有條件的 Safety Case = 不合格