做车联网的人都知道一个尴尬的事实车机上那一整套看起来高大上的智能驾驶、智能座舱、车控系统本质是在跟物理世界的各种不确定性搏斗。卫星信号说没就没雷达说被脏东西糊住就被糊住人说话带口音带方言还夹着音乐车停了人走了还得替你盯着有没有人踹轮胎。这套系统真正有意思的地方从来不是某个单点技术多先进而是它怎么把一堆不可靠的传感器组织成一个在绝大多数情况下都还靠谱的整体。这一篇我挑四个真实车机链路来讲都是一线工程师天天在打交道的东西隧道里 GNSS 拒止时的融合定位、多传感器感知与 3D 渲染、语音控车的全链路、以及泊车离车后的安防状态机。我不堆名词只讲底层机制讲清楚为什么这些组件要这么排布以及它们背后真正的取舍。一、先建立整车的骨架认知在讲具体链路之前必须先理解车子的电子电气架构长什么样。早年是分布式架构每个功能一个 ECU车上一百多个 ECU 各自为政线束缠成麻花算力也上不去。现在主流走的是域集中式把全车算力收拢到几个域控制器上。典型的划分是智驾域、座舱域、车控域再加一个网关和 T-Box 负责对外通信。智驾域吃的是摄像头、毫米波雷达、激光雷达、GNSS、IMU 这些信号算出来的驾驶决策要送到执行器。座舱域管的是屏幕、语音、HUD、娱乐。车控域管车身、底盘、动力直接对接MCU 和各类执行电机。网关负责这几域之间的报文路由和隔离T-Box 带着 5G 和 C-V2X把车连到云端和手机。你看到的高德、车企云、手机 App都在 T-Box 这一跳之外。高德更像一个高精地图和在线定位服务的提供方车端把原始观测数据传上去云端融合完把结果回传这就引出了本节要啃的硬骨头也就是隧道里的定位。多说一个底层区分域控制器里跑的是两种性质完全不同的芯片。智驾域和座舱域用的是大算力 SoC比如带几十到上百 TOPS 算力的车规级处理器它跑的是 Linux 或者 QNX上面能塞下神经网络、大块渲染、复杂融合算法。而真正对接电机、刹车、转向的是 MCU比如英飞凌 AURIX 这类微控制器它是实时核跑 AUTOSAR响应是微秒级的确定性不做花哨计算只保证该动的时候绝对动得了。SoC 负责想MCU 负责动中间的 VHAL 和车控框架就是把想法翻译成动作的桥梁。这个分层的本质是为了安全智驾 SoC 死机了不能让车失控所以最终执行一定握在独立实时核手里。理解了这个 SoC 加 MCU 的双芯结构后面语音链路最后那几跳为什么绕那么远就好懂了因为那是从会思考的 SoC往只会执行的 MCU做逐级降落。二、隧道里没有卫星车怎么定位到车道级这是整篇里我认为最值得讲透的部分。先说结论车进隧道前的定位精度本来就不只靠卫星卫星还只是其中一个输入源隧道里它断了剩下的源照样要把位姿续上。进隧道之前系统会在每 100 毫秒把一组观测打包丢出去。这组观测里至少包含四类信号。GNSS 接收机给出的经纬度、速度、航向这是全局基准。IMU惯性测量单元或者更完整的 INS 惯性导航系统给出的角速度和加速度它能感知车的转向、加减速而且完全不依赖外部信号。轮速里程计来自轮端脉冲车轮每转一圈发出固定数量的脉冲数脉冲就能算出轮速和行驶距离这是最朴实也最可靠的里程来源。还有陀螺仪感知横摆角速度配合 IMU 才能把车头朝向算准。把这些丢给高德做高精度融合定位背后跑的其实是经典的传感器融合算法。工程上最常见的是扩展卡尔曼滤波EKF它把 GNSS、IMU、轮速分别建模成带有噪声的过程每来一帧新观测就做一次预测加更新的迭代输出一个比任何单传感器都稳的位姿估计。再往上还有图优化graph optimization / factor graph把每一时刻的位姿和传感器约束都建成图里的节点和边一次性求全局最优精度更高但算力也更贵往往离线或半离线跑。关键来了进隧道以后 GNSS 直接拒止也就是收不到卫星信号。这时候还能靠的是 IMU/INS 的死推算dead reckoning靠上一帧的位姿加上这一帧的惯性增量一步一步把车的位置推出来。但死推算有个致命问题误差随时间积累陀螺零偏、加速度计温漂都会让推算出来的位置慢慢漂走。好消息是轮速里程计不受隧道影响它能提供相对可靠的位移把惯性推算的发散速度压一压。真正把误差兜住的是高精地图匹配。车道线、隧道壁的几何形状、匝道曲率这些都在高精地图里。融合定位的结果会和地图里的车道模型做匹配相当于告诉系统你这辆车大概率就贴着某条车道中心走横向偏差被强约束在车道宽度范围内。三者合在一起隧道里也能维持车道级位姿而且输出频率还是 100ms 一级也就是每秒 10 次。我的看法是这套设计的核心思想就一句话没有任何单一传感器值得信任但把它们用正确的统计模型绑在一起工程上就足够可信了。GNSS 给绝对基准但不连续IMU 给高频但会漂轮速给里程但不管方向地图给约束但不感知实时变化四者互补而不是冗余。看车联网定位看的就是这条互补链能不能在任一环节断裂时自动降级而不崩盘。再往算法里钻一点EKF 和图优化的取舍值得说。EKF 是递推式的每来一帧就更新一次内存占用恒定适合车端实时跑但它本质上是高斯假设下的局部最优一旦某个传感器出现非高斯的大跳变噪声它会被带偏且难以回头。图优化把历史所有帧都当作待优化变量用整体最小二乘一次性求解抗野值能力强得多但它要吃更多内存和算力而且对实时性的要求更苛刻。所以工程上常见做法是车端用 EKF 保实时云端或离线用图优化做精修和校正两者不是二选一而是分层的伙伴。还有一点常被忽视100ms 这个节奏不是随便定的。它要跟感知、规划、控制的整体闭环对齐定位慢于控制周期车就会用过期位姿做决策高速下几十毫秒的位姿滞后就是几米的偏差。100ms 基本是兼顾算力和精度的平衡点再快算力吃紧再慢安全风险上升。三、感知融合与 3D 渲染隧道里车比你看得还清楚定位解决的是车知道自己在哪感知解决的是车知道周围有什么。这一节讲车怎么把一堆传感器拼成一幅你能看懂的 3D 画面。车上挂的传感器数量很吓人用户场景里提到的是 12 路雷达加顶置激光雷达加 5 路 DVR 视频流。12 路雷达通常是毫米波雷达和超声波雷达的组合覆盖远近和盲区。毫米波雷达对速度和距离是强项但分辨率低、分不清静止物。激光雷达给的是稠密的三维点云能精准刻画障碍物的轮廓和距离。5 路 DVR 是环视加前向的摄像头负责语义红绿灯、车道线、行人姿态这些只有视觉能认。多传感器最难的不是采集是时空对齐。时间上各传感器采样频率不同雷达 20Hz、激光 10Hz、摄像头 30Hz必须靠硬件时间戳或者软件插值把它们对齐到同一帧。空间上每个传感器安装位置不同、外参不同所有感知结果都要先转换到统一车体坐标系否则前视摄像头看到的目标和侧雷达看到的目标对不上号。对齐之后的融合分两层。底层是目标级融合各传感器先各自检测出目标这有个车、那有个行人再把不同传感器对同一物理目标的描述关联起来形成更完整的目标属性位置用激光、速度用雷达、类别用视觉。再往上整车根据融合后的目标列表做 3D 场景重建把周围几百米内的所有障碍、车道、可行驶区域都塞进一个局部三维世界模型里。这里头有个工程师天天头疼的问题叫传感器各扫门前雪。毫米波雷达对静止车辆经常看不见因为静止目标的多普勒接近零容易和路牌护栏混在一起被滤掉。摄像头怕逆光和大雾激光雷达怕暴雨和扬尘。所以当某一个传感器在某个场景下退化融合层必须能从其他传感器补足而不是让盲区直接暴露给决策。这套冗余设计才是多传感器路线比纯视觉贵但更稳的根。最后这一步是给驾驶员看的。3D 智驾窗口把那个世界模型渲染成你能直观理解的三维视图旁边车、前车、匝道都标得清清楚楚。HUD 则把多车道地图信息和导航指引投影到前挡风让你视线不用离开路面。隧道里光线再差雷达和激光不受可见光影响所以这套渲染出来的画面反而比人眼看到的更可靠这也是为什么隧道里自动驾驶能成立的前提之一。讲到这里多说一句很多人以为纯视觉才是未来但现实是国内除纯视觉方案外多数车厂都是雷达加激光加视觉的多传感器路线。原因很朴素单一模态在极端工况下总会失效多模态融合是工程上更稳的活法。四、语音控车一句话怎么让方向盘转起来语音控车这条链路看起来只是个交互功能但把它完整拆开你会发现它几乎穿过了一整辆车的所有软件层级。我按真实链路一步一步讲。你喊一声唤醒词或者车觉得你可能在跟它说话唤醒引擎先触发。之后进入 ASR 自动语音识别把声音转成文字。但机器不知道你一句话哪里是开头哪里是结尾所以中间要插一个 VAD 端点检测判断你到底说完了没有没说完就继续收说完了才往后端送。文字进了 NLU 自然语言理解做意图识别。这里有个关键设计是拒识模型先拦一道。你想想看车在行驶中,周围可能有音乐、有人聊天、有导航播报系统未必每次都是被叫去干活的。拒识模型判断这句话到底是不是合法指令不是就直接忽略不浪费后面算力也避免误触发。过了拒识才进分类模型识别这条指令属于哪个领域是空调、导航、车窗还是驾驶操作。然后做提槽也就是从句子里抠出关键参数比如左转指令里的左、调温指令里的26 度。拿到意图加槽位智控场景模块就把这条指令落域到具体的智控能力上。到了落域之后还有一层仲裁这是经常被忽略但极其重要的安全闸门。系统拿到左转意图不会直接就转它会结合周围情况加上脉冲车速来判断此刻左转是否安全能不能转。能转才下发 carserver fwk 指令交给车控框架。从车控框架往下就进入了车厂经典的硬件抽象分层。指令先到 VHAL 硬件抽象层这一层把上层的语义化控制指令翻译成对具体硬件的访问接口屏蔽不同车型硬件差异。VHAL 往下通过 IPC 进到 Linux 内核内核里的驱动和设备模型把请求进一步下发到 MCU 微控制器。MCU 是真正的硬件大脑它驱动对手件也就是车上的执行机构最后由方向盘电机执行那个实实在在的转角。把整条链路数一下从一声唤醒到方向盘动一下中间跨了唤醒、ASR、VAD、NLU、拒识、分类、提槽、落域、仲裁、车控框架、VHAL、内核、MCU、电机十几个环节。每个环节都是一次独立的失败可能任何一个环节的延迟或误判都会让这次语音控制要么慢半拍要么干脆不响应。我的观点是语音控车好不好用一半在算法准不准另一半在这些层级之间的接口设没设计好尤其是仲裁那一刀切得太紧车像哑巴切得太松车会乱来。五、泊车与离车安防车停了你以为就结束了最后一个场景很生活化但你仔细想会发现它背后是一整套状态机和事件分级逻辑。车开到停车场先自动扫描闸机识别进场。然后它要搞清楚自己停在哪楼层、区域、车位号一层层上报最后发到手机上你逛完商场回来不用满场找车。这套上报链路本质是把车位状态机从行驶切到泊入再切到驻车已确认每一跳都有明确的状态转移条件。人离开车之后事情才刚开始。车上的感知系统不会关机它会持续扫描周围的移动危险物和人。这里就涉及事件分级而且是靠状态机驱动的分级,不是简单的报警。先说普通事件有人在车边逗留超过 5 秒系统判定为异常关注给车主推一条普通事件消息属于提醒级别。逗留本身不危险但持续有人在你车边晃值得让你知道。危险事件则是另一档。有人拉车门或者踢轮胎这些动作带有明确的恶意意图系统直接升级成危险事件给车主推送高优先级告警。这一档和普通事件的区别不只是文案不同它背后是不同的状态跃迁阈值和不同的下发通道优先级。普通事件可能走普通推送危险事件往往要走更高的实时通道确保你第一时间收到。为什么要用状态机而不是简单 if 判断因为真实世界的逗留和恶意动作之间没有明显边界靠车身传感器给出的目标轨迹、停留时长、接触事件这些连续量喂给状态机做多级判定才能既不过敏也不漏报。逗留 4.9 秒不报5 秒报这是时间阈值拉门是接触加位移踢胎是冲击加形变这是动作特征阈值。把这些都做成可配置的状态转移表比散落在代码里的硬编码 if 要健壮得多。讲到这里这个系列想传达的东西其实就浮出来了。国内的车联网架构,除了少数走纯视觉极简路线的大体思路都差不多原因无他物理世界的约束就摆在那里卫星会丢、传感器会脏、人会含糊、坏人会动手架构设计的全部功夫就是承认这些不可靠然后用分层、融合、仲裁、状态机这些手段把不可靠的个体拼成可靠的整体。六、写在最后回过头看这四个链路定位、感知、语音、安防表面上是四个功能底层是一套统一的工程哲学。能用统计模型消除单点不确定性的就用融合比如定位。能把异构输入统一到一套坐标和语义的就用对齐加抽象比如感知。一次控制要穿越十几个软件硬件层才能落地的就在中间垫好抽象层和安全闸门比如语音。面对连续模糊的现实输入要给出离散可靠决策的就用状态机和分级比如安防。车联网没有银弹它的优雅不在某个酷炫算法而在于把一堆会出错的零件组织成一个在出错时也能体面降级、不把人坑了的系统。这也是做架构的人最该从车里学到的东西。
