【汽车与环境】南京航空航天大学教授宋廷伦：如何应对自动驾驶技术量产化对整车开发流程和机制的挑战

2018年12月7日-8日，以“创新驱动、技术引领”为主题的2018第六届“汽车与环境”创新论坛在上海·安亭正式举办。本次论坛完整覆盖汽车行业技术领域的研讨，旨在进一步促进整车企业与零部件企业之间对技术发展趋势的探讨、加强汽车行业专家之间的交流互动、增强整车与零部件企业的交流、搭建合作平台，通过活动促进汽车零部件产业创新转型升级、打造更具竞争力的整零协同创新关系，助力实现向汽车强国的转变。以下是南京航空航天大学教授宋廷伦的发言：

南京航空航天大学教授 宋廷伦

如果自动驾驶技术要量产话的话，我们要解决哪些问题？尤其从流程体制和机制上。自动驾驶技术很多主机厂、供应商都在做，但要落实到量产上还需要从流程、机制和组织机构上做相应安排，否则会出现工作承接问题。

自动驾驶是一个分层的决策和控制问题，自动驾驶技术尚有几个关键技术问题和商业模式问题需要解决，我认为现在这几个问题还没有最终答案。

第一个问题是基于逻辑的控制还是基于AI端对端的控制，这两个策略到底走哪条路。Waymo采用的是是基于AI的环境感知和控制策略，国内开展的工作到目前为止我认为更多采用的是增量式的。换句话说，设计一定的自动驾驶功能，在可控的场景下一步一步往前走，这更适合在短期内推出具有自动驾驶功能的量产车。

第二个问题是以车载传感器为主的环境感知，还是V2X和车载传感器相结合的环境感知策略。

第三是实施路径上的考虑，两条路径。一是适用于所有驾驶场景的的部分驾驶功能，二是适用于特殊场景的全自动驾驶。第四，从商业层面，我们在新的竞争模式下，主机厂、供应商、关键技术提供商它们之间的分界到底在哪里？换句话说，主机厂做自动驾驶技术研究和开发要研究哪些内容？要不要去研究传感器、要不要去研究芯片技术，从商业和合作模式上我们的边界到底在哪里。

刚才讲第一个技术路线问题是基于传统控制逻辑vs. 基于AI的环境感知和控制策略。第一种路线基于AI的，以AI为基础的基本上是靠图象映射的方式，根据环境感知、反应车辆周边路况的图象直接可以映射出驾驶的决策，是加速、踩刹车、左转还是右转。第二种路线是环境感知用了很多人工智能的技术，真正的车辆控制策略还是基于传统逻辑的控制，这就要求两步走，环境感知部分采用AI技术、控制策略设计采用传统的基于逻辑的控制方法。

第二个技术路线的问题是多少信息来自车载传感器，多少信息来自的基础设施，极端情况是所有信息来自车载传感器、或绝大部分信息通过V2X获取，这是两种不同的考虑。胡教授最开始讲的这种路线可能是第二种路线更极端的情况，换句话说，车只要具备最基本的自动驾驶的功能，那么我更多的信号是来自基础设施，车辆控制信号是来自于全国400多个基站，也就是说你这车到了高速路上，识别之后会问你是要自己开还是自动开，自动开就是被这些基站控制中心某种程度上“劫持”，驾驶员不再对这个车有驾驶控制权。

这张图是说现在大部分研究的还处在前两个模块，横轴驾驶功能由简单到复杂、纵轴是在什么样的场景下去实现这个自动驾驶，驾驶场景由简单到复杂。看到这里面绿色的，大家都在研究，基本上也有些靠谱的关键技术逐渐地体现在量产车上，但是越往右越往上难度就越大，红色这部分到底能实现还是不能实现，什么时候能实现，这是目前还回答不了的问题。

这张图还是在一定的假设条件下，道路情况非常简单，天气因素没有考虑，周边的交通情况也是在很可控很简单的情况下。那拿到现实世界中来这张图可能就变成这样，尤其在L3和以上级别的，以及路况更复杂的情况下，这个实现起来难度就非常大了。

商业模式上的不确定性，两个维度，一个维度是对客户的拥有权到底是多大，换句话说这些客户，主机厂车直接卖给客户，主机厂拥有了这些客户，第二个是在关键技术和核心技术上掌握多少，这当然指的是自动驾驶技术。原来传统的主机厂有了很多新的竞争对手，在用户拥有权这方面优步也好，滴滴出行也好，还是其他的公司也好，其实也在努力的去争取用户拥有权。在核心技术方面，我们主机厂在很多零部件自动驾驶，尤其是芯片、传感器这方面主机厂并没有核心技术，如果说将来想到黄的那个地方，优步、滴滴出行可以往下走，核心技术和供应商它们可以往右走，潜在的都有可能把主机厂未来放到第一供应商的位置。那么主机厂怎么做？需要广泛的联合，那联合的边界在哪里？这也是自动驾驶行业需要考虑的问题。

