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

國外的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的應用軟件開發團隊來實現。

審核編輯 ：李倩