隨著汽車向自動駕駛汽車發(fā)展，硬件和軟件的功能安全是軟件開發(fā)人員、工程師、經(jīng)理和高管最關心的問題。沒有不折不扣的安全性，就不會有自動駕駛汽車。

功能安全是系統(tǒng)或設備響應其輸入的正確操作。當功能安全得到滿足時，該系統(tǒng)已經(jīng)消除了所有不可接受的風險，并且不會對乘員造成傷害威脅。不幸的是，由于嵌入式軟件通常非常復雜，因此很難降低所有風險。

汽車行業(yè)的安全標準 ISO 26262 定義了開發(fā)軟件以降低風險和生產(chǎn)更安全軟件的方法。ISO 26262 中定義的功能安全是一種為車輛中的每個電氣或電子系統(tǒng)設定安全目標的方法。這些目標使用汽車安全完整性等級 （ ASIL ） 分類按嚴重程度分類。這些級別由風險級別確定，ASIL A 為最低嚴重性，ASIL D 為最高。例如，ASIL A 風險可能是 DVD 播放器故障（沒有受傷的機會），而安全氣囊意外展開是 ASIL D 風險。想象一下在高速公路上以 55 英里/小時的速度進行部署：很可能會造成嚴重傷害和失控。

ASIL 是在開發(fā)過程開始時確定的。ASIL 用于定義系統(tǒng)必須滿足的安全目標。通過檢查事故的可能嚴重程度、暴露時間量以及在這種情況下車輛的可控性來確定每個 ASIL。ASIL 迫使設計人員提出這樣一個問題：“如果出現(xiàn)功能故障，操作員、相關道路使用者和周圍環(huán)境會發(fā)生什么？”

該標準定義了開發(fā)軟件以滿足功能安全要求的方法。這些要求包括軟件開發(fā)過程的管理、可追溯性、風險管理和質(zhì)量保證。公司需要實施嚴格的過程控制。

那么，如何才能開發(fā)出具有這些嚴格要求的產(chǎn)品呢？

確保功能安全的工具

大多數(shù)軟件錯誤和問題是由于需求不足和管理不善造成的。糟糕的需求會導致功能執(zhí)行不正確或不可靠，從而導致功能安全失敗。當一個功能執(zhí)行不正確時，可能會導致對其他軟件功能的干擾，違反了 ISO 26262 的“基本指令”，即不受干擾。

當軟件造成干擾時，可以使用靜態(tài)分析來查找錯誤。使用靜態(tài)分析的主要優(yōu)點之一是您可以在完成的模塊準備好后立即開始分析。分析可以繼續(xù)，直到整個產(chǎn)品代碼集完成。

可以對源代碼或目標代碼執(zhí)行靜態(tài)分析。分析二進制文件有一些優(yōu)點。例如，它不依賴于使用的編譯器或匯編器。它還可以揭示編譯器或匯編器在沒有源代碼的情況下引入的錯誤。

然而，缺乏關于編譯器以及它如何優(yōu)化代碼的信息使得一些分析變得不可能。此外，您無法將錯誤追溯到源代碼中的違規(guī)點，因此對于糾正錯誤幾乎沒有用處。

因此，當使用源代碼時，分析質(zhì)量會大大提高。使用源代碼，您確實可以將故障追溯到它發(fā)生的點。當然，您必須擁有可用于運行靜態(tài)分析的源代碼。

靜態(tài)分析揭示了 ASIL 功能在未經(jīng)許可的情況下非法嘗試訪問受保護內(nèi)存的干擾。您可以想象在自動駕駛車輛中破壞受保護的內(nèi)存的后果 - 甚至在您當前的車輛中。如果您點擊 DVD 播放按鈕而不是更改巡航控制設置，可能會導致壞事！

靜態(tài)分析確保不受干擾

靜態(tài)分析不能代替硬件和軟件驗證，但對于防止應用程序中的干擾非常有價值。它可以在您的源代碼中發(fā)現(xiàn)違反 ISO 26262 要求的錯誤。通過在開發(fā)代碼時發(fā)現(xiàn)問題，驗證通?？梢愿斓剡M行。具有 SIL 意識的靜態(tài)分析涵蓋了完整的代碼庫。您可以在編寫完第一個軟件元素后立即開始分析，然后繼續(xù)分析，直到所有軟件都集成到系統(tǒng)中。

審核編輯：郭婷