自动驾驶汽车安全管理自主框架(三):实现案例

行人过街是自动驾驶车辆与行人之间最重要的交互场景之一。在某些条件下，行人属于易受伤害的交通参与者，与车辆发生碰撞可能导致严重的人身伤害。在一些特定场景中，碰撞可能无法避免，此时车辆应当在撞击发生前采取行动，将总伤害和受伤程度降至最低。研究表明，有38个因素可能会影响行人与自动驾驶车辆交互时的行为表现。然而，这些因素会因地理位置不同而存在差异，不同地区的文化和社会规范也会产生影响。因此，每一辆自动驾驶车辆都应当做出适当的反应，如进行通信和交互协商。这也意味着自动驾驶车辆需要具备理解行人意图的能力。

本部分文章旨在将我们提出的方法和框架应用于行人相关危害场景的检测与缓解。最终实现的系统应当能够：第一，识别场景中的相关元素；第二，推理这些元素之间的相互关系；第三，推断道路使用者即将采取的行动。此外，系统的灵活性和可重构性使其能够对各种交通场景（如不同的街道结构、交通信号、人行横道配置）做出恰当的响应。

第2小节介绍了框架各层对应元素的通用实现方式，同时详细说明了容器和知识表示的实现，以体现系统的灵活性、自适应性和可观测性。

第3小节介绍了场景的生成与分析，以及构成框架的不同容器的应用。为了进行框架的实验验证，我们将相关的安全约束作为缓解机制集成到上述容器中。我们的应用采用了一些符号化方法来理解行人意图并对其行为进行缓解，从而在运行时保障安全。初步结果表明，将该框架集成到ADCC架构的机器人操作系统（ROS）中是可行的，并且能够显著减少车辆在行人周边的不安全行为。

系统范围与系统架构

我们在推进这套框架落地的过程中，始终遵循一套通用的设计原则，它们也定义了框架里组合、自适应和知识三类核心机制的主要特点。

实现概述

嵌入式与限制性约束

系统规范

本节详细介绍我们是用哪些框架、技术和方法来实现系统行为、搭建物理设计架构并最终完成落地的，其中会重点讲解支撑整套方案实现与验证的机器人操作系统（也就是 ROS）中间件。

ROS：ROS本质上是一款中间件，既支持基于组件的软件工程开发思路，也支持发布 - 订阅这类更灵活的通信模式。因为ADCC架构本身就已经在使用ROS，所以我们可以直接沿用面向服务的思路来搭建整套技术架构。虽说目前基于ROS开发的系统还达不到面向用户开放道路运营的成熟度，但用来做原型开发和科研项目，优势非常突出：

1.ROS生态里有大量现成的功能包可以直接调用，不少包刚好能提供我们需要的基础能力，后续有需求也可以随时替换成其他方案。

2.ROS本身就是分布式的面向服务架构，推崇模块化的开发和运行模式，而非把所有功能堆砌在一起的单体架构。这种“轻量化”的设计思路，能有效避免最后开发出臃肿的单体应用。

3.它自带很多高效的开发工具，比如支持内省功能（可以查看消息载荷内容）、节点关系拓扑图，还有各类数据可视化工具。

4.ROS拥有规模庞大且活跃度很高的社区，通过ROSCON这类行业会议、官方教程和共享功能包，持续推动技术交流和迭代。

5.ROS支持多语言开发，不同编程语言编写的组件，都可以通过交互层的消息传递完成通信。

6.它的场景回放和仿真能力（比如启动文件、配置文件）是本次研究的重要支撑。我们可以基于它搭建、模拟各类场景，也能回放提前录制好的场景，既简化了实验流程，也方便对比验证不同节点的算法效果。

ROS的这些优势，和我们的解决方案设计方向高度匹配。这款面向服务的中间件本身就已经具备了微服务架构需要的基础能力，引入ROS之后，我们可以直接复用这些成熟的功能：

· 基于ROS搭建的系统，核心组成单元是节点、消息、主题和服务。在本次实现中，我们遵循ROS的行业最佳实践，直接把节点当作微服务来使用——毕竟ROS本身的设计定位，就是做细粒度的模块化系统。

· 服务注册中心支持点对点的网络拓扑结构，主节点承担服务发现的作用，让各个进程可以在运行时自动找到彼此。

