2020年10月19日 | 车亭智能：车场协同式AVP的发展机遇与挑战

 佐思产研 直播间第 2 期由北京车亭智能 CTO 朱聪博士主讲。以下是讲座内容。

大家好！我是来自停简单 / 车亭智能的朱聪。今天很高兴在这里通过直播这种方式，跟大家分享我们在 AVP 方面的一些思考和积累。在此，我要感谢佐思汽研提供了这个平台。 停简单是一家做智慧停车的互联网公司，成立于 2014 年，最大的股东是阿里的蚂蚁金服和复星。目前停简单在全国 60 多个城市的近 7000 个公共停车场运营停车业务。车亭智能是停简单的全资子公司，定位是专门从事 AVP 场端基础设施的建设和运营。

今天我跟大家分享的内容大概是这么几块，首先是对 AVP 发展趋势、现状，以及现在所面临的一些挑战提出一些我们自己的理解。然后，就是停简单 / 车亭智能总结的应对方案，以及在探索中的一些实践案例。

首先，说一下 AVP 当前在国内外的发展趋势。从做自动驾驶这个行业来讲，国内外大概都是在 2015 年前后开始出现这一波风口，业内讨论 AVP 这个话题比较多的时候，应该是在 2018 年下半年和 2019 年上半年，但是到今年尤其到今年下半年以来，整个行业对 AVP 讨论的声音相对来说弱一点。现在业内听到更多的声音，是以主机厂为代表，提得更多的已经是 L3 级自动驾驶，而一些科技公司、互联网公司现在提得更多的是 Robotaxi 或者是智慧交通车路协同。 这两种趋势，其实也反映了业内两种不同的技术路线，比如热衷 L3 的核心逻辑可能是：完全无人驾驶落地应用的时间，相对还比较遥远，技术很难实现，那就往下先做 L3，既能够解决用户实际的问题，同时也能够通过场景的迭代、升级，往完全无人驾驶的方向做具体应用、做小步趋近，这是在 L3 方面的核心逻辑。 Robotaxi 和智慧交通车路协同这边的核心逻辑，大家可能是说，虽然完全的无人驾驶存在很大挑战，但是这件事情不仅是对汽车行业的一种改变，对未来的交通模式，甚至整个城市的运转方式，都会产生巨大的影响。最简单的例子，比如现在大家买房时常说的地铁房概念，大家都知道，在北京地铁房和非地铁房的差别还是很明显的，如果说有Robotaxi 和车路协同可持续地解决城市交通拥堵问题，那确实改变的不仅仅是交通本身，整个城市未来的布局规划都会发生变化。所以 Robotaxi 和车路协同虽然也很远，但是这么有价值、有意义的事，还是值得现在投入资源去做的。 我们今天在这里不直接评论，到底是 L3 还是 Robotaxi 或者车路协同他们逻辑各自的正确性，我在这里是想讲一下，这两条逻辑无论哪一条，背后其实都有 AVP，或者说如果这两条逻辑成立的话，AVP 的逻辑也是必然成立的。 为什么这么讲？首先从 L3 来讲，L3 的主要逻辑就是说这个技术挑战的难度。对于 AVP 来说，AVP 和 L3 面临的技术挑战，无论是定位还是感知，还是从规划到控制，其实没有太大区别，甚至因为 AVP 是一个低速行驶场景，因此在技术挑战上比 L3 相对还要更简单一些。另外，如果从对交通整个的影响，我们先不上升到城市的高度，就简单说对交通运行模式的影响和产生的可能变化，AVP 也是一个很好的切入点。 比如现在北京，有很多私家车主住在郊区，到市区上班，很多人会选择先把车开到临近市区五环四环的一个地铁站，然后通过地铁接驳换乘到市内，因为市内的交通太拥堵了，开车太慢。这种方式对大部分用户来说，也不具备可操作性，因为地铁站附近的停车点或者停车措施不是那么完备，不是每个用户早上开车过去都能够很方便的把车停下，然后能很快去乘地铁，大家如果在北京体验过地铁早高峰，就知道体验很不舒适。如果在地铁站附近有一个支持 AVP 的停车场所，那么我相信愿意通过这种方式停车换乘到市内的用户会更多一些，当然这只是一种畅想。如果说 Robotaxi、车路协同有可能改变城市整个的交通运输模式，那么 AVP 其实也是具备这个机会的。 从技术挑战来说，AVP 并不比 L3 高，而它不仅能为整车销售带来价值，产品逻辑、潜在价值也能为城市未来交通的规划优化带来一些新的手段和措施。因此在这里，我们要重申一个观点，AVP 还是乘用车实现大规模自动驾驶必经的一个场景。

