做開(kāi)發(fā)也是如此，除了需要高效的編碼能力，同樣也離不開(kāi)編程思維的指導(dǎo)。作為剛剛進(jìn)入汽車(chē)電子行業(yè)的開(kāi)發(fā)小白，本篇博文將總結(jié)最近學(xué)習(xí)到的汽車(chē)軟件行業(yè)開(kāi)發(fā)思維：V模型。

1、V模型概述

汽車(chē)軟件開(kāi)發(fā)過(guò)程中的V模型對(duì)行業(yè)內(nèi)開(kāi)發(fā)者早已是司空見(jiàn)慣的模型，是由瀑布模型演變而來(lái)的，也是目前汽車(chē)行業(yè)運(yùn)用最廣的軟件開(kāi)發(fā)模型。由于該模型的構(gòu)圖形似字母V，所以俗稱V模型。V模型核心思想是通過(guò)A-SPICE流程（汽車(chē)產(chǎn)業(yè)的軟件流程改進(jìn)和能力測(cè)定標(biāo)準(zhǔn)）來(lái)支持和管理整個(gè)開(kāi)發(fā)流程，從需求到源代碼的每個(gè)過(guò)程都有相應(yīng)的測(cè)試。

V模型大體可劃分為幾個(gè)不同的階段步驟即：功能需求、功能開(kāi)發(fā)、軟件開(kāi)發(fā)、軟件集成測(cè)試、功能集成測(cè)試、整車(chē)集成測(cè)試（系統(tǒng)合格性測(cè)試），如下圖所示，左邊為需求分析和設(shè)計(jì)開(kāi)發(fā)的過(guò)程，右邊則為針對(duì)左邊的測(cè)試驗(yàn)證，左邊的每個(gè)過(guò)程是與右邊的過(guò)程正好相對(duì)應(yīng)。

從系統(tǒng)需求到軟件需求，再到軟件的釋放，需要工具對(duì)其進(jìn)行管理，以達(dá)到可追溯，可記錄的目的，目前市場(chǎng)主流的工具含有 Door、ClearCase、GIT、SDOM 等，也有公司自己研發(fā)的一些流程工具，當(dāng)然這些工具的運(yùn)作方式都遵循V流程的需求、研發(fā)和測(cè)試要求。

2、V模型實(shí)施

2.1、系統(tǒng)需求分析

系統(tǒng)需求需要系統(tǒng)工程師完成。

基于項(xiàng)目的整體需求，以及軟硬件整體定義，對(duì)系統(tǒng)邏輯架構(gòu)進(jìn)行整體定義，這部分工作包括：硬件功能定義，控制器與其他控制器通信定義，軟件簡(jiǎn)要功能定義。這個(gè)過(guò)程并不會(huì)對(duì)具體的技術(shù)實(shí)現(xiàn)做出定義。

2.2、軟件需求分析

軟件需求需要系統(tǒng)工程師完成。

系統(tǒng)工程師根據(jù)系統(tǒng)相關(guān)方需求說(shuō)明書(shū)、軟硬件接口文件、變更通知書(shū)等輸入，梳理定義軟件研發(fā)需求說(shuō)明書(shū)，包括操作系統(tǒng)需求、電源管理策略、傳感器讀取，執(zhí)行器控制、信號(hào)特性需求、存儲(chǔ)服務(wù)、通信服務(wù)，網(wǎng)絡(luò)管理、故障診斷、標(biāo)定、程序升級(jí)等功能需求和非功能需求。

根據(jù)項(xiàng)目規(guī)劃，制定軟件開(kāi)發(fā)計(jì)劃。

軟件需求分析建立需求追蹤矩陣，將軟件需求映射到系統(tǒng)需求，確保軟件要實(shí)現(xiàn)的系統(tǒng)需求全部覆蓋。

成功實(shí)施這個(gè)過(guò)程的結(jié)果如下：

定義系統(tǒng)中分配給軟件要素的軟件需求及其接口；

將軟件需求進(jìn)行分類(lèi)，并分析了其正確性和可驗(yàn)證性；

分析軟件需求對(duì)運(yùn)行環(huán)境的影響；

定義軟件需求實(shí)現(xiàn)的優(yōu)先級(jí)；

根據(jù)需要更新了軟件需求；

在系統(tǒng)需求與軟件需求之間、在系統(tǒng)架構(gòu)設(shè)計(jì)與軟件需求之間建立了一致性和雙向可追溯性；

