詳解功能安全概念階段
2021年7月16日 10:19瀏覽：2751
來源 | 汽車ECU開發
“當我們展望未來新技術的挑戰時，采用統一的開發和應用標準至關重要?！?— 通用汽車副總裁 Ken Kelzer， 2018。
在諸多的標準與規范中，ISO 26262（汽車功能安全標準），繼承自 IEC 61508（通用電子電氣功能安全標準），定義了針對汽車工業的安全（Safety）相關組件的國際標準。簡單的說，ISO 26262通過指導與規范化的形式，對汽車電子產品，從概念階段到最后的產品報廢階段，提出了標準化的要求。更進一步的是，ISO 26262細化了如何控制一個汽車電子產品或組件的人身傷害風險在可接受的范圍，及文檔化整個分析、設計、開發、測試及生產過程。
ISO 26262的歷史可以追溯到2011年，第一版的ISO 26262標準發布。第一版標準包含10個部分:
Part 2: 功能安全管理（Management of functional safety）
Part 3: 概念階段（Concept phase）
Part 4: 系統級的產品開發（Product development at system level）
Part 5: 硬件級的產品開發（Product development at hardware level）
Part 6: 軟件級的產品開發（Product development at software level）
Part 7: 生產，運營（Production and operation）
Part 8: 支持過程（Supporting processes）
Part 9: 面向ASIL及面向安全的分析（Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyes）
Part 10: ISO 26262指南（Guidelines on ISO 26262）
相對于2011版的ISO 26262，發布于2018年的第二版標準修改了Part 7的名字為：
Part 7: 生產，運營，維護及報廢（Production, operation, service and decommissioning）
Part 11: 半導體廠商應用ISO 26262的指南（Guidelines on application of ISO 26262 to semiconductors）
Part 12: 適用于摩托車的ISO 26262（Adaptation of ISO 26262 for motorcycles）
在ISO 26262的Part 3中，介紹在產品開發的早期階段的活動及用于保障功能安全的開發流程。這個部分包含了相關項的定義（Item Definition），危害分析與風險評估（Hazard Analysis and Risk Assessment）的內容。本文將從基本概念出發，介紹ISO 26262 : 2018 Part 3相關的流程，分析方法及相關技術。
ISO 26262中的概念眾多（2018版185個），無法在一篇文章中一一描述，所以在本節中，只針對Part 3中涉及到的重要概念進行解釋說明。其中可以涉及到到的其它名詞，都符上英文名詞，便于在標準中查找。
1.1 相關項定義（Item Definition）
Part 3的第一個活動是相關項定義（Item Definition）。相關項定義對于應用ISO 26262到產品中非常重要，參與到產品開發人員和咨詢人員需要對產品有深入的了解，而相關項定義則提供了理解產品所必需的信息。相關項（Item）在標準的Part 1中定義如下：
應用了ISO 26262開發標準，實現了整車級的某個功能或者某個功能的一部分的系統或者系統的組合（System or Combination of Systems）
而相關項定義（Item Definition）是為了描述清楚：
相關項（Item）的功能，依賴關系，與駕駛員、周圍環境以及其它整車級相關項的交互關系
提供足夠的信息用于理解相關項（Item），以便于后續過程中的活動能夠執行
一個相關項（Item）可以分解為1個或多個系統（System），并向外提供1個或多個功能（Function）。系統可以由多個子系統（Sub-system）構成，也可以分解為多個組件（Component）。構成一個系統或子系統的組件至少是3個：負責輸入信號的傳感器（Sensor），負責信號處理及邏輯控制的控制器（Controller）及負責輸出的驅動器（Actuator）。一個組件（Component）可以由1個或多個軟件單元（Software Unit）或1個或多個硬件（Hardware Part）構成。下圖給出了這些概念的邏輯關系：
1.3 危害分析與風險識別（Hazard Analysis & Risk Assessment）
危害分析與風險識別（以下簡稱HA & RA）的主要目的在于以下2個方面：
識別危害與危害事件（Hazard and Hazardous Event），相關項的異常行為會導致這些危害事件
為預防與緩解識別出來的危害事件，推導出相應安全目標（Safety Goal）及其ASIL評級，來避免不合理的風險
ISO 26262:2011中，HA & RA的輸入主要是相關項定義（Item Definition） 和 影響分析（Impact Analysis）。影響分析指出了2種可能的進入HA & RA的初始條件：
從產品的Idea和期望的功能開始，把相關項視為全新開發而進行HA & RA
由于產品本身的功能修改或者運行環境變化，從影響分析（Impact Analysis）開始進行HA & RA
從2018版開始，關于影響分析的部分被劃分到Part 2 功能安全管理中，因此在2018版中，只有相關項定義作為HA & RA的輸入。
相關項定義的過程中，已經考慮了產品的功能、性能及可能的失效帶來的后果（如已知的失效模式），但并沒有這些需求進行分類。通過HA & RA識別產品的安全目標，將這部分需求同產品自身功能區別開，納入功能安全管理的流程（如下圖所示）。因此，HA & RA對于產品的后續開發活動有重要的意義。
1.4 危害與危害事件（Hazard and Hazardous Event）
危害（Hazard） 是指由于產品功能的失效，作為潛在的原因，會導致發生人身傷害。但這種危害只是一種可能性，把危害和危害發生的場景（Operation Situation） 結合起來，形成危害事件（Hazardous Event），才能對其進行分級（如，可接受或不可接受）。對危害事件的分級主要考慮以下3個方面：嚴重度（Severity），暴露度（Exposure）和可控度（Controllability）。在HA & RA過程中，分別對這3個方面進行打分：嚴重度（0 - 3，傷害的嚴重程度逐漸增加），暴露度（0 - 4，暴露在危險環境中的程度逐漸增加），可控度（0 - 3，危害發生時的可控度逐漸降低）。這3個數值中，經過評估任一數值取值為0，或者相加后的數值小于7，則認為這個危害事件的風險可接受，即相關的功能開發按照QM管理即可；但如果相加的數值大于等于7，則認為風險不可接受，對這個危害事件要分配 ASIL（Automotive Safety Integrity Level） 等級。ASIL分為4個等級，分別對應相加數值的7，8，9和10。ASIL與嚴重度、暴露度和可控度的對應關系可以參考下表：
對于識別出的危害事件，進行細致的分析，并制定安全目標（Safety Goal）。安全目標在功能安全產品開發中，處于最上層的需求。安全目標與危害事件之間，可以是1:N或N:1（N大于等于1）的關系。安全目標可以用自然語言的形式來描述，通常是如下的模式化形式：
避免（Avoid to），如，避免近光燈非預期的熄滅
阻止（Prevent to），如，阻止安全相關提示信息在2秒內關閉
應該（Should），如，收到胎壓不足的警告信號后，胎壓不足警告燈應該亮起
每個安全目標都有對應的ASIL評級，安全目標的ASIL等級取決于與之相關聯的風險事件的最高ASIL等級。可以為每個安全目標分配故障響應時間間隔（Fault Tolerance Time Interval），用以規定檢測違反安全目標的故障和安全機制響應時間的最大間隔。安全目標可以用如下的表格的形式表示：
1.6 功能安全需求（Functional Safety Requirement）
功能安全需求（Functional Safety Requirement，FSR）派生自安全目標，一個安全目標至少派生一條功能安全需求。派生出的功能安全需求有無歧義，可理解，無矛盾，可實現及可測試等要求。派生的過程中，功能安全需求獨立于系統的技術架構，還要給功能安全需求分配唯一的ID，當前狀態及對應ASIL等級屬性。下面是一個表格形式的功能安全需求的例子：
1.7 功能安全概念（Functional Safety Concept）
功能安全概念（Functional Safety Concept）是Part 3的最后一個活動。雖然在產品開發尚未進入系統設計階段（Part 4），但此時需要假設一個系統架構（System Architectural Design），因為功能安全概念需要在整車的架構上實現。功能安全概念階段需要描述必要的功能安全需求，并分配這些安全需求到系統的功能要素（Element）上。在ISO 26262中，功能安全概念階段要求達成以下目標：
指定與相關項安全目標相符功能行為（Functional Behavior）或者降級的功能行為（Degraded Functional Behavior）。系統功能的降級是指如果由于故障不能正確的運行，需要系統工作在一個功能或性能受限的狀態。一般系統降級要設計降級的策略，如近光燈系統，降級策略要求至少有一個燈可以工作。
根據安全目標，指定針對合適的手段及時檢測和控制相關的故障的限制條件
在相關項的層面上，設計策略或者措施用來達成要求的容錯能力，或者基于相關項本身、駕駛員或者外部措施以減輕相關故障造成的影響
驗證功能安全概念并指定功能安全確認標準，這里的驗證是指對設計過程的驗證（Verification），主要是檢查設計過程的正確性。
為保障功能安全概念階段的活動能夠正確實施，對應每個活動都有一系列的實施方法。本節對涉及到的一些重要技術手段進行介紹。
為了識別出相關項（Item)及針對相關項（Item）任何的功能開發之前，無論這些涉及到的功能，是否是功能安全相關的，都需要一個合適的出發點。在這里，系統工程（System Engineering）的方法論可以給出一個很有價值的方案。系統工程方法論中，為描述系統對外提供的服務，有一個針對系統上下文（System Context）建模的過程。通過模型化的系統上下文，可以表達出一個系統針對周圍環境直接的影響，還可以得到系統的輸入與輸出信息流（包括數據流與控制流）。在這個階段，在外部與系統交互的是系統參與者（System Actor）。
通常系統工程中對系統建模采用SysML/UML，但系統上下文并沒有作為獨立概念在SysML/UML中存在，因此需要引入一種能夠形象表達系統上下文的方法：SYSMOD。通過SYSMOD，我們就可以在SysML/UML中，以如下的方式定義一個車燈管理系統（Headlight Management System）的上下文：
一個車載系統或相關項，必然要和周邊系統或駕駛員產生交互，它的邊界就是一個非常重要的信息：哪些組件屬于系統元素，哪些位于系統之外？這些信息要在相關項定義這個過程中識別出來（至少是一部分，因為有時項目初期產品的需求并不十分明確）。明確相關項邊界的第一個任務是要明確系統交互的參與者（System Actor）。系統參與者在概念階段應該是清晰的，否則就會陷入一個怪圈：如果系統的開發者對于系統的使用者無法識別清楚，那么該如何正確的建立系統的概念和理解呢？下面有幾個方法可以快速的幫助識別系統的參與者：
系統的參與者應該是使用系統提供的服務或接口，與系統有直接交互的人員
與正在開發的系統有交互的其它系統也應該被列為系統的參與者，并且進行分類，如，傳感器，驅動器，外部系統，或者由于系統的運行，會受到影響的外部環境（光線、溫度等），這些可以幫助我們更好的理解當前開發的系統，更容易的描述其提供的服務
識別出系統的參與者之后，第二個任務要識別出參與者與系統之間的信息流。通過SysML/UML，我們可以建立系統參與者和相關項之間的連接（如使用Connector將2者相連），這表示系統的參與者提供信息流給系統，或者接收從系統提供來的信息流（如從傳感器來的車速信號，或者輸出到屏幕的視頻信號）。同系統的參與者一樣，我們需要在系統開發的早期識別出這些信息流，并用建模的形式把它們識別出來（可以使用SysML中的Information Item來表示，參考系統上下文圖中的黑色三角）。以下幾個方法可以用來識別系統中的信息流：
哪些信息是系統參與者發送給相關項的，如系統上下文中的車輛信號、開關信號
定義完系統的參與者與相應的信息流后，最后一個任務則是它們如何同相關項交互（包括輸入及輸出），即識別出系統的交互點（Interaction Point，系統上下文圖中的帶箭頭的小正方形）。當我們使用Connector建立系統參與者與相關項之間的連接時，Connector與相關項的交點可以認為就是交互點。但這種識別方法不夠精確，需要使用以下方法進行提煉：
需要注意的是，在功能安全概念階段，系統的交互點（Interaction Point）和系統接口（Interface）是不同的：系統交互點在這個階段仍然是個抽象的概念，只用于識別相關項與外部環境之間存在交互；而接口則包含在交互點內，描述相關項對外要求或提供的服務，以及信息流的具體內容。接口的建模在系統設計過程中實施，如ASPICE流程中的SYS.2。
2.3 需求定義技術（Techniques for Specifying Requirements）
概念階段的功能安全需求（Functional Safety Requirement）是后續功能安全開發活動的基礎。產品開發的成功或失敗依賴于功能安全需求的質量，大量的事故可以追溯到有缺陷的需求，如不完整的表述，錯誤的實現以及對不清晰的需求的錯誤理解。ISO 26262中需求可以分為4個等級（但不限于4個，可以根據需要再細分）：功能安全目標，功能安全需求，技術安全需求及硬件/軟件安全需求。好的需求對于產品質量、成本/時間、功能安全的實現及測試都有重要的意義，因此本節對需求的定義技術做一些基本的描述。
需求定義通常由需求工程師進行。大多數成功的項目至少有2名資深的需求工程師，他們協同工作并相互檢查對方的成果。需求開發過程中，最好也有其他的助理工程師加入，因為從組織的角度，需求開發過程中的知識積累需要傳遞給下游的工程活動，并且組織也需要培養更多的需求專家。需求開發要求的工程師技能要求一般包括以下幾點：
需求開發的經驗。沒有什么比經驗更重要，經過多個項目的磨練后，有經驗的工程師可以判斷出哪些該做，哪些不該做。即使沒有成功項目的經驗，那么那些從失敗的錯誤中獲取的經驗也十分重要。
合作。需求工程師幾乎和項目中的所有人員打交道，特別是在敏捷（Agile）開發團隊中，還要和客戶進行面對面的溝通。
傾聽和觀察的技巧。需求工程師應該擅長從系統工程師或客戶處發現細微的線索，用于挖掘缺失的需求。
寫作溝通能力。需求工程師的主要角色是將需求文檔化，那就要求需求工程師能夠清晰有組織的把需求表達出來，即使是一些復雜問題和想法。常用的手段包括圖表化、數據流圖、控制流圖、用例圖或狀態圖等。
領域知識。對于正在開發的產品，需求工程師要具備相應的領域知識，如導航工程師就不是十分適合開發剎車或者燃油系統的需求。
需求的表達方式除了采用MS Office系列（Word，Excel），還可以使用支持SysML的工具進行描述，除了具備直觀的好處之外，還可以和后續的工程活動方便的追溯（見下節）。SysML中增加了需求圖（Requirement Diagram）用于描述系統需求，如下圖所示：
在工具中，每一個需求塊（Block）會分配一個全局唯一的GUID，可以用于標識這個需求。但GUID通常與需求定義時分配的ID不一致且難于理解，因此針對需求塊，SysML還提供了需求ID字段，用于與外部工具建立需求對應關系。另外，為方便在各個需求管理工具之間交換數據，通常會采用CSV格式的表格，通過導入/導出的形式進行數據傳遞。
2.4 追溯性相關技術（Techniques for Traceability）
作為消除系統性故障（Systematic Fault）的重要手段，可追溯性在功能安全相關設計的驗證過程中是重點檢查的內容。可追溯性在系統開發的不同階段表現不同，如用例和需求之間，可以表現為實現關系（Realization）；用例和用例之間，可以表現為包含、擴展（Include, Extend）等關系?？勺匪菪缘谋憩F形式可以有多種：
下圖是一個使用SysML/UML關系圖建立追溯性的例子，在圖中通過手工連接的方式把用例和需求連接起來，優點是圖形比較直觀：
追溯圖的形式能夠同時表達的追溯范圍有限，如果需求和用例較多，追溯圖由于圖中的元素太多，就不容易使用（如，查找是否有需求的遺漏），在這種情況下使用追溯矩陣（Traceability Matrix）就更合適。追溯矩陣可以在工程的全路徑的任意2個連續的環節（如，需求和用例）中間建立直觀的關系矩陣。如下圖所示，圖的橫縱坐標分別表示需求與用例，箭頭則表示實現（Realization）的方向，高亮的行表示需求有遺漏的情況：
建立了雙向追溯之后，需求或者設計發生了變更，就可以通過追溯判定變更的影響范圍。支持Baseline的SysML/UML工具，還可以基于Baseline進行差分。基于Baseline可以很容易的識別出需求和設計中發生了變更的部分，從發生了變更的部分出發，可以追溯到對應的上下游工程中，需要變更的內容，以確保一致性。
2.5 危害識別與分析技術（Techniques for Hazard Identification and Analysis）
常用的危害分析技術有20多種，幾乎覆蓋了包括了：概念，概要設計，詳細設計，測試及運行在內的產品開發的各個階段。從方法論上來說，危害分析技術可以分為2大類：內推法（Inductive）和外推法（Deductive）：
內推法從系統中某個組件的故障出發，自下而上的推導，在整車的級別上產生的影響是否違反功能安全目標
外推法從違反功能安全目標的失效開始，自上而下的推導可能產生這個影響的組件故障
在功能安全概念階段，危害分析的主要目的是保障完整及正確的派生功能安全需求。在ISO 26262:2018, Part 3中提到了3種危害分析方法：FMEA (Failure Mode and Effects Analysis)，HAZOP (Hazard and Operability Analysis) 和FTA (Fault Tree Analysis)。這三種分析方法的分類見下圖：
以下介紹一下FMEA的基本分析技巧。FMEA用于分析系統中的關鍵組件的失效是否會影響功能安全目標，影響功能安全目標的失效是否設計了安全機制，相應的安全機制可以作為功能安全需求而記載到對應的文檔中。FMEA的主要成果物為FMEA Worksheet，下圖是來自于Ford的FMEA Handbook，圖中給出了FMEA的主要的分析過程：
FMEA的輸入有多種，其中比較重要的是功能塊圖（Functional Block Diagram）和參數圖（Parameter Diagram）。功能塊圖簡化了系統設計和支持的服務，在功能安全概念階段可以幫助快速建立對產品的理解。功能塊圖展示了子系統之間的關系和接口，同時也指示了系統所必須提供的功能。下圖給出了系統的功能塊圖的例子：
對于功能塊圖中的任一功能，對其進行危害分析時，需要明確該功能的輸入信號，運行環境，配置信息及期望的和錯誤的輸出。把這些信息整合，可以如下圖所示的參數圖（Parameter Diagram）：
通過對這些參數的分析，可以得出導致某個功能出現故障的基本原因。在后續的分析過程中，針對故障原因，設計合理的檢測和消除機制，可以有效的提升系統的安全性。
本文從ISO 26262:2018，Part 3中的基本概念出發，介紹了該部分涉及到重要概念及開發過程中需要用到的基本技術。在ISO 26262流程中，概念階段（包括功能安全概念和技術安全概念）是最重要的階段，這個階段出現的任何紕漏，都會影響后續的功能安全開發活動。由于ISO 26262采用的是V模型，概念階段變更引起的工作量會十分巨大。本文希望通過一些重要概念的解釋和實用技術的說明，理清功能安全概念的過程，幫助功能安全開發人員，實現正確的功能安全概念。
版權聲明：本文為CSDN博主「coroutines」的原創文章，遵循CC 4.0 BY-SA版權協議，獲作者轉載權限。
技術鄰APP
工程師必備
