電子電氣架構的正向開發流程

國外的OEM在多年的Know-how積累下，其在規劃新一代電子電氣架構平臺時，基本完全按照正向的流程來開發，例如VW的MEB E3架構，Volvo的SPA2等，伴隨其正向電子電氣架構開發的需要，誕生了強大的工具供應商，比如Vector的PREEvision，其囊括了電子電氣開發的整個流程，從需求分析、邏輯功能架構、軟件架構、硬件架構到電氣原理設計、線束原理設計、幾何拓撲設計以及線束2D圖紙設計，同時包含通訊設計、功能安全開發、變形管理等，提供了電子電氣開發的集成平臺，需求工程師、功能工程師、軟件工程師，通信工程師、架構工程師、電氣工程師、功能安全工程師可以在這個平臺彼此協作開發，數據無縫傳遞，每個專業的輸入可通過上游設計的輸出數據重構生成，數據可在全流程追溯，在應對目前電子電氣的復雜性上確實具有領先性。

下面以PREEvision為例來簡單介紹下電子電氣架構的正向開發流程是什么樣的：

1、需求工程和需求管理

在電子電氣架構開發的概念階段，我們需要明確開發的目標及范圍，需要收集客戶對車輛的功能需求、法規需求以及其他非功能需求，在這個階段涉及兩個重要的概念：

lCustomer Feature：在高層級描述車輛的特征，通常是客戶可以感知的功能，比如自動空調，自動啟停，自動泊車、自適應巡航等，

lRequirements:需求Requirement 是對Customer Feature的進一步細化，包括功能需求，技術需求（工作溫度范圍等），法規需求（排放法規等）；

同時可以將Requirement和Customer Feature進行映射關聯，從而實現追溯，另外Customer Feature和Requirement在向下映射過程也是有差別的，Customer Feature通常和邏輯架構層（Logical Function Architecture）的元素(Activity Chain)進行映射,而Requirement通常和軟件架構層（Software Architecture）的元素以及硬件架構層（Harware Architecture）的元素進行映射。

2、邏輯功能架構（Logical Function Archtecture）

邏輯功能架構設計階段，就是根據需求階段定義的Customer Feature，為每一個Feature設計功能的實現邏輯，設計的Activity Chain提供了一個功能的抽象視圖，只從功能實現的角度劃分Sensor（Input）、Logical Function(Process)、Actuator（Output），并不關心具體的軟件實現、以及硬件實現，在該階段設計完成的邏輯組件（Logical Component）會分配到硬件架構中的組件（ECU、傳感器、執行器等）以及軟件架構中組件（Application Software Component等）。

3、軟件架構（Software Architecture）

在汽車行業嵌入式軟件開發領域繞不開AUTOSAR（Automotive Open System Architecture）,其定義了一套分布式的、功能驅動的汽車電子軟件開發方法和電子控制單元上的軟件架構標準方案，AUTOSAR的核心思想“統一標準、分散實現、集成配置”，即提供統一、開放的軟件架構標準和平臺，軟件構建在不同的汽車平臺上復用，應用軟件整合到ECU 中，建立獨立于硬件的、分層的軟件架構，針對AUTOSAR Classic的系統和軟件架構設計在PREEvision中可以分為如下步驟：

同時，在目前SDV趨勢下，PREEvision同時支持面向服務的架構設計（SOA）以及Adaptive AutoSAR系統和軟架構設計，并提供SOA&Ethernet Explorer（Classic Platform）和Adaptive AutoSAR Explorer（Adaptive Platform）支持新的設計需求。

4、硬件架構（Hardware Architecture）

硬件架構的設計分為三層：硬件組件（Hardware components）和網絡拓撲（Network topology），電氣原理和線束原理，

l硬件組件（Hardware Component）架構，設計硬件組件（例如ECU、傳感器、執行器）之間的硬線連接，包括硬線信號（PWM、高低電平等），總線連接（CANFD/CAN/LIN等），以及電源連接和接地連接，另外也設計ECU內部的細節，比如MCU、SBC、RAM等；

l網絡拓撲（Network Topology）

l電氣原理（Electric Circuit）,電氣原理層將硬件架構層的數據進行重構，重新定義硬件組件之間的連接，并關注與線束設計相關的電氣屬性，例如電源供應、接地連接等，其可設計電源分配的保險、繼電器以及接地分配電路。

l線束原理（Wiring Harness）將電氣原理數據進行細化，將邏輯連接轉換為導線，同時添加導線之間的焊接點（Splice），內部連接器（Inline），端子（Terminal），線束端連接器（Female Connector）,

