智能座舱系统可靠性发展

智能座舱软件系统可靠性发展涵盖了以下几个关键方面：

1 信息安全

数据保护：确保乘客和车辆数据的安全，防止未授权的访问和数据泄露。

加密技术：使用强加密算法来保护传输和存储的数据，防止信息被截获和篡改。

访问控制：实施严格的用户身份验证和权限管理，确保只有授权用户才能访问系统。

漏洞管理：定期更新软件以修复安全漏洞，防止黑客利用这些漏洞进行攻击。

2 功能安全

故障检测：实时监测系统状态，快速识别潜在故障。

故障响应：在检测到故障时，系统能够采取适当的措施，如切换到备用系统或安全模式。

冗余设计：通过冗余的硬件和软件组件来提高系统的可靠性，确保关键功能在单个组件故障时仍能运作。

合规性：遵循国际标准，如ISO 26262，确保软件开发过程和产品符合功能安全要求。

3 性能

响应时间：确保座舱软件对用户输入的响应时间迅速且一致。

处理能力：软件应高效利用硬件资源，提供流畅的用户体验。

资源管理：合理分配计算和存储资源，避免资源过度使用导致的性能下降。

4 稳定性

长期运行：软件应能在车辆整个使用周期内稳定运行，无频繁崩溃或死机现象。

环境适应性：软件应能在不同环境和操作条件下保持稳定，包括极端温度、湿度、振动等。

错误恢复：在发生错误时，系统能够有效恢复，最小化对用户体验的影响。

中汽研科技

https://www.castc.net/news/9778.cshtml

随着智能网联汽车的快速发展，智能座舱逐渐成为具备信息娱乐、人机交互等多功能的智慧空间。其中，触控交互系统作为智能座舱的中央大脑，发挥着极其重要的作用。然而，随着系统长时间、高负载的运行，车机容易出现卡顿延迟，甚至黑花卡闪等现象，从而影响消费者的驾乘体验，甚至危及行车安全。这些问题可能源于硬件性能的限制、软件设计的不合理等多方面因素，因此能否通过合理的测试策划，借助自动化测试工具，及时发现上述问题并精准定位问题原因，成为当前解决触控交互系统运行稳定性疑难杂症的关键所在。

以往智能座舱触控交互系统运行稳定性测试大多通过人工开展，部分采取半自动化方式。其中，人工测试方法不仅占用大量人力资源，而且通过人工断言和计算响应时间，很难保证测试结果的准确性和一致性。当前主流的测试方案，大多采用开源的测试工具自动模拟用户操作，其测试结果缺乏对用户场景的针对性，存在误报率较高等问题，同时需要开发环境的支持，具有较大的局限性。

为满足各大企业对触控交互系统运行稳定性的研发测试需求，中汽研科技建立了智能座舱触控交互系统运行稳定性自动化测试平台，示意图如图1所示。该平台通过集成高帧工业相机、高灵敏触控传感器，结合内置的图像分析算法，实现对系统运行稳定性的测试，其测试环境有效避免了人工检测等传统测试方法对测试结果的影响。同时，该平台可通过机械臂模拟人手快速点击，并通过测试软件自动化执行测试脚本任务，使被测系统在高负荷操作下长时间自动化运行，测试其响应性、流畅性以及黑花卡闪等问题，从而充分验证触控交互系统运行之稳定性。

分析以往测试案例发现，随着触控交互系统长时间运行和多任务并发，不同应用间的循环切换逐渐增加，如在试验过程中以导航+音乐/电话+空调为一级功能主线，进行其他应用的后台挂起和切入切出时，容易导致进程调度错误、系统资源不足等情况，进而出现黑屏、花屏、卡屏等问题

Thoughtworks

https://www.thoughtworks.com/zh-cn/insights/blog/platforms/evaluation-and-improvement-of-intelligent-cockpit-software-performance-and-reliability

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

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

软件架构特性模型

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

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

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

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

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

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

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

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

寻找指标元素的数据来源

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

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

GQM 方法是一种有效的寻找和建立指标元素的分析法：

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

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

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

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

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

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

可观测工具集帮助分析

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

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

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

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

• 《2023智能座舱白皮书-聚焦电动化下半场》，毕马威
• 《2023年一季度汽车投诉分析报告》，车质网
• 《2023年二季度汽车投诉分析报告》，车质网
• 《2023年三季度汽车投诉分析报告》，车质网
• 《2023年四季度汽车投诉分析报告》，车质网
• 《软件架构：架构模式、特征及实践指南》，Mark Richards / Neal Ford
• SQuaRE 系统与软件质量模型：ISO/IEC 25010:2011，国际标准
• SQuaRE 质量测量框架：ISO/IEC 25020:2019，国际标准
• GQM 分析法，Victor Basili 和 David Weiss
• 《什么是性能工程》
• 故障树分析（FTA）
• 故障模式和影响分析（FMEA）
• ASPICE
• 《演进式架构》，Neal Ford / Patrick Kua / Rebecca Parsons