壓差設備軟體整合 FAQ

Modbus 規範每個暫存器內為高位元組在前，但兩個暫存器組成 32 位元值時的字序（哪個暫存器放高位字）由廠商決定，須以暫存器表確認並用已知實際量測值驗證。

• 兩個獨立決定：暫存器內的位元組序（Modbus 規範為大端）與跨暫存器的字序（因廠商而異）。
• 症狀：地址正確但浮點數讀出接近 0、負值或約 1e-38 的極小值，幾乎可判定是字序或位元組序不符。
• 排查步驟：先讀原始暫存器值 → 依 ABCD/CDAB/BADC/DCBA 四種組合解碼 → 與已知物理量（如已知 25.0 Pa）比對 → 保留吻合者。
• 換算驗證：25.0 的 IEEE 754 單精度為 0x41C80000；若字序顛倒（0x0000 0x41C8 被讀成 0x41C8 在低位），解碼會得到約 2.36e-41（換算/驗算結果），看起來就像「近乎 0」。
• 實務：把位元組序/字序、資料型態、倍率設為每個測點的設定欄位，不要寫死在程式裡；同型號多台設備應以同一份 profile 驗證。

RS-485 單一段落常見上限為 32 個單位負載（定址可到 247），輪詢是主從依序進行，週期由「每台往返時間 × 台數」決定；台數多時應分多條匯流排或降低輪詢頻率，而非縮短逾時。

• Modbus 序列線為主從式：只有主站發起請求，從站被輪詢才回應，同一時間匯流排只有一個傳輸。
• 定址：從站位址 1–247；但 RS-485 硬體單一段落無中繼約 32 個單位負載，超過需中繼器或多條匯流排（依 第三方文章引述 V1.02 指南）。
• 週期粗估（假設：每次讀 2 個保持暫存器，請求 8 byte+回應 9 byte=17 byte，每字元 11 bit，前後各留 3.5 字元靜默，從站回應延遲假設 20 ms）：9600 bps 約 47.5 ms/台，32 台輪詢一圈約 1.5 秒；19200 bps 約 33.8 ms/台，約 1.1 秒（粗估，實際依設備而定）。
• 設計建議：同型態測點用一次讀取連續多個暫存器；輪詢順序避免多個執行緒同時搶同一個序列埠；逾時與重試次數要有上限，並把「連續失敗」轉為設備離線狀態。
• 無塵室壓差趨勢通常秒級更新已足夠，但若同一匯流排要兼顧快速告警，應預留餘裕並分條。

純 MQTT 不規定主題與 payload；若平台與閘道器支援，Sparkplug B 提供標準主題命名空間、型別化 payload 與 birth/death 狀態管理，可降低跨廠牌歧義；否則自訂時至少要統一測點 ID、單位、時間戳記與品質欄位。

• MQTT 規格刻意不規定主題命名、payload 格式與應用層狀態，需自行約定。
• Sparkplug 主題結構：namespace/group_id/message_type/edge_node_id/[device_id]；Sparkplug B 的 namespace 為 spBv1.0。
• 訊息類型含 NBIRTH/NDEATH（節點上線/離線憑證）、NDATA（變化資料）；節點連線時先發 BIRTH 帶出全部指標，之後只送變化量。
• 若自訂：每筆至少含測點 ID、數值、工程單位、source timestamp、品質碼、設備狀態，並約定重送與去重欄位（見第 6 題）。
• 選擇原則：現有 SCADA/UNS 平台已支援 Sparkplug → 優先採用；平台只做簡單訂閱 → 自訂 JSON 也可，但要寫成版本化的資料契約。

兩者解決不同問題：OPC UA 提供語意與資訊模型，MQTT 擅長輕量遙測傳輸；實務常並用（場域內 OPC UA、往平台用 MQTT），且 OPC UA PubSub 可走 MQTT 傳輸。

• OPC UA 為綜合框架（資訊模型、安全、多種互動模式），實作較複雜；MQTT 為極簡傳輸，語意需自行約定或用 Sparkplug。
• OPC UA Part 14 定義 PubSub，可使用 MQTT 作為傳輸層。
• 學術比較（OPC UA PubSub vs MQTT 對雲端資料交換）顯示兩者在負載量與往返時間上各有適用情境，需依場景選擇。
• 決策因素：既有 SCADA/PLC 是否內建 OPC UA、測點數量與頻寬、是否需要雙向控制或僅單向遙測、平台原生支援的協定、團隊維運能力。
• 壓差監測以單向遙測為主者，常見做法是閘道器讀 Modbus/OPC UA，再以 MQTT 送平台；此為常見架構，非唯一正解。

以測點 ID 等低變動值當索引（tag），數值與品質當欄位（field）；避免把 UUID、序號等高度變動資訊放進 tag，造成序列基數爆炸而拖垮記憶體與查詢。

