摘要：

軟件定義汽車（SDV）開發(fā)模式對主機廠自主管理車載軟件開發(fā)提出了不同于傳統(tǒng)模式的全新要求。文章提出了用戶體驗軟件產(chǎn)品（UESP）的概念，并且分析了UESP與Feature之間的關系，得出了UESP是SDV模式下主機廠軟件開發(fā)的關注重點這一結論。文章針對SDV模式下的UESP的產(chǎn)品結構，設計方法進行了較深入分析，并對UESP的設計工具乃至開發(fā)環(huán)境提出了初步建議。

Abstract:

Software-defined vehicle (SDV) development model is different from the traditional model in the development of vehicle software. This paper puts forward the concept of user experience software product (UESP) and analyzes the relationship between UESP and Feature, and draws the conclusion that UESP is the focus of software development for OEMs under the mode of SDV. This paper analyzes the product structure and design method of UESP in SDV mode, and puts forward some preliminary suggestions for UESP design tools and even development environment.

關鍵詞：軟件定義汽車（SDV），F(xiàn)eature, 用戶體驗軟件產(chǎn)品（UESP），場景，元場景，功能，元功能，服務，元服務，交互，交互周期，交互層級，輸入單元，輸入方法，輸入點，輸出單元，場景庫，部件庫，服務庫

KEY WORDS:  Software defines vehicle (SDV), feature, user experience software product (UESP), scene, meta-scene, function, meta-function, service, meta-service, interaction, interaction cycle, interaction hierarchy, input unit, input method, input point, output unit, scene library, component library, service library

正文

軟件定義汽車開發(fā)模式的最大特點就是車載軟件的發(fā)布和車型發(fā)布分離開。這樣做的好處在于車型的硬件生命周期可以延長，而車載軟件的發(fā)布時間可以非常的靈活。要做到車載軟件和車型發(fā)布的分離，就需要引入主機廠自主管理車載軟件開發(fā)的模式。這種模式是以車載軟件成為獨立產(chǎn)品為代表的，在與之相對的傳統(tǒng)開發(fā)模式下，并沒有獨立的軟件產(chǎn)品的概念，所有的Feature是依靠多個ECU來協(xié)同完成的，也因此由多個供應商來開發(fā)和管理代碼。

在SDV的模式下，車載軟件才可以作為獨立的軟件被主機廠管理。因此車載軟件的設計就成為了主機廠必須面對的課題，而這些工作原本大都是由部件供應商來完成的。同時作為獨立產(chǎn)品的車載軟件也需要獨立的物理運行環(huán)境，這就是域控制器出現(xiàn)的原因之一。

本文將針對SDV開發(fā)模式下的車載軟件設計進行研究，并提出設計方法。這一設計方法也是建立主機廠車載軟件正向開發(fā)體系的重要部分。

研究車載UESP的設計方法既是為了提高整車正向開發(fā)能力，也是為實現(xiàn)軟件定義汽車建立可遵循的規(guī)范，更為軟件定義汽車的技術體系構成提供了基礎，同時也為主機廠從傳統(tǒng)汽車開發(fā)模式向軟件定義汽車的開發(fā)模式過渡提供指引。

1、用戶體驗產(chǎn)品的概念

用戶體驗產(chǎn)品（User Experience Product，簡稱UEP）是指搭載在汽車上，能夠被用戶感知，進而影響到用戶體驗的刻意設計出來的一切汽車特性。

UEP包含但不限于汽車造型，顏色，尺寸,  部件（比如后掀背門），加速產(chǎn)生的推背感，防夾車窗，自動駕駛的TJA，智能鑰匙或者是迎賓系統(tǒng)等等。

用戶體驗軟件產(chǎn)品（User Experience Software Product, UESP）則是專指UEP中需要軟件實現(xiàn)其功能的那一部分汽車特性。前面提到的加速產(chǎn)生的推背感，防夾車窗，TJA，智能鑰匙，迎賓系統(tǒng)就屬于UESP的范疇，因為他們都需要軟件來實現(xiàn)其功能。其他的顏色，造型就僅僅屬于普通的UEP。

本文中的正向開發(fā)設計方法就是針對UESP的正向開發(fā)過程的。

