一、概念階段的核心框架與開發模型
汽車功能安全概念階段是ISO 26262標準中“Part 3”所規定的關鍵環節，其核心目標是通過系統化的流程定義相關項、分析風險并設計安全方案，為后續的系統開發、硬件與軟件設計奠定基礎。從標準框架來看，概念階段主要包含三個核心活動：相關項定義（Item Definition）、危害分析與風險評估（Hazard Analysis and Risk Assessment, HARA）以及功能安全概念（Functional Safety Concept, FSC）的制定。這些活動貫穿于產品的安全生命周期，是確保車輛功能在異常狀態下仍能避免不合理風險的關鍵。
概念階段的開發模型呈現L型流程走向，具體可分為四個核心步驟。首先，需收集與相關項有關的所有已有信息，包括功能定義、用例描述、產品設計文檔等，通過梳理形成“相關項定義”文檔。這一步是后續所有分析的基礎，其輸出的準確性直接影響風險評估的有效性。其次，基于相關項定義開展HARA活動，該過程需依賴外部輸入，如VDA 702（場景分類標準）、ISO 21448（預期功能安全）等，最終輸出危害分析與風險評估報告。由于HARA的結果將直接決定下游供應商的安全等級要求，因此該環節的評審需滿足最高的獨立性等級（I3），即由不同機構的非利益相關方進行審核，以避免因利益關聯導致的風險誤判。
在HARA活動之后，需結合功能或系統架構設計，將風險評估得出的安全目標轉化為具體的功能安全概念。這一過程的核心是推導功能安全要求（Functional Safety Requirements, FSR），明確系統在故障情況下應采取的安全機制。最后，功能安全概念需經過認可評審與驗證評審，形成驗證報告，確保其符合安全目標且能有效減輕或避免危害。整個流程中，每個環節的輸出都需經過嚴格的文檔管控與評審，以保證開發過程的可追溯性與合規性。
二、相關項定義與功能定義的邊界與關聯
相關項定義（Item Definition）是概念階段的起點，其核心是明確“相關項”的范圍與邊界。根據ISO 26262標準，相關項是指在整車層面實現完整或部分功能的系統或系統組合，例如自適應巡航控制（ACC）、電子穩定程序（ESC）、轉向助力系統等。這些系統直接影響車輛的動態行為，其功能異常可能導致危害事件的發生。與之相對的“要素”（如傳感器、芯片、執行器）則是支持相關項功能的組件，其本身并不直接實現整車功能，因此需以“獨立于環境的安全要素”形式進行開發，無需納入相關項定義的范疇。
相關項定義與功能定義的區別在于，功能定義聚焦于單一功能的具體表現（如轉向助力的扭矩范圍、制動系統的減速度），而相關項定義則從整車視角出發，整合功能與系統間的依賴關系。例如，轉向助力功能的定義可能描述“在車速30km/h時提供5N·m的助力扭矩”，而相關項定義則需說明“轉向助力系統與駕駛員操作、路面摩擦力、ESP系統的交互關系”。這種整合性的描述是后續危害分析的基礎，確保風險評估不遺漏任何系統間的關聯影響。
相關項定義文檔的編制需整合多方面信息，包括但不限于：法規與標準要求（如GB 7258、ISO 26262）、功能用例（Use Case）、預實驗結果、產品設計文檔等。文檔內容需明確以下關鍵信息：相關項的功能目標（如“實現0-130km/h范圍內的自適應巡航”）；與駕駛員的交互方式（如“通過方向盤按鍵激活，儀表顯示當前狀態”）；運行環境限制（如“僅在鋪裝路面、能見度≥50m時可用”）；與其他相關項的依賴關系（如“依賴ESP系統提供的車身穩定信號”）；已知的不安全信息（如“低溫環境下傳感器可能延遲響應”）。這些信息需經過跨部門評審（如產品、安全、測試團隊），確保全面性與準確性。
三、 危害分析與風險評估（HARA）的實施流程
危害分析與風險評估（HARA）是概念階段的核心活動，其目的是識別功能異常可能引發的危害事件，評估風險等級，并確定對應的安全目標。HARA的實施需遵循系統化的流程，確保覆蓋所有潛在風險。
（一）功能異常與危害的識別
功能異常（Malfunctioning Behavior）是指相關項偏離預期功能的表現，可通過HAZOP（危險與可操作性分析）方法識別。HAZOP方法基于“引導詞+功能參數”的組合，系統性地列舉潛在異常，例如針對轉向助力功能，引導詞“過量”與參數“扭矩”組合可得出“轉向助力扭矩過量”，引導詞“丟失”與參數“信號”組合可得出“轉向角信號丟失”。常見的引導詞包括：過量（Excessive）、不足（Insufficient）、丟失（Loss）、反向（Opposite）、非預期激活（Undemanded Activation）、卡滯（Stuck）等。不同功能的異常模式存在差異，例如制動系統的異常可能包括“制動壓力不足”“非預期制動”，而轉向系統則可能包括“轉向角度偏移”“助力突然消失”。
危害（Hazard）是功能異常在整車層面引發的不安全狀態，需結合車輛運動的六個自由度（縱向、橫向、垂直、俯仰、側傾、偏航）分類。例如，縱向方向的危害可能包括“非預期加速”“制動失效”；橫向方向的危害可能包括“非預期轉向”“側滑”。危害的描述需聚焦于整車級后果，而非功能本身的異常，例如“轉向助力過量”是功能異常，而“車輛非預期偏離車道”才是危害。
（二）危害事件的構建
危害事件（Hazardous Event）是“危害+運行場景”的組合，其中運行場景（Operating Situation）需涵蓋環境、道路、交通參與者等要素。運行場景的分類可參考VDA 702（場景目錄）、SAE J2980等標準，典型維度包括：位置（如城市道路、高速公路、停車場）；道路條件（如干燥、濕滑、結冰）；交通狀況（如擁堵、暢通、交叉路口）；車輛狀態（如靜止、加速、轉彎）；環境因素（如光照、能見度、風速）。例如，“城市道路交叉路口處，車輛因制動失效導致追尾前方車輛”即為一個完整的危害事件，其中“制動失效”是危害，“城市道路交叉路口”是運行場景。
在構建危害事件時，需注意場景的“顆粒度”。過于寬泛的場景（如“道路行駛”）會導致風險評估不準確，而過于細化的場景（如“晴天30℃、風速2m/s的城市主干道”）則會增加分析復雜度。企業需根據產品特性定義合適的顆粒度，例如針對自動泊車功能，需重點關注“狹小空間（≤2.5m寬車位）”“障礙物密集區域”等場景。
（三）風險等級的評估
風險等級由暴露度（E）、危害度（S）、可控度（C）三個維度決定，每個維度分為4個等級，最終映射為ASIL等級（A、B、C、D）或QM（質量管理）。
暴露度（E）衡量危害事件所在場景的發生頻率或持續時間，分為E1（極低）至E4（極高）。若危害與場景發生次數相關（如通過交叉路口的次數），則采用頻率維度：E1（每年＜1次）、E2（每年幾次）、E3（每月幾次）、E4（每次駕駛）。若與場景持續時間相關（如高速公路行駛時長），則采用時間占比維度：E1（＜1%）、E2（1%-10%）、E3（10%-30%）、E4（＞30%）。例如，“高速公路巡航”場景的暴露度通常為E3（中等），而“停車場泊車”場景可能為E2（低）。
危害度（S）評估傷害的嚴重程度，參考AIS（損傷嚴重度評分）分為S0（無傷害）至S3（致命傷害）。S0對應AIS 0（無傷害，如輕微刮擦）；S1對應AIS 1-2（輕傷至中度傷害，如皮膚挫傷、單純性骨折）；S2對應AIS 3-4（嚴重但非致命傷害，如顱骨骨折、內臟損傷）；S3對應AIS 5-6（致命傷害，如脊柱斷裂、體腔開放傷）。實際評估中，可結合碰撞速度判斷：例如正面碰撞中，Δv（相對速度）＜10kph通常為S0；10-40kph為S1-S2；＞40kph為S3。不同碰撞類型（正面、側面、追尾）的閾值存在差異，側面碰撞因車身保護較弱，Δv＞20kph即可評為S3。
可控度（C）評估交通參與者規避傷害的能力，分為C0（可控）至C3（不可控）。C0指“超過99%的普通駕駛員可規避傷害”（如低速下的輕微轉向偏移）；C1指“90%-99%的駕駛員可規避”（如高速公路上的車道偏離，駕駛員有足夠時間修正）；C2指“不足90%的駕駛員可規避”（如突發制動失效，需緊急操作）；C3指“幾乎無法規避”（如高速行駛中轉向突然失靈）。C2需通過測試驗證：選取20名不同駕駛經驗的測試者，在場景復現中若均能規避傷害，可證明85%以上的可控性；C1可基于專家判斷；C3無需驗證。
（四）安全目標的確定
安全目標（Safety Goal）是針對每個危害事件制定的風險控制目標，其ASIL等級由E、S、C的組合確定。根據ISO 26262標準，E、S、C的不同組合對應不同ASIL等級，例如：S3（致命傷害）+E4（高暴露）+C3（不可控）=ASIL D；S2（嚴重傷害）+E3（中暴露）+C2（低可控）=ASIL B。安全目標需以“防止/減輕危害事件”的形式表述，例如“防止因制動失效導致的高速行駛中追尾事故（ASIL D）”。
安全目標需明確兩個關鍵屬性：安全狀態（Safe State）和FTTI（故障容錯時間間隔）。安全狀態是指故障發生后應達到的安全狀態，例如“制動系統失效后，激活電子駐車制動，保持車輛靜止”；FTTI是從功能異常到危害事件發生的最大允許時間，需通過仿真或測試確定，例如轉向系統的FTTI通常為200ms（即故障發生后，需在200ms內完成診斷與安全狀態遷移）。FTTI的確定需考慮最壞場景：例如在濕滑路面上，轉向失效后車輛可能在1.5s內偏離車道，因此FTTI需≤1.5s。
四、功能安全概念（FSC）的設計與驗證
功能安全概念（FSC）是基于安全目標推導的整車級安全方案，核心是將安全目標轉化為可執行的功能安全要求（FSR），并分配至系統或組件層面。
（一）功能安全要求（FSR）的推導
FSR的推導需覆蓋故障處理的全流程，包括故障避免、探測、響應及安全狀態遷移。以“防止近光燈非預期關閉（ASIL B）”的安全目標為例，FSR可分為：
輸入層：開關模塊（SM）需持續發送“點亮”信號（FSR1：SM在駕駛員激活后，每秒發送一次“近光燈開啟”信號，信號錯誤率≤10??/h）；
傳輸層：CAN總線需檢測信號異常（FSR2：通訊鏈路需采用CRC校驗，錯誤幀比例≤10??）；
處理層：車身控制模塊（BCM）需驗證信號有效性（FSR3：BCM若連續3次未收到信號，需激活備用電源點亮近光燈）；
輸出層：燈具執行器需確保冗余（FSR4：至少保持一盞近光燈點亮，即使其中一個燈泡故障）。
FSR需明確以下屬性：運行模式（如“僅在點火開關ON時生效”）；容錯時間（如“BCM需在100ms內檢測到信號丟失”）；安全狀態（如“近光燈保持常亮”）；冗余設計（如“雙路電源供電，單路故障時自動切換”）。對于輔助駕駛等復雜系統，還需考慮緊急運行策略：例如“當輔助駕駛系統失效時，在5s內提醒駕駛員接管，若未響應則執行靠邊停車”。
（二）外部依賴與接口設計
功能安全概念可能依賴非電子電氣技術（如機械、液壓系統）或外部相關項（如ESC、ADAS系統），需明確這些依賴的安全要求。例如，若制動系統的安全概念依賴機械駐車制動（非電子系統），則需導出：“機械駐車制動在車速≤5km/h時，制動效能≥300N·m（ASIL QM）”。對于外部電子系統，如“輔助駕駛系統依賴ESC提供的橫擺角速度信號”，則需提出：“ESC發送的橫擺角速度信號誤差≤2°/s，更新頻率≥100Hz（ASIL C）”，并要求ESC遵循ISO 26262的對應等級開發流程。
接口設計需定義信號格式、校驗機制及容錯策略。例如，CAN通訊接口需規定：“信號采用8位數據格式，包含1位奇偶校驗位；連續3次校驗失敗時，觸發備用通訊鏈路（如LIN總線）”。對于跨系統接口，還需考慮時序要求：“ADAS系統向制動系統發送的減速請求，需在10ms內得到響應，超時則觸發降級”。
（三）功能安全概念的驗證
功能安全概念的驗證需證明其符合安全目標，包括以下方式：
評審驗證：由獨立團隊（I2等級）審核FSR的完整性（是否覆蓋所有安全目標）、一致性（不同FSR之間無沖突）及可行性（技術上可實現）；
仿真驗證：通過CarSim、Prescan等工具仿真故障場景，驗證安全機制的有效性，例如“仿真轉向助力丟失后，ESP系統是否能在FTTI內糾正車輛軌跡”；
原型驗證：在HIL（硬件在環）測試臺架上，模擬ECU故障（如信號中斷、計算錯誤），驗證安全狀態遷移的及時性，例如“人為切斷轉向傳感器信號，測量BCM激活備用模式的響應時間是否≤150ms”。
驗證需形成文檔，包括驗證計劃（明確驗證目標與方法）、測試用例（覆蓋所有FSR）、結果報告（記錄實測值與目標值的偏差）。對于高ASIL等級（如C、D）的安全目標，驗證需采用更嚴格的方法，例如增加測試樣本量（≥50次）、引入第三方機構審核。
汽車功能安全概念階段是安全開發的基石，其核心是通過相關項定義明確邊界，通過HARA識別風險，通過FSC設計安全方案。相關項定義需聚焦整車功能與交互，確保分析范圍的準確性；HARA需系統化識別危害事件，科學評估E、S、C以確定ASIL等級；FSC需將安全目標轉化為可執行的FSR，覆蓋故障處理全流程，并驗證其有效性。
概念階段的輸出直接影響后續開發環節，因此需注重文檔的規范性與評審的獨立性。企業需建立跨部門協作機制（如安全委員會），確保產品、安全、工程團隊的協同；同時，需積累場景庫與故障案例（如基于實際事故數據），提升HARA的準確性。隨著輔助駕駛等復雜功能的普及，概念階段還需結合預期功能安全（SOTIF，ISO 21448），考慮性能局限導致的風險，實現更全面的安全保障。