在 AVP 的技术分类上，国内目前在中国汽车工程学会和中国通信工业协会联合做了一个团体标准。在这个团体标准里，把 AVP 的技术路线大概分为三类。这三类具体的定义，从字面上其实就很好理解，分别是 Type1（车端智能）、Type2（场端智能）、Type3（车场协同），依次表示整个系统智能化程度是在车辆端还是基础设施端，还是两边一起。当然这里要说明一下，当时在做这个团体标准的时候，我们跟国际上的 AVP 标准工作组也对接过，那边是由法雷奥、博世、电装这些企业在牵头。在国际上，这个分类方式也是大体类似的。我今天不过多阐述这里面每个技术路线的具体含义，因为我相信今天观看直播的朋友们应该多少会有一些了解的。 目前市场上主流的几个玩家，或者说主流的参与机构，我们在这里简单罗列了一下，总体来说大部分目前还是以车端智能为主，这类参与机构或者企业大部分以前也是从事 ADAS 方面相关的开发工作，他们从 ADAS 往上拓展应用场景。以电信运营商或互联网公司为代表的一些企业，他们可能更多的是从车路协同角度来切入，做车场协同式的 AVP 技术路线。 就像特斯拉马斯克的论调一样，说所有使用激光雷达做自动驾驶的都是傻子，让特斯拉的自动驾驶汽车的安全性陷入争论。AVP 的三类技术路线，也一直存在争论，但我想说这三类技术路线，纯粹从技术路线的角度来说，各有优劣，技术路线本身没有对错，决定对错的是能否商业化应用，哪一种技术路线如果能够率先实现商业落地的话，就是能够走进这个行业、改变这个行业的技术变量。 对于 AVP 来说，从产业链角度来说，对于车路协同、智能汽车所需要的传感器、芯片、通信模组、云计算等，基本上多方面都有一些覆盖。但是由于目前市场上主要的玩家还是围绕主机厂的整车开发，所以大部分玩家目前聚焦的还是车端智能的这条路线。不过我个人判断，虽然 AVP 是应用在相对封闭的场景，但只要不是应用在纯粹的 AVP 专用停车场，只要这个场景还开放给人工驾驶的车辆使用，行人还是有可能出现，那么现在车端智能这条技术路线，无论是英伟达的，还是 Mobileye 的，在环境感知方面，这个低速场景虽然可以给大家更长的反应时间，即使你说你需要的环境感知范围可以不用那么大，但是你需要感知事件的类型和多样性并不比开放交通场景容易，后面我会具体分析一下我们在停简单所运营的 6000 多个公共停车场日常遇到的各种各样的问题。 当然今天有各种各样新的传感技术，包括车端的传感技术，包括成像的毫米波雷达，包括像四线、十六线低成本的激光雷达，大大增强了车辆的感知能力，但这些东西相比车场协同这条技术路线而言，产品本身的成熟度还比较低，（后面我会详细讲一下我们方案里面所用的具体模块，它们现在的成熟程度，要比我们今天所谓大算力的模型、芯片、成像毫米波雷达、低成本的激光雷达研发的成熟度要高一些）。所以我个人判断，在未来 5 年，如果车端刚才讲的这些组合式传感器的成本、性能，没有完全达到可以跟现在车场协同里面相关模块竞争的程度，至少在 5 年内，车场协同这条技术路线还是最切实际的。

