摘要：已經開發了幾種方法來幫助汽車系統制造商通過遵守功能安全標準來設計更安全的車輛。然而，這些方法中的大多數要么主要關注汽車系統的技術方面而忽略了社會方面，要么沒有配備足夠的自動化支持。為此，我們提出了一種基于模型的方法來建模和分析汽車系統的功能安全需求(FSR)，該方法基于ISO 26262標準并考慮此類系統的技術和社會方面。該方法提出了一個UML配置文件，用于從項目定義到安全驗證對FSR進行建模，并提出了以OCL表達的約束以用于驗證FSR模型。我們使用汽車領域的一個示例來說明該方法的實用性。

01.簡介

汽車工業是世界上最大的工業之一，每年生產數百萬輛新車供人類日常使用。因此，確保這些車輛的安全一直是制造商日益關注的問題。特別是，汽車系統是安全關鍵系統，除了功能需求外，還必須滿足安全需求，其中安全需求描述了系統必須具備的特性才能確保安全。此外，當前汽車系統在實施功能方面的復雜性顯著增加，這增加了處理其功能安全需求的復雜性。

為了保持可接受的安全水平，已經制定了名為ISO 26262的功能安全標準。ISO 26262為汽車領域提供了適當的開發流程、需求和安全完整性水平。然而，該標準主要涵蓋車輛的電氣和電子(E/E)系統，而駕駛員及其行為不在標準范圍之內，即假定駕駛員可以采取必要的行動來保證安全。但情況并非總是如此，因為駕駛員是許多事故的主要原因，即車輛安全不僅僅是純粹的技術問題。

更具體地說，汽車系統可以看作是一個信息-物理-社會系統(CPSS)，即網絡組件（例如軟件、傳感器）、受控組件（例如車輛、交通信號燈）和社會組件（例如駕駛員）的組合。因此，如果不考慮它們的三個主要組件，就無法確保此類系統的安全性。換句話說，在CPSS設計過程中忽略社會組件會使系統容易受到不同類型的漏洞的影響，因為CPSS的漏洞不僅是由技術（例如網絡和物理）問題產生的，而且還可能由于社會問題而產生。在這種情況下，只有在系統設計過程中也考慮駕駛員行為，才能設計出安全的汽車系統。

研究人員提出了一種基于ISO 26262標準的方法，該方法考慮了E/E系統以及駕駛員的行為，但它沒有配備任何類型的自動化支持。因此，不可能依靠它來手動處理大量危害、功能安全需求(FSR)、安全目標等。為了解決這個問題，我們提出了一種基于模型的方法，并通過以下組件對其進行了擴展：

? 一種工程方法，用于協助設計人員對汽車系統的FSR進行建模和分析。

? 用于建模FSR的UML配置文件，它采用了面向目標的需求工程(GORE)中的社會和組織概念，并將它們與ISO 26262中采用的概念相結合。這允許捕獲汽車系統的網絡、物理和社會方面。

? 允許驗證FSR模型的自動分析支持。更具體地說，已經制定了設計的幾個屬性，表示為對象約束語言(OCL)，以驗證FSR模型的正確性和一致性。

? 允許生成和驗證FSR模型的工具。

本文的其余部分組織如下：第2節介紹研究基線，第3節描述了有關機動輔助系統的說明性示例。在第4節中，我們介紹并討論了我們的方法，并在第5節討論了對其有效性的威脅。相關工作在第6節中介紹，我們在第7節中總結并討論了未來的工作。

02.研究基礎

A. ISO 26262

ISO 26262是一項功能安全標準，適用于所有重量低于3500公斤的道路車輛，其制定的主要目的是提供指導方針和最佳實踐，以提高車輛的安全性。更具體地說，ISO 26262側重于由E/E系統故障引起的危害及其相關風險，然后為每個相關風險分配一個汽車安全完整性等級(ASIL)。ASIL可分為質量管理(QM)、A、B、C或D，其中QM分配給概率非常低的危害，這些危害可能只會造成輕微傷害，并且不需要降低風險。ASIL A、B、C或D需要降低風險，其 ASIL D需要最大的降低風險努力。表1顯示了與產品開發不同階段相關的ISO 26262主要條款。

