功能架構(gòu)在電子電氣架構(gòu)開發(fā)中的應用和實踐

在軟件定義汽車的時代，功能體驗日新月異，采用面向信號的架構(gòu)開發(fā)模式不能滿足用戶對于功能快速交付的期待，正初步地被面向服務架構(gòu)所取代。本文討論了面向功能開發(fā)流程中的核心元素，以及功能、系統(tǒng)和零件之間的關(guān)系，提出了在系統(tǒng)層建立以功能架構(gòu)為基礎的建模方法。同時結(jié)合吉利汽車的開發(fā)實踐經(jīng)驗，提出功能導向開發(fā)模式的組織分工，建議由系統(tǒng)工程師來主抓功能架構(gòu)在系統(tǒng)層建模并推動落地。最后展望了功能架構(gòu)在面向服務架構(gòu)和敏捷開發(fā)流程中的重要作用。

前言

隨著電動化、共享化、智能化和網(wǎng)聯(lián)化時代的到來，用戶的需求與日俱增，豐富的應用場景和個性的駕乘體驗驅(qū)動著整車電子和軟件進行快速地迭代和創(chuàng)新。2010年生產(chǎn)的一臺豪華轎車具備800個整車功能，而在2007年這個數(shù)量只有270個。隨著整車算力的提升，信息安全、功能安全要求也在提高，代碼量還會快速提升。當前豪華車輛代碼已經(jīng)能達到2~3億行，軟件在進行快速迭代的同時，也增加其在整車價值鏈中的比重，根據(jù)Apostu等的預測，軟件創(chuàng)造的價值在2030年將達到整車的30%。在當今存量市場競爭的背景下，各整車廠都在積極地推出架構(gòu)平臺，比如：大眾汽車的MEB，豐田汽車TGNA和吉利汽車的SEA架構(gòu)，依托架構(gòu)進行造車，用于控制成本，提高競爭力。電子電氣架構(gòu)作為整車功能的基礎平臺，其可擴展性將決定各整車廠在未來軟件定義汽車賽道上的競爭力。如何在電子電氣架構(gòu)上快速進行功能的開發(fā)和擴展，是業(yè)界共同的挑戰(zhàn)。

1 面向功能開發(fā)模式

現(xiàn)代汽車電子電氣架構(gòu)通過各類總線至少可以連接150個控制器，并且能部署300萬多項功能。要整體管理這樣規(guī)模的系統(tǒng)，僅通過網(wǎng)絡架構(gòu)和系統(tǒng)架構(gòu)來梳理是無法掌握功能之間的依賴關(guān)系。網(wǎng)絡架構(gòu)從通信的維度定義各個控制器之間的信號矩陣，而系統(tǒng)架構(gòu)從零件分工的維度明確它們之間的接口關(guān)系，其核心都是管理零件與零件之間的依賴關(guān)系。這就需要立足于功能，重構(gòu)其在電子電氣架構(gòu)上的開發(fā)邏輯。

面向功能開發(fā)模式強調(diào)從用戶使用場景出發(fā)，全面分析用戶需求，定義功能特征，最終通過零件來實現(xiàn)，執(zhí)行功能實現(xiàn)的零件包括控制器、傳感器、執(zhí)行器、開關(guān)和顯示器等。功能需求在創(chuàng)建時顆粒度大小不一，通過層層傳遞后，需求內(nèi)容也會隨著關(guān)注重點的不同而被誤解，最后導致功能策劃和功能實現(xiàn)效果不一致。為了彌補功能需求理解差異，需要引入系統(tǒng)層來捋清功能和零件的映射關(guān)系，如圖1所示，起到承上啟下的作用。業(yè)內(nèi)對系統(tǒng)層的定義比較抽象和寬泛，在實際工作中不具備可操作性，反而額外增加了需求開發(fā)和維護的溝通開銷。

功能層的需求捕獲來自于用戶的使用場景，目的在于明確功能價值，控制器層的需求輸出給供應商(內(nèi)部或者外部供應商)開展開發(fā)工作，目的在于選擇技術(shù)方案。因此，系統(tǒng)層的需求工程目的就是將功能和零件統(tǒng)一關(guān)聯(lián)起來，主要起到以下兩方面的作用：

(1)引導功能場景進行具體形象化，體驗方式進行精細化，并提煉成技術(shù)需求語言;

