利用汽車開發(fā)標準規(guī)范汽車應用程序的軟件開發(fā)

當普通的非工程師消費者想到汽車中的電子系統(tǒng)時，他們可能會想到集成 GPS、信息娛樂系統(tǒng)，并且可能會想到汽車某處有一臺計算機控制某些安全功能的模糊概念。當然，現(xiàn)實情況是現(xiàn)代汽車要復雜得多，軟件在功能的各個方面發(fā)揮著越來越大的作用，包括許多對安全至關(guān)重要的功能。事實上，幾十年來，汽車一直在利用電子系統(tǒng)實現(xiàn)關(guān)鍵功能，而市場變化，例如推動“物聯(lián)網(wǎng)”，推動汽車制造商嵌入更多運行關(guān)鍵范圍的復雜計算機系統(tǒng)。

與系統(tǒng)開發(fā)相關(guān)的業(yè)務結(jié)構(gòu)和供應鏈進一步增加了復雜性。很少有制造商從頭開始設計和構(gòu)建汽車中的每個組件和子系統(tǒng)，這會導致潛在的集成問題。變速箱取自該模型，該模型具有良好的制動系統(tǒng)。雖然它們可能在以前的環(huán)境中運行良好，但在一個全新的復雜系統(tǒng)中，它們很可能會產(chǎn)生意想不到的結(jié)果。因此，汽車軟件通常是復雜的系統(tǒng)大雜燴，可能經(jīng)過充分測試，也可能未經(jīng)過充分測試。在沒有適當測試的情況下以臨時方式實現(xiàn)組件，尤其是在安全關(guān)鍵應用程序中，成本可能非常高。

不過，好處是，有一些已知的做法可以幫助汽車制造商通過將軟件質(zhì)量構(gòu)建到他們的開發(fā)過程中來降低失敗的風險。在本文中，我們將討論導致汽車軟件復雜性的一些問題，以及與汽車軟件開發(fā)相關(guān)的風險。我們還將討論實施已知的開發(fā)最佳實踐（例如 ISO 26262）如何幫助組織降低這些風險。

更多代碼會帶來更多風險嗎？

根據(jù)一些估計，一輛標準的中檔汽車可以有超過一百個電子控制單元 （ECU） 處理數(shù)百萬行代碼——而且這個數(shù)字還在增加。對于制造商來說，擁有幾款代碼超過 1 億行的汽車并不少見。

人們認為，汽車越貴，嵌入的軟件就越多——而且大多數(shù)軟件都專用于高端信息娛樂組件。雖然隨著模型線的升級，這些系統(tǒng)確實會變得越來越復雜，但即使是汽車的入門線也使用軟件來控制轉(zhuǎn)向、制動系統(tǒng)、電力分配等。即使是藍牙、氣候控制、巡航控制等功能看似微小的變化，也會導致代碼呈指數(shù)級增長。

我們可以假設更多的代碼會轉(zhuǎn)化為更多的復雜性——因此會帶來風險——但影響可能不一定很大。與汽車軟件相關(guān)的業(yè)務風險的更大貢獻者是從多個層級的各種來源開發(fā)的代碼的集成。大多數(shù)組件，包括基于 ECU 的組件，都分包給二級供應商，而二級供應商又分包給三級供應商，依此類推。前面的每一層都有與他們正在開發(fā)的組件相關(guān)的特定要求。組織通常（但并非總是）有分析傳入代碼的實踐，以確保組件按預期運行。

但這假設供應鏈上的每個組件都是新的發(fā)展。實際上，下游層正在分支為特定品牌、型號和年份編寫的代碼。代碼的變異和重用發(fā)生在整個供應鏈中，這導致了測試問題。制造商如何在如此混亂的軟件開發(fā)生態(tài)系統(tǒng)中實施端到端測試？當方向盤中的 ECU 最初是為一輛車開發(fā)的，而儀表板中的 ECU 是為另一輛車開發(fā)的，而這兩個 ECU 都不是為當前嵌入的車輛而設計的，那會產(chǎn)生什么影響？您如何確保整個系統(tǒng)按預期運行？兩個系統(tǒng)完全有可能通過功能測試，但在所有情況下都無法正常通信。