5、幾何拓撲（Geometric Topology）

幾何拓撲層是整車電器的2.5D布局視圖，其可以通過將3D CAD工具（Dassault Catia等）設計完成的3D線束通過KBL格式導入，展平為2D視圖，表達各電器的安裝位置，線束分段，然后將線束原理層中各組件映射到幾何拓撲層，從而進行導線的路由規劃，從而為最終的架構評估提供線束的長度、重量等數據支撐。

6、線束設計（Harness Design）

將幾何拓撲中完成導線路由的線束總成，在Wire Harness Diagram中進行數據重構，同時添加卡扣、膠帶以及其他固定件、防護件，可生成線束2D圖紙，指導線束供應商進行線束的工藝轉化，然后進行線束的生產和制造。

7、通訊設計（Communication）

在完成軟件組件到硬件的Mapping后，可進行信號的路由，并進行網絡通訊設計，PREEvision提供了多種通信設計編輯器來應對同步的通信類型，比如CAN Bus Editor,LIN Scheduling Editor,FlexRay Schedulling 和Ethernet Explorer。

上述基于模型的系統工程方法（MBSE）同時可導出文檔，作為供應商開發的輸入，比如可導出ECU的軟件需求規范SWRS（Software Requirement Specification）用于指導供應商進行軟件設計，導出ARXML文件用于供應商生成應用層軟件框架代碼，生成DBC/LDF文件用于總線仿真及測試等。

國內OEM的電子電氣架構開發過程

而國內OEM通常采用基于文檔的電子電氣架構的開發流程，基于模型的正向開發流程通常很難真正的實施下去的，因為在過去幾十年分布式架構下形成的OEM、Tier1的產業供應鏈是很固化的，目前市面上車型搭載的ECU大部分都是由國外頭部Tier1在供應，特別是在底盤、動力領域，ESP、Ibooster、ECM這些零部件的核心Know-how都掌握在Bosch、Continental、APTIV等掌握在這些零部件巨頭手里，國內OEM的電子電氣架構團隊自己的積累太少，并不能在此領域提出足夠支配供應商的需求，另外這些供應商開發的零部件基本是平臺化的，相同的零件應用在多家主機廠的車型上，收發信號都是定義好OEM根據需求信號進行匹配，因此我們的架構團隊寫的功能規范（子系統功能規范），迫于無奈要根據零部件實際的功能情況去更改適配，架構輸出規范的作用更多的是梳理目前整車已有的功能，而不是去正向設計整車的功能，但是近些年我們國內的OEM也在一直成長，并嘗試建立正向的電子電子電氣架構開發流程：

l在需求階段進行市場調研、法規標準分析、競品分析、新技術分析、基礎平臺分析，定義整車架構目標，輸出Function List，并針對每個功能編制功能需求規范FRS（Function Requirement Spefication）,進行功能描述，場景定義，功能系統框圖設計等；

l在功能實現階段，把功能需求分解并分配給子系統設計團隊（功能需求+子系統交互圖）；

l在子系統設計階段，輸出子系統需求描述SRD（System Requirement Description）

l在零部件設計階段輸出 零部件技術規范CTS（Component Technical Spefication）

通過上述規范的輸出，國內OEM掌握的Know-how也越來越多，并在新一代電子電氣架構中，逐漸掌握主動權，不管是Domain架構還是Zonal架構，要實現SOA是大家達成的共識，同時在新的面向服務的架構中，主機廠要掌握車端、和云端可以提供的服務，并將服務開放給第三方應用開發者，從而創建SOA的開發生態，因此作為主機廠的電子電氣架構團隊在新的SOA趨勢下，其作用顯得越來越重要，其要從整車功能需求來設計整車的服務，并將服務分配到不同的Domain，由不同Domain的應用軟件開發團隊來實現。

面向服務的電子電氣架構開發方法

面向服務的架構SOA（Service-Orientied Architecture）是一種軟件設計范式，它將應用程序的不同功能單元（稱為服務）進行拆分，并通過這些服務之間良好定義的接口和協議聯系起來，接口采用中立的方式進行定義，他獨立于實現服務的硬件平臺、操作系統和編程語言，

這使得構建在各種系統中的服務可以以一種統一和通用的方式進行交互。