傳統(tǒng)汽車設計中，F(xiàn)eature（特性或者賣點）是很重要的概念。在本方法中，F(xiàn)eature等同于UEP。Feature（即UEP）通常包含單部件的功能或者多部件協(xié)同完成的功能組合。多部件協(xié)同完成的功能組合（比如前面提到的TJA）通常都需要軟件的參與，所以屬于UESP。單部件功能中有一些（比如防夾車窗）也需要軟件才能完成，所以也屬于UESP。其他不需要軟件實現(xiàn)的單部件功能（比如手動掀背門）就不屬于UESP。這些概念之間的關系參見圖1。

（圖1）

2、用戶體驗軟件產(chǎn)品（UESP）的構成

用戶體驗軟件產(chǎn)品（UESP）包含三個構成要素，分別是場景，服務，交互。通過分析，我們會發(fā)現(xiàn)所有的UESP都是在特定的場景下，調(diào)用一些服務的組合，按照一定的交互方式向用戶提供服務。

除了場景，服務，交互之外，用戶需求也是設計UESP時需要重點考慮的，因為它是設計UESP的目的，所有UESP都是為了滿足用戶需求而產(chǎn)生的。雖然用戶需求并不出現(xiàn)在UESP要素中，但它卻是隱藏在產(chǎn)品設計背后的真正驅(qū)動力。

UESP通過對場景的識別來判斷或者猜測用戶的需求（產(chǎn)品設計者在設計時需要把用戶需求和場景做對應），因此場景被引入為UESP的構成要素。場景的識別包含兩種方式，一種是用戶意愿的自主表達，另一種則是場景識別，即基于場景識別算法自動進行識別。

場景的識別和服務的提供都依賴交互手段的采用，也就是用戶意愿表達和服務的提供都離不開交互手段的應用，無論這種交互手段是點擊按鍵，擰旋鈕，語音或者手勢控制，還是文字信息，音視頻服務或者HUD。所以交互也是UESP的重要構成要素。

UESP的三個構成要素關系可參見圖2。

圖2

3、UESP三要素的分析

為了研究UESP的設計方法，就必須要對場景，服務和交互這三個要素深入分析。

3.1 場景

場景就是狀態(tài)，是汽車，汽車使用者或者外部條件的多種狀態(tài)的組合。

汽車狀態(tài)包括汽車的所有機械部件，電子部件，軟件組件的狀態(tài)，以及它們之間的龐大的組合。汽車狀態(tài)還包括與其產(chǎn)品屬性相關的生命周期狀態(tài)和與其財產(chǎn)屬性相關的權屬狀態(tài)。

汽車使用者狀態(tài)可以細分為包括但不限于的身體姿態(tài)，心理狀態(tài)，生理狀態(tài)和社會身份等等。多位汽車使用者同時在汽車上出現(xiàn)本身也構成了更為復雜的社交狀態(tài)。

外部狀態(tài)可以細分為包括但不限于的時間，地理位置，天氣狀態(tài)，交通狀態(tài)，通信環(huán)境狀態(tài)等。

前面提到過，UESP的設計是為了滿足特定的用戶需求。需求由汽車使用者的需求或者汽車的需求所構成，兩者都是與特定的場景相關聯(lián)的。由于用戶需求無法在產(chǎn)品中直接得到體現(xiàn)，所以我們通過定義特定場景來間接反映出用戶的特定需求。

比如我們要設計一款UESP，加油服務產(chǎn)品。在汽車油量低時這款產(chǎn)品會主動向駕駛者提供周圍的加油站位置。這個產(chǎn)品的需求就是汽車的加油需求。而場景就是汽車的油量狀態(tài)低于一定比例時，比如20%。我們可以通過傳感器定量判斷“汽車油量低于20%”這個場景是否出現(xiàn)，這樣場景就可以被測量和管理。因此我們把這個狀態(tài)定義為汽車需要加油的場景。當然我們也可以把所剩油量不同狀態(tài)分別對應于急迫程度不同的加油需求。 僅僅有油量狀態(tài)還不夠，因為我們還需要知道汽車的位置，這樣才能查找周圍的加油站。加油服務產(chǎn)品的需求，場景和狀態(tài)的關系見圖3。通過匹配急迫程度不同的加油需求和加油站里車輛的距離，還可以設計出更加精細，更有實用價值的場景加油產(chǎn)品。這就是高德導航里的Range on的設計原理。

