先定義資源的唯一主人
兩個虛擬工站 A、B 共用一個檢測模組時，不能只把兩個允許線圈 OR 在一起；同一掃描可能同時得到允許，下一掃描也不知道誰該釋放。先建立 owner：NONE、A、B；request_a/request_b；busy；grant；release；timeout。資源規則是 owner 不是 NONE 時，另一站永遠不能進入使用段，且只有 owner 能釋放。
| 欄位 | 意義 | 改變者 |
|---|---|---|
| owner | 目前唯一使用者 | 仲裁器 |
| request | 等待使用的請求 | 工站 |
| grant | 本掃描核准脈衝 | 仲裁器 |
| release | 工作完成通知 | owner 工站 |
| timeout | 逾時事件 | 監視器 |
先畫 NONE→A/B、A/B→NONE 的合法轉移。
規定同時請求時採先到先服務；同一掃描同時到達則固定 A 優先。
規定 owner 逾時後進入 FAULT_LOCK，人工確認或明確復歸才回 NONE。
選排程規則並消除掃描偏差
固定優先容易讓 B 飢餓；單純每掃描先檢查 A，也會讓掃描順序變成隱藏優先。這篇採簡化先到先服務：記錄 request_seq，請求成立時取得遞增序號；同掃描到達依A先B後分配序號，這是明訂的決勝規則。資源釋放後才選下一位，不能在 owner 尚未清除的同一邏輯段又授予另一站。
| 事件 | A 序號 | B 序號 | owner | 說明 |
|---|---|---|---|---|
| S1 同時請求 | 1 | 2 | A | 先到先服務 |
| S2 A 工作中 | 1 | 2 | A | B 等待 |
| S3 A 釋放 | 1 | 2 | NONE | 只完成釋放 |
| S4 仲裁 | — | 2 | B | 下一掃描授予 B |
| S5 B 完成 | — | 2 | NONE | 兩站皆有機會，且等待中的請求不會因掃描順序被永久跳過 |
若兩個 request 在同一掃描被置位，A 得 seq=1、B 得 seq=2 是規格中的固定結果；若需要真正同時性，應由上游事件時間戳提供排序，不要宣稱 PLC 掃描能觀察到物理上的同一瞬間。 另外，取消請求必須在仲裁前生效；已取得 owner 後的取消則走釋放或故障流程，不能直接刪除 owner。這個差異要在測試表中各做一次。
逾時 故障與資源回收
owner A 取得模組後，啟動本工作專屬的逾時計時。完成回饋來自 A 才能 release；若逾時，先撤銷 A 的使用允許，記錄 fault_owner=A 與 fault_code=TIMEOUT，再鎖住資源。不能直接把 owner 改 NONE 讓 B 立刻進入，因為模組可能仍處於未知狀態。維修或復歸條件完成後，才清除鎖定並依等待序號重新仲裁。
教學偽碼，非指定PLC語法：
NextOwner:=owner；Grant:=NONE
若fault_lock：保留owner，等待明確復歸流程
否則若owner≠NONE：
若目前owner逾時：fault_lock:=TRUE；保存fault_owner
否則若目前owner的release與工作序號有效：NextOwner:=NONE
否則（原owner為NONE）：
NextOwner:=選擇最早有效等待請求；Grant:=NextOwner
owner:=NextOwner
enable_a:=(owner=A) AND NOT fault_lock AND PermitA
enable_b:=(owner=B) AND NOT fault_lock AND PermitB
同次釋放不再仲裁；復歸需另確認模組可用才清鎖。
| 異常 | 狀態 | 操作員先做什麼 |
|---|---|---|
| A 無完成回饋 | FAULT_LOCK、owner=A | 確認模組安全狀態與 A 的故障原因 |
| B 取消請求 | 保留 A 或 NONE | 刪除 B 的等待序號 |
| PLC 重新啟動 | 依保持規格恢復或鎖定 | 確認模組實際狀態再復歸 |
| 兩站都要求釋放 | 只接受 owner 的 release | 追查訊號交叉接用 |
公平不是讓兩站同時動，而是讓等待規則可預測。你可先算出最壞等待：若 A 每次最多使用 3 掃描、B 每次最多 2 掃描，採先到先服務時，等待上界需包含目前owner剩餘時間、前面請求使用時間、每次釋放後一掃描仲裁間隔與排程延遲；故障鎖定期間不能保證有限等待；超過上限就進入警告，不可默默覆蓋。仲裁器要在一個明確位置產生 owner，工站只提出 request 並回報 done，避免 A 子程式和 B 子程式互相寫 owner。若共用模組還需要初始化，初始化也算資源使用期間，必須由 owner 執行完後才 release。
測試流程與驗收
仲裁採NextOwner單次決策：目前owner逾時優先於完成，fault_lock當次成立，最後產生輸出時立即遮罩；不會先放行另一站才鎖定。取消未獲授權請求可刪等待序號，取消已獲授權工作須完成受控停止與釋放。
為了驗證不會雙重使用，你可以把共用模組想成一扇只有一把鑰匙的門。每一掃描先處理釋放，再處理仲裁，最後依新的 owner 產生允許；同一掃描不直接重用剛釋放的鑰匙，下一掃描才授予下一站，時序最容易讀懂。request 要附上有效序號，取消後序號失效；重送同一請求不可取得第二把鑰匙。模組回報完成時，先核對 owner 和工作序號，兩者任一不符就記錄孤立回饋。逾時鎖定時保存當下輸入、輸出、經過時間與故障碼，復歸後先核對等待請求是否仍有效，失效才清除並要求重新請求。若有安全門、急停或外部控制器介入，這些訊號只能使 owner 進入受控停止，不能繞過資源狀態直接放行另一站。最後以連續壓力測試確認每一站都有服務紀錄，並檢查最長等待不超過規格。
仲裁結果要能在監看表重現：同一組輸入與序號，經過同一規則必須得到同一 owner。
只送 A 請求，確認 A 得到 grant 且 B 永不 enable。
在 A 使用中送 B 請求，確認 B 排隊；A 釋放後下一掃描才輪到 B。
同時送兩請求，依 seq 表核對結果；連續做十輪檢查沒有永久餓死。
切斷 A 的完成回饋，確認逾時鎖定，不讓 B 偷接資源。
測試流程與驗收 續
請用兩站交錯的事件驗證公平性：第一輪 A 先請求，第二輪 B 先請求，第三輪兩站同時請求。每輪都要記錄 request_seq、grant_scan、release_scan，並計算等待掃描數。以 A 工作 3 掃描、B 工作 2 掃描為例，A 在 S1 取得、S4 釋放，B 最早 S5 取得；若B也在S1提出請求，至S5授權的掃描索引差為4。下一輪 B 先請求時，A 不得因程式排列在前就插隊。若固定優先造成 B 等待超過上限，應產生 STARVATION_WARN，讓工程師選擇輪轉或調整優先規則。
還要定義取消與復歸的邊界。仲裁前取消 request_b，B 的序號作廢，不應留下空洞而阻塞後面請求；仲裁後 B 已是 owner，取消只能轉成受控停止，等模組回到安全狀態才 release。若 owner A 的完成訊號和逾時訊號同一掃描出現，故障優先，結果標成 TIMEOUT_RACE 並鎖定，不能自行判定成功。重新啟動後若 owner 被保持為 A，程式應先要求模組狀態確認；若不能確認，直接進故障鎖比猜測可用更安全。
驗收時把每一掃描的 owner、兩個 request、兩個 enable、grant、release 與 fault_lock 一起記錄。只看工站畫面上的忙碌圖示不夠，因為畫面更新可能晚於 PLC 掃描；以監看表的順序才可判斷是否短暫雙重放行。
完成後應看到什麼結果
任一時刻 owner 只有一個；使用中只有 owner 的允許有效；釋放後下一位依規則取得；逾時會留下可追蹤的故障鎖，不會靜默放行。
失敗時先查哪裡
先查 owner 是否由多處寫入，再查 grant 與 enable 是否脫離 owner，接著查 release 是否被非 owner 觸發，最後核對逾時計時與復歸條件。
適用型號與限制
可作為 Q06UDVCPU 控制共用設備的應用框架；Q 系列並不因此自動提供跨程式的資源鎖，需由工程師實作並依任務、中斷及通訊延遲驗證。
常見問題與來源
FAQ
問：固定 A 優先可以嗎？答：可以，但要接受 B 可能長期等待，或加最大等待時間。
問：逾時後能否自動交給 B？答：只有模組安全復歸被確認後才可，否則會重疊使用。
問：輪流排程一定更公平嗎？答：它改善順序偏差，但仍要定義取消、故障與連續請求。