界線與基線
異常注入先定隔離測試台、注入位置、持續時間與停止條件。本文用S1來源停更、S2單欄格式錯、S3服務逾時，所有案例從同一正常基線開始。
S2的欄位驗證錯誤必須發生在解析器實際收到的資料上。若注入器只是丟掉封包，就只能驗證遺失或延遲；要用原始輸入與解析日誌證明錯誤值確實到達，不能只看工具設定成功。
七組基本矩陣包含三個單點、三組成對與一组三點。每組還要指定開始與解除順序，以及持續時間；七個集合只涵蓋選定的故障種類，不等於涵蓋所有時序、持續長度與實體設備故障。
矩陣建立前先寫故障字典：S1只停止第二筆更新，S2只改第二筆格式，S3只延遲服務回覆。注入器每次輸出命中記錄，若未命中仍跑出正常結果，案例應標注入失效而非通過。
基線送三筆有效資料，每筆有Good品質、輸出與序號。保存輸入和輸出後才注入；沒有基線就不能解釋組合故障的差異。
單點先測S1、S2、S3，各自記狀態、品質、時間與解除方法。組合不等於單點結果相加，優先級、短路、重試與資源限制都可能改變行為。
只在離線替身或隔離測試台注入。正式設備沒有隔離程序時標NotRun，不以看畫面或口頭保證替代安全邊界。
本文使用隔離軟體替身示範三個故障模型，不涵蓋RS485實體干擾、電源故障或任何PLC型號的全部故障模式。狀態英文名稱均為案例標籤，實際品質與告警表示需對照專案；測試矩陣不能作為現場安全功能已驗證的證明。
單點案例
每個注入器要回報命中證據，例如歷史輸入序號、注入開始時間、命中計數與替身回覆。沒有命中證據的案例只算工具設定完成，不算故障行為已驗證。
三筆基線若每秒更新一次，第二筆停止後在兩秒內仍可能保留最後值。驗收門檻要把值保留與品質轉態分開，不能因畫面數字不變就說S1沒有生效。
S1讓第二筆停止更新，預期第一、三筆仍可更新，第二筆轉Stale或Unknown。保存最後有效時間，不能用執行緒成功時間刷新失敗點。
S2把第二筆單位改成未知字串，保存原字串與錯誤位置。若整批拒絕，記錄為契約行為，不能事後私自改成部分成功。
S3假設請求逾時門檻為一百五十毫秒，讓回覆晚於門檻。預期保留原確認時間並依契約標通訊異常或過期，不能繼續冒充新鮮良好；解除延遲後要有新有效確認才恢復。
每個單點重跑兩次，一次確認可重現，一次確認可回基線。若結果不同，先查快取、佇列、重試與初始化，標Uncertain後才決定是否進組合。
組合與優先級
三點組合若日誌溢位，通過條件應要求明確Overflow標記與保留最小證據，不可把缺日誌當沒有故障。
組合S1+S2的主因順序可定為解析錯先、資料新鮮度後，但這只是本案例契約；若專案選另一順序，必須在矩陣寫明並以同一順序驗收。
S1+S2時第二筆既無新資料又有格式錯，契約要指定先顯示哪個主因、哪些原始證據保留，以及其他筆是否繼續更新。
S1+S3要分來源最後有效、請求送出、回覆截止與狀態決定時間。兩者皆可成立時，狀態保留主因與附加原因，不能只顯示網路錯誤。
S2加S3時先指定錯誤資料到達及回覆到期的順序，再各測先錯誤後逾時、先逾時後晚到錯誤。不同時序可有不同合法結果，驗收重點是符合各自契約，不是強迫所有時序產生相同主因。
S1+S2+S3的重點是仍保留案例ID、原始輸入、第一個可定位原因與最後狀態。日誌容量不足造成的遺失要列為矩陣結果。
以第二筆資料先被判單位無效，再停止更新為例，解析錯誤是已收到資料的歷史證據，過期是後續沒有新確認的判斷。兩者可以並存，但不能說停止後根本未收到的同一新訊息又被解析器判錯。
解除與失敗
解除後再送三筆正常資料，確認舊錯誤不會污染新案例；若計數保留歷史，報告要分歷史與目前狀態。
成對與三點案例應重做基線，不能把上一組殘留注入帶入下一組。每組結束記錄解除確認，若無法回到三筆Good，後續組合全部標Invalid。
解除一個注入後，另一個仍應在清單中可見。若工具只提供全域Stop，需記錄無法獨立解除的限制，不能宣稱每個故障均已單獨驗證。
解除依明訂順序逐步做，每步保存狀態。服務恢復不代表來源資料恢復，來源恢復也不代表解析錯誤消失，三者各有健康證據。
回歸重送三筆基線，檢查值、品質、序號、時間與錯誤欄。畫面正常但錯誤計數未清零，要依契約判斷歷史保留或遺留狀態。
失敗保存腳本、命中時間、輸入輸出、日誌、工具與環境版本。先清除再收證據會使注入失效與處理錯誤無法區分。
組合不過先回到單點重跑；單點若也變動，矩陣失效需重建基線。只有單點穩定而組合失敗，才分析交集優先級與資源。
矩陣的通過不是七組都顯示錯誤，而是每組命中指定注入、狀態符合時序、未受影響資料仍按契約更新，並能在解除後回到明確基線。
練習要求驗收者預測S1+S3的四個時間點，再和日誌比對。若只有最後Timeout而沒有來源最後有效時間，矩陣仍缺少定位證據。
矩陣與練習
矩陣欄位包括案例ID、注入集合、基線、預期主因、允許附因、觀測點、解除、實際與證據。不能只寫『錯誤有顯示』。
練習完成S1至S3後預測S1+S3的狀態，寫出如何用時間線分辨兩原因。若不能分辨，就增加來源、請求或原始錯誤欄。
再測三故障同時產生大量日誌，確認系統至少留下第一原因與最後狀態；若截斷，通過條件要包含截斷事件與阻止假成功。
由未撰寫者重跑一單點與一組合，確認沒有隱藏步驟。未測設備與正式環境限制要列在結論。
練習可設最後有效確認在零秒，一秒開始停止更新，資料年齡大於兩秒才過期；同時讓請求在一秒送出，逾時門檻一百五十毫秒。預期先看到該請求逾時，超過兩秒才看到資料過期，這兩個事件不是同一計時器。
問：三個故障為何有七組？答：三個單點、三組成對及一組三點，共七個非空集合，仍未涵蓋所有發生順序。
問：工具顯示已設定就算注入成功嗎？答：還要有目標命中與資料路徑證據，沒有命中應列測試無效。
問：解除延遲後資料仍不良是失敗嗎？答：先看其他故障是否仍存在，以及是否已有新有效確認，不能只看注入器停止。
問：可用單點結果推測同時故障嗎？答：只能形成預期，實際組合可能受優先順序與資源競爭影響，仍須驗證。
參考：NIST SP 800-82 Rev.3：OT測試與運作風險背景；本文案例及狀態為自訂驗收設計。