圖3

實際場景會涉及很多維度，很多變量，變量的取值范圍也會很廣泛。因此針對復雜的場景研究，我們可以考慮采用場景狀態(tài)相空間的概念，見圖4。

圖4

從圖4可以看出來，有時候場景對應于場景狀態(tài)相空間中的一個點。有的時候，場景也可能對應于狀態(tài)相空間中的多個點或者區(qū)域，見圖5。比如四個車門的開合狀態(tài)和使用者的位置狀態(tài)（車內(nèi)或者車外）（這一場景可以用于設計PEPS系統(tǒng)）。

圖5

在實際的場景設計中，當涉及的維度較少時，狀態(tài)矩陣可以被引入到方法中。比如上面提到四個車門開合狀態(tài)所構成的不同場景，見圖6。

圖6

場景狀態(tài)相空間和狀態(tài)矩陣提供分析了場景分析，場景設計的工具。

場景設計就是找到場景狀態(tài)相空間的一個子集，把它和需要滿足的特定需求建立起對應關系。這種對應關系的設定很多時候依靠的是產(chǎn)品經(jīng)理的常識或者直覺。但是對于復雜場景和隱蔽需求之間的關系，僅僅靠常識或直覺是不夠的，這時候基于歷史大數(shù)據(jù)的分析是可能有效的方法。

UESP涉及的場景往往比較復雜，研究場景設計的方法，我們需要研究最小顆粒度的場景，我們稱之為元場景。元場景就是可以被識別的最小車輛部件的狀態(tài)，或者人員和環(huán)境可以被識別的最小狀態(tài)。

比如單個車門的開合狀態(tài)就是一個元場景，而幾個門的開合狀態(tài)就不是。比如駕駛員饑餓就是一個元場景，而駕駛員身體不舒服（因為不舒服可以包含饑餓和其他很多元場景）就不是。元場景的的結構可以描述為：

{對象：{狀態(tài)值集合}}

就像場景的定義一樣，元場景對象包含汽車部件，汽車使用者和外部環(huán)境的各種因素。

狀態(tài)值集合可能有一些離散值構成，也可能是連續(xù)值集合。車輛狀態(tài)的元場景往往是用車載傳感器來征測的，所以狀態(tài)值往往是傳感器偵測的數(shù)值。當然元場景也可能與執(zhí)行器對應，這樣的話狀態(tài)值就執(zhí)行器的狀態(tài)數(shù)值。

3.2服務

本設計方法中的服務包括車載功能和第三方服務。

車載功能是指汽車部件通過軟件控制所實現(xiàn)的，可以被駕乘人員所感知的能力，比如車窗可以開合，燈光可以亮滅，可以語音識別等等。這里強調(diào)的車載功能需要區(qū)別于完整的UESP，因為完整的UESP是有場景觸發(fā)條件的，而車載功能只是能力，需要設計了場景觸發(fā)條件才成為UESP。

UESP可以有很多車載功能組成，因此與元場景類似，我們也需要研究最小顆粒度的功能，我們稱之為元功能。元功能就是可以識別，可以用軟件控制的車載部件的最小功能。它的結構可以描述為：

圖7