從成本、進(jìn)度和技術(shù)影響來(lái)評(píng)估軟件需求；

約定了軟件需求，并與所有受影響方溝通。

2.3、軟件架構(gòu)設(shè)計(jì)

軟件架構(gòu)需要架構(gòu)工程師完成。

為了建立清晰的、結(jié)構(gòu)化的軟件設(shè)計(jì)，應(yīng)該統(tǒng)一分配軟件需求，然后完成軟件架構(gòu)設(shè)計(jì)。根據(jù)系統(tǒng)相關(guān)需求、軟硬件接口表、軟件需求確定軟件架構(gòu)。將每條軟件需求合理分配到軟件模塊中，定義每個(gè)軟件模塊的輸入輸出接口、動(dòng)態(tài)行為、資源消耗目標(biāo)等，評(píng)估多種軟件架構(gòu)的優(yōu)缺點(diǎn)等。

架構(gòu)工程師需要使用EA等架構(gòu)軟件畫(huà)出整個(gè)控制器軟件所有模塊的輸入輸出接口、以及內(nèi)部動(dòng)態(tài)行為。

如果項(xiàng)目基于AUTOSAR開(kāi)發(fā)，需要架構(gòu)工程師配置應(yīng)用層的所有組件，并輸出每個(gè)組件的ARXML描述文件。

一般來(lái)說(shuō)，還需要架構(gòu)工程師輸出架構(gòu)文檔。

成功實(shí)施這個(gè)過(guò)程的結(jié)果如下：

定義了識(shí)別軟件要素的軟件架構(gòu)設(shè)計(jì)；

將軟件需求分配給軟件的要素；

定義每個(gè)軟件要素的接口；

定義軟件要素的動(dòng)態(tài)行為和資源消耗目標(biāo)；

建立軟件需求與軟件架構(gòu)設(shè)計(jì)之間的一致性和雙向可追溯性；

約定軟件架構(gòu)設(shè)計(jì)，并與所有受影響方溝通。

2.4、軟件單元設(shè)計(jì)和軟件實(shí)現(xiàn)

軟件單元設(shè)計(jì)需要軟件開(kāi)發(fā)工程師完成。

在此階段，需要對(duì)每個(gè)組件內(nèi)部的算法邏輯進(jìn)行詳細(xì)的內(nèi)部設(shè)計(jì)。組件功能的詳細(xì)設(shè)計(jì)需要與軟件需求建立有效的對(duì)應(yīng)關(guān)系。

如果是算法邏輯編碼，建議使用Matlab進(jìn)行模型開(kāi)發(fā)，如果是接近底層的復(fù)雜驅(qū)動(dòng)，一般是使用手寫(xiě)代碼。

如果項(xiàng)目使用AUTOSAR架構(gòu)，使用模型開(kāi)發(fā)時(shí)需要導(dǎo)入arxml生成模型框架進(jìn)行開(kāi)發(fā)，使用手寫(xiě)代碼進(jìn)行開(kāi)發(fā)時(shí)需要使用AUTOSAR工具生成的組件代碼框架進(jìn)行開(kāi)發(fā)。

需要將代碼經(jīng)過(guò)多次代碼審查和優(yōu)化之后，將最終版本上傳至代碼庫(kù)，以實(shí)現(xiàn)最佳的可靠性和性能。

成功實(shí)施這個(gè)過(guò)程的結(jié)果如下：

開(kāi)發(fā)描述軟件單元的詳細(xì)設(shè)計(jì)；

定義各軟件單元的接口；

定義軟件單元的動(dòng)態(tài)行為；

建立軟件需求與軟件單元之間的一致性和雙向可追溯性；建立軟件架構(gòu)設(shè)計(jì)與軟件詳細(xì)設(shè)計(jì)之間的一致性和雙向可追溯性；建立軟件詳細(xì)設(shè)計(jì)與軟件單元之間一致性和雙向可追溯性；

約定軟件詳細(xì)設(shè)計(jì)及該設(shè)計(jì)與軟件架構(gòu)設(shè)計(jì)的關(guān)系，并和所有受影響方溝通；

生成軟件詳細(xì)設(shè)計(jì)所定義的軟件單元。

2.5、軟件單元測(cè)試

組件單元測(cè)試一般需要軟件開(kāi)發(fā)工程師完成，也可以讓測(cè)試工程師完成。