我们停简单现在全国运营的 6000 多个停车场，根据这 4 年多的运营经验，我们大概提炼出来这些停车场的一些数据。为什么要讲停车场这个场景呢？所有的系统开发、软件开发、自动驾驶开发，都要先把 ODD 的边界定义清楚，对于 AVP 来说，停车场这个交通场景就是它的 ODD，这里总结的数据可能不一定那么准确，但应该还是具有一定的普遍性和代表性。

全国公共停车场的大概数量，我们估算是在 25 万个左右，这 25 万个指的是机动车保有量超过 100 万的城市，因为我们认为在保有量低于 100 万的地方，人们对停车的痛点感受或者说对 AVP 的需求应该还不是很明显。在所有停车场类型里面，占主要的应该还是商业综合体、CBD、写字楼、综合交通枢纽等地。在这些停车场里面，大概有 80%是属于室内停车场，而且是跨层停车场。在现有的停车场场景里面，典型的人车混流、潮汐效应比较明显，就是说忙闲时段比较集中，忙时很容易堵车，堵车高峰期时，不比我们刚经历的中秋国庆期间的高速路大堵车差。 另外还有一个特点，在全国的停车场里面，我们公共停车场有一个名字叫配建停车场，它的意思是随着建筑或者房地产开发配套建起来的。这个配套建设过程，每个城市的周期和时间都不太一样，所以因为停车场建设的早晚，或者说以前住建部对停车场不像对开放道路一样有明确的国家标准、行业标准去规范，导致现在这 25 万个停车场规格非常不统一，各有各的样子，从管理上，每个地方也有自己物业方或者业主方的特色。 针对所收集的停车场场景的素材，我们大概梳理了在这里面应用 AVP、应用自动驾驶系统，可能会出现的限制问题，总结起来有以下四点。

第一，这可能在咱们人开车的时候也比较常遇到这种场景，尤其是在商场、CBD 这种人流车流比较大的地方，也就是抢车位、抢车道，我相信大家开过车的，经常会有这种经历，开下去可能会绕好几圈，尤其在大型商场，比如像万达广场等地方。 第二，在停车场里面经常会出现迷路，尤其是跨层的停车场。在一些多层停车场里，装修风格、环境特征在一个停车场往往是比较统一的，尤其在坡道上你稍不留神，转了几层后，你可能不知道自己现在在第几层了。在停车场内部也是，走一个大长廊，转几个弯后，你东南西北都不知道了。对于自动驾驶车来说，如果通过视觉方式做定位，这对机器来说是一个灾难。如果通过有源方式做定位，现在大部分停车场里 GPS 信号或者说电信网络信号还是比较差的，这是做 AVP 时面临的 TOP2 的问题。 第三，刚才讲了停车场主要是一个配建的停车场，它有一个特点是建筑结构决定了停车场主要的物理结构，房子一盖好，停车场的各种柱子、墙就在那里了，停车场划车位、划车道只能依据建筑结构本身去考虑，因此很多车位和车道的布置，跟开放道路和广场上规划车位有很大的差异。我们在修高速路、城市道路的时候，都会考虑到驾驶员的视野，或者考虑车速、车流量的因素，但是配建停车场先天就不具备这些条件，所以在配建停车场里，经常会碰到七拐八绕或遮挡，人开车进去都会觉得有视觉盲区。 第四，停车场里的管理、进出路线不像开放道路那么统一、规范，因此在这里面到底是人让车还是车让人，经常说不清楚，尤其是在人流、车流比较大的时候。在我们运营的停车场里面，业主们都有一个很强烈的需求，就是停车场里面现在可以什么系统都不装，但是一定要装监控。为什么？因为配建停车场的规划局限，虽然是低速的，但是因为每个人开车的水平、习惯不同，进出路线不规范，比较容易发生磕碰纠纷，需要摄像头来记录真相。因此，如果我们开发的 AVP 系统想在全国范围内大规模落地应用，这也是一个不得不解决的问题。