或者是：{對象：{物理量類型}，{狀態(tài)值集合}

類似于元場景的結構，這里的狀態(tài)值集合可以是離散值，也可以是連續(xù)值集合。離散值對應于比如門窗的開合狀態(tài)，音響的開關狀態(tài)。連續(xù)值就對應于空調(diào)溫度，或者音量。車載元功能大都是和車載執(zhí)行器件相關的。

UESP涉及的第三方服務指的是汽車通過車聯(lián)網(wǎng)獲取的第三方能力，這些能力主要表現(xiàn)為信息服務，可能包括傳統(tǒng)的CP/SP的服務，也可能包括未來V2X時代來自于交通設施和其他交通參與者提供的信息。這些信息主要由文本，圖片，音頻和視頻構成。類似于元功能，我們也需要提出第三方元服務的概念，以作為UESP設計會用到的基礎對象，它的結構可以描述為：

圖8

或者是：{元服務來源：{元服務類型}，{內(nèi)容格式}，{元服務內(nèi)容}}

比如天氣查詢服務就可能描述為：服務商名字+天氣服務+文本+“內(nèi)容”。

3.3 交互

一個完整UESP產(chǎn)品的交互是由多個相似周期組成的，其結構可以描述為：

{交互周期1；交互周期2；交互周期3；...}，每一個交互周期的結構是：

{輸入單元，輸出單元}。綜合到一起就是：

圖9

三個周期只是UESP的典型結構，并不是每一個UESP產(chǎn)品都必須有這三個周期，有的可能只有一個，也有的可能需要四個，甚至更多。UESP產(chǎn)品所包含的交互周期的數(shù)量，可以稱為交互層級或者交互深度。（有關交互深度的研究不在本文范圍中）。交互設計的目標是讓交互周期數(shù)量越少越好，也就是交互層級越少越好。無論UESP有幾個交互周期，第一個交互周期始終是存在的，而且是比較特殊的，因為它代表著用戶對UESP的發(fā)起。

輸入單元是使用者或者場景識別算法對車提供輸入的環(huán)節(jié)，屬于車輛感知范疇，出現(xiàn)在場景判斷中，用于功能或者服務的觸發(fā)。UESP的發(fā)起必然通過兩種方式。第一種方式是用戶主動表達自己的意愿，依靠的手段包括但不限于實體按鍵，遙控（遙控器或者手機），語音命令，手勢識別等等控制。第二種方式是用戶沒有主動表達意愿情況下，UESP根據(jù)場景識別的算法判斷出設計的場景已經(jīng)出現(xiàn)。這兩種情況在輸入單元中都會涉及，但本文主要分析第一種情況。

輸出單元是車輛對用戶提供輸出的環(huán)節(jié)，作為用戶輸入的反饋，出現(xiàn)在功能或服務提供的過程中，用于確保UESP按照用戶意愿去提供服務。輸出單元主要用于詢問用戶是否確定提供服務（確認），或者是對不同服務選項的選擇（多項選擇），以及服務過程本身（提供服務）。

從UESP的交互結構圖可以看出來，一共有四種類型的輸入和輸出單元，分別是功能發(fā)起輸入單元，意愿選項輸出單元，意愿選項輸入單元，服務內(nèi)容輸出單元。

功能發(fā)起輸入單元只會出現(xiàn)在第一個交互周期，通常用于功能的發(fā)起。意愿選項輸出單元大多是要求用戶確認意愿或者為用戶提供服務選項，可以出現(xiàn)在除了最后一個交互周期的任何一個交互周期中。意愿選項輸入單元通常用于用戶對意愿或者服務選項進行確認或選擇。服務內(nèi)容輸出選項則是開始提供服務。

3.3.1 功能發(fā)起輸入單元可以抽象為：

{目標功能；輸入方式；輸入點}。

先談談輸入方式。第一大類輸入方式是物理按鍵輸入，包含實體按鍵和屏幕軟鍵兩種方式。實體按鍵和屏幕軟鍵都可以出現(xiàn)在車載上，遙控器上，手機上或者智能家居的設備上。而按鍵形式可以包含開關，擋位選擇，旋鈕。第二大類輸入方式是語音輸入，這也是目前非常流行的輸入方式，原因當然是它屬于人類最自然的交互方式之一。第三大類輸入方式是身體姿態(tài)輸入，包括手勢識別，眼動識別或者其他目前還沒有發(fā)明的用人體姿態(tài)變化來實現(xiàn)輸入的方式。

雖然功能發(fā)起輸入單元屬于第一交互周期，但是這三大類輸入方式在其他交互周期的中也是一樣的。

輸入點是指具體的輸入方式中承載明確輸入目的的某個按鍵，某句語音指令，某個手勢動作或某個眼球注視角度。

所以功能發(fā)起輸入單元實際上就是把一個UESP功能的發(fā)起分配給某種（或者某幾個）輸入方式的某一個（或者某幾個）輸入點。

輸入方式見圖10。

圖10

第一交互周期的功能發(fā)起輸入單元的具體設計會面對兩個重要問題。

第一個問題是，在用戶準備啟用某個UESP之前，他一定是知道這個功能存在的。那么怎么讓用戶知道這個功能存在呢？一些傳統(tǒng)功能（比如空調(diào)，音響），已經(jīng)布置在車載的物理按鍵上了，用戶根據(jù)常識或者熟悉按鍵布置就可以了解。但是對于現(xiàn)在的智能網(wǎng)聯(lián)汽車，功能越來越多，還出現(xiàn)了物理按鍵減少，合并，采用軟按鍵的趨勢，很多功能就不是那么一目了然的。在這樣的狀況下，如何讓用戶很容易地知道存在哪些UESP，并且知道如何啟用這些UESP成為了問題。我們把這個問題稱為UESP功能展現(xiàn)的完備性設計和可發(fā)現(xiàn)性設計。也就是說如何針對日益豐富的UESP功能設計出系統(tǒng)性的分類方法，合理的座艙按鍵布置，直觀容易理解的輸入方法，是座艙交互系統(tǒng)設計的重要課題。

第二個問題是輸入方法的替代性問題和協(xié)同問題。輸入方法有按鍵輸入，語音輸入，還有手勢識別，眼動識別或者其他還沒有被發(fā)明的輸入方法。在UESP整個交互過程中，輸入方法之間并不是完全可以相互替代的。（舉例？）分析這些輸入方法的差異，從而發(fā)揮各自最大作用和協(xié)同作用是很重要的。

3.3.2 意愿選項輸出單元有兩種情況，一種只是意愿確認（是或者否），一種則是選項提供，分別可以抽象為：

{服務意愿；{輸出方式1；部件；參數(shù)}； {輸出方式2；部件；參數(shù)}...；輸入方式提示}

{服務選項；{輸出方式1；部件：參數(shù)}:；{輸出方式2；部件；參數(shù)}...；輸入方式提示}

（第一交互周期的服務意愿和服務選項通常都是文本信息。）

服務意愿通常只有“是”和“否”兩個選項。

服務選項則有兩種情況，第一種情況下，選項是離散的，有兩三種，到十幾種，甚至更多，比如POI查詢結果。另一種情況下，選項是連續(xù)值，比如要設定的空調(diào)溫度。

輸出方式可以按照視覺輸出，聽覺輸出，體感輸出來劃分。視覺輸出又可以按照信息格式來區(qū)分，比如文本，圖片，動效，動畫或者視頻。與之對應的部件則是能夠提供視覺輸出的所有車載部件，比如車內(nèi)外燈光，車內(nèi)各個屏幕，儀表，HUD，甚至未來的透明車身和車窗顯示器等等。視覺輸出的參數(shù)則是文本的字體，大小，位置等等，圖片的質(zhì)量，位置，大小等等，視頻的質(zhì)量，位置，大小，碼率等等。

類似的，聽覺輸出對應的部件包含車上的一切可以軟件控制發(fā)出聲音的部件，比如喇叭，音響，低速聲音發(fā)生器等等，而參數(shù)就包括音質(zhì)，音量，聲效，聲源位置等。

體感輸出包括但不限于觸感回饋，座椅震動，方向盤震動等。觸感回饋可以告訴用戶自己輸入的有效性。座椅震動則可以用在提醒駕駛員在自動駕駛失效時對車輛的接管。體感輸出通常只是作為輔助手段而出現(xiàn)。

輸出方式見圖11。

圖11

設計意愿選項輸出單元的目的就是要解決如何把服務意愿和服務選項分配給合適的輸出方式，按照合適的參數(shù)在合適部件上，以供用戶確認或者選擇，最好還可以提示用戶如何輸入自己的選擇。特定輸出單元可以選擇一種，也可以是兩種或以上輸出方式提供給用戶。

當選項數(shù)量較多時，輸出方式本身的局限性會暴露出來。首先語音播報不太適合選項較多的情況，因為播報完所有選項的時間太長了，用戶會失去耐心，也不可能記得住。用視覺顯示也會存在顯示區(qū)域大小的限制，如果加上翻頁的交互操作，又會增加交互的深度。但是這個矛盾的解決不在本文討論。這個問題我們稱之為輸出方式的效率問題。（翻頁操作其實也可以看作為選項的一種，所以仍然可以包括在本方法之中，只是增加了一個交互周期而已）

在選項是連續(xù)值的情況下，輸出并沒有實質(zhì)性的困難，只需要告訴用戶取值范圍就好了。但是選擇具體數(shù)值的輸入方式會比較困難，我們留待以后的研究進行解決。

輸入方式提示是告訴用戶采用什么輸入方式來進行選擇。這一部分和意愿選項輸入單元的輸入方式設計需要保持一致。

3.3.3 意愿選項輸入單元可以抽象為：

{服務意愿m；輸入方式；輸入點m}

{服務選項n；輸入方式；輸入點n}

本單元設計目標是針對意愿選項輸出單元所提供每一個意愿和服務選項，按照其所提示的輸入方法，設計輸入方式和輸入點。

有關輸入方式和輸入點的解釋和前面功能發(fā)起輸入單元是一致的。

需要注意的是無論服務選項是可數(shù)的離散值還是連續(xù)值，{服務選項n；輸入方式；輸入點n} 的結構都是適用的。當然也可以針對同一個選項，同時設計多種輸入方式和輸入點。

3.3.4 服務內(nèi)容輸出單元可以抽象為：

{服務內(nèi)容；{輸出方式1；部件；參數(shù)}； {輸出方式2；部件；參數(shù)}...；輸入方式提示}

服務內(nèi)容輸出單元與意愿選項輸出單元的結構幾乎是一樣的。差別在于意愿選項大多是文本內(nèi)容，而服務內(nèi)容除了文本內(nèi)容，還可以有圖片，視頻和音頻。

需要注意的是服務內(nèi)容輸出單元，并不意味著交互的終結。因為在服務內(nèi)容輸出過程中，用戶還可能產(chǎn)生一些新的需求，比如在聽音樂過程中換曲，暫停等等。這些功能選項也屬于服務內(nèi)容的范疇，也需要進行輸出方式的相關設計。

這個單元里的輸入方式提示則是用于告訴用戶在當前周期里，他可以做用什么輸入方式做什么樣的操作。這部分設計的困難與前面提到的UESP功能展現(xiàn)的完備性設計和可發(fā)現(xiàn)性設計是相似的。

4、UESP的產(chǎn)品結構

基于2和3的分析，UESP產(chǎn)品的的結構可以表示如下：

圖12

這個結構為后面的設計環(huán)境，運行環(huán)境的分析提供了基礎。

5、UESP的開發(fā)環(huán)境分析

在引入軟件定義汽車開發(fā)模式之前，針對Feature的完整的開發(fā)環(huán)境是不存在的，也沒有意義，因為大多數(shù)時候Feature是由幾家供應商分頭開發(fā)的，主機廠主要是管理需求。在傳統(tǒng)模式下，主機廠可能會采用需求管理和功能分解的流程工具，用來管控給供應商的需求輸入。

在軟件定義汽車的模式下，與Feature對等的UESP成為了主機廠管理，開發(fā)的對象，由于其單一，獨立的產(chǎn)品形態(tài)，客觀上要求主機廠擁有能夠有效開發(fā)UESP的開發(fā)環(huán)境。

在本文前面部分分析的基礎上，研究UESP的開發(fā)環(huán)境和開發(fā)工具就成為了可能。

由于軟件定義汽車開發(fā)模式在各主機廠還處于實踐初期，因此UESP的開發(fā)環(huán)境就具有很大的市場價值，也將定義一個規(guī)模客觀的全新市場領域。

UESP的開發(fā)環(huán)境主要由下面幾個部分構成：軟件主體設計工具，場景庫，部件庫和與服務庫。

下面對每一部分，進行簡要分析。

5.1 軟件主體設計工具

設計工具是各主機廠的產(chǎn)品設計開發(fā)部門使用的，用于UESP產(chǎn)品的設計。設計工具包含兩個主要部分，一個用于設計把特定場景和對應車載功能，第三方服務關聯(lián)起來的決策軟件模塊，可以被稱為決策模塊設計。決策模塊設計主要解決的問題是，基于以多種場景觸發(fā)條件為輸入的算法，決定調(diào)用車載功能和第三方服務的方式。決策模塊可以包括簡單的邏輯運算，時序判斷和設計，也可以包含復雜的自動駕駛算法或者DMS（駕駛員監(jiān)控系統(tǒng)）等。

主體設計工具的另一個部分可以被稱為交互模塊設計，用于設計人機交互的整個過程，負責把輸入輸出信息分配到不同的輸入輸出方式和部件，并且把設計規(guī)范固化在其中，可以被稱為交互模塊設計。注意第二部分交互模塊設計不是簡單交互界面設計，不同于傳統(tǒng)的交互原型設計軟件。在SDV模式下，由于硬件控制組件的標準化，交互模塊設計完成后可以調(diào)用部件庫里的硬件控制組件，從而直接驅(qū)動硬件。

交互模塊設計主要解決的問題是，每一個交互周期的設計，需要具備針對每一個交互信息定義對應的交互部件，并且設定其交互參數(shù)的能力。

5.2 部件庫

使用軟件主體設計工具進行設計時，必然需要把車載功能設計到UESP中，因此需要用到部件庫。部件庫的設計要遵循完備性，系統(tǒng)性和平臺性的原則。

5.3 服務庫

使用軟件主體設計工具進行設計時，必然需要把第三方服務設計到UESP中，因此需要用到服務庫。服務庫同樣需要按照完備性，系統(tǒng)性和平臺性的設計原則進行設計。

5.4 場景庫

場景庫要能夠管理場景的完整生命周期，即創(chuàng)建，修改，刪除和管理UESP所包含的場景。為了實現(xiàn)這個目標，場景庫要能夠訪問部件庫，因為根據(jù)前面3.1對場景的分析，場景大多是時候是由部件狀態(tài)構成的。

UESP開發(fā)環(huán)境最好是在云環(huán)境中進行建設。

以上是對UESP開發(fā)環(huán)境的簡單分析，詳細分析內(nèi)容不在本研究方法的范圍內(nèi)。

6、UESP的運行環(huán)境分析

UESP作為一個車載獨立軟件需要運行在明確的硬件上，這個硬件就是一個域控制器。座艙域控制器就是實現(xiàn)信息交互為目的的UESP所運行的硬件環(huán)境。其實域控制器的出現(xiàn)原因就在于在軟件定義汽車模式下，獨立存在的車載軟件必須要有相應的硬件運行環(huán)境。

除了硬件運行環(huán)境之外，UESP還需要域控制器上的軟件運行環(huán)境。這個軟件運行環(huán)境主要指的是操作系統(tǒng)，以及可能需要的服務中間件。

另外為了保證新開發(fā)的UESP可以下發(fā)到已經(jīng)銷售出去的汽車上，還需要支持能夠針對每一輛具體車輛升級的OTA系統(tǒng)。同時為了管理每一臺車輛不同的升級狀態(tài)，運行狀態(tài)，付費狀態(tài)，安全狀態(tài)，還需要建設能夠記錄和管理每一臺汽車軟件和硬件狀態(tài)的汽車數(shù)字鏡像云。

軟件定義汽車的開發(fā)模式是傳統(tǒng)主機廠前所未遇的，因此UESP的正向開發(fā)設計方法也通過本文第一次提出來，而UESP的開發(fā)環(huán)境和運行環(huán)境則是更加前瞻性的思考。UESP的開發(fā)環(huán)境和運行環(huán)境將形成巨大的軟件產(chǎn)業(yè)發(fā)展機會，其效應將不亞于其他傳統(tǒng)開發(fā)模式下開發(fā)工具鏈。然而UESP運行環(huán)境和運行環(huán)境的詳細分析內(nèi)容不在本論文研究范圍內(nèi)。作者在后續(xù)論文將逐步闡述。

原文標題《符合軟件定義汽車（SDV）開發(fā)模式的車載用戶體驗軟件產(chǎn)品（UESP）正向開發(fā)設計方法》