點擊上方藍字談思實驗室
(資料圖片)
獲取更多汽車網絡安全資訊
今天的電子電氣架構相對于以往發生了重要變化，首先相對于以往分布式架構中眾多計算資源有限的ECU而言，新的架構引入了高性能計算單元HPC，同時車輛不再是封閉的系統，而是整個IoT(物聯網)的一部分，另外在車輛軟件層面，在傳統Classic AutoSAR及其他RTOS系統的基礎上，引入了Adaptive AutoSAR平臺、Linux、QNX等車載中間件及操作系統，以支持高性能運算，同時在電子電氣架構設計層面，在以前面向信號的設計方法基礎上同步要進行面向服務SOA的設計，對于OEM功能工程師（Function Designer）和系統工程師（System Developer）提出了新的挑戰。
目前新一代的電子電氣架構，大致可以分為如下四層：
第四層即云平臺，包括新能源車法規平臺、OTA平臺、遠程診斷平臺、自動駕駛云平臺、售后服務平臺、客戶運營平臺等；
而我們通常所說的SOA主要是在第二（Integration Layer）及以上層級實施，采用面向服務的架構設計方式，而在第一（Sensor/Actuator Layer）層級主要采用面向信號的設計方式，那面向信號和面向服務架構設計方法的主要差別在哪里呢？
通過上圖可以看到面向服務架構在邏輯功能架構（Logical Function Library&Function Architecture）和軟件架構層（Software Architect）之間插入了服務架構層（Service Oriented Architecture）,在服務架構層進行服務的抽象、服務劃分、服務接口設計、服務編排、服務部署等工作。
電子電氣架構主要提供了整車功能的開發框架，無論面向信號還是面向服務起點都是Customer Feature，最近幾年在電子電氣架構領域基于模型的開發方法（MBSE）被大家廣泛采用，基于模型用例驅動能夠更好跟蹤用戶需求與最終的技術實現（軟件、硬件設計）。采用基于模型的開發雖然各家的開發方法論及工具鏈細節上存在差異，但是總體的流程基本一致。
這一步是站在用戶視角，分析所有相關方對功能的需求，借助于用例（Use Case） 場景（包含基礎路徑、替代路徑、異常路徑及行為者、前提條件、后置條件等）分析系統需求，包括：
a)功能需求（Function Requirements）
?功能激活條件
?激活/關閉/進行中的系統行為
?功能激活/關閉的條件
b)非功能需求（Non-Function Requirements）
?系統時間及性能需求
?法規相關需求
?功能安全相關需求
?信息安全相關需求
c)平臺/跨域需求（Platform/Domain Requirements）
?車輛配置需求
?人機交互需求
這一步的主要輸出物是用例圖及用例描述，同時用例和需求要做Mapping，輸出FRD（Function Requirements Document）。
基于上一步的用例及功能需求，我們針對每個Feature（Use Case）進行邏輯功能架構設計，在這一步我們會劃分邏輯功能組件LC（Logical Component），LC是一個抽象的組件它獨立于具體的硬件和軟件實現，同時LC在整個架構平臺是一個重要的數據庫，應該形成一個LC Library，并且LC的創建、更新由架構工程師（System Architect）來統一負責，功能工程師（Function Designer）在進行邏輯架構設計時向架構工程師（SA）提出LC的需求，同時架構工程師（SA）負責LC向系統的分配。
我們來看一個具體的例子，如下圖有兩個整車Feature X和Feature Y，Feature X在邏輯功能架構設計時由Sensorfunction1、Function1和ActuatorFunction1 三個LC實現，Feature Y在邏輯功能架構設計時由SensorFunction1、Function1、Function2、SensorFunction2、Function3、Function4、Function5、Function6等9個LC組成；
為了保證邏輯功能架構與后面AutoSAR軟件架構的繼承性，邏輯組件LC的接口設計應遵循AutoSAR的標準，在邏輯功能架構設計階段，不同的方法論和工具鏈會有些許的差異，例如PREEvision中我們通常會針對每個Feature創建Activity Chain，另外像BEG等用IBM工具鏈的廠家會在Rhapsody中創建整車層級、系統層級到邏輯組件層級的泳道圖，從而進行功能的細化分解形成LC，最后進行LC的部署，上述邏輯架構圖中的每個邏輯組件都將被分配到對應的Sensor、Actuator、ECU或計算單元中，將圖7中的邏輯組件分配到圖3中的架構層級各節點中，形成的矩陣如下：
至此完成功能層面的需求分析及功能設計，可導出FRS（Function Requirement Specification）,上述過程無論是面向信號還是面向服務的架構設計都是必須進行中的，同時上述內容將成為OEM的核心資產。
上面我們說到SOA主要是在第二（Integration Layer）及以上層級（Computing Layer、IT-Backend Layer and external Devices）實施，采用面向服務的架構設計方式，經過上述LC的部署，我們可以看到Fucntion2、Function4、Function5、Backup Function6和Function6分別被部署到了Integration ECU2、High-Performance Computer1以及Backend Server1上，同時我們經過各方面的評估（實時性、安全性、可擴展性等）認為Function4、Function5、和Function6適合服務化，可將其抽象為服務，并設計Service Interface（Method、Event、Properties）及服務的參與者（Service Provider/Service Consumer）,同時根據邏輯功能架構的設計服務的依賴關系，如下圖9：
在設計完服務Service，并將服務部署到對應的運行環境中，如將Service4部署到Integration ECU2的Classic AutoSAR運行環境，則對應到軟件層面Service4 Port將轉換為一簇Sender/Receiver/Client/Server Ports端口，并通過SOA Adaptor（S2S）與部署到Adaptive AutoSAR運行環境的Service5、Service6交互，完成服務部署，服務的參數者（Service Provider/Service Consumer）將轉換為對應的應用軟件組件（Application SWC/Adaptive Application SWC），如下圖10為對應Feature Y的軟件架構：
從上圖我們可以看到對應部署在Sensor Actuator ECU1的Fucntion1，部署在Integration ECU2的Fucntion2、以及部署在Sensor Actuator ECU3的Function3等非服務化的邏輯組件LC，其在軟件層面會設計對應的Classic AutoSAR Application SW Component,以及S/R Interface及C/S Interface。
基于上述過程我們可以導出信號列表和服務列表，導入下游的通信設計工具進行CAN（FD）、LIN、Ethernet的設計，從而輸出DBC、LDF、ARXML文件，在此不詳細描述。
在當前階段，電氣化、智能化、網聯化、共享化的需求推動電子電氣架構的變革，OEM想在這場變革中掌握主動權，希望更多的軟件自主化，從而在軟件定義汽車SDV的浪潮中站穩腳跟，另一方面卻是過去的開發模式造成在人員、組織架構、知識儲備方面的缺失，大多數的企業還是根據自己的情況逐步構建新一代的電子電氣架構，在這種情況下怎么將自上而下的正向功能開發與自下而上（繼承已有的供應鏈資源）的開發有效結合是一個挑戰，而基于模型的開發可有效的銜接各個開發角色以應對新一代電子電氣架構的復雜性。
來源：線束中國
會員權益:(點擊可進入)談思實驗室VIP會員
關鍵詞：
營業執照公示信息
