1、鐵路安全信號平臺開發中的安全管理實踐摘要：介紹了某鐵路安全信號平臺開發中符合EN50126系列歐洲標準的安全管理實踐工作，論述了符合安全完整性等級4級（SIL4）的安全管理流程。本文首先對EN50126系列標準中有關安全管理工作的相關規定進行綜述；然后結合安全信號平臺研究開發過程，著重介紹了符合SIL4的安全管理流程和實踐方案；最后對安全管理對平臺開發的實踐意義進行總結。關鍵詞：RAMS 安全管理 安全完整性等級 安全信號平臺Abstract: The practical work of safety management in compliance with the EN50126 seri

2、al European Standards during the development of a railway safety signalling platform is proposed. The safety management flow against safety integrity level 4 (SIL4) is also introduced. Firstly, this paper presents a summary on safety management roles in the EN50126 serial European Standards. Secondl

3、y, the SIL4 safety management processes and practices are introduced with the research and development process of the safety signalling platform. Finally, the practical significance of safety management to the platform is summed up.Key words: RAMS, safety management, safety integrity level, safety s

4、ignalling platform隨著經濟和軌道運輸業的飛速發展，特別是高速鐵路和高密度城市軌道的建設，世界上包括發達國家和發展中國家在內的許多國家已經越來越認識到鐵路產品可靠性，可用性，可維護性和安全性（RAMS）的重要性。因為產品的可靠性，可用性，可維護性和安全性與鐵路運營的性能密切相關，失去任何一個性能，將對鐵路的正常運營產生嚴重影響。特別是安全性，它是鐵路信號產品的關鍵特征。本文首先對EN50126系列歐洲標準進行介紹，明確不同標準的相互制約關系和適用范圍；然后結合某鐵路安全信號平臺的研究開發過程，對如何構建符合歐洲標準的安全管理系統進行綜述；對項目進展過程中安全管理系統的實際運行和

5、相關經驗進行總結，論述如何通過安全管理手段，在相關技術安全手段和質量管理體系的配合下，使產品最終符合SIL4要求。1. EN50126系列歐洲標準為保證產品（系統）的高安全、高可靠性，歐洲電子與電氣委員會（CENELEC）制定了專門的標準，給鐵路關鍵應用（特別是信號系統）的產品研發，設計和工程應用提供了高層次的可以借鑒的指導標準。這些標準包括：EN50126：鐵路應用可靠性，可用性，可維護性和安全性的規格和證明EN50128：鐵路應用通信、信號和處理系統鐵路控制和防護系統軟件EN50129：鐵路應用通信、信號和處理系統信號安全相關的電子系統歐聯盟國家已經把這些標準作為鐵路信號項目必須遵循的法律

6、法規來對待。并且這些標準已經被國際標準組織（IEC）所接受， 這些標準已經成為國際標準。如IEC62278、IEC62279、IEC62425分別對應于歐標的EN50126、EN50128、EN50129。以上三個標準之間的關系如下圖所示1。圖 1 主要CENELEC鐵路應用標準的關系圖其中，EN50126定義了系統可靠性、可用性、可維護性和安全性，并且規定了安全生命周期內各個階段對RAMS的管理和要求。但是在該標準中未定義RAMS的具體的定量目標。RAMS作為系統服務質量衡量的一個重要特征，是在整個系統安全生命周期內的各個階段通過設計理念、技術方法而得到的。為了達到規定的RAMS，必須針對前

7、面的RAMS影響因素，在整個系統的生命周期內有效控制RAMS的影響因素，即系統的隨機故障和系統故障。EN50126要求在整個安全生命周期進行RAMS管理，針對每個階段給出應需要完成的RAMS任務，同時給出相關的具體文檔和要求2。由于在信號系統中采用計算機技術越來越廣泛，由軟件來承擔安全性需求的比重越來越大，因此軟件安全性問題變得更加突出。為此EN50128針對軟件的安全保證提出了相關的規范和設計標準。在該標準中，對鐵路控制和防護系統的軟件進行了安全完善度等級的劃分，針對不同的安全要求制訂了相應的標準，按不同等級對整個軟件開發、檢查、評估、檢測過程包括對軟件需求規格書、測試規格書、軟件結構、軟件

