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

前言

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

1 面向功能開發模式

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

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

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

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

(2)指導零件技術方案選型，將功能需求分配到零件中去，并且明確零件在功能實現過程中的作用。考慮網絡架構的約束條件，在功能策劃階段，就能判斷功能實現的可行性并預估開發的成本和時間，能為功能決策提供相對可靠的依據。

1.1 功能、系統和零件的矩陣關系

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

解讀完術語定義并結合吉利汽車在開發中的工作實踐，本文建議采用矩陣方式來重新定義三者關系，在工作組織關系上則沿用分層結構來建立上下游關系。控制器是整車比較特殊的零件，考慮到軟件基本上都集成在控制器中，因此在圖 2中使用控制器來代替零件。

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

1.2 系統對功能的完善

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

1.3 系統對零件的約束

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

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

1.4 系統對架構的補充

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

2 功能架構模型

功能驅動帶來軟件復雜度的提升，嚴重地拖延了整車廠的創新和新功能交付，這就需要研究功能開發的關鍵路徑并找到優化方向。結合吉利汽車的實踐經驗，使用功能架構模型進行系統層建模，由此有效地管理依賴關系，進而提高研發效率。

2.1 功能架構概念

功能架構是在系統層對于功能進行關系建模，根據前期開發的經驗，在實際開發工作中主要關注以下3個維度工作：

(1) 功能結構：功能細化并描述功能對于系統的行為要求;

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

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

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

2.2 功能狀態定義

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

2.3 功能激勵條件定義

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

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

3 應用與實踐

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

3.1 用戶場景定義

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

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

3.2 搭建需求框架

首先，對于功能進行結構拆解，由于尾門開啟是一個動作執行過程，可以根據動作的類型對于功能繼續細分，比如：

· 尾門解鎖

· 尾門升程運動

· 尾門停止

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

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

3.3 使用依賴矩陣

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

3.4 組織和人員分工

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

(1) 互聯網產品不需要考慮硬件，更不用說機電系統的限制，只要把軟件邏輯實現就行;

(2) 互聯網產品經理也是從軟件開發成長起來的，所以和工程師進行需求交流比較順暢。

而系統工程師來牽頭開發工作，就能利用他們的系統思維和嚴謹工作方式來協助擅長創意和體驗的功能開發工程師來完善需求，有效地實現功能落地。

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

4 結論與展望

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

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

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

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

再次，結合電子電氣架構向中央化計算平臺的演進，以及軟件自研和SOA架構的推廣，將會使得軟件的復用變得簡單。功能架構將軟件模塊和功能關聯，可以將產品規劃和軟件開發都集中到統一平臺上，如圖9所示。

?

審核編輯：湯梓紅