表1：ISO 26262針對產品開發不同階段的主要條款

B. 通過目標模型對需求進行建模

面向目標的需求工程(GORE)已成為需求工程(RE)的主要方法。在GORE中，目標模型可以作為未來系統的抽象規范。盡管已經引入了幾種基于目標的建模語言（例如KAOS）。Tropos已被證明可以在社會和組織背景下有效地對需求進行建模。Tropos引入了用于對系統參與者（代理實體）和參與者打算實現的目標進行建模的原語。任務代表一種抽象的做事方式，其執行可以成為滿足目標的一種手段。當目標/任務處于高抽象級別時，可以通過和/或分解為更精細的子目標/子任務來進行細化。資源代表物理或信息實體。最后，依賴關系允許參與者相互依賴以實現目標、執行任務和提供資源。

03.示例：機動輔助系統

我們的示例是一個高度自動化的駕駛系統，即機動輔助系統(MAS)，該系統有望通過檢測和防止意外的戰術和運行操作來提高駕駛員的安全性。通常，戰術操作是由駕駛員最近改變的愿望（例如，車道變換）引起的，并且與短期時間尺度（幾十秒）相關，而運行操作通常是駕駛員保持安全的愿望（例如，避免碰撞）的結果，并且與非常短的時間尺度（幾十毫秒）相關。具體而言，MAS收集有關車輛、車輛周圍環境以及駕駛員行為的信息，然后分析這些信息以確定是否有需要和/或希望進行該操作。如果有需要和/或希望進行此類操作，則將其視為有意的。否則，則將其視為非有意的。因此，MAS應允許預期操作并防止意外操作。

04.基于模型的工程功能安全需求方法

在本節中，我們將介紹我們的方法。首先，我們介紹方法論，然后介紹允許對FSR進行建模的UML配置文件，然后討論可用于驗證FSR模型的自動推理支持。最后，我們描述了允許生成和驗證FSR模型的工具。

A. 方法論

我們方法論的基礎流程如圖1所示，它是通過建模和分析活動對其進行了擴展。請注意，P. 和C. 分別代表ISO 26262標準的部分和條款，它們已被用作定義該方法論某些活動的基礎。

圖1.符合ISO 26262的汽車系統FSR建模和分析流程

該流程由兩個主要階段組成，即建模和分析：

1）建模階段旨在從項目定義和建模開始，直到定義安全驗證，對汽車系統的功能安全概念進行建模，它由八項活動組成：

（1）項目定義和建模是該流程的第一項活動，我們在此定義和建模項目以及它旨在實現的主要功能需求。

（2）危害分析和風險評估(HARA)建模，識別并建模可能危及實現每個功能需求的可能危害，這些危害已在上一項活動中確定。然后，對每個危害進行風險評估，根據其嚴重性、暴露和可控性水平為其分配ASIL。之后，與ASIL A、ASIL B、ASIL C或ASIL D級別的每個危害都應通過至少一個安全目標(SG)來解決。

（3）功能安全需求(FSR)建模，從上一項活動中確定的每個SG中得出至少一個FSR。

（4）技術安全需求(TSR)建模，從FSR建?；顒又幸炎R別的每個FSR中定義至少一個TSR。

（5）定義硬件安全需求(HWSR)規范，定義可用于運行可分配給硬件的每個已識別TSR的規范。

（6）定義軟件安全需求(SWSR)規范，定義可用于運行可分配給軟件的每個已識別TSR的規范。

（7）定義社會安全需求(SCSR)規范，定義可用于運行可分配給社會行為的每個已識別TSR的規范。

（8）定義安全驗證，定義已識別HWSR、SWSR和SCSR的驗證和核實的驗收標準。這可以提供證據，證明安全目標可以在車輛級別實現，并且FSR適合項目的功能安全。

2）分析階段旨在根據我們定義并制定為OCL約束的一組設計屬性來驗證FSR模型的正確性和一致性。