8、設計開發、軟件檢驗和測試、軟硬件集成、軟件確認評估、質量保證、生命周期、文檔等提出相應的程序與規范的要求2。EN50129定義了為了保證安全相關的鐵路信號電子系統所必須滿足的條件。這些條件包括： 質量管理措施；安全管理措施；功能與技術安全措施以及安全接收與許可。對于安全管理，引入IEC61508提出的安全生命周期概念，就是說對于安全相關系統的安全部分，在設計時按照該步驟進行設計，并且需要進行全程的安全評估和驗證，目的是進一步減少和安全相關的人為失誤，進而減少系統故障風險2。系統的安全完整性是指在規定的條件下系統于給定時間內滿意地實現所要求的安全功能的可能性3。安全相關系統中根據在安全

9、功能上對安全完整性的定量要求，將安全完整性分級，即安全完整性等級（Safety Integrity Level, SIL）。SIL通常由可定量計算部分（通常與硬件相關，如隨機失效）和不可定量計算部分（通常與軟件、技術規格、文檔和過程等的系統性失效相關）共同組成3。為了獲得實現系統指定功能安全完整性等級的信心，對于不可定量計算部分，需要完善的質量管理體系和符合EN50126的安全管理體系來保證。2. 安全管理系統構建安全管理過程的目的是進一步減少安全相關的人為因素在整個產品生命周期中對系統的影響，從而降低安全相關的系統故障殘留風險。而使用安全管理過程對于安全完整性等級1到4是強制性的。安全管理過

10、程是由一些階段和活動組成，將這些階段和活動聯系起來就形成安全生命周期。安全生命周期應與EN50126中定義的系統生命周期相一致，系統生命周期見圖 23。系統生命周期可以根據不同開發目的加以適當調整。圖 2 系統生命周期示意圖考慮到某鐵路安全信號平臺的特點，本項目主要包括生命周期的1-10階段。通過對這些生命周期的分析，認為可以將安全生命周期分為下面六個階段：階段1系統需求定義：此階段需要識別操作和維修策略；識別操作和維修環境；識別既有基礎設施限制產生的影響；評價以往RAM的經驗數據；進行初步RAM分析；制定RAM政策；識別既有基礎設施限制對RAM產生的影響；評價以往安全性的經驗數據；進行初步風

11、險分析；制定總體的安全性計劃；定義風險標準的可容許性并識別既有基礎設施限制對安全性的影響。階段2系統風險分析：此階段需要進行系統危險和安全性風險的分析；建立風險源日志；識別會導致風險的事件；進行風險源識別以及安全性分析。階段3系統規范：此階段進行需求分析，包括根據風險分析結果定義系統安全需求；定義安全接收準則；建立用于控制各個不同生命周期安全任務的安全管理措施。階段4設計實現：此階段包括進行系統結構設計，并識別安全相關系統和非安全相關系統；對系統安全需求和安全目標進行分配；定義子系統或模塊的安全接收準則；根據項目進展適當更新系統安全計劃；深入進行風險源識別以及安全性分析；通過理論分析、會議回顧

12、、測試（軟件模塊測試、硬件模塊測試和集成測試）和驗證手段系統或子系統設計與實現能夠滿足安全需求；對安全管理進行過程控制，管理；準備安全例證。階段5系統確認：根據子系統測試報告、系統測試報告，以及系統各個階段的驗證報告，確認系統中所采用的風險控制或緩解措施能夠符合安全需求，并形成確認報告階段6系統安全接收：此階段接受獨立的三方對產品進行安全評估。下圖使用V形表示法對安全生命周期六個階段以及不同階段之間的驗證/確認關系進行表示。圖 3 安全生命周期不同階段之間的確認關系安全系統生命周期的設計和確認過程可看成為一個“自頂向下”階段并伴隨一個“自底向上”階段。為了保證安全管理過程的有效執行，必須建立符

