1 目的

軟件集成和驗證階段的核心目標是證明集成后的軟件單元（模塊、組件）已經正確地開發出來，滿足了所有的功能和（至關重要的）安全要求。
該子階段的目的是：

• a) 定義集成步驟并集成軟件元素，直至嵌入式軟件完全集成；
• b) 驗證由軟件架構級別的安全分析產生的已定義的安全措施是否得到了適當的實施；
• c) 提供證據，證明集成的軟件單元和軟件組件滿足其軟件架構設計需求；及
• d) 提供充分證據，證明集成軟件不包含關于功能安全的非所需功能和特性。

在此子階段，按照軟件架構設計，對軟件要素之間特有的集成層次和接口進行驗證。軟件要素的集成和測試的步驟直接對應著軟件的分層架構。

2 驗證輸入

• 軟件架構設計規范，按照7.5.1；
  • 定義： 描述軟件如何被分解為組件、單元以及它們之間如何交互、接口、依賴關系和約束的文檔。
  • 作用： 為如何進行集成（集成的順序、接口要求）以及驗證測試的結構（如模塊測試、組件測試、集成測試）提供藍圖和依據。
  • 來源： 軟件設計階段的輸出，基于技術安全要求開發。

3 軟件集成要求

3.1 要求和建議

定義軟件集成方法，并描述將單個軟件單元分層集成到軟件組件的步驟，直至嵌入式軟件完全集成為止。

• 定義軟件集成方法： 你需要明確規定“怎么把小塊軟件組裝成大塊軟件”。這個方法要詳細描述集成策略、使用的工具、環境搭建、執行流程（誰、何時、做什么）、以及如何記錄結果。
• 描述軟件集成步驟： 你需要清晰地描繪出軟件集成的“階梯”，從最小的、不可再分的軟件單元開始：
  • 第一步：把幾個單元集成為一個小的軟件組件。
  • 第二步：把小的組件（或結合更多單元）集成為更大的組件。
  • 后續步驟：重復上述分層組合過程…
  • 最終步：將所有組件集成，形成完整的嵌入式軟件。

• 在定義步驟時，必須考慮以下依賴關系：

  • a) 原文定義：與實現10.4.2提供的驗證目標之間的依賴關系
  • a)解釋： 與驗證目標（10.4.2）的依賴： 你在軟件單元驗證階段（ISO26262 Part 6 Clause 10.4.2）定義了很多測試目標和用例。現在集成過程中，需要考慮：哪些新的集成測試必須在單元測試完成后才能進行？哪些集成步驟的結果（或提供的接口）是執行后續集成測試的前提條件？集成測試如何補充和覆蓋單元測試無法發現的（主要是單元交互和集成帶來的）問題？
  • b) 原文定義：與軟件集成相關的功能依賴關系；
  • b) 解釋：功能依賴關系： 軟件各部分之間不是孤立的！一個組件（比如油門控制器）需要另一個組件（比如引擎控制器）提供數據才能工作。在定義集成順序時，必須識別這些運行時的依賴關系。你需要先集成提供基礎服務/數據的組件，再集成依賴這些服務/數據的組件。集成時要測試這些交互是否正確。
  • c) 原文定義：軟件集成與軟硬件集成之間的依賴關系。
  • c)解釋： 軟件集成與軟硬件集成的依賴： 你的軟件最終要跑在目標硬件（ECU）上。這帶來了約束：
    • 資源依賴： 某些集成步驟可能必須在目標硬件/模擬器上進行，因為需要驗證內存占用、實時性能等（純軟件模擬環境不夠）。
    • 執行環境依賴： 某些集成功能（如底層驅動、中斷處理）直接依賴硬件，需要盡早與硬件一起驗證。
    • 集成策略協調： 軟件集成完成到什么程度后，才能開始與硬件集成（VSI）？它們之間可能有部分重疊或并行。需要明確交接點和協同方式。

