李兵，趙磊，林方圓

（安徽江淮汽車集團(tuán)股份有限公司，安徽 合肥 230601）

1 前言

1.1 車載信息娛樂系統(tǒng)發(fā)展歷程

1.1.1 功能進(jìn)化

早期的車輛只具備基本的駕駛功能，沒有娛樂功能，隨著用戶需求的提高，車內(nèi)信息娛樂功能不斷升級(jí)，從FM/AM收音機(jī)到CD 機(jī)，再到大屏多媒體終端。近年來進(jìn)一步新增出在線音樂、網(wǎng)絡(luò)電臺(tái)、聽書、天氣、新聞等服務(wù)。

1.1.2 技術(shù)發(fā)展

從未止步的功能進(jìn)化需要通過技術(shù)發(fā)展來實(shí)現(xiàn)，車載信息娛樂系統(tǒng)終端硬件上從單片機(jī)應(yīng)用發(fā)展到單核、雙核、四核的SOC 應(yīng)用，軟件上從基本的單片機(jī)嵌入式系統(tǒng)應(yīng)用發(fā)展到WinCE、QNX、Linux、Android 等高級(jí)操作系統(tǒng)應(yīng)用，軟件代碼量指數(shù)級(jí)增長，開發(fā)難度也顯著提升。

1.2 軟件開發(fā)挑戰(zhàn)

1.2.1 復(fù)雜度增長

功能的不斷增加必然帶來軟件復(fù)雜度成倍提高，代碼量增多，以包含收音機(jī)、藍(lán)牙電話、藍(lán)牙音樂、USB 音視頻、倒車影像、車輛設(shè)置等功能的車載信息娛樂系統(tǒng)終端開發(fā)為例，代碼量達(dá)到73 萬行，軟件開發(fā)投入達(dá)到16 人*24 個(gè)月，軟件開發(fā)費(fèi)用至少900 萬。

1.2.2 交付質(zhì)量問題

車載信息娛樂系統(tǒng)軟件復(fù)雜度增加后，在試制試驗(yàn)階段會(huì)暴露出大量軟件問題，小批量生產(chǎn)階段后仍會(huì)存在體驗(yàn)類問題，造成用戶抱怨。主要原因?yàn)檐囕d應(yīng)用環(huán)境更為復(fù)雜、軟件代碼邏輯不合理、缺少系統(tǒng)性的過程管控和測試驗(yàn)證。

1.2.3 交付進(jìn)度問題

新車型的開發(fā)迭代周期越來越短，目前在8 個(gè)月左右，每次車型迭代車載信息娛樂系統(tǒng)必定升級(jí)，軟件功能又是主要升級(jí)的部分。從前期項(xiàng)目開發(fā)來看，80%項(xiàng)目存在軟件交付延期的情況。

綜上所述，軟件開發(fā)工作已成為車載信息娛樂系統(tǒng)開發(fā)過程中的重點(diǎn)和難點(diǎn)，如何有效管控軟件開發(fā)過程是項(xiàng)目管控上亟需解決的問題，基于項(xiàng)目開發(fā)實(shí)踐，本文就軟件開發(fā)流程的研究過程與應(yīng)用情況進(jìn)行說明。

2 軟件開發(fā)流程調(diào)研

2.1 V 開發(fā)流程簡介

軟件開發(fā)V 字模型是一種軟件生存期模型，由Paul Rook在1980 年率先提出的，在1990 年出現(xiàn)在英國國家計(jì)算中心的出版物中，旨在提高軟件開發(fā)的效率和有效性。

V 模型強(qiáng)調(diào)軟件開發(fā)的協(xié)作和速將軟件實(shí)現(xiàn)和驗(yàn)證有機(jī)地結(jié)合起來，V 形左邊是設(shè)計(jì)和分析，是軟件設(shè)計(jì)實(shí)現(xiàn)的過程，同時(shí)伴隨著質(zhì)量保證活動(dòng)--審核的過程，也就是靜態(tài)的測試過程。V 形右邊是對(duì)左邊結(jié)果的驗(yàn)證，是動(dòng)態(tài)測試的過程，即對(duì)設(shè)計(jì)和分析的結(jié)果進(jìn)行測試，以確認(rèn)是否滿足用戶的需求。

2.2 Automotive SPICE 簡介

