每新增一款感測器都變成新專案，產品利潤怎麼可能守得住？

工廠鬼話

客戶拿著新規格書找維護人員。

客戶： 之前那款溫度感測器斷貨了，我們要換新廠牌。你們接上去要多久？

維護人員看了一眼。外觀差不多，一樣是溫度，一樣有通訊，一樣會吐數值。他心裡想，畫面上本來就有溫度欄位，應該不會太難。

但他不敢答應，只能回公司問 RD。

RD： 這不是換一顆而已。

維護人員： 它不就是溫度嗎？

RD： 對客戶來說是溫度，對程式來說不是。新廠牌代表新封包格式，我要新增 case，確認位元組位置、倍率、單位、小數位、錯誤碼，還要測斷線、重連、異常值會不會影響原本流程。

維護人員： 所以不是一兩天？

RD： 接起來也許很快，但交付不是只看接不接得起來。

老闆在旁邊算另一筆帳。這個客戶平常利潤不高，維護費也壓得低，這次剛好補一點回來。

老闆： 報 XXXX。不要太低，以後每換一顆都變免費支援。

隔天，維護人員回覆客戶。

維護人員： 開發部評估兩週，費用是 XXXX。

客戶： 兩週？費用還這麼多？溫度功能不是本來就有了嗎？

客戶不是不想付錢。他只是覺得這應該是小修改，不該是大工程。最後需求就停在那裡。

同一件事，四個角色看到的成本完全不同。

客戶看到的是功能：溫度本來就有。

維護人員看到的是現場：設備換了，應該接一下就好。

RD 看到的是程式結構：每個新廠牌都要新增解析邏輯，還要測影響範圍。

老闆看到的是商業帳：這次不收，以後每次都變免費。

這就是很多工廠系統最常見的鬼話：只是換一顆感測器。

如果每一種新設備都要 RD 進程式加 case，它就不會是小事。它會變成一次又一次的小專案，吃掉廠商毛利、客戶耐心，也吃掉維護人員的信用。

ParserManager 要處理的，就是把能設定的變動拉出來，不讓每個現場差異都直接變成程式修改。

這章不是在教偷懶不寫程式，而是在處理碎片化擴大後的產品成本：如果每種新感測器都變成新專案，SI 的利潤和維護速度都會被吃掉。

課程地圖

圖解：本章在 LocalNest 架構中的位置

圖解：ParserManager、語意對應與 DCE 的分工

10-1 現場痛點：新感測器不該變成新專案

製造現場的整合商有一個固定的噩夢：

客戶打電話說：「那個日本廠牌的振動計斷貨了，
我找到另一款，規格差不多，可以協助接進系統嗎？」

整合商知道這意味著什麼：
要拿到新感測器的資料格式文件，
看懂廠商把數值放在哪裡、用什麼倍率、單位是什麼，
然後找工程師修改封包解析器、送測試、排期部署。
兩週後才能回覆客戶「好了」。

這不只發生在 BLE。
Modbus 的點位表和暫存器設定已經是成熟做法，
通常本來就會被拉出來獨立設定，所以它不是本章最痛的例子。

更麻煩的是這幾類資料來源：

這些格式不一定複雜，但如果每一款都寫成一段程式碼，維護成本會一直累積。
真正應該抽出來的是：這筆資料從哪個位置讀、怎麼換算、是否有效，以及後續要用哪一種統計方式處理。

這個流程有兩個問題：

第一，太慢。
在現場環境裡，「兩週」等於「客戶已經開始懷疑整合商的能力」。
更麻煩的是，客戶不一定相信這些時間真的都花在技術處理上，
還可能懷疑整合商是不是多報工時。

第二，不該這麼貴。
修改封包解析器是例行性的技術工作，不應該每次都動用核心工程師的時間。
如果每加一款新裝置都要改程式碼，整合商的人力成本永遠降不下來。

根本原因是：
解析邏輯與資料行為寫死在程式碼裡，
跟裝置型號直接耦合。
ParserManager 解決封包怎麼拆、怎麼換算；
DCE 解決解析後的值該用哪一種統計方式處理，
讓後續統計與歷史資料處理知道該怎麼用。

