按照《中华人民共和国标准化法》和《强制性国家标准管理办法》，工业和信息化部装备工业一司组织全国汽车标准化技术委员会开展了《智能网联汽车组合驾驶辅助系统安全要求》强制性国家标准的制定。2025年9月17日开始，公开征求社会各界意见（以下简称：征求意见稿）。这份征求意见稿都规定了啥？对自动驾驶行业提出了什么要求？会对自动驾驶行业未来发展产生什么影响？
把“谁管谁的事”讲清楚
这份征求意见稿首先把“组合驾驶辅助系统”定义成在其设计运行条件（ODD）下，持续执行车辆横向和纵向运动控制，并具备相应目标和事件探测与响应能力的软硬件系统。组合驾驶辅助系统主要分成四类，即基础单车道、基础多车道、领航类和泊车类，每一类作为独立系统来规定要求和试验方法。标准适用于M、N类车辆（常见的乘用车及商用车）。整体目录除了功能与安全要求外，还把场地试验、道路试验、用户告知、系统禁用、同一型式判定、实施日期和若干规范性附录（例如仿真可信度、功能安全描述、制造商安全保障与数据记录）都系统化列出，形成“规则+验证+治理+数据”闭环。
把系统类型、ODD范围和试验方法放在同一标准里，对于自动驾驶行业来说或有两方面的现实意义。一是可以统一口径，监管与检测机构可以用同一套条目检查不同厂家的产品是否满足“能做什么/不能做什么”；二是可以促使厂商在产品设计阶段就把能力声明（比如在哪些道路、速度、能否换道、能否通过复杂路段）和对应的验证计划写清楚，避免“功能说明模糊、现场使用超范围”的风险。标准通过把试验方法也规范化，缩短了“规则—检验—整改”的闭环时间，有利于从工程端把安全做成可测量、可复现的工作。
一个组合驾驶辅助系统最容易出问题的环节就是“谁在开车”的边界不清。征求意见稿对驾驶员监测（手部和视线）以及在驾驶员不配合时的提示与接管/减灾流程做了严格规定，并给出明确的时序要求。当车辆速度大于10km/h且驾驶员视线偏离驾驶任务相关区域时，系统应在最迟5秒内发出EOR（视线回归提示）；如果视线继续偏离，要在发出EOR后最迟3秒升级EOR；在升级EOR后若视线仍未回归，系统最迟在5秒内发出DCA（立即控制警告），DCA要显著提示驾驶员立即恢复对车辆横向运动的控制；如果在发出升级的HOR或DCA后仍无响应，系统应在最迟10秒内触发RMF（风险减缓功能）。这些时间点和升级顺序都有明确的条款约束。
为什么要把这些提示和时间量化成“秒级”的硬指标？这背后其实是出于安全的考虑。人类在被提示后恢复注意力与动作需要时间，但这个时间窗口不能任意放大，太短会造成误报警、太长会让车辆进入不可控风险区。把视线/手部检测与分级提示（HOR、EOR、DCA）做成可测量的时序，便于在实验场场景复现人机不配合的极限情形，检验系统是否能在可接受风险下完成安全控制或及时触发RMF。此外，明确“RMF最迟触发时间”能给系统设计一个硬的“最后防线”，在驾驶员明确未响应时，系统必须在限定时间内把车辆带入更安全状态，不能靠模糊的人机判断拖延决策，降低因迟缓引发事故的概率。
征求意见稿还提到允许“跳过阶段直接发出DCA或RMF”，并对不同警示之间的抑制逻辑做了说明（例如在发出升级的HOR时可以抑制EOR等），这是在用户体验与报警之间的折中选择。在某些紧迫情形，系统不必按严苛流程逐级提示，而是直接进入高优先级警示或RMF；但为何允许这种跳步？因为实际路况具有突发性，标准既要保证用户有充分的纠正机会，也要允许系统在不可逆风险面前采取果断策略。
征求意见稿还要求DCA要持续到系统检测到驾驶员已恢复横向控制或系统触发RMF，并规定DCA应包括持续的光学、声学和触觉信号。这充分体现了一个原则，即报警设计需要“可感知且可信”。单一通道（比如只闪灯）在真实车内很容易被忽略或误判，把多种感官通道组合起来能提高驾驶员对紧急提示的响应概率，从而降低因信号不可见或不可闻导致的事故风险。
为什么要严格告知“在哪儿能干活”？
征求意见稿对系统的ODD要求与能力声明非常重视。厂商必须明确系统能在哪些道路类型、车速范围、车道宽度、天气光照等条件下运行，并且要有办法探测是否即将超出ODD，一旦检测到超出应提示驾驶员并可控地终止自动控制。这一条的意义在于把“能力声明”变成可执行的安全约束，若没有明确的ODD定义，用户容易把系统能力过度泛化（例如在匝道、交叉口或施工区误用），导致事故风险上升，现阶段就有很多智驾车主会过渡使用组合辅助驾驶功能，并给其他人造成错误的引导。明确ODD有助于从产品发布到用户使用形成一致预期，便于监管核查与事故责任认定。
换道等复杂动作在征求意见稿中被单独列了出来，其中要求对换道的触发条件、后向交通评估以及换道执行期间的可预期性提出限制（换道在不同触发模式下要满足更高的感知与决策要求）。换道会带来对周边车辆的影响，错误的时机或过激的横向动作可能触发后车紧急制动或碰撞。征求意见稿通过对换道行为设置更严格的感知与决策门槛，防止“系统主动换道引发连锁风险”的情形。虽然征求意见稿中把许多细则放在技术要求和试验方法里，但其核心逻辑是，越是影响周边交通参与者的动作，越要高置信度的感知与更保守的决策策略。
后向距离示意图
另外，征求意见稿中还要求系统在与AEB（自动紧急制动）等安全系统交互时不得抑制正在执行的紧急动作，并要明确控制优先级的转换策略。这说明自动驾驶并非孤立模块，它需要与车身控制、安全系统紧密协作，任何优先级冲突都可能带来灾难性后果。把这些交互写进标准，可以迫使设计者在早期就处理好模块间的接口与异常场景。
为什么要同时要求“场地+道路+仿真+数据”四管齐下？
征求意见稿把验证体系分成场地试验、道路试验和仿真试验，并在附录中专门对仿真试验的可信度评估提出规范（包括工具链管理、模型不确定性量化、验证与确认流程）。这是对当前产业实践的直接回应，随着仿真替代实车测试的比重上升，必须有统一的可信度评估办法，避免“仿真结果与现实脱节”的风险。要求仿真工具链可溯源、模型不确定性有量化说明，能促使厂商提升仿真平台的工程能力。
仿真测试可信度评估框架
场地和道路试验把关键情景和通过准则在征求意见稿中更加具体化，例如触发驾驶员脱离检测的试验方法、碰撞事件触发的要求以及对记录数据的读取与核验方式。这些试验流程的规范化会给自动驾驶行业带来两个好处，一是帮助检测方在有限的试验资源下复现关键失效场景；二是让产品设计方有明确的验证清单，从而把安全需求映射成可测试的工程任务。
关于数据记录，征求意见稿提出要把记录系统分为I型和II型，并对时间段事件与时间戳事件、记录字段、锁定与不可覆盖原则等做了规范。把记录要求写清楚目的其实非常直接，那就是一旦发生事故，完整且保真（不可覆盖）的时间序列数据是判定事实、回放决策链与改进算法的基础。没有可用数据，既无法做出技术上的责任判定，也不利于行业吸取教训。
制造商责任、用户告知与系统禁用的规范
征求意见稿不仅规范了具体技术，还要求制造商建立覆盖车生命周期的安全保障体系，其中包括安全方针、风险管理、设计开发流程、生产管理、供应商管理与持续改进机制等。这部分其实强调的是组织能力，自动驾驶系统的安全不是单一算法或单个模块的事，而是涵盖供应链、软件迭代、上线后监测与事件处置的体系工程。要求制造商在制度层面负责，是为了把技术安全上升为企业治理的核心任务，而非工程团队的孤立工作。
用户告知和确认机制也有硬性条款，例如要求车辆在静止时提供用户确认已阅读并理解使用说明的操作（可以通过账号登录与两步确认动作），并要求在最长30天未再次确认时提示用户更新。这样的规定既考虑到合规性，也考虑到用户理解能力与设备转手后的使用安全。与之配套的系统禁用规则也很严格，在当前点火周期内若发生触发RMF、或连续升级报警多次等情况，系统应被禁用至少30分钟，并提示用户重新阅读使用说明。这些条款是对“多次逃避人机责任或频繁误报”的直接治理手段，目的在于防止驾驶员过度依赖或对系统失去信任，同时强制回到人工控制与学习环节。
最后的话
把以上条款综合起来看，这份征求意见稿的方向和逻辑很清晰，把组合驾驶辅助系统的能力、边界、人机交互时序、关键安全行为与验证流程都从“工程模糊区”拉回到“可声明、可测量、可复核”的范畴。对于厂商而言，短期要求他们在感知、驾驶员监测、仿真验证与数据记录上有更多的技术投入；长期却能带来市场竞争的秩序化，让那些能把安全治理做扎实的企业在合规/信任上取得更多的优势。对用户而言，标准能带来更明确的使用说明和事故可溯源性，减少“功能过度宣传—现场误用—责任不清”的灰色地带。
-- END --
原文标题 : 《组合驾驶辅助系统安全要求》对自动驾驶行业提出了什么要求？
按照《中华人民共和国标准化法》和《强制性国家标准管理办法》，工业和信息化部装备工业一司组织全国汽车标准化技术委员会开展了《智能网联汽车组合驾驶辅助系统安全要求》强制性国家标准的制定。2025年9月17日开始，公开征求社会各界意见（以下简称：征求意见稿）。这份征求意见稿都规定了啥？对自动驾驶行业提出了什么要求？会对自动驾驶行业未来发展产生什么影响？
把“谁管谁的事”讲清楚
这份征求意见稿首先把“组合驾驶辅助系统”定义成在其设计运行条件（ODD）下，持续执行车辆横向和纵向运动控制，并具备相应目标和事件探测与响应能力的软硬件系统。组合驾驶辅助系统主要分成四类，即基础单车道、基础多车道、领航类和泊车类，每一类作为独立系统来规定要求和试验方法。标准适用于M、N类车辆（常见的乘用车及商用车）。整体目录除了功能与安全要求外，还把场地试验、道路试验、用户告知、系统禁用、同一型式判定、实施日期和若干规范性附录（例如仿真可信度、功能安全描述、制造商安全保障与数据记录）都系统化列出，形成“规则+验证+治理+数据”闭环。
把系统类型、ODD范围和试验方法放在同一标准里，对于自动驾驶行业来说或有两方面的现实意义。一是可以统一口径，监管与检测机构可以用同一套条目检查不同厂家的产品是否满足“能做什么/不能做什么”；二是可以促使厂商在产品设计阶段就把能力声明（比如在哪些道路、速度、能否换道、能否通过复杂路段）和对应的验证计划写清楚，避免“功能说明模糊、现场使用超范围”的风险。标准通过把试验方法也规范化，缩短了“规则—检验—整改”的闭环时间，有利于从工程端把安全做成可测量、可复现的工作。
一个组合驾驶辅助系统最容易出问题的环节就是“谁在开车”的边界不清。征求意见稿对驾驶员监测（手部和视线）以及在驾驶员不配合时的提示与接管/减灾流程做了严格规定，并给出明确的时序要求。当车辆速度大于10km/h且驾驶员视线偏离驾驶任务相关区域时，系统应在最迟5秒内发出EOR（视线回归提示）；如果视线继续偏离，要在发出EOR后最迟3秒升级EOR；在升级EOR后若视线仍未回归，系统最迟在5秒内发出DCA（立即控制警告），DCA要显著提示驾驶员立即恢复对车辆横向运动的控制；如果在发出升级的HOR或DCA后仍无响应，系统应在最迟10秒内触发RMF（风险减缓功能）。这些时间点和升级顺序都有明确的条款约束。
为什么要把这些提示和时间量化成“秒级”的硬指标？这背后其实是出于安全的考虑。人类在被提示后恢复注意力与动作需要时间，但这个时间窗口不能任意放大，太短会造成误报警、太长会让车辆进入不可控风险区。把视线/手部检测与分级提示（HOR、EOR、DCA）做成可测量的时序，便于在实验场场景复现人机不配合的极限情形，检验系统是否能在可接受风险下完成安全控制或及时触发RMF。此外，明确“RMF最迟触发时间”能给系统设计一个硬的“最后防线”，在驾驶员明确未响应时，系统必须在限定时间内把车辆带入更安全状态，不能靠模糊的人机判断拖延决策，降低因迟缓引发事故的概率。
征求意见稿还提到允许“跳过阶段直接发出DCA或RMF”，并对不同警示之间的抑制逻辑做了说明（例如在发出升级的HOR时可以抑制EOR等），这是在用户体验与报警之间的折中选择。在某些紧迫情形，系统不必按严苛流程逐级提示，而是直接进入高优先级警示或RMF；但为何允许这种跳步？因为实际路况具有突发性，标准既要保证用户有充分的纠正机会，也要允许系统在不可逆风险面前采取果断策略。
征求意见稿还要求DCA要持续到系统检测到驾驶员已恢复横向控制或系统触发RMF，并规定DCA应包括持续的光学、声学和触觉信号。这充分体现了一个原则，即报警设计需要“可感知且可信”。单一通道（比如只闪灯）在真实车内很容易被忽略或误判，把多种感官通道组合起来能提高驾驶员对紧急提示的响应概率，从而降低因信号不可见或不可闻导致的事故风险。
为什么要严格告知“在哪儿能干活”？
征求意见稿对系统的ODD要求与能力声明非常重视。厂商必须明确系统能在哪些道路类型、车速范围、车道宽度、天气光照等条件下运行，并且要有办法探测是否即将超出ODD，一旦检测到超出应提示驾驶员并可控地终止自动控制。这一条的意义在于把“能力声明”变成可执行的安全约束，若没有明确的ODD定义，用户容易把系统能力过度泛化（例如在匝道、交叉口或施工区误用），导致事故风险上升，现阶段就有很多智驾车主会过渡使用组合辅助驾驶功能，并给其他人造成错误的引导。明确ODD有助于从产品发布到用户使用形成一致预期，便于监管核查与事故责任认定。
换道等复杂动作在征求意见稿中被单独列了出来，其中要求对换道的触发条件、后向交通评估以及换道执行期间的可预期性提出限制（换道在不同触发模式下要满足更高的感知与决策要求）。换道会带来对周边车辆的影响，错误的时机或过激的横向动作可能触发后车紧急制动或碰撞。征求意见稿通过对换道行为设置更严格的感知与决策门槛，防止“系统主动换道引发连锁风险”的情形。虽然征求意见稿中把许多细则放在技术要求和试验方法里，但其核心逻辑是，越是影响周边交通参与者的动作，越要高置信度的感知与更保守的决策策略。
后向距离示意图
另外，征求意见稿中还要求系统在与AEB（自动紧急制动）等安全系统交互时不得抑制正在执行的紧急动作，并要明确控制优先级的转换策略。这说明自动驾驶并非孤立模块，它需要与车身控制、安全系统紧密协作，任何优先级冲突都可能带来灾难性后果。把这些交互写进标准，可以迫使设计者在早期就处理好模块间的接口与异常场景。
为什么要同时要求“场地+道路+仿真+数据”四管齐下？
征求意见稿把验证体系分成场地试验、道路试验和仿真试验，并在附录中专门对仿真试验的可信度评估提出规范（包括工具链管理、模型不确定性量化、验证与确认流程）。这是对当前产业实践的直接回应，随着仿真替代实车测试的比重上升，必须有统一的可信度评估办法，避免“仿真结果与现实脱节”的风险。要求仿真工具链可溯源、模型不确定性有量化说明，能促使厂商提升仿真平台的工程能力。
仿真测试可信度评估框架
场地和道路试验把关键情景和通过准则在征求意见稿中更加具体化，例如触发驾驶员脱离检测的试验方法、碰撞事件触发的要求以及对记录数据的读取与核验方式。这些试验流程的规范化会给自动驾驶行业带来两个好处，一是帮助检测方在有限的试验资源下复现关键失效场景；二是让产品设计方有明确的验证清单，从而把安全需求映射成可测试的工程任务。
关于数据记录，征求意见稿提出要把记录系统分为I型和II型，并对时间段事件与时间戳事件、记录字段、锁定与不可覆盖原则等做了规范。把记录要求写清楚目的其实非常直接，那就是一旦发生事故，完整且保真（不可覆盖）的时间序列数据是判定事实、回放决策链与改进算法的基础。没有可用数据，既无法做出技术上的责任判定，也不利于行业吸取教训。
制造商责任、用户告知与系统禁用的规范
征求意见稿不仅规范了具体技术，还要求制造商建立覆盖车生命周期的安全保障体系，其中包括安全方针、风险管理、设计开发流程、生产管理、供应商管理与持续改进机制等。这部分其实强调的是组织能力，自动驾驶系统的安全不是单一算法或单个模块的事，而是涵盖供应链、软件迭代、上线后监测与事件处置的体系工程。要求制造商在制度层面负责，是为了把技术安全上升为企业治理的核心任务，而非工程团队的孤立工作。
用户告知和确认机制也有硬性条款，例如要求车辆在静止时提供用户确认已阅读并理解使用说明的操作（可以通过账号登录与两步确认动作），并要求在最长30天未再次确认时提示用户更新。这样的规定既考虑到合规性，也考虑到用户理解能力与设备转手后的使用安全。与之配套的系统禁用规则也很严格，在当前点火周期内若发生触发RMF、或连续升级报警多次等情况，系统应被禁用至少30分钟，并提示用户重新阅读使用说明。这些条款是对“多次逃避人机责任或频繁误报”的直接治理手段，目的在于防止驾驶员过度依赖或对系统失去信任，同时强制回到人工控制与学习环节。
最后的话
把以上条款综合起来看，这份征求意见稿的方向和逻辑很清晰，把组合驾驶辅助系统的能力、边界、人机交互时序、关键安全行为与验证流程都从“工程模糊区”拉回到“可声明、可测量、可复核”的范畴。对于厂商而言，短期要求他们在感知、驾驶员监测、仿真验证与数据记录上有更多的技术投入；长期却能带来市场竞争的秩序化，让那些能把安全治理做扎实的企业在合规/信任上取得更多的优势。对用户而言，标准能带来更明确的使用说明和事故可溯源性，减少“功能过度宣传—现场误用—责任不清”的灰色地带。
-- END --
原文标题 : 《组合驾驶辅助系统安全要求》对自动驾驶行业提出了什么要求？
