為確保安全和效率，鐵路和運輸系統正在實施各種保護系統，如列車自動保護（ATP）、積極列車控制（PTC）和基于通信的列車控制(CBTC)等。地鐵和其他軌道交通系統正在采用自動列車操作（ATO）系統并運行“無人駕駛”列車(沒有駕駛員或駕駛員只用來處理緊急情況的列車)。

這些控制系統與安全息息相關。它們必須滿足IEC 61508和EN 5012x標準中所設定的嚴格可靠性要求。本文側重于介紹操作系統中對系統可靠性帶來最直接影響的一些特點：確保實時性的架構特性、故障分離和故障恢復等功能。



圖1 新西蘭的ONTRACK安裝了一個四頻道RoIP裝置，命名為ORC，作為IP網絡和傳統的VHF/IHF無線電網絡之間的橋梁，用于促進列車安全運行和追蹤軌道工人的位置。

標準

二十年前，歐洲電工標準化委員會頒發(fā)了鐵路應用標準EN 50126，它定義了可靠性、可用性、可維護性和安全性的規(guī)范，同時頒布了用于鐵路控制和保護系統軟件的標準EN50128和用于發(fā)送信號的安全相關的電子系統的標準EN 50129。

EN 50128:強調了軟件架構的重要性：“軟件架構是軟件和軟件安全完整性等級開發(fā)的基本安全策略。”規(guī)定如果要求SIL 3 或SIL 4的系統部署COTS（商用現成）軟件，“應定義一個策略以檢測COTS軟件的故障并保護系統免于故障”。

可靠性和隔離性

在一個軟件系統中，可靠性是可用性和可靠性的組合。這些品質主要取決于操作系統審計架構。

操作系統架構是整個系統可靠性的基礎，它決定了將組件與不同的SIL要求進行分離的難度和成本。

例如，一個ATO系統可能包含了一個顯示非關鍵信息的多媒體組件。該組件只需要達到SIL1或甚至SIL 0（EN標準為非安全相關的軟件定義了SIL 0）就可以了，而關鍵組件（處理與軌旁基礎設施相關的通信、管理減速和制動，報警等）則需要SIL 3或更高的認證。一個有利于SIL 0組件分離的架構不能在系統的安全關鍵部分上妥協：

a) 簡化設計，允許以最少的集成工作為SIL 0組件使用COTS軟件

b) eli消除了為滿足SIL 3要求而產生的設計、構建和驗證非關鍵組件的成本。

c) 由于它減少了安全關鍵系統的范圍，側重于關鍵系統組件的開發(fā)和驗證，使得整體系統更為安全。

架構

支持可靠性保證的操作系統通常被稱為實時操作系統（RTOS）。實時操作系統的架構是不同的。最常見的架構是實時執(zhí)行、單片式和微內核。

實時執(zhí)行

盡管已有50年歷史，實時執(zhí)行模式依然是許多實時操作系統的基礎。在此模式中，所有軟件組件—內核、網絡協議棧、文件系統、設備驅動程序和應用程序均在單一的內存地址空間里運行。

雖然有效，但該架構有兩大弱點。首先，任何模塊中的單一指針錯誤均能破壞內核或任何其它模塊所使用的內存，從而可能導致系統范圍內的故障。其次，系統崩潰也許沒有留下幫助識別錯誤的診斷信息。

宏內核

宏內核實時操作系統通過使用一個架構解決了內存錯誤所引起的系統崩潰的問題，在該架構里，用戶應用程序作為內存保護進程而運行。

該架構保護了內核免于錯誤的用戶代碼，但內核組件仍舊與文件系統、協議棧和驅動程序共享地址空間。因此，這些服務中的任何一個錯誤都能讓系統崩潰。例如，在一個Linux操作系統中，驅動程序組成75%的代碼，每一行顯示能達到內核的潛在錯誤。與實時執(zhí)行操作系統一樣，單片式操作系統架構的系統也許難于滿足可靠性的要求。

微內核

在一個微內核實時操作系統中，應用程序、設備驅動程序、文件系統和網絡協議棧存在于內核之外的一個獨立的地址空間；它們即與內核分離而且彼此分離。某一個組件中的故障不會波及系統。此外，由于它同樣以可預見的方式運行，因此系統能重啟故障組件。



圖2 微內核：組件彼此分離，一個組件的故障不會波及整個系統


對于安全相關的系統，內核與其它組件彼此分離是有利的。不是所有的組件都需要實現系統的安全關鍵部分所需的SIL。所要求的是較低級別的SIL組件能與安全關鍵組件分離。

這種分離也能通過虛擬機實現（管理程序），但這種策略通常需要更強大的處理器，這限制了合適的處理器的選擇并增加了成本。它也增加了系統的復雜程度，并可能影響實時性能。

實時操作系統的關鍵特點

微內核架構只是實現操作系統可靠性的一個特點。其它關鍵特點包括：

• 通過搶占低優(yōu)先級的內核調用來滿足實時性的承諾

• 由于優(yōu)先級反轉，防止不可預知的行為和系統故障

• 保證CPU資源調度的可用性以防止關鍵進程饑餓

• 利用軟件看門狗監(jiān)視進程，并在組件發(fā)生故障時采取糾正行動

搶占式內核

搶占式內核是實時操作系統的一個核心特點，在一個沒有搶占式內核調用的操作系統中，系統遇到不可預測的延遲會引起關鍵活動錯過截止時間— 使得系統無法滿足其可靠性的要求。

