摘要

當SIL2LinuxMP項目三年前開始啟動的時候，一些對Safety沒要求的系統(tǒng)已經開始構建并使用Linux了。工業(yè)界使用Linux主要是因為它強大的Security能力以及對現代硬件無與倫比的支持。這兩個要求對現代工業(yè)應用很重要，可以在多核CPU上使用Linux來滿足。但是，是否存在基于Linux系統(tǒng)的Safety論證和維護問題，依然是開放的。

?

到目前為止，雖然還未實現基于Linux的系統(tǒng)的Safety認證的最終目標，但對于基本組件(Linux，glibc，busybox)的認證已經實現。

?

SIL2LinuxMP項目是作為工業(yè)研究項目而啟動的，目的是確定是否有可能使用Linux操作系統(tǒng)作為基礎來構建復雜的軟件密集型Safety相關的系統(tǒng)。在過去的幾年中，最初發(fā)現的許多潛在的問題幾乎都可以解決，但是其他的問題令我們驚訝。到目前為止，似乎沒有經過Safety認證的多核CPU（具有四個或更多核）。

?

這篇文章不僅說明了在過去三年我們碰到的問題和取得的成就，也討論了目前提出的解決這些問題的方法。

?

這些方法涵蓋了系統(tǒng)Safety生命周期的所有方面。在系統(tǒng)工程系別，我們設計了適當的過程來量身定制Safety過程，從開發(fā)到可控制的選擇過程。我們開發(fā)了分層的系統(tǒng)危害分析，以系統(tǒng)地得出足夠的Safety屬性，并在用例上演示了此分析的功能。我們在評估中涵蓋了Linux開發(fā)過程，為此我們設計了數據挖掘方法，以利用可用的開發(fā)數據來量化軟件質量?；谶@些數據，我們得出了統(tǒng)計論證來證明開發(fā)過程的適用性。為了解決Linux源代碼及其評估方面的剩余不確定性，我們將能夠緩解同一系統(tǒng)故障的多個半獨立Linux特性的質量評估合并為一個Safety論證。這種殘余故障的多層處理是基于軟件保護層的分析。

?

這些方法為Linux認證路線提供了必要的方法，使得Linux能夠達到符合IEC 61850(SIL2)的Safety等級2。

?

關鍵詞：Linux，Safety，預存在的軟件

?

引言

?

近些年來，整個行業(yè)的發(fā)展是越來越依賴高度復雜的系統(tǒng)。比如汽車自動駕駛，工業(yè)機器人和共享的工作環(huán)境。這些新的發(fā)展有望為個人生活和工作生活帶來巨大的改善。但是目前為止，大多數都只解決了功能問題。除了從功能方面著手外，還需要考慮非功能屬性，比如Security和Safety要求，然后才能讓大眾使用這些系統(tǒng)。

?

本篇文章重點是復雜系統(tǒng)的Safety特性以及深入介紹在SIL2LinuxMP項目最初三年的經驗。這個項目由由開放源代碼自動化開發(fā)實驗室（OSADL）和各個行業(yè)的許多合作伙伴公司管理。

?

SIL2LinuxMP項目的目標是創(chuàng)建一個可用于提供主線Linux內核Safety論證的框架，該框架可指導認證過程并盡可能減少認證過程的工作量。我們通過盡可能多的自動化過程來減少工作量，并使Linux的質量評估對不斷發(fā)展的Linux內核可重復使用。

?

為了驗證該框架是否實際可用，我們針對特定用例對Linux進行了驗證。

?

在研究解決方案之前，與其他之前存在的Safety關鍵的系統(tǒng)相比，本文在復雜性規(guī)模上邁出了重要的一步。在第2部分討論的這些含義證明了對SIL2LinuxMP項目以及其所涉及的（Safety關鍵的系統(tǒng)）過大的軟件堆棧的必要性。

?

然后，本文介紹了項目中要解決的最重要問題，并展示了目前的中間結果。我們把這些問題的討論分成了兩部分。第三部分介紹了從項目開始就討論的問題。第四部分介紹了在這個項目的過程中意料之外發(fā)現的問題。

?

