1 軟件單元驗證 (Software Unit Verification)

通過評審、分析和測試等驗證措施來驗證軟件單元設計和所實現的軟件單元。

• 專業定義： 在ISO 26262框架下，軟件單元驗證是針對汽車軟件中可識別的最小結構（如函數、類、模塊）進行的一系列活動，旨在確保這些單元本身的設計和實現是正確、安全、符合要求且無多余內容。

• 通俗解釋： 就像造汽車零件（比如一個活塞環或一個ECU里的微芯片控制程序）需要出廠前的質檢一樣，軟件單元驗證就是對構成汽車控制軟件的一個個“小零件”進行嚴格的“出廠檢驗”。這個檢驗不是等到整臺車（整個軟件）都裝好了才做，而是在每個“零件”剛生產出來就立刻檢查，確保它們本身是靠譜的、符合圖紙（需求）、沒有瑕疵或者多余的東西。
  

• 目的:
  該子階段的目的是：

• 1. 提供證據，證明軟件單元設計符合分配的軟件需求并適合于實現；
  • 詳細解釋： 這個目的的核心是檢查軟件單元的軟件需求詳細實現。
    • “符合分配的軟件需求”：檢查這個單元的設計是否精確地涵蓋了它應該實現的所有功能？比如需求要求它能監測車速并在超過100km/h時發出警告，設計里有沒有體現這個邏輯？
    • “適合于實現”：檢查這個設計在技術上是否真的能做得出來？設計得是不是足夠清晰、沒有歧義？有沒有考慮效率和資源限制（如芯片處理能力、內存占用）？設計會不會太復雜，導致后面程序員寫代碼非常容易出錯？
  • 通俗類比解釋： 檢查這個軟件“零件”的設計圖是否正確？它應該干的事情，圖上都畫清楚了嗎？畫的圖是不是太天馬行空，工廠（程序員）根本做不出來？或者畫的圖太模糊，讓不同工人理解不一樣？
  • 示例：
    • 需求： 輪速信號采集單元需求 - “輪速傳感器輸入濾波后，每10ms采集一次信號。”
    • 設計檢查 (驗證)：
      • 符合需求： 設計文檔里是否描述了輪速傳感器接口、輸入濾波算法（如均值/中值濾波）、10ms定時采集的機制？
      • 適合于實現： 設計的濾波算法復雜度是否在所選微控制器能負擔的范圍內？10ms的采集周期是否能在系統調度中穩定實現？設計的接口定義是否清晰（電壓范圍、數據類型）？如果設計過于復雜（例如用了超出MCU計算能力的實時濾波算法），就需要修改設計。
• 2. 驗證符合7.4.10和7.4.11要求的面向安全的分析所定義的安全措施是否正確實現；
  • 詳細解釋： ISO 26262標準要求在之前的步驟（安全需求規范、架構設計）進行安全分析（如FMEA, FTA），識別出可能導致危險的軟件故障模式（例如：函數計算錯誤返回危險值、條件判斷錯誤導致動作誤觸發）。然后會定義針對這些故障的安全措施（Safety Mechanisms - SM），比如：
    • 范圍檢查（檢查輸入/輸出值是否在合理范圍內）
    • 冗余計算（相同邏輯用不同算法算兩次，比較結果）
    • 看門狗監控（監測程序是否卡死）
    • 程序流監控（檢查函數執行順序是否正確）
    • 校驗和（檢測內存數據是否被意外篡改）
    • 安全庫函數（避免使用標準庫里不安全的功能，如非邊界檢查的數組訪問）。
    • 這個目的就是檢查：這些計劃好的安全措施（“保險絲”、“備用泵”、“報警器”）是否真真切切地在這個軟件單元本身的代碼里實現出來了？實現得對不對？
  • 通俗類比解釋： 汽車零件上如果設計了防錯、保險措施（比如剎車片上的磨損報警金屬片，防止你磨到極限都不知道），在出廠質檢時，就要檢查這個報警片是不是真的裝上了、裝的位置對不對、材料是不是能導電？
  • 示例：
    • 安全分析結論： 如果油門踏板位置傳感器信號處理函數內部計算錯誤，可能導致輸出一個100%油門的危險值。
    • 定義的安全措施 (SM)： 在該函數內部實施“輸入范圍檢查”和“輸出范圍檢查”。輸入值應在0-5V（對應0%-100%油門開度）之間，輸出值也應在0%-100%范圍內。
    • 驗證 (檢查代碼實現)： 代碼審計或單元測試檢查這個信號處理函數中：
      • 有沒有讀取傳感器輸入電壓值的代碼？
      • 有沒有檢查這個電壓是否在0V到5V之間的代碼？如果有電壓超出，怎么處理？（比如輸出默認安全值0，或者報錯）
      • 計算后輸出油門開度百分比時，有沒有檢查輸出是否在0%-100%之間的代碼？如果超出怎么處理？（強制鉗制到邊界值）
      • 這些檢查代碼本身邏輯是否正確？
