HMI大螢幕與平板共用資訊 響應式版面 權限與防誤觸要分開

先定義兩種尺寸與同一資料模型

大螢幕與平板可以共用資料模型，不能直接共用每個像素位置。大螢幕的觀看距離、橫向寬度與同時顯示量較大；平板常用直向、觸控與較短的操作時間。先把泵浦編號、狀態、流量、壓力、品質、最後更新時間定義成相同欄位，再由各版面選擇顯示順序。響應式排版只回答元件如何重排，不會替使用者判斷權限，也不會阻止誤觸。

本例有 P-101 至 P-104 四台泵。大螢幕顯示四張設備卡與右側警報佇列；平板一次顯示一張設備卡，操作按鈕要另經角色授權、二次確認與互鎖條件。若平板把停止按鈕縮到很小，仍可能被誤觸；若只把按鈕藏起來，也不代表後端拒絕未授權請求。

先建立畫面元件的資料契約，而不是先畫兩個尺寸。每張設備卡至少收到 deviceId、displayName、state、quality、value、unit、sourceAt、receivedAt、age、commandCapabilities。缺少 value 時顯示 Unknown；缺少 unit 時不能拼接數字假裝完整。大螢幕可以把四張卡放在同一列，平板則逐卡捲動，但兩者對同一欄位的空值與品質規則必須完全一致。

響應式只負責排列 不負責安全邊界

設定三個斷點只是版面工程決策。例如寬度 1920 px 顯示四欄、1024 px 顯示兩欄、平板直向 800 px 顯示一欄。每個斷點都必須保留狀態文字、品質標記與更新時間；不能只留下顏色圓點。當資料卡由四欄變一欄，排序要固定，否則同一警報在不同裝置出現不同位置會增加判讀負擔。

按鈕流程獨立於 CSS 或畫面大小。後端收到 Stop 請求時先檢查登入角色、設備可控狀態、聯鎖與 requestId；畫面只顯示可執行、被拒絕或等待回覆。測試時讓操作員在大螢幕送出 Start、再用平板送 Stop，驗收伺服器以明確序號處理兩個請求，而不是靠畫面先後猜測。

權限模型也要先於視覺設計。假設 Viewer 只能讀取，Operator 可提出 Start/Stop，Supervisor 可批准旁路流程；每個請求帶deviceId與requestId，服務端由受驗證的登入狀態取得userId與role，不接受前端任意聲稱角色。當 Viewer 仍看到 Stop 圖示時，按下後應由 API 回覆 NotAuthorized 並寫入稽核，而不是只靠前端 disabled。平板離線時更不能把快取按鈕當成可執行控制。

資料更新可採版本號或 sequence。若平板在 10:00:05 收到版本 21，大螢幕稍後收到版本20，若它先前已收到21，就應在該客戶端拒絕用20覆蓋21；若它只收到20，顯示目前已知版本及時間，不能假稱已和另一端同步。這是資料一致性規則，不是由響應式 CSS 解決。

當 API 回覆延遲時，兩個裝置都顯示 Pending 和最後更新時間，不能一個顯示成功、一個顯示失敗。完成驗收後再測後端重複請求，確認 idempotency key 讓重送不產生第二個控制動作。

權限、資料品質與版面三者在驗收表分欄記錄；只通過版面縮放不能宣稱控制安全。

平板觸控的防誤觸流程

以 P-101 Stop 為例，第一步是按鈕按下後產生本次 requestId 並顯示確認視窗，第二步由使用者確認設備名稱、目前狀態與原因，第三步才送出命令。確認視窗若在 10 秒內沒有完成就失效。伺服器回覆 Accepted 不等於馬達已停止，畫面還要等待回饋點或顯示 Timeout，並保存操作者、時間與回覆。

對大螢幕可用滑鼠點擊，對平板可用長按 800 ms；這是互動設計，不是權限控制。自動化測試應同時發送一個沒有角色的請求和一個有角色但設備互鎖未滿足的請求，驗收兩者在畫面上都是拒絕，但 audit reason 必須不同。這能避免只測按鈕是否出現。

大螢幕適合持續監看，應優先顯示異常、資料 age 和目前責任區；平板適合巡檢，應把單一設備的上下文、確認原因與回饋放在同一流程。兩種裝置都要提供可讀文字，不以紅綠色作唯一辨識。當色盲模式或投影機灰階顯示時，狀態文字、圖示和品質欄仍應可判讀。

