這是數(shù)字化的風(fēng)險之一：網(wǎng)絡(luò)犯罪分子在自動駕駛汽車中發(fā)現(xiàn)安全漏洞，并操縱油門或制動。隨著車輛中軟件占比越來越高，與安全漏洞相關(guān)的風(fēng)險也會增加。長期以來，全面分析和符合編碼標(biāo)準(zhǔn)已成為必不可少的。靜態(tài)代碼分析可以在這方面提供幫助，因?yàn)檎_使用代碼，可以顯著提高代碼質(zhì)量。

在討論功能安全時，繞不開ISO26262。車輛中大多數(shù)軟件組件必須得到相應(yīng)的認(rèn)證，對于這些軟件組件，ISO26262建議在軟件編碼要遵循編碼規(guī)范。汽車領(lǐng)域最成熟的編碼標(biāo)準(zhǔn)莫過于MISRA C，MISRA C中的編碼規(guī)則構(gòu)成了高水平源碼質(zhì)量的基礎(chǔ)，如果不嚴(yán)格執(zhí)行編碼標(biāo)準(zhǔn)，則很難獲得功能安全認(rèn)證，但是鑒于當(dāng)前軟件的復(fù)雜性很高，如果不使用自動化工具，這將是一項(xiàng)艱巨的任務(wù)。

近年來，靜態(tài)代碼分析越來越受汽車行業(yè)重視。適當(dāng)?shù)墓ぞ呖梢栽诰幋a過程中檢查代碼是否滿足編碼規(guī)則，如果不滿足，立即顯示違反的規(guī)則，并提示修改措施，這樣可以幫助開發(fā)人員遵守編碼規(guī)則。這樣一來可以在開發(fā)階段就避免潛在的問題，從而節(jié)省時間和精力，還能保證產(chǎn)品的質(zhì)量。

盡早引入代碼靜態(tài)分析

“盡早”意味著在流程中引入靜態(tài)代碼分析的最佳時間是盡可能早的。理想情況下，應(yīng)在開始編碼之前部署合適的工具。然而，實(shí)際上，汽車行業(yè)的軟件開發(fā)項(xiàng)目很少是從頭開始。取而代之的是，開發(fā)是基于現(xiàn)有的代碼進(jìn)行的，例如來自開源，第三方開發(fā)人員或以前的項(xiàng)目的代碼。在這種情況下，應(yīng)盡早追溯并引入相應(yīng)的工具，然后在整個開發(fā)過程中持續(xù)使用，這樣就可以確保至少將來的代碼從一開始就滿足代碼規(guī)范的要求。
在準(zhǔn)備部署靜態(tài)代碼分析工具時，應(yīng)該考慮軟件集成的需求，例如開發(fā)人員使用的編譯器？該工具如何與版本管理系統(tǒng)一起使用？如何與現(xiàn)有的工具鏈進(jìn)行融合？最好的商業(yè)工具將允許靈活的部署方案，并與其他流行的開發(fā)工具順利集成。

靜態(tài)代碼工具部署：第一步在開發(fā)人員的電腦桌面

靜態(tài)分析器直接安裝在開發(fā)人員的電腦上。這種解決方案可以在源代碼編寫的時候?qū)崟r檢測代碼是否符合相關(guān)的編碼規(guī)范(如圖1)。如果某些代碼不符合當(dāng)前設(shè)定的編碼規(guī)則，則開發(fā)人員會看到提示窗，以便開發(fā)人員可以更正此問題。由于提供了有關(guān)如何編寫代碼才能符合MISRA C規(guī)范的即時反饋結(jié)果，開發(fā)人員在中長期進(jìn)行了培訓(xùn)，使其更加合規(guī)，慢慢的效率也就提高了。


圖1 靜態(tài)代碼分析
另外分析工具也會檢查當(dāng)前代碼組件是否存在客觀錯誤。這樣可以調(diào)高源碼質(zhì)量，從而節(jié)省時間和成本，例如潛在錯誤存在源碼中的時間越長，則需要追溯檢查已執(zhí)行的流程和對其修復(fù)的成本就越高。更不用說如果部署在最終的產(chǎn)品中，它可能會成為安全漏洞，

