嵌入式系統(tǒng)開發(fā)中的靜態(tài)分析

由于嵌入式系統(tǒng)行業(yè)的快速增長，嵌入式設(shè)備的代碼質(zhì)量成為主要關(guān)注點(diǎn)之一?？紤]到嵌入式系統(tǒng)開發(fā)的特殊性（調(diào)試難度大、出錯成本高等），開發(fā)人員需要使用專用工具來提升代碼質(zhì)量。

靜態(tài)代碼分析器是這些工具之一。本文介紹靜態(tài)分析及其在嵌入式系統(tǒng)中的優(yōu)勢。

靜態(tài)代碼分析

首先，讓我們弄清楚什么是靜態(tài)代碼分析器以及它們可以執(zhí)行哪些功能。

靜態(tài)代碼分析器是一種分析程序而不實(shí)際執(zhí)行程序的軟件。靜態(tài)分析工具比編譯器對源代碼執(zhí)行更深入的檢查。通常，編譯器只發(fā)現(xiàn)語法錯誤。

靜態(tài)分析工具的工作原理：

分析器的輸入數(shù)據(jù)是源代碼（最好是可編譯的）

分析器將源代碼轉(zhuǎn)換為特殊模型以供進(jìn)一步分析（AST、語義模型等）;

分析器通過將一組診斷規(guī)則應(yīng)用于模型來搜索缺陷。診斷規(guī)則基于各種方法;

分析器以您方便的格式保存所有發(fā)出的警告;

開發(fā)人員只需要研究報告并修復(fù)所有缺陷;

利潤！

靜態(tài)分析儀可以執(zhí)行廣泛的任務(wù)。讓我們介紹分析器最常見的任務(wù)：

程序代碼中的錯誤檢測。在這種情況下，靜態(tài)分析極大地補(bǔ)充了代碼審查。它允許您在您和您的同事開始煩人的代碼審查之前找到并修復(fù)許多問題;

廣義上的代碼質(zhì)量增強(qiáng)。代碼質(zhì)量可以包括可讀性、可維護(hù)性、代碼復(fù)雜性、內(nèi)聚級別以及可能直接或間接影響錯誤數(shù)的其他方面。因此，靜態(tài)分析儀有助于遵循編碼標(biāo)準(zhǔn)（公司內(nèi)部接受和普遍接受）;

代碼分析作為 CI/CD 中質(zhì)量門機(jī)制的一部分。分析器不僅可以警告代碼中的潛在錯誤，還可以用作保護(hù)機(jī)制。如果代碼質(zhì)量級別不符合指定的要求，它們將停止持續(xù)交付。此類代碼分析器擴(kuò)展編譯器行為，并在檢測到不符合標(biāo)準(zhǔn)的錯誤或代碼片段時阻止生成;

收集項(xiàng)目指標(biāo)，收集統(tǒng)計數(shù)據(jù)，反映項(xiàng)目“總體健康狀況”的圖形和圖表結(jié)構(gòu)。

實(shí)施的好處

事實(shí)證明，靜態(tài)分析儀對于嵌入式軟件非常有用。讓我們來看看靜態(tài)分析最明顯的積極方面。

首先，靜態(tài)分析的使用降低了已經(jīng)發(fā)布的設(shè)備“閃爍”的昂貴（如果不是不可能的話）的可能性。

嵌入式系統(tǒng)軟件中的錯誤非常麻煩。問題在于，一旦開始批量生產(chǎn)，錯誤就不可能或幾乎不可能糾正。假設(shè)一家公司已經(jīng)生產(chǎn)并交付了數(shù)千臺洗衣機(jī)。但是，事實(shí)證明機(jī)器在特定模式下無法正常工作。公司應(yīng)該怎么做？一般來說，這個問題是修辭性的，有兩種真正的選擇：

順其自然，在各種網(wǎng)站上收到負(fù)面的客戶反饋，并破壞聲譽(yù)。當(dāng)然，公司可以發(fā)布并發(fā)送手冊添加說“不要這樣做”。然而，這是一個“弱”的選擇;

以停止銷售計算機(jī)并開始更新固件。這是一個昂貴的選擇。