防誤觸驗收還要測失焦、返回上一頁、網路斷線和重複點擊。一次確認只允許一個 requestId，按鈕在 Pending 時不得再建立第二筆；逾時後顯示未知結果，要求查詢狀態，而不是直接再送 Stop。

視覺元件可依裝置選擇卡片或清單，但欄位標籤不可只用顏色、縮寫或圖示。觸控區域、鍵盤焦點、放大字體和橫向滾動都要在目標平板實際測試，這些是可用性驗收而非權限設計。

資料新鮮度與跨裝置一致性驗收

假設伺服器在 10:00:00 收到 P-101 流量 120 L/min，source timestamp 是 09:59:58，接收時間是 10:00:00。大螢幕每 2 秒刷新，平板每 1 秒刷新；本例sourceAt明確定義為最後成功量測時間，時鐘已對齊，且每筆定時回報。兩端在相同snapshotAt=10:00:00時，age都為2秒；刷新時刻不同則age可以不同，規則必須一致。若 10:00:06 沒有新資料，age為8秒；本例自訂age大於6秒即Stale。若來源時間只在值變化時更新，不能套用此門檻判定量測停更。

驗收先固定同一筆測試資料，再截取兩種尺寸的顯示快照。比較欄位值、品質、排序、警報計數和 requestId，允許位置不同但不允許語意不同。故障排查順序是先查 API payload，再查權限與控制回覆，最後才查 CSS 斷點；否則容易把後端拒絕誤判成按鈕排版問題。

測試資料可先由伺服器固定回放，不必接設備。依序回放 Running、Fault、Stale、恢復四筆 payload，確認大螢幕和掌上裝置的狀態遷移相同；再用兩個 requestId 同時提出命令，確認回覆分別綁定，不會把平板的結果顯示到另一張卡。

ISA101 的官方說明涵蓋圖形、導覽、警報、安全方法及資料庫介面；本文只借用這些設計範圍，沒有把任何版面配置宣稱為標準強制尺寸。

限制 FAQ與查核來源

版面驗收要量實際可讀性。用 1920、1366、1024、800 像素四個視窗截圖，記錄每個 breakpoint 的欄數、標題換行、按鈕最小尺寸、警報數量和表格是否出現水平捲軸。平板橫直轉向後重新讀取同一個 requestId，不能因元件重建而重送命令。

使用者測試要有明確任務，例如在大螢幕找出 P-102 的 Stale 原因、在平板提出 P-101 Stop 並完成確認、再從大螢幕查詢同一 requestId。記錄完成秒數、錯誤點擊與是否看錯設備；不能只問使用者覺得好不好。

最後的現場演練要讓兩個裝置同時開啟同一設備。大螢幕送出顯示查詢，平板提出控制請求，確認狀態更新在兩端一致；若一端快取未更新，畫面必須顯示 age 或版本差異，而不是繼續顯示綠色正常。

本案例只建立離線資料模型與驗收流程，未宣稱任何特定 HMI 產品自動支援斷點、長按或角色管理。實作時須依平台的權限、觸控事件、瀏覽器支援和後端 API 文件確認。響應式畫面不等同安全功能；安全控制仍應由獨立的控制邏輯與授權服務負責。

FAQ1：大螢幕與平板能否共用同一套畫面？可以共用資料契約與元件語意，但尺寸、導航和觸控流程應各自驗收。

FAQ2：把 Stop 按鈕隱藏是否等於限制權限？不是，後端仍須檢查角色、互鎖和設備狀態。

FAQ3：資料變黃是否代表設備故障？不一定，可能只是 age 超過門檻；要查看品質旗標與通訊紀錄。

FAQ4：Accepted 是否代表動作完成？不是，仍要等設備回饋或明確失敗/逾時。

參考：ISA101, Human-Machine Interfaces（ISA 官方頁說明其涵蓋導覽、圖形、警報、安全方法與資料庫介面）

參考：ISA-101 Series of Standards（官方頁說明設計、實作、操作與維護生命週期）

延伸閱讀

• HMI 事件時間線如何把警報 操作和備註放在同一脈絡
• 工業 CSV 欄位規格與匯入驗收