車載智能計算平臺作為智能汽車的安全關(guān)鍵系統(tǒng),軟件層面的安全性至關(guān)重要。由于車載智能計算平臺功能豐富,應(yīng)用場景復(fù)雜,對軟件的實時性、安全性、可靠性要求極高,應(yīng)通過技術(shù)和流程兩個方面保障軟件的功能安全。技術(shù)上確保軟件層級的每個功能安全相關(guān)軟件節(jié)點都有相應(yīng)的故障監(jiān)測和處理機制,流程上按照軟件安全生命周期模型規(guī)范軟件開發(fā)過程?;趨⒖茧A段模型,為軟件層面產(chǎn)品開發(fā)進行生命周期的剪裁。
軟件開發(fā)參考階段模型
01
軟件安全要求
車載智能計算平臺軟件安全要求是對軟件安全相關(guān)的功能和性能的具體要求,主要是通過技術(shù)安全要求在軟件層面的分配得到,并通過繼承或分配得到相應(yīng)的ASIL等級。另外,在軟件架構(gòu)階段執(zhí)行的軟件安全分析也可能會識別出額外的軟件安全要求。采用專業(yè)的需求管理工具來實現(xiàn)需求的編寫、評審、管理以及雙向追溯性檢查可大幅降低軟件層面的系統(tǒng)性安全風(fēng)險。 ?
02
軟件架構(gòu)設(shè)計
軟件架構(gòu)設(shè)計是對軟件需求的設(shè)計與實現(xiàn),用來描述軟件的框架要素和軟件各分層結(jié)構(gòu)之間的相互作用,其范圍層面應(yīng)到能夠識別所有軟件單元的程度。軟件架構(gòu)設(shè)計不僅需滿足相應(yīng)ASIL等級的軟件安全要求,還應(yīng)滿足軟件其他非安全要求。在軟件架構(gòu)層面,軟件安全要求會分層次地分配給軟件組件直到軟件單元,每個軟件組件應(yīng)按照分配給它的安全要求中最高的ASIL等級來開發(fā)。
車載智能計算平臺應(yīng)在軟件架構(gòu)設(shè)計階段進行軟件安全分析和相關(guān)失效分析,完善錯誤探測和錯誤處理的安全機制,以便識別或確認軟件安全相關(guān)部分,證明軟件的安全相關(guān)的功能和性能滿足相應(yīng)的ASIL要求,支持安全措施的定義及其有效性。
車載智能計算平臺軟件架構(gòu)設(shè)計完成后,應(yīng)對其開展驗證活動,輸出軟件驗證報告,證明軟件架構(gòu)設(shè)計嚴格遵守設(shè)計規(guī)則,兼容目標環(huán)境,滿足相應(yīng)ASIL等級的需求,并且相關(guān)評審證據(jù)充足。 ? 軟件安全設(shè)計依然可以從E-Gas三層架構(gòu)中提取關(guān)鍵設(shè)計理念。
E-Gas針對的典型系統(tǒng),基本的思想是外圍系統(tǒng)—內(nèi)部系統(tǒng),內(nèi)部系統(tǒng)分為傳感器、控制器和執(zhí)行器。在這個系統(tǒng)概念里,傳感器是加速踏板傳感器,控制器是ECU(Engine Control Unit),執(zhí)行器是節(jié)氣門。展開安全架構(gòu)設(shè)計的時候,需要時刻關(guān)注將系統(tǒng)解耦和模塊化,這對于軟件的安全設(shè)計是非常重要的。
?
E-Gas典型系統(tǒng)組成及邊界 ? 關(guān)于E-Gas安全架構(gòu)的核心理念和設(shè)計,這里再回顧一下,整體設(shè)計分為Level1、Level2和Level3,其定義如下:
?
E-Gas三層安全架構(gòu)(帶鎖步核) ?
(1)Level1:功能層,包括扭矩的解析、功能的診斷等,最直接的理解就是能夠?qū)崿F(xiàn)設(shè)計基本功能的軟件及相關(guān)硬件資源的組合。
(2)Level2:功能監(jiān)控層,負責監(jiān)控功能層的輸出結(jié)論,簡單理解來看,就是軟件的冗余校驗,但是,由于不想消耗太多資源及避免算法共因,所以基于功能結(jié)果的監(jiān)控。
(3)Level3:硬件監(jiān)控層,負責確保Level1和Level2的運行的硬件環(huán)境是正常工作的,異常的運行環(huán)境會導(dǎo)致Level2的設(shè)計起不到很好效果,因此,Level3在整體的監(jiān)控架構(gòu)中作用是不可替代的。 ?
下圖是Level2算法架構(gòu)的一個示例(汽油歧管噴射),其整體思想是計算實際系統(tǒng)輸出的扭矩和此刻系統(tǒng)允許輸出的安全現(xiàn)值之間的差值,當差值大于一定數(shù)值及一定時間時,采用相應(yīng)的故障動作。
同時,方案為了避免出現(xiàn)誤報或者漏報的情況,每一項用于計算的信號或者相應(yīng)的傳感器都應(yīng)該具有相應(yīng)的診斷及故障動作,這也是軟件開展功能安全設(shè)計很關(guān)鍵的理念,輸入信號是需要高完整性和準確性的。
?
三層架構(gòu)Level2算法架構(gòu)示例 ? 針對Level3的硬件監(jiān)控層,需要涉及軟件和硬件的交互,監(jiān)控的機制可以通過軟件實現(xiàn),也可以通過硬件實現(xiàn)。這里羅列了E-Gas中涉及軟件方面的問題: ?
(1)ROM檢查:針對ROM的檢查,主要是涉及數(shù)據(jù)翻轉(zhuǎn)、錯誤的刷寫、錯誤的數(shù)據(jù)等,軟件在其中扮演著檢測對比算法的角色,當然,ROM的檢查通過硬件也可以實現(xiàn)。
(2)應(yīng)答機制檢查:軟件需要在設(shè)定時間窗口內(nèi)正確回答獨立硬件監(jiān)控單元的問題,如果超時或者回答錯誤一定次數(shù),都會觸發(fā)重置或者下電。
(3)指令集檢查:指令集是處理器核心的計算最基本單元,也是Level2監(jiān)控算法正確執(zhí)行的基礎(chǔ),確保指令集的正確可以采用軟件輔助計算應(yīng)答方法,或者采用目前診斷覆蓋率更高的鎖步核機制冗余校驗(Lockstep-Core)。
(4)程序流檢查:監(jiān)控算法、診斷算法等都是周期性按順序執(zhí)行的,因此,執(zhí)行時序也需要進行檢查。 ?
通過E-Gas的三層經(jīng)典架構(gòu),我們可以分析出軟件層級的功能安全設(shè)計需要考慮的軟件包括Level1的功能層軟件、Level2的監(jiān)控層軟件以及Level3的部分支持硬件監(jiān)控層軟件。 ?
對于Level1功能軟件,它本身的失效在整體架構(gòu)中并不會違反安全目標,理應(yīng)可以按照QM來開發(fā),但考慮到軟件本身的可靠性,建議依照ASIL-A或者ASPICE CL2級進行開發(fā),畢竟,一個產(chǎn)品只確保安全但可靠性很差是沒有辦法交付給客戶的;對于Level2和Level3的軟件,按照安全分析,需要依靠系統(tǒng)的最高ASIL等級開發(fā)。 ?
軟件開發(fā)遵循原則參考
?
當然,并不是說非三層架構(gòu)設(shè)計軟件無法實現(xiàn)功能安全開發(fā)或者產(chǎn)品無法符合功能安全要求。E-Gas三層架構(gòu)能夠很清晰地實現(xiàn)層級遞進式的監(jiān)控設(shè)計,尤其適用于功能軟件復(fù)雜的產(chǎn)品。
如果功能軟件相對復(fù)雜,高ASIL等級的產(chǎn)品在導(dǎo)致軟件開發(fā)的工作量大量增加的同時安全性也很難兼顧;當然,如果應(yīng)用層軟件相對簡單(例如濾波算法、局部優(yōu)化、狀態(tài)機等函數(shù)),采用下表所列方式會更好。 ?
非三層架構(gòu)開發(fā)遵循原則參考
?
對于功能安全軟件設(shè)計而言,軟件架構(gòu)設(shè)計一個重要的目標是使軟件需求的實現(xiàn)過程以一種完整的、正確的同時盡可能簡單、可理解和可驗證的方式展現(xiàn),從而在軟件需求實現(xiàn)過程中,盡可能降低由于設(shè)計錯誤造成違反功能安全需求的可能性。
功能安全要求軟件架構(gòu)的設(shè)計具備以下屬性:可理解性,一致性,簡單性,可驗證,模塊化,層次化,按層逐步細化、封裝,低耦合性,可維護性。對于可理解性,ISO 26262中按照不同的ASIL等級規(guī)定了不同的軟件架構(gòu)設(shè)計的表示方式。 ?
軟件架構(gòu)設(shè)計符號說明
?
常見的幾種軟件架構(gòu)安全分析方法包括SW-FMEA、SW-FTA及SW-DFA。 ?
A、SW-FMEA
SW-FMEA以硬件組件和軟件模塊之間的接口或軟件模塊和軟件模塊之間的接口為分析對象,列舉硬件組件接口或軟件模塊的失效模式,分析失效模式對后續(xù)軟件模塊或者軟件需求的影響,尤其是與功能安全相關(guān)的影響。在明確失效模式和失效后果的基礎(chǔ)上,去尋找造成硬件組件接口或軟件模塊的原因,并且對原因施加控制措施。 ?
2.SW-FTA
SW-FTA探究的重點是軟件架構(gòu)中多點錯的發(fā)生對軟件功能安全需求的影響。SW-FTA分析過程從軟件功能安全需求出發(fā),從軟件架構(gòu)設(shè)計中所有軟件模塊和軟件接口的失效模式中去尋找和當前軟件功能安全需求相關(guān)的失效模式,并且識別出這些失效模式和當前軟件功能安全需求的相關(guān)性(單點失效還是多點失效)。 ?
3.SW-DFA
SW-DFA在標準中定義的從屬故障(Dependent failure)包括級聯(lián)故障(Cascading failure)和共因故障(Common cause failure)。通常可以從以下幾個方面來考慮Dependent failure 中Cascading failure的部分: ?
時間和調(diào)度問題造成Cascading failure。比如,由于其他模塊運行時間過長導(dǎo)致目標模塊無法運行,死鎖、活鎖、饑餓等現(xiàn)象導(dǎo)致模塊運行停滯或者延遲,軟件模塊之間的同步性問題或者優(yōu)先級問題導(dǎo)致調(diào)度次序出現(xiàn)問題。 ?
存儲空間問題造成Cascading failure。比如,目標存儲區(qū)域被其他軟件模塊誤篡改,軟件模塊之間對于同一存儲空間的讀寫操作配合問題導(dǎo)致數(shù)據(jù)不一致(讀數(shù)據(jù)的同時允許寫數(shù)據(jù)),棧溢出等問題。 ?
軟件模塊之間的通信( 尤其是ECU 間的通信) 問題造成Cascading failure。時間和調(diào)度問題造成Cascading failure。 ?
隨著ASIL等級的提升,ISO 26262從語法和語義兩個維度出發(fā),從最低要求的自然語言描述到半正式的表述方式,逐步加強對表述方式的理解一致性的要求。為了避免系統(tǒng)性失效,ISO 26262對軟件架構(gòu)設(shè)計提出了一些設(shè)計原則。 ?
軟件架構(gòu)設(shè)計原則
?
ISO 26262對軟件架構(gòu)設(shè)計驗證
方法
03
軟件單元設(shè)計與實現(xiàn) ?
在軟件單元設(shè)計與實現(xiàn)階段,基于軟件架構(gòu)設(shè)計對車載智能計算平臺的軟件單元進行詳細設(shè)計。軟件單元設(shè)計應(yīng)滿足其所分配的ASIL等級要求,與軟件架構(gòu)設(shè)計和軟硬件接口設(shè)計相關(guān)內(nèi)容保持一致。為了避免系統(tǒng)性失效,應(yīng)確保軟件單元設(shè)計的一致性、可理解性、可維護性和可驗證性,采用自然語言與半形式化方法相結(jié)合的方式進行描述。
說明書應(yīng)描述實施細節(jié)層面的功能行為和內(nèi)部設(shè)計,包括數(shù)據(jù)存儲和寄存器的使用限制。在源代碼層面的設(shè)計與實施應(yīng)使得軟件單元設(shè)計簡單易懂,軟件修改適宜,具有可驗證性和魯棒性,確保軟件單元中子程序或函數(shù)執(zhí)行的正確次序,軟件單元之間接口的一致性,軟件單元內(nèi)部及軟件單元之間數(shù)據(jù)流和控制流的正確性。
車載智能計算平臺軟件包含數(shù)百個軟件單元,軟件單元的標準化、單元間解耦是高效實現(xiàn)軟件功能安全的基礎(chǔ)。車載智能計算平臺中不同安全等級的軟件可以采用硬件虛擬化、容器、內(nèi)存隔離等技術(shù)進行隔離,防止軟件單元之間的級聯(lián)失效。 ?
軟件代碼設(shè)計過程中應(yīng)遵守成熟的代碼設(shè)計規(guī)范,例如MISRA C。MISRA C是由汽車產(chǎn)業(yè)軟件可靠性協(xié)會(MISRA)提出的C語言開發(fā)標準。其目的是在增進嵌入式系統(tǒng)的安全性及可移植性,針對C++語言也有對應(yīng)的標準MISRA C++。MISRA C一開始主要是針對汽車產(chǎn)業(yè),不過其他產(chǎn)業(yè)也逐漸開始使用MISRA C:包括航天、電信、國防、醫(yī)療設(shè)備、鐵路等領(lǐng)域中都已有廠商使用MISRA C。
MISRA C的第一版《Guidelines for the use of the C language in vehicle based software》是在1998年發(fā)行,一般稱為MISRA-C:1998.。MISRA-C:1998有127項規(guī)則,規(guī)則從1號編號到127號,其中有93項是強制要求,其余的34項是推薦使用的規(guī)則。
在2004年時發(fā)行了第二版的MISRA C的第一版《Guidelines for the use of the C language in critical systems》(或稱作MISRA-C:2004),其中有許多重要建議事項的變更,其規(guī)則也重新編號。MISRA-C:2004有141項規(guī)則,其中121項是強制要求,其余的20項是推薦使用的規(guī)則。
規(guī)則分為21類,從“開發(fā)環(huán)境”到“運行期錯誤”。2012年發(fā)布第三版,為當前最新有效的C語言規(guī)范版本,稱為MISRA C:2012。企業(yè)可以基于MISRAC建立一套滿足車載智能計算平臺安全編碼要求的內(nèi)部編碼規(guī)范,并嚴格執(zhí)行。 ?
ISO 26262軟件單元設(shè)計和實現(xiàn)的設(shè)計原則
04
軟件單元驗證 ?
軟件單元驗證是通過評審、分析和測試的方法對功能安全相關(guān)的軟件單元設(shè)計與實現(xiàn)進行驗證,證明軟件相關(guān)安全措施已經(jīng)在設(shè)計與實現(xiàn)中全部落實。軟件單元設(shè)計滿足相應(yīng)的ASIL等級的軟件需求和軟硬件接口規(guī)范要求,軟件源代碼的實現(xiàn)與單元設(shè)計一致,不存在非期望的功能和性能,且支持功能和性能實現(xiàn)的相關(guān)資源充足。 ?
車載智能計算平臺的軟件單元驗證可參考下表,通過需求分析、等價類的生成與分析、邊界值分析和錯誤推測相結(jié)合的方法合理設(shè)計測試用例,確保對軟件單元進行充分驗證。為了評估軟件單元驗證的完整性,為單元測試的充分性提供證據(jù),應(yīng)確定在軟件單元層面的需求覆蓋率,同時對結(jié)構(gòu)覆蓋率進行測定。
車載智能計算平臺軟件單元測試的結(jié)構(gòu)覆蓋率目標為100%,如果已實現(xiàn)結(jié)構(gòu)覆蓋率不能達到目標,可以定義額外的測試用例并提供接受理由。車載智能計算平臺軟件單元的結(jié)構(gòu)覆蓋率測試應(yīng)采用滿足相關(guān)安全要求的測試工具,確保在測試過程中測試工具和檢測代碼不會對測試結(jié)果產(chǎn)生影響。 ?
車載智能計算平臺軟件單元測試應(yīng)根據(jù)測試范圍,選用適當?shù)臏y試環(huán)境。測試環(huán)境應(yīng)適合完成測試目標,盡可能接近目標環(huán)境,如果不是在目標環(huán)境執(zhí)行,應(yīng)分析源代碼與目標代碼的差異、測試環(huán)境和目標環(huán)境之間的差異,以便在后續(xù)測試階段的目標環(huán)境中,定義額外的測試。 ?
軟件單元驗證方法
?
軟件單元測試用例的得出方法
05
軟件集成驗證 ?
軟件集成驗證需要根據(jù)軟件驗證計劃、接口規(guī)范、軟件架構(gòu)設(shè)計規(guī)范、軟件驗證規(guī)范等對軟件架構(gòu)中所描述的集成層次、接口、功能等進行持續(xù)測試,以驗證其與設(shè)計的符合性。由于車載智能計算平臺軟件的復(fù)雜性,實時性、可靠性、安全性既是設(shè)計目標也是基礎(chǔ)性能,集成測試設(shè)計階段應(yīng)對其功能、邏輯、性能、邊界、接口進行詳細分析。
車載智能計算平臺的軟件集成驗證參考下表,不僅需涵蓋所有應(yīng)用軟件、功能軟件、系統(tǒng)軟件以及與硬件之間的接口,并且應(yīng)涵蓋軟件單元之間的接口。
測試用例在測試工作中至關(guān)重要,其輸出需要考慮功能需求、性能需求、邊界值、接口、邏輯關(guān)系等。 ?
軟件集成驗證方法
? 軟件集成測試用例的得出方法
06
嵌入式軟件測試 ?
車載智能計算平臺嵌入式軟件測試主要是基于軟件安全要求的測試可參考下表,針對軟件安全要求進行充分的故障注入測試,最終確保軟件安全要求的正確實現(xiàn)。
為了驗證車載智能計算平臺軟件在目標環(huán)境下是否滿足軟件安全要求,應(yīng)進行硬件在環(huán)測試、車輛電控系統(tǒng)和網(wǎng)絡(luò)通信環(huán)境下的測試以及實車測試。硬件在環(huán)測試是將車載智能計算平臺軟件燒寫到目標芯片中,在目標芯片的硬件異構(gòu)平臺環(huán)境下驗證軟件的安全要求。
然后,將車載智能計算平臺與部分或全部的車輛電子電氣設(shè)備進行網(wǎng)絡(luò)通信,在車輛電控系統(tǒng)和網(wǎng)絡(luò)環(huán)境下驗證軟件的安全要求。最后,將車載智能計算平臺安裝到實際車輛中,進行軟件安全要求的驗證與確認。 ? ?
嵌入式軟件的測試方法
? ?
嵌入式軟件測試用例的得出方法
07
人工智能 ?
通過實施完善的開發(fā)流程可降低車載智能計算平臺人工智能的系統(tǒng)性安全風(fēng)險。車載智能計算平臺人工智能的開發(fā)包含需求分析、算法設(shè)計、數(shù)據(jù)采集和標注、模型訓(xùn)練、測試驗證以及運行等流程。 ?
人工智能的需求分析應(yīng)包含算法的基本功能需求和功能安全要求(如算法精度目標、算法Fail-Operational等)。算法設(shè)計階段應(yīng)考慮采用多算法、多模型、多幀數(shù)據(jù)、多傳感器等多種冗余機制的組合以提升安全性。數(shù)據(jù)采集和標注階段應(yīng)確保數(shù)據(jù)標注精度、數(shù)據(jù)場景分布,并避免數(shù)據(jù)錯標和漏標,從而確保模型訓(xùn)練不受影響。模型訓(xùn)練階段采用業(yè)界成熟、文檔全面的人工智能框架。
測試驗證階段對所有需求進行閉環(huán)的測試,同時全面考慮各種潛在應(yīng)用場景及環(huán)境影響因素,進行長距離的實車試驗。根據(jù)測試結(jié)果不斷重復(fù)進行數(shù)據(jù)的采集、標注、模型訓(xùn)練和測試驗證的階段,通過迭代的方式逐步提高人工智能的安全性。在運行階段,應(yīng)持續(xù)地對實際運行數(shù)據(jù)和人工智能的安全性進行監(jiān)控,通過分析實際運行數(shù)據(jù)對人工智能算法和模型不斷優(yōu)化。 ?
08
軟件階段常用工具介紹 ?
a、Polyspace
Polyspace Bug Finder可以識別嵌入式軟件C和C++代碼中的運行時錯誤、并發(fā)問題、安全漏洞和其他缺陷。使用靜態(tài)分析(包括語義分析),Polyspace Bug Finder可分析軟件控制流、數(shù)據(jù)流和進程間行為。通過在檢測到缺陷之后立即高亮顯示缺陷,可在開發(fā)過程的早期階段鑒別和修復(fù)錯誤。
Polyspace Bug Finder可檢查是否符合編碼規(guī)范,如MISRA C、MISRA C++、JSF++、CERT C、CERT C++和自定義命名規(guī)范。它可以生成報告,其中包括發(fā)現(xiàn)的錯誤、代碼違規(guī)和代碼質(zhì)量指標,如圈復(fù)雜度。Polyspac eBug Finder可與Eclipse IDE配合使用進行代碼分析。
?
Polyspace軟件截圖 ?
b、Tessy
Tessy軟件源自戴姆勒—奔馳公司的軟件技術(shù)實驗室,由德國Hitex公司負責全球銷售及技術(shù)支持服務(wù),是一款專門針對嵌入式軟件動態(tài)測試的工具。它可以對C/C++代碼進行單元、集成測試,可以自動化搭建測試環(huán)境、執(zhí)行測試、評估測試結(jié)果并生成測試報告等。
多樣化的測試用例導(dǎo)入生成方式和與測試需求關(guān)聯(lián)的特色,使Tessy在測試組織和測試管理上也發(fā)揮了良好的作用,目前,Tessy廣泛應(yīng)用汽車電子主流客戶中。Tessy滿足各類標準(如ISO 26262、IEC61508)對測試的需求,比如Tessy可以滿足ISO 26262中各個測試等級對模塊測試的要求,當然,Tessy本身也通過了TüV的認證,證明該軟件是安全可靠的,可以在安全相關(guān)的軟件研發(fā)過程中使用。
?
Tessy 軟件截圖 ?
c、Helix QAC
Helix QAC是靜態(tài)代碼分析工具,依據(jù)C和C++編碼規(guī)則自動掃描代碼對規(guī)則的違背。在開發(fā)過程的早期就可以用它來檢測缺陷,因為此時修改代碼是最方便也最經(jīng)濟的。Helix QAC自動化強制實施代碼編程標準,比如,MISRA保證代碼的合規(guī)性。
Helix QAC識別必須修改的缺陷,提供詳細的指導(dǎo),幫助開發(fā)人員修改問題。這是不需要運行程序的。開發(fā)人員既然獲得了即時的上下文反饋,他們將因此從錯誤中獲得學(xué)習(xí),下一次編寫新的代碼(或者評審代碼)時,能力將得到提升。Helix QAC自動審查代碼,確保它們符合用戶選擇的編碼標準。
合規(guī)性報告可視化地提醒用戶哪些代碼需要多加留意。Helix QAC支持多種C和C++編碼標準,提供相應(yīng)的合規(guī)性模塊,也支持標準的客戶化定制。
? ?
Helix QAC軟件截圖 ??
審核編輯:劉清
評論
查看更多