設計范式是設計解決方案邏輯的一種方法，在構建分布式解決方案邏輯時，設計方法通過一種稱為“關注點分離”的軟件工程理論實現，簡而言之，這個理論說明，將更大的問題分解為一組較小的問題或關注點時，這個問題就能得到更有效的解決，這讓我們產生了將解決方案邏輯劃分為多個功能的想法，每個功能都旨在解決單一的關注點，相關功能可以分組為解決方案邏輯單元。分布式解決方案邏輯存在不同的設計范式，面向服務體現在：面向服務執行關注點分離的方式以及如何塑造具有特定特性和支持特定目標狀態解決方案邏輯的單個單元。從根本上說，面向服務將合適的解決方案邏輯單元整合為企業資源，其可以被設計為解決即時問題，同時對更大的問題保持不可知，這就為我們提供了不斷的機會來重新利用那些單元內的功能并解決其他問題。

在面向服務持續應用于軟件程序設計時，一系列戰略目標和優勢共同代表了我們所期望實現的目標狀態，理解這些目標和優勢是非常有益的，因為它們可以為我們提供連續不斷的總體背景和理由，以維持我們長期面向服務的投入。

l增加本征互操作性:即增加數據共享，軟件程序的互操作性越高，其之間的信息交換越容易；

l增強聯合:即服務的聯合，軟件資源和應用程序聯合在一起，同時保持其各自的自主性和自治性；

l增加供應商的多元化選擇：即供應商多元化能力，指組織必須選擇“最佳品種”的供應商產品和技術創新；

l同步提升業務與技術領域：即應用程序的設計和實現不僅要滿足初始業務需求，也應滿足未來隨業務性質和方向變化時的也業務需求；

l提高投資回報率：即衡量自動化解決方案投資回報率（ROI）是決定應用程序或系統實際成本效益的關鍵因素；

l提高組織的業務敏捷性：即組織能夠對變化做出反應的效率，以適應行業變化并超越競爭對手；

l減少研發成本：即減少浪費和冗余，縮小規模和運營成本，減少與其治理和演進相關開銷等。

1、面向服務的設計原則

(1)標準化服務合約原則

面向服務架構體系中，服務通過一個服務合約來表達他們的目標和能力，標準化服務合作設計原則是面向服務中最基本的原則之一，其本質上是在設計一個服務的公開技術接口，或評估作為服務正式合約的一部分而發布的內容特性和數量時，給予特殊考慮指導方法。

服務合約設計時，需要重點考慮服務能力的表達方式、數據類型和數據模型，以及服務策略、服務端點的一致性、可靠性和可治理性。

(2)服務松耦合原則

耦合是指兩個事務之間的關聯和聯系，這一原則主張在服務的邊界之內和之外創建特定類型的關系時，要始終強調減少服務合約、服務實現和服務消費者之間的依賴關系（車載領域尤其需要關注感知、決策和執行的耦合關系），在服務設計過程中存在各種數據類型的耦合關系，每一個都會影響合約的內容和粒度，需要依靠原則指導和實際經驗獲得一個適當的耦合級別。

(3)服務抽象原則

這個原則強調盡量隱藏服務的更多細節，服務需要一致地抽象關于技術、邏輯和功能的相關信息，不會展現給外部世界（服務邏輯開發上之外的世界），屆時，服務合約需要抽象僅僅包含服務不要對外發布公開的信息，如必要的交互需求、約束和必須的服務元數據。

(4)服務可復用性原則

服務可復用性原則強調在無關的功能性上下文環境中，把服務定位為企業的資源，確保服務是無關單個應用和業務流程，具有無關功能性和通用性，可以在無關服務環境中被定義，并且可以保證它們能促進必要的復用環境，可以被多個消費者程序提供訪問。

(5)服務自治性原則

為了讓服務能夠持續可靠地提供服務能力，底層的方案邏輯要求對環境和資源進行相當程度的控制，這一原則涉及服務邏輯設計及服務實際實施環境的各類問題，合理利用可以增加服務的可靠性和行為的可預測性的設計特性，可以對其他設計原則在實際開發過程中的有效應用提供足夠的支持。在車載領域，由于涉及不同安全等級和實時性要求，尤其要關注隔離級別和服務規范化，針對不同應用領域一起可以達到各自適合程度的自治，對于經常需要共享的可復用服務來說尤其重要。

(6)服務無狀態性原則

就服務而言，管理過多的狀態信息會導致服務可用性和伸縮性潛力的破壞，在理想情況下，服務只應該在必要時保持狀態；

(7)服務可發現性原則

將服務定位為可服用資產時，若復用機會出現，服務可以被發現并理解。服務發現機制（SOME/IP-SD等）和服務自身的設計（尤其服務端點）都需要將服務的“交流質量”和其自身能力考慮在內。

(8)服務可組合性原則