• InfluxDB 文件：tag 值有索引、field 值沒有；每組唯一 tag 組合形成一條序列，高變動資訊（如唯一 ID、雜湊）放 tag 會造成高序列基數，是記憶體用量偏高的主因，建議改放 field。
• InfluxDB 3 的儲存引擎宣稱 tag 值基數不影響整體效能，因此 schema 建議因引擎版本而異，需依實際採用的資料庫查證。
• 建議欄位：測點 ID、房間/區域 ID、設備 ID 作為 tag（數量有限且穩定）；壓差值、品質碼、設備狀態作為 field；時間戳記使用來源時間（見第 7 題）。
• 數百測點屬中小規模，關鍵是命名一致與可演進：測點中繼資料（量程、精度、單位）另存維度表，不要塞進每筆時序資料。
• 保留策略：原始高頻資料短期保留、降採樣後長期保留；實際年限依法規與品質系統決定。

在閘道器本地先持久化再轉送；MQTT QoS 1 保證至少一次但可能重複，因此後端必須以冪等寫入（如測點 ID+來源時間戳記為唯一鍵）去重；QoS 2 不代表端到端零重複。

• store-and-forward：資料先寫入本地持久儲存（如 SQLite），網路恢復後再依序轉送，可避免斷線期間的資料缺口。
• MQTT QoS 0 最多一次（可能遺失）、QoS 1 至少一次（可能重複）、QoS 2 恰好一次；離線排隊需搭配持久會話（persistent session），乾淨會話斷線即丟棄。
• QoS 2 只保證該段連線的訊息處理；若發佈端以 QoS 0/1 送出，訂閱端的 QoS 2 不構成端到端恰好一次。
• 「只重試」不是策略：無去重會造成重複計數；後端應以唯一鍵做 upsert/ignore，唯一鍵建議為「測點 ID+來源時間戳記（+序號）」。
• 須定義：緩存上限與淘汰策略（滿了先丟舊還是丟新）、補傳速率限制（避免補傳壓垮平台）、資料缺口如何在儀表板呈現。

每筆資料應攜帶品質狀態（良好/不確定/不良）與來源時間戳記；OPC UA 的 StatusCode 與 source/server timestamp 是成熟範本，斷線時應標示「不確定：最後有效值」而非繼續當作即時值顯示。

• OPC UA DataValue 同時含值、StatusCode（Good/Uncertain/Bad）、source timestamp 與 server timestamp。
• OPC UA Data Access 規定：通訊中斷時值為最後一個良好值，品質為 Uncertain，且 server timestamp 為最後一次檢查通訊狀態的時間；嚴重度為 Bad 時伺服器應回傳 Null 值。
• 來源時間戳記代表量測發生時間，應作為時序資料的主要時間軸；伺服器/寫入時間僅用於診斷延遲。
• 工程做法：自訂資料契約時沿用三態品質；Modbus/4–20 mA 這類本身無品質碼的來源，由閘道器依逾時、錯誤碼、斷線電流範圍補出品質。
• 畫面與告警：Uncertain/Bad 不應觸發『壓差超限』告警，而應觸發『設備/通訊異常』告警，避免誤判。

告警要用遲滯（deadband）與開/關延遲（on/off-delay）抑制抖動，警戒值/行動值以無塵室監測計畫與風險評估決定，不要寫死通用數字；ISA-18.2 提供告警系統管理的通用方法。

• ISA-18.2/IEC 62682 以遲滯（deadband）與開關延遲抑制告警抖動；遲滯不應涵蓋長期平均值。
• Emerson 引述 ISA-18.2 的績效指標之一：10 分鐘內告警少於 10 筆、持續（常駐）告警少於 10 筆。
• ISO 14644-2 要求建立監測計畫，附錄 B 涵蓋壓差警戒值/行動值（alert/action levels）的設定，含建立正常操作範圍與壓差儀器選型。
• 房間等級間壓差：Testo（引述 ISO 14644-3 測試要求）指出不同潔淨度房間間需確保由潔淨側往較不潔淨側有 5–20 Pa 的壓差；實際設定值須依專案設計與風險評估，不得照抄。
• 實作建議：告警狀態機（Normal/Alarm/Acknowledged/…）、持續時間門檻、通訊異常與超限分開、每筆告警保留觸發值與時間以利稽核。

壓差趨勢與告警多為秒級，多數情況 NTP（並監控偏移）已足夠；只有需要亞毫秒級事件對齊（如與高速設備事件比對）才需評估 PTP。