(2)指導零件技術(shù)方案選型，將功能需求分配到零件中去，并且明確零件在功能實現(xiàn)過程中的作用?？紤]網(wǎng)絡架構(gòu)的約束條件，在功能策劃階段，就能判斷功能實現(xiàn)的可行性并預估開發(fā)的成本和時間，能為功能決策提供相對可靠的依據(jù)。

1.1 功能、系統(tǒng)和零件的矩陣關(guān)系

為了更好地理解面向功能開發(fā)的流程，首先需要梳理清楚功能、系統(tǒng)和零件的關(guān)系。這3個術(shù)語的定義都整理在表 1~表 3中，同時增加了中文的翻譯。

解讀完術(shù)語定義并結(jié)合吉利汽車在開發(fā)中的工作實踐，本文建議采用矩陣方式來重新定義三者關(guān)系，在工作組織關(guān)系上則沿用分層結(jié)構(gòu)來建立上下游關(guān)系?？刂破魇钦嚤容^特殊的零件，考慮到軟件基本上都集成在控制器中，因此在圖 2中使用控制器來代替零件。

功能、系統(tǒng)和控制器三者的矩陣依賴關(guān)系放在整車環(huán)境下進行定義，可以表述為：在整車制造維度上，整車由單體零件組裝而來;在整車功能維度上，用戶體驗是由單項功能組合呈現(xiàn);系統(tǒng)從管理維度，將功能分門別類進行組合?？紤]到整車功能開發(fā)往往從特色功能的定義開始，故作表4所示定義。

1.2 系統(tǒng)對功能的完善

特色功能往往通過創(chuàng)新手段(比如：頭腦風暴，設計思維)或者對標而捕獲，并形成一個概念或者愿景表述，通過功能層的需求抽取，逐步地形成使用場景。在系統(tǒng)層上，面向功能場景進行建模，使用用例圖、狀態(tài)機、時序圖等方法進行分析，就能將功能點擴展為功能族，進而形成完整的功能清單。這份功能清單又作為新一輪的輸入進行市場調(diào)研，然后確定每項功能的價值和優(yōu)先級。經(jīng)過多輪迭代和優(yōu)化，整車功能定義就能層次清晰，場景目標明確，并能全局把控用戶的目標期待，功能需求的提取是一個系統(tǒng)工程。

1.3 系統(tǒng)對零件的約束

零件的開發(fā)需要完整而清晰的功能需求和性能指標，這樣才能有效地避免與需求反復確認。系統(tǒng)層在進行功能分配之前，需要了解零件的性能和處理能力，這樣就能有效地避免分配下來的功能，在零件上無法實現(xiàn)的問題。結(jié)合系統(tǒng)層利用零件和零件之間的分工方式定義出來的最優(yōu)接口方案，比如信號的周期和類型，就能明確地指導觸發(fā)機制的選擇。在系統(tǒng)層面進行建模仿真能有效地預估功能響應時間和動作幅度，并能給出帶有數(shù)據(jù)支持的零件開發(fā)目標。

考慮到當前功能安全和信息安全的要求，系統(tǒng)失效模式的分析工作，可以框定零件FMEA的工作重點，并能指導零件的異常處理機制部署。

1.4 系統(tǒng)對架構(gòu)的補充

網(wǎng)絡架構(gòu)的開發(fā)模式要求架構(gòu)團隊輸出網(wǎng)絡拓撲圖、通信矩陣和診斷數(shù)據(jù)，但是對于功能的開發(fā)僅僅停留在信號層面。表5所示為架構(gòu)的定義，通過系統(tǒng)層的需求定義，建立功能和零件的依賴矩陣，這樣不僅能有效地協(xié)同各個零件同步開發(fā)進程，快速高質(zhì)量地交付，同時也能有效地把控功能的變更，主動進行功能重構(gòu)，迅速地適應需求的變化。系統(tǒng)層需求的建模分析結(jié)果，從數(shù)據(jù)也能支持架構(gòu)拓撲結(jié)構(gòu)、電源模式管理和網(wǎng)絡休眠喚醒機制等基礎性功能優(yōu)化的決策。

2 功能架構(gòu)模型

