自从2011年功能安全标准ISO 26262正式发布以来，已经过去9年了。

这9年里，汽车上的ECU越来越多，E/E架构越来越复杂。

这9年里，汽车辅助驾驶功能越来越丰富，AEB（紧急制动系统，Automatic Emergency Brake）、ACC（自适应巡航，Adaptive Cruise Control）、APA（辅助泊车，Automatic Parking Assist）功能基本成了中级车的标配。

这9年里，在这些变化的驱动下，功能安全越来越被汽车行业接受，国内外各大主流汽车企业陆陆续续将ISO 26262的需求融入自己的研发体系和流程中，以保证安全能跟上E/E系统快速变革的步伐，保证辅助驾驶功能不仅好用而且安全。

于是乎，借着这股东风，ISO 26262一路“平步青云”，功能安全俨然成为了汽车研发的新兴热门话题。

Bosch对E/E架构发展的预测

但是，汽车行业在另一条赛道的狂奔，让风光的ISO 26262渐露窘色。

这就是自动驾驶。

在经历了初期的狂热后，工程思维的理智慢慢将行业拉回脚踏实地的轨道。在自动驾驶关键技术逐步取得突破的同时，“分步发展”的思路也在慢慢让自动驾驶变成现实。在私家车上，目前的一个主流思路是分成两步：

· Parking

· Driving

各大厂家正在把自动泊车作为在私家车上实现自动驾驶的一个突破口。国内从2020年开始，主流OEMs都会逐步推出AVP（自动代客泊车，Automatic Valet Parking）功能，到达停车场后驾驶员可以直接离开，车辆会自己去找车位并停车，实现“最后一公里”的自动驾驶。国外OEMs也显露出这一趋势。

本人作为一名功能安全工程师，在参与一些AVP项目的功能安全开发过程中，既深深地体会到了ISO 26262在保证系统安全中的作用和价值，也深深地感受到了ISO 26262在自动驾驶面前的窘境。所以在这里试图通过本文记录自己的一些见闻和感想与各位同行朋友们分享。

1. 从ISO 26262的视角看自动驾驶

大家对SAE的Level 0--Level5分级图都非常熟悉：

从功能安全的角度，不需要去细抠每个等级的定义，而是根据系统故障导致事故的责任方的不同，将智能驾驶汽车分成两类：

· 辅助驾驶汽车（包含Level1 / Level2）

· 自动驾驶汽车（包含Level3 / Level4 / Level5）

对于功能安全来说，两者什么区别呢？

功能安全开发的目的就是避免电子电器系统功能异常引起不合理的风险而对驾乘者或行人造成危害。简而言之，功能安全聚焦系统故障后怎么做。

对于辅助驾驶，当系统出现故障以后，只要正确向驾驶员报告了故障，那么接下无论是驾驶员一顿操作猛如虎还是车毁人亡，全看驾驶员的水平，出了事故责任方在驾驶员，厂家是没有责任的。对于自动驾驶，系统在出现故障之后，需要系统来自己操作避免事故（自动驾驶等级越高，驾驶员可以越晚介入接管甚至是完全不用接管），出了事故是厂家的责任而不是驾驶员的责任。

关于之前特斯拉被告虚假宣传，从而不得不将其宣称的“自动驾驶”改成“增强版辅助驾驶”的新闻大家都很熟悉。特斯拉的Autopilot功能正常工作的时候，表现出来的确实是无人驾驶，而一旦出现异常，却是由驾驶员来担责。从这个角度看，Autopilot充其量算一个功能表现顶级的辅助驾驶功能，远没有做到自动驾驶。

故障发生后，系统从报警变成了继续进行安全控制，可以预见，功能安全的开发难度以及功能安全对系统架构的要求都产生了质的改变。

如何保证系统故障后还能继续运行到安全状态（比如安全停车）呢？核心就是“冗余设计”。

从某种程度上可以说，汽车上的技术都是航空航天领域玩剩下的。所以我们不妨先把目光转到飞机上。我们都知道，飞机在飞行过程中机长是可以出去泡咖啡的，在飞机上已经实现了自动驾驶。飞机的自动驾驶是怎么保证的呢？除了尽可能保证零部件可靠性之外，飞机有两个发动机，保证在一个发动机故障以后另一个仍能安全飞行。这就是“冗余设计”的概念。冗余设计在飞机上到处可见，比如两个独立运行的主控ECU，两套独立的供电系统等等。