这些关键问题没回答之前主机厂是不是就不做事了？不是这样，所有的主机厂都在积极主动的去制定自己的自动驾驶路线，也在不断地推出具有一定自动驾驶功能的量产车型。在这样一个大的背景下，作为主机厂如果开发自动驾驶相关技术的话，在这些关键技术路径问题没有明确答案之前应该怎么做才能够保证现在做的工作不至于被今后的技术路径否定掉。

主机厂应该怎么样面对这样的挑战？下面有几点思考和大家分享一下。第一，开发活动纳入整车开发流程体系并有相应组织架构支持。第二，电器架构兼容性，自动驾驶技术对整车的电器架构提出了更高的要求，电器架构是在整车平台开发的时候定的。一个整车平台生命周期至少在10年到15年，换句话说如果你的电器架构现在定了，那带宽基本上就确定了，今后如果上其他自动驾驶的功能可能做不了，如果要做的话就要回来修改电器架构，这就影响非常大。第三，在关键技术问题还没有明确答案之前，自动驾驶技术的开发要有一定的标准，怎么样保证它的安全？建议有条件的将ISO26262作为自动驾驶软硬件功能安全标准。这个标准不是说拿过来都能用到自动驾驶技术的开发上，有些层面的内容其实是这个标准没有覆盖到的，换句话说我们采用这个标准的时候要有条件的。第四，采用基于模块的软件开发技术。第五，自动驾驶的测试到底应该怎么做。

在整车开发的过程中，自动驾驶技术在前期就要充分考虑很多因素。做自动驾驶技术不能埋头苦干，要抬头看路，看的是整车产品开发流程，你在客户需求、可行性等方面要做充分。红色的线这是全生命周期的管理，不管你开发的是零部件也好、软件也好都要遵从全生命周期的管理。

参照整车产品开发流程，我们自动驾驶技术在产品开发的不同阶段要做哪些主要工作。这些关键活动应该由哪些部门来负责，对于一个传统的主机厂，每个部门在产品开发流程里都承担非常明确的责任，自动驾驶技术我们刚才说了针对产品开发流程这些关键活动要有相应部门来承担工作，当然不同的主机厂它的部门划分和职能可能不一样，但是每样工作一定有个承接部门。

我讲的第一部分就是自动驾驶技术如果要量产化的话一定要纳入整车产品开发流程中去，每项工作要有承接部门。第二部分就是电子电器架构的兼容性，电器架构除了传统电器功能之外还要考虑两点，一是自动驾驶技术对电器架构的需求，另一个是新能源车对电子电器架构的需求，电子电器架构的设计要充分考虑到这两个主要技术趋势的兼容性。电子电器架构最后落实的是五个方面，换句话说电子电器架构设计要考虑五个方面内容。第一功能定义；第二架构拓扑；第三电源分配；第四电器件布置，整车平台在开发过程中它零部件位置都很清楚了，这通常是不能动的；第五线束拓扑。

接下来简单说一下功能安全标准ISO26262在整车开发当中尤其自动驾驶这块哪些是和我们相关的，哪些是不能直接拿过来用的。ISO26262主要关注的是两个方面，一是随机硬件失效，二是系统性失效，所有软件失效都属于系统性失效。

ISO26262有几方面内容，一要做风险分析，风险分析通常包括三个主要因素，一个是风险的严重度，受伤还是没有受伤，还是有生命危险，二是这种风险出现的频率，三是这种风险的可控性。还有就是人体伤害的评估，自动驾驶技术实际上在事故出现的频率和可控性方面，这两方面提出了更高的挑战，原因是原来我们更多关注的是人和车，自动驾驶技术的引入我们要更多关注自动驾乘环境。

在驾驶员不在环或部分在环情况下，可控性降低/危险状态几率增加，提升ASIL级别以保证功能安全。根据三个因素你来确定它ASIL的等级，ASIL-D是最高的，引入了自动驾驶技术之后ASIL发生了巨大变化，驾驶员不在环或者部分在环，车的可控性变的很低了，这种情况下对软件和硬件的功能安全级别提出了较高要求。我们也在问除了ASIL-D之外是不是上面还应该有个更高的层级。

我怎么样把ISO26262纳入到产品的开发流程体系中？在产品开发的不同阶段根据ISO26262的要求开展这些关键的功能安全活动，这里面重点强调的是全周期的安全管理，还有流程和组织机构，以及支持流程。支持流程关注了很多，包括需求管理、变更管理、配置管理以及软件的质量，还有测试。