發(fā)布多少設(shè)備并不重要。修復(fù)錯誤可能有問題，甚至為時已晚?；鸺龎嫐Я恕獧z測到錯誤，但為時已晚。病人死了——錯誤被檢測到了，但它不會把人帶回來。導(dǎo)彈防御系統(tǒng)有瞄準(zhǔn)精度損失 - 檢測到錯誤，但損害已經(jīng)完成。汽車故障不起作用 - 檢測到錯誤，但這無助于車禍?zhǔn)芎φ摺?a href="http://www.wenjunhu.com/v/tag/1315/" target="_blank">編程錯誤的代價是可怕的，不是嗎？

結(jié)論很簡單：嵌入式設(shè)備的代碼應(yīng)該盡可能徹底地測試。特別是如果錯誤可能導(dǎo)致人員傷亡或巨大的經(jīng)濟(jì)損失。

靜態(tài)代碼分析是檢測錯誤的過程，但它不能保證它會找到代碼中的所有錯誤。但是，開發(fā)人員應(yīng)利用任何機(jī)會額外檢查代碼的正確性。靜態(tài)分析器可以指出即使在多次代碼審查后仍然存在的各種錯誤。

如果靜態(tài)分析可以幫助減少設(shè)備代碼中的錯誤數(shù)量，那就太棒了。也許發(fā)現(xiàn)這些特定錯誤將防止生命損失。或者也許這些公司不會浪費(fèi)很多錢，也不會因?yàn)榭蛻敉对V而失去良好的聲譽(yù)。

其次，靜態(tài)代碼分析器大大降低了軟件測試和調(diào)試過程的成本。

靜態(tài)分析允許您在編碼或夜間構(gòu)建期間發(fā)現(xiàn)錯誤。因此，搜索和修復(fù)大多數(shù)錯誤可以便宜得多。

可能每個開發(fā)人員都嘗試“刷新”設(shè)備失敗。例如，在此過程中，設(shè)備未設(shè)置為適當(dāng)?shù)碾妷夯蛲耆珶龎?。發(fā)生了什么，你在哪里尋找問題？畢竟，不僅是軟件錯誤可能是問題的根源。這也可能是硬件本身或低質(zhì)量布局中的錯誤。因此，查找錯誤的過程可能需要很長時間。

最可悲的情況：

開發(fā)人員 100% 確定他編寫的代碼正確;

電路工程師和其他負(fù)責(zé)硬件的同事參與該項(xiàng)目;

對問題的搜索緩慢而疲憊;

開發(fā)人員再次查看代碼，突然發(fā)現(xiàn) - 一個錯別字;

超級低效浪費(fèi)隊(duì)友的精力和時間;

這是尷尬和不愉快的。

由于以下原因，可能會彈出此類錯誤。在正在進(jìn)行的項(xiàng)目中，開發(fā)人員使用了他的舊做法，他至少需要適應(yīng)項(xiàng)目。例如，他可以編寫以下代碼片段：

uchar Arr［3］;

。..。

for （uchar idx = 0; idx ！= 4; idx++）

avg += Arr［idx］;

avg /= 3;

此錯誤的背景如下。開發(fā)人員以他以前的開發(fā)為基礎(chǔ)，代碼主要是使用復(fù)制粘貼方法編寫的。他沒有注意，忘了在一行中用 4 替換 3。結(jié)果，他在訪問數(shù)組邊界之外的索引時獲得了未定義的行為。這樣的代碼可能是陰險的。程序在調(diào)試期間可以正常工作。但是，在實(shí)際條件下，當(dāng)客戶端多次運(yùn)行它時，它可能會崩潰。如果靜態(tài)分析器發(fā)現(xiàn)此類錯誤，那就太好了。

因此，為了避免曲折而疲憊的調(diào)試過程，在刷新設(shè)備之前檢測盡可能多的缺陷位置非常重要。

第三，靜態(tài)分析的使用為沒有太多經(jīng)驗(yàn)的開發(fā)人員提供了保障。

