万字长文 | 谈谈自动驾驶仿真

▲ 一个自动驾驶仿真软件的运行可视化界面

全文共9006字，阅读大约需25分钟

• “在三年前，还没有很多人提到自动驾驶仿真测试这个词。那时的笔者也想不到，三年后它能发展到如此程度。笔者的几年学习，与自动驾驶仿真的高速发展期正好相吻合。从最开始的懵懂无知到现在的刚刚入门，如今回首一望，感慨万千。今天借此平台谈谈对自动驾驶仿真的整体认识。

• 为了讨论更自由一些，这篇文章不求结构工整，具体表述细节也不求严谨，如文章中有错误或表述不当的地方，欢迎在文末留言或在后台与笔者直接交流。也欢迎关注此公众号，后期我们会围绕自动驾驶仿真进行一系列论述。

• 对于自动驾驶这一行，只有不断交流不断进步才不会被抛下。”

本文首发于公众号"自动驾驶仿真" 未经授权 不得转载

文 | 鲨鱼观海

什么是自动驾驶仿真？个人来下一个不成熟的定义，自动驾驶仿真是借助计算机虚拟技术对实际交通系统进行某种层次的抽象。

仿真的重要性已经不容置疑，自动驾驶想要大规模商业化落地，仿真是绕不过去的。为什么？因为自动驾驶的核心痛点之一就是成本，而仿真测试能把大量自动驾驶开发和测试的成本转化为GPU的物料成本和工程师的知识经验成本，进而大大缓解该痛点。

当前，几乎每家自动驾驶公司或涉及相应业务的公司都在进行仿真相关的工作。但同是仿真，不同公司的水平却参差不齐，不同工程师的仿真工程经验也有很大差异。如何才能搭建一个良性的高效的自动驾驶仿真体系？如何才能成为一名优秀的自动驾驶仿真工程师？这是公众号的未来讨论核心。

搭建自动驾驶仿真体系是一个下限很低，上限很高的事情。下载一个仿真软件，它可以是MATLAB，CarSim，也可以是CARLA、Lgsvl，或者是Prescan、VTD，通过文档学习一下仿真流程，就基本可以开始进行相关工作，这是大多数人对自动驾驶仿真的认识，也是这个细分领域门槛不高的佐证。但需要清楚的是，一个良性的自动驾驶仿真体系是一个标准的系统工程，它包括广义上的场景、系统以及评价三个主要模块，贯穿自动驾驶的开发、测试、落地以及运营等整个流程。有人说，需要让最熟悉自动驾驶系统的人来承担仿真相关工作，这个观点从某种程度上来说是正确的。

接下来就让我们按照这三个主要维度，来谈谈一个良性的自动驾驶仿真体系应该包括什么。

1 仿真场景

场景是仿真体系的开端，它在整个体系扮演着极其重要的角色，但其重要性相比于仿真系统却相对容易被忽略。而且随着仿真系统和评价体系的逐渐完善，越往后期，场景在整个体系中扮演的角色越重要。场景之所以有此地位，本质是因为其是对自动驾驶相关数据的一种价值提炼，是发挥数据价值的必须且高效的途径之一。基于场景的测试方法可以弥补基于里程的测试方法的局限性，在提高系统开发效率、产品落地效率方面都有重要作用。

以光照程度为自变量的场景

场景是公众号后期要讨论的核心内容之一，主要会围绕场景的形式和内容两方面展开。

1.1 场景形式

场景形式指的是场景数据的具体呈现方式。为什么要着重介绍场景的形式？核心在于三个字：标准化。标准化的场景体系的作用包括但不限于以下几点：

• 提高对原始数据的提取以及转化效率；

• 方便构建冗余度低的场景体系；

• 方便不同场景体系之间的比较以及场景交换；

• 减轻第三方测试时的多余工作。

目前相对比较通用的场景形式是由德国PEGASUS项目提出的功能场景-逻辑场景-具体场景三层体系。举个例子，功能场景可以描述为，“自车（被测车）在当前车道运行，在自车前方有前车加速运行，自车跟随前车行驶。” 逻辑场景则提炼出关键场景参数，并赋予场景参数特定的取值范围，如以上描述的场景可提取自车车速，前车车速以及加速度，自车与前车距离等参数，每个参数都有一定的取值范围和分布特性，参数之间可能还存在相关性。具体场景则需要选取特定的场景参数值，组成场景参数向量，并通过具体的场景语言表示。

