汽車行業(yè)的當前趨勢意味著開發(fā)軟件項目已成為一項日益復雜的任務。軟件團隊和項目經理需要在復雜和異構的軟件系統(tǒng)中使用專門的錯誤搜索和流程優(yōu)化框架。

在這次與 Elektrobit Automotive 的Torsten Mosis 和 Sebastian K?nig 的問答 中，兩人討論了在復雜的汽車軟件供應鏈中在破壞開發(fā)項目之前檢測出代價高昂的錯誤的機制。

嵌入式計算設計：哪些因素導致汽車軟件開發(fā)項目日益復雜，在復雜的汽車供應鏈中，誰最終負責確保軟件質量？

K?nig： 如今，主機中已經可以找到廣泛的軟件技術。它們通?；?HTML5、Java 或 Qt 等標準系統(tǒng)，其下層的應用程序和服務利用了已建立的框架（如 Android、QNX Car Platform 或 GENIVI Linux）的優(yōu)勢。

在此期間，用戶可以體驗的功能由智能手機應用程序和Android Auto或Apple CarPlay等鏡像方法的集成來補充。除此之外，還有大量數(shù)據從車輛到云端的遷移和處理。市場發(fā)展表明，在未來，分布在不同硬件實體上或在虛擬機管理程序上運行在虛擬化環(huán)境中的幾種不同操作系統(tǒng)通常會同時運行。在這里，導航系統(tǒng)等復雜功能通常會滲透到所有軟件和硬件層。

雖然基本集成通常由 OEM 自己完成，但幾個供應商通常會在不同程度上對整體功能做出貢獻。因此，對于開發(fā)人員和程序員來說，為了測試和保證整個軟件系統(tǒng)的質量和穩(wěn)健性，需要進行重大的協(xié)調工作。除了久經考驗的標準系統(tǒng)和技術外，還需要考慮許多專有擴展。

嵌入式計算設計：在軟件開發(fā)生命周期早期發(fā)現(xiàn)的錯誤遠低于在生產后期發(fā)現(xiàn)的錯誤。開發(fā)人員可以使用哪些機制來簡化錯誤檢測，以免對生產產生負面影響？

摩西：某些軟件開發(fā)工具使工程師能夠在早期開發(fā)階段識別和定位功能性和非功能性錯誤。涉及導航系統(tǒng)開發(fā)的日常項目工作中的一個典型示例是，經常過早或過晚宣布關閉機動的語言指令。這方面的潛在錯誤來源差異很大，并且通常只能在某些情況下重現(xiàn)。通常，錯誤的原因不在于單個軟件模塊本身，而在于模塊之間的交互，因為它們的接口經常被錯誤地使用，例如以錯誤的順序、錯誤的值或錯誤的時間點。 糾正這種類型的錯誤是昂貴的，因為通常，

例如，EB solys 是一種用于高度復雜的汽車開發(fā)項目的工具，不僅支持單個組件的錯誤搜索和流程優(yōu)化，而且支持整個系統(tǒng)結構的更高級別。 這里的重點是收集、聚合和關聯(lián)正在研究的軟件系統(tǒng)的數(shù)據和操作狀態(tài)。通常，只有在不同來源的數(shù)據相互關聯(lián)時才能檢測到錯誤和異常。為了收集數(shù)據，將在要監(jiān)控的系統(tǒng)上安裝一個目標代理，Elektrobit 將作為開源軟件提供該代理。在這里，對目標系統(tǒng)的監(jiān)控是被動的。該分析觀察正在進行的數(shù)據處理和進程間通信，并且不僅基于對檢測源代碼的訪問。

目標代理支持插件架構，以便能夠訪問目標系統(tǒng)上的特定進程間通信或開發(fā)人員跟蹤（圖 1）。相比之下，數(shù)據在運行在 Windows PC 上的主機系統(tǒng)上進行聚合和關聯(lián)。以與目標代理類似的方式，主機系統(tǒng)的體系結構也被設計為使其自身易于適應，例如，適應特定的數(shù)據格式和不同的進程間通信過程。單獨調整的導入器可以從所需的任何日志文件向核心系統(tǒng)提供數(shù)據，以便將特定數(shù)據內容（例如二進制跟蹤）轉換為結構文本格式。

圖 1. EB solys 的進程間通信架構。

許多細節(jié)功能源于 Elektrobit 的開發(fā)實踐，從而滿足程序員、集成商和系統(tǒng)開發(fā)人員的特定需求。例如，可視化數(shù)據始終以不同的方式保持相互關聯(lián) - 例如，如果用戶在圖形圖像中設置標記，則該標記也會自動采用并顯示在所有鏈接的圖表和表格中。根據需要，分析和描述可以在比功能或流程更高的抽象層次上進行，也可以在接口、服務或對象等較低層次上進行。（圖2）

圖 2.不同的抽象級別可以分析 EB solys 中的特定功能、流程和服務。

目前，該代理可用于 Linux、QNX、Android 和 Windows Embedded 目標系統(tǒng)，隨后還會有其他系統(tǒng)。

嵌入式計算設計：自動化監(jiān)控和驗證怎么樣？鑒于車輛中越來越多的軟件，這對于系統(tǒng)分析和錯誤發(fā)現(xiàn)似乎至關重要。

K?nig： 通常，在后期開發(fā)階段，系統(tǒng)分析和錯誤搜索之后是對關鍵 KPI 和流程的持續(xù)監(jiān)控和驗證。為此，“EB solys Auto”版本支持批處理模式操作，使其功能能夠集成到自動化測試環(huán)境中。這些還包括記錄和可視化 KPI 的方法，例如系統(tǒng)資源的使用、各個部分系統(tǒng)和熱點的性能以及組件和流程之間的通信。

通過這種方式，開發(fā)人員可以評估系統(tǒng)的健康和穩(wěn)定性，例如，測試是否滿足某些規(guī)范和開發(fā)標準，監(jiān)控性能指標并檢測趨勢，以便及早定義度量。結果，開發(fā)過程得到了改進，特別是在分散的開發(fā)團隊中。項目經理可以及早給他們的團隊反饋并確定有針對性的措施，以提高質量和穩(wěn)定性。

基于為 Java 設計的 Xtend 編程語言的內置腳本語言可實現(xiàn)功能擴展，而無需適應主機系統(tǒng)或目標代理的源代碼?？梢酝ㄟ^編程接口訪問腳本和收集的數(shù)據并生成新的操作元素。此外，腳本 API 還提供了在 Auto 版本中記錄和存儲 KPI 的方法。為了在更長的時間內顯示 KPI，EB solys 使用了 InfluxDB（作為指標數(shù)據庫）和 Grafana（作為儀表板）的技術配對接口。

作為主要針對汽車行業(yè)的開發(fā)工具，EB solys 還支持日志數(shù)據與地理數(shù)據的關聯(lián)。例如，這允許它結合地圖顯示顯示系統(tǒng)事件，如果需要，還可以記錄攝像機圖像。

盡管它明顯植根于汽車市場，但開放式架構通常也允許它適應其他市場或開發(fā)環(huán)境。

作者：Torsten Mosis ，Sebastian K?nig

審核編輯：郭婷