摘要：在過去的二十年中，汽車軟件的需求和應(yīng)用急劇增長，隨之復(fù)雜性急劇上升。現(xiàn)有技術(shù)和框架不足以應(yīng)對這種復(fù)雜性，現(xiàn)在很明顯，汽車制造商（OEM）必須重新考慮他們生產(chǎn)車輛的方式以及車輛本身的生命周期。通過將重點(diǎn)放在軟件上，OEM可以在車輛整個(gè)生命周期中實(shí)現(xiàn)許多新的應(yīng)用用例，并打開一個(gè)充滿機(jī)遇的新世界。博世及其子公司ETAS在過去幾十年中一直處于汽車創(chuàng)新的前沿。

通過他們的專業(yè)知識和與汽車制造商的密切關(guān)系，他們正在親身經(jīng)驗(yàn)體驗(yàn)軟件復(fù)雜性的增加和開發(fā)概念的改變。本文介紹為了賦能新一代 “軟件定義汽車 “，OEM所必須采取的改變其當(dāng)前技術(shù)棧的步驟。

介紹

在過去的二十年中，軟件組件在塑造汽車行業(yè)方面發(fā)揮了主導(dǎo)作用。汽車制造商（OEM）正面臨著新一代的買家，他們希望擁有一輛可以滿足所有新愿望的個(gè)性化和互聯(lián)的汽車，軟件甚至正在成為OEM的決定性區(qū)別和銷售論據(jù)。根據(jù)波士頓咨詢集團(tuán)（Boston Consulting Group）的數(shù)據(jù)，目前汽車行業(yè)90%的創(chuàng)新來自軟件[1]。同樣，據(jù)麥肯錫[2]預(yù)計(jì)，汽車電子和軟件市場的增長速度將遠(yuǎn)遠(yuǎn)超過整個(gè)汽車市場。駕駛員輔助系統(tǒng)的基于傳感器的環(huán)境檢測和廣泛的信息娛樂產(chǎn)品只是客戶期望他們的車輛所具備的軟件定義功能中的兩個(gè)示例。

在未來，實(shí)現(xiàn)更高級別的自動(dòng)駕駛功能、提供即時(shí)錯(cuò)誤修復(fù)并持續(xù)提供新功能將成為新的規(guī)范。后者似乎很熟悉，因?yàn)?a target="_blank">智能手機(jī)市場經(jīng)歷了一場類似的革命[1]，現(xiàn)在已經(jīng)成為客戶數(shù)字生活的中心。車輛多樣性和固有管理復(fù)雜性的增加，要求新的軟件和硬件的開發(fā)方式。因此，在軟件和硬件開發(fā)解耦的情況下，需要從傳統(tǒng)的V模型向持續(xù)開發(fā)和集成的轉(zhuǎn)變。盡管汽車制造商需要進(jìn)行大量的初始投資來開發(fā)和建立新的電氣和電子（E/E）架構(gòu)及其軟件平臺，但預(yù)計(jì)他們每年將避免在測試、集成和維護(hù)多個(gè)領(lǐng)域獲得160億美元的節(jié)省[3]。

現(xiàn)有的方式將軟件引入車輛有明顯的主要局限性。OEM依賴分布式E/E架構(gòu)和整體的軟件架構(gòu)，由于開發(fā)新功能以及更新現(xiàn)有協(xié)議棧所需的復(fù)雜度和工作導(dǎo)致了測試、集成和維護(hù)成本很高[3]。由于缺乏速度和巨大的開發(fā)成本，汽車設(shè)備制造商無法快速進(jìn)行試驗(yàn)和創(chuàng)新。因此，這限制了他們滿足單個(gè)客戶需求的能力，從而限制最大限度地利用車輛的整個(gè)生命周期的價(jià)值。