這些延遲是由高優(yōu)先級用戶線程等待完整的內核調用來完成所引起的，即使這個調用是系統中最低級別的進程造成的。更為糟糕的是，當驅動程序或其它系統服務（通常在內核調用時執(zhí)行）代表客戶線程執(zhí)行時，優(yōu)先級信息通常會丟失。

然而，在一個設計良好的實時操作系統中，搶占不會發(fā)生的時間窗極其短暫，通常是在納秒級，實時操作系統對中斷被禁止的時間和搶占關閉上規(guī)定了一個上限。該上限允許開發(fā)者確定最壞情況的延遲并在其設計中做調整。

為確?？深A測性和關鍵活動的及時完成，實時操作系統必須盡可能簡單，以便在通過內核的最長的非搶占式代碼路徑上有一個明確的上限。通過一個包括只用短執(zhí)行路徑服務的內核和分配給外部進程或線程的密集型操作（例如進程加載）能實現最佳的簡易性。

優(yōu)先級繼承

優(yōu)先級反轉是一種低優(yōu)先級線程阻止高優(yōu)先級線程完成其工作的情況。表３顯示了一個低優(yōu)先級線程封鎖高優(yōu)先級線程的例子。這也許是通過同步引起（例如，警報和數據記錄器共享由鎖或信號燈控制的資源，警報等待數據記錄器解除鎖定的資源），或通過警報要求一項目前由數據記錄器使用的服務引起的。

在圖３的例子中，一個中等優(yōu)先級的線程（數據聚合器）搶占低優(yōu)先級的記錄器，但不需要該記錄器使用的資源，這使記錄器保持了資源控制。當警報嘗試運行，它搶占了聚合器并封鎖，但不能訪問仍被記錄器控制的資源。由于警報的封鎖，調度程序尋找能運行的優(yōu)先級別最高的線程，并運行聚合器，顛倒線程優(yōu)先級。



圖3 有了優(yōu)先級繼承，高優(yōu)先級線程不會被封鎖

優(yōu)先級繼承是一個阻止優(yōu)先級反轉的機制。它將高優(yōu)先級線程的優(yōu)先級分配給低優(yōu)先級線程直到線程完成。在上面的這個例子中，數據記錄器將繼承警報的優(yōu)先級，因此不能被數據聚合器搶占。它將完成并恢復到原來的優(yōu)先級，而且警報將解除封鎖并不受數據聚合器的影響，該機制在圖4中顯示。



圖4 自適應分區(qū)是保護特定線程和線程組的一套規(guī)則



時間分區(qū)

在與安全相關的系統里，如果一個子系統缺乏CPU周期，它提供的服務也許對其它子系統來說是不可用的。例如，在地鐵系統里，如果一個車載ATP系統的通信棧進程在需要時無法響應，該車載ATP系統也許要與軌旁ATP基礎設施承擔通信中斷并開始啟動安全程序，減速或停止列車并中斷上下線的服務。

時間分區(qū)通過硬件或軟件的手段強制分配CPU預算，解決資源饑餓。它可以防止進程或線程壟斷其它進程或線程需要的CPU周期?？赡艹霈F兩種類型的分區(qū)：靜態(tài)和自適應。

在靜態(tài)分區(qū)中，任務在區(qū)內分組，每個區(qū)分配了一定比例的CPU時間。沒有一個任務在任何區(qū)內能消耗超過分區(qū)預先確定的CPU時間。通過確保每個分區(qū)都能得到一定的CPU時間，該限制確保所有的關鍵進程總是能夠保持運行。

不幸的是，沒有進程能夠使用比分配給它分區(qū)限定的更多的CPU周期，即使其它分區(qū)沒有使用所有分配給它們的時間。因此，靜態(tài)分區(qū)白白浪費了CPU周期并降低了系統處理高峰需求的能力。

與靜態(tài)分區(qū)一樣，自適應分區(qū)為進程或進程組保留了CPU周期。然而，不像靜態(tài)分區(qū)，自適應分區(qū)使用動態(tài)調度算法，重新分配未使用的CPU周期給需要的分區(qū)。只有當CPU運行時，它才執(zhí)行分區(qū)預算。自適應分區(qū)從而讓系統以100% 的能力運行，僅當一個分區(qū)以上的進程競爭周期時，它才執(zhí)行分區(qū)預算。

此外，自適應分區(qū)基于預先確定的標準，能在系統運行時調整預算。例如，一個負責制動調整的分區(qū)也許在每小時低于20公里的速度時被分配30%的CPU時間，而在更高速度時分配到45%的CPU時間。

軟件看門狗

要求可用性保證的系統會實施以硬件為導向的高可用性解決方案和軟件看門狗。

軟件看門狗是一個監(jiān)測系統并進行多階段恢復或清除關閉的一個用戶空間進程?？撮T狗必須自我檢測并彈性處理內部故障。它如果意外停止，必須通過將其任務移交給鏡像進程從而立即、完全重建其自我狀態(tài)。

如發(fā)生故障，看門狗可以執(zhí)行多種操作以確保系統安全性并恢復。例如，它能夠中止然后重啟故障進程，避免系統重啟?；蛘?，它也能終止該進程和相關進程，初始化硬件到一個安全狀態(tài)，然后以協調的方式重新啟動終止的進程?；蛘?，如果故障至關重要，看門狗可以執(zhí)行可控的關閉或重啟整個系統并發(fā)出報警。

最后，軟件看門狗能夠監(jiān)測傳統的硬件看門狗不可見的系統事件。例如，硬件看門狗能確保驅動程序正服務于硬件，但可能無法檢測到其他程序是否正確的與該驅動程序溝通。而軟件看門狗可以彌補這一差距，當它檢測到一個內部異常時能夠采取行動。