面向教育汽車軟件工程的AUTOSAR靜態測試策略

原創智能汽車開發者平臺 2022-09-13 18:00

進階BLE開發：DA1459x 外設、功耗與工程實戰 瑞薩×物聯網：4 場直播，搞定全棧無線連接開發

摘要

AUTOSAR（汽車開放系統架構）是歐洲汽車領域軟件開發的領先架構基礎。然而，由于存在大量不同的工具、規范和架構指南，其本身就很復雜，所以使用時更復雜。因此，汽車軟件工程領域的學生需要指導和手段，以快速和可理解的方式評估他們的編程輸出是否符合標準。基于之前提出的汽車軟件工程的教育云平臺，在本文中提出了一種評估基于AUTOSAR的軟件開發質量的方法。這種方法被定位為開發過程中的一個步驟，學習者最終會在測試驅動過程中運行實現，以評估其實際性能。在這樣的測試基礎設施中，關于測試執行的資源總是短缺的，因為真正的測試驅動涉及相當復雜的準備工作和時間表。但在采用軟件或硬件在環模擬的情況下，也需要協調執行。因此，本文描述的方法有兩方面的重點。一方面，希望在更稀缺的資源（如模擬器或真正的測試車輛）被分配之前，盡快捕捉方法上的錯誤。為此，我們提出了專門用于評估基于AUTOSAR實現的靜態測試方法。希望避免實際運行必然會失敗的實現。另一方面，上述方法的輸出應使學習者和開發者更容易評估和比較其結果的質量。

I.簡介

在過去的15年里，汽車領域的軟件開發經歷了很多的重新調整和改進，包括對現有方法論的改進以及新方法的建立。今天，軟件組件的模塊化、可重用性和可測試性等方面被認為與實際功能同等重要。因此，旨在減輕確保這些特性所需精力的架構已經被開發出來。其中一個框架是AUTOSAR（Automotive Open System Architecture），它是歐洲汽車軟件工程的事實上的標準。本質上，由于涉及許多不同的要求和企業，AUTOSAR是一個非常復雜的話題，擁有一個陡峭的學習曲線，需要大量的經驗才能有效地工作。因此，開發人員需要應用不同領域的知識，如硬件開發、通信系統和軟件工程。此外，汽車開發人員必須在資源受限的系統中操作，需要比非嵌入式編程（如網絡開發）更有效地使用。AUTOSAR引入了以功能為導向的應用開發范式。它將電子控制單元（ECU）的系統結構分成三個水平層--應用層、運行時環境（RTE）和基本軟件。應用層的開發是獨立于目標平臺的。因此，在開發新功能時，需要花費相對較長的時間，直到開發人員能夠觀察到他們的代碼在真實車輛的真實硬件上運行，而這兩者在開發開始時可能根本不存在。在此之前，將對實施方案進行大量的測試，以確保質量并且符合AUTOSAR標準，并暴露出需要返工的地方。此外，每個測試步驟都需要獲得更多有限的測試資源，例如單元測試平臺、硬件/軟件在環解決方案和最終的真實測試車輛。圖1說明了V型模型中開發過程中的各種測試步驟，這是在嵌入式汽車軟件開發中使用的主要過程模型。然而，這種設置使得開發人員，特別是學習者，很難及時檢索反饋信息，或者以簡潔的方式評估、可視化以及比較他們的進展。因此，一個測試步驟越早進行，其結果就應該越快得到，對稀缺資源的依賴也就越少。滿足這些要求的一種方法是靜態代碼分析。在本文中指出靜態代碼分析在多大程度上可用于基于AUTOSAR的軟件的早期測試和評估。此外，將展示AUTOSAR特定的靜態測試如何為汽車學習者和開發人員提供比通用靜態代碼分析更多的好處。

圖 1.? 標明測試階段的V模型

II.相關工作

