存量设备接入平台前，应该先检查什么？

一台设备的数据可能经网关和原有平台多次转发。台账应记录这条路径及管理方，避免在出现异常时无法判断是终端、网络还是上层系统的问题。

同名字段不一定同义，设备状态也可能采用不同编码。接入前需记录数据类型、单位、更新时间和缺失处理方式，不能只以接口返回成功判断完成。

断网、重启和终端更换都会影响状态。应检查恢复后数据是否补传、是否重复、时间是否正确，以及平台是否能够区分离线和正常零值。

点位新增、设备更换和账号变更都需要维护记录。物联网设备的识别、配置和更新能力可参阅 NIST 的基础能力说明；这些资料提供一般技术参考，不是客户产品认证。

终端可能直接向新平台提供数据，也可能先进入网关、原有控制系统或第三方业务平台。不同路径会影响数据刷新、故障定位与维护权限。建议为代表性设备记录完整数据路径，明确每一段连接由哪个单位负责，而不是只保留最后一个接口地址。

当新平台看不到数据时，可以沿路径逐段检查：现场终端是否工作，网关是否收到，原系统是否更新，接口是否返回，以及新平台是否正确解析。分层定位能够减少各方互相判断“不是本系统问题”的情况，也能为后续维护留下可重复使用的排查方法。

系统能建立连接，只解决了传输的一部分问题。字段可能存在不同单位、倍率、枚举值、字节顺序或时间表示方式；不同型号还可能在同名字段中使用不同含义。项目应取得对应版本的接口或设备资料，通过授权样本验证后再批量配置，不能用一个点位的结果推定全部设备。

以计量数据为例，需要确认接口给出的是累计读数还是某个区间的用量。累计值通常要结合起止时刻计算差值，且需处理表计更换、复位和数据缺失。若直接把累计值当区间量汇总，即使接口一直返回成功，也可能形成严重失真的报表。

接入方案应区分只读查看与允许写入控制。先明确业务需要哪些权限，再配置相应账号和访问范围；不要为了联调方便长期保留过大的操作权限。原厂、集成方与运营方使用不同身份，也有助于追溯配置变化和处理责任。

NIST 的 物联网安全能力目录列出设备识别、配置、数据保护、接口访问、软件更新和状态感知等能力。这里作为检查思路使用，不表示目录中的每项功能都是智联城科产品已经具备的能力，也不替代对具体终端的验证。

建议在不影响生产与公共服务的授权条件下，验证断网、重启、延迟、重复数据和时间异常的处理方式。需要确认平台能否区分离线、无数据与正常零值，恢复后是否补传，补传数据是否保留原始时间，以及是否造成重复统计。

测试不应随意改变实际在运行的关键设备。可以优先使用测试环境、备用设备或双方确认的维护窗口，明确恢复方法和停止条件。无法在本阶段验证的异常情况，应作为已知限制记录，而不是在验收表中默认填为通过。

一台设备是否保留，不宜只依据年限或品牌。需要综合判断是否满足目标数据质量、接口授权、维护支持和运行要求。若只能读取较低频的数据，它可能适合趋势展示，却不适合需要快速反馈的联动场景；同一设备在不同业务中的适用性可能不同。

建议形成逐类设备的结论：可直接接入、需补充条件、需局部改造或暂不纳入。每项说明原因与依赖，让预算和排期能够对应实际工作。批量推广前复核同类设备是否存在型号和版本差异，避免代表性测试被错误地当作全部范围已经完成。

建议保留设备类别、型号与版本、验证点位、检查时间、数据样本和结论。能够复用的配置应注明适用条件，例外设备单独列出。这样即使后续人员变化，也可以理解某一批设备为什么采用同样设置，而不是只能依赖实施者记忆。

推广过程中可以按区域或设备类型分批核对，检查新接入数据与代表性样本是否一致。若发现某类设备需要不同倍率或字段解释，应先修订分类规则，再继续扩展，避免在规模增大后才集中修正历史数据。

接入完成时，验收记录还应说明设备本身已知的维护问题。平台读到了一个长期异常的终端，不代表该终端已经被修复；接入质量和设备状态需要分别说明，才能给运营方准确的交接信息。

1. 梳理数据路径记录终端、网关、原平台与新平台之间的连接，标明各节点维护方。
2. 校对字段语义验证单位、倍率、时间、状态枚举和累计或区间含义，使用对应版本资料。
3. 确认授权范围区分只读与控制权限，采用可追溯身份，并明确原厂配合和维护方式。
4. 验证异常条件在授权环境中测试掉线、补传、重复和更换，保留未验证范围。
5. 形成分类结论按复用、补条件、改造或暂缓分类，完成代表性验证后再扩展。