功能安全开发实战经验：智能座舱软件如何布局？

“博世依据ISO26262规范，在时间成本、研发成本和驾驶体验、功能安全反馈体验等关键项上进行功能安全保障。

 内容摘录自盖世汽车，BOSCH-姬聪飞，仅供学习参考！

功能安全开发的两个重点——成本考量、用户体验

功能安全开发主要关注的方向是符合规范，成本考量和用户体验。规范上，相对应的国标是ISO26262, 主要是产品出口压力，要出口到欧盟、北美、南美、澳大利亚、中东这些地区，避免法律上不合规问题。

成本上，在保证了产品可靠性安全性的同时，成品成本随之提高，这个不可避免。对于成本我们在考虑可以尝试使用新技术的加持，如AI大数据，chatGPT等，希望能在成本上作些优化。

用户体验上，用户感知度最高的就是体验。驾驶体验，功能安全反馈体验这两者之间有一定的矛盾点。驾驶体验，偏重于用户对智能座舱产品的可用性、舒适性的体验。而功能安全更偏重于可靠性。它的反馈体验就是在出现异常事件时，在满足安全目标的前提下，所采取的措施和进入的安全状态，是否能满足或解决用户的切身需求，并让用户能够和平接受。

就像车辆异常进入跛行模式，行动缓慢，但是用户希望能正常驾驶。再比如说智能座舱中监控到某种异常，然后仪表黑屏。但是用户还希望能看到仪表中的其他指示信息。这是对软件策略制定和开发人员的挑战。

功能安全开发实战经验

下面结合项目，和大家聊一下，在满足功能安全ISO26262要求的前提下，我们在其中的一些探索和思考。

智能座舱功能安全的主流方案其中的一个safety goals是报警灯或者档位指示灯，避免非预期不发出报警或错误指示或者不发出提醒。

目前我们计算安全报警灯显示的内容，完全依赖于区域内所有像素点，像素点显示是否正确。基于所显示的图标的像素点进行检测，大家可以看左侧，我可以对这张图进行转换，转换为二进制，比如说后三位数是011，如果说其中的像素点产生了偏差，最后的二进制就变成了110，这个时候我就可以通过这种机制，来判断是否这张图受到了干扰，或者是这张图已经跟原来不一致了，比如说图有残缺或是完全不一致。

其中的思路是从pipeline混合后的图层中，基于区域获取到区域内所有像素点，利用CRC引擎计算，然后去对比，若有差异则进入安全状态。

当前的主流方案有两个技术性的要求，一个是基于每个像素点的检测，一个是基于一块方形区域进行检测。这是比较传统的做法。

就算增加硬件成本，升级硬件依然是基于区域内所有像素点的，检查图标范围内像素的偏差。于是在满足功能安全规范的前提下，我们也在探索一些新的功能安全解决方案和架构设计。

图源：演讲嘉宾素材

大家看左侧的显示对比，第一个是正常的，其次是背景透传，雪花斑点，波段条纹，是否都可以正常识别出是安全气囊故障报警指示灯？

我们认为驾驶员是可以识别出来的，如果基于现在主流的方案，毕竟存在像素点的偏差，我们会认为这样的状态存在错误。但是站在驾驶员的角度，功能安全更人性化和可用性的角度，这种情况是否也有一定的合理性呢？

基于这种思考，我们在探索一个新的方案：

采用图像识别技术，对图像的特征点和关键点进行动态识别。假如有背景透传，我们认为这些存在像素点的偏差，但是这些像素点的偏差并不会对驾驶员整体的判断产生影响，那么我们依然认为这是一个安全的状态。

那么在实施的时候，我们可以对类似于表示安全气囊的圆球和人形轮廓进行动态采集。在满足功能安全ISO26262标准要求的前提下，将采集到的数据集导入模型组件进行训练，并将训练和验证好的模型部署到工程模块中。

通过部署的模型可以识别出虽然有些瑕疵但是依然可以被用户正常识别的case,避免不必要的进入安全状态情况，提高系统的可用性、容忍性。现在如果对安全状态行为细分的话，现在多数方案为简单的 Fail-Safe，就是第四种重启系统，重启就会黑屏，带来的问题就是用户体验很不友好。这就又回到了驾驶体验与功能安全反馈体验之间的冲突。

为了降低两种体验之间的冲突，我们探索采用多级降级方案，就算进入安全状态也可以继续使用，来提升系统的可用性，同时也提升用户体验。

目前我们评估能够想到的大概是这四种方式。当检测到问题之后，按照严重程度，我们评估出问题若是一些偶发低严重程度的问题，可以采用第一种显示备份图标。如果持续校验失败，严重度升级为中等，可以采用第二种弹窗提示。

如果是持续的，不可恢复的故障 ，那么就要尝试重启相关组件。由此带来另一个问题就是不同组件之间要进行解耦，功能安全相关的功能在设计时要保证独立性。当所有的降解方案都无效后，再尝试采用第四种重启系统恢复。

上面的严重度判定可以结合图像识别模型的判断，反馈的每种错误分为非严重，轻微严重，中等严重，重度严重等级四种严重度对应4级恢复策略。总体来说就是降低驾驶体验与功能安全反馈体验之间的冲突，提升可用性与用户体验，其中重启相关组件最为复杂。

对于重启相关组件，使用多核系统，进行多核功能分区，不同组件之间解耦并保持独立性。

比如，如果功能分区1是对配置数据进行监控，若发现配置数据损坏后，可以单独init该功能分区，重新设置配置数据。或者功能分区3是部署的图片识别模型，与CRC引擎计算结果不匹配，那么可以单独重启图片识别模型功能分区即可。当然在执行相关重启的时候，如果对中控和仪表会有影响，可能设置的策略为在小于60km速度场景下可以尝试单独重启，仪表在30km速度下可以尝试单独重启等。 

图源：演讲嘉宾素材

对于测试验证：1.针对图像识别模型，使用错误图数据集训练出的图像故障模型，结合测试case进行自动化故障注入测试。

2.其他所有安全机制，根据需求和应用场景整合大量的test cade，进行充分的自动化测试。用来保证产品的鲁棒性等。

智能座舱领域面临的挑战是更多Telltale灯，更多主题模式，主机厂推出主题商城，层出不穷的UI设计风格，也使开发复杂度难度增大。在这里的体会是，实施了功能安全可以被看作是state of the art。但是需要注意的是state of the art并不是静态停滞的，它是随着技术发展需要不断迭代更新的。我们就要找到新的思路和方法去适应和推动产品的迭代发展，让客户更好的接受和认可功能安全。