先分清楚列出與解除的責任
測試結束時，自動列出強制值可以幫你避免遺漏，但解除強制可能讓真實輸入重新接管，並改變後續邏輯。先建立完整清單與受控解除條件，再談自動清理；不能把一個「全部清除」按鈕當成測試結束的充分證據。
本文適用於隔離測試台的強制值管理流程，不指定PLC、HMI或閘道的指令。實際工具是否能列出全部強制項目、是否跨重啟保持、解除後如何接回來源，必須依型號與版本文件確認。本篇沒有建立或清除任何現場強制值。
先記錄來源、目標、型別、建立時間、操作者、測試案例、強制值及建立前的觀察值。建立前值只是快照，不能作為解除時必須寫回的答案。原始輸入在測試期間可能合法改變，解除強制與寫回舊值是兩個不同動作。
管理表分兩欄：一欄記解除工作狀態，例如待處理、已送出、結果未知、已確認；另一欄記最近確認的強制狀態、確認時間及目前是否可知。這些名稱是教學自訂，不是廠商API。結果未知時保留舊證據，不把最後確認值偷偷改成新結論。
建立兩筆案例並驗證列單範圍
隔離替身的TankLevel原始輸入為四十二，強制為六十；ValveReady原始為假，強制為真。第三個AlarmReset保持正常、不建立強制。本例共兩筆，清單應列出兩筆有效強制，且保留它們各自的來源與建立識別。
自動列單時記錄工具連線目標、權限、查詢範圍與回覆完整性。工具只查目前程式或目前站號時，空清單不能證明其他範圍沒有強制值。無權限或通訊失敗應標列單未完成，不能用零筆代替錯誤。
將TankLevel的正常來源改為四十五，保持其強制值六十。預期使用強制來源的讀值仍為六十且標示強制中；若工具可觀察正常來源，另顯示四十五。這個案例可證明解除後應接回當前來源，而非回寫先前四十二。
另外準備同名但不同來源的項目，檢查唯一鍵是否包含來源或站號。清單排序改變時仍要逐鍵對帳，不能用列的位置配對。完成後應能由每個清單項目找到建立紀錄，並指出目前查詢尚未涵蓋哪些範圍。
按照受控條件解除並獨立確認
先確認隔離有效、後續邏輯處於允許狀態，再產生待解除快照，依專案授權流程核對目標與可能影響。自動化只能在已核准範圍執行，不能替代對設備狀態的確認；若解除會接回實際輸出，必須按現場程序處理。
本例先解除ValveReady，假設正常來源仍為假。預期新查詢確認它已無強制，讀值回到假；管理紀錄保留解除請求、回覆與再次查詢的時間。按鈕回覆成功是其中一項證據，仍須核對實際目標狀態。
接著模擬TankLevel解除回覆逾時。此時只知道沒有及時取得結果，不能斷定解除失敗或仍然有效，更不能直接再寫六十或四十二。解除工作標結果未知，保留最近曾確認強制有效的時間，同時將目前狀態標成尚未確認。
停止後續自動解除流程，透過允許的唯讀查詢釐清現況。若確認已解除且正常來源仍為四十五，讀值應接回四十五；若確認仍強制，是否重試由工具語意與授權程序決定。單靠逾時不具備盲目重試的依據。
讓異常與晚到回覆都有去向
分別測權限不足、目標不存在、重複請求與回覆逾時。權限不足表示無法確認，目標不存在則先查來源與建立世代；重複請求可能已處理或仍進行中，依實際工具語意記錄，不自行創造通用返回碼。
晚到回覆應關聯原解除請求、來源與建立識別。測試台重啟後重新建立同名強制，舊回覆不能把新項目標成已解除。若工具沒有足夠關聯資訊，改採受控序列操作與再次查詢，並明列無法辨識的限制。
保存原始牆鐘與來源資訊，同一時鐘域內可用單調時間量測等待間隔；不同主機的單調時鐘不能直接互減或排序。若跨端時鐘未確認同步，報告只能保留各端時間與已知請求關聯，不能杜撰精確先後。
測試工具關閉或清單快取消失不代表設備強制已解除。重啟後重新取得清單，與建立紀錄及已確認解除紀錄對帳。失敗時先查連線目標、查詢範圍、權限與回覆完整性，再查真正的強制狀態，避免先做寫入才收集證據。
清單更新期間還可能有人建立新的強制項目，因此結束快照要記錄取樣時間與範圍；若工具無法提供一致快照，就在受控條件禁止新增並重新核對。建立數與解除數相等只是必要檢查之一，仍須逐項確認來源與建立識別相符。
完成結果與練習
本例兩筆強制若一筆已確認解除、一筆結果未知，報告應寫建立二筆、確認解除一筆、待釐清一筆。可以確認異常處理流程符合設計，但不能宣布強制值全部清除。未完成項目須有負責人與後續確認方式，並阻止它被下一案例誤當正常來源。
練習：來源從四十二變四十五後，強制仍為六十；解除後讀回四十二，該先查什麼？先查是否有清理腳本把舊快照寫回、來源是否再次改變、讀值是否來自舊快取，再核對強制清單。只有數值恢復到舊值，不能證明解除正確。
問：列單為零就能交接嗎？答：先確認查詢成功且範圍完整，再與建立紀錄對帳；空清單本身不足以證明全部解除。
問：解除後一定恢復建立前的值嗎？答：不一定，通常還需看當前正常來源與工具行為，不能無條件寫回舊快照。
問：逾時後能直接再送解除嗎？答：先釐清原請求結果及目前狀態，再按工具規則決定，不能把未知當失敗重送。
問：這份流程能直接套到所有PLC嗎？答：只能沿用管理原則，強制範圍、持久化與解除機制須依實際型號和軟體版本核對。
參考：NIST SP 800-82 Rev.3：OT變更與測試環境的運作風險背景；本文清單和狀態為自訂示例。