• NTPv4 規格指出在現代工作站與高速區網下，潛在精度可達數十微秒（RFC 5905 摘要）。
• PTP（IEEE 1588）常用於工業自動化與量測網路，由 grandmaster 向區網內多個客戶端校時。
• FSMLabs 指出「NTP 做不到優於 1 ms」與「PTP 一定遠比 NTP 準」兩種說法都不完全正確，精度取決於硬體時間戳與網路品質。
• 決策：先界定要對齊的事件（門禁、風閥、風機）與需要的時間解析度；大多數壓差場景秒級對齊即可，重點是所有系統用同一時間源、統一時區並記錄偏移。
• 實作：以來源時間戳記入庫、同時記錄伺服器接收時間以量測延遲（見第 7 題）。

傳統 Modbus 沒有驗證與加密，資安要靠架構補強：依 IEC 62443 做區域/管道分區、把閘道器當受控管道、只開放必要通訊；新部署可評估 Modbus Security（TLS、X.509、埠 802）。

• 傳統 Modbus/TCP 沒有驗證與加密，只需 IP 位址與功能碼即可建立通訊（INCIBE-CERT 說明）。
• Modbus Security 以 TLS 封裝、使用 X.509v3 憑證做雙向認證，IANA 指定埠為 802。
• IEC 62443：以風險評估劃分「區域（zones）」，區域之間僅經「管道（conduits）」通訊；管道由防火牆、DMZ 或代理實作。
• IEC 62443-4-1 規範產品安全開發生命週期，-4-2 規範元件技術安全要求；選購時可要求供應商說明其對應程度。
• 設計建議：閘道器置於 OT 區與資料平台之間，只允許單向外送與必要的讀取功能碼，禁止寫入；帳號最小權限、憑證輪替、記錄存取。

AAS（IEC 63278-1）是工業設備數位表示的標準結構，以子模型描述銘牌、量測資料等；第一階段不必全面導入，但可借鏡其做法：設備、測點、房間分離，並保存量程/精度等中繼資料。

• IEC 63278-1：2024 定義 Asset Administration Shell 的結構，目的是讓不同軟體以可信且安全的方式交換與使用資訊。
• AAS 由資產資訊與多個子模型（submodel）組成，可含銘牌、量測資料、參數等，並以唯一識別碼與語意描述區分。
• AAS 是資料模型，需有實際資料流入才有價值；與 BMS 儀表板相比，重點在可交換、可描述。
• 實務借鏡：資產（設備）↔ 測點 ↔ 空間（房間）三層分離；設備銘牌、量程、精度、校正日期放中繼資料，不混入時序資料。
• 是否導入完整 AAS 取決於客戶生態系與工具；小規模專案可先用自訂 JSON schema 並保留對應 AAS 的可能。

用 Modbus 模擬器（如 pymodbus simulator）模擬設備與多點匯流排，測試例外回應、通訊錯誤與切割封包，並納入 CI；但最終仍須以真實設備驗證暫存器與字序。

• pymodbus 模擬器可用簡單設定模擬設備或多點線路、模擬不符規範的設備與通訊問題（如資料遺失）、測試客戶端對例外的處理。
• 網頁介面可注入錯誤（如長度錯誤、切割訊息）並監看請求/回應；REST API 可在測試框架中自動啟動測試伺服器並檢查結果。
• 測試矩陣：字序/位元組序組合、逾時與重試、錯誤碼、讀取邊界（暫存器越界）、斷線恢復、緩存補傳與去重（見第 6 題）。
• 契約測試：把暫存器表視為契約（YAML/JSON），模擬器與解碼層共用同一份，避免兩邊各寫各的。
• 真實設備驗證不可省：模擬器只驗證你的理解，不驗證設備實作。

應索取完整型錄、接線圖、通訊協定與暫存器表（或類比輸出規格）、資料型態/倍率/字序、更新頻率與錯誤碼；昶特 ATLANTIS 提供儀表本體，不提供 IoT/AWS 整合服務，客戶需自行整合至自身平台。

• Modbus 資料模型與設備應用的對應由設備廠商定義，因此暫存器表是整合的唯一依據。
• 文件清單：型錄、接線圖、通訊參數（鮑率/位址或 IP/埠）、暫存器表、數值型態、倍率、位元組/字序、工程單位、更新頻率、錯誤碼。
• 樣品驗證：正式採購前以樣品在目標閘道器/平台上驗證。
• 責任邊界：昶特 ATLANTIS 為工業儀表製造商（壓力表、溫度計等）；不提供 IoT/AWS 整合服務，客戶須自行把儀表輸出連接至自己的平台。
• 詢價單建議明列：測點數量、介面需求、資安需求、交期與校正文件，並由採購與 IT/OT 共同核定。

「40001」只是文件慣用的參考編號，實際請求是「功能碼＋從 0 起算的位址」：功能碼 03 讀保持暫存器、04 讀輸入暫存器；40001 對應功能碼 03、位址 0，30001 對應功能碼 04、位址 0。

