边缘计算
Edge Computing
在靠近数据产生位置的设备端完成计算与决策，减少对云端往返的依赖，适用于实时性要求高或网络条件不稳定的场景。
定义
边缘计算指把计算任务放在靠近数据产生位置的地方执行，而不是全部上传到云端处理。在工业车辆场景中，「边缘」通常指车载终端或厂区内的本地服务器。采用这一架构的原因有三：安全相关的判断需要在毫秒级完成，等待云端往返的延迟不可接受；厂区内的无线网络存在盲区与波动，依赖持续联网的功能会在信号不佳时失效；视频等高带宽数据全量上传的成本与带宽压力都难以承受。因此实际系统多采用云边协同的分工——实时判断在车端完成，长期分析、跨车对比与模型训练在云端进行。
为什么不能全部放到云端
三个约束决定了纯云端方案在工业车辆上不可行。延迟方面，行人接近预警、碰撞风险判断这类功能要求从感知到输出的总时间控制在极短范围内，而数据上传、云端处理、指令下发的往返过程受网络波动影响很大，无法保证确定性。可用性方面，厂区内金属货架密集、电磁环境复杂，无线信号存在盲区，若安全功能依赖联网，进入盲区即失效，这在安全场景中不可接受。带宽与成本方面，多路视频持续上传对网络与存储的压力巨大，而其中绝大部分内容并无分析价值。把实时判断留在车端，只把结果、摘要与关键片段上传，可以同时解决这三个问题。
云边如何分工
较为成熟的分工方式是按时间尺度与数据范围划分。车端负责毫秒到秒级、单车范围内的任务：传感器数据采集与预处理、安全相关的实时判断与告警、本地缓存与断网续传、以及必要的边缘推理。云端负责分钟到月级、跨车范围的任务：多车数据汇聚与横向对比、长期趋势分析与健康评估、模型训练与更新、报表与管理功能。两者之间通过事件与摘要交互，而非原始数据流。这种分工还带来一个实际好处：即使网络中断，车端功能仍能独立工作，数据在本地缓存，恢复连接后补传，不会造成数据缺失或功能中断。
车端算力的现实约束
车载终端的算力、功耗与散热条件远不如机房设备，这对边缘侧能跑什么模型构成硬约束。工业车辆的安装环境还额外带来振动、粉尘、温度变化与电压波动，对硬件可靠性要求高于一般计算设备。因此边缘侧的模型通常需要经过裁剪、量化等优化以适配算力，且必须在目标硬件上实测帧率与延迟，而非仅看理论性能。另一个常被忽视的点是功耗——车载设备由整车电池供电，长期额外功耗会影响续航，在电量紧张的场景中并非可忽略的量。选型时应把实际工况下的持续算力需求、温升表现与功耗一并评估。
断网与数据一致性
工业现场网络不稳定是常态而非例外，因此边缘系统必须把断网当作正常工况来设计。基本要求包括：本地存储容量能覆盖预期的最长断网时长；数据带有可靠的时间戳与序号，便于恢复后按序补传并去重；补传过程不影响实时功能且能在网络恢复初期避免瞬时拥塞；关键事件优先上传，普通数据可延后。时间同步是另一个容易出问题的环节——若车端时钟漂移或断电后未及时校准，补传的数据时间戳会失真，导致后续分析中因果关系错乱。实践中应通过网络时间同步机制定期校时，并在数据中记录时钟状态供后续判断。
运维与版本管理
边缘节点数量多、分布广、物理接触不便，运维难度显著高于集中式系统。若每次升级都需要人工逐台操作，随车队规模扩大将迅速不可持续，因此远程升级能力几乎是必备的。同时需要建立版本管理机制，清楚掌握每台设备当前运行的软件与模型版本，避免出现同一车队中多个版本并存且行为不一致的情况。健康监测同样重要，应能远程感知设备的运行状态、存储余量、通信质量与异常重启记录，在问题扩大前介入。这些能力看似与业务功能无关，但在实际运行数年后，它们往往决定了系统能否持续可用。
常见问题
为什么安全功能不能放在云端处理？
三个原因。延迟上，行人接近预警这类判断要求极短的响应时间，数据上传、云端处理、指令下发的往返受网络波动影响，无法保证确定性。可用性上，厂区金属货架密集、电磁环境复杂，无线信号存在盲区，依赖联网的安全功能进入盲区即失效。带宽上，多路视频持续上传成本高昂且多数内容无分析价值。因此实时判断应在车端完成。
车载设备断网了数据会丢吗？
设计良好的系统不会。边缘侧应把断网当作正常工况：本地存储容量覆盖预期最长断网时长，数据带时间戳与序号便于恢复后按序补传去重，关键事件优先上传。需要特别注意时间同步——车端时钟漂移或断电后未校准会导致补传数据时间戳失真，使后续分析的因果关系错乱，因此应定期校时并记录时钟状态。
相关术语
本术语库收录行业通用概念，用于技术交流与知识普及，不含任何特定厂商的非公开资料。具体设备的技术参数与操作规范，请以整车厂官方文档为准。