當(dāng)進(jìn)行單元測(cè)試通過(guò)后，將會(huì)將軟件編譯成ECU可執(zhí)行的文件，比如Hex格式的文件，將其刷寫(xiě)到ECU進(jìn)行集成測(cè)試（或稱HIL測(cè)試），如果只是測(cè)試底層軟件，那么一般只需要額外的硬件負(fù)載箱支持就行，比如用負(fù)載箱來(lái)模擬一些傳感器信號(hào)輸入，或制造一些執(zhí)行器的短路和開(kāi)路故障；如果測(cè)試包括應(yīng)用層軟件，那么就還需要物理模型支持才行，比如電機(jī)控制就需要電機(jī)的物理模型，變速箱控制可能就需要整個(gè)動(dòng)力傳動(dòng)系統(tǒng)的模型才行。

單元測(cè)試與軟件單元設(shè)計(jì)對(duì)應(yīng)。

單元測(cè)試是根據(jù)軟件單元設(shè)計(jì)，進(jìn)行代碼級(jí)別上進(jìn)行的測(cè)試。

單元測(cè)試一般可以通過(guò)Matlab和Tessy等工具進(jìn)行。

成功實(shí)施這個(gè)過(guò)程的結(jié)果如下：

制訂包括回歸策略在內(nèi)的軟件單元驗(yàn)證策略，以驗(yàn)證軟件單元；

根據(jù)軟件單元驗(yàn)證策略，制訂軟件單元驗(yàn)證準(zhǔn)則，以適于提供軟件單元符合軟件詳細(xì)設(shè)計(jì)及非功能性軟件需求的證據(jù)；

根據(jù)軟件單元驗(yàn)證策略及軟件單元驗(yàn)證準(zhǔn)則，驗(yàn)證軟件單元并記錄了結(jié)果；

建立軟件單元、驗(yàn)證準(zhǔn)則及驗(yàn)證結(jié)果之間的雙向可追溯性和一致性；

總結(jié)單元驗(yàn)證結(jié)果，并與所有受影響方溝通。

2.6、軟件集成測(cè)試

集成測(cè)試需要測(cè)試工程師完成。

集成測(cè)試與軟件需求對(duì)應(yīng)。

集成測(cè)試將各個(gè)組成部分整合入一個(gè)軟件系統(tǒng)中之后，最后進(jìn)行軟件的集成測(cè)試。根據(jù)定義的需求，測(cè)試相應(yīng)的功能是否滿足軟件需求。

成功實(shí)施本過(guò)程的結(jié)果如下：

制訂與項(xiàng)目計(jì)劃、發(fā)布計(jì)劃和軟件架構(gòu)設(shè)計(jì)相一致的軟件集成策略，以集成軟件項(xiàng)；

制訂包括軟件回歸測(cè)試策略在內(nèi)的軟件集成測(cè)試策略，以測(cè)試軟件單元之間和軟件項(xiàng)之間的交互；

根據(jù)軟件集成測(cè)試策略，開(kāi)發(fā)了軟件集成測(cè)試規(guī)范，以適于提供集成的軟件項(xiàng)符合軟件架構(gòu)設(shè)計(jì)（包括軟件單元之間和軟件項(xiàng)之間的接口）的證據(jù)；

根據(jù)集成策略集成了軟件單元和軟件項(xiàng)直至完整的集成軟件；

根據(jù)軟件集成測(cè)試策略和發(fā)布計(jì)劃，選擇了軟件集成測(cè)試規(guī)范中的測(cè)試用例；

使用選定的測(cè)試用例測(cè)試了集成的軟件項(xiàng)，并記錄了測(cè)試結(jié)果；

建立軟件架構(gòu)設(shè)計(jì)要素與軟件集成測(cè)試規(guī)范中的測(cè)試用例之間的一致性和雙向可追溯性，并建立了測(cè)試用例與測(cè)試結(jié)果之間的一致性和雙向可追溯性；

總結(jié)軟件集成測(cè)試結(jié)果，并與所有受影響方溝通。

2.7、軟件系統(tǒng)測(cè)試

系統(tǒng)測(cè)試需要測(cè)試工程師完成。

系統(tǒng)測(cè)試與系統(tǒng)需求對(duì)應(yīng)。