回到汽车自动驾驶上，设计思路和飞机一样，采用冗余设计，保证当关键控制器（如制动、转向等）在故障后备份系统仍能使车辆继续运行到安全状态。

2. ISO 26262窘境1——成本高昂，阻碍项目运行

自动驾驶系统电子电器的数量非常庞大，且其中非常大的部分都与安全密切相关。在自动驾驶中，功能安全的方法论概括如下：

· 进行场景与危害分析，确定安全目标和对应的安全等级（ASIL等级）

· 综合安全目标和系统架构筛选出功能安全相关的环节，进行安全设计，包括冗余设计

· 对设计的有效性进行验证

在自动驾驶系统中，因为驾驶员不参与控制，导致危害评级中因为C值上升而让很多安全目标的ASIL等级提高，满足更高的ASIL等级就意味着开发成本的上升。另一方面，系统冗余本来就是一个用钱堆出来的方案，拿制动来说，首先自动驾驶需要两个完全独立的制动控制系统，且两个系统都需要满足ASIL D的制动需求，保证在高速运行时，主ECU故障的情况下备份ECU仍能正常响应上层大脑ECU的制动指令，保证车辆安全停车。

可想而知，自动驾驶系统满足功能安全的开发成本有多高。

但是在汽车上我们又不得不面对这样的现实：汽车是走量的产品，汽车的利润比飞机的利润低得多。因此，在汽车自动驾驶系统开发中，进行功能安全开发的同时不得不兼顾成本，否则即使实现了安全系数很高的自动驾驶系统，也会因为价格过高而不被市场认可。“巧妇难为无米之炊”，如何在功能和安全之间找到平衡，是功能安全在自动驾驶中面临的挑战之一。

于是，在项目中就往往会演变成技术和市场的博弈。作为供应商，很多次和OEM开会的时候，开着开着那边的技术部门和市场部门吵起来了，这边以取消项目威胁要取消备份，那边吵着坚决不能取消备份。我们惺惺地夹在中间，场面一度很尴尬。

虽然作为功能安全工程师，肯定是坚守安全的底线。但每次碰到这种情况，都忍不住默默问自己：

功能安全应该为项目服务，还是为技术服务？

车企研发自动驾驶是为什么？为了造福人类吗？

不是。答案很现实，是为了抢占市场，为了赚钱。

现阶段功能安全有点像中途闯进车企研发团队的“外宾”——当因为功能安全开发造成的成本与收益相比能被接受时，功能安全会成为“座上宾”；但是，如果功能安全造成的成本远远大于收益，主人会不会翻脸？

如果企业有一个被寄予厚望的项目，因为功能安全而拦住了项目的开展，不排除一些安全基因很浓的企业会叫停项目或者把功能降级到安全范围内，但是谁又能保证有的企业不会越过安全保证项目继续进行呢？如何来做这样的取舍呢？

3. ISO 26262窘境2——就算不计成本，还是不能保证足够安全

我们假设所有的企业都选择“安全第一”，项目中不计成本地保证自动驾驶系统满足功能安全，那么，我们就可以说这个系统足够安全了吗？

回答这个问题之前，我们不妨先来看一个让人啼笑皆非的例子：特斯拉智能驾驶功能错把具有中国特色的幸运红绸识别成了路障。

特斯拉错误将红绸识别成路障（图片来自网络）

这个错误识别不是因为传感器故障导致的，而是传感器本身的功能局限和算法深度学习不够导致的。

从这个案例我们发散一下，会用到很多的雷达和摄像头。但是因为多普勒效应，毫米波雷达不擅长识别静态物体；而摄像头在雾天或者光线不足等情况下探测度都会降低，这些因素都会导致在一些场景下无法正确识别物体从而可能导致系统做出错误的驾驶动作，引起交通事故。

ISO 26262功能安全旨在避免电子电气系统故障导致功能异常而引起的不合理的危害。而如果传感器不是故障仅仅是功能受限，软件没有bug而是深度学习不够，这些问题都不属于ISO 26262的范畴。

ISO 26262在自动驾驶面前暴露出了它的局限性。

业内也已经注意到了ISO 26262的这一尴尬，为弥补这种局限，预期功能安全SOTIF (Safety of the Intended Functionality)诞生了。

Functional safety+SOTIF是目前行业认可的解决这一问题的方案。

简单来说，SOTIF强调的是避免因为预期的功能表现局限而导致不合理的风险。