• Modbus 資料模型有四張表：離散輸入、線圈、輸入暫存器（16 位元、唯讀）、保持暫存器（16 位元、可讀寫）。
• 規範明訂請求 PDU 中的暫存器位址從 0 起算，因此編號 1–16 的暫存器，位址為 0–15（規範 6.3、6.4 節）。
• 換算範例：40001 → 功能碼 03、位址 0；40108 → 功能碼 03、位址 107；30001 → 功能碼 04、位址 0；30010 → 功能碼 04、位址 9。
• 編號開頭的 3 或 4 只是文件的表別標示，不會出現在封包中，由功能碼決定讀哪一張表。
• 各廠牌習慣不同：有的從 40000 起算、有的從 40001 起算，且「3xxxx」對應功能碼 04、「4xxxx」對應功能碼 03，容易混淆；32 位元值若位址差一格，會讀到錯誤資料（見第 1 題）。
• 排查：若每個值都讀成「隔壁暫存器」的內容，通常是手冊與軟體對「從 0 或從 1 起算」的認定不同，前後位移一格再比對。

例外回應代表設備收到請求且通訊無誤，但無法處理（回應功能碼為請求功能碼加 0x80，並附例外碼）；而請求遺失或通訊錯誤（同位檢查、CRC 錯）時設備完全不回應，只能靠客戶端逾時判斷。兩者原因不同，重試與告警策略應分開。

• 規範描述四種情況：正常回應；伺服器沒收到請求而無回應（客戶端逾時）；收到但偵測到通訊錯誤（同位、LRC、CRC）而無回應（客戶端逾時）；收到且無通訊錯誤但無法處理（例如讀取不存在的暫存器），此時回傳例外回應。
• 例外回應的功能碼為原功能碼加 0x80，資料欄位為例外碼；規範範例中，功能碼 01 的請求位址無效時，回應為功能碼 0x81、例外碼 02。
• 常見例外碼：01 非法功能（不支援該功能碼）；02 非法資料位址；03 非法資料值；04 從站設備故障；閘道器情境另有 0A（閘道路徑不可用）與 0B（目標設備未回應）。
• 設計建議：例外碼 01／02／03 多屬設定或位址錯誤，重試不會改善，應記錄並告警、停止該筆請求；逾時屬通訊問題，才套用有上限的重試，連續失敗後再把設備標示為離線（見第 2、7 題）。
• 記錄時務必保留請求的功能碼、位址、數量與例外碼，這是排查 profile 設定錯誤最直接的線索。

Modbus TCP 在 PDU 前加 7 位元組的 MBAP 標頭（交易識別碼、協定識別碼、長度、單元識別碼），預設埠 502；交易識別碼用來配對請求與回應，單元識別碼用於經閘道器轉送到序列線從站。許多嵌入式設備只允許少量同時連線，閘道器宜維持持久連線並與維護工具協調。

• MBAP 標頭共 7 位元組：交易識別碼 2、協定識別碼 2（Modbus 為 0）、長度 2、單元識別碼 1；欄位為大端編碼，Modbus TCP 使用註冊埠 502。
• 交易識別碼由客戶端設定，伺服器於回應中原樣帶回，因此同一連線上可同時有多個未完成請求；RTU 序列線一次只有一筆請求，所以沒有這個欄位。
• 單元識別碼用於經橋接器、路由器或閘道器（共用一個 IP）連到多台獨立設備的情境，例如 Modbus TCP 轉 RTU 閘道器，此時它指向下游的從站位址。
• 連線數：部分設備只支援少量同時連線（低階設備甚至只有 1–2 條）；若閘道器與維護筆電同時連線，設備可能拒絕其中一方。建議閘道器維持持久連線、啟用 TCP keep-alive，並與維護工具約定不同時連線。
• 連線被拒時先確認設備的實際埠號（部分設備預設並非 502），再檢查防火牆；逾時與重連策略見第 15 題。

匯流排兩端各接一組約 120 Ω 的終端電阻以抑制反射；偏壓（failsafe bias）只在匯流排上設一處，使閒置時 A／B 之間維持足夠的差動電壓，避免雜訊被誤判為資料。終端與偏壓設定不當，是 CRC 錯誤與隨機逾時的常見原因。

• RS-485 接收器需偵測到至少 200 mV 的差動電壓才判讀訊號；匯流排閒置時沒有驅動器作用，雜訊可能被誤判為資料，所以需要偏壓網路讓 B(+) 相對 A(−) 保持正電壓。
• 偏壓只應在匯流排上啟用一處（ABB 指出同一條主幹只應啟用一組偏壓電路），多處偏壓會改變終端負載。
• 終端電阻應與纜線的特性阻抗相符，雙絞線通常為 120 Ω，匯流排兩端各一個；纜線很短或速率很低時終端可能不是必要，但速率與距離增加後就屬必要。
• TI 說明：較舊的收發器沒有內建 failsafe，需外加偏壓電阻，讓閒置、斷線或短路時接收器輸出為確定狀態。
• 排查順序（設計建議）：先確認鮑率、同位與停止位元兩端一致，再檢查終端電阻、偏壓是否只有一處，以及 A／B 極性有無接反。

