內燃動車組安全風險管理

李娜，談立成，燕春光，傅振亮，田雪艷

(中國北車集團 唐山軌道客車有限責任公司 產品技術研究中心，河北 唐山 063035)*

0 引言

根據東南亞地區高溫高濕、炎熱、多雨的熱帶氣候以及基礎設施相對陳舊和落后、具有一定的維修能力但缺乏先進的工具手段和技術水平的特點，在出口某內燃動車組的設計中采用“安全可靠、堅固耐用、適風適俗、成熟經濟”的原則.該內燃動車組適用于某國最長運輸距離為150 km軌鐵路的旅客運輸.動車組為3輛編組，兩輛動車和一輛拖車.動車組可以實現兩列重聯運行.車體鋼結構采用薄壁筒形整體承載焊接結構，設計強度滿足標準EN12663中P-III的要求，牽引傳動系統采用交—直—交傳動技術，主要由柴油機、主發電機、逆變器和牽引電機等組成.

對于鐵路客車產品而言，安全可靠的運營至關重要，在出口某內燃動車組設計過程中采用了系統安全工程的分析方法［1］，以識別車輛、子系統、接口、硬件、軟件、相關操作和運營程序等可能導致的引起人員傷亡、系統損壞、運營嚴重中斷的隱患事件，并根據事故影響的嚴重程度以及可能的發生概率評估其風險，提出了設計、制造、測試、維修程序等相關減輕措施，將該內燃動車組的安全風險控制在合理可接受的范圍，即符合國際標準 EN50126“Railway applications-The specification and demonstration of Reliability，Availability，Maintainability and Safety(RAMS)”鐵路應用可靠性，可用性，可維護性和安全性技術條件和驗證(RAMS)中規定的ALAPP(風險降到可行)原則.

1 各階段安全性分析工作

在安全性研究的所有內容中，最基本的是安全性分析和安全性評估［2］.根據EN50126標準中對RAMS工作的要求，并結合公司實際，內燃動車組在產品設計初期就將系統安全性分析的各項工作融入到了產品生命周期各階段中［3］，如圖1所示.隨著設計工作的進展、可獲得的數據和信息的增多，相關技術人員對安全性分析結果及時進行了更新、補充和完善.

圖1 項目各階段安全性分析工作

2 采用的安全性分析方法

系統安全性分析是安全系統工程的核心內容，也是安全性評價的基礎［4］.通過對出口某內燃動車組的功能特性和運行條件進行分析，項目采用的系統安全分析方法主要有初步危害分析(PHA)、系統危害分析(SHA)、子系統危害分析(SSHA)、接口危害分析(IHA)、操作和保障危害分析(O＆SHA)、量化風險評估以及安全原則及規范要求的符合性評估.

在開展內燃動車組各項安全性分析之前，首先制定了系統安全性工作計劃［5］，該計劃包含用戶所提出的安全性工作項目要求，用來實現組織結構、責任、工作流程和資源的合理安排，明確并安排所要開展工作項目、時間節點進度，并同時保證系統能夠滿足合同及項目規定的安全性要求，安全性工作計劃隨著產品研發進程不斷完善，并根據用戶要求對工作計劃做相應更改.本內燃動車組項目中安全性分析流程如圖2所示.

圖2 安全性分析流程

2.1 系統定義

在項目設計初期對出口某內燃動車組進行了系統定義，明確系統的主要功能及系統功能層次和約束條件，為安全性分析工作提供基礎［5］.同時，通過分析發現了許多低層次功能的接口問題，為系統接口隱患分析奠定了基礎.此項分析也是可靠性分析工作，如功能FMEA、可靠性建模、可靠性分配、可靠性預計等的前導工作.

本項目中系統定義涉及到的主要內容有系統功能和接口分析、成熟產品分析、環境條件及敏感部件分析等.

2.2 初步隱患分析(PHA )

隱患分析是針對系統的潛在隱患進行系統的分析，確定系統的主要隱患清單是進行初步隱患分析的基礎［6］.本項目中通過識別和車輛相關的隱患事件(參見表1)，確定了車輛系統安全要求，并進一步驗證了車輛系統架構和功能設計是否滿足其安全要求，以確保系統從設計一開始便具備固有的安全屬性.

表1 主隱患清單

在項目設計初期進行了車輛初步隱患分析，用以識別車輛系統可能涉及和需要控制的潛在隱患，并提出系統設計過程中需要執行的措施以消除或減輕相關隱患.本項目中進行的初步隱患分析如表2所示.

2.3 系統隱患分析、接口隱患分析以及操作和支持隱患分析

系統危害分析(SHA)用以識別和分析與子系統設計相關的、與安全關鍵設備功能和接口的相關的潛在隱患(如子系統結構設計、功能劃分等)，并提出相應的隱患消除或減輕措施［6］.SHA將設備看作“黑盒”以識別其邊界范圍內的隱患，并確定其相應的安全需求.SHA的目的包括驗證和確認子系統結構和功能設計是否滿足其安全要求;識別設備功能和接口故障以及人因錯誤可能導致的潛在隱患及對子系統/系統的影響等.本項目中進行的系統隱患分析如表3所示.

