在自动驾驶进入新一轮疯狂的“硬件堆砌”阶段，更大的隐患也在出现。

4月19日，滴滴自动驾驶在上海车展发布全新硬件平台 “滴滴双子星”。相较上一代，硬件平台在传感器数量级和种类，以及性能算力方面都大幅提升。

其中，全车传感器数量增至50个，算力超过700TOPS，每秒超千万级点云成像，传感器最远探测距离超过300米，最小可探测距离为10cm，车规级相机像素总和超1亿。

7月6日，AutoX推出了公司的第五代全无人驾驶系统AutoX Gen5，共50个高清车规级传感器，包括：28个8百万像素的车规级摄像头，每帧像素总和超过2.2亿；4D毫米波雷达，角分辨率达到0.9度；高清激光雷达，每秒超1500万点云成像。

计算平台采用英特尔32核双CPU 3.4GHz、英伟达7nm制程车规级GPU，以及赛灵思的车规级FPGA，可支持最多32路800万像素摄像头、10颗激光雷达和10颗毫米波雷达的数据处理，总算力达到2200TOPS。

实现车规级别功能安全的多重冗余，是这一轮硬件升级的主要话题，但在软件层面，几乎没有一家自动驾驶公司有更多的披露。而对于功能安全的解读，更多停留在硬件的冗余以及类似QNX这样的高安全级别操作系统的加持。

但，这对于自动驾驶甚至是无人驾驶的上路，还远远不够。而各家单打独斗、比拼硬件、相互质疑成本和硬件的“军备竞赛”已经成为行业常态，也埋下了隐患。

一、

“不管是传感器、芯片等硬件，还是商业化的操作系统，这些对于所有的自动驾驶公司来说，都是公平的（完善的代工及供应商体系）。但，核心在于软件算法的安全。”业内人士坦言。

首先是决策的规则。

2017年，Mobileye发表了一篇学术论文，提出了责任敏感安全(RSS)模型，为自动驾驶汽车安全决策模型提供了一个数字化的框架，这是一种可验证的数学方法来证明软件的安全能力。

RSS使用一套透明和可验证的数学公式和逻辑规则，定义了常识性的驾驶员行为特征，作为一个独立于基于人工智能的决策者的层运行。

比如，对于和前车的距离，在RSS中，将此规则形式化为数学计算。这意味着当两辆车之间的距离小于dmin时，自动驾驶车辆将做出适当的反应：比如提前制动，直到恢复安全的距离或直到车辆完全停止。

还有常见的Cut-in场景，如何保持安全横向距离；还有很多因素都会影响传感器的能见度，比如行人从路边的停泊车辆中穿过马路，为了确保安全，自动驾驶汽车将不得不做出类似的假设，并在可能的遮挡区域保持谨慎的规划决策。

此外，对于最后一道安全防线——紧急制动， RSS可以使用公式来帮助车辆提前预警，并采取更为合理的刹车制动，保持一个合理的刹车缓冲区，而不是采取最大的制动力。

行业内还有一系列的相关标准来为自动驾驶设定安全机制。

比如，ISO/PAS 21448以及SOTIF（预期功能安全），其中，ISO 21448适用于需要适当的态势感知以确保安全的功能，该标准关注的是在没有故障的情况下保证预期功能(SOTIF)的安全性。

ISO 21448是对传统车辆功能安全标准（ISO 26262）的补充，后者涵盖了系统故障时的功能安全，但不包括没有系统故障的安全隐患。ISO 21448则是在没有系统故障的情况下确保安全。

这意味着，使用ISO 21448将是确保人工智能能够做出正确决策和避免安全隐患的关键。SOTIF的目标就是减少潜在的未知的、不安全的条件。

此后，更多的汽车制造商、芯片供应商、软件及系统供应商、政府监管机构等等陆续启动自动驾驶安全标准的制定，以及一个可用于评估和验证自动驾驶汽车安全性的指标。

比如，全球首个自动驾驶产品评估的商业化安全标准——UL 4600，包括在无人驾驶的情况下评估系统的安全原则和流程，涉及设计过程的风险分析和与安全相关的测试、工具鉴定、自主验证、数据完整性和非驾驶员的人机交互等等。