• 注：原文定義：對于基于模型的開發，軟件集成可以替換為模型級別的集成以及隨后來自集成模型的代碼自動生成（參見附件B）。

  • 解釋：基于模型開發（MBD）的備注： 如果使用模型驅動開發（如MATLAB/Simulink），你的“軟件單元”可能就是模型塊，“軟件組件”就是子系統模型。軟件集成驗證 可以先在模型層面進行（做模型在環MIL測試），驗證模型子系統之間的接口、邏輯和功能是否在集成后依然正確。驗證通過后，再從集成好的系統模型自動生成代碼。這時再通過生成的代碼進行類似傳統方式的軟件集成測試（但前期大部分問題已在模型層面解決）。后續仍需進行目標硬件上的集成驗證。

3.2 汽車行業示例（混合動力控制器軟件）

• 軟件單元示例：
  • Read_Battery_Voltage_Cell()：讀取單個電池單體電壓。
  • Calculate_SOC()：基于電壓電流計算電池剩余電量（SOC）。
  • Control_Motor_Relay()：控制高壓電機接觸器的通斷。
• 早期集成步驟：
  • 集成電池基礎組件： 將多個 Read_Battery_Voltage_Cell() (單元) 集成到一個能同時讀取所有單體電壓并進行初步一致性校驗的組件中。考慮**(b功能依賴)：電壓讀取組件是計算SOC的基礎。考慮(a驗證依賴)**：需先保證每個Read_Battery_Voltage_Cell()單元自身驗證通過。
  • 集成SOC估算組件： 將電壓讀取組件（已是組件）與Calculate_SOC()（單元）以及其他單元（電流讀取、溫度讀取）集成。執行組件級測試驗證SOC計算邏輯。考慮**(b功能依賴)：依賴電壓、電流、溫度讀數。考慮(c軟硬件依賴)**：可能需要部分在ECU硬件評估板上運行（或高仿真環境），因為算法計算量可能很大，需驗證性能。
• 中期集成步驟：
  • 集成高壓控制組件： 將 Control_Motor_Relay()（單元）與接觸器狀態監控、預充電控制邏輯等單元集成，形成一個能安全管理高壓回路通斷的組件。測試其安全邏輯（如預充電順序、短路檢測）。考慮**(c軟硬件依賴)**: 必須 在目標ECU（或精確模擬器）上進行測試，涉及底層驅動、高精度時序控制和硬件直接交互。
• 后期集成步驟：
  • 集成能量管理核心組件： 將 電池SOC估算組件、高壓控制組件、引擎運行狀態組件、發電機控制邏輯等集成。測試其在各種工況下的充放電策略、模式切換邏輯（如純電->混動）、能量回收等。考慮**(b功能依賴)：依賴幾乎所有底層組件提供的數據和狀態。考慮(a驗證依賴)**：依賴所有底層組件及前期集成步驟的測試結果。
• 最終集成：
  • 集成完整混合動力控制軟件： 將能量管理核心組件與其他組件（如熱管理、整車通信模塊、診斷模塊、扭矩分配控制等）集成成一套完整軟件。進行系統級軟件集成測試。考慮**(c軟硬件集成依賴)**：此刻，完整的軟件應準備好進行軟硬件集成（VSI），即部署到目標ECU上進行與硬件的聯合調試和測試。

• 依賴關系在示例中的體現：

  • (a驗證目標依賴)：你無法測試能量管理核心組件對SOC的依賴性，除非SOC估算組件已經通過了自身的集成測試。集成測試覆蓋了各組件之間接口的邏輯、時序和數據一致性，這是單元測試無法覆蓋的。
  • (b功能依賴)：SOC估算功能依賴于精確的電壓讀取和溫度讀數。沒有可靠的底層數據（功能提供），高層策略（功能使用）無法正常工作。集成順序必須先確保基礎功能組件就緒。
  • (c軟硬件集成依賴)：
    • 像高壓接觸器控制這樣直接操縱關鍵硬件、涉及高安全性的組件，必須在集成早期就結合硬件（或高保真模擬環境）進行驗證（因為純軟件環境無法捕捉關鍵硬件時序和驅動問題）。
    • 當軟件集成到一定程度（如具備基礎輸入/輸出控制、通信、內存管理），就可以提前部署到目標ECU（HW或快速原型板）上，并行開展部分軟硬件集成工作（如驗證基本輸入輸出信號、刷寫流程等），而不是等所有功能都集成完畢才開始上車調試。

