當(dāng)下ECU軟件開發(fā)的挑戰(zhàn)
隨著軟件技術(shù)的發(fā)展,車輛的開發(fā)過程從硬件主導(dǎo)轉(zhuǎn)變?yōu)檐浖x汽車(SDV),軟件開發(fā)在汽車的開發(fā)過程中扮演著舉足輕重的角色。車輛E/E架構(gòu)由原先的各ECU只負(fù)責(zé)單一功能的分布式架構(gòu),轉(zhuǎn)變?yōu)楦咝阅苡?jì)算單元(HPC)和區(qū)域控制單元(Zonal ECU)分工協(xié)作的架構(gòu)。因此,ECU的軟件功能越來越多,越來越復(fù)雜。ECU的軟件開發(fā),也將引入不同部門、不同公司的更多項(xiàng)目開發(fā)人員的協(xié)作。在ECU軟件開發(fā)變得更加復(fù)雜更加緊密協(xié)作的同時,軟件的版本迭代周期也變得越來越短。
傳統(tǒng)的工作流程和開發(fā)過程難以滿足這些要求,因此以DevOps為導(dǎo)向的持續(xù)集成方法正成為新的趨勢。然而,由于AUTOSAR Classic項(xiàng)目的單一工程結(jié)構(gòu),實(shí)現(xiàn)AUTOSAR Classic ECU軟件開發(fā)的持續(xù)集成并不是一項(xiàng)容易的任務(wù)。根據(jù)項(xiàng)目的部署和開發(fā)過程,可以觀察到以下三種方式及挑戰(zhàn)。
1.1 基于功能開發(fā)中的合并沖突問題
將項(xiàng)目中各成員的增量(設(shè)計(jì)、配置和實(shí)現(xiàn))合并是一個重大挑戰(zhàn),特別是基于各功能團(tuán)隊(duì)獨(dú)立開發(fā)的模式。對于AUTOSAR Classic項(xiàng)目(圖1-1),基于功能的開發(fā)方式意味著項(xiàng)目成員開發(fā)應(yīng)用軟件(SWC),并自行將其集成到基礎(chǔ)軟件(BSW)中。這種方法可以應(yīng)用于獨(dú)立完整的SWC,也可以應(yīng)用于與其他項(xiàng)目成員協(xié)作開發(fā)的SWC。
圖1-1基于功能的開發(fā)方式
1.2 基于組件開發(fā)的集成滯后問題
另一種方法是將工作角色劃分為項(xiàng)目內(nèi)更專業(yè)的角色,這里定義為基于組件的開發(fā)方式(圖1-2)。在這種項(xiàng)目開發(fā)方式中,有專注于SWC的應(yīng)用開發(fā)人員,以及一個軟件集成團(tuán)隊(duì)負(fù)責(zé)配置BSW,并將SWC和BSW進(jìn)行集成。
圖1-2基于模塊的開發(fā)方式
在這種情況下,應(yīng)用開發(fā)人員既無法訪問BSW的配置,也無法使用工具將SWC與BSW集成。相比于基于功能的開發(fā)方式(每個項(xiàng)目成員可以獨(dú)立處理自己的功能),在基于組件的開發(fā)方式中,應(yīng)用開發(fā)人員依賴于軟件集成團(tuán)隊(duì)。
圖1-3基于模塊的開發(fā)方式的集成流程
這種方法的好處是減少了合并問題,缺點(diǎn)是集成的總時長增加了。軟件集成團(tuán)隊(duì)只能在應(yīng)用開發(fā)人員完成他們的工作后才開始集成,而且集成必須根據(jù)軟件集成團(tuán)隊(duì)的可用時間進(jìn)行安排。據(jù)應(yīng)用開發(fā)人員的反饋,許多人等待他們的SWC與BSW集成的時間在1到4周之間,導(dǎo)致驗(yàn)證延遲,發(fā)現(xiàn)問題延遲,最終可能會危及項(xiàng)目的里程碑。圖1-3描述了這種集成流程。
1.3 手動集成中的重復(fù)工作問題
在傳統(tǒng)的基于DaVinci Configurator Classic GUI的工作模式中,將SWC與BSW集成需要許多手動步驟(圖1-4)。
圖1-4手動集成步驟
首先,需要打開DaVinci Configurator Classic并將SWC加載到項(xiàng)目中。接下來,針對每個 SWC需要執(zhí)行以下重復(fù)的步驟:
手動配置RTE,例如將Runnable映射到Task,將NvSWC連接到對應(yīng)部分,創(chuàng)建或調(diào)整內(nèi)存塊,以及添加數(shù)據(jù)映射;
配置完成后,需要驗(yàn)證配置,并解決可能存在的問題。
在SWC和Runnable數(shù)量龐大的大型項(xiàng)目中,這種重復(fù)的集成活動將非常耗時,并且會花費(fèi)大量人力。因此,手動集成步驟的自動化實(shí)現(xiàn),對縮減項(xiàng)目集成時間,降低集成的人力成本,加快版本發(fā)布,都能帶來極大的好處。
如何解決這些挑戰(zhàn)?
上述挑戰(zhàn),使得ECU的軟件開發(fā)過程變得繁瑣,且迭代周期變得滯后。為了應(yīng)對這些挑戰(zhàn),DaVinci Team提供一種分布式開發(fā)團(tuán)隊(duì)高效協(xié)作的解決方案?;靖拍钊缦拢?/p>
SWC和BSW解耦;
前移集成決策(例如,Runnable和Task的映射、端口映射、數(shù)據(jù)映射或NvM集成決策),以便于SWC開發(fā)人員能夠自行將SWC與BSW集成;
提供一個自動化Pipeline,自動執(zhí)行SWC與BSW集成的步驟。
結(jié)合支持自動化的工具,基于定制的持續(xù)集成Pipeline,工程師能夠獨(dú)立工作,并省去大量的重復(fù)工作。
2.1 基于組件開發(fā)的集成滯后問題
使用DaVinci Team,可以通過不同的方式組織項(xiàng)目,從而顯著解決前文提到的這些挑戰(zhàn)。首先是拆分項(xiàng)目(圖2-1)使得SWC與BSW解耦并將BSW定義為Root Configuration。
對于優(yōu)化工作流程至關(guān)重要的一步是移除RTE并為SWC添加集成指令(Integration Instruction)。這完全避免了RTE的合并,解決了合并項(xiàng)目增量時經(jīng)常遇到的沖突問題。
圖2-1DaVinci Team工作流程
關(guān)于SWC,需要由SWC開發(fā)人員將其分解為App Package。這種分解的最大好處是限制合并沖突,并通過Instruction文件來管理App Package,從而實(shí)現(xiàn)持續(xù)集成。
在此背景下,App Package定義如下:
SWC組件(ARXML)
源代碼或庫文件
Instruction文件(Task Mapping、Port Mapping、Data Mapping等JSON文件)
圖 2-2 示例App-Package
圖2-2顯示了一個示例App Package。這些JSON格式的Instruction文件描述了RTE應(yīng)該如何構(gòu)建(下一章中將詳細(xì)說明)。
盡管項(xiàng)目被拆分成多個包,用戶仍然可以自由選擇他們喜歡的開發(fā)方法。這只是一個在倉庫中組織包的問題:包含所有包的單一倉庫(適用于基于功能的開發(fā)方法)或創(chuàng)建多個倉庫,每個倉庫包含單一的包(適用于基于組件的開發(fā)方法)。
2.2 前移集成決策
App Package作為DaVinci Team的輸入,包含了JSON格式的Integration Instruction。為了在不同角色之間實(shí)現(xiàn)高效協(xié)作,也可以為整個項(xiàng)目定義全局集成指令(Global Integration Instruction),不同集成角色將使用不同類型的Integration Instruction。
>顯式映射
這種類型的Integration Instruction可用于明確定義映射關(guān)系。例如,在Task映射的示例中,可以定義哪些runnable應(yīng)該映射到哪些Task。如圖2-3所示,runnable0和runnabl1需要映射到task0,并且在JSON文件中列出了runnable的屬性(以runnable0為例,runnable0在swc0中,具有schedulePoint和activationOffset的屬性)。
圖2-3顯式映射
>基于規(guī)則的映射
也可以使用基于規(guī)則的映射方式,如圖2-4所示,是一個包括了不同規(guī)則的Instruction文件。首先定義應(yīng)用規(guī)則的Task(task0),然后指定觸發(fā)類別(周期、初始化或其他),接著是觸發(fā)條件(周期:100ms),最后列出應(yīng)用此規(guī)則的SWC(這里是swc2)。
圖 2-4 基于規(guī)則的映射
>自動映射
這個功能可以在配置文件中配置為啟用或禁用。特別是在項(xiàng)目早期階段或用于原型設(shè)計(jì)時,自動映射可以在不需要Integration Instruction的情況下獲得符合AUTOSAR標(biāo)準(zhǔn)的映射。這個功能旨在作為一個補(bǔ)充解決方案,生成的配置應(yīng)該由開發(fā)人員進(jìn)行評估或優(yōu)化。
除了Task映射之外,還有其他類型的Instruction,如時序順序約束文件(Execution Order Constraint)和NvM集成Instruction,還可以為端口映射(Port Mapping)和數(shù)據(jù)映射(Data Mapping)提供Integration Instruction。
>全局集成指令
全局集成指令很多情況下,中央集成團(tuán)隊(duì)可能仍然希望監(jiān)督集成決策,這可以通過提供Global Instruction來實(shí)現(xiàn)。這些Global Instruction具有與App Package相同的格式和映射指令類型,但具有更高的優(yōu)先級,并且會覆蓋App Package中的指令。
2.3 用于自動集成的Pipeline
該P(yáng)ipeline基于Gradle構(gòu)建系統(tǒng)實(shí)現(xiàn),并且項(xiàng)目中每個成員都可以使用。無論是更改SWC還是更改BSW的Root Configuration,都會以確定性的方式執(zhí)行相同的集成步驟。根據(jù)這一理念,每個開發(fā)人員都可以輕松集成ECU軟件。
DaVinci Team可以在本地或服務(wù)器上運(yùn)行。在服務(wù)器場景下,對代碼倉庫的提交可以觸發(fā)Pipeline的集成動作,例如通過Jenkins這樣的構(gòu)建服務(wù)器進(jìn)行控制。這使得SWC開發(fā)人員可以獨(dú)立于中央集成團(tuán)隊(duì)工作。在本地場景下,可以通過命令行觸發(fā)Pipeline的集成動作。前文描述的在DaVinci Configurator Classic的GUI中的重復(fù)手動步驟(見第1.3節(jié)),現(xiàn)在可以完全自動化處理。如圖2-5所示,集成Pipeline被觸發(fā)后將自動執(zhí)行圖中灰色的集成步驟。
圖2-5 自動集成步驟
自動集成步驟如下:
1.準(zhǔn)備步驟:
a. SIP被復(fù)制到執(zhí)行主機(jī)(如有必要)
b. Root Configuration和App Package被復(fù)制到執(zhí)行主機(jī)
2.執(zhí)行DaVinci Team自動化操作:
a. SWC類型被實(shí)例化
b. 通過NV data port配置文件,生成NvSWC
c. 基于集成指令(如Port Mapping、Data Mapping、Task Mapping等),生成RTE
d. 初始化未使用的SWC端口
3.輸出步驟:
a. 生成模塊
b. 生成源碼
c. 編譯
d. 打包工程
集成ECU軟件(包括SWC、RTE和BSW)完成后,輸出文件包括.elf、.c/.h和.dpa,同時還包括執(zhí)行Pipeline期間的操作報(bào)告。值得一提的是,DaVinci Team支持vVIRTUALtarget項(xiàng)目以及Real Target平臺,無論開發(fā)人員是基于vVIRTUALtarget或是實(shí)際ECU驗(yàn)證,都能通過DaVinci Team集成軟件并生成相應(yīng)的目標(biāo)產(chǎn)物來支持后續(xù)的驗(yàn)證工作。
集成后的結(jié)果可以上傳到類似Artifactory的二進(jìn)制數(shù)據(jù)管理系統(tǒng),以便開發(fā)人員下載集成版本。然而,集成結(jié)果不需要存儲在像Git這樣的源代碼管理系統(tǒng)中,后者更適合用作開發(fā)人員代碼版本管理的工具。這種集成過程通過動態(tài)執(zhí)行,可以有效避免RTE的合并問題。
自動化Pipeline還可以通過添加自定義擴(kuò)展來進(jìn)行定制,這使得工具專家可以進(jìn)一步創(chuàng)建適配于項(xiàng)目工程的自動化工具腳本,并擴(kuò)展CI/CD Pipeline。
總結(jié)
當(dāng)今的ECU軟件開發(fā)正逐步轉(zhuǎn)變,以應(yīng)對日益增加的軟件功能、更多的協(xié)作以及實(shí)現(xiàn)更短的發(fā)布周期。然而,采用DevOps方法并實(shí)現(xiàn)持續(xù)集成的自動化會面臨諸多挑戰(zhàn),特別是由于AUTOSAR Classic項(xiàng)目的串行開發(fā)特性。面對這些挑戰(zhàn),Vector基于DaVinci Team工具,為軟件開發(fā)人員提供可行的解決方案:
挑戰(zhàn):不同軟件開發(fā)人員在同一項(xiàng)目中的SWC和BSW配置有不同的實(shí)現(xiàn),合并這些不同的實(shí)現(xiàn)是一個重大的挑戰(zhàn)。
解決方案:通過移除RTE,來解耦SWC和BSW,極大程度地避免了合并時的沖突問題。這個解決方案在第2.1節(jié)中有詳細(xì)描述。
挑戰(zhàn):按計(jì)劃進(jìn)行的SWC集成時間過長,導(dǎo)致延遲發(fā)現(xiàn)問題,這可能會危及項(xiàng)目的里程碑。
解決方案:將集成決策前置(例如Runnable和Task的映射、端口映射、數(shù)據(jù)映射或NvM集成決策),以賦予SWC開發(fā)人員自行集成SWC與BSW的能力。這一概念在2.2節(jié)中有詳細(xì)描述。
挑戰(zhàn):將SWC集成到BSW中通常涉及許多手動步驟,違背了敏捷開發(fā)的原則。
解決方案:DaVinci Team使用自動化Pipeline,可以自動執(zhí)行SWC和BSW集成過程中的手動步驟。這個自動化Pipeline在2.3節(jié)中有詳細(xì)描述。
Vector通過DaVinci Team提供解決方案,以實(shí)現(xiàn)敏捷和高效的AUTOSAR Classic ECU軟件開發(fā)。工程師們可以通過基于多種工具的自動化Pipeline來獨(dú)立工作。這一自動化過程可以簡化大部分重復(fù)的工作步驟,避免集成過程中的沖突問題,集成時間滯后問題。
-
軟件開發(fā)
+關(guān)注
關(guān)注
0文章
636瀏覽量
28021 -
AUTOSAR
+關(guān)注
關(guān)注
10文章
370瀏覽量
22298 -
ecu
+關(guān)注
關(guān)注
14文章
905瀏覽量
55310 -
Vector
+關(guān)注
關(guān)注
3文章
65瀏覽量
8964
原文標(biāo)題:DaVinci Team | 助力CI環(huán)境下的AUTOSAR Classic ECU 軟件開發(fā)
文章出處:【微信號:VectorChina,微信公眾號:Vector維克多】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
ECU電控軟件開發(fā)及測試介紹

Autosar軟件開發(fā)技術(shù)概述
如何購買AUTOSAR軟件?
AUTOSAR架構(gòu)深度解析及開發(fā)指引 精選資料分享
ECU/MCU軟件開發(fā)
AUTOSAR的相關(guān)資料推薦
基于OSEKturbo的電控柴油機(jī)ECU軟件開發(fā)與實(shí)現(xiàn)
基于AUTOSAR規(guī)范的汽車ECU軟件開發(fā)方法

基于CANoe和Visual Studio實(shí)現(xiàn)Classic和Adaptive AUTOSAR應(yīng)用層調(diào)試
AUTOSAR軟件開發(fā)環(huán)境之EB tresos Studio簡介

Elektrobit已正式推出現(xiàn)成的Classic AUTOSAR和OSEK軟件和服務(wù)
Vector和HighTec推出基于Rust和AUTOSAR Classic實(shí)現(xiàn)安全應(yīng)用的解決方案

9月12日云技術(shù)研討會 | ECU電控軟件開發(fā)及測試全流程解決方案

評論