建站
咨詢
售后
建站咨詢
新聞中心
隨著整車集成化的程度越來越高,越來越多ECU的功能將會慢慢的被吸收到區(qū)域控制器當(dāng)中。而平臺化區(qū)域控制器則是采用相同的硬件設(shè)計、相同的IO接口看，可以更好的滿足對于不同車型的擴展性要求。所以，區(qū)域控制還同時承擔(dān)整車硬件抽象的重要職能。其兩者之間都會采用高速以太網(wǎng)代替原始的Can通信進行相互連接。概括來講，可拓展的電子架構(gòu)就是要屏蔽車型之間的硬件差異。不管采用多少個區(qū)域控制器組成的通訊網(wǎng)絡(luò)，其相互之間的通訊模式，都遵守同樣的規(guī)則。同時區(qū)域控制器也承擔(dān)其局域網(wǎng)內(nèi)，ECU功能的抽象之責(zé)。
創(chuàng)新互聯(lián)建站專注于企業(yè)成都全網(wǎng)營銷推廣、網(wǎng)站重做改版、安丘網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5響應(yīng)式網(wǎng)站、購物商城網(wǎng)站建設(shè)、集團公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為安丘等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
如上以中央計算平臺為核心的集中式架構(gòu)設(shè)置了統(tǒng)一的傳感器及外設(shè)接口，能夠支持芯片的升級，其最終目的就是要實現(xiàn)在車生命周期內(nèi)的硬件可升級，從而延長汽車的智能化生命周期。而各區(qū)域控制器各自帶有自己的操作系統(tǒng)中間件SOA Core Middleware，可以提供一個分布式計算和通信框架，對下屏蔽各類操作系統(tǒng)系統(tǒng)內(nèi)核差異，對上提供統(tǒng)一的服務(wù)開發(fā)框架。涉及功能包括服務(wù)管理、網(wǎng)絡(luò)管理、通信管理、升級、診斷、日志、狀態(tài)等。
本文將重點重軟硬件解耦的方向講解如何對SOA進行軟硬件部署。
01 SOA的軟件架構(gòu)設(shè)計原理
如下圖表示了典型的SOA軟件架構(gòu)設(shè)計原理。這種以服務(wù)為目標(biāo)的開發(fā)架構(gòu)實際上是實現(xiàn)面向服務(wù)開發(fā)的SOA架構(gòu)模型方案，讓產(chǎn)品經(jīng)理專注于服務(wù)的設(shè)計，而系統(tǒng)軟件則深入到產(chǎn)品的開發(fā)過程中，這也是解決汽車軟件危機的重大突破。整個SOA架構(gòu)可以總結(jié)為由邏輯架構(gòu)構(gòu)建起的一個軟硬解耦的系統(tǒng)和由服務(wù)架構(gòu)完成的服務(wù)抽象與適配，最終建立了一個標(biāo)準(zhǔn)化的服務(wù)體系。
其整體邏輯架構(gòu)設(shè)計過程可概括為：
電子電氣架構(gòu)：設(shè)計可拓展的架構(gòu)（也叫計算與通信架構(gòu)）需要滿足分層設(shè)計、分層測試、分層驗證要求，避免在開發(fā)階段軟件更迭的連鎖反應(yīng)和集成測試中問題集中爆發(fā)，使得發(fā)現(xiàn)問題更加迅速，軟件版本更迭更加快速。
硬件計算平臺：可擴展的硬件平臺包括SOA基礎(chǔ)服務(wù)管理和SOA硬件I/O控制管理，可兼容自動駕駛系統(tǒng)的多個傳感器和外部設(shè)備，支持多異構(gòu)芯片和硬件升級。
操作系統(tǒng)內(nèi)核/服務(wù)中間件：作為文件調(diào)度和驅(qū)動的核心，操作系統(tǒng)在支撐軟硬件解耦和軟件在硬件上的部署方面可以實現(xiàn)最好的支配能力。
通信架構(gòu)：通信架構(gòu)的可擴展性可以很好的確保平臺化車型開發(fā)中快速適配，車型之間的差異可以減少到最少，開發(fā)下階段車型秩序進行通信擴展借鑒當(dāng)前這代產(chǎn)品，不用再進行很多額外的開發(fā)工作，這樣可以大大減少后期產(chǎn)品線維護的壓力。
為了滿足車輛控制實時性的要求，核心網(wǎng)將會采用如TSN等的可靠通訊技術(shù)。在區(qū)域控制器下的局域網(wǎng)內(nèi)，傳統(tǒng)的CAN、Lin等通訊方式將會繼續(xù)存在。局域網(wǎng)內(nèi)可以以傳統(tǒng)的信號的方式進行通信，在核心的以太網(wǎng)骨干網(wǎng)絡(luò)中，將會以服務(wù)的方式進行數(shù)據(jù)之間的交互，就需要如DDS等通信中間件。
服務(wù)層/應(yīng)用層：標(biāo)準(zhǔn)化的服務(wù)層及可編排的應(yīng)用層包含SOA系統(tǒng)功能管理、單元域功能管理、整車功能控制管理、云端服務(wù)管理幾個重要部分。
02 SOA中的設(shè)備抽象技術(shù)
在詳細分析以中央域控為核心的軟件架構(gòu)部署核心技術(shù)之前，需要詳細說明一下相關(guān)聯(lián)的幾個重要概念。Autosar中的傳感器/執(zhí)行器設(shè)計模式描述了在整體架構(gòu)環(huán)境中ECU如何處理在環(huán)的傳感器/執(zhí)行器。
BEG設(shè)備抽象位于RTE（是試運行環(huán)境之上），它是從連接到特定ECU的傳感器和執(zhí)行器中抽象出來的一組軟件組件，他使用了傳感器或執(zhí)行器軟件組件，是RTE之上唯一允許訪問ECU抽象接口的組件。設(shè)備抽象提取傳感器和執(zhí)行器的原始信號，如像素點、點云、電壓、PWM信號、數(shù)字信號/消息、頻率，并為應(yīng)用層軟件提供物理接口（例如像素點、點云、壓力、質(zhì)量、溫度等），實際說來，設(shè)備抽象完成了電壓值、數(shù)字信號、點云等到物理值的轉(zhuǎn)換。
設(shè)備抽象體現(xiàn)了應(yīng)用層軟件通過平臺軟件及底層驅(qū)動軟件在其他不同硬件變體之間的可互換性。
表1平臺軟件與設(shè)備抽象關(guān)系（傳感器）
|
抽象分層 |
作用 |
工作原理 |
工作明細 |
|
平臺軟件 |
輸入原始采集值，輸出電壓值 解耦軟件與硬件連接 |
提供物理特性原始接口 |
機械特性、電氣特性、功能特性和規(guī)程特性。 |
|
電氣設(shè)備驅(qū)動 |
輸入電壓值，輸出過濾后電壓值 確保傳感器測量值可用性 |
運行電氣設(shè)備驅(qū)動軟件電氣診斷（如檢測對地、電池短路、開路等） |
去噪濾波器 傳感器外部供電時的電壓補償 |
|
傳感器設(shè)備驅(qū)動 |
輸入電壓值，輸出傳感器含值如像素、點云、溫度值 解耦不同傳感器差異項 |
執(zhí)行傳感器設(shè)備驅(qū)動程序； 控制傳感器的物理行為； |
·從原始信號（電信號）到物理值的轉(zhuǎn)換； ·零點和偏移適應(yīng) ·測量值的漂移檢測 ·診斷檢查 ·物理值檢查 ·過濾功能（包括下采樣） |
|
虛擬設(shè)備驅(qū)動 |
輸入傳感器含義值，輸出補充后完整值，如亮度值 解耦傳感器信號補償端 |
傳感器的虛擬設(shè)備驅(qū)動用軟件程序其物理表示進行抽象 |
·信號質(zhì)量評估 ·信號原始值替換（如傳感器信號質(zhì)量不足時） ·信號原始值補償 ·信號原始值驗證 ·功能測試診斷接口 |
表2 平臺軟件與設(shè)備抽象關(guān)系（執(zhí)行器）
|
抽象分層 |
作用 |
工作原理 |
工作明細 |
|
平臺軟件 |
輸入PWM，輸出PWM值 解耦軟件與硬件連接 |
提供物理特性原始接口 |
機械特性、電氣特性、功能特性和規(guī)程特性。 |
|
電子設(shè)備驅(qū)動 |
輸入電壓值，輸出過濾后電壓值 確保執(zhí)行器執(zhí)行過程有效性 |
運行電氣設(shè)備驅(qū)動軟件電氣診斷（如檢測對地、電池短路、開路等） |
去噪濾波器 執(zhí)行器外部供電時的電壓補償 |
|
執(zhí)行器設(shè)備驅(qū)動 |
輸入PWM，輸出保護及相應(yīng)的PWM值 解耦執(zhí)行機械過程 解耦執(zhí)行器能力保護 |
傳感器設(shè)備驅(qū)動程序代表執(zhí)行器的物理行為 |
·疊加輸出值以克服驅(qū)動器的摩擦 ·輸出執(zhí)行信號值并保證執(zhí)行有效 ·限制輸出值以防止過度損壞 ·控制設(shè)定值(配合傳感數(shù)據(jù)閉環(huán)) ·提供限制和能力信息的接口 |
|
虛擬設(shè)備驅(qū)動 |
輸入執(zhí)行器請求值輸出PWM值，如閥門開度 解耦傳執(zhí)行器抖動、非線性化、執(zhí)行超限等處理 |
虛擬設(shè)備執(zhí)行程序抽象執(zhí)行器的物理表現(xiàn) |
·控制端物理請求值轉(zhuǎn)換 ·非線性值轉(zhuǎn)化為線性值 ·用于功能測試的診斷測試器接口 ·特殊模式處理 ·啟動執(zhí)行機構(gòu)運行 ·通過覆蓋設(shè)定值或濾波消除執(zhí)行器階段性抖動 ·協(xié)調(diào)執(zhí)行器的安全激活 |
總結(jié)來講，BEG設(shè)備抽象概念和設(shè)計可概括如下：
應(yīng)用軟件獨立于連接到特定ECU的具體傳感器和執(zhí)行器；
不同傳感器和執(zhí)行器之間代碼可復(fù)用；
不同的代碼共享合作模式（軟件共享），從而支持不同的商業(yè)模式；
將功能部署或重新分配到不同的ECU；該設(shè)計模式也被稱為設(shè)備抽象；
設(shè)備抽象解決了S&A層Module向上暴露功能及服務(wù)接口，向下連接平臺軟件，目標(biāo)是盡可能地暴露接口，實現(xiàn)軟硬件解耦，避免因S&A變化導(dǎo)致地軟件變更。
03 SOA中的設(shè)備抽象示例
這里我們列舉一個實例說明在SOA架構(gòu)中如何進行設(shè)備抽象。這種方式只需要了解傳感器類別（如雷達、攝像頭等）來定義輸入的原始數(shù)據(jù)Rawdata，無需了解這些傳感器的具體連接方式，對于頂層應(yīng)用層則是只需要應(yīng)用最終的傳感數(shù)據(jù)。
以傳感器的設(shè)備抽象為例，可以表示如下：
首先是在底層物理層MCAL通過訪問uC端口的方式進行數(shù)據(jù)采集并提供原始數(shù)據(jù)，每隔一定周期（如10ms）檢測一次，這里不需要了解器電器連接方式以及相應(yīng)的數(shù)據(jù)含義。比如從底層激光雷達傳感器采集到原始圖像像素點數(shù)據(jù)，并輸入給微控制器MCU/SOC。
其次，MCU/SOC從對應(yīng)物理地址中按照一定周期取出對應(yīng)的點云值，通過I/O設(shè)備給I/O硬件抽象模塊，并通過I/O硬件抽象點檢測所測數(shù)據(jù)測量點的一級電器連接路由，傳感器基于路由信息和解讀后的原始數(shù)據(jù)計算的電壓值并進行濾波處理，該過程不需要了解所測數(shù)據(jù)的含義。
隨后，將硬件抽象模塊中的電壓值按照8bit驅(qū)動進行分階處理，并由傳感器電子設(shè)備驅(qū)動調(diào)用生成基礎(chǔ)原始值。該值通過傳感器虛擬設(shè)備驅(qū)動Virtual Device Dri 行人、路標(biāo)等。
最終，AP Autosar中的應(yīng)用軟件通過實時運行環(huán)境RTE對傳感器感知目標(biāo)級數(shù)據(jù)進行實時的讀取，用于后續(xù)的應(yīng)用軟件的規(guī)劃控制和決策控制。
從如上示例可看出，設(shè)備抽象具備如下優(yōu)勢，Sensor&Actuator的變化不會引起平臺軟件和應(yīng)用軟件的連帶更改，總結(jié)起來大致有如下幾種變換導(dǎo)致的軟硬件解耦類型。
對于替換不同型號的感知傳感器，ECU的選型不再受限制于ECU支持的信號分析模式的型號。如NTC和PTC型號的替換，只需要修改位于Device Driver中軟件模塊即可。
同一類型的傳感器和執(zhí)行器模塊可共用某些相同的處理模塊，比如對于側(cè)視攝像頭的處理模式，可以直接將對其中一個側(cè)視攝像頭的處理算法直接應(yīng)用于其余三個，而只需要重新對該三個攝像頭的相機參數(shù)進行標(biāo)定即可，如果有部分?jǐn)z像頭需要更新?lián)Q代為更高分辨率攝像頭，對于底層驅(qū)動軟件和平臺軟件來講也是無需做很大變動的，至少I/O接口形式和數(shù)據(jù)輸入模式都不用在動，只是在處理圖像的算法模塊需要重新進行調(diào)優(yōu)，比如原來采用的低分辨率處理算法可能無法達到高分辨率處理模塊對其實時性的要求，這時需要研究神經(jīng)網(wǎng)絡(luò)加速模型的優(yōu)化方式，但是整體的算法架構(gòu)模型是仍舊不變的。
04 總結(jié)
當(dāng)前眾多主機廠比較倡導(dǎo)的開發(fā)方式是進行平臺化產(chǎn)品開發(fā)，而平臺化講求的就是軟硬件解耦的核心思想，采用SOA架構(gòu)模式則是便于形成產(chǎn)品線和平臺線的分工，產(chǎn)品線負責(zé)具體車型項目，平臺線，負責(zé)構(gòu)建技術(shù)中臺。新平臺的開發(fā)，技術(shù)鏈路往往非常長且復(fù)雜，分層的架構(gòu)設(shè)計和軟硬件解耦的方式，可很好的便于進行分層測試與驗證，減少集成測試的壓力，問題發(fā)現(xiàn)的更充分，也能夠提高版本發(fā)布的速度。?
網(wǎng)頁標(biāo)題：SOA中的軟件架構(gòu)設(shè)計及軟硬件解耦方法論
鏈接分享：http://m.fisionsoft.com.cn/article/djehgpe.html
