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

軟件開發(fā)參考階段模型

01

軟件安全要求

車載智能計(jì)算平臺(tái)軟件安全要求是對軟件安全相關(guān)的功能和性能的具體要求，主要是通過技術(shù)安全要求在軟件層面的分配得到，并通過繼承或分配得到相應(yīng)的ASIL等級。另外，在軟件架構(gòu)階段執(zhí)行的軟件安全分析也可能會(huì)識(shí)別出額外的軟件安全要求。采用專業(yè)的需求管理工具來實(shí)現(xiàn)需求的編寫、評審、管理以及雙向追溯性檢查可大幅降低軟件層面的系統(tǒng)性安全風(fēng)險(xiǎn)。 ?

02

軟件架構(gòu)設(shè)計(jì)

軟件架構(gòu)設(shè)計(jì)是對軟件需求的設(shè)計(jì)與實(shí)現(xiàn)，用來描述軟件的框架要素和軟件各分層結(jié)構(gòu)之間的相互作用，其范圍層面應(yīng)到能夠識(shí)別所有軟件單元的程度。軟件架構(gòu)設(shè)計(jì)不僅需滿足相應(yīng)ASIL等級的軟件安全要求，還應(yīng)滿足軟件其他非安全要求。在軟件架構(gòu)層面，軟件安全要求會(huì)分層次地分配給軟件組件直到軟件單元，每個(gè)軟件組件應(yīng)按照分配給它的安全要求中最高的ASIL等級來開發(fā)。

車載智能計(jì)算平臺(tái)應(yīng)在軟件架構(gòu)設(shè)計(jì)階段進(jìn)行軟件安全分析和相關(guān)失效分析，完善錯(cuò)誤探測和錯(cuò)誤處理的安全機(jī)制，以便識(shí)別或確認(rèn)軟件安全相關(guān)部分，證明軟件的安全相關(guān)的功能和性能滿足相應(yīng)的ASIL要求，支持安全措施的定義及其有效性。

車載智能計(jì)算平臺(tái)軟件架構(gòu)設(shè)計(jì)完成后，應(yīng)對其開展驗(yàn)證活動(dòng)，輸出軟件驗(yàn)證報(bào)告，證明軟件架構(gòu)設(shè)計(jì)嚴(yán)格遵守設(shè)計(jì)規(guī)則，兼容目標(biāo)環(huán)境，滿足相應(yīng)ASIL等級的需求，并且相關(guān)評審證據(jù)充足。 ? 軟件安全設(shè)計(jì)依然可以從E-Gas三層架構(gòu)中提取關(guān)鍵設(shè)計(jì)理念。

E-Gas針對的典型系統(tǒng)，基本的思想是外圍系統(tǒng)—內(nèi)部系統(tǒng)，內(nèi)部系統(tǒng)分為傳感器、控制器和執(zhí)行器。在這個(gè)系統(tǒng)概念里，傳感器是加速踏板傳感器，控制器是ECU（Engine Control Unit），執(zhí)行器是節(jié)氣門。展開安全架構(gòu)設(shè)計(jì)的時(shí)候，需要時(shí)刻關(guān)注將系統(tǒng)解耦和模塊化，這對于軟件的安全設(shè)計(jì)是非常重要的。

?

E-Gas典型系統(tǒng)組成及邊界 ? 關(guān)于E-Gas安全架構(gòu)的核心理念和設(shè)計(jì)，這里再回顧一下，整體設(shè)計(jì)分為Level1、Level2和Level3，其定義如下：

?

E-Gas三層安全架構(gòu)（帶鎖步核） ?

（1）Level1：功能層，包括扭矩的解析、功能的診斷等，最直接的理解就是能夠?qū)崿F(xiàn)設(shè)計(jì)基本功能的軟件及相關(guān)硬件資源的組合。

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

（3）Level3：硬件監(jiān)控層，負(fù)責(zé)確保Level1和Level2的運(yùn)行的硬件環(huán)境是正常工作的，異常的運(yùn)行環(huán)境會(huì)導(dǎo)致Level2的設(shè)計(jì)起不到很好效果，因此，Level3在整體的監(jiān)控架構(gòu)中作用是不可替代的。 ?

