智能座舱软件性能与可靠性的评估和改进

随着智能汽车的不断发展，智能座舱在性能与可靠性上暴露出体验不佳、投诉渐多的问题，本文从工程化的角度简述了如何构建智能座舱软件的评估框架，以及如何持续改进其性能和可靠性。

1. 智能座舱软件性能和可靠性表现不佳

据毕马威发布的《2023智能座舱白皮书-聚焦电动化下半场》中的数据，中国汽车智能座舱市场规模呈逐年扩大之势，2022 到 2026 的 5 年复合增长率将超过 17%，预示着这一领域的蓬勃发展。随之而来的是智能座舱软件功能日益丰富，整体智能化程度显著提升。

_（来源：《2023智能座舱白皮书-聚焦电动化下半场》）_

在市场规模预测逐年扩大的同时，消费者对智能座舱软件的相关投诉占比也愈发显著。这主要聚焦在智能座舱软件的操作体验度、性能和可靠性方面，揭示出智能化功能不断增加所带来的挑战。

根据车质网 2023 年四个季度的汽车投诉分析报告汇总，智能座舱（车机）涉及的质量问题占比显著，其中 Q1~Q4 的投诉故障点 TOP20 中与车机相关的部分（影音系统故障，导航问题，车载互联故障，行车安全辅助系统故障等）分别占据总投诉的 15.89%，10.99%，10.56% 和 9.56%。

_（来源：车质网）_

进一步查阅具体投诉单，会发现包括死机、黑屏、卡顿、响应慢等问题非常普遍，严重影响了用户的驾乘体验，也降低了用户对品牌的信心和认同。

结合智能座舱软件的发展趋势和用户投诉问题后，可以发现性能和可靠性是除了操作易用性以外，最为关键的使用体验影响因素。这两个关键因素不仅直接关系到用户的满意度，也在很大程度上决定了智能座舱软件在市场中的竞争力。

性能的提升是确保智能座舱软件流畅运行的基石。随着功能的不断增加，软件需要更高效的处理器和优化的算法，以保证用户操作的即时响应和系统的高度流畅性。
可靠性是确保用户在各种使用场景下都能够信赖智能座舱软件的关键。用户期望在驾驶过程中不会受到智能座舱软件故障产生的干扰，系统最好稳定运行，避免出现崩溃或死机等问题。

后文我们将结合软件研发的最佳实践和智能座舱领域软件的自身特点，探讨评估和改进其性能和可靠性的方法。

2. 性能和可靠性的评估框架

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

智能座舱软件系统本身是一种软件，其研发过程也遵循软件的架构设计、开发落地和质量验证的常见流程。因此在讨论如何改进之前，我们首先应当明确：如何正确评估软件系统的性能和可靠性？

2.1. 软件架构特性模型

Mark Richards 和 Neal Ford 在《软件架构：架构模式、特征及实践指南》中曾这样描述 “架构特性”：

架构师可能会与他人合作确定领域或业务需求，但架构师的一个关键职责是定义、发现和分析软件所必须的、与领域无关的事情：架构特性。

架构特性（Architecture Characteristics）是架构师在设计软件时需要考虑的与领域或业务需求无关的软件特性，如可审计性、性能、安全性、可伸缩性、可靠性等等。在很多时候我们也会称之为非功能性需求（Nonfunctional Requirements）或质量属性（Quality Attributes）。

显然，对于关键的软件架构特性，需要在架构设计之初就纳入整体考量，并且在软件研发的流程中持续进行关注。那么在研发软件系统的时候，都有哪些关键架构特性需要考虑呢？

ISO/IEC 25010:2011 是由国际标准化组织推行的一套标准（现已更新至 2023 版本），它隶属于 ISO 系统与软件质量需求和评估（SQuaRE）体系，定义了一组系统和软件质量模型。该质量模型被广泛应用于描述和评估软件质量，可以很好的指导我们对软件关键架构特征进行建模。

ISO 25010 描述的质量模型如下（图中着重标明了与性能和可靠性相关的部分）：