B.建模階段

接下來，我們將介紹用于對汽車系統的FSR進行建模的UML配置文件（如圖2所示），然后介紹如何使用它對MAS系統的FSR進行建模。

圖2.用于建模功能安全概念的UML配置文件

我們方法中的項目可以是社交實體，也可以與社交實體交互。因此，我們采用了Tropos中的<<AgentiveElement>>和<<Actor>>概念，提出了兩個具有相同名稱的刻板印象，以捕捉項目的社會方面。<<Actor>>刻板印象具有識別其目標需求的屬性。為了捕捉與項目相關的有意實體，我們遵循Tropos并提出了<<IntentionalElement>>刻板印象，該刻板印象主要用于捕捉項目在其社會和組織背景下的戰略目標/需求。這允許捕捉這些目標/需求的技術方面和社會方面。<<IntentionalElement>>刻板印象分為三個刻板印象：<<Requirement>>、<<SafetyGoal>>和<<OperationalElement>>。

<<Requirement>>構造型進一步細分為三種不同的構造型：

1）<<FunctionalRequirement>>捕獲項目旨在實現的功能，

2）<<FunctionalSafetyRequirement>>捕獲項目的安全功能，但不指定如何實現這些功能，

3）<<TechnicalSafetyRequirement>>捕獲可從FSR定義并可運行的詳細技術需求。

<<SafetyGoal>>構造型已被采用以與ISO 26262標準提供的術語保持一致，并用于定義用于解決<<Hazard>>的安全目標。

<<OperationalElement>> (OE)構造型是基于Tropos中任務的相同想法開發的，并進一步細分為三種構造型<<SHWSR>>、<<SSWSR>>和<<SSCSR>>，分別定義硬件、軟件和社會安全需求的規范。此外，OE刻板印象具有兩個屬性。第一個屬性標識了OE應達到的驗證和確認(V&V)驗收標準，才能被視為已滿足。第二個屬性標識了OE是否已得到滿足。包含這兩個屬性是為了定義每個OE的安全驗證，即定義已識別的HWSR、SWSR和SCSR的確認和驗證的驗收標準，并確定這些標準是否已得到滿足。

<<Hazard>>刻板印象是基于ISO 26262標準中提出的危害概念開發的，它捕獲了可能危及功能需求實現的危害。

<<Hazard>>具有幾個屬性，可用于評估其相關風險：

1）嚴重程度，衡量危害的潛在傷害，范圍從S0到S3，其中S0表示無傷害，S3表示危及生命的傷害；

2）暴露等級，度量產品處于危害事件情形下的暴露概率，范圍從E0到E4，其中E4為最高暴露等級；

3）可控等級，度量產品通過及時反應避免特定傷害的能力，范圍從C0到C3，其中C0表示一般可控，C3表示難以控制或不可控；

4）ASIL等級度量必要的風險降低程度，其等級范圍從QM、ASIL A、ASIL B、ASIL C和ASIL D，其中ASIL D為最高。

在ISO 26262中，ASIL等級根據嚴重性、暴露概率和可控性等級按照表2確定。在S0、E0或C0的情況下，不分配ASIL，并且使用NA作為ASIL等級的值。

表2.根據嚴重性、概率和可控性確定ASIL等級