請注意，盡管本文提出了更有趣和新穎的方法，但并未提及設計傳統(tǒng)Safety工程活動的那一部分工作量。這些目標在這里被描述為明確的反陳述，以防止再次引起誤解。這些誤解曾經導致了討論伙伴的困惑。

?

A．SIL2LinuxMP的目標和常見誤解

在我們開始討論第3到5的技術部分之前，我們首先展示SIL2LinuxMP項目的目標。這里明確了期望和不期望的內容，并總結了SIL2LinuxMP項目如何處理特定的問題。

?

澄清目標是很有必要的，因為它需要對習慣于購買和將操作系統(tǒng)視為黑盒的公司進行重大的范式轉換。盡管Linux具有為每個已部署的系統(tǒng)提供免版稅使用許可的優(yōu)勢，但成本卻轉移到了建立各個公司適合的Safety工程知識方面。

?

目標1：

建立一個框架，能夠給如何構建基于Linux的Safety相關系統(tǒng)提供指導

?

常見誤解：有些人認為SIL2LinuxMP正在創(chuàng)建一種產品，該產品將以收縮包裝的形式提供，而無需額外的工程工作。

?

SIL2LinuxMP創(chuàng)建打包產品的想法是一個非常普遍的誤解，但不幸的是，這似乎使某些公司無法積極參與SIL2LinuxMP項目。

?

作者們認為，將來不會存在縮水打包的Linux軟件包，該軟件包可以在任意硬件上執(zhí)行而沒有任何限制，并且仍可用于對Safety要求很高的應用程序。

?

這是許多人似乎擁有的夢想（有的人將其命名為夢想SEooC），但是不幸的是，由于多種原因，這個夢想是不現實的。 最重要的是，Linux內核的接口相當龐大。 它大概有1500次API調用，甚至不包括內核中的其他接口，例如 proc或sys偽文件系統(tǒng)。

?

從理論上講，直到最后一次系統(tǒng)調用為止，對其進行分析都是可行的，但它絕對不可維護，因此從經濟上來說并不劃算。在撰寫本文時，在SIL2LinuxMP用例中大約使用了30~35個API調用（系統(tǒng)調用以及庫調用，例如memset()），并且對其參數有額外的限制，比如僅允許使用某些標志。并且對用法也有額外的限制，比如某些調用只能在系統(tǒng)初始化期間使用。所有這些API調用都是在Linux上運行的，大多數現有應用程序中普遍使用的方法，沒有任何較深奧且很少使用的調用。

?

此外，它們的用法僅限于特定的組合，比如：內存分配需要組合調用malloc()，mlockall()和memset()，并且只允許系統(tǒng)初始化的時候調用。

?

此外，我們僅實現機制來抵消危害分析過程中發(fā)現的用例特定故障。

?

與不切實際的，預認證的縮水打包的Linux包相比，SIL2LinuxMP項目的目標是創(chuàng)建一個框架，以指導Safety工程師完成基于Linux的系統(tǒng)認證過程。

?

這意味著，有必要對每個基于Linux的Safety關鍵的系統(tǒng)進行特定的分析。 當然，隨著時間的推移，將會出現某些模式，并且在Safety關鍵型系統(tǒng)中使用Linux會變得更加容易。但是，盡管如此，如此復雜的操作系統(tǒng)在任何當前和將來都無法抵御在當前應用和未來應用程序中所有可信任的故障。

?

目標2：

為Safety關鍵型應用程序提供最小的運行時環(huán)境，最高級別達到SIL2。

?

常見誤解：一個完整的發(fā)行版，比如可用的Debian, Yocto。

?

不行的是，運行一個完整發(fā)行版是不行的（就此而言，這很實用），因為發(fā)行版中所有軟件包的代碼庫都太大了。

?

因此，SIL2LinuxMP項目僅限于Linux內核，最少的標準庫集和最小的運行時環(huán)境（基于busybox）。 盡管有些人可能仍然希望獲得SIL2認證的Android或基于Yocto的系統(tǒng)，包括圖形堆棧和所有其他東西，這當然不是我們的目標。

?

正在考慮將SIL0的Container放在整個關鍵混合的系統(tǒng)中。 盡管這將允許更多非Safety的功能并行運行，但它也不會提供沒有任何限制的完整Linux發(fā)行版。

?

