作者按：做过几个调味品厂的数字化项目，发酵环节的数据建模和肉制品、饮料差异很大。这里把踩过的坑整理一下，供做工业软件或 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 的速率和曲线形态。降太快可能是杂菌污染，降太慢可能是酶活性不足。
所以数据采集策略要变：
参数 采集频率 存储策略
发酵池温度 每 30 分钟 时序数据库（InfluxDB/TDengine）
pH 取样 每 2-3 天人工+设备 关系库，绑定 event
环境温湿度 每 1 小时 时序库
翻醅操作 每 1-2 天一次 事件表
审计时需要的不是"某天的快照"，而是连续曲线 + 人工干预事件叠加显示——曲线上能标出"哪天翻了醅、哪天加了盐"。
四、风味追溯的逆向查询
这是最难的。客户投诉"这批酱油有异味"，你要能反查：
成品批号
→ 发酵批次号
→ 发酵期间所有事件（翻醅频次/温控偏差/添料记录）
→ 原料批号（黄豆产地/年份/存储条件）
→ 种曲批号（酶活性指标）
→ 环境数据（雨季/高温天影响）
这个链路里，发酵事件表是核心枢纽。没有它，你只能查到"用了哪批黄豆"，查不到"发酵第 45 天是不是温度超标了"。
五、落地建议
1.先数字化发酵事件：让操作工每天用平板记录翻醅/添料/取样，比上传感器快得多
2.温度先上无线探头：发酵池埋 IoT 温度传感器，30 分钟采一次，成本几千块
3.pH 和理化指标走 LIMS 对接：别在 MES 里重复建检验模块
4.追溯展示用时间轴 UI：把发酵曲线+人工事件叠加在同一时间轴上，审计员一眼能看懂
六、小结
发酵食品的数字化和饮料/肉制品最大的不同：时间尺度从小时级变成月级，控制对象从设备变成微生物群落。
数据模型要从"工单驱动"转向"批次+事件驱动"。先跑通发酵事件记录和温度曲线采集，后面的追溯、品质分析、工艺优化都是水到渠成的事。
本文基于实际调味品发酵项目经验整理。相关数据采集方案已在多个酿造车间落地运行。
