點擊上方藍字談思實驗室

(資料圖片)

獲取更多汽車網(wǎng)絡(luò)安全資訊

今天的電子電氣架構(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ǔ)上同步要進行面向服務(wù)SOA的設(shè)計，對于OEM功能工程師（Function Designer）和系統(tǒng)工程師（System Developer）提出了新的挑戰(zhàn)。

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

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

而我們通常所說的SOA主要是在第二（Integration Layer）及以上層級實施，采用面向服務(wù)的架構(gòu)設(shè)計方式，而在第一（Sensor/Actuator Layer）層級主要采用面向信號的設(shè)計方式，那面向信號和面向服務(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)層進行服務(wù)的抽象、服務(wù)劃分、服務(wù)接口設(shè)計、服務(wù)編排、服務(wù)部署等工作。

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

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

a)功能需求（Function Requirements）

?功能激活條件

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

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

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

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

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

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

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

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

?車輛配置需求

?人機交互需求

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

基于上一步的用例及功能需求，我們針對每個Feature（Use Case）進行邏輯功能架構(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)一負責，功能工程師（Function Designer）在進行邏輯架構(gòu)設(shè)計時向架構(gòu)工程師（SA）提出LC的需求，同時架構(gòu)工程師（SA）負責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組成；

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

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

上面我們說到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)過各方面的評估（實時性、安全性、可擴展性等）認為Function4、Function5、和Function6適合服務(wù)化，可將其抽象為服務(wù)，并設(shè)計Service Interface（Method、Event、Properties）及服務(wù)的參與者（Service Provider/Service Consumer）,同時根據(jù)邏輯功能架構(gòu)的設(shè)計服務(wù)的依賴關(guān)系，如下圖9：

在設(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)：

從上圖我們可以看到對應(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。

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

在當前階段，電氣化、智能化、網(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ù)雜性。

來源：線束中國

會員權(quán)益:(點擊可進入)談思實驗室VIP會員

關(guān)鍵詞：