因?yàn)檐浖o各個(gè)ECU提供了相應(yīng)的功能，因此在集成測(cè)試中，需要將軟件燒錄至硬件中。然后ECU要與其他電子系統(tǒng)組件集成起來(lái)，比如傳感器和執(zhí)行器。在接下來(lái)的系統(tǒng)綜合測(cè)試中，對(duì)所有系統(tǒng)設(shè)備的交互響應(yīng)進(jìn)行評(píng)估。

成功實(shí)施本過(guò)程的結(jié)果如下：

制訂與項(xiàng)目計(jì)劃和發(fā)布計(jì)劃相一致的包括回歸測(cè)試策略在內(nèi)的軟件合格性測(cè)試策略，以測(cè)試集成軟件；

根據(jù)軟件合格性測(cè)試策略，開(kāi)發(fā)集成軟件的軟件合格性測(cè)試規(guī)范，以適于提供符合軟件需求的證據(jù)；

根據(jù)軟件合格性測(cè)試策略和發(fā)布計(jì)劃，選擇了軟件合格性測(cè)試規(guī)范中的測(cè)試用例；

使用選定的測(cè)試用例測(cè)試了集成軟件，并記錄軟件合格性測(cè)試結(jié)果；

建立軟件需求與軟件合格性測(cè)試規(guī)范中的測(cè)試用例之間的一致性和雙向可追溯性，建立測(cè)試用例與測(cè)試結(jié)果之間的一致性和雙向的可追溯性；

總結(jié)軟件合格性測(cè)試結(jié)果，并與所有受影響方溝通。

3、V模型的追溯性和一致性要求

汽車(chē)軟件開(kāi)發(fā)的過(guò)程中有嚴(yán)格的追溯性和一致性要求，每個(gè)階段的過(guò)程要求、使用的工具方法和人員要求，前一階段的輸出交付物作為下一階段輸入，在每個(gè)階段完成后對(duì)交付物進(jìn)行驗(yàn)證，在軟件集成后在最后階段進(jìn)行確認(rèn)與軟件需求的一致性。概覽如下圖所示：

4、V模型面臨的挑戰(zhàn)

特斯拉人工智能總監(jiān)Andrej Karparthy在他的一篇技術(shù)博客中提出構(gòu)建軟件2.0技術(shù)棧的觀點(diǎn)，代碼正在從軟件 1.0（由人類(lèi)編寫(xiě)的代碼）過(guò)渡到軟件 2.0（由優(yōu)化編寫(xiě)的代碼，以神經(jīng)網(wǎng)絡(luò)訓(xùn)練的形式編寫(xiě)）。

軟件1.0 是我們熟悉的V模型，它是用 Python、C++、C等語(yǔ)言書(shū)寫(xiě)的。它包括程序員對(duì)計(jì)算機(jī)的明確說(shuō)明，通過(guò)編寫(xiě)每行代碼，程序員會(huì)用一些可取的行為識(shí)別程序空間中的特定點(diǎn)。

軟件1.0的工程方法遵循以下4個(gè)步驟：

確定要解決的問(wèn)題，即需求；

把需求進(jìn)行分解；

為每個(gè)分解的需求設(shè)計(jì)軟件；

逐級(jí)測(cè)試，集成并部署軟件。

軟件2.0時(shí)代正在逐漸到來(lái)，目前AI算法大量應(yīng)用于自然語(yǔ)言識(shí)別、行為分析、決策協(xié)助、身份識(shí)別等不涉及公眾安全的領(lǐng)域，也在自動(dòng)駕駛、醫(yī)療診斷等安全領(lǐng)域也在逐步應(yīng)用。對(duì)于安全關(guān)鍵系統(tǒng)，系統(tǒng)工程方法學(xué)是否還適合軟件2.0時(shí)代，功能安全標(biāo)準(zhǔn)如IEC61508、ISO26262、EN50128不同行業(yè)安全軟件開(kāi)發(fā)所遵循的標(biāo)準(zhǔn)，是否還能指導(dǎo)軟件2.0的開(kāi)發(fā)實(shí)踐，下面從開(kāi)發(fā)過(guò)程、軟件需求、開(kāi)發(fā)工具三個(gè)方面談?wù)勏敕ā?/p>

4.1、軟件2.0開(kāi)發(fā)過(guò)程