很明顯，當(dāng)前的開發(fā)理念不再合適，行業(yè)需要轉(zhuǎn)向以軟件為中心的方法[3]。基于軟件的功能需要“可靠、快速反應(yīng)并在車輛使用壽命內(nèi)快速更新”[1]。通過重新思考汽車的生產(chǎn)方式，將以軟件為中心，汽車設(shè)備制造商可以提高其客戶忠誠度，并在其生命周期內(nèi)增加汽車的價(jià)值。例如，特斯拉Model S在購買七年后比其競爭對手更保值，這歸功于其始終最新的軟件協(xié)議棧和功能更新[1]。

本文旨在涵蓋技術(shù)解決方案，使原始設(shè)備制造商能夠成功地從“耗費(fèi)大量精力和成本的軟件創(chuàng)新和更新”轉(zhuǎn)向“自動(dòng)、連續(xù)、快速、輕松地將任何數(shù)量的軟件功能交付給任何期望的車輛”。

二

成功轉(zhuǎn)向軟件定義車輛（SDV）意味著什么？

為了釋放SDV的全部潛力，必須通過在云端和車輛中運(yùn)行的合適的工具和軟件解決方案來理解和掌握幾個(gè)挑戰(zhàn)。

2.1硬件和軟件解耦——SDV的基礎(chǔ)

在過去的幾十年中，汽車設(shè)備制造商主要從不同供應(yīng)商處采購電子控制單元（ECU），作為一個(gè)組合的硬件-軟件系統(tǒng)，以功能為中心，并承受較高的成本壓力。因此，系統(tǒng)級的集成工作隨著每一個(gè)新的子系統(tǒng)呈指數(shù)增長，計(jì)算資源在預(yù)生產(chǎn)定義的功能范圍內(nèi)得到優(yōu)化，開發(fā)工具鏈專門針對OEM、供應(yīng)商和功能特定需求進(jìn)行項(xiàng)目實(shí)施。因此，實(shí)現(xiàn)的功能代碼從一個(gè)車輛項(xiàng)目轉(zhuǎn)移到另一個(gè)幾乎是不可能的。

同時(shí)，汽車行業(yè)一直面臨著車輛軟件功能數(shù)量和交付頻率的增加[1,3]，涉及數(shù)量不斷增加的ECU。這種復(fù)雜性導(dǎo)致了集成工作的泛濫，成本飆升，項(xiàng)目持續(xù)時(shí)間更長。麥肯錫表示，過去十年，軟件復(fù)雜性增長了4倍，而開發(fā)生產(chǎn)力僅增長了1.0至1.5倍[4]。

因此，必須采取三項(xiàng)主要行動(dòng)：

減少ECU的數(shù)量，同時(shí)增加計(jì)算資源，以降低硬件復(fù)雜性并提高其性能。

協(xié)調(diào)OEM內(nèi)部的基礎(chǔ)軟件及其底層開發(fā)工具鏈，以實(shí)現(xiàn)跨車輛平臺的車輛功能兼容性。

引入開放接口和面向服務(wù)的體系結(jié)構(gòu)，以簡化OEM、其供應(yīng)商和開發(fā)人員之間的協(xié)作和集成。

因此，OEM目前引入了硬件和軟件生命周期的解耦，允許將通常分布在幾個(gè)區(qū)域ECU和車輛計(jì)算機(jī)內(nèi)的多個(gè)ECU上的功能捆綁在一起[2,5]。車輛中的這種新E/E）架構(gòu)簡化了功能部署，同時(shí)需要更高的計(jì)算資源和工具來支持管理依賴性和變量。

2.2選擇標(biāo)準(zhǔn)化中間件

集中式E/E架構(gòu)正在推動(dòng)平臺軟件方面的大規(guī)模技術(shù)變革，需要根據(jù)領(lǐng)域的不同而擴(kuò)展一系列功能。AUTOSAR Classic[6]為安全和硬實(shí)時(shí)ECU提供了全面的解決方案。該標(biāo)準(zhǔn)在汽車行業(yè)被廣泛接受和采用，涵蓋多個(gè)網(wǎng)絡(luò)的診斷和安全通信等服務(wù)，通常是發(fā)動(dòng)機(jī)控制器、變速器ECU等所必需的。

