智慧座艙軟體效能與可靠性的評估與改進

作者 | 张旭海

随着智能汽车的迅速发展，智能座舱在性能和可靠性方面出现了一些问题，用户体验不佳，投诉也逐渐增加。本文从工程化的角度简要讨论了构建智能座舱软件评估框架的重要性，以及持续改进性能和可靠性的方法。

一、智能座舱软件性能和可靠性表现不佳

根据毕马威发布的《2023智能座舱白皮书-聚焦电动化下半场》，中国汽车智能座舱市场规模不断扩大，2022年至2026年的年复合增长率预计将超过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. 可观测工具集帮助分析

至此我们已经拥有了一些手段来支持持续的性能和可靠性评估，但评估本质上是为了暴露问题，之后的分析和优化才是持续改进的难点。

暴露了问题之后，往往需要以最快的速度开展优化，而对于业务型组织而言，团队绝大多数时间都在业务领域工作，对性能和可靠性一类的问题分析和优化能力不足，通常此时组织就会寻找或聘请技术专家来帮助改进。但技术专家作为稀缺资源，面对多种多样的问题，往往捉襟见肘。

因此，期望实现持续改进的组织，建立工程化的分析和优化手段来提升效率必不可少，这里首当其中的就是构建可观测工具集。在前面提到的评估框架中，指标的作用主要是为了指示当前状态如何，指标可以评估优劣，但不能帮助分析问题根因。分析软件问题需要能复现系统运行时发生了什么，组件是如何交互的，产生了哪些数据，而这些信息都需要通过可观测工具来抓取和记录。

拥有了这样的工具集之后，当评估发现某些指标出现劣化，就能基于一些基本信息迅速关联出系统运行时的上下文和观测记录，从而快速分析和定位问题，快速实施优化。

总结

智能汽车市场前景广阔，发展迅速，随着竞争的深入，智能座舱的极致体验一定会成为各汽车厂商的一大目标。

本文主要从软件研发和交付的角度，结合软件领域的优秀实践和探索，讨论了智能座舱软件在性能和可靠性方面的持续评估方法和持续改进方法。

随着越来越多的外部投资和跨领域人才涌入智能汽车领域，相信未来在相关产业中定能不断地创造巨大的价值。

以上是智慧座艙軟體效能與可靠性的評估與改進的詳細內容。更多資訊請關注PHP中文網其他相關文章！