近年來，中國汽車產業在電動化、智能化浪潮中快速發展，整車、電池與智能座艙等領域已逐步建立起全球影響力，但在車載軟件、底層芯片及電子電氣架構等核心技術方面仍面臨嚴峻挑戰。

2025年9月10日，在蓋世汽車主辦的第五屆未來汽車AI計算大會上，Qt Group質量保證產品中國區技術負責人劉相全指出，在汽車電子、航空航天等高安全要求的嵌入式系統中，嚴格的軟件架構設計是系統安全運行的核心前提。尤其在ISO 26262標準下，不同ASIL等級（如ASIL-D）的組件必須實現“免于干擾”，即高風險組件的故障不得影響低安全級組件。傳統的開發流程中，架構問題往往在集成測試階段才被發現，此時修復成本極高，而通過靜態架構檢查方法，可在編碼階段早期識別架構偏差，大幅提升開發效率與系統可靠性。

同時，他也指出靜態分析雖能有效解決軟件層面的系統故障，但仍需結合其他手段處理偶發性故障、工具鏈及硬件問題，并需確保源代碼無未定義行為。劉相全表示，對于已采用靜態架構驗證的用戶，實施分區架構驗證以保障免于干擾將變得簡單。

劉相全 | Qt Group質量保證產品 中國區技術負責人

以下為演講內容整理：

免于干擾與故障傳播控制

“免于干擾”指系統中某一分區的故障不應引發其他分區發生連鎖故障。劉相全舉例說明，例如低安全等級（QM）或較低ASIL等級的組件應與高ASIL等級組件實現隔離。ISO 26262中明確指出了可能導致干擾的多種故障類別，包括時序與執行問題（如阻塞、死鎖、活鎖）、內存錯誤（如數據損壞、棧溢出、非法內存訪問）以及信息交換異常（如數據重復、丟失、插入）等。

他強調，這些問題若在開發后期甚至車輛路測中暴露，將導致項目周期延長和成本上升。因此，最佳實踐是在軟件編譯和持續集成（CI）階段即引入自動化架構檢查機制，實現“安全左移”。

圖源：Qt Group

架構檢查的三要素與基本流程

架構檢查的實現依賴于三個核心要素：架構模型、源代碼及其之間的映射關系。

架構模型通常包括組件及其允許的關系，可采用多種形式定義，如文本描述（Word或Python腳本）、UML圖形或帶有節點與邊的注視圖。源代碼則需編譯為中間表示形式，以提取實體間的依賴關系。第三，需建立從源碼至架構元素的映射關系。

架構檢查算法主要分為兩步：首先，識別源代碼中的所有依賴，并將其與架構模型中定義的允許關系進行比對，結果分為“收斂”（符合設計，綠色箭頭）、“分歧”（違反設計，紅色箭頭）；其次，檢查是否所有架構模型中定義的依賴都在代碼中實現，避免出現“缺失”（黃色箭頭）。

圖源：Qt Group

分區架構檢查在FFI中的應用

在基礎架構檢查的基礎上，可進一步實施分區架構檢查，以系統性地驗證“免于干擾”（FFI）要求。該流程首先需為每個軟件組件標注其安全等級，例如QM、ASIL-A、ASIL-B或ASIL-D；隨后明確分區之間的依賴規則，例如允許低ASIL等級的組件調用高ASIL組件，但嚴禁低ASIL組件對高ASIL組件的數據進行寫入操作；接著將這些規則轉化為可驗證的FFI架構模型；最終通過運行自動化檢查，精準識別出所有違規的訪問或調用行為，從而確保不同安全等級組件之間的有效隔離與系統功能安全。

劉相全現場展示了一個示例，其中QM分區組件非法調用了ASIL-B分區接口，以及ASIL-B組件錯誤寫入ASIL-D數據區——這些違規行為均被工具以紅色箭頭標出，而符合預期的訪問則顯示為綠色。他指出，這一方法可大幅提高安全審計效率，并適用于現有架構模型的擴展與自動化驗證。

靜態分析的優勢與局限

盡管靜態架構檢查能有效識別多數軟件層面的系統故障，劉相全也坦言其存在一定局限。靜態分析通常會高估指針和數組訪問范圍，可能引入誤報；它無法處理硬件隨機故障或工具鏈本身的問題，也不能替代動態測試、硬件在環（HIL）或故障注入測試。

他強調，該技術的前提是源代碼中不能包含未定義行為，建議開發團隊首先借助MISRA等編碼規范消除此類隱患。此外，架構檢查仍可部分輔助識別競爭條件、時序違規及模塊接口誤用等問題。

劉相全總結道，在實現“免于干擾”的過程中，基于架構的靜態檢查是一項必要且高效的技術手段。尤其當團隊已在使用架構驗證工具時，擴展至安全分區驗證只需增加安全標簽標注，其余流程可實現高度自動化。

他代表Qt Group提出，使用如Axivion等靜態分析工具，可在開發早期實現架構與代碼一致性檢查，并支持FFI驗證。最后，他邀請觀眾申請工具試用，進一步了解其在持續集成環境中的實際效果。最后，劉相全表示，Qt Group將持續致力于為中國汽車及嵌入式行業提供可靠的安全軟件開發和驗證解決方案。