隨著車載計(jì)算機(jī)的引入，另一個(gè)標(biāo)準(zhǔn)與經(jīng)典一起被定義，這就是AUTOSAR自適應(yīng)標(biāo)準(zhǔn)[6]。盡管共享了大部分基本原則，但目標(biāo)卻截然不同，因?yàn)锳UTOSAR自適應(yīng)旨在為基于POSIX的ECU提供一組集群式服務(wù)，其微處理器能夠執(zhí)行車輛范圍的功能，以增強(qiáng)駕駛員體驗(yàn)。

最近，LINUX（獨(dú)立或與信息娛樂集成）上非安全通用計(jì)算環(huán)境的采用受到了越來越多的關(guān)注。在這個(gè)稱為車輛邊緣，像容器化這樣的云原生方法針對汽車用途進(jìn)行了優(yōu)化。這使得能夠進(jìn)一步簡化和加速車輛應(yīng)用程序的集成，同時(shí)通過隔離實(shí)現(xiàn)封裝和安全性。

當(dāng)涉及到支持汽車中最先進(jìn)的技術(shù)功能，轉(zhuǎn)向自動(dòng)駕駛時(shí)，汽車操作系統(tǒng)（AOS）為ADAS功能引入了一個(gè)完整的新開發(fā)模式，涵蓋了整個(gè)開發(fā)周期以及實(shí)現(xiàn)ADAS功能的中間件平臺軟件。領(lǐng)先的汽車原始設(shè)備制造商正利用其非常有效的方法采用此類技術(shù)。

2.3使用云開發(fā)工具鏈簡化和加快開發(fā)速度

在理想的世界中，開發(fā)人員有一個(gè)隨時(shí)可用的開發(fā)環(huán)境，支持他們檢查更改并從自動(dòng)化流水線系統(tǒng)收集反饋。經(jīng)過少量調(diào)整和迭代后，他們一直在開發(fā)的功能就準(zhǔn)備好發(fā)布了。如果他們是由分布式開發(fā)團(tuán)隊(duì)組成的更大組織的一部分，那么他們將連接到正確的代碼庫，所有開發(fā)人員將在一個(gè)共同的協(xié)作平臺中同步。最后，作為流水線系統(tǒng)管道的一部分，自動(dòng)生成認(rèn)證和其他發(fā)布手續(xù)所需的文檔。

然而，汽車行業(yè)的現(xiàn)實(shí)情況卻大不相同。開發(fā)人員將60%以上的時(shí)間用于維護(hù)開發(fā)環(huán)境、手動(dòng)執(zhí)行大量測試、處理文檔（包括其他手續(xù)）以及最終發(fā)布代碼。

汽車云開發(fā)工具鏈和協(xié)作平臺旨在通過結(jié)合汽車領(lǐng)域的專業(yè)知識以及云技術(shù)提供的可能性。通過使用標(biāo)準(zhǔn)化接口，現(xiàn)在可以集成第三方工具。這使開發(fā)人員能夠?qū)Ｗ⒂趧?chuàng)建新內(nèi)容，而不是維護(hù)現(xiàn)有工具。由于自動(dòng)化流水線系統(tǒng)，開發(fā)測試和反饋周期可以加快。云技術(shù)還為OEM內(nèi)部不同團(tuán)隊(duì)及其供應(yīng)商之間的協(xié)作平臺提供了基礎(chǔ)。

2.4快速輕松地開發(fā)車輛應(yīng)用程序

來自終端消費(fèi)者和高性能軟件驅(qū)動(dòng)的競爭對手的壓力越來越大，迫使原始設(shè)備制造商提高其軟件交付性能。這種性能可以通過幾個(gè)關(guān)鍵性能指標(biāo)（KPI）來衡量，如功能交付周期、部署頻率、恢復(fù)時(shí)間或更改失敗百分比。

通過選擇經(jīng)過驗(yàn)證的云原生模式并將其用于汽車，可以顯著減少軟件開發(fā)持續(xù)時(shí)間。例如，通過將容器隔離、開發(fā)人員為中心的工具鏈和車輛API相結(jié)合減少軟件流程負(fù)載。這種方法為從ECU上的ASIL環(huán)境（具有不同的安全等級）到車輛計(jì)算機(jī)上的質(zhì)量管理（QM）環(huán)境（沒有安全要求）的業(yè)務(wù)邏輯轉(zhuǎn)變打開了大門。

