1. 先把问题说透中间件在自动驾驶体系里到底管哪几摊事先说个我自己的真实经历。有次在园区里做迭代测试车刚跑出去两百米感知模块突然没有任何输出车直接进入安全停车流程。查了半天不是算法崩了不是传感器断了最后定位到是中间件层的一个队列配置问题——某个消息的缓存数量设得太小上游短暂阻塞时直接往后丢数据下游等不到最新感知结果就自动降级。整个过程里激光雷达、摄像头、计算单元全是好的纯粹是管道出了问题。这件事给了我一个特别深的印象很多人聊自动驾驶聊的是感知、决策、控制是BEV、Transformer、规划算法但这些东西跑起来以后靠什么串在一起靠的正是中间件。在自动驾驶的软件架构里中间件处在操作系统和业务应用之间。它管的事情概括起来是三摊第一是通信也就是各模块之间的数据怎么传激光雷达点云怎么从驱动送到感知、感知结果怎么送给预测规划、规划轨迹怎么送到底盘控制这个链路上任何一环断了都不行第二是生命周期管理节点的启动、退出、崩溃要不要自动重启、状态怎么监控、参数怎么配置和动态更新这些如果全用业务代码自己写每个模块都得重复一堆脏活第三是部署与编排在一台域控制器里有多个进程、多块芯片甚至多个域控之间跨设备通信怎么保证正确的启动顺序、稳定的连接关系和可控的资源分配。一个比较直观的类比是操作系统管理的是文件和进程中间件管理的是自动驾驶系统里的模块和它们之间的关系。没有中间件你也能用裸的socket去收发数据、用protobuf去序列化但一旦模块数量上到几十个、上百个进程间调用关系变成一张网你就会发现所有时间都花在解决通信细节上了。中间件就是把这层能力平台化让搞感知的人专心写感知搞控制的人专心写控制。那为什么不直接每家都自研一套通信库呢可以很多公司确实这么干过但问题在于通信只是中间件的一部分调度、监控、配置、工具链、跨设备同步这些深度耦合在一起短时间内很难做得成熟。而且自动驾驶对实时性、确定性、可靠性有很强的要求数据链路不是发出去就行而是要在限定时间内必须送达、重复数据怎么办、迟到的数据怎么处理这些策略都要由中间件来承载。可以说选对中间件就是给整个软件系统搭对了骨架。这也是这篇文章想做的事情把自动驾驶领域目前真正在用、并且有代表性的中间件方案放在一起横向对比从通信模型、实时性、可靠性、资源占用、量产适配、社区生态这些角度逐项拆开讲清楚。目标读者是三类人正在做选型评估的软件架构师刚进入自动驾驶领域、想把底层通信机制弄明白的开发者以及准备面试自动驾驶中间件岗位的工程师。看到最后你会有一个比较清晰的判断依据——在什么样的场景下该用什么样的中间件以及具体落地时容易在哪里翻车。2. 主流中间件横向拆解ROS 2、CyberRT、DDS与SOME/IP各自站在什么位置这个领域目前的玩家其实并不算多但每一个背后都代表了一套完全不同的设计哲学。我按代表性来逐个讲。2.1 ROS 2从科研原型到准量产工程之间的那座桥ROS 2在自动驾驶圈子里几乎无人不知它继承了ROS 1的话题、服务、动作三种通信模型但底层放弃了ROS 1自研的TCPROS/UDPROS改成了直接跑在DDS之上。这意味着什么对比ROS 1ROS 2把QoS策略完整地带进了机器人社区。QoS是DDS体系里最核心的一套可靠性策略后面我会拿一节专门讲它这里先记住一句话它决定了消息传输是可靠还是尽力而为、消息迟到是丢弃还是排队、历史数据是保留还是只留最新的。ROS 2解决的问题是让研究者不需要关心底层网络细节就能搭起一套多节点协同系统。比如你用ros2 topic pub /cmd_vel geometry_msgs/Twist {...}往小车上发一条速度指令底层DDS会自动完成发现、匹配、序列化、传输整个过程对用户透明。这就是它最大的价值开发效率极高。但ROS 2的短板也很明显——它在嵌入式车规环境里不是为量产设计的。DDS的发现协议在节点多的局域网里会产生不小的网络冲击内存开销相对比较高实时调度策略也需要额外配置而且未经ISO 26262功能安全认证。所以在实际量产车项目里几乎看不到直接裸上ROS 2的。但有一个趋势值得注意很多量产中间件的通信抽象层都在向ROS 2的API风格靠拢这说明它的接口设计确实有相当强的合理性。2.2 Apollo CyberRT为自动驾驶场景而生的确定性框架如果说ROS 2是通用机器人领域的产物那百度Apollo的CyberRT就是完全冲着自动驾驶场景长出来的。CyberRT在设计之初的定位就很明确高并发、低延迟、确定性调度。它跟ROS 2最大的不同在调度模型上。ROS 2的node默认跑在系统线程上调度的实时性主要依赖底层操作系统的优先级策略CyberRT则在自己的运行时里内置了协程调度器用协程来承载计算任务将同进程内的消息传递做成了类似函数调用级别的开销。这种设计让CyberRT在单机多模块场景下的时延和CPU占用都相当有优势尤其适合Apollo这类需要在一个计算单元上同时跑感知、预测、规划、控制的场景。在通信层面CyberRT提供了两种机制同机场景优先走共享内存通道数据发出去不需要序列化直接引用内存指针极大降低拷贝开销跨机场景才回退到网络通信。读过CyberRT源码的人会发现它的transport层把共享内存做得非常精致从内存池、slot、分段上的设计都有很多值得学习的地方。CyberRT的另一个特色是组件模型。一个Component声明了读者和写者框架负责在数据到达时触发对应的处理函数这种数据驱动的调度模型比ROS 2里手动写循环要省心很多。组件还支持按优先级调度模型推理这种延迟敏感的任务可以拿到更高的执行优先级。局限性也存在CyberRT跟Apollo整体的构建体系绑定得比较深它的模块管理、参数中心、启动脚本甚至底层的各类组件都跟Apollo的工程形态紧密耦合。想只把CyberRT这一层抽出来给别的项目用虽然有开源代码但需要额外做不少适配工作。2.3 SOME/IP与Adaptive AUTOSAR量产车里的正牌军如果你在传统Tier 1或OEM做量产域控制器SOME/IP这个名字你大概率不陌生。SOME/IP的全称是Scalable service-Oriented MiddlewarE over IP翻译过来就是基于IP的面向服务的可扩展中间件。它不是为机器人社区设计的而是汽车工程界为了解决ECU之间、域控制器之间的服务化通信而定义的标准归属在AUTOSAR Adaptive Platform的通信栈里。这套体系的核心是服务发现SDService Discovery。一个ECU要提供某项服务比如读取车速、切换驾驶模式它会周期性地对外广播自己的服务可用性另一个ECU想调用这个服务同样通过SD去主动查找。这种服务发现机制和DDS有些相似之处但SOME/IP在设计上更偏向量产的确定性控制——服务的实例标识、通信的端口和协议、数据格式都要求预先在配置阶段确定好几乎不给你运行期自由发挥的空间。SOME/IP支持两种交互模式请求/响应类似于RPC和事件通知服务端主动推送。数据序列化采用传输层缓存友好的设计。在底层传输上可以选择UDP或TCP配合SOME/IP-TP做大包分片传输。对于量产车里的ECU间调用这套机制成熟、可控、可预期而且有完整的AUTOSAR工具链支撑从模型设计到代码生成再到集成测试都是现成的。但SOME/IP的问题在于它的开发效率。它不是一个拿来就能跑的开源框架而是需要配合整套AUTOSAR方法论才能发挥价值的规范很多公司用的都是商业方案比如Vector、ETAS、Elektrobit的协议栈。对于做原型验证、算法研究的团队来说这套东西太重了。2.4 原生DDS连接标准、性能与灵活性的中间地带ROS 2用DDS做底层但DDS本身也可以作为自动驾驶的中间件独立使用。OMG定义的DDS规范一共有两个关键层以Topic为中心的发布订阅模型DCPS和以数据类型为中心的监听/读写接口DLRL。简单理解它把系统里的所有数据都抽象成全局共享的数据空间任何节点都可以往某个Topic写数据、从某个Topic读数据节点之间不需要点对点建立连接。DDS最强大的一点是QoS策略极其丰富。你可以指定消息的可靠性RELIABLE还是BEST_EFFORT、历史保留策略保留最近几条还是全部、数据生命周期、自动清理时间、所有权与优先级等。这意味着你可以把一条数据链路的通信策略精细地调到和场景完全匹配感知点云用尽力传输没关系丢了就丢最新的车辆控制指令则必须可靠送达。市面上的DDS实现有好几款Eclipse Cyclone DDS以高吞吐和启动快见长Fast DDS在ROS 2生态里用得很广RTI Connext是商业产品里功能最完整的另一个商业实现的存在感也很强车规级支持做得不错。在那些需要车路协同、多域控通信、异构平台互通的场景里原生DDS的跨平台和去中心化能力非常有价值。它的问题在于DDS标准本身比较高成熟好用的实现又往往要收费完全靠开源方案做量产级系统还需要做不少补充工作比如功能安全认证、代码规模裁剪、跟现有车载网络架构的融合等。下面这张表是我整理的主流中间件特征对照几个关键的维度缩在一屏里方便整体看维度ROS 2Apollo CyberRTSOME/IP (Adaptive AUTOSAR)原生DDS通信模型发布订阅 / 服务 / 动作发布订阅 / 请求响应服务请求响应 / 事件通知全局数据空间发布订阅底层传输DDSFast/Cyclone等共享内存 网络通道UDP/TCP SOME/IP-TP共享内存 / UDP / TCP实时性能力中依赖DDS与OS高协程调度共享内存高配置确定性强中到高依赖实现与配置可靠性策略QoS全面有可靠传输与队列策略服务状态与超时控制QoS最丰富资源占用偏高中低单机共享内存低专为ECU控制调用设计中等过高需裁剪车规认证生态基本无无公开认证件AUTOSAR体系完备部分商业实现有认证典型场景科研、原型验证Robotaxi、L4预研/工程化量产ADAS、整车SOAV2X、跨域、混合异构系统一句话总结没有完美的中间件只有最合适的取舍组合。科研和早期原型开发ROS 2是起步成本最低的选择做L4类系统且在Apollo生态内CyberRT的工程效率很漂亮进量产车控领域SOME/IP和Adaptive AUTOSAR是绕不开的标准遇到多域跨车、互通要求极高的系统原生DDS会体现出很大的灵活度。3. 选型时真正要看的四个维度可靠性、实时性、资源占用与生态约束很多人选中间件时会陷入一个误区谁的宣传数据好看就选谁或者哪个火就追哪个。但在实际项目里决定一个中间件能不能用的往往不是单个指标而是四个维度共同作用的结果。选错了前期开发速度可能不受影响等到联调、路测、过车规的时候才开始返工代价就非常大了。3.1 可靠性维度重传、缓存与静默丢数据的陷阱先说可靠性。自动驾驶系统里对可靠性的要求是分级的对于底盘控制指令、安全状态心跳这一类消息必须做到可靠传输一旦丢了一条轻则控制抖一下重则直接触发安全机制对于激光雷达原始点云、图像数据这类高频大包追求每一条都要可靠送达是不现实的网络拥塞时旧的感知数据本来也就没有意义了所以通常在尽力传送的基础上配合新鲜度策略。中间件的可靠性设计主要体现在三件具体的事情上。第一是消息确认与重传可靠模式下发送方会缓存已发送但未确认的消息必要时重传第二是队列与缓存策略接收端和发送端的队列长度限定了消息可以滞留多少条这直接决定了来不及处理的时候是丢弃还是积压第三是故障感知通过对端心跳超时、进程崩溃通知等手段让系统能及时感知链路的失效状态。我在实际调试中最常踩的坑就是静默丢数据。中间件不会告诉你消息丢了它会在队列溢出时默认丢弃旧消息让接收端永远只看到最新的一条。这在大多数情况下是合理的但如果你没有意识到缓存策略改变了消息交付语义就可能出现下游明明在线却长时间没收到新数据这类诡异问题。3.2 实时性与确定性时延均值好看不如最坏情况可控自动驾驶场景下中间件对消息链路的时延要求按链路类型有很大差异。控制回路的时延敏感度最高从感知结果到执行机构整个闭环能留给端到端的裕量往往只有几十毫秒而像高精地图加载、日志回传这类离线数据时延就算涨到秒级也没有影响。选型时不要只看平均时延更要看重尾时延和确定性。有实测数据表明同一个通信中间件在高负载情况下99分位时延和平均时延之间可以差一个数量级。对于控制模块真正需要关心的是最坏情况下的时延上限能不能兜住。中间件里影响这一点的因素主要包括调度模型是否支持优先级抢占组播共享内存是否开启消息序列化时是否有隐藏的拷贝路径发送队列是否会有突发拥塞。在实时性上CyberRT的协程调度共享内存方案比纯网络传输的方案有天然结构优势。如果用量产语义更强的SOME/IP时延表现会很稳定因为很多机制都是预配置的参数空间小但代价就是灵活性低。3.3 资源占用在MCU上不能叫吃内存那叫内存紧张下的精细运营资源占用这个维度在PC或工控机上讨论价值不大一旦上到量产域控制器特别是MCU级别的控制器记忆体是以KB为单位计量的。DDS这类通用中间件全量跑在MCU上是不现实的光发现协议和状态管理模块就能吃掉几十KB的RAM还不算传输缓冲区。这就是为什么量产ECU之间更喜欢SOME/IP的原因——它的协议栈可以裁得非常薄代码量和内存占用在严格优化下可以做到满足典型ECU资源约束。在芯片丰富的座舱域控或智驾域控上资源约束则主要体现在CPU占用和内存带宽。零拷贝技术在这里很重要共享内存如果能避免拷贝点云这类大数据的CPU消耗能低一个量级但如果实现不小心引入边界对齐问题或缓存一致性问题性能反而会更差。3.4 生态约束中间件选的不只是软件是整条工具链和产业配套很多工程师选中间件只看技术指标忽略了生态约束这是最容易在后期付出代价的部分。所谓生态约束包含几个层面第一协议栈的商业授权和功能安全认证状态这决定了它能不能用在量产车上第二配套的工具链比如调试工具、诊断接口、录包回放工具、监控面板是不是够用第三团队里有多少人真正熟悉这个中间件招聘市场是否能招到有经验的人这直接关系到项目排期和风险管理。以CyberRT为例它的生态基本在Apollo社区内部有一个特点是你得到的是一个已经帮你选好一切的完整框架——通信、调度、参数中心、录制回放都是配套的。而原生DDS的组件独立性更强但也意味着你要自己组合拼装一套工具链。ROS 2生态虽然丰富但在嵌入式与车规工具链上存在明显空缺。这个维度很难用几个数字做量化但经验告诉我它往往是最终拍板时最重要的依据。下面这张表是我评估一个中间件方案时习惯用的记分卡大家可以直接拿去做选型参考评估维度核心问题典型的绿/红灯信号可靠性消息是否会丢、是否会重复、故障能否感知绿有完整QoS控制红只能选可靠/尽力两档实时性99分位时延是否能接受、调度是否可控绿内置协程/优先级调度红线程模型完全依赖OS资源占用内存/CPU能否满足硬件预算绿有零拷贝、可裁剪红全量功能无裁剪选项生态约束工具链、社区、认证、招聘是否配套绿有量产先例红只在demo阶段见过4. 调试中间件问题时我踩过的坑从现象到根因的完整复盘这里分享几个我在不同项目里实际遇到过的中间件问题。每个问题在表象上都像是业务代码写错了或者硬件有问题但查到最后都指向了中间件本身的配置或设计细节。我尽量把排查思路写完整方便大家以后遇到类似现象时能少走弯路。4.1 QoS参数不匹配节点都在线就是收不到数据现象是用ROS 2搭了一套多节点测试环境两个节点都在线各自的Topic列表里能看到对方但其中一个节点就是收不到另一个节点的消息。tcpdump看网络包数据明明有在传接收端却始终没有任何回调触发。从现象到定位首先怀疑是网络问题但发送端的log显示它还在发接收端log也显示订阅关系建立正常接着怀疑是话题名拼写或类型定义不一致检查之后也没有问题。最后把两个节点在启动时打印的QoS配置打出来对比才发现发送端的reliability策略设置成了RELIABLE接收端设置成了BEST_EFFORT两边没有匹配上。DDS契约里这种策略不匹配而且没有兼容策略兜底时通信就是建立不起来的。这件事让我记住了一个原则在多语言、多模块协作的项目里中间件的QoS配置必须作为一种契约文档像接口定义一样纳入review范围而不是大家各写各的。否则早期开发阶段偶尔收不到和完全收不到这两种现象排查起来的成本完全不一样。4.2 网络发现风暴节点上百个之后局域网被协议报文挤爆第二个坑是在一个比较大的仿真集群里遇到的。原本几十个节点跑得挺稳后来为了做并行的场景测试一台机器上起了上百个节点整个局域网的网络延迟突然变得非常不稳定控制指令时不时超时。排查过程是先看CPU发现业务CPU负载不高再看网络流量发现组播流量异常大占了将近40%的带宽。深入了解发现DDS的发现协议在最简单配置下每个节点都会通过组播周期性地发布存在告知信息节点数量一旦上来组播包互相叠加会让每个节点都收到大量与自己无关的发现报文形成一种发现风暴。解决方法是调整发现协议的行为让本机节点优先通过共享内存或本地回环通信跨机发现再走组播同时把发现信息中的租约时间、探查周期调大。另外一个土办法是尽量避免单机起太多完全独立的DDS DomainParticipant改用进程内共享同一Participant的方式能显著降低发现报文的数量。这提醒了我在做大规模测试之前先对网络发现的行为做一次容量评估别等集群上了再去救火。4.3 共享内存的零拷贝陷阱省了拷贝但引入缓存一致性问题说到零拷贝CyberRT在共享内存通道的实现里做得很漂亮但它对使用方式是有隐性要求的——它直接暴露内存块给读取方如果读取方要长时间持有这块内存引用要么自己做一份拷贝要么确保写入方不会篡改数据。有一次我们为了省一份copy让下游模块直接持有了共享内存中的引用并在处理完之后延迟释放。结果同一块内存被复用后旧数据还没有消费完新数据就覆写上去了下游拿到的是拼接了一半的新旧数据出现了非常难查的偶发数据异常。后来我整理了三条纪律第一尽量让共享内存的生命周期和消息消费生命周期严格对齐消费完立刻释放不要延迟第二如果确实要持有引用必须自己做一份深拷贝同时评估这份拷贝的成本是否真的比共享内存的收益大第三在压测场景里专门记录内存复用次数和异常出现频率之间的相关性帮助快速定位类似问题。4.4 背压没处理好上游一堵下游雪崩最后一个坑是关于办理流程的。在一个流式数据处理管线里感知模块以固定帧率往规划模块发结果规划模块处理一帧的时间偶尔会超过帧间隔。默认情况下发送队列是有限的队列满了之后新消息会把旧消息挤掉。短时间的积压还能接受但一旦规划模块卡了一两秒队列里的帧全被冲掉规划模块会突然收到一帧时间跳变很大的新数据导致规划轨迹出现大幅度摆动。这个问题的根因不是规划算法而是中间件缺乏时间戳校验和背压反馈机制。后来我们在中间件层加了一组分发的时间戳校验规则如果发现前后两帧的时间戳差值超过阈值就丢弃后帧并报警同时把发送端的背压信号暴露出来当队列积压到一定程度时让上游主动降低输出频率而不是默默丢帧。这个改动让整条链路的稳定性提升了一个档次也让我认识到中间件层看起来简单的队列和背压策略在链路设计里值得被当成一等公民来对待。4.5 问题排查的通用套路把这几次排查经验总结成一套固定的排查顺序在以后遇到中间件相关问题时我基本都按这个来先看通信双方的QoS配置是否互相满足不少问题都出在这。再看网络层报文确认数据在传输层面的状态排除发现协议和路由因素。检查队列深度和缓存策略确认有没有溢出丢弃的行为。验证共享内存或传输层的拷贝路径确认是否存在数据复用时序问题。最后看业务逻辑中对时间戳和消息新鲜度的处理是否合理。多说一句中间件问题的排查有时候比业务代码问题更磨人因为现象往往是偶发的、分散的。准备一套稳定可复现的压测方案以及一整套完整的log采集和回放工具比什么都重要。5. 中间件技术的演进方向与一条可落地的学习路径中间件这个领域并不是静止不动的。从这些年行业的变化来看有几个趋势比较明显。第一个趋势是面向服务架构SOA在整车软件里的普及。传统ECU之间的信号通信正在向服务调用转变这种转变和SOME/IP、DDS进入车载网络的时间线基本重合。未来车内除了传感器数据流这类传统的发布订阅通信会有越来越多按需调用的服务课堂上的服务发现会成为和数据分发平起平坐的核心能力。第二个趋势是确定性通信与时间敏感网络TSN的结合。TSN技术逐步上车后中间件需要更好地利用TSN提供的确定性时延能力。这里的挑战在于中间件如何把TSN的流预留机制和业务QoS映射起来保证关键数据流的传输不受其他数据流的干扰。第三个趋势是中间件与AI计算框架的深度耦合。越来越多的感知模型跑在GPU/NPU上中间件要能在专有硬件之间高效搬运数据把数据从相机进入、模型预处理、推理、后处理到结果分发的整条数据管线串起来。这个过程里中间件不能只停留在传输数据的层面还需要考虑任务编排、资源隔离、优先级调度等这些更接近一个轻型运行时runtime的能力。所以未来中间件与推理引擎、数据管线的边界会越来越模糊很多产品形态可能会融合。说回学习路径。如果你是一个刚接触这个领域的学生或转行工程师又正好在准备中间件相关的工作面试这条路径我本身的面试经验就是按这个顺序准备的建议按下面的顺序一步步来。第一步先把ROS 2跑熟。装个Ubuntu跟着官方教程把topic、service、action三者都写一遍小例子理解节点、话题、消息、QoS这几个最基本的概念。然后跑通一个简单的多节点系统比如摄像头节点加一个显示节点看几行日志数据是怎么流转的。这一步的目标不是成为ROS 2专家而是要建立起分布式系统里模块间如何通信的直觉。第二步深入阅读一个DDS实现的代码或者源码。选一个你项目里实际用到的开源实现把RMW层和底层实现的关系弄明白。重点关注它的QoS是怎么映射到具体传输行为的发现协议是怎么工作的共享内存通道是怎么实现的。这一步能帮你从会用API升级到知道为什么。第三步去读CyberRT的源码重点看它的调度器和共享内存通道。把它的Component模型、协程调度策略、数据分发策略和ROS 2的对应机制做对比。如果能把CyberRT移植到自己的测试工程里跑通体会会更深。第四步找一套完整的自动驾驶demo无论用仿真平台还是开源的自动驾驶项目把整个链路从传感器数据到控制输出完整跑一遍并在其中观察中间件在整条链路上的角色。跑通之后试着人为制造故障比如杀掉某个节点、往网络里注入丢包、把某个Topic的QoS改掉看看系统会怎样表现。这种故障注入的实验是面试里最能体现你对中间件理解深度的素材。整个过程中有几个核心知识点需要反复咀嚼发布订阅模型的语义和边界、共享内存与网络传输的适用场景、QoS各参数的含义和相互作用、服务发现的原理和代价、进程调度的确定性从何而来。把这些吃透了再回头看任何一款中间件都会有种它不过是在这些基本原语上做组合优化的感觉。6. 最后分享两个我在实际选型中的小建议这篇文章从中间件的定位讲到具体方案又从选型维度聊到实战排查内容已经不算少。最后不做什么系统性总结了就把我个人在项目里沉淀下来的两条经验分享给各位。第一中间件选型没有一步到位这回事。一家公司的技术栈往往由多个阶段拼成早期做算法验证时用ROS 2中期出了原型车后切到CyberRT或基于DDS自研一套量产阶段再引入SOME/IP做车载服务化。与其纠结哪个是最好的不如把精力放在定义好通信契约和模块边界上这样才能让后期切换中间件的代价可控。我在项目中实践过一套做法在系统配置里定义服务接口的数据组织规则统一用DDL描述后再映射到具体中间件的消息类型业务层只和统一描述层打交道换中间件时只需要换适配层。第二中间件的问题往往要到系统压力上来之后才会暴露。所以任何项目在正式提交之前都值得做一轮比预期更狠的压测包括大幅提高消息频率、模拟节点崩溃和网络丢包、让链路长时间满负载运行。这个过程越早做后面联调踩的坑就越少。别等到路测时才发现中间件层有静默丢数据的风险那时候再回头排查代价完全不一样。从我的观察来看一个能把中间件原理和应用都吃透的工程师在团队里扮演的往往不只是会用某套框架的角色而是那个能解释为什么系统在极限情况下会出这种问题的人。希望这篇文章能帮你把这块拼图补上。