在軟件定義汽車的時代，功能體驗(yàn)日新月異，采用面向信號的架構(gòu)開發(fā)模式不能滿足用戶對于功能快速交付的期待，正初步地被面向服務(wù)架構(gòu)所取代。本文討論了面向功能開發(fā)流程中的核心元素，以及功能、系統(tǒng)和零件之間的關(guān)系，提出了在系統(tǒng)層建立以功能架構(gòu)為基礎(chǔ)的建模方法。同時結(jié)合吉利汽車的開發(fā)實(shí)踐經(jīng)驗(yàn)，提出功能導(dǎo)向開發(fā)模式的組織分工，建議由系統(tǒng)工程師來主抓功能架構(gòu)在系統(tǒng)層建模并推動落地。最后展望了功能架構(gòu)在面向服務(wù)架構(gòu)和敏捷開發(fā)流程中的重要作用。
前言
隨著電動化、共享化、智能化和網(wǎng)聯(lián)化時代的到來，用戶的需求與日俱增，豐富的應(yīng)用場景和個性的駕乘體驗(yàn)驅(qū)動著整車電子和軟件進(jìn)行快速地迭代和創(chuàng)新。2010年生產(chǎn)的一臺豪華轎車具備800個整車功能，而在2007年這個數(shù)量只有270個。隨著整車算力的提升，信息安全、功能安全要求也在提高，代碼量還會快速提升。當(dāng)前豪華車輛代碼已經(jīng)能達(dá)到2~3億行 ，軟件在進(jìn)行快速迭代的同時，也增加其在整車價(jià)值鏈中的比重，根據(jù)Apostu等的預(yù)測，軟件創(chuàng)造的價(jià)值在2030年將達(dá)到整車的30%。在當(dāng)今存量市場競爭的背景下，各整車廠都在積極地推出架構(gòu)平臺，比如：大眾汽車的MEB，豐田汽車TGNA和吉利汽車的SEA架構(gòu)，依托架構(gòu)進(jìn)行造車，用于控制成本，提高競爭力。電子電氣架構(gòu)作為整車功能的基礎(chǔ)平臺，其可擴(kuò)展性將決定各整車廠在未來軟件定義汽車賽道上的競爭力。如何在電子電氣架構(gòu)上快速進(jìn)行功能的開發(fā)和擴(kuò)展，是業(yè)界共同的挑戰(zhàn)。
1 面向功能開發(fā)模式
現(xiàn)代汽車電子電氣架構(gòu)通過各類總線至少可以連接150個控制器，并且能部署300萬多項(xiàng)功能。要整體管理這樣規(guī)模的系統(tǒng)，僅通過網(wǎng)絡(luò)架構(gòu)和系統(tǒng)架構(gòu)來梳理是無法掌握功能之間的依賴關(guān)系。網(wǎng)絡(luò)架構(gòu)從通信的維度定義各個控制器之間的信號矩陣，而系統(tǒng)架構(gòu)從零件分工的維度明確它們之間的接口關(guān)系，其核心都是管理零件與零件之間的依賴關(guān)系。這就需要立足于功能，重構(gòu)其在電子電氣架構(gòu)上的開發(fā)邏輯。
面向功能開發(fā)模式強(qiáng)調(diào)從用戶使用場景出發(fā)，全面分析用戶需求，定義功能特征，最終通過零件來實(shí)現(xiàn)，執(zhí)行功能實(shí)現(xiàn)的零件包括控制器、傳感器、執(zhí)行器、開關(guān)和顯示器等。功能需求在創(chuàng)建時顆粒度大小不一，通過層層傳遞后，需求內(nèi)容也會隨著關(guān)注重點(diǎn)的不同而被誤解，最后導(dǎo)致功能策劃和功能實(shí)現(xiàn)效果不一致。為了彌補(bǔ)功能需求理解差異，需要引入系統(tǒng)層來捋清功能和零件的映射關(guān)系，如圖1所示，起到承上啟下的作用。業(yè)內(nèi)對系統(tǒng)層的定義比較抽象和寬泛，在實(shí)際工作中不具備可操作性，反而額外增加了需求開發(fā)和維護(hù)的溝通開銷。
功能層的需求捕獲來自于用戶的使用場景，目的在于明確功能價(jià)值，控制器層的需求輸出給供應(yīng)商（內(nèi)部或者外部供應(yīng)商）開展開發(fā)工作，目的在于選擇技術(shù)方案。因此，系統(tǒng)層的需求工程目的就是將功能和零件統(tǒng)一關(guān)聯(lián)起來，主要起到以下兩方面的作用：
（1）引導(dǎo)功能場景進(jìn)行具體形象化，體驗(yàn)方式進(jìn)行精細(xì)化，并提煉成技術(shù)需求語言；
（2）指導(dǎo)零件技術(shù)方案選型，將功能需求分配到零件中去，并且明確零件在功能實(shí)現(xiàn)過程中的作用。
考慮網(wǎng)絡(luò)架構(gòu)的約束條件，在功能策劃階段，就能判斷功能實(shí)現(xiàn)的可行性并預(yù)估開發(fā)的成本和時間，能為功能決策提供相對可靠的依據(jù)。
1.1 功能、系統(tǒng)和零件的矩陣關(guān)系
為了更好地理解面向功能開發(fā)的流程，首先需要梳理清楚功能、系統(tǒng)和零件的關(guān)系。這3個術(shù)語的定義都整理在表 1~表 3中，同時增加了中文的翻譯。
解讀完術(shù)語定義并結(jié)合吉利汽車在開發(fā)中的工作實(shí)踐，本文建議采用矩陣方式來重新定義三者關(guān)系，在工作組織關(guān)系上則沿用分層結(jié)構(gòu)來建立上下游關(guān)系。控制器是整車比較特殊的零件，考慮到軟件基本上都集成在控制器中，因此在圖 2中使用控制器來代替零件。
功能、系統(tǒng)和控制器三者的矩陣依賴關(guān)系放在整車環(huán)境下進(jìn)行定義，可以表述為：在整車制造維度上，整車由單體零件組裝而來；在整車功能維度上，用戶體驗(yàn)是由單項(xiàng)功能組合呈現(xiàn)；系統(tǒng)從管理維度，將功能分門別類進(jìn)行組合。考慮到整車功能開發(fā)往往從特色功能的定義開始，故作表4所示定義。
1.2 系統(tǒng)對功能的完善
特色功能往往通過創(chuàng)新手段（比如：頭腦風(fēng)暴，設(shè)計(jì)思維）或者對標(biāo)而捕獲，并形成一個概念或者愿景表述，通過功能層的需求抽取，逐步地形成使用場景。在系統(tǒng)層上，面向功能場景進(jìn)行建模，使用用例圖、狀態(tài)機(jī)、時序圖等方法進(jìn)行分析，就能將功能點(diǎn)擴(kuò)展為功能族，進(jìn)而形成完整的功能清單。這份功能清單又作為新一輪的輸入進(jìn)行市場調(diào)研，然后確定每項(xiàng)功能的價(jià)值和優(yōu)先級。經(jīng)過多輪迭代和優(yōu)化，整車功能定義就能層次清晰，場景目標(biāo)明確，并能全局把控用戶的目標(biāo)期待，功能需求的提取是一個系統(tǒng)工程。
1.3 系統(tǒng)對零件的約束
零件的開發(fā)需要完整而清晰的功能需求和性能指標(biāo)，這樣才能有效地避免與需求反復(fù)確認(rèn)。系統(tǒng)層在進(jìn)行功能分配之前，需要了解零件的性能和處理能力，這樣就能有效地避免分配下來的功能，在零件上無法實(shí)現(xiàn)的問題。結(jié)合系統(tǒng)層利用零件和零件之間的分工方式定義出來的最優(yōu)接口方案，比如信號的周期和類型，就能明確地指導(dǎo)觸發(fā)機(jī)制的選擇。在系統(tǒng)層面進(jìn)行建模仿真能有效地預(yù)估功能響應(yīng)時間和動作幅度，并能給出帶有數(shù)據(jù)支持的零件開發(fā)目標(biāo)。
考慮到當(dāng)前功能安全和信息安全的要求，系統(tǒng)失效模式的分析工作，可以框定零件FMEA的工作重點(diǎn)，并能指導(dǎo)零件的異常處理機(jī)制部署。
1.4 系統(tǒng)對架構(gòu)的補(bǔ)充
網(wǎng)絡(luò)架構(gòu)的開發(fā)模式要求架構(gòu)團(tuán)隊(duì)輸出網(wǎng)絡(luò)拓?fù)鋱D、通信矩陣和診斷數(shù)據(jù)，但是對于功能的開發(fā)僅僅停留在信號層面。表5所示為架構(gòu)的定義，通過系統(tǒng)層的需求定義，建立功能和零件的依賴矩陣，這樣不僅能有效地協(xié)同各個零件同步開發(fā)進(jìn)程，快速高質(zhì)量地交付，同時也能有效地把控功能的變更，主動進(jìn)行功能重構(gòu)，迅速地適應(yīng)需求的變化。系統(tǒng)層需求的建模分析結(jié)果，從數(shù)據(jù)也能支持架構(gòu)拓?fù)浣Y(jié)構(gòu)、電源模式管理和網(wǎng)絡(luò)休眠喚醒機(jī)制等基礎(chǔ)性功能優(yōu)化的決策。
2 功能架構(gòu)模型
功能驅(qū)動帶來軟件復(fù)雜度的提升，嚴(yán)重地拖延了整車廠的創(chuàng)新和新功能交付，這就需要研究功能開發(fā)的關(guān)鍵路徑并找到優(yōu)化方向。結(jié)合吉利汽車的實(shí)踐經(jīng)驗(yàn)，使用功能架構(gòu)模型進(jìn)行系統(tǒng)層建模，由此有效地管理依賴關(guān)系，進(jìn)而提高研發(fā)效率。
2.1 功能架構(gòu)概念
功能架構(gòu)是在系統(tǒng)層對于功能進(jìn)行關(guān)系建模，根據(jù)前期開發(fā)的經(jīng)驗(yàn)，在實(shí)際開發(fā)工作中主要關(guān)注以下3個維度工作：
（1） 功能結(jié)構(gòu)：功能細(xì)化并描述功能對于系統(tǒng)的行為要求；
（2） 映射關(guān)系：描寫功能和零件通過接口定義的依賴關(guān)系；
（3） 零件角色：統(tǒng)一和擴(kuò)展功能對于零件的分工要求。
圖3把功能架構(gòu)的3個維度內(nèi)容有機(jī)地結(jié)合起來：功能和零件的依賴關(guān)系通過交叉圓點(diǎn)展示出來，零件在功能架構(gòu)中的作用也能通過查看三角標(biāo)記而得知，比如觸發(fā)條件、前提條件。針對系統(tǒng)層的功能實(shí)現(xiàn)邏輯，還能定義系統(tǒng)的類型，挖掘出系統(tǒng)層級的邏輯需求。系統(tǒng)的類型如表 6所示。
針對多輸入系統(tǒng)，就需要對輸入進(jìn)行優(yōu)先級定義，并且在邏輯上建立仲裁機(jī)制，而對于多輸出系統(tǒng)，就需要定義各個零件的響應(yīng)同步性；此外這也大大方便了功能安全的評審，不僅可以了解失效之后的功能安全狀態(tài)，也能明確零件單點(diǎn)失效率如何影響功能的降級行為。
2.2 功能狀態(tài)定義
利用功能架構(gòu)模型進(jìn)行系統(tǒng)層建模，就需要統(tǒng)一定義功能的狀態(tài)，如表7所示。統(tǒng)一建模語言，能方便開發(fā)團(tuán)隊(duì)進(jìn)行技術(shù)交流和討論。本文只標(biāo)準(zhǔn)化功能狀態(tài)，但不約束功能行為，也就是說單體功能可以根據(jù)場景的需求對于功能狀態(tài)進(jìn)行不同行為規(guī)范，比如燈光功能的Off指的是關(guān)燈，而玻璃升降器的Off指的是停止運(yùn)動。利用功能架構(gòu)進(jìn)行系統(tǒng)建模時，只關(guān)注功能的狀態(tài)遷移條件，而具體的控制行為或者算法實(shí)現(xiàn)方式，比如采用PID控制還是模糊控制，可由功能執(zhí)行的主要零件工程師進(jìn)行選擇。這樣分工，在概念設(shè)計(jì)階段能高效地定義系統(tǒng)行為，不用陷入太多技術(shù)細(xì)節(jié)討論，同時也能激活零件開發(fā)工程師的創(chuàng)造力，只要達(dá)成開發(fā)目標(biāo)，就可以各自自由進(jìn)行算法和程序的設(shè)計(jì)。
2.3 功能激勵條件定義
通過外部或者內(nèi)部的事件可以改變功能的狀態(tài)，這些事件可以按照表8來進(jìn)行分類，考慮到供應(yīng)鏈全球化趨勢，需求規(guī)范編寫時，也添加了英文名。
圖4表示功能狀態(tài)和條件關(guān)系，針對每個功能，如果有多個事件或者狀態(tài)組合成為一個條件，就需要把它們的組合關(guān)系也表示出來，比如邏輯“與”和邏輯“或”的關(guān)系。
3 應(yīng)用與實(shí)踐
在吉利浩瀚架構(gòu)上進(jìn)行了實(shí)踐，在此選擇腳踢開尾門的功能作為案例進(jìn)行說明。此功能允許車主利用腳來非接觸式地開啟后備箱。
3.1 用戶場景定義
在用戶場景階段，僅僅關(guān)注在什么情況下（When），解決了什么問題（What），但是對于問題怎么解決（How）不進(jìn)行討論。
根據(jù)市場部的調(diào)研以及功能開發(fā)工程師的對標(biāo)，腳踢開啟尾門功能按照卡諾模型的分類是屬于期望型功能，功能能給用戶帶來正向的使用價(jià)值，幫助客戶解決了不方便用手開啟尾門的場景，這種場景在超市購物、搬家和運(yùn)輸過程中發(fā)生的概率也比較高。當(dāng)然這個功能依賴于電動尾門開啟和無鑰匙進(jìn)入功能，并且一般部署在SUV車型之上。
3.2 搭建需求框架
首先，對于功能進(jìn)行結(jié)構(gòu)拆解，由于尾門開啟是一個動作執(zhí)行過程，可以根據(jù)動作的類型對于功能繼續(xù)細(xì)分，比如：
· 尾門解鎖
· 尾門升程運(yùn)動
· 尾門停止
其次，羅列尾門模塊中的零件清單，這個清單不僅僅包含控制器、開關(guān)、傳感器、電機(jī)等機(jī)電零件，甚至也可以將關(guān)聯(lián)的機(jī)械零件如鉸鏈也放在清單中。在尾門的升程運(yùn)動過程中，電機(jī)負(fù)責(zé)提供動力，而鉸鏈的摩檫力和尾門自身的重力為阻力，在后期的標(biāo)定過程中，鉸鏈和尾門的工藝一致性影響尾門開啟的響應(yīng)時間。圖5所示為自動尾門開啟功能的依賴關(guān)系，為了簡單起見，僅僅把部分零件整理出來。
· 腳踢傳感器
· 尾門鎖
· 尾門升降電機(jī)
· 鉸鏈
· 電動尾門控制器
· 車輛防盜系統(tǒng)
最后，將功能按行排序，零件按列排序，畫成矩陣圖，并且在矩陣上將功能和零件的關(guān)聯(lián)點(diǎn)用圓圈標(biāo)識出來。此外還可整理出一張表格，用于定義依賴關(guān)系的信號。
3.3 使用依賴矩陣
在整個開發(fā)過程中，使用依賴矩陣進(jìn)行了信號矩陣的校核，沒有功能需要的信號就會被標(biāo)識出來，根據(jù)是否有功能預(yù)留作為判斷依據(jù)，來討論并決定是否需要刪除。除了上述提到的系統(tǒng)層需求抽取之后，根據(jù)依賴矩陣，可以快速進(jìn)行功能成熟度的評估和軟件問題的原因分析。
3.4 組織和人員分工
在需求開發(fā)過程中，本文建議可以在系統(tǒng)工程師配合架構(gòu)團(tuán)隊(duì)，對于各域的功能架構(gòu)進(jìn)行統(tǒng)一開發(fā)管理。觀察到有些整車廠學(xué)習(xí)互聯(lián)網(wǎng)行業(yè)的經(jīng)驗(yàn)，由功能開發(fā)工程師主導(dǎo)功能開發(fā)、系統(tǒng)設(shè)計(jì)和零件開發(fā)，但效果不是太好，分析其原因有以下兩點(diǎn)：
（1） 互聯(lián)網(wǎng)產(chǎn)品不需要考慮硬件，更不用說機(jī)電系統(tǒng)的限制，只要把軟件邏輯實(shí)現(xiàn)就行；
（2） 互聯(lián)網(wǎng)產(chǎn)品經(jīng)理也是從軟件開發(fā)成長起來的，所以和工程師進(jìn)行需求交流比較順暢。
而系統(tǒng)工程師來牽頭開發(fā)工作，就能利用他們的系統(tǒng)思維和嚴(yán)謹(jǐn)工作方式來協(xié)助擅長創(chuàng)意和體驗(yàn)的功能開發(fā)工程師來完善需求，有效地實(shí)現(xiàn)功能落地。
在開發(fā)人員比較充足的情況下，也推薦單獨(dú)定義功能架構(gòu)師角色，如圖6所示，這樣系統(tǒng)工程師可以更加專注于系統(tǒng)層中零件的技術(shù)方案，而功能架構(gòu)師則關(guān)注系統(tǒng)的外部功能或者行為表現(xiàn)。
4 結(jié)論與展望
功能架構(gòu)展示了需求工程的一種全新視角，利用功能的生命周期進(jìn)行需求的系統(tǒng)化整理，通過電子尾門功能的案例和吉利汽車浩瀚架構(gòu)的開發(fā)實(shí)踐，完整地提出了整套功能架構(gòu)方法論在工程實(shí)踐中的資源和需求組織原則，具備對行業(yè)進(jìn)行架構(gòu)開發(fā)的實(shí)際指導(dǎo)作用。
在當(dāng)前軟件定義汽車的背景下，電子電氣系統(tǒng)的開發(fā)發(fā)生了深刻的變化。
首先，SOA面向服務(wù)架構(gòu)正在興起，如圖7所示，通過功能架構(gòu)建模，將功能顆粒度細(xì)化，可以快速地封裝成為原子化的服務(wù)，而依賴關(guān)系可以作為服務(wù)訂閱和發(fā)布機(jī)制的原則基礎(chǔ)。
其次，敏捷開發(fā)流程相對于傳統(tǒng)的迭代開發(fā)流程更加有效，整車項(xiàng)目開發(fā)要求在短時間內(nèi)進(jìn)行功能交付，細(xì)化的功能需求將有利于更具有效地進(jìn)行兩周的沖刺計(jì)劃。圖8所示為一種敏捷模塊釋放計(jì)劃，利用依賴矩陣可以有的放矢地進(jìn)行釋放節(jié)奏把控，按照功能計(jì)劃更加高效和靈活地實(shí)施開發(fā)計(jì)劃。
再次，結(jié)合電子電氣架構(gòu)向中央化計(jì)算平臺的演進(jìn)，以及軟件自研和SOA架構(gòu)的推廣，將會使得軟件的復(fù)用變得簡單。功能架構(gòu)將軟件模塊和功能關(guān)聯(lián)，可以將產(chǎn)品規(guī)劃和軟件開發(fā)都集中到統(tǒng)一平臺上，如圖9所示。
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點(diǎn)擊舉報(bào)。