10-2 架構分工：解析、語意、統計要分開

Device Core Extraction（裝置行為核心萃取，DCE） 的核心主張是：

DSS（Device Semantic Stack，裝置語意棧）已在 CH03 定義為裝置身份分層，負責 R / VU / VS 等身份如何一路接到上層顯示。它回答的是「誰是誰、上層指向誰」，不是 Parser 與 DCE 中間的統計轉換程序。

本章要看的中間層是「語意對應」：Parser 解出的來源 Key 要接到哪一種 DCE 行為。原生設計由 USFID 設定承接這個對應，細節放在 EX05。

一個傳統的 BLE 封包解析器長什麼樣：

def parse_ble_packet(manufacturer_id, payload):
    if manufacturer_id == 0xABCD:   # A牌溫度計
        raw = int.from_bytes(payload[2:4], 'big')
        return {'temperature': raw * 0.1}
    elif manufacturer_id == 0xEFGH: # B牌溫度計
        raw = int.from_bytes(payload[5:7], 'little')
        return {'temperature': (raw - 2731) / 10.0}
    # ... 每加一款就多一個 elif

這個設計的問題不是程式碼寫得爛，而是把「設定」和「邏輯」混在一起了。

「從第 2 個位元組開始取 2 個位元組、大端序、乘以 0.1、單位是 °C」
——這是裝置差異，應該放在設定檔。

「依設定取值、換算、檢查有效性、輸出標準資料」
——這是共用解析流程，應該留在解析引擎裡。

把裝置差異移出程式碼，在 DB / 統計支線要分成三層看。

第一層是 ParserManager：這段封包資料怎麼拆、怎麼換算。
第二層是語意對應：這筆資料代表什麼，以及要接到哪一種 DCE 行為。
第三層是 DCE：解析後的值依統計特性進入平均、累積、邏輯判斷或其他已支援的方法。

即時支線也會使用 ParserManager 內的即時解析能力，但不等待 DB 支線的 DCE 統計完成。

遇到全新的協定框架、系統從未支援的換算方式，可能需要擴充解析引擎。
遇到全新的統計方式，可能需要擴充 DCE 行為核心。
但既有行為的新增裝置，不應該每次都變成新專案。

10-3 ParserManager：raw data 怎麼解

本節把 ParserManager 當成「解析能力與設定的家族」來說明，不代表執行時只有一個共同 Parser 先跑完，再把同一份結果分給即時與 DB。

ParserManager 的責任很單純：
把 raw data 依照設定檔解析成系統看得懂的標準資料。
它處理的是「資料怎麼拆」，不是「資料後續怎麼統計」。

ParserManager 把封包解析工作分成兩層：

解析引擎是通用的：
給它一段位元組資料和一條規則，它就能輸出工程值。
設定檔是特定的：每款感測器一行規則，說明欄位位置、倍率、單位與有效範圍。

這裡的 CSV 指的是 ParserManager 的解析設定檔。
它記錄的是「怎麼拆封包」：
從哪裡取值、怎麼換算、用什麼單位、有效範圍怎麼判斷。
這還不是資料庫本身，也不是 DCE 統計邏輯。

原生流程是先分路，再由兩條支線呼叫各自的 Parser：

所以兩條資料路徑都依賴 ParserManager 內的解析能力與設定，
但不是共用同一次解析結果，也不是等 DB Parser 完成後才更新即時值。
但它本身不負責決定平均、累積、布林判斷，也不負責把統計結果寫成資料庫。

新增同類型裝置時，優先是在 ParserManager 的解析設定檔加規則，不是先改程式碼。

10-4 語意對應：把來源語意接到 DCE 行為

在 DB / 統計支線，ParserManager 解出來的是標準資料；
DCE 要知道的是這筆資料該怎麼被統計。
中間需要一份語意對應，將 Parser 輸出的來源 Key 接到 DCE 支援的平均、累積、布林、最大值或最小值等行為。

這份對應不是拿來取代 ParserManager，也不是資料庫路徑。它讓系統知道：這筆數值代表哪一類現場資料，以及後續應交給哪一種 DCE 行為。

