作者：竇明佳

一、前言

今天的電子電氣架構(gòu)相對于以往發(fā)生了重要變化，首先相對于以往分布式架構(gòu)中眾多計算資源有限的ECU而言，新的架構(gòu)引入了高性能計算單元HPC，同時車輛不再是封閉的系統(tǒng)，而是整個IoT(物聯(lián)網(wǎng))的一部分，另外在車輛軟件層面，在傳統(tǒng)Classic AutoSAR及其他RTOS系統(tǒng)的基礎(chǔ)上，引入了Adaptive AutoSAR平臺、Linux、QNX等車載中間件及操作系統(tǒng)，以支持高性能運算，同時在電子電氣架構(gòu)設(shè)計層面，在以前面向信號的設(shè)計方法基礎(chǔ)上同步要進(jìn)行面向服務(wù)SOA的設(shè)計，對于OEM功能工程師（Function Designer）和系統(tǒng)工程師（System Developer）提出了新的挑戰(zhàn)。

圖1：EEA電子電氣架構(gòu)的發(fā)展

二、新一代電子電氣架構(gòu)

目前新一代的電子電氣架構(gòu)，大致可以分為如下四層：

最低一層包含眾多的傳感器/執(zhí)行器ECU，這些ECU在功能層面主要承擔(dān)車輛的基礎(chǔ)邏輯控制，包括閉環(huán)控制、故障診斷、運行監(jiān)測等，在軟件層面Classic AutoSAR或其他RTOS被應(yīng)用在這里；

第二層主要是包含集成ECU（域控制器或區(qū)域控制器），這些ECU主要承擔(dān)高一層級的集成功能控制，例如面向功能域的控制器（BDCU、CDC、ADC），或者面向車輛分區(qū)的區(qū)域控制器（PDC、VIU等）

注：但是我覺得如果不能做到有效的軟硬解耦，區(qū)域控制器VIU/PDC不做智能配電（eFuse）、不能將車輛眾多的傳感器（Camera/Radar/Lidar）及執(zhí)行器（H-Bridge）與中央計算平臺進(jìn)行隔離，不能真正的降低線束的長度、重量及安裝空間，并不能發(fā)揮Central&Zone方案的價值；

第三層是高性能計算單元，Adaptive AutoSAR被在這里使用，同時Classic AutoSAR也會存在以滿足功能安全Fail-operational場景需求，同時在多核異構(gòu)芯片上運行Hypervisor以為Adaptive AutoSAR、Linux、Android提供虛擬機(jī)。

圖2：高性能計算單元HPC的硬件架構(gòu)

第四層即云平臺，包括新能源車法規(guī)平臺、OTA平臺、遠(yuǎn)程診斷平臺、自動駕駛云平臺、售后服務(wù)平臺、客戶運營平臺等；

圖3：新一代電子電氣分層架構(gòu)

而我們通常所說的SOA主要是在第二（Integration Layer）及以上層級實施，采用面向服務(wù)的架構(gòu)設(shè)計方式，而在第一（Sensor/Actuator Layer）層級主要采用面向信號的設(shè)計方式，那面向信號和面向服務(wù)架構(gòu)設(shè)計方法的主要差別在哪里呢？

圖4：面向服務(wù)與面向信號架構(gòu)設(shè)計流程差別

通過上圖可以看到面向服務(wù)架構(gòu)在邏輯功能架構(gòu)（Logical Function Library&Function Architecture）和軟件架構(gòu)層（Software Architect）之間插入了服務(wù)架構(gòu)層（Service Oriented Architecture）,在服務(wù)架構(gòu)層進(jìn)行服務(wù)的抽象、服務(wù)劃分、服務(wù)接口設(shè)計、服務(wù)編排、服務(wù)部署等工作。

三、面向信號與面向服務(wù)混合架構(gòu)設(shè)計