以上示例只是为了说明三层场景体系的内涵，具体的表述形式会有更多细节，需要有更多的标准和约束。

三层场景体系

具体场景需要转换为计算机可理解的语言即场景语言才能发挥作用。场景语言是一种可用以描述自动驾驶系统待处理的外部环境的计算机可解析的形式化语言。

场景语言的具体形式不一。针对功能场景、逻辑场景以及具体场景都有相应的场景语言：如针对前两者，有M-SDL等高级场景语言；针对后者有OpenSCENARIO、GeoScenario等。不同仿真软件支持的场景语言也不同：如CARLA和lgsvl等都支持基于Python脚本的场景语言；CARLA、VTD和最新版本的51Sim-One1.2等支持基于XML的场景语言。此外，protobuf、JSON都可以作为承载具体场景语言的格式。

这其中的关键不在于语言本身，而在于能全面且不冗余的覆盖交通元素的体系标准。目前已有一些机构在推相应的标准，比较成功的是由VTD发起的由ASAM（国际）/ CASAM（国内）推动的OpenX系列。公众号在后期会围绕OpenX系列展开较多介绍，因为这是目前看来最有可能推广开来的一个标准。具体也可以关注中汽中心周博林周博的分享。

M-SDL 一种高级场景语言

1.2 场景内容

1.2.1  基于知识、数据的场景来源

在确定场景形式后，后期日常工作会围绕场景内容的构建展开。场景内容有两个主要来源：知识和数据。其中，基于知识的方法主要是依赖于具体场景结构，综合借鉴各相关学科的知识，分析自动驾驶系统需要处理的静、动态元素类型，并结合自动驾驶系统的测试需求构建场景。基于数据的分析方法则是从采集的自然驾驶数据中分析提取出有价值的场景。

基于知识、数据的场景构建方法最终都可以生成测试所需要的具体场景，这部分也是公众号后期要展开讨论的核心内容之一。

知识驱动和数据驱动的场景生成方法

1.2.2  具体静、动态场景内容

从具体元素的角度看待场景内容，可将元素分为静态元素和动态元素（半动态）两部分。

静态场景元素的分析和提取相对较简单，主要包括道路、基础交通设施（交通标线、交通标志、交通信号灯以及抽象的交通规则等）、天气、光照、其他建筑物基础设施等，难点在于一些连续量（如光照和雨量）的取值范围分析，以及不同静态场景元素之间的约束关系。

动态场景元素的提炼和转化相对较为困难。主要原因如下：

• 除了静态场景元素固有的连续值取值范围和多约束问题外，交通行为是在一个高度复杂的存在多种约束条件的环境下的高交互性行为；

• 交通参与者类型众多，包括重卡、轻卡、乘用车、电动车、行人等，每种交通参与者都有自己特定的动态行为模式；

• 具体的动态行为模式有多种类型：带时间戳的轨迹数据、基于行为分类的数据（如跟车、换道等）、基于Agent的动态行为；

• 在实际提取动态交通数据时，需要考虑采集车自身的影响，即考虑处理交互性；

• 简单动态交通元素的分析以及大规模复杂交通元素的提取和具体形式有较多不同，需要不同的技术手段。

以上都是在提取动态场景内容时需要考虑的问题，也是公众号未来会重点展开的内容。

动态交通流示意

1.2.3  场景提取pipline

最后再大致回顾一下场景提取的pipline。基本流程是数据采集、数据提取和数据转化。传统的数据采集工作，包括数据存储、数据标注、数据分类在企业中往往由基础架构部门负责，这部分在理论上和实践上也已经相当成熟了。仿真需要重点关注的是如何高效的从数据中提取有价值的场景，并将其转化为具体的场景格式。

2 仿真系统

仿真系统是整个仿真体系中承上启下的部分。它播放仿真场景，测试研究对象，通过仿真数据接口提供被测对象的运行表现数据。仿真系统是当之无愧的仿真体系核心，前面抛出有个仿真软件就能进行仿真工作的观点，只是为了说明构建仿真体系的下限。但在实际应用工作中，仿真系统的性能也决定着整个仿真体系的上限。

接下来我们来谈谈应该怎么看待仿真系统，围绕着仿真系统又该重点关注什么工作。

2.1 仿真软件 | 被测对象 | 通信环境