第二步：構(gòu)建在服務(wù)器上
在持續(xù)集成流程的形式中，進(jìn)一步的分析流程將在服務(wù)器部署的幫助下執(zhí)行。這通常是夜間在服務(wù)器上分析，涉及完整的項(xiàng)目分析，包括白天簽入的所有代碼部分。除了來自單個開發(fā)人員代碼的檢查，項(xiàng)目作為一個整體也會被檢查。服務(wù)器部署的核心是深度數(shù)據(jù)流分析。這模擬了每個可能的執(zhí)行路徑的執(zhí)行，而不是實(shí)際創(chuàng)建一個可執(zhí)行程序。相反，它創(chuàng)建了一個軟件的行為模型，可以用來監(jiān)控變量及其在運(yùn)行時將被分配的值。數(shù)據(jù)流分析還可以識別冗余代碼，或永遠(yuǎn)不被執(zhí)行的代碼，這類代碼可能會指向設(shè)計(jì)錯誤。另外在硬件資源嚴(yán)格受限的嵌入式系統(tǒng)中，它們可能會占用寶貴的存儲空間。

在服務(wù)器分析過程中識別出的任何錯誤或沖突都會被標(biāo)記以供審查。理想情況下，所使用的分析工具應(yīng)該集成到一個問題管理系統(tǒng)中。這允許自動整理問題，并且分發(fā)給相應(yīng)的開發(fā)人員，以便在第二天進(jìn)行修復(fù)。另外也有可能發(fā)現(xiàn)了團(tuán)隊(duì)已知的問題，或者與各自項(xiàng)目無關(guān)的問題，例如，項(xiàng)目中根本沒有使用特定的MISRA規(guī)則。即使這些與故障排除無關(guān)，也可以使用一個復(fù)雜的分析工具來確保對它們進(jìn)行正式的文檔化。如果進(jìn)行了審核，團(tuán)隊(duì)可以很容易地證明該問題不是一個被忽略的錯誤，而是一個經(jīng)過考慮的已知偏差，并且不會對車輛的正確運(yùn)行產(chǎn)生風(fēng)險。

為了在實(shí)踐中使該解決方案達(dá)到最高的有效性，在引入和使用過程中要注意多個方面，這一點(diǎn)很重要。分析的效率隨著工具針對特定工作環(huán)境、特定目標(biāo)和特性的定制程度的提高而提高。

一般來說，引入這樣的工具也需要進(jìn)行個別的微調(diào)。如果不這么做,大多數(shù)時候可以檢測出目標(biāo)錯誤,但同時也存在風(fēng)險。解決方案會產(chǎn)生大量的誤報。沒有優(yōu)化配置的工具可能會產(chǎn)生許多誤報，這需要時間和精力來優(yōu)化工具。這可能會產(chǎn)生挫折感，并降低對工具的信心。因而開發(fā)人員可能不太愿意使用這個工具，這將不可避免地導(dǎo)致更多的安全問題出現(xiàn)在最終產(chǎn)品中。

另外一個潛在的風(fēng)險在于靜態(tài)分碼分析工具引入時，未對開發(fā)人員進(jìn)行培訓(xùn)，導(dǎo)致開發(fā)人員不能準(zhǔn)確的分析報出的原因，另外也要認(rèn)識到靜態(tài)代碼分析的局限性，例如，它不能根據(jù)開發(fā)人員的實(shí)際意圖來檢查一段代碼，例如,如果一個函數(shù)是用來計(jì)算面積，但是開發(fā)人員寫成圖2所示,靜態(tài)代碼分析不會檢測到一個錯誤,除非使用的變量出現(xiàn)了溢出。為使代碼分析在實(shí)踐中達(dá)到比較好的效果,汽車專家不應(yīng)低估所需的努力訓(xùn)練開發(fā)人員的重要性。


圖2 靜態(tài)分析工具可能檢測到可能的溢出，但無法確定該功能沒有執(zhí)行預(yù)期的操作

一旦正確的先決條件已經(jīng)就位，在實(shí)踐中成功使用靜態(tài)代碼分析的思路就清晰了。具體的好處可以用數(shù)字來衡量，并在整個項(xiàng)目中直接監(jiān)控?？梢远攘抠|(zhì)量指標(biāo)，并將其與代碼的快照關(guān)聯(lián)起來，以構(gòu)建隨著時間推移的進(jìn)度圖。

最后就可以成為項(xiàng)目經(jīng)理或者是管理者匯報項(xiàng)目的指標(biāo)，例如錯誤數(shù)量隨時間變化的報告，或者顯示自引入解決方案以來，代碼復(fù)雜性降低了多少。最終每個人都最終受益于改進(jìn)代碼質(zhì)量：開發(fā)人員負(fù)擔(dān)減小，不要因?yàn)槟涿畹膯栴}抓破頭腦；汽車制造商可以得到滿足合規(guī)要求的產(chǎn)品，并且獲得不錯的口碑，最后消費(fèi)者使用的車輛更加安全。