)
1. 為什么BMS工程師繞不開(kāi)AUTOSAR見(jiàn)過(guò)不少?gòu)腗ATLAB/Simulink模型起步的BMS工程師一開(kāi)始接觸AUTOSAR都有點(diǎn)抗拒。我自己也是。當(dāng)時(shí)項(xiàng)目組拿到客戶的新需求——軟件架構(gòu)必須按照AUTOSAR分層來(lái)ASW、RTE、BSW這些詞突然鋪天蓋地地出現(xiàn)在評(píng)審會(huì)上。我腦子里第一反應(yīng)是我只要能把SOC、SOH算準(zhǔn)把均衡和繼電器控制做好不就行了為什么非要套一層這么復(fù)雜的“殼”真正改變我看法的是一個(gè)下午的聯(lián)調(diào)現(xiàn)場(chǎng)。BMS樣件上電以后控制器一直報(bào)通信超時(shí)但用示波器看CAN波形完全正常報(bào)文也在發(fā)。最后查下來(lái)問(wèn)題根本不在算法也不在硬件而是BSW層的通信棧配置和ASW側(cè)的任務(wù)周期對(duì)不上——某個(gè)關(guān)鍵的控制信號(hào)沒(méi)有按照預(yù)期時(shí)間被發(fā)送出去。那一刻我意識(shí)到如果不懂ASW與BSW的分層邏輯和工作邊界你連排查問(wèn)題的入手點(diǎn)都找不到。1.1 BMS的開(kāi)發(fā)模式正在從“裸機(jī)”走向“平臺(tái)化”傳統(tǒng)BMS開(kāi)發(fā)普遍是“一個(gè)單片機(jī)加一堆驅(qū)動(dòng)庫(kù)”底層ADC采樣自己初始化CAN收發(fā)自己寫寄存器故障存儲(chǔ)直接操作EEPROM應(yīng)用代碼和硬件代碼攪在一起。只要換一顆MCU整套軟件都要?jiǎng)右槐橐浦渤杀緲O高。但今天OEM和Tier 1的交付要求已經(jīng)變了很多新項(xiàng)目直接把“符合AUTOSAR架構(gòu)”寫進(jìn)技術(shù)協(xié)議里供應(yīng)商如果沒(méi)有按標(biāo)準(zhǔn)分層交付驗(yàn)收那關(guān)就過(guò)不去。AUTOSAR解決的正是這個(gè)問(wèn)題。它把汽車電子軟件抽象成一組標(biāo)準(zhǔn)化的層次應(yīng)用層只做控制邏輯底層驅(qū)動(dòng)由標(biāo)準(zhǔn)化模塊接管中間通過(guò)RTE通信。BMS作為整車安全件涉及高壓采樣、絕緣監(jiān)測(cè)、繼電器驅(qū)動(dòng)、熱管理、整車通信等一大堆功能恰恰是從這個(gè)平臺(tái)化中受益最多的系統(tǒng)之一。因?yàn)锽MS的硬件平臺(tái)迭代很快——從分布式采集板到域控集成式方案從單MCU到多核MCU——沒(méi)有AUTOSAR這種分層每一次硬件升級(jí)都是災(zāi)難。1.2 “會(huì)用”和“懂架構(gòu)”是兩回事很多BMS工程師會(huì)用工具比如用Vector的DaVinci或者EB tresos把配置刷一遍生成代碼編譯燒錄能跑起來(lái)就覺(jué)得完事了。但這屬于“會(huì)用”。真正遇到問(wèn)題的時(shí)候——為什么這個(gè)信號(hào)沒(méi)發(fā)出去為什么掉電后NvM里存的數(shù)據(jù)丟了為什么一個(gè)任務(wù)把另一個(gè)任務(wù)餓死了——你如果沒(méi)有ASW和BSW的底層認(rèn)知就只能靠猜。舉個(gè)最常見(jiàn)的例子ASW里寫了一個(gè)狀態(tài)機(jī)某個(gè)狀態(tài)下要把“允許充電”這個(gè)信號(hào)置1。但整車端一直收不到或者收到了但值不對(duì)。如果你不懂ASW信號(hào)是通過(guò)RTE映射到BSW的COM模塊、再經(jīng)過(guò)PDUR、CAN接口才能變成一幀CAN報(bào)文的你就很難判斷問(wèn)題出在RTE的端口映射、COM的信號(hào)打包還是PDUR的路由配置。這已經(jīng)不是“把代碼寫對(duì)”的問(wèn)題而是“把架構(gòu)搞清楚”的問(wèn)題。1.3 哪些人應(yīng)該重點(diǎn)學(xué)習(xí)這部分內(nèi)容我不建議所有人都一頭扎進(jìn)去啃全套規(guī)范。優(yōu)先需要弄懂ASW與BSW的是這幾類人第一做BMS應(yīng)用層算法集成的工程師你需要知道自己的算法如何變成周期任務(wù)、如何和底層交互第二做BMS底層軟件和MCAL集成的工程師你需要搞清楚BSW模塊的依賴關(guān)系和配置參數(shù)第三做系統(tǒng)測(cè)試和整車聯(lián)調(diào)的工程師你要能快速定位故障是出在應(yīng)用邏輯還是基礎(chǔ)軟件層。這篇文章就圍繞“ASW和BSW到底各自是什么、在BMS場(chǎng)景里怎么配合”來(lái)展開(kāi)。我不會(huì)去抄規(guī)范文檔而是按照實(shí)際工程中的理解和踩坑經(jīng)驗(yàn)來(lái)講。2. AUTOSAR的分層邏輯ASW、RTE、BSW的邊界到底在哪AUTOSAR最核心的思想就是“分層”每一層只關(guān)心自己的事層與層之間通過(guò)標(biāo)準(zhǔn)接口對(duì)話。對(duì)于BMS工程師來(lái)說(shuō)理解這三個(gè)層次就是理解整個(gè)架構(gòu)的地圖。2.1 一張圖說(shuō)清AUTOSAR的橫向分層從上往下看AUTOSAR經(jīng)典平臺(tái)大致分四層應(yīng)用層ASW、運(yùn)行時(shí)環(huán)境RTE、基礎(chǔ)軟件層BSW、微控制器抽象層MCAL。另外還有復(fù)雜驅(qū)動(dòng)CDD這個(gè)概念——但先不展開(kāi)后面會(huì)提到。層次包含內(nèi)容在BMS中的典型對(duì)應(yīng)應(yīng)用層ASW軟件組件SWC、內(nèi)部行為、可運(yùn)行實(shí)體RunnableSOC/SOH算法、均衡策略、絕緣檢測(cè)策略、繼電器控制邏輯運(yùn)行時(shí)環(huán)境RTE通信基礎(chǔ)設(shè)施、任務(wù)實(shí)體生成、端口連接數(shù)據(jù)從電壓采集SWC傳遞到SOC估算SWC服務(wù)層BSW上層OS、EcuM、BswM、NvM、Dcm、Dem、Com、PduR等任務(wù)調(diào)度、故障管理、診斷服務(wù)、非易失存儲(chǔ)ECU抽象層BSW中層與具體外設(shè)無(wú)關(guān)的抽象驅(qū)動(dòng)接口CAN接口、IO抽象、ADC抽象微控制器抽象層MCAL直接操作寄存器的驅(qū)動(dòng)Port、Dio、Adc、Pwm、Spi、Can驅(qū)動(dòng)ASW的主體是軟件組件。你可以把一個(gè)SWC理解成一個(gè)“帶清晰邊界的功能模塊”比如“SOC估算組件”“單體均衡組件”“絕緣監(jiān)測(cè)組件”。每個(gè)SWC內(nèi)部有若干個(gè)Runnable相當(dāng)于C語(yǔ)言里的函數(shù)——但它們的觸發(fā)方式不是誰(shuí)調(diào)用誰(shuí)而是由RTE按周期或事件來(lái)觸發(fā)。BSW則是“功能提供方”和“資源管理方”。它不關(guān)心你SOC算得準(zhǔn)不準(zhǔn)它只負(fù)責(zé)保證每個(gè)任務(wù)在正確的時(shí)間被調(diào)度、把CAN報(bào)文發(fā)出去、把數(shù)據(jù)存進(jìn)非易失存儲(chǔ)器、對(duì)外提供診斷服務(wù)。RTE夾在中間角色很特殊。它不是一個(gè)常規(guī)意義上的“模塊”而是為每個(gè)ECU自動(dòng)生成的一段代碼層。它的職責(zé)是把SWC需要的數(shù)據(jù)從生產(chǎn)者送達(dá)到消費(fèi)者把Runnable的調(diào)用時(shí)機(jī)和OS任務(wù)綁定起來(lái)屏蔽應(yīng)用對(duì)BSW的直接訪問(wèn)。換句話說(shuō)如果ASW是員工BSW是公司的財(cái)務(wù)和行政那RTE就是OA系統(tǒng)——所有報(bào)銷單都要通過(guò)它流轉(zhuǎn)。2.2 為什么邊界劃分這么重要很多剛接觸AUTOSAR的人會(huì)問(wèn)一個(gè)問(wèn)題既然BSW已經(jīng)把ADC采樣、CAN收發(fā)都封裝好了那是不是ASW里可以直接調(diào)這些函數(shù)答案是不行。AUTOSAR架構(gòu)強(qiáng)制的規(guī)則就是ASW不能直接調(diào)用BSW的接口必須通過(guò)RTE。原因很現(xiàn)實(shí)一旦允許ASW直接操作底層那么“應(yīng)用軟件可移植”就變成一句空話。你換了一顆MCU底層驅(qū)動(dòng)變了應(yīng)用代碼里還留著對(duì)舊寄存器的直接調(diào)用那就又退回傳統(tǒng)的嵌入式開(kāi)發(fā)模式了。在BMS項(xiàng)目里這種分離還有一個(gè)額外的價(jià)值功能安全。BMS通常要求ASIL C甚至ASIL D等級(jí)的開(kāi)發(fā)流程。分層架構(gòu)天然把“安全算法邏輯”和“底層資源管理”隔離每條數(shù)據(jù)鏈路、每次任務(wù)觸發(fā)都變得可追溯。審查員問(wèn)起來(lái)“這個(gè)保護(hù)功能是從哪個(gè)Runnable觸發(fā)的數(shù)據(jù)從哪里來(lái)走了哪條通信路徑”——如果你能清晰回答這就是分層架構(gòu)最大的回報(bào)。2.3 復(fù)雜驅(qū)動(dòng)CDD的定位實(shí)際BMS里總會(huì)遇到一些AUTOSAR標(biāo)準(zhǔn)模塊覆蓋不了的功能比如某些廠家的專用IC溫度采樣協(xié)議、特定AFE芯片的菊花鏈采集時(shí)序。這類驅(qū)動(dòng)如果硬塞進(jìn)應(yīng)用層會(huì)破壞可移植性如果硬套MCAL標(biāo)準(zhǔn)接口又很別扭。AUTOSAR允許用復(fù)雜驅(qū)動(dòng)CDD來(lái)承載這部分非標(biāo)準(zhǔn)化的功能。CDD可以直接放在BSW里給上層提供相對(duì)標(biāo)準(zhǔn)的接口但內(nèi)部實(shí)現(xiàn)可以保留硬件相關(guān)的邏輯。這塊我只說(shuō)一句經(jīng)驗(yàn)不要輕易把所有不好歸類的代碼都塞進(jìn)CDD。CDD用多了架構(gòu)就退化成一堆“補(bǔ)丁”后續(xù)軟件升級(jí)和維護(hù)會(huì)很痛苦。能用標(biāo)準(zhǔn)模塊解決的盡量用標(biāo)準(zhǔn)模塊。3. BSW里BMS工程師必須重點(diǎn)掌握的模塊BSW涵蓋的模塊非常多但它內(nèi)部的層次結(jié)構(gòu)是清晰的服務(wù)層管調(diào)度、存儲(chǔ)、診斷和通信ECU抽象層管接口統(tǒng)一MCAL管寄存器操作。這里我不打算把幾十個(gè)模塊都過(guò)一遍只挑BMS工程師在項(xiàng)目里打交道最多的五個(gè)方向。3.1 AUTOSAR OSBMS任務(wù)的搶占與調(diào)度AUTOSAR OS是BMS軟件的“心臟”。BMS里任務(wù)天然分輕重緩急單體電壓采樣、絕緣檢測(cè)這些涉及安全的計(jì)算必須嚴(yán)格按時(shí)完成而均衡策略、SOC濾波這類周期性任務(wù)可以稍微“讓路”。實(shí)際項(xiàng)目中你可能需要配置這樣幾個(gè)任務(wù)10ms周期任務(wù)跑電壓電流采樣和短路保護(hù)判斷50ms任務(wù)跑絕緣監(jiān)測(cè)狀態(tài)機(jī)100ms任務(wù)跑SOC估算500ms任務(wù)跑均衡策略。高優(yōu)先級(jí)的任務(wù)搶占低優(yōu)先級(jí)任務(wù)這是AUTOSAR OS的標(biāo)準(zhǔn)行為。配置OS時(shí)最核心的幾個(gè)參數(shù)任務(wù)優(yōu)先級(jí)、調(diào)度策略搶占或協(xié)作、激活次數(shù)、周期、以及任務(wù)體量。我的建議是在BMS項(xiàng)目中優(yōu)先采用搶占式調(diào)度因?yàn)橥耆揽繀f(xié)作式調(diào)度很難保證極端工況下的保護(hù)響應(yīng)時(shí)間。另一個(gè)容易踩的坑是優(yōu)先級(jí)反轉(zhuǎn)——高優(yōu)先級(jí)任務(wù)等待的共享資源被低優(yōu)先級(jí)任務(wù)占著這時(shí)候需要配置優(yōu)先級(jí)天花板協(xié)議或者立即繼承協(xié)議。BMS是安全件這類問(wèn)題必須在設(shè)計(jì)階段就規(guī)避。3.2 NvM關(guān)鍵時(shí)刻的數(shù)據(jù)居然沒(méi)存住NvM非易失存儲(chǔ)器管理負(fù)責(zé)管理EEPROM或Flash類存儲(chǔ)。BMS里哪些數(shù)據(jù)需要存SOC初值、SOH衰減因子、故障碼和故障凍結(jié)幀、標(biāo)定參數(shù)、生產(chǎn)下線信息、累計(jì)充放電安時(shí)數(shù)等。這些數(shù)據(jù)如果掉電丟了輕則SOC跳變重則影響售后診斷。NvM里有幾個(gè)概念BMS工程師必須搞清楚NV Block數(shù)據(jù)塊、Block狀態(tài)、數(shù)據(jù)校驗(yàn)、以及讀/寫時(shí)機(jī)。最常見(jiàn)的錯(cuò)誤是NvM寫入時(shí)機(jī)和任務(wù)周期不匹配——某段邏輯在正常運(yùn)行周期里反復(fù)觸發(fā)NvM寫操作導(dǎo)致Flash壽命迅速耗盡或者等到下電瞬間才開(kāi)始寫但硬件掉電時(shí)間根本不夠?qū)懲?。我建議的做法是分成“正常周期寫”和“掉電保護(hù)寫”兩種策略。周期性的SOC初值等數(shù)據(jù)用比較低的頻率比如每30秒一次或者每次值變化超過(guò)閾值時(shí)寫入掉電瞬間的關(guān)鍵數(shù)據(jù)則由BSW的EcuM接管保證下電時(shí)序里預(yù)留出足夠的時(shí)間完成最后一次寫操作。不要依賴在應(yīng)用代碼里“最后時(shí)刻寫NvM”競(jìng)爭(zhēng)風(fēng)險(xiǎn)太大。3.3 COM與網(wǎng)絡(luò)管理CAN報(bào)文不是你想發(fā)就能發(fā)COM模塊負(fù)責(zé)信號(hào)Signal、PDU協(xié)議數(shù)據(jù)單元和報(bào)文Frame之間的映射。ASW里的SOC信號(hào)通過(guò)RTE傳給COMCOM按PDU打包進(jìn)CAN報(bào)文再由PduR、CanIf、CanDriver一層層送到總線。這個(gè)鏈路里任何一層都有可能導(dǎo)致報(bào)文發(fā)不出去。以BMS和整車控制器VCU的通信為例VCU需要一個(gè)10ms周期的“BMS狀態(tài)報(bào)文”里面包含總壓、總流、SOC、絕緣電阻等信號(hào)。這個(gè)信號(hào)可能分散在好幾個(gè)SWC里。配置COM時(shí)你需要把這些信號(hào)映射到同一個(gè)PDU設(shè)置好發(fā)送周期和觸發(fā)條件。如果你只把信號(hào)映射對(duì)了但PDU的傳輸模式配置成“事件觸發(fā)”而該信號(hào)一直沒(méi)有變化那整車就收不到報(bào)文——這個(gè)問(wèn)題我用“周期性事件觸發(fā)”的組合模式來(lái)解決。再說(shuō)說(shuō)網(wǎng)絡(luò)管理。AUTOSAR網(wǎng)絡(luò)管理NM負(fù)責(zé)協(xié)調(diào)ECU的睡眠和喚醒。BMS這個(gè)系統(tǒng)很特殊整車下電后BMS通常還要保持低壓供電一段時(shí)間確保繼電器斷開(kāi)、絕緣檢測(cè)完成、高壓安全監(jiān)測(cè)還在工作。這個(gè)“延遲下電”的時(shí)序需要和整車網(wǎng)絡(luò)管理策略對(duì)齊。我實(shí)際做項(xiàng)目時(shí)發(fā)現(xiàn)很多下電異常問(wèn)題根本不是BMS算法邏輯問(wèn)題而是網(wǎng)絡(luò)管理狀態(tài)機(jī)和整車的快照喚醒/睡眠時(shí)機(jī)沒(méi)配合好。3.4 診斷模塊BMS的“病歷本”和“體檢室”診斷棧在AUTOSAR里的核心模塊是Dcm診斷通信管理和Dem診斷事件管理。Dcm負(fù)責(zé)處理UDS診斷服務(wù)比如0x10會(huì)話切換、0x22讀取標(biāo)識(shí)、0x2E寫入數(shù)據(jù)、0x31例程控制Dem負(fù)責(zé)管理故障碼DTC。BMS的項(xiàng)目中新增一個(gè)“過(guò)溫故障”不是簡(jiǎn)單地在代碼里置一個(gè)標(biāo)志位而是要在Dem里定義好DTC、故障判定條件、降級(jí)處理策略和故障存儲(chǔ)方式。這塊我自己踩過(guò)坑早期項(xiàng)目直接在ASW里寫了一句“故障標(biāo)志1”然后就把這個(gè)標(biāo)志變量發(fā)給整車。到了臺(tái)架測(cè)試階段診斷儀讀不到任何有效歷史故障碼售后也查不到故障發(fā)生時(shí)的環(huán)境數(shù)據(jù)。后來(lái)改成按照AUTOSAR診斷事件管理的流程在Dem中注冊(cè)DTC把故障發(fā)生時(shí)的電壓、電流、溫度等上下文數(shù)據(jù)寫進(jìn)“事件快照數(shù)據(jù)”。這樣才能完整支撐售后診斷和生產(chǎn)下線檢測(cè)。這里我多說(shuō)一句BMS的診斷設(shè)計(jì)應(yīng)該從項(xiàng)目需求階段就開(kāi)始定義而不是最后“補(bǔ)”。哪些故障是DTC哪些只是Debug日志哪些需要在故障消失后保持狀態(tài)一段時(shí)間——這三類處理邏輯完全不一樣。3.5 ECUC與工具鏈配置世界的入口ECUCECU Configuration是AUTOSAR配置參數(shù)的統(tǒng)稱。無(wú)論你用Vector DaVinci Configurator Pro、EB tresos還是其他工具本質(zhì)上做的都是同一件事描述這顆ECU使用哪些BSW模塊每個(gè)模塊的參數(shù)是什么模塊之間的依賴關(guān)系怎么建立。在BMS項(xiàng)目里用到的最核心ECUC配置點(diǎn)包括MCU時(shí)鐘樹(shù)和內(nèi)核分配、Adc通道與采集通道的映射、PWM通道與主動(dòng)均衡控制引腳映射、CanController和CanChannel配置、以及OS任務(wù)和SWC Runnable之間的映射關(guān)系。在配置工具里改一個(gè)參數(shù)生成的代碼行為就可能完全不同。我見(jiàn)過(guò)有同事把Adc采樣通道順序配置錯(cuò)了結(jié)果所有單體電壓全部錯(cuò)位——這種問(wèn)題如果只看ASW代碼永遠(yuǎn)找不到根因。帶著問(wèn)題去理解ECUC效率會(huì)高很多。不要被工具界面里幾百個(gè)選項(xiàng)嚇到你只需要先搞清楚與自己負(fù)責(zé)模塊相關(guān)的參數(shù)頁(yè)就夠了。4. ASW側(cè)的設(shè)計(jì)邏輯SWC、端口與Runnable在BMS中的實(shí)踐很多算法工程師第一次接觸ASW時(shí)最不適應(yīng)的就是“代碼不再是自己直接寫的一個(gè)main函數(shù)”而是被拆成了一個(gè)個(gè)帶嚴(yán)格接口的軟件組件。這需要轉(zhuǎn)變思維。4.1 用SWC重新審視BMS功能架構(gòu)一個(gè)典型的BMS應(yīng)用層可以拆成這些SWC信號(hào)采集SWC負(fù)責(zé)把ADC采樣值、溫度通道、電流傳感器信號(hào)轉(zhuǎn)換成物理量SOC估算SWC包含安時(shí)積分、OCV查表、卡爾曼濾波等算法SOH估算SWC管理容量衰減、內(nèi)阻增長(zhǎng)等性能指標(biāo)均衡控制SWC根據(jù)單體電壓差異生成均衡策略絕緣檢測(cè)SWC控制注入信號(hào)、讀取絕緣電阻值保護(hù)邏輯SWC根據(jù)關(guān)鍵參數(shù)觸發(fā)故障處理和繼電器控制。每個(gè)SWC都有自己的獨(dú)立內(nèi)存和對(duì)外端口內(nèi)部Runnable就是具體算法函數(shù)。你在Simulink里建的模型通過(guò)AUTOSAR Blockset或者Embedded Coder生成時(shí)可以直接映射成SWC和Runnable——這個(gè)流程現(xiàn)在工程師用得很多但前提是你先在工具里把接口定義清楚。4.2 端口與接口數(shù)據(jù)不是靠全局變量傳遞的傳統(tǒng)嵌入式里模塊之間傳數(shù)據(jù)最直接的辦法是全局變量。AUTOSAR ASW不允許這樣做SWC之間必須通過(guò)端口Port和接口Interface通信。接口分成兩類發(fā)送者-接收者接口Sender-Receiver和客戶端-服務(wù)端接口Client-Server。前者適合周期性的數(shù)據(jù)流比如把電壓采樣結(jié)果發(fā)給SOC估算組件后者適合請(qǐng)求-響應(yīng)式操作比如某個(gè)組件請(qǐng)求執(zhí)行一次均衡。在配置工具里建立端口和接口時(shí)最需要關(guān)注的是“映射”這個(gè)動(dòng)作。RTE會(huì)把發(fā)送端口的變量值和接收端口的變量值自動(dòng)對(duì)接但這里有個(gè)隱藏問(wèn)題發(fā)送方和接收方如果不在同一個(gè)任務(wù)周期數(shù)據(jù)可能會(huì)被跳變或延遲一拍。你需要在配置時(shí)把通信周期、數(shù)據(jù)接收緩沖策略最近一次值還是排隊(duì)配置合理。4.3 Runnable的觸發(fā)方式直接影響B(tài)MS時(shí)序每個(gè)Runnable必須綁定一個(gè)觸發(fā)事件RTE才會(huì)在正確的時(shí)機(jī)調(diào)用它。常見(jiàn)的觸發(fā)類型有周期觸發(fā)Periodic、事件觸發(fā)Event、數(shù)據(jù)接收觸發(fā)DataReceived、模式切換觸發(fā)ModeSwitch等。BMS里保護(hù)邏輯建議用事件觸發(fā)而且要綁在高優(yōu)先級(jí)任務(wù)上。舉個(gè)例子絕緣采集SWC檢測(cè)到絕緣電阻驟降這個(gè)事件必須立刻觸發(fā)繼電器保護(hù)操作而不是等下一個(gè)100ms周期才處理。SOC濾波算法這類低頻且計(jì)算量大的Runnable放到低優(yōu)先級(jí)周期任務(wù)里合適。這里有個(gè)我反復(fù)強(qiáng)調(diào)的觀點(diǎn)架構(gòu)階段如果不設(shè)計(jì)好Runnable的觸發(fā)方式和優(yōu)先級(jí)后期優(yōu)化只能靠“超頻”來(lái)補(bǔ)救要么提高任務(wù)周期密度要么調(diào)整算法效率整個(gè)系統(tǒng)變得很難維護(hù)。5. 把ASW和BSW拼起來(lái)從配置到代碼生成的完整流程理解了分層邏輯后最終還是要落實(shí)到工程實(shí)現(xiàn)。在BMS項(xiàng)目里把ASW和BSW“拼接”起來(lái)的工作流是固定的。5.1 使用圖形化配置工具定義ECU整體結(jié)構(gòu)拿Vector工具鏈舉例DaVinci Developer用來(lái)定義SWC和端口DaVinci Configurator Pro用來(lái)配置BSW和生成RTE。EB tresos也是一套高效的BSW配置工具很多國(guó)內(nèi)項(xiàng)目也在用。還有一些OEM會(huì)提供自己的流程和模板。配置的順序我建議從硬件側(cè)向軟件側(cè)推進(jìn)第一步定義MCU時(shí)鐘、內(nèi)核、外設(shè)資源第二步做MCAL配置Port、Adc、Can、Pwm、Spi等第三步配置BSW服務(wù)層OS、NvM、Com、Dcm、Dem、EcuM第四步在ASW側(cè)定義SWC并建立Runnable最后在RTE配置里把SWC的Runnable和OS任務(wù)綁定并完成端口的數(shù)據(jù)映射。實(shí)際操作中特別容易出問(wèn)題的是“通信路徑”的定義。AUTOSAR里從ASW信號(hào)到CAN報(bào)文要經(jīng)過(guò)Signal→PDU→Frame→CanIf→CanDrv一連串映射光這些映射關(guān)系在工具里就有好幾層樹(shù)形頁(yè)面。每個(gè)環(huán)節(jié)的命名規(guī)則如果沒(méi)統(tǒng)一生成代碼后調(diào)試起來(lái)就是一場(chǎng)災(zāi)難。我強(qiáng)烈建議項(xiàng)目一開(kāi)始定義好命名規(guī)范和縮寫表比如“Sig_SoC_Pct”“Pdu_Bms_Stat_10ms”“Frame_Bms_Stat_10ms”這種清晰的層級(jí)命名。5.2 生成RTE與BSW代碼配置完成之后工具會(huì)生成一組C代碼BSW模塊代碼、MCAL驅(qū)動(dòng)代碼、RTE代碼。RTE是應(yīng)用層和基礎(chǔ)軟件層的“膠水層”它內(nèi)部包含了所有SWC Runable的調(diào)用邏輯、端口數(shù)據(jù)讀寫函數(shù)和通信接口。一個(gè)簡(jiǎn)單Runnable的生成代碼大致長(zhǎng)這樣/* RTE生成的函數(shù)聲明示例 */ void Runnable_SOC_Estimation(void) { float32 soc; /* 應(yīng)用層代碼邏輯 */ soc SoC_AlgorithmCore(); /* 通過(guò)RTE接口發(fā)送給其他SWC */ Rte_Write_SoCOutput_SOC_Value(soc); }你不用手寫RTE內(nèi)部實(shí)現(xiàn)工具會(huì)處理任務(wù)掛接、數(shù)據(jù)一致性保護(hù)、跨核通信這些底層細(xì)節(jié)。這也是AUTOSAR的價(jià)值——把重復(fù)性工作自動(dòng)化讓工程師專注在算法和策略上。5.3 最小可運(yùn)行的BMS AUTOSAR工程如果你是第一次在BMS項(xiàng)目里做AUTOSAR集成我強(qiáng)烈建議別追求“一步到位”。先搭一個(gè)最小工程把最簡(jiǎn)單的鏈路跑通一個(gè)ADC采樣SWC采集單體電壓→一個(gè)RTE路由→一個(gè)CAN上報(bào)SWC把電壓打包發(fā)給整車。整個(gè)工程只包含必要的MCAL、OS、COM和RTE其他模塊先關(guān)閉。這樣做的三個(gè)好處第一你能快速理解工具生成代碼、編譯、下載、運(yùn)行的全流程第二可以在最小工程上驗(yàn)證MCU時(shí)鐘和引腳配置是否正確第三后續(xù)每增加一個(gè)模塊都有清晰的參考基線出了問(wèn)題能夠快速對(duì)比。我從實(shí)際經(jīng)驗(yàn)說(shuō)先跑通最小工程再擴(kuò)展比直接搭一個(gè)Monolithic大工程再調(diào)試要省幾倍時(shí)間。6. 典型BMS場(chǎng)景拆解從單體電壓采集到整車報(bào)文理論講了一大堆最終還是要在具體場(chǎng)景里把鏈路走通。我選三個(gè)BMS中最有代表性的場(chǎng)景來(lái)拆解。6.1 場(chǎng)景一單體電壓采集、SOC估算與上報(bào)信號(hào)采集SWC里的一個(gè)Runnable以10ms周期運(yùn)行從Adc接口讀取AFE芯片經(jīng)過(guò)調(diào)理后的單體電壓值轉(zhuǎn)換成物理量后通過(guò)發(fā)送端口發(fā)出。RTE把這個(gè)數(shù)據(jù)寫入變量然后觸發(fā)SOC估算SWC的數(shù)據(jù)接收事件。SOC估算SWC內(nèi)部一個(gè)100ms周期的Runnable啟動(dòng)安時(shí)積分和OCV補(bǔ)償運(yùn)算把估算結(jié)果通過(guò)輸出端口發(fā)送。這個(gè)結(jié)果經(jīng)過(guò)RTE映射到COM模塊COM又把這個(gè)信號(hào)打包進(jìn)周期為100ms的CAN報(bào)文。整車控制器通過(guò)總線解析這個(gè)報(bào)文顯示當(dāng)前剩余電量。這個(gè)鏈路最常見(jiàn)的排查點(diǎn)就是數(shù)據(jù)流向。如果整車收到SOC但值一直是0先查SOC估算SWC的輸入端口有沒(méi)有值如果輸入沒(méi)問(wèn)題再查RTE到COM的信號(hào)映射最后看CAN報(bào)文是否真實(shí)發(fā)送。沿著ASW→RTE→BSW這條路徑去查比瞎改代碼高效得多。6.2 場(chǎng)景二絕緣檢測(cè)與繼電器保護(hù)BMS運(yùn)行時(shí)需要周期性檢測(cè)高壓回路對(duì)地絕緣電阻。絕緣檢測(cè)SWC發(fā)送一個(gè)事件請(qǐng)求采樣電路執(zhí)行一次注入測(cè)量然后等待結(jié)果。這個(gè)場(chǎng)景適合用Client-Server接口——絕緣檢測(cè)SWC作為客戶端調(diào)用服務(wù)端驅(qū)動(dòng)SWC的“執(zhí)行絕緣檢測(cè)并返回電阻值”的接口。如果檢測(cè)到絕緣電阻低于安全閾值保護(hù)邏輯SWC需要立刻斷開(kāi)主繼電器。此時(shí)我建議設(shè)計(jì)為兩條路徑同時(shí)觸發(fā)一條是絕緣檢測(cè)SWC內(nèi)部根據(jù)電阻值直接置“故障”事件通過(guò)RTE同步觸發(fā)保護(hù)Runnable另一條是把絕緣電阻值周期性上傳到BSW的Dem記錄故障碼和當(dāng)時(shí)的總壓、溫度等環(huán)境數(shù)據(jù)。這樣既保證保護(hù)動(dòng)作的時(shí)效又保留診斷信息。這里涉及一個(gè)重要的調(diào)度設(shè)計(jì)保護(hù)Runnable必須綁定在最高優(yōu)先級(jí)的任務(wù)上且不能被長(zhǎng)時(shí)間屏蔽。AUTOSAR OS里的關(guān)鍵路徑要設(shè)置中斷和調(diào)度保護(hù)防止一個(gè)長(zhǎng)時(shí)間運(yùn)行的低優(yōu)先級(jí)任務(wù)把保護(hù)動(dòng)作卡住。6.3 場(chǎng)景三故障存儲(chǔ)與下電時(shí)序BMS發(fā)生故障后除了實(shí)時(shí)保護(hù)還要把故障信息保存下來(lái)。實(shí)際項(xiàng)目里故障存儲(chǔ)往往不是實(shí)時(shí)寫NvM而是先寫到Dem的事件緩存等到合適的時(shí)機(jī)再進(jìn)行NvM寫操作。如果故障發(fā)生瞬間斷電則靠EcuM的下電時(shí)序處理。我遇到過(guò)一個(gè)售后問(wèn)題客戶反饋車輛長(zhǎng)時(shí)間停放后SOC記憶丟失每次重新上電都要重新估算。排查發(fā)現(xiàn)是NvM寫操作放在正常運(yùn)行周期里數(shù)據(jù)塊頻繁寫后來(lái)觸發(fā)寫入保護(hù)機(jī)制有些寫被丟棄了。改成在下電流程里集中寫一次并在每次正常運(yùn)行時(shí)保留最新數(shù)據(jù)到RAM緩存中問(wèn)題才解決。這也是為何AUTOSAR的EcuM和NvM協(xié)作機(jī)制如此重要。7. 常見(jiàn)誤區(qū)和實(shí)戰(zhàn)心得那些“從入門到放棄”的坑最后說(shuō)說(shuō)學(xué)習(xí)這個(gè)技術(shù)體系最常見(jiàn)的幾個(gè)坑。很多人都想一步到位搞懂AUTOSAR結(jié)果被規(guī)范和工具界面勸退這很自然。7.1 誤區(qū)一把BSW當(dāng)成普通驅(qū)動(dòng)庫(kù)來(lái)改有一些嵌入式底子不錯(cuò)的工程師看到BSW生成的代碼后第一反應(yīng)是“這代碼寫得太繞了我直接改一下驅(qū)動(dòng)文件不就行了”。這是很危險(xiǎn)的。BSW模塊之間有嚴(yán)格的接口依賴你手動(dòng)改了一處生成的代碼下一次可能被覆蓋或者導(dǎo)致其他模塊接口不一致。正確的做法是所有配置都通過(guò)ECUC工具完成代碼生成后不要手改生成文件。實(shí)在需要定制行為用模塊提供的回調(diào)接口或者復(fù)雜的配置選項(xiàng)去實(shí)現(xiàn)。7.2 誤區(qū)二算法跑得好不等于系統(tǒng)時(shí)序好很多算法在離線仿真里完美上車運(yùn)行后偶發(fā)表現(xiàn)不佳。原因經(jīng)常不是算法本身而是Runnable和任務(wù)之間的綁定關(guān)系錯(cuò)了。比如你把一個(gè)計(jì)算量龐大的SOH估算Runnable綁定在10ms任務(wù)上這就把系統(tǒng)拖垮了。經(jīng)驗(yàn)是任務(wù)周期只放它該放的東西算不準(zhǔn)和算不快是兩回事。7.3 學(xué)習(xí)方法建議從一個(gè)小切入口打通全鏈路如果讓我重新學(xué)一遍我會(huì)選擇這樣的路徑選一個(gè)BMS里的最小場(chǎng)景比如單體電壓采集并CAN上報(bào)先看RTE生成的代碼搞懂應(yīng)用函數(shù)是怎么被調(diào)用的再回到配置工具里看對(duì)應(yīng)的配置項(xiàng)搞清楚改一個(gè)周期、一個(gè)端口名生成的代碼會(huì)發(fā)生什么變化最后再逐步引入NvM、診斷、網(wǎng)絡(luò)管理等模塊。別忘了多利用Automotive行業(yè)里開(kāi)源的示例以及工具廠商自帶的例程。讀規(guī)范原文很重要但不是從第一個(gè)字開(kāi)始啃。我通常先看某個(gè)具體模塊的Overview再看示例工程確定它怎么用起來(lái)的然后遇到細(xì)節(jié)問(wèn)題再去規(guī)范里查精確描述這樣“從放棄到入門”的距離會(huì)縮短很多。坦白說(shuō)AUTOSAR這套體系不完美工具鏈龐雜、學(xué)習(xí)曲線陡峭但它確實(shí)是目前汽車電子軟件走向平臺(tái)化的主流答案。對(duì)BMS工程師而言主動(dòng)去理解ASW與BSW的分層邏輯不是給自己的工作找麻煩而是給未來(lái)幾年的職業(yè)發(fā)展換一條更寬的賽道。 從ASW到BSW：BMS工程師必懂的AUTOSAR分層架構(gòu)
1. 為什么BMS工程師繞不開(kāi)AUTOSAR見(jiàn)過(guò)不少?gòu)腗ATLAB/Simulink模型起步的BMS工程師一開(kāi)始接觸AUTOSAR都有點(diǎn)抗拒。我自己也是。當(dāng)時(shí)項(xiàng)目組拿到客戶的新需求——軟件架構(gòu)必須按照AUTOSAR分層來(lái)ASW、RTE、BSW這些詞突然鋪天蓋地地出現(xiàn)在評(píng)審會(huì)上。我腦子里第一反應(yīng)是我只要能把SOC、SOH算準(zhǔn)把均衡和繼電器控制做好不就行了為什么非要套一層這么復(fù)雜的“殼”真正改變我看法的是一個(gè)下午的聯(lián)調(diào)現(xiàn)場(chǎng)。BMS樣件上電以后控制器一直報(bào)通信超時(shí)但用示波器看CAN波形完全正常報(bào)文也在發(fā)。最后查下來(lái)問(wèn)題根本不在算法也不在硬件而是BSW層的通信棧配置和ASW側(cè)的任務(wù)周期對(duì)不上——某個(gè)關(guān)鍵的控制信號(hào)沒(méi)有按照預(yù)期時(shí)間被發(fā)送出去。那一刻我意識(shí)到如果不懂ASW與BSW的分層邏輯和工作邊界你連排查問(wèn)題的入手點(diǎn)都找不到。1.1 BMS的開(kāi)發(fā)模式正在從“裸機(jī)”走向“平臺(tái)化”傳統(tǒng)BMS開(kāi)發(fā)普遍是“一個(gè)單片機(jī)加一堆驅(qū)動(dòng)庫(kù)”底層ADC采樣自己初始化CAN收發(fā)自己寫寄存器故障存儲(chǔ)直接操作EEPROM應(yīng)用代碼和硬件代碼攪在一起。只要換一顆MCU整套軟件都要?jiǎng)右槐橐浦渤杀緲O高。但今天OEM和Tier 1的交付要求已經(jīng)變了很多新項(xiàng)目直接把“符合AUTOSAR架構(gòu)”寫進(jìn)技術(shù)協(xié)議里供應(yīng)商如果沒(méi)有按標(biāo)準(zhǔn)分層交付驗(yàn)收那關(guān)就過(guò)不去。AUTOSAR解決的正是這個(gè)問(wèn)題。它把汽車電子軟件抽象成一組標(biāo)準(zhǔn)化的層次應(yīng)用層只做控制邏輯底層驅(qū)動(dòng)由標(biāo)準(zhǔn)化模塊接管中間通過(guò)RTE通信。BMS作為整車安全件涉及高壓采樣、絕緣監(jiān)測(cè)、繼電器驅(qū)動(dòng)、熱管理、整車通信等一大堆功能恰恰是從這個(gè)平臺(tái)化中受益最多的系統(tǒng)之一。因?yàn)锽MS的硬件平臺(tái)迭代很快——從分布式采集板到域控集成式方案從單MCU到多核MCU——沒(méi)有AUTOSAR這種分層每一次硬件升級(jí)都是災(zāi)難。1.2 “會(huì)用”和“懂架構(gòu)”是兩回事很多BMS工程師會(huì)用工具比如用Vector的DaVinci或者EB tresos把配置刷一遍生成代碼編譯燒錄能跑起來(lái)就覺(jué)得完事了。但這屬于“會(huì)用”。真正遇到問(wèn)題的時(shí)候——為什么這個(gè)信號(hào)沒(méi)發(fā)出去為什么掉電后NvM里存的數(shù)據(jù)丟了為什么一個(gè)任務(wù)把另一個(gè)任務(wù)餓死了——你如果沒(méi)有ASW和BSW的底層認(rèn)知就只能靠猜。舉個(gè)最常見(jiàn)的例子ASW里寫了一個(gè)狀態(tài)機(jī)某個(gè)狀態(tài)下要把“允許充電”這個(gè)信號(hào)置1。但整車端一直收不到或者收到了但值不對(duì)。如果你不懂ASW信號(hào)是通過(guò)RTE映射到BSW的COM模塊、再經(jīng)過(guò)PDUR、CAN接口才能變成一幀CAN報(bào)文的你就很難判斷問(wèn)題出在RTE的端口映射、COM的信號(hào)打包還是PDUR的路由配置。這已經(jīng)不是“把代碼寫對(duì)”的問(wèn)題而是“把架構(gòu)搞清楚”的問(wèn)題。1.3 哪些人應(yīng)該重點(diǎn)學(xué)習(xí)這部分內(nèi)容我不建議所有人都一頭扎進(jìn)去啃全套規(guī)范。優(yōu)先需要弄懂ASW與BSW的是這幾類人第一做BMS應(yīng)用層算法集成的工程師你需要知道自己的算法如何變成周期任務(wù)、如何和底層交互第二做BMS底層軟件和MCAL集成的工程師你需要搞清楚BSW模塊的依賴關(guān)系和配置參數(shù)第三做系統(tǒng)測(cè)試和整車聯(lián)調(diào)的工程師你要能快速定位故障是出在應(yīng)用邏輯還是基礎(chǔ)軟件層。這篇文章就圍繞“ASW和BSW到底各自是什么、在BMS場(chǎng)景里怎么配合”來(lái)展開(kāi)。我不會(huì)去抄規(guī)范文檔而是按照實(shí)際工程中的理解和踩坑經(jīng)驗(yàn)來(lái)講。2. AUTOSAR的分層邏輯ASW、RTE、BSW的邊界到底在哪AUTOSAR最核心的思想就是“分層”每一層只關(guān)心自己的事層與層之間通過(guò)標(biāo)準(zhǔn)接口對(duì)話。對(duì)于BMS工程師來(lái)說(shuō)理解這三個(gè)層次就是理解整個(gè)架構(gòu)的地圖。2.1 一張圖說(shuō)清AUTOSAR的橫向分層從上往下看AUTOSAR經(jīng)典平臺(tái)大致分四層應(yīng)用層ASW、運(yùn)行時(shí)環(huán)境RTE、基礎(chǔ)軟件層BSW、微控制器抽象層MCAL。另外還有復(fù)雜驅(qū)動(dòng)CDD這個(gè)概念——但先不展開(kāi)后面會(huì)提到。層次包含內(nèi)容在BMS中的典型對(duì)應(yīng)應(yīng)用層ASW軟件組件SWC、內(nèi)部行為、可運(yùn)行實(shí)體RunnableSOC/SOH算法、均衡策略、絕緣檢測(cè)策略、繼電器控制邏輯運(yùn)行時(shí)環(huán)境RTE通信基礎(chǔ)設(shè)施、任務(wù)實(shí)體生成、端口連接數(shù)據(jù)從電壓采集SWC傳遞到SOC估算SWC服務(wù)層BSW上層OS、EcuM、BswM、NvM、Dcm、Dem、Com、PduR等任務(wù)調(diào)度、故障管理、診斷服務(wù)、非易失存儲(chǔ)ECU抽象層BSW中層與具體外設(shè)無(wú)關(guān)的抽象驅(qū)動(dòng)接口CAN接口、IO抽象、ADC抽象微控制器抽象層MCAL直接操作寄存器的驅(qū)動(dòng)Port、Dio、Adc、Pwm、Spi、Can驅(qū)動(dòng)ASW的主體是軟件組件。你可以把一個(gè)SWC理解成一個(gè)“帶清晰邊界的功能模塊”比如“SOC估算組件”“單體均衡組件”“絕緣監(jiān)測(cè)組件”。每個(gè)SWC內(nèi)部有若干個(gè)Runnable相當(dāng)于C語(yǔ)言里的函數(shù)——但它們的觸發(fā)方式不是誰(shuí)調(diào)用誰(shuí)而是由RTE按周期或事件來(lái)觸發(fā)。BSW則是“功能提供方”和“資源管理方”。它不關(guān)心你SOC算得準(zhǔn)不準(zhǔn)它只負(fù)責(zé)保證每個(gè)任務(wù)在正確的時(shí)間被調(diào)度、把CAN報(bào)文發(fā)出去、把數(shù)據(jù)存進(jìn)非易失存儲(chǔ)器、對(duì)外提供診斷服務(wù)。RTE夾在中間角色很特殊。它不是一個(gè)常規(guī)意義上的“模塊”而是為每個(gè)ECU自動(dòng)生成的一段代碼層。它的職責(zé)是把SWC需要的數(shù)據(jù)從生產(chǎn)者送達(dá)到消費(fèi)者把Runnable的調(diào)用時(shí)機(jī)和OS任務(wù)綁定起來(lái)屏蔽應(yīng)用對(duì)BSW的直接訪問(wèn)。換句話說(shuō)如果ASW是員工BSW是公司的財(cái)務(wù)和行政那RTE就是OA系統(tǒng)——所有報(bào)銷單都要通過(guò)它流轉(zhuǎn)。2.2 為什么邊界劃分這么重要很多剛接觸AUTOSAR的人會(huì)問(wèn)一個(gè)問(wèn)題既然BSW已經(jīng)把ADC采樣、CAN收發(fā)都封裝好了那是不是ASW里可以直接調(diào)這些函數(shù)答案是不行。AUTOSAR架構(gòu)強(qiáng)制的規(guī)則就是ASW不能直接調(diào)用BSW的接口必須通過(guò)RTE。原因很現(xiàn)實(shí)一旦允許ASW直接操作底層那么“應(yīng)用軟件可移植”就變成一句空話。你換了一顆MCU底層驅(qū)動(dòng)變了應(yīng)用代碼里還留著對(duì)舊寄存器的直接調(diào)用那就又退回傳統(tǒng)的嵌入式開(kāi)發(fā)模式了。在BMS項(xiàng)目里這種分離還有一個(gè)額外的價(jià)值功能安全。BMS通常要求ASIL C甚至ASIL D等級(jí)的開(kāi)發(fā)流程。分層架構(gòu)天然把“安全算法邏輯”和“底層資源管理”隔離每條數(shù)據(jù)鏈路、每次任務(wù)觸發(fā)都變得可追溯。審查員問(wèn)起來(lái)“這個(gè)保護(hù)功能是從哪個(gè)Runnable觸發(fā)的數(shù)據(jù)從哪里來(lái)走了哪條通信路徑”——如果你能清晰回答這就是分層架構(gòu)最大的回報(bào)。2.3 復(fù)雜驅(qū)動(dòng)CDD的定位實(shí)際BMS里總會(huì)遇到一些AUTOSAR標(biāo)準(zhǔn)模塊覆蓋不了的功能比如某些廠家的專用IC溫度采樣協(xié)議、特定AFE芯片的菊花鏈采集時(shí)序。這類驅(qū)動(dòng)如果硬塞進(jìn)應(yīng)用層會(huì)破壞可移植性如果硬套MCAL標(biāo)準(zhǔn)接口又很別扭。AUTOSAR允許用復(fù)雜驅(qū)動(dòng)CDD來(lái)承載這部分非標(biāo)準(zhǔn)化的功能。CDD可以直接放在BSW里給上層提供相對(duì)標(biāo)準(zhǔn)的接口但內(nèi)部實(shí)現(xiàn)可以保留硬件相關(guān)的邏輯。這塊我只說(shuō)一句經(jīng)驗(yàn)不要輕易把所有不好歸類的代碼都塞進(jìn)CDD。CDD用多了架構(gòu)就退化成一堆“補(bǔ)丁”后續(xù)軟件升級(jí)和維護(hù)會(huì)很痛苦。能用標(biāo)準(zhǔn)模塊解決的盡量用標(biāo)準(zhǔn)模塊。3. BSW里BMS工程師必須重點(diǎn)掌握的模塊BSW涵蓋的模塊非常多但它內(nèi)部的層次結(jié)構(gòu)是清晰的服務(wù)層管調(diào)度、存儲(chǔ)、診斷和通信ECU抽象層管接口統(tǒng)一MCAL管寄存器操作。這里我不打算把幾十個(gè)模塊都過(guò)一遍只挑BMS工程師在項(xiàng)目里打交道最多的五個(gè)方向。3.1 AUTOSAR OSBMS任務(wù)的搶占與調(diào)度AUTOSAR OS是BMS軟件的“心臟”。BMS里任務(wù)天然分輕重緩急單體電壓采樣、絕緣檢測(cè)這些涉及安全的計(jì)算必須嚴(yán)格按時(shí)完成而均衡策略、SOC濾波這類周期性任務(wù)可以稍微“讓路”。實(shí)際項(xiàng)目中你可能需要配置這樣幾個(gè)任務(wù)10ms周期任務(wù)跑電壓電流采樣和短路保護(hù)判斷50ms任務(wù)跑絕緣監(jiān)測(cè)狀態(tài)機(jī)100ms任務(wù)跑SOC估算500ms任務(wù)跑均衡策略。高優(yōu)先級(jí)的任務(wù)搶占低優(yōu)先級(jí)任務(wù)這是AUTOSAR OS的標(biāo)準(zhǔn)行為。配置OS時(shí)最核心的幾個(gè)參數(shù)任務(wù)優(yōu)先級(jí)、調(diào)度策略搶占或協(xié)作、激活次數(shù)、周期、以及任務(wù)體量。我的建議是在BMS項(xiàng)目中優(yōu)先采用搶占式調(diào)度因?yàn)橥耆揽繀f(xié)作式調(diào)度很難保證極端工況下的保護(hù)響應(yīng)時(shí)間。另一個(gè)容易踩的坑是優(yōu)先級(jí)反轉(zhuǎn)——高優(yōu)先級(jí)任務(wù)等待的共享資源被低優(yōu)先級(jí)任務(wù)占著這時(shí)候需要配置優(yōu)先級(jí)天花板協(xié)議或者立即繼承協(xié)議。BMS是安全件這類問(wèn)題必須在設(shè)計(jì)階段就規(guī)避。3.2 NvM關(guān)鍵時(shí)刻的數(shù)據(jù)居然沒(méi)存住NvM非易失存儲(chǔ)器管理負(fù)責(zé)管理EEPROM或Flash類存儲(chǔ)。BMS里哪些數(shù)據(jù)需要存SOC初值、SOH衰減因子、故障碼和故障凍結(jié)幀、標(biāo)定參數(shù)、生產(chǎn)下線信息、累計(jì)充放電安時(shí)數(shù)等。這些數(shù)據(jù)如果掉電丟了輕則SOC跳變重則影響售后診斷。NvM里有幾個(gè)概念BMS工程師必須搞清楚NV Block數(shù)據(jù)塊、Block狀態(tài)、數(shù)據(jù)校驗(yàn)、以及讀/寫時(shí)機(jī)。最常見(jiàn)的錯(cuò)誤是NvM寫入時(shí)機(jī)和任務(wù)周期不匹配——某段邏輯在正常運(yùn)行周期里反復(fù)觸發(fā)NvM寫操作導(dǎo)致Flash壽命迅速耗盡或者等到下電瞬間才開(kāi)始寫但硬件掉電時(shí)間根本不夠?qū)懲?。我建議的做法是分成“正常周期寫”和“掉電保護(hù)寫”兩種策略。周期性的SOC初值等數(shù)據(jù)用比較低的頻率比如每30秒一次或者每次值變化超過(guò)閾值時(shí)寫入掉電瞬間的關(guān)鍵數(shù)據(jù)則由BSW的EcuM接管保證下電時(shí)序里預(yù)留出足夠的時(shí)間完成最后一次寫操作。不要依賴在應(yīng)用代碼里“最后時(shí)刻寫NvM”競(jìng)爭(zhēng)風(fēng)險(xiǎn)太大。3.3 COM與網(wǎng)絡(luò)管理CAN報(bào)文不是你想發(fā)就能發(fā)COM模塊負(fù)責(zé)信號(hào)Signal、PDU協(xié)議數(shù)據(jù)單元和報(bào)文Frame之間的映射。ASW里的SOC信號(hào)通過(guò)RTE傳給COMCOM按PDU打包進(jìn)CAN報(bào)文再由PduR、CanIf、CanDriver一層層送到總線。這個(gè)鏈路里任何一層都有可能導(dǎo)致報(bào)文發(fā)不出去。以BMS和整車控制器VCU的通信為例VCU需要一個(gè)10ms周期的“BMS狀態(tài)報(bào)文”里面包含總壓、總流、SOC、絕緣電阻等信號(hào)。這個(gè)信號(hào)可能分散在好幾個(gè)SWC里。配置COM時(shí)你需要把這些信號(hào)映射到同一個(gè)PDU設(shè)置好發(fā)送周期和觸發(fā)條件。如果你只把信號(hào)映射對(duì)了但PDU的傳輸模式配置成“事件觸發(fā)”而該信號(hào)一直沒(méi)有變化那整車就收不到報(bào)文——這個(gè)問(wèn)題我用“周期性事件觸發(fā)”的組合模式來(lái)解決。再說(shuō)說(shuō)網(wǎng)絡(luò)管理。AUTOSAR網(wǎng)絡(luò)管理NM負(fù)責(zé)協(xié)調(diào)ECU的睡眠和喚醒。BMS這個(gè)系統(tǒng)很特殊整車下電后BMS通常還要保持低壓供電一段時(shí)間確保繼電器斷開(kāi)、絕緣檢測(cè)完成、高壓安全監(jiān)測(cè)還在工作。這個(gè)“延遲下電”的時(shí)序需要和整車網(wǎng)絡(luò)管理策略對(duì)齊。我實(shí)際做項(xiàng)目時(shí)發(fā)現(xiàn)很多下電異常問(wèn)題根本不是BMS算法邏輯問(wèn)題而是網(wǎng)絡(luò)管理狀態(tài)機(jī)和整車的快照喚醒/睡眠時(shí)機(jī)沒(méi)配合好。3.4 診斷模塊BMS的“病歷本”和“體檢室”診斷棧在AUTOSAR里的核心模塊是Dcm診斷通信管理和Dem診斷事件管理。Dcm負(fù)責(zé)處理UDS診斷服務(wù)比如0x10會(huì)話切換、0x22讀取標(biāo)識(shí)、0x2E寫入數(shù)據(jù)、0x31例程控制Dem負(fù)責(zé)管理故障碼DTC。BMS的項(xiàng)目中新增一個(gè)“過(guò)溫故障”不是簡(jiǎn)單地在代碼里置一個(gè)標(biāo)志位而是要在Dem里定義好DTC、故障判定條件、降級(jí)處理策略和故障存儲(chǔ)方式。這塊我自己踩過(guò)坑早期項(xiàng)目直接在ASW里寫了一句“故障標(biāo)志1”然后就把這個(gè)標(biāo)志變量發(fā)給整車。到了臺(tái)架測(cè)試階段診斷儀讀不到任何有效歷史故障碼售后也查不到故障發(fā)生時(shí)的環(huán)境數(shù)據(jù)。后來(lái)改成按照AUTOSAR診斷事件管理的流程在Dem中注冊(cè)DTC把故障發(fā)生時(shí)的電壓、電流、溫度等上下文數(shù)據(jù)寫進(jìn)“事件快照數(shù)據(jù)”。這樣才能完整支撐售后診斷和生產(chǎn)下線檢測(cè)。這里我多說(shuō)一句BMS的診斷設(shè)計(jì)應(yīng)該從項(xiàng)目需求階段就開(kāi)始定義而不是最后“補(bǔ)”。哪些故障是DTC哪些只是Debug日志哪些需要在故障消失后保持狀態(tài)一段時(shí)間——這三類處理邏輯完全不一樣。3.5 ECUC與工具鏈配置世界的入口ECUCECU Configuration是AUTOSAR配置參數(shù)的統(tǒng)稱。無(wú)論你用Vector DaVinci Configurator Pro、EB tresos還是其他工具本質(zhì)上做的都是同一件事描述這顆ECU使用哪些BSW模塊每個(gè)模塊的參數(shù)是什么模塊之間的依賴關(guān)系怎么建立。在BMS項(xiàng)目里用到的最核心ECUC配置點(diǎn)包括MCU時(shí)鐘樹(shù)和內(nèi)核分配、Adc通道與采集通道的映射、PWM通道與主動(dòng)均衡控制引腳映射、CanController和CanChannel配置、以及OS任務(wù)和SWC Runnable之間的映射關(guān)系。在配置工具里改一個(gè)參數(shù)生成的代碼行為就可能完全不同。我見(jiàn)過(guò)有同事把Adc采樣通道順序配置錯(cuò)了結(jié)果所有單體電壓全部錯(cuò)位——這種問(wèn)題如果只看ASW代碼永遠(yuǎn)找不到根因。帶著問(wèn)題去理解ECUC效率會(huì)高很多。不要被工具界面里幾百個(gè)選項(xiàng)嚇到你只需要先搞清楚與自己負(fù)責(zé)模塊相關(guān)的參數(shù)頁(yè)就夠了。4. ASW側(cè)的設(shè)計(jì)邏輯SWC、端口與Runnable在BMS中的實(shí)踐很多算法工程師第一次接觸ASW時(shí)最不適應(yīng)的就是“代碼不再是自己直接寫的一個(gè)main函數(shù)”而是被拆成了一個(gè)個(gè)帶嚴(yán)格接口的軟件組件。這需要轉(zhuǎn)變思維。4.1 用SWC重新審視BMS功能架構(gòu)一個(gè)典型的BMS應(yīng)用層可以拆成這些SWC信號(hào)采集SWC負(fù)責(zé)把ADC采樣值、溫度通道、電流傳感器信號(hào)轉(zhuǎn)換成物理量SOC估算SWC包含安時(shí)積分、OCV查表、卡爾曼濾波等算法SOH估算SWC管理容量衰減、內(nèi)阻增長(zhǎng)等性能指標(biāo)均衡控制SWC根據(jù)單體電壓差異生成均衡策略絕緣檢測(cè)SWC控制注入信號(hào)、讀取絕緣電阻值保護(hù)邏輯SWC根據(jù)關(guān)鍵參數(shù)觸發(fā)故障處理和繼電器控制。每個(gè)SWC都有自己的獨(dú)立內(nèi)存和對(duì)外端口內(nèi)部Runnable就是具體算法函數(shù)。你在Simulink里建的模型通過(guò)AUTOSAR Blockset或者Embedded Coder生成時(shí)可以直接映射成SWC和Runnable——這個(gè)流程現(xiàn)在工程師用得很多但前提是你先在工具里把接口定義清楚。4.2 端口與接口數(shù)據(jù)不是靠全局變量傳遞的傳統(tǒng)嵌入式里模塊之間傳數(shù)據(jù)最直接的辦法是全局變量。AUTOSAR ASW不允許這樣做SWC之間必須通過(guò)端口Port和接口Interface通信。接口分成兩類發(fā)送者-接收者接口Sender-Receiver和客戶端-服務(wù)端接口Client-Server。前者適合周期性的數(shù)據(jù)流比如把電壓采樣結(jié)果發(fā)給SOC估算組件后者適合請(qǐng)求-響應(yīng)式操作比如某個(gè)組件請(qǐng)求執(zhí)行一次均衡。在配置工具里建立端口和接口時(shí)最需要關(guān)注的是“映射”這個(gè)動(dòng)作。RTE會(huì)把發(fā)送端口的變量值和接收端口的變量值自動(dòng)對(duì)接但這里有個(gè)隱藏問(wèn)題發(fā)送方和接收方如果不在同一個(gè)任務(wù)周期數(shù)據(jù)可能會(huì)被跳變或延遲一拍。你需要在配置時(shí)把通信周期、數(shù)據(jù)接收緩沖策略最近一次值還是排隊(duì)配置合理。4.3 Runnable的觸發(fā)方式直接影響B(tài)MS時(shí)序每個(gè)Runnable必須綁定一個(gè)觸發(fā)事件RTE才會(huì)在正確的時(shí)機(jī)調(diào)用它。常見(jiàn)的觸發(fā)類型有周期觸發(fā)Periodic、事件觸發(fā)Event、數(shù)據(jù)接收觸發(fā)DataReceived、模式切換觸發(fā)ModeSwitch等。BMS里保護(hù)邏輯建議用事件觸發(fā)而且要綁在高優(yōu)先級(jí)任務(wù)上。舉個(gè)例子絕緣采集SWC檢測(cè)到絕緣電阻驟降這個(gè)事件必須立刻觸發(fā)繼電器保護(hù)操作而不是等下一個(gè)100ms周期才處理。SOC濾波算法這類低頻且計(jì)算量大的Runnable放到低優(yōu)先級(jí)周期任務(wù)里合適。這里有個(gè)我反復(fù)強(qiáng)調(diào)的觀點(diǎn)架構(gòu)階段如果不設(shè)計(jì)好Runnable的觸發(fā)方式和優(yōu)先級(jí)后期優(yōu)化只能靠“超頻”來(lái)補(bǔ)救要么提高任務(wù)周期密度要么調(diào)整算法效率整個(gè)系統(tǒng)變得很難維護(hù)。5. 把ASW和BSW拼起來(lái)從配置到代碼生成的完整流程理解了分層邏輯后最終還是要落實(shí)到工程實(shí)現(xiàn)。在BMS項(xiàng)目里把ASW和BSW“拼接”起來(lái)的工作流是固定的。5.1 使用圖形化配置工具定義ECU整體結(jié)構(gòu)拿Vector工具鏈舉例DaVinci Developer用來(lái)定義SWC和端口DaVinci Configurator Pro用來(lái)配置BSW和生成RTE。EB tresos也是一套高效的BSW配置工具很多國(guó)內(nèi)項(xiàng)目也在用。還有一些OEM會(huì)提供自己的流程和模板。配置的順序我建議從硬件側(cè)向軟件側(cè)推進(jìn)第一步定義MCU時(shí)鐘、內(nèi)核、外設(shè)資源第二步做MCAL配置Port、Adc、Can、Pwm、Spi等第三步配置BSW服務(wù)層OS、NvM、Com、Dcm、Dem、EcuM第四步在ASW側(cè)定義SWC并建立Runnable最后在RTE配置里把SWC的Runnable和OS任務(wù)綁定并完成端口的數(shù)據(jù)映射。實(shí)際操作中特別容易出問(wèn)題的是“通信路徑”的定義。AUTOSAR里從ASW信號(hào)到CAN報(bào)文要經(jīng)過(guò)Signal→PDU→Frame→CanIf→CanDrv一連串映射光這些映射關(guān)系在工具里就有好幾層樹(shù)形頁(yè)面。每個(gè)環(huán)節(jié)的命名規(guī)則如果沒(méi)統(tǒng)一生成代碼后調(diào)試起來(lái)就是一場(chǎng)災(zāi)難。我強(qiáng)烈建議項(xiàng)目一開(kāi)始定義好命名規(guī)范和縮寫表比如“Sig_SoC_Pct”“Pdu_Bms_Stat_10ms”“Frame_Bms_Stat_10ms”這種清晰的層級(jí)命名。5.2 生成RTE與BSW代碼配置完成之后工具會(huì)生成一組C代碼BSW模塊代碼、MCAL驅(qū)動(dòng)代碼、RTE代碼。RTE是應(yīng)用層和基礎(chǔ)軟件層的“膠水層”它內(nèi)部包含了所有SWC Runable的調(diào)用邏輯、端口數(shù)據(jù)讀寫函數(shù)和通信接口。一個(gè)簡(jiǎn)單Runnable的生成代碼大致長(zhǎng)這樣/* RTE生成的函數(shù)聲明示例 */ void Runnable_SOC_Estimation(void) { float32 soc; /* 應(yīng)用層代碼邏輯 */ soc SoC_AlgorithmCore(); /* 通過(guò)RTE接口發(fā)送給其他SWC */ Rte_Write_SoCOutput_SOC_Value(soc); }你不用手寫RTE內(nèi)部實(shí)現(xiàn)工具會(huì)處理任務(wù)掛接、數(shù)據(jù)一致性保護(hù)、跨核通信這些底層細(xì)節(jié)。這也是AUTOSAR的價(jià)值——把重復(fù)性工作自動(dòng)化讓工程師專注在算法和策略上。5.3 最小可運(yùn)行的BMS AUTOSAR工程如果你是第一次在BMS項(xiàng)目里做AUTOSAR集成我強(qiáng)烈建議別追求“一步到位”。先搭一個(gè)最小工程把最簡(jiǎn)單的鏈路跑通一個(gè)ADC采樣SWC采集單體電壓→一個(gè)RTE路由→一個(gè)CAN上報(bào)SWC把電壓打包發(fā)給整車。整個(gè)工程只包含必要的MCAL、OS、COM和RTE其他模塊先關(guān)閉。這樣做的三個(gè)好處第一你能快速理解工具生成代碼、編譯、下載、運(yùn)行的全流程第二可以在最小工程上驗(yàn)證MCU時(shí)鐘和引腳配置是否正確第三后續(xù)每增加一個(gè)模塊都有清晰的參考基線出了問(wèn)題能夠快速對(duì)比。我從實(shí)際經(jīng)驗(yàn)說(shuō)先跑通最小工程再擴(kuò)展比直接搭一個(gè)Monolithic大工程再調(diào)試要省幾倍時(shí)間。6. 典型BMS場(chǎng)景拆解從單體電壓采集到整車報(bào)文理論講了一大堆最終還是要在具體場(chǎng)景里把鏈路走通。我選三個(gè)BMS中最有代表性的場(chǎng)景來(lái)拆解。6.1 場(chǎng)景一單體電壓采集、SOC估算與上報(bào)信號(hào)采集SWC里的一個(gè)Runnable以10ms周期運(yùn)行從Adc接口讀取AFE芯片經(jīng)過(guò)調(diào)理后的單體電壓值轉(zhuǎn)換成物理量后通過(guò)發(fā)送端口發(fā)出。RTE把這個(gè)數(shù)據(jù)寫入變量然后觸發(fā)SOC估算SWC的數(shù)據(jù)接收事件。SOC估算SWC內(nèi)部一個(gè)100ms周期的Runnable啟動(dòng)安時(shí)積分和OCV補(bǔ)償運(yùn)算把估算結(jié)果通過(guò)輸出端口發(fā)送。這個(gè)結(jié)果經(jīng)過(guò)RTE映射到COM模塊COM又把這個(gè)信號(hào)打包進(jìn)周期為100ms的CAN報(bào)文。整車控制器通過(guò)總線解析這個(gè)報(bào)文顯示當(dāng)前剩余電量。這個(gè)鏈路最常見(jiàn)的排查點(diǎn)就是數(shù)據(jù)流向。如果整車收到SOC但值一直是0先查SOC估算SWC的輸入端口有沒(méi)有值如果輸入沒(méi)問(wèn)題再查RTE到COM的信號(hào)映射最后看CAN報(bào)文是否真實(shí)發(fā)送。沿著ASW→RTE→BSW這條路徑去查比瞎改代碼高效得多。6.2 場(chǎng)景二絕緣檢測(cè)與繼電器保護(hù)BMS運(yùn)行時(shí)需要周期性檢測(cè)高壓回路對(duì)地絕緣電阻。絕緣檢測(cè)SWC發(fā)送一個(gè)事件請(qǐng)求采樣電路執(zhí)行一次注入測(cè)量然后等待結(jié)果。這個(gè)場(chǎng)景適合用Client-Server接口——絕緣檢測(cè)SWC作為客戶端調(diào)用服務(wù)端驅(qū)動(dòng)SWC的“執(zhí)行絕緣檢測(cè)并返回電阻值”的接口。如果檢測(cè)到絕緣電阻低于安全閾值保護(hù)邏輯SWC需要立刻斷開(kāi)主繼電器。此時(shí)我建議設(shè)計(jì)為兩條路徑同時(shí)觸發(fā)一條是絕緣檢測(cè)SWC內(nèi)部根據(jù)電阻值直接置“故障”事件通過(guò)RTE同步觸發(fā)保護(hù)Runnable另一條是把絕緣電阻值周期性上傳到BSW的Dem記錄故障碼和當(dāng)時(shí)的總壓、溫度等環(huán)境數(shù)據(jù)。這樣既保證保護(hù)動(dòng)作的時(shí)效又保留診斷信息。這里涉及一個(gè)重要的調(diào)度設(shè)計(jì)保護(hù)Runnable必須綁定在最高優(yōu)先級(jí)的任務(wù)上且不能被長(zhǎng)時(shí)間屏蔽。AUTOSAR OS里的關(guān)鍵路徑要設(shè)置中斷和調(diào)度保護(hù)防止一個(gè)長(zhǎng)時(shí)間運(yùn)行的低優(yōu)先級(jí)任務(wù)把保護(hù)動(dòng)作卡住。6.3 場(chǎng)景三故障存儲(chǔ)與下電時(shí)序BMS發(fā)生故障后除了實(shí)時(shí)保護(hù)還要把故障信息保存下來(lái)。實(shí)際項(xiàng)目里故障存儲(chǔ)往往不是實(shí)時(shí)寫NvM而是先寫到Dem的事件緩存等到合適的時(shí)機(jī)再進(jìn)行NvM寫操作。如果故障發(fā)生瞬間斷電則靠EcuM的下電時(shí)序處理。我遇到過(guò)一個(gè)售后問(wèn)題客戶反饋車輛長(zhǎng)時(shí)間停放后SOC記憶丟失每次重新上電都要重新估算。排查發(fā)現(xiàn)是NvM寫操作放在正常運(yùn)行周期里數(shù)據(jù)塊頻繁寫后來(lái)觸發(fā)寫入保護(hù)機(jī)制有些寫被丟棄了。改成在下電流程里集中寫一次并在每次正常運(yùn)行時(shí)保留最新數(shù)據(jù)到RAM緩存中問(wèn)題才解決。這也是為何AUTOSAR的EcuM和NvM協(xié)作機(jī)制如此重要。7. 常見(jiàn)誤區(qū)和實(shí)戰(zhàn)心得那些“從入門到放棄”的坑最后說(shuō)說(shuō)學(xué)習(xí)這個(gè)技術(shù)體系最常見(jiàn)的幾個(gè)坑。很多人都想一步到位搞懂AUTOSAR結(jié)果被規(guī)范和工具界面勸退這很自然。7.1 誤區(qū)一把BSW當(dāng)成普通驅(qū)動(dòng)庫(kù)來(lái)改有一些嵌入式底子不錯(cuò)的工程師看到BSW生成的代碼后第一反應(yīng)是“這代碼寫得太繞了我直接改一下驅(qū)動(dòng)文件不就行了”。這是很危險(xiǎn)的。BSW模塊之間有嚴(yán)格的接口依賴你手動(dòng)改了一處生成的代碼下一次可能被覆蓋或者導(dǎo)致其他模塊接口不一致。正確的做法是所有配置都通過(guò)ECUC工具完成代碼生成后不要手改生成文件。實(shí)在需要定制行為用模塊提供的回調(diào)接口或者復(fù)雜的配置選項(xiàng)去實(shí)現(xiàn)。7.2 誤區(qū)二算法跑得好不等于系統(tǒng)時(shí)序好很多算法在離線仿真里完美上車運(yùn)行后偶發(fā)表現(xiàn)不佳。原因經(jīng)常不是算法本身而是Runnable和任務(wù)之間的綁定關(guān)系錯(cuò)了。比如你把一個(gè)計(jì)算量龐大的SOH估算Runnable綁定在10ms任務(wù)上這就把系統(tǒng)拖垮了。經(jīng)驗(yàn)是任務(wù)周期只放它該放的東西算不準(zhǔn)和算不快是兩回事。7.3 學(xué)習(xí)方法建議從一個(gè)小切入口打通全鏈路如果讓我重新學(xué)一遍我會(huì)選擇這樣的路徑選一個(gè)BMS里的最小場(chǎng)景比如單體電壓采集并CAN上報(bào)先看RTE生成的代碼搞懂應(yīng)用函數(shù)是怎么被調(diào)用的再回到配置工具里看對(duì)應(yīng)的配置項(xiàng)搞清楚改一個(gè)周期、一個(gè)端口名生成的代碼會(huì)發(fā)生什么變化最后再逐步引入NvM、診斷、網(wǎng)絡(luò)管理等模塊。別忘了多利用Automotive行業(yè)里開(kāi)源的示例以及工具廠商自帶的例程。讀規(guī)范原文很重要但不是從第一個(gè)字開(kāi)始啃。我通常先看某個(gè)具體模塊的Overview再看示例工程確定它怎么用起來(lái)的然后遇到細(xì)節(jié)問(wèn)題再去規(guī)范里查精確描述這樣“從放棄到入門”的距離會(huì)縮短很多。坦白說(shuō)AUTOSAR這套體系不完美工具鏈龐雜、學(xué)習(xí)曲線陡峭但它確實(shí)是目前汽車電子軟件走向平臺(tái)化的主流答案。對(duì)BMS工程師而言主動(dòng)去理解ASW與BSW的分層邏輯不是給自己的工作找麻煩而是給未來(lái)幾年的職業(yè)發(fā)展換一條更寬的賽道。