作者 | 張旭海

隨著智能汽車的不斷發展，智能座艙在性能與可靠性上暴露出體驗不佳、投訴漸多的問題，本文從工程化的角度簡述了如何構建智能座艙軟件的評估框架，以及如何持續改進其性能和可靠性。

一、智能座艙軟件性能和可靠性表現不佳

據畢馬威發布的《2023智能座艙白皮書-聚焦電動化下半場》中的數據，中國汽車智能座艙市場規模呈逐年擴大之勢，2022 到 2026 的 5 年復合增長率將超過 17%，預示著這一領域的蓬勃發展。隨之而來的是智能座艙軟件功能日益豐富，整體智能化程度顯著提升。

（來源：《2023智能座艙白皮書-聚焦電動化下半場》）

在市場規模預測逐年擴大的同時，消費者對智能座艙軟件的相關投訴占比也愈發顯著。這主要聚焦在智能座艙軟件的操作體驗度、性能和可靠性方面，揭示出智能化功能不斷增加所帶來的挑戰。

根據車質網 2023 年四個季度的汽車投訴分析報告匯總，智能座艙（車機）涉及的質量問題占比顯著，其中 Q1~Q4 的投訴故障點 TOP20 中與車機相關的部分（影音系統故障，導航問題，車載互聯故障，行車安全輔助系統故障等）分別占據總投訴的 15.89%，10.99%，10.56% 和 9.56%。

_（來源：車質網）_進一步查閱具體投訴單，會發現包括死機、黑屏、卡頓、響應慢等問題非常普遍，嚴重影響了用戶的駕乘體驗，也降低了用戶對品牌的信心和認同。

結合智能座艙軟件的發展趨勢和用戶投訴問題后，可以發現性能和可靠性是除了操作易用性以外，最為關鍵的使用體驗影響因素。這兩個關鍵因素不僅直接關系到用戶的滿意度，也在很大程度上決定了智能座艙軟件在市場中的競爭力。

• 性能的提升是確保智能座艙軟件流暢運行的基石。隨著功能的不斷增加，軟件需要更高效的處理器和優化的算法，以保證用戶操作的即時響應和系統的高度流暢性。
• 可靠性是確保用戶在各種使用場景下都能夠信賴智能座艙軟件的關鍵。用戶期望在駕駛過程中不會受到智能座艙軟件故障產生的干擾，系統最好穩定運行，避免出現崩潰或死機等問題。

后文我們將結合軟件研發的最佳實踐和智能座艙領域軟件的自身特點，探討評估和改進其性能和可靠性的方法。

二、性能和可靠性的評估框架

If you can't measure it, you can't improve it.

智能座艙軟件系統本身是一種軟件，其研發過程也遵循軟件的架構設計、開發落地和質量驗證的常見流程。因此在討論如何改進之前，我們首先應當明確：如何正確評估軟件系統的性能和可靠性？

1. 軟件架構特性模型

Mark Richards 和 Neal Ford 在《軟件架構：架構模式、特征及實踐指南》中曾這樣描述 “架構特性”：

架構師可能會與他人合作確定領域或業務需求，但架構師的一個關鍵職責是定義、發現和分析軟件所必須的、與領域無關的事情：架構特性。

架構特性（Architecture Characteristics）是架構師在設計軟件時需要考慮的與領域或業務需求無關的軟件特性，如可審計性、性能、安全性、可伸縮性、可靠性等等。在很多時候我們也會稱之為非功能性需求（Nonfunctional Requirements）或質量屬性（Quality Attributes）。

顯然，對于關鍵的軟件架構特性，需要在架構設計之初就納入整體考量，并且在軟件研發的流程中持續進行關注。那么在研發軟件系統的時候，都有哪些關鍵架構特性需要考慮呢？

ISO/IEC 25010:2011 是由國際標準化組織推行的一套標準（現已更新至 2023 版本），它隸屬于 ISO 系統與軟件質量需求和評估（SQuaRE）體系，定義了一組系統和軟件質量模型。該質量模型被廣泛應用于描述和評估軟件質量，可以很好的指導我們對軟件關鍵架構特征進行建模。

ISO 25010 描述的質量模型如下（圖中著重標明了與性能和可靠性相關的部分）：

ISO 25010 對軟件架構特性（標準原文中稱為“質量屬性”）進行了劃分，涵蓋了眾多方面，如功能性、可靠性、性能效率、可維護性、可移植性等。每個架構特性都定義了與之相關的關鍵方面，特性下還包括多個子特性，更細致地描述了特性的具體維度。可見該質量模型提供了一個全面且通用的框架，以便更好地理解和評估軟件的質量。

對于性能特性，該模型劃分了三種子特性：時間特性，資源利用性，容量；而對于可靠性特性，模型劃分了四種子特性：成熟性，可用性，容錯性和易恢復性。