依 NAMUR NE43，3.8–20.5 mA 為有效的量測資訊（含上下端的超量程區），≤3.6 mA 或 ≥21.0 mA 才判定為硬體故障；3.6–3.8 mA 與 20.5–21.0 mA 為區隔區，故障需持續一段時間才確認，以免誤報。

• NE43 把輸出分成量測資訊（3.8–20.5 mA）與故障資訊（0–3.6 mA 或 ≥21.0 mA）。
• 製程超出量程時，符合 NE43 的變送器可輸出至 20.5 mA，下端也有類似的飽和區；長期漂移可能使低端訊號落在 3.9 mA 附近。
• 3.6–3.8 mA 與 20.5–21.0 mA 是區隔區，符合規範的變送器不應輸出該區間；控制系統可把偵測門檻設在區隔區中間（如 3.7 mA、20.75 mA），不會因漂移而誤報。
• 為避免誤報，硬體故障訊號需持續一段時間才確認（有來源以持續至少 4 秒、至少 2 個掃描週期為例）。
• Siemens ET 200SP 類比輸入模組的範例：低故障範圍 ≤3.6 mA（遲滯 0.2 mA）、高故障範圍 ≥21 mA（遲滯 0.5 mA），進入故障範圍時品質碼為 bad；可直接對應到第 7 題的品質碼設計。
• 各廠預設不同：例如 Yokogawa 的標準輸出上下限為 3.6／21.6 mA，NE43 版本則為 3.8／20.5 mA；故障電流方向（上限或下限）也常可設定。

濾波只在需要時使用：中位數濾波用來剔除孤立尖峰，移動平均或一階（指數）濾波用來抑制隨機雜訊；但送往告警與資料收集的訊號，在 cGMP 製程中通常建議少濾或不濾，並同時保留原始值，以免壓低尖峰幅度或延長其持續時間。

• 移動平均：窗口 N 越大，雜訊變異越小（約與 √N 成反比），但對步階變化的反應是長度 N 個取樣的斜坡，且不會剔除離群值。
• 一階（指數）濾波：運算簡單，但過去資料的影響不會完全消失，同樣不剔除離群值；濾波時間常數不宜大於主要製程時間常數的 1/5。
• 中位數濾波：取最近 3、5 或 7 筆的中間值，用來剔除離群值；若可能連續兩筆異常，用 5 筆即可濾掉；它對一般雜訊的抑制有限。
• 可組合使用：先用中位數濾波剔除離群值，再用一階濾波降低雜訊。
• ISA 指出：送往告警演算法或資料收集系統的訊號，以及 cGMP 製程中影響產品品質的關鍵參數，通常建議少濾或不濾，以如實記錄偏移；必要時同時記錄原始與濾波兩種版本。
• 濾波會增加延遲，且常被不當用來讓趨勢圖「看起來平滑」；強濾波會增加表觀延遲與製程滯後。變送器本身也可能有阻尼設定，現場人員調整會改變表觀動態，應納入變更管理（設計建議）。

建議內部統一以 Pa 儲存，顯示層再換算；常用換算：1 mbar＝1 hPa＝100 Pa，1 inH₂O＝249.089 Pa，1 mmH₂O＝9.80665 Pa。每筆資料都應帶單位（或由測點中繼資料固定單位），避免混用。

• Pa 是 SI 單位，在潔淨室壓差串級、濾網監測等約 2,000 Pa 以下的低壓範圍最常用；北美常用 inH₂O，舊系統常見 mmH₂O。
• 換算：1 mbar＝1 hPa＝100 Pa；1 inH₂O＝249.089 Pa＝2.49089 mbar＝25.4 mmH₂O；1 mmH₂O＝9.80665 Pa。
• 換算驗算：10 Pa ≈ 0.1 mbar ≈ 1.02 mmH₂O ≈ 0.040 inH₂O（依上列係數計算）。把 mmH₂O 當成 Pa 讀取，數值會差約 10 倍。
• 水柱單位依水的密度與重力定義，採 4 °C 水或 60 °F 水時差異約 0.003%～0.1%，不同來源的 inH₂O 數值可能略有出入。
• 設計建議：資料模型固定「值＋單位」，單位用明確代碼；寫入時間序列前先轉成統一單位；測點中繼資料保留設備原生單位與倍率，顯示層才換算（見第 11 題的資料／中繼資料分離）。