功能驅(qū)動帶來軟件復雜度的提升，嚴重地拖延了整車廠的創(chuàng)新和新功能交付，這就需要研究功能開發(fā)的關(guān)鍵路徑并找到優(yōu)化方向。結(jié)合吉利汽車的實踐經(jīng)驗，使用功能架構(gòu)模型進行系統(tǒng)層建模，由此有效地管理依賴關(guān)系，進而提高研發(fā)效率。

2.1 功能架構(gòu)概念

功能架構(gòu)是在系統(tǒng)層對于功能進行關(guān)系建模，根據(jù)前期開發(fā)的經(jīng)驗，在實際開發(fā)工作中主要關(guān)注以下3個維度工作：

(1) 功能結(jié)構(gòu)：功能細化并描述功能對于系統(tǒng)的行為要求;

(2) 映射關(guān)系：描寫功能和零件通過接口定義的依賴關(guān)系;

(3) 零件角色：統(tǒng)一和擴展功能對于零件的分工要求。圖3把功能架構(gòu)的3個維度內(nèi)容有機地結(jié)合起來：功能和零件的依賴關(guān)系通過交叉圓點展示出來，零件在功能架構(gòu)中的作用也能通過查看三角標記而得知，比如觸發(fā)條件、前提條件。針對系統(tǒng)層的功能實現(xiàn)邏輯，還能定義系統(tǒng)的類型，挖掘出系統(tǒng)層級的邏輯需求。系統(tǒng)的類型如表 6所示。

針對多輸入系統(tǒng)，就需要對輸入進行優(yōu)先級定義，并且在邏輯上建立仲裁機制，而對于多輸出系統(tǒng)，就需要定義各個零件的響應同步性;此外這也大大方便了功能安全的評審，不僅可以了解失效之后的功能安全狀態(tài)，也能明確零件單點失效率如何影響功能的降級行為。

2.2 功能狀態(tài)定義

利用功能架構(gòu)模型進行系統(tǒng)層建模，就需要統(tǒng)一定義功能的狀態(tài)，如表7所示。統(tǒng)一建模語言，能方便開發(fā)團隊進行技術(shù)交流和討論。本文只標準化功能狀態(tài)，但不約束功能行為，也就是說單體功能可以根據(jù)場景的需求對于功能狀態(tài)進行不同行為規(guī)范，比如燈光功能的Off指的是關(guān)燈，而玻璃升降器的Off指的是停止運動。利用功能架構(gòu)進行系統(tǒng)建模時，只關(guān)注功能的狀態(tài)遷移條件，而具體的控制行為或者算法實現(xiàn)方式，比如采用PID控制還是模糊控制，可由功能執(zhí)行的主要零件工程師進行選擇。這樣分工，在概念設計階段能高效地定義系統(tǒng)行為，不用陷入太多技術(shù)細節(jié)討論，同時也能激活零件開發(fā)工程師的創(chuàng)造力，只要達成開發(fā)目標，就可以各自自由進行算法和程序的設計。

2.3 功能激勵條件定義

通過外部或者內(nèi)部的事件可以改變功能的狀態(tài)，這些事件可以按照表8來進行分類，考慮到供應鏈全球化趨勢，需求規(guī)范編寫時，也添加了英文名。

圖4表示功能狀態(tài)和條件關(guān)系，針對每個功能，如果有多個事件或者狀態(tài)組合成為一個條件，就需要把它們的組合關(guān)系也表示出來，比如邏輯“與”和邏輯“或”的關(guān)系。

3 應用與實踐

在吉利浩瀚架構(gòu)上進行了實踐，在此選擇腳踢開尾門的功能作為案例進行說明。此功能允許車主利用腳來非接觸式地開啟后備箱。

3.1 用戶場景定義

在用戶場景階段，僅僅關(guān)注在什么情況下(When)，解決了什么問題(What)，但是對于問題怎么解決(How)不進行討論。

根據(jù)市場部的調(diào)研以及功能開發(fā)工程師的對標，腳踢開啟尾門功能按照卡諾模型的分類是屬于期望型功能，功能能給用戶帶來正向的使用價值，幫助客戶解決了不方便用手開啟尾門的場景，這種場景在超市購物、搬家和運輸過程中發(fā)生的概率也比較高。當然這個功能依賴于電動尾門開啟和無鑰匙進入功能，并且一般部署在SUV車型之上。

3.2 搭建需求框架

首先，對于功能進行結(jié)構(gòu)拆解，由于尾門開啟是一個動作執(zhí)行過程，可以根據(jù)動作的類型對于功能繼續(xù)細分，比如：