首先需要明确的是，仿真系统不止是仿真软件。从狭义上来说，它是仿真软件、通信环境与被测对象的集合；从广义上来说，它又包括云仿真环境等。

其次需要明确的是，仿真系统是具体的工具，是“术”。而在构建仿真系统时，作为仿真工程师在关注“术”之余，也需要关注“道”的部分。不同仿真软件、不同的通信环境、不同的被测对象都有各自的特点，作为仿真工程师需要了解不同仿真模块各自的共有属性，并充分理解并利用不同对象的特异性。关键是做到兼容并包，调节需求和客观仿真资源之间的矛盾。

仿真软件

在了解不同仿真软件的共有属性方面，可以学习基本的pipline。从比较粗的粒度上看，基本的仿真pipline是加载静态地图、构建动态场景、接入被测对象、导出运行数据、结果评价处理。这之后就基本可以上手一个仿真软件，剩余的深入拓展工作也可以围绕整体流程向外展开。

在了解不同仿真软件的差异方面，需要明白市面上各类软件各自的特点，集中精力是正确的，但是封闭眼界并不可取。单就自动驾驶仿真软件而言，Prescan、VTD、Panosim、51simOne、GaiA等商业自动驾驶仿真软件，CARLA、lgsvl、Airsim等开源自动驾驶仿真软件，稍微粗糙一些的DeepDrive、一些基于ROS构建的自动驾驶仿真平台，就都有各自的可取之处。

CARLA Simulator

另外，还有一些专精于特定功能仿真的软件。如在交通流仿真方面有Vissim、SUMO、High-env等；在动力学仿真方面有CarSim、Trucksim、Carmaker等软件；在静态场景仿真方面有一些大规模城市构建仿真软件；在构建复杂交通流场景方面也有一些软件。这些软件都可以纳入到整个自动驾驶仿真体系里来。我们会以后也会重点展开介绍各软件的不同点。

SUMO Simulator

被测对象

根据被测对象的不同，业界常用的仿真工具链包括模型在环（MIL）、软件在环（SIL）、硬件在环（HIL）、整车在环（VIL）。目前SIL在各类公司应用范围最广，但其他各类也都有自己的独特优势和测试必要性；按照自然开发的流程，完整的测试过程也确实需要兼顾这几种平台。站在具体实践角度，每种在环仿真平台有适配于自己的仿真软件和技术栈，其中部分要掌握的技术如下：

• MIL与SIL相似，最基础的问题是通信环境构建，往上进一步则需要研究仿真效率、实时性、同步性等；

• HIL需要补充实时机与硬件通信接口的知识；

• VIL是大工程，需要投入大量人力物力来搭建专门的实验室，目前一般都应用于驾驶员在环仿真。

各种技术栈也是我们未来要探讨的重点之一，SIL会是主体，其他几种优先级会放的低一些。

通信环境

最后再来说说通信环境，即仿真软件和被测对象之间的信息传输环境。其基础是利用计算机网络的相关知识完成信息传输工作，也即各种JD描述中提到的开发仿真接口。

一般情况下，可以通过通信中间件处理仿真数据，并将其转化为被测对象所需的数据格式进行传输。中间件类型有很多，常用的可能有基于ROS的中间件、基于AutoSAR的中间件等。关键问题是结合具体测试需求选择合适的中间件；以及如何减少仿真消息的延迟和丢失以保证通信效率，这和仿真的可用度密切相关。

总之，优秀的仿真工程师除了需要有为软件增加仿真功能的能力外，更关键的是需要对自动驾驶系统有整体宏观上和局部微观上的理解，并能对接各方其他工程师的需求。在此基础上，如果是基于成熟商业仿真软件进行工作，就围绕着说明书、教程以及培训，同时与仿真软件的技术支持工程师时刻保持交流，并不断积累自己的应用能力。如果是基于开源仿真软件进行开发，则需要时刻关注软件的新版本和新功能，多刷issue以解惑。当然，也可时刻关注借助一些典型的基于仿真平台的优秀项目提升自己的能力。

2.2 静态环境模块 |  交通流模块 |  传感器模块 |  动力学模块 |  数据模块

在了解基本仿真系统的构成后，还是需要再回到仿真软件本身。只有在了解仿真软件的机理并清楚相应软件的缺陷之后，才能高效的对接各种测试需求以及针对性地开发相应功能。