13、合歐標要求的安全組織，由有能力的人員，按照預定的角色要求，對安全活動進行控制。同時，為了符合相應的安全完整性等級，歐標對不同角色之間的獨立性存在明確的要求。比如對于SIL3和SIL4，設計人員、驗證人員與確認人員必須滿足下圖所示的獨立性1。(a)(b)圖 4 滿足SIL3或SIL4的角色獨立性關系圖中，使用點劃線區分不同組織，即評估人員與其它人員必須屬于不同的組織；使用實線表示不同的人。可以看出，驗證與確認人員必須滿足與設計人員的獨立性。在項目開發實踐中，我們采用了符合圖 4(a)的安全組織。3. 項目安全管理實踐在某鐵路安全信號平臺的研究開發過程中，為了使產品能夠滿足SIL4的要求，需要相關

14、技術安全手段并結合安全管理和質量管理手段才能實現。而安全管理過程必須符合一定的流程，安全管理人員必須遵照相關的安全管理規定，對項目安全生命周期中各個階段進行有效管理。下面對平臺開發過程中的安全管理的實踐經驗進行總結。3.1 安全計劃在安全管理過程中，首先要制定安全計劃。安全計劃不僅包括目標，而且包括實現這個目標需要采取的措施；計劃制定之后，要按照計劃使用檢查表的方式對各個活動進行檢查，看是否實現了預期效果并達到了預期目標；通過檢查找出問題和原因，并及時進行處理。在安全計劃的執行過程中，應該在安全生命周期每個階段結束后進行安全計劃的評審，以確保安全計劃得以有效執行。同時在執行過程中，會根據具體執

15、行情況對計劃進行修改，而為了保證計劃修改的可行性，需要對修改后的安全計劃重新進行評審。3.2 系統安全需求規范系統的安全需求規范主要包括安全功能和安全完整性要求，這些內容可以通過風險分析過程得到，并被單獨記錄在系統安全需求規范中。根據不同的安全完整性等級，所需的安全需求規范內容各不相同。對于某鐵路安全信號平臺，為使系統安全需求規范制定階段達到SIL4的要求，應該在流程上注意下面幾點：a) 為了明確平臺中不同子系統的安全特性，確定后續安全分析對象，應區分安全相關子系統和非安全相關子系統，定義它們之間的接口，并對這些接口進行分析。b) 在項目中，分別對平臺、子系統和模塊這三個層次提出了相應的安全需

16、求。為了保證不同層次的功能需求和安全需求具有可追溯性和一致性，使用了需求管理工具和需求對照表，分別利用自動化的方法和人工方法對需求規格進行檢查。c) 在系統需求規格定義過程中，由于涉及到用戶、設計者等多方面人員，因此需要一種簡單明確、無二義性且容易被大家接受的描述方法對不同群體的意圖進行準確表達。半形式化描述語言UML可以很好的表達不同行業、不同背景人員的意圖，使用UML可以極大地減少由于信息誤讀或行業限制造成的溝通困難，較好的完成平臺需求規格的定義。d) 風險日志在項目的初期即被建立，在整個項目生命周期中進行了更新和維護。風險日志的內容包括風險源標識、風險源描述、初步分析得到的產生風險源的原

17、因及風險源導致的結果、風險源的風險指數、風險源狀態、風險源負責人等內容。e) 在需求規范的編寫過程中，始終貫徹SMART（Specific, Measurable, Achievable, Realistic, Testable）原則，即具體的、可測量、可完成、現實的、可測試的。SMART原則的遵循，可以有效提高需求規范的可讀性、可追溯性和可實現性。f) 在系統功能需求和安全需求規范定義完成后，為了保證需求規格能夠正確、完整的反映各方面的要求，通過會議評審的方式對需求規格進行了檢查與審查。3.3 安全組織安全管理系統必須在一個適當的安全組織控制之下，由有能力的人員按照規定的角色來執行。為保證安