· 节点之间有两种通信方式：既可以通过发布/订阅机制往主题发送消息（也就是事件流），也可以通过服务调用完成同步的事务处理。

· 配套的工具和API支持日志记录、运行状态监控，还有网络数据流可视化（也就是节点通信图），可以很方便地搭建、自定义、扩展特定接口的内省能力。

微服务架构：开源机器人基金会（非营利组织）的软件工程师Dirk Thomas，曾在ROS2 的 GitHub开源仓库中提到，无论是ROS1还是ROS2，要实现微服务都不需要额外安装任何功能包或者扩展插件，因为它的通信核心“不会对使用场景做特殊限定”。基于这个结论，把ROS节点设计成独立的微服务是完全可行的。尤其是当不同节点的生命周期不一致，或者需要做针对性的系统重构时，分开管理多个ROS节点会灵活很多。

在部署方面，Docker是Web服务和微服务领域广泛使用的部署方案，主要用来标准化开发环境。它的容器可以承载一组服务，很适合支撑持续集成、持续开发这类软件开发目标。关于ROS在Docker上的部署方式，已经有相关文献做过总结，明确提出要遵循“一个容器只运行一个进程”的原则，这和微服务架构的要求是一致的。像过去通过roslaunch或者子进程调用，在同一个终端启动多个节点的做法，是不符合这个规范的。至于用Docker实现统一部署，我们会放在后续的工作中推进。

支持可扩展性、可替换性和灵活性的设计模式：我们在开发中用到了多种经典设计模式，比如抽象模式、策略模式、装饰器模式和组合模式，大幅提升了框架物理结构实现的可读性和可维护性。设计模式一般不绑定具体的代码实现，只是给各类常见问题提供通用的解决思路，比起临时凑出来的应急方案，它的综合权衡成本更低。

编程语言：这套方案支持用Python、C++和Java进行开发。ROS中间件本身就允许使用不同编程语言编写节点，不同服务之间通过通信层交换数据，前提是要先定义好所有语言通用的ROS消息结构，再完成编译。举个实际的例子，我们可以用Python编写监控节点，用C++编写其他功能节点，同时对接运行在Java环境上的知识库。

基于SMACH包的状态机：我们直接复用SMACH包提供的模板状态机做自定义改造，不用从零开发一套带内省功能的完整组件库。这个包支持搭建完全自定义的状态机，可以自由定义状态名称、事件触发条件（比如收到指定消息，或者自定义触发规则），以及每个状态下要执行的具体操作。

基于ARMOR包的本体管理：ARMOR包提供了一个ROS服务实现，可以加载多个本体，并且能够在运行时执行类似Protegé的功能（加载、添加实例、推理、一致性检查）。

以上我们介绍了系统的约束条件和规范，提出了一个适用于框架应用和实现的可行环境。下一节将概述基于上述技术选择（ROS、状态机、本体服务）的框架实现方案。

基于模型的框架架构精细化设计的逻辑视图实现

本节按功能介绍构成框架实现的不同实例和抽象。

服务架构与容器分配

我们的框架采用微服务架构，将功能分配给不同的组件（即微服务），每个组件专注于执行其核心操作功能。图1展示了整体设计，以及微服务按其所在层（L1、L2或L3）和角色（监控、分析、规划或执行）的聚类情况。需要注意的是，图中展示的安全评估过程容器（L2）是其通用版本。此外，图1还明确了不同实例之间的主要组件交换通道（发布-订阅或客户端-服务器消息）。

图1：框架中作为服务容器的组件与组件交互关系（逻辑架构空白视图）

框架微服务的原型模板

原型模板是构成框架的微服务组件的主要抽象形式，它们有助于处理微服务底盘框架中的横切关注点。这些模板在运行时进行特化，以提供系统所需的相应能力。这些原型模板遵循组合架构模式，该模式定义了模板函数和接口，使这些机制能够被部署、组合和特化。这一节我们来讲讲框架里用到的原型模板，它具体起什么作用、有哪些能力，又是怎么实现差异化定制的。

监控、分析、规划、执行这几类功能实例，底层有不少相似、可以共用的机制。所以我们先把这些通用的规则抽出来整合到一起，给所有微服务搭了一套通用的底层结构。这么一来，系统里所有微服务都有一套我们叫「原型模板」的通用骨架，不同类型的微服务——也就是监控、分析、规划、执行这几类——只在具体能力的呈现和实现逻辑上有区别。举个例子，监控类的微服务会订阅各类不同数据源的信息，从知识库调取目标和阈值来设定评估标准，再把感知到的信息同步更新到知识库，必要的时候还会触发异常征兆。