核心目的： 通過這種結構化、分層級并明確定義了依賴關系的集成方法，旨在早期發現和修復軟件單元在集成過程中產生的接口錯誤、時序問題、資源沖突、邏輯交互缺陷等，確保最終生成的嵌入式軟件在功能、性能和安全方面滿足要求，為后續順利的軟硬件集成和系統驗證打下堅實基礎。

4 驗證要求

按照ISO 26262-8:2018第9章，通過表10所示方法，對軟件集成進行驗證，證明分層集成的軟件單元、軟件組件和集成嵌入式軟件能夠實現：

• a) 與軟件架構設計的符合性，按照第7章；【軟件集成驗證重點關注】

  • ISO解釋： 驗證集成后的軟件的結構、組織方式（比如模塊怎么劃分、怎么通信）和預期的“藍圖”（即軟件架構設計）一致。
  • 通俗解釋 (汽車角度)： 就像按照精確的電路圖組裝電腦主板一樣，軟件集成也要嚴格按照事先設計好的“軟件結構圖”來連接各個程序模塊。要檢查模塊之間的實際連接（誰和誰說話，怎么傳數據）和設計圖上的連線是否一致。
  • 例子：
    • 設計圖要求： 發動機控制模塊中的“噴油控制軟件”必須直接接收“發動機轉速傳感器軟件”的數據。
    • 驗證方法： 在集成好的軟件里，檢查噴油控制模塊是否真的調用了轉速傳感器模塊提供的接口函數來獲取數據。如果沒有（比如它錯誤地調用了水溫傳感器的接口），那就是不符合。
    • 測試類型： 接口測試、動態分析（運行中追蹤數據流）。

• b) 與軟硬件接口規范的符合性，按照6.5.2；【可在系統集成測試驗證】

  • ISO解釋： 驗證軟件如何與它運行其上的硬件（如微控制器、傳感器、執行器）打交道的方式，是否符合預先定義好的規則。
  • 通俗解釋 (汽車角度)： 就好比確保ECU里的軟件芯片（芯片）的“管腳”（軟件接口）和連接它的傳感器、執行器（如發動機噴油器、剎車卡鉗的電磁閥）的“接線”（硬件接口）定義匹配無誤（電壓、信號類型、頻率、怎么讀怎么寫）。軟件讀取傳感器值和發送控制命令的方式必須嚴格遵守硬件說明書。
  • 例子：
    • 規范要求： 剎車壓力傳感器信號是0-5V模擬信號，對應0-300bar壓力值。軟件必須通過ADC（模數轉換器）通道3讀取該值，并按線性比例計算實際壓力。
    • 驗證方法：
      • 測試： 模擬硬件給ADC通道3輸入一個2.5V電壓，看軟件計算出的壓力值是否為150bar（在允許誤差范圍內）。
      • 代碼審查： 檢查軟件讀取該信號的代碼確實是指定了對ADC通道3的操作。
    • 潛在錯誤： 軟件錯誤地配置為讀取ADC通道2的信號，或者計算壓力的公式錯誤（比如忘了除以2）。

