WHO_FITS
誰適合？
監控系統整合的詢問，三種現場最典型：高雄與南台灣的廠區、倉庫與大樓。共同點是資料就在設備裡，但人要用的時候拿不出來。
工廠廠務
廠務設備監控與機房環境監控要盯的是溫濕度、電力與設備狀態，但異常常常是隔天巡檢才發現。現場有感測器，數字卻只停在設備面板上，沒有集中的儀表板，也沒有人被通知。
物流倉管
客戶打電話問「這筆貨到底有沒有出」，倉管得先查出貨時間，再到監控主機把時間軸一格一格拉回去，還要猜是哪一支攝影機。一天幾通就等於綁住一個人。出貨影像查詢做成單號直接調畫面，這件事就結束了。
大樓管理與連鎖門市
監控、門禁、網通、照明各自一套原廠 App，帳號密碼一堆，跨點沒有統一畫面。要看「哪個點現在不正常」，只能一個一個開。智慧建築系統真正缺的不是更多設備，是一個把它們收在一起的介面。先講清楚：多點狀態集中看、告警分流、設備對接我們做得出來；建築平面圖上的空間可視化目前是展示版，沒有可公開的建物導入案例，細節寫在下面。
這三種場景克隆資訊用同一套管線處理：現場設備先把狀態送出來（MQTT 感測器監控，或設備本身的介面），影像則直接取 DVR／NVR 的標準串流，集中成可視化儀表板，異常依規則通報，影像和公司系統的單號對起來。IoT 系統整合講到底就是這條管線，差別在每個現場的設備長得不一樣。
系統端全台遠端進行；這一項是唯一需要有人到現場的服務——勘查與佈線依專案安排時間。
NOT_FOR_YOU
誰不適合？
下面幾種情況，我們會直接說不要做，或建議找別人做。
- 只要裝幾支攝影機、不用跟任何系統對起來。找監視器經銷商比較快也比較便宜。整合的價值在「和單號、工單、ERP 對得起來」，沒有這個需求就不需要我們。
- 設備完全封閉，原廠不開放串流或 API，也不接受更換。沒有介面就接不起來。這件事勘查時就看得出來，我們會在報價前講，不會先收錢再說做不到。
- 還沒想清楚要看什麼、誰處理告警。「先上系統再想要看什麼」做出來沒人看。至少要能說出哪三個數字會讓你半夜想被吵醒、以及誰負責處理。
- 要的是保全值勤或代管監看。我們做系統，不派人值班、不做保全業務。
- 希望一次性交付、之後完全不留維護。IoT 的現場會變：設備汰換、網路改線、門檻要調。沒有維護安排，這些事發生時就沒人接，系統很快會沒人用。
WHAT_WE_DID
我們做過什麼？
監控系統整合分兩塊講：有程式碼可對照的，以及沒有程式碼、要在現場做的。
出貨影像查詢與監控影像回放整合
這是我們做的出貨影像回放系統，把監控影像和出貨單號綁在一起。倉管輸入出貨單號，系統自動跳到該筆出貨前 30 秒（預設值，可依現場調整），四路攝影機同格回放，不必手動拉時間軸。串流採自適應位元率（ABR），倉庫的網路品質不穩時自動降階，先讓畫面出來。不綁 DVR／NVR 品牌，走的是設備本身的標準串流，通常不必為了軟體換硬體。
設備異常告警規則
這是我們做的監控系統，設備狀態走 MQTT 集中、異常經規則判斷後推播，這條路線的程式碼是現成的。設備異常告警規則怎麼定，才是這一頁真正的重點。我們照三層設計：
- 持續時間門檻與遲滯。超標且持續一段時間才觸發，而不是數值跳一下就叫；設計上回落也要低於門檻一段幅度才算恢復，避免在邊界上來回震盪。
- 同一件事只吵你一次。同一事件在恢復前只發一次，設計上恢復時補一則結束通知，讓收到的人知道問題還在不在。
- 分級與升級。依嚴重程度決定通知對象，設定多久沒有人處理要往上升一級。
這三層是我們導入時會做的設計，不是現成套用的預設值。訊息怎麼排版送進 LINE、推播與回覆額度怎麼算、綁定後誰收得到，屬於 LINE 企業應用開發。
空間可視化：Clone Vision
我們自研的跨設備整合平台，在建築平面圖上直接看設備狀態與監控畫面，MQTT 收 IoT 資料、RTSP 取攝影機串流，自動化規則在本地運算。目前為展示版，沒有可公開的建物導入案例。智慧建築與空間監控這一塊，我們寫的是承接能力，不是做過的成績。實際介面可以在 本地化智慧家庭與隱私實作 裡看到。
機房與廠區環境監控（承接）
走的是上面同一條管線：感測器 → MQTT → 儀表板 → 告警，這條管線是現成的。門禁與電力狀態能走一樣的路徑，我們承接；接不接得上要看現場控制器開放什麼介面，勘查時逐台確認。
現場那一半
佈線規劃、攝影機角度與參數調校、感測器校正、設備選型建議都在我們的承接範圍內，這部分不會有原始碼。我們不是只寫程式然後請師傅去裝——攝影機對錯角度，再好的回放系統也查不到你要的那一幕。這部分需要排現場時間，系統端則全程遠端。
和公司系統怎麼接
影像與感測資料要有用，前提是跟訂單、工單、庫存對得起來——也就是監控系統串接 ERP 這件事。ERP 與既有系統的整合邊界我們處理過：全通路訂單整合平台 用讀鏡像、寫 API 的方式不動 ERP 主帳；唯讀 ERP 查詢閘道 則是嚴格限制查詢範圍與稽核。從零開始的系統本體屬於 企業系統客製開發。
PROCESS
怎麼進行？要多久？
先勘查，再決定範圍。看過現場之前我們不報時間，也不報價。
- 現場勘查與可行性確認。逐台列設備型號、能不能取得串流或 API、帳號權限誰持有；同時在預定安裝點實測網路訊號與封包遺失，而不是看規格書。
- 定義要看什麼、誰處理。哪些數字進儀表板、哪些狀況要通知、通知給誰、多久沒處理要升級。這一步沒談完，後面做什麼都會白工。
- 小範圍試點。一條產線、一個出貨口或一層樓，把感測、告警與查詢流程整輪跑完。試點會把真正的問題逼出來：設備介面、佈線路徑、以及告警到底有沒有人理。
試點的驗收條件開工前就寫成書面。 哪幾支攝影機要能用單號調出畫面、哪幾條告警要在幾分鐘內送到指定的人手上、誤報要降到什麼程度，逐條列出來當驗收依據。試點沒過就不進下一階段，已完成的設備與介面清單、佈線圖仍然給你。
- 串接公司系統與儀表板。影像與感測資料對上單號與工單，這時候才看得出整合的價值。
- 現場佈線、調校與交付訓練。攝影機角度與參數、感測器校正、操作人員實機走過一次。
- 觀察期調門檻。上線後跟著實際數據把門檻與升級時間調過一輪，告警才會被信任。交付後保固期內的告警門檻調整與對接修正不另計費，期間長度依合約。
實際天數看下面三件事。
時程主要卡在三件事：設備能不能開放介面、現場施工要不要停線或停工、告警規則要跑幾輪才穩。這三項在勘查後就能給明確的階段時程。
PRICING
費用怎麼算？
依需求評估。計價結構分成勘查與需求定義、系統建置、現場工程、雲端與儲存、後續維護五塊，可以拆開談，也可以只做前兩塊確認可行性再決定要不要往下。
影響金額的是這幾件事：
- 設備數量與種類。設備型號越單一越省；每多一種介面就是一套對接與測試。
- 介面開放程度。設備直接給標準串流或 API 最單純；要靠中繼裝置轉換或逆推私有協定，工就明顯多一截。
- 影像保存期與畫質。保存幾天、幾路、什麼解析度，直接決定儲存與頻寬，而且是按月累積的成本，不是一次性的。
- 現場工程量。佈線長度、要不要走管線或天花板、有無高空作業、能不能在營運時間施工。停線施工的成本通常比材料高。
- 要不要串既有系統。只做儀表板，和要跟 ERP／WMS 的單號對起來，是兩種規模。
- 維護範圍。只做故障排除，或包含門檻調整、設備汰換後的重新對接，範圍不同價格不同。
設備選型我們會給建議與理由，由誰採購可以談。
OWNERSHIP
帳號與資料歸誰？
都是客戶的。這件事在開工前就寫進書面，不留模糊空間。
- 雲端專案（Cloudflare、GCP）、網域、儲存桶一律開在客戶自己的帳號，我們以受邀成員身分進去做事。不會出現「系統在廠商帳號底下」這種情況。
- 設備帳號密碼由客戶保管。我們需要的權限列成清單給你核准，結案時移交並移除我們的存取。
- 影像與感測資料存哪裡由客戶決定。我們的預設建議是影像留在現場錄影主機，雲端只存事件索引與縮圖，要調的時候才從現場取那一段。這樣成本低、外流面也小。
- 原始碼與部署設定結案移交，包含儀表板、告警規則與對接程式。
- 遠端連線走 Zero Trust Tunnel由內部往外建立通道，不對外開 port、不做 DDNS 轉發。誰能連、權限怎麼收回屬於存取控管，整體資安架構（WAF、DDoS、Zero Trust）寫在 企業雲端建置與資安防護。
EVIDENCE
這一頁的說法，去哪裡查證？
這一頁的技術主張都有出處，發布單位不是我們。
- MQTT 是公開標準我們說「設備狀態走 MQTT 集中」時，指的是 OASIS 的 MQTT 5.0 標準，不是某一家的私有協定。走標準協定，換掉我們之後你的設備一樣接得上別人。
- 攝影機能不能被整合，看它支援哪個 ONVIF ProfileONVIF Profiles 說明定義了串流（Profile S／T）與存取控制（Profile A／C）的能力範圍。勘查時逐台確認型號與 Profile，就是在確認這件事，不是憑經驗猜。
- 監控影像屬於個人資料《個人資料保護法》最近一次修正公布於民國 114 年 11 月 11 日。影像保留多久、誰調得到、調閱要不要留紀錄，我們在定義階段就一起決定，不是上線後才補。