設備怎麼接到既有業務系統
把設備接到既有業務系統，先寫明設備識別碼、讀數與工單要寫進哪一套系統的哪一個欄位。欄位在那套系統裡不存在時，這一次寫入沒有去處。讀數與工單仍回到貴司已經在用的那一套紀錄。
先寫既有系統裡的那一筆
每一類要交換的資料先寫四項：哪一件設備、寫進哪一套已經在用的系統、那套系統裡的哪一個欄位、寫入失敗時交給誰。四項缺任何一項，接線還沒有落點。
系統可以是貴司已經在用的資源規劃、倉儲或維修系統。本文不另起一套平行帳。怎麼評估並接到現況，見 方案評估、原型及整合。
識別碼沿用已經核發的那一套
業務系統裡的那一筆，要用現場已經貼在設備上的同一個識別碼。識別碼由誰核發、讀取結果如何回到同一筆，見 設備追蹤用條碼還是 RFID。
租賃若已有資產登記，識別碼對上那一筆資產，見 設備租賃管理系統怎麼選。兩套系統各用各的編號時，先寫對照表：哪一個外部識別碼等於哪一筆內部紀錄，由誰在編號變更時改這張表。
讀數要落到具名欄位
2026-10-15 讀取的 OPC UA 說明 寫明，OPC Unified Architecture 於 2008 年發布，是與平台無關的服務導向架構。同一頁寫明位址空間以階層表示資料，客戶端可以依權限讀寫；訂閱在數值按客戶端條件變化時回報；方法讓客戶端執行伺服器上已經定義的程式。該頁並寫明，Client-Server 由服務端接收請求、處理並在回應裡送回結果，每一則通知給單一客戶端，並寫明保證送達。PubSub 由發布者把訊息送到中介，發布者不必知道有哪些訂閱者，訂閱者也不必知道來源，並寫明這種方式針對多對多。該頁沒有刊登日期。本文不把「保證送達」換成貴司的服務水準，也不補上該頁沒有寫的延遲或距離。
寫入之前，先記下伺服器已經提供的是讀、寫、訂閱、方法，還是 PubSub。業務系統要的欄位，對上其中一種已經存在的存取。伺服器沒有定義的方法，本文不假設可以呼叫。若讀數改走發布，承載要自帶識別碼。MQTT Version 5.0 於 2019 年 3 月 7 日成為 OASIS 標準，並寫明承載內容與協定無關。識別碼、讀數與單位由你放進承載，並與業務系統裡的同一筆相同。協定怎麼選，見 設備遙測用 MQTT 還是 HTTP。
工單沿用維修或租賃紀錄
讀數要變成維修動作時，寫回的是貴司已經在用的工單，或工單上已經存在的狀態欄位。門檻與工單怎麼交接，見 設備預測性維護怎麼做。
租賃裡的保養與歸還，同樣寫回那套租賃紀錄已經有的欄位。新產生的單號若要留在業務系統裡，先確認那套系統有地方放這個單號。沒有地方放，單號只存在於設備側，業務系統裡的人看不到。
系統沒有欄位時寫入停住
寫入前打開目標紀錄，核對識別碼、讀數或工單編號各自要進的欄位名稱。畫面與介面上都沒有該欄位時，這一次寫入停住，並在待處理清單寫明缺的是哪一個欄位、哪一筆設備。
另開一份試算表承接正式讀數，業務系統裡的那一筆仍是舊的。待處理清單只記失敗與負責人。欄位由誰向系統負責人申請、申請之後誰再試一次寫入，寫在同一行。欄位出現之前，這一筆維持未寫入。
失敗要交到有人的清單
寫入失敗、設備斷線、或伺服器拒絕存取，都落到同一份清單。每一行有設備識別碼、原定欄位、失敗時間，以及接手的人。沒有接手的人，清單只是日誌。
權限不足與欄位不存在分成兩種原因。權限不足時，寫明誰可以向系統負責人申請這一筆的寫入權。欄位不存在時，沿上一節停住，不改用另一個名稱相近的欄位頂替。
先用一小段試寫
正式接上之前，用少量已有識別碼的設備試寫。試寫紀錄寫明日期、成功寫進哪個欄位、哪幾筆因欄位或權限失敗。數量由貴司自己定，本文不代填件數。
試寫只證明這一小段欄位對得上。試寫通過之後，仍按同一張欄位表擴大。中途改欄位名稱，要回到規格那一筆，改完再試。評估與這一小段樣本怎麼安排，見 方案評估、原型及整合。
什麼時候先不要接上
識別碼尚未核發、目標系統還沒命名、或失敗清單沒有負責人時，先不要接上設備。先補這三項。
目標系統沒有欄位、也沒有人負責申請該欄位時，同樣先不要接。本文不給出上線工期或節省人力。沒有試寫紀錄之前，用「每一筆是否帶同一識別碼、欄位是否在業務系統裡真實存在、失敗是否有人接手」來檢查接線有沒有在按流程走。