微服务在运行时怎么实现差异化，是按照各自的逻辑来的，这些逻辑都存在知识库⾥，系统初始化的时候会统一读取。知识库⾥存的是用语义描述的各类属性：比如对外暴露的服务接口、可部署可发现可复用的声明式功能（也就是部署方案）、需求、功能和机制的说明（也就是能力属性），还有针对组件行为和组合规则的前置条件、后置条件，以及不变量规则。

除此之外，我们还设计了四类接口：一类负责和被管控资源做输入输出通信，一类是观测接口用来监控每个微服务的运行状态，一类是自适应接口由管理单元统一调度，最后一类是通过专属服务对接和操作知识库的通道。这些接口都支持扩展和装饰，可以按需给全部微服务配置，也可以只给部分特定的微服务使用。

输入输出模板接口：输入输出接口可以借助语义解释器服务，给对外暴露的服务接口做动态的语义绑定。输入输出端口既可以是固定的静态端口，也可以根据需求和语义描述做中转适配。这两类输入输出都配套了对应的语义描述，里面包含区间完整性、阈值限制、错误处理这类属性信息。

知识库模板接口：知识接口专门用来对接负责本体访问的知识管理服务。它能保证多个微服务访问本体的方式统一、数据同步，比如统一的访问方式、交互格式和日志规则。

监控模板接口：正因为原型模板是抽象的通用骨架，我们可以很方便地给组合型微服务接入监控接口。这套监控接口默认覆盖了基础的监控能力，比如心跳检测、数据一致性校验、服务性能和运行状态监控；也可以针对特定服务或者更复杂的计算需求做定制，比如监控服务质量类的属性。

自适应模板接口：框架还专门设置了自适应端口，用来落地外部下发的自适应策略。它为原型模板提供了一个接口，用于接收来自外部组件的自适应请求，以及向被管实体或资源发送自适应请求。在我们的实现中，我们将代码执行、启动和重构过程与状态机关联起来，这样自适应过程只能在"重构"状态下对服务进行配置。

原型模板顶层视图：以上我们介绍了框架运行时系统架构能力（通信、监控、自适应）的组合结构、能力继承，以及在设计阶段对其进行自定义的可能性。图2展示了使用Arcadia/Capella建模软件建模的原型模板的逻辑视图。该系统表示指定了通用微服务的结构、接口和知识访问方式，同时还显示了五个特定于角色的模型，代表微服务可以从知识服务中使用和访问的本地知识类型。知识服务将在下一小节详细介绍。

图2：构造型接口与能力（上下文内部接口视图）

知识管理服务

原型模板拥有连接到知识管理服务（KMS）的接口，用于对本体进行更改或请求数据。知识管理服务在微服务架构中扮演着集中式服务器和知识访问入口的核心角色，其他微服务作为其客户端。所有的更改和请求都会被存储、同步和记录。参考架构的不同层和不同类型的微服务可能会以不同的方式与知识管理服务交互，以存储观测结果和请求信息。这些交互如图3所示。

图3：知识管理（逻辑功能数据流空白视图）

在我们的实现中，它们被表示为通过知识服务访问的本体。知识管理服务的实现主要基于定义与微服务的接口，并在运行时操作ARMOR API。

安全评估过程（SAP）的监控、分析、规划、执行分解

安全评估过程按照 MAPE 分解为微服务，如图4所示。蓝色的功能链展示了一个安全评估过程的数据流：从ADCC中感知的上下文和组件获取观测结果，依次经过分配的监控、分析、规划、执行微服务，最终对ADCC组件执行操作。

该示意图是通用的，因为不同的安全评估过程可能执行不同的功能。然而，MAPE 分解提供了一个通用模板，用于使用本地或知识模型中存储的信息。

图4：安全评估流程逻辑功能数据流空白图（第2层），在参考架构中标记为B模块

安全编排器的监控、分析、规划、执行分解

类似地，安全编排器执行一个包含监控、分析、规划、执行功能的闭环。功能链的来源有三个：感知到的ADCC上下文和组件的变化（新症状检测到新上下文）、被管资源的变化（ADCC组件变化），以及安全评估过程性能不足的情况。