當然，任何一種軟件都有其自身的特點和運行環境，能夠滿足上述模型中所有架構特性的軟件固然優秀，但成本勢必高昂，正如對于一套只有 3 個用戶的內部系統，設計彈性伸縮來滿足可用性是毫無必要的。顯然在智能座艙軟件的領域，以用戶體驗來評估性能和可靠性特性，比用吞吐量和彈性伸縮比來評估更符合智能座艙軟件的設計目標。

2. 通過指標體系評估架構特性

分析前面的軟件質量模型，我們會發現該模型主要定義了軟件的架構特性“應當表現為什么樣子”，但沒有講明“需要怎么評估”才能判斷已經達成了架構特性的要求。質量模型中的特性和子特性是對架構特性的定性描述，而如何對架構特性進行定量評估未能提及。

事實上，SQuaRE 也提供了對質量模型的評估框架（詳見 ISO/IEC 25020:2019）：

以上評估框架本質上就是采用一組權重不同的指標集來評估一項架構特性（子特性），指標可以由一些指標元素計算得出，而指標元素可通過一些實施在軟件研發活動中的測量方法測量而得。

在軟件行業，許多評估指標都能夠跨業務領域達成共識，如響應時間、吞吐量、RTO、RPO、MTTR 等等，企業在建立自己業務領域的指標體系時可以直接采納。

如下就是一些相對通用的軟件性能和可靠性指標示例，這些指標對絕大多數的軟件都適用：

當然，由于功能領域和運行環境的不同，用于評估架構特性的指標體系勢必會存在一定的差異。

首先，不同的業務場景對評估指標的權重設置會存在區別。例如對智能座艙系統和軟件的性能效率評估，由于關系到用戶駕乘體驗，時間特性至關重要，而對提供互聯網服務的 Web 應用，為了向更多用戶提供服務，容量特性就是其需要關注的重點。

其次，特定的領域會有其獨特的性能指標。這些差異性指標需要從實際業務中提煉。例如 UI 界面流暢度無法簡單的用響應時間來評估，而是需要通過幀率、丟幀數等指標來綜合判斷。

3. 尋找指標元素的數據來源

在建立了指標體系之后，接下來面臨的問題就是如何尋找合理的指標元素來計算指標值。

同樣的，有非常多通用的指標元素可以直接采納，例如圈復雜度，模塊耦合度，CPU 使用率，內存使用率，事務執行時間，并發度等等。但指標元素相比指標本身而言，與業務領域相關度更高，更需要結合領域知識來尋找合適的指標元素。

GQM 方法是一種有效的尋找和建立指標元素的分析法：GQM 即“Goal - Question - Metrics”，可譯為“目標 - 問題 - 指標” ，是一種歷史悠久的分析方法，由 Victor Basili 和 David Weiss 在 1984 年提出。

本質上 GQM 是通過樹形分析結構，層層遞進。首先以如何實現目標為前提，對目標進行提問，之后將每個問題拆解為多個能支撐解決該問題的指標元素，最后評選出最合適的指標元素。

如下我們以“幫助尋找智能座艙軟件的性能和可靠性特征的評估指標元素”為例，分別基于“評估智能座艙主屏操作流暢度”和“計算智能座艙系統與應用的故障率和可用性”為目標，建立 GQM 分析樹：

在分析之初，為了擴展思路，可以先不考慮指標元素的價值和獲取難度，盡可能多的識別可能的指標元素，之后再分析每一個指標元素的價值和獲取的難易程度，并據此對其進行優先級排序，篩選最適合的指標元素。這一過程可遵循如下優先級原則：

• 能支撐越多問題越靠前
• 越容易收集和計算越靠前

基于 GQM 方法，我們能夠對抽象的指標進行拆解，得到更為清晰的指標計算公式和采集數據點，至此一個完整的評估框架就搭建完成了。

三、持續改進性能和可靠性的工程化方法

基于前文引入的評估框架，我們已經掌握了一定的分析方法，明確了改善智能座艙軟件性能和可靠性的方向。

評估的下一步就是改進，本節將要討論如何以工程化的方法，對智能座艙軟件的性能和可靠性架構特性進行持續改進，從而確保隨著軟件的迭代，其性能和可靠性不僅不會劣化，而是會長期、穩步地提升。

1. 架構建模指導研發

建模是在設計階段對業務領域和架構特征進行分析的有效實踐。許多組織在進行軟件架構設計時，往往注重業務領域建模，輕視架構特性建模，經常會導致諸如安全性、可靠性、性能等的設計考量嚴重后置，等軟件發布之后再被生產問題倒逼改進。