電子電氣架構(gòu)主要提供了整車功能的開發(fā)框架，無論面向信號還是面向服務(wù)起點都是Customer Feature，最近幾年在電子電氣架構(gòu)領(lǐng)域基于模型的開發(fā)方法（MBSE）被大家廣泛采用，基于模型用例驅(qū)動能夠更好跟蹤用戶需求與最終的技術(shù)實現(xiàn)（軟件、硬件設(shè)計）。采用基于模型的開發(fā)雖然各家的開發(fā)方法論及工具鏈細(xì)節(jié)上存在差異，但是總體的流程基本一致。

圖5：基于模型的EEA開發(fā)流程

3.1 用戶特征及需求（Customer Feature and Requirements ）

這一步是站在用戶視角，分析所有相關(guān)方對功能的需求，借助于用例（Use Case） 場景（包含基礎(chǔ)路徑、替代路徑、異常路徑及行為者、前提條件、后置條件等）分析系統(tǒng)需求，包括：

a)功能需求（Function Requirements）

功能激活條件

激活/關(guān)閉/進(jìn)行中的系統(tǒng)行為

功能激活/關(guān)閉的條件

b)非功能需求（Non-Function Requirements）

系統(tǒng)時間及性能需求

法規(guī)相關(guān)需求

功能安全相關(guān)需求

信息安全相關(guān)需求

c)平臺/跨域需求（Platform/Domain Requirements）

車輛配置需求

人機(jī)交互需求

這一步的主要輸出物是用例圖及用例描述，同時用例和需求要做Mapping，輸出FRD（Function Requirements Document）。

圖6：用例圖

3.2 邏輯功能架構(gòu)(Logical Architecture)

基于上一步的用例及功能需求，我們針對每個Feature（Use Case）進(jìn)行邏輯功能架構(gòu)設(shè)計，在這一步我們會劃分邏輯功能組件LC（Logical Component），LC是一個抽象的組件它獨立于具體的硬件和軟件實現(xiàn)，同時LC在整個架構(gòu)平臺是一個重要的數(shù)據(jù)庫，應(yīng)該形成一個LC Library，并且LC的創(chuàng)建、更新由架構(gòu)工程師（System Architect）來統(tǒng)一負(fù)責(zé)，功能工程師（Function Designer）在進(jìn)行邏輯架構(gòu)設(shè)計時向架構(gòu)工程師（SA）提出LC的需求，同時架構(gòu)工程師（SA）負(fù)責(zé)LC向系統(tǒng)的分配。

我們來看一個具體的例子，如下圖有兩個整車Feature X和Feature Y，F(xiàn)eature X在邏輯功能架構(gòu)設(shè)計時由Sensorfunction1、Function1和ActuatorFunction1 三個LC實現(xiàn)，F(xiàn)eature Y在邏輯功能架構(gòu)設(shè)計時由SensorFunction1、Function1、Function2、SensorFunction2、Function3、Function4、Function5、Function6等9個LC組成；

圖7：邏輯功能架構(gòu)圖

為了保證邏輯功能架構(gòu)與后面AutoSAR軟件架構(gòu)的繼承性，邏輯組件LC的接口設(shè)計應(yīng)遵循AutoSAR的標(biāo)準(zhǔn)，在邏輯功能架構(gòu)設(shè)計階段，不同的方法論和工具鏈會有些許的差異，例如PREEvision中我們通常會針對每個Feature創(chuàng)建Activity Chain，另外像BEG等用IBM工具鏈的廠家會在Rhapsody中創(chuàng)建整車層級、系統(tǒng)層級到邏輯組件層級的泳道圖，從而進(jìn)行功能的細(xì)化分解形成LC，最后進(jìn)行LC的部署，上述邏輯架構(gòu)圖中的每個邏輯組件都將被分配到對應(yīng)的Sensor、Actuator、ECU或計算單元中，將圖7中的邏輯組件分配到圖3中的架構(gòu)層級各節(jié)點中，形成的矩陣如下：

圖8：LC部署矩陣