框架Arcadia/Capella模型的顶层视图

综上所述，框架的设计和实现可以总结为图6，其中可以识别出六个主要功能。两层自主适配被指定为L2和L3，而L1对应于与现有系统和车辆平台的接口。知识管理服务提供请求和推理结果的接口。最后，微服务管理服务提供了一个框架库，用于运行分配的原型模板，并支持自定义内省功能。

图5：安全编排器逻辑功能数据流空白图（第3层），在参考架构中标记为C模块

图6：包含三层架构与支撑系统的顶层逻辑功能数据流视图

这一节我们会拿行人存在检测这个核心功能做例子，讲讲这套框架具体要怎么落地，以及它是如何通过采取对应措施来保障场景安全的。我们基于真实交通采集的数据，设定了一个测试场景。目前这套框架还处在第二次迭代阶段，全部功能还没开发完，但在这个案例的范围内，已经能完整展示行人场景下的行为自适应和结构自适应能力。

案例研究介绍与说明

这个案例的核心目标，是验证框架在有行人这类弱势交通参与者的场景中，能不能做好风险管理，同时生成合理的纠偏自适应方案。测试过程中，框架会对接ADCC的现有架构，从感知模块获取观测数据，再向导航系统输出行驶建议或者修正后的轨迹。测试主要在ROS平台上运行，用模拟数据和高还原度的真实回放数据来完成。

场景定义：示例场景描述与安全评估

本案例研究包含三个初始场景：车辆一开始沿直道行驶，随后进入过街区域，整体布局如图 7 所示。场景里的元素和命名规则，都参考了Voyage项目的工具包规范。行人初始位置设在过街区域的直道上，距离自车的检测范围有足够的距离。等自车行驶到场景中的指定位置时，行人开始按不同规则移动：

·（A）自车驶向人行横道，预判当自车到达横道位置时，行人的行进轨迹刚好落在人行横道范围内。

·（B）自车驶向人行横道，行人停在横道附近没有移动，但呈现出要过马路的意图。

·（C）自车向前行驶，行人正在无人行横道的区域横穿马路，预判当自车到达时，行人的轨迹还没进入人行横道范围。

图7：涵盖多类行人过街场景的案例研究示意图

我们这次研究的“行人存在”功能，核心就是聚焦行人的动态，通过多套流程判断行人和自车的状态是否处于安全水平，也就是保证足够的安全距离，确保自车能做出合理的应对动作。

在本次测试的场景里，因为没有出现明显的环境变化，所以不会触发微服务的实际结构自适应。但如果扩展初始条件，比如加入实际弯道、或者更换不同的限速要求，最终就需要给组成安全评估流程的微服务调整不同配置，这时候就会触发结构自适应了。

框架应用

案例研究知识库表示方法

在我们这套本体驱动的方案中，本体有两种具体的使用形式，用来引导框架执行结构自适应。

第一种方式是基于服务组件的语义描述（部署配方、能力属性、能力部署等）来表示框架结构和服务组合。我们遵循OGC和W3C联合标准SOSA/SSN本体，该标准描述了传感器、观测、采样和执行器，并将其应用于自动驾驶车辆领域。

第二种方式是指定组件在不同上下文中的行为。为此，我们需要详细说明实际服务、关注特征、其属性（功能或非功能属性）与当前上下文之间的依赖关系。这些关系定义了Waymo提出的安全需求。我们部分采用了文献提出的上下文分解方法，以及文献中的附加场景装饰方法。

图8：融合SOSA/SSN标准的本体拓扑结构图

我们当前使用的本体如图8所示。创建该结构和安全需求的方法遵循以下6个步骤：

1.从安全指标/需求以及与风险评估方法或运动规划相关的功能中捕获需求。

2.在功能层（模块、事件）中识别这些需求的信息来源，并创建相应的接触点以访问这些特征化信息。

3.用各自的本地逻辑和数据库表示这些方法的能力，明确其在安全等领域的作用。

4.将这些能力的需求与相应微服务的语义描述服务接口关联起来。

5.确保作为学科知识表示一部分的局部图的一致性，并在监控、分析、规划、执行和接触点实例之间分配能力。

6.根据上下文（或系统模式）对组合和编排进行特化。