SIL2LinuxMP的方法是將那些軟件元素保留在可以執(zhí)行各種非Safety應用程序的QM / SIL0 Container中（請參見圖3），并將對Safety關鍵的應用程序保持在最低限度。 使用Linux內核中的隔離機制完成混合關鍵性的應用程序的集成，稍后在第3章C小節(jié)中討論。

?

復雜性增加的含義

正如引言中已經提到的，許多行業(yè)的復雜性正在顯著增加。 這種復雜性的提高是由為不久將來開發(fā)的應用程序驅動的。 我們從這些預期的應用程序中得出了許多含義，這些含義對系統(tǒng)的非功能特性具有重大影響。

?

計算性能

這些高度復雜的應用程序對性能的要求比傳統(tǒng)系統(tǒng)要高得多。 這不僅意味著更高的功耗[3]，而且還意味著需要使用迄今為止尚未在工業(yè)應用中使用的CPU，例如在服務器中使用的CPU，否則將無法提供必要的性能。

并發(fā)計算能力

性能要求不僅是對最先進處理器的需求，也要求操作系統(tǒng)能夠管理此類多核CPU，并能夠利用盡可能多的性能增強功能。

Security

另一個所有行業(yè)通用的需求是系統(tǒng)需要和外部世界互聯，通常是通過互聯網。這不可避免的導致Security問題。

?

盡管SIL2LinuxMP并不專注于Security，但該項目設定了自己的目標去檢查體系架構上每個設計決策，以確保設計與一般應用程序的Security概念不沖突。

?

由于Linux多年來一直用于高性能以及對Security要求很高的應用程序中，因此它成了即將出現的高復雜度應用程序計算平臺的主要考慮對象。因為它提供了一系列的機制，在提供出色的Security功能（保護和監(jiān)控）的同時，能夠最優(yōu)地利用現有資源。

?

但是，到目前為止，Linux在Safety關鍵系統(tǒng)的使用僅限于某些特殊的情況[4][5]。即使在過去進行過討論[6]，也無法使用通用的方法來驗證未修改的主線內核。為了縮小這個差距，所以啟動了SIL2LinuxMP項目，能夠使未來的應用程序運行在基于Linux的計算平臺上，同時滿足性能和Safety的要求。

?

預期研究的問題

本章節(jié)總結了我們從項目開始就預期研究的問題。這并不意味著解決方案都是完全明確的，只是在原則上認識到如何解決這些問題的概念。

?

A.從實現到選擇

SIL2LinuxMP平臺與常用方法之間的主要區(qū)別在于，基本軟件元素是尚未進行專門開發(fā)的預存在的軟件。

?

這意味著在生命周期中沒有消除故障的措施，意思是著重于減輕故障是從根本上錯誤的系統(tǒng)Safety方法。

?

因此，通過調整Safety生命周期來減輕此缺陷。 具體來說，V模型分為兩部分，上部是系統(tǒng)規(guī)范和架構。此部分是為該特定系統(tǒng)開發(fā)的，因此可以按照IEC 61508 [2]中定義的常規(guī)路線1S開發(fā)來完成。底部通常是設計，開發(fā)和集成專用軟件。 由于使用了預先存在的軟件，因此該底部由軟件選擇過程代替，如圖1所示。

這種經過調整的生命周期模型描述了元素選擇的工作流程。 根據元素的不同，可能的選擇項也有所不同。 對于SIL2LinuxMP項目中的元素，可以選擇以下變量：

• 內核版本

大概每兩個月發(fā)布一個新的穩(wěn)定的Linux內核版本。此外，大概每一年，這些穩(wěn)定版本的其中一個版本作為一個長期穩(wěn)定（long-term stable LTS）的版本發(fā)布。并非每個版本都像其他版本一樣穩(wěn)定，因此SIL2LinuxMP項目選擇過程的一個重要部分是選擇穩(wěn)定的內核（有關如何使用開發(fā)數據來識別穩(wěn)定版本的詳細信息，請參見第3章D小節(jié)）。這個內核是長期支持并且在非常廣泛的上地下文環(huán)境中使用的穩(wěn)定內核（例如，使用主要發(fā)行版本），因此經過了充分的測試。

• 內核配置

SIL2LinuxMP項目的目標不是提供一個認證的完整內核然后進行配置，而是建立一個對特定配置進行認證的框架。假設此配置被簡化為以下功能：

