一、車輛開發(fā)概述

汽車的開發(fā)流程中，首先會將汽車分割成動力總成、底盤、車身、多媒體和駕駛輔助等子系統(tǒng)（如圖1）。

圖1 車輛功能和控制器網(wǎng)絡(luò)

然后再進一步將各子系統(tǒng)劃分為次級子系統(tǒng)和組件。主機廠和供應(yīng)商會按照分工并行開發(fā)這些組件并測試，隨后再將各子系統(tǒng)集成為上級系統(tǒng)并再次測試，如此遞進最終集成為整車。

但這樣做的前提不僅是明確子系統(tǒng)和零部件的開發(fā)分工，同時還要確保在零部件安裝空間、車輛功能、生產(chǎn)等方面便于開展對系統(tǒng)的分區(qū)和集成合作。此外，汽車行業(yè)的一大特點是主機廠和供應(yīng)商之間的跨公司合作開發(fā)，因此不同的分工還必須在主機廠和供應(yīng)商之間明確分配。

同一款車輛存在不同變形又給開發(fā)流程增加了另一個維度。這意味著主機廠和供應(yīng)商在所有系統(tǒng)級別上很可能要面對多項目并行開發(fā)的情況。

無論哪種合作維度，都需要合作雙方針對各問題及其解決方案帶給系統(tǒng)的影響達成共識。同時，彼此在項目中的能力和責任也需定義清晰。這里向讀者提供兩種實踐中常用的整體開發(fā)方法：從技術(shù)維度出發(fā)的機電一體化方法以及從項目組織管理維度出發(fā)的系統(tǒng)工程法。

除了上述維度，主機廠和供應(yīng)商的合作還需考慮商務(wù)因素，尤其是產(chǎn)品追責和專利歸屬等法律問題。本文僅聚焦于技術(shù)維度，對此不做展開。

二、電子系統(tǒng)開發(fā)

車輛電子系統(tǒng)的開發(fā)與車輛開發(fā)類似。首先也需要將其劃分為若干子系統(tǒng)，包括控制器（硬件和軟件）、設(shè)定值發(fā)生器、傳感器和執(zhí)行器等，然后分工完成開發(fā)和測試，并逐步從局部集成至完整電子系統(tǒng)（圖2）。同樣的，在處理劃分和集成問題時，也會涉及跨子系統(tǒng)的合作。

電子系統(tǒng)的開發(fā)流程設(shè)計需要遵循兩個原則。

首先，這一流程應(yīng)該建立在久經(jīng)檢驗的基本流程模型之上，例如“能力成熟度模型集成”（CMMI?）、“軟件過程改進和能力評定 （SPICE） ”、V-模型或敏捷開發(fā)方法。

從實踐角度對上述四個概念進一步澄清。通常在一個汽車軟件開發(fā)組織中，符合 ASPICE 的流程都可在符合 CMMI 的基礎(chǔ)上繼續(xù)深化其可追溯性的嚴苛程度而實現(xiàn)。而 V 模型（或瀑布模型）是一種通用的軟件工程方法，而非標準，ASPICE 及 CMMI 流程均以 V 模型為核心理念。敏捷開發(fā)方法則強調(diào)開發(fā)效率，如經(jīng)過精細流程設(shè)計，可與 CMMI/ASPICE 流程在同一項目中并存。

其次，該流程也應(yīng)支持實現(xiàn)主流的汽車技術(shù)規(guī)范，如 AUTOSAR、JASPAR（、OSEK、ASAM等。其中，AUTOSAR 表示汽車開放系統(tǒng)架構(gòu)，JASPAR 代表日本汽車軟件標準化組織，OSEK代表汽車電子類開放系統(tǒng)和對應(yīng)接口標準，ASAM 則代表自動化及測量系統(tǒng)標準化組織。

此外，還可在流程中穿插一些發(fā)展成熟的程序和方法用以提升開發(fā)效率和質(zhì)量并降低開發(fā)成本，如仿真方法或快速原型方法等。

無論對整車開發(fā)、電子系統(tǒng)開發(fā)還是軟件開發(fā)，都會牽扯到開發(fā)者之間的大量交互。

圖2 電子系統(tǒng)開發(fā)概述

2.1 從硬件到軟件的轉(zhuǎn)變

電子系統(tǒng)的發(fā)展總體上遵循由硬件解決方案向軟件解決方案轉(zhuǎn)變的趨勢。

