本系列文章旨在分享功能安全要求下，如何设计一些增量的安全组件，在原有的预期功能上叠加，尽可能少去变更原有功能，而让整体功能达到安全的要求。在智驾产品应用方面，L3+自动驾驶系统满足功能安全要求，既要考虑安全性，也要考虑可靠性，其中，关键环节就是安全架构和安全机制设计（如一些安全组件作为安全监控）。本篇文章将以依托L3+高级别自动驾驶安全架构和安全组件设计详细展开。
当汽车迈向L3级（SAE J3016规范-有条件自动驾驶）及更高L4以上级别的自动驾驶时代，传统的分布式电子电气架构已无法满足需求，域控制器（DCU） 作为集中式处理中心应运而生。与L2级别辅助驾驶系统（ADAS）相比，L3+智驾域控制器在性能和安全性上实现了质的飞跃。传统L2级辅助驾驶域控系统架构如下，在域控中实现单链路的感知-规划-控制功能。
而对于L3+级别自动驾驶而言，传统的L2架构是无法满足要求的，其原因在于L2与L3+自动驾驶对于故障发生后的处理要求不同。对于L2而言，驾驶员需随时接管驾驶任务，当自动驾驶系统发生故障时，车辆的接管权会移交到驾驶员手中，在这一等级，自动驾驶系统属于辅助驾驶系统（ADAS）。对于L3而言，架构更新为主通道和冗余通道的双通道架构，自动驾驶主通道发生故障后，驾驶员无需立即接管，自动驾驶系统冗余系统仍会在10-20秒内保证车辆的操控，直至车辆达到安全状态或驾驶员接管车辆。
L3系统必须具备完善的Fallback（故障备份）机制。当系统检测到自身无法处理的情况时，会向驾驶员发出接管请求，并提供足够宽裕的交接时间（通常10秒）。若驾驶员未响应，系统将自主执行最小风险策略（MRM），如安全靠边停车。Fallback机制的实现依赖于独立于Main ECU的Fallback ECU实现，如下图，图中的域控架构由独立的Main ECU和Fallback ECU部分组成。Fallback ECU能够独立实现接管自动驾驶的功能，因此在功能层面上与MainECU类似，同样会完整的设计感知规划控制等模块。
图4 L3+自动驾驶域控安全架构实施（Main+Fallback）
在功能安全等级方面，L3域控制器必须满足ISO 26262 ASILD等级。这方面也可参考目前市面已有的域控方案，比如某公司的IPU03域控制器采用QNX Safety OS操作系统和包含Safety组件的Autosar系统，硬件设计采用备份冗余设计，达到ASILD等级要求。再比如另一家公司的RazorDCX Pantanal域控制器同样遵循ASILD开发标准，采用先进的Fall-Operational（故障后可运行）安全架构，可满足不同自动驾驶功能安全需求。而图3中所展示的架构也是由双ECU组成的Fall-Operational安全架构。
无论是MainECU还是FallbackECU，需要达到相应的ASIL等级。而对于高ASIL等级的组件，如控制、规划等模块，在预期功能设计开发阶段，要求其直接达到ASILD等级是相当困难的，这需要功能安全对预期功能提出具体的安全要求，这涉及到预期功能甚至系统架构层面的大量修改，一方面增加了预期功能开发团队的工作量，另一方面在时间成本上也会增加。
因此可以通过设计安全组件的方式，解耦预期功能和功能安全来实现所需的安全监控、安全机制，以此实现相应安全目标。通过设计安全组件来满足功能安全的实现方式如下图4，PerformanceChannel中的Decision/Planning模块和Control模块分配为QM，SafeChannel的安全组件Planning&Monitor模块和Control&Monitor模块分配为ASILD，SafeChannel的安全组件实现对预期功能的故障监控和处理。
图5 规划与控制模块安全组件设计实施
安全组件的具体设计流程以MainECU的Control功能为例，对控制模块设计安全组件实现安全监控，Control模块的功能是执行规划轨迹的跟踪控制，计算得到当前车辆所需控制量如油门刹车开度、方向盘转角大小等，输入到车辆执行。首先从概念阶段得到MainECU的Control相关的FSR（功能安全需求）为：当车辆处于自动驾驶模式控制车辆时，MainECU不能发出错误的/不安全的车控信息。经过分析得到对于控制模块的TSR（技术安全需求）为：控制模块不能输出非预期/过大/过小的横纵向控制量。
那么如何实现该TSR，首先通过加入安全组件监控控制模块进行安全需求的分配，将控制模块设计分配为QM等级，其监控模块（Control&Monitor）分配为ASILD等级，解耦预期功能开发与功能安全开发，将功能安全需求落到安全组件监控模块，总结的Control&Monitor（控制模块的监控模块）SSR（软件安全需求）如下表。
表1 Control&Monitor的软件安全需求
第一条SSR012_001是计算控制量是否非预期/过大/过小，可以通过在Control&Monitor模块中添加计算控制量的逻辑，并将计算结果与Control模块的输出控制量进行对比，来实现对Control模块控制量是否非预期/过大/过小的判断，如果二者差值超过标定的安全阈值，则可以认为Control输出控制量非预期/过大/过小。第二条SSR012_002是检查Control模块输出的控制量是否处于车辆驾驶性能内，这就需要去标定不同环境工况下，车辆的加速度、方向盘转角的安全边界，得到标定后的数据与车辆当前驾驶状态进行对比。第三条SSR012_003则是在Control故障确认后，Control&Monitor模块输出其控制量至车辆，接管车辆控制。
依据软件安全需求可以设计如下的Control&Monitor模块来实现对Control模块的故障监控（确认+处理），具体的实现方案和算法逻辑可灵活处理，下图仅为一种参考的实现方式。
| L3+自动驾驶的域控一定需要Fallback设计吗？ |
| 因为L3+自动驾驶中，驾驶员可不在环，这个特性就要求了域控需要能够在出现故障后，能够进行Fall-Operational处理，而Fall-Operational则需要FallbackECU的存在。 |
| |
| 就规控部分来说，是基于规则的算法，因为通常预期功能的规控算法可能是基于AI做的，因此做监控的安全组件是基于规则的，一方面便于实现和达到安全等级要求，另一方面要和预期功能做到算法异构，排除共因失效，还有就是基于规则的算法更方便以补丁的方式去迭代而不需要大量数据，对于小数据量的corner case更容易实现覆盖。 |
L3+级自动驾驶对系统性能和安全性提出了更高要求，传统L2架构已无法满足。通过探讨L3+自动驾驶域控的安全架构设计，展现了Fallback机制在L3+域控架构中的重要性。无论是MainECU还是FallbackECU，二者的功能安全等级都需达到ASIL-D标准。智驾的预期功能本身达到ASIL-D等级是相当困难的，但通过安全组件的设计，如Control&Monitor模块，可以实现对控制模块的有效监控，而不需要被监控组件修改设计与开发。因此，在智驾域控开发过程中，通过合理设计安全组件，可以在解耦预期功能与功能安全开发的同时，保证达到ASIL-D等级的需求，确保自动驾驶系统的安全性、可靠性和可用性。
我们功能安全团队成立于2008年，是国内较早从事功能安全技术研究的团队，作为功能安全国家标准委员会成员参与功能安全、预期功能安全标准制定，作为芯片创新联盟核心成员参与车规级自主芯片功能安全国标制定。目前有专职的功能安全技术人员80余人，团队成员大多来自985/211高校，核心项目实施团队拥有8年以上电控产品开发经验，可以提供面向量产车型开发从概念设计到正式投产的全栈功能安全咨询服务，当前已成功为国内外整车及零部件企业提供150+项工程咨询服务。
未来，我们将紧跟行业发展趋势和市场需求，结合自身汽车电子产品研发和国内外咨询实践，一如既往地坚持自主创新道路，为智能汽车安全保驾护航。
如涉及文字或图片侵权请及时与我们联系反馈，文章版权及解释权归原作者及发布单位所有，如需转载或引用文本的任何内容，请注明出处。
✌✌tips:敬爱的读者朋友们，由于微信的推送规则，即使您关注了我们，可能也常常收不到推送，记得点击"HiFusa"名片，设为星标⭐ ，文章会自动推送哦！
hifusa@hirain.com | 联络/投稿邮箱
