让位置、姿态、进水与电力进入决策：船舶数据接入的三层架构

设备上线只是开始。如何把位置、姿态、进水与电力接入船队管理、VTS、保险与海事监管平台，建立告警、报表与闭环，是船舶项目真正的分水岭。

架构：设备、边缘、平台三层

船舶项目的数据链路通常分为三层：设备负责采集位置、姿态、进水与电力；边缘层负责协议解析、缓存与本地规则；平台层负责存储、告警、报表与业务集成。三层各司其职，任何一层都不应该承担不属于它的职责。

如果设备直接连业务系统，短期看很快，长期会失控。建议设备统一接入物联网平台，再由平台向船队管理、VTS、保险与海事监管平台提供稳定的数据服务。

• 设备层：通过 4G / AIS / 卫星 / RS485 上报原始数据，保留设备编号与时间戳。
• 边缘层：做单位换算、异常过滤、断网缓存和本地联动。
• 平台层：做资产模型、告警规则、权限、审计与 API。
• 业务层：把船队在线率、应急响应与燃油/岸电成本嵌入船队管理、VTS、保险与海事监管平台的日常流程。

数据模型先于大屏

大屏是最容易做、也最容易过时的部分。先定义资产模型：一个“设备”属于哪个“场区”、哪个“资产”、由谁负责、当前状态是什么。模型稳定后，大屏、报表和告警都可以复用。

以船舶为例，至少需要四类对象：场区、资产、设备、事件。每类对象有唯一编码和生命周期，设备更换时只迁移绑定关系，不丢历史数据。

告警不是越多越好

一线人员很快会对高频、低价值的告警脱敏。设计告警时，先问三个问题：这条告警对应什么动作？谁负责？多久内必须处理？答不上来的，先不要上线。

建议把告警分为三级：提示、需要关注、必须处置。只有“必须处置”才触发电话或强提醒，其余进入日报或工作台。每季度复盘一次误报率，持续收敛规则。

• 把失联、落水、进水、岸电异常与保险争议拆成可观测的信号，而不是直接映射成告警。
• 为每条告警定义明确的处置动作和责任人。
• 设置合理的持续时长与恢复条件，避免抖动刷屏。
• 把处理结果写回事件，形成可统计的闭环率。

从一个可衡量的试点开始

不要从“全量上线”开始。选择一个场区、一个班组、一个明确的船队在线率、应急响应与燃油/岸电成本指标，运行 4–6 周，形成前后对比。

试点结束后，用三个问题决定是否扩展：数据是否被真实使用？异常是否被更快处理？一线是否愿意继续用？如果答案是否定的，先修流程，再谈扩容。

1. 选定一个基线清晰、痛点具体的场区。
2. 定义 1 个主指标和 2 个辅助指标。
3. 打通设备到业务系统的最小闭环。
4. 每周复盘一次数据质量与告警处理。
5. 用结果而不是功能清单，决定下一阶段投入。