Ficosa International的Polyspace使用歷程

在當(dāng)今汽車的安全性、可靠性和效率方面，汽車軟件系統(tǒng)發(fā)揮著日益重要的作用。為此，工程團(tuán)隊需要專注于為高級駕駛輔助系統(tǒng) (ADAS)、電池管理系統(tǒng)、穩(wěn)定性控制和類似應(yīng)用提供創(chuàng)新功能。此外，他們往往還需要證明符合 ISO 26262 和 ISO/SAE 21434 標(biāo)準(zhǔn)，以此確保滿足功能安全和網(wǎng)絡(luò)安全要求。

作為一家全球頂級汽車供應(yīng)商，F(xiàn)icosa International 致力于開發(fā)適用于各種汽車應(yīng)用的軟件。在為確保符合行業(yè)標(biāo)準(zhǔn)而建立的流程中，F(xiàn)icosa的工程團(tuán)隊使用 Polyspace 靜態(tài)代碼分析產(chǎn)品來衡量并提升代碼質(zhì)量，并將這一做法貫穿于從實現(xiàn)到單元驗證、集成和鑒定測試的整個開發(fā)生命周期。Ficosa 使用的許多流程都是依據(jù)一組明確定義的軟件質(zhì)量目標(biāo)建立的。這些目標(biāo)圍繞著正在開發(fā)的組件的關(guān)鍵程度和項目的成熟度而制定。軟件質(zhì)量目標(biāo)清楚地闡明了 Polyspace 靜態(tài)分析度量和編碼規(guī)范（如 MISRA 和 CERT/CWE）的驗收標(biāo)準(zhǔn)和閾值，以及運行時錯誤。目前，在每次進(jìn)行軟件更改時，都會自動評估并強制實施這些標(biāo)準(zhǔn)，作為 Ficosa 軟件開發(fā)過程不可或缺的一部分。因此，最大限度地減少了代碼質(zhì)量評估的主觀性，同時提高了整個軟件開發(fā)生命周期的總體開發(fā)效率。

本文的作者是來自 Ficosa International 的 David Tuset、Roger Marsal 和 Yolanda Guasch。

Ficosa International 的 Polyspace 使用歷程

2010 年，我們開始研究一個與車輛通信模塊有關(guān)的項目。作為此項目要求的一部分，我們需要利用靜態(tài)分析來檢查 MISRA C 合規(guī)性。經(jīng)過對市售靜態(tài)分析產(chǎn)品的全面評估，我們根據(jù)性能和成本選擇了 Polyspace 產(chǎn)品。與此同時，我們還在逐步實現(xiàn) Automotive SPICE (ASPICE) 能力 2 級合規(guī)性。我們開始使用 Polyspace Bug Finder 和 Polyspace Code Prover 進(jìn)行靜態(tài)分析，從而為軟件單元驗證活動提供支持。

很快，我們的工程團(tuán)隊就開始涉足 ADAS 的其他領(lǐng)域?？蛻粢查_始要求我們實現(xiàn) ASPICE 3 級合規(guī)性。我們同時啟動了多個項目，這些項目要求滿足 ISO 26262 的功能安全標(biāo)準(zhǔn)。不久之后，我們的一些客戶又開始要求進(jìn)行 CERT C 合規(guī)性和常見弱點枚舉 (CWE) 檢查，以確保符合安全編碼標(biāo)準(zhǔn)；具體到我們的情況，客戶要求實現(xiàn) ISO 21434 合規(guī)性。

Polyspace 產(chǎn)品的靜態(tài)分析有助于我們支持上述各項活動。但從組織的角度來看，我們?nèi)狈θ娴挠媱?，以明確定義我們?yōu)榱舜_保軟件質(zhì)量要在開發(fā)和驗證活動中應(yīng)用的方法、度量和閾值以及何時應(yīng)用它們。沒有形式化框架的一個缺點是，開發(fā)團(tuán)隊往往要等到項目后期才執(zhí)行靜態(tài)分析，而不是從項目伊始就系統(tǒng)化地執(zhí)行這項分析。如果僅在開發(fā)后期進(jìn)行靜態(tài)分析，其結(jié)果就可想而知了，一定包含許多違規(guī)行為，其中包括諸多不符合 MISRA C 的情況。由于在發(fā)現(xiàn)問題時項目已經(jīng)接近尾聲，因此，很難通過解決這些問題或證明其合理性來糾正如此多的違規(guī)行為。