• 3. 提供證據，證明所實現的軟件單元符合單元設計，并滿足所分配的具有所要求ASIL等級的軟件需求；
  • 詳細解釋： 這個目的的核心是檢查做好的“軟件單元”本身的質量。
    • “符合單元設計”：程序員最終寫出來的代碼，真的實現了前面檢查過的那個軟件需求詳細實現嗎？有沒有偷工減料？有沒有畫蛇添足？
    • “滿足所分配的軟件需求”：通過測試等方法證明，這個寫好的“軟件單元”，確實能完成它被分派的功能任務。
    • “具有所要求ASIL等級的軟件需求”：這個軟件單元要求達到什么樣的安全等級（A-D）？驗證的方法和嚴格程度需要和這個等級匹配。越高的安全等級（比如D級），驗證就要做得越多（比如更全面的測試、更嚴格的代碼審查）。
  • 通俗類比解釋： 檢查生產好的零件是否嚴格按設計圖紙制造的？拿這個零件去測試（比如裝在發動機試驗臺上跑），它能不能達到設計要求（比如提升多少馬力）？對這個零件的檢驗標準是否夠嚴，得看它裝在車上哪個關鍵位置（普通零件抽檢就行，剎車零件就得100%檢甚至更復雜的檢驗）。
  • 示例：
    • ASIL等級： 車門鎖控制單元中的“車門鎖閉鎖命令生成函數”，分配了ASIL B的需求。
    • 設計： 該函數應接收車速（>5km/h時閉鎖）和駕駛員鎖門按鍵按下信號，輸出閉鎖命令。
    • 驗證 (單元測試)：
      • 測試1 (符合需求)：車速=0km/h, 按鍵按下 -> 應無閉鎖輸出。（測試滿足ASIL B需求中的安全鎖定條件）
      • 測試2 (符合需求)：車速=10km/h, 按鍵按下 -> 應有閉鎖輸出。
      • 測試3 (符合需求)：車速=10km/h, 按鍵未按下 -> 應無閉鎖輸出。（防止誤動作）
      • 測試4 (符合設計)：使用代碼覆蓋率工具（如LDRA, VectorCAST）檢查測試用例是否執行了設計文檔描述的邏輯分支（如車速判斷、按鍵判斷），達到ASIL B要求的覆蓋率指標（如100%語句覆蓋，決策覆蓋）。
      • 測試5 (錯誤注入，針對ASIL)：人為注入一個故障（如讓車速傳感器信號線暫時斷開），檢查安全機制（如信號失效默認處理邏輯 - 假設車速為0）是否生效，阻止意外閉鎖。這是驗證故障容錯能力。