軟件1.0的開(kāi)發(fā)生命周期模型按照系統(tǒng)工程V模型的方式開(kāi)發(fā)，從上到下是瀑布式的，規(guī)定每個(gè)階段的過(guò)程要求、使用的工具方法和人員要求，前一階段的輸出交付物作為下一階段輸入，在每個(gè)階段完成后對(duì)交付物進(jìn)行驗(yàn)證，在軟件集成后在最后階段進(jìn)行確認(rèn)與軟件需求的一致性。在實(shí)際應(yīng)用中，設(shè)計(jì)實(shí)現(xiàn)階段和測(cè)試階段，會(huì)規(guī)劃小版本之間的迭代，從整體過(guò)程來(lái)看還是V模型。

在軟件2.0中，軟件的行為需求很大程度上取決于所使用的數(shù)據(jù)集（datasets），數(shù)據(jù)集不同于傳統(tǒng)意義上的數(shù)據(jù)，以往的數(shù)據(jù)如傳感器數(shù)據(jù)、系統(tǒng)的參數(shù)（如配置參數(shù)、校準(zhǔn)數(shù)據(jù)等）或系統(tǒng)使用的數(shù)據(jù)庫(kù)（如導(dǎo)航數(shù)據(jù)庫(kù)、障礙物數(shù)據(jù)庫(kù)等），這些數(shù)據(jù)可以一定程度上確定系統(tǒng)的行為，但它們并不描述這種行為的邏輯。而機(jī)器學(xué)習(xí)使用的數(shù)據(jù)集不僅用來(lái)提取信息，而且用來(lái)建立模型，用來(lái)處理其他數(shù)據(jù)并確定一個(gè)系統(tǒng)的行為，確定安全關(guān)鍵系統(tǒng)的需求，等同于軟件需求。當(dāng)軟件需求階段無(wú)法獲得完整的訓(xùn)練數(shù)據(jù)集，從V模型來(lái)說(shuō)，后面的架構(gòu)、設(shè)計(jì)實(shí)現(xiàn)階段也無(wú)法開(kāi)始。

軟件2.0的開(kāi)發(fā)模型始于數(shù)據(jù)，可以劃分為數(shù)據(jù)管理、模型訓(xùn)練、模型驗(yàn)證、模型部署，這四個(gè)階段不斷往復(fù)迭代，不是一次性完成的。

數(shù)據(jù)管理：先建立所需數(shù)據(jù)集的要求，通過(guò)對(duì)數(shù)據(jù)的分析確定數(shù)據(jù)收集、增強(qiáng)和預(yù)處理的需求，收集什么數(shù)據(jù)，如何收集數(shù)據(jù)，如何解決樣本數(shù)不足，收集成本過(guò)高的問(wèn)題，如何對(duì)收集的數(shù)據(jù)清洗預(yù)處理。

模型訓(xùn)練：選擇所使用的模型，構(gòu)建損失函數(shù)作為訓(xùn)練誤差的衡量標(biāo)準(zhǔn)，訓(xùn)練的目的是產(chǎn)生一個(gè)最小化該誤差的模型。需要制定一個(gè)合適的數(shù)據(jù)拆分策略，用于訓(xùn)練模型、驗(yàn)證模型、測(cè)試模型的比例。

模型驗(yàn)證：針對(duì)數(shù)據(jù)管理階段產(chǎn)生的獨(dú)立于訓(xùn)練數(shù)據(jù)集的驗(yàn)證數(shù)據(jù)集，通過(guò)測(cè)試評(píng)估訓(xùn)練模型的性能。

模型部署：使用驗(yàn)證過(guò)的模型的系統(tǒng)將被集成，將經(jīng)過(guò)驗(yàn)證的ML模型與使用傳統(tǒng)軟件工程方法開(kāi)發(fā)和驗(yàn)證的系統(tǒng)組件進(jìn)行整合，對(duì)其運(yùn)行進(jìn)行監(jiān)控，并通過(guò)在線維護(hù)或在線學(xué)習(xí)進(jìn)行更新。

4.2、軟件2.0新的軟件需求：數(shù)據(jù)集

既然軟件2.0的系統(tǒng)行為主要由數(shù)據(jù)集決定，系統(tǒng)是否符合其預(yù)期功能，很大程度上取決于數(shù)據(jù)集的質(zhì)量。要證明數(shù)據(jù)集對(duì)于軟件的預(yù)期功能在系統(tǒng)的操作環(huán)境下是足夠的，對(duì)于認(rèn)證來(lái)說(shuō)是非常大的挑戰(zhàn)。與軟件1.0的需求對(duì)比，有以下不同：

