當下ECU軟件開發(fā)的挑戰(zhàn)

隨著軟件技術(shù)的發(fā)展，車輛的開發(fā)過程從硬件主導(dǎo)轉(zhuǎn)變?yōu)檐浖x汽車（SDV），軟件開發(fā)在汽車的開發(fā)過程中扮演著舉足輕重的角色。車輛E/E架構(gòu)由原先的各ECU只負責單一功能的分布式架構(gòu)，轉(zhuǎn)變?yōu)楦咝阅苡嬎銌卧℉PC）和區(qū)域控制單元（Zonal ECU）分工協(xié)作的架構(gòu)。因此，ECU的軟件功能越來越多，越來越復(fù)雜。ECU的軟件開發(fā)，也將引入不同部門、不同公司的更多項目開發(fā)人員的協(xié)作。在ECU軟件開發(fā)變得更加復(fù)雜更加緊密協(xié)作的同時，軟件的版本迭代周期也變得越來越短。

傳統(tǒng)的工作流程和開發(fā)過程難以滿足這些要求，因此以DevOps為導(dǎo)向的持續(xù)集成方法正成為新的趨勢。然而，由于AUTOSAR Classic項目的單一工程結(jié)構(gòu)，實現(xiàn)AUTOSAR Classic ECU軟件開發(fā)的持續(xù)集成并不是一項容易的任務(wù)。根據(jù)項目的部署和開發(fā)過程，可以觀察到以下三種方式及挑戰(zhàn)。

1.1 基于功能開發(fā)中的合并沖突問題

將項目中各成員的增量（設(shè)計、配置和實現(xiàn)）合并是一個重大挑戰(zhàn)，特別是基于各功能團隊獨立開發(fā)的模式。對于AUTOSAR Classic項目（圖1-1），基于功能的開發(fā)方式意味著項目成員開發(fā)應(yīng)用軟件（SWC），并自行將其集成到基礎(chǔ)軟件（BSW）中。這種方法可以應(yīng)用于獨立完整的SWC，也可以應(yīng)用于與其他項目成員協(xié)作開發(fā)的SWC。

圖1-1基于功能的開發(fā)方式

1.2 基于組件開發(fā)的集成滯后問題

另一種方法是將工作角色劃分為項目內(nèi)更專業(yè)的角色，這里定義為基于組件的開發(fā)方式（圖1-2）。在這種項目開發(fā)方式中，有專注于SWC的應(yīng)用開發(fā)人員，以及一個軟件集成團隊負責配置BSW，并將SWC和BSW進行集成。

圖1-2基于模塊的開發(fā)方式

在這種情況下，應(yīng)用開發(fā)人員既無法訪問BSW的配置，也無法使用工具將SWC與BSW集成。相比于基于功能的開發(fā)方式（每個項目成員可以獨立處理自己的功能），在基于組件的開發(fā)方式中，應(yīng)用開發(fā)人員依賴于軟件集成團隊。

圖1-3基于模塊的開發(fā)方式的集成流程

這種方法的好處是減少了合并問題，缺點是集成的總時長增加了。軟件集成團隊只能在應(yīng)用開發(fā)人員完成他們的工作后才開始集成，而且集成必須根據(jù)軟件集成團隊的可用時間進行安排。據(jù)應(yīng)用開發(fā)人員的反饋，許多人等待他們的SWC與BSW集成的時間在1到4周之間，導(dǎo)致驗證延遲，發(fā)現(xiàn)問題延遲，最終可能會危及項目的里程碑。圖1-3描述了這種集成流程。

1.3 手動集成中的重復(fù)工作問題

在傳統(tǒng)的基于DaVinci Configurator Classic GUI的工作模式中，將SWC與BSW集成需要許多手動步驟（圖1-4）。

圖1-4手動集成步驟

首先，需要打開DaVinci Configurator Classic并將SWC加載到項目中。接下來，針對每個 SWC需要執(zhí)行以下重復(fù)的步驟：

