Factory JAVIS
智慧工廠能源監控系統。從發表論文,再延伸為黑客松作品 Flex Pro 。
- 期間
- 2026
- 角色
- 系統設計、後端與看板實作
- 技術
- FastAPIPython asyncioSQLite WALVue 3EChartsChart.jsDockerRaspberry Pinginx
- 連結
- 黑客松新聞(高科大) ↗

問題
有多台設備,想知道哪一台吃電最多、現在誰在跑、一天下來花了多少電費和碳排。條件有三個:資料要留在實驗室內網、不依賴任何雲端服務、裝置成本要低到中小型模具廠負擔得起。
架構
模具製造設備(CNC / 射出機 / 空壓機)
│ 配電端各接一顆
▼
衛星裝置:CozyLife 智慧插座(非侵入式電流量測)
│ 區網 TCP 協議,asyncio 長連線,每 30 秒批次查詢
▼
邊緣電腦(三個容器化微服務)
├── 資料採集服務 ──批次寫入──► SQLite(WAL)
├── 後端 API(FastAPI,9 個端點)
│ ├── REST ──► Vue 3 + ECharts 桌面管理介面
│ └── 5 秒輪詢 ──► 800×480 嵌入式工業看板(Chart.js)
└── nginx 靜態代理(:80 對穿透隧道、:8081 僅區網給看板)
│
▼
碳排估算 ── 異常耗能分析 ── 決策支援儀表板
所有業務資料只存在邊緣電腦本機。穿透隧道只指向 nginx 的 :80,看板用的 :8081 對公網而言不存在,不靠防火牆規則,在拓樸上就碰不到。
做了什麼
- 衛星裝置通訊:逆向 CozyLife 插座的區網協議,用 asyncio 寫非同步 client,維持長連線、每 30 秒對全部裝置並行查詢,加上 /24 網段自動掃描與註冊,新插座插上電就被收進系統
- 批次上報:原本每顆裝置各自打一次 API,重構成一個查詢週期聚合後單批寫入,服務間請求數從 O(N) 降到 O(1)
- 後端與儲存:FastAPI 九個端點(即時狀態、歷史時序、區間能耗、設備管理、系統指標),SQLite 開 WAL 並設 5 秒鎖等待,高頻寫入與多並發讀取互不阻塞
- 碳排與成本:任一區間的碳排 = 累計用電差 × 電力排碳係數(經濟部能源署 113 年度 0.474 kg CO₂e/kWh,做成可逐年更新的參數),電費用同一筆資料乘工業電價。不加任何感測硬體就同時得到兩個數字
- 異常耗能:用設備歷史用電算 μ±2σ 的基準耗能模式,超出就推警示;依累積用電、碳排、成本排序產生 Carbon Hotspot Ranking
- 可靠性:採集服務寫資料時同步更新心跳時戳,前端據此分出「服務存活 / 離線」與「設備在線 / 資料過期 / 離線」;自動部署後等 110 秒穩定期,再驗證心跳時戳是否真的更新過,不符就回滾到前一版。這個雙重判定是為了修掉「壞版本被誤判為健康」的競爭條件,並用注入故障的方式驗證過 110 秒內會還原
- 看板:既有監控工具在 ARM64 上多次整合失敗後,改用 Chart.js 自製 800×480 kiosk 看板,呈現多衛星裝置熱圖、功率趨勢與即時 KPI
- CI / 部署:GitHub Actions 自動編譯前端與打包後端,邊緣電腦排程比對版本拉新版
量化結果
實驗室既有設備上連續部署 12 天:
| 項目 | 數字 |
|---|---|
| 累積樣本 | 130,046 筆,平均上報間隔吻合 30 秒設計值 |
| 三個微服務記憶體 | 合計約 150 MB,CPU 平均合計低於 1% |
| 即時狀態端點延遲 | P50 6.45 ms、P95 7.23 ms |
| 歷史時序端點(24 小時、約 1 萬筆 JSON) | P50 58.9 ms、P95 65.9 ms |
| 累計用電單調性違規 | 10 萬餘筆中 2 筆(0.002%),來源是設備斷電重置,不是採集或儲存層 |
三個場景
同一套系統走了三個地方:
-
實驗室上線
-
論文:〈面向中小型模具製造企業之低成本智慧碳排監測系統建構與初步驗證〉,曾唯誠、梁鈞瑋、許桓瑜、鄭瑞鴻,2026 台灣區模具工業同業公會「模具暨應用產業技術論文發表會」
-
黑客松:兩天在 Pi 4B 上重建最小版,接上 Bambu A1 mini 當試量產場域,往上疊一層「FlexPro 製程智選」商業應用(24 小時試量產評估:製程 / 成本 / 碳排 / 風險報告)。2026 教育部技職盃黑客松南區評審團大獎、全國賽佳作

