设备怎么接到既有业务系统
把设备接到既有业务系统，先写明设备识别码、读数与工单要写进哪一套系统的哪一个字段。字段在那套系统里不存在时，这一次写入没有去处。读数与工单仍回到贵司已经在用的那一套记录。
先写既有系统里的那一笔
每一类要交换的资料先写四项：哪一件设备、写进哪一套已经在用的系统、那套系统里的哪一个字段、写入失败时交给谁。四项缺任何一项，接线还没有落点。
系统可以是贵司已经在用的资源规划、仓储或维修系统。本文不另起一套平行账。怎么评估并接到现况，见 方案评估、原型及整合。
识别码沿用已经核发的那一套
业务系统里的那一笔，要用现场已经贴在设备上的同一个识别码。识别码由谁核发、读取结果如何回到同一笔，见 设备追踪用条码还是 RFID。
租赁若已有资产登记，识别码对上那一笔资产，见 设备租赁管理系统怎么选。两套系统各用各的编号时，先写对照表：哪一个外部识别码等于哪一笔内部记录，由谁在编号变更时改这张表。
读数要落到具名字段
2026-10-15 读取的 OPC UA 说明 写明，OPC Unified Architecture 于 2008 年发布，是与平台无关的服务导向架构。同一页写明地址空间以层次表示资料，客户端可以依权限读写；订阅在数值按客户端条件变化时回报；方法让客户端执行服务器上已经定义的程序。该页并写明，Client-Server 由服务端接收请求、处理并在响应里送回结果，每一则通知给单一客户端，并写明保证送达。PubSub 由发布者把消息送到中介，发布者不必知道有哪些订阅者，订阅者也不必知道来源，并写明这种方式针对多对多。该页没有刊登日期。本文不把「保证送达」换成贵司的服务水平，也不补上该页没有写的延迟或距离。
写入之前，先记下服务器已经提供的是读、写、订阅、方法，还是 PubSub。业务系统要的字段，对上其中一种已经存在的访问。服务器没有定义的方法，本文不假设可以调用。若读数改走发布，承载要自带识别码。MQTT Version 5.0 于 2019 年 3 月 7 日成为 OASIS 标准，并写明承载内容与协议无关。识别码、读数与单位由你放进承载，并与业务系统里的同一笔相同。协议怎么选，见 设备遥测用 MQTT 还是 HTTP。
工单沿用维修或租赁记录
读数要变成维修动作时，写回的是贵司已经在用的工单，或工单上已经存在的状态字段。门槛与工单怎么交接，见 设备预测性维护怎么做。
租赁里的保养与归还，同样写回那套租赁记录已经有的字段。新产生的单号若要留在业务系统里，先确认那套系统有地方放这个单号。没有地方放，单号只存在于设备侧，业务系统里的人看不到。
系统没有字段时写入停住
写入前打开目标记录，核对识别码、读数或工单编号各自要进的字段名称。画面与接口上都没有该字段时，这一次写入停住，并在待处理清单写明缺的是哪一个字段、哪一笔设备。
另开一份试算表承接正式读数，业务系统里的那一笔仍是旧的。待处理清单只记失败与负责人。字段由谁向系统负责人申请、申请之后谁再试一次写入，写在同一行。字段出现之前，这一笔维持未写入。
失败要交到有人的清单
写入失败、设备断线、或服务器拒绝访问，都落到同一份清单。每一行有设备识别码、原定字段、失败时间，以及接手的人。没有接手的人，清单只是日志。
权限不足与字段不存在分成两种原因。权限不足时，写明谁可以向系统负责人申请这一笔的写入权。字段不存在时，沿上一节停住，不改用另一个名称相近的字段顶替。
先用一小段试写
正式接上之前，用少量已有识别码的设备试写。试写记录写明日期、成功写进哪个字段、哪几笔因字段或权限失败。数量由贵司自己定，本文不代填件数。
试写只证明这一小段字段对得上。试写通过之后，仍按同一张字段表扩大。中途改字段名称，要回到规格那一笔，改完再试。评估与这一小段样本怎么安排，见 方案评估、原型及整合。
什么时候先不要接上
识别码尚未核发、目标系统还没命名、或失败清单没有负责人时，先不要接上设备。先补这三项。
目标系统没有字段、也没有人负责申请该字段时，同样先不要接。本文不给出上线工期或节省人力。没有试写记录之前，用「每一笔是否带同一识别码、字段是否在业务系统里真实存在、失败是否有人接手」来检查接线有没有在按流程走。