BACnet 是樓宇自動化常用的協定，具標準物件模型；Modbus 簡單、廣用，但沒有標準化的資料點描述，須依暫存器表手動設定。兩者並存時，常以 Modbus 轉 BACnet 閘道器完成映射。

• BACnet 由 ASHRAE 發展，常見實作有 MS/TP（RS-485）與 BACnet/IP；MS/TP 同樣需要處理終端電阻與偏壓（見第 17 題）。
• Modbus 沒有網路探索功能，整合人員需要暫存器表與位址，並手動設定每個點；Modbus 也不提供資料點的標準描述，每個暫存器都要依廠商文件解讀。
• BACnet 以預先定義的物件類型呈現資料，讓資訊較容易跨廠商理解，可降低整合工時。
• 閘道器實例：Kele／Sierra Monitor 的 FieldServer EZ Gateway 可把 Modbus RTU／TCP 設備轉成 BACnet/IP 或 MS/TP；Envirco 也有針對其風機過濾單元（FFU）的 Modbus 轉 BACnet 閘道器。
• 選擇原則（設計建議）：由 BMS 端既有協定決定；若 BMS 只講 BACnet，就在閘道器完成映射，並把暫存器表與物件對照表視為契約，以契約測試驗證（見第 12 題）。

每台設備使用一個專屬狀態主題：連線成功後發布 retained 的「online」，並在 CONNECT 時設定同一主題、retained 的 Last Will「offline」；異常斷線由 broker 代為發布 offline，正常關機則須自行先發布 offline，因為正常 DISCONNECT 不會觸發 Will。

• HiveMQ 的做法：以設備專屬主題搭配 retained 與 LWT；連線時帶 Will，連線後發布 retained 的 online；異常斷線時 broker 發布 Will，取代先前的 retained 狀態；重新連線後再發布 online。
• MQTT 每個主題只保留最新一則 retained 訊息，新訂閱者一訂閱就能收到目前狀態。
• AWS IoT Core 文件說明：客戶端主動以 DISCONNECT 斷線時，broker 不會發布 Will；斷線處理為非同步，Will 在重新連線期間不保證依序送達，建議搭配含時間戳與版本號的生命週期事件，以提升準確度。
• 三件事缺一不可：連線後的 online（retained）、CONNECT 時的 retained Will、關機時主動發布的 offline；少了第一項，恢復後仍顯示離線；少了第二項，當機時沒人知道；少了第三項，計畫性關機後仍顯示線上。
• Will 需等到 keepalive 逾時才觸發（例如 keepalive 20 秒，靜默斷網約 1.5 倍時間後才觸發）；Will 的內容宜簡單，因為無法預知故障時的狀態。
• 與 Sparkplug 的 BIRTH／DEATH 概念相近（見第 3 題）；通訊離線與壓差超限屬不同告警，宜分開處理（見第 8 題）。

常見做法是以 ISA-95 設備階層（企業／廠區／區域／產線／儲存格或設備）作為主題階層，下接測點；階層須在部署前文件化，名稱避免空白與保留字元，讓訂閱者能用萬用字元精準取得資料。

• HiveMQ 的命名空間文件依 ISA-95 定義節點類型：Enterprise、Site、Area、Line、Asset、Tag、Field；前幾項屬組織節點，Tag 為單一資料點，Field 是 payload 內的值（不能直接用 MQTT 主題定址）。
• 常見樣式：Enterprise／Site／Area／Line／Cell／測點名稱（Proxus）。
• 示意（非標準）：廠名／廠區／無塵室／房間編號／設備／pressure_diff。
• 訂閱者可用 +（單層）與 #（多層）萬用字元取得某區域或產線的全部資料，這也是階層設計要一致的原因。
• ISA-95 階層是強烈建議但允許彈性調整；重點是命名一致、事先文件化，並建立存取規則，避免資料外洩或被竄改。
• 主題只負責定址；payload 的單位、時間戳與品質欄位仍須另行約定或採用 Sparkplug（見第 3 題）。

正式環境至少使用 Sign 或 SignAndEncrypt（需要保密時用 SignAndEncrypt，None 完全不提供保護），安全原則至少選 Basic256Sha256，每個應用程式實例有自己的 X.509 憑證，並由管理者維護信任清單與憑證撤銷清單。

