作者 | 張旭海

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

一、智能座艙軟件性能和可靠性表現(xiàn)不佳

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

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

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

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

_（來源：車質(zhì)網(wǎng)）_進一步查閱具體投訴單，會發(fā)現(xiàn)包括死機、黑屏、卡頓、響應(yīng)慢等問題非常普遍，嚴(yán)重影響了用戶的駕乘體驗，也降低了用戶對品牌的信心和認(rèn)同。

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

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

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

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

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

智能座艙軟件系統(tǒng)本身是一種軟件，其研發(fā)過程也遵循軟件的架構(gòu)設(shè)計、開發(fā)落地和質(zhì)量驗證的常見流程。因此在討論如何改進之前，我們首先應(yīng)當(dāng)明確：如何正確評估軟件系統(tǒng)的性能和可靠性？

1. 軟件架構(gòu)特性模型

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

架構(gòu)師可能會與他人合作確定領(lǐng)域或業(yè)務(wù)需求，但架構(gòu)師的一個關(guān)鍵職責(zé)是定義、發(fā)現(xiàn)和分析軟件所必須的、與領(lǐng)域無關(guān)的事情：架構(gòu)特性。

架構(gòu)特性（Architecture Characteristics）是架構(gòu)師在設(shè)計軟件時需要考慮的與領(lǐng)域或業(yè)務(wù)需求無關(guān)的軟件特性，如可審計性、性能、安全性、可伸縮性、可靠性等等。在很多時候我們也會稱之為非功能性需求（Nonfunctional Requirements）或質(zhì)量屬性（Quality Attributes）。

顯然，對于關(guān)鍵的軟件架構(gòu)特性，需要在架構(gòu)設(shè)計之初就納入整體考量，并且在軟件研發(fā)的流程中持續(xù)進行關(guān)注。那么在研發(fā)軟件系統(tǒng)的時候，都有哪些關(guān)鍵架構(gòu)特性需要考慮呢？

ISO/IEC 25010:2011 是由國際標(biāo)準(zhǔn)化組織推行的一套標(biāo)準(zhǔn)（現(xiàn)已更新至 2023 版本），它隸屬于 ISO 系統(tǒng)與軟件質(zhì)量需求和評估（SQuaRE）體系，定義了一組系統(tǒng)和軟件質(zhì)量模型。該質(zhì)量模型被廣泛應(yīng)用于描述和評估軟件質(zhì)量，可以很好的指導(dǎo)我們對軟件關(guān)鍵架構(gòu)特征進行建模。

ISO 25010 描述的質(zhì)量模型如下（圖中著重標(biāo)明了與性能和可靠性相關(guān)的部分）：

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

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

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

2. 通過指標(biāo)體系評估架構(gòu)特性

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

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

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

在軟件行業(yè)，許多評估指標(biāo)都能夠跨業(yè)務(wù)領(lǐng)域達成共識，如響應(yīng)時間、吞吐量、RTO、RPO、MTTR 等等，企業(yè)在建立自己業(yè)務(wù)領(lǐng)域的指標(biāo)體系時可以直接采納。

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

當(dāng)然，由于功能領(lǐng)域和運行環(huán)境的不同，用于評估架構(gòu)特性的指標(biāo)體系勢必會存在一定的差異。

首先，不同的業(yè)務(wù)場景對評估指標(biāo)的權(quán)重設(shè)置會存在區(qū)別。例如對智能座艙系統(tǒng)和軟件的性能效率評估，由于關(guān)系到用戶駕乘體驗，時間特性至關(guān)重要，而對提供互聯(lián)網(wǎng)服務(wù)的 Web 應(yīng)用，為了向更多用戶提供服務(wù)，容量特性就是其需要關(guān)注的重點。

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

3. 尋找指標(biāo)元素的數(shù)據(jù)來源

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

同樣的，有非常多通用的指標(biāo)元素可以直接采納，例如圈復(fù)雜度，模塊耦合度，CPU 使用率，內(nèi)存使用率，事務(wù)執(zhí)行時間，并發(fā)度等等。但指標(biāo)元素相比指標(biāo)本身而言，與業(yè)務(wù)領(lǐng)域相關(guān)度更高，更需要結(jié)合領(lǐng)域知識來尋找合適的指標(biāo)元素。

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