1. 應用程序滿足功能或非功能需求需要的功能，而它們的選擇受各個候選項的成熟度和質量驅動。

2. 事實標準的功能，即沒有該配置的內核配置與正在使用的其他內核配置相差甚遠。

因此，內核的配置還允許某些子系統(tǒng)的選擇基于某些標準，諸如其開發(fā)歷史，設計的新穎性，大小和已知的bug率。

• 非內核元素

除了內核，其他預存在的元素也會被用到，比如C函數庫和math函數庫。通常，這些庫有不同的變體。對這些非內核元素，開始的時候都會選擇已經被廣泛使用的那些變體。此選擇還可以包括部署的寬度和開發(fā)的活動。 使用僅部署在少數系統(tǒng)中并且?guī)啄晡淳S護的C庫沒有任何意義。這個選擇的標準也用在內核版本的選擇中。一個積極健康的項目必須考慮廣泛而活躍的社區(qū)這個優(yōu)勢。

?

B.適配方法

在很多Safety相關的項目中，一個爭論點是量身定制方法還是論證一個全新的方法。SIL2LinuxMP項目概述了預存在軟件的選擇過程，不僅需要考慮軟件本身（即源代碼），而且需要調查開發(fā)預存在軟件的開發(fā)環(huán)境，包括開發(fā)過程中所使用到的所有工具。需要調查分析工具（如果有）對Safety的貢獻。

?

此外，復雜性的增長要求將不適合此類應用的方法替換為可以處理這種復雜性的最新方法。 不幸的是，標準建議的方法（例如IEC 61508[2]）大部分都是過時的，需要討論適當的替代方法。

?

最后，使用預存在方法的應用程序也改變了已有方法的屬性，比如，回顧預存在元素的規(guī)范中不能提供在附件C提到的措施和技術實現中提出的建議即61508-3 Table C.1 “擺脫固有規(guī)范的錯誤…”。

?

因此，定制或新引入方法列表非常重要。我們認為這是一種很好的做法，不是嘗試論證各種方法，而是應該建立一個系統(tǒng)的過程，不僅允許論證定制的方法，也允許對新方法進行論證。而且表明使用新方法和已有方法的組合可以滿足ICE 61508[2]關于覆蓋性的初衷。

圖2概括了定制方法的工作流程。黑色虛線表示從當前方法過渡到新的或定制的方法。

?

所采用的方法（圖2區(qū)域（1）中的紅色路徑）是對IEC 61508-7中的基本原理進行逆向工程，以便找出原始設計意圖。然后使用IEC 61508-3附錄C檢索該方法對系統(tǒng)開發(fā)有貢獻的屬性。 接著評估新引入（或定制）方法對這些屬性的貢獻。

?

接下來（跟隨圖2中區(qū)域（2）中的綠色路徑），將新方法對特性的貢獻與原始方法的貢獻進行比較。請注意，此時可以使用多種新方法來代替原始方法。如果是這種情況，至少在半定量水平上將所有（相關）新方法的貢獻與原始方法的貢獻進行比較。

?

最后一步（跟隨圖2中區(qū)域（3）中的藍色路徑），在新方法和原始方法對特性的貢獻之間進行差距分析，并在必要時調整方法集以彌補這些差距。直到所有的范圍都被覆蓋，這個迭代過程才算完成。

?

C.隔離特性

隔離機制是Linux內核廣泛使用的關鍵功能之一。以前，它們主要用于具有Security意識的系統(tǒng)中。但是如今，隨著Container技術的興起，由于Container技術能夠簡化系統(tǒng)部署，系統(tǒng)管理和應用程序開發(fā)，這些隔離機制實際上已在每個運行的系統(tǒng)中使用。這些隔離機制用于構建與系統(tǒng)其它部分隔離的Container，為了確保所包含的應用程序的故障獨立于核心系統(tǒng)，從而限制Security漏洞對容器的影響，并確保不相關的應用程序不會彼此崩潰導致核心系統(tǒng)崩潰。

?

多個獨立設計的隔離和保護機制建立了一個分層的隔離體系結構。圖3說明了如何使用多層保護隔離混合臨界的獨立應用程序。