從車載軟件的角度來看，需要一個(gè)異構(gòu)的車輛邊緣QM環(huán)境，以便在車輛內(nèi)便捷開發(fā)、部署和運(yùn)行應(yīng)用程序。為了加快開發(fā)，開發(fā)者商不必履行任何與安全相關(guān)約束。相反，運(yùn)行環(huán)境與基礎(chǔ)E/E和安全架構(gòu)相結(jié)合，確保車輛始終處于安全狀態(tài)。

此外，這種方法在軟件人才招聘方面帶來了進(jìn)一步的好處，汽車行業(yè)在聘請足夠熟練的開發(fā)人員以C或C++等編程語言進(jìn)行經(jīng)典汽車軟件開發(fā)方面面臨越來越大的困難。通過上述現(xiàn)代軟件開發(fā)方法，OEM擁有的或第三方開發(fā)人員能夠使用他們選擇的現(xiàn)代編程語言開發(fā)基于容器的應(yīng)用程序，并專注于差異化的業(yè)務(wù)邏輯，而不是處理安全問題和汽車特定流程。

2.5虛擬測試軟件

原始設(shè)備制造商面臨的一個(gè)關(guān)鍵問題是軟件開發(fā)過程即將結(jié)束時(shí)的“大爆炸”集成，其中一些問題被發(fā)現(xiàn)，導(dǎo)致車輛生產(chǎn)延遲。

對對于車輛的開發(fā)，有不同的角色。每一個(gè)都有不同的測試關(guān)注點(diǎn)。功能開發(fā)人員對底層協(xié)議棧或操作系統(tǒng)不感興趣，但他們希望了解他們對功能KPI（針對ASIL）產(chǎn)生的影響。軟件集成商希望驗(yàn)證功能增量（快速反饋回路），而無需運(yùn)行在基于硬件的設(shè)置。安全工程師希望檢測軟件中的異常和弱點(diǎn)。測試工程師希望能夠盡早開始（前置）驗(yàn)證所有功能。

更重要的是，需要基于不同版本的軟件進(jìn)行回歸運(yùn)行測試以實(shí)現(xiàn)可比性，即執(zhí)行不同代碼版本的重復(fù)運(yùn)行，并檢查它們是否導(dǎo)致相同（確定性）結(jié)果輸出。一旦報(bào)告了現(xiàn)場錯(cuò)誤，就需要在實(shí)驗(yàn)室（電子取證）重現(xiàn)情況。

面臨的挑戰(zhàn)在于建立一個(gè)足夠模塊化的測試解決方案，以支持所有用戶，無論在哪個(gè)開發(fā)階段，在這種情況下，以下能力是效率的重要標(biāo)準(zhǔn)：

加快測試，例如，避免等待幾天來完成回歸測試

自動(dòng)化測試，例如，在后臺進(jìn)行實(shí)際測試時(shí)更改配置并獲得反饋。

SDV方法允許獨(dú)立于硬件的可用性來解決這些問題。上述用例和角色視角清楚地表明，虛擬測試解決方案需要

模塊化和標(biāo)準(zhǔn)化，

適用于自動(dòng)化（無頭，CI-CD-CT），

可以在云中進(jìn)行擴(kuò)展，以按需處理回歸峰值，從而優(yōu)化成本。

因此，OEM可以從旨在解決這些需求的解決方案中受益，該解決方案采用模塊化和標(biāo)準(zhǔn)化的云虛擬測試解決方案，以實(shí)現(xiàn)高效開發(fā)，并向第三方供應(yīng)商開放。

2.6在影子模式下采集現(xiàn)場數(shù)據(jù)

在不可能指定和驗(yàn)證所有駕駛或環(huán)境情況（例如，“開放環(huán)境”或“開放世界”問題）的所有系統(tǒng)中，良好的確認(rèn)和驗(yàn)證（V&V）策略會(huì)增加很高的價(jià)值。

