先定義流量單位
需求常寫每秒一千筆，但測試需要知道每筆 payload 大小、標頭、封包分段、方向、連線數與峰值持續時間。bits 與 bytes 必須分開，payload 大小也不等於線路上的總位元組。
先畫資料流向：感測器到閘道、閘道到資料庫、回覆到設備。每段可能有不同編碼、重試與批次大小。若只把應用層字串長度乘頻率，就會低估協定與傳輸層負擔。
例如每秒 200 訊息，每個 payload 600 bytes，應用資料量是 120,000 bytes/s，換算約 960,000 bits/s；若估計額外標頭與重試 20%，規劃線路負載約 1.152 Mbit/s。這是負載假設，不是設備實測。
峰值還要寫 burst 形狀。每秒平均相同，可能是均勻 200 筆，也可能在 100 ms 內集中 200 筆；佇列、緩衝與逾時會因此不同，測試器要能表達這項差異。
還要區分有效訊息數與傳輸嘗試數。重試可能讓線路流量增加，卻沒有增加有效業務資料；兩者都列出，才能評估容量與可靠性。
本文適用通用 PLC、HMI 與整合服務的負載規劃，不指定網卡、模組或通訊指令；實際上限要依版本手冊、拓撲與現場量測確認。
從需求算到線路
把需求拆成正常、尖峰與故障重送三種情境。正常情境可用 200 筆/s，尖峰設定 400 筆/s 持續 30 秒，故障情境再加 10% 重試；每個數字都要寫來源與允許範圍。
若每筆 payload 600 bytes、應用封裝額外 40 bytes、每秒 200 筆，估算總資料為 640×200=128,000 bytes/s，即 1.024 Mbit/s，尚未含底層額外成本。測試報告應寫估算邊界，不能把它當 NIC 實測。
批次會改變結果。十筆合併一包可能減少封包數，但增加單包延遲與失敗重送的資料量；因此同時記錄批次大小、最大 frame、壓縮與編碼。不同設定不可直接共用同一門檻。
測試前固定方向與連線數，並確認收發兩端的計數器定義。某工具以 bytes 計，另一工具以 bits 計，若未統一單位，報告可能出現八倍錯誤。
壓縮後大小若隨內容改變，應使用實際分布或最壞情況，不可只用一個漂亮平均值。測試資料要說明是否代表尖峰內容，否則容量結論很脆弱。
把 payload、協定標頭、封包數與線路 bits 分欄，還要保存編碼與壓縮設定。任何欄位口徑改變，都建立新負載版本，不能直接和舊結果疊加。
百分之十五重試在本文練習中定義為額外完整傳送次數占原始次數的比例，所以可乘一點一五。若需求給的是每次嘗試獨立失敗機率，重試次數還受重試上限與後續失敗影響，不能直接當成同一個加成係數。
建立峰值與基準
先固定每筆有效內容六百bytes，以每秒二十筆建立基準，量測吞吐、p95延遲、錯誤數與佇列深度，再逐級增加到一百、二百、四百筆。若另要比較每筆一百bytes，建立不同測試組，避免同時改大小和頻率而混淆原因。
門檻在測試前決定，例如尖峰 400 筆/s 持續 30 秒、遺失率 0、p95 小於 200 ms；這些是需求轉成的驗收條件，不可看到結果後才調寬。沒有需求來源時，標為暫定門檻並請負責人批准。
峰值測試要保存輸入產生器設定、時間表、payload 大小分布與封包計數。平均值不代表尖峰，平均吞吐達標但 burst 時佇列爆滿仍應判為該情境失敗。
若資源不足，先判斷測試器瓶頸。產生器 CPU 滿載或網卡受限時，測到的是測試器能力；應用、線路與設備計數器要互相對照，不能只看單一監控圖。
方向不對稱時，回覆流量也要換算；設備上傳低而控制回覆高，單看總量可能掩蓋某一方向先飽和。測試報告將收與發分開記數。
假設尖峰 400 筆/s 持續 30 秒，只能說明此測試時間表；它不代表全天流量，也不保證設備緩衝、CPU 或交換器在其他 burst 形狀下相同。
尖峰結束後繼續記錄排空時間。假設三十秒內送入一萬二千筆，截止時只完成一萬一千五百筆，剩下五百筆須追蹤至成功、拒絕或逾期，不能只因來源停止便結束統計。完成期限由需求指定，期限後完成另列延遲結果。
負載測試結果判讀
假設案例用 600 bytes payload、400 筆/s、30 秒，應用資料量為 7,200,000 bytes；加入 20% 估計後約 8.64 MB，不代表實際線路一定是此值。測試結果另記收發計數與實際封包統計，差異才可排查。
假設達標結果為產生器送出 12,000 筆，接收端確認 12,000 筆，p95 為 142 ms；失敗結果可能是送出達標但接收少 30 筆。此時先分辨丟失在產生器、網路、服務或確認邏輯，不能直接歸咎頻寬。
若只測平均速率而漏測 burst，限制欄要明寫。若重試造成資料加倍，也要把原始與重送分開計數，否則總量會掩蓋有效訊息數。
結果比較必須維持相同 payload 分布、批次、連線數與門檻；任何一項改變都建立新基準。測試未含實際加密或壓縮時，不能把估算結果外推正式部署。
負載遞增應設定停止條件，例如錯誤率超門檻、佇列持續上升或測試器受限。達到停止條件就保存證據，不為了追求更大數字而破壞環境。
若產生器先達到 CPU 上限，結果不能用來判定被測系統容量。先確認發送端、接收端與線路計數器一致，再決定是否需要更強產生器。
練習與常見問題
問：payload 1 MB/s 就代表線路 1 MB/s 嗎？答：不一定，標頭、編碼、重試、加密與分段都可能增加線路量。
問：平均吞吐達標但尖峰遺失，算通過嗎？答：依需求情境判斷；若尖峰是驗收條件，就應判該情境失敗並保留證據。
問：bits 和 bytes 可以在報告中省略單位嗎？答：不可以，數字沒有單位會造成八倍換算錯誤。
問：測試器送出數量正確就代表設備收到嗎？答：不代表，還需接收端確認、封包或應用層計數與錯誤分類。
容量估算只支援測試設計，不能取代網路、設備與安全工程評估；正式門檻仍需由需求擁有人核准並以實際部署驗證。
練習答案：有效內容為每秒二十萬bytes；含六十bytes標頭後為二十一萬五千bytes；再按額外完整傳送百分之十五計，為二十四萬七千二百五十bytes，即每秒一百九十七萬八千bits。此處仍未計其他底層成本，尖峰的筆數與時間表需另列。
參考：NIST SP 800-82 Rev. 3：OT 網路架構與運行影響考量。