图7中展示的一组场景使我们能够构建第一批模型（本体），用于表示自动驾驶车辆的运行上下文和被管资源（即ADCC功能的配置和可访问性）。在这一步，通过生成和模拟的情况验证检测功能的正确分类。正确的检测会在系统运行期间，将特定场景的新实例填充到本体中。

然后，对每个提取的场景进行安全分析和边界界定，生成一组可在运行时评估的安全约束。将这些约束分解为MAPE过程以及症状、变更请求等元素，定义微服务可以执行的自主过程。这一步还明确了知识库中需要包含的内容（例如上下文与观测之间的关系、安全评估的症状）。因此，第二次知识表示步骤提供了表示系统结构、能力、数据和组件交换的本体。

图9：框架内的本体表示：上图为上下文维度本体，下图为场景推理等价性

上下文本体如图9所示。它存储来自监控的症状，并支持使用不同的道路对象（如行人、自车）和相关属性来组合抽象上下文（如场景）。此外，每个道路使用者都可以分配多个动作（如减速、停车），并附加置信度来表示感知行为的不确定性。图9中黑色矩形框定的区域对应于我们建模的不同场景，我们试图通过对存储的症状运行推理器来识别这些场景。推理器可以在运行时通过评估可用的个体来执行推理，这是一种场景识别规则。黑色矩形右下角的"Equivalent To"字段展示了一个场景检测规则的示例。

技术解决方案实现：设计阶段的初步反馈

这套框架横跨多个不同领域，各层级的机制互相关联、彼此影响。管控这种结构复杂度很容易走偏方向，还容易堆出大量冗余代码。针对这个问题，我们采用了MBSE方法搭配Arcadia/Capella工具来做设计，尽可能复用现成的功能库和API，减少重复开发。通过迭代式的Arcadia方法，我们可以在Capella里一步步定义、细化架构模型，最终直接落地成ROS环境下的代码。除此之外，用SMACH实现模板状态机、用AMOR搭建支持运行时多本体操作的ROS服务，再搭配抽象、策略、装饰器、组合这几种经典设计模式，也大幅提升了框架物理结构和代码的可读性与可维护性。

实验验证

我们的初步测试已经验证，把这套框架集成到现有的ROS架构里是完全可行的，而且系统确实能正常执行自适应动作。为了验证自适应行为和安全管理系统（SMS）的实际运行效果，我们在原有ADCC导航模拟器的基础上做了功能扩展。这个模拟环境可以自由搭建包含自车、其他交通参与者和道路基础设施的各类场景，用来评估系统的实际行为表现。

图10：行为自适应模块的微服务组合架构

本次模拟针对的是图7中的场景 A，目标是跑通由图10中这些微服务组成的安全管理系统。这些微服务都已经在本次实验的本体中完成了定义，并且按照原型模板的规范，实现成了对应的ROS节点。模拟过程中，我们的预期是安全管理系统能准确识别出PEDES_02_01场景，自动部署对应的微服务并正常运行，最终输出合理的自适应动作。

结果分析

这部分的分析和测试场景，核心是验证框架能不能准确识别场景，并且顺利部署图10里的这套安全评估流程。监控接口会发布所有运行数据，比如状态、一致性、心跳信息，后续的微服务可以直接记录或者调取查看。我们还通过监控外部关键绩效指标（KPI），对比了自车在搭载和不搭载这套框架时的行为差异。

模拟场景分析

为了更直观地展示测试结果，我们拿PEDES_02_01场景来具体说明：自车驶向人行横道，预判车辆到达横道位置时，行人的行进轨迹会落在横道范围内。在我们的场景库中，这个场景的正式编号是2-2-XX-CW-STR-PED:S>N:01，对应的检测事件是“识别到不在行车道内、但靠近人行横道或有过马路意图的行人”。系统的预期行为分为两步：

1.自车减速，在人行横道前停下，保持静止状态；

2.等行人完全通过之后，自车再继续行驶穿过人行横道。

图11记录了模拟过程中车辆和行人的几个关键时间节点：车辆驶向人行横道（关键帧3）、检测到路边有过马路意图的行人（关键帧5）、识别行人行为后开始减速（关键帧6）、行人通过横道（关键帧7）、车辆驶过横道并恢复车速（关键帧8-10）。

图11：仿真环境下行人场景PEDES_02_01的关键帧

