電子電氣架構(gòu)正向開發(fā)流程介紹

電子電氣架構(gòu)的正向開發(fā)流程

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

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

1、需求工程和需求管理

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

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

lRequirements：需求Requirement 是對Customer Feature的進(jìn)一步細(xì)化，包括功能需求，技術(shù)需求（工作溫度范圍等），法規(guī)需求（排放法規(guī)等）；

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

2、邏輯功能架構(gòu)（Logical Function Archtecture）

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

3、軟件架構(gòu)（Software Architecture）

在汽車行業(yè)嵌入式軟件開發(fā)領(lǐng)域繞不開AUTOSAR（Automotive Open System Architecture），其定義了一套分布式的、功能驅(qū)動的汽車電子軟件開發(fā)方法和電子控制單元上的軟件架構(gòu)標(biāo)準(zhǔn)方案，AUTOSAR的核心思想“統(tǒng)一標(biāo)準(zhǔn)、分散實(shí)現(xiàn)、集成配置”，即提供統(tǒng)一、開放的軟件架構(gòu)標(biāo)準(zhǔn)和平臺，軟件構(gòu)建在不同的汽車平臺上復(fù)用，應(yīng)用軟件整合到ECU 中，建立獨(dú)立于硬件的、分層的軟件架構(gòu)，針對AUTOSAR Classic的系統(tǒng)和軟件架構(gòu)設(shè)計(jì)在PREEvision中可以分為如下步驟：

同時，在目前SDV趨勢下，PREEvision同時支持面向服務(wù)的架構(gòu)設(shè)計(jì)（SOA）以及Adaptive AutoSAR系統(tǒng)和軟架構(gòu)設(shè)計(jì)，并提供SOA&Ethernet Explorer（Classic Platform）和Adaptive AutoSAR Explorer（Adaptive Platform）支持新的設(shè)計(jì)需求。

4、硬件架構(gòu)（Hardware Architecture）

硬件架構(gòu)的設(shè)計(jì)分為三層：硬件組件（Hardware components）和網(wǎng)絡(luò)拓?fù)洌∟etwork topology），電氣原理和線束原理，

l硬件組件（Hardware Component）架構(gòu)，設(shè)計(jì)硬件組件（例如ECU、傳感器、執(zhí)行器）之間的硬線連接，包括硬線信號（PWM、高低電平等），總線連接（CANFD/CAN/LIN等），以及電源連接和接地連接，另外也設(shè)計(jì)ECU內(nèi)部的細(xì)節(jié)，比如MCU、SBC、RAM等；

l網(wǎng)絡(luò)拓?fù)洌∟etwork Topology）

l電氣原理（Electric Circuit），電氣原理層將硬件架構(gòu)層的數(shù)據(jù)進(jìn)行重構(gòu)，重新定義硬件組件之間的連接，并關(guān)注與線束設(shè)計(jì)相關(guān)的電氣屬性，例如電源供應(yīng)、接地連接等，其可設(shè)計(jì)電源分配的保險(xiǎn)、繼電器以及接地分配電路。

l線束原理（Wiring Harness）將電氣原理數(shù)據(jù)進(jìn)行細(xì)化，將邏輯連接轉(zhuǎn)換為導(dǎo)線，同時添加導(dǎo)線之間的焊接點(diǎn)（Splice），內(nèi)部連接器（Inline），端子（Terminal），線束端連接器（Female Connector），

5、幾何拓?fù)洌℅eometric Topology）

幾何拓?fù)鋵邮钦囯娖鞯?.5D布局視圖，其可以通過將3D CAD工具（Dassault Catia等）設(shè)計(jì)完成的3D線束通過KBL格式導(dǎo)入，展平為2D視圖，表達(dá)各電器的安裝位置，線束分段，然后將線束原理層中各組件映射到幾何拓?fù)鋵?，從而進(jìn)行導(dǎo)線的路由規(guī)劃，從而為最終的架構(gòu)評估提供線束的長度、重量等數(shù)據(jù)支撐。

6、線束設(shè)計(jì)（Harness Design）

將幾何拓?fù)渲型瓿蓪?dǎo)線路由的線束總成，在Wire Harness Diagram中進(jìn)行數(shù)據(jù)重構(gòu)，同時添加卡扣、膠帶以及其他固定件、防護(hù)件，可生成線束2D圖紙，指導(dǎo)線束供應(yīng)商進(jìn)行線束的工藝轉(zhuǎn)化，然后進(jìn)行線束的生產(chǎn)和制造。