· 尾門解鎖

· 尾門升程運動

· 尾門停止

其次，羅列尾門模塊中的零件清單，這個清單不僅僅包含控制器、開關(guān)、傳感器、電機等機電零件，甚至也可以將關(guān)聯(lián)的機械零件如鉸鏈也放在清單中。在尾門的升程運動過程中，電機負責提供動力，而鉸鏈的摩檫力和尾門自身的重力為阻力，在后期的標定過程中，鉸鏈和尾門的工藝一致性影響尾門開啟的響應時間。圖5所示為自動尾門開啟功能的依賴關(guān)系，為了簡單起見，僅僅把部分零件整理出來。

· 腳踢傳感器· 尾門鎖· 尾門升降電機· 鉸鏈· 電動尾門控制器· 車輛防盜系統(tǒng)最后，將功能按行排序，零件按列排序，畫成矩陣圖，并且在矩陣上將功能和零件的關(guān)聯(lián)點用圓圈標識出來。此外還可整理出一張表格，用于定義依賴關(guān)系的信號。

3.3 使用依賴矩陣

在整個開發(fā)過程中，使用依賴矩陣進行了信號矩陣的校核，沒有功能需要的信號就會被標識出來，根據(jù)是否有功能預留作為判斷依據(jù)，來討論并決定是否需要刪除。除了上述提到的系統(tǒng)層需求抽取之后，根據(jù)依賴矩陣，可以快速進行功能成熟度的評估和軟件問題的原因分析。

3.4 組織和人員分工

在需求開發(fā)過程中，本文建議可以在系統(tǒng)工程師配合架構(gòu)團隊，對于各域的功能架構(gòu)進行統(tǒng)一開發(fā)管理。觀察到有些整車廠學習互聯(lián)網(wǎng)行業(yè)的經(jīng)驗，由功能開發(fā)工程師主導功能開發(fā)、系統(tǒng)設計和零件開發(fā)，但效果不是太好，分析其原因有以下兩點：

(1) 互聯(lián)網(wǎng)產(chǎn)品不需要考慮硬件，更不用說機電系統(tǒng)的限制，只要把軟件邏輯實現(xiàn)就行;

(2) 互聯(lián)網(wǎng)產(chǎn)品經(jīng)理也是從軟件開發(fā)成長起來的，所以和工程師進行需求交流比較順暢。

而系統(tǒng)工程師來牽頭開發(fā)工作，就能利用他們的系統(tǒng)思維和嚴謹工作方式來協(xié)助擅長創(chuàng)意和體驗的功能開發(fā)工程師來完善需求，有效地實現(xiàn)功能落地。

在開發(fā)人員比較充足的情況下，也推薦單獨定義功能架構(gòu)師角色，如圖6所示，這樣系統(tǒng)工程師可以更加專注于系統(tǒng)層中零件的技術(shù)方案，而功能架構(gòu)師則關(guān)注系統(tǒng)的外部功能或者行為表現(xiàn)。

4 結(jié)論與展望

功能架構(gòu)展示了需求工程的一種全新視角，利用功能的生命周期進行需求的系統(tǒng)化整理，通過電子尾門功能的案例和吉利汽車浩瀚架構(gòu)的開發(fā)實踐，完整地提出了整套功能架構(gòu)方法論在工程實踐中的資源和需求組織原則，具備對行業(yè)進行架構(gòu)開發(fā)的實際指導作用。

在當前軟件定義汽車的背景下，電子電氣系統(tǒng)的開發(fā)發(fā)生了深刻的變化。

首先，SOA面向服務架構(gòu)正在興起，如圖7所示，通過功能架構(gòu)建模，將功能顆粒度細化，可以快速地封裝成為原子化的服務，而依賴關(guān)系可以作為服務訂閱和發(fā)布機制的原則基礎。

其次，敏捷開發(fā)流程相對于傳統(tǒng)的迭代開發(fā)流程更加有效，整車項目開發(fā)要求在短時間內(nèi)進行功能交付，細化的功能需求將有利于更具有效地進行兩周的沖刺計劃。圖8所示為一種敏捷模塊釋放計劃，利用依賴矩陣可以有的放矢地進行釋放節(jié)奏把控，按照功能計劃更加高效和靈活地實施開發(fā)計劃。