車載智能計算平臺作為智能汽車的安全關鍵系統，軟件層面的安全性至關重要。由于車載智能計算平臺功能豐富，應用場景復雜，對軟件的實時性、安全性、可靠性要求極高，應通過技術和流程兩個方面保障軟件的功能安全。技術上確保軟件層級的每個功能安全相關軟件節點都有相應的故障監測和處理機制，流程上按照軟件安全生命周期模型規范軟件開發過程。基于參考階段模型,為軟件層面產品開發進行生命周期的剪裁。

軟件開發參考階段模型

01

軟件安全要求

車載智能計算平臺軟件安全要求是對軟件安全相關的功能和性能的具體要求，主要是通過技術安全要求在軟件層面的分配得到，并通過繼承或分配得到相應的ASIL等級。另外，在軟件架構階段執行的軟件安全分析也可能會識別出額外的軟件安全要求。采用專業的需求管理工具來實現需求的編寫、評審、管理以及雙向追溯性檢查可大幅降低軟件層面的系統性安全風險。 ?

02

軟件架構設計

軟件架構設計是對軟件需求的設計與實現，用來描述軟件的框架要素和軟件各分層結構之間的相互作用，其范圍層面應到能夠識別所有軟件單元的程度。軟件架構設計不僅需滿足相應ASIL等級的軟件安全要求，還應滿足軟件其他非安全要求。在軟件架構層面，軟件安全要求會分層次地分配給軟件組件直到軟件單元，每個軟件組件應按照分配給它的安全要求中最高的ASIL等級來開發。

車載智能計算平臺應在軟件架構設計階段進行軟件安全分析和相關失效分析，完善錯誤探測和錯誤處理的安全機制，以便識別或確認軟件安全相關部分，證明軟件的安全相關的功能和性能滿足相應的ASIL要求，支持安全措施的定義及其有效性。

車載智能計算平臺軟件架構設計完成后，應對其開展驗證活動，輸出軟件驗證報告，證明軟件架構設計嚴格遵守設計規則，兼容目標環境，滿足相應ASIL等級的需求，并且相關評審證據充足。 ? 軟件安全設計依然可以從E-Gas三層架構中提取關鍵設計理念。

E-Gas針對的典型系統，基本的思想是外圍系統—內部系統，內部系統分為傳感器、控制器和執行器。在這個系統概念里，傳感器是加速踏板傳感器，控制器是ECU（Engine Control Unit），執行器是節氣門。展開安全架構設計的時候，需要時刻關注將系統解耦和模塊化，這對于軟件的安全設計是非常重要的。

?

E-Gas典型系統組成及邊界 ? 關于E-Gas安全架構的核心理念和設計，這里再回顧一下，整體設計分為Level1、Level2和Level3，其定義如下：

?

E-Gas三層安全架構（帶鎖步核） ?

（1）Level1：功能層，包括扭矩的解析、功能的診斷等，最直接的理解就是能夠實現設計基本功能的軟件及相關硬件資源的組合。

（2）Level2：功能監控層，負責監控功能層的輸出結論，簡單理解來看，就是軟件的冗余校驗，但是，由于不想消耗太多資源及避免算法共因，所以基于功能結果的監控。

（3）Level3：硬件監控層，負責確保Level1和Level2的運行的硬件環境是正常工作的，異常的運行環境會導致Level2的設計起不到很好效果，因此，Level3在整體的監控架構中作用是不可替代的。 ?

下圖是Level2算法架構的一個示例（汽油歧管噴射），其整體思想是計算實際系統輸出的扭矩和此刻系統允許輸出的安全現值之間的差值，當差值大于一定數值及一定時間時，采用相應的故障動作。

同時，方案為了避免出現誤報或者漏報的情況，每一項用于計算的信號或者相應的傳感器都應該具有相應的診斷及故障動作，這也是軟件開展功能安全設計很關鍵的理念，輸入信號是需要高完整性和準確性的。

?

三層架構Level2算法架構示例 ? 針對Level3的硬件監控層，需要涉及軟件和硬件的交互，監控的機制可以通過軟件實現，也可以通過硬件實現。這里羅列了E-Gas中涉及軟件方面的問題： ?

（1）ROM檢查：針對ROM的檢查，主要是涉及數據翻轉、錯誤的刷寫、錯誤的數據等，軟件在其中扮演著檢測對比算法的角色，當然，ROM的檢查通過硬件也可以實現。

（2）應答機制檢查：軟件需要在設定時間窗口內正確回答獨立硬件監控單元的問題，如果超時或者回答錯誤一定次數，都會觸發重置或者下電。

（3）指令集檢查：指令集是處理器核心的計算最基本單元，也是Level2監控算法正確執行的基礎，確保指令集的正確可以采用軟件輔助計算應答方法，或者采用目前診斷覆蓋率更高的鎖步核機制冗余校驗（Lockstep-Core）。

