作者按:做过几个调味品厂的数字化项目,发酵环节的数据建模和肉制品、饮料差异很大。这里把踩过的坑整理一下,供做工业软件或 IoT 采集的朋友参考。
调味品发酵(酱油、醋、豆瓣酱、腐乳等)和连续生产最大的区别是:
时间维度被拉到极致
。
传统 MES 的"工单→工序→报工"模型在这里基本失效。你没法让操作工每天给发酵罐"报工"。
batch_no VARCHAR(64) PRIMARY KEY,
product_code VARCHAR(32),
starter_lot VARCHAR(64), -- 种曲/酵母批号
raw_material_lots JSON, -- 原料批号列表(大豆/小麦/麸皮)
status SMALLINT -- 发酵中/已出池/异常终止
关键在 raw_material_lots 用 JSON 存多个原料批——因为发酵投料不是一次性完成的,可能分 3-5 批投不同产地的黄豆。
event_type SMALLINT, -- 1翻醅 2添料 3取样 4温控调整 5异常
params_json JSON, -- 温度/pH/湿度等快照
params_json 是灵活字段,因为不同发酵阶段关注的参数不同:
发酵食品的 CCP 不是"杀菌温度"这种单点参数,而是
趋势
。
比如酱油发酵,关键不是某一天的 pH 值,而是 pH 从 6.5 降到 4.2 的
速率和曲线形态
。降太快可能是杂菌污染,降太慢可能是酶活性不足。
审计时需要的不是"某天的快照",而是
连续曲线 + 人工干预事件叠加显示
——曲线上能标出"哪天翻了醅、哪天加了盐"。
这是最难的。客户投诉"这批酱油有异味",你要能反查:
→ 发酵期间所有事件(翻醅频次/温控偏差/添料记录)
这个链路里,
发酵事件表是核心枢纽
。没有它,你只能查到"用了哪批黄豆",查不到"发酵第 45 天是不是温度超标了"。
1.
先数字化发酵事件
:让操作工每天用平板记录翻醅/添料/取样,比上传感器快得多
2.
温度先上无线探头
:发酵池埋 IoT 温度传感器,30 分钟采一次,成本几千块
3.
pH 和理化指标走 LIMS 对接
:别在 MES 里重复建检验模块
4.
追溯展示用时间轴 UI
:把发酵曲线+人工事件叠加在同一时间轴上,审计员一眼能看懂
发酵食品的数字化和饮料/肉制品最大的不同:
时间尺度从小时级变成月级,控制对象从设备变成微生物群落
。
数据模型要从"工单驱动"转向"批次+事件驱动"。先跑通发酵事件记录和温度曲线采集,后面的追溯、品质分析、工艺优化都是水到渠成的事。
本文基于实际调味品发酵项目经验整理。相关数据采集方案已在多个酿造车间落地运行。