手動配置RTE，例如將Runnable映射到Task，將NvSWC連接到對應(yīng)部分，創(chuàng)建或調(diào)整內(nèi)存塊，以及添加數(shù)據(jù)映射；

配置完成后，需要驗證配置，并解決可能存在的問題。

在SWC和Runnable數(shù)量龐大的大型項目中，這種重復(fù)的集成活動將非常耗時，并且會花費大量人力。因此，手動集成步驟的自動化實現(xiàn)，對縮減項目集成時間，降低集成的人力成本，加快版本發(fā)布，都能帶來極大的好處。

如何解決這些挑戰(zhàn)?

上述挑戰(zhàn)，使得ECU的軟件開發(fā)過程變得繁瑣，且迭代周期變得滯后。為了應(yīng)對這些挑戰(zhàn)，DaVinci Team提供一種分布式開發(fā)團隊高效協(xié)作的解決方案?；靖拍钊缦拢?/p>

SWC和BSW解耦；

前移集成決策（例如，Runnable和Task的映射、端口映射、數(shù)據(jù)映射或NvM集成決策），以便于SWC開發(fā)人員能夠自行將SWC與BSW集成；

提供一個自動化Pipeline，自動執(zhí)行SWC與BSW集成的步驟。

結(jié)合支持自動化的工具，基于定制的持續(xù)集成Pipeline，工程師能夠獨立工作，并省去大量的重復(fù)工作。

2.1 基于組件開發(fā)的集成滯后問題

使用DaVinci Team，可以通過不同的方式組織項目，從而顯著解決前文提到的這些挑戰(zhàn)。首先是拆分項目（圖2-1）使得SWC與BSW解耦并將BSW定義為Root Configuration。

對于優(yōu)化工作流程至關(guān)重要的一步是移除RTE并為SWC添加集成指令（Integration Instruction）。這完全避免了RTE的合并，解決了合并項目增量時經(jīng)常遇到的沖突問題。

圖2-1DaVinci Team工作流程

關(guān)于SWC，需要由SWC開發(fā)人員將其分解為App Package。這種分解的最大好處是限制合并沖突，并通過Instruction文件來管理App Package，從而實現(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)建（下一章中將詳細說明）。

盡管項目被拆分成多個包，用戶仍然可以自由選擇他們喜歡的開發(fā)方法。這只是一個在倉庫中組織包的問題：包含所有包的單一倉庫（適用于基于功能的開發(fā)方法）或創(chuàng)建多個倉庫，每個倉庫包含單一的包（適用于基于組件的開發(fā)方法）。

2.2 前移集成決策

App Package作為DaVinci Team的輸入，包含了JSON格式的Integration Instruction。為了在不同角色之間實現(xiàn)高效協(xié)作，也可以為整個項目定義全局集成指令（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ī)則的映射

>自動映射

這個功能可以在配置文件中配置為啟用或禁用。特別是在項目早期階段或用于原型設(shè)計時，自動映射可以在不需要Integration Instruction的情況下獲得符合AUTOSAR標準的映射。這個功能旨在作為一個補充解決方案，生成的配置應(yīng)該由開發(fā)人員進行評估或優(yōu)化。

除了Task映射之外，還有其他類型的Instruction，如時序順序約束文件（Execution Order Constraint）和NvM集成Instruction，還可以為端口映射（Port Mapping）和數(shù)據(jù)映射（Data Mapping）提供Integration Instruction。

>全局集成指令

全局集成指令很多情況下，中央集成團隊可能仍然希望監(jiān)督集成決策，這可以通過提供Global Instruction來實現(xiàn)。這些Global Instruction具有與App Package相同的格式和映射指令類型，但具有更高的優(yōu)先級，并且會覆蓋App Package中的指令。

2.3 用于自動集成的Pipeline

該Pipeline基于Gradle構(gòu)建系統(tǒng)實現(xiàn)，并且項目中每個成員都可以使用。無論是更改SWC還是更改BSW的Root Configuration，都會以確定性的方式執(zhí)行相同的集成步驟。根據(jù)這一理念，每個開發(fā)人員都可以輕松集成ECU軟件。

