近年來，電子業者和晶片設計企業大舉進攻汽車、醫療和工業等關鍵任務（mission-critical）領域，為自己找到了擺脫紅海的新領域。
但是高可靠應用多數都需要功能安全認證，在諸如汽車、航空電子、醫療和工業控制等許多行業中，這是很常見甚至是必須的項目。
這些認證透過必要的流程和測試來填寫功能安全清單，一直以來都是一個非常困難的事情，但有一些方法可以加快您的認證流程。雖然對開發過程進行大量的微調以加快認證可能可行，但一切現代電子資訊系統都從軟體即程式碼程式碼品質開始。
但如何能夠確保程式碼品質呢？幸運的是，使用一些簡單的方法，可以幾乎立即提升您的程式碼品質，並盡可能地降低所需心力。
為什麼 C/C++ 程式碼需要編碼標準（如 MISRA）來消除語法歧義？
作為一家產品被全球近五萬家企業/機構採用的嵌入式開發工具提供商，IAR的研發工程師評估，在C99中，程式碼規範約有190種模棱兩可之處。
也就是在C99中，有190種不同的合乎句法的C結構，在C語言規範中沒有明確說明。實際上，進入C18，情況會變得有一點糟糕，在C++中情況會更糟，這裡需要導入多繼承和虛擬繼承的概念。
當然，編譯器必須把您的原始程式碼變成具體的程式碼，所以它必須對程式碼的含義選擇一種解釋，然後以此來運行。
這在實踐中意味著，您可以得到不同的編譯器，它們對原始程式碼有不同的解釋。在一個高可靠的系統中，這是一個如同噩夢般的場景；特別是由於許多公司為了追求儘快通過功能安全認證及方便測試在多個平台上交叉編譯他們的程式碼。
可以想像，這對您獲得認證的時間會有多麼糟糕的影響，因為您不得不圍繞所有這些情況進行測試，以證明程式碼的可重複性和可信賴性。
該如何破解這個難題呢？簡短的答案是，避免模棱兩可的情況出現在您的程式碼中。但如何做到這一點呢？
使用像MISRA這樣的編碼標準可以快速解決這個難題，因為這些標準就是為了讓您避免掉入程式碼中那些常見類型的陷阱。
這些標準還宣導編碼要安全可靠，以減少您程式碼中的漏洞數量。但是，如何才能確保我們遵循這些標準呢？幸運的是，功能安全標準提供了一種方法。
IEC 61508 與 SIL 認證的要求：為何必須進行程式碼靜態與動態分析？
幾乎每一個功能安全標準都需要您對程式碼進行靜態分析，並且強烈建議您對程式碼進行動態分析。
這些標準中影響最廣的是IEC 61508，涵蓋了一般與安全相關的系統。在該標準的C.4.2這一節中，對於安全完整性等級（SIL）1以上的產品，不建議使用沒有消除模棱兩可和危險行為的編碼標準的C語言。
換句話說，如果您想為您的產品獲得SIL 2-4等級的認證，您必須使用靜態分析來讓程式碼更加穩固。
這是為什麼呢？這些靜態分析工具可以迫使開發者實施諸如MISRA的編碼標準。
此外，靜態和運時分析可以幫助您提高程式碼品質，快速指出您何時的編碼行為是有風險的，特別是存在上述編碼標準中模棱兩可的情況。
然而，當您使用這類自動化工具時，也會對您的認證時間產生巨大影響。許多組織使用難以配置、難用的程式碼分析工具，這些工具在構建伺服器上運行，作為每日構建的一部分。這對您的幫助並不是很大，因為個體開發者並沒有得到即時的回饋，他們並不知道自己剛剛寫的程式碼有什麼問題。
此外，有時這些工具發出的警告資訊是難以理解的，開發人員必須釐清是什麼意思，以及怎樣修正程式碼才能讓警告消失，而這會浪費了他們的時間。
換句話說，安全性認證不是要突出專案的優點（高性能），而是要儘量找出專案的弱點（漏洞），所以要盡可能地選用被最大量開發人員群體驗證過的開發工具，或者是“見多識廣”的開發工具系統。
全球有超過15萬開發人員使用IAR提供的IAR Embedded Workbench開發工具來完成其各種嵌入式專案，透過與其中許多“高手”開發人員溝通發現：如果您能在開發過程中進行程式碼分析–在正式構建之前–那麼漏洞就像是從來沒有過一樣，您專案的漏洞會比較低，這正是認證機構想要的，因為這意味著您有一個非常成熟的開發組織。
如何在日常開發中整合程式碼分析，大幅降低測試成本與產品上市時間？
IAR的工程師們見過許多來自各行各業的公司，我們注意到，配置越容易使用的程式碼分析工具越簡單，開發人員就更有可能使用它們，如此將能幫助開發人員更快完成專案實現產品上市。
讓這些自動化工具成為開發者工具箱的一部分，意味著您可以在編寫應用程式時檢查和改進程式碼品質，同時可以在“區域 ”內瞭解這部分程式碼的用途，以及它如何與系統中的其他模組進行交互作用。為了有效地做到這一點，這些工具必須被整合到日常工作流程中。
在瀏覽其他人對整合程式碼分析的看法時，IAR的工程師發現Google在ACM出版物上發表了一篇文章，探討了程式碼分析的優點。
雖然文章對他們的整個程式碼庫，包括C、C++和Java進行了全面的考察，但他們的結果非常明確：
“在開發過程的早期就能發現編譯器錯誤，並且能夠整合到開發人員的工作流程中。我們發現擴大編譯器的檢查集對提高 Google 的程式碼品質是有效的。”
作者表示，將靜態分析檢查整合到編譯器工作流程中，並使其作為錯誤出現可大幅提高了對工具調查結果的關注度，這意味著將能提升其程式碼品質。
再往下看，他們談到了一項調查，這項調查針對最近遇到編譯器錯誤以及已經修復同一問題補丁的開發者所提出：
“Google開發人員認為，在編譯時標記的問題（與已提交的程式碼補丁不同）能捕捉到更嚴重的漏洞；例如，編譯過程中標記的問題裡面有74%被調查參與者認為是‘真正的問題’，相較之下，在已提交的程式碼中發現的問題只有21%。”
文章還談到了將程式碼分析作為工作流程一部分的重要性，指出當他們透過靜態分析工具自動運行提交的程式碼，並邀請工程師查看分析儀錶板時，很少有工程師跟進到底。
在編譯過程中的即時回饋讓靜態分析的使用更簡單，也更難被忽視。因此，他們選擇在每個人的工作流程中預設加入靜態分析。
Google團隊認為，程式碼分析工具要想取得成功，一定要讓開發人員覺得他們運用了這些工具並從中受益，並且很享受使用這些工具。
但是，在工作流程中加入程式碼分析，您期望看到什麼樣的結果呢？有一件事情是可以期望實現的，那就是提高應用程式的整體安全性，因為高品質程式碼可以消除漏洞來利用諸如緩衝區溢位和非法指針等機會，如該文所述。
雖然這本身就是使用程式碼分析的一個良好理由，但有時很難說服人們，您需要更明顯的結果來說服開發者和管理階層，讓他們信服程式碼分析的好處。
Stefan Wagner等人的一篇論文使用經驗資料來計算程式碼分析工具與傳統測試在不同程式碼庫上的優勢。
其結果很具說服力：在769個被識別到的漏洞中，76%是被程式碼分析工具所發現，只有4%是在傳統測試中發現，其餘20%在程式碼審查中發現。如果能在開始測試前就消除75%的漏洞，那麼能多快地實現軟體的平均故障間隔時間（MTTF）目標？
答案是「非常快」。
僅僅是看測試節省下來的時間和金錢，即可發現對程式碼分析工具的投資就是值得的，更不用說加速產品上市所省下的時間。
這些都是功能安全認證機構喜歡看到的流程類型，因為它大幅降低了最終產品仍然含有漏洞的風險。
總結：以早期程式碼分析降低漏洞率，才是快速通過功能安全認證的最佳捷徑
加速功能安全認證之路的關鍵是提高程式碼品質。
提高程式碼品質可降低您的產品漏洞率，這意味著可以更快地達到軟體發表標準，讓您的開發組織在功能安全認證機構看來非常成熟。
雖然您永遠不可能確切地知道一個應用程式中還有多少漏洞，但儘早地多使用程式碼分析工具可以減少漏洞的數量。
歡迎前往 ➤ 與 FSG 功能安全專家們繼續深入探討
文由IAR提供