值得注意的是，在SIL2LinuxMP中使用這些隔離屬性有以下兩個邊界：

• 實現獨立應用程序（具有不同重要性）之間的隔離

• 確保遵守由危害分析結果指定的API約束（請參閱第4章B小節(jié)）

這聽起來很吸引人，不用擔心不相關的應用程序甚至是具有混合關鍵性的應用程序之間的相互依賴性，但是調查Safety可用性的問題時出現的老問題一直是如何驗證這是足夠Safe，并且允許應用程序獨立發(fā)生故障的隔離屬性值得信賴。

?

在這種特殊情況下，人們意識到這是一個工業(yè)過程中眾所周知的類似的問題，該問題由Audrey Canning提出。

?

然而進一步關注的是后果是否可能如此嚴重以至于不應考慮危險情況的發(fā)生頻率，因此在選擇適當的實施技術時就忽略了“風險”的概念。為了解決這一問題，IEC 61511正式確立了“保護層”的概念，要求不同層之間具有多樣性。[7]

?

這種特殊情況也相似。到目前為止，由于危險情況的發(fā)生頻率無法評估，因此無法評估風險，至少不能以一個合理的工作量進行評估。因此，我們的解決方案依賴于保護層分析（layers of protection Analysis, LOPA）的基礎，目的是為每種危害分配多層保護。只有在所有保護層同時失效的情況下，危險情況（通常已經非常不可能）才會被發(fā)現。使發(fā)生危險情況的可能性更小-可以說極不可能。

?

為了采用LOPA并如實得出上述結論，隔離機制滿足獨立保護層（independent protection layer, IPL）的基本屬性，請參見 [8，第1.3節(jié)]。

• 獨立性

僅當保護層彼此足夠獨立時，LOPA才能進行正確的風險評估。如果目標是物理隔離，那么軟件可能是有問題的。因此，重點轉向了邏輯隔離。

• 高效率性

需要確保的是，即使發(fā)生危險，該層的功能也可以保護或減輕所研究的后果并起作用。每個保護層都應自行提供足夠的保護或緩沖措施，多層的使用旨在為論證或分析各個層的弱點增加一個額外的Safety網絡。這并不是說，開發(fā)人員可以不進行分析，而僅指完全無法獲得確切的失敗頻率或者存在不確定性過高而無法進行正確論證的情況。

• 可審核性

應該可以檢查IPL的設計和開發(fā)以及IPL本身，以確保各個IPL的Safety。由于SIL2LinuxMP項目僅使用自由開源軟件（FLOSS），根據大量的文檔和開發(fā)歷史記錄（修訂控制系統(tǒng)，郵件列表，錯誤報告等），因此IPL本身的源代碼可用于分析。

?

通過執(zhí)行此LOPA，我們展示了隔離機制足以為在基于Linux的共享系統(tǒng)上運行的不同應用程序提供適當的邏輯隔離。

?

D.統(tǒng)計模型

傳統(tǒng)式，Safety關鍵的軟件開發(fā)在相關標準的指導下遵循嚴格的開發(fā)流程。假設是，此嚴格的開發(fā)過程會導致殘留的bug率達到目標SIL級別。或者我們可以問這樣一個問題：“什么過程負責軟件bug的存在？”。我們期望使用SIL2LinuxMP中的統(tǒng)計方法來回答這個問題。換句話說，我們的目標是提供有關在開發(fā)生命周期活動中由隨機過程（人）引入的故障統(tǒng)計報表。

?

不足為奇的是，傳統(tǒng)的與Safety相關的系統(tǒng)由于軟件規(guī)模小和迭代式重新設計的統(tǒng)計數量少，因此無法量化軟件中的系統(tǒng)故障。取而代之的是，考慮定性的防御和更深入的分析。從本質上講，可以采取多種方法，由合格的工程師團隊應用這些方法，并將其全部打包到一個受控過程中，過程指標可以用作賦予軟件元素系統(tǒng)能力的指標。

?

如果有足夠的跟蹤數據和開發(fā)元數據可用于此類預先存在的元素，我們可以通過不合規(guī)開發(fā)的間接指標統(tǒng)計推斷出足夠的過程合規(guī)性。圖4描述了這個基本模型。

構建高度復雜軟件（比如Linux內核）的過程合規(guī)性，需要兩步：