確定軟件需求不是在需求階段，而是在軟件開(kāi)發(fā)階段，對(duì)軟件設(shè)計(jì)實(shí)現(xiàn)的輸入將不是軟件的功能需求，而是訓(xùn)練過(guò)程的輸出。如一個(gè)神經(jīng)網(wǎng)絡(luò)架構(gòu)、權(quán)重和偏差。 ?

需求和設(shè)計(jì)實(shí)現(xiàn)不具備可追溯性，神經(jīng)網(wǎng)絡(luò)結(jié)構(gòu)和權(quán)重不能追溯到開(kāi)發(fā)它們的軟件需求，追溯不到描述預(yù)期屬性的需求文件，也追溯不到訓(xùn)練數(shù)據(jù)集。 ?

安全軟件的驗(yàn)證方法不再適合數(shù)據(jù)集及訓(xùn)練模型，人類(lèi)已無(wú)法理解，無(wú)法實(shí)現(xiàn)人工審查和分析，傳統(tǒng)軟件基于需求的測(cè)試方法也無(wú)法進(jìn)行。例如，功能安全軟件的測(cè)試用例采用的等價(jià)類(lèi)生成分析，由于常規(guī)規(guī)模的神經(jīng)網(wǎng)絡(luò)的高度復(fù)雜和非線性特征，不適用于模型的實(shí)施。要確定神經(jīng)網(wǎng)絡(luò)模型算法的等價(jià)類(lèi)是不可能的。 ?

ISO26262 軟件單元測(cè)試用例生成推薦方法

數(shù)據(jù)集的屬性與軟件需求保證屬性存在差異，傳統(tǒng)軟件需求的完整性，清晰性，精確性，無(wú)歧義性，可驗(yàn)證性，可測(cè)試性，可維護(hù)性，可擴(kuò)展性 這些屬性的含義需要重新定義。

網(wǎng)絡(luò)權(quán)重作為參數(shù)數(shù)據(jù)項(xiàng)，在本質(zhì)上與傳統(tǒng)的數(shù)據(jù)配置文件不同，依據(jù)已有配置參數(shù)修改流程而套用網(wǎng)絡(luò)權(quán)重，存在很大偏差。

?4.3、軟件2.0開(kāi)發(fā)工具鏈 ?

傳統(tǒng)軟件開(kāi)發(fā)中已建立完善的工具鏈用于支持開(kāi)發(fā)，集成開(kāi)發(fā)環(huán)境，編輯器，編譯器，調(diào)試器，git集成，單元測(cè)試，集成測(cè)試工具，在功能安全軟件工具的鑒定中，根據(jù)工具對(duì)軟件安全性影響的不同，劃分為不同的級(jí)別，例如ISO26262-8對(duì)軟件工具的TCL1、TCL2和TCL3分級(jí)。在軟件2.0中，也可以按照類(lèi)似的分類(lèi)對(duì)工具進(jìn)行分級(jí)，但目前還沒(méi)有完善的開(kāi)發(fā)工具鏈和如何對(duì)工具鑒定的標(biāo)準(zhǔn)。 ?

從軟件領(lǐng)域的發(fā)展來(lái)看，軟件2.0所占的規(guī)模越來(lái)越大，已出現(xiàn)機(jī)器自動(dòng)生成的代碼，當(dāng)這類(lèi)軟件應(yīng)用于安全關(guān)鍵系統(tǒng)時(shí)，有可能徹底改變既有軟件的開(kāi)發(fā)模式，需要識(shí)別與現(xiàn)有標(biāo)準(zhǔn)的差異，安全關(guān)鍵領(lǐng)域如航空航天、鐵路、汽車(chē)標(biāo)準(zhǔn)，采用協(xié)作的方式在不同領(lǐng)域之間獲取經(jīng)驗(yàn)；對(duì)應(yīng)用軟件2.0產(chǎn)品的鑒定也不再是一次性的，與軟件2.0生命周期類(lèi)似，是一個(gè)迭代的過(guò)程，評(píng)估系統(tǒng)運(yùn)行性能表現(xiàn)是重要環(huán)節(jié)；軟件的變更會(huì)更加頻繁，如智能網(wǎng)聯(lián)汽車(chē)的OTA功能，對(duì)軟件變更的評(píng)估，應(yīng)考慮其服務(wù)期限、運(yùn)行設(shè)計(jì)域差異、產(chǎn)品異常行為記錄報(bào)告等所有既有數(shù)據(jù)記錄。

審核編輯：劉清