面向服務的解決方案的復雜程度在持續增長，位于其下的服務組合配置的復雜度也在持續增長，車載領域也面臨同樣的問題，能夠有效組合服務能力是面向服務計算的一些基本目標的關鍵要求，復雜的服務組合對服務設計提出了要求，服務有望作為有效的組合成員參與，無論他們是否需要立即加入組合。

2、面向服務的設計方法

在面向服務的架構開發時，分析和設計服務架構的過程是從客戶需求到SOA架構產出的分析過程，相對于傳統汽車軟件開發采用的基于功能分解的面向過程分析方法，“用例驅動的開發方法”和“面向服務架構的設計方法”是SOA軟件架構開發的兩個主要特點。

（1）需求分析

用例（Use Case）驅動的開發方法指從用戶的角度而非開發人員的角度考慮功能需求和系統實現，重視從系統外部觀察對系統的使用，由用例驅動的開發活動，可建立需求和系統功能之間清晰的追溯關系，更好的應對智能汽車產品需求的快速迭代更新。

（2）功能設計

在功能設計階段我們用產品能力（Product Capability）描述功能實現的邏輯，產品能力是連接功能設計和軟件設計的橋梁，在功能設計層面，借助UML動態圖（序列圖、活動圖、狀態機）運用產品能力PC描述每個UseCase的功能實現鏈路；在軟件架構設計階段，通過將產品能力分配到不同的軟件模塊，從而明確各軟件模塊的職責范圍，作為軟件開發的輸入，同時各軟件模塊中的服務也根據PC描述的功能范圍來設計。

（3）軟件架構設計

軟件分層

為了更好地管理依賴關系和構建軟件架構，應該使用分層軟件架構，對于SOA的應用軟件架構分層可采用如下原則:

a.分離HMI和核心應用軟件

HMI行為比核心應用功能更容易改變，因此，將核心應用軟件和HMI之間的分離將使設計更容易更改，特別是在開發期間的后期更改，或在HMI適應新產品時，此外，開發核心應用軟件和HMI設計需要不同的的能力技能，分開時應該更容易處理，基本的策略是將HMI功能與其他應用軟件（功能）的核心部分分離，為了實現這一點，MVC(Model-View-Controller)模式需要被使用，這意味著核心應用軟件不應該意識到任何HMI，而是HMI應該對模型做出反應并呈現給用戶，用戶輸入由Controller處理，Controller解釋用戶的意圖并操作模型。

b.分離傳感器/執行器軟件和應用軟件

將硬件邏輯，例如傳感器和執行器邏輯與應用程序邏輯分開，以便能夠在中央系統中分配應用程序，同時保持傳感器/執行器盡可能的具體，這將促進能夠在應用程序之間使用SOA，及時傳感器和執行器不支持，更容易將傳感器/執行器作為現有組件來采購，從而降低價格；更容易處理中央系統的可變性；將戰略軟件與中央系統分開，以更好地控制，并在需要時更容易進行內部開發；此策略目的在于提高上層應用軟件關鍵功能的復用性，將依賴硬件的功能與邏輯控制功能分離。

c.分離的設備抽象層

這一層包含了對設備的抽象，即設備代理（Device Proxy）和設備驅動程序（Device Driver）,這里的模塊將在需要時，對信號到服務之間進行轉換，并處理設備層中的可變性，這一層不應該包含任何車輛功能，只管理設備，在這一層的Device Driver不允許直接彼此通信，必須通過DP或車輛控制層，DP和DD可以使用一些平臺服務，如日志、診斷等；

d.分離平臺服務和主應用軟件

與所有系統一樣，需要一些更偏向支持的功能，這是所有模塊都可以使用的公共服務，如日志記錄，資源管理等；

e.應用軟件分為多層

即便我們已經將HMI 、Platform Service、Sensor/actuator和Device Abstraction與核心應用進行分離，針對龐大的核心應用功能的開發，對于開發部門來講還是很復雜的，為了促進高效的開發工作，這個核心應用功能需要以某種方式進行分割，根據核心應用功能軟件特點，公司組織結構等，可根據需要將核心應用功能軟件劃分為多個層次：

-車輛應用層：這一層包含的軟件部件，對本車應用負有總體責任，例如如何使用各種能源策略的定義，他們更像是應用程序類型的SWC，使用其他層中的服務，而不向其他層提供服務接口；

-車輛協調層：這一層包含協調特定范圍內（Domain內）功能的軟件部件，例如協調不同類型的電氣能量的使用；

-車輛控制層：這一層包含控制功能范圍更有限的軟件部件，例如門窗控制，門鎖控制等，除分層外，核心應用功能，或部分的核心應用功能也可以根據開發組織進行分離，例如：Connectivity，Energy,Motion，Control,Safety,Body和Infotainment，不同的企業可以采用不同的定義方案。