• 4. 提供充分證據，證明軟件單元既不包含非所需功能，也不包含與功能安全相關的非所需特性
  • 詳細解釋： 這是軟件安全的特殊要求。
    • “非所需功能” (Unintended Functionality)：軟件單元做了它完全不應該做的事情，在需求或設計里沒有定義的額外功能。例如：一個只負責讀取溫度的代碼，偷偷去修改了剎車參數。
    • “與功能安全相關的非所需特性” (Non-required Functionality that impacts Safety)：軟件單元具有在需求或設計里沒有定義的額外能力（比如一個隱藏的調試接口、一個未使用的計算變量），雖然這個能力本身不是功能，但一旦被外部利用或者異常觸發，可能干擾或破壞需要滿足功能安全要求的功能。
  • 通俗類比解釋： 檢查這個零件里沒有藏著后門、多余的功能開關或者不相關的危險材料！比如，一個控制音響音量的零件，里面絕對不能有能暗中控制剎車的線路；一個零件上如果有沒焊上的調試接口（比如串口），這個接口如果暴露出來，被人插上電腦亂發指令，會不會讓剎車失靈？那就很危險，也要避免。
  • 示例：
    • 非所需功能： 在車身控制模塊BCM的燈光控制單元代碼里，發現存在控制雨刷的邏輯。這個邏輯完全沒有被BCM的需求提及，是多余的、未計劃的且可能存在意外激活的風險。
    • 非所需特性 (影響安全)：
      • 一個負責計算發動機扭矩的單元里，包含一個未啟用且設計文檔未提及的、能通過診斷指令秘密開啟的“超增壓模式”。雖然沒開啟，但指令接口存在，可能被惡意利用。
      • 單元代碼中殘留了大量開發測試用的#ifdef DEBUG開關和對應的調試代碼。其中某些調試代碼如果被激活（即使意外編譯），可能繞過安全機制或輸出診斷信息到不安全的總線上。
      • 代碼中定義了全局變量volatile int secret_key;，但沒有任何使用它的代碼路徑。這個變量可能被外部攻擊者篡改，用作緩沖區溢出攻擊的一部分，間接影響安全關鍵功能。
    • 如何驗證： 嚴格進行代碼審查（特別是第三方代碼），靜態代碼分析（工具檢查未使用的變量、函數、潛在危險的API調用），檢查編譯配置（確保Debug代碼被排除），安全審計（尋找隱藏接口和調試遺留）。

總結:

軟件單元驗證就像是給汽車軟件的每一個微小“智能零件”做的一次全面“出廠前體檢 + 安全檢查”。其核心目的就是確保：

1. 設計靠譜且可實現： 零件圖紙（設計）正確且能制作。
2. 安全措施到位： 圖紙要求的“保險絲”、“警報器”（安全措施）真的裝好且裝對了。
3. 成品合格且達標： 生產出的零件（代碼）按圖紙制造，功能正確，并通過了相應安全等級（ASIL）要求的嚴格測試。
4. 純凈無污染： 零件里沒有任何不該有的功能、后門、危險開關或多余且可能惹禍的“零件”。
   只有確保這些“零件”個個都高質量、安全、純凈，由它們組裝起來的整個汽車控制系統（整車軟件）才更有可能是可靠、安全的。ISO 26262認為，在軟件單元級別及早發現和修復問題，是構建高功能安全等級汽車軟件最為有效和基礎的手段。

2 ISO 26262-6對單元驗證的實施要求和建議

2.1 要求和建議

ISO 26262-9原文：如果軟件單元是與安全相關的，則應符合本子章條的要求。

• 解釋： 這個條款的核心非常明確。它規定，汽車軟件中任何一個獨立的“單元”（可以理解為一個功能模塊、一個類、一個函數、一個小的算法塊等），只要這個單元的功能涉及到車輛安全（即如果不正確工作可能導致事故或人員傷害），那么在驗證（確認這個單元是否正確實現了需求且沒有缺陷）這個單元時，必須嚴格遵守 ISO 26262中討論軟件單元驗證的具體章節，如 ISO 26262-9里規定的，所有驗證方法和要求。安全相關的單元需要更嚴格、更全面的測試。