ISO 25010 对软件架构特性（标准原文中称为“质量属性”）进行了划分，涵盖了众多方面，如功能性、可靠性、性能效率、可维护性、可移植性等。每个架构特性都定义了与之相关的关键方面，特性下还包括多个子特性，更细致地描述了特性的具体维度。可见该质量模型提供了一个全面且通用的框架，以便更好地理解和评估软件的质量。

对于性能特性，该模型划分了三种子特性：时间特性，资源利用性，容量；而对于可靠性特性，模型划分了四种子特性：成熟性，可用性，容错性和易恢复性。

当然，任何一种软件都有其自身的特点和运行环境，能够满足上述模型中所有架构特性的软件固然优秀，但成本势必高昂，正如对于一套只有 3 个用户的内部系统，设计弹性伸缩来满足可用性是毫无必要的。显然在智能座舱软件的领域，以用户体验来评估性能和可靠性特性，比用吞吐量和弹性伸缩比来评估更符合智能座舱软件的设计目标。

2.2. 通过指标体系评估架构特性

分析前面的软件质量模型，我们会发现该模型主要定义了软件的架构特性“应当表现为什么样子”，但没有讲明“需要怎么评估”才能判断已经达成了架构特性的要求。质量模型中的特性和子特性是对架构特性的定性描述，而如何对架构特性进行定量评估未能提及。

事实上，SQuaRE 也提供了对质量模型的评估框架（详见 ISO/IEC 25020:2019）：

以上评估框架本质上就是采用一组权重不同的指标集来评估一项架构特性（子特性），指标可以由一些指标元素计算得出，而指标元素可通过一些实施在软件研发活动中的测量方法测量而得。

在软件行业，许多评估指标都能够跨业务领域达成共识，如响应时间、吞吐量、RTO、RPO、MTTR 等等，企业在建立自己业务领域的指标体系时可以直接采纳。

如下就是一些相对通用的软件性能和可靠性指标示例，这些指标对绝大多数的软件都适用：

当然，由于功能领域和运行环境的不同，用于评估架构特性的指标体系势必会存在一定的差异。

首先，不同的业务场景对评估指标的权重设置会存在区别。例如对智能座舱系统和软件的性能效率评估，由于关系到用户驾乘体验，时间特性至关重要，而对提供互联网服务的 Web 应用，为了向更多用户提供服务，容量特性就是其需要关注的重点。

其次，特定的领域会有其独特的性能指标。这些差异性指标需要从实际业务中提炼。例如 UI 界面流畅度无法简单的用响应时间来评估，而是需要通过帧率、丢帧数等指标来综合判断。

2.3 寻找指标元素的数据来源

在建立了指标体系之后，接下来面临的问题就是如何寻找合理的指标元素来计算指标值。

同样的，有非常多通用的指标元素可以直接采纳，例如圈复杂度，模块耦合度，CPU 使用率，内存使用率，事务执行时间，并发度等等。但指标元素相比指标本身而言，与业务领域相关度更高，更需要结合领域知识来寻找合适的指标元素。

GQM 方法是一种有效的寻找和建立指标元素的分析法：GQM 即“Goal - Question - Metrics”，可译为“目标 - 问题 - 指标” ，是一种历史悠久的分析方法，由 Victor Basili 和 David Weiss 在 1984 年提出。

本质上 GQM 是通过树形分析结构，层层递进。首先以如何实现目标为前提，对目标进行提问，之后将每个问题拆解为多个能支撑解决该问题的指标元素，最后评选出最合适的指标元素。

如下我们以“帮助寻找智能座舱软件的性能和可靠性特征的评估指标元素”为例，分别基于“评估智能座舱主屏操作流畅度”和“计算智能座舱系统与应用的故障率和可用性”为目标，建立 GQM 分析树：

在分析之初，为了扩展思路，可以先不考虑指标元素的价值和获取难度，尽可能多的识别可能的指标元素，之后再分析每一个指标元素的价值和获取的难易程度，并据此对其进行优先级排序，筛选最适合的指标元素。这一过程可遵循如下优先级原则：

能支撑越多问题越靠前
越容易收集和计算越靠前