（4）程序流檢查：監控算法、診斷算法等都是周期性按順序執行的，因此，執行時序也需要進行檢查。 ?

通過E-Gas的三層經典架構，我們可以分析出軟件層級的功能安全設計需要考慮的軟件包括Level1的功能層軟件、Level2的監控層軟件以及Level3的部分支持硬件監控層軟件。 ?

對于Level1功能軟件，它本身的失效在整體架構中并不會違反安全目標，理應可以按照QM來開發，但考慮到軟件本身的可靠性，建議依照ASIL-A或者ASPICE CL2級進行開發，畢竟，一個產品只確保安全但可靠性很差是沒有辦法交付給客戶的；對于Level2和Level3的軟件，按照安全分析，需要依靠系統的最高ASIL等級開發。 ?

軟件開發遵循原則參考

?

當然，并不是說非三層架構設計軟件無法實現功能安全開發或者產品無法符合功能安全要求。E-Gas三層架構能夠很清晰地實現層級遞進式的監控設計，尤其適用于功能軟件復雜的產品。

如果功能軟件相對復雜，高ASIL等級的產品在導致軟件開發的工作量大量增加的同時安全性也很難兼顧；當然，如果應用層軟件相對簡單（例如濾波算法、局部優化、狀態機等函數），采用下表所列方式會更好。 ?

非三層架構開發遵循原則參考

?

對于功能安全軟件設計而言，軟件架構設計一個重要的目標是使軟件需求的實現過程以一種完整的、正確的同時盡可能簡單、可理解和可驗證的方式展現，從而在軟件需求實現過程中，盡可能降低由于設計錯誤造成違反功能安全需求的可能性。

功能安全要求軟件架構的設計具備以下屬性：可理解性，一致性，簡單性，可驗證，模塊化，層次化，按層逐步細化、封裝，低耦合性，可維護性。對于可理解性，ISO 26262中按照不同的ASIL等級規定了不同的軟件架構設計的表示方式。 ?

軟件架構設計符號說明

?

常見的幾種軟件架構安全分析方法包括SW-FMEA、SW-FTA及SW-DFA。 ?

A、SW-FMEA

SW-FMEA以硬件組件和軟件模塊之間的接口或軟件模塊和軟件模塊之間的接口為分析對象，列舉硬件組件接口或軟件模塊的失效模式，分析失效模式對后續軟件模塊或者軟件需求的影響，尤其是與功能安全相關的影響。在明確失效模式和失效后果的基礎上，去尋找造成硬件組件接口或軟件模塊的原因，并且對原因施加控制措施。 ?

2.SW-FTA

SW-FTA探究的重點是軟件架構中多點錯的發生對軟件功能安全需求的影響。SW-FTA分析過程從軟件功能安全需求出發，從軟件架構設計中所有軟件模塊和軟件接口的失效模式中去尋找和當前軟件功能安全需求相關的失效模式，并且識別出這些失效模式和當前軟件功能安全需求的相關性（單點失效還是多點失效）。 ?

3.SW-DFA

SW-DFA在標準中定義的從屬故障（Dependent failure）包括級聯故障（Cascading failure）和共因故障（Common cause failure）。通常可以從以下幾個方面來考慮Dependent failure 中Cascading failure的部分： ?

時間和調度問題造成Cascading failure。比如，由于其他模塊運行時間過長導致目標模塊無法運行，死鎖、活鎖、饑餓等現象導致模塊運行停滯或者延遲，軟件模塊之間的同步性問題或者優先級問題導致調度次序出現問題。 ?

存儲空間問題造成Cascading failure。比如，目標存儲區域被其他軟件模塊誤篡改，軟件模塊之間對于同一存儲空間的讀寫操作配合問題導致數據不一致（讀數據的同時允許寫數據），棧溢出等問題。 ?

軟件模塊之間的通信（ 尤其是ECU 間的通信） 問題造成Cascading failure。時間和調度問題造成Cascading failure。 ?

隨著ASIL等級的提升，ISO 26262從語法和語義兩個維度出發，從最低要求的自然語言描述到半正式的表述方式，逐步加強對表述方式的理解一致性的要求。為了避免系統性失效，ISO 26262對軟件架構設計提出了一些設計原則。 ?

軟件架構設計原則

?

ISO 26262對軟件架構設計驗證

方法

03

軟件單元設計與實現 ?

在軟件單元設計與實現階段，基于軟件架構設計對車載智能計算平臺的軟件單元進行詳細設計。軟件單元設計應滿足其所分配的ASIL等級要求，與軟件架構設計和軟硬件接口設計相關內容保持一致。為了避免系統性失效，應確保軟件單元設計的一致性、可理解性、可維護性和可驗證性，采用自然語言與半形式化方法相結合的方式進行描述。