• 原文：注1：根據ISO 26262-1，“安全相關元素”是指單元實現安全需求，或未滿足單元和其他單元共存（參見ISO 26262-9:2018第6章）的標準。

  • 解釋： 這里明確說明了什么樣的軟件單元屬于“與安全相關的”。
    • 情況1：實現安全需求 (主要情況)：這個軟件單元直接負責執行一個或多個“安全需求”。安全需求是為了防止或減輕特定危害（如意外加速、制動失效）而設定的功能或性能要求。例如，一個控制剎車壓力的軟件模塊。
    • 情況2：未滿足共存標準 (潛在情況)：這個軟件單元本身可能不直接實現安全需求，但它必須符合與其他（安全相關或非安全相關）單元“共存”的標準。這里的“共存標準”是指：
      • 獨立性：一個單元的功能失效不應該輕易導致另一個（尤其是安全相關的）單元失效（避免級聯失效）。
      • 無干擾性：一個單元的正常運行（例如占用大量CPU資源）不能干擾其他（尤其是安全相關的）單元及時、正確地執行其功能（避免資源爭奪）。
      • 失效后狀態定義：如果這個單元自身失效了，不能導致整個系統進入不可控的危險狀態。
    • 通俗關鍵點： 即使某個模塊看起來“普通”（如一個內存管理模塊或通信模塊），如果它崩潰了會導致旁邊的關鍵安全模塊（如氣囊控制器）也失效或無法正常工作，那么它也必須被視為“安全相關”的，因為它對整體安全構成了間接威脅。

• 原文注2：本章要求涉及安全相關軟件單元；其他軟件標準（參見ISO 26262-2:2018, 5.4.5.1）可用于其他軟件單元的驗證。

  • 解釋： 強調了ISO 26262中關于軟件單元驗證的嚴格規則只強制適用于安全相關單元。對于軟件中不涉及安全功能的部分（例如娛樂系統的界面動畫、收音機調諧、非關鍵的溫度顯示模塊等），在驗證時可以不遵循ISO 26262-6的全部嚴苛要求。
  • 替代標準： 這些非安全相關的單元可以采用更通用、要求相對低一些的軟件驗證標準或實踐（比如A-SPICE的特定級別要求、公司內部的編碼規范檢查、基本的功能測試等）。ISO 26262-2的5.4.5.1節通常會指引采用行業內認可的合適標準（如A-SPICE）或公司自身定義的合格標準。
  • 通俗關鍵點： 不同重要性的東西，檢查的嚴格程度不同。安全核心部件要像防彈衣一樣層層把關測試，收音機UI出個小Bug可能只需簡單檢查。

• 原文注3：對于基于模型的軟件開發，實現模型的相應部件也是驗證計劃的對象。根據所選軟件的開發過程，驗證對象可以是來自該模型的代碼，可以是模型本身，也可以兩者都是。

  • 解釋： 現代汽車軟件開發中，廣泛使用模型（在工具如Simulink/Stateflow中建立的圖形化或形式化描述）來設計軟件的行為邏輯。
    • “實現模型的相應部件”: 指模型中那些最終會對應生成實際代碼的部分（比如某個子系統、狀態機或算法函數）。
    • “也是驗證計劃的對象”: 在MBD流程中，不能只驗證最終生成的代碼。模型本身（或其關鍵部分）也必須作為獨立的驗證對象，納入驗證計劃進行充分檢查。
  • 驗證對象的靈活性：
    • 來自該模型的代碼: 有些流程選擇主要驗證最終自動生成的或手動調整后的代碼（這是最接近最終運行形態的）。
    • 模型本身: 有些流程選擇直接在模型層面進行非常深入的驗證（如形式化驗證、仿真測試、模型審查），并且認為只要模型正確，生成的代碼也正確（依賴于可靠的工具鏈）。
    • 兩者都是: 最嚴格的流程要求對模型本身（作為設計源頭）和從該模型生成的代碼（作為最終實現）都進行驗證。這是最全面但成本最高的方法，適用于ASIL D等級或核心安全功能。
  • 通俗關鍵點： 如果你是用模型設計軟件的（相當于畫了詳細的建筑圖紙和電路圖）：
    • 你不能只等蓋好房子（生成代碼）才檢查。圖紙（模型）本身就要認真校對、模擬測試。
    • 至于蓋好后的檢查（代碼驗證），可以靈活：可以只檢查房子（代碼），或只相信檢查合格的圖紙（模型），也可以圖紙和房子都檢查（雙保險）。