影子模式是這種V&V策略的重要組成部分。新開發(fā)的數(shù)據(jù)驅(qū)動(dòng)功能或算法在真實(shí)條件下在目標(biāo)環(huán)境中執(zhí)行，以獲得“真實(shí)世界”輸入數(shù)據(jù)。影子功能不會(huì)主動(dòng)控制駕駛系統(tǒng)，而是以靜音模式運(yùn)行，并通過使用可配置的基于AI的過濾器和觸發(fā)條件從系統(tǒng)收集相關(guān)數(shù)據(jù)。功能、過濾器和條件通過OTA部署到一個(gè)系列車隊(duì)。

而收集的輸出數(shù)據(jù)則通過OTA傳送回云后端進(jìn)行分析和進(jìn)一步處理。

2.7大規(guī)模部署和管理軟件

軟件和硬件生命周期的為SDV建立一個(gè)連續(xù)的軟件開發(fā)和部署過程。車輛因此能夠不斷地適應(yīng)其當(dāng)前的需求。結(jié)合部署個(gè)性化車輛應(yīng)用的能力，現(xiàn)場硬件軟件組合的多樣性使每輛車都獨(dú)一無二。數(shù)字維修也是如此：預(yù)計(jì)每輛車每年會(huì)更新數(shù)百次大量電子部零件、應(yīng)用程序和服務(wù)。因此，SDV對靈活更新的需求將大幅增加。

傳統(tǒng)的OTA更新解決方案需要大量的手動(dòng)工作來創(chuàng)建更新包（內(nèi)在依賴關(guān)系管理）和管理活動(dòng)。這種繁瑣的方法在當(dāng)今車輛中跨異構(gòu)軟件域管理更新時(shí)已經(jīng)顯示出了局限性。因此，現(xiàn)有的解決方案不再適應(yīng)來處理由于SDV所需的軟件更新數(shù)量和種類不斷增加帶來的挑戰(zhàn)。

為了克服這些挑戰(zhàn)，易特馳正致力于下一代OTA更新解決方案，該解決方案的靈感來源于云原生模范式[7]。基于聲明性方法[8]，授權(quán)車輛單獨(dú)識別其必須執(zhí)行哪些操作（例如，“下載”、“安裝”、“更新”、“刪除”）以達(dá)到預(yù)期的狀態(tài)。

下一代OTA更新帶來以下好處：

通過上下文感知流水線并通過應(yīng)用基礎(chǔ)設(shè)施即代碼[9]原則，自動(dòng)生成和驗(yàn)證車輛的各個(gè)預(yù)期狀態(tài)，

減少云后端的量和依賴性管理工作，

減少通過移動(dòng)網(wǎng)絡(luò)傳輸并存儲在云中的數(shù)據(jù)量，

通過統(tǒng)一的車載更新API對所有車載域進(jìn)行更新，如Linux/QNX OS、AUTOSAR經(jīng)典/自適應(yīng)中間件和應(yīng)用程序、Container/AAAOS框架和應(yīng)用程序以及ADAS/AD系統(tǒng)。

2.8從現(xiàn)場正確的數(shù)據(jù)中提取、分析、學(xué)習(xí)和改進(jìn)

在“真實(shí)世界”條件下從現(xiàn)場車輛和設(shè)備收集的數(shù)據(jù)是各種用例的重要來源。例如，來自連接車輛的診斷數(shù)據(jù)用于檢測和解決質(zhì)量問題，旨在減少召回活動(dòng)和軟件故障。基于傳感器的環(huán)境檢測依賴于雷達(dá)、激光雷達(dá)或攝像頭，正被用于ADAS/AD功能的背景下的數(shù)據(jù)驅(qū)動(dòng)開發(fā)。

