正确的自动驾驶“安全观”应是什么样子？
前言
自动驾驶比人安全的论述主要是站在自动驾驶解决了由人类缺陷引发的事故的角度上，进行分析得出的结论，但论据并不全面。诚然，人类驾驶员有诸多缺陷，但其优势也是现有自动驾驶算法所无法比拟的，比如对行人及其他驾驶员面部表情、手势的理解，这是自动驾驶短期或者永远也无法达到的能力，而正是这样的能力使得车辆在混杂的路口穿梭自如，避免了因不必要的交互风险而造成的交通事故。对比露出在水面的冰山（事故），我们更应关注那些被人类合理处理掉的沉在水面下的冰山（安全风险）。
自动驾驶并非一个传统意义上可以无限试错的“手机APP”，其安全基线就是要能替代人类处理路上千奇百怪的行驶风险。自动驾驶不是可以“任性甩锅”的辅助驾驶功能，其开发商将从交通运输工具提供商转变为直接交通事故责任者以及整体交通协调的责任者，既要考虑自车安全，又要兼顾整体交通的安全和效率。这种改变也使得原有的汽车和驾驶员管理相关部门的职能交织在一起，因此，自动驾驶就需要应对适应各方管理要求。
在美国交通部发布的自动驾驶安全愿景2.0中，就提到了13种企业需要声明的安全要素，分别是：系统安全、ODD、OEDR、接管（最小风险状态）、验证方法、HMI、车辆网络安全、耐撞性、事故后行为、数据记录、消费者教育与培训及对国家、洲和地方法规的遵守。美国政府鼓励自动驾驶公司按照这13个要素阐述企业的实际情况。虽然目前NHTSA网站中已有多达28家企业提交了安全报告，但报告内容相似度较高，内容也都比较空洞。
驾驶能力的最优实践是由低概率故障水平的车+有概率性错误的人类组成的驾驶水平。“依靠企业最优实践提出自动驾驶安全要求”这条路貌似很难走通，自动驾驶的安全要求不仅是个研发技术水平问题，更是从社会接受度、法规、权责等角度综合讨论得出的对企业开发管理流程和质量的要求。
在联合国WP29中，FRAV综合各国的自动驾驶安全理念，总结了五大类安全领域：DDT性能要求、与用户间交互安全、极端情形处理、系统失效处理、生命周期管理，并在最新的guideline文件中加入了多支柱法与五类安全领域的测试验证关系的阐述。我国工信部发布的《智能网联汽车生产企业及产品准入管理指南（试行）》（征求意见稿）则综合了网络安全、功能安全、预期功能安全、合理可预见和可避免、数据安全、OTA管理、ODC识别与应对，以及多支柱验证方法等要求。
相关企业应该在多种已经形成基本共识的安全视角下分析自动驾驶带来的收益，满足多领域的安全管理规则，才能真正证明所开发的自动驾驶功能是安全的。本文将对各国现有的关于自动驾驶评价的基本共识和热点，进行介绍和讨论，以供读者参考。本文主要围绕运行在开放道路的自动驾驶功能展开，其他区域运行的自动驾驶功能亦可参照。
功能安全
功能安全广泛存在于电子电器系统安全设计中，但落实到自动驾驶企业中却往往仅保留了系统冗余的概念，这是理解上的重大偏颇。功能安全是一套为降低电子电气安全相关系统故障引起的危害而开发的管理体系，并不是说企业做了冗余功能设计就可以满足功能安全要求。自动驾驶系统也是一种安全相关系统，因此企业应满足汽车安全生命周期相关阶段的功能安全活动流程要求，符合汽车安全完整性等级对应流程的规定，证明自动驾驶有能力处理故障导致的可避免的不合理风险。
类比人类驾驶员+车的组合体，企业应通过功能安全，回答在自动驾驶系统故障和车辆故障的情况下能够将总体剩余风险（P=E*C*S）降低到现有车辆故障和人类驾驶员不可抗力条件（如突发心脏病）下的风险水平。
关于故障曝光率，以现阶段工业水平，电子产品的可靠性还远远达不到人类的可靠性水平。由于人类身体原因（排除疲劳驾驶等不良行为）影响不能正常驾驶的事件是微乎其微的，而即便是发展了几十年的电脑手机等产品，死机概率仍居高不下，更何况新兴的“汽车驾驶机器人”。因此业界的普遍认知是通过对车辆结构进行冗余，提高自动驾驶+车辆的整体故障曝光率（E），以降低风险概率（P）。
关于可控度C是很难评判的。在不改变当前社会车辆的结构下，对于L4级自动驾驶系统故障曝光率（E）就需要达到人类驾驶员同等的“身体健康”水平，并且能够合理有效处置车辆故障时情况（可控性C）。而对于L3级自动驾驶系统则较为复杂，因为L3级系统车上仍存在人类驾驶员，在设计分析过程中，需要对故障进行合理分级：何种只需要提醒，不需做DDT响应；何种可让驾驶员接管，长时间不接管进入MRM；何种直接进入MRM并同时发出接管请求。宗旨是在自动驾驶与人类驾驶员协同时，不留存不合理风险给人类驾驶员及其他交通参与者，特别在极端情形下需要有能力处理。
网络安全
网络安全是指汽车的电子电气系统、组件和功能处于被保护、不受网络风险威胁的状态。自动驾驶功能区别于人，会受到内外部的网络攻击，由此带来安全隐患，这是区别于人类驾驶新增的安全风险，暂无明确可参考的接受准则。
企业应先参照ISO21434制定网络安全防护机制，定期开展网络安全风险识别、分析评估和管控网络安全风险，及时消除重大网络安全隐患；建立网络安全监测预警机制，采取监测、记录、分析网络运行状态、网络安全事件等技术措施；企业应建立网络安全应急响应机制，制定网络安全事件应急预案，及时处置系统漏洞、网络攻击、网络侵入等安全风险。
预期功能安全
预期功能安全最早是针对驾驶员误用滥用而提出的开发流程要求。而自动驾驶功能，由于ODD的约束，理论上是不存在驾驶员误用滥用问题。如何将其方法论应用于自动驾驶，笔者认为主要有两点。
第一，预期功能安全适用于基于已知功能策略性不足造成的危害场景（非能力边界问题），通过合理泛化，驱动研发开发新策略对危害场景进行全覆盖。图1第一个圈的开发模式就是目前行业常用的数据驱动型，也就是基于问题数据的回归式开发。第二个圈则是在已知危害场景周围进行泛化，测试新的功能，验证其对已知问题的解决程度，并将更多未知问题变为已知问题，并进行下一轮迭代。这也就是常说的通过压缩第三象限达到让功能不足风险最小化的基本思想。
图1 基于预期功能安全理念的开发测试迭代模式（图片来自21448）
随着迭代次数增加，该功能的剩余风险会呈现锯齿状的降低，当达到验证目标，企业即可终止迭代过程，发布该功能。验证目标也需要通过跟人类驾驶水平相比较进行确定。比如行人礼让功能的验证目标可以设定为人类驾驶员发生一次不合理礼让行人的平均行驶里程。
第二，预期功能安全方法论与功能安全类似，同样适用于自动驾驶算法缺陷的概率性问题的开发管控，其在功能安全的ECS概念基础上再引入危害事件概率。举例来讲，对信号灯的感知无论多么优秀的算法总会存在概率性的将红灯识别为黄灯的风险，在这种已知风险下，自动驾驶如何能够安全合规地通过路口，企业可通过采用V2X获知前方信号灯相位、同时识别垂直车道信号灯状态、通过相邻车道车辆行驶状态等多种策略保证在该场景下满足安全目标，并且通过仿真、路测、运行监控证明其对安全目标的符合性。在该实例下，安全目标我们可以设定为自动驾驶需要低于人类驾驶员闯红灯的概率。同样与人进行对比，企业通过预期功能安全，能够将由算法缺陷概率性问题带来的风险降低到人类因走神粗心等不确定错误行为导致风险的同等水平。
研发过程中企业会遇到无论如何开发，问题的应对水平也到不到人类能力基准，那么对该问题就应通过ODD予以约束。比如，上述信号灯识别问题，若企业引入V2X信息后可以满足预期功能安全要求，若无V2X信息则无法满足，但企业不能期望所有路口均拥有V2X设施。因此V2X将作为ODD的要求元素之一，如果前方路口不能提供V2X的信号灯信息，L3级自动驾驶应在路口前提前提醒驾驶员接管。
针对已知危害事件，企业均需有相应的预期功能安全开发流程。针对未知危害场景，企业目前尚未有良好的研发和测试策略予以应对，需要建立完善的收集、评估、限制开启、开发应对等响应机制，保障车辆不存在因预期功能的不足而导致的不合理风险。
上述两种预期功能安全的应用领域，验证目标均是以剩余风险概率来衡量。但预期功能安全并不能解决自动驾驶正常状态下能力边界的开发管控。
预期行为安全
对于“水下冰山”，我们也需要定义自动驾驶能力可接受的准则。目前行业共识是自动驾驶需要避免设计运行范围内合理可预见且可避免的事故发生。这就与剩余风险的接受准则有明显的差异：风险量化方式是概率，能力量化方式是参数范围。
至于为什么约束是在“设计运行范围内”而非“自动驾驶运行过程中”，我们会在下文的ODD的安全性要求中单独讨论。
合理可预见这是对“水面下”所有情形的语义级量化。这就引出了基于场景的自动驾驶能力评价，参考标准是ISO34502。其通过对道路实际情形的采集，统计得到逻辑场景的参数分布统计值，通过“小概率事件”概念找到合理可预见的参数范围。在34502中，用广泛意义上的切入场景为例，介绍了两参数联合分布区间统计方法，给出3倍标准差和5倍标准差作为参考合理可预见的量化。企业应用该标准时，需要进一步细化功能场景，避免功能场景宽泛，导致参数范围过大，造成自动驾驶能力的过约束。从实际企业应用实践来看，路上的切入行为可以进一步细分，如慢速切入，快速切入、慢速切入后制动、切入中止等行为。通过对每一种危险交互行为进行参数边界刻画，可以降低对自动驾驶能力的过约束程度，并降低测试验证的成本。
图2 慢速切入场景参数空间示例（图片来自34502）
参考模型是注意力集中的一般驾驶员。一般驾驶员尚没有明确定义。本文推荐是具备防御性驾驶能力、能够灵活遵守交规、可采取多种规避风险手段、反应生理指标为大数据统计样本均值的驾驶员。在UNECE R157（ALKS）法规中仅介绍了一般驾驶员的反应生理指标确定方法。但并未对前三个驾驶能力特点予以界定。
防御性驾驶能力：当代社会防御性驾驶能力已经是一般驾驶员的普遍要求。人类驾驶员可对周围环境进行提前10s的意图预判，比如道路前方公交车站有静止公交车开启左转灯，那么对于该情景的预判是，公交车将要起步向左进行变道，社会车辆人类驾驶员的正确动作是在公交车起步前，及时制动让其变道，或者自车向左进行变道。
能够灵活遵守交规：在交规中有层级关系，为避免事故发生或为特殊车辆让行的情况下，人类驾驶员可以突破交规其他条款要求。
可采取多种规避风险手段：在UNECE R157，驾驶员对于切入场景的应对措施为制动跟随，但真实人类驾驶员规避手段还有鸣笛、灯语、变道等手段；这些手段均需要进行建模评价。
如果自动驾驶能够在合理可预见的场景下，达到上述一般驾驶员避免风险的水平，则可判定满足了预期行为安全要求。
交规符合性
提高交通流整体的协调性，才能有效提高道路的交通安全水平。协调性的提升需要长时间的法规、教育和社会引导。为保持协调性的稳健提升，政府不可能，也不应该因为自动驾驶发展轻易改变既定且合理的交通规则。
自动驾驶功能的设计应考虑交通流行为模式，不可特立独行。驾驶辅助功能往往仅关注车辆的横纵向控制（包括那些高级驾驶辅助功能），但自动驾驶功能充当了驾驶员的角色，它需要能够理解其他道路使用者的灯语、鸣笛、特殊行驶权力等，并做出相应的决策响应。原则上，作为道路交通行为的参与者，自动驾驶功能应遵循所运行区域的交规项。但以现有感知和规划决策研发水平看，想实现这一原则具有非常大的挑战性。举例来说，交规要求对警车、救护车等应急车辆让行。为实现该行为要求，自动驾驶功能首先应识别到周围存在的应急车辆，并且能够判断其是否在执行公务，之后判定自车是否有让行的可能性。让行的可能性的判定较为复杂，若自动驾驶车辆是阻碍应急车辆行驶的关键要素，那么自动驾驶车辆哪怕违反信号灯等要求，也要为应急车辆挪出通行空间。当完成让行义务后，应立即停止其他违规行为。这一要求虽难，但却可以实现，尤其对于L4级来说，是必须要实现的。
有些交规要求则在短期内看，是无法实现的，比如按交警指挥行驶，这需要感知实现对非标准手势的精准识别，如图3所示。对于此类难以实现的要求，自动驾驶设计过程中，可通过ODD，与驾驶员和远程协调员进行良好配合以满足交规。比如，ODD中可将交警作为其中一项要素，当ADS识别到交警在其行驶范围内，就发出接管请求，由驾驶员或远程协调员接管控制。这样既满足了交规要求，又保证了行驶安全。
图3复杂情形下交警非标准手势指挥交通（图片来自网络）
有些交规项约束的行为无法清晰量化，如路口通行优先权。实际路口交通事故，往往是由于博弈失败造成的，交警通过通行优先权能够较为清晰判断何方为主责。但对于自动驾驶工程师而言则很难把握到底何种程度的让行，才算是从前因满足了要求，而非后果。这需要不同部委协调将某些主观条款进行客观化，让自动驾驶的开发及验证需求明确。基于后果的判定，仍由实际运行结果进行定责，并由算法的优劣和保险来综合承担博弈的风险。
自动驾驶即使完全遵守了交规，也需合理应对在路上合理可预见的违规社会车辆。这点也是预期行为安全需要覆盖的内容。
有人可能会说，如果按照严格交规行驶在路上，自动驾驶车辆无法在开放道路上行驶。诚然，部分交规条目设置较为严苛，比如安全距离、超车对于开启转向灯时长要求、不能连续变道等要求。这些要求在人类驾驶员开车过程中也并非严苛执行，需要综合周围环境灵活执行。比如一个设置不合理路口，如图4所示，从A点进入主路的车辆需要在前方路口从B点左转，其需要跨越多个直行道才可到达左转道，按照不能连续变道的行为要求，那么车辆仅能用近乎泊车的操作方式行进，在交通拥堵的情况下，这种方式还可以接受，但如果此路段上没有与主车交互的社会车辆，却仍需蠕行前进，那么这条交规约束就显得很不合理。这需要公安部门连同相关研究院所和自动驾驶企业进行科学分析，对道交法进行合理修正。
图4交规与实际道路冲突示意（图片来自青岛交警）
ODD合理性
ODD的提出对驾驶自动化分级甚至自动驾驶产业发展有重要作用。
一是，ODD是区分L5与L3、L4的重要依据，ODD的宽泛与否直接显示了自动驾驶应对复杂环境的能力水平。
二是，ODD定义了跟用户间交互的边界。对于L2来说ODD无异于免责条款，只需要将不适用工况写到ODD中，并提前对用户进行告知，即可免除产品缺陷的责任，核心原因是L2及以下，人类驾驶员承担了环境感知的主体责任。受此种观念的影响，最初L3要求发出接管请求驾驶员就有责任义务去做接管动作。其思维模式还是从企业角度撇清由于设计不足导致的责任问题。但到达L3以上时，我们应该从用户角度思考接管，用户不应承担设计不足的不合理风险。自动驾驶功能承担了运行过程中所有的感知职能，包含对ODD的感知。正是因为重要，ODD的识别与响应才被工信部准入指南意见列为第一位要求。
UNECE R157中将ODD的识别与响应要求分为了两大类事件：计划事件和非计划事件。针对计划事件，系统需在该事件发生前留足充足的接管时间，即使在驾驶员不接管的情况下，也要通过MRM，避免计划事件的发生。举例来说，某功能不能实现匝道行驶，由于匝道入口是可以提前预知的，因此该功能在接近匝道入口时，应提前发出接管请求。针对非计划事件，系统识别到该事件发生后应发出接管请求。举例来说，某功能不能实现在能见度低的情况行驶，由于大雾天气是不可以提前预知的，因此该功能在识别到能见度低于一定程度后，应提前发出接管请求，即非计划事件已经发生，再进行ODD相关的响应动作。
在研的ISO 34503标准将采用分层的方式给出ODD描述的规范性话术。对于ODD的描述，笔者有三点建议。
首先，不将交通参与者作为ODD要素。在公开道路上，我们无法约束交通参与者的种类，即使在高速公路，仍然会有沿路行驶的道路养护工人、发生事故后去摆三角警示牌的驾驶员等出现。这类情况要由预期行为安全来覆盖，不能通过ODD予以免责。
其次，ODD的要求应能符合要素的状态存在变化的实际情况，合理设定“不要求、不允许/允许、计划事件、非计划事件”。比如图5，路面铺装状态，在大家普遍认知下，该状态可以以固定值写在地图文件中。但某段路面铺装状态可能经过一个晚上就会发生变化，由铺装路面变成全部非铺装。本来自动驾驶功能在该路段是可以行驶的，由于该变化，在依靠地图确认ODD的技术路线下，标注状态未变更时，自动驾驶功能将会在此路段驶出ODD，此时应识别到超出ODD，并做出相应的响应，即非计划事件发生。如果地图标注信息更新，那么，ODD针对该路段的铺装状态由不要求变为计划事件，之后车辆再行驶到此路段，就应按照计划事件要求进行响应。
最后，计划事件和非计划事件的划分是在不具有换道功能的前提下提出的。针对更广泛的自动驾驶功能，我们需要综合考虑通行空间，设定计划事件和非计划事件响应要求。还以铺装状态为例（图5），如果一段道路同向存在多条通行车道，若存在一条车道的状态由铺装变为非铺装，若自动驾驶功能能够依靠地图标标注，获知可通行车道，在该路段提前变道驶入铺装车道，那么依然可以作为“不要求”，不需进行ODD边界相关的响应。
图5 地图标记状态与ODD响应要求示例
企业需要证明针对所有涉及ODD边界的要素的感知手段可靠合理，及响应方式满足计划事件和非计划事件要求，不留存不合理的风险，可采用预期功能安全的分析方式。
回到我们在预期行为安全部分留存的话题：为什么约束预期行为安全是在“设计运行范围内”而非“自动驾驶运行过程中”。原因是，当遇到非计划事件时，自动驾驶车辆已经超出了ODD，但仍处于自动驾驶运行过程中，此时安全风险激增，我们只能要求自动驾驶进入到MRM，无法要求其仍能实现正常状态下的驾驶能力即预期行为安全。
人机交互安全
人机交互环节主要涉及驾驶员主动干预、HMI、接管请求、驾驶员状态监控等。国际的FRAV和国内的国标自动驾驶功能通用技术要求都针对各交互环节提出了技术要求，以保证安全。企业开发相关功能应证明满足相关要求。本文不对相关要求进行复述，仅抛出几个未解的原则性难题。
主动干预时，自动驾驶功能是否立即退出？笔者认为，短期内自动驾驶对风险的判断能力难以达到老司机的水平，除非企业能通过其驾驶脱离数据，证明由人干预导致碰撞的风险水平要比自动驾驶显著高。如果这种水平真的已经达到了，公开数据也是一件对企业市场反响有极大利好的事情。但到目前为止，众多企业对脱离数据进行高度封锁。由此可知，人类的决策依然在大多情况是合理的。在该推断下，如果发生主动干预，自动驾驶功能应将驾驶权立即交还给人类驾驶员。这样也能够避免人机共驾状态下责任界定不清的问题，干预后责任应由人类驾驶员承担。
接管请求发出后，驾驶员是否应被要求立即接管？在最初的SAE J3016中，L3级自动驾驶功能发出接管请求后，驾驶员有义务立即接管。但随着行业发展，人们对自动驾驶理解日趋深入，再将接管中不合理的风险留给驾驶员就是企业不负责的表现。从“ODD合理性”一节中，我们可以看出，无论是非计划事件还是计划事件，只是要求发出接管请求，接管前风险的承担者仍是企业。驾驶员接管后，责任逻辑和干预时一样的，接管点后，自动驾驶立即退出，驾驶权和责任交还给驾驶员。如果接管请求发出的不合理，留存了人类驾驶员也无法处理的风险，则证明企业在设计之初就存在严重问题，驾驶员也不应被强加接管义务。人类驾驶员应出于流畅驾驶体验和补充自动驾驶功能策略性不足（比如不能在V2X装置的红绿灯路口通行）等原因收到请求后自愿择机接管，而非接管处理自动驾驶存留的不合理风险。
我国创新性地将驾驶员状态作为自动驾驶激活与运行条件之一，提出了驾驶员状态+ODD的ODC概念。那么，是否任何驾驶员均可以激活自动驾驶功能呢？笔者认为，需要经过专业培训后的驾驶员，在熟练知晓自动驾驶功能的激活/接管/干预/MRM等基础概念和操作后，才可激活自动驾驶功能。为实现这一要求，企业在销售车辆时，需对驾驶员进行售后培训。自动驾驶功能的驾驶员状态监控也不仅仅监控驾驶员的疲劳状态，还需确认当前驾驶员是否经过培训，是否拥有开启功能的权限。
另外，自动驾驶功能有义务提供用户接管或者干预的所有驾驶条件，包括合适的照明范围与强度、干净的挡风玻璃、合适的后视镜角度等。并且，能在此基础之上，提供接管和干预时机的安全风险提示，这是在用户驾驶安全性水平上的附加功能，其收益与预警功能的辅助驾驶相同。
通过上述问题的讨论可以看出，合理组织人机交互，让驾驶权责清晰，是保证安全的先决条件。行业仍需进行广泛讨论并验证合理的人机交互方式，为功能标准制定和法规完善做出贡献。
事故相关功能要求
从众多驾驶辅助事故中我们可以看到自动驾驶运行数据和事故数据记录的重要性，对于未来自动驾驶更是如此。交警需要基于该数据判定事故与违规责任承担方，市场监督管理局需要基于该数据判定自动驾驶是否存在质量缺陷，工信部需要据此后置性评判企业准备准入材料的真实性。
企业需要按照DSSAD标准和GB 39732—2020 汽车事件数据记录系统记录下相关内容，并且应满足数据存储测试要求，包括：数据触发条件试验、数据正确性试验、数据存储能力试验、存储覆盖试验、断电存储试验等。存储的数据应能被正确读取，且应能防止数据被篡改、伪造或恶意删除。
按照现行交规要求，在事故发生后，应停车对受伤人员进行施救。自动驾驶功能应能发现自车发生了事故，并在自车情况允许的条件下，控制停车，保留事故现场。如若不能实现该能力，则会带来肇事逃逸的严重后果。
参考美国耐撞性安全要素，自动驾驶功能不应降低现有主被动安全标准约束下的安全性水平。如果制造商不改变现有驾驶舱布局、主动安全参数设置，这点要求不难达到。但现有L4方案提供商提出了拿掉方向盘或者调转座椅的方向等概念，这就需要重新对气囊安装位置、起爆时间进行标定。企业如果想做到高于此基准要求，那么就要将自动驾驶功能、主被动安全联合开发，精准降低碰撞损伤程度。
OTA升级管理
车辆全生命周期运行的自动驾驶功能原则上应与最初准入采用的版本一致。但考虑到未知不安全的缺陷需要长时间验证，社会接受通过软件升级解决未知不安全问题。但企业也需要担起升级管理的规范化问题。
企业应制定软件升级从设计、开发、测试、发布、推送等过程的标准规范，并遵照执行。企业应对软件升级可能影响的功能和性能进行测试和验证，确保符合相关法规、标准和技术要求。具体要求可参看WP29中关于OTA的讨论文件。
生命周期管理
车辆并非手机，电脑，它要求在其全生命周期中，性能应保持在相对稳定且一致的状态。传统车辆在长时间运行后，制动系统、悬架系统、驱动系统等参数均会发生小幅度的变化，但仍能通过合理养护，保证通过年检要求。
自动驾驶功能仍然搭载在传统车辆结构之上，应能够适应这些参数的变化，并保持对上述各项安全要求的符合性。适应的方式可以是能够识别到参数的变化，并对自动驾驶功能进行自适应调整，或者是在自动驾驶功能设计之初就对各项要求增加一定的安全系数，亦或者是在参数变化到一定程度，提醒用户进行维修养护。
另外，自动驾驶功能在车辆上安装了独属于自己的部件。企业在开发过程中也需要考虑部件老化、疲劳、标定参数变更等影响。
测试验证方法
我国汽车领域标准制定方式往往是将一个新功能的性能要求和对应试验方法写在同一个标准中，这方便了企业研发和第三方测试实施。但自动驾驶功能要求涉及了太多方面，如果将所有试验方法都写出来并不现实。国内借鉴多支柱法理念，分别制定了仿真（起草中）、封闭场地（发布）、实际道路（征求意见）三项标准。
封闭场地国标的思路与传统ADAS标准一致，挑选了典型功能和危险场景作为测试项，很难约束自动驾驶的安全基准。实际道路测试标准基于小概率事件在较短试验时长中不应发生的假设，选取覆盖典型要素的试验道路，进行72小时自动驾驶功能“连续”测试，通过的核心要求为无故障、无干预、无事故、无违规、无明显不合理行为。该标准确定了一个合理门槛，但也只能供第三方使用。
自动驾驶开发企业在量产时会声明满足了上述十个方面安全要求，但各方面仍需要科学的证明方式，企业需说明其保证达到要求所采用的测试评价方法与工具以及最终评价结论，比如功能安全需要做FEMA和故障注入，预期功能安全需要做HARA和基于数据驱动的问题全覆盖测试，预期行为安全需要进行基于场景和驾驶员的能力比对测试等。如果自动驾驶引发了上述要求相关的事故，政府也需要企业依据声明的测试评价方法与工具，提供更详细的自证明材料证明研发测试的充分性与真实性。
行业需要针对上述安全要求（包括国标通用技术要求的每一条）形成能满足测试充分性的最优实践方法，使得各项功能、性能评价规范在同一对话纬度上，也可为各部委的准入提供格式一致的证明材料。
总结
企业需要认真思考，务实实践上述十点安全要求，遵从并高于相关标准法规，从功能实现、开发流程等多个维度，脚踏实地提升自动驾驶能力，保证自动驾驶安全。
本文重点阐述了可造成事故风险的安全话题。自动驾驶还需依法保护个人数据安全，在此，就不继续讨论了。
上述各点内容介绍并不全面，大家可自行阅读本文参考文献，找到每一点更细致的要求。本文仅为打破多年来行业空谈“自动驾驶比人安全”的陈旧理念，促进行业树立正确的自动驾驶安全观，实事求是提升自动驾驶安全能力。文中观点意在抛砖引玉，并非定论，如有不妥，欢迎同行多交流指正。
安全类别 |
核心内涵 |
企业应对方法 |
待解决问题 |
相关管理部门 |
功能安全 |
管控由硬件或者软件故障导致的风险 |
GB/T 34590 |
风险可接受程度量化 |
公安、质检 |
预期功能安全 |
管控算法缺陷的概率性风险 |
ISO 21448 |
缺乏算法缺陷普遍认知 风险可接受程度量化 |
工信、质检 |
预期行为安全 |
管控应对交互行为的风险 |
ISO 34502 |
缺乏对交互行为系统梳理 缺乏多种人类驾驶模型研究 |
工信、质检 |
网络安全 |
避免网络攻击造成人身财产损失 |
ISO21434 |
-- |
国安、工信、公安 |
交规符合性 |
与人类驾驶车辆同规同权 |
道交法 |
修改不合理的交规 路权等法规需要量化，哪些范围属于合理可接受的博弈 |
公安，交通部，工信部 |
ODD合理性 |
ODD边界需要自动驾驶功能识别与应对，保证不将不合理风险留给用户 |
ISO 34503 |
ODD边界处理的合理性判断原则 |
工信部、交通部、公安、质检 |
人机交互安全 |
给用户良好的使用体验 |
ALKS |
干预后驾驶权交接 接管是否是义务 驾驶员激活权限确认 |
公安、保险 |
事故相关功能要求 |
能确定责任，能识别事故并停车，不降低耐撞性 |
待增补 |
工信部，公安 |
|
OTA升级管理 |
修复未知不安全的缺陷，不对其他安全要求阐述影响 |
讨论中的OTA国标 |
质检，公安 |
|
生命周期管理 |
能够合理应对系统参数变化 |
待增补 |
公安 |
|
数据安全 |
合法合规使用数据 |
数据安全法 网络安全法 个人信息保护法 |
国安、工信、公安 |
参考文献
1. 自动驾驶汽车交通安全白皮书
2. AUTOMATED DRIVING SYSTEMS 2.0: A VISION FOR SAFETY
3. 《智能网联汽车生产企业及产品准入管理指南（试行）》（征求意见稿）
4. GB/T 34590 道路车辆 功能安全
5. ISO 21434 Road vehicles — cybersecurity engineering
6. ISO/DIS 21448 Road vehicles — Safety of the intended functionality
7. ISO/DIS 34502 Road vehicles - Scenario-based safety evaluation framework for Automated Driving Systems
8. ISO/AWI 34503 Road vehicles — Taxonomy for operational design domain for automated driving systems
9. 中华人民共和国道路交通安全法
10. Functional Requirements for Automated and Autonomous Vehicles (FRAV). https://wiki.unece.org/pages/viewpage.action?pageId=87622236
11. UNECE R157 Proposal for a new UN Regulation on uniform provisions concerning the approval of vehicles with regards to Automated Lane Keeping System
12. SAE J3016 Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Systems
13. GB/T XXXX 智能网联汽车 自动驾驶功能通用技术要求
14. DSSAD / EDR. https://wiki.unece.org/pages/viewpage.actiopageId=87621709
15. GB 39732—2020 汽车事件数据记录系统
扩展阅读
为未来道路安全有效集成自动驾驶汽车的积极方法
自动驾驶安全框架开发进展综述
智能网联汽车封闭测试场建设内容简介
道路天气数据：提高当今驾驶员和未来自动驾驶汽车的安全性
世界道路协会(PIARC)道路安全手册(RSM)
合作联系方式：18515441838，标注“合作”。
欢迎加入智能交通群！标注”加群“。
