前段时间，梳理了当前L2+系统的功能定义变迁趋势，并梳理出两个审视智能驾驶系统的维度，即“场景多样性”和“自动化程度”（图1）。
“场景多样性”，在保持驾驶员不脱手的前提下，尽量提升智能驾驶系统的开启范围以及开启后的连续性（不要经常退出），提升功能可用性和用户体验，目前特斯拉以及国内主流的OEM也都较为认可这种功能定义策略。
“自动化程度”，则更多地关注如何提升系统的MTBF（Mean Time Between Failures），满足脱手/脱眼/脱脑等逐步提升的自动化程度。这方面，一般需要构建冗余系统来提升MTBF。冗余的方式之前的文章也盘点过。
在盘点过了现有的各家智驾方案后，个人还是认为Mobileye的L4 Robotaxi方案能够最完整的覆盖“场景多样性”和“自动化程度”这两个维度的诉求。简单讲，“场景多样性”由Camera-Only subsystem负责；“自动化程度”由Radar-LiDAR subsystem覆盖。
关于传感器的冗余，个人认为简单的单一传感器叠加是不够的。本小结尝试证明该判断。
【关于MBTF】贴一下百度词条的信息：MTBF，即平均无故障工作时间，英文全称是“Mean Time Between Failure”。是衡量一个产品（尤其是电器产品）的可靠性指标。单位为“小时”。它反映了产品的时间质量，是体现产品在规定时间内保持功能的一种能力。具体来说，是指相邻两次故障之间的平均工作时间，也称为平均故障间隔。概括地说，产品故障少的就是可靠性高，产品的故障总数与寿命单位总数之比叫“故障率”（Failure rate）。它仅适用于可维修产品。同时也规定产品在总的使用阶段累计工作时间与故障次数的比值为MTBF。磁盘阵列产品一般MTBF不低于5万小时。
对于一款智能驾驶产品（智驾系统方案），多少MTBF算是合理的？目前没有行业定论，但我们可以估一个出来。有几个常用的衡量信息罗列如下：
如图2，功能安全的ASIL-D对随机硬件失效的要求，取个倒数，就是MTBF，10的8次方小时，1亿小时。现在需要想想，这个工程指标为什么定到这个量级？即使想不通，抄作业时，是不是可以复制过来灵活使用这个经验值？
如图2，功能安全的ASIL-C对随机硬件失效的要求，取个倒数，10的7次方小时，1千万小时；
如图3，Mobileye给自己的L4系统定的安全目标：10的7次方小时（10的负7次方在博客上打字不好打，我默认取倒数，做了个转换），1千万小时。他这么定的原因是说，每1万小时（10的4次方）的行车过程中就会有人受伤；每100万小时（10的6次方）的行车过程中就有人死亡。所以他的系统，再加一个量级（10的7次方），比平均水平安全十倍，就可以接受了。
以上的数据罗列，是不是有些胡子眉毛一把抓？拿硬件随机失效和Mobileye的系统失效等完全不在一个维度上的数字来对比^_^。但是对于做方案评估，已经足够了。因为参考的是这个数字的量级，百万级小时数、千万级小时数、亿级小时数，这个范围我心里有数了，【百万小时 到 亿小时】之间。再结合《100万小时（10的6次方）的行车过程中就有人死亡》这个关键的统计数据（Mobileye给的这个数据源在哪不清楚，先假设这个值值得信赖），基本能确认一点：要想保证智驾系统足够安全（其实也是个质量目标），需要做到≥100万小时不出关键错误（Safety Critical Error）；加一个安全余量和倍数，那就是做到千万小时级别。
千万小时量级的MBTF目标拍下来，如果都让Camera-only系统搞，难度大不大，我不清楚。看了下Mobileye的做法，是使用两个完全独立的子系统，来分摊掉这个目标的。这样Camera-only系统领到一个10的3.5次方的指标，再加点安全余量，取个整数，就是10的4次方（1万小时安全无故障）这么一个指标。这个指标代入到正常使用的场景中，是个什么状态？Mobileye的市场材料里（图4）也帮我们翻译好了：意味着每天开车开2小时的话，连续开十年，没有出过安全相关的感知失误！
再回过头来看，如果不拆成两个子系统，让Camera-only系统领一个10的7次方指标，对视觉感知又会是什么样的要求呢？说好的完全无人驾驶，准备哪年实现呢？
因此，单一传感器实现自动驾驶/无人驾驶，目前看起来有不小挑战，即便Mobileye为了提升Camera-only系统的MBTF，搞了Vidar方案，纯视觉冗余方案（图5）。
根据第一小节的分析，我们可以了解到，由于当前主流的智驾传感器，如摄像头、毫米波雷达、激光雷达等，都有各自的缺陷，而且这些缺陷造成系统的MTBF过低。简单的加倍不能很好的解决问题。
因此更好的方式，应该是遵循多样性（diversity），如图6所示，能互补（complementary），减少单一传感器导致的共因失效。这也是为什么这两年大家都在关注激光雷达（包括我之前的系列文章，也都默认L3以上需要Lidar，原因也在于此）。
所以，Mobileye的方案，给的是被动传感器系统（Camera-only，如图7） + 主动传感器系统（Radar+Lidar，如图8）。每个系统需要背锅背指标，10^-4指标。每种传感器都有自己的角色和定位，不翻译英文，各位自己在截图上看。
三、多样性就完了？不，还要强调《独立》
应该说，如果只看Mobileye这套系统的传感器配置（Sensor Set）的话，目前国内很多主流方案都比较类似，比如我之前这篇文章的分析。
ADAS/AD系统方案03-L2+级传感器配置更新和可能的终局配置
但是实际上，最关键的一点在于：独立子系统。
国内绝大部分智驾系统方案是这么做的（图9）。Radar、Lidar只是在感知环节，作为了一种感知的补充；整个系统，仍旧是单个数据流的pipeline。一个单点失效，整个系统就挂了。没办法，功能安全工程师就给环境模型模块，定了个ASIL-D。这里面有很多工程实现上的悖论，不细说了。
所以，除了看表面的传感器配置以外，还是要关注系统架构的设计。Mobileye的方案（如图10），确实是从感知、到环境模型（ADAS阶段low一点，叫道路模型road model；甚至更早，就是经常说的那个“传感器融合”软件模块）、再到规划，都是单独的两条pipeline数据流。直到决策，才是一个。这里面可以做很多逻辑，比如做plausibility check、或者其中一条pipeline失效了，使用另外一条，巴拉巴拉...
四、两个独立子系统，对产品策略也很友好
最后，说说这种方案在产品层面的好处。其实Moblieye现在也是这么做的。
那套Camera-only系统，Mobileye起了个名字：SuperVision（图11）。做好L2+方案。潜台词，不增加MBTF，不脱手，但是吧，我感知性能至少比当前的1R1V、5R1V效果好（特斯拉的FSD也证明了这一点），在城区里跑跑问题不大（从来不提自动化程度，出问题人要接管；自动化程度，要看MBTF），至少智驾系统的开启率和连续性显著提高了，可用性增强。
要做真正的自动驾驶（体会体会“自动”这词，想想学校有个专业：自动化专业），肯定不是能在城区跑、能在山里跑，就叫自动驾驶。是需要提高MBTF的，那么Mobileye的想法是，我加一个基于Lidar+Radar感知的冗余子系统，而且跟Camera-only系统解耦，完全独立。
这两年感觉ME的重点都在打造Lidar+Radar这套子系统上。一直在搞FMCW LiDAR和Imager Radar的硬件开发。
分析完以后，结合最近的两篇文章，我们总结下，看看在讨论高级别智能驾驶方面，有什么收获：
ADAS/AD系统方案03-L2+级传感器配置更新和可能的终局配置
做高级智能驾驶系统/功能，应该盯着MBTF（或者类似指标），产品化的名称，如可脱手、可脱眼、可脱脑；
冗余系统，在感知侧，更多强调多样性（diversity），以快速提升系统的MBTF；
L2+系统，应该更聚焦。放弃脱手、脱眼等MBTF指标，专心致志做场景多样性（即ODD扩展性，比如今天能在高速上用，明天能在城区里用，后天能在山区里用）；但是只说能用，不为自动化（冗余、Lidar、4D Radar等部件）埋单；而是拼当前主流的接管率等用户体验指标，提升系统开启后的流畅度，提升可开启率和系统正常运行的时间；
自动驾驶法规方面，如果你一直在L2+打转，不touch到高级智能驾驶系统/功能，其实影响不大；但是如果励志做高级别智能驾驶（真自动驾驶），那么如何提升MBTF，如何设计ODD、Take-over、Override、MRM和HMI等模块，都很重要。就不是光盯着感知、定位建图、决策规划这几个general ADAS/AD SW components玩就算OK了。
（完）
联系客服