2.2 通俗易懂的解釋與總結

想象一下汽車的軟件是由成千上萬個小小的“智能部件”（軟件單元）組成的。

1. 核心規矩：關鍵部件，嚴上加嚴！

   • 規則： 如果一個智能部件（軟件單元）負責安全大事（比如管剎車、防碰撞、控安全氣囊），那么檢查它的時候必須用最嚴格、最全面的“安檢流程”（ISO 26262-6子章條的要求）！
   • 為啥？ 因為這些部件要是出點毛病，車就可能失控、撞車，要人命！馬虎不得！

2. 啥算“關鍵部件”（安全相關）？

   • 直接負責安全： 這個部件本身干的活就是保障安全的。例：
     • 剎車壓力控制器：它直接決定踩剎車時有多大勁兒能停下來。
     • 氣囊觸發器：它要在撞車瞬間準確判斷該不該炸開氣囊。
   • 可能拖后腿/幫倒忙的： 這個部件本身不是管安全的，但如果它壞了或者亂來（比如瘋狂刷屏顯示歌詞，占光CPU算力；或者傳遞錯誤數據），搞得旁邊真正管安全的部件（比如上面說的剎車或氣囊控制器）也不能好好干活甚至癱瘓，那它也得算“關鍵部件”！例：
     • 通信管理模塊：它負責不同部件間傳消息。如果它掛了，剎車指令可能發不到剎車控制器那里去，這就拖了安全的后腿！
     • 中央處理器任務調度模塊：它負責分配CPU時間。如果它失控，把CPU都給了娛樂大屏放動畫，導致剎車控制模塊沒得到計算時間，那就壞事了！

3. 普通部件？可以寬松點！

   • 規則： 那些不管安全的部件（比如車內大屏的UI動畫控制模塊、調頻收音機搜臺模塊、氛圍燈變色邏輯模塊），檢查的時候不用按上面那份頂級嚴苛的安全規范（ISO 26262-6）來。
   • 怎么做？ 可以用公司自己成熟的軟件檢查流程（比如代碼規范掃描、一般功能測試），或者參考業內比較通用的質量標準（如A-SPICE），保證功能正常、不出大問題就行。畢竟這些部件出Bug一般不會直接導致車禍。

4. 特殊開發方式：從圖紙就開始查！

   • 背景： 工程師現在經常先在電腦上用圖形工具（比如Simulink）畫出軟件的“設計圖紙”（模型），再讓工具自動生成或微調成最終運行的程序（代碼）。
   • 規矩： 對用這種方式開發的關鍵安全部件，光檢查生成的程序（代碼）還不夠！這個設計過程本身（那些圖形圖紙 - 模型）也必須列入安全檢查計劃！
   • 檢查什么？三種選擇：
     • 選擇1：只查程序（代碼） - 相當于只檢查蓋好的房子。這是最直接接觸實物的方式，但可能發現不了設計思路的根本錯誤。
     • 選擇2：只查圖紙（模型） - 相信只要設計圖紙經過超級仔細的驗證（仿真、模型級測試、形式化驗證），蓋出來的房子就不會有問題。前提是蓋房工具必須非常靠譜。這能更早發現問題。
     • 選擇3：圖紙和程序都查（雙保險） - 圖紙驗證確保思路正確，程序驗證確保實現完美。這需要投入最多資源，但安全等級最高！常用在最核心的救命部件上（如ASIL D功能）。

2.3 示例