针对我们梳理的停车场场景的特色，以及这个场景里面所面临的问题，我们按照车场协同的方式，列了这样一个系统架构图。首先声明一下，这个系统架构图里面的模块，不是我们传统意义上理解的物理零部件的那种划分，我们这些模块更多还是从专业领域里面做的划分，每个模块保证它专业的独立性，至于物理的零部件，因为可能每一家的方案或者原先的积累不一样，比如车载感知这块最明显，有的可能感知、规划、决策、定位都融合在一起，甚至把地图都融合在一起，可能在有的车型上是分开的。所以后面我在继续讲这些架构里面的一些业务流程和功能逻辑的时候，大家提前有这个了解，不是在物理上的模块划分，而更多的是从专业领域方面不同的差异做了这样一个结构模块的划分。 另外要强调的一个点，在我们现在这个架构里面，我们依据车型的能力，就是现有 L2 量产车型的能力，简单说传感器大概的配置就是 5R1V，就是 5 个毫米波雷达、1 个前视摄像头，在这个基础上做的这个架构定义，当然如果说你车辆本身传感器配置更加丰富，你本身的智能化程度更高，也是同步可以兼容的，后面会具体讲兼容的地方。 车亭智能的定位，我们承担的工作主要就是 AVP 的基础设施方面，包括中心云、本地服务器、边缘云、场端感知和通信系统，也包括我们和地图系统的一些对接。至于用户这块，看我们目前的合作经验，有的在车厂那边，有的在运营方，有的在第三方，这块相对比较成熟，主要是提供人机交互的一个界面。 我们车场协同式的 AVP 系统，第一个优势对于我们目前面临场景，刚才讲的第一个痛点问题是抢车位，我们是怎么解决的呢？目前我们几个项目讨论下来，大体固化了这样一个流程。首先依靠我们场端的传感器实时采集场内车位的空闲状态、占用状态，包括车位附近的道路或者可行驶区域的状态，然后以一定频率来做状态更新，实时上报给我们的云平台。所有跟我对接过或者在我们平台上注册过的 AVP 车辆，用户之前在我们平台注册了，当然后面的那个逻辑策略肯定也是对接过的，在用户发起一键泊车或者一键召车请求之后，我会根据场端的实时车位状态给你分配一个空闲车位，并且相应会把相对交通冲突比较少的可行驶路径分配到这个车。这里面就避免了刚才我们说的跟人类驾驶员抢车位，甚至车辆与车辆之间抢车位、抢车道的情况。另外它更大的意义是，我们目前所了解到的车辆智能化程度或者说所定义的 ODD 范围，还是希望它的通行区域或者巡航区域相对来说是比较干净的，这个停车场里面是有可能做到的，我们尽可能避开一些人工驾驶的车流或者行人用户人流，通过场端来做路径规划，可以很好的解决这个问题，这是针对第一个痛点。 第二，在停车场里面经常迷失方向，不知道怎么定位，或者说通过纯视觉的方式定位可能会出现一些困难。我们现在的方案里面是在场端，我们在团体标准里面，包括 ISO 国际标准里其实也提到了这一点，就是通过在场端部署统一专门的标识，这种标识由场端基础设施的建设方负责部署、维护、更新。这个专用标识一旦部署上之后，我们会做统一的测绘，同时结合场端的感知系统会做日常的维护管理，如果有坏了、有脏了，也会做相应及时的更新。这个专用的标识，对于机器来说不是标识本身，而是这个标识数字化以后，它会把这个标识固定的 ID 和这个标识固定的位置，存在一个叫定位层的数据层里面，这个数据层根据车辆请求会发送给相应 AVP 的车辆，AVP 车辆接到这个定位层数据之后，仅仅依靠一个前置摄像头就可以了，这里面对算力、对特征提取、对标志识别，无论是 SLAM 定位也好，语义定位也好，它的特征提取对算力、对模型的要求完全不是一个维度。然后，从鲁棒性上来讲，室内定位用这种方式目前来说应该还是最高的。当然标识肯定在空间部署上，我们也发现在实际过程中，可能有一些场地的标识密度或者均匀性也会受到一些影响，所以这个定位，还是会结合车辆本身车载的一些低成本的惯性导航等，做一些航迹推算作为补充，甚至结合局部的一些 SLAM 也可以做一些补充，都可以。但是整体上来讲主要的定位或者说精准定位，我们说在停车场里面要实现厘米级的定位，应该还是通过专用标识的实时识别和匹配来实现的。这是我们作为场端建设方，针对 AVP 场景做的很好的一个手段。 然后，在这里面，我们还有一个很大的优势，相比于纯车端的方案，我们初始化定位的时候也有一定优势。我们可以通过场端的感知系统做一个外部定位，这仅仅是针对无源定位，如果是有源的像 UWB，或者自己建的差分基站的方式排除在外，无源的定位方式在重新上电的时候，在初始化定位的时候，可能需要有一个初始的输入，尤其是在一键泊车开始的时候特别明显。我们会在场边部署一个专用的泊车或者召车的起始区或完成区，在这个指定的区域，AVP 车辆停放到指定区域里面之后，我才允许你开启你的 AVP 系统，这里面其实就相当来说给了车一个相对固化的初始化位置，这个位置如果说在实际用户使用的过程当中，我们也碰到车厂的运营方，挑战我们这个问题，如果用户就是没有按照指定的泊车区域去泊怎么办，我们有场端的辅助设备提醒或者帮助车辆重新规划一个大概的初始位置，这个位置可能不那么精准，到不了厘米级，但是在米级的范围内能够给车辆做一个参考，这是场端做定位的话，有这么一个补充性优势。 第二个优势就是场端做这种补充定位，同时也可能做定位纠偏的服务。什么意思？车辆在我停车场内如果发生定位偏离，不管因为什么原因，因为航迹推算或者在标识识别或者因为本身导致当前定位出现了比较大的偏差的时候，我通过外部车辆的跟踪和车辆外部系统定位能够实时通知这辆车，让这辆车能够重新定位或者重新做一次初始化，这样能够充分保证停车场内部定位的安全。 我们针对第三类 TOP 问题，关于停车场内部盲区比较多的问题，也就是大家说的“鬼探头”，这种场景在停车场里是尤其容易常见的，比如柱子与柱子之间，有辆车原先停放在那里，AVP 的车通过的时候，这辆人工驾驶的车突然冲出来了，或者说停放着的车辆与车辆之间，突然有个人从中间走出来，这种情况在停车场里面其实是比较常见的，但是对于车载本身的传感器来说，至少在现在的传感架构下，还是有一定困难的。所以我们也会根据 AVP 车辆本身实时上报的位置，通过场端的服务器，会实时收集场端感知系统采集到的行人和车辆的状态和位置，根据 AVP 车辆的位置，我把 AVP 车辆位置周围或者它行驶路线前方 30 米移动障碍的信息，实时周期性推送给这个车，这个车具体自己怎么用，我们跟不同的 Tier1 方面也探讨过，不一定说某种程度上能解决车端传感器所有的局限，但是结合控制策略上来讲，可以有一些相对保守的措施，保证出现危险和出现“鬼探头”场景的时候，能够有足够的时间，来应对后面可能发生的碰撞的风险。 第四，ODD 状态监控，这其实是整个车场协同式技术路线里面的精髓。为什么这么说呢？因为精髓所在，就是我们现在场端能够结合现有量产的 L2 级的车，实现 L4 的应用。为什么能够实现这个应用呢？主要是因为场端能够实时帮 L2 的车监控 ODD 的状态，这个 ODD 的状态可以包括刚才说的移动障碍物，也可以包括一些静态的交通基础设施，包括车位的状态，包括可行驶区域的状态。刚才也讲了，我们整个架构定义里面是以 L2 的车型为基础，向上是可以兼容的，每个车的 ODD 边界不一样，我们也可以根据车辆本身你所定义的 ODD 的能力范围，在你能力范围之内的，我们帮你监控，场端我可能以 10 秒为周期，周期性发给你，你的 ODD 是 OK 的。但如果说场端一旦出现了超出你车辆原先定义的 ODD 范围之外，也就是说车辆本身能力之外，我会及时的至少在 1 秒的时间内通知到这个车，这就是说我们的监控预警机制。这套机制的精髓或者说这套机制的核心意义和价值，就是充分保障 L2 车型有可能能够在满足 ODD 的状态下，可能有些预警的情况我处理不了，但是在满足 ODD 边界范围之内的条件下我是完全可以运行的。 这里我们也举了两个例子，就是说在遇到一些异常事件的时候到底如何处理。比如说在可行驶区域发生了堵塞，或者有一些遗洒，这时候如果超出了这个车辆本身的范围，我们会通知到这个车，当然这个机制每家主机厂的处理机制可能会有些差异，目前来说大家倾向于的一种方案是，这个车可以重新去请求一条路径，这条路径可以基于现有的可行性区域，如果说场端具备这个条件的话，可以重新给车辆规划一条路径，避开堵塞和遗洒，让他绕开不可通行的区域。 第二个例子这种情况下不仅仅是可行驶区域有障碍物阻碍，可能还会有一些危及到车辆本身，可能会产生一些碰撞风险的事件在这里发生，比如说有可能是车流过大或者人流过大，如果说本身只是 5R1V 传感架构的话，假定只能够应对的就是一辆车、两辆车这种环境车，或者说五个人以内环境目标人的感知，超过两辆车或者五个人我就不能保证做完全全面覆盖的感知了。这时候如果我们事先定义好了这个边界，场端会及时通知车紧急停车，紧急停车之后，我们还有一个机制，并不是说这个车紧急停了之后就让这个车停在这里，让用户过去取或者让运维过去取，这样会大大增加运营成本。我们本地服务区会同步通知到云平台，由云平台的坐席人工通过场端的视频确认，通过场端的扬声器（喇叭），调度指挥一下在可行驶区域里面可能存在的异常事件，一旦可行驶区域或者路径上人流、车流满足我车辆原先定义的边界之内的话，这时候人工会通知到这个 AVP 的车，现在异常事件解除了，可以重新上电、重新开始你的巡航或者说 AVP 的过程。 这两个例子说明我们在做的整个方案，从量产可行性上来讲，或者说从运营安全性的保障上讲，应该说还是有足够的冗余和可操作性的。