靜態代碼分析是軟件測試方法學的一個重要組成部分。它是通過在語法和語義層面上分析源代碼來進行的，但不需要實際編譯和執行。靜態代碼分析被用作一種手段，以發現開發人員常犯的錯誤，這些錯誤不會導致編譯器錯誤，但很可能表現為運行時故障—一個眾所周知的例子是在Java中使用引用相等來比較字符串。此外，靜態代碼分析工具1也經常被用來確保遵守代碼準則，如項目范圍內一致的標識符命名。統一的風格是可取的，以減少團隊成員在接手別人的源代碼時的學習難度，并方便編碼審查。此外，當還沒有完全可編譯和可執行的原型時，靜態分析可以在早期開發階段發現問題。這是一種節約成本和開發資源的手段，因為通常在開發過程中越晚發現缺陷，修復的成本就越高，這是由模型和現實世界研究提出的。此外，靜態代碼分析經常被用來搜索導致軟件安全漏洞的缺陷。事實上，在行業中生效的一些安全規范要求使用靜態代碼分析2。根據所使用的編程語言，存在著大量不同的靜態分析工具。由于AUTOSAR是C標準，可以使用針對C的靜態分析工具。在這個領域，一些現有的和不斷開發的工具是Infer、Coverity和Splint。作為一個特例，Clang3值得一提，它本身是一個編譯器，但也提供一個靜態分析器。這些工具是報告內容方面的通用工具。一方面，這些是警告或錯誤，暗示著可能的運行時問題，另一方面，可能的輸出是代碼質量指標。這樣的指標提供了一種快速的方法來評估代碼庫的總體性質和質量。它們的范圍可以從最簡單的代碼行數、評論與代碼比率到更復雜的，如循環復雜性。然而，通用工具只能檢查有關編程語言的常見錯誤，并執行風格指導，但不能詳盡地分析AUTOSAR項目，因為它們沒有考慮到領域知識。這主要是由于AUTOSAR項目由模塊化的源代碼文件和大量的配置文件組成，這些文件是相互依賴的。在此基礎上，配置是AUTOSAR項目的一個非常復雜和關鍵的方面。因此，許多錯誤都與配置有關，特別是在早期開發階段。例如，定義的端口或屬性實際上沒有被實現，或者配置和實現的行為之間不匹配。這些錯誤不可能用標準的C語言靜態分析工具發現，因為這些工具只在源代碼層面上操作。

在[7]中，作者使用三種常見的靜態分析工具，對AUTOSAR軟件組件的可測試性進行了研究。然而，他們只評估了有關C語言編程的常見錯誤，而沒有評估與AUTOSAR配置有關的錯誤。因此，最近提出了專門為測試AUTOSAR項目設計的靜態測試方法。? 在教育背景下，為學習者提供一種簡單易懂的方式來評估他們自己的表現或進步也很重要。此外，還需要一個指標來比較相互競爭的實施方案，以便選擇應該被看好的解決方案進行進一步測試。因此，在本文中提出了一個在汽車軟件工程教育背景下的AUTOSAR項目的靜態分析方法。與一般用途的提示器一樣，這種方法提供了質量指標和可能的錯誤檢測，但以AUTOSAR特定的方式，使其對汽車領域的學習者和開發者更加有用。此外，還會根據檢測到的問題提供糾正建議。本文展示了如何利用這些靜態分析來評估和提高AUTOSAR項目的質量。

III.AUTOSAR特定靜態分析