下圖是Level2算法架構(gòu)的一個(gè)示例（汽油歧管噴射），其整體思想是計(jì)算實(shí)際系統(tǒng)輸出的扭矩和此刻系統(tǒng)允許輸出的安全現(xiàn)值之間的差值，當(dāng)差值大于一定數(shù)值及一定時(shí)間時(shí)，采用相應(yīng)的故障動(dòng)作。

同時(shí)，方案為了避免出現(xiàn)誤報(bào)或者漏報(bào)的情況，每一項(xiàng)用于計(jì)算的信號(hào)或者相應(yīng)的傳感器都應(yīng)該具有相應(yīng)的診斷及故障動(dòng)作，這也是軟件開展功能安全設(shè)計(jì)很關(guān)鍵的理念，輸入信號(hào)是需要高完整性和準(zhǔn)確性的。

?

三層架構(gòu)Level2算法架構(gòu)示例 ? 針對Level3的硬件監(jiān)控層，需要涉及軟件和硬件的交互，監(jiān)控的機(jī)制可以通過軟件實(shí)現(xiàn)，也可以通過硬件實(shí)現(xiàn)。這里羅列了E-Gas中涉及軟件方面的問題： ?

（1）ROM檢查：針對ROM的檢查，主要是涉及數(shù)據(jù)翻轉(zhuǎn)、錯(cuò)誤的刷寫、錯(cuò)誤的數(shù)據(jù)等，軟件在其中扮演著檢測對比算法的角色，當(dāng)然，ROM的檢查通過硬件也可以實(shí)現(xiàn)。

（2）應(yīng)答機(jī)制檢查：軟件需要在設(shè)定時(shí)間窗口內(nèi)正確回答獨(dú)立硬件監(jiān)控單元的問題，如果超時(shí)或者回答錯(cuò)誤一定次數(shù)，都會(huì)觸發(fā)重置或者下電。

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

（4）程序流檢查：監(jiān)控算法、診斷算法等都是周期性按順序執(zhí)行的，因此，執(zhí)行時(shí)序也需要進(jìn)行檢查。 ?

通過E-Gas的三層經(jīng)典架構(gòu)，我們可以分析出軟件層級的功能安全設(shè)計(jì)需要考慮的軟件包括Level1的功能層軟件、Level2的監(jiān)控層軟件以及Level3的部分支持硬件監(jiān)控層軟件。 ?

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

軟件開發(fā)遵循原則參考

?

當(dāng)然，并不是說非三層架構(gòu)設(shè)計(jì)軟件無法實(shí)現(xiàn)功能安全開發(fā)或者產(chǎn)品無法符合功能安全要求。E-Gas三層架構(gòu)能夠很清晰地實(shí)現(xiàn)層級遞進(jìn)式的監(jiān)控設(shè)計(jì)，尤其適用于功能軟件復(fù)雜的產(chǎn)品。

如果功能軟件相對復(fù)雜，高ASIL等級的產(chǎn)品在導(dǎo)致軟件開發(fā)的工作量大量增加的同時(shí)安全性也很難兼顧；當(dāng)然，如果應(yīng)用層軟件相對簡單（例如濾波算法、局部優(yōu)化、狀態(tài)機(jī)等函數(shù)），采用下表所列方式會(huì)更好。 ?

非三層架構(gòu)開發(fā)遵循原則參考

?

對于功能安全軟件設(shè)計(jì)而言，軟件架構(gòu)設(shè)計(jì)一個(gè)重要的目標(biāo)是使軟件需求的實(shí)現(xiàn)過程以一種完整的、正確的同時(shí)盡可能簡單、可理解和可驗(yàn)證的方式展現(xiàn)，從而在軟件需求實(shí)現(xiàn)過程中，盡可能降低由于設(shè)計(jì)錯(cuò)誤造成違反功能安全需求的可能性。