Automotive SPICE 是由歐洲的主要汽車制造商共同制定的“面向汽車行業(yè)的流程評(píng)估模型”，目的是改善搭載于汽車上的電子控制單元（ECU）/車載電腦的質(zhì)量。

Automotive SPICE 主要包括7 大流程群31 種有關(guān)軟件開發(fā)的流程，其中工程流程群里包含10 項(xiàng)，定義了軟件開發(fā)流程，具體內(nèi)容包括ENG.1 需求導(dǎo)出、ENG.2 系統(tǒng)需求分析、ENG.3 系統(tǒng)架構(gòu)設(shè)計(jì)、ENG.4 軟件需求分析、ENG.5 軟件設(shè)計(jì)、ENG.6 軟件建構(gòu)、ENG.7 軟件集成測試、ENG.8 軟件測試、ENG.9 系統(tǒng)集成測試、ENG.10 系統(tǒng)測試。

2016 年TS16949 換版為IATF16949，IATF 16949：2016中對(duì)嵌入式軟件提出了明確要求，提供嵌入式軟件的供應(yīng)商必須基于Automotive SPICE（或同等標(biāo)準(zhǔn)）進(jìn)行軟件開發(fā)以保證軟件質(zhì)量，并提供基于Automotive SPICE（或同等標(biāo)準(zhǔn)）的評(píng)估報(bào)告。

3 軟件開發(fā)流程研究

車載信息娛樂系統(tǒng)開發(fā)是整車開發(fā)的重要組成部分，產(chǎn)品開發(fā)上需要與整車開發(fā)同步，軟件開發(fā)流程的制定要與整車開發(fā)流程相結(jié)合，這樣軟件開發(fā)流程能夠符合整車開發(fā)流程要求，與整車項(xiàng)目相關(guān)方實(shí)現(xiàn)協(xié)同。

3.1 NAM 開發(fā)流程

整車開發(fā)方面制定了NAM（Now And Me）開發(fā)流程，所有項(xiàng)目均按照該流程要求執(zhí)行，該流程將整車的開發(fā)過程劃分為7 個(gè)階段（產(chǎn)品規(guī)劃、產(chǎn)品策劃、造型開發(fā)、設(shè)計(jì)開發(fā)、設(shè)計(jì)驗(yàn)證、量產(chǎn)準(zhǔn)備、量產(chǎn)評(píng)價(jià)）、13 個(gè)節(jié)點(diǎn)門（G1—G13），詳細(xì)定義了每個(gè)階段的工作內(nèi)容和每個(gè)節(jié)點(diǎn)門的審核通過條件，只有完成階段工作并達(dá)成節(jié)點(diǎn)門指標(biāo)審核通過方可進(jìn)入下一階段，確保了開發(fā)過程的分階段可控。

3.2 軟件開發(fā)流程研究

3.2.1 結(jié)合NAM 流程確定版本節(jié)點(diǎn)

對(duì)標(biāo)NAM 流程的思路，針對(duì)如何約束車載信息娛樂系統(tǒng)軟件開發(fā)流程開展研究，將車載信息娛樂系統(tǒng)軟件開發(fā)過程劃分為4 個(gè)大版本，分別為V1.0、V2.0、V3.0、V4.0 版本，并分別對(duì)應(yīng)到整車NAM 流程的G6（技術(shù)文件下發(fā)）、G7（試制確認(rèn)）、G8（設(shè)計(jì)確認(rèn)）、G10（P2 下發(fā)）關(guān)鍵節(jié)點(diǎn)門上，確保軟件開發(fā)進(jìn)度與整車進(jìn)度同步。

3.2.2 軟件開發(fā)任務(wù)劃分

定義上述軟件開發(fā)關(guān)鍵版本節(jié)點(diǎn)和要求后，接下來明確每個(gè)階段需要完成的開發(fā)任務(wù)，車載信息娛樂系統(tǒng)軟件開發(fā)有其獨(dú)特性，部分功能必須與整車結(jié)合才能實(shí)現(xiàn)構(gòu)成完整的系統(tǒng)，也必須有整車環(huán)境下的測試，開發(fā)過程遵循V 開發(fā)模型、ASPICE 流程的同時(shí)需要與整車開發(fā)相結(jié)合。

圖1 軟件開發(fā)流程及任務(wù)

