导言：小米SU7由于软件策略缺陷主动向国家市场监督管理总局备案召回计划迅速上热搜榜单，解决方案为智能泊车系统增加更多冗余保护策略，说明了以冗余(可以在软件层面实施)为代表的安全机制，对于汽车电子电气系统设计非常重要。功能安全设计开发做的好可以提高产品的附加值，提升产品在用户心目中的定位，当然升级消费者对品牌认知需要的时间比较漫长，然而如果设计的不好引发安全失效，这类事件则会迅速拉低客户对品牌的认知。本文试图从该事件出发，揭示功能安全行业当前在认证层面存在的一些不理智行为，并提出对功能安全从业者的一些建议，目标是期望能引起各位从业者对功能安全的重视，在安全开发与成本之间找到合理的平衡点。
01 软件策略缺陷导致召回
1月24日，国家市场监督管理总局官网披露信息显示，日前，小米汽车根据《缺陷汽车产品召回管理条例》和《缺陷汽车产品召回管理条例实施办法》的要求，向国家市场监督管理总局备案了召回计划。决定自即日起，召回2024年2月6日至2024年11月26日生产的部分SU7标准版电动汽车，共计30931台（车辆型号BJ7000MBEVR2涉及车辆18410台；车辆型号XMA7000MBEVR2涉及车辆12117台；车辆型号XMA7000MBEVR5涉及车辆404台）。
引用：国家市场监督管理总局
召回的原因是这部分车辆存在软件策略上的缺陷，可能会导致授时同步异常。这一异常状况会进一步影响到智能泊车辅助功能对静态障碍物的探测能力，从而增加了车辆发生剐蹭或碰撞的风险，对行车安全构成了潜在威胁。同步，小米汽车王化表示，此次OTA召回仅通过对车辆进行免费远程升级（OTA）即可完成，不需要车辆进店进行任何检查或处理。
小米汽车本次主动备案召回计划，一方面说明了小米汽车在深陷舆论风波和智能泊车功能存在软件缺陷的背景下，主动承担责任的大厂形象；另一方面也说明了汽车安全相关的电子软件系统，特别是智能驾驶相关的控制系统，按照功能安全要求相关开发非常重要。
引用：易车
通过对小米汽车召回原因的解释分析，用功能安全的语言表示即为：安全目标为智能泊车系统要避免发出非预期的加速请求，安全机制为要对静态障碍物有探测能力(传感器)，必要时有一定冗余机制实现探测，如果不按照这个要求开发，就会产生缺陷，从而对行车安全构成威胁。
02 智能泊车系统及功能安全开发
搭载有智能泊车功能的汽车可以在不需要人工干预，通过车载智能泊车系统实现自动识别车位，并自动完成泊车入位的过程，这对于新手驾驶者而言，可以带来更加智能和便捷的体验。从技术角度来讲，主要是利用车辆自身和周边环境中的传感器，测量车辆自身与周边物体之间的相对距离，速度和角度，然后通过车载计算平台或者云计算平台计算出操作流程，并控制车辆的转向和加减速，以实现自动泊入，泊出及部分行驶功能。
概念阶段：主要开展Item definition相关工作，也就是识别系统开发的边界，理清产品与周边其他交互产品的交互，通过危害分析与风险评估的方法，推导所开发系统的功能安全目标。
引用：Xiaojun Kuang: System Design of APA
智能泊车系统的功能安全目标为：
架构阶段：在得出了安全目标后，需要在架构层面，应用安全分析工具如FMEDA，FTA等进行安全分析，确保相关失效模式及安全机制都被考虑到设计中，确保系统架构层面的安全相关设计被充分考虑。
引用：TTTech
系统架构设计阶段，就可以在系统层面引入一定的安全机制，对于智能泊车系统，功能安全设计最重要的安全机制是冗余，包括计算平台异构多处理器进行锁步处理，传感器备份冗余，整车电源冗余等。
同时，在产品整个生命周期开发过程中，概念阶段的系统架构与设计实施中的硬件架构和软件架构要保持持续的沟通，确保相关设计(系统层，软件层，硬件层)能够及时同步开展，系统把控产品的安全性。
设计阶段：产品硬件设计阶段要对三种不同硬件架构指标(SPFM, LFM, PMHF)进行定量计算，确保相关安全机制，失效率均能满足对应安全目标要求。
引用：ISO26262-5
软件需要从架构设计的角度去规避风险，检测失效，比较典型的方式就是三层监控，在功能层进行功能正常的信号采集，泊车功能计算和实施，功能监控层对功能层进行监控，确保功能层的功能实施与请求的功能一致，最后还有微控制器监控，检查运行的整套系统工作状态是否正常。
引用：E-Gas Monitoring Concept
相比于硬件冗余会增加单车的BOM成本，软件层面的冗余保护措施从性价比层面会很高，但同时对产品开发从业者的技能水平也会有更高的要求。在事故发生后第一时间确定了问题原因，即云端服务偶发故障引起的软件授时同步异常，同时小米汽车通过云端服务实施了有效的防范措施，并在智能泊车辅助中加入了更多冗余保护策略措施，已确认排除风险可能。
需要说明的是，智能泊车系统的功能安全需求并不是自发产生的，而是按照本文中所述的开发步骤，从整车层面一层层分解到所开发的系统中的。
03 功能安全行业认证乱象
04 总结与希望
-
说起来重要，做起来次要，忙起来不要； -
对外重要，对内次要，实际不要； -
宣传重要，实践次要，花钱不要。
-
对于认证机构：要有安全底线，要保护认证行业的权威和公允；功能安全流程认证和产品认证已经成为了一门由外资认证机构主导的生意，在这个生意的链条中，认证机构在国内的代理商不要把自己的饭碗给砸了，国内当前不太重视功能安全，说实话与这类只看重个人短期利益，不在乎认证机构声誉和客户产品安全性的认证机构，有很大关联；还是要从帮助客户切实提高产品安全性的角度，为中国汽车行业和半导体行业的健康发展贡献力量。
-
对于汽车及零部件公司管理者：要正视功能安全开发带来的价值和成本间的矛盾；小米汽车的召回在网上迅速成为热搜，进一步说明了安全性对于品牌的重要性，功能安全做的好可以提高公司和产品的形象，进一步产品的附加值，占据产品在用户心目中的品牌认可度，做的不好则会对品牌的形象造成很大影响；符合功能安全标准的开发不意味着所有的工作都要完全按照流程刻板的照猫画虎，可以有一定的裁剪和适用性评估，这个过程建议寻找有产业实际经验的技术专家进行技术把控，对产品真正理解的工程师才可以把安全做好，功能安全，功能在前，对功能没有认知的咨询机构，能起到锦上添花的作用，但雪中送炭，很难。
-
对于汽车及零部件功能安全从业者：要练内功；功能开发工作不一定要有专职的功能安全工程师来进行，只需要对产品的功能理解，有一定的软硬件有深入理解，且具备功能安全基本知识的人员就可以把相关工作做的很好；真正的功能安全从业者要能够与系统工程师进行架构层面的技术沟通，识别架构中安全的薄弱点，可以理清原理图中对安全机制贯彻的不到位，可以从代码的逻辑中找出软件安全机制设计的不合理，这样的功能安全工程师才能在产品开发团队中取得公信力，进而让系统，软硬件工程师与自己积极配合，而不是被认为仅仅是一个单纯的流程执行者。
-
对于有意愿转向功能安全方向的刚入职大学生：要打好软硬件开发基础，在具备一定软硬件开发经验前，最好不要转入功能安全这个方向，因为如果对产品功能不理解，即使转到功能安全方向，也不容易受到身边同事的认可；当然，对于已经转行的同学，建议抓紧事件培养自己软硬件的基础知识。