以我个人的理解，一个完整的自动驾驶仿真软件从逻辑上包括静态环境模块，交通流模块 ，传感器模块，动力学模块，数据模块（包括场景模块）。针对每个模块都有一些亟需解决的关键仿真问题。

静态环境模块，

静态环境模块指构建、维护静态场景的模块。具体需要的静态元素需要同感知组进行对接，也可以结合具体的专家知识提取分析产品ODD。之后需要设计符合真实情况的场景元素并以合理的方法进行泛化。

这一模块的关键问题在于静态环境的真实度保障以及自动化构建大规模静态场景的方法两方面。

交通流模块

对应于动态场景的概念，参考51VR公众号的总结，需要重点关注以下几种动态场景构建方式。每种构建方式都有一整套基础理论和实践手段，之后我们会一一展开。

• 典型交通行为建模，如启动、跟车、换道、超车、十字路口处理等。这部分主要可以使用DBM相关方法进行分析。

• 利用AI技术生成驾驶模型，在虚拟世界中设置AI车辆自动行驶，AI可以学习交通流的特性，尤其在行人仿真方面有比较好的成效。这部分主要可以使用模仿学习、强化学习来完成；

• 导入交通学中的交通流模型，并引入数学概率分布数学模型。这样的交通流模型包括宏观交通流模型和微观模型，相应的数学概率分布模型应该以高斯模型为主，这部分可以通过与SUMO/Vissim联合仿真完成，也可直接构建交通流模型。

• 将真人开车的数据导入交通流中，研究rare-events simulation，主要利用驾驶模拟器实现。

Agent-based traffic simulation

传感器模块

传感器模块是连接外界环境和被测车辆的媒介。针对不同的被测对象，有不同的传感器模块使用方法。在进行决策规划系统测试时，可使用对象级传感器，由此可以避免传感器模型的不准确带来的大部分后续问题。对于需要原始仿真信息（如图像、点云）的被测系统，则需要基于实际产品情况精确标定传感器参数，如对于图像传感器标定位置外参和畸变系数等内参，对于激光雷达等传感器，标定线数、旋转速度等。

传感器建模是个处理难度很高的模块，目前有物理建模和统计建模两种典型的传感器建模方法。物理建模难度比较高，且需要大量的计算资源；统计建模方法始终存在真实度gap。如何弥补这两种模型的缺陷是需要深入讨论的问题。

一个可以借鉴的手段来自waymo，对于感知仿真的相关问题，它们似乎没有直接进行传感器建模，而是采用GAN的方式解决。如果必须要用到传感器建模，对于统计建模的方法，可以精心设计噪声参数并通过数据处理方法解决由真实程度带来的仿真结果差异。对于物理建模，则要看各仿真器的硬实力。但不管怎么样，首要的是处理真实程度的问题，其次是考虑计算资源的约束。

Surfel GAN

动力学模块

这部分的重要性不再多提。它在传统车辆仿真工作中占有非常重要的地位，相关的理论和实践工作也已非常成熟。但不能因为待攻克的工程问题比较少就忽略它，相反，必须高度重视动力学仿真的结果，因为它的精确度可以直接影响仿真结果的可用程度。这部分的工作主要需考虑的是集成动力学仿真的方式，是内部支持还是通过与CarSim等进行联仿支持高精度动力学仿真？要不要考虑实时性问题？

总的来说，对于动力学仿真模块，要熟练掌握CarSim和TruckSim等动力学仿真软件和各种动力学模型，掌握联仿方法，动力学模型标定方法。另外，百度提供了一种基于数据的动力学建模方法，也有很高的实用价值。

数据管理模块

本文指管理整个仿真数据pipline的模块，它的内涵覆盖范围很广，包括场景解析、仿真过程记录、过程回放、数据导出等等。每个具体功能都可以专门拿出一篇文章来谈，这部分也非常重要，但限于篇幅在此就不具体展开了。

2.3 本地仿真 | 大规模云仿真 | 稀有事件仿真

仿真可以降低时间成本、经济成本，提高测试的安全性。但是要保证自动驾驶系统的安全性，需要进行非常多的测试里程。即使采用场景测试的方法作为补充，但由于可能的场景参数较多以及部分参数具有连续性，因此很容易形成海量的测试场景。在这样的前提条件下，只用几个本地仿真系统的话，跑完这些场景的时间成本是不可接受的。能否合理解决这个问题，决定着仿真体系能不能发挥最大效能。