基于 GQM 方法，我们能够对抽象的指标进行拆解，得到更为清晰的指标计算公式和采集数据点，至此一个完整的评估框架就搭建完成了。

3. 持续改进性能和可靠性的工程化方法

基于前文引入的评估框架，我们已经掌握了一定的分析方法，明确了改善智能座舱软件性能和可靠性的方向。评估的下一步就是改进，本节将要讨论如何以工程化的方法，对智能座舱软件的性能和可靠性架构特性进行持续改进，从而确保随着软件的迭代，其性能和可靠性不仅不会劣化，而是会长期、稳步地提升。

3.1 架构建模指导研发

建模是在设计阶段对业务领域和架构特征进行分析的有效实践。许多组织在进行软件架构设计时，往往注重业务领域建模，轻视架构特性建模，经常会导致诸如安全性、可靠性、性能等的设计考量严重后置，等软件发布之后再被生产问题倒逼改进。

事实上早期的架构特性建模不仅可以指导后续研发过程中的代码开发，也天然能转化为白盒测试来验证代码是否符合设计要求。

对于性能建模，可以通过识别软件架构的性能关注点，以及预定义性能指标来形成性能模型。关于性能建模，笔者曾在《什么是性能工程》中有过介绍。

对于可靠性建模，得益于汽车生产制造领域已有很多成熟的建模方法，软件领域也可直接参考和剪裁。故障树分析（FTA）、故障模式和影响分析（FMEA）等建模方法。

_（来源：描述 FMEA 程序的国家标准 G）_

_（B/T 7826-2012）_

为了避免建立的模型只在架构评审会议上有效，而实际落地的时候完全没有遵循架构设计，很有必要基于模型构建对应的适应度函数，以确保架构不会慢慢腐化，下一小节将介绍架构适应度函数。

3.2 适应度函数持续看护

有了指标体系，我们可以定量的对智能座舱软件的性能和可靠性进行分析和评估。然而，如果评估的过程过于复杂、冗长且难以快速进行，那么随着时间的推移，对这些架构特性的评估就会成为团队沉重的负担，这意味着评估活动的次数会越来越少，反馈越来越慢，难以持续，最终停滞下来。

一切可以被自动化的事情，都应该被自动化。

在评估软件功能是否满足要求时，我们会构建大量的自动化测试，这样就能形成一张软件特性安全网，持续的保障软件符合要求。而对于架构特性的评估，传统的做法更像是 “运动式” 评估：

在研发侧，定期拉起专门的性能或可靠性测试团队，手握指标体系，从黑盒角度测试并评估是否满足指标要求，产出测试报告；
在设计侧，定期安排各类架构讨论会、评审会来评估设计本身以及软件是否正确的按设计落地，产出大量文档。

ASPICE 是一个典型的案例，由于流程和文档的复杂性，以及对每个研发阶段的严格要求，导致设计和测试很容易停留在上一个较早的快照版本状态，永远都跟不上软件变化的速度。

_（来源：An ASPICE Overview）_

在 Neal Ford、Patrick Kua 和 Rebecca Parsons 合著的《演进式架构》一书中，将适应度函数定义为“用于总结预期设计的解决方案与实现设定目标接近程度的目标函数”。引出适应度函数，就是要通过工程化的手段实现对架构的评估也能自动化、常态化。

_（来源：《演进式架构》）_

当我们的指标和模型被转换为一个个适应度函数，它们就能够绑定在研发流水线上，从而实现对架构特性的自动化评估。有了自动化作为前提，接下来就可以采用架构看护来驱动持续改进。基于已经建立的各类适应度函数，在每日构建、迭代测试以及集成测试等流程中，适应度函数产生的执行结果能够形成一组完整的性能和可靠性评估报告。取上一版本的评估结果作为基线，与最新版本的评估结果进行对比，就能对软件在性能和可靠性上的表现实现细致的看护，从而判断新版本哪些部分进行了优化，哪些部分发生了劣化，一目了然。

3.3 可观测工具集帮助分析

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

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

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

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

总结

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

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

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

参考文献