至此完成功能層面的需求分析及功能設(shè)計，可導(dǎo)出FRS（Function Requirement Specification）,上述過程無論是面向信號還是面向服務(wù)的架構(gòu)設(shè)計都是必須進(jìn)行中的，同時上述內(nèi)容將成為OEM的核心資產(chǎn)。

注：上述邏輯功能架構(gòu)階段，還有功能安全工程師、信息安全工程師的參與進(jìn)行功能安全概念（FSC）、信息安全等相關(guān)工作；

3.3 服務(wù)架構(gòu)(Service Architecture)

上面我們說到SOA主要是在第二（Integration Layer）及以上層級（Computing Layer、IT-Backend Layer and external Devices）實施，采用面向服務(wù)的架構(gòu)設(shè)計方式，經(jīng)過上述LC的部署，我們可以看到Fucntion2、Function4、Function5、Backup Function6和Function6分別被部署到了Integration ECU2、High-Performance Computer1以及Backend Server1上，同時我們經(jīng)過各方面的評估（實時性、安全性、可擴(kuò)展性等）認(rèn)為Function4、Function5、和Function6適合服務(wù)化，可將其抽象為服務(wù)，并設(shè)計Service Interface（Method、Event、Properties）及服務(wù)的參與者（Service Provider/Service Consumer）,同時根據(jù)邏輯功能架構(gòu)的設(shè)計服務(wù)的依賴關(guān)系，如下圖9：

圖9：SOA Diagram

3.4 軟件架構(gòu)(Software Architecture)

在設(shè)計完服務(wù)Service，并將服務(wù)部署到對應(yīng)的運行環(huán)境中，如將Service4部署到Integration ECU2的Classic AutoSAR運行環(huán)境，則對應(yīng)到軟件層面Service4 Port將轉(zhuǎn)換為一簇Sender/Receiver/Client/Server Ports端口，并通過SOA Adaptor（S2S）與部署到Adaptive AutoSAR運行環(huán)境的Service5、Service6交互，完成服務(wù)部署，服務(wù)的參數(shù)者（Service Provider/Service Consumer）將轉(zhuǎn)換為對應(yīng)的應(yīng)用軟件組件（Application SWC/Adaptive Application SWC），如下圖10為對應(yīng)Feature Y的軟件架構(gòu)：

圖10：軟件架構(gòu)視圖

從上圖我們可以看到對應(yīng)部署在Sensor Actuator ECU1的Fucntion1，部署在Integration ECU2的Fucntion2、以及部署在Sensor Actuator ECU3的Function3等非服務(wù)化的邏輯組件LC，其在軟件層面會設(shè)計對應(yīng)的Classic AutoSAR Application SW Component,以及S/R Interface及C/S Interface。

3.5 通信架構(gòu)(Communication Architecture)

基于上述過程我們可以導(dǎo)出信號列表和服務(wù)列表，導(dǎo)入下游的通信設(shè)計工具進(jìn)行CAN（FD）、LIN、Ethernet的設(shè)計，從而輸出DBC、LDF、ARXML文件，在此不詳細(xì)描述。

圖11：信號列表

在當(dāng)前階段，電氣化、智能化、網(wǎng)聯(lián)化、共享化的需求推動電子電氣架構(gòu)的變革，OEM想在這場變革中掌握主動權(quán)，希望更多的軟件自主化，從而在軟件定義汽車SDV的浪潮中站穩(wěn)腳跟，另一方面卻是過去的開發(fā)模式造成在人員、組織架構(gòu)、知識儲備方面的缺失，大多數(shù)的企業(yè)還是根據(jù)自己的情況逐步構(gòu)建新一代的電子電氣架構(gòu)，在這種情況下怎么將自上而下的正向功能開發(fā)與自下而上（繼承已有的供應(yīng)鏈資源）的開發(fā)有效結(jié)合是一個挑戰(zhàn)，而基于模型的開發(fā)可有效的銜接各個開發(fā)角色以應(yīng)對新一代電子電氣架構(gòu)的復(fù)雜性。

圖12：架構(gòu)層級及對應(yīng)角色職責(zé)

審核編輯：湯梓紅