為了應(yīng)對這一挑戰(zhàn)，我們抓住了 2020 年新冠疫情期間活躍項目相對空閑的機(jī)會，全面分析了 Ficosa International 如何才能在可靠性、功能安全和網(wǎng)絡(luò)安全等多個方面最好地實現(xiàn)我們自己和客戶的軟件質(zhì)量目標(biāo)。根據(jù)此分析，我們最終得到了一個軟件質(zhì)量目標(biāo)文檔。目前，我們的團(tuán)隊使用該文檔作為確保所交付軟件系統(tǒng)質(zhì)量的依據(jù)。

制定軟件質(zhì)量目標(biāo)

在 Ficosa International 的軟件質(zhì)量目標(biāo)文檔中，我們定義了在驗證我們開發(fā)的軟件時應(yīng)用的各種度量和規(guī)則，包括基于 MISRA C、CERT C 和 CWE 的度量和規(guī)則，以及圈復(fù)雜度和注釋密度等軟件度量。

接下來，我們根據(jù)所驗證代碼的來源、正在開發(fā)的組件的類型及其成熟度定義了應(yīng)用度量和規(guī)則的標(biāo)準(zhǔn)。

例如，我們針對第三方代碼、現(xiàn)有代碼、自動生成的代碼和手寫代碼制定了不同的目標(biāo)（圖 1）。對于第三方代碼，我們只運行強制性的 MISRA C 規(guī)則，并假設(shè)這種類型的代碼附帶其他補充性質(zhì)量證據(jù)。而對于現(xiàn)有代碼、生成的代碼和手寫代碼，我們強制實施越來越嚴(yán)格的規(guī)則集。根據(jù) ISO 26262 的汽車安全完整性等級 (ASIL) 要求和 ISO/SAE 21434 的網(wǎng)絡(luò)安全保證等級 (CAL) 要求，在功能安全或網(wǎng)絡(luò)安全方面受到影響的組件需要進(jìn)行額外的檢查。

圖 1. Ficosa International 依據(jù)軟件組件類型和項目成熟度制定的軟件質(zhì)量目標(biāo)。

此外，在組件從早期開發(fā)（“A 樣本”）階段推進(jìn)到中間階段、倒數(shù)第二個階段和最終交付（“B、C 和 D 樣本”）階段的過程中，我們還針對項目制定了更嚴(yán)格的目標(biāo)。最后，對于集成的代碼，我們提供了單獨的精簡規(guī)則和度量子集。也就是說，一組通過各自軟件質(zhì)量目標(biāo)評估的組件現(xiàn)在可合并成為更大系統(tǒng)的一部分。這在簡化復(fù)雜軟件的靜態(tài)分析時非常有用。

將靜態(tài)分析集成到開發(fā)工作流中

我們一旦擁有明確定義軟件質(zhì)量目標(biāo)的文檔，就開始使用 Polyspace 靜態(tài)分析產(chǎn)品將這些目標(biāo)集成到我們的開發(fā)和測試過程中（圖 2）。

圖 2. Ficosa International 的代碼實現(xiàn)和驗證過程，突出顯示靜態(tài)分析和后續(xù)更正。

在此過程中，一個關(guān)鍵步驟是當(dāng)開發(fā)人員在 Git（我們的版本控制系統(tǒng)）中發(fā)出拉取請求時引入了一項要求。為了使拉取請求獲得批準(zhǔn)，除了單元測試之外，代碼還必須成功通過 Polyspace Bug Finder 和 Polyspace Code Prover 的某些靜態(tài)分析檢查。這一變化使得我們的整體工作流得到了顯著改進(jìn)，因為它建立了一種門控機(jī)制，確保開發(fā)人員只有在根據(jù)適當(dāng)?shù)能浖|(zhì)量目標(biāo)徹底驗證其代碼，并解決靜態(tài)分析期間識別的任何問題或證明其合理性后，才能成功完成拉取請求。