车亭自 2019 年成立以来，在这块也做了不少的探索，跟行业里面的主机厂也好，Tier1 也好，也做了不少的交流。我们目前在北京中关村这边已经改造了一个停车场，这个停车场里面刚刚我们所讲的场端的几个模块都有相应部署。我们自己在奇瑞的一个小车，也做了一个初步的功能打通。同时我们去年以来跟中国汽车工程学会的 AVP 标准工作组也一直在合作和互动，将来也有可能作为标准的验证或者示范的场所，如果说今天参会的相关单位有这个兴趣的话，我们后面也可以围绕这个交流一下。

目前来讲，我们在车场协同的这条技术路线的功能流，或者说整个功能逻辑已经初步打通了，我们也做了相应的简单的一些测试验证，不能说多么完整，但基本上我们有仿真的、有实车的，因为这是一个实际运营的停车场，刚才的照片因为是晚上拍的所以看起来有些空旷，也有结合实际交通流做了一些测试。仿真这块我们测的东西是比较多、比较全的，正常使用的一键泊车、一键召车，各个模块之间数据流的实时性和正确性，基本上都验证通了，包括几个安全场景下常见的静态避障、动态避障也都验证过，包括刚刚提到的针对一些异常事件，它能不能实时的把异常事件发现，能不能实时地推送给车，车能不能及时的停下来，我们也都做了相应的验证。这是一些我们整个数据打通之后模拟的场景。
最后简单总结一下。今天跟大家分享的题目是车场协同式 AVP 的机遇和挑战。这里机遇和挑战各自总结了三点。

