作者：Shawn Prestridge，IAR Systems行業(yè)分析兼高級現(xiàn)場應(yīng)用工程師/美國FAE團隊負(fù)責(zé)人

　　序言

　　在汽車、航空電子、醫(yī)療和工業(yè)控制等眾多行業(yè)中，新開發(fā)的應(yīng)用在大多數(shù)情況下必須取得相應(yīng)的功能安全認(rèn)證。通過所有必要的流程和測試來完成功能安全認(rèn)證歷來是一個非常困難的過程，但有一些方法有助于加快完成認(rèn)證的速度。當(dāng)然，選擇諸如IAR Embedded Workbench這樣本身就獲得了認(rèn)證，并在多樣化的實際應(yīng)用中經(jīng)過驗證的開發(fā)工具，也是加快從設(shè)計到完成認(rèn)證過程的方法。

　　在開發(fā)功能安全型關(guān)鍵應(yīng)用中，開發(fā)人員可以采取多項調(diào)整措施來加快認(rèn)證，然而這一切都依賴于應(yīng)用的代碼質(zhì)量。要怎么做代碼質(zhì)量才能得到保障呢？幸運的是，我們擁有一些簡單的方法來立竿見影地提升代碼質(zhì)量，并盡可能地減少工作量。

　　善用標(biāo)準(zhǔn)

　　您知道嗎，在C99代碼規(guī)范中有大約190個歧義？確切地說，在C99中，有190種語法上合法的C結(jié)構(gòu)，但在C語言規(guī)范中卻沒有得到明確說明。實際上，如果使用最新的C18代碼規(guī)范，情況會變得更糟一些，如果在C++中引入多重繼承和虛擬繼承，將會陷入更為糟糕的局面。編譯器會把源代碼轉(zhuǎn)變成可執(zhí)行代碼，因此必須對代碼的含義進(jìn)行解析后才能正確運行。

　　在實際情況中，開發(fā)人員可能會用到不同的編譯器，它們可能會對源代碼進(jìn)行不同的解釋。然而，在一個高可靠性的系統(tǒng)中，這將是一個噩夢般的場景，尤其是許多追求功能安全認(rèn)證的公司一般都會在多個平臺上交叉編譯他們的代碼以方便測試?？梢韵胂?，這將嚴(yán)重拖慢認(rèn)證速度，因為您必須針對所有此類情況進(jìn)行測試，以證明代碼的可重復(fù)性和可靠性。

　　怎樣才能度過這個難關(guān)呢？簡單來說，避免代碼歧義即可。但要如何做到這一點呢？開發(fā)人員可以選擇MISRA這樣的編碼標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)經(jīng)設(shè)計，可避免常見的代碼歧義。此外，該標(biāo)準(zhǔn)還提倡運用安全可靠的編碼實踐，以減少代碼中的缺陷數(shù)量。有了功能安全標(biāo)準(zhǔn)，問題就能迎刃而解。

　　功能安全標(biāo)準(zhǔn)涵蓋了代碼分析

　　幾乎每一個功能安全標(biāo)準(zhǔn)都要求開發(fā)人員對代碼進(jìn)行靜態(tài)分析，而且還會強烈建議項目團隊對代碼進(jìn)行運行時（或稱之為動態(tài)）分析。其中影響最廣的標(biāo)準(zhǔn)是IEC 61508，在通常意義上它適用于所有安全相關(guān)系統(tǒng)。根據(jù)該標(biāo)準(zhǔn)第C.4.2節(jié)的內(nèi)容，不建議在安全完整性等級（SIL）在1級以上的情況下使用沒有消除歧義和危險行為的編碼標(biāo)準(zhǔn)的C語言。換句話說，如果開發(fā)的產(chǎn)品要獲得SIL 2-4認(rèn)證，就必須使用靜態(tài)分析來提升代碼的健壯性。

　　而靜態(tài)分析工具可以強制開發(fā)者實施編碼標(biāo)準(zhǔn)，如MISRA。此外，靜態(tài)和運行時分析可以快速指出有風(fēng)險的編碼行為，特別是之前提到的編碼標(biāo)準(zhǔn)歧義，因此有助于提高代碼質(zhì)量?；谶@樣的考慮，開發(fā)人員應(yīng)當(dāng)更多地選擇諸如IAR Embedded Workbench這類在多樣化應(yīng)用中得到驗證的工具，它們可以提供更全面的標(biāo)準(zhǔn)化功能。

　　然而，何時使用這些類型的自動化工具也會對項目的認(rèn)證時間表產(chǎn)生巨大影響。許多公司組織會使用難以配置、難以使用的代碼分析工具，使其每晚運行在構(gòu)建服務(wù)器上。然而這種工具實際作用有限，因為每個程序開發(fā)者無法得到即時反饋，弄清他們剛寫的代碼究竟有什么問題。

　　此外，有時這些工具發(fā)出的警告信息本身就晦澀難懂，浪費了開發(fā)者的時間去弄清楚它們的真正含義，以及如何糾正代碼來消除警告。如果能在開發(fā)過程中先運行代碼分析，然后才進(jìn)入正式構(gòu)建，那么就可以完美避免代碼缺陷。如此一來，項目代碼缺陷注入率將大幅降低，這正是認(rèn)證機構(gòu)非?？粗氐闹笜?biāo)，因為這意味著項目有一個非常成熟的開發(fā)組織。