18、全組織中各類人員能夠有足夠能力從事相關的工作，在項目實施過程中，需要在所有安全相關活動中進行重復或定期的培訓；同時動態對所有人員進行人員能力的考核與評價，確保所有人員具有較高的技術教育程度或豐富的經驗，并對不合格的人員進行特殊培訓或更換。安全組織采用如圖 4(a)所示的組織形式。如圖可知，雖然設計人員與驗證/確認人員均處于同一組織，但存在管理上的獨立性，即驗證/確認人員在管理體制上完全不受設計人員或項目負責人的控制，可以獨立進行相應的工作，得出獨立的結論，并就安全管理存在的問題直接向上級管理機關反應；評估人員與其他項目相關人員不能任職于同一組織，以進行獨立的第三方安全評估。3.4 系統設計與開

19、發這一階段需要通過采用一種自頂向下、結構化的設計方法實現系統特定的功能與安全需求，并通過對各種設計文檔的嚴格控制和評審，確保設計能夠滿足功能和安全需求的要求。在平臺結構設計過程中，使用自頂而下的分層設計方法，盡量采用模塊法設計理念，在保證所有設計均能完全追溯到需求規格的同時，盡量使用完全經過確認的、易于理解的且大小受限制的模塊，并確保模塊之間的功能隔離。在軟件設計以及軟硬件集成過程中安全管理的相關內容可以參見文檔4。為使平臺能夠具有較好的抗外部干擾能力，在設計與開發過程中，還需要對諸如EMC、振動等外部干擾進行相關研究和處理。3.5 系統驗證與確認在平臺安全計劃中，還包括了對生命周期各階段滿足

20、前階段確定的具體安全要求的驗證計劃，以及對整個系統滿足安全需求規格的確認計劃。在圖 3中，虛線所示的就是設計實現階段的各種驗證活動。下面給出不同安全生命周期的驗證活動：a) 系統需求定義階段：用戶、項目主管部門對平臺需求與定義文檔進行審核。b) 系統風險分析階段：對平臺工作狀態和功能的UML狀態圖和時序圖描述進行審核，確認其描述的充足性和準確性；驗證對風險源日志，原因分析，結果分析，以及風險分析報告等文檔進行驗證。c) 系統規范階段：對平臺需求規格書、安全需求規格書、驗收規格書等進行了驗證。d) 設計實現階段：首先對平臺結構設計進行驗證；然后對平臺各個子系統中不同軟/硬件模塊的軟/硬件設計方案

21、進行驗證；并對涉及到安全需求實現的軟/硬設計進行專家評審；接著依據相應層次的設計規格，通過軟件單元測試、軟件集成測試、硬件模塊測試、子系統軟/硬件集成測試、系統集成測試等，對系統設計實現進行驗證，確保所有功能和性能需求規格均得到有效實現；通過測試和分析驗證方法，對每個安全需求的實現進行驗證，確保所有安全需求規格得到有效實現；采用FMEA方法，驗證硬件的故障模式可以滿足系統安全需求。在安全生命周期的第五階段，即系統確認階段，根據測試報告、RAM報告及安全驗證報告，證實所開發的平臺滿足原始的用戶需求。以上這些驗證與確認過程均需要通過相關級別的審批，并產生驗證或確認報告。當出現對平臺的修改或變更時，相應的驗證過程需要重新進行。3.6 安全回顧安全回顧可以在安全生命周期中合適的階段及項目安全管理者認為必要的時間進行。在平臺開發過程中，在每個安全生命周期結束時，均進行了安全回顧。考慮到風險分析階段在系統設計實現過程中也要不斷循環進行，因此對該階段根據階段性成果進行了數次安全回顧。安全回顧一般采用安全管理人員組織相關人員，通過回顧會