如前所述，本文提出的方法有兩個目的，一方面是為開發人員，特別是學習者提供一個簡單而便捷的方法來評估他們的表現，另一方面是在動態和集成測試階段之前提高汽車軟件項目的質量。提出方法與V型模型中的四個主要發展里程碑相結合，如圖1所示（M1至M4）。在第一個里程碑中，支持的對象是單個功能的開發者，他們會根據所進行的靜態分析得到提示。這提高了AUTOSAR項目在實施過程中的代碼庫質量，確保了與標準有關的一致行為，并通過糾正建議促進了學習效果。第二個里程碑在正常測試過程開始之前。這里進行的檢查可能比在里程碑一的檢查更嚴格。例如，對某些模式的遵守可以被強制執行，而在第一步中只建議更改。這是必要的，因為開發人員可能會在(原型)開發期間忽略提示，或者以非標準兼容的方式合并建議的糾正。因此，在這個里程碑的分析確保了測試過程開始前的預期質量水平。事實上，如果使用虛擬驗證平臺，這個里程碑可能存在兩次。在這種情況下，在V模型中建立第二個測試分支（見圖1），并在虛擬平臺上測試AUTOSAR應用之前執行檢查。然后在V模型的右側分支中正常處理常規測試流程。在目標ECU上動態測試實際代碼之前的第三個里程碑，不僅要檢查應用程序的質量，還要檢查基本軟件（BSW）和RTE。這可能是這個過程中最重要的一步，因為AUTOSAR提供了大量的參數作為ECU配置的一部分。這個配置需要以一種特定于應用程序的方式創建，這意味著在這一點上的修改可能也需要對應用程序進行調整。第四個里程碑位于開發過程的后期，對整個 AUTOSAR 項目的質量進行評估，因此涉及的檢查可能與之前的檢查非常不同。這個里程碑的想法是確保應用程序的高質量，并評估它們是否適合被添加到跨項目的汽車庫中。該庫中的應用將在其他項目中以新的配置重新使用，因此要遵守更嚴格的合規性和兼容性要求。特別是通過第二和第四個里程碑的檢查，可以對參與項目的開發人員進行分類或評估。因此，它們已被用作AUTOSAR軟件工程自適應學習概念的一部分。總之，里程碑M1至M4的檢查旨在實現AUTOSAR開發的以下方面：

M1? 通過改正建議為個別開發者提供支持

M2 對AUTOSAR應用的分析，以及對目前開發草案RTE部分內容的分析

M3? 對BSW和最終RTE應用特定的檢查

M4? 應用特定的BSW和RTE的動態測試，適合于整合到庫中

圖 2.? 靜態測試AUTOSAR

如圖2所示，AUTOSAR項目主要由配置文件和源代碼組成，這些文件都是由提出的靜態測試來分析的。這些測試與實際使用的工具鏈無關，只要對正式的、標準化的文件進行分析即可。該分析建立在一個廣泛的知識庫上，其中包含AUTOSAR的架構信息。該知識庫主要包括BSW及其模塊以及RTE的信息。每個AUTOSAR版本的信息都是單獨存儲的，從而能夠支持針對不同版本和供應商堆棧的并行開發。每個靜態分析都可能產生一個修正建議，包括對程序員的解釋。如果應用了此修正，并且項目文件發生了更改，那么該檢查也將重新運行。這就避免了在項目中因錯誤應用糾正建議而造成的錯誤。如果在分析過程中確實發生了問題，但沒有進行修正，則在分析報告中增加一個單獨的報告條目。該報告條目包含關于文件、行號和分析模塊的信息。

A.?分析的對象

靜態分析的對象是某AUTOSAR項目的文件。這包括所有架構層，即應用、BSW和RTE。除了在每個文件的基礎上進行分析外，我們還解決和比較不同位置和層之間的屬性問題。?

雖然AUTOSAR項目可以由不同供應商的不同工具創建，但它通常由以下類型的文件組成：

●? ?源代碼文件（c和h文件）

●? ?AUTOSAR標準規定的配置文件

●? ?供應商指定的配置文件

該靜態分析是基于對所謂方面的定義。一個方面確定了相關分析的調查重點。目前，對于每個被分析的項目，可以定義一組具有以下屬性的問題：

●? 顆粒度

●? ?AUTOSAR 層

一個方面的粒度目前可以是三個不同的類別之一--文件、函數和代碼/配置行，如表I所示。

相應的，AUTOSAR層方面是應用層、BSW和RTE。每一個方面a的分析都會產生一個相應的覆蓋值cva，它是成功檢查的實體數量(取決于粒度)和這個方面中實體總數之間的比率，例如cva = #檢查的entitiesa /#entitiesa(#是基數)。

B. AUTOSAR一致性等級

一組覆蓋率值可用于計算AUTOSAR軟件項目或項目部分的單一、整體質量值。這種綜合指標稱為 AUTOSAR 一致性水平 CL。讓cva指定給定方面a的一致性值和ωa的嚴重度，那么集合A中各方面的CL可以用以下方法計算:

其結果是一個單一的值，它提供了一個簡明的方法來快速評估AUTOSAR項目在標準一致性方面的質量。在下一節中，將展示如何使用一致性值和級別來提高資源利用率和開發人員在基于AUTOSAR的汽車開發和測試基礎設施中的反饋。