　　將代碼分析融入日常工作流程

　　根據(jù)針對多個行業(yè)里多家公司開展的調(diào)研的結(jié)果，IAR Systems團隊發(fā)現(xiàn)，代碼分析工具的配置和使用越容易，開發(fā)者選用它的幾率就越高，也能更快受益。如果能將這些自動化工具納入到開發(fā)者的工具箱中，那么開發(fā)者就可以在編寫應(yīng)用時隨時檢查和改進(jìn)代碼質(zhì)量，同時在“實地”考察這部分代碼要做什么以及它如何與系統(tǒng)中的其他模塊互動。為了有效地做到這一點，必須將代碼分析工具整合到日常工作流程中。

　　為了解其他人對集成代碼分析的看法，IAR團隊在查閱資料時發(fā)現(xiàn)谷歌在ACM期刊上發(fā)表了一篇文章，探討了代碼分析的優(yōu)點。雖然文章對他們的整個代碼庫（包括C、C++和Java）進(jìn)行了全面的考察，但他們的結(jié)論非常明確：

　　“在開發(fā)過程的早期就能發(fā)現(xiàn)編譯器錯誤，并且能夠整合到開發(fā)者的工作流程中。我們發(fā)現(xiàn)擴大編譯器的檢查集合對提高谷歌的代碼質(zhì)量是有效的?！?/p>

　　作者表示，把靜態(tài)分析檢查整合到編譯器工作流程并輸出為Error信息，將極大地提高開發(fā)者對工具輸出信息的關(guān)注，最終大幅提升代碼質(zhì)量。再往下看，他們談到了向最近遇到某個編譯器錯誤的開發(fā)者和已經(jīng)收到該錯誤問題的修復(fù)補丁的開發(fā)者發(fā)出相同的調(diào)研。

　　“谷歌的開發(fā)者認(rèn)為，在編譯時標(biāo)記出錯誤信息（相比于植入代碼檢測功能的補?。┠懿蹲降礁卮蟮腻e誤；例如，調(diào)研參與者認(rèn)為在編譯時標(biāo)記的問題中的74%屬于真正的問題，而在檢測代碼中發(fā)現(xiàn)的真正問題只有21%?！?/p>

　　此外，該文章還談到了將代碼分析整合到工作流程的重要性，指出當(dāng)他們通過靜態(tài)分析工具自動運行提交的代碼并邀請工程師查看分析儀表板時，很少有工程師跟進(jìn)。但是，如果在編譯過程中就能得到即時反饋，則靜態(tài)分析工具的使用更便捷且分析結(jié)果也更難被忽視。因此，他們選擇在每個人的工作流程中默認(rèn)集成靜態(tài)代碼分析。他們認(rèn)為要推廣代碼分析工具，開發(fā)者必須感到能從中受益，并且喜歡使用這些工具。

　　在工作流程中加入代碼分析會得到什么樣的結(jié)果？結(jié)果之一是提高了應(yīng)用的整體安全性，因為優(yōu)質(zhì)代碼可以消除緩沖區(qū)溢出、非法指針等漏洞。雖然這個理由足夠充分，但有時很難讓人們做到“防范于未然”，您需要更顯著的結(jié)果來說服開發(fā)者和管理層相信代碼分析的優(yōu)點。

　　Stefan Wagner等人的一篇論文（https://arxiv.org/pdf/1711.05019.pdf）使用經(jīng)驗數(shù)據(jù)來計算代碼分析工具與傳統(tǒng)測試在不同代碼庫中的優(yōu)劣。他們的結(jié)果很有說服力，在769個被識別的缺陷中，76%是被代碼分析工具發(fā)現(xiàn)的，而只有4%被傳統(tǒng)測試發(fā)現(xiàn)（其余20%則在代碼審查時發(fā)現(xiàn)）。

　　如果能在開始測試前就消除75%的缺陷，實現(xiàn)軟件平均故障間隔時間（MTTF）目標(biāo)能有多快？答案是“非?？臁薄H僅是在測試上節(jié)省的時間和金錢就值得在代碼分析工具上進(jìn)行投資，更不用說它還能加快上市時間。這些都是功能安全認(rèn)證機構(gòu)喜歡看到的流程類型，因為它極大地降低了缺陷進(jìn)入最終產(chǎn)品的風(fēng)險。

　　優(yōu)質(zhì)代碼加速功能安全認(rèn)證

　　加快功能安全認(rèn)證的關(guān)鍵是提高代碼質(zhì)量。只有提高代碼質(zhì)量，項目團隊才可以降低缺陷注入率，從而更快地達(dá)到軟件發(fā)布標(biāo)準(zhǔn)，這樣在提交給功能安全認(rèn)證機構(gòu)認(rèn)證時，它們才會認(rèn)為您的組織擁有非常成熟的流程。雖然開發(fā)者永遠(yuǎn)無法確切知道一個應(yīng)用中還有多少缺陷，但通過早期和經(jīng)常使用代碼分析工具將有助于減少其數(shù)量。

　　文章作者：Shawn Prestridge，IAR Systems行業(yè)分析兼高級現(xiàn)場應(yīng)用工程師/美國FAE團隊負(fù)責(zé)人