在軟件集成和測試期間，可以使用 Polyspace 產(chǎn)品根據(jù)集成代碼的軟件質(zhì)量目標(biāo)執(zhí)行靜態(tài)分析。在此階段，僅基于系統(tǒng)級規(guī)則和集成的軟件度量，對 MISRA C 合規(guī)性和代碼度量執(zhí)行檢查。特別要關(guān)注集成級別的問題，如共享內(nèi)存的并發(fā)訪問、死代碼和關(guān)鍵運行時錯誤。

隨著我們越來越多地使用 Jenkins 來實現(xiàn)持續(xù)集成和持續(xù)交付 (CI/CD)，Polyspace 產(chǎn)品支持的頻繁靜態(tài)分析和持續(xù)反饋將發(fā)揮重要作用，可確保我們的開發(fā)人員和集成商使源代碼與軟件質(zhì)量目標(biāo)保持一致。此外，通過 Polyspace Access Web 界面，我們所有團(tuán)隊都可以訪問集中式數(shù)據(jù)庫以查看靜態(tài)代碼分析結(jié)果，并監(jiān)控達(dá)成交付質(zhì)量目標(biāo)水平的進(jìn)度。

開發(fā)功能安全產(chǎn)品時，需要考慮的另一個重要方面是，確保軟件工具不會在大規(guī)模生產(chǎn)軟件中引入錯誤或無法檢測到錯誤。ISO 26262 明確要求執(zhí)行軟件工具鑒定過程，以根據(jù)工具的關(guān)鍵程度對其進(jìn)行分類，并執(zhí)行必要的活動來鑒定他們。對于 Polyspace 產(chǎn)品，MathWorks 提供了一個認(rèn)證套件，可為 Bug Finder 和 Code Prover 提供項目級支持。

主要優(yōu)勢

在根據(jù) ISO 26262 和 ISO/SAE 21434 標(biāo)準(zhǔn)開發(fā)和交付汽車軟件的過程中，使用 Polyspace 產(chǎn)品依據(jù)明確定義的軟件質(zhì)量目標(biāo)為 Ficosa International 帶來了諸多重要優(yōu)勢。

其中一個優(yōu)勢是，我們開發(fā)人員的開發(fā)技能得到了穩(wěn)步提升。Polyspace 產(chǎn)品能夠提供詳細(xì)及時的反饋，幫助開發(fā)人員了解如何以及從何處提高代碼質(zhì)量，進(jìn)而使他們成長為更嫻熟也更高效的開發(fā)人員。事實上，根據(jù)我們現(xiàn)有的流程，開發(fā)人員別無選擇，只能了解并解決通過靜態(tài)分析檢測到的問題。

我們獲得的另一個重要優(yōu)勢是，簡化了 ASPICE 和 ISO 26262 的外部質(zhì)量評估或其他客戶要求的合規(guī)性目標(biāo)。如今，我們所做的一切都更容易得到驗證，因為我們有明確的軟件質(zhì)量目標(biāo)以及相應(yīng)的報告（例如說明 MISRA 和 CERT 偏差問題比過去少得多），還有證明我們的代碼已通過客觀質(zhì)量標(biāo)準(zhǔn)的證據(jù)。

也許，最重要的是，Polyspace 產(chǎn)品幫助我們實現(xiàn)了質(zhì)量目標(biāo)，同時提高了效率（或至少保持效率不變）。通常，當(dāng)治理團(tuán)隊或類似小組更改他們所在組織的開發(fā)工作流，引入我們所實施的那種早期驗證步驟時，開發(fā)人員會將他們需要完成的附加步驟視為額外工作。然而，借助 Polyspace 產(chǎn)品，我們能夠向我們的團(tuán)隊證明，為每個拉取請求執(zhí)行靜態(tài)分析的附加步驟實際上提高了他們的效率。他們可以更高效、更自信地交付高質(zhì)量的代碼，因為通過靜態(tài)分析發(fā)現(xiàn)的所有錯誤都在開發(fā)過程的早期階段得到了消除，而不必等到最后階段才來解決。

除了 Ficosa 法可賽，還有很多其他的主機(jī)廠和供應(yīng)商也在使用 Polyspace，來解決他們軟件質(zhì)量的問題。

例如沃爾沃汽車也選用了 Polyspace 來提高開發(fā)速度和軟件質(zhì)量，并通過了 ISO 26262 和 ISO/SAE 21434 的認(rèn)證。

審核編輯：湯梓紅