如何提升項目代碼質(zhì)量以快速通過(guò)功能安全認證

序言

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

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

善用標準

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

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

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

功能安全標準涵蓋了代碼分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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