1. 建立強制性活動的原則，本質上這就是IEC 61508-3 第二版7.4.2.13 a-i中的3S路由編碼。

2. 基于過程元數據的統(tǒng)計分析，建立這些方法的實際有效性。

Linux內核開發(fā)者定義了一個相當嚴格的開發(fā)過程[9]，原則上可以滿足IEC 61508 第二版第3部分中提出的結構化和管理過程的大多數要求。但是很明顯，該FLOSS項目缺乏Safety管理結構，無法對應用方法論提出任何特殊要求，即使是嚴格的R1（詳見IEC 61508-3 Ed 2 Annex C.1.1）。

R1：沒有客觀的接受標準或客觀接受標準有限。比如基于判斷和現場試驗的黑盒測試。

?

似乎要求很少。如果我們從統(tǒng)計學上在要求的活動和有效發(fā)現之間建立明確的聯系，則可以確立實現IEC 61508目標原則的總體主張。具體來說，第7.4節(jié)的第5個目標在這里得到解決[2，Part3，7.4]。

本條款要求的第5個目標是驗證Safety相關軟件的需求（就所需的軟件Safety功能和軟件系統(tǒng)能力而言）已經達成。

?

這種預測模型是對假定的穩(wěn)定的基礎發(fā)展過程的評估，而不是評估特定版本本身中的系統(tǒng)故障。為此，我們對內核DLC的連續(xù)周期進行建模，并推斷出整個內核以及特定配置的連續(xù)性和改進趨勢。本質上講，使用在Linux內核的開發(fā)跟蹤數據上引導的負二項式回歸模型，對長期穩(wěn)定的內核穩(wěn)定版本進行回歸分析。

通過分析圖6中的在選定的內核功能集中應用的補丁的特定功能的分析，分別基于圖5所示的基于穩(wěn)定內核補丁的開發(fā)進行建模，可以估計內核中的剩余bug以及對過程健壯性進行總體判斷。這種模型的目的并不是要暗示我們知道內核中尚未發(fā)現的錯誤數量，而是判斷開發(fā)過程是否完美，并且同樣重要的，是否可以在Safety生命周期中管理所報告的bug率。

目前來看，從目前仍然十分有限的根本原因分析數據集中，也就是分析穩(wěn)定內核中的錯誤bug的數據，我們估計不超過1/30的Safety相關的bug是跟我們的特定用例相關的，因此可預估的bug數量是可控的。不過，回歸假設錯誤是在現場發(fā)現的，因此是通過與時間相關的過程來發(fā)現的。自然，并非所有錯誤都如此。最近出現的融化和頻譜錯誤導致對關鍵內核非常重要的更新，表明此類預測有其局限性。然而，這是對潛在影響的首次量化，因此這是選擇特定內核版本和配置選擇的重要指標。

?

意料之外的麻煩

?

上述我們展示的問題一開始就知道了，這里還有些問題在SIL2LinuxMP項目開始的時候我們并沒有認識到。

?

A．影響分析

在討論過程經常提到的一個問題是如何計劃認證一個1900萬行代碼的操作系統(tǒng)。答案很簡單：這從來都不是一個計劃。如第3章A小節(jié)提到的那樣，配置項的選擇是Safety開發(fā)生命周期的一部分。從本質上講，選擇不僅是消除故障并最大程度地減少殘留bug的步驟，并且還是可以大大減少代碼量的步驟。

?

Linux內核配置要確保僅實際使用一部分實際上的代碼庫。除此之外，最終完成的所有分析（例如第3章D小節(jié)展示的統(tǒng)計模型）都應將其考慮重點放在那些對特定配置有影響的提交上。

?

為了做到這一點，SIL2LinuxMP項目使用了在項目中開發(fā)的兩個工具。

• minimization[10]工具是由Hitachi在SIL2LinuxMP項目中開發(fā)的。它允許基于內核配置生成代碼庫，其中所有未使用的代碼都基于用于配置的C宏進行剝離。

• patch impact tester(PIT)工具仍在開發(fā)當中，但是結果很樂觀。與minimization工具相比，它不適用于單個版本的內核，而是測試給定補丁對給定配置是否有影響。這樣，可以保存各個變更的開發(fā)數據，并減少了必須考慮的提交次數。