• c) 已定義的功能性**【可在系統合格性測試進行驗證】**

  • ISO解釋： 驗證集成后的軟件作為一個整體，能正確地執行它被要求完成的所有具體工作任務（功能）。
  • 通俗解釋 (汽車角度)： 軟件集成后，它負責的核心業務能力是否都實現了？比如，自動剎車軟件能不能在探測到障礙物時剎停車輛？自動雨刮能不能根據雨量大小自動調整速度？車窗控制軟件能不能讓四個車窗按按鈕要求升降？
  • 例子：
    • 功能定義： 自適應巡航控制軟件集成后，必須具備的功能包括：自動跟車保持設定距離、在駕駛員踩油門時暫時加速覆蓋ACC、自動探測前車消失并加速到設定速度、探測到本車插入慢車道車輛后方時自動降速保持安全距離。
    • 驗證方法： 搭建測試臺架（或者用仿真軟件），模擬各種駕駛場景（如前方車輛減速、加速、變道、切出等），輸入相應信號（雷達數據、車輛速度信號、駕駛員操作信號等），檢查集成軟件輸出的控制指令（油門、剎車）是否符合預期（即實現上述每個功能）。
    • 測試類型： 功能測試、黑盒測試（關注輸入輸出）、場景測試。

• d) 指定的特性；【根據ASIL等級確定軟件集成驗證的實施程度】
  示例：可靠性（沒有不可訪問的軟件），魯棒性（防止錯誤輸入），可信賴性（有效的錯誤檢測和處理）。可靠性（沒有不可訪問的軟件），魯棒性（防止錯誤輸入），可信賴性（有效的錯誤檢測和處理）。
  示例：不存在無法訪問的軟件；具備有效的錯誤檢測和處理。

  • ISO解釋： 驗證集成后的軟件除了能“做事”，還要具備一些非功能性但極其重要的品質，如可靠性、健壯性、可依賴性和易維護性（后面三項特別強調）。
  • 通俗解釋 (汽車角度)： 軟件不能光會干活，還得“靠得住”、“不嬌氣”、“好養活”。重點關注：
    • 可靠性 (Reliability - No Dead Code)： 集成后的軟件里有沒有“僵尸代碼”？也就是那些永遠不會被執行到的代碼（死代碼），它們可能占據寶貴的內存和計算資源，浪費空間。
    • 魯棒性 (Robustness)： 當遇到意想不到的壞數據或者不合理輸入時（比如傳感器突然發瘋給了個超出范圍的值，或者通信報文被干擾了），軟件能不能“穩住”，不崩潰（藍屏死機），還能做出合理的、安全的響應？
    • 可信賴性 (Trustworthiness - Effective Error Detection & Handling)： 當軟件內部或外部真的發生錯誤時，它能不能及時準確地發現這個錯誤？發現后能不能采取正確的處理措施？比如切換到安全模式、發出報警、記錄錯誤日志。這是功能安全的基石。
  • 例子 (對應每個特性)：
    • 可靠性 (Dead Code)：
      • 檢查方法： 進行代碼覆蓋率分析（如語句覆蓋、分支覆蓋）。在運行了所有能想到的正常和異常場景的測試用例后，看是否還有未執行到的代碼塊。
      • 結果： 如果發現有代碼段從未被執行，則需要評估這些代碼是否是必要的（如果是冗余的則刪除），或者是測試用例不充分（需要補充測試）。
    • 魯棒性 (Bad Input)：
      • 測試方法： 異常值/錯誤輸入測試。 故意給軟件接口輸入不合理、超出范圍、畸形的數據或信號。
      • 例子：
        • 給發動機ECU的油門踏板位置傳感器輸入一個超過最大允許值（比如>120%）的信號。
        • 給車窗控制信號發送一個同時要求升窗和降窗的矛盾指令。
        • 模擬網絡通信丟包或干擾。
      • 期望結果： 軟件能檢測到這些無效輸入，不會執行危險動作（如猛加速到超出安全范圍），而是進入故障安全狀態（如限制發動機扭矩，或者車窗保持不動），并報告錯誤（如儀表盤亮起故障燈）。
    • 可信賴性 (Error Detection & Handling)：
      • 測試/分析方法：
        • 故障注入測試 (Fault Injection)： 人為制造硬件或軟件錯誤（比如模擬內存讀寫錯誤、CPU寄存器出錯、關鍵任務超時），檢查軟件的錯誤檢測機制能否捕捉到這個錯誤（日志記錄？錯誤標志置位？），以及后續的安全處理機制（如重啟、降級模式）是否被正確觸發并執行。
        • 代碼審查： 查看錯誤處理代碼（如try-catch塊、返回值檢查、看門狗監控）的邏輯是否正確，覆蓋了所有可能的錯誤點。
      • 例子：
      • 剎車控制系統軟件內置了軟件監控任務（Watchdog）和冗余計算校驗。當人為注入錯誤導致主計算任務卡死，監控任務應能檢測到超時，并激活備份計算通道（或觸發安全剎車）。驗證就是看這個過程是否如設計般工作。