說明書應描述實施細節層面的功能行為和內部設計，包括數據存儲和寄存器的使用限制。在源代碼層面的設計與實施應使得軟件單元設計簡單易懂，軟件修改適宜，具有可驗證性和魯棒性，確保軟件單元中子程序或函數執行的正確次序，軟件單元之間接口的一致性，軟件單元內部及軟件單元之間數據流和控制流的正確性。

車載智能計算平臺軟件包含數百個軟件單元，軟件單元的標準化、單元間解耦是高效實現軟件功能安全的基礎。車載智能計算平臺中不同安全等級的軟件可以采用硬件虛擬化、容器、內存隔離等技術進行隔離，防止軟件單元之間的級聯失效。 ?

軟件代碼設計過程中應遵守成熟的代碼設計規范，例如MISRA C。MISRA C是由汽車產業軟件可靠性協會（MISRA）提出的C語言開發標準。其目的是在增進嵌入式系統的安全性及可移植性，針對C++語言也有對應的標準MISRA C++。MISRA C一開始主要是針對汽車產業，不過其他產業也逐漸開始使用MISRA C：包括航天、電信、國防、醫療設備、鐵路等領域中都已有廠商使用MISRA C。

MISRA C的第一版《Guidelines for the use of the C language in vehicle based software》是在1998年發行，一般稱為MISRA-C:1998.。MISRA-C:1998有127項規則，規則從1號編號到127號，其中有93項是強制要求，其余的34項是推薦使用的規則。

在2004年時發行了第二版的MISRA C的第一版《Guidelines for the use of the C language in critical systems》（或稱作MISRA-C:2004），其中有許多重要建議事項的變更，其規則也重新編號。MISRA-C:2004有141項規則，其中121項是強制要求，其余的20項是推薦使用的規則。

規則分為21類，從“開發環境”到“運行期錯誤”。2012年發布第三版，為當前最新有效的C語言規范版本，稱為MISRA C:2012。企業可以基于MISRAC建立一套滿足車載智能計算平臺安全編碼要求的內部編碼規范，并嚴格執行。 ?

ISO 26262軟件單元設計和實現的設計原則

04

軟件單元驗證 ?

軟件單元驗證是通過評審、分析和測試的方法對功能安全相關的軟件單元設計與實現進行驗證，證明軟件相關安全措施已經在設計與實現中全部落實。軟件單元設計滿足相應的ASIL等級的軟件需求和軟硬件接口規范要求，軟件源代碼的實現與單元設計一致，不存在非期望的功能和性能，且支持功能和性能實現的相關資源充足。 ?

車載智能計算平臺的軟件單元驗證可參考下表，通過需求分析、等價類的生成與分析、邊界值分析和錯誤推測相結合的方法合理設計測試用例，確保對軟件單元進行充分驗證。為了評估軟件單元驗證的完整性，為單元測試的充分性提供證據，應確定在軟件單元層面的需求覆蓋率，同時對結構覆蓋率進行測定。

車載智能計算平臺軟件單元測試的結構覆蓋率目標為100%，如果已實現結構覆蓋率不能達到目標，可以定義額外的測試用例并提供接受理由。車載智能計算平臺軟件單元的結構覆蓋率測試應采用滿足相關安全要求的測試工具，確保在測試過程中測試工具和檢測代碼不會對測試結果產生影響。 ?

車載智能計算平臺軟件單元測試應根據測試范圍，選用適當的測試環境。測試環境應適合完成測試目標，盡可能接近目標環境，如果不是在目標環境執行，應分析源代碼與目標代碼的差異、測試環境和目標環境之間的差異，以便在后續測試階段的目標環境中，定義額外的測試。 ?

軟件單元驗證方法

?

軟件單元測試用例的得出方法

05

軟件集成驗證 ?

軟件集成驗證需要根據軟件驗證計劃、接口規范、軟件架構設計規范、軟件驗證規范等對軟件架構中所描述的集成層次、接口、功能等進行持續測試，以驗證其與設計的符合性。由于車載智能計算平臺軟件的復雜性，實時性、可靠性、安全性既是設計目標也是基礎性能，集成測試設計階段應對其功能、邏輯、性能、邊界、接口進行詳細分析。

車載智能計算平臺的軟件集成驗證參考下表，不僅需涵蓋所有應用軟件、功能軟件、系統軟件以及與硬件之間的接口，并且應涵蓋軟件單元之間的接口。

測試用例在測試工作中至關重要，其輸出需要考慮功能需求、性能需求、邊界值、接口、邏輯關系等。 ?

軟件集成驗證方法

? 軟件集成測試用例的得出方法

06

嵌入式軟件測試 ?