目前学术界/工业界有以下几个主流方案。其一是大规模云仿真，这也是工业界正在推动的主要路径，通过使用云资源进行并行计算，并在不同agent之间交换仿真结果以提高效率。另外一种由学术界重点推动的方法，则是借助场景的概念，通过设计一些策略缩少无风险里程，或者提高能对自动驾驶系统形成特定挑战的场景的生成效率，即通过“压力测试”提高仿真效率。

Sim Cloud of TAD 

One Case of Stress Test

3 仿真评价

最后说说整个仿真体系中最容易被忽略的部分，基于仿真的评价。想象这样一个需求，自动驾驶系统更新了一个重要功能，相应的版本从V0.8更新到V0.9，现在需要进行回归测试以保证新的修改在解决新问题的同时，不对系统已经被验证过的能力造成影响。需要怎么做？

这时首要是要准备一个“标准场景库”，这个场景库也必须被精心设计，此处先不具体展开。考虑另外一个问题，如何保证系统过了这个场景库？用pass/fail的二元指标，或者违反交通规则的次数? 这种指标是有局限性的。最大的问题在于，由于仿真测试和实车测试结果的差异性，单纯的二元指标会催生大量的假阴性、假阳性结果，进而造成系统的安全性风险。因此我们需要建立一个更合理的评价体系，设计带有连续值属性的评价指标，通过评估“距离”来评估系统的安全性。

具体仿真评价指标的设计需要精确对接产品需求。不同的算法，不同的系统有自己的特定指标，这些可灵活发挥的点比较少，关键是对接好开发工程师的具体需求；面向第三方的评价体系则相对更具灵活性，可以设计面向安全性、舒适性、经济性等维度的具体指标。

总的来说，评价体系是必须精心设计的，因为它是评估迭代后的系统性能是否变好的基础。

4 主要挑战

在文章的最后，我们再集中谈谈目前仿真工作中遇到的几个挑战。

4.1 Reality Gap

Gap1：仿真对物理现实的表现是不充分的。举个典型例子，在针对感知系统进行测试时，是否需要保证渲染图像/点云和现实世界的高度一致性？由仿真合成的图像/点云等用于训练对应的自动驾驶系统是否能有效提高性能？

保持高度一致性需要非常高的成本。为了规避较高成本，目前也有一部分相关研究工作。典型的如百度的AADS（虚实结合）、谷歌的SurfelGAN（以GAN为代表的一系列工作）等。

Gap2：考虑所有相关的物理现象具有挑战性。举一些典型例子，简单车辆模型如果没有包含轮胎模型，在较高速度下如何考虑转向以及加减速等行为？如何建模随机过程(如信号噪声)并将这些模型作为一个整体集成到仿真中？如何将V2X仿真与物理地形仿真集成在一起？

解决这些问题，要开源节流。例如，感知渲染做不好，从工程的角度，可以考虑把仿真重心放在决策规划和控制上，而感知测试的重心可暂时放在回放型仿真上。或者仿真工程师可在已有的gap下，通过数据处理分析，以及一些交叉验证手段来覆盖掉gap。

总的来说，若系统在仿真环境和实际运行环境之间的表现差异太大，必须仔细分析造成差异的关键矛盾。如果该矛盾在短期内因为客观原因不能解决，则需果断调整重心。仿真非常有用，但不是测试过程的万能药，为了仿真而仿真是没什么意义的。

4.2 Complexity & Lack & Business

Complexity

复杂性表征在三个方面。其一，自动驾驶软件本身的多样性；其二，单个仿真软件的功能复杂性；其三，针对特定系统和特定软件开发仿真接口的复杂性。

当前的自动驾驶仿真软件确实很多。VTD、Prescan、51Simone、PanoSim、GaiA、rfPro、CARLA、Airsim、Lgsvl、DeepDrive、Carsim、CarMaker；甚至Matlab/Simulink、GTA-5、Gazebo都可用于自动驾驶仿真。每个仿真软件都有自己的优缺点，如果面对具体测试需求不断切换要使用的模拟器，无疑会增加很多学习成本。此外，面向同一被测系统，针对不同自动驾驶仿真软件，往往需要开发不同的仿真接口，这也需要较高的时间成本。如此之多的仿真套件也不利于工程师日常维护，进而在开展工程级别的大规模仿真测试会有较多掣肘。