此外，從<<Dependency>>元類中專門化了幾個構造型，以捕獲前面提到的構造型之間的關系。<<endanger>>構造型捕獲從<<Hazard>>構造型開始的依賴關系并指向<<FunctionalRequirement>>構造型，而<<address>>構造型捕獲從<<SafetyGoal>>構造型開始的依賴關系并指向<<Hazard>>構造型。<<derivedFrom>>構造型捕獲從<<FunctionalSafetyRequirement>>構造型開始的依賴關系并指向<<SafetyGoal>>構造型。<<definedFrom>>構造型捕獲從<<TechnicalSafetyRequirement>>構造型開始的依賴關系并指向<<FunctionalSafetyRequirement>>構造型。最后，<<operationalize>>構造型從<<operationalElement>>構造型開始捕獲依賴關系并指向<<TechnicalSafetyRequirement>>構造型，并且它具有類型屬性（“SHWSR”、“SSWSR”或“SSCSR”）以確保正確的運行化。圖3使用我們的UML配置文件顯示了MAS系統的部分模型。其中，我們可以識別已表示為參與者的項目以及它旨在實現的兩個功能需求（Freq_01和Freq_02）。這兩個功能需求都與每個需求的簡短描述一起表示。按照我們的方法，在對項目及其功能需求進行建模后，我們識別并建?？赡芪＜懊總€功能需求實現的潛在危害。危害H_01和H_02分別危及Freq_01和Freq_02。對于每個已識別的危害，我們都會進行風險評估以分配適當的ASIL級別。H_01和H_02都與ASIL級別C相關聯，因此它們應該通過安全目標來解決，例如，H_01由安全目標SG_01解決。

圖3.應用UML Profile對MAS的功能安全概念進行建模

在該方法的第三項活動中，我們從每個SG中派生出至少一個FSR。從SG_01派生出兩個FSR（FSR_01和FSR_02）。在第四項活動中，我們從每個FSR中定義至少一個TSR。從FSR_02中定義了四個TSR（TSR_01、TSR_02、FSR_03和FSR_04）。滿足完整的TSR集被認為足以確保該項目符合其功能安全概念。因此，TSR應該足夠詳細，以便分配給不同的硬件、軟件和/或社會組件，這分別在活動5、6和7中執行。例如，TSR_02被運行化為SHWSR_01、SSWSR_01和SSCSR_01，分別定義硬件、軟件和社會安全需求的規范。在最后的活動中，我們定義了對已識別的HWSR、SWSR和SCSR的確認和驗證的驗收標準，這有助于確保在車輛級別能夠實現安全目標，并且FSR適合該項目的功能安全。

C.分析階段

我們不能僅依靠模型來執行所需的分析以驗證FSR的正確性和一致性。因此，我們定義了一組以OCL表示的設計屬性（如表3所示），這些屬性指定了保證模型正確性和一致性的邏輯約束。具體來說，這些約束限制了模型元素之間某些關系的存在，強制其他關系的存在，以及評估某些屬性的值。此外，它們還可用于評估模型驗證和確認的標準。如果所有這些屬性都成立，則模型是正確且一致的。而如果其中任何一個被違反（例如，缺少元素或關系、不匹配的關系、無效值等），設計師將收到此類違規通知，這使他/她能夠執行所需的修改來解決問題。

表3.設計特性

接下來，我們給出兩個清單，展示如何在OCL中表達兩個屬性：清單1展示了一個關于Pro 2的OCL，它將任何具有構造型<<address>>的依賴關系的客戶端（源）限制為具有構造型<<SafetyGoal>>的類，并將此類依賴關系的供應商（目的地）限制為具有構造型<<Hazard>>的類。這保證了具有構造型<<address>>的依賴關系只能從具有構造型<<SafetyGoal>>的類指向具有構造型<<Hazard>>的類。

清單1.用于驗證Pro 2的OCL約束

清單2顯示了與Pro 8相關的OCL，它限制了具有與ASIL A-D級別相關的構造型<<Hazard>>的類與構造型<<address>>具有至少一個（大于零）供應商（傳入）依賴關系。這保證了具有與ASIL A-D級別相關的構造型<<Hazard>>的任何類都由至少一個具有構造型<<SafetyGoal>>的類處理。

清單2.用于驗證Pro 8的OCL約束

D.工具支持

我們開發了一個基于Eclipse-Papyrus的工具，它允許設計人員使用我們的UML配置文件提供的各種原型來為汽車系統建模FSR。此外，它還允許設計人員根據表3中所示的設計屬性（OCL約束）驗證FSR模型。如果違反了這些屬性中的任何一個，設計人員將收到違規的確切名稱通知，以便他/她能夠解決該問題。

05.有效性威脅