第一个机遇，AVP 虽然相对大交通、相对 Robotaxi、相对 L3 来说是一个小场景，但是它切切实实是用户的一个痛中之痛，停车在日常用车的生活中还是比较高频的。所以从宏观上来讲，主机厂在做一些智能化配置的时候是有这个意愿、驱动力去帮助用户解决这个痛点的。而且大家如果在北上广深的话，其实能够切切实实感受到停车难、停车不好找的现实矛盾，如果我们拔高一点，从车路协同、Robotaxi 这个角度去讲的话，AVP 其实是确保一个城市在有限停车泊位资源的现实矛盾下实现可持续发展的一个有效解决手段。因此，这两个矛盾，一个是用户需求，一个是土地资源天然的有限性，一定会驱动车辆和停车基础设施一起协同发展。这是第一个宏观层面上做协同式 AVP 的一个机遇。 第二个机遇，现在虽然说车端智能可能是市场上主流的一个声音，但是它也切切实实存在一个技术上研发的瓶颈和相应周期，目前来说在今年以来新基建包括交通强国等一系列顶层政策的引导，停车场的智能化改造，我们能够感受到业主方对改造停车场智能化，提升智能化管理，实现无人化的预期是明显加强了，这在某种程度上来讲能保证我们 AVP 的基础设施是有一定智能化基础的。 第三个机遇，以前我们说开发一个车载系统特别强调功能安全，所有的安全责任都压在主机厂或者 Tier1 的身上。车场协同这种方向某种程度上来说，当然这里面对信息安全、运营安全有新的挑战，但是这种挑战是有实实在在的商业模式在里面的，有愿意掏这个成本来承担这部分责任的主体，所以说把一个系统从单纯的功能安全分解到功能安全、信息安全和运营安全这三个维度的话，某种程度上来说用户更加愿意接受，或更加愿意使用，能够保证我们这套系统落地的可行性。 当然也存在一些现实的风险。第一个挑战，虽然停车场是一个封闭的场景，但是目前各地的法规和标准还不那么清晰，到底这是属于交通法规还是属于住建部的法规，各有各的说法，相应的行业监管和认证，包括相应的保险机制，还不是那么完善，这是政策层面和配套环境方面的一些挑战。 第二个挑战，前面讲了车场协同这个技术路线里面核心精髓就是场端对于车辆 ODD 状态的一个监控，那么车辆 ODD 范围之外异常事件自动化的识别，目前来说我们主要是通过视觉的方式来做，主要是考虑成本的原因，通过视觉的方式来做，大家知道视觉天然是靠数据、靠样本做迭代的，这本身也会有一个过程，但是这个过程相对来说，因为我们作为运营方来说，样本采集的来源和成本比车端会更加有一些优势，所以时间上来说应该还好，但这确确实实也会影响到，如果说我们这个 ODD 边界范围的异常事件自动化识别范围不能够快速成长起来的话，那其实对于这种协同式系统的适用范围、可适用停车场以及整个系统的运营成本会有一些影响。 第三个挑战，在 AVP 系统里面把场端这些东西加进去之后，会发现任何一个以前所开发的定位功能、感知功能、控制功能整个的逻辑或策略都需要发生一些调整，这对于传统做 ADAS 起家的这些伙伴来说，其实是特别不适应的，我们也在现实跟客户的合作过程当中，收到一些这样的反馈，就是做这种项目比较烦，周期相应也比以前单车的系统开发比较长，但我相信这个只是眼下的，未来随着边界或者随着功能分配越来越清晰，相信后面这些所谓开发上或者项目管理、项目协调上的困难都是可以克服的。 因为时间关系，今天跟大家的分享就到这里，谢谢大家！