車載智能計算平臺嵌入式軟件測試主要是基于軟件安全要求的測試可參考下表，針對軟件安全要求進行充分的故障注入測試，最終確保軟件安全要求的正確實現。

為了驗證車載智能計算平臺軟件在目標環境下是否滿足軟件安全要求，應進行硬件在環測試、車輛電控系統和網絡通信環境下的測試以及實車測試。硬件在環測試是將車載智能計算平臺軟件燒寫到目標芯片中，在目標芯片的硬件異構平臺環境下驗證軟件的安全要求。

然后，將車載智能計算平臺與部分或全部的車輛電子電氣設備進行網絡通信，在車輛電控系統和網絡環境下驗證軟件的安全要求。最后，將車載智能計算平臺安裝到實際車輛中，進行軟件安全要求的驗證與確認。 ? ?

嵌入式軟件的測試方法

? ?

嵌入式軟件測試用例的得出方法

07

人工智能 ?

通過實施完善的開發流程可降低車載智能計算平臺人工智能的系統性安全風險。車載智能計算平臺人工智能的開發包含需求分析、算法設計、數據采集和標注、模型訓練、測試驗證以及運行等流程。 ?

人工智能的需求分析應包含算法的基本功能需求和功能安全要求（如算法精度目標、算法Fail-Operational等）。算法設計階段應考慮采用多算法、多模型、多幀數據、多傳感器等多種冗余機制的組合以提升安全性。數據采集和標注階段應確保數據標注精度、數據場景分布，并避免數據錯標和漏標，從而確保模型訓練不受影響。模型訓練階段采用業界成熟、文檔全面的人工智能框架。

測試驗證階段對所有需求進行閉環的測試，同時全面考慮各種潛在應用場景及環境影響因素，進行長距離的實車試驗。根據測試結果不斷重復進行數據的采集、標注、模型訓練和測試驗證的階段，通過迭代的方式逐步提高人工智能的安全性。在運行階段，應持續地對實際運行數據和人工智能的安全性進行監控，通過分析實際運行數據對人工智能算法和模型不斷優化。 ?

08

軟件階段常用工具介紹 ?

a、Polyspace

Polyspace Bug Finder可以識別嵌入式軟件C和C++代碼中的運行時錯誤、并發問題、安全漏洞和其他缺陷。使用靜態分析（包括語義分析），Polyspace Bug Finder可分析軟件控制流、數據流和進程間行為。通過在檢測到缺陷之后立即高亮顯示缺陷，可在開發過程的早期階段鑒別和修復錯誤。

Polyspace Bug Finder可檢查是否符合編碼規范，如MISRA C、MISRA C++、JSF++、CERT C、CERT C++和自定義命名規范。它可以生成報告，其中包括發現的錯誤、代碼違規和代碼質量指標，如圈復雜度。Polyspac eBug Finder可與Eclipse IDE配合使用進行代碼分析。

?

Polyspace軟件截圖 ?

b、Tessy

Tessy軟件源自戴姆勒—奔馳公司的軟件技術實驗室，由德國Hitex公司負責全球銷售及技術支持服務，是一款專門針對嵌入式軟件動態測試的工具。它可以對C/C++代碼進行單元、集成測試，可以自動化搭建測試環境、執行測試、評估測試結果并生成測試報告等。

多樣化的測試用例導入生成方式和與測試需求關聯的特色，使Tessy在測試組織和測試管理上也發揮了良好的作用，目前，Tessy廣泛應用汽車電子主流客戶中。Tessy滿足各類標準（如ISO 26262、IEC61508）對測試的需求，比如Tessy可以滿足ISO 26262中各個測試等級對模塊測試的要求，當然，Tessy本身也通過了TüV的認證，證明該軟件是安全可靠的，可以在安全相關的軟件研發過程中使用。

?

Tessy 軟件截圖 ?

c、Helix QAC

Helix QAC是靜態代碼分析工具，依據C和C++編碼規則自動掃描代碼對規則的違背。在開發過程的早期就可以用它來檢測缺陷，因為此時修改代碼是最方便也最經濟的。Helix QAC自動化強制實施代碼編程標準，比如，MISRA保證代碼的合規性。

Helix QAC識別必須修改的缺陷，提供詳細的指導，幫助開發人員修改問題。這是不需要運行程序的。開發人員既然獲得了即時的上下文反饋，他們將因此從錯誤中獲得學習，下一次編寫新的代碼（或者評審代碼）時，能力將得到提升。Helix QAC自動審查代碼，確保它們符合用戶選擇的編碼標準。

合規性報告可視化地提醒用戶哪些代碼需要多加留意。Helix QAC支持多種C和C++編碼標準，提供相應的合規性模塊，也支持標準的客戶化定制。

? ?

Helix QAC軟件截圖 ??





審核編輯：劉清