劉彥博,孫偉奇,史 瑞,陳思聰,郝 麗,申贊偉
(1.上海交通大學a.電子信息與電氣工程學院教學發(fā)展與學生創(chuàng)新中心,b.資產(chǎn)管理與實驗室處,上海 200240;2.心動互動娛樂有限公司城北大王寨工作室,上海 200070;3.斯柯信號有限公司平臺技術(shù)中心,上海 200071)
“十四五”期間,智能網(wǎng)聯(lián)汽車產(chǎn)業(yè)將越發(fā)備受關注。國務院、國家發(fā)展和改革委員會都將智能汽車放到核心戰(zhàn)略發(fā)展地位[1]。到2025 年,我國部分自動駕駛、有條件自動駕駛智能網(wǎng)聯(lián)汽車將有望占當年汽車市場銷量的50%以上[2]。行業(yè)預計智能汽車中的代碼行數(shù)將超過1 億行,這使得汽車系統(tǒng)變得越來越復雜。而傳統(tǒng)面向文檔的方法來開發(fā)系統(tǒng)和軟件已達到其效率極限[3]。
“智能網(wǎng)聯(lián)汽車技術(shù)路線圖2.0”的發(fā)布,加速了汽車產(chǎn)業(yè)布局。隨著無人駕駛汽車系統(tǒng)復雜程度的提高,開發(fā)過程的每個階段都會帶來復雜性[4]。對于大型系統(tǒng),任何隱藏在復雜階段中的小問題都有可能對整個系統(tǒng)造成損害。自動駕駛公司正在使用基于模型開發(fā)的設計理念來踐行軟件定義汽車。在教學中引入企業(yè)前沿設計理念,可激發(fā)學生的興趣和研究方向[5]。
在傳統(tǒng)的開發(fā)過程中,需求、設計、實現(xiàn)和測試任務在不同的工具環(huán)境中順序執(zhí)行,有許多手動步驟。需求通過文本方式捕獲,使用文檔管理工具。如圖1所示的傳統(tǒng)設計流程中,每個階段都可能會出現(xiàn)一些缺陷。前面階段中所積累的缺陷會引發(fā)在測試階段中開發(fā)時間和成本的資源消耗和損失[6]。
圖1 傳統(tǒng)設計流程
如圖2 所示,相同的一組需求分別為基于模型的設計和傳統(tǒng)流程設計流程。需求不作為文本規(guī)范的基礎,而是用于以模型的形式開發(fā)可執(zhí)行的規(guī)范。MBD使用這些模型來闡明需求和規(guī)范。然后對模型進行詳細闡述,來進行詳細設計。使用基于模型的設計工具,可以在系統(tǒng)級模擬設計實現(xiàn)之前發(fā)現(xiàn)接口缺陷。一旦設計完成,就會自動從模型中生成產(chǎn)品代碼和測試用例。測試可以在需求階段開始來模擬可執(zhí)行的規(guī)格,以驗證需求是否被滿足。進而使得缺陷被更早地捕獲并移除,降低了開發(fā)的總成本[7]。
圖2 基于模型設計流程
如圖3 所示為V-模型開發(fā)生命周期的各階段與其相關的測試階段之間的關系。水平軸和垂直軸分別表示時間或項目完整性(從左到右)和抽象級別。
圖3 V-模型開發(fā)流程
(1)系統(tǒng)設計階段。通過研究用戶需求文檔來分析和理解所提議系統(tǒng)的業(yè)務。系統(tǒng)設計實現(xiàn)用戶需求的可能性和技術(shù),并相應地編輯用戶需求文檔。這個過程生成用作開發(fā)階段藍圖的軟件規(guī)范文檔。這些文檔包含一般的系統(tǒng)組織,菜單結(jié)構(gòu),數(shù)據(jù)結(jié)構(gòu)等。為了更好地理解,它可能還包含示例業(yè)務場景,示例窗口,報告。在此階段還將制作其他技術(shù)文檔,例如實體圖,數(shù)據(jù)字典。在這一階段準備了用于系統(tǒng)測試的文檔。
(2)需求分析階段。首先生成需求文檔,描述系統(tǒng)的功能、界面、性能、數(shù)據(jù)和安全需求。它將作為系統(tǒng)設計人員在系統(tǒng)設計階段的指南,包括軟性和硬性方法的需求。
(3)架構(gòu)設計階段。即計算機體系結(jié)構(gòu)和軟件體系結(jié)構(gòu)設計的階段,也可以稱為高級設計。選擇體系結(jié)構(gòu)的基準是應實現(xiàn)包括模塊列表等每個模塊的簡要功能,如接口關系、依賴關系、數(shù)據(jù)庫表、體系結(jié)構(gòu)圖、技術(shù)細節(jié)等。在特定階段進行集成測試設計。
(4)單元設計階段。也稱為底層設計。設計的系統(tǒng)分為較小的單元或模塊,并對每個單元或模塊進行說明,以便直接編碼。設計文檔或程序規(guī)范將以偽代碼包含模塊的詳細功能邏輯:數(shù)據(jù)庫表以及所有元素,包括其類型和大?。凰薪涌谠敿毿畔⒁约巴暾膽贸绦蚪涌冢ˋpplication Programming Interface,API)參考;所有相關性問題和錯誤消息列表;完成模塊的輸入和輸出。在此階段進行單元測試設計。
(5)單元測試(Unit Testing,UT)階段。即一種測試源代碼的各個單元以確定它們是否適合使用的方法。在過程編程中,一個單元可以是單獨的功能或過程。UT由程序員或偶爾由白盒測試人員創(chuàng)建。通過測試功能中的每個可能分支,來驗證內(nèi)部邏輯代碼。
(6)集成測試(Integration Testing,IT)階段。將其單獨的模塊一起測試來暴露接口和集成組件之間在交互中的故障。在IT 過程中通常不直接檢查代碼是否存在錯誤,因此測試通常是一個黑匣子。
(7)需求驗證測試階段。即用于確定系統(tǒng)是否滿足需求分析階段中指定的需求的測試階段。驗收測試設計源自需求文檔。驗收測試階段是客戶用來確定是否接受系統(tǒng)的階段。
(8)系統(tǒng)集成和測試(System Integration Testing,ST)階段。它將系統(tǒng)規(guī)范與實際系統(tǒng)進行比較。IT 完成后,下一個測試級別是ST。ST 將檢查集成產(chǎn)品是否滿足指定要求。在較低的測試級別中,測試是根據(jù)技術(shù)規(guī)范進行的,即從軟件生產(chǎn)商的技術(shù)角度進行的測試。ST是從客戶和未來用戶的角度來看系統(tǒng)。測試人員驗證是否完全和適當?shù)貪M足了要求;所有系統(tǒng)組件的相互作用都會產(chǎn)生許多功能和系統(tǒng)特性。因此,它們僅在整個系統(tǒng)的級別上可見,并且只能在此處進行觀察和測試。
選擇的底盤設計為阿克曼底盤設計。阿克曼轉(zhuǎn)向幾何學是汽車或其他車輛轉(zhuǎn)向中連桿的幾何布置,它能解決轉(zhuǎn)彎內(nèi)外車輪需要找出不同半徑圓的問題[8]。
目前阿克曼底盤在低速自動駕駛底盤和中國大學生方程式賽車中應用較多[9-10]。
如圖4 所示,阿克曼底盤可分為前轉(zhuǎn)向和后轉(zhuǎn)向。本文阿克曼模型選用前轉(zhuǎn)向。
圖4 阿克曼底盤模型
圖中參數(shù):δin為轉(zhuǎn)向角,(°);δL為左車輪角,(°);δR為右車輪角,(°);δvir為虛擬輪角,(°);TW為跟蹤寬度,m;WB為軸距,m;TC為轉(zhuǎn)彎半徑,m;γ 為轉(zhuǎn)向比例。
阿克曼轉(zhuǎn)向系統(tǒng)的基本要求,在轉(zhuǎn)彎時,內(nèi)側(cè)轉(zhuǎn)向輪相對于車輛縱向中心線的轉(zhuǎn)向角必須大于外側(cè)轉(zhuǎn)向輪。轉(zhuǎn)向輪之間的轉(zhuǎn)向角之差稱為前束角。對于理想的阿克曼轉(zhuǎn)向,車輪角度有一個共同的轉(zhuǎn)彎圈。
為了簡化整體結(jié)構(gòu),對經(jīng)典汽車底盤件做了部分改動。普通的獨立車輪懸架是一種復雜的機械結(jié)構(gòu)。底盤分為兩部分,后部(承載兩個驅(qū)動單元)和前部(承載其余的設備)。這兩個部分由軸承內(nèi)的軸連接,使后橋能夠擺動。這種方法能夠避免因重載而使經(jīng)典的獨立懸架無法實現(xiàn)的情況?;趯嶋H的轉(zhuǎn)向角度和期望的前進速度,車載電腦(Electronic Control Unit,ECU)來計算車輪速度和設置為驅(qū)動單位。計算轉(zhuǎn)向角度的方程為[8]:
使用Matlab Simulink 進行車輛運動過程進行建模[11]。Matlab Simulink 軟件被廣泛適用于汽車仿真,用于建立模型車動力模型,將車輛動力模型進行匹配。在Mathworks Hardware Suppport頁面中可以獲取、配置Matlab和Simulink的集成硬件解決方案。
在車輛建模設計過程中,對于車輛運動力學方面要考量速度、縱向加速度、橫向加速度以及車輛本身的質(zhì)量,車輪轉(zhuǎn)動慣量等參數(shù)。線控底盤Simulink 建模結(jié)構(gòu),如圖5 所示。模型采用高電平控制器,該模型的異步系統(tǒng)基于中斷的子系統(tǒng),模型的同步基于控制器局域網(wǎng)絡(Controller area network,CAN同步通信[12]。
圖5 線控底盤控制模型
編碼器計數(shù)異步更新。當一個完整上升沿觸發(fā),中斷發(fā)布。CPU 和中斷信號的設置對應eCAP 模塊。如圖6 所示,eCAP引腳需要根據(jù)型號硬件實現(xiàn)配置上的布線進行設置。在主同步模型中每10 ms檢索和重置一次的計數(shù)。
圖6 eCAP模型
如圖7 所示,目前限于編碼器更新速率,車輛動力學控制器采樣時間為10 ms。
圖7 編碼器采樣模型
如圖8 所示,在線控底盤設計中,ePWM模塊產(chǎn)生PWM(Pulse width modulation)信號來調(diào)節(jié)電動機。定時器周期必須小于20 kHz,電動機使用ePWM模塊的A和B通道。當收到標準化的期望速度時,1 前進,-1反向。
圖8 電機速度控制模型
如圖9 所示,舵機轉(zhuǎn)向控制信號(steering端)經(jīng)過處理后,輸出至eCAP 模塊。本文使用CAN 打包/解包以及CAN傳輸和接收在CAN總線上共享數(shù)據(jù)。
圖9 舵機轉(zhuǎn)向控制模型
CAN Receive端接收到信號后解析出控制信號傳輸?shù)綀?zhí)行端口,如圖10 所示。
圖10 CAN接收模型
CAN Send端接發(fā)送信號,將控制信號打包后傳輸?shù)絺魉投丝?,如圖11 所示。
圖11 CAN發(fā)送模型
DBC(Data Base CAN)設計文件包含打包信息,如圖12 所示。使用CAN硬件支持包訪問CAN網(wǎng)絡,發(fā)送信息到CAN網(wǎng)絡,使用儀表板塊可視化車輛狀態(tài)。
圖12 Simulink CAN DBC打包信息
通過使用Embedded Coder 生成代碼,如圖13所示。
圖13 Simulink模型代碼生成
基于MBD設計代碼測試全覆蓋,滿足要求,如圖14 所示。
圖14 Simulink模型代碼測試
將以上實驗模型,配合目前設計參數(shù)來構(gòu)建總模型,滿足電動機控制器功率與電壓的基本需求。
如圖15 所示,線控底盤供電系統(tǒng)7.3 V電池為舵機、雙電動機驅(qū)動供電。7.3 V通過DC-DC 模組升壓到9 V為CAN卡供電。7.3 V通過5 V穩(wěn)壓器給ECU供電。ECU 輸出3.3 V 給霍爾傳感器獲取前端編碼器和后端編碼器信息。底盤調(diào)試,通過DB9 數(shù)據(jù)接口將程序加載到自動駕駛線控底盤。
圖15 線控底盤硬件供電圖
圖16 所示為Matlab Gui 搭建的調(diào)試界面,讀取CAN信號解析后,圖形頁面顯示不同傳感器上的信息??赏ㄟ^速度以及車輛動力學參數(shù),計算出在當前車速下車輛性能,在某一時刻下車輛的縱向加速度、速度、車輛質(zhì)量的信息。
圖16 線控底盤Simulink調(diào)試界面
圖17 所示為設計的線控底盤在全局參考軌跡的跟蹤途徑,從原點出發(fā),返回到終點,能夠滿足自動駕駛賽道的要求。
圖17 線控底盤軌跡路徑圖
本文搭建了基于模型線控底盤仿真模型與硬件。將仿真參數(shù)代入實車模型,驗證了模型的正確性。通過線控底盤的全流程設計,培養(yǎng)了基于車輛動力學方程從系統(tǒng)設計、需求分析,到自動生成代碼、代碼測試的工程實踐能力,提升自主設計的創(chuàng)新能力。該設計方法的掌握,可使設計過程少走彎路,不僅可以縮短開發(fā)周期,還能有效節(jié)約開發(fā)成本。