DaVinci Team可以在本地或服務(wù)器上運行。在服務(wù)器場景下，對代碼倉庫的提交可以觸發(fā)Pipeline的集成動作，例如通過Jenkins這樣的構(gòu)建服務(wù)器進行控制。這使得SWC開發(fā)人員可以獨立于中央集成團隊工作。在本地場景下，可以通過命令行觸發(fā)Pipeline的集成動作。前文描述的在DaVinci Configurator Classic的GUI中的重復(fù)手動步驟（見第1.3節(jié)），現(xiàn)在可以完全自動化處理。如圖2-5所示，集成Pipeline被觸發(fā)后將自動執(zhí)行圖中灰色的集成步驟。

圖2-5 自動集成步驟

自動集成步驟如下：

1.準備步驟:

a. SIP被復(fù)制到執(zhí)行主機（如有必要）

b. Root Configuration和App Package被復(fù)制到執(zhí)行主機

2.執(zhí)行DaVinci Team自動化操作:

a. SWC類型被實例化

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期間的操作報告。值得一提的是，DaVinci Team支持vVIRTUALtarget項目以及Real Target平臺，無論開發(fā)人員是基于vVIRTUALtarget或是實際ECU驗證，都能通過DaVinci Team集成軟件并生成相應(yīng)的目標產(chǎn)物來支持后續(xù)的驗證工作。

集成后的結(jié)果可以上傳到類似Artifactory的二進制數(shù)據(jù)管理系統(tǒng)，以便開發(fā)人員下載集成版本。然而，集成結(jié)果不需要存儲在像Git這樣的源代碼管理系統(tǒng)中，后者更適合用作開發(fā)人員代碼版本管理的工具。這種集成過程通過動態(tài)執(zhí)行，可以有效避免RTE的合并問題。

自動化Pipeline還可以通過添加自定義擴展來進行定制，這使得工具專家可以進一步創(chuàng)建適配于項目工程的自動化工具腳本，并擴展CI/CD Pipeline。

總結(jié)

當今的ECU軟件開發(fā)正逐步轉(zhuǎn)變，以應(yīng)對日益增加的軟件功能、更多的協(xié)作以及實現(xiàn)更短的發(fā)布周期。然而，采用DevOps方法并實現(xiàn)持續(xù)集成的自動化會面臨諸多挑戰(zhàn)，特別是由于AUTOSAR Classic項目的串行開發(fā)特性。面對這些挑戰(zhàn)，Vector基于DaVinci Team工具，為軟件開發(fā)人員提供可行的解決方案：

挑戰(zhàn)：不同軟件開發(fā)人員在同一項目中的SWC和BSW配置有不同的實現(xiàn)，合并這些不同的實現(xiàn)是一個重大的挑戰(zhàn)。

解決方案：通過移除RTE，來解耦SWC和BSW，極大程度地避免了合并時的沖突問題。這個解決方案在第2.1節(jié)中有詳細描述。

挑戰(zhàn)：按計劃進行的SWC集成時間過長，導(dǎo)致延遲發(fā)現(xiàn)問題，這可能會危及項目的里程碑。

解決方案：將集成決策前置（例如Runnable和Task的映射、端口映射、數(shù)據(jù)映射或NvM集成決策），以賦予SWC開發(fā)人員自行集成SWC與BSW的能力。這一概念在2.2節(jié)中有詳細描述。

挑戰(zhàn)：將SWC集成到BSW中通常涉及許多手動步驟，違背了敏捷開發(fā)的原則。

解決方案：DaVinci Team使用自動化Pipeline，可以自動執(zhí)行SWC和BSW集成過程中的手動步驟。這個自動化Pipeline在2.3節(jié)中有詳細描述。

Vector通過DaVinci Team提供解決方案，以實現(xiàn)敏捷和高效的AUTOSAR Classic ECU軟件開發(fā)。工程師們可以通過基于多種工具的自動化Pipeline來獨立工作。這一自動化過程可以簡化大部分重復(fù)的工作步驟，避免集成過程中的沖突問題，集成時間滯后問題。