軟件解決方案在實現(xiàn)電子系統(tǒng)功能方面具有天然優(yōu)勢。通過軟件實現(xiàn)對子系統(tǒng)的閉環(huán)、開環(huán)控制或監(jiān)控，可以使子系統(tǒng)在諸如自適應(yīng)/自學習算法、安全性保障方法及診斷等各方面具有最高的設(shè)計自由度。這是其他技術(shù)載體，尤其是那些直接受安裝空間和制造工藝影響的技術(shù)方案所無法企及的。

因此，用軟件來實現(xiàn)汽車功能為主機廠和供應(yīng)商都帶來了巨大的潛在商機，有助于它們在激烈的行業(yè)生態(tài)競爭中脫穎而出。事實上，在其他工業(yè)領(lǐng)域我們也能發(fā)現(xiàn)類似的趨勢。

盡管軟件開發(fā)者會考慮到內(nèi)存的限制，但其并非主要制約因素。即使是當前具備最高數(shù)據(jù)和程序存儲要求的豪華電動車型，其內(nèi)存占整車 BOM成本也僅為 1%，常規(guī)的代碼優(yōu)化對整車成本的降低作用暫時十分有限。

2.3 產(chǎn)品生命周期

通常車輛的研發(fā)時長在 3 年左右，從批產(chǎn)到停產(chǎn)持續(xù)約7年，在最后一輛車下線后仍需繼續(xù) 15 年左右的運營和售后服務(wù)。因此一款車的生命周期可長達25 年（圖3）。

然而對于電子零部件，其技術(shù)的迭代速度遠高于整車產(chǎn)品的生命周期。這為零部件的售后配件供應(yīng)帶來了極大挑戰(zhàn)，通常需要在開發(fā)階段就將售后運維因素納入考量。同樣，電子零部件的快速迭代也會影響到軟件架構(gòu)設(shè)計，車企為了讓軟件功能維系持久的生命力，就必須使軟件和不同的硬件兼容。這一訴求推動了軟件架構(gòu)的標準化，也引發(fā)了業(yè)界對軟硬件解耦這一話題的關(guān)注。

圖3 車輛的產(chǎn)品生命周期

與硬件相比，軟件的迭代周期更短。將軟件刷新技術(shù)與控制器網(wǎng)絡(luò)化技術(shù)相結(jié)合，即可完成現(xiàn)場（通過車輛 OBD 端口）或遠程（OTA）程序刷新，從而避免了更換控制器的極高成本。更短的迭代周期也意味著在軟件開發(fā)時也必須要考慮到車輛全生命周期相當長時間內(nèi)的維護工作。

通常對軟件功能的更新和缺陷修復將一直持續(xù)到車輛停產(chǎn)。除軟件的兼容性挑戰(zhàn)外，主機廠和供應(yīng)商面臨的兩個最常見的現(xiàn)實問題是研發(fā)工具鏈的淘汰以及研發(fā)經(jīng)驗的傳承。因此在軟件開發(fā)之初選擇工具時即需考慮到全生命周期的可維護性，同時也需做好版本變更管理和技術(shù)資料的傳承。

2.4 安全要求

與機械或電信等其他行業(yè)相比，車輛功能對安全性的要求極高。這是因為在車輛出現(xiàn)事故時，人類（司機和乘客）位于事故發(fā)生區(qū)域內(nèi)的概率為 100%，導致人員傷害的概率更高；而在一般機械工程領(lǐng)域，如果采取適當?shù)淖韪舸胧┗虬踩b置，即可持續(xù)保障人員遠離事故發(fā)生地。

基本的安全注意事項在 ISO 26262或 IEC 61508等標準和 ECE 法規(guī)中已有明確規(guī)定。如今在乘用車領(lǐng)域，具備基礎(chǔ)的功能安全保證已經(jīng)成為車輛獲批上路的前提條件。

電子系統(tǒng)和軟件功能對車輛安全的影響在不斷增加，從行駛情況分析（如車速顯示）、情景評估（如結(jié)冰警告）、行動建議（如導航），再到行動執(zhí)行（如加速或制動干預）幾乎無所不包，甚至還涉及主動的駕駛干預（如主動轉(zhuǎn)向）。

因此，功能安全分析以及安全概念設(shè)計已成為功能及軟件開發(fā)的必須環(huán)節(jié)。但凡有較高的安全要求，就必須采取故障識別和故障響應(yīng)措施。而系統(tǒng)冗余設(shè)計是故障識別和響應(yīng)的最有效措施之一。因此我們可以認為，對功能安全的高要求加速了汽車分布聯(lián)網(wǎng)式系統(tǒng)的演變。

