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

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

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

Ficosa International 的 Polyspace 使用歷程

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

很快，我們的工程團隊就開始涉足 ADAS 的其他領域。客戶也開始要求我們實現 ASPICE 3 級合規性。我們同時啟動了多個項目，這些項目要求滿足 ISO 26262 的功能安全標準。不久之后，我們的一些客戶又開始要求進行 CERT C 合規性和常見弱點枚舉 (CWE) 檢查，以確保符合安全編碼標準；具體到我們的情況，客戶要求實現 ISO 21434 合規性。

Polyspace 產品的靜態分析有助于我們支持上述各項活動。但從組織的角度來看，我們缺乏全面的計劃，以明確定義我們為了確保軟件質量要在開發和驗證活動中應用的方法、度量和閾值以及何時應用它們。沒有形式化框架的一個缺點是，開發團隊往往要等到項目后期才執行靜態分析，而不是從項目伊始就系統化地執行這項分析。如果僅在開發后期進行靜態分析，其結果就可想而知了，一定包含許多違規行為，其中包括諸多不符合 MISRA C 的情況。由于在發現問題時項目已經接近尾聲，因此，很難通過解決這些問題或證明其合理性來糾正如此多的違規行為。

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

制定軟件質量目標

在 Ficosa International 的軟件質量目標文檔中，我們定義了在驗證我們開發的軟件時應用的各種度量和規則，包括基于 MISRA C、CERT C 和 CWE 的度量和規則，以及圈復雜度和注釋密度等軟件度量。

接下來，我們根據所驗證代碼的來源、正在開發的組件的類型及其成熟度定義了應用度量和規則的標準。

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

圖 1. Ficosa International 依據軟件組件類型和項目成熟度制定的軟件質量目標。

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

將靜態分析集成到開發工作流中

我們一旦擁有明確定義軟件質量目標的文檔，就開始使用 Polyspace 靜態分析產品將這些目標集成到我們的開發和測試過程中（圖 2）。

圖 2. Ficosa International 的代碼實現和驗證過程，突出顯示靜態分析和后續更正。

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

在軟件集成和測試期間，可以使用 Polyspace 產品根據集成代碼的軟件質量目標執行靜態分析。在此階段，僅基于系統級規則和集成的軟件度量，對 MISRA C 合規性和代碼度量執行檢查。特別要關注集成級別的問題，如共享內存的并發訪問、死代碼和關鍵運行時錯誤。

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

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

主要優勢

在根據 ISO 26262 和 ISO/SAE 21434 標準開發和交付汽車軟件的過程中，使用 Polyspace 產品依據明確定義的軟件質量目標為 Ficosa International 帶來了諸多重要優勢。

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

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

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

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

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

審核編輯：湯梓紅