根據Wohlin等人的研究，我們將有效性威脅分為四類：

1）結構有效性涉及研究測量其聲稱要測量的內容的程度。我們已經確定了一種威脅，即概念化不良：在分析研究主題時考慮的因素很少。為了減輕這種威脅，我們精心選擇了示例，以涵蓋可能影響汽車系統功能安全概念的所有三個主要方面（例如，網絡、物理和社會）。

2）內部有效性涉及研究中未考慮的因素，它們可能會影響所調查的因素。我們的分析集中在我們認為對保證功能安全概念至關重要的三個主要方面。然而，也可能涉及其他我們無法識別的因素。需要進一步分析以驗證我們考慮的方面是否足夠，或識別其他未揭示的方面。

3）外部有效性涉及研究結果可以推廣的程度。我們已經確定了兩個威脅，(i)設計屬性的完整性：我們根據對有關FSR的現有報告和研究的廣泛分析確定了這些屬性。但是，我們計劃與領域專家一起評估它們的完整性。(ii)廣泛評估：該方法僅應用于一個示例，但它涵蓋了許多復雜汽車系統的主要方面。此外，將我們的方法應用于其他汽車系統是我們未來工作的計劃。

4）結論有效性涉及關于實驗處理和結果之間關系的結論的正確程度。我們已經確定了一種威脅，即(i)追求特定結果：我們從項目定義到安全驗證所遵循的流程均基于廣為采用的標準(ISO 26262)，這降低了出現這種威脅的可能性。此外，汽車領域的許多其他研究人員/專家也報告了考慮駕駛員行為的重要性。

06.相關工作

文獻中提出了幾種處理功能安全要求的方法。例如，Giese等人提出了一種方法，可以系統地識別哪些危害/失效最為關鍵、哪些組件需要更詳細的安全分析以及應考慮哪些對失效傳播的限制。Zhang等人介紹了一種基于功能模型的綜合危害分析方法。此外，Li和Zhang提出了一種汽車控制系統的危害分析方法，該方法將安全程序納入傳統開發流程。Basir等人提出了一種采用目標結構符號(GSN)構建安全檔案以將需求追溯到代碼的方法。Habli等人的工作研究了模型驅動的開發和評估如何為系統地生成功能安全需求提供基礎。

Baumgart提出了一種考慮功能安全的整個安全生命周期的方法，特別強調危害分析和風險評估。Palin等人為GSN提供了擴展，其中包含模式和許多安全參數，以幫助研究人員創建符合ISO 26262的安全檔案。此外，還提出了一種根據GSN符號定義功能安全需求的方法，但GSN并未提供專門用于對系統的社會方面進行建模的結構。最后，Beckers等人提出了一種基于模型的汽車系統危害分析和風險評估方法，該方法在ISO 26262的背景下，提供了UML配置文件和幾個以OCL表達的約束來驗證模型。

雖然這些方法中的大多數都提出了提高功能安全性的解決方案，但它們主要關注系統的技術方面而忽略了社會方面。此外，其中許多方法沒有配備足夠的自動化支持，這使得它們不適合處理大量危害、FSR、安全目標等。

07.結論和未來工作

我們提出了一種基于ISO 26262標準開發的基于模型的方法，并考慮了此類系統的技術和社會方面。我們的方法允許在社會和組織背景下對FSR進行建模和分析，通過考慮駕駛員及其在處理FSR時的行為，賦予駕駛員發言權。

對于未來的工作，我們旨在通過整合GORE中的其他社會概念（例如依賴關系概念）來豐富我們的建模語言，該概念允許捕獲系統不同參與者（項目）之間的依賴關系。此外，我們計劃采用和/或分解概念來改進SG、FSR、TSR，并為它們的成就提供替代方案。此外，我們打算聯系同行研究人員，收集他們對該方法的反饋，并旨在通過將其應用于幾個真實案例研究來更好地驗證我們的方法。最后，我們計劃與行業專家一起進行一系列實驗，以評估我們的方法，即它在多大程度上能夠支持用戶對FSR進行建模和分析。

END