事實上早期的架構特性建模不僅可以指導后續研發過程中的代碼開發，也天然能轉化為白盒測試來驗證代碼是否符合設計要求。

對于性能建模，可以通過識別軟件架構的性能關注點，以及預定義性能指標來形成性能模型。關于性能建模，筆者曾在《什么是性能工程》中有過介紹。

對于可靠性建模，得益于汽車生產制造領域已有很多成熟的建模方法，軟件領域也可直接參考和剪裁。故障樹分析（FTA）、故障模式和影響分析（FMEA）等建模方法。_（來源：描述 FMEA 程序的國家標準 G）_

（B/T 7826-2012）

為了避免建立的模型只在架構評審會議上有效，而實際落地的時候完全沒有遵循架構設計，很有必要基于模型構建對應的適應度函數，以確保架構不會慢慢腐化，下一小節將介紹架構適應度函數。

2. 適應度函數持續看護

有了指標體系，我們可以定量的對智能座艙軟件的性能和可靠性進行分析和評估。然而，如果評估的過程過于復雜、冗長且難以快速進行，那么隨著時間的推移，對這些架構特性的評估就會成為團隊沉重的負擔，這意味著評估活動的次數會越來越少，反饋越來越慢，難以持續，最終停滯下來。

一切可以被自動化的事情，都應該被自動化。

在評估軟件功能是否滿足要求時，我們會構建大量的自動化測試，這樣就能形成一張軟件特性安全網，持續的保障軟件符合要求。而對于架構特性的評估，傳統的做法更像是 “運動式” 評估：

• 在研發側，定期拉起專門的性能或可靠性測試團隊，手握指標體系，從黑盒角度測試并評估是否滿足指標要求，產出測試報告；
• 在設計側，定期安排各類架構討論會、評審會來評估設計本身以及軟件是否正確的按設計落地，產出大量文檔。

ASPICE 是一個典型的案例，由于流程和文檔的復雜性，以及對每個研發階段的嚴格要求，導致設計和測試很容易停留在上一個較早的快照版本狀態，永遠都跟不上軟件變化的速度。

（來源：An ASPICE Overview）

在 Neal Ford、Patrick Kua 和 Rebecca Parsons 合著的《演進式架構》一書中，將適應度函數定義為“用于總結預期設計的解決方案與實現設定目標接近程度的目標函數”。引出適應度函數，就是要通過工程化的手段實現對架構的評估也能自動化、常態化。

（來源：《演進式架構》）

當我們的指標和模型被轉換為一個個適應度函數，它們就能夠綁定在研發流水線上，從而實現對架構特性的自動化評估。

有了自動化作為前提，接下來就可以采用架構看護來驅動持續改進。

基于已經建立的各類適應度函數，在每日構建、迭代測試以及集成測試等流程中，適應度函數產生的執行結果能夠形成一組完整的性能和可靠性評估報告。取上一版本的評估結果作為基線，與最新版本的評估結果進行對比，就能對軟件在性能和可靠性上的表現實現細致的看護，從而判斷新版本哪些部分進行了優化，哪些部分發生了劣化，一目了然。

3. 可觀測工具集幫助分析

至此我們已經擁有了一些手段來支持持續的性能和可靠性評估，但評估本質上是為了暴露問題，之后的分析和優化才是持續改進的難點。

暴露了問題之后，往往需要以最快的速度開展優化，而對于業務型組織而言，團隊絕大多數時間都在業務領域工作，對性能和可靠性一類的問題分析和優化能力不足，通常此時組織就會尋找或聘請技術專家來幫助改進。但技術專家作為稀缺資源，面對多種多樣的問題，往往捉襟見肘。

因此，期望實現持續改進的組織，建立工程化的分析和優化手段來提升效率必不可少，這里首當其中的就是構建可觀測工具集。在前面提到的評估框架中，指標的作用主要是為了指示當前狀態如何，指標可以評估優劣，但不能幫助分析問題根因。分析軟件問題需要能復現系統運行時發生了什么，組件是如何交互的，產生了哪些數據，而這些信息都需要通過可觀測工具來抓取和記錄。

擁有了這樣的工具集之后，當評估發現某些指標出現劣化，就能基于一些基本信息迅速關聯出系統運行時的上下文和觀測記錄，從而快速分析和定位問題，快速實施優化。

總結

智能汽車市場前景廣闊，發展迅速，隨著競爭的深入，智能座艙的極致體驗一定會成為各汽車廠商的一大目標。

本文主要從軟件研發和交付的角度，結合軟件領域的優秀實踐和探索，討論了智能座艙軟件在性能和可靠性方面的持續評估方法和持續改進方法。

隨著越來越多的外部投資和跨領域人才涌入智能汽車領域，相信未來在相關產業中定能不斷地創造巨大的價值。