• e) 支持功能的足夠資源；【軟件集成驗證重點關注】

  • ISO解釋： 驗證集成后的軟件運行所需的計算資源（CPU運算時間）、存儲資源（RAM/ROM）和通信帶寬在目標ECU上足夠用，不會出現“跑不動”或“塞不下”的情況。
  • 通俗解釋 (汽車角度)： 拼裝好的軟件在ECU上跑起來后，會不會把“大腦”（CPU）累壞了？內存和閃存夠不夠裝下它自己？跟別的ECU或內部模塊“說話”會不會堵車（總線帶寬）？必須在真實或模擬的目標硬件上確認這些核心資源是否夠用、有余量（通常要求有余量，應對未來變更）。
  • 例子：
    • 資源監控工具： 使用實時性能監控工具（如Lauterbach Trace32, iSYSTEM winIDEA，或芯片自帶調試模塊）：
    • 記錄最壞情況下，所有任務（如引擎控制循環、剎車控制循環、通信任務）的執行時間，確保總執行時間小于一個控制周期的設定時間（如2ms）。防止CPU來不及算完，導致控制延遲甚至功能失效。
    • 監控實時運行時的RAM和棧空間峰值使用量，確保不會超過芯片內存大小和安全預留空間。防止堆棧溢出導致崩潰。
    • 測量串行通信或網絡通信（如CAN, FlexRay, Ethernet）的實際帶寬利用率，確保在最大負載情況下不會堵塞。
    • 結果： 如果發現任務A在最壞情況下用了1.8ms（周期是2ms），余量很小（0.2ms），就需要優化代碼或提高硬件性能。如果RAM接近爆滿（用了95%），需要削減功能或增加內存。

• f) 如適用，根據7.4.10和7.4.11，從面向安全的分析得出的安全措施的有效性。

  • ISO解釋： 如果在安全分析（如FTA, FMEA）中發現某些故障可能導致危險結果，并為此設計了軟件層面的安全措施（比如軟件分區/隔離、內部監控診斷邏輯、冗余計算校驗、安全庫函數），那么需要驗證在軟件集成后，這些安全措施能夠實際地、有效地工作。
  • 通俗解釋 (汽車角度)： 這是功能安全（Safety）的核心環節。集成時要檢驗那些為防止嚴重事故而設計的軟件“保險絲”和“保鏢”（安全機制）是否安裝到位且真能起作用。