然而，通過從車輛中收集數(shù)據(jù)，必須在收集不必要的數(shù)據(jù)和冒著丟失有價(jià)值的數(shù)據(jù)之間進(jìn)行權(quán)衡。前者可能導(dǎo)致昂貴的流量、存儲和處理成本，但后者可能導(dǎo)致缺乏適當(dāng)決策所需的相關(guān)數(shù)據(jù)。由于正確的權(quán)衡在很大程度上取決于用例，OEM應(yīng)在車輛外部上有一個(gè)靈活的數(shù)據(jù)通道，以便在需要時(shí)僅收集相關(guān)數(shù)據(jù)。

除此之外，數(shù)據(jù)不僅來自現(xiàn)場，還來自各種來源。為了充分利用其價(jià)值，必須將收集的數(shù)據(jù)提供給公司在世界各地的開發(fā)團(tuán)隊(duì)，甚至是其它公司的開發(fā)團(tuán)隊(duì)，例如從OEM到Tier 1。因此，需要解決的挑戰(zhàn)有兩個(gè)方面：1.為數(shù)據(jù)共享創(chuàng)建法律基礎(chǔ)的組織基礎(chǔ)；2.建立接口和工具的技術(shù)基礎(chǔ)，以方便提取、處理和分析車輛現(xiàn)場數(shù)據(jù)。

在這種情況下，成功的基礎(chǔ)的關(guān)鍵標(biāo)準(zhǔn)是：

可擴(kuò)展性和資源效率，其中集中式的一次性集成實(shí)現(xiàn)了針對多個(gè)用例快速載入不同的數(shù)據(jù)源

標(biāo)準(zhǔn)化，以便轉(zhuǎn)化來自不同來源的異構(gòu)數(shù)據(jù)

卓越運(yùn)營，依靠可擴(kuò)展的全球數(shù)據(jù)基礎(chǔ)設(shè)施來確保數(shù)據(jù)可用性。

2.9遵循法規(guī)和標(biāo)準(zhǔn)

最近，汽車行業(yè)很少有法規(guī)和標(biāo)準(zhǔn)受到關(guān)注。在這方面最需要強(qiáng)調(diào)的是描述車輛軟件更新要求的第156號UNECE法規(guī)[10]。特別是OEM需要提供“軟件更新管理系統(tǒng)（SUMS）”正常運(yùn)行的證據(jù)。SUMS是一種系統(tǒng)化方法，它定義了組織過程，以符合軟件更新管理和部署的要求。這種方法：

解決軟件更新是否會(huì)影響任何已有的系統(tǒng)，

使用RxSWIN（RX軟件識別號）生成已有系統(tǒng)的唯一識別軟件版本，

評估軟件更新與目標(biāo)車輛的兼容性、更新系統(tǒng)的相互依賴性、通知車輛用戶更新的能力以及車輛所有軟件更新的記錄。

這種方法還包括車輛類型的專用功能。軟件更新的真實(shí)可靠性和完整性應(yīng)通過以上步驟獲得保證。

更新失敗也是需要進(jìn)行管理的，例如，通過將系統(tǒng)恢復(fù)到以前的版本或進(jìn)入安全狀態(tài)。還需要確保OTA軟件更新之前、期間和之后的車輛安全。

在這種情況，ISO/FDIS 24089[11]標(biāo)準(zhǔn)的目標(biāo)是支持第156號UNECE法規(guī)的執(zhí)行。用于解決執(zhí)行軟件更新的基礎(chǔ)架構(gòu)、涉及的車輛和車輛系統(tǒng)、軟件更新包的開發(fā)以及軟件更新活動(dòng)的運(yùn)行。目前，ISO文件仍處于起草階段，計(jì)劃于2023年初發(fā)布。

2.10確保軟件環(huán)境的安全，防止黑客入侵

隨著車輛功能由軟件定義，從而變得更加通用，相關(guān)安全風(fēng)險(xiǎn)預(yù)計(jì)會(huì)不斷變化，并可能增加。這對于定義安全風(fēng)險(xiǎn)的兩個(gè)因素來說是正確的：1.成功攻擊的潛在影響（特別是在自動(dòng)駕駛領(lǐng)域）2.成功攻擊的可能性，因?yàn)楦叩能浖?fù)雜性與漏洞概率的增加直接相關(guān)。當(dāng)今的安全方法主要集中在車輛開發(fā)和設(shè)計(jì)階段，因此需要延伸以覆蓋SDV生命周期。

