作者按：做过几个调味品厂的数字化项目，发酵环节的数据建模和肉制品、饮料差异很大。这里把踩过的坑整理一下，供做工业软件或 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 不是"杀菌温度"这种单点参数，而是趋势。

比如酱油发酵，关键不是某一天的 pH 值，而是 pH 从 6.5 降到 4.2 的速率和曲线形态。降太快可能是杂菌污染，降太慢可能是酶活性不足。

所以数据采集策略要变：

参数

采集频率

存储策略

发酵池温度

每 30 分钟

时序数据库（InfluxDB/TDengine）

pH 取样

每 2-3 天人工+设备

关系库，绑定 event

环境温湿度

每 1 小时

时序库

翻醅操作

每 1-2 天一次

事件表

审计时需要的不是"某天的快照"，而是连续曲线 + 人工干预事件叠加显示——曲线上能标出"哪天翻了醅、哪天加了盐"。

这是最难的。客户投诉"这批酱油有异味"，你要能反查：

成品批号

 → 发酵批次号

 → 发酵期间所有事件（翻醅频次/温控偏差/添料记录）

 → 原料批号（黄豆产地/年份/存储条件）

 → 种曲批号（酶活性指标）

 → 环境数据（雨季/高温天影响）

这个链路里，发酵事件表是核心枢纽。没有它，你只能查到"用了哪批黄豆"，查不到"发酵第 45 天是不是温度超标了"。

1. 先数字化发酵事件：让操作工每天用平板记录翻醅/添料/取样，比上传感器快得多

2. 温度先上无线探头：发酵池埋 IoT 温度传感器，30 分钟采一次，成本几千块

3. pH 和理化指标走 LIMS 对接：别在 MES 里重复建检验模块

4. 追溯展示用时间轴 UI：把发酵曲线+人工事件叠加在同一时间轴上，审计员一眼能看懂

发酵食品的数字化和饮料/肉制品最大的不同：时间尺度从小时级变成月级，控制对象从设备变成微生物群落。

数据模型要从"工单驱动"转向"批次+事件驱动"。先跑通发酵事件记录和温度曲线采集，后面的追溯、品质分析、工艺优化都是水到渠成的事。

本文基于实际调味品发酵项目经验整理。相关数据采集方案已在多个酿造车间落地运行。