程序錯誤可以形象地分為兩種類型。開發(fā)人員知道第一種類型的錯誤。由于疏忽，這些錯誤意外出現(xiàn)在代碼中。第二種錯誤出現(xiàn)在開發(fā)人員根本不知道以這種方式編寫代碼的情況下。換句話說，他們可以根據(jù)需要查看此類代碼，但仍然找不到錯誤。

靜態(tài)分析器包含有關(guān)各種代碼模式的知識庫。在某些情況下，這些模式會導(dǎo)致錯誤。因此，他們可以指出開發(fā)人員自己不會發(fā)現(xiàn)的錯誤。一個例子是使用 32 位 time_t 類型，這可能會導(dǎo)致2038 年之后設(shè)備不正確的工作。

另一個例子是程序的未定義行為，這是由于不正確使用班次運(yùn)算符 《《/》》 而發(fā)生的。這些運(yùn)算符在微控制器的代碼中應(yīng)用非常廣泛。不幸的是，開發(fā)人員經(jīng)常非常粗心地使用這些運(yùn)算符。這使得程序不可靠，并且依賴于編譯器的特定版本和設(shè)置。同時，該程序可以工作，但這并不是因?yàn)樗拇a編寫正確，而是因?yàn)殚_發(fā)人員很幸運(yùn)。

使用靜態(tài)分析器，開發(fā)人員可以對沖許多此類不愉快的情況。此外，還可以使用分析器來控制整體代碼質(zhì)量。當(dāng)項(xiàng)目團(tuán)隊(duì)成長或變化時，這一點(diǎn)很重要。換句話說，分析器有助于跟蹤初學(xué)者是否開始編寫錯誤代碼。

第四，現(xiàn)代靜態(tài)分析儀不僅可以發(fā)現(xiàn)代碼錯誤和漏洞，還可以支持嵌入式系統(tǒng)的編碼標(biāo)準(zhǔn)。這些標(biāo)準(zhǔn)提高了程序的安全性、可移植性和可靠性級別。

C 和 C++ 被稱為嵌入式系統(tǒng)的流行編程語言。MISRA C、MISRA C++ 和 AUTOSAR C++ 等標(biāo)準(zhǔn)是為這些語言開發(fā)的。每個標(biāo)準(zhǔn)都有相當(dāng)數(shù)量的規(guī)則和建議（MISRA C：143，MISRA C++：228，AUTOSAR C++：超過350）。在沒有靜態(tài)代碼分析器的情況下進(jìn)行編碼時，根本不可能遵守這么多規(guī)則和建議。這些規(guī)則是開發(fā)人員需要避免的編碼模式，從而降低出錯的可能性。目前，靜態(tài)分析的所有主要參與者（Coverity，Klockwork，PVS-Studio等）都在努力盡可能增加標(biāo)準(zhǔn)的覆蓋范圍。

編碼標(biāo)準(zhǔn)

MISRA的歷史始于很久以前。早在 90 年代初，“安全 IT”英國政府計劃就為與電子系統(tǒng)安全相關(guān)的各種項(xiàng)目提供資金。MISRA（汽車行業(yè)軟件可靠性協(xié)會）項(xiàng)目本身的成立是為了創(chuàng)建陸地車輛（主要是汽車）微控制器軟件開發(fā)指南。

MISRA（作為一個組織）是一個由來自各個汽車和飛機(jī)行業(yè)的利益相關(guān)者組成的社區(qū)。

賓利汽車;

福特汽車公司;

捷豹路虎;

德爾福柴油系統(tǒng);

堀場米拉;

千變?nèi)f化的電氣;

偉世通工程服務(wù);

利茲大學(xué);

里卡多·英國;

采埃孚天合。

非常強(qiáng)大的市場參與者，不是嗎？毫不奇怪，他們的第一個語言相關(guān)標(biāo)準(zhǔn)MISRA C在關(guān)鍵嵌入式系統(tǒng)的開發(fā)人員中得到了廣泛的認(rèn)可。過了一會兒，米斯拉C++出現(xiàn)了。標(biāo)準(zhǔn)的版本已逐步更新和修訂，以涵蓋語言的新特征。目前，目前的版本是MISRA C：2012和MISRA C++：2008。