UL 4600还提出了在潜在的非结构化环境中进行传感的硬件和软件的可靠性问题。它还包括对关键功能的机器学习的风险分析和验证的规定。

事实上，到目前为止，自动驾驶模式下涉及的事故大多是由软件和系统设计或工程缺陷引起的，而不是E/E故障或者失效。随着人工智能和深度学习的使用增加，验证软件功能安全性变得更加复杂。

从自动驾驶的产品层面来看，量产除了要兑现承诺的自动驾驶功能，还要满足汽车行业电子产品的相关标准，比如IATF16949、AEC-Q100/200，整个研发流程必须遵守功能安全ISO26262、SOTIF等。

此外，针对环境感知相关的KPI要求，不仅是硬件上的产品质量达标，如振动实验，耐久性测试、耐高低温等等，还有包括软件层面的测评。在这方面，目前整个行业还缺乏权威的检测和一套完整的验证测试规则。

二、

事实上，除了硬件，在汽车软件开发中，安全性一直是至关重要的。确保功能安全仍然是自动驾驶的关键。此外，在 络安全和人工智能方面有很多需要考虑的问题。

比如，自动驾驶公司软件开发团队的编程规范和全面的测试工作，对于消除安全漏洞至关重要。这可以通过使用汽车行业认可的类似ASPICE的标准规范（汽车软件过程改进及能力评定）来实现。

到目前为止，只有一些拿到车企量产项目的软件公司才会去落实软件质量评估认证，类似的标准事实上也需要在自动驾驶领域得到落实。

过去，功能安全标准(ISO 26262)并没有考虑系统错误和软件缺陷，而ASPICE为汽车行业的软件和基于软件的系统开发定义了流程和最佳实践。

ASPICE与典型的法规和合规要求有很大的不同，因为它评估的不仅仅是生产的产品，这套标准是对一家公司进行的整体软件开发质量的评估，包括内部流程的效率和一致性。

一直以来，汽车制造商在自动驾驶软件方面缺乏经验，而自动驾驶平台供应商则缺乏开发安全关键系统软件和硬件的经验。

在今年初的一次采访中，Waymo首席执行官强调，从原型平台到量产就绪平台的转型需要安全、仿真和集成方面的丰富经验积累。“相比于硬件，将软件投入量产并符合安全法规要求的复杂性更高。”

事实上，整个自动驾驶软件开发领域，玩家更多专注于开发功能，并通过硬件的迭代推出一代代解决方案，亮点也永远都是硬件。但在内部开发软件的过程中，并没有遵循类似ASPICE和ISO等流程。

众所周知，整个AD系统的性能很大一部分取决于对感知的响应时间，而响应时间取决于代码质量、成熟度和嵌入式实现。而在大部分自动驾驶L4车辆的原型测试中，只有特征或算法作为单独的组件进行测试。

但，真正进入量产阶段，中间件组件（如Autosar、Adaptive Autosar、安全冗余组件等）将是完整软件堆栈的核心部分。在这一点上，几乎很难从自动驾驶公司的宣传中看到任何信息。

就在几天前，奥迪、Arm和大众集团旗下软件子部门Cariad等多家公司参与了一个名为“安全软件”的行业工作组，目标是为自动驾驶汽车开发一个安全的系统软件架构，服务于传感器和执行器的子系统，以确保车辆安全自动运行的故障控制。

“真正自动驾驶的商业化安全落地，将由汽车制造商、一级供应商、科技公司等多方联合力量一起参与。”上述开发小组对外声明表示。这是汽车行业的传统玩法，通过技术联盟来制定行业标准。

在这一点上，“分裂”的自动驾驶行业，尤其是争夺“硬件制高点”的初创公司恐难成气候，在这条漫长的商业化道路上，行业监管和规范是“商业化美好预期”折戟的最大风险。

如今，监管的“靴子”即将落地。

根据工信部在今年发布的《智能 联汽车生产企业及产品准入管理指南（试行）》征求意见稿，已经明确提出智能 联汽车（包括最终可实现替代人来操作的新一代汽车），需要满足生产企业及产品准入管理。

《征求意见稿》明确提出，智能 联汽车产品应满足功能安全、预期功能安全和 络安全等过程保障要求，保障车辆不存在因预期功能的不足所导致的不合理风险。