先列資料用途 再選通訊模型
如果十台系統都要取得相同資料，先不要因為有十台就直接改用PubSub。你要先分清楚它們只是接收數值，還是需要瀏覽點位、讀取指定值、呼叫方法及取得歷史。OPC UA Client/Server與PubSub可互補，選型要看資料用途、網路範圍、延遲、完整性和設備實際支援。
| 問題 | Client/Server | PubSub |
|---|---|---|
| 互動方式 | 服務請求及Subscription通知 | Publisher傳送DataSet訊息 |
| 資料接收 | Client建立Session及監看項目 | Subscriber依匹配設定解析 |
| 典型需求 | 瀏覽、讀值、方法、歷史查詢 | 同一資料集分發多個接收者 |
| 必要確認 | 服務與訂閱資源限制 | 訊息及傳輸映射支援 |
| 可否直接互換 | 原有服務呼叫有各自語意 | 不能只換URL當成完成遷移 |
PubSub的訊息表示與網路傳送分成不同層次。UADP或JSON是訊息映射選擇，UDP或MQTT是傳輸映射選擇；不能把UADP當成UDP同義詞，也不能說所有PubSub都用UDP。哪些組合可用，要比對規格Profile和兩端產品的支援清單。
本篇十台消費者是離線設計情境，沒有指定PLC或SDK型號。若現有產品只支援Client/Server，即使規範定義PubSub也不能直接開啟不存在的功能。先把目前設備能力列成已支援、需授權、未支援及待確認四類，再討論採購或改造。
十台消費者的需求拆解
假設六台同網段監看端每100ms需要一次最新狀態，允許少量中間樣本遺失但要求顯示資料過期；另外四台跨網段分析端每秒接收資料，重視歷史完整與缺口說明。這裡的監看端不直接控制機械，不能把允許漏樣本的規則套到安全聯鎖。
| 需求群組 | 六台現場監看端 | 四台分析端 |
|---|---|---|
| 更新需求 | 100ms最新狀態 | 每秒分析資料 |
| 網路 | 同一受控網段 | 跨網段 |
| 完整性 | 可漏中間值，需過期標記 | 需定義補送及去重 |
| 候選方案 | 保留Subscription或評估UDP PubSub | 聚合服務或MQTT PubSub |
| 額外條件 | 多播、接收端匹配、逾時 | broker、授權、schema及儲存 |
方案一維持十個Client各自建立Subscription，優點是既有Browse與Read流程可沿用；成本是伺服器要管理各Session、監看及通知資源。也可由一個受控聚合服務訂閱來源，再提供資料給其他系統，但這會增加一個需要監控及備援的元件，且不能假設所有下游協定語意自然保留。
方案二讓資料來源發布一個DataSet，由多個Reader接收。現場可以評估UDP映射，分析端可以評估MQTT映射，但不必強迫兩群使用同一種。若來源無法同時支援，需確認是否有合適的轉換端；轉換會帶來時間戳、品質與型別責任，不能只比較網路流量。
初步結論應寫成條件：只有來源與接收端都支援所需Profile、資料品質欄位及運維能力時，才保留PubSub方案。支援表未齊前，選型仍是候選，不能把離線比較寫成已證明PubSub更快或更可靠。
用流量算式看懂比較邊界
先用一個刻意簡化的預算：每份完整資料集400 bytes，每秒十份，十個接收端都要相同內容。不計各層標頭、重送、加密與metadata，若來源對每個Client各送一次，來源應用資料量為400×10×10=40,000 bytes/s。這是對照模型，不是OPC UA實測封包大小。
| 設計假設 | 來源側純資料 | 還沒算進去 |
|---|---|---|
| 十份各別傳送 | 40,000 bytes/s | 各Session及協定開銷 |
| 一次UDP多播 | 4,000 bytes/s | 交換器出口複製及接收成本 |
| 一次送broker再分發 | 來源至broker 4,000 bytes/s | broker至十端共40,000 bytes/s |
| 降為每秒一份 | 上述數字各除十 | 資料新鮮度需求是否仍滿足 |
多播降低來源重複傳送，不等於整個網路只有一份成本；交換器仍要把流量送到需要的出口。經broker分發也不是零成本，broker需管理連線、授權與下游傳送。這張表只回答來源重複傳送量，不回答端到端延遲、CPU負載或故障恢復時間。
原先十台分成100ms與1s兩群，不能直接把全體十台都套進同一更新率。若分別逐端傳送，六台每秒十份加四台每秒一份，純資料量為400×(6×10+4×1)=25,600 bytes/s。先對齊需求再比較，否則把慢速分析端也升成100ms會平白放大負載。
封包大小要另測。UDP設計需核對路徑MTU與所選映射的訊息大小及分段處理，不能只看到1600 bytes就對所有網路宣稱一定可用或一定失敗。以實際編碼後的NetworkMessage及網路條件測試，記錄遺失和重組行為，再決定資料集切分。
Reader收到訊息後還要核對什麼
接收端收到封包不等於能正確解碼。把PublisherId、WriterGroupId、DataSetWriterId、DataSetMetaData及欄位型別列入匹配表，按所選映射及內容遮罩核對實際攜帶哪些欄位。MQTT topic相同也不保證兩端理解同一份資料集，metadata版本改變必須有對應更新流程。
| 失敗現象 | 先查 | 完成後應看到 |
|---|---|---|
| 完全沒訊息 | 來源發布、路由、多播或broker訂閱 | 接收端有正確來源的訊息 |
| 有訊息不能解析 | 映射、metadata、Writer匹配 | 每欄型別及單位一致 |
| 數值看似合理但串位 | 欄位順序及版本 | 固定樣本逐欄重算一致 |
| 間歇過期 | 發布率、逾時、網路與處理積壓 | 過期狀態及恢復時間可追溯 |
| 重連重複資料 | 重送與事件識別契約 | 業務不重算，留送達紀錄 |
UDP沒有自動替每個接收端提供可靠歷史補送，應設接收逾時和資料品質。MQTT的QoS及會話機制也不能自動保證分析資料庫不重複。完整歷史需求要另外安排事件識別、保存範圍及補送介面，不能只在選型表勾可靠傳輸就算解決。
安全也要分層。MQTT TLS保護Client到broker的連線，不自動代表broker無法看到內容；PubSub訊息安全是另一層能力，需按Profile核對支援、金鑰分發與輪替。UDP多播的網路隔離也不能取代訊息來源驗證，具體部署要看產品安全能力。
驗收練習與常見問題
離線練習先準備同一資料集的三欄：溫度Double、累計UInt32、品質欄位，明寫它們的順序及單位。列出十個接收端的能力，再模擬metadata升版把累計移到第一欄。預期舊Reader應察覺契約不符並停止當作正常值使用，而不是讓合理外觀的數字混入報表。
FAQ1：PubSub是不是比Subscription快？沒有通用結論。實際延遲包含來源更新、編碼、傳輸、broker及接收端處理，需在相同需求下量測，不能從名稱判定。
FAQ2：MQTT JSON就是OPC UA PubSub嗎？不是。自訂JSON透過MQTT發布不會自動符合OPC UA PubSub的訊息及metadata規則，必須核對所用映射。
FAQ3：換成PubSub後還需要Client/Server嗎？可能需要。瀏覽、設定、歷史及其他服務需求可以繼續保留，兩者按產品能力共同使用，不必把所有功能改成同一通道。
FAQ4：十個Reader收到就能宣稱永不漏資料嗎？不能。還要定義測試區間、來源筆數、每端實收、缺口、重複及過期判定。一次收到資料只證明那次路徑成立。
本篇計算是純資料流量預算。正式適用性需以產品版本的Profile、授權、訊息大小與安全支援矩陣確認。保留候選方案及尚缺證據，才能讓下一步測試直接回答選型問題。
參考：OPC UA Part 14 Abstraction layers，訊息與傳輸映射分層。
參考：OPC UA Part 14 MQTT transport mapping。