表2 初步隱患分析

表3 系統隱患分析

接口隱患分析(IHA)用以識別和分析與系統/子系統內部以及外部的接口相關的潛在隱患，提出系統/子系統和相關接口系統/子系統需要執行的隱患消除或減輕措施［6］.IHA關注接口功能中可能存在的潛在隱患，其識別出的隱患減輕措施可做為系統/子系統本身以及接口系統/子系統的安全需求.在分析過程中，一般也可采用系統隱患分析代替接口隱患分析.

操作和支持隱患分析(O＆SHA)用以識別和分析在系統/子系統/設備的運營和維修過程中與人員和規程相關的潛在隱患，并提出需要執行的隱患消除或減輕措施［6］.OSHA關注與人員操作相關的潛在隱患，其目的是優化系統設計或運維規程.本項目中進行的系統隱患分析如表4所示.

2.4 隱患管理和關閉

出口某內燃動車組項目中所有識別出的隱患均記錄在隱患登記冊中.使用隱患登記冊對隱患關閉狀態以及證據進行管理，定期更新隱患登記冊中有關隱患信息、預防/減輕措施相關證據、隱患關閉狀態等.車輛系統的隱患關閉遵循ALARP(風險降到可行)原則，隱患關閉過程如圖3所示.

圖3 車輛系統的隱患關閉過程

2.5 安全關鍵項

安全關鍵項(SCI)是一種工程項目，其安全完整性對列車的安全至關重要.本項目根據FMECA、危害分析和量化風險評估的結果，對顯著影響車輛安全運營的設備或產品列入安全關鍵項清單，進行重點關注和管理.本項目中納入安全關鍵項管理的項目包括:

(1)單一故障導致“嚴重的”或以上后果的部件或組件;

(2)單一故障導致初始風險等級為R1或R2的部件或組件;

(3)雙重故障導致“重大的”或以上后果的部件或組件.

其中形成的安全性關鍵項清單如表5所示.

3.安全性分析結果

通過對出口某內燃動車組開展上述系統安全分析，對車輛系統的各種潛在的隱患進行了識別，對風險發生的可能性及后果嚴重性進行了綜合分析，根據國際鐵路標準EN50126:1999中的規定，在本項目執行過程中，依照表6定義的風險矩陣對所有危害進行了風險等級評估:初始風險等級R1的12項，R2為22項，R3為84項，R4為102項.各風險等級的定義如下:

(1)R1(不容許的):除特殊情況外，必須消除該類風險(Risk must be reduced save in exceptional circumstances);

(2)R2(不希望的):必須將風險減低至最低實際可行的水平(Risk must be reduced if it is reasonably practicable to do so);

(3)R3(容許的):可忍受的風險，但仍須按成本效益盡量減低風險(Risk is tolerable but should be further reduced if it is cost effective to do so);

(4)R4(可忽略的):可接受的風險 (Risk is acceptable).

表5 安全關鍵項清單

表6 風險矩陣

通過以上的風險分析結果，在設計、制造、安裝、測試以及運營維護等階段提出為消除危險或將風險減少到用戶可接受水平所需的安全性措施和替換方案，其中以在設計上采取糾正措施作為首選考慮，并在設計過程中制定了所采用的安全性設計準則，例如，采用聯鎖、警告和過程指示等設計特性來避免會導致事故的人為差錯等.車輛系統最終剩余風險R1為0項、R2為0項、R3為23項、R4為197項.

3 結論

出口某內燃動車組項目通過在產品生命周期的不同階段開展PHA、SHA、IHA以及O＆SHA，識別出車輛、子系統、接口、硬件、軟件、相關操作和運營程序等可能導致的引起人員傷亡、系統損壞、運營嚴重中斷的隱患事件，并針對隱患提出了設計、制造、測試、維修程序等相關減輕措施.通過將PHA、SHA、IHA、O＆SHA 識別出的隱患和措施記錄在隱患登記冊，定期更新隱患登記冊中有關隱患信息、預防/減輕措施相關證據、隱患關閉狀態等，實現了改善系統的安全薄弱環節，有效降低了車輛產品的運營風險.

［1］周經倫，龔時雨，顏兆林.系統安全性分析［M］.長沙:中南大學出版社，2003:14-19.

［2］艷萍，唐禎敏，武旭.地鐵行車安全保障系統的研究［J］.城市軌道交通研究，2004(5):23.

［3］張凌輝，王海峰，漁海雷.港口工程全壽命風險管理［J］.中國水運，2008，8(8):56-57.

［4］沈斐敏.安全系統工程基礎與實踐［M］.2版，北京:煤炭工業出版社，1996.

［5］BSI.EN50126-1:1999 Railway applications-The specification and demonstration of Reliability，Availability，Maintainability and Safety(RAMS)(S).［s.l.］:［s.n.］，1999.

［6］MIL-STD-882C System Safety Program Requirements［S］.［s.l.］:［s.n.］，1996.