MISRA最顯著的特點(diǎn)是其對細(xì)節(jié)的令人難以置信的關(guān)注和在確保安全和保障方面的極其細(xì)致。作者不只是在一個地方收集所有C和C++缺陷（例如，CERT的作者）。他們還仔細(xì)制定了這些語言的國際標(biāo)準(zhǔn)，并寫出了所有可能犯錯的方法。之后，他們添加了有關(guān)代碼可讀性的規(guī)則和建議。畢竟，在簡單易讀的代碼中犯錯誤更難，并且在代碼審查期間更容易檢測到錯誤。

通常，第一次遇到MISRA的人會覺得該標(biāo)準(zhǔn)的目的是“禁止這個，禁止那個”。事實(shí)上，確實(shí)如此，但只是部分。

該標(biāo)準(zhǔn)確實(shí)有許多禁止某些操作的規(guī)則。但是，這并不意味著要全部禁止，而是列出可能以某種方式導(dǎo)致安全漏洞的所有可能方法。對于大多數(shù)規(guī)則，您可以自己選擇是否需要遵守它們。讓我更詳細(xì)地解釋一下。

MISRA C 規(guī)則分為三個主要類別：強(qiáng)制性、必需性和建議性。在任何情況下都不能違反強(qiáng)制性規(guī)則。例如，此部分包含規(guī)則：“不要使用未啟動變量的值”。所需的規(guī)則不太嚴(yán)格。它們允許偏差的可能性。但是開發(fā)人員需要以書面形式證明這些偏差的合理性，并詳細(xì)記錄它們。其余規(guī)則屬于咨詢類別——它們是非強(qiáng)制性的。

MISRA C++略有不同：沒有必填類別，大多數(shù)規(guī)則都屬于必需類別。因此，事實(shí)上，您有權(quán)違反任何規(guī)則——只是不要忘記記錄偏差。還有文檔類別。它包括與一般做法相關(guān)的強(qiáng)制性規(guī)則（不允許有偏差），例如“匯編程序的每次使用都必須記錄”或“包含的庫必須符合 MISRA C++”。

該標(biāo)準(zhǔn)既包含對問題問題的描述，也包含有關(guān)在承擔(dān)某項(xiàng)任務(wù)之前必須了解的提示：如何根據(jù)MISRA設(shè)置開發(fā)過程;如何使用靜態(tài)分析器檢查代碼的合規(guī)性;必須維護(hù)哪些文件，如何填寫等等。

目前，MISRA不斷發(fā)展。例如，MISRA在2019年初宣布了MISRA C：2012第三版（第一版）”。MISRA C：2012版已更新并擴(kuò)展了新規(guī)則。同時，即將發(fā)布的“MISRA C：2012修正案2 - C11核心”，這是2012年的修訂標(biāo)準(zhǔn)。

MISRA C++也不會停滯不前。如您所知，MISRA C++的最后一個標(biāo)準(zhǔn)可以追溯到 2008 年，因此它涵蓋的語言的最新版本是 C++03。正因?yàn)槿绱?，還有另一個類似于MISRA的標(biāo)準(zhǔn)，它的名字是AUTOSAR C++。它最初旨在作為MISRA C++的延續(xù)，旨在涵蓋該語言的更高版本。與其策劃者不同，AUTOSAR C++每年更新兩次，目前支持 C++14。新的 C++17 和 C++20 更新尚未到來。

結(jié)論

在本文中，我想說明使用靜態(tài)分析器對于任何嵌入式項(xiàng)目都非常有用。使用靜態(tài)分析將幫助您：

減少查找和修復(fù)錯誤所需的時間;

減少出現(xiàn)嚴(yán)重錯誤的可能性;

減少對固件更新的需求;

監(jiān)控整體代碼質(zhì)量;

監(jiān)控新團(tuán)隊(duì)成員的表現(xiàn);

嚴(yán)格遵守一定的軟件開發(fā)標(biāo)準(zhǔn);

監(jiān)控第三方模塊/庫的代碼質(zhì)量。

審核編輯：郭婷