本質(zhì)上 GQM 是通過樹形分析結(jié)構(gòu)，層層遞進。首先以如何實現(xiàn)目標(biāo)為前提，對目標(biāo)進行提問，之后將每個問題拆解為多個能支撐解決該問題的指標(biāo)元素，最后評選出最合適的指標(biāo)元素。

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

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

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

基于 GQM 方法，我們能夠?qū)Τ橄蟮闹笜?biāo)進行拆解，得到更為清晰的指標(biāo)計算公式和采集數(shù)據(jù)點，至此一個完整的評估框架就搭建完成了。

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

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

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

1. 架構(gòu)建模指導(dǎo)研發(fā)

建模是在設(shè)計階段對業(yè)務(wù)領(lǐng)域和架構(gòu)特征進行分析的有效實踐。許多組織在進行軟件架構(gòu)設(shè)計時，往往注重業(yè)務(wù)領(lǐng)域建模，輕視架構(gòu)特性建模，經(jīng)常會導(dǎo)致諸如安全性、可靠性、性能等的設(shè)計考量嚴(yán)重后置，等軟件發(fā)布之后再被生產(chǎn)問題倒逼改進。

事實上早期的架構(gòu)特性建模不僅可以指導(dǎo)后續(xù)研發(fā)過程中的代碼開發(fā)，也天然能轉(zhuǎn)化為白盒測試來驗證代碼是否符合設(shè)計要求。

對于性能建模，可以通過識別軟件架構(gòu)的性能關(guān)注點，以及預(yù)定義性能指標(biāo)來形成性能模型。關(guān)于性能建模，筆者曾在《什么是性能工程》中有過介紹。

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

（B/T 7826-2012）

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

2. 適應(yīng)度函數(shù)持續(xù)看護

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

一切可以被自動化的事情，都應(yīng)該被自動化。

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

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

ASPICE 是一個典型的案例，由于流程和文檔的復(fù)雜性，以及對每個研發(fā)階段的嚴(yán)格要求，導(dǎo)致設(shè)計和測試很容易停留在上一個較早的快照版本狀態(tài)，永遠(yuǎn)都跟不上軟件變化的速度。

（來源：An ASPICE Overview）

在 Neal Ford、Patrick Kua 和 Rebecca Parsons 合著的《演進式架構(gòu)》一書中，將適應(yīng)度函數(shù)定義為“用于總結(jié)預(yù)期設(shè)計的解決方案與實現(xiàn)設(shè)定目標(biāo)接近程度的目標(biāo)函數(shù)”。引出適應(yīng)度函數(shù)，就是要通過工程化的手段實現(xiàn)對架構(gòu)的評估也能自動化、常態(tài)化。

（來源：《演進式架構(gòu)》）

當(dāng)我們的指標(biāo)和模型被轉(zhuǎn)換為一個個適應(yīng)度函數(shù)，它們就能夠綁定在研發(fā)流水線上，從而實現(xiàn)對架構(gòu)特性的自動化評估。

有了自動化作為前提，接下來就可以采用架構(gòu)看護來驅(qū)動持續(xù)改進。

基于已經(jīng)建立的各類適應(yīng)度函數(shù)，在每日構(gòu)建、迭代測試以及集成測試等流程中，適應(yīng)度函數(shù)產(chǎn)生的執(zhí)行結(jié)果能夠形成一組完整的性能和可靠性評估報告。取上一版本的評估結(jié)果作為基線，與最新版本的評估結(jié)果進行對比，就能對軟件在性能和可靠性上的表現(xiàn)實現(xiàn)細(xì)致的看護，從而判斷新版本哪些部分進行了優(yōu)化，哪些部分發(fā)生了劣化，一目了然。

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

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

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

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

擁有了這樣的工具集之后，當(dāng)評估發(fā)現(xiàn)某些指標(biāo)出現(xiàn)劣化，就能基于一些基本信息迅速關(guān)聯(lián)出系統(tǒng)運行時的上下文和觀測記錄，從而快速分析和定位問題，快速實施優(yōu)化。

總結(jié)

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

本文主要從軟件研發(fā)和交付的角度，結(jié)合軟件領(lǐng)域的優(yōu)秀實踐和探索，討論了智能座艙軟件在性能和可靠性方面的持續(xù)評估方法和持續(xù)改進方法。

隨著越來越多的外部投資和跨領(lǐng)域人才涌入智能汽車領(lǐng)域，相信未來在相關(guān)產(chǎn)業(yè)中定能不斷地創(chuàng)造巨大的價值。