因为SOTIF诞生的背景是智能驾驶的发展，所以如果按照智能驾驶的功能链：感知——决策——执行来归类，“功能表现局限”体现在3个方面：

传感器感知局限导致场景识别错误（包括对驾驶员误操作的漏识别）；深度学习不够导致决策算法判断场景错误（包括对驾驶员误操作的误响应）；执行器功能局限导致与理想目标偏差。

限于篇幅，这里对SOTIF不作展开，感兴趣的朋友可以在知乎上搜索“如何理解预期功能安全SOTIF?”的回答。

但是截止到2020年5月，SOTIF的ISO标准还没有正式释放。而且从draft版本可以预见，SOTIF虽然很大程度上弥补了ISO 26262对“功能局限”的盲区，但是仍然有一些关键点没有给出明确的答案，比如如何做定量分析。

另外，ISO 26262从诞生到被行业普遍认可用并较为熟练运用经历了9年，SOTIF又会如何呢？目前仍是一个问号。

4. ISO 26262在自动驾驶面前的窘境，正反映出传统车企在特斯拉面前的窘境

相信大家看到这里，也能体会到ISO 26262在自动驾驶面前的一些尴尬了。

如果单纯考虑技术，那么ISO 26262的尴尬在于，功能安全的方法论不能完全避免所有自动驾驶可能产生的不合理的风险。

不过，这说到底只是一个技术问题。技术问题总归是有解的。车企通过项目实践，边做边学，假以时日，终究能琢磨出完善的functional safety+SOTIF的方法论组合落地的方案，而且这个方案一定会越来越完善。

但是当综合考虑市场等因素时，功能安全面对的就不仅仅是技术问题了，如果过分强调功能安全，必然会造成项目节点的推后，更严重的甚至会造成项目流产。这可能是个哲学问题，因为它在某种程度上正反映了在自动驾驶洪流中，传统车企面对特斯拉时的困境。

毕竟，我们不能说没有进行功能安全开发的系统出错概率就一定大到系统无法使用的地步。在没有ISO 26262之前，很多企业的完善的开发流程已经能够把电子电器系统出错的概率保证在比较低的数值之内，功能安全从某种意义上只是采用系统的方法把这个概率降得更低。所以，对于自动驾驶这一仍然充满着未知的系统，估算自家的系统故障概率以及市场对于故障概率的容忍度，有点像是企业的赌博。

传统的车企摸爬滚打了这么多年，深谙口碑树立之道，见识过太多的召回以及召回对品牌的损害程度，保障安全已经溶入了它们的研发基因中，竭力将危及安全的因素扼杀在研发阶段，所以在这个赌局中表现得谨小慎微。对于用户来说，这种保险的做法是负责任的表现。但是对企业来说，这导致的一个弊端就是项目开发周期长，推进慢，实车道路实验还停留在测试阶段，没有足够的数据样本去发现系统问题，系统的升级速度自然就慢，形成了一个恶性循环。这样一来，留给了对手太多的成长时间。

而特斯拉作为拥有互联网基因的新势力，深知用户体验的重要性，把研发重心放在功能表现上，功能安全暂时先放一边，通过极佳的功能表现和大众对自动驾驶定义的误解迅速成为“自动驾驶”的代名词，在这个赌局中表现得非常激进。这种思维不可避免地导致量产初期经常因为系统问题引发安全事故而饱受诟病。但是，随着销量的攀升，每多卖一辆车，就多一辆车帮特斯拉采集真实的道路数据，数据样本越大，系统越就能越快发现问题，每升级一次便安全一分。特斯拉已经形成了这样一个正循环来保证它的智能驾驶系统越来越成熟，从而使它在向自动驾驶进发的道路上占领先机。

结语：

传统工程思维和互联网思维的碰撞，各有优劣，我无法做出武断的评价。作为消费者，我为传统车企在安全面前谨慎的态度而感到心安，毕竟人命关天。同时作为汽车从业者，我也由衷为特斯拉取得的成就而高兴。因为传统车企工程思维根深蒂固，难免会有僵化的风险，所以需要特斯拉的搅局带来的危机感给这种思维一些冲击，好刺激传统车企做出新的思考和改变。对于汽车行业来说，如果传统工程思维和互联网思维能取长补短，在功能和安全上尽快找到平衡点，那么这对促进自动驾驶技术的早日落地会有很大帮助。

图｜网络及相关截图

作者简介：某Tier1系统功能安全工程师，在知乎上写有专栏《功能安全工程师的笔记》，知乎ID：小青的风筝。