IV.應用和用例

對于汽車軟件工程研究課程的發展，我們已經建立了工作流程，如圖3所示，該流程已在[4]中提出。在那里，學習者可以在基于AUTOSAR的實施方案的開發周期中承擔不同的角色。它們得到了兩個工具的支持。ASTAS（AUTOSAR系統的應用規格測試）和TUC驅動云。前者提供了測試AUTOSAR ECU的方法，而后者則提供了一個測試驅動管理接口，以及訪問汽車測試驅動數據的大數據存儲的標準化方法。

圖 3.? 已部署的汽車軟件工程工具鏈與圖1中注釋的測試步驟

由于本文提出的AUTOSAR特定靜態測試已被整合到ASTAS中，本節將把重點放在這里。圖4說明了測試AUTOSAR項目的原型的工作流程，以及ASTAS在這個過程中的整合。ASTAS包含用于分析AUTOSAR項目的軟件模塊和用于AUTOSAR ECU動態測試的軟件模塊。除了AUTOSAR特定的靜態測試，ASTAS還支持以連續的方式對BSW和RTE進行應用特定的測試。這種測試方法是用符合AUTOSAR的方法實現的，并支持錯誤定位。知識庫包含了在目標平臺上實現動態測試的所有必要信息。關于這種方法的細節在[18]中解釋。除了自有的功能之外，還整合了一個商業工具鏈，用于代碼分析、構建和測試。在開發和教學過程中，從以下方面檢查項目：

●? ? AUTOSAR應用之間的連接(M1, M2)

●? ?符合AUTOSAR BSW（M2）的要求

●? ?產生的RTE與應用程序和BSW的一致性（M2, M3）

●? ?整個AUTOSAR應用的一致性（M1, M4）

圖 4.? 通過ASTAS和集成工具鏈測試AUTOSAR系統的工作流程

圖 5.? 應用程序中軟件組件之間未連接端口的例子

第一個檢查是評估應用程序內通信的一致性。AUTOSAR在應用中定義了所謂的軟件組件，它代表了ECU的實際功能。為了實現部分或完整應用的可重復使用性，軟件組件內的通信需要符合標準。然而，遵守標準通常意味著實施者要做額外的工作，而學習者往往在一開始就盡量避免。因此，在實施過程中，使用這種考核是確保軟件質量的一個非常重要的輔助手段。AUTOSAR ECU的BSW是根據映射的應用進行配置的，由一組不同的模塊組成。為了確保符合標準，第二次評估根據應用情況檢查項目中的集成和配置模塊。這一步驟確保了應用程序在以后開發中的可擴展性。在實施應用和配置BSW之后，AUTOSAR方法論規定了RTE的生成。這是在目標平臺上測試前的最后一步。由于不同的層（RTE、BSW、Application）可以使用不同的工具進行開發，AUTOSAR ECU的所有三個層的一致性需要得到確認。這種檢查避免了測試過程后面步驟中代價高昂的錯誤定位。第四個方面是單獨測試應用程序。它包含關于代碼合規性、架構和編碼準則的檢查。通過這種方式，希望確保AUTOSAR庫的軟件質量，其中包含用于教學、學生自我評估以及研究課題的應用程序。例如，我們正在使用這些評估層面，對研究示范車Yellow Car 進行持續測試，其中包括3個符合AUTOSAR的ECU。在汽車軟件課程教學方面，最重要的應用之一是燈光控制，它管理著汽車的不同燈光（如內部、外部）。燈光控制的主要功能被映射到一個ECU，由11個軟件組件組成，共有48個端口。AUTOSAR應用之間的聯系評估了AUTOSAR規格化的配置文件，稱為系統描述。就燈光控制而言，已經檢查了3429行的配置和262行的代碼。為了演示各層面檢查的目的，想象一下圖5中的情景：在當前的開發中，應該集成兩個新的端口。這些端口能夠集成一個活躍的信號，代表對其他ECU的可用性。被指定的開發者已經在軟件架構中實現了這些端口，但它們在RTE中沒有端點。因此，該評估將顯示96%的符合性（見公式2）。但是，我們對連接端口的測試配置將100%定義為嚴格的要求。因此，程序員需要解決斷