针对ISO26262这块我们认为自动驾驶功能开发的过程中要做几件事，第一要采用ISO26262进行软硬件安全风险分析和设计。第二，功能需求和安全需求要适当分离，这句话什么意思呢？ISO26262覆盖更多的是功能安全方面的需求，但是自动驾驶有些功能其实不在这个标准的覆盖范围内，比如说你的车前面有行人，这个车根据环境感知判断出来说这不是行人，这个误判其实不在标准的覆盖范围内，这应该通过自动驾驶需求去定义，所以漏识别和误识别情况通常不在ISO26262的覆盖范围内。

自动驾驶的软件开发要把它用软件开发的流程进行规范，我们现在的软件开发可能离规范的流程还有一定的距离。这里面我们尤其要强调的就是在自动驾驶软件开发的需求定义的时候，要同步定义驾驶场景和测试规范。换句话说，开发的软件要能够处理所有意外情况，意外情况最差的情况处理不了了，车可以靠路边停下来，但每一个问题都必须要考虑清楚，要有出口。

在软件开发方面，我们认为应该采用模块式开发，它有很多的优点。比如，核心功能需求不影响软件的根本构成元素。同时，模块化开发可以快速集成具有特定系统的功能。

模块开发有这么几个层级，第一层级是要定义出相应的模块，比如说车载传感器模块、高精定位模块、路径规划模块、车辆控制模块，模块构成了模块库，模块库相应的组合可以开发出具有各种自动驾驶功能的。

模块化开发体系有三个基本的要素，一是模块的管理，二是接口和通讯，第三方面是模块的可集成性。针对每一个模块要满足相应的模块设计要求，这些要求包括你这个模块的功能是什么，你的接口是什么，这个模块后面的数据模型是什么，还有这个模块如果集成到一个流程中，它和流程相关的属性应该怎么定义，还有它哪些属性是可以客户化的，还有这个模块应该怎么做质量保证测试，最后这个模块它对故障诊断和识别是怎么处理的。

模块开发我们刚才说了它分成几个层级，最上层的是供应商，当然我们的愿望是希望供应商能对我们开放它的接口，这也是主机厂比较困惑的地方。如果说模块设计合理的话，我的供应商可以去换，供应商A不提供可以换成B。这中间有一个接口层，我们叫它adaptors，下面是模块层，再下面是由功能模块搭建起来的应用层，它包括AEB、ACC等等。

自动驾驶测试的复杂性在于驾驶工况复杂、非确定性算法、机器学习系统，还有虚拟和实物验证对标，一定工况确定的情况下虚拟验证怎么来保证模型正确，要和实际实验的结果进行对标，对标以后来验证模型，验证的方法就是通过实验验证来对标，但是自动驾驶技术在对标这块基本上没有办法去用虚拟验证和实际验证去对标的，这个很难。

在自动驾驶测试方面，上午邓教授讲的比较多，这里面基本上观点一致。这张图说明了自动驾驶虚拟和实物验证技术的关系，虚拟和实物验证有两处衔接。第一，机器学习的数据集、实测驾驶场景数据、开放式道路测试为虚拟验证提供场景建设数据；第二，虚拟和实物测试验证对标。它搭接在两个地方，一是场景数据库，怎么样构建一个确实能够客观反映驾驶场景，这是虚拟验证和实物验证搭接的地方。第二个搭接验证地方就是对标，对标这块非常难，但这件事还是要做，我们认为到目前为止对标可能可以做的地方就是在封闭实验厂里跑出来的数据，基本上应该可以和仿真的进行一定对标。

同时，我们在验证的过程中有几个难题，一是随机变量依赖关系模型建立，一定要考虑随机变量和随机过程，否则的话就变成了前面那张好多线纠缠在一起的图。第二个难题就是虚拟和实物路试结果对标。第三个问题，是基于随机过程的测试置信度研究。我引入了随机过程、随机变量以后可以产生成千上万个自动驾驶的工况，在这些工况下进行了仿真验证，说明没有问题了，这能说明什么？能不能比较有信心的告诉我说你跑了我随机产生的一万个工况，自动驾驶技术有90%的自信度可以上路，能不能回答这个问题？这个问题我认为回答不了，这个工作我们现在还在做。

中短期自动驾驶技术量产化路径我认为应该是以下这么几个方面，第一采用约束投入概念，即阶段性的“可控驾驶环境下的可控驾驶功能”。第二，自动驾驶技术开发全生命周期活动纳入整车产品开发流程、组织结构支持。第三，有条件的采用ISO26262作为自动驾驶技术开发和验证的规范。第四，采用模块化、增量式的自动驾驶软件开发。第五，虚拟验证中引入随机过程和随机变量的方法。第六，继续支持基于人工智能的自动驾驶技术研究。

我就和大家分享这么多，谢谢。

敬请关注盖世汽车“2018汽车与环境创新论坛”直播专题：

PC：http://auto.gasgoo.com/NewsTopic/157.html

移动：http://m.gasgoo.com/news/topic/157

提示：本文为现场速记，未经专家审核，请勿转载！