在这些模拟截图里，蓝色矩形代表车辆，带黑圈的蓝色方点代表行人，白色矩形代表行人横道。

图12：激进驾驶模式下自适应动态巡航系统（ADCC）在行人场景PEDES_02_01中的观测指标

为了直观体现框架带来的行为变化，我们跟踪了从ADCC和框架内省接口拿到的几项物理和安全指标。图12是未做修改的原车在遇到行人时的基线数据，两组实验都采用ADCC车辆做模拟，统计了x轴方向的车速、加速度，以及传感器对行人的检测状态。场景从第45秒启动，车辆一开始加速驶入道路、靠近人行横道，第54秒达到最高车速；第57秒车辆传感器检测到行人，触发减速（加速度变为负值，车速下降）；车辆靠近行人时保持低速行驶，第63秒驶过行人之后开始恢复最高车速。

图13：行人场景PEDES_02_01的观测指标

为了测试框架的实际介入效果，我们特意修改了ADCC的行为逻辑，让它的驾驶风格更激进，更容易突破我们分析设定的安全约束，以此触发我们的系统。具体做法是把原始车速乘以1.3倍，同时降低了加速能力，测试结果如图13所示。当本体中开始出现行人实例时，框架马上识别到了PEDES_02_01场景并介入干预，等车辆驶过人行横道之后，就不再触发该场景的管控。值得一提的是，虽然现场只有一个行人，但系统里会生成多个实例，这是因为我们保留了已识别道路使用者的部分历史数据。第63到69秒之间实例数量有所下降，是因为我们加了一套清理机制，避免实例太多拖慢推理速度，更多的限制条件会在下一节详细说明。

落地过程中遇到与解决的局限

整个实现过程里我们碰到了不少难题，其中一部分已经通过不同方案得到了解决。

首先，这个场景里原生的ADCC安全策略过于保守，全程都不会突破和行人的安全距离。所以我们必须刻意把ADCC的行为调得更激进，才能触发对应的自适应动作，展示修正后的正确行为。

其次，把观测结果存进本体生成异常征兆的时候，元素数量会快速暴涨。针对这个问题我们做了自定义的时间窗口，限定参与推理的元素范围，同时定期保存本体方便调试。举个例子，在多传感器的场景下，传感器采样率、监控聚合逻辑、各环节处理时长都不一样，观测数据的时间戳会有差异，因此必须做数据同步，保证场景里包含的都是最相关的实体。我们还给本体里每个道路使用者概念的存储元素总数设了上限，确保推理速度能满足运行时的要求。

最后，采用微服务架构，就意味着要对不同的节点和依赖库做非常严谨的设计与实现。第一次协调整套系统的这么多节点时，确实遇到了不小的困难。

为了验证这套“安全设计”导向的自适应架构，我们系统性地整合并处理了来自环境、场景化系统能力、不确定性和安全因素带来的动态复杂度。我们把自动驾驶车辆的安全问题，转化成了一个系统编排与组合的问题。通过系统分析和MBSE方法，我们把软件开发架构的各维度规范都沉淀到了知识库中，供系统在运行时执行自适应调用。对这些系统属性和所需知识的标准化表示，让系统具备了灵活、可组合、可观测的自主能力，能够自主评估并安全地执行驾驶行为。

这套方法仅从服务维度解决安全相关的非功能系统属性，因此框架是在现有ADCC被控系统的基础上做扩展，进一步提升了可观测性和可维护性。而语义化描述的方式，也让运行阶段安全风险缓解与管理的复杂逻辑变得清晰可追溯。

目前这一版迭代的框架，加上对应的案例研究，已经成功验证了这套方法在自动驾驶车辆安全领域的可行性。但自动驾驶的场景分析和知识体系体量庞大，搭建对应的模型和本体需要投入大量的人力。后续如果能把系统工程工具和这套框架整合起来，就可以从设计初期就纳入运行时的安全保障，同时全程保证可追溯性和一致性。

本研究后续还有很多方向需要推进，首要的是适配未来的行业标准，让安全评估流程能在整个设计开发生命周期里得到合理的设计与落地。比如优化场景变化的观测方式、提供故障注入接口，以及测试不同服务自主学习规避、缓解碰撞的能力。

免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系alpha.yuan@houwa-tech.com告知，我们会在第一时间做出处理。