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