原生 LocalNest 由 USFID 設定承接這個對應。ParserManager 交出帶有來源 Key 的標準資料；系統依 USFID 設定取出核心數值與 DCE運算代號；DCE 再依指定行為處理。APP 則依同一個 USFID 設定，把伺服器數值還原成資料名稱與顯示單位。

10-5 說白話：DCE 看的是統計性質

說白話，大部分現場資料會用到的統計方式，其實就那幾種。
溫度、濕度、照度，多半看平均值。
漏液、開關，多半看布林狀態。
用電度數、流量，多半看累積值。

所以在 DCE 架構下，溫度、濕度、照度就是同一種東西。
它們單位不同、物理意義不同，但 DCE 不在乎。
DCE 在乎的是統計性質：這筆資料後續是不是要算平均值。

這就是 DCE 的「去單位、萃取核心」：核心只處理數值與統計性質；資料名稱與單位留在語意定義中，交給顯示端還原。

漏液和開關也是一樣。
它們現場意義不同，但 DCE 看的是布林狀態：有或沒有、開或關、成立或不成立。

用電度數和流量則是累積型資料。
DCE 不會把它們拿去做單純平均，而是依累積型資料的規則處理。

也就是說：

只要不是新的統計方式，DCE 核心通常不用改程式。
不管是哪一家廠牌的溫度計，只要封包解析器把 raw data 正確解成標準資料，
進到 DCE 後就是算平均值。

DCE 接收 ParserManager 解析後的數值，依統計特性算出該時間段應保存的統計資料，
最後進入資料庫路徑。
至於 raw data 要從哪個位元組開始拆、倍率怎麼算、單位怎麼標，那是 ParserManager 的責任。

10-6 中小型 SI 的實際意義

LocalNest 的定位不是取代 PLC 或大型 SCADA。
LocalNest 的目標是：

這句話的重點不是「每個客戶都要自己維護」。
現場其實有兩種情況：有些客戶有內部工程人員，希望常見異動可以自己處理；
也有些中小型企業沒有人力，反而希望系統整合商或維護廠商長期負責。

ParserManager、語意對應與 DCE 真正要解決的是維護成本。
當新增同類型感測器、調整位元組位置、倍率、單位或統計特性對應時，
維護廠商不需要每次都回到研發排程、重新 build 程式、重新部署封包解析器。
常見變更能留在解析設定與語意對應完成，系統整合商就能用更低成本服務更多客戶，維持合理利潤。

設計簡單也有另一個好處：
維護廠商可以遠端指導客戶完成簡單設定，
或由一線維護人員依標準流程修改設定檔。
真的需要新增解析能力或架構變更時，再交回核心工程流程處理。

這裡還有另一個維運重點：LocalNest 的本地資料庫也是以 CSV 檔案形式落地。
這和 10-3 的 ParserManager 解析設定 CSV 是兩件事。
10-3 的 CSV 是解析規則；
這裡的 CSV 是資料在 DB 支線被 ParserManager 解析、再經語意對應與 DCE 統計整理後，
保存在 LocalNest 本地資料庫不同角色裡的資料檔。

也就是說，原始資料進站後，不是只停在即時畫面。
CoreNest 收到後先分成兩路：RealTimeManager 在即時支線自行呼叫即時 Parser 更新畫面與狀態；DB 支線另依 CatchPeriod、DB 用 Parser、語意對應與 DCE 整理，最後留下可備份、可搬移、可抽查的 CSV 型態資料庫（DB）。

這對中小型 SI 很實際：資料不被鎖在黑箱資料庫裡，
維護廠商可以直接備份、追查、搬移，
也比較容易把整理後的資料交給企業資源規劃系統（ERP）、製造執行系統（MES）或分析平台。
LocalNest 本地資料庫的完整分工會在 CH11 展開，
屆時會正式說明 Temp / System / Finial 三個角色。這裡先把名稱交代清楚：Finial 是原生系統沿用的資料夾與資料層名稱（legacy naming），不是通用的資料庫專業名詞；課程保留原拼字，是為了能直接對照實際路徑與原始碼。

這裡先知道：資料不是只停在即時畫面，
而是會留下本地 CSV 型態資料庫（DB），
支撐後續追查、統計與歷史查詢。