點(diǎn)擊上方藍(lán)字談思實(shí)驗(yàn)室

(資料圖片)

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

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

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

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

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

通過上圖可以看到面向服務(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è)計(jì)、服務(wù)編排、服務(wù)部署等工作。

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

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

a)功能需求（Function Requirements）

?功能激活條件

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

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

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

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

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

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

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

c)平臺(tái)/跨域需求（Platform/Domain Requirements）

?車輛配置需求

?人機(jī)交互需求

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

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

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

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

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

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

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

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

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

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

來源：線束中國

會(huì)員權(quán)益:(點(diǎn)擊可進(jìn)入)談思實(shí)驗(yàn)室VIP會(huì)員

關(guān)鍵詞：