功能安全要求軟件架構(gòu)的設(shè)計(jì)具備以下屬性：可理解性，一致性，簡單性，可驗(yàn)證，模塊化，層次化，按層逐步細(xì)化、封裝，低耦合性，可維護(hù)性。對于可理解性，ISO 26262中按照不同的ASIL等級規(guī)定了不同的軟件架構(gòu)設(shè)計(jì)的表示方式。 ?

軟件架構(gòu)設(shè)計(jì)符號(hào)說明

?

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

A、SW-FMEA

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

2.SW-FTA

SW-FTA探究的重點(diǎn)是軟件架構(gòu)中多點(diǎn)錯(cuò)的發(fā)生對軟件功能安全需求的影響。SW-FTA分析過程從軟件功能安全需求出發(fā)，從軟件架構(gòu)設(shè)計(jì)中所有軟件模塊和軟件接口的失效模式中去尋找和當(dāng)前軟件功能安全需求相關(guān)的失效模式，并且識(shí)別出這些失效模式和當(dāng)前軟件功能安全需求的相關(guān)性（單點(diǎn)失效還是多點(diǎn)失效）。 ?

3.SW-DFA

SW-DFA在標(biāo)準(zhǔn)中定義的從屬故障（Dependent failure）包括級聯(lián)故障（Cascading failure）和共因故障（Common cause failure）。通?？梢詮囊韵聨讉€(gè)方面來考慮Dependent failure 中Cascading failure的部分： ?

時(shí)間和調(diào)度問題造成Cascading failure。比如，由于其他模塊運(yùn)行時(shí)間過長導(dǎo)致目標(biāo)模塊無法運(yùn)行，死鎖、活鎖、饑餓等現(xiàn)象導(dǎo)致模塊運(yùn)行停滯或者延遲，軟件模塊之間的同步性問題或者優(yōu)先級問題導(dǎo)致調(diào)度次序出現(xiàn)問題。 ?

存儲(chǔ)空間問題造成Cascading failure。比如，目標(biāo)存儲(chǔ)區(qū)域被其他軟件模塊誤篡改，軟件模塊之間對于同一存儲(chǔ)空間的讀寫操作配合問題導(dǎo)致數(shù)據(jù)不一致（讀數(shù)據(jù)的同時(shí)允許寫數(shù)據(jù)），棧溢出等問題。 ?

軟件模塊之間的通信（ 尤其是ECU 間的通信） 問題造成Cascading failure。時(shí)間和調(diào)度問題造成Cascading failure。 ?

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

軟件架構(gòu)設(shè)計(jì)原則

?

ISO 26262對軟件架構(gòu)設(shè)計(jì)驗(yàn)證

方法

03

軟件單元設(shè)計(jì)與實(shí)現(xiàn) ?

在軟件單元設(shè)計(jì)與實(shí)現(xiàn)階段，基于軟件架構(gòu)設(shè)計(jì)對車載智能計(jì)算平臺(tái)的軟件單元進(jìn)行詳細(xì)設(shè)計(jì)。軟件單元設(shè)計(jì)應(yīng)滿足其所分配的ASIL等級要求，與軟件架構(gòu)設(shè)計(jì)和軟硬件接口設(shè)計(jì)相關(guān)內(nèi)容保持一致。為了避免系統(tǒng)性失效，應(yīng)確保軟件單元設(shè)計(jì)的一致性、可理解性、可維護(hù)性和可驗(yàn)證性，采用自然語言與半形式化方法相結(jié)合的方式進(jìn)行描述。

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

車載智能計(jì)算平臺(tái)軟件包含數(shù)百個(gè)軟件單元，軟件單元的標(biāo)準(zhǔn)化、單元間解耦是高效實(shí)現(xiàn)軟件功能安全的基礎(chǔ)。車載智能計(jì)算平臺(tái)中不同安全等級的軟件可以采用硬件虛擬化、容器、內(nèi)存隔離等技術(shù)進(jìn)行隔離，防止軟件單元之間的級聯(lián)失效。 ?