盡管這個問題乍看之下并不重要，但在很多情況下，這并不是一個簡單的問題。

?

PIT本身是基于GCC插件開發(fā)的。這個插件編譯內核和配置的時候會用到。這個插件收集的信息會存在數據庫中，可以用來檢查一個給定的補丁包是否對配置有影響。

B.HD3-危害驅動的解耦，設計和開發(fā)

盡管SIL2LinuxMP項目中考慮的用例的復雜性遠低于預期的未來應用程序的復雜性，比如，自動駕駛，在危害分析過程中，很明顯，這種復雜性用傳統(tǒng)危害分析方法無法控制的。由于這個原因，研究了一種基于危害和可操作性研究（hazaRD and operability study, HAZOP）的新的方法。這種新的方法叫做危害驅動的解耦，設計和開發(fā)（Decomposition, Design, Development, HD3）。

?

HD3的主要前提是系統(tǒng)的設計應由確定的危險驅動。這個想法是將危害作為設計輸入，并在可能的地方在設計級別消除危害。這樣，減少了對緩解機制的需求，從而防止不必要地增加系統(tǒng)復雜性。

?

HD3的一般過程是從系統(tǒng)的基本功能開始。在SIL2LinuxMP用例中，這是“測量水質”?；诖嘶竟δ埽贸隽伺c技術無關的過程。換句話說，這個過程就像是有生化學家在實驗室中完成的一樣。然后，對該技術無關的過程進行第一次危害分析。傳統(tǒng)的HAZOP在與技術無關的過程中進行，從高度抽象的層面揭示了危害。對于每個層級的分析，消除條件和緩解能力以Safety應用程序條件（Safety Application condition, SAC）的形式記錄下來。然后將這些SAC合并到一組派生項中-仍在技術無關的級別。

?

技術無關的危害分析結果將用作技術意識設計的輸入，同時仍保持技術不確定性。意思是，設計一個自動系統(tǒng)，分配不確定的設備（馬達，泵，閥，傳感器等）去執(zhí)行由生化學家在技術無關過程中執(zhí)行的動作。在這個級別，不會分配特定的設備（比如，僅使用“泵”而不知道它是隔膜泵，徑向泵，蠕動泵等）。

?

這種技術意識非特定設計作為另一輪危害分析的輸入。第二輪災害分析的結果用作使用特定設備的技術意識設計輸入。最重要的是，基于更高抽象層的危害，可以選擇特定的Safety設備識別大量的故障。這留下了有限的（理想情況下是最小化的）危害，這些危險無法通過這種方式消除。僅對于此有限的集合，必須將緩解機制引入系統(tǒng)設計中，以確保較低的故障殘余概率。

?

緩解機制的分配可以是跟Safety相關的應用程序，也可以是非特定元素的非特定級別（參見LOPA）。

?

第二輪危害分析的結果用作第三層危害分析的輸入。在第三層，將未指定的設備替換為選擇的特定的設備。

?

最重要的是要注意，HD3方法接著使用派生需求的中間層來完成，這些中間層對于下一層設計需要的危害信息是必須的。

?

此外，每層危害分析都會產出Safety應用條件（SAC）。系統(tǒng)必須滿足這些條件。HD3方法導致SAC也是分層的，SAC會從更高的抽象映射到更細粒度的SAC。比如，在技術無關的幾倍，SAC是這樣描述的：“關鍵數據寫入后必須驗證”。在技術無關的級別后要進行改進。在非特定的技術意識級別，是這樣描述的：“灰通道存儲介質”。在特定的技術意識級別變成了“寫入的數據必須可以回讀”，“各個測量值應加蓋時間戳”，“存儲的每個測量數據時候都應該加CRC校驗”。

這個簡單的示例說明了如何在各種抽象級別上進行危害分析時完善SAC。要求的API清單情況也類似。在這個例子中沒有看到的是SAC和所使用的API調用作為結果的一部分包括：

• 參數受限的API調用的最小集

• 約束的最大集

因此，需要進行分析減少功能子集。這樣就可以以最小的投入對軟件組件的復雜性進行分析。

?