• OPC 基金會建議：SecurityMode 應使用 Sign 或 SignAndEncrypt；None 不提供任何保護；需要機密性時必須使用 SignAndEncrypt。
• SecurityPolicy 至少選 Basic256Sha256（前提是既有客戶端皆支援）；使用 SHA-1 的較弱原則不應使用；連線策略應從最安全的設定開始，逐級往下協商。
• 使用者驗證：匿名登入只適用於非關鍵資源，因為無法追蹤是誰修改了資料或設定。
• 應用程式鑑別：每個 OPC UA 應用程式實例都有 ApplicationInstanceCertificate，在建立 SecureChannel 時交換；接收方依信任清單（TrustList）判斷是否信任，信任清單由管理者指定的憑證庫實作，並含 CA 與憑證撤銷清單（CRL）。
• 實務：使用自簽憑證時，要把對方憑證安裝到信任清單；使用 CA 簽發的憑證則只要信任該 CA，並須維護最新的 CRL。
• 憑證庫的存取：存放私鑰的憑證庫只應允許管理者與應用程式讀寫，信任清單只允許管理者寫入。

傳輸與儲存一律使用 UTC，並以 RFC 3339 格式（帶 Z）表示絕對時間，例如 2026-10-22T12:00:00Z；本地時區只在顯示層轉換，需要追溯當地時間時另存時區或偏移欄位。

• RFC 3339 是 ISO 8601 的網際網路設定檔；夏令時間規則複雜，且可能被當地法規無預警更改，要達到真正的互通，最好使用 UTC。
• 帶偏移的時間（如 18:50:00-04:00）等同 UTC 的 22:50:00Z；若 UTC 已知但本地偏移未知，RFC 3339 以「-00:00」表示。
• W3C 建議把時間戳記正規化為 UTC，以便不同序列比較與合併；沒有把握時，序列化、儲存與交換都用 UTC。
• AEP（API 設計指引）：絕對時間欄位用 RFC 3339 字串、UTC 並明確帶 Z，欄位名稱以 _time 結尾（如 create_time）。
• InfluxDB 內部以 UTC 的 epoch 奈秒儲存，查詢時以 RFC 3339 UTC 呈現。
• 設計建議：資料契約同時規定欄位名稱（如 source_time、received_time）、格式與精度；少數設備只提供本地時間而無時區資訊，需在閘道器補上並記錄假設；校時見第 9 題，來源時間與接收時間見第 7 題。

常見做法是兩個 bucket：原始高解析資料放短期保留的 bucket，定期聚合成低解析（如 1 小時平均）寫入保留期間更長的 bucket；降採樣任務須排在原始資料到期之前，並考慮資料遲到。但受法規管理的紀錄不宜只留聚合值。

• InfluxDB 降採樣需要來源 bucket、目的 bucket 與聚合方式（mean、median、top、bottom 等）；目的 bucket 的保留期間應比來源更長。
• 官方範例任務每週執行，以 1 小時窗口取平均後寫入降採樣 bucket。
• 注意：若資料可能遲到，要設定足夠的 offset；若來源 bucket 有保留期限，任務須排在期限到達之前執行。
• 好處是降低儲存量，並加快大範圍時間的查詢；InfluxDB 3 的 Downsampler 外掛還會在降採樣紀錄附上 record_count、time_from、time_to 等欄位，利於稽核聚合範圍。
• 壓差場景的取捨（設計建議）：聚合除了平均，也應保留最大值、最小值與超限次數，否則短暫的超限在平均後會消失；平均與濾波一樣會隱藏尖峰的實際幅度與持續時間（見第 19 題）。
• 告警事件與稽核相關紀錄應另存，保留年限依品質系統與法規決定（見第 5 題的資料模型、第 30 題的資料完整性）。

無資料與查詢錯誤是和「壓差超限」不同的狀況。以 Grafana 為例，預設會產生獨立的 DatasourceNoData／DatasourceError 告警，也可改設為 Alerting、Normal 或 Keep Last State；壓差監測不建議把無資料當成正常，並應搭配等待期（pending period）避免瞬斷誤報。

• No Data 狀態：查詢成功但完全沒有資料點；它遵守等待期，狀態依序為 Normal → Pending → No Data；等待期設為 0 則立即進入。
• 查詢錯誤（逾時、網路中斷、查詢無效）是 Error 狀態，與資料來源離線的可用性問題不同。
• 可選行為：No Data（預設，觸發 DatasourceNoData 告警）、Alerting、Normal、Keep Last State；Keep Last State 可緩解暫時性的資料來源問題，但嚴格監控時不宜單獨依賴，應另設規則偵測長時間中斷。
• Keep firing for：條件解除後仍維持觸發一段時間，避免反覆觸發、解除、再觸發。
• 自 Grafana v12.4.0（2026-02-12）起，NoData 與 Error 也遵守等待期，通知在等待期過後才發送。
• 壓差場景（設計建議）：Normal 會在斷線時掩蓋風險，Keep Last State 會讓最後一筆「正常」值被當成現況，都不宜單獨使用；應搭配品質碼與設備上線狀態（見第 7、22 題），把通訊異常與壓差超限分成不同告警（見第 8 題）。

