1. 课程导入

Robotaxi（自动驾驶出租车）正在从示范运营走向规模化商业落地。与私家车或传统网约车不同，Robotaxi 没有人类驾驶员随时感知车辆状态、处理异常，它的安全与可用性高度依赖车辆自身的健康管理能力和后台运维体系。本课程围绕"车辆健康与运维工程"这一核心命题，帮助学习者建立从传感器、执行器到云端平台的全链路认知，掌握状态监测、故障诊断、预测性维护与运营保障的方法体系。

一、学习目标：从"会修车"到"会管系统"

本课程的学习目标分为四个层次。第一层是认知层：理解 Robotaxi 与传统车辆在健康管理上的本质差异，掌握关键术语与指标体系。第二层是方法层：掌握数据采集、特征提取、异常检测、故障定位与寿命预测的工程方法。第三层是系统层：能够设计覆盖"车端—边缘—云端"的健康监测与运维架构。第四层是运营层：理解如何通过运维策略提升车队可用率、降低故障停运时间，并满足功能安全与合规要求。

二、核心概念：健康、运维与可用性

车辆健康（Vehicle Health）指车辆各子系统在规定条件下完成规定功能的能力状态。它不是一个"好/坏"二值判断，而是由多维度指标构成的连续谱，包括传感器置信度、执行器响应精度、计算平台负载、通信链路质量、电池与热管理状态等。

运维工程（Operations & Maintenance Engineering）则是围绕"保持健康、恢复健康、预测健康"展开的一整套活动，涵盖监控、告警、诊断、维修、备件、远程干预与数据闭环。对 Robotaxi 而言，运维的对象不仅是机械部件，还包括感知算法、定位模块、域控制器和云端调度服务。

可用性（Availability）是运营方最关心的结果指标，通常用"可运营时间 / 总时间"衡量。它由可靠性、可维护性和维修保障共同决定。理解这三者的关系，是后续所有技术手段的出发点。

三、整体框架：车端—边缘—云端三层健康运维体系

Robotaxi 健康与运维工程的整体框架可以概括为"三层两环"：车端负责实时感知与本地保护，边缘/场站负责快速诊断与近场维护，云端负责全局数据分析、预测与调度决策；两个闭环分别是"实时控制闭环"和"数据驱动运维闭环"。

图中车端层强调"实时性"，任何影响安全的异常必须在毫秒到秒级完成降级或靠边停车；边缘层强调"可维护性"，通过诊断工位和边缘节点把问题在近场解决；云端层强调"预测性"，利用历史数据训练模型，提前安排维护，减少突发故障。

四、行业背景：为什么现在必须重视健康与运维

Robotaxi 的运营成本结构中，车辆折旧、能源、保险和运维是四大块。随着车队规模从几十辆扩展到几千辆，运维效率直接决定单位里程成本能否下降。行业实践表明，计划外停运是最大的成本黑洞：一辆车在路中故障，不仅产生救援费用，还会造成订单取消、乘客体验下降和品牌损失。

与此同时，监管对自动驾驶车辆的安全要求日益严格。多地要求运营方具备实时车辆状态监控、故障上报和远程干预能力。健康与运维工程不再是"后台支持"，而是合规运营的前置条件。

五、案例场景：一次典型的健康运维事件

假设一辆 Robotaxi 在运营中，车端监测到左前轮速传感器信号间歇性丢失。系统首先在车端触发降级策略：限制最高车速、增强制动冗余监控，并上报云端。云端健康评估模型结合该车近 7 天数据，判断为传感器接插件松动概率较高，生成"近场检查"工单。车辆完成当前订单后自动返回场站，诊断工位读取故障码并检查接插件，确认后更换并标定。整个过程从告警到恢复运营控制在 2 小时内，未发生路中停运。

六、常见误区与复盘

• 误区一：把健康管理等同于故障报警。报警只是起点，真正的健康管理要回答"剩余寿命"和"维护优先级"。
• 误区二：只关注硬件，忽略算法与数据链路。感知模型漂移、定位跳变、通信延迟同样会导致运营中断。
• 误区三：追求零故障。工程目标是"可控降级"和"快速恢复"，而非绝对零故障。
• 误区四：数据采集越多越好。无标签、无治理的数据只会增加存储和计算成本，必须建立特征库与标签体系。

# 典型健康运维数据字段示例
vehicle_id: RTX-1024
timestamp: 2025-03-18T09:23:41Z
subsystem: wheel_speed_sensor
signal: front_left_speed
status: intermittent_loss
degradation_level: L2
recommended_action: near_field_inspection
estimated_rul_hours: 36