軟件代碼設(shè)計(jì)過程中應(yīng)遵守成熟的代碼設(shè)計(jì)規(guī)范，例如MISRA C。MISRA C是由汽車產(chǎn)業(yè)軟件可靠性協(xié)會(huì)（MISRA）提出的C語言開發(fā)標(biāo)準(zhǔn)。其目的是在增進(jìn)嵌入式系統(tǒng)的安全性及可移植性，針對C++語言也有對應(yīng)的標(biāo)準(zhǔn)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項(xiàng)規(guī)則，規(guī)則從1號(hào)編號(hào)到127號(hào)，其中有93項(xiàng)是強(qiáng)制要求，其余的34項(xiàng)是推薦使用的規(guī)則。

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

規(guī)則分為21類，從“開發(fā)環(huán)境”到“運(yùn)行期錯(cuò)誤”。2012年發(fā)布第三版，為當(dāng)前最新有效的C語言規(guī)范版本，稱為MISRA C:2012。企業(yè)可以基于MISRAC建立一套滿足車載智能計(jì)算平臺(tái)安全編碼要求的內(nèi)部編碼規(guī)范，并嚴(yán)格執(zhí)行。 ?

ISO 26262軟件單元設(shè)計(jì)和實(shí)現(xiàn)的設(shè)計(jì)原則

04

軟件單元驗(yàn)證 ?

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

車載智能計(jì)算平臺(tái)的軟件單元驗(yàn)證可參考下表，通過需求分析、等價(jià)類的生成與分析、邊界值分析和錯(cuò)誤推測相結(jié)合的方法合理設(shè)計(jì)測試用例，確保對軟件單元進(jìn)行充分驗(yàn)證。為了評估軟件單元驗(yàn)證的完整性，為單元測試的充分性提供證據(jù)，應(yīng)確定在軟件單元層面的需求覆蓋率，同時(shí)對結(jié)構(gòu)覆蓋率進(jìn)行測定。

車載智能計(jì)算平臺(tái)軟件單元測試的結(jié)構(gòu)覆蓋率目標(biāo)為100%，如果已實(shí)現(xiàn)結(jié)構(gòu)覆蓋率不能達(dá)到目標(biāo)，可以定義額外的測試用例并提供接受理由。車載智能計(jì)算平臺(tái)軟件單元的結(jié)構(gòu)覆蓋率測試應(yīng)采用滿足相關(guān)安全要求的測試工具，確保在測試過程中測試工具和檢測代碼不會(huì)對測試結(jié)果產(chǎn)生影響。 ?

車載智能計(jì)算平臺(tái)軟件單元測試應(yīng)根據(jù)測試范圍，選用適當(dāng)?shù)臏y試環(huán)境。測試環(huán)境應(yīng)適合完成測試目標(biāo)，盡可能接近目標(biāo)環(huán)境，如果不是在目標(biāo)環(huán)境執(zhí)行，應(yīng)分析源代碼與目標(biāo)代碼的差異、測試環(huán)境和目標(biāo)環(huán)境之間的差異，以便在后續(xù)測試階段的目標(biāo)環(huán)境中，定義額外的測試。 ?

軟件單元驗(yàn)證方法

?

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

05

軟件集成驗(yàn)證 ?

軟件集成驗(yàn)證需要根據(jù)軟件驗(yàn)證計(jì)劃、接口規(guī)范、軟件架構(gòu)設(shè)計(jì)規(guī)范、軟件驗(yàn)證規(guī)范等對軟件架構(gòu)中所描述的集成層次、接口、功能等進(jìn)行持續(xù)測試，以驗(yàn)證其與設(shè)計(jì)的符合性。由于車載智能計(jì)算平臺(tái)軟件的復(fù)雜性，實(shí)時(shí)性、可靠性、安全性既是設(shè)計(jì)目標(biāo)也是基礎(chǔ)性能，集成測試設(shè)計(jì)階段應(yīng)對其功能、邏輯、性能、邊界、接口進(jìn)行詳細(xì)分析。

車載智能計(jì)算平臺(tái)的軟件集成驗(yàn)證參考下表，不僅需涵蓋所有應(yīng)用軟件、功能軟件、系統(tǒng)軟件以及與硬件之間的接口，并且應(yīng)涵蓋軟件單元之間的接口。

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