Lack
如果有一款足够完美的自动驾驶仿真软件是不是就一劳永逸了呢？

话虽如此，但实际情况没这么简单。从功能来说，目前很难说有一款公认的足够完美的自动驾驶仿真软件。大部分软件都还不能同时支持以下列举的全部功能：

• 由于可能破坏物理引擎的稳定性无法提供高于实时的模拟速度；

• 不支持高效的无GUI运行(headless execution)模式进而影响自动化测试等；

• 建模基于复杂多维真实交通行为的动态场景时需要较高数据成本以及专业知识；

• 构建大规模真实、异构静态场景时需要较高时间成本；

• 适配多种场景语言（或者说，将场景编码为场景语言）时，需要较高的时间成本；

• 不支持多agent联合仿真以及跨多台机器仿真会话有效分发；

• 不支持大规模场景（整个市区级）（此需求合理性有待讨论）。

Business

不可否认，对有些自动驾驶仿真领域的深耕玩家而言，以上功能都已直接间接得开发成熟。但在实际进行研发时，还必须考虑软件使用的经济成本、所用数据安全性、仿真与基础架构的契合度（与数据闭环的契合度）。

因此部分机构还是会去独立开发完善一个仿真系统。此时，以上提到的相应功能开发也正是自动驾驶仿真工程师可能的部分日常工作。

4.3 Reproducibility 

可复现性，某种角度上也叫仿真结果的确定性，包括两个方面，由仿真到现实的可复现性和仿真本身的可复现性。需要注意的是，前者是可复现性的重点和难点，需要通过精心处理Reality gap 解决，这里只是说说相对容易被忽略的后者。在实际测试过程中，只有在一定程度上保障了系统的可复现性，就可以知道对代码所做的更改是否修复了问题，进而有利于测试自动化和CI，规避假阴性和假阳性的结果。

MIL、SIL、HIL、VIL，无论是哪种仿真系统，仿真结果都可能存在一定噪声。表现在采用同一组场景，重复运行多次，评价指标值会出现一定的波动。自动驾驶系统作为CPS系统的一种，相应的仿真结果出现波动是正常的。由于波动出现的原因受众多较难追溯的因素影响（线程不稳定性、信息传输帧率、指标本身的高度非线性），因此需要精确建模噪声并定量分析的可能性较小。一种可行方法是通过多次运行实验，采用平均值等统计处理手段尝试定性解决这个问题。另外一种可行的方法则是通过设计模糊化、综合化的评价指标实现。

4.4 CI

在CI中集成仿真是大势所趋。但其会受到以下特性影响。

模拟器可靠性。CI的挑战之一是仿真软件本身的可靠性。在自动化中使用仿真软件时，可能有意外的崩溃、时间和同步问题。

接口稳定性。自动驾驶仿真软件接口的稳定性会对自动化过程产生重大影响，因为不一致的、不稳定的、脆弱的仿真软件接口可能会导致客户端应用程序出现故障。这里需要做大量的工程工作，来不断开发并维护仿真接口。

5 结语

自动驾驶仿真体系的搭建，下限很低，上限也很高。它在很多方面上决定着一个自动驾驶公司或部门能走多远。合理的完整的仿真体系能加速整个系统的开发和测试，提供正反馈。

目前已有很多知名公司和前辈分享了许多仿真相关的知识，这些知识令人受益匪浅，但由于每次分享时间有限，所以不太能展开更多，不易形成完整的系统。国内的51VR等于2019年参与出台了自动驾驶仿真蓝皮书，这本书为仿真的学习提供了系统学习路线，但受限于蓝皮书的性质，不易展开更多细节。

这也正是我们去开这个公众号的原因。我们希望能通过建立一个专精于自动驾驶仿真相关知识的公众平台，和大家共同探讨对整个自动驾驶系统的认识。并在不断交流不断讨论的过程中，系统化仿真学习路线，并能深入研究更多具体细节。

既宏观，又微观。这样才可以获得长久的进步。

• 声明：偶尔转载的文章出于非商业性的教育和科研目的，并不意味着支持其观点或证实其内容的实行，欢迎大家评论发表自己的意见。版权归原作者所有，如转载稿涉及版权等问题，请立即联系我们，我们会予以更改或删除相关文章，保障您的权利！