发酵食品批次追溯的数据建模难点：以调味品酿造为例

 

作者按：做过几个调味品厂的数字化项目，发酵环节的数据建模和肉制品、饮料差异很大。这里把踩过的坑整理一下，供做工业软件或 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：把发酵曲线+人工事件叠加在同一时间轴上，审计员一眼能看懂

六、小结

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

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

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