2.3.1 場景1：電動助力轉向系統 (EPS)

• 關鍵安全相關軟件單元 (必須嚴格驗證)：
  • 轉向扭矩計算模塊：它根據方向盤轉角和車速算出應該給方向盤多大的助力。這個模塊錯了，要么助力太大太靈敏（危險），要么太小掰不動方向盤（危險）。
  • 故障診斷模塊：監測電機、傳感器是否異常。如果這個模塊失效，發現不了嚴重故障可能導致突然喪失轉向助力。
  • 電機控制信號生成模塊：直接控制轉向電機的轉動方向和力量。
  • 潛在安全相關單元 (需評估是否滿足共存標準)：
    • 與主控制模塊通信的底層驅動：如果這個通信模塊掛了，或者發送錯誤指令，可能導致主控模塊無法控制電機。結論：需要按安全相關驗證！
    • 非關鍵的狀態顯示模塊（比如顯示轉向模式“舒適/運動”）：這個模塊即使徹底失效，理論上不影響安全駕駛（駕駛員仍能轉動方向盤，只是可能不知道當前模式）。結論：可以用非安全相關的普通標準驗證。

2.3.2 場景2：自動緊急制動系統 (AEB)

• 關鍵安全相關軟件單元 (必須嚴格驗證)：
  • 目標識別與追蹤算法模塊：識別前方車輛/行人并計算碰撞風險。
  • 碰撞時間/碰撞距離預測模塊 (TTC/TTB)：計算多久后會撞上。
  • 制動決策邏輯模塊：判斷是否以及何時需要緊急制動。
  • 制動執行指令生成模塊：向制動系統發出準確的增壓指令。
  • 傳感器融合模塊：綜合處理來自雷達、攝像頭的數據。
• 潛在安全相關單元 (需評估是否滿足共存標準)：
  • 目標列表管理模塊：管理所有被追蹤到的目標。如果它失效導致關鍵目標信息丟失，決策模塊就會犯錯。結論：需要按安全相關驗證！
  • 系統狀態記錄（日志）模塊：用于后續分析。它本身故障不影響實時決策和執行。結論：可以用非安全相關普通標準驗證。

2.3.3 示例模型驗證

• 剎車壓力控制模塊 (MBD)：
  • 模型本身驗證 (選擇注2或選擇注3的一部分)：
    • 在Simulink中對該模型進行覆蓋性充分的仿真測試：模擬各種車速、踏板深度、ABS/ESC介入、故障條件等，看模型計算的壓力指令是否正確。
    • 進行模型形式化驗證：使用工具檢查模型邏輯是否存在死鎖、溢出、除以零等根本性問題。
    • 代碼生成配置檢查：確保模型設置能生成安全可靠的代碼。
  • 生成代碼驗證 (選擇注1或選擇注3的一部分)：
    • 對最終生成的C代碼進行靜態分析 (檢查編碼規范、潛在缺陷)。
    • 進行代碼級單元測試 (與模型測試類似，但基于源代碼)。
    • 進行代碼結構覆蓋率測試 (語句覆蓋、分支覆蓋等 - ISO 26262要求)。
  • 結論： 對于ASIL D的制動系統，很可能采用選擇注3：模型和代碼都要嚴格驗證。

2.4 核心要點總結

• 安全相關 = 嚴查 (ISO 26262-6)!
• 安全相關判定： 要么管安全本身，要么亂搞會害到管安全的兄弟部件。
• 非安全相關 = 常規查就行。
• 模型開發： 關鍵安全功能的設計模型圖 (框圖/流程圖) 也得認真驗！怎么驗？取決于公司流程：單獨查圖、單獨查代碼、或者圖代碼一起查（最保險）！

簡單說：人命關天的軟件模塊，就要用最頂級的安檢；不影響安全的軟件模塊，普通安檢就行了。如果用模型設計，圖紙也得仔細審，不能光看蓋好的房子！這就是ISO 26262為保障我們行車安全在軟件層面定下的鐵律。