把整合程式當成服務來監控：以 Prometheus 慣例輸出指標，例如最後一次成功輪詢的 Unix 時間戳、輪詢耗時、錯誤計數；用「目前時間 − 時間戳」判斷資料新鮮度，並採用應用前綴、基本單位與標籤來命名。

• Prometheus 建議：要追蹤「距離某事件多久」，輸出事件發生的 Unix 時間戳，而不是「經過了多久」；以 time() − 時間戳 計算，可避免更新邏輯卡住而不自知。
• 命名：指標名稱應有應用前綴、使用基本單位（秒、位元組），累計計數以 _total 結尾；官方範例 data_pipeline_last_record_processed_timestamp_seconds 就是追蹤資料管線最新處理紀錄時間的時間戳指標。
• counter 只增不減（重啟時歸零），要搭配 rate() 使用；會下降的值用 gauge，且不要對 gauge 取 rate()。
• 用標籤區分維度，而不是把變動資訊放進指標名稱。
• exporter 應在被抓取時同步取得指標，不要自行設定時間戳，由 Prometheus 指派；若覺得需要自行帶時間戳，通常代表該改用 Pushgateway。
• 示意指標（設計建議）：modbus_poll_last_success_timestamp_seconds{device}、modbus_poll_duration_seconds、modbus_request_errors_total{type="exception|timeout"}，並與第 6 題的緩存佇列長度一併輸出。

EU GMP Annex 1（2022 版）以至少 10 Pa 作為不同等級相鄰房間壓差的指引值；被判定為關鍵的壓差須連續監測並記錄，並有警報即時警告操作人員。警報不可未經評估就被忽略，警報延遲須在污染控制策略（CCS）中評估並說明理由。

• Annex 1 4.14：不同等級的相鄰房間應有至少 10 Pa 的壓差（指引值），並特別保護關鍵區；潔淨室在所有操作條件下，應相對較低等級的背景環境維持正壓或氣流。
• Annex 1 4.16：潔淨室之間（或隔離器與其背景）應裝設壓差指示；設定值與壓差的關鍵性應納入 CCS；判定為關鍵的壓差須連續監測並記錄；須有警報系統即時指示並警告操作人員空氣供應失效或壓差降到設定值以下。
• 警報訊號不可未經評估就被忽略，並應有程序說明警報時的處置步驟；若設有警報延遲，須在 CCS 中評估並提出理由；其他非關鍵壓差則定期監測與記錄。
• ISPE 文章的設計範例：相鄰房間在門關閉時維持 10–15 Pa；偏離操作範圍（如 ±2.5 Pa）發出警示，偏離設定值達 5 Pa 以上且持續預定時間則啟動警報。這是設計範例，不是法規數值。
• 軟體含意（設計建議）：區分關鍵與非關鍵測點的監測頻率與記錄方式；警報延遲、遲滯等參數以可設定項管理並保留變更紀錄；警報的確認與抑制都要留紀錄（見第 30 題）。

FDA 2018 年的資料完整性指引把資料完整性定義為資料的完整性、一致性與準確性，且應具備 ALCOA 特性（可歸屬、清晰易讀、同步記錄、原始或真實副本、準確）；稽核軌跡則是安全、由電腦產生、帶時間戳記的紀錄，可重建電子紀錄的建立、修改與刪除經過。軟體應保留原始資料與中繼資料，並記錄修改理由。

• 資料完整性適用整個 CGMP 資料生命週期：建立、修改、處理、維護、封存、取回、傳輸，以及保存期後的處置；系統設計與控制應使錯誤、遺漏與異常結果容易被發現。
• 中繼資料（metadata）是理解資料所需的脈絡資訊：例如數字「23」若沒有單位「mg」就沒有意義；中繼資料可包含取得時間戳記、操作者 ID、儀器 ID 與稽核軌跡，且資料與其中繼資料的關係必須以安全、可追溯的方式保存。對應到壓差，就是數值要連同單位、測點 ID、品質碼與時間戳一併保存。
• 稽核軌跡的範例：應包含使用者名稱、執行日期與時間、使用的參數與重新處理的細節，重新處理並應記錄變更理由；稽核軌跡涵蓋資料層（建立、修改、刪除）與系統層（存取嘗試、重新命名或刪除檔案）。
• FDA 對 21 CFR Part 11 的適用範圍指引指出：是否採用稽核軌跡，可依適用的規則要求與經文件化的風險評估決定；使用者預期會建立、修改或刪除受管制紀錄時，稽核軌跡特別適用。
• 軟體設計含意（設計建議）：原始資料不覆寫，修正以新版本新增並保留原值；補傳資料保留來源時間與接收時間（見第 6、7 題）；告警確認、抑制與門檻變更都寫入稽核軌跡；原始值與濾波值並存（見第 19 題）；時間同步狀態一併記錄（見第 9 題）。