軟件集成驗(yàn)證方法

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

06

嵌入式軟件測試 ?

車載智能計(jì)算平臺(tái)嵌入式軟件測試主要是基于軟件安全要求的測試可參考下表，針對軟件安全要求進(jìn)行充分的故障注入測試，最終確保軟件安全要求的正確實(shí)現(xiàn)。

為了驗(yàn)證車載智能計(jì)算平臺(tái)軟件在目標(biāo)環(huán)境下是否滿足軟件安全要求，應(yīng)進(jìn)行硬件在環(huán)測試、車輛電控系統(tǒng)和網(wǎng)絡(luò)通信環(huán)境下的測試以及實(shí)車測試。硬件在環(huán)測試是將車載智能計(jì)算平臺(tái)軟件燒寫到目標(biāo)芯片中，在目標(biāo)芯片的硬件異構(gòu)平臺(tái)環(huán)境下驗(yàn)證軟件的安全要求。

然后，將車載智能計(jì)算平臺(tái)與部分或全部的車輛電子電氣設(shè)備進(jìn)行網(wǎng)絡(luò)通信，在車輛電控系統(tǒng)和網(wǎng)絡(luò)環(huán)境下驗(yàn)證軟件的安全要求。最后，將車載智能計(jì)算平臺(tái)安裝到實(shí)際車輛中，進(jìn)行軟件安全要求的驗(yàn)證與確認(rèn)。 ? ?

嵌入式軟件的測試方法

? ?

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

07

人工智能 ?

通過實(shí)施完善的開發(fā)流程可降低車載智能計(jì)算平臺(tái)人工智能的系統(tǒng)性安全風(fēng)險(xiǎn)。車載智能計(jì)算平臺(tái)人工智能的開發(fā)包含需求分析、算法設(shè)計(jì)、數(shù)據(jù)采集和標(biāo)注、模型訓(xùn)練、測試驗(yàn)證以及運(yùn)行等流程。 ?

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

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

08

軟件階段常用工具介紹 ?

a、Polyspace

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

Polyspace Bug Finder可檢查是否符合編碼規(guī)范，如MISRA C、MISRA C++、JSF++、CERT C、CERT C++和自定義命名規(guī)范。它可以生成報(bào)告，其中包括發(fā)現(xiàn)的錯(cuò)誤、代碼違規(guī)和代碼質(zhì)量指標(biāo)，如圈復(fù)雜度。Polyspac eBug Finder可與Eclipse IDE配合使用進(jìn)行代碼分析。

?

Polyspace軟件截圖 ?

b、Tessy

Tessy軟件源自戴姆勒—奔馳公司的軟件技術(shù)實(shí)驗(yàn)室，由德國Hitex公司負(fù)責(zé)全球銷售及技術(shù)支持服務(wù)，是一款專門針對嵌入式軟件動(dòng)態(tài)測試的工具。它可以對C/C++代碼進(jìn)行單元、集成測試，可以自動(dòng)化搭建測試環(huán)境、執(zhí)行測試、評估測試結(jié)果并生成測試報(bào)告等。

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

?

Tessy 軟件截圖 ?

c、Helix QAC

Helix QAC是靜態(tài)代碼分析工具，依據(jù)C和C++編碼規(guī)則自動(dòng)掃描代碼對規(guī)則的違背。在開發(fā)過程的早期就可以用它來檢測缺陷，因?yàn)榇藭r(shí)修改代碼是最方便也最經(jīng)濟(jì)的。Helix QAC自動(dòng)化強(qiáng)制實(shí)施代碼編程標(biāo)準(zhǔn)，比如，MISRA保證代碼的合規(guī)性。

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

合規(guī)性報(bào)告可視化地提醒用戶哪些代碼需要多加留意。Helix QAC支持多種C和C++編碼標(biāo)準(zhǔn)，提供相應(yīng)的合規(guī)性模塊，也支持標(biāo)準(zhǔn)的客戶化定制。

? ?

Helix QAC軟件截圖 ??





審核編輯：劉清