(4)服務設計

a.服務分層

l硬件抽象服務：基于ECUs功能和硬件外圍設備（傳感器/執行器），定義硬件抽象服務，這些服務應該在軟件平臺級別提供。

l平臺核心服務：所有跨應用程序集群和域的公共服務都需要在軟件平臺級別定義和提供；

l域核心服務：在一個應用集群中，跨不同應用程序的公共服務應定義為域核心服務，

l應用程序服務：特定于系統的每個應用程序或功能的服務，需要定義為應用程序服務；

b.服務類型

根據服務提供功能的特點，可以分為基礎型服務與功能型服務，

l基礎型服務：提供與業務無關的通用系統服務能力，包括操作系統、基礎軟件、通用中間件提供的功能；

l功能型服務，提供具體業務功能相關的服務，包括與域控相關的專用中間件、應用層提供的功能。

c.服務框架

Service Framework是對通用基礎軟件的擴充，在基于不同種類的操作系統及基礎軟件平臺之上提供系統級服務調用及整車級功能設計視圖，其次對AutoSAR的服務管理框架進行擴展，向應用層提供更多基于服務開發需要的功能，最后提供基于引擎的動態服務配置方法，基于預設的靜態服務，通過云端對靜態服務進行編排，實現更加豐富的業務功能。

l原子服務：不可拆分的服務，一般為執行單一操作的功能，不同功能節點可以提供針對業務的原子服務；

lSOA+：基于AutoSAR的服務框架擴展，向應用層提供更多基于服務開發需要的功能，其中包括服務轉換、服務調試、服務同步、服務權限管理和基于Andorid的SOA協議棧；

l系統基礎服務：系統可以提供的基礎服務，體現該系統可以提供的能力，需要依賴通用基礎軟件提供的功能，可以通過API或服務的形式提供給上層，針對不同異構系統分別提供軟件包；

l整車級系統基礎服務：整車角度需要多個控制器協同實現的功能

l動態服務：基于原子服務及系統服務提供的功能進行組合，實現服務的級聯，包括動態服務配置接口：提供給調用者實現動態服務的可配置接口；動態服務引擎，根據配置接口的輸入，執行動態服務的核心功能。

d.服務定義

車載SOA軟件接口是服務提供者或使用者之間數據交換的定義，它定義了向使用者公開的服務的屬性、方法和事件等，服務定義定義服務之間的依賴關系，以及服務的接口（Require Interface Provide Interface）

(5)物理架構設計

定義整車的網絡拓撲以及硬件架構類型（功能域架構、中央計算單元+區域架構），綜合各家OEM的下一代電子電氣架構分析，車載計算單元+自動駕駛域控制器+智能座艙域控制器+區域控制器的架構形態被大多數的OEM所采用。

(6)網絡通信設計

可在PREEvision中定義SOME/IP服務矩陣，設計Machine，SWC to Machine Mapping, Machine Deployment,Application Deployment,Servcie Instance Design,可導出Service Interface Description ARXML文件，該文件可以包含一個或多個服務接口的詳細信息，如Method/Event/Property以及對應的數據類型等內容。該文件可以將服務接口信息準確的傳遞給其他工具，如DaVinci Adaptive IDE，用于生成服務接口的頭文件。

同時可導出Execution Manifest包含了Adaptive Application部署到目標AUTOSAR Adaptive平臺上所需的信息，比如進程啟動配置，進程與Machine的映射等內容，導出Machine Manifest包含Machine部署相關的信息，比如網絡配置信息，計算資源等，導出Service Instance Manifest包含基于服務的通信相關信息，如應用層及相應的傳輸層、網絡層通信參數信息。

(7)應用層軟件開發

將PREEvision導出的SWC Description ARXML文件導入MatLab Simunlink 創建模型框架，配置服務發現機制，確認AutoSAR屬性，生成代碼。

接下來需要利用基礎軟件供應商提供的開發工具（例如DaVinCi Adaptive tool Suite）和AP中間件（例如MICROSAR）進行集成、配置，詳細的過程我們后續再來探討。

以上簡單的描述了傳統電子電氣架構的開發過程，以及在新一代SOA架構中，我們采取的以用例驅動的，以服務設計為核心的電子電氣架構開發流程，在新的架構中需要探索新的適合每個OEM的開發方法，開發工具鏈以及與供應商的合作方式（包括芯片供應商、基礎軟件供應商、零部件供應商等），行業在變革，作為電子電氣架構工程師的我們應該直面困難和挫折，尋找一條清晰的發展道路。

審核編輯：郭婷