此外，需要通過持續(xù)的安全監(jiān)測和風(fēng)險(xiǎn)管理來修改安全方法。這些概念包括以下功能：

利用入侵檢測系統(tǒng)檢測車輛中的潛在入侵，

通過車輛安全運(yùn)營中心持續(xù)監(jiān)控車隊(duì)安全并統(tǒng)籌攻擊遷移

通過各自車輛和云端能力來阻止和/或應(yīng)對新發(fā)現(xiàn)的攻擊

2.11在基于開源的生態(tài)系統(tǒng)中合作

過去，汽車行業(yè)在構(gòu)建新技術(shù)時(shí)通常面臨兩種選擇：“制造與購買”。雖然“制造”選項(xiàng)提供完全控制，但在就開發(fā)和運(yùn)營而言，它是最昂貴的選項(xiàng)。它需要稀少而多樣化的技能，最終可能會(huì)成為難以在市場上成功且跨車系或品牌復(fù)用率低的一個(gè)利基小眾解決方案，另一方面，“購買”選項(xiàng)可能會(huì)導(dǎo)致供應(yīng)商或技術(shù)鎖定，從而降低在市場上差異化的可能性。

其他行業(yè)已經(jīng)成功地展示了通過利用開源社區(qū)而帶來經(jīng)過驗(yàn)證和充分測試的優(yōu)勢，例如免于技術(shù)鎖定、廣大技術(shù)人員的力量、可靠性和免費(fèi)測試、縮短上市時(shí)間或提高安全性。

將其適應(yīng)汽車行業(yè)提供了一種更靈活、更平衡的解決方案以擺脫“制造或購買”：開放式SDV計(jì)劃推動(dòng)所需技術(shù)在非差異化構(gòu)造塊上的開發(fā)和增強(qiáng)。因此，汽車行業(yè)可以分享基于在一個(gè)開放技術(shù)平臺、標(biāo)準(zhǔn)，和以開源車內(nèi)協(xié)議棧為中心的框架上的成就。利用開放標(biāo)準(zhǔn)和供應(yīng)商中立的治理模式可以避免市場分裂，并為OEM提供廣泛采適用的技術(shù)平臺和解決方案。此外，在這些開放的、經(jīng)過測試的、無差別的要素上構(gòu)建軟件可以釋放出寶貴的開發(fā)人員資源。Eclipse SDV工作組、COVESA聯(lián)盟或SOAFEE項(xiàng)目在這些上是公認(rèn)先進(jìn)的典范。

三

結(jié)論

軟件是OEM滿足客戶期望的關(guān)鍵差異化因素。由于它解鎖開啟了新的使應(yīng)用用例和收入模式，也成為了延長車輛生命周期的推動(dòng)者。

對軟件的巨大需求和增長導(dǎo)致OEM面臨多項(xiàng)挑戰(zhàn)，例如處理復(fù)雜性，同時(shí)保證整個(gè)技術(shù)鏈的安全性，以便將新軟件引入車輛。本文全面概述了這些挑戰(zhàn)，并概述了OEM為成功克服這些挑戰(zhàn)所需要的技術(shù)方案。這些方案涵蓋了汽車價(jià)值所在定位、使用哪些開發(fā)工具、需要考慮的相關(guān)云服務(wù)和車輛組件等方面的心態(tài)理念轉(zhuǎn)變。在這個(gè)前提下，強(qiáng)調(diào)了行業(yè)法規(guī)和基于開源生態(tài)系統(tǒng)的必要性。同時(shí)把上述那些不同的構(gòu)造塊結(jié)合在一起，將使OEM及其解決方案提供商能夠簡化、加速和自動(dòng)化軟件的創(chuàng)建和測試，以改進(jìn)開發(fā)、節(jié)省上市時(shí)間并降低成本。

審核編輯：劉清