（1）V1.0 版本前除了解決軟件功能開發(fā)問題，還需進(jìn)行模型驗(yàn)證，及早發(fā)現(xiàn)顯示問題，對(duì)顯示屏布置進(jìn)行調(diào)整或UI 界面進(jìn)行優(yōu)化。

表1 V1.0 版本任務(wù)

（2）V2.0 版本需要達(dá)成全功能軟件開發(fā)，完成代碼測試、單元測試和集成測試，以及單機(jī)的性能測試。

表2 V2.0 版本任務(wù)

（3）V3.0 版本對(duì)V2.0 版本測試項(xiàng)目進(jìn)行1 輪或多輪回歸測試，重點(diǎn)進(jìn)行實(shí)車環(huán)境下的功能測試、性能標(biāo)定和測試，V3.0 版本需要同步完成OTS 認(rèn)可，驗(yàn)收發(fā)布后可用于生產(chǎn)線小批量生產(chǎn)，交付內(nèi)部用戶體驗(yàn)評(píng)測。

表3 V3.0 版本任務(wù)

（4）V4.0 版本主要針對(duì)V3.0 版本發(fā)布后生產(chǎn)線驗(yàn)證和用戶評(píng)測問題進(jìn)行改進(jìn)優(yōu)化，完成遺留問題點(diǎn)的閉環(huán)，V4.0版本可用于批量生產(chǎn)。

表4 V4.0 版本任務(wù)

針對(duì)以上每一項(xiàng)測試，都制定了測試方法和用例，使得驗(yàn)證過程標(biāo)準(zhǔn)統(tǒng)一，就具體測試方法和用例本文不再逐一展開闡述，同時(shí)，測試方法和用例在實(shí)際項(xiàng)目實(shí)踐中也在不斷完善和優(yōu)化。

3.2.3 軟件版本審核要求

針對(duì)每個(gè)軟件版本設(shè)定關(guān)鍵評(píng)價(jià)指標(biāo)，只有達(dá)成指標(biāo)才能評(píng)定通過該版本軟件的發(fā)布，具體定義如下：

表5 軟件版本評(píng)價(jià)指標(biāo)

問題嚴(yán)重度分類說明：

S 類問題：影響到行車安全；死機(jī)，需斷主機(jī)B+才可恢復(fù)；主要功能缺失；黑屏、白屏、花屏、嚴(yán)重閃屏、嚴(yán)重色差；觸摸屏或按鍵失效；

A 類問題：主要功能失效，影響視聽、交互操作，不影響行車安全；

B 類問題：部分功能偶發(fā)性錯(cuò)誤，不影響使用，重新上電后可恢復(fù)；

C 類問題：個(gè)別用戶體驗(yàn)類問題（存在主觀性）、HMI 細(xì)節(jié)問題。

4 軟件開發(fā)流程應(yīng)用情況

車載信息娛樂系統(tǒng)開發(fā)流程2015 年下半年完成制定并開始應(yīng)用，2016 年應(yīng)用過程中補(bǔ)充了測試項(xiàng)目、優(yōu)化了測試用例和標(biāo)準(zhǔn)，截至2019 年6 月總計(jì)完成96 個(gè)軟件版本的簽發(fā)或發(fā)布，項(xiàng)目管控上通過軟件開發(fā)版本矩陣表進(jìn)行管控，檢查是否按期完成軟件版本發(fā)布，及時(shí)發(fā)現(xiàn)風(fēng)險(xiǎn)予以對(duì)應(yīng)，通過軟件開發(fā)流程分階段驗(yàn)收管控有效加強(qiáng)了對(duì)軟件開發(fā)過程的管控。

5 結(jié)論

本論文對(duì)車載信息娛樂系統(tǒng)軟件開發(fā)流程的研究與制定過程、流程說明、應(yīng)用情況進(jìn)行了闡述，該流程的制定和應(yīng)用符合當(dāng)前軟件開發(fā)復(fù)雜度提高對(duì)開發(fā)流程的需求，在實(shí)際應(yīng)用中確實(shí)也發(fā)揮了應(yīng)有的作用，保障了車載信息娛樂系統(tǒng)項(xiàng)目的開發(fā)質(zhì)量和進(jìn)度，對(duì)其它系統(tǒng)的軟件開發(fā)管控具備參考意義。