此外，高安全性也對開發(fā)流程和工具提出了特殊的要求，包括開發(fā)流程、開發(fā)工具、標準化軟件組件（例如適用于高功能安全等級的經(jīng)典 AUTOSAR 操作系統(tǒng)）等。

三、電子系統(tǒng)和軟件開發(fā)的核心流程

由于如上所述的車輛、電子系統(tǒng)和軟件開發(fā)之間存在大量的相互影響，我們需要建立一套可銜接各環(huán)節(jié)的開發(fā)流程，以涵蓋從用戶需求分析到電子系統(tǒng)驗收測試的所有步驟。

汽車工業(yè)中通常采用 V 模型來表述開發(fā)流程。V 模型對系統(tǒng)視圖和部件視圖做了區(qū)分，同時融入了質(zhì)量措施，它兼顧了汽車電子系統(tǒng)開發(fā)的各類要求，因此被廣泛應(yīng)用。

V 模型因開發(fā)流程符合“V”字形而得名。事實上，在項目管理、系統(tǒng)、軟件開發(fā)之間的接口都可以用 V 模型來表示。圖4 展示了這一流程的全貌。

圖4 電子系統(tǒng)和軟件開發(fā)核心流程概述

V 模型的核心流程包含如下步驟：

1、分析用戶需求并確定邏輯系統(tǒng)架構(gòu)

該步驟的目標是基于用戶需求制定邏輯系統(tǒng)架構(gòu)，包括整車或子系統(tǒng)的功能網(wǎng)絡(luò)、功能接口和功能間通信。在這一階段，開發(fā)者不需對技術(shù)如何實現(xiàn)做出任何決策。

2、分析邏輯系統(tǒng)架構(gòu)并確定技術(shù)系統(tǒng)架構(gòu)

邏輯系統(tǒng)架構(gòu)是制定具體技術(shù)系統(tǒng)架構(gòu)規(guī)格說明的基礎(chǔ)。這種基于統(tǒng)一的邏輯系統(tǒng)架構(gòu)分析備選技術(shù)實施方案的方法在相關(guān)學科領(lǐng)域中十分常見。技術(shù)系統(tǒng)架構(gòu)定義了哪些功能或子功能需要由軟件實現(xiàn)，由此形成軟件需求。

3、分析軟件需求并確定軟件架構(gòu)

在該階段，工程師會對上一步分解出的軟件需求進行分析，并形成軟件架構(gòu)規(guī)格說明。其中定義了軟件系統(tǒng)的邊界和接口、所包含的軟件組件、層級和運行狀態(tài)。

4、確定軟件組件

在該階段，工程師將確定軟件組件的規(guī)格說明。這一過程通常建立在理想化假設(shè)基礎(chǔ)上，不會確定軟件實施中的具體細節(jié)（例如是否采用整數(shù)型運算等）。

5、軟件組件的設(shè)計、實施和測試

上一步中的理想化假設(shè)將在這里細化，軟件詳細開發(fā)中的所有細節(jié)都需在此時確定，從而指導完成軟件組件的開發(fā)和測試。

6、軟件組件的集成和集成測試

在所有軟件組件并行完成開發(fā)和測試后，將集成為完整軟件系統(tǒng)，并進行集成測試。

7、系統(tǒng)組件的集成和集成測試

通過上述測試的軟件系統(tǒng)將嵌入控制器硬件，保障控制器正常運行。接著將控制器與其他部件集成為完整的電子系統(tǒng)，包括設(shè)定值發(fā)生器、傳感器和執(zhí)行器等，并開展系統(tǒng)集成測試評估系統(tǒng)和被控對象之間的相互作用。

8、標定

為了縮短開發(fā)時間，工程團隊經(jīng)常需要同時處理多個開發(fā)任務(wù)，這一現(xiàn)象也被稱為“同步工程”。對于軟件功能開發(fā)，同步工程意味著在一條線上將串行地開展對軟件功能的分析、規(guī)格說明、設(shè)計、實施、集成、測試和校驗，而在另一條線上，我們還要同步地對另一個軟件功能完成上述串行過程。另外，不同的開發(fā)環(huán)境必須能夠相互協(xié)調(diào)，即模擬環(huán)境、實驗室、測試臺架以及實車環(huán)境上的開發(fā)步驟必須盡可能保持一致并彼此同步，如圖 7 所示。

End

分享不易，懇請點個【??】和【在看】