• 注1：安全措施可以包括軟件分區。

  • 關鍵安全措施例子 - 軟件分區 (注1)：
    • 概念： 將軟件劃分為不同的、受保護的安全域（例如：ASIL D的高安全關鍵性功能 - 比如牽引力控制算法，和QM級的低安全關鍵性功能 - 比如電臺UI）。利用芯片硬件（如內存保護單元MPU）或RTOS特性，嚴格限制它們之間的訪問權限。
    • 目的： 防止低安全等級模塊（萬一出錯）破壞或干擾高安全等級模塊的運行（比如病毒般的錯誤數據覆寫了關鍵的控制變量）。
  • 驗證方法 (f項)：
    • 靜態分析：
    • 檢查分區規則配置文件（如MPU配置、RTOS安全配置）是否正確實施，各分區的訪問權限設定是否符合安全要求。比如高安全域內存能否被低安全域代碼寫入？不行！
    • 動態測試/故障注入 (結合d項可信賴性)：
    • 破壞性測試： 故意讓運行在QM區的軟件嘗試非法訪問ASIL D區控制算法的內存或變量。
    • 期望結果： 硬件MPU（或RTOS保護機制）必須立即檢測到訪問沖突，并觸發錯誤（如拋出異常、重啟低安全域任務、記錄錯誤），保護高安全域不受侵害。
    • 關鍵路徑測試： 在真實干擾環境下，測試內置的軟件安全監控器（如程序流監控Plausibility Checks, 數值范圍檢查, 時間看門狗）是否能正確檢測到注入的錯誤（比如篡改一個關鍵計算結果），并在規定的時間內觸發定義的安全響應（如進入跛行回家模式）。
  • 例子：
    • 設計：引擎管理軟件使用MPU分區，將噴油控制算法（ASIL D）保護在一個分區，將空調控制算法（QM）放在另一個低權限分區。規定QM區代碼絕對不能讀寫噴油控制分區的數據。
    • 驗證：故意在空調控制代碼里寫一段企圖篡改噴油量的指令，然后運行。結果是：硬件MPU檢測到非法訪問，CPU立即觸發一個硬件錯誤中斷，在該中斷里軟件（或系統）強制將空調控制任務踢出去或重啟，同時引擎噴油控制模塊毫發無損地繼續正常工作。這就證明了分區安全措施的有效性。

• 注2：對于基于模型的開發，驗證對象可以是與軟件組件相關聯的模型。

  • 解釋 (汽車角度)： 現在很多汽車軟件是用圖形化模型（如Simulink模型）來設計的，代碼是由這些模型自動生成的。ISO 26262認可，在這種開發流程下，針對軟件組件的集成驗證不必等到生成了最終代碼才進行，而是可以在模型級別就做！把相關的組件模型（比如幾個不同團隊開發的模塊）集成在一起運行測試和檢查，同樣可以驗證上面a-f項的很多要求。
  • 優勢： 更早發現問題（Shift-Left），降低后期集成風險，節省時間和成本。測試模型通常比測試硬件更容易設置和執行。
  • 驗證方法（模型級別）：
    • 模型在環測試（MIL - Model-in-the-Loop）： 將集成的組件模型放在仿真環境中運行測試用例（包括功能、魯棒性測試）。
    • 軟件在環測試（SIL - Software-in-the-Loop）： 將組件模型自動生成代碼后，在PC上運行該代碼進行測試。
    • 檢查（通過模型驗證工具）：
      • 檢查模型集成結構是否與架構設計一致（對應a）。
      • 接口信號的連接在模型級別是否正確（對應a,b）。
      • 在模型中添加的監控和診斷邏輯（安全措施模型）能否檢測錯誤輸入或內部模型錯誤（對應d魯棒性、可信賴性，f安全措施有效性）。
      • 估算模型（或生成代碼）的資源消耗（對應e）。
  • 例子： ADAS團隊開發了雷達數據處理模型，車輛動力學團隊開發了制動控制模型。在正式將代碼刷入ECU前，先將這兩個模型在仿真環境中連接起來進行集成測試（MIL/SIL）。測試場景：模擬前方車輛突然減速 -> 雷達模型探測到并輸出目標信息 -> 制動控制模型接收并計算需要的制動力。驗證這個過程是否符合架構設計（a），接口是否匹配（b），制動力計算是否正確（c），資源消耗是否合理（e）。同時可以注入雷達信號丟失錯誤，檢驗模型中內置的“信號有效性檢查”安全機制是否能檢測并觸發警告（d, f）。