1. 項目緣起與整體設(shè)計思路1.1 為什么要在Autosar架構(gòu)下用Simulink建模先說說這個項目的來龍去脈?，F(xiàn)在汽車電子控制單元ECU的軟件開發(fā)基本繞不開Autosar這套架構(gòu)標(biāo)準(zhǔn)。不管是經(jīng)典平臺還是自適應(yīng)平臺只要涉及到量產(chǎn)項目OEM和Tier1基本都會要求軟件架構(gòu)符合Autosar規(guī)范。而Simulink作為模型化開發(fā)MBD的主力工具在控制策略開發(fā)、算法驗證、代碼生成這幾個環(huán)節(jié)里幾乎是標(biāo)配。問題就出在這兩者的結(jié)合部。Autosar定義了一套非常嚴(yán)格的分層架構(gòu)——應(yīng)用層SWC、運行時環(huán)境RTE、基礎(chǔ)軟件層BSW每一層之間的接口、數(shù)據(jù)類型、通信機制都有明確規(guī)定。Simulink本身是一個通用的建模工具它默認(rèn)的建模方式跟Autosar的要求之間存在著天然的“縫隙”。這個項目要解決的就是把這些縫隙一個個找出來給出可落地的填縫方案。我接觸過不少團隊一開始都覺得“不就是把Simulink模型生成代碼然后集成到Autosar工程里嘛”結(jié)果真動手了才發(fā)現(xiàn)光是SWC的端口定義和RTE接口的匹配就能卡住好幾天。所以這個匯總的價值在于把踩過的坑提前標(biāo)出來讓后來者少走彎路。1.2 整體方案選型與工具鏈搭配在Autosar架構(gòu)下做Simulink建模工具鏈的選擇直接決定了后續(xù)的順暢程度。目前主流的路子有這么幾條MathWorks官方路線Simulink Embedded Coder AUTOSAR Blockset。這是最“正統(tǒng)”的方案AUTOSAR Blockset提供了SWC建模、端口定義、Runnable調(diào)度、IRVInter-Runnable Variable等全套支持生成的ARXML可以直接導(dǎo)入到Davinci、EB tresos這類BSW配置工具里。第三方工具輔助路線有些團隊會用一些中間轉(zhuǎn)換工具把Simulink模型先轉(zhuǎn)成特定格式再對接Autosar工具鏈。這種方式靈活但容易出兼容性問題不太推薦新手走。手寫膠水層路線Simulink只負(fù)責(zé)算法部分SWC的框架和RTE接口全部手寫。這種方式可控性最強但工作量大而且容易在數(shù)據(jù)類型和接口一致性上出錯。我個人的建議是如果是新項目直接上AUTOSAR Blockset雖然學(xué)習(xí)曲線陡一點但長期來看維護成本最低。如果是老項目改造手寫膠水層可能更穩(wěn)妥因為不用動已有的BSW配置。工具鏈版本搭配這塊有個坑要特別注意MATLAB的版本和Autosar工具鏈的版本必須匹配。比如MATLAB R2020b對應(yīng)的AUTOSAR Schema版本是4.4如果你用的BSW配置工具只支持到4.2那ARXML導(dǎo)入就會報錯。這個版本對應(yīng)關(guān)系在MathWorks官網(wǎng)有張表動手之前一定要先查。1.3 項目覆蓋的核心問題域這個匯總覆蓋的問題域我把它分成四大塊第一塊是SWC建模層面的問題包括端口定義、數(shù)據(jù)類型映射、Runnable調(diào)度、IRV使用這些。這是最基礎(chǔ)也最容易出問題的地方。第二塊是代碼生成與集成的問題涉及生成的代碼結(jié)構(gòu)、RTE接口匹配、BSW配置對接、鏈接腳本調(diào)整等。第三塊是仿真與驗證的問題包括SIL/PIL測試、RTE仿真、總線仿真這些環(huán)節(jié)。第四塊是工程管理的問題比如模型版本管理、ARXML合并沖突、多團隊協(xié)作等。每一塊我都會在后面的章節(jié)里展開講先給個全局視圖讓大家心里有數(shù)。2. SWC建模層面的核心細節(jié)與實操要點2.1 端口定義與數(shù)據(jù)類型映射的坑SWC的端口定義是Simulink模型和Autosar架構(gòu)對接的第一道關(guān)卡。AUTOSAR Blockset里提供了專門的Port模塊包括Sender Receiver Port、Client Server Port、Mode Switch Port等。用起來看著簡單但細節(jié)特別多。第一個坑是數(shù)據(jù)類型映射。Simulink默認(rèn)的數(shù)據(jù)類型是double但Autosar里常用的數(shù)據(jù)類型是uint8、uint16、sint16、boolean這些。如果你在Simulink里用double建模生成代碼的時候要么報錯要么自動轉(zhuǎn)成float而很多ECU的MCU根本不支持硬件浮點性能直接崩掉。正確的做法是在Simulink里就用Autosar支持的數(shù)據(jù)類型建模通過Simulink.NumericType或者fixdt來定義。具體操作上我習(xí)慣在模型初始化腳本里先把所有需要的數(shù)據(jù)類型定義好比如% 定義Autosar常用數(shù)據(jù)類型 uint8_t Simulink.NumericType; uint8_t.DataTypeMode Fixed-point: binary point scaling; uint8_t.Signedness Unsigned; uint8_t.WordLength 8; uint8_t.FractionLength 0; sint16_t Simulink.NumericType; sint16_t.DataTypeMode Fixed-point: binary point scaling; sint16_t.Signedness Signed; sint16_t.WordLength 16; sint16_t.FractionLength 0;然后在模型里通過Data Type Assistant把這些類型應(yīng)用到信號線上。這樣做的好處是生成代碼的時候Embedded Coder會直接生成對應(yīng)的C類型定義不會出現(xiàn)隱式轉(zhuǎn)換。第二個坑是端口方向的命名規(guī)范。Autosar里Sender Receiver Port的方向是從SWC的角度看的Sender Port是SWC往外發(fā)數(shù)據(jù)Receiver Port是SWC接收數(shù)據(jù)。但在Simulink里Inport和Outport的方向是從模型本身看的。這兩個方向容易搞混。我的經(jīng)驗是在Simulink里建模的時候就把Port的名字按照Autosar的命名規(guī)范來寫比如SR_Sender_XXX、SR_Receiver_YYY這樣生成ARXML的時候不容易出錯。第三個坑是端口的數(shù)據(jù)元素Data Element定義。一個Sender Receiver Port下面可以掛多個Data Element每個Data Element有自己的數(shù)據(jù)類型和初始值。在Simulink里這些是通過Port模塊的對話框來配置的。這里要注意的是Data Element的名字必須符合Autosar的命名規(guī)范字母開頭只包含字母數(shù)字下劃線而且同一個Port下的Data Element名字不能重復(fù)。注意如果你在Simulink里改了Port的名字或者Data Element的名字生成ARXML之后一定要重新導(dǎo)入到BSW配置工具里驗證一遍。我遇到過好幾次因為名字改了但BSW那邊沒同步導(dǎo)致RTE生成失敗的情況。2.2 Runnable調(diào)度與觸發(fā)機制的設(shè)計Runnable是Autosar里SWC的基本執(zhí)行單元相當(dāng)于一個可以被RTE調(diào)度的函數(shù)。在Simulink里Runnable是通過Function-Call Subsystem或者AUTOSAR Blockset提供的Runnable模塊來實現(xiàn)的。Runnable的觸發(fā)方式有好幾種周期觸發(fā)Timing Event、數(shù)據(jù)接收觸發(fā)Data Received Event、操作調(diào)用觸發(fā)Operation Invoked Event、模式切換觸發(fā)Mode Switch Event等。選擇哪種觸發(fā)方式取決于這個Runnable要完成的功能。比如一個做信號處理的Runnable通常是周期觸發(fā)的周期可以是1ms、5ms、10ms、100ms等。而一個做診斷響應(yīng)處理的Runnable可能是Operation Invoked Event觸發(fā)的因為它是被診斷儀請求的時候才執(zhí)行。在Simulink里配置Runnable的觸發(fā)方式是通過AUTOSAR Blockset的Runnable模塊來做的。這里有個細節(jié)Runnable的周期必須和BSW里配置的Task周期匹配。比如你在Simulink里把Runnable周期設(shè)成5ms但BSW里對應(yīng)的Task是10ms那RTE生成的時候就會報錯。這個匹配關(guān)系在項目初期就要規(guī)劃好不然后面改起來很麻煩。Runnable的調(diào)度順序也是個容易出問題的地方。同一個Task下面掛多個Runnable的時候它們的執(zhí)行順序會影響數(shù)據(jù)的一致性。比如Runnable A寫了一個IRVRunnable B讀這個IRV那A必須在B之前執(zhí)行。在Simulink里這個順序是通過Runnable模塊的優(yōu)先級參數(shù)來控制的。但要注意這個優(yōu)先級只在同一個Task內(nèi)部有效跨Task的調(diào)度順序是由BSW的調(diào)度器決定的。我一般會在模型里用一個表格來管理所有Runnable的信息包括名字、觸發(fā)方式、周期、優(yōu)先級、所屬Task等。這樣在跟BSW團隊對接的時候直接把這個表格發(fā)過去雙方對著表格來配置效率高很多。2.3 IRV與全局變量的使用邊界IRVInter-Runnable Variable是Autosar里用來在同一個SWC的不同Runnable之間傳遞數(shù)據(jù)的機制。它跟Sender Receiver Port的區(qū)別在于IRV是SWC內(nèi)部的不經(jīng)過RTE所以效率更高而Sender Receiver Port是SWC之間的必須經(jīng)過RTE。在Simulink里IRV是通過AUTOSAR Blockset的IRV模塊來實現(xiàn)的。用起來跟普通的Data Store Memory有點像但有幾個關(guān)鍵區(qū)別IRV必須在SWC的ARXML里顯式定義包括數(shù)據(jù)類型、初始值、是否可被多個Runnable訪問等。IRV的讀寫順序會影響數(shù)據(jù)的一致性。如果Runnable A寫IRVRunnable B讀IRV那A和B的調(diào)度順序就決定了B讀到的是新值還是舊值。IRV不能跨SWC使用。如果你需要跨SWC傳數(shù)據(jù)必須用Sender Receiver Port。什么時候用IRV什么時候用全局變量我的經(jīng)驗是如果數(shù)據(jù)只在同一個SWC內(nèi)部使用優(yōu)先用IRV因為它是Autosar標(biāo)準(zhǔn)的一部分可移植性好。如果數(shù)據(jù)需要跨SWC共享那只能用Sender Receiver Port。全局變量在Autosar架構(gòu)下是不推薦的因為它繞過了RTE破壞了SWC的封裝性。但實際項目中有些團隊為了圖方便會在Simulink里用Data Store Memory來實現(xiàn)跨Runnable的數(shù)據(jù)共享然后生成代碼的時候再手動改成IRV。這種做法短期看省事長期看是技術(shù)債。我建議一開始就規(guī)范使用IRV模塊雖然配置麻煩一點但后面維護省心。2.4 模型分割與SWC粒度的權(quán)衡一個項目里到底應(yīng)該劃分多少個SWC每個SWC的粒度應(yīng)該多粗這個問題沒有標(biāo)準(zhǔn)答案但有一些經(jīng)驗法則。SWC劃分太細的問題每個SWC都需要獨立的ARXML描述、獨立的RTE接口、獨立的代碼文件。如果劃分太細會導(dǎo)致ARXML文件數(shù)量爆炸RTE生成時間變長代碼體積增大。而且SWC之間的通信都要經(jīng)過RTE效率比SWC內(nèi)部通信低。SWC劃分太粗的問題一個SWC里面塞了太多功能導(dǎo)致模型臃腫編譯時間長而且不同功能之間的耦合度高復(fù)用性差。我的經(jīng)驗法則是按照功能域來劃分SWC每個SWC負(fù)責(zé)一個相對獨立的功能。比如一個電機控制SWC、一個電池管理SWC、一個通信管理SWC。每個SWC內(nèi)部的Runnable按照執(zhí)行周期來劃分比如1ms的Runnable做電流環(huán)控制10ms的Runnable做速度環(huán)控制100ms的Runnable做狀態(tài)監(jiān)控。在Simulink里SWC的邊界是通過AUTOSAR Blockset的SWC模塊來定義的。一個SWC模塊里面可以包含多個Runnable每個Runnable是一個Function-Call Subsystem。SWC之間的連接通過Sender Receiver Port或者Client Server Port來實現(xiàn)。這里有個實操技巧在模型開發(fā)初期先用普通的Subsystem把算法搭出來驗證功能沒問題之后再逐步替換成AUTOSAR Blockset的SWC和Runnable模塊。這樣做的好處是前期可以快速迭代算法不用被Autosar的配置細節(jié)束縛后期再花時間做架構(gòu)適配。如果一上來就用Autosar模塊光是配置就能耗掉大量時間算法驗證反而被耽誤了。3. 代碼生成與集成環(huán)節(jié)的實操過程3.1 Embedded Coder配置的關(guān)鍵參數(shù)代碼生成是Simulink模型到Autosar工程的橋梁。Embedded Coder的配置參數(shù)直接決定了生成的代碼能不能跟BSW對接上。這里我把最關(guān)鍵的幾個參數(shù)列出來并解釋為什么這么設(shè)。系統(tǒng)目標(biāo)文件System target file必須選autosar.tlc。這個目標(biāo)文件是AUTOSAR Blockset提供的它會生成符合Autosar規(guī)范的代碼結(jié)構(gòu)和ARXML描述文件。如果選錯了目標(biāo)文件生成的代碼里不會有RTE接口BSW那邊根本沒法集成。代碼生成語言選C。雖然C在Autosar自適應(yīng)平臺里可以用但經(jīng)典平臺基本還是C的天下。而且C的代碼生成會引入額外的運行時開銷對資源緊張的ECU來說不劃算。代碼生成風(fēng)格這里有個Generate code only和Generate code and compile的選項。我建議選Generate code only因為編譯環(huán)節(jié)交給BSW那邊的構(gòu)建系統(tǒng)來做Simulink這邊只負(fù)責(zé)生成代碼和ARXML。這樣職責(zé)清晰出了問題也好定位。代碼優(yōu)化選項Optimization里面的參數(shù)要根據(jù)項目需求來調(diào)。比如Default parameter behavior選Inlined可以減少全局變量的使用但會增加代碼體積選Tunable則相反。我一般會在項目初期選Tunable方便調(diào)試后期再改成Inlined優(yōu)化性能。代碼風(fēng)格選項Code Style里面的Parentheses level、Preserve operand order這些參數(shù)會影響生成代碼的可讀性。如果項目有代碼規(guī)范要求比如MISRA C這些參數(shù)要仔細調(diào)。我遇到過因為括號層級設(shè)置不對導(dǎo)致生成的代碼過不了靜態(tài)檢查的情況。ARXML導(dǎo)出選項在AUTOSAR選項卡里要勾選Export ARXML并指定導(dǎo)出的Schema版本。這個版本必須跟BSW配置工具支持的版本一致。另外Export XML options里面的Export comments建議勾上這樣ARXML里會保留Simulink模型的注釋方便后續(xù)維護。3.2 ARXML導(dǎo)入BSW配置工具的流程ARXML生成之后下一步是導(dǎo)入到BSW配置工具里比如Davinci Configurator、EB tresos等。這個環(huán)節(jié)的坑主要集中在版本兼容性和命名沖突上。版本兼容性前面提過ARXML的Schema版本必須跟BSW工具支持的版本匹配。如果不匹配導(dǎo)入的時候會報Schema validation error。解決辦法有兩個一是調(diào)整Simulink的ARXML導(dǎo)出設(shè)置選一個兼容的版本二是用XSLT轉(zhuǎn)換工具把ARXML轉(zhuǎn)成目標(biāo)版本。前者簡單但可能丟失一些信息后者復(fù)雜但保留完整信息。命名沖突ARXML里的元素名字SWC名字、Port名字、Runnable名字、Data Element名字必須在整個工程里唯一。如果兩個SWC用了同一個Port名字導(dǎo)入的時候就會沖突。我的做法是在項目初期就制定一套命名規(guī)范比如SWC名_Port名_DataElement名確保全局唯一。導(dǎo)入流程以Davinci Configurator為例大致步驟是打開工程進入AUTOSAR視圖。選擇Import ARXML選中Simulink生成的ARXML文件。工具會解析ARXML列出里面包含的SWC、Port、Runnable等元素。選擇需要導(dǎo)入的元素點擊Finish。導(dǎo)入完成后在SWC視圖里檢查導(dǎo)入的SWC是否完整Port連接是否正確。如果一切正常執(zhí)行Generate RTE生成RTE代碼。注意導(dǎo)入ARXML之前一定要備份BSW工程的配置文件。我遇到過好幾次因為ARXML導(dǎo)入失敗導(dǎo)致工程配置損壞的情況沒有備份就只能從頭再來。3.3 RTE接口匹配與膠水代碼處理RTERuntime Environment是Autosar架構(gòu)里連接SWC和BSW的中間層。Simulink生成的代碼里SWC的Runnable會通過RTE接口來讀寫數(shù)據(jù)、調(diào)用服務(wù)。這些接口的匹配是集成環(huán)節(jié)最容易出問題的地方。RTE接口的生成RTE代碼是由BSW配置工具根據(jù)ARXML描述自動生成的。生成的RTE接口包括Rte_Write_Port_DataElement、Rte_Read_Port_DataElement、Rte_Call_Port_Operation等函數(shù)。Simulink生成的代碼里Runnable會調(diào)用這些函數(shù)來跟外界交互。接口匹配的問題如果Simulink模型里的Port定義跟BSW里的配置不一致RTE生成的時候就會報錯。常見的錯誤包括Port方向不匹配Simulink里定義的是Sender Port但BSW里配的是Receiver Port。數(shù)據(jù)類型不匹配Simulink里用的是uint8但BSW里配的是uint16。Data Element名字不匹配Simulink里叫Speed但BSW里叫VehicleSpeed。解決這些問題的辦法是在導(dǎo)入ARXML之前先用一個腳本把Simulink模型里的Port信息導(dǎo)出來跟BSW團隊的配置表做比對。比對通過之后再導(dǎo)入可以避免大部分接口匹配問題。膠水代碼的處理有些情況下Simulink生成的代碼不能直接跟RTE對接需要加一層膠水代碼。比如Simulink里的函數(shù)接口跟RTE的函數(shù)接口簽名不一致或者需要做一些數(shù)據(jù)轉(zhuǎn)換。膠水代碼一般放在單獨的C文件里通過#include的方式跟Simulink生成的代碼和RTE代碼鏈接。我一般會把膠水代碼放在一個叫swc_glue.c的文件里里面實現(xiàn)一些適配函數(shù)。比如/* swc_glue.c */ #include Rte_MySWC.h #include MySWC.h /* 適配函數(shù)把RTE的數(shù)據(jù)轉(zhuǎn)成Simulink代碼需要的格式 */ void MySWC_Adapter_Step(void) { uint8_t rte_value; Rte_Read_SR_Receiver_InputData_Value(rte_value); MySWC_InputData rte_value; MySWC_Step(); Rte_Write_SR_Sender_OutputData_Value(MySWC_OutputData); }這樣做的好處是Simulink生成的代碼不用改膠水層負(fù)責(zé)所有適配工作。缺點是增加了一層調(diào)用開銷但對大多數(shù)應(yīng)用來說可以忽略。3.4 鏈接腳本與內(nèi)存布局的調(diào)整代碼生成和RTE集成完成之后最后一步是鏈接。鏈接腳本決定了代碼和數(shù)據(jù)在MCU內(nèi)存里的布局。Autosar架構(gòu)下不同的數(shù)據(jù)段有不同的用途.text段存放代碼。.data段存放已初始化的全局變量。.bss段存放未初始化的全局變量。.calib段存放標(biāo)定數(shù)據(jù)可以通過標(biāo)定工具在線修改。.nvram段存放需要掉電保存的數(shù)據(jù)。Simulink生成的代碼里不同的變量會被分配到不同的段。比如標(biāo)定量會被分配到.calib段普通全局變量會被分配到.data或.bss段。這些分配規(guī)則是通過Embedded Coder的Code Generation Memory Sections配置來控制的。鏈接腳本的調(diào)整主要是確保這些段在MCU的內(nèi)存空間里有合適的地址范圍。比如.calib段通常放在Flash里但標(biāo)定的時候需要能在線修改所以要通過特定的內(nèi)存映射機制來實現(xiàn)。這個環(huán)節(jié)需要跟底層軟件團隊緊密配合因為鏈接腳本通常是他們維護的。我遇到過的一個典型問題是Simulink生成的代碼里有一個大的查表數(shù)據(jù)比如一個1024點的MAP默認(rèn)被分配到了.data段導(dǎo)致RAM不夠用。解決辦法是在Simulink里把這個查表數(shù)據(jù)標(biāo)記為Const這樣它就會被分配到Flash里不占RAM。這個標(biāo)記是在Data Store Memory或者Lookup Table模塊的參數(shù)里設(shè)置的。4. 仿真驗證與常見問題排查實錄4.1 SIL/PIL測試環(huán)境的搭建SILSoftware-in-the-Loop和PILProcessor-in-the-Loop是Autosar開發(fā)里必不可少的驗證環(huán)節(jié)。SIL是在PC上運行生成的代碼驗證功能邏輯PIL是在目標(biāo)MCU上運行代碼驗證時序和資源占用。SIL環(huán)境搭建Simulink支持通過Model Configuration Parameters Code Generation Verification SIL來配置SIL仿真。關(guān)鍵是要把生成的代碼編譯成PC上可執(zhí)行的動態(tài)庫Windows下是DLLLinux下是SO然后Simulink通過S-Function來調(diào)用這個庫。這里有個坑Autosar生成的代碼里會調(diào)用RTE接口但SIL環(huán)境下沒有RTE。解決辦法是提供一個RTE的樁函數(shù)Stub模擬RTE的行為。比如/* RTE_Stub.c */ #include Rte_MySWC.h static uint8_t g_input_value 0; static uint8_t g_output_value 0; void Rte_Read_SR_Receiver_InputData_Value(uint8_t* value) { *value g_input_value; } void Rte_Write_SR_Sender_OutputData_Value(uint8_t value) { g_output_value value; } /* 供Simulink S-Function調(diào)用的接口 */ void SIL_SetInput(uint8_t value) { g_input_value value; } uint8_t SIL_GetOutput(void) { return g_output_value; }這樣Simulink就可以通過S-Function來設(shè)置輸入、讀取輸出完成閉環(huán)仿真。PIL環(huán)境搭建PIL需要把生成的代碼下載到目標(biāo)MCU上運行然后通過通信接口比如CAN、串口、以太網(wǎng)跟Simulink交換數(shù)據(jù)。這個環(huán)節(jié)的難點在于通信協(xié)議的設(shè)計和時序的匹配。我一般會用CAN總線來做PIL通信因為大多數(shù)ECU都有CAN接口而且CAN的實時性足夠。PIL測試的一個典型問題是Simulink的仿真步長跟MCU的實際執(zhí)行周期不匹配。比如Simulink步長是1ms但MCU上的Task周期是5ms那PIL測試的時候就會出現(xiàn)數(shù)據(jù)不同步。解決辦法是在Simulink里把步長設(shè)成跟Task周期一致或者在PIL通信協(xié)議里加時間戳來對齊。4.2 常見編譯錯誤與解決方法編譯環(huán)節(jié)是問題最集中的地方。我把常見的編譯錯誤整理成一個速查表錯誤類型典型報錯信息原因分析解決方法數(shù)據(jù)類型不匹配error: incompatible types when assigning to type uint8 from type doubleSimulink里用了double但Autosar要求uint8在Simulink里改用Autosar支持的數(shù)據(jù)類型未定義引用undefined reference to Rte_Write_XXXRTE代碼沒有鏈接進來檢查鏈接腳本確保RTE庫被鏈接重復(fù)定義multiple definition of MySWC_Step同一個函數(shù)在多個文件里定義檢查是否有重復(fù)的代碼文件被編譯內(nèi)存溢出region RAM overflowed by 1024 bytesRAM不夠用優(yōu)化數(shù)據(jù)結(jié)構(gòu)把常量放到Flash里棧溢出stack overflow detected局部變量太大或遞歸調(diào)用太深減少局部變量避免遞歸對齊錯誤misaligned access at address 0x20000001數(shù)據(jù)結(jié)構(gòu)對齊不符合MCU要求調(diào)整數(shù)據(jù)結(jié)構(gòu)的對齊屬性這些錯誤里數(shù)據(jù)類型不匹配是最常見的。我粗略統(tǒng)計過大概有60%的編譯錯誤都跟數(shù)據(jù)類型有關(guān)。根本原因還是Simulink默認(rèn)用double而Autosar生態(tài)里double基本不可用。所以我在項目初期就會強制要求所有信號線都顯式指定數(shù)據(jù)類型不允許出現(xiàn)double。未定義引用是第二常見的。這個通常是因為RTE代碼沒有正確鏈接。檢查步驟是先確認(rèn)RTE代碼已經(jīng)生成在BSW工程的generated目錄下然后確認(rèn)鏈接腳本里包含了RTE的目標(biāo)文件最后確認(rèn)RTE的頭文件路徑在編譯器的include路徑里。4.3 RTE通信失敗的排查思路RTE通信失敗的表現(xiàn)形式很多數(shù)據(jù)讀不到、寫不進去、讀到的值是錯的、寫完之后BSW那邊沒反應(yīng)等。排查的時候我一般按照“從下往上”的順序來第一步檢查RTE是否生成成功。在BSW配置工具里執(zhí)行Generate RTE看有沒有報錯。如果有報錯根據(jù)報錯信息定位是哪個SWC、哪個Port、哪個Data Element的問題。第二步檢查RTE接口是否被正確調(diào)用。在Simulink生成的代碼里搜索Rte_Write和Rte_Read確認(rèn)這些函數(shù)被調(diào)用了而且參數(shù)類型跟RTE頭文件里的聲明一致。第三步檢查RTE的配置。在BSW配置工具里查看RTE的配置確認(rèn)Port的連接關(guān)系、Data Element的映射關(guān)系、Task的調(diào)度關(guān)系都正確。第四步檢查運行時行為。如果編譯鏈接都沒問題但運行時數(shù)據(jù)不對那就用調(diào)試器在RTE函數(shù)里打斷點看數(shù)據(jù)流是否正常。我常用的方法是在Rte_Write和Rte_Read里加日志記錄每次調(diào)用的時間和數(shù)據(jù)值然后分析日志。一個典型的RTE通信問題是數(shù)據(jù)一致性問題。比如Runnable A在1ms Task里寫數(shù)據(jù)Runnable B在10ms Task里讀數(shù)據(jù)如果A寫了多次但B只讀一次那B讀到的可能是中間值。解決辦法是用IRV或者加數(shù)據(jù)保護機制比如雙緩沖、原子操作。4.4 模型版本管理與ARXML合并沖突多人協(xié)作開發(fā)的時候模型版本管理和ARXML合并沖突是兩個繞不開的問題。模型版本管理Simulink模型是二進制文件.slxGit這類版本控制工具對二進制文件的合并支持很差。如果兩個人同時改了一個模型合并的時候基本只能二選一。我的做法是把模型拆小每個人負(fù)責(zé)的SWC放在獨立的模型文件里減少沖突概率。用Simulink Project來管理模型依賴關(guān)系確保每個人用的庫文件版本一致。提交之前先更新確保本地版本是最新的。如果沖突不可避免用Simulink的Compare工具來對比兩個版本的差異手動合并。ARXML合并沖突ARXML是文本文件Git可以合并但Autosar的ARXML結(jié)構(gòu)復(fù)雜自動合并經(jīng)常出錯。我的做法是ARXML文件由專人負(fù)責(zé)生成和提交其他人不直接改ARXML。如果必須改改完之后用BSW配置工具重新導(dǎo)入驗證一遍。在Git里配置ARXML的合并策略優(yōu)先用BSW配置工具的合并功能而不是Git的自動合并。注意ARXML合并沖突如果處理不當(dāng)可能導(dǎo)致BSW配置損壞進而導(dǎo)致整個工程編譯失敗。所以每次合并之后一定要做一次完整的編譯和RTE生成驗證。5. 工程管理層面的經(jīng)驗與建議5.1 多團隊協(xié)作的接口約定Autosar項目通常涉及多個團隊?wèi)?yīng)用層團隊負(fù)責(zé)Simulink建模、BSW團隊負(fù)責(zé)基礎(chǔ)軟件配置、集成團隊負(fù)責(zé)整體集成。這三個團隊之間的接口約定直接決定了項目效率。應(yīng)用層和BSW之間的接口主要是SWC的ARXML描述。應(yīng)用層團隊負(fù)責(zé)生成ARXMLBSW團隊負(fù)責(zé)導(dǎo)入和配置RTE。雙方需要約定好ARXML的Schema版本、命名規(guī)范、數(shù)據(jù)類型映射規(guī)則、Runnable調(diào)度周期等。BSW和集成之間的接口主要是RTE代碼和BSW配置。BSW團隊負(fù)責(zé)生成RTE代碼和BSW配置集成團隊負(fù)責(zé)把這些跟應(yīng)用層代碼鏈接起來。雙方需要約定好鏈接腳本、內(nèi)存布局、編譯選項等。應(yīng)用層和集成之間的接口主要是生成的代碼和膠水層。應(yīng)用層團隊負(fù)責(zé)生成代碼集成團隊負(fù)責(zé)寫膠水層和做集成測試。雙方需要約定好代碼接口、數(shù)據(jù)格式、測試用例等。我建議在項目初期就制定一份《接口約定文檔》把上面這些內(nèi)容寫清楚所有團隊簽字確認(rèn)。后面如果有變更走變更流程避免口頭約定導(dǎo)致的信息不一致。5.2 模型規(guī)范與檢查清單Simulink模型的規(guī)范程度直接影響代碼生成的質(zhì)量和后續(xù)維護的效率。我一般會制定一份模型檢查清單在模型提交之前逐項檢查所有信號線都顯式指定了數(shù)據(jù)類型沒有double。所有Port都按照Autosar命名規(guī)范命名。所有Runnable都配置了正確的觸發(fā)方式和周期。所有IRV都定義了數(shù)據(jù)類型和初始值。模型里沒有未連接的輸入輸出端口。模型里沒有死循環(huán)或者代數(shù)環(huán)。模型的注釋完整每個Subsystem都有功能說明。模型的版本號和變更記錄完整。這份檢查清單可以用Simulink Model Advisor來自動化檢查。Model Advisor里有很多內(nèi)置的檢查項也可以自定義檢查項。我一般會把檢查清單里的項目做成Model Advisor的配置每次提交之前跑一遍不通過就不允許提交。5.3 持續(xù)集成與自動化測試Autosar項目的持續(xù)集成CI比普通軟件項目復(fù)雜因為涉及到Simulink模型、生成的代碼、ARXML、BSW配置等多個環(huán)節(jié)。我搭建的CI流程大致是這樣的模型檢查每次提交觸發(fā)Model Advisor檢查確保模型符合規(guī)范。代碼生成模型檢查通過后自動生成代碼和ARXML。ARXML驗證把生成的ARXML導(dǎo)入到BSW配置工具里驗證是否能成功導(dǎo)入和生成RTE。編譯鏈接把生成的代碼、RTE代碼、BSW代碼一起編譯鏈接生成可執(zhí)行文件。SIL測試在PC上運行SIL測試驗證功能邏輯。PIL測試把可執(zhí)行文件下載到目標(biāo)MCU上運行PIL測試驗證時序和資源占用。報告生成把每一步的結(jié)果生成報告郵件通知相關(guān)團隊。這個流程里ARXML驗證是最容易出問題的一步。因為ARXML的導(dǎo)入依賴于BSW配置工具而BSW配置工具通常是Windows下的GUI程序不容易在CI服務(wù)器上自動化。我的解決辦法是用BSW配置工具的命令行接口大多數(shù)工具都提供或者用腳本模擬導(dǎo)入過程檢查ARXML的結(jié)構(gòu)和內(nèi)容是否符合預(yù)期。5.4 從項目復(fù)盤看高頻問題分布最后分享一下我從多個項目復(fù)盤里總結(jié)的高頻問題分布。如果把所有問題按出現(xiàn)頻率排序大致是這樣的排名問題類別占比典型表現(xiàn)1數(shù)據(jù)類型不匹配30%編譯錯誤、運行時數(shù)據(jù)異常2RTE接口配置錯誤25%RTE生成失敗、通信失敗3Runnable調(diào)度問題15%數(shù)據(jù)不一致、時序錯誤4ARXML版本兼容性10%導(dǎo)入失敗、Schema驗證錯誤5內(nèi)存布局問題8%鏈接錯誤、RAM溢出6模型規(guī)范問題7%代碼可讀性差、維護困難7其他5%工具鏈問題、環(huán)境問題從這個分布可以看出數(shù)據(jù)類型和RTE接口是兩大主要問題源加起來占了55%。所以我在項目初期會把最多的精力放在這兩個方面的規(guī)范制定和自動化檢查上。數(shù)據(jù)類型方面強制要求所有信號線顯式指定類型RTE接口方面用腳本自動比對Simulink模型和BSW配置的一致性。另外Runnable調(diào)度問題雖然占比不是最高但排查難度最大。因為它往往不是編譯期錯誤而是運行時的偶發(fā)問題復(fù)現(xiàn)困難定位耗時。我的經(jīng)驗是在模型設(shè)計階段就把Runnable的調(diào)度關(guān)系畫成圖標(biāo)注每個Runnable的周期、優(yōu)先級、讀寫的數(shù)據(jù)然后人工評審一遍。這樣可以在早期發(fā)現(xiàn)潛在的調(diào)度沖突避免后期調(diào)試的痛苦。我在實際項目里踩過最深的一個坑是一個10ms的Runnable和一個1ms的Runnable共享了一個IRV但10ms的Runnable在寫IRV的時候沒有做保護導(dǎo)致1ms的Runnable讀到了中間值。這個問題在實驗室里復(fù)現(xiàn)不出來只有在特定工況下才會出現(xiàn)。后來我們用了雙緩沖機制才解決。從那以后我在所有跨周期共享數(shù)據(jù)的地方都強制要求加保護機制不管是IRV還是全局變量。這個內(nèi)容后續(xù)還可以這樣擴展把每個問題的排查過程錄成視頻配上實際的調(diào)試器操作和代碼演示做成一個系列教程。另外可以整理一份常見錯誤的代碼片段庫每個錯誤配一個正確寫法和一個錯誤寫法方便新手對照學(xué)習(xí)。