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

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

嵌入式計算設(shè)計：哪些因素導(dǎo)致汽車軟件開發(fā)項目日益復(fù)雜，在復(fù)雜的汽車供應(yīng)鏈中，誰最終負(fù)責(zé)確保軟件質(zhì)量？

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

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

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

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

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

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

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

圖 1. EB solys 的進(jìn)程間通信架構(gòu)。

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

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

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

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

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

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

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

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

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

作者：Torsten Mosis ，Sebastian K?nig

審核編輯：郭婷