作者按：做過幾個調味品廠的數字化項目，發酵環節的數據建模和肉制品、飲料差異很大。這里把踩過的坑整理一下，供做工業軟件或 IoT 采集的朋友參考。

一、發酵工藝的特殊性

調味品發酵（醬油、醋、豆瓣醬、腐乳等）和連續生產最大的區別是：時間維度被拉到極致。

· 醬油高鹽稀態發酵：3-6 個月

· 醋固態發酵：20-40 天

· 豆瓣醬自然曬露：6-12 個月

這意味著：

1. 一個"批次"的生命周期跨越數月甚至數年

2. 發酵過程中要經歷多次"翻醅/攪拌/添料"

3. 環境參數（溫度、濕度、光照）直接影響風味

4. 最終產品品質和中間每一天的狀態都有關

傳統 MES 的"工單→工序→報工"模型在這里基本失效。你沒法讓操作工每天給發酵罐"報工"。

二、核心實體重新設計

發酵場景的核心不是"工序"，而是"發酵事件"：

-- 發酵批次主表

fermentation_batch (

  batch_no          VARCHAR(64) PRIMARY KEY,

  product_code      VARCHAR(32),

  starter_lot       VARCHAR(64),    -- 種曲/酵母批號

  raw_material_lots JSON,           -- 原料批號列表（大豆/小麥/麩皮）

  start_date        DATE,

  expected_end_date DATE,

  status            SMALLINT       -- 發酵中/已出池/異常終止

);

關鍵在 raw_material_lots 用 JSON 存多個原料批——因為發酵投料不是一次性完成的，可能分 3-5 批投不同產地的黃豆。

然后是發酵事件表（記錄每一次翻醅、添料、檢測）：

-- 發酵過程事件

fermentation_event (

  id              BIGINT PRIMARY KEY,

  batch_no        VARCHAR(64),

  event_type      SMALLINT,   -- 1翻醅 2添料 3取樣 4溫控調整 5異常

  event_time      DATETIME,

  operator        VARCHAR(32),

  params_json     JSON,       -- 溫度/pH/濕度等快照

  notes           TEXT

);

params_json 是靈活字段，因為不同發酵階段關注的參數不同：

· 前期：溫度上升速率、水分含量

· 中期：pH變化、還原糖含量、氨態氮

· 后期：色率、總酸、氨基酸態氮

三、CCP 監控的難點

發酵食品的 CCP 不是"殺菌溫度"這種單點參數，而是趨勢。

比如醬油發酵，關鍵不是某一天的 pH 值，而是 pH 從 6.5 降到 4.2 的速率和曲線形態。降太快可能是雜菌污染，降太慢可能是酶活性不足。

所以數據采集策略要變：

審計時需要的不是"某天的快照"，而是連續曲線 + 人工干預事件疊加顯示——曲線上能標出"哪天翻了醅、哪天加了鹽"。

四、風味追溯的逆向查詢

這是最難的。客戶投訴"這批醬油有異味"，你要能反查：

成品批號

 → 發酵批次號

 → 發酵期間所有事件（翻醅頻次/溫控偏差/添料記錄）

 → 原料批號（黃豆產地/年份/存儲條件）

 → 種曲批號（酶活性指標）

 → 環境數據（雨季/高溫天影響）

這個鏈路里，發酵事件表是核心樞紐。沒有它，你只能查到"用了哪批黃豆"，查不到"發酵第 45 天是不是溫度超標了"。

五、落地建議

1. 先數字化發酵事件：讓操作工每天用平板記錄翻醅/添料/取樣，比上傳感器快得多

2. 溫度先上無線探頭：發酵池埋 IoT 溫度傳感器，30 分鐘采一次，成本幾千塊

3. pH 和理化指標走 LIMS 對接：別在 MES 里重復建檢驗模塊

4. 追溯展示用時間軸 UI：把發酵曲線+人工事件疊加在同一時間軸上，審計員一眼能看懂

六、小結

發酵食品的數字化和飲料/肉制品最大的不同：時間尺度從小時級變成月級，控制對象從設備變成微生物群落。

數據模型要從"工單驅動"轉向"批次+事件驅動"。先跑通發酵事件記錄和溫度曲線采集，后面的追溯、品質分析、工藝優化都是水到渠成的事。

本文基于實際調味品發酵項目經驗整理。相關數據采集方案已在多個釀造車間落地運行。