由于技術的創(chuàng)新性，HD3的使用經驗仍然有限。但是從初步成果來看是很有希望的。從高層設計到實現對SIL2LinuxMP用例進行全面分析是可能的。對這種級別的復雜度，傳統(tǒng)的危害分析方法也許是可行的，但是根據我們的經驗，投入的工作量比HD3要大的多。更重要的是，要兌現“先消除再緩解”這一重要原則，是不可能做到的。

?

結論

?

盡管在SIL2LinuxMP項目開始的前三年并沒有完成SIL2認證平臺這個目標，部分原因是因為沒有認證的多核CPU，但是證明了這個并非遙不可及，特別是對于我們的主要調查主題-Linux內核。

?

以上各章節(jié)介紹了在Safety生命周期的各個部分所取得的進展。這個項目的最大問題是尋找解決復雜性的方法。這個目標可以使用HD3（第3章B小節(jié)介紹）進行危害分析和系統(tǒng)設計來達成。其次，軟件LOPA（第3章C小節(jié)）論證了對重要性相同和不同的應用程序進行分區(qū)并進行單獨處理。最后，影響分析，如在第4章節(jié)A小節(jié)描述的那樣，允許將Linux內核代碼庫自動縮減為對使用的特定配置有直接影響的那些代碼行，因此其他部分可以忽略從而降低工作量。

?

對于重用那些已經存在的開源元素，最重要的步驟是從傳統(tǒng)的軟件開發(fā)V模型過度到第3章A小節(jié)介紹的選擇過程，以及第3張B小節(jié)討論的論證新方法使用和量身定制已有方法的系統(tǒng)過程。

?

簡而言之，SIL2LinuxMP項目的總體進展是，作者有信心通過完成這些概述的活動實現目標。

?

致謝

SIL2LinuxMP項目由開源自動化開發(fā)實驗室（OSADL）管理以及SIL2LinuxMP合作伙伴公司參與。感謝他們的支持和贊助。

參考文檔

[1] OSADL, SIL2LinuxMP Webpage, www.osadl.org/SIL2LinuxMP…, 2016

[2] IEC 61508 Edition2, Functional Safety of electrical/electronic/programmable electronic Safety-related systemsIEC,2010

[3] Bloomberg, Driverless Cars Giving Engineers a Fuel Economy Headache,www.bloomberg.com/news/articl… 2017

[4] Andreas Gerstinger, Heinz Kantz and Christoph Scherrer, TAS Control Platform: A Platform for Safety-Critical Railway Applications, publik.tuwien.ac.at/files/PubDa… 167529.pdf

[5] Peter SieveRDing and Detlef John, SICAS ECC – die Platform fr Siemens-ESTW fr den Nahverkehr, Signal und Draht, May 2008

[6] CSE International Limited for the Health and Safety Executive, RESEARCH REPORT 011: Preliminary assessment of Linux for Safety related systems, 2002

[7] Audrey Canning, Functional Safety: Where have we come from? Where are we going? in Proceedings of the Twenty-fifth Safety-critical Systems Symposium, Briston, UK, 2017

[8] Guidelines for Initiating Events and Independent Protection Layers in Layer of Protection Analysis, Center for Chemical Process Safety (CCPS), 2015, Published by Wiley&Sons

[9] A guide to the Kernel Development Process, www.kernel.org/doc/html/la…, 2018

[10] GIT Repository of the Minimization Tool, github.com/Hitachi-Ind… RD/minimization, 2017

原文作者：Andreas Platschek /?Nicholas Mc Guire /?Lukas Bulwahn?

本文譯者：王紅燕?-?Elektrobit中國團隊的專家

相關產品：

Elektrobit提供車規(guī)級高性能操作系統(tǒng)產品——EB corbos Linux。EB corbos Linux是面向汽車工業(yè)的基于容器的Linux分發(fā)版。容器概念解決了“不同應用程序之間的依賴性管理”這一主要難題，為客戶擴展提供了可變性，并能夠實現有效的維護。為了滿足較高的安全性和可靠性要求，EB corbos Linux可配備一個硬化Linux內核和根文件系統(tǒng)，用來確保所有階段的系統(tǒng)完整性。此外，EB corbos Linux還可為各種CPU供應商集成板級支持包和特定補丁。訪問官網獲得更多產品技術詳情：https://www.elektrobit.cn/products/ecu/eb-corbos/linux/