軟件質(zhì)量成本

當組織試圖衡量軟件開發(fā)的成本時，他們傾向于查看一般指標：工程師的開發(fā)時間；QA的測試時間；以獲取工具許可證、編譯器和其他基礎設施組件的形式“構(gòu)建材料”。這些是重要的指標，但經(jīng)常被忽視的是失敗的成本。

如果制動系統(tǒng)中的軟件出現(xiàn)故障，企業(yè)在返工、召回、審計、訴訟和庫存價值損失方面的成本是多少？如果有生命損失怎么辦？我們認為質(zhì)量成本是開發(fā)和測試軟件的成本，包括我們確定的所有正常指標以及與現(xiàn)場失敗相關(guān)的非常有形的成本。

缺陷使汽車制造商付出了很多錢。NHTSA 估計，整個行業(yè)的召回和修復每年使汽車制造商損失 30 億美元。當談到與軟件相關(guān)的問題的成本時，IEEE 2005 年估計制造商的成本為每輛車 350 美元。當您考慮到一系列車輛的低利潤率時，可以想象一個足夠嚴重的軟件缺陷會嚴重損害業(yè)務。

底線很重要，但更重要的是，人們可能會因軟件缺陷而受重傷甚至死亡。無論缺陷可能起源于供應鏈多遠，缺陷及其所有相關(guān)后果都成為汽車制造商的責任。因此，任何圍繞軟件開發(fā)的成本分析都需要考慮失敗的潛在成本。

軟件開發(fā)的現(xiàn)狀

我們認為，汽車軟件分層供應鏈的復雜性會導致與安全關(guān)鍵系統(tǒng)相關(guān)的整體風險。我們還重申了汽車業(yè)務的潛在成本。但是這個問題的另一個方面在于工程和軟件開發(fā)之間的文化差異。

軟件開發(fā)幾乎從來都不是工程。也就是說，來自工程原理的某些概念，例如可重復性、良好實踐的最佳實踐和對構(gòu)建標準的依賴，尚未在軟件開發(fā)中牢固確立。此外，對軟件開發(fā)人員的培訓可能不一致——甚至根本不存在——組織必須竭盡全力來驗證他們的開發(fā)人員是否擁有足夠的知識來構(gòu)建安全關(guān)鍵型軟件。

這與工程形成對比，在工程中，與軟件開發(fā)相比，學科的態(tài)度、思維方式和歷史強制執(zhí)行的過程不太容易出現(xiàn)缺陷。這并不是說工程師知道他們在做什么而軟件開發(fā)人員不知道。而是說，汽車工程作為一個領(lǐng)域的成熟度是軟件開發(fā)的兩倍，軟件的無形的、時間性的特性使一種傲慢的態(tài)度永存，如果它有效，那么它就完成了。

軟件開發(fā)的重點是更快的交付和功能需求——我們能多快擁有這個功能？管理層幾乎沒有動力在軟件開發(fā)生命周期中實施良好的工程實踐。在軟件中實現(xiàn)功能安全需要實施某些工程原則：

功能安全必須是主動的

過程必須是可控的、可測量的和可重復的

應通過執(zhí)行標準來預防缺陷

測試必須有效且具有確定性

應對復雜的內(nèi)存問題進行測試

好消息是圍繞軟件開發(fā)的態(tài)度一直在演變。ISO 26262、MISRA 和其他標準旨在通過為在軟件開發(fā)過程中實施工程概念提供基礎來規(guī)范汽車應用程序的軟件開發(fā)。一些組織將遵守 ISO 26262 和其他標準視為增加開銷的負擔，沒有任何直接價值，但事實是，與軟件缺陷相關(guān)的失敗成本遠遠高于確保質(zhì)量的成本。與指定特定規(guī)格的電線以承載已知電壓的電氣標準一樣，編碼標準可以提供有助于避免災難的指南。

作者：Arthur Hicken，Adam Trujillo

審核編輯：郭婷