7、通訊設(shè)計(jì)（Communication）

在完成軟件組件到硬件的Mapping后，可進(jìn)行信號的路由，并進(jìn)行網(wǎng)絡(luò)通訊設(shè)計(jì)，PREEvision提供了多種通信設(shè)計(jì)編輯器來應(yīng)對同步的通信類型，比如CAN Bus Editor，LIN Scheduling Editor，F(xiàn)lexRay Schedulling 和Ethernet Explorer。

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

國內(nèi)OEM的電子電氣架構(gòu)開發(fā)過程

而國內(nèi)OEM通常采用基于文檔的電子電氣架構(gòu)的開發(fā)流程，基于模型的正向開發(fā)流程通常很難真正的實(shí)施下去的，因?yàn)樵谶^去幾十年分布式架構(gòu)下形成的OEM、Tier1的產(chǎn)業(yè)供應(yīng)鏈?zhǔn)呛芄袒模壳笆忻嫔宪囆痛钶d的ECU大部分都是由國外頭部Tier1在供應(yīng)，特別是在底盤、動力領(lǐng)域，ESP、Ibooster、ECM這些零部件的核心Know-how都掌握在Bosch、Continental、APTIV等掌握在這些零部件巨頭手里，國內(nèi)OEM的電子電氣架構(gòu)團(tuán)隊(duì)自己的積累太少，并不能在此領(lǐng)域提出足夠支配供應(yīng)商的需求，另外這些供應(yīng)商開發(fā)的零部件基本是平臺化的，相同的零件應(yīng)用在多家主機(jī)廠的車型上，收發(fā)信號都是定義好OEM根據(jù)需求信號進(jìn)行匹配，因此我們的架構(gòu)團(tuán)隊(duì)寫的功能規(guī)范（子系統(tǒng)功能規(guī)范），迫于無奈要根據(jù)零部件實(shí)際的功能情況去更改適配，架構(gòu)輸出規(guī)范的作用更多的是梳理目前整車已有的功能，而不是去正向設(shè)計(jì)整車的功能，但是近些年我們國內(nèi)的OEM也在一直成長，并嘗試建立正向的電子電子電氣架構(gòu)開發(fā)流程：

l在需求階段進(jìn)行市場調(diào)研、法規(guī)標(biāo)準(zhǔn)分析、競品分析、新技術(shù)分析、基礎(chǔ)平臺分析，定義整車架構(gòu)目標(biāo)，輸出Function List，并針對每個功能編制功能需求規(guī)范FRS（Function Requirement Spefication），進(jìn)行功能描述，場景定義，功能系統(tǒng)框圖設(shè)計(jì)等；

l在功能實(shí)現(xiàn)階段，把功能需求分解并分配給子系統(tǒng)設(shè)計(jì)團(tuán)隊(duì)（功能需求+子系統(tǒng)交互圖）；

l在子系統(tǒng)設(shè)計(jì)階段，輸出子系統(tǒng)需求描述SRD（System Requirement Description）

l在零部件設(shè)計(jì)階段輸出 零部件技術(shù)規(guī)范CTS（Component Technical Spefication）

通過上述規(guī)范的輸出，國內(nèi)OEM掌握的Know-how也越來越多，并在新一代電子電氣架構(gòu)中，逐漸掌握主動權(quán)，不管是Domain架構(gòu)還是Zonal架構(gòu)，要實(shí)現(xiàn)SOA是大家達(dá)成的共識，同時在新的面向服務(wù)的架構(gòu)中，主機(jī)廠要掌握車端、和云端可以提供的服務(wù)，并將服務(wù)開放給第三方應(yīng)用開發(fā)者，從而創(chuàng)建SOA的開發(fā)生態(tài)，因此作為主機(jī)廠的電子電氣架構(gòu)團(tuán)隊(duì)在新的SOA趨勢下，其作用顯得越來越重要，其要從整車功能需求來設(shè)計(jì)整車的服務(wù)，并將服務(wù)分配到不同的Domain，由不同Domain的應(yīng)用軟件開發(fā)團(tuán)隊(duì)來實(shí)現(xiàn)。

審核編輯 ：李倩