開連接的端口。這個檢查乍一看可能是微不足道的，但是因為即使沒有連接的端口，代碼也是可編譯的，它是在開發后期才會被檢測到的方面，從而產生不必要的額外費用。此外，根據經驗，這種錯誤經常發生，特別是對AUTOSAR新手來說。除此之外，ASTAS目前的檢查還分析了端口的更多屬性，而不僅僅是連接。

由于我們有兩個端口，一個具有require屬性，第二個端口具有provid屬性，ASTAS建議用戶用一個接口連接這兩個端口。為此，用戶可以選擇發送者-接收器和客戶端-服務器的通信原則。圖6顯示了程序員批準后進行的修正。在這種情況下，修正改變了系統描述，這是一個正式的標準化AUTOSAR配置文件。一個發送者-接收者接口已經創建，并被分配給兩個新的端口。之后，在集成的商業工具鏈中觸發RTE生成，以創建RTE端點。

圖 6.? 系統描述中對架構中斷開的端口的更正

圖7顯示了在AUTOSAR項目中通過采用自動修正建議所能實現的改進。左邊的條形圖代表了在引入建議的靜態分析之前的學生項目的CL。

圖 7.? 通過使用擬議的AUTOSAR特定靜態測試改善CL

右邊的條形圖顯示了運行靜態分析后的CL值。可以看出，在開發過程中，不同架構層的組合獲得了最大的改善。這一階段對學生來說往往是一個挑戰，因為它需要對整個標準有深刻的了解，包括其方法和異質的AUTOSAR工具鏈。

V.結論和未來的工作

本文提出的測試策略促進了AUTOSAR項目的發展。程序員可以通過AUTOSAR特定的靜態分析來支持配置和C代碼，而一般靜態分析工具只支持C代碼。靜態分析涵蓋了系統架構的所有架構層，并且獨立于正在使用的AUTOSAR版本和工具鏈。使用建議的方法，通過提高學生AUTOSAR項目的質量來改善應用程序的可重復使用性。此外，該靜態分析通過對AUTOSAR標準的解釋和參考，幫助學習者了解軟件質量的不同方面，這些問題在架構中都有顯示。因此，ASTAS的靜態分析是汽車軟件工程碩士研究課程中的一個重要教學部分，特別是從電子學習的角度來看。

在未來，希望將這一概念進一步發展到自我學習和自我評估的方向，其中個人統計變得更加重要。例如，我們通過直接向學習者展示一致性值和水平隨時間的變化來探索對學習者動機的影響。

參考文獻：

[1]? S. Mathur and S. Malik, “Advancements in the v-model,” International?Journal of Computer Applications, vol. 1, no. 12, 2010.

[2]? B. Hardung, T. K?lzow, and A. Krüger, “Reuse of software in distributed?embedded? automotive? systems,”? in? Proceedings? of? the? fourth? ACM international conference on Embedded software - EMSOFT '04.? ? ACM Press, 2004.

[3]? K. Juhnke, M. Tichy, and F. Houdek, “Challenges concerning test case?speci?cations in automotive? software testing: assessment of frequency and criticality,” Software Quality Journal, nov 2020.

[4]? N. Englisch, R. Bergelt,? and W. Hardt,? “An Educational Platform? for?Automotive Software Development and Test,” in 2020 IEEE 32nd Confer- ence on Software Engineering Education and Training (CSEE&T).? IEEE, nov 2020.

[5]? A. Leitner, R. Mader, C. Kreiner, C. Steger, and R. Weiss, “A development?methodology for variant-rich automotive software architectures,” e? &? i Elektrotechnik und Informationstechnik, vol. 128, pp. 222–227, 2011.

[6]? P. Louridas, “Static code analysis,” IEEE Software, vol. 23, no. 4, pp.58–61, jul 2006.

[7]? A. Imparato, R. R. Maietta, S. Scala, and V. Vacca, “A comparative study?of static analysis tools for AUTOSAR automotive software components development,” in 2017 IEEE International Symposium on Software Reli- ability Engineering Workshops (ISSREW).? ?IEEE, oct 2017.

[8]? I.? Gomes,? P.? Morgado,? T.? Gomes,? and? R.? Moreira,? “An? overview? on?the static code analysis approach insoftware development,” Faculdade de Engenharia da Universidade do Porto, Tech. Rep., 2009.

