先定義原子資料單位
一筆量測不是單一數字，而是value、quality、reason、source、sequence、source_time、receive_time與schema_version的集合。HMI若先收到新value、下一刷新才收到Bad，就會短暫誤認；因此需要硬體或通訊層支援原子更新，或由一致快照保證同一版本欄位一起讀取。
若平台不能原子提交，至少以sequence或snapshot_id配對；HMI只接受欄位版本一致的一組資料。value=25、quality=Good、snapshot=41是一筆；value=26、quality仍41則拒絕，不可拼成半新半舊。
品質Bad時lastgood可保存25供診斷，但current value必須另標不可用，趨勢不補零。缺值、零、超界、失聯和Uncertain各有語意，不能靠顏色或預設值代替。
value、quality、reason、source、sequence、source_time和receive_time同一快照更新，才可稱一致。
本篇以應用層量測紀錄教學，不指定Q系列或其他PLC能原子讀取的字數。即使通訊一次讀一段連續裝置，來源程式也可能在不同掃描或任務改寫欄位。先查硬體、驅動與程式更新邊界，再決定是否已有一致性，不能把一次請求直接等同原子快照。
單調接收計時可以知道本機多久沒收到新資料，不需要和來源對時；它不能告訴你資料在來源端已老了多久。顯示時寫「距上次接收三秒」與「來源時間未知」比只寫三秒延遲更精確，並讓操作員知道缺少哪種時間證據。
實作一致快照與測試
若底層提供已定義的原子區塊或快照，依文件一次取得值、品質和來源時間。若要自行設計版本檢查，必須處理寫入中的狀態；只在所有欄位寫完後增加序號，讀者可能在更新中途讀到新值、舊品質與尚未改變的序號，不能保證一致。
測試故意讓value與quality分別延遲一個刷新週期，確認HMI不顯示混合版本；再測來源失聯、恢復、序號倒退、重啟與格式錯誤。每案保存原始封包或快照、預期畫面文字和事件id。
例10:00來源送25、10:00:12收到，只有兩端時鐘可信且定義一致時才可計算來源age；否則只說接收於10:00:12並標時鐘限制。接收順序不能代替來源時間。
若硬體沒有品質寄存器或一致快照能力，軟體只能建立自己的封裝層並記錄風險，不能假稱底層更新是原子的。控制端和HMI分別驗證，畫面可讀不代表控制可用。
版本檢查示意：單一寫入者先將版本由偶數改為奇數，表示正在更新；寫入值、品質及時間後，才發布下一個偶數。讀者先讀v1，若奇數便等待；讀內容後再讀v2，只有v1等於v2且為偶數才接受。版本讀寫必須原子、寫入順序可見，且一次讀取期間不可完整回捲，否則這個推理不成立。
例v1=40，讀到value=26之後，寫入者完成發布42，讀者v2=42便拒絕本次，不把26與舊Good混用。若持續更新導致多次重試都失敗，設定有界重試與診斷，不能讓通訊任務無限循環。平台不滿足原子版本及可見順序時，改用鎖存、握手或文件支援的方式。
快照的一致性和時間新鮮度是兩項檢查。即使完整讀到版本40，如果來源已停更十秒，仍可能超出使用期限；相反地，剛收到的新封包也可能含混版欄位。驗收時兩種情境各自測試，不讓通過其中一項代替另一項。
故障案例與畫面結果
正常：snapshot41包含25、Good、來源S1，HMI更新數值和最後有效時間。失聯：保留lastgood25，但current quality=Bad、reason=Timeout，趨勢留空並顯示失聯，不把25當新值。
超界120而量程0到100時，原始值120可保留供診斷，工程可用值標Invalid；不可夾成100再顯示Good。恢復收到26且新snapshot品質Good後，才更新lastgood與趨勢。
來源重啟後sequence歸零，要用epoch分隔新舊。若沒有epoch，不可把小序號一律當倒退，也不能把舊連線的Good沿用到新來源。
snapshot_id=41的value、quality、reason和時間必須同版；讀到value=26但quality仍40就重讀或標不一致。
雙緩衝也有生命週期限制。寫入者完成非作用區後切換索引，看似安全；但慢讀者可能還在讀舊區，寫入者繞回便覆蓋它。需要讀者確認、鎖定期間或其他可證明的存活機制，不能只增加兩個陣列就宣稱沒有競態。
品質要分來源診斷與接收端新鮮度。來源最後一筆Good仍留在緩衝，但連線中斷後，本地目前可用狀態應按逾時規則改變。保存原始來源品質與本地Timeout原因，不要直接覆寫原始診斷；畫面可顯示最後有效值25、來源最後Good、目前失聯，讓各欄意義清楚。
驗收限制
畫面同時顯示value、quality文字、reason、source、snapshot與lastgood時間；灰階、文字和圖示多重呈現。品質更新落後一筆、趨勢把Bad畫零、或重啟後舊值未切epoch，都判失敗。
驗收保存每筆測試輸入、版本、畫面證據、事件紀錄與拒絕原因。若來源時鐘未校準，報表不要宣稱資料age，只列接收時間與不確定。
回復時要求連續有效快照與新鮮度通過才清除警報；不因單一Good樣本就恢復控制。若品質碼無法一對一映射，保留原始碼並顯示Unknown，報表不得假造標準名稱。
OPC UA DataValue封裝值、StatusCode與相關時間欄位，Client使用結果前須檢查狀態。Bad結果不作正常量測使用；伺服器時間也不等於HMI收到封包的本地時間。若另用自訂PLC結構，應定義自己的品質碼與映射，不假造OPC UA標準StatusCode。
完成後用刻意交錯的讀寫測試，而不只讓畫面正常跑五分鐘。測試在寫入value之後、quality之前暫停，在讀v1後切換版本，再模擬重啟與舊封包延遲到達。每案確認接受或拒絕理由，以及控制端是否同樣防止使用混版資料。這些測試須在受控環境執行。
資料重啟後的版本策略也要核對。若版本號會回零，搭配可靠的啟動識別，並清除舊連線等待中的讀取結果；不能讓上一個啟動期間的版本42蓋掉新啟動期間的版本2。來源沒有啟動識別時，記錄這個限制並定義重新同步程序。
常見問題與官方參考
FAQ1：可以只傳value和一個Good旗標嗎？若無法表達失聯、超界和不確定，不能滿足診斷。
FAQ2：lastgood能當目前值控制嗎？除非控制規格明確允許，否則只能作診斷並標時間。
FAQ3：分欄讀取如何避免混版？用一致snapshot或sequence驗證，不一致就拒絕。
FAQ4：HMI顯示正常代表底層原子更新嗎？不代表，需檢查版本配對與硬體支援。
參考：OPC UA Part4 DataValue：值、StatusCode與來源及伺服器時間。
參考：OPC UA Part4 StatusCode：使用結果前的狀態檢查。