[9]? R.? van? Megen? and? D.? B.? Meyerhoff,? “Costs? and? bene?ts? of? early?defect? detection:? experiences? from? developing? client? server? and? host applications,” Software Quality Journal, vol. 4, pp. 247–256, dec 1995.

[10]? J. Westland, “The cost of errors in software development: evidence from?industry,” Journal of Systems and Software, vol. 62, pp. 1–9, 2002.

[11]? P. Vitharana, “Defect propagation at the project-level: results and a post-hoc analysis on inspection ef?ciency,” Empirical Software Engineering, vol. 22, no. 1, pp. 57–79, nov 2015.

[12]? M. Kulenovic and D. Donko, “A survey of static code analysis methods?for security vulnerabilities detection,” in 2014 37th International? Con- vention on Information and Communication Technology, Electronics and Microelectronics (MIPRO).? ?IEEE, may 2014.

[13]? M. Courrier, H. Clergeau, A. Calvy, P. Favrais, and M. Lecat, “Autosar

bsw? in? real? life:? A? summary? of? the? last? years? starting? and? putting projects into production,” in Embedded RealTime Software and Systems (ERTS2012), Toulouse, France, Feb. 2012.

[14]? N. Englisch, R. Mittag, F. H?nchen, O. Khan, A. Masrur, and W. Hardt,

“Ef?cient Static Testing of AUTOSAR Software supported by an auto- matically created Knowledge Base,” in Proceedings of the 7th Conference on Simulation and Testing for Vehicle Technology, May 2016, pp. 87–97.

[15]? H.? Venkitachalam,? K.? A.? Powale,? C.? Granrath,? and? J.? Richenhagen,

“Automated Continuous Evaluation of AUTOSAR Software Architecture for Complex Powertrain Systems,” in INFORMATIK 2017, 15. GI Work- shop Automotive? Software Engineering, M. Eibl and M. Gaedke, Eds. Gesellschaft für Informatik, Bonn, 2017, pp. 1563– 1574.

[16]? D. Diekhoff, “AUTOSAR Basic Software for Complex Control Units,” in

Proceedings of the Conference on Design, Automation and Test in Europe, ser. DATE ’10.? ?3001 Leuven, Belgium, Belgium: European Design and Automation Association, 2010, pp. 263–266.

[17]? N. Englisch, A. Heller, U. Tudevdagva, J. Tonndorf-Martini, L. Gaitzsch,

and? W.? Hardt,? “Adaptive? Learning? System? in? Automotive? Software Engineering,” in Proceedings? of? the? 27th International? Conference? on Software, Telecommunications and Computer Networks (SoftCOM), 2019.

[18]? N.? Englisch,? F.? H?nchen,? F.? Ullmann,? A.? Masrur,? and? W.? Hardt,

“Application-Driven Evaluation of AUTOSAR Basic Software on Modern ECUs,” in Proceedings of the 13th IEEE/IFIP International Conference on Embedded and Ubiquitous Computing (EUC), October 2015, pp. 60– 67.

[19]? N. Englisch, O. Khan, R. Mittag, F. H?nchen, A. Heller, and W. Hardt,

“YellowCar Automotive MultiECU Demonstrator Platform,” in 15.? GI Workshop Automotive Software Engineering, 2017, pp. 1517– 1522.

END

分享不易，懇請點個【??】和【在看】

登錄閱讀全文



免責聲明：該內容由專欄作者授權發布或作者轉載，目的在于傳遞更多信息，并不代表本網贊同其觀點，本站亦不保證或承諾內容真實性等。若內容或圖片侵犯您的權益，請及時聯系本站刪除。侵權投訴聯系：? nick.zong@aspencore.com！

智能汽車開發者平臺分享汽車最新前言技術解讀，行業分析，與授權行業資料分享平臺。

進入專欄

評論

智能汽車開發者平臺分享汽車最新前言技術解讀，行業分析，與授權行業資料分享平臺。

文章：1055篇粉絲：33人

 私信

面向教育汽車軟件工程的AUTOSAR靜態測試策略

最近文章

熱門文章

推薦

最新資訊